Les incidents d’IA deviennent des crises opérationnelles. Nous devons les traiter en conséquence.

Pendant les dernières années, la plupart des organisations ont parlé des risques liés à l’IA dans le langage de la gouvernance.

Est-ce que le modèle est précis ? Est-ce qu’il est équitable ? Est-ce que les données sont approuvées ? Est-ce que nous respectons la réglementation émergente ? Ce sont des questions importantes, mais elles ne sont pas les seules. La question la plus urgente est ce qui se passe lorsque quelque chose va mal ?

Que se passe-t-il lorsque un agent d’IA prend une action qu’il n’aurait jamais dû prendre ? Que se passe-t-il lorsque un modèle divulgue des données sensibles ? Que se passe-t-il lorsque une réponse hallucinée crée une exposition juridique, ou lorsque une décision automatisée affecte un client, un employé, un patient ou un partenaire de manière qui ne peut pas être facilement annulée ?

Et peut-être plus pratiquement : où l’organisation va-t-elle pour coordonner la réponse ? C’est le changement en cours. Le risque lié à l’IA devient une question de résilience opérationnelle, et non plus seulement de gouvernance.

L’IA passe de l’expérimentation à la machinerie de travail de l’entreprise. Elle est intégrée dans le support client, le développement de logiciels, les opérations financières, les flux de travail de soins de santé, l’embauche, le traitement des réclamations, les chaînes d’approvisionnement et l’automatisation interne. À mesure que l’IA devient plus connectée à l’entreprise, les défaillances de l’IA deviennent des incidents d’entreprise.

Le moniteur d’incidents d’IA de l’OCDE a suivi 596 incidents d’IA en janvier 2026 seul, soit une croissance de 200 % d’une année sur l’autre. Des efforts comme le moniteur d’incidents d’IA de l’OCDE et la base de données d’incidents d’IA documentent les résultats négatifs ou nuisibles impliquant des systèmes d’IA afin que l’industrie puisse apprendre de l’expérience de la même manière que l’aviation et la cybersécurité l’ont fait pendant des années.

Cette comparaison est importante. Les industries matures demandent comment prévenir les défaillances ET comment réagir lorsque les défaillances se produisent quand même.

Les incidents d’IA ne se comportent pas comme des bogues de logiciels traditionnels

Un bogue de logiciel traditionnel a généralement une limite relativement claire. Quelque chose se brise, les ingénieurs enquêtent et l’équipe reproduit le problème, patche le code et expédie une correction.

Cependant, les incidents d’IA sont plus compliqués. Ils peuvent être probabilistes, intermittents et émerger de l’interaction entre un modèle, une invite, un système de récupération, un plug-in, un agent, un utilisateur et un processus commercial en aval. Parfois, le système d’IA fonctionne exactement comme conçu, mais la conception est incomplète pour l’environnement dans lequel il est utilisé. Cela rend la réponse plus difficile.

Une hallucination dans un chatbot de consommation est un type de problème. Une hallucination à l’intérieur d’un flux de travail juridique, financier, clinique ou RH est un autre. Un résultat biaisé lors des tests est grave. Un processus de décision biaisé fonctionnant à grande échelle en production est tout à fait différent. Un assistant d’IA qui rédige un e-mail est une chose, mais un agent qui peut modifier les autorisations, émettre des remboursements, mettre à jour les enregistrements, déclencher des flux de travail ou exécuter du code est une catégorie de risque très différente.

Le référentiel de risques d’IA du MIT capture une large gamme de risques d’IA, notamment de fausses ou trompeuses informations, des défaillances de confidentialité et de sécurité, de la discrimination, des abus et des problèmes de sécurité des systèmes. Le top 10 d’OWASP pour les applications de modèles de langage à grande échelle met également en évidence des risques tels que l’injection d’invite, la divulgation d’informations sensibles, la gestion de sortie non sécurisée et l’excès d’agence. Ce sont des modes de défaillance pratiques, plutôt que des préoccupations techniques abstraites.

Si un agent d’IA a trop d’autorité, il peut prendre des actions que aucun humain n’a intentionnellement prises. Si une injection d’invite réussit, le système peut divulguer des informations ou suivre des instructions hostiles. Si des données sensibles fuient à travers un modèle ou un système de récupération, la réponse a des implications juridiques, réglementaires, client et de réputation. C’est pourquoi le langage de la gouvernance d’IA peut parfois devenir trop passif. La gouvernance nous dit ce qui devrait être vrai. La réponse aux incidents nous dit ce que nous devons faire lorsque la réalité se déplace plus vite que la politique.

La réponse sera transversale

