Retour d'expérience, ce que j'ai vu réussir et échouer en première ligne

Article

Introduction

Je lis encore des études de cabinet qui promettent que 87 % des organisations qui implémentent SAFe atteignent un gain de 35 % en vélocité en dix-huit mois. Je lis aussi des billets tranchants qui disent que l'agilité à l'échelle est un mythe coûteux et qu'on ferait mieux de rester en Scrum pur. Les deux vous mentent. L'un par optimisme de commande, l'autre par cynisme.

Ce qui manque dans le débat public, ce sont les histoires vraies. Pas triomphales, pas catastrophiques. Justes, réalistes, pétries des détails qui font basculer une transformation.

Je pilote ou j'observe des trains depuis une dizaine d'années, sur une quinzaine de contextes différents. J'ai vu des trains réussir brillamment, d'autres s'étioler sans qu'on sache vraiment pourquoi, d'autres encore qui ont détruit autant de valeur qu'ils en ont créée. Et dans chaque cas, ce qui décide, ce ne sont jamais les raisons qu'on croit. Ce sont des patterns récurrents, imprédits par les frameworks, mais observables par le terrain. Je partage ce que j'ai retenu.

Un grand compte industriel, les leçons structurantes d'un engagement de grande échelle

Sur l'un des engagements les plus exigeants de mon parcours, j'ai accompagné un train SAFe structuré autour de plusieurs équipes, environ soixante personnes à plein régime. L'organisation comptait 13 à 15 trains à l'échelle du domaine, ce qui posait à la fois la complexité interne d'un train et la complexité inter-trains d'un système plus large.

Ce qui a marché, c'est ce dont vous entendez peu parler. D'abord, la discipline implacable sur le périmètre. Nous avons décidé que ce train servait un scope précis et durable. Pendant dix-huit mois, ce périmètre a failli être ouvert cent fois. Chaque fois, on a dit non. Pas avec agressivité, mais avec clarté. Cette discipline a forcé une vision du train. C'est le vrai gain.

Ensuite, un sponsor engagé réellement. Pas un titre, une présence. Ce directeur venait au planning, pouvait répondre à une question en moins de deux heures, arbitrait sans tout faire remonter. Ce pattern, je l'ai vu partout depuis, c'est le plus corrélé au succès.

Enfin, nous avons accepté dès le PI 1 que la première année prendrait du temps. Pas en termes de delivery date, en termes de stabilité du système. Les trois premiers PI ont été chaotiques. Les dépendances explosaient. Les équipes se sentaient perdues. Au lieu de réorganiser ou de changer de cadre, nous avons dit attendre, laisser les retours arriver, ajuster chaque rétro. Au PI 4, le train volait.

L'évaluation finale, 4.1/5 en satisfaction interne, 100 % compliance sur les audits SAFe, 1ère place du classement interne sur 13 à 15 trains observés sur un grand compte industriel. Je ne le mentionne pas pour la vanité. La leçon que j'en retiens est différente. Pas d'éclairs. De la discipline de fond. Et du temps raisonnable.

Ce qui me marque rétrospectivement, c'est ce que j'ai échoué à améliorer. Les dépendances inter-trains. Les inter-dépendances entre les trains du domaine étaient la vraie complexité, pas l'agile intra-train. Et je n'ai pas su monter en généralisation, je suis resté dans le périmètre d'un seul train. C'est le rappel que la maîtrise de votre train n'est jamais suffisante en grande organisation. Le système autour vous rattrape.

Pattern, trois mois de patience pour deux ans de fluidité

Cas anonymisé, un grand groupe industriel français dans le secteur de l'énergie, culture classique, hiérarchique.

Première année, lancement d'un train SAFe sur un nouveau domaine métier, gestion prédictive d'assets critiques. Soixante-dix personnes, sept équipes, PM issu de la direction métier, RTE nommé à partir d'un manager projet classique.

