Risque IA : de quoi parle-t-on exactement ?

Dans beaucoup d'entreprises, « risque IA » sert à désigner trop de choses à la fois. La sécurité entend attaque et fuite de données. Le juridique entend AI Act et RGPD. Les métiers entendent erreur opérationnelle. La direction entend exposition financière, réputation et capacité à répondre en cas d'incident. Tant que ces sujets restent mélangés, la discussion avance mal : chacun parle d'un risque différent en croyant parler du même.

Le risque IA n'est pas un seul risque

Une IA peut être utile, performante, et quand même poser un problème sérieux. Un modèle peut bien détecter la fraude tout en exposant des données clients. Un assistant peut accélérer l'analyse d'un dossier sans laisser de trace claire sur ce qui a justifié une recommandation. Un chatbot peut répondre correctement dans 95 % des cas et se tromper précisément sur les réponses qui engagent l'entreprise.

Pour un décideur, la question n'est donc pas seulement : « est-ce que le modèle marche ? » La question utile est plus directe : que peut-il abîmer, qui peut être touché, comment verrait-on la défaillance, et quelles preuves montrent que les contrôles tiennent dans la durée ?

On ne pilote pas un risque IA en bloc. On le découpe en décisions, données, actions et preuves.

Six familles de risque que l'on confond souvent

Avant de choisir des contrôles, il faut nommer le risque. Sinon, la même réunion passe de la qualité du modèle à la vie privée, puis de la conformité à la confiance client, sans jamais trancher. Dans une entreprise, « risque IA » recouvre au moins six réalités différentes.

Risque de modèle : le système se trompe, hallucine, score mal, se dégrade avec le temps ou échoue dès qu'il sort des cas prévus.
Risque de données : les données sont sensibles, biaisées, obsolètes, incomplètes, mal gouvernées ou utilisées pour une finalité qui n'a pas été validée.
Risque de sécurité : le système peut être manipulé, contourné ou utilisé pour accéder à des données, outils ou droits qui devraient rester protégés.
Risque réglementaire : l'entreprise ne peut pas prouver qu'elle respecte ses obligations de documentation, supervision humaine, analyse d'impact, transparence, traçabilité ou gestion des incidents.
Risque opérationnel : le système ralentit un processus, bloque un dossier, répète une erreur à grande échelle, déclenche la mauvaise action ou laisse les équipes sans solution de repli.
Risque réputationnel : clients, salariés, partenaires ou public perdent confiance parce que le système paraît injuste, absurde, opaque ou impossible à défendre.

Prenez un assistant sinistres en assurance. Il lit une déclaration d'accident, des pièces médicales, des clauses contractuelles, des factures et des décisions passées, puis propose un résumé et une prochaine action au gestionnaire. Le risque de modèle, c'est le résumé faux ou l'exclusion oubliée. Le risque de données, c'est le document médical visible par la mauvaise équipe. Le risque de sécurité, c'est la pièce jointe qui contient une instruction cachée. Le risque réglementaire, c'est l'impossibilité d'expliquer la décision. Le risque opérationnel, c'est le mauvais montant payé ou le dossier légitime bloqué. Le risque réputationnel, c'est le client qui prouve que l'entreprise s'est appuyée sur un processus opaque.

Ces familles ne remplacent pas une évaluation. Elles servent à nommer le type de dommage possible. Les six dimensions ci-dessous servent ensuite à examiner le système, à décider ce qui est acceptable et à garder une preuve de cette décision.

Partez de l'usage, pas du modèle

Un chatbot de support, un modèle d'octroi de crédit, un moteur anti-fraude, un assistant sinistres et un outil de triage médical ne défaillent pas de la même manière. Ce qui compte d'abord, c'est l'usage. Le système conseille-t-il un humain ? Classe-t-il des dossiers ? Prend-il une décision ? Déclenche-t-il une action ? Parle-t-il directement à un client ?

Cette distinction pèse plus lourd que la technologie utilisée. Un petit modèle statistique utilisé pour l'éligibilité au crédit peut porter plus de risque qu'un grand modèle de langage qui résume des contenus publics. Un assistant documentaire devient sensible s'il voit des fichiers confidentiels sans contrôle d'accès. Un agent devient critique dès qu'il peut envoyer un e-mail, créer un ticket, approuver un paiement ou modifier un système de production.

Les six dimensions à examiner

Une bonne évaluation oblige à regarder le système sous six angles. Ce ne sont pas des cases théoriques. Ce sont les endroits où les problèmes apparaissent le plus souvent dans les organisations.

Vie privée : quelles données personnelles, confidentielles ou réglementées le système peut-il voir, déduire, conserver ou exposer ? Le problème typique : une réponse qui révèle les informations d'un autre client, un document RH qui remonte au mauvais utilisateur, ou des données conservées hors de la finalité prévue.
Sécurité : le système peut-il être manipulé, contourné ou utilisé comme point d'entrée vers un autre système ? Le problème typique : une instruction cachée, une fuite de données, un appel d'outil non autorisé, un secret exposé ou un agent trop permissif.
Précision : la sortie est-elle fiable pour la décision concernée ? Le problème typique : une règle inventée, un mauvais score, une alerte manquée, une source mal citée ou une recommandation qui contredit le dossier.
Équité : le système traite-t-il des personnes ou dossiers comparables de façon différente sans justification solide ? Le problème typique : un refus injuste, une qualité de service plus faible pour certains profils ou une règle qui reproduit un biais historique.
Explicabilité : l'entreprise peut-elle expliquer la décision, la recommandation ou l'action au niveau attendu par l'utilisateur, l'auditeur ou le régulateur ? Le problème typique : une décision que personne ne sait reconstruire, contester ou corriger.
Auditabilité : sait-on qui possède le système, qui approuve les changements, qui suit les incidents et où sont les preuves ? Le problème typique : une IA utile mais sans responsable clair, sans historique, sans journaux et sans chemin d'escalade.

