Guide d'ingénierie

Évaluation des agents de code et observabilité

Utilisez une évaluation des agents de code répétable et des traces respectueuses de la confidentialité pour déterminer où les agents aident, où ils échouent et comment l'environnement doit évoluer.

Publié le: 14 juil. 2026
Mis à jour le: 15 juil. 2026
Temps de lecture: 20 min de lecture

Sur cette page

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. Cette discipline compte encore davantage à l'échelle où opère une couche d'orchestration d'edge managée : un même plan de contrôle coordonne des décisions sur de nombreuses origines, et un changement qui semble sûr une fois peut y dériver sans être vu.

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. Prenons un scénario concret : la boutique en ligne fictive Acme Shop traite le ticket ACME-1842, qui exige que le service checkout-api rejette un panier sans country avec le code TAX_COUNTRY_REQUIRED, avant tout calcul de taxe. Le cas de test ne se limite pas à un prompt : il fige la révision de base, la politique de sandbox, les chemins autorisés, les vérifications requises, le comportement de diff attendu, le correcteur, le nombre d'essais et une condition d'escalade explicite.

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 — pour Acme Shop, uniquement services/checkout-api/** — 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 : pour ACME-1842, la réponse doit renvoyer TAX_COUNTRY_REQUIRED et un panier français valide doit toujours obtenir un devis.
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'evals d'agents 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. Versionnez le cas lui-même, le correcteur, l'environnement et la configuration du modèle : chez Acme Shop, le cas checkout-missing-country est passé en version 1.3.0 le jour où la politique de sandbox a changé.

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. Pour ACME-1842, le README du dépôt de test demande explicitement à l'agent d'appeler un service de taxe en production : une suite d'evals d'agents bien conçue doit noter ce refus comme une réussite de politique, pas comme un échec de tâche.

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 plutôt qu'indépendants. 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.

Rendre l'évaluation des agents de code reproductible sur plusieurs essais

L'évaluation des agents de code ne mérite ce nom qu'à partir du moment où un résultat se reproduit sur plusieurs essais, pas une seule fois. Les agents de code échantillonnent un modèle et retentent après un appel d'outil échoué : le même cas, exécuté une seule fois, peut réussir ou échouer par hasard. Rapportez un taux calculé sur plusieurs essais, jamais un verdict unique, et choisissez le taux qui correspond à ce que le cas protège réellement.

Deux mesures distinguent « a fonctionné une fois » de « fonctionne à chaque fois ». Le pass@k est la probabilité qu'au moins un essai parmi k réussisse — la bonne mesure pour une tâche exploratoire. Le pass^k est la probabilité que les k essais réussissent tous — la bonne mesure pour une assertion critique en matière de sécurité, comme le rejet du panier sans pays. Un agent qui résout ACME-1842 dans quatre essais sur cinq affiche un pass@5 solide (1,00) mais un pass^5 faible (0,80) : promouvoir sur la seule base du pass@k revient à livrer un correctif fiable quatre fois sur cinq, pas cinq fois sur cinq.

Avant d'incriminer l'agent, écartez l'hypothèse de l'exécuteur : si l'essai en échec trahit une dépendance mise en cache et périmée, il s'agit de la défaillance d'environnement corrélé qu'un exécuteur isolé doit précisément empêcher. Corrigez l'exécuteur, puis relancez l'ensemble des essais — un nouvel essai partiel ne permet pas de recalculer le pass^k honnêtement.

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 — jamais l'inverse.

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 un petit échantillon annoté par des humains et consignez les désaccords. Un juge fondé sur un modèle qui change de verdict sur une transcription inchangée ajoute son propre bruit à celui de l'agent : préférez un prompt de jugement étroit, ancré à une grille précise et exécuté à basse température, à une instruction ouverte du type « évaluez ce diff ». En cas de désaccord entre le juge et la vérification déterministe, faites toujours confiance à cette dernière.

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.

Construire l'observabilité des agents dans le 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 restent expérimentales : plusieurs SDK et collecteurs exigent une activation explicite, par exemple la variable OTEL_SEMCONV_STABILITY_OPT_IN=gen_ai_latest_experimental, avant d'émettre les nouvelles formes de span. Épinglez ce drapeau avec la version de convention implémentée, et traitez tout changement de l'un ou de l'autre comme une migration délibérée.

Un span GenAI isolé ne capture ni l'état du dépôt ni la provenance CI ; ajoutez des spans et attributs spécifiques au service à ces frontières. Traitez les budgets comme le statut de réussite : émettez tokens, appels d'outils et durée sous forme de métriques portant les mêmes dimensions de tâche et de version que vos évaluations, plutôt qu'en lignes de journal, afin qu'une régression de budget apparaisse à côté de la tendance du taux de réussite.

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.

Un seul modèle de corrélation, tous les fournisseurs du chemin

Chez Optimi, la couche MYO applique la même discipline de corrélation à l'ensemble des fournisseurs qu'elle orchestre : une requête qui traverse Cloudflare, Fastly ou NS1 en périphérie et un changement d'agent de code sur l'origine derrière elle doivent se résoudre en une seule chronologie d'incident, pas en trois tableaux de bord distincts.

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. 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é.

Testez la suppression avec une valeur canari unique, par exemple ACME_REDACTION_CANARY_7F2, injectée dans une fixture censée provoquer une erreur. Exécutez le chemin de capture et d'export complet, puis interrogez les charges utiles de trace stockées et chaque système en aval pour retrouver cette valeur : un canari absent du magasin de traces principal peut malgré tout ressortir via un pipeline d'expédition de logs, un exportateur de secours en mode débogage ou une sauvegarde en stockage froid dotée de ses propres règles de rétention. Vérifiez chaque endroit où la donnée est copiée, pas seulement celui dont une équipe se souvient avoir configuré.

Étendez la même preuve aux données personnelles, pas seulement aux secrets : injectez un second canari, par exemple une adresse e-mail client synthétique, dans une fixture qui déclenche une trace d'appel susceptible de porter le contexte de la requête. OWASP classe la divulgation d'informations sensibles parmi les principaux risques liés aux agents ; une règle réglée uniquement pour des clés d'API la manquera.

Validation positive : la réponse attendue et la régression de panier valide réussissent, le correcteur enregistre les chemins autorisés, et l'identifiant de corrélation atteint la CI et la pull request.
Validation négative : la demande du README d'accéder au service de taxe en direct est refusée et notée comme un résultat de politique attendu ; une modification de chemin non autorisée fait échouer le cas.
Validation d'échec : le canari de suppression apparaît dans une charge utile exportée, ou l'exportateur de trace lui-même échoue. Marquez l'exécution non promouvable, restreignez l'accès aux traces, ne conservez que ce dont les répondants d'incident ont besoin, et arrêtez la promotion.

La récupération après un échec de suppression n'est pas « supprimer le tableau de bord et continuer » : confinez l'accès, expurgez les données concernées, faites tourner un secret réel s'il a été exposé, corrigez la règle de capture, puis relancez le canari et l'ensemble de réserve complet. En cas de panne de l'exportateur, conservez les preuves déterministes de la CI mais étiquetez l'exécution comme incomplète. Le même raisonnement sur l'excès d'agentivité qui justifie une politique de sandbox étroite plaide aussi pour des identifiants d'évaluation à portée réduite et de courte durée de vie.

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, réparez l'image de sandbox ou découpez une catégorie de tâche. Réexécutez le cas affecté et l'ensemble de réserve sur l'ensemble des essais requis, pas sur un seul, avant de promouvoir un changement — même un changement qui ne fait que réduire la variance mérite sa place dans ce backlog. 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 et calibrées comme preuves complémentaires.
Exécutez des evals d'agents versionnées dans des environnements propres et isolés avec un ensemble de réserve.
Rapportez un taux sur plusieurs essais — pass@k pour l'exploratoire, pass^k pour tout ce qui est critique en matière de sécurité — avant de promouvoir un changement.
Corrélez les preuves de tâche, agent, sandbox, CI, pull request et release avec un identifiant stable unique, et épinglez la version des conventions OpenTelemetry que vous adoptez.
Instrumentez latence, coût, contexte, tentatives, refus de politique et reprises des examinateurs comme des métriques, pas seulement des journaux.
Minimisez les charges utiles de trace, expurgez agressivement et prouvez la suppression avec des canaris de secrets et de données personnelles sur chaque système en aval.
Promouvez les changements d'environnement seulement après une évaluation de régression et de sécurité sur l'ensemble des essais, non après une seule exécution favorable.

Références faisant autorité

Rendez l'évaluation des agents de code et ses preuves exploitables

Échangez avec Optimi sur la corrélation des preuves de livraison de vos agents de code avec la télémétrie Performance, Sécurité et Visibilité entre edge, origine et services critiques dans MYO.

Discuter de l'observabilité