A/B testing en production : au-delà du shadow traffic

Faire de l'A/B testing en production, pas seulement du shadow traffic : c'est ce que propose Together AI dans un article publié le 17 août, qui pointe une limite rarement discutée. Le shadow traffic prouve qu'un modèle candidat tient la route en production, mais il ne dit rien de ce que les utilisateurs en pensent réellement. Pour une équipe qui change régulièrement de version de modèle — nouvelle génération Claude, mise à jour Mistral, itération interne d'un modèle fine-tuné — c'est exactement la question qui compte le plus, et celle que le shadow traffic ne peut pas trancher.

Le contexte

Le shadow traffic consiste à dupliquer une partie du trafic de production vers un modèle candidat, sans jamais exposer sa réponse à l'utilisateur final. L'utilisateur continue de voir la réponse du modèle en place ; en coulisse, le candidat traite la même requête et son résultat est comparé sur des métriques opérationnelles : latence, taux d'erreur, coût par requête, stabilité sous charge. C'est une pratique solide et peu risquée — aucune chance qu'un candidat bogué atteigne un vrai utilisateur.

Mais cette solidité a un prix : le shadow traffic ne mesure jamais la préférence. Un modèle peut être aussi rapide, aussi fiable et moins cher que l'ancien, tout en produisant des réponses moins utiles, moins précises ou moins bien formulées. Ces défauts n'apparaissent dans aucune métrique d'infrastructure — ils n'apparaissent que dans le comportement réel des utilisateurs face à une vraie réponse.

Pourquoi le shadow traffic ne suffit pas

Together AI résume le problème en une phrase directe : « Shadow traffic proves a candidate is operationally sound. It can't tell you if users like it better » — le shadow traffic prouve qu'un candidat est opérationnellement sain, il ne peut pas dire si les utilisateurs le préfèrent.

C'est un écart que beaucoup d'équipes découvrent au pire moment : après avoir bascule un modèle en production sur la seule foi de ses métriques d'infrastructure, en constatant ensuite une hausse silencieuse des reformulations, des tickets support, ou du taux d'abandon — sans qu'aucune alerte technique ne se soit déclenchée. Le modèle n'a jamais été « en panne ». Il a juste été moins bon, d'une façon qu'aucun dashboard de latence ne capture.

Faire l'A/B testing au niveau de l'endpoint, pas dans le code applicatif

La proposition de Together AI est de sortir l'A/B test du code applicatif pour le faire vivre au niveau de l'infrastructure d'endpoint. Concrètement : au lieu d'un if/else dans le service qui appelle le modèle, le split de trafic entre variante A et variante B est géré par la couche d'inférence elle-même.

L'intérêt n'est pas seulement esthétique. Un split géré en infrastructure permet de changer le ratio de trafic (10 % puis 25 % puis 50 %) sans toucher au code ni redéployer l'application. Il centralise aussi la mesure : les deux variantes passent par le même point d'observabilité, ce qui évite les biais qu'introduit souvent un split fait à la main dans plusieurs services différents.

Ce n'est pas une idée isolée à Together AI. Sur Vertex AI, Google Cloud documente un mécanisme comparable de répartition du trafic entre versions de modèle lors d'un déploiement progressif (« rolling deployment »), qui permet de migrer le trafic d'une version à l'autre par paliers plutôt que par bascule brutale. Le principe se retrouve dans plusieurs plateformes d'inférence : découpler la décision de routage de la logique métier.

Cohortes utilisateur et cohérence de session

Un point technique souvent sous-estimé : un même utilisateur doit voir la même variante pendant toute la durée du test. Sans routage cohérent par utilisateur (ou par session), une personne peut recevoir tantôt la réponse du modèle A, tantôt celle du modèle B, au fil de ses échanges — ce qui rend toute mesure de préférence inexploitable, puisqu'on ne compare plus deux populations distinctes mais un mélange. La pratique courante est de hacher un identifiant stable (utilisateur, session, ou compte) pour assigner une cohorte de façon déterministe et durable sur toute la fenêtre du test.

Que mesurer dans un A/B test de modèles IA en production

