Estimer le coût réel d'un projet no-code sur trois ans

On va être clair dès le départ : le coût total d’un projet no-code sur trois ans n’a rien à voir avec le petit abonnement affiché sur la page pricing. Vous avez peut-être ce réflexe très répandu : “on part sur du no-code, ça sera moins cher”. Sur la première année, ça peut tenir. Sur trois ans, beaucoup de projets se réveillent avec une facture qui pique.

Entre les licences Bubble, Webflow, Airtable, Make, les intégrations API, les frais Apple/Google, la maintenance, les évolutions métiers et les montées de plan quand les utilisateurs arrivent, le budget réel déborde vite.

L’objectif de cet article est simple : vous donner une méthode concrète pour estimer le coût réel d’un projet no-code sur trois ans, avec des chiffres réalistes, des scénarios et quelques avertissements assez cash pour éviter les mauvaises surprises.

Comprendre ce qu’on appelle vraiment “coût réel” d’un projet no-code

Le résultat avant l’explication : un projet no-code qui semble “raisonnable” à 200 € par mois peut passer à plus de 20 000 € sur trois ans, une fois qu’on ajoute les abonnements, les évolutions et les intégrations.

Des analyses récentes montrent par exemple qu’un SaaS B2B à 500 utilisateurs construit sur Bubble + Make + Airtable tourne autour de 22 300 € de coût total de possession sur trois ans, quand une stack plus légère en code reste sous les 3 500 € environ.

Le coût total de possession (TCO), appliqué au no-code, c’est l’ensemble des dépenses liées au projet sur la durée :

• Le développement initial ou le MVP (agence, freelance, équipe interne)
• Les licences de plateforme et les coûts d’abonnement
• Les intégrations (paiement, emailing, API, monitoring…)
• La maintenance et les petites corrections
• Les évolutions fonctionnelles et les refontes partielles
• Éventuellement les migrations ou la sortie du no-code

Sur trois ans, ce TCO absorbe tout : renouvellement des licences, montée de plan liée au nombre d’utilisateurs, temps passé par les équipes internes, ajustements techniques, travail lié aux changements d’API ou de règlementation. Un projet qui avait l’air “pas cher” la première année devient très gourmand si la stack est mal choisie ou si l’architecture ne prend pas en compte les coûts de performance et de scaling.

On constate souvent que regarder uniquement le budget de livraison du MVP, c’est fermer les yeux sur 70 % de l’histoire.

Les postes de coût à intégrer dès le départ (et que beaucoup oublient)

On ne va pas se mentir : le fameux “c’est bon, on a un abonnement à 30 €/mois” est une illusion dans quasiment tous les projets sérieux. Quand on veut estimer le coût réel d’un projet no-code, il faut empiler plusieurs briques.

D’abord les abonnements aux plateformes no-code. Sur Bubble, les plans payants se situent entre 29 $ et plus de 500 $ par mois selon l’usage et le niveau de service; le plan Growth à 119 $ est couramment cité pour des apps professionnelles avec un volume de requêtes confortable.

Webflow pour un site CMS tourne autour de 23 $ par mois côté hébergement, auxquels on ajoute parfois un Workspace payant pour les designers, à 16–35 $ mensuels selon les sièges. Airtable fonctionne plutôt au prix par utilisateur : 20 $/seat/mois sur le plan Team, 45 $/seat/mois sur le plan Business selon la grille 2026.

Sur une stack type Bubble + Make + Airtable + Webflow + un outil de documentation, des retours d’équipes parlent d’environ 400–450 $ par mois, soit près de 5 000 $ par an rien que pour les licences.

Ensuite arrivent les outils tiers : automation avancée (Make, Zapier), emailing (SendGrid, Mailjet), paiement (Stripe, PSP avec frais fixes), monitoring, logs, data warehouse. Pour un SaaS B2B, il n’est pas rare de voir des briques critiques facturées 100 à 300 $ par mois chacune, avec des cas où certaines API ou services datacenters avoisinent 5 000 $ annuels dès que les volumes augmentent.

Si vous faites du mobile, il faut ajouter les licences Apple et Google : Apple Developer Program à 99 $ par an et Google Play Console avec des frais initiaux puis parfois des coûts associés à certaines fonctionnalités ou services, cités dans les grilles officielles.

La maintenance technique, elle, ne disparaît pas avec le no-code. Des agences spécialisées parlent d’une enveloppe annuelle représentant 10 à 20 % du coût de développement initial pour garder le projet propre (correction de bugs, adaptation aux changements d’API, optimisation de workflows).

