— 16 mai 2026 · 9 min de lecture

IATA ONE Record : l'avenir de l'EDI cargo aérien

Le cargo aérien repose depuis cinquante ans sur des messages EDI propriétaires — Cargo-IMP, puis Cargo-XML. IATA développe depuis 2018 un nouveau standard, ONE Record, qui rompt avec la logique du message pour adopter celle du graphe lié. Cet article cadre l'évolution, son calendrier et ce qu'elle change pour les intégrateurs.

De Cargo-IMP à Cargo-XML : cinquante ans de messages

Le standard historique du cargo aérien s'appelle Cargo-IMP (Cargo Interchange Message Procedures), né dans les années 1970, conçu autour de messages structurés en lignes (le célèbre FWB pour la déclaration de cargaison, le FFM pour le manifeste vol, le FHL pour la liste des house waybills). Le format est plat, taillé pour des liaisons SITA et X.25, et reste largement opérationnel dans les hubs cargo en 2026. IATA a publié dès 2010 une version XML — Cargo-XML — pour moderniser les échanges sans rompre la sémantique. Cargo-XML est aujourd'hui en version 4 (publiée en 2022), avec une trentaine de messages côté shipper, transitaire, transporteur, sol et douane.

Cargo-IMP et Cargo-XML partagent le même modèle : un message est une photographie atomique d'un événement (réservation, manifeste, status update), envoyée d'un acteur à un autre. Si dix parties prenantes sont impliquées dans une expédition (shipper, transitaire, hub origine, compagnie, hub transit, hub destination, transitaire arrivée, douane, consignee, et le truck final), chacune doit reconstituer son propre référentiel local à partir des messages reçus. Le modèle est message-centric ; l'état partagé n'existe nulle part.

ONE Record : la rupture du data sharing

ONE Record retourne ce paradigme. L'idée fondatrice, publiée en 2018 dans la Resolution 672 de l'IATA Cargo Services Conference, est que chaque acteur du transport publie ses données sous forme d'un graphe lié (JSON-LD), accessible aux autres acteurs autorisés via API. Le standard repose sur un data model ontologique (Logistics Data Model) décrivant les concepts du cargo (Shipment, Waybill, Piece, TransportMovement, Booking, etc.) avec leurs propriétés et leurs relations. Chaque acteur héberge un Logistics Object server qui expose ces objets via une API REST, et les acteurs s'abonnent aux changements d'état.

L'analogie la plus parlante est celle d'une blockchain sans blockchain ou d'un Notion partagé entre acteurs : au lieu d'envoyer des copies de l'objet à chaque mise à jour, on partage l'accès à un objet canonique qui évolue dans le temps. Les change requests ONE Record formalisent les mises à jour proposées, et chaque acteur peut auditer la chronologie complète d'une expédition.

Calendrier d'adoption : pilotes, transition, cible

IATA a lancé un ONE Record Pilot avec une vingtaine de compagnies entre 2020 et 2023 (Air France-KLM, Cathay Pacific, Lufthansa Cargo, Qatar Airways Cargo, ANA, et d'autres). Les premières mises en production opérationnelles couvrent des cas d'usage ciblés : notifications de status à partir de hubs, partage d'informations avec autorités douanières (notamment l'expérimentation avec la Commission européenne via le projet eFTI), partage de température et de capteurs IoT pour le fret pharmaceutique.

La résolution IATA prévoit une transition graduelle : ONE Record et Cargo-XML coexistent durant la phase de migration, et IATA n'a pas annoncé de date couperet de retrait des messages Cargo-XML. La déprécation effective dépendra de la pénétration des Logistics Object servers chez les transitaires et les compagnies, qui doit en pratique atteindre une masse critique avant que les partenaires legacy ne décident de basculer.

Ce que ça change techniquement

Pour un intégrateur EDI cargo, la bascule ne se résume pas à un changement de format : c'est un changement de modèle opératoire. Quatre conséquences majeures :

• De batch à event-driven. Là où un FFM envoyé en SITA suivait une cadence par vol, un changement d'attribut sur un Shipment ONE Record génère un webhook quasi instantané. Les architectures de traitement EDI cargo doivent basculer vers un modèle de réception d'événements et de réconciliation asynchrone.
• Authentification mutuelle obligatoire. Chaque appel à un Logistics Object server passe par OAuth 2.0 avec scopes, et chaque acteur publie sa propre API gateway. La discipline de gestion des credentials et de rotation des tokens devient une compétence opérationnelle quotidienne.
• Référentiel sémantique partagé. Le Logistics Data Model est publié sous forme d'une ontologie OWL/JSON-LD ; les développeurs peuvent générer du code TypeScript ou Python à partir du schéma, et la traduction entre objets internes et objets ONE Record devient testable de bout en bout.
• Audit et chronologie natifs. Chaque modification d'un Logistics Object est tracée par construction ; la conformité aux exigences douanières (notamment ICS2 dans l'UE depuis 2023, expansion 2024-2025) devient un effet de bord du modèle, et non une fonctionnalité à ajouter.

Conclusion : une migration patiente, mais structurelle

ONE Record est probablement la transformation la plus profonde du paysage EDI cargo depuis la naissance de Cargo-IMP. La rupture ne tient pas au format mais à l'inversion du paradigme : on ne s'échange plus des messages, on partage l'accès à des objets canoniques. Pour les éditeurs et intégrateurs en 2026, le bon réflexe est de commencer une exploration sandbox avec un Logistics Object server open source (plusieurs implémentations existent), d'identifier un ou deux partenaires pilote, et de cartographier le périmètre des messages Cargo-XML qui peuvent être projetés en équivalents ONE Record.

Pour creuser, l'architecture d'intégration moderne donne le cadre général dans lequel s'inscrit cette bascule, et l'analyse de la convergence EDI/API détaille pourquoi un modèle event-driven sur des ressources REST cohabite désormais sans heurt avec l'EDI historique.