Développement d'application web : ce que coûtent la construction et l'exploitation

Une application web sur mesure est un logiciel qui tourne dans le navigateur et qui est construit autour du processus d'une organisation plutôt que vendu à un grand nombre. La frontière avec un site n'est pas visuelle. Un site publie de l'information ; une application conserve un état, applique des règles et fait un travail : comptes, permissions, enregistrements qui changent et logique qui a des conséquences quand elle se trompe.

Cette différence commande tout le reste : le coût, le calendrier, les obligations de sécurité et le profil du prestataire. Cet article montre où passe réellement la frontière, ce que coûte un développement en 2026 et quelles parties d'un devis tiennent la route.

Le test pratique consiste à se demander si le système a des utilisateurs qui se connectent et des données qui changent du fait de leurs actions. Un système de réservation, un portail revendeur, un outil interne de chiffrage et un flux de sinistres sont des applications. Un site vitrine avec formulaire de contact n'en est pas une, même très bien construit, et cette distinction fixe l'ordre de grandeur du prix.

Trois éléments les séparent sur le plan technique. Une application possède authentification et autorisation, c'est-à-dire qu'elle doit décider non seulement qui vous êtes mais ce que vous avez le droit de voir. Elle possède un état persistant que plusieurs personnes modifient en même temps, ce qui amène transactions, gestion des conflits et journaux d'audit. Et elle porte des règles métier inscrites dans le code plutôt que dans un document, là où part l'essentiel de l'effort de test.

Si aucun des trois ne s'applique, vous regardez un site et ne devriez pas payer un prix d'application.

La plupart des entreprises arrivent à cette question par la douleur et non par la stratégie. Un tableur est devenu le système de référence, trois personnes s'en échangent des versions par courriel, et quelque chose de coûteux a déjà mal tourné. Quatre situations reviennent sans cesse, et chacune justifie d'envisager une application propre plutôt que de continuer à rustiner.

Un tableur pilote un processus réel. Tarification, affectation, planification. Cela tient jusqu'à ce que deux personnes modifient en même temps, ou jusqu'au départ de celui qui a écrit les formules.

Les clients demandent l'accès à leurs propres données. Historique de commandes, documents, avancement. Envoyer des PDF par courriel ne passe pas à l'échelle, et un portail est la réponse habituelle. Notre guide du portail client traite ce cas précis.

Il manque un flux entre deux systèmes. L'ERP tient le stock, le CRM tient les clients, et un humain ressaisit chaque jour de l'un à l'autre.

L'outil du marché couvre 70 % du processus. Les 30 % restants sont exactement là où se trouve votre marge, et aucun paramétrage n'y accède.

Les tarifs des agences européennes, au mois d'août 2026, démarrent autour de €12 000 pour une application vraiment modeste et montent vite ensuite. Contrairement à un site, le nombre d'écrans ne dit rien : ce qui fait le prix, c'est le nombre de rôles utilisateurs distincts, le nombre de systèmes externes impliqués et le caractère réglementé ou non des données.

Une règle utile à la lecture d'un devis : la première version fonctionnelle représente environ la moitié du coût total. L'autre moitié, c'est tout ce qui la rend viable, à savoir la gestion des erreurs, les cas limites de permissions, la reprise des données existantes et les rapports que personne n'a mentionnés au lancement.

Le levier le moins cher sur le prix, ce sont les rôles et non les fonctionnalités. Chaque type d'utilisateur supplémentaire multiplie les cas de permissions à concevoir, développer et tester, et il le fait plus vite qu'un écran de plus.

Les clients imaginent les écrans. Les écrans représentent peut-être un tiers du travail. En dessous se trouvent quatre couches qui figurent rarement dans une proposition et toujours sur la facture. En connaître les noms permet de lire une estimation avec un œil critique et de repérer vite là où une offre bon marché reste creuse.

Modèle de données et reprise. Définir les entités et transférer l'existant, généralement un tableur aux données incohérentes qu'il faut nettoyer avant import.

Authentification et permissions. Rôles, sessions, récupération de mot de passe et matrice de qui a le droit de faire quoi. Court à décrire, long à tester.

Intégrations. Chaque système externe est un projet en soi : identifiants, limites d'appel, gestion des erreurs et plan pour le moment où l'autre côté ne répond plus.

Observabilité. Journaux, alertes et un moyen de répondre à la question de ce qu'a fait le système mardi à 14h20.

