Combien coûte une application web sur mesure ?

La réponse courte, et pourquoi elle ne suffit pas

Une application web sur mesure coûte entre 5 900 € HT et quelques dizaines de milliers d’euros. Cette fourchette est si large qu’elle n’aide personne — sauf à comprendre une chose : le prix ne dépend pas de la taille de l’écran, il dépend du nombre de décisions que le logiciel doit prendre à votre place.

Un outil qui affiche une liste et permet de la modifier coûte peu. Le même outil, s’il doit gérer trois profils d’utilisateurs aux droits différents, se synchroniser avec votre logiciel de facturation, reprendre huit ans d’historique et continuer de fonctionner un vendredi soir quand l’API d’en face tombe, coûte cinq fois plus. Rien de tout cela ne se voit sur une maquette.

Trois repères concrets

Voici les trois situations que je rencontre le plus souvent, avec les fourchettes que je pratique.

Ces montants correspondent au marché français du développement indépendant. Une agence structurée facture généralement 1,5 à 2 fois plus pour un périmètre équivalent : c’est le prix des frais de structure, du chef de projet et du commercial — utile dans certains contextes, inutile dans beaucoup d’autres.

Les sept postes qui font vraiment le budget

1. Le nombre de rôles d’utilisateurs

C’est de très loin le premier facteur, et celui que les clients sous-estiment le plus. Une application avec un seul type d’utilisateur est simple. Dès qu’il y a un administrateur, un gestionnaire et un consultant, il faut décider pour chaque écran et chaque action qui a le droit de faire quoi — puis le développer, puis le tester. Passer d’un rôle à trois ne multiplie pas le travail par trois, mais il l’augmente nettement plus que ce que le bon sens suggère.

2. Les connexions à vos outils existants

Chaque système tiers à connecter — logiciel de facturation, messagerie, agenda, ERP, prestataire de paiement — est un projet miniature : lire la documentation, gérer l’authentification, prévoir ce qui se passe quand l’autre système est indisponible, et tester tout cela. Comptez de une à trois journées par connexion quand l’API est bien documentée, davantage quand elle ne l’est pas.

Le cas le plus coûteux est le logiciel métier ancien sans API, où l’échange passe par des fichiers déposés sur un serveur. C’est faisable, c’est même fréquent, mais il faut le chiffrer honnêtement.

3. La reprise de vos données existantes

Vos huit ans de données dans un tableur ne se transfèrent pas d’un clic. Il faut les nettoyer, réconcilier les doublons, arbitrer sur les lignes incomplètes, et vérifier le résultat. Sur les projets que je livre, c’est régulièrement 10 à 20 % du budget total — et c’est le premier poste que les devis les moins chers suppriment discrètement.

4. Le niveau d’exigence sur la fiabilité

Un outil interne utilisé par cinq personnes aux heures de bureau, et une application sur laquelle repose votre chiffre d’affaires 24 heures sur 24, ne se construisent pas de la même façon. Sauvegardes vérifiées, surveillance, gestion fine des erreurs, tests automatisés, procédure de retour arrière : ces éléments peuvent représenter 20 à 30 % du budget. Ils sont superflus dans le premier cas, indispensables dans le second.

5. Les tests et la recette

Une application se teste à trois niveaux : le développeur vérifie son code, vous vérifiez que le logiciel fait ce que vous aviez demandé, et les utilisateurs finaux vérifient qu’ils peuvent travailler avec. Ce troisième niveau est celui qu’on saute quand le budget serre — et c’est celui qui révèle les vrais problèmes.

6. La documentation et la formation

Une demi-journée de prise en main et une documentation écrite pour vos usages précis représentent une à deux journées de travail. C’est peu au regard du budget total, et c’est ce qui décide si l’application est réellement utilisée trois mois plus tard. Une application non adoptée coûte 100 % de son prix pour 0 % de bénéfice.

7. Le design

Il arrive en dernier de cette liste, volontairement. Sur un outil métier, l’interface doit être claire, dense et rapide à parcourir au clavier : c’est un travail d’ergonomie, pas de direction artistique, et il est compris dans le développement. Sur un produit destiné à des clients, le design devient un véritable poste, parce qu’il porte une partie de la valeur perçue.

Ce que doit contenir un devis sérieux

Un devis d’application web qui tient en une page avec un montant global n’est pas un devis : c’est une intention. Voici ce que vous devez y trouver, et ce que je fais systématiquement figurer dans les miens.

• Le périmètre fonctionnel écrit, fonctionnalité par fonctionnalité, dans un langage que vous comprenez sans moi.
• Le découpage en lots, avec un prix par lot, pour que vous puissiez en retirer un si le budget serre.
• La liste des rôles d’utilisateurs et de ce que chacun a le droit de faire.
• La liste des systèmes tiers à connecter, avec le sort réservé aux pannes de chacun.
• Le sort des données existantes : reprises, partiellement reprises, ou repartir de zéro — et le coût de chaque option.
• Ce qui est explicitement hors périmètre. C’est la section la plus utile du devis, et la plus rare.
• Les modalités de recette : qui valide, sur quels critères, dans quel délai.
• La garantie après livraison : durée pendant laquelle les corrections d’anomalies sont comprises.
• La propriété du code et des accès, noir sur blanc.
• Le coût annuel estimé d’hébergement et de services, pour que vous ne le découvriez pas au premier renouvellement.

