Ce que coûte un incident sur un système d'IA

Un incident sur un système d’IA est, le plus souvent, une période pendant laquelle le système a produit des réponses dégradées sans jamais renvoyer d’erreur, sur une durée et un nombre de dossiers que personne ne connaît. C’est une dérive silencieuse, pas une coupure.

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 modèle a changé de version, un document de référence a été remplacé, un prompt a été retouché, et les réponses se sont mises à dériver. 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 ».

Les causes les plus courantes sont connues : une mise à jour du modèle côté fournisseur, un corpus qui n’a pas suivi l’évolution des procédures, une modification de prompt sans rejeu des tests, ou un changement dans la façon dont les documents sont découpés et retrouvés. Aucune ne déclenche d’alerte technique.

« 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, parce qu’une panne se date alors qu’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. Les utilisateurs reçoivent des réponses bien formées, au ton assuré, et rien ne signale qu’elles s’appuient sur une version ancienne d’une procédure.

La journalisation décide du coût d’un incident d’IA parce que la date de bascule, le périmètre, ce qui a été transmis et la version en cause ne se reconstituent pas après coup : ils se lisent dans un journal, ou ils n’existent pas. Sans journal, la reconstitution devient une enquête humaine.

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.

La journalisation est souvent écartée au cadrage pour deux raisons : elle ne produit aucune fonctionnalité visible, et elle soulève des questions de protection des données. La seconde est légitime et se traite par une durée de conservation décidée explicitement, pas par l’absence de journal.

Cinq champs rendent un incident d’IA analysable : la question posée, les extraits fournis au modèle, la réponse produite, la décision humaine et l’horodatage. 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. C’est le mécanisme décrit dans reprendre un système d’IA construit par quelqu’un d’autre.

À ces cinq champs s’ajoute l’identifiant de version de chaque composant : modèle, prompt, index documentaire. C’est lui qui permet d’aligner la date de bascule sur un changement précis.

Le coût d’un incident sur un système d’IA se compose de quatre postes : la reconstitution, la correction, la reprise des dossiers touchés et la perte d’usage, et la correction technique est généralement le plus léger. C’est l’inverse d’une panne classique, où l’essentiel du coût tient à l’indisponibilité.

• La reconstitution : établir la fenêtre et le périmètre. Avec un journal, quelques heures ; sans journal, des semaines d’entretiens.
• La correction : modifier le prompt, le corpus ou la version du modèle, puis vérifier que rien d’autre n’a régressé.
• La reprise des dossiers : revoir les réponses parties à l’extérieur, informer les personnes concernées, rectifier ce qui doit l’être.
• La perte d’usage : les utilisateurs qui ont cessé de se servir du système et qu’il faut reconquérir.

Ces postes ne figurent dans aucun budget initial, ce qui explique qu’ils surprennent. Ils complètent la lecture du coût réel d’un système d’IA en production.

La confiance perdue après un incident d’IA se reconquiert beaucoup plus lentement qu’elle ne s’est installée, et aucun correctif technique n’y suffit : la parade se construit avant l’incident. C’est le poste le plus lourd.

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.

Pendant un incident sur un système d’IA, il faut d’abord restreindre ou couper le système selon une procédure écrite à l’avance, puis dater la bascule, délimiter le périmètre et seulement ensuite corriger. Décider de la procédure pendant l’incident garantit qu’on la décidera mal.

La procédure d’arrêt écrite précise qui peut couper le système, comment, et ce qu’on dit aux utilisateurs. Elle s’applique ensuite en six étapes :

1. Restreindre ou suspendre le système, ou repasser en validation humaine systématique.
2. Dater la bascule en rejouant le jeu de tests sur les versions successives conservées.
3. Extraire du journal les dossiers traités pendant la fenêtre.
4. Séparer ce qui a été relu et corrigé de ce qui est parti tel quel à l’extérieur.
5. Corriger la cause, puis rejouer l’ensemble du jeu de tests avant remise en service.
6. Ajouter les cas fautifs au jeu de tests, pour que la même dérive soit détectée la prochaine fois.

Le cas le plus fréquent, un modèle mis à jour par le fournisseur sans annonce visible, est traité dans le jour où le modèle a changé sans prévenir.

Trois dispositifs posés dès la mise en service réduisent le coût d’un incident d’IA : la journalisation des cinq champs, l’affichage de la source datée et un jeu de tests rejouable au moins chaque semaine. Ils demandent une journée de travail et aucun 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 rejoué automatiquement, avec conservation des résultats : c’est ce qui borne la fenêtre d’un incident à quelques jours au lieu de plusieurs mois. Sa constitution est décrite dans construire un jeu de tests en une journée, et son rôle dans l’évaluation continue, le chaînon manquant.

Ce troisième dispositif 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. Le rejeu sur l’état antérieur est le point qu’on oublie ; il relève du dispositif décrit dans ce qui occupe l’équipe la deuxième année.

Ces dispositifs servent autant au diagnostic quotidien qu’au contrôle réglementaire. Leur constitution commune est décrite dans ce qui doit exister avant l’échéance. Sur un système déjà en service, un audit IA vérifie s’ils existent et s’ils permettraient de répondre à la question « depuis quand ».