Lexique

Le vocabulaire de l’agilité à l’échelle, expliqué

ART, PI Planning, WSJF, ROAM, Architectural Runway : SAFe® a produit un vocabulaire dense, que les définitions officielles expliquent souvent avec d’autres termes du même vocabulaire. Voici 22 notions définies en français courant, avec ce qu’elles changent concrètement — et la formation qui les approfondit.

Structure

Agile Release TrainART: L'unité d'organisation centrale de SAFe : un ensemble d'équipes — typiquement cinq à douze, soit cinquante à cent vingt personnes — qui travaillent sur une même cadence, vers une mission commune, et livrent ensemble. Le train est dit « long-lived » : il persiste, contrairement à un projet qui se dissout à sa livraison. C'est le passage du financement de projets au financement d'équipes stables qui rend un ART possible.
Program IncrementPI: L'horizon de planification d'un ART : huit à douze semaines, généralement quatre itérations de développement plus une itération d'innovation et de planification. Le PI donne au train un rythme commun et un point de rendez-vous régulier avec le métier. Depuis SAFe 6.0, la documentation parle aussi de « Planning Interval » — même objet, terminologie ajustée.

Événements

PI Planning: L'événement qui ouvre chaque Program Increment : deux journées pendant lesquelles toutes les équipes du train planifient ensemble, identifient leurs dépendances et prennent un engagement collectif. C'est le point de synchronisation qui distingue le plus visiblement SAFe d'un empilement d'équipes Scrum. Sa préparation, souvent sous-estimée, conditionne largement sa réussite.
Programme Board: Le mur — physique ou numérique — construit pendant le PI Planning : une colonne par itération, une ligne par équipe, les Features positionnées et les dépendances matérialisées par des fils entre elles. Il rend visible d'un coup d'œil ce qu'aucun document ne montre : qui attend quoi, et quand.
Inspect & AdaptI&A: L'événement de clôture d'un PI : démonstration de l'incrément complet, revue des métriques, puis atelier structuré de résolution de problèmes. La différence avec une rétrospective d'équipe tient à l'échelle et à l'engagement : les améliorations retenues entrent dans le backlog du PI suivant, avec un porteur.
System Demo: La démonstration de l'incrément intégré de tout le train, à la fin de chaque itération. Elle se distingue de la revue d'équipe : ce qui est montré, c'est le système assemblé, pas la contribution isolée d'une équipe. C'est souvent le premier endroit où les problèmes d'intégration deviennent visibles.

Rôles

Release Train EngineerRTE: Le chef d'orchestre de l'ART : il prépare et anime les événements du train, coache les Scrum Masters, tient la vue des dépendances et des risques, et porte l'amélioration continue. C'est un rôle de serviteur-leader, pas de chef de projet : il ne décide pas du contenu, il fait fonctionner le système qui le produit.
Product Owner / Product ManagerPO / PM: Deux rôles distincts et complémentaires. Le Product Manager porte la vision et le backlog des Features au niveau du train, en dialogue avec le marché. Le Product Owner porte le backlog des Stories au niveau de l'équipe, au quotidien. La frontière entre les deux est l'un des points les plus mal compris de SAFe, et l'une des causes les plus fréquentes de friction.
System ArchitectARCH: L'architecte responsable de la cohérence technique d'un ou plusieurs trains. Sa contribution ne passe pas par la validation de chaque décision — ce qui ferait de lui un goulot d'étranglement — mais par l'intention architecturale et le Architectural Runway. À ne pas confondre avec ASE, sigle du cursus SAFe® Agile Software Engineering, qui porte sur les pratiques d'ingénierie.
Business Owner: Les quelques responsables métier qui portent la responsabilité économique de ce que produit le train. Ils présentent le contexte business au PI Planning, participent à l'attribution des valeurs métier et votent la confiance. Leur absence à ces moments est l'un des signaux les plus fiables d'une transformation qui n'a pas embarqué la direction.

Priorisation

