i

Description

Vue aérienne d'un lotissement de maisons presque identiques le long de rues sinueuses.

Source

Derek Jensen (Tysto) · page d’origine

Licence

PD Domaine public

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

L'estimation par classe de référence

Avant de décrire ce que votre projet a de particulier, demandez-vous comment ont fini les projets qui lui ressemblent.

En bref

• Quoi : estimer à partir de la distribution des résultats de projets semblables (la « vue extérieure »), et non à partir du détail de son propre plan (la « vue intérieure »).
• Pourquoi : la vue intérieure est systématiquement trop optimiste ; la vue extérieure mesure ce qui arrive en moyenne, imprévus compris.
• Comment : choisir une classe de référence, rassembler les résultats réels, en tirer une distribution, positionner son projet, ajuster avec prudence.
• Limite : tout dépend de la classe choisie et de la qualité des données ; sans historique comparable, la méthode ne s'applique pas telle quelle.

Sur cette page

1. Définition
2. Le principe : pourquoi ça marche
3. Comment faire : la procédure pas à pas
4. Exemples
   1. Le manuel scolaire d'Israël années 1970 à 1980 environ
   2. Les dépassements de coûts des grands projets 2002 à 2023
   3. Chiffrer une refonte applicative Exemple illustratif
5. Quand l'utiliser, quand l'éviter
   1. À utiliser
   2. À éviter ou à adapter
6. Limites et critiques
7. Avec l'IA
   1. Détecter
   2. Remédier
   3. Atténuer
   4. Prompts à utiliser
   5. Précautions
8. Sources et vérification
9. Voir aussi
   1. Biais que cette méthode combat
   2. Méthodes complémentaires

Définition#

Illustration inspirée de la personne

Illustration fictive

Illustration fictive

L'estimation par classe de référence (reference class forecasting) consiste à prévoir l'issue d'un projet en la rapprochant de celle d'un ensemble de projets comparables déjà terminés, et à en déduire une fourchette. Elle repose sur la distinction proposée par Daniel Kahneman et Dan Lovallo (1993, Management Science) entre deux manières de regarder un projet :

• la vue intérieure : on analyse le projet lui-même, ses tâches, ses ressources, ses obstacles prévisibles, et l'on construit un scénario ;
• la vue extérieure : on traite le projet comme un cas parmi d'autres d'une catégorie, et l'on regarde comment finissent les cas de cette catégorie.

Kahneman et Lovallo ont décrit la méthode en psychologie ; l'économiste et chercheur en grands projets Bent Flyvbjerg l'a ensuite développée et diffusée pour les grands projets d'infrastructure. Son article « From Nobel Prize to project management: getting risks right » (Project Management Journal, 2006) en expose la procédure. Au Royaume-Uni, à la suite de la révision du Green Book du Trésor (2003), le ministère des Transports et le Trésor ont décidé en 2004 d'appliquer la méthode aux grands projets de transport, avec des majorations de coût (uplifts) fondées sur l'historique.

Le principe : pourquoi ça marche#

Quand on planifie de l'intérieur, on décrit une suite d'étapes qui se déroulent bien. Les imprévus, par définition, ne figurent pas dans le scénario. Résultat : on prévoit le meilleur cas plausible et on le prend pour le cas moyen. C'est le mécanisme de l'erreur de planification, aggravé par l'optimisme et par l'ancrage sur le premier chiffre entendu.

La vue extérieure court-circuite ce mécanisme. Elle ne demande pas de deviner les imprévus : l'historique les contient déjà, y compris ceux qu'on n'aurait pas su imaginer. Elle fait aussi passer la question de « que va-t-il se passer chez nous ? » (où chacun se croit à part) à « que se passe-t-il d'habitude ? ». On connaît aujourd'hui le biais inverse, tout aussi humain : se croire une exception, c'est le travers que la méthode cherche à corriger.

Comment faire : la procédure pas à pas#

Flyvbjerg (2006) décrit trois étapes (classe de référence, distribution, position du projet). Voici une version adaptée à un chiffrage en équipe. Durée : une demi-journée pour une première fois, 30 à 60 minutes une fois les données constituées. Participants : un ou deux estimateurs et quelqu'un qui garde l'historique (PMO, qualité, finance).

1. Estimer d'abord, en privé. Chacun note sa propre estimation (la vue intérieure), pour pouvoir la comparer ensuite. Ne pas montrer ce chiffre avant d'avoir fait l'exercice.
2. Choisir la classe de référence. Des projets assez semblables (même type, même ordre de taille, même technologie ou contexte) pour que la comparaison ait un sens, et assez nombreux pour dégager une distribution. C'est l'étape délicate : trop étroite, on n'a que trois cas ; trop large, la moyenne ne dit plus rien.
3. Rassembler les résultats réels. Pour chaque projet de la classe : l'estimation initiale et le résultat final (coût, durée, périmètre livré). L'important est l'écart relatif entre les deux. Utiliser les chiffres de fin de projet, pas les souvenirs.
4. Construire la distribution. Calculer médiane, quartiles, valeurs extrêmes de l'écart. Regarder la queue : un petit nombre de projets très dérivés pèse plus que la moyenne ne le laisse croire.
5. Positionner son projet. Se placer dans la distribution : le projet est-il typique ou extrême ? Le point de départ est la médiane de la classe.
6. Ajuster, avec parcimonie. Déplacer l'estimation seulement pour des raisons précises, vérifiables et que les projets de la classe n'avaient pas (équipe qui a déjà réalisé exactement la même chose, outil réellement différent). Écrire la raison. Un ajustement « parce que nous, on est meilleurs » est refusé.
7. Choisir un niveau de risque. Un budget ou un délai se fixe sur un percentile de la distribution (par exemple, un coût qui n'est dépassé que dans une minorité de cas), choisi en fonction de ce qu'on peut supporter si l'on se trompe.
8. Enregistrer le résultat pour la fois suivante. Chaque projet terminé enrichit la classe.

Livrables : la définition de la classe et ses critères, la distribution des écarts, l'estimation finale avec sa fourchette, la liste des ajustements justifiés.

Exemples#

Quand l'utiliser, quand l'éviter#

À utiliser#

• Pour tout engagement chiffré : durée, budget, charge, avant de le communiquer.
• Quand le sponsor ou le client a déjà un chiffre en tête : l'historique est un contrepoids (voir l'ancrage).
• Pour les projets d'un type récurrent (refontes, migrations, déploiements, développements d'une taille donnée).
• Pour réviser en cours de route : un projet en retard sur sa classe a une probabilité connue de l'être encore.

