Sources de risques IA : décoder l'Annexe C

Le rôle de l'Annexe C dans le SMIA

L'ISO/IEC 42001 est structurée autour d'un système de management de l'IA (SMIA) qui regroupe politiques, rôles, processus et contrôles documentés^[3]. Parmi ses annexes informatives, l'Annexe C occupe une place particulière : elle fournit un catalogue de sources de risques liées à l'IA que l'organisation peut consulter lorsqu'elle conduit son appréciation des risques.

Ce catalogue n'est pas normatif. Il ne crée pas d'obligation directe. Son statut est celui d'un guide, d'une liste de référence que chaque organisation adapte à son contexte^[4]. L'Annexe C ne remplace pas l'analyse : elle l'alimente. Si votre organisation dispose déjà d'un registre de risques mûr (par exemple dans le cadre d'un SMSI ISO 27001), l'Annexe C vient compléter ce registre avec des catégories propres à l'IA que les référentiels classiques ne couvrent pas.

La norme ISO/IEC 42001 suit la structure harmonisée commune aux normes ISO de systèmes de management^[3]. Les organisations familières d'ISO 27001 ou d'ISO 9001 retrouvent donc des mécanismes connus : périmètre, responsabilités de la direction, documentation, audits internes, amélioration continue. L'Annexe C s'inscrit dans cette logique comme un outil d'aide à la clause 6.1, au même titre que l'Annexe A fournit les contrôles et l'Annexe B les objectifs de mise en œuvre.

Le catalogue de sources de risques IA

L'Annexe C recense des catégories de sources de risques spécifiques aux systèmes d'IA. Ces sources couvrent aussi bien des dimensions techniques qu'organisationnelles, éthiques ou sociétales. Parmi les grandes familles identifiées, on trouve notamment les risques liés à la qualité et à la provenance des données, les biais algorithmiques, le manque de transparence ou d'explicabilité des modèles, les atteintes à la vie privée, et les conséquences sur la santé, la sécurité ou les droits des personnes^[6].

La norme met aussi en avant des sources de risques liées au contexte organisationnel : gouvernance insuffisante, absence de compétences internes, dépendance à des tiers pour le développement ou l'exploitation des systèmes d'IA^[8]. Ces catégories rappellent que le risque IA ne se limite pas au modèle lui-même. Un système d'IA performant, déployé dans une organisation qui ne comprend pas ses limites ou qui n'a pas défini de responsabilités claires, génère un risque organisationnel tout aussi réel qu'un biais dans les données d'entraînement.

L'Annexe C mentionne également les risques liés au cycle de vie complet du système d'IA, de la conception à la surveillance post-déploiement^[7]. Cela inclut les risques de dérive du modèle en production, les mises à jour non maîtrisées ou les changements dans les données d'entrée qui modifient le comportement du système sans que l'organisation s'en aperçoive.

Articulation avec la clause 6.1 et l'appréciation des risques

La clause 6.1 de l'ISO 42001 exige que l'organisation identifie les risques et opportunités liés à son SMIA, puis qu'elle conduise une appréciation des risques IA structurée. L'Annexe C intervient en amont de cette appréciation : elle sert de grille de lecture pour s'assurer qu'aucune catégorie de source de risque n'a été oubliée.

En pratique, le processus fonctionne ainsi : l'organisation parcourt le catalogue de l'Annexe C, identifie les sources pertinentes pour chacun de ses systèmes d'IA, puis évalue la vraisemblance et l'impact de chaque risque identifié. Les résultats alimentent ensuite le plan de traitement des risques exigé par la clause 6.1.3.

L'Annexe C ne prescrit ni échelle de probabilité, ni matrice de criticité. L'organisation reste libre de sa méthode d'évaluation^[7]. Cela dit, la norme attend une approche documentée, traçable et reproductible. Si vous utilisez déjà une méthode comme EBIOS RM ou la matrice de risques de votre SMSI, rien n'empêche de l'adapter aux catégories de l'Annexe C.

Utiliser l'Annexe C en pratique

Pour un responsable conformité ou un DPO, l'Annexe C se consulte idéalement lors de deux moments clés. Le premier est la mise en place initiale du SMIA, lorsque l'on construit le registre des risques IA pour la première fois. Le second est la revue périodique, lorsque de nouveaux systèmes d'IA sont déployés ou que le contexte évolue (nouveau fournisseur, nouveau cas d'usage, changement réglementaire).

