Un agent qui « a l’air de marcher » est un agent que personne n’a mesuré. Les LLM sont non déterministes et échouent en silence : la démo brille, puis la deuxième semaine produit une réponse absurde que personne n’avait vue venir. L’évaluation et l’observabilité, c’est remplacer « ça a l’air bon » par des chiffres.

L’analogie

Le tableau de bord et le crash-test. L’observabilité, c’est le tableau de bord : vitesse, carburant, voyants — on voit ce que fait le système pendant qu’il roule. Les évals, ce sont les crash-tests : avant de livrer un changement, on l’envoie dans le même mur que la dernière fois et on vérifie qu’il survit. Aucun constructeur ne livre sur « le pilote d’essai avait un bon feeling ».

Le principe

flowchart LR
    P["changement de prompt ou de code"] --> E["lance le jeu d'évaluation"]
    E --> S{"scores vs référence"}
    S -->|meilleur ou égal| SHIP([livre])
    S -->|régression| P
    PROD["traces de production"] -->|"les échecs deviennent des cas de test"| E

Deux habitudes, une seule boucle :

• Tout observer. Journalisez chaque étape de chaque exécution : le prompt exact, les appels d’outils et leurs résultats, les tokens dépensés, la sortie finale. Quand ça casse, la trace dit quelle étape a dérivé — sans elle, vous déboguez une boîte noire.
• Évaluer sur un jeu fixe. Quelques dizaines de cas réels avec les résultats attendus. Notez-les de la même façon après chaque changement. Là où le contrôle ne peut pas être programmatique (« ce résumé est-il fidèle ? »), utilisez un second modèle comme juge — un évaluateur avec une grille explicite, contrôlé par échantillonnage humain.

Un exemple concret

Une équipe maintient un assistant d’analyse de contrats :

jeu d'éval → 50 vrais contrats + clauses clés attendues
changement → quelqu'un « améliore » le prompt d'extraction
exécution  → le rappel des clauses passe de 92 % → 71 %
             sur les dates de renouvellement
verdict    → le nouveau prompt résume mieux, extrait moins
             bien les dates — rejeté, corrigé, relancé : 94 %

Sans le jeu d’éval, cette régression part en production et c’est un client qui la trouve.

Le kit de départ

• Commencez avec 20 cas, pas 500 — des entrées réelles, tirées de l’usage, y compris les moches.
• Chaque échec de production devient un cas de test. Votre jeu d’éval grandit depuis la réalité, comme une suite de régression.
• Notez simplement : correspondance exacte quand c’est possible, juge à grille explicite sinon, échantillonnage humain pour calibrer le juge.
• Suivez aussi le coût et la latence — un prompt 2 % meilleur et 3× plus cher est en général une régression (voir budgets & limites).

Le piège classique

Noter au feeling — y compris le modèle qui se note lui-même. « J’ai lu trois réponses et elles avaient l’air bien » ne survit pas au premier changement de prompt. Et un LLM qui juge sans grille dit « c’est très bien » presque aussi souvent qu’un humain qui survole. Jeu fixe, critères explicites, même mesure à chaque fois — c’est tout le truc.