Transformation agile en entreprise : pourquoi elle s’essouffle (et ce que les dirigeants refusent de changer)

Votre transformation agile a démarré il y a deux ou trois ans. Il y a eu les formations, les coachs, les nouveaux rôles, les premiers sprints pleins d’énergie. Aujourd’hui, les équipes font toujours du Scrum. Les daily ont lieu, les rétrospectives aussi. Mais les décisions restent lentes, les priorités changent toutes les deux semaines et les équipes peinent à terminer ce qui compte vraiment. L’agile est partout dans le vocabulaire et presque nulle part dans les résultats.

Le 10 novembre 2026, Mike Cohn (cofondateur de la Scrum Alliance et de l’Agile Alliance, auteur de User Stories Applied) a publié sur Mountain Goat Software un texte qui circule déjà beaucoup chez les coachs : Why Agile Initiatives Lose Momentum. Son diagnostic tient en une phrase : une initiative agile cale quand l’organisation adopte les pratiques agiles sans changer les conditions qui déterminent si ces pratiques fonctionnent.

Ce sujet revient en force pour une raison simple : beaucoup d’entreprises ont fini leur « programme de transformation », ont démobilisé leurs coachs et regardent maintenant l’IA comme la prochaine vague. Avant de repeindre la façade une nouvelle fois, il vaut la peine de comprendre pourquoi la précédente n’a pas tenu. On reprend les trois causes identifiées par Cohn, les quatre changements qu’il attend des dirigeants, et on ajoute notre lecture Corporate Mavericks.

Le symptôme : l’agilité de façade

Une transformation agile qui s’essouffle ne ressemble pas à un échec. Elle ressemble à un succès figé. Les cérémonies sont tenues, les tableaux Kanban sont remplis de post-its, les rôles de Product Owner et de Scrum Master existent sur l’organigramme. Vu de loin, tout est conforme. C’est précisément ce qui rend le problème si difficile à détecter.

Mike Cohn propose un test très simple : comparer les changements visibles avec les changements opérationnels.

La colonne de gauche peut aider, mais elle ne crée pas d’agilité à elle seule. Les vraies questions sont dans la colonne de droite : les décisions se rapprochent-elles du terrain ? Sait-on qui décide quoi ? Les arbitrages sont-ils faits plus tôt et plus honnêtement ? L’organisation apprend-elle plus vite de ses utilisateurs ? Si la réponse est non, vous avez changé de méthodologie, pas de fonctionnement.

Cause n°1 : le process change, le leadership ne change pas

Le scénario est connu. L’entreprise adopte Scrum ou un autre framework agile, crée des backlogs, demande aux équipes de livrer par itérations. Mais les hypothèses profondes restent les mêmes. Les managers continuent d’attribuer le travail. Les dirigeants continuent de valider les solutions. Les équipes sont évaluées sur leur taux d’occupation. Il faut toujours une permission pour prendre des décisions qui devraient se prendre au plus près du travail.

Cohn insiste sur un point que beaucoup de comités de direction préfèrent ignorer : les dirigeants ne peuvent pas déléguer leur part de l’agilité. On demande aux équipes de devenir agiles, on nomme des Scrum Masters, on finance des formations, parfois on crée un bureau de transformation. Mais une grande partie des obstacles rencontrés par les équipes ne sont pas des obstacles d’équipe. Une équipe ne peut pas décider du nombre d’initiatives actives dans l’entreprise. Elle ne peut pas donner à son Product Owner une autorité que la direction lui refuse. Elle ne peut pas empêcher que ses membres soient éparpillés sur plusieurs projets. Elle ne peut pas changer seule le budget, les incitations ou le reporting.

L’exemple qu’il raconte est terriblement banal. Un comité exécutif soutient l’agile « en principe » : il finance le coaching, envoie les gens en formation, en parle positivement. Mais aucun dirigeant ne vient aux sprint reviews. Personne ne demande ce que les équipes ont appris des clients ni quels résultats s’améliorent. La seule question posée est : est-ce que tout le monde est occupé à 100 % ? Les équipes ont parfaitement compris le vrai message. Ce qui compte, ce n’est pas d’apprendre plus vite, c’est d’avoir l’air débordé.

