129 heures contre 49 : anatomie d'une erreur de chiffrage
Dans nos archives, il y a une landing page saisonnière. Le devis facturé s'élevait à 49 heures. En réalité, le projet en a consommé 129. Le projet a été livré, le client était satisfait, le paiement a été encaissé — et c'est le seul cas où je connais les deux chiffres avec certitude, parce que les deux ont été conservés dans nos documents.
Cet écart de 2,6 fois n'est ni un record ni une exception. Dans une étude de terrain portant sur 52 projets, un dépassement de la charge de travail a été observé dans 76 % des cas, avec un dépassement moyen de 41 %. La question à se poser lors de l'estimation de la charge d'un projet n'est pas « combien d'heures », mais « à quel moment et sur quelle base ce chiffre a-t-il été annoncé ».
Une estimation ne se trompe pas parce que quelqu'un compte mal les heures. Elle se trompe parce qu'elle est annoncée avant que le périmètre ne soit fixé, et qu'ensuite le premier chiffre énoncé fait office d'ancre pour tous les recalculs suivants. Le remède n'est pas la précision du calcul, mais le déplacement du chiffrage vers une étape distincte du processus — après la description du périmètre et avant la signature.
Où sont passées les 80 heures imprévues
La réponse « nous avons sous-estimé la complexité » n'explique rien et ne corrige rien. Ce qui est utile, c'est de décomposer l'écart en événements, chacun pouvant être nommé et daté. Dans ce projet, il y en a eu cinq, et aucun ne ressemblait à un problème au moment où il est survenu.
L'estimation a été annoncée avant la description du périmètre. Le chiffre est sorti dès le premier appel, en réponse à la question « ça coûte à peu près combien ». Ce chiffre approximatif devait simplement donner au client un ordre de grandeur — il est devenu le chiffre de l'accord. Entre « à peu près » et « validé », il n'y a eu aucun document.
Chaque ajustement arrivait au compte-gouttes. Ajouter un bloc avec le programme. Afficher les prix dans deux devises. Créer une version distincte pour l'envoi en newsletter. Pris isolément, chaque ajustement représente une demi-heure ou une heure, et refuser paraît mesquin. C'est la somme de ces demi-heures qui a constitué l'essentiel de l'écart.
La validation était considérée comme gratuite. L'estimation intégrait le travail du designer et de l'intégrateur. N'y figuraient pas : les échanges par écrit, trois séries de corrections du texte, l'attente des éléments, un nouveau montage après que le client a montré la maquette à un collègue. Ce sont des heures de chef de projet et des heures d'exécution, et elles existent, qu'on les ait comptées ou non.
La saisonnalité a mangé la marge. Le projet était lié au Nouvel An, la date de lancement ne pouvait pas bouger. Quand le travail prend du retard et que la date est fixe, la seule ressource disponible, ce sont les heures des équipes le soir et le week-end. La marge qui, dans un projet ordinaire, se traduit par un report de délai, se traduisait ici directement en heures de travail.
Personne ne recalculait en cours de route. Le signal de dépassement est apparu à peu près à mi-parcours — et ne s'est pas transformé en discussion. Parler d'argent quand le travail est fait à moitié est toujours plus inconfortable qu'au début, alors on repousse la conversation jusqu'à la fin, où elle n'a plus de sens.
| Événement | Ce qui se perd | Qui le remarque |
|---|---|---|
| L'estimation est annoncée avant la description du périmètre | Le droit de revoir le chiffre sans perdre la face | Personne — le chiffre passe pour une aubaine |
| Les ajustements arrivent un par un | Des heures de travail, une heure à la fois | L'exécutant — qui se tait |
| La validation n'entre pas dans l'estimation | Tout le temps du chef de projet | Personne — ces heures ne sont enregistrées nulle part |
| Une date fixe sans marge | Les soirées et les week-ends de l'équipe | L'équipe — sous forme de fatigue, pas de chiffre |
| Aucun recalcul à mi-parcours | La possibilité de s'entendre | Le dirigeant — à la fin du mois |
Observez la troisième colonne. Trois événements sur cinq ne sont vus par personne dans l'entreprise : ils n'ont ni rapport, ni responsable, ni moment prévu pour émerger. C'est précisément pour cela qu'ils se reproduisent.
Pourquoi le premier chiffre annoncé détermine tous les suivants
L'écart de chiffrage n'est pas une caractéristique propre à une équipe donnée. C'est une régularité robuste, reproduite dans des échantillons et des pays différents. Et elle repose sur un mécanisme qui a été décrit séparément.
Dans une étude portant sur des projets logiciels réels, un dépassement de la charge de travail a été observé dans 76 % des cas, avec un dépassement moyen de 41 %. En synthétisant des revues internationales antérieures, l'auteur indique une fourchette type de sous-estimation de 30–40 %.
Il faut nommer soi-même la limite de ces données : l'échantillon est norvégien, vieux de vingt ans, et les heures réelles ont été recueillies auprès des chefs de projet, pas d'un système de suivi du temps. La valeur ne tient pas à la précision du pourcentage, mais à la robustesse du constat lui-même — le dépassement s'avère être la norme, pas l'exception.
C'est là que ça devient intéressant. Une revue de travaux empiriques sur le chiffrage par des experts montre que le problème n'est pas arithmétique, mais tient à l'ordre d'apparition des chiffres.
Les estimations d'experts de la charge de travail se déplacent systématiquement vers le premier chiffre énoncé — l'« ancre ». Une évaluation grossière et précoce, faite avec un minimum d'informations, continue d'influencer les recalculs ultérieurs, même une fois les exigences précisées.
C'est un travail de synthèse, qui rassemble des expériences menées par d'autres, en partie en laboratoire — il ne fournit pas de proportion exacte des cas où l'ancrage opère. Mais la conclusion qualitative explique notre cas mieux que n'importe quel chiffre : « environ 49 » lors du premier appel n'était pas une estimation. C'était une ancre, vers laquelle tous les calculs suivants ont ensuite été tirés, y compris ceux effectués une fois le périmètre pleinement compris.
Ce qui a changé après ce projet
La conclusion que nous en avons tirée ne portait pas sur la méthode de calcul, mais sur l'architecture du processus. Le chiffrage a cessé d'être une réplique au fil d'une conversation pour devenir une étape distincte, avec sa propre entrée et sa propre sortie. L'ordre est devenu le suivant : demande, clarification du besoin, cahier des charges, estimation de la charge, validation, exécution, livraison, trois jours de délai de recette.
Deux points sont fondamentaux dans cet ordre. Le premier : l'estimation vient après le cahier des charges, pas avant — on ne peut chiffrer que ce qui est décrit. Le second : entre l'estimation et l'exécution se trouve une validation, c'est-à-dire un point explicite où les deux parties voient le même chiffre et le confirment.
La seconde partie de la solution est financière. Dans la maintenance sont apparus des forfaits de maintenance à périmètre explicitement défini, avec un tarif distinct pour les heures au-delà. Pas parce que c'est plus rentable, mais parce que ce dispositif fait que la discussion sur les heures supplémentaires suit une règle, et non l'humeur du moment.
Quelle est l'ampleur habituelle de l'écart
L'essentiel reste en dehors de cette comparaison : les moyennes trompent. La distribution des dépassements est asymétrique — l'essentiel du risque ne se situe pas au centre, mais dans la queue de distribution, et c'est précisément pour cela que planifier sur la moyenne ne protège pas.
Sur un échantillon de 1 471 projets informatiques, le dépassement budgétaire moyen s'est élevé à 27 %. Un projet sur six s'est en outre révélé être un « cygne noir » : dépassement budgétaire moyen de 200 % et dépassement des délais de près de 70 %.
La limite ici est importante : ce sont de grandes initiatives d'entreprise et publiques, pas une landing page saisonnière. Ce qui se transpose, ce n'est pas l'échelle, mais la forme de la distribution. Un projet sur six dérape complètement, et il est payé par la marge des cinq autres.
Ce qui a changé en 2026 et ce qui n'a pas changé
Ce qui a changé, c'est qu'une partie du travail s'est réellement accélérée. Un prototype, un brouillon de texte, l'analyse des exigences, une première version de schéma — tout cela se fait aujourd'hui nettement plus vite, et la tentation de réduire l'estimation pour cette raison est forte. Ce qui n'a pas changé, c'est l'origine de l'écart : il vient du périmètre, pas de la vitesse d'exécution.
52 % des projets achevés au cours des 12 mois précédents ont connu une dérive du périmètre incontrôlée. Cinq ans plus tôt, ce taux était de 43 %.
Le rapport repose sur les déclarations des praticiens eux-mêmes et a été publié par une association professionnelle qui a intérêt à promouvoir ses propres standards — il faut le garder à l'esprit. Mais la direction de l'évolution est révélatrice : la part des projets touchés par la dérive du périmètre augmente, elle ne diminue pas, malgré deux décennies de développement méthodologique.
La conclusion pratique est simple. Si un outil a doublé la vitesse d'exécution, mais que le périmètre continue d'être précisé au coup par coup et en silence, l'écart entre l'estimation et le réel persistera — il s'exprimera simplement dans d'autres unités.
Quatre règles qui suppriment l'essentiel de l'écart
Ne pas annoncer de chiffre avant la description du périmètre
À la question « ça coûte à peu près combien », il n'existe qu'une seule réponse sûre : une fourchette d'ordre de grandeur et un délai pour l'annonce du chiffrage. Tout le reste deviendra une ancre.
Chiffrer plus que la seule production
La validation, l'attente des éléments, les séries de corrections et le remontage sont des heures. Si elles ne figurent pas dans l'estimation, elles existent quand même dans le réel.
Écrire ce qui n'est pas inclus
La liste des exclusions est plus courte que la liste des travaux, et elle fonctionne mieux. C'est elle qui transforme un ajustement en une discussion à part, et non en un ajout gratuit.
Recalculer à mi-parcours
Fixez un point où le réel est comparé à l'estimation, et rendez-le obligatoire. Une conversation inconfortable à mi-parcours coûte moins cher qu'une perte silencieuse constatée à la fin.
Si une estimation apparaît dans les échanges avant que le périmètre ne soit décrit, vous ne chiffrez plus le projet — vous négociez autour d'un chiffre annoncé par hasard.
Les questions les plus fréquentes
Comment estimer correctement la charge d'un projet quand les exigences ne sont pas encore prêtes ?
On ne peut pas — et c'est une réponse honnête. Tant que le périmètre n'est pas décrit, ce n'est pas le projet qu'on estime, mais une étape : le temps que prendront l'analyse des exigences et la rédaction du cahier des charges. Cette étape peut être chiffrée avec précision, car son contenu est connu. L'estimation du projet dans son ensemble est donnée après, et le client reçoit non pas un chiffre au départ, mais deux, à des moments connus d'avance.
Que faire si le client exige un chiffre immédiatement ?
Donner une fourchette d'ordre de grandeur et annoncer le délai auquel l'estimation sera fournie. La fourchette doit être suffisamment large pour ne pas devenir une ancre : « entre deux et six semaines, précision après le cahier des charges ». Une fourchette étroite, annoncée par désir de paraître sûr de soi, fonctionne comme un chiffre exact et crée le même problème.
Quelle provision pour aléas prévoir dans l'estimation ?
Une provision en pourcentage ne règle pas le problème, car l'écart naît d'un changement de périmètre, pas d'une imprécision de calcul. Ce qui fonctionne, c'est autre chose : une ligne budgétaire distincte pour les exigences qui apparaîtront après la première présentation du résultat, avec un responsable et une règle d'utilisation propres. En l'absence d'une telle ligne, ces exigences seront de toute façon satisfaites — aux frais du prestataire.
L'écart de 129 contre 49 est-il représentatif ?
C'est un projet d'une seule entreprise, pas une référence sectorielle. Ce qui est révélateur, ce n'est pas le ratio, mais le fait que les deux chiffres aient été conservés : les heures réelles ont été enregistrées, pas reconstituées de mémoire. Dans la plupart des entreprises, une telle comparaison est tout simplement impossible, parce que la charge de travail réelle n'est consignée nulle part.
Les chiffres « 129 heures réelles » et « 49 heures facturées » proviennent du devis interne du projet de landing page saisonnière, dans les archives d'Alego.Digital. L'ordre des étapes (demande → clarification → cahier des charges → estimation de la charge → validation → exécution → livraison → trois jours de recette) et le modèle de forfait avec un tarif distinct pour les heures supplémentaires proviennent du règlement de relation client de la même période. Ce sont des documents internes de l'entreprise de l'auteur ; ils n'ont pas été vérifiés par un tiers indépendant et sont présentés comme une illustration du mécanisme, pas comme une référence sectorielle. La liste des cinq événements sur lesquels l'écart est décomposé a été reconstituée à partir des documents du projet et des échanges.
- Moløkken-Østvold K. J. Effort and Schedule Estimation of Software Development Projects. Université d'Oslo, thèse de doctorat, août 2004. simula.no
- Jørgensen M. A Review of Studies on Expert Estimation of Software Development Effort. Journal of Systems and Software, 2004. simula.no
- Flyvbjerg B., Budzier A. Why Your IT Project May Be Riskier Than You Think. Harvard Business Review, septembre 2011. hbr.org
- Project Management Institute. Pulse of the Profession 2018 (enquête auprès de 5 402 répondants). pmi.org