Données IA ISO 42001 : gouverner selon l'Annexe A.7

Pourquoi la donnée occupe une place à part dans la norme

La norme ISO/IEC 42001 couvre l'ensemble des dimensions liées à l'IA, dont la qualité des données, la transparence et la conformité réglementaire^[1]. Parmi les contrôles de l'Annexe A, la catégorie A.7 se distingue parce qu'elle traite la matière première de tout système d'IA : les données. Sans gouvernance de la donnée, les autres contrôles (fiabilité, équité, explicabilité) reposent sur du sable.

Pour un éditeur ou fournisseur de solutions IA, cette catégorie n'est pas un détail documentaire. Elle conditionne la capacité à démontrer, lors d'un audit de certification, que les systèmes sont développés et utilisés de manière responsable^[2]. Un modèle entraîné sur des données mal documentées ou biaisées ne satisfera pas les exigences du SMIA, quel que soit le soin apporté aux autres volets.

La donnée est aussi le point de convergence entre la norme et les réglementations applicables. L'AI Act européen impose des exigences de qualité des jeux de données pour les systèmes à haut risque. La nLPD suisse encadre le traitement des données personnelles. L'Annexe A.7 offre un cadre structuré pour répondre à ces obligations de manière cohérente^[5].

Périmètre de l'Annexe A.7

L'Annexe A de l'ISO 42001 regroupe les contrôles que l'organisation sélectionne dans sa déclaration d'applicabilité. La catégorie A.7, intitulée « Données pour les systèmes d'IA » (interprétation de la structure publiée), rassemble les contrôles relatifs à la gestion des données tout au long du cycle de vie d'un système d'IA. Elle couvre, selon notre lecture de la norme, au minimum trois axes : la provenance des données, leur qualité et leur préparation.

Ces contrôles ne sont pas isolés. Ils s'articulent avec la gestion des risques (clause 6.1) et avec l'analyse d'impact des systèmes d'IA. Concrètement, l'évaluation des risques liés aux données alimente la sélection des contrôles A.7, et les résultats de ces contrôles nourrissent à leur tour le suivi de performance du SMIA^[3].

Pour un éditeur qui développe plusieurs produits IA, le périmètre de l'Annexe A.7 s'applique à chaque système couvert par le SMIA. Cela signifie que chaque produit, chaque modèle, chaque pipeline de données doit faire l'objet d'une documentation et d'un suivi adaptés. La structure clause par clause de la norme aide à comprendre comment ces contrôles s'insèrent dans l'architecture globale.

Provenance et traçabilité des jeux de données

Le premier volet de la gouvernance des données IA concerne leur origine. D'où viennent les données d'entraînement ? Qui les a collectées ? Sous quelles conditions juridiques ? Ces questions, banales en apparence, deviennent critiques dès qu'un système d'IA est déployé dans un environnement réglementé.

La norme attend de l'organisation qu'elle documente la provenance de ses jeux de données. Cette exigence va au-delà d'un simple inventaire : il s'agit de tracer le parcours de la donnée, de sa source jusqu'à son utilisation dans le modèle. Pour un éditeur qui agrège des données de sources multiples (données clients, données ouvertes, données synthétiques), cette traçabilité est un exercice non trivial.

En pratique, la traçabilité implique de tenir un registre des jeux de données utilisés pour chaque système d'IA, avec pour chacun la source, la date d'acquisition, les conditions de licence ou de consentement, et les transformations appliquées. Ce registre alimente directement le registre des risques IA, car une donnée mal sourcée constitue un risque juridique et un risque de biais.

Un piège courant : considérer que les données « publiquement disponibles » n'ont pas besoin de traçabilité. Or, une donnée publique peut être soumise à des restrictions d'usage, à des droits d'auteur ou à des biais systémiques non documentés. La norme ne fait pas de distinction entre données publiques et privées dans ses exigences de gouvernance.

Qualité des données : critères opérationnels

La qualité des données figure parmi les dimensions explicitement couvertes par l'ISO 42001^[1]. Mais que signifie « qualité » pour des données destinées à un système d'IA ? La réponse dépend du contexte d'utilisation, ce qui rend l'exercice plus subtil qu'un simple contrôle de complétude.

