Build vs buy : le seuil a changé, pas les règles

Pendant vingt ans, la réponse par défaut était claire : sauf si c'est du cœur de métier, achetez un SaaS. La question ne se posait pas vraiment. Construire un outil interne coûtait cher, prenait du temps, et finissait souvent abandonné faute de ressources pour le maintenir.

En 2026, ce consensus commence à se fissurer.

Selon le rapport Retool publié en février¹, 35 % des équipes tech ont déjà remplacé au moins un outil SaaS par un développement custom, et 78 % prévoient de construire davantage d'outils internes sur l'année. La montée en puissance des outils de développement assistés par IA — vibe coding, Claude Code, Cursor — a fait chuter le coût d'entrée. Une app qui demandait six mois et 100k€ il y a trois ans peut aujourd'hui être livrée en quelques semaines.

Mais "moins cher à construire" ne veut pas dire "moins cher à posséder". Et c'est là que le calcul devient sérieux.

La vieille règle tenait debout pour de bonnes raisons

Le raisonnement classique était solide : si un SaaS couvre 80 % de vos besoins, achetez-le. L'effort de construction pour gagner les 20 % restants coûte généralement cinq fois plus cher². Pendant ce temps-là, vos développeurs ne travaillent pas sur votre produit.

Cette logique s'appuyait sur trois constats réels :

Le premier, c'est le coût d'opportunité. Chaque sprint passé à construire un outil interne est un sprint qui n'améliore pas votre produit principal. Pour une startup de dix personnes, l'arbitrage est brutal.

Le deuxième, c'est la fiabilité. Un SaaS mature, utilisé par des milliers de clients, est mieux testé que n'importe quel outil maison. La sécurité, les mises à jour, le support : tout est pris en charge.

Le troisième, c'est la vitesse. Vous êtes opérationnel en heures, pas en semaines.

Ces trois constats restent vrais. Ce qui a changé, c'est l'équation financière du côté "build".

Ce que l'IA a réellement déplacé

Les outils de développement IA ont compressé le coût de construction initiale. Sur un outil interne de complexité moyenne — gestion de workflow, dashboard opérationnel, interface de traitement de données — un studio comme le nôtre peut livrer en une à deux semaines ce qui prenait deux à trois mois. Le coût de développement initial a chuté de 60 à 80 % selon la catégorie de projet.

C'est réel. C'est documenté. Et ça change le point d'équilibre.

Concrètement : si vous payez 800 € par mois pour un outil SaaS, vous dépensez 48 000 € sur cinq ans. Si ce même outil peut être construit pour 8 000 € avec une supervision sénior correcte, le retour sur investissement brut semble évident. Sauf que le calcul s'arrête rarement là.

Le piège du TCO que tout le monde sous-estime

La construction initiale ne représente que 25 à 35 % du coût total de possession sur trois ans³. Le reste, c'est ce qui vient après :

• Maintenance : budget 15 à 20 % du coût initial par an⁴. Un outil construit à 10 000 € vous coûte 1 500 à 2 000 € par an rien que pour rester fonctionnel (mises à jour des dépendances, compatibilité des APIs tierces, corrections de bugs).
• Évolutions : les utilisateurs internes ont des demandes. "On peut ajouter l'export Excel ?" "Ça marchera avec le nouveau CRM ?" Si personne n'est responsable du backlog, l'outil se fige — et finit par ne plus être utilisé.
• Gouvernance et sécurité : un SaaS avec SOC 2 vous offre une base de sécurité que vous devrez reconstruire you-même pour un outil custom. Gestion des accès, audit logs, chiffrement au repos : chaque élément a un coût d'implémentation et de maintenance.
• Documentation et onboarding : si l'outil n'est pas documenté, c'est la personne qui l'a construit qui devient le support. Et quand elle part, l'outil meurt.

La formule à appliquer est simple — et souvent ignorée :

TCO build (5 ans) = coût initial + (coût initial × 0,175 × 4 ans) + infrastructure

Pour un outil à 12 000 € de construction, ça donne environ 20 000 à 22 000 € sur cinq ans. Toujours rentable face à un abonnement de 300 €/mois (18 000 € sur cinq ans) ? Peut-être pas autant qu'espéré. Et franchement pas si l'abonnement SaaS est à 150 €/mois.

Les trois questions qui structurent la décision

Avant tout calcul, trois questions filtrent 80 % des cas.

1. Est-ce du cœur de métier ou du contexte ?

C'est le filtre le plus important. Un outil qui constitue votre avantage concurrentiel — qui fait quelque chose que vos concurrents ne peuvent pas répliquer en achetant un SaaS — mérite d'être construit. Un outil de CRM, de gestion de projet ou de facturation pour usage interne standard n'a rien de différenciant : achetez.

Le CEO de Retool le formule clairement dans leur rapport¹ : "Les entreprises qui peuvent construire leurs outils différenciants sur mesure auront un avantage compétitif." La nuance est là : leurs outils différenciants, pas tous leurs outils.

2. Le SaaS existant couvre-t-il plus de 80 % de vos besoins ?

Si oui, achetez. Construire pour gagner 20 % de personnalisation supplémentaire coûte généralement bien plus que les économies réalisées. L'exception : quand ce 20 % restant est précisément ce qui fait votre valeur opérationnelle, et que les compromis imposés par le SaaS créent de la friction réelle au quotidien.

