Qu’est-ce que SAFe (Scaled Agile Framework) ? La réponse compliquée à un problème complexe

Une entreprise veut devenir agile. Quarante équipes, six produits, et personne ne sait qui décide quoi. Un cabinet arrive avec SAFe. Dix-huit mois plus tard, il y a un nouveau vocabulaire, six nouveaux rôles, un grand raout de planification tous les trimestres, un budget de certification conséquent, et exactement la même lenteur qu’avant. Les équipes ont appris à dire feature au lieu de fonctionnalité. Voilà le paradoxe de SAFe. Un cadre censé apporter l’agilité, qui applique à un problème complexe les outils du compliqué, et qui reconstruit patiemment ce que l’agilité voulait démonter.

SAFe, c’est quoi exactement

SAFe, pour Scaled Agile Framework, est un cadre méthodologique propriétaire créé par Dean Leffingwell et édité par la société Scaled Agile. Son objectif affiché : permettre à de grandes organisations d’appliquer les principes agiles au-delà de l’équipe unique, là où Scrum s’arrête.

Le constat de départ est juste. Scrum fonctionne bien pour une équipe de sept personnes. Quand une entreprise fait travailler quarante équipes sur un même produit, avec des dépendances techniques, des contraintes réglementaires et un budget annuel à tenir, Scrum seul ne dit rien. SAFe prétend combler ce vide.

Sa brique centrale porte un nom qui mérite qu’on s’y attarde plus loin : l’Agile Release Train, littéralement le train de livraison agile. Il regroupe généralement plusieurs équipes, soit un ensemble de plusieurs dizaines de personnes, synchronisées sur une cadence commune.

Toutes les huit à douze semaines, ces équipes se réunissent pendant deux jours pour le PI Planning. Cet événement est le cœur battant du dispositif. On y planifie collectivement l’incrément à venir, on identifie les dépendances entre équipes, on formule des objectifs, et chaque équipe vote sa confiance dans le plan produit. Un Release Train Engineer, le RTE, en assure la facilitation, la logistique et le déroulé.

Autour de cette brique, le cadre empile des rôles et des niveaux. Product Management, System Architect, Business Owners, Epic Owners, Solution Train Engineer pour coordonner plusieurs trains entre eux, puis toute une couche de gestion de portefeuille. Quatre configurations existent, de la version dite essentielle à la version complète, selon la taille de l’organisation.

L’ensemble s’accompagne d’un vocabulaire dense, d’un site de référence détaillé, et d’un système de certifications payantes à plusieurs niveaux, du praticien au consultant habilité à déployer le cadre chez les clients.

Sur le papier, tout cela est cohérent, documenté, professionnel. C’est précisément là que le problème commence.

Le vocabulaire, premier symptôme

Avant d’entrer dans le fond, arrêtons-nous sur un détail qui n’en est pas un. Pour utiliser SAFe, il faut apprendre une langue.

Un ART regroupe des équipes. Un PI est un incrément de programme. Les Epics se découpent en Features, qui se découpent en User Stories. Certaines Features sont des Enablers, c’est-à-dire du travail technique qui ne produit pas de valeur visible. La priorisation utilise le WSJF, une formule de calcul du coût du retard. Entre deux incréments s’intercale une itération dite d’innovation et de planification. À la fin de chaque cycle a lieu un atelier Inspect and Adapt. Le portefeuille est piloté par le Lean Portfolio Management.

Aucun de ces termes n’est absurde pris isolément. Mis bout à bout, ils produisent un effet redoutable : pour discuter du travail, il faut d’abord maîtriser le cadre. Les personnes formées et certifiées parlent une langue que les autres ne parlent pas. Une hiérarchie de la compréhension s’installe, qui recoupe étrangement la hiérarchie des rôles.

Le Manifeste Agile tient en quatre valeurs et douze principes, sur une page. SAFe demande plusieurs jours de formation avant de commencer. Cet écart n’est pas un détail d’implémentation. Il dit quelque chose de la nature réelle du dispositif.

