« Nous avons terminé notre transformation agile, tous nos collaborateurs sont certifiés. » « Avez-vous une certification à une méthode agile ? Sinon nous ne recrutons pas. » « Cette année, j'aimerais que mon entreprise m'offre une certification. » Ces trois phrases, je les entends depuis dix ans, et elles disent toutes la même chose : on a confondu le diplôme avec la compétence, et le rituel avec le changement.

Les méthodes agiles, c'est un peu comme les régimes à la mode. Tout le monde en parle, tout le monde veut les essayer, presque personne ne tient la discipline qui les rendrait utiles. On achète le programme, on affiche le tableau, et six mois plus tard on pèse le même poids en ayant dépensé beaucoup d'argent. Sauf qu'ici, ce n'est pas votre silhouette qui est en jeu, c'est la capacité de votre organisation à décider vite et bien.

Je ne suis pas en train de dire que l'agilité est une escroquerie. Je dis que la grande majorité de ce qui se vend sous ce nom est une mise en scène. Et je vais essayer de le montrer avec les sources primaires plutôt qu'avec des statistiques d'agence.

Que dit vraiment le Manifeste Agile de 2001 ?

Il tient sur une page, il ne nomme aucun outil et il ne prescrit aucune cérémonie. Le Manifeste pour le développement agile de logiciels a été rédigé et signé par 17 personnes réunies à The Lodge at Snowbird, dans l'Utah, du 11 au 13 février 2001. Il énonce quatre valeurs et, dans son texte complémentaire, douze principes. C'est tout. Vous pouvez le lire en trois minutes.

Les quatre valeurs, dans leur formulation d'origine

La formule complète du Manifeste précise que les éléments de droite ont de la valeur, mais que ceux de gauche en ont davantage. Cette nuance a disparu du discours ambiant. Dans la plupart des organisations que je croise, la colonne de droite a purement et simplement gagné, et on appelle ça une transformation agile.

Ce que les douze principes ne disent nulle part

Les douze principes parlent de satisfaction du client, de livraison fréquente, de collaboration quotidienne entre le métier et la technique, d'équipes auto-organisées, de rythme soutenable et de simplicité. Un seul évoque une pratique récurrente, et encore sans la nommer : « à intervalles réguliers, l'équipe réfléchit aux moyens de devenir plus efficace ». Il n'y a ni Daily, ni Sprint, ni Jira, ni certification, ni framework de mise à l'échelle. Ces objets sont arrivés après, et ce sont eux que l'on vend.

Le Manifeste tient en une page et ne coûte rien. Tout ce que vous avez payé par-dessus est une interprétation, et vous avez le droit de la contester.

Pourquoi les rituels agiles ne produisent-ils pas l'agilité ?

Parce qu'un rituel reproduit la forme d'un comportement sans en reproduire la cause. C'est exactement le mécanisme que Richard Feynman a décrit en 1974 à Caltech sous le nom de « science du culte du cargo ». Il racontait ces habitants du Pacifique Sud qui, après la guerre, avaient reconstruit des pistes d'atterrissage, allumé des feux sur les côtés, installé un homme dans une cabane de bois avec deux morceaux de bois sur les oreilles en guise de casque, et qui attendaient les avions. Sa conclusion tient en une phrase : la forme est parfaite, tout ressemble à ce qui existait avant, mais aucun avion ne se pose.

Remplacez la piste par un tableau Kanban, le casque en bois par un poste de Scrum Master certifié, et les feux de bord de piste par un burndown chart. Vous obtenez la moitié des transformations agiles françaises.

Le culte du cargo agile n'est pas une métaphore de coach, c'est un objet d'étude