3. Avez-vous la capacité opérationnelle de posséder cet outil ?

"Construire un outil interne, c'est devenir une société logicielle pour cet outil⁴." Vous avez besoin de quelqu'un pour maintenir le backlog, répondre aux demandes, déployer les mises à jour. Si ce n'est pas identifié avant la construction, l'outil finira dans un coin, cassé ou figé sur la version du jour de livraison.

Les cas où construire gagne clairement

Quelques configurations où le build l'emporte de façon nette :

Abonnements multiples qui couvrent un seul workflow fragmenté. Vous payez trois SaaS à 200 €/mois chacun pour couvrir un processus que vous pourriez unifier dans un seul outil custom. Le TCO sur cinq ans d'un outil construit une fois est inférieur aux 36 000 € d'abonnements cumulés — et vous récupérez de la fluidité opérationnelle.

Données sensibles qui ne peuvent pas transiter chez un tiers. Certains secteurs (santé, finance, juridique) ont des contraintes de souveraineté des données que les SaaS grand public ne satisfont pas facilement. Construire son propre outil avec les bons choix d'hébergement (cloud souverain français ou on-premise) devient une obligation, pas une option.

Workflows vraiment propriétaires. Si votre processus est genuinement unique — une combinaison d'étapes métier que personne d'autre ne fait exactement comme vous — un SaaS généraliste vous fera toujours travailler à côté du problème plutôt que dedans.

Outil à fort volume d'usage. Les abonnements SaaS facturés à l'usage ou au siège deviennent prohibitifs à l'échelle. Un outil custom bien dimensionné a un coût marginal proche de zéro une fois construit.

Ce que change concrètement l'IA dans ce calcul

Le recours à un studio IA comme NXL Forge déplace le point d'équilibre sur deux axes.

Le premier, c'est le coût initial. Sur les projets que nous livrons, le coût de construction descend dans une fourchette où des SaaS à 300-600 €/mois deviennent économiquement battables dès 18 à 24 mois, même en intégrant la maintenance. L'estimateur de coût permet de chiffrer un projet en moins de cinq minutes.

Le second, c'est le temps de validation. Avant, le risque principal du build était d'investir trois mois et 80k€ pour découvrir que le besoin était mal posé. Avec une livraison en deux semaines, vous pouvez tester, ajuster, ou décider d'abandonner sans avoir brûlé une partie significative du budget.

Ce que ça ne change pas : la maintenance reste à votre charge. Le code est auditable, transféré, documenté² — mais c'est à vous de décider si vous l'internalisez, le confiez à un prestataire ou négociez un contrat de maintien en condition opérationnelle.

Le vibe coding ne suffit pas

Un point à ne pas esquiver : construire vite n'est pas construire correctement. Les outils de vibe coding ont réduit la barrière d'entrée, mais ils ont aussi produit une vague d'outils internes sous-architecturés, sans tests, sans gestion des erreurs, qui se comportent bien en démo et plantent en production.

La différence entre un outil livré en deux semaines qui tient la route et un prototype qu'on n'ose pas mettre en production, c'est la supervision sénior. Pas le modèle IA utilisé.

C'est précisément la raison pour laquelle le "build moins cher grâce à l'IA" ne peut pas être dissocié de la question "construit par qui, avec quel niveau de supervision".

Ce qu'on garde comme règle de décision

Le filtre reste simple :

• Si c'est du contexte standard (CRM, support, facturation, communication), achetez un SaaS. Concentrez vos ressources sur ce qui vous différencie.
• Si c'est du cœur de métier, ou si la somme de vos abonnements pour un workflow fragmenté dépasse 500-600 €/mois, posez le calcul TCO sérieusement.
• Si vous construisez, assumez la ownership : maintenance, gouvernance, évolutions. Sans ça, vous créez de la dette, pas un actif.

Ce qui a changé en 2026, c'est que le seuil de rentabilité du build a baissé. Pas que les règles de fond aient disparu.

---

Vous voulez chiffrer un projet ? L'estimateur de coût NXL Forge donne une estimation en quelques minutes.

---

Footnotes

1. Retool 2026 Build vs. Buy Report, Business Wire, 17 février 2026 — "35 % of teams have already replaced at least one SaaS tool with a custom build and 78 % expect to build more custom internal tools in 2026." https://www.businesswire.com/news/home/20260217548274/en/Retools-2026-Build-vs.-Buy-Report-Reveals-35-of-Enterprises-Have-Already-Replaced-SaaS-With-Custom-Software ↩ ↩²

2. SaaS vs Custom Software 2026, Codivox, mars 2026 — "If existing SaaS covers 80%+ of your needs, buy it. Custom-building what already exists is the most expensive mistake." https://codivox.com/blog/saas-vs-custom-software-2026/ ↩ ↩²

3. AI Agent Development Cost 2026, AlphaCorp, mars 2026 — "Initial development represents only 25%–35% of what you'll spend over three years." https://www.alphacorp.ai/blog/what-does-it-cost-to-build-an-ai-agent-in-2026-a-transparent-pricing-guide ↩

4. Build vs Buy Software: A Decision Framework, ThirstySprout, janvier 2026 — "Budget 15–20% of the initial development cost annually for maintenance." https://www.thirstysprout.com/post/build-vs-buy-software ↩ ↩²