Un cadre qui grossit à chaque version

L’histoire du framework est instructive, parce qu’elle suit une trajectoire connue de tous ceux qui ont vu vieillir un référentiel d’entreprise.

À l’origine, la proposition est relativement contenue : synchroniser plusieurs équipes agiles sur une cadence commune. Puis les versions successives ajoutent. Une couche pour les très grandes solutions. Une couche pour le portefeuille et le financement. Des rôles pour articuler ces couches entre elles. Des pratiques de gestion lean pour piloter le tout. Une configuration complète pour les organisations qui veulent l’ensemble.

Chaque ajout se justifie individuellement. Un client rencontre une difficulté, le cadre y répond par un nouvel élément. C’est la logique d’un produit qui écoute son marché. Sauf qu’appliquée à une méthode censée alléger le travail, cette logique produit mécaniquement l’inverse de son intention initiale.

La version 6 fournit une illustration presque comique de cette dynamique. L’éditeur y renomme le Program Increment en Planning Interval, un changement de vocabulaire qui a semé la confusion chez les praticiens sans rien modifier au fond du dispositif. Des équipes entières ont dû réapprendre à nommer ce qu’elles faisaient déjà.

Quand un cadre censé produire de l’adaptation consacre son énergie à rebaptiser ses propres artefacts, la question n’est plus de savoir comment mieux l’appliquer. Elle est de savoir ce que l’on cherchait à résoudre au départ.

L’erreur de diagnostic, au fondement de tout le reste

Voici le cœur du problème, et il est théorique avant d’être pratique.

Coordonner quarante équipes qui construisent un produit vivant, avec des clients qui changent d’avis, des concurrents qui bougent et des technologies qui évoluent, c’est un problème complexe. Complexe a un sens précis, formalisé notamment par le cadre Cynefin de Cynthia Kurtz et Dave Snowden en 2003 : la relation entre cause et effet n’y est cohérente qu’en rétrospective et ne se répète pas. Vous comprenez pourquoi une décision a fonctionné après coup, et refaire la même chose l’année suivante ne donnera pas le même résultat.

Face à un problème complexe, la conduite qui marche consiste à sonder, observer, puis répondre. On lance des expériences peu coûteuses, on regarde ce qui prend, on amplifie ce qui fonctionne, on abandonne le reste. Le plan émerge de l’action.

SAFe traite ce problème comme s’il était compliqué. Compliqué veut dire nombreux mais prévisible : beaucoup de pièces en interaction, des règles stables, une bonne réponse à trouver par l’analyse. Un moteur d’avion est compliqué. Une déclaration fiscale est compliquée. Face au compliqué, la bonne conduite consiste à analyser, découper, planifier, synchroniser, et nommer des experts responsables de la coordination.

Relisez la liste. C’est exactement le programme de SAFe.

Le résultat était donc écrit d’avance, et il ne dit rien de la qualité des gens qui l’appliquent. Quand on répond au complexe par de la complication, on n’obtient pas de la clarté. On obtient une organisation plus lourde, plus chère, plus lente, avec le même brouillard qu’avant. La complication n’a jamais absorbé la complexité. Elle s’y ajoute.

William Ross Ashby a formulé en 1956 une loi qui éclaire ce point : seule la variété peut absorber la variété. Pour faire face à un environnement riche en surprises, un système a besoin d’un répertoire de réponses au moins aussi riche. SAFe fait l’inverse. Il réduit la variété des réponses possibles en les canalisant dans un processus unique, standardisé, cadencé. Il diminue précisément la capacité qu’il prétendait augmenter.

C’est ce piège que doit éviter toute transformation sérieuse, et c’est le plus difficile à faire entendre à une direction, parce que la complication a une qualité imbattable : elle est visible. Elle se montre en comité, elle se présente en slides, elle rassure.

Le train, une métaphore qui trahit tout

