Le paradoxe de l’estimation en gestion de projet
L’estimation est l’une des compétences les plus enseignées en gestion de projet. Le PMBOK y consacre plusieurs processus, HERMES l’intègre dans chaque phase, PRINCE2 en fait un pilier de ses business cases. Pourtant, les estimations de projet restent notoirement peu fiables. Ron Jeffries, co-fondateur d’Extreme Programming (XP, une méthodologie agile pionnière centrée sur les pratiques d’ingénierie), va jusqu’à qualifier l’estimation de “mal nécessaire devenu simplement un mal”. Sa critique, formulée dès 2013, mérite d’être examinée: non pour abandonner toute prévision, mais pour comprendre pourquoi tant d’estimations échouent.
Des exigences trop floues pour être chiffrées
Le premier problème est structurel. Pour estimer avec précision, il faut comprendre ce qu’on estime. Or les exigences projet sont, au démarrage, rarement complètes. Un chef de projet reçoit un cahier des charges qui décrit une intention plus qu’une spécification. Les zones d’ombre sont nombreuses, les hypothèses implicites, les dépendances mal cartographiées.
Dans ce contexte, produire un chiffre crée une illusion de certitude. Une estimation de “six mois” sonne comme un engagement alors qu’elle repose sur des dizaines d’hypothèses non vérifiées. Jeffries observe que le travail véritablement nouveau ne peut pas être prédit avec précision, car il n’existe pas de base historique comparable.
La négociation qui n’en est pas une
Le deuxième problème est organisationnel. Jeffries décrit un pattern récurrent sur ses cinquante années de carrière: la “négociation” des estimations depuis une position d’autorité. Un responsable demande une estimation, la reçoit, puis la conteste. “On est tous dans le même bateau”, “il faut trouver une solution”, “et si on réduisait le scope un peu?” sont autant de formulations qui masquent une pression à la baisse.
Le résultat est prévisible. Une fourchette “entre juin et octobre” devient “juin” dans l’esprit du décideur. Quand la réalité se manifeste en septembre, l’équipe est accusée d’avoir manqué à sa promesse, une promesse qu’elle n’a jamais formulée. Ce mécanisme ne relève pas de la mauvaise foi individuelle: c’est un dysfonctionnement systémique où chaque acteur joue son rôle dans une fiction collective.
L’estimation comme instrument de pression
Jeffries identifie un abus plus insidieux: l’utilisation des estimations pour accélérer les équipes. Le raisonnement implicite est simple, si l’équipe estime un travail à dix jours, lui en accorder huit la poussera à être plus efficace. Cette logique ignore une réalité bien documentée: sous pression temporelle, les équipes ne travaillent pas plus vite, elles coupent les coins. La dette technique s’accumule, les tests sont réduits, la qualité se dégrade. Le projet “tient ses délais” mais livre un produit fragile dont la maintenance coûtera bien plus que les deux jours économisés.
Ce que le management cherche vraiment
Si les estimations posent tant de problèmes, pourquoi y tient-on autant? Parce qu’elles répondent, en apparence, à des questions légitimes: le projet avance-t-il, les délais seront-ils tenus, faut-il intervenir?
Jeffries observe que les estimations ne répondent directement à aucune de ces questions. Un écart entre estimation et réalité ne dit rien sur la santé du projet si les exigences ont évolué entre-temps. Un projet “dans les temps” selon le plan initial peut être en difficulté si le scope (périmètre) a changé sans que le calendrier ne s’ajuste.
Des alternatives existent. La visualisation de l’avancement par les données réelles, qu’il s’agisse du nombre d’items livrés, de la tendance du cycle time ou d’un burndown chart basé sur les livraisons effectives, offre une image plus fidèle que la comparaison entre prévision et réalité.
Découper plutôt qu’estimer
La proposition la plus concrète de Jeffries concerne le découpage du travail. Quand les tâches sont décomposées en incréments de taille homogène, compter les items complétés devient plus informatif qu’estimer les items restants. Cette approche présente un avantage secondaire important: chaque découpage force une clarification des exigences et révèle souvent des éléments reportables sans compromettre l’essentiel.
Le principe rejoint une pratique bien établie en gestion de projet classique: la WBS (Work Breakdown Structure, décomposition structurée du travail). La différence réside dans la granularité visée. Là où une WBS traditionnelle peut s’arrêter à des lots de travail de plusieurs semaines, le découpage agile vise des incréments de quelques heures à quelques jours, ce qui réduit mécaniquement l’incertitude de chaque estimation individuelle.
Faut-il cesser d’estimer?
La réponse honnête est non, pas entièrement. Les décisions d’investissement nécessitent des ordres de grandeur: un sponsor doit savoir si un projet coûtera cent mille ou un million d’euros avant de l’approuver. Le mouvement #NoEstimates ne nie pas ce besoin; il conteste l’obsession de la précision là où elle n’est ni atteignable ni utile.
La vraie question n’est pas “faut-il estimer?” mais “à quel moment l’effort d’estimation dépasse-t-il la valeur de l’information produite?”. Un chef de projet qui consacre trois jours à affiner un planning dont les hypothèses changeront dans deux semaines investit mal son temps. Un autre qui refuse toute prévision et laisse ses parties prenantes sans visibilité ne sert pas mieux son projet.
L’estimation reste un outil. Comme tout outil, sa valeur dépend de l’usage qu’on en fait, pas de l’outil lui-même.