Système de gestion des risques de l’IA : guide de l’article 9

L’essentiel

• L’article 9 du règlement sur l’IA impose un système de gestion des risques pour chaque système d’IA à haut risque. Ce n’est pas une évaluation ponctuelle : c’est un processus itératif continu qui couvre tout le cycle de vie, de la conception initiale à l’exploitation après mise sur le marché, jusqu’à la mise hors service.
• Le système de gestion des risques doit identifier et analyser les risques connus et raisonnablement prévisibles, estimer les risques nés de l’usage conforme à la destination et de la mauvaise utilisation raisonnablement prévisible, et intégrer les données de surveillance après mise sur le marché dans une boucle de rétroaction continue.
• Le risque résiduel, celui qui demeure après atténuation, doit être jugé acceptable au regard des bénéfices du système. Les fournisseurs communiquent ces risques résiduels aux déployeurs par la notice d’utilisation.
• Les essais ne sont ni facultatifs ni cosmétiques. L’article 9, paragraphes 6 et 8, exige des essais au regard d’indicateurs et de seuils probabilistes préalablement définis, le cas échéant des essais en conditions réelles, et une attention particulière aux personnes de moins de 18 ans et aux groupes vulnérables.
• Les exigences de l’article 9 se recoupent largement avec ISO 42001 (clause 6.1) et le NIST AI RMF (fonctions GOVERN et MAP), ce qui permet de construire un dispositif unique plutôt que trois silos.
• Les obligations à haut risque de l’annexe III, y compris l’article 9, s’appliquent à compter du 2 décembre 2027 (reportées du 2 août 2026 par le Digital Omnibus, règlement (UE) 2026/1744, en vigueur depuis le 27 juillet 2026). Pour les systèmes de l’annexe I, l’échéance est le 2 août 2028. Les obligations de transparence de l’article 50 restent au 2 août 2026. Le non-respect peut entraîner des amendes jusqu’à 15 millions d’euros ou 3 % du chiffre d’affaires annuel mondial.
• Utilisez l’outil d’évaluation au titre du règlement sur l’IA de Legalithm pour déterminer si votre système d’IA est à haut risque et quelles obligations de gestion des risques s’appliquent.

Si vous ne lisez qu’un seul article du règlement sur l’IA, lisez l’article 9. Le système de gestion des risques est le socle sur lequel repose chaque autre obligation à haut risque. La documentation technique vous demande de décrire votre processus de gestion des risques. La gouvernance des données s’appuie sur les risques que vous avez identifiés. Le contrôle humain doit être calé sur les risques résiduels. La surveillance après mise sur le marché alimente le système de gestion des risques. Tous les chemins mènent à l’article 9, et en reviennent.

Pourtant, c’est là que beaucoup d’organisations trébuchent, en traitant la gestion des risques comme une case à cocher plutôt que comme le processus vivant et itératif que l’article 9 exige. Ce guide décortique chaque paragraphe, traduit les exigences en gestes concrets, les relie aux normes internationales, et vous donne de quoi construire un système de gestion des risques défendable.

Pourquoi l’article 9 est l’épine dorsale de la conformité

Une obligation fondatrice pour toute IA à haut risque

Si votre système d’IA tombe dans la catégorie à haut risque, que ce soit par l’annexe I (composant de sécurité d’un produit réglementé) ou par l’annexe III (cas d’usage autonomes : identification biométrique, infrastructures critiques, emploi, solvabilité, services répressifs), l’article 9 s’applique. Pas sûr que votre système y entre ? Notre guide de classification déroule l’analyse, et l’évaluation au titre du règlement sur l’IA de Legalithm peut vous répondre en quelques minutes.

L’article 9 est la première obligation de fond de la section 2 (articles 8 à 15). Vous ne pouvez pas satisfaire sérieusement la gouvernance des données, la transparence, l’exactitude, la robustesse ou le contrôle humain tant que vous n’avez pas d’abord identifié les risques que votre système fait peser.

Continu, itératif, et déployé sur tout le cycle de vie

L’article 9, paragraphe 2, dispose que le système de gestion des risques « s’entend comme étant un processus itératif continu qui est planifié et se déroule sur l’ensemble du cycle de vie d’un système d’IA à haut risque et qui doit périodiquement faire l’objet d’un examen et d’une mise à jour méthodiques ». Cela écarte les évaluations ponctuelles, les documents figés produits pour l’évaluation de la conformité puis archivés, et les revues déclenchées seulement par un incident. L’article 9 exige un processus planifié (activités, calendrier, responsabilités), itératif (chaque cycle informe le suivant) et déployé sur tout le cycle de vie (de la conception à la mise hors service). Les fabricants de dispositifs médicaux travaillent depuis des décennies sous des dispositifs comparables (ISO 14971) ; l’article 9 y fait entrer l’IA.