Le choix du mot train mérite un examen attentif, parce qu’il en dit plus long que n’importe quelle critique extérieure.

Un train ne s’adapte pas. C’est sa définition même. Sa voie est posée dans le sol, souvent depuis des décennies. Son horaire est fixé longtemps à l’avance. Son terminus est décidé avant que le premier voyageur ne monte. Il ne peut pas bifurquer parce qu’un passager a eu une meilleure idée en cours de route, ni s’arrêter dans une ville qui n’était pas prévue parce que le marché s’y est ouvert.

Ces contraintes ne sont pas des défauts. Pour transporter des gens en masse, en sécurité, à l’heure, ce sont exactement les bonnes propriétés. Le rail est un chef-d’œuvre d’ingénierie du compliqué. La régularité y est une vertu cardinale.

Pour construire un produit dans l’incertitude, ces mêmes propriétés deviennent des handicaps. Vous ne voulez pas garantir que vous arriverez à la destination prévue il y a trois mois. Vous voulez pouvoir changer de destination quand vous découvrez que la première ne valait rien.

L’ironie va plus loin, et elle est savoureuse pour qui connaît le ferroviaire. Le secteur travaille avec un plan de transport, et lorsque les conditions l’imposent, il bascule sur un plan de transport adapté. Neige, panne, mouvement social, incident sur la voie : le plan initial est remplacé par un autre, conçu pour la situation réelle. Le rail, ce symbole de rigidité, assume donc de modifier son plan quand la réalité change.

Un train agile, lui, verrouille ses objectifs pour dix à douze semaines. Le ferroviaire réel est plus adaptatif que la métaphore censée illustrer l’agilité.

Le Manifeste Agile, en 2001, énonce quatre valeurs. La quatrième dit de préférer l’adaptation au changement plutôt que le suivi d’un plan. SAFe organise un événement de deux jours mobilisant des dizaines de personnes pour produire un plan de trois mois, avec vote de confiance à la clé. Il ne s’agit pas d’une dérive d’application. Il s’agit du fonctionnement nominal du cadre.

Ce que dit le Manifeste, ce que fait SAFe

Valeur 1. Les individus et leurs interactions, plus que les processus et les outils. Ce que SAFe installe : une dizaine de rôles normés, des dizaines d’artefacts, et un référentiel complet à apprendre avant de pouvoir participer utilement à une réunion.

Valeur 2. Des solutions qui fonctionnent, plus qu’une documentation exhaustive. Ce que SAFe installe : des backlogs sur plusieurs niveaux, des tableaux de programme, des feuilles de route et une cartographie des dépendances à maintenir en permanence.

Valeur 3. La collaboration avec le client, plus que la négociation contractuelle. Ce que SAFe installe : un engagement pris devant des Business Owners, avec vote de confiance sur des objectifs fixés à douze semaines.

Valeur 4. L’adaptation au changement, plus que le suivi d’un plan. Ce que SAFe installe : un plan produit en deux jours, tenu sur huit à douze semaines, révisable seulement au prochain incrément.

D’un côté l’intention d’origine, de l’autre ce qui est réellement mis en place. Les quatre valeurs sont inversées, une par une, méthodiquement. Ce n’est pas une caricature militante : chaque élément de la seconde colonne figure noir sur blanc dans la documentation officielle du cadre.

Les principes agiles passés au crible

Le Manifeste ne se limite pas à quatre valeurs, il énonce aussi douze principes. Quatre d’entre eux sont particulièrement instructifs quand on les confronte au fonctionnement réel d’un train de livraison.

Principe. Accueillir favorablement les changements de besoins, même tard dans le projet.

Dans un train : un changement en cours d’incrément dérègle les dépendances négociées entre équipes. Il est donc renvoyé au prochain PI Planning, c’est-à-dire à plusieurs semaines de là.

Principe. Livrer fréquemment, avec des cycles de quelques semaines de préférence. Dans un train : la cadence de planification structurante s’étend sur huit à douze semaines.

