REX #5 · Méthodo Agile · SAFe
Implémenter SAFe en contexte IT Cloud & On-Premise
SAFe n'est pas réservé aux éditeurs logiciels. Sur les programmes d'infrastructure complexes — migration datacenter, adoption cloud hybride, replatforming serveur — c'est l'approche la plus robuste pour coordonner plusieurs équipes techniques en parallèle. Voici six piliers d'implémentation issus de mon expérience terrain.
Par Philippe Damas
· PMP® · ITIL v3 · SAFe
· ~13 min de lecture
L'essentiel
Un programme IT Agile ne dérape pas à cause de la technique. Il dérape à cause d'une organisation d'équipes floue, de dépendances inter-Squads mal gérées, d'un planning non partagé, de risques non priorisés et d'un pipeline de livraison sans filet de sécurité. Ces sept piliers sont interdépendants — négliger l'un fragilise les six autres.
🚂
Pilier 01
Structure de l'ART
👥
Pilier 02
Rôles clés SAFe
🔄
Pilier 04
PO Sync & Dépendances
⚠️
Pilier 05
ROAM — Risques
🔒
Pilier 06
DevSecOps & Compliance
🏗️
Pilier 07
Architecture & Runway
Sur un programme IT complexe, constituer une grande équipe projet unique est tentant — et contre-productif. Dès que plusieurs domaines coexistent (réseau, serveur, cloud, sécurité, DRP), la coordination centrale devient un goulot d'étranglement. SAFe répond à ce problème avec l'Agile Release Train (ART) : 50 à 125 personnes réparties en Squads de 6 à 12 membres, chacune mono-spécialisée et cross-fonctionnelle. Les dépendances entre Squads existent — elles sont rendues visibles, documentées et gérées explicitement, pas subies.
Règles d'or pour constituer un ART IT
Une Squad = un domaine technique cohérent — Réseau, serveurs, cloud/IaC, sécurité, DRP. Pas de Squad "divers". Un périmètre flou = conflits de priorité permanents.
6 à 12 personnes par Squad — pas plus — Au-delà de 12, la coordination interne pèse sur les cérémonies. Diviser plutôt que laisser dériver.
Cadence commune à toutes les Squads — Tous les sprints démarrent et finissent le même jour. Sans cette synchronisation, le Program Board devient illisible.
Dépendances cartographiées dès le départ — Sur un programme infra, un livrable réseau peut bloquer la Squad cloud qui bloque à son tour les tests DRP. Ces chaînes doivent être cartographiées avant le premier sprint.
Un RTE (Release Train Engineer) nommé dès le kick-off — Chef d'orchestre de l'ART. Sans RTE, personne n'arbitre les dépendances critiques — les Squads fonctionnent en silos.
💡
SAFe sur un contexte hybride Cloud / On-Premise
La bonne approche : une Squad dédiée à l'IaC (Terraform, Ansible) possède les modules de déploiement et les conventions de nommage. Les Squads applicatives consomment ces modules sans gérer la plomberie cloud. Cette séparation réduit les dépendances et la dette technique — et clarifie les responsabilités en cas d'incident.
« Constituer un ART, ce n'est pas dessiner un organigramme. C'est décider à l'avance comment les équipes vont se synchroniser, pas seulement comment elles vont travailler en isolation. »
SAFe en contexte IT — De mon expérience terrain, 25 ans
La confusion entre les rôles SAFe est l'une des premières causes d'échec des déploiements. SM, RTE et PO ne correspondent pas aux intitulés classiques (chef de projet, PMO, chef de lot) — voici une lecture directe pour un contexte infrastructure.
SM
Scrum Master
1 par Squad · Niveau équipe
Facilite les 4 cérémonies sprint (Planning, Daily, Review, Rétro), retire les obstacles, protège l'équipe des interruptions.
Ne fait PAS
Décisions techniques, arbitrages inter-Squads, pilotage de programme. Il coache, ne manage pas.
Profil type
Ingénieur senior promu, coach Agile. Pas obligatoirement un manager IT.
RTE
Release Train Engineer
1 par ART · Niveau programme
Anime le PI Planning, le PO Sync hebdo et le ROAM Board. Gère les dépendances entre Squads et escalade les blocages vers les Business Owners.
Profil type
IT Program Manager senior ou PMO Agile expérimenté. Transposition directe du chef de programme dans le référentiel SAFe — si vous avez géré des programmes multi-équipes en mode PMP, c'est votre rôle.
Point de vigilance
Le RTE n'est pas un "super Scrum Master". Il ne gère pas les sprints — il orchestre l'ART.
PO
Product Owner
1 par Squad · Interface métier
Tient et priorise le backlog. Définit le QUOI (User Stories, critères d'acceptance), valide les livrables à chaque Sprint Review.
Ne fait PAS
Le COMMENT — domaine de la Squad. Le PO représente la valeur business, pas la technique.
Profil type infrastructure
Architecte cloud connaissant les 40 applications à migrer, ou responsable sécurité pour la Squad compliance/DORA.
⚠️
L'erreur la plus fréquente : cumuler les rôles
Nommer une même personne RTE et PO d'une Squad "pour économiser des ressources" est une fausse économie. Le RTE qui porte un backlog Squad ne peut pas arbitrer objectivement les dépendances — sa neutralité est sa valeur principale. Si les ressources sont contraintes, réduisez le nombre de Squads plutôt que de diluer les rôles.
Le PI Planning est souvent perçu comme une cérémonie lourde et coûteuse — deux jours de réunion avec toutes les Squads, toutes les 10 semaines. C'est en réalité l'investissement le plus rentable d'un programme SAFe. Avant de l'implémenter, j'ai souvent entendu : « on ne peut pas se permettre deux jours sans produire ». Après, la réponse est invariablement : « on ne pouvait pas se permettre de ne pas le faire ».
La raison est simple : le PI Planning est le seul moment où toutes les dépendances entre Squads sont rendues visibles simultanément. Sans lui, chaque Squad planifie dans son coin et découvre en cours de sprint que son livrable est conditionné par un autre qui lui-même est en retard. Sur un programme infrastructure, où un déploiement réseau conditionne un déploiement cloud qui conditionne des tests DRP, ce problème est systémique.
J1
Jour 1 matin — 08h30
Business Context & Product Vision
Même cadrage pour toutes les Squads : objectifs du PI, contraintes réglementaires (DORA, NIS2), priorités DSI. L'alignement avant la planification autonome.
J1
Jour 1 après-midi — 14h00
Breakout Squads — Planification en autonomie
Chaque Squad planifie ses User Stories sprint par sprint et cartographie ses dépendances sortantes et entrantes. La valeur se crée ici.
J1
Jour 1 fin de journée — 16h00
Draft Plan Review — Mise en commun
5 minutes par Squad : objectifs, dépendances, risques. Le RTE note les conflits et prépare J2.
J2
Jour 2 matin — 09h00
Dependency Review — La session critique
Le RTE anime. Chaque dépendance est portée sur le Program Board ; les Squads négocient dates et capacités. C'est ici que réseau → cloud → DRP se séquencent — ou se réajustent.
J2
Jour 2 — 11h00
Risk ROAM — Chaque risque classifié
Chaque risque classifié R/O/A/M avec un propriétaire. Non traité ici, il a 10 semaines pour se matérialiser. Voir Pilier 05.
J2
Jour 2 — 14h00 → Vote
Final Plan & Vote de confiance
PI Objectives signés. Vote 1→5 doigts — moyenne < 3 = plan ajusté avant de partir. Ce mécanisme force l'honnêteté : personne ne peut invoquer le doute six semaines plus tard.
✅
Output du PI Planning : deux documents de référence
PI Objectives signés (committed vs stretch goals) et Program Board des dépendances inter-Squads. Ces deux documents pilotent le programme jusqu'au prochain PI — ils remplacent un Gantt de 200 lignes que personne ne lit.
Avant le PI Planning
Backlog Squad priorisé
Chaque PO arrive avec un backlog épuré : les features à traiter dans le PI sont identifiées et grossièrement estimées. Arriver sans backlog préparé, c'est perdre le Jour 1 à trier plutôt qu'à planifier.
Après le PI Planning
Program Board complet
Toutes les dépendances visibles, datées, avec un propriétaire. Si une dépendance ne figure pas sur le Program Board, elle n'existe pas officiellement — et elle surprendra tout le monde à mi-PI.
Output Squad
PI Objectives signés
La liste des features engagées (committed) et des stretch goals. Un committed ne peut pas être retiré sans escalade au RTE. C'est la différence entre un backlog et un engagement.
Output Programme
ROAM Board initial
Tous les risques identifiés pendant le PI Planning, classifiés et avec un propriétaire nommé. Il sera mis à jour à chaque PO Sync. Un risque sans propriétaire est un risque ignoré.
« Le PI Planning n'est pas une réunion de plus. C'est le seul moment où toutes les dépendances du programme sont rendues visibles simultanément. Le supprimer pour "économiser du temps", c'est décaler ce temps de plusieurs PI plus tard, en mode urgence. »
SAFe en contexte IT — De mon expérience terrain, 25 ans
Entre deux PI Planning, les Squads se désynchronisent si aucun mécanisme ne force la visibilité hebdomadaire. Le PO Sync — 30 minutes, RTE + tous les POs — est cette mécanique. Règle fondamentale : c'est une réunion de déblocage, pas de reporting. Si tout est vert, elle dure dix minutes. Si une dépendance est rouge, le RTE sort avec une décision — pas une liste d'actions.
Agenda type — PO Sync 30 minutes
0–5 min : Tour de table statut dépendances — Chaque PO dit vert / orange / rouge sur ses dépendances actives. Pas de détail — juste le statut.
5–15 min : Focus sur les blocages orange et rouge — Le RTE anime en posant la question directe : "Squad X, tu devais livrer Y avant Sprint 3. Où tu en es ?" Pas de généralités, pas de digressions techniques — juste la réponse à la question.
15–25 min : Actions correctives décidées — Réaffectation de ressource, réduction de scope, acceptation du risque documentée, ou escalade au Business Owner si l'impact dépasse les PI Objectives. Le RTE décide — il ne consulte pas.
25–30 min : Mise à jour du Program Board — Jira/Confluence mis à jour en direct. CR en cinq lignes envoyé dans la foulée : statut, décisions, actions, risques ajoutés au ROAM Board.
💡
Exemple concret : dépendance réseau → cloud bloquante
La Squad réseau prend une semaine de retard sur le VNet Peering Azure. La Squad cloud/IaC ne peut pas déployer ses modules Terraform. Identifié au PO Sync semaine 4 en moins de 3 minutes. Décision RTE : un ingénieur réseau est détaché 4 jours vers la Squad bloquante. Déploiement cloud décalé de 4 jours dans le sprint — pas sur le sprint suivant. Business Owner informé, zéro impact PI Objectives. Sans PO Sync, ce blocage aurait consommé le sprint entier.
⚠️
Le PO Sync ne doit pas devenir un Copil déguisé
La dérive classique : chaque Squad présente son avancement en détail. Résultat : 90 minutes, aucune décision, les blocages réels noyés dans le reporting. Règle stricte — si un sujet dépasse 5 minutes, il n'a pas sa place en PO Sync. Un atelier dédié entre les Squads concernées, animé par le RTE, hors plénière.
Contrairement au Risk Register mensuel sorti au Copil, la méthode ROAM — Resolved, Owned, Accepted, Mitigated — impose que tout risque soit classifié, doté d'un propriétaire nommé et suivi chaque semaine. En contexte infra, les risques dominants sont rarement techniques : coordination (dépendance non tenue), conformité (fenêtre de maintenance non validée), capacité (ressources partagées entre Squads). ROAM les traite explicitement plutôt que de les laisser se gérer eux-mêmes.
R
Resolved — Éliminé
Éliminé pendant le PI Planning. Décision sur le champ — ressource réaffectée, scope réduit. Fermé.
Ex. : Squad réseau : VPN et SD-WAN impossibles sur le même sprint. SD-WAN déprioritisé. Résolu avant de partir.
O
Owned — Propriétaire nommé
Un responsable nommé gère et reporte à chaque PO Sync. Sans propriétaire, le risque est mort-né.
Ex. : Serveurs RHEL 7 EOL : risque de vulnérabilité. Squad infra propriétaire, replatforming Sprint 3, suivi hebdo.
A
Accepted — Accepté
Connu, non supprimable dans le PI. On vit avec — à condition de documenter le plan B. Sans plan B, c'est ignorer.
Ex. : Fournisseur ne garantit pas le circuit avant Sprint 4. Plan B : VPN temporaire Sprints 1–3.
M
Mitigated — Réduit
Action préventive réduisant probabilité ou impact. Risque contenu, non éliminé.
Ex. : Quota API gestionnaire de secrets atteint. Cache TTL 30 min côté client → appels réduits de 80%.
Règles d'or de la gestion des risques ROAM
Pas de risque sans propriétaire nommé — Une personne, pas une Squad. "La Squad réseau" n'est pas un propriétaire — l'ingénieur réseau principal l'est. C'est la première règle et la plus violée.
Mise à jour à chaque PO Sync — sans exception — Un risque non discuté en PO Sync progresse sans surveillance. La fréquence hebdomadaire est la différence fondamentale avec le Risk Register PMP.
Distinguer risque et dépendance — Dépendances sur le Program Board, risques sur le ROAM Board. Quand une dépendance n'est pas tenue, elle devient un risque et migre sur le ROAM Board avec propriétaire et catégorie.
Accepted sans plan B = risque ignoré — Accepter est une décision valide ; ne pas documenter le plan B et sa date de déclenchement, c'est se donner bonne conscience sans se protéger. Même logique qu'en PMP avec les risques résiduels couverts par une réserve.
Le ROAM Board est vivant — pas un livrable — 8 à 12 risques au début du PI, 2 ou 3 encore ouverts à la fin : signe que le pilotage fonctionne.
« La différence entre un Risk Register PMP et un ROAM Board SAFe n'est pas dans le format — c'est dans la fréquence. En PMP, on le sort au Copil mensuel. En SAFe, on le lit chaque semaine au PO Sync. C'est la même rigueur, à une fréquence dix fois supérieure. »
SAFe en contexte IT — De mon expérience terrain, 25 ans
Sur un programme d'infrastructure de production, la sécurité ne peut pas être un workstream validé "à la fin". Elle doit être câblée dans le pipeline de livraison au même titre que les tests fonctionnels. Concrètement : aucun livrable ne passe en production sans avoir franchi une security gate automatisée (CVE, secrets en clair, chiffrement, contrôle d'accès). Gate échouée = pipeline bloqué. En contexte réglementé (DORA, NIS2, ISO 27001), ce point est non-négociable.
1 · Commit
→
2 · Build
→
3 · Tests unitaires
→
4 · SAST / DAST
→
5 · Deploy RECETTE
→
6 · Tests intégration
→
7 · PROD (approbation)
❌ Échec à n'importe quel stage → pipeline bloqué. Pas de merge possible tant que tous les stages sont verts.
Checklist DevSecOps — avant toute mise en production
RTO et RPO documentés et testés — La bascule DRP doit être simulée et chronométrée. Un RTO non testé est une déclaration d'intention.
Chiffrement at-rest et in-transit validé — Disques chiffrés avec clés gérées par l'organisation (Customer Managed Keys), flux réseau en TLS 1.3 minimum. TLS 1.0 et 1.1 désactivés. Pas d'exception pour les flux internes.
Aucun secret en clair dans le code — Scan automatique à chaque commit (GitLeaks). Credentials, clés API et chaînes de connexion injectés au runtime depuis un gestionnaire de secrets centralisé, jamais codés en dur.
Principe du moindre privilège appliqué — RBAC minimal sur toutes les ressources. Aucun accès root permanent — authentification forte avec justification et expiration automatique pour les accès privilégiés. Audité à chaque déploiement.
Scan de vulnérabilités sans CVE critique — Trivy ou SonarQube intégrés dans le pipeline. CVE critique = déploiement bloqué. La Squad sécurité tient la "Cloud Eligibility Gate" sur la base documentaire — sans validation, le pipeline reste fermé.
Logs d'audit retenus 12 mois minimum — DORA et NIS2 imposent la traçabilité des accès et incidents de sécurité. Logs centralisés, non modifiables, disponibles pour audit à tout moment.
💡
Infrastructure as Code : le lien entre SAFe et DevSecOps
L'IaC (Terraform, Ansible, Bicep) est le point de jonction. Versionner l'infrastructure comme du code permet les mêmes contrôles qu'une application : revue de code, tests automatisés, security scan. Le rollback devient possible en minutes — sur un programme de migration datacenter, c'est la différence entre un incident et une catastrophe.
⚠️
La security gate n'est pas une contrainte — c'est une assurance
Un pipeline avec contrôles automatisés prend plus de temps qu'un déploiement manuel — c'est vrai. Mais comparer ce surcoût au coût d'un incident en production (remédiation, communication de crise, audit réglementaire) change la perspective. La security gate est l'équivalent automatisé du Local Security Officer sur une certification datacenter. La différence : c'est scalable et reproductible à chaque sprint.
« Intégrer la sécurité dans le pipeline CI/CD, ce n'est pas ralentir l'équipe. C'est éliminer la phase de "durcissement sécurité" qui, dans les projets traditionnels, consomme les deux derniers mois du projet — toujours sous-estimés, toujours en dépassement. »
SAFe en contexte IT — De mon expérience terrain, 25 ans
C'est la question qui revient systématiquement lors d'une transition SAFe dans un contexte IT structuré : où passe le document d'architecture technique ? En méthodologie traditionnelle (PMP, PRINCE2), le TAD (Technical Architecture Document) est produit en amont, validé en comité, puis transmis aux équipes. En SAFe, ce modèle est remplacé par trois mécanismes complémentaires — plus légers, plus vivants, et conçus pour évoluer avec le programme.
RWY
Architectural Runway
Le socle technique préalable
L'ensemble des composants techniques déjà construits qui permettent aux Squads de livrer des features sans attendre des décisions d'architecture. Ce n'est pas un document — c'est un état du SI.
Concrètement
Modules Terraform standardisés, pipelines CI/CD partagés, conventions de nommage cloud, politiques NSG validées. La Squad cloud consomme ces briques sans avoir à les concevoir.
ENB
Enabler Features
L'architecture livrée en sprints
Les travaux d'architecture apparaissent dans le backlog comme n'importe quelle feature : un PO, une définition de done, une estimation, un sprint de livraison. Pas de workstream parallèle invisible.
Concrètement
"Créer le module Terraform Hub & Spoke", "Définir les standards NSG", "Valider la stratégie de chiffrement CMK" — chacune est une Enabler Feature avec un owner et une date.
SI
Solution Intent
Le plus proche du TAD
Document vivant co-maintenu par le System Architect. Il capture les exigences non-fonctionnelles, les contraintes d'architecture et les décisions de design majeures du programme.
Concrètement
Choix d'architecture Hub & Spoke Azure, politique de peering VNet, standards TLS, stratégie DRP et RTO cibles. Il évolue à chaque PI — pas figé au kick-off.
Règles d'or de l'architecture en SAFe
Just enough architecture, just in time — Ne pas documenter ce qu'on n'a pas encore besoin de construire. Un schéma d'architecture produit 6 mois avant le déploiement sera périmé. L'architecture se précise au fur et à mesure que les Squads construisent.
Le System Architect travaille dans les sprints — Il n'est pas en amont dans une tour d'ivoire. Il participe aux Sprint Reviews, valide les Enabler Features et maintient le Solution Intent en continu. Son output principal n'est pas un document — c'est l'Architectural Runway disponible.
Les décisions d'architecture sont des risques ROAM — Un choix architectural non tranché (ex. : chiffrement at-rest avec CMK ou clés gérées par le provider ?) est un risque de blocage futur. Il doit figurer sur le ROAM Board avec un propriétaire et une date de décision.
L'Architectural Runway se planifie au PI Planning — Les Enabler Features nécessaires pour le PI suivant sont identifiées et priorisées pendant le PI Planning, au même titre que les features business. Une Squad qui démarre un sprint sans runway disponible est une Squad bloquée.
💡
Transition PMP → SAFe : que faire du TAD existant ?
Si votre organisation dispose d'un TAD produit en amont, ne le jetez pas — transformez-le en Solution Intent initial. Extrayez les décisions d'architecture majeures et les contraintes non-fonctionnelles, versionnez-les dans Confluence, et nommez le System Architect comme propriétaire. Les éléments non encore validés deviennent des Enabler Features dans le backlog. Le TAD statique devient un référentiel vivant mis à jour à chaque PI.
« En SAFe, l'architecte ne livre pas un document — il livre du runway. La différence : un document se lit, le runway se consomme. »
SAFe en contexte IT — De mon expérience terrain, 25 ans
SAFe 6.0
Agile Release Train
PI Planning
ROAM
PO Sync
DevSecOps
RTE
Scrum Master
Product Owner
Terraform
Infrastructure as Code
DORA
NIS2
CI/CD
Cloud hybride
Migration datacenter
REX
PMP®
Architectural Runway
Solution Intent
System Architect
Enabler Features
Vous pilotez un programme IT Agile complexe ?
PMP® certifié, 25 ans de programmes IT sur 5 pays. Expérience SAFe sur des programmes d'infrastructure hybride Cloud/On-Premise à grande échelle. Je peux accompagner la mise en place de votre ART ou prendre en charge le rôle de RTE sur votre programme.
Me contacter →