Pourquoi est-il si difficile de donner un prix fixe pour un projet logiciel ? Parce qu'on chiffre de l'inconnu. Voici comment Scrum traite honnêtement cette question — et comment expliquer ça à un client.
Le chiffrage d'un projet logiciel est l'un des exercices les plus périlleux du secteur. On demande à des experts d'estimer la durée et le coût de quelque chose qu'ils n'ont jamais fait exactement de cette façon. La planning fallacy, documentée par Kahneman et Tversky, montre que les individus sous-estiment systématiquement la durée des tâches complexes — même en ayant vécu des expériences similaires passées.
Le cône d'incertitude
Barry Boehm a formalisé le cône d'incertitude : en début de projet, l'estimation peut varier de ±400%. À mi-parcours, ±25%. À la livraison, l'incertitude se réduit à zéro — parce que c'est terminé. Ce n'est pas de l'incompétence : c'est la nature du travail de conception. Promettre une estimation précise en début de projet, c'est prétendre que le cône n'existe pas.
Estimation relative et story points
Scrum répond à ce défi avec l'estimation relative. Plutôt que de dire « cette feature prendra 3 jours », on compare les features entre elles : « celle-ci est deux fois plus complexe que celle-là ». Les story points capturent cette relativité. Le Planning Poker force chaque développeur à voter indépendamment, révélant les désaccords qui cachent des incompréhensions ou des risques. La discussion qui suit est plus précieuse que le chiffre lui-même.
Fixed price vs Time & Material
Le contrat en prix fixe donne au client une certitude sur le budget mais transfère l'incertitude sur le périmètre et la qualité. Le contrat en Time & Material (régie) est plus honnête sur ce que l'on peut promettre, mais demande confiance et transparence. La meilleure approche : un budget d'appétit (Shape Up) — « voici ce qu'on peut faire avec ce budget en ce temps imparti » — qui laisse l'équipe optimiser la valeur livrée dans la contrainte.
Comment l'expliquer à un client
Un projet logiciel ressemble plus à l'écriture d'un livre qu'à la construction d'un mur. On ne sait pas combien de pages fera le livre avant de l'avoir écrit. La bonne question n'est pas « combien ça coûte ? » mais « quelle valeur peut-on livrer avec ce budget ? ». Scrum structure cette conversation sprint par sprint, avec des livrables réels à chaque itération.