Le modèle est la partie facile

Un opérateur de produits frais est venu nous voir avec une question propre : pouvez-vous prédire la demande de demain — par plat, par site — assez précisément pour qu'on arrête de jeter de la marge et de tomber en rupture au déjeuner ? Dix-huit mois plus tard, la plateforme prévoit à 98 % de précision en production. Les gens supposent que la partie difficile était le machine learning. Ce n'était pas elle.

Le modèle qui fait les prédictions est un régresseur à gradient boosting avec quelques features de saisonnalité boulonnées dessus. Une data scientist compétente monte quelque chose de cette famille en un après-midi. Nous avions une première version respectable en trois semaines — assez précise au backtest pour faire hocher toutes les têtes dans la pièce.

Puis nous avons passé cinq mois à construire tout ce qui transforme « un backtest précis » en « un chiffre sur lequel une responsable d'exploitation parie sa journée ». Cet écart est tout le métier — et presque personne n'écrit dessus, parce qu'il n'a rien de glamour. Alors le voici.

Le modèle des trois semaines

Prévoir la demande d'une activité stable et bien enregistrée est, franchement, un problème résolu. Vous avez une cible (les unités vendues), un calendrier et une pile de lignes historiques. Vous fabriquez quelques dizaines de features — jour de semaine, fenêtres décalées, moyennes glissantes, jours fériés, une jointure météo — et vous laissez une bibliothèque de boosting trouver les interactions. Ce n'est pas sur les maths que les projets meurent.

Ce que les trois semaines nous ont réellement acheté, c'est la certitude que le signal existait tout court. Le backtest disait : la demande est prévisible à quelques points de pourcentage près, avec des entrées propres. C'est le feu vert. Ce n'est pas le produit.

Le piège :

Un bon chiffre de backtest est l'artefact le plus dangereux du machine learning. Il ressemble à la ligne d'arrivée et c'est à peine le coup de pistolet du départ. Les backtests tournent sur des données nettoyées, jointes et alignées dans le temps par un humain qui connaît déjà la réponse. La production n'a aucun de ces luxes.

Où sont passés les cinq mois

Voici la comptabilité honnête des cinq mois suivants. Rien n'est de la modélisation. Tout est ce qui a rendu le modèle utilisable.

1. Une ingestion qui survit à la réalité. Les flux de ventes arrivent en retard, en double, ou pas du tout. Une caisse redémarre et rejoue la veille. Nous avons construit une ingestion idempotente, relançable sans danger, qui met en quarantaine les lignes douteuses au lieu d'empoisonner l'ensemble d'entraînement.
2. Un feature store avec une mémoire. Les features sur lesquelles le modèle s'entraîne doivent être calculables au moment de la prédiction, avec les seules données qu'on aurait réellement alors — sans regarder l'avenir. Imposer cette justesse point-dans-le-temps a pris des semaines et attrapé deux fuites qui gonflaient le backtest d'origine.
3. Backfill et replay. Quand l'historique d'un site était faux, il fallait reconstruire toutes ses prévisions en aval sans arrêter le système en production. Le replay est de la plomberie que personne ne montre en démo et dont tout le monde a besoin.
4. Le monitoring avant les fonctionnalités. Nous avons livré les alarmes de dérive et de fraîcheur avant la moitié de l'interface. Une prévision silencieusement fausse est pire qu'une prévision visiblement manquante.
5. La correction humaine. Un nouveau site ouvre, un festival tombe, une route ferme. Le modèle ne peut pas le savoir. Les planificateurs avaient besoin d'un levier sanctionné pour ajuster le chiffre — et le système devait apprendre de l'ajustement.

Le modèle répond à une question. La plateforme décide quelle question, avec quelles données, pour qui — et ce qui se passe quand la réponse est fausse.

— Sur pourquoi l'enveloppe est le travail

Le contrat de données

La chose au plus fort levier que nous ayons construite n'était pas une amélioration du modèle. C'était un contrat de données : un schéma explicite et validé entre chaque source amont et notre pipeline. Types de colonnes, plages autorisées, fenêtres de fraîcheur, politiques de nuls — tout déclaré, tout vérifié à la porte.

Avant le contrat, une prévision pouvait se dégrader en silence parce qu'un fournisseur de caisses passait un champ monétaire des centimes aux francs sans prévenir. Après le contrat, ce changement est rejeté à l'ingestion — avec une erreur nommée qui réveille quelqu'un — et la dernière bonne prévision reste à l'écran au lieu d'une nouvelle, fausse avec assurance.

contract · sales_daily

# every source is validated at the door, not after it poisons training
sales_daily:
  units:        int  >= 0      # reject negatives — refunds go elsewhere
  revenue:      decimal(10,2)  # cents → flagged in v3, now enforced
  site_id:      fk(sites)      # unknown site → quarantine, page on-call
  recorded_at:  freshness <= 6h # stale feed → hold last good forecast
