Pourquoi 2026 change radicalement l'équation Build vs Buy
Depuis quinze ans, la réponse par défaut à la question « build ou buy » penchait presque toujours vers buy. Les SaaS couvraient tout : CRM, support, analytics, auth, payments, email, scheduling. Construire semblait coûteux, risqué, et jamais aussi abouti qu'une équipe produit spécialisée. Cette époque se termine. En 2026, quatre forces convergentes redistribuent les cartes, et une PME qui applique mécaniquement le dogme « buy by default » laisse 200 à 600 k€ sur la table tous les cinq ans.
Première force : la SaaS fatigue. Une PME française de 50 collaborateurs utilise en moyenne entre 40 et 80 outils SaaS en 2025, contre 15 à 25 en 2018. La facture mensuelle moyenne par utilisateur a grimpé de 35 € à 90 € sur la même période. Le phénomène de subscription sprawl n'est plus anecdotique : il représente désormais le deuxième poste de coûts IT après la masse salariale, devant le matériel et l'hébergement. Les DSI commencent à auditer ces abonnements comme elles auditent des contrats de prestation — et le bilan est souvent rude.
Deuxième force : l'IA et les outils d'assistance ont fait chuter le coût du build. Cursor, Claude Code, GitHub Copilot, v0.dev : un développeur senior produit aujourd'hui en une semaine ce qui prenait un mois en 2020. Le coût marginal d'une fonctionnalité custom a été divisé par trois à cinq. Les projets qui n'étaient pas rentables en 2020 — un workflow internalisé, un connecteur sur mesure, un petit back-office — le deviennent en 2026.
Troisième force : la souveraineté européenne. RGPD, NIS2, DSA, et la prochaine Loi IA européenne imposent une traçabilité de plus en plus coûteuse sur les données traitées hors UE. Héberger chez un éditeur américain soumis au CLOUD Act n'est plus une neutralité : c'est un risque juridique documenté. Le SREC (Système de Référence Europol) et les directives EUCS poussent vers des architectures self-hosted ou EU-hosted. Plusieurs de nos clients ont migré leur stack analytics de Mixpanel vers Plausible self-hosted pour cette raison précise.
Quatrième force : la parité open-source. En 2026, pour 80 % des cas d'usage génériques (auth, DB, analytics, scheduling, CRM, helpdesk, payments orchestration), il existe un équivalent open-source mature : Supabase, PostHog, Plausible, Cal.com, Twenty, Chatwoot, Hyperswitch. La parité fonctionnelle n'est plus un angle mort — souvent, c'est même l'inverse, avec une extensibilité supérieure. Le « buy » n'achète plus une fonctionnalité introuvable ailleurs : il achète le confort du managed service. Et ce confort a un prix, qui se révèle à la 5e année.
Le framework à 5 critères que nous appliquons en mission
Chez VALRY LABS, nous ne prenons jamais la décision build vs buy à l'instinct. Nous appliquons un framework à cinq critères pondérés, conçu pour une PME française de 10 à 250 collaborateurs. Chaque critère est noté de 1 (penche vers buy) à 5 (penche vers build). Un total ≥ 15 déclenche une étude approfondie du build. Un total ≤ 10 clôt le débat : on buy.
Critère 1 — Différenciation stratégique. La fonctionnalité est-elle une compétence cœur de métier, ou un service générique ? Si demain votre concurrent utilise la même chose sans différence visible, c'est probablement un commodity → buy. Si la fonctionnalité est ce qui fait payer vos clients → build. Exemple : pour une HealthTech, le dossier patient est build ; la facturation est buy. Pour un e-commerce DTC, le moteur de recommandation produit est build ; le shipping label est buy.
Critère 2 — TCO sur 3 à 5 ans, pas sur 1 an. L'erreur classique du SaaS : raisonner en coût annuel. À 50 €/utilisateur/mois × 50 utilisateurs × 5 ans, un seul outil coûte 150 k€. Un workflow interne bien conçu, hébergé sur une VM à 80 €/mois, avec 0,3 FTE de maintenance lissée sur 5 ans, coûte environ 90 à 120 k€ sur la même période — tout en restant sous votre contrôle. Le TCO ne se calcule jamais sur l'année 1, où le SaaS est structurellement gagnant (zéro coût d'implémentation, démarrage immédiat).
Critère 3 — Sensibilité des données et RGPD. Plus les données sont sensibles (santé, finance, RH, IP métier), plus le build ou le self-hosted s'imposent. Le coût de conformité d'une fuite chez un sous-traitant US peut dépasser celui d'un build complet (sanctions CNIL, perte de contrat, préjudice réputationnel). Règle empirique : données santé ou financières identifiantes → build ou EU-hosted avec DPA robuste. Données opérationnelles génériques → buy acceptable.
Critère 4 — Coût d'intégration avec la stack existante. Un SaaS mal intégré coûte plus cher qu'un build bien intégré. Si l'outil nécessite 4 à 8 semaines de travail de connexion (connecteurs custom, ETL bidirectionnel, synchronisation d'état, gestion des webhooks, retry policies), le coût d'intégration peut atteindre 25 à 40 k€ — et cette dette persiste à chaque changement côté éditeur. Pour un outil appelé à interagir profondément avec votre cœur métier, le build gagne presque toujours.
Critère 5 — Risque fournisseur. Que se passe-t-il si l'éditeur ferme, change de pricing de 200 %, ou est racheté par un acteur hostile ? Cette question était théorique en 2018 ; elle est devenue concrète en 2026 (voir les acquisitions agressives de Thoma Bravo, Vista, ainsi que les tournants pricing de plusieurs éditeurs analytics en 2023-2024). Évaluez : âge de l'éditeur, rentabilité, dépendance à un tier-investisseur, lock-in contractuel, complexité d'export des données. Si la réponse est « impossible à migrer en moins de 6 mois », le risque fournisseur devient un facteur build dominant.
L'axe « commodity vs differentiation » : le tableau qui désamorce les débats
Au-delà du scoring, il existe un axe empirique qui désamorce 80 % des débats en réunion de direction : la distinction commodity / differentiation. Les commodities sont les fonctions standards que tout le monde implémente de la même manière ; les differentiators sont celles qui font votre produit unique. La règle est simple : buy pour les commodities, build pour les differentiators.
Buy sans hésiter : auth (Clerk, Supabase Auth, WorkOS), payments orchestration (Stripe, Adyen), email transactionnel (Resend, Postmark), infrastructure cloud (AWS, GCP, Scaleway), observability (Sentry, Better Stack). Construire son propre système d'auth ou son propre processeur de paiement en 2026 est presque toujours une erreur — ces couches sont commoditisées, surveillées par la régulation, et bénéficient d'effets d'échelle qu'aucune PME ne peut égaler.
Build par défaut : outils internes (back-offices métier, interfaces de gestion, scripts d'ops), workflows clients exposés qui incarnent votre promesse produit, et surtout tout process assisté par IA qui consomme votre propriété intellectuelle. Si votre avantage concurrentiel tient à un algorithme de scoring, un pipeline RAG sur votre base documentaire, ou un workflow de qualification propre — construire est la seule option défendable. Acheter un outil SaaS qui demanderait à votre équipe de déposer son IP dans un prompt externe est un transfert de valeur caché.
La zone grise — CRM, helpdesk, analytics, marketing automation — est celle où le débat mérite réellement d'avoir lieu. Pour une PME de services B2B, un CRM comme HubSpot ou Pipedrive reste pertinent : la valeur est dans l'usage, pas dans la technologie. Pour une PME tech avec un cycle de vie client atypique (mobilier en abonnement, marketplaces multi-sided, services à étapes), un CRM générique casse le process commercial : on commence à coder des contournements, des champs custom, des automations increasingly brittle. À ce moment-là, basculez vers Twenty (CRM open-source) ou évaluez un build ciblé.
Le vrai coût d'un SaaS sur 5 ans : chiffres à l'appui
Prenons le cas réel d'une PME française de services B2B, 50 collaborateurs, qui active en 2026 cinq outils SaaS standards : un CRM (HubSpot Starter, 18 €/user/mois HT × 50), un outil de support (Intercom Essential, ~25 €/user/mois × 20 agents), une solution d'analytics produit (PostHog Cloud, ~40 €/user/mois × 10 sièges + 200 €/mois de volume), un scheduling (Calendly Teams, 12 €/user/mois × 30), un marketing automation (Brevo Business, ~50 €/user/mois × 10 + volume).
Sur 12 mois, la facture totale atteint environ 56 000 € HT. Sur 5 ans, en considérant les hausses tarifaires moyennes observées chez ces éditeurs (8 à 12 % par an), on dépasse 340 000 € HT. Pour 5 outils, sans compter les 15 à 30 autres abonnements mineurs qui se sont ajoutés en cours de route (Notion, Loom, Figma, Slack, Linear, 1Password, Loom, Hotjar, etc.) — qui rajoutent facilement 25 000 € à 60 000 € supplémentaires par an.
Profil alternatif : migration vers Supabase (auth + DB + storage, hébergé EU, ~150 €/mois en self-hosted), Plausible self-hosted (analytics, 9 €/mois sur une VM), Cal.com self-hosted (0 €/mois hormis l'infra), Twenty CRM self-hosted (open-source, ~100 €/mois d'infra), Chatwoot (helpdesk open-source, ~80 €/mois d'infra). Coût infra total : ~600 €/mois. Coût FTE maintenance lissé : 0,5 développeur full-stack senior, soit environ 60 000 €/an chargé. Sur 5 ans : ~360 000 €. Le break-even financier pur est atteint vers le mois 24, et la courbe diverge fortement ensuite — à la 5e année, le profil open-source est 30 à 40 % moins cher, et l'entreprise détient son infrastructure.
Le raisonnement financier n'est pas le seul. Le profil open-source supprime le risque pricing : aucun éditeur ne peut augmenter votre facture de 30 % unilatéralement. Il supprime aussi le lock-in : vos données restent dans votre PostgreSQL, vos schémas vous appartiennent, vos intégrations ne dépendent pas d'une API fermée. À l'inverse, le profil SaaS vous dispense de gérer une infra, et libère 0,5 FTE pour des tâches produit. Le bon choix dépend de votre capacité à recruter et à retenir un profil DevOps compétent — ce qui, en 2026, n'est plus un obstacle pour une PME qui se digitalise sérieusement.
Le modèle hybride : open-source + commercial support, le meilleur des deux mondes
Le débat build vs buy est de plus en plus remplacé par un tiers modèle : l'hybride. Le pattern le plus mature en 2026 consiste à utiliser un socle open-source pour le cœur, avec un contrat de commercial support pour le confort opérationnel. Vous gardez la maîtrise du code et des données, sans supporter seul la charge de maintenance.
Supabase illustre parfaitement ce modèle : l'offre self-hosted est gratuite et complète (PostgreSQL, Auth, Storage, Realtime, Edge Functions), et l'offre Cloud propose un managed service avec SLA, support, et dashboard. Plausible Analytics fonctionne sur le même schéma, ainsi que Cal.com, PostHog, Twenty, ou Sentry. Pour une PME, la stratégie efficace consiste à commencer en Cloud (time-to-market, pas d'ops), puis à basculer en self-hosted dès que l'usage justifie un FTE DevOps — généralement autour de 1 500 €/mois de facture Cloud.
Second pattern hybride : self-hosted pour le cœur (données, auth, IP métier) + SaaS pour la périphérie (outils de collaboration, communication, marketing). Une HealthTech va self-host sa base patient, son API métier, son auth ; elle peut en revanche acheter Slack, Notion, Figma sans risque. La règle : tout ce qui touche au produit ou aux données sensibles est self-hosted ; tout ce qui est outil collaboratif générique peut rester SaaS.
Troisième pattern, le plus stratégique : build l'orchestration, buy les composants. Plutôt que de construire chaque brique, on achète (ou on adopte en open-source) des composants standards, et on construit la couche d'orchestration qui les assemble selon la logique métier. Concrètement : Stripe pour la charge, Hyperswitch pour le routing multi-PSP, et un orchestrateur maison qui décide quelle route selon le montant, le pays, le risque. Ce pattern maximise la différenciation (orchestration) tout en minimisant le coût (composants). C'est l'architecture que nous déployons chez nos clients FinTech et e-commerce.
La matrice de décision par secteur
Le framework à 5 critères s'incarne différemment selon le secteur. Voici la matrice de décision que nous appliquons en mission, établie à partir d'une cinquantaine de dossiers PME traités en 2024-2025.
FinTech / PayTech. Tout ce qui touche au risque de crédit, au scoring KYC, à la prévention fraude, à l'orchestration multi-PSP, et à la comptabilisation réglementaire → build. Tout ce qui est paiement brute (carte, SEPA), reporting fiscal standardisé, identité vérifiée → buy (Stripe, Adyen, Onfido, Pennylane). Ne construisez jamais votre propre processeur de paiement ; construisez toujours votre propre couche de fraude si c'est cœur de métier.
HealthTech. Dossier patient, algorithmes de diagnostic assisté, pipelines d'anonymisation, intégrations avec les DMP et les logiciels métier (Doctolib, Maiia, Wandercraft) → build, en hébergement HDS. Facturation, signature électronique (Yousign, DocuSign), visioconférence → buy, en vérifiant la certification HDS et le DPA. L'enjeu n'est pas tant le coût que la conformité et la maîtrise de la donnée patient, qui est votre principal actif.
E-commerce. Le moteur de recommandation, le pricing dynamique, les règles de merchandising, l'univers cross-sell → build (c'est ici que se joue la marge). Le shipping (Sendcloud, Shoprunr), les paiements, le SEO technique, l'email marketing (Brevo, Klaviyo), le CMS headless pour la vitrine → buy. Cas particulier du CRM : en B2C avec forte volumétrie, build ciblé ou outil spécialisé ( Klaviyo, Sarbacane) ; en B2B, CRM standard comme HubSpot ou Pipedrive suffisent largement.
Services B2B (cabinet de conseil, agence, ESN, cabinet d'avocats). Le time-tracking, la facturation, le reporting marge par mission, le pipeline commercial → mix pragmatique où le SaaS tient la route (Pennylane, Cycle, Forecast, HubSpot). Le knowledge management interne et les outils d'IA générative appliquée aux livrables → build, parce que c'est ici que se construit l'avantage compétitif (réutilisation des savoir-faire, capitalisation des méthodes).
Notre conduite à tenir pour une PME en 2026
La réponse courte : arrêtez de raisonner en « build vs buy » et raisonnez en « core vs context ». Core : ce qui vous différencie, protège votre IP, ou traite des données sensibles — build ou self-hosted hybride. Context : tout le reste, commoditisé, générique — buy sans culpabilité, en auditant la facture annuellement.
Conduite à tenir opérationnelle en quatre étapes. Étape 1 : lancez un audit SaaS complet (1 semaine, 6-10 k€). Cartographie des abonnements, coût réel par utilisateur, taux d'usage réel. Vous y découvrirez en moyenne 25 à 35 % d'abonnements sous-utilisés ou redondants — première économie immédiate de 15 à 40 k€/an sans aucune décision build.
Étape 2 : appliquez le framework 5 critères sur vos 10 outils les plus coûteux. Notez chaque critère, faites la somme, identifiez les 2 ou 3 candidats à migration. Concentrez vos efforts : ne migrez pas 15 outils d'un coup, sélectionnez les 2 où le TCO 5 ans penche le plus nettement vers build ou self-hosted.
Étape 3 : pour chaque candidat, évaluez l'alternative open-source et le coût de migration (souvent 30-80 k€ pour un outil de portée moyenne). Calculez le break-even en mois. Si ≤ 24 mois, lancez. Si 24-36 mois, étudiez selon votre horizon stratégique. Si > 36 mois, gardez le SaaS — le contexte ne justifie pas la migration.
Étape 4 : industrialisez le raisonnement via un ADR (Architecture Decision Record) interne pour chaque nouvelle acquisition d'outil. Toute nouvelle souscription SaaS au-dessus de 200 €/mois passe par une fiche ADR de 1 page : besoin, alternatives open-source, TCO 5 ans, risque fournisseur. C'est la seule manière d'éviter que la situation se reconstitue en trois ans.