« On a juste besoin d'un tableau de bord. » Presque toutes les discussions sur une web app commencent ainsi, et la phrase est presque toujours fausse. Pas par naïveté : le tableau de bord est la seule partie que l'on voit. En dessous se trouvent la connexion, les rôles, les droits, les tenants, la facturation, et la question de savoir qui a le droit de voir quelle ligne.
C'est surtout cette partie invisible que vous payez.
Faire développer une web app : la réponse courte
Faire développer une web app coûte $30,000–55,000 pour une première version allégée en 8–14 semaines, et $55,000–110,000 pour un produit avec plusieurs rôles, de vraies intégrations et le reporting opérationnel, en 12–20 semaines. Ce qui fait bouger le chiffre, ce sont les rôles, les intégrations et le degré de temps réel exigé.
Fourchette indicative, pas un devis — le chiffre ferme sort d'un sprint de discovery payant et est crédité sur la réalisation. Les chiffres ici sont en dollars américains ; les missions suisses et européennes sont chiffrées en francs suisses ou en euros depuis les éditions correspondantes de la même grille 2026, remises par votre interlocuteur.
Site web ou web app ? Cette frontière décide du prix
Un site web affiche du contenu. Une web app conserve un état : vous vous connectez, vous modifiez quelque chose, et à la visite suivante la modification est toujours là, pour vous et pour les bons collègues. Décider qui fait partie des bons collègues, c'est le modèle de droits. C'est là que passe l'essentiel de mon temps chez CODT Technologies, et cela ne se voit dans aucune démonstration.
Si vous faites développer une web app, voici les quatre éléments qui déterminent la charge, et le design n'en fait pas partie :
- Les rôles. Deux rôles, c'est une condition dans le code. Six rôles avec des exceptions, c'est un modèle de droits qu'il faut tester, parce qu'une erreur dedans montre à un client les données d'un autre.
- Les intégrations. Chaque système tiers arrive avec sa propre authentification, ses propres pannes et sa propre limite d'appels par minute. L'intégration est rarement le point difficile. Gérer ses mauvais jours, en revanche, oui.
- Le temps réel. « En direct » coûte plusieurs fois « à jour au rechargement », et c'est un coût récurrent qui ne disparaît plus jamais.
- Les données réglementées. Données de santé, de paiement ou de RH imposent une journalisation d'audit, des durées de conservation et une politique de suppression. Rien de tout cela n'apparaît dans une maquette cliquable.
Si votre projet est au fond un formulaire que trois personnes remplissent chaque semaine, avec un tableur derrière, prenez un outil no-code et gardez votre argent. Ne nous le donnez pas. Le construire sur mesure est l'option la plus chère qui existe pour ce cas. Nous avons détaillé quand construire l'emporte sur acheter.
Ce que coûte chaque forme de projet
| Forme du projet | Équipe | Durée | Fourchette indicative |
|---|---|---|---|
| MVP allégé — un parcours central, avec des briques éprouvées où c'est possible | 2–3 développeurs | 8–14 semaines | $30,000–55,000 |
| Produit standard — plusieurs rôles, de vraies intégrations, administration et reporting | 3–4 développeurs + un référent livraison | 12–20 semaines | $55,000–110,000 |
| Plateforme complexe — multi-tenant, données réglementées, migration en parallèle du système en production | 5+ développeurs, pluridisciplinaire | 20+ semaines | $120,000–250,000+ |
Fourchettes indicatives pour 2026, pas un devis. Ce qui fait bouger le chiffre, c'est la complexité — intégrations, conformité, migration de données et le niveau de fiabilité qu'il vous faut dès le premier jour. Chaque projet est chiffré de manière ferme et par écrit après un sprint de discovery payant, et ce sprint est intégralement crédité sur la réalisation.
Reste le coût d'exploitation, que le premier budget oublie presque toujours. Le support annuel représente typiquement 15–20 % du coût initial de réalisation. Chez nous, les 30 premiers jours après la mise en production sont sous garantie ; ensuite un plan de support démarre à $550 par mois. Notre calculateur de coûts chiffre votre configuration en deux minutes, et si la web app doit être vendue par abonnement, le guide des coûts SaaS est plus proche du sujet. Les applications natives relèvent d'un autre calcul, et nous l'avons détaillé là.
Le déroulé, étape par étape
Le premier atelier et une estimation de principe ne coûtent rien — en général sous trois jours ouvrés. Ensuite :
- Sprint de discovery, 1–2 semaines, $2,900–4,900. Vous repartez avec un périmètre écrit, une architecture système, une feuille de route chiffrée et une liste explicite de ce que nous ne construirons pas — elle vous appartient, et c'est le document à partir duquel le devis ferme est rédigé. Le sprint est intégralement crédité sur la réalisation.
- Fondations. Tenants, connexion, rôles, pipeline de déploiement, préproduction. Pour le client, c'est la phase la plus ennuyeuse du projet, parce qu'il n'y a presque rien à regarder. Elle décide pourtant des années suivantes.
- Parcours principaux. Une version fonctionnelle en préproduction toutes les deux semaines, que vos équipes peuvent vraiment utiliser.
- Durcissement. Tests de charge, tests de droits, chemins d'erreur, restauration depuis une sauvegarde. C'est la phase que l'on comprime en premier quand une date glisse.
- Mise en production, puis 30 jours de garantie.
Deux points commerciaux à connaître à l'avance. Le livrable et le code source vous appartiennent au paiement. 100 % des droits sont transférés — aucun verrouillage, aucune licence par siège. Et un prix ferme est possible, mais seulement après le sprint de discovery payant : un prix ferme établi sur la base d'un e-mail de demande est supposé plutôt que calculé, quel que soit celui qui le signe.
Un portail partenaires où l'on peut vérifier le calcul
FeelEat exploite des frigos connectés en Suisse et les approvisionne depuis sa propre cuisine. Les partenaires B2B qui gèrent ces flottes n'avaient aucune vue sur leurs propres données. Chaque question (pourquoi ce frigo est-il vide, qu'est-ce qui se vend au point de vente B, quand faut-il réapprovisionner) passait par un appel au support. En interne, il y avait des tableaux de bord. Les partenaires avaient l'e-mail.
Nous avons construit un portail multi-tenant : React côté interface, Node.js avec NestJS derrière, stocks par frigo en temps réel, prévision de la demande, analyse du chiffre d'affaires par frigo et par produit. Deux détails, parce qu'ils sont typiques des web apps. Des centaines de frigos par partenaire interrogeant l'API toutes les 30 secondes l'auraient mise à genoux : une couche de lecture en cache Redis est donc passée devant, et seuls les frigos activement consultés sont poussés en WebSocket. L'isolation multi-tenant est aussi dans la base, pas seulement dans le code : row-level security dans MySQL, pour qu'une requête ayant oublié sa clause WHERE ne puisse pas renvoyer les lignes d'un autre partenaire. Les fondations de plateforme sont mon travail chez CODT Technologies, et cette double isolation est la seule chose que je refuse d'échanger contre de la vitesse de livraison.
La première version de la prévision de la demande était moins bonne que les responsables d'exploitation expérimentés. Il a fallu la saisonnalité, le jour de la semaine et des signaux de demande par emplacement avant qu'elle atteigne 94 % de précision de réapprovisionnement.
Ce que nous avons pu mesurer ensuite : appels au support en baisse de 68 %, environ 320 appels évités par mois, plus de 180 utilisateurs partenaires actifs par jour, un NPS passé de +38 à +71. L'étude de cas complète est ici.
Trois décisions qui tombent dès la première semaine
- La multi-tenance. « On le fera plus tard » est la phrase la plus chère du projet, parce que l'hypothèse qu'il n'existe qu'une seule organisation se répand dans les requêtes, les caches, les tâches de fond et les chemins de fichiers. Pourquoi cela devient une reconstruction et non un refactoring.
- L'identité et les rôles. Votre propre gestion d'utilisateurs, ou le login d'entreprise de vos clients. Ajouter le second plus tard est faisable, mais cela touche chaque vérification de droits écrite jusque-là.
- La facturation. Si de l'argent change de mains, le modèle doit passer avant la première ligne de code. La facturation par siège, par tenant et à l'usage implique chacune une forme de tenance différente et un jeu de vérifications de droits différent, et poser l'une sur l'autre après coup revient à les rouvrir toutes.
Comment nous commençons
Vous décrivez qui va utiliser la web app et ce que ces personnes font à la place aujourd'hui. Dès le premier échange, nous vous disons quelle partie vous feriez mieux d'acheter plutôt que de construire. Un NDA précède toute discussion technique. Un contrat de sous-traitance et les clauses contractuelles types sont signés par défaut. La façon dont nous construisons ce type d'application est décrite sur notre page développement d'applications web.
