Réponse aux incidents

Pourquoi ce chapitre est le plus utile

Les chapitres précédents partagent un principe commun : un système LLMLLMIAGrand modèle de langage (Large Language Model) entraîné sur d'énormes corpus pour prédire et générer du texte.Voir dans le glossaire finira par se tromper, et l'objectif n'est pas de l'en empêcher totalement mais de réduire la fréquence et la gravité de ses erreurs. Golden set, monitoring de production, red teamingRed teamingCybersécuritéExercice offensif structuré visant à identifier les failles d'un système IA (prompt injection, fuite de données, biais) avant mise en production.Voir dans le glossaire, tests de régression — tout cela repousse le moment où un incident survient. Rien ne le rend impossible.

Ce chapitre traite de ce qui se passe quand, malgré tout, l'incident arrive : un modèle qui invente une clause contractuelle, un agentagentIASystème qui enchaîne des appels d'outils de façon autonome pour atteindre un objectif : il planifie, agit, observe, recommence. Sa fiabilité décroît exponentiellement avec le nombre d'étapes.Voir dans le glossaire qui exécute une action non autorisée, une fuite du promptpromptIAConsigne ou contexte fourni à un modèle de langage pour orienter sa réponse. La qualité du prompt conditionne souvent la qualité du résultat.Voir dans le glossaire système dans une réponse publique, un pic de coût soudain, une dérivedériveIADégradation progressive des performances d'un modèle après son déploiement, causée par l'évolution des comportements ou du contexte. Elle impose surveillance et réentraînement.Voir dans le glossaire de ton qui devient virale. Sans playbook préparé à l'avance, la première réaction est presque toujours désorganisée — chacun improvise, personne ne sait qui décide, et le temps perdu à s'organiser aggrave la situation plus que l'incident lui-même.

Ce qui distingue un incident LLM d'un incident logiciel classique

Une partie de la discipline se transpose directement depuis le génie logiciel classique : détection, triage, confinement, communication, résolution, post-mortem. Mais plusieurs traits propres aux systèmes LLMgrand modèle de langageIAModèle entraîné à prédire le token suivant d'une séquence de texte. Toutes ses capacités apparentes — résumer, traduire, coder — découlent de cette unique tâche.Voir dans le glossaire changent la manière d'appliquer chaque étape.

• La cause n'est pas toujours un bug de code. Une régression peut venir d'un changement de comportement du modèle chez le fournisseur, d'une dérive du corpus d'un RAGRAGIATechnique consistant à rechercher les documents pertinents et à les fournir au modèle dans son contexte. Elle permet des réponses à jour et citables, ce que l'affinage ne permet pas.Voir dans le glossaire, ou d'un utilisateur ayant trouvé une formulation de contournement des garde-fous.
• L'impact peut être qualitatif avant d'être quantitatif. Le taux d'erreur technique reste souvent bas alors qu'un incident de réputation se propage déjà : une seule réponse choquante, capturée et partagée, peut faire plus de dégâts qu'une panne de plusieurs heures.
• Le volume de sortie rend l'ampleur difficile à évaluer immédiatement. Contrairement à une panne binaire, un LLM continue de répondre pendant l'incident — il faut échantillonner et analyser, pas seulement vérifier une disponibilité.
• Certains incidents sont invisibles côté infrastructure. Une hallucinationhallucinationIAProduction par un modèle d'un énoncé faux formulé avec la même assurance qu'un fait établi. Le phénomène est structurel : le modèle optimise la vraisemblance, pas la vérité.Voir dans le glossaire convaincante ou un biaisbiaisIARégularité correctement apprise dans des données qui ne représentent pas la réalité visée, ou qui enregistrent des décisions passées avec leurs préjugés. Changer d'algorithme ne le corrige pas.Voir dans le glossaire de traitement ne déclenche aucune alerte système classique (latence, taux d'erreur HTTP) : elle exige une détection sémantique dédiée.

Un incident LLM peut être en cours sans qu'aucun indicateur d'infrastructure ne l'indique. La supervision technique standard reste nécessaire mais ne suffit jamais seule à couvrir les incidents propres à la génération de texte.

Les six phases d'un playbook d'incident

1. Détection

La détection s'appuie sur deux canaux complémentaires, qui doivent alimenter le même point d'entrée :

• Signaux automatisés — seuils de dérive détectés par le pipeline de régression, taux d'escalade vers un humain anormalement élevé, pic de coût par requête, taux de blocage par les garde-fous en hausse soudaine, tentative de prompt injectionInjection de promptCybersécuritéAttaque visant à détourner un LLM en insérant des instructions malveillantes dans le contexte (entrée utilisateur, document RAG, etc.).Voir dans le glossaire réussie.
• Signalements humains — retours d'utilisateurs, remontées du support, capture d'écran partagée en interne ou publiquement, alerte d'un partenaire ou d'un régulateur.

