Les démonstrations impressionnantes et les benchmarks publics donnent une indication, mais ils ne reproduisent ni votre architecture ni vos règles de livraison. Pour choisir un agent de code, il faut mesurer sa capacité à accomplir des tâches représentatives dans un environnement contrôlé.
Commencer par les décisions à prendre
Un benchmark utile répond à une question concrète : quel outil aide le mieux à corriger des bugs ? lequel prépare les migrations les plus sûres ? lequel réduit le temps de revue ? Sans décision cible, le score global mélange des usages incompatibles.
Composer un jeu de tâches
Sélectionnez 12 à 20 tâches réparties en quatre familles :
- compréhension : expliquer un flux et identifier ses dépendances ;
- modification : ajouter une fonctionnalité bornée ;
- correction : reproduire puis réparer un défaut ;
- maintenance : migration, documentation ou amélioration de tests.
Chaque tâche doit disposer d'un état initial figé, d'une consigne identique, de critères d'acceptation et d'une solution de référence non transmise à l'agent.
Isoler l'environnement
Utilisez un commit et une image de développement identiques. Fixez les dépendances, les variables non secrètes, la durée maximale, l'accès réseau et les outils disponibles. Répétez chaque scénario plusieurs fois : un agent n'est pas déterministe.
Mesurer autre chose que « ça compile »
Le score peut combiner :
- réussite des tests existants ;
- tests cachés ou cas limites ;
- vulnérabilités et secrets introduits ;
- compatibilité de l'API ;
- taille et cohérence du diff ;
- temps total et interventions humaines ;
- consommation facturable ;
- qualité de l'explication finale.
Définissez les poids avant l'exécution. Une tâche de sécurité ne doit pas être gagnée par une solution rapide mais vulnérable.
Ajouter des évaluateurs complémentaires
Anthropic recommande de combiner plusieurs types d'évaluation pour les agents. Utilisez des tests déterministes pour le comportement, des analyseurs statiques pour la sécurité et une grille humaine pour la maintenabilité. Un second modèle peut aider à trier, mais ne doit pas être l'unique juge.
Exemple de fiche de résultat
Tâche: corriger l'expiration d'un cache concurrent
Tests publics: 8/8
Tests cachés: 4/5
Régression API: non
Interventions humaines: 1
Durée: 14 min
Diff utile: 63 lignes
Risque principal: verrou non libéré sur exception
Éviter les biais courants
Ne donnez pas davantage d'indices à l'outil que vous connaissez le mieux. Ne changez pas de modèle au milieu de la campagne. Ne comptez pas seulement le premier résultat : mesurez aussi la capacité de correction après retour de revue.
Publiez le protocole, les versions, les prompts, les commits et les limites. C'est cette transparence méthodologique qui rend notre Observatoire des assistants IA réutilisable.
Décider avec une matrice, pas un podium
Un outil peut être excellent en exploration et médiocre en modifications autonomes. Présentez donc les résultats par famille de tâches, niveau de risque et coût. Le meilleur choix peut être une combinaison : agent local pour les dépôts sensibles, agent cloud pour les migrations et outil spécialisé pour la revue.
quel scenario de depot reel devrait absolument figurer dans un benchmark reproductible d'agents IA ?
Publié dans la discussion