Qualité des données vision

Pourquoi ce chapitre conditionne tous les autres

Un modèle de détection d'objets, de segmentationChunkingIADécoupage d'un document en segments de taille fixe ou sémantique avant indexation vectorielle, pour optimiser la récupération RAG.Voir dans le glossaire ou de classification d'images n'est jamais meilleur que les donnéesdonné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 qui l'ont formé. Cette évidence est répétée si souvent qu'elle finit par perdre son sens opérationnel — chacun l'approuve, peu la traduisent en pratique de contrôle systématique. Ce chapitre a un objectif précis : donner des critères concrets pour évaluer, avant et après le déploiement, si les données d'un système de vision sont dignes de confiance.

Trois familles de problèmes sont traitées séparément parce qu'elles ont des origines et des remèdes différents. Le 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 est un défaut structurel du jeu de données au moment de sa constitution. La dérivedériveIADégradation progressive des performances d'un modèle après son déploiement, causée par l'évolution des comportements ou du contexte. Elle impose surveillance et réentraînement.Voir dans le glossaire est un décalage qui apparaît après coup, quand le monde change et que le modèle reste figé. Les défauts d'annotationannotationIAProcessus 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 sont des erreurs humaines ou méthodologiques dans l'é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, qui plafonnent la performance atteignable quelle que soit la qualité de l'architecture.

Un modèle de vision entraîné sur des données biaisées, dérivées ou mal annotées produira des métriques d'entraînement excellentes et un comportement de production défaillant. L'écart entre les deux n'est visible qu'en surveillant activement la donnée, pas seulement le modèle.

Le biais dans les jeux de données visuelles

Le mot « biais » est utilisé de façon vague dans le débat public. En ingénierie de la donnée, il désigne un écart systématique entre la distribution des données d'entraînement et la distribution des cas réellement rencontrés en production. Trois formes reviennent constamment dans les projets de vision par ordinateur.

Biais de représentation

Le jeu de données sous-représente ou sur-représente certaines classes, certains contextes ou certaines populations. Un modèle de reconnaissance faciale entraîné majoritairement sur des visages clairs et bien éclairés perdra en précisionprécisionIAProportion des alertes émises par un modèle qui sont justifiées. Elle s'oppose au rappel : améliorer l'une dégrade l'autre.Voir dans le glossaire sur des peaux plus foncées ou des conditions de faible luminosité — non par défaut algorithmique, mais parce que ces cas étaient statistiquement rares dans l'échantillon d'apprentissage. En contrôle qualité industriel, le même phénomène apparaît quand les défauts rares (fissures fines, décolorations légères) sont sous-représentés par rapport aux pièces conformes, ce qui pousse le modèle à privilégier la classe majoritaire.

Biais d'acquisition

Le biais d'acquisition provient des conditions matérielles de capture : type de capteur, angle de prise de vue, résolution, éclairage, compression. Un modèle entraîné exclusivement avec des images issues d'une caméra industrielle particulière peut échouer dès qu'on le déploie sur une ligne équipée d'un capteur différent, même si la scène photographiée est identique. Ce biais est particulièrement insidieux car il n'apparaît dans aucune métrique de diversité de classes — le jeu de données peut sembler équilibré en termes de catégories tout en étant homogène en termes de source d'acquisition.

Biais d'étiquetage

Ce biais provient des choix, conscients ou non, des annotateurs. Un annotateur qui applique un seuil de tolérance plus strict pour une classe que pour une autre introduit un biais systématique qui sera appris comme un signal légitime par le modèle. Ce type de biais est traité plus en détail dans la section sur l'annotation, car il recoupe des problèmes de méthodologie plutôt que de composition du jeu de données.

L'exactitude, le F1-score ou l'IoU calculés sur un jeu de testjeu de testIAPartie des données réservée à l'évaluation finale, à n'utiliser qu'une seule fois. Ajuster le modèle d'après ses résultats sur ce jeu lui ôte toute valeur de mesure indépendante.Voir dans le glossaire issu de la même distribution que l'entraînement ne révèlent aucun biais — ils mesurent la cohérence interne du système, pas sa validité externe. Un modèle peut afficher 97 % d'exactitude sur son jeu de test et échouer massivement sur une sous-population absente de ce jeu de test.