La situation a changé le jour où un dirigeant a commencé à assister aux reviews de façon régulière en posant trois questions : quel problème client avons-nous traité ? Qu’avons-nous appris ? Que devons-nous faire ensuite à cause de ce que nous avons appris ? Ces questions ont modifié ce que les équipes préparaient et ce à quoi tout le monde prêtait attention.

Cause n°2 : l’agilité à l’échelle avant l’agilité tout court

Deuxième piège : l’organisation étend l’agile avant d’avoir un modèle qui fonctionne et qui mérite d’être répliqué. On forme plus d’équipes, on ajoute des tableaux et des réunions, on passe des départements entiers en itérations. Sans jamais répondre à une question plus basique : est-ce que l’agile fonctionne quelque part, ici, aujourd’hui ?

C’est souvent le moment où arrivent les grands frameworks de mise à l’échelle, le copier-coller du modèle Spotify (que Spotify lui-même n’a jamais présenté comme un modèle à reproduire) et les trains de release. Si quelques équipes ne savent pas déjà livrer régulièrement de la valeur, apprendre des retours et s’améliorer, la mise à l’échelle ne fait que répandre les mêmes problèmes plus loin. Cohn le formule ainsi : l’organisation obtient plus d’activité agile sans devenir plus agile.

Répliquer les conditions, pas les pratiques

La meilleure séquence consiste à créer quelques réussites, à comprendre pourquoi elles marchent, puis à diffuser les conditions de ce succès. Regardez vos équipes qui fonctionnent bien et posez-vous ces questions :

• Ont-elles des priorités claires ?
• Une seule personne a-t-elle la responsabilité finale des décisions produit ?
• Peuvent-elles terminer un travail important avant d’en commencer un autre ?
• Leurs managers les protègent-ils des interruptions permanentes ?
• Les décisions peuvent-elles être prises au plus près du travail ?
• Reçoivent-elles un retour utile assez tôt pour agir dessus ?

Ce sont ces conditions qui valent la peine d’être répliquées. La bonne question n’est pas « comment faire passer plus d’équipes à l’agile ? » mais « qu’est-ce qui a fait marcher l’agile pour ces équipes, et comment créer ces conditions ailleurs ? ».

Occupé n’est pas productif

Parmi ces conditions, Cohn met en avant la focalisation. Face à une livraison lente, beaucoup d’organisations réagissent en lançant davantage de chantiers. On ajoute des initiatives, on insère des demandes urgentes, on répartit les gens sur plusieurs projets pour que chaque sujet important « avance un peu ». Résultat prévisible : plus de changements de contexte, plus d’attente, plus de dépendances, plus de coordination. Tout est commencé, presque rien n’est fini. C’est exactement ce que la limitation du travail en cours, au coeur de Kanban et du lean, cherche à éviter.

Son exemple : une entreprise où presque tout le monde était affecté à trois ou quatre projets en même temps. Du point de vue de la direction, c’était efficace, personne n’était inactif. Du point de vue des équipes, c’était épuisant. Du point de vue du système, c’était un embouteillage. Nous avions décrit ce mécanisme dans notre article sur le sur-engagement des équipes, et il s’aggrave avec l’IA : quand produire du code devient presque gratuit, la tentation de tout lancer en parallèle explose, comme on l’a vu avec le paradoxe de Jevons.

Cause n°3 : personne ne tranche les décisions produit

Beaucoup de problèmes qui ressemblent à des problèmes de livraison sont en réalité des problèmes de décision produit. L’organisation a quelqu’un avec le titre de Product Owner, mais très peu d’autorité pour arbitrer. Les priorités se négocient entre managers, dirigeants, parties prenantes, architectes, commerciaux et l’auteur de la dernière demande urgente. Que beaucoup de gens donnent leur avis est sain. Le problème commence quand beaucoup de gens pensent aussi avoir le dernier mot.

Les arbitrages deviennent politiques. L’équipe construit ce qui est le plus récent, le plus bruyant ou soutenu par le sponsor le plus haut placé. Le backlog devient un entrepôt de demandes plutôt que l’expression d’une stratégie produit. Les stories sont livrées, la vélocité est comptée, les releases sortent. Mais une question devient impossible à trancher : livrons-nous les bonnes choses ?

