CA2907529A1

CA2907529A1 - Optimisation de modules informatiques pour le deploiement d'un service informatique

Info

Publication number: CA2907529A1
Application number: CA2907529A
Authority: CA
Inventors: Eric Gourmelen; Jean-Charles RAGONS
Original assignee: ARROW ECS
Current assignee: ARROW ECS
Priority date: 2013-03-25
Filing date: 2014-03-03
Publication date: 2014-10-02
Also published as: WO2014154965A1; FR3003667A1; AU2014242885A1; US20160004520A1; EP2946289A1

Abstract

L'invention concerne une sélection automatisée de modules informatiques optimums pour un déploiement d'un service informatique. On prévoit à cet effet les étapes: obtenir des données relatives à une pluralité de modules informatiques, et, en fonction desdites données de modules, classer les modules au moins par catégories, obtenir des données relatives au service informatique, et, en fonction desdites données de service, définir un ou plusieurs types de service constituant ledit service informatique, et établir une correspondance entre lesdits types de service et une partie au moins desdites catégories de modules, pour générer une liste de modules aptes à être utilisés pour mettre en uvre chaque type de service. On peut ainsi sélectionner des modules dans cette liste en vue de déployer le service.

Description

Optimisation de modules informatiques pour le déploiement d'un service informatique L'invention concerne l'évaluation de modules informatiques optimums pour le déploiement d'un service informatique constitué de ces modules informatiques.
Elle trouve une application avantageuse mais non limitative à la mise en oeuvre d'un service d'hébergement de ressources informatiques sur un serveur distant, notamment pour une société utilisant ces ressources, par exemple dans le cadre d'une informatique dématérialisée, ou informatique en nuage (pour cloud computing en anglais).
En particulier, l'invention vise à simuler, construire et déployer un service informatique à partir de modules informatiques (software et/ou hardware), et, dans une réalisation optionnelle mais avantageuse, à gérer la facturation liée à l'utilisation et la revente de ce service.
Ainsi, l'invention peut être utilisée par des fournisseurs de services informatiques ou des revendeurs de modules informatiques pour délivrer tous types de services comme par exemple des serveurs virtuels, des services de courrier électronique, des services de base de données, des services d'applications bureautiques, des services de sécurité (anti-virus, firewall, etc.) ou toute combinaison (par exemple serveur de courrier électronique virtuel sécurisé).
On connait des réalisations habituelles dans lesquelles une société
fournisseur de services informatiques cherche simplement sur le marché un ensemble de modules informatiques tels que des produits logiciels, puis les acheter et tester leur fonctionnement. L'industrialisation du service, est totalement manuelle, chaque composant logiciel est acheté de manière anticipée par rapport à l'utilisation exactement prévue.
La fourniture de services informatiques nécessite de mobiliser de nombreux techniciens spécialistes pour la sélection des produits et leurs tests ainsi que leur intégration. Une fois déployées, les licences logicielles associées à ces produits représentent un lourd investissement alors même que le service n'est pas encore délivré.

2 La présente invention vient améliorer la situation.
Elle vise à cet effet un procédé mis en oeuvre par des moyens informatiques, de sélection de modules informatiques optimums pour un déploiement d'un service informatique, le procédé comportant les étapes :
- obtenir des données relatives à une pluralité de modules informatiques, et, en fonction de ces données de modules, classer les modules au moins par catégories, - obtenir des données relatives au service informatique, et, en fonction de ces données de service, définir un ou plusieurs types de service constituant le service informatique précité, - établir une correspondance entre les types de service, d'une part, et une partie au moins des catégories de modules, d'autre part, pour générer une liste de modules aptes à être utilisés pour mettre en oeuvre chaque type de service.
Un utilisateur des moyens informatiques mettant en oeuvre le procédé, tel que par exemple un fournisseur de service informatique, peut alors effectuer une sélection de modules dans cette liste en vue du déploiement du service informatique précité.
L'invention permet de sélectionner, voire déployer, en un temps très court des services informatiques pour un besoin déterminé. Il s'avère qu'en quelques minutes ce service peut être sélectionné alors que dans l'état de l'art, quelques semaines étaient nécessaires. En outre, il n'est pas nécessaire de mobiliser des moyens humains pour rassembler tous les modules nécessaires à la mise en place de chaque type de service constitutif du service à déployer. On comprendra alors que le gain économique est conséquent.
Ainsi, on comprendra que la mise en oeuvre de la présente invention permet d'assurer automatiquement et sans intervention excessive d'un utilisateur, une compatibilité
technique entre des modules informatiques (hardware et/ou software), sélectionnés grâce à la mise en oeuvre de l'invention, et une destination informatique (environnement OS, capacités mémoire et de processeur, etc.), grâce notamment aux classes créées dans les différentes catégories de modules.

