AI Act : système de gestion des risques d’une IA à haut risque (article 9)

L’article 9 du règlement (UE) 2024/1689 sur l’intelligence artificielle (AI Act) impose au fournisseur d’un système d’IA (intelligence artificielle) à haut risque un système de gestion des risques « établi, mis en œuvre, documenté et tenu à jour ». Ce n’est pas un document à rendre une fois : c’est une boucle qui court de la conception jusqu’au retrait du système, alimentée par des essais et par les données du terrain. Cette page décrit ce que l’article exige vraiment, ce qu’il n’exige pas, et comment en faire un dispositif qui tient face à un auditeur comme face à la production.

→ Lire l’explication complète de la marmotte

Ce que l’article 9 exige du fournisseur d’un système d’IA à haut risque

L’obligation pèse sur le fournisseur : l’article 16 lui renvoie l’ensemble des exigences de la section 2 du chapitre III (articles 8 à 15), dont l’article 9. Le déployeur n’a pas d’article 9 à lui ; il a ses propres obligations à l’article 26 et, pour certains déployeurs, l’analyse d’impact sur les droits fondamentaux de l’article 27. Qui est fournisseur, et quand un déployeur le devient par requalification au titre de l’article 25, est traité dans la page rôles de fournisseur et de déployeur.

Prérequis avant la première ligne du registre des risques :

Le système est classé à haut risque. Sans cette qualification (article 6, annexes I et III), l’article 9 ne s’applique pas. La démarche est décrite dans la page sur la classification haut risque, que celle-ci prolonge.
La destination est écrite. Tout l’article raisonne par rapport à l’usage « conforme à la destination ». Une destination floue (« aide à la décision RH ») rend l’analyse invérifiable, puisque la mauvaise utilisation se définit par écart à cette destination.
Un système de gestion de la qualité existe ou se construit. Le système de gestion des risques s’inscrit dans celui de l’article 17, et sa description détaillée figure dans la documentation technique (annexe IV, point 5).
Les données de la surveillance après commercialisation sont prévues. Le point c) du paragraphe 2 se nourrit de l’article 72 ; sans collecte terrain, la boucle reste ouverte.

Côté calendrier, le règlement (UE) 2026/1744, dit omnibus numérique, publié au JO (Journal officiel de l’Union européenne) le 24 juillet 2026 et en vigueur le 27 juillet 2026, ne modifie pas l’article 9. Il reporte en revanche l’application des exigences du haut risque au 2 décembre 2027 pour les systèmes de l’annexe III et au 2 août 2028 pour ceux de l’annexe I ; le détail figure dans le calendrier de l’AI Act. Il introduit aussi un article 2, paragraphe 13, selon lequel l’application des articles 9 à 15 et 17 à 25 peut être limitée pour les produits de l’annexe I lorsque, et dans la mesure où, la législation d’harmonisation de l’annexe I, section A, prévoit un niveau de protection équivalent ou supérieur. La portée exacte de cette limitation se lit dans la version consolidée du règlement sur EUR-Lex, pas dans un résumé.

Ce que l’article n’exige pas compte autant :

Pas de risque zéro. Le paragraphe 5 demande que le risque résiduel de chaque danger et le risque résiduel global soient jugés acceptables. Acceptable, pas nul.
Pas de liste de risques imposée. Aucune annexe ne fournit de catalogue ; le fournisseur identifie les risques « connus et raisonnablement prévisibles ».
Pas d’obligation sur tout ce qui peut mal tourner. Le paragraphe 3 limite le champ aux risques qui peuvent être raisonnablement atténués ou éliminés par le développement, la conception ou la fourniture d’informations techniques. Un risque qui tient à l’organisation interne du déployeur reste hors de portée du fournisseur, qui peut en revanche le signaler dans la notice d’utilisation.

La position à retenir : l’article 9 est une obligation de méthode tracée, pas de résultat absolu. Un auditeur ne demandera pas « le système est-il sans danger ? » mais « montrer comment ce risque a été trouvé, mesuré, traité, testé, puis accepté, et par qui ».

Cycle de vie du système de gestion des risques (article 9, paragraphe 2)

Le paragraphe 2 décrit un « processus itératif continu qui est planifié et se déroule sur l’ensemble du cycle de vie », avec un examen et une mise à jour méthodiques périodiques. Quatre étapes : a) identifier et analyser les risques connus et raisonnablement prévisibles pour la santé, la sécurité ou les droits fondamentaux en usage conforme ; b) estimer et évaluer ces risques en usage conforme et en mauvaise utilisation raisonnablement prévisible ; c) évaluer d’autres risques à partir de la surveillance après commercialisation ; d) adopter des mesures appropriées et ciblées.

