Un client m'a appelé en 2021 — la vraie panique dans la voix. Il avait dépensé 140 000 £ sur quatorze mois pour construire une plateforme de facturation personnalisée. Son équipe de développement avait livré environ 60 % des spécifications. Et vers le onzième mois, il avait découvert qu'Invoice Ninja existait, était open-source, et faisait 90 % de ce dont il avait besoin d'emblée. Gratuitement.Invoice Ninjaexisted, was open-source, and did 90% of what he needed out of the box. For free.
Cet appel me hante un peu. Parce que l'honnête réponse est : j'ai commis l'erreur inverse aussi. 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 personnalisé — pour gérer un flux de travail client qui, rétrospectivement, aurait pu être résolu proprement et durablement par une construction personnalisée de 15 000 £. Nous payions à peu près 900 £/mois en abonnements combinés à la fin. Fais les maths sur trois ans.
Aucun des deux extrêmes n'est automatiquement le bon. Et quiconque te vend une règle nette — « toujours construire », « ne jamais construire » — vend quelque chose. Voici donc le vrai cadre que j'utilise quand un fondateur 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 « dois-je construire ou acheter ? », ce que tu demandes vraiment, c'est : où se situe la différenciation dans mon produit ? Si ce que tu envisages de construire est au cœur de ton avantage concurrentiel — la raison pour laquelle les clients te choisiront plutôt que l'onglet suivant de leur navigateur — alors construire a probablement du sens. Si c'est de l'infrastructure, de l'administration, ou une fonctionnalité standard, acheter est presque certainement moins cher en termes réels.reasoncustomers will choose you over the next tab in their browser — then building probably makes sense. If it's infrastructure, admin, or commodity functionality, buying is almost certainly cheaper in real terms.
Je pose d'abord une question aux fondateurs : Tes utilisateurs verront-ils jamais cette chose ? Si la réponse est oui et que cela façonne leur expérience de manière significative, cela vaut peut-être la peine de construire. Si c'est du back-office, opérationnel, ou interne, le seuil pour justifier de construire devrait être très élevé.Will your users ever see this thing?If the answer is yes and it shapes their experience in a meaningful way, it might be worth building. If it's back-office, operational, or internal, the bar for building should be very high.
---
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 coût unique. Tu en es responsable pour toujours à moins de l'abandonner.Not a one-off. You're on the hook forever unless you sunset the thing.
- Correctifs de sécurité. Un fournisseur SaaS s'en charge pour toi. Tu le construis, tu en es propriétaire, y compris les alertes à 2h du matin.A SaaS vendor handles this for you. You build it, you own it, including the 2am alerts.
- Onboarding de nouveaux développeurs. Si ton ingénieur principal part, la personne suivante doit apprendre ta base de code. C'est des semaines de temps facturable.If your lead engineer leaves, the next person needs to learn your codebase. That's weeks of billable time.
- L'expansion des fonctionnalités. Les parties prenantes voient un outil sur mesure et supposent qu'il peut tout faire. Le périmètre s'élargit. Les coûts suivent.Stakeholders see a custom tool and assume it can do everything. Scope expands. Costs follow.
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 tourne autour de 45-50% des projets qui sont « en difficulté » ou qui échouent carrément. Ce n'est pas une raison de ne jamais construire — c'est une raison d'y aller les yeux ouverts.Standish Group's CHAOS Reporthas been showing for decades that software projects overrun their budgets at an alarming rate. The number sits around 45-50% of projects being "challenged" or outright failing. That's not a reason to never build — it's a reason to go in clear-eyed.
---
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 forfait à 49 £/mois qui semblait raisonnable au début de l'année a la fâcheuse habitude de devenir 490 £/mois au bout de trois ans — une fois que vous êtes passé à un forfait supérieur, vous avez ajouté des utilisateurs, et le fournisseur a fait une « restructuration tarifaire » (lisez : augmentation). J'ai vu cela arriver à des clients chez Salesforce, Intercom et Mixpanel. Ce n'est pas malveillant. C'est simplement 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 un travail d'ingénierie de données important.Your data is in their format, their schema, their export flow. Leaving is painful and sometimes effectively impossible without significant data engineering work.
- La complexité de la pile Frankenstein. Cinq outils qui s'intègrent vaguement via Zapier n'est pas un système. C'est un passif. Une dépréciation d'API et les choses commencent à s'effondrer.Five tools that sort-of integrate via Zapier is not a system. It's a liability. One API deprecation and things start falling apart.
- L'inflation des abonnements. Personne n'audite sa stack d'outils annuellement. Ils devraient. J'ai fait 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.Nobody audits their tool stack annually. They should. I ran an audit for a 12-person agency last year and found £3,200/month in SaaS they'd either stopped using or were using for one feature each.
Cela dit — pour les fonctions de base, SaaS est presque toujours le bon choix. Livraison d'e-mails ? Postmark ou SendGrid. Paiements ? Stripe, bien évidemment. Auth ? Auth0 ou Clerk. Personne ne devrait construire son propre processeur de paiement en 2024.Postmarkor SendGrid. Payments? Stripe, obviously. Auth? Auth0 or Clerk. Nobody should be building their own payment processor in 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 votre produit véritablement différent — construire mérite une considération sérieuse. Si non, arrêtez-vous là. Achetez.
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 à rechercher le marché des SaaS avant de jamais recommander une construction personnalisée. Product Hunt et G2 sont véritablement utiles ici — pas comme parole d'évangile mais comme un inventaire de départ.Product Huntand G2 are genuinely useful here — not as gospel but as a starting inventory.
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. Une solution sur mesure demande au minimum quelques semaines, généralement des mois. Si la rapidité compte — et dans les startups en phase précoce c'est presque toujours le cas — acheter vous permet de gagner du temps pour apprendre ce dont vous avez vraiment besoin avant de vous engager à le construire.
En 2022, Seahawk a travaillé avec une startup de logistique qui voulait un tableau de bord d'optimisation des itinéraires sur mesure. Nous les avons convaincus d'utiliser d'abord une couche API avec marque blanche (ils ont commencé avec Route4Me). Six mois plus tard, ils savaient exactement quelles trois fonctionnalités leurs clients recherchaient vraiment. La solution sur mesure qu'ils ont finalement commandée avait la moitié de la portée initiale — et était deux fois meilleure — parce qu'ils avaient appris en production plutôt que sur un document de spécifications.Route4Meas a starting point). Six months later, they knew exactly which three features their customers actually cared about. The custom build they eventually commissioned was half the scope — and twice as good — because they'd learned in production rather than in a spec document.
Question 4 : Que se passe-t-il quand ça tombe en panne ?
Parce que ça va tomber en panne. La question est qui le répare et à quelle vitesse. Avec du SaaS, vous déposez un ticket support et vous vous plaignez sur Twitter. Avec du logiciel sur mesure, vous appelez votre équipe de développement. Si vous n'avez pas d'équipe de développement retenue, vous êtes en mauvaise posture. Ce n'est pas hypothétique — 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 IP fondamentale est le logiciel lui-même. Si vous vendez un produit SaaS, vous ne pouvez pas externaliser la chose que vous vendez.If you're selling a SaaS product, you can't outsource the thing you're selling.
- Les exigences réglementaires signifient que du prêt-à-l'emploi ne suffira pas. Certaines applications fintech, santé et juridiques ont des contraintes de conformité que la plupart des outils SaaS ne sont pas conçus pour satisfaire.Certain fintech, healthcare, and legal applications have compliance constraints that most SaaS tools aren't built to satisfy.
- 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.This is the best possible position to be in before commissioning a custom build.
- Le prix SaaS à grande échelle est genuinely plus cher que la possession. Faites les calculs sur votre utilisation projetée en année 3. Parfois le custom gagne sur la pure économie.Do the maths at your projected Year 3 usage. Sometimes custom wins on pure economics.
---
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 une infrastructure commodity — 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 vous construisez en tant que fondateur pour éviter une décision commerciale plus difficile, cela vaut la peine d'examiner. Les builds personnalisés peuvent être une forme très coûteuse de procrastination.to avoid making a harder business decision, that's worth examining. Custom builds can be a very expensive form of 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 vue fonctionner régulièrement, c'est celle-ci — acheter agressivement les éléments standard, et construire la fine couche de logique différenciée par-dessus. Votre CRM, c'est HubSpot. Votre support desk, c'est Intercom. Mais le moteur de workflow sur mesure qui les relie et automatise votre processus spécifique ? C'est deux semaines de dev custom, pas six mois.
Chez Seahawk, nous avons construit des centaines de sites sur WordPress — une plateforme achetée — avec des plugins custom qui font des choses véritablement novatrices. La plateforme gère les 80 %. Nous construisons les 20 % qui comptent. 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 dis quatre ou cinq heures, pas vingt minutes — à cartographier chaque produit SaaS de votre catégorie. Si vous l'avez fait et qu'aucun ne couvre votre besoin fondamental, demandez-vous si ce besoin est vraiment nécessaire maintenant ou s'il s'agit d'une fonctionnalité sympathique que vous avez élevée au rang de blocker. Si c'est véritablement nécessaire et véritablement non couvert, c'est un signal qui mérite d'être pris au sérieux.necessary right nowor whether it's a nice-to-have you've elevated into a blocker. If it's truly necessary and truly unserved, that's a signal worth taking seriously.
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, plus soit un deuxième développeur, soit une agence conservée qui peut prendre le relais en son absence. Posséder un logiciel personnalisé avec un seul freelance et sans plan B, c'est une position fragile. J'ai vu cela causer des dégâts opérationnels réels quand cette personne devient indisponible — congés, maladie, une meilleure offre 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-exploité. Des outils comme Metabase pour l'analytique, Directus pour un CMS headless, ou ERPNext pour les opérations vous donnent la flexibilité d'un logiciel sur mesure avec un coût initial de développement considérablement inférieur. Le hic : vous possédiez toujours l'infrastructure et vous avez quand même besoin de quelqu'un de technique pour la gérer. Ce n'est pas gratuit — c'est juste moins cher au démarrage.Metabasefor analytics, Directus for headless CMS, or ERPNext for operations give you the flexibility of custom software with significantly lower initial build cost. The catch: you're still owning infrastructure and you still need someone technical to manage it. It's not free — it's just cheaper to start.
---
Une Dernière Réflexion
La question construire ou acheter n'a pas une réponse. Elle a votre réponse, spécifique à votre stade, votre équipe, votre position concurrentielle, et ce que vous avez vraiment validé jusqu'ici.youranswer, specific to your stage, your team, your competitive position, and what you've actually validated so far.
Sur quoi j'irais à contre-courant, c'est le romantisme autour du développement. Un logiciel sur mesure n'est pas intrinsèquement plus sérieux, plus scalable, ou plus impressionnant qu'une stack SaaS bien configurée. Le fondateur en facturation dont j'ai parlé au début ? Il a finalement construit quelque chose vraiment sur mesure — mais seulement après dix-huit mois avec Invoice Ninja qui lui a appris exactement ce que ses clients avaient vraiment besoin. La construction était meilleure pour l'attente.
Commencez par l'option ennuyeuse. Gagnez le droit de construire quelque chose de nouveau.