Article 9 de l’AI Act : transformer les risques en contrôles et en tests vérifiables

Ce que couvre ce guide — et ce qui n’en fait pas partie

L’article 9 du règlement européen sur l’intelligence artificielle (AI Act) impose aux fournisseurs de systèmes d’IA à haut risque d’établir, de mettre en œuvre, de documenter et de maintenir un système de gestion des risques. Le principe pratique développé ici est simple : associer chaque risque identifié à une mesure et définir comment vérifier que celle-ci contribue à le réduire.

Ce guide se limite à cet article. Il ne constitue ni une présentation complète du règlement, ni une évaluation juridique d’un produit, ni une méthode permettant à elle seule de déterminer si un système relève de la catégorie des systèmes à haut risque. Il ne soumet pas non plus automatiquement tous les outils d’IA à l’article 9. Il faut d’abord vérifier que le système et sa finalité relèvent du champ pertinent du règlement ; ce n’est qu’ensuite que ce modèle peut servir d’aide au travail.

L’article impose des obligations aux fournisseurs de systèmes d’IA à haut risque. Cela ne signifie pas que toute personne utilisant un système doit automatiquement créer et maintenir le système de gestion des risques exigé des fournisseurs. Les obligations d’autres acteurs, notamment les déployeurs, doivent faire l’objet d’une analyse distincte. Pour vous repérer dans le sujet plus largement, vous pouvez consulter les guides consacrés à la sécurité, à la comparaison des systèmes et à la découverte d’outils d’IA. Ils ne remplacent pas la vérification des obligations applicables à une situation précise.

Dans la suite, nous distinguons deux niveaux. La mention « Exigence du règlement » désigne ce que prévoit l’article 9. La mention « Recommandation opérationnelle » indique une façon pratique d’organiser le travail, susceptible de faciliter la démonstration de conformité, mais qui ne doit pas être confondue avec un formulaire ou un champ imposé littéralement par le texte.

Vérification préalable : le système entre-t-il dans le champ d’application ?

Avant d’inscrire des risques au titre de l’article 9, identifiez le système concerné et sa finalité prévue. La classification ne dépend pas seulement du fait que le produit utilise un modèle avancé, que l’organisation le juge sensible ou que ses résultats puissent avoir des conséquences importantes. Le règlement définit les systèmes considérés comme à haut risque au moyen de catégories et de conditions ; leur qualification peut dépendre de la manière dont le système est utilisé et de la fonction qu’il remplit.

Pour commencer, décrivez assez précisément l’usage réel et prévu : qui exploite le système, qui reçoit ou utilise ses résultats, quelle décision ou quel processus il soutient et dans quel contexte il est intégré. Comparez ensuite cette description aux dispositions applicables du règlement, notamment aux catégories pertinentes et aux conditions ou exceptions susceptibles d’influer sur la classification. Si la catégorie, le rôle de l’organisation ou le calendrier d’application d’une obligation soulève des doutes, demandez un examen juridique avant de présenter une conclusion provisoire comme un fait établi.

Ne classez pas un système sur la seule base d’une description commerciale, de la technologie qu’il intègre ou du nom d’une catégorie. Un même système peut servir à plusieurs usages ; l’évaluation doit porter sur l’usage concret examiné. L’exemple du tri de candidatures présenté plus loin est hypothétique. Il illustre une manière de documenter un risque, sans prétendre que tous les systèmes de recrutement reçoivent automatiquement la même qualification juridique.

Notez les éléments qui étayent votre première conclusion : documentation du produit, finalité déclarée, description du processus et conditions de déploiement. Si la conclusion repose sur des hypothèses qui restent à confirmer, indiquez qu’elles sont en attente de vérification. Cette précaution évite que le modèle transforme une hypothèse de classification en prémisse apparemment définitive.

Du contexte à un risque analysable

L’article 9 prévoit un processus continu et itératif couvrant le cycle de vie du système. Pour commencer utilement, décrivez le contexte d’utilisation avant d’énumérer les préjudices possibles. Un même résultat du système peut entraîner des conséquences différentes selon la personne qui l’interprète, les vérifications complémentaires en place et la possibilité, pour une personne, de corriger une erreur avant qu’elle n’ait des effets.

