Appréciation des risques IA selon la clause 6.1.2 : méthode et pièges à éviter

Pourquoi des risques spécifiques à l'IA

Les systèmes d'IA présentent des caractéristiques que la gestion des risques informatiques classique ne couvre pas. Selon Trend Micro, les menaces ciblées comprennent l'empoisonnement des données d'entraînement, les attaques par inversion de modèle visant à extraire des informations sensibles, et les exemples contradictoires (adversarial examples) qui poussent un système à prendre de mauvaises décisions^[3]. À cela s'ajoutent les biais, la dérive des modèles et les problèmes de sécurité et de robustesse identifiés par Bureau Veritas dans le cadre de ses audits de certification^[2].

La norme ISO/IEC 42001 reconnaît cette spécificité. Elle inclut des protections adaptées aux systèmes qui apprennent en continu, se comportent de manière parfois imprévisible et impliquent des relations complexes avec de multiples parties prenantes^[3]. C'est pourquoi la clause 6.1.2 exige une appréciation des risques distincte, calibrée pour les enjeux propres à l'intelligence artificielle.

Ce que demande la clause 6.1.2

La clause 6.1.2 se situe dans la section « Planification » (clauses 4 à 10) de la norme, qui suit la méthodologie PDCA (Planifier, Déployer, Contrôler, Agir)^[8]. En substance, elle demande à l'organisation de définir et d'appliquer un processus d'appréciation des risques liés à l'IA. Ce processus doit, en paraphrasant la norme :

