Biais de planification : Pourquoi vos développeurs sont mauvais en estimation

Votre équipe technique promet deux semaines, vous attendez un mois. Ce n'est ni une fatalité ni de l'incompétence. C'est le planning fallacy, un biais cognitif universel. Voici comment le comprendre et l'atténuer dans vos projets tech.

Le planning parfait n'existe pas

Je me souviens de ma première expérience en startup. Notre CTO avait pris l'habitude de multiplier par deux les délais, pas par manque de confiance, par expérience. Malgré cette précaution, nous dépassions régulièrement les échéances.

Ce phénomène dépasse la tech. Le Sydney Opera House devait coûter 7 millions de dollars, il en a coûté 102 millions. Des grands projets d'infrastructure aux développements logiciels modestes, tout le monde sous-estime le temps nécessaire.

Le planning fallacy n'est pas un problème de compétence. Des développeurs seniors y succombent autant que les juniors. C'est un biais cognitif identifié par Daniel Kahneman et Amos Tversky dans les années 1970.

Comment fonctionne ce biais

Le planning fallacy repose sur notre incapacité à prendre en compte notre propre expérience passée quand nous planifions l'avenir. On se focalise sur le scénario idéal.

Demandez à un développeur d'estimer une fonctionnalité. Il va considérer la tâche dans sa forme la plus simple : écrire le code, le tester, le déployer. Il néglige les bugs imprévus, les réunions qui s'éternisent, la documentation manquante, les dépendances externes qui échouent, ou les jours moins productifs.

D'autres biais renforcent cette tendance. L'optimisme nous pousse à croire que nous éviterons les problèmes que d'autres ont rencontrés. L'effet Dunning-Kruger peut amener les moins expérimentés à surestimer leurs capacités. Et le désir de plaire nous incite à annoncer des délais irréalistes.

Pourquoi le dev logiciel est particulièrement touché

Le planning fallacy est universel, mais le développement logiciel l'amplifie.

La complexité du code d'abord. Une fonctionnalité simple peut cacher des interactions complexes avec le reste du système. Même en le sachant, estimer le temps nécessaire reste difficile.

L'incertitude technique ensuite. Le développement logiciel implique souvent d'explorer des territoires inconnus. Comment estimer le temps de résolution d'un problème jamais rencontré ?

La dette technique aussi. Un code mal structuré ou peu documenté ralentit le développement, mais cette dette est souvent invisible lors de l'estimation initiale.

La pression des délais enfin. En startup, les développeurs se sentent obligés de donner des estimations optimistes. Cette pression renforce le cycle des mauvaises estimations.

Comment atténuer ce biais

Quelques approches qui ont fonctionné dans mon expérience.

L'estimation par analogie historique : se baser sur des expériences passées similaires plutôt que sur une analyse théorique. Si votre équipe a mis trois semaines pour une fonctionnalité comparable, c'est un meilleur point de départ que l'analyse théorique qui suggère deux semaines.

La décomposition en petites tâches. Notre cerveau estime mieux de petites tâches concrètes que des projets abstraits.

Les marges de sécurité ciblées. Plutôt qu'un pourcentage arbitraire, identifiez les risques potentiels et allouez du temps en conséquence.

La méthode PERT (Program Evaluation and Review Technique) : une estimation pondérée basée sur trois scénarios (optimiste, probable, pessimiste). Elle oblige l'équipe à envisager ce qui pourrait mal tourner.

Une culture d'équipe qui valorise l'honnêteté plutôt que l'optimisme. Les développeurs doivent pouvoir donner des estimations réalistes sans craindre d'être perçus comme lents.

Les méthodologies agiles comme Scrum. En travaillant par sprints courts et en mesurant la vélocité de l'équipe, vous accumulez des données concrètes qui affinent vos prévisions.

Ce qu'il faut retenir

• Le planning fallacy est un biais cognitif identifié par Kahneman et Tversky, pas un problème de compétence. Les développeurs seniors y succombent autant que les juniors.
• Le développement logiciel amplifie ce biais : complexité cachée du code, incertitude technique, dette technique invisible et pression des délais faussent les estimations.
• Les approches qui fonctionnent : estimation par analogie historique, décomposition en petites tâches, buffers ciblés, méthode PERT, et une culture d'équipe qui valorise l'honnêteté.

Questions fréquentes

Pourquoi multiplier les estimations par deux ne suffit-il pas ?

Parce que le facteur de sous-estimation varie selon la complexité et le contexte. Un multiplicateur arbitraire ne prend pas en compte les risques spécifiques de chaque tâche. Préférez identifier les risques concrets et allouer du temps en conséquence avec des approches comme la méthode PERT.

Comment améliorer la précision des estimations au fil du temps ?

Mesurez systématiquement la vélocité de votre équipe par sprint (méthodologie Scrum). Ces données concrètes permettent d'affiner progressivement vos prévisions. Comparez aussi régulièrement les estimations aux temps réels pour identifier vos biais récurrents.

Le planning fallacy est-il pire chez les juniors que chez les seniors ?

Non, c'est un biais universel. Les juniors peuvent surestimer leurs capacités (effet Dunning-Kruger), mais les seniors sont tout aussi vulnérables à l'optimisme et à la focalisation sur le scénario idéal. La différence est que les seniors disposent de plus d'analogies historiques pour calibrer leurs estimations.

Conclusion

La lutte contre le planning fallacy est une question de culture plus que de technique. Il s'agit d'accepter l'incertitude du développement logiciel et de créer un environnement où la transparence compte plus que l'optimisme.

Un planning réaliste, même avec des délais plus longs, permet une meilleure allocation des ressources et une livraison plus fiable. Un planning optimiste mais irréaliste produit du stress et de la déception.

En tant que fondateur, votre rôle n'est pas de pousser votre équipe à promettre l'impossible, mais de l'aider à évaluer ses capacités avec lucidité. La prochaine fois qu'un planning semble trop beau pour être vrai, engagez une conversation sur les risques, les expériences passées et les marges nécessaires.