Brevet FR2816732A1 — publié le 20020517

Compactage d'un fichier de configuration d'objets inclus dans un système informatique. DESCRIPTION Domaine technique La présente invention se rapporte à un procédé de compactage de fichiers de configuration d'objets appartenant à un système informatique. Le système informatique comprend des objets matériels (machines,...), et/ou logiciels (applications,...). Ce système est indifféremment un système distribué ou non, hétérogène ou non. Les objets comprennent des paramètres inclus dans le fichier de configuration. L'invention s'applique à tout fichier de configuration écrit dans un langage de balisage extensible, c'est-à-dire un langage qui présente de l'information encadrée par des balises. Le fichier de configuration est écrit en utilisant un métalangage de description dont le format est indépendant du matériel et/ou logiciel à configurer. Un métalangage se défini généralement comme étant un langage utilisé pour décrire un autre langage. Le langage de balisage XML (eXtensible Markup Language), connu de l'homme du métier, est bien adapté à la mise en oeuvre de la présente solution. Rappelons que la spécification du langage XML est définie par le consortium W3C (World Wide Web Consortium). Ce consortium est un organisme de promotion du World Wide Web , qui met au point des normes et des protocoles ouverts et libres, dans un souci d'Interopérabilité maximale. Le fichier de configuration XML a une structure déclarée dans un fichier de description. Ce fichier de description comprend la description des paramètres de configuration d'un objet et se nomme généralement Définition de Type de Document (DTD, Document Type Definition). Cette définition s'effectue selon un formalisme particulier également défini dans la spécification XML du consortium W3C. L'état de la technique Par définition, le langage XML distingue deux classes de documents : les documents bien formés et les documents valides. Un document XML est dit bien formé lorsqu'il obéit aux règles syntaxiques du langage XML pouvant donc être traité par un processeur adéquat, notamment par un processeur (parser) XML. Un document est dit valide lorsqu'il est bien formé et qu'il obéit en outre à une structure type défini explicitement dans le fichier de description DTD. Le processeur XML est donc utlisé pour lire les documents XML et pour accéder à leur contenu et à leur structure. En général, un processeur XML effectue un travail pour le compte d'une application. Un processeur XML est programmé de telle manière à lire les documents XML et à fournir, à l'application en question, les informations lues dans le document XML. Par définition, l'écriture d'un fichier de configuration dans un langage XML doit obéir à certaines contraintes syntaxiques. En effet, un document XML a une structure logique. Il se compose de descriptions, d'éléments, de commentaires, d'appels de caractère et d'instructions de traitement, qui sont indiqués dans le document par l'intermédiaire d'un balisage explicite. Chaque élément est encadré par une balise ouvrante, par exemple , et une balise fermante, par exemple . Les éléments sont structurés et décrivent les paramètres des objets. Les paramètres, comme un attribut d'un objet, peuvent être inclus à l'intérieur même des balises. Par exemple, on peut écrire signifiant que l'attribut sujet de l'élément LIVRE a la valeur k. Dans notre exemple de réalisation, les paramètres des objets sont définis dans un fichier de configuration écrit dans un langage XML tel que défini précédemment. Le problème principal est que les objets à configurer se comptent en milliers et que plusieurs de ces objets peuvent se reposer sur un même fichier de description DTD et avoir des valeurs identiques pour tout ou partie de leurs paramètres. Pour construire le fichier de configuration, l'administrateur du système de gestion doit alors valoriser les paramètres décrit dans le fichier de description autant de fois qu'il y a d'objets se reposant sur ce fichier DTD. Plus précisément, supposons que deux objets B1 et B2 se reposent sur un même fichier de description (DTD). Pour configurer l'objet B1, l'utilisateur doit valoriser tous les paramètres décrit dans le fichier DTD. Pour configurer l'objet B2, l'utilisateur doit à nouveau valoriser tous les paramètres décrit dans le fichier DTD. En conséquence, les paramètres de même valeur sont écrit autant de fois qu'il y a d'objets se reposant sur un même fichier de description. L'écriture d'un fichier de configuration présente donc des redondances. Le langage XML étant un langage de configuration de bas niveau, un utilisateur est donc contraint d'écrire dans le fichier de configuration des descriptions de paramètres répétitives dont la sémantique est, dans certains cas, sans rapport avec ses besoins, ce qui nécessite une culture importante de sa part de l'ensemble des syntaxes offertes par le langage XML. De ce fait, le fournisseur doit fournir avec le fichier de description une documentation précise. Il est clair qu'un fichier de configuration impose un coût en temps important en écriture. Cette redondance d'écriture a également pour conséquence d'augmenter l'espace mémoire occupé par le fichier de configuration. A l'heure actuelle, un fichier de configuration peut être très volumineux, et réduit considérablement l'espace mémoire pour l'implantation d'autres données comme des applications, etc. Un autre problème, lié au nombre important d'objets à décrire, est que si un utilisateur situé sur une machine quelconque du réseau souhaite visualiser des ressources du système informatique configurées dans le fichier de configuration, le système de gestion doit alors transmettre le fichier de configuration à la machine distante par l'intermédiaire du réseau. Lorsque le fichier de configuration a un gros volume, le flux de données entre le système de gestion et l'application cliente peut s'avérer très important et conduire à saturer le système de communication entre les applications clientes et le système de gestion. Enfin, un autre problème est que la syntaxe définie selon les recommandations du consortium W3C doit être respectée à la lettre tout au long de l'écriture du fichier de configuration. Le risque d'erreur lors de l'écriture d'un fichier de configuration est donc permanent pour un administrateur du système de gestion. Sommaire de l'invention Un premier but de la solution est donc de simplifier considérablement l'écriture des fichiers de configuration réduisant en conséquence à la fois le coût en temps d'écriture de celui-ci et le risque d'erreurs d'écriture. Un deuxième but visé est de réduire la taille du fichier de configuration permettant d'optimiser considérablement l'espace mémoire occupé par le fichier de configuration. A cet effet, la solution a pour objet un procédé de compactage d'un fichier de configuration d'au moins un objet matériel et/ou logiciel d'un système informatique, ledit fichier de configuration étant stocké dans une mémoire de stockage d'information et étant écrit en utilisant un métalangage de description dont le format est indépendant du matériel et/ou logiciel à configurer, ledit fichier de configuration incluant tout ou partie des paramètres dudit objet et se reposant sur un fichier de description incluant au moins un élément définissant des contraintes à respecter sur sa structure et sa syntaxe lors de son écriture, caractérisé en ce qu'il consiste, à inclure dans le fichier de description une réserve de valeurs, en ce qu'il consiste à attribuer à tout ou partie des éléments du fichier de description un identifiant, un élément avec un identifiant incluant au moins un paramètre dont la valeur est un pointeur propre à adresser une valeur de la réserve, et en ce qu'il consiste, lors de l'écriture du fichier de configuration, à instancier ladite réserve pour chaque noeud, l'instantiation d'un élément d'un noeud pouvant se limiter en un pointeur référençant un élément préalablement instantié. Il en résulte un système informatique comprenant au moins un processeur, des moyens de mémoire, des ressources physiques et/ou logiques dont les paramètres sont définis dans un fichier de configuration stocké dans une mémoire de stockage d'information et écrit en utilisant un métalangage de description dont le format est indépendant du matériel et/ou logiciel à configurer, ledit fichier de configuration incluant tout ou partie des paramètres dudit objet et se reposant sur un fichier de description définissant des contraintes à respecter sur sa structure et sa syntaxe lors de son écriture, caractérisé en ce que le fichier de description comprend au moins une réserve pour la mise en oeuvre du procédé défini précédemment. L'invention a aussi pour objet un fichier de description définissant des contraintes à respecter sur la structure et la syntaxe lors de l'écriture d'un fichier de configuration, ledit fichier de configuration étant stocké dans une mémoire de stockage d'information et étant écrit en utilisant un métalangage de description dont le format est indépendant du matériel et/ou logiciel à configurer, ledit fichier de configuration incluant tout ou partie des paramètres dudit objet, caractérisé en ce qu'il est contenu dans des moyens de mémoire et mis en oeuvre par au moins un processeur conformément au procédé défini précédemment. L'invention sera mieux comprise à la lecture de la description qui suit, donnée à titre d'exemple et faite en référence aux dessins annexés. Description d'un exemple de réalisation Dans les dessins : - la figure 1 est une vue synoptique de l'architecture d'un système informatique sur lequel peut s'appliquer la solution, - la figure 2 est une vue schématique de la description d'un arbre. - la figure 3 est une vue schématique de la description d'un arbre utilisant la notion de réserve conformément à la présente invention. Sur la figure 1, on a représenté un système informatique SYS distribué illustrant un exemple de réalisation préféré de la solution. Dans l'exemple illustré, ce système SYS inclut un système de gestion SG et au moins une machine M1. Dans la réalité, le système de gestion est apte à gérer un nombre important de machines. Ces machines peuvent être très diverses, telles que stations de travail, serveurs, routeurs, machines spécialisées et passerelles entre réseaux. Le système de gestion SG comprend au moins un système d'exploitation, au moins une mémoire de stockage d'informations et au moins un processeur PRO contrôlant le processus du traitement de l'information. Le terme gestion est utilisé pour être conforme à la traduction Afnor (Association Française de NORmalisation) de Management . Le système de gestion peut être assimilé à un ensemble de services qui interagissent entre eux pour donner une représentation objet du monde réel constitué notamment par les machines du système informatique. C'est une représentation objet qu'un administrateur manipule (surveillance, action) pour gérer le monde réel. La représentation objet porte sur des objets virtuels du monde réel et constitue un modèle objet. En d'autres mots, un objet géré par le système de gestion est une vue abstraite, définie pour les besoins de gestion, d'une ressource logique ou physique du système informatique. (disque, processeur, mémoire, etc.) et/ou logiques (fichiers, processus, sémaphores, etc.). Dans notre exemple, le système de gestion et les machines qu'il gère constituent une architecture Client/Serveur. Dans une telle architecture, une application cliente interroge le système de gestion pour connaître l'état des objets gérés par le système de gestion. Le mode client/Serveur a l'avantage de permettre à un utilisateur appelé client (ou application cliente) situé sur une machine, par exemple par l'intermédiaire d'un simple micro-ordinateur ou d'une station de travail, de confier une partie de sa tâche ou de ses opérations à effectuer au serveur à savoir le système de gestion. De cette manière, le client dispose d'une capacité de calcul beaucoup plus importante que celle de son micro-ordinateur. Le système informatique peut être hétérogène. Afin de masquer l'hétérogénéité du système informatique, le système de gestion SG et les machines gérées par le système de gestion comprennent au moins un agent respectif associé à un protocole de gestion. Un agent assure, entre autre, une conversion de protocole. Le système de gestion SG est relié à une machine gérée par l'intermédiaire d'un réseau quelconque. Le réseau peut être de type LAN (Local Area Network), WAN (Wide Area Network), etc. Un ensemble de couches logicielles s'interpose entre le système de gestion SG et le réseau RES et entre le réseau et chaque machine. Pour des raisons de simplification de la description, cet ensemble de couches logicielles n'est pas représenté sur la figure 1. Chaque objet géré comprend des paramètres définis dans un fichier de configuration. Le mode d'obtention des objets gérés et des paramètres associés est indifférent. Ceux-ci ont pu être téléchargés via le réseau RES, ou introduit en mémoire manuellement par l'intermédiaire d'un clavier. De préférence, le fichier de configuration est écrit dans un langage de description à balisage comportant une structure et incluant tout ou partie des paramètres (nom, au moins un attribut, au moins une action, etc. ) des objets. Le fichier de configuration se base sur un fichier distinct appelé fichier de description définissant les contraintes sur la structure et les contraintes syntaxiques des paramètres pour l'écriture dudit fichier de configuration associé à un objet d'une machine. De préférence, le fichier de configuration est écrit dans un langage de type XML, et le fichier de description est un fichier de description de type DTD, connus de l'homme du métier. Dans notre exemple de réalisation, ce fichier de configuration XML et le fichier de description DTD sont mémorisés dans des moyens de mémoire MEM inclus dans le système de gestion SG. Le système de gestion comprend un processeur spécifique dit processeur XML (terme utilisé dans la recommandation du W3C) et une pluralité d'applications APP. Ce processeur XML est un logiciel apte à lire le fichier de configuration XML et à accéder à son contenu et à sa structure. Concrètement, le processeur XML effectue un travail pour le compte d'une application APP. Ce processeur XML est programmé de telle manière à lire les documents XML et à fournir, à l'application en question, les informations lues dans le document XML. Dans notre exemple de réalisation, le fichier de description DTD est centralisé sur le système de gestion de façon à être utilisable par toutes les machines du réseau. De préférence, les objets gérés peuvent être représentés par un arbre, chaque noeud de l'arbre représentant un objet géré. Une application de visualisation APV incluse sur la machine M1 peut interroger le fichier de configuration dans le but de recevoir les paramètres des objets configurés et de visualiser ces objets sur cette machine. De préférence, pour la visualisation des paramètres de configuration des objets, la machine M1 est munie d'un navigateur standard dit Internet Explorer , connu de l'homme du métier, dans lequel un programme en langage JAVA est exécuté pour lire le fichier de configuration, accédant ainsi à son contenu et à sa structure, et pour transmettre les informations lues à (aux) applications de visualisation APV. Description de paramètres de configuration d'un ob ! et : Le cas étudié est celui d'une application de visualisation APV devant visualiser un ensemble d'objets par l'intermédiaire d'un arbre. Chaque objet étant représenté par un noeud de l'arbre. L'exemple s'attache à définir la description de ces noeuds. Chaque description d'objet, pouvant être référencée, comporte au moins un attribut, son identifiant (Id). Un noeud a des propriétés comme : * l'identifiant de l'objet qu'il représente, * sa représentation graphique (label, icône, bulle de commentaire) * les actions qui peuvent s'exécuter sur cet objet incluant l'action "ouvrir" pour l'ouverture du noeud, l'action "fermer" pour la fermeture du noeud, l'action"développer"pour visualiser les noeuds subordonnés à un noeud, a etc. La figure 2 représente un exemple de structure d'un fichier de configuration. Dans un fichier de configuration, il y a un seul élément, appelé racine dont aucune partie n'apparaît dans le contenu d'un autre élément. Pour les autres éléments, si la balise de début est dans le contenu d'un autre élément, la balise de fin est automatiquement dans le contenu du même élément. Autrement dit, les éléments délimités par des balises de départ et de fin s'imbriquent correctement les uns dans les autres. Pour cette raison, le fichier de configuration peut être facilement modélisé par l'intermédiaire d'un arbre d'imbrication, ou arbre de contenance. Cet arbre est composé d'une racine. Trois noeuds (Noeud 1, Noeud 2, i Noeud 3) sont subordonnés à cette racine. Dans notre exemple de réalisation, chaque noeud (Noeud 1, Noeud 2, Noeud 3) contient une représentation graphique et chaque représentation graphique contient une icône et un label. Naturellement, l'exemple est choisi très simple afin de permettre une meilleure compréhension de l'invention. Chaque cadre pointillé de la figure représente une partie descriptive. La partie descriptive Arbre d'identifiant 1 est composée de 3 parties descriptives Noeud 1 d'identifiant 1.1 Noeud 2 d'identifiant 1.2 Noeud 3 d'identifiant 1.3 La partie descriptive Noeud 1 est composée d'une partie descriptive : - Représentation G raph i que d'identifiant 1. 1. 1, elle-même composée de 2 parties descriptives : - Label d'identifiant 1. 1. 1. 1, - et Icône d'identifiant 1. 1. 1. 2 La partie descriptive Noeud 2 est composée d'une partie descriptive : - ReprésentationGraphique d'identifiant 1.2. 1, elle-même composée de 2 parties descriptives : - Label d'identifiant 1.2. 1.1, - une référence sur Icône d'identifiant 1.1. 1.2. La partie descriptive Noeud 3 est composée d'une partie descriptive : - ReprésentationGraphique d'identifiant 1.3. 1 elle-même composée de 2 parties descriptives : - Label d'identifiant 1.3. 1.1, - et une référence sur Icône d'identifiant 1.1. 1.2. Cet exemple permet de voir : - Qu'une même partie descriptive Icône d'identifiant 1.1. 1.2 peut être référencée à des endroits différents d'un document. - Que des parties très voisines ReprésentationGraphique doivent être décrites complètements. Pour simplifier l'exemple, seule la représentation graphique de l'objet sera prise en considération, les remarques faites concernant la représentation graphique pouvant être aisément étendues aux autres propriétés du noeud. Un fichier de description DTD définissant un objet de l'arbre peut être écrit de la façon suivante, en respectant le formalisme particulier défini dans la spécification XML du consortium W3C : Dans ce fichier, CDATA #REQUIRED signifie que l'attribut en question doit être un bloc de texte contenant des caractères. Dans ce fichier, #PCDATA signifie bloc de caractères analysés. Dans la suite de la description, on appellera partie descriptive l'instantiation d'un élément respectif du fichier de description. Dans le fichier de configuration XML, la partie descriptive décrivant le noeud1 de l'arbre peut être écrit de la façon suivante, en respectant le fichier de description DTD : Noeud K/Chaîne > ICONSTD. gif Double-cliquez sur ce noeud pour voir ses fils Les parties descriptives décrivant les noeuds nommés Noeud1 et noeud2 de l'arbre, respectivement, doivent être écrites de la même façon à quelques différences près. Dans notre exemple, seul le paramètre "label" diffère entre chaque partie descriptive. On comprend bien que, si la configuration nécessite la description d'un grand nombre de noeuds dont seul le label varie, très vite le fichier de configuration va être volumineux, alors que seules les informations concernant le label sont pertinentes. Le gros problème est que l'emploi des références dans les fichiers de configuration se trouve souvent limité à cause de différences mineures. Toute évolution au niveau de la description d'un noeud entraînera de nombreuses modifications ce qui rend la maintenance fastidieuse et augmente le risque d'erreur. A cet effet, l'invention consiste à pouvoir utiliser plus massivement les références en donnant la possibilité d'instancier une partie descriptive référencée en fonction de la position dans l'arbre de sa référence. Pour cela, la solution consiste à rendre possible au niveau de chaque noeud de la structure du document, l'enrichissement de ce que nous appellerons une réserve de couples (Clé ; valeur). Plus précisément, le procédé de compactage consiste à inclure dans le fichier de description une réserve de valeurs, à attribuer à tout ou partie des éléments du fichier de description un identifiant, un élément avec un identifiant incluant au moins un paramètre dont la valeur est un pointeur propre à adresser une valeur de la réserve. Ensuite, lors de l'écriture du fichier de configuration, le procédé de compactage consiste à instancier ladite réserve pour chaque noeud, l'instantiation d'un élément pouvant se limiter en un pointeur référençant un élément comportant un identifiant. Le principe de la solution consiste à rendre possible l'utilisation des valeurs de la réserve en les adressant par leur clé, et ce dans chaque partie descriptive pouvant être référencée. Ainsi, chaque partie référencée bénéficie d'une réserve différente au moment où elle est référencée et donc son instanciation peut être différente. Ecriture du fichier de description et introduction de la notion de réserve dans un fichier de description : La figure 3 représente la structure d'un fichier de configuration permettant de visualiser le principe de la solution. Dans notre exemple de réalisation, la réserve comprend un seul couple. Naturellement, la réserve peut contenir un nombre quelconque de couples. Chaque cadre en pointillé représente une partie descriptive. Les cadres à bord gras représentent l'enrichissement de la réserve. A chaque partie descriptive la réserve peut être enrichie. La partie descriptive Arbre d'identifiant 1 est composée de 3 parties descriptives # Noeud 1 d'identifiant 1.1 # Noeud 2 d'identifiant 1.2 w Noeud 3 d'identifiant 1. 3 ; La partie descriptive Noeud 1 ajoute à la réserve le couple (Clé=LABEL ; valeur= Noeud 1 ). Elle est composée d'une partie descriptive : # ReprésentationGraphique d'identifiant RGSTD composée de 2 parties descriptives : . Label d'identifiant 1. 1. 1. 1 qui utilise la valeur de la clé LABEL de la réserve, c'est à dire Noeud 1 Label instancié donne : Noeud 1 # Icône d'identifiant 1.1. 1.2 La partie descriptive Noeud 2 ajoute à la réserve le couple (Clé=LABEL ; valeur= Noeud 2 ). Elle est composée d'une référence à la partie descriptive : # ReprésentationGraphique d'identifiant RGSTD Dans ce contexte elle est composée de 2 parties descriptives : # Label d'identifiant 1.1. 1.1 qui utilise la valeur de la clé LABEL de la réserve, c'est à dire Noeud 2 . Label instancié donne : Noeud 2 dans ce contexte. # Icône d'identifiant 1.1. 1.2 La partie descriptive Noeud 3 ajoute à la réserve le couple (Clé=LABEL ; valeur= Noeud 3 ). Elle est composée d'une référence à la partie descriptive : e ReprésentationGraphique d'identifiant RGSTD Dans ce contexte elle est composée de 2 parties descriptives : # Label d'identifiant 1.1. 1.1 qui utilise la valeur de la clé LABEL de la réserve, c'est à Noeud 3 . Label instancié donne : Je suis le noeud 3 dans ce contexte. # Icône d'identifiant 1.1. 1.2 La méthode consiste à élargir la définition du Noeud afin de permettre d'enrichir la réserve et dans ce contexte à élargir la notion de Chaîne afin de pouvoir accepter une valeur de la réserve. Une modification de la DTD pourrait être la suivante : Clé CDATA #REQUIRED Valeur CDATA #REQUIRED > L'écriture % équivalent~chaîne ; signifie qu'il faut remplacer l'entité équivalent-chaîne par son contenu Chaîne 1 ValeurDeLaReserve c'est à dire une chaîne de caractères ou une valeur de la réserve. (AjouterALaReserve) * signifie 0 ou une ou plusieurs occurrence de AjouterALaReserve . Il peut donc être ajoutés autant de couples (clé ; valeur) à la réserve que nécessaire. Il devient alors possible d'écrire le noeud 1 comme ceci : ICONSTD gif Double-cliquez sur ce noeud pour voir ses fils Cette écriture permet d'écrire les noeuds suivants de façon beaucoup plus concise : L'écriture signifie une référence sur la description d'identifiant RGSTD . En étendant cette méthode à tous les éléments de la DTD, les gains en volume de description peuvent être très importants. De plus, toute évolution d'une description est partagée avec tous les éléments qui la référence ce qui permet des gains en temps et une maintenance plus aisée. D'une manière générale, la présente invention a pour objet un procédé de compactage d'un fichier de configuration d'au moins un objet matériel et/ou logiciel d'un système informatique, ledit fichier de configuration étant stocké dans une mémoire de stockage d'information et étant écrit en utilisant un métalangage de description dont le format est indépendant du matériel et/ou logiciel à configurer, ledit fichier de configuration incluant tout ou partie des paramètres dudit objet et se reposant sur un fichier de description incluant au moins un élément définissant des contraintes à respecter sur sa structure et sa syntaxe lors de son écriture, caractérisé en ce qu'il consiste, à inclure dans le fichier de description une réserve de valeurs, en ce qu'il consiste à attribuer à tout ou partie des éléments du fichier de description un identifiant, un élément avec un identifiant incluant au moins un paramètre dont la valeur est un pointeur propre à adresser une valeur de la réserve, et en ce qu'il consiste, lors de l'écriture du fichier de configuration, à instancier ladite réserve pour chaque noeud, l'instantiation d'un élément d'un noeud pouvant se limiter en un pointeur référençant un élément préalablement instantié. On a vu dans notre exemple illustré que l'inclusion de la réserve consiste à définir au moins un couple de valeurs incluant une clé adressable et un paramètre respectif dont la valeur est à spécifier lors de l'écriture du fichier de configuration. On a vu que l'instantiation préalable d'un élément consiste, lors de l'écriture du fichier de configuration, à écrire entièrement une première partie descriptive associée à un élément. Ensuite, il consiste à pointer sur cette partie descriptive autant de fois qu'on le souhaite. Avantageusement, tout ou partie des paramètres de chaque partie descriptive ont la valeur de la réserve qu'elle référence. De façon à être adressable, chaque clé de la réserve a de préférence un identifiant unique. On a vu aussi que l'instantiation de ladite réserve pour chaque noeud consiste à donner une valeur à chaque paramètre de la réserve, valeur qui est fonction de l'élément associé à cette réserve. On a vu aussi qu'une réserve peut être introduite dans chaque élément du fichier de description donnant la possibilité d'enrichir une réserve à chaque partie descriptive du fichier de configuration.. Il en résulte un système informatique comprenant au moins un processeur, des moyens de mémoire, des ressources physiques et/ou logiques dont les paramètres sont définis dans un fichier de configuration stocké dans une mémoire de stockage d'information et écrit en utilisant un métalangage de description dont le format est indépendant du matériel et/ou logiciel à configurer, ledit fichier de configuration incluant tout ou partie des paramètres dudit objet et se reposant sur un fichier de description définissant des contraintes à respecter sur sa structure et sa syntaxe lors de son écriture, caractérisé en ce que le fichier de description comprend au moins une réserve pour la mise en oeuvre du procédé défini précédemment. Enfin, l'invention a aussi pour objet le fichier de description définissant des contraintes à respecter sur la structure et la syntaxe lors de l'écriture d'un 1 fichier de configuration, ledit fichier de configuration étant stocké dans une mémoire de stockage d'information et étant écrit en utilisant un métalangage de description dont le format est indépendant du matériel et/ou logiciel à configurer, ledit fichier de configuration incluant tout ou partie des paramètres dudit objet, caractérisé en ce qu'il est contenu dans des moyens de mémoire et mis en oeuvre par au moins un processeur conformément au procédé défini précédemment. En conclusion, on s'aperçoit que la solution offre de nombreux avantages. Un premier avantage est la simplification considérable de l'écriture d'un fichier de configuration. Les références peuvent être utilisées abondamment, et seules les parties permettant de les instanciées sont spécifiées par l'intermédiaire de la réserve. En conséquence, l'administrateur évite ainsi la répétition de paramètres t identiques entre objets. Le coût en temps d'écriture et le risque d'erreur lors de l'écriture du fichier de configuration est largement réduit. De plus, l'utilisation accrue des références réduit considérablement la taille du fichier de configuration. La taille du fichier de configuration étant réduit, le transfert de ce fichier s'effectue donc plus rapidement. La méthode est complètement compatible avec les analyseurs XML du marché puisqu'elle n'utilise qu'une extension du langage de description (or ces langages sont justement conçus pour être étendus). REVENDICATIONS 1-Procédé de compactage d'un fichier de configuration d'au moins un objet matériel et/ou logiciel d'un système informatique, ledit fichier de configuration étant stocké dans une mémoire de stockage d'information et étant écrit en utilisant un métalangage de description dont le format est indépendant du matériel et/ou logiciel à configurer, ledit fichier de configuration incluant tout ou partie des paramètres dudit objet et se reposant sur un fichier de description incluant au moins un élément définissant des contraintes à respecter sur sa structure et sa syntaxe lors de son écriture, caractérisé en ce qu'il consiste, à inclure dans le fichier de description une réserve de valeurs, en ce qu'il consiste à attribuer à tout ou partie des éléments du fichier de description un identifiant, un élément avec un identifiant incluant au moins un paramètre dont la valeur est un pointeur propre à adresser une valeur de la réserve, et en ce qu'il consiste, lors de l'écriture du fichier de configuration, à instancier ladite réserve pour chaque noeud, l'instantiation d'un élément d'un noeud pouvant se limiter en un pointeur référençant un élément préalablement instantié. 2-Procédé de compactage selon la revendication 1, caractérisé en ce que l'inclusion de la réserve consiste à définir au moins un couple de valeurs incluant une clé adressable et un paramètre respectif dont la valeur est à spécifier lors de l'écriture du fichier de configuration. 3-Procédé de compactage selon la revendication 1 ou 2, caractérisé en ce qu'il consiste, lors de l'écriture du fichier de configuration, à écrire entièrement une première partie descriptive associée à un élément et ensuite à pointer sur cette partie descriptive autant de fois qu'on le souhaite. 4-Procédé de compactage selon l'une des revendications 1 à 3, caractérisé en tout ou partie des paramètres de chaque partie descriptive ont la valeur de la réserve qu'elle référence. 5-Procédé de compactage selon l'une des revendications 1 à 4, caractérisé en ce que chaque clé de la réserve a un identifiant unique. 6-Procédé de compactage selon l'une des revendications 1 à 5, caractérisé en ce que l'instantiation de ladite réserve pour chaque noeud consiste à donner une valeur à chaque paramètre de la réserve, valeur qui est fonction de l'élément associé à cette réserve. 7-Procédé de compactage selon l'une des revendications caractérisé en ce qu'une réserve est introduite dans chaque élément du fichier de description donnant la possibilité d'enrichir une réserve à chaque partie descriptive du fichier de configuration.. 8-Système informatique comprenant au moins un processeur, des moyens de mémoire, des ressources physiques et/ou logiques dont les paramètres sont définis dans un fichier de configuration stocké dans une mémoire de stockage d'information et écrit en utilisant un métalangage de description dont le format est indépendant du matériel et/ou logiciel à configurer, ledit fichier de configuration incluant tout ou partie des paramètres dudit objet et se reposant sur un fichier de description définissant des contraintes à respecter sur sa structure et sa syntaxe lors de son écriture, caractérisé en ce que le fichier de description comprend au moins une réserve pour la mise en oeuvre du procédé défini par l'une des revendications 1 à 7. 9-Fichier de description définissant des contraintes à respecter sur la structure et la syntaxe lors de l'écriture d'un fichier de configuration, ledit fichier de configuration étant stocké dans une mémoire de stockage d'information et étant écrit en utilisant un métalangage de description dont le format est indépendant du matériel et/ou logiciel à configurer, ledit fichier de configuration incluant tout ou partie des paramètres dudit objet, caractérisé en ce qu'il est contenu dans des moyens de mémoire et mis en oeuvre par au moins un processeur conformément au procédé défini par l'une des revendications 1 à 7.