SAFe et Scrum@Scale : quelles différences, et comment choisir ?

En 2022, SAFe (Scaled Agile Framework) était utilisé par 53 % des professionnels agiles ayant répondu au State of Agile Report. En 2023, ce chiffre était retombé à 26 %. Une chute de moitié en un an. Quelque chose se passe dans le monde du scaling agile, et ça mérite qu'on s'y arrête.

Cela fait plusieurs années que cette question revient dans mes conversations avec des équipes et des managers. Scrum fonctionne bien à l'échelle d'une équipe. Mais dès qu'on a découvert ce que l'agilité peut produire à cette échelle, on se pose rapidement la suivante : comment étendre ça à plusieurs équipes qui doivent travailler ensemble vers un objectif commun ?

C'est précisément ce à quoi répondent les frameworks d'agilité à l'échelle : des systèmes de coordination pensés pour permettre à plusieurs équipes agiles de travailler ensemble vers un objectif commun. Et parmi ces frameworks, deux noms reviennent le plus souvent : SAFe, très répandu et très structuré ; et Scrum@Scale, beaucoup moins visible en France, mais dont l'histoire et les résultats terrain méritent qu'on s'y arrête.

Faut-il choisir entre les deux ? La réponse est moins binaire qu'on ne le croit.

Quand une équipe ne suffit plus

Le Guide Scrum recommande des équipes de dix personnes au maximum. Dès qu'une organisation fait travailler plusieurs équipes en parallèle sur un même produit ou un même objectif, sans système de coordination pensé pour ça, les mêmes problèmes émergent.

Les dépendances entre équipes ne sont pas visibles avant qu'elles ne bloquent quelqu'un. Les priorités d'une équipe peuvent entrer en conflit avec celles d'une autre. Les décisions qui touchent plusieurs équipes se perdent entre les managers. La direction perd la visibilité sur l'avancement global.

C'est pour répondre à ces enjeux que les frameworks d'agilité à l'échelle ont été conçus. SAFe et Scrum@Scale y répondent chacun à leur façon.

SAFe, le plus répandu

SAFe est aujourd'hui le framework le plus utilisé pour coordonner des dizaines d'équipes agiles dans de grandes organisations, principalement dans le secteur IT.

Son architecture est précise. Les équipes sont regroupées en trains (Agile Release Trains), qui se synchronisent lors d'événements de planification appelés PI Planning, organisés toutes les 8 à 12 semaines. Plusieurs niveaux de gouvernance s'emboîtent : Team, Program, Portfolio. Les rôles sont définis, les événements cadrés, les artefacts nombreux.

C'est sa force principale : dans une grande organisation où rien n'est formalisé, SAFe apporte une structure immédiatement lisible. Les dépendances deviennent visibles. La feuille de route se partage. Les équipes comprennent comment leur travail s'articule avec celui des autres.

SAFe peut cependant s'avérer lourd à mettre en place et coûteux à déployer. Il est également fragile si les équipes n'en adoptent pas réellement le sens : on parle alors de "SAFe theater" (par analogie avec le "cargo cult agile"), une situation où les équipes suivent les pratiques sans en tirer la valeur, faute de fondamentaux en place avant l'adoption du framework.

Et c'est une observation récurrente dans les organisations que j'accompagne. SAFe est souvent adopté avant que les équipes aient une vraie maîtrise de Scrum. Parfois sans les avoir formées à Scrum au préalable. C'est mettre la charrue avant les boeufs. SAFe est construit sur l'hypothèse que les équipes pratiquent Scrum ou Kanban au niveau équipe. Ce n'est pas un prérequis formel dans la documentation officielle, mais c'est la fondation sur laquelle tout le reste repose. Quand cette fondation manque, les résultats sont rarement au rendez-vous, en termes de performance comme d'adhésion au changement.

Les données d'adoption le reflètent peut-être. Après un pic à 53 % en 2022, SAFe est retombé à 26 % en 2023 dans le State of Agile Report (enquête annuelle de Digital.ai auprès de professionnels agiles). Ce n'est pas nécessairement une condamnation du framework, mais le signe que beaucoup d'adoptions n'ont pas tenu leurs promesses.