on_violation: quarantine + alert  # never: silently train on it

C'est le cœur sans sex-appeal de tous les systèmes ML de production que nous avons livrés. Le modèle est une fonction ; le contrat garantit que la fonction reçoit les entrées pour lesquelles elle a été entraînée. Sautez-le et vous n'avez pas une plateforme de prévision — vous avez un générateur de nombres aléatoires très cher qui a raison la plupart du temps.

La dérive est une fonctionnalité, pas un échec

Tout modèle se dégrade. Les goûts bougent, une nouvelle carte arrive, un concurrent ouvre en face. La question n'a jamais été de savoir si le monde allait glisser sous votre modèle — mais si vous l'apprendrez par un tableau de bord ou par un coup de fil furieux.

Nous traitons la détection de dérive comme une fonctionnalité produit de premier rang. La plateforme compare en continu les distributions d'entrée et l'erreur en direct aux références d'entraînement. Quand l'une franchit un seuil, elle fait trois choses, dans l'ordre :

• Elle prévient quelqu'un — un humain précis, avec le site, la métrique et l'ampleur du mouvement.
• Elle protège la sortie — élargissant les bandes de confiance ou retombant sur une référence plus simple et plus robuste, plutôt que de croire un modèle en train d'extrapoler.
• Elle programme un réentraînement — avec les nouvelles données, derrière la même barre de backtest que l'original devait franchir.

Précision des prévisions —

Tenue en production, pas seulement au backtest.

Ruptures —

Frigos vides au déjeuner, réduites de plus de moitié.

Surstock —

De la marge qui finissait à la poubelle en fin de journée.

Notez que le chiffre en une — 98 % — n'est pas l'intéressant. Les chiffres intéressants sont les deux d'à côté, parce que ce sont eux que l'activité ressent. La précision est l'entrée ; moins de gaspillage et moins de ruptures sont la sortie. Une plateforme qui optimise la première en ignorant la seconde est un projet de science.

Le tableau de bord que quelqu'un regarde à 8 h

La prévision est consommée par une cheffe de cuisine en début de service, sur une tablette, avec un café, en quatre-vingt-dix secondes. Cette contrainte a façonné plus de décisions que l'architecture du modèle.

Elle signifiait que la réponse devait être une quantité, pas une distribution de probabilités. Que « je ne suis pas d'accord, voici pourquoi » devait tenir en un tap. Que l'écran devait montrer la prévision d'hier face à ce qui s'est réellement passé — parce que la confiance se gagne en étant visiblement redevable, pas en étant assuré. Un modèle incapable de montrer son bilan à la personne qui s'y fie sera ignoré en silence en une semaine.

Le vrai test d'acceptation :

Pas le score F1. Pas le RMSE. Le test d'acceptation, c'était une cheffe de cuisine en semaine deux disant « ouais, maintenant je prends ce qu'il dit, c'est tout ». Cette phrase vaut plus que n'importe quelle métrique hors ligne — et on ne la gagne qu'en concevant les quatre-vingt-dix dernières secondes aussi soigneusement que le modèle.

Notes à nos anciens nous-mêmes

Si vous allez démarrer quelque chose de cette forme, voici ce que nous dirions à l'équipe d'il y a dix-huit mois :

• Budgétez l'enveloppe, pas le modèle. Supposez que le modèle fait 15 % de l'effort et planifiez les 85 % restants délibérément. Les équipes qui ratent les délais sont celles qui ont budgété l'inverse.
• Écrivez le contrat de données en premier. Avant la moindre feature. Il révélera une fuite dans votre backtest et vous évitera de livrer un chiffre indéfendable.
• Livrez le monitoring avant l'interface. On n'exploite pas ce qu'on ne voit pas — et une prévision fausse que personne n'a remarquée est le mode d'échec qui fait perdre des contrats.
• Concevez la correction humaine. Les humains sauront toujours des choses que le modèle ignore. Donnez-leur un levier sanctionné et apprenez-en — sinon ils contourneront tout le système dans un tableur.
• Rendez le modèle redevable à l'écran. Montrez son historique à côté de sa prédiction. La confiance est une décision d'interface autant qu'une décision mathématique.

Le machine learning était la partie facile. Nous ne le disons pas pour rabaisser le modèle — il est réellement bon — mais pour pointer là où vit vraiment la difficulté. Le cycle du battage vend les trois semaines. Les cinq mois, c'est ce pour quoi on paie réellement une équipe d'ingénierie.

Les cinq mois, c'est la partie pour laquelle nous existons — plomberie des données, évaluations, l'ingénierie ingrate autour d'un bon modèle. Dites-nous où votre pilote est bloqué.