Build vs buy : le cadre de décision du fondateur non technique

Build vs buy n’est presque jamais la bonne question. Voici une checklist de quatre questions qu’un fondateur en early stage peut faire tourner en quinze minutes avant de signer un contrat SaaS, d’embaucher un dev, ou d’ouvrir un doc Notion intitulé “spec du MVP.”

Le fondateur en call avec moi avait une question propre et une réponse embrouillée. Il avait levé un tour seed huit mois plus tôt, signé deux pilotes enterprise, et fixait maintenant un tableur avec onze abonnements SaaS dessus. “Je crois qu’on doit construire le nôtre,” a-t-il dit. “Ou alors consolider. Je sais pas trop. Franchement, je sais même pas comment trancher.”

On a parlé une heure. En vrai, il n’avait pas formulé la bonne question. Il pensait qu’il choisissait entre logiciel sur mesure et SaaS. L’arbre de décision réel était plus large, ses contraintes plus serrées qu’il ne le voyait, et la réponse à “build ou buy” dépendait presque entièrement de trois variables qu’il n’avait pas encore nommées à voix haute. Il est sorti du call avec une checklist de quatre questions. Deux semaines plus tard, il a coupé quatre des onze outils, en a pris deux de plus, et n’a mis qu’un seul workflow sur la liste “à construire.”

Cette conversation, sous une forme ou une autre, a lieu chez Pixel Breeders presque chaque semaine. La question de build vs buy est la décision la plus fréquente qu’un fondateur non technique nous amène. C’est aussi celle qui est le plus régulièrement mal formulée.

Voici le cadre qu’on utilise.

Ce que “build vs buy” veut vraiment dire

Build vs buy, c’est la décision entre construire un logiciel sur mesure pour un workflow et acheter un produit prêt à l’emploi qui résout un problème similaire. La formulation classique est binaire : écrire le code soi-même (build), ou payer un éditeur pour un logiciel fini (buy).

En 2026, la formulation est déjà fausse avant qu’on commence. Il existe une troisième option qui, en silence, couvre la majorité des workflows des sociétés en early stage : coudre quelques outils SaaS ensemble avec une colle no-code (Zapier, Make, n8n, Airtable, un Retool par-dessus). Ce n’est ni du build pur ni du buy pur. C’est la réalité par défaut de presque toutes les startups pré-Série A avec lesquelles on travaille, et l’ignorer produit de mauvaises décisions.

La vraie question, donc, est :

• Build : logiciel sur mesure écrit pour votre workflow spécifique.
• Buy : un produit prêt à l’emploi qui prend en charge le workflow de bout en bout.
• Stitch : assembler deux produits existants ou plus avec une colle légère (automatisations, formulaires internes, un dashboard).

La plupart des fondateurs vont au buy par défaut, dépensent parfois trop en stitch, et sous-estiment à quel point build est rarement la bonne réponse à leur stade. Les quatre questions ci-dessous sont conçues pour faire émerger laquelle des trois colle vraiment.

Les quatre questions

À faire tourner dans l’ordre. Chacune est une porte. Si une question tue l’option build, on s’arrête là. Pas besoin d’aller à la suivante.

1. Ce workflow est-il central pour la façon dont on gagne de l’argent ?

La première porte, c’est de savoir si le workflow est structurel pour le revenu.

Un workflow est central s’il rentre dans l’un des cas suivants :

• Une surface produit que vos clients payants touchent directement.
• Un workflow que votre équipe exécute des milliers de fois par mois et qui a un effet mesurable sur la conversion, la rétention, ou les unit economics.
• Un workflow réglementaire ou de confiance critique (KYC, custody, sinistres) où une panne ou une limite côté éditeur impacterait sérieusement l’entreprise.

Un workflow n’est pas central s’il s’agit de coordination interne (gestion de projet, agenda, notes de frais), de communication précoce avec le client (CRM, e-mail), ou de tout ce où “suffisamment bon” l’emporte sur “exactement comme je veux.”

Si le workflow n’est pas central : buy ou stitch. Vous ne devriez pas construire un logiciel pour des problèmes qui sont résolus correctement par un produit à 40 $ par poste utilisé par 50 000 autres boîtes. L’avantage d’un outil générique est réel, le temps gagné est réel, et le coût de maintenance d’une version sur mesure se cumule contre vous pendant des années.

Si le workflow est central, passez à la question deux.

2. Un produit du marché colle-t-il vraiment à notre workflow ?

La plupart des fondateurs sautent cette étape, ou la font à moitié. Ils regardent deux concurrents, en trouvent un qu’ils détestent, et concluent que “rien ne convient.”

La version honnête de cette question, c’est : passez un vrai après-midi à cartographier votre workflow tel qu’il existe aujourd’hui, prenez cette carte, allez vers trois produits réels, et faites-le tourner dedans. Pas la démo. Le workflow réel, avec vos vrais cas limites.

