Nos données ERP suffisent-elles pour l'IA ? Oui, presque toujours
Le socle qu'un modèle exige tient dans ce que tout ERP enregistre déjà : ventes, commandes, nomenclatures, délais, stocks. Ce qui manque vraiment ne se trouve pas dans l'ERP, et un projet de nettoyage de deux ans ne l'y mettra pas.
L'essentiel
Le socle qu'un modèle exige tient dans ce que tout ERP enregistre déjà : ventes, commandes, nomenclatures, délais, stocks. Ce qui manque vraiment ne se trouve pas dans l'ERP, et un projet de nettoyage de deux ans ne l'y mettra pas.
Ma réponse, avant les nuances
« Nos données ne sont pas prêtes » est l'objection que j'entends en premier dans une ETI industrielle, et je la prends au sérieux parce qu'elle vient de gens qui connaissent leurs systèmes. Mon avis est pourtant qu'elle est fausse dans la grande majorité des cas sur l'essentiel, et vraie sur des points que personne ne nettoiera jamais. Un ERP qui facture, expédie et réceptionne depuis cinq ans contient tout ce dont un modèle de décision supply chain a besoin pour démarrer, dans un état imparfait mais exploitable. Ce qui lui manque relève moins de la propreté que d'une catégorie d'information que l'ERP n'a jamais été conçu pour enregistrer, et c'est sur cette distinction que se joue la décision de commencer ou d'attendre. Je vais détailler ce qu'un modèle exige, ce qui manque presque toujours, pourquoi cela n'empêche pas de démarrer, et pourquoi le projet de nettoyage préalable est, à mes yeux, la pire des réponses.
Ce qu'un modèle exige vraiment
Le socle est plus court que ce que l'on imagine. Il faut un historique de ventes et de commandes à la maille de la décision, en général la référence par site et par semaine, sur assez de temps pour couvrir les saisons que l'on veut reconnaître. Deux à trois cycles sont confortables, et un seul suffit pour les usages de détection d'écart. Il faut les nomenclatures pour dériver la demande des composants de celle des produits finis, et les délais fournisseurs et de production tels qu'ils ont été constatés, pas seulement tels qu'ils sont saisis dans la fiche article. Il faut enfin les positions et mouvements de stock, les commandes ouvertes des deux côtés, et les coûts unitaires qui permettent de traduire une recommandation en euros. Tout cela existe dans l'ERP parce qu'il en a besoin pour fonctionner : on ne facture pas sans commande, on ne réceptionne pas sans date. Le doute légitime porte sur la cohérence de ces données entre modules et entre sites, pas sur leur existence, et la cohérence se vérifie en quelques jours d'extraction là où l'existence, elle, ne se crée pas.
Ce qui manque presque toujours, et que l'ERP n'a jamais eu
Le vrai trou est ailleurs, et il est de nature différente. L'ERP enregistre ce qui a été livré, pas ce qui a été demandé : une rupture apparaît comme une vente faible, et un modèle qui apprend sur cet historique conclut que la demande a baissé au moment même où elle dépassait l'offre. Il n'enregistre pas non plus les décisions prises, le transport express arbitré par téléphone, la réallocation entre deux clients décidée dans un couloir, le lot avancé à la demande du commercial. Il n'enregistre pas davantage leurs causes, la machine en panne, le fournisseur en grève, la promotion du distributeur qui a doublé les sorties. Ces informations vivent dans les boîtes mail, les tableurs personnels et la mémoire des planificateurs, et elles sont exactement ce qui permettrait à une IA supply chain de distinguer un signal d'un bruit. Aucun projet de nettoyage ne les fera apparaître, parce qu'on ne nettoie pas ce qui n'a jamais été saisi, et c'est pour cela que la question « nos données suffisent-elles » est mal posée : le socle suffit, et le manque se comble par l'usage, pas par un chantier préalable.
Pourquoi on peut commencer avec des données imparfaites
Trois raisons me rendent tranché sur ce point. La première est que les modèles tolèrent bien mieux le bruit que l'absence : un délai fournisseur légèrement faux dégrade une recommandation, un délai absent l'empêche, et les ETI sont dans le premier cas bien plus souvent que dans le second. La deuxième est que l'usage de décision demande moins que l'usage de prévision fine : détecter qu'une situation s'écarte de l'habitude exige une référence, pas un historique parfait, et c'est l'écart, pas la valeur absolue, qui déclenche un arbitrage. La troisième est que démarrer est le seul moyen de commencer à enregistrer ce qui manque : dès que les décisions passent par un outil, la rupture est qualifiée comme rupture, l'arbitrage est daté et motivé, la cause est notée. Le trou dont je parlais plus haut commence alors à se combler avec les données que l'on produit chaque semaine. Un modèle qui tourne sur des données imparfaites signale d'ailleurs lui-même où il hésite, ce qui donne une liste de corrections classée par impact, alors qu'un audit préalable donne une liste classée par ordre alphabétique.
Le piège du projet de nettoyage de deux ans
Le réflexe de vouloir tout fiabiliser avant de commencer produit un projet que je connais bien : un chantier de référentiel, une gouvernance de la donnée, des ateliers par module. Et au bout de dix-huit à vingt-quatre mois, un ERP plus propre sur des données qui ont depuis continué de vieillir à la vitesse des opérations. Les données se polluent au rythme où l'on crée des articles et où l'on modifie des délais, de sorte que le nettoyage d'aujourd'hui décrit l'entreprise d'hier, et personne n'entretient une donnée qu'aucun système ne lit, parce que ses erreurs n'ont aucune conséquence visible. L'alternative que je défends tient en une phrase : corriger, en quelques semaines, les trois ou quatre champs que le cas d'usage visé lit réellement, le délai constaté, le statut de rupture, l'unité de gestion, la correspondance article entre sites, et laisser l'usage désigner le reste. Cette approche coûte une fraction du chantier complet, produit une décision supply chain utile dès le premier trimestre, et améliore la qualité des données plus sûrement qu'aucun programme, parce qu'une donnée dont dépend une commande est corrigée par celui que la mauvaise commande dérange.
Les deux cas où la réponse est non
Pour être honnête jusqu'au bout, il existe des situations où le socle d'une IA supply chain manque vraiment. La première est l'absence d'historique : un site ouvert depuis six mois, une gamme lancée cette année, une activité passée d'un ERP à un autre sans reprise des mouvements. Dans ces cas, aucun modèle n'apprendra une saisonnalité qu'il n'a jamais vue, et l'on travaillera par règles et par analogie avec des familles voisines en attendant. La seconde est l'incompatibilité des référentiels entre sites sans aucune clé de correspondance, quand le même composant porte trois codes et que personne ne peut affirmer qu'il s'agit du même, parce qu'un modèle ne peut pas deviner ce que l'organisation elle-même ignore. Il reste le cas fréquent où l'ERP n'est pas le système de vérité et où le planning vit dans des tableurs : ces tableurs sont des données, moins structurées mais réelles, et un outil qui sait les lire démarre avec elles. Même dans ces trois situations, la réponse raisonnable est de commencer plus petit, sur une famille dont l'histoire existe, plutôt que de lancer deux ans de nettoyage en espérant que le besoin attende.
Cet article part d'une conviction : la prévision parfaite n'existe pas, ce qui compte c'est la décision d'après.
- Ma réponse, avant les nuances
- Ce qu'un modèle exige vraiment
- Ce qui manque presque toujours, et que l'ERP n'a jamais eu
- Pourquoi on peut commencer avec des données imparfaites
- Le piège du projet de nettoyage de deux ans
- Les deux cas où la réponse est non
Clevizio
Clevizio est la couche de décision qui se branche sur vos outils existants : elle détecte l'imprévu, simule vos options et garde la mémoire de chaque arbitrage. Découvrir comment fonctionne le copilote de décision.
Nelson Mukuze
CTO & CAIO, cofondateur de Clevizio
Une question sur vos imprévus ? Réservez 30 minutes avec moi pour estimer ce qu'ils vous coûtent vraiment, sans engagement.
Questions fréquentes
Quelles données faut-il pour un projet d'IA en supply chain ?
Un historique de ventes et de commandes, les nomenclatures, les délais constatés, les stocks et mouvements, les commandes ouvertes et les coûts unitaires. L'historique se prend à la maille de la décision, en général la référence par site et par semaine, et les délais fournisseurs et de production sont ceux constatés, pas ceux de la fiche article. Tout cela existe dans un ERP qui facture et réceptionne. Ce qui manque le plus souvent, les ruptures qualifiées, les décisions prises et leurs causes, se construit par l'usage.
Combien d'historique faut-il pour entraîner un modèle de prévision ?
Deux à trois cycles saisonniers donnent une base confortable pour reconnaître les saisonnalités. Un seul cycle suffit pour les usages de détection d'écart, qui comparent une situation à son habitude plutôt que de prédire une valeur absolue. En dessous d'un cycle, on travaille par règles et par analogie avec des familles voisines.
Faut-il nettoyer les données ERP avant un projet IA ?
Pas en bloc : il suffit de corriger les quelques champs que le cas d'usage lit vraiment. En quelques semaines, ces trois ou quatre champs sont corrigés et le projet peut démarrer, puis l'outil en fonctionnement désigne ensuite les corrections par ordre d'impact. Un chantier préalable de deux ans livre des données déjà vieillies et ne fait pas apparaître ce que l'ERP n'a jamais enregistré.
À lire aussi
Mettez enfin un chiffre sur ce que vos imprévus vous coûtent chaque année.
Commençons par estimer ce que vos imprévus vous coûtent réellement. C'est gratuit, ça prend 30 minutes, et vous repartez avec un chiffre que personne dans votre entreprise ne connaît aujourd'hui.