L'an dernier, un 3PL de l'Ontario m'a fait venir comme consultant. Ils voulaient de la prévision de demande par IA, la démo du fournisseur était impeccable et le contrat était pratiquement signé. J'ai passé deux jours sur place et, de retour, j'ai dit au patron d'emblée : si vous dépensez cet argent maintenant, il est perdu. Non pas parce que l'algorithme était mauvais — mais parce que sur plus de 20 000 références, plus de 4 000 n'avaient même pas de code-barres. Les préparateurs identifiaient les produits de mémoire. Aucun algorithme au monde ne peut prévoir la partie de votre stock qui vit dans la tête de quelqu'un.
C'est la façon la plus courante dont l'IA meurt dans un entrepôt : elle meurt des données, pas de la technologie. J'ai vu une douzaine de pilotes IA au fil des ans, et sept ou huit échecs sur dix remontent à une préparation des données qui n'a jamais eu lieu. Les fournisseurs ne vous le diront pas d'eux-mêmes — ils gagnent de l'argent en vendant des licences, alors ils aimeraient que vous signiez tôt. Voici ma propre liste de contrôle : avant que l'IA ne passe en production, trois catégories de données d'entrepôt doivent être nettoyées d'abord. Si une catégorie n'atteint pas le seuil, ne lancez pas le cas d'usage qui en dépend. Vous économiserez plus que vous ne pensez.
Données de référence : SKU, emplacements, lots — « à peu près » ne suffit pas
Les données de référence sont le socle sur lequel repose tout modèle d'IA. Attributs SKU manquants, codes d'emplacement en désordre, informations de lots bricolées à la main — en exploitation classique, on peut masquer tout cela avec le savoir tribal des anciens. Dès que l'IA entre en scène, chaque trou devient une mine terrestre.
J'impose à mes clients trois seuils durs. D'abord, une complétude des données de référence SKU au-dessus de 95 % : dimensions, poids, spécifications de colisage, classe ABC. S'il manque des choses, le slotting et la planification des vagues de l'IA, c'est « poubelle entrée, poubelle sortie ». Ne croyez pas que « l'algorithme comble les lacunes tout seul » : des dimensions fausses de 10 % signifient que chaque recommandation de carton est fausse.
Ensuite, 100 % des emplacements doivent être scannables. L'IA qui répartit les AMR et optimise les parcours de déplacement suppose que chaque emplacement du système correspond à un emplacement physique. J'ai vu un bâtiment avec 12 000 emplacements dans le système où un audit au sol a révélé plus de 300 emplacements fantômes : étiquettes tombées, racks démontés, mais toujours présents dans la base de données. Donnez cela à manger à une IA et chaque itinéraire qu'elle planifie est une fiction.
Troisièmement, les données de lots et de péremption doivent boucler la boucle. Pour les entrepôts alimentaires et pharmaceutiques qui font tourner une IA d'alerte de péremption, sans enregistrements d'entrées/sorties au niveau du lot, il n'y a tout simplement aucun échantillon d'entraînement. Ce sont les données les plus lentes à reconstruire, car l'historique n'existe généralement pas — vous commencez à collecter aujourd'hui et attendez un trimestre complet.
Comment réparer cela ? Ne lancez pas de campagne de nettoyage. Ma méthode : échantillonnez 200 SKU, calculez le taux d'erreur des données de référence. Au-dessus de 15 %, il faut une reconstruction systématique — prévoyez deux à trois mois. En dessous de 5 %, vous pouvez lancer l'IA et compléter en parallèle. Faites ce calcul en amont, pas après la mise en production de l'algorithme.
Données d'événements : les horodatages doivent être continus, sinon l'historique ne vaut rien
L'IA apprend comment votre entrepôt fonctionne réellement, et son manuel, c'est chaque scan, chaque mise en stock, chaque horodatage de vague. Le plus gros problème ici, ce n'est pas les données manquantes — ce sont les données cassées.
Beaucoup d'entrepôts scannent la réception, la mise en stock et la préparation religieusement, puis gèrent le pack et l'expédition sur papier. Les horodatages s'arrêtent à mi-chemin. Une IA qui essaie d'apprendre le vrai temps de cycle de commande se heurte à une impasse en pleine leçon. D'autres laissent l'équipe de nuit sauter des scans pour tenir le rythme, laissant des pans entiers du registre vides — un modèle entraîné sur ces données sous-estimera systématiquement la capacité de l'équipe de nuit.
Mon seuil d'acceptation : une couverture de scan au-dessus de 90 % à chaque étape clé, continue pendant trois mois. Pas encore là ? Deux solutions. La moins chère, c'est le management de la conformité de scan : mettez le taux de scan dans le KPI d'équipe, et la couverture grimpe en deux mois pour un coût quasi nul. La coûteuse, c'est du matériel, comme des unités automatiques de pesée-scan aux postes de pack. Je recommande généralement la moins chère d'abord — corrigez l'habitude, obtenez la continuité, puis on parle IA.
Une chose de plus : gardez au moins six mois d'historique couvrant un cycle complet basse/haute saison. Un modèle entraîné uniquement sur des données de haute saison criera au loup pendant toute la basse saison, et inversement. Quand un fournisseur dit « trois mois de données suffisent amplement », c'est le bruit de quelqu'un qui veut être payé plus tôt.
Données de résultats : sans bulletin de notes, l'IA ne sera jamais diplômée
Les deux premières catégories sont des entrées. Celle-ci, ce sont des sorties : journaux d'écarts d'inventaires tournants, relevés d'erreurs de préparation, taux de ponctualité, classification des motifs de retour. Les modèles ont besoin de données de résultats pour savoir s'ils ont raison. Sans elles, après la mise en production, vous ne pouvez même pas dire si le modèle s'améliore ou hallucine.
C'est le plus ignoré parce que les données de résultats vivent partout : les écarts dans un tableur, les réclamations dans les e-mails, les motifs de retour dans la tête de quelqu'un. L'an dernier, j'ai évalué un client pour un inventaire tournant par vision IA et j'ai trouvé deux ans de relevés d'écarts stockés uniquement en totaux — sans détail par SKU. Le modèle ne pouvait même pas apprendre où étaient les erreurs. Son plafond de précision était évident avant même de commencer.
La solution, c'est un journal maître de résultats : date, SKU, étape du processus, type de problème, impact en euros. Enregistrez-le à la main pendant deux mois pour prendre l'habitude, puis systématisez. Il y a aussi un bénéfice collatéral : beaucoup de problèmes de management émergent de ce seul journal. Vous obtenez une amélioration du management avant même l'arrivée de l'IA.
Réalité du budget : la préparation des données absorbe 60–70 % du projet. Ne soyez pas surpris.
Honnêtement : dans un pilote IA, la préparation des données consomme typiquement 60 à 70 pour cent du temps et des efforts ; la sélection et le déploiement de l'algorithme prennent le reste. Les plans de projet des fournisseurs disent rarement cela — ils listeront la préparation des données comme « deux semaines de coopération client ». Croyez-le, et votre projet dérape de trois mois minimum.
Mon conseil : faites un bilan de santé des données avant le lancement, en notant chacune des trois catégories sur dix. En dessous de 18 au total, ne parlez même pas d'IA — menez la préparation des données comme son propre projet de trois à six mois, puis revenez. Au-dessus de 24, allez directement au POC. J'ai fait ce bilan pour cinq ou six clients, et à chaque fois il a tué un ou deux projets condamnés. Les économies sont de l'argent réel.
La vérité brute : la préparation des données n'a aucun glamour. C'est tout du travail de forçat, c'est pourquoi personne ne se porte volontaire — les fournisseurs la sautent, et personne en interne ne s'en charge. Mais à l'ère de l'IA, les données sont les nouveaux racks. Des racks en désordre signifient des produits perdus ; des données en désordre signifient que votre IA est de la décoration. Coulez d'abord les fondations, et la partie algorithme devient facile.
Traduit de l'anglais. En cas de divergence, la version anglaise fait foi.
