Aller au contenu principal
Bonnes pratiques

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.

Photo de David Patiashvili David Patiashvili 12 min de lecture
Calculatrice posée sur des tableaux financiers, entourée de billets en euros — le devis d'un projet, avant qu'on ne sache ce qu'il contient.
Photo de Jakub Zerdzicki / Pexels
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 particuliersDécouverts à la recetteListés avant le devis
    Les rôles« Deux ou trois »Sept, avec leurs exceptions
    Les exceptions du cycle de vieNon chiffréesChiffrées, ou explicitement exclues
    Les données« Elles sont propres »On a ouvert le tableur
    L’historiqueQuestion non poséeDécision prise et assumée
    Le devisBasÉlevé
    Le coût finalLe même — plus tard, et en avenantsCelui 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.

    Partager

    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

    En savoir plus

    Nos prestations associées

    SaaS B2B

    SaaS B2B

    Plateforme métier vendue aux entreprises — multi-tenant, RBAC, SSO/SAML, audit logs, SLA cadrés.

    En savoir plus