Pourquoi deux devis varient du simple au triple

Parce qu’ils ne décrivent pas le même projet. Quand un client me montre trois propositions dont les totaux vont de 6 000 à 22 000 €, la lecture ligne à ligne révèle presque toujours la même chose :

• Le moins cher ne reprend pas les données existantes.
• Il prévoit un seul rôle d’utilisateur là où le métier en demande trois.
• Il ne comporte ni tests ni recette formelle.
• Il ne dit rien de la formation ni de la documentation.
• Il ne précise pas qui héberge, ni à quel nom.

Ce n’est pas nécessairement de la malhonnêteté : c’est souvent une lecture optimiste du besoin. Mais le travail supprimé du devis ne disparaît pas du projet — il réapparaît en avenants, ou il ne sera jamais fait, et vous le découvrirez à l’usage.

Le test des trois questions Avant de signer, posez ces trois questions à chaque prestataire : que se passe-t-il si le système tiers ne répond pas ? Qui a accès à quoi, rôle par rôle ? Et que deviennent mes données actuelles ? Les réponses — leur précision autant que leur contenu — vous en diront plus que le montant.

Forfait ou régie : comment choisir

Le forfait convient quand le périmètre est clair et que vous voulez un prix ferme. C’est le bon montage pour une première version d’outil métier, où l’on sait à peu près ce qu’on veut. Le risque est porté par le prestataire, qui le compense par une marge de sécurité : un forfait est structurellement un peu plus cher qu’une régie bien menée.

La régie, facturée à la journée — 450 € HT dans mon cas — convient quand le périmètre va évoluer, quand vous renforcez une équipe existante, ou quand vous préférez arbitrer semaine après semaine ce qui est développé. Vous payez le temps réel, vous gardez la main sur les priorités, et vous portez le risque.

Le mauvais montage, c’est le forfait sur un périmètre flou. Il produit mécaniquement des avenants, des discussions sur ce qui était « compris ou pas », et de la méfiance des deux côtés. Quand un projet arrive dans cet état, je préfère commencer par une phase de cadrage facturée à part : deux à trois journées qui transforment un besoin flou en périmètre chiffrable.

Le coût après la livraison

Un projet ne s’arrête pas à la mise en ligne. Trois postes à budgéter pour l’année suivante :

• Hébergement et services : de 20 à 200 € par mois selon le trafic, la base de données et les services tiers utilisés. Pour un outil interne de quelques dizaines d’utilisateurs, on est dans le bas de la fourchette.
• Maintenance corrective et sécurité : comptez 10 à 20 % du coût initial par an. Les bibliothèques utilisées publient des correctifs, les navigateurs évoluent, les API tierces changent. Une application laissée trois ans sans suivi devient coûteuse à rattraper — exactement comme un site WordPress non maintenu.
• Évolutions : entièrement à votre main, facturées au temps passé. En pratique, la première année d’usage fait remonter une liste de petites améliorations qui valent largement leur coût, parce qu’elles viennent des utilisateurs.

Comment réduire le budget sans saboter le projet

Il y a de bonnes et de mauvaises façons d’économiser.

Ce qui marche : réduire le périmètre de la première version à la fonction qui fait vraiment gagner du temps, et garder le reste pour plus tard. Repousser la reprise de l’historique et démarrer sur les données courantes. Accepter une interface sobre plutôt qu’un design signé. Utiliser un service existant pour ce qui n’est pas votre valeur ajoutée — authentification, envoi d’e-mails, paiement — au lieu de le redévelopper.

Ce qui ne marche pas : supprimer les tests, supprimer la formation, ou choisir le devis le moins cher sans comparer les périmètres. Ces trois économies se paient à trois, six et douze mois, avec intérêts.

À retenir

• Comptez 5 900 à 12 000 € HT pour un outil métier interne, 9 000 à 15 000 € HT pour un premier produit client, plus de 20 000 € HT pour une plateforme complète.
• Le prix dépend d’abord du nombre de rôles d’utilisateurs, des connexions aux systèmes existants et de la reprise des données — pas du design.
• La reprise des données représente souvent 10 à 20 % du budget, et c’est le premier poste que les devis les moins chers retirent en silence.
• Un devis sérieux écrit le périmètre lot par lot, dit ce qui est hors périmètre, et précise à qui appartiennent le code et les accès.
• Budgétez 10 à 20 % du coût initial par an pour la maintenance, plus l’hébergement.
• Réduire le périmètre de la première version est une bonne économie ; supprimer les tests et la formation n’en est pas une.