Pourquoi les incidents d'IA sont différents
Un incident d'IA ressemble rarement à une panne informatique classique. Les modes de défaillance les plus coûteux sont silencieux : un modèle qui dérive et se met à discriminer, un assistant qui hallucine des informations face aux clients, un système de scoring qui exclut systématiquement un groupe. Sans surveillance dédiée, ces défaillances peuvent opérer pendant des mois avant d'être détectées, en accumulant un préjudice juridique, financier et réputationnel.
Ce qui constitue un incident d'IA
Mieux vaut une définition large dans la politique interne : résultats erronés ou préjudiciables affectant des personnes, comportement discriminatoire, fuite de données via les prompts ou les sorties du modèle, usage non autorisé d'outils d'IA (l'IA fantôme), défaillance d'un fournisseur d'IA tiers et dégradation significative des performances du modèle par rapport à ce qui a été validé.
Phase 1 : préparation
La réponse commence avant l'incident : un inventaire à jour des systèmes d'IA avec des responsables nommés, des seuils clairs définissant ce qui constitue un incident et sa gravité, un runbook par système critique (comment le désactiver, vers quel processus manuel basculer) et une journalisation activée. ISO/IEC 42001 comme le cadre NIST AI RMF (fonction Manage) exigent des processus documentés de gestion des incidents.
Phase 2 : détection
Combinez la surveillance technique (métriques de qualité et de dérive du modèle, alertes), les canaux humains (des voies simples pour que salariés et clients signalent des résultats anormaux) et la revue périodique des journaux. Beaucoup d'incidents d'IA sont d'abord repérés par un utilisateur, pas par un système.
Phase 3 : confinement et réponse
Les décisions clés doivent être prédéfinies : quand désactiver le système ou repasser en supervision humaine totale, qui a l'autorité pour le faire et quel est le processus de repli pendant ce temps. Préservez les preuves (entrées, sorties, versions du modèle, journaux) : elles seront nécessaires pour l'analyse des causes et face à toute autorité.
Phase 4 : notification
Définissez l'escalade interne (direction, juridique, communication) et les obligations externes. Pour les fournisseurs de systèmes à haut risque, l'article 73 de la Loi IA de l'UE fixe des délais stricts une fois les obligations à haut risque applicables : notification à l'autorité de surveillance en règle générale dans les 15 jours suivant la connaissance de l'incident grave, 10 jours en cas de décès et 2 jours en cas d'infraction généralisée ou de perturbation grave et irréversible d'infrastructures critiques. Un rapport initial incomplet est admis, à compléter ensuite. Si des données personnelles sont impliquées, les délais de notification des règles de protection des données applicables peuvent s'ajouter.
Phase 5 : rétablissement et revue
Après le rétablissement du service, menez une revue post-incident sans recherche de coupable : cause racine (données, modèle, intégration, supervision), correction et réentraînement si nécessaire, mise à jour des contrôles et de la cartographie des risques, et partage des enseignements. Chaque incident doit laisser le dispositif de gouvernance plus solide.
Par où commencer cette semaine
Trois actions à fort impact : (1) nommez un responsable des incidents d'IA et un suppléant ; (2) créez une matrice de déclenchement d'une page indiquant quels événements activent le processus et qui est alerté ; (3) organisez une simulation de 60 minutes avec les équipes technique, juridique et communication. Une exécution simple sous pression vaut mieux qu'un document de politique supplémentaire.
Sources
Article 73, Loi IA de l'UE — Commission européenne (AI Act Service Desk) · Règlement (UE) 2024/1689 (EUR-Lex) · NIST AI Risk Management Framework · ISO/IEC 42001:2023. Informations générales, et non un conseil juridique ; vérifiez toujours auprès des sources officielles.