Brevet FR3098941A1 — publié le 20210122

Description Titre de l'invention : Dispositif et Procédé pour l'analyse de per- formances d'une application n-tier [0001] La présente invention concerne le domaine des tests de performance d'infrastructures informatiques. Plus particulièrement, l'invention porte sur un procédé et un système d'analyse de performances d'une application n-tier permettant la gestion de données confidentielles et/ou sensibles. Technique antérieure [0002] Les tests de performance (« Benchmark » en terminologie anglo- saxonne) peuvent avoir pour objectif de résoudre des problèmes de performance existants d'une application, de dimensionner une infrastructure nécessaire pour une application en fonction d'une utilisation donnée, de valider les performances, l'endurance, la robustesse d'une application n-tier, de comparer des évolutions (version d'application, optimisations, etc.), ou autre. [0003] De telles infrastructures informatiques sont par exemple des calculateurs hautes per- formances, généralement désignés sous leur appellation anglo-saxonne « clusters » HPC (HPC étant le sigle de « High Performance Computing »). Il peut également s'agir de réseaux de serveurs (par exemple n-tier). [0004] Les applications (ou logiciels) de test de performance permettent de simuler plusieurs utilisateurs simultanément. Par exemple, pour une infrastructure informatique d'application n-tier (un réseau de serveurs n-tier), l'application de test est capable d'envoyer vers l'infrastructure un très grand nombre de requêtes (par exemple au format SQL pour « structured query language » selon une terminologie anglo-saxonne), comme si elles provenaient d'utilisateurs simultanés différents. 100051 Ces applications permettent de créer un ou plusieurs scénarios de test en choisissant une ou plusieurs catégories de requêtes à faire exécuter par l'application testée et en choisissant un débit de requêtes pour chaque scénario. Les applications de test effectuent un certain nombre de mesures (temps de réponse de l'infrastructure, taux d'erreurs, ou autre) et génèrent un rapport de test. 100061 De manière générale, un test de performance d'infrastructure informatique, peut se dérouler en plusieurs étapes. Dans une première étape, la stratégie de test est définie, avec notamment la définition du contexte technique de l'architecture testée, le choix d'un ou plusieurs scénarios et la pondération de ces scénarios (c'est-à-dire la définition de l'importance relative des uns par rapport aux autres), la détermination de la volumétrie cible (c'est-à-dire le débit de requêtes souhaité pour le test), la détermination des types de requêtes à envoyer en fonction des objectifs du test, et la définition de 2 l'architecture testée. [0007] Ensuite, l'environnement du test est mis en place. Il s'agit par exemple d'appliquer une certaine configuration à l'architecture informatique testée pour pouvoir tester cette configuration en particulier. [0008] Les scénarios de test sont ensuite définis au moyen d'applications de test (par exemple JMeter®) puis modifiés pour être paramétrables. Ensuite, à partir de ces définitions, les jeux d'injection d'instructions sont construits. Il s'agit de définir les paramètres des requêtes à envoyer vers l'infrastructure testée pour mettre en oeuvre les scénarios. Des scripts d'ordonnancement sont ensuite générés pour exécuter de façon chronologique les tâches nécessaires à la mise en oeuvre des requêtes selon les jeux d'injection. Enfin, les requêtes sont exécutées lors d'une « campagne de tir » et les résultats sont mesurés et analysés pour générer un rapport. [0009] Ainsi, pour réaliser ces tests de performance, il est nécessaire de disposer d'un jeu de données suffisant pour tester l'applicatif. Pour ce faire, une première solution consiste à utiliser les données de production de l'applicatif pour réaliser de tels tests de performance. Cependant, l'utilisation de telles données de production peut s'avérer impossible, notamment lorsque celles-ci contiennent des informations sensibles et/ou confidentielles ne pouvant être communiquées à des tiers. Il est alors d'usage de créer un jeu de données de test afin de pouvoir réaliser les tests de performance tout en respectant les règles de confidentialité des données imposées par les normes de régulation européennes. [0010] Néanmoins, la création d'un jeu de données test peut s'avérer très complexe et chronophage de par la volumétrie dont il faut disposer pour effectuer de tels tests, mais également de la complexité à modifier les données d'origine pour respecter les normes de confidentialité. [0011] Actuellement, les solutions connues ne permettent pas de tester l'applicatif à partir des données de production, il existe donc un besoin pour de nouvelles solutions permettant d'utiliser des données de production pour réaliser des tests de performance tout en garantissant la confidentialité et la cohérence de ces données. [Problème technique] [0012] L'invention a donc pour but de remédier aux inconvénients de l'art antérieur. En par- ticulier, l'invention a pour but de proposer un procédé d'analyse de performances d'une application n-tier comportant un traitement d'anonymisation à la volée de données de production, ledit procédé permettant d'assurer la confidentialité des données sensibles desdites données de production tout en utilisant l'ensemble des données de production pour réaliser les tests de performance. [0013] L'invention a en outre pour but de proposer un dispositif d'analyse de performances d'une application n-tier, ledit dispositif permettant la réalisation de tests de per- 3 formance à partir de données de production, dans le cadre d'applications n-lier, tout en assurant l'anonymisation des données sensibles desdites données de production. [Brève description de l'invention] 100141 A cet effet, l'invention porte sur un procédé pour l'analyse de performances d'une application n-fier comportant un traitement d'anonymisation à la volée de données de production, lesdites données de production étant générées suite à un message de requête de test de performances transmis à un serveur de persistance, [0015] ledit traitement d'anonymisation étant mis en oeuvre par un module d'anonymisation comportant une unité de traitement, un moyen de communication, et une mémoire de données configurée pour mémoriser un référentiel d'identification de données sensibles et un référentiel d'anonymisation, [0016] ledit traitement d'anonymisation à la volée de données de production de l'application n-ticr comprenant : [0017] une étape de réception, par un moyen de communication, d'un message de réponse au message de requête de test de performances, suite à l'émission dudit message de réponse par un serveur de persistance ; une étape d'identification, par l'unité de traitement à partir du référentiel d'identification dc données sensibles, dc données à anonymiscr dans le message de réponse ; une étape d'encodage, par l'unité de traitement à partir du référentiel d'anonymisation, comportant la génération de données anonymisées à partir des données à anonymiscr préalablement identifiées; une étape de génération, par l'unité de traitement à partir des données anonymisées et du message de réponse, d'un message de réponse anonymisé ; et une étape d'envoi, par le moyen de communication, du message de réponse anonymisé à un serveur métier, ledit message de réponse anonymisé comportant des données nécessaires à l'analyse de performances de l'application n-tier. [0018] Un tel procédé permet d' anonymiser à la volée des données de production d'une ap- plication n-tier au fur et à mesure qu'elles sont transmises par l'application n-tier. Ainsi, un utilisateur peut s'affranchir d'une étape fastidieuse de transformation d'un jeu de données avant la mise en place d'un test de performance. De plus, l' administrateur de l' application n-tier sait que ces données seront anonymisées selon des procédures prédéterminées. Ainsi un tel procédé permet un gain de temps mais également des analyses au plus proche des conditions réelles. En outre, les analyses de performance peuvent être réalisées au niveau du module d'anonymisation, d'un poste client ou de tout autre dispositif déporté. Ce procédé permet de conserver l'intégralité du jeu de données initiales, lesdites données initiales étant en partie confidentielles, d'optimiser l'anonymisation en chiffrant une partie des données initiales et de conserver la cohérence des données initiales pour pouvoir effectuer les tests désirés. En particulier, ce procédé permet de produire un jeu de données à des fins d'analyse de performance dont seulement une partie desdites données est anonyrniséc, seules les données décrites par le référentiel d'anonymisation sont encodées et ainsi le reste des données demeurent « lisibles ». Un tel jcu de données produit en continue peut ainsi être utilisées lors des tests de performance tout en conservant la confidentialité des données. [0019] Cette anonymisation sélective d'un ensemble de données permet donc de fournir un jeu de données complet pour la réalisation de tests de performance sur des applications n-ticr en toute sécurité / confidentialité. [0020] Selon d'autres caractéristiques du procédé, ce dernier peut inclure faculta- tivement une ou plusieurs des caractéristiques suivantes, seules ou en combinaison : [0021] - il comporte en outre une étape d'enregistrement, sur un référentiel de corres- pondance entre des données sensibles et des données anonymisécs, d'une correspondance entre chacune des données à anonymiscr et chacune des données anonymisécs correspondantes. La présence d'un tel référentiel et de cet enregistrement de correspondance permet de plus rapidement désanonymiscr les données. Alternativement, un algorithme de désanonymisation, opposé à l'algorithme utilisé pour anonymiser les données, peut être utilisé. Les données sensibles sont des données qu'il convient d'anonymiser. il comporte en outre une étape de mesure d'une pluralité de paramètres de fonctionnement de l'application n-tier, de préférence au moins en partie à partir d'une pluralité de messages de réponse anonymisés. En outre cette étape peut comporter une mesure de consommation de ressources sur le deuxième dispositif par des sondes. Ainsi il sera possible de suivre les niveaux de service ou plus largement les performances de l'application n-tier au cours du temps. il comporte en outre une étape de génération d'au moins une valeur d'indicateur de performance de l'application n-tier. Cette étape de génération peut être réalisée par le module d' anonymisation, par un poste client ou par un autre dispositif tel que le serveur de persistance s'il est configuré ainsi. Ainsi, un utilisateur pourra disposer d'une information claire sur les performances de l'application n-tier. il comporte en outre une étape de génération d'au moins un plan de charge comportant au moins un scénario d'un test de performances apte à permettre une génération d'une pluralité de messages de requête. Cette génération au- tomatiséc, par exemple à partir de données antérieures, permet un gain de temps significatif dans le cadre de l'analyse de performance. Il comporte unc étape de comparaison des données d'un message de requête au référentiel de correspondance, et, lorsque ledit message de requête ne comprend aucune donnée anonymiséc, une transmission, par le moyen de communication, du message de requête au serveur de persistance. Une telle caractéristique permet une réelle interaction avec l'application n-tier lors de l'analyse de performance et cela sans qu'il y ait divulgation d'information sensible. Il comporte une identification d'une donnée anonymisée dans le message de requête puis une étape de restauration d'une donnée anonymisée, ladite étape de restauration comportant, par exemple à partir du référentiel de correspondance, la substitution dans le message de requête d'une donnée anonymisée par une donnée à anonymiser correspondante de façon à générer un message de requête restaurée. Une telle caractéristique permet une réelle interaction avec l'application n-ticr lors de l'analyse de performance et cela sans qu'il y ait divulgation d'information sensible. l'étape d'encodage correspond à une anonymisation et/ou à une pseudonymisation de tout ou partie des données à anonyrniscr. En particulier la pseudonymisation permet la réalisation d'une analyse de performance selon des règles métier ce qui ne serait pas possible si les informations étaient entièrement chiffrées. [0022] D'autres mises en oeuvre de cet aspect comprennent des systèmes informatiques, des appareils et des programmes informatiques correspondants enregistrés sur un ou plusieurs dispositifs de stockage informatiques, chacun étant configuré pour effectuer les actions d'un procédé selon l'invention. En particulier, un système d'un ou de plusieurs ordinateurs peut être configuré pour effectuer des opérations ou des actions particulières, notamment un procédé selon l'invention, grâce à l'installation d'un logiciel, micrologiciel, matériel ou d'une combinaison de logiciels, micrologiciels ou matériel installé sur le système. En outre, un ou plusieurs programmes informatiques peuvent être configurés pour effectuer des opérations ou des actions particulières grâce à des instructions qui, lorsqu'elles sont exécutées par un appareil de traitement de données, obligent l'appareil à effectuer les actions. [0023] Ainsi, l'invention porte en outre sur un produit programme d'ordinateur comportant une ou plusieurs instructions exécutables par une unité de traitement d'un module d'anonymisation, l'exécution desdites instructions, par exemple par ledit module d'anonymisation, provoquant la mise en oeuvre d'un procédé pour l'analyse de performances d'une application n-tier selon l'invention. 6 [0024] L'invention porte également sur un module d'anonymisation configuré pour exécuter un traitement d'anonymisation à la volée de données de production générées par une application n-ticr, lesdites données de production étant générées suite à un message de requête de test de performances transmis à ladite application n-ticr, ledit module d'anonymisation comprenant : [0025] un moyen de communication configuré pour recevoir un message de réponse au message de requête de test de performances, suite à l'émission dudit message de réponse par un serveur de persistance, une mémoire de données configure° pour mémoriser un référentiel d'identification de données sensibles et un référentiel d'anonymisation, une unité de traitement configurée pour analyser lesdits message de requête de test de performances et/ou message de réponse et pour mettre un oeuvre un traitement d'anonymisation à la volée des données de production, ladite unité de traitement étant en particulier configurée pour : - Identifier, à partir du référentiel d'identification de données sensibles, des données à anonymiser dans le message de réponse ; - Générer, à partir du référentiel d'anonymisation, des données anonymisées à partir des données à anonymiser préalablement identifiées ; et - Générer, à partir des données anonymisées et du message de réponse, un message de réponse anonymisé [0026] ledit moyen de communication étant aussi configuré pour envoyer le message de réponse anonymisé à un serveur métier, ledit message de réponse anonymisé comportant des données nécessaires à l'analyse de performances de l'application ntier. [0027] L'invention porte également sur un système pour l'analyse de performances d'une application n-tier comportant : [0028] un serveur de persistance configuré pour mémoriser des données pour l'exécution de l'application n-tier et pour recevoir un message de requête de test de performance et émettre un message de réponse à une requête ; un module d' anonyrnisation selon l'invention. [0029] 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 [0030] [fig.1] représente un schéma fonctionnel d'un système pour l'analyse de per- formances d'une application n-tier. [0031] [fig.2] représente un schéma des différentes étapes d'un procédé pour l'analyse de performances d'une application n-tier selon l'invention. Les étapes encadrées par des 7 pointillés sont facultatives. [0032] [fig.3] représente un schéma d'un traitement d'anonymisation d'un procédé pour l'analyse de performances d'une application n-ticr selon l'invention. [0033] 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. [0034] Sur les figures, les organigrammes et les schémas fonctionnels illustrent l'architecture, la fonctionnalité et le fonctionnement d'implémentations possibles de 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 un code, 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 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 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. [Description de l'invention] [0035] Dans la suite de la description, on entend par « dispositif électronique com- municant » tout dispositif informatique ou toute infrastructure informatique comprenant une ou plusieurs ressources matérielles et/ou logicielles configurées pour envoyer et/ou recevoir des messages de requête et stocker des informations relatives auxdits message de requête apte à faire fonctionner une application ou une chaine applicative. La structure informatique peut être un serveur ou plusieurs, et peut par exemple être composée d'un serveur de présentation, d'un serveur métier et d'un serveur de données. Le dispositif électronique communicant peut également être un serveur « test » avec les mêmes ressources qu'un serveur de production ou bien un clone d'un serveur virtuel de production. De façon préférée, une structure informatique est un serveur. [0036] L'expression « anonymisation à la volée de données de production » au sens de l'invention, correspond à une anonymisation dynamique des données de production, notamment suite à un message de réponse à une requête émis par un dispositif électronique communicant, tel qu'un serveur de persistance, à destination d'un dispositif électronique communicant tiers, comprenant par exemple un module d'accès à une 8 base de données. [0037] On entend par « message de requête de test de performances », le fait d'envoyer, par une application de test de performance, vers un dispositif électronique communicant tel qu'un serveur de persistance hébergeant une application n-tier, un message au format SQL. [0038] On entend par « application n-tier », une application hébergée par un serveur d'application d'une architecture n-ticr. Une architecture n-tier ou à n-niveaux consiste à segmenter une application selon plusieurs couches. Généralement, on retrouve au moins une couche responsable de la communication avec une base de données pouvant être représentée par une base de données SQL, des fichiers XML etc. Cela permet de communiquer directement avec cette couche de communication plutôt que directement avec une hase de données. On retrouve également une couche métier, qui forme le coeur de l'application et englobe tous les processus qui vont permettre de manipuler et transformer des données métier définies par une demande client (au travers de messages de requête). Enfin on retrouve une couche de présentation comprenant tout ce qui est affichage des données et interaction avec l'application. En aucun cas, la couche métier ou la couche de présentation ne peuvent communiquer directement avec la hase de données, cela permet ainsi d'assurer qu'une modification effectuée dans une couche n'impose aucun changement dans les autres. [0039] 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 des valeurs de paramètres de qualité de service, de l'état de fonctionnement des ressources ou de l'utilisation de ressources. [0040] Par « plan de charge prédéterminé », on entend au sens de l'invention un fichier de configuration de la charge ou contrainte à appliquer à un dispositif informatique ou à une infrastructure informatique. Le fichier de configuration peut par exemple être un fichier, ou un ensemble de fichiers, qui permet d'associer plusieurs données ou champs. Cette association de champs est aussi appelée un enregistrement de charge. Un tel fichier de configuration de charge est, par exemple, un fichier XML, un fichier CSV, un fichier INI, un fichier JSON.... Un fichier de configuration de charge peut comporter un ou plusieurs enregistrements de charge. Il peut être généré à partir d'information renseignées par un utilisateur. [0041] On entend par « Ressources » des ressources matérielles telles que des paramètres, des capacités ou des fonctions de dispositifs informatiques permettant le fonctionnement d'une application n-tier. Un même dispositif informatique est associé généralement à plusieurs ressources. Par exemple, le terme « ressource » peut inclure des ressources physiques ou virtuelles telles que des disques réseaux caractérisé par 9 exemple par leurs entrées/sorties (I/0), la lecture/écriture sur des disques, le taux d'utilisation de la mémoire, un réseau caractérisé par sa bande passante, un processeur caractérisé par exemple par son utilisation (en pourcentage) 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. [0042] Par « niveau d'une ressource » ou « niveaux de ressources », on entend au sens de l'invention une quantité de ressource. Par exemple, cela peut correspondre pour des disques réseaux, au nombre de disques réseaux disponibles ou à la quantité de mémoire disponible sur ces disques réseaux, pour un processeur, au nombre de coeurs ou au nombre de processeurs ou à la dimension des caches, pour une mémoire vive, à la quantité disponible, et pour des ports, le nombre de ports pouvant être ouverts simultanément. [0043] Par « niveau d'utilisation de ressources », on entend, au sens de l'invention, une valeur représentative de la consommation ou de l'occupation de ladite ressource lors du fonctionnement d'une chainc applicativc. Par exemple, la valeur d'utilisation peut correspondre pour des disques réseaux à leurs entrées/sorties, la lecture/écriture sur des disques, le taux d'utilisation de la mémoire, pour un réseau à sa bande passante, pour des processeurs à leur utilisation (en pourcent) ou au taux d'occupation des caches, pour de la mémoire vive la quantité utilisée et pour des ports, le nombre de ports ayant été ouverts simultanément lors du fonctionnement du procédé. La valeur d'utilisation est avantageusement ramenée au pourcentage du niveau de la ressource. [0044] L'expression « niveau de service » au sens de l'invention correspond à une qualité de service à laquelle peut s'engager un tiers et ainsi garantir de bonnes performances pour les applications critiques d'une organisation. Ainsi, le niveau de service peut correspondre à des critères objectifs tels que des débits et des temps de réponse associés à une application n-tier ou bien subjectif, et prendre par exemple la forme d'une échelle de valeur, 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. [0045] Les termes « transformation de données », au sens de l'invention, font référence à toute technique visant à anonymiser un jeu de données. Une transformation de données pourra ainsi correspondre à une technique de chiffrement de données, dont la fonction est de rendre illisible ou tout au moins intelligible un tel jeu de données, ou encore à une technique d'encodage d'un jeu de données dont la fonction est de remplacer une donnée par une donnée tiers tout en conservant la lisibilité et l'intelligibilité du jeu de données. A titre d'exemple, l'encodage de données peut correspondre à une technique de pseudonymisation. [0046] On entend par « indicateur de performances », la restitution à un utilisateur, notamment par l'intermédiaire d'une interface homme-machine adaptée, d'un rendu graphique suite à la réalisation d'un test de performance. Un tel indicateur de performances peut prendre la forme d'une ou plusieurs valeurs traduisant le niveau d'utilisation d'une ou plusieurs ressources, ou encore d'un graphique détaillant l'évolution du niveau d'utilisation d'une ou plusieurs ressources dans le temps et au cours de la phase de test. [0047] Le ternie « injection », au sens de l'invention, peut correspondre à l'envoi de messages de requêtes à destination d'une application n-ticr, lesdits messages de requête étant interceptés par un dispositif électronique communicant configure pour analyser et anonymiscr les données comprises dans lesdits messages. [0048] On entend par « traiter », « calculer », « déterminer », « afficher », « extraire » « comparer » ou plus largement « opération exécutable », au sens de une action effectuée par un dispositif ou un processeur sauf si le contexte indique autrement. À cet égard, les opérations se rapportent à des actions et / ou des processus d'un système de traitement de données, par exemple un système informatique ou un dispositif informatique électronique, qui manipule et transforme les données représentées en tant que quantités physiques (électroniques) dans les mémoires du système informatique ou d'autres dispositifs de stockage, de transmission ou d'affichage de l'information. Ces opérations peuvent sc baser sur des applications ou des logiciels. [0049] Les termes ou expressions « application », « logiciel », « code de programme », et « code exécutable » signifient toute expression, code ou notation, d'un ensemble d'instructions destinées à provoquer un traitement de données pour effectuer une fonction particulière directement ou indirectement (e.g. après une opération de conversion vers un autre code). Les exemples de code de programme peuvent inclure, sans s'y limiter, un sous-programme, une fonction, une application exécutable, un code source, un code objet, une bibliothèque et/ou tout autre séquence d'instructions conçues pour l'exécution sur un système informatique. [0050] On entend par « processeur », au sens de l'invention, au moins un circuit matériel configuré pour exécuter des opérations selon des instructions contenues dans un code. Le circuit matériel peut être un circuit intégré. Des exemples d'un processeur comprennent, sans s'y limiter, une unité de traitement central, un processeur graphique, un circuit intégré spécifique à l'application (ASIC) et un circuit logique programmable. [0051] L'expression « interface homme-machine » au sens de l'invention correspond à tout élément permettant à un être humain de communiquer avec un ordinateur en particulier et sans que cette liste soit exhaustive, un clavier et des moyens permettant en réponse aux ordres entrés au clavier d'effectuer des affichages et éventuellement de sélectionner à l'aide de la souris ou d'un pavé tactile des éléments affichés sur l'écran. Un autre exemple de réalisation est un écran tactile permettant de sélectionner di- 11 rectement sur l'écran les éléments touchés par le doigt ou un objet et éventuellement avec la possibilité d'afficher un clavier virtuel. [0052] Dans la suite de la description, les mêmes références sont utilisées pour désigner les mêmes éléments. [0053] De manière générale, des processus de test de performances sont généralement requis dans le cadre de la création d'une application n-ticr mais également tout au long de son exploitation. En particulier, ces processus permettent, pour une application n-ticr et le dispositif informatique la supportant, de détecter les limites de performances, les faiblesses, et permettent par conséquent de déterminer les corrections à apporter, ainsi que de quantifier les gains apportés par ces éventuelles corrections. [0054] Il se trouve, à cet égard, différents outils (ou logiciels) de test de performances permettant de simuler divers scénarios d'utilisation d'un dispositif informatique cible pour en détecter les défauts. Parmi ces outils, on cite, à titre d'exemples, l'outil WebLOADC) (proposé par RADVIEWO), l'outil LoadRunner® (proposé par HPC)), l'outil Rational Performance Tester® (proposé par MME)), SOAtest® & LoadTest® (proposé par PARASOFTO), l'outil TOSCA-Testsuite®, ou l'outi1JMeter0 (un logiciel libre édité par la Fondation Apache0). [0055] Faisant généralement partie d'un kit de test de performances, ces outils permettent, en effet, de stresser un système d'information via une injection d'une ou de plusieurs charges. Une telle charge peut correspondre à l'envoi simultané de requêtes, conformément à des scénarios prédéfinis et à des instanciations différentes de ces scénarios. Notamment, ces différents types de scénarios peuvent inclure la simulation de Bugs par la reproduction d'anomalies, ce genre de test nécessite généralement de disposer d'une volumétrie très importante de données de production. Dans la plupart des cas, ces tests de performance se font sur des jeux de données qui ont été préalablement anonymisés. [0056] Néanmoins, 1' anonymisation préalable d'un jeu de données est d'une part très chronophage et d'autre part limite les possibilités de test de performance. Ainsi, les inventeurs ont développé un procédé et un dispositif de performance comportant une anonyrnisation à la volée des données, en particulier de données de production. [0057] Ainsi, selon un premier aspect, l'invention porte sur un module d'anonymisation 10 configuré pour exécuter un traitement d'anonymisation à la volée de données de production. Ces données de production anonymisées sont particulièrement utiles pour l'analyse de performances d'une application n-tier. En particulier, et comme illustré à la figure 1, un module d' anonymisation 10 selon l'invention peut comporter une unité de traitement 11, un moyen de communication 12, une mémoire de données 13 et un module d'accès à une base de données 17. [0058] L'unité de traitement 11 peut comporter un processeur pour l'exécution d'au moins 12 une fonction d'analyse et de traitement de message de requête. En outre, l'unité de traitement 11 peut comporter ou être couplée à d'autres moyens tels que des combinaisons de processeurs, de mémoire ainsi que de codes supportant des instructions ou à une mémoire de données comportant une pluralité de référentiels mémorisés. L'unité de traitement 11 peut en particulier être configurée pour analyser lesdits message de requête MR1, MR2 de test de performances et/ou message de réponse MRR1, MRR2. En outre, elle peut mettre un oeuvre un traitement d'anonymisation à la volée des données de production. L'unité de traitement 11 étant en particulier configurée pour identifier, à partir du référentiel d'identification de données sensibles 14, des données à anonymiscr dans le message de réponse MRR1, MRR2 ; générer, à partir du référentiel d'anonymisation 15, des données anonymisées à partir des données à anonymiser préalablement identifiées ; et générer, à partir des données anonymisées et du message de réponse MRR2, un message de réponse anonymisé MRR2'. [0059] Le moyen de communication 12 est apte à échanger des données avec des dis- positifs électroniques communicant tiers. Le moyen de communication 12 peut correspondre à tout élément ou combinaison d'éléments permettant à un utilisateur d'émettre des requêtes, par l'intermédiaire d'un réseau de communication (par exemple LAN, WLAN, ou PAN, journal d'une base de données, courriel), vers des dispositifs tiers. Avantageusement, il est configure pour recevoir un message de requête MR1, MR2 de test de performances et/ou un message de réponse MRR1, MRR2 et pour transmettre un message de requête de test de performance restauré MR2' ou non MR1 et/ou un message de réponse à une requête anonymisé MRR2'ou non MRR1. [0060] La mémoire de données 13 est avantageusement configurée pour mémoriser un ré- férentiel d'identification de données sensibles 14 et un référentiel d'anonymisation 15. Elle peut en outre être configurée pour mémoriser un référentiel de correspondance 16 entre des données sensibles et des données anonymisées. La mémoire de données 13 peut comprendre une mémoire transitoire et/ou une mémoire non transitoire. La mémoire non transitoire peut être un support tel qu'un CDrom, une carte mémoire, un disque dur local ou un disque dur hébergé par un serveur distant. De préférence, la mémoire de données 13 prend la forme d'un disque dur local. La mémoire de données 13 est notamment apte à enregistrer, par exemple sous la forme d'un ou plusieurs fichiers, des données générées par une IHM (pour Interface Homme Machine) ou par des sondes de consommation ou encore des données acquises par l'intermédiaire d'un autre module. Les données mémorisées peuvent avoir été renseignées, dès la mise en route ou au cours du temps, par un utilisateur via une IHM. [0061] Un module d'anonymisation 10 selon l'invention peut être porté par un dispositif électronique communiquant dédié ou peut être intégré dans une des composantes de l'application n-tier. Ainsi, le module d'anonymisation 10 peut être intégré à un serveur 13 de persistance 20, à un serveur métier 30 ou encore à un serveur de présentation 40. [0062] Ainsi, selon un autre aspect, l'invention porte sur un système 2 pour 1"analyse de performances d'une application n-tier. Un exemple d'un système 2 pour l'analyse de performances d'une application n-ticr selon l'invention est présenté en figure 1. Outre, un module d'anonymisation 10 pour l'analyse de performances d'une application n-ticr selon l'invention, un tel système peut comporter un serveur de persistance 20 configure pour recevoir un message de requête MR1, MR2' de test de performance et/ou émettre un message de réponse à une requête MRR1, MRR2'. [0063] En particulier le deuxième dispositif communicant peut correspondre à une infra- structure informatique comportant un ou plusieurs serveurs. [0064] De manière avantageuse, un tel système peut comprendre un serveur de présentation 40 configure pour recevoir et transmettre un message de réponse à une requête de test de performances, anonymisé MRR2' ou non MRR1. [0065] Quand il est fait référence au système 2 selon l'invention, celui-ci est assimilable à un système comprenant une architecture n-ticr avec : [0066] une couche de présentation de l'application responsable de l'affichage des données et de l'interaction avec l'application n-ticr correspondante au travers d'une interface homme-machine adaptée et exécutée par un serveur de présentation 40, une couche métier de l'application responsable de tous les processus qui vont permettre de manipuler et transformer des données métier définies par une demande client (au travers de messages de requête émis par un poste client PC) et exécutée par un serveur métier 30, un module d' anonyrnisation 10, et une base de données représentée par un serveur de persistance 20. [0067] Avantageusement, un tel système peut comporter un poste client PC à partir duquel un opérateur peut piloter un test de performance et au travers duquel sont émis des messages de requête à destination d'un serveur de persistance 20. [0068] C'est par exemple au sein d'un tel système que peut s'exécuter un procédé selon l'invention. En effet, selon un autre aspect, l'invention porte sur un procédé pour l'analyse de performances d'une application n-tier comportant un traitement d'anonymisation 400 à la volée de données de production. Un tel procédé peut être mis en oeuvre par un module d' anonymisation 10 tel que décrit précédemment. [0069] Comme illustré à la figure 2 et comme cela sera détaillé par la suite, un procédé selon l'invention comporte une étape de traitement d'anonymisation 400 à la volée de données de production d'une application n-tier. [0070] En outre, il peut comporter des étapes d'acquisition 100 de données, de génération 200 d'un plan de charge, d'injection 300 d'une charge applicative, de mesure 500 14 d'une pluralité de paramètres de fonctionnement de l'application n-ticr, et de génération 600 d'au moins une valeur d'indicateur de performance de l'application n-ticr. [0071] Un tel procédé comprend avantageusement une étape d'acquisition 100 de données . Cette étape d'acquisition 100 peut par exemple être réalisée par une unité de traitement d'un poste client PC. [0072] Cette étape d'acquisition 100 correspond par exemple au chargement de paramètres et règles de fonctionnement permettant la mise en oeuvre du procédé. Cette étape peut être réalisée juste avant les étapes suivantes du procédé. Cette étape d'acquisition 100 de données comporte plus particulièrement le chargement de données, de préférence mémorisées sur une mémoire de données d'un dispositif électronique communiquant PC,10 en charge d'effectuer le test de performances de l'application n-ticr. Les données acquises peuvent inclure des données d'identification de ressources utilisées et de leur niveau d'utilisation maximum par le dispositif informatique mettant en oeuvre l'application n-ticr testée, des données correspondant à des seuils prédéterminés de paramètre de qualité de service, au-delà desquels l'application n-ticr testée est considérée en défaillance, des règles de consommation des ressources et un plan de charge prédéterminé représentatif du fonctionnement de l'application n-ticr testée. [0073] Une fois l'étape d'acquisition 100 de données effectuée, un procédé selon l'invention peut comporter une étape de génération 200 d'un plan de charge. Cette étape de génération 200 d'un plan de charge peut par exemple être mise en oeuvre par une unité de traitement d'un poste client PC. [0074] Comme décrit précédemment, un plan de charge peut être préalablement enregistré sur une mémoire de données du poste client ou plus généralement du dispositif électronique communicant en charge d'effectuer le test de performances de l'application ntier. Ainsi, une pluralité de plan de charges peuvent être enregistrés dans une telle mémoire de données, chaque plan de charge pouvant être associé à un scénario particulier d'un test de performances, tel qu'un test de non régression, un test de recherche de limites notamment associées à une charge utilisateur maximale ou encore à une vitesse de traitement, un test d'endurance consistant à déterminer la tenue des limites de performances dans le temps avant qu'apparaissent des dérives de performances, un test de « crash » visant à analyser le comportement d'un ou de plusieurs serveurs sur lesquels est mis en oeuvre l'application n-tier. Ainsi, un plan de charge peut être représentatif du fonctionnement classique, ou de la charge nominale, de l'application n-tier à tester, ou peut être utilisé pour générer des contraintes sur le dispositif informatique simulant l'activité et donc l'utilisation de ressources par l'application n-tier à tester, tels que selon les scénarios de test de performances décrit juste avant. La charge nominale correspond à l'activité courante sur l'applicatif ou la charge habituellement observée en production pour l'application n-tier. Cela peut correspondre par exemple à une distribution dc différents types de scénarios reproduisant les principales actions impliquées dans la mise en oeuvre de l'application n-ticr, avec par exemple combien de scénarios à l'heure de chacun des types doit être joué pour mimer le fonctionnement de l'utilisation de l'application n-ticr. [0075] Ainsi, un plan de charge peut avantageusement comporter des valeurs sur les pa- ramètres suivants : les différents types de scénario, la pondération de chacun de ces scénarios métiers (c.g. la proportion relative des uns par rapport aux autres), et le niveau de charge globale (e.g.la volumétrie cible ou le débit de requêtes souhaité au cours du procédé). De façon équivalente, il peut comporter des informations sur le nombre de scénarios de chaque type exécuté en simultané, par exemple pendant une heure. TI peut aussi comporter des informations sur le dispositif informatique testée. [0076] Un plan de charge peut ainsi se caractériser par un ensemble de requêtes, géné- ralement enregistrées dans un fichier de commande de charge comportant le code devant être exécuté. L'exécution du fichier de commande de charge peut produire un certain nombre d'actions aussi diverses que la création, la consultation, la modification, la suppression de fichiers ou l'impression, la copie et l'affichage de données. Ces actions seront généralement similaires aux actes métiers principaux pris en charge lors de l'utilisation dc l'application n-tier. Ainsi, comme cela sera détaillé par la suite, un procédé selon l'invention peut également comporter une étape d'injection d'une charge applicativc. [0077] Avantageusement, un plan de charge peut comporter un référentiel de charge ap- plicative configuré pour mémoriser des champs relatifs à la date de début de la charge, il s'agit par exemple d'une date absolue évaluée relativement à une horloge interne du dispositif informatique réalisant le test de l'application n-tier ou d'une date relative au début d'un scénario de test. El peut également comprendre la date de fin de la charge ou la durée de la charge, par exemple un nombre de secondes. [0078] Suite à la génération d'un plan de charge, un procédé 1 d'analyse de performances d'une application n-tier peut comporter une étape d'injection 300 de la charge applicative relative à un scénario de test de performances préalablement déterminé. Ladite étape d'injection 300 de la charge applicative peut être mise en oeuvre par un module d'injection porté par un dispositif électronique communicant PC,10. [0079] Les données de charge, contenues dans le plan de charge, peuvent être utilisées par le module d'injection afin de réaliser un plan de charge permettant de simuler une activité d'une application n-tier avec par exemple l'ouverture et l'envoi de fichiers, des sauvegardes ou encore de la navigation sur internet. [0080] La soumission du dispositif informatique à la charge applicative est de façon préférée obtenue en utilisant des mécanismes d'injection tels que JMeter®, Tsung® ou Gatling®. De préférence, cela est réalisé par l'injection de requêtes selon un plan de 16 charge prédéterminé. [0081] Lors de l'étape d'injection, un dispositif électronique tel que le poste client PC enverra des requêtes à destination d'une application n-ticr et ces requêtes seront avantageusement interceptées par le module d'anonymisation 10. Pour permettre l'utilisation en continue des données en production de l'application n-ticr à tester, un procédé 1 d'analyse de performances d'une application n-ticr conforme à l'invention comporte un traitement d'anonymisation 400 à la volée. Le traitement d'anonymisation 400 à la volée peut être mis en oeuvre par une unité de traitement 1 1 . Cette unité de traitement 11 peut être intégrée au serveur de persistance 20 ou bien être déporté dans un module d'anonymisation 10, pouvant notamment comprendre un module d'accès à une base de données 17, tel qu'à titre d'exemple non limitatif un driver de base de données. Le traitement d'anonymisation 400 suit généralement l'étape d'injection 300 de la charge applicative. [0082] Pour permettre le respect des politiques de confidentialité relatives à un aspect métier particulier, il convient de procéder à une anonymisation de tout ou partie des données en production utilisées pour la réalisation d'un test de performances. Un tel aspect métier peut par exemple correspondre à un ensemble de règles préétablies à partir desquelles des données sensibles seront déterminées. [0083] Ainsi, le traitement d'anonymisation peut comporter une transformation des données sensibles issues de données de production, selon toute technique de transformation de données adaptée. De manière avantageuse, une telle transformation peut correspondre à toute technique de cryptage de données visant à rendre celles-ci incompréhensibles lors de leur lecture par un dispositif tiers, notamment un poste client PC. De préférence, une telle transformation des données sensibles issues de données de production, peut correspondre à toute technique d'encodage de manière à conserver une cohérence entre une donnée jugée sensible, donc une donnée à anonyrniser, et la donnée transformée correspondante, c'est-à-dire la donnée anonymisée, et permettre sa compréhension lors de leur lecture par un dispositif tiers, notamment un poste client PC. En effet, pour la réalisation de tests de performances il peut être primordiale qu'au moins une partie des données encodées soient accessibles, l'encodage de données sensibles permet alors de substituer la donnée sensible par une donnée de même nature anonymisée A titre d'exemple non limitatif, une donnée sensible relative à un prénom masculin pourra être encodée de sorte que celle-ci soit remplacée par une donnée encodée (i.e. anonymisée) relative à un autre prénom masculin et ne permettant ainsi pas d'identifier la personne. [0084] Comme décrit précédemment, l'étape d'injection 300 d'une charge applicative peut correspondre à l'envoi d'un ou de plusieurs messages de requêtes. De tels messages de requêtes peuvent consister en une requête émise sous un protocole de communication 17 HTTP (« Hypertext Transfer Protocol » selon une terminologie anglo-saxonne) codant une commande de type GET par exemple. Ainsi, un traitement d'anonyrnisation 400 à la volée pourra de préférence comporter une modification d'une requête, par exemple de type SQL émise sous un protocole de communication de type HTTP, avant sa transmission à l'application n-tier sujette au test de performance. [0085] Un mode de réalisation d'un traitement d'anonymisation sera maintenant détaillé en lien avec la figure 3. [0086] Un traitement d'anonymisation 400 selon l'invention peut comprendre une étape de comparaison 411 des données d'un message de requête MR1 à un référentiel de correspondance 16 entre des données sensibles et des données anonymisées suite à la réception dudit message de requête préalablement émis par un poste client PC. Cela permet avantageusement d'identifier une ou plusieurs données anonymisées. [0087] Ainsi, si l'étape de comparaison 411 ne permet pas l'identification de données ano- nymisées, le message de requête MR1 est directement transmis 411n par le moyen de communication 12 du module d'anonymisation 10 au serveur de persistance. Lors de l'initiation de l'envoi d'un message de requête MR1, ce dernier peut coder une demande d'accès à une page d'accueil de l'application n-ticr à tester. Nous partirons du principe que lors de l'initialisation de l'envoi d'un message de requête MR1, celui-ci ne contient aucune donnée anonymiséc. [0088] En revanche, au cours d'un test de performances, de multiples messages de requêtes sont généralement échangés. L'accès à ces données de production s'avère bien souvent nécessaire pour la mise en oeuvre d'un procédé d'analyse de performances d'une application n-tier. [0089] Supposons que le serveur de persistance 20 comprenne des données associées au domaine médical, telles qu'à titre d'exemple non limitatifs des données de remboursement de produits médicamenteux prescrits par un médecin traitant pour un individu donné, le nom, le prénom, la date de naissance, le sexe ou encore le numéro de sécurité sociale associé audit individu. [0090] Ainsi, un message de requête MR2 peut comporter une ou plusieurs données ano- nymisées, pour lesquelles une correspondance entre chaque donnée anonymisée et le référentiel de con-espondance 16 pourra être identifiée 411y lors de l'étape de comparaison 411. [0091] L'identification de données anonymisées est suivie d'une étape de restauration 412 d'une donnée anonymisée, en comparant chaque donnée anonymisée préalablement identifiée au référentiel de correspondance 16 afin d'identifier la donnée correspondante qui avait préalablement fait l'objet d'une anonymisation. Pour illustrer une telle identification, supposons qu'un premier message de requête encodant une commande d'accès aux données médicales d'individus ait été préalablement émis et 18 que ces données, une fois anonymisécs aient été communiquées au poste client PC. Le message de requête MR2 pourrait par exemple correspondre à un message de requête encodant des données commandant un accès aux remboursements et aux médicaments associés à un individu donné, dont un exemple est illustré ci-après. [0092] REVENDICATIONSProcédé (1) pour l'analyse de performances d'une application n-ticr comportant un traitement d'anonymisation (400) à la volée de données de production, lesdites données de production étant générées suite à un message dc requête (M RI, MR2') de test de performances transmis à un serveur dc persistance (20), ledit traitement d'anonymisation (400) étant mis en oeuvre par un module d'anonymisation (10) comportant une unité de traitement (11), un moyen de communication (12), et une mémoire de données (13) configurée pour mémoriser un référentiel d'identification de données sensibles (14) et un référentiel d'anonymisation (15), ledit traitement d'anonymisation (400) à la volée de données de production de l'application n-tier comprenant : - une étape de réception (420), par un moyen de communication (12), d'un message de réponse (MRR1, MRR2) au message de requête (MR1, MR2') de test de performances, suite à l'émission dudit message de réponse (MRR1, MRR2) par un serveur de persistance (20) ; - une étape d'identification (430), par l'unité de traitement (11) à partir du référentiel d'identification de données sensibles (14), de données à anonymiser dans le message de réponse (MRR1, MRR2) ; - une étape d'encodage (440), par l'unité de traitement (11) à partir du référentiel d'anonymisation (15), comportant la génération de données anonymisées à partir des données à anonymiser préalablement identifiées; - une étape de génération (460), par l'unité de traitement (11) à partir des données anonymisées et du message de réponse (MRR2), d'un message de réponse anonymisé (MRR2') ; et - une étape d'envoi (470), par le moyen de communication (12), du message de réponse anonymisé (MRR2') à un serveur métier (30), ledit message de réponse anonymisé (MRR2') comportant des données nécessaires à l'analyse de performances de l'application n-tier. Procédé (1) pour l'analyse de performances d'une application n-tier selon la revendication précédente, caractérisé en ce qu'il comporte en outre une étape d'enregistrement. (450), sur un référentiel de correspondance (16) entre des données sensibles et des données anonymisées, d'une correspondance entre chacune des données à anonymiser et chacune des données anonymisées correspondantes. 25 [Revendication 3] [Revendication 4] [Revendication 5] [Revendication 6] [Revendication 7] [Revendication 8] [Revendication 9] Procédé (1) pour l'analyse de performances d'une application n-ticr selon l'une des revendications 1 ou 2, caractérisé en ce qu'il comporte en outre une étape de mesure (500) d'une pluralité de paramètres de fonctionnement de l'application n-tier, de préférence au moins en partie à partir d'une pluralité de messages de réponse anonymisés (MRR2'). Procédé (1) pour l'analyse de performances d'une application n-ticr selon la revendication précédente, caractérisé en cc qu'il comporte en outre une étape de génération (600) d'au moins une valeur d'indicateur de performance de l'application n-ticr. Procédé (1) pour l'analyse de performances d'une application n-ticr selon l'une quelconque des revendications précédentes, caractérisé en cc qu'il comporte en outre une étape de génération (200) d'au moins un plan de charge comportant au moins un scénario d'un test de performances apte à permettre une génération d'une pluralité de message de requête (MR1, MR2). Procédé (1) pour l'analyse de performances d'une application n-ticr selon l'une des revendications 2 à 5, caractérisé en ce qu'il comporte une étape de comparaison (411) des données d'un message de requête (MR1, MR2) au référentiel de correspondance (16), et, lorsque ledit message de requête (MR1) ne comprend aucune donnée anonymisée, une transmission (411n), par le moyen de communication (12), du message de requête (MR1) au serveur de persistance (20). Procédé (1) pour l'analyse de performances d'une application n-tier selon la revendication précédente, caractérisé en ce qu'il comporte une identification (411y) d'une donnée anonymisée dans le message de requête (MR2) puis une étape de restauration d'une donnée anonymisée (412), ladite étape de restauration comportant, par exemple à partir du référentiel de correspondance (16), la substitution dans le message de requête (MR2) d'une donnée anonymisée par une donnée à anonymiser correspondante de façon à générer un message de requête (MR2') restaurée. Procédé (1) pour l'analyse de performances d'une application n-tier selon l'une quelconque des revendications précédentes caractérisé en ce que l'étape d'encodage (440) correspond à une anonymisation et/ou à une pseudonymisation de tout ou partie des données à anonymiser Produit programme d'ordinateur d'analyse de performances d'une application n-tier comportant une ou plusieurs instructions exécutables par une unité de traitement d'un module d'anonymisation (10), caractérisé 26 [Revendication 10] [Revendication 11] en ce que l'exécution desdites instructions provoque la mise en oeuvre d'un procédé (1) pour l'analyse de performances d'une application ntier selon l'une quelconque des revendications 1 à 8. Module d'anonymisation (10) configuré pour exécuter un traitement d'anonymisation à la volée de données dc production générées par une application n-ticr, lesdites données de production étant générées suite à un message de requête de test de performances transmis à ladite application n-ticr, ledit module d'anonymisation comprenant : - un moyen de communication (12) configuré pour recevoir un message de réponse (MRR1, MRR2) au message de requête de test de performances (MR1, MR2), suite à l'émission dudit message de réponse (MRR1, MRR2) par un serveur dc persistance, - une mémoire de données (13) configurée pour mémoriser un référentiel d'identification de données sensibles (14) et un référentiel d'anonymisation (15), - une unité de traitement (11) configurée pour analyser lesdits message de requête (MR1, MR2) de test de performances et/ou message de réponse (MRRI, MRR2) et pour mettre un oeuvre un traitement d'anonymisation à la volée des données de production, ladite unité de traitement (11) étant en particulier configurée pour : - Identifier, à partir du référentiel d'identification de données sensibles (14), des données à anonymiser dans le message de réponse (MRR1, MRR2) ; - Générer, à partir du référentiel d'anonymisation (15), des données anonymisées à partir des données à anonymiser préalablement identifiées ; et - Générer, à partir des données anonymisées et du message de réponse (MRR2), un message de réponse anonymisé (MRR2'). ledit moyen de communication (12) étant aussi configuré pour envoyer le message de réponse anonymisé (MRR2') à un serveur métier, ledit message de réponse anonymisé (MRR2') comportant des données nécessaires à l'analyse de performances de l'application n-tier. Système (2) pour l'analyse de performances d'une application n-tier comportant : - un serveur de persistance (20) configuré pour mémoriser des données pour l'exécution de l'application n-tier et pour recevoir un message de requête (MR1, MR2') de test de performance et émettre un message de réponse à une requête (MRRI, MRR2) ; 27 - un module d'anonymisation (10) selon la revendication 10.