Voici une approche en quatre étapes pour exploiter le catalogue :

• Dresser l'inventaire des systèmes d'IA dans le périmètre du SMIA (la cartographie des systèmes IA est un prérequis).
• Pour chaque système, parcourir les catégories de l'Annexe C et noter les sources de risques applicables.
• Évaluer chaque risque identifié selon les critères définis par l'organisation (vraisemblance, impact, parties prenantes affectées).
• Documenter les résultats et les lier aux contrôles de l'Annexe A retenus dans la déclaration d'applicabilité.

Cette démarche produit un registre des risques IA qui constitue une pièce documentaire attendue lors de l'audit de certification^[6]. L'auditeur vérifiera non seulement que le registre existe, mais aussi que les sources de risques ont été identifiées de manière systématique et que le traitement est cohérent avec les contrôles déclarés applicables.

Exemple concret : PME romande et chatbot RH

Prenons le cas fictif d'une PME genevoise de 80 collaborateurs qui déploie un chatbot alimenté par un modèle de langage pour répondre aux questions RH de ses employés (solde de vacances, procédures internes, règlement du personnel). L'organisation utilise le système d'IA sans le développer elle-même : le modèle est fourni par un prestataire externe.

En parcourant l'Annexe C, le responsable conformité identifie plusieurs sources de risques pertinentes. D'abord, la qualité des données : le chatbot est entraîné sur des documents internes qui peuvent être obsolètes ou incomplets. Ensuite, la transparence : les collaborateurs qui interagissent avec le chatbot ne savent pas toujours qu'ils échangent avec un système automatisé, ni comment les réponses sont générées. Puis la dépendance au tiers : si le prestataire met à jour le modèle sous-jacent, le comportement du chatbot peut changer sans préavis^[3].

