Prenons un exemple fictif de prévision. Un modèle trouve une tendance spectaculaire dans les ventes de pièces de vélo : la demande explose le premier jour de chaque mois. La courbe est claire, répétitive et complètement fausse.

Le problème vient d’une ancienne migration. Les montants mensuels ont été gardés, mais pas les dates précises. Toutes les transactions ont reçu le premier jour du mois. Pour produire des totaux mensuels, ce raccourci était acceptable. Pour apprendre un rythme quotidien, il crée un signal artificiel qu’aucun algorithme ne peut corriger sans autre source.

Une requête de profilage le montre rapidement :

SELECT DAY(DateVente) AS JourDuMois,
       COUNT(*) AS NbTransactions,
       SUM(Montant) AS Total
FROM Vente
GROUP BY DAY(DateVente)
ORDER BY JourDuMois;

Je comparerais ensuite la distribution avant et après chaque migration ou changement de système :

source A avant 2018  → dates transactionnelles réelles
migration 2018       → anciens mois placés au jour 1
source B après 2018  → date de facture, pas date de commande

La colonne possède donc trois sémantiques sous un seul nom. Ajouter PrecisionDate = JOUR|MOIS et TypeDate = COMMANDE|FACTURE conserve l’incertitude au lieu de fabriquer une précision. Pour un modèle quotidien, j’exclus les dates mensuelles ou je les agrège au mois; je ne répartis pas les montants au hasard sur 30 jours.

Construire un jeu de données dans le temps

Une prévision ne doit pas mélanger le futur dans l’entraînement. Je coupe chronologiquement : apprentissage sur les premières années, validation sur une période suivante, test sur les derniers mois jamais utilisés. Un découpage aléatoire laisserait des semaines voisines et les mêmes promotions des deux côtés, donnant un résultat trop optimiste.

Les variables doivent être connues au moment de prédire. Utiliser le montant final corrigé, la date réelle de livraison ou une catégorie ajoutée après la vente crée une fuite. Je documente pour chaque feature sa source, son heure de disponibilité et sa transformation.

Le modèle complexe affronte des références simples :

1. même valeur que la semaine précédente;
2. moyenne mobile des quatre dernières semaines;
3. même semaine l’année précédente;
4. moyenne par saison avec jours fériés;
5. modèle candidat avec ses intervalles de prévision.

Je mesure l’erreur par produit, saison et horizon. Une moyenne peut cacher un modèle excellent sur les produits stables et dangereux sur les pièces rares. Les périodes de rupture de stock sont particulières : les ventes observées sont faibles parce qu’on ne pouvait pas vendre, pas nécessairement parce que la demande avait disparu. Une variable de disponibilité ou une exclusion explicite évite d’apprendre cette confusion.

Le pipeline conserve une table de rejets et des contrôles : taux de dates au premier du mois, doublons, montants négatifs, valeurs manquantes, changement soudain de volume. Une panne de source arrête la publication du nouveau forecast plutôt que remplir silencieusement les jours de zéros. La dernière prévision valide reste visible avec son âge.

La connaissance métier intervient avant et après. Une personne de l’industrie du vélo va questionner une pointe parfaite en janvier, mais elle doit voir la distribution et la provenance pour confirmer. Son intuition ne remplace pas le test; elle aide à trouver la question que la métrique globale cache.

Dans cet exemple, la bonne action est de corriger le contrat de données et de réduire la granularité du modèle, pas d’ajouter des couches. Ma pratique sera de profiler chaque variable par période et système source avant l’entraînement, puis de conserver la précision originale comme une donnée. Un calendrier inventé peut préserver tous les totaux et quand même détruire toute prévision quotidienne.