Données machine learning entreprise : ce qu'il faut vraiment

Un projet de machine learning prédictif ne peut pas fonctionner sans un historique de données exploitable : c'est l'objection numéro un que soulèvent les dirigeants de PME, et elle est légitime. Cet article détaille les prérequis réels en données selon le type de modèle prédictif visé : volume, granularité, qualité, étiquetage, et les pièges qui font échouer les projets même avec de bons historiques (fuite de données, biais, déséquilibre des classes).

Volume et historique : les seuils réels selon le type de prédiction

La première question posée dans tout projet prédictif est "ai-je assez de données ?". La réponse honnête : ça dépend du type de modèle. Il n'existe pas de seuil universel, mais des fourchettes pragmatiques selon le cas d'usage.

"La question du volume est souvent mal posée. Ce n'est pas combien de lignes que vous avez, c'est combien d'occurrences de l'événement que vous cherchez à prédire. Prédire une panne qui arrive trois fois par an sur 5 ans donne 15 exemples positifs. C'est insuffisant pour un modèle supervisé classique, même avec 50 000 lignes de capteurs." (Anas Rabhi, ingénieur IA et data scientist, fondateur de Tensoria)

Seuils pratiques par type de modèle prédictif

Type de prédiction	Historique minimum	Remarque
Prévision de ventes (mensuelle)	12 à 24 mois	24 mois pour capturer la saisonnalité
Prévision de stocks (hebdo)	18 à 36 mois	Deux cycles saisonniers complets
Scoring client (churn, risque)	1 000 à 5 000 exemples par classe	Nécessite des étiquettes historiques
Maintenance prédictive (capteurs)	50 à 100 occurrences de la panne cible	Volume brut secondaire face aux occurrences
Détection d'anomalies (non supervisé)	Quelques milliers de lignes "normales"	Pas besoin d'exemples anormaux étiquetés
Prévision de trésorerie	24 à 36 mois	Cycles annuels et comportements de paiement

Ces seuils sont des points de départ, pas des garanties. Un historique de 24 mois avec des données mal structurées ou incohérentes produira des résultats inférieurs à 12 mois de données propres et bien annotées.

Pour mieux comprendre comment ce prérequis s'articule avec les autres dimensions d'un projet IA en PME (RAG, automatisation, assistant interne), consultez l'article données prêtes pour l'IA en entreprise qui couvre les cas non prédictifs.

Granularité et qualité : ce qui compte vraiment

La granularité est la résolution temporelle ou dimensionnelle de vos données. Elle détermine ce que le modèle peut apprendre.

Choisir la bonne granularité temporelle

La règle pratique : votre granularité doit être au moins 4 à 5 fois plus fine que l'horizon de prédiction.

Vous souhaitez prévoir vos ventes à un horizon de 4 semaines ? Des données journalières, voire hebdomadaires, conviennent. Vous cherchez à anticiper une panne 48 heures à l'avance sur une machine industrielle ? Vos capteurs doivent remonter des mesures toutes les 5 à 15 minutes au moins.

Une granularité trop grossière nivelle les signaux fins qui différencient un comportement normal d'un comportement précurseur. Une granularité trop fine crée du bruit inutile et fait exploser les coûts de stockage et de calcul sans valeur ajoutée.

Les quatre indicateurs de qualité à vérifier en priorité

Taux de valeurs manquantes. En dessous de 5 % sur les colonnes clés, c'est gérable par imputation. Entre 5 et 20 %, la stratégie de traitement impacte les résultats. Au-delà de 20 %, la colonne est souvent inutilisable pour l'entraînement.

Cohérence temporelle. Cherchez les trous dans vos séries. Une série de ventes journalières avec des week-ends et jours fériés manquants n'est pas un problème, c'est attendu. Des semaines entières absentes sans explication sont un signal de problème amont (export incomplet, changement de système).

Stationnarité du processus. Si votre entreprise a changé de modèle commercial, de zone de chalandise, ou de gamme produit sur la période de l'historique, les données antérieures au changement peuvent polluer l'entraînement. Le modèle apprend un comportement qui n'existe plus.