Une application développée avec un budget initial de 30 000 € engendre donc assez logiquement 3 000 à 6 000 € par an en maintenance pure, hors nouvelles fonctionnalités.

Sur les évolutions fonctionnelles, les chiffres sont encore plus parlants : plusieurs agences no-code facturent plusieurs milliers d’euros par an pour faire vivre le produit. Entre la création de nouveaux modules, les refontes de parcours et les adaptations métier, le ticket annuel de “product evolutions” s’étale souvent entre 5 000 et 15 000 € pour des SaaS un peu sérieux.

Quand on additionne tout ce qui gravite autour de la plateforme de base, on change de catégorie de budget.

Exemples chiffrés : combien coûte vraiment un projet no-code sur trois ans ?

Les chiffres abstraits, c’est bien. Les scénarios concrets, c’est mieux. Voyons quelques cas typiques pour un budget sur trois ans.

Premier scénario : un petit projet web, type site vitrine ou mini app marketing sur Webflow ou Wix. On trouve des stacks Webflow CMS avec Airtable en back-office qui coûtent autour de 2 000 à 8 000 € la première année (setup + templates + intégrations) et entre 3 000 et 11 000 € pour l’année 1 si on inclut tous les abonnements mentionnés dans certaines études de SEO programmatique.

En étalant sur trois ans, la plupart des cas se stabilisent dans une fourchette de 3 500 à 10 000 € selon le niveau de personnalisation et le volume de pages.

Deuxième scénario : le SaaS B2B à 500 utilisateurs, stack Bubble + Make + Airtable. Un rapport de 2026 cite très précisément un TCO de 22 300 € sur trois ans pour cette configuration, avec les coûts de plateforme, d’intégration et de maintenance inclus, face à un stack “vibe coding” type Lovable + Supabase + Vercel autour de 3 420 € sur trois ans.

Ici, le poids financier réel est concentré dans les abonnements (Bubble en plan intermédiaire, Airtable Team ou Business, Make Core/Pro) et les heures récurrentes pour ajuster l’outillage. Voir un écart de près de 18 900 € pour le même produit, ça remet en cause la phrase “le no-code est toujours plus économique”.

Troisième scénario : projet pris en charge par une agence no-code. Exemple classique : 15 000 € pour la mise en place du MVP, un abonnement mensuel à 600 € pour la stack et la supervision, et un budget d’évolutions de 5 000 € par an. Sur trois ans, on atteint 15 000 + (600 × 36) + (5 000 × 3) = 56 600 €.

Dans ce genre de montage, le vrai poids financier vient du combo abonnement + évolutions; le dev initial devient presque minoritaire sur la durée.

Quatrième scénario : un outil métier sur Airtable pour une PME. Des analyses récentes montrent qu’un passage au plan Business avec 30 seats fait passer un budget annuel de 2 880 $ à 16 200 $, uniquement en licences, pour une équipe qui grandit. Sur un horizon plus long, on tombe facilement sur 4 800 $ par an ou davantage pour une base de travail structurée, ce qui donne des montants de 24 000 $ sur cinq ans, rien qu’en droits d’accès.

Ce type de modèle “à vie” doit être assumé dès le départ.

Si on compare ces scénarios à des solutions plus classiques en développement sur mesure, certains cas montrent un avantage net du no-code sur le court terme, mais un basculement à trois ans selon la croissance et la complexité.

Des grilles comparatives parlent par exemple d’applications custom qui dépassent les 150 000 € sur trois ans face à des stacks no-code autour de 25 000 €, quand, à l’inverse, certaines stacks Bubble/Airtable très chargées finissent plus coûteuses qu’un développement léger.

Comparer no-code et développement traditionnel sur trois ans : l’écart est-il si énorme ?

La vérité qui dérange : le no-code n’est pas “toujours moins cher”. Il déplace le budget et il crée une forte dépendance aux plateformes.

Dans les cas où le projet reste d’une complexité raisonnable, les comparaisons sont flatteuses pour le no-code. Certaines études montrent des TCO à trois ans autour de 25 000 € pour une stack no-code, contre plus de 150 000 € pour un développement sur mesure équivalent, soit plus de 120 000 € d’écart quand on agrège coûts initiaux, maintenance et hébergement. On parle surtout d’applications métier internes, de back-offices et de SaaS de niche.

Le tableau change quand les abonnements explosent. Sur des plans Bubble Team ou Production, les grilles indiquent 349 $ à plus de 849 $ par mois, avec de fortes hausses quand les Workload Units augmentent. Airtable Business à 45 $/seat/mois peut faire passer une équipe de 12 à 30 personnes de 2 880 $ à 16 200 $ par an.

