Combien coûte une application métier ? Ce qui fait vraiment le prix
Vous recevez trois devis pour la même demande, et ils vont du simple au triple. Ce n'est pas que l'un est cher et l'autre honnête : c'est qu'ils ne chiffrent pas la même chose. Voici ce qui fait réellement le prix — et ce que vous pouvez y changer.
Sommaire
Trois devis, trois prix, et vous ne savez rien
Vous cherchez à faire développer un outil métier. Vous demandez trois devis pour la même demande.
Vous recevez trois montants qui vont du simple au triple.
Le réflexe est de conclure que l’un est cher et l’autre honnête. C’est presque toujours faux — et cette erreur de lecture est la plus coûteuse que vous puissiez commettre à ce stade.
La vérité est plus dérangeante : ils ne chiffrent pas la même chose. Le moins cher a supposé que vos données étaient propres, que vos process étaient stables et qu’il n’y aurait pas d’exceptions. Le plus cher a prévu la réalité.
Les deux sont sincères. Un seul a compris ce que vous demandiez.
Alors plutôt que de vous donner des fourchettes — que vous appliqueriez de travers, parce qu’elles ne connaissent pas votre contexte — je vais vous donner ce qui vous sera réellement utile : les huit facteurs qui font le prix, et ce que vous pouvez y changer.
Le prix se décide avant de chiffrer
Retenez ceci, parce que tout le reste en découle.
Le prix d’un projet n’est pas fixé par le prestataire. Il est fixé par le cadrage.
Deux prestataires également compétents, également honnêtes, à qui l’on présente le même besoin de la même façon, produiront des devis proches. Ce qui creuse l’écart, ce n’est pas leur marge — c’est ce qu’ils ont compris, et donc ce qu’ils ont prévu.
C’est pour cela que négocier un devis à la baisse ne fait presque jamais baisser le coût réel. Cela demande simplement au prestataire de sous-estimer. Vous paierez la différence plus tard, en avenants, en retards, et en mauvaise humeur des deux côtés.
Ce qui fait baisser un prix, c’est de réduire le périmètre. Pas de réduire le chiffre.
Voyons donc ce qui remplit ce périmètre.
1. Les intégrations avec l’existant
C’est le poste numéro un, et de très loin.
Brancher votre nouvelle application sur votre logiciel de comptabilité, votre outil de caisse ou votre ERP coûte souvent plus cher que l’application elle-même. Pas parce que c’est techniquement difficile, mais parce que ces systèmes sont anciens, mal documentés, et qu’on découvre leurs particularités en les branchant — jamais avant.
L’exemple qui résume tout :
Le devis le moins cher a supposé que l’intégration se ferait « par API ». Le devis le plus cher a appelé l’éditeur pour vérifier qu’il y en avait une.
Il n’y en avait pas. Le premier prestataire l’apprendra en cours de route, et il vous enverra un avenant.
2. Les cas particuliers de votre métier
« Sauf quand le client est en compte. » « Sauf le week-end. » « Sauf au-delà d’un certain montant, qui doit passer par la direction. » « Sauf pour les clients historiques, qui ont une remise négociée il y a dix ans que personne n’a jamais documentée. » « Sauf si le produit est en rupture, auquel cas on appelle le client. » « Sauf pour l’agence de Nantes, qui fonctionne autrement depuis toujours. »
Chacune de ces phrases est anodine en réunion. Chacune est une branche de code, un écran de plus, un test à écrire, et un cas à ne pas oublier six mois plus tard.
Ce sont elles qui font la différence entre une maquette et un outil qu’on utilise vraiment. Elles ne sont pas du gaspillage — elles sont votre métier, et c’est précisément pour cela qu’un logiciel du commerce ne vous convenait pas.
Mais elles doivent être dites avant le devis, pas découvertes à la recette.
3. Le nombre de rôles, et qui a le droit de voir quoi
Voici le facteur le plus sous-estimé, parce qu’il ne ressemble pas à une fonctionnalité.
Au début de l’atelier, il y a deux rôles : « l’administrateur » et « l’utilisateur ». À la fin, il y en a sept — et trois d’entre eux ont des exceptions.
Le commercial voit ses clients, mais pas ceux des autres. Sauf le directeur commercial, qui voit tout. Sauf sur les marges, que seule la direction consulte. Et le comptable, lui, voit les montants mais pas les noms.
Chaque règle de visibilité se multiplie avec les autres. Ce n’est pas une addition, c’est une combinatoire — et c’est la raison pour laquelle une application « avec juste quelques droits en plus » coûte beaucoup plus que prévu.
4. Les états, et surtout les exceptions
On chiffre toujours le chemin heureux : la commande arrive, elle est validée, elle part, elle est payée.
Le vrai coût est ailleurs. Il est dans ce qui sort du chemin.
Une commande annulée après expédition. Un paiement partiel. Un remboursement. Un litige. Un client qui change d’avis pendant le traitement. Un produit renvoyé abîmé. Une facture émise deux fois.
Ces cas sont rares — quelques pourcents. Mais ils représentent souvent la moitié du travail, parce qu’ils doivent tous être prévus, testés, et rattrapables. Un outil qui ne gère que le chemin heureux n’est pas un outil : c’est une démonstration.
5. La qualité des données de départ
Personne ne budgète ça, et c’est systématiquement le premier motif de dépassement.
Si vos données actuelles vivent dans un tableur, vous y trouverez : des doublons, trois orthographes pour le même client, des dates au format libre, des numéros de téléphone avec et sans espaces, et une colonne « commentaire » dans laquelle on a rangé, au fil des années, tout ce qui n’entrait nulle part ailleurs — et qui contient parfois l’information la plus importante.
Quelqu’un devra nettoyer tout ça. Ce quelqu’un sera facturé. Et le vrai problème n’est pas le coût : c’est qu’on ne le découvre qu’en cours de route.
6. La reprise de l’historique
Question qu’on ne pose jamais assez tôt : faut-il reprendre l’existant, et jusqu’où ?
Reprendre vingt ans d’historique depuis un logiciel qu’on ne peut plus ouvrir n’a rien à voir avec repartir d’une base vierge. Entre les deux, il existe une infinité de positions — reprendre les trois dernières années, reprendre seulement les clients actifs, ne reprendre que ce qui a une valeur légale.
Chacune a un prix très différent. Et cette décision, c’est vous qui devez la prendre : le prestataire ne peut pas deviner ce dont vous avez besoin dans cinq ans.
7. Le mobile, quand il n’est pas nécessaire
Une application installée sur téléphone coûte plus cher : deux plateformes, un processus de publication soumis à Apple et Google, des contraintes de fonctionnement hors ligne.
La vraie question est : vos utilisateurs sont-ils réellement en mobilité ?
S’ils sont sur un poste fixe, une tablette au comptoir ou un ordinateur d’atelier, une application web fait le travail, se met à jour instantanément, et vous évite d’attendre plusieurs jours la validation d’un magasin d’applications.
Le mobile se justifie quand il y a du terrain, du hors-ligne, ou du matériel embarqué. Pas parce que « tout le monde a un téléphone ».
8. L’absence d’arbitre de votre côté
C’est le facteur le plus coûteux, et le plus invisible — parce qu’il ne figure sur aucun devis.
Quand personne, chez vous, n’a le mandat de dire « non, cette fonctionnalité attendra », le périmètre grossit à chaque réunion. Chacun ajoute son besoin, tous sont légitimes, et le projet double sans qu’aucune décision n’ait jamais été prise.
Ce n’est pas le prestataire qui gonfle le projet. C’est l’absence de quelqu’un pour le tenir.
C’est précisément la fonction d’une direction technique — y compris quand elle n’est portée que quelques jours par mois.
Le même besoin, deux cadrages, deux projets
| Cadrage bâclé | Cadrage sérieux | |
|---|---|---|
| Les intégrations | « Il y a sûrement une API » | On a appelé l’éditeur |
| Les cas particuliers | Découverts à la recette | Listés avant le devis |
| Les rôles | « Deux ou trois » | Sept, avec leurs exceptions |
| Les exceptions du cycle de vie | Non chiffrées | Chiffrées, ou explicitement exclues |
| Les données | « Elles sont propres » | On a ouvert le tableur |
| L’historique | Question non posée | Décision prise et assumée |
| Le devis | Bas | Élevé |
| Le coût final | Le même — plus tard, et en avenants | Celui du devis |
Les deux dernières lignes sont l’article entier.
Ce qu’un bon devis contient
Un devis honnête ne se juge pas à son montant. Il se juge à ce qu’il ose écrire :
- ce qui est exclu du périmètre, nommément ;
- les hypothèses prises sur vos données et vos intégrations ;
- ce qui se passe si l’une de ces hypothèses est fausse ;
- ce qui reste à votre charge — les contenus, les accès, les décisions ;
- la propriété du code, explicitement, sujet que nous traitons dans notre article sur la propriété du code source.
Un devis sans aucune exclusion n’a pas été réfléchi. Il a été deviné.
Le seul conseil qui compte
Ne demandez pas « combien ça coûte ». Vous obtiendrez un chiffre, et il ne vous apprendra rien.
Demandez : « qu’est-ce qui pourrait faire doubler ce prix ? »
Un prestataire sérieux vous répondra en trois minutes, avec précision, en nommant deux ou trois risques concrets qu’il a identifiés chez vous. Cette réponse vaudra plus que les trois devis réunis.
Celui qui esquive vient de vous dire ce que vous vouliez savoir.
Nous construisons des outils métier internes, des plateformes B2B et des applications mobiles — et nous commençons toujours par vous dire ce qui, chez vous, fera monter la facture. Parlons-en.
Retrouvez nos articles en priorité dans vos résultats Google en nous ajoutant à vos sources préférées.
Ajouter aux sources préférées