Brevet FR2976378A1 — publié le 20121214

Procédé et système de gestion de données partagées entre des sites de gestion distincts La présente invention concerne d'une manière générale un procédé et un système de gestion de données partagées entre au moins deux sites de gestion distincts. Plus particulièrement, l'invention concerne un procédé de gestion d'un ensemble de données partagées qui sont accessibles par plusieurs applications exécutées dans aux moins deux sites de gestion distincts formant le système de gestion de données. II est connu des systèmes d'information déployés sur plusieurs sites géographiquement distincts, des applications exécutées dans lesdits sites se partageant un même ensemble de données. On entend par donnée partagée, une donnée qui est accessible en écriture et en lecture dans au moins une base de données par différentes applications en cours d'exécution sur les sites d'un système d'information. Un tel système d'information comporte une base de données localisée sur un premier site considéré comme site principal. Le site principal comporte une première application par exemple en cours d'exécution dans un premier terminal utilisateur et qui se connecte localement à la base de données. Les applications des autres sites se connectent à distance à la base de données du site principal. On entend ici par connexion à distance, le fait que chaque site, géographiquement distinct, est relié aux autres sites par une connexion par réseaux de communication. Lorsqu'un utilisateur de terminal d'un des sites non principaux souhaite accéder, via une application, à une donnée partagée de la base de données, ledit terminal se connecte à distance à la base de données par le réseau de communication. Un tel système d'information est considéré comme intègre lorsque pour une même donnée accessible par plusieurs terminaux sur des sites distincts, au moyen d'applications, la valeur de ladite donnée partagée reste cohérente. En effet, dans ce cas, une donnée partagée n'est accessible en écriture que par une seule application à la fois dans la base de données. Il n'y a pas de conflit d'accès multiple à la donnée. Cependant, lors d'une défaillance de communication entre le site principal et un autre site, le terminal utilisateur dans l'autre site ne peut accéder aux données partagées de la base de données. Un tel système d'information n'est pas robuste. Un système d'information est considéré comme robuste lorsqu'un des sites est défaillant ou lorsque la communication entre les sites est défaillante, mais qu'elle n'obstrue pas l'accès aux données partagées ou à une partie de ces données aux autres sites d'information. Pour pallier un problème de robustesse, il existe des systèmes d'information multi-sites comportant autant de bases de données qu'il y a de sites. Les données partagées de chaque base de données sont dupliquées dans les différentes autres bases de données. Dans un tel cas, on parle alors de réplication de données dans les différentes bases de données du système. Il existe deux types de réplications : la réplication synchrone (« eager » en anglais) et la réplication asynchrone (« lazy » en anglais). La réplication synchrone entre deux bases de données correspond à une mise à jour des bases de données durant une modification d'une donnée, appelée également transaction d'une donnée, dans l'une ou l'autre des bases de données. L'intégrité des bases de données est satisfaite à chaque réplication d'une donnée dans les bases de données grâce à une validation à deux phases ("two phase commit" en anglais) dont une phase de vote et une phase de décision. Ces deux phases permettent de garantir la cohérence d'une donnée partagée dupliquée dans les différentes bases de données à la fin d'une transaction sur la donnée. Cependant, cette technique de réplication a pour conséquence des transactions longues sur les données car à chaque transaction est ajoutée une validation à deux phases. De plus, lors d'une défaillance de communication entre des sites, la duplication synchrone des données ne peut s'effectuer puisque la validation à deux phases ne peut avoir lieux. En l'espèce, cela implique un problème de robustesse du système. La duplication asynchrone de données partagées entre deux bases de données comprend une exécution et une validation d'une transaction sur une donnée se trouvant localement dans une base de données. Les mises à jour effectuées par duplication sont propagées dans chaque base de données de manière différées après la fin de la transaction. Ainsi, si une base de données distante est indisponible du fait d'une défaillance, les mises à jour sur des données partagées qui lui sont destinées, sont mises en attente, puis appliquées lorsque la base de données distante redevient opérationnelle. De ce fait, l'exigence de robustesse est considérée si un site est inaccessible, puisque les autres sites du système d'information peuvent opérer sur leur base de données locale. Toutefois, en cas de transactions effectuées pratiquement simultanément sur une même donnée partagée dans des bases de données distinctes, la réplication asynchrone aboutie à une incohérence de la donnée dans chacune des bases de données, puisque les mises à jour différées 1 o n'ont pas été effectuées. Le partage de données entre différents sites d'un système d'information dit multi-sites, nécessite le respect des exigences que sont l'intégrité des données partagées, la robustesse dudit système face à une défaillance partielle ou générale de la communication entre les différents sites et la 15 performance du système d'information. L'objectif de l'invention est de pallier en partie ou totalement les inconvénients de l'art antérieur. Pour cela, l'invention propose un procédé de gestion de données partagées entre plusieurs sites d'un même système d'information comportant chacun une base de données. Chaque site gère 20 localement l'accès en écriture à une partie distincte de l'ensemble des données partagées mémorisées dans les bases de données du système d'information. Pour atteindre cet objectif, un procédé permet de gérer une donnée mémorisée dans au moins deux bases de données comprises 25 respectivement dans deux sites distincts appartenant à un même réseau, ladite donnée étant associée à un état d'accès en écriture géré par un site maître, la dite donnée étant partagée en lecture et en écriture par des applications implémentées sur des terminaux de chaque site, et ladite donnée étant apte à être sollicitée pour une opération en écriture par une 30 application d'un site local. Le procédé comprend les étapes suivantes : - une vérification de l'état d'accès en écriture à la donnée dans le site maître, - si l'accès en écriture à la donnée est à l'état accessible, un verrouillage de l'accès en écriture à la donnée dans le site maître, - un traitement de l'opération sur la donnée dans la base de données du site 35 local, et - un déverrouillage de l'accès en écriture à la donnée dans le site maître. Le système de gestion de données selon l'invention gère les conflits d'intégrité des bases de données, par une gestion de l'état d'accès en écriture à chaque donnée par l'intermédiaire d'un site maître spécifique pour chaque donnée. Ce site maître permet ainsi d'éviter de multiple accès simultanés à une donnée partagée par plusieurs applications implémentées sur des terminaux du site maître ou des sites distants. Dans l'invention, l'accès à une donnée signifie la possibilité de lire la donnée et/ou d'effectuer une opération d'écriture sur la donnée dans les bases de données. Une donnée est associée à un état d'accès. Si la donnée est accessible en écriture, l'état d'accès associé est alors à l'état accessible. Si l'accès en écriture à la donnée est verrouillé, l'état d'accès est alors à l'état verrouillé. Selon la donnée à accéder, le site maître peut être le site local ou peut être un site distinct du site local. Selon une réalisation de l'invention, le site local est distinct du site maître. Le site local communique avec le site maître pour commander au site maître l'exécution des étapes de vérification de l'état d'accès à la donnée et de verrouillage, déverrouillage de l'accès en écriture à la donnée. Le procédé comprend alors, avant le traitement de l'opération, une commande d'une première mise à jour de la donnée dans la base de données du site local par duplication de la donnée mémorisée dans la base de données du site maître. Le procédé comprend également après le traitement de l'opération, une commande d'une deuxième mise à jour de la donnée dans la base de données du site maître par duplication de la donnée mémorisée dans la base de données du site local. Lorsque le site maître est distinct du site local, la double mise à jour des bases de données locale et distante commandée par le site local permet d'obtenir des données cohérentes dans les deux bases de données, avant et après le traitement de l'opération sur la donnée. Lorsque le site maître est distinct du site local et lors d'une détection d'une défaillance de communication entre le site local et le site maître par le site local, la donnée partagée dont l'état d'accès en écriture est géré par le site maître est accessible uniquement en lecture dans la base de données du site local. Si l'accès en écriture à la donnée a été verrouillé dans le site maître, le site local mémorise une commande de déverrouillage de l'accès en écriture à la donnée à transmettre au site maître dès que la communication entre les deux sites est de nouveau établie. Si préalablement à la détection de la défaillance, l'opération sur la donnée a été effectuée dans la base de données du site local et que la deuxième mise à jour n'a pas été exécutée entre les deux bases de données, le site local commande une annulation de l'opération sur la donnée dans la base de données du site local. Le système de gestion de données exécutant le procédé selon l'invention est robuste. En effet, lors d'une défaillance de communication entre le site local et le site maître distant, le site local peut accéder en lecture et en écriture dans la base de données locale aux données dont il gère l'état d'accès en écriture, c'est-à-dire pour ces dites données le site local est le site maître. Le site local accède en lecture aux autres données. Pendant la défaillance de communication avec le site distant, le site local fonctionne en mode dégradé. Selon une autre réalisation de l'invention, le site local est le site maître. Selon l'une ou l'autre des réalisations de l'invention, un ensemble de données mémorisé par duplication dans les deux bases de données est formé de groupes de données disjoints, l'un des groupes comportant ladite donnée, l'état d'accès en écriture de chaque donnée d'un groupe de données étant géré par un des deux sites. Selon l'une ou l'autre des réalisations de l'invention, l'état d'accès à la donnée est vérifié dans le site maître au moyen d'une table d'accès appariant un identificateur de la donnée à un jeton lorsque l'accès en écriture à la donnée est à l'état verrouillé et supprimant le jeton lorsque l'accès en écriture à la donnée est à l'état accessible. L'invention concerne également un système de gestion de données gérant au moins une donnée mémorisée dans au moins deux bases de données comprises respectivement dans deux sites distincts appartenant à un même réseau et formant ledit système de gestion de données, ladite donnée étant associée à un état d'accès en écriture géré par un site maître, la dite donnée étant partagée en lecture et en écriture par des applications implémentées sur des terminaux de chaque site, et ladite donnée étant apte à être sollicitée pour une opération en écriture par une application d'un site local. Le système comprend : - des moyens pour vérifier l'état d'accès en écriture à la donnée dans le site maître, - des moyens pour verrouiller l'accès en écriture à la donnée dans le site maître, - des moyens pour traiter l'opération sur la donnée dans la base de données du site local, et - des moyens pour déverrouiller l'accès en écriture à la donnée dans le site maître. L'invention comprend également un site de gestion apte à gérer une donnée mémorisée dans au moins deux bases de données distinctes comprises respectivement dans deux sites distincts formant un système de gestion de données, le site de gestion de données étant apte à mettre en oeuvre le procédé selon l'invention. L'invention comprend également un programme d'ordinateur apte à être mis en oeuvre dans un site de gestion de données, ledit programme étant caractérisé en ce qu'il comprend des instructions qui, lorsque le programme est exécuté dans le site de gestion de données, réalisent des étapes du procédé selon l'invention. D'autres caractéristiques et avantages de la présente invention apparaîtront plus clairement à la lecture de la description suivante de plusieurs réalisations de l'invention, données à titre d'exemples non limitatifs, en référence aux dessins annexés correspondants dans lesquels : - la figure 1A montre schématiquement un système de gestion de données partagées, selon un mode de réalisation de l'invention; - la figure 1B montre schématiquement un site de gestion compris dans un système de gestion de données partagées, selon un mode de réalisation de l'invention; - les figures 2 à 4 sont des diagrammes fonctionnels du procédé de gestion de données, en mode de fonctionnement normale du système, selon 30 un mode de réalisation de l'invention ; et - la figure 5 est un diagramme fonctionnel du procédé de gestion de données, en mode de fonctionnement dégradé du système, selon un mode de réalisation de l'invention. Les différents éléments apparaissant sur les différentes figures 35 conservent, sauf précision contraire, les mêmes références. Dans ce qui suit, différents modes de réalisations seront décrits selon une représentation d'un système de gestion de données, sans, cependant, restreindre l'invention aux termes et expressions divulguées. L'invention est applicable dans tout système de gestion de données multi-sites nécessitant un partage de données entre différents sites du système. Différentes configurations de systèmes impliquant différentes technologies peuvent être utilisées séparément ou en combinaison pour implémenter les réalisations de l'invention. Les technologies évoluant constamment, les réalisations de l'invention peuvent exiger de nombreuses modifications qui sont évidentes pour un homme du métier. La figure 1A est une architecture d'un système de gestion de données multi-sites simplifiée dans laquelle sont représentés quelques éléments et entités fonctionnelles, tous étant des unités logiques dont l'implémentation peut différer de ce qui est représenté. Les connections montrées dans la figure 1 sont des connections logiques, les connections physiques actuelles peuvent être différentes. Il est évident pour un homme du métier que les systèmes comprennent également d'autres fonctions et structures. Il devrait être considéré que les fonctions, structures, éléments et protocoles utilisés dans ou pour des communications dans le système de gestion de données, ne sont pas pertinents pour l'invention actuelle. Par conséquent, ils n'ont pas besoin d'être décrits plus en détail ici. En référence à la figure 1A, un système de gestion de données SG est destiné à implémenter un procédé de gestion de données partagées selon l'invention. Le système de gestion de données comprend N sites de gestion géographiquement distincts : ST1 à STN, avec l'indice N étant un nombre entier supérieur ou égal à deux. On entend par donnée partagée, une donnée qui est accessible par les applications de tous les sites du système de gestion. Chaque site STn, avec 1 n N, comprend au moins un terminal Tn mis à la disposition d'un utilisateur et implémentant une ou des applications. Chaque site STn comprend également une interface d'accès IAn gérant l'accès à un ensemble de données mémorisées dans une base de données BDn. Une application du terminal Tn peut solliciter à l'interface d'accès un accès à la base de données. L'interface d'accès IAn est reliée à un serveur de jeton SJn. Le serveur de jeton est apte à gérer des états d'accès en écriture d'une partie des données de la base de données locale BDn. Dans le serveur de jeton, une telle donnée est associée à un état d'accès en écriture qui indique l'accessibilité en écriture de la donnée. Si la donnée est accessible en écriture, l'état d'accès en écriture est alors à l'état accessible. Si l'accès en écriture à la donnée est verrouillé, l'état d'accès en écriture est alors à l'état verrouillé. Le terme état d'accès en écriture est également écrit état d'accès dans la suite de la description. Chaque site STn comprend une interface de communication (non représentée) pour communiquer entre eux via un réseau de communication R, avec ou sans fil, tel qu'un réseau WAN ("Wide Area Network" en anglais) ou un réseau LAN ("Local Area Network" en anglais) utilisant par exemple le protocole internet IP. Le réseau R peut être un réseau sécurisé. Ainsi chaque site STn peut communiquer avec les autres sites du système de gestion de données via le réseau R. Toutes ces unités An, Tn, IAn, SJn et BDn sont représentées sous forme de blocs fonctionnels dont la plupart assurent des fonctions ayant un lien avec l'invention et peuvent correspondre à des modules logiciels et/ou matériels. Selon un exemple de réalisation d'un site de gestion illustré à la figure 1B, chaque site STn peut comporter plus particulièrement une unité de contrôle UCn reliée à un terminal Tn du site via une interface de communication ICn comprise dans l'unité UCn. L'interface de communication ICn permet également de communiquer avec les interfaces de communication des autres sites via le réseau R. L'unité de contrôle comprend au moins un microprocesseur Mln, un ensemble de mémoires MEn et la base de données BDn. Les différents éléments ICn, Mln, MEn, et BDn de l'unité de contrôle sont reliés entre eux par un bus bidirectionnel. L'interface d'accès IAn et le serveur de jeton SJn sont considérés comme des modules logiciels et sont répartis dans l'ensemble des mémoires MEn. Les mémoires peuvent être des mémoires volatiles ou non volatiles, par exemple EEPROM, ROM, PRM, RAM, DRAM, SRAM, microprogramme, logique programmable et mémorisent typiquement des contenus, données ou analogue. De plus les mémoires peuvent mémoriser des codes programmes d'ordinateur par exemple les codes programmes des systèmes d'exploitation. Les mémoires peuvent être par exemple à accès aléatoire, ou un disque dur, ou une combinaison de ces moyens. De plus les mémoires peuvent être des mémoires amovibles ou détachables connectées à l'unité de contrôle. La base de données peut être incorporées dans l'unité de contrôle UCn, ou être indépendante sous la forme d'un serveur de gestion de base de données (non représenté dans la figure 1B) qui est relié à l'unité de contrôle avec ou sans fil. La base de données peut comprendre une unité de traitement pour exécuter notamment des mises à jour de données et une ou plusieurs mémoires pour mémoriser les données partagées. L'interface de communication ICn peut comprendre une ou plusieurs unités de réception pour recevoir différentes données d'entrée et une ou plusieurs unités d'envoi pour envoyer différentes données de sorties, les données étant des informations de contrôle, des demandes et réponses, par exemple. L'unité de réception et l'unité d'envoi comprennent un transmetteur et/ou un récepteur ou un moyen correspondant pour transmettre et recevoir des informations et exécuter les fonctions nécessaires afin que les contenus, les informations de contrôle, etc puissent être reçus et ou transmis. Les unités de réception et de transmission peuvent comprendre un ensemble d'antennes, le nombre n'étant pas limité à un nombre en particulier. La suite de la description décrit plus en détail les différentes unités composant un des sites de gestion du système SG, appelé site de gestion local STn. Le site local STn peut communiquer avec au moins un site distant STd, avec 1 _ Un groupe de données maître dans une base de données locale BDn est un groupe de données dont l'état d'accès associé à chaque donnée du groupe est géré localement par le serveur de jeton local SJn. En variante un état d'accès associé au groupe maître lui-même peut être mémorisé dans le serveur de jeton local. Le groupe de données est considéré comme groupe de données maître dans une base de données et comme groupe de données esclave dans les autres bases de données du système de gestion de données multi-sites. Une des bases de données du système peut comprendre uniquement des groupes de données esclaves. Pour toute donnée appartenant à un groupe de données maître dans la base de données locale et appartenant par conséquence aux groupes de données esclave correspondants dans d'autres sites, le site local correspond au site maître desdites données. Un accès en écriture à une donnée d'un groupe de données maître dans la base de données locale BDn ne nécessite pas une mise à jour de la donnée dans les autres bases de données du système de gestion. Les données d'un groupe de données maître dans la base de données locale sont considérées comme étant toujours à jour. Un groupe de données esclave dans la base de données locale BDn est un groupe de données dont l'état d'accès en écriture associé à chaque donnée du groupe est géré dans un site maître distant distinct du site local. Un site maître distant gérant les états d'accès associés aux données d'un groupe de données esclave de la base de données locale peut être différent d'un autre site maître distant gérant les états d'accès associés aux données d'un autre groupe de données esclave de la base de données locale Un site maître distant STd comprend un serveur de jeton distant SJd pour mémoriser l'état d'accès associé à chaque donnée du groupe de données maître distant correspondant à un groupe de données esclave de la base de données locale. Un site maître distant STd comprend également une base de données, dite base de données distante BDd, mémorisant en partie ou en totalité les mêmes groupes de données que la base de données locale, en particulier les données dudit groupe de données maître distant. L'accès à une donnée du groupe esclave dans la base de données locale BDn par l'interface d'accès locale IAn nécessite zéro, une ou deux mises à jour de la donnée partagée, selon le type d'accès, par duplication de la donnée entre le groupe de données esclave mémorisé dans la base de données locale BDn et le groupe de données maître distant correspondant mémorisé dans la base de données distante BDd. On entend par terminal Tn, une station de travail tel qu'un ordinateur portable, un livre électronique, un téléphone évolué ("smartphone" en anglais), un ordinateur personnel, un micro-ordinateur, un assistant personnel numérique ou un dispositif embarqué dans un véhicule. Le terminal Tn comporte une ou plusieurs applications locales An aptes à se connecter à l'interface d'accès locale IAn pour solliciter l'accès à une donnée partagée. Une application An peut être une application opérant sur des données partagées mémorisées dans les bases de données BD1 à BDN du système de gestion de données SG. Une ou des applications AI à AN forment, par exemple, un logiciel de gestion d'une bibliothèque multi-site comportant des groupes d'abonnés, des groupes livres et des groupes d'auteurs sur plusieurs sites. Les applications AI à AN peuvent également correspondre à un logiciel de gestion des ressources humaines d'une grande entreprise implantée sur plusieurs sites. Ces applications accèdent à un ensemble de bases de données dans lesquelles sont enregistrés des groupes d'employés, des groupes de managers, des groupes métier, des groupes projet, etc. Les opérations demandées par une application locale An à effectuer sur une donnée partagée impliquent des accès en lecture ou en écriture à la donnée dans la base de données locale BDn. Plus particulièrement, l'accès en écriture à la donnée peut correspondre soit à une opération de modification de la donnée, une opération de suppression de la donnée ou une opération de création de la donnée dans un groupe de données maître ou esclave de la base de données locale BDn. Selon l'opération requise et selon le type de groupe maître ou esclave comprenant la donnée partagée, l'accès à la donnée implique une gestion différente par l'interface d'accès locale IAn. Lors d'une lecture de la donnée dans un groupe maître ou esclave la donnée est considérée comme toujours accessible en lecture. Avant l'opération de lecture de la donnée appartenant à un groupe de données esclave, une mise à jour de la donnée peut être exécutée entre la base de données locale BDn et la base de données distante BDd mémorisant le groupe de données maître correspondant. Avant une modification de la donnée dans la base de données locale BDn pour l'application locale An, l'accès en écriture à la donnée dans toutes les bases de données est préalablement mis à l'état d'accès verrouillé pour les autres applications du système SG. Le verrouillage de l'accès en écriture à la donnée permet d'éviter tout conflit d'accès multiple à la donnée dans les différentes bases de données du système. Avant une suppression de la donnée dans la base de données locale BDn pour l'application An, les accès en écriture respectivement à toutes les données du groupe de données incluant la donnée à supprimer dans toutes les bases de données sont préalablement mis à l'état d'accès verrouillé pour les autres applications du système SG. Le verrouillage des accès en écriture respectivement des données du groupe permet d'éviter tout conflit d'accès multiples aux données dans les différentes bases de données. Avant une création d'une donnée dans la base de données locale BDn pour l'application locale An, l'accès en écriture à un nouvel identificateur unique de donnée à associer à la donnée à créer dans toutes les bases de données est préalablement mis à l'état d'accès verrouillé pour les autres applications du système SG afin d'éviter tout conflit de non unicité de la donnée. En outre, lors d'un accès en lecture ou en écriture à une donnée, ou à son identificateur unique, appartenant à un groupe de données esclave zéro, une ou deux mises à jour de la donnée selon le type d'opération requise, entre la base de données locale Bdn et la base de données distante BDd incluant le groupe de données maître correspondant sont exécutées. Ces mises à jour sont décrites plus en détail ultérieurement en référence au diagramme fonctionnel illustré aux figures 2 à 4. L'interface d'accès locale IAn analyse l'opération requise par l'application locale An et la ou les données concernées par l'opération. L'interface d'accès locale IAn vérifie via le serveur de jeton local SJn l'état d'accès en écriture associé à la donnée partagée, la donnée appartenant soit à un groupe de données maître soit à un groupe de données esclave de la base de données locale BDn. Pour accéder à une donnée vérifiée à l'état d'accès accessible, l'interface d'accès IAn commande le verrouillage puis le déverrouillage, une fois l'opération terminée, de l'accès à la donnée ou au groupe de données associé pour les autres applications du système SG. Le serveur de jeton local exécute la commande de verrouillage /déverrouillage de l'interface d'accès soit localement soit en faisant appel à un serveur de jeton distant. Si la donnée appartient à un groupe de données esclave, l'interface d'accès locale IAn commande une ou deux mises à jour, selon le type d'accès, des bases de données locale et distante. Les mises à jour entre les deux bases de données sont exécutées de manière connue. Par exemple une première base de données transmet un journal de données modifiées vers une deuxième base de données qui duplique les données modifiées et les mémorise par écrasement des données initiales. Ces mises à jour garantissent une donnée cohérente dans toutes les bases de données. De même l'interface d'accès locale IAn peut commander périodiquement la mise à jour des groupes de données esclaves contenus dans la base de données locale BDn afin d'éviter une trop grande divergence dans le temps entre les bases de données du système SG. En variante, c'est l'unité de traitement de la base de données locale qui commande et exécute la mise à jour des groupes de données esclaves. Lors de la détection du mode dégradé du système SG, due à une défaillance du système SG, l'interface d'accès locale IAn rend impossible ou annule toutes opérations effectuées sur des données de groupes esclaves si ces opérations n'ont pas été mises à jour dans les bases de données distantes contenant les groupes de données maître correspondants. Puis, l'interface d'accès lAn commande le déverrouillage des accès aux données de groupes esclaves qui ont été précédemment verrouillés. Ces opérations de déverrouillage seront effectuées dés le rétablissement de la liaison. Le serveur de jeton local vérifie SJn si une donnée d'un groupe de données maître est accessible. Le serveur de jeton local exécute le verrouillage/déverrouillage de l'accès à cette donnée. Dans le serveur de jeton SJn l'accès en écriture à une donnée partagée appartenant à un groupe de données maître de la base de données locale est verrouillé lorsque l'état d'accès associé à la donnée est mémorisé à l'état verrouillé. Plus particulièrement, l'état verrouillé correspond à un verrou, appelé également jeton, associé à la donnée dans le serveur de jeton local SJn. De même, dans le serveur de jeton, l'accès en écriture à la donnée partagée appartenant à un groupe de données maître de la base de données locale est accessible lorsque l'état d'accès associé à la donnée est mémorisé à l'état accessible, c'est-à-dire que la donnée n'est pas associée à un jeton. Un état d'accès peut également être associé à un groupe de données maître local dans le serveur de jeton local, un état d'accès verrouillé étant considéré comme identique pour toutes les données du groupe de données maître local, chaque donnée du groupe étant associée à un jeton. Selon une réalisation de l'invention, la mémorisation de l'état d'accès associé à une donnée dans un serveur de jeton local est réalisée dans une table de jeton locale TJn. La table de jeton locale TJn apparie chaque identificateur unique de donnée partagée appartenant à un groupe de données maître de la base de données locale BDn à un jeton, si l'accès en écriture à la donnée est à l'état verrouillé. Pour un identificateur d'une donnée compris dans la table de jeton TJn et non apparié à un jeton, l'accès en écriture à la dite donnée est considéré à l'état accessible. De même pour un état d'accès associé à un groupe de données maître local dans le serveur de jeton local, le serveur apparié toutes les données du groupe respectivement à un jeton si l'accès en écriture au groupe de données est à l'état verrouillé. Un identificateur unique de donnée peut être apparié à un type de jeton selon l'opération en cours de traitement sur la donnée partagée. Un jeton, dit jeton de modification, est apparié à un identificateur de donnée à modifier. Dans ce cas, l'accès en écriture à la donnée est à l'état verrouillé pour modification. Un jeton, dit jeton de suppression, est apparié à un identificateur de groupe de données dans lequel au moins une donnée est à supprimer. Dans ce cas, l'accès en écriture à chaque donnée du groupe est à l'état verrouillé. Un jeton, dit jeton de création, est apparié à un identificateur de donnée à associer à la donnée une fois celle-ci créée. En variante, la table de jeton TJn ne comprend que les identificateurs des données ou groupes de données maîtres chacun apparié à un type de jeton tel que précédemment décrit et dont l'accès en écriture à la donnée est à l'état verrouillé. Pour les identificateurs de données appartenant à des groupes de données maîtres non présents dans la table, l'accès en écriture auxdites données est considéré comme non verrouillé et est à l'état accessible. Pour vérifier si une donnée d'un groupe de données esclave est accessible et/ou pour exécuter le verrouillage/déverrouillage de l'accès à cette donnée, le serveur de jeton local fait appel au serveur de jeton distant qui gère l'état d'accès associé à ladite donnée. Le serveur de jeton distant comprend également une table de jeton. Une défaillance du système SG est détectée par le serveur de jeton local SJn lorsqu'il ne peut pas communiquer avec un serveur de jeton distant. De même, une défaillance du système SG est détectée par la base de données locale BDn lorsqu'elle ne peut pas communiquer avec une base de données distante. En variante, c'est l'interface de communication du site local qui détecte une défaillance du système SG lorsqu'elle ne peut pas communiquer avec une autre interface de communication d'un site distant. Le site local passe alors en mode dégradé et seules les données appartenant aux groupes de données maître peuvent être accessibles en écriture et lecture par les applications locales. Les données appartenant à des groupes de données esclaves dans la base de données locale et dont l'état d'accès en écriture ne peut être vérifié sont accessibles uniquement en lecture. Selon la donnée et/ou selon l'opération à effectuer sur la donnée des règles d'accessibilité appelées RA dans la suite de la description peuvent être également associées aux données. Ces règles doivent être satisfaites pour considérer la donnée comme accessible. Si la règle d'accessibilité associée à la donnée est satisfaite et si l'accès à la donnée n'est pas à l'état verrouillé, la donnée est réputée accessible. Au contraire, si la donnée est à l'état accessible et que la règle d'accessibilité associée n'est pas satisfaite alors la donnée est réputée non accessible. Un exemple de règle d'accessibilité RA concerne des liens établis ou potentiellement à établir entre des données de groupes différents. Ces règles permettent d'éviter qu'une donnée liée à une autre donnée d'un même groupe ou d'un autre groupe de données ne soit supprimée, pouvant de ce fait entrainer un problème de cohérence dans les bases de données. Les règles d'accessibilité peuvent également empêcher la suppression ou la modification de certaines données lorsqu'un site de gestion spécifique ou quelconque est en mode dégradé. Des règles d'accessibilités peuvent être, par exemple, appliquées dans un système gérant des bases de données relationnelles. Ces règles d'accessibilité peuvent être mémorisées dans une table de règles TR appariant chaque règle à un identificateur unique de données ou de groupe de données. La table de règles TR peut-être mémorisée dans chaque interface d'accès du système SG. Pour vérifier l'accessibilité d'une donnée partagée l'interface locale d'accès doit vérifier si la donnée est associée à un jeton et si la règle associée à la donnée est satisfaite. Afin de communiquer avec les sites distants, chaque site locale STn peut comprendre une table de localisation. La table de localisation apparie chaque identificateur de groupes de données mémorisés dans la base de données locale à l'identificateur du site maître correspondant. Cet identificateur de site correspond par exemple à une adresse réseau de site. La table de localisation peut être mémorisée dans l'interface d'accès locale lAn. En variante, la table de localisation peut être mémorisée également dans le serveur de jeton local. En variante encore, la table de localisation TL est mémorisée dans toute entité du système SG, par exemple l'interface de communication ou la base de données locale, permettant d'informer sur l'identité d'un site apparié à un groupe de données maître. Les diagrammes fonctionnels AGI, AG2 et AG3 représentent les étapes du procédé de gestion d'une donnée partagée D appartenant à un groupe de données Gm dans la base de données locale BDn, en fonctionnement normal du système SG. Les diagrammes fonctionnels AGI, AG2 et AG3 sont implémentés dans chaque site du système SG. Le diagramme fonctionnel AGI illustré à la figure 2 comprend plus particulièrement les étapes du procédé selon l'invention lors d'une demande d'accès en lecture à une donnée de la base de données locale BDn. Le diagramme fonctionnel AGI comprend les étapes principales El-1 à El-15. A l'étape E1-1, une application locale An sollicite un accès à une donnée partagée à l'interface d'accès locale IAn. Ainsi l'application An transmet à l'interface d'accès locale IAn une demande d'opération DOP(Id-D) sur une donnée D identifiée par l'identificateur unique Id-D. A l'étape E1-2, l'interface d'accès locale IAn analyse la demande et vérifie si la demande d'opération DOP demandée nécessite un accès à la donnée en lecture - référencé "READ" sur la figure 2 - ou en écriture. Si l'opération nécessite un accès en écriture à la donnée, le procédé est exécuté selon les étapes du diagramme fonctionnel AG2 décrit ultérieurement en référence à la figure 3. Si l'opération nécessite un accès en lecture à la donnée, l'interface d'accès lAn vérifie à l'étape E1-3, si la donnée D appartient à un groupe de données maître - référencé GMn sur la figure 2- ou un groupe de données esclave. Cette vérification est, par exemple, effectuée en faisant appel à la base de données locale dans laquelle est définie l'appartenance de la donnée à un groupe de données esclave ou maître. En variante, la vérification peut se faire en fonction de la table de localisation. Si l'identificateur du groupe de données comportant la donnée est apparié à l'identificateur du site local alors le groupe est considéré comme groupe maître. Dans le cas contraire le groupe est considéré comme groupe esclave. A l'étape E1-3, si la donnée appartient à un groupe de données esclave, l'interface d'accès vérifie, à l'étape E1-4, si la dernière mise à jour de la donnée entre la base de données locale BDn et la base de données distante BDd, comprenant le groupe maître correspondant audit groupe esclave, a été commandée par l'interface d'accès locale lAn. Par exemple, un indicateur UD-D, appelé également "flag" en anglais, associé à la donnée D dans l'interface d'accès lAn, est mis à la valeur 1 dès que la mise à jour de la donnée D, commandée par l'interface d'accès locale, a été exécutée. Puis, un message notifiant la mise à jour de la donnée ou du groupe de données esclave est envoyé depuis le site ayant commandé la dernière mise à jour vers les autres sites distants comportant respectivement les bases de données mémorisant le groupe de données défini comme esclave. A la réception de ce message chaque site récepteur met à zéro l'indicateur UD-D correspondant indiquant de ce fait que la dernière mise jour de la donnée D n'a pas été commandée par l'interface d'accès du site. Selon cette réalisation l'interface d'accès de chaque site comprend une table appariant un indicateur UD-D à l'identificateur unique d'une donnée D. D'autres réalisations connues peuvent être appliquées permettant de vérifier si la dernière mise à jour de la donnée D a été commandée par l'interface d'accès locale. A l'étape E1-4, si la dernière mise à jour de la donnée D n'a pas été commandée par l'interface d'accès locale (UD-D = 0), alors l'interface d'accès locale commande la mise à jour de la donnée D entre la base de données locale BDn et la base de données distante BDd. La mise à jour est exécutée de manière connue entre les deux bases de données. Par exemple, l'interface d'accès IAn transmet une demande de mise à jour DU(Id-D, ld-STd), à la base de données locale BDn, à l'étape E1-5. La demande DU comporte l'identificateur Id-D de la donnée D et l'identificateur ld-STd du site maître distant Td comportant la base de données distante BDd, l'identificateur ld-STd pouvant être mémorisé dans la table de localisation. Après retransmission de la demande de mise à jour DU(Id-D) depuis la base de données locale vers la base de données distante, à l'étape E1-6, la mise à jour de la donnée D ou du groupe de données associé mémorisé dans la base de données distante vers la base de données locale, est exécutée à l'étape E1-7. Selon une méthode connue, la mise à jour d'une donnée ou d'un groupe de données d'une première base de données vers une deuxième base de données est effectuée par transmission d'un journal de données répertoriant uniquement les différences entre les deux bases de données. Une donnée qui n'a pas été modifiée dans l'une des bases de données n'est pas mise à jour dans l'autre base de données. Une donnée qui a été modifiée entre les deux bases de données est mise à jour par duplication de la donnée dans une des deux bases de données pour être mémorisées dans l'autre base de données. Après mise à jour des bases de données, une réponse de mise à jour RU(ld-D), à l'étape E1-8, est transmise depuis la base de données locale vers l'interface d'accès locale. A l'étape E1-9, l'interface d'accès locale prend en compte qu'elle est l'initiatrice de la dernière mise à jour de la donnée D, par exemple en mettant à un l'indicateur UD-D, et en informe les autres sites distants comportant respectivement les bases de données mémorisant le groupe de données défini comme esclave. A l'étape E1-10, si la donnée appartient à un groupe de données maître 35 selon l'étape E1-3, ou si la donnée D appartient à un groupe de données esclave et que l'interface d'accès locale a commandé la dernière mise à jour de la donnée selon l'étape E1-4 ou l'étape E1-9, alors l'interface d'accès locale informe, l'application locale que la donnée D est accessible en lecture. Par exemple, l'interface d'accès IAn transmet une réponse d'opération ROP(OK, Id-D) à l'application An, en identifiant la donnée par son identificateur Id-D. A la réception de la réponse ROP(OK, Id-D) et aux étapes E1-11 et E1-12, l'application An transmet une opération de lecture OP(Id-D) à la base de données locale BDn via l'interface d'accès lAn, en identifiant la donnée D par son identificateur Id-D. A la réception de l'opération OP, à l'étape E1-13, la base de données locale BDn traite l'opération OP sur la donnée D. Puis, aux étapes E1-14 et E1-15, la base de données transmet un acquittement de l'opération ACK-OP(Id-D) à l'application An via l'interface d'accès IAn. En mode de fonctionnement dégradé du site local Tn, lorsque le site local ne peut communiquer avec le site distant Td, l'interface d'accès locale peut autoriser ou interdire l'accès en lecture à la donnée dans la base de données locale. Cette autorisation peut être établie dans les règles d'accessibilité RA selon, par exemple, un niveau de cohérence souhaitée de la donnée lue et/ou selon l'utilisation qui va en être faite par l'application locale. A l'étape E1-2, si l'opération requise par l'application locale An nécessite un accès en écriture à la donnée, le procédé est exécuté selon les étapes du diagramme fonctionnel AG2. En référence à la figure 3, le diagramme fonctionnel AG2 comprend plus particulièrement les étapes du procédé selon l'invention lors d'un accès en écriture à la donnée appartenant à un groupe maître de la base de données locale BDn. Le diagramme fonctionnel AG2 comprend les étapes principales E2-1 à E2-18. Après vérification que l'opération requise par l'application An nécessite un accès en écriture à la donnée, à l'étape E1-2 du diagramme fonctionnel AGI, l'interface d'accès IAn vérifie, à l'étape E2-1, si la donnée D appartient à un groupe de données maître GMn ou un groupe de données esclave. L'étape E2-1 est similaire à l'étape E1-3 du diagramme fonctionnel AGI, et n'est donc pas décrite de manière détaillée. Si la donnée appartient à un groupe de données esclave, le procédé est exécuté selon les étapes du diagramme fonctionnel AG3 décrit ultérieurement en référence à la figure 4. Si la donnée appartient à un groupe de données maître, l'interface d'accès IAn transmet au serveur de jeton local SJn, à l'étape E2-2, une demande de vérification de jeton DVJ(Id-D) pour vérifier l'état d'accès en écriture à la donnée. La demande DVJ(Id-D) comporte notamment l'identificateur unique Id-D de la donnée D. A l'étape E2-3, à la réception de la demande DVJ(Id-D), le serveur de jeton local SJn vérifie localement dans la table de jeton locale TJn si l'identificateur de la donnée Id-D est apparié à un jeton J,. Puis, à l'étape E2-4, le serveur de jeton local SJn transmet une réponse de vérification de jeton RVJ(Id-D) à l'interface d'accès locale lAn informant de l'état d'accès en écriture à la donnée Didentifiée dans la réponse RVJ par son identificateur Id-D. A l'étape E2-5, l'interface d'accès IAn reçoit la réponse RVJ(ld-D). Si l'identificateur de la donnée ou du groupe de données est apparié à un jeton : TJn[Id-D] = J selon la réponse RVJ alors l'accès à la donnée est à l'état verrouillé. L'interface d'accès locale IAn transmet alors, à l'étape E2-6, une réponse d'opération ROP(NOK, Id-D) à l'application An indiquant que la donnée D n'est pas accessible en écriture. Selon une variante, si l'accès en écriture à la donnée est à l'état accessible et si une règle d'accès RA associée à la donnée ou au groupe de données, vérifiée par l'interface d'accès locale, n'est pas satisfaite, l'interface d'accès locale IAn transmet, à l'étape E2-6, une réponse d'opération ROP(NOK) à l'application An indiquant que la donnée D n'est pas accessible en écriture. L'application An réitérera sa demande d'opération ultérieurement en exécutant de nouveau l'étape El-1 du diagramme fonctionnel AGI. A l'étape E2-5, si l'identificateur de la donnée ou du groupe de données n'est pas apparié à un jeton alors l'accès à la donnée est à l'état accessible, et, selon la variante précédente, si une règle d'accès RA associée à la donnée ou au groupe de données, vérifiée par l'interface d'accès est satisfaite, la donnée est considérée comme accessible en écriture. A l'étape E2-7, l'interface d'accès locale IAn commande le verrouillage de l'accès en écriture à la donnée par mémorisation de l'état d'accès à la donnée à l'état verrouillé dans le serveur de jeton local SJn, à l'étape E2-8. Plus particulièrement l'interface d'accès locale IAn transmet au serveur de jeton local SJn, à l'étape E2-7, une demande de création d'un jeton DCJ(ld-D) à associer à la donnée D afin de verrouiller l'accès en écriture à la donnée. A l'étape E2-8, dès la réception de la demande DCJ(ld-D) et pour une opération de modification sur la donnée D, le serveur de jeton SJn apparie dans la table de jeton TJn l'identificateur de la donnée Id-D à un jeton de modification. Pour une opération de suppression d'une donnée D, le serveur de jeton local SJn apparie l'identificateur du groupe de données Gm associé à la donnée D à un jeton de suppression ce qui revient à apparier tous les identificateurs des données appartenant audit groupe de données respectivement à un jeton de suppression. Pour une opération de création d'une donnée, l'identificateur unique Id-D à associer à la donnée est généré par l'interface d'accès et est apparié à un jeton de création dans la table de jeton local TJn par le serveur de jeton local SJn. Dans ce cas, le serveur de jeton local SJn notifie par un message les autres serveurs de jetons du système SG que l'accès à l'identificateur Id-D est verrouillé. A la réception dudit message les autres serveurs de jeton enregistrent dans leur table de jeton locale l'appariement de l'identificateur Id-D à un jeton de création. Puis à l'étape E2-9, le serveur de jeton local SJn transmet à l'interface d'accès locale IAn une réponse RCJ(ld-D) de création de jeton apparié à l'identificateur Id-D de la donnée D ou au groupe de données associé. A l'étape E2-10, à la réception de la réponse de création de jeton RCJ(Id-D), l'interface d'accès locale IAn transmet à l'application locale An une réponse d'opération ROP(OK) indiquant que l'application An peut accéder à la donnée D dans la base de données locale BDn. Selon une variante de réalisation et afin d'éviter un grand nombre d'échanges de messages entre l'interface d'accès locale et le serveur de jeton local, la vérification de l'accessibilité de la donnée - étape E2-3 - et la création d'un jeton associé à cette donnée vérifiée accessible - étape E2-8 - sont exécutées dans une même étape. Les étapes E2-4 à E2-7 sont supprimées et une nouvelle étape est ajoutée après l'étape E2-9. De manière plus détaillée, à l'étape E2-2 modifiée pour cette variante, l'interface d'accès locale transmet une demande de vérification de jeton et de création de jeton si la donnée est vérifiée accessible. Aux étapes E2-3 et E2-8, si la donnée est déjà verrouillée, aucun jeton n'est créé. Si la donnée est accessible, un jeton est créé tel que décrit précédemment. Puis le serveur de jeton local transmet, à l'étape E2-9, une réponse de vérification et de création à l'interface d'accès locale. Puis, dans une nouvelle étape, l'interface d'accès traite la réponse et transmet une réponse à l'application locale. Si l'accès à la donnée a été vérifiée à l'état verrouillé, l'interface d'accès transmet à l'application la réponse ROP(NOK, Id-D) - selon l'étape E2-6 - indiquant ainsi que l'application ne peut pas accéder à la donnée. Par contre, si un jeton a été créé et associé à la donnée, l'interface d'accès transmet la réponse ROP(OK, Id-D) - selon l'étape E2-10 - indiquant ainsi que l'application peut accéder à la donnée D. Selon l'une ou l'autre des réalisations précédentes, à la réception de la réponse ROP(OK) et aux étapes E2-11 et E2-12, l'application An transmet une opération OP(Id-D) à la base de données locale BDn via l'interface d'accès IAn, l'opération OP étant à traiter sur la donnée associée à l'identificateur Id-D. A l'étape E2-13, la base de données locale BDn reçoit l'opération OP, traite l'opération sur la donnée D et renvoie aux étapes E2-14 et E2-15, un acquittement de l'opération ACK-OP(Id-D), à l'application An via l'interface d'accès locale lAn. A l'étape E2-16, à la réception de l'acquittement ACK-OP, l'interface d'accès locale IAn commande le déverrouillage de l'accès en écriture à la donnée par mémorisation de l'état d'accès à la donnée à l'état accessible dans le serveur de jeton local SJn, à l'étape E2-17. Plus particulièrement, à l'étape E2-16, l'interface d'accès locale IAn transmet au serveur de jeton local SJn une demande de suppression DSJ(ld-D) de jeton apparié à l'identificateur Id-D de la donnée D ou du groupe de données associé. A l'étape E2-17 et à la réception de la demande de suppression de jeton DSJ, le serveur de jeton local SJn déverrouille l'accès à la donnée D : TJn[Id- 2 5 D] = 0 en supprimant le jeton associé à l'identificateur Id-D.Ainsi, après une opération de modification sur la donnée D, le serveur de jeton SJn supprime dans la table de jeton locale TJn le jeton de modification apparié à l'identificateur de la donnée Id-D. Après une opération de suppression d'une donnée D, le serveur de jeton SJn supprime dans la table de jeton locale le 30 jeton de suppression apparié à l'identificateur du groupe de données Gm associé à la donnée D ou en variante supprime tous les jetons de suppression appariés respectivement aux identificateurs des données appartenant audit groupe de données. Après une opération de création d'une donnée, le serveur de jeton local supprime le jeton de création apparié 35 à l'identificateur unique associé à la donnée créée et notifie par un message les autres serveurs de jeton du système SG que ledit identificateur Id-D n'est plus verrouillé et est associé à une donnée. A la réception du message les autres serveurs de jeton suppriment dans leur table de jeton locale l'appariement de l'identificateur Id-D au jeton de création et supprime également l'identificateur Id-D. L'identificateur Id-D associé à la donnée créée peut être mémorisé dans chaque table d'allocation en association avec le groupe comportant la donnée créée. A l'étape E2-18, le serveur de jeton SJn transmet à l'interface d'accès IAn, une réponse de suppression RSJ(ld-D) de jeton. En revenant à l'étape E2-1, la donnée est vérifiée appartenir à un groupe de données esclave et le procédé est exécuté selon les étapes du diagramme fonctionnel AG3 illustré à la figure 4. En référence à la figure 4, le diagramme fonctionnel AG3 comprend plus particulièrement les étapes du procédé selon l'invention lors d'un accès en écriture à la donnée appartenant à un groupe de données esclave de la base de données locale BDn. Le diagramme fonctionnel AG3 comprend des étapes E3-1 à E3-31. Après vérification que la donnée appartient à un groupe de données esclave, à l'étape E2-1 du diagramme fonctionnel AG2, l'interface d'accès locale IAn transmet, à l'étape E2-2 du diagramme fonctionnel AG3, au serveur de jeton local SJn une demande de vérification de jeton DVJ(ld-D, ld-STd). La demande de vérification DVJ(ld-D, ld-STd) permet de vérifier l'état d'accès à la donnée et comporte l'identificateur de la donnée Id-D ainsi que l'identificateur du site distant maître Id-STd associé dans la table de localisation à l'identificateur du groupe de données comportant la donnée D. A l'étape E3-3, le serveur de jeton local SJn ayant reçu la demande de vérification de jeton DVJ retransmet la demande DVJ(ld-D) au serveur de jeton distant SJd compris dans le site maître distant Td pour vérifier l'état d'accès à la donnée D. L'étape E3-3 est identique à l'étape E2-3 du diagramme fonctionnel AG2. Puis à l'étape E3-4, pour informer sur l'état d'accès en écriture à la donnée D, le serveur de jeton distant SJd transmet une réponse de vérification de jeton RVJ(ld-D) au serveur de jeton local SJn qui retransmet la réponse de vérification de jeton RVJ(ld-D), à l'interface d'accès locale IAn à l'étape E3-5. A l'étape E3-6, similaire à l'étape E2-5 du diagramme fonctionnel AG2, l'interface d'accès locale IAn reçoit la réponse RVJ(ld-D) et la traite. Si l'accès à la donnée est à l'état verrouillé, c'est-à-dire si l'identificateur de la donnée ou du groupe de données est apparié à un jeton : TJd[Id-D] = J selon la réponse RVJ, l'interface d'accès locale IAn transmet, étape E3-7, à l'application An une réponse d'opération ROP(NOK, Id-D) indiquant que la donnée D identifiée par l'identificateur Id-D n'est pas accessible en écriture. Selon une variante, si l'accès en écriture à la donnée est à l'état accessible et si une règle d'accès RA associée à la donnée ou au groupe de données, vérifiée par l'interface d'accès locale, n'est pas satisfaite, l'interface d'accès locale IAn transmet, à l'étape E3-7, la réponse d'opération ROP(NOK, Id-D) à l'application An. L'application An réitérera sa demande d'opération ultérieurement en exécutant de nouveau l'étape E1-1 du diagramme fonctionnel AGI. A l'étape E3-6, si l'accès en écriture à la donnée est à l'état accessible c'est-à-dire que l'identificateur de la donnée ou du groupe de données n'est pas apparié à un jeton selon la réponse RCJ, et selon la variante précédente, si une règle d'accès RA associée à la donnée ou au groupe de données, vérifiée par l'interface d'accès, est satisfaite, la donnée est considérée comme accessible en écriture. A l'étape E3-8, l'interface d'accès locale IAn commande le verrouillage de l'accès en écriture à la donnée. Plus particulièrement, l'interface d'accès locale IAn transmet au serveur de jeton local SJn, à l'étape E3-8, une demande de création d'un jeton DCJ(Id-D, Id-STd) à associée à la donnée D afin de verrouiller l'accès en écriture à la donnée. La demande DCJ comporte l'identificateur de la donnée Id-D ainsi que l'identificateur du site maître distant Id-STd comportant le serveur de jeton distant SJd qui va exécuter la demande. A l'étape E3-9, le serveur de jeton local SJn ayant reçu la demande DCJ retransmet la demande de création d'un jeton au serveur de jeton distant SJd. Le serveur de jeton distant SJd apparie, à l'étape E3-10, dans la table de jeton distante TJd, l'identificateur de la donnée Id-D à un jeton de modification, de suppression ou de création selon l'opération requise. L'appariement d'un identificateur d'une donnée à un jeton dans la table de jeton distante, à l'étape E3-10 est identique à celui effectué dans la table de jeton locale TJn, à l'étape E2-8 du diagramme fonctionnel AG2. A l'étape E3-11, le serveur de jeton distant SJd transmet au serveur de jeton local SJn une réponse RCJ(Id-D) de création de jeton apparié à l'identificateur de la donnée D ou du groupe de données associé. Le serveur de jeton local SJn retransmet la réponse RCJ à l'interface d'accès locale IAn, à l'étape E3-12. Selon une variante de réalisation et afin d'éviter un grand nombre d'échanges de messages entre l'interface d'accès locale et le serveur de jeton distant via le serveur de jeton local, la vérification de l'accessibilité de la donnée - étape E3-3 - et la création d'un jeton associé à cette donnée vérifiée accessible - étape E3-10 - sont exécutées dans une même étape. Les étapes E3-4 à E3-9 sont supprimées et une nouvelle étape est ajoutée après l'étape E3-12. De manière plus détaillée, aux étapes E3-2 et E3-3 modifiées selon la variante, l'interface d'accès locale transmet une demande de vérification de jeton et de création de jeton si la donnée est vérifiée accessible au serveur de jeton distant via le serveur de jeton local. Dans le serveur de jeton distant, aux étapes E3-3 et E3-10 modifiées selon la variante, si la donnée est vérifiée verrouillée, selon l'étape initiale E3-3, aucun jeton n'est créé. Si la donnée est vérifiée accessible, selon l'étape initiale E3-3, un jeton est créé tel que décrit précédemment à l'étape initiale E3-10. Puis le serveur de jeton distant transmet via le serveur de jeton local, aux étapes E3-11 et E3-12 modifiées selon la variante, une réponse de vérification et de création à l'interface d'accès locale. Puis, dans une nouvelle étape, l'interface d'accès locale traite la réponse et transmet une réponse à l'application locale An. Si l'accès à la donnée a été vérifiée à l'état verrouillé selon la réponse de vérification et de création précédente, l'interface d'accès locale IAn transmet à l'application locale An la réponse ROP(NOK, Id-D) - selon l'étape initiale E3-7 - indiquant ainsi que l'application ne peut pas accéder à la donnée. Par contre, si un jeton a été créé et associé à la donnée, selon la réponse de vérification et de création précédente, l'interface d'accès exécute l'étape E3-13 telle que décrite ci-après. Selon cette variante, les règles d'accessibilité RA peuvent être traitées directement dans le serveur de jeton distant, la donnée n'étant pas accessible en écriture si la règle associée n'est pas satisfaite. Ou encore les règles d'accessibilité peuvent être traitées dans l'interface d'accès locale avant les étapes E3-1 et E3-2. Ainsi les étapes E3-1 et E3-2 ne sont pas exécutées si la règle d'accès associée à la donnée n'est pas satisfaite. Selon l'une ou l'autre des réalisations précédentes, à l'étape E3-13, à la réception de la réponse RCJ, l'interface d'accès locale IAn commande une première demande de mise à jour DU1(D, ld-STd) de la donnée D ou du groupe de données comportant la donnée D entre la base de données locale BDn et la base de données maître distante BDd. La demande DU1 est transmise vers la base de données locale BDn et comporte l'identificateur de la donnée Id-D et l'identificateur du site maître distant ld-STd comportant la base de données distante. A l'étape E3-14, la base de données locale BDn transmet la demande DU1 à la base de données distante BDd qui, à l'étape E3-15, met à jour la donnée ou le groupe de données associé dans la base de données locale BDn. La mise à jour est effectuée de manière identique qu'à l'étape E1-7 du diagramme fonctionnel AGI. La première mise à jour de la base de données locale BDn, permet à l'application An d'opérer sur une donnée D exacte et cohérente. Pour une opération de création de la donnée dans la base de données locale, la première mise à jour DU1 peut ne pas être exécutée puisque la donnée n'est pas encore créée. En variante pour une création de la donnée D, les données du groupe de données qui comportera la donnée à créer peuvent être mises à jour une première fois, avant la création de la donnée D. A la fin de la première mise à jour, étape E3-16, la base de données locale BDn transmet à l'interface de gestion d'accès locale IAn une première réponse de mise à jour RU1(Id-D, ld-Sd) indiquant que la mise à jour a été exécutée. A l'étape E3-17, l'interface d'accès locale IAn prend en compte qu'elle est l'initiatrice de la dernière mise à jour de la donnée D, par exemple en mettant à 1 l'indicateur UD-D associé à la donnée D, et en informe les autres sites distants comportant respectivement les bases de données mémorisant le groupe de données défini comme esclave. Puis, l'interface d'accès locale IAn transmet à l'application locale An une réponse d'opération ROP(OK, Id-D) indiquant que l'application An peut accéder à la donnée D dans la base de données locale BDn. La réponse ROP comporte l'identificateur Id-D de la donnée D. A la réception de la réponse ROP(OK,ld- D) et aux étapes E3-18 et E3-19, l'application An transmet une opération OP(Id-D) sur la donnée D identifiée par l'identificateur Id-D, à la base de données locale BDn via l'interface d'accès lAn. A l'étape E3-20, la base de données locale BDn reçoit l'opération OP, traite l'opération sur la donnée D et renvoie aux étapes E3-21 et E3-22, un acquittement ACK-OP(Id-D) de l'opération sur la donnée D à l'application locale An via l'interface d'accès locale IAn. A l'étape E3-22, l'interface d'accès locale IAn transmet une deuxième demande de mise à jour DU2(Id-DD, ld-STd) de la donnée D ou du groupe de données comportant la donnée D entre la base de données locale BDn et la base de données distante BDd. La demande DU2 transmise vers la base de données locale BDn comporte l'identificateur Id-D de la donnée D et l'identificateur ld-STd du site maître distant comportant la base de données distante BDd. A l'étape E3-23, la base de données locale BDn met à jour la donnée D ou le groupe de données comportant la donnée D dans la base de données distante BDd selon une méthode connue de mise à jour des données. Cette méthode peut être similaire à celle décrite lors de la mise à jour de la donnée D ou le groupe de données comportant la donnée D de la base de données distante BDd vers la base de données locale à l'étape E3-15. La deuxième mise à jour est exécutée pour une opération de modification, suppression ou de création de la donnée D qui appartient à un groupe de données esclave. Après l'exécution de la deuxième mise à jour, la base de données maître distante BDd peut transmettre une réponse de mise à jour exécutée RU2(Id-D) vers la base de données locale BDn qui transfère la réponse à l'interface d'accès locale. Après réception de la réponse RU2, l'interface d'accès locale IAn transmet un acquittement ACK-OP(Id-D)d'opération sur la données D à l'application An, à l'étape E3-26. Egalement, après réception de la réponse RU2, à l'étape E3-27, l'interface d'accès locale IAn commande le déverrouillage de l'accès en écriture à la donnée. Plus particulièrement, à l'étape E3-27, l'interface d'accès local transmet au serveur de jeton local SJn une demande de suppression DSJ(Id-D, ld-STd) du jeton apparié à l'identificateur Id-D de la donnée D ou du groupe de données associé dans le serveur de jeton distant du site distant identifié par l'identificateur ld-STd. A la réception de la demande RSJ, à l'étape E3-28, le serveur de jeton local transfert la demande RSJ au serveur de jeton distant SJd. Puis à l'étape E3-29, le serveur de jeton distant supprime le jeton apparié à l'identificateur Id-D de la donnée dans la table de jeton distante TJd et libère l'accès en écriture à la donnée D. Aux étapes E3-30 et E3-31, le serveur de jeton distant SJd transmet une réponse de suppression du jeton RSJ(ld-D) au serveur de jeton local SJn qui transfert la réponse RSJ à l'interface d'accès locale IAn. Le site local peut faire appel à plusieurs exécutions simultanées des diagrammes fonctionnels AGI à AG3 lorsqu'une ou plusieurs applications locales demandent des accès simultanés à des données partagées. Les exécutions d'étapes identiques lors du traitement de plusieurs demandes d'accès simultanées pourront être mutualisées afin d'optimiser le temps de traitement desdites demandes. Le fonctionnement en mode dégradé d'un site local est établi dès que le site local STn ne peut communiquer avec un site distant STd. En fonctionnement normal ou dégradé du site local, les applications locales peuvent accéder en lecture et en écriture aux données partagées appartenant à des groupes maîtres dans la base de données locale si les règles d'accessibilité sont satisfaites. Les applications locales peuvent également accéder en lecture et en écriture aux données partagées appartenant à des groupes esclaves de la base de données locale lorsque le site local peut communiquer avec le site maître distant qui gère l'état d'accès en écriture aux données desdits groupes de données esclaves, si les règles d'accessibilité sont satisfaites. Dans ces deux derniers cas, le site local fonctionne normalement selon les diagrammes fonctionnels AGI à AG3. Les applications locales peuvent accéder uniquement en lecture aux données du ou des groupes de données esclaves dont les états d'accès en écriture sont gérés par un site ou des sites maîtres ne pouvant communiquer avec le site local. Dans ce dernier cas et relativement aux groupes de données esclaves non accessibles en écriture, le site local fonctionne en mode dégradé selon les diagrammes fonctionnels AG3 et AG4. Le diagramme fonctionnel AG4 illustré à la figure 5 présente les étapes principales du procédé de gestion d'au moins une donnée partagée D appartenant à un groupe de données esclave dans la base de données locale BDn, lors de la détection du fonctionnement en mode dégradé du système SG, plus particulièrement lors de la détection d'une défaillance de communication entre le site local et le site distant maître gérant les états d'accès des données du groupe de données comportant la donnée D. Le diagramme fonctionnel AG4 est implémenté dans chaque site du système SG et fonctionne parallèlement aux diagrammes fonctionnels AGI à AG3, plus particulièrement au diagramme fonctionnel AG3. Le diagramme fonctionnel AG4 comprend principalement les étapes E4-1 à E4-11. L'étape E4-1 comprend la détection d'une défaillance de communication entre le site local et le site maître distant, impliquant de ce fait un fonctionnement en mode dégradé du site local. Tant qu'aucune défaillance n'a été détectée, l'étape E4-1 est rebouclée sur elle-même. La défaillance de communication est détectée par le serveur de jeton local ou la base de données locale. Lorsque le serveur de jeton local SJn ne peut pas communiquer avec le serveur de jeton distant SJd, aux étapes E3-2, E3-9 ou E3-28 du diagramme fonctionnel AG3, une défaillance de communication est détectée. Ou lorsque la base de données locale BDn ne peut pas communiquer avec la base de données distante BDd aux étapes E3-14, E3-15 et E3-23, E3-24 du diagramme fonctionnel AG3 une défaillance de communication est détectée. Si une défaillance est détectée à l'étape E4-1, le serveur de jeton local SJn ou la base de données locale BDn transmet à l'interface d'accès locale IAn un message Msg-MD(Id-G) notifiant que les données du groupe de données esclave correspondant identifié par l'identificateur Id-G ne sont pas accessibles en écriture. A la réception du message Msg-MD(Id-G), à l'étape E4-2 du diagramme fonctionnel AG4, l'interface d'accès locale IAn informe l'application locale An que la donnée requise est disponible uniquement en lecture. Pour ce faire l'interface d'accès locale transmet un message Msg-read(Id-D) à l'application An., le message comportant l'identificateur Id-D de la donnée D. L'accès à la donnée en mode lecture par l'application locale est effectué selon le diagramme fonctionnel AGI. Puis, à l'étape E4-4, l'interface d'accès locale IAn vérifie si un jeton est créé dans la table de jeton distante TJd et est apparié à l'identificateur Id-D de la donnée D. Par exemple, si l'interface d'accès locale IAn a préalablement reçu une réponse de création de jeton RCJ(ld-D), transmise à l'étape E3-11 du diagramme fonctionnel AG3, alors un jeton a précédemment été créé. L'interface d'accès locale transmet alors au serveur de jeton locale SJn une demande de suppression DSJ(Id-D, Id-STd) du jeton. La demande de suppression DSJ comporte l'identificateur Id-D de la donnée ou du groupe de données apparié au jeton et l'identificateur Id-STd du site distant comportant le serveur de jeton distant SJd. Puis, à l'étape E4-6, le serveur de jeton local SJn mémorise la demande DSJ(Id-D, Id-STd) afin de la transmettre ultérieurement au serveur de jeton SJd distant du site distant identifié par l'identificateur ld-STd, une fois que la communication entre le site local et le site distant sera de nouveau opérationnelle. L'interface d'accès exécute ensuite l'étape E4-7. Toujours à l'étape E4-4, si la vérification indique qu'aucun jeton n'est créé et n'est apparié à l'identificateur Id-D de la donnée D, l'interface d'accès locale IAn exécute directement l'étape E4-9. A l'étape E4-7, l'interface d'accès locale IAn vérifie si une opération liée à un accès en écriture sur la donnée a été exécutée dans la base de données locale BDn et si une deuxième mise à jour de la donnée opérée a 1 0 été exécutée entre la base de données locale BDn et la base de données distante BDd. Par exemple pour vérifier qu'une opération d'écriture sur la donnée a été exécutée, l'interface d'accès locale IAn vérifie qu'elle a reçu un acquittement ACK-OP(Id-D) de l'opération, transmise par la base de données locale à l'étape E3-21 selon le diagramme fonctionnel AG3. De 15 même, par exemple, pour vérifier que la deuxième mise à jour de la donnée opérée entre la base de données locale BDn et la base de données distante a été exécutée, l'interface d'accès locale IAn vérifie qu'elle a reçu une réponse de mise à jour RU2(Id-D) envoyée par la base de données locale BDn, à l'étape E3-25 du diagramme fonctionnel AG3. Si une modification a 20 été effectuée dans la base de données locale BDn et qu'aucune deuxième mise à jour entre la base de données locale et la base de données distante n'a été exécutée alors l'interface d'accès locale IAn commande à la base de données locale BDn d'annuler l'opération précédente effectuée sur la donnée D. Pour ce faire l'interface d'accès transmet une demande AOP(Id- 25 D)) d'annulation de l'opération comportant l'identificateur Id-D de la donnée D à l'étape E4-8 du diagramme fonctionnel AG4. La base de données locale BDn restaure la donnée telle qu'elle était avant le traitement de l'opération. L'interface d'accès locale exécute ensuite l'étape E4-9. A l'étape E4-9, le site local STn vérifie s'il peut communiquer de 30 nouveau avec le site distant STd et peut détecter ainsi un retour au fonctionnement en mode normal du site local. Tant qu'une défaillance est détectée, c'est-à-dire tant que le site local est en mode dégradé, l'étape E4-9 se reboucle sur elle-même. A l'étape E4-9, lorsque le site local peut de nouveau communiquer avec le site distant, le serveur de jeton local SJn ou 35 la base de données locale BDn transmet à l'interface d'accès locale IAn un message Msg-MN(Id-G) notifiant le retour au fonctionnement en mode normal et ainsi que les données du groupe de données esclave correspondant identifié par l'identificateur Id-G sont accessibles en écriture et en lecture, à l'étape E4-10. Puis à l'étape E4-11, le serveur de jeton local SJn transmet la demande de suppression de jeton mémorisée DSJ(Id-D, Id-STd) au serveur de jeton distant STd qui exécute le déverrouillage de l'accès à la donnée D en supprimant le jeton apparié à l'identificateur Id-D de la donnée ou du groupe de données dans la table de jeton distante TJd. Au retour du mode normal de fonctionnement le serveur de jeton local peut avoir plusieurs demandes de suppression mémorisées relatives respectivement à plusieurs données partagées pouvant appartenir à différents groupes de données esclaves dans la base de données locale. Le serveur de jeton local transmet toutes les demandes de suppression de jeton mémorisées aux différents sites distants inaccessibles durant le fonctionnement en mode dégradé du site local. Puis le site local exécute de nouveau l'étape E4-1 de détection du mode dégradé. L'exécution du procédé de gestion de données partagée en mode dégradé n'est pas limitée à la succession des étapes selon le diagramme fonctionnel AG4. Plusieurs étapes peuvent être exécutées simultanément. Par exemple l'étape E4-2 et l'ensemble des étapes successives E4-4 à E4-8 peuvent être exécutées en parallèle. L'exigence de cohérence des données dans les différentes bases de données du système SG selon l'invention est satisfaite. D'une part, grâce à la gestion d'un état d'accès en écriture à chaque donnée par un unique site maître spécifique pour chaque donnée qui permet d'éviter de multiples accès simultanés à la donnée par différentes applications du système SG. En effet, une seule application à la fois du système SG peut accéder en écriture à la donnée dans toutes les bases de données du système et l'accès en écriture à la donnée est verrouillé pour les autres applications du système. D'autre part, chaque opération est traitée sur une donnée cohérente. En effet, soit la donnée appartient à un groupe maître de la base de données locale et est considérée toujours à jour, soit la donnée appartient à un groupe esclave de la base de données locale et les deux mises à jour commandées par le site local permettent d'avoir une donnée cohérente dans les deux bases de données avant et après le traitement de l'opération sur la donnée. En fonctionnement dégradé du site local, si l'accès à une donnée appartenant à un groupe de données maître a été verrouillé par un autre site distant préalablement à la défaillance de communication entre les deux sites, l'accès en écriture à la donnée reste verrouillé pour le site local tant qu'une commande de déverrouillage de l'accès à la donnée n'a pas été transmise par l'autre site à l'étape E4-11 du diagramme fonctionnel AG4 appliqué dans le site distant. L'exigence de robustesse du système SG selon l'invention est satisfaite puisqu'en mode dégradé du site local seule une partie des données partagées dans la base de données locale est inaccessible en écriture. Le site local continue à accéder en écriture et en lecture aux données partagées appartenant aux groupes de données maître dans la base de données locale et appartenant également aux groupes de données esclaves dont les états d'accès des données sont gérés par des sites maîtres distants accessibles par le site local. Un site local comportant une base de données ne comprenant que des groupes esclaves peut tout de même accéder en lecture aux données de la base de données locale. Un utilisateur final considère le système SG comme ergonomique et performant. En effet, toutes les opérations annexes dudit système telles que les première et deuxième mises à jour de données dans les bases de données du système SG sont transparentes pour l'utilisateur. En outre, l'accès aux données des groupes de données maîtres d'un site local est aussi performant que s'il accédait aux données d'une base de données non distribuée. En effet, l'accès à ces dites données ne nécessite pas de mise à jour systématique entre deux bases de données et d'échange avec un serveur de jeton distant. Selon un exemple, un système de gestion de données multi-sites SG gère des bases de données relationnelles. Chaque base de données relationnelle sur un même site mémorise des données dans un même groupe selon une même caractéristique. Par exemple dans un système de gestion de données tel que la gestion d'une bibliothèque sur plusieurs sites, un ou plusieurs groupes peuvent comprendre des données relatives à des titres de livre chaque donnée pouvant être associée à des informations complémentaires sur le livre. Un ou d'autres groupes peuvent comprendre des données relatives à des abonnés de la bibliothèque chaque donnée pouvant être associée à des informations caractérisant l'abonné telles que des informations personnelles. Et Un ou d'autres groupes peuvent comprendre des données relatives à des auteurs chaque donnée pouvant être associée à des informations caractérisant l'auteur, telles que sa bibliographie. Une donnée d'un groupe peut être liée à au moins une donnée d'un autre groupe. Par exemple, une donnée relative à un abonné dans un groupe d'abonnés est liée à une donnée relative à un livre emprunté par l'abonné dans un groupe livres qui elle-même est liée à une donnée relative à l'auteur du livre dans un groupe d'auteurs. Les liaisons entre deux données peuvent être mémorisées dans des tables de liaisons, une liaison entre deux données correspondant à l'appariement des deux identificateurs des deux données. Dans les bases de données, chaque groupe de données peut comprendre une table de liaison appariant l'identificateur d'une donnée du groupe à un ou plusieurs identificateurs de données d'autres groupes. Selon cet exemple de base de données relationnelle, une opération d'écriture sur une donnée peut correspondre à l'établissement ou la suppression d'une liaison entre deux données de groupes différents. Une opération d'écriture peut comprendre également à une modification, une suppression ou à la création d'une donnée dans un groupe de données. Pour effectuer une opération d'écriture sur une première donnée liée à une deuxième donnée, les deux données doivent être préalablement vérifiées accessibles et verrouillées. La vérification d'accessibilité de chacune des deux données et le verrouillage de chacune des deux données sont exécutés selon les étapes E2-2 à E2-9 du diagramme fonctionnelle AG2 et/ou les étapes E3-1 à E3-12 du diagramme fonctionnel AG3, que l'une ou l'autre des deux données appartiennent à un groupe de données maître ou esclave dans la base de données locale. Puis l'opération d'écriture sur la première donnée s'exécute selon les étapes E2-10 à E2-15 du diagramme fonctionnel AG2 si la donnée appartient à un groupe de données maître, ou selon les étapes E3-13 à E3- 26 du diagramme fonctionnel AG3 si la donnée appartient à un groupe de données esclave. Puis les deux données liées sont déverrouillées selon les étapes E2-16 à E2-18 du diagramme fonctionnel AG2 et/ou E3-27 à E3-30 du diagramme fonctionnel AG3, selon que l'une ou l'autre des deux données appartient à un groupe de données maître ou esclave. Selon cet exemple, les règles d'accessibilité RA spécifiques associées aux groupes ou à chaque donnée partagée d'un groupe peuvent prendre en compte les différentes liaisons établies entre les données des différents groupes. Par exemple, une règle d'accessibilité relative à la suppression d'une donnée peut-être associée à la donnée empêchant toute suppression de la donnée dès lors que la donnée est liée à une ou plusieurs autres données d'un autre groupe. L'invention décrite ici concerne un procédé de gestion de données partagées implémenté dans chaque site d'un système de gestion de données SG. Selon une implémentation, les étapes du procédé de l'invention sont déterminées par les instructions d'un programme d'ordinateur incorporé dans l'unité de contrôle de chaque site du système SG. Le programme d'ordinateur apte à être mis en oeuvre en partie dans chaque unités de chaque site du système SG de l'invention comporte des instructions de programme qui, lorsque ledit programme est exécuté dans chaque site du système SG dont le fonctionnement est alors commandé par l'exécution du programme, réalisent une gestion des données partagées entre plusieurs sites du système SG conformément au procédé de l'invention. En conséquence, l'invention s'applique également à un programme d'ordinateur, notamment un programme d'ordinateur enregistré sur ou dans un support d'enregistrement lisible par un ordinateur et tout dispositif de traitement de données, adapté à mettre en oeuvre l'invention. Ce programme peut utiliser n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable pour implémenter le procédé selon l'invention. Le programme peut être téléchargé dans le dispositif via un réseau de communication, comme internet. Le support d'enregistrement peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage sur lequel est enregistré le programme d'ordinateur selon l'invention, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore une clé USB, ou un moyen d'enregistrement magnétique, par exemple un disque dur. REVENDICATIONS1 - Procédé de gestion d'une donnée (D) mémorisée dans au moins deux bases de données (BDn, BDd) comprises respectivement dans deux sites (STn, STd) distincts appartenant à un même réseau, ladite donnée étant associée à un état d'accès en écriture géré par un site maître, la dite donnée étant partagée en lecture et en écriture par des applications implémentées sur des terminaux de chaque site, et ladite donnée étant apte à être sollicitée pour une opération en écriture par une application d'un site local, ledit procédé comprenant les étapes suivantes : - vérification (E2-3, E3-3) de l'état d'accès en écriture à la donnée dans le site maître, - si l'accès en écriture à la donnée est à l'état accessible, verrouillage (E2-8, E3-10) de l'accès en écriture à la donnée dans le site maître, - traitement (E2-13, E3-20) de l'opération sur la donnée dans la base de données du site local, et - déverrouillage (E2-17, E3-29) de l'accès en écriture à la donnée dans le site maître. 2 - Procédé conforme à la revendication 1, caractérisé en ce que le site local est distinct du site maître, le site local communique avec le site maître pour commander au site maître l'exécution des étapes de vérification (E3-3) de l'état d'accès à la donnée et de verrouillage (E3-10), déverrouillage (E3-29) de l'accès en écriture à la donnée. 3 - Procédé conforme à la revendication 1 ou 2, caractérisé en ce qu'il comprend avant le traitement de l'opération, une commande d'une première mise à jour (E3-13 à E3-16) de la donnée dans la base de données du site local par duplication de la donnée mémorisée dans la base de données du site maître. 4 - Procédé conforme à l'une quelconques des revendications 1 à 3, caractérisé en ce qu'il comprend après le traitement de l'opération, une commande d'une deuxième mise à jour (E3-22 à E3-25) de la donnée dans la base de données du site maître par duplication de la donnée mémorisée dans la base de données du site local. 5 - Procédé conforme à l'une quelconques des revendications 1 à 4, 35 comprenant une détection (E4-1) d'une défaillance de communication entrele site local et le site maître par le site local, la donnée partagée dont l'état d'accès en écriture est géré par le site maître est accessible uniquement en lecture dans la base de données du site local. 6 - Procédé conforme à l'une quelconques des revendications 1 à 5, caractérisé en ce que lors d'une défaillance de communication entre le site local et le site maître, si l'accès en écriture à la donnée a été verrouillé dans le site maître, le site local mémorise (E4-6) une commande de déverrouillage de l'accès en écriture à la donnée à transmettre au site maître dès que la communication entre les deux sites est de nouveau établie. 7 - Procédé conforme à l'une quelconques des revendications 1 à 6, caractérisé en ce que lors d'une défaillance de communication entre le site local et le site maître, si préalablement à la détection de la défaillance l'opération sur la donnée a été effectuée dans la base de données du site local et que la deuxième mise à jour n'a pas été exécutée entre les deux bases de données, le site local commande (E4-8) une annulation de l'opération sur la donnée dans la base de données du site local. 8 - Procédé conforme à la revendication 1, caractérisé en ce que le site local est le site maître. 9 - Procédé conforme à l'une quelconque des revendications 1 à 8 caractérisé en ce qu'un ensemble de données mémorisé par duplication dans les deux bases de données est formé de groupes de données disjoints, l'un des groupes comportant ladite donnée, l'état d'accès en écriture de chaque donnée d'un groupe de données étant géré par un des deux sites. 10 - Procédé conforme à l'une quelconque des revendications 1 à 9, caractérisé en ce que l'état d'accès à la donnée est vérifié dans le site maître au moyen d'une table d'accès (TAn) appariant un identificateur de la donnée (Id-D) à un jeton (J) lorsque l'accès en écriture à la donnée est à l'état verrouillé et supprimant le jeton lorsque l'accès en écriture à la donnée est à l'état accessible. 11 - Système de gestion de données (SG) gérant au moins une donnée (D) mémorisée dans au moins deux bases de données (BDn, BDd) comprises respectivement dans deux sites (STn, STd) distincts appartenant à un même réseau et formant ledit système de gestion de données, ladite donnée étant associée à un état d'accès en écriture géré par un site maître, la dite donnée étant partagée en lecture et en écriture par des applications implémentéessur des terminaux de chaque site, et ladite donnée étant apte à être sollicitée pour une opération en écriture par une application d'un site local, ledit système comprenant : - des moyens (IGn, SJn, SJd) pour vérifier l'état d'accès en écriture à la donnée dans le site maître, - des moyens (SJn, SJd) pour verrouiller l'accès en écriture à la donnée dans le site maître, - des moyens (IGn) pour traiter l'opération sur la donnée dans la base de données du site local, et - des moyens (SJn, SJd) pour déverrouiller l'accès en écriture à la donnée dans le site maître. 12 - Système de gestion de données conforme à la revendication 11, étant apte à mettre en oeuvre un procédé selon l'une des revendications 1 à 10. 13 - Site de gestion (STn, STd) étant apte à gérer une donnée (D) mémorisée dans au moins deux bases de données distinctes (BDn, BDd) comprises respectivement dans deux sites distincts (STn, STd) formant un système de gestion de données, le site de gestion de données étant apte à mettre en oeuvre le procédé selon l'une des revendications 1 à 10. 14 - Programme d'ordinateur apte à être mis en oeuvre dans un site de gestion de données (STn), ledit programme étant caractérisé en ce qu'il comprend des instructions qui, lorsque le programme est exécuté dans le site de gestion de données, réalisent des étapes du procédé selon l'une des revendications 1 à 10.