Dataset vision IA : du POC à la production

En computer vision, beaucoup de projets échouent pour une raison simple : le dataset est traité comme un livrable ponctuel, alors qu’en production, c’est un actif vivant. On collecte des images, on annote, on entraîne, on obtient un bon résultat… puis le terrain change. Et tout ce qui n’a pas été pensé (taxonomie, règles, qualité, inconnus, versioning) revient plus tard, souvent en pleine exploitation.

Chez Skalio, nous considérons qu’un dataset “qui survit” n’est pas forcément un dataset “énorme”. C’est un dataset cohérent, auditable, évolutif et opérable.

Pourquoi le dataset casse en production (même quand le POC est bon)

Un POC est souvent validé dans un cadre “propre” : une configuration stable, une durée courte, et une annotation faite vite pour aller au résultat. En production, la réalité est plus large :

• les conditions changent (éclairage, angle, vitesse, opérateurs),
• les objets changent (packaging, variantes, nouveaux défauts),
• les règles métier changent (tolérances, priorités, exigences qualité),
• les cas rares deviennent ceux qui coûtent le plus.

Un dataset casse quand il n’a pas de structure pour absorber ces évolutions.

Encadré terrain — ce que nous voyons le plus

“On a un dataset qui marche… tant que la caméra, la lumière et le produit ne changent pas.” Le problème n’est pas la quantité d’images. C’est l’absence de règles, de versioning, et de gestion des cas nouveaux.

Taxonomie : la décision la plus chère… si elle est mauvaise

La taxonomie (classes, sous-classes, attributs, périmètre) conditionne la stabilité du modèle, la qualité de l’annotation et votre capacité à analyser les erreurs.

Les erreurs classiques :

• classes trop larges : le modèle “moyenne” et devient fragile,
• classes trop fines : impossibles à apprendre (trop rares) et difficiles à annoter,
• zones grises : deux annotateurs font des choix différents,
• taxonomie “POC” : pensée pour la démo, pas pour l’exploitation.

Une bonne taxonomie répond clairement à trois questions : ce qui compte, ce qui ne compte pas, et ce qui doit remonter comme inconnu.

Règles d’annotation : écrire ce que tout le monde pense “évident”

Sans règles écrites, l’annotation n’est pas reproductible. Et sans reproductibilité, on ne sait plus si une nouvelle version s’améliore vraiment.

Nous recommandons un guide court (1 à 3 pages) :

• définition de chaque classe + exemples / contre-exemples,
• gestion des cas limites (partiellement visible, flou, occlusion),
• règle “hors scope”,
• conventions (formats, noms, attributs).

Deux pages claires valent mieux que des milliers d’images ambiguës.

Qualité : rendre le dataset auditable, pas “discutable”

Pour objectiver, nous travaillons en général sur trois axes :

1. qualité des données (netteté, exposition, diversité),
2. qualité des annotations (cohérence, oublis, erreurs récurrentes),
3. couverture (pas seulement des cas faciles).

Un levier très efficace : un golden set (quelques centaines d’images) annoté avec un soin maximal, stable dans le temps. C’est le repère qui évite l’auto-illusion.

Encadré terrain — un piège courant

Quand un modèle “s’améliore” après une itération, c’est parfois parce que le dataset a changé (splits, règles, ré-annotations) — pas parce que le modèle est meilleur. Le golden set + le versioning évitent ce biais.

Unknowns & OOD : apprendre à “ne pas savoir” proprement

En production, il y aura toujours des cas non vus : nouveaux objets, nouvelles conditions, scènes inattendues. Le piège est de forcer ces cas dans une classe existante “à peu près”. On obtient un dataset propre en apparence… et un modèle fragile.

Nous préférons une approche explicite :

• tracer les cas unknown / out-of-scope,
• ne pas les “noyer” dans une classe existante,
• les convertir en collecte ciblée pour la prochaine itération.

Versioning : dataset v1/v2 comme un produit, pas comme un dossier

Un dataset de production doit être versionné comme du code :

• version taxonomie + version du guide d’annotation,
• traçabilité des ajouts/suppressions/ré-annotations,
• stabilité des splits (train/val/test),
• capacité à expliquer pourquoi une perf change.

Règle simple : si vous voulez pouvoir rollback un modèle, vous devez pouvoir rollback le dataset.

Boucle d’amélioration : collecter moins, mais mieux

Le bon réflexe n’est pas “collecter plus”. C’est collecter ciblé :

• cas où le modèle hésite,
• cas où il se trompe,
• cas unknown,
• cas difficiles (reflets, occlusions, nouvelles références).

Puis itérer : collecte ciblée → annotation selon règles → QA → version dataset → validation → déploiement progressif.

Mini-schéma (logique d’itération)

Prod → erreurs & unknowns → collecte ciblée → annotation + QA → dataset v2 → entraînement → validation → déploiement

Accélérer l’annotation sans casser la qualité : SAM3 (assisté, pas automatique)

Des modèles de segmentation “foundation” comme SAM3 peuvent accélérer la création de masques/contours, surtout sur des scènes complexes. Mais l’essentiel reste inchangé : c’est de l’annotation assistée. Sans taxonomie claire, guide d’annotation, et QA, on accélère… dans la mauvaise direction.

Checklist Skalio (courte) : dataset durable (POC → prod)

• Taxonomie stable + guide d’annotation écrit
• Golden set stable pour mesurer les progrès
• Gestion explicite des unknowns / OOD
• Dataset versionné (traçabilité, reproductibilité)
• Boucle d’amélioration ciblée (erreurs et cas nouveaux)

Conclusion : le dataset est votre produit caché

Un bon dataset, ce n’est pas “un stock d’images”. C’est une base vivante, gouvernée, versionnée, capable d’évoluer avec le terrain.

Chez Skalio, c’est souvent là que nous faisons gagner le plus de temps (et éviter le plus de crises) : transformer un dataset de POC en dataset de production, avec une méthode qui tient quand tout change.