# Piège 3 - La planification

> Un plan est une hypothèse, pas une promesse. La plupart des programmes le traitent comme une promesse. La pensée agile aide au niveau des équipes, mais la plupart des organisations peinent encore à planifier au niveau du programme.

Source: https://www.bluewise.fr/fr/why-programs-fail-the-planning-trap  
Author: Marc Morel  
Published: 2026-10-15  
Category: Programs  
Series: Why programs fail, part 4

## Le plus beau dépassement du monde

En 1957, un jeune architecte danois, Jørn Utzon, remporte le concours pour concevoir le nouvel opéra de Sydney : des coques blanches s'élevant au-dessus du port comme des voiles. Le plan promettait 7 millions de dollars australiens et une ouverture en janvier 1963.

Le chantier démarre en 1959, avant que quiconque sache comment construire les coques. Une partie du podium doit être démolie puis reconstruite pour porter un toit que personne n'avait conçu au moment où on l'avait coulé. Utzon part en 1966 et ne revient jamais.

L'Opéra ouvre en octobre 1973, avec dix ans de retard, pour 102 millions de dollars : plus de quatorze fois l'estimation, et toujours le record Guinness du plus grand dépassement de coût proportionnel pour un bâtiment. C'est aujourd'hui l'un des bâtiments les plus admirés de la planète. Personne ne se souvient du plan. Ceux qui l'ont vécu ne l'oublient jamais.

## Une hypothèse déguisée en promesse

Chaque programme commence par un plan : un périmètre, une date, un budget. À ce moment-là, c'est la meilleure estimation qu'un groupe de personnes compétentes puisse faire d'un avenir que personne ne voit.

Puis quelque chose de subtil se produit. L'estimation entre dans un business case. Le business case est approuvé. La date est annoncée au conseil d'administration, au régulateur, aux clients. Et l'hypothèse devient discrètement une promesse.

À partir de là, la réalité n'a que deux façons de rencontrer le plan. Elle peut le confirmer, ce qui est rare. Ou elle peut le contredire, et les gens doivent choisir entre changer le plan, ce qui ressemble à rompre une promesse, et le protéger, ce qui ressemble à de la loyauté. La plupart choisissent la loyauté. Ce n'est pas de la malhonnêteté ; c'est ainsi que les organisations récompensent les gens.

C'est cela, le piège de la planification : s'engager sur une estimation comme s'il s'agissait d'un fait, puis la défendre au lieu de la mettre à jour.

## Les dix visages du piège

En 25 ans, je l'ai vu prendre dix formes, en trois familles : comment on estime, comment on s'engage, et comment on ajuste. La plupart des programmes en retard en présentent quatre ou cinq.

### Comment on estime

- **« Notre programme est différent. »** Chaque programme semble unique vu de l'intérieur, donc personne ne regarde comment des programmes similaires se sont réellement déroulés. Daniel Kahneman appelait cela la _vision de l'intérieur_ : on planifie à partir de sa propre histoire, pas à partir des faits observés chez tous les autres.
- **L'estimation comme négociation.** Le premier chiffre honnête est « trop élevé », alors on le retravaille jusqu'à ce qu'il rentre dans l'enveloppe budgétaire. Puis la négociation s'inverse : les équipes blâmées pour des « points manqués » apprennent à se garder de la marge, et les estimations gonflent discrètement. Dans les deux cas, le chiffre cesse d'être une prévision et devient une défense.
- **Aucune place pour l'inconnu.** Le plan couvre chaque tâche connue, et rien d'autre. La provision pour aléas est soit absente, soit discrètement dépensée dès le premier trimestre pour des choses connues depuis le début.

### Comment on s'engage

- **Périmètre, date et budget, tous figés.** Verrouiller les trois laisse la qualité comme seule variable. Elle cède en silence, et la facture arrive après la mise en production.
- **La date est venue en premier.** L'échéance a été annoncée avant que quiconque ne planifie le travail, et le plan a ensuite été construit à rebours pour s'y ajuster. Tout paraît faisable, parce que c'est ainsi qu'il a été conçu.
- **Construire avant de concevoir.** Comme pour le podium de l'Opéra, le travail démarre avant que les inconnues clés ne soient résolues, pour montrer des progrès ou pour sécuriser un financement. La vitesse du début devient le retravail de la fin.
- **La longue fenêtre.** Des années de construction avant le premier vrai utilisateur. Plus la fenêtre est longue, plus le monde a le temps de changer sous le plan : nouvelles réglementations, nouveaux dirigeants, nouvelles technologies.