• Établir des critères de risque (seuils d'acceptation, échelles de vraisemblance et de conséquence).
• Identifier les risques spécifiques aux systèmes d'IA dans le périmètre du SMIA.
• Analyser ces risques (vraisemblance, conséquences, niveau résultant).
• Évaluer les risques analysés par rapport aux critères définis pour déterminer lesquels nécessitent un traitement.
• Conserver des informations documentées sur l'ensemble du processus.

Cette structure est familière pour quiconque connaît l'ISO 27001, puisque la norme ISO 42001 partage la même architecture de haut niveau (Harmonized Structure)^[7]. La différence réside dans la nature des risques à identifier et dans le catalogue de contrôles de référence (annexe A) vers lequel les résultats de l'appréciation doivent pointer.

Définir les critères de risque

Avant de recenser quoi que ce soit, il faut poser les règles du jeu. Les critères de risque fixent le cadre dans lequel chaque risque sera mesuré. En pratique, cela implique de décider :

• D'une échelle de vraisemblance (par exemple, de 1 à 4, de « rare » à « quasi certain »).
• D'une échelle de conséquences, adaptée aux impacts de l'IA : atteinte aux droits des personnes, biais discriminatoire, dommage réputationnel, non-conformité réglementaire, perte financière.
• D'un seuil d'acceptation du risque, validé par la direction.

L'erreur la plus courante observée dans les démarches de conformité est de reprendre telle quelle une matrice de risques conçue pour la sécurité de l'information, sans y intégrer les dimensions propres à l'IA. Les conséquences d'un biais algorithmique sur une population vulnérable ne se mesurent pas avec les mêmes critères qu'une fuite de données. Il est recommandé d'ajouter des axes de conséquence couvrant l'équité, la transparence et l'impact sociétal, conformément aux thématiques couvertes par l'annexe A de la norme^[8].

Identifier les risques IA

Partir de l'inventaire des systèmes d'IA

L'identification des risques commence par un inventaire des systèmes d'IA dans le périmètre du SMIA. Pour chaque système, il s'agit de décrire sa finalité, les données qu'il consomme, son degré d'autonomie décisionnelle et les parties prenantes affectées. La norme couvre l'ensemble du cycle de vie, de la conception à la mise hors service^[5].

Catégories de risques à considérer

Bureau Veritas identifie, dans le cadre de ses audits ISO 42001, les catégories suivantes : biais, dérive, sécurité et robustesse^[2]. Trend Micro y ajoute l'empoisonnement des données, l'inversion de modèle et les attaques adversariales^[3]. L'annexe A de la norme propose des contrôles de référence couvrant notamment l'atténuation des biais, la gouvernance des données et la réponse aux incidents^[8].

Une grille utile pour structurer l'identification consiste à croiser chaque système d'IA avec les familles de risques suivantes :

Familles de risques IA à couvrir dans l'appréciation

Famille de risque	Exemples concrets
Biais et équité	Discrimination dans un modèle de scoring, sous-représentation d'un groupe dans les données d'entraînement
Dérive de modèle	Dégradation progressive de la précision après déploiement, décalage entre données d'entraînement et données réelles
Sécurité et robustesse	Empoisonnement de données, attaques adversariales, inversion de modèle
Transparence et explicabilité	Impossibilité d'expliquer une décision automatisée à un utilisateur ou à un régulateur
Données et vie privée	Traitement de données personnelles non conforme, rétention excessive de données d'entraînement
Impact sociétal	Effets négatifs sur des groupes vulnérables, conséquences environnementales du calcul

Cette liste n'est pas exhaustive. Chaque organisation doit l'adapter à son contexte, à ses systèmes et à son secteur d'activité.

Analyser et évaluer

Analyse : vraisemblance et conséquences

Pour chaque risque identifié, l'analyse consiste à estimer la vraisemblance de sa survenance et la gravité de ses conséquences. En matière d'IA, cette estimation est souvent plus incertaine que pour des risques informatiques classiques. Un modèle de langage déployé en production peut dériver de manière subtile sans qu'un indicateur technique ne le signale immédiatement.

Il est donc recommandé de combiner plusieurs approches : revue des incidents connus dans le domaine, tests techniques (red teaming, tests de robustesse), avis d'experts métier sur les conséquences en cas de défaillance. La norme ISO/IEC 42001 met l'accent sur la surveillance continue précisément parce que le profil de risque d'un système d'IA évolue après son déploiement^[3].

Évaluation : comparer aux critères et prioriser

L'évaluation consiste à confronter le niveau de risque estimé aux critères d'acceptation définis en amont. Les risques qui dépassent le seuil d'acceptation doivent faire l'objet d'un plan de traitement. Ceux qui se situent en dessous sont acceptés, mais documentés.

Un point souvent négligé : la clause 6.1.2 exige que les résultats soient conservés sous forme d'informations documentées. En audit, l'absence de traçabilité entre un risque identifié et la décision de traitement (ou d'acceptation) constitue une non-conformité. L'audit ISO 42001 vérifie notamment la capacité de l'organisation à démontrer la conformité réglementaire et l'alignement éthique de ses choix^[2].

Lien avec l'annexe A et la déclaration d'applicabilité

L'annexe A de la norme ISO/IEC 42001 contient un catalogue de contrôles de référence spécifiques aux risques liés à l'IA, couvrant par exemple l'atténuation des biais, la gouvernance des données et la réponse aux incidents^[8]. L'annexe B fournit un guide de mise en œuvre pour ces contrôles^[8].

Après l'appréciation des risques, l'organisation doit produire une déclaration d'applicabilité (DdA). Ce document liste les contrôles de l'annexe A retenus, justifie leur sélection en lien avec les risques identifiés, et explique l'exclusion éventuelle de certains contrôles. Mitratech souligne l'importance de la DdA pour documenter les choix de gouvernance IA, y compris dans la gestion des risques liés aux tiers^[7].

Le lien entre l'appréciation des risques et la DdA doit être traçable. Pour chaque risque jugé inacceptable, au moins un contrôle de l'annexe A (ou un contrôle additionnel) doit être assigné dans le plan de traitement. Ce chaînage constitue l'ossature du SMIA au stade de la planification.

Articulation avec le NIST AI RMF et l'AI Act

L'appréciation des risques au sens de la clause 6.1.2 ne se fait pas en vase clos. Deux autres cadres influencent directement la manière dont les organisations structurent cet exercice.

NIST AI RMF : des outils opérationnels complémentaires

Le NIST AI Risk Management Framework est un cadre volontaire et adaptable qui propose des outils concrets pour identifier, évaluer et gérer les risques liés à l'IA^[5]. Selon l'analyse de Damien Soulé publiée en septembre 2025, l'ISO/IEC 42001 fournit le cadre de management, tandis que le NIST AI RMF permet d'opérationnaliser la gestion des risques avec des outils pratiques^[5]. Les organisations peuvent utiliser les fonctions du NIST AI RMF (Govern, Map, Measure, Manage) comme grille méthodologique pour alimenter l'appréciation des risques exigée par la clause 6.1.2.

AI Act : l'approche par niveaux de risque

L'AI Act européen, applicable progressivement jusqu'en 2027, impose des obligations strictes pour les systèmes d'IA à haut risque^[2]. L'ISO 42001 offre une démarche structurante pour se préparer à ces exigences^[2]. L'articulation des trois cadres (AI Act, ISO 42001, NIST AI RMF) favorise l'interopérabilité des pratiques de gouvernance et facilite la conformité dans des environnements réglementaires variés^[5].

En pratique, si votre organisation opère des systèmes classés « haut risque » au sens de l'AI Act, l'appréciation des risques au titre de la clause 6.1.2 devrait intégrer les exigences spécifiques du règlement européen (gestion des risques, transparence, traçabilité, respect des droits). Cela évite de conduire deux exercices parallèles et renforce la cohérence du dispositif.

Pièges fréquents

Recycler une matrice ISO 27001 sans adaptation

L'ISO 42001 partage la structure de haut niveau de l'ISO 27001^[7], ce qui incite certaines organisations à réutiliser leur registre de risques existant en y ajoutant quelques lignes « IA ». Cette approche passe à côté des risques spécifiques : un registre de risques conçu pour la sécurité de l'information ne contient pas de scénarios de biais algorithmique, de dérive de modèle ou d'attaque adversariale. L'appréciation doit être conduite comme un exercice distinct, même si elle peut s'appuyer sur la même méthodologie (ISO 27005 ou équivalent).

Oublier le cycle de vie complet

Les trois cadres (AI Act, ISO 42001, NIST AI RMF) couvrent l'ensemble du cycle de vie des systèmes d'IA, de la conception à la surveillance post-déploiement et à la mise hors service^[5]. Les démarches observées montrent que l'appréciation se concentre souvent sur la phase de développement, en négligeant les risques qui apparaissent après la mise en production (dérive, changement de contexte d'utilisation, évolution des données).

Ne pas impliquer les parties prenantes métier

L'appréciation des risques IA ne peut pas être conduite uniquement par l'équipe technique ou par le responsable conformité. Les conséquences d'un biais dans un modèle de recrutement, par exemple, sont avant tout un risque RH et juridique. La norme exige un engagement de la direction et une gouvernance claire des rôles et responsabilités^[2]. Cela implique d'associer les métiers concernés à l'identification et à l'évaluation des risques.

Confondre appréciation ponctuelle et surveillance continue

L'appréciation des risques au titre de la clause 6.1.2 est un exercice structuré, mais elle ne remplace pas la surveillance continue exigée par les clauses opérationnelles et d'évaluation de la performance. Les systèmes d'IA nécessitent des outils de surveillance spéciaux pour détecter les attaques et les dérives en temps réel^[3]. L'appréciation initiale fixe le cadre, la surveillance continue le maintient à jour.

Exemple : clinique romande et outil de triage IA

Prenons le cas fictif d'une clinique de taille moyenne en Suisse romande qui déploie un outil d'IA pour le triage des patients aux urgences. L'outil analyse les symptômes déclarés, les constantes vitales et l'historique médical pour proposer un niveau de priorité au personnel soignant.

Étape 1 : critères de risque

La direction de la clinique valide une échelle de conséquences à cinq niveaux, intégrant un axe « sécurité du patient » (de « inconfort mineur » à « mise en danger vitale ») et un axe « conformité » (de « écart documentaire » à « violation réglementaire avec sanction »). Le seuil d'acceptation est fixé : tout risque de niveau 4 ou 5 sur l'axe « sécurité du patient » doit être traité.

Étape 2 : identification des risques

L'équipe projet, qui réunit le médecin-chef, le responsable informatique et le DPO, identifie notamment : le biais lié à la sous-représentation de certaines tranches d'âge dans les données d'entraînement, la dérive du modèle si le profil des patients change (par exemple, en période d'épidémie), le risque d'opacité de la décision pour le personnel soignant, et le risque de non-conformité avec la LPD si des données de santé sont traitées au-delà de la finalité déclarée.

Étape 3 : analyse et évaluation

Le biais lié à la sous-représentation est jugé vraisemblable (niveau 3/4) avec des conséquences potentiellement graves (niveau 4/5 sur l'axe sécurité du patient). Il dépasse le seuil d'acceptation et doit être traité. Le plan de traitement renvoie aux contrôles de l'annexe A relatifs à l'atténuation des biais et à la gouvernance des données^[8]. La clinique prévoit un rééchantillonnage des données d'entraînement, un test de biais périodique et une supervision humaine systématique du résultat de triage.

Étape 4 : déclaration d'applicabilité

La DdA de la clinique liste les contrôles de l'annexe A retenus, avec pour chacun la référence au risque correspondant dans le registre. Les contrôles relatifs à la mise hors service sont déclarés applicables, car la clinique anticipe le remplacement de l'outil à moyen terme et doit planifier la transition.

Cet exemple illustre comment l'appréciation des risques structure les décisions concrètes de gouvernance IA, y compris pour une organisation de taille modeste. La rigueur du processus ne dépend pas de la taille de l'organisation, mais de la qualité du chaînage entre risques identifiés, critères d'acceptation et contrôles sélectionnés.

Questions fréquentes

À lire ensuite