Exigences d’un système de gestion du transport : guide 2026
Une liste de contrôle pratique des exigences d’un système de gestion du transport pour les transporteurs, couvrant la planification, le POD, les intégrations, les KPI et les questions RFP.
Le tableau d’exploitation est saturé, le créneau au port bouge, et la finance demande pourquoi les courses terminées de la semaine dernière n’ont toujours pas été facturées. Un conducteur a envoyé un bon de livraison via une application de messagerie, un autre POD est resté dans une cabine, et personne ne peut confirmer si l’horloge de temps libre d’un conteneur a expiré. Voilà la réalité opérationnelle derrière les exigences d’un système de gestion du transport. Une longue liste de fonctionnalités ne réglera pas le problème. Le bon système doit relier la planification, l’exécution, le statut des conteneurs, la preuve de livraison, la facturation, la conformité et les données de performance dans un flux de travail utilisable.
Le marché évolue dans cette direction. Un benchmark évalue le marché mondial des systèmes de gestion du transport à USD 18.50 billion en 2025, avec une projection à USD 37.04 billion d’ici 2030, soit un CAGR de 14.9% de 2025 à 2030 (market benchmark for transportation management software). Pour les transporteurs de taille intermédiaire et les opérateurs conteneurs, cette croissance compte moins comme titre de marché que comme signal d’achat. Les logiciels TMS deviennent une infrastructure opérationnelle, et non plus un simple tableur de dispatch plus joli.
Table des matières
Pourquoi la plupart des listes d’exigences TMS passent à côté du vrai problème d’achat
L’erreur de cadrage la plus courante consiste à copier une liste de contrôle d’entreprise dans un exercice d’achat pour le milieu de marché. La liste inclut l’optimisation multimodale, l’achat de transporteurs, des tableaux de bord de tour de contrôle, l’analyse prédictive et toutes les intégrations jamais développées par l’éditeur. Pendant ce temps, les exploitants ressaisissent encore les courses depuis les e-mails, les conducteurs n’ont pas les consignes d’accès, et la finance attend les POD signés.
Une exigence n’a de valeur que si elle modifie une décision ou supprime un goulot d’étranglement. La bonne question n’est pas « Le système offre-t-il de la visibilité ? » C’est « Le dispatcher peut-il identifier chaque course à risque de rater un créneau terminal, voir qui est responsable de la prochaine action, et alerter le client avant que l’échec ne devienne une réclamation ? »
Commencer par des preuves opérationnelles
Exécutez trois diagnostics avant de parler aux fournisseurs.
Auditez les 30 derniers jours d’exceptions. Passez en revue les enlèvements en retard, les fenêtres de livraison manquées, les POD manquants, les litiges de facturation, les doublons de courses, les erreurs de disponibilité véhicule, l’exposition aux temps d’attente et les mises à jour manuelles aux clients. Ne vous fiez pas aux résumés de direction. Comparez le tableau de dispatch, les messages des conducteurs, les documents de livraison et les dossiers de finance.
Associez une conséquence métier à chaque écart. Un POD manquant peut retarder la facturation, créer un litige ou obliger le personnel à relancer un destinataire. Un créneau terminal manqué peut générer du temps d’attente, du travail de replanification et de l’insatisfaction client. Inutile d’inventer une estimation d’économie. Il faut en revanche identifier quelle défaillance consomme du cash, de la capacité ou de l’attention managériale.
Classez les exigences selon leur impact sur le cycle de trésorerie. Placez la capture du POD, la validation de fin de course, la préparation à la facturation et les contrôles de règlement en haut de la liste si les documents tardifs bloquent les encaissements. Placez l’optimisation avancée plus bas si les planificateurs peuvent déjà construire des tournées viables, mais ne parviennent pas à clôturer proprement les courses terminées.
Règle pratique : Une exigence ne doit figurer dans le RFP que si l’acheteur peut nommer la décision opérationnelle qu’elle améliore, l’utilisateur qui en a besoin, et la preuve qui démontrera qu’elle a fonctionné.
Les orientations sectorielles fournissent encore une base utile. Les critères TMS de Gartner couvrent la planification, le sourcing et l’achat de fret, la visibilité, l’exécution et l’analyse, y compris la saisie des commandes, la consolidation, le choix du mode et de l’itinéraire, la sélection des transporteurs, les communications et la mesure des KPI (industry coverage of Gartner's TMS criteria). Utilisez ces catégories comme plancher, puis ajoutez les contrôles propres aux transporteurs et aux conteneurs que les modèles génériques oublient souvent.
Les exigences ne sont pas une liste de souhaits. Ce sont des décisions sur ce que l’exploitation doit pouvoir faire de façon fiable un jour de forte activité.
Modules fonctionnels essentiels qu’un TMS pour le milieu de marché doit couvrir
Un dispatcher vit un TMS comme une succession de transferts. Une commande arrive, l’équipe la valide, affecte un véhicule, briefe le conducteur, suit l’avancement, collecte la preuve de livraison, puis libère la course pour la facturation. Si une étape reste en dehors du système, le personnel recrée la même information ailleurs.
La séquence opérationnelle
La prise de commande doit accepter des données structurées depuis les e-mails, les portails clients, les API ou la saisie manuelle sans créer d’enregistrements dupliqués. Le système doit conserver les références, adresses, exigences, tarifs, fenêtres de livraison et pièces jointes.
La planification a besoin d’une grille visuelle des courses avec filtrage par véhicule, conducteur, client, statut, terminal et exception. Un planificateur doit pouvoir reprogrammer, réaffecter et modifier en masse les courses sans ouvrir chaque fiche individuellement. Si la démonstration ne fonctionne qu’avec une course propre, demandez au fournisseur de montrer un véhicule en retard, un créneau annulé et une modification qui touche plusieurs courses.
Le briefing conducteur doit placer les consignes pratiques là où le conducteur peut les utiliser. Cela inclut les informations d’itinéraire, les références de collecte et de livraison, les restrictions d’accès, les coordonnées, les exigences de timing et, le cas échéant, les informations de conteneur ou de scellé. Une application conducteur qui ne fonctionne pas sans connexion fiable représente un risque de production ; testez donc le mode hors ligne au lieu d’accepter une promesse verbale.
Le suivi d’exécution doit montrer les jalons prévus par rapport aux jalons réels, le statut actuel, l’ETA, la raison du retard et l’utilisateur responsable. Le suivi n’a aucune utilité s’il affiche une carte sans file d’exceptions.
La capture du POD se situe directement sur le chemin de conversion en cash. Le conducteur doit soumettre un document lisible ou un POD numérique depuis le flux mobile, avec horodatage et pièces jointes associés à la bonne course. Définissez en interne une norme d’exploitation pour la rapidité de soumission, puis mesurez-la. L’acheteur ne doit pas se contenter de « les conducteurs peuvent téléverser des documents » comme réponse complète.
La facturation doit identifier les courses terminées, appuyées par un POD, et signaler les références manquantes, les quantités incohérentes, les écarts de tarif ou les exceptions non résolues avant qu’une facture n’arrive au client. Le règlement doit rapprocher les charges prévues et réelles, prendre en charge les validations et conserver une piste d’audit.
| Module |
Comportement minimal acceptable |
Mode de défaillance si absent |
| Prise de commande |
Capturer les données de course structurées et les pièces jointes sans saisie en double |
Ressaisie, références manquantes, doublons |
| Tableau de planification |
Filtrer, réaffecter, reprogrammer et modifier en masse les courses en cours |
Les planificateurs travaillent sur des tableurs obsolètes |
| Briefing conducteur |
Transmettre itinéraire, accès, timing et références sur mobile |
Consignes manquées et appels évitables |
| Exécution |
Enregistrer jalons, ETA, retards et responsables |
Les problèmes n’apparaissent qu’après une réclamation |
| Capture du POD |
Associer les images ou enregistrements numériques à la bonne course terminée |
La facturation attend pendant qu’on recherche les documents |
| Facturation |
Libérer les courses appuyées et signaler les exceptions |
Factures erronées et litiges débiteurs |
| Règlement |
Comparer les charges prévues aux coûts réels |
Érosion de marge et rapprochement manuel |
Utilisez cet aperçu des modules d’un système de gestion du transport pour vérifier si la terminologie d’un fournisseur correspond à de vrais processus. La distinction importante est entre un module qui existe dans le menu et un flux de travail qui survit à une journée d’exploitation difficile.
Exigences spécifiques aux conteneurs au-delà du transport généraliste
Une liste de contrôle pour lots palettisés considère un mouvement comme un point d’origine, une destination, un véhicule et un événement de livraison. Les opérateurs conteneurs gèrent un objet opérationnel différent. La course peut dépendre d’une référence de réservation, d’un ordre de mise à disposition, d’un rendez-vous terminal, d’un numéro de conteneur, d’un code ISO, du statut portuaire et d’une échéance de temps libre.
Un TMS générique enregistre souvent le port comme un arrêt de plus. Ce n’est pas suffisant. Une visite terminal est un événement contraint par un créneau, et les conséquences d’un retard peuvent continuer après que le camion a quitté la zone. Le système doit distinguer un ordre de transport d’un ordre de mise à disposition, conserver la référence de réservation et afficher le conteneur exact associé au mouvement.
Modèle de données minimal pour les conteneurs
Au niveau de la course, exigez les champs suivants :
- Numéro de réservation, afin que le mouvement puisse être rapproché du client ou de l’instruction d’expédition.
- Numéro de conteneur et code ISO du conteneur, afin que l’unité physique et son type restent sans ambiguïté.
- Terminal ou quai, y compris le lieu pertinent d’enlèvement ou de livraison.
- Expiration du temps libre, avec un statut visible et un responsable pour la prochaine action.
- Type de mise à disposition, afin que le dispatch comprenne si le mouvement dépend d’une release, d’une réservation, d’un interchange ou d’une autre autorisation.
- Détails du créneau, y compris l’heure prévue, la référence de confirmation et l’historique des modifications.
- ETA en direct vers le terminal, afin que l’équipe puisse intervenir avant qu’un créneau ne soit manqué.
Le suivi du demurrage et de la détention ne doit pas être enfoui dans un champ de notes. Le système doit afficher l’horloge, la relier au conteneur et à la course, et générer une exception lorsque l’échéance approche ou que les données opérationnelles sont incomplètes.
| Zone d’exigence |
Hypothèse de transport générique |
Besoins spécifiques au conteneur |
| Identité de la course |
Commande client et référence de livraison |
Références de réservation, de release, de conteneur et de transport |
| Mouvement du véhicule |
Jalons d’enlèvement et de livraison |
Créneau terminal, événement de gate, interchange et statut de quai |
| Détail du fret |
Marchandises, quantité, emballage |
Code ISO, numéro de conteneur, scellé et type de mise à disposition |
| Gestion du temps |
Fenêtre de livraison |
Expiration du temps libre plus exposition au detention et au demurrage |
| Visibilité |
Localisation du véhicule ou de l’envoi |
ETA vers le terminal et statut sur les événements portuaires |
| Gestion des exceptions |
Enlèvement ou livraison en retard |
Créneau manqué, release indisponible, refus au gate ou risque sur l’horloge |
Un opérateur conteneur devrait rejeter toute plateforme incapable d’afficher ces champs dans la vue de travail du dispatcher. Le guide d’architecture des logiciels de transport de conteneurs fournit un contexte utile pour évaluer les flux spécifiques aux conteneurs, mais le test final reste opérationnel. Donnez au fournisseur une vraie réservation, un créneau terminal modifié et une échéance de temps libre. Demandez à l’équipe de gérer l’exception sans créer de fichier parallèle.
Intégrations et échanges de données sur lesquels les opérateurs s’appuient réellement
Les discussions sur l’intégration tournent souvent à l’exercice d’architecture. Les fournisseurs parlent d’API et de connectivité pendant que l’acheteur oublie de demander qui possède les données, à quelle fréquence elles circulent et ce qui se passe lorsque le flux s’arrête.
Utilisez trois niveaux. Le premier protège la finance, le second protège le dispatch, et le troisième protège l’exécution portuaire.
Le niveau 1 protège la facture
Les connexions ERP et comptables incluent Sage, Xero, QuickBooks, SAP Business One et Microsoft Dynamics 365 Business Central. La finance détient généralement les données maîtres, notamment les clients, les paramètres fiscaux, les codes comptables, les tarifs et le statut débiteur. L’intégration doit utiliser une API REST documentée, un connecteur approuvé ou un échange de fichiers sécurisé, avec des mises à jour programmées ou déclenchées par événement.
Au minimum, échangez les références client et course, les lignes de facture, les données fiscales, les devises le cas échéant, le statut de crédit, le statut de paiement et les ajustements de règlement. Sans cette connexion, le personnel ressaisit les factures et la finance peine à rapprocher les soldes débiteurs.
Le niveau 2 protège le planning quotidien
Les systèmes de télématique et d’aide conducteur comme Webfleet, Microlise, Trimble et Geotab alimentent les données opérationnelles. L’équipe des opérations détient l’interprétation de travail, même si le fournisseur télématique contrôle la plateforme source. Utilisez des API REST, des webhooks ou des fichiers sécurisés, avec des mises à jour fréquentes adaptées à l’événement. Les champs minimums doivent inclure l’identité du véhicule, l’identité du conducteur, la localisation, l’horodatage, l’état du contact ou du mouvement, les données d’ETA et les alertes pertinentes du conducteur ou du véhicule.
Les portails clients et 3PL doivent échanger la création de commande, les jalons de statut, l’ETA, la raison de l’exception, la disponibilité du POD et les numéros de référence via REST ou SFTP. Si le flux échoue, les dispatchers ne devraient pas revenir aux appels téléphoniques et aux messages dispersés.
Le niveau 3 protège l’exécution au terminal
Les systèmes portuaires et EDI peuvent inclure Portbase, Cargo Community System, EDIFACT IFTMIN, PortNet et les API de réservation de créneaux terminal. Le port ou terminal externe possède souvent les données. Demandez explicitement si le TMS prend en charge le format de message requis, la gestion des accusés de réception, la visibilité des erreurs et les mises à jour de statut de créneau.
| Niveau |
Groupe d’intégration |
Systèmes types |
Propriétaire des données |
Protocole / cadence |
Mode de défaillance si absent |
| 1 |
ERP et comptabilité |
Sage, Xero, QuickBooks, SAP Business One, Business Central |
Finance |
REST, connecteur ou SFTP, programmé ou déclenché par événement |
Ressaisie en double et soldes non rapprochés |
| 2 |
Télématique et applications conducteur |
Webfleet, Microlise, Trimble, Geotab |
Exploitation et flotte |
REST ou webhook, mises à jour fréquentes par événement |
Le dispatch revient aux appels |
| 2 |
Portails clients et 3PL |
Plateformes clients et portails partenaires |
Exploitation ou client |
REST ou SFTP, événements de commande et de jalon |
Mises à jour manuelles du statut et recherche de documents |
| 3 |
Systèmes portuaires et EDI |
Portbase, Cargo Community System, PortNet, API terminal |
Terminal ou port externe |
EDI, API ou échange de fichiers sécurisé, basé sur des événements |
Réservation manuelle de créneau et statut portuaire opaque |
Le risque majeur est un TMS qui s’intègre à la finance mais n’a aucune connectivité portuaire pratique. Pour un opérateur conteneur, cela peut laisser hors du système la partie la plus sensible en termes de délais.
Sécurité, conformité et preuves de sécurité routière
La diapositive de sécurité d’un fournisseur n’est pas une preuve. Les achats ont besoin de documents, d’un accès au système et d’engagements contractuels qui résistent à un audit client ou à une inspection réglementaire.
Exigez un certificat ISO 27001 à jour couvrant le service TMS spécifique, et pas seulement la société mère du fournisseur. Demandez un rapport SOC 2 Type II publié ou une assurance équivalente, des conditions de traitement alignées sur le RGPD, des détails d’hébergement pertinents pour votre organisation et une politique claire de conservation des données. Le contrat doit également traiter des sous-traitants, de la notification des violations, de l’export des données et de leur suppression.
Preuves que l’exploitation peut récupérer
Les droits d’accès basés sur les rôles doivent séparer le dispatch, les conducteurs, la finance, les clients, les administrateurs et les sous-traitants. La MFA, le chiffrement en transit et au repos, les pistes d’audit immuables et un accès administrateur contrôlé sont des contrôles de base. Demandez à voir comment le système enregistre les modifications des tarifs, des POD, du statut de livraison, des factures et des permissions utilisateur.
Pour les opérateurs concernés par le Paquet mobilité de l’UE, vérifiez comment les données de tachygraphe et d’heures conducteur sont importées, téléchargées, stockées et produites lors d’un contrôle. Un TMS ne remplace pas automatiquement les systèmes de conformité spécialisés. Il doit montrer exactement quelles données il gère et où un autre système reste la source faisant foi.
La norme ISO 39001 définit les exigences relatives aux systèmes de management de la sécurité routière et constitue une référence utile pour des processus de sécurité répétables et auditables (ISO's transport sector guidance). Un TMS peut soutenir cette preuve grâce aux enregistrements de comportement conducteur, aux journaux d’incidents, au statut de formation, à la qualification des sous-traitants, aux contrôles véhicules et aux liens entre les contrôles de sécurité et les courses affectées.
Une ressource pratique sur la conformité de la chaîne logistique peut aider à structurer le cadre de contrôle global. Lors de l’évaluation du fournisseur, demandez à chaque éditeur de démontrer la récupération des preuves en direct. Si produire une piste d’audit nécessite un ticket support, le contrôle n’est pas encore mature sur le plan opérationnel.
Déploiement, prise en main et coût total de possession
En 2026, la facilité de mise en œuvre et la transparence tarifaire doivent être des exigences de base, et non des concessions spéciales pour les petits opérateurs. Un transporteur de taille intermédiaire ne devrait pas accepter un long programme de transformation simplement parce que l’éditeur propose plus d’écrans que l’entreprise ne peut en utiliser.
Exigez un responsable de prise en main nommé, un périmètre écrit et un plan de mise en service figé pour le cœur planification-vers-facturation. Le fournisseur doit fournir un tenant de test pour les exécutions en parallèle, des modèles d’import documentés, une formation par rôle et un processus de traitement des défauts après lancement. Demandez ce que le client doit fournir, car le travail interne caché fait aussi partie du coût du projet.
Construire le vrai modèle de coût
Chiffrez le système sur un horizon de trois ans. Incluez les licences, les travaux d’intégration, la migration des données, la formation, le temps projet interne, les niveaux de support, les coûts d’appareil ou de connectivité le cas échéant, et le coût d’opportunité d’une facturation retardée.
| Poste de coût |
Année 1 |
Année 2 |
Année 3 |
Notes |
| Licence logicielle |
Montant devisé |
Renouvellement devisé |
Renouvellement devisé |
Préciser si la tarification est par véhicule, conducteur, course ou utilisateur |
| Mise en œuvre |
Montant unique |
Aucun ou demandes de changement |
Aucun ou demandes de changement |
Exiger un périmètre fixe et plafonné |
| Intégrations |
Développement et paramétrage |
Maintenance |
Maintenance |
Distinguer les connecteurs natifs du travail spécifique |
| Formation |
Première session |
Remise à niveau ou formation nouveaux utilisateurs |
Remise à niveau ou formation nouveaux utilisateurs |
Préciser ce qui est inclus |
| Support |
Niveau de support |
Niveau de support |
Niveau de support |
Définir les temps de réponse et l’escalade |
| Temps interne |
Affectation du personnel |
Gestion du changement |
Gestion du changement |
Inclure le travail de la finance et de l’adoption par les conducteurs |
| Sortie et migration |
Service contractuel |
Service contractuel |
Service contractuel |
Définir le format d’export et l’assistance |
Les signaux d’alerte incluent des engagements minimums supérieurs à 24 mois, des frais par appel API et une prise en main facturée à des tarifs journaliers non plafonnés. Les fournisseurs doivent expliquer chaque coût variable avant signature. Une licence bon marché avec une intégration coûteuse n’est pas un TMS bon marché.
KPI, SLA et boucle de performance du POD à la facture
Un tableau de bord rempli d’indicateurs peut quand même laisser le cycle de trésorerie invisible. Définissez chaque KPI comme un calcul opérationnel avec un responsable, une source, une règle d’exception et une conséquence.
La livraison à l’heure doit reposer sur un créneau de rendez-vous nommé. « À l’heure » doit signifier que l’arrivée réelle ou l’événement de fin se produit dans la fenêtre convenue, et non simplement que le conducteur a atteint la zone générale.
Le délai de traitement du POD doit mesurer le temps écoulé entre la fin de livraison et le scan ou le téléversement numérique. Utilisez la médiane plutôt qu’un meilleur cas sélectionné, et segmentez le résultat par conducteur, client, type de course et sous-traitant.
Le passage de la facture au cash doit mesurer la période entre l’acceptation du POD et la libération de la facture jusqu’au paiement client. Cela relie le comportement du dispatch aux résultats financiers. Un POD arrivé en retard n’est pas seulement un problème documentaire. Il retarde le moment où l’entreprise peut facturer en toute confiance.
Un exemple d’exploitation pourrait fixer 95% de livraisons à l’heure dans une fenêtre de 60 minutes, un POD médian inférieur à 4 heures et un DSO inférieur à 38 jours. Ces chiffres sont des exemples de définitions de KPI, et non des références universelles. Le TMS doit montrer comment chaque résultat est calculé, qui fournit les données, et ce qui se passe lorsque le service du fournisseur manque le seuil convenu.
| KPI |
Définition |
Objectif |
Source de données |
Réponse SLA |
| Livraison à l’heure |
Fin dans la fenêtre de rendez-vous nommée |
95% dans une fenêtre de 60 minutes |
Données de jalon et de rendez-vous du TMS |
Revue des causes profondes et crédit de service si les données du fournisseur sont indisponibles |
| Délai de traitement du POD |
Médiane des heures entre la fin de livraison et le POD téléversé |
Moins de 4 heures |
Application conducteur et horodatage du POD |
Escalade en cas d’échec du flux mobile |
| Préparation à la facturation |
Courses terminées avec références requises et POD joint |
À définir pendant la contractualisation |
Données course, POD et facturation du TMS |
Plan de correction des défauts de flux |
| Facture au cash |
Jours entre l’acceptation du POD et la libération de la facture jusqu’au paiement |
DSO inférieur à 38 jours |
TMS et système comptable |
Revue finance des litiges et des échecs d’intégration |
Pour les contrôles de flotte plus larges, les conseils 2025 sur la sécurité et la conformité de la flotte peuvent compléter les exigences de sécurité routière ci-dessus. Gardez la boucle de mesure fermée : événement de livraison, acceptation du POD, libération de la facture, statut du litige et résultat du paiement doivent être traçables jusqu’à la même course.
Exemples de formulation RFP et questions d’évaluation fournisseur
Un bon RFP force le fournisseur à décrire son comportement sous pression. Remplacez « fournit une visibilité en temps réel » par une clause testable : « Le fournisseur doit afficher les jalons prévus et réels, le statut actuel des exceptions, ainsi que l’horodatage et la source de chaque mise à jour pour chaque course active. »
Clauses prêtes à copier
- Propriété des données : « Toutes les données opérationnelles, clients, courses, POD, factures, audits et configurations créées par l’acheteur restent la propriété de l’acheteur et doivent pouvoir être exportées dans un format documenté et utilisable. »
- Accès d’audit : « L’acheteur doit pouvoir récupérer les modifications d’utilisateur, de statut, de tarif, de POD, de facture et d’autorisation avec horodatage et identité de l’acteur. »
- Niveau de service d’intégration : « Les intégrations critiques doivent disposer d’une cible de disponibilité, d’une surveillance, d’une notification d’incident et d’un processus de reprise convenus. »
- Conservation des POD : « Les images POD et leurs métadonnées associées doivent rester récupérables pendant la période de conservation contractuelle de l’acheteur et exportables à la résiliation. »
- Assistance à la sortie : « Le fournisseur doit fournir un export documenté, un support de transition et une coopération raisonnable avec un prestataire de remplacement. »
Trente questions qui imposent des réponses utiles
- Le système peut-il capturer les commandes depuis nos canaux requis ?
- Les planificateurs peuvent-ils filtrer la grille des courses en cours par véhicule, conducteur, client, statut et exception ?
- Les utilisateurs peuvent-ils modifier en masse ou réaffecter des courses ?
- Le système peut-il conserver un historique complet des modifications ?
- Les conducteurs peuvent-ils recevoir sur mobile les consignes d’itinéraire, d’accès et de référence ?
- Le flux conducteur fonctionne-t-il en l’absence de connectivité ?
- Le système peut-il enregistrer les jalons prévus et réels ?
- Peut-il signaler les courses à risque avant qu’une fenêtre de rendez-vous ne soit manquée ?
- Les conducteurs peuvent-ils téléverser les POD directement sur la bonne course ?
- La finance peut-elle voir quelles courses sont prêtes à être facturées ?
- Le système peut-il bloquer ou signaler les factures sans POD ou sans références ?
- Peut-il rapprocher les charges de transport prévues et réelles ?
- Peut-il capturer les données de réservation, de release, de conteneur, de terminal et de code ISO ?
- Peut-il afficher l’expiration du temps libre et le risque de detention ou de demurrage ?
- Peut-il enregistrer les réservations de créneaux terminal et leurs modifications ?
- Peut-il calculer ou recevoir l’ETA en direct vers le terminal ?
- Quels systèmes ERP et comptables disposent de connecteurs pris en charge ?
- Quelles interfaces REST, webhook, SFTP ou EDI sont disponibles ?
- Quelle partie possède chaque champ de données échangé ?
- Que se passe-t-il lorsqu’une intégration échoue ?
- Les utilisateurs peuvent-ils voir les messages rejetés et les renvoyer ?
- Le système peut-il échanger les données de POD et de statut avec les portails clients ?
- Le service dispose-t-il d’une couverture ISO 27001 pour le TMS lui-même ?
- Un rapport SOC 2 Type II ou équivalent est-il disponible ?
- Comment la MFA, le chiffrement, les rôles et les journaux d’audit sont-ils mis en œuvre ?
- Comment les flux d’heures conducteur et de tachygraphe sont-ils pris en charge ?
- Le fournisseur peut-il montrer la récupération des preuves de sécurité et des sous-traitants ?
- Qui est responsable de la prise en main, et que comprend le périmètre fixe ?
- Existe-t-il un sandbox pour les exécutions parallèles et les tests d’acceptation utilisateur ?
- Quels sont les frais de licence, d’intégration, de support, de renouvellement, d’API, de sortie et de résiliation ?
Pondérez la grille d’évaluation en faveur de la performance à l’heure, du délai de traitement du POD, de la préparation à la facturation, du contrôle du statut conteneur et de l’intégration ERP. Les analyses intéressantes ne doivent pas surpasser les flux de travail qui font avancer les camions et défendent les factures.
Mise en correspondance des exigences avec Logivo à titre d’exemple
Une évaluation pratique de Logivo doit commencer par le périmètre opérationnel publié, et non par une promesse commerciale. Sa plateforme de gestion du transport couvre la création des courses, l’affectation, le suivi d’exécution, les briefings conducteur, la capture numérique des POD et la facturation dans un flux de travail connecté. Elle inclut aussi des flux de travail de transport conteneur et une aide IA pratique pour les tâches documentaires et de saisie.
| Zone d’exigence |
Adéquation |
Notes |
| Modules fonctionnels |
Couvre le socle |
Valider la modification en masse, la responsabilité des exceptions et le comportement hors ligne du conducteur |
| Spécificités conteneur |
Couverture pertinente |
Confirmer les champs exacts de réservation, release, terminal et temps libre requis |
| Intégrations |
Nécessite une validation |
Confirmer les connexions natives ERP, télématique, portail, API, SFTP et portuaires |
| Sécurité |
Contrat et preuve à vérifier |
Demander des certifications spécifiques au service, les contrôles d’audit, la conservation et les conditions de traitement |
| Déploiement |
Conçu pour une charge de configuration réduite |
Confirmer le périmètre, le calendrier, les responsabilités de migration, la formation et la tarification des demandes de changement |
| KPI |
Point de départ paramétrable |
Tester la logique de calcul pour les jalons, le délai de traitement du POD, la préparation à la facturation et les données cash |
| Prêt pour RFP |
Adapté à une évaluation structurée |
Exiger des réponses mesurables et des engagements écrits plutôt que des descriptions de fonctionnalités |
Un transporteur de taille intermédiaire devrait tout de même valider trois points avant de signer : le modèle exact du statut conteneur, le processus d’intégration et de rapprochement comptable, et le comportement du flux mobile en cas de faible connectivité. Considérez ce tableau comme une première évaluation, et non comme un substitut aux tests de processus en conditions réelles.
Liste de contrôle rapide, glossaire et FAQ
Remettez cette liste de contrôle au responsable des opérations, au directeur financier et au dispatcher. Chaque question doit recevoir un oui ou un non clair pendant la démonstration fournisseur.
Liste de contrôle acheteur
- Socle fonctionnel : Le système peut-il créer, planifier, affecter, briefer, suivre, terminer et facturer les courses dans un seul flux ?
- Grille des courses : Les utilisateurs peuvent-ils filtrer, modifier en masse, réaffecter et identifier les exceptions sans ouvrir chaque course ?
- POD : Les conducteurs peuvent-ils soumettre une preuve signée ou numérique directement sur la course ?
- Contrôle de facturation : La finance peut-elle identifier les courses prêtes à facturer et les documents manquants ?
- Contrôle conteneur : Le système peut-il stocker le numéro de réservation, le numéro de conteneur, le terminal, le type de release, le créneau et l’expiration du temps libre ?
- Visibilité terminal : Le dispatch peut-il voir l’ETA et les exceptions liées au port dans la même vue opérationnelle ?
- Intégration ERP : Les données client, tarif, facture, taxe, paiement et ajustement peuvent-elles circuler sans ressaisie en double ?
- Données conducteur et télématique : Le système peut-il recevoir les données véhicule, conducteur, localisation, horodatage et jalon ?
- Échange portuaire : Peut-il prendre en charge l’API, le SFTP, l’EDI ou le flux de réservation requis ?
- Sécurité : Le fournisseur fournit-il une certification spécifique au service, la MFA, le chiffrement, des contrôles de rôle et des pistes d’audit ?
- Conformité : L’équipe peut-elle récupérer les preuves conducteur, incident, sous-traitant et document ?
- Déploiement : Existe-t-il un responsable de prise en main nommé, un périmètre fixe, un sandbox, un plan de migration et un plan de formation ?
- Commercial : Les coûts de licence, d’intégration, de support, d’API, de prise en main, de renouvellement et de sortie sont-ils détaillés ?
- KPI : Les définitions de livraison à l’heure, du délai de traitement du POD, de la préparation à la facturation et du passage de la facture au cash sont-elles écrites ?
- Protection RFP : Le contrat et le SLA couvrent-ils la propriété des données, la disponibilité, l’accès d’audit, la conservation et le support de transition ?
Glossaire en langage simple
TMS : Logiciel qui gère la planification transport, le dispatch, l’exécution, la visibilité, les documents, la facturation et le règlement.
POD : Preuve de livraison, telle qu’un bon de livraison signé, une confirmation numérique, un horodatage ou un enregistrement de livraison joint.
EDI 204 et 214 : Messages électroniques courants utilisés pour communiquer les tenders de transport et les événements de statut d’envoi. Confirmez les formats exacts exigés par vos clients.
ISO 39001 : Une norme pour les systèmes de management de la sécurité routière, utile pour des contrôles de sécurité structurés et des preuves auditables.
SOC 2 : Un rapport d’assurance indépendant sur les contrôles liés à la sécurité et aux engagements de service associés.
Télématique : Données véhicule et conducteur, incluant la localisation, le mouvement et certains signaux opérationnels.
Réservation de créneau : Un rendez-vous planifié permettant à un véhicule d’accéder à un terminal, un dépôt, un entrepôt ou toute autre installation contrainte.
Detention : Une charge ou une exposition associée au maintien d’un équipement au-delà de la période autorisée. Le demurrage concerne généralement l’équipement ou la cargaison restant dans un terminal au-delà de la période autorisée. Les définitions contractuelles varient, donc configurez le système pour correspondre aux termes applicables.
Questions fréquentes
Combien de temps dure généralement un déploiement de milieu de marché ?
La réponse dépend de la qualité des données, des intégrations, de la variation des processus et de la préparation des utilisateurs. Pour le cœur planification-vers-facturation, exigez du fournisseur un plan de mise en service fixe et fondé sur des preuves plutôt qu’une mise en œuvre ouverte sans fin.
Quel est le périmètre minimal viable pour une flotte de 20 camions ?
Commencez par la prise de commande, la grille des courses, le dispatch, le briefing conducteur, les jalons d’exécution, la capture du POD, la préparation à la facturation et l’intégration comptable. Ajoutez l’optimisation avancée et une connectivité portail plus large une fois le flux de base stabilisé.
Comment éviter la dérive du périmètre pendant la prise en main ?
Inscrivez le processus minimum viable dans le cahier des charges. Nommez les champs requis, les intégrations, les utilisateurs, les rapports, les tests d’acceptation et les livrables de formation. Faites passer chaque demande supplémentaire par un processus de changement chiffré.
Quand faut-il construire plutôt qu’acheter ?
Ne construisez que lorsque votre modèle d’exploitation est distinctif et que vous pouvez financer la propriété à long terme, le support, la sécurité, les intégrations et les mises à niveau. Achetez lorsque le processus est suffisamment courant pour utiliser des flux éprouvés, tout en exigeant de la configuration et un accès aux données plutôt qu’un développement spécifique coûteux.
Logivo offre un flux de travail unifié pour les transporteurs et les opérateurs conteneurs afin de planifier les courses, briefer les conducteurs, capturer des POD numériques, gérer les travaux liés aux conteneurs et relier les courses terminées à la facturation. Visitez Logivo pour comparer son flux de travail à votre RFP, puis testez les trois points les plus importants pour votre exploitation : le délai de traitement du POD, l’intégration comptable et le contrôle du statut conteneur.