Principe. Les meilleures architectures émergent d’équipes auto-organisées.

Dans un train : un System Architect et un Enterprise Architect figurent dans la structure officielle des rôles.

Principe. À intervalles réguliers, l’équipe réfléchit aux moyens de devenir plus efficace et ajuste son comportement.

Dans un train : l’ajustement porte sur l’exécution du cadre, très rarement sur la pertinence du cadre lui-même.

Le dernier point est le plus vicieux. SAFe prévoit bien des moments d’inspection et d’adaptation. Mais l’objet de cette adaptation est presque toujours la façon d’appliquer le cadre, jamais le cadre. Quand un dispositif ne produit pas les résultats attendus, la conclusion est invariablement qu’il a été mal implémenté. Cette structure d’argument est imparable, et c’est bien ce qui la rend suspecte : un cadre qui ne peut jamais être réfuté par l’expérience n’est plus un outil de travail.

La strate managériale qu’on voulait justement supprimer

L’agilité était née d’une idée simple, presque politique : rapprocher la décision de ceux qui font le travail. Moins d’échelons, plus d’autonomie, des boucles de retour courtes, une confiance accordée aux équipes.

SAFe rajoute des échelons. Un responsable de train, une couche solution pour coordonner plusieurs trains, une couche portefeuille pour arbitrer les budgets, des propriétaires d’epics, des architectes système et d’entreprise. La matrice se reconstitue, avec ses instances de coordination et ses fonctions d’arbitrage, précisément aux endroits où l’agilité proposait d’en retirer.

Il faut le dire clairement, parce que c’est l’explication la plus solide du succès du cadre. Pour un management intermédiaire que les organisations plates inquiètent légitimement, SAFe est une aubaine. Il rend un titre, un périmètre, une équipe, une légitimité. Il permet de dire oui à l’agilité sans rien céder de la structure de pouvoir existante.

Craig Larman, concepteur d’une approche concurrente, a formulé une observation qui porte sur ce point exact. Sa première loi du comportement organisationnel énonce que les organisations sont implicitement optimisées pour éviter de modifier le statu quo des managers intermédiaires et des positions de spécialistes. Autrement dit, face à un changement qui menace ces positions, une organisation trouvera toujours une façon de l’absorber sans les toucher.

SAFe est l’illustration parfaite de cette loi. C’est un dispositif qui permet à une entreprise de se déclarer agile tout en préservant intégralement sa chaîne hiérarchique. Ce n’est pas un accident. C’est une fonctionnalité, et c’est ce qui explique qu’il se vende si bien à ceux qui décident de l’acheter.

Ron Jeffries, l’un des dix-sept signataires du Manifeste Agile, a posé la critique dans un texte au titre limpide : SAFe, bien mais pas assez bien. Il y reconnaît des bénéfices réels, tout en affirmant que le cadre met en danger la progression d’une organisation vers un fonctionnement vraiment performant. Sa formule est plus dure encore : c’est de la restauration rapide. Nourrissant sur le moment, mauvais sur la durée.

Le PI Planning au microscope

L’événement central mérite qu’on regarde ce qui s’y déroule, parce qu’il concentre toutes les tensions du dispositif.

Deux jours durant, des dizaines de personnes sont réunies dans une même salle ou sur un même outil. On présente le contexte métier et les priorités. Les équipes travaillent ensuite par groupes pour découper le travail, estimer, et surtout identifier les dépendances avec les autres équipes. Ces dépendances sont matérialisées sur un tableau commun, souvent au moyen de fils tendus entre des notes adhésives. Des sessions de négociation permettent d’arbitrer les conflits de calendrier. À la fin, chaque équipe présente ses objectifs, puis les participants votent leur niveau de confiance dans le plan obtenu.

Observez maintenant ce que cette description révèle. L’essentiel de l’énergie de ces deux jours ne sert pas à décider quoi construire. Elle sert à démêler qui dépend de qui. Le tableau couvert de fils tendus n’est pas un outil de pilotage, c’est un diagnostic : il photographie le degré de couplage de votre organisation.

