FR 2785691 A1 20000512 FR 9814150 A 19981110 Procédé de déclenchement généralisé d'actions d'administration sur un système informatique distribué. La présente invention concerne un procédé de déclenchement généralisé d'actions d'administration sur un système informatique distribué. Un système informatique distribué comprend en général un ensemble de machines ou ordinateurs constituant un réseau. Ce réseau est administré par un utilisateur par l'intermédiaire d'un système de gestion ou d'administration (manager) constitué d'un logiciel administrateur utilisant une base d'information, par exemple une base d'information de gestion (MIB: io Management Information Base) constituée d'objets et exécuté par au moins un ordinateur de gestion. Ce logiciel doit être capable d'exécuter sur l'ensemble du réseau ou individuellement sur chaque machine des actions d'administration. Cependant, en règle générale, les machines constituant le réseau ne sont pas toutes identiques. De plus, certains groupes de machines peuvent avoir un système d'exploitation ou environnement différent d'autres groupes de machines. Dans ce type de réseau, une même action d'administration destinée à l'ensemble du système doit donc avoir un formalisme ou une sémantique différente en fonction des différents groupes constituant le système, ce qui complique sensiblement le travail de l'utilisateur qui doit non seulement connaître les propriétés de tous les groupes, mais également la sémantique des commandes de gestion de ces différents groupes. La présente invention a donc pour objet de pallier les inconvénients de l'art antérieur en proposant un procédé de déclenchement généralisé d'action d'administration permettant de cacher à l'utilisateur l'hétérogénéité du système informatique à administrer. Ce but est atteint par le fait que le procédé de déclenchement généralisé d'action d'administration sur un système informatique distribué géré par un logiciel administrateur utilisant une base d'informations (MIB: Management Information Base) mémorisée dans des moyens de mémorisation et représentant des objets définissant un domaine principal comprenant au 2 2785691 moins deux sous-domaines, chaque sous-domaine comprenant un groupe de machines et/ou au moins un autre sous-domaine, est caractérisé en ce que le procédé comprend d'une part, une étape d'initialisation comprenant: une première étape d'association et de mémorisation o chaque action d'administration du domaine principal est associée à une action spécifique, pour chaque sous-domaine, toutes ces actions spécifiques ayant la même fonctionnalité correspondant à la réalisation de l'action d'administration, une deuxième étape de création et de mémorisation, pour chaque action spécifique, d'au moins un jeu de paramètres nommé comprenant les io paramètres nécessaires à la mise en oeuvre de l'action spécifique, chaque nom de jeux de paramètres nommés étant identique pour toutes les actions spécifiques réalisant la même action d'administration; et d'autre part, une étape d'utilisation. Selon une autre particularité, I'étape d'utilisation comprend le is déclenchement par un utilisateur d'une action d'administration déterminée du domaine principal, une fois l'action d'administration déclenchée, le logiciel administrateur recherche et identifie sur chaque sous-domaine du système, l'action spécifique de l'action d'administration déterminée ainsi que le jeu de paramètres nommé associé à l'action spécifique, puis envoie vers chaque sous-domaine une commande pour l'exécution de la l'action d'administration déterminée ainsi que les paramètres du jeu de paramètre nommé associé à l'action spécifique de chaque sous-domaine. Selon une autre particularité, un sous-domaine regroupe des machines ayant, soit un environnement déterminé, soit une implantation géographique déterminée, soit un type d'application déterminé, soit une architecture déterminée, soit une utilisation déterminée. Selon une autre particularité, les différentes actions d'administration sont classées par type d'actions. Selon une autre particularité, la recherche et l'identification de l'action spécifique de l'action d'administration déterminée s'effectuent par l'intermédiaire d'une scrutation d'une base d'information du logiciel 3 2785691 administrateur comprenant l'identification de chaque sous domaine et de chaque action spécifique. Selon une autre particularité, tous les jeux de paramètre nommés d'une même action spécifique sont préalablement définis et mémorisés dans une base d'information, pour être réutilisables par le logiciel d'administration. Selon une autre particularité, l'étape d'utilisation comprend, avant le déclenchement de l'action d'administration par l'utilisateur, une étape de sélection d'une action d'administration par l'utilisateur parmi une liste d'action d'administration fournie par le logiciel administrateur et affichée sur des io moyens de visualisation de la machine, cette, cette sélection provoquant l'affichage d'au moins un nom de jeu de paramètre utilisable avec l'action d'administration, pour que l'utilisateur en sélectionne un, la sélection du nom du jeu de paramètre provoquant le déclenchement de l'action d'administration. D'autres particularités et avantages de la présente invention apparaîtront plus clairement à la lecture de la description ci-après faite en référence au dessin annexé dans lequel: - la figure 1 représente un schéma d'un exemple de système informatique avec lequel le procédé selon l'invention est mis en oeuvre. Afin de mieux comprendre l'invention il convient de préciser son domaine d'application. Le procédé selon l'invention est mis en oeuvre dans un système informatique distribué. Ce système informatique comprend une pluralité de machines (10, 20, 40) qui peuvent être, par exemple des ordinateurs ou des stations. Une particularité du système dans lequel est utilisé le procédé est que les machines peuvent être regroupées en divers sous- domaines (D1, D2) ayant par exemple en commun la même implantation géographique, le même système d'exploitation ou environnement par exemple, un premier sous-domaine (D1) utilisant le système UNIX (marque déposée par Unix Software Laboratory) et un deuxième sous-domaine (D2) utilisant le système Windows NT (marque déposée par la société Microsoft), ou le même domaine d'application, par exemple un premier domaine étant utilisé pour des applications de marketing et un deuxième domaine étant utilisé pour des 4 2785691 applications de comptabilité. L'ensemble des machines (10, 20, 40) du réseau du système forme au moins un domaine principal (DO). Chaque domaine principal (DO) selon l'invention, possède donc une architecture arborescente. En effet, chaque domaine principal (DO) comprend au moins deux sous- domaines (D1, D2), sachant qu'un sous domaine comprend un groupe de machines (20, 40) et/ou au moins un autre sous-domaine (21, 41). L'ensemble des domaines principaux est administré par un logiciel administrateur (30) du système ou manager installé sur une machine (10), par exemple du domaine principal DO comprenant une base d'informations (31), par exemple une base d'information de gestion ou MIB (Management Information Base) dans laquelle sont stockées sous forme arborescente, les informations sur le domaine principal (DO) et sur les sous domaines (D1, D2). Ce logiciel administrateur (30) permet de surveiller, configurer, ou assurer la maintenance du système. En règle générale, l'administration du système est i5 réalisée par différentes actions qui doivent être exécutées sur tous les sous- domaines (D1, D2) et toutes les machines (20, 40) de chaque domaine principal (DO). Or, comme expliqué précédemment, toutes les machines (20, ) du système ne sont pas nécessairement identiques. Ainsi, dans l'art antérieur, il est nécessaire d'adapter chaque action d'administration en fonction de chaque type de machine (20, 40) ou de chaque sous-domaine (D1, D2). Notamment, les actions, réalisées sur chaque sous-domaine (D1, D2) correspondant à la réalisation de la l'action d'administration n'utilisent pas nécessairement les mêmes paramètres ce qui oblige l'utilisateur à saisir autant de jeu de paramètres qu'il y a d'actions différentes à réaliser sur les sous- domaines (D1, D2). Le procédé selon l'invention permet de renseigner et d'exécuter une action d'administration en une seule opération de sorte que cette action d'administration soit exécutée de manière transparente par l'ensemble des actions spécifiques de chaque sous-domaine (D1, D2). La notion d'action spécifique sera décrite plus en détail ultérieurement. 2785691 A titre d'exemple non limitatif, une des actions d'administration consiste à créer un nouvel utilisateur pour un domaine principal (DO) selon l'invention. Selon l'art antérieur, cette action d'administration nécessite un certain nombre de paramètres en fonction des différents environnements des sous-domaines (D1, D2). Ainsi, il n'est pas possible de renseigner tous ces paramètres en une seule opération. De plus, l'utilisateur doit connaître l'ensemble des paramètres nécessaires pour chaque action spécifique de chaque sous-domaine (D1, D2). Rappelons qu'une action d'administration d'un domaine principal (DO) io ne possède pas d'implémentation réelle, car elle peut consister à l'exécution d'une pluralité d'actions comme expliqué en détail ultérieurement. Le procédé comprend une étape d'initialisation dans laquelle on associe dans une table (3421) chaque action d'administration de l'administrateur du réseau à une action spécifique de chaque sous- domaine (D1, D2) ayant la même fonctionnalité et correspondant à l'exécution de la l'action d'administration déterminée du domaine principal (DO). En d'autres termes, chaque action d'administration du domaine principal (DO) est associée à chaque action de chaque sous- domaine (D1, D2), qui sera exécutée sur ce sous-domaine pour réaliser l'action d'administration. Chaque action des sous-domaines ainsi associée sera considérée comme une action spécifique de l'action d'administration. Cette association est, par exemple, ensuite mémorisée dans un fichier (fic.ass) ou chargée en mémoire (32) sur la machine (10) sur laquelle fonctionne le logiciel administrateur (31) du système, pour les utilisations ultérieures de l'action d'administration. L'étape d'initialisation du procédé selon l'invention comprend également une étape de création, pour chaque action d'administration du système, d'au moins un jeu de paramètres nommé pour chaque action spécifique de l'action d'administration des sous-domaines. Pour tous les jeux de paramètres des actions spécifiques d'une action d'administration déterminée, le même nom sera choisi. 6 2785691 A titre d'exemple non limitatif, reprenons l'action d'administration consistant à créer un utilisateur, par exemple l'utilisateur Oracle, sur toutes les machines du domaine DO. On entend par utilisateur, une application ou un programme, une machine, un individu, etc. Cette action d'administration se nomme par exemple " CreateUser " (créer un utilisateur) sur le domaine DO. En règle générale, cette action d'administration nécessite de spécifier le nom de l'utilisateur, tel que par exemple une base de données Oracle. Selon l'invention, I'action d'administration " createUser " aura donc comme paramètre " Oracle ". Prenons également à titre d'exemple un domaine io principal DO constitué de deux sous-domaines. Un premier sous-domaine D1 comprend des machines fonctionnant dans un environnement " UNIX " et un deuxième sous- domaine (D2) comprend des machines fonctionnant dans un environnement " Windows NT ". Il est connu que les deux environnements choisis à titre d'exemple comprennent chacun une action permettant de créer un utilisateur. Par exemple, pour " UNIX ", il s'agit de l'action réelle permettant de créer un utilisateur libellée " Cr_User_UNIX " et pour " Windows NT " il s'agit de l'action réelle permettant de créer un utilisateur libellée " CrUserNT ". Selon l'invention, ces 2 actions sont déclarées comme des actions spécifiques de l'action d'administration " CreateUser " du domaine principal DO. Ensuite deux jeux de paramètres (P1, P2) nommés sont créés, chaque jeu de paramètres ayant comme nom " Oracle ". Rappelons que l'action d'administration " CreateUser " exécutée avec le nom de jeu de paramètres " Oracle " correspond à l'action d'administration " créer un utilisateur Oracle ". Un premier jeu de paramètres (P1) correspond aux paramètres nécessaires à l'exécution de l'action " créer un utilisateur Oracle " pour le sous- domaine (D1) regroupant les machines UNIX, un deuxième jeu de paramètres (P2) correspond aux paramètres nécessaires à l'exécution de l'action " créer un utilisateur Oracle " pour le sous-domaine (D2) regroupant les machines Windows NT. A titre d'exemple, le premier jeu de paramètres (P1) nommé " Oracle " est: Nom = oracle 7 2785691 Group = database Répertoire = /oracle, et le second jeu de paramètres (P2) nommé " Oracle " est: Nom = oracle Répertoire = C:\oracle. Ainsi, selon l'invention lorsque l'utilisateur souhaite réaliser l'action d'administration " créer un utilisateur Oracle ", celui-ci sélectionne dans un premier temps parmi une liste d'action (342) fournie par le logiciel administrateur, par exemple sur des moyens de visualisation (34), l'action io d'administration (3421) " créer un utilisateur " (CreateUser). Cette sélection provoque l'affichage par le logiciel administrateur (30), d'une liste (343) de noms de jeux paramètres nommés dans laquelle l'utilisateur sélectionne le nom " Oracle " (3431). Ensuite, le logiciel administrateur (30) cherche les actions spécifiques sur les sous-domaines (D1, D2). Pour ce faire, une description (32) par exemple sous forme de tableau de toutes les actions spécifiques (321) a chacun des sous-domaines, par exemple " Windows NT " et " UNIX " (voir page 9 et 12), est accessible par le logiciel administrateur (30), par exemple par l'intermédiaire, soit d'un chargement préalable de cette description (32) dans la mémoire de la machine (10) sur laquelle fonctionne le logiciel administrateur (30), soit d'un fichier mémorisé sur des moyens de mémorisation (non représentés) de cette même machine (10), par exemple ce fichier contenant dans cette description, un ou plusieurs attributs d'une MIB (non représentée) consultable par le logiciel administrateur (30). Cette description (32) comprend pour chaque action spécifique (321) notamment le nom de I'action spécifique, le nom de l'action d'administration à laquelle elle est associée, et le type d'actions auquel elle appartient. L'utilisation des types d'actions fournis par une liste (341) sera explicitée ultérieurement. Dans l'exemple choisi, le résultat de la recherche donnera, I'action spécifique " Cr_User_Unix " pour le sous-domaine D1, et l'action spécifique " Cr_User_NT " pour le sous-domaine D2 Comme expliqué précédemment, pour toutes les actions spécifiques trouvées, il existe des jeux de paramètres 8 2785691 (P1, P2) nommés portant le même nom. Ainsi, lorsque les actions spécifiques ainsi que les jeux de paramètres correspondants sont trouvés, le logiciel administrateur (30) envoie la commande de création d'utilisateur vers les sous- domaines (D1, D2) trouvés dans lesquels il existe des actions spécifiques, en spécifiant les paramètres (P1, P2) des jeux de paramètres nommés trouvés, associés à chaque action spécifique. Ainsi, en une seule opération, I'action d'administration " créer un utilisateur Oracle " est exécutée sur l'ensemble des sous-domaines avec les paramètres adéquats. Dans cet exemple, un jeu de paramètre (P1, P2) nommé " Oracle " est o crée pour chaque action spécifique de chaque sous domaine (D1, D2). Pour créer un nouvel utilisateur sur le domaine principal DO, un nouveau jeu de paramètres (P'1, P'2) nommé sera crée pour chaque action spécifique associée à l'action d'administration. Ainsi, pour l'action d'administration " créer un utilisateur ", il peut exister une pluralité de jeux de paramètres (P1, P'1, P2, P'2) nommés. Les jeux de paramètres (P1, P'1, P'2, P2) nommés, permettant l'exécution des actions spécifiques sur chaque sous-domaine, sont définis préalablement, et par exemple, mémorisés sur des moyens de mémorisation (33) de la machine (10) sur laquelle se situe le logiciel administrateur (30). Cette mémorisation est réalisée par exemple par la création d'un répertoire (331, respectivement 332) pour chaque action spécifique (Cr_User_Unix, Cr_UserNT). Chaque répertoire (331, 332) contient au moins un fichier (P1, P'I, respectivement, P2, P'2). Chaque fichier (P1, P'1, P2, P'2) correspond à la mémorisation d'un jeu de paramètres nommé correspondant à l'action spécifique associée au répertoire. Le nom de chaque répertoire correspond, par exemple au nom de l'action spécifique et le nom du fichier de paramètres correspond au nom du jeu de paramètre nommé. Ainsi, la recherche du jeu de paramètre nommé choisi par l'utilisateur consiste à rechercher dans chaque répertoire (331, 332) relatif à chaque action spécifique trouvée, le fichier respectif (P1, P'I, P2, P'2) ayant comme nom le nom du jeu de paramètre nommé choisi par l'utilisateur. 9 2785691 Afin de rechercher et d'identifier rapidement, tous les sous-domaines et toutes les actions spécifiques de chaque action d'administration, la base d'information par exemple comprenant une MIB (31) du logiciel administrateur (30) du système comprend des informations particulières. Une première information consiste par exemple en un attribut de l'objet (311) définissant le domaine principal (DO), dans la MIB (31), permet par exemple d'identifier la liste (341) des types d'actions permettant de définir les actions d'administrations (3421) parmi une liste d'actions (342) et correspondant aux actions d'administration supportées par le domaine principal. L'ensemble des io descriptions des actions d'administrations est alors mémorisé, par exemple dans la mémoire de la machine (10) sur laquelle fonctionne le logiciel administrateur (30). Le noms des actions d'administration peuvent par exemple être affichée sur les moyens de visualisation (34) sous forme de liste (341), de sorte que lorsque l'utilisateur sélectionne un type d'action (3411) dans la liste (341), le logiciel retrouve dans une deuxième liste (342) toutes les actions d'administrations faisant partie de ce type d'action. De même, chaque sous- domaine (D1, D2) du domaine principal (DO) est un objet (312, respectivement 313) de la MIB (31) dont un attribut correspond également aux types d'actions supportées par le sous-domaine. A titre d'exemple, les deux tableaux ci-dessous représentent une liste des types d'actions supportés par le sous-domaine D1 de type UNIX et le sous- domaine D2 de type Windows NT, ainsi que quelques actions particulières par type d'actions. Dans ces deux tableaux, chaque nom de type d'action est une instance particulière de l'attribut " types d'actions " des objets ( 312, 313) de la MIB des deux sous-domaines D1 et D2. Le premier tableau représente un exemple de types d'actions et d'actions possibles pour l'objet (312) du sous-domaine UNIX: Type d'actions Actions ICMCOfg Les actions de ce type sont utilisées pour la gestion nig des systèmes gérés par le logiciel administrateur. Ainsi, une première action permet l'installation de toutes les actions de ce type d'action sur les serveurs, c'est-à-dire la machine sur laquelle fonctionne le 2785691 logiciel administrateur. Une deuxième action permet de lister les actions installées, une troisième action permet d'instancier la MIB pour l'agent d'action, une quatrième action permet d'installer un équipement pouvant être administré par un logiciel administrateur. ICMManagerConfig Les actions de ce type sont utilisées pour la gestion du serveur. Ainsi, une première action permet d'installer tout ou partie des actions sur les serveurs, une deuxième action permet de créer une action. File Les actions de ce type sont utilisées pour la gestion des fichiers. Ainsi, une première action permet d'installer tout ou partie des actions sur les serveurs, une deuxième action permet de changer le groupe propriétaire d'un répertoire ou d'un fichier, une troisième action de changer les permissions d'accès d'un répertoire ou d'un fichier, une quatrième action permet de changer le propriétaire d'un répertoire ou d'un fichier, une cinquième action permet de créer un répertoire, une sixième action permet de créer un répertoire avec de multiples options. Command Les actions de ce type sont utilisées pour la gestion des commandes. Ainsi, une première action permet d'installer tout ou partie des actions sur les serveurs, une deuxième action permet d'exécuter une commande, une deuxième action permet d'exécuter un fichier de commandes. LVM Les actions de ce type sont utilisées pour la gestion des volumes logiques. Ainsi, une première action permet d'installer tout ou partie des actions sur les serveurs, une deuxième action permet de créer un volume logique, une troisième action permet de détruire un volume logique, une quatrième action permet d'étendre un volume logique, une cinquième action permet de créer un espace de pagination, une sixième action permet de détruire un espace de pagination, une septième action permet de lister les groupes de volumes. FileSystem Les actions de ce type sont utilisées pour la gestion des systèmes de fichiers. Ainsi, une première action permet d'installer tout ou partie des actions sur les serveurs, une deuxième action permet de créer un système de fichiers et son volume logique associé, une troisième action permet de créer un système de fichiers à partir d'un volume logique associé, une quatrième action permet de détruire un système de fichiers et son volume logique associé, une cinquième action permet de détruire un système de fichiers, une sixième action ll 2785691 permet d'étendre un système de fichiers, une septième action permet de créer un système de fichiers, une huitième action permet de détruire un système de fichiers, une neuvième action permet de monter un système de fichiers. Les actions de ce type sont utilisées pour la gestion User des utilisateurs. Ainsi, une première action permet d'installer tout ou partie des actions sur les serveurs, une première action permet de créer un groupe, une deuxième action permet de détruire un groupe, une troisième action permet de lister un groupe, une quatrième action permet de créer un utilisateur, une cinquième action permet de détruire un utilisateur, une sixième action permet de lister les utilisateurs, une septième action permet de modifier un utilisateur. Nfs Les actions de ce type sont utilisées pour la gestion des systèmes de fichiers réseau. Ainsi, une première action permet d'installer tout ou partie des actions sur les serveurs, une deuxième action permet d'exporter un répertoire, une troisième action permet de monter un système de fichiers, une quatrième action permet de démonter un système de fichiers, une cinquième action permet de supprimer l'exportation d'un système de fichiers. Printer Les actions de ce type sont utilisées pour la gestion des imprimantes. Ainsi, une première action permet d'installer tout ou partie des actions sur les serveurs, une deuxième action permet l'ajout d'une file d'attente sur un système distant, une troisième action permet de supprimer une file d'attente sur un système distant. Agent Les actions de ce type sont utilisées pour la gestion des agents. Ainsi, une première action permet d'installer tout ou partie des actions sur les serveurs, installer les agents, une deuxième action permet de relancer les agents, une troisième action permet d'initialiser les agents. SD Les actions de ce type sont utilisées pour la distribution des logiciels. Ainsi, une première action permet d'installer tout ou partie des actions sur les serveurs, distribuer un logiciel, une deuxième action permet de désinstaller un logiciel. SDPCServerMgt Les actions de ce type sont utilisées pour la distribution de logiciel pour PC. Ainsi, une première action permet d'installer tout ou partie des actions sur les serveurs, une deuxième action permet de délivrer un produit sur les serveurs. 12 2785691 SDPCStationMgt Les actions de ce type sont utilisées pour la distribution de logiciel pour PC. Ainsi, une première action permet d'installer tout ou partie des actions sur les serveurs, une deuxième action permet d'installer un lot de logiciel (package) sur les PC. Le deuxième tableau représente un exemple de types d'actions et d'actions possible pour l'objet (313) du sous-domaine Windows NT: Type d'actions Actions ICMConfigNT Les actions de ce type sont utilisées pour la gestion - des équipements NT. Ainsi, une première action permet d'installer tout ou partie des actions sur les serveurs, une deuxième action permet d'installer un équipement NT pouvant être administré par le logiciel administrateur. User NT Les actions de ce type sont utilisées pour la gestion des utilisateurs NT. Ainsi, une première action permet d'installer tout ou partie des actions sur les serveurs, une deuxième action permet de créer un utilisateur, une troisième action permet d'ajouter un utilisateur existant dans un groupe global existant, une quatrième action permet de créer un groupe global, une cinquième action permet d'enlever un utilisateur d'un groupe global, une sixième action permet de détruire un groupe global, une septième action permet d'ajouter un membre (utilisateur ou groupe global) dans un groupe local, une huitième action permet de créer un groupe local, une neuvième action permet d'enlever un membre (utilisateur ou groupe global) dans un groupe local, une dixième action permet de créer un groupe local, une onzième action permet d'enlever un membre (utilisateur ou groupe global) d'un groupe local, une douzième action permet de détruire un groupe local, une treizième action permet de détruire un utilisateur). RegistryNT Les actions de ce type sont utilisées pour la gestion du registre NT. Ainsi une première action permet d'installer tout ou partie des actions sur les serveurs, une deuxième action permet d'ajouter une nouvelle clé dans la base de registre, une troisième action permet de supprimer une clé dans la base de registre. ServiceNT Les actions de ce type sont utilisées pour la gestion des services NT. Ainsi, une première action permet d'installer tout ou partie des actions sur les serveurs, une deuxième action permet de modifier la 13 2785691 configuration de lancement d'un service, une troisième action permet de modifier le statut d'un service). DirectoryNT Les actions de ce type sont utilisées pour la gestion -_ des répertoires NT. Ainsi, une première action permet d'installer tout ou partie des actions sur les serveurs, une deuxième action permet de créer un répertoire, une troisième action permet de détruire un répertoire, une quatrième action permet de modifier les permissions d'un fichier ou d'un répertoire). Pour reprendre l'exemple précédant, I'action d'administration" créer un utilisateur " fait partie du type d'action permettant la gestion desutilisateurs, qui comprend également par exemple l'action d'administration " lister les utilisateurs " ou encore " modifier un utilisateur ". Dans cet exemple, pour le sous-domaine D1, I'action " Créer un utilisateur " (Cr_User_UNIX) fait partie du type d'action " User " et pour le sous-domaine D2, l'action " Créer un utilisateur " (CrUserNT) fait partie du type d'action " User_NT ". A l'action d'administration " créer un utilisateur " (CreateUser) sur le domaine principal DO fait partie par exemple du type d'action " UserO " du domaine principal DO. Alors, les actions " Cr_User_UNIX " et " CrUser_NT " sont des actions spécifiques de " CreateUser ". Cependant, il convient de remarquer pour ces 2 exemples de tableaux que certains types d'actions et actions ne se retrouvent pas dans les deux sous-domaines. Ces types d'actions et actions particuliers ne sont pas concernés par le procédé selon l'invention. En effet, le but du procédé est d'exécuter une action d'administration sur l'ensemble du domaine principal ce qui suppose que tous les sous-domaines du domaine principal sont capables de réaliser cetteaction d'administration. Par conséquent, les actions d'administration supportées par le domaine principal correspondent aux actions communes à tous les sous-domaines. Ainsi, selon l'invention, lorsque l'utilisateur du système déclenche une action d'administration sur le domaine principal, en sélectionnant dans I'affichage réalisé sur les moyens de visualisation (34), un type d'action (3411) 14 2785691 puis, I'action d'administration (3421) (" CreateUser "), et enfin le nom (3431) (" Oracle ") du jeu de paramètre nommé correspondant, le logiciel administrateur (30) effectue premièrement une scrutation de la base d'information (31) comprenant par exemple une MIB, pour identifier l'ensemble des objets (312, 313) de la base d'information (31) représentant les sous- domaines (D1, D2), appartenant au domaine principal (DO). Lorsque les actions d'administrations sont classées par type d'actions, I'utilisateur sélectionne dans un premier temps parmi une liste (341) de type d'action fournie par le logiciel administrateur (30), le type d'actions (3411) io correspondant à l'action d'administration, sachant que la liste (341) des types d'actions (3411) supportées par le domaine principal DO, est définie et mémorisée dans la base d'information (31). Cette mémorisation est réalisée par exemple par l'intermédiaire d'un attribut de l'objet (311) de la base d'information (31) représentant le domaine principal (DO). Dans l'exemple précédant l'action d'administration " CreateUser " permettant de créer un utilisateur sur le domaine principal fait, par exemple, partie du type d'action " UserO ". Deuxièmement, par l'intermédiaire d'une recherche dans les descriptions (321) des actions mémorisées dans la mémoire (32) de la machine (10), exécutée par exemple par un programme, le logiciel administrateur (30) identifie pour chaque sous-domaine (D1, D2) trouvé, I'action spécifique (CrUser_Unix, Cr_UserNT) de l'action d'administration (CreateUser), puis recherche dans chaque répertoire (331, 332) associé à chaque action spécifique (Cr_User_Unix, Cr_UserNT) identifiée, le fichier (P1, P2) contenant les paramètres correspondant au nom du jeu de paramètre (Oracle) sélectionné par l'utilisateur. Une fois toutes les actions spécifiques (Cr User_Unix, Cr_UserNT) et les jeux de paramètre (P1, P2) correspondants identifiés, le logiciel administrateur (30) envoie vers chaque sous-domaine (D1, D2) identifié, une commande pour l'exécution de l'action spécifique identifiée associée au sous-domaine en utilisant le jeu de paramètres associé au sous- domaine. 2785691 Il est clair que le procédé de l'invention permet ainsi à l'utilisateur de déclencher des actions d'administration sans avoir à connaître la constitution du système ou la sémantique des commandes. D'autres modifications à la portée de l'homme du métier entrent dans le s cadre de l'invention. 16 2785691 REVENDICATIONS 1. Procédé de déclenchement généralisé d'action d'administration sur un système informatique distribué géré par un logiciel administrateur (30) utilisant une base d'information mémorisée dans des moyens de mémorisation et des objets définissant un domaine principal (DO) comprenant au moins deux sous-domaines (D1, D2), chaque sous-domaine (D1, D2) comprenant un groupe de machines (20, 40) et/ou d'au moins un autre sous-domaine (21, 41), est caractérisé en ce que le procédé comprend d'une part, une étape io d'initialisation comprenant: une première étape d'association et de mémorisation o chaque action d'administration du domaine principal est associée à une action spécifique, pour chaque sous-domaine (D1, D2) les différentes actions spécifiques ayant la même fonctionnalité correspondant à la réalisation de lI'action d'administration, une deuxième étape de création et de mémorisation pour chaque action spécifique d'au moins un jeu de paramètres (P1, P'1, P2, P'2) nommé comprenant les paramètres nécessaires à la mise en oeuvre de l'action spécifique, chaque nom de jeux de paramètres étant identique pour toutes les actions spécifiques d'une même action d'administration; et d'autre part, une étape d'utilisation. 2. Procédé de déclenchement généralisé d'action d'administration sur un système informatique distribué selon la revendication 1, caractérisé en ce que l'étape d'utilisation comprend le déclenchement par un utilisateur d'une action d'administration déterminée du domaine principal (DO), une fois cette action d'administration déterminée déclenchée, le logiciel administrateur (30) recherche et identifie sur chaque sous-domaine (D1, D2) du système, I'action spécifique de l'action d'administration déterminée ainsi que le jeu de paramètres nommé associé à l'action spécifique, puis envoie vers chaque sous-domaine (D1, D2) une commande pour l'exécution de l'action spécifiques 17 2785691 identifiée ainsi que les paramètres du jeu de paramètre nommé associé à l'action spécifique de chaque sous-domaine. 3. Procédé de déclenchement généralisé d'action d'administration sur un système informatique distribué selon la revendication 2, caractérisé en ce qu'un sous-domaine (D1, D2) regroupe des machines (20, 40) ayant, soit un environnement déterminé, soit une implantation géographique déterminée, soit un type d'application déterminé, soit une architecture déterminée. 4. Procédé de déclenchement généralisé d'action d'administration sur un système informatique distribué selon l'une des revendications 1 à 3, io caractérisé en ce que les différentes actions d'administration sont classées par type d'actions. 5. Procédé de déclenchement généralisé d'action d'administration sur un système informatique distribué selon l'une des revendications 1 à 4, caractérisé en ce que la recherche et identification de l'action spécifique de I'action d'administration déterminée s'effectuent par l'intermédiaire d'une scrutation de la base d'informations (31) du logiciel administrateur (30) comprenant l'identification de chaque sousdomaine et de chaque action spécifique. 6. Procédé de déclenchement généralisé d'action d'administration sur un système informatique distribué selon l'une des revendications 1 à 5, caractérisé en ce que tous les jeux de paramètres (P1, P'1, P2, P'2) nommés d'une même action spécifique sont préalablement définis et mémorisés dans la base d'information accessible par le logiciel administrateur, pour être réutilisable. 7. Procédé de déclenchement généralisé d'action d'administration sur un système informatique distribué selon l'une des revendications 1 à 5, caractérisé en ce que tous les jeux de paramètres (P1, P'1, P2, P'2) nommés d'une même action spécifique sont préalablement définis et mémorisés dans un répertoire sous forme de fichier sur la machine (10) sur laquelle est installé le logiciel administrateur, pour être réutilisables. 18 2785691 8. Procéde de déclenchement généralisé d'action d'administration sur un système informatique distribué selon l'une des revendications 1 à 7, caractérisé en ce que l'étape d'utilisation comprenant, avant le déclenchement de l'action d'administration par l'utilisateur, une étape de sélection de cette action d'administration (3431) par l'utilisateur parmi une liste (342) d'actions d'administrations fournie par le logiciel administrateur (30) et affichée sur les moyens (34) de visualisation de la machine, cette sélection provoquant l'affichage d'au moins un nom de jeu de paramètre (343) utilisable avec l'action d'administration, pour que l'utilisateur en sélectionne un (3431), la sélection du 1o nom du jeu de paramètre provoquant le déclenchement de l'action d'administration. 9. Procédé de déclenchement généralisé d'action d'administration sur un système informatique distribué selon l'une des revendications 1 à 7, caractérisé en ce que la base d'information utilisée par le logiciel administrateur comprend une base d'information de gestion (MIB:Management information Base) représentant sous forme arborescente des objets définissant un domaine principal (DO) comprenant au moins deux sous-domaines (D1, D2), chaque sous-domaine (D1, D2) comprenant un groupe de machines (20, 40) et/ou d'au moins un autre sous-domaine (21, 41).