TMS : ce qu’est un Transportation Management System et comment il fonctionne

En bref

TMS signifie Transportation Management System. Il n’existe toutefois aucune liste universelle de fonctions qu’un logiciel doit posséder pour pouvoir s’appeler TMS. Sur le marché, ce terme désigne des produits très différents : des outils relativement simples de planification des trajets aux plateformes d’entreprise qui gèrent l’approvisionnement auprès des transporteurs, les appels d’offres, les tarifs, les réseaux internationaux, l’audit des coûts, le suivi, les documents et les intégrations avec les ERP et systèmes d’entrepôt.

Pour une PME, la question n’est pas « ai-je besoin d’un TMS ? », mais quels processus dois-je contrôler et avec quel niveau de complexité ? Une entreprise de cinq camions qui reçoit les commandes par e-mail n’a pas les mêmes besoins qu’un opérateur logistique qui achète du transport à des centaines de transporteurs ou coordonne plusieurs hubs européens.

Ce que signifie réellement TMS

En pratique, un TMS est un système d’information dédié à la gestion du transport. Il peut accompagner une ou plusieurs étapes :

demande → commande → planification → attribution → exécution → suivi → documents → coûts → clôture → analyse

La profondeur varie beaucoup d’un produit à l’autre. Un système peut se limiter à planifier ses propres transports ; un autre peut choisir automatiquement parmi plusieurs transporteurs selon le tarif et le service ; un autre encore peut gérer des trajets multimodaux, des rendez-vous, des SLA, des factures et des rapprochements.

C’est pourquoi deux offres appelées « TMS » peuvent avoir des prix, des délais de mise en œuvre et des utilisateurs visés totalement différents.

Le cycle opérationnel qu’un TMS peut gérer

1. Acquisition de la demande

Les commandes peuvent arriver par saisie manuelle, fichiers, API, EDI, ERP, portails clients ou autres systèmes. La première tâche consiste à transformer des demandes hétérogènes en données utilisables.

2. Planification

Le système combine destinations, créneaux horaires, capacité, contraintes, disponibilité des véhicules et des conducteurs ou disponibilité des transporteurs. Les systèmes les plus sophistiqués peuvent intégrer des moteurs d’optimisation ; dans les plus simples, la planification reste surtout visuelle et manuelle.

3. Attribution

Le trajet est confié à un véhicule/conducteur interne ou à un transporteur externe. Lorsque des prestations de transport sont achetées, des grilles tarifaires, appels d’offres, classements de fournisseurs et règles d’approvisionnement peuvent entrer en jeu.

4. Exécution

Le bureau, le conducteur et les partenaires doivent partager les statuts et les changements : prise en charge, arrivée, chargement, en route, livré, anomalie, etc.

5. Documents et preuve du service

Le système peut relier commande, documents de transport, POD et pièces jointes. La présence d’un document dans le TMS ne signifie toutefois pas que ce document est automatiquement correct sur le plan juridique, fiscal ou technique.

6. Coûts et contrôle

Les TMS les plus évolués comparent coût prévu et coût réel, tarifs, suppléments, péages, services accessoires et factures reçues des transporteurs.

7. Analyse

Volumes, ponctualité, coûts par trajet, utilisation des ressources, anomalies, performance des transporteurs et autres KPI peuvent devenir des données de gestion plutôt que des reconstitutions manuelles en fin de mois.

Les modules les plus courants

Un TMS peut inclure :

• gestion des commandes ;
• référentiels clients, sites et transporteurs ;
• planification des trajets ;
• attribution des véhicules/conducteurs ;
• approvisionnement et appels d’offres auprès des transporteurs ;
• gestion des tarifs ;
• suivi ou intégration avec un suivi externe ;
• gestion des rendez-vous ;
• documents et POD ;
• contrôle des coûts et audit de fret ;
• facturation ou intégration comptable ;
• tableaux de bord et KPI ;
• portail clients/fournisseurs ;
• API, EDI et intégrations ERP/WMS ;
• gestion des exceptions ;
• fonctions d’optimisation.