Cohn raconte le cas d’une organisation où le rôle de Product Owner tournait entre plusieurs parties prenantes. À chaque sprint, quelqu’un d’autre était aux commandes. Les objectifs de sprint devenaient instables, les priorités bougeaient en cours de route et les équipes ont cessé de croire au plan. La direction voyait un problème de livraison. L’organisation avait un problème de responsabilité. Dès qu’un Product Owner unique a été nommé et protégé, l’équipe s’est améliorée très vite, non parce qu’elle était devenue plus intelligente, mais parce qu’elle avait enfin une direction cohérente. Si le sujet vous parle, notre analyse sur l’avenir du Product Owner face à l’IA prolonge la réflexion : quand plus personne ne peut dire non, plus personne ne possède vraiment le résultat.

Quand l’agilité rend les problèmes visibles, ce n’est pas un échec

C’est sans doute le passage le plus utile pour un comité de direction. Ces trois causes deviennent souvent plus visibles après l’adoption de l’agile. Les plans changent, les équipes remontent davantage de problèmes, les mauvaises décisions produit sont questionnées. On découvre plus tôt que les clients ne veulent pas une fonctionnalité autant qu’on le pensait. L’entreprise a l’air plus désordonnée qu’avant.

Cohn décrit une équipe de direction qui avait conclu, après quelques mois, que « l’agile ne marchait pas ». Mais l’agile n’avait rien créé. Les équipes construisaient déjà des choses dont les clients ne voulaient pas. Les priorités étaient déjà instables. Les retours arrivaient déjà avec des mois de retard, et tout le monde trouvait ça normal. L’agilité a seulement rendu ces conditions visibles plus tôt. Inconfortable, mais précieux : c’est une information qui permet d’agir pendant qu’il est encore temps.

On retrouve ici une idée que nous défendons depuis longtemps : quand une transformation cale, il est tentant d’accuser la résistance au changement des équipes. Nous avons expliqué dans notre article sur l’échec de la transformation digitale pourquoi ce diagnostic est presque toujours trop confortable pour ceux qui le posent.

Relancer une transformation agile : les 4 changements que les dirigeants doivent faire

Les organisations en meilleure santé ont aussi des problèmes, prennent aussi de mauvaises décisions et découvrent aussi que leurs plans étaient faux. La différence est dans la réponse. Elles ne confondent pas visibilité et échec, ni activité et progrès. Et elles ne demandent pas aux équipes de changer pendant que les dirigeants continuent exactement comme avant. Concrètement, Cohn identifie quatre changements de posture.

1. Participer de façon visible

Pas pour piloter le travail quotidien des équipes, mais pour ne plus rester en dehors du changement. Venir aux reviews, demander des résultats et des apprentissages, chercher les obstacles organisationnels que les équipes ne peuvent pas lever seules. Et le faire dans la durée. Quand les collaborateurs pensent que l’agile est « l’initiative du trimestre », beaucoup attendent que ça passe en gardant l’ancien fonctionnement sous le nouveau vocabulaire. Une visite isolée en sprint review se remarque. Une présence répétée change ce que les gens croient que la direction valorise.

2. Donner un vrai pouvoir de décision

L’empowerment ne se décrète pas en nommant un Product Owner. Il demande trois choses : l’autorité de prendre les décisions qu’exige le rôle, le temps de bien le tenir, et la confiance quand une décision devient inconfortable. Quand chaque décision significative remonte la hiérarchie pour validation, l’apprentissage ralentit et la responsabilité se dilue. La formule de Cohn mérite d’être affichée dans toutes les salles de comité : une responsabilité sans autorité, ce n’est pas de l’empowerment.

3. Focaliser le système

Relancer l’élan ne veut pas dire tout relancer. Réduire le nombre de priorités actives, protéger les équipes des interruptions inutiles, laisser le travail important se terminer avant d’en ajouter. Toute entreprise a plus de bonnes idées que de capacité. La question difficile n’est pas de savoir quelles idées ont de la valeur (la plupart en ont), mais lesquelles vont attendre, lesquelles vont s’arrêter, et lesquelles l’organisation accepte de ne pas faire maintenant. Prioriser vraiment ferme des portes et déçoit des gens. C’est le prix à payer pour finir quelque chose qui compte. La vitesse vient de la capacité à terminer.

