SAFe : et si sa bureaucratie expliquait son succès ?

Une transformation qui s'arrête à la porte du comité

Soit une grande organisation, banque, assureur, industriel ou service public, qui annonce sa transformation agile. La scène qui suit est une illustration de mécanisme, pas un cas réel. Plusieurs centaines de personnes sont formées, à l'image des plus de 300 salariés formés au cadre dans le cas PFA étudié plus loin, des « trains » sont constitués, les équipes planifient tous les trimestres, livrent toutes les deux semaines, tiennent leurs rétrospectives. Le vocabulaire change, les certifications s'accumulent.

Puis une équipe constate, après trois démonstrations, qu'une fonctionnalité prévue au plan ne sert à rien. Elle propose de l'abandonner et de réaffecter sa capacité à un besoin révélé par les utilisateurs. La proposition remonte. Elle passe devant un comité, qui la renvoie à l'arbitrage budgétaire annuel, lequel attend l'avis de la direction métier. Six mois plus tard, la fonctionnalité inutile est livrée, conformément à l'engagement initial.

Rien, dans cette scène, n'est contraire à la lettre du cadre adopté. Tout, pourtant, contredit son intention. Les équipes ont changé leur façon de travailler, mais doivent toujours obtenir les mêmes autorisations pour changer de direction. Le cadre en question s'appelle souvent SAFe, et ce n'est peut-être pas un hasard.

L'agilité promettait de déplacer la décision, pas seulement le rythme

Le Manifeste pour le développement agile de logiciels, publié en 2001, énonce quatre valeurs dont la dernière donne son nom au mouvement : « L'adaptation au changement plus que le suivi d'un plan ». Le texte ne rejette ni le plan, ni la documentation, ni le contrat : « Nous reconnaissons la valeur des seconds éléments, mais privilégions les premiers. » Ses douze principes ajoutent l'accueil des changements de besoins, « même tard dans le projet », la livraison fréquente et la confiance faite aux personnes motivées.

L'agilité n'est donc ni l'absence de planification, ni l'absence de hiérarchie, ni l'absence de budget. Elle désigne la capacité d'une organisation à apprendre de ses livraisons et à modifier en conséquence ses priorités, en confiant les décisions à ceux qui disposent de l'information. L'article propose de distinguer trois niveaux de cette capacité. L'agilité de production consiste à produire, tester et livrer fréquemment. L'agilité de décision consiste à modifier les priorités à partir de ce qui a été appris. L'agilité de gouvernance consiste à réallouer des ressources, changer d'objectifs ou abandonner une initiative. Une équipe qui livre toutes les deux semaines peut parfaitement travailler dans une organisation qui n'est agile qu'au premier niveau.

Les enquêtes industrielles suggèrent que ce décalage n'a rien d'exceptionnel. La quinzième enquête State of Agile de l'éditeur Digital.ai, conduite en ligne entre février et avril 2021 sur 1 382 réponses complètes, place parmi les principaux obstacles à l'adoption et à la mise à l'échelle de l'agilité la résistance générale de l'organisation au changement (42 %), une participation insuffisante de la direction (41 %) et un soutien managérial inadéquat (40 %). L'échantillon n'a rien de représentatif, puisque l'enquête a été diffusée avec l'appui de Scrum.org et de Scaled Agile, l'éditeur de SAFe. Même tirés d'une population acquise à l'agilité, ces chiffres situent pourtant la difficulté moins dans les équipes que dans ce qui les entoure. L'agilité de production progresse plus vite que l'agilité de gouvernance.

SAFe, une agilité assez organisée pour être présentable

