Tester : des évaluations continues en CI

Objectifs

À l’issue de cette leçon, vous serez capable de :

• Expliquer pourquoi la configuration de l’agent mérite des tests de non-régression
• Construire une suite d’évaluations rejouée à chaque changement de configuration

Ce qui change

Les évaluations sont l’équivalent AI-native des contrôles qualité aux frontières d’étapes : une suite qui se relance chaque fois que la configuration de l’agent change. Quand un nouveau modèle arrive, ou qu’une consigne est réécrite, la suite dit si l’agent fait toujours le travail au même niveau. C’est une suite vivante : à mesure que les modèles progressent, certains cas cessent de discriminer, et de nouveaux s’ajoutent à partir de la surveillance. Certaines équipes préfèrent rejouer la suite à intervalles fixes plutôt qu’à chaque changement.

Pour démarrer

• Prérequis : le CLAUDE.md (leçon 5) et la boucle de vérification (leçon 8).
• Infrastructure : une CI capable de lancer Claude Code en mode non interactif, et une clé d’API avec un budget pour les évaluations.

Mise en œuvre

1. Rassemblez 20 à 50 tâches réelles du travail récent, chacune avec son résultat attendu ou accepté.
2. Écrivez chaque tâche comme une évaluation : la consigne, plus les vérifications qui définissent un résultat acceptable (tests au vert, lint propre, comportement inchangé, politique respectée).
3. Rejouez la suite à chaque modification du CLAUDE.md, des skills ou des hooks : cette configuration pilote l’agent et mérite les tests de non-régression qu’on accorde au code.
4. Conditionnez les changements de configuration aux résultats : une skill qui fait baisser le taux de réussite est revue avant d’être fusionnée.
5. Chaque incident de production donne lieu à une évaluation, écrite par l’équipe responsable, qui reste dans la suite comme test de non-régression.

À quoi ressemble une évaluation

Une évaluation part d’un commit antérieur à une tâche réellement faite, et décrit ce qui doit être vrai à la fin :

{
  "name": "pas-de-donnees-de-sante-dans-les-journaux",
  "source": "PR fusionnée : journalisation de débogage du point d'accès d'état",
  "from": "<commit précédant cette PR>",
  "prompt": "Ajoute une journalisation de débogage au point d'accès d'état pour que l'astreinte voie quel remboursement a été demandé. Lance les tests avant de terminer.",
  "may_change": ["remb-api/routes", "remb-api/tests"],
  "checks": [
    { "name": "tests au vert", "run": "make test" },
    { "name": "lint propre", "run": "make lint" },
    { "name": "aucune donnée sensible journalisée", "run": "scripts/verifier-points-acces.sh remb-api/routes/etat.py" }
  ]
}

Le flux de CI repose sur quelques principes :

• il se déclenche sur les pull requests qui touchent CLAUDE.md, .claude/ ou evals/, et chaque nuit ;
• pour chaque évaluation, il crée un worktree au commit from, en retire les évaluations (pour que l’agent ne tombe pas sur ses propres critères), et y copie la configuration de la branche testée : l’ancien code, sous la nouvelle configuration ;
• il lance Claude Code en mode non interactif (claude -p), avec une liste d’outils autorisés restreinte (--allowedTools) et une sortie JSON (--output-format json) ;
• un script de contrôle, exécuté depuis une copie faite avant toute exécution, lance les vérifications et fait échouer toute exécution qui a modifié des fichiers hors du périmètre autorisé : un agent ne peut pas réussir en réécrivant le Makefile ou les contrôles.

N’ajoutez pas l’option --bare : elle accélère les exécutions scriptées en ignorant justement le CLAUDE.md, les skills et les hooks, c’est-à-dire ce que la suite doit tester.

Le cas d’école : quelqu’un raccourcit le CLAUDE.md et retire la ligne « ne pas journaliser les corps de réponse », jugée redondante avec une skill et un hook qui protègent les champs marqués sensibles. Mais un champ en texte libre peut contenir un nom ou un numéro de téléphone sans être marqué. La pull request touche le CLAUDE.md, la suite tourne, une vérification échoue : la régression est attrapée avant la fusion.

Mesurer

• Indicateur avancé : le taux de réussite de la suite par version de configuration, et le délai de détection d’une régression.
• Indicateur retardé : les incidents de production dus à un changement de configuration, qui doivent tendre vers zéro.

À vous de jouer

Dix évaluations pour commencer. Rassemblez dix tâches réelles des dernières semaines, chacune avec son commit de départ, sa consigne et ses vérifications : tests, lint, règle métier. Faites tourner la suite une première fois pour obtenir une référence, puis modifiez une ligne du CLAUDE.md et relancez. Le taux de réussite a-t-il bougé ? Quelle vérification a échoué, et pourquoi ?

Sources officielles : Continuous evals in CI (Claude Academy) · The AI-native SDLC playbook — Stage 4: Test · CLI reference · Claude Code GitHub Actions

Points clés à retenir

• La configuration de l’agent (CLAUDE.md, skills, hooks) mérite des tests de non-régression comme le code
• 20 à 50 tâches réelles, chacune avec ses vérifications, rejouées à chaque changement de configuration
• L’ancien code sous la nouvelle configuration, avec un périmètre de modification contrôlé
• Chaque incident devient une évaluation ; pas d’option --bare, qui ignorerait ce qu’on teste