FR 2810432 A1 20011221 FR 0007636 A 20000615 Titre : Procédé de gestion de contrôle de cohérence paramètres associés à ressources physiques et/ou logiques dans un système informatique. Domaine techniaue L'invention se rapporte à un procédé de gestion contrôle de cohérence paramètres associés à des ressources physiques et/ou logiques dans un systeme informatique. Le systeme informatique comprend une machine ou plusieurs machines reliées entre elles par l'intermédiaire d'un réseau de type (Local Area Network), (Wide Area Network) ou INTERNET. Ce systeme peut être un système distribué ou non, hétérogène ou non. Au moins une machine de ce système informatique un système de gestion. machines sont connectées directement ou indirectement à ce système gestion. Un système de gestion de machines type OpenMaster (marque deposée par la société BULL S.A.), connu de l'homme métier, est particulièrement bien adapté pour la mise en oeuvre de la presente solution. Ce systeme de gestion peut être assimilé à un ensemble services qui interagissent entre eux pour donner une représentation virtuelle monde réel (les ressources physiques ou logiques) constitué par le système informatique. C'est une representation virtuelle qu'un administrateur, du système de gestion, manipule (surveillance, action) pour gérer le monde réel. définition, la représentation virtuelle porte sur des objets du monde réel constitue donc un modèle objet. Cette représentation virtuelle est materialisée par l'intermédiaire d'un arbre de contenance. Signalons que le terme gestion est utilisé pour être conforme à la traduction de Management de l'Agence Française de Normalisation (Afnor). Egalement, dans la suite de la description, le terme arbre de contenance est utilisé pour être conforme à la traduction de MIB (Management Information Base). L'état de la technique Chaque ressource à des propriétés définies par l'intermédiaire de paramètres peuvent être, notamment, un ou plusieurs attributs comprenant des valeurs lesquelles des actions peuvent être exécutées. Le système de gestion procure des services, notamment service donnant la possibilité de surveiller les objets répartis sur les machines du système informatique. Ce service de surveillance est plus communément appelé service de contrôle de cohérence en ce sens qu'il permet de surveiller les valeurs de chaque paramètre par rapport à un fichier de configuration établit fixant des valeurs souhaitées des paramètres que l'on appellera valeurs nominales des objets dans la suite de la description. Le principe du contrôle de cohérence consiste à comparer la valeur réelle d'un paramètre d'un objet distant à l'instant t avec la valeur nominale de ce paramètre définie au préalable dans le fichier de configuration. Si la valeur réelle n'est pas celle définie dans le fichier de configuration, une action dite correctrice peut être exécutée de façon à ce que la valeur du paramètre correspond à la valeur nominale définie dans le fichier de configuration. La mise en oeuvre d'un contrôle de cohérence , pour un utilisateur, nécessite de saisir, - tout d'abord, dans une requête, la description complète des valeurs à contrôler, exemple le contrôle de la taille d'un fichier temporaire, - ensuite le moyen d'accéder à cet objet (par exemple connaître le chemin d'accès du fichier temporaire à interroger) - enfin l'action correctrice avec son paramétrage. De cette façon, la requête accède aux objets interrogés et fournie les valeurs de ces objets. Ensuite, l'action correctrice peut être éventuellement exécutée lorsque les valeurs de référence inscrite dans le fichier de configuration ne sont pas atteintes. Dans le système de gestion connu nommé OpenMaster , l'utilisateur dispose de plusieurs fenêtres de dialogue, notamment une fenêtre de dialogue pour le lancement de la requête et une autre fenêtre de dialogue pour l'exécution de l'action correctrice. Une requête peut être de différents type CMIS, SQL, un script, etc. Une interface du système de gestion donnant la possibilité d'interroger ces sources de données hétérogènes est decrite dans la demande de brevet français N 2776789 déposée au de la demanderesse. En d'autres mots, l'utilisateur doit saisir les paramètres de la requête dans une fenêtre de dialogue. Après réception des valeurs réelles des paramètres issues du résultat de la requête, l'utilisateur doit sélectionner, dans une autre fenêtre de dialogue indépendante de la première, une action parmi celles sont proposées (installer des agents, monter des systèmes de fichier, créer des utilisateurs, etc.) et doit paramétrer correctement cette action correctrice pour que le déclenchement de celle-ci, corrige effectivement le (ou les) paramètre(s) venant d'être accédé(s) par la requête. gros problème est que la fenêtre de dialogue associée à la requête et la fenêtre de dialogue associé à l'action correctrice sont indépendantes l'une de l'autre. En effet, l'utilisateur doit définir, dans une fenêtre de dialogue, les variables (le résultat qu'il souhaite obtenir) pour lesquelles il veut obtenir la valeur reelle, et donc les objets qu'elles caractérisent (système de fichier, compte utilisateur, présence d'une MIB), et, dans une autre fenêtre de dialogue indépendante, les objets sur lesquels portent les actions correctrices. Cette double saisie complique la tâche de configuration de l'application et est source d'erreurs. Un autre problème est que l'utilisateur doit aussi préciser ' les valeurs des variables obtenues doivent être récupérées comme paramètres pour l'action correctrice. En d'autres mots, l'utilisateur doit tenir compte du résultat, de la requête pour lancer une action ou non. Comme ces valeurs ne peuvent pas être déterminées par avance, cela oblige à utiliser une notation symbolique dans le paramétrage de l'action correctrice pour faire référence à variables. Cette forme de saisie vient du fait que le contrôle de cohérence est considéré comme un tout, mettant sur un même plan la nature de ce qui est contrôlé, et la désignation des objets sur lesquels il porte ainsi que les valeurs de référence qui doivent être vérifiées. L'invention Un premier but visé est de guider l'utilisateur dans l'écriture de l'action correctrice afin qu'elle corresponde effectivement à la correction attendue. Un second but visé est de simplifier considérablement le paramétrage d'une requête et d'une action. Un troisième but visé est de fournir une interface utilisateur simple d'utilisation. cet effet, l'invention a pour objet un procédé de contrôle de coherence, dans système informatique, entre des paramètres associés ' des ressources physiques et/ou logiques du système informatique et un fichier de configuration incluant les valeurs nominales de ces paramètres, le procédé consistant à interroger ces paramètres par l'intermédiaire d'au moins une requête, l'écriture d'une requête incluant au moins un paramètre à interroger et au moins une variable donnant la valeur courante des paramètres, ledit procédé consistant ensuite à sélectionner et exécuter une action correctrice prédéfinie sur ledit au moins un paramètre dont la valeur n'est pas cohérente avec la valeur nominale définie dans le fichier de configuration, l'écriture d'une action incluant au moins un paramètre sur lequel l'action doit être exécutée, caractérisé en ce qu'il consiste à créer au moins un objet Requête/Action dit de configuration autorégulatrice incluant chacun - un type de requête les paramètres associés, - et au moins une action spécifique à ce type de requête et les paramètres associés, tout ou partie des paramètres de l'objet étant indéfinis et devant être renseignés avant exécution de l'application correspondante. L'utilisateur a à sa disposition, non plus requêtes permettant d'obtenir des valeurs pour des variables, et indépendamment, des actions à paramétrer, mais un seul objet "Configuration auto régulatrice" qui fait la synthèse des deux. II en résulte une fenêtre de dialogue pour contrôle de cohérence, dans un système informatique, entre des paramètres associés à des ressources physiques et/ou logiques du système informatique et un fichier de configuration incluant les valeurs nominales de ces paramètres, le procédé consistant à interroger ces paramètres par l'intermediaire d'au moins une requête, l'écriture d'une requête incluant au moins un paramètre à interroger et au moins une variable donnant la valeur courante des paramètres, ledit procédé consistant ensuite à sélectionner et exécuter une action correctrice prédéfinie sur ledit au moins un paramètre dont la valeur n'est pas cohérente avec la valeur nominale définie dans le fichier de configuration, l'écriture d'une action incluant au moins un paramètre sur lequel l'action doit être exécutée, caractérisé en ce qu'elle met en ceuvre le procédé défini précédemment. L'invention sera mieux comprise à la lecture la description qui suit donnée à titre d'exemple et faite en référence aux dessins annexés. Dans les dessins: Pour simplifier la description, dans les dessins les mêmes éléments portent les mêmes références. - la figure 1 est une vue synoptique de l'architecture d'un système informatique sur lequel peut s'appliquer laprésente solution ; - la figure 2 est un algorithme illustrant différentes étapes de construction de l'objet Requête/Action ; - la figure 3 est un algorithme illustrant les différentes étapes du procédé de contrôle de cohérence conformément à l'invention - les figure 4 et 5 sont des vues respectives de fenêtres de dialogue incluant à fois les paramètres d'une requête et les paramètres de l'action correctrice spécifique à cette requête. Description d'un exemple de réalisation. Sur figure 1, on a représenté un système informatique SYS à environnement distribué de type hétérogène. Dans l'exemple illustré, ce système SYS inclut au moins un système de gestion OpenMaster SG, moins une station distante MAC, par exemple de type JAVA. De préférence, cette station JAVA est une machine Windows NT munie d'un navigateur standard dit Internet Explorer connu de l'homme du métier. Des programmes en langage JAVA nommés applets sont chargés et exécutés sur cette station. L'utilisation de ce type de station a pour avantage de fournir à l'utilisateur une interface machine bien connue. Le système comprend au moins un processeur PRO et des moyens de mémoire MEM affectés à la station de travail et au système de gestion Dans l'exemple de réalisation, le système de gestion SG supporte des services type CMIS (Common Managment Information service) normalisés conforme modèle OSI connu de l'homme du métier. Afin de masquer l'hétérogénéité du système informatique, le systeme de gestion SG comprend également au moins un intégrateur d'agent associé à un protocole de gestion respectif. Un intégrateur d'agent est un logiciel dont la fonction est, notamment, de convertir le protocole de gestion du système de gestion en un protocole de gestion associé à la machine distante. façon générale, un intégrateur d'agent du système de gestion SG est relié à agent de même type situé sur une machine quelconque (MAC, M1. M2 ou par l'intermédiaire d'un réseau RES respectif. Le réseau RES peut être un reseau LAN (Local Area Network) ou WAN (Wide Area Network) ou INTERNET. Un ensemble de couches logicielles s'interpose entre le système de gestion SG et le réseau RES, et entre le réseau RES et une machine. Cet ensemble de couches logicielle repose sur le modèle OSI (Open System Interconnection) d'architecture en couche de l'ISO (International Organization for Standard ization), connu de l'homme du métier. Pour des raisons de simplification de la description, cet ensemble de couches logicielles n'est pas représente sur la figure 1. Dans notre exemple de réalisation, les trois machines M1, M2 et M3 comprennent des ressources physiques et/ou logicielles. A titre d'exemple, on s'intéressera uniquement aux fichiers temporaires TMP1 TMP2 et TMP3 présents ces machines M1, M2 et M3, respectivement. Dans notre exemple, supposera que l'espace mémoire occupé par les fichiers temporaires TMP1, TMP2 et TMP3 est de 60Moctets, 25Moctets, et 65Moctets, respectivement. Le système de gestion SG comprend également au moins un arbre MIB1 comprenant en ses nceuds des objets constituant une representation virtuelle des ressources physiques et/ou logiques du système informatique. Cet arbre constitue une représentation qu'un utilisateur UT ou administrateur manipule (surveillance, action) pour gérer le monde reel. Dans l'exemple illustré, monde réel est matérialisé par les machines M3 et la station MAC. préférence, cet arbre se divise en au moins un domaine. Un domaine est un ensemble d'équipements ayant les mêmes caractéristiques. Par exemple, un domaine peut être associé à une liste d'équipements tels que des machines (par exemple des serveurs) UNIX ou Windows NT. Un autre domaine pourrait rassembler des ordinateurs de type PC (Personal Computer). Dans l'exemple de réalisation, dans le but de simplifier la description, l'arbre comprend un unique domaine incluant trois objets associés aux trois machines M1, M2, et M3. Dans la réalité, cet arbre contient un nombre de domaines beaucoup plus important. Rappelons qu'un objet à des propriétés comprenant valeurs et des états susceptibles d'être modifiées dans le temps suite à requêtes ou opérations sur ces objets. Les propriétés d'un objet sont notamment définies par - au moins un attribut - au moins une action que cet objet peut exécuter - comportement de cet objet suite aux sollicitations externes - moins une notification que l'objet doit émettre pour signaler des événements. Les propriété des objets de l'arbre sont stockées sein du système de gestion. Une application graphique installée sur la station cliente MAC permet à un utilisateur de visualiser ces objets. L'application graphique peut être par exemple une application cliente propre à demander au système de gestion SG l'exécution d'un contrôle de cohérence sur des valeurs d'objets, plus précisément des valeurs d'attributs. Les objets de l'arbre peuvent être interrogés à partir de la station cliente par l'intermédiaire de requêtes. Une requête peut être de différents type CMIS, SQL, un script, etc., une interface du système gestion donnant la possibilité d'interroger ces sources de données hétérogènes. Cette interface est décrite dans la demande de brevet français N 2776789 déposée au nom de la demanderesse. Dans notre exemple de réalisation, l'écriture d'une requête nécessite de définir - le type de la requête. Un type de requête peut être la surveillance de la taille de l'espace libre sur un système de fichiers (par exemple le système de fichiers de type temporaire /tmp. Un autre type de requête peut aussi être la surveillance de répertoire. - le ou les paramètres à interroger, - et au moins une variable résultat ; Rappelons qu'une variable est une donnée non fixe et qui évolue au cours du traitement des informations et de l'exécution d'un programme. Une variable,est en quelque sorte le résultat de la requête. Dans notre exemple, considérons que la requête ait pour objet l'interrogation des objets correspondants aux fichiers temporaires TMP1, TMP2 et TMP3. La requête peut consister , par exemple, à obtenir la taille de ces fichiers temporaires. Une requête permettant d'obtenir les attributs du système de fichier monté sur /tmp, par exemple pour la machine M2 peut être écrite la façon suivante -Get sourceObjectInstance = (snmpSystemID =M2 source0bjectClass= snmpsystem scope= ALL SUBTREE fi = (uxFSmountPoint= /tmp) Dans cette requête, - Le terme source0bjectlnstance est la désignation de l'objet l'arbre sur lequel porte la requête CMIS (qui est un protocole orienté objet). - Le terme source0bjectClass est le nom de la classe CMIS de l'objet désigné par sou rceObjectlnstance. En l'espèce, la classe OMIS sélectionnée est la classe snmpsystem . - Le terme Mount point désigne un chemin d'accès. Plus précisément, quand on défini un système de fichiers sur Unix dans une requête, il faut préciser le chemin d'accès de cet objet dans l'arborescence de l'arbre. Par exemple, le système de fichiers dont le chemin d'accès est /dev/Iv00 peut être ensuite "monté" où on veut dans l'arborescence des fichiers Unix. Au démarrage, on doit préciser au système d'exploitation qu'il faut le monter, par exemple, sur /usr/local. Pour l'utilisateur, seul le chemin d'accès /usr/local est un nom pariant, car c'est ce chemin d'accès qu'il utilise pour accéder aux fichiers de ce système de fichiers. L'utilisateur dispose également d'un fichier de configuration dans lequel il fixe les valeurs souhaitées pour les différents attributs de l'arbre. Ces valeurs fixées constituent les valeurs nominales (ou valeurs de référence) des attributs. Par exemple, dans ce fichier de configuration, l'utilisateur peut fixer que la taille disponible d'un fichier temporaire, dans le domaine D1, doit être supérieur à 30 Moctets. Un contrôle de cohérence peut être réalisé et consiste à comparer les valeurs réelles des tailles des différents fichiers temporaires avec leurs valeurs nominales définies dans le fichier de configuration. Dans notre cas d'espèce, comme la valeur nominale définie dans le fichier de configuration indique que la taille disponible fichier temporaire, dans le domaine D1, doit être supérieur à 30 Moctets, action correctrice doit être exécutée sur la machine M2. Une action correctrice peut être lancée. D'une manière générale, une pluralite d'actions sont disponibles dans le système de gestion. Une action peut être l'installation d'un logiciel sur une ou plusieurs machines, - la création de répertoire sur une machine distante - supprimer des répertoires, - étendre la taille de l'espace mémoire libre d'un système de fichiers, - etc. Dans notre exemple, une action correctrice est lancée de manière à réduire l'espace mémoire occupé du fichier temporaire TMP2 correspondant à la machine M2. L'écriture d'une telle action peut être la suivante extendFs mountPoint=/tmp osType="AIX" system="M2" increment=10 gros problème est que l'écriture d'une requête et l'écriture d'une action sont indépendantes l'une de l'autre. Un utilisateur donc contraint dans un premier temps d'écrire une requête et dans un second temps, une fois les résultats obtenus, à sélectionner une action correctrice parmi les actions correctrices proposées. cet effet, la solution consiste à fusionner les paramètres de la requête et les paramètres de l'action correctrice dans une même application paramétrable. La solution consiste à créer au moins un objet paramétrable RA qui rassemble la requête et l'action, plus précisément les paramètres d'une requete respective et les paramètres de l'action associée à cette requête. Dans la suite de la description, cet objet sera nommé objet Requête/Action. Pour ce faire, la solution consiste à inclure, dans l'objet Requête/Action, au moins un paramètre indéfini. Le paramètre indéfini est un paramètre sans valeur. Le paramètre défini est un paramètre fixé par défaut. En d'autres mots, la solution consiste, lors de l'écriture de l'application, à valoriser les paramètres défini (valeur par défaut) et à ne pas attribuer de valeurs aux paramètres indéfinis. Le choix des paramètres indéfinis est fonction du besoin réel de l'utilisateur final de l'application paramétrable. Dans notre exemple de réalisation, la solution consiste à afficher sur un écran d'ordinateur l'application paramétrable par l'intermédiaire d'une fenêtre de dialogue FD, cette fenêtre comprenant au moins un champs à compléter associé à un paramètre indéfini respectif, et en ce consiste, pour un utilisateur de l'application, à entrer une valeur dans ledit moins un champs de manière à valoriser ledit au moins paramètre indéfini. Un exemple de réalisation d'une telle fenêtre est donné dans la suite de la description (figures 4 et Les valeurs des paramètres indéfinis doivent être renseignés au moment de l'exécution de l'application paramétrable. Ainsi, la requête, la condition et l'action sont prédéfinis dans l'application paramétrable. Dans notre exemple, la condition à vérifier concerne la taille disponible d'un fichier temporaire, dans le domaine D1, celle-ci devant être supérieur à 30 Moctets. La création d'un objet Requête/Action est réalisée en plusieurs étapes. Eta e 1 Une première étape consiste à écrire une requête et un ensemble d'actions spécifiques susceptibles d'être exécutée pour cette requête, L'intégrateur, selon souhait de l'utilisateur final de l'application parametrable, configure l'objet Requête/Action en ce sens qu'il peut fixer des valeurs de paramètres par défaut. Etape 2 Lors d'une deuxième étape, l'intégrateur crée un objet Requête/Action propre à contenir informations nécessaires et suffisantes pour l'execution de la requête et l'action. Cet objet comprend des paramètres indéfinis (X, Y, N). objet Requête/Action inclut au moins - la requête et ses paramètres (définis et/ou indéfinis), - condition à atteindre (par exemple la taille disponible d'un fichier temporaire), - moins une action spécifique à cette requête, action incluant des paramètres définis et/ou indéfinis, - et au moins le type des paramètres indéfinis (string, Integer, etc.) à respecter lors de l'écriture de ces paramètres par l'utilisateur final. Cet objet peut être écrit de la façon suivante Requête: > m-get SourceObject = (snmpSystemId=X) > filtre (UxFSmountPoint = Y) source0bjectClass="snmpSystem" scope=ALL-SUBTREE Condition: > UxFSsize > N Action: > Extend FS > Ostype AIX > System = X > Increment = (N - $ UxFSsize) > Mount Point = Y Paramètres de la configuration auto-correctrice: > X String > Y String > N Integer Dans cet exemple, le paramètre défini est le type du système d'exploitation AIX. Les autre paramètres sont indéfinis. Dan notre exemple, X = /tmp Y=cache N=50 Moctects Etape 3 Une fois que l'utilisateur a choisi le type de la requête qu'il veut appliquer (établir une liste d'utilisateur, d'agents présents, de tailles minimums de systèmes de fichiers,...), la requête qui permet de l'obtenir ainsi que l'action correctrice qui permet de rectifier la configuration, il ne lui reste qu'à fournir un seul jeu de paramètres correspondants aux paramètres indéfinis, qui servira à la fois à l'obtention de l'état actuel de la configuration à travers la requête, et au paramétrage de l'action correctrice. La figure 3 illustre l'enchaînement des différentes phases du procédé de contrôle de cohérence. Lors d'une première étape 31, l'utilisateur sélectionne un type de requête. Dans notre exemple, l'utilisateur sélectionne le type de requête Espace libre sur un système de fichier . Avantageusement, à l'aide de pointeurs, un type de requête est associé à un objet Requête/Action. De cette façon, lorsque l'utilisateur sélectionne un type de requête, l'application identifie l'objet Requête/Action correspondant. Lors d'une étape ET 32, l'identification de l'objet Requête/Action étant effectué, la fenêtre de dialogue FD apparaît avec tous les paramètres indéfinis que l'utilisateur doit compléter dans des champs prévus à cet effet. Dans notre exemple, les paramètres indéfinis sont Pour la reguete -le nom du système de fichiers (/tmp) Pour la condition l'espace libre ( N > 50 Moctects) et pour l'action , le choix entre deux actions correctrices, à savoir - étendre le système de fichiers, - ou supprimer un sous-répertoire Les valeurs des paramètres indéfinis devant être renseignées au moment de l'exécution de l'application paramétrable, l'utilisateur complète les champs de la fenêtre de dialogue lors d'une étape ET33. A l'étape ET34, l'utilisateur lance l'application paramétrable. A l'exécution de l'application paramétrable, une série d'étapes (ET341- ET347) successives et automatiques sont exécutées par l'application paramétrable. Ainsi, la requête et l'action sont exécutées successivement l'une après l'autre. L'étape ET341 concerne l'exécution de la requête. L'exécution de la requête consiste à interroger les objets (ET342) et à récupérer la valeur des paramètres (ET343), en l'occurrence à récupérer la taille des fichiers temporaires TMP1, TMP2 et TMP3. taille des fichiers temporaires sont stockées dans une mémoire quelconque du système informatique. A l'étape ET344, l'application paramétrable réalise un contrôle de cohérence. A l'étape ET345, l'application compare la valeur réelle des objets avec la valeur nominale de ces objets et détermine si oui ou non une action correctrice doit être exécutée. Dans l'affirmative, l'application paramétrable lance (ET346) l'action correctrice sélectionnée au prealable lors de l'étape ET32. Dans la négative, il n'y a pas lieu d'exécuter action correctrice, l'étape (ET347) signifiant la fin du procédé. Comme indiqué précédemment, la taille du fichier TMP2 ne vérifie pas la condition fixée. A l'étape (ET346), l'action correctrice est donc exécutée sur cet objet. La commande increment définie dans l'écriture de l'objet Requête/Action est exécutée Increment = (N - $ UxFSsize) le mécanisme récupère la taille du fichier TMP2 ($ UxFSsize =25Moctects) stockée à l'étape (ET343), et effectue la soustraction entre la valeur fixée N dans la condition et la valeur réelle. Le résultat de ce calcul (50 Moctects - 25 Moctets) correspond à l'incrément c'est-à-dire l'augmentation minimale de taille à effectuer de façon à ce que l'espace libre sur ce fichier .temporaire TMP2 soit supérieur à 50 Moctets. L'action correctrice libère donc une taille 25 Moctets de façon à être cohérent avec la condition fixée. Ce calcul est effectué individuellement pour chaque paramètre interrogé. La figure 5 est une vue d'une fenêtre de dialogue FD. Cette fenêtre fait apparaître plusieurs paramètres associés ou non à un champs respectif à compléter par l'utilisateur final de l'application. Un champs est représenté par l'intermédiaire d'espace rectangulaire. Cette fenêtre FD comprend type de la requête et un champs incluant un menu déroulant MEN contenant liste de type de requête. De préférence, seul ce menu est visible sur la fenêtre FD. Ce n'est une fois que l'utilisateur a sélectionné un type de requête que les autres champs associés aux paramètres indéfinis apparaissent sur fenêtre. L'utilisateur sélectionne donc le type de requête Espace libre sur un système de fichier , et automatiquement, les paramètres associés à ce type de requete apparaissent à l'écran dans la fenêtre FD. Ces paramètres sont - le nom du système de fichier à interroger. Un champs a compléter est visible sur la fenêtre. Dans notre exemple le système de fichier est l'ensemble des fichiers temporaires /T"MP. - La condition à vérifier concernant l'espace libre désiré pour ce système de fichiers. Dans notre exemple, la fenêtre comprend deux champs disponibles pour ce paramètre. Un premier champ peut contenir opérateur (>, - Au moins une action correctrice. Dans notre exemple, deux actions correctrice sont proposées à l'utilisateur. Une première action propose d'étendre le système de fichiers et une deuxième action propose supprimer un sous-répertoire. L'utilisateur peut sélectionner la première ou la seconde en cochant une case prévue à cet effet sur la fenêtre. La deuxième action est associée à un champs à compléter par l'utilisateur. Dans notre exemple, l'utilisateur choisi de supprimer le sous-répertoire nommé cache . Plus précisement, cette action va supprimer le répertoire /tmp/cache . Cette action est possible car l'intégrateur a précisé que l'action correctrice supprimer un répertoire prendrait comme paramètre le nom du système de fichiers, suivi de la chaîne de caractères complété par l'utlisateur à savoir cache . figure 6 illustre une autre vue d'une fenêtre FD ayant les mêmes caractéristiques à la différence que l'intégrateur n'a prévu qu'une seule action correctrice. Comme dans l'exemple précédent, l'utilisateur complète les champs vides correspondants au système de fichier à interroger (cache), le volume d'espace libre qu'il doit contenir au minimum, et un sous-repertoire de ce système de fichier à surveiller (/tmp). On met ici en avant le sous-répertoire dont le remplissage est supposé devoir poser des problèmes d'espace dans le système de fichier, mais le fonctionnement est le même que dans le premier exemple: dès que le système de fichier ne dispose plus de suffisamment d'espace libre, l'action correctrice Supprimer un répertoire est déclenchée avec pour paramètre /tmp/cache . D'une manière générale, on peut dire que l'invention a pour objet un procède de contrôle de cohérence, dans un système informatique, entre des paramètres associés à des ressources physiques et/ou logiques système informatique et un fichier de configuration incluant les valeurs nominales de ces paramètres, le procédé consistant à interroger ces paramètres par l'intermédiaire d'au moins une requête, l'écriture d'une requête incluant au moins paramètre à interroger et au moins une variable donnant la valeur courante des paramètres, ledit procédé consistant ensuite à sélectionner et exécuter une action correctrice prédéfinie sur ledit au moins un paramètre dont la valeur n'est pas cohérente avec la valeur nominale définie dans le fichier de configuration, l'écriture d'une action incluant au moins un paramètre sur lequel l'action doit être exécutée, caractérisé en ce qu'il consiste à créer moins un objet Requête/Action dit de configuration autorégulatrice incluant chacun - un type de requête (par exemple, l'espace libre... ) et les paramètres associés - et moins une action spécifique à ce type de requête et paramètres associés, tout ou partie des paramètres de l'objet étant indéfinis et devant être renseignés avant exécution de l'application correspondante. On a vu dans l'exemple de réalisation que le procédé consiste, lors de la phase de construction de l'objet Requête/Action, à fixer des valeurs par défaut à certains paramètres (paramètres définis) et à ne pas attribuer de valeurs aux paramètres indéfinis. Après avoir construit l'objet Requête/Action, au moment de l'exécution de l'application correspondante, on a vu que la solution consiste à valoriser les paramètres indefinis, et en ce que les paramètres de l'action correctrice peuvent s'exprimer comme une expression algébrique faisant intervenir paramètres indéfinis et/ou les paramètres associés à des ressources physiques ou logiques, obtenus comme résultat de la requête. De préférence, la solution consiste à afficher sur un écran d'ordinateur l'application paramétrable par l'intermédiaire d'une fenêtre de dialogue cette fenêtre comprenant au moins un champs à compléter associé à paramètre indéfini respectif, et en ce qu'il consiste, pour un utilisateur l'application, à entrer une valeur dans ledit au moins un champs de manière valoriser ledit moins paramètre indéfini. Dans notre exemple, cette fenêtre de dialogue FD propose au moins un type de requête, en ce qu'il consiste ensuite à sélectionner un type de requête dans un menu MEN, et en ce que l'application construit dynamiquement les paramètres à compléter associés à ce type de requête et les actions possibles à sélectionner. Ainsi, avant exécution de l'application et après avoir sélectionné un type de requête, l'utilisateur peut remplir les champs inclus dans la fenêtre et peut sélectionner l'action correctrice souhaitée. L'invention consistant à crée un unique objet Requête/Action, lors de l'exécution de l'application, la requête et l'action correctrice sélectionnée peuvent s'exécuter l'une après l'autre dynamiquement et de façon transparente. Tout ou partie des paramètres indéfinis peuvent être d'un type différent. A cet effet, il est possible d'inclure dans l'objet Requête/Action dit de configuration autorégulatrice le type des paramètres indéfinis (string, integer, etc.). Ainsi, lorsque l'utilisateur complète les champs des paramètres indéfinis dans la fenêtre de dialogue FD, le système peut émettre un message d'erreur de façon à signaler à l'utilisateur, exemple qu'il n'a pas respecter le type du paramètre défini dans l'objet Requete/Action. Avantageusement, la création d'un objet Requête/Action unique incluant des paramètres indéfinis donne la possibilité d'interroger plusieurs paramètres à la fois et de lancer une action correctrice l'ensemble de ces objets, si cela est nécessaire, dynamiquement et de façon transparente pour l'utilisateur. A cet effet, l'application paramétrable comprend un module logiciel propre à déterminer pour chaque paramètre la correction adaptée au vu des valeurs nominales fixées pour chaque paramètre dans le fichier de configuration. Par exemple, si l'action correctrice concerne l'extension de l'espace libre dans une ressource de type fichier temporaire , le module logiciel est apte à soustraire, pour chaque paramètre interrogé et nécessitant une action correctrice, la valeur nominale du paramètre correspondant de la valeur réelle issue de la requête, et, une fois le résultat de la soustraction obtenu, de procéder à l'exécution de l'action correctrice consistant à augmenter la taille de l'espace libre d'une taille égale au résultat soustraction. II résulte aussi de ce qui précède solution a aussi pour objet une Fenêtre de. dialogue FD pour le controle cohérence, dans un système informatique, entre des paramètres associés des ressources physiques et/ou logiques du système informatique et un fichier de configuration incluant les valeurs nominales de ces paramètres, procédé consistant à interroger ces paramètres par l'intermédiaire d'au moins requête, l'écriture d'une requête incluant au moins un paramètre à interroger et au moins une variable donnant la valeur courante des paramètres, ledit procédé consistant ensuite à sélectionner et exécuter une action correctrice prédéfinie sur ledit au moins un paramètre dont la valeur n'est pas cohérente avec la valeur nominale définie dans le fichier de configuration, l'écriture d'une action incluant au moins un paramètre sur lequel l'action doit être exécutée, caractérisé en ce qu'elle met en ouvre le procédé défini précédemment. II ressort aussi de la description que l'invention offre nombreux avantages. L'utilisateur final en phase d'exploitation n'a plus besoin savoir quels sont les mecanismes de requêtes et de transmission des paramètres aux actions correctrices sous-jacentes. Ce travail est fait dans une étape antérieure, déjà livré avec le produit. Pour , seule la configuration finale à obtenir est pertinente. A noter que les objets Requête/Action sont prédéfinis dans l'application paramétrable, ou peuvent être écris par un intégrateur dans phase de configuration la solution client. REVENDICATIONS 1- Procédé de contrôle de cohérence, dans un système informatique constitué réseau (RES), entre des paramètres associés à ressources physiques et/ou logiques du système informatique et un fichier configuration incluant valeurs nominales de ces paramètres, le procède consistant à interroger ces paramètres via le réseau (RES) par l'intermédiaire d'au moins une requete, l'écriture d'une requête incluant au moins un paramètre à interroger au moins une variable donnant la valeur courante paramètres, ledit procédé consistant ensuite à sélectionner et exécuter, via le reseau (RES), une action correctrice prédéfinie sur ledit au moins un paramètre dont la valeur n'est pas cohérente avec la valeur nominale définie dans fichier de configuration, l'écriture d'une action incluant au moins un paramètre sur lequel l'action doit être exécutée, caractérisé en ce qu'il consiste a créer et à mémoriser dans une mémoire du système informatique au moins un objet Requête/Action dit de configuration autorégulatrice incluant chacun - un type de requête et les paramètres associés, - et au moins une action spécifique à ce type de requête et paramètres associés, tout ou partie des paramètres de l'objet étant indéfinis devant être renseignés avant exécution de l'application correspondante. 2- Procedé selon la revendication 1, caractérisé en ce consiste, lors de la phase construction de l'objet Requête/Action, à fixer valeurs par défaut à certains paramètres (paramètres définis) et à ne attribuer de valeurs aux paramètres indéfinis. 3- Procédé selon la revendication 1 ou 2, caractérisé en ce qu'il consiste, à l'exécution de l'application correspondante, à valoriser les paramètres indéfinis, et en ce que les paramètres de l'action correctrice peuvent s'exprimer comme une expression algébrique faisant intervenir les paramètres indéfinis et/ou les paramètres associés à des ressources physiques ou logiques, obtenus comme résultat de la requête. 4- Procédé selon la revendication 1 ou 2, caractérisé en qu'il consiste à afficher sur un écran d'ordinateur l'application paramétrable par l'intermédiaire d'une fenêtre de dialogue (FD), cette fenêtre comprenant au moins un champs à compléter associé à un paramètre indéfini respectif, et en ce consiste, pour un utilisateur de l'application, à entrer une valeur dans ledit moins un champs de manière à valoriser ledit au moins paramètre indéfini. 5- Procédé selon l'une des revendications 1 à 4, caractérise en ce que la fenêtre de dialogue (FD) propose au moins un type de requête, en ce qu'il consiste ensuite à sélectionner un type de requête dans un menu (MEN), et en ce que l'application construit dynamiquement les paramètres à compléter associés ce type de requête et les actions possibles à sélectionner. 6- Procédé selon l'une des revendications 1 à 5, caractérisé en ce qu'il consiste, avant exécution de l'application et après avoir sélectionne un type de requête, remplir les champs inclus dans la fenêtre (FD) et à sélectionner l'action correctrice souhaitée. 7- Procédé selon l'une des revendications 1 à 6, caractérise ce que, lors de l'exécution de l'application, la requête et l'action correctrice sélectionnée s'exécute l'une après l'autre de façon transparente. 8- Procédé selon l'une des revendications 1 à 7, caractérise en qu'il consiste a inclure dans l'objet dit de configuration autorégulatrice le type des paramètres indéfinis (string, integer, etc.). 9- Procédé selon l'une des revendications 1 à 8, caractérisé en ce que la détermination de la correction est réalisée par l'intermédiaire d'un module logiciel propre à déterminer pour chaque paramètre la correction adaptée au vu des valeurs nominales fixées pour chaque paramètre dans le fichier de configuration. 10- Procédé selon l'une des revendications 1 à 9, caracterisé en ce que, si l'action correctrice concerne l'extension de l'espace libre dans une ressource de type fichier temporaire , le module logiciel est apte à soustraire, pour chaque paramètre interrogé et nécessitant une action correctrice, la valeur nominale du paramètre correspondant de la valeur réelle issue de la requête, et, une fois le résultat de la soustraction obtenu, de procéder l'exécution de l'action correctrice consistant à augmenter la taille de l'espace libre d'une taille égale au résultat de la soustraction. 11- Fenêtre de dialogue (FD) pour le contrôle de coherence, dans un système informatique constitué d'un réseau (RES), entre paramètres associés à des ressources physiques et/ou logiques du système informatique et un fichier de configuration incluant les valeurs nominales de ces paramètres, le procédé consistant à interroger ces paramètres via le réseau (RES) par l'intermédiaire d'au moins une requête, l'écriture d'une requête incluant au moins un paramètre à interroger et au moins une variable donnant la valeur courante des paramètres, ledit procédé consistant ensuite à sélectionner et exécuter, via le réseau (RES), une action correctrice prédéfinie sur ledit au moins un paramètre dont la valeur n'est pas cohérente avec la valeur nominale définie dans le fichier de configuration, l'écriture d'une action incluant au moins un paramètre sur lequel l'action doit être exécutée, caractérisée en ce qu'elle comprend au moins un champs à compléter associé à un paramètre indéfini respectif pour la mise en #uvre du procédé défini dans l'une des revendications 1 à 10.