Application à compter de décembre 2027

Les obligations de l’article 9 deviennent opposables le 2 décembre 2027 pour les systèmes de l’annexe III, reportées du 2 août 2026 par le Digital Omnibus (règlement (UE) 2026/1744, en vigueur depuis le 27 juillet 2026). Pour les systèmes de l’annexe I, l’échéance est le 2 août 2028. Les fournisseurs qui mettent un système d’IA à haut risque sur le marché de l’Union à compter de ces dates doivent disposer d’un système de gestion des risques pleinement mis en œuvre. Les systèmes déjà sur le marché doivent être mis en conformité. Pour l’ensemble des dates, voir notre calendrier du règlement sur l’IA.

L’article 9, les exigences juridiques expliquées

Établir un système de gestion des risques (article 9, paragraphe 1)

L’article 9, paragraphe 1, dispose : « Un système de gestion des risques est établi, mis en œuvre, documenté et tenu à jour en ce qui concerne les systèmes d’IA à haut risque. » Quatre verbes, quatre obligations distinctes. Le système doit être formellement créé, avec une gouvernance et une méthode (établi), effectivement exécuté plutôt que décrit dans une politique (mis en œuvre), consigné avec assez de détail pour un auditeur ou une autorité (documenté), et actualisé à mesure que le système et son environnement évoluent (tenu à jour).

Le paragraphe 2 ajoute l’examen et la mise à jour méthodiques et périodiques : les actualisations ne peuvent pas être sporadiques ni informelles ; elles suivent une cadence et une méthode définies.

Identification et analyse des risques connus et prévisibles (article 9, paragraphe 2, point a))

L’article 9, paragraphe 2, point a), exige « l’identification et l’analyse des risques connus et raisonnablement prévisibles que le système d’IA à haut risque peut poser pour la santé, la sécurité ou les droits fondamentaux lorsque le système d’IA à haut risque est utilisé conformément à sa destination ».

Les risques connus sont ceux que l’état de la technique documente, que les essais ont observés, ou que des versions antérieures ont signalés. Les risques raisonnablement prévisibles sont ceux qu’un professionnel compétent anticiperait, même s’ils n’ont pas encore été observés.

Le champ couvre la santé, la sécurité et les droits fondamentaux : l’identification ne s’arrête pas aux modes de défaillance technique ; elle inclut les atteintes à la vie privée, à la non-discrimination, à la liberté d’expression et aux autres droits de la Charte. L’analyse d’impact sur les droits fondamentaux (FRIA) complète cette analyse pour certains déployeurs.

Estimation et évaluation des risques nés de la destination et de la mauvaise utilisation prévisible (article 9, paragraphe 2, point b))

L’article 9, paragraphe 2, point b), exige « l’estimation et l’évaluation des risques susceptibles d’apparaître lorsque le système d’IA à haut risque est utilisé conformément à sa destination et dans des conditions de mauvaise utilisation raisonnablement prévisible ». La destination est le but documenté pour lequel le système est conçu. La mauvaise utilisation raisonnablement prévisible recouvre des usages non voulus mais prévisibles au vu du comportement humain et des capacités du système. Une IA de présélection à l’embauche, par exemple, peut être détournée pour filtrer des candidats sur des caractéristiques protégées corrélées à des critères légitimes.

Cette exigence vous force à poser la question : que se passe-t-il lorsque des personnes s’en servent d’une manière que nous n’avons pas voulue, mais que nous aurions dû prévoir ? Omettre la mauvaise utilisation prévisible est l’un des écarts de conformité les plus fréquents.

Évaluation des risques à partir des données de surveillance après mise sur le marché (article 9, paragraphe 2, point c))

L’article 9, paragraphe 2, point c), crée une boucle formelle entre la surveillance après mise sur le marché et la gestion des risques : « l’évaluation d’autres risques susceptibles d’apparaître, sur la base de l’analyse des données recueillies au moyen du système de surveillance après commercialisation visé à l’article 72 ». Les données réelles sur la performance, les défaillances, les presque-incidents et les incidents doivent refluer dans le système de gestion des risques : risques non identifiés avant la mise sur le marché, risques connus qui se manifestent autrement que prévu, ou risques nouveaux nés d’un changement d’environnement (dérive de distribution). La surveillance après mise sur le marché est un intrant de la gestion des risques, pas une obligation parallèle.

Adoption de mesures appropriées et ciblées (article 9, paragraphe 2, point d))