Le règlement vise les risques connus et raisonnablement prévisibles pour la santé, la sécurité et les droits fondamentaux lorsque le système est utilisé conformément à sa finalité prévue. Il exige également d’estimer et d’évaluer les risques susceptibles de découler de cette finalité et d’un mauvais usage raisonnablement prévisible. Il convient donc d’examiner l’usage prévu et les écarts prévisibles, sans pour autant traiter toute éventualité lointaine comme un risque avéré.

Pour chaque scénario, distinguez trois éléments : le fait connu, l’hypothèse à vérifier et le préjudice possible. Par exemple, le fait peut être que le système produit un classement ; l’hypothèse, que certains dossiers incomplets augmentent la probabilité d’un classement erroné ; et le préjudice plausible, qu’une personne soit exclue d’une étape d’évaluation sans examen approprié. Le test devra déterminer si l’hypothèse est fondée et dans quelles conditions.

Tenez compte des personnes potentiellement concernées et des conditions susceptibles de modifier le résultat : qualité ou absence de données, langue, environnement d’utilisation, intervention humaine, dépendance à d’autres composants et changements apportés au processus. Il n’est pas nécessaire de feindre une certitude lorsqu’il ne s’agit que d’une hypothèse. Mieux vaut préciser quelles informations manquent et comment elles seront recherchées que de présenter une estimation non étayée comme une mesure établie.

Associer une mesure pertinente à chaque risque

Après avoir décrit le scénario, définissez le changement susceptible de prévenir ou de réduire le risque et expliquez pourquoi vous pensez qu’il pourrait fonctionner. L’article 9 exige l’adoption de mesures de gestion des risques appropriées et ciblant les risques identifiés. Il prévoit également que les risques soient éliminés ou réduits autant que possible sur le plan technique au moyen d’une conception et d’un développement adéquats. Lorsqu’ils ne peuvent être éliminés, des mesures appropriées d’atténuation et de contrôle doivent être appliquées.

En pratique, une mesure peut concerner la conception du système, son paramétrage, les instructions qui l’accompagnent ou son intégration dans le processus. Le choix dépend du risque et du système. Ne présumez pas qu’un avertissement dans l’interface ou qu’une formule générale de « supervision humaine » suffisent. Décrivez ce que la mesure doit faire, à quel moment elle s’applique, qui peut intervenir et quelles sont ses limites. Si la personne qui déploie le système doit recevoir des informations ou une formation pour l’utiliser correctement, précisez ce qu’elle doit savoir et comment ces éléments lui seront fournis. L’article prévoit également, le cas échéant, des informations et une formation destinées aux déployeurs.

La justification d’une mesure doit être liée au mécanisme du risque. Si le problème envisagé est que des données incomplètes rendent les résultats peu fiables, un contrôle qui se contente d’enregistrer la date d’exécution peut laisser la cause intacte. Il serait possible, par exemple, d’évaluer des mécanismes capables de détecter les données manquantes, d’empêcher l’utilisation d’un résultat invalide sans examen ou d’alerter la personne chargée de l’exploitation. Ce sont des pistes à étudier, pas des prescriptions universelles : le test doit montrer si elles sont pertinentes et efficaces dans le contexte concerné.

Le règlement relie la gestion des risques aux connaissances et à l’état de la technique, ainsi qu’à la finalité prévue et aux mauvais usages raisonnablement prévisibles. Le registre doit donc permettre d’expliquer pourquoi une mesure a été choisie et sur quelles informations repose ce choix. Si elle ne supprime pas le risque, indiquez ce qui subsiste et dans quelles conditions le contrôle pourrait échouer.

Concevoir les tests avant de les exécuter