Plusieurs critères sont généralement retenus dans les démarches observées : l'exactitude (les données reflètent-elles la réalité ?), la complétude (les catégories pertinentes sont-elles représentées ?), la cohérence (les formats et définitions sont-ils uniformes ?), l'actualité (les données sont-elles à jour ?) et la représentativité (le jeu de données couvre-t-il la population cible du système ?).

Critères de qualité des données IA

Critère	Question opérationnelle
Exactitude	Les valeurs correspondent-elles à la réalité mesurée ?
Complétude	Les champs et catégories nécessaires sont-ils renseignés ?
Cohérence	Les formats et définitions sont-ils uniformes entre sources ?
Actualité	Les données reflètent-elles l'état courant du domaine ?
Représentativité	Le jeu de données couvre-t-il la population cible ?

Pour un éditeur, la difficulté réside souvent dans le fait que les données sont fournies par les clients. Le contrôle qualité ne peut alors pas se limiter au pipeline interne : il doit inclure des spécifications claires transmises aux clients sur les données attendues, des contrôles à l'ingestion et des mécanismes de rejet ou d'alerte en cas de non-conformité.

La norme n'impose pas une métrique unique de qualité. Elle demande que l'organisation définisse ses propres critères, les documente et les applique de manière cohérente. C'est une approche par les risques : les critères de qualité doivent être proportionnés à l'impact potentiel du système d'IA^[7].

Préparation des données et biais

Entre la donnée brute et la donnée prête à entraîner un modèle, il y a un processus de préparation qui inclut le nettoyage, la transformation, l'enrichissement et l'étiquetage. Chacune de ces étapes peut introduire ou amplifier des biais. La norme attend que l'organisation identifie et traite les risques de biais dans ses données^[3].

Les menaces spécifiques aux données d'IA dépassent les problèmes classiques de sécurité informatique. L'empoisonnement des données (corruption délibérée des données d'entraînement) et les attaques par inversion de modèle (extraction d'informations sensibles) sont des risques que la conformité cybersécurité standard ne couvre pas^[3]. L'Annexe A.7 fournit le cadre pour intégrer ces menaces dans la gouvernance des données.

Le traitement des biais ne se résume pas à un audit ponctuel avant la mise en production. Il suppose un suivi continu, car les données évoluent, les populations changent et les distributions se décalent. Un éditeur qui commercialise un produit IA sur plusieurs marchés doit vérifier que les données d'entraînement restent représentatives pour chaque contexte d'utilisation.

La documentation de la préparation des données est un livrable attendu. Elle doit décrire les choix effectués (quelles données exclues, quels critères de filtrage, quelles méthodes d'augmentation) et les justifier au regard de l'objectif du système. Cette documentation est un élément que l'auditeur examinera pour vérifier la cohérence entre la politique de données et la pratique réelle.

Lien avec la gestion des risques et l'analyse d'impact

Les contrôles A.7 ne fonctionnent pas en vase clos. Ils s'inscrivent dans le processus global de gestion des risques du SMIA, tel que décrit dans la clause 6.1. L'évaluation des risques IA doit identifier les risques liés aux données, et les contrôles A.7 constituent une partie de la réponse à ces risques.

L'analyse d'impact des systèmes d'IA, qui évalue les conséquences potentielles sur les individus et les groupes, dépend directement de la qualité et de la représentativité des données. Un système entraîné sur des données non représentatives produira des résultats biaisés, ce qui se traduit par un impact disproportionné sur certaines populations. L'Annexe A.7 et l'analyse d'impact sont donc liées par une relation de cause à effet.

Pour un éditeur, cette articulation a une conséquence pratique : le registre des risques doit contenir des entrées spécifiques aux données. Chaque jeu de données utilisé par un système d'IA devrait être évalué en termes de risques de biais, de risques de qualité insuffisante et de risques juridiques liés à la provenance. Ces risques alimentent ensuite le plan de traitement et la sélection des contrôles dans la déclaration d'applicabilité^[5].

La norme encourage une approche proportionnée. Un système d'IA qui classe des tickets de support n'exige pas le même niveau de rigueur sur les données qu'un système qui évalue des demandes de crédit. L'éditeur doit calibrer ses contrôles A.7 en fonction de la criticité de chaque système, telle qu'établie par l'analyse de risques^[7].

Exemple : un éditeur de logiciel en Suisse romande

Prenons le cas fictif d'un éditeur basé dans l'Arc lémanique qui développe un outil de scoring pour le secteur immobilier. Le modèle utilise des données de transactions, des caractéristiques de biens et des indicateurs socio-économiques par commune.

Pour satisfaire les contrôles A.7, cet éditeur devrait d'abord documenter la provenance de chaque source : registre foncier cantonal (données publiques, mais soumises à des conditions d'utilisation), données de l'Office fédéral de la statistique, données propriétaires collectées auprès de clients. Chaque source fait l'objet d'une fiche dans le registre des jeux de données.