Scrum@Scale, l'approche à connaître

Scrum@Scale est moins connu, mais son histoire est plus ancienne qu'on ne le croit. Jeff Sutherland, co-créateur de Scrum, a commencé à prototyper les bases du scaling dès 1983. Le guide formel n'a été publié qu'en 2018, à la demande de responsables agiles chez Intel et SAP qui, selon Sutherland lui-même, avaient testé les frameworks disponibles et concluaient qu'ils "ralentissaient tout."

J'ai eu la chance d'être formé par Jeff Sutherland en 2008. En tant que père fondateur de Scrum, c'est une référence que je suis de près. Quand il publie un guide pour le scaling, ça mérite attention, d'autant plus que ce guide est le fruit de décennies d'expérience réelle, pas d'une conception théorique.

Contrairement à SAFe, Scrum@Scale pose un prérequis explicite : les équipes doivent maîtriser Scrum. Ce n'est pas une option, c'est le point de départ.

Ce prérequis dit quelque chose de la philosophie du framework. Scrum@Scale est conçu dans l'esprit de Scrum, pas au-dessus de lui. Le guide est court et délibérément non-prescriptif sur la façon de s'organiser : il vous fournit un cadre de coordination que vous adaptez à votre contexte, en y intégrant les pratiques, processus et outils qui ont déjà fait leurs preuves chez vous. C'est le même ADN que le Guide Scrum : minimaliste et inclusif par principe.

Un démarrage concret : le Reference Model. Avant d'étendre Scrum@Scale à toute une organisation, le guide recommande de constituer un petit groupe d'équipes pilotes capables de livrer ensemble à chaque Sprint. C'est ce qu'il appelle le Reference Model : une instance de référence, opérationnelle et saine, qui servira de prototype pour l'ensemble de l'organisation. Cette approche intègre d'emblée une stratégie de conduite du changement : prouver que ça fonctionne à petite échelle, corriger les défauts avant de les amplifier, puis étendre organiquement.

Une bureaucratie minimale, pas nulle. Scrum@Scale repose sur le principe de "Minimum Viable Bureaucracy" : le moins de structure possible pour atteindre les objectifs organisationnels, sans brider la livraison de valeur. Pas d'empilement de rôles, pas de niveaux de gouvernance superposés. Si un mécanisme de coordination n'apporte pas de valeur mesurable, il n'a pas sa place.

Une scalabilité linéaire. Contrairement aux frameworks qui imposent des niveaux d'organisation prédéfinis (Team, Program, Portfolio chez SAFe), Scrum@Scale est conçu pour grandir sans rupture de modèle. Une startup de trois équipes utilise le même framework qu'une organisation de cent équipes. On ajoute des équipes et des niveaux de coordination au fur et à mesure des besoins réels, pas selon un schéma imposé.

Deux mécanismes forment le coeur du système de coordination. L'Executive Action Team (EAT) est responsable de la transformation et de la suppression des obstacles qui dépassent les équipes. L'Executive MetaScrum porte la priorisation à haut niveau et connecte réseau agile et direction. Ces deux instances fonctionnent comme des interfaces connues entre la structure hiérarchique de l'organisation et son réseau agile, permettant aux deux de collaborer sans se court-circuiter.

Un périmètre délibérément universel. Scrum@Scale n'a pas été conçu exclusivement pour l'IT. La Royal Navy dispose d'un Agile Centre of Excellence et a adopté des pratiques Scrum@Scale. Safety Co., fabricant de systèmes de sécurité pour véhicules commerciaux avec plus d'un milliard de chiffre d'affaires, l'a déployé dans un secteur hautement régulé. C'est un choix délibéré : les principes qui rendent Scrum efficace dans une équipe logicielle sont les mêmes qui rendent Scrum@Scale efficace dans une organisation de manufacture ou de services.