L’article 9 prévoit des tests des systèmes à haut risque afin d’identifier les mesures de gestion des risques les plus appropriées. Il dispose également que, le cas échéant, les tests sont réalisés à différentes étapes du développement et, en tout état de cause, avant la mise sur le marché ou la mise en service. Le texte précise qu’ils doivent s’appuyer sur des métriques et des seuils probabilistes définis au préalable et adaptés à la finalité prévue. L’article ne fixe pas de métrique unique applicable à tous les systèmes.

Pour qu’un test permette de prendre une décision, définissez à l’avance le scénario couvert, les données ou conditions utilisées, le résultat observé et le critère jugé suffisant. Expliquez pourquoi ce critère convient à l’usage prévu. Le déterminer après avoir vu les résultats accroît le risque d’adapter l’évaluation à ce qui s’est déjà produit et de ne pas repérer des défaillances importantes.

Testez aussi les conditions pertinentes pour le risque : données manquantes, changements de langue, cas limites, entrées hors des conditions habituelles ou intervention humaine prévue, par exemple. La sélection de ces conditions doit être motivée ; il est inutile d’énumérer des scénarios sans rapport avec l’usage. Si un échantillon est utilisé, expliquez ses limites et précisez quels groupes, situations ou conditions il ne représente pas. Un résultat favorable lors d’un test limité ne prouve pas, à lui seul, que le système est sûr dans tous les environnements.

Le résultat peut être favorable, insuffisant ou non concluant. Dans les deux derniers cas, décrivez ce qui a échoué ou ce qui empêche de conclure, ajustez la mesure si nécessaire et définissez un nouveau test. Conservez les résultats et les décisions pertinentes comme éléments probants de la façon dont le risque a été géré. L’obligation de tester ne se réduit pas à conserver un score : le but est d’évaluer les mesures appropriées et le comportement du système au regard de sa finalité.

Modèle pratique : relier risque, contrôle, test et décision

Une ligne de registre utile permet de suivre toute la logique sans confondre une mesure envisagée et une mesure déjà validée. Dans l’exemple hypothétique du tri de candidatures, il ne s’agit pas d’affirmer qu’un biais ou un préjudice a été démontré. L’objectif est de montrer quelles informations réunir avant de décider si un contrôle réduit le risque envisagé.

La mesure doit correspondre au scénario et le test doit évaluer cette mesure, et non le système de façon abstraite. Dans l’exemple, si le scénario est qu’une donnée manquante influe sur un classement qui n’est ensuite pas examiné, un test pertinent pourrait étudier ce qui se passe lorsque cette donnée manque et vérifier si la procédure d’examen prévue se déclenche. Les critères précis et le résultat ne peuvent pas être inventés : ils doivent être définis et mesurés pour le système réel.

Consignez séparément la personne qui a préparé l’évaluation, celle qui a approuvé une décision interne et celle qui doit examiner les questions juridiques. Attribuer ces fonctions peut constituer une bonne pratique de gouvernance, mais n’attribuez pas à l’article 9 un poste universel que le texte ne précise pas. La personne ou l’entité tenue d’agir dépend du rôle qu’elle joue au regard du règlement et du cas considéré.

Que faire des résultats insuffisants et des risques résiduels

Un résultat qui n’atteint pas le critère prévu ne doit pas être rendu acceptable en modifiant le seuil après coup. Consignez le résultat tel qu’il a été obtenu, expliquez quelle condition n’a pas été remplie et examinez si la cause exige de modifier la conception, d’ajouter ou de changer une mesure d’atténuation, de modifier le processus de déploiement ou de restreindre l’usage évalué. Prévoyez ensuite une nouvelle évaluation lorsque cela est pertinent.

Si le test ne permet pas de conclure, indiquez pourquoi : données inadaptées, scénario impossible à reproduire, échantillon limité ou condition d’utilisation non observée. Cette incertitude constitue elle aussi une information pertinente. Précisez ce qui serait nécessaire pour la lever et qui doit décider de poursuivre les recherches, de limiter l’utilisation ou de faire remonter le problème.

Ne décrivez pas un risque comme éliminé si vous avez seulement réduit sa probabilité ou limité son impact. La documentation doit faire apparaître la différence entre le risque initial, l’effet des mesures et ce qui n’a pas encore été testé. Les personnes qui examinent le dossier ne confondront ainsi pas une action envisagée avec une efficacité démontrée.

