Build, buy ou no-code : la décision qui engage votre runway autant que votre architecture

Un fondateur tech me montre fièrement son backend. Authentification maison, système de paiement custom, file d’attente d’emails réécrite « pour avoir le contrôle ». Trois mois de travail. Le problème : il n’avait encore aucun client payant, et son ICP n’était pas validé. Il avait construit une cathédrale avant de savoir si quelqu’un viendrait prier.

À l’inverse, j’ai vu une startup assembler tout son produit en no-code, signer ses dix premiers clients en six semaines… puis se cogner à un mur quand le onzième a demandé une intégration que la plateforme ne permettait pas. Deux erreurs opposées, une même racine : la décision build / buy / no-code a été prise par réflexe, pas par arbitrage.

Ce que la plupart des startups ratent

La question n’est presque jamais « est-ce qu’on est capables de le construire ? ». Une bonne équipe tech est capable de construire à peu près n’importe quoi. La vraie question, c’est : « est-ce que ce composant mérite qu’on y dépense de la semaine-ingénieur, alors que cette ressource est la plus rare de toute l’entreprise ? »

Chaque ligne de code que vous écrivez est une ligne que vous devrez maintenir, sécuriser, documenter et faire évoluer. Le coût d’un build ne se paie pas une fois : il se paie tous les mois, sous forme de charge cognitive et de dette potentielle. Une startup pre-seed avec deux développeurs ne dispose pas de deux développeurs : elle dispose d’environ 320 heures de focus par mois, dont la moitié partira en réunions, en support et en bugs imprévus. Le vrai budget, c’est ça.

Et c’est là que stratégie et architecture se rejoignent. Décider de builder l’authentification, ce n’est pas un choix technique neutre : c’est décider de retirer deux à trois semaines de votre runway à un sujet qui n’apporte aucune valeur perçue par le client. Personne n’a jamais signé un contrat parce que votre système de login était fait maison.

La règle simple : construisez ce qui vous différencie, achetez le reste

Il existe une heuristique qui résout 80 % des cas. Posez-vous une question : ce composant fait-il partie de ce qui rend votre produit unique sur le marché ?

Si la réponse est oui — votre algorithme de matching, votre moteur de recommandation, la logique métier qui justifie que le client vous paie — alors construisez. C’est votre cœur, votre avantage défendable, l’endroit où la dette technique finit par être un investissement parce que vous y reviendrez sans cesse.

Si la réponse est non — paiement, authentification, emails transactionnels, monitoring, gestion des fichiers, recherche — alors achetez. Stripe, Clerk ou Auth0, Resend ou Postmark, Algolia : ces briques sont commoditisées, testées par des millions d’utilisateurs, conformes au RGPD par défaut, et coûtent une fraction de ce que vous dépenseriez à les réécrire mal. Le « contrôle » que vous croyez gagner en buildant est souvent une illusion : vous échangez une dépendance fournisseur claire contre une dépendance à votre propre code obscur, écrit à 23h un soir de sprint.

Le piège du fondateur tech, c’est précisément d’inverser cette règle : builder les briques commodité parce que c’est « intéressant » techniquement, et négliger le cœur produit parce qu’il est moins satisfaisant à coder. Le marché ne récompense pas l’élégance de votre infrastructure. Il récompense le problème que vous résolvez mieux que les autres.

Le no-code n’est pas un sous-produit : c’est un instrument de validation

Le no-code souffre d’un malentendu. Beaucoup d’équipes tech le considèrent comme un jouet, ou au mieux un prototype jetable. C’est une erreur de cadrage. Le no-code n’est pas « moins bien que du code » : c’est plus vite que du code, ce qui, avant la validation de votre ICP, est la seule métrique qui compte.

Avant le product-market fit, votre objectif n’est pas de construire un produit scalable. C’est d’apprendre, vite, ce que les gens veulent vraiment, et de le prouver avec des clients réels. Un MVP assemblé sur Bubble, Softr ou Airtable, avec quelques automatisations Make ou n8n, peut valider une proposition de valeur en deux semaines là où un build « propre » en prendrait deux mois. Sur ces deux mois économisés, vous aurez peut-être appris que votre hypothèse de départ était fausse — et vous l’aurez appris pour quelques centaines d’euros au lieu de plusieurs dizaines de milliers.