Le schéma montre la boucle complète ; ce qu’il faut y lire, ce sont les deux retours en arrière (essai raté vers nouvelle mesure, terrain vers nouvelle identification), qui distinguent un processus vivant d’un rapport figé.

Le considérant 65 ajoute ce que l’article sous-entend : réexamen régulier, justification et documentation des décisions et mesures majeures, prise en compte de l’état de la technique, association le cas échéant d’experts et de parties prenantes externes. Concrètement, « planifié » veut dire une périodicité de revue écrite et des déclencheurs de revue hors calendrier : réentraînement, changement de jeu de données, nouvelle population d’utilisateurs, incident signalé. Un modèle réentraîné chaque mois avec une revue de risques annuelle n’a pas de processus continu ; il a un rituel annuel et onze versions non analysées.

Santé, sécurité, droits fondamentaux : pas une analyse cyber, pas une AIPD

L’objet de l’article 9 n’est pas le système d’information. C’est la personne : sa santé, sa sécurité, ses droits fondamentaux (non-discrimination, accès à l’emploi, à l’éducation, à un recours, vie privée). Une analyse EBIOS RM (Expression des besoins et identification des objectifs de sécurité, Risk Manager) ou un modèle de menaces partent d’un attaquant et de valeurs métier ; une AIPD (analyse d’impact relative à la protection des données) au sens de l’article 35 du RGPD (règlement général sur la protection des données) part d’un traitement de données personnelles. L’article 9 part d’une destination et de ses effets sur des gens, y compris quand aucune donnée personnelle ni aucun attaquant n’est en jeu.

Critère	Analyse de risque cyber	AIPD (RGPD, art. 35)	Gestion des risques (AI Act, art. 9)
Objet protégé	Biens et valeurs métier du SI (système d’information)	Droits et libertés des personnes concernées par un traitement	Santé, sécurité, droits fondamentaux des personnes affectées
Source du risque	Menace intentionnelle ou accidentelle	Traitement de données personnelles	Comportement du système, en usage conforme ou mal utilisé
Porteur	Organisation exploitante	Responsable du traitement	Fournisseur du système
Durée	Revue périodique	Avant le traitement, révisée si changement	Tout le cycle de vie, alimentée par le terrain

Les trois se recoupent sans se remplacer. Un modèle parfaitement durci contre l’exfiltration peut écarter systématiquement une sous-population ; un modèle équitable peut tomber à la première attaque par empoisonnement des données d’entraînement. Réutiliser la matrice de risques cyber en changeant les libellés produit un document plausible et une analyse fausse : les échelles de gravité « perte de chiffre d’affaires » ne mesurent pas une exclusion injustifiée d’un candidat. Les méthodes sœurs ont leurs pages : EBIOS RM et ses limites, le modèle de menaces en amont du développement et l’AIPD.

Mauvaise utilisation raisonnablement prévisible

Le considérant 65 la définit comme l’usage hors destination qui résulte d’un comportement humain aisément prévisible. Ce n’est ni l’attaque sophistiquée ni l’usage absurde : c’est ce que font des utilisateurs pressés, confiants ou mal formés. Exemples génériques :

Score traité comme une décision. Un outil conçu pour prioriser des dossiers sert à rejeter automatiquement tout dossier sous un seuil, sans revue humaine.
Population hors périmètre. Un modèle validé sur des adultes est appliqué à des candidatures d’apprentis dont une partie a moins de 18 ans.
Contexte hors périmètre. Un outil de notation de solvabilité conçu pour des salariés est appliqué à des travailleurs indépendants, aux revenus irréguliers.
Biais d’automatisation. L’opérateur valide la recommandation sans la lire parce qu’elle a eu raison les deux cents fois précédentes.

Deux conséquences pratiques. D’abord, ces circonstances doivent figurer dans la notice d’utilisation (article 13) : ce que le système ne sait pas faire et sur qui il n’a pas été validé. Ensuite, le considérant 65 précise qu’aucun ré-entraînement spécifique n’est exigé pour couvrir une mauvaise utilisation prévisible ; il est seulement encouragé. La mesure peut donc être une contrainte de conception (refus de produire un score hors périmètre), un contrôle d’usage ou une information, selon la hiérarchie du paragraphe 5. Vingt ans de métier apprennent que l’usage réel d’un outil diverge de l’usage prévu dès la deuxième semaine ; le texte demande simplement de l’avoir écrit avant.

