← Tous les articles coût et périmètre

Combien coûte une application métier, sans fourchette

Par Ayoub El Amri · 6 septembre 2026

Vous cherchez un prix. Cette page n'en donne pas, et c'est délibéré. Voici ce qu'elle donne à la place : la liste des variables qui font réellement le montant, dans un ordre qui vous permet de calculer votre propre borne en une heure, avec n'importe quel prestataire.

Toutes les fourchettes que vous avez lues sont exactes. C'est bien le problème. « Entre 3 000 et 150 000 euros » décrit honnêtement un marché où deux projets qui portent le même nom peuvent différer d'un facteur cinquante. Le chiffre ne vous dit rien parce que le prix n'est pas une propriété du logiciel. C'est une propriété du périmètre. Tant que le périmètre n'est pas écrit, aucun montant n'a de sens, et celui qui vous en annonce un avant de l'avoir écrit vous annonce un chiffre qu'il révisera.

Ce qui fait vraiment varier le montant

Six variables. Vous pouvez les évaluer vous-même, aujourd'hui, sans faire venir personne.

1. Le nombre d'écrans qui portent une décision

Pas le nombre d'écrans. Le nombre d'écrans où quelqu'un tranche quelque chose.

Une liste qui affiche des dossiers coûte peu. Un écran où un responsable valide, refuse ou renvoie en correction coûte beaucoup plus : il faut des états, des transitions, des droits, une trace de qui a décidé quoi, et le comportement de chaque cas limite.

Comptez vos points de décision, pas vos pages.

2. Le nombre de règles conditionnelles

C'est la variable la plus sous-estimée, et de loin.

« Si le dossier vient d'un client historique et que le montant dépasse un seuil, la validation remonte au dirigeant, sauf en période de congés. » Cette phrase, dite en dix secondes en réunion, se paie en développement, en tests et en maintenance à chaque évolution.

Un logiciel ne coûte pas cher parce qu'il a beaucoup d'écrans. Il coûte cher parce qu'il a beaucoup d'exceptions.

Un exemple concret, tiré d'un produit que nous avons construit. Dans Zestelio, notre logiciel pour artisans pâtissiers, le coût de revient d'une pièce se calcule à travers des sous-recettes imbriquées : une crème entre dans un entremets, qui entre lui-même dans une pièce montée. Le calcul doit donc descendre récursivement, et le coût doit se figer au moment de la commande, sinon une hausse du prix du beurre réécrirait rétroactivement la marge de commandes déjà facturées.

Vu de loin, c'est « calculer un coût ». Vu de près, ce sont deux règles qui changent la nature du travail. Aucune fourchette ne peut anticiper ça, et c'est exactement pour cette raison que les fourchettes sont fausses par construction.

3. Les rôles et les droits

Un outil pour trois personnes qui voient tout est simple. Un outil où le commercial voit ses dossiers, le responsable voit ceux de son équipe et l'assistante voit tout sauf les montants coûte nettement plus.

La question à se poser n'est pas « combien d'utilisateurs », c'est combien de vues différentes de la même donnée.

4. Les connexions avec vos outils existants

C'est le multiplicateur.

Une application isolée est bornée. Dès qu'elle doit lire ou écrire dans un logiciel de comptabilité, un progiciel métier, une boîte mail ou un agenda, le coût dépend d'une chose que ni vous ni le prestataire ne contrôlez : la qualité de l'interface de l'autre logiciel. Certains offrent une interface documentée et stable. D'autres n'en ont aucune, et il faut alors passer par des exports, avec toutes les fragilités que ça implique.

Avant de demander un devis, listez les logiciels avec lesquels l'outil devra parler, et cherchez pour chacun si une interface publique existe. Cette liste déplace le montant plus que toutes les autres réunies.

5. La reprise de vos données existantes

Tout le monde l'oublie au chiffrage, et personne ne l'oublie à la livraison.

Reprendre l'historique n'est jamais un import. C'est un travail de nettoyage, de rapprochement et d'arbitrage sur ce qui est irrécupérable.

Nous l'avons mesuré sur notre propre chaîne d'acquisition. En cherchant des établissements dans une base cartographique ouverte, nous avons trouvé 1 330 fiches. Après filtrage sur le seul critère qui nous servait, la présence d'un numéro de téléphone, il en restait 490. Puis 41 ont été écartées parce qu'elles portaient un signal disqualifiant. Le volume brut annonçait un travail ; le volume exploitable en annonçait un autre, trois fois moindre.

Pire, dans un cas antérieur : une base de 1 707 fiches entièrement constituée, propre, structurée, et finalement inutilisable, parce qu'il manquait le seul champ qui comptait pour l'usage prévu. Le travail avait été fait. Il n'a servi à rien.

Demandez toujours à voir un échantillon réel de vos données avant de chiffrer leur reprise. Un prestataire qui accepte de la chiffrer sans les avoir regardées chiffre au hasard.

6. Qui répond aux questions, chez vous

Le coût caché, et le seul que le prestataire ne peut pas absorber.

Un développement avance au rythme des réponses. Si la personne qui connaît la règle est en clientèle toute la semaine, chaque question attend, et un projet qui tiendrait en quelques semaines s'étale sur plusieurs mois. Le prestataire facture rarement cette attente, mais elle vous coûte : elle retarde le moment où l'outil vous fait gagner du temps.

