Ce que coûte vraiment une application web (et pourquoi les devis varient du simple au quintuple)

Trois agences, trois devis, un écart de un à cinq. Voici ce qui détermine réellement le prix d'une application web — et comment lire une proposition.

Vous décrivez le même projet à trois agences. L'une chiffre à huit mille euros, l'autre à trente-cinq mille, la troisième à cent vingt mille. Les trois sont honnêtes. Elles chiffrent simplement trois projets différents, parce que votre brief laissait la place à trois interprétations différentes.

Les cinq variables qui fixent le prix

1. Le nombre de rôles utilisateurs distincts. Une application avec un seul type d'utilisateur représente une fraction du travail d'une application avec un administrateur, un client et un partenaire — les permissions, interfaces et cas limites se multiplient, ils ne s'additionnent pas.
2. Les intégrations. Chaque système externe est une négociation avec l'API de quelqu'un d'autre, ses limites de débit, son environnement de test et ses pannes. Trois intégrations représentent souvent plus de travail que toute l'interface.
3. La complexité des données. Un formulaire qui écrit une ligne est trivial. Un système où une modification doit se propager correctement à cinq autres endroits, avec historique et retour arrière, ne l'est pas.
4. L'ambition graphique. Une interface propre bâtie sur une bibliothèque de composants va vite. Une expérience sur mesure, animée et direction-artistiquée est une discipline distincte, avec son propre calendrier.
5. Les exigences non fonctionnelles. Mode hors ligne, multilingue, traçabilité, conformité réglementaire et haute disponibilité peuvent chacune doubler l'effort tout en restant invisibles en démonstration.

Où part réellement l'argent

Sur un projet typique, le développement des fonctionnalités représente environ la moitié du budget. Le reste couvre le cadrage et la spécification, la conception d'interface, les tests, l'infrastructure de déploiement, et le cycle d'itération après la confrontation de la première version aux vrais utilisateurs. Les propositions qui allouent quatre-vingt-dix pour cent au développement ne sont pas moins chères : elles omettent simplement les phases qui déterminent si la chose fonctionne.

• 20-25% cadrage, spécification et design
• 45-55% développement et intégrations
• 20-30% tests, déploiement, itérations post-lancement

Le devis le moins cher et ce qu'il signifie généralement

• Pas de phase de cadrage : la spécification sera inventée en cours de développement, par celui qui tape le code.
• Pas de budget de test : vous devenez l'équipe de test, après le lancement, devant vos clients.
• Un thème ou un constructeur de pages présenté comme du développement sur mesure, qui tient jusqu'à la première exigence qu'il ne sait pas exprimer.
• Un prix ferme sur un périmètre flou, ce qui garantit une relation conflictuelle dès que la réalité s'écarte du brief.

Rien de tout cela ne rend un devis bas automatiquement mauvais. Pour un projet réellement simple et bien compris, une approche légère est le bon choix. Cela ne devient dangereux que lorsque le périmètre est incertain — car cette incertitude ne disparaît pas, elle est simplement facturée plus tard.

Comment comparer honnêtement des propositions

1. Donnez aux trois agences le même brief écrit, exigences non fonctionnelles incluses. Des briefs différents produisent des devis incomparables.
2. Demandez à chacune ce qu'elle couperait pour diviser le budget par deux. La réponse révèle sa compréhension de vos priorités.
3. Demandez ce qui se passe après la mise en production : qui corrige un bug à 20h, sous quel délai, à quel coût.
4. Faites confirmer par écrit que vous êtes propriétaire du code, des données et des comptes. Ce point n'est pas négociable et ne coûte rien à demander.
5. Exigez une référence sur un projet de complexité comparable — et appelez-la vraiment.

L'approche qui garde les budgets sous contrôle

Découpez la mission. Payez une phase de cadrage courte et à prix ferme, qui produit une vraie spécification, un modèle de données et un prototype cliquable. Ce livrable vous appartient, et n'importe quelle agence peut chiffrer dessus avec précision — y compris celle qui l'a produit. Vous transformez une décision incertaine à cent mille euros en une décision petite et bornée, et tous les devis suivants deviennent comparables.