L’article 9, paragraphe 2, point d), exige « l’adoption de mesures appropriées et ciblées de gestion des risques, conçues pour répondre aux risques identifiés ». Les mesures doivent être proportionnées (un risque catastrophique appelle une atténuation robuste), spécifiques (chaque risque identifié a une mesure correspondante ; « nous surveillerons le système » ne suffit pas) et effectives (elles réduisent réellement le risque, au lieu d’en donner l’apparence).

Le règlement ne prescrit pas de mesures types. Cette souplesse pèse sur le fournisseur : c’est à lui de justifier ses choix si une autorité de surveillance du marché les conteste.

Risque résiduel, ce qui est acceptable (article 9, paragraphes 3 à 5)

Les paragraphes 3 à 5 posent trois principes décisifs :

1. Le champ est borné. Le paragraphe 3 précise que les risques visés sont seulement ceux qui peuvent être raisonnablement atténués ou éliminés par la conception, le développement, ou la fourniture d’informations techniques appropriées.
2. Les interactions comptent. Le paragraphe 4 exige de tenir dûment compte des effets et de l’interaction possibles résultant de l’application combinée des exigences de la section 2, afin de prévenir les risques plus efficacement tout en parvenant à un bon équilibre.
3. Le risque résiduel doit être acceptable. Le paragraphe 5 dispose que « le risque résiduel pertinent associé à chaque danger ainsi que le risque résiduel global lié aux systèmes d’IA à haut risque sont jugés acceptables ». Après toutes les atténuations, le risque qui reste doit l’être pour chaque danger et pour le système dans son ensemble.

L’acceptabilité se juge en pesant le risque résiduel contre les bénéfices, l’état de la technique, les attentes sociétales et les normes harmonisées pertinentes. Nous y revenons plus bas.

Le paragraphe 5 ajoute la hiérarchie d’action : éliminer ou réduire les risques autant que la technologie le permet par une conception et un développement appropriés ; mettre en œuvre, le cas échéant, des mesures d’atténuation et de contrôle pour les risques impossibles à éliminer ; fournir aux déployeurs les informations requises par l’article 13 et, éventuellement, une formation. Il est dûment tenu compte des connaissances techniques, de l’expérience, de l’éducation et de la formation pouvant être attendues du déployeur, ainsi que du contexte prévisible d’utilisation.

Essais pour garantir un fonctionnement conforme à la destination (article 9, paragraphes 6 à 8)

Quatre exigences d’essai se dégagent des paragraphes 6 à 8 :

• Orientés vers les mesures, les essais visent à déterminer les mesures de gestion des risques les plus appropriées et les plus ciblées, pas seulement à démontrer une performance technique (paragraphe 6).
• Fondés sur des critères, ils sont effectués « sur la base d’indicateurs et de seuils probabilistes préalablement définis, qui sont adaptés à la destination » (paragraphe 8), et non sur des bancs d’essai choisis après coup.
• Tout au long du développement, « selon les besoins, à tout moment pendant le processus de développement et, en tout état de cause, avant leur mise sur le marché ou leur mise en service » (paragraphe 8).
• En conditions réelles lorsque c’est pertinent, les procédures d’essai peuvent comprendre des essais en conditions réelles conformément à l’article 60 (paragraphe 7) : c’est une faculté encadrée, pas une obligation automatique.

Pour le détail des méthodes, y compris l’examen des biais, voir notre guide des essais de biais et d’équité.

Gestion des risques pour des populations particulières (article 9, paragraphe 9)

L’article 9, paragraphe 9, dispose que, lors de la mise en œuvre du système de gestion des risques, les fournisseurs « prennent en considération la probabilité que, compte tenu de sa destination, le système d’IA à haut risque puisse avoir une incidence négative sur des personnes âgées de moins de 18 ans et, le cas échéant, sur d’autres groupes vulnérables ».

Conséquences pratiques :

• Les systèmes d’IA utilisés dans l’éducation doivent évaluer les risques propres au développement cognitif des enfants, à leur sensibilité à la manipulation, et à la protection des données (voir notre guide pour l’éducation).
• Les systèmes d’IA utilisés dans les soins doivent évaluer les risques propres aux patients, y compris les personnes âgées, les personnes handicapées, et celles dont la maîtrise des questions de santé est limitée.
• Les systèmes d’IA utilisés dans l’emploi doivent évaluer les risques pour les groupes qui subissent des désavantages structurels dans les processus d’embauche.

Les jeux d’essai et les scénarios doivent refléter ces populations, pas seulement la personne « moyenne ».

Le cycle de vie de la gestion des risques