Distribution des variables cibles. Pour les classifications (panne ou pas, churn ou pas), vérifiez le ratio entre les classes. Un ratio 99/1 (99 % de transactions normales pour 1 % d'anomalies) est un déséquilibre sévère qui nécessite des techniques spécifiques : suréchantillonnage (SMOTE), sous-échantillonnage de la classe majoritaire, ou pondération des classes dans la fonction de perte.

La règle des 80 %

D'après une analyse publiée par IBM Institute for Business Value en 2023, les data scientists passent en moyenne 60 à 80 % de leur temps sur les données, dont la majorité sur le nettoyage et la préparation. Ce chiffre n'est pas une surprise pour les praticiens : c'est le reflet de ce que vous devez anticiper dans votre budget projet.

Étiquetage des données : le vrai frein des modèles supervisés

L'apprentissage supervisé exige que chaque exemple d'entraînement soit associé à une valeur cible connue (l'étiquette). C'est ce qui permet au modèle d'apprendre la correspondance entre les features d'entrée et l'outcome à prédire.

En pratique, l'étiquetage est l'étape la plus sous-estimée des projets prédictifs en PME.

Quand l'étiquetage est naturel

Pour la prévision de ventes ou de stocks, l'étiquette est la valeur historique que l'on cherche à prédire. Elle est déjà dans vos données : pas besoin d'annotation manuelle. C'est pourquoi les projets de prévision de séries temporelles sont souvent les plus accessibles techniquement.

Même logique pour la prévision de trésorerie : vos relevés bancaires passés constituent un historique d'étiquettes naturelles.

Quand l'étiquetage pose problème

Les cas difficiles sont ceux où l'événement à prédire n'a jamais été formellement enregistré comme tel dans vos systèmes.

Exemple typique : vous souhaitez prédire quels clients risquent de partir (churn). Pour que le modèle apprenne, il vous faut un historique de clients qui sont effectivement partis, avec leur profil comportemental avant le départ. Si votre CRM n'a jamais tracé les résiliations, ou si l'information est éparpillée dans des emails et des notes manuscrites, vous n'avez pas d'étiquettes exploitables.

Autre cas fréquent : la maintenance prédictive industrielle. Si vos techniciens n'ont jamais rempli de rapport de panne structuré (date, machine, type de défaut), vous n'avez pas d'exemples positifs sur lesquels entraîner un modèle supervisé. Vous pouvez travailler en détection d'anomalies non supervisée, mais les résultats seront moins précis.

La qualité de l'étiquetage compte autant que son volume

Des étiquettes bruitées (pannes mal documentées, résiliations mal codifiées, valeurs renseignées à la louche) dégradent les performances du modèle de façon souvent non visible à l'entraînement mais visible en production. C'est ce que les praticiens appellent le problème du "garbage in, garbage out" : le modèle apprend parfaitement une vérité erronée.

Selon une étude citée par LeMagIT sur la qualité des données en IA, les données inexactes ou mal étiquetées causent l'échec d'une majorité de projets d'apprentissage automatique (source LeMagIT, 2024).

Données de séries temporelles : spécificités et pièges

La majorité des modèles prédictifs en PME (prévision des ventes, des stocks, de la trésorerie, maintenance prédictive) traitent des séries temporelles. Ce type de données a des particularités que les approches classiques de machine learning ne gèrent pas bien si on les ignore.

La séparation train/test ne se fait pas au hasard

En machine learning classique sur données tabulaires, on mélange aléatoirement les exemples pour créer les jeux d'entraînement et de test. Sur une série temporelle, c'est une erreur grave. Le jeu de test doit toujours être postérieur au jeu d'entraînement, sans chevauchement.

Si vous mélangez les dates, le modèle voit "du futur" pendant l'entraînement et apprend des corrélations impossibles en conditions réelles. Ses métriques de performance semblent excellentes. Il échoue en production. C'est une forme de fuite de données temporelle.

Saisonnalité, tendance et cycles

Pour qu'un modèle capture correctement la saisonnalité annuelle, il lui faut au minimum deux cycles complets dans l'historique d'entraînement. Sur 12 mois, un modèle de prévision de ventes de jouets ne "voit" qu'un seul pic de Noël. Il ne peut pas distinguer ce pic de la tendance générale. Sur 24 à 36 mois, la saisonnalité devient un signal robuste.

Les tendances (croissance régulière, déclin progressif) et les cycles économiques posent un problème différent : le modèle entraîné sur une période de croissance sous-estime les creux, et inversement. Il n'existe pas de solution parfaite, mais des techniques de décomposition (STL, X-13ARIMA) permettent de traiter séparément les composantes saisonnières, tendancielles et résiduelles.

Les variables exogènes : un levier sous-utilisé en PME

Les séries temporelles pures (ventes passées pour prédire les ventes futures) ont une limite : elles ne peuvent pas anticiper les ruptures causées par des événements externes. L'ajout de variables exogènes améliore significativement les prédictions.

Exemples concrets selon le secteur :

+Distribution alimentaire : calendrier des jours fériés, données météo, promotions planifiées
+Industrie de process : température ambiante, humidité, cadence de production
+E-commerce : budget pub Google/Meta, visites site, notes produits
+Services financiers : taux d'intérêt, indicateurs macroéconomiques sectoriels

Ces variables doivent être disponibles non seulement dans l'historique (pour l'entraînement) mais aussi dans le futur au moment de la prédiction. Un calendrier des jours fériés est connu à l'avance. La météo ne l'est que sur un horizon de quelques jours. Attention à ne pas utiliser en variables exogènes des données que vous n'aurez pas au moment de l'inférence.

Les pièges qui font échouer même les bons historiques

Disposer d'un bon historique ne suffit pas. Les projets prédictifs échouent en production pour des raisons souvent évitables dès la phase de préparation des données.

La fuite de données (data leakage)

C'est le piège le plus insidieux et le plus dévastateur. La fuite de données survient quand des informations qui ne seraient pas disponibles au moment de la prédiction réelle se retrouvent dans les features d'entraînement.

Exemple concret : vous entraînez un modèle pour prédire si un client va résilier dans les 30 prochains jours. Vous incluez dans vos features le nombre d'appels au service client du mois en cours. Mais au moment de la prédiction, vous n'avez que les appels des semaines passées, pas le total mensuel définitif. Le modèle apprend à partir d'une information qui n'est pas encore disponible.

Les sources classiques de fuite en PME :

+Agrégats calculés sur la fenêtre qui inclut la cible (total mensuel, moyenne glissante mal construite)
+Variables renseignées a posteriori dans l'ERP (statut final d'une commande complété après livraison)
+Jointures involontaires avec des tables contenant des informations futures
+Normalisation statistique calculée sur l'ensemble du jeu (train + test) avant la séparation

