L'agile au temps de l'IA

Le sprint planning a été conçu pour une réalité bien précise : des personnes estimant le travail d'autres personnes. Les backlogs étaient rédigés pour des développeurs qui lisaient les tickets, en précisaient l'intention, écrivaient leur code et le testaient à la main, tous à des cadences comparables. La plupart des rituels agiles, des métriques et des logiques de planification se sont bâtis sur ce contrat implicite.

Mais toute pratique évolue, et ce qui fonctionne à un moment donné est appelé à changer.

L'IA ne se contente pas d'accélérer la livraison du logiciel : elle en transforme la nature même. Certaines phases (la mise en œuvre, tout particulièrement) voient leur durée se réduire fortement,tandis que d'autres n'en deviennent que plus déterminantes :validation, revue, cohérence architecturale, sécurité et fiabilisation avant la mise en production.

Ce n'est pas une affaire d'outils, mais de modèles opérationnels.

L'agilité est née en réaction au modèle en cascade, et à l'illusion qu'un logiciel complexe puisse être intégralement spécifié à l'avance. Son idée maîtresse : l'incertitude est irréductible ; le système de livraison doit donc être pensé pour la faire émerger et l'absorber en continu, plutôt que de chercher à l'éliminer dès le départ.

Itérations courtes, logiciel fonctionnel comme mesure de l'avancement, retours continus, collaboration transverse : tous ces principes répondaient à une réalité bien précise. Le travail était réalisé par des personnes, à leur propre rythme ; la mise en œuvre était l'étape la plus longue ; et le cycle de deux semaines s'imposait naturellement comme cadence de planification.

Les principes tiennent toujours ; les mécanismes, eux, ne suivent plus.

L'IA met chacune de ces hypothèses à l'épreuve, et toutes en même temps :

Les boucles de feedback qui maintenaient la livraison alignée sur les objectifs métier inspirent désormais moins confiance.

Pendant des années, les responsables techniques ont considéré la capacité à produire du code comme la principale contrainte limitant le débit de livraison. L'IA révèle aujourd'hui à quel point cette vision était partielle.

La véritable limite, aujourd'hui, n'est plus la génération du code, mais sa revue.

La revue de code n'est plus un simple point de contrôle qualité appliqué à du code écrit à la main. Elle devient le mécanisme central par lequel les équipes transforment un flot abondant de code généré en évolutions fiables du système. Or, la plupart des équipes n'y sont pas encore préparées.

Le code généré par l'IA transforme le travail du relecteur, qui doit désormais examiner :

Une tâche plus exigeante, et menée à un volume plus élevé.

C'est pourquoi le sprint se comprime de manière inégale : la mise en œuvre se réduit, tandis que la revue et l'intégration s'étendent dans l'espace ainsi libéré. Les équipes voient le tableau avancer, mais le système, lui, accumule du risque.

Sur le plan pratique, cela revient à structurer le travail de manière plus réfléchie :

La planification agile classique était, au fond, une planification de la charge de travail : combien cette équipe peut-elle produire sur une période donnée ? Story points, vélocité, charge de sprint : ces outils visaient tous à piloter la répartition de l'effort.

L'IA déplace la contrainte. La capacité à produire devient plus abondante ; désormais, c'est le bon jugement humain, exercé au bon moment, qui s'impose comme la ressource limitante.

La question devient de moins en moins « combien pouvons-nous produire ? », et de plus en plus« où concentrer le jugement humain, et comment éviter qu'il ne se dilue dans le volume ? »

Cela ne fait pas disparaître l'estimation ; cela en transforme plutôt la nature. Les dimensions de planification qui comptent désormais :

Là où un chiffre unique tend à tout aplatir, ces dimensions rendent compte de ce que le travail demande vraiment sur le plan opérationnel.

Dans un environnement plus lent, un ticket flou ne ralentissait qu'un seul développeur. Dans un processus assisté par l'IA, en revanche, il amplifie la confusion à l'échelle du système. Le binôme humain-IA peut malgré tout produire quelque chose qui semble fini ; le résultat n'est alors pas un travail bloqué, mais un travail mal orienté.