L’article 9 décrit un processus itératif continu. En pratique, on peut le structurer en cinq phases alignées sur le cycle de vie du système. Le tableau ci-dessous relie chaque phase aux exigences de l’article 9.

Phase 1, identification des risques (avant le développement)

Avant d’écrire une ligne de code ou de choisir un jeu d’entraînement, cette phase dresse le paysage des risques. Activités :

• Analyse de contexte. Quelle est la destination du système d’IA ? Qui sont les déployeurs prévus ? Qui sont les personnes concernées ? Dans quel environnement le système fonctionnera-t-il ?
• Cartographie réglementaire. Quelles règles sectorielles s’ajoutent au règlement sur l’IA ? (MDR pour les dispositifs médicaux, directive sur le crédit aux consommateurs pour l’évaluation de la solvabilité, RGPD pour les données à caractère personnel). Voir notre liste de contrôle 2026 pour une vue d’ensemble.
• Identification des dangers. Quelles catégories de préjudice le système peut-il causer ? Santé et sécurité, droits fondamentaux (discrimination, vie privée, liberté d’expression), impacts économiques, impacts environnementaux.
• Consultation des parties prenantes. Associez des experts de domaine, des déployeurs potentiels, des communautés concernées et un conseil juridique, pour faire émerger des risques que les équipes internes ne voient pas.

Phase 2, analyse et évaluation (développement)

Pendant le développement, les risques identifiés sont analysés en profondeur :

• Estimation de la vraisemblance. Quelle est la probabilité que chaque risque se matérialise ? Appuyez-vous sur l’analyse technique, les essais empiriques, les données historiques de systèmes comparables, et le jugement d’experts.
• Estimation de la gravité. Si le risque se matérialise, quelle serait la gravité ? Tenez compte du scénario le plus probable et du pire cas.
• Niveau de risque. Combinez vraisemblance et gravité (voir la matrice plus bas).
• Analyse de la mauvaise utilisation prévisible. Allez au-delà de la destination pour modéliser les détournements. Quels sont les incitations ? Quelles sont les conséquences ?

Phase 3, traitement et atténuation (avant le déploiement)

Pour chaque risque qui dépasse le seuil d’acceptation défini, concevez et mettez en œuvre des mesures :

• Élimination. Le risque peut-il être éliminé en changeant la conception ? (par exemple retirer une fonctionnalité qui crée un risque injustifiable)
• Réduction. Peut-on le ramener à un niveau acceptable ? (validation des entrées, contrainte des sorties, seuils de confiance)
• Transfert. Peut-on le confier à une instance mieux armée pour le gérer ? (examen humain au-delà d’un seuil de confiance, en lien direct avec le contrôle humain de l’article 14)
• Surveillance. Pour les risques qui ne peuvent être ni éliminés ni suffisamment réduits, une surveillance continue peut-elle détecter le moment où ils commencent à se matérialiser ?

Le paragraphe 4 exige de considérer les interactions entre mesures. Un seuil de confiance peut réduire les faux positifs et augmenter les faux négatifs. Un examen humain peut réduire les erreurs automatisées et introduire un biais humain. Documentez ces arbitrages.

Phase 4, appréciation du risque résiduel (déploiement)

Avant le déploiement, appréciez le risque qui demeure après toutes les mesures :

• Risque résiduel par danger. Pour chaque danger identifié, quel niveau reste-t-il après atténuation ?
• Risque résiduel global. Tous dangers confondus, y compris les interactions, quel est le profil global ?
• Jugement d’acceptabilité. Le risque résiduel est-il acceptable, au vu des bénéfices, de l’état de la technique et des attentes sociétales ?
• Communication. Tous les risques résiduels doivent être documentés et communiqués aux déployeurs par la notice d’utilisation, comme l’exige l’article 13.

Phase 5, surveillance après mise sur le marché et rétroaction (exploitation)

Une fois le système en service, le cycle continue :

• Suivi de la performance. Suivez les indicateurs clés au regard des métriques et seuils du plan de gestion des risques.
• Suivi des incidents. Enregistrez et analysez incidents, presque-incidents, réclamations et anomalies.
• Analyse des données. Utilisez les données après mise sur le marché pour valider ou réviser les estimations. Les risques se matérialisent-ils à la fréquence et à la gravité prévues ?
• Boucle de rétroaction. Réinjectez les constats dans la phase 1, ce qui déclenche un nouveau cycle d’identification. C’est le mécanisme par lequel l’article 9, paragraphe 2, point c), est satisfait.

Pour mettre en place ces dispositifs, voir notre guide de la surveillance après mise sur le marché et du signalement d’incidents.

Identification et analyse des risques, en pratique

Risques connus et risques prévisibles

