Deux jours. Une salle ou un lien Teams. Dix à quinze équipes qui doivent tomber d'accord sur ce qu'elles vont livrer pendant les dix prochaines semaines.
C'est le PI Planning : l'événement où une transformation SAFe® cesse d'être une slide de comité de direction pour devenir, ou non, une réalité opérationnelle.
Beaucoup de DSI marocaines ont franchi le pas de SAFe. Elles ont formé leurs équipes, nommé un Release Train Engineer, dessiné un Agile Release Train sur un organigramme. Mais le premier PI Planning arrive, et il ressemble davantage à une réunion de lancement de projet classique qu'à l'événement structurant qu'il est censé être. Ce guide détaille ce qui doit se passer avant, pendant et après un PI Planning avec les pièges spécifiques aux organisations en transformation en France et au Maroc.
Source : 18ᵉ State of Agile Report, Digital.ai (2025)
Le PI Planning, l'événement qui fait ou défait une transformation SAFe
Dans le vocabulaire SAFe, le PI Planning (Program Increment Planning) est décrit comme le « cœur battant » de l'Agile Release Train. Ce n'est pas une formule marketing : c'est littéralement l'événement où la vision business rencontre la capacité réelle des équipes à livrer. Selon la documentation officielle du framework, un PI Planning aligne l'ensemble des équipes et des parties prenantes d'un ART autour d'une mission, d'une vision et d'un plan engagé pour les huit à douze semaines suivantes.
Concrètement, il se distingue d'une planification de sprint sur trois points :
- L'échelle : il réunit toutes les équipes d'un même train, pas une seule équipe.
- L'horizon : il couvre un Program Increment entier (8 à 12 semaines), pas une itération de deux semaines.
- La nature de l'engagement : les équipes ne livrent pas une liste de tâches, elles formulent des PI Objectives avec une valeur business explicite, votés en confiance collective.
Un PI Planning réussi ne produit pas seulement un planning. Il produit un accord partagé sur les dépendances entre équipes, les risques identifiés, et un engagement mesurable, la PI Predictability Measure qui sert ensuite de socle aux indicateurs de pilotage de la transformation SAFe.
Pourquoi tant d'entreprises ratent leur premier PI Planning
Le symptôme est presque toujours le même : les deux jours se déroulent, les post-its sont posés, la photo de groupe est prise et six semaines plus tard, personne ne sait si l'ART est en train de tenir ses objectifs. Trois causes reviennent systématiquement :
- Le contexte business est survolé. La présentation de la vision et des priorités stratégiques dure quinze minutes au lieu d'ancrer réellement les équipes dans le « pourquoi ».
- L'architecture n'est pas prête. Le System Architect découvre les dépendances techniques en même temps que tout le monde, au lieu de préparer un « architectural runway » en amont.
- Le vote de confiance est une formalité. Personne n'ose lever moins de trois doigts, alors que c'est précisément ce signal qui doit déclencher une revue du plan.
Ces trois causes ont un point commun : elles se règlent avant le jour J, pas pendant. D'où l'importance de la préparation traitée plus bas.
Les rôles à réunir avant même de réserver la salle
Un PI Planning n'est pas un atelier d'équipe élargie : c'est un événement avec des rôles précis, dont l'absence de l'un d'eux suffit à en dégrader la qualité.
Release Train Engineer (RTE)
Facilite l'ensemble de l'événement. Chief Scrum Master du train, il garantit que le processus est respecté et que les blocages remontent vite.
Business Owners
Portent la responsabilité business et le ROI de la solution développée par l'ART. Ils participent activement leur absence prive l'événement de tout arbitrage de valeur.
Product Management
Présente les dix fonctionnalités prioritaires du PI et porte le backlog programme partagé entre les équipes.
System Architect / Engineer
Partage la vision technique et l'architectural runway, le socle qui rend les engagements des équipes réalistes plutôt qu'optimistes.
Agile Teams
Cinq à onze personnes par équipe, cross-fonctionnelles. Chaque Scrum Master représente son équipe et anime les breakouts.
System Team & parties prenantes
Support à l'intégration continue et invités selon les dépendances identifiées leur présence évite les surprises de dernière minute.
L'agenda du PI Planning en deux jours
L'événement suit une structure standardisée, dont voici la version condensée applicable à la majorité des ART :
| Moment | Séquence | Objectif |
|---|---|---|
| Jour 1 — matin | Contexte business & vision produit | Ancrer les équipes dans la stratégie et les priorités du PI |
| Jour 1 — matin | Vision architecture | Partager l'architectural runway et les contraintes techniques |
| Jour 1 — après-midi | Breakout équipes #1 | Estimer la capacité, identifier risques et dépendances, ébaucher un plan |
| Jour 1 — fin de journée | Draft Plan Review | Chaque équipe présente son plan initial pour retour croisé |
| Jour 2 — matin | Management Review & Problem Solving | Résoudre les dépendances, ajuster le périmètre, arbitrer les risques |
| Jour 2 — après-midi | Breakout équipes #2 | Finaliser les PI Objectives, affiner les engagements |
| Jour 2 — fin de journée | Plan final & vote de confiance | Engagement collectif sur une échelle de 1 à 5 — cible : 3 ou plus |
L'exercice de ROAMing (Resolved, Owned, Accepted, Mitigated) mérite une mention à part : c'est la méthode utilisée pour trier les risques identifiés pendant le breakout et s'assurer qu'aucun ne reste flottant sans propriétaire.
Se préparer : la checklist des trois semaines qui précèdent
La qualité d'un PI Planning se joue à 80 % avant l'événement. Voici les prérequis à valider :
- Le contexte business et les priorités stratégiques sont formalisés et validés par les Business Owners
- Le backlog programme est suffisamment affiné pour couvrir 1,5 PI de travail
- L'architectural runway est documenté et communiqué aux System Architects et équipes
- La logistique est réservée : salle(s), outils collaboratifs, tableaux de dépendances
- Les rosters d'équipe sont à jour, avec fuseaux horaires si l'ART est distribué
- Un facilitateur est désigné par site en cas de PI Planning multi-localisations
PI Planning à distance ou hybride : ce qui change
Pour une organisation avec des équipes réparties entre Casablanca, Rabat et Paris, le PI Planning 100 % présentiel n'est pas toujours réaliste. La documentation officielle du framework recommande, dans ce cas, de consolider les localisations plutôt que de disperser chaque individu : mieux vaut réunir chaque équipe sur un site unique que d'avoir chacun de ses membres connecté séparément depuis chez lui.
Désigner un facilitateur technique par site, tester les outils de visioconférence et de tableau partagé plusieurs jours à l'avance, prévoir des marges de temps supplémentaires pour les transitions, et ne pas sacrifier les moments de cohésion d'équipe sous prétexte de distance.
Les cinq erreurs qui transforment un PI Planning en réunion de plus
- Sauter le contexte business. Sans vision claire, les équipes planifient des tâches, pas de la valeur.
- Ignorer le vote de confiance faible. Un score sous 3 doit déclencher un ajustement du plan, pas être noyé dans l'enthousiasme collectif.
- Laisser les dépendances non assignées. Un risque sans propriétaire après le ROAMing reste un risque non traité.
- Traiter le PI Planning comme un one-shot. Sans ART Sync ni System Demo réguliers ensuite, l'alignement créé pendant l'événement s'érode en quelques semaines.
- Confondre présence et engagement. Des Business Owners présents mais passifs privent l'événement de tout arbitrage réel de valeur.
Après le PI Planning : de l'exécution à la gouvernance
Le PI Planning fixe un cap ; il ne le garantit pas. Deux prolongements sont nécessaires pour que l'investissement de ces deux jours ne soit pas perdu :
Mesurer. La PI Predictability Measure le pourcentage d'objectifs atteints par rapport aux objectifs engagés devient le premier indicateur à suivre dans les semaines suivantes. Nous détaillons l'ensemble du tableau de bord recommandé dans notre guide sur les KPI qui comptent vraiment dans une transformation SAFe.
Gouverner. Le PI Planning révèle souvent des tensions entre logique projet et logique produit, la même tension que nous explorons dans notre article sur le rôle du PMO dans une organisation agile à l'échelle. Un Lean Portfolio Management actif est ce qui relie les PI Objectives votés en salle à la stratégie d'entreprise portée en comité de direction un fil que nous abordons également dans notre article sur les OKR comme chaînon entre stratégie et exécution agile.
Enfin, un PI Planning ne compense pas une conduite du changement absente. Si les équipes arrivent en salle sans avoir compris pourquoi SAFe a été choisi, l'événement ressemblera à une contrainte de plus — un sujet que nous traitons dans notre article sur le change management comme angle mort des transformations digitales.
Questions fréquentes sur le PI Planning
Qu'est-ce qu'un Agile Release Train (ART) ?
Un ART est un regroupement de cinq à quinze équipes agiles entre 50 et 125 personnes qui partagent une mission commune, une cadence de livraison et un backlog programme. Le PI Planning est l'événement qui synchronise l'ensemble de cet ART.
Combien de temps dure un PI Planning ?
Deux jours complets, en présentiel dans l'idéal, tous les huit à douze semaines. Un PI comprend généralement quatre itérations de développement suivies d'une itération d'innovation et de planification.
Le PI Planning peut-il se faire entièrement à distance ?
Oui. Le framework fournit des recommandations spécifiques pour les PI Planning distribués désignation de facilitateurs par site, outils de synchronisation en temps réel, marges de temps additionnelles. La qualité de la préparation compte davantage que le mode de connexion.
Quelle est la différence entre PI Planning et Sprint Planning ?
Le Sprint Planning organise le travail d'une seule équipe sur deux semaines. Le PI Planning aligne toutes les équipes d'un ART sur huit à douze semaines, avec un focus sur les dépendances inter-équipes et la valeur business, pas seulement sur les tâches.
Qui doit obligatoirement participer ?
Le RTE (facilitateur), les Business Owners, le Product Management, les System Architects, et l'ensemble des équipes agiles du train. L'absence d'un Business Owner prive l'événement de tout arbitrage de valeur réel.
Ce qu'il faut retenir
Le PI Planning n'est pas une cérémonie SAFe parmi d'autres : c'est le moment de vérité où une stratégie de transformation devient ou non, un plan opérationnel partagé. Sa réussite se joue avant l'événement, dans la préparation du contexte business et de l'architecture ; pendant l'événement, dans la qualité du dialogue entre équipes ; et après l'événement, dans la mesure et la gouvernance qui en prolongent les effets.
Pour une DSI marocaine qui structure son premier ART, l'enjeu n'est pas de reproduire l'agenda à la lettre, mais de comprendre ce que chaque étape est censée produire et de ne sauter aucune des conditions qui rendent l'engagement collectif crédible.
Vous préparez votre premier PI Planning ?
Chez Arrioph, nous accompagnons les DSI marocaines dans le déploiement de SAFe®, de la structuration de l'ART jusqu'à l'animation du premier Program Increment.
Parler à un expert
