FR 3085771 A1 20200313 FR 1858072 A 20180907 DISPOSITIF ET PROCEDE D'ANALYSE DU COMPORTEMENT D'UNE BRIQUE APPLICATIVE SOUMISE A UNE RAREFACTION DES RESSOURCES [0001] La présente invention concerne le domaine de la surveillance des performances des infrastructures informatiques et particulièrement celui de la résilience des applications. Plus particulièrement, l'invention porte sur un dispositif et un procédé d'analyse d'une brique applicative soumise à une raréfaction des ressources pour en améliorer la résilience. [0002] [Art antérieur] [0003] Dans le domaine de la surveillance des performances des infrastructures informatiques, la gestion de la performance et de la disponibilité des applications logicielles tient une place essentielle. Ainsi, un administrateur du système d'information (SI) s'efforce de mettre en place les outils permettant de détecter, de diagnostiquer et de corriger les problèmes de performance des applications pour maintenir un niveau de service attendu notamment malgré la survenue de défaillances matérielles ou logicielles. En effet, certaines applications constituent des pierres angulaires de l'activité d'une société et un haut niveau de résilience est donc exigé. [0004] La résilience d'une application ou d'une chaine applicative est sa capacité à offrir le meilleur service possible malgré la survenue d'un problème sur l'un de ses composants. La résilience devient de plus en plus importante au fur et à mesure que les entreprises continuent à implémenter des applications dont le maintien en activité est critique pour elles et pour lesquelles une interruption de service n'est pas envisageable. Ainsi, la résilience est un terme très large qui inclut notamment la tolérance aux pannes, la haute disponibilité et la capacité à la reprise après une défaillance. Une résilience élevée permet de réduire les conséquences négatives des défaillances. [0005] II existe des méthodes connues permettant de tester la résilience d'une application et d'étudier les causes d'une défaillance. Par exemple, il existe de nombreuses solutions techniques permettant de surveiller le comportement des applications (monitoring), d'étudier le comportement des applications (profiling) ou d'avoir des Réf [0594-BULL25]- Confidentiel 2 informations associées au crash d'une application (dump). Ensuite, il existe des méthodes de test de résilience d'une application comportant la réception d'un script de test qui spécifie un scénario de défaillance dans une application. Le scénario de défaillance spécifié est traduit en règles d'injection de fautes utilisées pour mettre en scène une panne spécifique. [0006] Néanmoins, il n'existe pas de solution satisfaisante dédiée à l'étude et à l'amélioration de la résilience d'une application faisant face à une raréfaction de ressources. [0007] Pourtant, lorsqu'une application s'exécute dans un système informatique, qu'il 10 s'agisse d'un système centralisé ou distribué, les performances de l'application dépendent au moins en partie de la quantité de ressources informatiques disponibles. Ainsi, il peut survenir des défaillances lorsque les ressources disponibles sont saturées. Or, les applications informatiques connaissent d'importantes variations dans leur niveau d'utilisation pouvant entrainer une réduction des ressources informatiques disponibles. 15 Cette utilisation peut varier dans la journée (i.e. plages horaires de travail par rapport au reste de la journée), dans la semaine (i.e. samedi, dimanche par rapport aux autres jours de semaine) dans le mois et l'année (e.g. période de clôture mensuelle, trimestrielle, annuelle, etc.). Par exemple, lorsqu'une application est en production, elle peut connaitre des évolutions importantes d'utilisation (i.e charge) dans le temps, causées par une 20 évolution du nombre d'utilisateurs et/ou de la nature de leurs activités. [0008] De nos jours, les ressources sont de plus en plus partagées entre les différentes applications du SI d'une entreprise. Les applications peuvent donc rencontrer de plus en plus souvent des problèmes de saturation de ressources. En effet, la défaillance d'une application pour cause de saturation des ressources disponibles peut intervenir lors d'un 25 pic de charge sur ladite application, mais également lors d'un pic de charge sur une application tierce utilisant les mêmes ressources ou lors d'un dysfonctionnement sur un composant de l'infrastructure informatique entrainant une réduction des ressources disponibles. Ainsi, le problème de la résilience face aux saturations des ressources est aggravé dans les environnements mutualisés ou virtualisés où la saturation d'une 30 ressource par une première application peut entraîner l'échec d'une tâche d'une seconde application et nécessiter sa réexécution complète. [0009] Habituellement, pour palier à ces difficultés, les administrateurs de SI vont augmenter les ressources disponibles éventuellement en fonction de test de charge Réf [0594-BULL25]- Confidentiel 3 consistant en une simulation de l'augmentation de la charge des applications. Sur cette base, au fil du temps, les administrateurs de SI font généralement évoluer leur infrastructure informatique de façon à toujours proposer des services applicatifs métiers performants et adaptés à la demande de leur organisation. [0010] Néanmoins, ces tests sont généralement basés sur une augmentation de la charge et non sur le comportement de la chaine applicative face à une saturation des ressources. Or, une application ne réagira pas de la même façon face à une augmentation de sa charge et face à une réduction des ressources disponibles pour son fonctionnement. [0011] Ainsi, il existe un besoin pour des méthodes et dispositifs permettant de rendre 10 les applications plus résilientes face aux saturations des ressources disponibles. Une application résiliente sera capable malgré la perte d'une partie des ressources disponibles de continuer à fonctionner tout en assurant des niveaux de service souhaités ou bien à fonctionner dans un mode dégradé où seulement les services critiques sont maintenus à des niveaux de service acceptables. 15 f Problème technique) [0012] 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 dispositif d'analyse du comportement 20 d'une brique applicative soumise à une raréfaction des ressources, ledit dispositif permettant de suivre le comportement de la brique applicative et de diagnostiquer la nature et/ou la source d'une éventuelle défaillance causée par la raréfaction de ressources. Selon un mode de réalisation, ce dispositif peut notamment être utilisé pour améliorer la résilience d'une brique applicative face à une raréfaction des ressources. 25 [0013] L'invention a en outre pour but de proposer un procédé d'analyse du comportement d'une brique applicative soumise à une raréfaction des ressources, ledit procédé pouvant selon un mode de réalisation permettre de rendre les applications plus résilientes face aux saturations des ressources disponibles. 30 Réf [0594-BULL25]- Confidentiel 4 f Brève description de l'invention] [0014] A cet effet, l'invention porte sur un dispositif d'analyse du comportement d'une brique applicative soumise à une raréfaction des ressources dans une infrastructure informatique, ledit dispositif comportant : 5 - Un module de mémorisation, configuré pour mémoriser une pluralité de référentiels incluant un référentiel de ressources, configuré pour mémoriser des données d'identification de ressources critiques utilisées par la brique applicative, un référentiel de règles d'exécution, configuré pour mémoriser des données correspondant à des seuils prédéterminés de paramètre de qualité de service, au- 10 delà desquels la brique applicative est considérée en défaillance, un référentiel de raréfaction, configuré pour mémoriser des règles de consommation des ressources critiques pour une raréfaction progressive des ressources critiques, et un référentiel de charge applicative, configuré pour mémoriser un plan de charge prédéterminé représentatif du fonctionnement de la brique applicative ; 15 - Un module de raréfaction de ressources, configuré pour générer une consommation contrôlée d'au moins une ressource critique selon les règles de consommation préalablement mémorisées sur le référentiel de raréfaction ; - Un module d'injection, configuré pour soumettre l'infrastructure informatique à une charge applicative représentative du fonctionnement de la brique applicative selon 20 le plan de charge mémorisé sur le référentiel de charge applicative ; - Un module de collecte de métriques, configuré pour mesurer la consommation des ressources de l'infrastructure informatique et/ou les niveaux de service de la brique applicative ; - Un module de détection de défaillance, configuré pour comparer les seuils 25 prédéterminés de paramètre de qualité de service aux valeurs mesurées de la consommation des ressources et/ou des niveaux de service de la brique applicative ; et - Un module de gestion de performance applicative, configuré pour, en présence 30 d'un dépassement des seuils prédéterminés de paramètre de qualité de service, analyser le comportement de la brique applicative et générer des données de défaillances capables d'informer sur la nature et/ou la source de la défaillance. Réf [0594-BULL25]- Confidentiel 5 [0015] Un tel dispositif peut être utilisé pour simuler la saturation d'une ou plusieurs ressources et pour analyser le comportement des applications utilisant ces ressources afin de les rendre plus résilientes aux différentes saturations pouvant se produire en production. En effet, pour chaque ressource critique, il est possible d'utiliser le module de 5 raréfaction de ressources pour simuler progressivement la raréfaction de la ressource tout en maintenant le niveau de charge de l'application (i.e. brique applicative) à qualifier. La raréfaction de la ressource est de préférence progressive jusqu'à provoquer une défaillance de l'application puis le module de gestion de performance applicative permet de déterminer la source et/ou la nature de la défaillance. Le dispositif selon l'invention peut 10 fournir à un administrateur SI la source et la nature des défaillances de la brique applicative suite à une raréfaction de ressource. Ainsi, l'administrateur SI pourra prendre les mesures correctives adéquates. Cela peut être lié à des problématiques de configuration système tout comme à des problèmes de configuration applicative voire à des problèmes de conception de la brique applicative. La brique applicative résiliente sera 15 alors capable malgré la perte d'une partie des ressources disponibles de continuer à fonctionner tout en assurant des niveaux de service souhaités ou bien à fonctionner dans un mode dégradé où seulement les services critiques sont maintenus à des niveaux de service acceptables. [0016] Une fois les adaptations réalisées, le dispositif selon l'invention peut être utilisé 20 pour refaire la simulation de façon à valider que les adaptations permettent bien à la brique applicative d'être résiliente à la raréfaction de la ressource. Si tel est le cas, le dispositif peut être utilisé pour poursuivre la raréfaction de ladite ressource pour valider la résilience de la brique applicative au-delà du point de défaillance trouvé précédemment ou bien tester la résilience de la brique applicative sur un autre type de ressources. 25 [0017] Selon d'autres caractéristiques optionnelles du dispositif : - les données de défaillances générées comportent une donnée sur un niveau de raréfaction de ressources que la brique applicative peut supporter avant de subir une 30 défaillance. Ainsi, l'administrateur SI sera informé de la résilience de la brique applicative concernée et des défaillances qu'elle est apte à supporter. - le module de gestion de performance applicative est configuré pour sélectionner la nature de la défaillance parmi : Réf [0594-BULL25]- Confidentiel 6 - configuration matérielle de l'infrastructure informatique, configuration logicielle de l'infrastructure informatique, - configuration de la brique applicative, et - conception de la brique applicative. - il comporte en outre un référentiel de connaissances configuré pour mémoriser des données prédéterminées de défaillances en fonction de données d'exécution, le module de gestion de performance applicative comporte des collecteurs de traces par exemple déployés sur des processus impliqués dans l'exécution de la brique 10 applicative, lesdits collecteurs de traces étant configurés pour collecter des données d'exécution et le module de gestion de performance applicative est configuré pour générer les données de défaillances à partir du référentiel de connaissances en fonction de données d'exécution collectées. 15 - il comporte en outre un référentiel de règles d'évolution configuré pour mémoriser des actions correctives en fonction de données de défaillance et un module d'amélioration de la résilience configuré pour identifier des actions correctives à partir de données de défaillances générées par le module de gestion de performance applicative. Cela permet notamment, de façon rapide et automatique, de générer des propositions de 20 modification permettant d'augmenter la résilience de la brique applicative à la saturation de ressources. le référentiel de règles d'exécution est configuré pour mémoriser plusieurs catégories de seuils prédéterminés de paramètre de qualité de service incluant une catégorie dite 25 acceptable, correspondant aux niveaux de services au-delà desquels la brique applicative est considérée comme fournissant un service dégradé mais acceptable et en ce que le module d'amélioration de la résilience est configuré pour mettre en oeuvre lesdites actions correctives de façon à ce que la brique applicative fournisse des niveaux de service correspondant à la catégorie dite acceptable malgré une 30 raréfaction de ressources. Ainsi, une brique applicative résiliente sera capable malgré la perte d'une partie des ressources disponibles de continuer à fonctionner tout en assurant des niveaux de service souhaités ou bien à fonctionner dans un mode dégradé où seulement les services critiques sont maintenus à des niveaux de service acceptables. Réf [0594-BULL25]- Confidentiel 7 le module d'amélioration de la résilience est configuré pour mettre en oeuvre lesdites actions correctives ou à vérifier leur mise en oeuvre pour permettre à l'application d'être résiliente à une raréfaction de ressources. Ainsi, l'invention permet de faciliter les modifications de la brique applicative, ou de l'infrastructure informatique l'hébergeant, entrainant une augmentation de la résilience de la brique applicative face aux saturations de ressources. - il comporte en outre un référentiel de ressources accessibles configuré pour mémoriser des données caractéristiques de ressources accessibles et un module 10 d'évolution d'infrastructure configuré pour générer au moins un plan d'évolution listant des modifications de ressources à effectuer dans l'infrastructure informatique à partir des données caractéristiques de ressources accessibles et des données de défaillances. 15 les règles de consommation des ressources critiques comportent au moins les données suivantes : - un niveau de consommation de ressource de départ, - un niveau final de consommation de ressource, - un pas d'augmentation de la consommation, et 20 - une durée entre chaque pas d'augmentation. [0018] L'invention porte en outre sur un procédé d'analyse du comportement d'une brique applicative soumise à une raréfaction des ressources dans une infrastructure informatique, ledit procédé étant mis en oeuvre par un dispositif de d'analyse de 25 comportement comportant un module de mémorisation, un module de raréfaction de ressources, un module d'injection, un module de collecte de métriques, un module de détection de défaillance, et un module de gestion de performance applicative, ledit procédé comportant les étapes suivantes : - Générer sur une infrastructure informatique, par l'intermédiaire du module de 30 raréfaction de ressources, une consommation contrôlée d'au moins une ressource critique selon les règles de consommation préalablement mémorisées ; Soumettre l'infrastructure informatique, par l'intermédiaire du module d'injection, à une charge applicative représentative du fonctionnement de la Réf [0594-BULL25]- Confidentiel 8 brique applicative selon un plan de charge, par exemple mémorisé sur un référentiel de charge applicative ; - Mesurer, par l'intermédiaire du module de collecte de métriques, de la consommation des ressources de l'infrastructure informatique et/ou de niveaux de service de la brique applicative - Comparer, par l'intermédiaire du module de détection de défaillance, des seuils prédéterminés de paramètre de qualité de service aux valeurs mesurées de niveaux de service de la brique applicative de façon à identifier un dépassement ; et 10 - En présence d'un dépassement des seuils prédéterminés de paramètre de qualité de service, analyser le comportement de la brique applicative et générer, par l'intermédiaire du module de gestion de performance applicative, des données de défaillances capables d'informer sur la nature et/ou la source de la défaillance. 15 [0019] Le procédé selon l'invention permet de façon automatisée, de réalisation permettre de rendre une brique applicative plus résiliente face aux saturations des ressources disponibles. En outre, il peut comporter une étape de sélection d'au moins une instruction d'action corrective si une défaillance est identifiée et une étape d'application de l'action corrective identifiée. 20 [0020] [0021] 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 : 25 - Figures 1A et 1B, le taux d'occupation des processeurs (« central processing unit » - CPU) cumulé (Fig.1B) ou non (Fig.1A) de différentes structures informatiques, en fonction du temps (en mois), par des briques applicatives (B1, B2). - Figure 2, une vue schématique des éléments du dispositif d'analyse du comportement d'une brique applicative soumise à une raréfaction des ressources selon un mode de 30 réalisation de l'invention. - Figure 3, une représentation schématique d'un procédé d'analyse du comportement d'une brique applicative soumise à une raréfaction des ressources selon l'invention. Les étapes encadrées par des pointillés sont facultatives. Réf [0594-BULL25]- Confidentiel 9 - Figure 4, des étapes de préparation du dispositif et/ou d'initiation du procédé selon l'invention. - Figure 5, une vue schématique de sous étapes d'une étape d'un procédé d'analyse du comportement d'une brique applicative soumise à une raréfaction des ressources 5 selon un mode de réalisation de l'invention. - Figure 6, une vue schématique d'un procédé d'analyse du comportement d'une brique applicative soumise à une raréfaction des ressources selon un mode de réalisation de l'invention. - Figure 7, une analyse de la défaillance selon un mode de réalisation de l'invention. 10 [0022] Ainsi, des aspects de la présente invention sont décrits en référence à des organigrammes et / ou à des schémas fonctionnels de procédés, d'appareils (systèmes) et de produits de programme d'ordinateur selon des modes de réalisation de l'invention. [0023] Sur les figures, les organigrammes et les schémas fonctionnels illustrent l'architecture, la fonctionnalité et le fonctionnement d'implémentations possibles de 15 systèmes, de procédés et de produits de programme d'ordinateur selon divers modes de réalisation de la présente invention. A cet égard, chaque bloc dans les organigrammes ou blocs-diagrammes peut représenter un système, un dispositif, un module ou une partie d'instructions, qui comprend une ou plusieurs instructions exécutables pour mettre en oeuvre la ou les fonctions logiques spécifiées. Dans certaines implémentations, les 20 fonctions associées aux blocs peuvent apparaître dans un ordre différent que celui indiqué sur les figures. Par exemple, deux blocs montrés successivement peuvent, en fait, être exécutés sensiblement simultanément, ou les blocs peuvent parfois être exécutés dans l'ordre inverse, en fonction de la fonctionnalité impliquée. Chaque bloc des schémas de principe et / ou de l'organigramme, et des combinaisons de blocs dans les schémas de 25 principe et / ou l'organigramme, peuvent être mis en oeuvre par des systèmes matériels spéciaux qui exécutent les fonctions ou actes spécifiés ou effectuer des combinaisons de matériel spécial et d'instructions informatiques. JDescription de l'invention] Réf [0594-BULL25]- Confidentiel 10 [0024] Dans la suite de la description, on entend par « comportement d'une brique applicative » les conditions d'exécution de la brique applicative tels que l'exécution des processus impliqués, les transactions internes ou externes, ou encore les performances de la brique applicative vis-à-vis des utilisateurs. [0025] Le terme « résilience » au sens de l'invention correspond à la capacité d'une brique applicative à offrir le service attendu malgré la survenue d'un dysfonctionnement sur l'infrastructure informatique l'hébergeant ou d'une défaillance sur l'un de ses composants. [0026] Par « infrastructure informatique », on entend au sens de l'invention un ensemble 10 de structures informatiques (i.e. dispositifs informatiques) apte à faire fonctionner une application ou une chaine applicative. La structure informatique peut être un serveur ou plusieurs, par exemple être composée d'un serveur de présentation, d'un serveur métier et d'un serveur de données. L'infrastructure informatique peut également être un serveur « test » avec les mêmes ressources qu'un serveur de production ou bien un clone d'un 15 serveur virtuel de production. De façon préférée, une structure informatique est un serveur. [0027] L'expression REVENDICATIONS1. Dispositif (1) d'analyse du comportement d'une brique applicative (2) soumise à une raréfaction des ressources dans une infrastructure informatique (4), ledit dispositif comportant : - Un module (10) de mémorisation, configuré pour mémoriser une pluralité de référentiels incluant : o Un référentiel (11) de ressources, configuré pour mémoriser des données d'identification de ressources critiques utilisées par la brique applicative, o Un référentiel (12) de règles d'exécution, configuré pour mémoriser des données correspondant à des seuils prédéterminés de paramètre de qualité de service, au-delà desquels la brique applicative est considérée en défaillance, o Un référentiel (13) de raréfaction, configuré pour mémoriser des règles de consommation des ressources critiques pour une raréfaction progressive des ressources critiques, et o Un référentiel (14) de charge applicative, configuré pour mémoriser un plan de charge prédéterminé représentatif du fonctionnement de la brique applicative ; - Un module (20) de raréfaction de ressources, configuré pour générer une consommation contrôlée d'au moins une ressource critique selon les règles de consommation préalablement mémorisées sur le référentiel (13) de raréfaction ; - Un module d'injection (30), configuré pour soumettre l'infrastructure informatique à une charge applicative représentative du fonctionnement de la brique applicative (2) selon le plan de charge mémorisé sur le référentiel (14) de charge applicative ; - Un module (40) de collecte de métriques, configuré pour mesurer la consommation des ressources de l'infrastructure informatique (4) et/ou les niveaux de service de la brique applicative (2) ; - Un module (50) de détection de défaillance, configuré pour comparer les seuils prédéterminés de paramètre de qualité de service aux valeurs mesurées de la consommation des ressources et/ou des niveaux de service de la brique applicative ; et Réf [0594-BULL25]- Confidentiel 42 Un module (60) de gestion de performance applicative, configuré pour, en présence d'un dépassement des seuils prédéterminés de paramètre de qualité de service, analyser le comportement de la brique applicative et générer des données de défaillances capables d'informer sur la nature et/ou la source de la défaillance. 2. Dispositif d'analyse de comportement selon la revendication 1, caractérisé en ce que les données de défaillances générées comportent une donnée sur un niveau de raréfaction de ressources que la brique applicative (2) peut supporter avant de subir 10 une défaillance. 3. Dispositif d'analyse de comportement selon l'une des revendications 1 ou 2, caractérisé en ce que le module (60) de gestion de performance applicative est configuré pour sélectionner la nature de la défaillance parmi : 15 - configuration matérielle de l'infrastructure informatique, - configuration logicielle de l'infrastructure informatique, - configuration de la brique applicative, et - conception de la brique applicative. 20 4. Dispositif d'analyse de comportement selon l'une quelconque des revendication 1 à 3, caractérisé en ce qu'il comporte en outre un référentiel (15) de connaissances configuré pour mémoriser des données prédéterminées de défaillances en fonction de données d'exécution, en ce que le module (60) de gestion de performance applicative comporte des collecteurs de traces (61), lesdits collecteurs de traces (61) 25 étant configurés pour collecter des données d'exécution et en ce que le module (60) de gestion de performance applicative est configuré pour générer les données de défaillances à partir du référentiel (15) de connaissances en fonction de données d'exécution collectées. 30 5. Dispositif d'analyse de comportement selon l'une quelconque des revendication 1 à 4, caractérisé en ce qu'il comporte en outre un référentiel (16) de règles d'évolution configuré pour mémoriser des actions correctives en fonction de données de défaillance et un module (70) d'amélioration de la résilience configuré pour identifier des actions correctives à partir de données de défaillances générées par le module 35 (60) de gestion de performance applicative. Réf [0594-BULL25]- Confidentiel 43 6. Dispositif d'analyse de comportement selon la revendication 5, caractérisé en ce que le référentiel (12) de règles d'exécution est configuré pour mémoriser plusieurs catégories de seuils prédéterminés de paramètre de qualité de service incluant une catégorie dite acceptable, correspondant aux niveaux de services au-delà desquels la brique applicative est considérée comme fournissant un service dégradé mais acceptable et en ce que le module (70) d'amélioration de la résilience est configuré pour mettre en oeuvre lesdites actions correctives de façon à ce que la brique applicative (2) fournisse des niveaux de service correspondant à la catégorie dite acceptable malgré une raréfaction de ressources. 10 7. Dispositif d'analyse de comportement selon l'une des revendications 5 ou 6, caractérisé en ce que le module (70) d'amélioration de la résilience est configuré pour mettre en oeuvre lesdites actions correctives ou à vérifier leur mise en oeuvre pour permettre à l'application d'être résiliente à une raréfaction de ressources. 15 8. Dispositif d'analyse de comportement selon l'une quelconque des revendication 1 à 7, caractérisé en ce qu'il comporte en outre un référentiel (17) de ressources accessibles configuré pour mémoriser des données caractéristiques de ressources accessibles et un module (80) d'évolution d'infrastructure configuré pour générer au 20 moins un plan d'évolution listant des modifications de ressources à effectuer dans l'infrastructure informatique (4) à partir des données caractéristiques de ressources accessibles et des données de défaillances. 9. Dispositif d'analyse de comportement selon l'une quelconque des revendications 1 à 25 8, caractérisé en ce que les règles de consommation des ressources critiques comportent au moins les données suivantes : un niveau de consommation de ressource de départ, - un niveau final de consommation de ressource, - un pas d'augmentation de la consommation, et 30 - une durée entre chaque pas d'augmentation. 10. Procédé d'analyse du comportement d'une brique applicative soumise à une raréfaction des ressources dans une infrastructure informatique, ledit procédé étant mis en oeuvre par un dispositif de d'analyse de comportement comportant un module 35 (10) de mémorisation, un module (20) de raréfaction de ressources, un module (30) d'injection, un module (40) de collecte de métriques, un module (50) de détection de Réf [0594-BULL25]- Confidentiel 44 défaillance, et un module (60) de gestion de performance applicative, ledit procédé comportant les étapes suivantes : - Générer (200) sur une infrastructure informatique, par l'intermédiaire du module (20) de raréfaction de ressources, une consommation contrôlée d'au moins une ressource critique selon les règles de consommation préalablement mémorisées ; - Soumettre (300) l'infrastructure informatique, par l'intermédiaire du module (30) d'injection, à une charge applicative représentative du fonctionnement de la brique applicative (2) selon un plan de charge par exemple mémorisé sur un 10 référentiel (14) de charge applicative ; - Mesurer (400), par l'intermédiaire du module (40) de collecte de métriques, de la consommation des ressources de l'infrastructure informatique (4) et/ou de niveaux de service de la brique applicative (2) ; Comparer (500), par l'intermédiaire du module (50) de détection de défaillance, 15 des seuils prédéterminés de paramètre de qualité de service aux valeurs mesurées de niveaux de service de la brique applicative (2) de façon à identifier un dépassement ; et - En présence d'un dépassement des seuils prédéterminés de paramètre de qualité de service, analyser (600) le comportement de la brique applicative (2) 20 et générer, par l'intermédiaire du module (60) de gestion de performance applicative, des données de défaillances capables d'informer sur la nature et/ou la source de la défaillance. 11. Procédé d'analyse du comportement d'une brique applicative selon la revendication 25 10, caractérisé en ce qu'il comporte en outre une étape de sélection (720) d'au moins une instruction d'action corrective si une défaillance est identifiée et une étape d'application de l'action corrective identifiée (721). Réf [0594-BULL25]- Confidentiel