Les trois premiers mois ont été terribles. Je parle technique et humain. L'équipe technique attendait des spécifications waterfall. Elle les recevait brutes et inachevées. Les équipes métier attendaient la livraison chaque deux semaines. Elles recevaient des prototypes qui changeaient de direction à chaque sprint. Le sponsor s'inquiétait. Les escalades quotidiennes. Les gens regardaient vers la direction, "c'est quoi ce bordel, pourquoi on a un Scrum Master".

La direction a voulu arrêter ou réorganiser. Je me souviens d'une conversation avec le CIO, "c'est le chaos, je pensais que vous maîtrisiez SAFe". Ma réponse, "je maîtrise le chaos organisé. Ce qu'on voit c'est que le système prend connaissance de ses limites. Donnez-moi trois PI supplémentaires."

Contre toute attente, il a dit oui. Entre le PI 2 et le PI 4, j'ai fait trois choses sans spectaculaire. D'abord, réduit les escalades à trois vraies décisions par sprint au lieu de dix fausses. Le RTE s'est armé d'une grille d'arbitrage simple, légalement pas trop grave, techniquement soutenable, métier aligné, oui on fait, non on refuse ou on replanifie. Deuxièmement, introduit une pré-cérémonie de PI Planning le mercredi pour déboguer les dépendances avant la vraie session jeudi. Troisièmement, tiré un dashboard très simple, dépendances ouvertes, arbitrages en attente, burndown.

Au PI 4, le train s'est stabilisé. À partir du PI 5, il a volé. Douze mois après, le système livrait avec une fiabilité qui n'avait jamais existé chez ce groupe auparavant. Pas à cause de SAFe. À cause de la patience.

La leçon, c'est celle-ci. Si votre organisation n'a jamais vu la fluidité de court cycle, elle doit passer par une phase de recalibrage brutal. Elle dure environ trois mois. Votre instinct est de l'arrêter. C'est l'inverse qu'il faut faire. Prolonger, jusqu'à ce que les boucles de feedback de court cycle créent une nouvelle mémoire organisationnelle.

Pattern, le train qui s'épuise faute de sponsor

Cas anonymisé, un éditeur logiciel, scale-up consolidée, deux cents personnes, cinq trains SAFe lancés en parallèle.

Le train trois, en charge d'un nouveau segment client (PME administratives), sponsorisé par un VP Product fondateur. Le lancement a été exemplaire. PM affamée, équipe technique solide, RTE compétent, charge de travail calibrée.

PI 1 et PI 2, victoires. Livraisons à la date. Clients heureux. Les réunions de synchro tournaient seules. Puis le fondateur VP a absorbé un rôle supplémentaire, expansion internationale. Il fallait le sponsor. Il n'était plus disponible une journée par mois, il l'était trois heures tous les quinze jours. Les notes de réunion s'accumulaient, les décisions attendaient deux semaines au lieu de deux heures.

Au PI 4, j'ai noté une fatigue diffuse. Les escalades n'étaient plus tranchées, elles traînaient. Les arbitrages métier partaient en comité. Les rétros demeuraient vagues. Au PI 6, j'ai dit au RTE, "vous n'avez plus de sponsor". Il a dit "si si, il valide tout". Je lui ai répondu "il valide, mais il n'est pas présent. Ce n'est pas la même chose."

Au PI 7, le train s'est mécaniquement effondré. Pas dramatiquement. Juste une lente usure. Les gens ne savaient plus bien pour qui ils travaillaient. Les priorités changeaient sans logique visible. Les bons éléments ont commencé à regarder ailleurs. Trois mois après, le train était plus mort qu'il ne semblait.

Ce que j'ai retenu, c'est que le sponsor n'est pas un titre. Le sponsor absent, c'est une équipe qui glisse vers un travail de Sisyphe. Elle peut tenir six mois si elle y croit. Après, elle calcule que son effort ne crée pas de sens et elle lâche prise.