Vous cherchez le gap entre ce que le produit fait et ce dont vous avez besoin. Un gap de 10% est acceptable ; vous apprendrez à vivre avec, et le produit livrera sans doute les 10% manquants dans deux trimestres. Un gap de 40% est fatal. Vous allez passer l’année à faire du travail manuel autour des limites, à former les gens aux contournements, et à expliquer à l’équipe pourquoi “c’est comme ça que l’outil marche.”

Le piège ici, c’est le gap de la démo. Les démos commerciales sont réglées pour que le produit ait l’air de tout couvrir. Il ne couvre pas tout. La carte du workflow est la seule façon de voir où le produit casse vraiment.

Si un produit colle avec un gap tolérable : buy. On arrête l’analyse. On passe à autre chose. Il n’y a pas de médaille pour construire ce que quelqu’un d’autre a déjà construit.

Si aucun produit ne colle, passez à la question trois.

3. Peut-on y arriver en cousant ce qui existe déjà ?

C’est la question qui a le plus changé depuis 2022, parce que la surface du SaaS a doublé et que la couche d’intégration a mûri.

Coudre, ça veut dire : prendre deux ou trois produits dont chacun couvre une partie du workflow, les connecter avec des automatisations, et ajouter la fine couche de logique custom qui ferme le dernier kilomètre. Un workflow stitched typique en early stage ressemble aujourd’hui à ça :

• HubSpot est propriétaire de la fiche contact.
• Un Typeform ou un formulaire d’intake custom pousse les nouveaux leads dans HubSpot.
• Une automatisation n8n ou Make route les leads à forte valeur vers un canal Slack et un dashboard Retool.
• Le dashboard Retool tire le contact et affiche au SDR une vue custom, appelle deux ou trois APIs internes, et réécrit un statut.

Ça, c’est du logiciel stitched. Ce n’est ni du code sur mesure pur, ni du tout-prêt pur. C’est le cheval de trait du stack moderne en early stage.

Stitch gagne quand :

• Le workflow est central, mais les briques existent déjà sous forme de produits.
• La couche custom nécessaire est peu profonde (un formulaire, un dashboard, quelques automatisations).
• Vous vous attendez à ce que le workflow change chaque trimestre pendant l’année à venir. Les couches stitched sont bon marché à jeter. Le code sur mesure non.

Stitch perd quand :

• La couche custom a grossi vers une demi-douzaine d’automatisations et trois Retool, et personne ne sait décrire comment ça marche.
• La performance commence à compter (files d’attente n8n qui s’allongent, rate limits Zapier qui tapent, vue Airtable qui charge lentement).
• Les points d’intégration eux-mêmes deviennent un poids de maintenance supérieur à ce que coûterait être propriétaire du code.

C’est le mode de défaillance qu’il vaut la peine de nommer explicitement : le piège du stitch. Les systèmes stitched sont bon marché à démarrer et chers à hériter. Le fondateur qui a tout monté sait où vit chaque pièce ; l’employé suivant ouvre le canvas Make, voit quarante-sept nœuds reliant onze produits, et démissionne en moins d’un mois. On a vu ce motif assez de fois pour traiter “on a un système stitched que personne d’autre ne sait lire” comme un vrai passif de recrutement.

Si coudre fonctionne sur les douze prochains mois : stitch, et on revoit à cet horizon.

Si coudre casse déjà, ou si le système a atteint le seuil de complexité, passez à la question quatre.

4. Le workflow est-il assez stable pour être encodé ?

La dernière porte, c’est de savoir si le workflow a arrêté de changer chaque semaine.

Le logiciel sur mesure a le plus de valeur quand vous l’écrivez pour un workflow que vous comprenez. Si vous itérez encore sur la forme même du workflow (quelles étapes existent, qui fait quoi, quels sont les inputs), construire un logiciel pour ça, c’est une assurance chère contre votre propre indécision. Vous allez construire la mauvaise chose, la jeter, en construire une seconde version, et découvrir que la troisième version est celle que vous vouliez vraiment. C’est un coût réel.

Le signal qu’un workflow est assez stable pour être encodé est opérationnel, pas philosophique. Vous pouvez décrire le workflow à une nouvelle recrue en quinze minutes sans dire “bon, ça dépend.” Les exceptions ont une règle. Les cas limites ont un nom.

Si le workflow est encore en mouvement : stitch un trimestre de plus. Ne construisez pas encore.

Si le workflow est stable, que les outils existants ne collent pas, que le gap est trop large pour être cousu, et que le workflow est central pour le revenu : build.

C’est le seul chemin vers le “build.” Il est plus étroit que la plupart des fondateurs ne le pensent.

Ce que “build” coûte vraiment à l’échelle d’une startup

