FR 2938356 A1 20100514 FR 0806252 A 20081110 La présente invention concerne un procédé et un système de synchronisation d'un ensemble de modules logiciels d'un système informatique distribué en plusieurs serveurs interconnectés en réseau. Elle concerne également un programme d'ordinateur pour la mise en oeuvre de ce procédé. L'invention s'applique plus particulièrement à un système informatique dans lequel chaque module logiciel s'exécute sur un serveur du système informatique pour la gestion d'un ensemble de données numériques, au moins une partie de ces données numériques étant répliquée sur plusieurs modules logiciels, et dans lequel la synchronisation entre deux modules logiciels de l'ensemble comporte une synchronisation des données communes qu'ils gèrent. Les données numériques sont par exemple des données de description d'un service et le service fourni par le système informatique est par exemple un service de stockage de données distribué entre les serveurs interconnectés en réseau, chaque serveur étant relié à des périphériques de stockage à disque dur ou bande magnétique. Dans ce cas, les données numériques comportent par exemple des données de description d'utilisateurs du service de stockage, des données de description de l'infrastructure et du fonctionnement du système informatique pour la fourniture du service, et des données de description des données stockées et de leur mode de stockage. Le service fourni par le système informatique peut également être un service de transmission de données d'information, de traitement de données, de calcul, de transaction ou une combinaison de ces services. Dans chaque cas, les données de description sont adaptées spécifiquement au service fourni. Les serveurs du système informatique sur lesquels s'exécutent les modules logiciels sont généralement interconnectés par au moins un réseau de type LAN (de l'Anglais � Local Area Network �) et/ou WAN (de l'Anglais � Wide Area Network �). Cet ensemble de serveurs interconnectés en réseau peut notamment être appelé � grappe de serveurs �, les modules logiciels étant alors généralement qualifiés de � noeuds � de la grappe. Dans une telle architecture, un serveur ou un module logiciel particulier est en principe dédié à la gestion de l'ensemble des modules logiciels, notamment pour la synchronisation des données numériques répliquées. Ceci pose des problèmes lorsque le serveur ou le module logiciel dédié à la gestion de l'ensemble est défaillant. Par exemple dans la demande de brevet publiée sous le numéro FR 2 851 709, il est prévu qu'un service puisse être fourni, via un réseau de communication, à un utilisateur par un serveur principal associé à une base de données. Des serveurs auxiliaires connectés à ce serveur principal sont également prévus dans le réseau de communication pour rendre ce service plus rapidement accessible à l'utilisateur. Mais ils doivent alors être synchronisés avec le serveur principal, notamment avec sa base de données. Pour réaliser cette synchronisation du serveur principal vers les serveurs auxiliaires, le réseau de communication est doté de moyens spécifiques de synchronisation, par exemple mis en oeuvre dans des serveurs de ressources. Il apparaît donc que certains éléments du réseau de communication, le serveur principal et les serveurs de ressources, ont un rôle très particulier et leur défaillance risque d'avoir des conséquences immédiates sur la qualité de service fournie. Dans la demande de brevet publiée sous le numéro US 2007/0233900, un système en grappe de calculateurs prévoit que plusieurs calculateurs puissent copier localement une même donnée issue de moyens de stockage communs. Pour gérer la synchronisation de l'ensemble des copies d'une même donnée, un système de couplage entre les calculateurs prévoit la mise à jour des moyens de stockage communs chaque fois qu'une donnée copiée localement est modifiée par un calculateur, de sorte que les autres calculateurs puissent mettre leurs données copiées localement à jour, en référence aux moyens de stockage communs. Là encore, l'architecture du système prévoit un rôle particulier pour le système de couplage et les moyens de stockage communs. Centraliser la synchronisation des modules logiciels, dans le sens d'une synchronisation des données numériques communes qu'ils gèrent, est pourtant la solution la plus simplement envisageable. En répartissant cette synchronisation sur plusieurs voire tous les serveurs du système informatique, cela pose des problèmes de coordination des serveurs. II n'existe donc pas aujourd'hui de solution complètement satisfaisante. Il peut ainsi être souhaité de prévoir un procédé de synchronisation de modules logiciels d'un système informatique distribué en plusieurs serveurs interconnectés en réseau qui permette de s'affranchir d'au moins une partie des problèmes et contraintes précités. L'invention a donc pour objet un procédé de synchronisation d'un ensemble de modules logiciels d'un système informatique distribué en plusieurs serveurs interconnectés en réseau, chaque module logiciel s'exécutant sur un serveur du système informatique pour la gestion d'un ensemble de données numériques dont au moins une partie est répliquée sur plusieurs modules logiciels, dans lequel la synchronisation entre deux modules logiciels de l'ensemble comporte une synchronisation des données communes qu'ils gèrent, caractérisé en ce qu'il comporte les étapes suivantes : regroupement de modules logiciels de l'ensemble, activés et synchronisés entre eux, en au moins un sous-ensemble synchronisé et identification de ce sous-ensemble, et - pour chaque module logiciel candidat, activé mais non synchronisé avec au moins un autre module logiciel de l'ensemble : ^ recherche d'un autre module logiciel activé de l'ensemble, ^ si un autre module logiciel activé est trouvé et s'il appartient à un sous- ensemble identifié, synchronisation du module logiciel candidat avec au moins l'un des modules logiciels de ce sous-ensemble identifié, et ^ intégration du module logiciel candidat dans le sous-ensemble identifié. Ainsi, tout en évitant une synchronisation centralisée, puisque chaque module logiciel activé mais non encore synchronisé gère lui-même sa synchronisation avec un autre module logiciel de l'ensemble, le suivi global de la synchronisation de l'ensemble des modules logiciels est assuré par la présence et la gestion de l'évolution de sous-ensembles homogènes de modules logiciels synchronisés. Ces sous-ensembles sont identifiés pour permettre leur suivi. De façon optionnelle, pour chaque module logiciel candidat, si un autre module logiciel est trouvé mais qu'il n'appartient pas à un sous-ensemble identifié : 25 - un nouveau sous-ensemble synchronisé est créé et identifié, - le module logiciel candidat est synchronisé avec l'autre module logiciel trouvé, et le module logiciel candidat et cet autre module logiciel trouvé sont intégrés dans ce nouveau sous-ensemble identifié. 30 De façon optionnelle également, lors de la synchronisation du module logiciel candidat avec au moins l'un des modules logiciels du sous-ensemble identifié comportant l'autre module logiciel trouvé, le choix d'au moins un module logiciel de ce sous-ensemble identifié pour réaliser la synchronisation est fonction d'une charge de travail d'au moins une partie des modules logiciels de ce sous-ensemble identifié. II est ainsi possible de répartir avantageusement la charge de travail occasionnée par la synchronisation elle-même. De façon optionnelle également, un procédé de synchronisation selon l'invention peut comporter en outre les étapes suivantes : - détection, par un premier sous-ensemble identifié, d'un second sous- ensemble identifié, regroupement des modules logiciels de ces deux sous-ensembles identifiés dans l'un de ces deux sous-ensembles identifiés, suppression de l'autre de ces deux sous-ensembles identifiés, et - synchronisation de chaque module logiciel faisant initialement partie du sous-ensemble supprimé avec au moins l'un des modules logiciels du sous-ensemble choisi pour le regroupement. Ainsi, ce procédé de synchronisation tend à favoriser la fusion entre sous-ensembles homogènes tant que la synchronisation complète de tous les modules logiciels de l'ensemble n'est pas obtenue. De façon optionnelle également, dans chaque sous-ensemble identifié, un module logiciel est sélectionné pour être spécifiquement marqué comme identifiant de ce sous-ensemble identifié. Ce module logiciel sélectionné dans chaque sous-ensemble joue alors un rôle de marqueur permettant à tous les autres modules logiciels de reconnaître leur appartenance à un sous-ensemble identifié. De façon optionnelle également, un procédé de synchronisation selon l'invention peut en outre comporter les étapes suivantes : - détection d'une rupture de connexion entre deux parties complémentaires d'un sous-ensemble identifié, comportant chacune au moins un module logiciel, à partir de ce sous-ensemble identifié, génération et identification de deux sous-ensembles intégrant l'une, respectivement l'autre, des deux parties complémentaires. Ainsi, une rupture étant source d'impossibilité à maintenir une synchronisation des modules logiciels d'un même sous-ensemble, ce procédé prévoit la séparation de chaque sous-ensemble en deux sous-ensembles dès qu'une telle rupture de connexion est détectée. De façon optionnelle également, un procédé de synchronisation selon l'invention peut comporter en outre les étapes suivantes : - exécution, sur un premier module logiciel appartenant à un sous-ensemble identifié, d'une action agissant sur une donnée numérique gérée par ce premier module logiciel, - transmission d'un message de synchronisation identifiant l'action à l'ensemble des autres modules logiciels du même sous-ensemble identifié comportant une réplication de cette donnée numérique, sur réception de ce message par l'un quelconque des modules logiciels concernés, exécution de l'action identifiée sur ce module logiciel de manière à agir sur la réplication de la donnée numérique située sur ce module logiciel. Ainsi, dans chaque sous-ensemble constitué et identifié, il est prévu un mécanisme de synchronisation permanente des modules logiciels entre eux particulièrement efficace et non centralisé. En effet, l'exécution d'une action sur un premier module logiciel d'un sous-ensemble a pour conséquence, grâce à la transmission d'un message identifiant cette action, l'exécution de cette même action sur l'ensemble des autres modules logiciels du même sous-ensemble gérant une réplication de la donnée numérique concernée par cette action. Par conséquent, quel que soit le module logiciel sur lequel est d'abord exécutée l'action, celui-ci remplit une fonction de gestionnaire de synchronisation dans le sous-ensemble et le résultat est le même : tout se passe comme si l'action s'était exécutée sur l'ensemble des modules logiciels comportant la donnée numérique concernée par l'action, dans le sous-ensemble considéré. Aucun module logiciel ne joue donc de rôle privilégié ou particulier du point de vue de la gestion des données numériques, ce qui rend le système informatique complet moins vulnérable aux ruptures de continuité de service en cas de défaillance d'un module logiciel ou d'un serveur. De façon optionnelle également, un procédé de synchronisation selon l'invention peut comporter en outre les étapes suivantes : - lors de la synchronisation du module logiciel candidat, celui-ci comportant une partie des données numériques, extraction d'un état des réplications de cette partie des données numériques sur au moins un autre module logiciel, et enregistrement du module logiciel candidat en tant que récepteur potentiel d'au moins un message de synchronisation identifiant une action sur une réplication de ses données numériques située sur un autre module logiciel, synchronisation des données numériques du module logiciel avec les données numériques de l'autre module logiciel et, pendant cette synchronisation, mise dans une file d'attente des messages de synchronisation éventuellement reçus, - une fois la synchronisation terminée, traitement de la file d'attente. L'invention a également pour objet un système de synchronisation d'un ensemble de modules logiciels d'un système informatique, comportant plusieurs serveurs interconnectés en réseau, chaque module logiciel s'exécutant sur un serveur du système informatique pour la gestion d'un ensemble de données dont au moins une partie est répliquée sur plusieurs modules logiciels, dans lequel la synchronisation entre deux modules logiciels de l'ensemble comporte une synchronisation des données communes qu'ils gèrent, caractérisé en ce qu'il comporte : - des moyens d'identification d'au moins un sous-ensemble regroupant des modules logiciels de l'ensemble activés et synchronisés entre eux, et pour chaque module logiciel candidat, activé mais non synchronisé avec au moins un autre module logiciel de l'ensemble : ^ des moyens de recherche d'un autre module logiciel activé de l'ensemble, • si un autre module logiciel activé est trouvé et s'il appartient à un sous-ensemble identifié, des moyens de synchronisation du module logiciel candidat avec au moins l'un des modules logiciels de ce sous-ensemble identifié, et ^ des moyens d'intégration du module logiciel candidat dans le sous- ensemble identifié. Enfin, l'invention a également pour objet un programme d'ordinateur téléchargeable depuis un réseau de communication et/ou enregistré sur un support lisible par ordinateur et/ou exécutable par un processeur, caractérisé en ce qu'il comprend des instructions de code de programme pour l'exécution des étapes d'un procédé de synchronisation tel que défini précédemment, lorsque ledit programme est exécuté sur un ordinateur. L'invention sera mieux comprise à l'aide de la description qui va suivre, donnée uniquement à titre d'exemple et faite en se référant aux dessins annexés dans lesquels : la figure 1 représente schématiquement la structure générale d'un système informatique de stockage de données distribué en plusieurs serveurs interconnectés en réseau, - la figure 2 illustre un exemple de répartition de données de description dans le système informatique de la figure 1, la figure 3 illustre les étapes successives d'un procédé de synchronisation mis en oeuvre dans le système de la figure 1 selon un mode de réalisation de l'invention, la figure 4 représente un diagramme d'états et de transitions entre ces états de modules logiciels et matériels du système informatique de la figure 1, pour la mise en oeuvre du procédé de synchronisation de la figure 3, - les figures 5 et 6 illustrent partiellement les étapes successives de procédés de synchronisation selon d'autres modes de réalisation de l'invention, les figures 7 et 8 illustrent des exemples de mise en oeuvre d'une étape particulière de synchronisation du procédé de synchronisation de la figure 3, et la figure 9 illustre un exemple de mise en oeuvre d'une autre étape particulière de synchronisation du procédé de synchronisation de la figure 3. Le système informatique 10 représenté sur la figure 1 comporte plusieurs serveurs 121, 122, 123, 124 et 125, répartis sur plusieurs domaines. Chaque serveur est de type classique et ne sera pas détaillé. En revanche, sur chaque serveur 121, 122, 123, 124 et 125 est installé au moins un module logiciel et matériel spécifique 141, 142, 143, 144 et 145 de gestion d'un service, par exemple un service de stockage de données. Cinq serveurs et deux domaines sont représentés sur la figure 1 à titre purement illustratif mais toute autre structure de système informatique distribué en plusieurs serveurs interconnectés en réseau peut convenir pour la mise en oeuvre d'un procédé de synchronisation selon l'invention. Par souci de simplification également, il est représenté un module logiciel et matériel par serveur, de sorte que les modules et leurs serveurs respectifs pourront être confondus dans la suite de la description, sans pour autant devoir être confondus dans une mise en oeuvre plus générale de l'invention. Le module logiciel et matériel 141 du serveur 121 est détaillé sur la figure 1. Il comporte une première couche logicielle 161 constituée d'un système d'exploitation du serveur 121. II comporte une deuxième couche logicielle 181 de gestion de données de description du service de stockage de données fourni par le système informatique 10. Il comporte une troisième couche logicielle et matérielle 201 remplissant au moins deux fonctions : une première fonction de stockage, sur un disque dur interne du serveur 121, des données de description du service de stockage et une deuxième fonction de mémoire cache, sur ce disque dur également, de données stockées sur des périphériques de stockage du serveur 121. Enfin, il comporte une quatrième couche logicielle et matérielle 221, 241 d'entrepôts de données, comportant au moins un entrepôt de données sur disque dur 221 et/ou au moins un entrepôt de données sur bandes magnétiques 241. Pour la suite de la description, un entrepôt de données désigne un espace virtuel de stockage de données constitué d'une ou plusieurs partitions de disque, ou d'une ou plusieurs bandes magnétiques, parmi les périphériques de stockage du serveur auquel il est associé. Les modules logiciels et matériels 142, 143, 144 et 145 des serveurs 122, 123, 124 et 125 ne seront pas détaillés parce qu'ils sont similaires au module logiciel et matériel 141. Dans l'exemple illustré par la figure 1, les serveurs 121, 122 et 123 sont interconnectés entre eux par un premier réseau 26 de type LAN pour créer un premier sous-ensemble ou domaine 28. Ce premier domaine 28 correspond par exemple à une organisation géographique localisée, telle qu'un site géographique, un bâtiment ou une salle informatique. Les serveurs 124 et 125 sont interconnectés entre eux par un second réseau 30 de type LAN pour créer un second sous-ensemble ou domaine 32. Ce second domaine 28 correspond également par exemple à une autre organisation géographique localisée, telle qu'un site géographique, un bâtiment ou une salle informatique. Ces deux domaines sont reliés entre eux par un réseau de type WAN 34, tel que le réseau Internet. Ainsi ce système informatique en grappe de serveurs répartis sur plusieurs sites géographiques permet d'envisager un stockage de données d'autant plus sûr que celles-ci peuvent être répliquées sur des modules logiciels et matériels situés sur des sites géographiques différents. Le service de stockage fourni par ce système informatique 10 et les données effectivement stockées sont avantageusement complètement définis et décrits par un ensemble de données de description qui vont être décrites dans leurs principes généraux en référence à la figure 2. De la sorte, la gestion de ces données de description par la couche logicielle 18; de l'un quelconque des modules logiciels et matériels 14; assure la gestion du service de stockage du système informatique 10. Les données de description sont par exemple regroupées en plusieurs ensembles structurés selon leur nature et éventuellement liés entre eux. Un ensemble structuré, qui sera appelé � catalogue � dans la suite de la description, peut se présenter sous la forme d'une arborescence de répertoires contenant eux-mêmes d'autres répertoires et/ou des fichiers de données de description. La représentation des données de description selon une arborescence de répertoires et de fichiers comporte l'avantage d'être simple et donc économique à concevoir et à gérer. De plus cette représentation est souvent suffisante pour le service visé. Il est aussi possible, pour des applications plus complexes, de représenter et gérer les données de description en bases de données relationnelles. Un catalogue de données de description peut être global, c'est-à-dire concerner des données de description utiles à l'ensemble du système informatique 10, ou bien local, c'est-à-dire concerner des données de description propres à un ou plusieurs module(s) logiciel(s) et matériel(s) 141, 142, 143, 144 ou 145 de gestion du service. Avantageusement, chaque catalogue est répliqué sur plusieurs serveurs ou modules logiciels et matériels. Lorsqu'il est global, il est de préférence répliqué sur l'ensemble des modules logiciels et matériels. Lorsqu'il est local, il est répliqué sur un nombre prédéterminé de modules logiciels et matériels dont au moins celui ou ceux qu'il concerne. A titre d'exemple, la figure 2 représente une répartition possible de catalogues de données de description entre les cinq modules logiciels et matériels 141, 142, 143, 144 et 145. Un premier catalogue CA global est répliqué sur les cinq modules logiciels et matériels 141, 142, 143, 144 et 145. II comporte par exemple des données décrivant l'infrastructure générale et le fonctionnement général du système informatique 10 pour la fourniture du service, notamment l'arborescence des domaines et des modules logiciels et matériels du système informatique 10. Il peut aussi comporter des données décrivant des utilisateurs potentiels du service de stockage de données et leurs droits d'accès, par exemple des utilisateurs préalablement inscrits, ainsi que les zones de partage, la structure ou le mode de stockage et la réplication de données stockées. D'autres catalogues sont locaux, comme par exemple le catalogue OBI, contenant des données de description propres au module logiciel et matériel 141 telles que des données relatives à l'infrastructure locale et au fonctionnement local du serveur 121 et de ses périphériques de stockage, ou à l'organisation en entrepôts du module logiciel et matériel 141, ou bien encore aux données numériques effectivement stockées dans ces entrepôts. Ce catalogue est répliqué en trois exemplaires, dont un sur le module logiciel et matériel 141. Pour améliorer la sécurité et la robustesse du système informatique 10, le catalogue CB1 peut être répliqué dans plusieurs domaines différents. Ici, le système complet comportant deux domaines 28 et 32, le catalogue OBI est par exemple sauvegardé sur les modules 141 et 142 du domaine 28 et sur le module 145 du domaine 32. De même, les modules logiciels et matériels 142, 143, 144 et 145 sont associés à des catalogues locaux respectifs CB2, CB3, CB4 et CB5. Par exemple, le catalogue CB2 est sauvegardé sur les modules 142 et 143 du domaine 28 et sur le module 144 du domaine 32 ; le catalogue CB3 est sauvegardé sur le module 143 du domaine 28 et sur les modules 144 et 145 du domaine 32 ; le catalogue CB4 est sauvegardé sur le module 144 du domaine 32 et sur les modules 141 et 143 du domaine 28 ; et le catalogue CB5 est sauvegardé sur le module 145 du domaine 32 et sur les modules 141 et 142 du domaine 28. La liste précitée de catalogues de données de description n'est pas exhaustive et n'est fournie qu'à titre d'exemple, de même que le nombre de réplications de chaque catalogue. Par cette réplication des catalogues, ici sur au moins trois modules logiciels et matériels pour chaque catalogue, on remarque que même si un module logiciel et matériel, voire deux, est (sont) hors d'état de fonctionnement, le système dans son ensemble est capable d'accéder à l'ensemble des données de description de sorte que la gestion du service de stockage de données n'est pas nécessairement interrompue. En pratique, cette continuité de service maintenue est efficace à partir du moment où une synchronisation des catalogues et plus généralement des données de description est assurée. Les données effectivement stockées sont également répliquées pour des questions de sécurité du service de stockage fourni de sorte que toute action ou modification portant sur ces données doit être aussi être appliquée aux différentes réplications. Une synchronisation des données effectivement stockées doit donc aussi être assurée. En d'autres termes, une synchronisation des modules logiciels et matériels 141, 142, 143, 144 et 145, comportant une synchronisation des données communes qu'ils gèrent, doit être assurée. Pour cela, un procédé de synchronisation selon l'invention va maintenant être détaillé en référence aux figures 3, 4, 5 et 6. Ce procédé de synchronisation vise à regrouper les modules logiciels et matériels 141, 142, 143, 144 et 145 du système informatique 10 en au moins un sous-ensemble identifié dans lequel tous les modules logiciels et matériels sont activés et synchronisés entre eux. Sa finalité peut même être de n'aboutir qu'à un seul sous- ensemble synchronisé, celui-ci regroupant alors tous les modules logiciels et matériels 141, 142, 143, 144 et 145 du système informatique 10, synchronisés entre eux. Ce procédé vise donc principalement à gérer le démarrage ou le redémarrage d'un module logiciel et matériel du système informatique 10 en vue de l'intégrer à l'un des sous-ensembles synchronisés existants ou à un nouveau sous-ensemble à créer. De façon optionnelle, il vise également à gérer des arrêts de modules logiciels et matériels, des ruptures de réseau, des détections d'un sous-ensemble synchronisé par un autre, etc. : autant d'événements susceptibles de faire évoluer les sous-ensembles synchronisés du système informatique 10. Comme illustré sur la figure 3, lors d'une première étape 100, résultant par exemple de l'activation d'un module logiciel et matériel 14; suite au démarrage d'un nouveau serveur dans le système informatique 10 ou au redémarrage d'un serveur existant, ce module logiciel et matériel, activé mais pas encore synchronisé avec un autre module logiciel et matériel du système informatique 10, recherche un autre module logiciel et matériel activé du système informatique 10. Si un autre module logiciel et matériel 14; activé est trouvé et s'il appartient à un sous-ensemble synchronisé identifié, on passe à une étape 102 de sélection d'au moins l'un des modules logiciels et matériels du sous-ensemble identifié pour réaliser une synchronisation du module logiciel et matériel 14; avec ce(s) module(s) logiciel(s) et matériel(s) sélectionné(s). En premier lieu, la sélection est basée sur les données numériques du module logiciel et matériel 14; qui doivent être synchronisées. Les modules logiciels et matériels du sous-ensemble identifié concernés par cette sélection sont donc ceux qui gèrent des données en commun avec le module logiciel et matériel 14;. De façon optionnelle, cette sélection est aussi fonction d'une charge de travail d'au moins une partie des modules logiciels et matériels de ce sous-ensemble identifié. Par exemple, il peut être considéré qu'au delà d'une charge prédéterminée, un module logiciel et matériel du sous-ensemble identifié ne peut pas être sélectionné. Ainsi, si un module logiciel et matériel sollicité a temporairement une surcharge, il peut indiquer au module logiciel et matériel 14; de choisir un autre module logiciel et matériel. Si aucun module logiciel et matériel sollicité n'est disponible à un instant donné, le module logiciel et matériel 14; peut attendre que le pic d'activité se termine pour se synchroniser. Ainsi, la charge de travail est répartie équitablement entre les modules logiciels et matériels sollicités si un grand nombre de modules logiciels et matériels démarrent en même temps ou si un module logiciel et matériel démarre alors que les autres sont très sollicités. Ensuite, au cours d'une étape 104, une synchronisation du module logiciel et matériel 14; avec le ou les modules sélectionnés est réalisée. Un exemple non limitatif d'une telle synchronisation sera détaillé en référence à la figure 9. Lors d'une étape 106 suivante, le module logiciel et matériel 14, est intégré au sous-ensemble synchronisé identifié qui comporte donc désormais un élément de plus. Enfin, on passe à une étape 108 au cours de laquelle on maintient en permanence les modules logiciels et matériels du sous-ensemble identifié synchronisés entre eux, selon un mécanisme prédéterminé dont un exemple non limitatif sera détaillé en référence aux figures 7 et 8. Au cours de cette étape également, le système informatique 10 surveille tout événement susceptible de faire évoluer le sous-ensemble identifié : détection d'un autre sous-ensemble synchronisé avec lequel fusionner, détection d'une rupture de connexion entre deux parties du sous-ensemble destinées alors à se séparer, perte d'un module logiciel et matériel (par exemple par arrêt du serveur correspondant), etc. A l'étape 100, si un autre module logiciel et matériel 141 activé est trouvé mais qu'il n'appartient pas à un sous-ensemble synchronisé identifié, on passe à une étape 110 de synchronisation du module logiciel et matériel 14; avec le module logiciel et matériel 14;. Cette synchronisation peut être identique à celle envisagée à l'étape 104. Elle sera détaillée en référence à la figure 9. Ensuite, au cours d'une étape 112, un nouveau sous-ensemble synchronisé est créé et identifié dans lequel on intègre les deux modules logiciels et matériels 14; et 14;. Enfin, on passe à une étape 114 au cours de laquelle on maintient en permanence les deux modules logiciels et matériels 14; et 14; de ce nouveau sous-ensemble identifié synchronisés entre eux, selon un mécanisme prédéterminé qui peut être identique à celui envisagé à l'étape 108 et qui sera détaillé en référence aux figures 7 et 8. Au cours de cette étape également, le système informatique 10 surveille tout événement susceptible de faire évoluer le nouveau sous-ensemble créé : détection d'un autre sous-ensemble synchronisé avec lequel fusionner, détection d'une rupture de connexion entre les deux modules logiciels et matériels 14; et 14; destinés alors à se séparer, perte d'un module logiciel et matériel (par exemple par arrêt du serveur correspondant), etc. A l'étape 100, si aucun autre module logiciel et matériel 14; activé n'est trouvé, le module logiciel et matériel 14; ne peut pas être synchronisé et reste isolé, bien qu'activé donc opérationnel. On passe alors à une étape 116, au cours de laquelle le système informatique 10 surveille tout événement susceptible de faire évoluer la synchronisation du module logiciel et matériel 14; : détection d'un sous-ensemble synchronisé dans lequel il pourrait être intégré, détection d'un autre module logiciel et matériel activé mais isolé avec lequel il pourrait être synchronisé, arrêt du serveur sur lequel il est implémenté, etc. Dans un mode de réalisation de l'invention, chaque sous-ensemble synchronisé inclut un module logiciel et matériel sélectionné pour être spécifiquement marqué comme identifiant de ce sous-ensemble. Par exemple, dans la situation de l'étape 112 précédemment décrite, c'est le module logiciel et matériel 14; qui peut être sélectionné comme devant identifier le nouveau sous-ensemble créé suite à sa détection par le module logiciel et matériel 14;. Un sous-ensemble est alors identifié par ce module logiciel et matériel sélectionné, de sorte que tout événement générateur d'une exclusion de ce module logiciel et matériel sélectionné du sous-ensemble génère la disparition de ce sous-ensemble et la création éventuelle d'un ou plusieurs nouveaux sous-ensembles. Un module logiciel et matériel quelconque 14; du système informatique 10 peut donc se trouver dans quatre états différents El, E2, E3 et E4 représentés sur la figure 4 avec leurs transitions. Dans le premier état El, le module logiciel et matériel 14; est arrêté. Dans le second état E2, il est activé mais isolé, c'est-à-dire sans être synchronisé avec un autre module logiciel et matériel du système informatique 10. Dans le troisième état E3, il est membre d'un sous-ensemble synchronisé identifié. Enfin, dans le quatrième état E4, il est membre d'un sous-ensemble synchronisé identifié et marqué comme identifiant de ce sous-ensemble. Une première transition t1 fait passer le module logiciel et matériel 14; de son état arrêté El à l'étape 100 de recherche d'un autre module logiciel et matériel activé du système informatique 10. En d'autres termes, au cours de l'étape 100, le module logiciel et matériel 14; est activé mais à la recherche d'une synchronisation des données numériques qu'il gère. Cette situation est provoquée par exemple par le démarrage ou le redémarrage du serveur correspondant. Une deuxième transition t2 fait passer le module logiciel et matériel 14, de l'étape 100 à son état activé mais isolé E2. C'est l'état dans lequel il se trouve si suite à l'étape 100 il passe à l'étape 116 par ce qu'il n'a détecté aucun autre module logiciel et matériel activé. Une troisième transition t3 fait passer le module logiciel et matériel 14; de l'étape 100 à son état E3 de membre d'un sous-ensemble synchronisé identifié. C'est l'état dans lequel il se trouve si suite à l'étape 100 il passe à l'étape 102 (il rejoint un sous-ensemble synchronisé existant) ou 110 (il rejoint un sous-ensemble synchronisé créé par le module logiciel et matériel isolé qu'il a détecté). Une quatrième transition t4 fait passer le module logiciel et matériel 14; de son état activé mais isolé E2 à son état E4 d'identifiant d'un sous-ensemble synchronisé. C'est l'état dans lequel il se trouve s'il a été détecté par un autre module logiciel et matériel pour effectuer une synchronisation. Il devient alors l'identifiant du nouveau sous-ensemble créé. Une cinquième transition t5 fait passer le module logiciel et matériel 14; de son état E3 de membre d'un sous-ensemble synchronisé identifié à son état E4 d'identifiant d'un sous-ensemble synchronisé. C'est l'état dans lequel il peut se trouver si le sous-ensemble auquel il appartient a perdu son module identifiant (arrêt du serveur correspondant par exemple), ou si le module logiciel et matériel 14; lui-même a perdu le contact avec le module identifiant du sous-ensemble dans lequel il se trouve suite à une rupture de connexion. Il peut alors devenir l'identifiant d'un nouveau sous-ensemble créé, mais il doit pour cela être sélectionné. En effet, dans cette situation, un nouveau module identifiant doit être sélectionné pour tous les modules logiciels et matériels du sous-ensemble considéré qui ont perdu contact avec le module identifiant initial : une solution est de créer un nouveau sous-ensemble pour tous ces modules logiciels et matériels et d'en sélectionner un pour être l'identifiant de ce nouveau sous-ensemble, par exemple le module logiciel et matériel 14;. En d'autres termes, dans le mode de réalisation décrit en référence à la figure 4, si le module identifiant d'un sous-ensemble synchronisé s'arrête, l'un des autres modules logiciels et matériels de ce sous-ensemble devient le module identifiant. Mais pour cela, un nouveau sous-ensemble est créé et tous les autres modules logiciels et matériels de l'ancien sous-ensemble deviennent membre du nouveau sous-ensemble. Si la connexion réseau entre deux sites distants d'un même sous-ensemble synchronisé est rompue, une partie des membres de ce sous-ensemble va se trouver séparée du module identifiant de ce sous-ensemble. Parmi ces modules logiciels et matériels séparés du module identifiant, l'un va être sélectionné pour devenir le module identifiant d'un nouveau sous-ensemble qui comprendra les modules logiciels et matériels du site isolé. En pratique, un nouveau sous-ensemble est créé chaque fois qu'un ou plusieurs modules logiciels et matériels sont séparés du module identifiant. L'un d'eux devient par sélection (transition t5) le module identifiant du nouveau sous-ensemble. Une sixième transition t6 fait passer le module logiciel et matériel 14; de son état activé mais isolé E2 à son état arrêté E1. Cette transition se produit notamment dans deux situations : - une première situation est l'arrêt du serveur sur lequel est implanté le module logiciel et matériel 14; ; une seconde situation est la détection par le module logiciel et matériel 14; d'un sous-ensemble synchronisé identifié ou d'un autre module logiciel et matériel dans l'état E2. En effet, dans la seconde situation, il doit se synchroniser avec au moins l'un des modules logiciels et matériels du sous-ensemble détecté pour en faire partie (étapes 102 à 106) ou avec l'autre module logiciel et matériel isolé détecté (étapes 110, 112). Or, comme le module logiciel et matériel 14; a évolué de manière isolée, une solution est de le redémarrer, ce qui devrait conduire, via l'étape 100, aux transitions t1 et t3 lors de ce redémarrage. Une septième transition t7 fait passer le module logiciel et matériel 14; de son état E3 ou E4 de membre ou identifiant d'un sous-ensemble synchronisé identifié à son état arrêté E1. Cette transition se produit notamment dans deux situations : - une première situation est l'arrêt du serveur sur lequel est implanté le module logiciel et matériel 14; ; - une seconde situation est la détection par le sous-ensemble dans lequel il se trouve d'un autre sous-ensemble synchronisé identifié avec lequel il peut fusionner. Dans la seconde situation, si la fusion se fait par maintien de l'autre sous-ensemble et disparition du sous-ensemble dans lequel le module logiciel et matériel 14; se trouve, ce dernier et les autres modules logiciels et matériels du sous-ensemble amené à disparaître doivent se synchroniser avec au moins l'un des modules logiciels et matériels de l'autre sous-ensemble détecté pour en faire partie (étapes 102 à 106). Or, comme les deux sous-ensembles ont évolué de manière isolée, une solution est de redémarrer le module logiciel et matériel 14; et les autres modules logiciels et matériels du sous-ensemble amené à disparaître, ce qui devrait conduire, via l'étape 100, aux transitions t1 et t3 lors de ce redémarrage. La figure 5 illustre les étapes successives mises en oeuvre de façon optionnelle par un procédé de synchronisation selon l'invention, lorsqu'un sous-ensemble synchronisé du système informatique 10 en détecte un autre, conformément à la seconde situation de la transition t7 décrite précédemment. Au cours d'une première étape 200, un premier sous-ensemble synchronisé S1 détecte un second sous-ensemble synchronisé S2 avec lequel il est possible de fusionner. Lors d'une étape suivante 202, un choix est fait pour savoir lequel des deux sous-ensembles doit être supprimé et lequel doit être conservé pour regrouper finalement tous les modules logiciels et matériels de ces deux sous-ensembles. Le sous-ensemble conservé sera noté Si, i = 1 ou 2, et le sous-ensemble supprimé sera noté Sj, j = 2 ou 1. Le choix se fait par exemple par logique majoritaire : - le sous-ensemble comportant le plus grand nombre de modules logiciels et matériels est conservé, - si les deux sous-ensembles comportent le même nombre de modules logiciels et matériels, le hasard détermine celui qui est conservé. Le critère de choix pourrait être différent ou affiné. Il pourrait par exemple prendre en compte un nombre de modifications exécutées sur les données gérées par les modules logiciels et matériels de chaque sous-ensemble S1 et S2. Il pourrait aussi prendre en compte le nombre de sessions ouvertes par des utilisateurs sur les modules logiciels et matériels de chaque sous-ensemble S1 et S2, puisque le redémarrage d'un module logiciel et matériel nécessite l'arrêt des sessions en cours sur ce module et peut provoquer une gêne pour un ou plusieurs utilisateurs. Ensuite, à une étape 204, chaque module logiciel et matériel du sous- ensemble Sj se synchronise avec au moins un module logiciel et matériel du sous-ensemble Si. Un exemple non limitatif d'une telle synchronisation sera détaillé en référence à la figure 9. A l'étape 206 suivante, le sous-ensemble Sj est supprimé. Enfin, au cours d'une dernière étape 208, tous les modules logiciels et matériels initialement dans ce sous-ensemble intègrent le sous-ensemble Si. Les étapes 204, 206 et 208 s'appliquent à tous les modules logiciels et matériels du sous-ensemble Sj et accompagnent leurs transitions successives t7, t1 et t3. La figure 6 illustre les étapes successives mises en oeuvre de façon optionnelle par un procédé de synchronisation selon l'invention, lorsqu'une rupture de connexion à l'intérieur d'un sous-ensemble synchronisé du système informatique 10 génère deux parties complémentaires de ce sous-ensemble, comportant chacune au moins un module logiciel et ne pouvant plus communiquer entre elles, conformément à la situation de la transition t5 décrite précédemment. Au cours d'une première étape 300, un sous-ensemble synchronisé S1 détecte une rupture de connexion entre deux parties complémentaires de S1 comportant chacune au moins un module logiciel. L'une des deux parties complémentaires de S1 comporte nécessairement son module identifiant. Cette partie reprend alors l'identité de S1. L'autre des deux parties comporte des modules logiciels et matériels ayant perdu tout contact avec le module identifiant de S1. On passe alors à une étape 302, lors de laquelle un nouveau sous-ensemble S2 est créé dans lequel sont intégrés tous les modules logiciels et matériels de cette autre partie. Au cours de cette intégration, aucune synchronisation n'est nécessaire. Seul un module logiciel et matériel de ce nouveau sous-ensemble S2 doit être sélectionné pour en être l'identifiant. Ce module logiciel et matériel sélectionné suit alors la transition t5. Il a été vu précédemment qu'au cours des étapes 108 et 114, on maintient en permanence les modules logiciels et matériels d'un même sous-ensemble synchronisés entre eux, selon un mécanisme prédéterminé dont un exemple non limitatif va maintenant être détaillé. Pour cela, la couche logicielle de chaque module logiciel et matériel du système informatique 10 comporte : - des moyens d'émission d'un message de synchronisation, identifiant une action agissant sur une donnée numérique qu'elle gère, vers l'ensemble des autres modules logiciels et matériels appartenant au même sous-ensemble synchronisé et comportant une réplication de cette donnée numérique, suite à l'exécution de cette action sur ce module logiciel et matériel, et des moyens d'exécution d'une action agissant sur une donnée numérique et identifiée dans un message de synchronisation, de manière à agir sur la réplication de la donnée numérique située sur ce module logiciel et matériel, en réponse à une réception de ce message de synchronisation. Comme les données numériques, notamment les données de description, gérées par un module logiciel et matériel sont avantageusement organisées en catalogues, un mécanisme de synchronisation permanent des catalogues au sein d'un même sous-ensemble va maintenant être détaillé. Tout d'abord, il convient de préciser qu'une synchronisation d'un catalogue dans un sous-ensemble s'impose à partir du moment où une réplication d'une donnée de description de ce catalogue est modifiée sur un module logiciel et matériel quelconque de ce sous-ensemble. Une modification de donnée de description peut être complètement définie par une action A déterminée sur cette donnée de description. Par exemple, une modification d'une donnée de description concernant un utilisateur peut être définie par une action sur ses droits d'accès au système informatique 10 choisis parmi un ensemble de droits comportant des droits d'administrateur système, des droits d'administrateur de données, des droits d'opérateur, des droits de simple utilisateur. Dans ce cas, l'action A identifie précisément la donnée de description à laquelle elle s'applique et la nouvelle valeur de cette donnée de description (en l'occurrence : administrateur système, administrateur de données, opérateur ou simple utilisateur). L'action A est identifiée par un identificateur universel unique et peut être sauvegardée, de sorte que l'état courant d'une donnée de description peut être retrouvé en connaissant l'état initial de cette donnée de description et la série des actions qui ont été opérées sur elle depuis sa création. Chaque réplication locale d'une donnée de description D est en outre associée à une version V qui comporte un numéro de version N et une signature S. Dans un mode de réalisation préféré, toute modification création ou suppression apportée par une action A sur une réplication de la donnée de description D modifie également sa version V de la façon suivante : N-N+1; - S Fû S + Incr(A), où Incr(A) est une valeur aléatoire générée à l'exécution de l'action A sur la réplication de la donnée de description concernée. Comme illustré sur la figure 7, lors d'une première étape 400, une action A est exécutée sur une réplication Di de la donnée de description D, cette réplication Di étant stockée par le serveur 12;. Avant l'exécution de l'action A, la réplication Di de la donnée de description D a une valeur val, un numéro de version N et une signature S. Après l'exécution de l'action A, la réplication Di de la donnée de description D a une valeur val', un numéro de version N' = N + 1 et une signature S' = S + Incr(A). Pendant l'exécution de l'action A, la réplication Di de la donnée de description D est protégée de sorte que d'autres actions sur cette réplication ne puissent pas être exécutées. Ces autres actions éventuelles sont mises en attente dans une liste prévue à cet effet et sont exécutées séquentiellement dès la fin d'exécution de l'action A. Lors d'une étape 402 suivante, un message de synchronisation M est généré par le module logiciel et matériel 14;. Ce message M comporte l'identifiant universel de l'action A, ou une description complète de cette action A, ainsi que la valeur de l'incrément de signature Incr(A). Lors de cette même étape, le message M est transmis à des modules logiciels et matériels 14i et 14k appartenant au même sous-ensemble que le module logiciel et matériel 14; et comportant également une réplication de la donnée de description D. Ensuite, lors d'une étape 404, à réception du message de synchronisation M, le module logiciel et matériel 14; exécute l'action A sur la réplication Dj de la donnée de description D, de manière à mettre à jour sa valeur, son numéro de version et sa signature qui prennent alors les valeurs respectives val', N' et S'. La mise à jour du numéro de version N se fait en appliquant la même règle que celle appliquée par le module logiciel et matériel 14; et la mise à jour de la signature se fait grâce à la transmission de l'incrément de signature Incr(A) généré par le module logiciel et matériel 14;. Ensuite également, lors d'une étape 406, à réception du message de synchronisation M, le module logiciel et matériel 14k exécute l'action A sur la réplication Dk de la donnée de description D, de manière à mettre à jour sa valeur, son numéro de version et sa signature qui prennent alors les valeurs respectives val', N' et S'. Grâce à ce procédé de synchronisation répété à chaque exécution d'une action sur l'une quelconque des données de description du système informatique 10, les catalogues répliqués sur plusieurs noeuds d'un même sous-ensemble synchronisé restent identiques, au temps de réalisation de la synchronisation près. D'autres techniques de modification de la version V d'une réplication de donnée de description que celle présentée en référence à la figure 7 sont envisageables en alternative, mais il est avantageux de prévoir que la mise à jour de la signature S soit incrémentale et commutative, ce qui permet de gérer les modifications croisées de différentes réplications d'une même donnée de description, comme cela est illustré par la figure 8. En effet, lors d'une première étape 500, une action A est exécutée sur une première instance d'une réplication Di de la donnée de description D, cette réplication Di étant stockée par le serveur 12;. Avant l'exécution de l'action A, la réplication Di de la donnée de description D a une valeur val, un numéro de version N et une signature S. Après l'exécution de l'action A, la réplication Di de la donnée de description D a une valeur val', un numéro de version N' = N + 1 et une signature S' = S + Incr(A). Avant même que le module logiciel et matériel 14; n'ait eu le temps d'envoyer un message de synchronisation MA aux autres modules logiciels et matériels de son sous-ensemble ayant une réplication de la donnée de description D, une action B est exécutée sur l'un d'entre eux, le module logiciel et matériel 14;, lors d'une étape 502. Lors de cette étape, l'action B est exécutée sur une seconde instance de la réplication Dj de la donnée de description D. Avant l'exécution de l'action B, la réplication Dj de la donnée de description D a la valeur val, le numéro de version N et la signature S. Après l'exécution de l'action B, la réplication Dj de la donnée de description D a une valeur val", différente de val', le numéro de version N' = N + 1 et une signature S" = S + Incr(B), différente de la signature S'. Ainsi, à l'issue des étapes 500 et 502, bien que les réplications Di et Dj aient le même numéro de version N', leurs signatures et valeurs respectives sont différentes. Leurs versions V' et V", identifiées à la fois par leurs numéros de version et par leurs signatures, sont donc différentes. Lors d'une étape 504 suivante, le message de synchronisation MA est généré par le module logiciel et matériel 14;. Ce message MA comporte l'identifiant universel de l'action A, ou une description complète de cette action A, ainsi que la valeur de l'incrément de signature Incr(A). Lors de cette même étape, le message MA est transmis notamment au module logiciel et matériels 14; comportant la réplication Dj. De même, lors d'une étape 506 suivante, un message de synchronisation MB est généré par le module logiciel et matériel 14i. Ce message MB comporte l'identifiant universel de l'action B, ou une description complète de cette action B, ainsi que la valeur de l'incrément de signature Incr(B). Lors de cette même étape, le message MB est transmis notamment au module logiciel et matériel 14; comportant la réplication Di. Lors d'une étape 508, à réception du message de synchronisation MB, le module logiciel et matériel 14; exécute l'action B sur la réplication Di de la donnée de description D, de manière à mettre à jour sa valeur, son numéro de version et sa signature qui prennent alors les valeurs respectives val"', N" et S"'. La valeur val"' résulte de l'action B sur val', c'est-à-dire de la combinaison des actions A et B sur la valeur val de la donnée de description D. La valeur N" est égale à N' + 1, soit N + 2. Enfin, la valeur de S"' est égale à s' + Incr(B) = S + Incr(A) + Incr(B). Enfin, lors d'une étape 510, à réception du message de synchronisation MA, le module logiciel et matériel 14; exécute l'action A sur la réplication Dj de la donnée de description D, de manière à mettre à jour sa valeur, son numéro de version et sa signature qui prennent alors les mêmes valeurs respectives val"', N" et S"' que pour Di à l'étape 508. En effet, la valeur val"' résulte de l'action A sur val", c'est-à-dire de la combinaison des actions A et B sur la valeur val de la donnée de description D. La valeur N" est égale à N' + 1, soit N + 2. Enfin, la valeur de S"' est égale à s" + Incr(A) = S + Incr(B) + Incr(A), grâce à la propriété incrémentale et commutative de la mise à jour de la signature. On remarque donc qu'à l'issue des étapes 508 et 510, les réplications Di et Dj sont correctement synchronisées, leurs versions identiques attestant de l'identité de leurs valeurs. Il a été vu précédemment qu'au cours des étapes 104, 110 et 204, on réalise ponctuellement un synchronisation d'un module logiciel et matériel 14; avec au moins un module logiciel et matériel 14; sélectionné, selon un mécanisme prédéterminé dont un exemple non limitatif va maintenant être détaillé en référence à la figure 9. Ce mécanisme permet de rattraper un éventuel retard ou un décalage pris par le module logiciel et matériel 14; par rapport au module logiciel et matériel 14; sélectionné dans la gestion des données de description qu'ils ont en commun. Selon ce mécanisme, lors d'une première étape 600 au cours de laquelle le module logiciel et matériel 14; est en recherche d'un autre module logiciel et matériel pour la synchronisation d'au moins l'un de ses catalogues de données de description, celui-ci sélectionne le module logiciel et matériel 14i. Il sélectionne bien sûr l'un des modules logiciels et matériels gérant une réplication du catalogue qu'il souhaite mettre à jour. Lorsque le module logiciel et matériel 14; est sélectionné, au cours de cette même étape 600, le module logiciel et matériel 14; lui transmet son identifiant ainsi qu'une information concernant les versions de chacune des données de description de son catalogue (i.e. numéro de version et signature). Ensuite, lors d'une étape 602, le module logiciel et matériel 14; établit une représentation figée du contenu de son catalogue et crée une liste d'attente pour la réception de tout nouveau message de synchronisation concernant ce catalogue. Suite à l'étape 600 également, lors d'une étape 604, le module logiciel et matériel 14; est inscrit comme possesseur d'une réplication du catalogue et destinataire de messages de synchronisation éventuels concernant ce catalogue. Il crée lors de cette étape également une liste d'attente pour la réception de tout nouveau message de synchronisation concernant ce catalogue. Suite à l'étape 602, lors d'une étape 606, le module logiciel et matériel 14; compare les versions des données de description du module logiciel et matériel 14; avec les siennes. Cette recherche des différences entre deux réplications d'un même catalogue peut être facilitée lorsque le catalogue de données de description est structuré selon un arbre dans lequel les données de description sont soit des noeuds (lorsqu'elles ont une relation de filiation directe ou indirecte avec au moins une donnée de description � fille �), soit des feuilles (lorsqu'elles sont situées en terminaison de l'arbre dans cette représentation hiérarchique). En effet, dans ce cas, chaque noeud de l'arbre peut être associé à une signature globale qui représente la somme des signatures de ses données � filles �, c'est-à-dire les données de description situées en aval de ce noeud dans l'arbre. Ainsi, la recherche des différences se fait en parcourant l'arbre, de sa racine vers ses feuilles, autrement dit d'amont en aval : chaque fois qu'un noeud de l'arbre a une même signature globale dans les deux réplications du catalogue, cela signifie que ce noeud et l'ensemble des données � filles � de ce noeud sont identiques, de sorte qu'il n'est pas utile d'explorer plus avant la sous-arborescence de l'arbre définie à partir de ce noeud. Lors de cette même étape, le module logiciel et matériel 14; constitue une première liste de données de description comportant les valeurs et versions des données de description dont la version qu'il possède est plus récente que celle du module logiciel et matériel 14;. Il constitue en outre éventuellement une seconde liste de données de description comportant les identifiants des données de description dont la version qu'il possède est moins récente que celle du module logiciel et matériel 14;. Il transmet alors ces deux listes au module logiciel et matériel 14;. Lors d'une étape 608, le module logiciel et matériel 14; traite la première liste de manière à mettre à jour, dans sa réplication du catalogue, les données de description concernées. Lors d'une étape 610, il transmet au module logiciel et matériel 14j les valeurs et versions des données de description identifiées dans la seconde liste. Ensuite, lors d'une étape 612, le module logiciel et matériel 14; traite ces valeurs et versions de données de description identifiées dans la seconde liste de manière à mettre à jour, dans sa réplication du catalogue, les données de description concernées. Chaque fois qu'il traite une mise à jour de donnée de description, il transmet un message de synchronisation, conformément au procédé décrit en référence à la figure 7, aux éventuels modules logiciels et matériels de son sous-ensemble comportant une réplication de cette donnée de description à l'exception du module logiciel et matériel 14;. Suite à cette mise à jour de catalogue entre le module logiciel et matériel 14j et le module logiciel et matériel 14;, la représentation figée du contenu du catalogue est désactivée du côté du module logiciel et matériel 14; lors d'une étape 614 et le module logiciel et matériel 14; en est informé lors d'une étape 616. Ainsi, lors de dernières étapes respectives 618 et 620, les modules logiciels et matériels 14; et 14; se libèrent pour traiter le cas échéant les messages de synchronisation reçus dans leurs listes d'attente respectives pendant toute la durée des étapes 606 à 616, de manière à résorber et supprimer ces listes d'attente, puis pour se mettre en situation de reproduire les étapes de synchronisation telles que décrites en référence aux figures 7 et 8 lorsque la situation se présente. Les étapes 600 à 618 sont répétées autant de fois que nécessaire sur le module logiciel et matériel 14; pour la mise à jour de l'ensemble de ses catalogues de données de description. II apparaît clairement qu'un procédé et/ou système tel que décrit précédemment permet la synchronisation décentralisée des données répliquées d'un système informatique distribué en plusieurs serveurs, tout en assurant un suivi global de la synchronisation de l'ensemble des modules logiciels par la présence et la gestion de l'évolution de sous-ensembles synchronisés. On notera par ailleurs que l'invention n'est pas limitée au mode de réalisation décrit précédemment. Il apparaîtra en effet à l'homme de l'art que diverses modifications peuvent être apportées au mode de réalisation décrit ci-dessus, à la lumière de l'enseignement qui vient de lui être divulgué. Dans les revendications qui suivent, les termes utilisés ne doivent pas être interprétés comme limitant les revendications au mode de réalisation exposé dans la présente description, mais doivent être interprétés pour y inclure tous les équivalents que les revendications visent à couvrir du fait de leur formulation et dont la prévision est à la portée de l'homme de l'art en appliquant ses connaissances générales à la mise en oeuvre de l'enseignement qui vient de lui être divulgué. REVENDICATIONS1. Procédé de synchronisation d'un ensemble de modules logiciels (141, 181, 142, 143, 144, 145) d'un système informatique (10) distribué en plusieurs serveurs (121, 122, 123, 124, 125) interconnectés en réseau (26, 30, 34), chaque module logiciel - regroupement (106, 112) de modules logiciels de l'ensemble, activés et synchronisés entre eux, en au moins un sous-ensemble synchronisé (S1, S2) et identification de ce sous-ensemble, et - pour chaque module logiciel candidat (14;), activé mais non synchronisé avec au moins un autre module logiciel de l'ensemble : recherche (100) d'un autre module logiciel activé de l'ensemble, ^ si un autre module logiciel activé est trouvé et s'il appartient à un sous-ensemble identifié, synchronisation (102, 104) du module logiciel candidat avec au moins l'un (14i) des modules logiciels de ce sous-ensemble identifié, et ^ intégration (106) du module logiciel candidat dans le sous-ensemble identifié. 2. Procédé de synchronisation selon la revendication 1, dans lequel, pour 25 chaque module logiciel candidat (14;), si un autre module logiciel est trouvé mais qu'il n'appartient pas à un sous-ensemble identifié : un nouveau sous-ensemble synchronisé est créé et identifié (112), - le module logiciel candidat est synchronisé avec l'autre module logiciel trouvé (14i), et 30 le module logiciel candidat (14;) et cet autre module logiciel trouvé (14i) sont intégrés (112) dans ce nouveau sous-ensemble identifié. 3. Procédé de synchronisation selon la revendication 1 ou 2, dans lequel, lors de la synchronisation (102, 104) du module logiciel candidat (14;) avec au moins l'un (14i) des modules logiciels du sous-ensemble identifié comportant l'autre module 35 logiciel trouvé, le choix (102) d'au moins un module logiciel (14;) de ce sous- s'exécutant sur un serveur du système informatique pour la gestion d'un ensemble (CA, CB1, CB2, CB3, CB4, CB5) de données numériques dont au moins une partie est répliquée sur plusieurs modules logiciels, dans lequel la synchronisation entre deux modules logiciels de l'ensemble comporte une synchronisation (102, 104, 110) des données communes qu'ils gèrent, caractérisé en ce qu'il comporte les étapes suivantes : 20ensemble identifié pour réaliser la synchronisation est fonction d'une charge de travail d'au moins une partie des modules logiciels de ce sous-ensemble identifié. 4. Procédé de synchronisation selon l'une quelconque des revendications 1 à 3, comportant en outre les étapes suivantes : - Détection (200), par un premier sous-ensemble identifié (Si), d'un second sous-ensemble identifié (S2), regroupement (208) des modules logiciels de ces deux sous-ensembles identifiés dans l'un (Si) de ces deux sous-ensembles identifiés, suppression (204) de l'autre de ces deux sous-ensembles identifiés, et synchronisation (206) de chaque module logiciel faisant initialement partie du sous-ensemble supprimé avec au moins l'un des modules logiciels du sous-ensemble (Si) choisi pour le regroupement. 5. Procédé de synchronisation selon l'une quelconque des revendications 1 à 4, dans lequel, dans chaque sous-ensemble identifié, un module logiciel est sélectionné pour être spécifiquement marqué comme identifiant de ce sous- ensemble identifié. 6. Procédé de synchronisation selon l'une quelconque des revendications 1 à 5, comportant en outre les étapes suivantes : - détection (300) d'une rupture de connexion entre deux parties complémentaires d'un sous-ensemble identifié (Si), comportant chacune au moins un module logiciel, à partir de ce sous-ensemble identifié (Si), génération (302) et identification de deux sous-ensembles (Si, S2) intégrant l'une, respectivement l'autre, des deux parties complémentaires. 7. Procédé de synchronisation selon l'une quelconque des revendications 1 à 6, comportant en outre les étapes suivantes : exécution (400), sur un premier module logiciel (14i) appartenant à un sous-ensemble identifié, d'une action (A) agissant sur une donnée numérique (Di) gérée par ce premier module logiciel, transmission (402) d'un message de synchronisation (M) identifiant l'action (A) à l'ensemble des autres modules logiciels (14j, 14k) du même sous-ensemble identifié comportant une réplication (Dj, Dk) de cette donnée numérique, 25 30sur réception de ce message (M) par l'un quelconque des modules logiciels concernés, exécution (404, 406) de l'action identifiée sur ce module logiciel de manière à agir sur la réplication de la donnée numérique située sur ce module logiciel. 8. Procédé de synchronisation selon l'une quelconque des revendications 1 à 7, comportant en outre les étapes suivantes : lors de la synchronisation du module logiciel candidat (14i), celui-ci comportant une partie des données numériques, extraction (602) d'un état des réplications de cette partie des données numériques sur au moins un autre module logiciel (14j), et enregistrement (604) du module logiciel candidat (14i) en tant que récepteur potentiel d'au moins un message de synchronisation identifiant une action sur une réplication de ses données numériques située sur un autre module logiciel, synchronisation (606, 608, 610, 612) des données numériques du module logiciel (14i) avec les données numériques de l'autre module logiciel (14j) et, pendant cette synchronisation, mise dans une file d'attente des messages de synchronisation éventuellement reçus, une fois la synchronisation terminée (614, 616), traitement de la file d'attente (618, 620). 9. Système de synchronisation d'un ensemble de modules logiciels (141, 181, 142, 143, 144, 145) d'un système informatique (10), comportant plusieurs serveurs (121, 122, 123, 124, 125) interconnectés en réseau (26, 30, 34), chaque module logiciel s'exécutant sur un serveur du système informatique pour la gestion d'un ensemble 25 (CA, CB1, CB2, CB3, CB4, CB5) de données dont au moins une partie est répliquée sur plusieurs modules logiciels, dans lequel la synchronisation entre deux modules logiciels de l'ensemble (14;, 14j) comporte une synchronisation des données communes qu'ils gèrent, caractérisé en ce qu'il comporte : - des moyens d'identification d'au moins un sous-ensemble regroupant 30 des modules logiciels de l'ensemble activés et synchronisés entre eux, et pour chaque module logiciel candidat (141 activé mais non synchronisé avec au moins un autre module logiciel de l'ensemble : ^ des moyens de recherche d'un autre module logiciel activé de 35 l'ensemble, 15 20^ si un autre module logiciel activé est trouvé et s'il appartient à un sous-ensemble identifié, des moyens de synchronisation du module logiciel candidat avec au moins l'un (14) des modules logiciels de ce sous-ensemble identifié, et ^ des moyens d'intégration du module logiciel candidat (14;) dans le sous-ensemble identifié. 10. Programme d'ordinateur téléchargeable depuis un réseau de communication et/ou enregistré sur un support lisible par ordinateur et/ou exécutable par un processeur, caractérisé en ce qu'il comprend des instructions de code de programme pour l'exécution des étapes d'un procédé de synchronisation selon l'une quelconque des revendications 1 à 8 lorsque ledit programme est exécuté sur un ordinateur.