Les risques connus figurent dans la littérature, les essais, les versions antérieures, les orientations des autorités et les normes harmonisées. Les risques raisonnablement prévisibles n’ont pas encore été observés sur votre système, mais on peut les anticiper à partir de l’architecture, des données et du contexte de déploiement : ceux qu’un professionnel compétent attendrait au vu de l’état des connaissances.

Le critère est « raisonnablement prévisible », pas « tout risque concevable ». On ne vous demande pas de prévoir les cygnes noirs ; on vous demande la prévoyance d’un fournisseur diligent.

Destination et mauvaise utilisation raisonnablement prévisible

La destination est nette (le but documenté). La mauvaise utilisation raisonnablement prévisible demande plus d’imagination disciplinée. Schémas fréquents :

• Surconfiance, traiter les recommandations de l’IA comme des décisions définitives.
• Glissement de périmètre, utiliser le système au-delà de sa destination (appliquer un outil de présélection à une autre population).
• Manipulation adverse, façonner les entrées pour exploiter les faiblesses.
• Contournement des garanties, désactiver des fonctions de sécurité pour le débit ou le confort.

Documentez les scénarios de destination et de mauvaise utilisation, avec risques et mesures pour chacun.

Techniques d’identification des risques

Aucune technique ne suffit seule. La pratique sérieuse en combine plusieurs :

Matrice de risques, vraisemblance contre gravité

Une matrice donne un cadre structuré pour classer les risques identifiés. Le règlement ne prescrit pas de format ; une matrice 5×5 est largement utilisée :

Les risques « Élevé » ou « Critique » doivent avoir des mesures d’atténuation documentées. Les risques « Moyen » doivent avoir des mesures, ou une justification écrite de l’acceptation. Pour la gravité, tenez compte de toutes les dimensions : santé et sécurité (préjudice physique ou psychologique), droits fondamentaux (discrimination, atteinte à la vie privée, déni d’un procès équitable), économique (perte financière, déni de service) et sociétale (érosion de la confiance, discrimination systémique).

Risque résiduel, l’exigence la plus mal comprise

Ce que « acceptable » veut dire

L’article 9, paragraphe 5, exige que le risque résiduel soit « jugé acceptable ». Cette formule crée plus de confusion que toute autre de l’article 9, parce que le règlement ne définit pas « acceptable » par un seuil chiffré. C’est voulu : l’acceptabilité dépend du contexte.

Le jugement pèse :

1. Le risque résiduel lui-même. Quelle vraisemblance et quelle gravité de préjudice restent après les mesures ?
2. Les bénéfices du système d’IA. Quels résultats positifs pour les déployeurs, les personnes concernées et la société ? Plus le bénéfice est grand, plus un risque résiduel peut être tolérable.
3. L’état de la technique. Quels niveaux de risque sont atteignables avec les techniques disponibles ? Un risque que vous pourriez encore réduire par des techniques disponibles non mises en œuvre est plus difficile à justifier.
4. Les attentes sociétales. Quel niveau les personnes et les autorités attendent-elles et tolèrent-elles pour ce type d’application ? Les attentes sont plus hautes lorsque des groupes vulnérables ou des droits fondamentaux sont en jeu.
5. Les alternatives disponibles. Existe-t-il d’autres approches, y compris sans IA, qui atteignent les mêmes bénéfices avec moins de risque ?

Peser les bénéfices et les risques

L’exercice n’est pas purement mathématique ; il exige un jugement documenté, étayé par des preuves. Pour chaque risque résiduel : (1) consigner le niveau après atténuation, (2) expliquer pourquoi on ne peut pas le réduire davantage, (3) documenter les bénéfices qui justifient l’acceptation, (4) comparer à l’état de la technique et aux normes harmonisées, et (5) enregistrer le jugement final, avec motifs et identité du décideur.

Exigences de documentation

L’appréciation du risque résiduel fait partie de la documentation technique de l’annexe IV. Elle comprend : un registre des risques avec niveaux avant et après atténuation, la description de chaque mesure et de son efficacité, des énoncés de risque résiduel par danger, une appréciation d’ensemble, le jugement d’acceptabilité motivé, et les qualifications des décideurs.

Communication aux déployeurs

Les risques résiduels doivent être communiqués aux déployeurs par la notice d’utilisation (article 13) : nature et niveau des risques résiduels, conditions dans lesquelles ils peuvent s’élever, mesures recommandées côté déployeur, et limites d’usage. Les déployeurs doivent en tenir compte pour leur analyse d’impact sur les droits fondamentaux et leurs mesures de contrôle humain.

Exigences d’essai au titre de l’article 9

