Vos données sont-elles prêtes pour l'IA ? Les 4 vérifications qui évitent l'échec
On me demande souvent pourquoi un projet d'IA qui semblait prometteur s'écroule en production. La réponse, presque à chaque fois, n'est pas un problème de modèle : c'est un problème de données. Le modèle le plus fin du monde ne peut rien contre un jeu d'entraînement biaisé, des champs incohérents, ou des données de production qui n'ont plus rien à voir avec ce qui a servi à l'apprentissage. Je monte des POC et des MVP Data & IA depuis des années, et je vous propose la méthode que j'utilise en interne : quatre vérifications concrètes, dans l'ordre, pour savoir si vos données sont réellement prêtes avant de lancer. Aucun jargon inutile, des exemples vécus, et les vrais ordres de grandeur — sans inventer de chiffre.
By John-Guy Park · · 10 min de lecture
Key facts
- La préparation des données est le poste dominant d'un projet d'IA : selon l'enquête Anaconda 2020 « State of Data Science » (2 360 répondants dans plus de 100 pays), les data scientists passent en moyenne 45 % de leur temps à charger et nettoyer les données — plus que sur la modélisation (donnée tierce : Anaconda, 2020).
- Une mauvaise qualité de données coûte cher et durablement : Gartner estime qu'elle coûte en moyenne au moins 12,9 M$ par an au sein d'une organisation, tout en notant que près de 60 % des organisations ne mesurent pas le coût de leur mauvaise qualité de données (donnée tierce : Gartner, 2020).
- À l'échelle macro, l'IBM Institute for Business Value chiffre à plus de 3 000 milliards de dollars par an le coût des mauvaises données aux États-Unis — un ordre de grandeur discuté, mais qui pointe l'enjeu (donnée tierce : IBM / Harvard Business Review, 2016).
- Le « leakage » (fuite entre données d'entraînement et de test) est l'un des pièges les plus coûteux : il affiche des performances flatteuses en test qui s'effondrent en production, parce que la mesure a « vu » la réponse attendue (principe méthodologique standard du machine learning, à vérifier sur son propre jeu de données).
- La représentativité des données de production est le test décisif : un modèle entraîné sur un historique qui ne ressemble plus à ce qu'il voit en production dérive, et les performances se dégradent sans que personne ne s'en aperçoive tant qu'on ne surveille pas la distribution (principe de surveillance de dérive des données).
- Le périmètre réglementaire précède la technique : si vos données contiennent des données personnelles de personnes situées dans l'UE, le RGPD s'applique (y compris au modèle entraîné, selon la CNIL et l'opinion 28/2024 de l'EDPB) ; et selon le type de système, l'AI Act peut imposer des obligations supplémentaires (données tierces : CNIL ; EDPB ; AI Act).
Pourquoi vos données, pas votre modèle, décident de l'échec
Quand un projet d'IA échoue, on cherche volontiers un coupable dans l'architecture ou le choix du modèle. Dans mon expérience de POC et de MVP Data & IA, c'est presque toujours ailleurs : le modèle le plus performant du marché ne peut rien produire d'utile si les données qui le nourrissent sont incohérentes, si les mesures sont faussées par une fuite, ou si la production n'a plus rien à voir avec l'historique d'apprentissage. J'ai vu des prototypes « parfaits en démo » se révéler inutilisables dès le premier trimestre réel : le code était bon, mais les données de production ne ressemblaient pas aux données de laboratoire.
Le chiffre qui résume le problème vient d'Anaconda : dans son enquête 2020 menée auprès de 2 360 data scientists dans plus de 100 pays, près de 45 % du temps de travail est consacré au chargement et au nettoyage des données — le « ménage » — contre 11 à 12 % à la sélection, l'entraînement et le déploiement du modèle (donnée tierce : Anaconda, State of Data Science 2020). La préparation des données occupe donc quatre fois plus de temps que la modélisation elle-même. Dès que je commence un cadrage, c'est sur cette part-là que je cherche à gagner — pas sur le choix du modèle.
L'enjeu financier n'est pas anecdotique. Gartner estime que la mauvaise qualité des données coûte en moyenne au moins 12,9 millions de dollars par an au sein d'une organisation — et que près de 60 % des organisations ne mesurent même pas ce coût (donnée tierce : Gartner, 2020). Des ordres de grandeur, mais la direction est claire : la donnée coûte cher par son absence de qualité, bien plus que le modèle.
D'où ma méthode, en quatre vérifications ordonnées — je ne les traverse jamais dans le désordre, chacune prépare la suivante. Et sachez ce qu'elles ne sont pas : ce n'est pas une check-list à cocher en une après-midi, c'est un socle qui se construit — quelques jours sur un jeu de données propre, des semaines quand le socle part de rien.
Vérification n°1 : le socle de données est-il propre et cohérent ?
Première vérification, la plus ingrate et la plus importante : votre socle de données est-il fiable ? Concrètement, je regarde quatre choses dans l'ordre. Les types et unités : une même colonne ne doit pas mélanger des dates en texte et en date, des montants en euros et en dollars, des mètres et des centimètres. Les doublons : la même entité apparaît-elle plusieurs fois sous des variantes que l'on ne détecte pas au premier regard ? Les valeurs aberrantes et manquantes : des champs vides ou absurdes que personne n'a signalés parce qu'ils passaient sous les radars. Et la traçabilité : sait-on d'où vient chaque ligne, et qui l'a entrée ?
C'est le piège le plus courant que je vois en cadrage : un jeu de données existant, déjà utilisé pour des tableaux de bord, que tout le monde croit sain parce qu'il « fonctionne » depuis des années. En y regardant de près, on découvre des unités mélangées ou des lignes dupliquées qui n'ont jamais été questionnées — parce que personne n'avait encore tenté de faire tourner un modèle dessus. Règle simple : ne commencez jamais l'entraînement sans avoir vérifié chaque colonne qui entre dans le modèle.
Cette vérification est fastidieuse, je ne vais pas prétendre le contraire. Mais c'est exactement là que se joue une grande partie de votre budget : plus le socle est sale, plus le nettoyage est long — et le nettoyage est le poste de temps dominant (45 % chez Anaconda). Investir ici, tôt, est ce qui coûte le moins à terme : c'est souvent l'une des premières choses que je fais découvrir à un client, combien ce « simple ménage » prend réellement.
Vérification n°2 : vos mesures sont-elles faussées par une fuite ?
La deuxième vérification est la plus sournoise, et de loin : le leakage, ou fuite d'information entre les données d'entraînement et les données de test. Dans son essence : votre modèle affiche des performances flatteuses en test parce que la mesure a, d'une manière ou d'une autre, « vu » la réponse attendue. Résultat : en laboratoire tout est parfait, en production tout s'effondre, et on n'a aucune idée de pourquoi. C'est sans doute l'échec de projet d'IA le plus coûteux que j'ai observé, parce qu'il donne une fausse confiance.
Les formes de fuite sont nombreuses. Le tri aléatoire qui laisse passer une ligne corrélée à la cible. Une variable d'identification (un numéro de client, une date) que le modèle apprend comme un raccourci vers la bonne réponse. Une colonne qui décrit le résultat attendu lui-même, créée à la main pour un usage métier et oubliée dans le fichier. Ou une temporalité mal gérée : on entraîne sur des données qui incluent le futur que l'on veut prédire — classique en prévision et en détection de fraude. Chacune produit des métriques irréprochables, et un produit qui ne marche pas.
Le test que je fais systématiquement : je prends les exemples de test que le modèle « réussit » le mieux, et je demande si un humain, avec le même jeu de contexte, pourrait raisonnablement produire la réponse. Si oui, c'est sain. Si non — si les seules bonnes réponses sont impossibles à déduire du contexte — il y a presque certainement une fuite. C'est une vérification qualitative, gratuite, et étonnamment efficace : elle vous met sur la piste avant de dépenser des semaines.
Vérification n°3 : les données de production ressemblent-elles à vos données d'entraînement ?
La troisième vérification regarde l'avenir : ce que votre modèle verra en production ressemble-t-il à ce sur quoi il a été entraîné ? C'est la question de la représentativité, et c'est le test décisif. Un modèle peut être parfaitement entraîné, sans aucune fuite, et échouer quand même si la distribution des données change — on parle de dérive de données. Les clients, les produits, les saisons, les règles métier évoluent ; un historique figé ne représente plus le monde au moment du déploiement.
Concrètement, je vérifie que les données de production — celles que le système verra « en vrai » — tombent dans la même zone que l'historique d'entraînement : mêmes plages de valeurs, mêmes catégories, mêmes volumes relatifs. Si votre historique date de trois ans et que votre produit a changé depuis, la prudence s'impose : le modèle risque d'arbitrer sur un monde qui n'existe plus. La parade est simple : surveiller la distribution au fil du temps (alertes quand une variable s'écarte) et rafraîchir le modèle sur des données récentes.
C'est là que je vois la différence entre un POC réussi et un produit durable. Un prototype démontre une faisabilité sur un échantillon. Un système fiable ajoute cette troisième vérification et instaure la surveillance de la dérive dès la mise en production. Sans elle, vous n'avez aucun signal avant que les performances ne chutent — c'est-à-dire au pire moment. La dérive n'est pas un détail de data scientist pointilleux : c'est le risque n°1 des modèles en conditions réelles.
Vérification n°4 : que vous permet de faire la réglementation de ces données ?
La quatrième vérification précède les trois autres en importance stratégique, et je la traite toujours en parallèle de la technique : avez-vous le droit de faire ce que vous projetez avec ces données ? Si vos données contiennent des données personnelles de personnes situées dans l'Union européenne, le RGPD s'applique — et il s'applique aussi au modèle entraîné lui-même. La CNIL et le comité européen de la protection des données (EDPB, opinion 28/2024) rappellent qu'un modèle entraîné sur des données personnelles ne peut pas être considéré comme anonyme dans tous les cas, du fait de ses capacités de mémorisation (donnée tierce : CNIL ; EDPB).
L'AI Act ajoute une couche. Selon le type de système que vous construisez, les obligations varient — et, pour les fournisseurs établis hors de l'UE dont les sorties sont utilisées dans l'Union, s'appliquent des obligations de mandataire établi (articles 22 et 54 du règlement 2024/1689). La qualité des données est d'ailleurs directement liée au régime, notamment aux exigences de gouvernance des données pour les systèmes à haut risque (donnée tierce : AI Act, règlement (UE) 2024/1689).
Le conseil pratique qui vaut pour tout le reste de cet article : traitez la vérification réglementaire au cadrage, en même temps que la vérification n°1 — pas au moment où le modèle est entraîné. Elle ne coûte presque rien à ce stade, et elle peut tout coûter si elle est découverte trop tard. La donnée n'est pas prête tant que son usage ne l'est pas.
L'ordre à retenir, et le budget honnête
Voici l'ordre que je retiens : d'abord le socle (vérif. 1) et le périmètre réglementaire (vérif. 4) en parallèle ; ensuite la question de la fuite (vérif. 2) ; enfin la représentativité de la production (vérif. 3). Changer l'ordre revient à construire sur du sable : afficher de belles métriques sur des données sales ou fuitées, puis découvrir le problème en production, au moment le plus coûteux.
En termes de calendrier honnête : sur un jeu de données déjà propre et documenté, ces vérifications sont un travail de concentration de quelques jours. Sur un socle qui part de rien — des exports hétérogènes, pas de documentation, des doublons — prévoyez des semaines, et cela peut peser autant que l'entraînement lui-même. C'est une raison de chiffrer la préparation des données dans le budget du projet, dès le cadrage, au lieu de la découvrir à la facturation. La transparence là-dessus est, à mon sens, la seule posture tenable — elle vous protège autant que vos données.
Si vous voulez cadrer un projet de prototype IA ou de MVP en gardant la maîtrise de ces quatre vérifications, je vous recommande de lire comment se déroule un développement de MVP en 60 jours et ce que révèle réellement le calendrier d'un projet IA de bout en bout — POC, MVP, production. Et si vos données sont l'enjeu n°1, le réflexe juste est de les traiter comme un actif à préparer, pas comme un détail à rattraper : c'est là que se décide, très tôt, l'essentiel du sort de votre projet.
Les 4 vérifications avant d'entraîner : ce que chacune change
| Vérification | Ce qu'elle détecte | Si elle échoue | Temps typique |
|---|---|---|---|
| 1. Propreté et cohérence du socle | Types, unités, doublons, valeurs aberrantes et manquantes | Modèle entraîné sur du bruit : performances aléatoires, coûts de nettoyage imprévus | Jours (socle propre) à semaines (socle à reconstruire) |
| 2. Absence de fuite (leakage) | Variable ou tri qui « donne » la réponse au modèle pendant la mesure | Métriques de test flatteuses qui s'effondrent en production | Jours, à refaire à chaque nouvelle feature |
| 3. Représentativité de la production | Dérive : la distribution réelle ne ressemble plus à l'historique | Performances qui se dégradent en silence, sans le signal attendu | À instaurer dès la mise en production, puis en continu |
| 4. Périmètre réglementaire (RGPD / AI Act) | Données personnelles UE, model non anonyme, obligations selon le type de système | Système à arrêter quels que soient ses résultats ; coûts et risques majeurs | À traiter au cadrage, en parallèle de la vérif. 1 |
Sources : Anaconda (2020, State of Data Science : 45 % du temps en préparation de données) ; Gartner (2020, coût moyen ≥ 12,9 M$/an, ~60 % des organisations ne mesurent pas) ; IBM / Harvard Business Review (2016, ~3 000 Md$/an aux États-Unis) ; CNIL & EDPB opinion 28/2024 (modèles entraînés sur données personnelles) ; AI Act (règlement UE 2024/1689). Les temps sont des ordres de grandeur d'expérience, pas des données publiées. Aucun chiffre inventé.
Frequently asked questions
Combien de temps passe-t-on vraiment à préparer des données pour l'IA ?
D'après l'enquête Anaconda 2020 (2 360 data scientists dans plus de 100 pays), la préparation des données — chargement et nettoyage — occupe en moyenne 45 % du temps de travail, contre 11 à 12 % pour la sélection, l'entraînement et le déploiement du modèle. Concrètement, sur un jeu propre et documenté, les quatre vérifications que je décris se font en quelques jours ; dès que le socle part de rien, comptez des semaines. C'est pourquoi il faut les chiffrer dans le budget dès le cadrage, pas les découvrir à la facturation.
Qu'est-ce que le « leakage » (fuite de données) et pourquoi est-ce si grave ?
C'est une fuite d'information entre les données d'entraînement et de test : d'une manière ou d'une autre, la mesure a « vu » la réponse attendue. Cela produit des métriques de test impeccablement hautes, puis un produit qui s'effondre en production sans explication claire. Les causes fréquentes : tri aléatoire qui laisse passer une ligne corrélée à la cible, une variable d'identification apprise comme raccourci, une colonne qui décrit le résultat attendu, ou une temporalité mal gérée (entraîner sur le futur que l'on prédit). Un test qualitatif simple : si les « bonnes » réponses ne sont pas déductibles du contexte par un humain, il y a probablement une fuite.
Combien coûte une mauvaise qualité de données ?
Gartner estime que la mauvaise qualité des données coûte en moyenne au moins 12,9 millions de dollars par an au sein d'une organisation, et note que près de 60 % des organisations ne mesurent pas ce coût. À l'échelle macro, l'IBM Institute for Business Value (relayé par Harvard Business Review) chiffre à plus de 3 000 milliards de dollars par an le coût des mauvaises données aux États-Unis. Ce sont des ordres de grandeur — la leçon à retenir est la direction : la donnée est coûteuse par son absence de qualité, bien plus que le modèle.
Le RGPD s'applique-t-il à un modèle entraîné sur des données personnelles ?
Souvent, oui. La CNIL et le comité européen de la protection des données (EDPB, opinion 28/2024) rappellent qu'un modèle entraîné sur des données personnelles ne peut pas être considéré comme anonyme dans tous les cas, du fait de ses capacités de mémorisation ; l'anonymité se juge au cas par cas. Si vos données contiennent des données personnelles de personnes situées dans l'UE, intégrez le RGPD au périmètre dès le cadrage, et non après l'entraînement — un système qui tourne sur un usage non licite est un système qu'il faut arrêter, quels que soient ses résultats.
Faut-il vérifier les données avant de choisir le modèle, ou après ?
Avant, et c'est le point central : les performances d'un modèle dépendent d'abord de la qualité et de la représentativité des données. Choisir un modèle sur des données sales ou fuitées revient à construire sur du sable — vous obtiendrez de belles métriques de test qui ne survivent pas à la production. L'ordre que je recommande : propreté du socle et périmètre réglementaire en parallèle, puis vérification de la fuite, puis représentativité de la production. La data prime sur le modèle, dans tous les cas de figure.
Comment savoir si mes données de production risquent de dériver ?
Comparez les données que le système verra « en vrai » avec l'historique d'entraînement : mêmes plages de valeurs, mêmes catégories, mêmes volumes relatifs. Si votre historique date de plusieurs années et que votre produit a évolué, la dérive est probable. La parade est de surveiller la distribution au fil du temps (alertes quand une variable s'écarte) et de rafraîchir le modèle sur des données récentes. Sans surveillance, vous n'avez aucun signal avant la chute des performances — c'est-à-dire au pire moment.
Sources cited
- Anaconda — 2020 State of Data Science (enquête) — donnée tierce · 2 360 répondants dans plus de 100 pays ; 45 % du temps de travail consacré au chargement et nettoyage des données ; la préparation dépasse nettement la modélisation (11-12 %) et le déploiement ; Anaconda constate le « lion's share » du temps en data wrangling
- Gartner — Data Quality : Why It Matters and How to Achieve It — donnée tierce · une mauvaise qualité de données coûte en moyenne au moins 12,9 M$ par an au sein d'une organisation (recherche Gartner 2020) ; ~59-60 % des organisations ne mesurent pas la qualité de leurs données
- Harvard Business Review — Bad Data Costs the U.S. $3 Trillion Per Year (IBM) — donnée tierce · Thomas C. Redman (Data Doc), s'appuyant sur une estimation IBM (Institute for Business Value) du coût des mauvaises données aux États-Unis, de l'ordre de 3 000 Md$/an (2016) ; ordre de grandeur macro, à prendre comme tel
- CNIL — Recommandations sur le développement des systèmes d'IA (RGPD) — donnée tierce · le RGPD s'applique à de nombreux modèles entraînés sur données personnelles du fait de leurs capacités de mémorisation ; démarche en étapes (finalité, base légale, minimisation, durée, information, droits, sécurité, AIPD)
- EDPB — Opinion 28/2024 sur les modèles d'IA et données personnelles — donnée tierce · les modèles entraînés sur données personnelles ne peuvent pas être considérés anonymes dans tous les cas ; l'anonymat s'évalue au cas par cas
- Règlement (UE) 2024/1689 (AI Act) — EUR-Lex — référence norme · cadre harmonisé des produits d'IA ; exigences de gouvernance des données pour les systèmes à haut risque ; mandataire établi pour les fournisseurs hors UE (art. 22 systèmes à haut risque, art. 54 modèles GPAI)
Got a project to turn into a product?
Book 30 minutes, or describe your idea in a few lines. We reply within 5 business days with free scoping — scope, risks, timeline and engagement pricing.