Données et modèles

Pourquoi les données pèsent plus que l'algorithme

Dans la majorité des incidents documentés impliquant un système IAintelligence artificielleIAEnsemble des techniques permettant à un programme d'accomplir une tâche qui demanderait de l'intelligence humaine. Le terme couvre aussi bien les systèmes à règles écrites que ceux qui apprennent de données.Voir dans le glossaire, la cause profonde n'est pas un défaut de l'architecture du modèle, mais un problème de données : un jeu d'entraînement non représentatif, une provenance floue, une contamination entre données d'entraînementdonnéesIAEnsemble d'informations structurées ou non utilisées pour entraîner, évaluer ou alimenter un modèle. La qualité, la quantité et la représentativité des données sont les facteurs décisifs pour les performances en apprentissage automatique.Voir dans le glossaire et données de test, ou une dépendance mal maîtrisée envers un fournisseur externe. Un modèle est un révélateur : il amplifie et fige les propriétés, y compris les défauts, du corpus qui l'a façonné.

L'ISO/IEC 42001 en tire une conséquence directe. Le groupe de contrôles de l'annexe A consacré aux données pour les systèmes IA n'existe pas par formalisme : c'est la reconnaissance que la gouvernance d'un système IA se joue autant, sinon davantage, en amont — sur ce qui nourrit le modèle — qu'en aval, sur ses résultats. Auditer un système IA sans auditer ses données revient à certifier un pont sans inspecter les fondations.

Un modèle qui obtient d'excellents scores de performance ne prouve rien sur la qualité de ses données d'entraînement. Un modèle peut être excellent sur les métriques choisies et structurellement biaisé, mal tracé ou juridiquement fragile en même temps. Les deux évaluations sont indépendantes et doivent être conduites séparément.

Qualité des données : les dimensions à contrôler

La qualité d'un jeu de données ne se résume pas à l'absence d'erreurs de saisie. L'ISO/IEC 42001 attend un contrôle sur plusieurs dimensions distinctes, chacune pouvant faire échouer un système même si les autres sont impeccables :

• Exactitude — les valeurs reflètent-elles la réalité qu'elles prétendent décrire ?
• Complétude — les catégories, populations ou cas de figure pertinents sont-ils tous représentés, ou certains segments sont-ils structurellement absents ?
• Représentativité — la distribution du jeu de données correspond-elle à la distribution réelle rencontrée en production, ou surreprésente-t-elle certains profils ?
• Actualité — les données reflètent-elles encore le monde tel qu'il est, ou datent-elles d'un contextefenêtre de contexteIAQuantité de texte qu'un modèle peut prendre en compte simultanément : question, documents fournis et historique. Au-delà, les éléments les plus anciens sortent du champ.Voir dans le glossaire qui a changé ?
• Cohérence — les mêmes règles de codage, d'étiquetageétiquetageIATravail consistant à associer à chaque exemple la réponse attendue. C'est presque toujours le poste le plus coûteux d'un projet d'apprentissage supervisé.Voir dans le glossaire et de format ont-elles été appliquées uniformément sur l'ensemble du corpus ?
• Licéité — la collecte, le stockage et l'usage des données respectent-ils les bases légales applicables (consentement, intérêt légitime, contrat) ?

Ces dimensions sont indépendantes : un jeu de données peut être parfaitement exact tout en étant gravement non représentatif — cas classique d'un corpus de CV historiques qui reflète fidèlement les décisions passées d'un recruteur, mais reconduit ainsi un biaisbiaisIARégularité correctement apprise dans des données qui ne représentent pas la réalité visée, ou qui enregistrent des décisions passées avec leurs préjugés. Changer d'algorithme ne le corrige pas.Voir dans le glossaire d'exclusion déjà présent dans ces décisions.

Un assureur entraîne un modèle de tarification sur dix ans d'historique de sinistres. Les données sont exactes (chaque sinistre est correctement enregistré) mais datées : elles ne reflètent pas l'évolution récente de la sinistralité climatique. Le modèle reproduit fidèlement un monde qui n'existe plus. Le contrôle qualité doit inclure une vérification explicite de l'actualité, pas seulement de l'exactitude.

