En faisant mes adieux à l’agile
(lewiscampbell.tech)- Réexamen critique de la méthodologie Agile qui a dominé l’industrie logicielle : en pratique, elle n’aurait été qu’un ensemble de principes flous et un reconditionnement de problèmes déjà résolus
- L’opposition avec le modèle waterfall relèverait largement de l’illusion, et des concepts clés comme le développement itératif et la participation du client étaient déjà formulés dans des travaux des années 1970
- Agile s’est toujours défini uniquement comme l’opposé du modèle waterfall, alors que les limites de ce modèle étaient déjà largement connues dès les années 1970
- Avec l’émergence récente des grands modèles de langage (LLM), le développement guidé par les spécifications (Spec-Driven Development) redevient central, et une approche centrée sur la documentation gagne du terrain
- Le mot d’ordre agile « du logiciel qui fonctionne plutôt qu’une documentation exhaustive » est désormais en train de céder la place à l’idée que « une documentation exhaustive produit un logiciel qui fonctionne »
- Au-delà du flou laissé par Agile, il est temps de revenir à des principes clairs et à une approche d’ingénierie
RIP Agile, we hardly knew ye.
And I mean that literally - because no one was ever clear on what it was.
Agile, repose en paix. Nous ne t’avons jamais vraiment connu.
Et je le dis au sens littéral : parce que personne n’a jamais vraiment su clairement ce que c’était.
Le problème d’identité d’Agile
- Agile a été une immense vague qui a balayé toute l’industrie du logiciel, mais en réalité le concept s’est diffusé alors même que son sens restait flou
- Chaque fois qu’une critique surgissait, la réponse revenait inlassablement : « ce n’est pas du vrai Agile »
- Quand on lit réellement le Manifeste Agile (2001), on y trouve très peu de directives concrètes, plutôt des maximes vagues du type « la collaboration avec le client est plus importante que la négociation contractuelle »
- Des principes comme « accueillir favorablement les changements d’exigences, même tard dans le développement » sont commercialement irréalistes
- Sous l’argument du « True Agile », on a régulièrement évacué les problèmes pratiques en prétendant qu’ils n’avaient rien à voir avec le manifeste
- Si l’industrie de l’agile ne pratique pas réellement l’agile, et si le manifeste lui-même manque de substance, alors la réalité même d’Agile devient sujette à caution
« Un spectre du waterfall hante le logiciel »
- Agile s’est toujours défini uniquement par ce qu’il n’était pas — le waterfall — avec une logique simple : si vous ne faites pas de l’agile, alors vous faites du waterfall, et le waterfall ne fonctionne pas
- Pourtant, le fait que le waterfall ne fonctionne pas était déjà connu dès 1970, et Winston W. Royce en avait expliqué précisément les raisons
- Royce recommandait comme alternative de commencer par la conception du programme, de construire un prototype logiciel pour affiner les exigences, et d’impliquer le client de manière formelle, approfondie et continue
- Tout cela a ensuite été présenté comme l’innovation d’Agile, alors qu’en réalité c’était déjà écrit en 1970, l’année suivant l’alunissage
- Note 1 : comment les programmeurs de l’Apollo Guidance Computer ont-ils pu accomplir un tel exploit sans story points, et sans même connaître le principe selon lequel « une attention continue à l’excellence technique renforce l’agilité » ?
L’article Bell-Thayer de 1976 et l’histoire du développement itératif
- L’article de Bell et Thayer de 1976 est présenté comme le premier texte à employer le terme « Waterfall », et ce terme y sert lui-même d’exemple de ce qu’il ne faut pas faire
- Conclusion de l’étude empirique de cet article : les défauts des exigences ne sont découverts, au cours du développement logiciel, qu’au moment où l’on tente de satisfaire ces exigences par la conception
- Le développement itératif n’avait rien de nouveau et avait déjà été affiné en continu pendant des décennies avant Agile
- Même avant que le manifeste ne « libère » l’industrie, le waterfall n’était pas à la pointe de l’état de l’art, et personne de sérieux ne mettait vraiment en doute l’utilité des exigences et des spécifications
L’essor du développement guidé par les spécifications et l’après-Agile
- Avec la diffusion des LLM, les programmeurs reviennent à l’écriture de spécifications
- Les LLM étant fragiles face aux entrées ambiguës, décrire clairement le problème s’impose comme le meilleur moyen d’obtenir le bon code
- Là où Agile mettait en avant « du logiciel qui fonctionne plutôt qu’une documentation exhaustive », le développement guidé par les spécifications propose la thèse inverse : « une documentation exhaustive produit un logiciel qui fonctionne »
- Royce soulignait déjà en 1970 que « documentation, spécification et conception ne font qu’un avant l’écriture du code ; si la documentation est mauvaise, la conception l’est aussi »
- Il insistait sur le fait que si la documentation n’existe pas, alors la conception n’existe pas non plus
- En revenant sur les travaux de 1970 et 1976, on constate que le Manifeste Agile de 2001 n’a pas apporté d’éclairage réellement nouveau
- Agile n’aurait fait que remplacer une approche d’ingénierie existante par une définition floue et un emballage commercial, sans produire de progrès substantiel
- Les articles de ces ingénieurs étaient bien plus clairs dans leur signification
- Alors que le développement logiciel continue de changer et d’évoluer, il est temps d’envoyer Agile dans les livres d’histoire et d’adopter une nouvelle perspective
- Il faut revenir aux principes clairs et à la pensée d’ingénierie légués par les ingénieurs sérieux du passé
21 commentaires
Je ne sais pas pourquoi on considère à ce point les méthodologies comme des textes sacrés. À mon avis, l’auteur original n’était pas si différent non plus : seule l’orientation changeait, mais il relevait tout autant du dogmatisme.
Je trouve que la conclusion est un peu excessive. La commercialisation ou la formalisation peuvent poser problème, mais cela ne veut pas dire que des outils comme les sprints ou le backlog sont devenus inutiles. Ils ont aussi contribué à ancrer une culture de réunion plus horizontale et centrée sur les objectifs. Il est vrai que le SDD a gagné en importance, mais comme on peut désormais rédiger rapidement cette spécification de manière collaborative avec l’IA, cela reste malgré tout agile. Les sprints de deux semaines se sont simplement raccourcis à quelques heures ; l’essence même, celle d’itérer en affinant progressivement, me semble inchangée.
Je suis d’accord.
Rien qu’avec la remise en cause de la prise de décision verticale et l’amélioration itérative par cycles courts, le message qu’elle nous laisse est fort pour nous (et il en va évidemment de même pour les méthodes et outils de gestion de projet).
La conclusion selon laquelle « l’agile lui-même n’a pas apporté de nouvelles perspectives et caricature tous ceux qui le défendent en fans aveugles de l’agile » me semble excessive.
Je suis d’accord. L’agile reste toujours pertinente. On dirait des propos tenus dans le vide par des gens qui n’ont jamais travaillé sur le terrain.
C’est un article assez idiot. Le point essentiel, c’est qu’il faut rédiger la spec. elle-même de manière agile... L’agilité, c’est s’adapter rapidement à l’évolution des exigences du client.
C’est à cause de ce genre de malentendus sur l’agilité et des idées vagues que les choses partent dans la mauvaise direction, que ce soit pour l’agilité ou pour la culture de développement.
Qu’est-ce que ça veut dire, au juste, « rédiger les specs de façon agile » ?
Au fond, le point essentiel de cet article, c’est qu’on ne sait même pas vraiment ce qu’est l’agile. On n’a cessé de dire que l’agile a telles ou telles caractéristiques et qu’il faut faire ceci ou cela, mais jusqu’à présent je n’ai jamais vu d’article qui montre concrètement : « voici un produit construit selon la méthodologie agile ». Même en lisant le Manifeste, ça reste assez flou. Peut-être pourriez-vous en montrer un exemple ?
C’est le contenu de base que l’on retrouve dans la plupart des livres sur les méthodes agiles, comme l’Extreme Programming de Kent Beck ou le Scrum de Jeff Sutherland. Vous pouvez aussi regarder les user stories. La plupart des gens ne savent pas vraiment que le fondement de l’agile, ce sont des sprints courts et des démos afin de s’adapter rapidement aux exigences des clients.
Les points 3 et 4. Écrire des specs en détail a une profondeur infinie. Ce que je veux dire, c’est qu’il existe un niveau adapté à chaque organisation. Quand on regarde l’histoire de la manière dont les services à succès ont été développés, je crois savoir que dans 99 % des cas, l’essentiel est justement de ne pas mettre trop d’énergie à rédiger des specs de façon parfaitement précise. Il ne faut pas s’y enfermer. Il suffit de voir comment ont été créés Summoners War, Dungeon & Fighter, Zigbang ou Lineage.
Et si le cycle en cascade ne prenait qu’une journée ?
Ces derniers temps, je vois ce genre de cas plus souvent.
Terriblement, c’est probablement ce que je vois le plus souvent...
En Corée, l’agile ne sert ni plus ni moins qu’à mettre la pression sur les délais des développeurs.
À certains égards, tout le monde est agile. Je me demande même s’il y a déjà eu une époque où l’on déployait aussi vite qu’aujourd’hui et où l’on recevait autant de retours.
À part les déploiements en cycles courts, je ne vois pas bien ce qu’il reste de l’agile.
Le backlog et les sprints existaient déjà auparavant sous d’autres formes, et la communication avec le client comporte souvent beaucoup d’aspects peu compatibles avec la réalité. Au final, je pense que l’amélioration du DevOps a davantage fait progresser le développement que l’agile.
Cet article lui-même n'est pas agile !
Comme on n’est pas sans avoir à lire du code, l’idée que le code prime sur la documentation me semble valable sous cet angle. Et puisque, en tant qu’instructions, la documentation doit être lue par la LLM qui en assure l’implémentation, je suis aussi d’accord de ce point de vue. Donc, au final, j’ai l’impression que les deux sont importants en même temps.
Le problème des produits fondés sur la productivité des LLM aujourd’hui, c’est la dette qui s’accumule en phase d’exploitation. Pour assurer une exploitation continue, les développeurs doivent intervenir sur le code, et pour cela je pense qu’à ce stade le code doit encore pouvoir tenir lieu de documentation.
Pour formuler une objection avec prudence, je pense que le code ne peut pas remplacer la documentation. Les langages de programmation n’ont pas encore la richesse d’expression ni la capacité de transmission du langage naturel, et, en pratique, qui peut vraiment lire tout ce code ?
Avoir un code capable de remplacer la documentation est un espoir, un vœu pieux, mais c’est une tour de Babel impossible à atteindre.
Autant faire sérieusement de l’OOAD, cela me paraît bien mieux.
À l’inverse, je pense aussi qu’il sera difficile que le langage naturel remplace le code. Le langage naturel, s’il est plus rapide que le code, est aussi bien trop abstrait. Pour l’informatique, il faut finalement combler les détails, et il semble difficile que le langage naturel puisse assumer ce rôle.
Dans l’écriture de logiciels, le problème n’est pas tant l’abstraction que l’ambiguïté. Le langage naturel est intrinsèquement ambigu. Il est aussi polysémique. C’est peut-être pour cela que les tentatives de coder en langage naturel ne fonctionnent pas très bien.
Dans ces conditions, imaginer que le langage naturel puisse remplacer le code relève carrément du fantasme.
Je comprends tout à fait votre point de vue.
Il y a clairement des aspects qui ne peuvent pas être remplacés par le code.
Dans ce sens, si je devais l’expliquer un peu différemment, ce que je voulais dire, c’est qu’un code très lisible permet d’éviter d’avoir à produire de la documentation.
La documentation qui s’accumule au fil du temps à mesure que le logiciel évolue impose elle aussi une charge cognitive aux développeurs. L’idée centrale est de réduire les allers-retours entre le code et la documentation.
Je ne pense pas qu’on puisse ne laisser que le code.
J’imagine que cela peut varier selon le contexte et la situation.
Merci pour votre commentaire.
Avis sur Hacker News
Agile m’a fait observer un phénomène intéressant
Quand ça échoue, on l’interprète comme un cas où « on n’en a pas fait assez ».
J’ai vu le même schéma avec le cloud, les microservices ou les politiques d’austérité : la cause de l’échec serait toujours un manque d’exécution, jamais l’idée elle-même, qui resterait forcément juste.
Si une équipe essaie Agile et que ça ne marche pas, on sort alors l’argument défensif : « ce n’était pas du vrai Agile ». Au final, Agile devient un concept qui ne peut pas échouer.
Le Manifeste Agile ne parle que de valeurs et de principes. Le vrai problème, c’est une culture d’entreprise qui essaie de le faire entrer de force dans un processus.
Une structure qui pousse à l’introspection en cas d’échec n’est pas forcément mauvaise. En ce sens, encourager l’examen de soi plutôt que de rejeter la faute sur l’extérieur peut même relever d’un système sain.
Une roadmap promise aux clients et une capacité d’adaptation souple vont difficilement ensemble. En pratique, des organisations centrées sur le planning se contentent d’imiter Agile.
En cas d’échec, on conclut qu’« il aurait fallu utiliser davantage d’agents ». Ça ressemble à cette blague selon laquelle « on n’a jamais assez de tokens ».
J’en suis venu à craindre la formalisation d’Agile.
J’ai piloté avec succès une équipe d’une quarantaine de personnes, mais le vrai Agile tient en quatre phrases : les personnes, un logiciel qui fonctionne, la collaboration avec le client et la capacité à répondre au changement.
Le problème, c’est que l’« Agile » avec un grand A s’est au contraire transformé en processus rigide.
Quand l’effectif augmente, l’alignement sur les objectifs devient plus difficile et on finit par avoir besoin de contrôle et de procédures.
On allait même jusqu’à restreindre le droit de créer des tickets, ce qui n’avait plus grand-chose à voir avec la flexibilité.
Avec une documentation insuffisante, la maintenance devient impossible, et on finit dans une logique de développement YOLO.
L’Agile des grands groupes où j’ai travaillé était un mensonge.
Un collègue disait : « si on fait à l’avance le travail du sprint suivant, on termine toujours à l’heure ».
Autrement dit, Agile fonctionnait comme un système de production d’indicateurs plutôt que comme une vraie manière de travailler.
Les managers se satisfont de voir les chiffres monter, et le produit devient un simple sous-produit de la statistique.
Ça vaut la peine de relire le texte original du Manifeste Agile.
C’est le seul véritable point d’accord. Il faut se rappeler à quel point le Waterfall d’avant Agile était désastreux.
C’était l’arme qui a mis fin à l’époque où l’on imposait des calendriers fixes et des livrables figés.
Si les équipes travaillent de manière autonome, cela menace leur position.
Comme le disait Kent Beck dans « Extreme Programming », Agile était une tentative pour échapper à la tyrannie d’une omniscience imaginaire.
Le Waterfall d’autrefois prétendait tout prévoir dès la phase de conception et ignorait l’apprentissage comme le feedback.
Mais avec le temps, les rites et la forme d’Agile ont fini par recouvrir son essence.
J’aime toujours l’Agentic programming, mais au final l’important reste le rôle humain qui relie le contexte.
L’article original était confus.
Il disait d’un côté qu’Agile n’avait rien inventé de nouveau, puis affirmait de l’autre que si les LLM écrivent le code, alors Agile est mort.
Pourtant, le cœur d’Agile, c’est reconnaître des spécifications incomplètes et améliorer itérativement.
Ce principe reste valable.
Agile n’en est qu’une variante parmi d’autres ; il y a surtout eu beaucoup de mauvaises implémentations.
Les bons produits naissent au fond d’une boucle spécification → apprentissage → correction.
Des procédures comme le Backlog Grooming ou la Sprint Review finissent au contraire par freiner le changement.
Le développement fondé sur des spécifications ne me paraît pas fait pour durer.
Construire un logiciel qui fonctionne puis itérer reste plus rapide — au fond, c’est le retour d’Agile.
La qualité des spécifications s’est améliorée, et la revue est devenue plus facile que celle du code.
Voir le lien GitHub.
On ne trouve nulle part dans le manifeste des termes comme Daily Standup ou Agile Coach.
L’essentiel, c’est de dire : « ne faites pas de micro-management des programmeurs ».
En d’autres termes, il faut offrir un cadre et de la confiance à des personnes motivées.
Kent Beck, Martin Fowler et les autres fondateurs visaient au départ des lignes directrices souples.
Mais avec le temps, tout cela s’est commercialisé, et des adeptes dogmatiques sont apparus, ce qui a accentué la confusion.
Le succès dépend en fin de compte des compétences et de l’attitude des personnes.
La durée des sprints doit elle aussi être ajustée selon le contexte, et s’il n’y a pas de spécifications, l’équipe doit les produire elle-même.
Même à l’ère de l’IA, si quelqu’un utilise Agile avec discernement, cela reste pertinent.
Je me demandais ce que voulait exactement dire « écrire une spec ».
Tous les projets Agile sur lesquels j’ai travaillé avaient des documents de conception, et les tickets en découlaient.
Un développement fondé sur des tickets sans documentation me semblerait infernal.
Chacun les interprète comme il veut.
Une approche centrée sur les tickets serait au contraire plus proche d’un Agile pur.
Le faux Agile fait comme si les documents produits par le PO ou le PM étaient la vérité.
La manière dont vous l’avez décrit est justement ce qui se rapproche le plus de ce que j’entendais par « rédaction de spécifications ».