Avant la mise sur le marché, et tout au long du cycle de vie

L’essai n’est pas une porte que l’on franchit une fois. L’article 9, paragraphe 8, dispose que les tests sont effectués « selon les besoins, à tout moment pendant le processus de développement et, en tout état de cause, avant leur mise sur le marché ou leur mise en service ». Cela veut dire :

• Pendant le développement : essais incrémentaux à mesure que le système est construit, entraîné et affiné.
• Avant la mise sur le marché : validation complète au regard de l’ensemble des indicateurs et seuils préalablement définis.
• Après le déploiement : essais déclenchés par des mises à jour, un changement d’environnement, ou des constats de la surveillance après mise sur le marché.

Au regard d’indicateurs préalablement définis

L’article 9, paragraphe 8, exige des tests « sur la base d’indicateurs et de seuils probabilistes préalablement définis ». Vous ne pouvez pas lancer des essais puis choisir les métriques flatteuses. Les indicateurs et les seuils de réussite ou d’échec doivent figurer dans le plan de gestion des risques avant le début des essais. « Exactitude supérieure à 90 % » est un seuil ; « une bonne exactitude » n’en est pas un.

Indicateurs fréquents :

Pour un examen approfondi des indicateurs d’équité et des essais de biais, voir notre guide des essais de biais et d’équité.

Essais en conditions réelles

Les essais en laboratoire sur des jeux soigneusement composés sont nécessaires, mais insuffisants. Les essais en conditions réelles devraient inclure des données d’entrée diverses reflétant les populations réelles, les cas limites identifiés lors de l’identification des risques, les contraintes opérationnelles (volume élevé, données bruitées), et la variabilité de comportement entre déployeurs experts et novices.

Essais spécifiques pour les enfants et les groupes vulnérables

Lorsqu’un système est susceptible d’affecter des personnes de moins de 18 ans ou d’autres groupes vulnérables, l’article 9, paragraphe 9, impose d’en tenir compte. En pratique : jeux d’essai dédiés représentant ces populations, indicateurs de performance mesurés séparément (pas seulement en agrégat), essais de scénarios simulant l’interaction de personnes vulnérables avec le système, et appréciation d’impact reconnaissant qu’une même erreur peut être plus grave pour un enfant que pour un adulte.

Relier l’article 9 à ISO 42001 et au NIST AI RMF

Les organisations qui visent ISO/IEC 42001 ou le NIST AI RMF y trouveront un recoupement substantiel avec l’article 9. S’appuyer sur l’existant réduit l’effort et évite les trous. Voir notre table de correspondance pour une cartographie complète.

Correspondance avec ISO 42001, clause 6.1

ISO/IEC 42001 (système de management de l’IA) traite le risque à la clause 6.1, actions face aux risques et opportunités. La correspondance :

Écart clé : ISO 42001 n’exige pas aussi explicitement des essais au regard d’indicateurs et de seuils probabilistes préalablement définis que l’article 9, paragraphe 8. Les organisations qui s’appuient uniquement sur ISO 42001 doivent compléter leur dispositif d’essai.

Pour la mise en œuvre d’ISO 42001, voir notre guide de certification ISO 42001.

NIST AI RMF, fonctions GOVERN et MAP

Le NIST AI RMF organise la gestion des risques en quatre fonctions : GOVERN, MAP, MEASURE et MANAGE. Correspondance avec l’article 9 :

Écart clé : le NIST AI RMF est volontaire et ne prescrit pas d’exigences de documentation. Les organisations qui s’en servent comme base doivent veiller à ce que leur documentation satisfasse les exigences prescriptives de l’article 9 et de l’annexe IV.

Efficacité d’une approche combinée

Pour les organisations présentes à la fois dans l’Union et aux États-Unis : utilisez ISO 42001 comme ossature de management (gouvernance Plan-Do-Check-Act), le NIST AI RMF pour la méthode d’identification (sous-catégories MAP), et superposez les spécificités de l’article 9 (indicateurs préalablement définis et seuils probabilistes, jugements explicites d’acceptabilité du risque résiduel, essais visant les populations vulnérables, documentation de l’annexe IV). Cela évite les doublons tout en couvrant les trois référentiels. Pour le détail, voir notre table de correspondance.

Construire votre système de gestion des risques, pas à pas

Les sept étapes ci-dessous offrent une démarche concrète pour l’article 9. À lire avec notre guide de gouvernance de l’IA.

Étape 1, définir le périmètre et le contexte

Avant d’analyser les risques, bornez le système de gestion des risques :