Par ailleurs, le lien avec le "modèle Spotify" mérite un arrêt. Henrik Kniberg est l'un des coaches agiles les plus connus au monde : auteur de plusieurs livres distribués gratuitement qui ont formé des générations d'agilistes (Scrum et XP depuis les tranchées, Lean depuis les tranchées, Kanban et Scrum), conférencier mondial, il a notamment travaillé chez Spotify, Lego et Minecraft. C'est lui qui a formalisé ce que l'on appelle aujourd'hui le "modèle Spotify" dans un document publié en 2012 avec Anders Ivarsson. Il a depuis identifié rétrospectivement ce qu'il avait mis en place comme une instance précoce de Scrum@Scale : Squads, Tribes, Chapters et Guilds correspondent aux patterns SoS, MetaScrum et EAT.

Ce qui est moins souvent dit : Spotify ne l'utilise plus sous cette forme. Et l'erreur commise par beaucoup d'organisations n'a pas été de copier la terminologie, mais d'appliquer le modèle rigidement, sans l'adapter à leur propre contexte ni le faire évoluer au fil du temps. Le modèle Spotify n'était pas conçu pour être copié-collé. C'était un instantané d'une organisation à un moment donné, pas une recette universelle.

SAFe vs Scrum@Scale : les différences essentielles

SAFe et Scrum@Scale ne sont pas les seuls frameworks d'agilité à l'échelle. LeSS (Large-Scale Scrum), développé par Craig Larman et Bas Vodde depuis 2008, est une alternative sérieuse et très documentée, plus proche de la philosophie Scrum dans son souci de légèreté. Nexus, publié par Ken Schwaber via Scrum.org, couvre un périmètre plus restreint (3 à 9 équipes sur un même produit) et convient bien aux organisations qui démarrent le scaling sans vouloir embarquer un framework complet. Des approches plus récentes comme FAST (Ron Quartel) explorent d'autres directions, notamment autour du dynamic teaming. Le paysage est large. Le choix de se concentrer sur SAFe et Scrum@Scale dans cet article est délibéré : ce sont les deux frameworks les plus adoptés et les mieux documentés par des cas terrain mesurables.

Quand les deux se combinent : le cas Rocket Mortgage

Rocket Mortgage avait mis en place SAFe pour coordonner 2 000 de ses 26 000 collaborateurs. Les résultats étaient déjà significatifs. Mais l'un de ses Release Trains, le Client Marketing, a voulu aller plus loin et a ajouté Scrum@Scale.

Ce qui s'est passé ensuite est documenté dans un article académique peer-reviewed présenté à la conférence HICSS 2022 : sur ce périmètre, le cycle de livraison est passé de 83,7 jours à 11,6 jours (-86 %), le nombre de fonctionnalités livrées a augmenté de 721 % et le débit global de 340 %. Ces chiffres concernent l'équipe Client Marketing Release Train, pas l'ensemble de Rocket Mortgage.

Ajouter un second framework à une implémentation existante ne risque-t-il pas de complexifier encore les choses ? Chez Rocket Mortgage, c'est l'inverse qui s'est produit. L'équipe a commencé par revenir aux trois rôles du Guide Scrum, en retirant les nombreux rôles supplémentaires qu'avait introduits SAFe, soit selon les auteurs du papier (dont Sutherland lui-même) une quinzaine au total. Scrum@Scale n'a pas ajouté de la bureaucratie, il en a retiré. C'est le principe de Minimum Viable Bureaucracy à l'oeuvre.

SAFe et Scrum@Scale ne sont pas en compétition. SAFe structure la planification au niveau programme. Scrum@Scale optimise la livraison et la coordination inter-équipes au niveau opérationnel. Les deux peuvent coexister et se renforcer mutuellement.

Hiérarchie et réseau agile : le modèle Dual OS

Les grandes organisations font cohabiter des activités de nature très différente. Certaines sont encadrées par des processus mûrs, des contraintes réglementaires strictes ou des cycles longs et prévisibles : paie, comptabilité, conformité légale, achats. D'autres sont exposées à l'incertitude, aux changements fréquents de priorité, à la nécessité d'expérimenter rapidement : développement produit, innovation, marketing. L'agilité peut apporter de la valeur dans les deux cas ; Scrum permet d'ailleurs de mesurer la vélocité et de faire des projections fiables. Mais c'est là où l'incertitude est forte que les cycles itératifs courts font la plus grande différence.

