Les modèles IA adorent les données… mais seulement quand elles sont propres. Dans la pratique, la « curation » de dataset (nettoyage, choix, organisation) explique souvent plus de la performance finale que l’architecture du modèle. Ce guide propose une méthode simple pour constituer un dataset fiable, reproductible et légalement sain, sans jargon inutile.
Objectif — Obtenir un dataset qui: (1) représente bien votre problème; (2) évite les doublons et contenus « toxiques »; (3) respecte les licences; (4) se maintient dans le temps sans s’effondrer sous son propre poids.
Idée clé — La taille brute ne compense pas des données mal étiquetées, déséquilibrées ou juridiquement risquées. Mieux vaut 200 000 exemples propres que 2 millions douteux.
1) Définir le périmètre utile — Avant d’ingérer « tout Internet », clarifiez votre cible.
Public et usages: pour qui et pourquoi le modèle sera‑t‑il utilisé ?
Domaine: documents techniques, emails clients, articles presse, tickets support…
Sortie du modèle: classification binaire, multi‑classe, génération de texte court, extraction de champs, etc.
Contraintes: langue, longueur, confidentialité, réglementation sectorielle.
Rédigez une page « contrat de dataset »: ce que le dataset contient, ce qu’il exclut, et pourquoi. Cette page devient votre référence quand vous hésiterez plus tard.
2) Collecte contrôlée — La collecte sauvage produit des surprises. Préférez des sources stables et documentées.
Sources internes: base de tickets, FAQ, manuels, dépôts de code. Avantage: droits clairs, contexte métier.
Sources externes: jeux publics (Hugging Face, Kaggle), sites sous licence ouverte, partenaires. Vérifiez les conditions exactes d’usage.
Évitez les zones grises: scraping de sites sans licence claire, contenus « user‑generated » sans consentement explicite.
Conseil pragmatique: commencez avec 2–3 sources fiables. Ajoutez ensuite des incréments en lots, chacun évalué.
3) Déduplication et quasi‑doublons — Les doublons faussent l’entraînement et les métriques. Ils gonflent la confiance du modèle sans apporter d’information nouvelle.
Déduplication exacte: hashs (SHA‑1/MD5) sur textes normalisés (minuscules, espaces normés). Rapide et efficace.
Quasi‑doublons: similarité (embeddings, MinHash) pour repérer du contenu très proche (quotes, retweets, copier‑coller).
Règle de conservation: garder la version la plus longue, la plus récente ou la mieux étiquetée.
Traces: conservez un fichier « dedup_report.csv » (id_source, id_conserve, score_similarité) pour audit.
Erreurs courantes: dédupliquer après split en train/val/test (fuite d’info) ou ignorer les versions proches d’un même article. Faites la déduplication en amont, puis découpez les splits.
4) Nettoyage simple et utile — Ne passez pas des semaines à micro‑nettoyer; ciblez ce qui casse les modèles.
Textes: retirer les binaires, HTML résiduels, entêtes/pieds; normaliser les espaces; corriger les encodages.
PII: anonymiser/pseudonymiser emails, téléphones, identifiants; retirer les données sensibles non nécessaires.
Langue: filtrer la langue cible (fr/en) avec un détecteur léger; écarter les mixes incohérents.
Longueurs: couper ou exclure les extrêmes si votre modèle n’en tire rien (ex: prompts > 32k tokens).
Astuce: gardez un « trash bin » avec identifiants des éléments écartés et la raison (spam, PII, hors domaine). Utile pour expliquer vos choix et éviter de retraiter les mêmes erreurs.
5) Équilibrage (balance) des classes/segments — Un dataset trop déséquilibré rend le modèle paresseux (ex: 95% de « non » → tout prédire « non » et avoir 95% d’accuracy…).
Photographier la distribution: par classe, domaine, période, longueur, langue.
Actions possibles: sur‑échantillonnage des classes rares, sous‑échantillonnage des classes dominantes, re‑pondération à l’entraînement.
Capter la « longue traîne »: inclure des cas peu fréquents mais salutaires (corner cases, dialectes, formats exotiques).
Éviter la sur‑correction: un dataset artificiellement plat peut dégrader la performance en production si la réalité est déséquilibrée. Calibrez selon la cible d’usage.
Mini‑exemple — Vous entraînez un classifieur d’emails « urgent / non urgent ».
Distribution brute: 8% urgent, 92% non urgent.
Plan: dupliquer x3 les « urgent » (ou en collecter activement), et sous‑échantillonner légèrement « non urgent » pour viser ~25/75. Conserver un set d’évaluation réaliste à 8/92 pour ne pas se mentir sur la perf réelle.
6) Qualité des étiquettes (labels) — Un label bruité vaut mieux que pas de label, mais un label systématiquement faux ruine l’entraînement.
Guide d’annotation: définitions, exemples positifs/négatifs, cas limites, décisions d’arbitrage écrites.
Échantillon double‑annoté: 5–10% revu par deux personnes; calcul de l’accord (Cohen’s kappa, simple % d’accord). Si désaccords fréquents → améliorer le guide.
Outils: interfaces simples, consignes visibles, raccourcis; export JSON/CSV stable.
Contrôles: injecter des « gold labels » connus pour vérifier attention et cohérence.
7) Découpage train/val/test sans fuites — La fuite d’information gonfle artificiellement vos métriques.
Règle d’or: splitter par entité logique (utilisateur, entreprise, document) plutôt que par ligne brute quand il existe de la corrélation.
Période: pour des systèmes sensibles au temps (news, prix), faire un split par chronologie (train passé, test futur).
Geler le test: ne modifiez pas le test en cours de route; si vous devez le changer, conservez l’ancien pour comparaison historique.
8) Licences et conformité — Un dataset doit être défendable juridiquement.
Registre des sources: pour chaque origine, notez la licence (MIT, CC‑BY, CC‑BY‑SA, « usage interne », etc.), l’URL, la date d’acquisition et la preuve (capture/snapshot).
Conditions: usage commercial autorisé ? Redistribution permise ? Obligation d’attribution ? Clauses « non‑dérivées » ?
Données personnelles: base légale (consentement, contrat), minimisation, droit d’accès/suppression. Évitez les sensibles (santé, opinions) sauf cas strictement encadrés.
Partenaires: clauses spécifiques (confidentialité, réversibilité, audit). Ne mélangez pas sans autorisation des jeux à licences incompatibles.
9) Documentation légère mais utile — Deux fichiers suffisent souvent:
DATASET.md (datasheet): origine, volume, domaine, nettoyage appliqué, limites connues, métriques de base, date de version.
DATA_LICENSES.csv: source, licence, obligations d’attribution, URL, date, note interne.
Ajoutez un CHANGELOG.md des versions (v0.3 → +50k emails support, nouveau label « remboursement »; correction PII sur 2k tickets, etc.).
10) Métriques de santé d’un dataset — Comme pour un service, on surveille la « santé » des données.
Base: nombre d’items, taux de doublons, part par classe/segment, longueur médiane, langue, taux d’items écartés.
Qualité: taux d’accord entre annotateurs, taux d’erreurs détectées en revue, couverture des cas rares.
Évolution: deltas par version; alerte si une classe chute de 30% sans raison.
11) Gouvernance et pipeline — Un dataset vit et se met à jour.
Ingestion par lots: chaque lot passe par le même pipeline (nettoyage, déduplication, PII, contrôles, rapport).
Revue rapide: quelqu’un signe le lot (OK/KO) avec commentaires. Si KO, corrigez puis re‑passez le pipeline.
Traçabilité: chaque item peut raconter son histoire (source → transformations → version). Un simple identifiant de lot + journal suffit.
12) Étude de cas condensée — Chatbot support d’un e‑commerce.
Périmètre: tickets clients FR, FAQ, guides internes. Sorties: classement « sujet » + génération de réponses.
Collecte: 300k tickets (3 ans), 1k FAQ, 200 guides; suppression PII (emails/tel/commandes). Langue = FR detected.
Déduplication: hash + MinHash; ‑7% d’items.
Balance: certains sujets rares (« douanes », « point relais fermé »). Sur‑échantillonnage pour l’entraînement, mais test reste réaliste.
Labels: 20 sujets; 8% d’échantillon double‑annoté → kappa=0,71 après révision du guide.
Splits: par client (entreprises), pas par ticket, pour éviter fuite sur phrases répétitives.
Résultat: +6 pts F1 macro vs dataset brut, baisse de 18% des réponses « hors sujet ».
Erreurs fréquentes à éviter —
Mesurer la perf sur un test contaminé par des doublons du train.
Oublier la représentativité (dataset « parfait » mais loin des cas réels).
Ignorer les licences (« tout le monde le fait ») jusqu’au jour où…
Sous‑investir dans les labels: un guide flou sabote la cohérence.
Mettre à jour le dataset sans versionner: impossible d’expliquer un changement de perf.
Checklist finale (copier‑coller) —
Périmètre écrit et assumé (qui/quoi/pourquoi).
Collecte depuis 2–3 sources propres; preuves de licence stockées.
Déduplication exacte et quasi‑doublons; rapport conservé.
Nettoyage ciblé (HTML, encodages, langue, PII).
Distribution par classes/segments analysée; plan d’équilibrage décidé.
Guide d’annotation + double lecture sur 5–10%; gold labels injectés.
Splits sans fuite (entité/temps), test gelé.
Fichiers DATASET.md, DATA_LICENSES.csv, CHANGELOG.md à jour.
Métriques de santé suivies par version; alertes sur dérives.
Pipeline d’ingestion « lot → contrôles → revue → version » opérationnel.
En gardant cette discipline simple, vous obtenez un dataset qui vieillit bien, supporte des itérations rapides et vous évite des casse‑têtes juridiques. Les meilleurs modèles démarrent rarement d’un miracle d’architecture; ils naissent de données soignées. original: true category: Guide tags:
Données
Datasets
Qualité permalink: /guides/dataset-curation-2025/