Le build n'est plus le goulot d'étranglement

Construire un SaaS, ce n'est plus ça le plus dur. Depuis presque deux ans, on lance des apps en production avec des agents IA, de Claude 3.5 Sonnet jusqu'à Claude Fable 5, et le goulot d'étranglement s'est déplacé deux fois. Ce n'est pas la recherche. Ce n'est pas le code. Les deux trucs qui font encore mal, c'est l'assurance qualité à grande échelle et la distribution.

Voilà ce qu'on a appris en regardant de vraies personnes construire sur notre stack, et ce qui a changé à chaque nouveau modèle.

---

---

Le build a été réglé plus vite que prévu

Il y a deux ans, le mur c'était le build lui-même. Auth, paiements, sécurité de la base de données, e-mails, jobs en arrière-plan. Des mois de plomberie avant même de toucher au produit. Ce mur a disparu. Avec un bon moteur et un vrai codebase de production en dessous, un MVP qui prenait un mois prend maintenant une journée.

On ne s'attendait pas à ce que ça aille aussi vite. On a démarré sur Claude 3.5 Sonnet, on a vu toute la lignée Sonnet et Opus s'améliorer version après version, et chacune nous a laissés lâcher un peu plus la bride aux agents. Le code a arrêté d'être notre souci. Ça sonne comme la ligne d'arrivée. Ça ne l'est pas. Ça révèle juste ce qui se cachait derrière le build depuis le début.

Nouveau goulot d'étranglement n°1 : le QA à grande échelle

Le problème le plus dur encore non résolu en développement IA, en ce moment, c'est l'assurance qualité, pas la génération. Générer une feature, c'est pas cher. Prouver qu'elle marche, en volume, sans qu'un humain surveille chaque run, c'est ça que personne n'a vraiment cracké.

Voilà la limite concrète qu'on a touchée : on n'arrivait pas à faire tourner plus de quatre features en parallèle avant que ça parte en vrille. Au-delà, les runs de test se télescopaient, l'état dérivait, et les agents de test partaient parfois en boucle, à relancer et revérifier sans jamais converger. Le côté build a passé l'échelle. Le côté vérification, non. Cet écart, c'est le vrai plafond de l'autonomie aujourd'hui, et quiconque te dit qu'il fait tourner des essaims d'agents totalement autonomes à grande échelle résout (ou ignore) discrètement ce problème précis.

De meilleurs modèles aident, parce qu'un modèle plus capable garde plus de contexte et fait moins des erreurs qu'il faut rattraper. Mais le QA à grande échelle reste la frontière. C'est là que se trouve le prochain vrai déclic.

Nouveau goulot d'étranglement n°2 : la distribution

Le second mur, c'est la distribution, et c'est dans celui-là que la plupart des builders foncent tête baissée. Quand construire prenait des mois, la distribution semblait être un problème pour plus tard. Maintenant que construire prend une journée, la distribution est tout le jeu. Tu peux lancer un super produit en un week-end et que personne ne le voie jamais.

C'est pour ça qu'on n'a pas juste construit un build system. On a construit un écosystème : quelque chose pour construire, et quelque chose pour distribuer. Topr.io est notre réponse côté distribution, une marketplace de UGC bâtie sur la même stack Build This Now, visant pile la partie qui est devenue plus dure, pas plus facile. La leçon derrière est simple. Si construire devient une commodité, le fossé défensif c'est de se faire trouver.

Ce que Fable 5 change : plus de marge pour avancer

Claude Fable 5 est le tout nouveau modèle d'Anthropic pour le travail complexe et de longue haleine, et la différence pratique, c'est la liberté que tu peux lui confier. Tu peux lui donner plus de marge, des tâches plus longues, plus d'autonomie en un seul passage, et il tient le coup. Pour un moteur d'agents, c'est la variable qui compte le plus. Plus un modèle enchaîne une longue chaîne sans dériver, plus il absorbe le problème du QA tout seul.

On a vécu chaque étape de cette courbe. Voici en gros comment le goulot d'étranglement s'est déplacé :

