Y a-t-il encore une place pour l'agilité avec l'AI-DLC ?

Le procès de l'agilité

Depuis quelques mois, une thèse circule dans les équipes de développement : l'agilité aurait fait son temps, et l'IA l'aurait rendue obsolète. Ses arguments ne sont pas tous faux, et il faut les prendre au sérieux.

Une méthode pensée pour un autre rythme

Le Manifeste Agile date de 2001. Il a été pensé pour des développeurs qui écrivaient chaque ligne de code à la main. Le cadre même du sprint et ses cérémonies (la planification, le point quotidien, la revue, puis la rétrospective) répondent à un tempo humain. Aujourd'hui, lorsqu'un agent d'IA produit un incrément fonctionnel en quelques heures, ce travail se retrouve bloqué en attente du prochain rituel : le point quotidien revient sur un travail déjà terminé, et la revue de sprint fait attendre deux semaines une démonstration qui aurait pu avoir lieu le jour même.

AWS dresse le même constat. Le 31 juillet 2025, Raja SP introduit l'AI-Driven Development Life Cycle (AI-DLC) sur le blog DevOps d'AWS. Il y constate que les product owners, les développeurs et les architectes passent l'essentiel de leur temps en planification, en réunions et en rituels, plutôt qu'au cœur de leur métier. Réduire l'IA à un simple assistant greffé sur ces méthodes traditionnelles, conclut-il, bride ses capacités et entretient des inefficacités dépassées.

Une maîtrise qui reste rare

Les chiffres de Forrester semblent leur donner raison. Selon son rapport « The State of Agile Development, 2025 », 61 % des répondants pratiquent l'agilité depuis plus de cinq ans, mais seulement 7 % des équipes en maîtrisent pleinement les pratiques.

Le même rapport conclut pourtant que l'agilité reste pertinente : 95 % des professionnels interrogés la jugent essentielle à leur activité, et l'IA générative y apparaît comme une occasion d'en renforcer l'effet. Ces chiffres disent en réalité autre chose que la fin de l'agilité : la plupart des organisations ne l'ont jamais vraiment pratiquée. Elles en ont surtout appliqué le calendrier.

Ce que l'AI-DLC change vraiment

Dans ce nouveau cycle, l'IA ne se contente plus de compléter du code : elle rédige les exigences, propose l'architecture, écrit le code et les tests, puis prépare l'infrastructure. L'équipe, de son côté, valide et approuve chaque étape.

Trois phases, une même boucle

Le cycle comprend trois phases : Inception, où l'intention métier devient des exigences détaillées ; Construction, où l'architecture, le code et les tests sont produits ; Operations (exploitation), où l'infrastructure et le fonctionnement en production sont pris en charge. Ces trois phases suivent une même boucle en cinq temps :

1. L'humain formule une intention.

2. L'agent rédige un plan et pose ses questions de clarification.

3. L'humain répond, corrige et approuve le plan.

4. L'agent exécute.

5. L'humain vérifie le résultat, et la boucle repart.

AWS écarte ainsi deux écueils : l'IA cantonnée à la simple complétion de code, et l'agent autonome que personne ne contrôle. Sa règle tient en une formule : « AI proposes, humans decide » (l'IA propose, l'humain décide).

Un nouveau vocabulaire

La méthode renomme les objets familiers de Scrum. AWS donne lui-même les deux premières correspondances ci-dessous ; les deux suivantes sont notre lecture de la méthode, par analogie.

La même logique de séance collective vaut pour la construction : en « Mob Construction », l'équipe tranche en direct les propositions de l'agent. Sur un projet neuf, le premier bolt peut livrer un « Walking Skeleton », la version la plus mince de l'application qui traverse déjà toutes les couches. AWS a aussi publié une implémentation open source de la méthode, aidlc-workflows, utilisable notamment dans Claude Code, Cursor et Kiro.

Plus de code ne veut pas dire plus de livraison

Si l'IA écrit plus vite, pourquoi les entreprises ne livrent-elles pas plus vite ? La question revient dès qu'une organisation passe de l'expérimentation au déploiement réel. Notre lecture tient en une idée : le gain se joue sur toute la chaîne de livraison, pas sur l'écriture du code. C'est pour cela que nos missions commencent par un diagnostic de maturité de tout le cycle, avant le choix d'un outil. Les chiffres publiés en 2025 vont dans ce sens :

Les deux rapports convergent : accélérer la production du code ne suffit pas, il faut faire circuler le travail dans tout le système. C'est exactement le problème que l'agilité cherchait à résoudre.

À lire aussiCode généré par l'IA : pourquoi « ça marche » ne veut pas dire « c'est maintenable »Les agents de code produisent vite du code qui passe les tests. Mais un code qui fonctionne n'est pas forcément un code sain. Ce que la recherche sur la détection des défauts de conception nous apprend, et comment garder la dette technique sous contrôle.Lire l'article

Les rituels tombent, les valeurs restent

Le décalage entre la vitesse des agents et le calendrier des cérémonies ne se règle pas en raccourcissant les réunions. Il oblige à revoir l'organisation elle-même : les rituels doivent suivre le rythme réel de la livraison, et non l'inverse. Dans l'AI-DLC, c'est le sprint lui-même qui change de nature.

Des principes qui ne bougent pas

L'agilité n'est pas née avec les sprints. L'un de ses principes fondateurs demande déjà de livrer « fréquemment un logiciel opérationnel avec des cycles de quelques semaines à quelques mois et une préférence pour les plus courts ». Le bolt ne le contredit pas : il le pousse à son terme.

