Registre des risques IA : le construire clause par clause

Rôle du registre dans le SMIA

Un SMIA sans registre des risques IA, c'est un tableau de bord sans compteurs. Le registre est le document vivant qui consigne chaque risque identifié, son évaluation, la décision de traitement retenue et le responsable désigné. Il constitue la preuve documentaire que l'organisation a mené son appréciation des risques de manière systématique et qu'elle en assure le suivi.

La norme ISO/IEC 42001 ne prescrit pas un format unique de registre. Elle exige en revanche que les résultats de l'appréciation des risques et du traitement soient documentés, traçables et révisés. Le registre est le véhicule naturel de cette exigence. Sans lui, l'auditeur ne dispose d'aucune ligne de traçabilité entre un risque brut et la mesure qui le couvre.

Un cadre de gouvernance efficace crée précisément cette traçabilité : chaque action, chaque décision et chaque flux de données peut être relié à une politique documentée et à un contrôle technique^[2]. Le registre des risques IA est la matérialisation de ce principe dans le périmètre spécifique de l'intelligence artificielle.

Ce que les clauses 6.1 et 8.2 attendent

La clause 6.1 de l'ISO 42001 porte sur la planification des actions face aux risques et opportunités. Elle demande à l'organisation de déterminer les risques liés au système de management de l'IA, d'établir des critères de risque, de mener une appréciation structurée et de planifier le traitement. Pour approfondir la logique de cette clause, consultez la page dédiée à l'évaluation des risques IA.

La clause 8.2 concerne la réalisation opérationnelle de cette appréciation. Elle exige que l'organisation réalise effectivement les appréciations de risques planifiées, à intervalles définis ou lorsque des changements significatifs surviennent. Le registre est le livrable tangible de la clause 8.2 : il prouve que l'appréciation a eu lieu, qu'elle a produit des résultats documentés et que ces résultats alimentent un plan de traitement.

En pratique, la clause 6.1 définit le cadre (critères, méthode, périmètre) et la clause 8.2 en assure l'exécution récurrente. Le registre fait le pont entre les deux. Pour une lecture détaillée de la méthode d'appréciation, l'article sur l'appréciation des risques selon la clause 6.1.2 complète utilement ce qui suit.

Colonnes et structure du registre

Le registre des risques IA n'a pas de gabarit imposé par la norme, mais certaines colonnes sont indispensables pour satisfaire les exigences d'audit. L'objectif est double : permettre la cotation et assurer la traçabilité jusqu'au traitement.

Structure minimale d'un registre des risques IA

Colonne	Contenu attendu
Identifiant du risque	Code unique (ex. R-IA-012) permettant le renvoi vers le plan de traitement
Système IA concerné	Référence à l'inventaire des systèmes IA (lien avec la cartographie)
Description du risque	Formulation précise : source, événement redouté, conséquence
Source du risque	Catégorie selon l'Annexe C (données, modèle, contexte d'utilisation, etc.)
Parties prenantes affectées	Utilisateurs, personnes concernées, organisation
Vraisemblance	Échelle définie dans les critères de risque (clause 6.1.1)
Gravité	Échelle définie dans les critères de risque (clause 6.1.1)
Niveau de risque brut	Résultat de la combinaison vraisemblance × gravité
Décision de traitement	Réduire, transférer, accepter ou éviter
Contrôles existants ou planifiés	Référence aux contrôles de l'Annexe A et au plan de traitement
Niveau de risque résiduel	Après application des contrôles
Propriétaire du risque	Personne nommée, avec autorité suffisante
Date de dernière revue	Preuve de la revue périodique exigée par la clause 8.2

Chaque ligne du registre doit pouvoir être reliée en amont à une source de risque documentée et en aval à un contrôle ou une action du plan de traitement. Cette double traçabilité est ce que l'auditeur vérifiera en priorité.

La colonne « Système IA concerné » mérite une attention particulière. Elle suppose qu'un inventaire des systèmes IA existe en amont. Sur ce point, l'article consacré à la cartographie des systèmes IA détaille la méthode d'inventaire. Sans cet inventaire, le registre des risques flotte dans le vide.

Alimenter le registre : sources de risques

L'Annexe C de l'ISO 42001 fournit une liste indicative de sources de risques propres à l'IA. Elle couvre notamment les risques liés aux données d'entraînement (biais, qualité, représentativité), au modèle lui-même (opacité, dérive), au contexte d'utilisation (mauvais usage, sur-confiance) et à l'environnement technique (dépendance fournisseur, sécurité). Pour un décryptage complet de cette annexe, voyez l'article sur les sources de risques IA selon l'Annexe C.

Les questions de gouvernance à se poser lors de l'alimentation du registre recoupent celles que tout cadre de gouvernance IA soulève : qui a accès aux données d'entraînement et aux paramètres du modèle, comment les résultats de l'IA sont-ils examinés et enregistrés, quelles politiques préviennent les mauvais usages^[2]. Chaque réponse insatisfaisante à ces questions est un risque potentiel à inscrire au registre.

