Agilité

SAFe et agilité à l'échelle : quand et comment passer de Scrum au Scaled Agile Framework

Par Codevista InnovationsPublié le 12 octobre 2026Mis à jour le 15 octobre 202610 min de lecture

SAFe (Scaled Agile Framework) se justifie lorsque plusieurs équipes agiles livrent ensemble une même solution et que les dépendances, les priorités divergentes et l'intégration tardive annulent ce que chaque équipe gagne avec Scrum. Il ajoute une structure, l'Agile Release Train, un événement de planification commun, le PI Planning, et une gestion de portefeuille Lean, au prix de rôles et d'événements supplémentaires. Avant de l'adopter, vérifiez que votre problème vient bien de la coordination entre équipes, et que la direction est prête à s'impliquer elle-même.

Comment savoir si Scrum ne suffit plus ?

Scrum est conçu pour une équipe resserrée qui peut livrer seule un incrément utilisable. Tant qu'un produit tient dans une ou deux équipes, mieux appliquer Scrum ou passer à Kanban règle souvent l'essentiel (voir notre comparatif Scrum ou Kanban). Les difficultés changent de nature quand plusieurs équipes travaillent sur la même solution :

• Dépendances en cascade : une équipe attend une API, un environnement ou une validation d'une autre, et le sprint se termine sans incrément utilisable.
• Priorités désalignées : chaque Product Owner optimise son propre backlog, personne n'arbitre entre les équipes, et le métier reçoit des morceaux de fonctionnalités qui ne servent à rien isolément.
• Intégration douloureuse : chaque équipe se déclare « terminé » de son côté, puis l'assemblage en fin de trimestre ressemble trait pour trait à l'ancienne phase d'intégration du cycle en V.
• Aucune visibilité pour la direction, qui finit par réclamer des plannings détaillés à six mois, en contradiction avec les sprints.

Un test simple : relisez les obstacles remontés lors des dernières rétrospectives. S'ils concernent surtout le fonctionnement interne de chaque équipe, le problème n'est pas l'échelle. S'ils renvoient systématiquement à une autre équipe, à un arbitrage manquant ou à une intégration tardive, la question de l'agilité à l'échelle devient légitime.

Ce que SAFe ajoute : Agile Release Train, PI Planning et portefeuille

Le Scaled Agile Framework ne remplace pas Scrum ou Kanban au niveau des équipes : il les organise autour d'un flux de valeur commun. Le référentiel officiel, qui fait foi pour la terminologie et évolue de version en version, est publié sur scaledagileframework.com.

L'Agile Release Train (ART)

Un ART est une équipe d'équipes agiles, stable dans le temps, qui partage la même mission, le même ART Backlog et la même cadence. Il reste volontairement de taille limitée, de l'ordre de 50 à 125 personnes selon le référentiel, pour que tout le monde puisse planifier dans la même pièce. Le Release Train Engineer (RTE) en est le facilitateur, le Product Management priorise les features, le System Architect porte la vision technique, et les Business Owners représentent les intérêts métier et valident les objectifs.

Le PI Planning

Le PI (Planning Interval, anciennement Program Increment) regroupe plusieurs itérations, suivies d'une itération d'innovation et de planification (IP Iteration). Au début de chaque PI, toutes les équipes du train se réunissent pour le PI Planning, généralement sur deux jours : elles découpent les features, rendent les dépendances visibles sur l'ART Planning Board et s'engagent sur des PI Objectives. En cours de PI, la System Demo montre l'incrément intégré de tout le train ; le PI se clôt par un Inspect & Adapt.

Le niveau portefeuille

Dans la configuration Portfolio SAFe, la Lean Portfolio Management finance des flux de valeur plutôt que des projets un par un, et les Epics passent par un Portfolio Kanban avant d'être approuvées. C'est souvent là que se joue le vrai changement pour une direction générale, parce qu'il touche au budget et à la gouvernance, pas seulement à la façon de travailler des équipes.

Combien coûte SAFe en cérémonies et en organisation ?

Le coût de SAFe ne se résume pas à une facture de formation. Il se mesure surtout en temps et en attention :

