Digitalisation et systèmes d’information transport : le guide du chargeur

Un chargeur qui confie ses expéditions à un transporteur lui confie aussi, sans toujours s’en rendre compte, une partie de son système d’information. Chaque commande transmise, chaque statut de livraison reçu, chaque preuve archivée transite par des outils numériques dont la qualité conditionne directement la fiabilité de la chaîne : un retard mal signalé coûte un litige client, une preuve de livraison introuvable coûte un impayé, un format d’échange bancal coûte des heures de ressaisie manuelle chaque semaine.

Ce guide se place du côté du chargeur, pas de celui de l’éditeur de logiciel : il ne compare aucune solution commerciale et ne classe aucun outil. Il répond à une question plus utile pour un responsable supply chain ou un directeur des systèmes d’information (DSI) : qu’est-ce qu’un système d’information transport doit réellement prouver, et qu’est-ce qu’un chargeur peut légitimement exiger de son transporteur, en dehors de toute promesse commerciale ? Les briques qui composent ce système, du logiciel de pilotage des tournées à la lettre de voiture électronique, sont détaillées ici dans leurs grandes lignes ; chacune fera l’objet d’un article dédié plus approfondi dans les prochains mois.

Qu’est-ce qu’un système d’information transport, et que change-t-il pour vous ?

Un système d’information transport regroupe l’ensemble des outils numériques et des flux de données qui pilotent une expédition, de la commande jusqu’à la preuve de livraison : logiciel de planification des tournées, informatique embarquée dans les véhicules, échanges de données entre le progiciel de gestion intégré (ERP, enterprise resource planning) du chargeur et celui du transporteur, documents dématérialisés, outils de suivi. Il ne se limite pas à un logiciel unique : c’est une chaîne, et une chaîne vaut ce que vaut son maillon le plus faible.

Pour un chargeur, l’enjeu n’est pas technologique en soi, il est opérationnel. Un système d’information transport fiable réduit trois coûts concrets : le coût du litige (une preuve de livraison introuvable ou contestée), le coût de la ressaisie (des données transmises par téléphone ou par fichier tableur qu’il faut ressaisir manuellement dans l’ERP) et le coût de l’incertitude (un client final qui appelle parce que personne ne sait où se trouve sa marchandise). Ces trois coûts ne figurent sur aucune facture de transport, mais ils pèsent sur la marge autant que le prix du gazole.

La digitalisation du transport routier de marchandises n’est pas un sujet marginal : les flux d’information pilotent désormais les flux physiques autant que l’inverse. Un transporteur qui ne sait pas produire une donnée fiable et horodatée n’est pas seulement en retard technologique, il expose son client chargeur à un risque contractuel et juridique dès qu’un litige survient. C’est pourquoi les exigences numériques méritent de figurer dans le cahier des charges d’un appel d’offres transport au même titre que le prix ou le délai.

Le TMS : ce qu’il pilote réellement, et ce qu’il faut pouvoir en extraire

Les fonctions centrales d’un système de gestion du transport

Le TMS (transport management system, système de gestion du transport) est le logiciel central du système d’information transport côté prestataire. Il couvre en principe quatre fonctions : la planification des tournées et l’optimisation du chargement, l’affectation des moyens (véhicules et conducteurs), le suivi de l’exécution en cours de route, et la facturation. Un TMS bien paramétré rapproche automatiquement la commande, l’exécution et la facture ; un TMS mal paramétré, ou absent, oblige à vérifier chaque facture ligne par ligne.

Le TMS n’est cependant qu’un outil de pilotage interne au transporteur. Ce qui intéresse le chargeur n’est pas la façon dont les tournées sont optimisées, mais ce que l’outil est capable de restituer vers l’extérieur : une donnée exploitable dans son propre système d’information, pas seulement un écran de suivi consultable en interne chez le prestataire.

Ce qu’un chargeur doit pouvoir en extraire : visibilité, preuve, coût

Trois types de restitution doivent être exigibles, indépendamment de l’éditeur retenu par le transporteur. D’abord la visibilité : un statut d’expédition consultable sans appel téléphonique, avec une heure d’arrivée estimée (ETA, estimated time of arrival) recalculée en cours de route, pas figée au moment du chargement. Ensuite la preuve : un document de livraison horodaté et archivé, accessible sans délai après la livraison, pas seulement sur demande écrite. Enfin le coût : un historique d’expéditions exportable, avec le détail par ligne (trajet, poids, délai réel contre délai contractuel), qui permet de calculer un coût réel par expédition et de challenger un tarif l’année suivante sur des données, pas sur une impression.

