Pourquoi les transformations agiles échouent vraiment

# Pourquoi les transformations agiles échouent vraiment

La transformation agile a été lancée il y a deux ans. Grand programme, cabinet de conseil, formations en cascade, nouveaux rôles partout.

Aujourd’hui, les dailys ont lieu. Les backlogs existent. Le vocabulaire a changé.

Et rien d’autre. Les décisions remontent toujours aux mêmes endroits. Les délais glissent pareil. Les gens sont fatigués, avec en prime le sentiment d’avoir joué une pièce de théâtre pendant deux ans.

Cette scène se rejoue dans les boîtes, partout, avec des variantes. La question n’est pas de savoir si les transformations agiles échouent souvent. Elles échouent souvent. La question est : pourquoi, exactement ? Parce que le diagnostic habituel, « on a mal appliqué la méthode », est faux. Et tant qu’il tient, on recommence la même erreur avec un framework différent.

Ce que disent les chiffres, et comment les lire

Une transformation agile échoue rarement avec fracas. Elle échoue en silence : les rituels s’installent, le vocabulaire change, mais les décisions, le rapport à l’erreur et les résultats restent identiques. L’organisation a payé pour bouger et n’a pas bougé. C’est cette forme d’échec, l’échec invisible, qui domine largement.

Sur l’ampleur du phénomène, deux repères chiffrés. À manier avec précaution.

Le chiffre des 70% mérite une mise en garde honnête. Il circule depuis trente ans, sa méthodologie est débattue, et « échouer » ne veut pas dire la même chose selon les études. Prenez-le pour ce qu’il est : un ordre de grandeur, pas une loi physique. Mais l’ordre de grandeur, lui, tient. Personne de sérieux ne prétend que la majorité des transformations réussissent.

Le chiffre Gallup dit autre chose. Une transformation agile est censée redonner de la prise aux équipes : décider plus près du terrain, apprendre de ses erreurs, retrouver du sens. Si l’engagement plafonne à 8% en France, c’est que ces promesses n’arrivent pas jusqu’aux gens. Des années de transformations, et les équipes regardent toujours le train passer.

Deux chiffres, un même signal : le problème n’est pas le volume d’efforts. C’est leur direction.

Cause n°1 : on forme la base, jamais le sommet

Le scénario classique d’une transformation agile : on forme les équipes. Massivement. Développeurs, chefs de projet, opérationnels. Des vagues entières passent en formation, reviennent avec du vocabulaire et de l’envie.

Et en haut ? Rien. Le comité de direction a validé le budget. Il a parfois assisté à une présentation de deux heures. Il considère que la transformation, c’est pour les équipes. Lui, il pilote.

C’est là que tout se joue. Et que tout casse.

Parce que l’agilité, au fond, redistribue la décision. Elle demande que les gens proches du problème décident, que l’erreur devienne une information, que le plan s’ajuste au réel. Or qui tient la décision, la sanction de l’erreur et le culte du plan ? Le sommet.

Une équipe formée revient avec l’envie de faire autrement. Elle propose de livrer petit : on lui répond engagement annuel. Elle assume une erreur en rétrospective : l’erreur ressort en entretien de fin d’année. Elle veut décider : la décision est déjà prise deux étages au-dessus.

L’équipe comprend vite. Elle garde les rituels, abandonne le reste. Le théâtre commence.

On ne peut pas demander à la base d’être agile dans un système que le sommet garde rigide. C’est l’objet d’un article entier : l’agilité commence au CODIR. Une organisation ne devient jamais plus agile que ses dirigeants. Pas par mauvaise volonté des équipes. Par simple rapport de forces : c’est le sommet qui fixe les règles du jeu, et personne ne joue contre les règles très longtemps.

Cause n°2 : on achète une méthode au lieu de poser une question

Deuxième cause, plus discrète : la transformation démarre par une réponse.

« On passe à l’agile. » « On déploie tel framework. » « On installe tel modèle d’organisation. » La solution est choisie avant que le problème soit posé. Souvent parce qu’un concurrent l’a fait, qu’un cabinet l’a vendue, ou qu’il fallait annoncer quelque chose.

Personne n’a répondu à la question d’avant : qu’est-ce qui nous empêche, aujourd’hui, de faire du bon travail ?

Cette question fait peur. Parce que ses réponses sont inconfortables. Les décisions remontent trop haut. Les silos se protègent. L’erreur se paie. Les priorités changent chaque semaine parce que le sommet n’arbitre pas. Aucune de ces réponses ne s’achète sur catalogue.

Une méthode, si. Une méthode a un prix, un planning, un livrable. Elle se présente en comité, elle rassure, elle occupe. Acheter une méthode, c’est transformer une question angoissante en projet gérable.