• Des rôles nouveaux (RTE, Product Management, System Architect), tenus par des personnes réellement disponibles, et non ajoutés à un poste déjà plein.
• Des événements supplémentaires : PI Planning, System Demo, Inspect & Adapt, synchronisations régulières entre équipes, affinage des features en amont.
• Un vocabulaire commun à faire adopter par toute l'organisation, donc de la formation pour les équipes, les managers et les dirigeants.
• Un cadre propriétaire : SAFe est une marque de Scaled Agile, Inc., qui délivre les certifications officielles ; cela pèse sur le budget de formation et de certification.
• Un risque de bureaucratie si le cadre est appliqué mécaniquement, artefact par artefact, sans se demander ce que chacun apporte.

Ce coût se justifie quand il remplace des coordinations informelles déjà coûteuses : réunions de crise, arbitrages par escalade, semaines perdues en intégration. Il ne se justifie pas pour deux équipes qui pourraient simplement partager un backlog et une revue.

SAFe, LeSS, Scrum@Scale ou Kanban : quelles alternatives ?

SAFe est le cadre le plus outillé et le plus prescriptif, mais il n'est pas le seul. Les alternatives ne sont ni meilleures ni moins bonnes par principe ; elles font d'autres paris :

• LeSS (Large-Scale Scrum) : un seul Product Owner et un seul Product Backlog pour plusieurs équipes, très peu de rôles ajoutés. Exigeant sur la maturité technique et la refonte de l'organisation.
• Scrum@Scale : une extension modulaire de Scrum, qui fait grandir l'organisation par réseaux d'équipes reliés entre eux.
• Nexus : le cadre de Scrum.org pour quelques équipes Scrum travaillant sur un même produit, avec une équipe d'intégration dédiée.
• Un Kanban de portefeuille bien tenu : rendre visibles toutes les initiatives en cours, limiter le travail en cours au niveau de la direction et arbitrer à intervalles réguliers. C'est souvent le premier pas le moins coûteux, et il prépare n'importe quel cadre ultérieur.

SAFe convient surtout aux grands ensembles qui ont besoin de rôles explicites, d'une gouvernance de portefeuille et d'un langage commun avec la direction. Pour un produit porté par trois ou quatre équipes, un cadre plus léger est généralement plus proportionné.

Pourquoi un déploiement SAFe échoue-t-il ?

Les échecs se ressemblent d'une organisation à l'autre :

• Des trains organisés par département plutôt que par flux de valeur : ils reproduisent les silos sous un nouveau nom.
• Des équipes qui ne maîtrisent pas Scrum : sans itérations stables ni Definition of Done partagée, l'échelle amplifie le désordre.
• Un PI Planning imposé : la direction arrive avec un périmètre et une date fixés, sans tenir compte de la capacité annoncée par les équipes.
• Des priorités modifiées en cours de PI sans passer par le Product Management, ce qui vide les PI Objectives de leur sens.
• Des pratiques techniques faibles : sans intégration continue ni tests automatisés, la System Demo montre des écrans, pas un système intégré.
• Un cadre adopté pour l'image, sans mesure du flux ni des résultats métier.

Aucune de ces causes ne tient au cadre lui-même : elles sont organisationnelles. C'est pourquoi la préparation compte davantage que le choix entre SAFe et ses concurrents.

Comment préparer un premier PI Planning ?

Un premier PI Planning se prépare sur plusieurs semaines. Les étapes essentielles :

1. Identifier le flux de valeur et les équipes qui y contribuent, y compris les fonctions support indispensables (sécurité, exploitation, conformité).
2. Nommer et former les rôles clés : RTE, Product Management, System Architect, Business Owners, ainsi que les Scrum Masters et Product Owners des équipes.
3. Construire l'ART Backlog : des features priorisées, avec critères d'acceptation et hypothèse de valeur métier. Les exigences réglementaires, comme la protection des données personnelles au titre de la loi 09-08, y figurent dès le départ, pas en fin de PI.
4. Préparer la vision que la direction présentera en ouverture : contexte métier, objectifs, contraintes, jalons connus.
5. Calculer la capacité de chaque équipe, en tenant compte des congés, des jours fériés et de la part réservée à la maintenance.
6. Organiser la logistique : salle ou outil collaboratif, ART Planning Board, ordre du jour minuté, décideurs présents du début à la fin.

Pendant l'événement

