Critères de risque IA : définir l'acceptable (6.1.1)

Pourquoi fixer des critères avant d'évaluer

Toute démarche de gestion des risques IA repose sur une question préalable : à partir de quel niveau un risque devient-il inacceptable pour votre organisation ? La réponse ne se trouve pas dans la norme elle-même, qui se garde bien de fixer des seuils universels. Elle revient à chaque organisme.

L'ISO/IEC 42001 structure un SMIA dont l'un des premiers actes de planification consiste à définir les critères de risque^[7]. Cette étape intervient avant l'identification et l'évaluation des risques proprement dites, car sans référentiel d'acceptabilité, toute cotation reste arbitraire.

Les démarches observées montrent que beaucoup d'équipes se précipitent sur l'inventaire des risques sans avoir posé ces critères. Le résultat : des matrices de risques remplies de scores numériques que personne ne sait interpréter, et que l'auditeur questionnera immédiatement.

Ce que la clause 6.1.1 attend concrètement

La clause 6.1.1 de l'ISO 42001 traite des actions à mener face aux risques et opportunités. En substance, l'organisation doit prendre en compte son contexte (clause 4.1), les attentes de ses parties prenantes (clause 4.2) et le périmètre de son SMIA (clause 4.3) pour déterminer les risques et opportunités à traiter^[7]. Cette détermination suppose de disposer de critères de risque documentés.

La norme ne prescrit pas un format particulier. Elle demande que les critères soient cohérents avec la politique IA de l'organisme et qu'ils permettent de produire des résultats reproductibles. Autrement dit, deux personnes différentes appliquant les mêmes critères au même système IA doivent arriver à des conclusions comparables.

La structure clause par clause de la norme montre que la clause 6.1.1 s'articule avec la clause 6.1.2 (appréciation des risques) et la clause 6.1.3 (traitement des risques). Les critères de risque définis en 6.1.1 alimentent directement l'appréciation des risques selon la clause 6.1.2. Sans critères clairs, la chaîne logique se rompt dès le premier maillon.

Construire une échelle de risque IA

Un critère de risque IA se compose de deux dimensions au minimum : la vraisemblance (probabilité qu'un événement se produise) et la gravité de ses conséquences. Pour l'IA, les conséquences à considérer dépassent le seul préjudice financier. La norme ISO 42001 intègre des préoccupations liées aux biais, à la sécurité, à la robustesse et à la dérive des modèles^[2].

L'échelle de vraisemblance peut être qualitative (rare, peu probable, probable, très probable) ou semi-quantitative (1 à 4). L'échelle de gravité doit refléter les types d'impacts propres à l'IA : atteinte aux droits des personnes, discrimination algorithmique, perte de contrôle sur un modèle autonome, atteinte à la réputation, ou non-conformité réglementaire.

Dimensions de gravité spécifiques à l'IA

La norme invite à considérer les impacts sur les individus et la société, pas seulement sur l'organisation^[5]. Cela signifie que vos critères de gravité doivent inclure des dimensions que l'on ne retrouve pas dans une matrice ISO 27001 classique : impact sur l'équité de traitement, sur l'autonomie décisionnelle des personnes, ou sur la confiance du public envers les systèmes automatisés.

Les sources de risques IA décrites dans l'Annexe C de la norme fournissent un inventaire utile pour calibrer ces dimensions. Chaque source de risque (qualité des données, opacité du modèle, biais d'entraînement) peut être traduite en scénario dont on évalue la gravité selon vos critères.

Exemple d'échelle de gravité adaptée aux risques IA

Niveau	Libellé	Description indicative
1	Négligeable	Désagrément mineur, aucun impact mesurable sur les personnes
2	Modéré	Erreur corrigeable, impact limité sur un petit groupe
3	Grave	Discrimination avérée, atteinte aux droits, perte de confiance
4	Critique	Dommage irréversible, sanction réglementaire, mise en danger

Cette échelle est indicative. Chaque organisation doit la calibrer selon ses systèmes IA, son secteur et son appétit pour le risque. L'auditeur vérifiera que l'échelle existe, qu'elle est documentée et qu'elle est effectivement appliquée lors de l'évaluation.

Définir le seuil d'acceptabilité

Une fois l'échelle posée, il faut tracer la ligne. Quel score combiné (vraisemblance × gravité) rend un risque inacceptable ? Quel score le rend tolérable sous conditions ? Et en dessous de quel seuil considère-t-on le risque comme acceptable sans traitement supplémentaire ?

Ces seuils relèvent d'une décision de la direction, pas d'un calcul technique. La norme ISO 42001 attend un engagement de la direction dans la gouvernance du SMIA^[7]. Fixer les seuils d'acceptabilité fait partie de cet engagement. Un responsable conformité ou un DPO peut préparer la proposition, mais la validation doit venir du niveau décisionnel approprié.

En pratique, on distingue généralement trois zones.

• Zone verte (acceptable) : le risque est connu, documenté, et ne nécessite pas de mesure supplémentaire.
• Zone orange (tolérable sous conditions) : le risque est accepté temporairement, avec un plan de traitement et une échéance de réévaluation.
• Zone rouge (inacceptable) : le système IA ne peut pas être déployé ou maintenu en production tant que le risque n'est pas ramené à un niveau tolérable.

Le plan de traitement des risques (clause 6.1.3) prend le relais pour les risques situés en zone orange ou rouge. Les critères de risque et les seuils d'acceptabilité constituent donc le pont entre l'identification et le traitement.

Articuler critères internes et exigences externes

