DELAIS D’IMPLEMENTATION DES ECHANGES ENTRE LES APPLICATIONS ENTREPRISES D’ASSURANCES ET LES LOGICIELS COURTIERS
1. INTRODUCTION
1.1. Convention entre les parties
1.1.1 Parties signataires
Cette convention est établie entre :
- Les entreprises d’assurances représentées par Assuralia
- Des développeurs de logiciels courtiers (des fournisseurs de logiciels courtiers et des courtiers ayant leurs propres systèmes de gestion)
- Le Centre TELEBIB2
- Les Fédérations de courtiers (Feprabel, FVF, UPCA)
- Les courtiers ne participent pas à cette convention à titre individuel. Ils y participent par l’intermédiaire de leur fournisseur de logiciel ou de leurs Fédérations.
1.1.2 Le rôle des différents intervenants
- Les entreprises d’assurances et les développeurs de logiciels courtiers sont les acteurs exécutifs de la convention.
- Assuralia et les Fédérations de courtiers veillent à l’aspect sectoriel.
- Le Centre TELEBIB2 publie les paramètres et le contenu des releases, mais n’intervient pas dans la définition du contenu de ceux-ci.
1.1.3 Durée de la convention
Cette convention est conclue pour une durée indéterminée. Elle entre en vigueur à la date de sa signature.
Chaque partie peut renoncer à la convention moyennant un préavis de 6 mois qui doit être signifié par écrit aux autres parties de la convention.
1.1.4 Modification
Seuls les souscripteurs peuvent modifier la convention. Ceci peut se faire à tout moment.
Les modifications ne peuvent être apportées que par consensus de tous les souscripteurs.
En cas de désaccord, chaque souscripteur peut sortir de la convention sans préavis. Il est cependant tenu de signifier sa sortie de la convention par écrit aux autres souscripteurs. Si les souscripteurs ne trouvent pas de consensus, la procédure de recours est activée.
1.2. Domaine/Scope
Cette convention couvre uniquement le processus qui s’écoule entre le moment où, un Message Content Inventory (MCI) se trouve en « status 2 » et sa mise en production. L’objet de cette convention se limite aux échanges électroniques entre les applications entreprises d’assurances et les logiciels courtiers.
1.3. Définitions
Release :
C’est l’inventaire des MCIs implémentés ou à implémenter avant une certaine date (la date de release). Le release est identifié par le mois (année-mois) à partir duquel le release est considéré comme étant utilisé.
Date de release :
Date de fin de mise en production d’un release.
Cut-off date :
Date à laquelle le contenu d’un release est défini.
Date de démarrage de la mise en production d’un release :
Date fixe à laquelle :
- L’émetteur peut au plus tôt commencer à émettre des messages repris dans un release ET
- Le destinataire doit au plus tard être prêt pour garantir la compatibilité avec les messages du release en implémentation.
Date de mise en production d’un MCI :
Date à laquelle :
- L’émetteur envoie un message pour la première fois ET
- Le destinataire est capable de recevoir et traiter les messages du release en implémentation et de garantir la compatibilité avec les messages en usage.
Période d’implémentation d’un release :
Période à durée fixe qui s’écoule entre la date cut-off et la date de release. Cette période est exprimée en nombre de mois.
Période de développement des mesures de compatibilité d’un release :
Période (à durée fixe) qui s’écoule entre la date cut-off et la date de démarrage de la mise en production. Cette période est exprimée en nombre de mois.
Période de mise en production d’un release :
Période (à durée fixe) qui s’écoule entre la date de démarrage de la mise en production et la date de release. Cette période est exprimée en nombre de mois.
Périodicité de release:
Intervalle fixe entre 2 releases successifs. La périodicité est exprimée en nombre de mois.
2. OBJECTIFS
Les objectifs de la convention sont les suivants :
2.1. Harmoniser et synchroniser l’implémentation et la mise en production d’un release
2.1.1 Harmoniser
Echanger le plus possible de nouveaux MCIs ou MCIs modifiés que possible entre le maximum d’utilisateurs.
2.1.2 Synchroniser
Pour un MCI, la mise en production se fait pendant la période de mise en production d’un release, mais au libre choix de chaque utilisateur.
3. OBJET DE LA CONVENTION
3.1. Définition et publication des paramètres de la convention
3.1.1 Définition de la périodicité des releases
Le Groupe de Normalisation définit de commun accord la périodicité des releases.
En principe, ce paramètre est défini avant la signature de cette convention pour toute sa durée. Néanmoins, le Groupe de Normalisation peut décider de le modifier.
3.1.2 Définition de la période d’implémentation
Le Groupe de Normalisation définit de commun accord la période d’implémentation.
En principe, ce paramètre est défini avant la signature de cette convention pour toute sa durée. Néanmoins, le Groupe de Normalisation peut décider de le modifier.
3.1.3 Définition de la période de développement des mesures de compatibilité
Le Groupe de Normalisation définit de commun accord la période de développement des mesures de compatibilité.
En principe, ce paramètre est défini avant la signature de cette convention.
Néanmoins, le Groupe de Normalisation peut décider de le modifier en fonction du contenu du release.
3.1.4 Définition de la période de mise en production
La durée de la période de mise en production est calculée sur base des paramètres définis dans les art. 3.1.2 et 3.1.3.
3.1.5 Publication des paramètres de la convention
Les paramètres sont publiés sur le site web TELEBIB2.
3.2. Traitement des releases
3.2.1 La composition du release
Deux semaines avant la date cut-off, le Groupe de Normalisation définit le contenu du release. Il sélectionne parmi tous les MCIs qui ont changé de version et portent un
« status 2 ». L’implémentation doit être réalisable pour la date du release. La liste des MCIs retenus doit être logique, cohérente et réaliste.
Pour la dépréciation d’un MCI, il faut veiller à ce que les nouveaux MCIs qui le remplacent soient implémentés en même temps.
Les MCIs dont le temps nécessaire pour l’implémentation dépasse la date de ce release, sont déjà projetés dans un release futur.
Le contenu du release tel que défini par le Groupe de Normalisation doit être accepté par tous les utilisateurs concernés avant la date cut-off.
3.2.2 La publication du contenu du release
Le résultat de la définition du contenu du release est publié sur site web TELEBIB2.
3.2.3 L’acceptation sectorielle du contenu du release
L’acceptation est tacite si, à la date cut-off, il n’y a pas de remarques. Dans l’autre cas, le Groupe de Normalisation prendra une décision finale à sa réunion suivante et la date cut-off est également reportée.
3.2.4 L’implémentation du release
L’implémentation du release est la responsabilité de chaque utilisateur potentiel. L’implémentation d’un nouveau message ressort du libre choix de l’utilisateur. Le suivi des différentes versions d’un message existant est obligatoire. Si l’utilisateur ne suit plus l’évolution des versions, cela signifie implicitement qu’il arrête l’échange du MCI.
L’implémentation sera différente pour l’émetteur et le destinataire :
Pour l’émetteur, l’implémentation consiste dans le développement et la mise en production des programmes nécessaires pour émettre les messages définis dans les
MCIs.
Les différents MCIs d’un release ne doivent pas nécessairement être mis en production à la même date mais cette mise en production ne peut pas se faire avant la date de démarrage de la mise en production.
Pour le destinataire, la période d’implémentation consiste en deux parties :
- le développement et la mise en production des mesures de compatibilité et
- le développement et la mise en production des programmes de traitement des messages.
Les mesures assurant la compatibilité avec le release en implémentation et le(s) release(s) en usage ne doivent pas être installées à la même date.
3.2.5 Validation et certification des messages
La validation et la certification se font au niveau du message.
Selon les règles de base de l’EDI, l’émetteur est le seul responsable de la qualité du contenu de ses messages.
La validation se fait sur initiative du récepteur. Celui-ci invite donc les émetteurs à lui envoyer des messages, dont il vérifie le contenu. S’il découvre des anomalies ou des incohérences avec les messages publiés, il en informe l’émetteur.
Le résultat de ce processus de validation doit être la certification bilatérale du message entre le récepteur et l’émetteur.
3.2.6 La flexibilité de la date de release
Quoique la date de release doive être considérée comme une date fixe et ferme, le Groupe de Normalisation peut se réserver le droit de revoir cette date au cours de la période d’implémentation du release. La date ne peut être reportée que pour une raison d’intérêt sectoriel.
3.2.7 La maintenance de la liste des releases
Au moment de la composition d’un release, les versions – 1 des MCIs qui en font partie, sont indiquées pour dépréciation à la date du release si cette version – 1 existe.
C’est du ressort du Groupe de Normalisation de définir la date de radiation de ce MCI déprécié.
Pour l’émetteur ceci signifie qu’il n’a qu’une version en production, la version qui fait partie du release ou la précédente. (version –1)
Pour le récepteur il doit pouvoir recevoir 2 versions d’un MCI :
- la version qui fait partie du release
- la version précédente (version –1)
La période couverte par ces versions va de la date de démarrage de la mise en production du release jusqu’à la date de radiation de la version –1 du MCI.
Un release n’est jamais déprécié. Il est radié à la même date que le dernier MCI qui y appartient.
Le résultat de cette maintenance est publié sur site web TELEBIB2.
4. PROCÉDURE DE RECOURS
Tous les problèmes provenant de l’application de cette convention doivent être soumis à la Commission Mixte de Suivi sans aucune procédure de recours possible.