Dans ces configurations, la solution no-code peut dépasser largement un software sur mesure bien dimensionné, surtout si l’on reste sur une architecture simple côté code et qu’on maîtrise la maintenance.

Côté développement traditionnel, les chiffres avancés tournent autour d’un coût initial de 25 000 à plus de 150 000 € selon la complexité, avec une maintenance récurrente estimée à 15–20 % du coût initial chaque année. Une app développée à 60 000 € nécessitera donc typiquement 9 000 à 12 000 € de maintenance annuelle, hors nouvelles features.

Le no-code prend en charge une partie de cette maintenance (mise à jour de la plateforme, sécurité, infrastructure) mais conditionne tout à des abonnements récurrents. Pas d’abonnement, pas d’app.

Prétendre qu’une approche est “toujours meilleure” est une erreur. Le no-code devient une excellente option quand on optimise correctement le stack et qu’on accepte la logique d’abonnements récurrents. Il devient une mauvaise idée quand on empile les outils sans réfléchir à leur modèle économique.

La méthode pas-à-pas pour calculer le budget no-code sur trois ans

Passons au mode très pratique. L’objectif : que vous puissiez ouvrir un tableur, poser vos chiffres et sortir une estimation des coûts no-code qui tient la route.

Je vous propose une structure simple avec trois onglets : “Abonnements”, “Build & maintenance”, “Risques & migration”.

Étape 1 : clarifier le périmètre fonctionnel et les outils pressentis. Plateforme principale (Bubble, Webflow, Softr…), base de données (Airtable, Supabase), automation (Make, Zapier), paiement (Stripe), emailing (SendGrid), analytics (Amplitude, GA4, etc.). Listez tout, même les petits.

Étape 2 : renseigner les abonnements mensuels et annuels pour chaque outil. Pour Bubble, partez sur un plan Starter ou Growth (29 à 119 $/mois), en intégrant la possibilité de passer à Team si les workloads augmentent. Pour Webflow, notez séparément le Site Plan (Basic ou CMS, 14 à 23 $/mois) et le Workspace éventuel.

Pour Airtable, calculez le coût par seat (20 à 45 $/mois) selon votre scénario d’équipe. Faites trois colonnes : année 1, année 2, année 3, et ajoutez un scénario réaliste de croissance des utilisateurs.

Étape 3 : estimer le développement initial. Si vous passez par une agence no-code, des grilles récentes évoquent des coûts de 15 000 à 30 000 € pour un V1 SaaS avec authentification, dashboards, paiement Stripe et contenu dynamique. En freelance, on trouve des builds entre 3 000 et 12 000 € pour des projets plus compacts. Indiquez le montant dans l’onglet “Build & maintenance”.

Étape 4 : chiffrer la maintenance et les petites évolutions. Les benchmarks parlent de 10–20 % du coût initial par an pour maintenir une app à niveau (bugfix, compatibilité, sécurité). Ajoutez à cela un forfait “évolutions” basé sur vos échanges avec des agences ou vos propres estimations; dans les exemples cités plus haut, 5 000 €/an est courant pour des projets avec de la vie produit.

Étape 5 : ajouter les coûts d’API et de services tiers. Regardez les pricing des services que vous ciblez (emails, SMS, logs, paiements, stockage). Pour certains projets, le total de ces API dépasse les 2 000–3 000 € par an; dans des stacks très transactionnelles ou très data, des cas à 5 000 $ annuels sont documentés. Inscrivez ces montants dans l’onglet “Abonnements”.

Étape 6 : inclure les coûts RH : temps des équipes métiers, formation au no-code, éventuelle dépendance à un “no-code maker” interne. Même si ce n’est pas une facture externe, c’est du budget. Certaines équipes consacrent facilement 10–20 jours homme par an à suivre, tester, ajuster l’app.

Étape 7 : prévoir un coussin budgétaire pour les changements de pricing de plateformes et les migrations partielles. Les exemples d’Airtable qui passe de 2 880 $ à 16 200 $ par an lors d’un changement de plan montrent bien le risque. Perso, j’ajouterais au moins 10–15 % de marge sur l’ensemble pour absorber les hausses tarifaires et un éventuel chantier de refonte/migration.

À la fin de la section, votre checklist TCO devrait inclure :

