Brevet FR3037417A1 — publié le 20161216

Arrière-plan de l'invention L'invention se rapporte au domaine général des applications logicielles. Elle concerne plus particulièrement le dimensionnement des ressources permettant l'exécution de telles applications. L'invention s'applique ainsi de façon privilégiée mais non limitative lorsque des applications logicielles sont déployées dans un système informatique en nuage aussi plus communément appelé « cloud » en anglais. La gestion de l'élasticité des applications logicielles déployées en cloud est une problématique importante, notamment dans les systèmes de type « PaaS » (« Platform as a Service » en anglais ou Plateforme en tant que service). Ces systèmes, principalement destinés aux entreprises, visent à proposer des services techniques qui facilitent la construction, la mise en oeuvre et l'administration des applications logicielles afin de recentrer l'attention des utilisateurs sur leurs applications. La finalité d'un système PaaS est de masquer la complexité liée à l'instanciation et à l'exploitation des applications. Pour cela, le système PaaS propose des briques techniques, accessibles au travers d'interfaces de haut niveau via un réseau de télécommunications, permettant de prendre en charge un panel important des services liés à l'administration des applications, notamment l'adaptation dynamique aux variations de charge, la sûreté de fonctionnement et la sécurité. Le périmètre fonctionnel de ces briques correspond généralement à celui rempli par un intergiciel (e.g. serveur HTTP, serveur d'application, base de données, interpréteurs de script, canevas logiciels divers...), à savoir des opérations qui peuvent être mutualisées entre plusieurs applications. Dans ce contexte, la gestion de l'élasticité des applications logicielles déployées en cloud a pour but de fournir et d'ajuster (i.e. adapter) les ressources nécessaires au bon fonctionnement de ces applications logicielles, en termes notamment de volumétrie, de disponibilité, de temps de réponse et de fiabilité, tout en satisfaisant les contraintes spécifiques à ces applications logicielles (ex. coût, placement des machines virtuelles, droit d'utilisation, etc.). En vue d'optimiser un rapport qualité/coût, la gestion de l'élasticité doit ainsi : permettre de déterminer (i.e. dimensionner) les ressources nécessaires au déploiement d'une application logicielle ainsi que la configuration optimale de ces ressources, en fonction notamment d'exigences contractualisées (par exemple sous la forme d'accord de niveau de service ou encore SLA pour « Service Level Agreement » en anglais) et des ressources engagées pour d'autres applications logicielles en cours d'exécution ; et être capable d'ajouter ou de supprimer dynamiquement des ressources durant l'exécution de l'application logicielle, afin notamment d'absorber des « rafales » ponctuelles (instantanées) de requêtes dues à des pics d'utilisation de l'application logicielle ou au partage de l'environnement d'exécution avec d'autres applications logicielles, et de respecter ainsi les exigences contractualisées dans les SLA (ex. en termes de temps de réponse de l'application 3037417 2 logicielle). Pour ce faire, la gestion de l'élasticité doit être en mesure de déterminer rapidement la nouvelle configuration de ressources et préciser quand doit intervenir l'opération de reconfiguration. Les techniques de dimensionnement des ressources sont donc au coeur de la gestion 5 de l'élasticité. Elles nécessitent généralement une bonne connaissance de l'application logicielle, notamment en termes de consommation de ressources par les instances de déploiement de l'application (ex. serveurs), mais également de profils de requêtes utilisateurs (ex. répartition par service, débits des requêtes, temps d'inter-arrivées entre les requêtes, etc.). Dans l'état actuel de la technique, il n'existe pas de procédé structuré connu 10 permettant de déterminer facilement les ressources nécessaires (ainsi que la configuration de ces ressources) pour le déploiement ou l'exécution d'une application logicielle. En effet, aujourd'hui, on dimensionne et on ajuste uniquement de façon expérimentale avec des outils de tests et/ou de supervision les ressources nécessaires à l'exécution d'une application logicielle à partir d'une étude de pré-métrologie. Cette façon de procéder implique un investissement très important en termes 15 de coût et de temps : de nombreuses configurations doivent être testées avant de trouver une configuration optimale, nécessitant la mise en place d'équipements physiques et de logiciels, l'exécution de nombreux tests, etc. Une telle approche n'est donc pas toujours envisageable en pratique du fait de contraintes de temps imposées au déploiement de l'application logicielle par exemple ou de contraintes imposées en termes de retour sur investissement. 20 Objet et résumé de l'invention L'invention permet de remédier notamment à cet inconvénient en proposant un procédé de détermination d'une configuration de serveurs dite cible pour un déploiement d'une application logicielle apte à offrir au moins un service, ce procédé comprenant : 25 une étape d'obtention, pour au moins un service offert par l'application logicielle, au moyen d'au moins un test unitaire réalisé sur une configuration de serveurs dite de référence apte à exécuter l'application logicielle, d'un temps d'exécution moyen d'une requête invoquant ce service pour chaque serveur de la configuration de référence ; une étape de sélection d'une configuration de serveurs dite initiale pour le déploiement de 30 l'application logicielle apte à supporter une charge cible déterminée pour l'application logicielle, cette étape de sélection tenant compte des temps d'exécution moyens obtenus lors dudit au moins un test unitaire, de la charge cible et d'une charge admissible déterminée pour la configuration de référence, et utilisant un modèle numérique reflétant au moins une contrainte de déploiement de l'application logicielle imposée à la configuration de serveurs initiale ; et 35 une étape de détermination, à partir de la configuration initiale, d'une configuration de serveurs cible destinée à être utilisée pour le déploiement de l'application logicielle, ladite étape de détermination comprenant la réalisation d'une pluralité de tests de tenue en charge 3037417 3 parannétrés en fonction d'une charge maximale théorique estimée pour la configuration initiale et de la charge cible, et utilisant au moins un profil de requêtes invoquant ledit au moins un service offert par l'application logicielle, ce profil étant représentatif d'une utilisation de l'application logicielle lors de son déploiement, ladite étape de détermination comprenant en 5 outre, en fonction du résultat de chaque test de tenue en charge, un ajustement d'au moins une ressource de la configuration initiale de sorte que la configuration cible obtenue à l'issue de ladite pluralité de tests de tenue en charge soit apte à vérifier un temps de réponse maximal fixé pour l'application logicielle et à supporter ladite charge cible. Corrélativement, l'invention vise aussi un système de détermination d'une 10 configuration cible pour un déploiement d'une application logicielle, le système comprenant : un premier outil de test permettant l'exécution d'au moins un test unitaire sur l'application logicielle lorsque celle-ci est exécutée sur une configuration de serveurs dite de référence ; - un module d'obtention, configuré pour commander l'exécution d'au moins un test unitaire par le premier outil de test sur ladite configuration de référence et pour obtenir, pour au moins un 15 service offert par l'application logicielle, un temps d'exécution moyen d'une requête invoquant ce service pour chaque serveur de la configuration de référence ; - un module de sélection, configuré pour sélectionner une configuration de serveurs initiale pour le déploiement de l'application logicielle apte à supporter une charge cible déterminée pour l'application logicielle, ledit module de sélection étant configuré pour tenir compte des temps 20 d'exécution moyens obtenus lors dudit au moins un test unitaire, de la charge cible et d'une charge admissible déterminée pour la configuration de référence, et pour utiliser un modèle numérique reflétant au moins une contrainte de déploiement de l'application logicielle imposée à la configuration de serveurs initiale ; - un second outil de test permettant l'exécution de tests de tenue en charge sur ladite 25 application logicielle lorsque celle-ci est exécutée sur la configuration de serveurs initiale sélectionnée par le module de sélection ; et un module de détermination configuré pour déterminer à partir de la configuration initiale une configuration de serveurs cible destinée à être utilisée pour le déploiement de l'application logicielle, ledit module de détermination étant configuré pour commander l'exécution d'une 30 pluralité de tests de tenue en charge par le second outil de test, lesdits tests de tenue en charge étant paramétrés par le module de détermination en fonction d'une charge maximale théorique estimée pour la configuration initiale et de la charge cible, et utilisant au moins un profil de requêtes invoquant ledit au moins un service offert par l'application logicielle, ce profil étant représentatif d'une utilisation de l'application logicielle lors de son déploiement, ledit 35 module de détermination étant en outre configuré pour ajuster, en fonction du résultat de chaque test de tenue en charge, au moins une ressource de la configuration initiale de sorte que la configuration cible obtenue à l'issue de ladite pluralité de tests de tenue en charge soit 3037417 4 apte à vérifier un temps de réponse maximal fixé pour l'application logicielle et à supporter ladite charge cible. Par serveur, on entend ici tout type de machine physique ou virtuelle, apte à exécuter tout ou partie d'une instance de l'application logicielle. L'application logicielle est destinée à être 5 déployée sur une configuration (i.e. un agencement) de serveurs formée d'un ou de plusieurs serveurs reliés entre eux et vérifiant des contraintes de déploiement imposées pour la mise en production de l'application logicielle (ex. déploiement multi-sites, utilisation de machines spécifiques, etc.). L'invention propose donc un procédé de dimensionnement des ressources nécessaires 10 au déploiement d'une application logicielle dans un environnement de production qui s'appuie sur l'exécution structurée de deux types de tests, à savoir des tests unitaires sans accès concurrent aux ressources puis des tests de tenue en charge, judicieusement paramétrés. Ces différents tests sont réalisés sur des configurations de serveurs différentes, à savoir : - pour les tests unitaires, sur une configuration de serveurs dite de référence, prédéterminée et 15 relativement simple, ce qui permet d'obtenir des résultats en termes de consommation de ressources ; et - pour les tests de tenue en charge, sur une configuration de serveurs de production dite initiale dont l'architecture reflète les contraintes imposées par le déploiement de l'application logicielle en environnement de production, et sélectionnée grâce à l'exploitation des résultats des tests 20 unitaires réalisés sur la configuration de référence combinée à un modèle numérique permettant de mettre en correspondance les ressources des deux configurations de serveurs. L'invention permet ainsi de déterminer de façon simple et efficace une configuration de production cible adaptée en termes de ressources au déploiement de l'application logicielle dans un environnement réel d'exécution et vérifiant les différentes exigences contractuelles qui lui sont 25 imposées par l'intermédiaire par exemple d'un accord SLA tel que précédemment décrit. Cette configuration cible est obtenue en ajustant de façon itérative à l'issue de chaque test de tenue en charge les ressources de la configuration initiale de sorte à vérifier ces exigences. L'ajustement des ressources d'une configuration de serveurs comprend, au sens de l'invention, le maintien, l'ajout, et/ou le retrait de ressources pour au moins un serveur de la 30 configuration, et/ou le maintien ou la mise à jour de paramètres de cette configuration (comme par exemple le nombre de serveurs considérés dans cette configuration). Cet ajustement conduit à une configuration de production « optimale », c'est-à-dire à une configuration minimale de serveurs, permettant de garantir le respect des exigences fixées pour l'application logicielle en termes de volumétrie (i.e. de charge cible), de disponibilité et de temps de réponse de bout en 35 bout de l'application logicielle aux requêtes des utilisateurs. Comme mentionné précédemment, la configuration de serveurs de référence utilisée pour réaliser les tests unitaires est choisie généralement de complexité relativement réduite par rapport à la configuration de serveurs sur laquelle est destinée à être effectivement déployée 3037417 5 l'application logicielle. Cette configuration de serveurs de référence peut typiquement se limiter à une seule machine (i.e. un serveur unique), par exemple la machine sur laquelle est développée l'application. Les tests unitaires réalisés à partir de cette configuration de référence visent à caractériser, pour chaque type de requête identifié comme pertinent au regard des services offerts par l'application logicielle (ex. requêtes de type souscription, résiliation, consultations d'objets multimédia, traitement, etc.), les ressources consommées par celle-ci sur chaque serveur de la configuration de référence pour traiter ce type de requête quand il n'y a pas d'accès concurrent à ces ressources. Autrement dit, il s'agit là de quantifier l'utilisation au niveau de chaque serveur de la configuration de référence des processeurs (ou unités de traitement centrales ou encore CPU 10 pour « Central Processing Unit » en anglais), de la mémoire (ex. disque, RAM (Random Access Memory)) et/ou encore des ressources réseaux (ex. connecteurs réseaux) sollicitées lors du traitement des requêtes. De tels tests unitaires sont connus en soi et sont classiquement mis en oeuvre lors du développement et du débogage des applications logicielles. Durant ces tests, on s'assure qu'il n'y a 15 pas d'accès concurrent aux ressources dont on cherche à quantifier la consommation pour traiter les requêtes envoyées à l'application logicielle. A cet effet, les requêtes peuvent être par exemple envoyées une par une à l'application logicielle exécutée par la configuration de référence (une requête étant envoyée à l'issue du traitement de la précédente), ou N requêtes (N nombre entier) peuvent être envoyées de façon déterministe à l'application logicielle en s'assurant qu'il n'y ait pas 20 d'accès concurrent aux ressources utilisées pour leur traitement. L'invention propose de tirer profit de ces tests unitaires simples à réaliser pour récolter diverses métriques de consommation de ressources liées au traitement intrinsèque de chaque requête par chaque serveur de la configuration de référence, et plus particulièrement pour chaque service représentatif offert par l'application logicielle, pour obtenir le temps d'exécution moyen 25 d'une requête invoquant ce service par chaque serveur de la configuration de référence. D'autres métriques peuvent bien entendu être obtenues lors de ces tests unitaires, comme par exemple le nombre de connecteurs réseau utilisés simultanément, le volume de RAM utilisé sur chaque serveur, la durée et le volume de disque occupé, la durée s'écoulant entre la fin d'exécution de la requête sur un serveur et le début d'exécution sur le serveur suivant, etc. Les métriques ainsi 30 récoltées servent d'entrées, conformément à l'invention, à des modèles numériques reflétant diverses exigences imposées en termes d'architecture notamment ou de types de machines à la configuration de production (c'est-à-dire diverses contraintes de déploiement de l'application logicielle) et sont exploitées pour sélectionner une configuration de production initiale satisfaisant une volumétrie (charge en termes de débit de requêtes) cible fixée pour l'application logicielle. Les 35 modèles numériques considérés modélisent par exemple les contraintes (exigences) de déploiement de l'application logicielle à partir d'au moins une file d'attente ou d'un réseau de files d'attente. 3037417 6 Il convient de noter que la sélection de la configuration de production initiale se fait sur la base de résultats de tests unitaires conduits dans un environnement d'exécution idéal où les requêtes ne subissent aucune concurrence pour l'accès aux ressources. Les tests unitaires permettent donc de déterminer uniquement quels sont les besoins de l'application logicielle en 5 ressources CPU, mémoire, et/ou réseau pour traiter intrinsèquement chaque requête. La configuration de production initiale sélectionnée conformément à l'invention ne tient donc compte que d'une volumétrie à respecter et du temps d'exécution intrinsèque des requêtes en découlant. Toutefois ces hypothèses ne sont pas représentatives des conditions réelles d'utilisation de l'application logicielle dans lesquelles les requêtes des utilisateurs arrivent généralement de façon 10 non déterministe, typiquement par rafales et avec des débits parfois très différents du débit moyen des requêtes. Les tests unitaires ne fournissent donc aucune information sur le temps de réponse à proprement parler de l'application logicielle dans un environnement de production, de sorte qu'un ajustement des ressources de la configuration de production initiale sélectionnée à l'issue des tests unitaires est proposé par l'invention pour tenir compte des exigences imposées à l'application 15 logicielle en termes notamment de temps de réponse maximal de bout en bout. Ces ajustements sont encadrés par des tests de tenue en charge dûment paramétrés et qui permettent de dimensionner les ressources nécessaires à la mise en production de l'application logicielle. Ces tests de tenue en charge prennent en effet en compte non seulement les contraintes en termes de volumétrie de l'application logicielle, mais également le profil des 20 requêtes invoquant les services offerts par celle-ci et en particulier la nature des temps d'inter- arrivées des requêtes (i.e. la distribution d'arrivée de ces requêtes au niveau de l'application logicielle). Ainsi, un profil de requêtes invoquant un service comprend par exemple, pour au moins une période de temps déterminée d'un cycle d'activité de l'application logicielle ou d'un cycle d'activité de l'application logicielle : 25 un débit moyen des requêtes invoquant ce service sur ladite période de temps ; une proportion de requêtes invoquant ce service parmi les requêtes invoquant des services offerts par l'application logicielle ; et une distribution des durées d'inter-arrivées entre deux requêtes invoquant ce service sur ladite période de temps. 30 En d'autres mots, les tests de tenue en charge prennent en compte un profil de requêtes réaliste représentatif de l'utilisation de l'application logicielle dans un environnement réel d'exécution (i.e. similaire ou tout du moins proche de celui auquel on s'attend lors de la mise en production de l'application logicielle). Il convient de noter que la configuration de production initiale sélectionnée par 35 l'invention n'est pas nécessairement strictement conforme à la configuration de serveurs qui sera déployée ultérieurement en production et testée dans un environnement réel d'exécution. Elle peut être notamment de complexité plus réduite, mais elle est sélectionnée préférentiellement de sorte à être représentative des différentes fonctionnalités et problématiques attendues lors de la mise en 3037417 production de l'application logicielle. Ainsi, la configuration de serveurs initiale est choisie préférentiellement de sorte à être représentative de la complexité logicielle, technique et fonctionnelle de l'environnement de production de l'application logicielle (ex. présence d'un noeud maître et de plusieurs noeuds secondaires qui communiquent entre eux, modélisation de la 5 communication inter-sites, prise en compte des problèmes de sécurité, etc.). De cette sorte, on s'assure que le dimensionnement des ressources réalisé par l'invention est pertinent et exploitable pour faciliter le déploiement en production de l'application et limiter les tests réalisés à grande échelle. Plusieurs configurations de serveurs cibles peuvent être identifiées à partir de 10 l'invention. La sélection de l'une de ces configurations peut ensuite être réalisée à partir de tests expérimentaux réalisés dans l'environnement de production. Toutefois le nombre de configurations de serveurs à tester est considérablement réduit par rapport à l'état de la technique. L'invention se distingue donc de l'état actuel de la technique en ce qu'elle offre une solution qui permet, avant la mise en production de l'application logicielle, de présélectionner et de 15 dimensionner, au moyen de modèles numériques, une ou plusieurs configurations de serveurs appropriées qui servent de points de départ pour le déploiement réel de l'application. Ainsi, contrairement à l'état de la technique, la sélection de la configuration optimale ne s'appuie pas uniquement sur des tests expérimentaux réalisés en production dans un environnement réel d'exécution et qui peuvent s'avérer, comme mentionné précédemment, hasardeux, coûteux et 20 chronophages. L'invention offre au contraire une possibilité de pré-provisionner les ressources nécessaires à l'exécution d'une application logicielle, ce qui permet d'effectuer de tels tests expérimentaux uniquement sur un nombre réduit de configurations en vue de sélectionner une configuration optimale. On obtient ainsi grâce à l'invention un gain substantiel en complexité et en temps. 25 L'invention permet donc, par rapport aux solutions existantes basées essentiellement sur des observations expérimentales, d'assurer la maîtrise et l'efficacité de la gestion de l'élasticité, et de réduire les coûts d'investissement pour des applications logicielles et des systèmes de type PaaS. Il convient de noter par ailleurs que de façon avantageuse, la mise en oeuvre de 30 l'invention ne requiert pas de connaissance détaillée des composants logiciels constituant l'application logicielle ni de l'enchaînement d'exécution de ces composants. L'application logicielle peut avantageusement être considérée comme une « boîte noire » offrant un ou plusieurs services en réponse à des requêtes d'utilisateur vérifiant un certain profil, et répartie ou instanciée sur un ou plusieurs serveurs. Les métriques de consommation des ressources issues des tests unitaires et 35 qui sont ensuite utilisées pour sélectionner une configuration de serveurs initiale sur laquelle sont effectués les tests de tenues en charge sont des métriques tous composants confondus mesurées sur chaque serveur de la configuration de référence. 3037417 8 Dans un mode particulier de réalisation de l'invention, le procédé de détermination comprend en outre une étape d'estimation d'une charge maximale théorique pour la configuration de référence et la charge admissible déterminée pour la configuration de référence résulte du produit d'un paramètre a compris entre 0 et 1 par la charge maximale théorique estimée pour la 5 configuration de référence. Par exemple, la charge maximale théorique pour la configuration de référence est estimée en appliquant une condition de stabilité de l'application logicielle à au moins un temps d'exécution moyen d'une requête de l'application logicielle dérivé pour ledit au moins un serveur de la configuration de référence à partir des temps d'exécution moyens obtenus pour ce serveur pour 10 les services offerts par l'application logicielle. Une telle condition de stabilité est vérifiée notamment si pour chaque serveur de la configuration de serveurs considérée pour exécuter l'application logicielle, le taux (débit) d'arrivée des requêtes est strictement inférieur au taux d'utilisation de ce serveur. Le temps de réponse du serveur peut être utilisé pour évaluer son taux d'utilisation. Cette condition de stabilité permet 15 d'évaluer facilement une charge théorique maximale pour l'application logicielle aux alentours de laquelle l'application logicielle n'est plus capable de traiter les requêtes. Cette charge théorique maximale est utilisée pour dimensionner la configuration de serveurs initiale. Par ailleurs, les inventeurs ont observé qu'en amont de cette charge théorique maximale, le temps de réponse moyen d'un serveur en fonction de la charge de l'application 20 logicielle suit généralement un premier régime linéaire en pente douce suivi d'une montée brutale définissant un deuxième régime linéaire à l'approche de la saturation du serveur. Le paramètre a compris entre 0 et 1 utilisé pour définir la charge admissible de la configuration initiale est choisi préférentiellement pour que la charge admissible considérée se situe dans une zone de transition se trouvant juste avant le deuxième régime linéaire et dans laquelle le temps de réponse de bout 25 en bout de l'application logicielle reste inférieur à un temps de réponse maximal fixé pour l'application logicielle (typiquement dans l'accord SLA). Dans cette zone « optimale », le temps de réponse versus la charge est contenu et reste inférieur au temps de réponse maximal autorisé pour l'application logicielle. On note que la valeur du paramètre a peut dépendre de la distribution des temps d'inter-arrivées des requêtes, comme détaillé ultérieurement. Toutefois une valeur de 0.8 ou 30 0.85 (ou aux alentours de ces deux valeurs) convient généralement assez bien pour mettre en oeuvre l'invention. Dans un mode particulier de réalisation, au cours de l'étape de détermination, l'ajustement d'au moins une ressource de la configuration initiale à l'issue d'un test de tenue en charge est réalisé en fonction d'une différence entre un temps de réponse de l'application logicielle 35 évalué lors du test de tenue en charge et le temps de réponse maximal fixé pour l'application logicielle. Cette façon d'ajuster les ressources en tenant compte du temps de réponse maximal fixé pour l'application logicielle et le temps de réponse obtenu de bout en bout avec la 3037417 9 configuration de serveurs en cours de test permet de converger rapidement vers un dimensionnement approprié des ressources. Dans un mode de réalisation, l'étape de détermination comprend au moins : un premier test de tenue en charge réalisé avec une première charge inférieure à une valeur 5 minimum entre une moitié de la charge maximale théorique estimée pour la configuration initiale et le produit de la charge cible par un nombre réel prédéterminé inférieur ou égal à 1 ; un deuxième test de tenue en charge réalisé avec une deuxième charge inférieure à la première charge ; et un troisième test de tenue en charge réalisé avec une troisième charge égale à la charge cible. 10 Ce protocole permet de limiter les tests de tenue en charge réalisés sur la configuration de serveurs initiale et d'aboutir rapidement à une configuration de serveurs cible dérivée de la configuration initiale. Par configuration dérivée de la configuration initiale on entend au sens de l'invention que la configuration est la même que la configuration initiale si celle-ci est considérée comme correctement dimensionnée ou qu'elle est obtenue après avoir ajusté des 15 ressources de la configuration initiale. Dans ce mode de réalisation, l'étape de détermination peut comprendre en outre une estimation à l'issue du deuxième test, d'un temps de réponse de l'application logicielle avec la charge cible à partir d'un temps de réponse évalué à l'issue du premier test réalisé avec la première charge sur une configuration testée dérivée de la configuration de serveur initiale et d'un 20 temps de réponse de l'application logicielle évalué à l'issue du deuxième test réalisé avec la deuxième charge sur ladite configuration testée, l'ajustement de ressources étant réalisé à l'issue du deuxième test en fonction d'une différence entre le temps de réponse estimé pour la charge cible et le temps de réponse maximal fixé pour l'application logicielle. Typiquement, à l'issue du deuxième test : 25 - la configuration de serveurs testée peut être considérée comme sous-dimensionnée si le temps de réponse estimé pour la charge cible est supérieur au temps de réponse maximal ; et/ou la configuration de serveurs testée peut être considérée comme surdimensionnée si le temps de réponse estimé pour la charge cible est inférieur au produit d'un nombre réel prédéterminé y compris entre 0 et 1 et du temps de réponse maximal, par exemple 0.9 ; et/ou 30 la configuration de serveurs testée peut être considérée comme correctement dimensionnée sinon. L'ajustement des ressources est ensuite réalisé en conséquence et le ou les tests de tenue en charge précédents sont réitérés sur la configuration ajustée pour valider cet ajustement et/ou procéder à un nouvel ajustement, et ce, jusqu'à déterminer la configuration cible apte à être 35 déployée et qui répond aux exigences fixées pour la mise en production de l'application logicielle en termes de charge et de temps de réponse de bout en bout. Typiquement, la configuration cible correspond à une configuration de serveurs testée pour laquelle à l'issue du troisième test, un 3037417 10 temps de réponse de l'application logicielle évalué pour la charge cible sur cette configuration de serveurs testée est inférieur au temps de réponse maximal. Dans un mode de réalisation particulier de l'invention, le procédé de détermination comprend en outre une étape de validation de la configuration cible au moyen d'un test 5 d'endurance réalisé pendant une durée d'exécution prédéterminée de l'application logicielle. Il s'agit par ce test d'endurance de tester l'application logicielle et la configuration de serveurs cible déterminée aux tests unitaires et aux tests de tenue en charge sur une durée suffisamment longue afin de prendre en compte, pour le dinnensionnement des ressources, des évènements rares dont la probabilité d'apparition est relativement faible. Le résultat de ce test 10 d'endurance permet de réajuster le cas échéant les ressources de la configuration cible en vue du déploiement de l'application logicielle. En effet, les métriques et les modèles numériques utilisés conformément à l'invention pour déterminer la configuration cible reposent sur certaines hypothèses d'abstraction sur le comportement de l'application logicielle, et notamment d'indépendance de certains composants ou de distribution des requêtes. Le test d'endurance 15 permet d'affiner ces modèles (et d'ajuster si besoin le dimensionnement des ressources), et dans une certaine mesure, de mettre en évidence les écarts entre la réalité et les modèles numériques utilisés établis, de les évaluer et de juger de leurs pertinences. Dans un mode particulier de réalisation, l'application logicielle est caractérisée par un cycle d'activité comprenant une pluralité d'intervalles, chaque intervalle étant associé à un débit 20 moyen d'arrivée des requêtes représentatif sur cet intervalle, et dans lequel lesdites étapes d'obtention, de sélection et de détermination sont mises en oeuvre pour au moins un intervalle de ladite pluralité d'intervalles. Ce mode de réalisation permet de s'adapter aux applications logicielles pour lesquelles on a une distribution dynamique des requêtes, autrement dit pour lesquelles le débit des arrivées 25 de requêtes de services varie de manière significative sur des intervalles de temps et ce de façon répétitive sur le cycle d'activité. Selon un autre aspect, l'invention vise également un procédé de gestion d'élasticité d'une configuration de serveurs apte à exécuter une application logicielle, ce procédé comprenant : une étape de détermination d'une configuration cible de serveurs pour le déploiement de 30 l'application logicielle comprenant l'exécution d'un procédé de détermination selon l'invention ; et une étape d'exécution de l'application logicielle sur ladite configuration cible de serveurs comprenant : o une surveillance d'au moins une métrique de supervision de cette configuration cible ; 35 et o en fonction de ladite au moins une métrique, un ajustement des ressources de la configuration cible, cet ajustement comprenant un maintien et/ou un ajout et/ou un retrait dynamique de ressources à la configuration cible. 3037417 11 L'invention vise aussi un système de gestion d'élasticité d'une configuration de serveurs apte à exécuter une application logicielle comprenant : un système selon l'invention de détermination d'une configuration cible de serveurs pour le déploiement de l'application logicielle comprenant l'exécution d'un procédé de détermination ; 5 un module de déclenchement d'une exécution de l'application logicielle sur la configuration cible de serveurs ; un module de surveillance d'au moins une métrique de supervision de cette configuration cible lors de l'exécution de l'application logicielle ; et un module d'ajustement configuré pour ajuster les ressources allouées à la configuration cible 10 en fonction de ladite au moins une métrique, ce module d'ajustement étant apte à maintenir les ressources allouées ou à ajouter et/ou retirer dynamiquement des ressources à la configuration cible. Le procédé et le système de gestion d'élasticité bénéficient des mêmes avantages cités précédemment que le procédé et le dispositif de détermination selon l'invention. 15 Dans un mode particulier de réalisation, les différentes étapes du procédé de détermination et/ou du procédé de gestion d'élasticité sont déterminées par des instructions de programmes d'ordinateurs. En conséquence, l'invention vise aussi un programme d'ordinateur sur un ou plusieurs support(s) d'informations, ce programme étant susceptible d'être mis en oeuvre dans un système 20 de détermination ou plus généralement dans un ordinateur, ce programme comportant des instructions adaptées à la mise en oeuvre des étapes d'un procédé de dimensionnement tel que décrit ci-dessus. L'invention vise également un programme d'ordinateur sur un ou plusieurs support(s) d'informations, ce programme étant susceptible d'être mis en oeuvre dans un système de gestion 25 d'élasticité ou plus généralement dans un ordinateur, ce programme comportant des instructions adaptées à la mise en oeuvre des étapes d'un procédé de gestion d'élasticité tel que décrit ci- dessus. Ce programme peut utiliser n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel 30 que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable. L'invention vise aussi un support d'informations lisible par un ordinateur, et comportant des instructions d'un programme d'ordinateur tel que mentionné ci-dessus. Le support d'informations peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une 35 ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple une disquette (floppy disc) ou un disque dur. D'autre part, le support d'informations peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio 3037417 12 ou par d'autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet. Alternativement, le support d'informations peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution 5 du procédé en question. On peut également envisager, dans d'autres modes de réalisation, que le procédé de détermination, le procédé de gestion d'élasticité, le système de détermination et le système de gestion d'élasticité selon l'invention présentent en combinaison tout ou partie des caractéristiques précitées. 10 Brève description des dessins D'autres caractéristiques et avantages de la présente invention ressortiront de la description faite ci-dessous, en référence aux dessins annexés qui en illustrent un exemple de réalisation dépourvu de tout caractère limitatif. Sur les figures : 15 - la figure 1 représente, de façon schématique, un système de détermination conforme à l'invention, dans un mode particulier de réalisation ; - la figure 2 représente un outil de test permettant la réalisation de tests de tenue en charge sur une configuration de serveurs de référence sur laquelle est déployée une application logicielle et pouvant être utilisé comme composant du système de détermination de la figure 1 ; 20 - les figures 3A et 3B illustrent, pour deux services distincts d'une application logicielle, un cycle d'activité de cette application logicielle et la répartition des nombres d'arrivées de requêtes sur ce cycle d'activité ; la figure 4 représente, sous forme d'ordinogramme, les principales étapes d'un procédé de détermination conforme à l'invention dans un mode particulier de réalisation dans lequel il est 25 mis en oeuvre par le système de détermination de la figure 1; - les figures 5A à 5D illustrent l'évolution du temps de réponse d'un serveur en fonction de la charge de l'application logicielle, et pour différents profils de requêtes ; - les figures 6A à 6D illustrent plusieurs modèles de systèmes de files d'attente pouvant être utilisés pour déterminer la configuration initiale selon l'invention ; 30 - la figure 7 détaille, sous forme d'ordinogramme, les principales étapes mises en oeuvre par le système de détermination de la figure 1 dans un mode particulier de l'invention pour déterminer la configuration de serveurs cible à partir de la configuration initiale ; - les figures 8A à 8D illustrent différents cas de figure conduisant à un ajustement des ressources de la configuration initiale conformément à l'invention ; 35 - la figure 9 représente, sous forme d'ordinogramme, les principales étapes d'un procédé de gestion de l'élasticité conforme à l'invention, dans un mode particulier de réalisation ; et - la figure 10 illustre le traitement mis en oeuvre dans un mode particulier de réalisation de l'invention lorsque l'application logicielle présente un cycle d'activité périodique. 3037417 13 Description détaillée de l'invention La figure 1 représente, dans son environnement, un système 1 de détermination d'une configuration de machines pour le déploiement d'une application logicielle APP, conforme à l'invention, dans un mode particulier de réalisation. Le système 1 propose, par le biais de la 5 configuration ainsi déterminée (désignée par configuration cible dans la suite de la description), un dimensionnennent des ressources nécessaire à la mise en production de l'application logicielle APP, autrement dit à son déploiement dans un environnement réel d'exécution. Aucune limitation n'est attachée à la nature de l'application logicielle APP. Il peut s'agir d'une application permettant l'accès à ou la génération de contenus multimédia, le référencement 10 de produits, l'accès à des équipements distants, etc. Cette application logicielle APP est apte à offrir un ou plusieurs services UC1,UC2,...,UCN (N entier supérieur ou égal à 1) à des utilisateurs, sur réception de requêtes invoquant ces services émises par ces derniers via des terminaux (ex. via un terminal mobile, un ordinateur, etc.). 15 Dans l'exemple envisagé ici, l'application logicielle APP est destinée à être déployée (i.e. mise en production) dans un système informatique en nuage ou cloud (non représenté), sur une configuration cible de machines (serveurs) virtuelles hébergées par le cloud. Dans un tel contexte, la gestion de l'élasticité des ressources mises à disposition par le cloud pour l'exécution des applications logicielles qu'il héberge est très importante : le cloud cherche en effet à optimiser 20 le partage des ressources communes aux applications logicielles qu'il héberge en vue de réduire notamment le coût de leur déploiement, tout en garantissant la qualité des services offerts par ces applications à leurs utilisateurs. Les ressources partagées peuvent être de différentes natures : il peut s'agir notamment de ressources de type processeurs ou CPU de machines (serveurs) virtuelles et/ou physiques, de ressources mémoires (ex. RAM, disque, etc.), ou encore de 25 ressources réseaux (ex. connecteurs réseaux, etc.). La gestion de l'élasticité dans le cloud a donc pour fonction de fournir aux différentes applications logicielles les ressources précitées nécessaires à leur exécution et de garantir leur bon fonctionnement selon un accord de niveau de service (ou SLA) convenu au préalable. Chaque SLA définit des contraintes spécifiques à l'application logicielle auquel il se rapporte, notamment en 30 termes de volumétrie, de disponibilité, de temps de réponse, de fiabilité mais également de coût, de placement des machines (virtuelles dans le contexte du cloud) sur lesquelles sont déployées l'application, de droits d'utilisation et d'abonnements, etc. Autrement dit, chaque SLA associé à une application logicielle définit un certain nombre d'exigences qui se doivent d'être respectées par le cloud. La gestion de l'élasticité a pour rôle de déterminer les ressources nécessaires au 35 déploiement de l'application logicielle APP dans le cloud afin de répondre aux exigences fixées par ce SLA et ce, tout en prenant en compte les ressources engagées pour d'autres applications logicielles hébergées par le cloud et en cours d'exécution. 3037417 14 Dans l'exemple envisagé ici, la gestion de l'élasticité du cloud hébergeant l'application logicielle APP s'appuie sur le système de détermination 1. Plus particulièrement, celui-ci permet une gestion efficace de l'élasticité du cloud en offrant la possibilité de procéder à un préprovisionnement des ressources nécessaires à l'exécution de l'application APP avant sa mise en 5 production via la détermination d'une configuration adaptée au déploiement de l'application APP dans un environnement réel d'exécution (aussi désignée par configuration « cible »). A cet effet, conformément à l'invention, le système de détermination 1 s'appuie sur différents environnements de tests de l'application logicielle APP dans lesquels l'application est déployée sur différentes configurations de serveurs, et sur différents modules (logiciels ici) mettant 10 en oeuvre des algorithmes ou des modèles de calcul programmés exploitant les résultats obtenus dans ces environnements de tests. Plus précisément, dans le mode de réalisation décrit ici, le système de détermination 1 comprend : un outil logiciel (ou environnement) de test ENV1, construit pour réaliser des tests unitaires sur 15 l'application logicielle APP lorsque celle-ci est déployée sur une première configuration de serveurs CONFIG1 dite de référence, constituée d'un nombre Ni de serveurs reliés entre eux (Ni désignant un entier supérieur ou égal à 1) ; un outil logiciel (environnement) de test ENV2, construit pour réaliser des tests de tenue en charge de l'application logicielle APP lorsque celle-ci est déployée sur une deuxième 20 configuration de serveurs CONFIG2 dite initiale, constituée d'un nombre N2 de serveurs reliés entre eux (N2 désignant un entier supérieur ou égal à 1), et tenant compte de contraintes de déploiement de l'application logicielle APP lors de sa mise en production ; un module 2 de récolte de diverses métriques lors des tests unitaires réalisés dans l'environnement de test ENVI., apte à évaluer à partir de ces métriques une consommation des 25 ressources par les serveurs de la configuration CONFIG1 pour le traitement de requêtes invoquant des services offerts par l'application logicielle APP. Plus précisément, le module 2 est apte à obtenir ici, à partir des métriques récoltées, un temps d'exécution moyen d'une requête invoquant un service offert par l'application logicielle APP pour chaque serveur de la configuration de référence CONFIG1 et pour chaque service offert par l'application logicielle 30 APP. Il est également configuré pour estimer à partir des temps d'exécution moyens obtenus, une charge théorique maximale kmaxi pouvant être supportée par la configuration de référence CONFIG1; un module 3 de sélection de la configuration de serveurs initiale CONFIG2 sur laquelle sont réalisés les tests de tenue en charge via l'environnement de test ENV2 et qui sert de point de 35 départ au dimensionnement des ressources nécessaires pour la mise en production de l'application logicielle APP. Cette configuration CONFIG2 est sélectionnée par le module 3 de sorte à supporter une charge cible déterminée ktarg. Pour déterminer la configuration CONFIG2, le module 3 est configuré de sorte à tenir compte des temps d'exécution moyens et 3037417 15 de la charge théorique maximale krnax1 déterminés par le module 2, et à utiliser un modèle numérique reflétant les contraintes de déploiement de l'application logicielle en environnement réel d'exécution (ex. types de machines utilisées, déploiement multi-sites, connexions réseau requises, etc.). Le module 3 est également configuré pour déterminer une charge maximale 5 théorique kmax2 pour la configuration initiale CONFIG2 ainsi sélectionnée ; et - un module 4 d'ajustement des ressources et des paramètres des serveurs de la configuration CONFIG2, configuré pour déterminer à partir de la configuration initiale CONFIG2 une configuration de serveurs cible désignée par CONFIG_TARG pour la mise en production de l'application logicielle APP. Cette configuration cible est déterminée par le module 4 en 10 réalisant plusieurs tests en tenue de charge sur la configuration initiale CONFIG2 grâce à l'outil de test ENV2 : le module 4 réajuste le cas échéant à l'issue de chacun des tests, en fonction des résultats obtenus (en terme de temps de réponse moyen notamment de l'application logicielle sur la configuration testée), les ressources et les paramètres des serveurs de la configuration initiale CONFIG2 jusqu'à déterminer une configuration qui permette de garantir 15 un temps de réponse maximal TRmax fixé pour l'application logicielle APP et qui supporte la charge cible ktarg. Dans le mode de réalisation décrit ici, par souci de simplification, la configuration de référence CONFIG1 est constituée d'un serveur unique (i.e. N1=1), par exemple, le serveur S11 sur lequel a été déployée l'application APP. La généralisation de l'invention à une configuration de 20 référence plus complexe comprenant une pluralité de serveurs reliés entre eux et sur lesquels sont déployées différentes unités de déploiement de l'application logicielle APP est évoquée ultérieurement. L'outil de test ENVi est un environnement logiciel de test similaire à ceux construits classiquement pour le débogage des applications logicielles et connus de l'homme du métier. Il 25 n'est par conséquent pas décrit en détail ici. Cet environnement ENVi permet au module 2 de récolter diverses métriques, pour chaque type de requêtes identifié comme pertinent pour les services offerts par l'application logicielle APP, chaque type de requête considéré étant associé à un unique service offert par l'application. Ainsi, dans l'exemple envisagé ici, le module 2 récolte à partir des tests unitaires 30 menés dans l'environnement de test ENVi une métrique représentative de la consommation moyenne de CPU par l'application logicielle APP sur le serveur S11 de la configuration de référence CONFIG1 pour le traitement d'une requête de chaque type de requêtes retenu, autrement dit pour chaque service. Cette métrique est définie ici comme le temps d'exécution moyen d'une requête du service envisagé par le serveur de la configuration de référence CONFIG1 (autrement dit le temps 35 de traitement moyen d'une telle requête par le serveur ou encore le temps de réponse moyen du serveur à une telle requête). Le temps d'exécution d'une requête par un serveur est défini comme la somme des durées d'exécution des processus de l'application logicielle APP (ou encore des 3037417 16 tâches ou fils, plus communément désignés par « threads » en anglais) associés à la requête après/avant des entrées/sorties. En variante, le module 2 peut récolter une métrique représentative d'un taux moyen d'utilisation de CPU sur le serveur considéré, le taux d'utilisation de CPU étant défini comme le 5 pourcentage de temps où le ou les processeurs (CPU) du serveur est (sont) actif(s) par rapport à la durée d'observation lors du traitement de la requête. Cette métrique peut également être évaluée à partir du temps moyen d'exécution d'une requête par le serveur considéré, comme détaillé ultérieurement. Dans le mode de réalisation décrit ici, on se limite à des métriques relatives à 10 l'utilisation du ou des processeurs (CPU) des serveurs et au dimensionnement de ces processeurs pour déterminer la configuration cible CONFIG_TARG. Cette ressource est en effet la plus critique et la plus sensible lorsque l'on envisage une gestion dynamique des ressources dans un système de type cloud comparativement par exemple à la mémoire. Toutefois, cette hypothèse n'est pas limitative et le dimensionnement d'autres 15 ressources peut être envisagé grâce à l'invention, comme notamment le dimensionnement de ressources mémoire (ex. disque, RAM) et/ou réseaux. A cet effet, d'autres métriques peuvent être obtenues lors des tests unitaires réalisés dans l'outil de test ENVi comme notamment : - une métrique représentative de la consommation de RAM, définie à partir du volume de RAM utilisé pour le traitement de la requête ; 20 - des métriques représentatives d'une consommation de disque, définies à partir de la durée et du volume de disque occupé lors du traitement de la requête ; - une métrique représentative d'une consommation réseau définie comme la durée s'écoulant entre la fin d'exécution de la requête sur un serveur et le début d'exécution de la requête sur le serveur suivant (qui pourrait être le même serveur) ; 25 - etc. Les tests unitaires réalisés avec l'outil de test ENVi s'appuient sur des scenarios (c'est-à-dire des cas d'utilisation de l'application) consistant à émettre chaque requête après la réception et le traitement de la requête précédente de sorte à ce qu'il n'y ait pas d'accès concurrent aux ressources (CPU ici) dont on cherche à quantifier la consommation. Chaque scénario s'ensuit du 30 déroulement séquentiel ou en parallèle des fonctions composant l'application logicielle (aussi désigné par flot ou graphe d'exécution ou encore « workflow » en anglais). En variante, ces scenarios peuvent consister à émettre un nombre entier K de requêtes de façon déterministe ou périodique si le temps de traitement d'une requête n'est pas significatif, et sans accès concurrent aux ressources CPU. 35 Les requêtes considérées dans les scenarios mis en oeuvre par l'outil de test ENVi correspondent à des requêtes considérées comme pertinentes au regard des services offerts par l'application logicielle APP. La description des services offerts par l'application logicielle APP et des 3037417 17 types de requêtes invoquant ces services est obtenue par exemple de l'administrateur et/ou le développeur de l'application logicielle APP, comme indiqué plus en détail ultérieurement. Les tests unitaires déroulés dans l'environnement de test ENVi permettent donc de quantifier une consommation de ressources au niveau de chaque serveur de la configuration de 5 référence considérée pour le traitement des requêtes mais sans accès concurrent à ces ressources : ils ne fournissent par conséquent aucune information pertinente à proprement parler en termes de temps de réponse des serveurs dans un environnement réel d'exécution. Ces informations de temps de réponse, dont la connaissance est utilisée ici pour dimensionner les ressources de la configuration de production de l'application logicielle APP pour atteindre une 10 charge cible Xtarg donnée (c'est-à-dire une volumétrie imposée à l'application logicielle APP), sont obtenues dans un second temps grâce à l'outil de test ENV2 qui permet de réaliser des tests de tenue en charge sur une autre configuration de serveurs (i.e. la configuration initiale CONFIG2) construite par le module 3 à partir des résultats de tests unitaires obtenus par le module 2. Dans le mode de réalisation décrit ici, la configuration de serveurs initiale CONFIG2 est 15 choisie par le module 3 de sorte à être représentative des différentes contraintes et fonctionnalités attendues lors de la mise en production de l'application logicielle, et notamment de la complexité logicielle, technique et fonctionnelle de l'environnement d'exécution réel de l'application logicielle (aussi appelé environnement de production). Ainsi notamment, si l'on envisage un déploiement multi-sites de l'application logicielle, la configuration de serveurs initiale CONFIG2 doit comprendre 20 une pluralité de noeuds matérialisant la composante « multi-sites », un noeud central orchestrant les données véhiculées par la pluralité de noeuds, et modéliser les communications entre les différents noeuds sur lesquels s'appuie l'application logicielle. La configuration de serveurs initiale peut toutefois comprendre un nombre N2 de serveurs réduit par rapport au nombre de sites sur lesquels on envisage de déployer réellement l'application en vue de limiter notamment le coût, la 25 complexité et le temps des tests à réaliser. De façon similaire, si lors de la mise en production de l'application logicielle on envisage une fonctionnalité de type pare-feu, cette fonctionnalité doit être reflétée au niveau de la configuration de serveurs initiale. Le type de machines utilisées (ex. mono ou multiprocesseurs, capacités maximales des machines, etc.) peut également être une contrainte imposée par l'environnement de production et qui doit être reflétée dans la configuration initiale. 30 Ces différentes contraintes imposées par l'environnement de production sont matérialisées conformément à l'invention par un modèle numérique MOD, qui s'appuie ici sur le formalisme des files d'attentes ou des réseaux de files d'attente. Différents exemples de modèles numériques sont illustrés ultérieurement. Le module 3 sélectionne alors la configuration initiale CONFIG2 en utilisant ce modèle numérique MOD et en tenant compte d'une part, des résultats des 35 tests unitaires réalisés sur la configuration de référence CONFIG1 (et notamment des temps d'exécution moyens obtenus pour chaque serveur de la configuration de référence pour chaque type de requête considéré (i.e. pour chaque service), et de la charge maximale théorique) qui 3037417 18 servent de référence pour dimensionner les ressources de la configuration initiale CONFIG2, et d'autre part, de la charge cible Xtarg fixée pour l'application logicielle APP (c'est-à-dire de la volumétrie imposée à l'application logicielle APP). La configuration initiale CONFIG2 sélectionnée par le module 3 est donc un échantillon 5 réduit de la configuration de serveurs sur laquelle est destinée à être mise en production l'application logicielle APP. Cette configuration initiale CONFIG2 est utilisée conformément à l'invention comme point de départ par le module 4 du système de détermination 1 pour le dimensionnement des ressources nécessaires à l'exécution de l'application logicielle APP en environnement de production. 10 Plus précisément, le module 4 est configuré pour procéder à un ajustement des ressources de la configuration initiale CONFIG2 en fonction de résultats de tests de tenue en charge réalisés à l'aide de l'outil de test ENV2 en vue de déterminer une configuration de serveurs « cible » CONFIG_TARG pour déployer l'application logicielle APP dans un environnement de production. Ces tests permettent d'évaluer la capacité de traitements (ex. taux d'utilisation des 15 CPU ou de la mémoire, temps de réponse, etc.) des serveurs de la configuration CONFIG2 sur laquelle est déployée l'application logicielle APP, pour différentes valeurs de débit de requêtes (i.e. différentes charges de l'application logicielle) avec des flux de requêtes utilisateurs simulés représentatifs d'une utilisation réelle de l'application. A cet effet, l'outil de test ENV2 tient compte des instances de déploiement de 20 l'application logicielle APP sur les serveurs de la configuration CONFIG2, de même que de la topologie reliant les instances, du périmètre de l'application logicielle APP par rapport à son environnement (i.e. applications ou produits logiciels tiers, terminaux, etc.), des protocoles de communication mis en oeuvre, etc. Il tient compte également des caractéristiques logicielles et matérielles de la configuration CONFIG2, et notamment du paramétrage des machines physiques 25 et des machines (serveurs) virtuelles, des espaces de stockage, des aspects réseaux, et du paramétrage des produits intermédiaires (ou « middleware » en anglais) comme les serveurs d'application, les bases de données, les bus et les protocoles de communication, etc. La figure 2 illustre schématiquement un exemple d'un tel environnement de test ENV2ex élaboré pour tester une application logicielle déployée sur une configuration de serveurs 30 comprenant un serveur de présentation 6, un serveur d'application 7 et un serveur de données 8. Une instance de l'application logicielle est installée sur le serveur d'application 7. Dans l'exemple illustré à la figure 2, des requêtes HTTP (HyperText Transfer Protocol) sont envoyées par un dispositif d'injection de charge 9 à l'application logicielle APP pour traitement. Les serveurs 6, 7 et 8 sont reliés à une zone de stockage 10, via le protocole NFS 35 (Network File System). L'application logicielle APP interagit avec des dispositifs tiers, tels que par exemple un serveur d'une zone d'échange mutualisée 11 et un serveur rebond 13, et différents systèmes externes 12 et 14 modélisés à l'aide de simulateurs partenaires. 3037417 19 De manière générale, pour réaliser des tests en tenue de charge de l'application logicielle APP, l'outil de test ENV2 comprend notamment : - des modules ou dispositifs d'injection de charge, aptes à générer et à fournir à l'application logicielle APP différents niveaux de charge générés par des utilisateurs virtuels (chaque niveau 5 de charge correspondant à un nombre d'utilisateurs virtuels différents), et à mesurer des temps de réponse moyens ou médians aux requêtes émises par ces utilisateurs virtuels. Ces modules d'injection de charge sont ici des modules CLIF s'appuyant sur un modèle de composante fractale et décrits notamment dans le document de B. Dillenseger intitulé « CLIF, a framework based on Fractal for flexible, distributed load testing », Annales des 10 Télécommunications,vol. 64, n°1-2, février 2009; et des sondes permettant d'observer différentes métriques de consommation de ressources (CPU, mémoire, réseaux, etc.) par l'application logicielle sur les serveurs de la configuration testée. L'outil de test ENV2 est configuré pour injecter, via ses modules d'injection de charge, de façon automatique, sur une durée fixe et selon une politique d'injection prédéterminée décrite 15 plus en détail ultérieurement, différents niveaux de charge (i.e. différents nombres de requêtes par unité de temps croissants) à la configuration de serveurs testée et supportant l'application logicielle APP. L'outil de test ENV2 est programmé à cet effet pour observer, après injection de chaque niveau de charge, le comportement de la configuration de serveurs testée, et décider en fonction de ce comportement du prochain niveau de charge à injecter. Le processus est réitéré jusqu'à 20 l'atteinte d'un critère prédéterminé. L'homme du métier est invité à se référer au document de N. Salmi et al. intitulé « Model-based performance anticipation in multi-tiers autonomic systems : methodology and experiments », International Journal on Advances in Networks and Services, vol 3 no 3 8( 4, 2010 (http://www.iariajournals.org/networks_and_services/tocv3n34.html), section III, pour plus de 25 détails sur l'automatisation du processus d'injection de charge mis en oeuvre par l'outil de test ENV2. Il convient toutefois de noter qu'à l'instar du mode de fonctionnement décrit dans le document de N. Salmi et al., l'outil de test ENV2 utilise, conformément à l'invention, des scénarios d'injection de charge s'appuyant sur des profils de requêtes utilisateurs représentatifs de 30 l'utilisation réelle ou tout du moins attendue de l'application logicielle APP en environnement de production (ou s'en approchant le plus possible). De tels profils peuvent être obtenus par exemple du développeur et/ou de l'administrateur de l'application logicielle APP. Ils comprennent notamment des informations relatives à la fréquence d'arrivée des requêtes, et plus particulièrement : 35 à la répartition des différents types de requêtes (i.e. proportion de chaque type de requêtes) ; aux débits moyens d'arrivée des différents types de requêtes associés aux services offerts par l'application logicielle APP ; et 3037417 20 - aux distributions des durées (temps) d'inter-arrivées entre ces requêtes (ex. distributions déterministes ou de type rafales telles que par exemple une distribution aléatoire ou exponentielle). Des informations relatives aux débits minimum et maximum peuvent également être contenues dans ces profils. Ainsi, les requêtes injectées par l'outil de test ENV2 ne sont plus systématiquement espacées de façon déterministe (ex. périodique) ou successives comme pour les tests unitaires réalisés par l'outil de test ENVI., mais des « grumeaux » de requêtes peuvent se produire et entraîner des concurrences d'accès à des ressources partagées, ce qui peut provoquer un 10 effondrement momentané de l'application logicielle APP (i.e. l'application logicielle est saturée et ne répond plus). En particulier, si un goulot d'étranglement se forme sur un serveur (correspondant à un débit crête de requêtes très supérieur au débit moyen) et persiste, le risque d'écroulement de l'application logicielle peut devenir non négligeable et le temps de réponse de celle-ci se dégrader rapidement. Les comportements observés en termes de temps de réponse et de consommation de 15 ressources de l'application logicielle à l'aide de cet outil de test ENV2 peuvent donc être très différents de ceux que l'on peut observer lors des tests unitaires réalisés à l'aide de l'outil de test ENVI. On note que l'application logicielle APP peut connaître des variations d'utilisation reproductibles sur une fenêtre temporelle, communément appelée « cycle d'activité ». Dans ce cas, 20 une connaissance détaillée des informations de débits et de distributions des temps d'inter-arrivées des requêtes sur différentes périodes de temps identifiées sur le cycle d'activité pour chaque service offert par l'application logicielle peut être envisagée. Le découpage en périodes de temps est réalisé préférentiellement de sorte à garantir que sur une période de temps donnée, le débit moyen des requêtes soit représentatif des valeurs réelles de débits observées. Ce découpage est 25 alors pris en compte au niveau de l'outil de tests ENV2. A titre d'exemple, les figures 3A et 3B illustrent, pour deux services distincts d'une application logicielle, la répartition des nombres d'arrivées de requêtes sur un cycle d'activité de 24h. Sur la figure 3A, on peut distinguer 2 à 5 périodes de temps sur lesquelles les débits 30 moyens sont assez représentatifs par rapport aux valeurs réelles de débits observées (et très différents du débit moyen global sur le cycle d'activité de 24h). Par exemple un découpage en deux périodes de temps peut consister en une première période de 00h à 8h environ et une seconde période de 8h à 00h. Sur la figure 3B, un découpage en 4 périodes de temps peut être envisagé comme 35 consistant en une première période entre Oh et 5h30, une deuxième période entre 5h30 et 10h, une troisième période entre 10h et 12h30 et une quatrième période entre 12h30 et 24h. Les sondes de l'outil de test ENV2 sont configurées pour récolter diverses métriques, et notamment ici : 3037417 21 le temps de réponse de bout en bout des requêtes utilisateur en fonction de débits d'arrivée moyens et de la distribution des inter-arrivées de requêtes utilisateur de l'application logicielle APP ; et pour chaque serveur de la configuration CONFIG2, le taux d'utilisation du ou des processeurs 5 de ce serveur, ou le temps d'exécution de la requête par le serveur. En variante, d'autres métriques peuvent être récoltées dans cet environnement de test et notamment pour chaque serveur, la distribution du nombre de connecteurs réseau utilisés, la distribution du volume de RAM utilisé, le taux d'occupation de RAM et/ou de pool de « threads » d'entrée/sortie de chaque serveur, etc. 10 Comme mentionné précédemment, le module 4 du système de détermination 1 est configuré pour procéder à un ajustement des ressources et des paramètres des serveurs de la configuration initiale CONFIG2 en fonction de résultats de tests de tenue en charge réalisés à l'aide de l'outil de test ENV2. Cet ajustement qui est réalisé en s'appuyant ici sur plusieurs tests de tenue en charge judicieusement paramétrés en termes de charge injectée pour limiter la complexité 15 d'implémentation de ces tests, permet au module 4 de déterminer une configuration de serveurs « cible » (configuration CONFIG_TARG) pour le déploiement de l'application logicielle APP dans un environnement de production qui vérifie le temps de réponse maximal TRnnax fixé pour l'application logicielle et supporte la charge cible ktarg. Dans le mode de réalisation décrit ici, l'environnement de test ENV2 permet également 20 de réaliser des tests d'endurance ou de disponibilité sur la configuration de serveurs CONFIG_TARG après sa détermination par le module 4. Ces tests sont destinés à valider le dimensionnement et le paramétrage des ressources réalisés à partir des tests unitaires et des tests de tenue en charge, ces derniers étant supposés correspondre à un déploiement réel mais à échelle réduite. Il s'agit, grâce aux tests d'endurance, de tester l'application logicielle et la 25 configuration de serveurs cible CONFIG_TARG sur une durée suffisamment longue (typiquement plusieurs jours) afin de prendre en compte des événements rares ou dont la probabilité d'apparition est faible. Les scenarios de tests considérés pour ces tests d'endurance consistent à répartir les requêtes utilisateur suivant les différents types de services invoqués, et à émettre ces requêtes 30 selon une certaine charge estimée à partir des tests de tenue en charge pour la configuration cible CONFIG_TARG et selon des distributions d'inter-arrivées des requêtes prédéfinies : déterministe, aléatoire, en rafales, etc. Les métriques récoltées à l'issue de ces tests sont similaires à celles récoltées à l'issue des tests en tenue de charge (temps de réponse de bout en bout de l'application, taux d'utilisation de ressources (CPU, RAM, pool de threads, etc.) de chaque serveur, 35 etc.). Dans le mode de réalisation décrit ici, les outils de test ENVI. et ENV2 et les modules 2 à 4 du système de détermination 1 sont des modules logiciels définis à l'aide d'instructions de programmes d'ordinateur stockés en mémoire d'une ou de plusieurs machines physiques. Chacune 3037417 22 de ces machines a ici l'architecture matérielle d'un ordinateur et comprend notamment un processeur, une mémoire morte, une mémoire vive, une mémoire non volatile et un module de communication avec notamment d'autres machines ou ordinateurs. La mémoire morte de chaque machine constitue un support d'enregistrement conforme à l'invention, lisible par le processeur de 5 la machine et sur lequel est enregistré un programme d'ordinateur conforme à l'invention comportant des instructions pour l'exécution d'une ou de plusieurs étapes du procédé de dimensionnement selon l'invention. Nous allons maintenant décrire, en référence à la figure 4, les principales étapes d'un procédé de détermination selon l'invention, tel qu'il est mis en oeuvre dans un mode particulier de 10 réalisation par le système de détermination 1 illustré à la figure 1. On suppose en préliminaire de la mise en oeuvre de ce procédé qu'un certain nombre d'informations relatives à l'application logicielle APP et à son déploiement dans un environnement de production sont fournies au système de détermination 1, par exemple par l'administrateur ou le développeur de l'application logicielle. Ces informations sont stockées par exemple dans une 15 mémoire non volatile du système de détermination 1. Ainsi, notamment, est fourni au système de détermination 1 l'accord de niveau de service (SLA) défini pour l'application logicielle APP. Comme mentionné précédemment, ce SLA définit les exigences en termes de qualité des services utilisateurs UC1,...,UCN offerts par l'application logicielle APP, et en particulier, en termes de volumétrie (ex. charge cible ktarg), de 20 disponibilité et de temps de réponse maximal TRmax attendu de bout en bout. On suppose ici que les services UC1,...,UCN sont des services considérés comme représentatifs en matière de consommation de ressources, c'est-à-dire dont la consommation de ressources pour la fourniture de ces services par l'application logicielle APP est considérée comme significative par l'administrateur ou développeur de l'application logicielle. Les services UC1,..,UCN dépendent bien 25 entendu de l'application logicielle considérée. Le système de détermination 1 dispose également comme mentionné précédemment, des profils des requêtes utilisateurs représentatifs de l'utilisation réelle ou tout du moins attendue de l'application logicielle APP en environnement de production (ou s'en approchant le plus possible). Via ces profils, le système de détermination 1 connait pour chacun des services 30 UC1,...,UCN, un pourcentage (i.e. proportion) de requêtes utilisateurs invoquant ce service parmi les requêtes adressées à l'application logicielle APP. On note p_i, le pourcentage des requêtes utilisateurs destinées à l'application logicielle APP et associées au service UCi avec p_i = 1. Ces requêtes utilisateurs peuvent être de nature (type) différente selon le service qu'elles invoquent. Elles déclenchent des séquences d'exécution de l'application logicielle et 35 entrainent des consommations de ressources logicielles et matérielles. En associant chaque requête à un service, l'invention permet d'établir un modèle de consommation de ressources de 3037417 23 l'application logicielle en tenant compte des exigences utilisateur pour chacun de ces services. A titre illustratif, on peut avoir par exemple les types de requêtes suivants : pour le service UC1 : commandes/souscriptions ; pour le service UC2 : résiliations ; pour le service UC3 : consultations passant en commandes ; pour le service UC4 : traitements différés dans la nuit ; etc. Si on désigne par k le débit moyen des requêtes associées aux services principaux de l'application logicielle, le système de détermination 1 déduit de la connaissance de k et de la 10 répartition des requêtes par service, le débit moyen ?d des requêtes associées au service UCi, i= 1, N, en utilisant la relation : Xi = p_i x Les informations sur la répartition des requêtes sur les N services UC1,...,UCN, et sur les débits moyens Xi sont données par les profils des requêtes utilisateurs de l'application logicielle APP stockés au niveau du système de détermination 1. 15 Chaque profil de requêtes associé à un service comprend également, comme évoqué précédemment, une information représentative de la distribution des temps d'inter-arrivées des requêtes invoquant ce service. Une telle information précise notamment si les temps d'inter-arrivées des requêtes pour un service donné suivent une distribution déterministe ou au contraire de type rafales, telle que par exemple une distribution aléatoire ou exponentielle, en spécifiant les 20 paramètres d'une telle distribution pour qu'elle corresponde au délai moyen associé au service considéré (ex. durée « on » pendant laquelle l'application reçoit des requêtes et durée « off », etc.). Ces profils de requêtes sont utilisés dans les scénarios de test implémentés par les outils de tests ENVI. et ENV2. Le système de détermination 1 dispose également d'informations sur les contraintes de 25 déploiement imposées lors de la mise en production de l'application logicielle APP. Ces contraintes comprennent notamment le type d'architecture de déploiement envisagée (présentée par exemple sous forme d'un graphe de noeuds associés aux unités de déploiement de l'application APP). Elles peuvent porter également sur des caractéristiques des serveurs (ex. types de machines envisagées), par exemple sur la capacité et la possibilité d'extension de CPU ou de RAM d'un 30 serveur, sur l'utilisation de serveurs mono ou multiprocesseurs ou encore d'un cluster de serveurs, sur le type de configuration des unités de déploiements de l'application APP, etc. Ces informations peuvent être notamment fournies dans l'accord SLA. D'autres contraintes et/ou informations peuvent être fournies au système de détermination 1 comme par exemple des contraintes en matière de placement des serveurs, etc. 35 Toutefois par souci de simplification ici, nous ne considérerons pas de telles contraintes additionnelles. 3037417 24 Conformément à l'invention, le système de détermination 1 permet de dimensionner les ressources nécessaires à l'exécution de l'application logicielle APP sur une configuration de serveurs, en vue de son déploiement dans un environnement réel d'exécution, la configuration de serveurs dûment dimensionnée étant apte à vérifier le temps de réponse global maximal TRmax et 5 à supporter la charge cible Xtarg. A cet effet, le système de détermination 1 s'appuie sur des tests unitaires réalisés sur une configuration de serveurs « minimale » de référence (à savoir la configuration CONFIG1) pour obtenir une estimation de la consommation de ressources de l'application logicielle APP. Cette consommation de ressources est caractérisée ici : 10 d'une part, par les temps d'exécution moyens d'une requête de l'application logicielle sur chacun des serveurs S11, ...,S1N1 de la configuration CONFIG1 sur lesquels sont déployées les unités de déploiement de l'application logicielle APP. Ces temps d'exécution moyens sont désignés dans la suite de la description par E(S1j), j =1,...,N1 ; et d'autre part, par la charge maximale kmax1 pouvant être supportée par l'application logicielle 15 APP1 dans la configuration de serveurs CONFIG1 (autrement dit le débit maximum de l'application logicielle APP dans la configuration de serveurs CONFIG1). Le choix de la configuration CONFIG1 a déjà été détaillé précédemment. Le système de détermination 1 dispose donc, en préalable de l'exécution des tests unitaires, d'une description de la configuration de serveurs CONFIG1 et des caractéristiques des serveurs impliqués dans cette 20 configuration (étape E10). Comme mentionné précédemment, à titre illustratif, on choisit ici une configuration CONFIG1 minimale constituée d'un unique serveur mono-processeur désigné par S11 (N1=1). Toutefois cette hypothèse n'est en aucun cas limitative, la configuration de référence CONFIG1 pouvant comprendre plusieurs serveurs reliés entre eux. Conformément à l'invention, le système de détermination 1 via son outil de test ENVI 25 réalise des tests unitaires sur la configuration de serveurs CONFIG1 à partir de scénarios définis pour chaque type de requête identifié comme pertinent pour les services UC1,...,UCN offerts par l'application logicielle APP (étape E20). Comme mentionné précédemment, à l'issue de ces tests unitaires, le module 2 du système de détermination 1 récolte des métriques quantifiant la consommation de ressources par l'application logicielle sur le serveur S11 lors du traitement des 30 requêtes de l'App. Dans les scénarios de test mis en oeuvre, les requêtes sont envoyées à l'application logicielle de façon déterministe de sorte à ne pas avoir d'accès concurrents aux ressources (ex. CPU ici) dont on cherche à évaluer la consommation à l'aide des métriques récoltées. Dans l'exemple envisagé ici, les métriques obtenues par le module 2 durant les tests 35 unitaires correspondent pour chaque type de requête associé à un service UCi offert par l'application logicielle, à la consommation de CPU notée E(UC1,S11) par l'application logicielle sur le serveur S11 pour exécuter une requête de ce type. Chaque métrique E(UCi,S11) est plus précisément ici une mesure du temps d'exécution moyen d'une requête associée au service UCi sur 3037417 25 le serveur S11 (ou de façon équivalente, une mesure du taux d'utilisation moyen du CPU du serveur S11 pour traiter cette requête). Le module 2 évalue ensuite (étape E30), à partir des métriques E(UCi,S11), i=1,...,N, récoltées pour chaque type de requête (autrement dit pour chaque service), un temps d'exécution 5 moyen E(S11) d'une requête par l'application logicielle APP sur le serveur S11 (i.e. tous services confondus) suivant la relation : E(S11) = p_i x E(UCi, S11) Puis le module 2 évalue à partir du temps d'exécution moyen E(S11), le taux d'utilisation ju (S11) du serveur S11. Pour un serveur S11 monoprocesseur exécutant une unique instance de l'application APP, le module 2 utilise à cet effet la relation suivante : ii(S11) = E(S11) 10 On note que lorsque la configuration CONFIG1 comprend plusieurs serveurs distincts S1j, j=1,...,N1 avec N1>1 (autrement dit, l'application logicielle APP est composée de plusieurs unités de déploiement distribuées sur différents serveurs), un temps d'exécution moyen E(S1j) d'une requête par l'application logicielle APP est évalué par le module 2 pour chaque serveur S1j, j=1,...,N1 de la configuration CONFIG1 à partir des métriques récoltées lors des tests unitaires 15 menés dans l'environnement de test ENVI. De même, un taux d'utilisation (ou taux de service) moyen it(S1j) est dérivé pour chaque serveur S1j, j=1,...,N1 à partir de ce temps d'exécution moyen de façon similaire à celle décrite précédemment. A partir de ces taux d'utilisation du (ou des serveurs) de la configuration CONFIG1, le module 2 estime ici la charge maximale théorique kmax1 pour la configuration de référence 20 CONFIG1 (étape E40). A cet effet, l'invention s'appuie sur une condition dite de stabilité de l'application logicielle selon laquelle pour que l'application logicielle APP soit stable, il faut que le taux d'arrivée k des requêtes sur un serveur (qui définit ici la charge de l'application logicielle) soit strictement inférieur au taux d'utilisation de ce serveur. Autrement dit dans l'exemple du serveur unique S11 de la configuration CONFIG1 : 1 (1) 25 i(s11)ii) REVENDICATIONS1. Procédé de détermination d'une configuration de serveurs dite cible pour un déploiement d'une application logicielle (APP) apte à offrir au moins un service, le procédé comprenant : une étape d'obtention (E20), pour au moins un service offert par l'application logicielle, au moyen d'au moins un test unitaire réalisé sur une configuration de serveurs dite de référence (CONFIG1) apte à exécuter l'application logicielle (APP), d'un temps d'exécution moyen d'une requête invoquant ce service pour chaque serveur (S1j) de la configuration de référence ; une étape de sélection (E60) d'une configuration de serveurs dite initiale (CONFIG2) pour le déploiement de l'application logicielle apte à supporter une charge cible (Xtarg) déterminée pour l'application logicielle, cette étape de sélection tenant compte des temps d'exécution moyens obtenus lors dudit au moins un test unitaire, de la charge cible et d'une charge admissible déterminée (k) pour la configuration de référence, et utilisant un modèle numérique reflétant au moins une contrainte de déploiement de l'application logicielle imposée à la configuration de serveurs initiale ; et une étape de détermination (E90), à partir de la configuration initiale, d'une configuration de serveurs cible (CONFIG_TARG) destinée à être utilisée pour le déploiement de l'application logicielle, ladite étape de détermination comprenant la réalisation (E80) d'une pluralité de tests de tenue en charge paramétrés en fonction d'une charge maximale théorique (kmax2) estimée pour la configuration initiale et de la charge cible, et utilisant au moins un profil de requêtes invoquant ledit au moins un service offert par l'application logicielle, ce profil étant représentatif d'une utilisation de l'application logicielle lors de son déploiement, ladite étape de détermination comprenant en outre, en fonction du résultat de chaque test de tenue en charge, un ajustement (E80) d'au moins une ressource de la configuration initiale de sorte que la configuration cible obtenue à l'issue de ladite pluralité de tests de tenue en charge soit apte à vérifier un temps de réponse maximal fixé pour l'application logicielle et à supporter ladite charge cible. 2. Procédé selon la revendication 1 comprenant en outre une étape d'estimation (E40) d'une charge maximale théorique (krnax1) pour la configuration de référence et dans lequel la charge admissible (k) déterminée pour la configuration de référence résulte du produit d'un paramètre a compris entre 0 et 1 par la charge maximale théorique estimée pour la configuration de référence. 3. Procédé selon la revendication 2 dans lequel la charge maximale théorique (kmax1) pour la configuration de référence est estimée en appliquant une condition de stabilité de 3037417 45 l'application logicielle à au moins un temps d'exécution moyen d'une requête de l'application logicielle dérivé pour ledit au moins un serveur de la configuration de référence à partir des temps d'exécution moyens obtenus pour ce serveur pour les services offerts par l'application logicielle. 5 4. Procédé selon l'une quelconque des revendications 1 à 3 dans lequel au cours de l'étape de détermination, l'ajustement (E804,E809,E811,E815) d'au moins une ressource de la configuration initiale à l'issue d'un test de tenue en charge est réalisé en fonction d'une différence entre un temps de réponse de l'application logicielle évalué lors du test de tenue en charge et le temps de réponse maximal (TRmax) fixé pour l'application logicielle. 10 5. Procédé selon l'une quelconque des revendications 1 à 4 dans lequel l'étape de détermination comprend au moins : un premier test de tenue en charge (E802) réalisé avec une première charge inférieure à une valeur minimum entre une moitié de la charge maximale théorique estimée pour la 15 configuration initiale et le produit de la charge cible par un nombre réel prédéterminé inférieur ou égal à 1; un deuxième test de tenue en charge (E806) réalisé avec une deuxième charge inférieure à la première charge ; et un troisième test de tenue en charge (E813) réalisé avec une troisième charge égale à la 20 charge cible. 6. Procédé selon la revendication 5 dans lequel l'étape de détermination comprend en outre une estimation (E807) à l'issue du deuxième test, d'un temps de réponse de l'application logicielle avec la charge cible à partir d'un temps de réponse évalué à l'issue du premier test réalisé 25 avec la première charge sur une configuration testée dérivée de la configuration de serveur initiale et d'un temps de réponse de l'application logicielle évalué à l'issue du deuxième test réalisé avec la deuxième charge sur ladite configuration testée, l'ajustement de ressources étant réalisé à l'issue du deuxième test en fonction d'une différence entre le temps de réponse estimé pour la charge cible et le temps de réponse maximal fixé pour l'application logicielle. 30 7. Procédé selon la revendication 6 dans lequel, à l'issue du deuxième test : la configuration de serveurs testée est considérée comme sous-dimensionnée si le temps de réponse estimé pour la charge cible est supérieur au temps de réponse maximal ; et/ou la configuration de serveurs testée est considérée comme surdimensionnée si le temps de 35 réponse estimé pour la charge cible est inférieur au produit d'un nombre réel prédéterminé y compris entre 0 et 1 et du temps de réponse maximal ; et/ou la configuration de serveurs testée est considérée comme correctement dimensionnée sinon. 3037417 46 8. Procédé selon la revendication 7 dans lequel y est pris égal à 0.9. 9. Procédé selon l'une quelconque des revendications 5 à 8 dans lequel la configuration cible correspond à une configuration de serveurs testée pour laquelle à l'issue du 5 troisième test, un temps de réponse de l'application logicielle évalué pour la charge cible sur cette configuration de serveurs testée est inférieur au temps de réponse maximal. 10. Procédé selon l'une quelconque des revendications 1 à 9 comprenant en outre une étape de validation (E100) de la configuration cible au moyen d'un test d'endurance réalisé 10 pendant une durée d'exécution prédéterminée de l'application logicielle. 11. Procédé selon l'une quelconque des revendications 1 à 10 dans lequel le modèle numérique modélise ladite au moins une contrainte de déploiement de l'application logicielle à partir d'au moins une file d'attente ou d'un réseau de files d'attente. 15 12. Procédé selon l'une quelconque des revendications 1 à 11 dans lequel au moins un profil de requêtes comprend, pour au moins une période de temps déterminée d'un cycle d'activité de l'application logicielle : un débit moyen des requêtes invoquant ce service sur ladite période de temps ; 20 une proportion de requêtes invoquant ce service parmi les requêtes invoquant des services offerts par l'application logicielle ; et une distribution des durées d'inter-arrivées entre deux requêtes invoquant ce service sur ladite période de temps. 25 13. Procédé selon la revendication 1 à 12 dans lequel ladite application logicielle est caractérisée par un cycle d'activité comprenant une pluralité d'intervalles, chaque intervalle étant associé à un débit moyen d'arrivée des requêtes représentatif sur cet intervalle, et dans lequel lesdites étapes d'obtention, de sélection et de détermination sont mises en oeuvre pour au moins un intervalle de ladite pluralité d'intervalles. 30 14. Procédé de gestion d'élasticité d'une configuration de serveurs apte à exécuter une application logicielle, ce procédé comprenant : une étape de détermination (F10) d'une configuration cible de serveurs pour le déploiement de l'application logicielle comprenant l'exécution d'un procédé de détermination selon l'une 35 quelconque des revendications 1 à 13 ; et une étape d'exécution (F20) de l'application logicielle sur ladite configuration cible de serveurs comprenant : 3037417 47 o une surveillance (F30) d'au moins une métrique de supervision de cette configuration cible ; et o en fonction de ladite au moins une métrique, un ajustement (F40) des ressources de la configuration cible, cet ajustement comprenant un maintien et/ou un ajout et/ou un 5 retrait dynamique de ressources à la configuration cible. 15. Système de détermination (1) d'une configuration cible pour un déploiement d'une application logicielle, le système comprenant : un premier outil de test (ENVI.) permettant l'exécution d'au moins un test unitaire sur 10 l'application logicielle lorsque celle-ci est exécutée sur une configuration de serveurs dite de référence ; un module d'obtention (2), configuré pour commander l'exécution d'au moins un test unitaire par le premier outil de test sur ladite configuration de référence et pour obtenir, pour au moins un service offert par l'application logicielle, un temps d'exécution moyen d'une requête 15 invoquant ce service pour chaque serveur (S1j) de la configuration de référence ; un module de sélection (3), configuré pour sélectionner une configuration de serveurs initiale (CONFIG2) pour le déploiement de l'application logicielle apte à supporter une charge cible déterminée pour l'application logicielle, ledit module de sélection étant configuré pour tenir compte des temps d'exécution moyens obtenus lors dudit au moins un test unitaire, de la 20 charge cible et d'une charge admissible déterminée pour la configuration de référence, et pour utiliser un modèle numérique reflétant au moins une contrainte de déploiement de l'application logicielle imposée à la configuration de serveurs initiale ; un second outil de test (ENV2) permettant l'exécution de tests de tenue en charge sur ladite application logicielle lorsque celle-ci est exécutée sur la configuration de serveurs initiale 25 sélectionnée par le module de sélection ; et un module de détermination (4) configuré pour déterminer à partir de la configuration initiale une configuration de serveurs cible destinée à être utilisée pour le déploiement de l'application logicielle, ledit module de détermination étant configuré pour commander l'exécution d'une pluralité de tests de tenue en charge par le second outil de test, lesdits tests de tenue en 30 charge étant paramétrés par le module de détermination en fonction d'une charge maximale théorique estimée pour la configuration initiale et de la charge cible, et utilisant au moins un profil de requêtes invoquant ledit au moins un service offert par l'application logicielle, ce profil étant représentatif d'une utilisation de l'application logicielle lors de son déploiement, ledit module de détermination étant en outre configuré pour ajuster, en fonction du résultat de 35 chaque test de tenue en charge, au moins une ressource de la configuration initiale de sorte que la configuration cible obtenue à l'issue de ladite pluralité de tests de tenue en charge soit 3037417 48 apte à vérifier un temps de réponse maximal fixé pour l'application logicielle et à supporter ladite charge cible.