Telebib2 en JSON : pourquoi

Telebib2 existe désormais en deux représentations techniques : EDIFACT, en production depuis trente ans et JSON, qui entre en service le 1^er janvier 2027. Les deux décrivent les mêmes messages, avec la même sémantique métier et évoluent ensemble à chaque release. Cette page explique ce qui a motivé la seconde et surtout ce qu'elle ne remet pas en cause.

Disons-le d'emblée : EDIFACT fonctionne. Il transporte les échanges du secteur depuis trois décennies, il est complet, il est éprouvé et rien de ce qui suit ne lui reproche quoi que ce soit sur le plan technique.

Le problème est ailleurs, il est d'ordre pratique. Pour lire un message EDIFACT, il faut connaître EDIFACT : les tags, les qualifiants, les annuaires, les règles de syntaxe. C'est un savoir spécialisé, qui s'acquiert, mais dont la maîtrise est de plus en plus rare sur le marché.

Chaque nouvelle intégration payait donc un droit d'entrée avant même d'écrire la première ligne utile. Pour un acteur qui rejoint le secteur ou pour une équipe qui refait son système, ce droit d'entrée pèse lourd, parfois plus lourd que l'intégration elle-même.

Un message qui se lit sans manuel. Les noms de propriétés portent le sens, les valeurs de listes sont écrites en toutes lettres. Un développeur qui n'a jamais entendu parler de Telebib2 comprend la structure d'un message à la première lecture.

Une validation qui se vérifie par la machine. JSON Schema n'est pas de la documentation : c'est un contrat exécutable. Une bibliothèque standard répond par oui ou non, avec le détail des écarts. Aucune convention hors bande, aucun accord bilatéral à documenter séparément.

De l'outillage partout. Tous les langages courants ont une bibliothèque JSON Schema mature, gratuite et maintenue. Il n'y a rien à acheter, rien de spécifique au secteur à installer.

C'est le point le plus important de cette page et celui qui rassure le plus les équipes en place.

Le modèle métier est identique. Le contrat, l'objet de risque, la garantie, la franchise, le sinistre, la quittance : la cascade contractuelle et les entités du modèle sont les mêmes. Ce qui était vrai en EDIFACT le reste.

Les messages sont les mêmes. Un M0151 reste un certificat de sinistralité. Il porte les mêmes informations, avec les mêmes règles d'obligation. Le pivot dont dérivent les deux représentations est unique : c'est le MCI.

Les listes de valeurs sont les mêmes. Les valeurs autorisées, leurs libellés bilingues, les organismes qui les arbitrent : rien de tout cela n'a bougé.

La gouvernance et le cycle de release sont les mêmes. Une seule instance décide, une seule cadence, une seule liste de changements par release, valable pour les deux représentations.

Ce pivot mérite mieux qu'un paragraphe : un article entier lui est consacré, parce que c'est lui qui rend crédible l'affirmation « les deux formats décrivent le même message ».

Soyons honnêtes sur le coût. Passer au JSON demande d'apprendre un petit nombre de conventions qui ne se devinent pas : les valeurs à virgule sont des chaînes, les schémas refusent toute propriété non prévue, la version d'un message est un entier alors que son code est une chaîne.

Ce n'est pas beaucoup, mais ce n'est pas rien et chacune de ces conventions coûte du temps à qui la découvre en production. La série d'articles qui suit existe pour que vous les rencontriez ici plutôt que là.

En contrepartie, tout le reste : la résolution des qualifiants, la connaissance des annuaires, les règles de syntaxe, disparaît du périmètre de votre équipe.

Une dernière chose, qui n'est pas anecdotique : les schémas JSON sont publiés en fichiers statiques, à des adresses stables et un fichier publié n'est jamais modifié. Ce que vous validez aujourd'hui, vous le validerez à l'identique dans dix ans. C'est la garantie qui rend le reste utilisable.