L'évaluation multi-référentielle est une approche qui gagne en pertinence lorsque l'organisation opère sous plusieurs cadres réglementaires. Selon iExperts Consulting, une évaluation des risques alignée sur ISO 31000 peut servir de socle méthodologique commun, sur lequel se greffent ensuite les exigences spécifiques de chaque norme sectorielle^[3]. Cette logique s'applique directement au registre des risques IA : un même risque peut être pertinent sous l'angle ISO 42001, sous l'angle du RGPD et sous l'angle de l'AI Act.

En pratique, les démarches observées montrent que trois à quatre ateliers d'identification suffisent pour une PME disposant de cinq à dix systèmes IA. Chaque atelier réunit le propriétaire du système, un représentant métier et le responsable conformité. Le résultat : une trentaine de risques bruts à évaluer, dont une dizaine se révèlent significatifs après cotation.

Cotation et priorisation

La cotation repose sur les critères de risque définis en amont (clause 6.1.1). Ces critères fixent les échelles de vraisemblance et de gravité, ainsi que les seuils d'acceptabilité. L'article sur les critères de risque IA détaille la manière de calibrer ces seuils.

Deux erreurs reviennent fréquemment. La première consiste à utiliser une échelle trop fine (cinq niveaux de vraisemblance, cinq niveaux de gravité, soit vingt-cinq combinaisons) sans disposer de données suffisantes pour discriminer entre les niveaux adjacents. Une échelle à trois niveaux (faible, modéré, élevé) est souvent plus honnête et plus exploitable. La seconde erreur est de coter la gravité uniquement sous l'angle financier, en oubliant l'impact sur les individus affectés par le système IA. La norme attend explicitement que les impacts sur les personnes soient pris en compte.

La priorisation découle naturellement de la cotation. Les risques dont le niveau brut dépasse le seuil d'acceptabilité doivent être traités en priorité. Ceux qui se situent en zone d'acceptabilité conditionnelle peuvent être acceptés sous réserve de contrôles compensatoires. Le registre doit refléter cette logique par une colonne de décision de traitement claire.

Un point souvent négligé : la cotation du risque résiduel. Après avoir identifié les contrôles existants ou planifiés, le registre doit indiquer le niveau de risque qui subsiste. Si ce niveau résiduel reste au-dessus du seuil d'acceptabilité, la direction doit formellement accepter ce risque résiduel ou décider de mesures supplémentaires.

Du registre au plan de traitement

Le registre des risques IA et le plan de traitement sont deux documents distincts mais indissociables. Le registre identifie et évalue. Le plan de traitement prescrit les actions, les responsables, les délais et les ressources. La clause 6.1.3 de la norme exige que ce plan soit documenté. Pour les détails de sa construction, consultez l'article sur le plan de traitement des risques IA.

Le lien entre les deux documents se fait par l'identifiant du risque. Chaque ligne du plan de traitement renvoie à un ou plusieurs identifiants du registre. Chaque contrôle de l'Annexe A référencé dans le plan est lui-même tracé dans la déclaration d'applicabilité (SoA). Cette triple traçabilité (registre, plan de traitement, SoA) est ce que l'auditeur reconstituera lors de l'audit de certification.

Du risque identifié à la preuve de traitement, quatre documents s'enchaînent.

1Registre des risques IA (identification et cotation)

2Plan de traitement (actions, responsables, délais)

3Déclaration d'applicabilité (contrôles Annexe A retenus)

4Preuves opérationnelles (journaux, tests, revues)

L'auditeur suit cette chaîne dans les deux sens : du risque vers la preuve, et de la preuve vers le risque.

Un registre qui ne pointe vers aucun plan de traitement est un constat documentaire. Un plan de traitement qui ne renvoie à aucun risque identifié est une liste de bonnes intentions. Les deux doivent se répondre ligne à ligne.

Exemple : chatbot RH dans une PME romande

Prenons une PME de services basée à Lausanne, employant 120 personnes, qui déploie un chatbot pour le tri initial des candidatures internes. Le système utilise un modèle de langage hébergé chez un fournisseur cloud européen. Voici comment trois lignes du registre pourraient se présenter.

