Un environnement jetable et idempotent

Le problème : le vrai pipeline écrit en base

Puisqu'on appelle le vrai pipeline (leçon précédente), il écrit : il crée des requêtes, enregistre des lignes, peut accumuler un historique. Deux dangers immédiats :

1. contaminer un vrai client — jamais, au grand jamais, l'éval ne doit tourner sur des données de production réelles ;
2. contaminer ses propres mesures — si chaque exécution laisse des traces qui influencent la suivante, tes scores dérivent d'un run à l'autre sans que le code ait changé.

La réponse : un tenant jetable à identité fixe

Le harness travaille sur un tenant dédié, jetable, à identifiant fixe (par exemple eval-…-0001). Trois propriétés le rendent sûr :

• isolé : c'est un tenant à part, jamais un client. Aucune donnée réelle n'y entre.
• idempotent : la commande de setup peut être relancée mille fois sans effet de bord — elle amène toujours la base au même état connu (catalogue chargé, tenant prêt). Pas de « ça marche seulement au premier run ».
• destructible : on peut le raser et le reconstruire à volonté. L'identifiant fixe garantit qu'on sait exactement quoi détruire.

C'est le même contrat qu'un bon test d'intégration : un état de départ reproductible, quoi qu'il se soit passé avant.

La contamination silencieuse

Le piège le plus subtil : certaines étapes apprennent. Un matcher peut mémoriser ses propres choix pendant le batch et s'auto-influencer — le fichier 50 est matché différemment du fichier 1 parce que le pipeline a « appris » entre les deux. Pour un chiffre propre, il faut pouvoir réinitialiser cet état entre deux mesures (ou le désactiver). Sinon tu ne mesures pas ton pipeline, tu mesures ton pipeline plus l'ordre dans lequel tu as passé les fichiers.

Un run d'éval doit être une fonction pure de (code, corpus, vérité) — surtout pas de l'historique accumulé pendant le run lui-même.