Construire n'a jamais été le goulot d'étranglement — mais cela faisait trois autres métiers (2026)
By Surya Pratap
5 août 2026
12 min read
Startup Strategy
5 août 2026
12 min read
La plupart des semaines, je lis les fils les plus en vue de r/SaaS et r/startups. D'habitude, c'est un fourre-tout : un lancement, une analyse de désabonnements, les premiers 9 dollars de quelqu'un. Pas cette semaine. Trois fils distincts, venant de trois points de vue complètement différents, décrivaient en fait la même chose sans qu'aucun ne s'en aperçoive.
Un développeur a écrit qu'il peut tout livrer et ne trouve pas une seule idée qui mérite d'être livrée. Une personne salariée a écrit que, lorsqu'un fournisseur se vante d'avoir construit quelque chose en un week-end, elle entend un avertissement. Et un consultant dont le métier consiste désormais à sauver des produits faits en vibe coding a raconté avoir vu un fondateur avec quatre-vingts clients payants ouvrir sa propre app et cliquer partout pour découvrir ce qu'elle faisait quand quelqu'un résiliait en milieu de mois.
Pris séparément, ce sont un problème d'idées, un problème de marketing et un problème de qualité. Pris ensemble, c'est un seul problème, et ce n'est pas celui sur lequel les commentaires ont conclu.
Voici ce que chacun disait réellement, avant que je n'y ajoute la moindre interprétation.
| Fil | Écrit par | Points | Commentaires |
|---|---|---|---|
| « J'en ai assez des fondateurs "je l'ai construit en un week-end avec l'IA" » | Un salarié côté acheteur | 306 | 102 |
| « Je peux construire presque tout. Je ne trouve pas une seule idée de SaaS qui vaille la peine » | Un développeur solide | 129 | 200 |
| « Je peux tout construire. Je n'ai aucune idée de comment intéresser les gens » | Un fondateur qui a livré sans écho | 84 | 108 |
| « Le plus gros problème du vibe coding, ce n'est pas la sécurité » | Un consultant en sauvetage | 81 | 51 |
Deux d'entre eux sont la même phrase tapée par deux personnes différentes dans deux subreddits différents, deux jours différents : je peux tout construire. Personne ne l'a contesté dans aucun des deux fils. Le désaccord portait uniquement sur la suite, et les principaux commentaires se sont nettement partagés entre « tu as un problème d'idées » et « tu as un problème de distribution », avec un troisième camp récurrent pour soutenir que non, en fait, construire reste la partie difficile et que quiconque prétend le contraire s'y prend mal.
Les trois camps décrivent un symptôme. Ce qu'ils ont en commun est plus utile.
Construire un logiciel était lent et cher. Tout le monde s'accorde à dire que c'était mal, et ça l'était le plus souvent. Mais la lenteur faisait trois métiers en plus de produire le logiciel, et elle les faisait de manière invisible, gratuitement, que vous le vouliez ou non.
Elle filtrait vos idées. Elle signalait votre maturité aux acheteurs. Et elle vous apprenait ce que faisait votre propre produit.
L'IA a supprimé le coût. Elle n'a pas remplacé les trois sous-produits. C'est toute la forme des plaintes de cette semaine, et c'est pourquoi les conseils des commentaires tombent toujours à côté : on ne répare pas un sous-produit manquant en travaillant plus dur sur ce qui le produisait autrefois.
Quand une construction vous coûtait six mois ou quatre-vingt-dix mille dollars, vous ne pouviez pas avoir trente idées. Le coût faisait la sélection à votre place. Vous choisissiez celle que vous pouviez défendre devant vous-même à deux heures du matin, et le simple poids de l'engagement imposait un niveau d'examen qui ressemblait à du jugement mais tenait surtout de la peur.
Supprimez le coût, et la contrainte qui forçait le choix disparaît avec lui. Le développeur de ce fil a décrit sa boucle avec précision : brainstormer, tomber sur quelque chose de malin, découvrir que dix entreprises le font déjà ou que personne ne le cherche, construire une version rapide, se rendre compte qu'il ne comprend absolument pas les utilisateurs, recommencer. Il a appelé le résultat un cimetière de choses astucieuses à moitié construites. Ce qui frappe, c'est qu'il a lui-même posé le bon diagnostic : il a écrit qu'il invente des idées depuis sa chaise au lieu de les voler à un problème dans lequel il vit.
C'est tout à fait juste, et il vaut la peine d'être précis sur le pourquoi. Construire est la partie confortable. Elle a une définition de « terminé », elle produit des progrès visibles, et personne ne vous dit non pendant que vous la faites. Deux cents commentaires sont arrivés pour lui dire de parler à des clients, et il le savait déjà. Si les fondateurs se cachent dans la construction, ce n'est pas par ignorance. C'est que la construction est la seule partie du métier qui récompense l'effort par un résultat de façon fiable, et quand elle ne coûte rien, on peut s'y cacher indéfiniment.
Le commentaire le plus incisif du fil a complètement recadré la recherche. Ne dressez pas un inventaire des problèmes, disait-il — dressez un inventaire des agacements. Pas « qu'est-ce qui manque », mais ce que les gens tolèrent en silence et ne mentionnent jamais, parce que cela ne leur semble pas être un vrai problème. Les vingt minutes d'appréhension avant une revue client. Le tableur que quelqu'un refait chaque lundi. Ces choses n'apparaissent jamais dans une analyse concurrentielle, parce que rien n'est techniquement cassé. C'est là que se trouve réellement la disposition à payer.
C'est celui auquel les fondateurs sont le moins préparés, parce qu'il ne s'est pas évaporé : il s'est inversé.
Les acheteurs n'ont jamais eu le moyen d'inspecter votre ingénierie. Ils avaient un indicateur indirect : un logiciel à moitié construit avait l'air à moitié construit. Finitions grossières, états manquants, une page de paramètres laide — tout cela indiquait à peu près combien de travail restait, et les acheteurs le lisaient couramment sans jamais formuler qu'ils le faisaient. La finition était le reçu prouvant qu'on avait survécu aux cas limites.
Désormais, l'enveloppe à l'air fini arrive dès le premier jour. L'indicateur s'est cassé, et le marché a fait ce que font les marchés quand un signal se casse : il l'a remplacé par un signal plus grossier. Le post à 306 points, c'est ce remplacement énoncé à voix haute. Son auteur, un salarié à qui l'on dépose des outils sur le bureau en lui demandant de les intégrer à son travail, a listé ce que son entreprise paie vraiment — que vous soyez encore là au sixième mois, que vous ne perdiez pas nos données, que l'outil fasse la même chose à chaque fois — puis a lâché la phrase sur laquelle tout le fil s'est accordé : arrêtez de vous vanter de la vitesse, parce que pour ceux qui vous paient, c'est un avertissement.
La réserve honnête
Une grande partie des commentaires a accusé ce post d'être un appât à engagement généré par IA, et a demandé à l'auteur de citer un seul vrai produit qui l'avait déçu. Ils ont peut-être raison. Mais ce n'est pas une raison d'écarter le fil — c'est le même phénomène, une couche plus haut. Si l'accusation porte, c'est qu'un résultat d'apparence soignée ne certifie plus l'effort nulle part, y compris dans un post Reddit. L'indicateur de confiance s'est cassé en même temps pour le logiciel et pour la prose, pour la même raison.
La conséquence pratique, c'est que la vitesse a cessé d'être un atout marketing pour devenir discrètement un passif qu'il faut compenser. Rien dans votre texte de lancement ne devrait commencer par la rapidité avec laquelle vous l'avez construit. Ce que les acheteurs recherchent désormais, ce sont des preuves de durée et de conséquences : depuis combien de temps vous tournez, ce qui se passe quand quelque chose casse, qui répond, si leurs données survivent à une mauvaise mise en production. Un fondateur du fil a proposé un indicateur qui mérite d'être repris : comptez combien de conversations de support portent sur le même problème qui revient une deuxième fois. Pas le volume de tickets. Les récidives. C'est une lecture impitoyable des parties de votre produit qui tiennent avec du ruban adhésif, et elle se moque de la vitesse à laquelle vous les avez livrées.
Le fil du consultant en sauvetage est le plus précieux des quatre et celui qui a reçu le moins d'attention, comme c'est généralement le cas.
L'histoire : un fondateur a apporté un produit de réservation qu'il avait construit en vibe coding en quelques week-ends. Il était vraiment bon, soigné, avec environ quatre-vingts clients payants. Puis un client a demandé ce qu'il advient de la part non utilisée d'un abonnement en cas de résiliation en milieu de mois, et le fondateur a ouvert son propre produit et cliqué partout pour le découvrir. Il n'était pas gêné. Pour lui, c'est tout simplement ainsi qu'on découvre ce que fait son produit.
La manière dont le consultant explique en quoi cela diffère de la dette technique est la partie à retenir : la dette suppose que quelqu'un sait lire les comptes. Ici, dès qu'un client conteste un montant, le fondateur doit modifier un comportement qu'il n'a jamais compris, et aucun refactoring ne comble cet écart, car l'écart n'a jamais été dans le code. Les commentateurs ont convergé pour l'appeler dette de compréhension.
Le mécanisme mérite d'être énoncé avec soin, car ce n'est pas « l'IA écrit du mauvais code ». Le code était correct. Ce qui s'est passé, c'est qu'une décision a été prise sans que personne sache qu'une décision était en train d'être prise. Quelqu'un — quelque chose — devait décider ce qu'une résiliation en cours de cycle fait à un solde au prorata. Le modèle a décidé, avec aplomb, d'une manière qui avait l'air plausible à l'écran, et le fondateur n'a jamais vu de point de décision. Comme l'a dit le consultant dans un commentaire ultérieur : écrivez d'abord les décisions, ou le modèle les prendra à votre place.
Son diagnostic est la chose la plus actionnable des quatre fils, et il prend une vingtaine de minutes :
Le test des cinq questions
Écrivez les cinq questions les plus difficiles qu'un client pourrait poser sur le comportement de votre produit. Répondez-y sans ouvrir l'app. Celles auxquelles vous ne pouvez pas répondre sont les parties de l'entreprise que vous ne possédez pas encore.
Un détail de plus tiré du même fil, de la part de quelqu'un qui a mené plusieurs de ces sauvetages : pour la facturation, il circule généralement trois versions de la vérité — ce qui est dans le code, ce qui est dans Stripe, et ce que le fondateur a raconté aux gens dans les e-mails de support. Mettre ces trois versions d'accord, c'est le sauvetage, la plupart du temps. Le travail de code qui suit est la partie facile.
Le fondateur de r/startups — le produit marche, quelques utilisateurs l'adorent, aucune idée de comment intéresser qui que ce soit — a reçu 108 commentaires, et la plupart disaient la même chose en quelques mots : trouve vingt personnes. C'est un bon conseil, et il ne l'a pas aidé, pour une raison qu'un commentateur a nommée avec une précision rare : la plupart des fondateurs sont incapables de dire qui sont ces vingt personnes. Pas le secteur, pas le persona. La situation précise qui fait que quelqu'un a besoin de cela aujourd'hui plutôt qu'au trimestre prochain.
La différence entre « les responsables des opérations dans les entreprises SaaS » et « les responsables des opérations qui viennent de recruter leur premier SDR et se rendent compte qu'ils n'ont aucun processus », c'est la différence entre un canal que l'on peut aller chercher à froid et une catégorie dans laquelle on ne peut que faire de la publicité. Tout le reste — le texte, le canal, le moment — est secondaire.
Il y a eu aussi une bonne réponse à la véritable objection du fondateur, à savoir que publier lui donne l'impression de jouer un rôle et qu'il le fait mal. Deux commentateurs, indépendamment : arrêtez de diffuser et commencez à répondre. Allez là où l'on parle du problème et répondez aux questions, la plupart sans rapport avec votre produit. Répondre, ce n'est pas monter sur scène. Et, par ailleurs, demandez à la poignée de personnes qui utilisent déjà votre outil dans quel fil, forum, Slack ou subreddit elles se trouvaient au moment où le problème les a assez agacées pour qu'elles se mettent à chercher. Cela vous donne trois endroits réels au lieu d'une stratégie de contenu.
Si le diagnostic est que trois choses autrefois gratuites doivent désormais être achetées délibérément, le travail consiste à planifier chaque achat. Concrètement :
Les commentaires ont passé la semaine à se demander si la partie difficile est de construire, d'avoir des idées ou de vendre. C'est un mauvais débat, parce que la réponse change sans cesse et que ce n'a jamais été la question intéressante. La question intéressante, c'est ce qu'un coût payait en silence avant de disparaître.
Six mois de construction vous achetaient autrefois une idée filtrée, un produit crédible et un modèle mental opérationnel de votre propre entreprise. Vous payiez pour une chose et en receviez quatre. Aujourd'hui, vous ne payez rien et en recevez une, et les trois autres doivent être acquises délibérément, par des gens qui, pour la plupart, ne savent pas qu'elles leur manquent.
C'est cela, la vraie compétence d'un fondateur en 2026. Ni le prompting, ni la vitesse de livraison — remarquer lesquels de vos anciens sous-produits gratuits ont cessé d'arriver, et aller les racheter avant qu'un client ne découvre que vous ne les avez jamais eus.
IdeaToMVP Academy
4-week live cohort for founders. Learn to ship AI agents, scope MVPs, and automate your business — taught by the same team that writes these guides.
