CONTENU 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 via leurs développeurs de logiciels courtiers ou 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 veille à la meilleure utilisation du TELEBIB2. Il agit comme point central dans les procédures et publie les résultats. Le Centre TELEBIB2 n’intervient pas dans la définition du contenu des Message Content Inventories (MCIs).
1.1.3 Durée de la convention
Cette convention est conclue pour une durée indéterminée. Elle débute à 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 de la convention
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 de base.
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 de base. 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ù une demande concernant un nouvel échange ou un changement d’un échange apparaît et le moment où le résultat est publié ou la demande refusée. L’objet de cette convention se limite aux échanges électroniques entre les applications entreprises d’assurances et les logiciels courtiers.
Cette convention ne couvre pas les étapes à franchir pour qu’un échange publié puisse être mis en utilisation. Ceci est l’objet de « la convention sectorielle sur les délais d’implémentation des échanges entre les applications entreprises d’assurances et les logiciels courtiers ». Elle ne couvre non plus les échanges appartenant à d’autres canaux de communication.
1.3 Définitions
Message Content Inventory (MCI) :
L’inventaire des données échangées qui supporte une fonction bien spécifique de l’assurance. Une fonction est déterminée par la combinaison d’un objet, d’une action et d’un domaine tels que définis dans le TELEBIB2. Le MCI est indépendant des syntaxes d’échange. Un MCI est identifié par son identifiant et sa version.
La version d’un MCI :
C’est le contenu d’un MCI à un certain moment, figé jusqu’à la prochaine version. Les versions sont gérées . Ceci signifie que les différentes versions sont stockées et utilisables. Une version est identifiée par un numéro qui sera incrémenté à chaque modification du MCI.
Comment gère-t-on la relation entre une version d’un MCI et le TELEBIB2/Référentiel ? Lors de la création d’une nouvelle version d’un MCI, le contenu du MCI, à savoir les données et les versions des listes de valeurs utilisées, est conservé.
Demande de développement d’un MCI :
C’est le document à utiliser pour envoyer une demande au Centre TELEBIB2.
- La demande d’un nouveau MCI contient :
- L’indication de la structure à utiliser (Contrat, Sinistre, “Quittance”, ...)
- La description de la fonction que le MCI doit couvrir. (Nouvelle Affaire, Avenant, …)
- La description du domaine que le MCI doit couvrir (Auto, Incendie, Multibranche, …)
- La description des partenaires qui vont le plus fréquemment échanger les messages dérivés du MCI.
- La périodicité d’usage.
- Le volume attendu.
Il est recommandé que la demande soit accompagnée d’une proposition de MCI.
Une demande de maintenance d’un MCI contient :
- L’identifiant et la version du MCI à modifier.
- La liste des données à ajouter et/ou à déprécier.
- La liste des données pour lesquelles une nouvelle version de la liste des valeurs est demandée, ainsi que l’identifiant de la nouvelle version de la liste des valeurs.
- La liste des données pour lesquelles le statut change.
- La description des modifications structurelles demandées.
Il est recommandé de joindre à la demande une proposition du MCI modifié.
Donnée échangée :
Une donnée TELEBIB2 qui figure dans un ou plusieurs MCIs peut figurer à plusieurs endroits.
Donnée d’échange obligatoire :
L’échange d’une donnée est obligatoire à partir du moment où le message ne peut pas être traité automatiquement quand la donnée n’y figure pas. L’état obligatoire d’une donnée échangée doit être indiqué au niveau du MCI. Vu que la même donnée peut être utilisée plusieurs fois dans un MCI, l’état doit être indiqué à chaque reprise. Exemple : dans Bloc Retour – Nouvelle affaire – Incendie :
‘Date d’effet’ du contrat est obligatoire, ‘date d’effet’ de la garantie Vol n’est pas obligatoire.
MCI en ‘Status 0’ (Version en élaboration) : Le contenu peut varier de réunion en réunion du groupe de projet. Cette version est uniquement publiée à titre d’information et en aucun cas pour implémentation.
MCI en ‘Status 1’ (Version pour analyse) : La stabilité du contenu n’est pas garantie. Il est déconseillé de faire des développements basés sur un MCI en status1.
MCI en ‘Status 2’ (Version pour implémentation) : Le contenu du MCI est stable jusqu’à la prochaine version du MCI. Il est recommandé de l’implémenter.
2. OBJECTIFS
Les objectifs de la convention sont :
2.1 Garantir la qualité du contenu des échanges
2.1.1 Qualité
Dans le cadre de cette convention, la qualité des échanges est définie en termes de compatibilité avec le TELEBIB2. Plus précisément ceci signifie que :
- Chaque donnée du MCI doit exister dans le TELEBIB2.
- La donnée dans le MCI est utilisée au sens de sa définition au TELEBIB2.
- La structure du message est conforme au modèle de données TELEBIB2.
- La liste des valeurs d’une donnée d’un MCI est identique à la liste recommandée par le TELEBIB2.
2.1.2 Contenu
Dans le cadre de cette convention, le contenu des échanges est défini en termes de degré d’intégration et degré de satisfaction des besoins fonctionnels. Plus précisément :
- Le degré d’intégration est le rapport entre les données émises et les données demandées par le destinataire.
- Le degré de satisfaction des besoins fonctionnels est le rapport entre les données émises et les données nécessaires pour une exécution optimale de la fonction supportée.
2.2 Réagir aux demandes dans les délais
Pour rester compatible avec les demandes acceptées, tous les acteurs exécutifs de cette convention doivent adapter leurs applications. L’implémentation de ces échanges n’est pas couverte par cette convention. Néanmoins, la préparation périodique des demandes doit cadrer dans le timing de cet implémentation (voir « la convention sectorielle sur les délais d’implémentation des échanges entre les applications entreprises d’assurances et les logiciels courtiers »).
3. QUI PEUT FORMULER UNE DEMANDE ?
Les demandes peuvent être introduites par :
- Une entreprise d’assurances,
- Un développeur de logiciels courtiers (en ce compris les bureaux de courtage avec leur propre système de gestion)
- Une Fédération de courtiers
Les demandeurs doivent être membre du groupe des entreprises d’assurances qui ont mandaté Assuralia ou du groupe des courtiers qui ont mandaté une Fédération de courtiers pour la signature de la présente convention. Les autres demandeurs doivent avoir signé la convention individuellement.
Les courtiers qui utilisent un logiciel de gestion pour bureaux de courtage peuvent introduire une demande uniquement par l’intermédiaire de leur fournisseur de logiciels de gestion du courtage ou leurs Fédérations.
4. PROCEDURE DE TRAVAIL
4.1 Le processus de traitement des demandes
4.1.1 Procédure de demande
Le demandeur envoie sa demande au Centre TELEBIB2.
La demande comprend une série d’éléments (cfr définition reprise à l’art.1.3) permettant de garantir une interprétation correcte. (Utilisation du template publié sur le web site TELEBIB2 )
Si la demande est incomplète ou imprécise, le Centre TELEBIB2 prend contact avec le demandeur afin d’obtenir davantage d’informations.
Le Centre TELEBIB2 renvoie dans tous les cas un accusé de réception.
4.1.2 Publication et communication de la demande
Publication de la demande sur le web site TELEBIB2 et communication aux acteurs exécutifs de cette convention.
Tous ceux qui sont intéressés et/ou ont des remarques sur cette demande doivent réagir par écrit auprès du Centre TELEBIB2 dans les délais définis dans le timing.
Enregistrement de la demande à l’agenda de la réunion suivante du Groupe de Normalisation.
4.1.3 Traitement de la demande
Pour être prises en compte, les demandes doivent répondre aux critères suivants :
- être supportées par un nombre d‘utilisateurs qui s’engagent à implémenter le MCI selon le schéma défini par le Groupe de Normalisation et décrit dans « la convention sectorielle sur les délais d’implémentation des échanges entre les applications entreprises d’assurances et les logiciels courtiers ».
- répondre à un intérêt économique sectoriel.
- ou répondre à une obligation légale.
Le traitement de la demande reste du ressort du Groupe de Normalisation.
L’existence d’un inventaire des MCIs est nécessaire pour situer les demandes. (‘Messages status 0/1/2’).
Le Groupe de Normalisation doit déterminer, sur base des éléments disponibles, si le
résultat de la demande est :
- un nouveau MCI
- ou une modification d’un MCI existant.
La modification d’un MCI ne peut se faire que dans les cas suivants :
- ajout et/ou dépréciation d’ une ou de plusieurs données
- l’utilisation d’une version plus récente d’une liste de valeurs
- la modification du statut d’ une ou de plusieurs données (obligatoire/optionnel)
- la modification de la structure des données ou une combinaison de plusieurs de ces points.
Dans tous les autres cas, les demandes donnent lieu à la création d’ un ou de plusieurs MCIs, éventuellement en combinaison avec la dépréciation d’ un ou de plusieurs MCIs.
Le Groupe de Normalisation doit motiver et défendre la décision prise et éventuellement proposer une alternative.
Au cas où la demande ne nécessiterait pas un travail de fond et le Groupe de Normalisation peut accepter la demande sans plus, le résultat de la demande est publié sous forme d’une nouvelle version du MCI en ‘status 1’. (voir 4.2.2)
Par contre, au cas où la demande nécessiterait un travail de fond, le Groupe de Normalisation crée un groupe de projet (sous-groupe du Groupe de Normalisation) et définit un planning pour ses activités. La demande est publiée comme un MCI en ‘status 0’
4.1.4 Timing
Comme la périodicité des réunions du Groupe de Normalisation est mensuelle, que les membres de ce groupe doivent être mis au courant de la demande deux semaines à l’avance et que le Centre TELEBIB2 a besoin d’une semaine pour le traitement de la demande, les demandes doivent être envoyées au Centre TELEBIB2 au moins trois semaines avant la réunion suivante du Groupe de Normalisation.
4.2 Le processus de traitement d’un MCI en « status 0 »
Ce processus vise à faire avancer l’état du MCI de 0 à 1.
4.2.1 La définition du contenu du MCI
Le groupe de projet est constitué de spécialistes en la matière étudiée. Il définit le contenu du MCI.
Le travail consiste plus particulièrement dans la création d’un inventaire des données nécessaires pour supporter la fonction d’assurance,objet de ce MCI.
Pour être conforme aux critères de qualité, le groupe de projet doit veiller à ce que :
Dans cet inventaire ne figurent que des données définies (ou à définir – voir « Convention sectorielle sur la maintenance du TELEBIB2 ») dans le TELEBIB2.
- Les données soient présentées dans la structure telle que définie dans le modèle de données TELEBIB2 (ou changement prévu du modèle).
- Pour les données codées (liste de valeurs), l’inventaire ne reprend que des listes de valeurs recommandées par le TELEBIB2 (ou à définir). Pour les données avec liste de valeurs, seule la version la plus récente de cette liste peut être utilisée.
Le groupe de projet est tenu à produire une liste des MCIs influencés par le MCI qui est l’objet de ses activités.
A la fin des travaux, la version du MCI est alignée sur le TELEBIB2. Le résultat est une combinaison bien concrète de données et de versions de listes de valeurs.
Le groupe de projet doit atteindre un consensus sur le résultat.
Le résultat est un MCI en « status 1’ » ; ceci signifie que le contenu (données et valeurs) est donc figé et devient l’objet d’analyse applicative par les utilisateurs potentiels.
4.2.2 Publication
Le MCI en « status 1 » est publié sur le site web du TELEBIB2.
4.2.3 Timing
La durée de cette phase est à définir par le groupe de projet en tenant compte de la complexité du MCI.
4.3 Le processus de traitement d’un MCI en « status 1 »
Ce processus vise à faire avancer l’état du MCI de 1 à 2.
4.3.1 “Fine tuning” du contenu
Tous les utilisateurs qui se sont engagés à implémenter le MCI doivent l’analyser en détail. Cette analyse est une analyse de réalisation de l’intégration du message dans l’environnement de l’intéressé.
Les utilisateurs doivent aussi fournir une estimation de la durée de l’implémentation au groupe de projet. Pour les destinataires des échanges, cette estimation doit au moins préciser le temps nécessaire pour le développement et l’implémentation des mesures de compatibilité.
4.3.2 Communication des modifications
Au cas où cette analyse engendrerait des modifications à un MCI, les modifications doivent être proposées au groupe de projet du MCI.
4.3.3 Traitement des modifications proposées
Le groupe de projet reçoit et étudie toutes les demandes de modification. Il les prend en charge ou les refuse.
4.3.4 Envoi d’un MCI en « status 1 » pour acceptation sectorielle
A la fin du processus, quand tous les commentaires ont été pris en compte, le MCI et les estimations des durées d’implémentation sont envoyés au Groupe de Normalisation pour acceptation sectorielle.
4.3.5 Timing
La durée de cette phase est à définir :
- Par le groupe de projet pour toutes demandes nécessitant un travail de fond.
- Par le Groupe de Normalisation pour toutes demandes ne nécessitant pas de travail de fond.
4.4 L’acceptation sectorielle du MCI
L’acceptation sectorielle d’un MCI se fait par le Groupe de Normalisation. Elle est concrétisée par l’attribution du « status 2 » au MCI.
4.5 Traduction en syntaxes et publication du MCI en « status 2 »
La syntaxe ou les syntaxes sectorielle(s) dans la(es)quelle(s) le MCI doit être traduit sont du ressort du Groupe de Normalisation.
Le Centre TELEBIB2 traduit le contenu d’un MCI en message(s) dans la(es) syntaxe(s) retenue(s).
Les MCIs en « status 2 », ainsi que les messages, sont publiés sur TELEBIB2.
4.6 Usage - Comment, quand et où utiliser le MCI
La description de l’usage d’un MCI ne fait pas partie de la présente convention mais se trouve dans la « Convention sectorielle sur les délais d’implémentation des échanges entre les applications entreprises d’assurances et les logiciels courtiers ».
5. PROCEDURE 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.