Une entreprise qui a besoin de deux jours pour cartographier ses interdépendances ne souffre pas d’un déficit de planification. Elle souffre d’un découpage qui oblige tout le monde à attendre tout le monde. Le PI Planning ne corrige pas ce défaut, il le rend supportable. Ce qui garantit sa reconduction indéfinie, puisque le vrai problème n’est jamais traité.

La question à poser en sortant de la salle n’est donc pas de savoir si le plan est bon. Elle est de savoir pourquoi ces équipes ne peuvent pas avancer sans se coordonner en permanence, et ce qu’il faudrait changer dans le découpage pour qu’elles le puissent.

Le coût réel, que personne ne calcule

Faites l’exercice vous-même, avec vos propres chiffres, parce qu’aucune étude générale ne remplacera votre arithmétique.

Prenez le nombre de personnes mobilisées lors de votre PI Planning. Multipliez par deux jours. Ajoutez la préparation en amont, qui occupe les responsables produit et les architectes pendant plusieurs jours. Ajoutez les réunions de synchronisation entre équipes tout au long de l’incrément. Ajoutez l’atelier de fin de cycle. Ajoutez le coût des formations et des certifications, ainsi que les honoraires des consultants habilités qui accompagnent le déploiement.

Vous obtenez un montant annuel qui surprend en général ceux qui le calculent pour la première fois. La vraie question n’est pas de savoir si ce montant est élevé dans l’absolu. Elle est de savoir ce qu’il achète.

Si la réponse est une meilleure visibilité pour la direction, c’est une réponse honnête, mais alors il faut cesser de parler d’agilité et parler de pilotage. Si la réponse est une capacité accrue à changer d’avis face au marché, il faut le vérifier avec un indicateur simple : quel délai s’écoule aujourd’hui entre le moment où quelqu’un a une bonne idée et le moment où un client en bénéficie ? Comparez ce délai avant et après le déploiement. Cette mesure unique en dit plus que tous les tableaux de bord du cadre.

Ce que ça produit dans les équipes

Sur le terrain, trois effets reviennent régulièrement, et ils ne relèvent pas de la mauvaise volonté des personnes.

Le premier est la perte du sens du client. Les équipes travaillent sur des Features issues d’Epics arbitrées au niveau du portefeuille. Entre le développeur et l’utilisateur final s’interposent plusieurs niveaux de découpage et plusieurs rôles de traduction. Les gens finissent par servir un backlog plutôt qu’un client.

Le deuxième est l’engagement contraint. Le vote de confiance en fin de PI Planning est présenté comme un outil de transparence. Dans une organisation où la confiance est moyenne, il devient un instrument de pression. Peu de personnes votent leur méfiance devant leur direction et quatre-vingts collègues. On obtient alors un engagement de façade, ce qui est exactement l’inverse d’un engagement.

Le troisième est le déplacement de l’énergie. Une part significative de l’intelligence des équipes se consacre à faire fonctionner le dispositif : préparer les événements, tracer les dépendances, alimenter les outils, respecter le formalisme. Cette énergie ne va pas au produit. Elle va au cadre.

S’ajoute un phénomène connu depuis longtemps. Melvin Conway a observé en 1968 que les organisations produisent des systèmes dont la structure copie celle de leurs canaux de communication. En figeant la composition des trains pour plusieurs mois, SAFe fige aussi les frontières de l’architecture technique. Les découpages organisationnels d’aujourd’hui deviennent la dette technique de demain.

Pourquoi ça se vend quand même

Un article qui se contenterait de charger passerait à côté de l’essentiel. SAFe rencontre un succès considérable, et il faut comprendre pourquoi, parce que les raisons de ce succès sont instructives.

