Chapitre 11 — Observabilité, journalisation et réponse aux incidents
Onzième billet de la tournée chapitre par chapitre de LLM Primer VII : Sécurité de l'IA. Le chapitre qui traite la journalisation, l'alerting et la réponse aux incidents comme la couche qui transforme les défenses architecturales en un système que les opérateurs peuvent vraiment exploiter.
Pourquoi ce chapitre existe
Un système à la structure correcte mais sans visibilité échoue invisiblement. Le chapitre 11 parcourt la couche d'observabilité pour les systèmes LLM — quoi journaliser, comment détecter abus et anomalie, comment alerter sans produire du bruit, comment exécuter un playbook de réponse aux incidents quand quelque chose tourne mal, et comment tirer des leçons de ce qui s'est passé. Les disciplines générales se transposent de l'ingénierie opérationnelle ailleurs, avec des extensions spécifiques aux LLM : les sorties probabilistes signifient que la reproduction des incidents exige de capturer plus d'état que dans les systèmes déterministes ; les conventions sémantiques OpenTelemetry GenAI, développées depuis 2024, donnent le vocabulaire neutre vis-à-vis des fournisseurs pour cet état.
11.1 Ce qu'il faut journaliser est une décision politique, non un défaut
Journaliser trop peu laisse l'équipe incapable d'enquêter. Journaliser trop crée des problèmes de conformité, de coût et de vie privée qui finissent par forcer une réduction. La position défendable est le minimum qui soutient les cas d'usage opérationnels que l'équipe a identifiés, sous une forme structurée qui les soutient chacun. Les finalités incluent typiquement l'alerting en temps réel sur abus ou anomalie, l'investigation après coup d'incidents, la planification de capacité et l'analyse de coût, le reporting de conformité, et l'évaluation continue du comportement du modèle. Chaque finalité a des exigences différentes sur le schéma ; un journal conçu pour l'une est inadéquat pour les autres. Les conventions sémantiques OpenTelemetry GenAI définissent des spans et attributs pour l'appel LLM — nom du modèle, fournisseur, paramètres de requête, contenu du prompt, contenu de la réponse, comptes de tokens, latence, coût — qui laissent l'outillage aval analyser la même télémétrie quel que soit le SDK spécifique. Langfuse, Helicone, Arize Phoenix et Datadog LLM Observability consomment tous cette forme. Une entrée de journal de production inclut typiquement l'identifiant de requête, le principal authentifié, le locataire, la version et le fournisseur du modèle, le prompt assemblé complet (avec contexte récupéré et sa provenance), les appels d'outils et leurs sorties, le contenu de la réponse, les scores du classificateur de sécurité en entrée et sortie, et la comptabilité de latence et de tokens. Stocker cela de manière responsable signifie être explicite sur les fenêtres de rétention, le traitement des données personnelles et les contrôles d'accès sur le magasin de journaux lui-même.
11.2 La détection compose signaux signature, statistiques et comportementaux
Une fois la télémétrie structurée, la question suivante est quels schémas indiquent que quelque chose va mal. La correspondance de signatures est la première ligne la moins chère — phrases d'injection de prompt connues, préambules de type DAN, charges encodées en base64, montages de jeu de rôle déjà observés. La liste est construite à partir de la recherche publique, du travail interne de red team et des incidents passés. Les signatures attrapent les variantes connues ; les adversaires s'adaptent une fois qu'ils apprennent quelles phrases sont marquées. La détection d'anomalie statistique surveille l'écart par rapport à la base : distributions de tokens inhabituelles, ratios latence-vers-longueur atypiques, pics soudains de taux de refus ou de taux d'invocations d'outils spécifiques. Les bases dérivent lentement sous conditions normales et changent brusquement sous conditions anormales. La détection de schémas comportementaux correspond aux profils d'abus même quand les requêtes individuelles ne sont pas ouvertement malveillantes — un principal unique émettant des milliers de variantes paraphrasées de la même requête restreinte, un pic de requêtes qui combinent contenu légitime et suffixe spécifique, une lente dérive dans les distributions de réponse par utilisateur. La détection n'est utile que si elle mène à des alertes auxquelles les opérateurs répondent effectivement. La taxonomie distingue typiquement critique (abus actif à l'échelle, réveiller un ingénieur d'astreinte), élevé (schéma notable avec dommage borné, notification en heures ouvrées), et moyen/faible (tableaux de bord et revue hebdomadaire). La fatigue d'alerte est le mode d'échec ; la discipline stricte de sévérité est ce qui la prévient.
11.3 La réponse aux incidents est un playbook, non de l'improvisation
NIST SP 800-61 révision 2 donne le cadre — préparation, détection et analyse, confinement, éradication, récupération, activité post-incident — que le playbook spécifique aux LLM étend. La préparation signifie que les runbooks, les rotations d'astreinte et l'accès à l'outillage pertinent existent avant l'incident. La détection et l'analyse est là où l'observabilité de la section 11.1 paie. Le confinement pour un incident LLM peut signifier basculer un feature flag pour désactiver un outil, dégrader vers une version de modèle plus conservatrice, resserrer les limites de débit sur un principal ou locataire spécifique, ou rerouter le trafic vers une pile alternative. L'éradication dépend du type d'incident : un jailbreak peut nécessiter une règle de filtre ajoutée, un document RAG compromis peut nécessiter d'être retiré de l'index, un identifiant divulgué peut nécessiter une rotation. La récupération est quand le système revient à la normale, avec le confinement inversé et l'éradication vérifiée. L'activité post-incident est là où le travail spécifique au modèle se concentre : reproduire le comportement si possible, caractériser la frontière de la défaillance, décider si l'incident reflète quelque chose sur le modèle qui devrait changer la façon dont il est utilisé, et alimenter le résultat dans la suite d'évaluation pour que les régressions futures soient attrapées avant déploiement. La reproduction n'est pas toujours possible sous échantillonnage à température non nulle, mais l'objectif est de définir quand le comportement indésirable se produit.
Ce que prépare le Chapitre 11
Le chapitre 12 clôt la partie IV avec la couche identité et accès — qui est autorisé à interagir avec le système, à quelles conditions, et comment l'application est structurée à travers les composants. Les disciplines traditionnelles s'appliquent : authentification avec clés API, OAuth et mTLS ; autorisation avec RBAC et ABAC ; isolation multi-locataire ; limites de débit et quotas ; surcouches de gouvernance d'entreprise. Les extensions spécifiques aux LLM concernent le modèle comme principal — un agent agissant au nom d'un utilisateur a sa propre identité et ses propres permissions —, le rôle des jetons de capacité pour l'invocation d'outils, et la configuration par locataire du comportement du modèle que les plateformes LLM multi-locataires doivent supporter. Le chapitre 13 ouvre ensuite la partie V avec le paysage réglementaire, où les contrôles techniques que ce livre a développés doivent être cartographiés sur l'AI Act, le RGPD, les lois d'États américains et les cadres qui les entourent.
Prochaine étape — Chapitre 12 : Contrôle d'accès et identité. Authentification, RBAC contre ABAC, isolation multi-locataire, limites de débit et la surcouche de gouvernance d'entreprise qui rend les systèmes LLM utilisables dans les environnements réglementés.
