En logistique, aucun système ne fonctionne isolément. Un seul envoi traverse l’ERP où la commande est créée, le TMS qui planifie le transport, le WMS qui pilote l’entrepôt, le portail du transporteur et le scanner dans la main d’un opérateur. Si ces systèmes ne se parlent pas automatiquement, quelqu’un ressaisit les données à la main, et chaque point de contact de ce genre est un retard, une erreur et un coût. Pour un directeur IT, l’intégration a cessé d’être un projet annexe pour devenir la fondation des opérations.
D’après notre expérience, le difficile n’est pas de relier deux systèmes pour une démonstration mais de garder des dizaines de ces connexions vivantes sous la charge, les pannes et un panel de partenaires en changement permanent. Nous n’avons pas d’étude de cas logistique à brandir ici, mais nous avons des ingénieurs qui construisent des intégrations de systèmes depuis des années - dans des projets industriels et embarqués, et là où nous avons relié des systèmes de classe entreprise à des fournisseurs externes. Nous apportons cette compétence à la logistique.
Pourquoi la logistique est-elle un enchevêtrement d’intégrations plutôt qu’un système unique ?
Parce qu’en logistique la valeur se crée aux jointures. La marchandise circule entre un expéditeur, un transporteur, un entrepôt et un destinataire, et en parallèle sa trace numérique doit circuler aussi : statut, documents, position, preuve de livraison - et chaque participant exploite son propre système, son format de données et son rythme de travail.
Un seul système géant ne résoudra pas cela. On construit plutôt une couche d’intégration qui traduit les messages entre les mondes, garde les événements en ordre et veille à ce qu’un statut venu d’un portail transporteur atteigne le TMS, et de là l’ERP et le client. C’est elle qui décide si une entreprise voit son exploitation en temps réel ou découvre les problèmes trop tard.
Qu’est-ce que l’EDI et comment organiser les intégrations avec les partenaires ?
L’EDI reste le moyen le plus répandu par lequel les partenaires logistiques échangent des documents structurés : commandes, avis d’expédition, confirmations de livraison, factures. Le hic, c’est que « l’EDI » n’est pas un standard unique mais une famille de standards et de variantes qu’il faut réconcilier.
En pratique, l’intégration EDI se ramène pour nous à une poignée de travaux récurrents :
- le mapping des formats - traduire l’EDIFACT, l’ANSI X12 ou des fichiers propres à un secteur vers le modèle de données du client et en sens inverse,
- le transport des messages - gérer les canaux AS2, SFTP ou VAN que les partenaires utilisent réellement pour envoyer les fichiers,
- la validation et le traitement des erreurs - attraper les messages incomplets ou non conformes avant qu’ils n’entrent profondément dans le système,
- l’onboarding de nouveaux partenaires - ajouter vite une contrepartie de plus, sans réécrire toute la logique de zéro.
Les mappings doivent rester faciles à maintenir, car les partenaires se multiplient et leurs formats diffèrent sur de petits détails douloureux.
Comment relier l’ERP et le TMS pour que planification et facturation concordent ?
L’ERP et le TMS sont les deux cœurs d’une entreprise logistique. Les commandes, les contreparties et les règlements vivent dans l’ERP, tandis que le TMS planifie les itinéraires, affecte les transporteurs et suit l’exécution. Si ces deux-là ne sont pas synchronisés, le planificateur travaille sur d’autres données que la comptabilité, et le client reçoit une facture qui ne correspond pas à ce qui est arrivé.
Pour nous, l’intégration TMS/ERP signifie concevoir un flux d’événements cohérent : une commande venue de l’ERP alimente la planification dans le TMS, et la mission réalisée, ses coûts et ses confirmations reviennent vers l’ERP pour le règlement. Nous tenons une source de vérité unique pour chaque objet - pour qu’une adresse, un poids ou un numéro de commande ne mène pas une vie séparée à trois endroits. Cela signifie généralement une fine couche intermédiaire plutôt qu’un lien point à point rigide, car ainsi remplacer un système ne fait pas tomber toute l’intégration.
Comment utiliser les API transporteurs et les places de marché logistiques ?
Aujourd’hui, la plupart des transporteurs et des plateformes exposent des API transporteurs modernes plutôt que le seul EDI. Cela ouvre des possibilités, mais multiplie les connexions à maintenir. Par ces interfaces, nous branchons le plus souvent :
- la cotation et la réservation de transport en temps réel chez plusieurs transporteurs à la fois,
- la génération d’étiquettes et de documents de transport sans se connecter à la main aux portails,
- le suivi des envois par webhooks et interrogation des statuts,
- les places de marché et bourses de fret, où l’offre et la demande de fret se rencontrent dynamiquement.
Le défi ici n’est pas une API mais leur diversité - des limites de débit différentes, des authentifications différentes, un même statut qui veut dire autre chose. C’est pourquoi nous concevons un modèle transporteur commun et y branchons les nouvelles intégrations, au lieu d’écrire chacune de zéro.
Comment relier appareils, scanners et capteurs aux systèmes ?
L’intégration ne s’arrête pas aux systèmes informatiques, car la logistique se déroule dans le monde physique. Scanners de codes-barres, terminaux mobiles, imprimantes d’étiquettes, balances, portiques RFID et capteurs embarqués génèrent un flux d’événements qui doit atteindre le WMS et le TMS au bon moment.
C’est là que notre expérience embarquée et industrielle paie, car l’intégration d’appareils suit d’autres règles que l’intégration d’applications : réseaux capricieux sur le terrain, protocoles propres au matériel et le fait qu’un appareil n’attendra pas le serveur. Nous construisons une couche qui collecte ces événements localement, les met en tampon quand la connectivité tombe et les transmet aux systèmes centraux au retour du lien.
Comment rendre les intégrations fiables : idempotence, retries, files d’attente ?
C’est la différence entre une intégration qui marche en démonstration et une à laquelle on peut se fier en production. En logistique, les messages se perdent, les réseaux cassent et un même statut peut arriver deux fois - une intégration non préparée affiche alors des envois dupliqués ou perd des preuves de livraison. Nous les concevons donc autour de quelques principes de résilience :
- l’idempotence - le même message reçu deux fois produit un effet, pas deux,
- les files d’attente et les brokers - les événements passent par une file qui lisse le trafic et ne perd pas de messages lors d’un pic de charge,
- les retries avec back-off - un appel échoué est rejoué à intervalles croissants, pas martelé une fois par seconde,
- une dead-letter queue - ce qui ne peut pas être traité atterrit dans un endroit à part pour analyse au lieu de disparaître,
- le monitoring et les alertes - l’équipe voit que quelque chose est bloqué avant que le client n’appelle.
Quelles compétences apportons-nous aux intégrations logistiques ?
Pour les intégrations, nous façonnons l’équipe autour de l’architecture précise, pas « au cas où ». Sur ce type de projets, nous pourvoyons typiquement :
- un architecte d’intégration qui conçoit les flux, le modèle de données et la couche intermédiaire,
- des développeurs backend qui construisent les connexions, les API et la logique de mapping,
- des spécialistes EDI qui connaissent la réalité de l’EDIFACT, du X12 et du transport de fichiers,
- des ingénieurs DevOps qui mettent en place les files d’attente, le monitoring et les déploiements.
Ainsi, nous n’apprenons pas l’intégration aux frais du client - nous arrivons avec des personnes qui ont déjà relié des systèmes de classe entreprise à des fournisseurs externes.
Comment procédons-nous chez RITS ?
Nous le faisons en partenaire nearshore depuis la Pologne qui ajoute de la compétence exactement là où elle manque. Nous ne prétendons pas avoir un déploiement logistique tout prêt sur l’étagère - nous fournissons plutôt des ingénieurs avec une expérience réelle des intégrations de systèmes et des projets industriels, des personnes capables de prendre en charge l’EDI, les API transporteurs et les appareils dans un même projet.
Le plus souvent, nous travaillons soit en logiciel sur mesure, quand la couche d’intégration doit être construite depuis la base, soit en renfort d’équipe, quand le client a sa propre équipe et doit combler vite une compétence manquante. Nous avons exposé les différences entre ces modèles dans notre article sur les modèles de collaboration IT.
Par où commencer l’intégration des systèmes logistiques ?
Commencez par cartographier un flux, le plus important - par exemple, de la commande dans l’ERP à la planification dans le TMS, jusqu’à un statut du transporteur et une confirmation pour le client. Ce seul flux montre quels systèmes doivent se relier, quels formats entrent en jeu et où les données sont ressaisies à la main aujourd’hui - et il définit le périmètre de la première étape, l’architecture de la couche d’intégration et les rôles dont vous avez besoin. Les autres partenaires et transporteurs viennent ensuite, sur une fondation qui fonctionne déjà.
Vous reliez vos systèmes logistiques - EDI, TMS, ERP et API transporteurs ? Parlons-en ; nous ajusterons une équipe et une architecture d’intégration à votre exploitation.