Estimateur du coût d'une application sur-mesure

Comment cette estimation est calculée

Cette estimation part des budgets constatés sur le marché français en 2026 : 12 000 à 50 000 € pour un premier périmètre resserré, 35 000 à 150 000 € pour une application complète, à partir de 100 000 € pour une plateforme riche. Vos huit réponses ajustent ce socle avec des coefficients affichés en clair dans le détail du résultat, plutôt que dans une boîte noire. Le calcul s'exécute dans votre navigateur, sans inscription et sans que rien ne soit transmis.

Pour situer ces repères : sur 184 budgets de logiciels sur mesure relevés par La Fabrique du Net, un annuaire d'agences, la médiane est de 30 000 €, et un projet sur sept dépasse 100 000 € (données arrêtées en juin 2026).

J'ai construit cet outil parce que la question du budget arrive presque toujours trop tard dans les projets, une fois que des attentes se sont installées. Avoir un ordre de grandeur avant de rédiger un cahier des charges change la conversation : on arbitre le périmètre en connaissance de cause au lieu de découvrir l'écart à la réception des devis.

Et l'IA, elle ne fait pas baisser le prix ?

Pas de façon mesurable à ce jour. L'IA accélère l'écriture du code, mais le code n'est qu'une partie de la facture, et le gain lui-même reste discuté : en 2025, l'essai contrôlé de METR a trouvé des développeurs expérimentés 19 % plus lents avec l'IA que sans, sur leurs propres projets. Refait fin 2025, l'essai ne mesure toujours pas de gain net, même si ses auteurs jugent probable que les outils récents en apportent un.

Ce que l'IA change vraiment, c'est le prototype. En quelques jours et pour le prix d'un abonnement, un outil de génération d'applications produit une maquette qui fonctionne, de quoi montrer l'idée à de vrais utilisateurs avant de signer un devis. C'est une très bonne étape, à condition de la traiter comme un brouillon : la sécurité, la reprise des données, les intégrations, la recette et la maintenance restent à faire, et c'est là que se trouve l'essentiel du budget. Je détaille ce passage dans passer un prototype IA en production.

Ce que l'estimateur ne peut pas deviner

Huit questions décrivent la forme d'un projet, pas sa matière. Ce qui déplace le plus un chiffrage, dans mon expérience, reste hors de portée d'un formulaire.

• La complexité des règles de gestion. Deux applications avec le même nombre d'écrans peuvent demander un travail du simple au triple selon les règles de calcul, les statuts, les droits par profil et les cas particuliers hérités de votre métier. C'est le premier facteur d'écart, et il ne se déclare pas en une réponse.
• La qualité de vos données existantes. Reprendre une base propre et documentée n'a rien à voir avec reprendre vingt ans de saisies libres, de doublons et de champs détournés de leur usage.
• La disponibilité de vos équipes. Un projet avance à la vitesse des décisions. Sans interlocuteur métier disponible pour trancher, les délais s'allongent et le coût de pilotage grimpe.
• Le niveau de design attendu. Une interface d'outil interne et une expérience travaillée écran par écran pour des clients ne se chiffrent pas de la même façon.
• Le degré de finition à la livraison. Une recette sérieuse, des tests automatisés, une documentation et une reprise en main par vos équipes représentent une part réelle du budget, souvent la première rognée quand un devis doit rentrer dans une enveloppe.

Ces angles morts sont exactement ce qu'un cadrage sert à lever. C'est aussi la raison pour laquelle je conseille de commencer petit, avec un MVP qui met le produit entre les mains d'utilisateurs réels avant d'engager le gros du budget.

Pourquoi le coût de départ n'est pas le coût total

Le montant du développement est la ligne visible, et c'est presque toujours la seule que l'on compare. Avec une maintenance de 15 à 20 % par an, trois ans d'exploitation ajoutent déjà de l'ordre de la moitié du budget initial, avant même l'hébergement et les évolutions. Une application est un logiciel vivant : elle se maintient, s'héberge et évolue, sinon elle se dégrade toute seule.

Le bon réflexe est de raisonner en coût sur trois ans plutôt que sur la seule ligne du devis initial. Le contrat qui porte cette dépense s'appelle souvent une TMA, et ce qu'il couvre exactement mérite d'être lu de près : j'en détaille les familles dans mon guide sur la maintenance d'une application.

Comment lire un devis à la lumière de ce résultat

Une fois la fourchette obtenue, elle sert de grille de lecture. Quand vous recevez des propositions, quatre réflexes suffisent à voir où sont les vrais écarts.

• Un devis nettement sous la fourchette n'est pas une bonne affaire. C'est presque toujours le signe d'un périmètre plus étroit que celui que vous avez en tête, ou d'une recette et d'une reprise de données réduites à la portion congrue. Demandez ce qui est explicitement exclu, la réponse est plus instructive que le total.
• Un devis nettement au-dessus mérite la même question, à l'envers. Il inclut peut-être des postes que les autres ont omis, ce qui en fait le seul chiffrage honnête du lot. Comparez les lignes, pas les totaux.
• Vérifiez le mode de facturation. Un forfait et une régie ne portent pas le même risque et ne se comparent pas directement. La distinction est détaillée dans ma fiche régie ou forfait.
• Cherchez la ligne maintenance. Un devis qui ne mentionne ni garantie, ni maintenance, ni réversibilité vous laisse le coût réel à découvrir l'année suivante.

Si les propositions que vous recevez s'écartent fortement les unes des autres, ce n'est pas un problème de tarif mais de périmètre implicite. C'est ce que règle un cahier des charges écrit, et c'est le travail que je fais en amont sur les projets que j'accompagne.