« On devrait faire de l’IA » est devenue une phrase beaucoup trop facile à lancer dans une réunion. Ça paraît ambitieux sur une slide, mais ça ne dit pas ce qu’on veut régler.

Je préfère partir d’une décision qui existe déjà et suivre le trajet au complet. Prenons un distributeur qui veut réduire ses ruptures de stock. La décision n’est pas « utiliser l’IA ». C’est choisir, chaque semaine, combien d’unités commander pour chaque produit avant que le fournisseur livre.

Transformer l’historique en prévision

Il faut d’abord définir l’horizon. Si le fournisseur prend trois semaines à livrer et que la commande part le lundi, une prévision pour demain ne sert pas à grand-chose. On veut estimer la demande pendant le délai d’approvisionnement, avec assez de marge pour absorber une variation raisonnable.

Une table d’entraînement pourrait contenir une ligne par produit et par semaine :

produit | semaine | ventes_1s | ventes_4s | prix | promo | stock_disponible | demande_suivante
BX-42   | 2017-40 |        18 |        71 | 249  | 0     |               9 |                22

Les colonnes de gauche sont les features connues au moment de la prévision. demande_suivante est la cible observée plus tard. Le pipeline lit les ventes, aligne les calendriers, calcule les fenêtres de une et quatre semaines, encode les promotions, puis entraîne un modèle à minimiser une erreur entre la demande prévue et la demande réelle.

Je séparerais les périodes dans l’ordre : les premières semaines pour l’entraînement, les suivantes pour ajuster le modèle et les plus récentes pour le tester. Un mélange aléatoire peut laisser presque la même saison des deux côtés et donner une impression trop optimiste. Une validation glissante — entraîner jusqu’en juin, tester juillet; entraîner jusqu’en juillet, tester août — montre mieux comment le modèle aurait résisté au passage du temps.

La prévision n’est pas encore une commande

Le modèle peut retourner 20 unités par semaine. Le processus d’inventaire doit convertir ce résultat en action. Avec un délai de trois semaines et un stock de sécurité de 10 unités, un calcul simple donne :

point de commande = demande hebdomadaire × délai + stock de sécurité
                  = 20 × 3 + 10
                  = 70 unités

quantité suggérée = 70 - stock disponible - commandes déjà en route

Ce calcul montre les composantes que la démo oublie souvent. Le stock disponible doit exclure les unités déjà réservées. Les commandes en route ont une date promise qui peut changer. Le stock de sécurité dépend de la variabilité de la demande et du niveau de service qu’on veut offrir. Le modèle fournit une estimation; les règles d’approvisionnement la placent dans le vrai processus.

Les deux erreurs ne coûtent pas la même chose. Prévoir trop haut immobilise du capital, prend de l’espace et augmente le risque de rabais. Prévoir trop bas cause une rupture, une vente perdue ou un client déçu. Je veux donc mesurer le coût en dollars et en disponibilité, pas seulement une moyenne statistique comme la MAE.

Les données qui mentent sans le vouloir

Une rupture crée un cas particulièrement tannant. Si le stock tombe à zéro mardi et que le système enregistre trois ventes pour la semaine, il ne prouve pas que la demande était de trois. Il dit seulement qu’on n’a pas pu vendre davantage. Entraîner directement sur ces ventes apprend au modèle à prévoir peu justement quand le produit était populaire.

Il faut au minimum signaler les périodes de rupture, les exclure de certains calculs ou estimer la demande censurée avec prudence. Les promotions, changements de prix, nouveaux produits et délais fournisseur doivent aussi être disponibles au bon moment. Une promotion saisie après la semaine ne peut pas devenir une feature connue avant la décision.

Le résultat doit ensuite arriver dans le workflow de l’acheteur avec la prévision, une plage d’incertitude, le stock utilisé dans le calcul et les raisons d’une variation importante. Une suggestion dans un dashboard que personne n’ouvre ne commande rien.

Au départ, je garderais quelqu’un dans la boucle. Cette personne peut connaître une promotion non saisie, un retard fournisseur ou une commande exceptionnelle. Le système enregistre alors la prévision, l’ajustement humain, la décision finale et le résultat réel. Cette trace permet de voir si le modèle aide, si les corrections sont utiles et où les données manquent.

Un prototype montre qu’on sait entraîner un modèle. Le projet commence pour vrai quand la prévision arrive avant la commande, se transforme en quantité explicable et qu’on mesure autant le surstock que les ruptures. C’est là qu’on sait ce qu’on confie réellement au système.