Avant de commencer, nommez une personne et un créneau. C'est gratuit, et c'est ce qui change le plus le déroulement réel.

Les quatre lignes que les devis ne montrent presque jamais

Elles arrivent toutes après la signature.

La recette. Quelqu'un doit essayer l'outil avec de vraies données et de vrais cas tordus, puis écrire ce qui ne va pas. Si ce n'est pas prévu, ce sont vos équipes qui le découvriront en production.

La mise en service. Le passage de l'ancien fonctionnement au nouveau, la journée où les deux coexistent, la reprise du travail en cours. C'est court, et ça ne se fait pas tout seul.

La maintenance. Un logiciel qui tourne demande de l'entretien même si personne ne demande de nouvelle fonction. Les briques sur lesquelles il repose évoluent, les services connectés changent leurs interfaces, les navigateurs bougent.

Ce n'est pas théorique. Sur nos propres projets, nous avons vu un service continuer à servir un code vieux de trois semaines parce qu'un lien de déploiement avait été rompu sans que rien ne le signale. Nous avons vu deux configurations pointer sur le même domaine et produire une panne difficile à lire. Nous avons vu un formulaire recueillir des réponses complètes, coordonnées comprises, et ne les envoyer nulle part, parce qu'une variable de destination était restée vide. Aucun de ces trois incidents n'était un bug de code. Tous auraient été invisibles sans surveillance.

Les évolutions. Un outil qui sert est un outil qu'on veut faire évoluer. C'est bon signe, et ça se budgète.

Comment borner votre estimation en une heure

Prenez une feuille et répondez dans cet ordre. Vous n'obtiendrez pas un prix, vous obtiendrez quelque chose de plus utile : de quoi juger un devis.

1. Écrivez la procédure, une ligne par étape, de ce qui déclenche à ce qui sort. Si vous ne dépassez pas huit lignes, le périmètre est sain. Au-delà de quinze, il faut le couper.
2. Entourez les étapes où quelqu'un décide. Ce sont vos écrans coûteux.
3. Listez les exceptions, les « sauf si ». Chacune est une règle à écrire, à tester et à maintenir.
4. Listez les logiciels avec lesquels l'outil devra parler, et notez pour chacun si une interface publique existe.
5. Regardez vos données existantes. Combien de lignes, et combien sont réellement exploitables ?
6. Nommez la personne qui répondra aux questions, et le créneau où elle sera disponible.

Ces six réponses tiennent sur une page. Un prestataire à qui vous donnez cette page peut chiffrer sérieusement. Un prestataire qui chiffre sans elle devine.

Ce qui fait exploser un devis

Trois causes, et deux sont de votre côté.

Le périmètre qui grandit en route. Chaque « pendant qu'on y est » est légitime pris isolément. Mis bout à bout, ils doublent le projet. Le remède n'est pas de refuser, c'est d'écrire ce qui entre dans la première version et ce qui attend, avant de commencer.

La règle découverte tard. Le cas particulier que personne n'avait mentionné parce qu'il est évident pour tout le monde en interne. Il ne coûte presque rien s'il apparaît au cadrage, et beaucoup s'il apparaît quand l'outil est construit autour de son absence.

Le prestataire qui a chiffré au forfait sans avoir vu les données. Il découvre l'écart en route. Deux issues, également mauvaises : il rogne sur la qualité, ou il demande un avenant.

Ce qu'il faut exiger d'un devis, quel que soit le prestataire

Cette liste vaut aussi si vous ne travaillez jamais avec nous.

• Le périmètre écrit et négatif. Ce qui est inclus, et surtout ce qui ne l'est pas. Un devis qui ne dit pas ce qu'il ne fait pas ne dit rien.
• Un montant accepté avant la première ligne de code, pas un taux journalier multiplié par une durée estimée. La régie fait porter le risque d'estimation sur vous.
• La reprise des données chiffrée séparément, après avoir vu un échantillon réel.
• Ce qui se passe à la fin : à qui appartient le code, où il est déposé, et ce que vous récupérez si vous partez.
• Ce qui n'est pas construit dans la première version, écrit noir sur blanc.

Si un prestataire refuse d'écrire l'un de ces cinq points, ce n'est pas une question de prix. C'est une information sur la suite.

Et si la réponse était de ne rien construire

Il faut le dire, parce que c'est fréquent.

Une partie des projets qu'on nous décrit ne justifie pas un logiciel. Le volume est trop faible pour rembourser l'investissement. La procédure change encore tous les mois, et figer des règles instables coûte deux fois. Ou le blocage est une validation en trop, un rôle mal attribué, une décision jamais tranchée, et aucun logiciel ne répare ça. Il l'automatise, et le rend plus difficile à changer.

Dans ces cas, le devis le moins cher est celui qu'on n'établit pas. Nous le disons avant de commencer, y compris quand ça nous coûte la vente. Le sujet est développé dans notre article sur le moment où un tableur devient un risque, qui donne les signaux inverses : ceux qui disent qu'il est temps.

---

elma développe des applications métier et des intégrations IA pour des entreprises de six à cinquante personnes, à Muret et en Occitanie. Nous partons du process que vous connaissez déjà, sans phase d'audit facturée, et nous construisons des outils que nous exploitons nous-mêmes. Parlez-nous de votre projet : trente minutes suffisent pour savoir si c'est constructible, et à quel périmètre.