La bonne question pendant une démonstration n’est pas « avez-vous cette fonction ? », mais comment fonctionne-t-elle dans le processus concret de l’entreprise et quelles données exige-t-elle ?

TMS, logiciel de gestion, FMS et télématique ne sont pas des synonymes

Logiciel de gestion du transport

C’est un terme général. Il peut désigner un logiciel centré sur l’organisation administrative et opérationnelle d’une petite entreprise : clients, commandes, conducteurs, camions, plan quotidien et statuts.

TMS

Il désigne généralement une plateforme plus approfondie pour la planification et le contrôle du transport et, dans les contextes d’entreprise, pour la gestion des réseaux, transporteurs, tarifs et intégrations.

FMS / Fleet Management System

Il est davantage orienté vers la flotte : véhicules, maintenance, consommation, échéances, utilisation, et éventuellement conducteurs et coûts des véhicules.

Télématique

Elle recueille des informations provenant du véhicule ou de dispositifs : position, kilomètres, données CAN lorsqu’elles sont disponibles, diagnostic, événements de conduite et autres signaux. Un TMS peut recevoir ces données, mais n’est pas par définition un dispositif télématique.

ERP

Il gère des processus d’entreprise plus larges : comptabilité, achats, ventes, administration, entrepôt et contrôle de gestion. Un TMS peut être un module d’ERP ou un système distinct intégré à celui-ci.

Pour une PME, il est normal d’utiliser plusieurs outils. Le problème commence lorsque personne ne sait quel système est la source officielle de chaque donnée.

Quand un TMS complexe est utile

La complexité tend à être justifiée lorsque certaines variables augmentent :

• des centaines ou milliers de commandes ;
• de nombreux sites de chargement/déchargement ;
• du transport acheté à de nombreux transporteurs ;
• des grilles tarifaires et suppléments complexes ;
• un réseau national/international ;
• plusieurs modes de transport ;
• des SLA et KPI contractuels ;
• un fort besoin d’intégration avec ERP/WMS ;
• des processus d’appel d’offres et d’approvisionnement ;
• la nécessité d’un audit systématique des coûts.

Dans ces cas, la plateforme ne sert pas seulement à « voir le plan » : elle devient une partie de l’architecture d’information de l’entreprise.

Quand il peut être surdimensionné

Une microentreprise de cinq ou dix camions peut avoir un problème très concret : commandes dispersées, modifications dans WhatsApp, planification dans Excel et appels incessants aux conducteurs. Pour le résoudre, il n’est pas forcément utile d’introduire :

• un projet ERP de six mois ;
• des configurations tarifaires complexes ;
• un moteur d’appels d’offres ;
• un entrepôt de données ;
• des dizaines de rôles et workflows ;
• du conseil spécialisé pour chaque modification.

Un logiciel trop grand peut déplacer le problème : de l’absence de structure vers la difficulté à utiliser cette structure.

Le critère devrait être la complexité minimale suffisante : bien couvrir le processus réel d’aujourd’hui et laisser de la place pour grandir, sans acheter des années de fonctions qui ne seront pas utilisées.

Données et intégrations : la partie qui coûte vraiment

Le logiciel n’est qu’un composant. Une part importante du travail d’un projet TMS concerne les données.

Avant la mise en œuvre, il est utile de définir :

Référentiels. Qui nettoie les clients, adresses, véhicules, conducteurs, transporteurs et codifications en double ?

Source de la donnée. L’adresse client naît-elle dans le CRM, l’ERP ou le TMS ? Qui peut la modifier ?

Identifiants. La commande, le trajet et le document ont-ils des codes cohérents entre les systèmes ?

Importations. Les fichiers existants ont-ils des colonnes stables ou chaque client utilise-t-il un format différent ?

