Brevet FR3067480A1 — publié le 20181214

PROCEDE ET SYSTEME DE PREDICTION DE L'IMPACT D'UN DYSFONCTIONNEMENT RESSOURCE SUR LE NIVEAU DE SERVICE D'UNE CHAINE APPLICATIVE [0001] L'invention concerne le domaine de la surveillance des performances de chaines applicatives. L'invention concerne plus particulièrement un procédé de prédiction automatique de l'impact d'un dysfonctionnement d'une ressource, sur un niveau de service d'au moins une chaine applicative. L'invention concerne également un système informatique capable de supporter la mise en oeuvre d'un tel procédé. [Art antérieur [0002] Au fil des années, l'utilisation des systèmes informatiques s'accroit avec des scénarios d'utilisation de plus en plus complexes, des chaines applicatives de plus en plus nombreuses et faisant appel à de nombreuses ressources informatiques pouvant faire l'objet de dysfonctionnement. Or, les directions métiers demandent désormais au directeur des systèmes d'information (DSI) de s'engager sur des niveaux de service (ou SLA pour « Service-level agreement ») pour l'ensemble des chaines applicatives relatives à leurs applications métiers. [0003] Dans ce contexte, il existe de nombreuses méthodes pour évaluer le respect des SLA. Par exemple, le brevet US8209273 décrit un procédé d'évaluation et de classement de niveau de service comportant une étape de prédiction de l'importance de la violation d'un SLA pouvant être basé notamment sur la fréquence d'occurrence et l'ancienneté du problème. De même, il existe des outils de surveillance permettant de monitorer le ressenti utilisateur, mais ces outils ne permettent pas d'établir un lien entre un incident matériel, ou dysfonctionnement, sur la chaine de liaison et une dégradation des performances de la chaine applicative, puis de déterminer l'impact du dysfonctionnement sur les SLAs devant être respectées. [0004] De même, s'il existe des outils de surveillance permettant de monitorer les différents équipements du système d'information (e.g. FR2985335), il n'y a pas de vision applicative permettant de savoir quel est l'impact d'un dysfonctionnement au niveau d'une ressource d'un équipement informatique, sur le niveau de service des chaines applicatives concernées. 2 [0005] Ainsi, il n'existe pas de procédé permettant de rapidement évaluer l'impact d'un dysfonctionnement matériel sur le niveau de SLA d'une chaine applicative. En effet, considérant la multiplicité des chaines applicatives d'un côté et des ressources d'un autre côté, les outils actuels de surveillance des infrastructures ne permettant pas d'avoir une vision 5 applicative de cette infrastructure. Il est donc impossible avec les outils actuels de mesurer ou de prédire les impacts d'un incident matériel ou d'une contention au niveau d'une ressource sur le niveau de SLA des applications métiers et donc de pouvoir faire un rapport prédisant l'impact d'un dysfonctionnement (e.g. incident matériel ou contention) sur le niveau de SLA des différentes applications métiers du système d'information. 10 [0006] Ainsi, il existe un besoin pour de nouveaux procédés et systèmes visant à automatiser l'analyse et la prédiction de l'impact des dysfonctionnements subis par des systèmes informatiques. 'Problème technique' 15 [0007] L'invention a donc pour but de remédier aux inconvénients de l'art antérieur. En particulier, l'invention a pour but de proposer un procédé de prédiction de l'impact d'un dysfonctionnement d'une ressource sur le niveau de service d'une chaine applicative, ledit procédé permettant de rapidement informer la direction des systèmes d'information, la direction métier ou les utilisateurs d'un dysfonctionnement détecté sur une ressources 20 pouvant impacter une ou plusieurs chaines applicatives. En outre, le procédé est capable de fournir une prédiction de la sévérité de cet impact. Enfin, ce procédé est en mesure de progresser au fur et à mesure de la survenue de dysfonctionnements de façon à améliorer la justesse de sa prédiction. L'invention a en outre pour but de proposer un système informatique susceptible de mettre en oeuvre le procédé de prédiction de l'impact d'un 25 dysfonctionnement ressource sur le niveau de service d'une chaine applicative. "Brève description de l'invention' [0008] A cet effet, l'invention porte sur un procédé de prédiction automatique de l'impact d'un dysfonctionnement affectant une ressource, sur un niveau de service d'au moins une chaine applicative utilisant des ressources, ledit procédé étant caractérisé en ce que lesdites ressources sont associées à un niveau prédéterminé d'utilisation courante et à un seuil 3 prédéterminé d'utilisation maximum, en ce qu'il comporte l'utilisation d'au moins une sonde configurée pour collecter des données, et en ce qu'il comporte les étapes suivantes : - Collecter les données de ladite sonde, lesdites données collectées comportant des données relatives à l'état de fonctionnement des ressources ; 5 - Détecter un dysfonctionnement sur au moins une ressource, à partir des données de sonde collectées ; - En présence d'un dysfonctionnement, quantifier l'impact présumé dudit dysfonctionnement sur le niveau de service d'au moins une chaine applicative, comportant les sous étapes suivantes : 10 - Calculer un nouveau seuil d'utilisation maximum en fonction du seuil prédéterminé d'utilisation maximum et des données relatives à l'état de fonctionnement des ressources, - Comparer le nouveau seuil d'utilisation maximum de la ressource au niveau prédéterminé d'utilisation courante de ladite ressource, de façon à déterminer si le 15 nouveau seuil d'utilisation maximum est dépassé par le niveau prédéterminé d'utilisation courante, - Si le nouveau seuil d'utilisation maximum est dépassé alors, - Calculer une valeur de sévérité présumée d'impact du dysfonctionnement sur le niveau de service d'au moins une chaine applicative, 20 - Générer un signal d'alerte applicative comportant la valeur de sévérité présumée d'impact du dysfonctionnement sur le niveau de service d'au moins une chaine applicative. [0009] Ce procédé permet de prévoir l'impact d'un dysfonctionnement, au niveau d'une ressource d'un équipement, sur le niveau de SLA des chaines applicatives et d'établir un 25 rapport concernant le niveau de SLA des différentes applications métiers du SI dans le cadre de ce dysfonctionnement. Ainsi, lorsqu'un dysfonctionnement (e.g. incident ou congestion) au niveau des ressources se produit, il est possible de déterminer précisément quelles seront les chaines applicatives qui seront impactées par ce phénomène et de calculer la sévérité présumée de cet incident sur les SLAs de l'application. 30 [0010] Selon d'autres caractéristiques optionnelles du procédé : - il comprend, une étape préalable de génération d'un premier référentiel d'utilisation des ressources, comportant, distinctivement pour chacune des ressources, une valeur 4 correspondant à un niveau d'utilisation d'une ressource par une chaine applicative. Un tel référentiel peut être avantageusement utilisé pour déterminer si une chaine applicative sera ou non impactée par un dysfonctionnement. En effet, cela permet d'identifier rapidement les chaines applicatives n'utilisant pas les ressources ayant 5 subi un dysfonctionnement. - l'étape de calcul de la valeur de sévérité présumée d'impact du dysfonctionnement sur le niveau de service d'au moins une chaine applicative est réalisée à partir de données mémorisées dans le premier référentiel d'utilisation des ressources. 10 - il comporte, en présence d'un dysfonctionnement, une étape d'enregistrement d'une valeur observée d'impact d'un dysfonctionnement sur un niveau de service d'au moins une chaine applicative. Cela permet d'évaluer et de mémoriser l'impact réel d'un dysfonctionnement détecté. Une telle valeur peut ensuite être comparée à la valeur 15 d'impact prédit par le procédé. Avantageusement, la valeur observée d'impact d'un dysfonctionnement sur un niveau de service d'au moins une chaine applicative est enregistré dans un second référentiel d'impact de dysfonctionnement. En effet, un tel référentiel sera en mesure de rassembler un grand nombre de données sur les impacts réels des dysfonctionnements détectés. Ainsi, le second référentiel d'impact 20 de dysfonctionnement comporte des données relatives au niveau de service observé, d'au moins une chaine applicative par exemple en fonction de valeurs relatives aux ressources subissant un dysfonctionnement, lesdites valeurs relatives aux ressources subissant un dysfonctionnement étant sélectionnées parmi des données relatives à l'état de fonctionnement des ressources ou de nouveaux seuils d'utilisation maximum 25 de ressources suite à un dysfonctionnement. - Le procédé comporte, après la détection d'un dysfonctionnement sur au moins une ressource : o une étape de comparaison du dysfonctionnement à un dysfonctionnement 30 antérieur de façon à identifier un dysfonctionnement antérieur identique ou sensiblement identique, et o si un dysfonctionnement antérieur identique ou sensiblement identique est identifié, une étape de génération d'un signal d'alerte applicative comportant une valeur observée d'impact du dysfonctionnement sur le niveau de service d'au moins une chaine applicative. 5 - il comprend une étape de mesure du niveau d'utilisation globale des ressources. [0011] Selon un autre aspect, l'invention porte sur un système informatique de supervision automatique de l'impact d'un dysfonctionnement d'au moins une ressource sur un niveau de 5 service d'au moins une chaine applicative, ledit système informatique comportant au moins une sonde configurée pour collecter des données, ledit système informatique étant caractérisé en ce qu'il comporte : Un module de configuration apte à associer lesdites ressources à un niveau prédéterminé d'utilisation courante et à un seuil prédéterminé d'utilisation 10 maximum, un module d'acquisition apte à collecter, à partir desdites sondes, des données relatives à l'état de fonctionnement des ressources, un module de détection apte à détecter un dysfonctionnement sur au moins une ressource, à partir de données de sonde collectées ; et apte, en présence 15 d'un dysfonctionnement, à transmettre l'information à un module de traitement, un module de traitement de données capable de quantifier l'impact présumé dudit dysfonctionnement sur le niveau de service d'au moins une chaine applicative et apte à o Calculer un nouveau seuil d'utilisation maximum en fonction du seuil 20 prédéterminé d'utilisation maximum et des données relatives à l'état de fonctionnement des ressources, o Comparer le nouveau seuil d'utilisation maximum de la ressource au niveau prédéterminé d'utilisation courante de ladite ressource, de façon à déterminer si le nouveau seuil d'utilisation maximum est dépassé par 25 le niveau prédéterminé d'utilisation courante, et o Si le nouveau seuil d'utilisation maximum est dépassé alors, calculer une valeur de sévérité présumée d'impact du dysfonctionnement sur le niveau de service d'au moins une chaine applicative et à le transmettre à un module de communication, 30 un module de communication de données apte à générer un signal d'alerte applicative comportant la valeur de sévérité présumée d'impact du dysfonctionnement sur le niveau de service d'au moins une chaine applicative. [0012] Avantageusement, ce système informatique comporte en outre : 6 -un premier référentiel d'utilisation des ressources, comportant, distinctivement pour chacune des ressources, une valeur correspondant à un niveau d'utilisation d'une ressource par une chaine applicative, et -un second référentiel d'impact de dysfonctionnement comportant une valeur observée 5 d'impact d'un dysfonctionnement sur un niveau de service d'au moins une chaine applicative en fonction de valeurs relatives aux ressources subissant un dysfonctionnement, lesdites valeurs relatives aux ressources subissant un dysfonctionnement étant sélectionnées parmi des données relatives à l'état de fonctionnement des ressources ou de nouveaux seuils d'utilisation maximum de 10 ressources suite à un dysfonctionnement. [0013] D'autres avantages et caractéristiques de l'invention apparaitront à la lecture de la description suivante donnée à titre d'exemple illustratif et non limitatif, en référence aux Figures annexées qui représentent : 15 - Figure 1, une vue schématique d'un procédé de prédiction automatique de l'impact d'un dysfonctionnement selon l'invention. Les étapes encadrées par des pointillés sont facultatives. - Figure 2, une vue schématique d'une étape de quantification de l'impact présumé dudit dysfonctionnement sur un niveau de service d'au moins une chaine applicative du 20 procédé selon l'invention. Les étapes encadrées par des pointillés sont facultatives. - Figure 3, une vue schématique des éléments du système informatique de prédiction automatique de l'impact de dysfonctionnement selon l'invention. Les éléments encadrés par des pointillés sont facultatifs. 25 'Description de l'invention] [0014] Dans la suite de la description, on entend par « Ressource » ou « Ressource matérielle », des paramètres ou des fonctions de dispositifs informatiques permettant le fonctionnement d'une chaine applicative. Un même dispositif informatique fait appel généralement à plusieurs ressources. De même, une même ressource est généralement 30 partagée entre plusieurs chaines applicatives. Par exemple, le terme « ressource » peut inclure : des disques réseaux caractérisé par exemple par leurs entrées/sorties, un réseau 7 caractérisé par sa bande passante, des ports de communication caractérisés par leur statut (ouvert / fermé), un processeur caractérisé par exemple par son utilisation (en pourcent) ou le taux d'occupation de ses caches, une mémoire vive caractérisée par la quantité allouée, ou de façon plus globale le temps de latence d'un processus ou les pertes de paquets. 5 [0015] L'expression « chaine applicative » au sens de l'invention correspond à un ensemble d'applications, reliées entre elles par un flot d'information et visant à proposer, au travers de plusieurs processus, une ou plusieurs fonctionnalités pouvant faire l'objet d'un accord de niveau de service (SLA). [0016] L'expression « niveau de service » au sens de l'invention correspond à une qualité 10 de service à laquelle peut s'engager un tiers et ainsi garantir de bonnes performances pour les chaines applicatives critiques d'une organisation. Ainsi, le niveau de service ou les valeurs de sévérité (présumée, observée, ou calculée) d'impact du dysfonctionnement peuvent correspondre à des critères objectifs tels que des débits et des temps de réponse par chaine applicative ou bien subjectif, et prendre par exemple la forme d'une échelle de valeur, 15 numérique ou non, correspondant à une appréciation de la qualité du niveau de service. Le niveau de service peut correspondre à une ou plusieurs valeurs. [0017] Le terme « dysfonctionnement » au sens de l'invention correspond à la survenue d'un incident matériel ou d'une congestion sur la structure informatique hébergeant une chaine applicative. 20 [0018] Par « sonde » ou « sonde informatique », on entend au sens de l'invention un logiciel associé à un équipement qui permet d'effectuer, de gérer et faire remonter vers un équipement informatique des mesures destinées à informer entre autres de l'état de fonctionnement des ressources. 25 [0019] Selon un premier aspect, l'invention porte sur un procédé de prédiction automatique de l'impact d'un dysfonctionnement affectant une ressource, sur un niveau de service d'au moins une chaine applicative utilisant des ressources. Une même ressource peut être utilisée par plusieurs chaines applicatives ainsi un seul dysfonctionnement peut avoir des impacts sur plusieurs chaines applicatives. De même, le procédé selon l'invention peut également être 30 utilisé lorsque plusieurs ressources présentent simultanément un dysfonctionnement. 8 [0020] Le procédé selon l'invention se base sur l'association desdites ressources à un seuil prédéterminé d'utilisation maximum d'une part et à un niveau prédéterminé d'utilisation courante d'autre part. [0021] Ainsi, à chaque ressource est associé à un seuil prédéterminé d'utilisation 5 maximum correspondant au paramètre maximal de ladite ressource permettant un bon fonctionnement de ladite ressource. Par exemple, cela correspond aux limites maximales acceptables de consommations de ressources pour un système informatique hébergeant une ou plusieurs chaines applicatives. Ces limites peuvent être réelles ou hypothétiques et correspondent généralement un niveau d'utilisation au-delà duquel des dysfonctionnements 10 peuvent survenir et ayant pour conséquence un arrêt de la ressource ou bien à tout le moins des baisses de qualités de service. Par exemple, le tableau 1 ci-dessous présente les seuils prédéterminés d'utilisation maximum pour trois ressources. Tableau 1 CPU1 Utilisation Utilisation réseau Disque Seuil prédéterminé d'utilisation maximum 80 (3/0 350 KBps 60 Mo/s 15 [0022] A chaque ressource est également associé un niveau prédéterminé d'utilisation courante correspondant à l'utilisation globale de ladite ressource par les chaines applicatives du système informatique. En effet, les chaines applicatives sont associées à un certain nombre d'actions, où chaque action implique une consommation de ressources spécifiques (I/O disques ou réseau, consommation CPU, etc). Ainsi, une même chaine applicative va faire 20 appel à plusieurs ressources avec des niveaux d'utilisation différents. [0023] En outre, le procédé selon l'invention peut également comprendre l'attribution d'un niveau de criticité à chaque couple Ressource (R,) - Chaine applicative (A,). Le niveau de criticité peut correspondre à une valeur numérique traduisant l'importance relative de la ressource dans le cadre du fonctionnement normale de la chaine applicative. 25 [0024] Dans ce contexte, le procédé selon l'invention peut comprendre une étape préalable 101 de mesure de valeurs correspondant à un niveau d'utilisation courant de chacune des ressources. Cette mesure est réalisée distinctivement pour chacune des chaines applicatives. Avantageusement, ces valeurs sont enregistrées dans un premier référentiel 200 d'utilisation des ressources par les chaines applicatives. 9 [0025] Ce référentiel 200 d'utilisation des ressources par les chaines applicatives présente la particularité de rassembler des informations sur le niveau d'utilisation des ressources, classées et distinguées en fonction de la chaine applicative utilisant ladite ressource. Ce référentiel est basé sur le fait que la ou les chaines applicatives A,..., An) 5 repose, pour leur fonctionnement, sur un ensemble de ressources (R1,..., R'..., Rn) utilisé en tout ou partie. Il permet de détailler le niveau d'utilisation courant (ou classique) de chacune des ressources (Ursa,) par chacune des chaines applicatives. Le référentiel 200 par exemple sous la forme d'un tableau dont chaque ligne correspond à une chaine applicative (A,) et chaque colonne une ressource (R,) et pour chaque ressource sont reportées dans ledit 10 référentiel une valeur correspondant à un niveau d'utilisation d'une ressource (Ursa,) par une chaine applicative. Le référentiel 200 peut par exemple prendre la forme d'une matrice représentée par le tableau 2. Tableau 2 R1 R, ... R, Al A, ... A, 15 [0026] Le référentiel 200 d'utilisation des ressources, par les chaines applicatives, est généré par l'intermédiaire d'une séquence de mesure des consommations de ressources par chaque chaine applicative de façon indépendante. La somme des utilisations de ressource par chacune des chaines applicatives d'un système informatique correspondant à l'utilisation 20 globale des ressources du système informatique lors du fonctionnement des chaines applicatives considérées. [0027] Le référentiel 200 peut correspondre à un agencement matériel et logiciel permettant d'une part la mesure, par des sondes, de l'empreinte de chaque chaine applicative sur chaque ressource, en soustrayant des consommations de ressources mesurées celles de l'empreinte 25 à vide sur une même période et d'autre part le calcul de l'empreinte totale sur l'ensemble des ressources induites par l'ensemble des chaines applicatives, puis la mémorisation de cette empreinte totale dans ledit référentiel. 10 [0028] Le niveau d'utilisation d'une ressource (Ursa,) par les chaines applicative peut varier en fonction du temps. Cette variation, souvent cyclique, peut être retrouvée par exemple au sein d'une même journée au gré des heures de travail mais également au gré de la saisonnalité de l'activité métier. En effet, lorsqu'une application est utilisée en production sur 5 une infrastructure, les demandes de ressource de l'application ne sont pas régulières, soit pour le déclenchement de taches périodiques (traitements batch) soit pour l'usage de l'application de façon saisonnière (période de clôture, lancement des campagnes...). Ainsi, de façon avantageuse, le référentiel 200 intègre une donnée temporelle de façon à intégrer les variations observées au cours du temps dans l'utilisation des ressources. Le même processus 10 s'effectue pour les périodes sans problème de performance pour mémoriser des triplets (A' R' Ursa,). [0029] Faisant suite au tableau 1 listant trois ressources avec leur seuil prédéterminé d'utilisation maximum respectif, un exemple de structure d'un référentiel 200 est exposé en tableau 3. 15 Tableau 3 CPU1 Utilisation Utilisation réseau Disque Seuil prédéterminé d'utilisation maximum 80 (3/0 350 KBps 60 Mo/s Niveau d'utilisation courante 60% 180 KBps 39 Mo/s Chaine Applicative 1 35 (3/0 50 KBps 8 Mo/s Chaine Applicative 2 20 (3/0 10 KBps 5 Mo/s Chaine Applicative 3 5 cyo 100 KBps 24 Mo/s Chaine Applicative 4 0 (3/0 20 KBps 2 Mo/s [0030] Ainsi, le premier référentiel comporte un agencement matériel et logiciel permettant de lister et mémoriser dans une mémoire : - des identifiants uniques pour chacune des ressources (R,) 20 - des identifiants uniques pour chacune des chaines applicatives (A,) - des niveaux d'utilisation (Ursa,) des ressources par les chaines applicatives. [0031] Comme cela est présenté dans le tableau 3, ce référentiel peut également mémoriser pour chaque ressource les seuils d'utilisation maximum et stocker une information relative au niveau d'utilisation courante. 11 [0032] Le procédé selon l'invention comporte l'utilisation d'au moins une sonde configurée pour collecter des données. Ainsi, le procédé selon l'invention peut faire appel à une sonde ou à une pluralité de sondes. La ou les sondes permettent de collecter des 5 données sur l'état de fonctionnement des ressources et ces données sont utilisées dans le procédé selon l'invention pour détecter un dysfonctionnement. Comme cela est présenté en figure 1, le procédé selon l'invention peut comporter une étape préalable facultative de configuration 102 de la ou des sondes correspondant à la mise en place d'une ou plusieurs sondes. 10 [0033] Les sondes particulières permettant d'obtenir des données sur l'état de fonctionnement des ressources peuvent être nommées sondes d'état de fonctionnement. Ces sondes d'état de fonctionnement peuvent être associées à chaque ressource pour remonter les informations de mesure ou métriques, représentant l'état de fonctionnement des ressources. Pour chaque ressource, les sondes d'état de fonctionnement définissent un 15 identifiant de la ressource et au moins une valeur correspondant à un état de fonctionnement. L'état de fonctionnement de chaque ressource peut être suivi en continue ou à des intervalles configurables de façon à obtenir des informations d'état de fonctionnement pour chaque ressource en fonction du temps. Ces informations peuvent être stockées dans une mémoire. [0034] L'étape de configuration des sondes peut comprendre la définition de seuils de 20 dysfonctionnement correspondant par exemple à des valeurs minimales et/ou maximales de pourcentage d'utilisation de ressources (ex : taux d'occupation des processeurs CPUs, de la mémoire RAM), des temps de réponse, des temps de traitement ou à des valeurs de variation autorisée en fonction du temps. Les seuils de dysfonctionnement peuvent être inscrits dans un fichier de configuration (par exemple pour chaque dispositif de l'infrastructure et/ou pour 25 chaque ressource). Ces seuils de dysfonctionnement peuvent être utilisés pour déterminer si l'infrastructure ne dévie pas d'un comportement attendu ou ne satisfait pas des performances voulues. [0035] Outre les éventuelles premières étapes de création 101 d'un premier référentiel ou 30 de configuration 102 des sondes, le procédé selon l'invention comporte une étape de collecte 110 des données d'une sonde, lesdites données collectées comportant des données relatives à l'état de fonctionnement des ressources utilisées par la chaine applicative. Comme évoqué précédemment, les informations collectées peuvent par exemple correspondre des valeurs minimales et/ou maximales de pourcentage d'utilisation de 35 ressources, des temps de réponse, des temps de traitement mais également le statut des 12 ports, le nombre de files de message JDBC ou JMS, 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). 5 [0036] Comme cela est présenté en figure 3, ces sondes 31, 32, 33 d'état de fonctionnement peuvent être associées à chaque ressource 11, 12, 13 pour remonter les informations de mesure ou métriques, représentant l'état de fonctionnement des ressources. Pour chaque ressource, la ou les sondes d'état de fonctionnement définissent un identifiant de la ressource et un état de fonctionnement. L'état de fonctionnement de chaque ressource 10 peut être suivi en continue ou à des intervalles configurable de façon à obtenir des informations pour chaque ressource d'état de fonctionnement en fonction du temps. Dans le cadre d'une étape 120 d'enregistrement des données relatives à l'état de fonctionnement des ressources, ces informations peuvent être stockées dans une mémoire. [0037] Dans un mode de réalisation particulier, le procédé peut prendre en compte la 15 présence d'une redondance au sein des ressources. Par exemple dans le cas d'un ensemble de serveurs, si l'un subit un dysfonctionnement global, il peut y avoir une répartition de la charge sur les serveurs restants. Ainsi, dans le cas d'une architecture redondée, il y a de préférence présence d'un répartiteur fournissant, dans le cadre du procédé selon l'invention, une indication sur l'état de fonctionnement de la ferme de serveurs. 20 [0038] Le procédé selon l'invention comporte une étape de détection 130 d'un dysfonctionnement sur au moins une ressource, à partir des données de sonde collectées. [0039] La détection de dysfonctionnement peut par exemple être réalisée via une étape de comparaison entre des valeurs mesurées par une sonde et des seuils de dysfonctionnement 25 correspondant par exemple aux données fournies lors d'une étape de configuration 102 des sondes. Cette détection peut par exemple être réalisée via une étape de comparaison entre des valeurs mesurées par une sonde et des seuils de dysfonctionnement spécifiés en accord avec les données fournies lors de l'étape de configuration 102. En effet, des seuils de dysfonctionnement peuvent être fixés dans un fichier de configuration (par exemple pour 30 chaque ressource). Ces seuils de dysfonctionnement permettent de déterminer si la ressource ne satisfait pas des performances voulues. [0040] Alternativement, un enregistrement systématique des valeurs des paramètres de ressources et une comparaison d'une nouvelle valeur aux valeurs préalablement enregistrées peut permettre de détecter un dysfonctionnement si la nouvelle valeur est significativement 13 différente des valeurs enregistrées antérieurement. Cette méthode alternative permet de déterminer si la ressource ne dévie pas d'un comportement attendu ou classique. Un dysfonctionnement peut également être détecté par comparaison avec le seuil d'utilisation maximum. 5 [0041] Afin de garder une trace des éventuels écarts par rapport aux seuils fixés, des alertes peuvent être émises vers un utilisateur ou être stockées dans un fichier de suivi. En outre, un dysfonctionnement détecté peut être associé avec une indication temporelle. [0042] Lorsqu'aucun dysfonctionnement n'est détecté, et par exemple que les résultats de mesure satisfont aux seuils de dysfonctionnement définis, alors il y a poursuite de la collecte 10 de données telle que prévue à l'étape 110 de collecte. [0043] Lorsque les résultats de mesure ne satisfont pas aux seuils de dysfonctionnement définis, un dysfonctionnement est alors détecté. A cette étape, il est en outre possible d'émettre un message d'alerte vers un utilisateur (un courriel, un message graphique, un son ou autre). Par exemple encore, il est possible d'inscrire cet événement 15 dans le fichier de suivi dans une étape de mise à jour de celui-ci. [0044] Le procédé selon l'invention peut également comprendre une étape facultative de mesure 140 du niveau d'utilisation globale des ressources. Cela permet de déterminer l'utilisation globale des ressources par l'ensemble des chaines applicatives sans distinction. 20 La mesure des niveaux d'utilisation globale des ressources (Ursg,) au cours du temps peut être complétée par une étape de comparaison avec des niveaux antérieurs d'utilisation globale de ressources. Ce processus a pour objectif de savoir si les observations sont stables dans le temps. Les niveaux d'utilisation globale des ressources (Ursg,) mesurés au cours du temps peuvent également être comparés avec la somme des niveaux d'utilisation courant de 25 chacune des ressources tels que mesurés lors de l'étape 101. Cela de façon à contrôler qu'il n'y ait pas au fil du temps une augmentation ou une modification du schéma d'utilisation des ressources nécessitant une nouvelle étape ponctuelle 101 de mesure de valeurs correspondant à un niveau d'utilisation courant de chacune des ressources correspondant à une cartographie de l'utilisation des ressources par les chaines applicatives constituant le 30 système informatique. [0045] Le procédé peut comprendre, à l'issue de l'étape 140, une étape d'enregistrement 141 dudit niveau de d'utilisation globale des ressources. [0046] De façon préférée, le procédé peut comprendre en outre une étape de comparaison 142 dans le temps de l'utilisation globale des ressources. Si l'utilisation globale des 14 ressources dévie ponctuellement ou de façon chronique, le procédé peut comprendre une étape de génération 143 d'une alerte si la consommation globale des ressources présente une variation significative. Le niveau de variation significative permettant de déclencher une telle alerte peut être librement configuré par les utilisateurs (par exemple une variation 5 supérieure à 10%, ou supérieure à 20%). [0047] En présence d'un dysfonctionnement, le procédé selon l'invention comporte une étape 160 de quantification l'impact présumé dudit dysfonctionnement sur un niveau de service d'au moins une chaine applicative. Cette étape 160 comporte plusieurs sous étapes pouvant être ou non facultatives et étant détaillées à la figure 2. 10 [0048] La sous étape 161 correspond au calcul d'un nouveau seuil d'utilisation maximum en fonction du seuil prédéterminé d'utilisation maximum de la ressource d'une part et des données relatives à l'état de fonctionnement des ressources d'autre part. Cela permet de quantifier l'impact du dysfonctionnement sur le niveau fonctionnalité de la ressource à un temps donné. 15 [0049] Par exemple, dans le cas d'un dysfonctionnement affectant principalement le CPU n°1 d'un système informatique, alors, comme cela est présenté dans le tableau 4, il peut y avoir une réduction du seuil d'utilisation maximum aboutissant à la génération d'un nouveau seuil d'utilisation maximum inférieur au seuil prédéterminé d'utilisation maximum. Comme présenté en tableau 4, il est également possible de calculer un nouveau seuil d'utilisation 20 maximum pour les ressources n'ayant pas subi de dysfonctionnement. Le tableau 4 montre dans ce cas un nouveau seuil d'utilisation maximum identique au seuil prédéterminé d'utilisation maximum. Néanmoins, il est possible également que le dysfonctionnement d'une ressource entraine une diminution du nouveau seuil d'utilisation maximum d'une autre ressource non impactée directement par le dysfonctionnement mais étant dépendante de la 25 ressource impactée. Tableau 4 CPU1 Utilisation réseau Utilisation Disque Seuil prédéterminé d'utilisation maximum 80 (3/0 350 KBps 60 Mo/s Nouveau seuil d'utilisation maximum 50 % 350 KBps 60 Mo/s 15 [0050] Dans une sous-étape 162, le nouveau seuil d'utilisation maximum de la ressource est comparé au niveau prédéterminé d'utilisation courante de ladite ressource, de façon à déterminer si le nouveau seuil d'utilisation maximum est dépassé par le niveau prédéterminé d'utilisation courante. Dans le cas présenté dans le tableau 5, il est possible de voir que le 5 seuil d'utilisation maximum du CPU n°1 est dépassé par le niveau prédéterminé d'utilisation courante du CPU n°1. Ainsi, il y aura probablement un impact du dysfonctionnement sur le niveau de service des chaines applicatives faisant appel au CPU n°1 alors qu'il n'y aura pas d'impact présumé sur le niveau de service de la chaine applicative 4 ne faisant pas appel au CPU n°1. 10 Tableau 5 CPU1 Utilisation Utilisation réseau Disque Seuil prédéterminé d'utilisation maximum 80 (3/0 350 KBps 60 Mo/s Nouveau seuil d'utilisation maximum 50 % 350 KBps 60 Mo/s Niveau prédéterminé d'utilisation courante 60% 180 KBps 39 Mo/s Chaine Applicative 1 35 (3/0 50 KBps 8 Mo/s Chaine Applicative 2 20 (3/0 10 KBps 5 Mo/s Chaine Applicative 3 5 cyo 100 KBps 24 Mo/s Chaine Applicative 4 0 (3/0 20 KBps 2 Mo/s [0051] Si le nouveau seuil d'utilisation maximum n'est pas dépassé alors le procédé peut poursuivre la collecte de données selon l'étape 110. A ce stade, le procédé peut également comprendre la génération 164 d'un signal d'alerte de dysfonctionnement sans impact sur le 15 niveau de service de la chaine applicative. Un tel signal d'alerte applicative peut par exemple être envoyé aux administrateurs du système informatique et/ou aux directions des applications métiers. [0052] Si le nouveau seuil d'utilisation maximum est dépassé, comme cela est présenté 20 dans le tableau 5, cela implique qu'il y aura un impact du dysfonctionnement sur le niveau de service d'une ou plusieurs chaines applicatives. Dans ce cadre, le procédé selon l'invention 16 comporte une sous étape 163 de calcul d'une valeur de sévérité présumée de l'impact du dysfonctionnement sur un niveau de service de la chaine applicative. Ce calcul peut être réalisé pour toutes les chaines applicatives pouvant être impactées par le dysfonctionnement détecté. 5 [0053] Il existe plusieurs méthodes pour le calcul d'un niveau présumé de sévérité du dysfonctionnement sur un niveau de service de la chaine applicative. Par exemple, cette méthode peut être basée sur une valeur de niveau de criticité de la ressource pour la chaine applicative. Ce niveau de criticité correspondant à l'importance relative de la ressource dans le cadre du fonctionnement normale de la chaine applicative. 10 [0054] Avantageusement, cette sous étape 163 de calcul peut comprendre la prise en compte de l'importance de ladite ressource dans le fonctionnement de l'application. Ainsi, il peut être pris en compte le niveau d'utilisation de la ressource (Ursa,) par la chaine applicative. Il est en effet possible pour un système informatique donné de quantifier l'utilisation des ressources par chacune des chaines applicatives hébergées par le système 15 informatique. De façon préférée, l'étape de calcul 163 de la valeur de sévérité présumée d'impact du dysfonctionnement sur le niveau de service d'au moins une chaine applicative est réalisée à partir de données mémorisées dans le premier référentiel 200 d'utilisation des ressources. Cette valeur de sévérité présumée d'impact du dysfonctionnement sur le niveau de service d'au moins une chaine applicative permet d'obtenir une prédiction du niveau de 20 service que fournir une chaine applicative suite au dysfonctionnement. Tableau 6 CPU1 Utilisation Utilisation réseau Disque Nouveau seuil d'utilisation maximum 50 (3/0 350 KBps 60 Mo/s Seuil prédéterminé d'utilisation courante 60 (3/0 180 KBps 39 Mo/s Chaine Applicative 1 35 % 50 KBps 8 Mo/s Chaine Applicative 2 20 (3/0 10 KBps 5 Mo/s Chaine Applicative 3 5 cyo 100 KBps 24 Mo/s Chaine Applicative 4 0 (3/0 20 KBps 2 Mo/s 17 [0055] Dans le tableau 6, ci-dessus il est possible de voir que la chaine applicative 1 fait beaucoup plus appel au CPU n°1 (ressource subissant un dysfonctionnement) que la chaine applicative 3 par exemple. [0056] Ainsi, lors de l'étape de calcul 163 d'une valeur de sévérité présumée de l'impact du 5 dysfonctionnement sur le niveau de service, il est probable que l'impact présumé soit plus important sur la chaine applicative 1 que sur la chaine applicative 3 dont l'utilisation du CPU n°1 est faible. [0057] Ensuite, le procédé comporte la génération 170 d'un signal d'alerte applicative comportant la valeur de sévérité calculée du dysfonctionnement sur un niveau de service d'au 10 moins une chaine applicative. Ce signal d'alerte applicative peut être envoyé par exemple au DSI, aux utilisateurs des chaines applicatives métiers concernées par le dysfonctionnement, et/ou aux référents métier. [0058] Ces informations peuvent être stockées dans une mémoire et permettre l'établissement d'un rapport. Les informations stockées sont par exemple : 15 - des données temporelles telles que la date et l'heure, - l'état de fonctionnement par exemple de la ressource subissant le dysfonctionnement, et - le nouveau seuil d'utilisation maximum, et éventuellement - la valeur de sévérité présumée d'impact du dysfonctionnement par exemple pour 20 chaque chaine applicative impactée. [0059] De façon à réduire l'impact sur la mémoire, seules les informations relatives aux ressources subissant un dysfonctionnement et les chaines applicative potentiellement impactées sont enregistrées. 25 [0060] Avantageusement, en présence d'un dysfonctionnement, le procédé selon l'invention comporte une étape 190 d'enregistrement d'une valeur observée d'impact d'un dysfonctionnement sur un niveau de service (Sob,) d'au moins une chaine applicative (R,). Par exemple, les données de sondes collectées enregistrées peuvent être utilisées pour mesurer l'impact réel sur le niveau de service des chaines applicatives lorsqu'un dysfonctionnement 30 s'est produit de façon à affiner les valeurs d'impacts. En outre, dans un mode de réalisation de la présente invention, le procédé selon l'invention peut comprendre la réception des mesures de niveau de service par des terminaux d'utilisateurs par l'intermédiaire d'un réseau de données. Chacun des mesures de niveau de service pouvant indiquer une mesure d'un 18 niveau de service d'une des chaines applicatives hébergées par l'un des terminaux utilisateurs. Le procédé peut comprendre en outre la détermination si l'un des niveaux de service rapportés par l'un des terminaux d'utilisateur viole une règle d'un accord de niveau de service prédéterminé. 5 [0061] Cette étape 190 d'enregistrement comporte de façon préférée une sous étape d'établissement d'un second référentiel 300 d'impact de dysfonctionnement. Ce second référentiel 300 d'impact de dysfonctionnement peut être utilisé pour mémoriser la valeur observée d'impact d'un dysfonctionnement sur un niveau de service (Sob,) d'au moins une chaine applicative. 10 [0062] Le second référentiel 300 d'impact de dysfonctionnement peut avantageusement comporter une valeur observée d'impact d'un dysfonctionnement sur un niveau de service (Sob,), d'au moins une chaine applicative (A,) en fonction de valeurs de fonctionnalités des ressources subissant un dysfonctionnement (Rdys,), lesdites valeurs de fonctionnalités des ressources subissant un dysfonctionnement (Rdys,) pouvant être sélectionnées parmi des 15 données relatives à l'état de fonctionnement des ressources ou de nouveaux seuils d'utilisation maximum de ressources suite à un dysfonctionnement. Ainsi, le second référentiel comporte des triplets d'information (Sob' A' Rdys,) 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 maintenant une précision suffisante pour l'intégration ultérieure de ces 20 données dans le procédé selon l'invention. [0063] De façon préférée, le second référentiel comporte un agencement matériel et logiciel permettant de lister et mémoriser dans une mémoire : - des identifiants uniques pour chacune des chaines applicatives, 25 - des identifiants uniques pour chacune des ressources, - des valeurs de fonctionnalités des ressources, et - des valeurs observées d'impact d'un dysfonctionnement sur un niveau de service (Sob,). 30 [0064] Le second référentiel peut être utilisé de manière particulièrement avantageuse pour améliorer la prédiction du procédé selon l'invention. [0065] Ainsi, de façon avantageuse, le procédé selon l'invention comporte, après la détection 130 d'un dysfonctionnement sur au moins une ressource : - une étape de comparaison 150 du dysfonctionnement à un dysfonctionnement 35 antérieur de façon à identifier un dysfonctionnement antérieur identique ou sensiblement identique, et 19 - si un dysfonctionnement antérieur identique ou sensiblement identique est identifié, une étape de génération 180 d'un signal d'alerte applicatiye comportant une valeur observée d'impact du dysfonctionnement sur le niveau de service d'au moins une chaine applicatiye. 5 [0066] Ainsi, l'étape de comparaison 150 peut être mise en oeuvre pour identifier un dysfonctionnement antérieur ayant eu un impact sensiblement identique au présent dysfonctionnement sur la ressource. Par sensiblement identique on entend au sens de l'invention une valeur variant de moins de 30 (3/0 par rapport à la valeur comparée, de préférence de moins de 20 %, de façon encore plus préférée de moins de 10 (3/0. 10 [0067] Lorsque le dysfonctionnement antérieur est sensiblement identique, le procédé selon l'invention peut comprendre une étape de calcul d'une valeur calculée d'impact du dysfonctionnement à partir de la valeur observée d'impact du dysfonctionnement antérieur sensiblement identique. Cette étape de calcul peut permettre, à partir de la valeur observée de dysfonctionnement antérieur sensiblement identique et par exemple à partir des données 15 relatives à l'état de fonctionnement, de calculer une nouvelle valeur d'impact du dysfonctionnement plus précise que le seraient la valeur présumée d'impact et la valeur observée d'impact. [0068] Selon une autre particularité de l'invention, le procédé peut également inclure une étape d'utilisation d'une interface homme-machine (IHM) pouvant intervenir par exemple 20 dans : - la définition et la mémorisation des seuils de dysfonctionnement, - la définition et la mémorisation des niveaux de criticité, - la définition et la mémorisation des paramètres de mémorisation et de transmission des informations générées par le système, et 25 - la définition et la mémorisation des valeurs observées d'impact du dysfonctionnement sur le niveau de service (par exemple des niveaux de services observés) suite à un dysfonctionnement et utilisé dans la construction du second référentiel 300. [0069] Selon un autre aspect, l'invention porte sur un système informatique 1 de supervision 30 automatique de l'impact d'un dysfonctionnement d'au moins une ressource 11, 12, 13 sur un niveau de service d'au moins une chaine applicatiye 21, 22, 23. Comme cela est présenté en figure 3, le système informatique 1 comporte au moins une sonde 31, 32, 33 configurée pour collecter des données. En outre, le système informatique 1 comporte plusieurs modules permettant son fonctionnement. 20 [0070] Le système informatique 1 selon l'invention comporte un module de configuration 40 apte à associer lesdites ressources à un niveau prédéterminé d'utilisation courante et à un seuil prédéterminé d'utilisation maximum. [0071] Le système informatique 1 selon l'invention comporte un module d'acquisition 50 5 apte à collecter, à partir desdites sondes, des données relatives à l'état de fonctionnement des ressources. [0072] Le système informatique 1 selon l'invention comporte un module de détection 60 apte à détecter un dysfonctionnement sur au moins une ressource, à partir de données de sonde collectées ; et apte, en présence d'un dysfonctionnement, à transmettre l'information à un 10 module de traitement 70. [0073] Le module de traitement 70 de données est capable de quantifier l'impact présumé dudit dysfonctionnement sur le niveau de service d'au moins une chaine applicative et il est notamment apte à: - Calculer un nouveau seuil d'utilisation maximum en fonction du seuil prédéterminé 15 d'utilisation maximum et des données relatives à l'état de fonctionnement des ressources, - Comparer le nouveau seuil d'utilisation maximum de la ressource au niveau prédéterminé d'utilisation courante de ladite ressource, de façon à déterminer si le nouveau seuil d'utilisation maximum est dépassé par le niveau prédéterminé d'utilisation 20 courante, et - Si le nouveau seuil d'utilisation maximum est dépassé alors, calculer une valeur de sévérité présumée d'impact du dysfonctionnement sur le niveau de service d'au moins une chaine applicative et à le transmettre à un module de communication, [0074] Le système informatique 1 selon l'invention comporte module de communication (80) 25 de données apte à générer un signal d'alerte applicative comportant la valeur de sévérité présumée d'impact du dysfonctionnement sur le niveau de service d'au moins une chaine applicative. [0075] Avantageusement, le système informatique 1 de supervision automatique de l'impact 30 d'un dysfonctionnement selon l'invention comporte : 21 - un premier référentiel 200 d'utilisation des ressources, comportant, distinctivement pour chacune des ressources (R,), une valeur correspondant à un niveau d'utilisation d'une ressource (Ursa,) par une chaine applicative (A,) et - un second référentiel 300 d'impact de dysfonctionnement comportant des valeurs 5 observées d'impact du dysfonctionnement sur le niveau de service (Sob,), d'au moins une chaine applicative (A,) en fonction de valeurs de fonctionnalités des ressources subissant un dysfonctionnement (Rdys,), lesdites valeurs de fonctionnalités des ressources subissant un dysfonctionnement (Rdys,) étant sélectionnées parmi des données relatives à l'état de fonctionnement des ressources ou de nouveaux seuils 10 d'utilisation REVENDICATIONS1. Procédé de prédiction automatique de l'impact d'un dysfonctionnement affectant une ressource, sur un niveau de service d'au moins une chaine applicative utilisant des ressources, ledit procédé étant caractérisé en ce que lesdites ressources sont associées à un niveau prédéterminé d'utilisation courante et à un seuil prédéterminé d'utilisation maximum, en ce qu'il comporte l'utilisation d'au moins une sonde configurée pour collecter des données, et en ce qu'il comporte les étapes suivantes : o Collecter (110) les données de ladite sonde, lesdites données collectées comportant des données relatives à l'état de fonctionnement des ressources ; o Détecter (130) un dysfonctionnement sur au moins une ressource, à partir des données de sonde collectées ; o En présence d'un dysfonctionnement, quantifier (160) l'impact présumé dudit dysfonctionnement sur le niveau de service d'au moins une chaine applicative, comportant les sous étapes suivantes : - Calculer (161) un nouveau seuil d'utilisation maximum en fonction du seuil prédéterminé d'utilisation maximum et des données relatives à l'état de fonctionnement des ressources, - Comparer (162) le nouveau seuil d'utilisation maximum de la ressource au niveau prédéterminé d'utilisation courante de ladite ressource, de façon à déterminer si le nouveau seuil d'utilisation maximum est dépassé par le niveau prédéterminé d'utilisation courante, et - Si le nouveau seuil d'utilisation maximum est dépassé alors, calculer (163) une valeur de sévérité présumée d'impact du dysfonctionnement sur le niveau de service d'au moins une chaine applicative ; et o Générer (170) un signal d'alerte applicative comportant la valeur de sévérité présumée d'impact du dysfonctionnement sur le niveau de service d'au moins une chaine applicative. 2. Procédé selon la revendication 1, caractérisé en ce qu'il comprend, une étape préalable de génération (101) d'un premier référentiel (200) d'utilisation des ressources, comportant, distinctivement pour chacune des ressources (R,), une valeur correspondant à un niveau d'utilisation d'une ressource (Ursa,) par une chaine applicative (A,). 23 3. Procédé selon la revendication 2, caractérisé en ce que l'étape de calcul (163) de la valeur de sévérité présumée d'impact du dysfonctionnement sur le niveau de service d'au moins une chaine applicative est réalisé à partir de données mémorisées dans le 5 premier référentiel (200) d'utilisation des ressources. 4. Procédé selon l'une quelconque des revendications 1 à 3, caractérisé en ce qu'il comporte, en présence d'un dysfonctionnement, une étape (190) d'enregistrement d'une valeur observée d'impact d'un dysfonctionnement sur un niveau de service 10 (Sob,) d'au moins une chaine applicative (R,). 5. Procédé selon la revendication 4, caractérisé en ce que la valeur observée d'impact d'un dysfonctionnement sur un niveau de service (Sob,) d'au moins une chaine applicative est enregistré dans un second référentiel (300) d'impact de 15 dysfonctionnement. 6. Procédé selon la revendication 5, caractérisé en ce que le second référentiel (300) d'impact de dysfonctionnement comporte des valeurs observées d'impact d'un dysfonctionnement sur un niveau de service (Sob,), d'au moins une chaine applicative 20 (A,) en fonction de valeurs de fonctionnalités des ressources subissant un dysfonctionnement (Rdys,), lesdites valeurs de fonctionnalités des ressources subissant un dysfonctionnement (Rdys,) étant sélectionnées parmi des données relatives à l'état de fonctionnement des ressources ou de nouveaux seuils d'utilisation maximum de ressources suite à un dysfonctionnement. 25 7. Procédé selon l'une quelconque des revendications 4 à 6, caractérisé en ce qu'il comporte, après la détection (130) d'un dysfonctionnement sur au moins une ressource : o une étape de comparaison (150) du dysfonctionnement à un 30 dysfonctionnement antérieur de façon à identifier un dysfonctionnement antérieur identique ou sensiblement identique, et o si un dysfonctionnement antérieur identique ou sensiblement identique est identifié, une étape de génération (180) d'un signal d'alerte applicative comportant une valeur observée d'impact du dysfonctionnement sur le niveau 35 de service d'au moins une chaine applicative. 24 8. Procédé selon l'une quelconque des revendications 1 à 7, caractérisé en ce qu'il comprend une étape de mesure (140) du niveau d'utilisation globale des ressources. 9. Système informatique (1) de supervision automatique de l'impact d'un 5 dysfonctionnement d'au moins une ressource (11, 12, 13) sur un niveau de service d'au moins une chaine applicative (21, 22, 23), ledit système informatique comportant au moins une sonde (31, 32, 33) configurée pour collecter des données, ledit système informatique étant caractérisé en ce qu'il comporte : un module de configuration (40) apte à associer lesdites ressources à un 10 niveau prédéterminé d'utilisation courante et à un seuil prédéterminé d'utilisation maximum, un module d'acquisition (50) apte à collecter, à partir desdites sondes, des données relatives à l'état de fonctionnement des ressources, un module de détection (60) apte à détecter un dysfonctionnement sur au 15 moins une ressource, à partir de données de sonde collectées, et apte, en présence d'un dysfonctionnement, à transmettre l'information à un module de traitement (70), un module de traitement (70) de données capable de quantifier l'impact présumé dudit dysfonctionnement sur le niveau de service d'au moins une 20 chaine applicative et apte à: o Calculer un nouveau seuil d'utilisation maximum en fonction du seuil prédéterminé d'utilisation maximum et des données relatives à l'état de fonctionnement des ressources, o Comparer le nouveau seuil d'utilisation maximum de la ressource au 25 niveau prédéterminé d'utilisation courante de ladite ressource, de façon à déterminer si le nouveau seuil d'utilisation maximum est dépassé par le niveau prédéterminé d'utilisation courante, et o Si le nouveau seuil d'utilisation maximum est dépassé alors, calculer une valeur de sévérité présumée d'impact du dysfonctionnement sur le 30 niveau de service d'au moins une chaine applicative et à le transmettre à un module de communication, un module de communication (80) de données apte à générer un signal d'alerte applicative comportant la valeur de sévérité présumée d'impact du dysfonctionnement sur le niveau de service d'au moins une chaine applicative. 35 25 10. Système informatique (1) de supervision automatique de l'impact d'un dysfonctionnement selon la revendication 9 caractérisé en ce qu'il comporte un premier référentiel (200) d'utilisation des ressources, comportant, distinctivement pour chacune des ressources (R,), une valeur correspondant à 5 un niveau d'utilisation d'une ressource (Ursa,) par une chaine applicative (A,) et un second référentiel (300) d'impact de dysfonctionnement comportant des valeurs observées d'impact du dysfonctionnement sur le niveau de service (Sob,), d'au moins une chaine applicative (A,) en fonction de valeurs de fonctionnalités des ressources subissant un dysfonctionnement (Rdys,), 10 lesdites valeurs de fonctionnalités des ressources subissant un dysfonctionnement (Rdys,) étant sélectionnées parmi des données relatives à l'état de fonctionnement des ressources ou de nouveaux seuils d'utilisation maximum de ressources suite à un dysfonctionnement.