• Coût de développement initial (MVP ou version 1)
• Abonnements plateforme sur 36 mois (avec montée de plan anticipée)
• Coûts d’API et de services tiers sur 36 mois
• Maintenance annuelle (en % du build ou en forfait)
• Budget d’évolutions métiers sur trois ans
• Coûts RH internes (formation, temps métier)
• Marge de sécurité pour changements de pricing et migrations

Les coûts cachés et pièges fréquents des projets no-code à moyen terme

Parlons des choses qui fâchent. Certains projets no-code deviennent des “abonnements perpétuels” dont on ne sort jamais. Si on ne l’accepte pas dès le départ, le réveil peut être violent.

Premier piège : les abonnements qui scalent avec le volume. Bubble facture à la fois un palier de Workload Units et des dépassements; le passage de Starter à Growth puis à Team se produit souvent bien plus vite que prévu dès que l’app trouve son marché.

Airtable limite le nombre de records par base et les automations; le saut vers Business multiplie les coûts par plus de cinq dans un cas analysé, alors que le nombre de seats n’est “que” multiplié par 2,5.

Deuxième piège : les intégrations devenues payantes ou limitées sur certains plans. Des connecteurs qui étaient inclus se retrouvent derrière des options premium ou des tiers; certaines automations doivent passer par des services facturés à la requête. On se retrouve à rajouter Zapier ou Make en plan Pro, alors qu’on pensait rester sur un core simple.

Troisième piège : la stack trop compliquée. Bubble + Airtable + Make + Webflow + 3–4 services annexes, c’est confortable au début. Quand vient l’idée de sortir du no-code ou de basculer une partie du système vers du code sur mesure, les migrations citées dans les retours d’expérience prennent 4 à 10 semaines pour des apps pourtant modestes. Ça fait vite un budget à 15 000–30 000 € pour réécrire proprement.

Quatrième piège : les politiques des stores et des API qui bougent. Apple ajuste ses exigences, Google modifie des règles de sécurité, des fournisseurs API changent leurs contrats ou imposent des plafonds plus stricts. Chaque fois, c’est du travail imprévu, donc des coûts. Considérer que le pricing 2026 restera figé pendant trois ans, c’est se raconter une belle histoire.

Comment optimiser le coût sur trois ans sans sacrifier la qualité du projet

La bonne nouvelle, c’est qu’on peut garder une bonne qualité de projet sans exploser le budget. Mais il faut être stratégique, pas naïf.

Premier levier : le choix rigoureux de la stack. Limiter le nombre d’outils, privilégier des plateformes qui incluent hébergement, sécurité et certaines intégrations, c’est un reflexe simple mais qui économise plusieurs centaines d’euros par mois sur la durée. Certaines analyses montrent des stacks “Frankenstein” à 425 $/mois; en rationalisant, on redescend sous les 300 $ sans perte fonctionnelle.

Deuxième levier : la conception orientée performance et coûts. On parle rarement de “performance no-code”, alors qu’un nombre excessif de workflows, de requêtes et de duplications de données déclenche des hausses tarifaires. Des équipes qui prennent le temps de simplifier leurs automations et de consolider leurs bases réduisent significativement la facture Make/Zapier et évitent les sauts de plan Bubble.

Troisième levier : la négociation avec les agences no-code. Un forfait maintenance clair, des packs d’évolutions, un engagement sur trois ans avec des conditions écrites sur les hausses et les refontes, ça change tout. On passe d’un mode “surprise permanente” à un budget maîtrisé, même s’il est un peu plus élevé sur le papier.

Quatrième levier : l’approche hybride. Quand certains modules explosent les coûts d’abonnement (grosse base Airtable Business, workflows très intensifs sur Bubble), l’idée de basculer ces parties vers du code léger ou des services plus économiques devient très rationnelle.

Des comparatifs montrent que de simples back-ends custom (Supabase + Vercel par exemple) amortissent très bien ces modules lourds tout en gardant le no-code pour les écrans et les workflows métier. Sur trois ans, ce type de compromis fait gagner plusieurs milliers d’euros tout en améliorant la performance.

Construire un budget no-code réaliste et défendable devant un investisseur ou une direction

On arrive au point sensible : comment défendre ce coût total d’un projet no-code devant un CFO, une direction ou un investisseur sans se faire démonter par des expériences passées ratées.

Première étape : structurer le budget en grandes catégories claires. Dans votre document, segmenter en “build initial”, “abonnements récurrents”, “maintenance”, “évolutions”, “risques et contingences” est une façon très lisible de montrer que vous avez pensé au TCO, pas seulement au chèque de départ.