Il répond à une angoisse réelle. Un dirigeant qui pilote quarante équipes a besoin de savoir où en sont les choses, ce qui sera livré, et à quel coût. L’agilité, dans sa version pure, lui répond souvent qu’il faut faire confiance et voir ce qui émerge. Ce n’est pas une réponse recevable quand on doit engager un budget devant un conseil d’administration.

Il offre un chemin balisé. Une direction qui décide une transformation veut un plan, des étapes, des rôles, un calendrier. SAFe fournit tout cela clé en main, avec des consultants formés pour l’installer. Comparé à la proposition alternative, qui consiste à dire qu’il faut travailler la culture pendant des mois sans garantie, l’offre est nettement plus facile à acheter.

Il apporte parfois de vrais bénéfices, en particulier dans les organisations qui partaient de très loin. Une entreprise où les équipes ne se parlaient jamais, où aucune cadence n’existait, où les priorités changeaient chaque semaine sans arbitrage, verra une amélioration en installant SAFe. Non parce que le cadre est bon, mais parce que la situation initiale était pire que tout. Mettre de l’ordre dans le chaos produit toujours un gain visible.

Le problème arrive ensuite. Ce gain initial est presque toujours interprété comme une validation du cadre, ce qui conduit à l’approfondir plutôt qu’à le questionner. L’organisation s’installe alors dans un plateau : plus jamais aussi mauvaise qu’avant, jamais vraiment agile non plus. C’est exactement ce que décrivait Jeffries en parlant d’un cadre qui met en danger la progression vers un fonctionnement réellement performant.

Quand un cadre lourd peut se défendre

Par honnêteté intellectuelle, il faut nommer les contextes où ce type de dispositif se discute.

Quand la coordination porte sur du matériel physique avec des délais d’approvisionnement longs, la synchronisation par cadence a du sens. On ne change pas d’avis sur une pièce commandée six mois à l’avance.

Quand l’environnement est fortement réglementé et que la traçabilité des décisions est une obligation légale, une part du formalisme est imposée de l’extérieur et ne relève pas d’un choix méthodologique.

Quand des dizaines d’équipes partagent un même socle technique ancien, avec des dépendances que personne ne peut supprimer à court terme, un mécanisme de synchronisation vaut mieux que rien.

Dans ces trois cas, le raisonnement reste le même : il s’agit de gérer un problème compliqué, et les outils du compliqué sont légitimes. L’erreur consiste à appeler cela de l’agilité. Ce n’est pas un défaut, c’est un choix. Assumons-le et nommons-le correctement.

Sept signaux que votre agilité à l’échelle n’en est pas

Plutôt qu’un débat théorique sur les cadres, voici des observations de terrain. Chacune se vérifie en quelques jours dans votre organisation.

Une bonne idée émise en semaine trois attend le prochain cycle de planification pour être examinée. Le mot d’ordre devient de la mettre au backlog, ce qui signifie le plus souvent de l’oublier proprement.

Les équipes connaissent par cœur le nom des cérémonies et beaucoup moins celui de leurs utilisateurs. Posez la question directement : à quand remonte le dernier échange avec une personne qui se sert réellement de ce que vous construisez ?

Les rétrospectives portent sur la façon d’appliquer le cadre, jamais sur sa pertinence. Quand un participant suggère de supprimer un rituel, la réponse consiste à expliquer qu’il n’a pas compris son intérêt.

Le nombre de personnes dont le métier consiste à coordonner croît plus vite que le nombre de personnes qui construisent. Comptez, le résultat est parfois édifiant.

Les engagements sont tenus mais les résultats ne suivent pas. Les objectifs de l’incrément sont atteints à quatre-vingt-dix pour cent, et pourtant le produit n’avance pas dans le marché. C’est le signe qu’on mesure la conformité au plan, pas la valeur produite.

Personne ne sait dire ce qui serait supprimé si l’organisation devait alléger le dispositif de moitié. Un cadre dont aucun élément n’est discutable n’est plus un outil, c’est une doctrine.

