Combien coûte le développement d’une application ? La question est mal posée, et voici celle qui marche

Une fondatrice avec qui nous avons travaillé l’an dernier nous a transféré trois devis pour ce qu’elle appelait la “même” application. 18 000 $ d’un freelance à Bogotá. 80 000 $ d’un petit studio à São Paulo. 260 000 $ d’une agence américaine. Même description de produit, mêmes wireframes, trois estimateurs honnêtes. Les trois chiffres étaient défendables. Le devis bon marché correspondait à un prototype Bubble qu’elle pouvait montrer à des investisseurs. Celui du milieu était une application fonctionnelle que deux clients réels pouvaient utiliser sans qu’elle casse. Le cher incluait l’intégration SSO et la revue de compliance que son pilote enterprise allait exiger.

Combien coûte le développement d’une application est l’une des questions les plus recherchées sur Google par les fondateurs. C’est aussi l’une des moins répondables. Les chiffres des listicles sont techniquement corrects de la même manière que “un repas à New York coûte entre 4 et 400 dollars” est techniquement correct. La fourchette est si large qu’elle ne transmet rien. Pire, chaque fourchette est biaisée par sa source. Les agences d’apps citent des fourchettes qui flattent les agences d’apps. Les marketplaces de freelances citent des fourchettes qui flattent les freelances. Les plateformes no-code citent des fourchettes qui rendent le no-code évident.

La question qui marche est différente : combien coûte la construction de mon application, avec mon périmètre, sur mon calendrier, avec une équipe à qui je peux faire confiance ? En logiciel sur mesure, le coût est le résultat de six leviers. Une fois que vous connaissez les vôtres, vous pouvez nommer une fourchette, la défendre, et arrêter de vous faire vendre quelque chose.

Pourquoi la réponse standard est mauvaise

La réponse standard fonctionne ainsi. Une application simple coûte 20 K$ à 50 K$. Une application de complexité moyenne, 50 K$ à 150 K$. Une application enterprise complexe, 150 K$ à 500 K$. Certaines sources poussent le plafond à un million.

Ces fourchettes ne sont pas des mensonges. Ce sont les moyennes de la population d’applications que la source a vues. Vous ne construisez pas l’application moyenne. Vous construisez une application précise, et la moyenne ne dit rien sur le fait que votre chiffre soit à 30 K$ ou à 300 K$. La variance à l’intérieur de chaque tranche est plus large que la tranche elle-même.

Le problème plus profond est que “simple, moyen, complexe” cache toutes les décisions qui font vraiment bouger le chiffre. Une application avec un seul écran et un checkout Stripe est simple. Une application avec un seul écran et une intégration SSO enterprise ne l’est pas. Une application avec cinq écrans et un backend type Notion est énorme. Une application avec quinze écrans et un panneau admin CRUD est petite. Les étiquettes effondrent tout cela en bruit.

Les fondateurs qui s’ancrent sur ces fourchettes commettent deux erreurs prévisibles. Ils prennent le devis le moins cher dans leur tranche cible et découvrent six mois plus tard que l’équipe bon marché a construit une application différente de celle dont ils avaient besoin. Ou ils supposent que le prix égale la qualité et paient quatre fois le prix pour une équipe qui n’est pas meilleure que l’option du milieu. Les deux erreurs commencent au même endroit : un chiffre qui n’a jamais été rattaché à une vraie estimation.

Les six leviers qui fixent vraiment votre chiffre

En logiciel sur mesure, le coût n’est pas magique. C’est le produit de six choses, et vous pouvez débattre avec n’importe quel estimateur sur chacune. Si un devis ne décompose pas le chiffre sur au moins quatre de ces six leviers, ce n’est pas une estimation. C’est une devinette habillée en estimation.

Périmètre : ce que les utilisateurs font, du début à la fin

Le périmètre est le levier le plus important, et celui que les fondateurs sous-estiment systématiquement. La bonne unité n’est pas “écrans” ni “fonctionnalités”. Ce sont des flows. Un flow, c’est tout ce qu’un utilisateur fait pour atteindre un objectif, de l’inscription au résultat.

