FR 2854260 A1 20041029 FR 0305205 A 20030428 Procédé d'optimisation dynamique des performances d'applications, dispositif et programme d'ordinateur correspondants. Le domaine de l'invention est celui des serveurs et de l'exécution d'applications sur ces serveurs. De façon générale, une application est constituée d'un ensemble de composants logiciels et/ou sous-ensembles fonctionnels. Plus précisément, l'invention concerne les serveurs et/ou sites spécialisés dans l'hébergement d'applications accessibles à distance au travers d'un réseau maillé, du type Internet, par exemple. L'invention s'applique notamment à l'optimisation du fonctionnement et des performances d'une application sur un ou plusieurs serveurs. Ces performances dépendent en partie de la qualité du paramétrage des composants logiciels et/ou sous-ensembles fonctionnels qui la composent, mais surtout de sa charge à un instant donné, plus particulièrement lorsque cette application est 15 rendue simultanément accessible, à distance et au travers d'un réseau, à de multiples utilisateurs. La charge d'une application peut être plus ou moins importante. Elle peut varier dans le temps en fonction de différents paramètres, parmi lesquels: - le nombre des utilisateurs sollicitant simultanément l'application; - le nombre de requêtes d'information et/ou de téléchargement émises par chaque utilisateur à un instant donné vers l'application; - le type de données (statiques ou dynamiques) requises par les utilisateurs; - la capacité des différents constituants de l'application à pouvoir 25 assurer le service rendu par l'application pour un nombre important d'utilisateurs. Différentes solutions ont été apportées selon l'art antérieur pour répondre au problème de l'amélioration et l'optimisation des applications (encore appelée " tunning " en anglais). Ces solutions visent en particulier à tirer le meilleur parti possible de l'infrastructure matérielle et/ou logicielle sur laquelle repose l'application. Cependant, dans la grande majorité des cas, ces solutions concernent des applications rendues accessibles uniquement sur un réseau d'entreprise, et/ou de 5 type intranet, et pour lesquelles la charge maximum possible à un instant donné peut être préalablement évaluée, le nombre des utilisateurs (individus et/ou autres machines " clientes ") potentiels étant parfaitement connu lors de leur mise en service. Les solutions de l'art antérieur pour les applications précitées sont donc 10 plutôt orientées vers une optimisation statique et figée de leurs temps d'accès et de réponse ou de leur niveau de sûreté de fonctionnement. Parmi les solutions de l'art antérieur, la demande de brevet français n0 FR 0208 275 par la même demanderesse que la présente demande de brevet décrit un procédé de réglage automatique d'un ensemble de paramètres d'une application, de 15 façon à optimiser ses performances pour un profil de charge donné. De façon plus détaillée, chaque paramètre de l'application est optimisé séquentiellement en utilisant un profil de charge simulée à l'aide d'un outil logiciel de tests en charge. Une fois cette première étape d'identification des paramètres de performance optimaux effectuée, une seconde étape consiste alors à configurer l'application en 20 y intégrant ces paramètres de façon à tenter de répondre de la meilleure façon possible aux contraintes d'utilisation réelles. Cependant, la solution décrite dans la demande de brevet français no FR 0208275 présente un certain nombre d'inconvénients. En particulier, les performances offertes dépendent uniquement d'un profil de charge statique. Cette 25 solution ne tient donc pas compte du caractère nécessairement non déterministe et aléatoire du comportement des utilisateurs, celui-ci n'étant ni stable, ni reproductible dans le temps. Or, de telles contraintes non maîtrisables du comportement des utilisateurs peuvent avoir certaines conséquences sur le comportement de l'application sollicitée, sa charge pouvant varier de façon: - temporelle: forte sollicitation de l'application à certaines heures de la journée et, à contrario, faible activité aux heures creuses; - événementielle: en fonction du comportement non connu et aléatoire des utilisateurs. Or, il est important de préciser qu'une application qui a été bien optimisée pour un profil de faible charge ne le sera pas forcément pour un profil de forte charge, et réciproquement dans le cas inverse. De plus, dans le cadre d'une évaluation préliminaire du comportement de l'application exécutée sur un serveur accessible depuis l'Internet, à l'aide d'un 10 outils de test en charges, le résultat obtenu est nécessairement non exhaustif. Il existe un effet un grand nombre d'événements aléatoires (liés au comportement des utilisateurs et/ou aux constituants logiciels et/ou matériels de l'application) qui peuvent remettre en cause les hypothèses de trafic initialement retenues à l'issue de la simulation réalisée avec " l'outil de tests en charge ". On peut donner 15 à titre d'exemple illustratif, un changement inattendu du comportement des utilisateurs (modification de la nature des requêtes suite à un incident ou séries d'actions spécifiques à certains moments de l'année: bilans, événements festifs, promotions commerciales, etc.). L'inconvénient principal de cette solution selon l'art antérieur concerne 20 donc l'aspect statique et figée de la configuration de l'application suivant un unique profil de charge qui ne peut évoluer ou être modifié suivant l'évolution des paramètres extérieurs de l'application. On ne connaît donc pas aujourd'hui de technique simple et efficace permettant de pallier ces inconvénients, parmi les techniques connues de l'art 25 antérieur. L'invention a notamment pour objectif de pallier ces différents inconvénients de l'art antérieur. Plus précisément, un objectif de l'invention est de fournir une technique d'optimisation des performances d'une application s'exécutant sur un ou plusieurs 30 serveurs, en fonction d'une évolution de la charge de l'application. Un autre objectif de l'invention est de fournir une telle technique, qui permette une optimisation dynamique, en fonctionnement, de l'application. En d'autres termes, l'invention a pour objectif de fournir une telle technique d'optimisation auto-adaptative et pro-active des performances d'une application. Un autre objectif de l'invention est de fournir une technique d'évaluation dynamique de la charge de l'application, au cours de son utilisation. Un objectif supplémentaire de l'invention est de fournir une telle technique qui permette d'assurer la continuité du service rendu par l'application de façon transparente pour les utilisateurs. Un autre objectif de l'invention est de fournir une telle technique qui soit simple à mettre en oeuvre, tout en étant générique pour une utilisation sur n'importe quel type de serveur. Encore un autre objectif de l'invention est de fournir une telle technique qui soit peu coûteuse à mettre en oeuvre. Notamment, l'invention a pour objectif de favoriser la limitation du nombre des équipements, notamment du type serveurs, à mettre en oeuvre sur la plate-forme matérielle et/ou logicielle à déployer, et donc la diminution des coûts de maintenance potentiels à assurer. Un dernier objectif supplémentaire de l'invention consiste mettre en oeuvre 20 une telle technique permettant d'accroître sensiblement de la qualité de service ressentie par les utilisateurs et/ou clients finaux, en particulier du point de vue de l'amélioration des temps de réponse. Ces objectifs, ainsi que d'autres qui apparaîtront par la suite sont atteints à l'aide d'un procédé d'optimisation des performances d'au moins une application 25 mise en oeuvre par au moins un serveur, selon au moins un fichier de configuration. Un tel procédé comprend avantageusement une étape de modification dynamique d'au moins un fichier de configuration, en fonction d'au moins une condition de charge réelle de l'application. D'une façon plus spécifique au domaine des serveurs d'applications, accessibles au travers d'un réseau maillé du type Internet par exemple, les gains recherchés au travers l'optimisation des applications sont de plusieurs ordres: - financier, par la limitation possible du nombre d'équipements, notamment du type serveur, à mettre en oeuvre; - technique, par la simplification possible de la plate-forme matérielle et/ou logicielle à déployer, et de la maintenance à assurer sur cette plate-forme; - relationnel et commercial par un accroissement de la qualité de service 10 ressentie par les utilisateurs et/ou clients finaux, plus précisément grâce à l'amélioration des temps de réponse et/ou à la mise en oeuvre de débits en ligne plus élevés. De façon avantageuse, l'étape de modification dynamique comprend une sousétape de détection automatique d'un changement d'au moins une condition 15 de charge réelle de l'application, et une sous-étape de chargement, sur le ou l'un des serveur(s), d'au moins un nouveau fichier de configuration, en fonction de la ou les nouvelle(s) condition(s) de charge réelle détectée(s). Il est possible d'envisager dans une variante du mode de réalisation décrit, que la sous-étape de détection automatique soit non-intrusive, de façon que les 20 utilisateurs ne perçoivent aucune perturbation dans le fonctionnement de l'application. Préférentiellement, l'application est mise en oeuvre par au moins deux serveurs, l'un au moins des serveurs étant actif et l'un au moins des serveurs étant en attente. De plus, le procédé selon l'invention nécessite la mise en oeuvre de la 25 sous-étape de chargement sur l'un des serveurs en attente et la mise en oeuvre d'une sous-étape d'activation du serveur sur lequel a été chargé le nouveau fichier de configuration. Une telle technique permet de garantir la continuité du service rendu par l'application, même lors de l'exécution des différentes étapes permettant d'aboutir 30 au changement de fichier de configuration de l'application. De façon préférentielle, on envoie au serveur un ordre de prise en compte du nouveau fichier de configuration, préalablement à l'exécution de la sous-étape d'activation. Durant l'étape de modification dynamique du fichier de configuration, on 5 réalise avantageusement, pour chacun des serveurs actifs ne mettant pas en oeuvre le nouveau fichier de configuration, une itération des sous- étapes suivantes - mise en attente du serveur actif; - chargement du nouveau fichier de configuration sur le serveur mis en attente; - réactivation du serveur. De plus, seul un des serveurs est mis en attente à un instant donné, de façon à limiter tout risque d'interruption brutale du service rendu par l'application durant cette étape de modification dynamique du fichier de configuration. De façon préférentielle, le nouveau fichier de configuration appartient à un 15 ensemble préenregistré d'au moins deux fichiers de configuration adaptés chacun à au moins une condition de charge réelle de l'application. Il est bien entendu que cet ensemble préenregistré de fichiers de configuration n'est pas figé dans le temps. Il peut être enrichi, modifié en fonction de l'évolution potentielle de l'utilisation de l'application et du nombre croissant de 20 ses utilisateurs. Avantageusement, au cours de la sous-étape de détection, on mesure en temps réel la charge réelle de l'application, de façon périodique. De façon avantageuse, on compare également la charge réelle mesurée à au moins deux seuils prédéterminés. Cette comparaison a pour objectif essentiel la 25 détermination du profil de charge réelle auquel est soumise l'application. Préférentiellement, la sous-étape de détection ne tient pas compte d'un franchissement de l'un des seuils par la charge réelle mesurée pendant un intervalle de temps inférieur à une durée minimalet prédéterminée. Une telle précaution permet en effet d'éviter tout remplacement du fichier de configuration 30 lors de la détection d'un pic ou d'une baisse de charge de très courte durée, qui aurait alors pour conséquence l'affectation d'un fichier de configuration non optimal, la charge ayant retrouvé son profil initial avant la fin du processus de remplacement de ce fichier de configuration. Avantageusement, la comparaison n'est mise en oeuvre que pour le ou les serveur(s) actif(s), car ils sont seuls à recevoir les requêtes des utilisateurs finaux Le procédé selon l'invention met en oeuvre, de façon avantageuse, une étape préliminaire de création d'un ensemble préenregistré de fichiers de configuration comprenant, pour chacun des fichiers, une recherche d'au moins un paramètre de configuration de l'application optimisant, pour un profil de charge 10 donné, des performances de l'application. De façon préférentielle, le procédé selon l'invention comprend en outre une étape d'actualisation de l'ensemble préenregistré des fichiers de configuration, permettant l'ajout et/ou la suppression d'au moins un fichier de configuration. En effet, la supervision régulière du comportement de l'application 15 en situation réelle d'utilisation peut avoir pour conséquence la création de nouveaux fichiers de configuration répondant à de nouveaux profils de charge, ou bien l'affinage des paramètres d'un ou plusieurs fichiers de configuration pour les rendre plus optimaux, ou bien encore la suppression d'un ou plusieurs fichiers de configuration devenus inadaptés aux charges subies par l'application. Avantageusement, le procédé selon l'invention comprend également une étape d'aiguillage d'au moins une requête émise par un utilisateur vers le ou les serveur(s) actif(s). L'invention concerne également un dispositif d'optimisation des performances d'au moins une application mise en oeuvre par au moins un serveur, 25 selon au moins un fichier de configuration. Un tel dispositif comprend avantageusement des moyens de modification dynamique d'au moins un fichier de configuration, en fonction d'au moins une condition de charge réelle de l'application. De façon également avantageuse, le dispositif d'optimisation selon 30 l'invention est mis en oeuvre par au moins un serveur, selon au moins un fichier de configuration. Un tel dispositif met en oeuvre, de façon préférentielle, le procédé d'optimisation des performances d'au moins une application mise en oeuvre par au moins un serveur, selon au moins un fichier de configuration et comprenant une étape de modification dynamique d'au moins un fichier de configuration, en 5. fonction d'au moins une condition de charge réelle de l'application. Le dispositif selon l'invention comprend en outre de façon avantageuse: pour chacun des serveurs, une sonde de mesure de la charge réelle de l'application; - un module de calcul du profil de la charge réelle déterminant, à partir de la 10 charge mesurée, un profil de charge de l'application; - un module de chargement de fichier de configuration mettant en oeuvre, si nécessaire en fonction du profil de charge, un chargement d'un nouveau fichier de configuration sur le ou l'un des serveur(s), et délivrant un ordre de prise en compte du nouveau fichier de configuration et une commande 15 d'activation du serveur sur lequel le nouveau fichier de configuration a été chargé; - un module d'aiguillage mettant en oeuvre, en fonction de la commande d'activation, le passage de chacun des serveurs dans un état actif ou en attente, et dirigeant une requête émise par un utilisateur vers le ou les 20 serveur(s) actif(s). Dans une variante du mode de réalisation précité de l'invention, la sonde de mesure de la charge réelle de l'application sera de préférence non intrusive, de façon à ne pas altérer le fonctionnement global de l'application et ne pas diminuer ses performances. L'invention concerne également un produit programme d'ordinateur comprenant des instructions de code de programme enregistré sur un support utilisable dans un ordinateur, comprenant des moyens de programmation lisibles par ordinateur pour effectuer les étapes du procédé d'optimisation des performances d'au moins une application mise en oeuvre par au moins un serveur, 30 selon au moins un fichier de configuration et comprenant une étape de modification dynamique d'au moins un fichier de configuration, en fonction d'au moins une condition de charge réelle de l'application. D'autres caractéristiques et avantages de l'invention apparaîtront plus clairement à la lecture de la description suivante d'un mode de réalisation 5 préférentiel, donné à titre de simple exemple illustratif et non limitatif, et des dessins annexés, parmi lesquels: - la figure 1 est un organigramme illustrant les éléments techniques constituant le dispositif selon un mode de réalisation particulier de l'invention; - la figure 2 est un organigramme de description d'un mode opératoire de création de l'ensemble des fichiers de configuration utilisables par une ou plusieurs applications d'un serveur du dispositif décrit par la figure 1; - la figure 3 est un organigramme de description d'un mode de 15 réalisation préférentiel du dispositif selon l'invention et une généralisation du mode de réalisation décrit par la figure 1; - la figure 4 est un chronogramme des ordres émis par le module de dépôt des fichiers de configuration depuis la détection du changement de charge subie par l'application, jusqu'au changement 20 de fichier de configuration pour l'application; - les figures 5.a, 5.b et 5.c décrivent trois exemples du principe d'évaluation de la charge subie par l'application à un instant donné relativement à des seuils prédéterminés et paramétrables, puis de mise en correspondance de la charge évaluée avec un profil de 25 charge possible et prédéterminé de l'application; - la figure 6 est un organigramme décrivant les étapes de détermination du profil de charge de l'application à un instant donné, et de choix du fichier de configuration optimal correspondant; - la figure 7 est un organigramme décrivant les différentes étapes de 30 l'algorithme d'optimisation auto-adaptative utilisé par le module de calcul de charge du dispositif de la figure 3. Le principe général de l'invention consiste à remplacer, de façon dynamique, le fichier de configuration d'une application, exécutée sur un ou plusieurs serveurs et mise à la disposition d'un nombre indéterminé d'utilisateurs, simultanément, au travers d'un réseau, du type Internet par exemple, lorsqu'on détecte une évolution de la charge réelle de l'application. On peut noter à ce stade de la description que le principe général du dispositif selon l'invention permet de répondre à tous les cas de figure, dont certains cas particuliers comme par exemple, la configuration d'une application reposant sur un seul serveur et pour laquelle il est possible d'effectuer une 10 optimisation en cours d'utilisation réelle, tout en garantissant la continuité du service. C'est typiquement le cas de certains progiciels, tel le serveur Web Apache (marque déposée) qui autorise certains types d'optimisation, sans altérer la continuité du service, via l'utilisation de commandes spécifiques (commande " restart " pour Apache, par exemple). La figure 1 décrit l'ensemble des éléments techniques constitutifs du dispositif auto-adaptatif et proactif de l'invention, selon un mode de réalisation particulier mettant en oeuvre un seul serveur 10, support de l'application 11 à optimiser. L'application Il à optimiser reçoit en entrée les requêtes 12 issues des 20 utilisateurs finaux destinées à l'application 11. L'application repose sur un code logiciel exécutable qui lui est spécifique, et utilise à un instant donné un ou plusieurs fichiers de configuration contenu dans l'ensemble 13. Comme mentionné précédemment, l'optimisation s'effectue en arrièreplan et de façon transparente pour les utilisateurs pour lesquels la continuité du 25 service rendu par l'application est désormais garantie (maintien des sessions en cours avec les utilisateurs). Cette application est déployée sur un serveur - ou plus généralement - peut être déployée sur un ensemble de serveurs, comme illustré sur la figure 3. Un ensemble 13 de fichiers de configuration est nécessaire pour répondre à 30 différents profils de charge, préalablement définis et créés par l'administrateur de l'application 11. La mise en correspondance par téléchargement 14 (ou dépôt) de ces fichiers de configuration 13 avec le profil de la charge identifié permet d'assurer l'optimisation des performances de l'application 11. A titre d'exemple illustratif et non limitatif, on peut imaginer un ensemble 5 de trois fichiers de configuration répondant aux trois profils suivants: " faible charge ", " charge moyenne ", et " forte charge ". On peut également prendre en compte les spécificités d'une application Internet particulière, comme la gestion de pages statiques en provenance d'un disque informatique ou d'une base de données, ou encore, la gestion de pages dynamiques créées à la volée. Toute combinatoire 10 entre ces différents exemples est également possible. La granularité d'optimisation est donc directement liée à l'ensemble des fichiers de configuration. Toujours à titre d'exemple illustratif, les trois profils de charge mentionnés ci-dessus peuvent être définis selon le critère technique du nombre de sollicitations de l'application par seconde (" hits/seconde "). La position du 15 nombre de hits/seconde dans une échelle à trois seuils permet alors de déterminer le profil de la charge selon les règles particulières suivantes - si hits/secondes Dans le cas général, le fichier de configuration est un fichier texte au format ASCII non propriétaire, dans lequel les paramètres de configuration respectent une certaine syntaxe, dont un exemple est donné dans la suite de la description. Dans le cas particulier d'une optimisation du serveur Web Apache (marque 25 déposée), le contenu du fichier de configuration " HTTPD.conf " sera par exemple le suivant en fonction de la charge: - valeur des paramètres Apache pour une faible charge de l'application: a MinSpareServers 5; * MaxSpareServers 10; 2854260 12 * StartServers 11; * MaxClients 50; * KeepAlive off; - valeurs des paramètres Apache pour une charge moyenne de 1' application: * MinSpareServers 18 * MaxSpareServers 25; * StartServers 28; * MaxClients 100; * KeepAlive off; - valeurs des paramètres Apache pour une forte charge de l'application: * MinSpareServers 20; * MaxSpareServers 29; 15 * StartServers 32; * MaxClients 150; ò KeepAlive off; Dans le cadre de l'optimisation d'une application exécutée sur un serveur Solaris (marque déposée), les paramètres à modifier en priorité peuvent concerner 20 par exemple les variables " maxusers ", " maxphys ", " bufhwm ", " maxpgio ". Cette liste n'est pas limitative du fait du nombre très important de paramètres potentiellement configurables dans un serveur Solaris. La sonde 15 illustrée sur la figure 1 permet de mesurer en temps réel la charge de l'application. Cette sonde 15 est de préférence peu ou nonintrusive car 25 elle ne doit pas altérer les performances de l'application. A titre d'exemple, elle peut remonter des paramètres 16 relatifs au débit en ligne, au nombre de requêtes ou au nombre de transactions par unité de temps; il peut également s'agir de paramètres relatifs à la charge du système d'exploitation (charge de l'unité centrale, taux d'échange de données, nombre de requêtes dans 30 la base de données, etc.). Les informations 17 délivrées par la sonde sont ensuite exploitées par le module 18 de calcul du profil de charge, pour lequel elles ont été préalablement mises en forme suivant la syntaxe suivante: . .. . Ce module 18 de calcul de charge reçoit en entrée les informations brutes 16 issues de la sonde 15 de mesure. Le principe de fonctionnement de ce module consiste à comparer la valeur instantanée de mesure de la charge avec un ensemble de seuils prédéfinis par l'opérateur et - si nécessaire de filtrer toute variation fugitive de la mesure (pour éviter les dépôts multiples et intempestifs des 10 fichiers de configuration). Une indication relative au profil de la charge est disponible en sortie de ce module. Le principe de fonctionnement de ce module est décrit plus en détail par la suite, en relation avec l'organigramme de la figure 5. Le module de dépôt de fichier de configuration 19 reçoit d'une part la 15 mesure 17 délivrée par le module de calcul du profil de la charge et d'autre part, les différents fichiers de configuration 13 de l'application exécutée sur le ou les serveurs. Les principales fonctionnalités de ce module consistent donc à: - lire le " profil de la charge "; - effectuer, le cas échéant, le dépôt du fichier de configuration 20 approprié au type de charge dans le serveur; - transmettre un ordre 111 de prise en compte du nouveau fichier de configuration au(x) serveur(s), mais uniquement si le dépôt d'un nouveau fichier de configuration est nécessaire, en raison d'une modification du profil de charge. De façon plus précise, la figure 2 détaille le mode opératoire permettant de créer un ensemble de fichiers de configuration optimaux pour un profil de charge donné de l'application à optimiser. Selon ce mode opératoire, un outil 20 de test en charge est utilisé. Il permet de simuler une charge fictive induite par des utilisateurs virtuels au travers l'envoi de requêtes 21 représentatives d'un profil de 30 charge donné et servant de données d'entrée à l'application 22 à optimiser. Cette phase d'optimisation au niveau de l'application 22 est soit manuelle, soit automatique à l'aide d'une recherche du maximum de performances nécessitant une intervention 23 sur l'application. Tant que le maximum de performance n'est pas obtenu, l'application retourne une réponse 24 aux requêtes 21, de façon 5 itérative, jusqu'à l'obtention d'un résultat 25 optimal, aboutissant à la création d'un fichier de configuration optimisé 26 pour le profil de charge considéré. Dans une variante du mode opératoire précité, dédié à la création des fichiers de configuration, il est possible d'envisager l'utilisation, par l'outil de simulation et de test en charge, de moyens complémentaires d'apprentissage du 10 comportement des utilisateurs virtuels, de façon à pouvoir considérer d'autres situations, non scénarisées initialement. Il devient alors possible de créer un plus grand nombre de fichiers de configuration et de permettre ainsi l'optimisation de l'application en réponse à un plus grand nombre de situations. Le mode de réalisation préférentiel de l'invention est décrit sur la figure 3 15 qui présente une généralisation à (n > 1) serveurs 30 exécutant en parallèle la même application 31, du mode de réalisation particulier de la figure 1, dans lequel l'application est exécutée sur un serveur unique. L'avantage essentiel de cette généralisation concerne la possibilité de pouvoir prendre en compte un ensemble de critères opérationnels tels que: - la scalabilité, qui permet de mieux répondre à la montée en charge de l'application et donc d'améliorer ses critères de performances; - la redondance, qui permet de garantir la continuité du service rendu par l'application, même en cas de défaillance brutale et intempestive d'un serveur exécutant l'application; 25 - la répartition de la charge entre les différents serveurs; - la continuité du service durant la phase d'optimisation. Dans un tel mode de réalisation, le dispositif selon l'invention comprend plusieurs serveurs 30 (1 à n, n > 1) exécutant l'application 31 et chaque serveur comprend une sonde 32 délivrant des informations sur la charge de l'application 30 exécutée par le serveur 30 qui l'héberge. Chaque serveur 30 peut être dans l'un des deux états suivants - " en service ": le serveur est actif et traite les requêtes 33 des utilisateurs finaux, la configuration de ce serveur doit donc être optimale, de façon à garantir aux utilisateurs un maximum de qualité de service; - " en attente ": le serveur ne traite pas les requêtes des utilisateurs finaux. Il est prêt à prendre le relais du serveur actif si nécessaire. L'état " en attente " est mis à profit dans le dispositif de l'invention pour permettre le dépôt du fichier de configuration 34 qui correspond au mieux à la 10 charge de l'application. En effet, la prise en compte d'un nouveau fichier de configuration 34 pourrait, comme dans le cas du mode de réalisation de la figure 1, provoquer une interruption du service pendant une courte durée. Pour éviter ce type d'interruption incompatible avec la qualité de service à offrir aux utilisateurs, le mode de réalisation préféré utilise la redondance et la mise " en attente " 15 volontaire d'au moins un des N serveurs utilisés. Le nouveau fichier de configuration 34 est déposé sur ce nouveau serveur, lequel est ensuite rendu actif (état " en service ") avec une configuration optimisée pour le nouveau profil de charge. Ce dépôt est effectué à l'aide du module 35 de dépôt de fichier de configuration. Pour résumer, lorsque l'application est déployée sur un ensemble de 20 N serveurs, un serveur parmi les N autres est toujours maintenu dans un état d'attente, de façon à pouvoir servir de relais pour l'application exécutée entre une première configuration devenue non optimale et une nouvelle configuration optimisée pour le nouveau profil de charge détecté. Une telle architecture nécessite la mise en oeuvre d'un module 36 25 d'aiguillage placé en amont des serveurs 30. Ce module réalise le changement d'état " en service " vers un état " en attente " pour tous les serveurs 30 et aiguille les requêtes 33 des utilisateurs uniquement vers les serveurs dans l'état " en service " (ou " actif "). En outre, l'utilisation de plusieurs serveurs permet de garantir la continuité du service durant les phases de changement d'état (maintien 30 de la persistance des sessions). Le module d'aiguillage reçoit en entrée l'ensemble des requêtes 33 des utilisateurs finaux et un ordre de commande 37 issu du module de dépôt du fichier de configuration 35. Par ailleurs, dans ce mode de réalisation préféré du dispositif de l'invention, le module 38 de calcul du profil de la charge comprend un nombre 5 d'entrées 39 au moins égal au nombre de serveurs déployés (nombre total des serveurs dans l'état " en service " et dans l'état " en attente "). Enfin, le calcul du profil de la charge ne prend en compte que les données issues des serveurs " en service ". Dans le cas contraire (état " en attente "), la mesure 39 issue de la sonde n'est pas représentative; cette mesure ne sera donc 10 pas prise en compte par le module 38 de calcul du profil de charge. Toujours dans le mode de réalisation préféré du dispositif de l'invention, le module de dépôt de fichier de configuration 35 est équipé d'un nombre de sorties dédiées aux ordres 310 de téléchargement du fichier de configuration et aux ordres 311 de prise en compte du fichier de configuration 34 au moins égal au 15 nombre de serveurs 30 déployés. Ce module a pour fonction d'orchestrer le changement d'état de tous les serveurs (" en service " vers " en attente ", " en attente " vers " en service ") et/ou ordonne l'aiguillage des requêtes vers les serveurs " en service ". La figure 4 décrit la chronologie des événements et actions s'exécutant à 20 l'intérieur, ou entre les différents composants matériels et/ou logiciels du dispositif selon l'invention lors d'un changement de profil de charge de l'application. Ainsi, dans le tableau de la figure 4, les différentes colonnes représentent la chronologie des événements, les lignes correspondant respectivement à: 25 - un changement d'état de la charge; - une succession d'ordres émis par le module de dépôt de fichier de configuration lors du changement d'état; - l'état des serveurs (" en service " ou " en attente "), ainsi que le contenu du fichier de configuration. Il est important de préciser ici que dans un soucis de simplification, les différentes étapes du changement de profil de la charge sont données ci-dessous pour seulement trois serveurs numérotés 1, i et j. Cela peut bien sûr être étendu à N serveurs (N > 3). Les actions inhérentes à un changement du profil de la charge sont rappelées au travers de la chronologie suivante: - étape 1: la configuration globale de l'application est dans un état stable. Les serveurs " 1 " et " i " sont en service et mettent en oeuvre le fichier de configuration correspondant au profil de la 10 charge délivré par le module de calcul du profil de la charge (profil " i "). Le serveur " j " est dans l'état " en attente " et prêt, également, à remplacer un serveur défaillant le cas échéant, ou à prendre en compte un nouveau fichier de configuration de l'application; - étape 2: le module de calcul du profil de charge vient de détecter un changement du profil de la charge (cas d'une transition nécessaire d'une charge de profil " i " vers une charge de profil " z "). Le module de dépôt de fichier de configuration envoie alors un ordre de téléchargement du fichier de configuration 20 correspondant au profil de la nouvelle charge (profil " z ") dans le serveur " j ", alors placé dans l'état " en attente " dans l'exemple courant; - étape 3: l'ordre de prise en compte du nouveau fichier de configuration complète l'étape précédente. Un temps court de 25 chargement du nouveau fichier de configuration par le serveur " j " est nécessaire, durant lequel les deux autres serveurs " 1 " et " i " contiennent le fichier de configuration qui correspond à la charge précédente (profil " i "); - étape 4: le serveur " j " peut être mis en service. A cet instant, c'est 30 le seul serveur " en service " qui possède le fichier de configuration optimal pour les performances de l'application. Le serveur " 1 " est ensuite placé dans l'état " en attente " (ce choix peut être séquentiel ou aléatoire); - étape 5: le module de dépôt de fichier de configuration envoie un 5 ordre de téléchargement du fichier de configuration correspondant au nouveau profil de charge (profil " z ") dans le serveur " 1 " nouvellement placé dans l'état " en attente "; étape 6: l'ordre de prise en compte du nouveau fichier de configuration complète l'étape précédente. Tout comme à l'étape 3, 10 un temps court de chargement du nouveau fichier de configuration par le serveur " 1 " est nécessaire; - étape 7: le serveur " 1 " est ensuite remis en service. A cet instant, deux serveurs (" 1 " et " j ") sont dans l'état " en service " et optimisés pour le nouveau profil de charge de l'application. A 15 l'issue de cette étape, seul le serveur " i " (placé dans l'état " en attente ") ne possède pas encore le fichier de configuration correspondant au nouveau profil de charge; - étape 8: le module de dépôt de fichier de configuration envoie un ordre de téléchargement du nouveau fichier de configuration 20 correspondant au profil de la nouvelle charge (profil " z ") au serveur " i "; - étape 9: l'ordre de prise en compte du nouveau fichier de configuration complète à nouveau l'étape précédente et tout comme dans les étapes 3 et 6, un temps court de chargement du nouveau 25 fichier de configuration par le serveur " i " est de nouveau nécessaire. Cependant, ce serveur étant le dernier à subir le chargement du nouveau fichier de configuration, il est alors volontairement laissé dans l'état " en attente " pour réaliser la redondance des serveurs et/ou pour servir de premier serveur relais 30 à pouvoir recevoir un nouveau fichier de configuration et à être le premier nouvellement activé, suite à la détection d'un nouveau profil de charge de l'application par le module de calcul du profil de charge. On peut noter que la succession des étapes ci-dessus est totalement 5 transparente et sans aucune conséquence sur la qualité de service rendue aux utilisateurs. En effet, à un instant donné, au moins un serveur est toujours en service. Le chargement d'un nouveau fichier de configuration est effectué sur un serveur " en attente ", ce dernier n'étant activé qu'après avoir reçu l'ordre de prendre en 10 compte le nouveau fichier. La généralisation de l'exemple précité est donnée au travers de l'organigramme de la figure 7 qui décrit l'algorithme du produit programme d'ordinateur mettant en oeuvre le procédé d'optimisation selon l'invention, depuis la détection d'une nouvelle valeur de profil de charge et jusqu'à la mise à jour du 15 fichier de configuration de tous les serveurs initiée par le module de dépôt de fichier de configuration. Les figures 5.a, 5.b et 5.c décrivent le principe du calcul du profil de charge par le module de calcul de charge 38, pour comparativement à trois profils de charge donnés, respectivement. Le module de calcul de charge 38 reçoit 20 périodiquement une mesure brute nommée " valeur ", représentée dans le temps par les courbes 51 d'évolution de cette valeur. Ce module 38 est également composé d'un ensemble de seuils paramétrables (52, 53, 54, 55, 56, 57). Pour chaque serveur 30 en service, le principe retenu consiste à: - comparer la variable " valeur" avec deux seuils (minimum, 25 maximum), (52, 53), (54, 55) ou (56, 57) respectivement; - filtrer les éventuels dépassements fugitifs 201 ou 502 de ces seuils, afin d'éliminer toute variation intempestive (et non représentative) de la charge de l'application à optimiser. Le filtrage des dépassements fugitifs des seuils supérieurs 501 et inférieurs 30 502 utilise la variable T. De plus, il est possible de prévoir un recouvrement entre les zones situées autour des seuils (52, 53), (54, 55) ou (56, 57) en introduisant une marge paramétrable E. Cette marge présente l'avantage de réduire tout changement intempestif lorsque la valeur restituée par la sonde 32 se trouve dans une zone située à proximité des seuils. La figure 6 est un organigramme détaillant l'algorithme du principe retenu au niveau du module 38 de calcul de profil de la charge, tel qu'illustré au travers l'exemple des figures 5.a, 5.b et 5.c. Le principe général de l'invention repose donc sur une approche nouvelle 10 et inventive consistant à proposer un dispositif d'optimisation autoadaptative basé sur - la mesure périodique et automatique de l'activité de l'application; - la mise en oeuvre d'une optimisation continuellement adaptée au profil de charge des utilisateurs finaux de l'application; 15 la garantie d'une continuité du service, y compris lorsqu'une optimisation de performances s'avère nécessaire (cas d'une inadéquation de l'optimisation avec le profil de la charge). On note que le procédé mis en oeuvre est totalement automatique (optimisation auto-adaptative et proactive). D'une façon générale, les moyens mis 20 en oeuvre dans l'invention consistent à: - mesurer la charge de l'application; appliquer un fichier de configuration adapté à la charge; - utiliser un serveur " en attente " pour mettre à jour la nouvelle configuration et basculer cette dernière vers les autres serveurs 25 pour les mettre à jour, dans l'objectif de garantir la continuité du service rendu pendant toute la phase de mise à jour. Selon un mode de réalisation préférentiel de l'invention, le dispositif selon l'invention utilise un ensemble (" pool ", en anglais) de fichiers de configuration préalablement créés par un administrateur ou opérateur de l'application. On peut 30 noter à titre informatif que cette opération préalable est réalisée à l'aide d'un environnement permettant de simuler les évolutions possibles de la charge que pourrait subir l'application considérée, à l'aide d'utilisateurs virtuels paramétrables. Il est important de préciser que cette étape peut être préliminaire à la mise en service de l'application considérée sur un ou plusieurs serveurs, et donc 5 à l'utilisation du dispositif selon l'invention pilotant l'optimisation de l'application. Dans cette phase préliminaire, les paramètres de configuration de l'application sont dynamiquement modifiés, l'objectif recherché étant la détermination d'un maximum en termes de performances de l'application pour un profil de charge donné. Ce profil de charge est par exemple déterminé 10 relativement au nombre d'utilisateurs utilisant simultanément le(s) service(s) offert(s) par l'application, au nombre de requêtes des utilisateurs sollicitant une base de données, à la sollicitation des composants et/ou moteurs logiciels, et/ou autres composants matériels. C'est uniquement une fois le maximum de performance déterminé pour un 15 profil de charge donné que le contenu des paramètres est ensuite consigné dans un fichier de configuration correspondant à ce profil de charge. Il y a donc un fichier de configuration par profil de charge donnée. Cette étape préliminaire est réalisée indifféremment, soit dans un mode manuel, soit dans un mode automatique, selon la solution proposée dans la demande de brevet français précédemment citée 20 FR'275. Cette opération est donc répétée autant de fois qu'il y aura de fichiers de configuration à créer. REVENDICATIONS 1. Procédé d'optimisation des performances d'au moins une application mise en oeuvre par au moins un serveur, selon au moins un fichier de configuration, caractérisé en ce qu'il comprend une étape de modification dynamique dudit au moins un fichier de configuration, en fonction d'au moins une condition de charge réelle de ladite application. 2. Procédé d'optimisation selon la revendication 1, caractérisé en ce que ladite étape de modification dynamique comprend une sous-étape de détection 10 automatique d'un changement d'au moins une condition de charge réelle de ladite application, et une sous-étape de chargement, sur ledit ou l'un desdits serveur(s), d'au moins un nouveau fichier de configuration, en fonction de la ou les nouvelle(s) condition(s) de charge réelle détectée(s). 3. Procédé d'optimisation selon l'une quelconque des revendications 1 et 2, caractérisé en ce que ladite application est mise en oeuvre par au moins deux serveurs, l'un au moins desdits serveurs étant actif et l'un au moins desdits serveurs étant en attente, en ce que ladite sous-étape de chargement est mise en oeuvre sur l'un desdits 20 serveurs en attente, et en ce que ledit procédé comprend également une sous-étape d'activation dudit serveur sur lequel a été chargé ledit nouveau fichier de configuration. 4. Procédé d'optimisation selon la revendication 3, caractérisé en ce que, préalablement à ladite sous-étape d'activation, on envoie audit serveur un ordre 25 de prise en compte dudit nouveau fichier de configuration. 5. Procédé d'optimisation selon l'une quelconque des revendications 3 et 4, caractérisé en ce que lors de ladite étape de modification dynamique du fichier de configuration, on réalise, pour chacun desdits serveurs actifs ne mettant pas en oeuvre ledit nouveau fichier de configuration, une itération des 30 sous-étapes suivantes: - mise en attente dudit serveur actif; - chargement dudit nouveau fichier de configuration sur ledit serveur mis en attente; - réactivation dudit serveur; seul un desdits serveurs étant en attente à un instant donné. 6. Procédé d'optimisation selon l'une quelconque des revendications 1 à 5, caractérisé en ce que ledit nouveau fichier de configuration appartient à un ensemble préenregistré d'au moins deux fichiers de configuration adaptés chacun à au moins une condition de charge réelle de ladite application. 7. Procédé d'optimisation selon l'une quelconque des revendications 1 à 6, caractérisé en ce qu'au cours de ladite sous-étape de détection automatique, on mesure en temps réel la charge réelle de ladite application, de façon périodique. 8. Procédé d'optimisation selon la revendication 7, caractérisé en ce qu'on compare également ladite charge réelle mesurée à au moins deux seuils prédéterminés, de façon à déterminer un profil de charge de ladite application. 9. Procédé d'optimisation selon la revendication 8, caractérisé en ce que ladite sous-étape de détection ne tient pas compte d'un franchissement de l'un desdits seuils par ladite charge réelle mesurée pendant un intervalle de temps 20 inférieur à une durée minimale t prédéterminée. 10. Procédé d'optimisation selon l'une quelconque des revendications 8 et 9, caractérisé en ce que ladite comparaison n'est mise en oeuvre que pour ledit ou lesdits serveur(s) actif(s). 11. Procédé d'optimisation selon l'une quelconque des revendications 6 à 25 10, caractérisé en ce qu'il met en oeuvre une étape préliminaire de création dudit ensemble préenregistré de fichiers de configuration comprenant, pour chacun desdits fichiers, une recherche d'au moins un paramètre de configuration de ladite application optimisant, pour un profil de charge donné, des performances de ladite application. 12. Procédé d'optimisation selon l'une quelconque des revendications 6 à 11, caractérisé en ce qu'il comprend une étape d'actualisation dudit ensemble préenregistré permettant l'ajout et/ou la suppression d'au moins un fichier de configuration. 13. Procédé d'optimisation selon l'une quelconque des revendications 3 à 12, caractérisé en ce qu'il comprend également une étape d'aiguillage d'au moins une requête émise par un utilisateur vers ledit ou lesdits serveur(s) actif(s). 14. Dispositif d'optimisation des performances d'au moins une 10 application mise en oeuvre par au moins un serveur, selon au moins un fichier de configuration, caractérisé en ce qu'il comprend des moyens de modification dynamique dudit au moins un fichier de configuration, en fonction d'au moins une condition de charge réelle de ladite application. 15. Dispositif d'optimisation des performances d'au moins une application mise en oeuvre par au moins un serveur, selon au moins un fichier de configuration, mettant en oeuvre le procédé d'optimisation de l'une quelconque des revendications 1 à 13. 16. Dispositif d'optimisation selon la revendication 15, caractérisé en ce 20 qu'il comprend: - pour chacun desdits serveurs, une sonde de mesure de la charge réelle de ladite application; - un module de calcul du profil de la charge réelle déterminant, à partir de ladite charge mesurée, un profil de charge de ladite application; - un module de chargement de fichier de configuration mettant en oeuvre, si nécessaire en fonction dudit profil de charge, un chargement d'un nouveau fichier de configuration sur ledit ou l'un desdits serveur(s), et délivrant un ordre de prise en compte dudit nouveau fichier de configuration et une commande d'activation dudit serveur sur lequel ledit nouveau fichier de 30 configuration a été chargé; - un module d'aiguillage mettant en oeuvre, en fonction de ladite commande d'activation, le passage de chacun desdits serveurs dans un état actif ou en attente, et dirigeant une requête émise par un utilisateur vers le ou lesdits serveur(s) actif(s). 17. Produit programme d'ordinateur comprenant des instructions de code de programme enregistré sur un support utilisable dans un ordinateur, comprenant des moyens de programmation lisibles par ordinateur pour effectuer les étapes du procédé d'optimisation selon l'une quelconque des revendications 1 à 13.