3 Dans un mode de réalisation avantageux, le procédé comporte en outre :
- une étape de vérification de compatibilité informatique de modules informatiques de la liste établie, avec une destination dans le service informatique à déployer, et - une étape de réduction de la liste en fonction d'une incompatibilité
d'une partie au moins des modules de la liste, qui sont alors retirés de la liste.
Cette vérification de compatibilité, dans un exemple de réalisation, met en oeuvre l'établissement d'une matrice de compatibilité, répertoriant tous les modules apte à être utilisés pour le déploiement d'un type de service donné.
Avantageusement, ces étapes de vérification et de réduction de liste sont mises en oeuvre automatiquement par les moyens informatiques à disposition du fournisseur de service. A cet effet, ces moyens informatiques sont judicieusement programmés pour vérifier dans les données de modules les compatibilités ou incompatibilités de chaque module avec le contexte de déploiement du service (par exemple la capacité
mémoire ou de processeur nécessaire à l'exécution d'un module logiciel, la version de système d'exploitation nécessaire, ou encore les limitations d'utilisation, en termes de nombre d'utilisateurs du module par exemple, etc.).
Par exemple, les données relatives à un module informatique peuvent comporter à cet effet des données :
o de prérequis sur des ressources informatiques nécessaires pour un déploiement du module, et o de limitations d'utilisation du module.
Dans une réalisation, le procédé comporte en outre une étape de détermination, en fonction de la liste précitée, d'une pluralité de jeux de modules, chaque jeu comportant un ensemble de modules nécessaires et suffisants pour la mise en oeuvre d'un type de service. Ainsi, le fournisseur du service peut avantageusement effectuer un choix parmi plusieurs solutions possibles d'ensembles de modules permettant le déploiement d'un type de service.

4 Avantageusement, pour aider le choix du fournisseur de service, le procédé
peut comporter une hiérarchisation de la pluralité précitée de jeux de modules en fonction d'un critère choisi, comme par exemple un critère de coût. Ainsi, les fonctions intégrées de gestion des achats dans un programme informatique au sens de l'invention, permettent, dans une telle réalisation, une gestion optimisée des modules à
choisir, notamment en termes de coûts de production.
D'une manière générale, les données relatives à un module informatique peuvent comporter, dans un mode de réalisation, au moins des données de:
o catégorie informatique du module, o description du module, o identifiant de référence du module et de nom de fournisseur du module, o unité d'utilisation du module, et de prix par unité du module.
Dans un mode de réalisation, les données relatives au service informatique peuvent comporter, quant à elles, pour chaque type de service :
- des données de description du type de service, et - un jeu de paramètres nécessaires et suffisants pour configurer le type de service.
Une fonctionnalité avantageuse pouvant être mise en oeuvre dans une réalisation particulière concerne le déploiement automatisé du service-même. Ainsi, dans une telle réalisation, le procédé comporte une étape de déploiement du service informatique et les données relatives à un module informatique peuvent comporter à cet effet des données :
- d'accès au module pour le déploiement du module (par exemple via une adresse web ou une URL, ou autre), et - de configuration du module, comprenant par exemple un jeu de paramètres et/ou de fichiers de configuration associés au module à déployer.
Une autre fonctionnalité avantageuse concerne les retours d'utilisation des modules logiciels une fois déployés. Ainsi, dans une réalisation, une étape du procédé, ultérieure au déploiement du service, comprend l'établissement d'un rapport de consommation indiquant un nombre d'unités consommées de chaque module informatique par un

5 PCT/FR2014/050463 client donné, et un prix du module informatique fourni à ce client, par unité
consommée, ce qui permet d'obtenir des informations de retour particulièrement avantageuses pour les éditeurs de modules logiciels ou les fournisseurs de matériels hardware.
La présente invention vise aussi un programme informatique comportant des instructions pour la mise en oeuvre du procédé ci-avant, lorsque ce programme est exécuté par un processeur. A titre d'exemple, on a représenté sur les figures 1 et 2, commentées plus loin, des organigrammes possibles d'algorithmes généraux d'un tel programme informatique.
Ce programme peut être exécuté par des moyens informatiques que comporte un dispositif au sens de l'invention, par exemple un ordinateur comprenant typiquement des moyens tels qu'un processeur, une mémoire de travail, une interface de communication, etc., pour la mise en oeuvre du procédé. Un tel dispositif peut comporter en particulier un support mémoire (amovible ou permanent) stockant les instructions du programme informatique pour la mise en oeuvre de l'invention.
A ce titre, la présente invention vise aussi un tel dispositif comportant des moyens informatiques, de sélection de modules informatiques optimums pour un déploiement d'un service informatique, lesdits moyens informatiques étant agencés pour:
- à partir de données relatives à une pluralité de modules informatiques, classer les modules au moins par catégories, - à partir de données relatives au service informatique, définir un ou plusieurs types de service constituant ledit service informatique, - établir une correspondance entre lesdits types de service et une partie au moins desdites catégories de modules, pour générer une liste de modules aptes à être utilisés pour mettre en oeuvre chaque type de service.
Un exemple de ce dispositif est représenté schématiquement sur la figure 3 sous la forme d'un ordinateur DIS.

6 D'autres avantages et caractéristiques de l'invention apparaîtront à la lecture de la description détaillée ci-après d'exemples possibles de réalisation, non limitatifs, et à
l'examen des dessins annexés sur lesquels :
- La figure 1 illustre les principales étapes d'un procédé selon un mode de réalisation particulier de l'invention, - La figure 2 illustre en détails un exemple de réalisation de quelques étapes du procédé de la figure 1, - La figure 3 illustre un dispositif au sens de l'invention mettant en oeuvre le procédé précité, - La figure 4 illustre un exemple de réalisation d'une étape supplémentaire d'obtention d'un rapport de consommation de modules informatiques fournis pour un service donné.
En référence à la figure 1, le procédé illustré commence par une première étape S11 consistant à dresser l'inventaire de l'ensemble des modules informatiques, appelés ci-après modules logiciels MI4, disponibles chez les fournisseurs Fk de solutions logicielles (ou tout au moins un sous-ensemble pour lequel une entité mettant en oeuvre le procédé a des droits de distribution).
Chaque module logiciel ML1 est caractérisé par deux jeux de paramètres.
Un premier jeu de paramètres concerne des paramètres descriptifs relatifs à :
o La catégorie informatique du module logiciel comme, par exemple, un module logiciel de communication, un module logiciel de sauvegarde, ou un module logiciel de sécurité, o La description du module logiciel permettant de comprendre ses fonctionnalités plus détaillées, o Un identifiant de référence du produit, unique, et un nom de fournisseur du module Fk, O Une unité d'utilisation du module logiciel, telle que par exemple une utilisation par personne utilisatrice, une utilisation par processeur de machine (ordinateur, serveur, ou autre), une utilisation par gigaoctet de mémoire mis à disposition pour le service, ou autre,

7 o Un prix par unité du module.
Un deuxième jeu de paramètres concerne des paramètres relatifs aux caractéristiques techniques d'utilisation, telles que:
o Un prérequis sur le nombre de processeurs, ou le nombre de gigahertz de processeur, ou le nombre de gigaoctet de mémoire, ou la capacité de stockage minimum pour l'installation et l'exécution du module, ainsi que sur le système d'exploitation supporté, o Aux limitations d'utilisation telles que l'incompatibilité avec d'autres modules logiciels, ou sur le nombre maximum d'unités du module (les utilisateurs, processeurs, etc.), o A l'accès au module : par exemple via un lien pour téléchargement, ou via un lien d'accès direct en cas de module déjà hébergé, o A la configuration du module pour déterminer par exemple si un jeu de paramètres et/ou de fichiers de configuration sont associés au module à
installer.
Un deuxième inventaire répertorie à l'étape S12 la liste des types de service mettant en oeuvre un ou plusieurs modules logiciels. Un type de service TS, peut être caractérisé
par:
- Une description du type de service (par exemple un service de sauvegarde et/ou un service de courrier électronique), et - Un jeu de paramètres nécessaires et suffisants pour configurer le type de service (par exemple un nom de domaine dans le cas d'un service de courrier électronique).
Dans un mode de réalisation, on peut segmenter les différents types de services TS, en plusieurs catégories de modules TS,Ci qui pourraient satisfaire chaque type de service (pour un type de service TS, et pour une catégorie associée Ci). Ces catégories TS,Ci sont nécessaires et suffisantes pour créer le service (par exemple un module logiciel de serveur virtuel, un module de serveur de courrier électronique, un module antivirus et anti-SPAM pour un service de courrier électronique).

8 A l'étape S13, on génère ensuite une liste définissant les modules les plus adaptés au type de service requis.
A cet effet, on applique une fonction de génération de catalogue de service, prenant, en entrée, la liste des catégories des modules logiciels d'une part, et la liste des types de services, d'autre part. Cette fonction calcule une matrice de compatibilité de la manière représentée sur la figure 2, dans un exemple de réalisation possible.
Sur la figure 2, on identifie des boucles de traitement imbriquées telles que :
pour chaque type de service T51 (boucle comprenant le test T21, l'incrémentation S22 du compteur i de cette boucle et l'initialisation S23 du compteur de boucle j suivant), pour chaque catégorie du type de service TSICJ (boucle comprenant le test T24, l'incrémentation S25 du compteur j de cette boucle et l'initialisation S26 du compteur de boucle k suivant), pour chaque fournisseur de modules logiciels Fk (boucle comprenant le test T27, l'incrémentation S28 du compteur k de cette boucle et l'initialisation S29 du compteur de boucle 1 suivant), et pour chaque module logiciel FkM14 (boucle comprenant le test T30 et l'incrémentation S31 du compteurl de cette boucle), si la catégorie du module logiciel FkM14 correspond à la catégorie du type de service requis TSICJ (test T32), on ajoute ce module logiciel FkM14 à la liste MC TSià l'étape S33.
Bien entendu, on prévoit une première étape d'initialisation S20 des compteurs de boucle. Par ailleurs, lorsque tous les types de service T51, dans le service général requis, ont été épuisés (sortie OK du test T21), alors le procédé peut s'arrêter à
l'étape S34 et la liste des modules FkM14 possibles pour l'établissement du service requis est finalement obtenue à l'étape S33.
La liste générée MC T51 peut initialement comporter plusieurs modules pour une même catégorie de service, mais elle est affinée alors, tout d'abord, en fonction de critères tels que les prérequis et les limitations, par exclusion des modules ne respectant pas ces critères.

9 Pour chaque ensemble (prérequis, limitations) défini selon les données S14 de la figure 1, on crée une liste affinée S15 en sélectionnant les modules logiciels compatibles avec l'application visée, par Catégorie Catégorie(FkM14) . Cette liste affinée correspond ainsi à une matrice de compatibilité des modules, expliquée plus loin en référence à la figure 3. Cette liste affinée peut être ordonnée ensuite selon un critère supplémentaire prédéterminé à l'étape S16, pour présenter un choix de modules logiciels hiérarchisé selon ce critère, à l'étape S17 de la figure 1. Cette hiérarchisation permet à l'utilisateur d'effectuer un choix final d'un jeu de modules nécessaires et suffisants pour réaliser chaque type de service, comme détaillé plus loin en référence à
la figure 3.
Ce critère supplémentaire défini à l'étape S16 peut être par exemple le coût total des modules pour l'ensemble des catégories pour offrir un type de service particulier, ou peut, en variante, être fonction de la performance par exemple de ces modules, ou encore de leur compatibilité entre eux.
Le fournisseur de service peut ensuite effectuer son choix par exemple sur cette base du coût total. Le procédé peut optionnellement se poursuivre ensuite par un renseignement des conditions d'accès et des configurations des modules logiciels à l'étape S18, pour définir des conditions de leur installation à l'étape S19.
En effet, après l'exécution du choix de service à partir de la liste hiérarchisée à l'étape S17, le fournisseur de service renseigne ensuite les paramètres de configuration à
l'étape S18 en vue d'une application d'une deuxième fonction, de déploiement de service, mise en oeuvre à l'étape S19. Cette deuxième fonction prend en entrée un type de service et le choix final de l'utilisateur d'un jeu de modules nécessaires et suffisants sélectionné par l'utilisateur fournisseur de service, pour déployer ce type de service. Par exemple, pour chaque module logiciel de la liste M14, la méthode d'accès MAI
est utilisée pour déployer chaque module et les informations de configuration de ce module sont ensuite appliquées à l'aide des paramètres du service renseignés par le fournisseur.
Le service peut ensuite être testé et fourni à des clients finaux.

La figure 3 présente le procédé jusqu'au choix du fournisseur de service d'un jeu approprié de modules, mis en oeuvre par des moyens informatiques à disposition du fournisseur de service.
Un utilisateur UL, fournisseur de services informatiques à des tiers et client lui-même de fournisseurs de modules logiciels, dispose de moyens informatique tels qu'un ordinateur DIS comportant typiquement un processeur, une mémoire de travail et des moyens de communication COM pour recevoir :
- d'une part, des données d'information des fournisseurs de modules logiciels, et - d'autre part, des données de ses clients caractérisant leurs besoins, pour définir un service global à fournir et, de là, des types de service correspondants.
Un programme informatique au sens de l'invention qu'exécute le dispositif DIS
pour la mise en oeuvre du procédé au sens de l'invention, génère, à partir des données sur les modules logiciels, une fiche de description FkML1 propre à chaque module incluant, comme indiqué précédemment à titre d'exemple, une organisation de données relatives à la catégorie du module, une description abrégée, sa référence et son éditeur, son unité
d'utilisation, son prix, ses prérequis pour l'installation, ses limitations, la méthode de son accès, et sa configuration. Cette fiche de description peut compter typiquement des balises (comme par exemple la description sommaire du module logiciel, ou son identifiant, etc.) pour une interprétation de ces fiches en langage objet (par exemple en langage de type java, ou autre), avec ainsi une possibilité de définir des classes de catégories, de descriptions, etc.
Par ailleurs, le programme informatique installé sur le dispositif DIS de l'utilisateur UL
génère, à partir des données sur les services requis par son client, une fiche de description T51 incluant, comme indiqué précédemment à titre d'exemple, une organisation de données relatives à une description du type de service, des paramètres propres à ce type de service. Cette fiche de description TS1, TSx, comporte en outre des catégories de modules logiciels ML Catégorie 1, 2, ..., susceptibles de convenir pour satisfaire le type de service requis (correspondant au paramètre TSICJ
présenté ci-avant).

Dans un exemple de réalisation, le procédé comprend ensuite, pour la génération des matrices de compatibilité 1, x, le détail des étapes illustrées sur la figure 2. Dans une réalisation, chaque matrice peut être affinée et ordonnée ensuite selon un critère choisi (de coût, de performance technique, de compatibilité d'un module avec un module d'un autre type de service, etc.). Ainsi, chaque matrice de compatibilité est transformée en plusieurs fiches descriptives, présentant chacune un jeu particulier de modules ML aptes à satisfaire ensemble un type de service défini dans la matrice de compatibilité. Cette fiche comporte le jeu de modules nécessaires et suffisants pour offrir ce type de service, le coût total de l'ensemble de ces modules, les prérequis d'installation, et les limitations d'utilisation.
Dans une réalisation, on peut prévoir une hiérarchisation de ces fiches de jeux de modules, en fonction d'un critère choisi, comme par exemple un critère de coût, et l'utilisateur peut ainsi choisir naturellement le premier jeu de modules qui apparait dans cette hiérarchisation, ou faire un autre choix, par exemple en fonction d'un délai de livraison, d'une fiabilité du fournisseur, ou autres.
Ainsi, en référence à la figure 3, l'utilisateur UL effectue un choix final F11, , Flx, pour chaque type de service, en retenant une liste particulière de modules de son choix pour chaque type de service, dans un mode de réalisation particulier de l'invention.
On peut prévoir en outre une autre fonctionnalité, de relevé de consommation, qui s'exécute périodiquement, par exemple tous les mois. Cette autre fonctionnalité prend en entrée des informations instantanées, liées aux utilisations du service, comme par exemple le nombre d'utilisateurs des modules logiciels, la mémoire consommée par exemple dans le cadre d'un hébergement de mémoire sur un serveur distant dans le cadre d'un service sur le cloud, ou encore le nombre de courriels émis/reçus, etc. En référence à la figure 4, une fois le service déployé auprès d'un ou plusieurs clients CL, pour chaque service déployé FI1 et pour chaque fournisseur Fk du module logiciel ML1 utilisé dans le service déployé, le procédé peut se poursuivre par une étape de création d'un rapport de consommation RCki comprenant par exemple des données sur:
- la référence du client CL, - le nombre d'unités consommées (en giga-octets utilisés effectivement, en nombre d'utilisations du module, etc.), - le prix de la ressource informatique fournie à ce client, par unité
consommée, ce qui permet à l'éditeur du module logiciel ou au fournisseur de hardware d'obtenir de précieuses informations sur l'utilisation du matériel vendu.
Bien entendu, la présente invention ne se limite pas aux formes de réalisation décrites ci-avant à titre d'exemples ; elle s'étend à d'autres variantes.
Ainsi, par exemple, le contenu des fiches décrivant chaque module logiciel est présenté
ici à titre d'exemple et est susceptible de variantes. Par exemple, les champs relatifs à la catégorie et à la description du module peuvent être regroupés dans un même champ.
De même, le contenu de la fiche informatique décrivant un type de service est susceptible de variantes.
De même, les étapes détaillées du procédé selon la figure 2, ou une partie au moins des étapes de la figure 1 sont présentées ici à titre d'exemples et sont susceptibles de variantes selon une conception informatique choisie.
Par ailleurs, en fonction de retours sur expérience d'un jeu complet de modules, sélectionné par un utilisateur, certaines fiches de jeu de modules peuvent évoluer dans le temps (par exemple être supprimées en cas d'incompatibilité expérimentée entre plusieurs modules d'un même jeu, ou au contraire certaines fiches peuvent être créées en fonction de nouveau produits logiciels sur le marché).

Claims

REVENDICATIONS

1. Procédé mis en uvre par des moyens informatiques, de sélection de modules informatiques optimums pour un déploiement d'un service informatique, le procédé
comportant les étapes :
- obtenir des données relatives à une pluralité de modules informatiques, et, en fonction desdites données de modules, classer les modules au moins par catégories, - obtenir des données relatives au service informatique, et, en fonction desdites données de service, définir un ou plusieurs types de service constituant ledit service informatique, - établir une correspondance entre lesdits types de service et une partie au moins desdites catégories de modules, pour générer une liste de modules aptes à être utilisés pour mettre en uvre chaque type de service, ce qui permet une sélection de modules dans ladite liste en vue du déploiement du service.

2. Procédé selon la revendication 1, comportant en outre une étape de vérification de compatibilité informatique de modules informatiques de ladite liste avec une destination dans ledit service informatique, et une étape de réduction de ladite liste en fonction d'une incompatibilité d'une partie au moins des modules de la liste.

3. Procédé selon l'une des revendications 1 et 2, comportant en outre une étape de détermination, en fonction de ladite liste, d'une pluralité de jeux de modules, chaque jeu comportant un ensemble de modules nécessaires et suffisants pour la mise en uvre d'un type de service.

4. Procédé selon la revendication 3, comportant une hiérarchisation de la pluralité de jeux de modules en fonction d'un critère choisi.

5. Procédé selon la revendication 4, dans lequel ledit critère choisi est un critère de coût.

6. Procédé selon l'une des revendications précédentes, comportant une étape ultérieure au déploiement du service comprenant l'établissement d'un rapport de consommation indiquant un nombre d'unités consommées de chaque module informatique par un client donné, et un prix du module informatique fourni à ce client, par unité
consommée.

7. Procédé selon l'une des revendications précédentes, dans lequel les données relatives à un module informatique comportent au moins des données de :
.circle. catégorie informatique du module, .circle. description du module, .circle. identifiant de référence du module et de nom de fournisseur du module, .circle. unité d'utilisation du module, et de prix par unité du module.

8. Procédé selon la revendication 2, dans lequel les données relatives à un module informatique comportent en outre des données de :
.circle. prérequis sur des ressources informatiques nécessaires pour un déploiement du module, et .circle. limitations d'utilisation du module.

9. Procédé selon l'une des revendications précédentes, comprenant une étape de déploiement du service informatique et dans lequel les données relatives à un module informatique comportent en outre des données :
- d'accès au module pour le déploiement dudit module, et - de configuration du module comprenant notamment un jeu de paramètres et/ou de fichiers de configuration associés au module à déployer.

10. Procédé selon l'une des revendications précédentes, dans lequel les données relatives au service informatique comportent, pour chaque type de service :
- des données de description du type de service, et - un jeu de paramètres nécessaires et suffisants pour configurer le type de service.

11. Programme informatique comportant des instructions pour la mise en uvre du procédé selon l'une des revendications 1 à 10, lorsque ce programme est exécuté par un processeur.

12. Dispositif comportant des moyens informatiques, de sélection de modules informatiques optimums pour un déploiement d'un service informatique, lesdits moyens informatiques étant agencés pour:
- à partir de données relatives à une pluralité de modules informatiques, classer les modules au moins par catégories, - à partir de données relatives au service informatique, définir un ou plusieurs types de service constituant ledit service informatique, - établir une correspondance entre lesdits types de service et une partie au moins desdites catégories de modules, pour générer une liste de modules aptes à être utilisés pour mettre en uvre chaque type de service.