Journal d'incident d'une IA : trame de post-mortem

Une IA en production tombe en panne d'une façon particulière : une erreur de fournisseur, un modèle retiré, une base documentaire qui ne répond plus, ou une réponse fausse qui circule pendant des jours avant que quelqu'un ne la signale. Un journal d'incident garde la trace de ce qui s'est passé, de la cause retenue et des mesures prises. Il sert à deux choses : retrouver rapidement le mécanisme la prochaine fois, et prouver qu'une correction a été faite si un client ou un régulateur pose la question.

Ce guide propose une trame. Elle a été écrite pour ce site, sans modèle emprunté à un organisme : elle reprend la logique habituelle d'un post-mortem, adaptée à une IA. Les exemples de codes d'erreur et de dates viennent de la documentation d'Anthropic lue le 15/11/2026.

La trame

Chaque incident tient sur deux à quatre pages. Les sections suivantes sont à remplir dans cet ordre.

1. Résumé

Trois lignes : ce qui a cassé, pour qui, pendant combien de temps. Exemple : « Pendant 2 heures, les réponses de l'agent de support ont été remplacées par un message d'erreur pour 30 % des utilisateurs. » Les chiffres de ce résumé doivent venir des traces, pas de la mémoire de l'équipe.

2. Impact

Qui a été touché, combien de requêtes, quelles fonctions ne marchaient plus, et si des données ont été exposées ou mal traitées. Si des données personnelles sont concernées, c'est le point à faire valider sans délai par votre délégué à la protection des données.

3. Chronologie

Un tableau avec l'heure, l'événement et la source de l'information : une alerte, une trace, un message d'utilisateur, un courriel de l'éditeur. Gardez l'heure dans le fuseau d'origine et indiquez-le. La chronologie est la partie la plus utile du document : elle montre le moment où le problème a commencé, et pas seulement celui où il a été vu.

Pour une IA, trois identifiants méritent d'être notés dans la chronologie :

• le request-id de la réponse en erreur. Anthropic indique que chaque réponse de l'API le contient, et qu'il sert au support en cas de problème ;
• l'identifiant de la trace concernée dans votre outil d'observabilité ;
• le nom exact du modèle utilisé, avec sa date de version.

4. Cause

Une cause se décrit en une phrase, puis en détail. Distinguez la cause déclenchante (ce qui a commencé le problème) de la cause profonde (pourquoi le système n'a pas résisté). Exemples de causes déclenchantes fréquentes en IA : une limite de débit atteinte, qui renvoie une erreur 429 ; une surcharge de l'API, une erreur 529 ; une clé d'API expirée, une erreur 401 ; un modèle retiré à sa date. La page d'erreurs d'Anthropic distingue ces situations, et il faut les nommer exactement.

Une cause fréquente est l'absence de réaction au code d'erreur. Une application qui ne réessaie pas, ou qui réessaie sans délai, transforme un incident court en incident long.

5. Correction

Ce qui a été fait pour rétablir le service, dans l'ordre. Indiquez la personne, l'heure et l'effet observé. Une correction de contournement (basculer sur un autre modèle, couper une fonction) n'est pas une correction définitive : séparez-les.

6. Prévention

Trois à cinq actions, chacune avec un responsable et une échéance. Une bonne action est vérifiable : une alerte ajoutée sur un signal précis, un jeu de contrôle rejoué après chaque changement de modèle, un délai de réessai ajouté dans le code. Une action du type « être plus vigilant » ne se vérifie pas et doit être remplacée.

7. Leçons et points ouverts

Ce que l'équipe a appris, et ce qui reste inconnu. Un point ouvert doit avoir une date de réponse.

Les règles de rédaction

• Pas de chiffre sans source. Chaque durée, chaque volume et chaque taux renvoie à une trace, un journal ou une mesure. Un chiffre estimé est écrit comme tel.
• Pas de nom de coupable. Décrivez les décisions et le contexte qui les ont rendues possibles.
• Une seule version, datée. Le journal se corrige en ajoutant une mise à jour datée, pas en réécrivant l'original.
• Données personnelles exclues. Le journal ne doit pas reprendre le texte des conversations. Citez l'identifiant de la trace, et laissez les contenus dans l'outil, selon les règles de conservation de votre organisation.

Où ranger le journal

Un répertoire unique, accessible à l'équipe d'exploitation et aux responsables, avec un numéro et une date par incident. Ajoutez une ligne dans le registre des incidents, et reliez le journal aux alertes qui se sont déclenchées, pour retrouver le signal d'origine. Les alertes et leurs seuils sont décrits dans six signaux à surveiller.

Pour l'exploitation courante, le suivi des erreurs et des limites est détaillé dans tokens et erreurs d'API. Pour une dérive due à un changement de modèle, voir changement de modèle IA : dérive et jeu de contrôle.