Quel seuil d'alerte faut-il choisir ?

Aucun seuil universel n'existe. Il se fixe après quelques semaines de mesure sur votre propre trafic, en regardant la valeur habituelle et les écarts qui ont vraiment causé un problème.

Combien d'alertes faut-il activer ?

Peu. Une alerte qui se déclenche tous les jours est ignorée au bout de quelques jours. Mieux vaut quelques alertes qui demandent une action, avec un responsable désigné pour chacune.

Alerte sur une IA en production : six signaux à suivre

Une alerte utile répond à une question précise : que dois-je faire maintenant ? Sur une IA en production, les signaux sont nombreux, mais six suffisent à couvrir la plupart des incidents. Ce guide les présente, avec la façon de fixer leurs seuils. Aucun chiffre de référence n'est donné comme une norme : les seuils dépendent de votre trafic, de votre modèle et de ce que coûte une erreur pour vos utilisateurs.

Méthode en trois temps

Mesurer avant d'alerter. Pendant deux à quatre semaines, enregistrez chaque signal sans déclencher d'alerte. Vous obtenez une valeur habituelle, avec ses variations normales.
Fixer un seuil par signal. Choisissez un seuil qui sépare le bruit d'un problème réel. Un seuil fixé au niveau de la moyenne se déclenche sans arrêt ; un seuil trop haut ne sert à rien.
Désigner une réponse. Pour chaque alerte, écrivez qui agit et ce qu'il fait : réduire le trafic, basculer sur un autre modèle, prévenir les équipes métier.

Les six signaux

1. Les erreurs

Le signal le plus simple est la proportion de réponses en erreur. La documentation d'Anthropic distingue plusieurs familles : les erreurs de requête (400), d'authentification (401), de facturation (402), les limites de débit (429), les erreurs internes (500), les délais dépassés (504) et la surcharge (529). Une hausse des 429 ou des 529 n'a pas la même cause qu'une hausse des 401. Séparez-les dans l'alerte, sinon le responsable ne sait pas où regarder.

2. La latence

Le temps de réponse se mesure par requête, dans la trace. Langfuse enregistre la latence de chaque requête. Il faut suivre un percentile élevé, par exemple le 95e, plutôt que la moyenne, qui masque les cas lents. Une latence qui augmente sans changement de code peut venir d'une saturation de l'API ou d'une réponse plus longue.

3. Les refus et les réponses de repli

Un refus est une réponse qui ne répond pas à la demande, ou que votre code remplace par une réponse de repli. Le suivi se fait dans votre application, pas dans l'API : comptez les cas où le code envoie un message du type « je ne peux pas vous aider » ou bascule vers une réponse standard. Une hausse soudaine peut signaler un changement de prompt ou un modèle qui a changé de comportement. Voir dérive d'un modèle après une mise à jour.

4. Le coût

Le coût se calcule à partir des tokens que l'API renvoie pour chaque appel. Langfuse et les autres outils de la comparaison suivent cette dépense par modèle et par requête. Trois alertes sont utiles : une dépense quotidienne au-dessus de la valeur habituelle, une dépense par utilisateur anormalement haute, et un plafond mensuel. Le plafond de dépense relève de la console du fournisseur ; l'alerte, de votre supervision. Pour les calculs, voir suivre ses dépenses d'API d'IA et poser des alertes.

5. La longueur des réponses

Une réponse qui s'allonge coûte plus cher et peut dérouter l'utilisateur. Suivez le nombre de tokens de sortie par type de requête. Une moyenne qui double en une semaine est un signal à examiner, même si aucune erreur n'apparaît. Une réponse tronquée, qui s'arrête au plafond de tokens fixé par votre code, doit aussi être comptée à part.

6. Les retours des utilisateurs

Un pouce baissé ou un commentaire négatif est le signal le plus proche de la réalité. Il ne sert à rien seul : il faut le relier à la trace concernée pour savoir ce qui a mal tourné. Langfuse décrit la collecte de scores à la main, par l'API ou par des évaluateurs automatiques. Le détail est dans retours des utilisateurs : pouce et traces.

Exemple de règle, à adapter

Ce qui suit est un exemple de structure, pas une valeur à reprendre : « si la part de réponses en 429 dépasse, sur une heure, le seuil que nous avons mesuré en période normale, le responsable de l'exploitation réduit le trafic et prévient l'équipe ». Le seuil est celui de votre mesure, jamais un chiffre emprunté à un article.

Ce qu'il faut éviter

Une alerte par signal sans responsable désigné.
Un seuil copié d'un autre projet, qui ne tient pas compte de votre trafic.
Des alertes qui ne sont jamais revues. Relisez-les une fois par trimestre : supprimez celles qui ne mènent à aucune action.

Pour la suite d'un incident, voir le journal d'incident d'une IA.