Le changement est subtil mais important : jusqu'ici, un bon ticket était un ticket assez petit pour tenir dans un sprint. Aujourd'hui, il doit être assez clair pour que rien ne se perde dans l'interprétation. Cela suppose d'expliciter :

Dans un contexte où tout s'accélère, « terminé » ne se résume plus à « c'est livré et ça a l'air de marcher ». Calibrée pour la livraison assistée par l'IA, une définition du « terminé » comprend en général :

Plus le rythme s'accélère, plus une définition claire du « terminé » devient un facteur de stabilité.

Une critique répandue de l'IA en ingénierie pointe l'automatisationcomme le vrai danger. En profondeur, le risque tient plutôt à la confiance qu'elle installe.

L'IA produit des livrables qui paraissent complets, argumentés et professionnels. Les équipes confondent alors cohérence et justesse, finition et fiabilité, rapidité et maîtrise.

C'est d'abord un problème de jugement, avant d'être technique : comment l'équipe distingue-t-elle ce qu'elle sait réellement de ce qu'elle suppose, et combien de temps lui faut-il pour repérer qu'une confiance est mal placée ?

Si les équipes peuvent produire bien plus de changements, elles doivent aussi faire apparaître plus tôt les contradictions.C'est précisément là que l'intuition la plus profonde de l'agilité garde toute sa pertinence. La valeur du travail itératif n'a jamais tenu à la seule vitesse : elle réside aussi dans la capacité à se corriger en cours de route et à rester aligné sur les besoins réels de l'entreprise.

C'est en rétrospective que s'opère ce réajustement, comme un bilan fiable de ce qu'a réellement donné le travail assisté par l'IA :

Dans les équipes matures, la rétrospective devient un exercice de calibrage : ce à quoi se fier, ce qu'il faut vérifier, ce qu'il faut confier de nouveau à une personne. Le ressenti du sprint compte désormais moins que l'intelligence opérationnelle.

Adapter la méthode agile à l'IA ne consiste pas à repartir de zéro. L'essentiel de la livraison itérative reste valable ; quelques ajustements ciblés suffisent à transformer l'expérience de la livraison assistée par l'IA. Voici quelques points de départ :

La méthode agile n'a pas besoin d'être entièrement repensée. Certains de ses réflexes essentiels comptent même plus qu'avant. Toute la question est de distinguer ce qu'il faut préserver de ce qu'il faut laisser partir, car s'accrocher aux mauvais éléments coûte aussi cher que renoncer aux bons.

Ce qui mérite d'être préservé ne se résume pas aux processus : ce sont les habitudes qui maintiennent l'équipe à l'écoute des besoins réels de l'entreprise. Les retours des parties prenantes, les petits incréments, les rétrospectives honnêtes : voilà ce qui empêche la livraison de dériver, quelle que soit sa vitesse.

Le principe même de la livraison itérative n'a changé : un travail complexe ne se prévoit pas parfaitement, il se pilote. Ce qui change, c'est de savoir où porter son attention.

L'accès à de meilleurs modèles ne sera pas longtemps un facteur de différenciation. Les outils progressent, les capacités deviennent courantes, et ce qui ressemble aujourd'hui à un avantage deviendra demain la norme.

Ce qui fera la différence entre les équipes est plus difficile à reproduire : la capacité à repenser leur façon de travailler autour d'un rythme d'exécution plus soutenu, sans perdre de vue ce qu'elles cherchent réellement à construire.

L'avantage n'ira pas aux équipes qui produisent le plus, mais à celles qui sauront :

La méthode agile a toujours eu pour but de raccourcir la distance entre le travail et l'apprentissage. Cela n'a pas changé. Avec l'IA dans l'équation, ce qui a changé, c'est le rythme du travail et avec lui, la vitesse à laquelle cet écart peut se creuser faute de vigilance. Car le besoin d'alignement, lui, restera toujours une constante.

Le défi central reste le même :comment avancer vite dans l'incertitude sans perdre le contact avec le réel.Au temps de l'IA, ce n'est plus seulement une philosophie de livraison : c'est la discipline opérationnelle qui séparera les équipes qui passent à l'échelle de celles qui dérivent.