Un acteur de la restauration fraîche est venu nous voir avec une question simple : 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 qu'on arrête d'être en rupture le midi ? Dix-huit mois plus tard, la plateforme prévoit avec 98 % de précision en production. On suppose que le plus dur était le machine learning. Ça ne l'était pas.
Le modèle qui fait la prédiction est un régresseur à gradient boosté auquel on a greffé quelques variables de saisonnalité. Un data scientist compétent peut mettre sur pied quelque chose de cette famille en une après-midi. Nous avions une première version respectable en moins de trois semaines — assez précise sur le backtest pour faire hocher la tête à tout le monde dans la pièce.
Nous avons ensuite passé cinq mois à construire tout ce qui transforme « un backtest précis » en « un chiffre sur lequel un responsable d'exploitation parie sa journée ». Cet écart, c'est tout le métier, et presque personne n'en parle parce que ce n'est pas glamour. Alors le voici.
01Le modèle en 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 (unités vendues), un calendrier, et un tas de lignes historiques. Vous concevez quelques dizaines de variables — jour de la semaine, fenêtres de décalage, 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 dans 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 simplement. Le backtest nous disait que la demande était prévisible à un ou deux points de pourcentage près, à condition d'avoir des entrées propres. C'est le feu vert. Ce n'est pas le produit.
Un bon chiffre de backtest est l'artefact le plus dangereux du machine learning. Il ressemble à la ligne d'arrivée alors qu'il n'est à peine que le coup de pistolet de départ. Les backtests tournent sur des données qui ont été 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.
02Où sont passés les cinq mois
Voici le décompte honnête des cinq mois suivants. Rien là-dedans n'est de la modélisation. Tout cela, c'est ce qui a rendu le modèle utilisable.
- Une ingestion qui survit au réel. Les flux de ventes arrivent en retard, en double, ou pas du tout. Un POS redémarre et rejoue la veille. Nous avons construit une ingestion idempotente qui peut être relancée sans danger et qui met en quarantaine les lignes auxquelles elle ne fait pas confiance, plutôt que d'empoisonner le jeu d'entraînement.
- Un feature store doté de mémoire. Les variables sur lesquelles le modèle s'entraîne doivent être calculables au moment de la prédiction, avec uniquement les données dont vous disposeriez réellement à cet instant — sans jeter un œil dans le futur. Faire respecter cette exactitude point-in-time a représenté des semaines de travail et a permis d'attraper deux fuites qui avaient gonflé le backtest initial.
- Backfill et replay. Quand l'historique d'un site était faux, il nous fallait reconstruire toutes les prévisions en aval pour ce site sans mettre le système live à l'arrêt. Le replay, c'est de la tuyauterie que personne ne démontre et dont tout le monde a besoin.
- La supervision avant les fonctionnalités. Nous avons livré les alarmes de dérive et de fraîcheur avant de livrer la moitié de l'interface. Une prévision silencieusement fausse est pire qu'une prévision visiblement absente.
- L'override humain. Un nouveau site ouvre, un festival débarque, une route ferme. Le modèle ne peut pas le savoir. Les planificateurs avaient besoin d'un moyen autorisé d'ajuster le chiffre et de faire en sorte que le système apprenne de cet 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'emballage est le vrai travail03Le contrat de données
La chose la 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 valeurs nulles — 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 POS avait changé un champ de devise des centimes vers les dollars sans nous prévenir. Après le contrat, ce changement est rejeté à l'ingestion avec une erreur nommée et escaladée — et la dernière bonne prévision reste à l'écran au lieu d'une nouvelle, confiante et fausse.
# chaque source est validée à la porte, pas après qu'elle ait empoisonné l'entraînement sales_daily: units: int >= 0 # rejette les négatifs — les remboursements vont ailleurs revenue: decimal(10,2) # centimes → signalé en v3, désormais appliqué site_id: fk(sites) # site inconnu → quarantaine, escalade à l'astreinte recorded_at: freshness <= 6h # flux périmé → conserve la dernière bonne prévision on_violation: quarantine + alert # jamais : s'entraîner dessus en silence
C'est le cœur peu sexy de chaque système ML en production que nous avons livré. Le modèle est une fonction ; le contrat est ce qui garantit que la fonction reçoit les entrées qu'elle a été entraînée à attendre. Sautez-le et vous n'avez pas une plateforme de prévision — vous avez un générateur de nombres aléatoires très coûteux qui a raison la plupart du temps.
04La dérive est une fonctionnalité, pas un échec
Tout modèle se dégrade. Les goûts évoluent, un nouveau menu débarque, un concurrent ouvre en face. La question n'est jamais si le monde va se dérober sous votre modèle — c'est de savoir 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 ordre. La plateforme compare en continu les distributions des entrées live et l'erreur live aux références d'entraînement. Quand l'une ou l'autre 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 de combien elle a bougé.
- Elle protège la sortie — en élargissant les intervalles de confiance ou en se repliant sur une référence plus simple et plus robuste, plutôt que de faire confiance à un modèle qui extrapole désormais.
- Elle programme un réentraînement — avec les nouvelles données, conditionné au même seuil de backtest que l'original devait franchir.
Tenue en production, pas seulement sur le backtest.
Les frigos vides du midi, réduits de plus de moitié.
De la marge qu'on jetait autrefois en fin de journée.
Remarquez que le chiffre phare — 98 % — n'est pas le plus intéressant. Les chiffres intéressants sont les deux qui l'entourent, parce que c'est eux que l'entreprise ressent. La précision est l'entrée ; moins de gaspillage et moins de ruptures sont la sortie. Une plateforme qui optimise le premier en ignorant le second est un projet de labo.
05Le tableau de bord que quelqu'un consulte à 8 h
La prévision est consommée par un chef de cuisine au début d'un service, sur une tablette, café à la main, en quatre-vingt-dix secondes. Cette contrainte a façonné plus de décisions que ne l'a fait l'architecture du modèle.
Elle imposait que la réponse soit une quantité, pas une distribution de probabilité. Elle imposait que « je ne suis pas d'accord, voici pourquoi » tienne en un seul tap. Elle imposait que l'écran montre la prévision d'hier face à ce qui s'est réellement passé, parce que la confiance se gagne en étant visiblement responsable, pas en étant sûr de soi. Un modèle incapable de montrer son historique à la personne qui s'appuie sur lui sera ignoré en silence en moins d'une semaine.
Pas le score F1. Pas le RMSE. Le test d'acceptation, c'était un chef de cuisine, en deuxième semaine, qui dit « ouais, maintenant je fais juste ce qu'il dit ». 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 avec autant de soin que le modèle.
06Notes à nos nous d'avant
Si vous êtes sur le point de démarrer quelque chose de cette forme, voici ce que nous dirions à l'équipe qui a commencé il y a dix-huit mois :
- Budgétez l'emballage, pas le modèle. Partez du principe que le modèle représente 15 % de l'effort et planifiez délibérément les 85 % restants. Les équipes qui ratent leurs délais sont celles qui ont budgété l'inverse.
- Écrivez le contrat de données en premier. Avant la moindre variable. Il fera remonter une fuite dans votre backtest et vous évitera de livrer un chiffre que vous ne pouvez pas défendre.
- Livrez la supervision avant l'interface. Vous ne pouvez pas exploiter ce que vous ne pouvez pas voir, et une prévision fausse que personne n'a remarquée est le mode de défaillance qui fait perdre des contrats.
- Concevez l'override. Les humains sauront toujours des choses que le modèle ignore. Donnez-leur un levier autorisé et apprenez-en, sinon ils contourneront tout le système dans un tableur.
- Rendez le modèle responsable à l'écran. Montrez son historique à côté de sa prédiction. La confiance est autant une décision d'interface qu'une affaire de maths.
Le machine learning était la partie facile. Nous le disons non pour rabaisser le modèle — il est franchement bon — mais pour pointer là où réside réellement la difficulté. Le battage médiatique vend les trois semaines. Les cinq mois, c'est ce pour quoi vous payez vraiment une équipe d'ingénierie.