R-IA-001 : Biais de genre dans le tri des candidatures. Source : données d'entraînement du fournisseur, non auditables par l'organisation. Vraisemblance : modérée (le fournisseur ne communique pas la composition du jeu d'entraînement). Gravité : élevée (discrimination directe sur un processus RH). Niveau brut : élevé. Décision : réduire. Contrôle planifié : test de biais semestriel sur un échantillon de décisions, avec seuil de rejet défini.

R-IA-002 : Fuite de données personnelles via les requêtes au modèle. Source : architecture technique (les CV sont transmis à l'API du fournisseur). Vraisemblance : faible (contrat avec clause de non-rétention). Gravité : élevée (données RH sensibles). Niveau brut : modéré. Décision : réduire. Contrôle existant : anonymisation des CV avant envoi à l'API. Contrôle planifié : audit annuel du respect de la clause contractuelle.

R-IA-003 : Sur-confiance des recruteurs dans les recommandations du chatbot. Source : contexte d'utilisation. Vraisemblance : élevée (observation terrain). Gravité : modérée (décisions RH biaisées sans recours). Niveau brut : élevé. Décision : réduire. Contrôle planifié : formation obligatoire des recruteurs sur les limites du système, revue humaine systématique avant toute décision.

Ces trois lignes illustrent la diversité des sources de risque pour un seul système IA. Le registre complet de cette PME, couvrant ses cinq systèmes IA, compterait probablement entre quinze et vingt-cinq risques documentés.

Pièges fréquents et signaux d'alerte

Le registre fantôme. Un registre créé pour l'audit initial, jamais mis à jour ensuite. La clause 8.2 exige une réévaluation périodique et lors de changements significatifs. Un registre dont la dernière date de revue remonte à plus de douze mois est un signal d'alerte immédiat pour l'auditeur.

La confusion entre risques IA et risques de sécurité de l'information. Les organisations déjà certifiées ISO 27001 ont tendance à recycler leur registre de risques SSI en y ajoutant une colonne « IA ». Le problème : les risques propres à l'IA (biais, opacité, dérive du modèle, impact sur les droits des personnes) n'apparaissent pas dans un registre conçu pour les menaces informatiques classiques. Les deux registres peuvent coexister, mais celui dédié à l'IA doit refléter les sources de risques spécifiques de l'Annexe C.

L'absence de propriétaire nommé. Chaque risque doit avoir un propriétaire identifié, c'est-à-dire une personne disposant de l'autorité et des ressources pour décider du traitement. « L'équipe data » n'est pas un propriétaire. Un nom et une fonction le sont.

La cotation uniforme. Quand tous les risques sont cotés « modéré » ou « élevé » sans discrimination, le registre perd sa fonction de priorisation. Si tout est prioritaire, rien ne l'est. Ce phénomène trahit souvent des critères de risque mal calibrés ou une peur de sous-évaluer un risque face à l'auditeur.

Le registre déconnecté de l'inventaire. Selon ACF Compliance, la réglementation européenne exige un registre complet des systèmes IA, et l'autorité de contrôle ne tolère pas un inventaire partiel^[6]. Si le registre des risques mentionne des systèmes qui n'apparaissent pas dans l'inventaire (ou l'inverse), la cohérence documentaire s'effondre.

Articulation avec l'AI Act et la nLPD

Le registre des risques IA construit selon l'ISO 42001 ne remplace pas les obligations documentaires de l'AI Act ou de la nLPD, mais il peut en constituer le socle. Plusieurs obligations réglementaires trouvent leur réponse naturelle dans un registre bien construit.

L'AI Act impose aux fournisseurs de systèmes à haut risque un système de gestion des risques couvrant l'ensemble du cycle de vie. À la date de publication de cet article (octobre 2026), les obligations de transparence et les sanctions relatives aux modèles à usage général sont déjà applicables depuis août 2026^[6]. Les obligations spécifiques aux systèmes à haut risque de l'Annexe III ont été reportées au 2 décembre 2027 par le Digital Omnibus^[6]. Le registre ISO 42001 peut alimenter directement la documentation de gestion des risques exigée par le règlement européen.

Les autorités de surveillance du marché, désignées par chaque État membre de l'UE, disposent du pouvoir de requérir de la documentation et d'accéder aux journaux d'activité des systèmes IA^[5]. Un registre des risques structuré et à jour constitue une pièce de réponse directe à ces demandes.

Côté suisse, la nLPD n'impose pas de registre des risques IA en tant que tel, mais son exigence d'analyse d'impact relative à la protection des données (AIPD) pour les traitements à risque élevé recoupe largement l'appréciation des risques ISO 42001. Un registre bien conçu, avec une colonne identifiant les traitements de données personnelles, facilite l'identification des cas nécessitant une AIPD.

L'approche multi-référentielle prend ici tout son sens. Plutôt que de maintenir trois registres distincts (ISO 42001, AI Act, nLPD), l'organisation peut enrichir un registre unique de colonnes supplémentaires indiquant la pertinence réglementaire de chaque risque. ISO 31000 fournit un cadre méthodologique commun pour cette consolidation^[3]. Cette approche réduit la charge de maintenance et améliore la cohérence, à condition que les critères de risque soient calibrés pour couvrir les exigences de chaque cadre.

Questions fréquentes

À lire ensuite