Les données : le vrai facteur limitant

Le facteur décisif

Dans un projet d'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, l'algorithme est rarement le problème. Les architectures performantes sont publiques, documentées et disponibles en bibliothèques libres. Ce qui distingue un projet qui aboutit d'un projet qui échoue, ce sont presque toujours 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.

Un modèle ne peut pas dégager une régularité absente de ses données, ni corriger une erreur systématique qu'elles contiennent. Il reproduit fidèlement ce qu'on lui a montré — y compris ce qu'on aurait préféré ne pas lui montrer.

Un modèle apprend les régularités de ses données d'entraînement, pas la vérité du monde. Si vos données historiques reflètent une pratique discriminatoire passée, le modèle la reproduira — et lui donnera l'apparence d'une objectivité mathématique.

Les trois jeux de données

Le jeu disponible se découpe en trois parts distinctes :

La séparation doit être étanche. Le même individu, le même document, la même transaction ne doit jamais figurer dans deux jeux à la fois.

Le découpageChunkingIADé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 naïf au hasard ne suffit pas toujours. Trois situations imposent une stratégie explicite :

• Données temporelles — prédire le mois prochain avec des exemples du mois prochain dans l'entraînement est une fuite déguisée. Découpez chronologiquement.
• Données groupées — plusieurs messages du même client, plusieurs clichés du même patient. Séparez par groupe, pas par ligne.
• Classes rares — un tirage aléatoire peut vider le 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 de la classe qui compte. Stratifiez.

La 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 (data leakage) est l'erreur la plus fréquente et la plus coûteuse. Elle survient quand une information indisponible au moment de la prédiction se glisse dans l'entraînement. Exemple typique : entraîner un modèle de prévision d'impayé en incluant la variable « relance envoyée » — laquelle n'existe qu'après l'incident. Le modèle affiche 99 % de réussite en test, et s'effondre en production.

Scénario : la fuite qui flatte le comité

Une équipe présente un score de 94 % pour prédire les résiliations. En audit, on découvre que la variable « motif de clôture » — renseignée après la résiliation — a été conservée dans le fichier d'entraînement par jointure automatique. Retirée, le score tombe à 61 %, à peine au-dessus d'une heuristique métier. Le projet n'était pas « presque prêt » : il n'avait jamais été évalué.

La parade est disciplinaire autant que technique : une revue des variables avec la question « cette information existe-t-elle au moment où nous devons prédire ? », conduite par quelqu'un qui n'a pas construit le modèle.

Sous-apprentissage et surapprentissage

Deux échecs symétriques guettent tout entraînement.

Le sous-apprentissagesous-apprentissageIADéfaut d'un modèle trop simple pour le problème posé : il se trompe autant sur les données d'entraînement que sur les nouvelles.Voir dans le glossaire décrit un modèle trop simple pour le problème : il se trompe autant à l'entraînement qu'en test. La correction est directe — augmenter la capacité, enrichir les variables, entraîner plus longtemps.

Le surapprentissagesurapprentissageIADéfaut d'un modèle qui mémorise ses exemples d'entraînement au lieu d'en dégager des régularités. Il excelle sur les données vues et échoue sur toute donnée nouvelle.Voir dans le glossaire est plus insidieux. Le modèle mémorise les exemples au lieu d'en extraire des régularités. Il obtient des résultats excellents à l'entraînement et médiocres sur toute donnée nouvelle. Un élève qui apprend par cœur les annales sans comprendre la matière échouera dès que l'énoncé changera.

Les parades sont connues : augmenter le volume de données, simplifier le modèle, interrompre l'entraînement au point optimal (early stoppingarrêt anticipéIAInterruption de l'entraînement au moment où l'erreur de validation cesse de diminuer, avant qu'elle ne remonte. C'est la parade la plus simple au surapprentissage.Voir dans le glossaire), ou recourir à la régularisation, qui pénalise la complexité excessive.

Ce que « données de qualité » signifie

Représentativité — les données doivent couvrir les situations réelles d'usage. Un modèle de reconnaissance vocale entraîné sur des locuteurs d'une seule région échouera ailleurs.

Volume suffisant — quelques centaines d'exemples permettent parfois d'affiner un modèle existant, jamais d'en entraîner un depuis zéro.

É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 fiable — des étiquettes erronées placent un plafond infranchissable sur la performance. Faire annoter un échantillon par plusieurs personnes et mesurer leur accord est un investissement rentable.

Équilibre des classes — si 99 % des transactions sont légitimes, un modèle qui répond toujours « légitime » atteint 99 % de 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 sans détecter la moindre fraude.

Fraîcheur — un historique de cinq ans peut contenir des régimes obsolètes (produits retirés, process changés). Plus n'est pas toujours mieux si le passé ne ressemble plus au présent.

Ne jugez jamais un modèle sur sa seule précision globale. Sur des classes déséquilibrées, cet indicateur est trompeur. Regardez le rappelrappelIAProportion des cas positifs réels effectivement détectés par un modèle. Sur un jeu déséquilibré, c'est un indicateur bien plus parlant que l'exactitude globale.Voir dans le glossaire — quelle proportion des cas positifs est effectivement détectée — et la précision — quelle proportion des alertes est justifiée. Le bon arbitrage dépend du coût respectif d'un faux positif et d'un faux négatif.