Enfin, le signal le plus fiable : les problèmes vraiment gênants ne remontent jamais en séance. Ils se règlent en aparté, dans les couloirs ou par téléphone entre deux directeurs. Le dispositif officiel tourne à côté du système réel de décision, sans jamais le rencontrer.

Si vous cochez plus de trois de ces signaux, votre difficulté ne relève pas du réglage. Elle est structurelle, et aucune montée de version n’y changera quoi que ce soit.

Que faire à la place

Le besoin auquel SAFe prétend répondre est réel. Quarante équipes qui se marchent dessus, c’est un vrai sujet, et l’improvisation ne le règle pas davantage qu’un référentiel de trois cents pages.

Ce qui fonctionne ressemble simplement moins à un produit qu’à une discipline.

Des règles peu nombreuses et claires, plutôt qu’un corpus complet. Deux ou trois règles que tout le monde comprend et applique valent mieux que cinquante que personne ne maîtrise sans certification.

Des boucles de retour courtes, plutôt qu’un grand rendez-vous trimestriel. Si votre organisation a besoin de deux jours tous les trois mois pour se coordonner, le problème n’est pas le manque d’événement. C’est que l’information ne circule pas le reste du temps.

Une intention claire et une autonomie réelle sur le comment. Dire où l’on va et pourquoi, puis laisser les équipes trouver la route, en acceptant qu’elles trouvent mieux que vous.

Et surtout, le courage de traiter ce qui bloque vraiment. Dans la plupart des organisations qui déploient un cadre d’agilité à l’échelle, le problème n’a jamais été méthodologique. Il était fait de non-dits entre directions, d’arbitrages que personne ne rend, de priorités contradictoires venues d’en haut, et de managers qui n’ont jamais réellement accepté de lâcher le contrôle. Aucun train ne résout cela.

Ce travail demande de la facilitation en entreprise et de l’intelligence collective au sens exigeant du terme, pas une certification supplémentaire. Il est moins confortable, parce qu’il expose ceux qui dirigent. C’est aussi la raison pour laquelle un cadre outillé se vend mieux.

Comment alléger un dispositif déjà en place

Si vous avez déployé SAFe, l’abandonner brutalement serait une seconde erreur. Une transformation menée au pas de charge a déjà coûté cher, une contre-transformation coûterait autant.

Commencez par mesurer. Trois indicateurs suffisent : le délai entre une idée et sa mise à disposition d’un client, le temps passé en cérémonies rapporté au temps total, et le nombre de décisions qui doivent remonter au-dessus de l’équipe pour être prises. Ces trois chiffres décrivent votre agilité réelle bien mieux que la conformité au cadre.

Retirez ensuite ce qui ne sert qu’à alimenter le dispositif. Chaque artefact, chaque réunion, chaque rôle doit pouvoir répondre à une question simple : qu’est-ce qui se passerait de mal si on l’arrêtait demain ? Quand personne ne trouve de réponse convaincante, vous tenez votre première suppression.

Raccourcissez la cadence progressivement. Passer d’une planification à douze semaines à une planification à six change davantage la culture qu’un discours sur l’agilité.

Enfin, ouvrez la question interdite : le cadre lui-même est-il adapté à ce que nous faisons ? Une organisation capable de poser cette question en réunion, sans que cela ressemble à un procès, a déjà accompli plus que la plupart des déploiements.

Le cadre n’a jamais été le sujet

SAFe n’est pas une escroquerie. C’est un dispositif cohérent, professionnellement construit, qui répond à une demande sincère de dirigeants confrontés à un problème difficile.

C’est simplement une réponse du compliqué à une question du complexe. Un cadre qui promet l’adaptation et livre de la planification. Qui promet l’autonomie et livre des rôles de coordination. Qui promet la simplicité et livre un vocabulaire à apprendre. Et qui, ce faisant, permet à une organisation de se déclarer transformée sans avoir rien changé à la façon dont ses décisions se prennent.

