Le scénario est fictif, mais le problème est courant. Un modèle prévoit qu’une commande va arriver en retard. Son score est bon, la démo fonctionne et l’alerte apparaît dans un nouveau dashboard. Pendant la journée, personne n’ouvre ce dashboard. La prédiction était correcte, mais elle n’a changé aucune décision.

Un système de prédiction en production est une chaîne. Un processus extrait les commandes, calcule les mêmes variables que pendant l’entraînement et appelle le modèle. Le résultat — par exemple risqueRetard=0,87 — doit être enregistré avec la version du modèle et l’heure. Une règle transforme ensuite le score en action : ignorer, demander une revue ou ouvrir une intervention. Une file remet le travail à une personne dans son outil habituel.

ERP → données de commande → features → modèle → score
                                      ↓
                              règle de décision
                                      ↓
                     file de travail → action → résultat
                                                    ↓
                                             feedback futur

Le seuil ne vient pas seulement de l’algorithme. Si une équipe peut traiter 50 alertes par jour, un seuil qui en produit 300 crée un arriéré où même les bons cas expirent. Je comparerais plusieurs seuils :

Seuil	Alertes/jour	Retards détectés	Fausses alertes
0,50	300	92 %	nombreuses
0,75	80	78 %	modérées
0,90	20	51 %	peu nombreuses

Le bon point dépend du délai disponible, du coût d’un appel inutile et du coût d’un retard non traité. Il peut aussi varier selon le type de commande. Une décision financière ou difficile à renverser garde une approbation humaine; un score ne donne pas automatiquement un droit d’action.

Le workflow a besoin d’états

Une alerte devrait posséder une identité et un cycle explicite :

Nouvelle → Assignée → En analyse → Action lancée → Résolue
                 ↘ Expirée / Faux positif / Impossible à traiter

L’identifiant relie la commande, le score et les actions. Si le service réessaie après un timeout, la contrainte unique empêche deux alertes pour la même commande et la même version de prédiction. Un changement important de la commande peut invalider le score précédent et déclencher une nouvelle version plutôt que modifier l’historique.

La file définit une priorité et un délai. Une alerte reçue après le départ du camion n’a aucune valeur, même avec 99 % de précision. Le monitoring doit donc suivre latence des données, temps d’inférence, âge des éléments en attente, taux d’action et résultat, pas seulement l’AUC du modèle.

Le feedback demande de la prudence. « Aucun retard » après une intervention peut vouloir dire que le modèle avait raison et que l’équipe l’a évité; l’étiqueter comme faux positif apprendrait la mauvaise leçon. Je conserve l’action prise et, si possible, un groupe ou une période de comparaison. Les décisions humaines ne sont pas automatiquement la vérité parfaite non plus; elles peuvent varier selon la personne.

Une panne du modèle ne devrait pas arrêter le traitement des commandes. Le système peut revenir aux règles existantes, marquer les prédictions indisponibles et garder une file à reprendre. Une nouvelle version passe en parallèle sur un échantillon avant de remplacer l’ancienne. Si sa distribution de scores ou sa latence change fortement, le déploiement s’arrête.

Les données et explications suivent les droits de l’ERP. Une alerte ne devrait pas exposer le prix, le client ou les notes à quelqu’un qui ne pouvait pas voir la commande source. Le journal conserve score, modèle, seuil, décision et identité de l’opérateur, sans recopier inutilement tout le dossier.

Avant de financer le modèle, je dessinerais ce flux avec les personnes qui font le travail et je chronométrerais une alerte fictive. Si personne n’a le droit, le temps ou l’information pour agir, le cas d’usage n’est pas prêt. La pratique est de mesurer la chaîne jusqu’au résultat métier; la prédiction n’est qu’une étape, pas la valeur finale.