# Connecter son transitaire à son SI : API, EDI et intégrations ERP/TMS

Une intégration transport se prépare en définissant les événements utiles, les références communes et les règles de mise à jour. Le choix entre portail, export, API et EDI dépend ensuite du besoin et des capacités documentées du prestataire. Un test sur des événements corrigés, manquants ou reçus en double permet de vérifier le fonctionnement avant déploiement.

[Source](https://www.ovrsea.com/insights/guides/connecter-transitaire-erp-tms-api)

Language: fr
Updated: 2026-10-13

## Comment OVRSEA vous accompagne sur ce sujet

OVRSEA accompagne les projets de connexion des données transport aux outils des chargeurs, notamment leur ERP ou leur TMS. Le projet part des informations nécessaires à vos équipes et des contraintes de vos systèmes. Les moyens de transmission, les données disponibles et les adaptations à prévoir sont précisés pour votre organisation ; portail, export, API et EDI restent des dispositifs à distinguer.

Connecter le transitaire à votre système d'information commence par définir les données à échanger, leur fréquence et les responsables de leur qualité. Une connexion peut limiter les ressaisies, à condition de traiter les corrections et les erreurs de transmission.

## Quelles données faut-il définir avant de choisir une API ou un export ?

Commencez par les décisions que la donnée doit permettre : préparer une réception, relancer un fournisseur, rapprocher une facture ou expliquer un retard. Pour chaque décision, identifiez le système destinataire et l'équipe qui l'utilisera. L'ERP, progiciel de gestion de l'entreprise, et le TMS, système de gestion du transport, n'ont pas nécessairement besoin du même niveau de détail.

Établissez ensuite un dictionnaire des données avec le prestataire. Pour chaque champ, précisez sa définition, sa source, son format, son caractère obligatoire et le traitement d'une valeur absente. Une date d'arrivée au port ne doit pas alimenter par défaut le champ de livraison à l'entrepôt. La [DCSA propose un modèle commun d'événements de suivi](https://dcsa.org/standards/track-and-trace) qui peut aider à structurer cette discussion. L'utilisation d'un vocabulaire commun ne démontre pas, à elle seule, la compatibilité entre deux outils.

| Donnée à cadrer | Question de validation |
| --- | --- |
| Référence de commande | Une commande peut-elle être liée à plusieurs expéditions ? |
| Booking, ou réservation de transport | Que devient le lien après annulation ou changement de réservation ? |
| Conteneur | Comment rattacher plusieurs conteneurs et leurs événements au même dossier ? |
| Événement et lieu | L'arrivée concerne-t-elle le port, un terminal ou l'entrepôt ? |
| Date et statut | La date est-elle prévue, révisée ou constatée ? |
| Source et mise à jour | Qui fournit l'information et quand a-t-elle été reçue ? |

Les statuts de transport ne sont qu'une partie du besoin. Cadrez aussi les coûts, les factures, les documents et, si nécessaire, les données d'émissions. Pour chaque donnée, vérifiez sa disponibilité, son format, les droits de consultation et sa fréquence de mise à jour. Les [documents maritimes et leurs échéances](https://www.ovrsea.com/insights/guides/documents-maritimes-cut-offs-si-vgm-bl) demandent notamment de distinguer une version reçue d'une version validée.

## Comment distinguer consultation, transfert de fichiers et intégration ?

Un portail permet aux utilisateurs autorisés de consulter des dossiers. Un export fournit des données dans un fichier exploitable. Une API, interface de programmation, permet à des logiciels d'échanger selon des règles documentées. L'EDI, échange de données informatisé, utilise des messages structurés ; [UN/EDIFACT est un référentiel de l'UNECE pour ces échanges](https://unece.org/trade/uncefact/unedifact-introduction-and-rules).

Choisissez le mode d'échange à partir de la fréquence nécessaire, des outils existants et du coût de maintenance. Un export peut suffire pour une revue périodique. Une intégration nécessite aussi de préciser l'authentification, les droits, les formats et les responsabilités de support. Aucun volume universel d'expéditions ne rend une API obligatoire.

Si des notifications automatiques, appelées webhooks, sont proposées, demandez quels événements les déclenchent et comment les messages non reçus sont récupérés. Une API ne suppose ni la présence de webhooks ni une actualisation immédiate des données des transporteurs. Le délai entre l'événement physique et sa disponibilité dans votre outil doit être étudié séparément.

## Comment conserver les dates initiales et traiter les corrections ?

Séparez la date prévue à la réservation, la dernière estimation et la date constatée. Conservez aussi la date de réception de l'information et le fuseau horaire. Cette distinction permet de comprendre à la fois le déroulement du transport et la fraîcheur des données. Elle complète la méthode du [guide de mesure de la qualité de service](https://www.ovrsea.com/insights/guides/mesurer-qualite-de-service-transitaire).

Demandez comment une correction remplace ou complète une information antérieure. Le système destinataire doit pouvoir reconnaître un message déjà reçu et éviter de créer un nouvel événement à chaque renvoi. Les règles doivent aussi prévoir un événement arrivé tardivement ou un conteneur rattaché à une nouvelle réservation.

Exemple fictif : un fournisseur transmet une nouvelle prévision d'arrivée, puis un ancien message est reçu après cette mise à jour. Le test doit vérifier que la prévision ancienne ne remplace pas silencieusement la plus récente. La règle retenue, fondée sur les dates et versions disponibles, doit être décrite et vérifiable.

## Quels scénarios tester avant la mise en service ?

Préparez un jeu d'essai avec les équipes métier et informatiques. Pour chaque scénario, notez le résultat attendu puis le résultat observé. Testez notamment :

- une commande répartie entre plusieurs expéditions ;
- un départ révisé suivi d'une arrivée constatée ;
- un message reçu en double ou dans un ordre différent ;
- un champ obligatoire manquant et un événement inconnu ;
- une interruption d'échange, puis la récupération des données manquantes ;
- un utilisateur qui tente de consulter une entité hors de son périmètre.

Intégrez au cadrage les [preuves de sécurité et de continuité du prestataire](https://www.ovrsea.com/insights/guides/preuves-securite-conformite-transitaire), en précisant les systèmes et les échanges concernés.

Pour le lancement, attribuez un responsable à chaque anomalie et définissez le canal de secours. Prévoyez aussi la procédure de changement de version : préavis, tests de compatibilité et retour à la situation précédente si nécessaire. Un environnement de test séparé est utile lorsqu'il existe ; sa disponibilité et son contenu doivent être confirmés.

Pour cadrer un projet avec OVRSEA, transmettez la liste des événements attendus, un exemple de fichier cible et les contraintes de votre ERP ou TMS. Cet échange permettra d'identifier les modes de transmission à étudier, le périmètre disponible et les adaptations éventuelles.

[Parler à un expert transport](https://www.ovrsea.com/insights/parler-a-un-expert).

## FAQ

### Quelle différence entre une API et un échange EDI ?

Une API permet à des logiciels d'échanger des données selon une interface documentée. L'EDI repose sur des messages structurés entre systèmes. Le choix dépend des outils, des données et de la fréquence attendue, avec des règles de reprise à vérifier dans les deux cas.

### Quelles données transport peut-on prévoir dans une intégration ERP ou TMS ?

Le cadrage peut porter sur les références de commande, les réservations, les conteneurs, les dates, les documents et les coûts. La disponibilité de chaque champ, son format et sa source doivent être confirmés avec le prestataire avant de développer l'échange.

### Un portail de suivi suffit-il pour intégrer les données transport ?

Un portail répond à un besoin de consultation. Pour alimenter un autre outil, il faut vérifier les exports disponibles ou les possibilités d'échange entre systèmes. Le choix dépend des données attendues et de leur fréquence de mise à jour.

### Une API transport fournit-elle forcément des données en temps réel ?

Une API ne garantit pas que l'événement physique soit immédiatement disponible. La fraîcheur dépend aussi des sources, de leur transmission et du traitement par chaque système. Demandez comment ces délais sont mesurés et quelles limites s'appliquent.

### Pourquoi tester les messages reçus en double ?

Un même événement peut être transmis à nouveau lors d'une reprise ou d'une correction. Les tests doivent vérifier que ces messages ne créent pas de doublons et qu'une donnée ancienne ne remplace pas une information plus récente.