Le signalement humain reste souvent la première source de détection sur les incidents qualitatifs les plus graves, précisément parce qu'ils ne franchissent aucun seuil technique préconfiguré. C'est une raison suffisante pour maintenir un canal de signalement simple et visible, côté utilisateurs comme côté équipes internes.

2. Triage et classification de sévérité

Chaque incident doit être classé rapidement selon une grille de sévérité partagée, avec un responsable désigné — souvent appelé incident commander — qui centralise les décisions le temps de la crise.

Un assistant de support annonce à plusieurs utilisateurs un remboursement automatique qui n'existe pas dans la politique de l'entreprise. Le volume reste faible (quelques dizaines de cas) mais l'engagement contractuel implicite crée un risque juridique direct. Ce cas se classe en SEV1 malgré un volume modeste : c'est la nature du préjudice, pas seulement son ampleur, qui détermine la sévérité.

Le triage doit rester rapide — quelques minutes, pas une réunion planifiée. Un gabarit de classification pré-rempli, avec des critères objectifs plutôt que des débats au cas par cas, accélère nettement cette étape.

3. Confinement

Le confinement vise à arrêter la propagation du dommage avant même de comprendre la cause exacte. Plusieurs mécanismes doivent être préparés et testés en amont — les découvrir en pleine crise coûte un temps précieux :

• Kill switch global — désactivation complète d'une fonctionnalité ou du système, remplacée par un mode dégradé. Solution la plus sûre, la plus coûteuse en expérience utilisateur.
• Rollback de version — retour à la version précédente du modèle, du prompt système ou du pipeline RAG, en s'appuyant sur le versionnement et le déploiement canari vus au chapitre régression.
• Restriction de périmètre — désactivation ciblée de la seule fonctionnalité identifiée comme source du problème.
• Renforcementapprentissage par renforcementIAMéthode où un agent agit dans un environnement et reçoit une récompense ou une pénalité. Par essais répétés, il découvre la stratégie qui maximise la récompense cumulée.Voir dans le glossaire temporaire des garde-fous — durcissement d'un filtre de sortie le temps d'une correction de fond, quitte à générer davantage de faux refus.
• Limitation de débit (throttling) — utile face à un incident de coût ou d'abus, sans couper l'accès pour tous les utilisateurs légitimes.

Un mécanisme de retour arrière jamais exercé en dehors d'un incident réel échoue plus souvent qu'on ne l'imagine : configuration oubliée, dépendance non prise en compte, script périmé. Le rollback doit être testé périodiquement, exactement comme un exercice d'incendie, pas seulement documenté.

Sur un SEV1, la règle générale est d'agir avant d'avoir la certitude complète sur la cause : le coût d'un confinement excessif est presque toujours inférieur au coût de laisser un préjudice se poursuivre pendant l'investigation.

4. Communication

La communication se scinde en deux flux distincts, avec des rythmes et des contenus différents.

Communication interne. Un statut d'incident centralisé et mis à jour régulièrement (toutes les 30 minutes sur un SEV1) évite que chaque équipe interroge séparément l'incident commander. Il indique la sévérité, les actions de confinement déjà appliquées, l'hypothèse de cause en cours de vérification, et la prochaine mise à jour prévue.

Communication externe. Elle s'adresse aux utilisateurs affectés, parfois à un régulateur (santé, finance, donnéesdonnéesIAEnsemble d'informations structurées ou non utilisées pour entraîner, évaluer ou alimenter un modèle. La qualité, la quantité et la représentativité des données sont les facteurs décisifs pour les performances en apprentissage automatique.Voir dans le glossaire personnelles), éventuellement au public. Trois principes la structurent :

1. Reconnaître sans minimiser ni sur-dramatiser — un ton défensif ou évasif dégrade la confiance davantage que l'incident lui-même.
2. Décrire ce qui est fait, pas seulement ce qui s'est passé — les utilisateurs veulent savoir que la situation est prise en main.
3. Ne jamais communiquer une cause non confirmée — une explication provisoire présentée comme définitive et ensuite contredite abîme la crédibilité plus durablement que l'absence temporaire d'explication.

Rédiger un message de crise pendant la crise ajoute une charge cognitive inutile au moment où l'attentionattentionIAMécanisme par lequel un modèle pondère l'importance de chaque token du contexte lorsqu'il en traite un autre, quelle que soit la distance qui les sépare.Voir dans le glossaire doit se porter sur la résolution. Des gabarits pré-validés par le juridique et la communication, pour chaque niveau de sévérité, permettent de publier un premier message en quelques minutes plutôt qu'en heures.

5. Résolution