À éviter ou à adapter#

• Projet vraiment unique : pas de classe sensée. On peut élargir à des projets « de la même famille de difficulté », avec prudence.
• Aucun historique : on peut commencer par des données externes (benchmarks publics, études sectorielles), en gardant à l'esprit qu'elles décrivent d'autres contextes.
• Classe polluée : si les chiffres de l'historique ont été « arrangés » en cours de projet (budget réajusté, périmètre réduit), la distribution est trop flatteuse.
• Pour décider d'un risque précis : la méthode donne des fréquences, pas des causes ; compléter par un pré-mortem.

Limites et critiques#

• Le choix de la classe est une décision de jugement. Deux estimateurs honnêtes peuvent choisir deux classes qui donnent deux fourchettes. Il faut écrire les critères et les tenir.
• Les données sont rares et biaisées. On n'a souvent que les projets terminés (voir le biais de survie) ; ceux qu'on a abandonnés manquent à la statistique et rendent l'historique trop favorable.
• Ajuster trop, c'est retomber dans la vue intérieure. Dans la pratique, les équipes rouvrent la discussion pour revenir à leur chiffre. La parade est d'exiger une raison écrite et vérifiable.
• L'amélioration passée n'est pas garantie. Une organisation qui s'est réellement améliorée est pénalisée par un historique ancien ; l'inverse vaut aussi.
• Pas de remède aux pressions politiques. Flyvbjerg insiste sur le fait que, si l'on a intérêt à sous-estimer, la meilleure méthode ne suffira pas : il faut aussi de la transparence et des sanctions pour les estimations manipulées.
• Chiffres à manier avec précaution. Les moyennes citées (28 %, 27 %) mêlent des secteurs, des pays et des époques ; elles montrent un sens du biais, pas un coefficient à appliquer tel quel à votre projet.

Avec l'IA#

Prompts à utiliser#

1. Construire la distribution à partir de l'historique. À utiliser avec des données réelles de vos projets terminés (anonymisées).

Voici l'historique de projets terminés, avec pour chacun le type, la taille, l'estimation initiale et le résultat final : [tableau].
1. Calcule pour chaque projet l'écart relatif (final - initial) / initial, pour la durée et pour le coût.
2. Donne la médiane, les quartiles, le minimum, le maximum, et le nombre de projets dépassant de plus de 50 % et de plus de 100 %.
3. Signale les projets qui ne sont pas comparables au suivant (décris-le) : [description du projet à estimer].
Utilise UNIQUEMENT les données ci-dessus : n'ajoute aucune statistique « du marché » et dis quand l'échantillon est trop petit pour conclure.

2. Contrôler un ajustement. Quand l'équipe veut s'écarter de la médiane de la classe.

La médiane de la classe de référence donne [valeur]. L'équipe propose [valeur différente] pour ces raisons : [liste].
Pour chaque raison : dis si elle est vérifiable, si les projets de la classe en bénéficiaient aussi, et quelle preuve on pourrait demander.
Conclus : quel ajustement est justifié, lequel ne l'est pas, et pourquoi. Ne cherche pas à plaire : si l'ajustement ressemble à de l'optimisme, dis-le.

Précautions#

• Ne demandez pas à l'IA « combien de temps prennent en général les projets de ce type ? » en attendant un chiffre fiable : la réponse sera plausible, pas sourcée.
• Donnez les données défavorables comme les autres ; un historique nettoyé donne une distribution flatteuse.
• Ne transmettez pas de budgets ni de données de clients à un outil non autorisé.

Sources et vérification#

• Kahneman, D. & Lovallo, D. (1993), « Timid choices and bold forecasts: A cognitive perspective on risk taking », Management Science, 39(1), 17-31 — vue intérieure et vue extérieure.
• Flyvbjerg, B. (2006), « From Nobel Prize to project management: getting risks right », Project Management Journal, 37(3), 5-15 — procédure de la méthode.
• Flyvbjerg, B., Holm, M. S. & Buhl, S. (2002), « Underestimating costs in public works projects: error or lie? », Journal of the American Planning Association, 68(3), 279-295 — 258 projets.
• Flyvbjerg, B. & Budzier, A. (2011), « Why Your IT Project May Be Riskier Than You Think », Harvard Business Review, septembre 2011 — 1 471 projets informatiques.
• Kahneman, D. (2011), Thinking, Fast and Slow, Farrar, Straus and Giroux — chapitre 23, « The Outside View » : l'histoire du manuel scolaire.
• Flyvbjerg, B. & Gardner, D. (2023), How Big Things Get Done, Currency — synthèse grand public des travaux de Flyvbjerg.

Voir aussi#