Les grands frameworks agiles du conseil, comparés : SAFe, LeSS, Scrum@Scale, Spotify, DAD, Nexus, KMM, FAST — et comment BCG, McKinsey, Deloitte, EY, PwC, KPMG, Accenture, Bain, Capgemini et IBM les packagent (édition 2026)
Une référence pour praticiens : ce que prescrivent réellement les huit frameworks agiles à l'échelle, ce que les dix grands cabinets de conseil ajoutent par-dessus, et comment un acheteur doit lire la différence — avec sources primaires et cas phares nommés tout au long.
Pourquoi comparer ?
« SAFe versus LeSS » est googlisé un million de fois. « Alternatives au modèle Spotify » l'est encore un demi-million de fois. Derrière ces requêtes, ce n'est presque jamais un responsable de transformation qui fait de la littérature comparative. C'est un CEO, un CIO, ou un administrateur qui essaie de comprendre, avant la réunion de la semaine prochaine, ce que son partenaire de conseil va réellement faire lundi matin — et si la saveur agile de la proposition est une vraie méthode, une vraie ingénierie, ou un simple relabeling du même slide « tribu Spotify » qui a gagné les trois derniers pitchs.
La réponse honnête est plus difficile à trouver qu'elle ne devrait l'être. La plupart des comparaisons publiques de frameworks sont écrites par les éditeurs de méthode eux-mêmes — Scaled Agile Inc. sur SAFe, la LeSS Company sur LeSS, Scrum Inc. sur Scrum@Scale — et ils gagnent tous l'argument qu'ils ont écrit. Les cabinets de conseil publient du thought leadership sur leurs propres offres sans admettre quelle méthode de base ils ont superposée, laquelle ils évitent discrètement, ou laquelle a produit un engagement depuis annulé. L'acheteur doit trianguler, en général sous pression de temps, entre un site de méthode qui veut des revenus de certification et un site de cabinet qui veut un contrat.
Ce texte est une référence de praticien, écrite du point de vue de l'acheteur. Le cadrage est le suivant : il existe huit frameworks agiles à l'échelle qui méritent d'être connus en 2026, et dix cabinets de conseil qui vendent des transformations agiles en volume. Chaque framework est un produit réel, avec un auteur réel, une théorie réelle de la mise à l'échelle, et une opinion réelle sur la pratique d'ingénierie. Chaque cabinet enveloppe un ou plusieurs de ces frameworks avec de l'IP brandée, une pile de certifications et un cas phare. Les questions intéressantes sont celles auxquelles les cabinets et les éditeurs de méthode sont les moins susceptibles de répondre eux-mêmes : où l'enveloppe ajoute une méthode réelle, où elle n'ajoute que du branding, où le cas phare nommé ressemble encore à lui-même cinq ans plus tard, et où les hypothèses d'ingénierie du framework tiennent toujours une fois qu'on tient compte des tailles d'équipe de l'ère IA.
Nous avons une préférence, et nous le disons d'emblée pour garder le reste du texte honnête. L'agile n'est pas le produit. L'agile est la couche de livraison sous chaque programme IA, digital et opérationnel qui doit continuer à livrer après la cérémonie de lancement. Le framework qui fait cela le mieux pour une organisation donnée est rarement celui à l'écosystème de certification le plus large ou à la marque la plus bruyante. C'est en général celui dont les hypothèses d'ingénierie, la forme de gouvernance et le point idéal de taille d'équipe correspondent au travail devant l'acheteur ce trimestre. Le choisir à tort est l'erreur la plus coûteuse des budgets de transformation, et celle qu'on attribue à la « culture » dans le post-mortem.
Ce qui suit est structuré pour qu'un CEO puisse le lire en quinze minutes et qu'un responsable de transformation puisse s'en servir comme référence de travail. La section 3 place les huit frameworks dans la chronologie qui les a produits, car rien de ce travail n'a de sens sans l'histoire. Les sections 4 et 5 comparent les frameworks et les cabinets côte à côte. La section 6 est le tableau que vous pouvez capturer d'écran. Les sections 7 et 8 disent ce qui est différent et ce qui est habillage. La section 10 vous donne l'arbre de décision côté acheteur. La section 11 dit où nous nous inscrivons.
Note de méthode
La date de référence de cette comparaison est le 14 mai 2026. Les guides de framework, les pages de capacité des cabinets et les bibliothèques de cas évoluent ; tout ce qui suit reflète l'état public à cette date. Les éditions suivantes conserveront l'édition précédente à une URL datée, afin que quiconque cite ce texte puisse épingler la version référencée.
Sources primaires pour les huit frameworks. Quand un framework a un livre canonique, le livre est la source primaire. SAFe : Dean Leffingwell, SAFe Reference Guide (Scaled Agile Inc., édition actuelle pour SAFe 6.0). LeSS : Craig Larman et Bas Vodde, Large-Scale Scrum: More with LeSS (Addison-Wesley, 2017), plus leur précédent Practices for Scaling Lean & Agile Development (2008). Scrum@Scale : Jeff Sutherland, The Scrum@Scale Guide plus Scrum: The Art of Doing Twice the Work in Half the Time (Sutherland et Sutherland, 2014). Spotify Model : Henrik Kniberg et Anders Ivarsson, « Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds » (2012), plus les vidéos Spotify Engineering Culture (Kniberg, 2014) et les rétrospectives ultérieures de Joakim Sundén et Marcin Floryan. Disciplined Agile : Scott Ambler et Mark Lines, Choose Your WoW! (PMI, édition actuelle). Nexus : Ken Schwaber et Scrum.org, The Nexus Guide. Kanban Maturity Model : David J. Anderson et Teodora Bozheva, Kanban Maturity Model (Lean Kanban Inc., 2018). FAST : Ron Quartel, The FAST Guide, plus des interventions communautaires.
Sources primaires pour les dix cabinets. Chaque cabinet est sourcé à partir de ses propres pages de capacité publiées, livres blancs et communiqués de presse à la date de référence, plus — quand ils existent — des cas phares publiquement nommés. Quand un cabinet est un SAFe Global Transformation Partner, l'annuaire public des partenaires est traité comme une source corroborante indépendante. Les données d'adoption à l'échelle du secteur proviennent du rapport annuel State of Agile (digital.ai) et des statistiques communautaires de Scrum.org. Nous évitons de citer des entretiens internes aux cabinets ; tout ce qui suit a une source publique.
Ce qui est dans le périmètre, et ce qui n'y est pas. Dedans : les frameworks avec un auteur nommé, une méthodologie publiée et une communauté de praticiens active au niveau équipe-d'équipes ou au-delà. Dedans : les cabinets qui publient une offre de transformation agile brandée et disposent d'un bench significatif de consultants certifiés ou spécialisés. Dehors : les frameworks purement au niveau équipe (Scrum, Extreme Programming, Kanban mono-équipe — ce sont des intrants des frameworks à l'échelle, pas leurs concurrents). Dehors : les certifications de coaching agile sans méthodologie de livraison sous-jacente. Dehors : les cabinets boutique de moins de cinquante consultants — la question de l'acheteur que sert ce texte porte sur les cabinets capables de mobiliser un programme d'entreprise.
Pourquoi huit frameworks, ni six ni douze. Six sous-estimerait le champ : omettre le Kanban Maturity Model et FAST effacerait les deux frameworks qui n'exigent explicitement aucune réorganisation de la structure d'équipe, exactement la situation que rencontrent beaucoup d'organisations post-fusion ou politiquement contraintes. Douze le surestimerait : la plupart des frameworks supplémentaires (Nexus+, Disciplined Agile Enterprise, enveloppes propres à un cabinet) sont des extensions ou des rebrandings des huit présentés ici. Les huit de ce texte ont soit un auteur nommé avec une méthode publiée et une communauté active, soit sont le seul actif brandé qu'un grand cabinet publie sous son propre nom.
Une brève histoire de l'agile à l'échelle (2001-2026)
Aucun des frameworks de cette comparaison n'a de sens sans l'histoire. L'agile à l'échelle est un argument vieux de vingt-cinq ans sur la façon de livrer du logiciel à une taille et un rythme que les auteurs originaux de l'Agile Manifesto n'ont jamais cherché à traiter, et presque chaque désaccord de la littérature actuelle se retrace à quelle année, quel problème et quelle culture d'ingénierie a produit le framework qui l'argumente.
2001 — Agile Manifesto. Dix-sept praticiens se réunissent à Snowbird, dans l'Utah, et publient quatre valeurs et douze principes. Chaque framework de ce texte en est, sous une forme ou une autre, un descendant. Fait crucial, le Manifesto est silencieux sur la coordination au-delà d'une seule équipe. Ce silence est le vide que le reste de cette histoire vient combler.
1994-1999 — la préhistoire. DSDM (Dynamic Systems Development Method) est publié en 1994 au Royaume-Uni, avec un récit de mise à l'échelle explicite pour la livraison à budget fixe. FDD (Feature-Driven Development) apparaît en 1997, issu du travail de Jeff De Luca à Singapour. RUP (Rational Unified Process) est finalisé chez Rational Software en 1998 et racheté par IBM en 2003, donnant aux grandes entreprises un processus itératif lourd qu'elles pouvaient acheter. Aucun de ces trois n'est « agile » au sens de la définition de 2001, mais ils prouvent que le même problème — la livraison coordonnée multi-équipe, multi-phase — était déjà en cours de résolution avant que le Manifesto ne nomme le système de valeurs.
2007-2010 — Scrum passe à l'échelle par accident. Scrum (Schwaber et Sutherland, formalisé dans les années 1990, popularisé après le Manifesto) devient la méthode dominante au niveau équipe. Les grandes organisations l'adoptent, atteignent la limite d'une seule équipe Scrum et commencent à inventer des solutions locales. Le motif « Scrum of Scrums » est documenté mais non gouverné. Les premières tentatives publiées de mise à l'échelle délibérée apparaissent dans cette période — Practices for Scaling Lean & Agile Development (2008) de Craig Larman et Bas Vodde est le premier traitement sérieux sous forme de livre.
2011 — SAFe 1.0. Dean Leffingwell publie le premier Scaled Agile Framework. C'est le premier framework agile à l'échelle qui ressemble à un produit achetable : rôles numérotés, cérémonies nommées (la plus célèbre étant le PI Planning), une couche portfolio au-dessus de la couche programme, et une pile de certifications. Les responsables de transformation d'entreprise, qui peinaient à faire correspondre le Scrum de niveau équipe à la gouvernance de niveau programme, ont enfin quelque chose à mettre sur un slide. Scaled Agile Inc. est fondée la même année. À partir de ce moment, chaque autre framework du champ se définit en partie par où il rejoint ou rejette SAFe.
2012-2014 — Spotify et LeSS. Henrik Kniberg et Anders Ivarsson publient « Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds » en 2012. C'est un livre blanc, pas un framework. Le vocabulaire — tribus, squads, chapters, guilds — se répand plus vite qu'aucun framework avant ou depuis. En 2014, Kniberg publie les vidéos Spotify Engineering Culture. La même année, Larman et Vodde lancent publiquement le framework LeSS sur less.works, le positionnant explicitement comme « Scrum avec les règles nécessaires pour le mettre à l'échelle » — une contre-position délibérée face à la densité de rôles et de cérémonies de SAFe.
2014-2015 — Scrum@Scale et Disciplined Agile. Jeff Sutherland publie Scrum@Scale, conservant le minimalisme originel de Scrum au cœur et ajoutant deux cycles de coordination (le cycle Scrum Master et le cycle Product Owner). Scott Ambler et Mark Lines, initialement chez IBM, publient Disciplined Agile Delivery comme alternative de type toolkit prenant en charge des cycles de vie plan-driven, agile et lean au sein du même programme — une accommodation délibérée pour les entreprises incapables d'adopter une philosophie de livraison unique.
2015-2016 — Nexus. Ken Schwaber et Scrum.org lancent Nexus comme l'option « Scrum, juste un peu plus grand » : un exosquelette pour trois à neuf équipes Scrum partageant un produit, avec une Nexus Integration Team responsable de l'intégration inter-équipes. Surface de marque plus faible que SAFe ou LeSS, mais plus épurée pour les équipes déjà engagées dans l'écosystème Scrum.org.
2018 — Kanban Maturity Model et les Five Trademarks. David J. Anderson et Teodora Bozheva publient le Kanban Maturity Model, formalisant un catalogue de pratiques par paliers de maturité qui n'exige aucun changement de structure d'équipe — le premier framework explicitement conçu pour les organisations qui ne peuvent pas ou ne veulent pas se réorganiser. La même année, McKinsey publie « The five trademarks of agile organizations » (Bazigos, De Smet, Gagnon), donnant aux cabinets de conseil un diagnostic hors-framework qu'ils peuvent vendre en salle de conseil d'administration.
2017-2019 — FAST et le rachat de DAD par le PMI. Ron Quartel publie le framework FAST en 2017 — le plus radicalement flexible de l'ensemble, avec une formation d'équipe dynamique et sans Scrum Master. En 2019, le PMI rachète Disciplined Agile, donnant au framework une crédibilité d'entreprise et ralentissant sa vélocité de communauté ouverte dans des proportions à peu près égales.
2019-2022 — consolidation de SAFe, rétrospectives Spotify. SAFe gagne l'argument des industries régulées par défaut : c'est le seul framework avec des rôles nommés propices à l'audit, une certification, et un écosystème de partenaires Scaled Agile Inc. qui permet à un acheteur de mobiliser des consultants spécialisés à la demande. En parallèle, Joakim Sundén et d'autres de la période Spotify originelle publient des rétrospectives clarifiant que le « Spotify Model » a toujours été un instantané, jamais un modèle — et que Spotify elle-même a depuis longtemps dépassé ces diagrammes.
2023-2026 — pression de l'ère IA. L'IA générative comprime la taille des équipes. Des charges de travail qui nécessitaient une tribu de quatre-vingts personnes en 2018 peuvent être livrées par huit à quinze personnes grâce au platform engineering et au développement assisté par IA. Le platform engineering remplace certaines cérémonies de coordination par des plateformes internes pour développeurs. Les frameworks sous pression structurelle sont ceux bâtis pour des programmes lourds en effectifs ; les frameworks qui gagnent discrètement du terrain sont ceux qui redescendent en échelle proprement (FAST, KMM, LeSS) ou qui survivent à une coupe d'effectifs sans perdre leur identité.
Voilà le canon. Les huit frameworks comparés dans la section suivante sont les huit qui ont survécu à cet argument de vingt-cinq ans avec une méthode publiée, un auteur nommé, et une communauté active en 2026. Tout le reste est soit une méthode de niveau équipe (hors périmètre), soit l'enveloppe d'un éditeur autour de l'un de ces huit (section 5), soit une idée qui n'a pas survécu au contact des budgets d'entreprise.
Huit frameworks, huit cadrages
Chaque méthode est un produit à part entière, avec son propre auteur, ses propres hypothèses sur la mise à l'échelle et sa propre théorie de la place de la pratique d'ingénierie logicielle. L'ordre ci-dessous suit à peu près le poids d'adoption dans les engagements de conseil en entreprise, pas la qualité.
Avant les cadrages, la filiation — car une grande partie de la variété apparente s'effondre dès qu'on voit d'où vient chaque méthode. Cinq des huit sont des extensions de Scrum, une descend de la Kanban Method, et deux ont des racines indépendantes. Cette lignée est la chose la plus utile à garder en tête en lisant le reste de cette section : quand un framework paraît peu familier, se demander « qu'est-ce qu'il met à l'échelle, et de quelle tradition vient-il ? » explique en général sa forme.
1. SAFe — Scaled Agile Framework
Auteur / origine : Dean Leffingwell, première publication en 2011, SAFe 6.0 en vigueur depuis 2023. Détenu et déposé par Scaled Agile Inc.
Hypothèse d'échelle : Construit autour de l'Agile Release Train (ART) de 50 à 125 personnes. Les configurations Large Solution et Portfolio étendent la coordination à des programmes multi-ART de plusieurs milliers de personnes. Conçu de haut en bas pour s'adapter aux entreprises, pas de bas en haut à partir du Scrum de niveau équipe.
Prescriptif ou flexible : Le framework le plus prescriptif de cette comparaison. Rôles nommés (RTE, Product Manager, Solution Train Engineer, System Architect, Business Owner, Release Train Engineer, plus le Scrum Master et le Product Owner au niveau équipe). Cadences nommées (le PI — Program Increment — en général 8 à 12 semaines). Cérémonies nommées (PI Planning, System Demo, Inspect & Adapt). Artefacts nommés (Programme Backlog, Solution Backlog, Portfolio Kanban).
Forme de gouvernance : Hiérarchique — Portfolio → Large Solution → Essential (ART) → Équipe. Couche Portfolio Lean Budgeting avec Strategic Themes et Value Streams. Propice à l'audit : chaque rôle, cérémonie et décision peut être tracé.
Profondeur d'ingénierie logicielle : DevOps et le Continuous Delivery Pipeline sont des piliers nommés de premier plan. Built-In Quality, Test-First et les pratiques XP sous-jacentes sont explicitement référencées. En pratique, la profondeur d'ingénierie dépend presque entièrement du SPC (SAFe Programme Consultant) qui pilote la mise en œuvre ; l'adoption des cérémonies dépasse généralement l'adoption de l'ingénierie.
Là où il excelle : Les industries régulées (banques, pharma, défense) qui ont besoin d'une gouvernance traçable pour l'audit. Les grandes entreprises dotées de bureaux de gestion de programme matures qui pensent déjà en rôles et cérémonies. Les contextes de livraison multi-fournisseurs où une cadence partagée et des rôles de coordination nommés réduisent le risque d'intégration.
Là où il est mal appliqué : Les petites organisations qui adoptent le framework complet parce que le parcours de certification l'a rendu visible. Le théâtre du PI Planning — la cérémonie de deux jours adoptée comme rituel sans la pratique d'ingénierie sous-jacente qui rend les douze semaines suivantes livrables. Le Portfolio Kanban comme artefact de justification budgétaire plutôt que comme outil de flux. Tout déploiement où le SPC n'a jamais écrit de code de production.
Ambiance générale : Le framework qui a pris de l'échelle parce qu'il a survécu à l'examen des entreprises. Adoré par les responsables de transformation car chaque conversation qu'ils doivent avoir avec un conseil d'administration a un artefact SAFe nommé derrière elle. Suspecté par les ingénieurs seniors car cette même conversation se connecte rarement à un pipeline de CI. L'écart le plus courant entre le diagramme SAFe au mur et la pratique d'ingénierie dans l'IDE.
Sources : Leffingwell, SAFe Reference Guide (Scaled Agile Inc.) · scaledagileframework.com · Annuaire des partenaires Scaled Agile Inc. · State of Agile Report (digital.ai, annuel)
2. LeSS — Large-Scale Scrum
Auteur / origine : Craig Larman et Bas Vodde, issu de leur travail chez Nokia Siemens Networks au milieu des années 2000. Premier livre Practices for Scaling Lean & Agile Development (2008) ; le framework LeSS formalisé sur less.works en 2014 ; Large-Scale Scrum: More with LeSS (2017) en est le texte canonique.
Hypothèse d'échelle : Un produit, un Product Owner, un Product Backlog. LeSS proprement dit couvre 2 à 8 équipes. LeSS Huge couvre 8 équipes et plus, organisées en Requirement Areas ayant chacune un Area Product Owner. L'hypothèse du produit unique est l'engagement central du framework et sa contrainte la plus dure à tenir.
Prescriptif ou flexible : Minimaliste par conception. Le slogan est « Scrum appliqué à plusieurs équipes travaillant ensemble sur un produit », avec seulement les règles supplémentaires nécessaires pour que cela fonctionne — pas une couche programme parallèle. Moins de rôles nommés, moins d'événements nommés, aucune surcouche portfolio.
Forme de gouvernance : Délibérément plate. Un seul Product Owner pour toutes les équipes (ou un Area PO par Requirement Area dans LeSS Huge). Aucune couche programme séparée. Aucun équivalent au Release Train Engineer. La coordination inter-équipes passe par le Multi-Team PBR, l'Overall Retrospective et des motifs de component-mentor / travelling-engineer, pas par un rôle hiérarchique.
Profondeur d'ingénierie logicielle : Parmi les plus élevées des huit. L'intégration continue est non négociable. Le framework exige explicitement l'excellence technique : refactoring, conception simple, développement piloté par les tests et propriété partagée du code sont traités comme des préconditions, pas des aspirations. Larman et Vodde ont beaucoup écrit sur les pratiques d'ingénierie que LeSS présuppose.
Là où il excelle : Les organisations mono-produit dont la culture d'ingénierie est déjà encline à aplatir la hiérarchie. Les éditeurs de logiciels, les équipes plateforme au sein de plus grandes entreprises, les organisations prêtes à démanteler les silos de component-team et fonctionnels au profit d'équipes feature.
Là où il est mal appliqué : Les portefeuilles multi-produits qui essaient de forcer l'hypothèse du PO unique. Les industries régulées où l'audit attend des rôles de conformité nommés que LeSS ne fournit pas. Les organisations qui adoptent la structure mais sautent les préconditions d'ingénierie — LeSS sans intégration continue n'est que du Scrum avec des rétros en plus.
Ambiance générale : Le framework que les ingénieurs respectent. Le framework que les responsables de transformation trouvent le plus dur à vendre à un conseil d'administration car il offre moins d'artefacts reconnaissables comme marque que SAFe. Celui qui donne les meilleurs résultats entre les mains d'un leadership technique fort, et les pires quand il est imposé à une organisation qui n'a pas encore acquis la discipline d'ingénierie qu'il présuppose.
Sources : Larman et Vodde, Large-Scale Scrum: More with LeSS (Addison-Wesley, 2017) · less.works · Certification LeSS Company (CLP, CLT) · Larman et Vodde, Practices for Scaling Lean & Agile Development (2008)
3. Scrum@Scale
Auteur / origine : Jeff Sutherland (co-créateur de Scrum avec Ken Schwaber), fondateur de Scrum Inc. Publié en 2014, Scrum@Scale Guide version 3.0 en vigueur (2022). Bâti sur le Scrum Guide sous-jacent co-écrit par Sutherland et Schwaber.
Hypothèse d'échelle : Modulaire et récursive. Cinq équipes forment un Scrum of Scrums (SoS) ; cinq SoS forment un Scrum of Scrums of Scrums ; et ainsi de suite. Aucune limite dure de nombre d'équipes. L'Executive MetaScrum siège au sommet comme forum stratégique de priorisation. Le framework est construit pour passer à l'échelle en répétant le même motif à des niveaux supérieurs, plutôt qu'en introduisant de nouvelles couches avec de nouveaux rôles à chaque niveau.
Prescriptif ou flexible : Noyau minimal, accrétion modulaire. Les seuls rôles requis sont les rôles Scrum standards (Scrum Master, Product Owner, Developer). Tous les composants additionnels — le SoS, le SoSoS, l'Executive Action Team, l'Executive MetaScrum — ne sont ajoutés que si l'organisation en a besoin. Plus proche d'un méta-framework que d'une implémentation unique prescrite.
Forme de gouvernance : Deux cycles parallèles. Le cycle Scrum Master traite le « comment » — levée des obstacles, amélioration continue, coordination inter-équipes. Le cycle Product Owner traite le « quoi » — priorisation du backlog, vision stratégique, retour client. Chaque cycle a sa propre cadence de réunions et son propre responsable.
Profondeur d'ingénierie logicielle : Guidance explicite légère dans le framework lui-même. Les livres de Sutherland et les formations Scrum Inc. portent un contenu de pratique d'ingénierie fort, mais le guide du framework n'impose pas de pratiques spécifiques. En pratique, cela signifie que la profondeur d'ingénierie dépend du formateur ou consultant certifié Scrum Inc. qui pilote la mise en œuvre.
Là où il excelle : Les organisations qui font déjà tourner Scrum efficacement au niveau équipe et ont besoin de coordination au niveau multi-équipe sans hériter d'une surcouche de niveau SAFe. Les entreprises technologiques du mid-market. Les organisations à direction d'ingénierie qui veulent préserver leur culture Scrum existante pendant la montée en échelle.
Là où il est mal appliqué : Les organisations qui confondent minimalisme et ambiguïté et abandonnent le framework avant que les composants modulaires ne se stabilisent. Les programmes de transformation qui attendent de la prescription et trouvent l'optionnalité de Scrum@Scale déstabilisante. Les mises en œuvre qui adoptent le motif SoS sans le cycle Product Owner correspondant, produisant une surcharge de coordination sans alignement stratégique.
Ambiance générale : Le nom de Sutherland pèse énormément. Le framework a une communauté ouverte plus petite que SAFe ou LeSS mais une forte concentration de consultants formés par Scrum Inc. sur le terrain. Le framework le plus souvent cité quand une organisation dit « nous voulons mettre à l'échelle notre Scrum de niveau équipe sans le rebrander ». Moins de surface de marque que SAFe ; structure conceptuelle plus épurée que LeSS Huge.
Sources : scrumatscale.com · The Scrum@Scale Guide v3.0 (Scrum Inc., 2022) · Sutherland et Sutherland, Scrum: The Art of Doing Twice the Work in Half the Time (Random House, 2014) · Certification Scrum Inc. (SSM, SPS)
4. Spotify Model
Auteur / origine : Henrik Kniberg et Anders Ivarsson, « Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds » (2012). Suivi des vidéos Spotify Engineering Culture de Kniberg (Part 1 et Part 2, 2014). Jamais publié comme framework officiel par Spotify ; les papiers originaux décrivent ce que Spotify faisait à l'époque, avec des avertissements explicites que le modèle continuerait d'évoluer. Les rétrospectives ultérieures (Joakim Sundén 2017, Marcin Floryan et d'autres) ont répété que Spotify elle-même avait dépassé ces diagrammes en un an ou deux.
Hypothèse d'échelle : Des squads typiquement de 6 à 12 personnes, transverses, autonomes. Les tribes regroupent des squads liés, plafonnées (chez Spotify) à environ 100 personnes pour préserver un sentiment d'appartenance. Les chapters traversent les tribes par discipline (ingénierie, design, données). Les guilds sont des groupes d'intérêt volontaires qui traversent toute l'organisation.
Prescriptif ou flexible : Culturellement prescriptif, structurellement suggestif. Les prescriptions culturelles — autonomie avec alignement, confiance plutôt que contrôle, « faiblement couplé, fortement aligné » — sont concrètes et exigeantes. Les éléments structurels (tribes, squads, chapters, guilds) décrivent ce que Spotify faisait, sans être imposés comme un framework à adopter à la lettre par n'importe qui d'autre.
Forme de gouvernance : Matricielle. Les tribes possèdent les résultats produit et les roadmaps. Les chapters possèdent les standards de discipline et la gestion des personnes pour leurs membres. Les guilds possèdent des sujets transverses par intérêt. Fait crucial, la gouvernance Spotify présupposait une fonction produit forte et une plateforme d'ingénierie solide — ni l'une ni l'autre nommée explicitement dans les diagrammes, toutes deux essentielles en pratique.
Profondeur d'ingénierie logicielle : Implicite, non spécifiée. Le modèle présuppose une culture d'ingénierie forte : développement trunk-based, déploiement continu, plateformes internes, et une exigence élevée d'autonomie sans dérive architecturale. Les adopteurs qui copient l'organigramme sans la plateforme d'ingénierie obtiennent du chaos de coordination, pas de l'autonomie.
Là où il excelle : Les organisations technology-native, orientées produit, avec un investissement existant significatif dans le platform engineering et l'expérience développeur. Les organisations qui ont déjà acquis l'autonomie d'ingénierie que le modèle présuppose. Souvent, l'application la plus utile du Spotify Model est comme vocabulaire pour des organisations qui fonctionnent déjà ainsi et ont besoin de mots pour ce qu'elles font.
Là où il est mal appliqué : Le mode d'échec dominant. Les organisations copient l'organigramme — tribes, squads, chapters — sans la culture d'ingénierie, la fonction produit, ou l'investissement plateforme qui faisaient fonctionner la structure. Elles obtiennent le diagramme, pas les résultats. Les propres rétrospectives de Spotify sont explicites : le modèle était un instantané, l'instantané est daté, et le traiter comme une architecture cible est une erreur.
Ambiance générale : L'artefact le plus influent, le moins implémentable du champ. Le framework que les gens citent quand ils veulent dire « nous voulons être plus comme Spotify » — ce qui signifie presque toujours qu'ils ont lu le diagramme mais pas les articles d'ingénierie. Utile comme vocabulaire, dangereux comme modèle à suivre. Le signe le plus clair qu'une organisation a lu au-delà du diagramme : elle se réfère aux rétrospectives post-2017, pas seulement au papier de 2012.
Sources : Kniberg et Ivarsson, « Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds » (2012) · Kniberg, « Spotify Engineering Culture » (Spotify Labs, 2014) · Sundén, « There is no Spotify Model » (2017) · Floryan et d'autres, rétrospectives Spotify ultérieures
5. Disciplined Agile (DA / DAD)
Auteur / origine : Scott Ambler et Mark Lines, développé à l'origine chez IBM Rational à partir de 2009 environ. Publié sous forme de livre en tant que Disciplined Agile Delivery (DAD) en 2012, étendu au toolkit Disciplined Agile (DA) plus large couvrant les enjeux de niveau entreprise. Racheté par le Project Management Institute (PMI) en 2019, donnant au PMI un actif agile crédible et à DA une distribution d'entreprise. Choose Your WoW! (Ambler et Lines, édition actuelle sous PMI) en est le texte canonique.
Hypothèse d'échelle : Un toolkit plutôt qu'un framework unique prescrit. DA prend en charge quatre cycles de vie au sein d'un même programme : agile (basé sur Scrum), lean (flux continu), exploratoire (lean-startup), et traditionnel (plan-driven). Les équipes choisissent le cycle de vie adapté à leur contexte et le toolkit guide le choix avec des diagrammes d'objectifs.
Prescriptif ou flexible : Piloté par le choix, orienté objectifs. Plutôt que de prescrire des pratiques spécifiques, DA définit des objectifs de processus (« Former l'équipe », « Traiter le risque », « Coordonner les activités ») et présente les options de pratique pour atteindre chaque objectif avec leurs compromis. Le framework est délibérément agnostique sur la pratique correcte, exigeant à la place que les équipes choisissent explicitement.
Forme de gouvernance : Pluraliste par conception. Le toolkit accueille livraison traditionnelle et agile dans le même programme — une concession délibérée aux entreprises avec des flux de travail régulés, des projets gérés par des fournisseurs, et des équipes produit purement agiles fonctionnant en parallèle.
Profondeur d'ingénierie logicielle : Large plutôt que profonde. Le toolkit inclut DevOps, sécurité, architecture, gestion des données et opérations comme domaines d'objectifs nommés. Le compromis est que DA couvre plus de sujets qu'aucun framework unique mais va moins profond sur les pratiques d'ingénierie de chacun.
Là où il excelle : Les organisations aux contextes de livraison mixtes — certaines équipes ont besoin de discipline plan-driven, d'autres mènent des expériences lean-startup, d'autres livrent du produit sur Scrum, le tout sous un seul programme. Les environnements de gouvernance alignés PMI où des chefs de programme formés PMP ont besoin d'un chemin vers l'agile qui respecte leurs certifications existantes. Les intégrations post-fusion où deux cultures de livraison doivent coexister sans que l'une soit subordonnée à l'autre.
Là où il est mal appliqué : Les petites organisations submergées par l'ampleur du toolkit, qui auraient été mieux servies par un seul framework prescrit. Les organisations qui lisent « PMI » sur la couverture et traitent DA comme de « l'agile pour boutiques PMP » plutôt que comme le toolkit qu'il est. Les mises en œuvre qui utilisent la flexibilité de DA comme prétexte pour ne jamais faire de choix.
Ambiance générale : Sous-aimé au regard de son périmètre. La propriété du PMI a donné au framework une crédibilité d'entreprise mais a ralenti la vélocité de la communauté ; les conférences sont plus discrètes que celles de SAFe ou de LeSS, les contributions ouvertes plus minces. Le framework le plus susceptible de faire un vrai travail dans les environnements régulés et de portefeuille mixte, et le moins susceptible d'être la réponse quand une organisation dit qu'elle veut « passer à l'agile ».
Sources : Ambler et Lines, Choose Your WoW! (PMI) · pmi.org/disciplined-agile · Filière de certification PMI DA (DAC, DASM, DAVSC) · Ambler et Lines, Disciplined Agile Delivery (IBM Press, 2012)
6. Nexus
Auteur / origine : Ken Schwaber (co-créateur de Scrum) et Scrum.org. Le Nexus Framework a été publié pour la première fois en 2015 et affiné dans les mises à jour ultérieures du Nexus Guide, la version actuelle couvrant la pratique évoluée de Scrum.org. Conçu explicitement pour être l'extension minimale viable de Scrum à plusieurs équipes sur un seul produit.
Hypothèse d'échelle : Trois à neuf équipes Scrum travaillant à partir d'un seul Product Backlog sur un incrément de produit intégré. Au-delà de neuf équipes, les auteurs du framework recommandent soit de restructurer en plusieurs instances Nexus, soit d'envisager un autre framework.
Prescriptif ou flexible : Étroit dans son périmètre, prescriptif au sein de ce périmètre. Nexus n'ajoute que le strict nécessaire pour faire fonctionner Scrum multi-équipe : une Nexus Integration Team (une unité de travail, pas une hiérarchie de rôles séparée), des événements de niveau Nexus qui encadrent les événements Scrum de niveau équipe, et un Nexus Sprint Goal qui tient l'incrément ensemble. Rien d'autre ne change.
Forme de gouvernance : Centrée sur l'équipe d'intégration. La Nexus Integration Team est responsable de l'incrément intégré et du coaching des équipes Scrum sur les pratiques d'ingénierie qui rendent l'intégration possible. Les dépendances inter-équipes sont mises en évidence et traitées lors du Nexus Sprint Planning plutôt que laissées à une coordination ad hoc.
Profondeur d'ingénierie logicielle : Explicite sur la discipline d'intégration. La Definition of Done au niveau Nexus impose des pratiques d'ingénierie — intégration continue, tests d'intégration, outillage partagé — faciles à sauter au niveau équipe. En pratique, c'est là que Nexus livre sa valeur : en faisant de la discipline d'intégration une exigence structurelle, pas une aspiration de coaching.
Là où il excelle : Les organisations mono-produit de trois à neuf équipes qui pratiquent déjà Scrum efficacement et veulent le changement de processus minimal requis pour passer à l'échelle. Les organisations produit à direction d'ingénierie engagées dans l'écosystème Scrum.org. Les mises en œuvre qui préfèrent un framework bien intégré à une surcouche de portefeuille.
Là où il est mal appliqué : Les organisations à dix équipes ou plus qui adoptent Nexus parce qu'elles le faisaient déjà tourner à neuf et n'ont pas pu se résoudre à changer. Les organisations aux fondations Scrum faibles au niveau équipe, où Nexus se contente d'élever les dysfonctionnements existants à une couche de coordination supérieure. Les portefeuilles multi-produits qui n'auraient pas dû être forcés sur un seul backlog.
Ambiance générale : L'option « Scrum, juste un peu plus grand ». Surface de marque plus faible que SAFe ou LeSS, avec un écosystème de consultants externes plus réduit. Chemin le plus épuré pour les organisations déjà dans la filière de formation Scrum.org qui veulent passer à l'échelle sans rebranding. Le framework le plus souvent oublié dans les débats de framework car il n'essaie pas de gagner ce débat — il essaie simplement de rester Scrum.
Sources : Schwaber et Scrum.org, The Nexus Guide · scrum.org/resources/nexus-guide · Certification Scrum.org Scaled Professional Scrum (SPS) · Études de cas communautaires Scrum.org
7. Kanban Maturity Model (KMM)
Auteur / origine : David J. Anderson et Teodora Bozheva, Kanban Maturity Model (Lean Kanban Inc., 2018 ; révisions ultérieures). Anderson est aussi l'auteur du livre fondateur Kanban (2010) qui a établi la Kanban Method dans la livraison logicielle. Distribué par Kanban University (anciennement Lean Kanban University) et le Mauvius Group.
Hypothèse d'échelle : S'applique aux niveaux équipe, livraison de service et entreprise. La maturité est étagée de 0 à 6 (sept stades : Oblivious, Emerging, Defined, Managed, Established, Optimising, Congruent), chaque niveau ajoutant des pratiques qui s'appuient sur le précédent. Le modèle est explicite sur le fait qu'il n'exige aucune réorganisation de la structure d'équipe pour démarrer — une organisation peut adopter KMM sans démanteler son organigramme existant.
Prescriptif ou flexible : Un catalogue de pratiques organisé par niveau de maturité, pas un processus unique prescrit. La prémisse centrale du framework — « commencez par ce que vous faites maintenant ; convenez de poursuivre un changement évolutif » — traite l'organisation existante comme point de départ et laisse l'adoption des pratiques suivre la capacité.
Forme de gouvernance : Basée sur le flux et orientée service. Le travail est traité comme un flux de demande contre une capacité. La gouvernance passe d'une pensée projet-et-ressources vers la livraison de service, les classes de service, et des politiques explicites pour traiter différents types de demande. Aucun changement de rôle requis — la structure organisationnelle existante reste en place.
Profondeur d'ingénierie logicielle : Agnostique. KMM se concentre sur le flux de travail, la gestion de la demande, les classes de service et les politiques ; il n'a pas d'avis tranché sur des pratiques d'ingénierie spécifiques. Les équipes riches en ingénierie gardent leurs pratiques ; les équipes légères en ingénierie n'y sont pas forcées par le framework.
Là où il excelle : Les organisations à forte composante opérations et livraison de service — opérations IT, équipes infrastructure, support, travail sur processus régulés. Les organisations où la réorganisation est politiquement ou pratiquement impossible. Les ateliers d'ingénierie matures qui ont déjà rejeté la densité de cérémonies de Scrum et veulent une amélioration structurelle sans perdre leur flux existant.
Là où il est mal appliqué : Les acheteurs orientés produit qui attendent des prescriptions de structure d'équipe et trouvent la posture évolutive de KMM frustrante. Les mises en œuvre qui réduisent le framework à « mettre un tableau Kanban au mur » sans adopter les limites de WIP, les classes de service, ou la progression de pratiques étagée par maturité. Les organisations qui adoptent KMM comme excuse pour éviter le travail organisationnel plus difficile.
Ambiance générale : Le framework vers lequel se tournent les consultants quand une organisation a rejeté Scrum mais a encore besoin d'une amélioration structurelle. Motif d'adoption discret et durable : moins de cas phares que SAFe, surface de marque plus faible, mais forte rétention une fois adopté. Le framework le moins discuté de cette comparaison et l'un des plus utiles dans le bon contexte organisationnel.
Sources : Anderson et Bozheva, Kanban Maturity Model (Lean Kanban Inc., 2018) · kanbanmaturitymodel.com · Certification Kanban University (KMP, KCP) · Anderson, Kanban: Successful Evolutionary Change for Your Technology Business (Blue Hole Press, 2010)
8. FAST — Fluid Agile Scaling Technology
Auteur / origine : Ron Quartel, formulé à l'origine en 2017 à partir de son travail antérieur avec des équipes agiles auto-organisées à l'échelle. Documenté dans le FAST Guide, affiné par des révisions ultérieures et des contributions communautaires sur fastagile.io. Le framework s'appuie sur les principes de l'Open Space Technology pour l'auto-organisation et les applique dans un contexte de livraison logicielle.
Hypothèse d'échelle : Une « tribu » typiquement de 30 à 150 personnes. Fait crucial, les équipes ne sont pas fixes. Au début de chaque courte itération (typiquement de deux jours à une semaine), les membres de la tribu s'auto-organisent autour des éléments de travail qui les intéressent, forment des équipes pour cette itération, et se dissolvent à la fin. Les équipes Scrum fixes à composition stable n'existent pas.
Prescriptif ou flexible : Radicalement flexible. Pas de Scrum Master fixe. Pas de Product Owner fixe. Pas de composition d'équipe fixe. Les prescriptions structurelles sont minimales : une réunion de tribu au début de chaque cycle, un marché où le travail est proposé et pris en charge, et des flux de travail légers pour maintenir la continuité entre cycles pour les sujets de plus longue durée.
Forme de gouvernance : Auto-organisée et basée sur le marché. La demande apparaît à la réunion de tribu ; les personnes choisissent sur quoi travailler ; des stewards de flux de travail maintiennent la continuité pour les éléments qui s'étendent sur plusieurs cycles. Le modèle repose sur la responsabilité collective et une surface transparente plutôt que sur une autorité fondée sur des rôles nommés.
Profondeur d'ingénierie logicielle : Présuppose une culture d'ingénierie mature. Aucune compensation intégrée pour une fondation technique faible. Sans développement trunk-based, intégration continue, couverture de tests complète et propriété partagée du code, le modèle d'équipe fluide produit du chaos plutôt que de l'autonomie. FAST ne pardonne pas les raccourcis d'ingénierie d'une façon que les frameworks plus structurés ne partagent pas.
Là où il excelle : Les organisations technologiquement matures, à forte confiance, prêtes à dissoudre l'identité d'équipe fixe au profit d'une collaboration fluide. Les groupes de recherche, les équipes platform engineering, les organisations produit avancées où le travail est intrinsèquement variable. Les organisations où la culture d'ingénierie existante est assez forte pour absorber la perte de structure de niveau équipe.
Là où il est mal appliqué : Les organisations qui manquent de la discipline d'ingénierie que FAST présuppose — sans intégration continue et une base de tests solide, le remaniement quotidien du framework devient de l'extinction d'incendies quotidienne. Les organisations avec des engagements externes ou des dates de livraison fermes qui ont besoin de la prévisibilité que fournissent des équipes fixes. Les programmes avec des exigences réglementaires de responsabilité individuelle nommée.
Ambiance générale : L'outsider. Presque inconnu des acheteurs corporate, occasionnellement cité par des ingénieurs seniors comme le plus authentiquement agile des frameworks à l'échelle. Le framework le plus susceptible d'être évoqué dans une conversation d'ingénierie senior sur « ce qui marcherait vraiment si nous n'avions pas à rentrer dans un modèle de procurement ». Influent bien au-delà de son empreinte d'adoption — des idées de FAST apparaissent dans les trajectoires d'évolution d'autres frameworks.
Sources : Quartel, The FAST Guide (fastagile.io) · fastagile.io · Interventions communautaires et études de cas FAST · Matériel d'origine de l'Open Space Technology (Owen, 1997)
Comment les grands cabinets les packagent
Les dix cabinets ci-dessous livrent des transformations agiles en volume. Chacun a une offre nommée, un récit de packaging, et (le plus souvent) un cas phare nommé. Le motif : une méthode de base (en général SAFe, parfois LeSS ou d'inspiration Spotify), plus les enveloppes signature du cabinet (plateformes nommées, accélérateurs, formation), plus l'accès à des talents mondiaux. Les différences vivent dans les enveloppes.
BCG
Offre nommée : Agile at Scale, situé sous les practices People & Organization et Business Transformation. Le diagnostic signature est « Agile Performance Management ».
Méthodes superposées : Les structures de tribes et squads d'inspiration Spotify forment le motif dominant dans les cas agiles publiés de BCG. Les motifs de coordination SAFe apparaissent dans les engagements en industries régulées. La propre surcouche de gouvernance de portefeuille de BCG se pose sur quelle que soit la méthode de base utilisée dans l'engagement.
IP signature : BCG Agile Diagnostic, le framework Agile Performance Management, la série de benchmarks « Build for the Future ». BCG X — l'unité de construction technologique fusionnée formée en 2022 à partir de BCG GAMMA, BCG Platinion et BCG Digital Ventures — fournit le volet ingénierie des grandes transformations.
Cas phare nommé : La transformation « d'inspiration Spotify » d'ING Bank en 2015-2018 est le cas agile public le plus cité de BCG (narré conjointement avec McKinsey, dont l'implication est également documentée publiquement). Roche et plusieurs grandes banques européennes figurent dans la bibliothèque de cas de BCG.
Formation/certification : Académies internes BCG pour les consultants. Aucune filière de certification publique. BCG X porte en interne une formation spécifique à l'ingénierie.
Ambiance de positionnement : Stratégie d'abord. L'agile est positionné comme une transformation d'operating model possédée au niveau C-suite, la pratique d'ingénierie étant un enjeu en aval géré par BCG X ou par les équipes d'ingénierie du client. Conceptuellement adjacent à la thèse plus large « 10-20-70 » de BCG issue de l'article IA — l'agile livre les 70 (personnes, processus, changement).
Sources : page de capacité BCG.com agile-at-scale, publications Agile Performance Management, couverture de la transformation ING (BCG et tiers). Date de référence à épingler lors de la session de recherche ; les pages des cabinets sont mises à jour fréquemment.
McKinsey & Company
Offre nommée : Transformation agile au sein de la practice People & Organizational Performance, ancrée par le diagnostic « Five Trademarks of Agile Organizations ». Les publications adjacentes McKinsey Quarterly et McKinsey Insights servent de couche d'IP publique.
Méthodes superposées : Des structures d'inspiration Spotify apparaissent dans les travaux de cas publiés de McKinsey. Une coordination de motif SAFe dans les engagements en industries régulées. La propre surcouche de conception organisationnelle de McKinsey (Org Health Index, Influence Model) traverse le travail de livraison agile.
IP signature : « The five trademarks of agile organizations » (Bazigos, De Smet, Gagnon, 2018) est l'actif publié dominant — les cinq étant une North Star incarnée dans toute l'organisation, un réseau d'équipes responsabilisées, des cycles de décision et d'apprentissage rapides, un modèle de personnes dynamique, et une technologie habilitante de nouvelle génération. Les essais Agile Performance Management et le diagnostic agile Org Health Index complètent l'IP publique.
Cas phare nommé : La transformation d'ING Bank en 2015-2018 (co-narrée publiquement avec BCG). La transformation agile R&D de Roche. Plusieurs transformations bancaires asiatiques et européennes citées dans McKinsey Quarterly. Le cas ING rédigé par McKinsey est la transformation agile la plus citée de la littérature business.
Formation/certification : Réseau interne de praticiens McKinsey. Aucune filière de certification publique. Le programme de formation McKinsey Forward (développement du leadership plus large) inclut du contenu agile.
Ambiance de positionnement : L'agile comme problème de conception organisationnelle. Poids sur les diagnostics, les enquêtes et le changement d'operating model plutôt que sur la pratique d'ingénierie. Le cabinet le plus susceptible de mener une conversation au niveau conseil d'administration sur la transformation agile, et le moins susceptible d'être dans la salle quand le pipeline de CI se configure.
Sources : Bazigos, De Smet, Gagnon, « The five trademarks of agile organizations » (McKinsey, 2018) · articles agiles de McKinsey Quarterly (Aghina, De Smet, autres, plusieurs années) · études de cas McKinsey sur ING Bank. Date de référence à épingler lors de la recherche.
Deloitte
Offre nommée : Agile@Scale (également référencé comme « Agile at Scale » sur diverses propriétés Deloitte), soutenu par un diagnostic Agile Maturity Model et l'Agile Transformation Playbook.
Méthodes superposées : SAFe est la méthode de base dominante — Deloitte est un Scaled Agile Inc. Global Transformation Partner au niveau le plus élevé de l'écosystème de partenaires. Des structures LeSS et d'inspiration Spotify apparaissent là où le contexte s'y prête, en particulier dans les engagements à orientation produit. Scrum au niveau équipe tout du long.
IP signature : Agile Maturity Model, Agile Transformation Playbook, accélérateurs du partenariat SAFe, pages de capacité Agile@Scale. Adjacent : le framework Trustworthy AI (sept dimensions, issu de l'article IA) partage l'ADN de gouvernance avec l'approche de gouvernance agile de Deloitte.
Cas phare nommé : Transformations dans le secteur public et les services financiers à travers les géographies US, UK et européennes. Les cas nommés spécifiques varient selon le cabinet membre Deloitte ; cas phare à confirmer lors de la prise de référence.
Formation/certification : Parmi les plus grands benchs de consultants certifiés SAFe du secteur. Deloitte Agile Academy interne. Partenariat PMI Disciplined Agile pour les programmes hybrides.
Ambiance de positionnement : Aligné SAFe, propice à la gouvernance, prêt pour l'audit. Le cabinet à retenir quand les régulateurs sont dans la salle et que la transformation doit survivre à une revue de conformité. Moins de profondeur d'ingénierie produit que Capgemini ou IBM ; plus de profondeur de gouvernance de programme que McKinsey ou Bain.
Sources : pages de capacité Deloitte.com Agile@Scale · annuaire des Global Transformation Partners de Scaled Agile Inc. · publications agiles Deloitte Insights · articles régionaux sur l'Agile Maturity Model. Date de référence à épingler lors de la recherche.
EY (et EY-Parthenon)
Offre nommée : Business Agility (également référencé comme « Agile Business Reinvention » sur diverses propriétés EY), positionné au sein du framework plus large Transformation Realized.
Méthodes superposées : Aligné SAFe dans la majorité des cas publics. Scrum au niveau équipe. La surcouche de conduite du changement « transformation activation » d'EY traverse la livraison agile.
IP signature : Le framework Transformation Realized (la méthodologie de transformation globale d'EY, dans laquelle Business Agility s'insère comme modèle de livraison). Les studios de facilitation EY Wavespace pour les ateliers et les événements de planification de type PI. Adjacent : EY.ai et l'EYQ Agentic Platform (issus de l'article IA) — livraison agile par-dessus la pile IA d'EY pour les industries régulées.
Cas phare nommé : Transformations en industries régulées (services financiers, gouvernement, fiscalité). Les cas nommés spécifiques varient selon le cabinet membre EY et la confidentialité de l'engagement ; cas phare à confirmer lors de la prise de référence.
Formation/certification : Partenaire SAFe. Programme de facilitation interne EY Wavespace. Certifications de conduite du changement spécifiques à EY.
Ambiance de positionnement : Fortement axé transformation et changement. L'agile vit à l'intérieur d'un récit de changement plus large plutôt que de se tenir seul. Moins de profondeur d'ingénierie logicielle que Capgemini ou IBM ; plus de profondeur de conduite du changement et de gestion des parties prenantes que la plupart des pairs. Le cabinet à retenir quand la livraison agile est le moyen et la restructuration en industrie régulée la fin.
Sources : pages de capacité EY.com Business Agility et Transformation Realized · publications EY Wavespace · analyses stratégie et transformation d'EY-Parthenon. Date de référence à épingler lors de la recherche.
PwC
Offre nommée : Transformation agile positionnée au sein de la practice Business Transformation, fréquemment groupée avec les engagements de Digital Transformation. Le modèle opérant BXT (Business-Experience-Technology) de PwC sert d'architecture de transformation globale.
Méthodes superposées : SAFe et Scrum@Scale apparaissent dans les travaux de cas publiés de PwC. Scrum au niveau équipe. Le modèle BXT enveloppe quelle que soit la méthode agile de base utilisée dans l'engagement.
IP signature : Le modèle opérant BXT (l'IP de transformation la plus citée de PwC — il soutient que Business, Experience et Technology doivent être conçus et pilotés ensemble plutôt que transmis séquentiellement). L'évaluation Digital Fitness. Adjacent : ChatPwC, le déploiement ChatGPT Enterprise à ~200 000 sièges (issu de l'article IA), est l'outil GenAI interne le plus mis à l'échelle de tous les cabinets de cette comparaison — les équipes de livraison agile livrent sur un lieu de travail saturé de GenAI.
Cas phare nommé : Déploiements agiles dans les services financiers à travers les marchés US, UK et européens. Cas phare à confirmer lors de la prise de référence ; la publication de cas agiles de PwC est de volume inférieur à celle des autres pairs du Big Four.
Formation/certification : Bench certifié SAFe. Programmes PwC Academy. Formation interne de facilitateurs BXT.
Ambiance de positionnement : Piloté par la conduite du changement. L'agile présenté comme une transformation comportementale d'entreprise plutôt qu'une pratique d'ingénierie logicielle. Méthodologie spécifiquement agile moins brandée que chez Deloitte ou Accenture — le travail agile de PwC se déroule à l'intérieur de Business Transformation plutôt que de constituer sa propre offre.
Sources : pages de capacité PwC.com Business Transformation et Digital Transformation · publications sur la méthodologie BXT · PwC Global CEO Survey (constats liés à l'agile). Date de référence à épingler lors de la recherche.
KPMG
Offre nommée : Transformation agile positionnée au sein du framework de capacité Connected Enterprise, souvent associée à KPMG Powered Enterprise (la méthodologie de transformation accélérée par le SaaS de KPMG).
Méthodes superposées : SAFe est la méthode de base dominante dans les engagements agiles publiés de KPMG. Scrum au niveau équipe. Connected Enterprise enveloppe la livraison agile avec l'évaluation du modèle de capacités de KPMG.
IP signature : Connected Enterprise (huit capacités fonctionnelles et client organisées pour la transformation de bout en bout), Powered Enterprise (accélérateurs de solutions SaaS préconfigurés pour l'ERP, les RH, la finance et les opérations), KPMG Lakehouse (le campus phare de formation et d'innovation du cabinet). Adjacent : le framework Trusted AI (10 piliers, issu de l'article IA) partage l'ADN de gouvernance avec l'approche de gouvernance agile de KPMG.
Cas phare nommé : Transformations dans les services financiers et le secteur public à travers le UK, les US et l'Asie-Pacifique. Cas phare nommé spécifique à confirmer lors de la prise de référence.
Formation/certification : Partenaire SAFe. KPMG Lakehouse (Orlando, Floride, et d'autres campus) fournit une formation immersive pour les consultants comme pour les équipes client.
Ambiance de positionnement : Piloté par le modèle de capacités. L'agile se situe à l'intérieur d'un framework de capacités plus large plutôt que d'en être la pièce centrale. L'ADN d'audit de KPMG se prolonge dans la conception de la gouvernance agile — le cabinet à retenir quand la transformation agile doit produire des artefacts de gouvernance traçables et auditables. L'adjacence au « first claim » ISO/IEC 42001 (issu de l'article IA) renforce la posture de gouvernance.
Sources : pages de capacité KPMG.com agile-transformation et Connected Enterprise · publications KPMG Powered Enterprise · présentation du programme KPMG Lakehouse. Date de référence à épingler lors de la recherche.
Accenture
Offre nommée : Business Agility au sein de la practice Strategy & Consulting ; Agile Engineering Studios au sein de la practice Technology ; services agile-et-DevOps au sein d'Operations. La capacité agile d'Accenture couvre trois des quatre lignes de service du cabinet.
Méthodes superposées : SAFe est la méthode de base dominante, Accenture étant parmi les plus grands SAFe Global Transformation Partners. Des structures d'inspiration Spotify apparaissent dans les engagements tech-native. Scrum au niveau équipe tout du long. La surcouche de solution industrie myConcerto se pose au-dessus de la livraison agile.
IP signature : myConcerto (accélérateur de solutions alignées sur l'industrie), Agile Engineering Studios (hubs d'ingénierie régionaux), ADM et ADMnext (Application Development & Maintenance — la surcouche de livraison de services d'ingénierie ; ADMnext en est la version nouvelle génération rebrandée). Adjacent : AI Refinery et l'investissement IA de 3 Md$ (issus de l'article IA) — les équipes agiles livrent sur Refinery ; l'Accenture-NVIDIA Business Group est l'alliance hyperscaler la plus brandée du conseil.
Cas phare nommé : Multiples transformations Fortune 500 citées publiquement dans les services financiers, le retail, la santé et les secteurs industriels. Cas phare spécifique à confirmer lors de la prise de référence ; le volume de cas publiés d'Accenture est parmi les plus élevés du secteur.
Formation/certification : Vraisemblablement le plus grand bench de consultants certifiés SAFe de tous les cabinets (dizaines de milliers de certifications à travers l'effectif mondial). Accenture Academy. Agile Engineering Studios comme moteur de développement du bench.
Ambiance de positionnement : Échelle et exécution. L'agile se situe à l'intérieur de l'offre d'ingénierie de services plus large d'Accenture plutôt que comme transformation autonome. Le cabinet à retenir quand la transformation exige une livraison mondiale, une coordination multi-fournisseurs, et un bench certifié SAFe disponible à la demande. Récit moins porté par des partners seniors que McKinsey ou Bain ; plus de profondeur de moteur d'exécution qu'aucun pair.
Sources : pages de capacité Accenture.com Business Agility, Agile Engineering Studios et myConcerto · annuaire des Scaled Agile Global Transformation Partners · publications ADM et ADMnext · annonces de l'Accenture-NVIDIA Business Group. Date de référence à épingler lors de la recherche.
Bain & Company
Offre nommée : Agile Innovation (l'offre agile publiée la plus distinctive de Bain), soutenue par le Bain Agile Innovation Network et le diagnostic Agile Enterprise au niveau portefeuille.
Méthodes superposées : Scrum au niveau équipe. Le propre diagnostic Agile Enterprise de Bain au niveau portefeuille. Moins prescriptif en matière de framework que le Big Four ; Bain travaille à la couche stratégique et d'operating model et laisse le framework de niveau équipe choisi s'ajuster à l'engagement.
IP signature : Darrell Rigby (partner Bain, aujourd'hui retraité mais avec une présence continue de thought leadership) a co-écrit Doing Agile Right (Harvard Business Review Press, 2020) — l'actif agile Bain le plus publié. Les articles HBR antérieurs incluent « Embracing Agile » (2016), « Agile at Scale » (2018) et « The Agile C-Suite » (2020). Adjacent : Sage (outil interne basé sur GPT-4, issu de l'article IA) et l'alliance OpenAI — les équipes agiles livrent un travail IA co-conçu par-dessus des actifs d'alliance brandés.
Cas phare nommé : John Deere (agile industriel, largement cité par Rigby), Bosch (transformation agile industrielle), plus de multiples cas dans le catalogue HBR de Rigby. La base de cas publiés est inhabituellement fournie pour un cabinet de stratégie.
Formation/certification : Bain Agile Innovation Practice interne. Aucune filière de certification publique. Le livre de Rigby et les articles HBR font office de transfert de connaissances externe pour Bain.
Ambiance de positionnement : L'agile comme discipline d'innovation plutôt que méthode de livraison IT. Récit porté par des partners seniors. Le cabinet le plus susceptible d'être dans la salle quand un industriel manufacturier veut introduire l'agile dans le développement produit sans restructurer la livraison IT. Moins de cérémonie, plus de stratégie.
Sources : pages de capacité Bain.com Agile Innovation · Rigby, Sutherland et Takeuchi, Doing Agile Right (HBR Press, 2020) · Rigby et al., articles HBR 2016-2020 · Bain Technology Report (annuel). Date de référence à épingler lors de la recherche.
Capgemini
Offre nommée : ADMnext (Application Development & Maintenance, nativement agile et DevOps — la plateforme phare de services d'ingénierie de Capgemini), soutenue par les services Agile et Scaled Agile et les Capgemini Agile Innovation Centers.
Méthodes superposées : SAFe est la méthode de base dominante — Capgemini est un Scaled Agile Global Transformation Partner. Scrum, Kanban et DevOps sont intégrés plutôt que superposés séparément ; la pratique d'ingénierie et la pratique agile arrivent ensemble.
IP signature : La plateforme ADMnext (l'actif de livraison de services d'ingénierie le plus cité de cette comparaison), les Capgemini Agile Innovation Centers (studios d'ingénierie régionaux). Adjacent : le Resonance AI Framework (issu de l'article IA) se pose au-dessus de la plateforme d'ingénierie ; le statut de Google Cloud Partner of the Year 2025 de Capgemini renforce l'inclinaison pilotée par l'ingénierie.
Cas phare nommé : Transformations bancaires, automobiles et énergétiques européennes. Mercedes-Benz, BNP Paribas et plusieurs grands distributeurs européens couramment cités. Cas phare spécifique à confirmer lors de la prise de référence ; la bibliothèque de cas de Capgemini est fortement centrée sur l'Europe et substantiellement pilotée par l'ingénierie.
Formation/certification : Parmi les plus grands benchs certifiés SAFe en dehors d'Accenture. Capgemini University (le campus de formation phare du cabinet, en France). Certification interne de praticien ADMnext.
Ambiance de positionnement : Piloté par l'ingénierie. Le cabinet le plus susceptible d'être dans la salle quand la transformation agile est indissociable d'un programme de platform engineering, DevOps ou de modernisation cloud. Forte autorité de marque européenne. Récit moins porté par des partners seniors que McKinsey ou Bain ; plus de profondeur d'ingénierie de livraison que Deloitte ou KPMG.
Sources : pages Capgemini.com ADMnext, services agiles et Agile Innovation Center · annuaire des Scaled Agile Global Transformation Partners · publications du Capgemini Research Institute (CRI). Date de référence à épingler lors de la recherche.
IBM Consulting
Offre nommée : IBM Garage Method (la méthodologie de livraison agile-plus-ingénierie canonique du cabinet), enveloppée par Enterprise Design Thinking en amont et une coordination alignée SAFe à l'échelle. Livrée via les sites IBM Garage (studios physiques et virtuels).
Méthodes superposées : SAFe au niveau programme — IBM est un SAFe Global Transformation Partner. Scrum au niveau équipe. Enterprise Design Thinking en amont de la boucle. La Garage Method intègre tout cela en un seul cycle Discover-Envision-Develop-Reason-Operate-Culture.
IP signature : IBM Garage Method — l'IP historique qui distingue le plus IBM du Big Four. Enterprise Design Thinking (l'approche de cadrage de problème pilotée par le design d'IBM). Filiation historique avec le Rational Unified Process (RUP), la méthodologie itérative lourde originelle d'IBM acquise avec Rational Software en 2003. Adjacent : IBM Consulting Advantage et watsonx (issus de l'article IA) — les équipes de livraison agile livrent sur la plateforme Advantage et la pile de modèles watsonx.
Cas phare nommé : American Airlines (transformation pilotée par la Garage, documentée publiquement), USAA (engagement Garage dans les services financiers), Travelport, de multiples transformations bancaires. Le playbook de la Garage Method contient une matière de cas substantielle.
Formation/certification : IBM Skills Academy. Partenaire SAFe. Filière de certification interne Garage Method pour les consultants IBM. Certification Enterprise Design Thinking.
Ambiance de positionnement : Intégré du design thinking à l'ingénierie. Le cabinet le plus susceptible d'être dans la salle quand l'engagement démarre par un exercice de cadrage de problème piloté par le design et se termine par une livraison de platform engineering. Fort sur les actifs (Garage Method, watsonx, Enterprise Design Thinking) plutôt que sur la cérémonie. La filiation ingénierie-et-design la plus claire de tous les cabinets de cette comparaison.
Sources : pages de capacité IBM.com/garage · playbook IBM Garage Method (ibm.com/cloud/architecture ou URL successeur) · pages Enterprise Design Thinking · publications IBM Consulting agile et transformation. Date de référence à épingler lors de la recherche.
Le tableau comparatif de référence
Le tableau ci-dessous est l'actif de référence. Il croise les huit frameworks avec huit dimensions de comparaison, les cabinets qui packagent le plus activement chaque framework étant indiqués dans la colonne de droite.
| Framework | Auteur principal | Hypothèse d'échelle | Niveau prescriptif | Forme de gouvernance | Profondeur d'ingénierie | Écosystème de certification | Packagers principaux |
|---|---|---|---|---|---|---|---|
| SAFe | Dean Leffingwell (Scaled Agile Inc.) | 50-125 par ART ; portfolio > 1 000 | Élevé | Hiérarchique (Portfolio → Équipe) | DevOps + XP nommés | SAFe SPC/SA/POPM/etc. (Scaled Agile Inc.) | Accenture · Deloitte · Capgemini · IBM · EY |
| LeSS | Craig Larman / Bas Vodde (LeSS Company) | 2-8 équipes (LeSS) ; 8+ équipes (LeSS Huge) | Faible à moyen | Plate (un seul PO) | Élevée (excellence technique) | CLP, CLT (LeSS Company) | Petits spécialistes ; usage partiel chez McKinsey, Bain |
| Scrum@Scale | Jeff Sutherland (Scrum Inc.) | Modulaire ; structure SoS | Faible (noyau modulaire) | Deux cycles (PO + SM) | Moyenne (dépend de la formation) | SSM / SPS (Scrum Inc.) | BCG (sélectif) ; consultants indépendants |
| Spotify Model | Henrik Kniberg / Anders Ivarsson | Tribes / Squads (taille non fixe) | Culturel, pas structurel | Matricielle (Tribe × Chapter) | Implicitement élevée (ingénierie Spotify) | Aucune officielle | BCG (ING) · McKinsey · cabinets digital-native |
| Disciplined Agile (DAD) | Scott Ambler / Mark Lines (PMI) | Toolkit ; agnostique au cycle de vie | Piloté par le choix (orienté objectifs) | Pluraliste (agile/lean/plan-driven) | Large (DevOps, sécurité, architecture) | DAC, DASM, DAVSC (PMI) | Cabinets alignés PMI ; héritage IBM |
| Nexus | Ken Schwaber (Scrum.org) | 3-9 équipes Scrum, un produit | Faible (extension de Scrum) | Centrée sur l'équipe d'intégration | Moyenne (discipline d'intégration) | SPS, NXTC (Scrum.org) | Cabinets alignés Scrum.org ; partiel chez Accenture |
| Kanban Maturity Model (KMM) | David J. Anderson (Mauvius Group) | Équipe à entreprise, stades de maturité 0-7 | Catalogue de pratiques | Basée sur le flux, évolutive | Agnostique | KMP, KCP (Kanban University) | Cabinets à forte composante opérations ; partiel chez Capgemini |
| FAST | Ron Quartel | Tribu de 30-150, équipes dynamiques | Radicalement flexible | Réunion de tribu / marché | Élevée (présuppose une pratique mature) | Aucune répandue | Coaches spécialisés ; rarement les grands cabinets |
Ce qui est réellement différent
- Seuls trois frameworks publient une méthodologie numérotée qu'on peut mettre en œuvre sans consultant. SAFe a des rôles, des cérémonies, des artefacts et un Continuous Delivery Pipeline qu'une équipe de transformation peut lire et exécuter. LeSS a les règles publiées du Scrum multi-équipe sur un seul produit. Scrum@Scale a le SoS et les deux cycles de coordination. Les cinq autres — Spotify, DAD, Nexus, KMM, FAST — sont soit des toolkits, soit des instantanés, soit des extensions minimales qui nécessitent soit un praticien expérimenté, soit un contexte existant substantiel pour atterrir. Ce n'est pas un jugement de qualité : les toolkits et instantanés sont parfois la bonne réponse. C'est un jugement de clarté pour l'acheteur : seuls trois des huit frameworks réduisent la dépendance au consultant que le framework était censé réduire.
- La profondeur d'ingénierie logicielle est la ligne de partage la plus nette du champ. LeSS et FAST présupposent une pratique d'ingénierie mature et ne pardonnent pas son absence. SAFe et Nexus nomment explicitement des pratiques d'ingénierie dans leurs guides mais s'en remettent à l'implémenteur pour les apporter. Spotify, DAD, KMM et Scrum@Scale sont largement agnostiques sur la pratique d'ingénierie. Un acheteur qui connaît honnêtement la culture d'ingénierie de son organisation peut faire correspondre cette colonne directement à l'adéquation du framework ; un acheteur qui ne la connaît pas adoptera un framework qui exposera l'écart douloureusement.
- Seuls deux frameworks ont des programmes de certification de niveau grand cabinet. SAFe (Scaled Agile Inc., dominant, multiples certifications alignées sur les rôles, large écosystème de partenaires) et Disciplined Agile (propriété du PMI depuis 2019, intégré au credential PMP). Les six autres ont des certifications — LeSS Company, Scrum.org Nexus, Scrum Inc. Scrum@Scale, Kanban University KMP, communauté fastagile.io — mais le volume et la pénétration dans les cabinets de conseil est d'un ordre de grandeur inférieur. Cela entraîne un effet secondaire que les acheteurs voient rarement : le marché du talent saturé de SAFe signifie que l'expertise SAFe est réellement disponible à la demande, d'une façon qui n'est pas vraie pour LeSS ou FAST à l'échelle de l'entreprise.
- Le Spotify Model est l'artefact le plus cité et le moins implémenté du champ. Ce n'est pas un framework. Le papier original de 2012 décrivait ce que faisait Spotify à l'époque ; les rétrospectives ultérieures (Sundén 2017, autres) sont explicites sur le fait que Spotify elle-même a dépassé ces diagrammes en un an ou deux. Pourtant, chaque cabinet de conseil de cette comparaison utilise une version des « tribes » et « squads » dans son collatéral agile, et une fraction substantielle des transformations agiles publiques cite Spotify comme le modèle. Le vocabulaire voyage ; la culture d'ingénierie, l'investissement en gestion produit et l'infrastructure de plateforme qui faisaient fonctionner la structure Spotify ne voyagent pas.
- FAST et le Kanban Maturity Model sont les seuls frameworks qui n'exigent aucune réorganisation de la structure d'équipe. Chaque autre framework de cette liste présuppose une forme explicite de configuration d'équipe, qu'elle soit prescrite (ART SAFe, équipes feature LeSS, équipes Scrum Nexus) ou descriptive (squads Spotify). KMM fonctionne avec la structure existante ; FAST dissout entièrement la structure stable au profit d'une formation quotidienne fluide. Pour les organisations où la réorganisation est politiquement ou pratiquement impossible — contextes post-fusion, structures régulées, organisations se remettant d'une transformation précédemment échouée — c'est la ligne de partage la plus nette du champ.
- Trois cabinets publient une IP méthodologique substantielle qui ne se contente pas de relabeler SAFe. Bain (le livre Doing Agile Right de Rigby et la série d'articles HBR) a une méthodologie publiée avec sa propre théorie de la place de l'agile dans une stratégie d'entreprise. McKinsey (les Five Trademarks of Agile Organizations) a un diagnostic de salle de conseil d'administration qui opère au-dessus de tout framework. IBM (la Garage Method et Enterprise Design Thinking, avec un héritage Rational Unified Process) a la méthodologie de livraison publiée la plus ancienne du champ. Les sept autres cabinets opèrent substantiellement comme des partenaires SAFe avec des enveloppes brandées, même quand leur collatéral public référence d'autres méthodes.
Ce qui relève surtout du branding
- La plupart des « offres de transformation agile » du Big Four sont du SAFe avec une enveloppe brandée par le cabinet. Retirez le diagnostic brandé, le template de PI Planning aux couleurs du cabinet et le modèle de maturité propriétaire, et la méthode de base en dessous est SAFe dans sept des dix cabinets de ce texte (les exceptions étant Bain, le récit piloté par le diagnostic de McKinsey, et la Garage Method d'IBM). Ce n'est pas une critique de SAFe ni des cabinets — SAFe a mérité sa part de marché — mais un acheteur devrait savoir si l'IP du cabinet est l'enveloppe ou la base.
- « Tribes et squads » est devenu un vocabulaire, pas une méthode. Presque chaque cabinet de cette comparaison utilise un langage dérivé de Spotify dans son collatéral agile. Presque aucun ne livre la culture d'ingénierie, la discipline de gestion produit, ou l'investissement en plateforme interne qui faisaient fonctionner la structure Spotify. Si un cabinet utilise le vocabulaire Spotify sans nommer ce qu'il fera des pratiques d'ingénierie, des plateformes internes pour développeurs et de l'operating model de gestion produit, traitez le vocabulaire comme du branding.
- Les modèles de maturité agile sont pour la plupart auto-similaires. Quatre à cinq niveaux. La même poignée d'axes — en général une combinaison de processus, personnes, technologie, culture et résultats client. Comparez côte à côte les modèles de maturité agile de trois cabinets quelconques et la similarité structurelle est frappante. Le modèle de maturité sert un objectif précis — il rend l'engagement lisible pour un comité de pilotage — mais c'est rarement l'IP de livraison réelle du cabinet. L'IP est dans les consultants qui font traverser les niveaux à l'organisation.
- Le volume de certifications SAFe signale moins qu'avant. La filière de certification est large, le pipeline de formation de masse est mature, et la durée de vie d'une certification fraîche n'est plus ce qu'elle était il y a dix ans. Un décompte de consultants certifiés SAFe vous dit combien de personnes le cabinet a fait passer par un cours, pas combien ont livré une transformation agile ayant survécu à un point de contrôle à cinq ans. Demandez le décompte d'engagements livrés, pas le décompte de certifications.
- La plupart des « cas phares » ne survivent pas à un point de contrôle honnête à cinq ans. La transformation la plus citée de l'ère moderne — la restructuration d'inspiration Spotify d'ING Bank en 2015-2018, narrée par BCG et McKinsey — a substantiellement évolué dans les années qui ont suivi, et l'organisation ING actuelle a l'air sensiblement différente du diagramme de 2017. Ce motif n'est pas propre à ING ; c'est la règle, pas l'exception. Le cas phare publié d'un cabinet est un instantané d'un moment dans un long programme. Demandez à quoi ressemble le cas aujourd'hui, pas à quoi la présentation disait qu'il ressemblerait.
La réalité 2026 : IA, équipes plus petites, platform engineering
Chaque framework de cette comparaison a été conçu avant que l'IA générative ne change la taille de l'équipe qui livre une charge de travail donnée. Les implications n'apparaissent pas encore dans les guides de framework — SAFe 6.0 ne fait que des gestes modestes vers l'IA, le guide LeSS est silencieux, les rétrospectives du modèle Spotify précèdent le moment IA actuel — mais elles sont visibles dans les transformations de 2026.
L'IA générative comprime la taille des équipes. Une charge de travail produit qui nécessitait une tribu de quatre-vingts ingénieurs, designers et product managers en 2018 est, dans de nombreux cas, livrable par huit à quinze personnes en 2026, grâce au développement assisté par IA, à la couverture de tests générée par IA et à la conception augmentée par IA. Les frameworks bâtis pour des programmes lourds en effectifs — SAFe au niveau ART en particulier, avec son hypothèse de 50 à 125 personnes et la logistique du PI Planning — sont sous pression structurelle. Les frameworks qui redescendent en échelle proprement (FAST, KMM, Nexus et LeSS à l'extrémité basse de sa plage) gagnent discrètement du terrain.
Le platform engineering remplace certaines cérémonies de coordination. Les plateformes internes pour développeurs font désormais le travail inter-équipes qui se trouvait auparavant dans les réunions de Scrum-of-Scrums, les salles de PI Planning et les rituels d'équipe d'intégration. Quand la plateforme absorbe la coordination, le framework en a besoin de moins. Les frameworks agiles les plus sous pression sont ceux dont la proposition de valeur était substantiellement « des cérémonies de coordination et une cadence partagée ». Les frameworks les plus renforcés sont ceux dont la proposition de valeur était substantiellement « pratique d'ingénierie et flux ».
Le remote-first change l'économie des cérémonies co-localisées. Un PI Planning sur Zoom n'est pas ce qu'était le PI Planning dans un centre de conférence avec quatre-vingts personnes sur des post-its. Les frameworks qui dépendaient d'une qualité de rituel co-localisé particulière sont plus fragiles qu'avant ; les frameworks qui fonctionnaient à travers n'importe quel canal de communication (les tableaux de flux de KMM, la discipline d'intégration de Nexus) ont mieux tenu. Ce n'est pas un verdict sur le travail à distance ; c'est une observation sur quels frameworks avaient intégré leurs cérémonies dans la proposition de valeur.
La règle de décision a changé. La question de sélection de framework en 2018 était « quel framework passe à l'échelle ? ». En 2026, elle se rapproche de « quel framework survit à une coupe de cinquante pour cent des effectifs sans perdre son identité ? ». Le SAFe-au-niveau-Portfolio survit à la coupe en réduisant le nombre d'ART, mais un ART SAFe lui-même est malaisé à moins de cinquante personnes. LeSS redescend proprement à deux équipes. KMM n'exige aucune structure définie par les effectifs. Les tribus de style Spotify perdent leur identité quand la tribu s'effondre à un seul squad.
Ce basculement se connecte directement à la question de l'acheteur que nous avons examinée dans le texte compagnon, Les grands frameworks IA du conseil, comparés. L'IA n'est pas seulement une technologie à déployer ; c'est un changement dans l'économie unitaire de la livraison logicielle. Le framework agile qui correspond à une organisation saturée d'IA en 2026 est rarement le même framework agile qui correspondait à la même organisation en 2018, même quand rien d'autre dans le travail n'a changé. Les frameworks qui paraissent les plus solides dans cet environnement sont ceux bâtis autour du flux et de la pratique d'ingénierie ; les frameworks qui paraissent les plus faibles sont ceux bâtis autour d'une coordination lourde en effectifs.
Comment lire ceci si vous êtes acheteur
Si vous êtes CEO, administrateur, responsable de transformation ou investisseur PE, le débat de framework n'est presque jamais l'endroit le plus utile pour dépenser votre énergie de décision. Les cinq scénarios ci-dessous couvrent l'essentiel de ce qui apparaît réellement dans les propositions de transformation agile ; choisissez le scénario qui correspond, regardez ce que la correspondance de framework vous dit, et utilisez les trois questions à la fin pour lire le pitch de n'importe quel cabinet en cinq minutes.
Scénario 1 — Mise à l'échelle mid-market (300-2 000 salariés, en forte croissance). La bonne réponse est rarement SAFe ; c'est trop lourd pour la taille et l'écosystème de certification est calibré pour de plus grandes entreprises. Regardez Scrum@Scale ou LeSS à l'extrémité basse de sa plage. Le choix de cabinet est en général un cabinet de conseil agile spécialisé ou un praticien indépendant senior ; le Big Four est calibré pour de plus gros engagements et le coût d'accès est élevé par rapport à la valeur que vous en extrairez à cette taille.
Scénario 2 — Industrie régulée (banque, pharma, utilities régulées, défense). SAFe gagne l'argument de la convivialité pour l'audit avec une large marge — rôles nommés, artefacts traçables, consultants certifiés qui passent les filtres de procurement. Le choix de cabinet est Deloitte, Accenture, Capgemini, KPMG ou EY, selon la présence régionale et la relation existante. Le compromis que vous faites est de la profondeur de pratique d'ingénierie contre de la lisibilité de gouvernance ; budgétez séparément pour combler l'écart d'ingénierie.
Scénario 3 — Intégration post-fusion. Deux cultures de livraison, souvent deux chaînes d'outils de livraison, souvent deux saveurs agiles existantes qui divergent. Le modèle de cycle de vie pluraliste de DAD correspond mieux à ce motif qu'un framework à philosophie unique ; KMM fonctionne bien quand la réorganisation est politiquement hors de question. Cabinets alignés PMI ou cabinets spécialisés en intégration post-fusion. Évitez de forcer un côté sur le framework de l'autre comme mouvement d'intégration — le coût politique justifie rarement la pureté méthodologique.
Scénario 4 — Programme lourd en IA. Équipes plus petites, cycles plus rapides, dépendant du platform engineering. FAST ou LeSS à l'extrémité basse correspondent mieux que SAFe ; KMM fonctionne pour le volet opérations du même programme. Le choix de cabinet chevauche substantiellement la décision de conseil en IA — voir le texte compagnon sur l'IA pour cette sélection. Le framework agile est la couche de livraison du travail IA ; choisissez-le pour l'adéquation de pratique d'ingénierie, pas pour la densité de cérémonie.
Scénario 5 — Bascule classique de l'IT vers le produit. Une organisation de livraison IT traditionnelle qui bascule vers des équipes orientées produit et résultats. Les structures d'inspiration Spotify avec un investissement profond en culture d'ingénierie sont la réponse de manuel ; le manuel est souvent mal lu. BCG ou McKinsey fournissent la surcouche de conception organisationnelle et le récit de niveau conseil d'administration ; le travail d'ingénierie est la partie difficile et rarement la partie que le cabinet de stratégie est le mieux positionné pour livrer. Prévoyez un second engagement piloté par l'ingénierie — Capgemini ou un cabinet spécialisé en platform engineering — en parallèle du travail de stratégie.
Trois questions percent le pitch d'un cabinet plus vite qu'aucune matrice de scoring :
- « Montrez-moi la pratique d'ingénierie que votre équipe livrera, en détail, dès lundi. » Si un cabinet ne peut pas décrire en détail la pratique d'ingénierie de son équipe — développement trunk-based, configuration de CI, approche de couverture de tests, discipline de revue de code, outillage plateforme — ce que vous achetez est de la cérémonie, pas de la livraison. C'est parfois le bon choix. Sachez que c'est le choix que vous faites.
- « Montrez-moi à quoi ressemble aujourd'hui la structure de votre dernier engagement. » Les frameworks évoluent, et la réponse honnête révèle ce qui a survécu au contact avec l'organisation. Les cabinets qui ne peuvent pas vous dire à quoi ressemble leur dernier engagement en 2026 sont soit non impliqués dans la réalité post-engagement, soit peu disposés à la partager. Les deux sont des signaux utiles.
- « Qui possède le travail d'intégration entre équipes, et comment est-il staffé ? » La coordination est le vrai coût de l'agile à l'échelle. Le motif d'échec le plus courant est un framework qui nomme le rôle d'intégration sur un slide et le laisse non staffé dans l'engagement. Demandez qui, demandez son CV, demandez sa ligne hiérarchique. Si les réponses sont vagues, l'intégration se paiera en retards de livraison.
Où s'inscrit Consulting Huber
Consulting Huber est un cabinet de praticiens, pas un pair Big Four ou MBB. Nous ne concurrençons pas sur la taille de bench certifié SAFe, sur l'empreinte de livraison mondiale, ou sur le volume de cas phares nommés. Nous concurrençons sur le problème inverse : les responsables de transformation, CEO, conseils d'administration et investisseurs PE qui veulent la méthodologie et la discipline d'ingénierie d'un grand cabinet, livrées directement par des praticiens seniors, avec la capacité transférée à l'équipe propre du client à la fin de l'engagement.
Cela signifie que nous vous dirons quel framework correspond réellement à la culture d'ingénierie de votre organisation plutôt que quel framework notre pile de certifications favorise. Cela signifie que nous travaillerons avec vous pour staffer correctement le rôle d'intégration plutôt que de le nommer sur un slide. Cela signifie que nous vous laisserons le droit de nous renvoyer à la fin de n'importe quel cycle, car le modèle est le transfert de capacité, pas le verrouillage sur une plateforme.
Le texte compagnon côté IA — comment les mêmes dix cabinets cadrent la transformation IA et GenAI, avec le même regard côté acheteur — se trouve à Les grands frameworks IA du conseil, comparés (2026). Notre page de service sur le travail agile de bout en bout est à Business Agility. Si vous voulez la vue de la passerelle IA-et-agile de comment ces deux textes se connectent pour un vrai programme, le playbook de création de valeur IA est le troisième coin du triangle.
Sources consultées
Sources primaires — textes canoniques des frameworks
Leffingwell, D., SAFe Reference Guide (Scaled Agile Inc., current edition for SAFe 6.0) · scaledagileframework.com
Larman, C., and Vodde, B., Large-Scale Scrum: More with LeSS (Addison-Wesley, 2017) · Larman and Vodde, Practices for Scaling Lean & Agile Development (Addison-Wesley, 2008) · less.works
Sutherland, J., and Sutherland, J. J., Scrum: The Art of Doing Twice the Work in Half the Time (Random House, 2014) · The Scrum@Scale Guide v3.0 (Scrum Inc., 2022) · scrumatscale.com
Kniberg, H., and Ivarsson, A., “Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds” (Spotify white paper, 2012) · Kniberg, H., “Spotify Engineering Culture” Part 1 and Part 2 (Spotify Labs videos, 2014) · Sundén, J., “There is no Spotify Model” (2017)
Ambler, S., and Lines, M., Choose Your WoW! (Project Management Institute, current edition) · Ambler and Lines, Disciplined Agile Delivery (IBM Press, 2012) · pmi.org/disciplined-agile
Schwaber, K., and Scrum.org, The Nexus Guide · scrum.org/resources/nexus-guide
Anderson, D. J., and Bozheva, T., Kanban Maturity Model (Lean Kanban Inc., 2018) · Anderson, D. J., Kanban: Successful Evolutionary Change for Your Technology Business (Blue Hole Press, 2010) · kanbanmaturitymodel.com
Quartel, R., The FAST Guide · fastagile.io
Beck, K. et al., The Agile Manifesto (2001) · agilemanifesto.org
Sources primaires — pages de capacité des cabinets (date de référence 2026-05-14)
BCG
Pages de capacité BCG.com Agile at Scale · publications BCG « Agile Performance Management » · pages de capacité de BCG X — l'unité de construction technologique — · couverture de l'étude de cas de la transformation ING Bank par BCG. URLs spécifiques à épingler lors de la prise de référence.
McKinsey & Company
Bazigos, M., De Smet, A., and Gagnon, C., “The five trademarks of agile organizations” (McKinsey & Company, 2018) · articles agiles de McKinsey Quarterly (Aghina, De Smet et al., plusieurs années) · études de cas McKinsey sur ING Bank · publications McKinsey Organizational Health Index. URLs spécifiques à épingler lors de la prise de référence.
Deloitte
Pages de capacité Deloitte.com Agile@Scale · entrée de l'annuaire des Global Transformation Partners de Scaled Agile Inc. · publications agiles et transformation de Deloitte Insights · articles régionaux Deloitte sur l'Agile Maturity Model. URLs spécifiques à épingler lors de la prise de référence.
EY (et EY-Parthenon)
Pages de capacité EY.com Business Agility · pages du framework EY Transformation Realized · publications EY Wavespace · analyses stratégie et transformation d'EY-Parthenon. URLs spécifiques à épingler lors de la prise de référence.
PwC
Pages de capacité PwC.com Business Transformation et Digital Transformation · publications sur la méthodologie PwC BXT (Business-Experience-Technology) · PwC Global CEO Survey (constats agiles et transformation). URLs spécifiques à épingler lors de la prise de référence.
KPMG
Pages de capacité KPMG.com agile-transformation et Connected Enterprise · publications KPMG Powered Enterprise · présentation du programme KPMG Lakehouse · analyses transformation de KPMG global advisory. URLs spécifiques à épingler lors de la prise de référence.
Accenture
Pages de capacité Accenture.com Business Agility et Agile Engineering Studios · pages de solutions industrie Accenture myConcerto · publications Accenture ADM et ADMnext · entrée de l'annuaire des Global Transformation Partners de Scaled Agile Inc. · annonces de l'Accenture-NVIDIA Business Group. URLs spécifiques à épingler lors de la prise de référence.
Bain & Company
Pages de capacité Bain.com Agile Innovation · Rigby, D., Sutherland, J., and Takeuchi, H., Doing Agile Right: Transformation Without Chaos (Harvard Business Review Press, 2020) · Rigby et al., “Embracing Agile” (HBR, 2016), “Agile at Scale” (HBR, 2018), “The Agile C-Suite” (HBR, 2020) · Bain Technology Report (annuel). URLs spécifiques à épingler lors de la prise de référence.
Capgemini
Pages de capacité Capgemini.com ADMnext · pages de services agiles et DevOps de Capgemini · pages des Capgemini Agile Innovation Center · entrée de l'annuaire des Global Transformation Partners de Scaled Agile Inc. · publications du Capgemini Research Institute (CRI). URLs spécifiques à épingler lors de la prise de référence.
IBM Consulting
Pages de capacité ibm.com/garage · playbook IBM Garage Method · pages IBM Enterprise Design Thinking · publications IBM Consulting Advantage · matériel de cas IBM American Airlines, USAA et autres cas Garage. URLs spécifiques à épingler lors de la prise de référence.
Benchmarks tiers et communauté
Annuaire des partenaires et données d'adoption en entreprise de Scaled Agile Inc. · State of Agile Report (digital.ai, éditions annuelles) · statistiques et données d'adoption communautaires Scrum.org · bibliothèque de cas LeSS Company · matériel communautaire Kanban University. URLs spécifiques à épingler lors de la prise de référence.
Entretiens de praticiens menés pour cette édition
À ajouter pendant la recherche : conversations nommées avec des auteurs de framework et des praticiens seniors des cabinets, lorsqu'ils consentent à l'attribution. Les textes de référence gagnent matériellement d'une ou deux citations attribuées ; les démarches sont en cours à la date de référence.
Comment citer cet article
Style APA :
Huber, B. (2026). Les grands frameworks agiles du conseil, comparés : SAFe, LeSS, Scrum@Scale, Spotify, DAD, Nexus, KMM, FAST et comment BCG, McKinsey, Deloitte, EY, PwC, KPMG, Accenture, Bain, Capgemini et IBM les packagent (édition 2026). Consulting Huber. https://consulting-huber.com/fr/agile-consulting-frameworks-compared.html
BibTeX :
@article{huber2026agile,
author = {Huber, Bernhard},
title = {Les grands frameworks agiles du conseil, comparés (édition 2026)},
journal = {Consulting Huber},
year = {2026},
url = {https://consulting-huber.com/fr/agile-consulting-frameworks-compared.html}
}
Date de référence : 14 mai 2026. Actualisation annuelle prévue ; les éditions suivantes conserveront l'édition précédente à une URL datée.
À lire aussi : Service Business Agility · Comparaison des frameworks IA (texte compagnon) · Playbook de création de valeur IA · Études de cas · Tous les services