Brevet FR3061570A1 — publié le 20180706

Mécanisme de surveillance et d'alertes des applications du Système Informatique DOMAINE TECHNIQUE DE L'INVENTION La présente invention concerne le domaine de la surveillance d'infrastructures informatiques, et plus particulièrement le domaine de la surveillance et d'alertes des applications du système informatique des 10 entreprises. ARRIERE-PLAN TECHNOLOGIQUE DE L'INVENTION Dans le cadre des activités de la Direction des Systèmes d'Information (DSI), une intervention est requise lorsque le respect de la qualité de service 15 d'une application est au dessus des seuils critiques ou lorsque l'application ne fonctionne pas. Généralement, cette situation s'explique par le fait qu'aucune surveillance n'est en place sur l'infrastructure hébergeant la solution et/ou que la remontée des alertes n'est pas faite ou est faite trop tardivement. Dans ce cas, il est généralement très difficile de trouver l'origine 20 du problème afin de la corriger, car les données nécessaires à l'analyse du problème ne sont pas ou plus disponibles. Il est connu de l'art antérieur des solutions permettant de surveiller des infrastructures informatiques. Ces solutions permettent de diagnostiquer des problèmes de contentions sur les serveurs, mais ne permettent pas de 25 faire le lien entre une saturation de ressources et les applications du système d'information. Ces solutions permettent uniquement de déclencher une intervention technique pour résoudre le problème, mais elles ne permettent pas de répondre aux niveaux des « accords de niveau de service » (défini également par le terme anglophone Service-Level Agreement SLA) que 30 doivent garantir les DSI (Directeurs des Systèmes Informatiques) à leurs directions métiers pour assurer une bonne performance et un bon respect de 3061570 2 la qualité de service des applications ou des serveurs d'une chaîne applicative. Dans ce contexte, il est intéressant de proposer une solution permettant de pallier les inconvénients de l'art antérieur en remédiant aux 5 problèmes de performance applicative d'un système informatique. DESCRIPTION GENERALE DE L'INVENTION La présente invention a pour but de pallier certains inconvénients de l'art antérieur en proposant une solution permettant de remédier et/ou prévenir les problèmes de performances applicative. A cet effet, la présente invention concerne un système comprenant au moins une machine informatique et un logiciel ou code exécutable par la machine pour mettre en oeuvre un mécanisme de surveillance des performances des applications d'une chaîne applicative, le système comprenant un agencement matériel et logiciel d'informatique formant un référentiel de mesure (1) permettant, d'une part, la mesure par des sondes de consommation installées sur des ressources pour mesurer des niveaux d'utilisation des ressources des applications lors des périodes de dégradation des performances d'une ou plusieurs application(s) de la chaîne applicative, et d'autre part, la mémorisation, par application et par période de la chaîne applicative, dans une mémoire (11) de ces niveaux d'utilisation dans le référentiel de mesure (1) ; caractérisé en ce que l' agencement matériel et logiciel du système permet en outre : d'établir un référentiel d'utilisation (2) des données du référentiel de mesure en définissant et mémorisant dans au moins une mémoire (21, 22, 23), par ressource et par application, des seuils (Smin, Sint, Smax) de performance acceptables du niveau d'utilisation ; 3061570 3 - de constituer un module de catégorisation (3) des problèmes de performance en fonction des référentiels de mesure (1) et d'utilisation (2) ; - et de mettre en oeuvre un mécanisme d'alerte (4) lorsque le 5 mécanisme de surveillance détecte un problème de performance d'une ou plusieurs applications dans la chaîne applicative ou lorsque le problème est résolu. Ainsi, l'invention permet en surveillant les consommations de ressources des applications d'une chaîne applicative et leurs évolutions dans 10 le temps d'alerter avant qu'une contention se produise ou lorsque des applications ont un comportement anormal et de résoudre le problème exposé ci-dessus. Selon une autre particularité, les seuils de performance acceptable du niveau d'utilisation, comprennent trois seuils acceptables formant un triplet et 15 constitué d'un seuil minimal, un seuil maximal et un seuil intermédiaire ; ce triplet de seuils étant mémorisé pour chaque ressource et pour chaque application de la chaîne applicative. Selon une autre particularité, le référentiel d'utilisation comprend au moins un agencement matériel et logiciel permettant d'établir et mémoriser 20 dans une mémoire, des intervalles de consommation acceptable définis à partir des mesures du niveau d'utilisation du référentiel de mesure. Selon une autre particularité, le mécanisme de surveillance est apte à comparer le niveau d'utilisation des ressources, mesuré et mémorisé dans le référentiel de mesure avec les seuils et/ou des intervalles de consommation 25 établis dans le référentiel d'utilisation par application. Selon une autre particularité, le référentiel d'utilisation (2) comprend au moins un agencement matériel et logiciel (20) permettant d'établir et mémoriser dans une mémoire les niveaux d'utilisation réel (21) et théorique (22) par seuil (Smin, Sint, Smax) pour chaque ressource. 3061570 4 Selon une autre particularité, les niveaux d'utilisation des ressources des applications, sont mesurés plusieurs fois de sorte à caractériser les différents niveaux de consommation de ressources des applications. Selon une autre particularité, la mesure des niveaux d'utilisation des 5 ressources des applications, est réalisée dans un environnement de pré- production ou de qualification. Selon une autre particularité, la mesure des niveaux d'utilisation des ressources des applications, est également réalisée dans un environnement de production, de sorte à affiner, si nécessaire, les seuils de performance 10 acceptable du niveau d'utilisation et/ou les intervalles de consommation pour chaque ressource et par application. Selon une autre particularité, le référentiel de mesure comprend un agencement matériel et logiciel permettant la mesure par des sondes de consommation et la mémorisation dans une mémoire des niveaux 15 d'utilisation « saisonnier » des ressources ou des applications ayant de fortes variations saisonnières d'utilisation, de sorte à établir et mémoriser des seuils « saisonniers » de performance acceptable du niveau d'utilisation par ressource et par application. Selon une autre particularité, le module de catégorisation des 20 problèmes de performance permet d'établir la catégorisation par une opération : - de création d'une catégorie « consommations ressources» mémorisée dans une mémoire et comprenant la consommation totale d'un niveau d'utilisation mesuré pour chaque ressource et chaque application de 25 la chaîne applicative, ou - de comparaison d'un niveau d'utilisation mesuré d'une ressource disponible dans le référentiel de mesure avec le seuil maximal de performance acceptable du niveau d'utilisation de chaque ressource d'une application disponible dans le référentiel d'utilisation afin de créer une catégorie « anomalie matérielle », mémorisée dans une 3061570 5 mémoire, lorsque le niveau d'utilisation mesuré est au dessus du seuil maximum de la ressource, ou - de comparaison d'un niveau d'utilisation mesuré d'une ressource disponible dans le référentiel de mesure avec l'intervalle de 5 consommation acceptable du niveau d'utilisation pour chaque ressource d'une application disponible dans une mémoire du référentiel d'utilisation, afin de créer une catégorie « dégradation performance applicative », mémorisée dans une mémoire, lorsque le niveau d'utilisation mesuré est hors de l'intervalle de consommation 10 acceptable de la ressource, ou - de calcul des consommations futures de dégradation de performance par ressource et par application, à partir de l'association d'une règle de saisonnalité des besoins en ressources d'une application avec le niveau d'utilisation mesuré de la ressource de l'application disponibles 15 dans le référentiel de mesure, mémorisé dans une mémoire, ou - de comparaison d'un résultat de calcul des consommations futures d'une ressource avec un seuil maximum de performance acceptable du niveau d'utilisation de chaque ressource d'une application disponible dans le référentiel d'utilisation, afin de créer une catégorie 20 « prévention performance applicative », mémorisée dans une mémoire, lorsque le résultat du calcul des consommations futures de la ressource est au dessus du seuil maximum de performance acceptable de la ressource d'une application, - ou de combinaison d'au moins deux des opérations ci-dessus. 25 Selon une autre particularité, le mécanisme d'alerte permet de créer et mémoriser dans au moins une mémoire au moins une ou plusieurs des alertes ci-après : - une alerte « anomalie matérielle » lorsque le niveau d'utilisation d'une ressource d'une application disponible dans le référentiel de mesure, 3061570 6 est au dessus d'un seuil maximal de performance acceptable de ladite ressource disponible dans le référentiel d'utilisation; - une alerte « dégradation performance applicative » lorsque le niveau d'utilisation d'une ressource d'une application disponible dans le 5 référentiel de mesure, est hors de l'intervalle de consommation acceptable de ladite ressource disponible dans le référentiel d'utilisation; - une alerte « préventive performance applicative » lorsque le résultat de calcul des consommations futures d'une ressource d'une 10 application disponible dans la mémoire du module de catégorisation, est au dessus d'un seuil maximal de performance acceptable de ladite ressource disponible dans le référentiel d'utilisation. Selon une autre particularité, le système est apte à surveiller et alerter en continu d'une anomalie sur une ou plusieurs applications de la chaîne 15 applicative, ou d'une dégradation de la performance sur la chaîne applicative due à une surconsommation de ressources critiques pour l'application ou d'une future surconsommation de ressources. Un autre but est de remédier à un ou plusieurs inconvénients de l'art 20 antérieur concernant le mécanisme de surveillance et d'alerte des symptômes observables sur des applications d'une chaîne applicative lors d'événements de dégradation de ces performances. Ce but est atteint par un procédé de surveillance des performances des applications d'une chaîne applicative et de commande d'un système 25 selon une des particularités de la présente invention, le procédé comprenant : - une étape de mesure et de mémorisation du niveau d'utilisation des ressources pour chaque application de la chaîne applicative pour pouvoir caractériser les différents niveaux de consommation de 30 ressources ; 3061570 7 le procédé comprend en outre : - une étape de mesure et de mémorisation des besoins en ressources des différents composants d'une application ; - une étape de construction d'un référentiel d'utilisations à partir des 5 données obtenues dans les étapes de mesure et de mémorisation des niveaux d'utilisation des ressources et des besoins en ressources des applications, de sorte à établir un seuil minimum, un seuil maximum et un seuil intermédiaire pour chaque ressource mesurée et pour chaque application; 10 - une étape de catégorisation et de mémorisation des problèmes de performance d'une ou plusieurs ressources à partir du référentiel d'utilisation et des données obtenues dans les étapes de mesure et de mémorisation des niveaux d'utilisation des ressources et des besoins en ressources des applications de la chaîne applicative ; 15 - une étape de comparaison des niveaux d'utilisation mesurés avec les seuils de performance acceptable à partir des problèmes de performance de l'étape de catégorisation ; - une étape de mise en place d'une alerte des problèmes de performance à partir des données obtenues dans l'étape de 20 comparaison, de sorte à corriger le ou les problèmes de performance en modifiant la chaîne applicative ou les ressources d'une application de la chaîne applicative. Selon une autre particularité, l'étape de comparaison des niveaux d'utilisation mesurés avec les seuils de performance acceptable, est réitérée 25 continuellement de sorte à surveiller et alerter en continu les applications de la chaîne applicative. D'autres particularités et avantage de la présente invention sont détaillés dans la description qui suit. 3061570 8 DESCRIPTION DES FIGURES ILLUSTRATIVES D'autres particularités et avantages de la présente invention 5 apparaîtront plus clairement à la lecture de la description ci-après, faite en référence aux dessins annexés, dans lesquels : - la figure 1 représente schématiquement des éléments d'un système pour mettre en oeuvre un mécanisme de surveillance des performances des applications d'une chaîne applicative, selon un mode de réalisation de 10 l'invention ; - la figure 2 représente schématiquement un procédé de surveillance et d'alerte des performances des applications d'une chaîne applicative, selon un mode de réalisation de l'invention. DESCRIPTION DES MODES DE RÉALISATION PRÉFÉRÉS DE 15 L'INVENTION Dans la suite, une sonde informatique est un logiciel associé à un équipement (par exemple un capteur) qui permet automatiquement, par exemple dès qu'il y a une certaine variation ou de façon cyclique, d'effectuer, 20 de gérer et faire remonter vers un équipement de surveillance des mesures destinées à informer entre autres de la qualité des flux réseau ou de la qualité de service (QoS, pour « quality of service » en anglais). Ainsi, elles ne nécessitent donc pas l'envoi de commandes répétitives de la part de l'utilisateur qui viennent encombrer le réseau mais les remontées 25 d'informations sont faites automatiquement par les sondes. Dans un mode de réalisation, la fréquence d'échantillonnage des sondes doit rester constante et synchrone afin de pouvoir corréler les mesures entre les différents serveurs physiques et/ou virtuels qui composent la chaine applicative. 30 3061570 9 La présente invention concerne un système comprenant au moins une machine informatique et un logiciel ou code exécutable par la machine, qui communique avec les autres matériels ou logiciels d'une chaîne applicative pour mettre en oeuvre un mécanisme de surveillance des 5 performances des applications (ou des serveurs) d'une chaîne applicative, notamment lors de la dégradation des performances des applications de la chaîne applicative. On notera que la dégradation de performance d'application de la chaîne applicative, peut-être tout type de comportement anormal ou tout type de contention potentielle sur l'une ou plusieurs des 10 applications (ou serveurs) de la chaîne applicative, par exemple et non limitativement une saturation des ressources d'une application ou une surconsommation des ressources d'une application. La chaîne applicative comprend un ensemble de ressources (R1, ..., R,, ..., Rn) utilisée en tout ou partie par une pluralité d'applications ou de serveurs (A1, A1, ..., Am), la 15 structuration de la chaîne applicative est donc représentée en mémoire par une liste d'identifiants Lride ressources associés à chaque application A1. Dans un mode de réalisation, le système comporte au moins un agencement matériel et logiciel informatique de mémorisation d'un référentiel 20 de mesure (1). Le référentiel de mesure (1) comprend au moins un agencement matériel et logiciel informatique (10), permettant la mesure, par des sondes de consommation, d'un niveau d'utilisation Nur; des ressources Ri sur chacune des applications A; de l'ensemble des applications (A1, ..., A1, ..., Am) qui constituent la chaîne applicative lors des périodes de dégradation 25 des performances Pdpi, puis la mémorisation de ces niveaux Nur; dans une mémoire (11) du référentiel de mesure (1), en association avec la période Pdp; , pour constituer des doublets d'information (Nuri,Pdpi). Les sondes de consommation sont associées à chaque ressource pour remonter les informations de mesures ou métriques, représentant le 30 niveau d'utilisation des ressources (Nur). Pour chaque ressource, les sondes de consommation définissent un identifiant Lr pour le nom de la ressource et un niveau d'utilisation Nu. Le niveau d'utilisation de chaque ressource Nur; 3061570 10 correspond à un doublet d'information (Lr, Nui). Le même processus s'effectue pour les périodes sans problème de performance pour mémoriser des triplets (Lr, Nui, Pndpi). La mémoire (11) du référentiel de mesure stocke ainsi des triplets (Lr, 5 Nui, Pdpi) ou (Lr, Nui, Pdpi), ce qui présente l'avantage de réduire le nombre et la quantité d'informations envoyées par les sondes, pour réduire l'encombrement du réseau tout en améliorant la précision par rapport aux solutions connues ci-dessus. 10 Dans certains modes de réalisation, les ressources sondées peuvent être chaque instance de cluster, chaque cache applicatif, chaque taille des files de messages d'interface de programmation d'applications JMS/JDBC en plus du processeur, des entrées/sorties, et de la mémoire. L'interface de programmation d'applications (API) JMS (service de messagerie java) est 15 une interface de programmation pour l'envoi et la réception de message entre applications et, JDBC (« connectivité des bases de données java ») est une API permettant l'accès à des bases de données. Des informations peuvent être remontées par les sondes de consommations, telles que par exemple et non limitativement, la charge sur 20 chacun des serveurs calculée en pourcentage (%) d'occupation des ressources (un processeur (définit également comme un « central processing unit CPU » en anglais), une mémoire, etc.), la charge sur les entrées/sorties des disques ou la charge sur le débit du réseau (paquets de connexion (définit également comme un « transmission control protocol TCP » en 25 anglais) et comptage des octets), etc. Des éléments génériques tels que: charges, pourcentages (%) d'occupations des ressources, temps de réponse, temps de traitement, niveau d'utilisation CPU, niveau de lecture disque, niveau d'écriture disque, etc., peuvent être mesurés par les sondes mais aussi des éléments ou 30 évènements plus spécifiques tels que le nombre de fichiers ou de ports 3061570 11 ouverts, de files de message JDBC (pour « Java DataBase Connectivity » en anglais, étant une interface de programmation permettant à un programme Java l'accès aux bases de données) ou JMS (pour « Java Message Service » en anglais, étant une interface de programmation permettant 5 d'envoyer et recevoir des messages entre les applications), le taux d'occupation du système de fichiers, le taux de fonctionnement du ramasse miettes ou récupérateur de mémoires (pour « garbage collector » en anglais) pour les applications J2EE (pour « Java Enterprise Edition » en anglais, J2EE étant une plateforme orientée serveur pour le développement et 10 l'exécution d'applications distribuées), etc. Par système de fichiers, d'une architecture matérielle informatique par exemple, on entend un ensemble de principes et de règles selon lesquels les fichiers de ladite architecture informatique sont organisés et manipulés. 15 Dans certains modes de réalisation, le système comprend également un agencement matériel et logiciel informatique (20) comprenant un référentiel de configuration (2). En effet, l'agencement matériel et logiciel du système permet d'établir le référentiel d'utilisation dans au moins une mémoire (21, 22, 23) définissant et mémorisant des seuils (Smin, Sint, 20 Smax) de performance acceptables du niveau d'utilisation par ressource et par application de la chaîne applicative. La mesure des niveaux d'utilisation des ressources par des sondes de consommation, permet d'obtenir des informations pour les DSI (Directeurs des Systèmes Informatiques) sur le niveau actuel et prédictif (par des 25 calculs) de la consommation des ressources d'une application donnée de la chaîne applicative. Dans certains modes de réalisation, les niveaux d'utilisation sont mesurés plusieurs fois, par exemple et non limitativement trois mesures ou plus, de sorte à pouvoir caractériser précisément et de façon fiable les différents niveaux de consommation ou d'utilisation des 30 ressources. La mesure répétée des niveaux d'utilisation des ressources 3061570 12 permet, d'une part, d'établir les seuils (Smin, Sint, Smax) de performance acceptable, c'est-à-dire le ou les seuils à partir duquel la performance de la ressource de l'application va être dégradée, et d'autre part, d'établir des intervalles (In) de consommation acceptable pour chaque ressource d'une 5 application, c'est-à-dire les intervalles dans lesquels la performance de la ressource de l'application n'est pas dégradée et fonctionne correctement. Dans certains modes de réalisation, les seuils de performance du niveau d'utilisation comprennent trois seuils acceptables formant un triplet constitué d'un seuil minimal (Smin), un seuil intermédiaire (Sint) et un seuil maximal 10 (Smax) pour chaque ressource et pour chaque application de la chaîne applicative. Ce triplet de seuils (Smin, Sint, Smax) est mémorisé dans au moins une mémoire (21, 22, 23) du référentiel d'utilisation (2) pour chaque ressource d'une application donnée de la chaîne applicative. Ces différents seuils présentent l'avantage de définir un indicateur ou une information 15 fiable, facile à établir et contribuant à l'appréciation de l'état de la performance des applications par les DSI. Dans certains modes de réalisation, les intervalles (In) de consommation sont établis à partir des mesures des niveaux d'utilisation du référentiel de mesure (1), et mémorisés dans une mémoire (24) du référentiel d'utilisation (2) pour chaque ressource 20 et par application de la chaîne applicative. Cet intervalle peut être calculé, par exemple, à partir des mesures des niveaux d'utilisation du référentiel de mesure (1) qui ont été effectuées antérieurement. En effet, ces mesures antérieures permettent d'établir une saisonnalité de l'utilisation ou de consommation de l'application et par conséquent du niveau d'utilisation de 25 ressources sur chaque application physique ou virtuelle. L'intervalle de consommation peut être aussi calculé à partir des seuils (Smin, Sint, Smax) de performance acceptable pour chaque ressource et par application. Dans ce cas d'exemple, les intervalles de consommation peuvent être compris entre le seuil minimal de performance et le seuil intermédiaire, entre le seuil 30 intermédiaire et le seuil maximal, ou entre le seuil minimal et le seuil maximal. 3061570 13 Dans certains modes de réalisation, le mécanisme de surveillance permet de comparer le niveau, d'utilisation des ressources, mesuré et mémorisé dans le référentiel de mesure (1) avec les seuils (Smin, Sint, Smax) et/ou les intervalles (In) de consommation établis, préalablement, 5 dans le référentiel d'utilisation (2) pour chaque ressource et pour chaque application. Cette comparaison des niveaux d'utilisation mesurés avec les seuils et/ou les intervalles préétablis et mémorisés dans le référentiel d'utilisation, permet de mettre en place un mécanisme d'alerte (4), détaillé ci-dessous, lorsque le système détecte une contention potentielle et/ou un 10 comportement anormal dans une ou plusieurs applications de la chaîne applicative, ou lorsque le problème est résolu. Ainsi, contrairement aux solutions des arts antérieurs, le système de la présente invention présente l'avantage de faire le lien entre une dégradation de performance d'une ressource et les applications du système d'information qui en seront 15 impactées. La mise en place d'une surveillance et d'une alerte des applications du système d'information, selon les modes de réalisation de la présente invention, permet donc de corriger et prévenir des incidents en production. 20 Dans certains modes de réalisation, la mesure des niveaux d'utilisation pour établir et mémoriser les seuils (Smin, Sint, Smax) de performance acceptable et/ou les intervalles (In) de consommation pour chaque ressource et par application, peut être réalisée, préalablement, dans un environnement informatique de pré-production (environnement sur lequel sont partiellement 25 exécutés les programmes de l'application) ou de qualification (environnement sur lequel sont testés les programmes de l'application). Cette démarche permet donc de mesurer et établir en amont, les seuils de performance acceptables et/ou les intervalles (In) de consommation pour chaque ressource et par application, de sorte à obtenir des seuils de performance et 30 des intervalles de consommation au plus proche de la phase de production 3061570 14 informatique et garantir une détection optimale de dégradations de performance applicative. Dans certains modes de réalisation, la mesure des niveaux d'utilisation pour établir et mémoriser les seuils (Smin, Sint, Smax) de performance 5 acceptable et/ou les intervalles (In) de consommation pour chaque ressource et par application, peut également être réalisée dans un environnement informatique de production, de sorte à redéfinir et affiner ces différents seuils de performance et d'intervalles de consommation préétablis et mémorisés dans le référentiel d'utilisation. Cette démarche permet de surveiller 10 l'évolution des seuils de performance pour chaque ressource d'une application de la chaîne applicative, de remesurer et ré-établir pour obtenir une calibration optimale des seuils de performance et des intervalles de consommation pour chaque ressource et pour chaque application, pour pouvoir mettre en oeuvre des actions correctives en fonction de l'évolution de 15 la dégradation ou non de la performance applicative. Dans certains modes de réalisation, comme représenté par exemple sur la figure 1, le référentiel d'utilisation (2) comprend au moins un agencement matériel et logiciel permettant d'établir et mémoriser dans au 20 moins une mémoire les niveaux d'utilisation réel (21) et théorique (22) par les différents seuils (Smin, Sint, Smax) pour chaque ressource. Dans ce cas, on mémorisera un triplet (Nui, Ai, Rp) ou un doublet ( Nui, Nurp) pour l'interaction LrRpSi: - dans une mémoire (21), la liste des niveaux d'utilisation réels NumrR; 25 pour chaque seuil (Smin, Sint, Smax) de chaque ressource R1; - dans une mémoire (22), la liste des niveaux d'utilisation théoriques NumtRq pour chaque seuil (Smin, Sint, Smax) de chaque ressource Rq. Les niveaux d'utilisation théoriques de chaque ressource sont obtenus, par exemple et de manière non limitative, en fonction d'abaques 30 concernant des infrastructures similaires (exemple: débit réseau ou disque). 3061570 15 Quant aux niveaux d'utilisation réels de chaque ressource, ils sont obtenus, par exemple et de manière non limitative, en analysant les résultats des différentes sondes sur les différentes périodes. 5 Dans certains modes de réalisation, le référentiel de mesure (1) comprend un agencement matériel et logiciel permettant la mesure par des sondes de consommation et de mémoriser dans une mémoire (11) des niveaux d'utilisation « saisonnier » des ressources ou des applications ayant de fortes variations d'utilisation, de sorte à établir et mémoriser des seuils 10 « saisonniers » (Smin, Sint, Smax) de performance acceptable du niveau d'utilisation, dans une mémoire (23) du référentiel d'utilisation (2) par ressource et par application. Dans ce cas, on mémorisera un triplet (Nui, Ai, R') ou un doublet ( Nui, Nurp) pour l'interaction LrR,Si: - dans une mémoire (21), la liste des niveaux d'utilisation réels NumrR; 15 pour chaque seuil (Smin, Sint, Smax) de chaque ressource R1; - dans une mémoire (22), la liste des niveaux d'utilisation théoriques NumtRq pour chaque seuil (Smin, Sint, Smax) de chaque ressource Rq; - dans une mémoire (23) la liste des niveaux d'utilisation réels NumsR0 pour chaque seuil (Smin, Sint, Smax) de chaque ressource R,. 20 Les niveaux d'utilisation saisonniers de chaque ressource sont obtenus, par exemple et de manière non limitative, en analysant les différentes sondes pendant un cycle complet d'utilisation pour chaque ressource de chaque application (par exemple une période d'un mois, d'un trimestre ou d'un an selon la variabilité d'utilisation de la ressource ou de 25 l'application). Le listage de ces paramètres permet de pouvoir réaliser les comparaisons des niveaux mesurés d'utilisation de ressources sur le ou les applications (ou serveurs) composant la chaîne applicative, avec les seuils (Smin, Sint, Smax) de performance acceptable du référentiel d'utilisation (2) 30 en fonction de la ressource, de l'application et du type d'utilisation 3061570 16 (utilisations réel, théorique et/ou saisonnier). Cette comparaison s'effectue sur des périodes Pdp; durant lesquelles les problèmes de performance se produisent avec des périodes Pndp; sans problèmes de performances. L'objectif est de vérifier que la ressource a atteint un niveau d'utilisation ou 5 de consommation anormale ou proche du niveau maximum, et mettre en place un mécanisme d'alerte sur ce niveau d'utilisation de la ressource de l'application, de sorte à pouvoir corriger le comportement anormals des ressources de applications de la chaîne applicative. La réalisation de ces analyses comparatives des performances applicatives de façon automatique 10 permet, ainsi, de réduire le temps des incidents en production. Dans certains modes de réalisation, le système comprend aussi un module de catégorisation (3) des problèmes de performance en fonction des référentiels de mesure (1) et d'utilisation (2). 15 Le module de catégorisation (3) des problèmes de performance comprend au moins un agencement matériel et logiciel (30) permettant de constituer une catégorisation par une opération : - de création d'une catégorie « consommations ressources» mémorisée dans une mémoire (31) et comprenant la consommation totale d'un 20 niveau d'utilisation mesuré pour chaque ressource et chaque application de la chaîne applicative, ou - de comparaison d'un niveau d'utilisation mesuré d'une ressource disponible dans le référentiel de mesure avec le seuil maximal de performance acceptable du niveau d'utilisation de chaque ressource 25 d'une application disponible dans le référentiel d'utilisation afin de créer une catégorie « anomalie matérielle », mémorisée dans une mémoire (32), lorsque le niveau d'utilisation mesuré est au dessus du seuil maximum de la ressource, ou - de comparaison d'un niveau d'utilisation mesuré d'une ressource 30 disponible dans le référentiel de mesure dans l'intervalle (In) de 3061570 17 consommation acceptable du niveau d'utilisation de chaque ressource d'une application disponible dans le référentiel d'utilisation, afin de créer une catégorie « dégradation performance applicative », mémorisée dans une mémoire (33), lorsque le niveau d'utilisation 5 mesuré est hors de l'intervalle (In) de consommation acceptable de la ressource, ou de calcul des « consommations futures » de dégradation de performance par ressource et par application, à partir de l'association d'une règle de saisonnalité des besoins en ressources d'une 10 application avec le niveau d'utilisation mesuré de la ressource de l'application disponibles dans le référentiel de mesure, mémorisé dans une mémoire (34) , ou de comparaison d'un résultat de calcul des consommations futures d'une ressource avec un seuil maximum de performance acceptable 15 du niveau d'utilisation de chaque ressource d'une application disponible dans le référentiel d'utilisation, afin de créer une catégorie « prévention performance applicative », mémorisée dans une mémoire (35), lorsque le résultat du calcul des consommations futures de la ressource est au dessus du seuil maximum de performance 20 acceptable de la ressource d'une application, ou par la combinaison d'au moins deux des opérations ci-dessus. La création d'une catégorie « consommations ressources » dans une mémoire (31) (par exemple : 10 réseau ou disques) s'effectue en utilisant une règle qui consiste à catégoriser ou classer en « consommations 25 ressources » toute ressource R1 dont les niveaux d'utilisation Nuri sont identifiés sur les différents applications (Ak, Al,...) composant la chaîne applicative, l'identifiant de ladite ressource R1 étant stockée dans la mémoire (31) dédiée aux «consommations ressources ». Cette création est réalisée au moyen des interactions entre les ressources des applications disponibles 30 dans la mémoire du référentiel de mesure (1) afin de créer, par ressource et par application, un niveau d'utilisation général NuGri de ladite ressource R1. 3061570 18 Le niveau d'utilisation général NuGr; est obtenu en effectuant la somme INurAi totale de tous les niveaux Nur; d'une ressource utilisée sur chaque application A, et représente la consommation totale mesurée de la ressource R1sur une application donnée de la chaîne applicative. 5 La création d'une catégorie « anomalie matérielle » dans la mémoire (32) s'effectue par l'utilisation de la règle suivante : lorsque les niveaux mesurés d'utilisation des ressources Nur; ont atteints ou dépassés le seuil maximal de performance acceptable des niveaux d'utilisation réels NumrR1 et/ou théoriques NumtR1 et/ou saisonniers NumsR1 pour chaque ressource R1 10 disponible dans le référentiel d'utilisation (2), le système créé l'anomalie suite, par exemple, à la saturation d'une ressource d'une application de la chaîne applicative. La création d'une catégorie « dégradation performance applicative » dans une mémoire (33), s'effectue par l'utilisation de la règle suivante : 15 lorsque les niveaux mesurés d'utilisation des ressources Nur; sont hors de leur intervalle de consommation des niveaux d'utilisation pour chaque ressource R1 disponible dans le référentiel d'utilisation (2). Ceci est le cas, par exemple, lors d'un comportement anormal d'une ressource d'une application de la chaîne applicative (tel qu'une application hors d'usage ou 20 un problème sur une instance des cluster entraînant une dégradation des SLA, etc.). La création d'une catégorie « consommations futures » dans une mémoire (34), s'effectue à partir des règles dites de « saisonnalité » et le niveau d'utilisation actuel des ressources. On notera que le niveau 25 d'utilisation d'une ressource ou d'une application peut varier dans le temps (par exemple, un ou plusieurs moments de la journée, de la semaine, du mois ou de l'année), entraînant des variations du niveau d'utilisation des ressources sur les différentes applications composant la chaîne applicative. Par exemple, certaines applications peuvent être moins sollicitées le 30 mercredi, ce qui peut s'expliquer par les congés hebdomadaires habituels des personnes à temps partiel. Autre exemple non limitatif, les applications 3061570 19 financières connaissent généralement de fort niveaux d'utilisation en période de clôture mensuelle ou trimestrielle. Ainsi, l'ensemble des évolutions de l'utilisation d'une application peut être défini par des règles de saisonnalités qui sont variables selon l'application (notamment dû au comportement des 5 utilisateurs de l'application et des activités métiers) et évolutives dans le temps. Ceci explique la nécessité de recourir à un système permettant de surveiller et alerter, de façon automatique et en continue, les problèmes de performance applicative d'un système d'information. La création d'une catégorie « prévention performance applicative » 10 dans une mémoire (35), s'effectue par l'utilisation de la règle suivante : lorsque les résultats du calcul des consommations futures à partir des niveaux mesurés d'utilisation des ressources Nuri montrent un risque de saturation de l'application. Par exemple et non limitativement, si les règles de saisonnalités pour une ressource tel qu'un CPU prévoient qu'à une période 15 Po+60M (m définissant une durée quelconque), le niveau d'utilisation (c'est- à-dire la consommation future) de la ressource sera de 3,2 fois plus importante qu'à la période donnée Po. De ce fait, si à une période Po, le niveau mesuré d'utilisation de la ressource d'un CPU est de 26% de la taille totale du CPU. Le résultat de la consommation future pour cette ressource, 20 obtenu par une multiplication du niveau d'utilisation mesuré par la prévision des règles de saisonnalité (selon la règle de saisonnalité à la date Dt= Po+60m, le 26% du niveau d'utilisation est multiplié par 3,2 et donnant un résultat de 83,2% de la taille totale du CPU), sera importante montrant un risque de saturation et une alerte sera mise en place pour pouvoir corriger le 25 problème de saturation du CPU (par exemple, en augmentant la mémoire du CPU). Dans certains modes de réalisation, le système comprend également un agencement matériel et logiciel informatique (40) permettant de mettre en 30 oeuvre un mécanisme d'alerte (4) lorsque le mécanisme de surveillance 3061570 20 détecte un problème de performance d'une ou plusieurs applications dans la chaîne applicative ou lorsque le problème est résolu. Le mécanisme d'alerte permet de créer et mémoriser dans au moins une mémoire (41, 42, 43) au moins une ou plusieurs des alertes ci-après : 5 - une alerte « anomalie matérielle » lorsque le niveau d'utilisation d'une ressource d'une application disponible dans le référentiel de mesure, est au dessus d'un seuil maximal de performance acceptable de ladite ressource disponible dans le référentiel d'utilisation ; - une alerte « dégradation performance applicative » lorsque le niveau 10 d'utilisation d'une ressource d'une application disponible dans le référentiel de mesure, est hors de l'intervalle (In) de consommation acceptable de ladite ressource disponible dans le référentiel d'utilisation ; - une alerte « préventive performance applicative » lorsque le résultat 15 de calcul des consommations futures d'une ressource d'une application disponible dans la mémoire du module de catégorisation, est au dessus d'un seuil maximal de performance acceptable de ladite ressource disponible dans le référentiel d'utilisation. L'alerte « anomalie matérielle » est mémorisée dans une mémoire 20 (41), lorsqu'un niveau d'utilisation en production est anormal, de sorte à mettre en place une action correctrice. Cette action correctrice permet généralement de modifier la configuration hardware ou software de la machine informatique virtuelle ou physique, telle que par exemple et non limitativement, augmenter la mémoire ou le processeur, libérer de l'espace 25 du disque (par ajout d'espace ou par suppression de fichier, etc.). L'alerte « dégradation performance applicative » est mémorisée dans une mémoire (42), lorsqu'une dégradation de performance sur la chaîne applicative est détectée, de sorte à mettre en place une action correctrice adéquate. Cette action correctrice permet généralement de surveiller le ou 30 les applications pour déterminer l'origine du problème, telle que par exemple 3061570 21 et non limitativement, une application hors service, un problème sur une instance de cluster qui entraine une dégradation des SLA, etc. Cette alerte est mise en place lorsque le niveau mesuré d'utilisation d'une ressource est hors de l'intervalle (In) de consommation acceptable de cette ressource 5 préétablie et mémorisé dans le référentiel d'utilisation du système. Cet intervalle peut être établi à partir des mesures antérieures des niveaux d'utilisation pour chaque ressource d'une application, ou à partir d'un intervalle de consommation acceptable du niveau d'utilisation par ressource et par application. 10 L'alerte « préventive performance applicative » est mémorisée dans une mémoire (43), lorsque le système a pour objectif de prévenir et anticiper un problème futur, de sorte à mettre en place des préconisations d'évolution de performance pour la ou les ressources concernées. Ainsi, s'agissant d'anticiper la consommation future des ressources des applications, un 15 programme correcteur sera mis en place dans un délai tardif. Cette configuration permet donc de gagner du temps pour pouvoir mettre en place un programme correcteur optimal qui limitera et corrigera les problèmes de performance applicative. Dans certains modes de réalisation, le système comprend un 20 agencement matériel et logiciel comprenant un programme de correction (5). En effet, comme représenté par exemple sur les figures 1 et 2, les différents types d'alertes sont analysés par un programme de traitement pour pouvoir mettre en place le programme de correction (5) adéquat selon l'alerte détectée par le système. 25 Dans certains modes de réalisation, le système est apte à surveiller et alerter en continu une anomalie sur une ou plusieurs applications de la chaîne applicative, ou une dégradation de la performance sur la chaîne applicative due à une surconsommation de ressources critiques pour l'application ou d'une future surconsommation de ressources. 3061570 22 Comme par exemple représenté sur la figure 2, le mécanisme de surveillance permet de collecter des mesures des niveaux d'utilisation pour chaque ressource et par application qui seront catégorisées et stockées dans la mémoire (31) du module de catégorisation (3), afin d'identifier les 5 problèmes de performance : - par comparaison avec les seuils (Smin, Sint, Smax) de performance établis précédemment pour chaque ressource et pour chaque application, en particulier, une ressource qui aura atteint le seuil maximum de performance, va être catégorisé et mémorisé dans la 10 mémoire (32) du module de catégorisation (3) par le système; ou - par comparaison avec les intervalles (In) de consommation préétablis pour chaque ressource et pour chaque application, en particulier, une ressource qui sera hors de son intervalle de consommation acceptable, va être catégorisé et mémorisé dans la mémoire (33) du 15 module de catégorisation (3) par le système; ou - en calculant les consommations futures pour chaque ressource et pour chaque application, en particulier, une ressource qui aura un risque de problème de performance, va être catégorisé et mémorisé dans la mémoire (34) du module de catégorisation (3) par le système. 20 Lorsque le niveau d'utilisation est anormal, le système permet de mettre en place des leviers d'amélioration grâce à des alertes automatiques et en continues. Ainsi, en fonction du problème de performance détecté, le système met en place un mécanisme d'alerte (4) et un programme de correction (5) adapté. Par exemple, lorsque le module de catégorisation (3) 25 indique que le niveau mesuré d'utilisation d'une ressource a atteint son seuil maximum de performance acceptable, le mécanisme d'alerte établi une alerte « anomalie matérielle » dans la mémoire (41) permettant de mettre en place un programme de correction adapté sur ladite ressource. Lorsque le module de catégorisation (3) indique que le niveau d'utilisation d'une 30 ressource est hors de l'intervalle de consommation acceptable, le 3061570 23 mécanisme d'alerte établi une alerte « dégradation performance applicative » dans la mémoire (42) permettant de mettre en place un programme de correction adapté sur ladite ressource. Enfin, lorsque le module de catégorisation (3) indique que le niveau d'utilisation d'une ressource présente 5 un risque de dégradation, par exemple une saturation de ressource, le mécanisme d'alerte établi une alerte « préventive performance applicative » dans la mémoire (43) permettant de mettre en place un programme de correction adapté sur ladite ressource. 10 La présence invention concerne également un procédé de surveillance des performances des applications d'une chaîne applicative et de commande d'un système selon un des modes de réalisation de la présente demande. Le procédé comprenant : - une étape de mesure et de mémorisation du niveau d'utilisation des 15 ressources pour chaque application de la chaîne applicative pour pouvoir caractériser les différents niveaux de consommation de ressources ; - une étape de mesure et de mémorisation des besoins en ressources des différents composants d'une application ; 20 - une étape de construction d'un référentiel d'utilisation (2) à partir des données obtenues dans les étapes de mesure et de mémorisation des niveaux d'utilisation des ressources et des besoins en ressources des applications, de sorte à établir un seuil minimum (Smin), un seuil maximum (Smax) et un seuil intermédiaire (Sint) pour chaque 25 ressource mesurée et pour chaque application; - une étape de catégorisation et de mémorisation des problèmes de performance d'une ou plusieurs ressources à partir du référentiel d'utilisation (2) et des données obtenues dans les étapes de mesure et de mémorisation des niveaux d'utilisation des ressources et des 30 besoins en ressources des applications de la chaîne applicative ; 3061570 24 - une étape de comparaison des niveaux d'utilisation mesurés avec les seuils de performance acceptable à partir des problèmes de performance de l'étape de catégorisation ; - une étape de mise en place d'une alerte des problèmes de 5 performance à partir des données obtenues dans l'étape de comparaison, de sorte à corriger le ou les problèmes de performance en modifiant la chaîne applicative ou les ressources d'une application de la chaîne applicative. Dans certains modes de réalisation, l'étape de comparaison des 10 niveaux d'utilisation mesurés avec les seuils de performance acceptable, est réitérée continuellement de sorte à surveiller et alerter en continu les applications de la chaîne applicative. Comme représenté par exemple sur la figure 2, les mesures des niveaux d'utilisation pour chaque ressource par application et par 15 saisonnalité de la chaîne applicative du référentiel de mesure (1), sont catégorisées et mémorisées dans la mémoire (31) du module de catégorisation (3). Ces mesures sont comparées soit avec les seuils de performance acceptable, soit avec les intervalles de consommation acceptable préétablis, qui ont été préétablis pour chaque ressource et par 20 application, pour surveiller et alerter les DSI des problèmes de performance applicative sur la chaîne applicative. Ces mesures des niveaux d'utilisation du référentiel de mesure (1) sont comparées en trois différentes étapes : - tout d'abord, une première étape dans laquelle le niveau mesuré est comparé avec le seuil maximal (Smax) de performance du référentiel 25 d'utilisation (2), une alerte (41) anomale applicative sera mise en place par le système lorsque le niveau d'utilisation a atteint son seuil maximum de performance ; - ensuite, si la première étape ne révèle pas d'anomalie, alors dans une seconde étape, le niveau d'utilisation est comparé avec l'intervalle (In) 30 de consommation du référentiel d'utilisation (2), une alerte (42) « dégradation 3061570 25 performance applicative » sera mise en place par le système lorsque le niveau d'utilisation est hors de son intervalle de consommation ; - puis, si la deuxième étape ne révèle pas de dégradation de performance, alors dans une troisième étape, un calcul de consommation 5 future est réalisé à partir du niveau d'utilisation mesurés, une alerte (43) « préventive performance applicative » sera mise en place par le système lorsque la mesure du niveau d'utilisation indique un risque de saturation de ressource; - enfin, si la troisième étape ne révèle pas de risque de saturation de 10 ressource, alors une nouvelle mesure du niveau d'utilisation sera réalisée afin de surveiller et alerter automatiquement et régulièrement lorsqu'un problème de performance intervient dans la chaîne applicative. Ces différentes étapes du procédé sont donc réalisées continuellement de façon automatique, pour pouvoir optimiser le pilotage des 15 opérations informatiques en limitant ou sans problèmes de performance dans le système informatique. Le procédé de surveillance des performances applicatives de la présente invention, présente l'avantage d'identifier rapidement et automatiquement les dégradations de performance applicative et de mettre en place un plan d'amélioration continue et adapté pour chaque 20 application du système informatique de l'entreprise. La présente demande décrit diverses caractéristiques techniques et avantages en référence aux figures et/ou à divers modes de réalisation. 25 L'homme de métier comprendra que les caractéristiques techniques d'un mode de réalisation donné peuvent en fait être combinées avec des caractéristiques d'un autre mode de réalisation à moins que l'inverse ne soit explicitement mentionné ou qu'il ne soit évident que ces caractéristiques sont incompatibles ou que la combinaison ne fournisse pas une solution à au 30 moins un des problèmes techniques mentionnés dans la présente demande. 3061570 26 De plus, les caractéristiques techniques décrites dans un mode de réalisation donné peuvent être isolées des autres caractéristiques de ce mode à moins que l'inverse ne soit explicitement mentionné. Il doit être évident pour les personnes versées dans l'art que la 5 présente invention permet des modes de réalisation sous de nombreuses autres formes spécifiques sans l'éloigner du domaine d'application de l'invention comme revendiqué. Par conséquent, les présents modes de réalisation doivent être considérés à titre d'illustration, mais peuvent être modifiés dans le domaine défini par la portée des revendications jointes, et io l'invention ne doit pas être limitée aux détails donnés ci-dessus. REVENDICATIONS1. Système de surveillance des performances des applications d'une chaîne applicative comprenant au moins une machine informatique et un logiciel ou code exécutable par la machine pour mettre en oeuvre un mécanisme de surveillance desdites performances des applications d'une chaîne applicative, ledit système comprenant un agencement matériel et logiciel d'informatique formant un référentiel de mesure (1) permettant, d'une part, la mesure par des sondes de consommation installées sur des ressources pour mesurer des niveaux d'utilisation des ressources des applications lors des périodes de dégradation des performances d'une ou plusieurs application(s) de la chaîne applicative, et d'autre part, la mémorisation, par application et par période de la chaîne applicative, dans une mémoire (11) de ces niveaux d'utilisation dans le référentiel de mesure (1) ; ledit système étant caractérisé en ce que l'agencement matériel et logiciel du système est apte en outre à : - établir un référentiel d'utilisation (2) des données du référentiel de mesure en définissant et mémorisant dans au moins une mémoire (21, 22, 23), par ressource et par application, des seuils (Smin, Sint, Smax) de performance acceptables du niveau d'utilisation ; - constituer un module de catégorisation (3) des problèmes de performance en fonction des référentiels de mesure (1) et d'utilisation (2) ; et mettre en oeuvre un mécanisme d'alerte (4) lorsque ledit mécanisme de surveillance détecte un problème de performance d'une ou plusieurs applications dans la chaîne applicative ou lorsque le problème est résolu. 2. Système selon la revendication 1, caractérisé en ce que les seuils (Smin, Sint, Smax)-de performance acceptable du niveau d'utilisation, comprennent trois seuils acceptables formant un triplet et constitué d'un seuil minimal (Smin), un seuil maximal (Smax) et un seuil intermédiaire (Sint) ; ce 3061570 2 triplet de seuils (Smin, Sint, Smax) étant mémorisé pour chaque ressource et pour chaque application de la chaîne applicative. 3. Système selon l'une des revendications 1 à 2, caractérisé en ce que le référentiel d'utilisation (2) comprend au moins un agencement matériel s et logiciel (20) permettant d'établir et mémoriser dans une mémoire (24), des intervalles (In) de consommation acceptable définis à partir des mesures du niveau d'utilisation du référentiel de mesure (1). 4. Système selon l'une des revendications 1 à 3, caractérisé en ce que le mécanisme de surveillance est apte à comparer le niveau d'utilisation 10 des ressources, mesuré et mémorisé dans le référentiel de mesure (1) avec les seuils (Smin, Sint, Smax) et/ou des intervalles (In) de consommation établis dans le référentiel d'utilisation (2) par application. 5. Système selon l'une des revendications 1 à 4, caractérisé en ce que le référentiel d'utilisation (2) comprend au moins un agencement matériel 15 et logiciel (20) permettant d'établir et mémoriser dans une mémoire les niveaux d'utilisation réel (21) et théorique (22) par seuil (Smin, Sint, Smax) pour chaque ressource. 6. Système selon l'une des revendications 1 à 5, caractérisé en ce que les sondes de consommation des ressources mesurent plusieurs fois 20 les niveaux d'utilisation des ressources des applications, de sorte à caractériser les différents niveaux de consommation ou d'utilisation des ressources des applications par l'agencement matériel et logiciel dans le référentiel d'utilisation (2). 7. Système selon l'une des revendications 1 à 6, caractérisé en ce 25 que la mesure des niveaux d'utilisation des ressources des applications par les sondes de consommation des ressources, est réalisée dans un environnement informatique de pré-production ou de qualification. 8. Système selon l'une des revendications 3 à 7, caractérisé en ce que la mesure des niveaux d'utilisation des ressources des applications par 30 les sondes de consommation des ressources, est également réalisée dans 3061570 3 un environnement informatique de production, de sorte à affiner, si nécessaire, les seuils (Smin, Sint, Smax) de performance acceptable du niveau d'utilisation et/ou les intervalles (In) de consommation pour chaque ressource et par application. 5 9. Système selon l'une des revendications 1 à 7, caractérisé en ce que le référentiel de mesure (1) comprend un agencement matériel et logiciel permettant la mesure par des sondes de consommation et la mémorisation dans une mémoire (23) des niveaux d'utilisation « saisonnier » des ressources ou des applications ayant de fortes variations saisonnières 10 d'utilisation, de sorte à établir et mémoriser des seuils « saisonniers » (Smin, Sint, Smax) de performance acceptable du niveau d'utilisation par ressource et par application. 10. Système selon l'une des revendications 3 à 9, caractérisé en ce que le module de catégorisation (3) des problèmes de performance 15 comprend au moins un agencement matériel et logiciel permettant d'établir une catégorisation par une opération : de création d'une catégorie « consommations ressources» mémorisée dans une mémoire (31) et comprenant la consommation totale d'un niveau d'utilisation mesuré pour chaque ressource et chaque 20 application de la chaîne applicative, ou de comparaison d'un niveau d'utilisation mesuré d'une ressource disponible dans le référentiel de mesure (1) avec le seuil maximal (Smax) de performance acceptable du niveau d'utilisation de chaque ressource d'une application disponible dans le référentiel d'utilisation 25 (2) afin de créer une catégorie « anomalie matérielle », mémorisée dans une mémoire (32), lorsque le niveau d'utilisation mesuré est au dessus du seuil maximum (Smax) de la ressource, ou de comparaison d'un niveau d'utilisation mesuré d'une ressource disponible dans le référentiel de mesure (1) avec l'interval : (In) de 30 consommation acceptable du niveau d'utilisation pour chaque ressource d'une application disponible dans une mémoire (24) du 3061570 4 référentiel d'utilisation (2), afin de créer une catégorie « dégradation performance applicative », mémorisée dans une mémoire (33), lorsque le niveau d'utilisation mesuré est hors de l'intervalle (In) de consommation acceptable de la ressource, ou s - de calcul des consommations futures de dégradation de performance par ressource et par application, à partir de l'association d'une règle de saisonnalité des besoins en ressources d'une application avec le niveau d'utilisation mesuré de la ressource de l'application disponibles dans le référentiel de mesure (1), mémorisé dans une mémoire (34), 10 ou - de comparaison d'un résultat de calcul des consommations futures d'une ressource avec un seuil maximum de performance acceptable du niveau d'utilisation de chaque ressource d'une application disponible dans le référentiel d'utilisation (2), afin de créer une 15 catégorie « prévention performance applicative », mémorisée dans une mémoire (35), lorsque le résultat du calcul des consommations futures de la ressource est au dessus du seuil maximum de performance acceptable de la ressource d'une application, ou de combinaison d'au moins deux des opérations ci-dessus. 20 11. Système selon l'une des revendications 3 à 10, caractérisé en ce que ledit système comprend un agencement matériel et logiciel informatique (40) pour mettre en oeuvre le mécanisme d'alerte (4) en créant et mémorisant dans au moins une mémoire (41, 42, 43) au moins une ou plusieurs des alertes ci-après : 25 - une alerte « anomalie matérielle » lorsque le niveau d'utilisation d'une ressource d'une application disponible dans le référentiel de mesure (1), est au dessus d'un seuil maximal (Smax) de performance acceptable de ladite ressource disponible dans le référentiel d'utilisation (2); 30 une alerte « dégradation performance applicative » lorsque le niveau d'utilisation d'une ressource d'une application disponible dans le 3061570 5 référentiel de mesure (1), est hors de l'intervalle (In) de consommation acceptable de ladite ressource disponible dans le référentiel d'utilisation (2); une alerte « préventive performance applicative » lorsque le résultat 5 de calcul des consommations futures d'une ressource d'une application disponible dans la mémoire du module de catégorisation (3), est au dessus d'un seuil maximal (Smax) de performance acceptable de ladite ressource disponible dans le référentiel d'utilisation (2). 10 12. Système selon l'une des revendications 1 à 11, caractérisé en ce que le système est apte à surveiller et alerter en continu d'une anomalie sur une ou plusieurs applications de la chaîne applicative, ou d'une dégradation de la performance sur la chaîne applicative due à une surconsommation de ressources critiques pour l'application ou d'une future 15 surconsommation de ressources. 13. Procédé de surveillance des performances des applications d'une chaîne applicative et de commande d'un système selon une des revendications 2 à 12, le procédé comprenant : une étape de mesure et de mémorisation du niveau d'utilisation des 20 ressources pour chaque application de la chaîne applicative pour pouvoir caractériser les différents niveaux de consommation de ressources ; le procédé étant caractérisé en ce qu'il comprend en outre : une étape de mesure et de mémorisation des besoins en ressources 25 des différents composants d'une application ; une étape de construction d'un référentiel d'utilisations (2) à partir des données obtenues dans les étapes de mesure et de mémorisation des niveaux d'utilisation des ressources et des besoins en ressources des applications, de sorte à établir un seuil minimum (Smin), un seuil 30 maximum (Smax) et un seuil intermédiaire (Sint) pour chaque ressource mesurée et pour chaque application; 3061570 - 6 une étape de catégorisation et de mémorisation des problèmes de performance d'une ou plusieurs ressources à partir du référentiel d'utilisation (2) et des données obtenues dans les étapes de mesure et de mémorisation des niveaux d'utilisation des ressources et des 5 besoins en ressources des applications de la chaîne applicative ; une étape de comparaison des niveaux d'utilisation mesurés avec les seuils (Smin, Sint, Smax) de performance acceptable à partir des problèmes de performance de l'étape de catégorisation ; - une étape de mise en place d'une alerte des problèmes de 10 performance à partir des données obtenues dans l'étape de comparaison, de sorte à corriger le ou les problèmes de performance en modifiant la chaîne applicative ou les ressources d'une application de la chaîne applicative. 14. Procédé selon la revendication 13, caractérisé en ce que 15 l'étape de comparaison des niveaux d'utilisation mesurés avec les seuils (Smin, Sint, Smax) de performance acceptable, est réitérée continuellement de sorte à surveiller et alerter en continu les applications de la chaîne applicative.