L'étiquetage (labellingannotationIAProcessus d'étiquetage manuel des données d'entraînement par des experts humains. La qualité de l'annotation conditionne directement les performances du modèle d'apprentissage supervisé.Voir dans le glossaire) mérite une attentionattentionIAMécanisme par lequel un modèle pondère l'importance de chaque token du contexte lorsqu'il en traite un autre, quelle que soit la distance qui les sépare.Voir dans le glossaire particulière lorsqu'il est réalisé par des annotateurs humains, internes ou externalisés. Un taux d'accord inter-annotateurs faible sur une tâche donnée signale une ambiguïté de la consignepromptIAConsigne ou contexte fourni à un modèle de langage pour orienter sa réponse. La qualité du prompt conditionne souvent la qualité du résultat.Voir dans le glossaire, pas seulement une erreur individuelle — et cette ambiguïté se propage mécaniquement dans le comportement du modèle final.

Provenance et traçabilité : reconstituer l'origine

La provenance répond à une question simple en apparence et redoutable en pratique : d'où vient chaque donnée utilisée, et sous quelles conditions a-t-elle été obtenue ? Sans réponse documentée, l'organisme ne peut ni démontrer la licéité de l'usage, ni réagir efficacement si une donnée problématique est découverte a posteriori — image protégée par le droit d'auteur, donnée personnelle collectée sans base légale, contenu diffamatoire intégré sans filtrage.

La traçabilité attendue couvre :

• la source d'origine de chaque jeu de données (collecte propre, achat, jeu de données public, scraping, génération synthétique) ;
• les conditions d'usage attachées à cette source (licence, consentement obtenu, finalité déclarée au moment de la collecte) ;
• les transformations successives appliquées (nettoyage, filtrage, augmentation, anonymisation) et leur horodatage ;
• le lien vers les versions de modèle ayant utilisé ce jeu de données, pour permettre une reconstitution en cas d'incident.

Les jeux de données publics largement utilisés dans l'industrie ne sont pas nécessairement licites pour tout usage. Un corpus disponible en téléchargement libre peut contenir des données personnelles ou protégées par le droit d'auteur collectées sans consentement explicite. La disponibilité technique n'équivaut jamais à une autorisation d'usage. Vérifier la licence et les conditions d'utilisation d'un jeu de données tiers est une étape obligatoire, pas une précaution optionnelle.

La donnée synthétique — générée par un modèle pour entraîner ou compléter un autre modèle — introduit un cas particulier : elle n'a pas de provenance au sens classique, mais hérite des propriétés, y compris les biais et les erreurs, du modèle générateur. Sa traçabilité doit documenter le modèle et la méthode de génération utilisés, au même titre qu'une source primaire.

Fine-tuning : risques spécifiques et pièges classiques

Le fine-tuningFine-tuningIAAjustement des poids d'un modèle pré-entraîné sur un jeu de données spécifique pour adapter son comportement à un domaine ou une tâche cible.Voir dans le glossaire — le réentraînement partiel d'un modèle pré-entraîné sur un corpus plus restreint et spécifique — est devenu la voie dominante pour adapter un modèle à un usage métier. Il introduit des risques distincts de ceux de l'entraînement complet, souvent sous-estimés parce que le volume de données manipulé est plus faible.

Contamination train/test. Lorsque le corpus de fine-tuningaffinageIAPoursuite de l'entraînement d'un modèle existant sur des données propres à un usage. Il enseigne une manière de répondre, non des connaissances fiables — d'où la préférence pour le RAG en entreprise.Voir dans le glossaire recoupe, même partiellement, les données utilisées pour évaluer le modèle, les métriques de validation deviennent trompeuses : le modèle « a vu » une partie de ce qu'on lui demande de restituer, ce qui gonfle artificiellement ses scores. Ce risque est amplifié quand le corpus de fine-tuning et le jeu d'évaluation proviennent de la même source interne sans séparation stricte.

Oubli catastrophique. Un modèle affiné trop intensément sur un corpus étroit peut perdre des capacités générales acquises lors du pré-entraînement — un modèle spécialisé sur le support client d'un secteur peut devenir moins fiable sur des tâches de raisonnement général qu'il maîtrisait auparavant.

Fuite de donnéesfuite de donnéesIAErreur consistant à laisser entrer dans l'entraînement une information qui n'existera pas au moment réel de la prédiction. Le modèle affiche des scores excellents puis s'effondre en production.Voir dans le glossaire d'entraînement. Un modèle affiné sur des données sensibles (dossiers clients, contrats, échanges internes) peut, dans certaines conditions, restituer des fragments de ces données lors de son usage en production — un risque de fuite qui n'existe pas de la même façon avec un modèle générique non affiné sur ce corpus.