Trois chercheuses et chercheurs suédois ont pris la métaphore au sérieux et l'ont instrumentée. Tanja Elina Havstorm, Fredrik Karlsson et Karin Hedström ont mené une étude ethnographique de trois équipes de développement, présentée à la conférence HICSS-56 en 2023. En observant uniquement leurs réunions quotidiennes, ils ont documenté 12 situations de comportement de type culte du cargo, réparties en 7 catégories de déviations : apport d'informations non pertinentes, annulation de la réunion, perturbation de l'équipe, réception d'informations peu claires, introduction de nouvelles exigences, résolution de problèmes à la place de la synchronisation, et distribution de tâches.

Regardez la dernière de cette liste. Un Daily qui sert à distribuer des tâches n'est pas un Daily, c'est un point d'affectation hiérarchique déguisé en rituel horizontal. La forme dit « équipe auto-organisée », le fond dit « le chef répartit le travail ». L'équipe se lève tous les matins pour rejouer l'organisation qu'elle prétend avoir quittée. Les mêmes auteurs ont prolongé ce travail en juillet 2025 avec un outil analytique publié dans la revue Information and Software Technology, ce qui donne au sujet une base autrement plus solide que les billets d'humeur, dont celui-ci.

Les signataires du Manifeste l'avaient dit avant tout le monde

Ce ne sont pas les critiques extérieurs qui ont tiré la sonnette d'alarme, ce sont les auteurs eux-mêmes. Dave Thomas, l'un des 17 signataires, publie le 4 mars 2014 un texte intitulé « Agile is Dead (Long Live Agility) ». Sa thèse : le mot « agile » est devenu un nom commun que l'on peut vendre, alors qu'il désignait une manière de faire. On n'est pas un développeur agile, on est un développeur qui travaille avec agilité. La nuance grammaticale porte tout le problème : un adjectif ne se certifie pas.

Quatre ans plus tard, en juin 2018, Martin Fowler, également signataire, nomme le phénomène devant la conférence Agile Australia : le « complexe agilo-industriel », cette industrie qui impose aux équipes des processus standardisés vendus au forfait, en contradiction directe avec la première valeur du Manifeste qu'il a lui-même signée. Sa lucidité mérite d'être notée, il précise qu'il en fait partie.

Que disent les travaux sérieux sur l'échec des transformations agiles ?

Ils disent que les obstacles sont culturels et managériaux, et que la littérature disponible est bien plus faible qu'on ne le prétend. Deux travaux académiques font référence, et leurs résultats convergent.

La revue systématique de Kim Dikert, Maria Paasivaara et Casper Lassenius, parue dans le Journal of Systems and Software en septembre 2016, reste la synthèse la plus citée du domaine. Elle est aussi la plus honnête, parce que ses auteurs signalent une limite que personne ne relaie : environ 90 % des publications qu'ils ont retenues sont des retours d'expérience, pas des recherches contrôlées. Autrement dit, le corpus scientifique sur les transformations agiles est mince, et il est très largement constitué de récits produits par les gens qui menaient la transformation. Ce n'est pas rien à savoir avant de croire un chiffre.

Le travail de Kieran Conboy et Noel Carroll, publié dans IEEE Software en 2019, va dans le même sens depuis un autre angle. Sur 13 transformations suivies pendant quinze ans, l'un des défis majeurs identifiés est le décalage entre le framework retenu et le contexte réel de l'organisation. Le framework n'est pas mauvais, il est plaqué. Personne n'a fait le travail d'adaptation, parce que ce travail est lent, politique et invisible, alors que l'achat d'un framework est rapide, chiffrable et présentable en comité.

Comment reconnaître une agilité de façade dans votre organisation ?

Regardez ce qui se passe quand quelqu'un a une mauvaise nouvelle à annoncer. C'est le test le plus rapide que je connaisse, et il ne coûte rien. Dans une organisation réellement agile, une mauvaise nouvelle remonte vite, elle est traitée comme une information et elle change une décision. Dans une agilité de façade, elle attend le prochain comité, elle est reformulée en « point d'attention », et elle ne change rien.

Voici les signaux que je relève le plus souvent en accompagnement, et ce qu'il faudrait voir à la place.