Weighted Shortest Job FirstWSJF: La méthode de priorisation de SAFe : on divise le coût du délai — valeur métier, criticité temporelle, réduction de risque ou création d'opportunité — par la taille de l'effort. On traite d'abord ce qui a le meilleur rapport. L'intérêt du WSJF n'est pas tant le chiffre obtenu que la conversation qu'il force entre métier et technique pour l'obtenir.
Coût du délaiCost of Delay: Ce que coûte le fait de ne pas livrer quelque chose maintenant. C'est le numérateur du WSJF, et le concept qui permet de sortir des débats de priorité fondés sur le pouvoir de conviction. Un élément peut être très important et pourtant attendre, si son coût du délai est faible.
Epic, Feature, Story: Les trois niveaux de granularité du travail dans SAFe. L'Epic vit au portefeuille et demande un dossier d'investissement ; la Feature vit au niveau du train et tient dans un PI ; la Story vit dans l'équipe et tient dans une itération. Le découpage entre ces niveaux est un exercice concret, pas une taxonomie : mal fait, il produit des Features qui ne tiennent jamais dans un PI.

Flux & mesure

ROAM: La méthode de traitement des risques au PI Planning : chaque risque identifié est classé Resolved (résolu), Owned (pris en charge par quelqu'un), Accepted (accepté tel quel) ou Mitigated (atténué par une action). L'intérêt tient à ce qu'aucun risque ne peut rester sans statut — c'est le refus explicite de la liste de risques que personne ne relit.
Architectural Runway: L'avance technique — code, infrastructure, composants — déjà en place et qui permet d'implémenter les prochaines Features sans refonte. Trop court, le runway force des retards ; trop long, il consomme de l'effort sur des besoins qui n'existeront peut-être jamais. L'arbitrage entre les deux est l'un des sujets centraux du rôle d'architecte.
Enabler: Un élément de backlog qui ne produit pas de valeur visible pour le client mais rend possible celle qui suivra : travaux d'architecture, d'infrastructure, de conformité, ou exploration. Les rendre visibles dans le backlog, au lieu de les cacher dans les estimations, est ce qui permet d'en discuter le financement.
Métriques de fluxFlow metrics: Les indicateurs qui décrivent comment le travail traverse le système plutôt que combien les équipes sont occupées : distribution du flux, vélocité de flux, temps de traversée, charge en cours, efficience du flux. SAFe 6.0 leur a donné une place centrale. Leur adoption change souvent plus les comportements que n'importe quelle réorganisation.
Lean budgeting: Le financement de flux de valeur durables plutôt que de projets à périmètre fixe. Les équipes reçoivent un budget et une direction, encadrés par des garde-fous, au lieu d'un cahier des charges validé un an plus tôt. C'est le changement qui débloque le plus souvent les transformations arrivées au plafond.
Portfolio Kanban: Le tableau qui rend visible le flux des Epics, de l'idée à la mise en œuvre, avec des limites d'en-cours à chaque étape. Sa fonction principale est moins d'accélérer que de rendre les arbitrages explicites : une limite d'en-cours atteinte oblige à décider ce qu'on arrête pour démarrer autre chose.

IA

AI-Native: La désignation retenue par Scaled Agile pour une organisation dont les processus sont repensés autour de l'intelligence artificielle, et non pas simplement outillés avec elle. La distinction est opérationnelle : plaquer un assistant sur un processus inchangé produit un gain marginal ; repenser le processus en supposant l'IA disponible produit autre chose.
POC graveyard: Le cimetière de preuves de concept : ces démonstrations d'IA réussies qui n'atteignent jamais la production, faute de propriétaire, de modèle économique ou de chemin d'industrialisation. C'est le symptôme le plus répandu des programmes d'adoption IA, et le point de départ du cursus AI-Native Value Architect.
Context engineering: La discipline consistant à préparer et structurer le contexte fourni à un modèle de langage — documents, conventions, exemples, contraintes — pour qu'il produise un travail exploitable. Dans une chaîne de livraison pilotée par des agents, c'est le facteur qui sépare une démonstration réussie d'un dispositif utilisable en production.

Ces notions s’apprennent mieux en les pratiquant

Nos formations certifiantes SAFe® les font vivre en simulation plutôt qu’en diapositives — à commencer par le PI Planning, que l’on comprend mal sur le papier.

Quelle certification choisir ?Voir le catalogue