L'annotation : un processus à concevoir, pas à sous-traiter aveuglément

L'annotation est souvent perçue comme une tâche mécanique déléguée à un prestataire externe, avec des consignes sommaires. C'est l'une des causes les plus fréquentes de dégradation silencieuse de la qualité d'un modèle de vision, car les erreurs d'annotation ne se corrigent pas par plus de données : elles se répliquent avec plus de données.

Trois éléments déterminent la qualité d'un pipeline d'annotation :

1. Le guide d'annotation. Un guide ambigu produit des annotations incohérentes même avec des annotateurs compétents. Par exemple, pour la segmentation d'un défaut de peinture, faut-il inclure le halo de transition entre le défaut et la surface saine ? Sans règle explicite et illustrée d'exemples limites, chaque annotateur tranchera différemment.
2. La formation et la calibration des annotateurs. Un onboarding qui se limite à la lecture du guide, sans session de calibration sur des cas litigieux partagés, laisse persister des divergences d'interprétation.
3. Le contrôle de cohérence. Sans vérification a posteriori, les dérives d'interprétation d'un annotateur au fil du temps — fatigue, relâchement du seuil de vigilance, réinterprétation progressive 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 — ne sont jamais détectées.

Mesurer l'accord inter-annotateurs

La métrique de référence pour quantifier la cohérence d'un pipeline d'annotation est l'accord inter-annotateurs (Inter-Annotator Agreement, IAA). Pour des tâches de classification, le kappa de Cohen (deux annotateurs) ou le kappa de Fleiss (plus de deux annotateurs) corrige l'accord brut par l'accord attendu au hasard, ce qui évite de surestimer la fiabilité sur des tâches très déséquilibrées. Pour des tâches de détection ou de segmentation, on utilise plutôt un IoU moyen entre les annotations de plusieurs annotateurs sur un même sous-échantillon.