Bruit d'étiquette et accord entre annotateurs

Avant d'acheter plus de données, mesurez la cohérence de celles que vous avez. Faites annoter le même échantillon par deux personnes indépendantes.

Un modèle entraîné sur des étiquettes incohérentes plafonne près du taux d'accord humain. Améliorer l'architecture ne franchit pas ce plafond : il faut clarifier le guide d'annotation, fusionner des catégories ambiguës, ou accepter qu'une part des cas reste hors automate.

Les biais et leur origine

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 n'est pas une défaillance technique : c'est une régularité bien apprise, dans des données qui ne représentent pas ce que l'on croyait.

• Biais de sélection — l'échantillon ne reflète pas la population visée.
• Biais historique — les données enregistrent des décisions humaines passées, avec leurs préjugés.
• Biais de mesure — l'instrument de collecte fausse lui-même l'observation.
• Biais d'automatisation — les humains accordent une confiance excessive à la sortie du système, parce qu'elle paraît objective.

Aucun de ces biais ne se corrige en changeant d'algorithme. Il faut revenir aux données, et à la façon dont elles ont été produites.

« Notre modèle est neutre, ce sont les données » n'est pas une décharge. Dès que vous déployez, vous assumez le comportement du système. Documenter l'origine des biais est le début du travail, pas la fin de la responsabilité.

La dérive en production

Un modèle déployé se dégrade avec le temps : les comportements évoluent, l'offre change, la réglementation aussi. C'est 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 — des données comme du concept lui-même.

Deux formes à distinguer :

• Dérive des entrées — la distribution des variables change (nouveaux produits, nouvelle typographie de factures).
• Dérive du concept — la relation entre entrées et cible change (ce qui définissait une « urgence » il y a un an ne la définit plus).

Un dispositif de surveillance est donc indispensable : suivi des indicateurs de performance, détection des écarts de distribution, et réentraînement périodique. Un projet d'IA n'a pas de date de fin ; il a un cycle de vie.

Sans jeu de contrôle figé, vous ne saurez jamais si le modèle a dérivé ou si le métier a simplement changé de définition. Conservez un échantillon de référence annoté à la main, réévalué à intervalle fixe.

Lire une matrice de confusion

Évaluer un modèle de classification suppose de savoir lire quatre nombres. Prenons un détecteur de fraude évalué sur 10 000 transactions dont 100 sont frauduleuses.

De ces quatre cases se déduisent les indicateurs qui comptent :

• Rappel = 80 / (80 + 20) = 80 % — la proportion de fraudes effectivement détectées.
• Précision = 80 / (80 + 400) = 17 % — la proportion d'alertes justifiées.
• Exactitude globale = (80 + 9 500) / 10 000 = 96 % — le chiffre flatteur, et le plus trompeur.

Un modèle qui ne détecterait aucune fraude afficherait 99 % d'exactitude. Ce seul chiffre ne dit donc rien.

Le seuil de décision — au-dessus de quelle probabilité alerter — est un levier métier, pas un détail technique. L'abaisser augmente le rappel et dégrade la précision ; l'inverse est vrai. Ce levier doit être réglé avec les coûts réels des deux erreurs, puis revu quand ces coûts changent.

Précision et rappel s'opposent : améliorer l'un dégrade l'autre. Le bon arbitrage dépend entièrement du coût respectif des deux erreurs. Manquer une fraude coûte le montant du préjudice ; lever une fausse alerte coûte le temps d'un analyste. Ce sont ces deux montants, et non un critère technique, qui doivent fixer le seuil de décision.

Cas chiffré : ce que l'annotation coûte vraiment

Une entreprise souhaite classer automatiquement ses courriels entrants en huit catégories. Le calcul réel :

Soit près de sept jours-homme, avant la moindre ligne de code. Ce poste est presque toujours absent des chiffrages initiaux, et il explique une bonne part des dépassements.

Ajoutez le coût de maintenance : chaque trimestre, un échantillon de production doit être réannoté pour mesurer la dérive. Comptez 10 à 20 % du volume initial par an si le domaine bouge. Un projet « terminé » sans budget d'annotation continue est un projet qui se dégrade en silence.

Bonne pratique. Faites annoter un échantillon de 100 exemples par deux personnes différentes avant de lancer la campagne complète. Si leur taux d'accord est inférieur à 80 %, ce n'est pas l'annotation qui est en cause : c'est que vos catégories sont mal définies. Aucun modèle ne saura trancher ce que deux experts ne tranchent pas de la même façon.

Ce que l'audit des données doit produire

Avant le premier entraînement sérieux, un audit utile livre au minimum :