L’une des plus grandes leçons de la cybersécurité est que les incidents rarement restent dans l’équipe de sécurité. Au début, un événement peut sembler technique. Très rapidement, il implique le juridique, la communication, la direction commerciale, la conformité, les équipes client, les conseils externes, les assureurs, les spécialistes de l’analyse et parfois le conseil d’administration.

Les incidents d’IA suivront le même modèle.

Imaginez un modèle qui expose des informations client sensibles. Les équipes de sécurité et de confidentialité doivent comprendre ce qui s’est passé. Le juridique doit évaluer les obligations. La communication peut devoir se préparer pour les clients, les régulateurs ou les médias. L’ingénierie peut devoir désactiver ou rétrograder un système. Les dirigeants commerciaux peuvent devoir peser la continuité par rapport à la contention.

Ou imaginez un agent d’IA qui commence à prendre des actions non intentionnelles dans les systèmes d’entreprise. L’équipe technique peut être en mesure de l’arrêter, mais l’organisation a toujours besoin de savoir ce qu’il a fait, qui a été affecté, quelles décisions ont été prises, si des obligations contractuelles ont été déclenchées et comment la même défaillance sera prévenue à l’avenir. Cela ne peut pas être résolu par l’équipe d’IA seule.

Les organisations devraient construire une mémoire musculaire transversale avant d’en avoir besoin. Cela signifie des déclencheurs d’escalade clairs, des rôles clairs, des droits de décision clairs, des voies de communication claires, des documents clairs et de la pratique.

En cas de crise, la coordination est une infrastructure, et non seulement une compétence douce.

L’IA faisant l’objet de l’enquête ne doit pas contrôler la réponse

Il y a une autre question que les organisations doivent considérer beaucoup plus soigneusement. Si le système d’IA faisant l’objet de l’enquête peut accéder aux mêmes communications, documents, flux de travail ou automatisations utilisés pour coordonner la réponse, l’organisation a un problème.

En cybersécurité, c’est un principe familier. Si le rançongiciel a compromis le réseau d’entreprise, vous ne coordonnez pas la réponse sur des systèmes que l’attaquant peut lire, perturber ou manipuler. Vous sortez de la bande. Vous séparez l’incident de la réponse.

La même logique s’applique à l’IA.

Un système d’IA peut ne pas être malveillant dans le sens humain, mais s’il peut voir le plan de réponse, résumer la réunion de réponse, influencer le flux de travail, recommander l’étape suivante ou fonctionner dans le même environnement utilisé pour le contenir, alors l’organisation n’a pas vraiment isolé la réponse.

Cela devient encore plus important avec l’IA agente. Le cadre d’IA sécurisé de Google met en évidence des risques tels que l’injection d’invite, l’empoisonnement des données et les actions rebelles, et les cartographie sur des contrôles tout au long du cycle de vie de l’IA. C’est le bon encadrement. À mesure que les systèmes d’IA deviennent plus capables d’agir sur des outils, des données et des flux de travail, les organisations doivent réfléchir à la sécurité du modèle ET à la séparation opérationnelle.

Pensez-y comme à une enquête sur un incendie. Vous ne voudriez pas que les commandes de sprinkleur soient liées au même système défectueux que vous essayez de diagnostiquer.

Préparez, pratiquez, répondez, signalez

Un cadre utile pour la préparation aux incidents d’IA est le même qui a mûri dans la cybersécurité : préparez, pratiquez, répondez, signalez.

Préparez signifie définir les types d’incidents avant qu’ils ne se produisent, comme les biais, les hallucinations, les fuites de données, la dérive de modèle, l’injection d’invite, la fuite d’agent, l’utilisation non autorisée d’outils et la défaillance de modèle tiers. Chacun nécessite différents intervenants et différentes décisions.

Un bon livre de jeu ne devrait pas être un document de 200 pages dans un dossier. Personne n’ouvre la page 137 pendant une crise. Un bon livre de jeu est basé sur les rôles, accessible et actionnable. Le juridique sait ce que le juridique doit faire. L’ingénierie sait ce que l’ingénierie doit faire. La communication sait quand s’engager. Le conseil d’administration sait quand la direction va escalader.

Pratiquez signifie exécuter des exercices de tableau. Pas une fois par an comme une case à cocher, mais suffisamment souvent pour construire une mémoire musculaire. La première fois que le conseil d’administration discute d’un incident d’IA ne devrait pas être pendant un véritable incident d’IA. La première fois que le juridique, l’ingénierie, la confidentialité, la sécurité et la communication travaillent ensemble sur une défaillance d’IA ne devrait pas être lorsque les clients posent déjà des questions.