La plupart des fondateurs comptent les fonctionnalités et reportent le périmètre comme “dix fonctionnalités”. Une application fonctionnelle avec dix fonctionnalités a environ quarante flows une fois qu’on inclut les chemins malheureux (ce qui se passe quand un paiement échoue, quand une session expire, quand un email rebondit, quand un utilisateur veut supprimer son compte, quand un admin doit rembourser). Chaque flow représente deux à dix heures de travail selon la forme du système en dessous. La différence entre compter dix fonctionnalités et compter quarante flows est la différence entre un devis à 40 K$ et une réalité à 120 K$.

Si vous n’avez pas encore écrit les flows que votre application doit supporter, vous n’êtes pas prêt à recevoir un devis. Vous êtes prêt à écrire un product requirements document, ce que tout vrai estimateur va vous demander avant de chiffrer.

Intégrations : avec quoi votre application parle

Chaque système externe que votre application touche ajoute un coût en deux endroits : le build initial et la longue traîne de la maintenance. Une intégration Stripe est bon marché parce que Stripe a investi pour être facile. Une intégration directe avec un fournisseur PIX brésilien ne l’est pas, parce que la documentation est en portugais, le sandbox est instable, et les bugs de production n’apparaissent qu’en charge.

Les intégrations apportent aussi des modes de panne que le reste de votre code n’a pas. Un webhook Stripe peut arriver deux fois. Un CRM peut renvoyer un 502. Un fournisseur d’identité peut changer son écran de consentement un mardi. Bien gérer cela demande plus de code que le chemin heureux, et un vrai estimateur le facture. Un devis bon marché qui liste “intégration Stripe” en une seule ligne facture le chemin heureux et découvre le reste à vos frais.

Comptez vos intégrations. La plupart des applications en phase initiale en ont entre trois et sept (auth, paiements, emails, analytics, file storage, une ou deux APIs métier). Chacune dépasse rarement les 2 000 $ de travail, et tombe entre 5 000 $ et 10 000 $ si le fournisseur est pénible.

Données : où vit l’état, qui en est propriétaire

Certaines applications ne sont qu’une UI posée sur une petite table Postgres. Elles sont bon marché. D’autres sont essentiellement la donnée, et l’UI n’en est qu’une fine couche. Celles-ci ne le sont pas.

Les questions qui font bouger le chiffre : combien de données par utilisateur, à quelle fréquence elles changent, qui d’autre doit les voir, peut-on les exporter, faut-il les rechercher, comment vous les sauvegardez, ce qui se passe quand les données d’un utilisateur sont corrompues à 23 h un vendredi. Chaque réponse tire un design à 0 $ ou un design à 20 K$. Un habit tracker B2C avec cinq champs par utilisateur est l’extrémité bon marché. Une plateforme B2B qui ingère le CSV d’un partenaire chaque nuit, le transforme et l’expose dans un dashboard où le partenaire doit aussi se connecter est l’extrémité chère. Même nombre d’écrans.

Si votre application est la donnée, le coût est la donnée. Si votre application est le workflow au-dessus de la donnée, le coût est le workflow. Les estimateurs qui ne demandent pas laquelle des deux vous construisez n’estiment pas ; ils devinent la plus facile des deux.

Compliance et comptes : ce que la loi et l’identité vous obligent à construire

Trois choses cassent un devis bon marché au premier contact : industries régulées, clients enterprise, et identité à grande échelle.

Santé, fintech, éducation et legaltech portent une charge de compliance qui n’est pas optionnelle. RGPD, SOC 2 readiness, audit logs, chiffrement au repos, contrôle d’accès par rôle. Rien de tout cela n’est difficile, mais tout est du travail, et ajouter une posture de compliance tard coûte trois à cinq fois plus que de l’intégrer dès le départ.

