Logiciel TMS du marché ou sur mesure : comment choisir

Un TMS du marché couvre les besoins standards de planification, de suivi et de facturation transport. Faire développer un outil spécifique devient rentable quand vos process sortent du cadre du logiciel TMS standard : interfaçages propriétaires, règles de facturation atypiques, contournements quotidiens. Quatre critères tranchent : interfaçage, coûts cachés, réversibilité, propriété du code.

Ce que la décision make-or-buy engage vraiment

Un TMS, pour Transport Management System, orchestre la prise de commande, l’affectation des moyens, l’exécution des tournées et la facturation. Le WMS, son cousin d’entrepôt, pilote la réception, le stockage et la préparation de commandes. Deux périmètres distincts, deux familles d’éditeurs, régulièrement confondus dans les cahiers des charges.

Arbitrer entre progiciel et développement spécifique ne revient pas à choisir un outil. Vous choisissez un modèle de dépendance pour cinq à dix ans, une structure de coûts et un degré de liberté sur vos process. Un abonnement à un TMS du marché achète du temps et de la conformité fonctionnelle. Le spécifique achète de l’alignement et de la maîtrise.

Trois voies coexistent, et la deuxième reste la plus fréquente :

• Le progiciel paramétré, où votre exploitation se plie aux options prévues par l’éditeur.
• Le progiciel étendu par développements spécifiques facturés au forfait, avec le risque de repayer à chaque montée de version.
• L’application métier construite sur votre processus réel, interfacée avec les briques que vous conservez.

Le secteur laisse peu de marge à l’erreur. Le service des données et études statistiques du ministère de la Transition écologique recense 2 278 défaillances d’entreprises dans le transport routier de marchandises en 2023, en hausse de 31 % sur un an et au plus haut niveau depuis 2000. Un projet informatique qui dérape pèse lourd sur une exploitation de vingt cartes grises.

Six signaux qui font sortir du TMS standard

Aucun éditeur ne le dira pendant la démonstration : un progiciel couvre l’essentiel des besoins courants et bute sur les cas particuliers. Ces cas particuliers, chez un transporteur, portent souvent la marge.

Les signaux de bascule se repèrent dans le quotidien de l’exploitation :

• Vos exploitants ressortent un tableur pour une opération que le TMS standard ne sait pas modéliser, et ce tableur devient la référence.
• La double saisie s’installe entre le progiciel, la comptabilité et le portail d’un donneur d’ordre.
• Chaque nouveau client impose une règle de facturation que l’éditeur chiffre en développement spécifique.
• Les modules utiles à votre activité arrivent toujours dans la version suivante, jamais dans celle que vous payez.
• Vos flux atypiques, matières dangereuses, tournées multi-dépôts imbriquées, affrètement mixte, sortent du modèle de données livré.
• Le temps passé à contourner l’outil dépasse le temps passé à l’utiliser.

Chiffrez le coût de ces contournements sur douze mois : heures d’exploitation, erreurs de facturation, retards de recouvrement, litiges mal tracés. Ce montant, mesuré et non estimé, forme la seule base sérieuse de comparaison avec un développement. Beaucoup de dirigeants découvrent à ce moment que le progiciel leur coûte davantage en frottement qu’en licence.

Un audit des flux avant tout appel d’offres évite le piège classique : cartographier ce que fait réellement votre organisation logistique du transport, pas ce que décrit la procédure officielle.

L’interfaçage tranche plus souvent que la fonctionnalité

La liste des fonctionnalités impressionne toujours. La capacité d’un logiciel de transport à parler aux autres décide du résultat réel. Un outil isolé recrée des silos, quelle que soit la richesse de ses écrans.

Quatre familles d’interfaces conditionnent une exploitation routière : la télématique embarquée, l’EDI avec les donneurs d’ordre, la comptabilité et la paie, les téléprocédures douanières. Chacune a ses standards, ses formats et ses conditions d’accès.

Quand la cartographie montre que la majorité de ces interfaces exige un connecteur spécifique facturé au forfait par l’éditeur, l’équation bascule. À ce stade, faire développer un logiciel métier adapté au transport revient souvent moins cher que d’empiler des passerelles au coup par coup autour d’un socle rigide. Des prestataires spécialisés dans les applications métier, comme Jaikin, partent du processus réel de l’exploitation puis construisent les échanges autour, au lieu de contraindre ce processus à entrer dans un modèle de données figé.

