Du segment EDIFACT à la propriété JSON

EDIFACT décrit un message comme une suite de segments codés ; JSON le décrit comme un objet de propriétés nommées. Passer de l'un à l'autre n'est pas une traduction mot à mot - c'est une série de décisions, prises une fois pour toutes et appliquées à l'ensemble de la norme. En voici les principales, celles qu'il faut avoir en tête pour lire un schéma sans se demander d'où vient chaque chose.

En EDIFACT, le sens d'une donnée naît de la rencontre entre un tag de trois lettres et un qualifiant. DTM annonce une date ; c'est le qualifiant 008 qui en fait une date d'effet. Sans l'annuaire des qualifiants sous les yeux, DTM+008 ne dit rien.

En JSON, ce couple est résolu à la source : il devient un nom de propriété. inceptionDate se lit sans annuaire et un développeur qui n'a jamais ouvert une spécification Telebib2 comprend ce qu'il manipule.

Le nom porte donc désormais tout le sens. C'est une responsabilité : un nom mal choisi ne se rattrape pas par un commentaire, puisque personne ne va chercher le commentaire.

Le même principe s'applique aux valeurs elles-mêmes. Là où EDIFACT transmet un code numérique qu'il faut résoudre dans une liste, JSON transmet directement la valeur lisible. Chaque liste devient un fichier de schéma autonome, avec son enum et ses libellés français et néerlandais dans x-enum-labels.

Les deux éléments qui accompagnaient les listes en EDIFACT survivent, parce qu'ils restent nécessaires : X901 devient codeListIdentifier (quelle liste est utilisée) et X902 devient codeListResponsibleAgencyCoded (qui la maintient).

Une réserve, cependant. Cette lisibilité vaut pour les listes que Telebib2 arbitre (plus de deux cent soixante), toutes déclarées avec un enum. Les listes officielles, celles qui viennent d'un organisme extérieur (SPF, DIV, ...), sont reprises telles quelles : elles conservent les codes d'origine et s'écrivent avec oneOf. Un code pays s'écrit "B", un type de carburant "1".

Une dernière particularité, qui déroute à la première rencontre : un degré bonus-malus s'écrit "_11" et non "11". L'underscore est hérité de la nomenclature XML dont ces noms proviennent (et un nom d'élément XML ne peut pas commencer par un chiffre). Le libellé, lui, affiche bien 11.

EDIFACT organise ses segments en groupes imbriqués, délimités par des segments d'ouverture et de fermeture. Or ces délimiteurs ne transportent aucune donnée : ce sont des marqueurs de structure, pas de sens.

Les reproduire en JSON aurait donné des objets enveloppes vides, dont la seule raison d'être aurait été de refléter une mécanique de transport. Pire : cette imbrication varie d'une version de MIG à l'autre, parfois pour des raisons purement techniques. Un consommateur aurait vu sa structure changer sans qu'aucune donnée métier n'ait bougé.

Tous les segments porteurs de données sont donc aplatis dans content. La structure JSON suit la logique métier, pas la topologie du transport.

Certains segments reviennent partout. RFF porte une référence (de police, de sinistre, de paiement) et on le retrouve dans presque tous les messages. Plutôt que de redécrire sa forme à chaque endroit, elle est définie une fois dans un composant partagé et référencée par tous les schémas qui en ont besoin.

Une décision mérite d'être signalée ici, parce qu'elle surprend à la première lecture. Le composant reference expose toujours deux propriétés, referenceContent et statusCoded, même dans les messages où le statut n'existe pas. On aurait pu simplifier ces cas en une simple chaîne de caractères. Ce n'est pas ce qui a été fait, pour une raison très concrète : votre code n'a alors qu'une seule forme à traiter, partout. Sans cela, chaque référence exigerait de savoir à l'avance si l'on reçoit un texte ou un objet et l'erreur serait silencieuse en JSON, mais bloquante à la génération de l'EDIFACT.

Le même raisonnement a produit partyIdentification, un tableau qui accueille sans modification les 65 façons dont Telebib2 identifie une partie.

Deux choses ne passent pas la frontière et il vaut mieux le savoir tôt.

Les nombres à virgule. EDIFACT accompagne chaque valeur décimale d'un qualifiant qui annonce son nombre de décimales. JSON n'a rien de tel et le nombre flottant ne représente pas exactement les fractions décimales. Toutes les valeurs à virgule sont donc portées par des chaînes : "1234.56", jamais 1234.56. Un article entier est consacré à cette décision.

Les codes de segment eux-mêmes. Vous ne trouverez, dans aucun schéma publié, la mention d'un tag ou d'un qualifiant EDIFACT. Ce n'est pas un oubli : les rares descriptions qui en contenaient encore ont été nettoyées. La correspondance entre les deux représentations existe, mais elle vit dans l'outillage de la norme et non pas dans les schémas.

La raison est simple. Un développeur qui implémente la norme JSON en 2027 n'a aucune raison d'apprendre EDIFACT pour lire un schéma. Faire figurer DTM+008 à côté de inceptionDate ne l'aiderait pas ; cela lui demanderait d'ouvrir un annuaire dont on vient précisément de le libérer.

Un fil conducteur relie ces cinq décisions : déplacer l'effort du lecteur vers le producteur de la norme. Résoudre les qualifiants, nommer les valeurs, supprimer les enveloppes vides, unifier les formes récurrentes. Chacun de ces choix a coûté des arbitrages aux groupes de travail de la normalisation pour que lire un message n'en coûte aucun.

C'est aussi ce qui explique qu'on ne puisse pas générer mécaniquement l'un depuis l'autre sans connaître toutes ces règles : chaque correspondance a demandé une décision. Elles sont consignées et les plus structurantes reviennent dans les articles consacrés au registre.