Comment je mesure si un agent IA fonctionne vraiment

Table des matières

Mis à jour mai 2026.

TL;DR: La plupart des opérateurs sautent les évaluations et supposent simplement que leurs agents fonctionnent. Mon framework : construire un golden set de 5 à 10 entrées connues avec les sorties attendues, définir des critères réussi/échoué en langage clair, et vérifier les logs chaque semaine. Ne pas construire un système d’évaluation élaboré avant d’avoir 10 vraies exécutions — c’est le piège qui tue l’élan.

[Point de vue opérateur] Je gère plus de 30 agents IA en production pour ma marque de conseil et Pickleland, une installation de pickleball à Pflugerville, TX. À un moment donné, j’ai réalisé que je passais plus de temps à m’inquiéter de la dérive des agents qu’à les utiliser vraiment. Voici le framework d’évaluation sur lequel je me suis arrêté — pas de doctorat requis, pas de plateforme d’évaluation personnalisée, pas de Python.

Le problème dont personne ne parle : les agents dérivent silencieusement

Quand un employé humain commence à mal faire son travail, on s’en aperçoit généralement. Quand un agent IA commence à produire des résultats médiocres, il continue à en produire — silencieusement, à grande échelle, jusqu’à ce que quelque chose tombe suffisamment en panne pour qu’un humain finisse par regarder.

J’ai eu un agent de contenu qui a commencé à ajouter des avertissements “En tant que modèle de langage IA” après une mise à jour du modèle. J’ai eu un agent promoteur d’événements qui a arrêté d’inclure des liens de billets parce qu’un nom de variable de prompt avait changé. Aucun n’a échoué bruyamment. Les deux se sont simplement dégradés.

La solution n’est pas de construire un système de surveillance digne de la NASA. C’est d’avoir une vérification simple et répétable qui détecte la dérive avant qu’elle ne s’accumule.

Ce qu’est vraiment une évaluation (pour les opérateurs)

Les ingénieurs utilisent le mot “eval” pour désigner l’exécution d’un benchmark sur un modèle. Pour les opérateurs, je veux dire quelque chose de plus simple : un test répétable qui vous dit si votre agent fait toujours ce pour quoi vous l’avez construit.

Trois composantes :

1. Golden set — 5 à 10 vraies entrées que vous avez déjà vues, avec les sorties attendues dont vous savez qu’elles sont bonnes
2. Critères réussi/échoué — des règles en langage clair définissant ce qui compte comme réussi
3. Une vérification planifiée — vous ou votre assistant exécute réellement le test selon un rythme

C’est tout. Vous n’avez pas besoin d’un framework. Vous avez besoin de discipline.

Construire votre golden set

Puisez dans vos logs de production. Trouvez 5 à 10 vraies entrées pour lesquelles vous savez déjà à quoi ressemble une bonne sortie. Ce sont vos vérités terrain.

Pour mon agent de pipeline de contenu, le golden set contient 5 articles publiés qui ont passé ma liste de contrôle de voix quand je les ai écrits manuellement. Pour mon promoteur d’événements Pickleland, ce sont 5 anciens posts Facebook qui ont eu un engagement supérieur à la moyenne (commentaires + partages, pas seulement des likes).

Règles pour un bon golden set :

• Des entrées réelles, pas des hypothèses que vous avez inventées
• Inclure au moins un cas limite (une entrée délicate, courte, ou avec une mise en forme inhabituelle)
• Garder les sorties attendues documentées — une capture d’écran, un fichier texte, une ligne dans une feuille de calcul
• Ne jamais supprimer du golden set ; seulement ajouter

Quand l’agent fonctionnait bien pour la dernière fois confirmée, notez exactement ce que “bon” signifiait. Cela devient votre sortie attendue.

Définir les critères réussi/échoué

Les critères vagues sont inutiles. “La sortie devrait être bonne” passera toujours parce que vous le rationaliserez.

Rédigez vos critères comme des éléments de liste de contrôle qu’un non-expert pourrait évaluer. Voici les critères réels que j’utilise pour mon agent de pipeline de contenu :

Liste de contrôle réussi/échoué de l’agent de contenu :

• L’article a un TL;DR dans les 100 premiers mots
• Pas de phrases comme “dans le monde trépidant d’aujourd’hui” ou “En tant qu’IA”
• Au moins un nombre concret ou une statistique
• Le nombre de mots est compris entre 800 et 2000
• Tous les liens internes se résolvent (pas de 404)

Pour le promoteur d’événements Pickleland :

Liste de contrôle réussi/échoué du promoteur d’événements :

• Le nom de l’événement correspond au calendrier source
• La date et l’heure sont correctes
• Le lien de billets est présent et fonctionnel
• Le texte fait moins de 280 mots
• Le post n’utilise pas de phrases génériques de remplissage

Si 4 des 5 éléments de la liste passent, l’exécution est réussie. Si 3 ou moins passent, c’est un échec et j’enquête avant la prochaine exécution.

Utiliser Claude comme juge

Pour les agents dont les sorties sont longues ou complexes, j’utilise Claude Sonnet comme juge automatisé. C’est plus rapide que la révision manuelle et détecte des choses que je survolerais.

