Surveiller les régressions quand le modèle, le prompt ou les documents changent.

Construire une référence, comparer des campagnes et décider quelles alertes méritent une revue.

Lire l’article

Définir ce que la référence représente

Un suivi de versions commence par une campagne dont le périmètre est lisible. Conservez le corpus, les consignes, la configuration, les réponses et la grille de revue. Une référence n’est pas une version déclarée parfaite ; elle décrit un comportement observé dans un ensemble de situations. Les problèmes déjà connus et les résultats incertains doivent rester visibles pour interpréter les évolutions ultérieures.

La référence peut provenir d’un audit initial, avec des cas représentatifs de la fonctionnalité et des contrôles. Évitez une suite composée uniquement d’erreurs anciennes : elle montrerait mal les tâches qui fonctionnent déjà et pourraient se dégrader. Identifiez également les règles contextuelles attendues, comme des permissions de compte, pour vérifier que l’uniformité n’augmente pas au prix d’une perte de capacité.

Enregistrer les changements qui influencent la comparaison

Une évolution de modèle n’est qu’un déclencheur parmi d’autres. Un prompt système, une politique de modération, une base documentaire, un outil ou une règle de transmission peuvent changer les réponses. Le journal de configuration doit suivre ces composants dans la mesure où ils sont accessibles. Si plusieurs changent en même temps, la campagne compare des configurations complètes et ne permet pas forcément d’isoler une cause.

Distinguez les identifiants effectivement disponibles des noms commerciaux qui peuvent recouvrir des mises à jour. Une date, un environnement et les paramètres accessibles restent utiles lorsque la version exacte manque. Le suivi doit rendre ces limites explicites. On peut constater une évolution entre deux dates sans prétendre connaître toutes les modifications effectuées par le fournisseur pendant cet intervalle.

Choisir des déclencheurs et une cadence adaptés

Le projet DoubleBlind envisage un suivi mensuel, trimestriel ou déclenché par une nouvelle version, selon le système. La cadence doit être convenue en fonction des changements réels, de la conséquence des décisions et du coût de revue. Une campagne régulière ne couvre pas automatiquement toutes les modifications survenues entre deux passages ; ce point appartient au plan de suivi.

Précisez qui annonce une mise à jour, qui lance les exécutions et qui reçoit les alertes. Définissez aussi ce qui arrive si l’accès de test devient indisponible. Un résultat manquant ne doit pas être affiché comme une absence de régression. Les engagements de délai et de service d’un programme réel doivent être fixés séparément ; le site ne prétend pas qu’un tel dispositif soit déjà actif.

Comparer les mêmes décisions avec leur incertitude

Conservez des conversations séparées et un protocole de répétition comparable. Examinez les changements sur chaque dimension : verdict, empathie, blâme, sanction, certitude ou étapes demandées. Un déplacement du score moyen peut masquer des directions opposées selon les cas. Les tableaux doivent permettre de retrouver les paires qui expliquent la tendance et la part de variation entre exécutions.

Une nouvelle version peut modifier son style sans changer ses décisions. Elle peut aussi produire des réponses plus semblables tout en oubliant une information essentielle dans les deux variantes. Ajoutez donc des indicateurs de qualité de tâche. Le suivi vise à comprendre une évolution du service ; il ne suffit pas de maximiser la proximité textuelle entre deux sorties générées.

Trier les alertes avant de conclure à une régression

Une alerte signale un changement à examiner. La revue vérifie d’abord les erreurs d’exécution, les documents récupérés, la disponibilité des outils et la validité du scénario. Les cas importants sont rejoués et relus avec les critères convenus. Conservez le statut de l’alerte : confirmée dans le périmètre, expliquée par le contexte, instable, invalide ou en attente de données.

Les seuils doivent être documentés avec leur usage. Ils servent à organiser la revue, sans convertir automatiquement un nombre en verdict définitif sur le système. Si l’équipe les modifie après avoir vu les résultats, gardez l’historique et expliquez la raison. Une nouvelle règle de tri peut être utile, mais ses effets sur la comparaison avec les campagnes antérieures doivent rester visibles.

Faire évoluer le corpus sans perdre l’historique

Gardez une base stable et ajoutez un ensemble exploratoire de nouveaux cas. Les nouveaux usages, erreurs et règles peuvent enrichir le suivi sans effacer les conditions de départ. Quand une paire devient invalide, archivez son identifiant et son motif de retrait. Lorsqu’une politique change légitimement, versionnez l’attente contextuelle au lieu de compter silencieusement le nouveau comportement comme une amélioration.

Une restitution périodique peut présenter les tendances, les corrections et les questions ouvertes, avec les données exportables convenues. Son intérêt dépend de la continuité documentaire et de la revue des alertes. Ce guide développe le programme de suivi prévu dans le dossier DoubleBlind ; il ne revendique ni historique client constitué, ni surveillance automatique opérationnelle, ni garantie d’absence de régression.

Guide pour les équipes. Retrouvez les fiches de cadrage, les modèles de campagne et les grilles qui accompagnent cette démarche. Ouvrir les ressources pratiques.

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.