Dans l'IT, j'entends souvent la même phrase : « On est en retard. »
Les roadmaps évoluent constamment, les priorités changent, des sujets apparaissent, disparaissent, reviennent trois mois plus tard. Pour suivre ce mouvement, on multiplie les analyses, les ateliers, les tickets, les estimations et les réunions d'alignement. Et malgré tout cet appareillage, le sentiment de retard, lui, ne bouge pas.
Vous avez déjà passé des jours à analyser un sujet, à découper des tickets, à cadrer proprement une fonctionnalité… pour apprendre, à l'étape suivante de la roadmap, que finalement « ce ne sera pas pris maintenant » ? Vous avez déjà livré quelque chose qui marche, et reçu comme seul retour non pas « super, comment on l'intègre ? » mais « attends, on n'avait pas de story là-dessus, si ? ».
Si oui, ce billet va vous parler. Il ne parle pas d'un outil, d'un framework ou d'un pattern. Il parle d'une manière de travailler — la nôtre — et d'un grain de sable de plus en plus visible : on dit qu'on est agile, on dit qu'on est en retard, et pourtant la première réaction face à un résultat qui arrive trop tôt et hors cadre, c'est de regarder s'il rentre dans une case, pas s'il crée de la valeur.
Je vais raconter une histoire, puis essayer de comprendre pourquoi elle se répète. Et surtout : comment on pourrait faire autrement, sans jeter ni la roadmap ni la traçabilité, qui existent pour de bonnes raisons.
Le décor est banal. Une roadmap, des sprints, des sujets priorisés. Et un sujet en best-effort — ce statut tiède qui veut dire « si on a le temps ». On fait ce qu'on est censé faire en bons professionnels : analyse du besoin, réflexions techniques, création de tickets, discussions d'architecture. Le sujet est prêt à être attaqué.
Puis la roadmap bouge. Comme souvent. Le sujet est repoussé — pas annulé, pas réintégré non plus : évaporé. Le travail de cadrage, lui, reste dans un coin, ni mort ni vivant.
De mon côté, j'avais regardé le sujet de plus près. Par curiosité, mais aussi parce que les outils d'IA permettent aujourd'hui d'explorer une solution beaucoup plus vite qu'avant, j'ai décidé d'y consacrer mon temps disponible. En une poignée de jours, j'avais une version fonctionnelle. Attention : pas un produit qui pouvait partir en prod le lendemain. Une estimation en sprints ne mesure pas que le code — elle englobe les tests, la doc, l'accompagnement métier. Ce que j'avais sous la main, c'était peut-être 50 % du chemin vers la prod. Mais ces 50 % transformaient un pari en quasi-certitude : la faisabilité n'était plus une question, on voyait concrètement à quoi ça ressemblait, et la moitié du chemin était déjà parcourue. Le reste restait à faire — sauf qu'on ne marchait plus dans le noir.
J'en parle à l'équipe. Je m'attendais à des questions sur le fond : est-ce pertinent ? est-ce réutilisable ? est-ce que ça peut nous faire gagner du temps, accélérer la roadmap ? À la place, les premiers retours ont été :
« Ce que tu fais, ce n'est pas tracé. Il faudrait une tâche pour ça. »
« Je ne comprends pas pourquoi tu bosses là-dessus. On n'a pas de story sur ça dans le sprint, non ? »
« Pour l'instant, tu peux mettre en pause, car dans le prochain quarter, je ne sais pas encore si on va bosser dessus. »
Pas « est-ce que ça marche ? ». Pas « est-ce qu'on peut l'intégrer et marquer des points sur notre capacité à aller vite ? ». Pas « comment tu as fait en deux jours ? ». Non : est-ce que c'est dans une case.
C'est ce décalage que je veux disséquer. Parce que la réaction n'est pas absurde — elle est même rationnelle, vu de l'intérieur du système. Et c'est précisément ça le problème.
Petit retour aux sources, parce qu'il est savoureux. Le Manifeste Agile, celui qu'on invoque dans toutes les cérémonies, tient en quatre lignes. Quatre arbitrages :
Relisez maintenant les retours reçus.
« Ce n'est pas tracé » oppose la documentation au logiciel qui fonctionne. « On n'a pas de story dans le sprint » et « on verra au prochain quarter » opposent le suivi du plan à l'adaptation au changement. Trois phrases, et on a pris l'exact contre-pied des valeurs de gauche — celles qui sont censées primer.
Ce n'est pas de la malveillance. C'est ce que j'appelle l'agilité rituelle : on a gardé les cérémonies (le sprint, la story, le board, le burndown) et on a perdu l'intention qui les justifiait. Le rite survit à sa raison d'être. On ne se demande plus « est-ce qu'on s'adapte ? », on se demande « est-ce que c'est dans le sprint ? ». Le process, qui était un moyen, est devenu la fin.
Le symptôme le plus net, c'est le rapport au résultat. Dans une équipe vraiment agile, un logiciel qui marche est une bonne nouvelle, quelle que soit la porte par laquelle il est entré. Dans une équipe en agilité rituelle, le même livrable, parce qu'il n'était pas planifié, est d'abord une anomalie de process — quelque chose à régulariser avant, éventuellement, de se réjouir.
Il y a une contradiction qu'on ne relève jamais. On nous dit, dans le même souffle :
On invoque le changement quand il vient d'en haut, et le plan quand l'initiative vient d'en bas. La roadmap est suffisamment fluide pour qu'un sujet cadré disparaisse sans préavis, mais suffisamment rigide pour qu'un résultat livré ne puisse pas y rentrer.
Ce n'est pas de l'agilité, c'est de l'arbitraire à sens unique. Le changement est un droit du management ; pour le dev, c'est une faute de traçabilité.
Et ça produit exactement le gâchis qu'on prétend combattre. Le cadrage initial du sujet — l'analyse, les tickets — a été payé puis jeté. Le travail réalisé, lui, existe et fonctionne, mais on hésite à le ramasser parce qu'il n'a pas la bonne étiquette. On a réussi à perdre de la valeur des deux côtés : ce qu'on a planifié sans le faire, et ce qu'on a fait sans le planifier.
Derrière « pourquoi tu bosses là-dessus ? » se cache une croyance plus profonde, rarement dite à voix haute : le développeur exécute, il n'initie pas. Il prend une story en haut de la pile, il la fait, il en prend une autre. L'initiative, dans ce modèle, n'est pas une qualité — c'est un écart. Un truc « pas tracé ».
C'est une erreur de casting sur ce qu'est, concrètement, la valeur d'un dev.
Un développeur n'est pas une fonction qui transforme des stories en code. C'est la personne qui est au contact de la matière : elle voit où sont les vraies frictions, ce qui coûte cher pour rien, ce qui pourrait être fait dix fois plus vite, ce qui est en train de pourrir. Cette information-là ne remonte dans aucune cérémonie. Elle ne vit que dans la tête de ceux qui codent. La brider, c'est jeter la source d'information la plus fine qu'une équipe possède sur son propre produit.
Et il y a un effet de bord cruel. Quand on répond « pas de story, pas de sujet » à quelqu'un qui a pris une initiative et qu'elle a marché, on n'éteint pas que cette initiative-là. On apprend à toute l'équipe que l'initiative ne paie pas — qu'au mieux elle est ignorée, au pire elle crée un problème de conformité. La fois suivante, personne n'essaie. On obtient exactement les exécutants qu'on croyait avoir, mais on les a fabriqués.
L'ironie, c'est que ce sont souvent les mêmes organisations qui, en réunion, déplorent que « les équipes manquent d'autonomie » et qu'« il faut être plus proactif ». L'initiative est appréciée tant qu'elle reste prévisible ; l'autonomie est valorisée tant qu'elle ne dérange pas le plan.
Il faut nommer l'éléphant — mais en le mettant à sa juste place. L'IA n'est pas le sujet principal de cette histoire. Le sujet, c'est ce qu'elle révèle.
Si j'ai fait en une poignée de jours ce qui était estimé en sprints, ce n'est pas un exploit personnel, c'est un changement d'échelle de l'outillage. L'IA a compressé le temps entre « j'ai compris le besoin » et « j'ai quelque chose qui tourne ». Or nos cadences — le sprint de deux semaines, l'estimation en points, la roadmap trimestrielle — ont été calibrées dans un monde où ce délai était long.
Quand l'exécution devient beaucoup plus rapide que la planification, le goulot d'étranglement se déplace : ce n'est plus « coder prend du temps », c'est « décider, prioriser, tracer prend du temps ». Le process, conçu pour synchroniser un travail lent, devient le facteur le plus lent.
C'est tout le sens de cette histoire : le code n'était pas le frein. Le frein, c'est que l'organisation n'avait pas de réceptacle pour un résultat arrivé hors cadence. Pas de case pour « quelqu'un a livré quelque chose d'utile plus vite que prévu ». Et ce qui n'a pas de case devient suspect.
La vraie question que pose l'IA n'est donc pas technique. Elle est organisationnelle : nos équipes sont-elles conçues pour saisir les opportunités quand elles surgissent, ou seulement pour suivre le plan établi ? Rien là-dedans ne plaide pour supprimer le cadre. Il s'agit d'admettre qu'il a été dessiné pour un tempo qui n'existe plus, et qu'il faut le redessiner — avant qu'il n'étouffe la vitesse qu'on prétend vouloir.
Maintenant, soyons honnêtes, parce qu'un coup de gueule qui ne reconnaît pas l'adversaire ne convainc personne. La traçabilité et la roadmap ne sont pas des caprices bureaucratiques. Elles répondent à de vrais besoins :
Donc « ce n'est pas tracé » n'est pas une bêtise. La bêtise, c'est d'en faire la seule et première réaction, et de l'utiliser comme un stop plutôt que comme un et ensuite. La traçabilité devrait être une conséquence à organiser, pas un péage à l'entrée qui annule la valeur de ce qui a été produit.
Le vrai sujet n'est pas « process contre initiative ». C'est : comment rendre l'initiative lisible par le système, pour qu'elle soit récompensée au lieu d'être régularisée à contrecœur. Quelques leviers concrets, du plus collectif au plus organisationnel.
Une équipe saine réserve du slack : un pourcentage de capacité (10–20 %) explicitement dédié aux initiatives, aux explorations, aux améliorations non planifiées. Ça donne une place légitime à ce qui sort du sprint, au lieu d'en faire une anomalie.
Surtout, il faut une règle simple et inversée : face à un résultat qui marche, la première question est « quelle est sa valeur ? », la traçabilité vient juste après. L'ordre des questions, c'est tout ce qui sépare une équipe qui capte la valeur d'une équipe qui la laisse filer pour respecter une forme.
Si on mesure une équipe à sa conformité au plan (vélocité, respect du sprint), on obtient de la conformité au plan. Si on veut de la vitesse et de l'initiative, il faut les rendre visibles et valorisées : raconter les coups gagnés en marge de la roadmap, les remontées du terrain qui ont fait gagner des semaines. Ce qui n'est pas célébré ne se reproduit pas.
Et il faut accepter de recalibrer les cadences à l'ère de l'IA. Si l'exécution est dix fois plus rapide, garder des cycles de planification d'avant l'IA, c'est faire de la planification le goulot — et transformer un avantage compétitif en file d'attente.
Soyons clairs pour finir : je ne pense pas qu'il faille abandonner les processus, ni développer tout ce qui nous passe par la tête. Le problème n'est pas le cadre — c'est l'ordre dans lequel on l'applique. Et je crois qu'on confond deux choses : suivre le plan et créer de la valeur. La plupart du temps, les deux coïncident, et le process fait son travail discrètement. Mais le jour où ils divergent — un sujet abandonné qu'on livre quand même, un résultat qui arrive trop tôt et hors cadre — on découvre laquelle des deux l'équipe sert vraiment. Et trop souvent, c'est le plan.
L'agilité rituelle et le dev-exécutant sont les deux faces d'une même pièce : un système qui valorise la forme plus que le fond, et la conformité plus que l'initiative. Le coût n'est pas qu'un projet raté de temps en temps. C'est que les gens les mieux placés pour voir où est la valeur apprennent à se taire, et que la vitesse offerte par les nouveaux outils est immédiatement reprise par la lenteur des process.
La bonne nouvelle, c'est qu'aucun de ces leviers n'exige de brûler la roadmap ou la traçabilité. Il suffit d'inverser l'ordre des questions : d'abord est-ce que ça crée de la valeur, ensuite comment on le trace et on l'intègre proprement. Un détail, en apparence. En réalité, toute la différence entre une équipe qui fait semblant d'être agile et une équipe qui l'est — entre celle qui décourage exactement ce qu'elle prétend rechercher, et celle qui sait reconnaître les gens capables d'agir sur une opportunité avant qu'elle ne devienne évidente pour tout le monde.