En pilotage de projet, un malentendu revient souvent : confondre la gouvernance de projet # comitologie.
👉 Pourtant, l’un est un cadre stratégique complet. 👉 L’autre n’est qu’un outil (important) au service de ce cadre.
–
Gouvernance de projet : le système nerveux du programme
La gouvernance, c’est l’architecture stratégique qui encadre le projet. Elle répond à la question : Qui décide quoi, comment, avec quelles règles et dans quel but ?
🔹 Ses piliers :
Les rôles et responsabilités (ex : matrice RACI)
Les instances de décision (COPIL, Comex, comité de pilotage stratégique…)
Les processus de pilotage : gestion des risques, suivi qualité, arbitrage ressources/budget
Les modes d’escalade des décisions critiques
Les rituels et indicateurs partagés
Les principes de relation avec les parties prenantes
🧠 Bref, la gouvernance aligne, structure, arbitre, et sécurise les décisions stratégiques du projet.
–
Comitologie : la mécanique des réunions
La comitologie, elle, répond à la question « Comment organiser nos comités ? »
🛠 C’est l’art de :
Définir la liste des comités
Préciser leur périmètre et composition
Planifier leur fréquence
Poser leur mode de décision
Formaliser leur préparation et reporting
📅 Elle structure le rythme de décision, mais sans les règles du jeu ni les objectifs globaux.
–
Ne pas confondre = éviter 3 pièges fréquents
Organiser des comités sans cadre/Réunions stériles, décisions floues
Croire que la comitologie suffit/Perte d’alignement stratégique, escalades mal gérées
Confondre décision et information/Trop de reporting, pas assez d’engagement
–
En résumé
Gouvernance
Comitologie
Vision globale et règles du jeu
Organisation pratique des comités
Pilote l’ensemble du projet
Structure les réunions
Alignement stratégique
Outil de coordination
Une bonne gouvernance utilise une comitologie claire, mais ne s’y limite pas.
3 vérités que j’aurais aimé entendre en tant que jeune chef de projet
Quand j’ai débuté dans la gestion de projet, je croyais que tout reposait sur les méthodes, les outils et les process.
Aujourd’hui, avec l’expérience, je sais que ce n’est pas le cœur du sujet.
Si je pouvais parler au jeune chef de projet que j’étais, je lui dirais 3 vérités simples, mais décisives.
–
Conduire un projet, c’est avant tout une aventure humaine
À mes débuts, je pensais que maîtriser les outils suffisait pour réussir. Faux.
Un projet ne vit que grâce aux femmes et aux hommes qui y travaillent. Sa richesse vient des profils différents, des talents variés, et parfois… des contradictions.
👉 Les outils structurent. L’humain fait réussir.
Mon conseil : passe une certification si tu veux, mais ne t’y accroche pas trop. Ce qui fera la différence, ce sont tes qualités relationnelles et ta capacité à fédérer.
–
Avoir raison ne sert à rien… si tu es seul à le penser
Jeune ingénieur, je croyais que démontrer la justesse de mon raisonnement suffisait pour convaincre. En réalité, avoir raison tout seul ne sert à rien.
Un projet avance uniquement quand les autres adhèrent à ton idée.
👉 Convaincre ne repose pas sur la logique pure, mais sur la perception, la confiance et la capacité à embarquer les parties prenantes.
Mon conseil : forme-toi au coaching, à la communication ou à la négociation. Ces compétences valent autant que tes équations.
–
Les conseils ne servent à rien… sauf à se faire sa propre expérience
À l’époque, je pensais qu’un conseil, surtout quand on me le demandait, devait être suivi à la lettre. Avec le recul, je sais qu’un conseil reflète surtout le vécu de celui qui le donne.
👉 Tu dois vivre tes propres expériences, tester, te tromper, recommencer.
Mon conseil : écoute les plus expérimentés, mais choisis ton chemin. Tu n’es pas dans leurs chaussures, ton contexte est différent.
–
En résumé
Ces trois vérités m’ont marqué :
Le projet reste avant tout une aventure humaine
La raison seule ne suffit pas, il faut savoir convaincre
Les conseils valent peu sans expérience personnelle
Un jeune chef de projet qui intègre ces leçons progresse plus vite et construit un leadership solide.
Les 5 types de réunions projet à connaître absolument
Dans un projet, les réunions rythment la vie de l’équipe et la prise de décision. Bien menées, elles fluidifient la communication, donnent de la visibilité et permettent de trancher rapidement. Mal cadrées, elles deviennent une perte de temps.
Voici les 5 types de réunions incontournables en gestion de projet, leur rôle et leurs bonnes pratiques.
Rédiger une User Story : un outil simple, agile… et adaptable à tout type de projet
Dans de nombreux projets, le besoin réel de l’utilisateur est mal compris, mal exprimé… ou carrément oublié.
La méthode des User Stories apporte une solution simple, claire et collaborative pour mieux capter les attentes des utilisateurs – que vous soyez en mode agile ou classique.
–
C’est quoi une User Story ?
Une User Story est une phrase courte, structurée, qui exprime un besoin du point de vue d’un utilisateur. Elle permet de recentrer le projet sur la valeur attendue, plutôt que sur le livrable.
🧩 Formule type : En tant que[utilisateur cible], je veux[ce qu’il ou elle cherche à faire], afin de[objectif ou valeur attendue].
–
Pourquoi utiliser des User Stories ?
Avec User Story
Sans User Story
✅ Besoin centré sur l’utilisateur final
❌ Brief flou ou trop centré livrable
✅ Vision commune entre toutes les parties
❌ Risque de malentendus fréquents
✅ Focus sur l’impact recherché
❌ Dérive : on produit, mais sans effet réel
–
Attention aux fausses User Stories !
Une User Story n’est pas une description de livrable, ni une solution prédéfinie.
❌ Mauvais exemple
✅ Bon exemple
On veut un flyer A5 recto/verso en quadri
Je veux comprendre rapidement l’offre
On a besoin d’un visuel impactant
Je dois capter l’info en 3 secondes
On produit une vidéo de 30 sec
Je veux savoir en quoi ça améliore mon quotidien
–
Comment construire une bonne User Story ?
En 3 étapes simples en atelier :
Choisir un projet réel ou une fonctionnalité
Identifier clairement la cible : utilisateur, client, collaborateur, etc.
Compléter la phrase type : En tant que, je veux, afin de
–
Et si on est en méthode traditionnelle (waterfall) ?
Même si la User Story vient du monde agile, elle est aussi très utile dans un projet en mode classique (cycle en V, waterfall). 👉 Elle ne remplace pas un cahier des charges fonctionnel (CDCF), mais peut l’enrichir dès la phase de cadrage.
User Story
CDCF (Cahier des Charges Fonctionnel)
Centrée sur l’utilisateur et la valeur
Centré sur les exigences fonctionnelles
Formulation accessible et rapide
Structuration technique ou normative
Support de dialogue
Base contractuelle ou de validation finale
💡 Bon usage : Commencez par des User Stories pour clarifier les intentions métier, puis transformez-les en exigences formalisées dans votre CDCF.
–
En résumé
✔ Une User Story rend le besoin humain, compréhensible et partageable ✔ Elle permet de faire le lien entre stratégie, utilisateur et livrable ✔ Elle est complémentaire au cahier des charges dans les projets classiques
💬 « Une User Story bien formulée est un petit investissement pour un gros retour sur clarté. »
