Vous avez intégré un modèle de langage dans un processus métier. Il fonctionne bien pendant quelques semaines, puis les résultats se dégradent sans alerte. Les réponses deviennent plus vagues, certains appels échouent silencieusement, et le taux de refus augmente sans explication apparente. Ce scénario est courant dès que l'on exploite un LLM en production, et il révèle un angle mort critique : l'absence de monitoring comportemental. Contrairement à un logiciel classique, un LLM ne plante pas de façon visible. Il dérive.
Cette dérive prend trois formes principales qu'il faut surveiller séparément. La première est la dérive sémantique : le modèle produit des sorties qui restent syntaxiquement correctes mais s'éloignent progressivement du comportement attendu. Cela arrive après une mise à jour du fournisseur, un changement de version silencieux ou simplement parce que le contexte des requêtes évolue. La deuxième forme concerne les relances excessives (retries). Un appel API qui échoue est relancé automatiquement, ce qui gonfle les coûts et la latence sans que personne ne s'en aperçoive si les logs ne distinguent pas les appels initiaux des relances. La troisième forme est le refus : le modèle décline de répondre ou produit une réponse générique de sécurité. Un taux de refus qui passe de 2 % à 8 % en une semaine signale un problème concret, soit dans vos prompts, soit dans les garde-fous du fournisseur.
Pour surveiller ces trois dimensions, il faut mettre en place un cadre de monitoring structuré. Commencez par instrumenter chaque appel avec un identifiant unique, un horodatage, le prompt envoyé, la réponse reçue, le statut HTTP et le nombre de tentatives. Ensuite, définissez des métriques comportementales claires : score de similarité entre la sortie obtenue et une sortie de référence pour détecter la dérive, ratio relances/appels initiaux pour repérer les problèmes de fiabilité, et taux de refus catégorisé par type de requête. Ces métriques doivent être suivies quotidiennement et comparées à une baseline établie lors de la mise en production. Un tableau de bord dédié, même simple, est indispensable pour rendre ces signaux visibles aux équipes concernées.
Les erreurs les plus fréquentes dans ce domaine sont prévisibles. Beaucoup d'équipes se contentent de surveiller la disponibilité de l'API et le temps de réponse, sans regarder la qualité des sorties. D'autres agrègent toutes les requêtes dans une seule métrique globale, ce qui masque les dégradations localisées sur certains types de tâches. Une autre erreur courante est de ne pas versionner les prompts : quand la dérive apparaît, il devient impossible de distinguer un changement côté modèle d'un changement côté prompt. Enfin, négliger les refus parce qu'ils semblent rares conduit à découvrir trop tard qu'une catégorie entière de requêtes métier ne fonctionne plus.
Ce type de surveillance s'inscrit dans une démarche plus large de performance digitale, où chaque composant technique est évalué non pas seulement sur sa disponibilité, mais sur sa capacité à produire un résultat métier fiable. Un LLM qui répond vite mais mal est un coût, pas un actif.
Le point essentiel à retenir : un LLM en production nécessite un monitoring comportemental, pas seulement technique. Suivez la dérive sémantique, les relances et les refus comme trois signaux distincts. Versionnez vos prompts. Établissez une baseline dès le déploiement et comparez-y chaque semaine les résultats observés. Sans cette discipline, vous pilotez à l'aveugle un système dont le comportement change sans prévenir.