4. Traiter l’agile comme un système d’apprentissage

Beaucoup de frustrations viennent du fait qu’on fait semblant d’avoir des certitudes qui n’existent pas. Les dirigeants exigent des garanties que personne ne peut honnêtement donner, les équipes répondent avec plus d’assurance qu’elles n’en ont, puis la réalité arrive et tout le monde fait mine d’être surpris. L’approche saine consiste à prendre la meilleure décision possible avec l’information disponible, tout en restant prêt à s’adapter. Quatre questions suffisent pour rendre un plan plus honnête : que savons-nous ? Qu’est-ce qui reste incertain ? Qu’espérons-nous apprendre ensuite ? Quelle fourchette de résultats est raisonnable ?

La méthode : un changement significatif à la fois

Une transformation agile qui cale n’a généralement pas besoin d’un nouveau grand déploiement, d’un rebranding ou d’un nouveau programme de transformation. Elle a besoin qu’on s’attaque aux contraintes que les équipes ne peuvent pas lever seules. La démarche proposée par Cohn est d’une simplicité désarmante, ce qui la rend difficile à appliquer pour les organisations habituées aux plans à dix chantiers :

1. Identifier la contrainte qui génère le plus de retard, de perturbation ou de confusion.
2. Choisir un changement significatif qu’un dirigeant peut faire lui-même.
3. Faire ce changement, au lieu d’annoncer un « soutien renouvelé ».
4. Observer si le flux, l’apprentissage ou la livraison s’améliorent.
5. Recommencer avec la contrainte suivante.

Ce changement peut consister à donner au Product Owner l’autorité sur une décision qui exige aujourd’hui une escalade. À arrêter une initiative moins prioritaire pour que l’important se termine. À supprimer un obstacle organisationnel que les équipes remontent depuis des mois en rétrospective. Bref, de l’amélioration continue appliquée à l’organisation elle-même, et pas seulement aux équipes.

Notre lecture sans bullshit

Le texte de Mike Cohn est solide, et on le partage largement. Trois remarques pour le lire avec du recul.

• Ce sont des retours d’expérience, pas une étude. Les exemples sont anonymes et non chiffrés. Ils sonneront juste pour quiconque a vécu une transformation agile, mais ils ne prouvent rien statistiquement. À vous de vérifier dans votre propre environnement, avec vos propres données de flux (délai de livraison, travail en cours, taux de changement de priorités en cours de sprint).
• L’auteur vend aussi un atelier pour dirigeants. Ça n’invalide pas le propos, mais ça explique l’angle : tout ramène au leadership. C’est souvent vrai. Ce n’est pas toujours suffisant : un système d’information rigide, des contrats au forfait ou une architecture monolithique peuvent aussi tuer l’agilité, quelle que soit la bonne volonté de la direction.
• Le vrai sujet, c’est l’organisation, pas la méthode agile. Scrum, Kanban, SAFe ou le prochain framework à la mode ne changent rien si la structure de décision reste identique. C’est la leçon de l’approche sociotechnique : une bonne pratique meurt dans une mauvaise organisation. Et c’est encore plus vrai à l’heure où les entreprises veulent intégrer des agents IA dans leurs équipes sans avoir réglé qui décide de quoi.

Si l’on devait résumer l’article en une phrase à glisser dans votre prochain comité de direction : les initiatives agiles calent rarement parce que les équipes ont oublié comment tenir un daily. Elles calent parce que l’entreprise a cessé de changer les conditions qui avaient rendu l’agilité nécessaire. Avant de demander aux équipes de changer davantage, les dirigeants doivent regarder lesquels de leurs propres comportements doivent changer ensuite. C’est là que commence l’agilité.

FAQ : transformation agile en entreprise

Sources : Mike Cohn, Why Agile Initiatives Lose Momentum, and How to Get Them Moving Again, Mountain Goat Software, 10 novembre 2026 (citations et exemples traduits par Corporate Mavericks) ; Manifeste pour le développement agile de logiciels, 2001.