Le dernier signal est le plus grave et c'est celui qu'on regarde le moins. Une organisation où personne ne conteste rien n'est pas une organisation alignée, c'est une organisation où l'absence de confiance empêche le conflit productif, et aucun rituel ne répare ça. Vous pouvez installer tous les tableaux du monde, si les gens n'osent pas se dire les choses, vos cérémonies ne sont que des occasions supplémentaires de ne pas se les dire.

Qu'est-ce qui change réellement quand une organisation devient agile ?

La culture de décision change, ou rien ne change. C'est le seul indicateur qui compte : qui décide, à quel niveau, à quelle vitesse, avec quelle information, et que se passe-t-il quand la décision se révèle mauvaise. Tout le reste est de l'accompagnement de ce mouvement, ou de la décoration.

Trois déplacements concrets, et ils sont inconfortables

• La décision descend. Une équipe auto-organisée décide de choses dont elle ne décidait pas avant. Cela veut dire qu'un manager en décide moins. Ce n'est pas un détail de process, c'est une redistribution de pouvoir, et personne ne l'annonce comme telle au moment de lancer la transformation.
• L'erreur devient une information. Tant qu'une hypothèse invalidée coûte politiquement à celui qui l'a portée, personne ne testera rien de risqué. On testera des choses dont on connaît déjà le résultat, et on appellera ça de l'expérimentation.
• Le désaccord devient public. L'agilité suppose que les arbitrages se posent devant l'équipe, pas dans un couloir. Cela demande de savoir traiter un désaccord sans qu'il dégénère ni ne s'enterre, ce qui est une compétence, pas un état d'esprit spontané.

Ces trois déplacements ne s'achètent pas. Ils se travaillent, lentement, et ils échouent d'abord. C'est précisément pour ça que le marché a préféré vendre autre chose : le déplacement de pouvoir ne rentre pas dans une offre de formation de deux jours.

Ce genre de bascule tient à la qualité de ce qui se dit dans la pièce. Une rétrospective utile suppose que les retours soient formulables sans mise en accusation, ce qui s'apprend, par exemple avec une structure de feedback comme le modèle OSCAR. Elle suppose aussi que les gens présents aient une raison d'être là et le droit de partir, ce que la loi des deux pieds formule mieux que n'importe quel règlement intérieur. Ce sont des compétences relationnelles, pas des cases à cocher dans un framework.

Une organisation ne devient pas agile parce qu'elle a installé des rituels. Elle installe des rituels utiles parce qu'elle a accepté de changer qui décide.

Il y a une dernière raison, plus dérangeante, pour laquelle tant de transformations agiles s'arrêtent à la façade. Une transformation imposée par le haut avec un calendrier et des indicateurs de conformité contredit dans sa forme même ce qu'elle prétend installer. On ne décrète pas l'auto-organisation. C'est toute la différence entre imposer un cadre et faire naître la confiance qui le rendrait utile, et beaucoup de directions n'ont jamais tranché cette question avant de lancer le chantier.

Pourquoi l'IA rejoue-t-elle exactement le même scénario ?

Parce que le mécanisme est identique : on achète un outillage visible pour éviter une conversation difficile sur la culture de décision. Je travaille le sujet de l'IA en organisation depuis fin 2024, en veille, en pratique et surtout en accompagnant des équipes qui la voient entrer dans leur métier. Et je vois se rejouer, presque plan par plan, ce que j'ai vu avec l'agilité depuis 2012.

Le déroulé est reconnaissable. On crée un comité IA. On achète des licences pour tout le monde. On lance un plan de formation avec un module et une attestation. On demande à chaque direction de remonter trois cas d'usage. On produit un tableau de bord du nombre d'utilisateurs actifs. Et on n'a toujours pas répondu à la seule question qui compte : qu'est-ce qu'on décide autrement, maintenant qu'on va plus vite ?

