i

Description

Un plan d'aménagement général d'une ville, dessiné avant le chantier

Source

BJGunnaban · page d’origine

Licence

CC0 Domaine public

Photo d’origine, non retouchée. L’arrière-plan en est une version stylisée par le site.

Fondamentaux de la conduite de projet

Vous saurez définir un projet, son cycle de vie, ses contraintes (triangle puis « quadruple contrainte ») et ses rôles, sans jargon d'école.

En bref

• Vous saurez définir un projet, son cycle de vie, ses contraintes (triangle puis « quadruple contrainte ») et ses rôles, sans jargon d'école.
• Vous saurez distinguer pilotage prédictif et adaptatif, et choisir selon le niveau d'incertitude (grille de Cynefin).
• Vous saurez raisonner en valeur, en risque et en parties prenantes, et non seulement en délai et en coût.
• Vous saurez ce qui change pour un projet informatique, puis pour un projet data / BI / datamart, où la qualité des chiffres est le vrai livrable.
• Ce fichier est le socle commun : Scrum, les méthodes prédictives et les méthodes agiles s'y appuient.

Sur cette page

1. 🟢 Novice — Qu'est-ce qu'un projet ?
   1. Réussir : trois niveaux de succès
2. 🟢 Novice — Le cycle de vie d'un projet
   1. Cycle de vie du produit contre cycle de vie du projet
   2. Les trois grandes façons d'enchaîner les phases
3. 🟢 Novice — Triangle et quadruple contrainte
   1. Ce que dit le triangle en pratique
   2. La variante agile : fixer le temps et le coût, faire varier le périmètre
4. 🟢 Novice — Les rôles
   1. MOA et MOE, le vocabulaire francophone
   2. Responsabilité, autorité, redevabilité
5. 🟡 Pratique — Prédictif ou adaptatif
   1. Les approches hybrides
   2. Prédictif ou adaptatif : un test en 5 questions
6. 🟡 Pratique — Valeur et bénéfices
   1. Cas d'affaires (business case)
   2. Prioriser par la valeur
7. 🟡 Pratique — Gérer le risque
   1. Les quatre réponses classiques
   2. Criticité
   3. L'agilité est une gestion du risque
8. 🟡 Pratique — Parties prenantes et communication
   1. Communiquer : plan minimal
9. 🟡 Pratique — Spécificités des projets informatiques
   1. Le constat historique
   2. Les ingrédients de la maturité IT moderne
10. 🟡 Pratique — Spécificités des projets data en bref
11. 🔴 Expert — Incertitude, Cynefin et choix de méthode
    1. Le « cône d'incertitude »
    2. Stacey et la zone de complexité
12. 🔴 Expert — Le triangle est un mensonge utile
    1. Les trois lois qui désamorcent les illusions
13. 🔴 Expert — Économie du retard, coût du délai et options réelles
    1. Coût du retard (Cost of Delay)
    2. Retarder les décisions, acheter des options
    3. Loi de Little et flux
14. 🔴 Expert — Lois et biais qui structurent les projets
    1. Sécurité psychologique
15. Contribution de l'IA
16. Voir aussi

Niveau : 🟢→🔴

🟢 Novice — Qu'est-ce qu'un projet ?#