Hiérarchie des mesures et risque résiduel (paragraphes 4 et 5)

Le paragraphe 5 impose un ordre, et c’est la règle la plus souvent inversée en pratique. Le schéma se lit de haut en bas : on ne descend d’un niveau que pour ce que le niveau précédent n’a pas pu traiter.

Le compromis central du sujet se trouve ici. Une mesure par conception coûte cher (données à reconstituer, architecture à revoir, latence) mais protège quel que soit le comportement du déployeur. Une mesure par information ne coûte presque rien au fournisseur et repose entièrement sur un lecteur de notice dont l’existence reste à démontrer. La recommandation : réserver le niveau c) aux risques dont la cause est réellement dans l’usage, et documenter pour chaque risque pourquoi le niveau a) a été jugé impossible. Une ligne « avertissement dans la notice » sans cette justification signale exactement l’inversion de hiérarchie qu’un évaluateur cherche. Le paragraphe 5 précise d’ailleurs qu’on tient compte des connaissances techniques, de l’expérience, de l’éducation et de la formation attendues du déployeur : une notice de quarante pages pour un opérateur formé en une demi-journée ne compte pas pour grand-chose.

Le paragraphe 4 ajoute une contrainte d’équilibre : les mesures tiennent compte de l’interaction des exigences des articles 8 à 15 entre elles. Les tensions sont connues :

Article 10 (données) contre droits fondamentaux. Corriger un biais exige souvent des données sur la caractéristique protégée, que la minimisation pousse à ne pas collecter ; l’article 10, paragraphe 5, encadre strictement cette exception.
Article 14 (contrôle humain) contre performance. Un seuil de revue humaine bas réduit les erreurs non vues mais multiplie le volume revu, donc le biais d’automatisation.
Article 15 (exactitude, robustesse, cybersécurité) contre explicabilité. Un ensemble de modèles plus robuste est aussi moins lisible pour l’opérateur chargé du contrôle.

Les garde-fous applicatifs décrits dans l’architecture de guardrails programmatiques relèvent du niveau b) ; ils ne remplacent pas une correction au niveau a) quand elle est possible.

Essais, indicateurs et seuils probabilistes (paragraphes 6 à 9)

Les essais servent deux fins (paragraphe 6) : choisir les mesures les plus appropriées et vérifier que le système fonctionne conformément à sa destination et aux exigences de la section 2. Ils ont lieu à tout moment du développement selon les besoins, et en tout état de cause avant la mise sur le marché ou la mise en service (paragraphe 8), éventuellement en conditions réelles au sens de l’article 60 (paragraphe 7).

Le mot qui change tout est « préalablement définis » : le paragraphe 8 exige des indicateurs et des seuils probabilistes fixés avant le test et adaptés à la destination. Règles qui en découlent :

Le seuil est versionné avant l’exécution. Un seuil choisi après avoir vu les résultats n’est pas un critère d’acceptation, c’est une description des résultats.
L’indicateur est désagrégé. Une moyenne globale masque l’écart entre sous-populations, qui est précisément là où naît l’atteinte aux droits fondamentaux.
Le seuil porte sur une borne, pas sur un point. Sur une sous-population de 200 exemples, un taux observé de 7 % a une borne supérieure d’intervalle de confiance à 95 % d’environ 10,5 %. Le critère s’écrit sur cette borne, ce qui oblige à dimensionner l’échantillon avant le test.
Le jeu de test est figé et isolé de l’entraînement et du réglage, sinon la mesure est contaminée.

Le paragraphe 9 impose de prendre en considération la probabilité d’une incidence négative sur les personnes de moins de 18 ans et, le cas échéant, sur d’autres groupes vulnérables. En pratique, cela se traduit par une sous-population explicite dans le plan de test, ou par une justification écrite de son absence dans la population visée par la destination. Les techniques d’attaque qui alimentent la partie robustesse sont décrites dans la page sur le red teaming de LLM (LLM pour Large Language Model, grand modèle de langage).

Exemple : tri de candidatures chez un fournisseur fictif

Organisation fictive : Présélecta, éditeur d’un système de présélection de candidatures (emploi, annexe III, point 4 a)). Destination déclarée : classer les candidatures reçues pour une offre afin de prioriser la lecture par un recruteur, sans rejet automatique.