La résolution ne se limite pas à corriger la cause immédiate : elle inclut une vérification explicite que le système est revenu à un état acceptable, avec les mêmes outilstool callingIACapacité d'un agent ou d'un LLM à invoquer des outils externes (API, calcul, recherche) pendant le raisonnement.Voir dans le glossaire que ceux des chapitres précédents — ré-exécution du golden set, fenêtre de monitoring post-correction, confirmation que les indicateurs déclencheurs sont repassés sous leur seuil normal.

Une résolution prématurée, annoncée avant cette vérification, est une cause fréquente de réouverture d'incident : le correctif semble fonctionner sur quelques cas testés manuellement mais ne couvre pas l'ensemble du périmètre affecté.

6. Post-mortem sans recherche de coupable

Le post-mortem se conduit quelques jours après la résolution, pendant que les détails sont encore frais, et répond à des questions précises :

• Quelle est la chronologie factuelle complète, de la première anomalie détectable à la résolution confirmée ?
• Quelle est la cause racine — pas seulement le déclencheur immédiat, mais la raison structurelle qui a permis l'incident ?
• Quels signaux auraient permis une détection plus précoce, et pourquoi n'ont-ils pas été captés ?
• Quelles actions correctives concrètes sont ajoutées, avec un propriétaire et une échéance ?

Le principe « sans recherche de coupable » ne signifie pas l'absence de responsabilité, mais le refus de traiter l'incident comme la faute d'un individu isolé. Une personne ayant déployé un changement validé par l'organisation a suivi un processus ; c'est ce processus, pas la personne, qu'il faut corriger.

Un post-mortem dont les actions correctives ne sont jamais suivies d'effet perd rapidement sa légitimité : les équipes cessent de les rédiger sérieusement si les mêmes causes racines reviennent sans jamais être traitées.

Rollback : les mécanismes à préparer en amont

Le rollback mérite une attention particulière : c'est souvent le geste le plus rapide pour arrêter un incident, à condition d'avoir été conçu pour cela dès l'architecture du système.

• Versionnement explicite de chaque composant modifiable indépendamment — prompt système, paramètres, version de modèle, index et corpus du RAG — pour revenir précisément à un état antérieur connu.
• Découplage du déploiement de code et de la configuration du comportement du modèle. Si changer un prompt système nécessite un déploiement applicatif complet, le rollback devient lent au moment où la rapidité compte le plus.
• Bascule accessible sans dépendance à la chaîne de déploiement potentiellement affectée par l'incident.
• Vérification post-rollback automatisée, réutilisant le golden set pour confirmer que le retour arrière a effectivement supprimé le comportement problématique.

Le déploiement canari, détaillé au chapitre sur les tests de régression, joue ici un rôle préventif direct : en limitant l'exposition initiale d'un changement à une fraction du trafic, il réduit mécaniquement l'ampleur de tout incident causé par ce changement, avant même qu'un rollback ne soit nécessaire.

Pièges fréquents

• Absence de responsable désigné — sans incident commander identifié, plusieurs personnes prennent des décisions contradictoires ou, à l'inverse, chacun attend qu'un autre décide.
• Rollback jamais testé en dehors d'un incident réel — le mécanisme échoue précisément au moment où il est le plus nécessaire.
• Communication externe retardée par excès de prudence juridique — un silence prolongé pendant qu'un texte est validé en interne est souvent interprété plus négativement que l'incident lui-même.
• Confusion entre confinement et résolution — désactiver une fonctionnalité arrête le préjudice mais ne corrige rien ; annoncer une résolution sur cette seule base expose à une réouverture rapide.
• Post-mortem sans échéance ni propriétaire — des actions correctives listées mais jamais assignées ne sont, dans les faits, jamais réalisées.
• Golden set jamais enrichi du cas de l'incident — le cas doit systématiquement rejoindre le golden set pour qu'une régression future sur ce point précis soit détectée automatiquement avant la mise en production.

Checklist opérationnelle

• Une grille de sévérité (SEV1 à SEV4) est définie, documentée et connue de toutes les équipes concernées.
• Un canal d'alerte unique centralise les signaux automatisés et les signalements humains.
• Un rôle d'incident commander est défini pour chaque garde et testé lors d'exercices réguliers.
• Les mécanismes de confinement (kill switch, rollback, restriction de périmètre, throttling) sont documentés et testés hors incident.
• Des gabarits de communication interne et externe sont pré-rédigés pour chaque niveau de sévérité.
• La résolution est confirmée par une vérification explicite (golden set, fenêtre de monitoring) avant toute annonce de retour à la normale.
• Chaque incident donne lieu à un post-mortem sans recherche de coupable, avec causes racines et actions correctives assignées.
• Le cas ayant déclenché l'incident est ajouté au golden set et au monitoring de régression.

Un playbook d'incident bien préparé ne réduit pas le nombre d'incidents à zéro : il réduit le temps entre la première anomalie et le retour à un état maîtrisé, et transforme chaque incident en amélioration mesurable du système plutôt qu'en crise répétée dans les mêmes termes.