La prochaine fracture de l’IA : pourquoi les entreprises logistiques du marché intermédiaire doivent réparer leur infrastructure avant de pouvoir exploiter l’IA

La conversation autour de l’IA se concentre souvent sur l’accès, avec l’hypothèse que, une fois qu’une entreprise a accès aux bons modèles et outils, le prochain défi consiste à déterminer comment les utiliser. Pour les entreprises logistiques du marché intermédiaire, ce n’est pas nécessairement là que le problème commence.

Dans de nombreux entrepôts et chez les prestataires logistiques tiers (3PL), l’écart n’est rarement dû à un système manquant. La plupart disposent déjà d’un système de gestion d’entrepôt (WMS), d’un logiciel de planification des ressources d’entreprise (ERP) ou d’un package comptable, de connexions transporteur et d’EDI avec leurs grands clients. Le problème réside dans ce qui se passe entre ces systèmes.

Les connexions point à point s’accumulent avec le temps. Un client ou partenaire commercial se connecte d’une manière, un autre partenaire se connecte d’une autre façon et, finalement, personne n’a une vue complète de ce qui communique avec quoi. L’intégration dépend également des personnes, par exemple lorsqu’une personne ressaisit des commandes depuis le portail d’un client ou rapproche les expéditions d’hier dans une feuille de calcul chaque matin. Un 3PL peut ne pas savoir qu’une transaction a échoué jusqu’à ce qu’un client l’appelle pour demander où se trouve sa commande.

Aucun de ces éléments n’apparaît sur une liste d’actifs informatiques, ce qui explique pourquoi il est si facile de sous‑estimer le problème.

Le problème réside dans les transferts

Les plus gros problèmes opérationnels surviennent généralement aux points de transition, où une commande, une réception ou une expédition passe d’un système ou d’une entreprise à un autre :

• Une commande entrante qui arrive en retard ou mal formée peut entraîner une vague manquée et une date d’expédition perdue.
• Un avis d’expédition anticipé qui ne correspond pas à ce qui arrive physiquement peut interrompre la réception pendant que les employés enquêtent sur chaque palette.
• Une confirmation d’expédition qui n’atteint jamais le système du client peut créer un retard de facturation et entraîner un rétrofacturation, où un détaillant déduit une pénalité pour un manquement de conformité.

Pour un 3PL, ces problèmes se multiplient parce que chaque client a ses propres formats, règles et attentes. Le plancher d’entrepôt fonctionne généralement bien, mais le flux d’informations qui l’entoure se rompt.

Cette distinction devient plus importante à mesure que les entreprises introduisent l’IA dans leurs opérations, car elle ne peut fonctionner qu’avec les informations qui lui sont disponibles. Connecter un chatbot ou un copilote à un seul système peut constituer une bonne démonstration, mais cela ne donne pas à ce système la visibilité d’une opération qui s’étend sur plusieurs systèmes.

Dans la logistique, les questions utiles traversent souvent ces frontières, de sorte qu’une réponse concernant une commande peut nécessiter des informations provenant du WMS, de l’ERP et d’un système de transport ou client. Un outil d’IA qui ne voit qu’une partie de ce processus travaille à partir d’une image incomplète.

Il existe un fossé grandissant entre les entreprises dont l’infrastructure permet à l’IA de travailler avec les informations dont elle a besoin et les entreprises dont les systèmes restent déconnectés, et c’est là que la prochaine fracture de l’IA émerge.

L’IA a besoin d’une base avec laquelle elle peut réellement fonctionner

Une infrastructure réellement prête pour l’IA devrait être décrite en termes opérationnels plutôt qu’en termes technologiques. Chaque événement important, tel qu’une commande, une réception, un mouvement d’inventaire ou une expédition, devrait passer par un hub commun plutôt que d’une collection de connexions séparées. Le format envoyé par un partenaire commercial ne devrait plus être le problème de l’entrepôt. X12, EDIFACT, XML ou JSON devraient se normaliser sur la même commande avant que quiconque en aval n’ait à réfléchir au format.

Les équipes doivent savoir quand quelque chose échoue en quelques minutes, avant que le problème n’atteigne le client. Les mêmes informations que les employés utilisent pour identifier et résoudre ces problèmes doivent également être accessibles aux logiciels et aux agents IA via des API propres qui conservent les autorisations existantes. Il faut également disposer d’un enregistrement de ce qui s’est passé afin que, lorsque l’IA propose une solution, une personne puisse vérifier pourquoi.

Lorsque ces conditions sont réunies, l’ajout de l’IA devient beaucoup plus simple. Cela ne signifie pas qu’une entreprise du segment moyen doive remplacer l’ensemble de son infrastructure technologique. En fait, un 3PL du segment moyen n’a presque jamais besoin d’un nouveau WMS ou ERP simplement pour être prêt pour l’IA. L’approche la plus pratique consiste à laisser les systèmes centraux intacts et à corriger les connexions entre eux.

