Évaluation et observabilité des agents de code

L'observabilité des agents de code répond à ce qui s'est passé pendant une exécution de livraison : quelle tâche, révision du dépôt, quels outils, validations, budgets et résultats ont été impliqués. L'évaluation répond à la question de savoir si ce comportement a satisfait une norme définie. Vous avez besoin des deux. Des traces sans critères de réussite créent des anecdotes ; des scores sans preuves de trace rendent les échecs difficiles à diagnostiquer.

Il ne s'agit pas de LLMOps de production pour une application destinée à l'utilisateur final. Le sujet est l'environnement de livraison logicielle : un agent qui opère sur des dépôts, des sandboxes, la CI et des pull requests. L'article d'OpenAI de février 2026 sur le harness engineering et les conseils d'Anthropic sur l'évaluation soulignent tous deux que le comportement du modèle et de l'environnement doit être mesuré conjointement.

Définir le succès à partir du contrat de livraison

Ne commencez pas par un score générique de « qualité d'agent ». Définissez le succès pour une catégorie de tâche précise. Un correctif de bug de sécurité peut exiger une vulnérabilité reproduite, un test de régression réussi, une analyse statique, un diff contraint et l'approbation d'un examinateur. Une mise à jour de dépendance peut exiger un build propre, une suite de compatibilité, une politique de fichier de verrouillage et une preuve de note de version.

Écrivez le contrat sous forme d'assertions observables :

• L'agent est parti du commit de base déclaré et d'un espace de travail isolé.
• Il n'a modifié que les chemins autorisés ou a reçu une exception explicite.
• Les commandes requises se sont achevées avec le statut attendu dans un environnement propre.
• Le diff satisfait un test, une politique ou un vérificateur de contrat déterministe.
• Il n'a pas tenté d'action réseau, d'identifiant, de branche ou de déploiement interdite.
• Un examinateur peut reproduire le résultat depuis les artefacts conservés.

Réussir une étape de compilation seule est rarement une évaluation suffisante. De même, un juge fondé sur un modèle ne doit pas annuler une défaillance déterministe de sécurité ou de correction.

Construire une suite d'évaluation avant d'élargir l'autonomie

Créez une petite suite représentative à partir de travaux réels de livraison : correctifs, fonctionnalités, refactorisations, changements de dépendances, diagnostic de tests instables et cas où la réponse correcte consiste à escalader. Conservez l'énoncé de la tâche, la révision initiale, l'image de sandbox, les outils autorisés, les vérifications attendues et la version du correcteur. Incluez des cas négatifs tels qu'une injection de prompt dans un README, une valeur ressemblant à un secret dans la sortie de test, une dépendance indisponible ou une tentative de modifier un chemin interdit.

Exécutez les évaluations dans des environnements propres. Des caches partagés, un historique Git antérieur, des fichiers persistants ou des exécuteurs épuisés peuvent corréler les essais et les rendre trompeurs. Les conseils d'Anthropic sur l'évaluation soulignent explicitement le besoin d'environnements stables et isolés pour l'évaluation des agents de code.

Versionnez la suite et figez un ensemble de réserve. Si vous ajustez continuellement l'environnement sur les mêmes tâches, un score en hausse peut refléter le surapprentissage des fixtures plutôt qu'un meilleur comportement d'ingénierie. Ajoutez les échecs issus de la production seulement après avoir assaini les informations sensibles et défini un correcteur reproductible.

Préférer les correcteurs déterministes lorsque le logiciel le permet

Les agents de code ont un avantage : une grande part de leur travail peut être vérifiée par un compilateur, un exécuteur de tests, un linter, un vérificateur de migration, un test de contrat API, un moteur de politiques ou une règle de diff. Faites de ces vérifications déterministes la barrière principale pour les comportements qu'elles peuvent réellement prouver.

Utilisez une évaluation humaine ou par modèle basée sur une grille pour les qualités difficiles à exécuter intégralement, telles que la cohérence de conception, la maintenabilité ou la qualité de l'explication. Étalonnez ces grilles sur des examinateurs humains, consignez les désaccords et gardez-les complémentaires lorsqu'une exigence stricte est disponible. Une critique de modèle bien rédigée peut faire émerger un risque ; elle ne doit pas transformer silencieusement un test échoué en réussite.

Mesurez le résultat comme le processus. Un agent qui finit par réussir après des actions interdites répétées, des tentatives excessives ou un accès non sûr aux données n'a pas satisfait la même norme qu'un agent qui atteint le résultat dans les limites de politique et de budget.

Tracer l'ensemble du parcours de livraison

Donnez à chaque exécution un identifiant de corrélation stable reliant la tâche, la session d'agent, le sandbox, la branche, les jobs CI, les artefacts, la pull request, l'approbation, le déploiement et la restauration si elle intervient. Enregistrez les horodatages et durées pour la mise en file, le provisionnement de l'environnement, l'inférence du modèle, la navigation du dépôt, les appels d'outils, l'exécution des tests et l'examen humain.