Les clients enterprise sont similaires. Le jour où votre premier vrai client demande SSO, export d’audit log, rôles personnalisés et un SLA est le jour où votre MVP à 40 K$ devient un produit à 120 K$. Aucune de ces choses n’est mauvaise à construire. Aucune n’est gratuite, et un devis bon marché qui dit “on ajoutera les fonctions enterprise plus tard” déplace le coût du devis vers le futur.

L’identité est le troisième levier silencieux. Une application avec un seul rôle utilisateur est bon marché. Une application avec admins, utilisateurs finaux, super-admins, comptes partenaires et un rôle read-only pour le client ne l’est pas. Chaque rôle traîne derrière lui une matrice de permissions, et les matrices de permissions ont la pire densité de bugs de tout le code de votre système.

Qualité d’équipe : qui écrit le code

Deux équipes qui chiffrent le même périmètre peuvent produire des chiffres trois fois plus éloignés, et le chiffre le plus élevé est souvent la meilleure affaire. Les équipes juniors écrivent plus de code pour faire la même chose, puis écrivent plus de code par-dessus pour réparer ce que la première passe a cassé. Le taux horaire ressemble à des économies. Le coût total de possession dit la vérité.

Une équipe senior écrit moins de code, l’écrit avec plus de soin, le laisse documenté assez pour qu’une équipe future puisse l’étendre, et livre un système qui ne s’effondre pas la première fois que vous essayez d’ajouter une seconde fonctionnalité par-dessus. Le taux horaire est plus élevé. Le coût de construire, faire tourner et étendre l’application sur ses dix-huit premiers mois est généralement plus bas.

Si vous ne pouvez pas évaluer le code vous-même (et presque aucun de nos clients ne le peut), regardez les signaux. Comment l’équipe parle-t-elle des trade-offs ? Demande-t-elle l’objectif business ou seulement la spécification ? Pousse-t-elle en retour sur les demandes qui vont créer de la dette technique ? Vous montre-t-elle un système d’un client précédent qui tourne en production, pas seulement une capture Dribbble ? Une équipe incapable de défendre un seul choix d’architecture en langage clair est l’équipe qui va vous facturer deux fois la même fonctionnalité quand elle cassera. Nous avons déballé le reste du diagnostic dans comment évaluer une software house ; presque chaque signal de cette liste se traduit en coût.

Rythme : à quel point le calendrier vous serre

Le calendrier est la variable la moins chère à bouger et celle que les fondateurs sont les plus réticents à bouger. Comprimer un build de six mois en trois mois ne coupe pas le coût en deux. Il le double, parce que les builds compressés exigent plus de monde en parallèle, plus d’overhead de coordination, plus de rework quand deux branches parallèles s’entrechoquent, et plus de temps senior par heure.

L’inverse est vrai aussi. Une équipe capable de construire à un rythme régulier sur six mois va chiffrer un total plus bas que la même équipe lancée dans un sprint pour livrer avant votre démo investisseurs. Si vous avez de la flexibilité sur la deadline, cette flexibilité vaut de l’argent réel. Si vous n’en avez pas, le devis va refléter la pression, et une équipe qui vous a donné un chiffre de rythme calme va livrer un produit différent (pire) quand vous lui direz le mardi qu’il vous le faut le vendredi.

Fourchettes réalistes par étape

Avec les six leviers en main, les fourchettes ci-dessous deviennent utiles au lieu d’être trompeuses. Ce sont toujours des fourchettes. Les leviers du dessus disent où vous tombez à l’intérieur de chacune.

Esquisse / prototype à montrer, pas à utiliser. 5 000 $ à 20 000 $. Build no-code (Bubble, Glide, FlutterFlow), application React très templatée, ou Figma cliquable. Ça démontre. Ça ne survit pas à un vrai utilisateur. Utilisez-le pour la levée de fonds, l’alignement interne, ou une lettre d’intention client. Ne l’utilisez pas comme fondation de votre vrai produit, et ne laissez pas un estimateur vous promettre que vous le pouvez.

