LLM : pourquoi votre monitoring classique ne voit rien

Avouons-le : si vous supervisez vos applications boostées par l'IA comme vos bonnes vieilles API REST, vous naviguez à l'aveugle.

Je le vois tout le temps. Des équipes déploient leur service IA, le branchent sur leur stack d'observabilité existante, vérifient que les voyants sont au vert… et se prennent le mur quand les utilisateurs se plaignent de la qualité des réponses ou quand la facture mensuelle explose de 300%.

Les outils leur disent que tout va bien. Ce n'est pas le cas.

Le problème n'est pas juste de choisir d'autres métriques. C'est que les systèmes IA cassent les hypothèses sur lesquelles toute notre infrastructure de monitoring a été construite.

Le modèle web ne colle plus

La supervision traditionnelle fonctionne sur un signal propre : une requête arrive, du travail se fait, une réponse sort. Succès ou échec, c'est binaire. La latence, c'est de la latence. Votre percentile 99 vous dit quelque chose d'utile.

Les LLM réduisent tout ça en miettes.

Une réponse n'arrive pas d'un coup — elle se génère token après token. Du coup, « la latence » devient au moins trois chiffres différents selon où vous vous situez dans le processus. Un code 200 ne veut rien dire sur la qualité du résultat. Le coût dépend des tokens, pas des requêtes. Et les pannes les plus graves sont complètement silencieuses : le modèle vous sort une absurdité avec assurance,包装ée dans un statut HTTP parfait.

Time to First Token : ce que l'utilisateur ressent

Quand quelqu'un envoie un prompt à votre fonctionnalité IA, la première chose qu'il vit, c'est l'attente. Plus précisément, il attend de voir le premier token apparaître. C'est le Time to First Token (TTFT), et c'est l'équivalent le plus proche de la « latence perçue » dans le monde des LLM.

Ce qui rend le TTFT délicat : il augmente avec la longueur du prompt. Si vous construisez un système RAG qui bourre des fenêtres de contexte massives dans chaque requête pour améliorer la précision, vous sabotez simultanément la performance perçue. C'est un compromis fondamental que votre monitoring traditionnel ne vous mettra jamais sous le nez.

Inter-Token Latency : le facteur fluidité

Une fois le streaming lancé, les utilisateurs développent des attentes sur la vitesse de lecture. L'Inter-Token Latency (ITL) — l'écart entre les tokens consécutifs — détermine si le résultat paraît fluide ou saccadé.

Les utilisateurs pardonnent un flux lent mais régulier. Ils détestent un flux plus rapide qui freeze et trébuche. Votre monitoring doit faire la différence entre ces deux expériences, même quand le débit brut semble acceptable.

Latence de bout en bout : le contexte change tout

La métrique p99 qui fonctionne merveilleusement pour votre API REST vous induira complètement en erreur pour des requêtes IA. Pourquoi ? Parce qu'une tâche de classification de 50 tokens et une génération de rapport de 2 000 tokens ont des profils de latence radicalement différents, et les mixer produit un chiffre qui ne représente rien.

Suivez la latence par cas d'usage. Chaque métrique doit correspondre à une charge de travail aux caractéristiques cohérentes. Sinon vous optimisez pour une abstraction qui n'existe pas.

Le problème des pannes silencieuses

Voici la partie flippante : les pires incidents en production avec des systèmes IA ne déclenchent souvent aucune alerte.

Votre modèle se met à générer des hallucinations assurance. Votre dérive de prompt introduit un biais subtil. Le contexte récupéré est ignoré au profit de souvenirs d'entraînement. Tout ça retourne un HTTP 200, se termine dans les temps, et paraît parfaitement sain sur votre dashboard.

Les checks de disponibilité ne suffiront pas. Vous avez besoin d'une supervision de la qualité des sorties, et c'est plus difficile à instrumenter — mais absolument vital.

Ce qui compte vraiment

Organisez vos métriques IA autour des questions auxquelles elles répondent :

• C'est rapide ? TTFT, ITL, percentiles de latence par cas d'usage
• Ça scale ? Débit de tokens, profondeur de file, utilisation du contexte
• C'est correct ? Taux de complétion des tâches, patterns d'erreurs dans les sorties
• Ça tient la route niveau coût ? Coût par tâche, efficacité des tokens, cohérence du modèle
• Comment ça se comporte ? (Pour les agents) Complétion de tâches, nombre d'étapes, détection de boucles

Certaines de ces métriques, vous les aurez gratuitement depuis votre infrastructure. La plupart, non. Construire une instrumentation spécifique pour les workloads IA n'est pas une option — c'est la seule façon de voir ce qui se passe vraiment.

Les équipes qui s'en sortent ne utilisent pas de meilleurs dashboards. Elles posent de meilleures questions.