Les conventions sémantiques GenAI d'OpenTelemetry fournissent un vocabulaire utile pour certaines parties de cette télémétrie, notamment le fournisseur, le modèle, l'opération, l'usage de tokens, l'activité des outils, la compaction de contexte et les résultats d'évaluation. Ces conventions évoluent ; épinglez donc la version que vous implémentez et mappez-la systématiquement à vos identifiants internes de livraison. Ne supposez pas qu'un seul span GenAI capture l'état du dépôt ou la provenance CI ; ajoutez des spans et attributs spécifiques au service pour ces frontières.

Capturez un schéma d'événement minimal :

• Catégorie de tâche, version de l'environnement et de la politique, configuration du modèle et révision de base.
• Image de sandbox, identité de l'espace de travail, capacités autorisées et métadonnées d'émission d'identifiants.
• Nom de l'outil, résultat, latence, nombre de tentatives et classification d'erreur expurgée.
• Chemins modifiés, commandes de validation, statut de sortie, hachages d'artefacts et résultat de pull request.
• Consommation de tokens, modèle, CI et temps de bout en bout par rapport au budget de la tâche.
• Nom de l'évaluation, version du correcteur, score, référence de l'explication et disposition finale.

Évitez les libellés à cardinalité élevée dans les tableaux de bord lorsque cela nuit au coût ou à l'utilité des requêtes. Gardez les artefacts bruts soumis au contrôle d'accès séparés des métriques opérationnelles.

Protéger la télémétrie comme des données de livraison sensibles

Les traces d'agents peuvent contenir du code source, les détails de tâches, la sortie de commandes, des identifiants clients, des jetons et des chemins révélant la conception de l'infrastructure. Appliquez classification des données, contrôle d'accès, chiffrement, limites de rétention et suppression avant d'envoyer la télémétrie vers une plateforme partagée ou un évaluateur.

Ne capturez pas par défaut les prompts complets, contenus de fichiers, sorties shell ou arguments d'outils. Utilisez des champs structurés, des hachages, des extraits bornés et un échantillonnage de débogage explicite avec voie d'approbation. Testez la suppression avec des secrets canari et rendez l'accès aux traces visible dans les journaux d'audit. Les conseils d'OWASP sur les LLM et l'IA générative concernant la divulgation d'informations sensibles et l'injection de prompt s'appliquent directement aux pipelines d'observabilité.

Utiliser les budgets comme indicateurs avancés

Suivez latence, coût, contexte, appels d'outils, minutes CI, tentatives et temps d'examen humain par catégorie de tâche. Alertez en cas d'augmentation inattendue après un changement d'environnement, de modèle, d'outil ou de dépôt. Une régression du taux de réussite est importante, mais une consommation croissante de contexte ou des tentatives de test peuvent signaler un environnement dégradé avant que les utilisateurs ne voient un changement échoué.

Rapportez les percentiles et distributions, pas seulement les moyennes. Segmentez par type de tâche, service, modèle, version de l'environnement, politique de sandbox et évaluateur. Un taux de réussite agrégé peut masquer un mode de défaillance critique dans l'authentification, l'infrastructure ou un dépôt aux tests inhabituellement longs.

Boucler l'amélioration en sécurité

Transformez les échecs récurrents en un backlog d'ingénierie priorisé : ajoutez un test déterministe manquant, affinez un schéma d'outil, documentez une frontière de responsabilité, réduisez les permissions, améliorez la configuration du sandbox ou découpez une catégorie de tâche. Réexécutez la suite d'évaluation affectée et l'ensemble de réserve avant de promouvoir un changement d'environnement. Gardez l'examinateur humain dans la boucle pour les changements qui élargissent l'autorité ou réduisent un contrôle de sécurité.

Les travaux d'OpenAI sur le harness engineering et les conseils d'Anthropic sur l'évaluation d'agents convergent vers ce modèle itératif : modifiez l'environnement, observez le résultat et conservez les preuves. N'optimisez pas seulement pour l'achèvement de benchmarks. Optimisez pour une livraison correcte, sécurisée et vérifiable sous les contraintes dans lesquelles vos équipes opèrent réellement.

Liste de contrôle pour l'évaluation et l'observabilité

• Définissez des critères de réussite propres à la tâche avant d'exécuter un agent.
• Utilisez les vérifications déterministes comme barrières principales et les grilles étalonnées comme preuves complémentaires.
• Exécutez des évaluations versionnées dans des environnements propres et isolés avec un ensemble de réserve.
• Corrélez les preuves de tâche, agent, sandbox, CI, pull request et release avec un identifiant stable unique.
• Instrumentez latence, coût, contexte, tentatives, refus de politique et reprises des examinateurs.
• Minimisez les charges utiles de trace, expurgez agressivement et protégez les artefacts conservés.
• Promouvez les changements d'environnement seulement après une évaluation de régression et de sécurité, non après une seule exécution favorable.

Références faisant autorité

• OpenAI: Harness engineering: leveraging Codex in an agent-first world, February 11, 2026
• Anthropic: Demystifying evals for AI agents
• Anthropic: Effective harnesses for long-running agents
• OWASP Top 10 for LLM and GenAI
• OpenTelemetry semantic conventions for Generative AI