Un hub unique auquel chaque système et partenaire se connecte est beaucoup plus facile à gérer qu’un enchevêtrement de liens ponctuels.

L’IA peut aider à construire l’infrastructure

C’est également là que l’IA peut être particulièrement utile pour les entreprises du segment moyen. Traditionnellement, l’intégration nécessitait que les personnes lisent les spécifications des partenaires, cartographient les champs manuellement et testent ces mappings un partenaire à la fois. Un seul mapping de partenaire peut prendre des semaines de travail pratique, de tests ainsi que des allers‑retours avec le partenaire.

Les modèles d’IA actuels sont capables de lire les spécifications et les fichiers d’exemple, de proposer un mapping et de le tester sur de vraies transactions. Une personne peut ensuite examiner et approuver le résultat.

L’IA peut réduire le travail manuel nécessaire pour produire la première version d’un mapping EDI. Le spécialiste peut commencer avec un brouillon, puis le réviser et le corriger avant de le soumettre au cycle de révision existant du partenaire, ce qui permet aux spécialistes de passer moins de temps à construire les mappings champ par champ tout en conservant le contrôle sur le résultat final.

Mais il existe une distinction importante entre utiliser l’IA pour l’intégration et faire confiance à l’IA pour l’intégration.

Lorsque je fais cela, j’utilise une approche que j’appelle « Proposer, Ancrer, Vérifier, Confirmer ».

L’IA propose la configuration du partenaire et le mapping des champs. Elle s’appuie sur la spécification réelle et les fichiers d’exemple plutôt que d’inventer des champs ou des codes. Un processus de vérification séparé compare le mapping champ par champ avec un document réel. Ensuite, une personne confirme le résultat avant qu’il n’atteigne un flux client en production. 

Nous avons compris pourquoi cette discipline est importante en testant les cartes générées par l’IA contre de vrais documents de production.

Dans un test, une carte générée par l’IA a lu un document de transfert d’entrepôt sans aucune erreur mais a tout de même omis les 15 lignes d’articles. Dans un autre, elle a conservé les six parties d’un bon d’expédition mais a perdu le code identifiant la partie destinataire, ainsi que l’adresse postale. Notre contrôle automatisé a déclaré la carte propre, et un spécialiste EDI a détecté la lacune.

Même les données de référence peuvent être erronées. Un fichier de normes prétendant avoir été vérifié ne correspondait pas à la norme publiée sur chaque segment contesté que nous avons testé.

La leçon est qu’un résultat partiel peut être plus difficile à détecter qu’un résultat manquant. La vérification doit comparer chaque champ d’un document réel avec ce que la carte a capturé. Confirmer qu’un document se parse n’est pas suffisant. 

Des résultats fiables dépendent de la discipline entourant le modèle, depuis son utilisation jusqu’à la manière dont ses sorties sont examinées.

La valeur commence avant que l’IA ne prenne une décision

Le travail d’infrastructure a également de la valeur bien avant qu’un agent IA ne formule des recommandations opérationnelles. Un 3PL avec lequel nous avons collaboré faisait fonctionner SAP en parallèle de son système d’entrepôt. Chaque réception entrante prenait trois à cinq minutes de saisie manuelle, et l’inventaire dans SAP était en retard d’environ 20 minutes par rapport au quai.

Une fois les deux systèmes connectés directement, ce retard est devenu quasi en temps réel. L’opération a économisé plus de 980 heures de travail par an, dont 775 heures sur les travaux sortants. Le suivi via feuilles de calcul a disparu, tandis que les étiquettes, connaissements et listes de colisage ont commencé à être générés automatiquement. L’entrepôt a conservé ses flux de travail existants, de sorte que personne sur le terrain n’a eu besoin d’être requalifié. 

La leçon que nous avons tirée de ce projet était plus importante que les économies de main-d’œuvre. Une fois que deux systèmes partagent une même image actuelle, cette même image est ce dont un agent IA a besoin pour être utile.

Les connecter est l’étape qui rend tout ce qui suit possible. 

La préparation de l’IA commence par l’intégration

Pour les entreprises qui décident par où commencer, l’intégration doit être prioritaire, l’IA effectuant une grande partie du travail d’intégration. Trop souvent, l’erreur des opérations consiste à considérer l’IA comme quelque chose qui ne doit intervenir qu’à la fin du processus. Elle peut aider à rendre le travail d’intégration plus rapide et moins coûteux au départ, puis aider à la prise de décision une fois que cette base est en place. 

Les entreprises logistiques de taille moyenne n’ont pas nécessairement besoin de davantage de technologie. Beaucoup disposent déjà des systèmes dont elles ont besoin. L’opportunité est de faire fonctionner ces systèmes ensemble. C’est là que l’IA peut jouer un rôle qui va au-delà de la simple génération d’une réponse supplémentaire à l’écran.