Pourquoi le vrai goulot d'étranglement de l'IA, c'est le QA

Aujourd'hui, le problème le plus dur du dev logiciel par IA, c'est l'assurance qualité, pas la génération. Construire des features avec une IA, ça coûte presque rien et c'est quasiment résolu. Le vrai défi, c'est de vérifier que ces features marchent vraiment, à la vitesse et au volume où tu peux maintenant les produire. Le QA, c'est le plafond actuel de l'autonomie des agents, parce que la vérification ne se parallélise pas comme la génération.

Ça fait à peu près 18 mois qu'on livre du SaaS construit par IA, de Claude Opus 4.1 jusqu'à Claude Fable 5. Sur cette période, le côté build est devenu radicalement plus rapide pendant que le côté vérification, lui, a à peine bougé. Tout est dans cet écart.

---

---

Construire n'est plus la partie difficile

Build This Now est un build system de SaaS propulsé par l'IA : un codebase de production plus 18 agents IA spécialisés qui planifient, construisent, testent et livrent des features en langage courant. Avec un bon moteur d'agents et un vrai codebase de production en dessous, la génération n'est plus la contrainte.

Un MVP qui nous prenait un mois se boucle maintenant en une journée. Auth, paiements, sécurité de la base, e-mails, jobs en arrière-plan : la plupart est déjà branché, et l'IA construit les features sur mesure par-dessus. Le coût pour produire une feature qui marche a chuté d'un facteur dix.

Donc on a fait le truc évident. On a essayé d'en lancer plus en parallèle.

Et c'est là qu'on a heurté le mur.

Le mur : tu ne peux pas vérifier tout ce que tu construis

D'après notre expérience, impossible de dépasser de façon fiable environ quatre features en parallèle avant que ça vire au chaos. Les agents de build, eux, suivaient sans problème. La vérification, non.

Passé environ quatre features en même temps, trois choses partaient de travers :

1. Les exécutions de tests commençaient à se télescoper. État partagé, lignes de base partagées, ports partagés. Le setup de test d'une feature écrasait le teardown d'une autre.
2. L'état dérivait. L'environnement que les tests supposaient ne correspondait plus à celui qui existait, parce qu'un agent voisin l'avait modifié sous leur nez.
3. Les agents de test partaient en boucle. Ils relançaient et revérifiaient les mêmes flows sans converger, brûlant du temps et des tokens, sans savoir si un échec était réel ou juste une collision.

Aucun de ces problèmes n'est un problème de génération. Ce sont des problèmes de vérification. Et ils empirent, au lieu de s'améliorer, à mesure que tu ajoutes du travail en parallèle.

La génération scale. La vérification non.

Voilà l'asymétrie au cœur du sujet. Générer une feature, c'est surtout une tâche indépendante : donne un spec et un codebase à un agent, et il bosse dans son coin. Vérifier une feature, c'est une tâche partagée : le test doit observer un vrai comportement dans un vrai environnement, et cet environnement, c'est justement ce que tous les autres agents touchent aussi.

Tu peux lancer dix agents sur dix features et récupérer dix features. Tu ne peux pas lancer dix agents sur dix suites de tests dans un seul environnement et récupérer dix verdicts propres. Les vérificateurs se disputent le même monde.

Voilà pourquoi le QA est le goulot d'étranglement. Ce n'est pas que tester soit dur dans l'absolu. C'est que tester résiste à la chose exacte qui a rendu la génération bon marché : faire tourner plein de copies d'un coup.

La fiabilité baisse quand le parallélisme monte

Voici l'allure de ce qu'on a observé, présenté comme « features en parallèle » contre « à quel point la vérification reste fiable ». Ce sont nos plages observées, pas des benchmarks.

La ligne de build est restée plate sur toute cette plage. On pouvait générer sept features aussi facilement que deux. On ne pouvait juste pas croire les résultats de tests pour sept.

Pourquoi de meilleurs modèles aident, sans régler le problème

Des modèles plus costauds font vraiment bouger les choses. Plus de contexte, c'est un agent qui garde plus de système en tête et fait moins d'erreurs, donc moins de choses à rattraper en aval. Moins de bugs générés, c'est moins de bugs à vérifier.

