Supabase Evals : un banc d'essai open source pour les agents de programmation

Le 31 juillet, Matt Rossman a annoncé Supabase Evals sur le blog de l'entreprise. Il s'agit d'un dépôt public, disponible sur GitHub sous licence Apache-2.0, conçu pour évaluer la compétence des agents de programmation dans le développement d'applications fondées sur Supabase. L'exécution se fait en local, avec les clés API des fournisseurs de modèles et un démon Docker actif pour les épreuves qui lancent une pile Supabase en conteneur ; contrairement à bien des solutions abstraites, les scénarios se déroulent face à de vraies piles Supabase, sans simulation. La méthode de notation associe des vérifications déterministes — l'accès d'un utilisateur donné à certaines données, par exemple — à une évaluation confiée à un autre modèle de langage jouant le rôle de juge, pour les parties qui exigent un jugement sémantique.

Les épreuves publiées mettent trois agents à l'épreuve — Claude Code, Codex et OpenCode — avec des modèles sous-jacents différents. Les données de la phase 'build' font apparaître des performances élevées pour les modèles de pointe : Opus 5 et Kimi K3 atteignent 100 % de réussite sans fonctions supplémentaires. L'arrivée des 'skills' modifie sensiblement les résultats des autres : Sonnet 5 passe de 78 % à 100 % et GPT-5.6 Sol de 89 % à 100 %, tandis que GPT-5.4 mini monte de 78 % à 89 %. L'entreprise note que ces compétences réduisent l'écart entre les modèles haut de gamme et les plus petits. Ni l'annonce ni la fiche du dépôt ne précisent toutefois le nombre total de scénarios, ce qui rend ces pourcentages difficiles à situer : s'il y avait neuf tâches, un seul résultat différent déplacerait la note de 11 points.

L'initiative s'inscrit dans une tendance plus large : des fournisseurs d'infrastructure développent des benchmarks propres à leurs produits et s'éloignent des classements généralistes comme SWE-bench. L'annonce officielle documente la phase 'build' ; les détails sur un découpage en trois phases (build, deploy, investigate/resolve) et sur la quantité de documentation lue par les agents proviennent de la reconstitution de MarkTechPost et ne sont pas vérifiés directement dans la source primaire. Distinguer les données opérationnelles publiées par l'entreprise des analyses de tiers, c'est précisément ce qui garde transparente la chaîne de traçabilité de l'information.

Au-delà du classement public, généré côté client en JavaScript, la valeur stratégique de l'outil tient à son usage interne comme suite de non-régression. Celui qui conçoit les scénarios connaît les réponses, et les tâches portent sur un produit et une documentation propriétaires : les scores disent à quel point un agent travaille bien avec Supabase, pas ce qu'il vaut en général.

Construire un mètre étalonné sur ses propres briques est une nécessité opérationnelle. Il reste que le mètre, le mur et la note appartiennent à la même maison.

— Olya