Le coût total d'une app web : build, run, et scale
'Combien ça coûte de développer une app' est la mauvaise question. La vraie distinction est entre coût de build, coût de run, et coût de scale — et où se cachent les dérapages.
"Ça dépend" n'est pas une réponse — mais un chiffre inventé serait pire
Chaque porteur de projet me demande combien coûte une application. Je pourrais donner une fourchette en euros, comme le fait la majorité des devis en ligne. Mais un chiffre sorti de nulle part, sans connaître le domaine, les intégrations et l'ambition réelle du produit, est plus trompeur qu'utile — il fixe une attente qui n'a aucun rapport avec le projet qu'on va réellement construire.
La question utile n'est pas "combien ça coûte de développer", c'est "combien ça coûte de faire exister ce produit, de le faire tourner, et de le faire grandir" — trois budgets différents, souvent gérés par des gens différents, et systématiquement confondus dans les devis.
Le coût de build : ce qui le fait vraiment varier
Le développement initial dépend de trois choses, dans cet ordre d'impact : la complexité des règles métier réelles (un outil de prise de rendez-vous n'a rien à voir avec un système de facturation multi-sources avec synchronisation ERP), le nombre d'intégrations tierces (chaque connexion à un service externe — paiement, email transactionnel, API partenaire — ajoute du temps de développement et une surface de maintenance permanente), et le niveau de finition attendu dès la V1.
Le point sur lequel je suis le plus tranché : un cahier des charges trop long fait toujours dériver le projet plus qu'il ne le sécurise. Identifier ce qui est essentiel à la V1 et le construire bien vaut mieux qu'un périmètre exhaustif jamais livré. Je travaille au forfait sur un périmètre défini, payable par jalons — pas au TJM flou où personne ne connaît le budget final avant la dernière facture.
Le coût de run : celui qu'on oublie de budgéter
Le développement initial n'est qu'une partie de la facture. L'hébergement continu, la surveillance des erreurs, les mises à jour de sécurité des dépendances, et les petites évolutions post-lancement sont des coûts récurrents qu'un devis de développement ne couvre jamais. C'est là que le choix d'infra pèse directement : une stack Coolify + VPS a un coût de run prévisible et linéaire ; une architecture cloud managée mal dimensionnée peut faire grimper la facture d'hébergement plus vite que l'usage réel ne le justifie.
Ignorer ce budget au moment du lancement, c'est se retrouver six mois plus tard avec un produit qui marche mais dont personne n'a prévu qui paie, ni combien, pour le garder en vie.
Le coût de scale : celui qui sanctionne les raccourcis du build
C'est le budget le plus mal anticipé. Un produit qui a été construit vite, avec des raccourcis justifiés par la pression du lancement, transfère sa dette au moment où il faut absorber plus de trafic ou plus de règles métier. Le coût de scale n'est pas un multiple linéaire du coût de build — c'est le prix de reprendre des décisions qui n'ont jamais été pensées pour être révisées.
Le vrai levier de maîtrise, ce n'est pas de sur-dimensionner dès la V1 pour éviter ce coût plus tard — c'est de garder des choix réversibles : une architecture qui sépare proprement les responsabilités, une infra qui peut monter en gamme sans migration complète, une base de code qu'un autre développeur peut reprendre sans devoir tout réécrire.
Le seul piège qui coûte systématiquement plus cher que prévu
Comparer un devis senior avec un devis d'agence offshore ou d'un développeur "pas cher" sans intégrer le coût de reprise. Un produit livré au rabais qui doit être repris plus tard coûte l'addition des deux budgets — celui du développement initial, et celui de l'audit + refactor qui suit. Le calcul qui compte n'est jamais le prix du premier devis, c'est le coût total cumulé sur build, run et scale.