Corollaire, une équipe abandonnée est pire qu'une équipe jamais lancée.

Pattern, le coach qui sauve trop vite

Cas anonymisé, une banque mutualiste, quatre-vingt-dix personnes, trois trains SAFe lancés sur une plateforme de gestion de portefeuille client.

Situation de départ, agile résiduelle, Scrum sur le papier, culture waterfall très présente, un système informatique très complexe, beaucoup de dette.

La direction a recruté un coach très bien crédibilisé, agile depuis quinze ans, coach de coachs. Il arrive. Le jour 1, il voit le chaos. Le jour 6, il a redessiné l'organigramme, imposé une séparation en trois trains, recruté deux RTE en embauchant de l'externe (des proches). Il a remis un cadre hyperstructuré sur les rituels. Il a gueulé sur la technique et imposé une refonte. Il a mis du contrôle partout.

Six semaines, le système était redéployé. Beau à voir. Slides brillantes. Tout le monde parlait de sa rigueur.

Trois mois après son départ (naturel, fin de mission), rien n'avait pris racine. Le système revenait à son état précédent. Les RTE qu'il avait recrutés n'avaient pas été adoptés par l'organisation. L'hyperstructure qu'il avait imposée avait été contournée. Les gens avaient appris à vérifier que les boîtes étaient cochées, pas à en respecter l'esprit. Les deux RTE externes s'ennuyaient et sont partis.

Ce que j'en retiens, c'est l'anti-héroïsme structurel. Le coach qui sauve le jour est séduisant. Mais il crée une dépendance personnelle. Si le coach ne revient pas en renforcement pendant un an, tout s'érode. Le vrai coach n'est pas le sauveur qui vient régler ça en trois semaines. C'est celui qui rend les gens capables de faire sans lui.

La banque mutualiste a dû recommencer un an plus tard avec une approche plus lente, plus tâtonnante, plus chère en consultant-mois mais qui a vraiment tenu.

Pattern, l'IA qui devient prétexte à différer

Cas anonymisé, grande administration de l'État, structure complexe, prise de décision très centralisée.

Contexte, une équipe produit lance une transformation agile. PI 1 et PI 2, ça marche moyennement. Les décisions métier traînent. Les priorités bougent de façon imprévisible.

Puis au comité de gouvernance Q3, quelqu'un dit "et si on intégrait l'IA pour mieux prédire les priorités". Concept séduisant. Intellectuellement intéressant. Techniquement pertinent.

Mais ce qui s'est passé dans les quatre mois suivants, c'est un débat sans fin sur comment structurer l'IA, quels étaient les garde-fous, comment s'assurer qu'elle ne se trompait pas, comment former les gens. Un bon sujet. Sauf que pendant ces quatre mois, les vraies décisions métier, qui auraient pu être tranchées en une réunion, restaient bloquées en attente de la solution IA.

C'était l'IA comme prétexte à différer. Ce n'était jamais dit comme ça. Mais observé à la surface, c'était transparent.

Quand j'ai pointé ça au comité, j'ai dit, "en quatre mois vous pouvez avoir 70 % de la solution IA. Ou vous pouvez trancher les trois vraies décisions métier qui bloquent le train. Je recommande les décisions." Ça a sonné brutalement. Mais ça a débloqué la situation.

La leçon, l'IA ne doit pas devenir une excuse pour ne pas arbitrer. Si vous lancez un train et que vous différez les décisions en attendant l'IA, l'IA devient un parasite, pas un outil.

Ce que ces patterns ont en commun

Cinq cas différents, cinq contextes, cinq organisations. Mais je retrouve quatre traits qui reviennent dans les transformations qui tiennent face à celles qui s'érodent.