Un TMS récent sait produire ces trois restitutions automatiquement. Un système ancien, ou un système utilisé uniquement en interne sans interface vers l’extérieur, oblige le chargeur à reconstituer ces informations à la main : c’est le signal le plus concret d’un système d’information transport insuffisant, bien avant toute question de marque ou de version logicielle.

Visibilité temps réel : ce qui est vérifiable, ce qui reste déclaratif

La visibilité temps réel de l’expédition, ou RTTV (real-time transportation visibility, visibilité transport en temps réel), désigne la capacité à connaître la position et le statut d’un envoi à tout moment, sans intervention humaine pour la produire. C’est ce mot « sans intervention humaine » qui sépare une visibilité réellement vérifiable d’une visibilité seulement déclarative.

Une position déclarée par un conducteur au téléphone, ou saisie manuellement dans une application par le chauffeur à chaque étape, reste une donnée déclarative : elle dépend de la discipline de saisie, elle est rétrospective de quelques minutes à quelques heures, et elle disparaît des radars en cas d’oubli. Une position issue de la géolocalisation automatique de l’informatique embarquée, couplée à des événements générés par le véhicule lui-même (démarrage, arrêt prolongé, ouverture de la caisse, chargement, déchargement), est vérifiable : elle ne dépend d’aucune saisie et alimente le système sans latence.

Ce qu’un chargeur doit exiger n’est donc pas « le tracking » en général, formule trop vague pour être contractualisée, mais des critères précis : la fréquence de rafraîchissement de la position (les écarts vont couramment de la mise à jour continue à un pointage toutes les heures selon l’équipement embarqué), la génération automatique des événements clés du trajet, et la distinction, dans l’outil de suivi lui-même, entre une donnée automatique et une donnée saisie manuellement. Un fournisseur qui ne peut pas répondre à ces trois points propose une vitrine de suivi, pas une visibilité réellement exploitable pour anticiper un aléa.

Connecter votre système d’information à celui du transporteur : EDI et API

L’EDI, le format éprouvé de l’échange B2B

L’EDI (échange de données informatisé) désigne l’échange automatique de documents structurés entre deux systèmes d’information, sans ressaisie manuelle. C’est la technologie la plus ancienne et la plus répandue de ce guide, et c’est aussi la plus fiable pour des flux répétitifs et volumineux : commande, avis d’expédition, statut de transport, facture. Les messages EDIFACT (norme internationale d’échange de données informatisé) les plus courants du transport portent des noms techniques qu’un chargeur croise rarement mais que son service informatique doit connaître : l’avis d’expédition (DESADV), l’instruction de transport (IFTMIN) et le message de statut de transport (IFTSTA), qui informe automatiquement le système du chargeur d’un chargement, d’un passage en douane ou d’une livraison.

L’EDI a un défaut connu : sa mise en œuvre initiale prend du temps (cartographie des flux, tests, recette), et chaque nouveau partenaire commercial nécessite en général une nouvelle interface, ou au minimum un nouveau mappage de champs. C’est pourquoi l’EDI reste la référence pour les relations durables et à fort volume, moins pour un partenaire ponctuel.

L’API, l’échange en temps réel sous conditions

L’API (interface de programmation applicative, application programming interface) permet à deux systèmes de dialoguer en direct, généralement au format REST/JSON, sans passer par des fichiers échangés à intervalles fixes. Elle convient particulièrement aux flux qui ont besoin d’instantanéité : interrogation d’une position, réception d’une notification d’événement (webhook), création d’une commande de transport à la volée depuis l’ERP du chargeur.

Une API n’est utile que si elle est gouvernée correctement. Un chargeur doit pouvoir exiger, avant intégration : une documentation technique à jour et accessible sans négociation commerciale préalable, un mécanisme d’authentification sécurisé (jeton d’accès, pas un identifiant et un mot de passe partagés en clair), un engagement de disponibilité du service (taux de disponibilité annoncé, fenêtre de maintenance prévisible) et une politique de gestion des versions qui évite qu’une mise à jour côté transporteur casse l’intégration côté chargeur sans préavis.

Le choix entre EDI et API n’est pas un choix technologique tranché : beaucoup de transporteurs sérieux maintiennent les deux, l’EDI pour les flux structurants et récurrents, l’API pour les besoins ponctuels ou les intégrations plus légères. Ce qui doit alerter un chargeur, ce n’est pas l’absence de l’un des deux formats, c’est l’absence des deux : un transporteur qui ne propose que la ressaisie manuelle ou l’échange de fichiers tableur par courriel reporte sur son client l’intégralité du coût de l’intégration.

Dématérialisation documentaire : de la lettre de voiture à l’e-CMR

La lettre de voiture reste, en document de transport, la pièce centrale de toute expédition : son établissement avant l’enlèvement est obligatoire pour tout transport public routier de marchandises, en application de l’article R3411-13 du code des transports, qui impose également sa conservation pendant deux ans. À l’international, elle prend la forme de la lettre de voiture CMR (convention relative au contrat de transport international de marchandises par route), établie en trois exemplaires originaux.