À quoi ressemblent vraiment les fourchettes

Donner des fourchettes en public est risqué : quelqu'un vous les ressort toujours deux ans plus tard. Refuser tout chiffre n'aide personne non plus. Aux tarifs européens, pour une application sur mesure et non un thème, les paliers ressemblent à peu près à ceci. Lisez-les comme des descriptions de périmètre, pas de qualité.

• 8k-25k un rôle, aucune intégration, design sur bibliothèque de composants
• 25k-80k plusieurs rôles, deux ou trois intégrations, un vrai modèle de données
• 80k+ contraintes réglementaires, haute disponibilité, interface direction-artistiquée

Ce qui fait passer un projet d'un palier à l'autre n'est presque jamais le nombre d'écrans. C'est le nombre de choses qui doivent rester cohérentes entre elles. Deux rôles et une intégration tiennent confortablement dans le premier palier. Ajoutez un portail partenaire, une synchronisation comptable et une piste d'audit : la même liste de fonctionnalités bascule dans le second, parce que chacune de ces obligations doit rester vraie pendant que les deux autres évoluent.

Les coûts qui arrivent après la facture

Le prix de construction est la partie que tout le monde compare. Le coût de fonctionnement est celle qui détermine si le projet était une bonne idée.

• L'hébergement et l'infrastructure, de quelques euros par mois pour une petite application à plusieurs centaines dès qu'il faut une base gérée, de vraies sauvegardes et un environnement de préproduction.
• Les abonnements par utilisateur sur tout ce à quoi l'application parle : le CRM, l'envoi d'e-mails, le prestataire de paiement, la plateforme d'automatisation. Ils grossissent avec vos effectifs, pas avec votre usage.
• Les frais à l'usage. Paiements, SMS, minutes téléphoniques et jetons d'IA se facturent à l'événement : le succès les augmente, il ne les réduit pas.
• La supervision et le suivi des erreurs, sans lesquels vous apprenez vos pannes par vos clients.
• Les mises à jour de dépendances et les correctifs de sécurité. Un framework arrive en fin de vie tous les deux à trois ans, et repousser cette migration ne fait que l'agrandir.
• Le support. Quelqu'un doit répondre à la question à laquelle l'interface n'a pas su répondre.

Sur trois ans, le coût de fonctionnement égale ou dépasse couramment celui de la construction initiale. Demandez ce chiffre avant de signer, pas après. Une agence qui n'a jamais eu à le produire vous dit quelque chose sur la durée de vie habituelle de ses projets.

Ce qui fait réellement gonfler un devis en cours de route

1. Une reprise de données que personne n'a chiffrée. Les anciens tableurs se contredisent, et les nettoyer est un projet à part entière.
2. Des contenus qui arrivent tard ou jamais. Textes, photos et pages légales relèvent généralement du client, et sont généralement la raison pour laquelle un lancement glisse.
3. Des décisions suspendues à quelqu'un qui est en vacances. Le temps mort se facture, en retard ou en temps de remise dans le sujet.
4. Le petit rapport qui n'est pas petit. Un nouveau chiffre suppose souvent une nouvelle donnée, saisie à un nouvel endroit, par chaque écran qui l'alimente.
5. Une intégration dont l'environnement de test se comporte autrement qu'en production, ce que l'on découvre le jour où l'on branche le vrai compte.

Deux habitudes absorbent l'essentiel. Prévoyez dix à quinze pour cent de budget de changement dès le départ, pour que la première surprise soit une décision et non une négociation. Et tenez une réunion hebdomadaire courte avec quelqu'un qui a réellement le pouvoir de trancher, car les retards coûteux sont rarement techniques.

Ce qui coûte cher dans le logiciel, c'est rarement le code. C'est de construire correctement la mauvaise chose.

Vous voulez la même chose pour votre entreprise ? Voir ce que nous faisons.