Combien coûte le développement d'un système web sur mesure en 2026

Le résumé direct

Un système web sur mesure est un logiciel conçu pour un processus précis d'une entreprise, avec sa propre base de données, des utilisateurs aux rôles distincts et une intégration avec ce que l'entreprise utilise déjà ; il se justifie quand le tableur ou le SaaS prêt à l'emploi coûte plus en reprises que ne coûterait le logiciel. Le prix ne sort pas d'une grille, il sort du périmètre. Ce qui fait grimper le coût, ce n'est pas le nombre d'écrans : c'est l'intégration à l'ERP, les permissions fines par utilisateur, la piste d'audit et qui maintient le tout après la mise en production. Un devis forfaitaire sans découverte est une supposition déguisée en contrat, et une supposition se transforme en avenant. Vous trouverez ci-dessous les variables qui forment le prix, les coûts d'exploitation avec des tarifs publics et datés, et la façon de demander des propositions que l'on peut comparer.

1. Pourquoi il n'existe pas de grille tarifaire pour un système sur mesure

Celui qui demande un devis veut un chiffre. Celui qui livre doit savoir ce qu'il y a dedans. La même demande (« un système pour suivre les commandes ») peut devenir trois projets aux coûts très différents :

• Un écran qui liste les commandes d'un tableur importé, deux utilisateurs, tout le monde sur le même identifiant.
• Le même suivi avec quatre services, chacun ne voyant que le sien, avec l'historique de qui a modifié quoi.
• Le même suivi qui récupère le stock de l'ERP en quasi temps réel, avec l'émission de la facture fiscale déclenchée en fin de flux.

Le premier est un CRUD avec authentification. Le troisième implique une file de retraitement, des erreurs de tiers, du rapprochement et une astreinte. Aucune grille ne distingue les trois, parce que la différence n'est pas dans l'interface : elle est dans ce qui se passe quand le système d'en face répond de travers. Celui qui publie une grille fermée vend un petit périmètre et facture le reste en avenants, ou gonfle le prix pour couvrir l'inconnu.

Les questions qui changent le prix plus que le design

Cinq réponses font bouger le prix avant toute estimation : combien de personnes l'utilisent et combien de rôles différents existent ; quels systèmes le logiciel doit lire ou alimenter (ERP, e-commerce, banque, tableur vivant) ; si quelqu'un devra prouver plus tard qui a fait chaque modification ; si le processus est lié à une obligation fiscale ou légale ; et qui s'occupe du système le mois qui suit la livraison.

« Trois personnes, aucun système, pas d'historique, pas de facture, c'est vous qui vous en occupez » donne un autre devis que « quarante personnes dans cinq services, intégration à l'ERP, audit obligatoire, émission de factures, mon service informatique prend le relais ensuite ».

2. Les quatre postes qui font le plus grimper le coût

Intégration à l'ERP

Intégrer, ce n'est pas « brancher l'API ». C'est cohabiter avec l'API de quelqu'un d'autre. La documentation de Bling est explicite sur le plafond : « 3 requêtes par seconde » et « 120 000 requêtes par jour », avec une limite sur le compte entier, pas par endpoint. En cas de dépassement, le retour est HTTP 429, et 600 requêtes en 10 secondes peuvent bloquer l'IP d'origine pendant 10 minutes.

Cela change l'architecture. Une synchronisation qui parcourt mille produits en boucle casse dès le premier jour d'exploitation réelle. Ce qui fonctionne exige une file, du backoff, de l'idempotence et un registre de ce qui a déjà été traité. Ajoutez les règles de filtre : les requêtes avec un intervalle supérieur à un an renvoient 400, ce qui oblige à paginer par fenêtres de dates pour toute reprise d'historique. Chacune de ces contraintes est du code que personne ne voit à l'écran et qui se retrouve dans le prix. Un devis qui traite l'intégration comme « 1 jour » n'a pas lu la documentation.

Multi-utilisateur avec de vraies permissions

Le « multi-utilisateur » se vend comme un identifiant avec mot de passe. Ce qui coûte, c'est la granularité : qui voit quelle ligne.

PostgreSQL règle une partie de cela dans la base, avec la Row Level Security. La documentation officielle décrit la conséquence de l'activation de la fonctionnalité : « If no policy exists for the table, a default-deny policy is used, meaning that no rows are visible or can be modified ». La sécurité devient explicite, politique par politique, commande par commande : plus sûr et plus de travail. La même documentation prévient que les vérifications d'intégrité référentielle, comme les clés uniques et étrangères, ignorent toujours la row security, ce qui exige une modélisation soignée pour ne pas laisser fuiter d'information par un canal indirect.

Externaliser l'identité sort le coût du code pour le mettre dans l'abonnement. Chez Clerk, les rôles personnalisés et les RoleSets ne sont pas dans le plan de base : ils dépendent de l'add-on B2B Authentication, US$ 100 par mois (US$ 85 en annuel), lu le 23/09/2026.

Audit

