Signaler une défaillance de l’IA pour qu’un tiers la reproduise

« L'IA s'est trompée » n'est pas un rapport d'incident exploitable. Il ne permet pas à un tiers de reproduire la tâche, de comparer le résultat à la norme attendue ou de décider s'il faut suspendre le workflow. Le temps de demander des détails, l'auteur du signalement aura peut-être déjà modifié le prompt, lancé une nouvelle session ou perdu le résultat exact.

Un rapport utile n'exige pas un long formulaire. Il suffit d'un petit dossier de preuves sécurisées, saisies dès l'apparition du problème. Le but n'est pas de prouver qu'une IA a toujours tort, mais de rendre un échec observable assez reproductible pour qu'un collègue puisse l'examiner, le contenir et en tirer des leçons.

Documentez l'échec avant de corriger le prompt

Partez du travail, pas du modèle. Notez ce que la personne cherchait à produire ou décider, la norme à respecter et ce qui a échoué. Ne conservez que le minimum de preuves. Remplacez les données personnelles, confidentielles ou sensibles par des exemples anonymisés ou synthétiques avant de partager le dossier.

Le guide Measure de l'AI RMF du NIST lie documentation et répétabilité, et préconise de tester les quasi-incidents, l'auditabilité et les mécanismes de signalement. Son guide Manage traite aussi les comportements inattendus, quasi-incidents et échecs comme des signaux à suivre et documenter. Le UK AI Risk Management Toolkit fait le même lien entre signalement, suivi, réponse aux incidents et formation. Ces pratiques convergent vers une règle simple : rendre l'observation reproductible avant que la preuve ne disparaisse.

Exemple : une condition d'annulation manquante

Une équipe support demande à une IA de résumer une politique de remboursement. La réponse est claire, mais omet une condition d'annulation sous 14 jours qui change tout. Le rapport initial indique : « Mauvais résumé, l'IA a raté la règle ». On ne peut savoir si le problème vient de la source, du prompt, de la politique ou de la validation.

Un dossier reproductible documente la tâche, la version et la section de la politique, la forme anonymisée de la question client, le point de checklist attendu et l'omission exacte. Il note aussi que la réponse n'a pas été envoyée et que l'envoi automatique est suspendu le temps de vérifier d'autres cas. Un analyste peut alors rejouer la tâche avec des données sûres, voir si l'omission se répète et choisir une réponse proportionnée.

Reproduire une fois, puis router selon l'impact

Une seule reproduction contrôlée peut suffire à valider le dossier. N'exposez pas de données sensibles à répétition et ne transformez pas un workflow de production en expérience. Si l'échec affecte des personnes, des fonds, des accès, des droits, la sécurité ou une décision réglementée, stoppez l'usage concerné et suivez la procédure d'incident de l'entreprise. Un dossier reproductible appuie ce processus, il ne le remplace pas.

Faire d'un rapport un savoir partagé

Le dossier est surtout utile lorsqu’il fait évoluer le système de travail. Une omission récurrente peut justifier un nouveau test de validation. Un cas limite peut rejoindre une bibliothèque d’exceptions. Un incident important peut exiger une chronologie vérifiée et une simulation de la décision humaine défaillante. Reliez la preuve à une action au lieu de classer le signalement comme une plainte isolée.

Nos guides Bokili expliquent comment rejouer une décision après un incident d’IA, transformer des notes d’incident en chronologie vérifiée et bâtir une bibliothèque de cas limites.

Un rapport d'échec doit faciliter la prochaine action corrective. Cinq champs suffisent pour passer de la frustration aux faits : reproduire l'incident, isoler l'essentiel, et intégrer la leçon aux formations, vérifications et processus.