Les tests traversent les quatre couches. La vraie question n'est pas de savoir si le parcours nominal fonctionne, mais ce qui se produit sur les autres : un envoi en double, une session qui expire au milieu d'un formulaire, deux personnes sur le même enregistrement, une intégration en dépassement de délai.

Trois à six mois jusqu'à une première version en production est la norme pour une application de taille moyenne. Le calendrier dérape pour des raisons assez prévisibles pour être anticipées, et selon notre expérience deux d'entre elles causent l'essentiel des dégâts. Toutes deux se désamorcent à bas coût avant la signature.

La première est un cadrage mené par entretien plutôt que par observation. Les gens décrivent le processus qu'ils croient suivre. Le vrai comporte des exceptions, et les exceptions sont les exigences. Regarder le travail une journée les trouve ; un atelier généralement non.

La seconde est une intégration avec un système sans propriétaire. L'estimation suppose qu'une API existe et qu'elle est documentée. La semaine six découvre le contraire, et une discussion avec un éditeur se retrouve sur le chemin critique.

Une étude technique d'une semaine avant de figer le prix intercepte presque tout cela.

Acheter l'emporte sur construire la plupart du temps, et toute agence qui prétend le contraire est en train de vendre. Le SaaS gagne sur le prix, sur le délai avant valeur et sur le fait qu'un autre s'occupe des correctifs de sécurité. Trois situations font basculer ce raisonnement, et elles méritent d'être nommées précisément.

Le processus est le facteur de différenciation. Si votre façon de chiffrer, d'orienter ou de tarifer est la raison pour laquelle les clients vous choisissent, l'inscrire dans un outil que tout le monde utilise supprime l'avantage.

Le prix par utilisateur dépasse le développement. À 200 utilisateurs, €40 par poste et par mois représentent €96 000 par an. Un développement amorti sur cinq ans devient alors de l'arithmétique et non de l'ambition.

Les données ne peuvent pas sortir. Localisation, conservation ou règles sectorielles écartent parfois toute plateforme partagée, et les obligations du RGPD sur le traitement et le stockage sont plus simples à satisfaire sur une infrastructure que vous maîtrisez.

Il existe par ailleurs une voie intermédiaire trop souvent écartée : une plateforme configurable surmontée d'une fine couche sur mesure.

Les portfolios montrent des écrans, c'est-à-dire la partie qui révèle le moins. Quatre questions séparent les équipes qui ont exploité du logiciel de celles qui n'en ont que livré, et aucune n'est assez technique pour exiger un développeur dans la pièce.

Montrez-moi quelque chose que vous maintenez encore. Construire est facile ; vivre trois ans avec une décision est la compétence.

Qu'est-ce qui s'est mal passé sur le dernier projet ? Une équipe sans réponse n'a pas assez livré ou ne joue pas franc jeu.

À qui appartiennent le code et les comptes d'infrastructure ? La réponse doit être à vous, par écrit, avec accès au dépôt dès le premier jour.

Que se passe-t-il si nous arrêtons de travailler ensemble ? Documentation, transfert, identifiants. Selon la Stack Overflow Developer Survey, la dette technique figure régulièrement parmi les frustrations les plus citées par les développeurs professionnels, et une partie tient à des systèmes hérités que personne ne sait expliquer.

La sécurité n'est pas une fonctionnalité qu'on ajoute plus tard, et la traiter ainsi est la façon dont un projet à €30 000 devient un projet à €30 000 plus un incident. La base n'a rien d'exotique, et une équipe compétente l'inclut sans qu'on le demande.

L'OWASP Top 10 est la référence réellement utilisée par le secteur : contrôle d'accès défaillant, injection, mauvaise configuration et le reste. Demandez si votre développement la couvre, et demandez quels tests le prouvent.

Au-delà de la base, le coût suit l'obligation. Les données personnelles imposent des règles de conservation, d'export et de suppression. Les paiements imposent de ne pas stocker de données de carte du tout. Les secteurs réglementés imposent journaux d'audit et preuves. Comptez 10 % à 20 % en plus lorsque l'un de ces cas s'applique.

Une obligation s'oublie facilement parce qu'elle n'est pas technique : quelqu'un doit continuer à appliquer les mises à jour après la mise en ligne. Nommez cette personne ou ce contrat avant de signer.