### Comment on ajuste

- **La fausse précision.** Un diagramme de Gantt détaillé au jour près pour le dix-huitième mois. La précision suggère une certitude que personne n'a, et fait passer chaque écart pour un échec.
- **Des plans par équipe, pas par programme.** Chaque équipe a un plan crédible. L'intégration entre elles, là où se trouve l'essentiel du risque, n'appartient au plan de personne.
- **Le coût irrécupérable.** « On a trop dépensé pour s'arrêter maintenant. » L'argent déjà dépensé devient la raison de continuer à dépenser, bien après que le business case a cessé d'avoir du sens.

L'agilité était censée dissoudre tout cela : des itérations courtes, une vélocité mesurée, un backlog à la place d'un Gantt. Au niveau des équipes, cela marche souvent. Au niveau du programme, c'est généralement la culture qui l'emporte. Depuis une décennie, les enquêtes State of Agile désignent la culture comme le premier frein au passage à l'échelle, et dans une édition récente, seuls 11 % des répondants se disaient très satisfaits de l'agilité.

Pire, « l'agilité » devient souvent un joker. Un programme qui n'arrive pas à décider ce qu'il veut appelle son indécision de l'agilité : « on verra ça dans les sprints ». Regardez de plus près, et le programme classique est toujours là. La date a été annoncée au conseil d'administration. L'enveloppe budgétaire est figée. L'intégration et la migration des données se font toujours en un seul big bang à la fin. La seule chose qui a disparu, c'est la spécification. De minces user stories que personne n'a challengées ont remplacé de vraies exigences, et les critères d'acceptation sont écrits après le code. Les spécifications sont plus faibles que jamais, alors que périmètre, date et budget sont aussi figés qu'avant.

Ce n'est pas de l'agilité. C'est du cycle en V sans les documents : tous les engagements d'un programme classique, sans aucune de sa réflexion en amont. La vraie agilité fait varier le périmètre par ordre de valeur. L'agilité joker ne fait rien varier, sauf la clarté.

Dès que la vélocité devient un objectif, les équipes font ce que fait tout système mesuré : elles s'adaptent à la mesure. Plus d'une fois, j'ai vu une équipe estimer exactement la même story à 13 points, puis à 34. J'ai aussi vu le mouvement inverse. Des équipes à qui l'on reprochait de ne pas avoir un rythme de livraison prévisible ont ralenti volontairement : elles ont calé leur rythme au niveau le plus bas qu'elles étaient certaines d'atteindre, et ne l'ont jamais dépassé. La vélocité est devenue parfaitement stable, et parfaitement inutile comme prévision.

La marge ne garantit même pas la sécurité. Une réserve cachée dans l'estimation d'une équipe tend à être consommée, si bien que le programme dépasse quand même alors que chaque équipe semble en sécurité. La sécurité doit se trouver dans une provision pour aléas unique, visible et mutualisée, pas dans cinquante provisions privées.

## La loi d'airain

Si cela vous semble pessimiste, regardez les données. Bent Flyvbjerg, professeur à Oxford, a passé des décennies à constituer une base de données de plus de 16 000 grands projets. Dans _How Big Things Get Done_, lui et Dan Gardner rapportent que seuls 8,5 % ont respecté à la fois le budget et le calendrier, et seulement 0,5 % ont en plus livré les bénéfices promis. Un projet sur deux cents.

Le second constat compte encore plus. Les dépassements ne se répartissent pas régulièrement autour d'une petite moyenne. Une part significative des projets ne dépasse pas de 10 % ou 20 % ; ils dépassent d'un facteur multiple, comme l'Opéra. Planifier sur la moyenne vous laisse sans défense face à la queue de distribution.

### L'IT est le pire des cas

En 2025, Flyvbjerg et quatre co-auteurs sont allés plus loin. Ils ont comparé 11 011 projets répartis en 23 types, des routes et des parcs éoliens jusqu'au nucléaire et à l'IT. La question était simple : l'IT est-elle vraiment plus risquée que tout le reste, ou en a-t-elle seulement l'air ?

Elle est plus risquée. L'IT a la queue de distribution la plus épaisse des 23 types. C'est le seul dont la queue est si lourde que, mathématiquement, sa moyenne et sa variance sont infinies : il n'existe pas de « dépassement typique » sur lequel planifier. Et parmi les projets IT qui dépassent de plus de 50 %, le dépassement moyen est de 453 %.