Amplification de biais locaux. Un corpus de fine-tuning restreint, souvent constitué avec moins de rigueur qu'un corpus d'entraînement initial, peut introduire ou amplifier des biais spécifiques à l'organisme (habitudes de rédaction, décisions historiques contestables) qui n'existaient pas dans le modèle de base.

Séparez strictement, dès la constitution des corpus, les données de fine-tuning et les données d'évaluation — idéalement par une séparation temporelle ou par entité plutôt que par un simple tirage aléatoire, qui peut laisser passer des quasi-doublons entre les deux ensembles. Documentez cette séparation comme preuve d'audit à part entière.

Tiers : fournisseurs de données et de modèles

Peu d'organismes entraînent aujourd'hui un modèle depuis zéro. La chaîne réelle mobilise le plus souvent un modèle pré-entraîné fourni par un tiers, éventuellement affiné avec des données elles-mêmes achetées à un courtier de données, le tout exposé via une API dont le comportement peut changer sans préavis. Chaque maillon de cette chaîne est un point où la maîtrise directe de l'organisme s'arrête.

L'ISO/IEC 42001 traite cette réalité comme un cas de gestion des fournisseurs à part entière, avec des exigences documentaires spécifiques :

Une clause contractuelle de notification préalable en cas de changement de version de modèle est l'un des points les plus souvent absents des contrats existants — et l'un des plus coûteux à l'usage. Sans elle, un fournisseur peut modifier le comportement d'un modèle exposé en API du jour au lendemain, et l'organisme cliente découvre la dérive uniquement via ses propres indicateurs de surveillance, après coup.

La responsabilité de l'organisme ne s'efface pas parce qu'un tiers est impliqué. L'ISO/IEC 42001 attend une évaluation documentée de chaque fournisseur significatif de la chaîne, proportionnée au niveau de risque du système final — un modèle utilisé pour une tâche à fort impact (décision affectant des personnes) justifie une diligence plus poussée qu'un usage interne à faible enjeu.

Documentation minimale attendue en audit

Trois documents reviennent systématiquement dans les demandes d'un auditeur ISO/IEC 42001 sur ce périmètre :

1. Un registre des jeux de données utilisés par système IA, avec source, licence, date de dernière mise à jour et lien vers les versions de modèle concernées.
2. Une fiche de diligence fournisseur pour chaque tiers significatif fournissant données, annotation ou modèle, réévaluée à fréquence définie.
3. Un journal des changements de modèle, incluant les changements initiés par un fournisseur externe hors du contrôle direct de l'organisme.

Checklist opérationnelle

• Chaque jeu de données utilisé dispose d'une fiche de provenance (source, licence, date, transformations appliquées)
• La représentativité du corpus est évaluée par rapport à la population réelle d'usage, pas seulement par des métriques globales
• Les corpus de fine-tuning et d'évaluation sont séparés de façon vérifiable
• Chaque fournisseur de données, de modèle ou d'annotation significatif a fait l'objet d'une diligence documentée
• Les contrats fournisseurs incluent une clause de notification en cas de changement de version de modèle
• Un registre centralisé relie jeux de données, versions de modèle et systèmes IA en production

Ce que l'auditeur vérifie

En audit, la question n'est jamais « vos données sont-elles parfaites ? » — aucune ne l'est — mais « pouvez-vous démontrer que vous savez ce que vous utilisez, d'où cela vient, et ce que cela implique ? ». Un organisme capable de produire, pour un système donné, la liste exacte des jeux de données mobilisés, leur provenance et le niveau de diligence appliqué à chaque fournisseur tiers présente un dossier solide, même si certaines de ces données comportent des limites connues et documentées. À l'inverse, un système performant dont personne ne peut retracer l'origine des données d'entraînement constitue une non-conformité, quel que soit son niveau de qualité perçue.

En synthèse

La gouvernance des données et des modèles n'est pas une étape technique isolée : elle conditionne la validité de toutes les autres exigences de l'ISO/IEC 42001 traitées ailleurs dans cette formation — appréciation des risques, cycle de vie, supervision humaine. Un modèle dont les données ne sont pas maîtrisées ne peut pas être correctement évalué, quelle que soit la rigueur du reste du dispositif de management.