Brevet FR3073639A1 — publié le 20190517

SYSTEME D'IMPORT-EXPORT DE DONNEES HETEROGENES ENTRE PLUSIEURS ENTITES DOMAINE TECHNIQUE DE L'INVENTION [0001]La présente invention concerne un système et un procédé d'import-export de données hétérogènes entre plusieurs entités. ETAT DE LA TECHNIQUE ANTERIEURE [0002]Depuis plusieurs années, des quantités de plus en plus importantes de données sont échangées par l'entremise d'outils informatiques plutôt que par oral ou par écrit. L'importance des données non vocales échangées entre des entités de toutes sortes a depuis longtemps supplanté les données vocales servant par exemple à la téléphonie. Les entités susceptibles d'échanger des données sont de plus en plus variées, les types et les formats de données sont également toujours plus nombreux. [0003]Pour faciliter les échanges, plusieurs acteurs importants développent de outils ayant vocation à devenir des standards, utilisant des formats communs pour l'ensemble des utilisateurs. Les avantages des standards sont nombreux, notamment parce qu'ils permettent de mettre en oeuvre des plates-formes comportant un nombre très important d'utilisateurs. A contrario, pour assurer l'universalité, les systèmes standards sont peu évolutifs, et les utilisateurs sont contraints à utiliser les formats mis à disposition. Si de nouveaux formats doivent être introduits, tous les utilisateurs doivent mettre à jours leurs outils afin d'assurer la pérennité du système. Les évolutions sont donc en général très lentes, coûteuses et il subsiste souvent des périodes de latence pendant lesquelles tous les utilisateurs ne disposent pas de toutes les mises à jour de format. [0004]Pour les systèmes non-standards, dès qu'une entité effectue une modification, les autres entités doivent aussitôt être informées afin de procéder aux ajustements nécessaires pour assurer la compatibilité entre les divers formats IDfor fr 2 utilisés. En effet, des données utilisées par deux entités distinctes pour communiquées peuvent être ajoutées, modifiées ou supprimées par l'une des deux entités, bloquant de ce fait la réception d'ordres envoyés par la première entité à la seconde entité. 5 [0005]L'intervention d'un professionnel est alors presque toujours obligatoire pour mettre à jour le système d'une ou plusieurs entités lors de changements opérés sur une ou plusieurs données. La plupart des grandes entités disposent du personnel expert pouvant s'occuper de modifications requises. Toutefois, les 10 petites entités n'ont pas toujours les ressources techniques et/ou financières pour procéder à ces modifications. Par ailleurs, le temps requis pour effectuer les modifications, voire la production de nouvelles applications plus adaptées, est souvent de plusieurs semaines ou mois. Ces longs délais de réalisation et les coûts associés constituent des freins importants au développement d'applications 15 plus performantes. [0006]Pour répondre à la demande des entités, des procédés d'import-export et/ou de transfert de données ont été mis en oeuvre. 20 [0007]Par exemple, le document FR2931272 décrit un procédé d'import export de données provenant d'une base de données par l'intermédiaire d'un fichier XML, acronyme de l'expression anglo-saxonne « eXtensible Markup Language », signifiant langage de balisage extensible. 25 [0008]Le procédé trouve notamment une de ses applications dans le domaine de l'ingénierie système et logicielle. Les données peuvent être stockées sur au moins un disque dur d'une base de données. La base de données peut être gérée par une première application logicielle au moyen d'au moins un processeur d'un premier ordinateur. L'export de données s'effectue de la base de données vers au 30 moins un deuxième ordinateur. Le deuxième ordinateur peut notamment comporter au moins un processeur sur lequel s'exécute au moins une deuxième application logicielle. La deuxième application logicielle est notamment apte à créer, modifier et supprimer des données de la base de données. Le procédé IDfor fr 3 d'import export comporte notamment un premier procédé d'export et un deuxième procédé d'import. Ce procédé est relativement lourd à mettre en oeuvre, limitant les utilisations à des cas où des bases de données volumineuses doivent être dupliquées ou transférées. 5 [0009]Le document FR2968425 décrit un procédé de transfert de données multimédia dans un réseau, d'un terminal multimédia source à un terminal multimédia cible. Ce principe repose sur l'évaluation de la compatibilité des données entre un terminal source et un terminal cible. Les données identifiées ou 10 les données converties à partir des données identifiées au terminal cible seront transférées seulement si elles sont compatibles. Lorsque les données ne sont pas compatibles, aucun transfert n'est possible, interdisant, de ce fait, les échanges entre les entités. Ce procédé est utile pour des applications multimédias. 15 [0010]Le document W02008098249 décrit un appareil pour adapter un contenu multimédia d'une variété de formats à une variété d'autres formats dans un ou plusieurs réseaux de télécommunication. Les données entrées sont modifiées par l'appareil afin d'être compatibles avec les données de sortie demandées. Ce procédé fonctionne seulement si les données d'entrée, une fois modifiées, sont 20 compatibles avec les données demandées en sortie. Le procédé vise spécifiquement les applications multimédia. [0011]Des procédés pour la synchronisation et/ou la gestion de base de données ont également été développés. 25 [0012]Par exemple, le document FR2909203 décrit un procédé de synchronisation de bases de données hétérogènes. Le document décrit une solution pour consulter, éditer, mettre à jour et synchroniser un ensemble de bases de données hétérogènes et propose un procédé et un système pour la 30 synchronisation de bases de données dont certaines informations d'une ou plusieurs desdites bases de données sont dépendantes de certaines autres informations d'une ou plusieurs autres desdites bases de données. Le problème IDfor fr 4 général est de fournir un dispositif capable de synchroniser et de mettre à jour un ensemble de bases de données hétérogènes et indépendantes. Un exemple de bases de données hétérogènes et non synchronisées automatiquement à ce jour est trouvé dans les clubs de sport où il est nécessaire de gérer d'un côté des 5 bases de données de membres du club de sport et de l'autre un ensemble de bases de données sur la réservation et l'occupation des lieux comme des salles et terrains de sport, des courts de tennis, des départs sur un parcours de golf ou encore des matériels de musculation. Par ailleurs, les membres d'un club ne se connaissant que très peu entre eux, une demande des membres est d'avoir la 10 possibilité de rencontrer et de jouer avec de nouveaux partenaires. La réservation optionnelle d'un lieu et la recherche de partenaires est un service qui doit être rendu par le procédé de synchronisation de bases de données hétérogènes. Avant de modifier des données des deux premières bases de données, un processus de vérification de la compatibilité de certaines informations des deux 15 autres bases de données est effectué. Des modifications, à effectuer par les utilisateurs, sont obligatoires s'il n'y a pas de compatibilités. Ce système constitue un exemple de système « fermé », prévu pour une application spécifique, avec des données spécifiques. 20 [0013]Le document FR3007548 décrit un procédé d'interrogation d'une base de données relationnelle. Le document décrit un dispositif pour l'interrogation d'une base de données relationnelles (DB) comportant des moyens pour effectuer un traitement sur certaines données transmises par un échange de messages entre un utilisateur (U) et la base de données relationnelle constitué d'une requête et 25 d'une réponse. Ce traitement est effectué par le dispositif (D) en séquence de l'échange et en fonction de règles mémorisées dans un fichier de configuration (CF) et identifiées par le contenu dudit échange. Le traitement des données est effectué en fonction des règles mémorisées dans un fichier de configuration. Ce système est architecturé avec une base de données centrale comportant 30 l'ensemble des données pour lesquelles les utilisateurs peuvent effectuer des requêtes. Il n'est pas adapté pour une architecture décentralisée des données. Il IDfor fr 5 s'agit d'un système-expert relativement complexe réservé à des utilisateurs d'un haut niveau d'expertise. [0014]Pour pallier ces différents inconvénients, l'invention prévoit différents 5 moyens techniques. EXPOSE DE L'INVENTION 10 [0015]Tout d'abord, un premier objectif de l'invention consiste à prévoir un système et un procédé permettant de simplifier et pérenniser les flux de données entre plusieurs entités. [0016]Un deuxième objectif consiste à permettre aux utilisateurs d'un réseau 15 comportant une pluralité d'entités d'apporter des modifications de données de syntaxe, de format ou de sémantique, sans devoir modifier le système utilisé, ni changer de système. [0017]Un troisième objectif consiste à permettre aux utilisateurs d'un réseau 20 comportant une pluralité d'entités d'assurer une traçabilité fiable des données échangées. [0018]Pour ce faire, l'invention prévoit un système d'import-export de données hétérogènes entre plusieurs entités (A, B, C) comprenant : 25 i) un serveur de mappage, ayant accès à des données de mappage ; ii) une pluralité d'entités utilisateurs chacune comprenant au moins un module descripteur et au moins un module d'échange d'ordre ; ledit serveur de mappage comprenant également : - un module analyseur de données ; 30 - un module coupleur de données ; - un module d'appariement de données. [0019]Le serveur centralisé, ou serveur de mappage, permet de créer et de conserver les correspondances pour chaque couple de descripteur pour les IDfor fr 6 entités susceptibles d'échanger entre elles des données. De cette façon, même si les données de formats ou de syntaxe et/ou les données de sémantique entre deux entités ne sont pas identiques, le serveur de mappage permet de transformer les données du format de l'entité source vers le format de l'entité 5 cible. Le serveur, grâce aux opérations de mappage, permet donc de transformer les données afin que celles-ci soient formatées en fonction de l'entité pertinente. [0020]Selon un mode de réalisation avantageux, chacun des modules d'échange d'ordres est conçu pour préparer, envoyer et/ou recevoir des données d'ordres 10 spécifiquement prévus pour le serveur de mappage. [0021]Selon un mode de réalisation avantageux, le module analyseur est conçu pour analyser les données d'ordres reçues par le serveur, afin de mettre en correspondance les données de descripteurs des entités concernées. [0022]Selon encore un autre mode de réalisation avantageux, le module coupleur est conçu pour créer des couples de données de descripteurs à apparier pour chacune des paires d'entités constituées par une source d'ordres et une cible d'ordres. [0023]Selon une variante avantageuse, le module d'appariement est conçu pour apparier les données de chaque couple de données de descripteur formé par le module coupleur. 25 [0024]Selon une autre variante avantageuse, le module descripteur est conçu pour générer et contenir les données de descripteurs de chacune des entités de la pluralité d'entités susceptibles d'être transférées à une autre entité de la pluralité d'entités. Les descripteurs correspondent à des données de caractéristiques se rapportant à des objets, des personnes, des opérations, etc. 30 [0025]Selon encore une variante avantageuse, le serveur d'appariement et/ou les entités comprennent par ailleurs un module de modification, conçu pour analyser 15 20 IDfor fr 7 les modifications de données d'une entité afin de déterminer s'il s'agit d'une modification de données d'un descripteur, ou d'un ajout, ou d'une suppression. [0026]L'invention prévoit également un procédé d'import-export de données 5 hétérogènes entre plusieurs entités (A, B, C) comprenant les étapes consistant à: (i) préparer, à l'aide d'un module d'échanges d'ordres d'une entité source, des données d'ordres destinées à une pluralité d'entités cibles, avec des données de descripteurs et des données d'entités ; (ii) envoyer les données d'ordres préparées à un serveur de mappage par 10 l'entremise du module d'échanges d'ordres de l'entité source ; (iii) recevoir les données d'ordres à l'aide du serveur de mappage ; (iv) analyser les données d'entités et les données de descripteurs à mettre en correspondance à l'aide d'un module analyseur ; (y) créer de couples de données à apparier pour chaque paire de la pluralité 15 d'entités à l'aide d'un module coupleur ; (vi) apparier les données de chaque couple à l'aide un module d'appariement ; (vii) obtenir des couples de données d'ordres appariées avec les données de descripteurs correspondants à chacune des entités de la pluralité d'entités ; (viii) envoyer, à l'aide du serveur de mappage, les données d'ordres appariées à 20 chacune des entités cibles ; (ix) recevoir, à l'aide de chacune des entités cibles, les données d'ordres appariées. [0027]Selon un mode de réalisation avantageux, le procédé comprend également 25 une étape préalable de préparation et mise en forme de données de descripteurs pour chacune des entités de ladite pluralité d'entités. [0028]Selon un autre mode de réalisation avantageux, en cas de modification d'un ou plusieurs descripteurs d'une entité, un module de modification de cette entité 30 envoie au serveur d'appariement la ou les données de descripteur modifiées. [0029]De manière avantageuse, le module de modification du serveur de IDfor fr 8 mappage analyse les modifications reçues de l'entité afin de déterminer s'il s'agit d'une modification de données d'un descripteur, ou d'un ajout, ou d'une suppression. 5 [0030]En cas de modification de données d'une entité, le module d'analyse du serveur centralisé permet de mettre à jour les données de mappage du serveur afin que les échanges de données entre les entités concernées par la modification puissent être poursuivis. 10 [0031]Cette caractéristique permet aux opérateurs de chacune des entités de faire évoluer les données sans se préoccuper des échanges avec les autres entités. D'une part, les destinataires potentiels des données modifiées pourront recevoir les ordres du fait de mappages mis à jour, et d'autre part, les entités tiers susceptibles d'envoyer des données à l'entité où les modifications ont été 15 effectuées, sont assurées que les ordres seront convenablement reçus. Cette caractéristique est particulièrement utile car elle évite les ruptures de transferts de données entre des entités suite à des modifications effectuées par l'une et/ou l'autre entité. Elle permet également d'éviter la nécessité de concevoir une nouvelle application suite à des modifications. Les coûts d'exploitation sont 20 considérablement réduits. La continuité de service permet également de meilleures performances dans la durée. [0032]Selon un mode de réalisation, si la continuité entre les descripteurs est maintenue (c'est-à-dire si, pour une entité, des données de format/syntaxe et/ou 25 de sémantique pour des descripteurs existants et maintenus sont effectuées) le module de modification du serveur modifie le ou les couples comprenant la donnée. Les données de mappage sont alors mises à jour et les échanges de données entre les entités sont assurés. 30 [0033]Selon un autre mode de réalisation, si la continuité entre les descripteurs est interrompue, le serveur d'appariement génère une alerte destinée aux entités cibles susceptibles d'utiliser la donnée. En cas d'ajout et/ou suppression d'un ou IDfor fr 9 plusieurs descripteurs, une alerte est générée pour les entités susceptibles d'utiliser ces descripteurs afin que l'opérateur de chaque entité concernée puisse adapter la configuration en fonction des besoins, par exemple en complétant les données manquantes pour cette entité, ou en supprimant des descripteurs, etc. [0034]Selon un autre mode de réalisation, si la continuité entre les descripteurs est susceptible d'être interrompue, le module de modification génère une modification automatique susceptible d'assurer la continuité des échanges entre les entités. DESCRIPTION DES FIGURES [0035]Tous les détails de réalisation sont donnés dans la description qui suit, 15 complétée par les figures 1 à 3, présentées uniquement à des fins d'exemples non limitatifs, et dans lesquelles : -la figure 1 est une représentation schématique d'un exemple de système d'import-export de données hétérogènes entre plusieurs entités ; -la figure 2 illustre un organigramme fonctionnel avec les principales étapes d'un 20 exemple de procédé d'import-export de données hétérogènes entre plusieurs entités ; -la figure 3 illustre un organigramme fonctionnel illustrant des exemples d'étapes pouvant permettre de prendre en compte des modifications de données effectuées au sein d'une entité. 25 DESCRIPTION DETAILLEE DE L'INVENTION [0036]Par descripteur, on entend un attribut permettant de qualifier et/ou décrire un élément sur la forme, par des éléments de format et/ou syntaxe, et sur le fond, 30 par des éléments de sémantique. Les descripteurs correspondent à des données de caractéristiques se rapportant à des objets, des personnes, des opérations, etc. 5 10 IDfor fr 10 [0037]La figure 1 est une représentation schématique d'un exemple de système d'import-export de données hétérogènes entre plusieurs entités, dans cet exemple les entités A, B, C, correspondant respectivement aux références numériques 20, 5 30 et 40. Le système comprend un serveur 10 de mappage, ayant accès à des données de mappage 14. Ces données peuvent être au niveau du serveur ou encore à distance. [0038]Dans l'exemple illustré, le système prévoit une pluralité d'entités 20, 30, 40 10 utilisateurs chacune comprenant au moins un module descripteur 21, 31, 41 et au moins un module de préparation et d'échange d'ordres 22, 32, 42. [0039]Le module descripteur 21, 31, 41 est conçu pour générer et contenir les données de descripteurs de chacune des entités. Ces données correspondent à 15 des données de caractéristiques ou attributs se rapportant à des objets, des personnes, des opérations, etc. [0040]Les données de descripteur sont l'objet d'échanges réguliers entre les entités du système. Or, il est très fréquent que les formats et/ou syntaxes et/ou 20 sémantiques différent entre certaines entités, rendant les échanges de données impossibles. Dans de nombreux autres cas, les données sont compatibles à un instant donné, mais sont sujettes à évolution et deviennent progressivement incompatibles. Pour éviter ces deux grands types d'inconvénients, le serveur d'appariement sert de carrefour d'échanges et de transformation des données, 25 avec une approche par couple, en considérant, pour chaque échange, le module source et le module cible. [0041]La portion du bas de la figure 1 comporte un tableau permettant de donner un exemple simplifié de données de descripteur. Dans cet exemple, un 30 descripteur correspondant à la couleur d'un objet est encodé de plusieurs façons en fonction des entités. Par exemple, la couleur « blanc » est encodée avec la valeur « 1 » à l'entité A, la valeur « b » à l'entité B, et la valeur « alpha » à l'entité IDfor fr 11 C. Dans cet exemple, un ordre « couleur » émanant de l'entité A serait encodé avec une valeur « 1 », non compatible avec les entités B et C. Le serveur d'appariement permet de former les couples, par exemple de A vers B, avec les données de mise en correspondance, par exemple la valeur « 1 » correspondant à 5 la valeur « b » dans ce cas. En centralisant les données de descripteur de l'ensemble des entités, le serveur d'appariement permet de mettre en oeuvre les échanges de données entre les entités, sans problème de compatibilité. [0042]Pour assurer une telle mise en oeuvre, les modules de préparation et 10 d'échanges d'ordres 22, 32, 42 sont conçus pour préparer, envoyer et/ou recevoir des données d'ordres à destination du serveur de mappage 10. Il n'y a donc pas d'échange direct entre les entités, contrairement aux systèmes de type connu. [0043]De son côté, le serveur de mappage 10 comprend un module analyseur 11 15 de données, un module coupleur 12 de données, ainsi qu'un module d'appariement 13 de données. Le module analyseur 11 est conçu pour analyser les données d'ordres reçues par le serveur 1. Cette analyse permet de mettre en correspondance les données de descripteurs des entités concernées, en identifiant les entités sources et les entités cibles. La centralisation permet à 20 plusieurs entités utilisant plusieurs formats et/ou syntaxe et/ou sémantiques distincts de pouvoir échanger des données tout en obtenant le bon format/syntaxe ou sémantique au moment de l'entrée des données dans une entité cible. [0044]Le module coupleur 12 est conçu pour créer des couples de données de 25 descripteurs à apparier pour chacune des paires d'entités constituées par une entité source d'ordres et une entité cible d'ordres. [0045]Le module d'appariement 13 est conçu pour apparier les données de chaque couple de données de descripteur formé par le module coupleur. 30 [0046]En variante, selon les mises en oeuvre envisagées, certains modules peuvent être combinés. IDfor fr 12 [0047]Encore en variante, selon les types d'architectures, certains modules des entités 20, 30, 40 peuvent éventuellement être intégrés au serveur d'appariement. Le concept et la mise en oeuvre sont alors simplement adaptés pour une gestion 5 plus centralisée des données et/ou des modules. [0048]Tel qu'illustré dans l'exemple de la figure 1, le système prévoit un ou plusieurs modules de modification, permettant d'assurer une continuité dans l'échange des données même en cas de modification par une ou plusieurs entités. 10 Un module de modification 15 est avantageusement prévu au niveau du serveur d'appariement, et/ou au niveau 23, 33, 43 de chaque entité du système. En cas de modification de données de descripteur d'une entité, le module de modification de cette entité transmet la modification au serveur pour prise en compte de la modification telle que décrite ci-après, en relation avec le procédé d'import-export 15 de données hétérogènes, et plus particulièrement en relation avec la figure 3. PROCEDE D'IMPORT-EXPORT DE DONNEES HETEROGENES ENTRE PLUSIEURS ENTITES 20 [0049]Les figures 2 et 3 illustrent, à l'aide d'organigrammes fonctionnels, des exemples de mise en oeuvre du procédé d'import-export de données hétérogènes selon l'invention. [0050]La figure 2 illustre les étapes clés du procédé permettant d'effectuer des 25 échanges de données d'ordres entre diverses entités. Tout d'abord, l'étape 100 consiste à préparer, à l'aide d'un module de préparation et d'échange d'ordre 22, 32, 42 d'une entité source, des données d'ordres destinées à une ou à une pluralité d'entités cibles 20, 30, 40, avec des données de descripteurs et des données d'entité. L'étape 101 consiste à envoyer les données d'ordres préparées 30 à un serveur de mappage 10 par l'entremise du module de préparation et d'échanges d'ordres 22, 32, 421 de l'entité source. IDfor fr 13 [0051]A l'étape 102, les données d'ordres sont reçues par le serveur de mappage 10. Ensuite, à l'étape 103, les données d'entités et les données de descripteurs à mettre en correspondance sont analysées à l'aide d'un module analyseur 11. L'étape 104 consiste à créer de couples de données à apparier pour chaque paire 5 de la pluralité d'entités 20, 30, 40. Cette étape est mise en oeuvre à l'aide d'un module coupleur 12. [0052]Ensuite, à l'étape 105, les données de chaque couple sont appariées à l'aide d'un module d'appariement 13. Cette phase permet d'obtenir, à l'étape 106, 10 des couples de données d'ordres appariées avec les données de descripteurs correspondants à chacune des entités de la pluralité d'entités. [0053]Le serveur 10 de mappage envoie, à l'étape 107, les données d'ordres appariées à chacune des entités cibles 20, 30, 40. Enfin, à l'étape 108, les 15 données d'ordres appariées sont reçues par chacune des entités cibles 20, 30, 40. [0054]Les étapes préalablement décrites peuvent être mises en oeuvre dans la mesure où des données de descripteur et des données de mappage sont présentes. Si les données sont incomplètes ou inexistantes, une ou plusieurs 20 étapes préalables de préparation et mise en forme de données de descripteurs pour chacune des entités et/ou une ou plusieurs étapes de préparation et mise en forme de données de mappage peuvent être mises en oeuvre. [0055] Par la suite, ce mode de mise en oeuvre permet un bon fonctionnement tant 25 et aussi longtemps que les données de descripteur de l'ensemble des entités demeurent inchangées. Dès qu'un changement intervient au niveau de l'une ou l'autre des entités, un risque de discontinuité est susceptible de se produire. [0056]Cette dernière éventualité est l'objet des diverses étapes illustrées à la 30 figure 3. IDfor fr 14 [0057]Ainsi, en cas de modification d'un ou plusieurs descripteurs d'une entité, aux étapes 200 et 201, un module de modification 23, 33, 43 de cette entité détecte une modification et envoie au serveur d'appariement la ou les données de descripteur modifiées. A l'étape 202, le serveur reçoit la ou les données de 5 descripteur modifiées. [0058]Ensuite, à l'étape 203, le module de modification 15 du serveur 10 de mappage analyse les modifications reçues de l'entité afin de déterminer s'il s'agit d'une modification de données d'un descripteur comme par exemple un 10 changement de syntaxe et/ou de format (étape 204), ou d'un ajout d'un ou plusieurs descripteurs (étape 205), ou d'une suppression d'un ou plusieurs descripteurs (étape 206). [0059]Dans le cas correspondant à l'étape 204, la continuité entre les descripteurs 15 est normalement maintenue. Par exemple, si, pour une entité, des données de format/syntaxe et/ou de sémantique pour des descripteurs existants et maintenus sont effectuées, le module de modification 15 du serveur modifie le ou les couples comprenant la donnée. Les données de mappage sont alors mises à jour et les échanges de données entre les entités sont assurés. 20 [0060]Par contre, dans les cas représentés par les étapes 205 et 206, la continuité entre les descripteurs est susceptible d'être affectée, engendrant une rupture probable lors d'un prochain échange de données entre les entités concernées. 25 [0061]Dans un tel cas, à l'étape 209, si la continuité entre les descripteurs n'est pas assurée, le serveur 10 d'appariement génère une alerte destinée aux entités cibles susceptibles d'utiliser la ou les données concernées. 30 [0062]Une étape optionnelle est par ailleurs prévue (étape 208 de la figure 3) dans laquelle, si la continuité entre des descripteurs est interrompue, le module de modification 15 génère une modification automatique susceptible d'assurer la IDfor fr 15 continuité des échanges entre les entités concernées. La modification automatique est de préférence sujette à validation avant d'être implémentée. Par exemple, en cas de suppression d'un descripteur par une entité, le module d'appariement peut générer une modification automatique visant à supprimer ce 5 descripteur pour l'ensemble des utilisateurs, ou visant à mettre en place un descripteur compatible. TRACABILITE 10 [0063]Selon une variante de réalisation avantageuse, du fait de la centralisation des échanges de données, le serveur d'appariement peut prévoir un module de traçabilité. Ce module est de préférence complété par une base de données de traçabilité. La totalité des échanges entre les diverses entités transitant par le 15 serveur 10, le module de traçabilité est prévu afin de conserver une trace de chaque échange de données. Les données conservées et pérennisées concernent au moins les entités entre lesquelles les échanges ont lieu et le descripteur concerné. D'autres données complémentaires peuvent également être conservées. Le module et la base de traçabilité permettent, en cas de besoin, de 20 retrouver les échanges de données effectués dans le passé au niveau du système. Les données peuvent par exemple être retracées en effectuant des recherches par entités concernées, et/ou par descripteurs, ou autres paramètres. La traçabilité permet par exemple d'identifier des entités, des ordres échangés entre ces entités, les données d'horodatage correspondantes, etc. L'infalsifiabilité 25 des données peut être garantie au besoin par un moyen ou un organisme certifié à cet effet, REVENDICATIONS1. Procédé d'import-export de données hétérogènes entre plusieurs entités (A, B, C) comprenant les étapes consistant à: (i) préparer, à l'aide d'un module de préparation et d'échange d'ordres (22, 32, 42) d'une entité source, des données d'ordres destinées à une pluralité d'entités cibles (20, 30, 40), avec des données d'attributs des données d'entités ; (ii) envoyer les données d'ordre préparées à un serveur de mappage (10) par l'entremise du module d'échange d'ordres (21, 31, 41) de l'entité source ; (iii) recevoir les données d'ordres à l'aide du serveur de mappage (10) ; (iv) analyser les données d'entités et les données d'attributs à mettre en correspondance à l'aide d'un module analyseur (11) ; (y) créer des couples de données à apparier pour chaque paire de la pluralité d'entités (20, 30, 40) à l'aide d'un module coupleur (12), en considérant, pour chaque échange, le module source et le module cible ; (vi) apparier les données de chaque couple à l'aide un module d'appariement (13) ; (vii) obtenir des couples de données d'ordre appariées avec les données d'attributs correspondants à chacune des entités de la pluralité d'entités ; (viii) envoyer, à l'aide du serveur (10) de mappage, les données d'ordres appariées à chacune des entités cibles (20, 30, 40) ; (ix) recevoir, à l'aide de chacune des entités cibles (20, 30, 40), les données d'ordre appariées. 2. Procédé d'import-export de données hétérogènes entre plusieurs entités selon la revendication 1, comprenant une étape préalable de préparation et mise en forme de données d'attributs pour chacune des entités de ladite pluralité d'entités (20, 30, 40). 3. Procédé d'import-export de données hétérogènes entre plusieurs entités selon l'une des revendications 1 ou 2, dans lequel en cas de modification d'un IDfor-fr ou plusieurs attributs d'une entité (20, 30, 40), un module de modification (23, 33, 43) de cette entité envoie au serveur (10) d'appariement la ou les données d'attributs modifiées. 4. Procédé d'import-export de données hétérogènes entre plusieurs entités selon la revendication 3, dans lequel le module de modification (15) du serveur (10) de mappage analyse les modifications reçues de l'entité afin de déterminer s'il s'agit d'une modification de données d'un attribut, ou d'un ajout, ou d'une suppression. 5. Procédé d'import-export de données hétérogènes entre plusieurs entités selon la revendication 4, dans lequel, si la continuité entre les attributs est maintenue, le module de modification (15) du serveur modifie le ou les couples comprenant la donnée. 6. Procédé d'import-export de données hétérogènes entre plusieurs entités selon la revendication 4, dans lequel, si la continuité entre les attributs est interrompue, le serveur (10) d'appariement génère une alerte destinée aux entités cibles (20, 30, 40) susceptibles d'utiliser la donnée. 7. Procédé d'import-export de données hétérogènes entre plusieurs entités selon la revendication 4, dans lequel, si la continuité entre les attributs est susceptible d'être interrompue, le module de modification (15) génère une modification automatique susceptible d'assurer la continuité des échanges entre les entités. IDfor-fr