Brevet FR2803062A1 — publié le 20010629

L'invention concerne un procédé d'administration distribué d'une base de données répartie. Elle concerne également une architecture pour la mise en oeuvre du procédé. Elle s'applique plus particulièrement à un annuaire électronique du même type, c'est-à-dire également réparti. Dans le cadre de l'invention, le terme "base de données" doit être compris dans son sens le plus général. Il concerne des bases de données proprement dites, d'architectures et de natures diverses : bases de données à structure hiérarchique, bases de données relationnelles etc., plus particulièrement orientées objets. Les objets sont des entités de diverses natures données élémentaires ou fichiers de données, pièces de logiciel, etc. Il concerne notamment des annuaires électroniques, qui constituent des bases de données particulières. Ce type d'annuaire intéresse notamment, mais non exclusivement, les grandes sociétés ou entités similaires, et plus particulièrement les sociétés dites multinationales ayant des implantations multiples, éventuellement très éloignées les unes des autres. L'essor des moyens de - transmission modernes permet de liaisons rapides et des communications à fort débit. On peut notamment citer le recours de plus en plus fréquent aux transmissions via le réseau Internet. Ici encore ce terme doit être compris dans son sens le plus général, Il englobe le réseau Internet proprement dit, mais aussi les réseaux intranet, extranet tout réseau utilisant des protocoles de transmission de type Internet. Cependant, il n'est pas en général souhaitable, ni même le plus souvent possible, de concentrer en un seul lieu toutes les données intéressant une entité du type précite, ne serait ce que pour des raisons de sécurité. On doit d'ailleurs rappeler que le réseau "ARPANET", prédécesseur du réseau Internet, avait notamment pour but de disséminer des ressources informatiques en des lieux géographiques éloignés les uns des autres et de les relier par un réseau de communication maillé (c'est- à-dire redondant). Une centralisation excessive conduirait également à une trop grande complexité des bases de données, Il existe aussi des données dites "sensibles" ou "critiques" qui nécessitent la mise en oeuvre de protections particulières lorsqu'elles sont transmises sur des liaisons publiques - chiffrage pour assurer la confidentialité, authentification, et/ou contrôle de l'intégrité. La multiplication de transmissions de ce type de données augmente les risques et les coûts. Il serait donc judicieux de les traiter le plus possible en local, c'est-à- dire le plus près possible de lieu d'utilisation principal, même les données constituent un sous-ensemble d'une base de données ou d'un annuaire global. Enfin, la tendance actuelle est de déléguer les responsabilités au niveau le plus bas possible. Pour répondre à ces différents besoins, parfois contradictoires, la tendance est également de répartir les informations dans les bases de données ou - annuaires distincts (et éventuellement géographiquement distants), ces sous-ér#ëembies étant liés et gérés par un système d'administration distribué. Il n'est pas pour autant souhaitable qu'un utilisateur local (ou plus généralement une application ou un processus local) ait autorité sur toutes données ou objets de l'ensemble. Généralement, à l'exception d'utilisateurs "privilégiés" (administrateur, officier de sécurité, les appellations variant selon les constructeurs), un utilisateur local a des habilitations qui sont limitées, sur tout au partie d'opérations (lecture, écriture, mise à jour, destruction etc.) pouvant être effectuées sur des objets locaux, mais aussi éventuellement sur des objets éloignés. De même, on prévoit un mécanisme de distribution de données ou plus généralement d'objets, notamment (mais non exclusivement) destiné à répliquer ces données ou objets dans différents sous-ensembles de la base de données ou de l'annuaire. Ces sous-ensembles peuvent être homogènes ou Ils peuvent notamment stocker des données de natures en tout ou partie différentes. Aussi, le besoin s'est très vite fait sentir d'avoir recours à des standards et, effectivement, de tels standards ont été proposés dans l'art connu. En ce qui concerne les annuaires, dès les années 70, l' "ISO" ("International Standard Organization") et l' 1UT' ("International Telecommunication Union", ex "CCITT") ont proposé un modèle, "OSV' ("Open Systems Interconnection") pour interconnecter des systèmes dits "ouverts". Ce modèle a conduit au standard dit "X.500" (versions 988, puis 1993). Ce standard s'est révélé complexe, notamment en ce qui concerne les annuaires associés aux transmissions par le réseau Internet, soit directement liés à celui-ci (annuaire de ressource réseau dit "DNS", pour "Domaine Name System"), soit tout simplement pour des annuaires (ou bases de donnees) répartis connectés entre eux par des liaisons empruntant le réseau Internet. Aussi, l'organisme connu sous le sigle "IEFT" ("Internet Engineering Task Force") a proposé un standard, que l'on peut qualifier d' "allégé", connu sous le sigle "LDAP" ("Lightweight Directory Access Protocol"). Ce standard mieux adapté aux besoins des applications Internet, mais convient egalement à d'autres applications mettant enjeu des bases de données ou des annuaires répartis. A titre d'exemple non exhaustif, on pourra trouver une description détaillée des caractéristiques d'annuaires standardises, ainsi que des principales caractéristiques des standard et protocole, X.500 et LDAP, dans l'article de Anne VINCENT et al, "Annuaires standardisés", paru dans "Les Techniques de l'Ingénieur", tome "H2 INFORMATIQUE", chapitre "H 2818", version mai 1999. Dans le cadre de l'application préférée de l'invention, c'est-à-dire l'administration distribuée d'un annuaire réparti, on aura recours avantageusement à ce protocole d'accès. Enfin, on peut indiquer que l'architecture globale de la base de données ou de l'annuaire peut mettre en ceuvre des relations entre sous-ensembles du type "maître-esclave" au "maître-maître". Ces rappels étant effectués, on constate, dans la pratique, un certain nombre de difficultés et/ou de problèmes. En effet, les traitements automatiques de relations entre objets appliqués sur des structures de données hiérarchisées et réparties sur plusieurs bases ou annuaires distincts pose des problèmes spécifiques délicats à résoudre. En particulier, la nécessité de mettre à jour, pour conserver la cohérence, des objets situés hors de l'habilitation du processus local de traitement, ou bien la difficulté d'accéder à des objets situés sur une base distante ne peuvent être traités par les mécanismes habituels de propagation 1 synchronisation mises à jour d'objets. Dans connu, on a tenté de remédier à ces problèmes, mais sans les résoudre façon satisfaisante. En effet, les techniques actuelles ne mettent en oeuvre des mécanismes "un pour un" de replications d'objets ou d'attributs d'objets. L'action sur des objets hors du domaine d'administration du processus local de mise à jour reste interdit. Cette disposition ne constitue donc pas un mécanisme offrant la fonctionnalité précitée désiree. L'invention vise à pallier les inconvénients des procédés et architectures base de données de l'art connu, et dont certains viennent d'être rapgelés, tout en répondant aux besoins qui se font sentir. L'invention se fixe pour but un procédé d'administration distribué d'une base de données répartie, notamment d'un annuaire réparti, et une architecture pour la mise en #uvre du procédé. Selon une première caractéristique importante du procédé selon l'invention, il prévu un mécanisme assurant la propagation de demandes d'actions coherentes à effectuer sur des objets distribués s'appuyant sur les mécanismes classiques de synchronisation automatique des objets distribués, ce qui constitue d'ailleurs un avantage, puisqu'il n'est besoin d'implanter un mécanisme spécifique. La synchronisation automatique objets répliqués sur différentes bases permet de transmettre toute création, modification ou suppression objet. Pour ce faire, selon une deuxième caractéristique importante, une sous- structure de base de données ou un sous-arbre d'annuaire est répliqué sur toutes les occurrences de la base ou de l'annuaire, se trouve dans le domaine d'administration de processus locaux spécialisés. Ce sous-ensemble d'objets distribués sera appelé ci-après "bus d'administration". Selon une autre caractéristique encore, le bus d'administration contient des objets dits d' "opération". La synchronisation automatique des objets sur l'ensemble des occurrences de base de données ou d'annuaire assure la circulation de ces objets, de manière comparable à la transmission physique de données sur un bus de communication. Selon une autre caractéristique encore, sur chaque occurrence concernée de base de donnée ou d'annuaire, une entité logicielle que appellera ci-après "agent d'administration local" prend en charge les actions demandées qu'il est capable de réaliser, c'est-à-dire pour lesquelles il possede une habilitation, et le signale en l' "écrivant" dans l'objet "opération". Dans une variante du procédé, il peut également modifier dynamiquement le contenu de l'objet "opération", voire en émettre un nouvel objet "opération.. Une des modifications possibles consiste en la transmission message destiné au processus émetteur indiquant qu'une ou plusieurs opérations particulières ont été exécutées et par qui. Un processus de signature d'une "opération" ou d'un message mettant en oeuvre des certificats, notamment selon la norme X.509, peut être avantageusement utilisé. Lorsque toutes les opérations sont effectuées, l'objet "opération" peut être détruit physiquement ou logiquement. Dans une variante préférée de réalisation de l'invention, comme il a eté indiqué, la base de données est constituée par un annuaire réparti répondant ' la norme 'X.500" précitée, plus particulièrement encore de technologie "LDAP". Dans ce cas, le "bus d'administration" est constitué par un n#ud X.500. définit, sous ce n#ud, des objets spécifiques, que l'on a appelé "opération", tant que classe d'objet non réservée par le standard X.500. L'invention a donc pour objet principal un procédé d'administration d'une base de données, ladite base de données étant du type réparti en moins deux sous-ensembles dits occurrences pour le stockage, dans moyens de mémorisation de ces occurrences, d'une pluralité de premiers objets, lesdites occurrences communiquant entre elles par l'intermédiaire de moyens transmission de données, ladite base de données comprenant des moyens dits de distribution/synchronisation de données pour la diffusion dans lesdites occurrences desdits premiers objets et leur réplication, en tout ou partie, lesdites occurrences étant sous le contrôle d'applications logicielles dites locales, ces applications ayant autorité sur une partie préétablie desdits premiers objets pour effectuer des opérations logiques de natures déterminées, caractérisé en ce qu'il comprend au moins une phase initiale consistant en la création d'un sous-ensemble spécifique répliqué dans toutes lesdites occurrences, dit bus d'administration distribué, et de création d'au moins une pièce de logiciel associée aux dites applications locales, dit agent d'administration local, lesdits agents d'administration locaux ayant la capacité de créer des deuxièmes objets, dits objets opération, enregistrés dans ledit bus d'administration distribué et d'effectuer des opérations élémentaires déterminées sur tous lesdits objets opération et leurs répliques, et sur une partie préétablie de ladite pluralité de premiers objets et/ou de leurs répliques, et en ce qu'il comprend au moins les étapes suivantes, initiées lors d'une opération effeçtuée sur l'un desdits premiers objets par l'une desdites applications locales et impliquant des opérations à effectuer sur au moins un autre desdits premiers objets sur lequel ladite application locale n'a pas autorité - a/ création d'un dit objet opération et son enregistrement dans ledit bus d'administration distribué ; b/ enregistrement, dans ledit objet opération, d'instructions concernant des opérations élémentaires restant à effectuer - c/ diffusion dans ledit bus d'administration dudit objet operation créé dans toutes lesdites occurrences, par l'intermédiaire desdits moyens de distribution/synchronisation de données, de manière à obtenir sa réplication dans lesdites occurrences ; d/ lecture par lesdits agents d'administration locaux desdites inscriptions enregistrées dans ledit objet opération ou ses réplications -, e/ exécution, en tout ou partie, par au moins un desdits agents d'administration locaux, desdites opérations élémentaires restant à réaliser sur un desdits objets opération ou sa réplique dans une desdites occurrences ; et Y modification conditionnelle dudit objet opération ou réplique, en fonction des opérations élémentaires effectuées par ledit agent d'administration local et/ou restant à effectuer, et répétition des étapes d/ et e/ jusqu'à ce que toutes lesdites opérations élémentaires soient effectuées. L'invention a encore pour objet une architecture pour la mise en couvre de ce procédé. L'invention va maintenant être décrite de façon plus détaillée en se référant aux dessins annexés, parmi lesquels : - la figure 1 illustre schématiquement l'architecture générale d'une base de données répartie selon l'art connu -, - la figure 2 illustre schématiquement un exemple concret simplifié de base données répartie selon l'art connu ; - la figure 3A illustre schématiquement un exemple d'architecture de base de données conforme à l'invention , la figure 3B illustre schématiquement, sur un exemple, de façon plus détaillée, un sous-ensemble de la base de données de la figure 3A et les principales étapes du procédé selon l'invention - et - la figure 4 illustre l'application du procédé selon l'invention à l'exemple base de données simplifié de la figure 2. La figure illustre schématiquement l'architecture générale d'une base de données répartie 1. On suppose que cette répartition est réalisée sur n sites distincts, références Si, ..., Si, _, S, Chaque site contient donc un sous- ensemble, appelé "occurrence" de la base de données globale 1, sous- ensembles référencés Bi, ..., Bi, ..., B, le terme "site" doit être entendu dans un sens général. Il n'implique pas obligatoirement un éloignement géographique. titre d'exemple, il peut s'agir de deux machines reliées par un dispositif communication type quelconque, ou encore de deux sous-ensembles même système traitement de l'information. Dans cas d'une base de données, on parle de sous-structures. Dans le cas d'un annuaire, on parle plus spécifiquement de sous-arbres. Chaque occurrence peut contenir des objets originaux, c'est-à-dire qui ne sont présents que dans cette occurrence, et/ou des objets répliqués, c!est-à-dire présents dans une ou plusieurs autre(s) occurrence(s). De façon classique, on prévoit un mécanisme 10 dit distribution/synchronisation des objets. Un tel mécanisme est bien connu l'Homme de Metier, et il est inutile de le décrire plus avant. Dans le cadre procédé de l'invention, on utilise ce mécanisme, sans modification. Pour le moins, des modifications éventuelles de ce mécanisme ne découlent pas directement de la mise en oeuvre du procédé de l'intention, On n'a pas représenté, sur la figure 1, les divers systèmes classiques associés à une base de données répartie - systèmes informatique de traitement de données et leurs dispositifs de mémoire associés, notamment pour le stockage des données de la base et de ses occurrences, dispositifs de communications entre sites, Si à S, (par exemple à base réseau Internet et/ou Intranet), dispositifs de sécurité pour les accès objets, etc. A l'exception de l'adoption de dispositions spécifiques à l'invention, qui seront préçJisés ci-après, tous ces systèmes et/ou dispositifs ne subissent pas de modifications. Avant de décrire de façon plus détaillée le procede d'administration distribué selon l'invention, on va décrire, par référence à la figure 2, un exemple simplifié de base de données, référencé 1', répartie sur deux sitesSA et SB. Plus précisément, la figure 2 illustre la structure associée à cette base de données, ses noeuds et ses branches. Les deux sous-structures associées aux occurrences de la base de données dans les sites SA et été également représentée, du moins partiellement. On suppose que le noeud racine (premier niveau) correspond à une classe d'objet de type "organisation", soit "0 Multinationale X', "X' étant le nom d'une multinationale possédant deux implantations, l'une aux Etats-Unis (site SA), l'autre en France.(site Sa). Les n#uds deuxième niveau correspondent à une classe d'objets que l'on appellera "pays" ou "C" (pour "Country'). Dans l'exemple de la figure 1, C = "France", pour l'occurrence du site SA, et C "Etats-Unis", pour l'occurrence du site SB. Dans ce dernier site, on trouve un n#ud de niveau trois, dont la classe d'objet est application", c'est-à- dire concernant une application particulière appelée "application Y, Cette application est associée à une liste d'autorisations d'accès par des personnes, généralement connue sous le sigle anglo-saxon "ACL". De même, dans l'exemple décrit, on trouve dans le siteSA un n#ud de niveau trois, de classe objet "personne". A cette personne particulière, référencee "personne Y' sont associées des autorisations lui permettant d'effectuer des opérations sur certaines applications de la base de données, non seulement en local mais a priori dans d'autres occurrences. La nature des opérations autorisees peut également être spécifiée (écriture, lecture, etc.). Cette liste est la liste duale de la liste "ACU précitée. On a également représenté sur la figure 2 des applications locales, référencées AA et As, pouvant agir sur les occurrences locales de la base de données 1'. On comprend aisément que, dans l'exemple précis décrit, 'il n'est pas généralement souhaité que l'une et/ou l'autre des applications locales, AA ou As, ait autorité sur la totalité des objets de l'annuaire 1'. Or si, par exemple, l'objpt "application x" doit être modifié (mise à jour, suppression, déplacement, etc.), il est primordial que les listes associées aux personnes ayant autorité sur cet objet soient mises à jour en conséquence. Dans l'hypothèse qu'il vient d'être prise, l'application As ne peut pas modifier l'objet "personne Y'. Le procédé selon l'invention vise à résoudre les problèmes de ce type et assurer une cohérence parfaite entre les différentes occurrences de l'annuaire 1'. Selon une première caractéristique du procédé selon l'invention, une sous-structure particulière est répliquée sur toutes les occurrences de la base de données. Cette sous-structure distribuée sera appelé "bus d'administration" ci-après. On prévoit, selon une caractéristique supplémentaire de l'invention, des objets spécifiques, que l'on appellera "objets opération" ci-après. Ces objets décrivent des opérations élémentaires à effectuer sur d'autres objets de la base de données. Le bus d'administration, en faisant appel au mécanisme classique de distribution/synchronisation d'objet (figure 1 - 10) fait "circuler" ces objets sur l'ensemble des occurrences de la base de données. Selon une autre caractéristique de l'invention, on prévoit également des entités spécifiques locales sur les occurrences concernées de l'annuaire, entités que l'on appellera "agents d'administration locaux". Il peut s'agir simplement de modules logiciels constitués par des modifications d'applications locales existantes (par exemple, figure 2 - AA et AB) pour les rendre compatibles avec le procédé de l'invention. Elles doivent notamment pouvoir une nouvelle classe d'objet constituée par ces objets "opération". Ce sont ces agents d'administration locale qui prennent en charge les actions demandées, pour moins celles qu'ils sont capables de réaliser. Par "capable", il faut entendre capacité physique de réaliser le type d'opération demandée, mais aussi le fait de posséder une habilitation pour effectuer l'opération demandée sur un objet donné. La figure 3A illustre schématiquement une architecture de base données conforme à l'invention. La base de données est désormais référencée 2, mais on retrouve, pouC l'essentiel, les éléments constitutifs d'une base de données conforme à l'art connu, telle qu'elle a été décrite en regard de la figure 1. On retrouve notamment les sites Si, ..., Si, ..., S, si on suppose qu'il existe n sites distincts, ainsi que les n occurrences de la base de données 2. Cependant, ces occurrences sont désormais référencées B'i, ..., Bi, _., B',, En effet, les occurrences de la base de données 2 sont constituée des sous-structures de base de données 1 (figure 1), qui restent inchangées, mais, selon caractéristique importante de l'invention, il existe une sous-structure supplémentaire et spécifique, répliquée dans toutes les occurrences. Cette sous-structure, référencée 21 (en traits hachurés sur la figure 3A), sera appelée ci-après "bus d'administration distribuée". On a également représenté schématiquement, sur la figure 3A, applications locales, référencées AI, ... 1 Ai, ..., A,. Chacune de ces applications, bien que supposée unique sur la figure 3A, peut naturellement en désigner plusieurs. Selon une autre caractéristique du procédé selon l'invention, lorsqu'un processus local (par exemple l'une des applications, Ai, -1 Ai, entreprend une action sur un objet local, que cette action entraîne des modifications sur d'autres objets (locaux ou éloignés) et que ces objets ne sont pas sous la responsabilité de ce processus local, il y a génération d'un objet l'on appellera "objet opération" décrivant les différentes actions élémentaires étapes logiques déjà effectuées sur l'objet en question et restant à effectuer par des agents d'administration locaux particuliers. contenu de l'objet opération (actions élémentaires restant à effectuer) evolue donc au fur et à mesure des actions partielles effectuée les agents d'administration locaux. Lorsque la dernière action élémentaire a été accomplie, l'objet opération peut être logiquement ou physiquement supprimé par le dernier agent d'administration intervenant. figure 3B illustre schématiquement, sur un exemple, de façon plus détaillée, bus d'administration local 21 et les principales étapes du procédé selop l'invention. Pour fixer les idées, on suppose, de façon purement arbitraire, trois objets 01 a 0.3, présents dans l'occurrence B', de la base de données sont répliqués dans les occurrences B'3 et B'8 - objets répliqués référencés 0'3, d'une part, et 0", à 0",, d'autre part. Ces trois objets sont symbolises, la figure 3B, par un carré, une croix et un cercle, respectivement. On suppose également que l'application Ai veuille modifier l'objet 01, et cette modification ait des répercussions précisément sur les objets 02 et On suppose enfin que l'application Ai n'a autorité que sur l'objet 01. zones d'autorité d'une application locale sont symbolisées, sur la figure des aires hachurées de l'occurrence qui lui est associée. L'application Ai modifie donc l'objet 01. Elle crée aussi, selon caractéristique de l'invention, un objet spécifique, à savoir l'objet operation précitée, dans le bus d'administration 21, référencé Op. L'application A, y "écrit" les opérations élémentaires restant à effectuer, qu'elle n'a pas pu faire elle même. l'occurrence, il s'agit de modifier également les objets 02 et sur lesquels elle n'a pas autorité. Habituellement, les applications locales, que ce soit Ai, A2 OU OU plus géneralement une application A, (figure 3A), ne savent pas créer l'objet ni le modifier. A pilori, il s'agit d'une nouvelle classe d'objet. Aussi, nécessaire de prévoir sur chaque occurrence de la base de données 2, B', et B'8, plus généralement Si (figure 3A), un agent d'administration local, comme il a été indiqué. Il peut s'agir d'une pièce de logiciel entièrement distincte ou d'un module spécifique intégré aux applications Ai, A2 ou A3, après modifications de celles-ci. Ces agents d'administration locaux (en traits hachurés), ont été référencés Ag,, A93 et Ag8, dans l'exemple de la figure 3B. De façon plus générale, un tel agent serait référencé Ag, pour une occurrence quelconque Bi (figure 3A) de la base de données 2. Le mécanisme de distribution/synchronisation de données 20 de la base de données 2 fait "circuler", sur le bus d'administration 21, l'objet O,p, créé dans l'occurrence B'l, dans les autres occurrences. Cette "circulati par diffusion s'effectue, comme pour tout objet devant être répliqué, de façon classique en soi.-,L'objet O,p est donc répliqué en 0'.p et 0",,p, dans les occurrences B'3 et B'8. Selon une des caractéristiques du procédé selon l'invention, toutes les applications locales, ou plus précisément tous les agents d'administration locaux, Agi, Ag3 et Ag8, ont autorité sur tous les objets du bus - 0#p et 0",,P. Il s'ensuit, dans l'exemple décrit, que les agents d'administration locaux Ag3 et Ag8, ont accès, notamment en lecture et en écriture, aux objets 0'.p et O"OPI respectivement. Ces agents peuvent également supprimer, logiquement ou physiquement l'un ou l'autre des objets Op à 0"op. L'objet 0'2, réplique de l'objet 02, se trouve dans zone de responsabilité de l'agent d'administration local Ag3. Ce dernier peut donc lire dans l'objet 0,p des instructions lui indiquant les opérations élémentaires restant à effectuer sur l'objet 0'2. Il effectue tout ou partie de ces opérations et écrit dans l'objet 0,,p les opérations qu'il a effectuées. Par contre, l'agent A.3 n'a pas accès à l'objet 0'3. C'est l'agent d'administration local Ag8 qui va effectuer les opérations restant à effectuer sur la réplique de 03, soit l'objet 0"3. Pour ce faire, il lit des instructions dans l'objet 0",p et les exécute. Normalement le processus est complété à ce stade. La dernière action de l'agent Ag3 peut consister en la destruction, physique ou logique, de l'objet 0",,p qui n'a plus lieu subsister. Cependant, à titre d'alternative, l'agent A.3 peut écrire dans l'objet 0",,p un message (signaux de complétion) destiné à l'agent Agi lui indiquant que le traitement demandé a été exécuté et, par exemple, par qui, à quel moment (données de chronodatage), etc. Ce message peut cumuler des informations de ce type, entrées par chacun des agents ayant participé au processus et acquises a chaque stade de celui-ci, En résumé, l'objet opération 0,,p et ses répliques sont éphémères. A titre d'alternative, il pourrait s'agir d'un objet permanent mis en veilleuse et réactivé pour exécuter le processus qui vient d'être décrit. Selon un mode de réalisation supplémentaire, tout ou partie des agents d'administration locaux peuvent ajouter dans les objets opération de façon dynamique, des actions élémentaires supplémentaires à effectuer les objets prévus initialement et/ou à effectuer sur des objets supplémentaires. Selon un autre mode de réalisation supplémentaire, tout partie des agents d'administration locaux peuvent créer des objets opération supplémentaires, à différents stades du processus. Les deux modes précédents sont naturellement combinables. Cette disposition avantageuse ajoute une grande souplesse au procède l'application initiatrice du processus n'a pas à connaître, a priori, toutes les implications des opérations élémentaires qu'elle requière. Cette disposition permet aussi à la structure de la base de données d'évoluer sans nécessiter de modifications importantes des composants propres au procédé de l'invention, voire sans nécessiter aucune modification. Il doit être clair qu'il peut exister, sans sortir du cadre de l'invention, plusieurs agents d'administration locaux affectés à une même occurrence de la base de données, chacun ayant par exemple autorité sur une partition de cette occurrence. La figure 4 illustre l'application du procédé selon l'invention à l exemple de base de données simplifié de la figure 2. La base de données est référencée2'. Selon l'une des caractéristiques de l'invention, on associe des agents d'administration locaux, AA et AgB, aux applications AA et AB, et on prévoit un bus d'administration 21 constitué par une sous-structure répliquée dans toutes les occurrences de la base 2'. Chaque agent d'administration local, AgA ou Ae, a pleine autorité sur tous les objets du bus d'administration. On suppose, comme précédemment, que l'on veuille modifier l'application "application È dans l'occurrence du site SB, voire la supprimer de la base de données 2'. Il est, a priori, nécessaire de modifier la ou les listes d'autorisation associée(s) aux personnes ayant accès, à un titre ou un autre, à l'application "application x", notamment "personne y" dans l'exemple Illustré par les figures 2 et 4. On suppose que l'agent d'administration A.,q n'a pas autorité sur l'objet "personne y". L'agent d'administration local Ai3 va alors créer un objet opération O,p indiquant qu'il va falloir modifier les objets de classe objet "personnes" figurant dans la liste "ACL". Il va écrire dans l'objet 0,,p les opérations élémentaires à effectuer (dans l'exemple illustré - modification de la liste associée à [?personne y") et éventuellement divers attributs et/ou paramètres. Parmi ceux-ci, pouCrait figurer la liste "ACU elle-même. L'objet 0,,p est diffusé par le mécanisme de distribution/synchronisation des objets : réplique O'.p. L'agent d'administration local AA qui a autorité sur l'objet "personne Y' détecte, à la lecture des instructions présentes dans l'objet O,p, qu'il doit effectuer une ou plusieurs opération(s) élémentaires sur l'objet "personne.V' et ces instructions lui indiquent la nature de cette/ces opération(s). Si le processus est complet après l'exécution opérations élémentaires prescrites, l'agent A_,A peut détruire physiquement logiquement l'objet O,p, ou exécuter l'une ou l'autre des opérations supplémentaires précédemment décrites .- compte-rendu à l'agent A.,q, ajout dynamique d'opérations élémentaires à effectuer, création d'un autre objet opération sur le bus 21, etc. Il y a lieu de remarquer que l'on n'affecte pas, a priori, une action élémentaire à un agent d'administration donné. Le procédé selon l'invention reste ainsi très souple : ce sont les agents d'administration qui décident de traiter ou non une action élémentaire. Il faut remarquer également que, grâce au mecanisme de synchronisation automatique standard existant, c'est-à-dire celui proposé par les éditeurs de bases de données ou d 'annuaires, tous les agents d'administration locaux peuvent surveiller l'état d'avancement des actions élémentaires sur la réplication locale de l'objet opération. Selon une variante supplémentaire du procédé selon l'invention on peut prévoir des agents spécialisés - par exemple un agent spécialisé dans la supervision. Un tel agent pourra déclencher un signal alarme, transmis à l'application initiatrice du processus, si après un temps prédéterminé ("time-out") des actions partielles restent non réalisées. Bien que l'on ait supposé jusqu'à ce stade de description, pour le moins implicitement, que le bus d'administration était physiquement distribué dans toutes les occurrences de la base de données, cette disposition n'est pas absolument nécessaire. Il suffit, que la sous-structure de base de données soit ilvue" logiquement par tous les agents d'administration locaux, En résumé, le procédé selon l'invention implique un agent d'administration local soit présent sur chaque occurrence de base de données concernée pour assurer le traitement prescrit -, - cet agent d'administration local soit en attente d'actions à effectuer, c'est à dire qu'il examine régulièrement les objets opération présents sur le bus d'administration et prend en compte les actions élémentaires qu'il est capable de traiter - et - lorsque l'action est terminée, que cet agent mette à jour la liste des actions élémentaires déjà traitées Le procédé selon l'invention implique également. - la définition d'un langage et d'une syntaxe spécifiques de description de l'objet opération ; et - la capacité de tous les agents d'administration locaux de comprendre ce langage et de partager des conventions communes de marquage des actions accomplies, voire de génération de nouvelles actions élémentaires non prévues par le créateur de l'objet opération. Il peut également être décidé, que, si des contraintes logiques l'exigent, de lancer une action complexe où un agent d'administration positionne l'action élémentaire à réaliser par le suivant. Il s'agit donc d'un traitement séquentiel non déterministe. Le langage spécifique peut être le langage "XML" ou un langage similaire. On va maintenant décrire un exemple d'application du procédé selon l'invention à la réalisation d'un annuaire répondant au standard X.500, plus précisément mettant en #uvre la technologie "LDAP". Pour une description plus détaillée des caractéristiques de ce standard et de cette technologie, on pourra se reporter à l'article des "Techniques de l'Ingénieur" précité. Dans un tel cadre d'application, l'objectif principal permet de remplir le procédé selon l'invention est la mise en cohérence relations dans les objets distribués : - qui ne sont pas tous situés dans la base locale - qui sont situés dans d'autres domaines d'administration, c'est-à- dire,des sous-arbres non accessibles. Pour cette application particulière, le bus d'administration peut être constitué par un noeud X.500 de classe objet "Organization Unit" particulier. Sous ce n#ud, on définit des objets "opération" spécifiques, sont une classe objet non réservée par le standard X.500. Conformément à l'une des caractéristiques procédé selon l'invention, ce n#ud bus est répliqué sur toutes les occurrences l'annuaire, et par voie de conséquence, la modification d'un objet ce n#ud sur une occurrence d'annuaire sera répercutée sur toutes les autres occurrences de l'annuaire. Lorsque l'exécution d'une application locale d'administration de l'annuaire doit mettre à jour l'annuaire (via les services "LDAP") agir sur des objets hors de sa portée (objets non déposés localement ou droits insuffisants), elle demande à l'agent d'administration local de créer un objet opération en indiquant typiquement . - l'action globalement lancée, consistant en une convention de liste fermée de codes actions ; - la ou les actions élémentaires effectuées (conventions) - la ou les actions élémentaires restant à faire ; - le type de traitement des actions élémentaires (dans un ordre quelconque, ou bien selon une séquence prédéterminée) ; l'autorisation ou non, que d'autres processus d'administration ajoutent des actions à effectuer; - La date et heure de création de l'objet - l'identité (un identifiant unique dit "UID", pour "Unique IDentifier") créateur de l'objet ; et - la signature des informations afin de garantir la validité de l'action engagée. En ce qui concerne la signature des informations, diverses techniques peuvent être utilisées, mais on aura recours de façon avantageuse à technique normalisée des certificats X.509, associés à des clés asymétriques. Les,principales caractéristiques de cette technique sont également rappelées dans l'article des "Techniques de l'Ingénieur" précité, auquel on se reportera avec profit. Chaque agent d'administration local scrute à intervalle régulier objets présents dans le bus d'administration. La fréquence de cette scrutation peut naturellement être configurable. Dès que les agents d'administration locaux ont traité une ou des actions élémentaires d'un objet opération, ils indiquent typiquement, pour chaque action élémentaire traitée - - la date et heure du traitement ; et - leur identité, ainsi qu'éventuellement leur signature. L'identification des agents d'administration et la signature des actions impliquent que les agents d'administration soient eux-mêmes enregistrés dans l'annuaire et que leur certificat de signature soit publié. Les agents d'administration locaux peuvent être considérés par exemple, selon le standard X.500, en tant qu'objets de classe "Application Entity" ou "Application Process". A la lecture de ce qui précède, on constate aisément que le procédé selon l'invention atteint bien les buts qu'elle s'est fixés. Il présente notamment l'avantage de ne pas nécessiter de modifications importantes de l'existant. Tout au contraire, il s'appuie sur le mécanisme de distribution/synchronisation de données dont les bases de données ou les annuaires répartis sont normalement pourvus, La disposition spécifique la plus importante consiste à prévoir une entité qui a été appelé un "bus d'administration". Ce bus est très simplement réalisé en créant une sous-structure de base de données (ou un sous-arbre), de manière classique en soi, et en faisant appel au mécanisme précité pour le répliquer dans toutes les occurrences de la base de données (de l'annuaire). On doit prévoir également des entités logicielles spécifiques au niveau de chaque occurrence que l'on a appelé "agents d'administration locaux". Ces agents peuvent créer des objets particuliers dans le bus précité, y lire des informations, les modifier et/ou les supprimer. Là encore, bien que ces objets, que l'on a appelé "objets opération", aient une fonction particulière et soient spéçifiques à l'invention, il s'agit d'objets, en soi, de nature classique. Il s'agit, le plus souvent, d'objets appartenant à une nouvelle classe d'objet, qu'il suffit de définir. Les entités logicielles spécifiques, c'est-à-dire les agents d'administration locaux, peuvent être des pièces de logiciel créees à cet effet. On peut également modifier le code des applications locales, tant que de besoin, pour les rendre compatibles avec le procédé de l'invention, notamment leur donner la capacité de créer et traiter les objets opération précités. Si la base de données ou l'annuaire réparti met en oeuvre un standard, par exemple le standard X.500 (notamment pour les bases de données de type annuaire), comme il a été montré sur un exemple, le procédé selon l'invention reste tout à fait compatible avec le standard utilisé. Tout en ne nécessitant que peu de modifications, le procédé selon l'invention permet une grande cohérence entre occurrence de la base de données et offre une grande souplesse d'utilisation. Il doit être clair cependant que l'invention n'est pas limitée aux seuls exemples de réalisations explicitement décrits, notamment en relation avec les figures 3A à 4. Il s'applique à toutes sortes de bases de données réparties, et notamment aux annuaires répartis qui constituent un type particulier de bases de données. REVENDICATIONS Procédé d'administration d'une base de données, ladite base données étant du type réparti en au moins deux sous-ensembles dits occurrences pour le stockage, dans des moyens de mémorisation de ces occurrences, d'une pluralité de premiers objets, lesdites occurrences communiquant entre elles par l'intermédiaire de moyens de transmission de données, ladite base de données comprenant des moyens dits de distribution/synchronisation de données pour la diffusion dans lesdites occurrences desdits premiers objets ef "r réplication, en tout ou partie, lesdites occurrences étant sous le contrôle d'applications logicielles dites locales, ces applications ayant autorité sur une partie préétablie desdits premiers objets pour effectuer des opérations logiques de natures déterminées, caractérisé en ce il comprend au moins une phase initiale consistant en la création d'un sous-ensemble spécifique (21) répliqué dans toutes lesdites occurrences (Si, B'3, B',3), dit bus d'administration distribué, et de création d'au moins une pièce de logiciel (Ae, Ag3, Ae) associée aux dites applicat i ons locales (A,, A3, A8), dit agent d'administration local, lesdits agents d'administration locaux (A.,, Ag3, Ag8) ayant la capacité de créer des deuxièmes objets (Op), dits objets opération, enregistrés dans ledit bus d'administration distribué (21) et d'effectuer des opérations élémentaires déterminées sur tous lesdits objets opération (Op) et leurs répliques (0",P, (0",,p), et sur une partie préétablie de ladite pluralité de premiers objets (01, 02, 03) et/ou de leurs répliques (0,, 0'2, CY3 -1 0"1. 0"2, C"3), et en ce qu'il comprend au moins les étapes suivantes, initiées lors d'une opération effectuée sur l'un desdits premiers objets par l'une desdites applications locales (A,, A3, A8) et impliquant des opérations à effectuer sur au moins un autre desdits premiers objets (01, 02, 03) sur lequel ladite application locale n'a pas autorité -. a/ création d'un dit objet opération (Op) et son enregistrement dans ledit bu-s d'administration distribué (21) ; bl enregistrement, dans ledit objet opération (0,,p), d'instructions concernant des opérations élémentaires restant à effectuer 1 c/ diffusion dans ledit bus d'administration (21) dudit objet opération (O,p) créé dans toutes lesdites occurrences (B'l, B'3, B'8), par l'intermédiaire desdits moyens de distribution/synchronisation de données (20), de manière à obtenir sa réplication dans lesdites occurrences -, d/ lecture par lesdits agents d'administration locaux A3, A8) desdites inscriptions enregistrées dans ledit objet opération ou ses réplications (O'Op, 0",p), et e/ exécution, en tout ou partie, par au moins un desdits agents 'd'administration locaux (A.,, Ag3, A.8), desdites opérations élémentaires restant à réaliser sur un desdits objets opération (Op) ou sa réplique (0',,p, 0",,P), dans une desdites occurrences (B'l, SI B'8) ; et f/ modification conditionnelle dudit objet opération (0,,p) ou sa réplique (O'Op, 0",p), en fonction des opérations élémentaires effectuées par ledit agent d'administration local (Agi, Ag3, Age) et/ou restant à effectuer, et répétition des étapes d/ et e/ jusqu'à ce que toutes lesdites opérations élémentaires soient effectuées. Procédé selon la revendication 1, caractérisé en ce qu'il comprend une étape supplémentaire consistant à modifier ledit objet opération (0,,p) ou sa réplique (0',p, 0",p) pour y inscrire des informations indiquant que lesdites opérations élémentaires sont toutes effectuées, de manière à ce que ladite application locale initiatrice (A,, A3, A8) reçoive des signaux de complétion des opérations, par l'intermédiaire dudit agent d'administration local (A.,, Ag3, Ag8) qui lui est associé. Procédé selon la revendication 2, caractérisé en ce que lesdites informations comprennent aussi des données d'identification desdits agents d'administration locaux (A.,, Ag3, Ae) ayant effectué des opérations élémentaires sur lesdits premiers objets (01, 02, 03) et/ou de leurs répliques (0',, 0'2, 0'3 ; 0",, 0"2, 0%), la nature desdites opérations élémentaires et des informations de chronodatage. 4. Procédé selon les revendications 2 ou 3, caractérise en ce que lesdites données d'identification comprennent en outre une signature d'au moins l'un desdits agents d'administration locaux (Agi, Ag3, Ag8) authentifiant le créateur desdits objets opération (Op) ou de leurs répliques (O,p, 0",p). 5. Procedé selon la revendication 4, caractérisé en ce que ladite signature utilise certificat d'authentification selon le standard "X.509", associé à des clés de chiffrage de type asymétrique. 6. Procédé selon l'une quelconque des revendications 2 à 5, caractérisé en ce qu'il comprend une étape finale consistant en la suppression desdits objets opération (Op) ou de leurs répliques (O,,p, 0",,p) par l'un desdits.agents d'administration locaux (A.,, Ag3, Ag8), après complétion desdites opérations élémentaires à exécuter. 7. Procédé selon l'une quelconque des revendications à 6, caractérisé en ce qu'il comprend une étape supplémentaire consistant l'ajout dynamique par au moins l'un desdits agents d'administration locaux (Agi, Ag3, A.6), dans l'un desdits objets opération (0,,p) ou de leurs répliques (0',,p, 0"#p), d'instructions commandant l'exécution d'opérations élémentaires supplémentaires sur au moins l'un desdits premiers objets (01, 02, 03) et/OU de leurs répliques (Ol, 0'2, 0'3 ; 0 0 '12, 0 8. Procédé selon l'une quelconque des revendications à 6, caractérisé en ce qu'il comprend une étape supplémentaire consistant la création, par au moins un desdits agents d'administration locaux (Agi, Ag3, A.8), d'un dit objet opération supplémentaire (Op). Procédé selon l'une quelconque des revendications 1 à 8, caractérisé en ce qu'il comprend une phase initiale supplémentaire consistant en la création d'au moins un dit agent d'administration local spécialisé, dit de supervision du bus d'administration distribué (21) et en ce que ledit agent de supervision lit les instructions et/ou informations contenues dans lesdits objets opération, de manière à surveiller l'état d'avancement desdites opérations élémentaires à exécuter. 10. Procédé selon la revendication 9, caractérisé en ce que ledit agent de supervision génère un signal d'alarme lorsque tout ou partie desdites opérations élémentaires reste inachevé après un intervalle de temps prédéterminé. 11. Procédé selon l'une quelconque des revendications 1 à 10, caractérisé en ce que lesdits agents d'administration locaux Ag3, A.6) associés aux dites applications locales (Ai, A3, A8) sont des pièces de logicielles distinctes de ces. a ,pplications locales. 12. . Procédé selon l'une quelconque des revendications 1 à 10, caractérisé en ce que lesdits agents d'administration locaux (Ag,, Ag3, A.8) associés aux dites applications locales (A,, A3, A8) sont des pièces de logicielles intégrées dans ces applications locales (Ai, A3, A8) et résultent d'une modification de celle-ci. 13. Procédé selon l'une quelconque des revendications 1 à 12, caractérisé en ce que ladite base de données (2) est un annuaire distribué à architecture hiérarchique, comprenant des noeuds associés à des classes d'objet et respectant le standard dit "X.500" et la technologie dite "LDAP", en ce que ledit bus d'administration (21) est réalisé par un n#ud de classe objet dite "Organization Unit" dans ledit standard 'X et en ce que lesdits objets opération (0,,p) et leurs répliques (O',p, 0",p) sont constitués par des objets de classe objet non réservée dans ledit standard 500". 14. Architecture de base de données pour mise en mise en couvre du procédé selon l'une quelconque des revendications précédentes, ladite base de données étant du type réparti en au moins deux sous-ensembles dits occurrences pour le stockage, dans des moyens de mémorisation de ces occurrences, d'une pluralité de premiers objets, lesdites occurrences communiquant entre elles par l'intermédiaire moyens de transmission de données, ladite base de données comprenant des moyens dits de distribution/synchronisation de donnees pour la diffusion dans lesdites occurrences desdits premiers objets leur réplication, en tout ou partie, chacune desdites occurrences étant sous le contrôle d'applications logicielles dites locales, ces applications ayant autorité sur une partie préétablie desdits premiers objets pour effectuer opérations logiques de natures déterminées, caractérisé en ce que ladite base de données (2) comprend un sous-ensemble supplémentaire répliqué dans toutes lesdites occurrences (SI, SI B'8), et en ce elle comprend des pièces de logicielles associées aux dites applications locales (Ai, A3, A8) pour former lesdits age nts d'administration locaux Ag3, Ag8), de manière à pouvoi r créer lesdits objets opération (Op) et les traiter.