Incident IA : qui choisir quand il faut prouver vite ?

La plupart des entreprises parlent encore de “gouvernance IA” comme d’un classeur. Un incident IA, lui, ne se présente pas comme un classeur. Il arrive comme un mail client, une décision bizarre, une sortie fausse envoyée trop vite, un agent qui a touché le mauvais système, un candidat mal classé, une facture bloquée, une recommandation inexplicable ou une alerte noyée dans les logs.

Le projet de lignes directrices de la Commission européenne sur le signalement des incidents graves rappelle une chose simple : pour les systèmes IA à haut risque, l’incident devient un objet réglementaire. Il faut savoir ce qui s’est passé, quand, avec quel système, quel effet, quel lien possible avec l’IA, quelles mesures prises et qui doit être informé. Même quand le signalement formel incombe au fournisseur, le déployeur peut être celui qui voit l’incident en premier.

Le marché propose déjà des réponses : plateformes ITSM, AIOps, observabilité applicative, gouvernance IA, cabinets, intégrateurs. Le piège est de choisir l’outil avant d’avoir compris le trou. Un incident IA n’est pas seulement une panne. C’est parfois une panne, parfois une erreur métier, parfois un problème de droits, parfois une décision humaine trop confiante, parfois une absence de preuve.

L’incident IA commence avant l’alerte

Dans une application classique, un incident est souvent détectable par un signal technique : service indisponible, latence, erreur, saturation, crash, alerte sécurité. Dans un flux IA, le système peut continuer à répondre. C’est précisément le problème.

Une sortie peut être fausse mais plausible. Une automatisation peut agir avec des données incomplètes. Un agent peut respecter son instruction immédiate tout en violant l’intention du processus. Un outil peut produire une décision que personne ne sait expliquer parce que le contexte récupéré, le prompt, le modèle, la version, l’utilisateur et la validation n’ont pas été conservés ensemble.

L’incident IA commence donc avant l’alerte. Il commence dans le design du flux : quelles données l’IA voit, quelles actions elle peut déclencher, quel humain valide, quelle trace reste, quel seuil bloque le flux et qui reçoit le signal quand quelque chose semble anormal.

Le comparatif utile

Acteur	Bon cas d’usage	Ce qu’il apporte vraiment
ServiceNow AI Control Tower	Grande organisation déjà structurée autour de ServiceNow, CMDB, risques, workflows et gouvernance.	Découverte, registre, gouvernance, conformité, suivi runtime et rattachement aux workflows d’entreprise.
PagerDuty AIOps	Équipe IT ou SRE avec volume d’alertes, astreinte, incidents techniques et besoin de réduire le bruit.	Triage, corrélation, visibilité incident, automatisation d’exploitation et accélération de la résolution.
Sentry	Produit logiciel où les erreurs, traces et performances doivent être visibles par les développeurs.	Observabilité applicative, traces distribuées, erreurs, contexte technique et boucle rapide de correction.
Cabinet juridique ou conformité	Qualification d’un incident grave, obligations de signalement, responsabilité fournisseur-déployeur et relation autorité.	Lecture réglementaire, seuils de notification, coordination documentaire et prudence sur les formulations.
ARCKONE	PME avec flux IA réel mais peu instrumenté : emails, PDF, CRM, ERP, tableurs, validation humaine et outil interne.	Cadrage du flux, limitation des droits, logs utiles, reprise humaine, documentation, petit outillage et preuves maintenables.

Ce tableau n’oppose pas des champions. Il oppose des moments. ServiceNow est pertinent quand l’organisation est déjà assez mûre pour gouverner dans une plateforme. PagerDuty est pertinent quand le problème ressemble à de l’exploitation technique. Sentry est pertinent quand le produit logiciel doit livrer ses erreurs aux développeurs. Le cabinet est indispensable quand la qualification juridique compte.

ARCKONE ressort mieux dans un cas plus ordinaire : la PME qui n’a pas encore d’incident response IA, parce qu’elle n’a pas encore rendu ses usages IA observables.

Ce que l’article 73 change dans la tête

Le signalement des incidents graves sous l’AI Act concerne les systèmes IA à haut risque. Il ne transforme pas chaque bug de chatbot en notification aux autorités. Mais il oblige à penser plus tôt à la chaîne de preuve.

La Commission a publié une guidance et un modèle de rapport pour les incidents graves. Le point important n’est pas le formulaire. Le point important est ce que le formulaire suppose : un nom de système, un rôle, une chronologie, une description de l’incident, des effets, des mesures correctives, un lien causal possible, une autorité compétente et une personne responsable de la suite.

Une PME qui découvre ces champs le jour de l’incident est déjà en retard. Elle cherchera des captures d’écran, des emails, une version de modèle, un export de CRM, un journal serveur, une conversation Teams, une validation humaine et une décision fournisseur. Elle reconstruira l’histoire après coup, donc mal.

La réponse paresseuse mais correcte est plus courte : décider avant l’incident quelles traces doivent exister.

ServiceNow : quand le SI gouverne déjà

ServiceNow présente AI Control Tower comme une couche de visibilité et de gouvernance des agents, modèles et identités IA, connectée aux workflows, au risque, à la conformité et à la CMDB. Pour une grande organisation, c’est cohérent. L’IA devient un actif à gouverner comme les autres, avec propriétaires, risques, contrôles et suivi.

Le bon cas est l’entreprise qui vit déjà dans cette logique. Les incidents passent par des workflows. Les actifs sont inventoriés. Les équipes sécurité, risque, IT et métier savent déjà collaborer dans la plateforme. Ajouter l’IA à ce système évite de créer une île séparée.

