Déploiement canary pour l'IA : réduire le risque

Le moment le plus dangereux dans la vie d’un agent IA, ce n’est pas le développement. C’est le déploiement. Une nouvelle version d’un prompt, un changement de modèle, une mise à jour du découpage documentaire : chacune de ces modifications peut améliorer le système, ou le dégrader silencieusement pour des milliers d’utilisateurs à la fois. Quand on déploie pour tout le monde d’un coup, on découvre les régressions au moment où elles font le plus de dégâts.

Le problème est aggravé par la nature non déterministe des modèles. Contrairement à un déploiement classique, où un test qui passe en recette passera en production, un agent peut se comporter différemment face au trafic réel, avec des questions imprévues et des cas limites que le jeu de test ne couvrait pas. Cette incertitude rend le déploiement brutal particulièrement risqué pour les systèmes à base d’IA.

Le déploiement canary répond à ce problème : on expose une petite fraction du trafic à la nouvelle version, on mesure, puis on élargit. En cas de régression, on revient en arrière avant qu’elle ne se généralise.

Pourquoi un déploiement IA est plus risqué qu’un autre

Un déploiement logiciel classique porte sur un comportement déterministe : à entrée égale, sortie égale. Les tests automatisés donnent donc une bonne confiance, et le risque résiduel est faible. Un déploiement IA porte sur un comportement probabiliste : la même question peut produire des réponses différentes, et la qualité dépend du contexte, des données et du modèle. Les tests donnent une indication, jamais une garantie.

Le deuxième facteur de risque, c’est la surface de changement invisible. Modifier un prompt système de quelques mots peut changer le comportement de l’agent sur des cas que personne n’avait anticipés. Changer de version de modèle peut améliorer la moyenne tout en dégradant des cas spécifiques importants pour votre métier. Ces effets ne se voient pas dans les métriques globales : ils se voient dans les cas particuliers, qui sont précisément ce que vos utilisateurs remarquent.

Le troisième facteur, c’est l’irréversibilité perçue. Une fois qu’une mauvaise version a répondu à des utilisateurs, le mal est fait : une réponse inventée, un conseil erroné, une donnée exposée ne s’effacent pas. Le coût d’une régression IA n’est pas seulement technique, il est aussi commercial et parfois juridique. C’est ce coût qui justifie d’investir dans un déploiement progressif.

Le principe du canary, appliqué à l’IA

Le principe est simple : faire coexister l’ancienne et la nouvelle version, et router une petite partie du trafic vers la nouvelle. On commence typiquement par 1 à 5 % des requêtes, on observe pendant une période suffisante pour accumuler des données significatives, puis on augmente par paliers : 10 %, 25 %, 50 %, 100 %. À chaque palier, on compare les deux versions sur les métriques qui comptent.

Pour un agent IA, le routage peut se faire par utilisateur, par session ou par requête, selon ce qui est pertinent. Le routage par utilisateur garantit une expérience cohérente pour chacun : un utilisateur voit toujours la même version pendant la période de test. Le routage par requête donne plus de données plus vite, mais mélange les versions au sein d’une même session. Le choix dépend de votre usage et de ce que vous mesurez. Techniquement, ce routage passe par un système de feature flags (LaunchDarkly, Unleash), par la passerelle de modèles (LiteLLM sait répartir le trafic entre deux modèles), ou, sur Kubernetes, par un outil de déploiement progressif comme Argo Rollouts.

La durée de chaque palier doit permettre d’observer des comportements représentatifs. Quelques heures suffisent rarement, parce que le trafic varie selon les moments de la journée et les jours de la semaine. Comptez en jours plutôt qu’en heures, et assurez-vous que chaque palier couvre les pics d’usage réels, pas seulement les heures creuses.

Ce qu’on mesure pendant le canary

