Un client m'a appelé en 2021, la panique dans la voix. Il avait dépensé 140 000 £ sur quatorze mois pour construire une plateforme de facturation sur mesure. Son équipe de dev avait livré peut-être 60% du cahier des charges. Et quelque part vers le mois onze, il avait découvert que Invoice Ninja existait, était open-source, et faisait 90% de ce dont il avait besoin prêt à l'emploi. Gratuitement.
Enseignement principal : Achetez du SaaS jusqu'au moment où la taxe d'abonnement, la propriété des données ou l'incompatibilité du flux de travail devient réellement problématique ; développez du sur mesure quand l'outil est au cœur de la façon dont l'entreprise gagne.
Cet appel me hante un peu. Parce que l'honnête réponse est : j'ai aussi fait l'erreur inverse. Seahawk avait un projet en 2019 où nous avons passé huit mois à assembler cinq outils SaaS différents, Airtable, Zapier, Typeform, HubSpot, et un CMS Webflow sur mesure, pour gérer un workflow client qui, avec le recul, un développement sur mesure de 15 000 £ aurait résolu proprement et définitivement. Nous payions à peu près 900 £/mois en abonnements combinés à la fin. Fais le calcul sur trois ans.
Aucun extrême n'est automatiquement juste. Et quiconque te vend une règle nette, « toujours construire », « ne jamais construire », vend quelque chose. Voici donc le vrai framework que j'utilise quand un founder s'assoit avec moi et pose la question.
---
Premièrement, admettre ce que vous décidez réellement
Ce n'est pas une décision technique. Pas vraiment. C'est une décision commerciale déguisée en termes techniques.
Quand tu dis « devrais-je construire ou acheter ? », ce que tu demandes vraiment est : où se situe la différenciation dans mon produit ? Si ce que tu envisages de construire est au cœur de ton avantage compétitif, la raison pour laquelle les clients te choisiront plutôt que l'onglet suivant dans leur navigateur, alors construire a probablement du sens. Si c'est de l'infrastructure, de l'admin, ou une fonctionnalité commodity, acheter est presque certainement moins cher en termes réels.
Je pose d'abord une question aux fondateurs : Vos utilisateurs verront-ils jamais cette chose ? Si la réponse est oui et que cela façonne leur expérience de façon significative, cela pourrait valoir la peine de construire. Si c'est du back-office, opérationnel, ou interne, le seuil pour construire devrait être très élevé.
---
Le Vrai Coût de la Construction (Les Gens le Sous-estiment Gravement)
Soyons direct. Le développement sur mesure coûte plus cher que tu le penses, prend plus longtemps qu'on te le dit, et demande une maintenance permanente que personne ne budgétise.
Ce que les fondateurs oublient réellement de compter
- Maintenance et hébergement. Pas un travail ponctuel. Vous en êtes responsable indéfiniment, sauf si vous abandonnez la chose.
- Correctifs de sécurité. Un fournisseur SaaS s'en charge pour vous. Vous la construisez, vous en êtes propriétaire, y compris les alertes à 2 h du matin.
- Intégration de nouveaux développeurs. Si votre ingénieur principal part, la personne suivante doit apprendre votre codebase. C'est des semaines de travail facturable.
- Expansion du périmètre. Les parties prenantes voient un outil personnalisé et supposent qu'il peut faire tout. Le périmètre s'élargit. Les coûts suivent.
Une règle approximative que j'utilise : prenez votre estimation initiale de développement, multipliez par 1,6 pour une livraison réaliste, puis ajoutez 20% de ce chiffre annuellement pour la maintenance. Si ces chiffres justifient toujours le modèle économique, parfait. Si ce n'est pas le cas, vous avez votre réponse.
Honnêtement, le CHAOS Report du Standish Group montre depuis des décennies que les projets logiciels dépassent leurs budgets à un taux alarmant. Le chiffre se situe autour de 45-50% des projets étant « en difficulté » ou franchement échoués. Ce n'est pas une raison de ne jamais construire, c'est une raison d'y aller les yeux ouverts.
---
Le vrai coût du SaaS (aussi sous-estimé, simplement différemment)
Le SaaS semble bon marché jusqu'à ce qu'il ne le soit plus.
Le plan à 49 £/mois qui semblait raisonnable au début de l'année a une drôle d'habitude de devenir 490 £/mois à la fin de l'année trois, une fois que tu as changé de tier, tu as ajouté des sièges, et le vendeur a fait une « restructuration tarifaire » (comprendre : augmentation). J'ai vu ça arriver à des clients chez Salesforce, Intercom, et Mixpanel. Ce n'est pas malveillant. C'est juste comment fonctionne l'économie du SaaS.
Les trois pièges du SaaS dans lesquels les fondateurs tombent
- L'enfermement propriétaire. Vos données sont dans leur format, leur schéma, leur flux d'export. Partir est douloureux et parfois effectivement impossible sans travail d'ingénierie de données considérable.
- La complexité de la Frankenstein-stack. Cinq outils qui s'intègrent vaguement via Zapier, ce n'est pas un système. C'est un passif. Une dépréciations d'API et tout commence à s'effondrer.
- Le dérapage des abonnements. Personne n'audite sa stack d'outils annuellement. Ils devraient. J'ai réalisé un audit pour une agence de 12 personnes l'année dernière et j'ai trouvé £3 200/mois en SaaS qu'ils avaient soit arrêté d'utiliser, soit utilisaient pour une seule fonctionnalité chacun.
Cela dit, pour les fonctions commodity, le SaaS est presque toujours le bon choix. Livraison d'email ? Postmark ou SendGrid. Paiements ? Stripe, évidemment. Auth ? Auth0 ou Clerk. Personne ne devrait construire son propre processeur de paiement en 2024.
---
Un Framework Qui Fonctionne Réellement
D'accord. Voici comment je réfléchis à la question. Quatre questions, dans l'ordre.
Question 1 : Est-ce un différenciateur concurrentiel ?
Si oui, si c'est ce qui rend ton produit vraiment différent, construire mérite une sérieuse considération. Si non, arrête là. Achète.
Question 2 : Existe-t-il une bonne alternative SaaS ?
Une bonne alternative, pas parfaite. Les fondateurs construisent régulièrement parce que « rien sur le marché ne fait exactement ce dont nous avons besoin ». Parfois c'est vrai. Souvent cela signifie qu'ils n'ont pas cherché assez dur, ou ils confondent « nous devons bien configurer ceci » avec « nous devons construire quelque chose de nouveau ».
Je passe au moins deux heures à étudier le marché du SaaS avant de jamais recommander un développement sur mesure. Product Hunt et G2 sont vraiment utiles ici, pas comme parole d'évangile mais comme inventaire de départ.
Question 3 : Quel est votre délai réaliste avant de générer de la valeur ?
Un outil SaaS peut être en ligne aujourd'hui. Un développement sur mesure prend des semaines minimum, généralement des mois. Si la rapidité compte, et dans les jeunes entreprises c'est presque toujours le cas, acheter vous achète du temps pour apprendre ce dont vous avez vraiment besoin avant de vous engager à le construire.
En 2022, Seahawk a travaillé avec une startup logistique qui voulait un tableau de bord d'optimisation d'itinéraires sur mesure. Nous les avons convaincus d'utiliser d'abord une couche API en marque blanche (ils ont utilisé Route4Me comme point de départ). Six mois plus tard, ils savaient exactement quelles trois fonctionnalités leurs clients recherchaient réellement. Le développement sur mesure qu'ils ont finalement commandé avait moitié moins de portée, et était deux fois meilleur, parce qu'ils avaient appris en production plutôt que dans un document de spécifications.
Question 4 : Que se passe-t-il quand ça tombe en panne ?
Parce que ça va casser. La question est qui le répare et à quelle vitesse. Avec SaaS, vous ouvrez un ticket de support et vous vous plaignez sur Twitter. Avec un logiciel sur mesure, vous appelez votre équipe de développement. Si vous n'avez pas d'équipe de développement en contrat, vous avez un problème. Ce n'est pas une hypothèse, j'ai vu des fondateurs bloqués avec un logiciel sur mesure cassé pendant des semaines parce que leur développeur freelance était en vacances.
---
Quand la Construction Est Clairement le Bon Choix
Il y a des situations où le sur mesure est clairement correct. Laissez-moi les nommer sans détour.
- Votre propriété intellectuelle fondamentale est le logiciel lui-même. Si vous vendez un produit SaaS, vous ne pouvez pas externaliser la chose que vous vendez.
- Les exigences réglementaires signifient que prêt-à-l'emploi ne suffira pas. Certaines applications fintech, santé et légales ont des contraintes de conformité que la plupart des outils SaaS ne sont pas construits pour satisfaire.
- Vous avez déjà validé avec un outil SaaS et vous savez exactement ce dont vous avez besoin. C'est la meilleure position possible avant de commander une construction personnalisée.
- Le prix SaaS à grande échelle est véritablement plus cher que la propriété. Faites les calculs à votre utilisation projetée de l'année 3. Parfois, la construction personnalisée gagne sur la pure économie.
---
Quand acheter est clairement le bon choix
De même, certaines situations rendent l'achat évident :
- Vous êtes pre-revenue ou pre-product-market fit. C'est tout.
- La fonction est l'infrastructure de commodité, email, paiements, authentification, stockage, analytics.
- Vous en avez besoin qui fonctionne ce trimestre, pas cette année.
- Votre équipe n'a pas de capacité engineering en interne et vous ne pouvez pas vous permettre d'embaucher correctement.
J'ajouterais aussi : si tu construis en tant que fondateur pour éviter de prendre une décision commerciale plus difficile, ça vaut le coup d'examiner. Les constructions sur mesure peuvent être une forme très coûteuse de procrastination.
---
L'approche hybride (souvent le mouvement le plus intelligent)
Voilà ce que personne ne dit assez : construire et acheter ne s'excluent pas mutuellement.
L'approche la plus pragmatique que j'ai vu fonctionner régulièrement est celle-ci : acheter les pièces de commodité agressivement, et construire la fine couche de logique différenciée par-dessus. Votre CRM est HubSpot. Votre support desk est Intercom. Mais le moteur de workflow bespoke qui les connecte et automatise votre processus spécifique ? C'est deux semaines de développement sur mesure, pas six mois.
Chez Seahawk, nous avons construit des centaines de sites sur WordPress, une plateforme achetée, avec des plugins personnalisés qui font des choses véritablement novatrices. La plateforme gère les 80%. Nous construisons les 20% qui importent. C'est un conseil ennuyeux. C'est aussi le conseil qui a marché le plus souvent.
---
FAQ
Comment sais-je si mon cas d'usage est vraiment assez unique pour justifier une construction custom ?
Réponse honnête : la plupart ne le sont pas. Commencez par passer un après-midi sérieux, je veux dire quatre ou cinq heures, pas vingt minutes, à cartographier chaque produit SaaS de votre catégorie. Si vous avez fait ça et rien ne couvre votre besoin fondamental, demandez-vous si cette exigence est vraiment nécessaire maintenant ou si c'est un « nice-to-have » que vous avez élevé en bloqueur. Si c'est vraiment nécessaire et vraiment non couvert, c'est un signal qui vaut la peine d'être pris au sérieux.
Quelle est l'équipe minimale dont vous avez besoin pour posséder responsablement un logiciel custom ?
Au minimum : un développeur qui comprend profondément la base de code, et soit un deuxième développeur soit une agence en contrat qui puisse assurer quand il est indisponible. Posséder un logiciel sur mesure avec un seul freelancer et pas de secours est une position fragile. J'ai vu ça causer des dégâts opérationnels réels quand cette personne devient indisponible, vacances, maladie, une meilleure proposition d'emploi.
Devrais-je développer en interne ou engager une agence pour construire du sur mesure ?
Cela dépend presque entièrement de si le logiciel est votre cœur de métier. Si vous êtes une entreprise de logiciels, vous voudrez presque certainement une équipe interne à terme, même si vous commencez par une agence. Si le logiciel est un outil qui soutient votre activité plutôt que l'activité elle-même, une relation avec une agence assortie d'un vrai SLA est généralement plus rentable que d'embaucher des ingénieurs à temps plein.
L'open-source est-il une voie intermédiaire entre construire et acheter ?
Oui, et c'est sous-utilisé. Des outils comme Metabase pour l'analytics, Directus pour un CMS headless, ou ERPNext pour les opérations vous donnent la flexibilité d'un logiciel sur mesure avec un coût de construction initial significativement plus faible. Le hic : vous possédez toujours l'infrastructure et vous avez toujours besoin de quelqu'un de technique pour la gérer. Ce n'est pas gratuit, c'est juste moins cher au démarrage.
---
Une Dernière Réflexion
La question construire ou acheter n'a pas une réponse. Elle a ta réponse, spécifique à ton stade, ton équipe, ta position compétitive, et ce que tu as réellement validé jusqu'à présent.
Ce sur quoi je reviendrais est le romantisme autour de la construction. Un logiciel sur mesure n'est pas intrinsèquement plus sérieux, plus scalable, ou plus impressionnant qu'une pile SaaS bien configurée. Le fondateur de facturation que j'ai mentionné au début ? Il a finalement construit quelque chose vraiment sur mesure, mais seulement après dix-huit mois d'utilisation d'Invoice Ninja qui lui avait appris exactement ce que ses clients avaient vraiment besoin. La construction valait mieux d'avoir attendu.
Commencez par l'option ennuyeuse. Gagnez le droit de construire quelque chose de nouveau.
Lectures connexes : Building a Real-Time Auction Site with Next.js & Supabase, développement web sur mesure et Next.js.