Là où le no-code devient dangereux, c’est quand on confond validation et passage à l’échelle. Une plateforme no-code impose des plafonds : limites d’appels API, modèles de données rigides, impossibilité de gérer certaines logiques complexes ou des volumes importants. Le bon usage consiste donc à traiter le no-code comme un échafaudage explicite. Vous l’utilisez pour apprendre et générer du chiffre d’affaires, et vous planifiez sa réécriture au moment où la traction l’exige — pas avant, pas par principe. La startup qui réécrit son no-code en code « propre » avec dix clients payants prend une bonne décision. Celle qui le réécrit avec zéro client par fierté d’ingénieur reproduit l’erreur de la cathédrale.

Arbitrer selon le stade : pre-seed, seed, série A

La même décision n’a pas la même réponse selon où vous en êtes, parce que ce qui est rare change.

En pre-seed, la ressource rare est le temps d’apprentissage. Tout doit servir à valider ou invalider une hypothèse. Penchez fortement vers le no-code et les briques achetées. Buildez uniquement le strict nécessaire de votre différenciateur, et acceptez que ce soit imparfait. Votre dette technique à ce stade est largement théorique : la moitié de ce que vous codez sera jetée de toute façon.

En seed, vous avez une traction initiale et probablement levé de quoi tenir 18 mois. La ressource rare devient la capacité à scaler ce qui marche sans s’effondrer sous le support. C’est le moment de migrer les parties no-code qui plient sous la charge, de consolider votre cœur produit en code maintenable, et de continuer à acheter tout ce qui n’est pas différenciant. C’est aussi le bon moment pour structurer un minimum votre architecture autour de votre modèle de pricing — parce qu’une décision tarifaire mal anticipée se paie en refonte technique six mois plus tard.

En série A, la ressource rare est la fiabilité et la vélocité d’équipe. Le build prend plus de sens sur les composants critiques où la dépendance fournisseur devient un risque stratégique ou un coût significatif à l’échelle. Mais même là, la règle tient : on n’internalise une brique commodité que lorsqu’un calcul précis le justifie — volume, coût, conformité, ou besoin d’un comportement que le marché ne propose pas. Internaliser par défaut reste une erreur, juste plus chère.

Ce qu’il faut vraiment faire

Avant chaque décision de composant, faites un arbitrage explicite, écrit, en trois minutes. Demandez-vous : est-ce que ce truc me différencie ? Combien de semaines-ingénieur coûte le build, maintenance comprise ? Existe-t-il une brique achetable conforme RGPD à un coût raisonnable ? Et puis-je le valider en no-code avant de m’engager ?

Concrètement : achetez l’authentification, le paiement, les emails, le monitoring, la recherche — sans débat, sauf cas exceptionnel. Validez votre proposition de valeur en no-code tant que votre ICP n’est pas verrouillé. Construisez votre cœur produit, et seulement lui, dès que vous savez qu’il mérite l’investissement. Et inscrivez vos morceaux no-code dans une logique d’échafaudage : sachez à quel signal de traction vous les remplacerez, pour ne réécrire ni trop tôt, ni trop tard.

Le fil conducteur, c’est que chaque décision build / buy / no-code est simultanément une décision de runway et une décision d’architecture. Les deux se déterminent mutuellement. Un fondateur qui sépare les deux conversations — « ça, c’est une question de tech », « ça, c’est une question de finances » — prend de mauvaises décisions sur les deux plans.

La vraie question à se poser n’est donc pas « qu’est-ce qu’on est capables de construire ? », mais « qu’est-ce qui mérite qu’on retire du temps à notre survie pour le construire ? ». Posez-la à chaque composant, et vous découvrirez que la plupart de ce que vous vouliez coder ne valait pas le prix de votre runway.