La raison pour laquelle cette décision compte, c’est l’écart de coût, et les chiffres que la plupart des fondateurs se citent à eux-mêmes sont faux d’un ordre de grandeur.

Pour une startup en early stage, construire un logiciel sur mesure avec un petit studio ou partenaire (pas une agence offshore générique, pas une équipe interne que vous n’avez pas) atterrit typiquement comme ça :

• Un petit outil interne qui remplace un workflow stitched : 20 K€–60 K€, quatre à dix semaines. Un dashboard custom avec quelques écritures dans votre base, une intégration externe, une UI propre.
• Un v1 d’une surface produit centrale que les clients verront : 80 K€–250 K€, trois à six mois. Vrai frontend, utilisateurs authentifiés, modèle de données réfléchi, un admin interne, un pipeline de déploiement.
• Un v1 d’un workflow réglementé (KYC, paiements, sinistres) : 150 K€–500 K€, six à douze mois. Tout ce qui précède, plus piste d’audit, flux de compliance, et la partie lente de faire la sécurité correctement.

Ce sont des chiffres 2026 pour un petit studio partenaire, en TypeScript, React, Postgres, déployant sur un cloud managé. Les chiffres montent si l’équipe est plus grosse, descendent si l’équipe est plus affûtée. Ils montent plus vite que les fondateurs ne s’y attendent quand le scope dérive sans que personne le nomme. On a écrit davantage sur combien ça coûte vraiment de développer une application et sur la façon dont la structure du contrat change la maths.

Les mêmes chiffres traduits en SaaS : 20 K€ de dev sur mesure valent environ deux ans d’un outil à 100 € par poste pour une équipe de dix. 250 K€, c’est plus proche d’une décennie de la même chose. C’est cette maths qui devrait pousser au buy par défaut.

La version honnête de “combien devrait-on dépenser là-dessus” : si le workflow est central, que les chiffres tiennent, et que le gap est réel, 80 K€–250 K€ pour un v1 propriétaire d’un workflow que vos concurrents ne peuvent pas copier en un trimestre, ce n’est pas cher. C’est le reste du spectre qui met les fondateurs dans le rouge.

Quand buy gagne (la réponse par défaut)

Dans les conversations qu’on a avec les fondateurs, buy gagne huit fois sur dix. Les raisons sont ennuyeuses et justes.

Les outils génériques sont matures. HubSpot, Notion, Linear, Stripe, Qonto, Pennylane, Pylon, Vanta : chacun a une équipe produit de dizaines à centaines de personnes, en train de construire précisément la feature que vous construiriez. Ils livrent plus vite que vous. Leur posture de sécurité est meilleure que la vôtre. Leurs intégrations sont plus profondes. Leur prix, même sur les paliers hauts, est en général inférieur au coût chargé d’un ingénieur sur un trimestre.

L’erreur du fondateur, c’est de surpondérer les 10% précis que l’outil ne fait pas. Les 90% qu’il fait, c’est la victoire. La plupart des workflows que vous croyez uniques ne le sont pas. On peut dire à un fondateur en quinze minutes si son workflow “custom” est vraiment custom ou si c’est un workflow standard qu’il n’a pas encore reconnu. L’Aggregation Theory de Ben Thompson est la lecture la plus propre sur pourquoi c’est structurel, pas accidentel.

Si un produit couvre 70% ou plus de votre workflow réel, buy. Vivez avec le gap de 30%. Revoyez dans un an.

Quand build gagne (les exceptions structurelles)

Build gagne dans un petit nombre de cas bien définis.

Le premier, c’est la surface produit. Si le logiciel en question, c’est ce que vos clients vous achètent, le construire n’est pas optionnel. Personne n’a pris un abonnement SaaS à une version générique de votre produit, parce qu’elle n’existe pas. Il y a vous. Le logiciel sur mesure, c’est l’entreprise.

Le deuxième, ce sont les workflows opérationnels qui composent un avantage. Certains workflows ne sont pas votre produit, mais génèrent un avantage mesurable à l’échelle. Un moteur de matching sur mesure pour une marketplace. Une automatisation de sinistres pour un assureur. Un système de réconciliation pour une fintech. Ce sont des workflows où une amélioration de 10% du throughput se traduit par un changement notable d’unit economics. Les éditeurs du marché ne peuvent pas affiner pour ça. Vous, oui.

Le troisième, c’est la profondeur d’intégration. Si le workflow a besoin de lire et écrire dans cinq systèmes internes avec des règles uniques à votre métier, et que le produit du marché demanderait quand même un projet d’intégration de six mois pour faire la moitié de ce qu’il vous faut, le coût build converge avec le coût buy, et la version build est à vous, à faire évoluer. On voit ce motif le plus souvent dans des sociétés late-seed et Série A qui sortent d’un montage stitched.

