Sommaire
Depuis quelques mois, une petite musique commence à revenir de plus en plus souvent dans les discussions autour du développement logiciel : Agile serait mort. Comme souvent dans notre industrie, la formule est volontairement provocatrice. Elle fonctionne bien dans un titre, elle déclenche des débats et elle permet surtout de pointer un malaise réel. Car si Agile n’est probablement pas mort, une partie de l’organisation du développement logiciel telle que nous la pratiquons depuis vingt ans commence sérieusement à montrer ses limites face à l’arrivée des agents IA.
Le problème ne vient pas nécessairement des principes Agile eux-mêmes. Il vient plutôt du fait que nous avons construit des méthodes, des cérémonies et des habitudes autour d’une contrainte très précise : la capacité humaine à produire du logiciel. Une équipe possède un nombre limité de développeurs, chaque développeur dispose d’un temps limité et il faut donc organiser cette capacité rare. On découpe le travail, on estime, on priorise, on planifie et l’on essaie de mesurer ce que l’équipe peut absorber sur une période donnée.
Pendant longtemps, cette logique avait du sens. Mais en 2026, une nouvelle variable est en train de modifier profondément l’équation : les agents de développement.
Le goulot d’étranglement est en train de se déplacer
Nous ne parlons plus simplement d’autocomplétion ou d’un assistant capable de générer une fonction PHP à partir d’un commentaire. Les outils actuels commencent à explorer des codebases entiers, analyser une architecture, modifier plusieurs fichiers, écrire des tests, corriger des erreurs et exécuter des tâches relativement longues avec un degré d’autonomie de plus en plus important.
GitHub utilise désormais publiquement l’expression « Agent-Driven Development » pour décrire certaines de ces nouvelles pratiques. OpenAI pousse des workflows multi-agents autour de Codex, tandis qu’Anthropic étudie déjà à grande échelle la manière dont les développeurs utilisent Claude Code dans des situations réelles. Nous sommes encore loin d’un modèle totalement stabilisé, mais la direction est claire : le développeur n’est plus systématiquement la seule unité d’exécution du processus de production logiciel.
Pendant longtemps, le code était l’un des principaux goulots d’étranglement. Une fonctionnalité pouvait être parfaitement définie, validée et priorisée, mais il fallait encore attendre qu’un développeur dispose du temps nécessaire pour l’implémenter. Avec les agents, cette contrainte commence progressivement à se déplacer.
Le problème devient moins « qui va écrire le code ? » et davantage « avons-nous correctement défini ce qui doit être construit, avec quelles contraintes et comment allons-nous valider le résultat ? ».
Cette nuance est importante, car elle change directement la manière dont nous devrions penser l’organisation du travail.
Oui, une certaine forme d’Agile est probablement en train de mourir
Prenons volontairement la thèse la plus radicale. Une fonctionnalité est identifiée le lundi. Elle doit être décrite dans un ticket, passer par une phase de refinement, être estimée, priorisée puis intégrée dans un sprint en fonction de la capacité disponible de l’équipe. Dans certaines organisations, plusieurs jours, voire plusieurs semaines, peuvent s’écouler avant même que le travail ne commence réellement.
En parallèle, un développeur correctement équipé peut aujourd’hui demander à un agent d’explorer le projet, d’identifier les composants concernés, de proposer plusieurs stratégies d’implémentation et de préparer une première version de la modification. Selon la complexité du sujet, tout cela peut parfois se produire avant la prochaine réunion de refinement.
Il serait évidemment malhonnête de prétendre que toutes les fonctionnalités peuvent désormais être développées en quelques minutes. Ce n’est pas le cas, et les agents rencontrent encore de nombreuses limites. Mais le décalage entre la vitesse potentielle d’exécution et la vitesse de certains processus organisationnels devient difficile à ignorer.
Nous avons progressivement construit une bureaucratie importante autour de la production logicielle. Cette bureaucratie était souvent justifiée par la nécessité de protéger une capacité de développement limitée. Lorsqu’une ressource est rare, il est logique d’essayer de l’optimiser au maximum.
Mais que se passe-t-il lorsque cette capacité d’exécution devient partiellement élastique ?
Dans ce contexte, un sprint de deux semaines peut parfois devenir moins un outil d’accélération qu’une simple file d’attente. Le processus commence alors à avancer moins vite que les outils qu’il est censé organiser.
Non, Agile n’est probablement pas mort
Il faut maintenant faire exactement l’exercice inverse et revenir aux principes plutôt qu’aux implémentations.
Livrer rapidement du logiciel fonctionnel, collaborer avec les utilisateurs, réduire les boucles de feedback et accepter le changement sont des idées qui restent extrêmement pertinentes. On pourrait même défendre que les agents IA rendent certains principes Agile encore plus intéressants.
Si le coût d’une modification diminue, il devient possible de tester une hypothèse plus rapidement, obtenir un retour, corriger puis recommencer. La boucle entre construction, feedback et adaptation peut devenir beaucoup plus courte. Sur ce point, les agents ne sont pas en opposition avec Agile. Ils peuvent au contraire renforcer sa philosophie initiale.
Le problème est peut-être ailleurs. Au fil des années, nous avons parfois confondu Agile avec l’ensemble des cérémonies et des mécanismes de gestion qui se sont construits autour. Les réunions sont devenues automatiques, les story points ont parfois été transformés en indicateurs de productivité et certains tickets sont désormais si détaillés qu’ils expliquent presque au développeur quelle ligne de code modifier.
Agile n’est donc peut-être pas mort. En revanche, la bureaucratie construite autour d’Agile pourrait rapidement se retrouver confrontée à une réalité beaucoup moins confortable.
Nos outils sont en train de changer plus vite que nos méthodes de travail.
Du ticket à l’intention
L’une des évolutions qui m’intéresse le plus concerne le niveau d’abstraction auquel nous définissons le travail.
Dans un fonctionnement classique, nous avons tendance à découper les fonctionnalités en tâches extrêmement précises. Ajouter un bouton d’export CSV. Créer une route API. Ajouter une colonne dans une table. Modifier l’affichage d’une page.
Cette approche répond encore une fois à une contrainte humaine. Une personne doit récupérer la tâche, comprendre ce qui est attendu puis l’exécuter. Plus la tâche est précise, plus nous réduisons le risque d’interprétation.
Avec des systèmes agentiques, nous pourrions progressivement remonter d’un niveau et définir davantage l’intention que la tâche elle-même.
Au lieu de demander simplement d’ajouter un bouton d’export CSV, nous pourrions expliquer que l’objectif est de permettre à un marchand d’exploiter ses données de commandes en dehors de son logiciel. Nous préciserions ensuite les contraintes : respecter l’architecture existante, ne pas exposer de données sensibles, supporter un volume important et éviter l’ajout d’une dépendance externe.
Enfin, nous définirions les conditions de succès. L’export doit être exploitable, les performances validées, les tests présents et la sécurité contrôlée.
La différence peut sembler subtile, mais elle est fondamentale. Dans le premier cas, nous décrivons une tâche à exécuter. Dans le second, nous définissons un espace de décision dans lequel un système peut explorer plusieurs solutions.
Ce modèle ne supprime absolument pas le développeur. Il augmente même son niveau de responsabilité, car quelqu’un doit définir correctement les limites de cet espace de décision.
Le véritable problème sera la validation
C’est généralement ici que on commence à me méfier des discours trop enthousiastes sur les agents IA.
Produire davantage de code n’est pas nécessairement une bonne nouvelle. Les travaux de DORA décrivent l’IA comme un amplificateur. Elle peut renforcer les qualités d’une organisation, mais également accélérer ses dysfonctionnements.
Une mauvaise architecture ne devient pas meilleure simplement parce qu’un agent est capable de produire du code plus rapidement. Une couverture de tests insuffisante devient même plus inquiétante lorsque la quantité de modifications augmente. Quant à un processus de déploiement fragile, il ne sera pas réparé par l’ajout de cinq agents capables de générer des pull requests en parallèle.
Nous pourrions donc très rapidement découvrir que la production de code n’était qu’une partie du problème.
Le nouveau goulot d’étranglement risque de se déplacer vers la décision, la compréhension du contexte, la sécurité, la review et surtout la validation. Plus la capacité d’exécution augmente, plus notre capacité à contrôler cette exécution devient critique.
Dans un monde où un développeur produit dix modifications par semaine, une review imparfaite représente déjà un risque. Dans un monde où plusieurs agents peuvent produire des dizaines de modifications en parallèle, la validation devient une discipline centrale.
C’est probablement à cet endroit que le développement agentique deviendra réellement un sujet d’ingénierie et non plus simplement une fonctionnalité impressionnante dans une démonstration.
Le développeur ne va pas devenir « prompt engineer »
On n’ai jamais vraiment cru à l’idée que les développeurs allaient devenir des prompt engineers passant leur journée à chercher la formulation magique pour obtenir du bon code.
Le métier est probablement en train de monter d’un niveau d’abstraction.
Un développeur expérimenté devra toujours comprendre une architecture, identifier des dépendances, anticiper les effets de bord et évaluer la qualité d’une solution. En revanche, il devra également apprendre à définir correctement une intention, fournir un contexte exploitable, poser des contraintes claires et déterminer le niveau d’autonomie acceptable pour un agent.
Il faudra aussi savoir organiser plusieurs capacités d’exécution et, surtout, conserver la capacité de regarder un résultat techniquement fonctionnel et de dire non.
Le développeur de demain ne sera peut-être plus celui qui écrit le plus de code. Il pourrait devenir celui qui sait gouverner correctement une capacité massive à en produire.
Cette compétence est très différente de la simple maîtrise d’un langage ou d’un framework. Elle demande une vision plus large du système, une capacité à raisonner sur les contraintes et une compréhension beaucoup plus fine du risque.
Bienvenue dans l’ère de l’Agent-Driven Development
On ne pense pas qu’Agile va disparaître brutalement en 2026. On pense en revanche que nos méthodes de travail vont devoir rattraper nos outils beaucoup plus rapidement que prévu.
Les agents commencent à explorer, coder, tester et travailler en parallèle. Dans le même temps, de nombreuses organisations continuent à mesurer leur capacité de développement avec des modèles construits à une époque où la production de code dépendait presque exclusivement du nombre d’heures disponibles dans une équipe humaine.
Ce décalage va devenir de plus en plus visible.
Peut-être que demain nous parlerons moins de sprint capacity et davantage de capacité de validation. Peut-être que les notions de budget agentique, de niveau d’autonomie, de qualité du contexte ou de gouvernance deviendront aussi importantes que la vélocité l’a été pendant les vingt dernières années.
On me méfie encore énormément de ceux qui prétendent avoir déjà inventé la méthode universelle du développement agentique. Nous sommes au début de cette transformation et il serait probablement dangereux de remplacer une bureaucratie Agile par une nouvelle bureaucratie de l’IA avant même d’avoir compris ce qui fonctionne réellement.
Mais après quinze ans passés dans le développement logiciel, j’ai rarement vu notre capacité d’exécution évoluer aussi rapidement.
Alors non, Agile n’est probablement pas mort.
Le développement logiciel vient simplement de changer de moteur. Et continuer à conduire exactement de la même manière serait peut-être notre plus grosse erreur.
