Opposition Agile vs Traditionnel : dogmatisme ou démagogie ?
J'ai une opinion assez arrêtée sur le sujet. La voici.
TL;DR
Je ne souscris pas au discours démagogique selon lequel approches agile et traditionnelle seraient tous les deux biens, et qu’il faudrait juste utiliser le bon en fonction du contexte… ❌
Je ne souscris pas non plus au discours dogmatique selon lequel : “l’approche traditionnelle c’est mal, agile c’est bien” ❌
En résumé : ces 2 discours sont trop simplistes !
Je partage dans cet article un certain nombre de nuances 😊
Le discours démagogique : “agile ou traditionnel, tout dépend du projet”
On entend souvent ce discours, notamment dans la bouche de ceux qui défendent la gestion de projet traditionnelle : il ne faudrait pas opposer approches agile et traditionnelle, ce serait deux trousses à outils distinctes et toutes deux pertinentes.
⚠️ Je ne cautionne PAS ce visuel !
Il est donné à titre d’exemple pour illustrer ce premier type de discours.
Je ne vais pas rentrer dans le détail en prenant un par un les arguments pour expliquer en quoi ils me semblent au mieux simplistes, au pire fallacieux.
Je me contenterai de dire ceci :
Il y aurait apparemment des projets où tout planifier en amont sans boucles de rétroaction rapides serait pertinent ! 🤔
Désolé, mais non. Ca ne se passe pas comme ça dans la vraie vie. 🤷
Le discours dogmatique : “traditionnel c’est mal, agile c’est bien”
On entend souvent aussi ce discours, cette fois plutôt dans la bouche des agilistes : les preuves ne manquent pas pour démontrer les soucis de l’approche traditionnelle, et c’est pourquoi les approches agiles ont été inventées. Bref, agile c’est mieux.
⚠️ Je ne cautionne PAS non plus ce visuel !
Il est également donné à titre d’exemple pour ce deuxième type de discours.
Mes propos de la section précédente peuvent suggérer que c’est ce que je pense.
Et bien, oui et non.
Sur le fond, oui c’est ce que je pense. Et il est vrai que les preuves ne manquent pas pour démontrer les soucis de l’approche traditionnelle, et que l’approche agile fonctionne mieux.
Néanmoins, sur la forme, ce discours est dogmatique et surtout simpliste. Ce qui le rend maladroit et contreproductif. Et c’est aussi un peu faux car on fait un mélange des genres.
Plus globalement, cette manière d’expliquer et d’amener les choses manque de beaucoup de nuances, que je vais apporter dans la section suivante.
Le vrai ennemi : faire n’importe quoi
On aime bien faire des versus pour faire passer des messages — que cela soit pour dire que agile et traditionnel sont différents mais complémentaires, ou pour dire que agile est mieux que traditionnel.
Pourtant, le vrai ennemi, celui qui mériterait réellement d’avoir son versus, c’est de faire n’importe quoi, comme le fameux Larrache. 1
Je me permet donc de refaire un visuel explicatif traditionnel vs agile, qui cette fois appuie plus sur la similarité des deux que sur l’opposition, tout en appuyant sur les difficultés et les nuances pour bien appliquer les approches :
D’un côté, on n’est pas sensé faire un projet traditionnel sans jalons, sans cycles, sans validation au plus tôt, sans gestion de risque dynamique. En somme, sans gestion de projet !
De l’autre, l’excellence technique, la qualité et la discipline sont les prérequis qui permettent les itérations rapides promues par l’agilité.
Il n’y a aucune opposition 🤔
Si ce n’est une opposition à faire n’importe quoi : sans cadre, sans logique, sans boucle de feedback ou sans expertise.
L’approche traditionnelle EST agile
Ainsi, plutôt que d’opposer les approches traditionnelle et agile, ou de les considérer comme à destination d’usages différents, je préfère dire que, bien faits, on parle de la même chose. Même si parfois le vocabulaire varie.
Il n’y a pas de projet où l’agilité n’a pas sa place.
Quand Tesla met en production entre 27 et 40 modifications par modèle et par jour, dans du hardware, dans une industrie réglementée et hautement complexe avec de nombreux sous-traitants, alors comment justifier qu’un quelconque projet logiciel pourrait durer un an, un trimestre ou même un mois sans avoir de jalon intermédiaire, de démonstration réelle ou de boucle de feedback ?2
La gestion de projet est agile par défaut
On pourrait penser qu’en écrivant que les approches traditionnelle et agile sont la même chose je risque m’attirer la foudre de la communauté des chefs de projets. C’est tout l’inverse : la gestion de projet moderne utilise le même vocabulaire que l’agilité et a les mêmes points de référence.
Par exemple, le PMI, le Project Management Institute, a complètement adopté l’agilité depuis longtemps déjà :
Le PMI sponsorise des événements agiles, et d’ailleurs la Agile Alliance a rejoint le PMI
Le PMI a fusionné avec DAD, Disciplined Agile Delivery, qui propose peut-être bien la meilleure source d’information sur l’agilité — disponible sur le site du PMI ! 3
Ou encore le PMBOK, Project Management Body Of Knowledge, fait la part belle à l’agilité comme une évidence depuis des années
Pour aller au bout de l’argumentaire, j’ajouterais que le cycle en V est censé fonctionner… En cycles 🤷
On oublie très souvent que Winston Royce, auteur d’un article souvent mis en avant comme la référence décrivant le cycle en V, dit lui-même dans cet article que :
L’approche en cascade (waterfall) ne marche pas, et
Qu’une approche itérative est dans tous les cas nécessaire.
Le vrai problème de l’approche traditionnelle mal faite reste donc l’absence d’itération et de boucles de feedback. On pourrait arguer que des sprints Scrum comme autant d’itérations de cycle en V, c’est un mode de fonctionnement qui marcherait. 4
L’argument recevable : le coût du changement
Reste un argument que je veux bien entendre :
“On a toujours fait comme ça, et c’est trop risqué d’essayer de changer nos manières de faire au vu des délais courts du projet.”
OK. Admettons que l’on soit sur un projet avec des contraintes fortes, notamment en temps, qui ne nous permettent pas d’envisager de sereinement tester de nouvelles manières de travailler sans mettre en péril le projet.
Je peux totalement comprendre que l’on se dise alors, dans cette situation : “ce n’est pas le bon moment pour apprendre à mieux travailler.”
J’ajouterais même que c’est super d’être aussi clair, tant que c’est bien de la lucidité et pas une excuse pour ne jamais essayer de s’améliorer.
Ca s’appelle la conduite du changement. Un moment pour chaque chose.
Tant qu’on n’utilise pas cet argument pour se complaire dans la médiocrité, bien entendu.
Pour ceux qui n’ont pas la référence, c’est une blague courante autour de l’expression “travailler à l’arrache”, qui avec un peu de déformation deviendrait la méthode Larrache. Des petits plaisantins sont allés jusqu’à déposer le nom de domaine la-rache.com et d’y héberger un véritable site satirique, tenu à jour (mise à jour 2026 sur l’IA, passage obligé !) et qui propose de générer son propre certificat de réussite ! Allez-y pour rigoler un coup 😁
Dans la même veine on a également “les méthodes à Gilles” comme manière de faire de l’auto-dérision autour de l’agilité et pour parler de son incompréhension auprès du commun des mortels.
Je tiens cette statistique de Joe Justice, de l’époque où il était passé chez Tesla en 2020. Les choses ont certainement bougé en 5 ans 😬
Nous avions parlé de Disciplined Agile sur Scrum Life lors d’une interview de Jean-Yves Klein :
Introduction à Disciplined Agile Delivery : https://www.pmi.org/disciplined-agile/process/introduction-to-dad
La base de connaissance détaillée, le “Disciplined Agile browser” : https://dabrowser.pmi.org/
C’était exactement l’exercice intellectuel auquel je m’étais prêté dans le Scrum Life suivant. En conclusion, la différence toucherait plus aux rôles et à l’ownership qu’aux processus à proprement parler :
Et bien sûr, on est ici sur une approche qui reste naïve de Scrum, en particulier sans Continuous Delivery. Cependant, cela correspond au contexte des sociétés qui se posent réellement la question de comparer les approches agile et traditionnelle, avec un cycle de release toujours long en 2026 😅