Le déroulé type alterne séquences plénières et travail en équipes : présentation du contexte métier, de la vision produit et de la vision d'architecture, puis ateliers où chaque équipe construit son plan d'itérations. Une revue des plans provisoires et une séance de résolution de problèmes avec la direction permettent d'ajuster le périmètre. Le second jour, les équipes présentent leurs plans finaux, les risques sont traités selon la méthode ROAM (Resolved, Owned, Accepted, Mitigated) et un vote de confiance clôt l'exercice. Un vote faible n'est pas un échec : c'est le signal qu'il faut replanifier avant de s'engager.

Quand les équipes sont réparties entre plusieurs sites, à Casablanca, ailleurs au Maroc ou à l'étranger, un format hybride bien outillé fonctionne, à condition que les Business Owners restent joignables pour arbitrer pendant les deux jours.

Ce que la direction doit engager pour réussir SAFe

SAFe ne se délègue pas à la DSI. La direction générale doit :

• Participer : les Business Owners assistent au PI Planning, à la System Demo et à l'Inspect & Adapt, et attribuent une valeur métier aux PI Objectives.
• Financer des flux de valeur plutôt que des projets, ce qui suppose de revoir le cycle budgétaire.
• Protéger le PI : pas d'urgences réinjectées sans arbitrage, peu d'initiatives menées en parallèle.
• Porter la transformation : désigner une équipe de pilotage, que le référentiel appelle Lean-Agile Center of Excellence (LACE), et lui donner du temps et de l'autorité.
• Se former au leadership agile et accepter que plusieurs PI soient nécessaires avant qu'un train trouve son rythme.

Les fonctions RH, finance ou marketing sont concernées dès que les flux de valeur les traversent (voir l'agilité au-delà de l'IT). Pour une PME, une démarche plus légère s'inscrit souvent mieux dans une transformation digitale progressive.

Codevista Innovations propose une formation SAFe pour les organisations qui dépassent le cadre d'une seule équipe, et une formation Scrum pour consolider les bases, en présentiel partout au Maroc, en hybride ou à distance. Notre dossier de qualification auprès de l'OFPPT est en cours : ces programmes ne sont donc pas encore finançables par les Contrats Spéciaux de Formation (CSF). Pour évaluer si SAFe correspond à votre situation, contactez notre équipe.

Questions fréquentes

Combien d'équipes faut-il pour justifier SAFe ?

Il n'y a pas de seuil magique. Un Agile Release Train réunit plusieurs équipes agiles qui livrent une même solution, de l'ordre de 50 à 125 personnes selon le référentiel. Avec deux ou trois équipes, un backlog commun, des revues conjointes ou un cadre léger comme Nexus ou LeSS suffisent souvent. Le critère décisif est le niveau de dépendance entre équipes et le besoin d'une planification commune visible par la direction.

Quelle différence entre PI Planning et Sprint Planning ?

Le Sprint Planning concerne une seule équipe et une itération. Le PI Planning réunit toutes les équipes d'un Agile Release Train, avec le Product Management, l'architecture et les Business Owners, pour planifier ensemble un Planning Interval de plusieurs itérations. Il rend visibles les dépendances et aboutit à des PI Objectives. Chaque équipe garde ensuite sa propre planification d'itération à l'intérieur du PI.

Faut-il maîtriser Scrum avant de passer à SAFe ?

Oui, c'est fortement recommandé. SAFe s'appuie sur des équipes capables de livrer un incrément fonctionnel à chaque itération, avec des rôles clairs et une Definition of Done partagée. Si les équipes peinent déjà avec les fondamentaux, la mise à l'échelle amplifie les problèmes au lieu de les résoudre. Consolider Scrum ou Kanban au niveau des équipes est donc souvent la première étape.

Une formation SAFe peut-elle être financée par l'OFPPT au Maroc ?

Le dispositif existe : les Contrats Spéciaux de Formation (CSF) de l'OFPPT permettent à l'entreprise de récupérer une partie de ses frais de formation. Le dossier de qualification de Codevista Innovations est en cours ; d'ici là, ses programmes, dont la formation SAFe, ne sont pas finançables par ce dispositif. Les conditions d'accès et la procédure sont fixées par l'OFPPT : vérifiez-les directement auprès de l'organisme avant d'engager la démarche. Notre article sur le financement CSF détaille le principe.