FR 3021138 A1 20151120 FR 1454397 A 20140516 ARCHITECTURE DE CORRELATION D'EVENE1VIENTS POUR LA SURVEILLANCE DE SUPERCALCULATEUR DOMAINE DE L'INVENTION L'invention est relative au domaine des centres de calcul, notamment des supercalculateurs. Elle concerne plus particulièrement la surveillance de ces supercalculateurs et des composants et équipements dont ils sont constitués. CONTEXTE DE L'INVENTION Un supercalculateur (ou superordinateur) est un ordinateur conçu pour atteindre les plus hautes performances possibles avec les technologies connues lors de sa conception, en particulier en termes de vitesse de calcul. Les supercalculateurs tirent leur supériorité par rapport aux ordinateurs conventionnels à la fois de la technologie des composants utilisés et leur architecture. Ainsi, les supercalculateurs ont des vitesses de plusieurs peta-flops et vont prochainement atteindre l'exa-flops. Le flops (pour « FLoating point Operations Per Second ») constitue une unité de mesure communément admise pour estimer la vitesse de traitement d'un calculateur. Cette architecture peut notamment être en « pipeline » ou parallèle, afin d'exécuter plusieurs tâches simultanément. Quelle que soit l'architecture retenue, les supercalculateurs contiennent un très grand nombre d'équipements comportant eux-mêmes un grand nombre de composants (mémoires, microprocesseurs, etc.) Typiquement, chaque équipement peut envoyer un message d'information vers un système de surveillance dès lors qu'un de ses composants ou lui-même change de statut. Ce type de message est communément appelé « événement ». Ce système de surveillance a pour mission de collecter et de traiter tous ces événements et doit réagir en conséquence. Par exemple, lorsqu'un équipement envoie dans un laps de temps donné un grand nombre d'alertes de température, le service de surveillance peut devoir prendre la décision de l'éteindre. Mais des alertes concernant un problème unique peuvent « remonter » de différents équipements (ou composants) et peuvent aussi être corrélées au niveau du système de surveillance. C'est par exemple le cas si l'ensemble des composants et/ou équipements situés en haut des armoires émettent des alertes de température, possiblement du fait d'un problème du circuit de refroidissement. Il est alors important de déclencher une alarme pour les administrateurs du supercalculateur. Le service de surveillance peut également alimenter une base de données pour la mettre à jour avec ces informations ainsi collectées et corrélées. Cette base de données peut ensuite être utilisée pour des corrélations plus complexes, des calculs statistiques, etc. Afin de gagner en puissance de calcul, les supercalculateurs deviennent de plus en plus complexes. En conséquence, le nombre d'événements susceptibles d'être générés au sein du supercalculateur croit également. Ce point est d'autant plus crucial que certains problèmes (par exemple affectant une zone d'un supercalculateur, une armoire, etc.) peuvent générer des événements en chaîne sur un grand nombre d'équipements et composants simultanément ou dans un très court laps de temps. Les solutions actuelles se basent sur un ou plusieurs moteurs de corrélation mais elles atteignent d'ores et déjà la limite de leurs possibilités. Certains systèmes de surveillance déployés sur le terrain montrent des retards de traitement de plusieurs heures, ce qui peut entrainer une prise de risque importante pour le calculateur (incident majeur non reporté à temps aux administrateurs, etc.) Les recherches et les travaux visant à améliorer la situation portent essentiellement sur le moteur de corrélation lui-même, ou sur l'adjonction de modules complémentaires pour rendre la chaîne de traitement plus efficace. Toutefois, l'architecture conçue autour d'un moteur de corrélation n'est pas adaptée pour un tel passage à l'échelle. Il en résulte que seules des adaptations ad-hoc, sur le terrain, ont pu être localement entreprises pour minimiser au mieux les problèmes de l'inadéquation des systèmes de surveillance existants aux supercalculateurs. RE SUME DE L'INVENTION Le but de la présente invention est de fournir un système de surveillance palliant au moins partiellement les inconvénients précités. Plus particulièrement, l'invention vise à fournir un système de surveillance pouvant s'adapter à des supercalculateurs de configurations variées, notamment aux « petits » supercalculateurs, aux « gros » supercalculateurs et aux supercalculateurs de prochaines générations. A cette fin, la présente invention propose un procédé de gestion d'un supercalculateur comportant un ensemble de composants comprenant une étape de génération de notifications par des capteurs associés auxdits composants ; une étape de traitement desdites notifications par une hiérarchie de modules, lesdites notifications formant des événements entrants pour les modules de plus bas niveau hiérarchique de ladite hiérarchie, et chaque module comprenant au moins un moteur de corrélation pour corréler des événements entrants et générer des événements sortants transmis aux modules de niveau supérieur au sein de ladite hiérarchie en tant qu'événements entrants; une étape de génération d'alarmes, à partir des événements sortants générés par les modules de plus haut niveau hiérarchique au sein de ladite hiérarchie. A cette fin, la présente invention propose également un système de surveillance d'un supercalculateur comportant un ensemble de composants et des capteurs associés auxdits composants générant des notifications ; ledit système de surveillance comprenant une hiérarchie de modules, chaque module comprenant au moins un moteur de corrélation apte à corréler des événements entrants et générer des événements sortants transmis aux modules de niveau supérieur au sein de ladite hiérarchie, en tant qu'événements entrants ; dans lequel lesdits capteurs sont prévus pour transmettre lesdites notifications à des modules de plus bas niveau hiérarchique de ladite hiérarchie en tant qu'événements entrants. Suivant des modes de réalisation préférés, l'invention comprend une ou plusieurs des caractéristiques suivantes qui peuvent être utilisées séparément ou en combinaison partielle entre elles ou en combinaison totale entre elles, avec l'un ou l'autre des objets de l'invention précédemment décrits : - le procédé de gestion comprend en outre une étape de déclenchement d'une action correctrice transmise audit supercalculateur. - lesdits événements sont aiguillés selon des critères prédéfinis vers un moteur de corrélation parmi ledit au moins un moteur de corrélation. - lesdites alarmes sont transmises à un moniteur disposant d'une interface homme-machine. - une action correctrice est transmise par ledit moniteur vers ledit supercalculateur. - un programme d'ordinateur qui comprend des instructions qui, une fois chargées sur un système de traitement de l'information, sont aptes à mettre en oeuvre le procédé selon l'invention. - les modules de plus haut niveau hiérarchique au sein de ladite hiérarchie sont prévus pour générer des alarmes et les transmettre à un moniteur. - les modules de plus haut niveau hiérarchique au sein de ladite hiérarchie sont prévus pour déclencher une action correctrice et la transmettre audit supercalculateur. - un module comprend en outre un bloc fonctionnel de filtrage et aiguillage apte à aiguiller selon des critères prédéfinis vers un moteur de corrélation parmi ledit au moins un moteur de corrélation. - au moins certains desdits moteurs de corrélation sont mis en oeuvre par un système de règles. - lesdits modules sont prévus pour communiquer conformément au protocole « Syslog ». - lesdites notifications sont transmises conformément au protocole SNMP. - un système qui comporte au moins un supercalculateur et un système de surveillance selon l'invention. - un système qui comporte au moins un supercalculateur, un système de surveillance selon l'invention et un moniteur, ledit moniteur étant prévu pour recevoir des alarmes dudit système de surveillance et pour transmettre des actions correctrices vers ledit supercalculateur. D'autres caractéristiques et avantages de l'invention apparaîtront à la lecture de la description qui suit d'un mode de réalisation préféré de l'invention, donnée à titre d'exemple et en référence aux dessins annexés. BREVE DESCRIPTION DES DESSINS La figure 1 représente schématiquement un supercalculateur. La figure 2 représente schématiquement un exemple de hiérarchie de module de corrélation, selon un mode de réalisation de l'invention. La figure 3 représente schématiquement un exemple de module de corrélation, selon une mise en oeuvre de l'invention. DESCRIPTION DETAILLEE DE L'INVENTION Ainsi qu'illustré sur la figure 1, un supercalculateur SC ou superordinateur peut être composé de plusieurs armoires ou « racks » Al, A2, dans lesquelles sont placés divers équipements El, E2, E3... E8 dans des « tiroirs ». Chaque équipement est généralement constitué lui-même d'un grand nombre de composants électroniques, Cl, C2, C3...C6. Sur la figure 1, uniquement les composants internes des équipements El et E2 sont représentés, par soucis de clarté, mais il est évident que les autres équipements sont également constitués de composants. De même, le nombre de composants représentés et le nombre d'équipements dans chaque armoire sont indiqués sur la figure dans un pur but illustratif : un supercalculateur dispose d'un nombre bien plus important de composants et d'équipements. Des capteurs sont associés aux composants. Il peut être prévu un ou plusieurs capteurs pour un même composant. Il peut aussi être prévu un même capteur pour plusieurs composants. Ainsi, différentes configurations d'association entre capteurs et composants peuvent être prévues. Il peut également être prévu de disposer de capteurs au niveau des équipements, ou bien de former des groupes de composants ou d'équipements qui sont associés à un ou plusieurs capteurs. Les capteurs peuvent être de différentes natures et capturer différents types d' information : température, taux d'humidité, consommation électrique.., mais aussi des informations liées au traitement de données : erreurs matérielles, erreurs logicielles, trafic de données, etc. Ces capteurs sont prévus pour générer des notifications. Ces notifications peuvent être des messages « INFORM » du protocole SNMP (Simple Network Management Protocol), par exemple défini par le STD 62 de l'IETF (Internet Engineering Task Force). Un message « INFORM » diffère d'un message « TRAP » en ce que le récepteur du message (ici le module) acquitte la bonne réception du message. D'une façon générale, donc, le capteur peut envoyer ce message à partir d'un agent SNMP. Il est reçu par un « démon » SNMPTRAPD, puis traité par SMPTT et transmis à un démon Syslog. Le protocole Syslog sera ultérieurement décrit. Les notifications N sont transmises au système de surveillance SS, qui peut les traiter afin d'éventuellement, fournir des alarmes A à un moniteur M et/ou déclencher une action correctrice R1 vers le supercalculateur SC. Une action correctrice R2 peut également être déclenchée par le moniteur M. Le moniteur M peut être un terminal informatique tel qu'un ordinateur, une console, une tablette, un « smartphone », etc. qui permet d'offrir une interface homme-machine à des administrateurs humains. Plusieurs moniteurs peuvent être prévus. Cette interface permet d'une part de présenter aux administrateurs les alarmes A provenant du système de surveillance, sous une forme brute, ou sous des formes plus évoluées (données statistiques, calculs d'évolution, etc.), et d'autre part aux administrateurs de déclencher des actions sur le système de surveillance SS et sur le supercalculateur SC. Ces actions peuvent être la recherche d'informations complémentaires mais aussi des actions correctrices R2. Ces actions correctrices R1, R2, générées par le système de surveillance SS ou par le moniteur M visent à résoudre partiellement ou complétement le ou les problèmes associés à l'alarme A. Cette résolution peut dans certaines situations corriger la source du problème : ainsi, dans le cas d'erreurs logiciels, une mise à jour du logiciel responsable peut être déclenchée et résoudre complétement le problème. Mais il peut aussi s'agir de supprimer les symptômes du problème sans en supprimer véritablement la source : ainsi, en cas d'alarmes associées à une élévation importante de température dans une armoire ou une partie d'armoire, les composants ou équipements impactés peuvent être éteints. Il s'agit là d'éviter tout risque et dégât pour le supercalculateur. Une alarme A est déclenchée par ailleurs pour les administrateurs qui pourront alors entreprendre les démarches nécessaires pour résoudre véritablement le problème (analyse de la cause, investigation sur le terrain, etc.). Il peut être possible également d'aiguiller les alarmes A vers un système d'administration informatique qui est adapté pour entreprendre certaines mesures de façon automatique. Différentes mises en oeuvre sont donc possibles. Le système de surveillance SS comprend une structure de modules Ml, M2, M3...M9. Chaque module peut comprendre au moins un moteur de corrélation apte à corréler des événements entrants et à générer des événements sortants. Il peut en outre être prévu des modules ne comportant pas de moteur de corrélation au sein de la structure. Dans l'exemple illustré par la figure 2, la structure est une hiérarchie. Les événements sortants sont transmis aux modules du niveau hiérarchique supérieur au sein de la hiérarchie, pour lesquels ils sont considérés comme événements entrants. Ainsi, sur la figure 2, le module M4 a comme événements entrants el, e2, e3, qui sont des événements sortants pour, respectivement, les modules Ml, M2, M3. De même, l'événement sortant e4 est considéré comme un événement entrant pour le module M9. Ces modules peuvent être répartis de différentes façons sur une plateforme de traitement de données constituée de plusieurs machines matérielles ou virtuelles. Par exemple, un niveau hiérarchique peut être déployé sur une machine donnée, ou bien plusieurs niveaux peuvent être déployés sur une même machine ; ou bien encore plusieurs modules d'un même niveau hiérarchique peuvent être déployés sur plusieurs machines, etc. La hiérarchie représentée en figure 2 comporte 3 niveaux hiérarchiques. Il s'agit bien évidemment là d'un exemple et un système de surveillance SS conforme à l'invention peut comporter un nombre arbitraire de niveaux hiérarchiques. Ce nombre de niveaux, ainsi que le nombre de modules pour chaque niveau et l'architecture générale de la hiérarchie peuvent être configurés par un utilisateur du système de surveillance SS. Cette configuration peut être effectuée en fonction de la taille et de l'architecture du supercalculateur. Elle peut aussi être adaptée en cours de fonctionnement du supercalculateur, soit pour prendre en compte des évolutions de l'architecture de celui-ci, soit pour prendre en compte les résultats produits par le système de surveillance SS : ainsi, si l'on se rend compte, en cours de fonctionnement, que la majorité des événements provient d'une certaine zone, alors il peut être utile de déployer davantage de modules pour cette zone, soit par ajout de nouveaux modules, soit par réaffectation de modules existants. Les capteurs sont prévus pour transmettre leurs notifications aux modules de plus bas niveau hiérarchique, en tant qu'événements entrant. Dans l'exemple de la figure2, le capteur associé au composant Cl transmet ses notifications au module Ml, le capteur associé au composant C2 transmet ses notifications au module M2, et ainsi de suite jusqu'au capteur associé au composant C6 qui transmet ses notifications au module M7. Dans ce mode de réalisation, les événements issus du niveau hiérarchique de plus haut niveau peuvent être considérés comme des alarmes, qui sont ensuite transmises au moniteur M. Ils peuvent également faire l'objet d'un traitement préalable afin de générer ces alarmes. Dans l'exemple illustré sur la figure 2, la couche de plus haut niveau possède un unique module M9. Ce module M9 peut transmettre des alarmes A à un moniteur M, ainsi que des actions correctrices R1 vers le supercalculateur (non représenté sur la figure 2). Il est toutefois possible d'imaginer des mises en oeuvre de l'invention avec plusieurs modules au sein de la couche de plus haut niveau. Comme il a été dit précédemment, selon l'invention, chaque module comprend au moins un moteur de corrélation pour corréler des événements entrants et générer des événements sortants. Ainsi qu'illustré par la figure 3, les modules peuvent en outre comporter d'autres fonctions qui peuvent être en prétraitement ou post-traitement par rapport au moteur de corrélation MC. Chaque module de la hiérarchie peut comporter des fonctions différentes, et des mises en oeuvre différentes de chaque fonction. Selon un mode de réalisation possible, les modules d'un même niveau hiérarchique sont semblables (mêmes fonctions, mêmes implémentations des fonctions), mais d'autres modes de réalisation sont possibles selon lesquels même au sein d'un même niveau hiérarchique, les modules peuvent disposer de fonctions différentes et, pour des fonctions communes, de mises en oeuvre différentes. Les événements entrants E peuvent être des événements sortants d'un autre module (de niveau hiérarchique immédiatement inférieur), ou bien des notifications provenant d'un capteur. Dans ce second cas, les notifications peuvent être conformes au protocole SNMP, et notamment être des messages « INFORM » ainsi que décrit précédemment. Elles peuvent être en outre conformes au protocole « Syslog » défini par le RFC 5424 de l'IETF. Les événements transmis entre modules du système de surveillance peuvent être conformes à différents protocoles normalisés ou « propriétaires ». Ils peuvent également être conformes à ce même protocole « Syslog ». Il peut en tout cas s'agir de communication directe entre les modules, sans mise en place de « file Syslog », de sorte que les communications en sont accélérées et que l'ajout de modules peut être configure de façon très simple et immédiate par un administrateur. L'événement entrant E peut tout d'abord être traité par un bloc fonctionnel de formatage LF. Cette fonction vise à réarranger et éventuellement compléter l'événement entrant, et notamment de préciser son niveau de criticité, de formater le contenu de l'événement selon des schémas prédéfinis, etc. Ce traitement permet de faciliter les traitements subséquents. L'événement est ensuite transmis à un bloc fonctionnel de filtrage et répartition FD. Cette fonction permet d'aiguiller les événements selon des critères prédéfinis vers des chemins différents au sein du module, notamment vers des moteurs de corrélation différents. Les critères peuvent être divers. Par exemple, il peut s'agir de disposer de moteurs de corrélation spécialisés pour traiter des types donnés d'événements (par exemple, les événements relatifs à la température). Ainsi, les critères prédéfinis permettent d'aiguiller chaque événement vers le moteur de corrélation approprié. Il peut être possible également d'effectuer de la répartition de charge en aiguillant les événements vers un moteur de corrélation moins chargé. La détermination du moteur de corrélation le moins chargé peut se faire de différentes façons : par une mesure de charge provenant périodiquement des moteurs de corrélation, par une estimation en fonction de statistiques sur les événements entrants préalablement répartis, etc. Un dispositif de monitoring MD peut être en charge d'établir des informations sur la charge des différents moteurs de corrélation et de les remonter vers le bloc fonctionnel de filtrage et aiguillage FD. Le bloc fonctionnel de filtrage et répartition FD permet aussi de filtrer les événements entrants. Ce filtrage peut avoir pour objectif de limiter les risques d'avalanche. En effet, certains dysfonctionnements du supercalculateur peuvent provoquer des réactions en chaine et/ou un très grand nombre de notifications provenant de composants. Par exemple, une panne du système de ventilation peut entraîner des notifications provenant du système de ventilation lui-même, puis un nombre grandissant de notifications provenant des composants de calcul à mesure que la température s'élève, etc. Ces phénomènes peuvent dans certains cas engorger complétement un système de surveillance, et donc empêcher ou ralentir la résolution du problème. Le filtrage permet de sélectionner un nombre réduit d'événements entrants étant visiblement liés à une même cause, afin de décharger les moteurs de corrélation de la charge impliquée. Il permet en outre de ne garder en traitement que les évènements ayant une certaine criticité. Ainsi, ceux représentant un niveau d'information inférieur peuvent être écartés afin de favoriser les évènements plus prioritaires (ayant une criticité plus élevée). Les événements entrants peuvent ensuite être transmis à un bloc fonctionnel de prétraitement LEP. Ce bloc a pour but de compléter, le cas échéant, l'événement par des informations complémentaires. Ces informations complémentaires peuvent être recueillies de différentes façons et peuvent dépendre de l'implémentation du moteur de corrélation. Dans la mesure où les moteurs de corrélation contenus dans le module peuvent être spécialisés et donc faire l'objet de différentes implémentations, ces blocs fonctionnels de prétraitement LEP peuvent être adaptés à chaque moteur de corrélation. Aussi, dans l'exemple de la figure 3 sont représentés 3 moteurs de corrélation avec donc 3 blocs fonctionnels de prétraitement. Puis, les événements sont transmis au moteur de corrélation MC correspondant au bloc fonctionnel de prétraitement LEP. Comme il a été dit précédemment, chaque moteur de corrélation peut faire l'objet d'une implémentation différente. Cette implémentation peut être adaptée à une spécialisation du moteur de corrélation pour traiter un type d'événements particuliers. Le module MC peut aussi ne contenir qu'un unique moteur de corrélation. Les moteurs de corrélation peuvent être répartis sur plusieurs machines matérielles, afin de paralléliser et répartir au mieux la charge de traitement. Il est également possible de déployer plusieurs modules M au sein d'une même machine matérielle ou virtuelle. Ces choix d'architecture et de déploiement sont à décider par un administrateur du système de surveillance. Mais il est à noter qu'un tel système de surveillance conforme à l'invention n'est pas figé et peut être modifié a posteriori. Il peut être modifié du fait d'évolutions apportées au supercalculateur supervisé, mais aussi du fait d'informations sur l'historique de la supervision : l'administrateur peut ainsi se rendre compte que certains dysfonctionnements ne sont pas gérés de façon optimale et décider d'une modification du système de surveillance pour mieux les prendre en compte pour le futur. Le(s) moteur(s) de corrélation transmettent ensuite l'événement vers un bloc de traitement des résultats RP. Ce bloc vise à élaborer et mettre en forme un événement sortant. Il peut ici être mis en place éventuellement une adaptation protocolaire afin de permettre une interopérabilité avec les modules ou d'autres dispositifs. Ce bloc de traitement des résultats peut aussi être prévu pour transmettre une action correctrice R1 vers le supercalculateur supervisé, ainsi qu'il a été décrit préalablement. Ce bloc de traitement des résultats peut aussi déclencher une mémorisation de l'événement dans une base de données qui peut être commune à l'ensemble des modules du système de surveillance. Cette base de données DB permet de garder un historique (« log ») des différents événements traités, afin de pouvoir s'y référer pour traiter des nouveaux événements (par le bloc fonctionnel de prétraitement LEP, notamment). Elle peut aussi être utilisée par un dispositif extérieur, par exemple le moniteur (décrit en référence avec la figure 2) pour effectuer des statistiques ou bien pour obtenir des informations plus précises sur une alarme reçue. Les moteurs de corrélation peuvent mettre en oeuvre différentes technologies. La technologie mise en oeuvre peut dépendre de choix de l'administrateur en fonction de son expertise et de sa connaissance du supercalculateur. Elle peut aussi dépendre de considérations de coûts, ou de performance des moteurs sur le marché au moment du choix. Elle peut aussi être adaptée au type d'événements traités dans le cas d'une spécialiste des moteurs de corrélation. Quelle que soit la technologie utilisée, une contrainte forte pour un moteur de corrélation est de permettre un résultat rapide et pertinent. La rapidité est importante afin de permettre une réaction rapide sur le problème détecté (de façon automatique ou manuelle). La pertinence implique de minimiser les fausses alertes et, surtout, de détecter un maximum d'événements pertinents, c'est-à-dire révélateurs d'un problème sur le supercalculateur supervisé. De nombreuses technologies ont été développées pour mettre en oeuvre les moteurs de corrélation. On peut citer 3 grandes familles de technologies, chacune se déclinant en de nombreuses variantes et implémentations. Une première famille de technologies est basée sur des règles (« rulebased systems »). Il s'agit probablement des technologies les plus courantes. Elles consistent à essayer de mettre en correspondance des événements entrants avec des règles, stockées dans une base de règles. En cas de mise en correspondance, la règle est inférée et des conclusions peuvent être établies. Ces conclusions peuvent consister en la transmission d'un nouvel événement, en le déclanchement d'une action correctrice, d'un traitement, etc. Parmi les implémentations de ces technologies, on peut citer le système SEC (« Simple Event Correlator »), JRules, Kazimir, etc. Une autre famille de technologies est appelée « codebook ». Il s'agit en quelque sorte d'une variante des technologies à base de règles, mais au lieu de considérer les événements individuellement, ceux-ci sont agrégés en vecteurs et les vecteurs sont comparés à des matrices contenant des signatures associées à différents problèmes possibles. Le but est de rechercher la cause première d'un ensemble d'événements (notifications) provenant du supercalculateur supervisé. Une autre famille fait usage des techniques d'intelligence artificielle : il peut s'agir de réseaux bayésiens, de systèmes experts, etc. ou de combinaisons de ces techniques. Un des avantages de l'invention est sa flexibilité. Le système de surveillance SS est ainsi très ouvert et permet d'imaginer et mettre en place différentes structures, afin de potentiellement répondre à un maximum de besoins, principalement en fonction de la taille des supercalculateurs mais aussi des technologies requises pour leur supervision. Du point de vue de l'implémentation, ce modèle peut être considéré comme une plateforme à « plugins ». Ainsi, les éléments peuvent être inter-changés, étendus... sans toucher au coeur de la plateforme. Les extensions peuvent ne se faire que sur des sous-ensembles précis et particuliers, si tel en est le besoin. De même, une architecture peut évoluer au fil du temps, en suivant les évolutions des supercalculateurs, sans à avoir à faire table rase de la solution actuelle. Les coûts de maintenance et d'évolution sont ainsi réduits. Bien entendu, la présente invention n'est pas limitée aux exemples et au mode de réalisation décrits et représentés, mais elle est susceptible de nombreuses variantes accessibles à l'homme de l'art. REVENDICATIONS1. Procédé de gestion d'un supercalculateur (SC) comportant un ensemble de composants (Cl, C2, C3...C6) comprenant Une étape de génération de notifications (N) par des capteurs associés auxdits composants ; Une étape de traitement desdites notifications par une hiérarchie de modules, lesdites notifications formant des événements entrants pour les modules de plus bas niveau hiérarchique de ladite hiérarchie, et chaque module comprenant au moins un moteur de corrélation pour corréler des événements entrants et générer des événements sortants transmis aux modules de niveau supérieur au sein de ladite hiérarchie en tant qu'événements entrants; Une étape de génération d'alarmes (A), à partir des événements sortants générés par les modules de plus haut niveau hiérarchique au sein de ladite hiérarchie. 2. Procédé selon la revendication précédente, comprenant en outre une étape de déclenchement d'une action correctrice (R1) transmise audit supercalculateur. 3. Procédé selon l'une des revendications précédentes, dans lequel lesdits événements sont aiguillés selon des critères prédéfinis vers un moteur de corrélation parmi ledit au moins un moteur de corrélation. 4. Procédé selon l'une des revendications précédentes, dans lequel lesdites alarmes sont transmises à un moniteur (M) disposant d'une interface homme-machine. 5. Procédé selon la revendication précédente, dans lequel une action correctrice (R2) est transmise par ledit moniteur (M) vers ledit supercalculateur (SC). 6. Programme d'ordinateur comprenant des instructions qui, une fois chargées sur un système de traitement de l'information, sont aptes à mettre en oeuvre le procédé selon l'une des revendications 1 à 5. 7. Système de surveillance (SS) d'un supercalculateur (SC) comportant un ensemble de composants (Cl, C2, C3...C6) et des capteurs associés auxdits composants générant des notifications (N) ; ledit système de surveillance comprenant une hiérarchie de modules, chaque module comprenant au moins un moteur de corrélation apte à corréler des événements entrants et générer des événements sortants transmis aux modules de niveau supérieur au sein de ladite hiérarchie, en tant qu'événements entrants ; dans lequel lesdits capteurs sont prévus pour transmettre lesdites notifications à des modules de plus bas niveau hiérarchique de ladite hiérarchie en tant qu'événements entrants. Système de surveillance selon la revendication précédente, dans lequel les modules de plus haut niveau hiérarchique au sein de ladite hiérarchie sont prévus pour générer des alarmes (A) et les transmettre à un moniteur (M). 9. Système de surveillance selon la revendication 7 ou 8, dans lequel les modules de plus haut niveau hiérarchique au sein de ladite hiérarchie sont prévus pour déclencher une action correctrice (R1) et la transmettre audit supercalculateur. 10. Système de surveillance selon l'une des revendications 7 à 9, dans lequel un module comprend en outre un bloc fonctionnel de filtrage et aiguillage (FD) apte à aiguiller selon des critères prédéfinis vers un moteur de corrélation parmi ledit au moins un moteur de corrélation.11. Système de surveillance selon l'une des revendications 7 à 10, dans lequel au moins certains desdits moteurs de corrélation sont mis en oeuvre par un système de règles. 12. Système de surveillance selon l'une des revendications 7 à 11, dans lequel lesdits modules sont prévus pour communiquer conformément au protocole « Syslog ». 13. Système de surveillance selon l'une des revendications 7 à 12, dans 10 lequel lesdites notifications (N) sont adaptées à être transmises Conformément au protocole SNMP. 14. Système comportant au moins un supercalculateur (SC) et un système de surveillance (SS) selon l'une des revendications 7 à 13. 15 15. Système comportant au moins un supercalculateur (SC), un système de surveillance (SS) selon l'une des revendications 7 à 13 et un moniteur (M), ledit moniteur étant prévu pour recevoir des alarmes (A) dudit système de surveillance (SS) et pour transmettre des actions correctrices 20 (R2) vers ledit supercalculateur.