Build vs Buy pour les outils internes : quand les fondateurs doivent construire eux-mêmes

Construisez un outil interne lorsqu'il touche vos données cœur de métier ou votre workflow central, lorsque la tarification SaaS par siège croît plus vite que ne le justifie votre effectif, ou lorsque la version standard oblige votre équipe à la contourner chaque jour. Achetez lorsque l'outil est une commodité, lorsque votre besoin est standard, et lorsque l'uptime et la sécurité du fournisseur sont des choses que vous préférez louer plutôt que posséder. Le développement assisté par IA a déplacé la ligne vers le build, mais il n'a pas déplacé la ligne sur la maintenance, et c'est là que la plupart des fondateurs se trompent dans leurs calculs.

Pourquoi la question revient sur la table

Pendant une décennie, le conseil par défaut donné aux fondateurs était simple : ne jamais construire ce qu'on peut acheter. Le temps d'ingénierie était rare, le SaaS était bon marché, et chaque heure passée sur un outil interne était une heure non consacrée au produit.

Ce conseil a été écrit pour un monde où un « petit » outil interne prenait un trimestre à une équipe. Ce n'est plus le cas. Les développeurs reconstruisent désormais régulièrement une version délimitée d'un produit commercial, un enregistreur d'écran navigateur, un outil de recherche de photos, un CRM léger, en un week-end avec un LLM qui fait la majeure partie de la saisie. Le coût de la première version s'est effondré.

Mais la première version n'a jamais été la partie coûteuse. C'est la possession qui l'est. Notre propre moteur de prospection, décrit plus bas, a pris bien moins de temps à faire fonctionner qu'il n'en a fallu pour le maintenir en état de marche : les scrapers cassent, les versions de modèles changent, et un ingénieur y consacre encore une partie de chaque mois. La première version était bon marché. La deuxième année est le vrai prix. La question est donc passée de « pouvons-nous nous permettre de construire ceci » à « pouvons-nous nous permettre de maintenir ceci en vie », et cela nécessite un cadre différent.

Les quatre questions qui tranchent

1. L'outil repose-t-il sur vos données cœur de métier ?

Si l'outil lit ou écrit les données qui font la valeur de votre entreprise, dossiers clients, événements d'usage, notes cliniques, logique de pricing, alors acheter signifie confier votre actif le plus important au modèle de données et à la politique d'export d'un fournisseur. Vous passerez des mois à lutter contre leur schéma et les limites de leur API. Les outils portant sur des données cœur de métier penchent fortement vers le build.

Si l'outil héberge des données dont la perte ne vous affecterait pas, enregistrements de réunions, maquettes de design, notes de standup, achetez-le et passez à autre chose.

2. Comment la tarification SaaS évolue-t-elle ?

La tarification par siège est le piège. Elle paraît triviale à cinq personnes et devient une ligne budgétaire que le directeur financier scrute à quarante. Faites le calcul sur trois ans avant de signer.

Un exemple illustratif : un outil à 30 $ par siège et par mois pour 40 personnes représente 14 400 $ par an, soit 43 200 $ sur trois ans. Et c'est avant l'inévitable montée en gamme lorsque vous avez besoin de SSO ou d'un audit log. Un outil interne ciblé, construit en deux à trois semaines et maintenu un à deux jours par mois, se situe généralement bien en dessous de ce montant sur la même période.

La tarification à l'usage est plus amicale. Si vous ne payez que ce que vous consommez et que l'usage suit le revenu, acheter reste souvent judicieux même à l'échelle.

3. Qui le répare quand il casse ?

C'est la question que les fondateurs esquivent. Un outil interne a des dépendances qui pourrissent, une API tierce qui change son flux d'authentification, une base de données qui a besoin d'une migration, et un correctif de sécurité qui arrive un vendredi. Si personne n'en est responsable, il devient discrètement le type de dette que nous décrivons dans gestion de la dette technique : fonctionnel, délaissé, et terrifiant à toucher.

Règle : un outil interne sans propriétaire désigné est un passif, pas un actif. Si vous ne pouvez pas nommer la personne qui le maintiendra l'année prochaine, achetez.

4. Allez-vous continuer à le faire évoluer ?

Si vos exigences pour l'outil changent chaque semaine, parce que vous êtes encore en train d'apprendre votre propre processus, le SaaS vous résistera à chaque étape. Champs personnalisés, bricolages Zapier et feuilles de calcul de contournement s'accumulent. Construire gagne lorsque l'outil est une cible mouvante.

Si le processus est stable et standard, facturation, notes de frais, prise de rendez-vous, le fournisseur l'a déjà mieux résolu que vous ne le ferez.

Notre propre exemple : le moteur de prospection