API/EDI. Quels flux sont réellement nécessaires ? En temps réel ou par lots ?

Erreurs. Que se passe-t-il si une intégration ne reçoit pas une commande ou la reçoit deux fois ?

Historique. Quel passé faut-il migrer ? Tout, seulement les référentiels, ou les derniers mois ?

Propriété. L’entreprise peut-elle exporter ses propres données dans un format réutilisable ?

Une mauvaise qualité des données n’est pas résolue automatiquement par un TMS : elle est simplement transférée dans un système plus coûteux.

Documents numériques et eFTI : pourquoi l’interopérabilité compte de plus en plus

Le règlement (UE) 2020/1056, relatif aux informations électroniques sur le transport de marchandises (eFTI), crée un cadre européen permettant aux opérateurs économiques de mettre certaines informations réglementaires à la disposition des autorités compétentes sous forme électronique au moyen de plateformes et services conformes au cadre eFTI.

La Commission européenne indique le 9 juillet 2027 comme date à partir de laquelle le cadre eFTI sera pleinement applicable et les autorités des États membres devront accepter les informations partagées électroniquement par les opérateurs via des plateformes eFTI certifiées. À partir de 2026, les plateformes et fournisseurs peuvent se préparer à l’exploitation selon la trajectoire prévue par la Commission.

Cela ne signifie pas qu’à partir de 2027 chaque petite entreprise doit acheter un « TMS eFTI ». Cela signifie en revanche que, lorsqu’on choisit aujourd’hui un système destiné à durer des années, il devient pertinent de demander au fournisseur :

• comment il exporte les données ;
• s’il dispose d’API ;
• comment il gère les standards et l’interopérabilité ;
• quels sont ses plans concernant l’évolution de l’eFTI ;
• si les éventuelles fonctions déclarées « eFTI compliant/certified » sont réellement couvertes par la certification requise, lorsqu’elle s’applique.

La numérisation européenne va vers des données structurées et échangeables. Une archive fermée dont il est difficile de récupérer ses propres données représente donc un risque plus important qu’auparavant.

Comment évaluer un TMS sans se laisser guider par la démonstration

Une démonstration montre presque toujours le parcours idéal. L’évaluation devrait plutôt utiliser des cas réels de l’entreprise.

Demandez au fournisseur de simuler au moins :

1. une commande standard ;
2. un enlèvement avec deux livraisons ;
3. une modification après l’attribution ;
4. un conducteur indisponible au dernier moment ;
5. une commande importée depuis Excel ;
6. un document manquant ;
7. une livraison en retard ;
8. un trajet annulé ;
9. une erreur d’intégration ;
10. l’export complet d’une période d’activité.

Puis mesurez :

• le nombre d’étapes nécessaires ;
• la quantité d’informations ressaisies ;
• qui doit intervenir ;
• ce que voit le conducteur ;
• ce qui reste dans l’historique ;
• comment les erreurs sont récupérées.

Checklist

• Quel processus voulons-nous améliorer en premier ?
• Le produit est-il conçu pour une flotte propre, un chargeur ou un commissionnaire de transport ?
• Gère-t-il vraiment notre type de commande ?
• Exige-t-il des modules que nous n’utiliserons pas ?
• Le plan est-il compréhensible pour les opérateurs ?
• Les conducteurs et les véhicules sont-ils reliés aux commandes ?
• Existe-t-il un historique des modifications ?
• Les données peuvent-elles être exportées dans des formats réutilisables ?
• Les API sont-elles incluses ou payantes ?
• Quelles intégrations sont standard et lesquelles sont des projets ?
• Quels coûts existent au-delà de la licence ?
• Combien de temps prend la mise en œuvre ?
• Comment sont gérés sauvegardes, sécurité et continuité ?
• Quelles fonctions sont réellement disponibles aujourd’hui et lesquelles sont sur la feuille de route ?
• Comment l’évolution de l’eFTI est-elle abordée ?