MVP réel que deux clients réels peuvent utiliser. 35 000 $ à 120 000 $. Trois à sept intégrations. Deux à trois rôles utilisateur. Compliance encore légère. Huit à vingt flows. Une équipe de deux à trois ingénieurs sur trois à cinq mois. C’est la forme la plus courante d’un engagement Pixel Breeders, et celle où la variance est la plus large, parce que les six leviers cessent d’être abstraits et commencent à produire des heures réelles.

V1 post-lancement avec des clients payants et un vrai backlog. 150 000 $ à 400 000 $+ sur la première année. Le build du MVP plus les dix choses que les clients demandent dans les quatre-vingt-dix premiers jours et que vous ne pouviez pas prédire. La demande SSO de votre premier pilote enterprise. Le rebuild de la queue que vous avez câblée trop vite pendant le MVP. L’analytics que vous avez décidé de sauter. Les fondateurs qui chiffrent seulement le MVP et pas “MVP plus la première année de réalité” reviennent en demandant pourquoi les seconds six mois ont coûté autant que les premiers.

Ces fourchettes supposent une équipe compétente, un périmètre honnête, et le marché américain ou ouest-européen. Le Brésil, l’Europe de l’Est et l’Amérique latine coupent la part coût-équipe d’environ moitié sans couper la qualité, si vous trouvez une vraie équipe. L’arbitrage géographique fonctionne, mais les pires projets dont nous avons entendu parler ont tous commencé par “on a trouvé une équipe en [pays] à moitié prix”.

Le diagnostic en cinq questions qui teste un devis

Quand un devis arrive, posez les cinq questions ci-dessous avant de comparer deux devis l’un à l’autre. Le diagnostic sépare les vraies estimations du théâtre commercial. Un vrai estimateur répond sans broncher. Une devinette produit des réponses vagues, du langage défensif ou “on verra ça ensemble”.

1. Quel périmètre avez-vous supposé, en flows ? Pas en fonctionnalités. En flows. S’ils ne peuvent pas lister dix ou vingt flows nommément, ils n’ont pas estimé ; ils ont mis un prix sur vos wireframes.
2. Quelles intégrations sont incluses dans le devis, et lesquelles sont explicitement exclues ? Un vrai devis a une liste. Une devinette dit “on gérera les intégrations au fil de l’eau”.
3. Qui exactement sera dans cette équipe ? Pas l’expérience collective de l’entreprise. Les trois personnes réelles qui vont écrire le code, avec leur LinkedIn ou GitHub. Une vraie équipe livre les noms. Une équipe bait-and-switch non.
4. Quels sont les trois plus gros risques que vous voyez sur ce périmètre ? C’est le diagnostic qui attrape le plus. Un estimateur senior nomme trois risques en quinze secondes. Un junior ou un malhonnête dit “aucun risque majeur, on a déjà fait ça”.
5. À quoi ressemble le septième mois si on vous embauche ? Cette question les force à penser au-delà du build, à la maintenance, aux demandes inévitables de fonctionnalités, aux bugs trouvés en production. Une équipe qui n’a pensé qu’au build va vous facturer deux fois cette conversation plus tard.

Si un devis répond bien aux cinq et coûte le double d’un devis qui n’en répond aucune, le plus cher est le moins cher sur douze mois.

Là où les fondateurs brûlent le plus d’argent

Nous avons vu les trois mêmes erreurs vider des budgets pendant des années. Aucune n’a à voir avec le taux horaire.

Construire l’application que vous avez imaginée au lieu de l’application que vos clients vont utiliser. La façon la plus rapide de dépenser 80 000 $ que vous n’aviez pas besoin de dépenser est de livrer le produit qui est dans votre tête et de découvrir, après le lancement, que les clients veulent autre chose. Le remède est de mettre la plus petite version possible devant trois clients réels avant le build, pas après. Nous avons écrit sur pourquoi la plupart des prétendus MVP n’en sont pas, et le principe vaut pour le coût aussi : la fonctionnalité la moins chère est celle que vous ne construisez pas.