SAFe répond à un problème réel : coordonner des dizaines d'équipes dont les travaux dépendent les uns des autres. Son unité de base est l'Agile Release Train (ART, regroupement de plusieurs équipes alignées sur une même mission et synchronisées sur un calendrier commun). Les trains travaillent par incréments de programme, dont la durée typique va de huit à douze semaines, ouverts par un PI Planning (événement de planification collective de deux jours où les équipes du train fixent leurs objectifs et identifient leurs dépendances). Le Product Management (fonction qui porte le besoin des clients et priorise le travail du train) arbitre le contenu, des Business Owners (responsables métier) valident les objectifs, et le Lean Portfolio Management (instance de pilotage des investissements à l'échelle du portefeuille) relie l'ensemble à la stratégie.

Ce formalisme se prête à deux lectures. La lecture favorable y voit une clarification des responsabilités, sans laquelle aucune grande organisation ne sortirait de ses habitudes. La lecture critique y voit un support commode pour un fonctionnement vertical, où la synchronisation devient contrôle et où chaque nouveau rôle ajoute un niveau de validation.

Il serait inexact de prétendre que SAFe est conçu pour centraliser. Son neuvième principe s'intitule précisément « Decentralize Decision-Making » (décentraliser la prise de décision) et affirme que la vitesse de livraison exige des décisions prises au plus près de l'information. Mais le même principe ménage une exception : certaines décisions sont « strategic and global and have economies of scale that justify centralized decision-making » (stratégiques et globales, et présentent des économies d'échelle qui justifient une décision centralisée). La frontière entre les deux catégories n'est pas fixée par le cadre. Elle est fixée par ceux qui détiennent déjà le pouvoir de la tracer.

Une analyse documentaire publiée le 1er avril 2026 dans les actes de la conférence XP 2026 par Rocha, Mendes, Paasivaara et Lassenius compare la manière dont les principaux cadres de mise à l'échelle répartissent les décisions. Les auteurs observent que « SAFe exhibits lower diversity in decision styles, suggesting that the model is more restrictive in the level of autonomy it allows » (SAFe présente une moindre diversité de styles décisionnels, ce qui suggère un modèle plus restrictif quant au niveau d'autonomie qu'il autorise). Ils relèvent que l'autonomie sur l'objectif produit y est réduite, le Product Owner devant consulter des parties prenantes et des responsables métier extérieurs à l'équipe. Ce résultat porte sur la documentation officielle des cadres, pas sur l'autonomie effectivement exercée.

Le cas PFA : choisir le cadre que la direction peut endosser

Pourquoi choisit-on SAFe ? Une enquête menée auprès de 204 praticiens répartis dans 26 pays, publiée le 11 octobre 2021 par Putta, Uludağ, Hong, Paasivaara et Lassenius, place SAFe en tête des cadres adoptés par les répondants. L'enquête State of Agile de 2021 aboutit au même classement : 37 % de ses répondants désignent SAFe comme le cadre de mise à l'échelle qu'ils suivent le plus étroitement, loin devant Scrum@Scale et Scrum of Scrums (9 %). Les auteurs de l'étude PFA résument ainsi les résultats de cette enquête : « SAFe is widely adopted, well-defined and clearly documented, and well-supported by coaching, training, and guidance » (SAFe est largement adopté, bien défini et clairement documenté, et bien soutenu par le coaching, la formation et l'accompagnement). L'étude du cas relève elle-même 17 raisons d'adoption, dont les plus saillantes sont de raccourcir les délais, d'améliorer la collaboration et d'utiliser un cadre « well-described and comprehensive » (bien décrit et complet). Ces critères sont rationnels. Ils dessinent pourtant une préférence : celle d'une transformation explicable, outillée et déjà validée par d'autres.

Le cas étudié par Putta, Paasivaara et Lassenius dans « SAFe transformation in a large financial corporation », publié le 16 décembre 2023 dans Empirical Software Engineering (vol. 29, article 27), permet de voir ce mécanisme à l'œuvre. PFA est un groupe danois de retraite et d'assurance fondé en 1917, qui employait 1 300 personnes, dont environ 300 dans le développement logiciel, organisées en 32 équipes entre le Danemark et la Pologne. L'organisation était fonctionnelle, découpée en silos dirigés par des directeurs « propriétaires » de leurs ressources, avec un style de commandement et de contrôle et une gestion de projet PRINCE2. Selon un interviewé, il fallait « at least one and a half year » (au moins un an et demi) pour passer d'une idée à une fonctionnalité livrable, et les auteurs indiquent que la livraison d'un projet aux clients internes prenait sous PRINCE2 de six mois à trois ans. Les motifs de la transformation étaient réels : à l'arrivée d'un nouveau PDG en 2015, l'organisation comptait « 14 different software development models » (14 modèles différents de développement logiciel), et il s'agissait de réduire les délais, rapprocher l'informatique et les métiers, gagner en productivité.

Fin 2016, les dirigeants examinent plusieurs approches, dont le modèle inspiré de Spotify, Disciplined Agile Delivery et LeSS (Large-Scale Scrum, mise à l'échelle fondée sur Scrum et sur la réduction des structures), et deux directeurs suivent un cours « Leading SAFe » de deux jours. L'approche Spotify était jugée plus ambitieuse et plus difficile à engager. Parmi les raisons du choix figurent la documentation abondante, le caractère complet et présentable du cadre, sa popularité dans le secteur financier, la facilité à trouver consultants et formateurs. Une raison retient l'attention : « The fact that SAFe prescribes a top-down approach was considered to make getting buy-in from top management easier » (le fait que SAFe prescrive une démarche descendante était considéré comme facilitant l'adhésion de la direction générale).

La suite montre comment l'organisation existante a façonné le cadre adopté. SAFe recommande d'aligner les trains sur les flux de valeur. PFA y renonce, et ses trains reproduisent presque à l'identique les anciens silos départementaux. Les chercheurs attribuent ce choix principalement aux enjeux de pouvoir internes, le poids de chaque directeur se mesurant au nombre de personnes placées sous son autorité, mais aussi au couplage technique étroit entre systèmes de retraite et d'assurance. Les grands projets traditionnels sont maintenus : plus de trente projets coexistent avec les trains, qui leur consacrent 40 à 50 % de leur temps. Il en résulte des conflits de priorité et une charge de coordination que les auteurs décrivent comme un frein à l'agilité.

Les bénéfices sont pourtant tangibles : meilleure collaboration, transparence accrue, délais raccourcis, autonomie plus grande des équipes, satisfaction élevée des salariés des trains. Le cas ne prouve aucune intention de préserver des prérogatives, et les auteurs, qui s'appuient sur 24 entretiens avec 27 personnes, menés de février à avril 2018 dans les deux plus anciens des quatre trains d'une seule entreprise, ne prétendent pas à la généralité. Il illustre en revanche comment l'acceptabilité managériale de SAFe et la conservation des structures historiques peuvent coexister. Une transformation peut être choisie pour sa compatibilité avec l'organisation existante, puis limitée par cette même organisation.

Le découplage, ou l'agilité comme mythe rationnel

Les faits qui précèdent appellent un concept. En 1977, dans « Institutionalized Organizations: Formal Structure as Myth and Ceremony », publié dans l'American Journal of Sociology, John Meyer et Brian Rowan soutiennent que bien des structures formelles ne s'expliquent pas par leur efficacité, mais par leur conformité aux mythes rationnels de l'environnement institutionnel (prescriptions impersonnelles, tenues pour rationnelles et légitimes indépendamment de leurs effets). En les adoptant, une organisation démontre qu'elle agit de manière moderne et responsable, et gagne en légitimité, en ressources et en stabilité.

Le découplage (Meyer et Rowan, 1977)

Pour Meyer et Rowan, une organisation soumise à des exigences institutionnelles contradictoires avec ses contraintes de travail protège sa structure formelle de l'épreuve des faits en la séparant de ses activités réelles. Les auteurs écrivent : « decoupling enables organizations to maintain standardized, legitimating, formal structures while their activities vary in response to practical considerations » (le découplage permet aux organisations de maintenir des structures formelles standardisées et légitimantes, tandis que leurs activités varient en fonction de considérations pratiques). Le découplage s'accompagne d'une « logique de confiance et de bonne foi » et d'une inspection rendue cérémonielle. Les auteurs précisent que cette confiance n'a rien de frauduleux.

L'application à l'agilité à l'échelle est une proposition de l'article, pas de Meyer et Rowan. Le vocabulaire agile, les rôles, les certifications, les événements de planification et les tableaux de bord constituent aujourd'hui une structure formelle hautement légitime. Une direction qui les adopte se signale comme moderne auprès de ses actionnaires, de ses salariés et de ses pairs. Le découplage apparaît lorsque cette structure se développe sans que les mécanismes de financement, d'arbitrage et de contrôle ne bougent. Chez PFA, le cadre visible est en place, mais la carte du pouvoir départemental est restée celle d'avant.

Cram et Newell ont observé ce phénomène avant même la diffusion massive de SAFe. Dans un article publié le 19 janvier 2016 dans l'European Journal of Information Systems, ils examinent l'agilité comme mode managériale (pratique diffusée par imitation et prestige autant que par démonstration de son efficacité) à partir de cinq études de cas. Ils distinguent les Crusaders, qui adoptent l'agilité sous une forme pure, les Tailors, qui la combinent avec des approches traditionnelles selon leurs circonstances, et les Dabblers, qui pratiquent quelques activités agiles cérémonielles à côté d'une approche traditionnelle. Leur typologie montre que l'adoption cérémonielle est un mode d'adoption documenté, et non une hypothèse polémique.

Treize tensions entre une unité SAFe et son environnement (Bitzer, Brax et Teuchert, 2023)

Chez un prestataire allemand de services financiers coté en bourse, une unité agile d'environ 150 personnes appliquait le cadre au milieu d'une organisation restée traditionnelle. À partir d'entretiens menés entre février et avril 2023 (16 selon l'article publié, 18 selon la thèse de Michael Bitzer qui le reprend), d'observations et de documents internes, les auteurs identifient 13 tensions, regroupées en trois domaines : la fixation des objectifs, la planification et le reporting. Les salariés y occupent souvent un rôle dans l'unité agile et un autre dans leur fonction d'origine, avec des objectifs divergents. Et tandis que les méthodes agiles engagent les équipes sur la livraison de valeur à court terme, les parties prenantes extérieures réclament des feuilles de route et des engagements de long terme. Les auteurs notent que certaines tensions naissent d'écarts par rapport au cadre lui-même.

Le reporting est le plus révélateur des trois domaines. Un dispositif de suivi qui jugerait des équipes agiles à leur écart au plan initial perpétuerait, par construction, la logique que l'agilité prétendait dépasser. Ce ne serait pas une défaillance des contrôleurs de gestion, mais l'indice d'un découplage : la méthode change dans les équipes, l'instrument de redevabilité reste prédictif.

Un précédent : les cercles de qualité, une participation sans pouvoir de décider

Le découplage a une histoire. Au début des années 1980, impressionnées par le succès des produits japonais, les entreprises américaines adoptent massivement les cercles de qualité, petits groupes de salariés réunis pour résoudre des problèmes de travail communs et formuler des suggestions à la direction : selon une étude de la Bourse de New York de 1982 rapportée par Lawler et Mohrman, 44 % des entreprises de plus de 500 salariés disposaient d'un tel programme, et près de trois sur quatre l'avaient lancé après 1980. Le dispositif promettait une organisation plus participative. Dans « Quality Circles After the Fad », publié dans la Harvard Business Review en janvier 1985, Edward Lawler et Susan Mohrman décrivent des programmes logés dans une structure parallèle à la hiérarchie, sans pouvoir de décision propre, et estiment que certains usages que leur assignaient les directions étaient « doomed from the start » (condamnés dès le départ). Leur déclin suivait un enchaînement typique : résistance de l'encadrement intermédiaire et des fonctions support, coupes budgétaires, désillusion des participants. En décembre 1991, Stephen Hill confirmait dans le British Journal of Industrial Relations, à partir de treize entreprises, que les cercles s'étaient effondrés « as the result of inadequate organizational design which encouraged managerial recalcitrance » (en raison d'une conception organisationnelle inadéquate, qui encourageait la réticence des managers).

La proximité avec l'agilité à l'échelle est structurelle : un dispositif importé pour son prestige, ajouté à côté de la hiérarchie plutôt qu'à sa place, et promettant une redistribution de la décision qui n'est pas transférée. La différence est tout aussi nette. Les cercles ne touchaient pas au travail quotidien, alors qu'un train SAFe réorganise réellement la production. Le précédent n'annonce donc pas le destin de SAFe. Il indique où regarder : non pas le nombre de cercles ou de trains, mais ce que l'organisation leur laisse décider.

Soutenir une transformation n'est pas accepter d'être transformé

La revue systématique de Dikert, Paasivaara et Lassenius, publiée dans le Journal of Systems and Software en septembre 2016, analyse 52 publications décrivant 42 transformations agiles à grande échelle. Selon la synthèse qu'en donnent Putta, Paasivaara et Lassenius en 2023, le soutien de la direction y figure, avec le choix et l'adaptation du modèle agile et l'investissement dans la formation et le coaching, parmi les facteurs de succès les plus saillants. Encore faut-il savoir de quel soutien il s'agit.

Une direction peut lancer, financer, communiquer, siéger aux comités, exiger des résultats, sans jamais renoncer aux arbitrages centralisés, sans réexaminer l'allocation budgétaire, sans accepter qu'une trajectoire change en cours d'année. L'article propose de distinguer, à titre analytique et non comme échelle validée, trois niveaux de soutien. Le soutien déclaratif annonce, encourage et finance. Le soutien opérationnel supprime des obstacles et fournit des ressources. Le soutien transformateur modifie les décisions de la direction elle-même, délègue réellement et adapte la gouvernance.

Le cas PFA offre deux indices. La sélection du cadre y a été une décision descendante, et de nombreux interviewés du niveau équipe, membres d'équipe et Scrum Masters, ont déclaré n'avoir aucune idée des raisons de l'adoption de SAFe. La direction a par ailleurs jugé que la formation « Leading SAFe » ne lui apprenait presque rien sur la manière de diriger, et a conçu un cours séparé d'une journée sur le leadership lean et agile. La documentation officielle de SAFe va plus loin : dans un article consacré à la mise en œuvre par invitation, elle qualifie la décision d'adopter l'agilité et de choisir l'approche de décision stratégique classique, à centraliser. Une organisation peut changer toute sa méthode de travail sans changer ceux qui ont le dernier mot.

Il en résulte une asymétrie. Les équipes doivent accepter l'incertitude, la remise en cause et l'apprentissage permanent. Dans le même temps, la gouvernance leur demande de garantir périmètre, budget, date et trajectoire plusieurs mois à l'avance. L'organisation demande aux équipes de devenir agiles, mais continue parfois à leur commander des certitudes. Le droit à l'adaptation est distribué à l'inverse de la hiérarchie.

Carroll, Conboy et Wang, dans « From transformation to normalisation », publié en 2023 dans le Journal of Information Technology, mobilisent la théorie du processus de normalisation (analyse des conditions par lesquelles une pratique nouvelle devient routinière et cesse d'être un projet) pour étudier une transformation agile à grande échelle. Leur constat est sans détour : « the standard focus on initial adoption is one of the main reasons for the widespread failure of digital transformations » (l'attention habituellement portée à l'adoption initiale est l'une des principales raisons de l'échec répandu des transformations numériques). Appliqué au découplage, ce déplacement suggère que ce qui se normalise peut être la cérémonie plutôt que la redistribution de la décision.

Ce que la critique de SAFe ne doit pas oublier

La thèse du découplage a ses limites, et elles sont sérieuses. SAFe n'impose aucune gouvernance autoritaire. Il prévoit la décentralisation, le retour d'expérience et des budgets de portefeuille révisables. La critique porte sur la compatibilité de sa structure avec des usages conservateurs, pas sur une intention de ses concepteurs.

Les grandes organisations ont, de plus, besoin de coordination. Une décision centralisée sur un risque transversal, des jalons réglementaires ou des contrôles de sécurité ne sont pas en soi des symptômes de découplage. Van Wessel, Kroon et De Vries, dans un article mis en ligne le 15 décembre 2021 par l'IEEE Transactions on Engineering Management, ont suivi sur près de trois ans, à partir d'entretiens avec des consultants d'un même cabinet, trois entreprises européennes de services qui avaient adopté SAFe, LeSS et le modèle inspiré de Spotify. Les trois ont convergé vers des solutions hybrides empruntant à SAFe et à Spotify. Le groupe financier parti de LeSS a ajouté de l'orientation descendante parce que les mises en œuvre de ses départements « did not fit together well » (ne s'articulaient pas bien entre elles). Mais chez l'opérateur de télécommunications passé par SAFe, les couches de management et les rôles ajoutés rendaient l'organisation « not as Agile as it is supposed to be » (moins agile qu'elle n'est censée l'être). Coordination nécessaire et sédimentation hiérarchique peuvent emprunter les mêmes formes. Seul l'examen des droits de décision permet de les distinguer.

Une transformation progressive vaut aussi mieux qu'une transformation impossible. Les auteurs de l'étude PFA rapportent que la structure en silos a été retenue en connaissance de cause comme point de départ sous-optimal, pour démarrer avec moins de résistance et réorganiser ensuite les trains vers des flux de bout en bout. L'acceptabilité initiale peut être un levier. Le problème naît lorsque le compromis de départ devient l'état permanent.

Enfin, un cadre plus léger n'est pas nécessairement meilleur. Verwijs et Russo ont publié le 29 mai 2024 dans Empirical Software Engineering une comparaison portant sur 15 078 membres de 4 013 équipes agiles, complétée par l'évaluation de 1 841 parties prenantes. Les différences d'efficacité entre approches de mise à l'échelle y sont jugées trop négligeables pour avoir une portée pratique. SAFe présente un effet négatif statistiquement significatif sur l'autonomie des équipes, mais d'une ampleur qualifiée de nulle en pratique. Ce résultat affaiblit toute critique fondée sur le seul nom du cadre et renforce l'intérêt d'examiner les décisions réelles. Le même raisonnement vaut pour l'approche inspirée de Spotify, dont Henrik Kniberg rappelait dès le 7 juin 2015 qu'elle n'avait jamais été conçue comme un cadre générique. Que la direction de PFA ait écarté l'option la plus ambitieuse ne prouve pas que celle-ci aurait mieux fonctionné.

Une grille pour savoir qui peut changer le plan

Proposition éditoriale de l'article, non instrument validé.

Question posée à l'organisation	Indice de transformation	Signal de découplage possible
Qui fixe les priorités opérationnelles ?	Le responsable produit, sur la base des retours	Un comité extérieur au train, sur la base du plan annuel
Une fonctionnalité devenue inutile peut-elle être abandonnée ?	Oui, au niveau du train, sans escalade	Seulement après un arbitrage budgétaire
Un retour d'utilisateurs contraire au plan modifie-t-il le plan ?	Oui, dès l'incrément suivant	Il est consigné pour la prochaine version
Les budgets peuvent-ils être réorientés en cours d'année ?	Oui, selon des règles connues	Non, ils restent attachés aux projets
Le reporting mesure-t-il la valeur livrée ou l'écart au plan ?	La valeur livrée et les apprentissages	L'écart au périmètre et à la date initiaux
La direction applique-t-elle des boucles de retour à ses propres décisions ?	Oui, ses arbitrages sont revus et révisés	Ses décisions ne sont jamais réexaminées

Qui a vraiment le droit de changer le plan ?

SAFe est un dispositif réel d'agilité à l'échelle. Il peut améliorer la coordination, raccourcir les délais et accroître l'autonomie, comme le montre le cas PFA. Sa bureaucratie, au sens neutre où l'article l'entend, le rend acceptable aux grandes organisations, et c'est à la fois sa force et sa vulnérabilité. Sa capacité à rassurer les organisations traditionnelles pourrait aussi leur permettre de ne pas changer suffisamment. Plusieurs études rendent plausible l'idée que cette compatibilité avec le management traditionnel contribue à son succès. Aucune ne la démontre comme mécanisme général. Le découplage décrit par Meyer et Rowan rend compte de ce qui se passe lorsque les mécanismes qui concentrent la décision restent intacts : la structure agile prospère, la gouvernance reste prédictive, et chacun agit de bonne foi.

Une hypothèse en découle, et elle est vérifiable. Si l'attrait de SAFe tient en partie à sa compatibilité avec le management traditionnel, son éditeur, attentif aux directions qui l'achètent, enrichira le cadre en instruments de gouvernance plus vite qu'en droits de décision délégués. Le terrain d'observation existe. En juin 2026, Scaled Agile a présenté AI-Native SAFe, une nouvelle version qui, selon l'entreprise, « does not replace Core SAFe » (ne remplace pas le SAFe de base) et se présente comme « a reinvention » (une réinvention). D'ici au 31 décembre 2027, la documentation publique d'AI-Native SAFe consacrée à la prise de décision et au portefeuille dira si l'exception du neuvième principe sur les décisions « strategic and global » reste formulée sans critère désignant qui en trace la frontière, et si un train y obtient le droit documenté de réallouer sa capacité ou son budget entre deux incréments sans escalade vers le portefeuille. Le maintien de l'exception en l'état, sans un tel droit, rendrait l'hypothèse plus plausible. L'apparition de règles explicites de délégation l'affaiblirait.

La vraie question n'est peut-être pas de savoir si les équipes ont appris à travailler en SAFe. Mais si leur direction a, elle aussi, appris à changer d'avis.

---

Note méthodologique

Recherche de sources, croisement des données et structuration du raisonnement s'appuient sur une assistance par intelligence artificielle. Le choix de l'angle et du cadre théorique, la vérification des sources, les arbitrages et l'établissement du texte final relèvent de l'auteur. Parmi ces arbitrages figurent le choix des cercles de qualité comme parallèle historique, préférés à la gestion de la qualité totale et au reengineering parce qu'ils combinent au plus près structure ajoutée à la hiérarchie et décision non transférée. Les trois niveaux d'agilité, les trois niveaux de soutien, la grille de diagnostic et l'hypothèse finale sont des propositions analytiques de l'auteur, non des résultats établis. Les enquêtes State of Agile reposent sur des échantillons volontaires de taille variable (1 382 réponses complètes en 2021, 788 répondants pour l'édition annoncée le 16 janvier 2024, où 34 % déclarent créer leur propre cadre ou ne suivre aucun cadre imposé à l'échelle de l'entreprise) : leurs pourcentages ne se comparent pas directement d'une édition à l'autre. Les citations anglaises sont traduites par l'auteur.

image générée par IA (ChatGPT Images 2.5)

Sources

Publications académiques empiriques

Putta, A., Paasivaara, M., Lassenius, C., « SAFe transformation in a large financial corporation », Empirical Software Engineering, vol. 29, article 27, 16 décembre 2023. https://link.springer.com/article/10.1007/s10664-023-10420-w

Putta, A., Uludağ, Ö., Hong, S.-L., Paasivaara, M., Lassenius, C., « Why Do Organizations Adopt Agile Scaling Frameworks? A Survey of Practitioners », actes ESEM '21, 11 octobre 2021. https://dl.acm.org/doi/10.1145/3475716.3475788

Bitzer, M., Brax, F. M., Teuchert, A., « Scaled Agile Framework Meets Traditional Management – A Case of a Financial Services Provider », ICIS 2023 Proceedings, mis en ligne le 15 novembre 2023. https://aisel.aisnet.org/icis2023/isdesign/isdesign/7/

Bitzer, M., « Conceptualizing and Theorizing Organizations' Digital Transformation From a Continuous Change Perspective », thèse de doctorat, Université de Bayreuth, soutenue le 26 mars 2024. https://epub.uni-bayreuth.de/id/eprint/7729/1/Dissertation_MichaelBitzer_Ver%C3%B6ffentlichung.pdf

Van Wessel, R. M., Kroon, P., De Vries, H. J., « Scaling Agile Company-Wide: The Organizational Challenge of Combining Agile-Scaling Frameworks and Enterprise Architecture in Service Companies », IEEE Transactions on Engineering Management, mis en ligne le 15 décembre 2021, vol. 69, n° 6, 2022, pp. 3489-3502, doi 10.1109/TEM.2021.3128278. https://pure.eur.nl/ws/portalfiles/portal/45533311/Scaling_Agile_Company_Wide_The_Organizational_Challenge_of_Combining_Agile_Scaling_Frameworks_and_Enterprise_Architecture_in_Service_Companies.pdf

Rocha, Mendes, Paasivaara, Lassenius, « Decision-Making and Team Autonomy in Large-Scale Agile Software Development: An Analysis of Scaling Frameworks », XP 2026, LNBIP vol. 578, pp. 39-55, 1er avril 2026. https://link.springer.com/chapter/10.1007/978-3-032-22375-3_3

Verwijs, C., Russo, D., « Do Agile scaling approaches make a difference? An empirical comparison of team effectiveness across popular scaling approaches », Empirical Software Engineering, vol. 29, article 75, 29 mai 2024. https://link.springer.com/article/10.1007/s10664-024-10481-5

Dikert, K., Paasivaara, M., Lassenius, C., « Challenges and success factors for large-scale agile transformations: A systematic literature review », Journal of Systems and Software, vol. 119, septembre 2016, pp. 87-108. https://www.sciencedirect.com/science/article/pii/S0164121216300826

Cram, W. A., Newell, S., « Mindful revolution or mindless trend? Examining agile development as a management fashion », European Journal of Information Systems, vol. 25, 19 janvier 2016, pp. 154-169. https://link.springer.com/article/10.1057/ejis.2015.13

Carroll, N., Conboy, K., Wang, X., « From transformation to normalisation: An exploratory study of a large-scale agile transformation », Journal of Information Technology, vol. 38, n° 3, 2023, pp. 267-303, doi 10.1177/02683962231164428, version AISeL mise en ligne le 29 août 2024. https://aisel.aisnet.org/jit/vol38/iss3/3/

Cadre théorique

Meyer, J. W., Rowan, B., « Institutionalized Organizations: Formal Structure as Myth and Ceremony », American Journal of Sociology, vol. 83, n° 2, septembre 1977, pp. 340-363. https://www.journals.uchicago.edu/doi/10.1086/226550

Parallèle historique

Lawler, E. E. III, Mohrman, S. A., « Quality Circles After the Fad », Harvard Business Review, vol. 63, n° 1, janvier 1985, pp. 65-71. https://hbr.org/1985/01/quality-circles-after-the-fad

Hill, S., « Why Quality Circles Failed but Total Quality Management Might Succeed », British Journal of Industrial Relations, vol. 29, n° 4, décembre 1991, pp. 541-568. https://onlinelibrary.wiley.com/doi/abs/10.1111/j.1467-8543.1991.tb00371.x

Enquêtes industrielles

Digital.ai, « 15th State of Agile Report. Agile adoption accelerates across the enterprise », publié le 13 juillet 2021. https://digital.ai/catalyst-blog/15th-state-of-agile-report-agile-leads-the-way-through-the-pandemic-and-digital/

Digital.ai, « 17th State of Agile Report: 71% Use Agile in their SDLC », communiqué du 16 janvier 2024. https://www.businesswire.com/news/home/20240116199385/en/17th-State-of-Agile-Report-71-Use-Agile-in-their-SDLC-Small-Organizations-Report-Strong-Business-Benefits-Medium-and-Larger-Sized-Companies-Continue-to-Experience-Barriers-in-Successfully-Scaling-Agile

Documentation de référence

Manifeste pour le développement Agile de logiciels, 2001, version française. https://agilemanifesto.org/iso/fr/manifesto.html

Principes sous-jacents au manifeste, 2001, version française. https://agilemanifesto.org/iso/fr/principles.html

Scaled Agile, « SAFe Lean-Agile Principles », « Principle #9 - Decentralize Decision-Making », « Advanced Topic - Invitation-based SAFe implementation », framework.scaledagile.com, consultation le 10 octobre 2026.

Sales, A., « New Release: AI-Native SAFe is the Operating Model for the AI-Native Organization », Scaled Agile, 23 juin 2026. https://framework.scaledagile.com/blog/ai-native-safe-is-the-operating-model-for-the-ai-native-organization

Kniberg, H., « No, I didn't invent the Spotify model », Crisp's Blog, 7 juin 2015.