Premier trait, la patience structurée. Les transformations qui marchent sont celles qui acceptent une phase de chaos organisé au démarrage. Pas comme une faiblesse qu'on excuse. Comme une étape prévisible. Et celles qui y plongent vraiment, trois PI minimum, en acceptant un ralentissement temporaire, en revanche émergent avec un système qui s'auto-corrige après. Celles qui résistent en disant non, on ne va pas dans cette phase bruyante, restent coincées.

Deuxième trait, le sponsor présent, pas absent. Investi. Disponible. Capable de trancher. C'est le trait le plus corrélé au succès. Et c'est celui que la plupart des organisations négligent en faveur de bonnes pratiques SAFe par ailleurs.

Troisième trait, anti-héroïsme assumé. Les transformations qui tiennent ne sont jamais sauvées par quelqu'un. Elles sont construites par un collectif qui apprend. Celui qui joue le sauveur en trois semaines crée une illusion qui vaut trois mois. Celui qui dit voilà, c'est notre travail collectif, ça prend du temps, finit avec quelque chose de vrai.

Quatrième trait, lisibilité du système. Les équipes qui savent pour qui elles travaillent, quelles sont les vraies décisions, comment ça va s'améliorer, restent engagées. Les équipes qui sentent que le système s'est fermé sur lui-même, que les décisions viennent de nulle part, que personne n'a le pouvoir, glissent vers l'apathie.

En réalité, ces quatre traits ne sont pas des choix méthodologiques. Ce sont des choix systémiques. Ils disent comment l'organisation choisit de fonctionner. Et cela ramène à la pillar sur les systèmes et organisations. Le framework n'en est que l'habillage.

En conclusion

Ce qu'on raconte moins, ce sont les histoires qui n'ont pas de dénouement spectaculaire. Des trains qui vivent, qui s'améliorent, qui livrent en stabilité, pas parce que quelqu'un a été héroïque, mais parce qu'une organisation a décidé de se discipliner et d'apprendre.

Je crois qu'honnêtement, c'est plus utile qu'un cas d'école.

L'intervalle entre la promesse du consultant ("35 % de gain en dix-huit mois") et la réalité ("vous allez découvrir comment vous travaillez vraiment, ça va vous secouer, puis vous allez vous recalibrer"), c'est ce fossé que personne ne raconte.

Et c'est là que le retour d'expérience honnête et brut, avec ses ratés et ses victoires, devient un outil plus utile que tout ce qu'on peut télécharger.

Voilà ce que je transmets aux équipes, pas des promesses de transformation, des traces de ce qu'on a vu se produire quand on essaie.

Si vous êtes dans un lancement de train et que vous sentez du chaos au PI 2, ce n'est pas un signal d'arrêt. C'est un signal que le système se confronte à lui-même. Restez dedans. Pour aller plus loin, je propose deux accompagnements. L'un sur diagnostic et arbitrage, si vous êtes dans une transformation qui s'enlise et que vous cherchez les leviers. L'autre, une intervention directe sur un train en difficulté, trois à cinq jours où on regarde ensemble ce qui se passe et comment recalibrer.

Pour aller plus loin

Cinq articles connexes à venir, placeholders à brancher en MDX :

• Trois mois de chaos, signe d'une bonne adaptation plutôt que d'une mauvaise implémentation.
• Le sponsor engagé, ce que faire vraiment de l'arbitrage veut dire.
• Anti-patterns de coaching en transformation, quand l'expert détruit plus qu'il ne construit.
• Lisibilité du système, comment les équipes savent où elles vont.
• Lecture en boucle fermée, quand la décision métier crée une attente éternelle.

Renvois croisés pillars KLA :

• Pillar 1, Agilité à l'échelle, les signaux faibles d'un train qui déraille.
• Pillar 2, Leadership produit, le rôle du sponsor et du PM dans les arbitrages structurants.
• Pillar 3, IA appliquée au métier, l'IA comme outil ou comme prétexte.
• Pillar 4, Systèmes et organisations, patience organisationnelle et bifurcations critiques.