L'audit, c'est la différence entre « la commande a changé de montant » et « tel utilisateur a changé le montant à 14h32 le 12, de X à Y, depuis cette IP ». Cela suppose une table d'historique, l'immuabilité des anciennes lignes, une politique de rétention et un écran pour consulter sans ouvrir la base. Dès que des données personnelles sont en jeu, ce n'est plus une préférence. La LGPD brésilienne dispose, à l'art. 37, que « le responsable du traitement et le sous-traitant doivent tenir un registre des opérations de traitement de données personnelles qu'ils effectuent », et l'art. 6, VII, exige des mesures techniques et administratives de protection contre les accès non autorisés.

Sur les plateformes, l'audit se trouve dans l'offre supérieure. Chez Supabase, les Platform Audit Logs n'existent qu'à partir du plan Team (US$ 599 par mois), avec une rétention des logs de 7 jours sur Pro. Chez Clerk, les Admin Logs arrivent avec Business (US$ 300 par mois), avec 30 jours. Les deux lus le 23/09/2026. Si l'exigence est de prouver quelque chose dans deux ans, aucune rétention par défaut ne suffit : la piste doit vivre dans votre propre base.

Maintenance après la mise en production

La mise en production ne clôt pas le coût, elle lance le coût récurrent. Les dépendances se mettent à jour, les certificats expirent, l'API de l'ERP change de contrat, le volume grandit, quelqu'un saisit une donnée erronée et veut un rollback. C'est le poste le plus souvent omis dans les devis et celui qui crée le plus de friction six mois plus tard. La question n'est pas « y a-t-il du support », c'est « qu'est-ce qui est inclus, pour combien de temps, et qu'est-ce qui devient payant ».

3. Des fourchettes par type de système, présentées comme du périmètre

Les trois types ci-dessous couvrent la plupart des demandes. Les colonnes ne sont pas des prix : ce sont les variables qui les déterminent.

Le tableau de bord interne est le seul des trois où la plus grande incertitude se trouve dans votre processus, pas dans des systèmes extérieurs. Dans les deux autres, une bonne partie de l'effort est défensive, écrite pour le jour où l'API d'en face renverra une erreur. Le critère « ça vaut le coup ou c'est du gaspillage » est le même que celui de WordPress headless.

4. Le coût qui continue d'arriver : infrastructure et services

Le prix de développement est un événement. Le coût d'exploitation est un abonnement. Séparez les deux, parce que la somme des petits abonnements surprend plus que le prix du projet. Les chiffres ci-dessous proviennent de pages officielles lues le 23/09/2026 et servent de plancher pour un système petit ou moyen.

Deux lectures en ressortent. Le serveur est le plus petit poste de la liste quand le système est interne et le volume modeste : un VPS fait tourner l'application, la base et la file pour le même genre de tableau de bord que le tableur actuel supporte. Des hébergeurs comme Hostinger, Hetzner, DigitalOcean et Contabo opèrent dans cette gamme, et le choix entre eux change moins le budget que la décision d'externaliser ou non.

L'autre : les add-ons de conformité coûtent plus que le serveur. Le PITR chez Supabase (US$ 100/mois) et le rôle personnalisé chez Clerk (US$ 100/mois) additionnés dépassent n'importe quel VPS du tableau. C'est le prix de ne pas écrire ces fonctions soi-même. L'erreur est de le découvrir après avoir signé le périmètre.

Où économiser sans créer de dette

Économie légitime pour un système interne à faible volume : faire tourner l'application et la base sur le même VPS tant que le volume ne justifie pas de les séparer, avec une sauvegarde hors du serveur, et utiliser l'authentification de la stack elle-même quand il n'y a ni SSO d'entreprise ni hiérarchie de rôles. Économie qui se paie avec intérêts : supprimer la piste d'audit (reconstituer un historique qui n'a pas été enregistré est impossible, pas coûteux) et supprimer le suivi des erreurs, parce que sans lui, c'est l'utilisateur qui découvre la panne.

5. Pourquoi un devis forfaitaire sans découverte finit en avenant

Un prix forfaitaire exige un périmètre fermé, et un périmètre fermé exige de connaître le processus. Si personne n'a regardé le tableur actuel, le chiffre du contrat est un pari. Ce que la découverte trouve et que la demande ne dit pas :

• Des règles d'exception qui vivent dans la tête d'une seule personne (« ce client a toujours un délai différent »).
• Des colonnes du tableur avec trois significations selon la ligne.
• Un second fichier que personne n'a mentionné et qui alimente le premier.
• Un rapport manuel que quelqu'un monte chaque vendredi et qui est la vraie raison de la demande.
• Des données historiques sales, qui doivent être migrées avant que le moindre écran fonctionne.

Chacun de ces points, découvert après la signature, devient une conversation inconfortable : soit le développeur l'absorbe et travaille gratuitement, soit il demande un avenant et le client a le sentiment que le prix a changé.

Un plan de découverte qui tiendrait en une semaine

Cinq livrables, sans devenir une mission de conseil : la cartographie du processus du déclencheur au résultat, avec qui fait chaque étape ; l'inventaire des systèmes avec la documentation de chaque API vérifiée, limites de requêtes comprises ; la matrice des rôles (qui voit, qui modifie, qui valide) ; ce qui a besoin d'une piste d'audit et pour combien de temps ; et le périmètre de la phase 1 avec la coupe explicite de ce qui reste pour plus tard. Là, le devis cesse d'être une supposition, et le client repart avec quelque chose d'utile même s'il engage quelqu'un d'autre.

