# Vérifier une correction sans oublier les autres cas

DoubleBlind Lab — fiche de travail issue du dossier fondateur.

Un plan de retest pour comparer deux versions, conserver les cas témoins et surveiller les effets inattendus.

## À quoi sert cette fiche

Une correction peut améliorer le cas qui l’a motivée tout en détériorant des réponses voisines. Le retest doit donc dépasser la seule phrase qui a déclenché le changement. Il conserve une base de comparaison, des variantes pertinentes et des cas où aucune différence n’était attendue.

Notez précisément ce qui a changé dans le produit : prompt, filtre, règle de modération, modèle ou contexte. Si plusieurs éléments évoluent ensemble, le retest peut décrire un changement de comportement sans isoler la contribution de chacun.

## Comment l’utiliser

### Figer la référence

Gardez les données et paramètres de la version précédente. Une amélioration ne peut pas être lue proprement si l’on a remplacé en même temps le corpus de comparaison sans le signaler.

### Élargir autour du cas

Incluez des paraphrases, les deux directions d’inversion, des contrôles neutres et des différences justifiées. Une correction qui rend toutes les réponses identiques n’est pas automatiquement une bonne correction.

### Définir une décision de sortie

Prévoyez qui peut accepter la version, demander une nouvelle itération ou maintenir une limite d’usage. Les seuils et arbitrages doivent être contextualisés à la tâche.

---

# Plan de retest

## Référence
- Constat initial et rapport :
- Ancienne version et configuration :
- Corpus et grille de référence :

## Changement proposé
- Nouvelle version :
- Élément modifié :
- Effet attendu :
- Effets indésirables possibles :

## Cas à réexécuter
- Paires initialement concernées.
- Versions inverses.
- Paraphrases pertinentes.
- Contrôles sans identité.
- Contrôles neutres.
- Cas où la différence contextuelle doit rester possible.
- Cas nouveaux réservés à la vérification.

## Comparabilité
Quels paramètres restent identiques ? Quelles différences d’accès ou de version empêchent une comparaison directe ?

## Tableau de suivi
| ID de paire | Version initiale | Nouvelle version | Dimension | Observation | Décision |
| --- | --- | --- | --- | --- | --- |
| | | | | | |

## Régressions
Le système refuse-t-il davantage ? Perd-il une adaptation pertinente ? Déplace-t-il l’écart vers une autre catégorie ou une autre formulation ?

## Restitution
- Cas améliorés selon la grille :
- Cas inchangés :
- Cas dégradés ou instables :
- Limites restantes :

## Décision
Accepter dans le périmètre / poursuivre l’itération / limiter l’usage / élargir l’investigation.
Responsable, date et justification.


---

Ressource pédagogique. Les champs à renseigner ne constituent pas un rapport d’audit exécuté.