Sauf que la méthode plaquée sur un problème non posé produit un résultat connu : elle habille l’existant. Les sprints recouvrent le cycle en V. Le Product Owner recouvre le chef de projet. Le vocabulaire change, la structure de décision reste. Au bout de dix-huit mois, on constate que « l’agile ne marche pas ici ». L’agile n’a jamais été essayé. On a essayé un déguisement.

Cause n°3 : on mesure le faire, jamais l’être

Troisième cause : le pilotage. Une transformation agile se pilote avec des indicateurs. Et on choisit toujours les mêmes : nombre d’équipes « passées à l’agile », nombre de personnes formées, nombre de cérémonies en place, taux de couverture des rôles.

Tous ces indicateurs mesurent le faire. Est-ce que les rituels tournent. Est-ce que les cases sont cochées.

Aucun ne mesure l’être. Est-ce que les décisions se prennent plus près du terrain qu’avant ? Est-ce qu’une erreur avouée coûte moins cher qu’une erreur cachée ? Est-ce qu’une équipe peut dire non à une demande absurde ? Est-ce qu’un plan a été changé récemment parce que le réel l’exigeait ?

Ces questions-là mesurent la transformation réelle. Elles sont plus dures à chiffrer, alors on ne les pose pas. Et ce qu’on ne mesure pas n’existe pas aux yeux d’un comité de pilotage.

Résultat mécanique : l’organisation optimise ce qu’on mesure. Les équipes font tourner les rituels, remplissent les outils, affichent les indicateurs verts. Le faire progresse, l’être stagne. Sur le papier, la transformation avance. Sur le terrain, rien.

C’est la différence entre être agile et faire agile, appliquée à l’échelle d’une organisation entière. Une transformation qui ne mesure que le faire obtient du faire. Du théâtre bien documenté.

Les faux coupables qu’on accuse à la place

Quand la transformation patine, il faut un coupable. Le diagnostic officiel désigne toujours les mêmes. Toujours à tort.

« La résistance au changement. » Le grand classique. Les équipes résisteraient par confort ou par peur. Sur le terrain, c’est presque toujours faux. Les gens ne résistent pas au changement. Ils résistent à l’incohérence : on leur demande d’être autonomes dans un système qui punit l’autonomie. Leur prudence n’est pas de la résistance. C’est de la lucidité.

« On a mal appliqué la méthode. » Donc il faudrait plus de conformité, plus de coachs, plus de rigueur dans les rituels. C’est prendre le problème à l’envers : plus de conformité à une méthode plaquée aggrave le théâtre, elle ne le soigne pas.

« Il faut plus de temps. » Parfois vrai. Souvent un alibi. Une transformation qui n’a rien changé aux décisions en deux ans ne changera rien en quatre. Le temps ne transforme pas un système. Il l’use.

Ces trois faux coupables ont un point commun : ils protègent le sommet du diagnostic. Tant que la faute vient d’en bas, rien n’oblige à regarder en haut.

Par où recommencer

Si votre transformation agile a échoué, ou patine, la tentation est de tout jeter. Mauvaise idée : les équipes ont déjà payé le prix du premier essai. Un deuxième grand programme les achèverait. Si des équipes sont sorties abîmées du premier round, il y a un travail spécifique à faire, que je décris dans réparer une équipe après une transformation agile ratée.

Pour le reste, trois déplacements. Pas un programme. Des déplacements.

Commencer par le sommet. Pas une présentation de deux heures : un vrai travail du CODIR et des managers sur leur propre rapport au contrôle, à l’erreur, à l’incertitude. Tant que ceux qui tiennent les règles du jeu n’ont pas bougé, former le reste ne sert qu’à fabriquer de la frustration.

Poser la question avant la réponse. Qu’est-ce qui nous empêche de faire du bon travail ? Prendre le temps d’y répondre collectivement, avec les gens du terrain. La réponse dessinera le dispositif. Parfois ce sera de l’agilité. Parfois ce sera juste trois décisions courageuses qu’on repousse depuis des années.

Mesurer l’être. Choisir deux ou trois questions qui touchent le réel : où se prennent les décisions, ce que coûte une erreur avouée, ce qu’on a appris ce trimestre. Et les suivre avec la même rigueur qu’un budget.

Sur la partie formation, la logique est la même : petit, honnête, posture d’abord. C’est le parti pris de la formation agile Insuffle Académie : une journée sur les fondamentaux, qui commence par le rapport à l’incertitude et assume de planter une graine plutôt que de promettre une transformation. Et avant d’acheter quoi que ce soit, le guide formation agile : comment choisir sans se faire avoir vous aidera à trier le marché.

Les transformations agiles n’échouent pas parce que l’agilité est une mauvaise idée. Elles échouent parce qu’on a voulu l’installer comme un logiciel, sur un système d’exploitation qui n’a pas changé. Changez le système d’exploitation. Le reste suivra.

Découvrir la formation agile Insuffle Académie