Traiter le risque IA : mesures et plan (Annexe A)

Du risque identifié au choix d'une mesure

Identifier un risque ne le réduit pas. La norme sépare clairement deux moments : l'appréciation des risques, qui repère et hiérarchise, et le traitement des risques, qui décide quoi faire. La clause 6.1.3 ouvre d'ailleurs sur cette continuité : c'est en tenant compte des résultats de l'appréciation que l'organisation définit un processus de traitement des risques liés à l'IA.^[1]

La première étape de ce processus consiste à sélectionner des options de traitement adaptées à chaque risque.^[1] Réduire le risque, l'éviter, le transférer ou l'accepter en connaissance de cause sont des choix de niveau différent, qui n'engagent pas les mêmes mesures. Le mot mesure mérite ici une définition précise. Dans le vocabulaire de la norme, un contrôle est une mesure qui maintient ou modifie un risque ; il peut s'agir d'un processus, d'une politique, d'un dispositif, d'une pratique ou d'autres conditions et actions.^[2]

La norme ajoute une nuance qui compte pour un praticien : un contrôle n'a pas toujours l'effet modificateur attendu.^[2] Choisir une mesure ne suffit donc pas, il faut aussi prévoir comment vérifier qu'elle agit. Cette prudence traverse toute la logique de traitement : on documente ce que l'on décide, et l'on garde de quoi le démontrer.

L'Annexe A : une liste de référence, pas une obligation

Une fois les options de traitement choisies, la norme demande de déterminer tous les contrôles nécessaires pour les mettre en œuvre, puis de les comparer à ceux de l'Annexe A afin de vérifier qu'aucun contrôle nécessaire n'a été omis.^[1] L'Annexe A n'est donc pas un point de départ imposé, mais un filet de sécurité. On conçoit sa réponse au risque, puis on la confronte à la liste pour repérer les angles morts.

Cette annexe rassemble des objectifs de contrôle et des contrôles de référence pour atteindre des objectifs organisationnels et traiter des risques liés à la conception et à l'usage des systèmes d'IA.^[1] Sa table principale, la Table A.1, est organisée en catégories qui couvrent les politiques relatives à l'IA, l'organisation interne, les ressources, l'évaluation des impacts, le cycle de vie du système, les données, l'information des parties intéressées, l'usage des systèmes d'IA et les relations avec les tiers et les clients.^[3]

Le point décisif est que ces contrôles ne sont pas tous obligatoires. La norme l'écrit sans détour : tous les objectifs de contrôle et contrôles listés dans la Table A.1 ne sont pas requis, et l'organisation peut concevoir et mettre en place ses propres contrôles.^[3] Plusieurs lectures professionnelles le confirment dans les mêmes termes : un contrôle déterminant pour une organisation peut être sans objet pour une autre, et la déclaration d'applicabilité doit refléter le contexte réel.^[5]

Concevoir ou ajouter ses propres mesures

La norme va plus loin que le simple tri dans une liste. Elle prévoit explicitement que les contrôles de l'Annexe A ne sont pas exhaustifs et que des objectifs de contrôle et des contrôles supplémentaires peuvent être nécessaires.^[1] Quand ceux de l'Annexe A ne couvrent pas un risque, l'organisation peut concevoir ses propres contrôles ou les reprendre de sources existantes.^[1]

Cette ouverture évite une erreur fréquente : traiter l'Annexe A comme un questionnaire fermé à cocher. Un usage d'IA particulier, un secteur réglementé, une attente forte d'une partie intéressée peuvent appeler une mesure que la liste ne nomme pas. La norme autorise alors à l'inventer, à condition de la documenter au même titre que les autres.

La conséquence est que la déclaration d'applicabilité peut tout aussi bien rester en deçà de l'Annexe A, parce que certains contrôles ne s'appliquent pas, que la dépasser, parce que l'organisation a ajouté les siens. La norme prévoit d'ailleurs ce double mouvement dans la définition même du document : l'organisation peut ne pas avoir besoin de tous les contrôles listés, ou au contraire excéder la liste avec des contrôles établis par elle-même.^[4] L'Annexe A cadre la réflexion, elle ne la borne pas.

La séquence du traitement, du risque à la preuve

La clause 6.1.3 décrit une suite d'opérations qui se lit comme une marche à suivre. Le risque entre par l'appréciation, ressort par un plan approuvé, et laisse derrière lui une trace documentée. Voici cette séquence, reformulée à partir du texte, pour visualiser l'enchaînement plutôt que les détails de chaque alinéa.