Voici le prompt de juge que j’utilise pour l’agent de contenu :

You are evaluating a blog post written by an AI agent. Your job is to check whether it meets the operator's standards.

Evaluate the following post against these criteria:
1. Starts with a direct answer or TL;DR in the first 100 words (YES/NO)
2. Contains at least one concrete number or specific example (YES/NO)
3. Free of AI-speak filler ("As an AI", "in today's fast-paced world", "delve", "it's worth noting") (YES/NO)
4. Word count is between 800 and 2000 words (YES/NO)
5. Tone matches the reference: direct, first-person, opinionated, no fluff (YES/NO)

For each criterion, respond YES or NO with one sentence of explanation.
At the end, output PASS if 4 or 5 criteria are YES, FAIL otherwise.

Post to evaluate:
---
{{post_content}}
---

Je l’exécute comme un Cloudflare Worker qui récupère le dernier brouillon, lance ce prompt et écrit le résultat dans une Google Sheet. Le tout prend 8 secondes et coûte environ 0,003 $ par exécution.

Pour le promoteur d’événements, le prompt du juge est plus simple :

You are checking an AI-generated Facebook event post for accuracy and quality.

Source data:
- Event name: {{event_name}}
- Date: {{event_date}}
- Time: {{event_time}}
- Ticket URL: {{ticket_url}}

Generated post:
---
{{generated_post}}
---

Check:
1. Does the post correctly state the event name? (YES/NO)
2. Does the post correctly state the date and time? (YES/NO)
3. Does the post include the exact ticket URL? (YES/NO)
4. Is the post under 280 words? (YES/NO)
5. Is the tone inviting without using generic filler phrases? (YES/NO)

Output PASS if all 5 are YES, FAIL if any are NO. List which items failed.

Où regarder : les logs de Cloudflare Worker

Si vous exécutez des agents sur Cloudflare Workers (ce que je fais pour la plupart de mes agents légers), le log tail intégré est votre meilleur ami. Vous n’avez pas besoin d’un service de journalisation tiers pour commencer.

Ce que je vérifie lors des révisions hebdomadaires ponctuelles :

• Erreurs et exceptions — tout ce qui a planté ou expiré
• Comptages de tokens — si une exécution utilise soudainement 3 fois les tokens habituels, quelque chose a changé
• Pics de latence — un ralentissement soudain signifie généralement que le prompt est devenu plus long ou que le modèle a du mal
• Dérive de la longueur de sortie — si la sortie moyenne est passée de 600 à 200 mots, l’agent a changé de comportement

Je passe 15 minutes chaque lundi matin là-dessus. J’ai une simple liste de contrôle dans Notion : ouvrir les logs de chaque agent, noter tout ce qui est anormal, comparer l’utilisation des tokens avec la ligne de base de la semaine dernière. C’est tout le processus.

L’évaluation par tableur : peu élégante mais efficace

Avant d’avoir toute automatisation, j’exécutais les évaluations dans une Google Sheet. J’utilise encore ça pour les nouveaux agents dans les 4 premières semaines.

Structure :

Cinq lignes par semaine. Prend 10 minutes. Si vous avez deux échecs consécutifs, vous arrêtez l’agent et corrigez le prompt avant de continuer.

C’est désespérément low-tech. C’est aussi ainsi que j’ai détecté trois régressions de prompt avant qu’elles n’arrivent en production.

Ce qu’il ne faut PAS faire

Ne pas construire le système d’évaluation avant d’avoir 10 vraies exécutions. J’ai vu des fondateurs passer deux semaines à construire un pipeline d’évaluation sophistiqué pour un agent qu’ils n’avaient exécuté que deux fois. Vous n’en savez pas assez sur ce que “bon” signifie tant que vous n’avez pas de vraies données de production.

Ne pas évaluer avec des entrées synthétiques que vous avez inventées. Les cas de test synthétiques manquent les cas limites étranges que la production vous lance. Toujours commencer avec de vrais logs.

Ne pas tout évaluer. Choisissez les 3 à 5 agents où l’échec ferait vraiment mal — sorties orientées client, tout ce qui poste publiquement, tout ce qui déclenche un paiement. Passez les agents utilitaires internes jusqu’à ce que vous ayez de la bande passante.

Ne pas automatiser trop tôt. Une feuille de calcul que vous utilisez réellement bat un dashboard Datadog que vous oubliez de vérifier. Commencez manuellement, automatisez après avoir exécuté la vérification 10 fois et savoir ce que vous cherchez vraiment.

La conclusion de l’opérateur

Les évaluations n’ont pas besoin d’être de niveau ingénierie pour être utiles. Un golden set de 5 à 10 vraies entrées, une liste de critères réussi/échoué, et 15 minutes de vérification des logs chaque lundi détecteront 80% de la dérive des agents avant qu’elle ne s’accumule. Commencez par là. Si vous exécutez encore des agents sans aucune évaluation, vous volez à l’aveugle — et éventuellement quelque chose échouera assez publiquement pour que vous regrettiez de ne pas avoir passé les 20 minutes.