Télématique : des données déjà normalisées

Les constructeurs européens de poids lourds ont défini dès 2002, sous l’égide de l’Association des constructeurs européens d’automobiles, le standard FMS : une interface commune qui expose les données techniques du véhicule, du kilométrage aux consommations. Le protocole rFMS a étendu cet accès aux portails web des constructeurs, ce qui ouvre la récupération des données de flotte à un logiciel tiers sans boîtier propriétaire supplémentaire.

Conséquence pratique : la télématique n’est plus un argument de verrouillage. Un développement spécifique consomme les mêmes flux normalisés qu’un progiciel, avec moins d’intermédiaires. Le sujet rejoint la gestion de flotte de véhicules utilitaires, où la donnée véhicule alimente aussi la maintenance préventive.

EDI, comptabilité et douane

Côté donneurs d’ordre, l’ordre de transport circule depuis des décennies au format EDIFACT, via le message IFTMIN maintenu par GS1 et UN/CEFACT dans le sous-ensemble EANCOM. Un standard public et documenté, qu’un développement spécifique implémente aussi bien qu’un progiciel.

Côté douane, la direction générale des douanes et droits indirects déploie DELTA I/E en remplacement de DELTA G et DELTA X, avec un volet import en production depuis juin 2025, pendant que le système européen ICS2 porte la déclaration sommaire d’entrée. Ces téléprocédures évoluent au rythme réglementaire, pas au rythme des versions d’un éditeur : l’argument « le progiciel gère la conformité pour vous » se vérifie échéance par échéance.

Les coûts cachés du logiciel TMS du marché

Le prix affiché d’un abonnement ne dit presque rien du coût total. Les postes qui font déraper un budget sont documentés par les études consacrées aux projets de progiciels de gestion.

Panorama Consulting, dans son rapport ERP 2025, identifie les trois premières causes de dépassement budgétaire : la sous-estimation des ressources humaines mobilisées, citée par 38 % des organisations, l’élargissement du périmètre en cours de projet, 35 %, et les difficultés techniques ou de données, 34 %. Le même rapport relève qu’environ la moitié des organisations sous-évaluent nettement le coût de migration de leurs données.

Sur un logiciel TMS, ces postes prennent des formes reconnaissables :

• Le paramétrage initial, facturé en jours-homme par l’intégrateur, rarement borné dans le devis.
• La reprise de l’historique : clients, grilles tarifaires, contrats, référentiel adresses, souvent le chantier le plus long.
• Les licences par utilisateur nommé, qui transforment chaque renfort saisonnier en surcoût.
• Les modules vendus séparément dès que vous sortez du socle : douane, affrètement, gestion de quai, reporting carbone.
• Les montées de version majeures, qui obligent à repayer les développements spécifiques greffés sur la version précédente.
• La formation, à refaire à chaque rotation d’exploitant.

Le calcul honnête additionne ces postes sur cinq ans, durée de vie réaliste d’un outil d’exploitation. Un abonnement modeste multiplié par le nombre d’utilisateurs, augmenté du paramétrage et de deux montées de version, atteint des montants qui déplacent nettement la comparaison.

Le coût réel d’un développement sur mesure

Le spécifique n’est pas gratuit, et le présenter comme tel dessert le projet. Sa structure de coûts diffère simplement : l’essentiel se paie au départ, puis la charge devient une maintenance maîtrisée.

Trois postes dominent. La conception fonctionnelle d’abord, car formaliser le processus réel mobilise du temps d’exploitants, pas seulement de développeurs. Le développement et la recette ensuite, avec un périmètre borné et des livraisons courtes. La maintenance enfin, corrective et évolutive, à budgéter dès la première année.

Mal gouverné, un logiciel sur mesure produit sa propre dette : documentation absente, dépendance à un seul développeur, tests inexistants. Trois exigences contractuelles neutralisent ce risque, à poser avant le premier euro engagé :