Ce qui définit l'agilité tient en trois gestes : itérer, obtenir un retour rapide, ajuster. Chez Adservio, nous concevons les bolts de la même façon : des itérations courtes pour obtenir un retour, ajuster le produit et intégrer ce retour dans l'itération suivante. La boucle est plus courte, mais c'est la même boucle.

Ce que confirment les données de DORA

L'équipe DORA de Google va dans le même sens. En septembre 2025, elle a publié un modèle des capacités qui amplifient l'effet de l'IA sur la performance des équipes. Deux des sept capacités retenues sont des principes agiles de toujours :

• Le travail en petits lots : il renforce l'effet positif de l'IA sur la performance du produit et réduit les frictions pour les équipes.
• L'attention portée à l'utilisateur : elle accroît l'effet positif de l'IA sur la performance des équipes. Sans elle, selon DORA, l'adoption de l'IA peut au contraire dégrader la performance : les équipes avancent vite, mais dans la mauvaise direction.

Le goulot se déplace : exigence et revue

Quand produire du code ne coûte presque plus rien, la contrainte se déplace en amont et en aval de la production.

En amont : la clarté de l'exigence

Dans un projet mené en AI-DLC, le premier risque n'est pas l'IA : c'est la clarté et la complétude des exigences. Une exigence floue produit, plus vite qu'avant, un logiciel qui ne répond pas à la question posée. Si la conception n'est pas étanche, l'IA n'évite pas le désalignement : elle l'accélère. La séance d'élaboration collective est donc le moment décisif, celui où le métier et l'équipe s'accordent sur ce qui doit être construit avant que l'IA ne le construise.

En aval : la revue et le risque du coup de tampon

Le temps de revue augmente presque autant que le volume produit, et la tentation est connue : valider vite, sans vraiment relire. La situation ressemble à l'entrée d'un stade où des dizaines de milliers de spectateurs se présentent devant une poignée de contrôleurs : soit le contrôle devient symbolique, soit la file s'allonge. Accélérer la production sans élargir la revue ne change rien au débit final : c'est le passage le plus étroit qui le fixe.

Des tests fiables et une équipe disponible

Pour que la boucle tienne, l'équipe ne peut pas tout relire ligne à ligne. Elle s'appuie sur des tests automatisés dérivés du comportement attendu, et non du code produit : ils permettent à l'agent de corriger ses propres erreurs avant de soumettre son travail. Un bolt n'a de sens, enfin, que si le retour arrive vite. Si le métier n'est disponible pour valider qu'une fois tous les quinze jours, la boucle courte redevient un sprint de deux semaines.

À lire aussiCas de tests générés par IA à partir de user storiesUne expérimentation contrôlée mesure la génération de cas de tests par IA : 80 % de temps gagné, 27 % d'ambiguïté, et ce que les agents de 2026 changent.Lire l'article

Ce que nous recommandons

Avant d'introduire un agent, nous recommandons d'évaluer la maturité du cycle de développement, étape par étape. Notre référentiel compte cinq niveaux, d'absent à piloté, et chaque niveau suppose le précédent acquis : l'IA accélère ce qui est déjà structuré, et amplifie ce qui ne l'est pas.

L'étape la plus faible fixe ce que l'IA peut accélérer sans dégâts. C'est par elle qu'il faut commencer, avant d'outiller les autres.

Dans une orchestration AI-DLC, l'humain pose l'intention et valide ; l'orchestrateur découpe le travail. Pour savoir si l'organisation fonctionne, nous recommandons de garder les quatre indicateurs de livraison définis par DORA : délai de livraison, fréquence de déploiement, taux d'échec des changements et temps de rétablissement. Ce ne sont pas de nouveaux critères : ce sont ceux qui comptaient déjà avant l'IA. La question reste la même : la fonctionnalité attendue a-t-elle été livrée, en combien de temps, et avec quelle fiabilité ?

Par où commencer

Sans attendre la fin de la série, cinq gestes permettent de savoir où en est votre organisation :

1. Mesurer avant de changer : relever ces quatre indicateurs sur un projet, pour savoir d'où l'on part.

2. Situer chaque étape : remplir la grille ci-dessus avec l'équipe plutôt que seul, puis renforcer l'étape la plus faible avant d'outiller.

3. Raccourcir la boucle : lancer un pilote avec des bolts de quelques jours et un métier disponible pour valider à ce rythme.

4. Revoir les rituels un par un : garder ceux qui produisent une décision ou un retour, alléger ceux qui ne font que constater l'avancement.

5. Surveiller la file de revue : si elle s'allonge, c'est là qu'il faut investir, pas dans davantage de production.

Notre approche de l'AI-DLC et du test augmenté est détaillée sur notre page dédiée.

À lire aussiAgile à grande échelle : Au-delà du modèle SpotifyLe modèle Spotify (Squads, Tribes, Chapters, Guilds) a dominé les discussions sur l'agile à grande échelle pendant des années. Mais voici un secret : même Spotify ne suit plus le modèle Spotify.Lire l'article

Notre réponse : la vérifier en public

Les travaux cités mesurent des milliers d'équipes, de l'extérieur. Aucun ne montre ce qui se passe, étape par étape, dans un projet mené en AI-DLC. C'est ce que nous allons faire.

Dans les prochaines semaines, nous vous montrerons l'AI-DLC à l'œuvre sur un projet créé pour l'exemple et mené de bout en bout selon la méthode. Nous publierons chaque étape : les questions posées par l'agent, les plans refusés, les bolts menés en parallèle, les erreurs et les mesures. Le cas est construit pour l'occasion ; l'exécution et les chiffres seront réels. À la fin de la série, nous dirons, mesures à l'appui, ce que sont devenus nos rituels, et ce qu'il reste de l'agilité.