Une estimation de projet web est une fourchette, parce qu’au moment où on la produit, une partie du projet n’est pas encore décidée : le périmètre exact, les règles de gestion, les écrans, les intégrations. Au stade de l’idée, l’écart entre hypothèse basse et hypothèse haute peut aller de 1 à 16. Cette fourchette ne se resserre pas avec le temps qui passe, mais avec les décisions que l’on prend. Réduire l’incertitude d’une estimation, c’est donc d’abord réduire l’incertitude du projet lui-même.
Ce guide explique d’où vient cette incertitude, comment les équipes sérieuses estiment, et ce que vous pouvez faire, côté client, pour obtenir une estimation fiable plus vite.
Pourquoi un chiffre unique est-il presque toujours faux ?
Une estimation est une prévision : la meilleure réponse possible à « combien de temps et d’efforts faudra-t-il ? » avec l’information disponible. Quand l’information est partielle, la réponse honnête comporte une marge d’erreur.
Prenons une demande simple en apparence : « une application pour gérer nos demandes d’intervention ». Selon les réponses à quelques questions, le projet change d’échelle :
- les techniciens travaillent-ils hors connexion ?
- faut-il planifier automatiquement les interventions ou simplement les lister ?
- les clients ont-ils un accès pour suivre leurs demandes ?
- la facturation doit-elle partir vers l’ERP ?
- combien de sites, de sociétés, de langues ?
Chaque question ouverte multiplie les versions possibles du projet. Un chiffre unique annoncé à ce stade correspond à l’une de ces versions, choisie implicitement par celui qui estime. C’est pourquoi deux prestataires peuvent annoncer des estimations très éloignées sans qu’aucun ne se trompe : ils n’estiment pas le même projet. Nous détaillons les facteurs qui font varier l’effort dans notre article sur le coût d’une application web sur mesure.
Le cône d’incertitude : de 1 à 16 au départ
Steve McConnell, spécialiste reconnu de l’estimation, a popularisé un modèle appelé cône d’incertitude. Dans son livre blanc publié par Construx, il représente l’erreur constatée dans des estimations produites par des estimateurs expérimentés, à chaque grande étape d’un projet.
| Étape du projet | Plage d’erreur (par rapport au réel) | Ce qui est décidé à ce stade |
|---|---|---|
| Idée initiale | de 0,25x à 4x | Une intention, un problème à résoudre |
| Vision du produit validée | de 0,5x à 2x | Les objectifs, les utilisateurs, ce que l’on ne fera pas |
| Besoins détaillés | de 0,67x à 1,5x | Les fonctionnalités, les règles de gestion, les priorités |
| Interfaces conçues | de 0,8x à 1,25x | Les écrans et les parcours, testés avec des utilisateurs |
Source : graphique du cône d’incertitude, Construx.
Trois enseignements du livre blanc sont essentiels pour un dirigeant :
- Le cône est le meilleur cas possible. Il représente la précision d’estimateurs compétents. On peut faire pire, pas mieux : McConnell écrit qu’on ne peut pas être plus précis, seulement plus chanceux.
- Il ne se resserre pas tout seul. Si les décisions ne sont pas prises, ou si le périmètre est rediscuté en permanence, l’incertitude ne forme pas un cône mais un « nuage » qui persiste jusqu’à la fin du projet.
- S’engager trop tôt est risqué. Un engagement pris au stade de l’idée ou de la vision comporte une erreur d’un facteur 2 à 4. Selon McConnell, des engagements fiables deviennent possibles vers 30 % du déroulement du projet, une fois le cône resserré.
Estimation, objectif, engagement : trois choses différentes
Beaucoup de tensions entre client et prestataire viennent d’une confusion entre trois notions.
- Une estimation est une prévision : « nous pensons que ce périmètre demande entre 14 et 20 semaines ».
- Un objectif est un souhait de l’entreprise : « nous voulons être en production pour le salon de mars ».
- Un engagement est une promesse : « nous livrerons ce périmètre à cette date ».
Une bonne discussion compare l’objectif à l’estimation, puis cherche l’engagement réaliste : réduire le périmètre de la première version, décaler la date, ou renforcer l’équipe quand c’est utile. La mauvaise discussion consiste à transformer l’objectif en estimation (« ça doit tenir en trois mois ») : le chiffre devient alors une contrainte déguisée, et le risque est reporté sur la qualité.
Martin Fowler rappelle, dans un court texte sur la finalité de l’estimation, qu’une estimation est utile quand elle éclaire une décision importante : lancer ou non un projet, arbitrer entre deux chantiers, coordonner des équipes. Avant de demander une estimation, demandez-vous quelle décision elle doit éclairer. La précision nécessaire en découle.
Comment les équipes sérieuses estiment-elles ?
Aucune méthode ne supprime l’incertitude, mais certaines la rendent visible et la réduisent.
La décomposition
On découpe le projet en éléments assez petits pour être compris (un écran, une règle de gestion, une intégration), on estime chacun, puis on additionne. La décomposition fait apparaître les oublis : c’est souvent en détaillant qu’on découvre la gestion des droits, les imports de données ou les notifications.
L’estimation à trois points
Pour chaque élément, on donne une valeur optimiste, une valeur probable et une valeur pessimiste. Cette méthode oblige à nommer les risques (« pessimiste si l’API de l’ERP n’est pas documentée ») et produit naturellement une fourchette argumentée.
L’estimation collective
Le planning poker, décrit par Mountain Goat Software, fait estimer chaque élément par plusieurs membres de l’équipe, qui révèlent leur estimation en même temps. Le choix privé limite l’effet d’ancrage, et l’écart entre les estimations la plus haute et la plus basse ouvre une discussion utile : l’un a vu un risque que l’autre a manqué.
La comparaison avec des projets similaires
Comparer le projet à des réalisations passées comparables (taille, intégrations, nombre de profils utilisateurs) corrige l’optimisme naturel de l’estimation détaillée. Un prestataire expérimenté doit pouvoir dire : « les trois derniers projets de ce type ont pris tant de temps, voici en quoi le vôtre diffère ».
Ce qui resserre la fourchette, et ce qui l’élargit
Le cône se resserre quand une question ouverte devient une décision écrite. Voici les leviers dont vous disposez, côté client.
| Levier | Effet sur l’estimation |
|---|---|
| Un cahier des charges qui décrit utilisateurs, processus et intégrations | Élimine les hypothèses implicites de chaque prestataire |
| Une phase de cadrage courte avec ateliers et backlog priorisé | Fait passer le projet de l’idée aux besoins détaillés |
| Un prototype interactif testé avec les utilisateurs | Réduit le risque de besoins mal compris avant d’écrire le code |
| Une preuve de concept sur l’intégration la plus risquée | Remplace une inconnue technique par un fait |
| Des priorités explicites (indispensable, important, souhaitable) | Permet d’ajuster le périmètre sans renégocier tout le projet |
À l’inverse, certains comportements élargissent la fourchette, ou empêchent le cône de se resserrer :
- changer d’interlocuteur métier en cours de projet, avec une vision différente ;
- repousser les décisions difficiles (« on verra pendant le développement ») ;
- ajouter des fonctionnalités sans en retirer ;
- découvrir tardivement une intégration ou une contrainte réglementaire.
Comment gérer l’incertitude qui reste ?
Même après un bon cadrage, une marge d’incertitude subsiste. Il existe deux façons saines de la gérer, souvent combinées.
Fixer le temps, ajuster le périmètre. C’est le principe des approches itératives : la durée et l’équipe sont fixées, et c’est le contenu qui s’ajuste. La méthode MoSCoW, documentée par l’Agile Business Consortium, recommande que les éléments indispensables ne dépassent généralement pas 60 % de l’effort prévu : les éléments souhaitables servent de réserve si les imprévus consomment du temps.
Livrer par lots et ré-estimer. Chaque lot livré fournit des données réelles sur la vitesse de l’équipe et la complexité du domaine. McConnell note qu’avec des itérations courtes, une équipe peut passer en quelques jours de la vision au besoin détaillé pour le contenu de l’itération, ce qui réduit fortement l’incertitude à cette échelle. C’est l’un des intérêts de livrer une version utilisable à chaque sprint.
Le choix du contrat suit la même logique. Un forfait global signé au stade de l’idée oblige le prestataire à couvrir une incertitude maximale ; un cadrage au forfait suivi de lots estimés au fur et à mesure partage le risque plus équitablement. Nous comparons ces formules dans notre article forfait, régie ou forfait par lots.
Les questions à poser sur une estimation reçue
Une estimation sérieuse s’accompagne de ses hypothèses. Avant de comparer des propositions, posez ces questions à chaque prestataire :
- Quelles hypothèses avez-vous retenues sur les points flous de notre demande ?
- Qu’avez-vous explicitement exclu du périmètre ?
- Quelle est votre fourchette, et qu’est-ce qui ferait basculer vers le haut ?
- Quels sont les deux ou trois risques principaux, et comment proposez-vous de les lever tôt ?
- À quel moment du projet pourrez-vous vous engager plus fermement ?
- Comment serons-nous informés si l’estimation dérive ?
Un prestataire qui répond précisément à ces questions vous donne plus de visibilité qu’un chiffre rond sans hypothèses. Pour situer votre propre projet dans le cône et savoir quelles décisions prendre en premier, décrivez-le dans notre diagnostic de projet : il prend deux minutes et vous indique les zones d’incertitude à lever avant de demander un chiffrage.