Avant tout test, le registre fixe pour le risque « candidat qualifié classé en fin de liste » l’indicateur suivant : taux de faux négatifs (candidat jugé qualifié par un jury humain mais classé dans le dernier tiers). Critères écrits et versionnés :

borne supérieure de l’intervalle de confiance à 95 % du taux de faux négatifs inférieure à 10 % pour chaque sous-population testée ;
écart entre la meilleure et la moins bonne sous-population inférieur à 3 points ;
sous-populations : tranches d’âge, dont les moins de 18 ans (offres d’apprentissage, paragraphe 9), parcours en reconversion, CV (curriculum vitae) non francophones.

Le schéma montre le déroulé ; ce qu’il faut y lire, c’est que l’échec sur une sous-population déclenche une mesure de conception avant toute mesure d’information.

Deux points méritent attention. Le seuil n’a pas bougé entre les deux essais : c’est le modèle qui a changé, pas le critère. Et la notice n’arrive qu’en dernier, pour le résiduel et pour la mauvaise utilisation prévisible (rejet automatique sous un rang), qu’aucune modification du modèle ne peut empêcher côté déployeur. Une revue sur la parité des scores entre groupes aurait pu passer alors que l’erreur, elle, ne se répartissait pas également : l’indicateur choisi pilote ce que le processus est capable de voir.

Preuves attendues, normes et exploitation du dossier

Le dossier qui atteste de l’article 9 (annexe IV, point 5) tient en quelques artefacts, à condition qu’ils soient reliés entre eux :

Registre des risques : danger, personnes affectées, scénario (usage conforme ou mauvaise utilisation), probabilité, gravité, niveau de mesure retenu.
Critères d’acceptation : par danger et global, datés et versionnés avant les essais.
Traçabilité décision → mesure → test : chaque risque pointe vers une mesure, chaque mesure vers un essai et son résultat, chaque acceptation vers une décision nominative.
Journal de revue : dates, déclencheurs, entrées issues de l’article 72.

La traçabilité est ce qui distingue un dossier d’une pile de documents. Le schéma résume la chaîne qu’un évaluateur remonte, dans un sens comme dans l’autre.

Côté normes, ISO/IEC 23894:2023, publiée conjointement par l’ISO et la CEI (Commission électrotechnique internationale), donne des lignes directrices de management du risque de l’IA adossées à ISO 31000, et ISO/IEC 42001:2023 décrit un système de management de l’IA. Ni l’une ni l’autre ne vaut présomption de conformité : seule une norme harmonisée publiée au JO la confère (article 40), et les normes harmonisées européennes sont encore en préparation au comité technique conjoint JTC 21 (Joint Technical Committee) du CEN-CENELEC (Comité européen de normalisation et Comité européen de normalisation électrotechnique). S’appuyer sur ISO/IEC 23894 reste un choix raisonnable pour la méthode ; brandir une certification ISO/IEC 42001 comme preuve de l’article 9, c’est présenter le plan de la maison comme le procès-verbal de réception.

Le paragraphe 10 évite la double comptabilité : un fournisseur déjà soumis à un processus interne de gestion des risques par un autre texte de l’Union peut y intégrer les paragraphes 1 à 9 ou les combiner. Le cas d’école est le dispositif médical, dont le processus ISO 14971 existe déjà ; il faut alors y ajouter ce qu’il ne couvre pas nativement, en particulier les droits fondamentaux et la mauvaise utilisation propre à un système appris.

Conditions d’exploitation, souvent oubliées :

Intégrité du dossier. Registre, seuils et résultats vivent dans un dépôt versionné à accès contrôlé, avec historique non réécrivable. Un seuil modifiable après coup par l’équipe qui le mesure annule la valeur de « préalablement défini ».
Sauvegarde et rétention. La documentation technique se conserve dix ans après la mise sur le marché (article 18) ; le dossier de risques suit, avec les jeux de test figés permettant de rejouer un essai.
Supervision. Les indicateurs du paragraphe 8 deviennent des métriques de production, désagrégées, avec alerte au franchissement du seuil ; la chaîne décrite dans l’observabilité des LLM en production en fournit la plomberie.
Rotation des revues. Périodicité écrite, plus déclencheurs sur réentraînement, changement de données, extension de périmètre ou incident grave.

Surface d’attaque et ce que l’article 9 ne garantit pas

Un système de gestion des risques a sa propre surface d’attaque, et elle est surtout organisationnelle :