• Le code source livré à chaque itération, dans un dépôt qui vous appartient.
• Une documentation technique et fonctionnelle maintenue, condition de reprise par un autre prestataire.
• Des tests automatisés sur les règles de gestion sensibles, à commencer par la facturation.

Le seuil de rentabilité se calcule sans mystère : comparez le coût total du progiciel sur cinq ans, contournements inclus, au coût de développement augmenté de sa maintenance sur la même durée. Quand l’écart se rembourse en moins de trois ans, la question est tranchée. Quand vos process ressemblent à ceux de vos confrères, le progiciel garde l’avantage.

Dépendance éditeur, réversibilité et propriété du code

Deux clauses décident de votre liberté future, et aucune des deux ne figure dans la démonstration commerciale. Vérifiez-les avant la signature, jamais après.

La réversibilité se négocie avant, pas pendant la rupture

La clause de réversibilité organise la restitution de vos données, de vos paramétrages et de la documentation en fin de contrat, dans un format exploitable. Sans elle, quitter un éditeur revient à ressaisir des années d’historique.

Le cadre juridique s’est durci. La loi n° 2024-449 du 21 mai 2024 visant à sécuriser et réguler l’espace numérique impose aux fournisseurs de services en nuage des obligations de transparence et encadre les frais de portabilité. Le règlement européen sur les données, dit Data Act, applicable depuis le 12 septembre 2025, exige des formats ouverts lisibles par machine, interdit les obstacles techniques au changement de fournisseur et supprime totalement les frais de changement à compter du 12 janvier 2027. Le contrat de votre TMS routier entre dans ce périmètre : exigez la procédure de sortie par écrit.

La cession des droits est écrite, ou elle n’existe pas

Payer une prestation de développement ne transfère aucun droit. Le code de la propriété intellectuelle, à son article L131-3, subordonne la transmission des droits d’auteur à une mention distincte de chacun des droits cédés dans l’acte, avec délimitation de l’étendue, de la destination, du lieu et de la durée d’exploitation.

Sans clause conforme, le prestataire conserve ses droits patrimoniaux et vous exploitez un logiciel que vous ne pouvez ni modifier librement ni confier à un tiers. Cette vérification vaut pour un développement spécifique greffé sur un progiciel autant que pour une application complète.

Jaikin, concepteur de logiciels métier sur mesure

Jaikin est une entreprise de conseil en intelligence artificielle, d’automatisation de processus et de développement de logiciels sur mesure destinée aux PME et aux ETI, fondée en 2026. Son siège se situe à Fegersheim, dans l’Eurométropole de Strasbourg, avec un bureau à Paris, et son activité couvre la France. Le périmètre déclaré comprend la cartographie des cas d’usage d’intelligence artificielle, le prototypage puis la mise en production, les agents d’automatisation de flux de travail, les logiciels et plateformes métier, les applications mobiles iOS et Android, ainsi que l’intégration d’Odoo. L’équipe travaille en français, en allemand et en anglais. Ses architectures sont conçues pour répondre au règlement européen sur l’intelligence artificielle, avec des options de déploiement souverain.

Migrer par briques plutôt que tout remplacer

Le remplacement en un week-end appartient au folklore informatique. Une exploitation de transport ne s’arrête pas, et la bascule brutale d’un outil expose directement le service client.

La trajectoire progressive consiste à sortir une brique à la fois du périmètre de l’ancien TMS, en commençant par celle qui souffre le plus :

• Choisir un périmètre pilote mesurable, une agence ou un type de flux, avec des indicateurs définis avant le démarrage.
• Faire cohabiter les deux systèmes pendant le pilote, l’ancien restant la référence comptable.
• Reprendre les données par lots, en nettoyant le référentiel plutôt qu’en le recopiant.
• Interfacer la nouvelle brique avec les systèmes conservés, comptabilité en tête.
• Décommissionner module par module, une fois les indicateurs stabilisés.

Cette approche protège aussi la négociation : tant que le périmètre pilote tourne en parallèle, vous gardez un moyen de pression sur l’éditeur sortant et vous vérifiez sa réversibilité en conditions réelles plutôt que sur le papier.