John Kotter a théorisé ce modèle dans son livre XLR8 : une structure hiérarchique pour les activités stables, un réseau agile pour l'innovation et la livraison de valeur. Les deux fonctionnent en parallèle, avec des points d'interface connus et explicites. Sans ces interfaces, les deux systèmes se parasitent. Avec elles, ils se complètent.

Safety Co. l'a mis en pratique avec Scrum@Scale. Fabricant de systèmes de sécurité embarqués pour véhicules commerciaux, dans un secteur hautement régulé où les exigences de qualité et de conformité ne sont pas négociables. Les résultats : hausse de 40 % des livraisons dans les délais, progression de 43 % de la vélocité des équipes, certaines équipes à +300 %. L'Executive Action Team résout les obstacles en moyenne en 3 jours, souvent en moins de 24 heures.

Ce modèle répond à une objection fréquente : l'agilité à l'échelle, c'est pour les boîtes tech. Safety Co. produit des freins et des capteurs pour camions. L'enjeu est identique à celui de n'importe quelle organisation qui cherche à innover et livrer rapidement, tout en maintenant des standards élevés de qualité et de fiabilité.

Comment choisir selon votre contexte

Il n'y a pas de réponse universelle. Quelques repères, cependant.

Si vos équipes débutent en Agile et ont peu de maturité Scrum, SAFe fournit une structure initiale plus lisible. Mais n'ignorez pas l'étape : investissez d'abord dans la maîtrise de Scrum au niveau équipe. Sans cette base, SAFe produira davantage de conformité formelle que de résultats.

Si vos équipes maîtrisent Scrum et cherchent à se coordonner à grande échelle, Scrum@Scale est l'extension naturelle. L'apprentissage est rapide parce que les briques sont déjà connues. Vous commencez par un Reference Model, un petit groupe d'équipes pilotes, et vous étendez une fois que ça fonctionne.

Si vous avez déjà SAFe et sentez que vous plafonnez, le cas Rocket Mortgage montre que Scrum@Scale peut être la couche complémentaire qui déverrouille la performance, en simplifiant plutôt qu'en ajoutant.

Si vous êtes hors IT ou dans un secteur régulé, Scrum@Scale couplé au modèle Dual OS est la voie la plus documentée et la plus adaptée à votre réalité organisationnelle.

Au fond, la vraie question n'est pas "SAFe ou Scrum@Scale". Elle est plus fondamentale : vos équipes pratiquent-elles vraiment Scrum ? Sans cette fondation, aucun framework de scaling ne tiendra. C'est l'hypothèse implicite de SAFe. C'est le prérequis explicite de Scrum@Scale.

Votre organisation est-elle prête à passer à l'échelle ? Ou y a-t-il encore du travail à faire à l'échelle de l'équipe ?

Sources

• Digital.ai, State of Agile Report, éditions 2021, 2022, 2023. digital.ai/resource-center/analyst-reports/state-of-agile-report
• Diebold F., Bhola J., Sutherland J., Rocket Mortgage Delivers Twice the Value in Half the Time at Scale, HICSS 2022. Résumé et chiffres clés : scruminc.com/rocket-mortgage-delivers-twice-the-value-at-half-the-cost-at-scale
• Scrum Inc., Safety Co. Dual Operating System Case Study (anonymisé). scruminc.com/dual-operating-system-scrum-scale
• Kniberg H., Ivarsson A., Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds, Crisp, 2012. blog.crisp.se/wp-content/uploads/2012/11/SpotifyScaling.pdf
• Kniberg H. / Scrum Inc., Spotify : a Scrum@Scale Case Study, 2019. agileeducation.org/spotify-model-scrum-at-scale
• Kotter J., XLR8, Harvard Business Review Press, 2014.
• Scrum@Scale Guide, version 2.1. https://www.scrumatscale.com/scrum-at-scale-guide-online/
• Scaled Agile Framework — PI Planning. scaledagileframework.com/pi-planning