1. Inventaire — sources, volumes, fraîcheur, droits d'usage.
2. Schéma de séparation — entraînement / validation / test, avec la règle anti-fuite (temps, groupe, strate).
3. Qualité d'étiquette — accord inter-annotateurs sur un échantillon.
4. Équilibre — effectifs par classe et décision sur le sous-échantillonnage ou la pondération.
5. Risques — variables proxies sensibles, historiques discriminants, champs postérieurs à l'événement.

Sans ces cinq points écrits, vous n'avez pas audité : vous avez parcouru des fichiers.

Quand collecter n'est plus l'option

Parfois les données n'existent pas encore, ou ne peuvent pas être utilisées. Trois alternatives sérieuses, dans l'ordre :

1. Réutiliser un modèle préentraîné et n'annoter que le delta métier.
2. Synthétiser avec prudence — utile pour dilater des classes rares, dangereux si la synthèse ignore les cas limites réels.
3. Reporter le projet jusqu'à ce qu'un processus métier produise des traces exploitables.

Créer un gigantesque chantier de collecte « pour l'IA » sans cas d'usage borné est la voie la plus lente. La donnée suit le problème ; elle ne le précède pas durablement.

Qualité avant quantité

Plus de données n’aide que si elles sont pertinentes, cohérentes et correctement labellisées. Un corpus massif bruité peut battre un petit corpus propre sur certains benchmarks, mais en métier régulé, la qualité documentée gagne presque toujours. Annoter coûte cher : investissez dans des guides d’annotation, des doubles lectures et des mesures d’accord inter-annotateurs.

Documentez la provenance. Une base « scrapée » sans licence claire peut bloquer un déploiement juridique six mois plus tard. Une base interne sans consentement peut créer un incident RGPDRGPDConformitéRèglement européen sur la protection des données personnelles. Il s'applique dès qu'un système d'IA traite de telles données, et se cumule avec l'AI Act.Voir dans le glossaire.

Jeux d’entraînement, validation, test

La séparation classique reste la discipline de base. Le jeu de test ne sert qu’à une évaluation finale. La validation guide les hyperparamètres. Si vous « regardez » trop le test, il cesse d’être un test. Dans les séries temporelles, respectez l’ordre chronologique : mélanger aléatoirement fuit le futur.

Pour les LLMLLMIAGrand modèle de langage (Large Language Model) entraîné sur d'énormes corpus pour prédire et générer du texte.Voir dans le glossaire et grands corpus, la contamination des benchmarks est un sujet réel. Méfiez-vous des scores publics sans protocole de décontamination.

Sans hygiène de séparation des données, vos métriques sont de la fiction rassurante.

Déséquilibre et coûts asymétriques

Beaucoup de problèmes métier sont déséquilibrés : fraude, panne, défaut, incident sécurité. Techniques classiques : rééchantillonnage, pondération de la perte, seuils calibrés, approches anomaly detection. Le choix dépend du coût métier, pas de la mode.

Calibrez les probabilités si vos décisions utilisent des seuils. Un modèle bien classant mais mal calibré trompe les workflows qui croient lire une « confiance ».

MLOps minimal viable

Versionnez données, code et modèle ensemble. Enregistrez les hyperparamètres. Automatisez un smoke test avant promotion. Surveillez latence, taux d’erreur et dérive. Prévoyez un rollback en un clic. Ce socle n’est pas du luxe : c’est ce qui sépare une expérimentation d’un produit.

Traitez le jeu de données comme un actif versionné, au même titre que le code applicatif.

Consentement, rétention, et datasets synthétiques

Les données personnelles imposent base légale, minimisation et durées de conservation. Les logs de prompts sont des données. Les datasets synthétiques aident parfois à partager ou augmenter, mais ils héritent de biais du générateur et ne remplacent pas une évaluation sur données réelles. Étiquetez clairement synthétique vs observé dans vos catalogues.

Un data card (fiche dataset) d’une à deux pages — provenance, licence, limites connues, taux d’erreur d’annotation — accélère audits et onboarding mieux qu’un dossier SharePoint opaque.

Pipeline de données : de la source à la feature store

Une chaîne saine commence à la source : extraction versionnée, contrôles de schéma, détection de nulls anormaux, puis transformation reproductible. Les notebooks seuls ne suffisent pas en production : industrialisez les jobs, journalisez les volumes, alertez sur les écarts. Une feature store légère (même une table documentée) évite que chaque équipe recalcule « son » âge client différemment.

Les labels arrivent souvent en retard (fraude confirmée J+14). Gérez le point-in-time correctement : entraîner avec un label futur non disponible à l’inférenceinférenceIAUtilisation d'un modèle déjà entraîné sur une donnée nouvelle. Peu coûteuse à l'unité mais répétée à chaque requête, elle constitue le coût récurrent d'exploitation.Voir dans le glossaire est une fuite classique. Notez l’horloge de chaque événement.

La ponctualité de la donnée (timeliness) fait partie de la qualité, au même titre que l’exactitude.

Quand vous achetez des données externes, exigez un dictionnaire, une fréquence de rafraîchissement, et un engagement sur les ruptures de schéma. Sans cela, votre modèle devient otage d’un fournisseur silencieux.