A.7 — Données pour les systèmes d'IA
Cinq contrôles sur les données, et un qui met presque tout le monde en difficulté : la provenance. Savoir d'où viennent vos données est plus rare qu'on ne le croit.
Le domaine A.7 compte cinq contrôles : A.7.2 sur les données pour le développement et l’amélioration, A.7.3 sur leur acquisition, A.7.4 sur leur qualité, A.7.5 sur leur provenance, A.7.6 sur leur préparation.
Une précision de localisation, car l’erreur est fréquente : la qualité des données relève d’A.7.4, et non du domaine A.4 qui traite des ressources. A.4.3 recense les données comme ressource ; A.7 s’occupe de ce qu’elles valent et d’où elles viennent.
Ce que l’auditeur regarde
Il prend un système, demande quelles données il utilise, et pose trois questions.
D’où viennent-elles ? C’est A.7.5, la provenance. La question paraît simple et met en difficulté la plupart des organisations, parce que la réponse honnête est souvent « d’une extraction faite il y a deux ans par quelqu’un qui est parti ».
Que valent-elles ? C’est A.7.4. Il ne s’agit pas d’une exigence de perfection mais de critères écrits : complétude, actualité, représentativité au regard de l’usage. Un critère non écrit ne s’audite pas.
Qu’est-ce qu’on leur a fait ? C’est A.7.6, la préparation. Nettoyage, filtrage, rééquilibrage, étiquetage : chacune de ces opérations modifie ce que le modèle apprendra, et chacune devrait être traçable.
Le contrôle qui coince
La provenance, et ce n’est pas un hasard. Elle demande de documenter une histoire, souvent reconstituée après coup.
Le cas typique : un modèle en production a été entraîné sur un extrait d’une base interne, l’extraction a été faite manuellement, personne n’a noté sa date, ses filtres ni son périmètre. Le modèle fonctionne, mais on ne peut ni reproduire le jeu, ni dire si ce qu’il contient est encore représentatif, ni répondre à une question sur un biais constaté.
C’est réparable, et le plus tôt est le mieux : à partir de maintenant, chaque jeu utilisé reçoit sa fiche. Reconstituer l’historique des jeux existants vient ensuite, dans la mesure du possible — une fiche qui dit honnêtement « origine non reconstituable, extraction antérieure à la mise en place du dispositif » vaut mieux qu’une fiche absente, et l’auditeur le comprend.
Trois niveaux de mise en œuvre
Minimal crédible. Une fiche par jeu de données important : d’où il vient, qui l’a validé, à quelle fréquence il est rafraîchi, et les vérifications de base effectuées — valeurs manquantes, valeurs aberrantes, et distribution sur les caractéristiques sensibles quand l’usage le justifie. Quelques lignes par jeu.
Mature. Un référentiel de données où chaque jeu est décrit : propriétaire métier, sensibilité, critères de qualité chiffrés, méthode de préparation standardisée, responsable. Les contrôles de qualité s’exécutent avant chaque usage, et la distribution est suivie dans le temps plutôt que mesurée une fois.
À éviter. Cataloguer chaque table et chaque colonne du patrimoine de données comme un actif d’IA, y compris ce qui ne sert à aucun apprentissage. Ou documenter chaque étape de traitement sous forme de procédures à plusieurs niveaux de diagrammes. L’effet est toujours le même : on ne peut plus tester une idée rapidement, donc on teste sans documenter.
Ce que le domaine ne demande pas
Aucun seuil de qualité, aucune méthode de préparation, aucun outil de catalogage. Il ne demande pas non plus que les données soient parfaites : il demande que vous sachiez ce qu’elles valent au regard de l’usage.
Il n’impose pas davantage de conserver les jeux de données : la traçabilité de ce qui a été utilisé ne suppose pas l’archivage de tout.