BudgetMéthodeChoisir un prestataireForfait
Estimer un projet logiciel : comment un prestataire chiffre, et comment obtenir une estimation fiable
10 min de lecture
Pour estimer un projet logiciel, un prestataire découpe le besoin en fonctions, chiffre chacune à partir de projets comparables, ajoute ce que l'on oublie toujours (intégrations, reprise de données, tests, mise en production) puis applique une marge proportionnée à ce qui reste flou. Le résultat n'est fiable que si le besoin l'est : deux devis qui divergent du simple au triple chiffrent en réalité deux projets différents. La meilleure façon d'obtenir une estimation juste est donc de réduire le flou avant de demander un prix, pas de multiplier les devis.
Cet article se place de votre côté, celui du dirigeant qui doit valider un budget. Il explique comment l'estimation se fabrique chez le prestataire, pourquoi elle se trompe, et ce que vous pouvez faire pour qu'elle se trompe moins.
Estimation, devis, engagement : trois choses différentes
Le vocabulaire entretient la confusion. Trois objets distincts circulent pendant une consultation :
- l'estimation : une évaluation de l'effort et du coût, avec une marge d'incertitude. Elle n'engage personne ;
- le devis : une proposition commerciale chiffrée, sur un périmètre décrit, avec des conditions ;
- l'engagement : ce que le contrat garantit réellement. Au forfait, un prix pour un périmètre ; en régie, un nombre de jours facturés au temps passé.
Un chiffre lancé au premier rendez-vous est une estimation, même s'il est présenté comme un prix. Tant qu'il n'est pas adossé à un périmètre écrit, il ne vaut pas engagement. Notre comparatif forfait ou régie détaille ce que chaque formule fait porter à chacune des parties.
Comment un prestataire chiffre un projet
Derrière un devis, on retrouve presque toujours une combinaison des mêmes méthodes.
| Méthode | Principe | Quand elle sert | Sa limite |
|---|---|---|---|
| Analogie | Comparer à des projets déjà livrés | Très tôt, pour un ordre de grandeur | Dépend de projets vraiment comparables |
| Décomposition | Découper en fonctions, puis en tâches, et chiffrer chacune | Après un cadrage | Oublie ce qui n'est pas listé |
| Trois points | Chiffrer un cas optimiste, probable et pessimiste | Sur les tâches incertaines | Demande de l'honnêteté sur le pessimiste |
| Avis croisé | Plusieurs développeurs chiffrent séparément, puis comparent | Sur les fonctions complexes | Prend du temps d'équipe |
| Enveloppe | Fixer le budget, puis ajuster le périmètre | Quand le budget est la vraie contrainte | Le périmètre devient la variable |
La décomposition, au cœur du chiffrage
La méthode la plus courante consiste à lister ce que le logiciel doit faire, écran par écran et règle par règle, puis à estimer chaque élément en jours de travail. Un bon découpage ne s'arrête pas aux fonctions visibles :
- les fonctions : saisie, recherche, validation, calcul, export, notifications ;
- les droits : qui voit quoi, qui valide quoi, selon le profil ;
- les intégrations : ERP, comptabilité, messagerie, paiement, signature électronique ;
- la reprise des données : depuis un tableur, un ancien logiciel ou une base Access ;
- le non fonctionnel : sécurité, sauvegardes, performances, journaux, conformité RGPD ;
- la vie du projet : conception, recette, corrections, mise en production, documentation, formation.
Les deux derniers blocs sont ceux qui disparaissent le plus souvent d'une estimation rapide. Ce sont aussi ceux qui reviennent sous forme d'avenant.
La marge pour risque
Une estimation honnête n'additionne pas seulement des tâches. Elle ajoute une provision pour ce qui n'est pas encore connu, plus forte sur les zones floues : une intégration avec un logiciel dont l'API n'a pas été vue, une règle de calcul décrite en une phrase, une reprise de données jamais testée. Cette marge n'est pas un gonflement du prix. Un prestataire qui n'en prend aucune vous la fera payer plus tard, en avenants ou en qualité.
Pourquoi l'estimation se trompe au début
L'incertitude d'une estimation diminue à mesure que le projet se précise. Les ingénieurs logiciels la représentent par le « cône d'incertitude », popularisé par Steve McConnell dans Software Estimation (Microsoft Press, 2006) à partir des travaux de Barry Boehm (1981). Selon la présentation qu'en fait Construx, le cabinet de McConnell (consultée le 6 novembre 2026), une estimation faite au stade de l'idée peut se révéler jusqu'à quatre fois trop haute ou quatre fois trop basse, et l'écart se resserre à mesure que la définition du produit et les exigences sont arrêtées.
Deux nuances comptent. D'abord, ces bornes relèvent de l'expérience des auteurs plus que d'une mesure statistique : prenez-les comme un ordre de grandeur. Ensuite, le cône ne se resserre pas tout seul avec le temps. Il se resserre parce que des décisions sont prises : quels écrans, quelles règles, quelles intégrations, quelles exclusions. Un projet qui avance sans trancher reste en haut du cône, même après plusieurs mois.
La conséquence pratique est simple : une estimation précise au premier rendez-vous n'est pas un gage de sérieux. C'est souvent le contraire.
Ce qui fait vraiment varier le coût
Pour un même titre de projet (« un outil de suivi des interventions », « un portail client »), le coût peut varier fortement selon quelques facteurs que l'on sous-estime :
- Le nombre de règles métier et leurs exceptions. Un circuit de validation à deux niveaux se développe vite. Le même circuit avec délégations, seuils par montant et cas particuliers par client prend plusieurs fois plus de temps.
- Les intégrations. Chaque connexion à un outil existant dépend de la qualité de son API, de sa documentation et de l'accès à un environnement de test. Notre article sur l'intégration à un ERP existant détaille ces inconnues.
- La reprise de données. L'export est rarement le problème ; le nettoyage, les doublons et les champs détournés de leur usage le sont.
- Les profils et les droits. Trois profils ou douze, ce n'est pas le même logiciel.
- Les exigences de disponibilité et de sécurité. Un outil interne pour dix personnes et une plateforme ouverte à vos clients n'appellent pas le même niveau d'exigence.
- Le mobile et le hors ligne. Une saisie terrain sans réseau ajoute de la synchronisation, donc de la complexité.
Pour des ordres de grandeur par type d'application, consultez notre article sur le prix d'une application métier sur mesure.
Pourquoi les devis divergent
Quand vous recevez trois devis pour le même besoin, les écarts viennent presque toujours des mêmes causes.
| Cause de l'écart | Ce qui se passe | Comment le repérer |
|---|---|---|
| Hypothèses différentes | Chacun comble le flou à sa façon | Les hypothèses ne sont pas écrites, ou différent |
| Périmètre caché | Recette, mise en production ou reprise non comptées | Chercher ces lignes dans chaque devis |
| Nature du prix | Forfait engageant contre estimation en régie | Lire ce qui est garanti, pas le total |
| Marge pour risque | Absente chez l'un, explicite chez l'autre | Demander comment le risque a été provisionné |
| Niveau de qualité | Tests automatisés, revue de code, documentation | Demander ce qui est livré en plus du code |
| Après la livraison | Maintenance et hébergement inclus ou non | Comparer le coût sur plusieurs années |
Le devis le plus bas n'est donc pas forcément le moins cher, et le plus haut n'est pas forcément le plus prudent. Pour remettre plusieurs devis dans une même grille, suivez la méthode de notre article comparer des devis de développement d'application.
Ce que vous pouvez faire pour obtenir une estimation fiable
La qualité d'une estimation dépend d'abord de ce que vous fournissez. Voici ce qui fait le plus progresser la précision, par ordre d'efficacité.
Décrire le problème avant la solution
Expliquez ce qui se passe aujourd'hui : qui fait quoi, avec quels outils, combien de fois par semaine, où se perd le temps. Un prestataire chiffre mieux un processus réel qu'une liste de fonctionnalités imaginées en réunion.
Lister les règles et leurs exceptions
« Le responsable valide les commandes » ne suffit pas. Au-dessus de quel montant ? Que se passe-t-il en son absence ? Peut-on modifier une commande validée ? Chaque exception connue à l'avance est un avenant évité. Notre article sur le cahier des charges d'une application interne propose une trame complète.
Nommer les outils à connecter et fournir un échantillon de données
Le nom de l'ERP, sa version, l'existence d'une API, un export anonymisé des données à reprendre : ces éléments transforment une ligne « intégration » chiffrée au jugé en tâche estimable.
Séparer l'indispensable du souhaitable
Classez chaque fonction : indispensable au premier jour, utile plus tard, confort. Demandez une estimation par bloc. Vous pourrez ainsi arbitrer sans tout rechiffrer, et démarrer avec une première version plus courte.
Montrer plutôt que décrire
Un écran vaut un paragraphe. Une maquette, même grossière, ou mieux un prototype cliquable, fait apparaître les malentendus avant le chiffrage : un champ oublié, un écran inutile, un parcours que les utilisateurs ne suivront pas. C'est le moyen le plus rapide de descendre dans le cône d'incertitude. Notre article voir son logiciel avant de le payer explique ce qu'un prototype prouve, et ce qu'il ne prouve pas.
Indiquer votre budget
Beaucoup de dirigeants le cachent, de peur que le prestataire s'aligne dessus. C'est rarement un bon calcul : sans enveloppe, chacun imagine une solution différente, et les devis deviennent incomparables. Avec une enveloppe, le prestataire peut vous dire ce qui tient dedans, et ce qui n'y tient pas.
Lire une estimation reçue
Une estimation sérieuse contient au minimum :
- une fourchette, ou un prix ferme adossé à un périmètre précis ;
- les hypothèses retenues, écrites noir sur blanc ;
- les exclusions, tout aussi explicites ;
- le détail par bloc fonctionnel, pour pouvoir arbitrer ;
- les postes hors développement : conception, recette, mise en production, hébergement, maintenance ;
- ce qui ferait bouger le prix, et dans quel sens.
Posez systématiquement la question : « qu'est-ce qui ferait passer ce projet de la borne basse à la borne haute ? ». La réponse vous dit où sont les risques, et souvent quelles décisions prendre tout de suite pour les réduire.
Les erreurs les plus fréquentes côté client
- Exiger un prix ferme sur un besoin flou. Le prestataire se protège par une marge élevée ou par un périmètre restrictif, et vous payez l'un ou l'autre.
- Négocier l'estimation à la baisse sans toucher au périmètre. Le travail ne diminue pas ; seule la marge de sécurité disparaît.
- Oublier l'après. Un logiciel en production coûte chaque année en hébergement, maintenance et évolutions. Notre article sur la maintenance d'une application métier aide à le budgéter.
- Confondre estimation et délai. Un effort de vingt jours ne se livre pas en vingt jours calendaires : il faut compter vos validations, la recette et la disponibilité de vos équipes.
- Ne pas réestimer. Une estimation se met à jour à chaque décision importante. Celle du premier rendez-vous n'a plus de valeur après le cadrage.
Quand une estimation précise n'est pas le bon objectif
Pour certains projets, chercher un chiffre exact coûte plus cher que l'erreur qu'on veut éviter. C'est le cas d'un outil simple dont le périmètre tient en une page, ou d'un produit nouveau dont personne, vous compris, ne connaît encore les bonnes fonctions. Dans ces situations, deux approches sont plus saines :
- raisonner par enveloppe : fixer un budget et une date, puis construire la meilleure version possible dans ce cadre, en priorisant ;
- avancer par étapes courtes : une première version utile, mesurée auprès des utilisateurs, puis une estimation de la suivante à partir de ce qui a été appris.
Rien n'oblige non plus à tout payer d'avance : un développement peut se financer par un abonnement mensuel, ce qui déplace la question de l'estimation vers celle du service rendu chaque mois.
Par où commencer
- Écrivez une page sur le problème, les utilisateurs, les outils en place et votre enveloppe.
- Listez les règles et les exceptions que vous connaissez déjà.
- Préparez un échantillon de données et le nom des logiciels à connecter.
- Faites rendre le besoin visible avant de demander un prix ferme.
Pour cette dernière étape, nous construisons un prototype visuel gratuit, présenté en visio sous 5 jours ouvrés : vous voyez les écrans et les parcours avant tout chiffrage, et l'estimation qui suit porte sur ce que vous avez validé, pas sur une description.