Le code est devenu gratuit. Construire un vrai business, lui, ne l'est toujours pas.

Cette semaine, j’ai parlé à six fondateurs qui m’ont dit avoir “lancé” un SaaS avec Claude Code ou Cursor.

Cinq d’entre eux ont un prototype qui marche. Aucun n’a encore un vrai produit en production avec des clients qui paient.

Et ce n’est pas un problème de technologie.

Le pattern du vibe coding 2026

Depuis dix-huit mois, je vois passer la même séquence chez des entrepreneurs très différents — fondateurs first-time, anciens salariés tech, opérationnels qui voulaient prouver qu’ils pouvaient construire un produit.

Tu démarres un weekend avec Claude Code ou Cursor. En quelques heures, t’as une UI. En quelques jours, t’as un flow utilisateur. En deux semaines, t’as un prototype qui ferait passer ce que tu construisais en 2018 en six mois pour une démo bricolée.

L’effet est grisant. Tu vois enfin ce que tu avais en tête depuis des années sans pouvoir le coder. Tu te dis : cette fois, je vais le faire.

Puis tu essaies de le mettre entre les mains de vrais utilisateurs. Et là, ça se complique.

Le gap que personne ne pitche en démo

Entre un prototype qui fait waouh et un produit que tu peux vraiment vendre à des entreprises B2B, il y a une liste de sujets qu’aucune vidéo de vibe coding ne montre.

La sécurité. Pas la sécurité “j’ai mis du HTTPS” — la sécurité réelle, celle d’un audit que ton premier client enterprise va te demander. Les permissions, les logs, l’authentification, la gestion des secrets, les attaques par injection que ton code généré n’a pas anticipées.

La délivrabilité. Si ton produit envoie des emails, prépare-toi à passer six mois à comprendre SPF, DKIM, DMARC, le warming d’IP, les blacklists, et pourquoi tes mails partent en spam chez 40% de tes utilisateurs.

Les comportements non maîtrisés. C’est le sujet qui m’inquiète le plus chez les boîtes que je vois construire avec des agents IA en production. Quand le LLM décide de quelque chose que tu n’as ni testé ni anticipé, tu portes la responsabilité — réglementaire, contractuelle, parfois personnelle.

Le support. Le legal. Le RGPD. La facturation. Les bugs liminaires qui n’apparaissent qu’à 200 utilisateurs simultanés. Les intégrations que ton client te demande dès le deuxième call.

Aucun de ces sujets n’est bloquant pour un prototype. Tous sont bloquants pour un vrai produit.

Pourquoi la plupart abandonnent à ce moment-là

Ce n’est pas la techno qui les arrête. Claude et Cursor peuvent t’aider sur 80% de ces sujets.

Ce qui les arrête, c’est l’addition. La somme de tout ce qu’il faut résoudre, en plus du produit lui-même, pour avoir le droit d’être pris au sérieux par une vraie boîte.

Et là, je vois deux scénarios.

Le premier : le fondateur se disperse. Il se met à coder un système d’auth maison, puis un facturateur custom, puis une intégration Salesforce, puis un dashboard analytics. Six mois plus tard, il a réécrit la moitié de Stripe et de Auth0 — et son produit n’a toujours pas trouvé son marché.

Le second : le fondateur abandonne discrètement. Il garde le projet en side project, il revient sur sa boîte principale, et il rachète un outil existant pour résoudre le problème qu’il prétendait résoudre. Ce qui est, soyons honnêtes, souvent la décision rationnelle.

Mais le pattern, dans les deux cas, n’est pas un problème technique. C’est un problème de focus.

Ce que j’aurais sous-estimé pour Sortlist

Quand j’ai commencé Sortlist, si on m’avait montré un quart de la moitié de ce qu’il faudrait faire pour atteindre €10M d’ARR, je ne suis pas certain que j’aurais commencé.

Pas le code. Le code n’a jamais été le problème — pas en 2014, et encore moins en 2026.

Ce que j’aurais sous-estimé, c’est tout le reste. Les neuf pays à ouvrir un par un avec des spécificités locales différentes. Les trois pivots de modèle économique qu’il faudrait faire. Les recrutements que je raterais. La compliance dans chaque juridiction. Les contrats clients qui mettent six semaines à se signer parce que le service achats demande un audit ISO. Les boards où il faut défendre des décisions que tu trouves toi-même fragiles. Les onze ans de constance.

Aucun outil n’a réduit cette part-là. Ni en 2014, ni aujourd’hui.

Et c’est exactement le piège du vibe coding aujourd’hui : on a réduit massivement le coût de la première étape — la construction du produit — et ça donne l’illusion qu’on a réduit le coût de toutes les étapes. C’est faux.

