Interfacer un développement sur mesure avec un TMS existant : ce qui casse en général
Le montage hybride — conserver le progiciel pour l’exécution, développer autour ce qu’il ne modélise pas — est celui que nous recommandons le plus souvent. Il a un point faible unique et prévisible : l’interface.
Voici ce qui casse, dans l’ordre de fréquence.
1. L’API existe, mais pas pour ce dont vous avez besoin
La plupart des progiciels exposent une API pensée pour l’import de commandes et l’export de statuts. Presque aucune n’expose ce qui sert au pilotage économique : les coûts internes, les temps réels d’immobilisation, la structure d’un affrètement.
Le réflexe est de demander « avez-vous une API ». La bonne question est « donnez-moi la liste des ressources exposées en lecture et en écriture, avec leurs champs ». La différence entre les deux se mesure en semaines de projet.
À noter que l’accès à l’API est parfois lui-même un palier commercial : chez AntsRoute, elle n’apparaît qu’à partir de l’offre à 54 € par véhicule et par mois.
2. Les référentiels ne coïncident pas
Le progiciel a ses codes clients, ses codes sites, ses codes véhicules. L’entreprise en a d’autres, souvent hérités de la comptabilité. Le développement doit décider lequel fait foi.
L’erreur classique est de construire une table de correspondance et de la maintenir à la main. Elle est juste le premier mois, fausse le sixième. La règle que nous appliquons : un référentiel maître unique par entité, désigné explicitement au cadrage, et une synchronisation dans un seul sens.
3. Le sens de la vérité n’a pas été tranché
Quand deux systèmes peuvent modifier la même donnée, il faut décider lequel gagne — et le décider par champ, pas par objet.
Sur une mission de transport, il est fréquent que le progiciel soit maître de l’affectation et des statuts, et que le développement soit maître des coûts et des données terrain. Tant que cette répartition n’est pas écrite, chaque incident produit une discussion.
4. Les volumes explosent au premier vrai jour
Une interface validée sur cent missions de test se comporte différemment sur un lundi matin réel. Les points de rupture habituels sont le nombre d’appels par minute toléré par le progiciel, la taille des lots en écriture, et la gestion des reprises après échec partiel.
La règle : tester sur un volume de pointe réel, pas moyen. Un système de transport ne vit pas sur sa moyenne.
5. La mise à jour du progiciel casse l’interface
C’est le risque structurel du montage hybride, et il ne se supprime pas — il se gère. Trois précautions réduisent fortement l’impact : isoler l’appel au progiciel derrière une couche d’adaptation unique, contractualiser un délai de préavis sur les changements d’API, et disposer de tests d’intégration exécutables avant chaque montée de version.
C’est aussi un argument à faire valoir auprès de l’éditeur au moment du renouvellement du contrat.
6. Personne ne surveille l’interface
Une interface qui échoue silencieusement est pire qu’une interface absente : elle donne des chiffres faux avec l’apparence de la fiabilité.
Le minimum est une supervision qui alerte sur trois événements — un lot non traité, un écart de volume par rapport à la veille, un rejet répété sur le même enregistrement. Ce n’est pas un raffinement, c’est ce qui permet de faire confiance au tableau de bord.
Ce qu’il faut décider au cadrage, pas après
- Le référentiel maître de chaque entité.
- Le sens d’autorité champ par champ sur les objets partagés.
- Le volume de pointe à tenir.
- Le comportement en cas d’indisponibilité du progiciel — file d’attente, dégradation, blocage.
- Qui est alerté, et sur quoi.
Ces cinq décisions prennent une demi-journée en atelier. Prises après la mise en production, elles coûtent un ou deux mois.
Le cas le plus parlant dans nos références publiées est Coïncidence, traiteur et lieu de réception de la région lyonnaise gérant des foodtrucks et la privatisation d’un domaine, pour qui nous avons conçu et développé des outils de réservation sur mesure connectés au CRM Dolibarr déjà en place.
C’est exactement le montage hybride décrit ici : le progiciel reste le système de référence commercial, et le développement traite ce qu’il ne modélise pas — dans ce cas des règles de réservation propres à deux activités qui n’ont pas la même logique de disponibilité. Le point qui a demandé le plus d’attention est celui du référentiel maître : décider, avant d’écrire la moindre ligne, quel système fait foi sur le client et quel système fait foi sur la disponibilité.
C’est aussi la leçon la plus transposable au transport. Sur les trois missions d’étude que nous avons publiées — ESLC, Maïa Rail, Grand Lyon et ENFRASYS —, ce sont systématiquement la cartographie de l’existant et l’analyse fonctionnelle, soit les phases 2 et 4 sur six, qui déterminent la difficulté de l’intégration. Une phase de cadrage de 15 à 17 jours, ce qui a été la durée constatée sur ces trois missions, sert d’abord à ça.
Voir aussi notre page logiciel de gestion pour transport routier.