khalilbenaz Stakeholder Communicator
Workflow
1. Cartographie des parties prenantes
Avant d'écrire quoi que ce soit, remplir la matrice pouvoir/intérêt :
| Partie prenante | Pouvoir (1-5) | Intérêt (1-5) | Stratégie | Fréquence |
|---|---|---|---|---|
| DG / sponsor | 5 | 3 | Garder informé | Bi-mensuel |
| Chef de projet | 3 | 5 | Collaboration | Hebdo |
| Équipe tech | 2 | 5 | Consulter | Quotidien |
| Client métier | 4 | 4 | Gérer activement | Hebdo |
| DSI | 4 | 2 | Satisfaire | Mensuel |
Règle de décision :
- Pouvoir ≥ 4 ET Intérêt ≥ 4 → gestion active, communication directe
- Pouvoir ≥ 4 ET Intérêt < 3 → satisfaire sans sur-communiquer
- Pouvoir < 3 ET Intérêt ≥ 4 → tenir informé, source de feedback
- Pouvoir < 3 ET Intérêt < 3 → surveiller, communication minimale
2. Collecte des informations — checklist avant rédaction
[ ] % avancement global et par lot/épic (outil : Jira, Azure DevOps, GitHub Projects)
[ ] Jalons atteints / manqués depuis dernier reporting
[ ] Risques actifs (probabilité, impact, mitigation en cours)
[ ] Décisions en attente (qui doit décider, deadline)
[ ] Dépenses vs budget (burn rate, forecast)
[ ] Blocages technique ou organisationnel
[ ] Actions ouvertes du COPIL précédent
3. Rapport de statut — structure type
Utiliser la pyramide inversée : conclusion en premier.
# Rapport de statut — [Nom Projet] — [Date]
## Résumé exécutif (3 lignes max)
Statut global : 🔴 ROUGE / 🟡 AMBRE / 🟢 VERT
Point critique : [une phrase]
Décision requise : [une phrase ou AUCUNE]
## Avancement
| Lot / Épic | Statut | % Fait | Delta vs plan |
|----------------|--------|--------|---------------|
| Authentification | 🟢 | 95% | +0j |
| Module paiement | 🟡 | 60% | -5j |
| Intégration SFTP | 🔴 | 20% | -15j |
## Risques actifs
| # | Risque | Proba | Impact | Mitigation | Owner |
|---|-------------------------------|-------|--------|-------------------------|--------|
| 1 | Livraison API partenaire tardive | H | H | POC alternative lancé | Tech |
| 2 | Congés équipe juillet | M | M | Plan de continuité actif| PM |
## Décisions requises
1. **[Sujet]** — Options : A / B / C — Recommandation : A — Deadline : [date]
## Actions ouvertes
| Action | Owner | Due | Statut |
|------------------|--------|--------|---------|
| Valider maquette | Client | 27/06 | En cours|
4. Adaptation du message par audience
| Audience | Focus | Format | Durée/longueur |
|---|---|---|---|
| DG / Sponsor | ROI, risques stratégiques, budget | Slide 1 page | 3 min pitch |
| Management métier | Planning, livraisons, impacts | Rapport 1 page | 5 min |
| Équipe technique | Détails tâches, blocages, dette | Ticket / Readme | Sans limite |
| Client externe | Fonctionnalités livrées, roadmap | Release notes | 1 page max |
Règle : plus le pouvoir est élevé, moins il y a de texte. Un DG lit 3 lignes.
5. Préparation COPIL — template slide
Slide 1 — Statut global (RAG) + 1 message clé
Slide 2 — Avancement jalons (tableau ou Gantt simplifié)
Slide 3 — Risques TOP 3 (tableau : risque / impact / mitigation)
Slide 4 — Décisions requises (une par slide si nécessaire)
Format : Contexte → Options → Recommandation → Vote
Slide 5 — Prochaines étapes + date du prochain COPIL
Pré-alignement obligatoire : Envoyer le draft aux décideurs clés 48h avant pour éviter les surprises. Format du mail de pré-alignement :
Objet : [Projet] COPIL [date] — Points sensibles à valider en amont
Bonsoir [prénom],
Avant notre COPIL de [date], je souhaitais vous partager un point sensible :
[Description en 2 phrases].
Options envisagées : A) … B) …
Ma recommandation : A, car [raison].
Besoin de votre validation ou d'un échange de 10 min avant jeudi ?
6. Gestion des escalades
Critères d'escalade :
- Blocage non résolu > 3 jours ouvrés
- Risque passant en criticité HAUTE
- Dérapage planning > 10% de la durée du lot
- Décision hors périmètre PM non prise sous 5 jours
Template d'escalade (email/ticket) :
Objet : [ESCALADE] [Projet] — [Sujet court]
Contexte : [1 phrase]
Problème : [ce qui bloque]
Impact : [délai / budget / qualité — chiffré si possible]
Déjà tentés : [actions menées]
Options : A) … B) …
Recommandation : [laquelle et pourquoi]
Décision requise avant : [date]
Ne jamais escalader sans avoir tenté au moins une résolution au niveau actuel.
7. Registre des décisions (Decision Log)
Tenir un fichier versionné (decisions.md ou colonne dans Notion/Azure DevOps) :
| # | Date | Décision | Décideur | Contexte | Actions déclenchées |
|---|--------|---------------------------------|--------------|-----------------------|-----------------------------|
| 1 | 2026-06-10 | Adoption API REST v2 (abandon SOAP) | DSI + PM | Migration coût élevé | Ticket #1234 créé, plan mis à jour |
Diffuser le decision log dans les 24h post-réunion à tous les stakeholders concernés.
Anti-patterns / Pièges
- Faux vert — signaler VERT sous pression pour éviter des questions. Un rouge signalé tôt est gérable ; un rouge surpris en COPIL est un incident politique.
- Over-reporting — envoyer trop d'informations tue l'attention. Une slide = un message.
- Escalade sans préparation — arriver sans options ni recommandation transforme l'escalade en problème supplémentaire pour le décideur.
- Décisions orales non tracées — toute décision prise en couloir doit être confirmée par écrit dans les 24h.
- Communication uniforme — envoyer le même rapport à la DG et à l'équipe technique est inefficace pour les deux.
- Absence de pre-alignment — surprendre un sponsor en COPIL crée de la méfiance ; les décisions importantes se prennent en amont, pas en réunion.
- Registre de décisions absent — sans trace, les décisions sont contestées, dupliquées ou oubliées.
Bonnes pratiques 2026
- Async-first : utiliser Teams/Slack pour les status updates hebdos ; réserver le COPIL aux décisions et arbitrages uniquement.
- One-pager executif : généré automatiquement depuis les données du projet (Jira/ADO export → template Markdown → PDF).
- Dashboard live : un lien vers un board Jira/ADO filtré remplace avantageusement les tableaux d'avancement statiques dans les rapports récurrents.
- OKR alignment : chaque rapport de statut doit référencer l'OKR ou l'objectif stratégique auquel le projet contribue — cela renforce la légitimité des demandes de ressources.
- RACI explicite : pour chaque lot, identifier clairement R (Responsible), A (Accountable), C (Consulted), I (Informed) avant le lancement pour éviter les flous lors des escalades.