Il y a encore deux ou trois ans, l’intelligence artificielle était un thème expérimental. Aujourd’hui, cette technologie est omniprésente dans les outils métiers, les navigateurs web, les processus de travail, les logiciels, les CRM, les suites bureautiques, mais aussi dans les outils de support client. Conséquence : les services helpdesk sont confrontés à un afflux massif de demandes.
« L’assistant m’a induit en erreur. Les chiffres affichés ne sont pas réels. », « J’ai accès à des documents délicats d’une autre équipe. » « L’IA a pris en considération une ancienne version d’un document pour référence, comment rectifier ça ? » … Autant de questions liées à la fiabilité et à la sécurité de l’IA se répètent. À travers cet article, découvrez pourquoi un playbook dédié est important, et comment le construire.
Un incident IA n’est pas un incident comme les autres
On peut traduire généralement un incident informatique classique en deux états, soit le service fonctionne ou il est en panne. Avec le déploiement de l’IA, les incidents sont devenus improbables et invisibles. L’outil est capable de répondre, mais la réponse manque de précision, biaisée ou carrément inappropriée. Alors, pourquoi ces incidents associés à l’intelligence artificielle générative sont si compliqués à déchiffrer et à traiter :
- Ils sont non déterministes. La même question peut générer deux réponses différentes. Reproduire le problème devient un véritable challenge.
- Ils sont multiformes. Un même incident peut soulever des enjeux multiples, liés étroitement à la qualité, à la sécurité, à la conformité réglementaire ou encore à la protection des données.
- Ils sont souvent silencieux. L’IA peut causer une hallucination (réponse fausse ou trompeuse) qui s’introduit dans un rapport, un devis ou une décision cruciale.
- Ils impliquent des tiers. La responsabilité est partagée entre plusieurs intervenants. Il peut s’agir du fournisseur du modèle, du développeur de l’application, ou encore de l’équipe interne.
C’est pourquoi il faut instaurer un cadre commun, qui organise les niveaux d’interventions, les types d’incidents et le temps de traitement réel. C’est précisément ce que le playbook vient corriger.
Apprendre à reconnaître les signaux faibles
Le premier réflexe est d’identifier ce qu’est un incident IA. Sans typologie claire, il est difficile de le dépister et de le trier. Pour y voir plus clair, nous avons catégorisé quatre grandes familles des incidents IA :
- Erreurs de réponse : l’IA peut proposer des informations fausses, trompeuses, inventées, périmées ou contradictoires.
- Accès inadaptés : l’outil attribue des accès inappropriés à des contenus supposés incassables, à cause de droits mal configurés sur les sources connectées.
- Données sensibles : saisie de données personnelles, délicates, confidentielles ou stratégiques dans un outil non autorisé.
- Comportements imprévisibles : des faits inattendus peuvent survenir comme les contenus offensants, les manipulations automatiques non demandées, le contournement des consignes, ou les réponses manipulées par un prompt malveillant.
Le playbook doit faciliter la déclaration de ces incidents. Il est recommandé d’intégrer une nouvelle section « Incident IA » dans votre outil de ticketing, avec certains champs guidés : outil en question, question posée, réponse générée, capture d’écran, impact perçu. Il sera plus utile d’intégrer aussi un bouton de signalement pour les utilisateurs afin de détecter puis signaler tout incident lié à l’IA : volumes inhabituels de requêtes, données sensibles, journalisation des accès.
Qui prend la décision, et à quelle vitesse ?
C’est justement à ce niveau que les choses deviennent de plus en plus sérieuses. Le help desk services de niveau 1 de ni dispose pas des compétences requises pour traiter une fuite de données potentielle, par exemple. C’est pourquoi il faudra mettre en place un circuit d’escalade pour identifier la gravité de chaque situation.
Pour commencer, voici une grille simple à trois niveaux d’intervention :
- Niveau 1, mineur : erreur de réponse sans incident grave, identifiée avant toute utilisation. Traitement rapide par le support IT help desk, avec signalement au référent de l’outil.
- Niveau 2, significatif : réponse erronée exploitée dans un livrable, ou accès ponctuel à un contenu non autorisé. Escalade immédiate vers le référent IA et l’équipe sécurité.
- Niveau 3, critique : fuite de données personnelles ou confidentielles, comportement automatisé à effet réel, atteinte à un client. Instauration de la cellule de crise, information du délégué à la protection des données (DPO) et du service juridique.
Votre playbook, dédié aux incidents IA, doit inclure les responsabilités et les intervenants. De manière plus explicite, il doit présenter qui qualifie l’incident et qui notifie, sans ambiguïté. Pour chaque niveau, il faudra détailler les délais de prise en charge, les interlocuteurs et les actions de confinement immédiates : stopper l’accès à la fonctionnalité, révoquer un connecteur, bloquer un compte, etc. Au niveau réglementaire, sachez qu’une fuite de données personnelles est susceptible de déclencher une notification à l’autorité de contrôle dans un délai de 72 heures au titre du RGPD.
Considérer chaque ticket comme une preuve exploitable
Un incident IA, mal documenté, peut poser de véritables problèmes vis-à-vis de l’auditeur. Ce genre d’incident est compliqué à comprendre et à reproduire. Le support Help Desk, comme celui de Advancia Téléservices, doit collecter de manière systématique :
- Le contexte : outil utilisé, version de l’outil, date et heure, utilisateur, périmètre de données connecté
- Le prompt exact et la réponse obtenue, en incluant des screenshots ou des export de la conversation
- L’effet constaté ou potentiel : décision prise, document diffusé, données exposées
- Les actions élaborées : confinement, échanges avec le fournisseur, correctifs ;
- La classification : famille d’incident, niveau de gravité, causes présumées.
Tout document lié à aux incidents IA simplifie les analyses de tendance et protège l’entreprise en cas de litige ou de contrôle
Le retour d’expérience : la boucle qui fait progresser
La valeur ajoutée du playbook se manifeste véritablement après la résolution des incidents IA. C’est à partir du retour d’expérience (REX) qu’on peut tirer les leçons. Les indicateurs exploités peuvent améliorer et optimiser la gouvernance de l’IA :
- Mettre en place un REX court et sans reproche pour les incidents de niveau 2 et 3.
- Repérer l’origine des problèmes : prompt mal rédigé, droits trop larges, pas de formation, modèle limité, défaut du fournisseur.
- Réaliser des actions concrètes : modification des permissions, filtres de contenu, actualisation de la charte d’usage, session de sensibilisation ciblée.
- Enrichir une base de connaissances accessible aux agents.
- Activer des KPI pour suivre la performance : nombre d’incidents par famille, délai de détection, délai de résolution, taux de récurrence.
Questions fréquentes (FAQ)
Une hallucination de l’IA correspond à une réponse fausse ou trompeuse. On peut la considérer comme un incident si elle a un impact direct sur une décision, un livrable ou un client. Même sans gravité, il faudra le signaler afin d’identifier les tendances et optimiser la configuration de l’outil.
Pas obligatoirement. Un référent IA, appuyé par la sécurité, le DPO et le Service Desk, peuvent largement suffire pour commencer. Le plus important est que chaque intervenant connaît ce qu’il a à faire.
Il s’agit d’un incident de niveau 2 ou 3 en fonction de la sensibilité des données : documenter ce qui a été saisi, contacter le fournisseur pour demander la suppression si possible, informer le DPO et rappeler les règles d’usage.
Pour éviter cela, il faudra mettre en place une culture sans reproche, en facilitant la déclaration et en montrant que chaque signalement mène à une amélioration concrète.
Oui. Les outils, les usages et la réglementation sont en constante évolution. C’est pourquoi, il faudra mettre à jour le playbook plus souvent, en l’alimentant par les retours d’expérience.
