Sélectionnez votre langue

Trajectoire EDIFACT et JSON

Suivre les releases

Trajectoire EDIFACT et JSON

Telebib2 existe en deux représentations techniques. Le JSON est la représentation cible et doit être privilégié pour toute nouvelle implémentation. L'EDIFACT reste pleinement documenté et supporté pendant toute la durée de la transition. Les deux décrivent les mêmes messages et évoluent ensemble à chaque release. Cette page précise ce que cela implique selon la situation dans laquelle vous vous trouvez.

Une coexistence, pas un remplacement

Il ne s'agit pas d'une migration au sens habituel : il n'y a ni bascule, ni gel de l'ancien format, ni date couperet annoncée pour EDIFACT. Les deux représentations sont maintenues en parallèle, par la même instance, selon le même calendrier.

Ce n'est pas un compromis politique : c'est ce que la structure de la norme permet. Les deux représentations dérivent d'un pivot commun, le MCI, qui décrit le contenu d'un message indépendamment de sa syntaxe. Quand une release ajoute une donnée à un message, elle l'ajoute au pivot, et les deux représentations en héritent.

La conséquence est forte et vaut d'être énoncée clairement : un message reste le même message quelle que soit sa représentation. Mêmes données, mêmes règles d'obligation, mêmes listes de valeurs. Ce qui diffère est la syntaxe, jamais le contenu.

Une source, deux sorties, une cadence. Chaque release annuelle alimente le pivot MCI, qui décrit le contenu d'un message indépendamment de sa syntaxe. Du MCI dérivent deux représentations maintenues en parallèle : le MIG EDIFACT, en production, et le schéma JSON, en production au 1er janvier 2027. Une seule liste de changements vaut pour les deux. Ce qui diffère est la syntaxe, jamais le contenu : un message reste le même message.
Fig. 01 — Une source, deux sorties, une cadence

Où en est le JSON aujourd'hui

Le registre est publié et complet pour la release cible, mais porte encore le statut pre-release. Concrètement : les schémas sont là, ils sont stables, ils sont validés mais la norme JSON n'entre officiellement en service qu'au 1er janvier 2027.

Ce statut n'est pas un avertissement sur la qualité. Chaque message publié est accompagné de deux exemples de référence, validés sur deux moteurs indépendants et les rapports sont publiés avec les schémas. Le travail d'implémentation peut commencer dès maintenant.

Ce que le statut signifie, c'est que les groupes de travail de la normalisation se réservent la possibilité d'ajuster avant la mise en service. Les évolutions restantes sont documentées dans la liste des changements du registre, comme toutes les autres.

L'état des deux représentations. EDIFACT est en production, pleinement documenté et supporté pendant toute la transition, sans date de fin annoncée. Le JSON entre en production le 1er janvier 2027 : son registre est publié avec le statut pre-release, ses schémas sont stables et validés sur deux moteurs indépendants. Au go-live, seul le statut change. Le travail d'implémentation peut commencer dès maintenant.
Fig. 02 — L'état des deux représentations

Que faire, selon votre situation

Vous démarrez une nouvelle intégration. Partez sur le JSON. C'est la représentation cible, l'outillage est disponible dans tous les langages courants et vous n'aurez pas à repayer le coût d'entrée plus tard.

Vous exploitez une chaîne EDIFACT qui fonctionne. Rien ne presse. EDIFACT reste supporté, continue d'évoluer à chaque release et aucune date de fin n'est annoncée. Une réécriture qui n'apporte rien d'autre qu'un changement de syntaxe n'est pas un bon investissement.

Vous refondez un système existant. C'est le moment de basculer : le coût marginal du JSON dans une refonte est faible et vous sortez du besoin de compétence EDIFACT.

Vous devrez faire coexister les deux. Cas le plus fréquent en pratique. Le pivot MCI est votre allié : il garantit que les deux représentations portent la même information et la fiche d'un message sur le site relie les deux implémentations. La table de compatibilité fait le lien entre release JSON et release EDIFACT.

Le lien entre les deux calendriers

{

  "x943": "M0151",

  "x944": 3,

  "migName": "M0151_202701",

  "edifactRelease": "01.01.2027",

  "jsonSchema": "community/M0151.202701.json",

  "validFrom": "2027-01-01"

}

Ce qui distingue les deux dans un message

{ "exchangeUnitIssuingFormat": "json" }
Que faire, selon votre situation. Pour une nouvelle intégration, partez sur le JSON. Si votre chaîne EDIFACT fonctionne, rien ne presse. Si vous refondez un système existant, c'est le moment de basculer. Si vous devez faire coexister les deux, le cas le plus fréquent, le pivot MCI garantit que les deux représentations portent la même information. Le JSON est là pour que les nouvelles intégrations coûtent moins cher, pas pour rendre obsolète ce qui fonctionne.
Fig. 03 — Que faire, selon votre situation
Le lien entre les deux calendriers. Une entrée de la table de compatibilité part du couple qui identifie le message, x943 vaut M0151 et x944 vaut 3, et donne d'un côté le nom du MIG et la release EDIFACT, de l'autre le fichier de schéma JSON et sa date d'entrée en vigueur. Dans un message, c'est la propriété exchangeUnitIssuingFormat qui indique la représentation utilisée. Un seul couple code plus version, deux calendriers de mise en service : la table fait le pont entre les deux.
Fig. 04 — Le lien entre les deux calendriers

Trois idées reçues

« Le JSON est une transposition automatique de l'EDIFACT. » Non. C'est un modèle à part entière : les qualifiants sont résolus en noms, les groupes de transport supprimés, les segments récurrents unifiés en composants. Chaque correspondance a demandé un arbitrage. Le format JSIfact, lui, est bien une transposition littérale (mais c'est un format distinct, que ce registre ne produit pas).

« EDIFACT va être gelé. » Non. Il évolue à chaque release, au même rythme que le JSON, à partir du même pivot.

« Il faudra tout migrer avant 2027. » Non. Le 1er janvier 2027 est la date à laquelle la norme JSON entre en service, pas une date de sortie de service de l'EDIFACT.

Trois formats à ne pas confondre. EDIFACT est la représentation historique, faite de segments, de tags et de qualifiants. JSIfact est une transposition littérale de l'EDIFACT en JSON, un format d'émission distinct que ce registre ne produit pas. La norme JSON Telebib2 est un modèle à part entière : les qualifiants y sont résolus en noms, les groupes de transport supprimés, les segments récurrents unifiés en composants. Ce n'est pas une transposition automatique : chaque correspondance a demandé un arbitrage.
Fig. 05 — Trois formats à ne pas confondre

La trajectoire tient donc en une phrase : le JSON est là pour que les nouvelles intégrations coûtent moins cher, pas pour rendre obsolète ce qui fonctionne. Le jour où l'EDIFACT sera moins utilisé que le JSON, la question de son avenir se posera et elle sera alors tranchée par le Comité stratégique de la normalisation, annoncée à l'avance et jamais imposée par un fichier qui aurait changé sans prévenir.

Contact

À propos de Telebib2