Une fois le split en place, la question suivante est ce qu'on mesure réellement. Les métriques d'infrastructure (latence, taux d'erreur, coût) restent nécessaires — un candidat qui les dégrade doit être écarté avant même de parler de préférence. Mais elles ne suffisent pas à trancher entre deux modèles également stables. Ce qui manque, ce sont des signaux de satisfaction réelle :

Taux de reformulation — un utilisateur qui reformule immédiatement sa question signale souvent une première réponse insatisfaisante.
Taux de résolution — la conversation ou la tâche s'est-elle terminée sans intervention humaine ?
Retours explicites — pouce levé/baissé, notation, ou tout signal de satisfaction directement collecté.
Comportement en aval — un utilisateur qui abandonne la session après une réponse du modèle candidat, comparé à la variante de référence.

Un point de rigueur à ne pas sauter : ces signaux sont bruités, et conclure trop tôt sur un petit échantillon revient à se tromper avec confiance. Une fenêtre de test suffisamment longue, et une taille d'échantillon calculée en amont plutôt qu'observée a posteriori, sont ce qui sépare un vrai A/B test d'une impression.

Quand arrêter le test et trancher

Un A/B test mal terminé est presque aussi trompeur qu'un test jamais lancé. Deux erreurs reviennent souvent. La première : arrêter dès qu'un écart favorable apparaît, sans avoir atteint la taille d'échantillon calculée au départ — c'est le meilleur moyen de généraliser un pur effet de hasard. La seconde, plus discrète : laisser le test tourner indéfiniment « pour être sûr », ce qui retarde une décision sans que la certitude supplémentaire justifie le coût de faire tourner deux modèles en parallèle.

La bonne pratique consiste à fixer, avant de lancer le test, trois éléments : le seuil de différence qui justifierait de basculer (par exemple un gain de 5 points sur le taux de résolution), la taille d'échantillon nécessaire pour détecter ce seuil avec une confiance raisonnable, et une date ou un volume de trafic au-delà duquel le test s'arrête de toute façon — gagnant déclaré ou non. Cette dernière règle évite qu'un test à la marge d'erreur trop large reste indéfiniment « en cours d'évaluation » sans jamais produire de décision.

Il faut aussi prévoir le chemin de sortie inverse : si le candidat dégrade un signal opérationnel en cours de route — pas seulement la préférence, mais la latence ou le taux d'erreur — le test doit pouvoir être coupé immédiatement, sans attendre la fin de la fenêtre prévue. Un bon dispositif d'A/B testing en production inclut donc, dès la conception, ses propres conditions d'arrêt anticipé.

Ce que ça change pour les équipes IA

Pour une équipe qui industrialise des agents ou des assistants IA en production, ce changement de méthode a une conséquence concrète : chaque montée de version de modèle cesse d'être un pari et devient une décision mesurée. Au lieu de choisir entre « on garde l'ancien modèle par prudence » et « on bascule tout le monde d'un coup et on espère », l'équipe dispose d'un chemin intermédiaire — exposer une fraction contrôlée du trafic, mesurer la préférence réelle, et ne généraliser qu'une fois le signal net.

C'est particulièrement pertinent dans un contexte où le choix du modèle génératif est de plus en plus pensé comme une couche remplaçable plutôt que comme une décision figée — routage vers le modèle le plus adapté à chaque type de requête, arbitrage coût/qualité par cas d'usage, veille permanente sur les nouvelles générations de modèles. Un A/B test propre au niveau de l'endpoint est ce qui rend ce remplacement continu réellement pilotable, plutôt que subi.

Ça change aussi la manière de présenter une migration de modèle en interne : au lieu d'un argumentaire basé sur des benchmarks publics ou des métriques d'infrastructure, l'équipe peut montrer un signal de préférence mesuré sur son propre trafic réel, avec ses propres utilisateurs et ses propres cas d'usage — un argument nettement plus solide face à des parties prenantes qui doivent valider le changement.

Il y a enfin un effet secondaire utile, souvent sous-estimé au moment de justifier l'investissement dans ce type d'infrastructure : une fois le split de trafic et la mesure de préférence en place pour un test, le même dispositif sert à autre chose qu'à comparer deux versions de modèle. Il devient l'infrastructure par défaut pour tester un nouveau prompt système, une nouvelle stratégie de récupération documentaire dans un pipeline RAG, ou un nouveau jeu d'outils mis à disposition d'un agent. La discipline de mesure — cohortes stables, seuil de décision fixé à l'avance, conditions d'arrêt anticipé — se réutilise telle quelle, bien au-delà du seul cas du changement de modèle. C'est un investissement d'infrastructure qui se rentabilise sur l'ensemble du cycle de vie d'un système IA en production, pas sur une seule migration.

En bref

Le shadow traffic prouve la stabilité opérationnelle d'un modèle candidat, pas la préférence des utilisateurs — ce sont deux questions différentes.
Faire le split de trafic au niveau de l'endpoint plutôt que dans le code applicatif permet d'ajuster les ratios sans redéploiement et centralise la mesure.
Le routage doit être cohérent par utilisateur ou session pendant toute la durée du test, sous peine de mesurer un mélange plutôt que deux populations distinctes.
Les métriques de préférence (reformulation, résolution, retours explicites) complètent les métriques d'infrastructure — ni l'une ni l'autre ne suffit seule.
Une fenêtre de test et une taille d'échantillon définies à l'avance évitent de conclure trop tôt sur un signal bruité.

Bien fait, l'A/B testing en production devient une infrastructure permanente pour toute décision qui touche au comportement d'un système IA — pas un dispositif ponctuel réservé au changement de modèle.

Vous industrialisez vos agents IA ? SeedVision propose des audits IA en 3-5 jours et des forfaits de mise en production de 15 à 30 jours. Voir les packages ou réserver un appel de 30 min.

Photo de couverture : Photo by Taylor Vick on Unsplash.