Nous gérons notre propre outbound au sein de l'agence, et cette décision s'est posée directement pour nous. Les outils de personnalisation sur étagère produisaient soit des e-mails génériques, soit facturaient par crédit d'enrichissement d'une manière qui évoluait mal avec le volume que nous voulions.

Alors nous l'avons construit. Une instance auto-hébergée de Firecrawl scrape le site de chaque prospect, un LLM local lit le résultat, et le moteur rédige un e-mail personnalisé par entreprise. Il tourne sur du matériel que nous possédions déjà, donc le coût marginal par prospect est proche de zéro.

La partie qui comptait pour la décision build vs buy est ce qui s'est passé après la première version. Notre pipeline initial enchaînait plusieurs étapes : extraire des faits sur l'entreprise, planifier l'angle, puis rédiger. Lorsque nous avons condensé cela en un seul appel qui extrait et rédige simultanément, le résultat a été supérieur à la fois en coût et en qualité. Nous n'avons pu l'apprendre que parce que nous possédions l'outil et pouvions modifier l'architecture de prompt en un après-midi. Avec un produit SaaS, cette expérimentation ne vous est pas accessible. Nous couvrons le schéma général dans appel unique vs chaînes d'agents, et le cas spécifique dans agent d'e-mail à froid par IA : build vs buy.

Le coût honnête de cette décision est qu'un ingénieur consacre une partie de chaque mois à le maintenir en bonne santé, car les scrapers cassent et les versions de modèles changent. Nous estimons que cela en vaut la peine. À vous de décider si votre équivalent en vaut la peine.

À quoi ressemble un bon « build »

Si les quatre questions pointent vers la construction, restez disciplinés :

• Limitez le périmètre à un seul workflow. Pas « un CRM interne », mais « la vue dont le responsable commercial a besoin chaque lundi matin ». Vous pourrez l'élargir plus tard.
• Utilisez une stack sobre. Pour nous, c'est Next.js, PostgreSQL ou Supabase, et TypeScript. Parfois, c'est un script et une tâche cron. L'objectif est que n'importe quel ingénieur de l'équipe puisse le réparer.
• Fixez un délai limité pour la première version. Une à trois semaines. Si ça ne rentre pas dans ce cadre, l'outil est plus gros que vous ne le pensez.
• Nommez un propriétaire et budgétisez son temps. Traitez-le comme un petit produit avec un backlog, pas comme un projet annexe.
• Instrumentez-le. Un outil dont personne ne sait qu'il est cassé est pire que l'absence d'outil. Journalisez les exécutions, alertez en cas d'échec.

Quand acheter est clairement la bonne décision

Certaines catégories ne font pas débat :

• Authentification, paiements, e-mails transactionnels. La sécurité et la délivrabilité du fournisseur sont le produit. Ne les possédez pas.
• Tout ce qui comporte un périmètre de conformité. Si l'outil entre dans le périmètre d'un audit SOC 2, HIPAA, ou de résidence des données, vous voulez l'attestation d'un fournisseur, pas la vôtre.
• Collaboration standard. Appels vidéo, documents, chat. Votre version sera moins bonne et personne ne vous en remerciera.
• Tout ce dont vous avez besoin cette semaine et qui n'est pas cœur de métier. Achetez-le, programmez un rappel pour la date de renouvellement, et réappliquez ce cadre à ce moment-là.

Une règle applicable en une seule réunion

Notez les quatre questions. Si deux réponses ou plus disent build, construisez une première version à délai limité pour un seul workflow avec un propriétaire désigné. Si moins de deux le disent, achetez, et réexaminez au prochain renouvellement.

Passez notre moteur de prospection dans ce cadre et vous verrez le score en pratique. Données cœur de métier : partiellement, puisque la recherche sur les prospects alimente notre pipeline mais nous survivrions à sa perte. Tarification : le modèle par crédit d'enrichissement évoluait mal avec le volume que nous voulions, donc build. Propriétaire : un ingénieur, désigné, avec une partie de chaque mois budgétisée, donc le build est autorisé. Évolution : nous avons réécrit l'architecture de prompt d'une chaîne multi-étapes vers un appel unique une fois que nous avions les données, donc build. Trois réponses sur quatre disaient build, et la décision s'est maintenue.

Notez la décision et la date, car la bonne réponse change à mesure que l'entreprise grandit, et l'attitude honnête consiste à la revérifier plutôt qu'à la défendre.

Où une agence trouve sa place

La plupart des fondateurs ne manquent pas du jugement nécessaire pour prendre cette décision. Ils manquent d'un ingénieur disposant de deux semaines libres. C'est le vide que nous comblons : un outil interne délimité, construit sur une stack que votre équipe connaît déjà, livré avec un manuel du propriétaire plutôt qu'une dépendance. Si vous êtes en train de fixer un renouvellement SaaS en vous demandant si vous ne devriez pas construire à la place, parlons-en.