Claude Fable 5, le tout dernier modèle d'Anthropic pour le travail complexe de longue haleine (à $10 par million de tokens en entrée et $50 par million en sortie), encaisse une partie du problème autrement. Il tient des chaînes plus longues sans dériver, donc un agent de vérification peut rester cohérent sur une longue boucle de test-et-correction, au lieu de perdre le fil à mi-chemin et de partir en vrille. Ça attaque directement le mode d'échec en boucle qu'on rencontrait sans arrêt.

Mais ça relève le plafond. Ça ne l'enlève pas. L'asymétrie est structurelle. Tant que la vérification doit observer un comportement dans un environnement partagé, ajouter des vérificateurs en parallèle ajoute de la contention. Un meilleur modèle converge plus vite et dérive moins, ce qui t'offre plus de features simultanées avant le mur. Ça ne repousse pas le mur à l'infini.

Le QA à grande échelle reste le défi du moment, et c'est le prochain vrai déblocage. L'équipe qui trouve comment paralléliser la vérification comme on parallélise déjà la génération décroche le prochain bond d'un facteur dix dans l'autonomie des agents. On a écrit, à partir des premiers principes, sur le fait que construire n'est pas le goulot d'étranglement, et tu retrouves la même limite en pratique dans notre façon de faire tourner un essaim d'IA autonome et dans la raison pour laquelle on s'appuie sur des évaluateurs adverses pour garder nos vérificateurs honnêtes.

FAQ

Pourquoi les agents IA n'arrivent-ils pas à tester du code à grande échelle ?

Les agents IA n'arrivent pas à tester du code à grande échelle parce que la vérification dépend d'un environnement partagé, contrairement à la génération. Chaque test doit observer un vrai comportement dans un vrai système, et quand plein d'agents testent en parallèle, ils se disputent la même base, le même état et les mêmes ressources. La génération est isolée et se parallélise bien. La vérification, elle, se télescope. D'après notre expérience, les exécutions de tests commencent à se gêner passé environ quatre features en concurrence.

Combien d'agents IA peut-on lancer en parallèle avant que la qualité s'effondre ?

D'après notre expérience à construire du SaaS IA depuis environ 18 mois, impossible de dépasser de façon fiable quatre features en parallèle avant que la vérification devienne incertaine. Au-delà, les agents de build scalaient très bien, mais les agents de test se mettaient à se télescoper, à dériver et à boucler sans converger. Le chiffre exact dépend de l'isolation de l'environnement, mais l'asymétrie entre génération et vérification reste constante : construire scale, vérifier non.

Quel est le vrai goulot d'étranglement du dev logiciel par IA ?

Le vrai goulot d'étranglement du dev logiciel par IA, c'est l'assurance qualité, pas la génération. Produire une feature qui marche avec un bon moteur d'agents prend désormais une journée au lieu d'un mois. Vérifier ces features à la vitesse où tu peux les générer reste non résolu, parce que la vérification ne se parallélise pas comme la génération. Le QA, c'est le vrai plafond de l'autonomie des agents aujourd'hui.

Est-ce que de meilleurs modèles règlent le goulot d'étranglement du QA ?

De meilleurs modèles aident, mais ne le règlent pas. Plus de contexte et moins d'erreurs, c'est moins de bugs à rattraper, et des modèles comme Claude Fable 5 tiennent des chaînes de vérification plus longues sans dériver, ce qui réduit le mode d'échec en boucle. Mais le goulot est structurel : la vérification observe un environnement partagé, donc ajouter des vérificateurs en parallèle ajoute de la contention. Des modèles plus costauds relèvent le plafond ; ils ne l'enlèvent pas.

La suite

La génération est assez bien résolue pour ne plus être intéressante. Le problème ouvert, c'est une vérification qui scale comme la génération. Celui qui craque le QA parallèle débloque le niveau d'autonomie suivant, et c'est ce travail qu'on surveille, et vers lequel on construit, avec Claude Fable 5 et le moteur autour.