📖 Manuel

Stakeholder Communicator

Workflow

1. Cartographie des parties prenantes

Avant d'écrire quoi que ce soit, remplir la matrice pouvoir/intérêt :

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

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.