Économiser sur l’équipe et le payer en rework. Le freelance qui coûte 25 $ de l’heure et produit du code que la prochaine équipe réécrit depuis zéro ne vous a pas fait économiser. Il vous a coûté le build deux fois plus le temps perdu entre les manches. La main-d’œuvre bon marché en travail d’ingénierie est le moyen le plus fiable de surpayer.

Choisir le contrat qui laisse la cherté se cacher. Un devis forfait sur un périmètre mal défini crée l’incitation pour l’équipe à rogner sur tout ce que vous n’avez pas écrit. Un devis purement régie sur un brief vague crée l’incitation à ce que le travail s’étende. La forme du contrat compte autant que le montant. Nous avons déballé les arbitrages dans forfait vs régie ; choisissez la structure qui permet à votre équipe d’être honnête avec vous.

Ce qu’il faut demander avant de signer

Mettez les trois choses ci-dessous dans le contrat.

Une liste des flows que le devis couvre, et la déclaration explicite que tout ce qui sort de cette liste est un change request. Cela protège les deux parties. L’équipe n’est pas tenue à des choses qui n’ont pas été estimées. Vous n’êtes pas surpris quand “on s’occupe du panneau admin” devient un ajout de 30 K$.

Une démo hebdomadaire de logiciel qui marche, pas des slides, pas des captures d’écran. Si l’équipe ne peut pas vous montrer une version qui tourne de ce qu’elle a construit cette semaine, elle ne l’a pas construite cette semaine. La démo est la forme de gestion de projet la moins chère que vous achèterez jamais.

Une structure de paiement par jalons attachée à ces démos. Pas “33 % au début, 33 % au milieu, 33 % à la livraison”. Quelque chose plus proche de “5 % au début, puis un paiement après chaque quinzaine de démo qui marche”. L’équipe est payée pour livrer. Vous arrêtez de payer si les démos s’arrêtent.

Le coût du développement d’une application est le coût de ces décisions, bien ou mal prises, multiplié par le temps qu’une équipe compétente met à les exécuter. Le chiffre n’est pas aléatoire. C’est le résultat de six leviers que vous pouvez nommer, trois clauses de contrat que vous pouvez écrire, et une conversation diagnostique que vous pouvez avoir avant de signer. Les fondateurs qui sautent la conversation la paient plus tard. Ceux qui l’ont paient à peu près ce que l’application aurait dû coûter, et finissent avec l’application qu’ils voulaient vraiment construire.

C’est la réponse à la question d’origine. Pas une fourchette. Une méthode.

FAQ

Puis-je construire une application gratuitement ?
Vous pouvez construire une esquisse gratuitement avec Bubble, Glide ou un outil no-code. Vous ne pouvez pas construire un business comme ça. La version gratuite démontre. Elle ne survit pas aux vrais utilisateurs, à l’échelle, aux intégrations ou à toute personnalisation significative. Traitez le build gratuit comme un outil de levée de fonds et de validation, puis planifiez un vrai build une fois la demande prouvée.

Pourquoi les fourchettes de coûts que je vois en ligne sont-elles si larges ?
Chaque fourchette effondre six leviers indépendants en un seul chiffre. Une application à 20 K$ et une application à 200 K$ peuvent avoir le même nombre d’écrans, la même description et le même objectif business. Les leviers de cet article sont la façon dont vous transformez une fourchette en un chiffre pour votre application.

Combien de temps faut-il pour développer une application ?
Un MVP réel avec des clients payants prend trois à six mois avec une équipe de deux à trois ingénieurs. Quiconque promet moins construit un prototype, coupe du périmètre sans vous le dire, ou s’apprête à livrer quelque chose qui casse. Quiconque chiffre douze mois sur-construit ou sous-staffe en silence.

Quelle est la façon la moins chère de valider une idée d’application avant de construire ?
Une landing page, une vidéo de démo et trois conversations menées par le fondateur avec des clients potentiels valideront plus en deux semaines que trois mois de construction. La plupart des fondateurs sautent cette étape et découvrent après le build que la demande qu’ils supposaient n’était pas là sous la forme qu’ils pensaient.