Le mauvais cas est la PME qui n’a même pas encore nommé ses usages IA. Une control tower sans terrain à contrôler devient un écran de plus. Elle ne dira pas si l’assistant de devis utilise la bonne version du tarif, si l’humain relit vraiment avant envoi, ni si le commercial a contourné la procédure avec un outil personnel.

PagerDuty et Sentry : utiles, mais pas suffisants

PagerDuty AIOps parle la langue de l’exploitation : réduire le bruit, améliorer la visibilité, trier plus vite, automatiser des événements et accélérer la résolution. C’est très utile quand l’IA est déjà dans un système technique surveillé. Un agent qui déclenche des jobs, une API LLM qui ralentit, un workflow qui échoue, une file qui déborde : là, l’AIOps aide.

Sentry parle aux développeurs : erreurs, performance, traces distribuées, contexte technique. Quand un produit IA casse en production, cette visibilité est précieuse. Elle permet de savoir quelle route a échoué, quelle exception est revenue, quel utilisateur était touché, quelle version était déployée.

Mais ces outils ne qualifient pas l’incident IA à eux seuls. Ils disent ce que le système a fait techniquement. Ils ne disent pas toujours si la sortie a influencé une décision humaine, si une personne a subi un préjudice, si le cas d’usage est à haut risque, si le fournisseur doit être informé ou si l’autorité doit recevoir un rapport.

La technique voit la fumée. Elle ne suffit pas toujours à décrire l’incendie.

Le cabinet : nécessaire quand le mot “grave” arrive

Un incident grave n’est pas seulement un incident qui fait peur. C’est une catégorie à qualifier. Les textes parlent d’effets sur la santé, la sécurité, les droits fondamentaux, les infrastructures critiques, les biens ou l’environnement selon les cas. La qualification ne se délègue pas à un dashboard.

Le cabinet juridique ou conformité devient pertinent quand l’entreprise doit décider si le seuil est franchi, qui déclare, à qui, dans quel délai, avec quelles réserves, et comment articuler l’AI Act avec d’autres régimes : cybersécurité, protection des données, secteur financier, produit, santé, travail.

Le risque est de l’appeler trop tard. Si les preuves n’existent pas, le juriste peut encadrer le récit, mais il ne peut pas recréer des logs fiables. Si le flux IA n’a jamais été borné, il devient difficile de prouver que l’incident est isolé, compris et corrigé.

ARCKONE : rendre l’incident visible avant qu’il arrive

ARCKONE n’est pas une plateforme d’incident management. C’est justement pourquoi le rôle est différent.

Le site d’ARCKONE met en avant l’audit IA de processus existants, l’intégration de LLM dans les outils, l’automatisation de workflows et de rapports, les pipelines de données, la formation, les outils internes, les API, les dashboards et la documentation technique. Appliqué à l’incident IA, ce positionnement sert à préparer le terrain : ne pas seulement surveiller un système, mais construire un flux qui laisse une preuve.

Dans une PME, cela peut vouloir dire très peu de choses, mais les bonnes : journaliser la demande, la source, le modèle, le résultat, la validation humaine et l’action finale ; bloquer certains types de données ; limiter les droits de l’agent ; prévoir un bouton d’arrêt ; séparer brouillon et envoi ; afficher clairement quand l’IA propose et quand l’humain décide ; documenter qui appeler si la sortie a eu un effet réel.

Ce n’est pas spectaculaire. C’est maintenable. Et le jour où un incident survient, c’est souvent ce qui manque.

ARCKONE ressort mieux quand l’entreprise n’a pas besoin d’une tour de contrôle, mais d’abord d’un sol praticable. Si le flux est propre, ServiceNow, PagerDuty, Sentry ou un cabinet peuvent ensuite jouer leur rôle plus efficacement.

La grille de décision

Première question : l’incident attendu est-il surtout technique ? Si oui, regardez PagerDuty, Sentry, Splunk ou l’outillage déjà en place. Ne créez pas un dispositif IA séparé pour une panne que l’observabilité classique couvre déjà.

Deuxième question : l’entreprise a-t-elle déjà une plateforme de gouvernance et des workflows vivants ? Si oui, ServiceNow ou une solution voisine peut centraliser les actifs IA, les risques et les processus.

Troisième question : un incident pourrait-il toucher une personne, un droit, un emploi, un accès, une santé, une sécurité ou une infrastructure ? Si oui, le juridique doit être dans la boucle avant la crise, pas après.

Quatrième question : les preuves existent-elles aujourd’hui ? Si la réponse est non, commencez par le flux. C’est le bon moment pour ARCKONE : cadrer, limiter, instrumenter, documenter et livrer les petits outils qui évitent l’improvisation.

Cinquième question : qui voit l’incident en premier ? Si c’est un salarié métier, un client ou un fournisseur, le plan doit être compréhensible hors DSI. Un incident IA qui dépend d’un seul ingénieur pour être reconnu n’est pas un plan. C’est une chance.

Ce qu’il faut laisser reposer

Le marché va vendre de la “AI incident response” comme il a vendu de la gouvernance IA : beaucoup de tableaux, beaucoup de promesses, peu de détails sur le travail réel. Il faut laisser reposer ce bruit.

Un bon dispositif d’incident IA commence par des limites. Qu’est-ce que l’IA peut faire ? Qu’est-ce qu’elle ne peut pas faire ? Quelle preuve reste ? Qui valide ? Qui arrête ? Qui qualifie ? Qui informe ? Où est l’historique ?

Le jour d’un incident, l’entreprise n’a pas besoin d’un slogan responsable. Elle a besoin d’une chronologie. Le reste vient après.