L’essentiel
- La gestion des risques liés à l’IA n’est pas un glossaire de cadres : c’est un programme unique et responsabilisé qui suit un même cycle (identifier, évaluer, traiter, surveiller) pour l’ensemble des systèmes d’IA de l’organisation.
- Trois références structurent ce programme sans le fragmenter : le
NIST AI RMF, le coupleISO/IEC 42001etISO/IEC 23894, et l’Article 9de l’EU AI Act. Elles alimentent le même jeu de contrôles, de propriétaires et de preuves. - Les risques se répartissent en quatre familles : les données, les modèles, la sécurité et l’exploitation, puis les enjeux éthiques et juridiques touchant aux droits fondamentaux.
- Pour un système d’IA à haut risque, l’
Article 9impose un processus continu et itératif, revu de façon systématique, jusqu’à ce que le risque résiduel soit jugé acceptable. - La valeur d’un tel dispositif tient à ses artefacts durables (inventaire, registre des risques, cartographie des contrôles, preuves, validation du risque résiduel) qu’un auditeur ou un organisme notifié peut inspecter. Voir notre guide sur la conformité et la gestion des risques.
Qu’est-ce que la gestion des risques liés à l’IA ?
La gestion des risques liés à l’IA désigne l’activité continue qui consiste à identifier, évaluer, traiter et surveiller les risques propres aux systèmes d’intelligence artificielle, sur toute leur durée de vie, de la conception jusqu’au retrait. L’objet n’est pas le code isolé, mais le système complet : les données qui l’alimentent, le modèle qui produit ses sorties, l’interface par laquelle des personnes s’en servent, et les décisions qui en découlent. C’est cette chaîne, et non un composant unique, qui porte le risque. Ce programme se distingue nettement de la gestion des risques d’entreprise classique ou du risque de cybersécurité. Un système d’information traditionnel est déterministe : à entrée égale, sortie égale. Un système d’IA est probabiliste. Il produit des résultats plausibles plutôt que certains, et son comportement dépend de données d’entraînement dont la qualité, la représentativité et la provenance conditionnent directement la fiabilité. Deux propriétés aggravent encore la difficulté. D’abord, un modèle se dégrade dans le temps : la population qu’il traite s’écarte de celle sur laquelle il a été calibré, et sa performance dérive silencieusement. Ensuite, beaucoup de modèles restent opaques, ce qui complique l’explication d’une décision individuelle et la démonstration qu’elle est justifiée. Le risque de cybersécurité reste pertinent, mais il ne couvre qu’une partie du tableau. Un modèle parfaitement protégé contre les intrusions peut néanmoins produire une décision discriminatoire, halluciner une information ou porter atteinte à un droit fondamental. La gestion des risques liés à l’IA absorbe donc les préoccupations de sécurité et y ajoute des dimensions absentes du registre informatique habituel : équité, transparence, supervision humaine, respect de la vie privée dans l’usage des données. Elle s’inscrit naturellement dans une démarche plus large de gouvernance de l’IA, qui fournit le cadre d’autorité, les rôles et les responsabilités au sein desquels le traitement du risque prend son sens.
Pourquoi la gestion des risques liés à l’IA s’impose maintenant
La pression réglementaire n’est plus une perspective, c’est une obligation datée. L’Article 9 de l’EU AI Act exige des fournisseurs de systèmes à haut risque qu’ils établissent, mettent en œuvre, documentent et maintiennent un système de gestion des risques. Le texte ne se contente pas d’un exercice ponctuel : il demande un processus continu et itératif, revu de manière systématique tout au long du cycle de vie. Autrement dit, un audit annuel figé ne suffit plus. Pour les organisations concernées, cette exigence transforme la gestion des risques d’une bonne pratique facultative en une condition d’accès au marché européen. Notre guide opérationnel de l’EU AI Act détaille les échéances et le périmètre. L’enjeu opérationnel est tout aussi concret. Un modèle de scoring qui dérive, un assistant génératif qui produit une réponse erronée présentée avec assurance, un système de recommandation qui amplifie un biais : chacun de ces incidents a un coût réel, en litiges, en réputation et en reprise manuelle. Ces défaillances ne se manifestent pas au moment du déploiement, mais des mois plus tard, quand personne ne surveille plus le système de près. Le troisième facteur est la visibilité. Beaucoup d’organisations ne savent tout simplement pas combien de systèmes d’IA elles utilisent réellement. Des outils génératifs adoptés par des équipes métier sans validation, des fonctionnalités d’IA activées par défaut dans des logiciels existants, des intégrations passées inaperçues : ce Shadow AI échappe à tout contrôle précisément parce qu’il reste invisible. On ne peut pas gérer le risque d’un système que l’on ignore. La montée en puissance de réglementations sectorielles ou régionales, comme le Colorado AI Act, renforce encore l’urgence d’un inventaire fiable et d’un programme structuré plutôt que d’initiatives dispersées.
Les grandes catégories de risques liés à l’IA
Un programme efficace commence par une taxonomie claire. Quatre familles de risques couvrent l’essentiel des situations rencontrées, et chacune appelle des contrôles et des propriétaires distincts.
Risques liés aux données
Les données constituent la matière première du modèle, et leurs défauts se propagent à toutes ses sorties. La qualité vient en premier : des jeux incomplets, obsolètes ou mal étiquetés produisent des décisions mal calibrées. La provenance compte tout autant, car un modèle entraîné sur des données dont on ignore l’origine ou les droits d’usage expose l’organisation à un risque juridique et de conformité. S’ajoutent la protection de la vie privée, lorsque des données personnelles alimentent l’entraînement ou l’inférence, et l’empoisonnement des données (data poisoning), une manipulation délibérée du corpus d’entraînement destinée à corrompre le comportement du modèle. La conduite d’une analyse d’impact sur la protection des données constitue ici un point de contrôle structurant, en particulier lorsque le traitement touche des personnes physiques.
Risques liés aux modèles
Le modèle lui-même porte des risques intrinsèques. Le biais algorithmique produit des écarts de traitement systématiques entre groupes, souvent hérités des données ou du choix des variables. La dérive (drift) dégrade progressivement la performance à mesure que le monde réel s’écarte des conditions d’entraînement. Les modèles génératifs ajoutent le risque d’hallucination, c’est-à-dire la production d’affirmations fausses formulées avec une apparente certitude. Enfin, la robustesse mesure la résistance du modèle à des entrées inhabituelles ou hostiles. Documenter la performance à l’aide de référentiels d’évaluation fournit une base objective pour suivre ces dimensions dans le temps plutôt que de s’en remettre à une impression générale.
Risques opérationnels et de sécurité
Une fois en production, le système devient une cible et un maillon dont dépendent des processus métier. Les attaques adverses cherchent à tromper le modèle par des entrées soigneusement construites, à extraire ses paramètres ou à reconstruire ses données d’entraînement. Le catalogue MITRE ATLAS recense précisément ces techniques d’attaque contre les systèmes d’apprentissage automatique et sert de référence utile pour cadrer les menaces. À cela s’ajoutent le détournement d’usage (un système employé hors de sa finalité prévue) et les risques de disponibilité, lorsqu’une défaillance du modèle ou de son infrastructure interrompt un service dont dépendent des décisions.
Risques éthiques, juridiques et pour les droits fondamentaux
Cette dernière famille est celle que la gestion des risques informatiques classique ignore, et c’est précisément celle que la réglementation européenne place au centre. Un système peut être techniquement irréprochable et pourtant produire une discrimination, priver une personne d’une voie de recours ou opérer sans supervision humaine effective. La transparence en fait partie : la capacité à rendre une décision compréhensible, que l’explicabilité de l’IA vient outiller, conditionne à la fois la confiance et la conformité. Les modèles à usage général, examinés dans notre article sur l’IA à usage général, amplifient ces enjeux, car un même modèle sert simultanément des dizaines d’usages en aval, dont certains imprévus par son concepteur.
Le cycle de vie de la gestion des risques liés à l’IA
Les quatre catégories précédentes décrivent ce que l’on gère. Le cycle de vie décrit comment on le gère, étape après étape. Un principe le traverse : un même système parcourt ces quatre phases en boucle, et non une fois pour toutes.
Identifier et cartographier
Tout commence par un inventaire fiable des systèmes d’IA, sans lequel le reste est vain. Chaque système est décrit avec sa finalité prévue, son contexte d’usage, les données qu’il traite et, surtout, les personnes qu’il affecte. Cette cartographie détermine le niveau d’exigence : un modèle qui recommande des articles de blog et un modèle qui filtre des candidatures n’appellent pas la même vigilance. Identifier les parties prenantes touchées, en amont, permet de repérer les risques pour les droits fondamentaux avant qu’ils ne se matérialisent, plutôt qu’après un incident.
Évaluer et mesurer
Chaque risque identifié est ensuite estimé selon sa vraisemblance et son impact. Cette évaluation ne peut rester déclarative : elle s’appuie sur des tests et des mesures. Tests d’équité entre sous-populations, évaluation de la robustesse face à des entrées dégradées, mesure du taux d’erreur sur des cas représentatifs, contrôle de la stabilité dans le temps. L’objectif est de convertir une inquiétude vague en une valeur suivie, comparable d’une revue à l’autre. C’est cette rigueur de mesure que l’Article 9 vise lorsqu’il exige que les risques soient estimés et évalués, et que des tests servent à identifier les mesures appropriées.
Traiter et gérer
Vient ensuite le traitement : la mise en place de contrôles destinés à ramener le risque à un niveau acceptable. Réentraînement sur des données corrigées, ajout d’une supervision humaine sur les décisions sensibles, restriction du périmètre d’usage, journalisation renforcée, seuils de confiance. Aucun contrôle n’annule totalement le risque, et c’est là qu’intervient la notion de risque résiduel. Ce qui subsiste après traitement doit être explicitement évalué, puis jugé acceptable par une personne dûment habilitée. Cette validation formelle, tracée et datée, constitue l’un des artefacts qu’un auditeur recherchera en priorité.
Surveiller et réviser
Un système validé aujourd’hui ne l’est pas indéfiniment. La surveillance continue traque la dérive, compare la performance réelle aux seuils fixés et déclenche une réévaluation dès qu’un écart apparaît. Elle s’appuie sur un suivi de conformité des systèmes d’IA qui transforme la vigilance en processus régulier plutôt qu’en réaction improvisée. Lorsqu’un incident survient, un dispositif de réponse structuré, incluant le signalement des incidents liés à l’IA prévu par l’article 73 de l’EU AI Act, permet d’agir vite et de documenter. Cette phase de surveillance post-commercialisation referme la boucle : chaque enseignement réalimente l’identification et l’évaluation.
Cadres et normes
Trois références dominent aujourd’hui la discipline. Bien comprises, elles ne s’empilent pas : elles décrivent le même processus sous trois angles complémentaires, et un programme mature les fait converger vers un jeu de contrôles unique.
NIST AI RMF
Le NIST AI RMF 1.0, publié en 2023, organise la gestion des risques autour de quatre fonctions : Govern, Map, Measure et Manage, appliquées de manière itérative sur tout le cycle de vie de l’IA. La fonction Govern est transversale : elle installe la culture, les rôles et les responsabilités dans lesquels les trois autres s’exécutent. En pratique, les équipes démarrent par Map (cartographier le contexte et les risques), poursuivent avec Measure (analyser et quantifier), puis Manage (traiter et prioriser), le tout sous la supervision permanente de Govern. Le cadre a le mérite d’être volontaire et adaptable, ce qui en fait une base solide même hors du périmètre européen. Les documents de référence NIST AI 100-1 et le centre de ressources du NIST en détaillent chaque fonction. Notre guide opérationnel du NIST AI RMF en propose une lecture appliquée.
ISO/IEC 42001 et ISO/IEC 23894
La norme ISO/IEC 42001 définit un système de management de l’IA (AIMS) certifiable : elle décrit le « quoi » et le « où », c’est-à-dire la structure organisationnelle, les rôles et le dispositif d’amélioration continue. Elle ne décrit pas en détail le « comment » du traitement du risque : pour cela, elle s’appuie sur ISO/IEC 23894, qui fournit les lignes directrices du processus (identification, analyse, évaluation, traitement) sur l’ensemble du cycle de vie. Autrement dit, la ISO/IEC 42001 importe la ISO/IEC 23894 comme sa méthode de gestion du risque. Cette articulation est précieuse : elle donne à la fois un cadre certifiable, reconnu par les auditeurs, et une méthode de risque cohérente avec le vocabulaire ISO. La page officielle de la norme précise son périmètre, et notre article ISO 42001 expliqué en résume les exigences.
EU AI Act Article 9
L’Article 9 de l’EU AI Act impose aux fournisseurs de systèmes à haut risque un système de gestion des risques établi, mis en œuvre, documenté et maintenu comme un processus continu et itératif, revu de façon systématique sur toute la durée de vie. Le texte détaille les étapes attendues : identifier les risques pour la santé, la sécurité et les droits fondamentaux ; les estimer et les évaluer ; adopter des mesures de gestion ciblées ; s’assurer que le risque résiduel est jugé acceptable ; et recourir à des tests pour identifier les mesures les plus appropriées. Il précise aussi que ce dispositif peut être combiné avec les processus de gestion des risques déjà exigés par d’autres textes de l’Union. Le rapprochement de ces trois références est traité dans notre article de correspondance entre NIST, ISO 42001 et EU AI Act.
Le tableau suivant montre comment une même étape de programme se lit dans les trois référentiels.
| Étape du programme | NIST AI RMF | ISO/IEC 42001 + 23894 | EU AI Act Article 9 |
|---|---|---|---|
| Gouvernance et responsabilité | Govern | Clauses de leadership et de planification | Système de gestion des risques documenté et maintenu |
| Identifier et contextualiser | Map | Identification des risques (23894) | Identifier les risques pour la santé, la sécurité et les droits |
| Évaluer et mesurer | Measure | Analyse et évaluation (23894) | Estimer et évaluer les risques, tests |
| Traiter et accepter | Manage | Traitement (23894), contrôles de l’Annexe A | Adopter des mesures, risque résiduel acceptable |
| Surveiller et réviser | Govern et Manage | Clauses d’évaluation et d’amélioration | Processus continu, revue systématique |
Construire un programme de gestion des risques liés à l’IA : rôles, artefacts, contrôles
Un cadre reste théorique tant que trois éléments ne sont pas fixés : qui répond de quoi, quels documents font foi, et quels contrôles s’appliquent. Ces trois piliers transforment une intention en programme opérable. Côté rôles, la responsabilité doit être nominative. Un propriétaire porte chaque système d’IA et répond de son niveau de risque. Des propriétaires de contrôles sont chargés de la mise en œuvre et du maintien effectif de chaque mesure. Un valideur, distinct de celui qui a conçu le système, prononce l’acceptation du risque résiduel. Enfin, une instance de supervision (comité ou conseil) arbitre les cas sensibles et donne la ligne. Cette séparation évite qu’une même personne évalue, traite et valide son propre travail. Le cadre de gouvernance de l’IA fournit le modèle d’organisation dans lequel ces rôles s’articulent. Côté artefacts, cinq documents structurent la mémoire du programme et forment la matière que tout audit inspecte. L’inventaire des systèmes d’IA recense l’ensemble du parc. Le registre des risques consigne, pour chaque système, les risques identifiés, leur évaluation et leur statut. La cartographie des contrôles relie chaque risque aux mesures qui le traitent et aux exigences réglementaires correspondantes. Le recueil de preuves rassemble résultats de tests, journaux et attestations. La validation du risque résiduel, datée et signée, clôt chaque cycle. Ensemble, ces éléments soutiennent l’auditabilité de l’IA : la capacité à reconstituer, après coup, ce qui a été décidé et sur quelles bases. Côté contrôles, la logique est de mutualiser plutôt que de dupliquer. Un même contrôle (par exemple une revue de biais avant mise en production, ou une supervision humaine sur les décisions à fort impact) satisfait souvent une fonction du NIST AI RMF, une clause de la ISO/IEC 42001 et une exigence de l’Article 9 à la fois. Rattacher chaque contrôle à ses multiples origines réglementaires, une fois, évite les trois programmes parallèles qui épuisent les équipes sans réduire davantage le risque.
Les erreurs fréquentes en gestion des risques liés à l’IA
La première erreur consiste à traiter la gestion des risques comme un projet ponctuel plutôt que comme un processus. Une évaluation menée au lancement, puis rangée, ignore la propriété centrale des systèmes d’IA : ils changent après le déploiement. Sans surveillance continue, la dérive s’installe sans alerte. La deuxième erreur est de multiplier les cadres au lieu de les faire converger. Monter un chantier NIST AI RMF, un chantier ISO/IEC 42001 et un chantier EU AI Act en silos triple la charge documentaire sans améliorer la maîtrise réelle. La bonne pratique est un jeu de contrôles unique, rattaché à plusieurs exigences. La troisième erreur est de réduire le risque de l’IA à un problème de cybersécurité. Sécuriser un modèle ne l’empêche ni de discriminer, ni d’halluciner, ni de porter atteinte à un droit. Négliger les dimensions éthiques et de droits fondamentaux, c’est passer à côté de ce que la réglementation surveille en priorité. La quatrième erreur est de produire de la documentation qui ne prouve rien. Une politique déclarative sans preuves de tests, sans journaux et sans validation nominative du risque résiduel ne résiste pas à un audit. La traçabilité, condition de l’auditabilité de l’IA, ne se décrète pas, elle se construit au fil des cycles.
Comment AI Sigil opérationnalise la gestion des risques liés à l’IA
AI Sigil a été conçu pour les secteurs régulés, là où la gestion des risques doit produire des preuves inspectables et non de simples intentions. La plateforme relie l’inventaire des systèmes d’IA, le registre des risques, la cartographie des contrôles, le recueil de preuves et la validation du risque résiduel dans un même fil continu, aligné sur le NIST AI RMF, la ISO/IEC 42001 et l’Article 9. Chaque contrôle est rattaché à ses exigences d’origine, ce qui évite les programmes parallèles, et chaque décision reste tracée pour un auditeur ou un organisme notifié. Pour comprendre la différence entre une plateforme intégrée et un assemblage d’outils dispersés, voir notre comparatif des outils de gouvernance de l’IA.
Questions fréquentes
Quels sont les quatre grands types de risques liés à l’IA ? On les regroupe en quatre familles. Les risques liés aux données concernent la qualité, la provenance, la vie privée et l’empoisonnement du corpus d’entraînement. Les risques liés aux modèles couvrent le biais, la dérive, l’hallucination et la robustesse. Les risques opérationnels et de sécurité englobent les attaques adverses, le détournement d’usage et les défaillances de disponibilité. Enfin, les risques éthiques, juridiques et pour les droits fondamentaux portent sur la discrimination, la transparence et la supervision humaine. Cette taxonomie sert de point de départ à l’inventaire des risques d’un système donné.
Comment l’IA est-elle utilisée dans la gestion des risques ? L’IA intervient à deux niveaux. D’une part, elle est l’objet à gérer : ce sont ses propres risques que le programme traite. D’autre part, elle peut soutenir le processus, par exemple en détectant des anomalies dans les journaux, en signalant une dérive de performance ou en aidant à trier un grand volume de systèmes à évaluer. Cette assistance reste un appui, jamais un substitut à la responsabilité humaine : la validation du risque résiduel et l’acceptation des décisions sensibles restent le fait de personnes nommément désignées.
Qu’est-ce que la « règle des 30 % » en gestion des risques liés à l’IA ? Il n’existe aucune « règle des 30 % » reconnue en gestion des risques liés à l’IA. Ni le NIST AI RMF, ni la ISO/IEC 42001, ni la ISO/IEC 23894, ni l’Article 9 de l’EU AI Act ne fixent un tel seuil. Cette formule circule parfois comme un raccourci commode, mais elle n’a aucune valeur normative et ne doit pas orienter une décision de conformité. Les référentiels reposent sur l’évaluation contextuelle de la vraisemblance et de l’impact, puis sur un jugement d’acceptabilité du risque résiduel, et non sur un pourcentage universel.
En quoi la gestion des risques liés à l’IA diffère-t-elle du risque de cybersécurité ? La cybersécurité protège la confidentialité, l’intégrité et la disponibilité des systèmes. Elle reste nécessaire, mais insuffisante face à l’IA. Un modèle parfaitement sécurisé peut produire une décision discriminatoire, halluciner une information ou fonctionner sans supervision humaine effective. La gestion des risques liés à l’IA intègre les préoccupations de sécurité et y ajoute l’équité, la transparence, le respect de la vie privée dans l’usage des données et la protection des droits fondamentaux. Les deux disciplines se recouvrent, mais la seconde couvre un périmètre plus large.
Quel cadre faut-il adopter pour gérer les risques liés à l’IA ? Le choix dépend de l’objectif, mais les trois grandes références sont complémentaires plutôt que concurrentes. Le NIST AI RMF offre une méthode volontaire et adaptable. La ISO/IEC 42001 apporte un système de management certifiable, adossé à la ISO/IEC 23894 pour le processus de risque. L’Article 9 de l’EU AI Act est une obligation légale pour les systèmes à haut risque commercialisés dans l’Union. Une organisation soumise à l’EU AI Act gagnera à construire un programme unique qui satisfait les trois à la fois, comme le montre notre correspondance entre référentiels.
Qui est responsable de la gestion des risques liés à l’IA dans l’entreprise ? La responsabilité est partagée mais nominative. Un propriétaire répond de chaque système et de son niveau de risque. Des propriétaires de contrôles assurent la mise en œuvre des mesures. Un valideur, indépendant de la conception, prononce l’acceptation du risque résiduel. Une instance de supervision arbitre les cas sensibles. La direction générale porte la responsabilité ultime, notamment au regard de l’Article 9, qui suppose un dispositif documenté et maintenu dans la durée. Cette répartition claire évite qu’un risque reste sans propriétaire identifié.
Conclusion
La gestion des risques liés à l’IA n’est ni un document ni une case à cocher : c’est un programme vivant, responsabilisé, qui fait tourner un même cycle (identifier, évaluer, traiter, surveiller) sur l’ensemble des systèmes d’IA de l’organisation. Sa force vient de la convergence : plutôt que de mener en parallèle un chantier NIST AI RMF, un chantier ISO/IEC 42001 et un chantier EU AI Act, un programme mature les fait alimenter un jeu de contrôles unique, avec des propriétaires clairs et des preuves inspectables. Ce sont ces artefacts durables, inventaire, registre des risques, cartographie des contrôles, preuves et validation du risque résiduel, qui distinguent une conformité affichée d’une maîtrise réelle. Les intégrer dans une démarche cohérente de gouvernance de l’IA est le moyen le plus sûr de tenir la distance, à mesure que la réglementation et les usages se resserrent.