En pratique, un kappa inférieur à 0,6 sur une tâche censée être objective (présence ou absence d'un défaut visible, par exemple) signale presque toujours un problème de guide d'annotation plutôt qu'un problème de compétence des annotateurs. La réponse n'est pas de remplacer les annotateurs mais de clarifier la consigne et de ré-annoter un échantillon de calibration.

Réservez 5 à 10 % du volume total pour un double ou triple étiquetage indépendant. Le coût supplémentaire est marginal comparé au coût de découvrir, après entraînement, que la moitié du jeu de données repose sur une interprétation erronée de la consigne.

Un projet de contrôle qualité automobile visait à détecter les rayures sur pare-brise avant expédition. Le premier guide d'annotation ne précisait pas de seuil de longueur minimale. Résultat : un annotateur marquait toute micro-rayure visible au zoom, un autre ignorait celles de moins de 3 mm. Le kappa mesuré sur un échantillon de calibration est ressorti à 0,41 — signe d'un désaccord quasi aléatoire au-delà du hasard attendu. Après ajout d'un seuil explicite de 2 mm et d'exemples visuels dans le guide, le kappa est passé à 0,84 sur un nouvel échantillon.

La dérive : quand le monde change plus vite que le modèle

Un modèle de vision déployé en production observe un flux de données qui évolue dans le temps, alors que ses paramètres restent figés depuis l'entraînement. L'écart croissant entre la distribution d'entraînement et la distribution réelle observée en production s'appelle la dérive. Deux formes doivent être distinguées car elles appellent des réponses différentes.

Dérive de covariables (data drift)

La distribution des entrées change, mais la relation entre l'entrée et la sortie attendue reste stable. Exemple : une caméra de surveillance de chantier voit progressivement changer la luminosité ambiante au fil des saisons, ou un fournisseur de matière première change légèrement la teinte d'un composant. Le modèle voit des images statistiquement différentes de celles de son entraînement, alors que la définition de ce qu'il doit détecter n'a pas changé.

Dérive de concept (concept drift)

La relation entre l'entrée et la sortie attendue change elle-même. Exemple : une nouvelle norme de contrôle qualité redéfinit ce qui constitue un défaut acceptable, ou une évolution du produit fabriqué modifie ce qu'on doit considérer comme une anomalie. Le modèle continue de produire des prédictions cohérentes avec son entraînement passé, mais ces prédictions ne correspondent plus à la définition actuelle du problème.

Une dérive de covariables se corrige généralement par un réentraînement avec des données récentes, la tâche restant identique. Une dérive de concept exige d'abord de revoir la définition du problème et le guide d'annotation, sans quoi le réentraînement reproduira une définition obsolète avec des données neuves.

Détecter et surveiller la dérive en production

La dérive ne se détecte pas en observant le modèle seul : elle se détecte en comparant en continu la distribution des données de production à celle de l'entraînement, et en surveillant l'évolution de métriques proxy quand les vraies étiquettes ne sont pas disponibles immédiatement.

Quelques pratiques de surveillance couramment utilisées en vision par ordinateur :

• Suivi des statistiques d'image bas niveau — histogrammes de luminosité, de contraste, de netteté — pour détecter un changement de conditions d'acquisition avant même qu'il n'affecte les prédictions.
• Suivi de la distribution des scores de confiance du modèle. Une baisse progressive de la confiance moyenne, ou un étalement de sa distribution, précède souvent une dégradation mesurable de la performance.
• Détection d'anomalies sur les embeddingsembeddingIAReprésentation numérique dense d'un texte, d'une image ou d'un objet dans un espace vectoriel, utilisée pour la similarité et la recherche sémantique.Voir dans le glossaire — projeter les images de production dans l'espace latent du modèle et surveiller l'apparition de régions non couvertes par les données d'entraînement.
• Audit périodique manuel sur un échantillon aléatoire stratifié des prédictions de production, avec ré-étiquetage indépendant pour recalculer les métriques réelles à intervalle régulier.
• Seuils d'alerte actionnables, définis à l'avance avec les équipes métier, pour déclencher une revue humaine plutôt qu'une décision automatique en cas de dépassement.

Tableau récapitulatif : sources de dégradation et parades

Checklist avant mise en production

• La composition du jeu de données a été analysée par sous-groupe pertinent (source, 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, classe rare) et comparée à la distribution attendue en production.
• Le guide d'annotation contient des exemples limites explicites, pas seulement une définition générale.
• Un accord inter-annotateurs a été mesuré sur un échantillon de calibration, avec un seuil minimal défini avant le lancement de l'annotation à grande échelle.
• Une réserve de données de production récentes, non vues à l'entraînement, sert de jeu de validation externe.
• Des métriques de surveillance de la dérive (statistiques d'image, confiance du modèle, embeddings) sont en place dès le déploiement, pas ajoutées après un incident.
• Des seuils d'alerte et une procédure d'audit humain sont définis avec les équipes métier avant la mise en production.
• Une cadence de ré-audit et de réentraînement est planifiée, indépendamment de toute alerte.

Le silence des métriques n'est pas une preuve de stabilité : l'absence d'alerte ne signifie pas l'absence de dérive si aucun mécanisme de surveillance n'a été mis en place. Un modèle non surveillé en production ne dérive pas moins qu'un modèle surveillé — il dérive simplement sans que personne ne le sache avant que les conséquences métier ne deviennent visibles.

Ce qu'il faut retenir

La qualité d'un système de vision par ordinateur ne se joue pas uniquement au moment de l'entraînement : elle se construit dès la collecte, se contrôle à l'annotation, et se surveille en continu après le déploiement. Traiter le biais, la dérive et les défauts d'annotation comme trois problèmes distincts, avec des méthodes de détection et des parades propres à chacun, évite l'erreur la plus coûteuse du domaine — croire qu'un modèle performant sur son jeu de test restera performant indéfiniment sur un monde qui continue, lui, de changer.