Un canary sans mesure ne sert à rien. Il faut définir avant le déploiement les métriques qui décideront de la suite, avec des seuils explicites : en dessous de tel seuil, on avance ; au-dessus, on revient en arrière. Ces métriques doivent couvrir la qualité des réponses, la satisfaction des utilisateurs et la santé technique du système. Elles supposent une instrumentation déjà en place, celle qu’on décrit dans monitorer un agent en production.

Côté qualité, on suit le taux de réponses évaluées comme correctes, le taux d’abstention quand l’information manque, et le taux de remontées négatives des utilisateurs. On compare la nouvelle version à l’ancienne sur les mêmes requêtes ou sur des requêtes équivalentes. Étiqueter chaque trace avec sa version, dans Langfuse ou LangSmith, permet ensuite de filtrer et de comparer les deux populations sans développement spécifique. Un écart significatif sur l’une de ces métriques est un signal d’alerte, même si la moyenne semble stable.

Côté technique, on surveille la latence, le taux d’erreur, la consommation de tokens et le coût par requête. Un changement de modèle peut diviser le coût par deux ou le multiplier par trois, et cette information fait partie de la décision. Un canary qui ignore le coût peut valider une version meilleure mais économiquement intenable.

Quand basculer, quand revenir en arrière

La règle d’or : on n’avance au palier suivant que si les métriques sont au vert, et on revient en arrière dès qu’elles passent au rouge. Ces seuils gagnent à être formalisés sous forme d’objectifs de service, comme on le détaille dans SLO et alertes pour un service IA. Cette règle doit être écrite avant le déploiement, pas improvisée sous la pression. Elle protège l’équipe contre le biais qui consiste à minimiser un signal négatif parce qu’on a investi du temps dans la nouvelle version.

Le retour en arrière doit être rapide et sans friction : l’ancienne version reste déployée, prête à reprendre le trafic, avec une bascule testée à l’avance. Un retour qui demande une intervention manuelle complexe arrivera toujours trop tard.

Les erreurs classiques à éviter

La première erreur, c’est de tester le canary sur un trafic non représentatif. Si la nouvelle version ne reçoit que les requêtes simples pendant que les cas complexes restent sur l’ancienne, la comparaison ne vaut rien. Le routage doit être aléatoire ou stratifié pour garantir que les deux versions voient le même type de trafic.

La deuxième erreur, c’est de ne mesurer que la moyenne. Une nouvelle version peut améliorer la moyenne tout en dégradant fortement une minorité de cas importants. Segmentez les métriques par type de requête, par catégorie d’utilisateur et par criticité. Les régressions se cachent dans les segments, jamais dans la moyenne. C’est aussi pour cela qu’un canary ne remplace pas les tests de non-régression en amont : il attrape ce qu’ils n’ont pas vu, il ne les dispense pas.

La troisième erreur, c’est d’oublier de nettoyer. Un canary qui traîne pendant des semaines avec deux versions en production devient une dette : deux configurations à maintenir, deux comportements à documenter, des utilisateurs qui voient des choses différentes sans qu’on sache pourquoi. Un canary a une fin prévue : bascule complète ou abandon, avec une date butoir.

Par où commencer sur les déploiements IA

Mettre en place un déploiement canary pour un agent ou un RAG demande une infrastructure et une discipline que les équipes produit n’ont pas toujours le temps de construire : deux versions qui tournent en parallèle, un routage maîtrisé, des métriques comparables et une bascule de retour testée à l’avance.

Sur les agents qu’on met en production, le canary fait partie du circuit standard, au même titre que les evals et la CI : on définit avant chaque changement ce qu’on mesure et les seuils de décision, on conduit les paliers, puis on tranche sur des chiffres. Tout est documenté dans vos outils pour que la pratique reste chez vous. C’est l’une des briques de notre méthode, avec les garde-fous qui l’entourent.

Si votre prochain changement de modèle ou de prompt doit partir pour 100 % du trafic faute de mieux, commencez simplement : 5 % des utilisateurs, trois métriques, une date butoir. C’est déjà bien moins risqué qu’une bascule complète.