Contournement de la mesure. Une mesure d’atténuation réalisée par un filtre en entrée tombe face à des entrées adverses (reformulation, encodage, injection). Contre-mesure : tester le contournement dans le plan d’essai, pas seulement le fonctionnement nominal.
Empoisonnement après validation. Un réentraînement sur des données collectées en production réintroduit un biais ou une porte dérobée que les essais initiaux n’ont jamais vus. Contre-mesure : réentraînement comme déclencheur obligatoire de revue et de rejeu des essais.
Optimisation contre l’indicateur. Un modèle réglé pour passer un seuil sur un jeu de test connu surapprend ce jeu. Contre-mesure : jeu de test isolé, rotation partielle contrôlée, essais en conditions réelles quand l’article 60 le permet.
Dossier altéré. Seuils réécrits, résultats sélectionnés. Contre-mesure : versionnement, séparation entre qui fixe le seuil et qui le mesure.

Ce que l’article 9 ne garantit pas : que le système soit sûr (il garantit qu’une méthode a été suivie), que le déployeur l’utilise comme prévu (article 26), que les données soient de qualité (article 10), que les journaux existent (article 12), que le contrôle humain fonctionne (article 14), ni que le système résiste à une attaque (article 15). Il ne dit pas non plus si une organisation donnée est en règle : cette appréciation relève d’un juriste, texte officiel en main sur EUR-Lex.

Erreurs fréquentes

Le registre écrit une fois, à la veille de l’évaluation. Il décrit alors l’état d’un modèle qui n’est plus en production depuis trois versions.
Seuils fixés après les résultats. Contraire au paragraphe 8, et visible dans l’historique du dépôt.
Matrice cyber recyclée. Échelles de gravité financières pour des atteintes à des personnes.
Tout en notice. Hiérarchie du paragraphe 5 inversée, sans justification de l’impossibilité du niveau a).
Moyenne globale seule. Aucune désagrégation, aucune sous-population de moins de 18 ans alors que la destination les inclut.
Boucle ouverte. Pas de canal entre la surveillance après commercialisation (article 72) et le registre ; le point c) du paragraphe 2 reste lettre morte.
Confusion des rôles. Un déployeur qui rédige un « article 9 » pour un système acheté, alors que ses obligations propres relèvent des articles 26 et 27, et que l’article 9 incombe au fournisseur.

🐝 Ce qui arrive si on s’en passe

Sans boucle de gestion des risques, un réentraînement change le comportement du système sans que personne ne rejoue les essais : une sous-population peut se retrouver écartée sans qu’aucun indicateur ne le signale, puisqu’aucun n’a été désagrégé. Les remontées du terrain s’accumulent sans atteindre la conception, et la mauvaise utilisation la plus prévisible n’apparaît dans aucune notice, ce qui laisse le déployeur sans limite écrite. Lors d’un contrôle, le fournisseur ne peut produire ni critère d’acceptation daté ni chaîne reliant un risque à son essai : la documentation technique exigée par l’annexe IV est incomplète, et la conformité du système ne peut plus être démontrée.

🦫 Explication de la marmotte 🍫

Une loi européenne classe certains programmes d’intelligence artificielle comme « à haut risque », par exemple ceux qui trient des candidatures d’emploi. L’entreprise qui fabrique un tel programme doit suivre une méthode pour repérer et réduire les dangers qu’il fait courir aux gens : à leur santé, à leur sécurité, à leurs droits, comme celui de ne pas être écarté injustement.

Tout commence par écrire précisément à quoi sert le programme. Ensuite, on liste ce qui peut mal tourner, quand il est bien utilisé, mais aussi quand des gens l’utilisent de travers de façon facile à deviner. Pour chaque danger, on cherche d’abord à corriger le programme lui-même. Si c’est impossible, on ajoute des contrôles, par exemple une personne qui vérifie. En dernier seulement, on prévient les utilisateurs par écrit.

Puis on teste. Avant le test, on fixe des chiffres à ne pas dépasser, comme une part maximale de bons candidats mal classés, mesurée séparément pour chaque groupe de personnes, y compris les mineurs. Si un groupe dépasse la limite, on modifie le programme et on refait le test avec la même limite.

Après la mise en vente, l’entreprise surveille ce qui se passe réellement. Un problème constaté relance toute la méthode. Si personne ne fait ce travail, une erreur qui touche un groupe précis peut durer longtemps sans être vue, et l’entreprise ne peut pas prouver qu’elle respecte la loi.

Pages voisines

La citent

AI Act : système de gestion des risques d'une IA à haut risque (article 9)

Elle cite

: les deux pages se citent l’une l’autre.