Dans le transport et la commission de transport, le travail est souvent dévoré non par l’acheminement lui-même mais par tout ce qui l’entoure. Une commande arrive par e-mail, la confirmation revient en PDF, la lettre de voiture CMR voyage avec le conducteur, et le tarif se trouve dans le tableur d’une seule personne. Pour un directeur du transport ou des règlements, cela revient à une chose : l’information sur une commande se disperse entre des dizaines d’endroits, et aucun n’est la source de vérité. Une plateforme de logiciel TMS bien conçue rassemble ce flux, de la prise de commande jusqu’à la facturation.
D’après notre expérience, le difficile n’est pas de dessiner un écran de « liste de commandes » mais de boucler toute la chaîne des documents et de l’argent pour qu’elle se réconcilie - ce qui compte ici est la cohérence des données, l’auditabilité et les intégrations, pas une interface tape-à-l’œil. Nous ne prétendons pas posséder une boîte qui conviendrait à toute entreprise de commission de transport ; nous pourvoyons plutôt le projet avec des personnes qui conçoivent et maintiennent de tels systèmes, en renfort d’équipe ou en équipe dédiée.
Pourquoi le fret se noie-t-il dans la paperasse et l’e-mail ?
Le papier et une boîte mail font très bien l’affaire tant que le volume est faible. Les ennuis commencent avec l’échelle : chaque changement d’itinéraire, correction de tarif et document manquant appelle un copier-coller manuel, et le règlement se fait « de mémoire ». Nous voyons généralement quelques sources de friction récurrentes :
- des commandes sur de nombreux canaux à la fois (e-mail, téléphone, portail client, EDI), sans registre unique,
- des documents épars en PDF et en scans, détachés d’un envoi précis,
- des tarifs dans des tableurs qui ne suivent jamais les avenants ni les surcharges carburant,
- un règlement en fin de mois, quand la moitié des détails sont déjà oubliés.
Comment organisons-nous le registre des commandes et des envois ?
La base d’un TMS est un registre cohérent où la commande, l’envoi et les documents forment un seul enregistrement relié, et non trois mondes séparés. Nous le concevons autour du flux de travail réel du commissionnaire : la couche fait passer une commande par ses statuts, de la prise en charge à l’affectation du transporteur et du véhicule, jusqu’à la livraison et la clôture, et chaque changement laisse une trace. Nous décrivons chaque envoi avec les attributs utilisés dans le règlement et le reporting (dimensions, poids, nombre de palettes, Incoterms, itinéraire, transporteur), et ces mêmes données pilotent ensuite la tarification et la facture.
Qu’est-ce que l’e-CMR et comment numérisons-nous les documents de transport ?
La lettre de voiture CMR classique est du papier avec des signatures, facile à perdre et difficile à rechercher. L’e-CMR en est l’équivalent électronique, fondé sur le protocole additionnel à la convention CMR, avec une signature numérique et un horodatage au lieu d’un stylo. Pour le règlement, cela change les règles : le document est disponible juste après la livraison, pas une semaine plus tard quand le classeur du conducteur revient.
Sur les projets documentaires, nous branchons le flux pour que chaque document soit rattaché à un envoi et à un statut précis. Nous numérisons non seulement l’e-CMR lui-même mais toute la famille des papiers de transport : preuve de livraison (POD), commandes, documents d’entrepôt, listes de colisage. Quand un client a encore besoin de papier, nous maintenons une impression cohérente avec la version numérique.
Comment préparer les données pour le dédouanement ?
Sur les mouvements internationaux, le dédouanement exige des données complètes et cohérentes, sinon l’envoi s’arrête à la frontière. Un TMS peut préparer ces données une seule fois, à la source, et les transmettre au lieu d’imposer une ressaisie dans un système de plus.
Nous ajoutons au registre les champs nécessaires aux déclarations : codes tarifaires douaniers (SH/NC), pays d’origine, valeur des marchandises, poids, données de l’expéditeur et du destinataire. Comme nous ne prétendons pas être un agent en douane, nous concevons un export et une intégration propres avec les systèmes douaniers ou un courtier : les données partent dans un format convenu, prêtes à être déclarées.
Comment fonctionne le moteur de tarifs et de barèmes ?
Un tarif de fret est rarement un chiffre unique. C’est généralement un barème qui dépend de l’axe, du poids, du volume, des zones, des surcharges carburant et d’avenants individuels avec le client, et quand tout cela vit dans un tableur, chaque changement est un risque. C’est pourquoi le cœur d’un TMS est un moteur tarifaire qui calcule le prix à partir de règles, pas de la mémoire d’un commercial.
Nous assemblons un tel moteur à partir de quelques éléments qui doivent jouer ensemble :
- des grilles et barèmes par client, axe, zone et type de marchandise,
- des règles de surcharge (carburant, douane, ADR, réservation) appliquées automatiquement,
- des grilles versionnées avec des dates de validité, pour qu’un ancien tarif n’atterrisse jamais sur une nouvelle commande,
- la simulation et la comparaison de variantes avant la confirmation d’une commande.
La même logique tarifie une commande à l’entrée et la règle à la sortie, pour que le devis et la facture concordent enfin.
Comment automatisons-nous la facturation et le règlement ?
Le règlement met au jour tous les manques antérieurs. Si les données de commande, les documents et les tarifs se trouvent au même endroit, la facture et le règlement du transporteur s’écrivent presque d’eux-mêmes. Nous construisons une couche de règlement qui compare ce qui a été convenu avec ce qui a été réellement fait et attrape les écarts avant qu’ils n’atteignent la comptabilité.
Cette couche fait plusieurs choses à la fois : elle calcule le montant facturé au client et le coût transporteur, collecte les surcharges et les corrections, vérifie que le jeu complet de documents (POD, e-CMR) est en place, et prépare les données pour le système financier et comptable. Le règlement des transporteurs suit la même logique, si bien que la marge est visible sur chaque commande, et pas seulement dans le rapport mensuel.
Comment relier un TMS à l’EDI et à l’ERP ?
Un TMS ne vit pas seul. D’un côté, il y a les clients et leurs commandes en EDI ; de l’autre, l’ERP, la comptabilité, la télématique et les portails des transporteurs. La valeur du système croît là où il cesse d’être une île.
Nous relions un TMS à son environnement pour que les données circulent sans ressaisie manuelle :
- l’EDI (par exemple EDIFACT, messages IFTMIN/IFTSTA) pour échanger commandes et statuts avec les clients,
- l’ERP et le système comptable pour les factures, les coûts et les fiches partenaires,
- la télématique et le GPS pour les statuts et les heures de livraison en route,
- des API et des webhooks vers les portails clients et les bourses de fret.
Nous traitons chaque intégration comme un contrat : un format convenu, un traitement des erreurs, des retries et du monitoring, pour qu’un mauvais message ne bloque pas tout le flux.
Quelles compétences apportons-nous à un projet TMS ?
Sur ce sujet, nous ne vendons pas un déploiement sur étagère ; nous fournissons les personnes capables de concevoir, construire et maintenir un tel système. Nous façonnons l’équipe autour du périmètre précis, pas au cas où, et nous pourvoyons généralement les rôles qui font réellement avancer un projet TMS :
- un analyste / architecte qui comprend les processus de commission de transport et les traduit en modèle de données,
- un développeur backend qui construit le moteur tarifaire, le règlement et la couche d’intégration,
- un développeur frontend responsable d’un panneau commissionnaire et règlement lisible,
- un spécialiste intégration / EDI qui relie le TMS à l’ERP, à la douane et à la télématique,
- en option, un spécialiste DevOps qui met en place les environnements, le pipeline CI/CD et le monitoring.
Nous vérifions les compétences avant le démarrage et branchons l’équipe sur le rythme du client.
Comment procédons-nous chez RITS ?
Nous le faisons en partenaire nearshore depuis la Pologne, avec une expérience des projets à forte complexité de données et d’intégration. Nous ne prétendons pas avoir dans un tiroir un déploiement de TMS pour un commissionnaire donné ; nous livrons plutôt les compétences qui mènent un tel projet à terme, de l’analyse à la maintenance.
Nous comprenons d’abord le processus, et seulement ensuite nous choisissons la technologie et l’équipe. Nous travaillons dans un fuseau horaire proche, donc l’équipe arrive sans longue montée en charge et prend progressivement la responsabilité du flux des commandes, des documents et des règlements. Le plus souvent, nous opérons en logiciel sur mesure construit par notre équipe, ou en renfort d’équipe quand des compétences manquantes doivent être complétées vite.
Par où commencer la construction d’un TMS ?
Partez du tronçon le plus douloureux, généralement le chemin de la commande à la facture. Il révèle quelles données manquent, quels documents doivent être numérisés et où le barème s’écarte du règlement. Les autres modules viennent ensuite s’empiler sur la même fondation. Nous avons traité les différences entre modèles de collaboration dans notre article sur les modèles de collaboration IT.
Vous mettez de l’ordre dans le fret, les documents et les règlements ? Parlons-en - nous ajusterons une équipe et une architecture à votre TMS.