Deuxième étape : présenter les avantages du no-code sur trois ans. Oui, la vitesse de développement no-code est supérieure; certains rapports parlent de 2–4 semaines pour un MVP contre 3–6 mois pour un dev traditionnel. Oui, l’investissement initial est souvent plus bas.

Mais il faut assumer les engagements récurrents : abonnements, limites de performance, dépendance à la plateforme. Faire comme si ces coûts récurrents n’existaient pas décrédibilise votre analyse coût-bénéfice.

Troisième étape : intégrer plusieurs scénarios de croissance. Scénario “modéré” avec peu d’utilisateurs supplémentaires, scénario “forte croissance” où les plans changent (Bubble Growth → Team, Airtable Team → Business), scénario “sortie du no-code” avec un budget de migration estimé à 4–10 semaines de dev pour une app Bubble/Airtable classique. Le décideur voit alors non seulement le budget sur trois ans, mais les risques associés.

Quatrième étape : s’appuyer sur quelques benchmarks chiffrés crédibles. Mentionner des ordres de grandeur issus d’études récentes (TCO Bubble + Make + Airtable à 22 300 € sur trois ans pour 500 utilisateurs, maintenance à 10–20 % du coût initial, licences Airtable qui passent de 2 880 à 16 200 $ par an selon le plan) rassure sur le sérieux de votre estimation. Ne visez pas la précision au centime, visez le réalisme et la transparence.

Dernier conseil personnel : si vous devez prendre une décision dans les semaines qui viennent, prenez une heure pour construire votre tableur TCO avec les éléments de ce guide, puis challengez-le avec quelqu’un qui a déjà vu un projet no-code déraper.

Vous verrez vite si votre budget sur trois ans tient la route ou s’il repose sur l’espoir que “tout ira bien” — et vous serez beaucoup plus à l’aise pour défendre votre projet devant une direction qui regarde surtout les coûts à long terme.

FAQ rapide sur le coût des projets no-code

Questions fréquentes

Comment calculer le coût d’un projet no-code ?

On additionne le développement initial (MVP ou V1), les abonnements à la stack (Bubble, Webflow, Airtable, Make, etc.), les coûts d’API et services tiers, la maintenance annuelle, les évolutions fonctionnelles et un coussin pour les hausses de pricing et les migrations. L’ensemble sur 36 mois donne un TCO réaliste.

Quels sont les coûts cachés du no-code ?

Les montées de plan liées aux utilisateurs et aux workflows, les intégrations devenues payantes, la complexité de la stack qui renchérit les migrations, et le temps des équipes internes pour suivre l’outil. C’est souvent là que le budget explose.

No-code ou développement sur-mesure : que choisir pour une PME ?

Pour une application métier de complexité modérée, le no-code garde un avantage net sur le court terme et reste pertinent sur trois ans si la stack est bien maîtrisée. Pour des besoins très spécifiques, avec forte croissance et exigences de performance, une approche hybride ou sur-mesure devient souvent plus rentable.

Comment anticiper les coûts de maintenance d’une application no-code ?

Vous pouvez partir sur une estimation de 10–20 % du coût initial par an si vous externalisez la maintenance, en ajoutant un budget distinct pour les évolutions métier et en surveillant les changements de pricing des plateformes pour ajuster votre enveloppe au fil du temps.

Pourquoi regarder le budget sur trois ans plutôt que sur la première année ?

Parce que la première année ne montre que le build et les abonnements de départ. Sur 36 mois s'ajoutent le renouvellement des licences, les montées de plan liées au nombre d'utilisateurs, la maintenance, les évolutions métier et le temps des équipes internes. L'article rappelle que regarder uniquement le budget de livraison du MVP revient à fermer les yeux sur une grande partie de l'histoire.

Quels postes oublie-t-on le plus souvent dans une estimation ?

Les API et services tiers (emailing, SMS, logs, paiement, stockage), les coûts RH internes comme la formation et le temps métier, et la marge de sécurité pour absorber les hausses de tarifs ou une migration partielle. L'article conseille aussi d'anticiper la maintenance, évaluée en pourcentage du coût de développement initial, et un budget distinct pour les évolutions fonctionnelles.

Comment limiter la facture sans dégrader le projet ?

Quatre leviers sont décrits : choisir une stack resserrée plutôt qu'un empilement d'outils, concevoir en limitant les workflows, les requêtes et les duplications de données qui déclenchent les hausses de plan, négocier avec l'agence un forfait de maintenance et des packs d'évolutions écrits, et adopter une approche hybride en sortant du no-code les modules les plus gourmands.