Agilité à l’échelle : SAFe, LeSS, unFIX et au-delà

Une équipe Scrum de sept personnes qui livre un produit en autonomie, c’est le cas d’école. La réalité des grandes organisations est différente : dix, trente, parfois cent équipes travaillent sur des produits qui se recoupent, avec des dépendances techniques, des arbitrages budgétaires et des calendriers communs. C’est là qu’intervient l’agilité à l’échelle, et c’est aussi là que se commettent les erreurs les plus coûteuses.

Ce guide fait le point sur les principaux cadres, de SAFe à unFIX, sans parti pris. Vous y trouverez un tableau comparatif, des critères pour choisir, le rôle que doit jouer le management, et les pièges à éviter. Nos articles détaillés sur chaque modèle sont liés au fil du texte.

Pourquoi passer à l’échelle, et quand ne pas le faire

Le besoin apparaît quand une seule équipe ne suffit plus à faire avancer un produit au rythme attendu. Plusieurs équipes doivent alors partager un même objectif, un même backlog ou un même calendrier de livraison, et leurs dépendances deviennent le principal frein.

Avant d’adopter un cadre, posez-vous trois questions :

• Les dépendances sont-elles inévitables ? Réorganiser les équipes autour des flux de valeur plutôt que des couches techniques (front, back, base de données) supprime souvent une bonne partie de la coordination nécessaire.
• Le produit peut-il être découpé ? Plusieurs produits indépendants, chacun porté par quelques équipes, sont plus simples à piloter qu’un produit géant.
• Les équipes savent-elles déjà livrer ? Passer à l’échelle des équipes qui ne livrent pas un incrément utilisable à chaque sprint, c’est multiplier les problèmes.

Si les réponses confirment le besoin, alors un cadre commun apporte un vocabulaire partagé, des événements de synchronisation et une gouvernance claire. Notre article 10 questions à se poser pour choisir un framework d’agilité à l’échelle détaille cette réflexion.

Les principaux cadres comparés

Le tableau simplifie volontairement : chaque cadre a ses variantes et évolue d’une version à l’autre.

SAFe : le plus répandu dans les grandes entreprises

Le Scaled Agile Framework est le cadre le plus adopté par les grands groupes, notamment parce qu’il propose une réponse complète : rôles, événements, artefacts, gouvernance financière et formation certifiante. Son unité de base est l’Agile Release Train, une équipe d’équipes qui planifie et livre ensemble. Le temps fort est la planification commune, appelée PI Planning : toutes les équipes du train se réunissent pendant deux jours pour aligner leurs objectifs sur les semaines qui viennent. Depuis la version 6.0, le sigle PI signifie Planning Interval.

Ses forces : un cadre lisible pour les directions, un vocabulaire commun, une prise en compte du portefeuille et du budget. Ses critiques : une certaine lourdeur, un risque de bureaucratie si l’on applique tout sans discernement, et parfois l’impression de rebaptiser l’existant sans changer la façon de travailler. Pour voir à quoi ressemble une planification commune réussie, lisez notre récit Monsieur Chatouille facilite un PI planning.

LeSS et Nexus : rester au plus près de Scrum

LeSS et Nexus partagent une même philosophie : ne pas ajouter de couche quand Scrum suffit. LeSS garde un seul Product Owner et un seul Product Backlog pour toutes les équipes, et pousse l’organisation à se simplifier plutôt qu’à se doter de nouveaux rôles. Au-delà de huit équipes environ, LeSS Huge introduit des domaines de besoins (Requirement Areas), chacun avec son propre Product Owner de domaine.

Nexus, proposé par Scrum.org, vise de trois à neuf équipes qui livrent un même incrément intégré. Il ajoute surtout une équipe d’intégration et des versions à l’échelle des événements Scrum (planification, Daily et rétrospective de Nexus). Ces deux cadres conviennent bien aux organisations déjà solides en Scrum, qui veulent éviter la lourdeur.

unFIX, FAST et équipes fluides : les alternatives

Une nouvelle génération de modèles part d’un constat : les organisations doivent changer de forme de plus en plus souvent, et les structures figées deviennent un frein.

• unFIX, créé par Jurgen Appelo, auteur du Management 3.0, n’est pas un framework mais une bibliothèque de motifs d’organisation : des bases regroupant plusieurs équipes, différents types d’équipes, des rôles qui se combinent. Chaque organisation y pioche ce qui lui convient. Nous le présentons dans unFIX model, c’est quoi ? et dans unFIX : entre dans l’ère des organisations adaptatives.
• FAST (Fluid Scaling Technology), proposé par Ron Quartel, organise un collectif de développeurs qui se répartit en équipes nouvelles à chaque cycle, selon les priorités du moment. Voir notre article sur FAST.
• Les équipes fluides poussent la logique jusqu’au bout : la stabilité de l’équipe n’est plus un dogme, l’important est la création de valeur. Lisez pourquoi les équipes agiles classiques limitent la création de valeur.