Un cas concret : l'assistant sinistres

L'assistant sinistres est intéressant parce qu'il paraît assez banal. Il n'approuve pas seul le paiement. Il ne remplace pas le gestionnaire. Il lit le dossier, résume les pièces, signale les clauses utiles et propose une prochaine étape. Pourtant, il touche des données sensibles, influence une décision financière, pèse sur l'explication donnée au client et peut répéter la même erreur sur des centaines de dossiers.

Sur la vie privée, il faut vérifier qu'il voit seulement les pièces nécessaires au sinistre. Sur la sécurité, il faut tester les PDF, e-mails et notes client qui pourraient contenir une instruction cachée. Sur la précision, il faut comparer ses résumés aux clauses du contrat et aux pièces du dossier, pas seulement mesurer une impression générale de qualité.

Sur l'équité, l'assureur doit vérifier que des sinistres comparables sont traités de façon cohérente selon les régions, les langues, les âges ou les profils clients. Sur l'explicabilité, le gestionnaire doit voir les documents et les clauses qui soutiennent la recommandation. Sur l'auditabilité, l'entreprise doit savoir qui a validé l'usage, quels seuils déclenchent une revue humaine, quels journaux sont conservés et comment corriger le système quand il se trompe.

Ce qu'il faut pouvoir prouver

Un comité de direction, un auditeur ou un régulateur n'a pas besoin d'entendre « nous avons testé le modèle ». Il a besoin de savoir ce qui a été testé, quand, sur quelle version, avec quels seuils, et ce qui s'est passé lorsqu'un test a échoué.

Les preuves utiles sont souvent simples : une entrée dans l'inventaire, une classification du risque, une cartographie des données, un jeu de tests, des résultats d'évaluation, des journaux, les versions du modèle et des instructions, les limites connues, les incidents, les décisions de correction et un responsable identifié.

Le point difficile, c'est la mise à jour de ces preuves. Le comportement d'un système peut changer après une nouvelle instruction, une réindexation de documents, un changement de fournisseur, une permission d'outil ajoutée, une nouvelle source de données ou simplement un nouvel usage. Une preuve du trimestre dernier ne décrit pas toujours le système qui tourne aujourd'hui.

Une grille simple pour décider

La discussion doit pouvoir tenir sur une page. Avant de débattre d'une politique interne ou d'une formulation juridique, posez sept questions sur le système lui-même.

Que fait le système ? Conseil, classement, décision, action ou communication externe ?
Qui peut être affecté ? Clients, salariés, patients, contreparties, fournisseurs, public ?
Quelles données utilise-t-il ? Données personnelles, documents confidentiels, dossiers réglementés, transactions, informations publiques ?
Quelles dimensions sont critiques ? Vie privée, sécurité, précision, équité, explicabilité, auditabilité, ou plusieurs à la fois.
Quelles preuves existent aujourd'hui ? Tests, journaux, suivi en production, approbations, incidents, corrections décidées.
Quel contrôle limiterait le pire scénario ? Revue humaine, limite d'accès, restriction d'outil, seuil, blocage avant mise en production, retour arrière, information client.
Quel risque résiduel le métier accepte-t-il ? En chiffres, en utilisateurs touchés, en exposition financière, juridique et opérationnelle.

Si l'équipe ne peut pas répondre, le système n'est pas prêt pour une décision d'acceptation du risque. Il peut être utile. Il peut même être peu risqué. Mais l'organisation n'a pas encore assez d'éléments pour l'affirmer.

Ce que les textes demandent, au fond

Les principaux cadres n'utilisent pas les mêmes mots, mais ils demandent à peu près la même discipline. L'AI Act parle de gestion du risque, de gouvernance des données, de journaux, de transparence, de supervision humaine, de précision, de robustesse et de cybersécurité. Le RGPD demande une analyse d'impact lorsque le traitement peut créer un risque élevé pour les personnes. NIST AI RMF organise le travail autour de Govern, Map, Measure et Manage. ISO/IEC 42001 demande des politiques, des rôles, des processus et une amélioration continue.

Pour un décideur, la leçon est simple : ne commencez pas par les numéros d'articles. Commencez par le système, son impact, les six dimensions de risque et les preuves disponibles. Le rattachement juridique vient ensuite. Si les faits sont flous, l'analyse juridique le sera aussi.

Le bon livrable : une fiche de risque

Le résultat ne devrait pas être une longue présentation de gouvernance. Pour chaque système d'IA important, il faut une fiche courte : périmètre, responsable, cas d'usage, données utilisées, personnes affectées, textes applicables, six dimensions, preuves disponibles, points ouverts, corrections prévues et risque résiduel accepté.

Cette fiche donne au comité de direction un vrai support de décision. Elle donne aussi aux équipes sécurité, juridique, données et produit une même base de discussion. Quand le système change, la fiche change. Quand un auditeur demande quels contrôles existent, la réponse n'est pas un récit reconstruit après coup. C'est une chaîne de preuves déjà attachée au système.

Références

Règlement (UE) 2024/1689 (AI Act), articles 9, 10, 12, 13, 14 et 15, eur-lex.europa.eu/eli/reg/2024/1689/oj.
Règlement (UE) 2016/679 (RGPD), article 35, eur-lex.europa.eu/eli/reg/2016/679/oj.
NIST, Artificial Intelligence Risk Management Framework 1.0, Govern, Map, Measure and Manage, nist.gov/itl/ai-risk-management-framework.
ISO/IEC 42001:2023, système de management de l'intelligence artificielle, iso.org/standard/42001.