Leur explication vous semblera familière. Deux facteurs ressortent : des développements sur mesure plutôt que des composants modulaires, et une prise de décision « pensée rapide » qui laisse les projets mal préparés. Les antidotes qu'ils proposent sont la modularité et la pensée lente.

### Le temps est le multiplicateur

L'explication de Flyvbjerg pour la queue de distribution est d'une simplicité remarquable : plus un projet dure, plus sa fenêtre de vulnérabilité s'élargit. Chaque mois supplémentaire est un mois de plus pour que quelque chose tourne mal. Une personne clé s'en va, un fournisseur change de stratégie, une réglementation évolue, un sponsor est remplacé.

Une étude antérieure de McKinsey et Oxford portant sur plus de 5 400 grands projets IT a chiffré ce phénomène : chaque année de calendrier supplémentaire augmentait les dépassements de coûts de 15 %. En moyenne, ces projets dépassaient leur budget de 45 % et livraient 56 % de valeur de moins que prévu. Le retard ne coûte pas seulement de l'argent. Il achète du risque supplémentaire.

La conséquence est un cercle vicieux. Un plan optimiste crée une longue construction. Une longue construction crée de l'exposition. L'exposition crée des surprises. Les surprises créent du retard. Et le retard, une fois de plus, allonge la fenêtre.

## Signaux précoces

On peut voir un piège de planification se former dès les toutes premières semaines :

- Personne ne sait dire comment se sont passés des programmes comparables, dans l'entreprise ou en dehors.
- L'estimation a baissé entre deux versions du business case, alors que le périmètre n'a pas bougé.
- La date de mise en production a été annoncée avant que le plan n'existe.
- Le plan comporte une date unique, pas une fourchette.
- Le budget est un chiffre unique, sans aucune idée de ce à quoi ressemble un mauvais scénario.
- Il n'y a pas de ligne de provision pour aléas, ou elle est déjà à moitié dépensée.
- Le premier vrai utilisateur est à plus d'un an.
- La partie la plus risquée du travail est planifiée en dernier.
- Chaque équipe est dans les temps, et personne n'est responsable du plan d'intégration.
- « On verra ça dans les sprints » est la réponse à chaque question de conception ouverte.
- « On ne peut pas s'arrêter maintenant » se dit plus souvent que « est-ce que ça vaut encore le coup ? ».

## Comment planifier honnêtement

La réponse n'est pas d'arrêter de planifier. C'est de planifier comme un scientifique et de s'engager comme un ingénieur : lentement tant que réfléchir coûte peu, vite une fois que construire coûte cher. Flyvbjerg le résume ainsi : « penser lentement, agir vite ».

1. **Partez de la vision de l'extérieur.** Avant d'estimer votre programme, regardez comment des programmes similaires se sont réellement déroulés : leur durée réelle, leur coût, leur dépassement. Flyvbjerg appelle cela la _prévision par classe de référence_. Ajustez ensuite pour ce qui est réellement différent, ce qui est généralement moins que vous ne le pensez.
2. **Donnez des fourchettes, pas des points.** « Entre 14 et 20 mois, 16 le plus probablement » est plus honnête et plus utile que « mise en production le 3 mars ». Engagez-vous à l'extérieur sur l'extrémité prudente de la fourchette.
3. **Résolvez les inconnues avant de construire.** Consacrez les premiers mois aux questions les plus risquées : prototypes, spikes, une tranche à travers l'intégration la plus difficile. Planifier et tester sur le papier ne coûte pas cher ; refaire dans le béton, ou en production, si.
4. **Figez-en deux, faites varier le troisième.** Choisissez ce qui est figé entre le périmètre, la date et le budget, et laissez le troisième s'ajuster ouvertement. En général, la date et le budget tiennent, et le périmètre se négocie par ordre de valeur.
5. **Raccourcissez la fenêtre.** Livrez à de vrais utilisateurs en quelques mois, pas en quelques années. Chaque livraison précoce réduit l'exposition et remplace des hypothèses par des faits. Au vu des données de 2025, c'est plus important dans l'IT que partout ailleurs.
6. **Protégez la provision pour aléas.** Dimensionnez-la à partir de la classe de référence, pas de l'espoir. Dans un monde à queue épaisse, budgétez sur un percentile pessimiste des projets comparables (P80 ou plus), pas sur la médiane. Gardez la réserve visible, détenue par le sponsor, tenue au niveau du portefeuille quand c'est possible, et dépensée uniquement pour de vraies surprises.
7. **Planifiez le programme, pas seulement les équipes.** Un plan intégré unique qui montre les dépendances et les points d'intégration entre équipes, avec un responsable nommé pour chacun.
8. **Replanifiez à un rythme régulier.** Chaque trimestre, ré-estimez à partir de ce que l'équipe a réellement livré, et montrez la nouvelle prévision à côté de l'originale. Replanifier n'est pas un échec ; cacher l'écart, si.
9. **Définissez à l'avance les critères de succès et d'arrêt.** Décidez dès le départ à quoi ressemble le succès, et quels résultats justifieraient d'arrêter ou de remodeler le programme. Cela paie : le _Pulse of the Profession_ 2025 du PMI rapporte que les projets dont les critères de succès sont définis en amont, avec un système mature pour les mesurer, réussissent presque deux fois plus souvent que les autres. L'argent déjà dépensé ne fait pas partie de la décision.