La parade systématique : reconstruire le pipeline de données exactement comme s'il fonctionnait en production, avec un "point de coupure" temporel strict. Tout ce qui est postérieur à ce point est interdit pour les features.

Le biais d'échantillon

Votre historique ne représente pas nécessairement la diversité des situations que le modèle rencontrera en production. Quelques situations fréquentes en PME :

Biais de survie : si votre historique de clients ne contient que les clients actifs aujourd'hui, vous avez éliminé tous ceux qui ont résilié. Le modèle de churn apprend sur un sous-ensemble non représentatif.

Biais de période : un modèle entraîné sur 2020-2022 inclut la période Covid, avec des comportements d'achat très atypiques. Si votre activité est revenue à la normale depuis, inclure cette période peut dégrader les prédictions.

Biais de sélection : dans les données de maintenance, seules les pannes diagnostiquées et enregistrées dans votre GMAO apparaissent. Les incidents traités en urgence sans documentation sont absents de l'historique.

Le surapprentissage sur petits jeux de données

Sur des historiques courts ou des événements rares, le modèle peut "mémoriser" les exemples d'entraînement au lieu de généraliser. Les métriques de validation paraissent bonnes, mais les prédictions en production sont instables.

Signaux d'alerte : performance parfaite sur le jeu d'entraînement mais dégradée sur le jeu de validation, ou forte variabilité des prédictions selon la graine aléatoire utilisée. La solution passe par une régularisation plus forte, des architectures plus simples, ou l'utilisation de techniques de validation croisée temporelle (walk-forward validation) adaptées aux séries temporelles.

Comment auditer vos données en 30 minutes

Avant de solliciter un prestataire ou de démarrer un projet, vous pouvez réaliser vous-même un audit rapide de vos données. L'objectif n'est pas la perfection : c'est d'identifier les blocages potentiels avant d'engager du temps et du budget.

Checklist d'audit données prédictif (30 minutes)

1
Identifier la cible : quelle valeur ou quel événement voulez-vous prédire ? Est-il tracé quelque part dans vos systèmes avec une date ?
2
Mesurer l'historique disponible : combien de mois ou d'années de données propres pouvez-vous extraire ? Comparez au seuil du tableau ci-dessus.
3
Compter les valeurs manquantes : exportez 1 000 lignes et vérifiez le taux de remplissage des colonnes que vous comptez utiliser comme features.
4
Chercher les ruptures : y a-t-il eu un changement de système, une acquisition, un nouveau périmètre commercial sur la période ? Ces ruptures peuvent invalider une partie de l'historique.
5
Vérifier les étiquettes : si vous avez besoin d'un modèle supervisé, combien d'exemples de l'événement cible (panne, résiliation, fraude) sont documentés dans l'historique ? Comparez au seuil minimal de votre cas d'usage.
6
Identifier les variables exogènes disponibles : quelles données contextuelles (promotions, météo, calendrier) sont déjà stockées et associables à vos séries ?

Ce diagnostic de 30 minutes permet de trancher honnêtement : le projet est faisable dès maintenant, il nécessite une phase de structuration préalable, ou il doit être différé le temps que l'historique s'accumule.