Ensuite, la qualité doit être définie par rapport à l'usage. Pour un scoring immobilier, la représentativité géographique est un critère déterminant : un modèle entraîné principalement sur des données genevoises ne sera pas fiable pour le marché valaisan. L'éditeur doit documenter cette limite et, le cas échéant, restreindre le périmètre d'utilisation du produit.

La préparation des données soulève la question des biais. Les prix immobiliers reflètent des dynamiques socio-économiques qui peuvent être discriminatoires. L'éditeur doit analyser si certaines variables (code postal, composition démographique) introduisent un biais indirect et documenter les mesures prises : exclusion de variables sensibles, tests d'équité sur les résultats, suivi en production.

Ce type de démarche, appliqué à chaque produit couvert par le SMIA, constitue la mise en pratique de l'Annexe A.7. Le certificat SQS ou celui d'un autre organisme accrédité en Suisse validera la cohérence de cette approche lors de l'audit^[7].

Pièges fréquents lors de l'audit

Les démarches observées révèlent plusieurs écueils récurrents lorsque les organisations abordent la gouvernance des données IA.

Confondre gouvernance des données classique et gouvernance des données IA. Un éditeur qui dispose déjà d'un système de management ISO 27001 peut être tenté de considérer que sa politique de gestion des données couvre les exigences de l'Annexe A.7. Or, la sécurité de l'information et la gouvernance des données IA ne se recouvrent que partiellement. L'ISO 27001 protège la confidentialité, l'intégrité et la disponibilité. L'Annexe A.7 ajoute des dimensions spécifiques : représentativité, biais, adéquation au cas d'usage^[3]. L'intégration des deux référentiels demande un travail d'articulation, pas une simple extension.

Documenter sans vérifier. Produire une politique de qualité des données sans mécanisme de contrôle effectif est un écueil classique. L'auditeur cherchera des preuves que les critères définis sont réellement appliqués : rapports de contrôle qualité, logs de rejet de données non conformes, résultats de tests de biais. La documentation seule ne suffit pas.

Ignorer les données de production. La gouvernance des données ne s'arrête pas à l'entraînement du modèle. Les données traitées en production (données d'entrée des utilisateurs, données de feedback) doivent aussi être couvertes. Un système qui apprend en continu, par exemple, ingère des données de production qui modifient son comportement. Sans contrôle sur ces données, le système peut dériver de manière imprévisible^[3].

Négliger la chaîne de sous-traitance. Si l'éditeur utilise des données fournies par des tiers (API, datasets commerciaux, données clients), la responsabilité de la qualité et de la provenance ne disparaît pas. La norme attend que l'organisation évalue et surveille ses fournisseurs de données, comme elle le ferait pour tout fournisseur critique dans un système de management^[5].

Sous-estimer l'effort de maintenance. La gouvernance des données est un processus continu, pas un livrable ponctuel. Les jeux de données vieillissent, les distributions changent, de nouvelles réglementations apparaissent. Le SMIA doit prévoir des revues périodiques des données, alignées sur le cycle d'amélioration continue prévu par la norme^[2]. La certification elle-même prévoit un audit de suivi annuel et une recertification après trois ans^[7], ce qui impose de maintenir la gouvernance des données dans la durée.

Questions fréquentes

À lire ensuite