Brevet FR2803060A1 — publié le 20010629

Titre Procédé de distribution d'une action dans un système informatique. Description. Domaine technique. L'invention se rapporte à un procédé de distribution d'une action dans un système informatique. L'action peut être une consultation d'état ou un changement d'état dans tout ou partie du système informatique. L'action qui sera prise comme exemple dans la suite du texte est un changement d'état par une installation de logiciel dans tout ou partie des machines constituant le système informatique. Le procédé relatif à cette action est couramment appelé procédé de distribution de logiciel. Le logiciel peut être fait d'un ou plusieurs modules dépendants ou non. Tout ou partie des modules peuvent aussi être versions complètes ou des mises à jour de versions antérieures. L'action en tant que changement d'état peut aussi être par exemple une modification de configuration de tout ou partie des machines du système informatique, l'ajout à un routeur d'une route sur ces machines ou la création d'un utilisateur pour ces machines. L'action en tant que consultation d'état peut être par exemple une consultation des utilisateurs ou des fichiers de système de tout ou partie d'un système informatique, ou faire un inventaire du logiciel installé dans tout ou partie des machines du système informatique. L'invention s'applique notamment dans un système informatique très dense et hétérogène, fait de nombreuses machines diverses fonctionnant avec des systèmes d'exploitation variés et portant des applications outils variés. Le procédé peut s'appliquer seul ou comme partie d'un logiciel d'administration du système informatique. L'exemple qui servira d'illustration du procédé de distribution est un procédé incorporé dans un système d'administration nommé OpenMaster du demandeur. L'invention a donc aussi pour objets corollaires le système informatique et optionnellement le système d'administration qui mettent en oeuvre le procédé de distribution. L'art antérieur. La distribution de logiciel consiste à installer un même logiciel sur un ensemble de machines cibles à partir d'une machine gestionnaire système informatique. Le logiciel à installer et ses procédures d'installation sont stockés sous forme d'une archive sur la machine gestionnaire formant serveur nommé serveur de dépôt. L'installation du logiciel sur chaque machine cible comprend les étapes de : rapatrier l'archive ; extraire de l'archive les fichiers constituant le logiciel et les procédures d'installation ; et exécuter procédures d'installation permettant de mettre à jour les fichiers de configuration et les fichiers de système, à partir de paramètres d'installation choisis par l'utilisateur. Un problème de la distribution de logiciel est de suivre une installation de logiciel sur un ensemble de machines cibles, indépendamment de l'état cibles. Il faut en particulier: suivre pour chacune des cibles la fin de l'installation du logiciel ; pouvoir, si un défaut d'installation se présente sur une cible, diagnostiquer l'opération qui a échoué et la cause de l'échec, afin de pouvoir relancer la commande d'installation ; et connaître l'ensemble des opérations effectuées sur une cible afin de pouvoir remonter dans la chaîne opérations et reprendre une installation à l'état où le défaut s'est présenté ou à un état antérieur. Plus précisément, le problème technique de l'art antérieur est de suivre de manière détaillée et fiable l'ensemble des opérations effectuées sur chaque machine cible lors d'une distribution de logiciel. Une solution à ce problème permettrait donc d'analyser le suivi de la distribution du logiciel dans les machines cibles et diagnostiquer les éventuels défauts d'installation. D'un tel diagnostic, il serait alors possible de reprendre une installation défaillante et d'assurer une installation complète et correcte. De nombreuses solutions pour le suivi de l'exécution d'une installation de logiciel existent actuellement sans pouvoir fournir un tel suivi. Une première solution, actuellement mise en oeuvre dans le produit d'administration "OpenMaster " du demandeur fait un suivi, au moyen d'un protocole propriétaire client-serveur, de l'avancement de l'installation. Le succès et l'avancement des opérations sont traités une application de distribution de logiciel de ce produit pour être visibles à l'utilisateur administrateur chargé de la surveillance de l'installation. Cependant, le résultat d'une installation n'est pas dans un format échangeable avec les autres applications disponibles dans la machine gestionnaire du système d'administration. De plus, la machine gestionnaire utilise un protocole client-serveur qui nécessite une communication entre le client et le serveur tout au long de l'échange. Le suivi du déroulement de l'installation est donc impossible si la liaison entre une machine cible la machine gestionnaire est rompue pendant le déroulement de l'installation. Une seconde solution consiste à faire un inventaire des machines cibles pour obtenir des informations sur les logiciels installés. Cependant, cette solution ne fournit ni l'historique des commandes de l'installation ni un diagnostic en cas d'échec ou de défaut d'une installation. Une troisième solution utilise un journal (log) d'installation sur chacune des machines cibles. Cette solution a l'inconvénient de nécessiter une connexion avec chacune des machines cibles et de savoir retrouver le journal d'installation, ou la trace de l'installation, dans un fichier du journal. Cet inconvénient ne peut être évité, car aucune centralisation des données relatives à l'installation n'est possible dans ce cas. Selon une quatrième solution, des notifications de la fin d'une installation sont émises au moyen d'alarmes. Cette solution présente l'inconvénient de retrouver ces alarmes parmi les nombreuses alarmes centralisées dans la machine gestionnaire. En outre, après avoir retrouvé une alarme, la description du défaut ou de l'échec y est très sommaire comme dans toute autre alarme. Une cinquième solution utilise un mécanisme d'exécution éloignée, appelé aussi remote exécution ("rexec") ou agent d'action, afin d'invoquer sur chacune des machines cibles une commande d'installation de logiciel et d'en récupérer une sortie normalisée ou le code de retour. Cette solution souffre de devoir disposer à la fois d'une commande d'installation donnant suffisamment de détails sur les opérations effectuées et d'un automate spécifique sur la machine gestionnaire. Cet automate doit être capable, d'une part, de soumettre ordres à un ensemble de machines cibles tout en tenant compte de la possibilité qu'une ou plusieurs d'entre elles peuvent ne pas être jointes au moment de la soumission de la commande d'installation et, d'autre part, suivre l'état de chaque machine cible à partir de sorties du programme d'installation. Toutes ces solutions mettent en relief la difficulté de faire un suivi complet et fiable des opérations requises pour être assuré d'une installation correcte d'un logiciel sur un ensemble de machines cibles. Cet exemple illustre bien les difficultés rencontrées d'une manière plus générale lors de la distribution d'une action dans un système informatique. Le suivi de l'action est fait de manière similaire à celle d'une distribution de logiciel et pose à des degrés divers les mêmes problèmes. Sommaire de l'invention. Un premier but de l'invention est de permettre à un procédé de distribution d'une action dans système informatique de faire dans une machine gestionnaire un suivi détaillé et fiable de l'action distribuée dans les machines cibles, indépendamment de leur état. Un second but est pourvoir faire une analyse fine du suivi pour diagnostiquer où et, si possible, quand et pourquoi les échecs et/ou défauts de la distribution de l'action se sont produits. Un troisième but est pouvoir faire, à partir de l'analyse du suivi de la distribution, une correction de la distribution au moyen d'une reprise partielle du procédé de distribution d'une action correctrice, afin d'assurer une distribution finale correcte de l'action désirée. Un quatrième but est d'atteindre les buts précédents en utilisant des moyens simples et peu coûteux a mettre en oeuvre. L'invention a pour objet un procédé de distribution, à l'aide d'au moins un processeur, d'une action dans des machines cibles à partir d'une machine gestionnaire d'un système informatique incluant des moyens de mémoire, comprenant : dans la machine gestionnaire, la description d'une commande de distribution dans un fichier de commande contenu dans les moyens de mémoire ; l'exécution de l'action dans chacune des machines cibles à partir du fichier de commande ; la génération, dans les moyens mémoire de chaque machine cible, d'un compte rendu d'exécution de l'action dans la machine cible correspondante ; et le suivi, dans la machine gestionnaire, de la distribution de l'action à partir des comptes rendus. L'invention a pour objet corollaire un système informatique incluant au moins un processeur et des moyens de mémoire répartis dans une machine gestionnaire et des machines cibles d'une distribution d'une action à partir de la machine gestionnaire, caractérisé en ce que les moyens de mémoire comprennent des moyens pour la mise en oeuvre du procédé défini précédemment. L'invention peut aussi avoir pour objet corollaire système d'administration comprenant au moins un processeur et des moyens de mémoire (15) répartis dans un gestionnaire inclus dans une machine gestionnaire et pourvu d'une application permettant la distribution d'une action, et dans des interfaces incluses dans des machines cibles dans lesquelles l'action doit être distribuée, caractérisé en ce que la distribution est faite à l'aide d'au moins ledit processeur selon le procédé défini précédemment. Présentation des dessins. # La figure 1 est une vue synoptique d'un système d'administration d'un système informatique incorporant une machine gestionnaire incorporant une application pour distribuer un logiciel dans un ensemble de machines cibles selon un procédé conforme à l'invention. # La figure 2 est un organigramme illustrant un exemple d'enchaînement d'étapes pour la mise en oeuvre du procédé de distribution représenté sur la figure 1. # La figure 3 est une vue schématique d'un exemple de structure d'un fichier de commande de distribution mis en oeuvre initialement dans le procédé de distribution représenté sur les figures 1 et 2. # La figure 4 est une vue schématique illustrant un exemple d'évolution de la structure du fichier de commande représenté sur la figure 3 durant le déroulement du procédé de distribution représenté par l'organigramme de la figure 2. # La figure 5 est un algorithme illustrant un exemple de suivi mis en oeuvre dans l'exemple de procédé de distribution tel que représenté sur la figure 2. # Et la figure 6 est un algorithme illustrant un exemple de reprise de distribution de l'action désirée pour corriger toute action mise en échec diagnostiquée à partir du suivi effectué selon le procédé de l'invention. Description détaillée d'exemples illustrant l'invention. La figure 1 représente un exemple de structure de distribution 10 incluse dans un système d'administration d'un système informatique 11. L'exemple qui va maintenant être illustré est celui qui a été conçu pour être incorporé dans le produit logiciel d'administration et sécurité OpenMaster du demandeur. Le procédé de distribution de logiciel y sera contenu dans un composant nommé "Network Software Distribution". La conception du produit est conforme aux normes ISO de l'administration de systèmes et réseaux. Dans ces conditions, les termes utilisés seront conformes à cette norme, qui sont de langue anglaise, notamment les sigles et acronymes. D'autre part, les verbes "administrer" et "gérer" et leurs dérivés qui seront employés ici traduisent tous deux indifféremment le verbe anglais "manage" et ses dérivés. L'homme du métier connaît bien ces normes. Compte tenu de leur masse informative, on ne donnera ici que les éléments nécessaires à la compréhension de l'invention. Le système informatique illustré 11 est distribué et se compose d'un nombre m de machines 12 (12a, 12b, ..., 12i, ..., 12m) organisées en un ou plusieurs réseaux 13. Pour la simplification des dessins, seules les machines 12a, 12b et 121 sont illustrées dans la figure 1. Le réseau 13 peut être un réseau de la Toile (réseau internet) et/ou un réseau autre que la Toile, tel que celui utilisant le protocole SNMP (System Network Management Protocol). machine est une unité conceptuelle très large, de nature matérielle et logicielle, pouvant être les moyens impliqués pour exécuter une application donnée, des moyens pour exécuter une fonction donnée, un ordinateur, ainsi système informatique dans une architecture à systèmes en cascade. Les machines 12 peuvent être donc très diverses, telles que stations de travail serveurs, routeurs, machines spécialisées et passerelles entre réseaux. Le système informatique 11 est ordinairement un système comprenant plusieurs processeurs 14, un processeur 14 étant par exemple illustré dans chaque machine 12, des moyens de mémoire 15 pour contenir logiciels et les données du système, et des moyens d'entrée-sortie 16 servant pour la communication entre machines par l'intermédiaire du réseau à l'aide de protocoles divers, ainsi que pour une ou plusieurs communications extérieures, par exemple pour l'impression, la télécopie, etc. Un tel système peut par exemple gérer des données à distance, distribuer des données dans cas d'un système de réservation, commander l'exécution de programmes à distance sur des machines spécialisées, partager localement des ressources physiques ou logicielles, et communiquer. Plus généralement, le système 11 se compose de ressources matérielles et/ou logicielles, réelles ou virtuelles telles que machines, imprimantes, circuits virtuels, réseaux et applications. Le système d'administration 10 utilise au moins l'une de ces ressources selon technologie orientée objets, bien connue de l'homme du métier. Le système d'administration choisi pour inclure la structure distribution 10 a une architecture de type client-serveur. La partie serveur gestionnaire et la partie cliente comprend la ou les ressources à gérer. Dans l'exemple illustré pour des raisons de simplification, la partie serveur comprend un seul gestionnaire 17 inclus dans la machine 12a, dite machine gestionnaire, tandis que la partie cliente inclut des interfaces 18b- donnant l'accès aux ressources à gérer incluses dans les machines respectives 12b-12m, dites machines cibles de l'action à distribuer. Selon une option courante et avantageuse du système d'administration 10, un gestionnaire 17 gère aussi la machine gestionnaire 12a correspondante ou gère tout ou partie des machines gestionnaires. Cela peut se faire de façon similaire à celle illustrée, plus moins adaptée à cette option. L'exemple illustré offre le double avantage de faciliter la lecture des dessins tout en permettant à l'homme du métier de faire une généralisation du système décrit et illustré. figure 1 illustre un exemple de structure de distribution 10 pour la mise en oeuvre du procédé de distribution 40 représenté sous forme d'un organigramme sur la figure 2. Pour la simplification des dessins, la structure de distribution 10 illustrée se confond avec celle du système d'administration à laquelle elle est en pratique incorporée. Dans la figure 1, le gestionnaire inclut une application 19 de distribution d'une action dans le système informatique 11. L'action choisie à titre d'exemple est une installation de logiciel. L'application 19 est de préférence connectée à une station graphique 20 permettant à un utilisateur de commander la distribution et d'avoir des données sur le déroulement de la distribution. L'application est connectée à une interface 21 de programmation d'applications dite couramment interface API (Application Programming Interface). L'interface API 21 illustrée a une fonction commande et de supervision de la distribution dans le système informatique 10. La fonction de commande de l'interface API 21 est exercée par la génération, lors d'une étape 41 du procédé de distribution 40 de la figure 2, d'une commande de distribution 22. Lors d'une étape 42, la commande de distribution 22 est matérialisée en un fichier de commande 23. La figure 3 illustre un exemple de structure initiale d'un fichier de commande 23. Cet exemple a été choisi à cause de sa structure organisée. La structure inclut d'une part une liste 52 des machines cibles 12b-12m décrites dans des documents 53. Dans l'exemple considéré, les machines cibles 12b-12m sont décrites dans des documents respectifs 53b-53m. Pour la clarté des dessins, les éléments constitutifs de toute liste sont seulement représentés par le premier élément de la liste et l'élément d'ordre i ou j. En variante, plusieurs machines cibles ayant des caractéristiques communes pour l'action désirée pourraient être décrites dans un seul document 53. Chaque document illustré 53 est complété par une annexe 54 indiquant l'état de la machine cible 121 ou de chaque machine cible relative à un document commun. Dans le fichier de commande 23 illustré, l'état initial indique si une installation du logiciel dans la machine cible 121 a déjà été effectuée. Pour des raisons de simplification, on considérera que le procédé de distribution 40 s'applique à toutes les machines cibles 12a-12m. Le fichier de commande 23 initial inclut d'autre part une liste 55 des opérations OPa-OPn à exécuter dans l'ensemble des machines cibles 12b-12m pour l'installation logiciel. Les opérations sont aussi décrites dans des documents 56. Dans l'exemple considéré, chaque opération OPj (avec j = {a;nJ) est décrite dans document respectif 56j. Cependant, tout document pourrait contenir plusieurs opérations. Aux documents 56j sont attachés des annexes respectives 57j indiquant des paramètres relatifs aux opérations décrites dans documents respectifs. La fabrication du fichier de commande 23 lors de l'étape 42 du procédé 40 correspond à une description de la commande de distribution 22. La description est faite accessoirement mais avantageusement dans un langage adapté à l'échange de documents d'administration à travers la Toile. Dans l'exemple choisi, le langage de description est le langage normalisé XML (eXtended Management Language). Le langage XML se compose de chapitres délimités par des marqueurs (tags) et pouvant se diviser en sous-chapitres. Les chapitres peuvent contenir du texte et/ou des données identifiées par une syntaxe du type "attribut = valeur". Le langage XML offre aussi l'avantage de décrire simplement des structures imbriquées et est ainsi particulièrement adapté à la description d'une commande de distribution 22 en un fichier de commande de distribution 23 tel qu'illustré dans la figure 3. Les fichiers au format XML dans le système informatique 11 peuvent être transportés par le protocole FTP (File Transport Protocol) du réseau 13. Cependant, d'autres protocoles sont possibles. Notamment, il serait possible d'utiliser le protocole HTTP (HyperText Transfer Protocol) par l'intermédiaire d'un serveur de la Toile. L'annexe A illustre un exemple de fichier de commande 23 décrit en XML. Étant donné la complexité et la longueur d'un vrai fichier de commande de distribution de logiciel, le fichier de commande 23 de l'annexe A a ' choisi pour avoir une forme simple et suffisante pour l'illustration. L'action correspondant au fichier de commande 23 de l'annexe A est une consultation pour faire l'inventaire du logiciel installé dans une liste de machines comprenant en l'occurrence deux machines nommées "clog005" et "clog006". Le fichier de commande 23 de l'annexe A a été généré par une commande de distribution 21 nommée "rlist", faite d'une seule opération élémentaire, à savoir une opération de visualisation. L'annexe A et celles qui s' rattachent offrent l'avantage de décrire une variante du procédé de distribution et d'indiquer à l'homme du métier la généralité d'application du procédé de distribution à d'autres actions que celles décrites. En référence à la figure 2, le procédé de distribution 40 continue une étape 43 de recherche, dans le fichier de commande 23, de chaque machine cible 12i. L'étape se boucle par une incrémentation faite lors d'une étape 44 pour rechercher la machine cible suivante 12i+1 et permet pour la machine cible 12i de fabriquer un fichier d'ordre 24i lors d'une étape 45. La consultation du fichier de commande 23 lors de l'étape 43 permet de sélectionner parmi les opérations OPa-OPn disponibles dans la liste 55 les opérations OPa-OPk prévues pour l'installation du logiciel dans la machine cible 12i. Les opérations OPa-OPk sont incluses dans le fichier d'ordre 24i. Les fichiers d'ordre 24 dans l'exemple choisi sont fabriqués sous la commande de l'interface API 21. La figure 4 illustre un exemple de structure finale du fichier de commande 23 et indique sous forme synoptique que les fichiers d'ordre 24i (24b-24m) sont contenus dans le fichier de commande 23. Ils pourraient bien être séparés du fichier de commande. L'annexe B présente exemple des deux fichiers d'ordre 24 extraits du fichier de commande l'annexe A et relatifs aux deux machines cibles "clog005" et "clog006". Cet exemple fait bien ressortir qu'un fichier d'ordre peut être commun à plusieurs machines cibles. conséquent, d'une manière générale, un fichier de commande 23 de distribution de logiciel génère des fichiers d'ordre 24 pour la distribution d'une action sur les machines cibles 12. Le procédé de distribution 40 de la figure 2 se poursuit par une étape 46 relative à l'exécution de l'action désirée, à savoir une installation de logiciel, dans les machines cibles. Cette étape commence par la transmission des fichiers d'ordre 24 aux machines cibles respectives 12b-12m. La transmission illustrée se fait par l'application des fichiers d'ordre 24 à un premier démon 25, en pratique appelé démon "send çmd" dans le composant du demandeur. Le démon 25 est dédié à l'envoi des fichiers d'ordre 24 et permet l'accès aux machines cibles respectives 12b-12m. La figure 1 illustre un exemple de structure d'une machine cible 12b pour la mise en ceuvre du procédé de distribution 40. Une telle structure est contenue aussi dans les autres machines cibles 121. Dans la machine cible 12b, lors de l'étape 46 du procédé de distribution, un premier répertoire 26b servant de boîte aux lettres de réception et appelé simplement répertoire de réception reçoit le fichier d'ordre 24b envoyé par le démon 25 et le transmet à un second démon 27b nommé "exec çmd" et commandé à partir de l'interface API 21 de la machine gestionnaire 12a pour exécuter le fichier d'ordre 24b. L'exécution du fichier d'ordre 24b se fait en utilisant des moyens 28b lors de l'étape 46. Dans cette étape, les opérations OPa-OPk du fichier d'ordre 24b sont commandées pour l'installation du logiciel dans la machine cible 12b par les moyens 28b. Dans une étape 47 du procédé, un compte rendu d'exécution 29b est construit et envoyé à la machine gestionnaire 12a. Le compte rendu 29b est construit sous la commande du démon d'exécution 24b. L'envoi du compte rendu est fait au moyen d'un troisième démon 30b, nommé "send res et piloté par l'interface API 21. Le compte rendu 29b traverse la Toile 13 sous forme de document. Un compte rendu 29 indique par exemple si l'installation n'a pas encore été faite, si elle a été réussie ou si elle a échoué. L'annexe présente un exemple de compte rendu 29 de la machine "clog006" en réponse à l'installation faite selon l'annexe B. Selon ce compte rendu, l'installation réussi. Il est supposé qu'il en est de même pour le compte rendu de l'autre machine. Dans la machine gestionnaire 12a, le compte rendu 29i de chaque machine cible 12i est reçu par un second répertoire de réception 31 qui le transmet à un quatrième démon 32 nommé "monitor çmd" et servant au suivi de la distribution de l'action dans le système informatique 11. Le démon de suivi est aussi commandé par l'interface API 21. Dans une étape 48 du procédé, le démon de suivi 32 analyse les comptes rendus 29 (29a-29m) et, dans une étape 49, il fait le suivi de la distribution par enregistrement des comptes rendus analysés. L'étape d'analyse est facultative. En pratique, elle peut simplement inclure un filtrage pour éliminer des parties inutiles ou un algorithme d'analyse évolué. L'étape de suivi 49 de l'exemple illustré fait par enrichissement du ficher de commande 23. L'enrichissement dans le fichier de commande 23 illustré dans la figure 4 est fait de documents 58i rattachés aux fichiers d'ordre respectifs 241. L'annexe D présente un exemple d'enrichissement fait dans le fichier de commande de l'annexe A en réponse aux comptes rendus issus des deux machines cibles. Dans l'exemple de l'annexe D aucune analyse a été faite et l'enrichissement correspond donc à simple copie du compte rendu dans le fichier de commande. La figure 1 illustre aussi par un trait discontinu une variante de mise en oeuvre de l'étape de suivi 49. Selon cette variante, le suivi est fait par enregistrement des comptes rendus analysés ou non dans un fichier suivi Le fichier de suivi 23' peut être connecté ou non au fichier de commande La figure 5 illustre un exemple d'algorithme 60 de suivi de la distribution par enrichissement du fichier de commande 23 correspondant étapes 48 et 49 du procédé de distribution 40. L'algorithme 60 est exécuté par le démon de suivi 32. On considère que le suivi effectué selon l'algorithme 60 commence à une étape 61 par une arrivée d'un compte rendu Un compte rendu 29i peut correspondre au résultat d'une opération de commande OPj sur la cible 12i ou au résultat de l'exécution du fichier d'ordre 241 dans la cible 12i, ou encore à une notification d'erreur. Le démon 32 recherche le fichier de commande 23 dans une étape 62 et ouvre ce fichier à une étape 63. À une étape 64, le démon 32 vérifie si le résultat est simplement issu d'une opération ou si c'est le résultat global de commande d'installation du logiciel sur une machine cible. Un résultat d'une opération OPj est amené à une étape 65. Le démon 32 procède alors, à étape 66, à une analyse du résultat de l'opération OPj. L'analyse illustrée et qui a été faite en pratique est simple. Cependant, l'homme du métier capable de la perfectionner au moyen d'une sémantique élaborée. Selon l'analyse illustrée, à une étape 67 le démon 32 recherche l'opération OPj dans la liste 55 des opérations OPa-OPn du fichier de commande de distribution 23. cas de succès, à une étape 68 il recherche dans la liste 52 la machine cible 12i concernée. En cas de succès, à une étape 69 il recherche alors dans le fichier de commande 23 le chapitre correspondant au résultat de l'opération OPj. Si ce chapitre existe, il correspond à un résultat déjà obtenu sur l'opération. À une étape 70 le démon 32 enrichit le fichier de commande en y remplaçant le chapitre relatif au résultat de l'opération OPj par le résultat vient d'être analysé. S'il ne trouve pas le chapitre concerné, le résultat analysé lors des étapes 66-68 correspond à la première exécution de l'opération OPj sur la cible 12i. Alors, à une étape 71 le démon enrichit le fichier commande en insérant dans le chapitre recherché le résultat analysé. La création ou le remplacement du chapitre correspond à la création ou au remplacement du document 58i correspondant du fichier de commande. Les étapes 70 et 71 sont donc incluses dans l'étape 49 du procédé de distribution 40. A une étape 72 de l'algorithme, le démon 32 vérifie si toutes les opérations OPa-OPk exécutées sur la cible 12i ont un résultat. Si oui, à une étape 73 il calcule le résultat global et met à jour l'état de la cible dans le document 541 du fichier de commande 23 et l'écrit dans ce fichier lors d'une étape 74. étapes 72, 73 et 74 sont aussi incluses dans l'étape 49 du procédé de distribution 40. Sinon, à une étape 75 le démon 32 revient à l'étape 65 pouf attendre un nouveau résultat d'opération à analyser. On considère maintenant qu'à l'étape 64 le compte rendu 29i obtenu de la machine cible 12i est le résultat de la commande de l'action d'installation sur la machine cible 12i. Ce compte rendu concerne donc l'ensemble des opérations OPa-OPk qui ont été effectuées sur la machine cible lors de l'exécution du fichier d'ordre 24i et forme donc un compte rendu de fin d'installation du logiciel dans la machine cible. Le compte rendu 291 alors placé à une étape 76 et le démon 32 procède alors à l'analyse du résultat lors d'une étape 77. Pour cela, lors d'une étape 78 il recherche la machine cible 121 concernée dans la liste 52 du fichier de commande 23. En cas de succes, lors d'une étape 79 il procède à la mise à jour de l'état de la machine cible 121 dans le document 541 du fichier de commande 23. Pour cela, le démon 32 recherche chaque opération OPj en une étape 80 et recherche en une étape 81 le chapitre relatif au résultat de cette opération, de façon similaire à l'étape 69. Dans une étape 82, le démon 32 enrichit le fichier de commande 23 de façon similaire aux étapes 70 et 71. Un bouclage entre les étapes 80 et 82 permet d'épuiser les opérations OPa-OPk. Le résultat global est écrit dans le document 541 du fichier de commande 23 dans une étape 83 correspondant en partie à l'étape 73, et le fichier de commande enrichi est sauvegardé lors d'une étape correspondant à l'étape 74. Les étapes 65-83 étant épuisées, l'algorithme prend fin. L'utilisation d'un fichier de commande 23 permet ainsi le suivi complet des opérations puisque l'on peut, à partir de ce seul fichier, connaître l'état d'avancement de l'installation sur toutes les machines. Il en serait de même pour l'utilisation du ficher de suivi 23'. À la fin de l'enrichissement, le démon de suivi 32 notifie à l'application de distribution 19, par l'intermédiaire de l'interface API 21 et lors d'une étape 50, des changements survenus dans l'état du processus de distribution afin que l'utilisateur administrateur puisse connaître de sa station 20 l'état de l'installation du logiciel sur les machines cibles. L'annexe E présente un exemple d'information affichée sur l'écran de la station 20 suite à l'annexe D. Une analyse du suivi de la distribution dans le fichier de commande enrichi ou dans le fichier de suivi 23' permet de diagnostiquer, pour chaque installation en échec dans une machine cible 12i et lors d'une étape d'analyse 51, l'opération OPj qui n'a pas pu être effectuée. En outre, le fichier de commande 23 de l'exemple illustré fait une décomposition de la commande de distribution 22 en opérations élémentaires OPa-OPn et rassemble l'état d'avancement de chacune des opérations sur chacune des cibles, de sorte qu'il offre l'avantage de permettre une reprise d'une installation qui n'a pas pu être effectuée correctement. La reprise peut même avoir lieu en cas de mort des démons, car le fichier de commande est non volatil et permet de relancer les démons. La reprise d'une installation en échec dans une ou plusieurs machines cibles s'effectue par la fabrication d'un ou de plusieurs fichiers d'ordre de correction de la même façon que fichiers d'ordre d'installation, comme indiqué à la figure 1 dans les blocs 24 et à la figure 2 à l'étape 45. De même, ces figures illustrent que les fichiers d'ordre de correction sont transportés et exécutés sur chaque machine cible puis les comptes rendus sont remontés vers la machine gestionnaire pour enrichir le fichier de commande 23 de la même façon que pour les fichiers d'ordre d'installation. En bref, la différence entre un fichier de correction et fichier d'installation ne tient que dans le nombre des opérations en cause. Par exemple, une installation qui a été mise en échec lors d'une opération OPj dont la cause analysée remonte à l'opération OPe, le fichier d'ordre de correction 241 ne contient que les opérations OPe-OPk. La figure 6 illustre un algorithme de reprise 90 mis en oeuvre par une commande d'utilisateur nommée "retry" dans le produit du demandeur et accessible à travers l'interface API 21 ou à travers une interface de l'application 19. La reprise de l'action relative ici à l'installation commence à l'étape 91 par l'ouverture du fichier de commande 23 ou du fichier de suivi 23'. À l'étape 92, le démon 32 recherche la ou les machines cibles dont l'état d'installation est en erreur récupérable (recoverable error). Pour chacune de ces machines cibles, la commande de reprise "retry" recherche lors d'une étape 93 la première opération OPe qui est la cause de la mise en échec. Lors d'une étape 94, la commande de reprise fabrique au moins un fichier d'ordre de correction 24i relatif à ces machines cibles et incluant l'ensemble des opérations OPe-OPk nécessaires à la correction. Un bouclage 95 permet d'envoyer un fichier d'ordre de correction 241 vers chacune des machines en erreur. procédé de distribution de logiciel 40 qui vient d'être décrit à titre d'exemple peut subir de nombreuses variantes à la portée de l'homme du métier. Plus particulièrement, la décomposition d'une commande de distribution logiciel en opérations élémentaires, la représentation de la commande distribution sous forme d'un fichier de commande, et suivi par enrichissement du fichier de commande ou du fichier de suivi à partir des comptes rendus d'exécution issus des machines cibles peuvent être ' en oeuvre de diverses façons fort différentes de celle qui vient d'être décrite; notamment selon la répartition de l'intelligence désirée entre la machine gestionnaire les machines cibles. Plusieurs variantes ont été décrites précédemment. En outre, l'emploi de démons est commode et avantageux mais n'est pas nécessaire. Par exemple, un mécanisme d'exécution à distance, tel que celui connu sous le nom "remote exécution" dans le système d'exploitation UNIX, pourrait être utilisé pour l'exécution des opérations élémentaires et la récupération des comptes rendus. Dans ce cas, la soumission des fichiers d'ordre aux machines cibles, l'analyse cas d'erreurs et des comptes rendus, et le suivi par enrichissement du fichier de commande ou du fichier de suivi demanderait cependant l'emploi d'un automate complexe sur la machine gestionnaire. Il en résulte que, d'une manière générale, l'invention a pour objet un procédé distribution d'une action dans des machines cibles -12m à partir d'une machine gestionnaire 12a d'un système informatique, comprenant : dans la machine gestionnaire, la description (à l'étape d'une commande distribution 21 dans un fichier de commande 23 ; l'exécution (à l'étape 46) de l'action dans chacune des machines cibles à partir du fichier de commande 23 ; la génération (à l'étape 47) dans chaque machine cible 12i d'un compte rendu 29i d'exécution de l'action dans la machine cible correspondante ; et le suivi (à l'étape 49) dans la machine gestionnaire de la distribution de l'action à partir des comptes rendus 29. Dans le procédé de distribution 40, le fichier de commande 23 inclut une pluralité d'opérations d'installation OPa-OPn à effectuer sur les machines cibles, et l'exécution de l'action dans l'une quelconque 12i des machines cibles inclut la sélection, à partir de la pluralité des opérations OPa-OPn fichier de commande, des opérations OPa-OPk adaptées à machine cible 121 pour former un fichier d'ordre 241. Cependant, par exemple, le fichier commande pourrait directement inclure des fichiers d'ordre pour les machines cibles. Dans l'exemple illustré, on a vu que le suivi peut être fait enregistrement des comptes rendus dans le fichier de commande 23 ou dans le fichier suivi 23'. En outre, le suivi inclut de préférence une analyse comptes rendus 29. Grâce au suivi contenu dans le fichier de commande ou dans un fichier de suivi, il est possible de faire une analyse du suivi pour diagnostiquer tout défaut de distribution et connaître la ou les machines concernées la ou les opérations qui en sont la cause. Cependant, l'analyse faite à l'étape 48 pourrait remplacer ou compléter l'analyse faite à l'étape 51. De même, est possible de créer à partir de l'analyse du suivi de la distribution faite à l'étape 51 au moins un fichier d'ordre de correction incluant opérations correctrices OPe-OPk, le traitement du fichier d'ordre de correction étant fait comme un fichier d'ordre de distribution. Il apparait aussi que processus de suivi et de reprise par décomposition d'une commande complexe en opérations simples et par agrégation des comptes rendus dans fichier de commande ou dans un fichier propre au suivi, sont indépendants du processus utilisé pour soumettre et exécuter les opérations élémentaires. D'autre part, bien que le dans le procédé de distribution illustré la description dans le fichier de commande soit faite en un langage du type XML, il ressort de la description qu'elle pourrait être faite en un langage, modèle ou format permettant l'échange de documents à travers la Toile (Web). Enfin, dans l'exemple illustré le procédé de distribution 40 est commandé par une application de distribution 19 par l'intermédiaire d'une interface 21 de programmation d'applications (API). On a vu l'avantage de l'option de relier des démons à l'interface. La description est suffisante pour suggérer à tout homme du métier l'emploi d'autres moyens que ceux décrits pour la mise en oeuvre du procédé tel a été défini précédemment. ANNEXE A Inventaire des logiciels installés sur machines clog005 et clog006 rlist -R G clog005 clog006 traduite en xml par le fichier de commande suivant ANNEXE B Fichiers d'ordre Les deux fichiers d'ordre suivants issus du fichier de commande precédent sont envoyés aux deux machines cibles ANNEXE C Compte rendu de la machine cible "clog006" ANNEXE Fichier de commande enrichi à partir des comptes rendus des deux machines ANNEXE affichage sur la station d'administration Revendications 1. Procédé de distribution, à l'aide d'au moins un processeur (14), d'une action dans des machines cibles (12b-12m) à partir d'une machine gestionnaire (12a) d'un système informatique (11) incluant des moyens de mémoire (15), comprenant : dans la machine gestionnaire, la description (42) d'une commande de distribution (21) dans un fichier de commande (23) contenu dans moyens de mémoire (15) ; l'exécution (46) l'action dans chacune des machines cibles à partir du fichier de commande (23) ; la génération (47), dans les moyens de mémoire (15) de chaque machine cible (12i), d'un compte rendu (29i) d'exécution de l'action dans machine cible correspondante - et le suivi (49), dans la machine gestionnaire, de la distribution de l'action à partir des comptes rendus (29). 2. Procédé selon la revendication 1, caractérisé en ce que le fichier de commande (23) inclut une pluralité d'opérations (OPa-OPn) à effectuer sur les machines cibles (12b-12m) et l'exécution de l'action dans l'une quelconque (12i) des machines cibles inclut la sélection, à partir de la pluralité des opérations (OPa-OPn) du fichier de commande, des opérations (OPa-OPk) adaptées à la machine cible (12i) pour former un fichier d'ordre (24i). 3. Procédé selon la revendication 1 ou 2, caractérisé en ce que le suivi est fait par enregistrement dans le fichier de commande (23) ou dans un fichier de suivi (23') inclus dans les moyens de mémoire (15). 4. Procédé selon l'une des revendications 1 à 3, caractérisé en ce que le suivi comprend une analyse des comptes rendus (29). 5. Procédé selon l'une des revendications 1 à 4, caractérisé en ce qu'il comprend en outre l'analyse (51) du suivi de la distribution pour diagnostiquer tout défaut de distribution et connaître la ou les machines concernées et la ou les opérations qui en sont la cause. 6. Procédé selon la revendication 5, caractérisé en ce qu'il comporte la création, à partir de l'analyse du suivi de la distribution, d'au moins un fichier d'ordre de correction (24i) incluant des opérations correctrices (ON OPk) et le traitement du fichier d'ordre de correction comme un fichier d'ordre de distribution. 7. Procédé selon l'une des revendications 1 à 6, caractérisé en ce que la description dans le fichier de commande est faite en un langage permettant l'échange de documents à travers la Toile (Web), tel que langage XML. 8. Procédé selon l'une des revendications 1 à 7, caractérisé en qu'il est commandé par une application de distribution (19) par l'intermédiaire d'une interface (21) de programmation d'applications (API). 9. Système informatique (11) incluant au moins un processeur (14) et des moyens de mémoire (15) répartis dans une machine gestionnaire (12a) et des machines cibles (12b-12m) d'une distribution d'une action à partir de la machine gestionnaire, caractérisé en ce que les moyens de mémoire (15) comprennent des moyens pour la mise en oeuvre du procédé défini selon l'une des revendications 1 à 8 pour la distribution de l'action à l'aide d'au moins ledit processeur. 10. Système d'administration (10) comprenant au moins un processeur (14) des moyens de mémoire (15) répartis dans un gestionnaire (17) inclus dans une machine gestionnaire (12a) et pourvu d'une application (19) permettant la distribution d'une action, et dans des interfaces (18b-18m) incluses dans des machines cibles (12b-12m) dans lesquelles l'action doit être distribuée, caractérisé en ce que la distribution est faite à l'aide d'au moins ledit processeur selon le procédé défini selon l'une des revendications 1 à 8.