La clause 6.1.3 enchaîne le choix des options, la sélection des contrôles, la confrontation à l'Annexe A, la déclaration d'applicabilité et le plan approuvé. Chaque étape produit une trace.

1Risque apprécié et hiérarchisé en 6.1.2

2Choix des options de traitement appropriées

3Contrôles nécessaires, comparés à l'Annexe A

4Contrôles propres ajoutés si l'Annexe A ne suffit pas

5Déclaration d'applicabilité : inclusions et exclusions justifiées

6Plan de traitement approuvé, risques résiduels acceptés

Séquence reformulée à partir de la clause 6.1.3. Le texte de la norme n'est pas reproduit.

Cette lecture en étapes a un mérite concret. Elle montre que le traitement n'est pas une décision isolée, mais une chaîne où chaque maillon s'appuie sur le précédent. On ne choisit pas une mesure sans risque apprécié, on ne déclare pas un contrôle sans l'avoir comparé à la référence, et on ne clôt rien sans une approbation formelle.

La norme demande aussi de considérer le guide de mise en œuvre de l'Annexe B pour les contrôles déterminés en cours de route.^[1] Cette étape ne figure pas dans le schéma parce qu'elle accompagne la mise en œuvre plutôt que la décision, mais elle s'intercale naturellement entre le choix d'un contrôle et sa réalisation.

La déclaration d'applicabilité, document central

Le traitement des risques converge vers un document que la norme nomme déclaration d'applicabilité. La clause 6.1.3 demande de produire une déclaration d'applicabilité qui contient les contrôles nécessaires et fournit une justification pour l'inclusion comme pour l'exclusion des contrôles.^[1] La définition formelle du terme le confirme : il s'agit de la documentation de tous les contrôles nécessaires et de la justification de leur inclusion ou exclusion.^[4]

L'exigence de justification mérite l'attention. Inclure un contrôle se justifie par le risque qu'il traite. L'exclure aussi se justifie, et la norme précise comment : on peut motiver une exclusion par le fait que le contrôle n'est pas jugé nécessaire au regard de l'appréciation des risques, ou par le fait qu'il n'est pas requis, ou soumis à exceptions, au titre d'exigences externes applicables.^[1] Une exclusion non motivée est une lacune ; une exclusion argumentée est une décision défendable.

La déclaration d'applicabilité relie aussi les risques aux mesures. La norme demande que tous les risques identifiés soient documentés, et que les contrôles établis pour les traiter soient reflétés dans la déclaration d'applicabilité.^[4] Les sources professionnelles décrivent ce document comme le pivot de la démarche : il atteste de l'approche de l'organisation face aux risques liés à l'IA, en rendant compte des contrôles choisis et de leur justification.^[6] C'est ce qui transforme une liste de bonnes intentions en un dossier traçable.

Le rôle de l'Annexe B, guide de mise en œuvre

Là où l'Annexe A énonce les contrôles, l'Annexe B explique comment les réaliser. Elle fournit un guide de mise en œuvre des contrôles listés dans la Table A.1, pour soutenir leur réalisation et atteindre leur objectif.^[7] La distinction est utile : l'Annexe A dit quoi viser, l'Annexe B suggère par où passer.

Un point pratique distingue nettement les deux annexes. Pour les contrôles de l'Annexe A, l'organisation doit documenter et justifier les inclusions et exclusions dans la déclaration d'applicabilité. Pour le guide de l'Annexe B, ce n'est pas le cas : l'organisation n'a pas à documenter ni à justifier l'inclusion ou l'exclusion du guide de mise en œuvre dans la déclaration d'applicabilité.^[7] Le guide aide, il n'oblige pas dans sa lettre.

La norme reconnaît elle-même les limites de ce guide. Il n'est pas toujours adapté ni suffisant pour chaque situation, et l'organisation peut l'étendre, le modifier ou définir sa propre mise en œuvre selon ses besoins et son traitement des risques.^[7] L'Annexe B est présentée comme un point de départ pour développer une mise en œuvre propre à l'organisation, pas comme une recette à appliquer telle quelle.^[7]

L'articulation avec l'appréciation et l'analyse d'impact