Dans la même veine, le livre Team Topologies de Matthew Skelton et Manuel Pais (2019) propose quatre types d’équipes (alignées sur un flux de valeur, de plateforme, facilitatrices et de sous-système complexe) et trois modes d’interaction entre elles. C’est un excellent outil pour réduire les dépendances avant même de choisir un cadre.

Ces modèles demandent une forte maturité : une culture de la confiance, des compétences larges et un management prêt à lâcher prise.

Le modèle Spotify : à lire, pas à copier

En 2012, Henrik Kniberg et Anders Ivarsson publient un court document décrivant l’organisation de Spotify : des squads autonomes, regroupées en tribes, avec des chapters par métier et des guilds transverses. Le texte a eu un succès considérable, et beaucoup d’entreprises ont rebaptisé leurs équipes en squads et leurs services en tribes.

C’est un contresens. Les auteurs décrivaient une situation à un moment donné, dans une culture particulière, et précisaient que l’organisation évoluait sans cesse. Copier les noms sans la culture d’autonomie et de confiance qui les accompagnait ne produit que de la confusion. Le modèle reste une excellente source d’inspiration, à condition d’en retenir les principes et non l’organigramme.

Comment choisir son cadre

Il n’existe pas de bon cadre dans l’absolu, seulement des cadres plus ou moins adaptés à votre situation. Quelques critères pour trancher :

• La maturité en Scrum : des équipes déjà autonomes tireront le meilleur de LeSS ou de Nexus ; des équipes qui débutent ont souvent besoin du cadre plus guidé de SAFe.
• La taille et la structure : trois équipes sur un produit n’ont pas les mêmes besoins que quarante équipes sur un portefeuille.
• Le niveau d’engagement de la direction : un cadre qui touche la gouvernance et le budget, comme SAFe, échoue sans soutien au plus haut niveau.
• La culture : une organisation très hiérarchique adoptera plus facilement un cadre structuré, une organisation habituée à l’autonomie se sentira à l’étroit dans un cadre prescriptif.
• Le rythme de changement : si votre marché impose de se réorganiser souvent, regardez du côté d’unFIX ou des équipes fluides.

Et surtout : commencez par un périmètre limité (un train, un produit, un domaine), mesurez les effets, puis élargissez. Pour tester vos connaissances avant de vous lancer, essayez notre quiz Agilité à l’échelle, êtes-vous incollable ?

Le rôle du management dans le passage à l’échelle

Aucun cadre ne fonctionne si le management continue à piloter comme avant. Les managers de proximité doivent passer du contrôle des tâches au développement des personnes et à la levée des obstacles, et les directions doivent accepter de financer des flux de valeur plutôt que des projets. Le Management 3.0 apporte beaucoup d’outils pour cela, comme nous l’expliquons dans Du Management 3.0 pour se poser les bonnes questions lors du passage à l’échelle et dans notre guide du Management 3.0.

La planification aussi change de nature : elle se fait à plusieurs niveaux, du portefeuille à l’équipe, avec des horizons différents. Notre guide de la planification agile détaille ces niveaux.

Les erreurs les plus fréquentes

• Choisir un cadre avant de comprendre le problème : adopter SAFe ou Spotify parce qu’un concurrent l’a fait, sans avoir identifié ce qui ralentit réellement la livraison.
• Passer à l’échelle des équipes qui ne livrent pas : si une équipe seule n’arrive pas à produire un incrément utilisable, en synchroniser dix n’arrangera rien.
• Ajouter des couches sans en retirer : un nouveau cadre qui vient s’empiler sur les comités, les jalons et les reportings existants alourdit tout.
• Ne rien mesurer : sans indicateurs de délai, de qualité et de valeur livrée, il est impossible de dire si la transformation porte ses fruits. Les métriques DORA et le cadre SPACE sont de bons points de départ.
• Oublier les personnes : une réorganisation à grande échelle bouscule les rôles, les statuts et les habitudes. Elle se prépare avec les équipes, pas contre elles.

Questions fréquentes sur l’agilité à l’échelle

Sources et références

• Scaled Agile, présentation de SAFe 6.0, mars 2023 : scaledagileframework.com
• LeSS Company, Large-Scale Scrum (LeSS) : less.works
• Scrum.org, The Nexus Guide : www.scrum.org
• Scrum@Scale, site officiel : www.scrumatscale.com
• Henrik Kniberg et Anders Ivarsson, Scaling Agile @ Spotify, 2012 : blog.crisp.se
• The unFIX Company, questions fréquentes sur le modèle unFIX : unfix.com
• Matthew Skelton et Manuel Pais, Team Topologies, 2019 : teamtopologies.com