La certification Scrum de 2018 est devenue le prompt engineering de 2025

Le parallèle vaut aussi pour le marché de la formation. Il y a eu un moment où l'on recrutait sur la possession d'une certification agile plutôt que sur la capacité à faire fonctionner une équipe. Il y a eu un moment, plus court, où l'on a recruté sur la maîtrise du prompt. Dans les deux cas, l'organisation achète un signal facile à vérifier pour ne pas avoir à évaluer une compétence difficile à observer. Et dans les deux cas, le signal se dévalue en dix-huit mois pendant que le problème de fond reste entier.

C'est le même diagnostic que je pose sur les rôles produit : l'IA ne tue pas le métier de Product Manager, elle révèle ce qui, dans ce métier, n'était que de la coordination documentaire. Une équipe qui empilait les cérémonies sans confronter ses hypothèses produira désormais des documents inutiles à une cadence industrielle. Le cargo cult n'a pas disparu, il a juste un moteur plus puissant.

Par où commencer si vous voulez de l'agilité et pas des cérémonies ?

Commencez par ne rien installer de nouveau pendant un trimestre. La tentation, quand on constate que les rituels ne produisent rien, est d'en ajouter un, ou de changer de framework. C'est l'erreur classique, et elle est confirmée par les travaux de Conboy et Carroll : le problème vient rarement du framework, il vient de l'absence d'adaptation au contexte. Changer de framework sans faire ce travail revient à repeindre la piste d'atterrissage.

Quatre pas dans l'ordre

1. Faites l'inventaire de ce que vous payez. Additionnez le coût annuel réel de vos licences, de vos certifications, de vos formations et du temps passé en cérémonies. Mettez ce chiffre en face de la question du test : est-ce qu'une décision importante se prend plus vite qu'il y a trois ans ? Ce rapprochement est souvent le premier moment de lucidité d'un comité de direction.
2. Choisissez un irritant structurel et supprimez-le. Un seul, celui que les équipes citent depuis le plus longtemps et que personne n'a le mandat de traiter. Le supprimer vaut plus que dix rétrospectives, parce que c'est la preuve visible que remonter un problème sert à quelque chose.
3. Rendez le désaccord possible avant de rendre la vitesse possible. Une organisation qui ne sait pas traiter un conflit n'a pas besoin d'aller plus vite, elle a besoin de pouvoir se parler. C'est un travail de posture et de facilitation, pas d'outillage.
4. Reprenez le Manifeste et confrontez-le à votre réalité, ligne par ligne. Quatre valeurs, douze principes, une heure en comité. Pour chaque ligne, une seule question : est-ce vrai chez nous, et qu'est-ce qui prouve que c'est vrai ? L'exercice est gratuit et il est brutal.

Et l'argument de 2023 que je maintiens en 2026

Arrêtez de dépenser votre budget en certifications. Non pas parce qu'une certification serait inutile, elle donne un vocabulaire commun et ce n'est pas rien. Mais parce qu'elle ne produit aucun des trois déplacements décrits plus haut, et qu'elle vous donne l'illusion confortable de les avoir produits. Mettez cet argent dans du temps : du temps de coaching auprès des équipes réelles, du temps de comité pour trancher les arbitrages que personne ne tranche, du temps protégé pour que les équipes travaillent sur ce qu'elles ont identifié elles-mêmes.

Une dernière chose, et c'est peut-être la seule qui compte. On s'épanouit au travail. Ce n'est pas un slogan de coach, c'est une condition de performance. Une équipe qui a peur ne remonte pas les mauvaises nouvelles, et une organisation qui ne reçoit pas ses mauvaises nouvelles à temps ne peut pas s'adapter, quel que soit le nombre de sprints qu'elle enchaîne. L'agilité, si le mot doit encore vouloir dire quelque chose, c'est cela : la capacité collective à regarder la réalité en face assez tôt pour en faire quelque chose.