« 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 surtout du temps de développement : 2–3 développeurs sur 8–14 semaines pour une première version allégée, 3–4 développeurs et un référent livraison sur 12–20 semaines pour un produit avec plusieurs rôles, de vraies intégrations et le reporting opérationnel. Ce qui fait bouger le chiffre, ce sont les rôles, les intégrations et le degré de temps réel exigé.
Repères indicatifs pour 2026, pas un devis. Votre devis arrive par écrit, à prix ferme, sous trois jours ouvrés après l'atelier gratuit de 4 heures ; un sprint de discovery payant ne vient d'abord que si le périmètre reste ouvert, et il est intégralement crédité. Les clients suisses et européens le reçoivent en francs ou en euros de leur 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 |
|---|---|---|
| MVP allégé — un parcours central, avec des briques éprouvées où c'est possible | 2–3 développeurs | 8–14 semaines |
| Produit standard — plusieurs rôles, de vraies intégrations, administration et reporting | 3–4 développeurs + un référent livraison | 12–20 semaines |
| Plateforme complexe — multi-tenant, données réglementées, migration en parallèle du système en production | 5+ développeurs, pluridisciplinaire | 20+ semaines |
Repères indicatifs 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. Après un atelier gratuit de 4 heures, vous recevez sous trois jours ouvrés un périmètre écrit et un devis, à prix ferme quand le périmètre est clairement délimité. Si le périmètre reste ouvert, un court sprint de discovery payant vient d'abord, entièrement déduit du prix du développement, et le prix ferme suit.
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 vient un plan de support mesuré en heures par mois. Notre calculateur de coûts estime l'effort de 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 dure quatre heures et ne coûte rien ; sous trois jours ouvrés, vous avez le périmètre et le devis par écrit. Ensuite :
- Sprint de discovery, 1–2 semaines, si le périmètre reste ouvert. 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.
Ce qu'il nous faut de votre part à chacune de ces étapes pour que le calendrier tienne, Minakshi l'a écrit du point de vue de la livraison : faire développer un logiciel, étapes et coûts.
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 la règle, mais seulement après l'atelier : 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 entreprises qui accueillent ces frigos pour leur personnel n'avaient aucun écran à elles. Pour chaque demande (une commande en plus pour un événement d'équipe, les bureaux fermés la semaine prochaine, plus de monde à partir de lundi, ce qui s'est vendu au point de vente B), il fallait écrire à FeelEat. 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. Une entreprise partenaire y passe ses commandes spéciales, indique ses fermetures, signale une hausse ou une baisse de ses effectifs, crée des bons pour son personnel, réserve la dégustation de FeelEat et consulte les ventes de ses propres frigos. Un détail, parce qu'il est typique des web apps : l'isolation multi-tenant est aussi dans la base, pas seulement dans le code. Avec la row-level security dans MySQL, une requête ayant oublié sa clause WHERE ne peut 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.
Depuis, les partenaires font tout cela eux-mêmes dans le portail. 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.
