Par où commencer
Telebib2 est la norme belge d'échange de données du secteur de l'assurance : contrats, sinistres, échanges financiers, parties prenantes. Elle existe en deux représentations techniques : EDIFACT, en production depuis trente ans et JSON, qui entre en service le 1er janvier 2027. Les deux décrivent les mêmes messages et évoluent ensemble.
Cette documentation suit un parcours : comprendre ce qu'est la norme, apprendre à lire un message, savoir où trouver ce dont on a besoin, écrire et valider son premier échange, puis suivre les releases dans la durée. Vous pouvez la lire dans l'ordre, ou entrer par la porte qui correspond à votre situation.
Trois entrées, selon ce que vous cherchez
Vous découvrez Telebib2. Commencez par comprendre ce que la norme couvre et pourquoi elle existe en deux formats, puis par le pivot, c'est lui qui garantit que les deux représentations ne divergent pas.
Vous devez implémenter un échange. Allez droit à la structure d'un message, puis à la validation. Vous aurez besoin d'un validateur correctement configuré avant tout le reste : c'est le point sur lequel une implémentation démarre bien ou mal.
Vous maintenez une intégration existante. Les articles sur les releases et la trajectoire répondent aux questions qui se posent dans la durée : ce qui change, à quel rythme et ce que le calendrier JSON implique -ou n'implique pas- pour votre chaîne EDIFACT.
Le parcours complet
1. Comprendre. Ce qu'est la norme, pourquoi elle existe en deux formats et comment les deux restent alignés. C'est la partie à lire une fois, pour ne plus y revenir.
- Introduction EDIFACT : les principes de la représentation historique.
- Telebib2 en JSON : pourquoi : ce qui a motivé la seconde représentation et ce qu'elle ne change pas.
- Le pivot : EDIFACT, MCI, JSON : ce qui garantit que les deux décrivent le même message.
2. Lire un message. La structure concrète d'un échange JSON et la correspondance avec ce que vous connaissez d'EDIFACT.
- Anatomie d'un message JSON : enveloppe, datablocks, contenu métier.
- Du segment EDIFACT à la propriété JSON : les cinq décisions de transposition.
3. S'orienter. Où trouver un message, un composant, une liste de valeurs. Sur le site pour comprendre ou dans le registre pour valider.
4. Écrire et valider. La partie opérationnelle. Elle commence par le choix du validateur, parce qu'un validateur mal configuré donne l'illusion que tout va bien.
- Valider un message : la chaîne, les bibliothèques, les erreurs.
- Les décimaux sont des chaînes : la convention qui surprend le plus et pourquoi.
- Hints & tips : les erreurs des premières semaines, rassemblées.
5. Suivre les releases. Ce qui change, à quel rythme et comment lire les numéros sans en tirer de fausses conclusions.
Référence. Le glossaire, à garder ouvert dans un onglet.
Quatre choses à savoir avant de commencer
Si vous ne deviez retenir que quatre points de toute cette documentation, ce seraient ceux-ci. Chacun est développé dans l'article correspondant.
Le deuxième mérite d'être souligné, parce qu'il ne se voit pas : un validateur configuré sur une version antérieure au draft 2020-12 ignore le mot-clé qui ferme les schémas. Il accepte alors sans broncher des messages truffés de propriétés inexistantes. Tout passe au vert et rien n'est vérifié.
Les deux adresses de la norme
Une distinction à poser une fois pour toutes : le site est fait pour être lu par des humains qui cherchent à comprendre, le registre pour être consommé par des programmes qui valident. Le premier vous sert pendant la conception, le second en production.
Votre code ne doit jamais lire le site : les pages sont faites pour l'œil, leur structure peut changer sans préavis et rien n'y est contractuel. Le registre, lui, est un point de distribution stable dont chaque fichier est immuable une fois publié.