Le coût réel d’un business n’a pas changé

Le code est devenu quasi-gratuit. Construire une vraie boîte, lui, coûte exactement la même chose qu’avant.

Ce qui coûte, ce n’est plus écrire la première version. C’est :

Trouver les dix premiers clients qui paient vraiment et qui restent
Comprendre précisément le problème que tu résous, pour qui, et pourquoi
Tenir un focus sur une seule chose pendant 18 à 36 mois sans te disperser
Construire les processus d’opérations, de support, de compliance qui font qu’une boîte tient
Recruter les bonnes personnes au bon moment, et pas trois mois trop tôt
Refuser 90% des bonnes idées pour pouvoir en exécuter 10% correctement

Aucun de ces sujets n’est attaqué par Claude Code, Cursor, ou un agent IA. Ce sont des sujets de focus, de discipline, et de patience. Les sujets que les fondateurs ont toujours eu du mal à tenir, et que la facilité de prototypage rend, paradoxalement, encore plus difficiles.

Parce que quand chaque idée nouvelle peut être prototypée en un weekend, la tentation de toutes les prototyper devient irrésistible. Et tu te retrouves avec un cimetière de prototypes au lieu d’un produit.

Les principes qui restent vrais en 2026

Trois principes anciens, parfois moqués, sont devenus plus importants que jamais.

Focus is king. Une seule cible client. Un seul problème. Un seul use case que tu nailes complètement avant de regarder à côté. Tous les fondateurs le savent. Aucun ne le fait vraiment, parce que dire non à 95% des opportunités demande une discipline qui ne s’apprend pas en lisant un livre.

Ship more, ship faster. Pas pour produire plus de fonctionnalités. Pour apprendre plus vite. Chaque release que tu mets entre les mains d’utilisateurs réels te donne plus d’information que trois semaines de planning. Le vibe coding rend cette boucle plus courte que jamais — à condition que tu ne confondes pas “j’ai un prototype” avec “j’ai shippé”.

KISS — Keep It Simple, Stupid. En 2026, c’est presque devenu un acte de résistance. Quand l’IA te permet de coder une fonctionnalité en une heure, le piège est d’en ajouter dix avant d’avoir validé que la première était bonne. Le produit qui gagne en B2B reste celui qui fait une chose mieux que tout le monde — pas celui qui en fait quinze médiocrement.

Ce que je dirais à un fondateur qui démarre en 2026

Trois conseils, dans cet ordre :

Un — Choisis un problème que tu vis personnellement, ou qu’un client réel te paye déjà pour résoudre à la main. Pas une idée que t’as eue sous la douche. Pas un problème que t’as vu dans un thread LinkedIn. Un problème dont tu peux décrire le coût exact pour un client réel, en euros par mois.

Deux — Construis la pire version possible qui résout ce problème. Vraiment la pire. Une UI moche, des features manquantes, des intégrations à la main. Mais qui résout le problème pour de vrai pour un utilisateur précis. Si t’as honte de la montrer, c’est probablement que c’est juste assez minimal.

Trois — Trouve dix clients qui paient avant d’écrire la deuxième version. Pas dix utilisateurs gratuits. Dix clients qui sortent une carte bancaire. Si t’arrives pas à dix après trois mois d’efforts sérieux, le problème n’est pas dans le produit — il est dans le problème que tu as choisi.

Le vibe coding ne te dispense d’aucune de ces trois étapes. Il te permet juste de les faire avec moins d’argent qu’avant. C’est un avantage massif si tu as la discipline. C’est un piège si tu ne l’as pas.

La conclusion courte

Le goulot d’étranglement d’une boîte tech a changé de place.

En 2014, c’était souvent le code. En 2026, ce n’est presque plus jamais le code. C’est le focus, la discipline, et la capacité à dire non à toutes les fonctionnalités que ton outil te permet de construire en deux heures.

L’IA a démocratisé la construction. Elle n’a pas démocratisé le business. Et la plupart des fondateurs qui se lancent aujourd’hui vont apprendre cette leçon à leurs frais — pas parce qu’ils ne savent pas coder, mais parce qu’ils n’ont pas encore compris que coder n’a jamais été l’essentiel.

Si tu démarres aujourd’hui : prototype moins, ship plus, et choisis le seul problème que tu acceptes de défendre pendant les cinq prochaines années.

Le reste, c’est du bruit.

Thibaut Vanderhofstadt est co-fondateur de Sortlist — leader européen de la mise en relation B2B, présent dans plus de 140 pays. Il accompagne aujourd’hui des fondateurs SaaS, marketplace et entreprises ambitieuses via MetSaaS. Réserver un diagnostic →