## À éviter

- Annoncer une date avant que le plan n'existe.
- Négocier l'estimation à la baisse sans changer le périmètre.
- Figer en même temps le périmètre, la date et le budget.
- Commencer à construire avant que les questions les plus risquées n'aient de réponse.
- Planifier la partie la plus difficile en dernier.
- Une précision au jour près pour un travail situé à plus d'un trimestre.
- Budgéter sur la moyenne dans un monde à queue épaisse.
- Appeler l'indécision « agilité » pendant que date, budget et périmètre restent figés.
- Laisser l'argent déjà dépensé décider s'il faut en dépenser davantage.

## Le facteur IA

L'IA change les données d'entrée de chaque plan, mais personne ne sait encore dans quelle mesure.

Début 2025, le groupe de recherche METR a mené le test le plus rigoureux à ce jour : un essai randomisé avec 16 développeurs open source expérimentés travaillant sur 246 tâches réelles, dans des bases de code qu'ils connaissaient bien. Avec des outils d'IA, ils ont mis 19 % de temps en plus. Avant de commencer, ils avaient prédit que l'IA les rendrait 24 % plus rapides. C'est la vision de l'intérieur, mesurée.

Un an plus tard, le tableau avait bougé. L'étude de suivi de METR, avec 57 développeurs et plus de 800 tâches, pointait plutôt vers une accélération : environ 18 % pour les développeurs revenus de la première étude, avec un intervalle de confiance allant de 38 % plus rapide à 9 % plus lent. Et METR elle-même a qualifié ces nouvelles données de peu fiables, parce que trop de développeurs refusaient désormais de travailler sans IA pour le groupe témoin.

Si les personnes dont c'est le métier de mesurer cela n'arrivent pas à fixer le chiffre, votre plan ne devrait pas prétendre y parvenir.

Le code n'est d'ailleurs qu'une partie d'un programme. Le rapport DORA 2025 de Google, fondé sur près de 5 000 praticiens, a constaté une adoption de l'IA à 90 %. Sa conclusion centrale est que l'IA agit comme un amplificateur : elle grossit les forces comme les faiblesses d'une organisation, et la stabilité est devenue une vraie préoccupation à mesure que les équipes livrent plus vite. Pendant ce temps, les décisions, l'intégration, la migration des données et l'adoption avancent à la même vitesse qu'avant. Un plan qui suppose que tout va plus vite sera aussi faux qu'un plan qui suppose que rien ne change.

Il y a aussi une vraie opportunité. L'IA rend la vision de l'extérieur bien moins coûteuse. Elle peut aider à rassembler des programmes comparables, à analyser les estimations passées face au réel, et à simuler des fourchettes plutôt que des dates uniques. Et elle rend la « pensée lente » moins coûteuse : les prototypes et les spikes qui prenaient des semaines prennent maintenant des jours, il y a donc moins d'excuses pour commencer à construire avant que les inconnues ne soient résolues.

## Les plans servent à apprendre

Les meilleurs programmes sur lesquels j'ai travaillé n'avaient pas les plans les plus détaillés. Ils avaient les plus honnêtes : des fourchettes plutôt que des dates, le travail le plus risqué en premier, et un sponsor qui disait « merci » quand la prévision changeait, plutôt que « qui est responsable ? ».

Alors la prochaine fois qu'on vous remet un plan, posez une question en douceur : combien de temps des programmes similaires ont-ils réellement pris, et à quelle distance ce plan en est-il ? La réponse vous en dira plus que le diagramme de Gantt.

_Toutes les situations décrites ici sont des composites, tirés de nombreux programmes sur 25 ans._