La vraie question n’a jamais été de choisir le bon cadre d’agilité à l’échelle. Elle est de savoir si vous êtes prêts à traiter ce qui bloque réellement chez vous. Si la réponse est oui, vous aurez besoin de beaucoup moins de méthode que vous ne le croyez. Si la réponse est non, aucun train ne vous emmènera nulle part.

Questions fréquentes sur SAFe

SAFe est-il vraiment agile ?

Il en reprend le vocabulaire et certaines pratiques, itérations et rétrospectives comprises. Mais son architecture repose sur la planification synchronisée, la coordination centralisée et l’engagement sur un horizon de plusieurs mois. Ce sont des réponses de type industriel, taillées pour des environnements prévisibles.

Sur les quatre valeurs du Manifeste Agile, le fonctionnement nominal du cadre produit l’inverse de chacune. Ce n’est pas un défaut d’application, c’est la conception. On peut trouver ce dispositif utile, mais l’appeler agile relève de l’abus de langage.

Quelle est la différence entre SAFe et Scrum ?

Scrum est un cadre léger destiné à une équipe unique, décrit en une vingtaine de pages, avec trois rôles et quelques événements. Il ne dit rien de la coordination entre plusieurs équipes.

SAFe est un cadre d’entreprise qui prétend couvrir toute l’organisation, de l’équipe au portefeuille financier, avec une dizaine de rôles et plusieurs niveaux de découpage. Le passage de l’un à l’autre ne relève pas d’un simple changement d’échelle : c’est un changement de nature, qui réintroduit une chaîne de commandement que Scrum s’efforçait précisément d’éviter.

Pourquoi SAFe est-il autant adopté malgré les critiques ?

Parce qu’il rassure. Il offre à une direction un plan lisible, des rôles identifiés, des indicateurs et un calendrier, là où l’agilité pure demande de faire confiance sans garantie. Il fournit un chemin balisé, des consultants formés et un déploiement clé en main.

Il permet surtout de conserver intégralement la structure hiérarchique existante en la rebaptisant. Adopter SAFe demande beaucoup moins de courage que de changer la façon dont les décisions se prennent, tout en produisant les mêmes annonces en interne et en externe.

Le PI Planning est-il utile ?

Réunir des équipes qui ne se parlent jamais produit toujours quelque chose. Beaucoup de participants en sortent avec le sentiment d’avoir enfin compris ce que font les autres, et ce sentiment est légitime.

La question est ailleurs : pourquoi faut-il un événement de deux jours tous les trois mois pour obtenir cela ? Si l’information ne circule qu’à cette occasion, le problème n’est pas l’absence de rendez-vous, c’est le fonctionnement du reste de l’année. Un dispositif qui compense un défaut structurel finit par le rendre invisible, donc permanent.

Existe-t-il des alternatives à SAFe ?

Oui, plusieurs approches revendiquent une plus grande fidélité aux principes agiles, avec des cadres nettement plus légers et beaucoup moins de rôles ajoutés. Elles reposent sur des équipes réellement autonomes, un minimum de règles communes et une coordination par l’information plutôt que par la structure.

Mais changer de cadre revient souvent à déplacer la question. Si les décisions continuent de remonter au même endroit, si les priorités restent contradictoires et si les désaccords entre directions restent non dits, aucun cadre ne produira d’agilité. La méthode n’a jamais été le facteur limitant.

Faut-il abandonner SAFe si on l’a déjà déployé ?

Pas du jour au lendemain. Mesurez d’abord ce que le dispositif produit réellement : délai entre une idée et sa mise en production, part du temps passé en cérémonies, nombre de décisions qui doivent remonter au-dessus de l’équipe.

Retirez ensuite ce qui ne sert qu’à alimenter le cadre lui-même, en posant pour chaque élément la question de ce qui se passerait si on l’arrêtait. Raccourcissez progressivement la cadence de planification. Un allègement continu, décidé sur la base de mesures, vaut mieux qu’une nouvelle transformation annoncée en grande pompe.