Vos critères de risque ne vivent pas dans un vide réglementaire. L'AI Act européen, applicable progressivement jusqu'en 2027, impose des obligations strictes pour les systèmes d'IA à haut risque^[2]. Certains dispositifs, notamment dans le domaine médical, sont automatiquement classés comme systèmes à haut risque par le règlement, indépendamment de l'évaluation interne de l'organisation^[3].

Cela signifie qu'un système IA classé « acceptable » selon vos critères internes pourrait être considéré comme « à haut risque » par le cadre réglementaire européen. Vos critères doivent donc intégrer une dimension de conformité réglementaire qui agit comme un plancher : aucun système soumis à des obligations renforcées ne peut être classé en zone verte, même si l'impact interne semble faible.

Pour les organisations suisses qui exportent vers l'UE, cette articulation est particulièrement délicate. Le rapport entre ISO 42001 et AI Act pour l'export mérite une attention spécifique lors de la définition des critères. La norme ISO 42001 offre une démarche structurante pour anticiper ces contrôles^[2], mais elle ne remplace pas l'analyse juridique propre au règlement.

De même, la nLPD suisse ou le RGPD européen peuvent imposer des seuils de facto. Un système IA qui traite des données personnelles sensibles et produit des décisions automatisées individuelles porte un risque réglementaire qui doit se refléter dans vos critères de gravité, quelle que soit la probabilité technique de défaillance.

Exemple romand : critères pour un chatbot RH

Prenons le cas d'une entreprise genevoise de 200 collaborateurs qui déploie un chatbot IA pour le tri de candidatures. Le responsable conformité doit définir les critères de risque avant l'évaluation des risques IA.

Première étape : identifier les dimensions de gravité pertinentes. Pour un chatbot RH, trois dimensions s'imposent. La discrimination (le modèle pourrait défavoriser certains profils sur des critères non pertinents). L'atteinte à la vie privée (le système traite des CV contenant des données personnelles). L'impact sur l'emploi (une décision automatisée peut écarter un candidat sans recours humain).

Deuxième étape : calibrer l'échelle. L'entreprise décide qu'un biais avéré touchant plus de 5 % des candidatures constitue un impact « grave » (niveau 3). Qu'une fuite de données de CV constitue un impact « critique » (niveau 4). Et qu'une erreur de tri corrigée par le recruteur humain dans les 48 heures reste « modérée » (niveau 2).

Troisième étape : fixer les seuils. La direction valide que tout risque de score supérieur ou égal à 9 (sur une matrice 4×4) est inacceptable. Entre 5 et 8, le risque est tolérable avec un plan de traitement documenté et une revue trimestrielle. En dessous de 5, le risque est accepté.

Ce calibrage n'est pas universel. Une institution financière soumise à la FINMA appliquerait des seuils plus bas pour les mêmes dimensions. Un laboratoire de recherche académique pourrait tolérer davantage d'incertitude. Les critères reflètent l'appétit pour le risque de l'organisation, pas une norme sectorielle.

Piège fréquent : critères copiés sans contexte

Le piège le plus courant observé dans les démarches de conformité ISO 42001 consiste à reprendre tels quels les critères de risque d'un autre référentiel, typiquement ceux d'un SMSI ISO 27001 existant, et à les appliquer aux systèmes IA sans adaptation.

L'ISO 27001 et l'ISO 42001 partagent une structure de management compatible^[2], ce qui facilite l'intégration. Mais les critères de risque ne sont pas transposables directement. Un risque de confidentialité des données (dimension ISO 27001) ne capture pas un risque de biais algorithmique ou de dérive de modèle (dimensions propres à l'IA). L'identification et l'évaluation des risques IA couvrent des catégories spécifiques comme les biais, la dérive, la sécurité et la robustesse^[2].

Un autre piège consiste à définir des critères trop granulaires. Une échelle à dix niveaux de vraisemblance et huit niveaux de gravité produit une matrice de 80 cellules que personne n'utilisera de manière cohérente. La reproductibilité, exigence implicite de la norme, suppose une échelle suffisamment simple pour être comprise et appliquée par tous les acteurs concernés.

Enfin, certaines organisations définissent des critères mais ne les relient pas à des décisions concrètes. Si un risque « rouge » ne déclenche aucune action documentée, les critères restent décoratifs. L'auditeur cherchera la preuve que les seuils ont effectivement conduit à des décisions de traitement, de transfert ou d'évitement.

Maintenir les critères dans le temps

Les critères de risque ne sont pas un document figé. La norme ISO 42001 s'inscrit dans une logique d'amélioration continue^[7]. Les critères doivent être revus lorsque le contexte change : nouveau système IA déployé, évolution réglementaire, incident survenu, retour d'audit.

L'entrée en application progressive de l'AI Act, dont les obligations pour les systèmes à haut risque s'appliquent par étapes jusqu'en 2027^[3], constitue un facteur de révision prévisible. Chaque nouvelle échéance peut modifier le plancher réglementaire et donc les seuils d'acceptabilité. Le calendrier des échéances de l'AI Act offre une base pour planifier ces révisions.

La revue de direction (clause 9.3 de la norme) est le moment naturel pour valider que les critères restent adaptés. Documentez la date de dernière révision des critères, les modifications apportées et leur justification. C'est un élément que l'auditeur demandera.

Pour les organisations qui gèrent plusieurs systèmes IA, la question se pose de savoir si les critères sont communs ou spécifiques à chaque système. Les deux approches sont défendables. Des critères communs simplifient la gouvernance. Des critères par système reflètent mieux la diversité des risques. Une approche hybride, avec un socle commun et des dimensions spécifiques par catégorie de système, constitue souvent le meilleur compromis.

La cartographie des systèmes IA de votre organisation vous aidera à déterminer si un jeu unique de critères suffit ou si des adaptations par système sont nécessaires.

Questions fréquentes

À lire ensuite