Un projet est un effort temporaire (début et fin identifiables) qui produit un résultat unique (un produit, un service, un changement) dans des contraintes données. Deux mots comptent : temporaire (par opposition à l'exploitation, qui est récurrente) et unique (même si l'on a déjà fait « quelque chose de comparable », le contexte, l'équipe et les données diffèrent).

Cette définition de bon sens recoupe celles des référentiels usuels (PMBOK du PMI, PRINCE2, ISO 21500/21502). On n'a pas besoin de les citer pour travailler : retenez qu'un projet se justifie (pourquoi ?), se borne (quoi, jusqu'où, avec quoi ?) et se termine (quand sait-on que c'est fini ?).

Un projet n'existe que s'il a un commanditaire (qui paie et décide), un objectif vérifiable et une équipe. Sans commanditaire identifié, c'est une « initiative » qui dérivera ; sans objectif vérifiable, on ne saura jamais s'il a réussi.

Réussir : trois niveaux de succès#

Un projet peut réussir à trois niveaux, indépendants :

1. Succès de gestion : livré dans les temps, le budget, le périmètre. Mesurable à la clôture.
2. Succès produit : le livrable fonctionne, est utilisé, est de qualité. Mesurable à la livraison et après.
3. Succès métier : les bénéfices attendus se réalisent (ventes mieux pilotées, temps gagné, décisions meilleures). Mesurable des mois plus tard.

Un datamart livré à l'heure (succès 1) dont personne ne fait confiance aux chiffres (échec 2) ne produit aucun bénéfice (échec 3). L'inverse existe : un projet « en retard » qui change l'activité. Une conduite de projet mûre mesure les trois.

🟢 Novice — Le cycle de vie d'un projet#

Tout projet traverse, explicitement ou non, des phases : on décide de le faire, on le prépare, on le réalise, on le met en service, on le clôt. Les méthodes diffèrent sur la façon d'enchaîner ces phases, pas sur leur existence.

Le suivi n'est pas une phase mais un fil transversal. De même, la conduite du changement (formation, adoption) commence au cadrage, pas à la recette.

Cycle de vie du produit contre cycle de vie du projet#

Il faut distinguer :

• le cycle de vie du projet (de l'idée à la clôture) ;
• le cycle de vie du produit (conception → exploitation → évolution → retrait) — souvent bien plus long.

Un projet est un épisode dans la vie d'un produit. Ignorer la phase « exploitation et retrait » à la conception est la source classique de dette : on livre vite, et on paie pendant dix ans. Cette vision « coût total de possession » justifie d'inclure, dès le cadrage, support, supervision, documentation et plan de retrait des versions anciennes. Pour la pratique de la livraison et de l'exploitation, voir CI/CD et son pendant CI/CD pour la data.

Les trois grandes façons d'enchaîner les phases#

Le détail des méthodes est dans Méthodes prédictives et Méthodes agiles et Lean.

🟢 Novice — Triangle et quadruple contrainte#

Le triangle de fer (ou triangle de la gestion de projet, « iron triangle ») pose trois contraintes qui s'influencent : périmètre (ce qu'on livre), délai (quand), coût (avec quels moyens). Modifier l'une déplace au moins une autre. La qualité se place au centre : la sacrifier est la variable d'ajustement cachée.

Le PMBOK a ensuite élargi à six contraintes (périmètre, calendrier, coût, qualité, ressources, risque) : on parle parfois de « quadruple contrainte » en ajoutant la qualité ; l'agile en propose une variante utile (voir ci-dessous).

Ce que dit le triangle en pratique#

La variante agile : fixer le temps et le coût, faire varier le périmètre#

Le triangle agile inverse le dogme : on fixe le délai (le timebox) et le coût (la taille d'équipe), et on laisse le périmètre varier en l'ordonnant par valeur. Qualité non négociable (la Definition of Done est un plancher). C'est le sens profond d'un sprint : les 20 % de périmètre les moins utiles sautent d'abord, pas la qualité.

🟢 Novice — Les rôles#

Quelle que soit la méthode, on retrouve les mêmes fonctions, que les méthodes nomment différemment. Distinguer la fonction du titre évite les débats stériles (« chef de projet » contre « Scrum Master »).

MOA et MOE, le vocabulaire francophone#

En France, on parle de MOA (maîtrise d'ouvrage : le client, qui exprime le besoin et valide) et de MOE (maîtrise d'œuvre : qui réalise). L'écart entre les deux est une source majeure de malentendus : la MOA « jette le besoin par-dessus le mur », la MOE livre, et la recette révèle les écarts. Les méthodes agiles réduisent cette cloison en intégrant un représentant du métier dans le cycle (Product Owner, utilisateurs en revue), ce qui est précisément le bénéfice recherché. Dans un contexte BI, le Product Owner data (voir Scrum et data) joue ce pont.

Responsabilité, autorité, redevabilité#

Trois mots à ne pas confondre. La responsabilité (faire), l'autorité (décider) et la redevabilité (« rendre des comptes ») doivent coïncider. Un chef de projet redevable du résultat sans autorité sur le périmètre ni sur l'équipe est en position intenable. Scrum résout en nommant un Product Owner unique doté d'autorité sur le contenu (et redevable de la valeur), et une équipe auto-gérée responsable de comment livrer. Le modèle RACI (Responsible, Accountable, Consulted, Informed) formalise la même idée en tableau : une seule case « A » par ligne.

🟡 Pratique — Prédictif ou adaptatif#

Les approches se situent sur un continuum entre deux pôles.

Aucun pôle n'est « bon ». Une construction d'immeuble réglementée se pilote en prédictif ; une application de force de vente dont les usages sont inconnus se découvre en adaptatif. Le vrai danger est la méthode mal appariée à l'incertitude : planifier au détail un terrain inconnu, ou improviser sur un sujet réglementaire et irréversible.

Les approches hybrides#

Dans la réalité d'une entreprise, on mélange presque toujours : cadrage et budget annuel prédictifs en haut, exécution itérative en bas (parfois appelée « water-scrum-fall » quand c'est subi plutôt que choisi). La question utile n'est pas « pur ou hybride ? » mais « où mets-je de la prévisibilité et où de l'adaptation ? ». Le détail est dans Choisir et hybrider et le Comparatif des méthodes.

Prédictif ou adaptatif : un test en 5 questions#

1. Le besoin est-il stable et bien compris des deux côtés ? (oui → prédictif)
2. La solution technique est-elle connue et déjà éprouvée ? (non → adaptatif)
3. Le coût d'une erreur découverte tard est-il prohibitif (réglementaire, physique, irréversible) ? (oui → prédictif sur ces zones)
4. Les utilisateurs sont-ils disponibles pour un retour fréquent ? (non → l'adaptatif ne produira pas ses bénéfices)
5. Le financeur accepte-t-il de piloter à la valeur plutôt qu'au périmètre ? (non → prévoir une couche de gouvernance prédictive)

🟡 Pratique — Valeur et bénéfices#

La valeur est ce qui justifie le projet. Elle n'est pas le périmètre livré : c'est le bénéfice réalisé par ceux qui utilisent ce qui est livré.

Une équipe qui ne suit que les outputs optimise l'activité ; une équipe qui suit les outcomes optimise l'utilité. C'est le glissement que propose l'agilité : passer d'une feature factory (usine à fonctionnalités) à une équipe orientée résultats.

Cas d'affaires (business case)#

Un cas d'affaires répond à : quel problème ? quels bénéfices (chiffrés ou qualitatifs) ? à quel coût total ? quels risques ? quelle alternative « ne rien faire » ? Il doit être revu aux jalons : un projet dont la justification s'est effondrée doit pouvoir être arrêté sans honte. PRINCE2 en fait un principe (justification économique continue). Pour le pilotage budgétaire et la valeur côté équipe, voir la matrice Budget, valeur et bénéfices.

Prioriser par la valeur#

Plusieurs outils, à combiner avec esprit critique :

• MoSCoW (Must / Should / Could / Won't) : simple, mais tout devient « Must » sans arbitrage ferme.
• Coût du retard (Cost of Delay) et WSJF (Weighted Shortest Job First) = coût du retard ÷ durée : on traite d'abord ce qui perd le plus de valeur par unité de temps d'attente.
• Valeur × confiance ÷ effort (variantes ICE/RICE) : utile, mais les chiffres de départ sont des estimations ; ne pas leur prêter une précision qu'ils n'ont pas.
• Kano : distingue besoins basiques, attendus et enthousiasmants.
• Story mapping : voir le parcours utilisateur pour trancher « le plus petit incrément qui a du sens ».

🟡 Pratique — Gérer le risque#

Un risque est un événement incertain qui, s'il se produit, a un effet (positif ou négatif) sur les objectifs. Un risque n'est pas un problème : un problème est déjà là (on le traite), un risque est probable (on l'anticipe). Confondre les deux produit des « registres de risques » qui sont des listes de problèmes.

Les quatre réponses classiques#

Criticité#

Criticité = probabilité × impact, sur des échelles simples (1 à 5). Prioriser par criticité décroissante ; ne pas dépasser une quinzaine de risques activement suivis. Un risque est vivant : nommer un propriétaire, une date de revue, un déclencheur (signal d'alerte) et une action.

L'agilité est une gestion du risque#

L'itération courte est la meilleure réponse au risque de conception (se tromper de produit) : on le découvre en deux semaines plutôt qu'en deux ans. Elle ne traite pas à elle seule le risque d'architecture, de sécurité ou de conformité, qui demandent des garde-fous explicites (spikes, revues, contraintes dans la Definition of Done). Le chapitre risque des matrices est dans Gestion des risques.

🟡 Pratique — Parties prenantes et communication#

Une partie prenante est toute personne ou entité qui peut affecter le projet ou en être affectée. On les identifie, on comprend leurs attentes, on décide quoi faire d'elles.

La grille pouvoir × intérêt (Mendelow) est la plus répandue :

Communiquer : plan minimal#

Le but est la transparence : plus un écart (retard, doute sur la qualité) est annoncé tôt, moins il coûte. Un projet « tout vert » jusqu'au dernier mois cache presque toujours une information non remontée (le « syndrome de la pastèque » : vert dehors, rouge dedans). Les indicateurs utiles sont présentés dans Métriques et reporting de projet. Le thème correspondant de la matrice est Parties prenantes et communication.

🟡 Pratique — Spécificités des projets informatiques#

Un projet informatique a des traits qui le distinguent d'un projet de BTP ou de production : il produit un objet immatériel, copiable à coût nul, modifiable en permanence, dont la complexité est invisible (le code ne se voit pas, il se lit).

Le constat historique#

Les rapports d'enquête sur les échecs de projets (comme le CHAOS Report du Standish Group) ont fortement marqué le débat, mais leur méthodologie est contestée. On les cite avec prudence : l'idée à retenir est que les gros projets prévus en une fois, à périmètre figé, échouent plus que les petits projets livrés par étapes, ce que recoupent d'autres sources (dont l'expérience du manifeste agile). On évitera donc de s'appuyer sur un pourcentage précis.

Les ingrédients de la maturité IT moderne#

• Petits lots : plus petit lot, moins de risque, plus de retour (principe du Lean).
• Automatisation : build, tests, déploiement répétables.
• Feedback rapide : à tous les étages (tests, revue de code, revue de sprint, supervision).
• Responsabilité de bout en bout : « you build it, you run it » (vision DevOps).

Les travaux de recherche de l'équipe DORA (Accelerate, et les rapports annuels « State of DevOps ») ont montré que la fréquence de déploiement, le délai de livraison, le taux d'échec des changements et le temps de restauration sont des indicateurs corrélés à la performance organisationnelle. Ce sont les « quatre métriques clés » ; voir CI/CD pour leur utilisation.

🟡 Pratique — Spécificités des projets data en bref#

Un projet data (datamart, entrepôt, reporting) partage tout ce qui précède, mais le livrable est un ensemble de chiffres auxquels on doit pouvoir se fier. Le détail est dans Scrum et data et Méthodes spécifiques à la data. En bref :

🔴 Expert — Incertitude, Cynefin et choix de méthode#

Le cadre Cynefin (Dave Snowden) classe les situations selon la relation entre causes et effets, et prescrit une manière d'agir adaptée. Il est précieux pour choisir une méthode car il rappelle qu'il n'existe pas de méthode universelle : il y a des types de problèmes.

Lecture pour la conduite de projet :

• Clair / compliqué : le prédictif et la planification détaillée fonctionnent ; l'expertise suffit, on peut estimer, standardiser, automatiser.
• Complexe : l'agilité (expérimenter, inspecter, adapter) est le bon outil — c'est le territoire de Scrum, dont le fondement est précisément l'empirisme.
• Chaotique : stabiliser d'abord (gestion de crise), analyser ensuite.

Un même projet contient les quatre domaines à des endroits différents. Scrum ne supprime pas le compliqué (il faut toujours de l'expertise), il cadre le complexe.

Le « cône d'incertitude »#

Boehm a illustré (et McConnell a popularisé) l'idée que l'incertitude sur le coût et la durée est très large au tout début d'un projet et se réduit à mesure qu'on avance. La forme exacte et les facteurs numériques font débat et dépendent des contextes ; le message robuste est : une estimation faite avant d'avoir exploré est une fourchette large, pas un engagement. S'engager sur un chiffre unique au cadrage est un acte de gouvernance, pas une mesure.

Stacey et la zone de complexité#

La matrice de Stacey croise degré d'accord sur le besoin et certitude sur la technique. Quand ni l'un ni l'autre ne sont acquis, on est en « complexité » et les méthodes prescriptives échouent. Ce cadrage justifie d'investir dans la découverte (ateliers, prototypes, spikes) avant de s'engager sur un périmètre.

🔴 Expert — Le triangle est un mensonge utile#

Le triangle de fer est un excellent outil pédagogique et un mauvais modèle prédictif :

1. Le périmètre n'est pas homogène. Vingt exigences n'ont pas la même valeur : dans l'immense majorité des cas, une petite fraction porte l'essentiel de la valeur (ordre de grandeur courant, pas une loi). Parler de « périmètre » comme d'un bloc masque l'arbitrage essentiel.
2. La qualité n'est pas une variable continue. Il y a un plancher en dessous duquel on ne livre pas de valeur (chiffres faux, sécurité défaillante). Et la qualité interne (maintenabilité) influence le délai futur : la sacrifier emprunte au futur à taux élevé.
3. Délai et coût ne sont pas indépendants du périmètre via une loi linéaire : la relation est non linéaire (loi de Brooks, coûts de coordination, loi de Parkinson).
4. Le triangle ignore la valeur et le risque, qui sont pourtant ce qui justifie le projet.

L'alternative est un « diamant » ou une vue plus riche : valeur, risque, qualité, durée, coût. Dans un cadre agile, on pilote la valeur livrée par unité de temps et le risque résiduel, tandis que délai et coût sont fixés par construction.

Les trois lois qui désamorcent les illusions#

La méthode de la chaîne critique (Goldratt) en tire une conséquence : on enlève les marges individuelles et on mutualise un tampon de projet, dont on surveille la consommation. Elle est présentée dans Méthodes prédictives.

🔴 Expert — Économie du retard, coût du délai et options réelles#

Coût du retard (Cost of Delay)#

Don Reinertsen (The Principles of Product Development Flow) a argumenté que l'élément économique le plus négligé en développement est le coût du retard : la valeur perdue par unité de temps de retard d'une livraison. Il en tire le WSJF :

Trois profils de coût du retard illustrent la diversité :

Retarder les décisions, acheter des options#

L'approche options réelles applique la logique financière aux décisions de projet : un choix irréversible tôt se paie par la perte de flexibilité ; différer jusqu'au « dernier moment responsable » (last responsible moment, expression popularisée par la communauté Lean/agile) conserve des options à moindre coût. Ce n'est pas de l'indécision : c'est décider quand l'information est la meilleure, avant que le coût de l'attente ne dépasse celui de l'erreur.

Concrètement pour la data : le choix de la granularité d'une table de faits ou de la clé de substitution d'une dimension est coûteux à inverser (tous les consommateurs en dépendent) — le faire tôt mais en connaissance de cause. Le choix du visuel d'un rapport est peu coûteux à changer — on peut le retarder et l'itérer.

Loi de Little et flux#

La loi de Little (théorie des files d'attente) relie les grandeurs d'un système en régime stable :

Conséquence directe : pour raccourcir le délai sans changer le débit, il faut réduire le travail en cours. Commencer plus de choses ralentit chacune. C'est le fondement mathématique des limites de WIP de Kanban et de la préférence Scrum pour des sprints à périmètre limité. Voir Méthodes agiles et Lean.

🔴 Expert — Lois et biais qui structurent les projets#

Sécurité psychologique#

Les travaux d'Amy Edmondson sur la sécurité psychologique (croyance qu'on peut s'exprimer, signaler une erreur ou un doute sans être sanctionné) et ceux du projet « Aristote » de Google sont cités pour établir que la qualité des interactions d'une équipe pèse plus que sa composition. Pratiquement : un chef de projet qui punit la mauvaise nouvelle reçoit des rapports verts jusqu'à l'effondrement. La culture d'équipe se mesure dans la matrice Équipe et collaboration.

Contribution de l'IA#

Exemples de prompts :

• « Voici le contexte de notre projet [résumé anonymisé]. Liste dix risques que nous n'avons pas mentionnés, classés par probabilité et impact, et pour chacun un signal d'alerte précoce. »
• « Relis ce cas d'affaires comme un directeur financier sceptique : quelles hypothèses sont non étayées ? »

Ce que l'IA ne remplace pas : le jugement sur la valeur, l'arbitrage entre parties prenantes, la responsabilité de la décision, la connaissance de votre historique et de votre culture. Elle ne doit pas recevoir de données confidentielles non autorisées. Attention aux hallucinations (faits, références ou chiffres plausibles mais faux) et à la dette cachée (plans produits sans appropriation par l'équipe). Voir IA et conduite de projet.

Voir aussi#

• Suite logique : Scrum, le cadre puis Scrum en pratique.
• Autres approches : Méthodes prédictives, Agiles et Lean, Comparatif, Choisir et hybrider.
• Pièges transverses : Pièges et bonnes pratiques.
• Mesurer votre pratique : Matrice conduite de projet informatique, Cadrage et vision, Planification et estimation.
• Termes : Glossaire ; lecture des notes : Notation.
• Outils : Planification, Azure DevOps / TFS.

✻ Rédigé par Claude Sonnet 5.5