L’article 9 impose de documenter le système de gestion des risques et les décisions pertinentes. À titre de recommandation opérationnelle, conservez avec le registre les versions des tests, leurs conditions d’exécution, les résultats et le raisonnement qui étaye les décisions. Avant de fixer des durées de conservation, vérifiez les dispositions applicables au système et à l’organisation : ce guide ne définit pas de délai universel.

Révision pendant le cycle de vie et articulation avec d’autres processus

La gestion des risques prévue par l’article 9 n’est pas présentée comme une évaluation unique qui s’achève une fois les tests réalisés. Elle doit fonctionner comme un processus continu et itératif pendant tout le cycle de vie, avec des révisions et des mises à jour régulières et systématiques. Les informations recueillies après le déploiement peuvent contribuer à évaluer les risques ; l’article prend également en compte les données issues du suivi après commercialisation auquel renvoie le règlement.

À titre de méthode d’organisation, définissez les changements susceptibles de déclencher une révision : modifications importantes du système, évolution de la finalité ou du contexte d’utilisation, problèmes détectés, nouvelles informations sur les risques ou résultats du suivi. Précisez qui reçoit ces informations et comment il est décidé s’il faut mettre à jour l’analyse, les mesures ou les tests. Ces déclencheurs précis sont des recommandations destinées à rendre la révision opérationnelle, et non une liste littéralement énoncée à l’article 9.

Si le système relève déjà d’exigences de gestion des risques prévues par une autre législation de l’Union, l’article 9 prévoit que le système de gestion correspondant puisse être intégré aux processus exigés par cette législation ou y contribuer, dans les conditions précisées par le règlement. Ne présumez pas qu’une procédure existante satisfait automatiquement à toutes les obligations de l’AI Act : vérifiez les risques, les éléments probants et les exigences qu’elle couvre effectivement, ainsi que les lacunes qui subsistent.

La date à laquelle une obligation devient applicable dépend des dispositions temporelles pertinentes. Il peut être nécessaire de vérifier les modifications et mesures transitoires en vigueur. Le calendrier ne se déduit pas du seul article 9. Avant de fixer une échéance de conformité, consultez le texte officiel à jour et les dispositions applicables au type de système et au rôle de l’organisation. Si cette date a une incidence immédiate sur une décision, demandez un conseil juridique actualisé.

Vérifications pratiques avant de clore l’évaluation

Avant de considérer le travail achevé, vérifiez que chaque risque est décrit de façon compréhensible et que les éléments observés sont distingués des hypothèses. Assurez-vous que chaque mesure répond à un risque particulier, que sa justification peut être reconstituée et que les critères du test ont été définis avant son exécution. Si une mesure n’a pas été testée, indiquez qu’elle reste à évaluer ; si un test ne couvre que certaines conditions, n’étendez pas son résultat à d’autres situations.

Vérifiez également que l’analyse correspond à la finalité et au contexte réellement évalués, qu’elle prend en compte les mauvais usages raisonnablement prévisibles pertinents et qu’elle n’oublie pas les personnes susceptibles d’être concernées. Documentez les limites du travail ainsi que les questions nécessitant un examen juridique ou technique. Si des processus existants sont utilisés, vérifiez ce qu’ils couvrent, quels éléments probants ils apportent et quelles lacunes subsistent.

L’article 9 ne certifie pas automatiquement qu’un système est sûr et ne garantit pas l’absence de préjudice. Il fonde un processus de gestion des risques qui doit être maintenu et documenté. La valeur d’une matrice ne se mesure pas au nombre de lignes qu’elle contient, mais à sa capacité à expliquer pourquoi une mesure a été choisie, quel test l’étaye, quel résultat a été observé et quelles questions restent ouvertes.

Poursuivre l’exploration

Corrections et transparence

Si vous repérez une information incorrecte ou obsolète, envoyez-nous la page et la source à vérifier.