En bref
« Logiciel de gestion du transport » et « TMS » ne sont pas deux catégories séparées par une réglementation. Ce sont des termes commerciaux et fonctionnels qui se recoupent souvent. Choisir selon le seul nom du produit est donc peu utile.
Pour une petite entreprise, la distinction la plus pratique est la suivante :
- un logiciel de gestion simple organise correctement le travail interne quotidien ;
- un TMS plus structuré tend à gérer une plus grande complexité de réseau, de transporteurs, de tarifs, d’intégrations, d’exceptions et de contrôle des coûts.
Ce n’est pas une échelle de qualité. Un système plus complexe n’est pas automatiquement meilleur : il ne l’est que si cette complexité est nécessaire.
Il n’existe pas de frontière juridique entre logiciel de gestion et TMS
Aucune loi n’établit qu’un logiciel doit avoir « 10 fonctions » pour s’appeler TMS, ni qu’un logiciel de gestion ne peut pas faire de planification. Le terme TMS décrit une famille de solutions, pas une certification.
Par conséquent, une PME devrait oublier quelques minutes le nom commercial et se demander :
- quels processus il couvre ;
- dans quelle mesure il les couvre bien ;
- quelles données il demande ;
- combien de personnes doivent l’utiliser ;
- combien coûte sa mise en œuvre et sa maintenance ;
- à quel point il est facile d’en sortir et de récupérer les données.
Comparaison pratique
| Domaine | Logiciel de gestion simple pour petite flotte | TMS structuré |
|---|---|---|
| Clients et sites | Central | Central |
| Commandes | Central | Central |
| Conducteurs et véhicules propres | Souvent central | Dépend de la cible |
| Plan quotidien | Central | Central, souvent plus sophistiqué |
| Application/communication conducteur | Possible | Possible/intégrée |
| Transporteurs tiers | Limitée ou absente | Souvent avancée |
| Appels d’offres/achats | Rare | Fréquent dans les systèmes d’entreprise |
| Tarifs complexes | Essentiels ou absents | Souvent avancés |
| Optimisation | Limitée/facultative | Plus courante |
| Audit du fret | Rare | Possible/avancé |
| ERP/WMS/EDI/API | Simple ou sélectif | Souvent fondamental |
| Mise en œuvre | Jours/semaines dans les cas simples | Peut nécessiter un projet dédié |
| Configuration | Réduite | Souvent étendue |
| Formation | Limitée | Plus structurée |
Le tableau est indicatif : chaque produit doit être vérifié individuellement.
La vraie ligne de partage : la complexité du processus
Le nombre de camions compte, mais ne suffit pas. Deux entreprises ayant chacune dix véhicules peuvent avoir des besoins opposés.
Entreprise A
- clients habituels ;
- itinéraires relativement stables ;
- flotte propre ;
- peu d’opérateurs au bureau ;
- commandes reçues par e-mail ;
- besoin principal : organiser la commande, le camion, le conducteur et les changements.
Un logiciel de gestion léger peut être parfaitement adapté.
Entreprise B
- dix véhicules propres mais aussi 80 transporteurs externes ;
- des centaines de commandes ;
- des tarifs différents selon la zone, le poids et le client ;
- flux EDI ;
- portail client ;
- audit des factures des transporteurs ;
- KPI contractuels.
Ici, le nombre de camions ne décrit plus la complexité. Un TMS plus structuré peut se justifier.
Cinq signes qu’un logiciel de gestion simple suffit
1. Le principal problème est la dispersion des informations
Si la vraie difficulté consiste à recopier des commandes depuis les e-mails dans Excel puis à téléphoner aux conducteurs, la priorité est d’avoir une source unique.
2. La flotte est majoritairement propre
Il n’est pas nécessaire d’avoir un moteur d’achat de transporteurs lorsqu’il n’y a pas d’achats à gérer.
3. La planification repose sur l’expérience du dispatcheur
Un bon calendrier et des données propres peuvent apporter plus de valeur qu’un moteur d’optimisation qui exige des mois de paramétrage.
4. Peu de personnes travaillent au bureau
Un système avec des dizaines de rôles, d’approbations et de workflows peut devenir un obstacle.
5. Les intégrations nécessaires sont peu nombreuses
S’il suffit d’importer un fichier Excel, d’exporter des données et de connecter un ou deux services, une architecture d’entreprise peut être inutile.
Cinq signes qu’il faut quelque chose de plus structuré
1. De nombreux transports sont achetés à des tiers
Le choix du transporteur, les conditions économiques, les performances et la disponibilité deviennent des processus centraux.
2. Les tarifs ne sont plus gérables manuellement
De nombreuses combinaisons de zone, poids, palettes, carburant, péages et suppléments exigent des règles structurées.
3. La commande doit traverser plusieurs systèmes
ERP, WMS, EDI, portails clients, plateformes de suivi et administration nécessitent une gouvernance des intégrations.
4. Les erreurs ont un coût systématique
Doubles factures, coûts imprévus, SLA, pénalités et grands volumes rendent utile un contrôle automatisé.
5. La direction a besoin de données consolidées
Il ne suffit pas de savoir « ce que font les camions aujourd’hui » : il faut mesurer les coûts, les performances et la capacité sur des réseaux complexes.
Le coût ne se limite pas à l’abonnement : calculer le TCO
Pour comparer deux solutions, il est utile d’estimer le Total Cost of Ownership sur au moins trois ans.
À prendre en compte :
- licences utilisateurs/véhicules/commandes ;
- coût de mise en place ;
- migration des données ;
- formation ;
- conseil ;
- développement API/EDI ;
- modules supplémentaires ;
- assistance premium ;
- coûts des environnements/tests ;
- éventuels appareils ;
- temps interne des équipes ;
- maintenance des intégrations ;
- augmentations de prix contractuelles ;
- coût de sortie/migration future.
Un logiciel à 100 euros par mois qui exige 15.000 euros de personnalisations ne coûte pas 100 euros par mois. À l’inverse, un logiciel standard légèrement plus cher peut se révéler moins coûteux s’il évite un projet et sa maintenance.
Le risque du surdimensionnement
Le surdimensionnement produit des effets concrets :
- davantage de champs à remplir ;
- davantage de formation ;
- des processus adaptés au logiciel plutôt qu’au travail ;
- des opérateurs qui reviennent à Excel « pour aller plus vite » ;
- dépendance à des consultants ;
- mises à jour plus difficiles ;
- coûts fixes disproportionnés.
Un signal d’alerte apparaît lorsque, pour gérer une commande normale, l’entreprise doit remplir des informations que personne n’utilisera.
Le risque inverse : rester trop longtemps avec des outils fragiles
Le sous-dimensionnement coûte également. Si Excel est devenu le système central mais que :
- il existe cinq versions du fichier ;
- des modifications et des commandes se perdent ;
- personne ne sait qui a changé quoi ;
- il n’existe ni rôles ni droits d’accès ;
- les conducteurs reçoivent les données séparément ;
- le fichier est reconstruit après chaque erreur ;
- le dirigeant est la seule personne qui « sait comment cela fonctionne »,
le coût n’apparaît pas sur une facture, mais il existe en heures, en erreurs et en dépendance aux personnes.
Le passage à un logiciel de gestion devrait avoir lieu avant que le fichier ne devienne impossible à remplacer.
Exemple : 8 camions face à un réseau de transporteurs
Entreprise avec 8 camions propres
Elle reçoit 25 commandes par jour. Deux personnes planifient. Le problème principal est de savoir de façon partagée quel conducteur effectuera quel enlèvement et de communiquer les changements.
Priorités :
- commande structurée ;
- plan quotidien ;
- données de référence conducteurs/véhicules ;
- mise à jour des conducteurs ;
- historique ;
- export.
Un logiciel de gestion simple peut couvrir presque toute la valeur nécessaire.
Opérateur qui coordonne 120 transporteurs
Il reçoit 800 commandes par jour, achète de la capacité sur le marché, utilise plusieurs grilles tarifaires, intègre l’ERP et le WMS et doit vérifier les factures et les SLA.
Priorités :
- intégration ;
- achats ;
- tarifs ;
- attribution ;
- exceptions ;
- suivi ;
- audit des coûts ;
- analytique.
Ici, le projet TMS fait partie de la structure opérationnelle de l’entreprise.
Matrice de décision
Attribuez de 0 à 2 points pour chaque élément :
| Question | 0 | 1 | 2 |
|---|---|---|---|
| Combien de systèmes doivent s’intégrer ? | 0-1 | 2-3 | 4+ |
| Combien de transporteurs tiers gérons-nous ? | presque aucun | quelques-uns | beaucoup |
| Complexité tarifaire | faible | moyenne | élevée |
| Nombre d’exceptions | faible | moyen | élevé |
| Besoin d’achats | aucun | occasionnel | central |
| Audit des coûts | manuel simple | partiel | systématique |
| Workflows/approbations | presque aucun | quelques-uns | beaucoup |
| Réseau | local/simple | national | multimodal/international complexe |
Le score ne produit pas une vérité mathématique. Il sert à obliger l’entreprise à décrire sa propre complexité avant de regarder les logiciels.
Checklist
- Choisissons-nous selon le nom « TMS » ou selon les processus ?
- Quels trois problèmes doivent être résolus dans les 90 jours ?
- Combien de personnes utiliseront réellement le système ?
- Combien d’intégrations sont indispensables ?
- Gérons-nous surtout une flotte propre ou des transporteurs tiers ?
- Avons-nous des tarifs complexes ?
- Combien coûte le projet sur trois ans, et pas seulement l’abonnement ?
- Pouvons-nous commencer petit et ajouter des modules ?
- Pouvons-nous exporter les données si nous changeons de fournisseur ?
- Le système demande-t-il plus de discipline que l’organisation ne peut en soutenir aujourd’hui ?