Fable 5 coûte plus cher qu'Opus 4.8 ($10 en entrée / $50 en sortie par million de tokens) parce qu'il est fait pour les runs longs, durs et autonomes. Pour le code de tous les jours, Opus 4.8 reste le meilleur rapport qualité-prix. Pour les jobs où tu veux confier une longue tâche et partir, cette marge en plus, c'est tout l'intérêt.

Le truc contre-intuitif : les fondamentaux comptent plus maintenant, pas moins

Voilà ce qui nous a le plus surpris. Plus construire est devenu rapide, plus les vieux fondamentaux des startups comptaient.

Quand tu peux construire n'importe quoi en une journée, la tentation c'est d'en construire dix. C'est le moyen le plus rapide d'échouer. L'IA n'abroge pas les lois des startups. Elle industrialise l'étape du build et laisse toutes les autres lois exactement où elles étaient. La concentration. La différenciation. Le souci du détail. Choisis une chose, fais-la bien, lance-la avant tout le monde.

Si quoi que ce soit, la vitesse augmente les enjeux sur les fondamentaux, parce que tout le monde peut maintenant aller aussi vite sur le build. Le build n'est plus ton avantage. Les premiers principes, si.

Comment on construit maintenant

Le schéma qui marche, à chaque fois :

1. Reviens aux premiers principes. Réduis l'idée à la seule chose qu'elle doit faire. Pas la roadmap. La seule chose.
2. Lance le premier MVP en 24 heures. Pas une semaine. Pas deux. Une journée. Le tooling rend ça réel maintenant, alors traite-le comme le défaut, pas l'objectif lointain.
3. Cours vers le product-market fit. Le MVP existe pour avoir du feedback, pas des applaudissements. Mets-le devant des utilisateurs et laisse la réalité te dire quoi construire ensuite.
4. Verse le temps gagné dans la distribution et le QA. C'est là que vivent les vrais problèmes durs. Le build est la partie bon marché maintenant, alors dépense ton attention sur les parties chères.

Fais une chose, fais-la bien, lance-la vite, fais-la trouver. C'est tout le jeu en 2026.

FAQ

Construire un SaaS, c'est encore dur avec l'IA ?

Le code n'est plus le plus dur. Avec un codebase de production et un bon moteur d'agents, un MVP qui prenait un mois prend maintenant à peu près une journée. Les parties difficiles se sont déplacées vers l'assurance qualité à grande échelle et vers la distribution, c'est-à-dire faire trouver ton produit une fois qu'il existe.

Pourquoi les agents IA ne peuvent-ils pas encore faire tourner un nombre illimité de features en parallèle ?

L'assurance qualité ne se parallélise pas aussi proprement que la génération. D'après notre expérience, tu peux faire tourner environ quatre features en parallèle avant que les runs de test se télescopent, que l'état dérive et que les agents de test se mettent à boucler sans converger. Générer des features passe l'échelle ; les vérifier de façon fiable en volume reste la frontière.

Qu'est-ce qui rend Claude Fable 5 différent pour le travail d'agents ?

Claude Fable 5 est fait pour les tâches complexes et de longue haleine, et on peut lui confier plus d'autonomie en un seul passage sans qu'il dérive. Pour un moteur d'agents, cette fiabilité sur de longues chaînes est la propriété la plus importante, parce qu'elle absorbe une partie du fardeau du QA. Son tarif est de $10 en entrée / $50 en sortie par million de tokens.

Si l'IA rend le build rapide, c'est quoi le vrai avantage concurrentiel ?

Les fondamentaux. Quand tout le monde peut construire vite, le build cesse d'être un fossé défensif. L'avantage se déplace vers la concentration, la différenciation, la distribution, et atteindre le product-market fit avant tout le monde. La vitesse augmente les enjeux sur les premiers principes, elle ne les supprime pas.

---

On est passés de « construire, c'est le mur » à « construire, c'est la partie facile » en environ dix-huit mois. Les équipes qui gagnent la prochaine étape ne sont pas celles qui construisent le plus vite. Tout le monde construit vite maintenant. Ce sont celles qui choisissent une chose, la réussissent à fond, et la mettent devant les gens. Vois comment marche tout le pipeline, ou commence à construire dès maintenant.