Remonter du constat à la réponse qui le soutient.

Relier cas, configuration, exécution, annotation et conclusion pour permettre une reprise ou une contestation du résultat.

Lire l’article

Construire une chaîne de références courte

Un constat utile doit pouvoir remonter à ses pièces : scénario, version miroir, paramètres, réponse brute et annotation. On peut représenter cette chaîne par quelques identifiants stables. L’objectif est simple : lorsqu’un lecteur conteste une conclusion, l’équipe retrouve le texte exact et les conditions de son obtention, sans dépendre du souvenir de la personne qui a mené la campagne.

Dans un exemple fictif, le cas SUPPORT-014 appartient au corpus v1.2, sa version B est exécutée pendant la campagne SEPT-01 et produit la réponse RUN-0087. Deux annotations distinctes citent ensuite cette réponse. Le rapport peut utiliser des références lisibles issues de cette chaîne. Aucun de ces identifiants n’a besoin de contenir le nom d’une personne réelle ou une donnée sensible.

Décrire le système réellement interrogé

Le nom commercial d’un modèle ne suffit pas toujours à décrire l’environnement. La fiche consigne la version exposée, l’interface utilisée, les instructions initiales, les outils disponibles et les paramètres accessibles. Si un réglage n’est pas fourni par le service, on le marque comme non disponible. Inventer une valeur par défaut donnerait une apparence de précision sans fondement.

La configuration comprend aussi les éléments susceptibles d’ajouter du contexte : historique de conversation, documents fournis et résultats d’outils utilisés dans la réponse. Lorsque l’exercice ne nécessite pas ces éléments, le protocole peut les exclure explicitement. Lorsque l’usage les exige, on décrit leur rôle et leur version afin de comprendre ce que le système pouvait effectivement prendre en compte.

Conserver la sortie brute et ses événements techniques

La réponse originale reste distincte de sa mise en forme pour le rapport. Une suppression de préambule, une traduction ou une correction de ponctuation peut changer ce que l’évaluateur perçoit. On conserve donc la sortie telle qu’elle a été reçue, puis on relie toute version de lecture à cette source. Les transformations doivent être explicites et réversibles lorsque cela est possible.

Chaque tentative reçoit un horodatage, un statut et les informations disponibles sur son déroulement. Une interruption, une erreur de connexion et un refus rédigé par le système ne sont pas équivalents. Si une tentative est reprise, le lien est conservé. Le rapport peut ainsi expliquer pourquoi certaines réponses sont absentes, incomplètes ou exclues d’une comparaison donnée.

Versionner aussi les décisions humaines

Le manuel d’annotation et les décisions d’arbitrage font partie de la provenance. Deux évaluations réalisées avec des définitions différentes ne devraient pas être regroupées sans explication. Lorsqu’une règle change, on identifie les réponses qui nécessitent une nouvelle lecture et on conserve les annotations initiales. Le résultat final peut alors être reconstruit à partir de la version de méthode annoncée.

Le même principe s’applique aux exclusions et aux corrections factuelles après une relecture contradictoire. Modifier une conclusion parce qu’un scénario était mal décrit est une correction utile. Elle devient difficile à comprendre si la première version disparaît sans trace. Une note courte peut préciser le problème, les pièces concernées et la portée de la correction sur le bilan.

Distinguer reproduction, comparaison et stabilité

Rejouer les mêmes entrées avec une configuration documentée permet de tenter une reproduction. Cela ne garantit pas des textes identiques, notamment lorsque le service évolue ou conserve des paramètres internes non exposés. Une campagne ultérieure peut donc être comparable sur certains éléments et différente sur d’autres. Ces limites doivent accompagner la lecture, pas apparaître seulement après une contestation.

Le protocole peut distinguer une reprise immédiate, un retest après correction et une nouvelle campagne dans le temps. La première explore une observation existante ; le deuxième évalue un changement ; la troisième examine une évolution plus large. Donner un nom et un identifiant à chaque opération évite d’assembler des réponses issues d’objectifs différents comme si elles formaient un seul essai.

Publier ce qui permet une vérification utile

Un dossier public peut comprendre les scénarios synthétiques diffusables, la fiche de configuration, les critères d’annotation, les extraits nécessaires et le registre des limites. Les éléments non publiés sont signalés avec leur effet sur la vérifiabilité. La traçabilité n’impose pas de diffuser des secrets techniques ou des conversations privées ; elle impose de ne pas prétendre les rendre vérifiables lorsqu’ils ne le sont pas.

Le test pratique est de demander à une personne extérieure de retrouver le chemin entre une phrase du rapport et ses pièces. Si elle ne sait pas quelle réponse a été notée ou quelle version a été utilisée, la chaîne est incomplète. La provenance transforme ainsi une collection d’exemples en un dossier que l’on peut relire, corriger et prolonger.

Note de méthode. Pour situer cette lecture dans l’ensemble du protocole, retrouvez les étapes, les critères d’analyse et leurs limites. Lire la méthode DoubleBlind.

Mettre la lecture en pratique

Regarder les faits,
puis inverser l’identité.

Explorez les scénarios synthétiques ou préparez votre propre paire miroir.

Continuer la lecture
Toute la bibliothèque
Tout le laboratoire

Une question en tête ?

Articles, cas, outils et parcours. Échap pour fermer.