6. Un périmètre par phases, pas un périmètre amputé

Une phase, ce n'est pas livrer moins : c'est livrer dans l'ordre de la valeur. La phase 1 est le plus petit découpage qui remplace le tableur dans le processus principal. Un chemin courant pour un tableau de bord interne qui grandit :

• Phase 1 : saisie et flux principal, rôles minimaux et historique des modifications déjà enregistré.
• Phase 2 : rapports et exports faits à la main aujourd'hui.
• Phase 3 : intégration à l'ERP, en commençant par la lecture avant l'écriture.
• Phase 4 : automatisation de ce qui est devenu répétitif une fois le processus rendu visible.

La piste d'audit est en phase 1 parce que c'est la seule partie qui ne peut pas être ajoutée rétroactivement avec la même valeur. L'intégration est mise à part pour une autre raison : c'est le poste qui a le plus de chances de bloquer pour une cause externe (un identifiant que le comptable n'a pas, une app en attente d'approbation, une limite de requêtes qui change la conception). Le mettre sur le chemin critique de la première livraison, c'est inviter un blocage venu d'un tiers.

7. Comment demander des devis comparables

Une demande vague produit trois propositions qui ne se comparent pas, parce que chacune a supposé un périmètre différent. Ce qu'il faut inclure :

• Le processus du début à la fin, avec le déclencheur et le résultat attendu.
• Combien de personnes l'utilisent et combien de rôles distincts existent.
• Les systèmes qui doivent être lus ou alimentés, avec leur nom et l'offre souscrite.
• S'il y a une exigence d'audit et combien de temps l'historique reste disponible.
• S'il y a une obligation fiscale dans le flux, et qui maintient le système ensuite.
• Le volume actuel en chiffres, même approximatifs (commandes par mois, enregistrements, utilisateurs simultanés).

Ce qu'il faut exiger de chaque proposition :

• La séparation entre coût de développement et coût mensuel d'exploitation.
• Quels services tiers entrent en jeu et combien coûte chacun par mois, avec le lien vers la page de tarifs.
• Ce qui est hors périmètre, par écrit, et à qui revient le code.
• Ce qui se passe quand une API tierce change.

Une proposition qui ne sépare pas développement et exploitation cache un coût récurrent. Une proposition qui ne liste pas ce qui est resté hors périmètre en discutera plus tard, sous pression.

Un prix unique sans aucune de ces réponses n'est pas un devis : c'est un risque caché dans un chiffre.

Questions fréquentes

Pourquoi personne ne me donne de prix au téléphone

Parce que le prix dépend de ce qui n'a pas encore été demandé. Le nombre d'écrans est ce qui varie le moins entre deux projets apparemment identiques ; ce qui varie, c'est l'intégration, les permissions, l'audit et la maintenance. Un chiffre donné avant ces réponses est un coup au hasard, et un chiffre haut protège celui qui l'a lancé tandis qu'un chiffre bas finit en avenant. Répondre aux cinq questions de la section 1 est le chemin le plus rapide vers un montant.

Est-ce moins cher d'adapter un SaaS prêt à l'emploi

Souvent oui, et ce doit être la première hypothèse testée. Le SaaS prêt à l'emploi perd quand le processus a une règle que l'outil n'accepte pas, quand le coût par utilisateur grandit plus vite que l'activité, ou quand les données doivent vivre avec le reste de l'entreprise pour devenir des rapports. Le test consiste à lister les règles de votre processus et à cocher celles que le SaaS couvre sans bricolage.

Que se passe-t-il si je veux changer de développeur plus tard

Cela se règle dans le contrat, pas dans la technologie. Trois clauses suffisent : le code vous appartient et se trouve dans un dépôt à votre nom ; les identifiants des services sont dans des comptes à vous ; et il existe une documentation minimale du déploiement et des variables d'environnement. Sans elles, changer de prestataire coûte presque un redémarrage, et c'est là que le prix bas de la proposition initiale se paie avec intérêts.

Conclusion

Le prix d'un système sur mesure se construit en additionnant des variables de périmètre, pas en consultant une grille. Les quatre qui pèsent le plus sont l'intégration à l'ERP, les permissions par utilisateur, l'audit et la maintenance après la mise en production, et aucune n'apparaît dans la maquette des écrans. Le coût d'exploitation est distinct du coût de développement, il a des tarifs publics et datés, et il doit être écrit dans la proposition. Un devis forfaitaire sans découverte est un pari, et un pari sur un logiciel se paie en avenants.

Si vous voulez un chiffre plutôt qu'une fourchette, envoyez sur oailton.dev/fr/contato le processus qui doit sortir du tableur et le nombre de personnes qui l'utilisent, avec les différents rôles qui existent entre elles. Avec cela et la liste des systèmes qui doivent communiquer, on peut dessiner un périmètre par phases et chiffrer sur une base concrète.