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é pense attaque et fuite de données. Le juridique pense AI Act, RGPD, documentation. Les métiers voient surtout l'erreur opérationnelle. La direction regarde l'exposition financière, la réputation et la capacité à répondre si le système dérape. Résultat : la discussion avance mal. Tout le monde croit parler du même sujet. En réalité, chacun parle d'un risque différent.

Le risque IA n'est pas un seul risque

Une IA peut être utile, performante, et poser quand même 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, mais ne laisser aucune trace claire de ce qui a justifié sa recommandation. Un chatbot peut répondre correctement dans 95 % des cas et se tromper sur les quelques réponses qui engagent vraiment l'entreprise.

Pour un décideur, la bonne question n'est donc pas seulement : « est-ce que le modèle marche ? » Elle est plus rude : que peut-il abîmer ? Qui peut être touché ? Verrait-on la défaillance assez tôt ? Et quelles preuves montrent que les contrôles tiennent encore 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 saute de la qualité du modèle à la vie privée, puis de la conformité à la confiance client, sans jamais décider quoi que ce soit. Dans une entreprise, « risque IA » recouvre au moins six réalités.

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. Ensuite, il 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 l'évaluation. Elles servent à nommer le dommage possible. Les six dimensions ci-dessous servent ensuite à examiner le système, à décider ce qui est acceptable et à garder la 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 force le système à passer par six angles. Pensez-les comme des lignes de faille pratiques : 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 ? Exemple 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 ? Ici, on cherche surtout les instructions cachées, les fuites de données, les appels d'outils non autorisés, les secrets exposés ou les agents trop permissifs.
Précision : la sortie est-elle assez fiable pour la décision concernée ? Une règle inventée, un mauvais score, une alerte manquée, une source mal citée ou une recommandation qui contredit le dossier suffisent à rendre le système dangereux.
Équité : le système traite-t-il des personnes ou dossiers comparables de façon différente sans justification solide ? Le risque, c'est le 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 ? Si personne ne sait reconstruire, contester ou corriger une décision, le contrôle est trop faible.
Auditabilité : sait-on qui possède le système, qui approuve les changements, qui suit les incidents et où sont les preuves ? Une IA utile mais sans responsable clair, sans historique, sans journaux et sans chemin d'escalade reste un mauvais actif de gouvernance.

Un cas concret : l'assistant sinistres

L'assistant sinistres est intéressant parce qu'il paraît 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. Il influence une décision financière. Il pèse sur l'explication donnée au client. Et s'il se trompe de façon répétée, l'erreur peut se retrouver sur des centaines de dossiers.

Côté vie privée, il faut vérifier qu'il voit seulement les pièces nécessaires au sinistre. Côté sécurité, les PDF, e-mails et notes client doivent être testés comme des vecteurs possibles d'instructions cachées. Pour la précision, une impression générale de qualité ne suffit pas : il faut comparer les résumés aux clauses du contrat et aux pièces du dossier.

L'équité demande de 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. Pour l'explicabilité, le gestionnaire doit voir les documents et les clauses qui soutiennent la recommandation. Pour 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 leur mise à jour. 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 rester utile, voire 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.