Le responsable note aussi un risque lié à la vie privée : le chatbot traite potentiellement des données personnelles (noms, taux d'occupation, situations familiales). Enfin, un risque de biais : si le modèle a été entraîné sur des corpus qui reflètent des stéréotypes, les réponses pourraient véhiculer des discriminations indirectes, par exemple dans l'interprétation de règles applicables au temps partiel.

Chacune de ces sources est ensuite évaluée, et des contrôles sont sélectionnés dans l'Annexe A pour y répondre. La déclaration d'applicabilité (SoA) documente ces choix et leurs justifications.

Piège fréquent : confondre source de risque et risque

L'une des erreurs les plus courantes observées dans les démarches de mise en conformité est la confusion entre une source de risque et un risque. L'Annexe C liste des sources, c'est-à-dire des origines potentielles de risques. Un biais dans les données d'entraînement est une source de risque. Le risque, lui, est la conséquence possible : par exemple, une discrimination dans les décisions de recrutement assistées par l'IA, avec un impact sur les droits des candidats et une exposition réglementaire pour l'organisation.

Cette distinction n'est pas académique. Elle conditionne la qualité de l'appréciation des risques. Si le registre se contente de lister des sources sans formuler les risques associés (c'est-à-dire les scénarios d'impact concrets), l'évaluation de la vraisemblance et de la gravité devient impossible. Et sans évaluation fiable, le plan de traitement manque de priorisation.

Pour chaque source identifiée via l'Annexe C, formulez le risque sous la forme : « En raison de [source], il existe un risque que [événement] survienne, entraînant [conséquence] pour [partie prenante] ». Cette formulation, classique en gestion des risques, permet de passer du catalogue à l'analyse opérationnelle.

Lien avec les Annexes A et B

L'Annexe C ne fonctionne pas de manière isolée. Elle s'articule avec l'Annexe A (contrôles) et l'Annexe B (objectifs de mise en œuvre) pour former un ensemble cohérent^[3]. L'Annexe A de l'ISO 42001 comprend des contrôles regroupés en catégories couvrant les politiques d'IA, l'organisation interne, les ressources, les évaluations d'impact, les processus de cycle de vie et la gouvernance des données^[3]. Les neuf catégories de contrôles de l'Annexe A constituent la réponse structurée aux risques que l'Annexe C aide à identifier.

Le flux logique est le suivant : l'Annexe C aide à repérer les sources de risques, l'appréciation des risques (clause 6.1) évalue ces risques, et les contrôles de l'Annexe A sont sélectionnés pour les traiter. L'Annexe B précise les objectifs de mise en œuvre de ces contrôles. La déclaration d'applicabilité (SoA) documente quels contrôles ont été retenus ou exclus, et pourquoi.

L'Annexe C alimente l'appréciation des risques, qui détermine les contrôles à retenir.

1Annexe C : identifier les sources de risques

2Clause 6.1 : apprécier les risques

3Annexe A : sélectionner les contrôles

4SoA : documenter l'applicabilité

L'Annexe B précise les objectifs de mise en œuvre des contrôles retenus à l'étape 3.

Cette mécanique est familière aux praticiens d'ISO 27001, où l'Annexe A joue un rôle analogue pour la sécurité de l'information. L'intégration des deux systèmes est d'ailleurs facilitée par la structure harmonisée commune^[3]. Pour les organisations qui gèrent déjà un SMSI, la question de l'intégration d'ISO 42001 à un SMSI ISO 27001 existant se pose naturellement.

Tiers et chaîne de fournisseurs IA

L'Annexe C attire l'attention sur une catégorie de sources de risques souvent sous-estimée : celles liées aux tiers. Lorsqu'une organisation utilise un système d'IA développé ou hébergé par un fournisseur externe, elle hérite de risques qu'elle ne maîtrise pas directement. Les mises à jour du modèle par le prestataire, les changements dans les données d'entraînement, ou l'absence de transparence sur l'architecture du système sont autant de sources de risques à considérer^[8].

Selon la plateforme Mitratech, spécialisée en gestion de la conformité, ISO 42001 élargit le périmètre de la gestion des risques tiers en introduisant des contrôles spécifiques pour les systèmes d'IA gérés par des fournisseurs et partenaires. Les équipes en charge de la gestion des risques tiers doivent désormais évaluer non seulement la sécurité des données et la conformité contractuelle, mais aussi l'équité, l'explicabilité, les mises à jour de modèles et l'usage éthique^[8].

Pour aligner la gestion des fournisseurs IA avec l'Annexe C, plusieurs bonnes pratiques se dégagent :

• Évaluer les pratiques de gouvernance IA du fournisseur dès la phase de sélection^[8].
• Surveiller les modifications apportées aux modèles d'IA tiers et à leur utilisation^[8].
• Exiger des preuves de transparence, d'explicabilité et de contrôles éthiques^[8].
• Prévoir des clauses contractuelles couvrant la réponse aux incidents et le traitement des données^[8].
• Évaluer les sous-traitants du fournisseur (risque de quatrième partie) et les risques IA associés^[8].

Ces pratiques s'appliquent aussi bien aux grandes organisations qu'aux PME. Une entreprise romande qui utilise un outil de scoring crédit fourni par un éditeur SaaS est tout autant concernée qu'un groupe bancaire qui développe ses propres modèles. La différence réside dans l'ampleur de l'analyse, pas dans son principe.

Convergence avec d'autres référentiels

L'Annexe C s'inscrit dans un paysage plus large de référentiels de gestion des risques IA. L'AI Act européen impose une approche fondée sur les risques avec des obligations strictes pour les systèmes à haut risque, notamment en matière de traçabilité, de transparence et de respect des droits^[7]. Le NIST AI RMF, cadre volontaire américain, propose des outils pratiques pour identifier, évaluer et gérer les risques IA^[7]. L'articulation de ces trois cadres permet de couvrir les dimensions techniques, organisationnelles, éthiques et juridiques de la gouvernance de l'IA^[7].

Pour un responsable conformité qui opère en Suisse et exporte vers l'UE, cette convergence est un atout. L'Annexe C de l'ISO 42001 fournit un vocabulaire commun pour identifier les sources de risques, tandis que l'AI Act précise les obligations légales et le NIST AI RMF offre des outils opérationnels complémentaires. Le choix du référentiel IA dépend du contexte réglementaire et des marchés visés, mais l'Annexe C reste un point de départ utile quelle que soit la combinaison retenue.

L'ISO 42001 suit le cycle Plan-Do-Check-Act (PDCA) et s'aligne avec d'autres normes ISO comme ISO 27001 (sécurité de l'information) et ISO 27701 (protection de la vie privée)^[8]. Cette compatibilité structurelle signifie que les sources de risques identifiées via l'Annexe C peuvent être intégrées dans un registre de risques unifié, couvrant à la fois la sécurité de l'information, la protection des données et la gouvernance de l'IA. Pour les organisations qui visent une gestion intégrée des risques, c'est un avantage concret.

Questions fréquentes

À lire ensuite