Ce que coûte un incident sur un système d'IA
ExploitationRisqueObservabilitéProduction2025-10-148 min
Un incident classique se répare. Un incident d'IA se répare aussi, mais il laisse une question : depuis quand, et sur combien de dossiers ?
Ce qui distingue un incident d'IA
Sur un service classique, l'incident a un début, une fin, et un périmètre connu : le service était indisponible de telle heure à telle heure.
Sur un système d'IA, l'incident typique est différent : le système a produit des réponses dégradées pendant une durée inconnue, sur un nombre de dossiers inconnu, sans jamais renvoyer d'erreur. La question qui coûte cher n'est pas « comment on répare », c'est « depuis quand, et qu'est-ce qui est parti dehors ».
Ce qu'il faut pouvoir reconstituer
- La date de bascule : à partir de quand le comportement a changé. Sans rejeu périodique du jeu de tests, elle est indéterminable.
- Le périmètre : quels dossiers ont été traités pendant la fenêtre, et par qui.
- Ce qui a été transmis à l'extérieur : une réponse relue et corrigée n'a pas le même statut qu'une réponse envoyée telle quelle.
- La version exacte du modèle, du prompt et du corpus au moment des faits.
Pourquoi la journalisation change tout ici
Ces quatre éléments ne se reconstituent pas après coup. Ils se lisent dans un journal, ou ils n'existent pas.
J'ai vu une organisation passer trois semaines à interroger manuellement ses équipes pour établir le périmètre d'un incident, faute d'avoir enregistré quelles réponses avaient été validées et lesquelles avaient été corrigées. Le coût de ces trois semaines a dépassé de loin celui de la journalisation qu'on avait jugée superflue au cadrage.
Le coût qui ne se chiffre pas
Après un incident visible, le taux d'usage baisse et ne remonte pas de lui-même. Les utilisateurs reviennent à la méthode manuelle, qu'ils n'avaient jamais complètement abandonnée. Reconquérir cet usage demande davantage d'efforts que la mise en service initiale.
Ce que je mets en place systématiquement
Un rejeu automatique du jeu de tests, au moins hebdomadaire, avec conservation des résultats. C'est ce qui borne la fenêtre d'un incident à quelques jours au lieu de plusieurs mois.
Et une procédure d'arrêt écrite : qui peut couper le système, comment, et ce qu'on dit aux utilisateurs. Décider cela pendant l'incident garantit qu'on le décidera mal.
Les cinq champs qui rendent un incident analysable
La question posée, les extraits fournis au modèle, la réponse produite, la décision humaine et l'horodatage. Cinq champs, et leur absence transforme chaque incident en enquête sans conclusion.
Le champ décisif est le deuxième. Devant une réponse fausse, la seule question utile est : l'information correcte figurait-elle dans ce qui a été fourni ? Si oui, le problème est dans le prompt ou le modèle. Si non, il est dans la recherche ou le corpus. Deux corrections opposées.
Sans cette trace, l'équipe modifie le prompt par défaut, ce qui installe le cycle où l'on corrige un cas en en cassant deux autres, le mécanisme décrit dans reprendre un système d'IA construit par quelqu'un d'autre.
La question à laquelle il faut pouvoir répondre
« Depuis quand, et sur combien de dossiers » : c'est ce qui distingue un incident d'IA d'une panne ordinaire, et c'est ce qui coûte cher. Une panne se date ; une dégradation ne se date pas sans journal.
Un service qui tombe est visible immédiatement. Un système qui s'est mis à répondre sur des documents périmés fonctionne normalement de l'extérieur, et la dérive peut durer des mois.
La reconstitution suppose deux choses : des journaux conservés assez longtemps, et un moyen de rejouer les mêmes questions sur l'état antérieur. Le second point est celui qu'on oublie, et il relève du dispositif décrit dans ce qui occupe l'équipe la deuxième année.
Le coût qui ne se chiffre pas
La confiance perdue se reconquiert beaucoup plus lentement qu'elle ne s'est installée, et aucun correctif technique n'y suffit. C'est le poste le plus lourd d'un incident.
Un utilisateur qui a reçu une réponse fausse sur un sujet qu'il maîtrisait doute ensuite de toutes les réponses, y compris justes. Il vérifie systématiquement, ce qui annule le bénéfice du système, puis cesse de s'en servir.
La parade est en amont : afficher la source et la date de chaque réponse, de sorte que l'utilisateur puisse vérifier lui-même plutôt que d'accorder ou retirer sa confiance en bloc. C'est le principal facteur d'adoption durable, comme détaillé dans mesurer l'adoption, pas la satisfaction.
Questions fréquentes
- Qu'est-ce qui distingue un incident d'IA d'une panne ?
Une panne est visible immédiatement ; une dégradation fonctionne normalement de l'extérieur et peut durer des mois. La question qui coûte cher est « depuis quand, et sur combien de dossiers ».
- Que faut-il journaliser pour pouvoir analyser ?
Cinq champs : la question, les extraits fournis au modèle, la réponse, la décision humaine et l'horodatage. Le deuxième est décisif car il sépare deux causes appelant des corrections opposées.
- Comment limiter la perte de confiance ?
En affichant la source et la date de chaque réponse, pour que l'utilisateur vérifie lui-même plutôt que d'accorder ou retirer sa confiance en bloc après une seule erreur.
- Combien de temps conserver les journaux ?
Assez longtemps pour couvrir la durée possible d'une dérive silencieuse, soit plusieurs mois. La durée doit être décidée explicitement, en tenant compte de la protection des données.
Ce que je mets en place dès la mise en service
Trois dispositifs, une journée de travail, et ils servent autant au diagnostic quotidien qu'au contrôle réglementaire. Aucun ne demande d'outillage particulier.
Le premier est la journalisation des cinq champs, avec une durée de conservation décidée explicitement. Le deuxième est l'affichage systématique de la source et de sa date dans chaque réponse, ce qui permet à l'utilisateur de détecter lui-même une donnée périmée. Le troisième est un jeu de tests rejouable à la demande, qui permet de comparer l'état actuel à l'état attendu.
Ce troisième dispositif est celui qui transforme une enquête en vérification : devant un doute sur une dégradation, on relance le jeu et on obtient une réponse en dix minutes plutôt qu'en trois jours.
Leur constitution commune est décrite dans ce qui doit exister avant l'échéance, et ils couvrent simultanément l'exploitation et la conformité.