Répondez signifie coordonner l’événement en direct avec discipline. Qui est dans la salle ? Quels faits sont connus ? Quels faits sont encore incertains ? Quelles décisions ont été prises ? Qui les a approuvées ? Qu’est-ce qui a changé entre l’heure 12 et l’heure 48 ?

Signalez signifie reconnaître que la réglementation de l’IA devient plus concrète. L’acte d’IA de l’UE inclut des obligations de signalement d’incidents graves pour les fournisseurs de certains systèmes d’IA à haut risque. Les détails varieront selon la juridiction, l’industrie et le cas d’utilisation, mais la direction est claire. Les incidents d’IA nécessiteront de plus en plus un dossier défendable de ce qui s’est passé, de ce qui était connu, des actions qui ont été prises et de quand.

L’IA peut aider, mais elle ne peut pas remplacer le jugement

Il y a une tentation de penser que la réponse aux incidents d’IA devrait être entièrement automatisée. Je pense que c’est le mauvais encadrement.

L’IA peut aider énormément. Elle peut résumer les faits. Elle peut identifier les informations manquantes. Elle peut comparer un incident à des modèles antérieurs. Elle peut rédiger des rapports après-action. Elle peut aider à cartographier les obligations réglementaires. Elle peut réduire la charge administrative lorsque les gens sont sous pression.

Mais dans un incident grave, les humains restent indispensables.

Quelqu’un doit décider si les faits sont suffisants. Quelqu’un doit peser l’impact client. Quelqu’un doit décider si la pause d’un système est nécessaire. Quelqu’un doit déterminer si l’organisation a franchi un seuil de signalement. Quelqu’un doit communiquer avec une responsabilité et de l’empathie.

Le rôle approprié de l’IA dans la réponse aux incidents est de donner à l’équipe de crise un meilleur contexte, plus rapidement.

Le cadre de gestion des risques d’IA du NIST est utile car il encadre la gestion des risques d’IA autour de quatre fonctions : gouverner, cartographier, mesurer et gérer. Pour la réponse aux incidents, j’ajouterais une extension pratique : répéter.

Un plan qui n’a jamais été testé n’est pas vraiment un plan. C’est une théorie.

Les conseils d’administration ont besoin d’un livre de jeu, eux aussi

Le risque d’IA devient un sujet de conseil d’administration, mais l’implication du conseil d’administration ne peut pas s’arrêter à des diapositives de surveillance. Les conseils d’administration doivent comprendre leur rôle avant qu’une crise ne se produise.

Quand le conseil d’administration sera-t-il informé ? Quelles décisions nécessitent une contribution du conseil d’administration ? Quelles informations la direction fournira-t-elle ? Comment la matérialité, l’impact client, l’exposition juridique, les obligations réglementaires et la perturbation opérationnelle seront-elles évaluées ?

De nombreuses organisations ont des livres de jeu de sécurité, des livres de jeu de confidentialité, des livres de jeu de communication et des livres de jeu juridiques. Beaucoup moins ont un livre de jeu de conseil d’administration pour les incidents d’IA. Ce fossé deviendra plus visible à mesure que les systèmes d’IA se déplaceront vers des flux de travail réglementés, générant des revenus et orientés client. Le rôle du conseil d’administration est d’aider l’organisation à prendre de meilleures décisions sous pression, et non de devenir plus technique.

L’IA fiable nécessite une résilience opérationnelle

Il y a beaucoup de conversation sur l’IA fiable. C’est l’aspiration appropriée, mais la confiance n’est pas créée par des principes seuls. La confiance est créée lorsque les organisations peuvent montrer comment elles se préparent, comment elles détectent les problèmes, comment elles répondent, comment elles communiquent, comment elles documentent les décisions et comment elles améliorent.

La cybersécurité a traversé la même évolution. Les organisations ont passé des années à investir dans la prévention, et elles devraient continuer à le faire. Mais les organisations matures ont finalement appris que la prévention ne suffit pas. Vous avez également besoin de résilience. L’IA entre dans la même phase.

Nous devrions absolument construire des modèles plus sûrs, des contrôles plus solides, de meilleures évaluations, de meilleures équipes rouges et de meilleures gouvernances, mais nous devrions également accepter que les incidents se produiront. Les modèles échoueront, les agents se comporteront de manière inattendue, les données fuiront, les humains abuseront des systèmes, les fournisseurs feront des erreurs et les réglementations évolueront.

La question est de savoir si l’organisation peut répondre avec rapidité, coordination, jugement et responsabilité lorsqu’un incident se produit. C’est ainsi que l’IA passe de l’expérimentation à une infrastructure fiable, et c’est ainsi que la résilience devient une culture.