Replit lance ViBench 2.0 : le meilleur modèle livre un produit fonctionnel dans 65% des builds

Replit, plateforme où les utilisateurs construisent des produits entiers sans écrire une seule ligne de code, présente ViBench 2.0, un benchmark consacré aux tâches longues de création de logiciels. L'agent part d'un projet vide, reçoit les exigences fonction par fonction dans une seule conversation et doit finalement livrer un produit web fonctionnel. Il n'est pas évalué par des tests unitaires, mais comme le ferait un utilisateur : via un navigateur, et uniquement après la dernière requête. Le résultat est peu flatteur pour les leaders du marché : le meilleur modèle, GPT-6.1 Sol, passe jusqu'à 98% des plans de test, mais ne livre un produit sans défaut que dans 64,7% des builds.

Comment fonctionne le benchmark

ViBench 2.0 réunit 17 produits web complets, calqués sur des services connus : Amazon, Asana, Discord, Figma, GitHub, Google Docs, Jira et Uber. Chacun s'enrichit au fil de 9 à 18 requêtes, soit 241 au total. Par exemple, l'agent construit d'abord une application de VTC, puis reçoit tour à tour les frais d'annulation, les chauffeurs disposant de plusieurs véhicules, les revenus par course et le paiement partagé. Chaque nouvelle fonctionnalité s'appuie sur du code que l'agent a lui-même écrit, et la conversation peut dépasser 200 000 tokens. Aucun retour n'est donné après chaque étape, et les anciennes fonctionnalités doivent survivre à toutes les modifications ultérieures.

Un agent navigateur vérifie le résultat : il pilote un vrai Chromium via Playwright et exécute 544 plans de test. 85% des plans vérifient plusieurs fonctionnalités à la fois, par exemple que le revenu du chauffeur tient compte des frais et ne casse pas à cause du paiement partagé. Un build n'est validé (pass@1) que si tous les plans passent. La métrique est volontairement sévère : pour un utilisateur qui ne lit pas le code, « presque fonctionnel » veut dire « ne fonctionne pas ».

Les conditions sont identiques pour tous les modèles : un agent basé sur OpenHands SDK, avec terminal et éditeur de fichiers, un niveau de raisonnement moyen, jusqu'à 300 étapes et deux heures par étape. Six modèles fermés ont été testés — GPT-6.1 Sol, GPT-6 Astra, Opus 5.5, Sonnet 5.5, Grok 4.7 et Gemini 3.8 Flash — ainsi que trois modèles ouverts : DeepSeek V4.1 Flash, Kimi K3 et GLM 5.3. Chacun a construit chaque produit quatre fois, soit 612 builds au total.

L'écart entre « presque » et « terminé »

Le trio de tête se présente ainsi : Sol, 64,7% en pass@1 ; Astra, 60,3% ; Opus 5.5, 48,5%. Leur taux de plans réussis se situe entre 93,7% et 98,0%. Sur 84 builds ratés parvenus jusqu'à la vérification, 42 ont échoué sur exactement un plan, et 62 sur deux plans au plus. Astra a produit au moins un produit entièrement fonctionnel pour 16 des 17 tâches, Sol pour 15, Opus pour 13. Le seul produit qui n'a jamais abouti sur les 36 tentatives des leaders est le clone de Figma : l'édition collaborative et l'annulation d'actions plantaient.

Les modèles ouverts sont encore loin de ce niveau : aucun de leurs 204 builds n'a passé tous les plans. Ils se distinguent toutefois par leur taux de plans réussis : DeepSeek V4.1 Flash atteint 77,4%, à moins de deux points de Sonnet 5.5, pour environ 60% de son coût.

Les écarts de prix et de vitesse sont importants. Un build coûte de $2,5 à $89,9 et dure de 26 minutes à plus de quatre heures. Astra revient environ sept fois plus cher que Sol pour un écart de pass@1 inférieur à cinq points. Opus construit 2,4 fois plus vite que Sol (73 minutes), avec seulement 6% de tokens de sortie en moins ; les auteurs l'attribuent à la vitesse d'inférence.

La progression est rapide. Sur trois versions d'une même famille de modèles, le pass@1 sur les produits publics est passé de 3% à 53%, et le coût d'un build a plus que divisé par deux. Le pass@1 ne progresse toutefois nettement que lorsque le taux de plans réussis dépasse environ 70%.

Dans quelle mesure peut-on se fier à l'évaluateur

Le maillon le plus fragile d'un tel système est l'évaluateur basé sur l'IA. Les auteurs l'ont vérifié séparément. Sur une évaluation unique, il fait échouer à tort un plan fonctionnel dans 0,2% des cas ; les plans échoués sont donc réévalués jusqu'à cinq fois, jusqu'à ce que trois évaluations concordent.

Les faux « réussis » sont plus rares : GPT-6.1 Sol a réexaminé 477 plans validés par Opus, et après analyse manuelle, seuls 4 (0,8%) se sont révélés faux. Sur 34 bugs introduits volontairement, dont 24 subtils (par exemple, un montant qui diffère d'un centime), l'évaluateur les a tous trouvés.

L'audit de 178 plans échoués a révélé 13 verdicts erronés et deux endroits où la spécification était incomplète. Tout cela a été corrigé avant la sortie, et les 159 autres échecs sont de vrais bugs.

Indépendamment de Replit, l'équipe de Fireworks a fait tourner le benchmark : elle l'a lancé en une seule commande pour chaque modèle, sans modification. Tous les chiffres de l'article proviennent de ces exécutions.

Limites et enseignement pratique

Huit produits sont accessibles publiquement, avec le lancement et l'évaluateur ; neuf autres sont tenus cachés pour éviter que les modèles s'entraînent sur ces tâches, et les résultats indépendants sont calculés sur les 17. Dans les expériences, l'évaluateur et l'agent de « seeding » sont tous deux Opus 5.5, ce qui peut théoriquement influer sur les notes, même si un second évaluateur ne l'a, dans l'ensemble, pas confirmé. Par ailleurs, le benchmark a été conçu en fonction des choix de Replit sur les modèles à intégrer ; il reflète donc ses propres scénarios : des produits web construits de zéro, et non le travail sur la base de code de quelqu'un d'autre.

Pour les équipes qui choisissent un modèle pour le développement agentique, l'enseignement est pratique : il vaut mieux comparer non pas la part de tests réussis, mais la probabilité d'obtenir un résultat entièrement fonctionnel. C'est là que les meilleurs modèles ont encore la plus grande marge de progression, et les modèles ouverts, le retard le plus important.