• Description du système d’IA. Que fait-il ? Quelles sont ses entrées, ses sorties, sa destination ?
• Déployeurs prévus. Qui fera fonctionner le système ? Quel est leur niveau de formation et d’expertise de domaine ?
• Personnes concernées. Qui est touché par les sorties ? Certaines personnes concernées sont-elles vulnérables ?
• Contexte de déploiement. Dans quel environnement, quelle géographie, quel contexte réglementaire ?
• Frontières du système. Où s’arrête le système d’IA et où commence son environnement ? Quels systèmes en amont et en aval interagissent avec lui ?

Consignez ce périmètre dans un plan de gestion des risques, le document qui gouverne toutes les activités suivantes.

Étape 2, établir les critères et les seuils

Définissez les critères d’évaluation et de classement :

• Schéma de classement. Définissez les niveaux (par exemple Faible, Moyen, Élevé, Critique) et les critères de chacun.
• Échelle de vraisemblance. Définissez ce que « rare », « improbable », « possible », « probable » et « quasi certain » signifient pour votre système, avec des plages quantitatives lorsque c’est possible.
• Échelle de gravité. Définissez les niveaux pour chaque catégorie d’impact (santé, sécurité, droits fondamentaux, économique).
• Seuils d’acceptation. Définissez le niveau à partir duquel l’atténuation est obligatoire, et celui à partir duquel le système ne doit pas être déployé.
• Seuils d’indicateurs. Définissez les indicateurs de performance, d’équité et de robustesse et leurs seuils de réussite ou d’échec, comme l’exige l’article 9, paragraphe 8.

Étape 3, mener un atelier d’identification

Réunissez une équipe transverse, scientifiques des données, ingénieurs, experts de domaine, conseil juridique, éthiciens et représentants des personnes concernées, pour identifier les risques par FMEA, modélisation des menaces, essais de scénarios et revue de littérature. Le livrable est un registre des risques qui consigne chaque risque avec sa description, sa source, sa catégorie et une première appréciation. Les ateliers structurés doivent couvrir les modes de défaillance de chaque composant, les scénarios de destination et de mauvaise utilisation, et les risques propres aux groupes vulnérables.

Étape 4, analyser et évaluer les risques

Pour chaque risque du registre :

• Estimez la vraisemblance à partir des preuves disponibles (analyse technique, données d’essai, littérature, jugement d’experts).
• Estimez la gravité pour chaque catégorie d’impact.
• Appliquez la matrice pour déterminer le niveau.
• Priorisez le traitement selon le niveau et les seuils de l’étape 2.

Documentez la méthode d’analyse, les sources, les hypothèses et les incertitudes pour chaque risque. Cette documentation est essentielle pour l’annexe IV et pour défendre votre analyse devant une autorité.

Étape 5, concevoir les mesures d’atténuation

Pour chaque risque qui dépasse le seuil d’acceptation :

• Identifiez des mesures candidates. Plusieurs options, pas une seule.
• Évaluez l’efficacité. Pour chaque candidate, estimez de combien elle réduit le risque.
• Évaluez la faisabilité. Faisabilité technique, coût, effet sur la performance, interaction avec d’autres mesures.
• Sélectionnez. Choisissez la combinaison qui ramène le plus efficacement le risque à un niveau acceptable, en tenant compte des interactions.
• Définissez les exigences de mise en œuvre. Pour chaque mesure, précisez ce qui doit être construit, configuré, documenté ou communiqué.

Étape 6, mettre en œuvre et documenter

Intégrez les mesures dans le système (validation des entrées, contraintes de sortie, seuils de confiance, atténuation des biais, déclencheurs d’examen humain) et établissez les processus opérationnels d’appui (procédures de contrôle, signalement d’incidents, cycles de revue). Mettez à jour le plan de gestion des risques, le registre, la documentation technique et la notice d’utilisation. La documentation doit suffire à un organisme notifié ou à une autorité de surveillance du marché pour en juger l’adéquation.

Étape 7, surveiller et itérer

Après le déploiement, mettez en place télémétrie, journalisation, retours des déployeurs et signalement d’incidents. Analysez régulièrement les données au regard des indicateurs et seuils préalablement définis. Définissez des déclencheurs de revue ad hoc (franchissement de seuils de gravité, échec d’un indicateur, mises à jour du système, changements réglementaires). Actualisez le registre avec les risques nouvellement identifiés et les estimations révisées, et réinjectez les constats dans l’étape 3 pour une nouvelle itération.

Liste de contrôle pratique

Servez-vous de cette liste pour vérifier que le système de gestion des risques est complet :

