Combien coûte une application web métier ? Ce que je réponds vraiment

C’est la question que j’entends à chaque premier rendez-vous, souvent formulée avec des précautions — comme si demander un prix était indélicat. Ça ne l’est pas. C’est même la question la plus légitime qui soit, et l’esquiver est un mauvais signe.

Alors voici comment je réponds, avec les fourchettes que nous pratiquons et surtout ce qui les fait bouger.

Les ordres de grandeur

Pour une application métier sur mesure, première version en production :

Profil de projet	Fourchette	Exemple
Outil interne simple	50 – 150 k€	Remplacer un tableur partagé, un seul type d’utilisateur
Application métier standard	150 – 400 k€	Plusieurs profils, back-office, 2 à 3 interfaces
Application critique ou complexe	400 k€ et plus	Reprise de données lourde, contraintes réglementaires, forte volumétrie

Ces montants couvrent le cadrage, la conception, le développement et la mise en production. Ils ne couvrent pas ce qui vient après — et c’est précisément là que se joue la rentabilité du projet.

Les quatre facteurs qui font le prix

Le nombre d’interfaces avec l’existant. C’est le premier levier, très loin devant. Une application autonome coûte une fraction de la même application connectée à un ERP, un outil comptable et l’annuaire de l’entreprise. Chaque interface ajoute des échanges, des cas d’erreur, et une dépendance à une équipe qui n’est pas la nôtre.

Le nombre de profils utilisateurs. Un seul type d’utilisateur va vite. Dès qu’il y a des rôles, des délégations, un back-office et des règles de visibilité, la conception se démultiplie : il faut penser chaque écran autant de fois qu’il y a de profils.

La reprise de données. Reprendre dix ans d’historique n’est pas une tâche technique, c’est une enquête. Que fait-on des enregistrements incomplets, des doublons, des statuts qui n’existent plus ? Ces décisions appartiennent au métier et prennent du temps.

La contrainte réglementaire. Données de santé, données bancaires, marchés publics : ce n’est pas plus difficile techniquement, mais cela ajoute des étapes de validation incompressibles.

L’erreur de raisonnement la plus fréquente

Comparer deux devis sur leur montant.

Un devis à 90 k€ et un devis à 180 k€ pour « la même application » ne décrivent presque jamais la même chose. L’écart tient à ce qui est inclus : le cadrage est-il dedans ? La reprise de données ? La recette ? La formation des utilisateurs ? Les trois premiers mois d’exploitation ?

Le moins-disant l’est presque toujours parce qu’il a exclu des postes qui reviendront en avenant. Je le dis d’autant plus volontiers que ça nous coûte parfois des affaires : nous chiffrons ce que nous savons devoir faire, pas ce qui rentre dans un budget annoncé.

Ma recommandation : demandez à chaque prestataire de chiffrer poste par poste, avec les mêmes lignes. La comparaison devient possible, et les écarts deviennent parlants.

Photo : Kristin Hardwick — licence CC0.

Forfait ou régie ? Ce que je conseille

La question du modèle contractuel arrive juste après celle du prix, et elle compte autant.

Le forfait rassure : un périmètre, un prix, une date. Il ne fonctionne bien que si le périmètre est réellement stabilisé — donc après un cadrage sérieux. Sur un besoin encore flou, le forfait pousse les deux parties à se protéger : le prestataire gonfle son estimation pour absorber l’incertitude, le client verrouille le périmètre pour tenir le prix, et on se retrouve à livrer exactement ce qui était écrit six mois plus tôt, même quand tout le monde sait que ce n’est plus le bon besoin.

La régie offre la souplesse mais transfère le risque au client. Elle suppose une confiance établie et quelqu’un côté client capable de piloter réellement la priorisation. Sans ça, elle dérive.

Ce que nous pratiquons le plus souvent : un cadrage au forfait, court et à prix ferme, puis un engagement sur la suite une fois qu’on sait de quoi on parle. Le client achète d’abord de la clarté — pour une somme limitée — et décide ensuite en connaissance de cause. S’il choisit un autre prestataire pour la réalisation, il repart avec un cadrage qui lui appartient.

Photo : Wilfred Iven — licence CC0.

Les postes qu’on oublie de chiffrer

Quand je relis un devis concurrent avec un prospect, ce sont presque toujours les mêmes lignes qui manquent :

• La reprise des données existantes, souvent réduite à une ligne alors qu’elle représente parfois 15 % du projet.
• La recette, c’est-à-dire le temps des utilisateurs et celui de l’équipe pour traiter leurs retours.
• La formation et l’accompagnement au changement. Une application que personne ne sait utiliser ne produit aucune valeur, quel que soit son niveau de finition.
• Les environnements et l’hébergement, y compris ce que ça coûte tous les mois après.
• Les trois premiers mois d’exploitation, période où l’on découvre ce que les vrais usages révèlent.

Aucune de ces lignes n’est facultative. Elles seront payées : la seule question est de savoir si elles apparaissent au devis ou en avenant.

Ce qu’un bon premier rendez-vous devrait produire

Pas un chiffre. Un périmètre de discussion.

À la fin d’un premier échange utile, vous devriez repartir avec : une idée claire de ce que le prestataire a déjà livré de comparable, les questions qu’il a posées et que vous ne vous étiez pas posées, et une fourchette assumée comme une fourchette.

Si vous obtenez un prix précis en fin de premier rendez-vous, méfiez-vous : soit le sujet est vraiment simple, soit on vous vend un chiffre qui bougera.

Photo : rawpixel — licence CC0.

La question à poser avant le prix

Avant « combien ça coûte », il y a une question plus utile : combien coûte l’absence de cette application ?

Des heures de ressaisie, des erreurs qu’on rattrape, un délai de traitement qui fait perdre des clients, une information que personne ne sait sortir. Quand ce chiffre est posé, la discussion budgétaire change de nature : on ne compare plus un devis à zéro, on compare deux coûts.

C’est aussi ce qui permet de décider quoi mettre dans la première version. Une application qui fait gagner deux heures par jour à cinq personnes se rentabilise vite ; la fonctionnalité qui sert trois fois par an peut attendre.

Le budget d’exploitation, la ligne qu’on oublie

Comptez 15 à 25 % du coût initial par an après la mise en production : supervision, corrections, mises à jour de sécurité, montées de version, et surtout les évolutions que l’usage réel va demander.

Ce n’est pas une rallonge, c’est le coût normal d’une application vivante. Un projet budgété sans cette ligne produit toujours le même scénario : la première année se passe bien, la deuxième voit les demandes s’accumuler sans budget, et la troisième amène la question « pourquoi faut-il refaire l’application ? ».

En résumé

• Une application métier sur mesure : 50 à 400 k€ selon la complexité, pour une première version en production.
• Les interfaces avec l’existant sont le premier facteur de prix.
• Comparez les devis poste par poste, jamais sur le total.
• Prévoyez 15 à 25 % par an d’exploitation et d’évolutions, dès le budget initial.

Et si un prestataire vous donne un prix avant d’avoir cadré : ce n’est pas un prix, c’est une supposition. Elle sera fausse, et l’écart apparaîtra au moment le moins commode.