Cette lettre de voiture peut désormais exister sous forme électronique : le protocole additionnel à la convention CMR concernant la lettre de voiture électronique, signé à Genève le 20 février 2008, lui donne la même valeur juridique que son équivalent papier. En France, ce protocole a été publié par le décret n° 2017-1 du 3 janvier 2017. Une e-CMR correctement émise et signée électroniquement n’est donc pas une simple copie numérique sans valeur : c’est un document opposable, à condition que son mode de génération et de signature respecte les exigences du protocole. Pour le détail des mentions obligatoires et la comparaison complète avec la lettre de voiture papier, consultez notre guide complet sur la lettre de voiture CMR.

Le second texte à connaître est plus récent et concerne les autorités de contrôle, pas seulement les parties au contrat : le règlement (UE) 2020/1056, dit eFTI (informations électroniques concernant le transport de marchandises, electronic freight transport information), oblige les autorités de contrôle des États membres à accepter les documents réglementaires présentés par voie électronique sur une plateforme certifiée. Entré en vigueur le 20 août 2020, il est applicable depuis le 21 août 2024. Concrètement, un contrôleur routier qui arrête un véhicule ne peut plus exiger, pour les documents couverts par le règlement, une version imprimée si le transporteur présente une plateforme certifiée conforme.

Pour un chargeur, ces deux textes se traduisent en une exigence simple à vérifier : le transporteur doit pouvoir démontrer, et pas seulement affirmer, que sa lettre de voiture électronique est opposable en cas de litige et acceptée en cas de contrôle. Une simple photocopie scannée d’un document papier signé à la main ne répond à aucun des deux régimes ; un vrai flux e-CMR répond aux deux.

Preuve de livraison électronique et traçabilité de bout en bout

La preuve de livraison électronique, ou POD (proof of delivery, preuve de livraison), est le document qui clôt juridiquement une expédition : elle atteste que la marchandise a été remise, en l’état, au bon destinataire, à une date et une heure données. Un POD exploitable comporte au minimum trois éléments : un horodatage fiable (pas une date saisie manuellement après coup), une géolocalisation du point de remise, et une preuve de réception (signature électronique du destinataire, ou à défaut photographie datée du colis livré et du lieu).

Ce triptyque n’est pas un confort, c’est une nécessité contractuelle. En cas d’avarie ou de perte partielle, l’article L133-3 du code de commerce impose au destinataire de notifier des réserves motivées dans les trois jours suivant la réception, jours fériés non compris. Un POD daté avec précision est ce qui permet de faire courir ce délai sans ambiguïté ; un POD approximatif (une simple case cochée « livré » sans horodatage vérifiable) rend ce délai contestable des deux côtés, chargeur comme transporteur.

La traçabilité de bout en bout va au-delà du seul instant de livraison : elle relie chaque événement du trajet (enlèvement, passage en plateforme le cas échéant, mise en livraison, remise) dans un historique consultable après coup, pas seulement en temps réel. C’est cet historique complet, et non le seul statut final, qui permet d’instruire un litige rapidement : savoir à quelle heure précise un incident de circulation a retardé le passage en plateforme évite de discuter une réclamation sur la seule base d’un « retard constaté ».

Un chargeur qui négocie un contrat de transport gagne à faire préciser, noir sur blanc, le format du POD fourni (signature numérique, photo, les deux), le délai de mise à disposition après livraison (immédiat via une interface, ou sur demande sous plusieurs jours) et la durée de conservation de la preuve, qui doit au minimum couvrir le délai de prescription applicable au litige.

Cybersécurité de la chaîne logistique : les principes à vérifier

Chaque intégration entre le système d’information du chargeur et celui du transporteur ouvre un canal d’échange de données qui peut devenir une faille si elle est mal sécurisée : identifiants de connexion, historique de commandes, coordonnées de clients finaux. La cybersécurité de la chaîne logistique n’est pas un sujet réservé aux grands groupes : un incident chez un prestataire de transport de taille modeste peut exposer les données de dizaines de clients chargeurs qui partagent le même système.

Le cadre réglementaire européen s’étend sur ce terrain : la directive (UE) 2022/2555, dite NIS2 (network and information security, sécurité des réseaux et de l’information), classe le transport routier parmi les secteurs hautement critiques de son annexe et impose une gestion des risques cyber et une notification des incidents aux entités qui en relèvent. Sa transposition en droit français est toujours en cours au moment de la rédaction de cet article, et le périmètre exact des obligations applicables aux prestataires de transport routier reste à préciser texte par texte : un chargeur ne doit donc pas présumer que son transporteur est automatiquement couvert, mais peut légitimement lui demander où il en est de sa mise en conformité.