• Plan de gestion des risques documenté, avec périmètre, gouvernance, méthode et cycle de revue
• Critères de risque et seuils d’acceptation définis avant le début de l’analyse
• Risques connus identifiés à partir de la littérature, des essais et des versions antérieures
• Risques prévisibles identifiés par une analyse structurée
• Scénarios de destination analysés sous l’angle des risques
• Scénarios de mauvaise utilisation prévisible analysés sous l’angle des risques
• Matrice appliquée, avec estimations documentées de vraisemblance et de gravité
• Mesures d’atténuation conçues, évaluées et mises en œuvre pour tous les risques au-dessus du seuil
• Interactions entre mesures évaluées
• Risque résiduel apprécié pour chaque danger et pour le système dans son ensemble
• Acceptabilité du risque résiduel jugée et motivée par écrit
• Essais conduits au regard d’indicateurs et de seuils probabilistes préalablement définis
• Essais conduits en conditions réelles ou simulées
• Impacts sur les populations vulnérables spécifiquement essayés, le cas échéant
• Risques résiduels communiqués aux déployeurs dans la notice d’utilisation
• Système de surveillance après mise sur le marché établi et alimentant la gestion des risques
• Cycle de revue et de mise à jour défini et opérationnel
• Toutes les activités documentées au regard des exigences de l’annexe IV

Questions fréquentes

En quoi l’article 9 diffère-t-il d’une appréciation des risques classique ?

Une appréciation classique est un exercice à un instant donné. L’article 9 exige un processus itératif continu qui couvre tout le cycle de vie de l’IA, tenu à jour à mesure que le système évolue, que de nouveaux risques émergent des données après mise sur le marché, et que l’environnement d’exploitation change.

L’article 9 s’applique-t-il aux modèles d’IA à usage général (GPAI) ?

L’article 9 s’applique aux systèmes d’IA à haut risque (articles 6 et 7), pas directement aux modèles GPAI (chapitre V). Toutefois, si un modèle GPAI est intégré dans un système à haut risque, le fournisseur de ce système doit couvrir les risques introduits par le GPAI au titre de l’article 9. Voir notre guide des obligations GPAI.

Que se passe-t-il si le risque résiduel est jugé inacceptable ?

Le système ne doit pas être mis sur le marché. Vous pourrez devoir le concevoir autrement, en limiter le périmètre, ajouter des garanties, ou abandonner le produit. Les organismes notifiés évalueront si le jugement sur le risque résiduel est défendable.

À quelle fréquence le système de gestion des risques doit-il être mis à jour ?

L’article 9, paragraphe 2, exige un examen et une mise à jour méthodiques périodiques, sans fixer de fréquence. Bonne pratique : définir un cycle de revue (annuel ou semestriel) avec des revues ad hoc déclenchées par des mises à jour du système, des incidents, des changements réglementaires, des glissements d’environnement, ou des constats de la surveillance après mise sur le marché.

Puis-je m’appuyer sur ISO 14971 (dispositifs médicaux) ?

Oui, avec des compléments. L’approche par cycle de vie et l’analyse bénéfice-risque d’ISO 14971 collent de près à l’article 9, mais la norme ne traite pas les risques propres à l’IA (biais, dérive de distribution, impacts sur les droits fondamentaux au-delà de la santé et de la sécurité). Voir notre guide pour l’IA de santé.

Quelle est la sanction en cas de non-respect de l’article 9 ?

Des amendes jusqu’à 15 millions d’euros ou 3 % du chiffre d’affaires annuel mondial, plus un possible retrait ou rappel des systèmes non conformes du marché de l’Union. Voir notre guide des sanctions.

Prochaines étapes

Construire un système de gestion des risques conforme à l’article 9 est un chantier lourd, mais il n’a pas à partir de zéro : registres des risques, dispositifs d’essai et processus documentaires peuvent être adaptés à partir des systèmes qualité et de gestion des risques existants.

Commencez ici :

1. Déterminez si votre système est à haut risque. Utilisez notre outil d’évaluation pour classer vos systèmes d’IA et identifier les obligations applicables.
2. Cartographiez l’état actuel. Comparez vos pratiques existantes à la liste ci-dessus et identifiez les écarts.
3. Construisez votre gouvernance. Mettez en place les structures, rôles et processus décrits dans notre guide de gouvernance de l’IA.
4. Alignez-vous sur les normes. Appuyez-vous sur ISO 42001 et le NIST AI RMF pour accélérer. Notre table de correspondance montre comment ils se relient.
5. Documentez en continu. Utilisez notre canevas de documentation technique de l’annexe IV pour que votre documentation de gestion des risques tienne les exigences réglementaires.

L’échéance du 2 décembre 2027 approche. Le moment de construire votre système de gestion des risques, c’est maintenant.