8. Versionnage, rejeu et expérimentation

Une fois la plateforme au niveau 3, trois capacités avancées deviennent accessibles : le versionnage, le rejeu (replay) et l’expérimentation. Chacune démultiplie la valeur des données d’observabilité déjà collectées.

8.1 Versionner chaque artefact

Tout artefact qui influence la sortie doit être versionné et sa version capturée comme attribut de span. Sans cela, impossible de répondre à la question : le changement de version du prompt a-t-il causé la régression ?

Artefacts à versionner

• Les gabarits de prompts (système et utilisateur), par empreinte du contenu et par version sémantique.
• L’identité du modèle, y compris la version réellement servie renvoyée par le fournisseur et pas seulement le nom demandé.
• L’index de recherche, par instantané ou identifiant de construction.
• Le modèle de reclassement et ses poids.
• Les schémas d’outils exposés à l’agent.
• Les prompts des évaluateurs, lorsqu’un LLM juge est utilisé.
• La configuration complète de la fonctionnalité, sous forme d’une empreinte de configuration unique.

Capturés sous forme d’attributs

acme.prompt.version       = "rag-answer-v17"
acme.prompt.hash          = "sha256:..."
acme.retriever.index      = "kb-prod-2026-05-12"
acme.retriever.version    = "hybrid-v3"
acme.reranker.model       = "bge-rerank-v2"
acme.config.hash          = "sha256:..."
gen_ai.response.model     = "provider-model-2026-03-15"

Si une régression apparaît, la première requête est : regrouper par acme.prompt.version et calculer la fidélité moyenne. La réponse est à une requête de distance, ou elle est hors d’atteinte.

Identifiant neutre

La première version de ce guide utilisait dans cet exemple un nom de modèle commercial fictif. Il a été remplacé par un identifiant neutre : l’important est de capturer la version exacte et datée renvoyée par le fournisseur.

8.2 Rejeu

Rejouer, c’est faire passer une ancienne trace dans une autre version du système pour comparer les sorties. C’est le fondement des déploiements sûrs.

Ce que le rejeu permet

• Tester une nouvelle version de prompt sur le trafic de la semaine précédente avant de la déployer.
• Comparer un nouveau modèle au modèle de production actuel sur des entrées identiques.
• Réévaluer des traces historiques avec un évaluateur mis à jour pour voir la tendance avec la nouvelle grille.
• Reproduire une réclamation client pour valider qu’un correctif fonctionne.

Ce que le rejeu exige

• La capture complète du prompt et des arguments d’outils au moment de la trace d’origine.
• Un moyen de court-circuiter les appels externes non déterministes (réponses MCP figées, résultats de recherche figés).
• Un chemin d’exécution séparé qui ne pollue pas les traces de production.

Pièges courants

• Oublier que les résultats de recherche ont changé depuis la trace d’origine. Rejouez sur un index figé, ou acceptez que les écarts de recherche fassent partie de la comparaison.
• Rejouer avec la température d’origine : le bruit d’échantillonnage domine les petits écarts de score. Utilisez une température nulle ou l’auto-cohérence. Une température nulle réduit la variabilité sans la supprimer : elle n’est pas déterministe chez tous les fournisseurs et certains modèles de raisonnement n’acceptent pas ce paramètre. Dans ce cas, l’auto-cohérence ou plusieurs exécutions par trace sont la seule option.
• Laisser les traces de rejeu entrer dans les tableaux de bord de production. Marquez-les explicitement comme rejeu et excluez-les des alertes opérationnelles.

8.3 Expérimentation : mode fantôme et tests A/B

Trois modes de déploiement pour tester des changements sur le trafic réel.

Mode fantôme

• Le nouveau système tourne en parallèle de la production, mais sa sortie n’est pas renvoyée à l’utilisateur.
• Les deux sorties sont journalisées avec un identifiant de trace commun.
• Les évaluateurs notent les deux. Les écarts apparaissent dans un tableau de bord de comparaison.
• À utiliser pour les déploiements à forte confiance, où le nouveau système doit égaler ou dépasser la production.

Tests A/B

• Une fraction du trafic est routée vers le nouveau système. L’utilisateur voit la sortie expérimentale.
• L’attribut de trace acme.experiment.variant indique la branche à laquelle la requête a été affectée.
• Les métriques et les scores des évaluateurs sont agrégés par variante.
• La significativité statistique est requise avant de promouvoir une variante. Un écart de 1 % de fidélité sur 1 000 traces n’est pas significatif.

Canari

• Comme un test A/B, mais avec une petite fraction initiale (1 à 5 %), élargie progressivement.
• Retour arrière automatique en cas de régression de qualité détectée par les évaluateurs en ligne.
• Particulièrement adapté aux fonctionnalités à fort trafic, où le signal statistique arrive vite.

8.4 Blocage des régressions en intégration continue

L’ultime étape de maturité : bloquer les déploiements sur la base des résultats d’évaluation hors ligne.

1. Entretenir un jeu de non-régression couvrant les modes de défaillance observés en production.
2. Exécuter le prompt ou le modèle candidat sur ce jeu à chaque construction en intégration continue.
3. Noter chaque sortie avec les évaluateurs pertinents.
4. Faire échouer la construction si un score d’évaluateur passe sous le meilleur score précédent.
5. Traiter le jeu de non-régression comme un artefact vivant : chaque défaillance de production triée devient une nouvelle entrée.

Suite : 9. Anti-modèles et pièges courants.

Marquer comme lue