Tensoria réalise ce type d'audit des données dans le cadre du cadrage de tout projet prédictif, avant d'engager le moindre développement. C'est la seule façon d'éviter les projets qui échouent sur un historique insuffisant ou mal structuré.

Pour aller plus loin sur les cas d'usage concrets du prédictif en PME et les livrables d'un projet de A à Z, consultez la page solutions IA prédictives pour PME et ETI.

Questions fréquentes sur les données pour un modèle prédictif

Il n'existe pas de règle universelle. Pour une prévision de ventes ou de stocks sur données structurées, 12 à 24 mois d'historique mensuel constituent un minimum fonctionnel. Pour un modèle de scoring ou de classification, comptez 1 000 à 5 000 exemples étiquetés par classe. En dessous de ces seuils, les résultats sont souvent insuffisants pour justifier un déploiement en production. La qualité et la cohérence des données comptent davantage que le volume brut.

Oui, dans certains cas. Les algorithmes non supervisés (clustering, détection d'anomalies) n'exigent pas d'étiquettes. Mais pour un modèle prédictif au sens strict, c'est-à-dire un modèle qui prédit une valeur ou une classe future, l'étiquetage est nécessaire. Pour la prévision de séries temporelles, le passé connu joue le rôle d'étiquette naturelle. Pour la classification (client à risque, panne imminente), il faut des exemples historiques de l'événement qu'on cherche à anticiper.

La fuite de données (data leakage) survient quand le modèle est entraîné sur des informations qu'il n'aurait pas pu connaître au moment de la prédiction en conditions réelles. Exemple classique : inclure le chiffre d'affaires du mois M dans les features utilisées pour prédire l'événement du mois M. Le modèle apprend une corrélation parfaite pendant l'entraînement, puis échoue en production car cette information n'est pas encore disponible. La parade : construire le jeu d'entraînement exactement comme si vous étiez dans le passé, sans aucune donnée postérieure à la date de prédiction.

La granularité dépend du délai d'anticipation souhaité et de la variabilité du phénomène. Pour une prévision de ventes à l'horizon mensuel, des données journalières ou hebdomadaires suffisent et apportent davantage d'information que des données mensuelles. Pour une maintenance prédictive sur capteurs industriels, la granularité peut descendre à la minute ou à la seconde selon la dynamique de la défaillance. La règle pratique : votre granularité doit être au moins 4 à 5 fois plus fine que l'horizon de prédiction.

Quatre indicateurs à vérifier : le taux de valeurs manquantes (acceptable en dessous de 10 à 15 % sur les colonnes clés), la cohérence temporelle (pas de trous dans les séries chronologiques, pas de doublons sur les périodes), la stationnarité du processus sous-jacent (pas de rupture structurelle majeure dans l'historique non expliquée), et la distribution des classes cibles (si vous prédisez un événement rare, vérifiez qu'il est suffisamment représenté dans le jeu d'entraînement). Un audit rapide sur un échantillon de 1 000 lignes suffit pour diagnostiquer les problèmes bloquants.

Le minimum : l'historique des ventes passées (au moins 12 mois, idéalement 24 à 36), la granularité temporelle adaptée (jour, semaine ou mois selon votre cycle), et si possible les variables exogènes connues (calendrier des fêtes, événements promotionnels, données météo pour les secteurs sensibles). Les variables les plus explicatives varient selon le secteur. Pour un distributeur, les ruptures de stock passées et les prix sont souvent plus prédictifs que les macrodonnées économiques.

Non. Un nettoyage complet a priori est rarement nécessaire et souvent contre-productif en termes de temps. L'approche pragmatique : identifier les données sources sur un périmètre restreint, réaliser un audit rapide de leur qualité, corriger les problèmes bloquants (valeurs aberrantes extrêmes, doublons sur la clé primaire), et démarrer un premier modèle baseline sur ce sous-ensemble. Les problèmes de qualité secondaires apparaîtront lors des premières analyses et seront traités au fil de l'eau.

6 mois d'historique est généralement insuffisant pour un modèle prédictif robuste, surtout s'il existe une saisonnalité annuelle (ce qui est le cas dans la majorité des secteurs). Quelques options : utiliser des données externes sectorielles pour compléter l'historique interne, appliquer des méthodes statistiques plus simples mais adaptées aux petits historiques (modèles ARIMA, lissage exponentiel), ou différer le projet ML de 6 à 12 mois pour laisser l'historique s'accumuler tout en structurant les données dès maintenant. Un cadrage honnête vaut mieux qu'un modèle entraîné sur un historique insuffisant.