Brevet FR3002348A1 — publié le 20140822

CONSTRUCTION VIA UN SERVEUR INFORMATIQUE D'UNE APPLICATION LOGICIELLE Domaine technique : La présente invention a trait au domaine de la construction d'applications logicielles via un serveur informatique. La présente invention vise plus précisément à permettre via un serveur informatique la construction d'applications logicielles personnalisées par des utilisateurs n'ayant aucune compétence dans le domaine de la programmation 10 informatique. La présente invention trouve ainsi de nombreuses applications avantageuses en offrant la possibilité à de tels utilisateurs de construire eux-mêmes leurs applications sans avoir recours à des programmeurs informatiques (ou développeurs). Etat de la technique : 15 Il existe aujourd'hui principalement trois approches pour la construction d'une application logicielle. Une première approche vise à développer manuellement son application (c'est- à-dire en rédigeant directement le code source avec un langage informatique approprié). 20 Selon cette approche, une fois le code source rédigé, il est ensuite nécessaire d'installer, de déployer et d'exécuter son application sur l'infrastructure informatique existante. Cette approche garantit une maitrise complète du code source et des fonctionnalités qui y sont développées. 25 Il existe cependant un fort risque de non-qualité immédiate lors de la première livraison de l'application ; il est bien souvent nécessaire de prévoir une phase de tests et de débogage pour remédier aux déficiences de l'application ainsi développée. Alternativement, une deuxième approche vise à développer son application avec l'assistance d'outils informatiques qui facilitent le codage. 30 Une telle approche consiste par exemple à utiliser un outil informatique du type « Environnement de Développement Intégré » (EDI) (également connu en anglais sous l'expression « Integrated Development Environment ») ou du type « Atelier de Génie Logiciel » (AGL) (également connu en anglais sous l'expression « Computer Aided Software Engineering »). En règle générale, les EDI ou AGL regroupent un ensemble d'outils informatiques pour le développement de logiciels comprenant un éditeur de texte, un compilateur, des outils automatiques de fabrication et de génération de codes, et éventuellement un débogueur. Le code source obtenu selon cette deuxième approche propose une syntaxe informatique fiable qui convient pour des fonctionnalités « standard ». Cependant, ce code est bien souvent sujet à de nombreuses erreurs lorsque les fonctionnalités de l'application attendue deviennent plus complexes. En effet, la génération automatique du code source présente très vite ses limites, et le code obtenu n'est généralement pas optimisé pour la fonctionnalité souhaitée. Les deux approches décrites ci-dessus permettent ainsi de construire toutes sortes d'applications logicielles ; néanmoins, elles nécessitent (toutes les deux à des degrés différents) un certain niveau de connaissance en informatique dans la mesure où elles nécessitent l'exécution et le déploiement de l'application. Ces deux approches sont donc réservées à des personnes ayant des 20 compétences en informatique. Or, ces personnes n'ont généralement pas la connaissance « métier ». De ce fait, le développement d'une application logicielle nécessite la constitution d'un binôme avec l'utilisateur ayant la connaissance « métier » et le développeur informatique. 25 Cette différence de compétence au sein du binôme est souvent à l'origine d'une forte disparité entre la solution désirée initialement par l'utilisateur et celle livrée par le développeur. Pour palier à ces inconvénients, les besoins sont généralement formalisés sous la forme d'un document, intitulé « analyse fonctionnelle ». Un tel document décrivant 30 le contenu fonctionnel attendu par l'utilisateur est généralement long et complexe à rédiger ; l'utilisateur n'a souvent pas de temps à consacrer à ce genre de tâche. De surcroît, il est nécessaire de requérir auprès de l'utilisateur une forte disponibilité pendant la période de développement, ceci afin de contrôler et tester régulièrement que le travail en cours et les fonctionnalités développées conviennent. Ceci est généralement très chronophage et n'est bien souvent pas très rentable, tant pour l'utilisateur que pour le développeur. Une troisième approche remédie au moins partiellement aux inconvénients ci-dessus et vise à utiliser un outil informatique de type « Système de Gestion de Contenu » (SGC) (également connu en anglais sous l'expression « Content Management System »). Ce type d'outil informatique propose une approche « macro » et permet d'assembler des modules complets qui sont « pré-codés » pour la conception et la mise à jour dynamique de sites Web ou d'applications multimédia. De tels outils sont des portails qui permettent d'activer et d'utiliser des modules fonctionnels complets, dédiés à un type d'activité, développés eux-mêmes par des 15 programmeurs. Cette troisième approche est intéressante avec l'arrivée du « Web 2.0 ». Ce type de solution permet donc à des utilisateurs « non-techniques » de déterminer eux même les grandes fonctionnalités qu'ils souhaitent « activer ». Il existe néanmoins plusieurs inconvénients majeurs à cette troisième 20 approche : - les fonctions développées sont essentiellement faites pour gérer du « contenu » multimédia (des articles, des discussions, des images, des documents, des données « simples »,...). Ils ne sont pas réellement structurés pour construire des fonctionnalités complexes de traitement et d'échange d'information 25 (« applications de gestion » ou « systèmes d'informations ») ; - les différents modules fonctionnels qui peuvent être activés sont relativement autonomes et sont étanches entre eux : ils ne communiquent pas entre eux ; et - l'utilisateur ne peut pas « construire » de nouvelles fonctionnalités, il ne peut qu'utiliser celles qui ont été conçues par les développeurs. Il ne peut donc pas 30 interagir pour construire une application complexe et optimisée. Cette troisième approche « macro », bien qu'intéressante, n'est pas suffisamment modulaire pour permettre la conception d'applications logicielles complexes : cette troisième approche est uniquement adaptée à la construction d'applications multimédia proposées via Internet. Ainsi, l'état de la technique n'offre pas de solution technique simple et efficace permettant de construire une application logicielle personnalisée intégrant des fonctions logicielles spécifiques. En effet, la demanderesse soumet que l'ensemble des technologies et des outils standards actuellement disponibles ne permet pas à un utilisateur n'ayant aucun connaissance en informatique de construire lui-même l'application logicielle qu'il souhaite obtenir à partir d'un besoin fonctionnel initial. Résumé et objet de la présente invention La présente invention vise à améliorer la situation actuelle décrite ci-dessus. Un des objectifs de la présente invention est de permettre la construction d'une ou plusieurs applications logicielles sans faire appel à une quelconque compétence informatique. A cet effet, l'objet de la présente invention porte sur un procédé de construction d'une application logicielle fournissant une ou plusieurs fonctionnalités logicielles prédéterminées. Le procédé de construction est apte à être mise en oeuvre par des moyens informatiques. De préférence, le procédé de construction est mis en oeuvre sur un serveur informatique : la présente invention s'intègre ainsi parfaitement dans un environnement technologique du type « Cloud Computing ». Selon la présente invention, le procédé de construction comporte une étape de sélection qui consiste notamment à sélectionner à distance à partir d'une première base de données une pluralité de composants logiciels exécutables, également connus sous l'expression « brique logicielle ». On comprend ici que les composants logiciels (ou briques) sont préprogrammés (de préférence, par des experts) et présentent une granularité très fines ; en d'autres termes, chaque composant est destiné à fournir une fonctionnalité. De préférence, ces composants (ou briques) sont enregistrés sur une première base de données qui constitue un véritable catalogue de fonctionnalités. On parle ici de bibliothèque numérique logicielle. Par composant logiciel (ou brique), on entend ici un élément constitutif d'un logiciel destiné à être incorporé dans une ou plusieurs applications. Les paquets, les bibliothèques logicielles, les exécutables, les fichiers, les bases de données ou encore les éléments de configuration tels que les paramètres, les scripts ou les fichiers de commandes sont des composants logiciels au sens de la présente invention. De préférence, chaque composant logiciel (ou brique) est un programme 10 informatique dédié à une unique fonctionnalité prédéterminée. Ainsi, chaque composant logiciel présente ici la granularité la plus fine possible. Avantageusement, les composants logiciels (ou briques) sont aptes à être assemblés (ou couplés) les uns avec les autres. A cet effet, les composants logiciels présentent une architecture leur permettant d'être assemblés les uns avec les autres. On 15 parle ici d'interopérabilité des composants logiciels entre eux. Cette interopérabilité des composants est assurée par un moteur d'échange et des paramètres d'échanges qui sont intégrés dans chaque composant. Ces paramètres d'échanges contiennent pour chaque composant les données relatives à la capacité d'un composant à être connecté et à échanger avec chacun des autres composants du catalogue. Cette structure des 20 composants logiciels avec un moteur d'échange est caractéristique de la présente invention. Avantageusement, le procédé de construction selon la présente invention comporte une étape de génération ; cette étape consiste notamment à générer, en fonction des composants logiciels sélectionnés, un plan fonctionnel associé à une 25 application logicielle cible ; ce plan fonctionnel est un fichier informatique reprenant de façon structurée des informations relatives aux fonctionnalités sélectionnées. Ce plan fonctionnel est caractéristique de la présente invention, et représente une véritable cartographie des différentes fonctionnalités de l'application logicielle cible que l'utilisateur veut construire. 30 Avantageusement, lors de l'étape de génération, les composants logiciels (ou briques) sont assemblés les uns avec les autres de sorte à garantir la cohérence des fonctionnalités de l'application logicielle cible. Cet assemblage est donc réalisé selon des règles d'assemblage prédéterminées qui sont fonction notamment du moteur d'échange intégré dans chaque composant ; comme évoqué ci-dessus, ce moteur d'échange gère la connectivité et l'interopérabilité du composant sélectionné avec les autres composants. De préférence, le procédé de construction selon la présente invention comporte une étape de mémorisation qui consiste à mémoriser le plan fonctionnel sur une deuxième base de données. Avantageusement, le procédé de construction selon la présente invention comporte une étape d'activation ; cette étape consiste notamment à activer le plan fonctionnel pour exécuter à l'aide d'un moteur d'exécution les composants logiciels. Ainsi, grâce à cette succession d'étapes techniques, caractéristiques de la présente invention, il est possible de générer automatiquement une application logicielle en exécutant sur un moteur d'exécution les différents composants logiciels sélectionnés ; cette exécution permet de fournir par exemple via un serveur informatique les fonctionnalités définies pour l'application. La présente invention permet donc à un utilisateur quelconque de construire, lui-même ou de façon collaborative, une ou plusieurs applications logicielles entièrement personnalisées, tout en ayant la maitrise du code et de la chaine d'exécution du code, ceci sans pour autant avoir une quelconque connaissance en informatique. En effet, dans les anciennes solutions existantes décrites ci-dessus, quand on génère automatiquement du code, on ne maitrise pas son contenu, ce qui représente alors une source d'instabilité, de lourdeur et de risque sur la qualité. La demanderesse soumet qu'un code généré ne peut pas être aussi efficace qu'un code développé spécifiquement pour une fonction donnée. La solution proposée ici consiste donc à exploiter un catalogue de composants logiciels préprogrammés dont la granularité et la perméabilité (c'est-à-dire la capacité des composants à être assemblées les uns avec les autres) permet de construire des applications stables et robustes. De préférence, cette application logicielle est activée à distance directement sur un serveur pour être exécutée. Une telle technologie s'applique particulièrement bien pour les services de type « Cloud Computing ». Dans une variante de réalisation, le procédé de construction selon la présente invention comporte, préalablement à l'étape de sélection, une étape d'acquisition consistant à acquérir des données descriptives relatives aux fonctionnalités logicielles de l'application logicielle cible. Cette étape d'acquisition permet ainsi à l'utilisateur de définir préalablement les différentes fonctionnalités qu'il souhaite pour son application logicielle. Cette étape se fait par exemple via une interface graphique. De préférence, les données descriptives sont converties dans un format dédié pour permettre une sélection automatique des composants logiciels. Il existe à cet effet une table de correspondance permettant de mettre en correspondance les données descriptives relatives à la fonctionnalité désirée avec le composant logiciel correspondant dans la première base de données. Cette sélection automatique est possible par exemple lorsqu'il existe dans cette table une correspondance entre la ou les données descriptives et les champs descriptifs des composants logiciels. La présente invention prévoit dans une variante la possibilité d'enrichir le catalogue de composants. A cet effet, le procédé de construction selon la présente invention comporte une étape de création ; cette étape consiste notamment à créer un composant logiciel, puis le stocker sur la première base de données. Dans un mode de réalisation avantageux, l'étape d'activation comporte préalablement une authentification pour autoriser l'exécution des composants logiciels par le moteur d'exécution. Cette authentification implique par exemple la comparaison de données d'identification saisies par l'utilisateur (lors de sa connexion au serveur par exemple) et des données d'identification qui sont préenregistrées dans une troisième base de données. Corrélativement, l'objet de la présente invention porte sur un programme d'ordinateur qui comporte des instructions adaptées pour l'exécution des étapes du procédé de construction tel que décrit ci-dessus, ceci notamment lorsque ledit programme d'ordinateur est exécuté par un ordinateur. Un tel programme d'ordinateur peut utiliser n'importe quel langage de programmation, et être sous la forme d'un code source, d'un code objet, ou d'un code intermédiaire entre un code source et un code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable. De même, l'objet de la présente invention porte sur un support d'enregistrement lisible par un ordinateur sur lequel est enregistré un programme d'ordinateur comprenant des instructions pour l'exécution des étapes du procédé de construction tel que décrit ci-dessus. D'une part, le support d'enregistrement peut être n'importe quel entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une mémoire ROM, par exemple un CD-ROM ou une mémoire ROM de type circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple une disquette de type « floppy disc » ou un disque dur. D'autre part, ce support d'enregistrement peut également être un support transmissible tel qu'un signal électrique ou optique, un tel signal pouvant être acheminé via un câble électrique ou optique, par radio classique ou hertzienne ou par faisceau laser autodirigé ou par d'autres moyens. Le programme d'ordinateur selon l'invention peut être en particulier téléchargé sur un réseau de type Internet. Alternativement, le support d'enregistrement peut être un circuit intégré dans lequel le programme d'ordinateur est incorporé, le circuit intégré étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question. L'objet de la présente invention porte également sur un système de construction d'une application logicielle fournissant une ou plusieurs fonctionnalités logicielles prédéterminées, ledit système comportant des moyens informatiques configurés pour la mise en oeuvre des étapes du procédé de construction tel que décrit ci-dessus. Avantageusement, le système de construction comporte : - une interface de sélection qui est configurée pour sélectionner à distance à partir d'une première base de données une pluralité de composants logiciels exécutables (ou briques logicielles), - un circuit de génération configure pour générer, en fonction des composants logiciels sélectionnés, un plan fonctionnel associé à une application logicielle cible, - un moteur d'exécution configure pour exécuter les composants logiciels relatifs au plan fonctionnel, et - un circuit d'activation configure pour activer le plan fonctionnel et déclencher l'exécution des composants logiciels sur le moteur d'exécution. Avantageusement, le système de construction est apte à être mis en oeuvre sur un serveur informatique. Il est donc possible pour l'utilisateur de construire et/ou d'appeler son application à distance par exemple sur un réseau privé ou via Internet. Ainsi, l'objet de la présente invention, par ses différents aspects fonctionnels et structurels décrits ci-dessus, permet la construction d'une application logicielle sans faire appel à de quelconque connaissance en informatique. Brève description des figures annexées D'autres caractéristiques et avantages de la présente invention ressortiront de la description ci-dessous, en référence aux figures 1 et 2 annexées qui en illustrent un exemple de réalisation dépourvu de tout caractère limitatif et sur lesquelles : - la figure 1 représente de façon schématique un système de construction d'une application logicielle conforme à un exemple de réalisation de la présente invention ; et - la figure 2 représente un organigramme illustrant le procédé de construction d'une application logicielle conforme à un exemple de réalisation de la présente 25 invention. Description détaillée d'un mode de réalisation avantageux Un procédé de construction d'une application logicielle et le système informatique 100 qui lui est associé vont maintenant être décrits dans ce qui suit en faisant référence conjointement aux figures 1 et 2. 30 Permettre la construction d'une application logicielle sans faire appel à une quelconque compétence informatique est un des objectifs de la présente invention. Ainsi, dans l'exemple décrit et illustré en figure 1, l'utilisateur U n'a aucune compétence en informatique ; cet utilisateur U est une personne du « métier » qui a une vision précise des fonctionnalités qu'il souhaite voir apparaître dans son application logicielle. Il n'a cependant aucune idée des incidences que peut avoir l'implémentation de telles fonctionnalités dans son système informatique, ni du niveau de difficultés que cette implémentation représente sur le plan informatique. Considérons donc dans l'exemple décrit ci-après que l'utilisateur U souhaite développer lui-même (pour cause de coût et de temps) une application logicielle qui intègre les fonctionnalités fi et f2. Ces fonctionnalités fi et f2 peuvent par exemple porter respectivement sur une fonction fi relative à l'affichage d'une fenêtre de visualisation, et sur une fonction f2 relative à l'enregistrement de l'image visualisée sur cette fenêtre. Bien évidemment, ces exemples de fonctionnalités sont purement illustratifs et n'ont en aucune manière un caractère limitatif Ainsi, dans l'exemple décrit ici, l'utilisateur U dispose à travers le système 100 d'une interface de sélection 10 qui est simple, intuitive, et accessible sur un serveur S via un navigateur Web classique. Cette interface 10 lui permet de décrire rapidement et facilement lors d'une étape d'acquisition SO les fonctionnalités fi et f2 qu'il souhaite assembler pour son application logicielle. Il y décrit donc par exemple les écrans attendus et leur apparence, les données à manipuler et leurs structures (textes, images, etc.), les traitements à effectuer (droits, tris, calculs,...). Cette acquisition SO génère ensuite de façon automatique des données descriptives (non représentées ici) relatives aux fonctionnalités logicielles fi et f2 de l'application logicielle cible. Le format et le contenu de ces données sont propres au système. L'interface de sélection 10 comprend une table qui établit ensuite une correspondance entre ces données descriptives et les composants logiciels CL1, CL2, CL3 qui sont enregistrés sur une première base de données DB 1 . Cette mise en correspondance permet une sélection Si automatique des composants dédiés aux fonctionnalités fi et f2 parmi les composants logiciels (ou briques logicielles) CL1, CL2, et CL3 de la base de données DB1. Dans l'exemple décrit ici, ce sont par exemple les composants CL1 et CL2 qui sont dédiés aux fonctionnalités fi et 12. On comprend ici que le composant logiciel CL3 est quant à lui dédié exclusivement à la fonctionnalité f3 (non sélectionnée ici pour l'application cible désirée). De façon optionnelle, il est possible d'enrichir la base de données DB1 en créant d'autres composants logiciels pour offrir de nouvelles fonctionnalités, ceci par exemple lors d'une étape de création S5. Ceci nécessite bien évidemment une compétence en programmation informatique : cette étape S5 peut être réalisée par quiconque, en fonction bien évidemment de ses droits d'accès sur le serveur. La constitution d'un catalogue de composants logiciels CL1, CL2, et CL3 est caractéristique de la présente invention. En effet, la présente invention repose sur l'exploitation de ce catalogue qui propose un programme informatique préprogrammé et dédié pour chaque fonctionnalité identifiée (ce qui assure une bonne granularité dans les fonctionnalités proposées dans le catalogue). Le concept sous-jacent à la présente invention est donc de « packager » sur un serveur informatique S déporté les fonctions informatiques fi, f2 et f3 les plus couramment utilisées dans les applications logicielles (de type par exemple système d'information) pour les rendre facilement activables et utilisables par l'intermédiaire de ce serveur S. Dans l'exemple décrit ici, les composants logiciels (ou briques) CL1, CL2, et CL3 de cette base de données DB1 sont donc exécutables directement, et présentent comme détaillée ci-dessus une architecture spécifique pour être assemblés les uns aux autres. Ainsi, chaque composant logiciel (ou briques) CL1, CL2, et CL3 correspond du point de vue « métier » à une fonctionnalité ou un ensemble limité de fonctionnalités. C'est cette vision granulaire, structurée et fonctionnelle qui est orientée « métier » qui permet à l'utilisateur de concevoir seul son application à la manière d'un jeu de briques qu'on assemble. Du point de vue « informatique », chaque composant logiciel (ou briques) CL1, CL2, et CL3 est un programme informatique dédié à une seule fonctionnalité, exécutable de façon indépendante, et qui peut être appelé dans le cadre d'une application informatique plus complexe pour répondre à un besoin partiel de celle-ci. Ce programme comprend du code exécutable ainsi qu'un certain nombre de données stockées (en fichier ou en base de données). Selon la présente invention, chaque composant logiciel peut comporter un certain nombre d'options activables qui peuvent être de deux types : - les échanges avec d'autres composants logiciels. Ces échanges ou connexions entre composants sont définies lors de l'assemblage de l'application et sont stockées dans un plan fonctionnel M de l'application dans une base de données DB2 ; et - les options définies par l'utilisateur notamment des options visuelles ou comportementales. Ces options sont définies lors de l'assemblage de l'application et sont également stockées dans le plan fonctionnel M de l'application. Afin de permettre des échanges à la fois suffisamment souples en garantissant néanmoins une certaine « étanchéité » des composants, le choix de la granularité des composants logiciels est important. Cette granularité prévoit donc de préférence une seule fonctionnalité par composant logiciel. On prévoit des composants logiciels de type : - « visuel », par exemple pour afficher des éléments, - « données », par exemple pour définir une structure de stockage ou pour définir la nature d'une information ou d'une données à traiter, et enfin - « traitement », par exemple pour définir une fonction ou un traitement des données. Cette découpe en différents composants fonctionnels distincts, modulaires, indépendants permet non seulement de réaliser de multiples fonctionnalités dans une application, mais également de rendre flexible la construction d'application en choisissant les composants les mieux adaptés. Une fois les composants logiciels CL1 et CL2 sélectionnés, le circuit de génération 20 du système génère lors d'une étape de génération S2 un plan fonctionnel M associé à une application logicielle cible, cette génération est fonction des composants logiciels sélectionnés CL1 et CL2. Ce plan M est en effet généré par le circuit de génération 20 en fonction de règles prédéfinies respectant notamment la capacité des composants à être assemblés les uns avec les autres (cette capacité étant paramétrée initialement dans chaque composant à travers un moteur d'échange). Ce plan M vérifie l'interopérabilité des composants entre eux, notamment en interrogeant le moteur d'échange et les paramètres associés dans chaque composant sélectionné du plan M. Ce plan M constitue une véritable cartographie des différentes fonctionnalités f1 et f2 de l'application logicielle cible. Ce plan M est de préférence mémorisé sur une deuxième base de données DB2 lors d'une étape de mémorisation S3. Ainsi, lorsque ce plan M est généré, l'utilisateur U doit activer par l'intermédiaire d'un circuit d'activation 40, lors d'une étape S4, ce plan fonctionnel M pour permettre l'exécution des composants logiciels CL1 et CL2 sur le moteur d'exécution 30. En d'autres termes, le circuit d'activation 40 permet d'activer le plan M qui est enregistré sur la base de données DB2. Cette activation permet l'exécution par le moteur 30 des composants logiciels (ou briques) CL1 et CL2 contenues dans le plan 20 M. Cette activation S4 de l'application à distance sur le serveur S est éventuellement conditionnée par une authentification S6 préalable de l'utilisateur U sur le serveur S, par exemple en saisissant un identifiant du type « login » et un mot de passe ; ces éléments d'authentification sont comparées à des données d'identification 25 stockées sur une troisième base de données DB3. Cette activation S4 du plan M permet ainsi la fourniture à l'utilisateur U des fonctionnalités fi et f2 sélectionnées relatives respectivement aux composants (ou briques) CL1 et CL2 exécutés. La présente invention propose donc un véritable « écosystème » permettant à 30 l'utilisateur U d'une part de créer rapidement l'application métier souhaitée (application de gestion, système d'informations, etc.) et d'autre part d'exécuter/utiliser directement cette application sur le serveur S à partir d'une application « polymorphe » sur la base d'un plan fonctionnel M. Dans l'exemple décrit ici, l'application logicielle ainsi construite/assemblée est accessible pour une utilisation immédiate à partir d'un navigateur Web. Selon l'invention, l'utilisateur U ne peut accéder au code source ou à un quelconque langage de programmation. Lorsqu'un utilisateur se connecte pour utiliser l'application ainsi construite, le circuit d'exécution se retourne vers le plan M pour savoir quelles sont les fonctionnalités et le comportement attendu : par exemple, quels sont les écrans à afficher, quelles sont les données à montrer ou à masquer, quels les traitements à réaliser, et quelles sont les actions qui doivent être proposées au travers de l'Interface Homme Machine (menus, boutons, fonctionnalités, etc.). Les fonctionnalités décrites par le plan fonctionnel M sont alors puisées et exécutées à la demande dans le catalogue de composants logiciels (ou briques), ceci au fil de l'utilisation. Ainsi, grâce à la présente invention, il est possible de construire puis d'exécuter immédiatement une application entièrement personnalisée sans aucune génération de code. De plus, le code ayant été spécifiquement écrit pour pouvoir exécuter les fonctionnalités attendues, il est optimisé et la qualité peut en être assurée de bout en bout jusqu'à l'exécution, grâce notamment à la structure des composants logiciels (et notamment grâce au moteur d'échange). Comme rappelé ci-dessus, pour respecter la granularité des composants et assurer l'interopérabilité des composants entre eux, il est préférable de permettre aux composants logiciels qui vont être assemblée puis exécutées : de savoir reconnaitre les composants logiciels avec lesquels ils peuvent interagir, une fois connectés, d'interagir nativement avec les composants logiciels, et de ne pas transmettre d'erreur aux autres composants logiciels (gestion des erreurs et notion d'étanchéité). Ceci est assuré notamment par les informations contenues dans le moteur d'échange de chaque composant logiciel. Il devra être observé que cette description détaillée porte sur un exemple de réalisation particulier de la présente invention, mais qu'en aucun cas cette description ne revêt un quelconque caractère limitatif à l'objet de l'invention ; bien au contraire, elle a pour objectif d'ôter toute éventuelle imprécision ou toute mauvaise interprétation des revendications qui suivent. REVENDICATIONS1. Procédé de construction d'une application logicielle fournissant une ou plusieurs fonctionnalités logicielles (fi, f2, f3) prédéterminées, ledit procédé mis en oeuvre par des moyens informatiques comportant les étapes suivantes : - une étape de sélection (Si) consistant à sélectionner à distance à partir d'une première base de données (DB1) une pluralité de composants logiciels exécutables (CL1, CL2, CL3), - une étape de génération (S2) consistant à générer, en fonction desdits composants logiciels (CL1, CL2, CL3) sélectionnés, un plan fonctionnel (M) associé à une application logicielle cible, et - une étape d'activation (S4) consistant notamment à activer ledit plan fonctionnel (M) pour exécuter sur un moteur d'exécution (30) lesdits composants logiciels (CL1, CL2, CL3). 2. Procédé de construction selon la revendication 1, caractérisé en ce que chaque composant logiciel (CL1, CL2, CL3) est un programme informatique dédié à une unique fonctionnalité prédéterminée (fi, f2, f3). 3. Procédé de construction selon la revendication 1 ou 2, caractérisé en ce qu'il comporte une étape de mémorisation (S3) dudit plan fonctionnel (M) sur une deuxième base de données (DB2). 4. Procédé de construction selon l'une quelconque des revendications précédentes, caractérisé en ce qu'il comporte, préalablement à l'étape de sélection (Si), une étape d'acquisition (SO) consistant à acquérir des données descriptives relatives aux fonctionnalités logicielles (fi, f2, f3) de l'application logicielle cible. 5. Procédé de construction selon l'une quelconque des revendications précédentes, caractérisé en ce qu'il comporte une étape de création (S5) consistant à créer uncomposant logiciel (CL1, CL2, CL3), puis le stocker sur la première base de données (DB 1 ) . 6. Procédé de construction selon l'une quelconque des revendications précédentes, caractérisé en ce que, lors de l'étape de génération (S2), les composants logiciels (CL1, CL2, CL3) sont assemblés les uns avec les autres de sorte à garantir la cohérence des fonctionnalités (fi, f2, f3) de l'application logicielle cible. 7. Programme d'ordinateur (PG) comportant des instructions adaptées pour l'exécution des étapes du procédé de construction selon l'une quelconque des revendications 1 à 6 lorsque ledit programme d'ordinateur (PG) est exécuté par un ordinateur. 8. Support d'enregistrement (CI) lisible par un ordinateur sur lequel est enregistré un programme d'ordinateur (PG) comprenant des instructions pour l'exécution des étapes du procédé de construction selon l'une quelconque des revendications 1 à 6. 9. Système de construction (100) d'une application logicielle fournissant une ou plusieurs fonctionnalités logicielles (fi, f2, f3) prédéterminées, ledit système (100) comportant : - une interface de sélection (10) configurée pour sélectionner à distance à partir d'une première base de données (DB 1) une pluralité de composants logiciels exécutables (CL1, CL2, CL3), - un circuit de génération (20) configure pour générer, en fonction desdits composants logiciels (CL1, CL2, CL3) sélectionnés, un plan fonctionnel (M) associé à une application logicielle cible, - un moteur d'exécution (30) configure pour exécuter lesdits composants logiciels (CL1, CL2, CL3) relatifs au plan fonctionnel (M), et - un circuit d'activation (40) configure pour activer ledit plan fonctionnel (M) et déclencher l'exécution desdits composants logiciels (CL1, CL2, CL3) par le moteur d'exécution (30). 10. Système de construction (100) selon la revendication 9, caractérisé en ce qu'il comporte des moyens informatiques configurés pour la mise en oeuvre du procédé de construction selon l'une quelconque des revendications 1 à 6.