Le bon modèle mental
Un projet n'est pas une liste de tâches à cocher — c'est un pari sur un résultat précis, dans un délai donné, avec des ressources limitées.
Comme construire une maison avec un budget et une date de mariage fixée : on ne peut pas avoir toutes les finitions, le budget le plus bas et la date la plus proche en même temps. Chaque décision de gestion de projet est un arbitrage entre ces trois axes — souvent appelés le triangle qualité, coût, délai.
Ce que ça change concrètement
- Le triangle qualité/coût/délai : améliorer un axe se paie presque toujours sur un autre — un bon chef de projet rend ces arbitrages visibles plutôt que de prétendre qu'ils n'existent pas.
- Gérer un projet, ce n'est pas exécuter des tâches — c'est anticiper ce qui pourrait empêcher le résultat d'arriver à temps.
- Le rôle principal du chef de projet est de rendre visible où en est le projet, pour tout le monde, à tout moment — pas de tout faire lui-même.
Qu'est-ce que le triangle qualité/coût/délai, et pourquoi ne peut-on presque jamais optimiser les trois à la fois ?
Voir la réponse
C'est le principe selon lequel qualité, coût et délai sont liés : améliorer l'un se fait presque toujours au détriment d'un autre (plus de qualité coûte du temps ou de l'argent, un délai plus court réduit la qualité ou augmente le coût). Gérer un projet, c'est choisir consciemment lequel des trois on protège.
Définir un objectif
Un objectif flou produit un projet qui n'a jamais vraiment fini ni vraiment échoué — juste un projet qu'on abandonne progressivement.
Comme viser une cible sans ligne définissant le centre : on peut toujours dire qu'on a « presque touché », mais personne ne peut vérifier si c'est vrai. Un objectif précis, c'est dessiner la cible avant de tirer.
Techniques qui marchent
- Un objectif se formule en résultat observable, pas en intention : « réduire le temps de traitement des commandes de 30 % » plutôt que « améliorer le service client ».
- Distinguer objectif et méthode : l'objectif dit où on veut arriver, jamais comment y arriver — mélanger les deux enferme le projet dans une seule solution avant même d'avoir exploré les options.
- Faire valider l'objectif par toutes les parties concernées avant de commencer — un objectif compris différemment par le commanditaire et l'équipe garantit un désaccord plus tard, au pire moment.
Pourquoi un objectif de projet doit-il être formulé en résultat observable plutôt qu'en intention générale ?
Voir la réponse
Parce qu'un résultat observable permet de vérifier objectivement, à la fin, si le projet a réussi ou échoué — une intention vague comme « améliorer le service » ne permet jamais de trancher, ce qui laisse le projet sans véritable fin ni véritable évaluation.
Découper le travail
Un projet non découpé est un mur qu'on regarde — un projet découpé est un escalier qu'on monte marche par marche.
Même logique que pour un problème complexe : personne ne construit une maison en une seule action — fondations, murs, toit, chacune une étape indépendante qu'on peut planifier et vérifier séparément.
Techniques qui marchent
- Découper en livrables concrets (ce qui sera produit), pas seulement en activités vagues — « maquette validée par le client » plutôt que « travailler sur le design ».
- La règle de la tâche d'un à deux jours : si une tâche prend plus de quelques jours, elle cache probablement plusieurs sous-tâches non identifiées.
- Structurer en arborescence (découpage hiérarchique du travail) : le projet global, ses grands lots, puis les tâches concrètes de chaque lot — chaque niveau doit couvrir 100 % du niveau au-dessus, ni plus ni moins.
Quel est le signal qu'une tâche du projet est en réalité mal découpée et cache plusieurs sous-tâches ?
Voir la réponse
Si une tâche prend plus de quelques jours (un à deux jours en règle générale), elle cache probablement plusieurs sous-tâches non identifiées qu'il faut découper séparément pour pouvoir les planifier et les vérifier individuellement.
Fixer les priorités
Tout ne peut pas être prioritaire en même temps — une liste où tout est urgent est une liste sans priorités.
Comme trier une salle d'urgence : le blessé grave passe avant celui qui attend depuis plus longtemps — la priorité ne se décide pas à l'ancienneté de la demande, mais à l'impact et l'urgence réels.
Techniques qui marchent
- La matrice impact/effort : prioriser d'abord ce qui a un impact fort pour un effort faible, avant les gros chantiers à fort impact mais plus lents à livrer.
- MoSCoW (indispensable / souhaitable / possible / exclu pour cette version) : trancher explicitement ce qui ne sera PAS fait cette fois, pas seulement ce qui sera fait.
- Reprioriser régulièrement plutôt qu'une seule fois au lancement — les priorités d'il y a trois mois ne sont pas forcément celles d'aujourd'hui.
Que signifie concrètement la méthode MoSCoW pour prioriser un projet ?
Voir la réponse
Elle classe chaque élément en Must (indispensable), Should (souhaitable), Could (possible si le temps le permet) ou Won't (exclu pour cette version) — l'important est de trancher explicitement ce qui ne sera PAS fait, pas seulement ce qui sera fait.
Répartir les responsabilités
Une tâche sans responsable clair n'appartient à personne — et une tâche qui n'appartient à personne ne se fait jamais.
Comme un plat au restaurant que trois serveurs pensent que « quelqu'un d'autre » va apporter à table — il refroidit sur le comptoir pendant que chacun suppose que ce n'est pas à lui de le faire.
Techniques qui marchent
- La matrice RACI (Responsable / Approbateur / Consulté / Informé) pour chaque livrable important : un seul Responsable par tâche, jamais deux, sinon la responsabilité se dilue.
- Communiquer la répartition à voix haute ou par écrit, jamais supposer qu'elle est « évidente » pour tout le monde.
- Adapter la charge aux compétences ET à la disponibilité réelle, pas seulement à qui est théoriquement le plus qualifié sur le papier.
Pourquoi une tâche importante ne doit-elle avoir qu'un seul Responsable désigné, jamais deux ?
Voir la réponse
Parce que la responsabilité partagée entre deux personnes se dilue : chacune peut supposer que l'autre s'en occupe, et la tâche finit par n'appartenir vraiment à personne — un responsable unique garantit qu'un nom précis répond du résultat.
Établir un calendrier
Un calendrier n'est pas une liste de dates souhaitées — c'est un calcul basé sur les dépendances réelles entre les tâches.
Comme un jeu de dominos : certaines tâches ne peuvent tomber qu'après que les précédentes soient tombées — planifier, c'est identifier ce chemin de dominos, pas juste écrire des dates qui nous arrangent.
Techniques qui marchent
- Identifier le chemin critique (la suite de tâches dépendantes la plus longue) — c'est lui, et seulement lui, qui détermine la date de fin du projet.
- Prévoir une marge de sécurité ciblée sur les tâches à forte incertitude, pas uniformément sur tout le planning — une marge diluée partout se dissout dans les détails.
- Toujours dater à partir des dépendances réelles, jamais à rebours depuis une date de livraison désirée sans vérifier que le chemin critique la permet.
Qu'est-ce que le chemin critique d'un projet, et pourquoi est-ce lui qui détermine la date de fin ?
Voir la réponse
C'est la suite de tâches dépendantes la plus longue du projet : chacune doit attendre la fin de la précédente. Même si d'autres tâches parallèles avancent plus vite, le projet ne peut pas finir avant la fin du chemin critique — c'est donc lui, et lui seul, qui fixe la date réelle.
Anticiper les risques
Un risque identifié à l'avance coûte une prévention ; le même risque découvert en cours de route coûte une crise.
Comme vérifier la météo avant un voyage en voiture plutôt que découvrir l'orage sur la route — le même orage existe dans les deux cas, mais anticipé, on prend un autre itinéraire ; découvert en roulant, on le subit.
Techniques qui marchent
- Lister les risques en début de projet avec deux critères : probabilité et gravité de l'impact — prioriser la prévention sur les risques à la fois probables et graves.
- Pour chaque risque important, préparer un plan d'action concret AVANT qu'il ne se produise, pas au moment où il se matérialise sous pression.
- Revisiter la liste régulièrement pendant le projet — de nouveaux risques apparaissent, d'anciens disparaissent, une liste figée au lancement devient vite obsolète.
Sur quels deux critères doit-on prioriser un risque identifié en début de projet ?
Voir la réponse
La probabilité qu'il se produise et la gravité de son impact s'il se produit — les risques à la fois probables et graves méritent un plan de prévention préparé à l'avance, avant qu'ils ne surviennent réellement.
Suivre l'avancement
Suivre l'avancement, ce n'est pas mesurer combien de temps a été passé — c'est mesurer combien de résultat a été produit.
Deux équipes qui ont travaillé 40 heures cette semaine n'ont pas forcément avancé pareil : l'une a fini trois livrables, l'autre a passé la semaine bloquée sur un seul. Le temps passé n'est pas l'avancement — le résultat produit l'est.
Techniques qui marchent
- Mesurer l'avancement en livrables terminés (fini / pas fini), pas en pourcentage subjectif — « on est à 80 % » ne veut souvent rien dire de vérifiable.
- Des points de suivi courts et réguliers plutôt qu'un seul grand bilan en fin de projet — un problème détecté à mi-parcours se corrige, un problème découvert à la fin se subit.
- Rendre l'avancement visible à toute l'équipe (tableau partagé, pas seulement dans la tête du chef de projet).
Pourquoi un pourcentage d'avancement subjectif (« on est à 80% ») est-il un mauvais indicateur de suivi de projet ?
Voir la réponse
Parce qu'il n'est pas vérifiable ni comparable dans le temps — mesurer en livrables réellement terminés (fini/pas fini) donne un état des lieux objectif, alors qu'un pourcentage estimé peut rester bloqué à « 80% » pendant des semaines sans que personne ne le remarque.
Livrer dans les délais
Livrer dans les délais se prépare dès le premier jour du projet — ça ne se décide jamais dans la dernière semaine.
Comme un marathon : on ne rattrape pas un mauvais départ en sprintant les derniers 500 mètres — le rythme des dix premiers kilomètres détermine largement le temps final.
Techniques qui marchent
- Couper le périmètre avant de repousser la date, si un choix devient nécessaire en cours de route — le triangle du bloc 00 s'applique concrètement ici.
- Détecter le retard tôt et le communiquer immédiatement, jamais en espérant « rattraper » silencieusement — un retard annoncé tôt se gère, un retard découvert à la date de livraison se subit.
- Réserver la dernière ligne droite à la stabilisation (tests, corrections), jamais à finir les dernières fonctionnalités.
Face à un retard détecté en cours de projet, quelles sont les deux options réelles, en dehors de repousser la date ?
Voir la réponse
Couper le périmètre (livrer moins de fonctionnalités mais à temps) ou accepter un compromis de qualité assumé — repousser la date n'est qu'une des trois variables du triangle qualité/coût/délai, pas la seule option disponible.
Les méthodes : Agile, Waterfall, Scrum
Aucune méthode n'est universellement meilleure — chacune répond à un niveau différent d'incertitude sur ce qui doit être livré.
Le Waterfall, c'est construire un pont : on planifie tout à l'avance parce qu'on ne peut pas changer les fondations une fois coulées. L'Agile, c'est cuisiner un plat qu'on goûte en cours de route : on ajuste au fur et à mesure parce que le résultat final peut évoluer avec ce qu'on découvre.
Trois repères
- Waterfall (cascade) : phases séquentielles (cadrage → conception → réalisation → tests → livraison), chacune validée avant de passer à la suivante — adapté quand les exigences sont stables et bien connues dès le départ.
- Agile : principe général de livraisons courtes et itératives avec ajustement continu selon les retours — adapté quand les exigences sont susceptibles d'évoluer ou ne sont pas toutes connues au départ.
- Scrum : une méthode Agile parmi d'autres, avec un cadre précis — sprints de durée fixe (souvent deux semaines), rôles définis (Product Owner qui priorise, Scrum Master qui facilite, équipe qui réalise), rituels réguliers (planification, points quotidiens courts, rétrospective de fin de sprint).
Le choix ne dépend pas d'une mode mais du niveau d'incertitude du projet : plus les exigences risquent de changer, plus une approche itérative protège contre le gaspillage de tout planifier sur une hypothèse qui ne tiendra pas.
Sur quel critère principal choisir entre une approche Waterfall et une approche Agile pour un projet donné ?
Voir la réponse
Le niveau d'incertitude sur les exigences finales : Waterfall convient quand elles sont stables et bien connues dès le départ (constructions, systèmes réglementés) ; Agile convient quand elles risquent d'évoluer en cours de route (produits numériques, contextes incertains).
Bloc mêlé
Les neuf sujets ci-dessus sont ici volontairement mélangés — un vrai projet ne présente jamais ses problèmes dans l'ordre du cours.
Tout est marqué « urgent » dans la liste de tâches. Problème ?
Une liste où tout est prioritaire n'a pas de vraies priorités — il faut trancher avec des critères objectifs partagés.
Une tâche importante n'a pas de nom clairement associé. Risque ?
Elle n'appartient à personne et ne se fera probablement jamais — assigner un responsable unique.
La date de livraison a été fixée avant de calculer le chemin critique. Risque ?
La date devient un vœu plutôt qu'un plan réel — risque de retard non anticipé.
Un risque identifié en début de projet n'a jamais été revu depuis. Problème ?
Un risque non suivi n'est pas un risque géré — la liste doit être vivante, pas figée au lancement.
Une équipe fait des sprints de 2 semaines mais ne change jamais rien selon les retours clients. Est-ce de l'Agile ?
Non — juste du Waterfall découpé en tranches. L'esprit d'ajustement continu manque.
Le commanditaire et l'équipe ont chacun une idée différente de l'objectif final. Conséquence probable ?
Un désaccord inévitable en fin de projet, au pire moment — il fallait faire valider l'objectif ensemble dès le départ.
Atelier approfondi et votre projet
Piloter un seul projet réel de bout en bout vaut mieux que connaître neuf techniques jamais appliquées — la technique 4 appliquée à ce cours.
Atelier — organiser un événement d'entreprise dans deux mois
- Objectif — un résultat précis : « 80 participants, satisfaction moyenne 4/5 », pas juste « un bel événement » (bloc 01).
- Découper — trois lots concrets : lieu/logistique, programme/intervenants, communication/inscriptions (bloc 02).
- Prioriser — MoSCoW : réserver le lieu et confirmer la date = indispensable ; traiteur haut de gamme = souhaitable ; animation surprise = possible (bloc 03).
- Répartir — un responsable unique par lot, le reste de l'équipe informé (bloc 04).
- Calendrier — chemin critique : rien ne peut avancer sans le lieu confirmé en premier (bloc 05).
- Risques — lister trois risques (intervenant qui annule, budget dépassé, météo si extérieur) avec un plan pour chacun (bloc 06).
- Suivi — point hebdomadaire court, tableau partagé des lots terminés, en cours, bloqués (bloc 07).
- Livrer — dernière semaine réservée aux répétitions et vérifications, pas à finir la logistique (bloc 08).
Ici, une approche Waterfall convient bien : la date est fixe et non négociable, et l'incertitude sur « ce qui doit être livré » reste faible (bloc 09) — un choix de méthode conscient, pas par défaut.
Votre projet — apprentissage par le projet
Cochez au fur et à mesure. Rien n'est acquis tant que vous n'avez pas piloté un vrai projet, pas un exemple du cours.