Indépendamment du calendrier réglementaire, trois exigences contractuelles restent du bon sens : le chiffrement des données en transit sur toute interface EDI ou API, une politique d’accès nominative (chaque utilisateur du portail transporteur identifié individuellement, pas un compte partagé), et une clause de notification d’incident qui oblige le transporteur à informer le chargeur sous un délai fixé si une donnée le concernant a été compromise. Ce sujet mérite un traitement dédié et approfondi : il fera l’objet d’un article spécifique du présent dossier.

Intelligence artificielle appliquée au transport : où en est-on aujourd’hui ?

L’intelligence artificielle s’invite progressivement dans le système d’information transport, sur trois usages aujourd’hui les plus répandus : l’optimisation des tournées (calcul d’itinéraires et de chargements sous contraintes multiples), la prévision de l’heure d’arrivée en tenant compte du trafic historique et en temps réel, et la détection d’anomalies dans les flux de données (une facture qui s’écarte anormalement du tarif habituel, un retard récurrent sur un même trajet).

Ces usages restent des outils d’aide à la décision, pas des substituts au contrôle humain, et leur pertinence dépend directement de la qualité des données qui les alimentent : un algorithme de prévision d’ETA appliqué sur des positions déclaratives peu fiables produit une estimation peu fiable, quelle que soit la sophistication du modèle. Autrement dit, l’intelligence artificielle n’est pas un raccourci pour éviter de résoudre en amont les sujets de visibilité et d’échange de données traités plus haut dans ce guide : elle en est plutôt la conséquence, une fois ces briques posées. Le sujet mérite lui aussi un traitement dédié, qui fera l’objet d’un article séparé du présent dossier.

Ce qu’il faut exiger contractuellement, pas ce qu’un éditeur promet

La différence entre une brochure commerciale et un engagement contractuel tient en une règle simple : ce qui n’est pas écrit dans le contrat n’existe pas en cas de litige. Un chargeur gagne à faire figurer, dans le contrat-cadre ou ses annexes, un véritable niveau de service data, distinct du niveau de service transport classique (délai, taux de casse).

Ce niveau de service data doit préciser, au minimum : les formats d’échange garantis (EDI, API, ou les deux) et leur documentation technique accessible sans négociation préalable ; la fréquence de mise à jour des statuts et de la géolocalisation ; le délai de mise à disposition de la preuve de livraison après l’événement ; la durée de conservation des données et des documents, alignée sur les délais de prescription applicables (un an pour l’action en responsabilité contre le transporteur, deux ans pour la lettre de voiture elle-même) ; et une clause de réversibilité, qui garantit au chargeur de pouvoir récupérer l’intégralité de son historique de données en cas de changement de prestataire, dans un format exploitable et sans délai excessif.

Cette dernière clause est souvent absente des contrats de transport, alors qu’elle protège directement le chargeur : sans réversibilité contractualisée, changer de transporteur signifie perdre l’historique de performance accumulé, et repartir de zéro pour évaluer un nouveau prestataire. Un fournisseur sérieux n’a aucune raison de refuser cette clause ; un fournisseur qui la refuse révèle, souvent, la fragilité réelle de son propre système d’information.

En synthèse, l’exigence numérique d’un chargeur envers son transporteur ne se limite pas à demander « un TMS » ou « un portail de suivi », formulations trop vagues pour être vérifiées. Elle se décline en critères précis : donnée automatique plutôt que déclarative, format d’échange documenté plutôt que fichier tableur, preuve horodatée et conservée plutôt qu’attestation orale, et clause de réversibilité plutôt que dépendance de fait. C’est cette exigence, posée dès l’appel d’offres, qui distingue un système d’information transport réellement au service du chargeur d’une simple vitrine numérique.

Innovia Transport et la donnée qui accompagne chaque expédition

Depuis 1998, Innovia Transport organise pour ses clients professionnels des expéditions qui vont de la course urgente en véhicule utilitaire à la livraison en semi-remorque, au départ de ses agences de Lyon et de Toulouse, sur l’ensemble du territoire français.

Chaque expédition confiée à Innovia est accompagnée d’un document de transport et d’une preuve de livraison, dont le format d’échange peut être précisé avec vous au moment de la mise en place de votre compte : c’est un point à aborder dès la prise de contact, pour l’aligner sur les exigences propres à votre système d’information.

Si votre organisation prévoit un appel d’offres transport intégrant un volet numérique, ou si vous souhaitez simplement faire le point sur les formats d’échange disponibles pour vos flux actuels, contactez Innovia Transport pour en discuter avec un interlocuteur dédié.

Questions fréquentes sur le système d’information transport