Le traitement des risques ne tient pas seul. Il prend en entrée l'appréciation des risques de la clause 6.1.2, qui identifie les risques, les analyse en évaluant leurs conséquences, leur vraisemblance et leurs niveaux, puis les évalue en les comparant aux critères de risque et en les hiérarchisant pour le traitement.^[8] Sans cette appréciation, le traitement n'aurait ni matière ni priorités.

L'appréciation s'aligne elle-même sur la politique IA et sur les objectifs IA de l'organisation.^[8] Quand vient le moment d'évaluer les conséquences d'un risque, la norme indique que l'organisation peut s'appuyer sur une analyse d'impact du système d'IA, décrite en clause 6.1.4.^[8] L'évaluation des risques et l'analyse d'impact ne sont donc pas deux exercices parallèles, mais deux pièces qui s'alimentent.

L'analyse d'impact évalue les conséquences potentielles que le déploiement, l'usage prévu et le mésusage prévisible d'un système d'IA peuvent avoir sur les individus, les groupes d'individus et les sociétés.^[9] Son résultat est documenté, et l'organisation tient compte de ce résultat dans l'appréciation des risques.^[9] La boucle est explicite dans le texte : la catégorie A.5 de la Table A.1 fournit justement des contrôles pour évaluer les impacts des systèmes d'IA, que l'on retrouve donc côté traitement.^[9] L'impact nourrit le risque, le risque oriente la mesure, la mesure se range dans une catégorie de l'Annexe A.

Ce qu'un auditeur attend comme preuve

La norme ne se contente pas de décisions, elle demande des traces. Pour le traitement des risques, l'organisation conserve une information documentée sur le processus de traitement des risques liés à l'IA.^[1] Trois pièces structurent ce dossier : la déclaration d'applicabilité, le plan de traitement des risques, et l'approbation de la direction.^[1]

L'approbation n'est pas une formalité. La norme demande d'obtenir l'accord de la direction désignée à la fois pour le plan de traitement et pour l'acceptation des risques résiduels.^[1] Accepter un risque résiduel est une décision de direction, pas un oubli toléré. Les contrôles nécessaires, eux, doivent être alignés sur les objectifs, disponibles comme information documentée, communiqués dans l'organisation et mis à disposition des parties intéressées le cas échéant.^[1]

Au-delà des documents, l'audit observe la réalité des mesures. Les pratiques décrites par les organismes du domaine convergent : l'auditeur cherche des preuves de processus de gouvernance, de la documentation technique, des enregistrements de surveillance et la démonstration des mécanismes de supervision humaine, en combinant entretiens, revue documentaire, observation et vérification technique.^[5] Une déclaration d'applicabilité bien tenue ouvre l'audit interne comme l'audit de certification, à condition que les mesures déclarées existent vraiment sur le terrain.

Un exemple romand : une fiduciaire et son outil de pré-tri

Prenons, à titre d'illustration, une fiduciaire d'une vingtaine de personnes qui utilise un outil d'IA pour pré-trier les pièces comptables de ses clients. Son appréciation des risques a fait ressortir deux préoccupations : la qualité des données traitées par l'outil, et sa dépendance à un fournisseur externe qui héberge ces données. Le traitement commence donc par choisir, pour chacune, une option appropriée.^[1]

Pour la qualité des données, elle retient des contrôles relevant de la catégorie des données de la Table A.1 : définir des exigences de qualité et vérifier que les données utilisées les respectent.^[3] Pour la dépendance au fournisseur, elle se tourne vers la catégorie des relations avec les tiers et les clients, qui prévoit de s'assurer que l'usage de services fournis par des tiers s'accorde avec l'approche responsable de l'organisation.^[3] En comparant ses choix à l'Annexe A, elle constate qu'aucun contrôle nécessaire ne manque.^[1]

Comme elle ne développe pas l'outil, les contrôles de la catégorie du cycle de vie qui portent sur la conception et le développement ne la concernent pas au premier chef.^[3] Elle les exclut, mais elle motive cette exclusion : ces contrôles ne sont pas jugés nécessaires au regard de son appréciation des risques, puisqu'elle n'intervient pas dans la construction du modèle.^[1] Inclusions et exclusions sont consignées dans sa déclaration d'applicabilité, qui devient le fil reliant ses risques à ses mesures.^[4] Reste à formuler un plan de traitement et à le faire approuver par la direction, avec l'acceptation explicite des risques résiduels.^[1]

Questions fréquentes

À lire ensuite