Le quatrième, c’est la responsabilité réglementaire. Quand vous êtes l’entité responsable de la piste d’audit, du chiffrement, de la résidence des données, et du flux de consentement, le coût de se tromper sur la posture de compliance d’un éditeur dépasse parfois le coût d’être propriétaire du code. C’est plus fréquent en fintech, healthtech, et legaltech que les fondateurs ne le réalisent.

En dehors de ces quatre cas, la réponse n’est pas, en général, build.

Le piège du stitch, et pourquoi c’est le mode de défaillance de 2026

Le débat build vs buy de 2015 n’est pas celui d’aujourd’hui. En 2015, le choix était réel : il y avait moins de produits SaaS, moins de plateformes d’intégration, et la question d’écrire du code pesait. En 2026, presque tous les workflows en early stage peuvent être cousus à partir d’outils existants, et la question a changé.

Le nouveau mode de défaillance, c’est le système stitched que personne ne sait lire. Un fondateur achète huit outils, recrute un ops à temps partiel pour tout brancher avec Zapier, ajoute deux dashboards Retool par-dessus, et découvre dix-huit mois plus tard que personne dans l’équipe ne comprend comment fonctionne le workflow d’onboarding client. Pas de documentation. Le schéma dans sa tête est le seul schéma. Quand l’ops part, le système devient un point unique de défaillance que personne n’ose toucher.

On met aujourd’hui les fondateurs en garde contre ça. Trois signaux :

• Votre système stitched a plus de dix points d’intégration, et la carte des dépendances n’existe que dans la tête de quelqu’un.
• Plus d’un workflow critique reste muet pendant une journée parce qu’une automatisation Make a touché un rate limit et personne ne l’a vu.
• Le recrutement traîne parce que les nouvelles recrues ne peuvent pas être onboardées sur votre outillage sans une visite guidée de la personne qui a tout monté.

Quand l’un de ces signaux est allumé, la bonne réponse n’est en général pas “tout construire.” C’est “encoder la colonne vertébrale du workflow et garder les feuilles en SaaS.” Un petit studio logiciel peut le faire dans un engagement de six à dix semaines. Le résultat, c’est un système que l’équipe sait lire, qui survit au turnover, et qui maintient les investissements SaaS en vie là où ils ont encore du sens.

Ce qu’il faut faire cette semaine

Si vous regardez cette décision aujourd’hui, le travail n’est pas philosophique. C’est un après-midi.

Écrivez le workflow. Listez les outils qui le touchent. Faites tourner les quatre questions, dans l’ordre. Si le workflow n’est pas central, arrêtez-vous et achetez quelque chose. Si un produit colle, arrêtez-vous et achetez ce produit. Si une couche stitched fonctionne pour les douze prochains mois, arrêtez-vous et cousez, et posez un rappel dans le calendrier pour revoir. Si rien de tout ça ne tient et que le workflow est stable, build.

Les fondateurs qui prennent cette décision correctement ne sont pas ceux qui agonisent dessus. Ce sont ceux qui formulent la bonne question, tranchent vite, et reviennent sur la décision quand le business change. C’est là que se trouve l’essentiel de la valeur.

FAQ

Quelle est la différence entre build et buy ?
Build, c’est écrire un logiciel sur mesure pour votre workflow spécifique. Buy, c’est acheter un produit prêt à l’emploi qui résout un problème similaire pour beaucoup d’entreprises. En pratique il existe une troisième option, coudre plusieurs produits SaaS avec des automatisations et une fine couche custom, et c’est la bonne réponse plus souvent que les fondateurs ne le réalisent dans les premières phases.

Est-il préférable de construire ou d’acheter ?
Pour un fondateur non technique en early stage, buy est la bonne réponse la plupart du temps. Build n’est la bonne réponse que lorsque le workflow est central pour le revenu, qu’aucun produit du marché ne colle, que la couture n’est pas viable, et que le workflow est assez stable pour être encodé. En dehors de ces conditions, le logiciel sur mesure est plus cher et plus lent que les alternatives.

Combien ça coûte, build vs buy ?
Un petit outil interne sur mesure coûte typiquement 20 K€–60 K€ et tourne sur quatre à dix semaines avec un petit studio partenaire. Un v1 d’une surface produit côté client tombe entre 80 K€ et 250 K€. La dépense équivalente en SaaS pour le même workflow est en général de 5 K€ à 30 K€ par an. La maths favorise buy, sauf si le workflow est central et durable.

Quand une startup doit-elle construire son propre logiciel ?
Quand le logiciel est le produit, quand un workflow opérationnel génère un avantage composé à l’échelle, quand la profondeur d’intégration entre systèmes internes est unique au métier, ou quand la responsabilité réglementaire rend le risque éditeur inacceptable. Ce sont les quatre cas où build gagne. En dehors de ça, buy ou stitch.