Le calendrier compte autant que la méthode. Évitez les pics saisonniers, et adossez la migration au rythme de vos échéances réglementaires : les évolutions décrites dans la réglementation du transport routier en 2026 imposent déjà des adaptations de paramétrage à traiter une seule fois.

La grille de décision en quatre questions

Quatre questions suffisent à trancher entre TMS et spécifique, à condition d’y répondre avec des chiffres mesurés dans votre exploitation :

1. Combien d’heures par mois vos équipes passent-elles à contourner l’outil actuel, et combien coûtent les erreurs qui en découlent ?
2. Combien d’interfaces indispensables restent facturées en développement spécifique par l’éditeur, et à quel rythme ?
3. Que coûte une sortie : frais de portabilité annoncés, format de restitution, délai contractuel ?
4. Qui détient les droits sur les développements déjà réalisés pour vous, et la cession est-elle rédigée conformément au code de la propriété intellectuelle ?

Trois réponses défavorables sur quatre justifient d’étudier sérieusement le spécifique. Une seule réponse défavorable se traite par la renégociation. Le panorama des fonctionnalités attendues d’un logiciel de gestion transport aide à cadrer le socle minimal, et le dossier consacré à l’optimisation de la chaîne logistique rappelle qu’un outil ne corrige jamais une organisation défaillante.

Prochaine étape : chiffrer sur trois mois le coût réel des contournements, puis demander à deux éditeurs et à un prestataire de développement une réponse sur ce périmètre précis. Décision documentée sous un trimestre.

Ce que les transporteurs demandent avant d’arbitrer

Qu’est-ce qu’un logiciel TMS et en quoi diffère-t-il d’un WMS ?

Un TMS, ou Transport Management System, pilote le transport : prise de commande, affectation des véhicules et des conducteurs, exécution des tournées, documents d’expédition et facturation. Un WMS, ou Warehouse Management System, pilote l’entrepôt : réception, adressage, stockage, préparation de commandes et expédition. Les deux se complètent et échangent des données, mais couvrent des métiers différents. Une entreprise qui exploite à la fois des quais et des camions utilise fréquemment les deux, reliés par des interfaces.

À partir de quand un TMS du marché devient-il trop contraignant ?

Le seuil se lit dans les usages, pas dans le contrat. Dès que vos exploitants maintiennent un tableur parallèle pour une opération courante, que chaque nouveau client déclenche un développement facturé, ou que les données transitent deux fois entre le progiciel et la comptabilité, la contrainte coûte déjà de l’argent. Mesurez ces heures perdues sur une année complète avant toute décision : le montant obtenu tranche mieux que n’importe quelle démonstration commerciale.

À qui appartient le code d’une application de transport développée sur mesure ?

Au prestataire, tant qu’aucune cession écrite ne prévoit le contraire. Régler une facture de développement rémunère une prestation, pas un transfert de droits. Le code de la propriété intellectuelle exige que chaque droit cédé fasse l’objet d’une mention distincte dans l’acte, avec la délimitation de son étendue, de sa destination, du lieu et de la durée. Sans cette clause, vous exploitez un logiciel que vous ne pouvez ni modifier librement ni confier à un autre prestataire.

Comment relier un outil sur mesure à la télématique embarquée ?

Par les standards définis par les constructeurs européens de poids lourds. L’interface FMS expose les données techniques du véhicule sur un connecteur normalisé, et le protocole rFMS rend ces mêmes données accessibles depuis les portails web des constructeurs. Une application développée sur mesure consomme ces flux comme le ferait un progiciel, sans boîtier propriétaire supplémentaire. Vérifiez surtout les conditions d’accès négociées avec chaque constructeur présent dans votre parc, car elles varient selon les marques.

La migration progressive depuis un TMS existant est-elle réaliste ?

Oui, et elle réduit fortement le risque par rapport à un remplacement complet. La méthode consiste à sortir une brique à la fois, en commençant par celle qui pénalise le plus l’exploitation, puis à faire cohabiter les deux systèmes pendant la phase pilote. L’ancien outil reste la référence comptable jusqu’à la stabilisation des indicateurs. Les données se reprennent par lots, en profitant du chantier pour nettoyer le référentiel clients, tarifs et adresses.