FR 2977344 A1 20130104 FR 1155811 A 20110629 L'invention concerne la communication entre applications de type application Web chargées simultanément dans un même environnement graphique. En particulier, l'invention a pour objets un procédé et un dispositif de création d'un lien d'exécution entre une première application Web et au moins une seconde application Web, aptes à présenter respectivement des données d'exécution au moyen d'une interface graphique respective incluse dans un environnement graphique. On entend ici par "application Web" des applications développées sous forme de modules distincts, appelées Porlets, Widgets ou simplement Modules en terminologie anglaise, et utilisés notamment dans le cadre des développements appelés "Web 2.0", qui utilisent par exemple la technique de construction d'application Web connue sous le nom de "AJAX" (acronyme de Asynchronous Javascnpt and XML) De telles applications Web sont généralement des logiciels applicatifs manipulables grâce un navigateur Web. Une application Web est généralement placée sur une serveur et se manipule en actionnant une interface graphique associée - d'où le terme "Widget', qui est parfois considéré comme procédant de la contraction des mots anglais "windoW' et "gadget' - à l'aide d'un navigateur Web, via un réseau informatique (Internet, intranet, réseau local, etc.). Il existe différentes techniques connues permettant de créer des liens d'exécution entre différentes applications Web, c'est-à-dire, utiliser un résultat d'exécution d'une première application pour exécuter une seconde application avec en paramètre d'entrée tout ou partie du résultat précité. On emploie aussi les termes "composition" ou "enchainement" d'applications. Ainsi, le document brevet n° EP 2 169 569 décrit un procédé de communication entre une première application et au moins une deuxième application, accessibles à 30 l'intérieur d'une page d'un navigateur Internet. Le procédé susmentionné comprend notamment les étapes suivantes : - transmission préalable par la deuxième application - par exemple une application d'annuaire électronique - à une entité de gestion d'applications, d'une première liste associant à chaque service proposé par la deuxième application, au moins un paramètre de sortie de type prédéterminé - par exemple une donnée de "contact" - dont une valeur sera générée à l'exécution du service considéré ; - transmission par la première application à l'entité de gestion d'applications, d'une deuxième liste associant des types de paramètres d'entrée (données ou évènements) respectivement à au moins une opération susceptible d'être exécutée par la première application ; - création par l'entité de gestion d'applications d'une troisième liste, dite de souscription de service, dans laquelle chaque service de la première liste, relatif à la seconde application, est associé à au moins une opération susceptible d'être exécutée par la première application, par mise en correspondance des types de paramètres contenus respectivement dans les première et deuxième listes. En d'autres termes, grâce à cette "troisième liste", une mise en correspondance est établie entre chaque service fourni par la seconde application, et au moins une opération susceptible d'être exécutée par la première application ; et cette mise en correspondance est basée sur une comparaison des types de paramètres de sortie déclarés pour la seconde application, avec des types de paramètres d'entrée déclarés pour la première application. Le procédé proposé dans ce document présente au moins deux inconvénients. Le premier inconvénient réside dans la nécessité d'un typage fort des données pour que les applications soient composables, c'est-à-dire pour qu'un lien d'exécution entre ces applications puisse être réalisé. En effet, les paramètres d'entrée et de sortie des applications considérées sont des paramètres "déclarés" donc clairement prédéfinis par les développeurs de ces applications, et sont formatés selon des spécifications précises de manière à rendre le typage de ces paramètres compatible entre différentes applications développées de manière indépendante par des développeurs distincts. Les développeurs sont donc contraints d'utiliser un même dictionnaire d'étiquettes (tags en anglais) pour définir les types de données que leurs applications acceptent comme paramètres d'entrée et génèrent comme paramètres de sortie. Un second inconvénient réside dans le fait que la communication entre les applications considérées, chargées simultanément dans un environnement graphique, reposant uniquement sur des types de données d'entrée ou de sortie prédéfinis, les données produites par l'exécution d'une application donnée, qui ne sont pas prédéfinies comme données de sortie pour cette application, ne sont pas prises en compte, alors qu'elles pourraient être utilisées comme données d'entrée d'une autre application chargée dans l'environnement graphique. 3 Par exemple, une adresse postale et un numéro de téléphone, échangés entre des utilisateurs dans une conversation de messagerie instantanée (chat) ou de messagerie électronique (email), pourraient servir de paramètres d'entrée, respectivement dans une application de cartographie en ligne et une application de téléphonie sur Internet. Les données produites lors de l'exécution d'une application Web qui ne sont pas déclarées - c'est-à-dire n'appartenant pas à un type de données de sortie formaté et déclaré pour l'application considérée -, sont parfois désignées par "données non structurées". La présente invention vise notamment à améliorer la situation exposée ci-dessus, en fournissant un procédé de communication entre applications Web, permettant d'utiliser de manière automatique des données non structurées produites par une première application Web en tant que données d'entrée d'une seconde application Web. A cette fin, l'invention concerne, selon un premier aspect, un procédé de création d'un lien d'exécution entre une première application Web et au moins une seconde application Web aptes à présenter respectivement des données d'exécution au moyen d'une interface graphique respective incluse dans un environnement graphique. Ce procédé comporte, lors du chargement de chacune des applications Web par un module de gestion d'applications, la mémorisation dans une première structure de données d'informations identifiant, d'une part, la ou les fonctionnalités fournies par l'application considérée, et d'autre part, l'ensemble des types de données d'entrée acceptés pour exécuter chaque fonctionnalité de l'application considérée. Conformément à l'invention, le procédé comporte en outre des étapes de : - (A) détermination, parmi des données d'exécution obtenues par l'exécution d'au moins une fonctionnalité associée à la première application, de celles qui sont conformes à au moins un type de données d'entrée identifié dans la première structure de données ; - (B) déclenchement de l'exécution d'au moins une fonctionnalité d'au moins une seconde application en appliquant au moins une donnée d'exécution de la première application, déterminée à l'étape (A), comme donnée d'entrée pour la (ou les) seconde(s) application(s). Ainsi, grâce au procédé de l'invention, il est maintenant possible de créer de manière automatique un lien d'exécution entre une première et une seconde S 2977344 4 application web, à partir de données structurées ou non structurées produites par l'exécution d'une fonctionnalité de la première application - c'est-à-dire sans prise en compte de types de données de sortie déclarés pour la première application, ni connaissance a priori de types de données susceptibles d'être produits par l'exécution 5 de la première application. En d'autres termes, selon le procédé défini ci-dessus, par la consultation du contenu de la première structure de données, il est possible d'effectuer une comparaison automatique entre n'importe quelle donnée produite par l'exécution d'une fonctionnalité d'une première application, et les types de données d'entrée déclarés 10 pour l'ensemble des applications chargées dans l'environnement graphique (par la consultation du contenu de la structure de données). La "comparaison" précitée rend possible, de manière automatique ou quasi automatique, le déclenchement de l'exécution d'une fonctionnalité d'une seconde application en appliquant au moins une donnée d'exécution de la première application, comme donnée d'entrée pour la 15 fonctionnalité de la seconde application considérée. Selon une caractéristique particulière, le procédé selon l'invention comprend préalablement à l'étape de détermination (A), une étape de détermination, pour chaque type de données d'entrée mémorisé dans la première structure de données, d'un module d'extraction de données adapté à extraire le type de données considéré, et de 20 mémorisation, dans une seconde structure de données, d'informations identifiant chaque module d'extraction de données déterminé. L'étape précitée de détermination (A) inclut alors des opérations de : - sélection, à partir de la seconde structure de données, d'un ensemble de modules d'extraction de données adaptés à extraire au moins un type de données 25 d'entrée accepté au moins par une seconde application ; - application de l'ensemble de modules d'extraction de données sélectionné, aux données d'exécution présentées dans l'interface graphique de la première application, pour extraire des données d'exécution conformes à au moins un type de données d'entrée accepté par au moins une seconde application. 30 La constitution d'une seconde structure de données dans laquelle sont référencés des modules d'extraction de données aptes à extraire les types de données d'entrées déclarés dans la première structure de données, est un moyen simple et efficace d'effectuer la détermination susmentionnée des données d'exécution relatives à la première application qui sont conformes à au moins un type de données d'entrée 35 accepté par une seconde application chargée dans l'environnement graphique. Selon un mode de réalisation particulier, l'opération de sélection d'un ensemble de modules d'extraction de données, comprend : - l'affichage de types de données d'entrée, obtenus à partir de la seconde structure de données, en relation avec l'interface graphique de la première application ; - la sélection graphique par l'utilisateur, via un dispositif de sélection graphique, d'au moins un type de données d'entrée affiché, le module d'extraction de données correspondant étant alors sélectionné. Dans ce mode de réalisation, la sélection des modules d'extractions de données, avant leur application aux données d'exécution relatives à la première application, fait avantageusement intervenir le choix de l'utilisateur. Selon une variante de réalisation, l'opération de sélection d'un ensemble de modules d'extraction de données, consiste à sélectionner automatiquement l'ensemble des modules d'extraction de données identifiés dans la seconde structure de données. Selon cette variante précitée, le choix de l'utilisateur pour la sélection des modules d'extraction, n'intervient plus. L'application automatique de tous les modules d'extraction identifiés dans la seconde structure de données au contenu d'exécution de la première application, présente l'avantage de présenter directement à l'utilisateur les différents liens d'exécution possibles, par exemple par l'affichage d'une icône représentative de chacune des secondes applications susceptibles d'être lancées. Selon un mode de réalisation particulier, l'étape de déclenchement de l'exécution (B) d'au moins une fonctionnalité d'au moins une seconde application en appliquant au moins une donnée d'exécution de la première application comme donnée d'entrée pour au moins une seconde application, comprend : - le marquage graphique des données d'exécution de la première application qui ont été extraites suite à l'application de l'ensemble de modules d'extraction de données; - la sélection graphique par l'utilisateur via un dispositif de pointage prédéfini d'au moins une donnée d'exécution marquée ; - en réponse à la sélection d'au moins une donnée d'exécution marquée, l'exécution d'au moins une fonctionnalité d'au moins une seconde application avec au moins une donnée d'exécution sélectionnée, comme donnée d'entrée pour chaque fonctionnalité exécutée. En pratique, selon un exemple de réalisation particulier, la première structure de données inclut en outre pour chaque application chargée dans l'environnement graphique un lien vers une icône graphique représentative de l'application considérée, et dans lequel le marquage graphique d'une donnée d'exécution extraite par un module d'extraction, comprend l'affichage de l'icône graphique correspondant à chaque seconde application qui accepte la donnée d'exécution extraite comme donnée d'entrée. Selon une première variante d'implémentation du procédé selon l'invention, les étapes précitées de détermination (A) et de déclenchement d'exécution (B), sont mises en oeuvre par le module de gestion d'applications. Selon une seconde variante d'implémentation du procédé selon l'invention, les étapes précitées de détermination (A) et de déclenchement d'exécution (B), sont mises en ceuvre par l'exécution d'instructions de programme incluses dans le code programme de chaque application Web chargée par le module de gestion d'applications. Cette seconde variante de réalisation présente l'avantage de rendre possible l'utilisation d'un module de gestion d'applications Web (agrégateur) standard, puisque ce sont les applications qui comportent des fonctions spécifiques à la mise en oeuvre du procédé selon l'invention. Corrélativement, selon un second aspect, l'invention concerne un dispositif de création d'un lien d'exécution entre une première application Web et au moins une seconde application Web aptes à présenter respectivement des données d'exécution au moyen d'une interface graphique respective incluse dans un environnement graphique, ce dispositif comportant un module de gestion d'applications adapté à charger des applications Web dans un environnement graphique, et des moyens pour mémoriser dans une première structure de données, lors du chargement de chacune des applications, des informations identifiant, d'une part, la ou les fonctionnalités fournies par l'application considérée, et d'autre part, l'ensemble des types de données d'entrée acceptés pour exécuter chaque fonctionnalité de l'application considérée. Conformément à l'invention, ce dispositif comporte en outre : - des moyens d'analyse et de traitement, adaptés à déterminer, parmi des données d'exécution obtenues par l'exécution d'au moins une fonctionnalité associée à la première application, celles qui sont conformes à au moins un type de données d'entrée identifié dans ladite première structure de données ; - des moyens de déclenchement de l'exécution d'au moins une fonctionnalité d'au moins une seconde application en appliquant au moins une donnée d'exécution de la première application, déterminée par les moyens d'analyse et de traitement, comme donnée d'entrée pour au moins une seconde application. Selon d'autres aspects, l'invention a aussi pour objets : - un terminal de communication comportant un dispositif de création d'un lien d'exécution entre applications Web, tel que succinctement exposé plus haut ; - un produit programme d'ordinateur comprenant des instructions de programme adaptées à mettre en oeuvre un procédé, selon l'invention, de création d'un lien d'exécution entre applications Web, lorsque ce programme est chargé et exécuté par un processeur ; - une application Web stockée sur un support d'informations ou téléchargeable via un réseau de communication incluant des instructions de programme adaptées à mettre en oeuvre un procédé, selon l'invention, de création d'un lien d'exécution entre applications Web, lorsque ces instructions sont exécutées par un processeur. Les avantages procurés par le dispositif de création d'un lien d'exécution, le terminal de communication, le programme d'ordinateur et l'application Web, exposés ci-dessus, sont identiques à ceux mentionnés plus haut en relation avec le procédé de création d'un lien d'exécution selon l'invention, et ne seront par conséquent pas rappelés ici. L'invention sera mieux comprise à l'aide de la description détaillée qui va suivre, faite en se référant : - aux éléments annexés en fin de description, parmi lesquels : - l'annexe 1 illustre un exemple de code XHTML d'une application Web de type Widget ; - l'annexe 2 illustre sous forme de pseudo code un algorithme d'extraction de données d'un type prédéfini "adresse postale" ; - aux dessins joints dans lesquels : - la figure 1 représente un système de communication dans lequel est mis en oeuvre un dispositif de création d'un lien d'exécution entre plusieurs applications Web, 30 selon l'invention ; - la figure 2 illustre un exemple de traitement effectué par un module d'extraction de données textuelles correspondant au type d'adresse postale exposé dans l'annexe 2 ; - 2977344 s - la figure 3 est un organigramme illustrant le déroulement des étapes d'un procédé de création d'un lien d'exécution entre plusieurs applications Web, selon un mode de réalisation de l'invention ; et - la figure 4 illustre l'affichage résultant de la lecture d'une page Web par un 5 navigateur Internet dans laquelle est chargée quatre applications Web distinctes, entre lesquelles des liens d'exécution de fonctionnalités peuvent être créés conformément à un mode de réalisation de la présente invention. La figure 1 représente un système de communication dans lequel est mis en 10 oeuvre un dispositif de création d'un lien d'exécution entre plusieurs applications Web, selon l'invention. Dans le système représenté, un terminal d'utilisateur UT communique, via un réseau de communication (NW), de type Internet, avec un ou plusieurs serveurs SVR d'applications Web (un seul représenté sur la figure 1), par exemple des applications 15 de type Widget. Dans la suite de la description, dans un but de simplification de l'exposé, les applications Web compatibles avec la présente invention, sont indifféremment désignées, de manière non limitative, par les termes suivants : "application Web", "application" ou "Widget". Le terminal UT, tel qu'un téléphone intelligent (smartphone en anglais) ou un 20 ordinateur personnel, est basé sur une architecture classique d'ordinateur, c'est-à-dire, comprenant notamment une unité centrale de traitement (CPU) ou processeur, un espace de stockage (STO) de données de type disque dur, une mémoire volatile (MEM) de type RAM, dans laquelle les instructions, les données et les variables des programmes en cours d'exécution par le processeur sont stockés de manière 25 temporaire. En particulier, la mémoire MEM stocke temporairement des structures de données L0, L1, L2 telles que des listes ou des tableaux de données, utilisées dans le cadre de la présente invention pour mémoriser des informations relatives aux fonctionnalités offertes par les applications Web (Widget) et les types de données d'entrée déclarés pour ces fonctionnalités. La première structure de données (L1), est utilisée pour mémoriser, lors du chargement de chacune des applications par l'agrégateur, des informations identifiant, d'une part, la ou les fonctionnalités fournies par l'application considérée, et d'autre part, l'ensemble des types de données d'entrée acceptés pour exécuter chaque fonctionnalité de l'application considérée. Ces structures de données sont détaillées plus loin dans la description. 9 Le terminal UT comporte en outre un écran d'affichage (SCR) et une interface réseau (NI) permettant au terminal de se connecter au réseau NW et d'échanger des données avec des équipements distants connectés au réseau. En particulier, le terminal UT peut télécharger, depuis le serveur SVR, des pages Web - codées en langage HTML (Hypertext Markup Language) ou XHTML (eXtensible HyperText Markup Language) -, que le terminal peut lire grâce à un logiciel de navigation sur le Web (navigateur Web) préalablement installé dans le terminal, par exemple dans l'espace de stockage STO. Dans l'exemple représenté sur la figure 1, le terminal UT a téléchargé du serveur SVR, sous la forme d'une page Web, un module (AM) de gestion d'applications Web, de type connu sous l'appellation "agrégateur de Widgets". Un agrégateur de Widgets peut être défini comme un logiciel permettant de charger des applications Web distinctes (Widgets) qui donnent lieu à l'affichage, dans la fenêtre du navigateur, de sous-fenêtres, propre chacune, à afficher un rendu d'exécution d'une application Web donnée. Comme représenté sur la figure 1, lorsque le moteur de rendu du navigateur Web traite le code de la page Web correspondant à l'agrégateur de Widgets, un environnement graphique GUI_AM est affiché par le navigateur. Dans l'exemple illustré, deux Widgets, WIDG1 et WIDG2, ont été en outre téléchargées du serveur SVR, et leur chargement par l'agrégateur (AM) a donné lieu à l'affichage par le navigateur, à l'intérieur de l'environnement graphique GUI_AM, de deux interfaces graphiques, G_WIDG1 et G_WIDG2, correspondantes. L'agrégateur de Widgets (AM) inclut un module d'analyse syntaxique/sémantique PSR (également désigné par le terme "parsec' en anglais). Le module PSR a notamment pour fonction d'analyser les fonctionnalités de chaque Widget chargée par l'agrégateur. Selon l'invention, l'agrégateur de Widgets (AM) inclut en outre une unité de communication d'applications Web (WCM). Selon le mode de réalisation illustré et exposé, l'unité WCM comprend les sous-entités suivantes : Un module d'analyse et de traitement (AT), dont la fonction principale est de déterminer, parmi des données d'exécution obtenues par l'exécution d'au moins une fonctionnalité associée à une première application (WIDG1), celles qui sont conformes à au moins un type de données d'entrée identifié dans la première structure de données (L1). Afin de mettre en oeuvre cette fonction principale, le module d'analyse et de traitement AT inclut, selon un mode de réalisation choisi, les sous-modules suivants (non représentés) : - un premier sous-module, dont la fonction est la détermination de modules (non représentés) d'extraction de données, destinés à déterminer, pour chaque type de données d'entrée mémorisé dans la première structure de données (Li), un module d'extraction de données adapté à extraire le type de données considéré, et à mémoriser, dans une seconde structure de données (L2), des informations identifiant chaque module d'extraction de données déterminé ; - un second sous-module, dont la fonction est de sélectionner, à partir de la seconde structure de données (L2), un ensemble de modules d'extraction de données adaptés à extraire au moins un type de données d'entrée accepté par au moins une seconde application (WIDG2) chargée par le module de gestion d'applications (agrégateur de Widgets, AM) ; - un troisième sous-module, dont la fonction est d'appliquer l'ensemble sélectionné de modules d'extraction de données, aux données d'exécution présentées dans l'interface graphique (G_WIDG1) associée à la première application (WIDG1), et d'extraire des données d'exécution conformes à au moins un type de données d'entrée accepté par au moins une seconde application (WIDG2). - un module de déclenchement d'exécution de fonctionnalités (DEF) dont la fonction principale est de déclencher l'exécution d'au moins une fonctionnalité d'au moins une seconde application (WIDG2) en appliquant au moins une donnée d'exécution de la première application (WIDG1), déterminée par le module (AT) d'analyse et de traitement, comme donnée d'entrée pour au moins une seconde application. Afin de mettre en oeuvre la fonction principale précitée, selon un mode de réalisation choisi, le module de déclenchement d'exécution de fonctionnalités, DEF, inclut les sous-modules suivants (non représentés) : - un sous-module de marquage graphique des données d'exécution de la première application (WIDG1) qui ont été extraites suite à l'application de l'ensemble sélectionné de modules d'extraction de données ; - un sous-module destiné à déclencher, en réponse à la sélection graphique par un utilisateur d'au moins une donnée d'exécution marquée, l'exécution d'au moins une fonctionnalité d'au moins une seconde application avec au moins une donnée d'exécution sélectionnée, comme donnée d'entrée pour chaque fonctionnalité exécutée. Comme déjà évoqué plus haut, les entités, modules et sous-modules fonctionnels exposés ci-dessus sont, en pratique, implémentés sous forme logicielle, c'est-à-dire, de manière générale, un ensemble de programmes d'ordinateur formant un ensemble et comprenant des instructions adaptées à la mise en oeuvre du procédé de création d'un lien d'exécution, selon l'invention. Ce procédé est par conséquent mis en oeuvre lorsque ce ou ces programmes sont chargés et exécutés dans un ordinateur ou dispositif informatique. En particulier, le module de gestion d'application (agrégateur, AM) est classiquement implémenté sous la forme d'une page Web codée en langage HTML ou XHTML, et l'unité de communication d'applications Web (WCM) est implémentée sous la forme d'un ou plusieurs objets codés dans un langage de programmation de scripts du type du langage JavaScript, et ces objets son accessibles à l'intérieur du code HTML ou XHTML de la page Web de l'agrégateur d'applications Web. L'annexe 1 illustre un exemple de code XHTML d'une application Web de type Widget, qui peut être chargée par un agrégateur de Widgets, selon l'invention. Selon l'exemple de la l'annexe 1, une telle application peut être implémentée comme étant une page Web. Le code d'une telle Widget comporte deux parties, une partie "définition" ou "déclaration" (située entre les balises ) et une partie "implémentation" (située entre les balises et comporte notamment la liste des fonctionnalités fournies par la Widget ("Functionality'), et les types de données attendus en entrée par chaque fonctionnalité. Dans l'exemple représenté, le type de données d'entrée est affecté à la variable "inputDataType" et sa valeur est "postalAddress", c'est-à-dire correspondant au type adresse postale. Un type de donnée, telle que "postalAddress" correspond à une étiquette (tag en anglais) sémantique. La liste des étiquettes sémantiques à utiliser dans les différentes Widgets et pour les divers modules d'extraction de données, doit être la même afin de permettre la détection automatique des extracteurs de données à utiliser dans l'environnement graphique présenté à l'utilisateur, et pouvoir ainsi créer des liens entre, d'une part, des données extraites d'exécution d'une fonctionnalité donnée d'une Widget, et d'autre part, les fonctionnalités disponibles correspondant à l'ensemble des Widgets chargées dans l'environnement graphique. En pratique, la liste d'étiquettes sémantiques correspondant aux types de 35 données d'entrée, peut être fournie par l'agrégateur de Widgets lui-même, mais aussi, en variante, par une communauté de fournisseurs de Widgets et d'extracteurs de données non structurées. L'annexe 2 illustre sous forme de pseudo code un algorithme d'extraction de données d'un type prédéfini d'adresse postale. Ce pseudo code, qui se comprend de lui-même, permet d'extraire des portions d'un texte d'entrée qui correspondent à une séquence de termes comprenant un nombre, suivi d'un mot identifiant une voie d'accès (rue, boulevard, avenue), suivi d'un nom de ville (Caen, Paris, Marseille, Lyon, ...). Chaque portion extraite est alors étiquetée à l'aide de balises appropriées, comme illustré à la figure 2, qui illustre un exemple de traitement effectué par un module d'extraction de données textuelles correspondant au type d'adresse postale exposé dans l'annexe 2. Dans cet exemple, un texte d'entrée T-IN issu par exemple d'une communication via une Widget de messagerie instantanée, est traité par un module d'extraction M-EX d'adresses postales, qui en extrait la séquence "167 boulevard Raspail' comme étant du type postalAddress. Le module d'extraction insère ensuite dans le texte d'entrée T-IN des balises spécifiques identifiant la séquence extraite et produit en conséquence un texte de sortie T-OUT dans lequel la séquence extraite est étiquetée comme étant du type postalAddress, c'est-à-dire encadrée par les deux balises et . En relation avec l'organigramme représenté à la figure 3 et la figure 4 qui illustre l'affichage résultant de la lecture d'une page Web par un navigateur Internet dans laquelle est chargée quatre applications Web distinctes, on va à présent décrire le déroulement des étapes d'un procédé de création d'un lien d'exécution entre plusieurs applications Web, selon un mode de réalisation de l'invention. Comme illustré à la figure 3, le procédé selon l'invention comporte deux phases principales S1, S2. La phase S1 correspond essentiellement, d'une part, au chargement (E1, E2) de l'agrégateur et des applications Web (Widgets), et d'autre part, à la détermination et mémorisation des données nécessaires à la création automatique de liens d'exécution de fonctionnalités entre plusieurs de ces Widgets chargées. La phase S2 quant à elle, correspond essentiellement à la création effective de liens d'exécution entre plusieurs Widgets. Au cours des étapes E1 et E2 (figure 3), le module (AM) de gestion d'application (agrégateur de Widgets) est chargé par le navigateur Web du terminal utilisateur (UT). En conséquence, comme illustré à la figure 4, une fenêtre GUI_AM liée à l'agrégateur est affichée sur l'écran (SCR) du terminal utilisateur, et une sous-fenêtre 13 est affichée respectivement pour chacune des Widgets chargées - quatre Widgets dans l'exemple de la figure 4 : WIDG1, WIDG2, WIDG3, WIDG4. Dans cet exemple, WIDG1 est une application de messagerie instantanée, WIDG2 une application d'agenda, WIDG3 une application de téléphonie sur Internet, et 5 WIDG3 une application de géolocalisation. A l'étape E3, il est procédé à la mémorisation dans une première structure de données, L1, d'informations identifiant, pour chacune des Widgets, d'une part, la ou les fonctionnalités fournies par la Widget considérée, et d'autre part, l'ensemble des types de données d'entrée acceptés pour exécuter chacune des fonctionnalités offertes par 10 la Widget considérée. Par ailleurs, selon le mode de réalisation choisi et exposé, la première structure de données, inclut en outre pour chaque application chargée dans l'environnement graphique (GUI_AM) un lien vers une icône graphique représentative de l'application considérée. Dans l'exemple de la figure 4, l'icône de chaque application est représentée dans le coin supérieur gauche de la fenêtre correspondant à chacune 15 des Widgets : en particulier ICI et IC2 respectivement pour les Widgets "instant Messaging" et "Agenda". En pratique, la structure de données L1 peut être implémentée sous la forme d'une liste ou d'un tableau de données. Le tableau 1 ci-dessus illustre un exemple de structure de données L1. 20 Widget Type Donnée URL Fonctionnalité Icône ID Entrée 101 postalAddress http://domain.com/Map/search.php http://domain.com/Map/ mapSearch.gif 102 emailAddress httpi/domain.com/Directory/search http://domain.com/Directory/ .php search.gif Tableau 1 : Structure de données L1 La structure de données L1 représentée dans le Tableau 1, correspond à deux 25 applications Web chargées dans l'environnement graphique, identifiées respectivement par les nombres 101 et 102, et acceptant comme type de données d'entrée, respectivement le type "postalAddress" (type d'adresse postale) et le type "emailAddress" (type d'adresse email). Dans cet exemple, les fonctionnalités de chacune des applications est accessible via un hyperlien Web (URL - Uniform 30 Resource Locator), de même que l'icône graphique qui les représente. Les informations mémorisées dans ce tableau sont obtenues par lecture du code XHTML de chaque application Web, comme illustré en annexe 1, le type de donnée d'entrée et l'URL d'accès à la fonctionnalité étant lus dans la partie "définition". De retour à la figure 3, l'étape E3 précitée est suivie de l'étape E4 au cours de laquelle il est procédé à la détermination de modules d'extraction de données, destinés à déterminer, pour chaque type de données d'entrée mémorisé dans la première structure de données, L1, un module d'extraction de données adapté à extraire le type de données considéré, et à mémoriser, dans une seconde structure de données, L2, des informations identifiant chaque module d'extraction de données déterminé. En pratique, selon le mode de réalisation de l'invention choisi, l'agrégateur de Widgets lorsqu'il est chargé, dispose d'une structure de données LO dans laquelle sont mémorisés les identifiants correspondant à l'ensemble des d'extracteurs disponibles pour extraire tous les types de données d'entrée déclarés pour l'ensemble des Widgets susceptibles d'être chargées par celui-ci. Lors du chargement d'une Widget donnée par l'agrégateur, une seconde structure de données, L2, - par exemple une liste ou un tableau de données -, référençant également des extracteurs de données, est mise à jour pour identifier les extracteurs correspondant au(x) type(s) de données acceptés pour la Widget considérée. Ainsi, à un instant donné, la structure de données L2 contient des informations qui constituent un sous-ensemble de celles mémorisées dans la structure de données L0, ces informations consistant aux identifiants des modules d'extraction relatifs aux types de données acceptés uniquement par les Widgets effectivement chargées à l'instant considéré, dans l'agrégateur. Le Tableau 2 ci-après illustre un exemple de structure de données L2 correspondant aux quatre Widgets chargées dans l'environnement graphique représenté à la figure 4. Référence de l'extracteur Type Donnée Entrée getPostalAddress postalAddress getEmailAddress emailAddress getPhoneNumber phoneNumber getDate Date Tableau 2 : Structure de données L230 15 Dans cet exemple, la référence d'un extracteur considéré correspond au nom de la fonction JavaScript permettant de lancer l'extracteur. En variante, cette référence peut être constituée d'une URL. La structure de données L2 est mise à jour en fonction du chargement ou de la fermeture de Widgets dans l'environnement graphique. Ainsi, dans le cas de l'environnement représenté à la figure 4, si la Widget "Agenda" (WIDG2) est supprimée de l'agrégateur, alors la ligne du Tableau 2 correspondant à la référence "getDate" identifiant le module d'extraction du type de données "Date", sera supprimée. De retour à la figure 3, à l'étape E5, l'utilisateur du terminal (UT) déclenche l'exécution d'une fonctionnalité d'une Widget considérée ("première" Widget), chargée dans l'environnement graphique (GUI_AM), par exemple la Widget WIDG1 de la figure 4, qui devient la Widget "courante" (WIDG_C), c'est-à-dire en cours d'utilisation. Dans l'exemple de la figure 4, la fonctionnalité exécutée consiste à engager une communication par messagerie instantanée avec le contact "Nassim". En conséquence, on obtient des données d'exécution de l'application WIDG1 affichées dans la fenêtre de cette application. Ces données d'exécution sont constituées dans cet exemple, des phrases échangées entre l'utilisateur "Me" et l'interlocuteur distant "Nassim". A l'étape E6 qui suit, il est procédé à la sélection de modules d'extractions de données. Dans ce but, le module AT (cf. Fig. 1) de l'agrégateur de Widgets, sélectionne, à partir de la seconde structure de données L2, un ensemble de modules d'extraction de données adaptés à extraire au moins un type de données d'entrée accepté au moins par une seconde application chargée dans l'environnement graphique (GUI_AM) de l'agrégateur. Cette seconde application peut être une application autre que celle en cours d'utilisation (WIDG1), par exemple : WIDG2, WIDG3, WIDG4, mais elle peut également être l'application courante elle-même. La sélection de cet ensemble de modules d'extraction peut consister à sélectionner automatiquement l'ensemble des modules d'extraction de données identifiés dans la structure de données L2, c'est-à-dire l'ensemble des extracteurs relatifs à tous les types de données d'entrée acceptés par l'ensemble des Widgets chargées dans l'environnement graphique, y compris celle en cours d'utilisation (WIDG1). Selon une variante de réalisation, la sélection de l'ensemble de modules d'extraction fait intervenir le choix de l'utilisateur, comme expliqué ci-après. - 2977344 16 Dans un premier temps, il est procédé à l'affichage des types de données identifiés dans la structure de données L2, en relation avec l'interface graphique (fenêtre) de la Widget courante (WIDG1). Par exemple, comme illustré à la figure 4, les types de données peuvent être affichés sous la forme d'une liste DT. 5 Ensuite, l'utilisateur sélectionne un ou plusieurs types de données, au moyen d'un dispositif de pointage tel qu'une souris, en cliquant par exemple sur les informations textuelles affichées dans la liste DT. Sur la figure 3, l'étape (E6) de sélection des modules d'extraction de données est représentée comme succédant à l'étape (E5) d'exécution d'une fonctionnalité de 10 Widget. Toutefois, selon une variante de réalisation, l'étape (E6) de sélection de modules d'extraction de données peut précéder l'étape (E5) d'exécution d'une fonctionnalité, et l'étape E10 est alors suivie directement par l'étape E7 d'application des modules d'extraction. Selon cette variante de réalisation, les modules d'extraction sont alors 15 sélectionnés une fois la Widget chargée par l'agrégateur de Widgets, et les modules sélectionnés restent applicables quelle que soit la fonctionnalité de l'application qui est exécutée. En particulier, les modules d'extraction peuvent être sélectionnés en prenant en compte un historique d'usage d'applications par l'utilisateur ou de sélections passées de modules d'extraction par l'utilisateur. 20 Par ailleurs, à tout moment, l'utilisateur peut décider de lancer une nouvelle application Web dans l'environnement graphique de l'agrégateur, dans ce cas, comme indiqué par la flèche F1, la phase S1 du procédé est à nouveau exécutée depuis l'étape E2 de chargement d'applications. De même, si une application est supprimée de l'environnement graphique, la 25 phase S1 est également exécutée, mais seulement à partir de l'étape E3 de mise à jour de la structure de données L1. A l'étape E7, l'ensemble des modules d'extraction de données sélectionnés est appliqué aux données d'exécution présentées dans l'interface graphique (G_WIDG1) de l'application courante (WIDG1), afin d'extraire des données d'exécution conformes à 30 au moins un type de données d'entrée accepté par au moins une autre application. A l'étape de test E8, si aucune donnée d'exécution de l'application courante (WIDG1) n'est extraite (E8, Non), alors on retourne à l'étape E5, dans l'attente de l'exécution d'une autre fonctionnalité d'application, de la Widget courante ou bien d'une autre Widget qui deviendra à son tour la Widget courante. En revanche, si des 17 données d'exécution de la Widget courante (WIDG1) ont été extraites (E8, Oui) par au moins un des extracteurs de l'ensemble précité, alors on passe à l'étape E9. A l'étape E9, des liens d'exécution sont créés entre les données d'exécution de la première application (WIDG1) qui ont été extraites à l'étape E7, et une ou plusieurs secondes applications chargées dans l'environnement graphique. En d'autres termes, il s'agit de permettre le lancement de fonctionnalités d'une ou plusieurs secondes applications en utilisant comme données d'entrées pour ces secondes applications, les données d'exécution extraites pour la première application, lors de l'étape E7. Plus précisément, les données d'exécution extraites subissent d'abord un marquage graphique. Selon une implémentation choisie, le marquage graphique d'une donnée d'exécution extraite par un module d'extraction, consiste en l'affichage de l'icône graphique représentative de chaque seconde application qui accepte cette donnée d'exécution comme donnée d'entrée. L'icône graphique est obtenue en consultant la structure de données L1 pour la seconde application concernée, identifiée par son identifiant "Widget ID" dans L1, et en chargeant l'hyperlien correspondant. Dans l'exemple de la figure 4, dans la fenêtre relative à la Widget WIDG1 ("Instant Messaging"), trois icônes IC2', IC3', IC4', représentatives respectivement des Widgets "Agenda", "Orange phone" et "Locate" ont été affichées en liaison avec les données d'exécution concernées de la fenêtre associée à l'application WIDG1. Ainsi, l'information textuelle "March, 25th", conforme au type de données d'entrée "Date", est associée graphiquement à l'icône IC2' représentative de l'application "Agenda". On notera ici qu'il se peut qu'une donnée d'exécution d'une application donnée soit conforme à un type de données d'entrée accepté par cette même application. Par exemple une adresse email, conforme au type de données d'entrée "emailAddress", peut apparaître comme information textuelle dans le cadre d'une communication via l'application WIDG1 (Instant Messaging). Dans ce cas, conformément à l'invention, une icône ICI' représentative de l'application WIDG1 apparaitrait affichée à proximité de cette adresse email. Ces "instances" d'icônes graphiques (IC2', IC3', IC4» associées aux données d'exécution de l'application considérée (WIDG1) constituent des liens d'exécutions vers les applications dont elles sont représentatives (WIDG2, WIDG3, WIDG4). En effet, selon l'invention il suffit alors que l'utilisateur effectue une sélection graphique, en cliquant avec sa souris sur l'une de ces icônes, pour qu'une fonctionnalité de l'application correspondante soit exécutée avec, comme données d'entrée, les 18 données d'exécution affichées par la première application qui sont associées à l'icône considérée. Ainsi, à la figure 4, si l'utilisateur clique avec sa souris sur le numéro de téléphone en surbrillance "+33 635353526" ou bien clique directement sur l'icône IC3', alors le numéro précité est composé automatiquement via l'application WIDG3. Si, dans le cas évoqué plus haut, une icône ICI' est présente dans la fenêtre de l'application WIDG1, associée à une donnée d'exécution correspondant à une adresse email par exemple, alors selon l'invention, lorsque l'utilisateur clique sur cette icône ICI' une seconde instance de l'application WIDG1 est lancée automatiquement par l'agrégateur de Widgets dans une nouvelle fenêtre, et une communication par messages instantanés avec un interlocuteur distant correspondant à l'adresse email précitée, peut alors commencer. De retour à la figure 3, l'étape E10 correspond à l'exécution d'une fonctionnalité d'une seconde application WIDGi (i = 1, 2, 3, ou 4), comme expliqué ci-dessus, cette seconde application pouvant également correspondre à une nouvelle instance de la première application. Cette seconde application, dont une fonctionnalité a été lancée, devient donc l'application courante, comme indiqué à l'étape E10 par'WIDG_C = WIDGi'. On retourne alors à l'étape E6, et le processus décrit ci-avant avec la "première application" (WIDG1) peut alors recommencer avec la seconde application (nouvelle application courante). D'un point de vue implémentation matérielle, selon le mode de réalisation décrit plus haut en relation avec la figure 1, les étapes E3 à E10 qui viennent d'être détaillées sont mises en oeuvre dans le module (AM) de gestion d'applications (agrégateur de Widgets), par le module d'analyse et de traitement (AT) et le module de déclenchement d'exécution de fonctionnalités (DEF), lesquels constituent l'unité (WCM) de communication d'applications Web. Selon un second mode de réalisation matérielle, les étapes E3 à E10 précitées sont mises en oeuvre par l'exécution d'instructions de programme incluses dans le code programme de chaque application Web chargée par le module (AM) de gestion d'applications. A cet effet, des applications Web selon l'invention incorporent chacune une instance de l'unité de communication d'applications Web (WCM), comprenant un module d'analyse et de traitement (AT) et un module de déclenchement d'exécution de fonctionnalités (DEF), sous forme de fonctions JavaScript. Dans ce mode de réalisation, chaque Widget crée ses propres structures de données L1, L2 décrites plus - 2977344 19 haut, et les met à jour en fonctions d'informations reçues de la part des autres Widgets chargées par l'agrégateur. Plus précisément, lorsqu'une Widget est chargée par l'agrégateur, l'unité WCM de la Widget considérée lit les fonctionnalités dont elle dispose. Ensuite, l'unité WCM 5 de la Widget considérée vérifie la présence ou non d'autres Widgets chargées dans l'agrégateur, qui incorporent également une unité WCM. En pratique, chaque Widget chargée dans l'agrégateur est incorporée dans un objet graphique connu sous le terme iFrame. La liste de ces objets iFrame est chargée dans la page XHTML correspondant à l'agrégateur de Widgets, et est accessible par la 10 ligne de code "window.frames" qui retourne un tableau d'objets iFrame. Pour vérifier la présence d'autres Widgets incorporant une unité WCM, chaque Widget selon l'invention dispose d'une fonction JavaScript qui parcourt la liste des objets iFrame et teste, dans chaque objet, la présence d'une variable identifiant l'unité WCM. Lorsque des Widgets incorporant une unité WCM ont été identifiées par une 15 Widget considérée, chargée dans l'agrégateur, cette dernière transmet la liste des fonctionnalités dont elle dispose aux autres Widgets comportant une unité WCM, et reçoit en retour, de la part de ces Widgets, leur liste de fonctionnalités respective. Ayant reçu la liste des fonctionnalités des autres Widgets, la Widget considérée peut alors mettre à jour sa structure de données L1. 20 Ainsi, chaque Widget (équipée d'une unité WCM) dispose d'une structure de données L1 à jour, et peut alors mettre à jour une structure de données L2 relative aux modules d'extraction de données pertinents vis-à-vis des données d'entrée acceptées par les Widgets chargées dans l'environnement graphique. Ensuite, si un lien d'exécution tel que défini précédemment doit être établi entre une première et une 25 seconde Widget, les données extraites du contenu d'exécution de la première Widget sont transmises par l'unité WCM de la première Widget à l'unité WCM de la seconde Widget qui déclenche alors l'exécution d'une fonctionnalité avec les données reçues. Enfin, lorsqu'une Widget est supprimée de l'agrégateur, l'unité WCM de la Widget considérée transmet une information relative à sa suppression aux autres 30 Widgets chargées dans l'environnement graphique de l'agrégateur, qui mettent à jour en conséquence leurs structures de données respectives L1 et L2. Dans ce mode de réalisation, on peut prévoir de mettre en ceuvre un serveur ou un équipement intermédiaire, entre le (ou les) serveur(s) d'applications SVR (figure 1) et des terminaux utilisateurs (UT), de manière à incorporer automatiquement dans des 35 applications Web standards, qui sont en cours de téléchargement, des modules de code de programmes adaptés à mettre en oeuvre un procédé de création de liens d'exécution selon l'invention, lorsque ces applications modifiées conformément à l'invention sont chargées par un agrégateur d'applications Web standard.5 ANNEXE 1 Locate 25 ANNEXE 2 Function extract(dataSource) DEBUT streetkeyWords =['rue', 'boulevard', 'avenue'] tocans =['Caen', 'Paris', 'Marseille', 'Lyon',_] listMots =transformation en mots(dataSource) Parcourir 1istMots DEBUT Mot=listMots[i] Si mot est une valeur numérique Alors DEBUT Si 1istMots[i+1]présent dans streetKeyWords DEBUT streetName=listMots[i+2] Si listMots[i+3] present dans tocans DEBUT Adresse détectée Il suffit alors de reformater dataSource pour étiqueter cette adresse FIN FIN FIN i=i+1 FIN FIN REVENDICATIONS1. Procédé de création d'un lien d'exécution entre une première application Web (WIDG1) et au moins une seconde application Web (WIDG2) aptes à présenter respectivement des données d'exécution au moyen d'une interface graphique respective (G_WIDGI,G_WIDG2) incluse dans un environnement graphique (GUI_AM), le procédé comportant, lors du chargement (E2) de chacune desdites applications par un module (AM) de gestion d'applications, la mémorisation (E3) dans une première structure de données (L1) d'informations identifiant, d'une part, la ou les fonctionnalités fournies par l'application considérée, et d'autre part, l'ensemble des types de données d'entrée acceptés pour exécuter chaque fonctionnalité de l'application considérée ; le procédé étant caractérisé en ce qu'il comporte en outre des étapes de : - (A) détermination (E4, E6), parmi des données d'exécution obtenues par l'exécution (E5) d'au moins une fonctionnalité associée à ladite première application (WIDG1), de celles qui sont conformes à au moins un type de données d'entrée identifié dans ladite première structure de données (L1) ; - (B) déclenchement (E7, E8, E9, E10) de l'exécution d'au moins une fonctionnalité d'au moins une seconde application (WIDG2) en appliquant au moins une donnée d'exécution de la première application, déterminée à l'étape (A), comme donnée d'entrée pour ladite au moins une seconde application. 2. Procédé selon la revendication 1, comprenant préalablement à l'étape de détermination (A), une étape de détermination (E4), pour chaque type de données d'entrée mémorisé dans ladite première structure de données (L1), d'un module d'extraction de données adapté à extraire le type de données considéré, et de mémorisation (E4), dans une seconde structure de données (L2), d'informations identifiant chaque module d'extraction de données déterminé ; ladite étape de détermination (A) incluant des opérations de : - sélection (E6), à partir de ladite seconde structure de données (L2), d'un ensemble de modules d'extraction de données adaptés à extraire au moins un type de données d'entrée accepté au moins par une seconde application (WIDG2) ; application (E7) dudit ensemble de modules d'extraction de données sélectionné, aux données d'exécution présentées dans l'interface graphique (G_WIDG1) de ladite première application (WIDG1), pour extraire (E8) des donnéesd'exécution conformes à au moins un type de données d'entrée accepté par ladite au moins une seconde application (WIDG2). 3. Procédé selon la revendication 2, dans lequel l'opération de sélection d'un ensemble de modules d'extraction de données, comprend : - l'affichage de types de données d'entrée, obtenus à partir de ladite seconde structure de données (L2), en relation avec l'interface graphique (G_WIDG1) de ladite première application ; et, - la sélection graphique par l'utilisateur, via un dispositif de sélection graphique, d'au moins un type de données d'entrée affiché, le module d'extraction de données correspondant étant alors sélectionné. 4. Procédé selon la revendication 2, dans lequel l'opération de sélection d'un ensemble de modules d'extraction de données, consiste à sélectionner automatiquement l'ensemble des modules d'extraction de données identifiés dans ladite seconde structure de données (L2). 5. Procédé selon l'une quelconque des revendications 2 à 4, dans lequel l'étape de déclenchement de l'exécution (B) d'au moins une fonctionnalité d'au moins une seconde application (WIDG2) en appliquant au moins une donnée d'exécution de la première application (WIDG1) comme donnée d'entrée pour ladite au moins une seconde application, comprend : - le marquage graphique des données d'exécution de la première application qui ont été extraites suite à l'application dudit ensemble de modules d'extraction de 25 données; - la sélection graphique par l'utilisateur via un dispositif de pointage prédéfini d'au moins une donnée d'exécution marquée ; - en réponse à la sélection d'au moins une donnée d'exécution marquée, l'exécution d'au moins une fonctionnalité d'au moins une seconde application avec au 30 moins une donnée d'exécution sélectionnée, comme donnée d'entrée pour chaque fonctionnalité exécutée. 6. Procédé selon la revendication 5, dans lequel ladite première structure de données (L1) inclut en outre pour chaque application chargée dans l'environnement 35 graphique (GUI_AM) un lien vers une icône graphique représentative de l'applicationconsidérée, et dans lequel le marquage graphique d'une donnée d'exécution extraite par un module d'extraction, comprend l'affichage de l'icône graphique correspondant à chaque seconde application qui accepte ladite donnée d'exécution extraite comme donnée d'entrée. 7. Procédé selon la revendication 1, dans lequel lesdites étapes de détermination (A) et de déclenchement d'exécution (B), sont mises en oeuvre par ledit module (AM) de gestion d'applications. 10 8. Procédé selon la revendication 1, dans lequel lesdites étapes de détermination (A) et de déclenchement d'exécution (B), sont mises en oeuvre par l'exécution d'instructions de programme incluses dans le code programme de chaque application Web chargée par le module (AM) de gestion d'applications. 15 9. Dispositif de création d'un lien d'exécution entre une première application Web (WIDG1) et au moins une seconde application Web (WIDG2) aptes à présenter respectivement des données d'exécution au moyen d'une interface graphique respective (G_WIDGI,G_WIDG2) incluse dans un environnement graphique (GUI_AM), ledit dispositif comportant un module (AM) de gestion d'applications adapté 20 à charger des applications Web dans un environnement graphique, et des moyens pour mémoriser dans une première structure de données (L1), lors du chargement de chacune desdites applications, des informations identifiant, d'une part, la ou les fonctionnalités fournies par l'application considérée, et d'autre part, l'ensemble des types de données d'entrée acceptés pour exécuter chaque fonctionnalité de 25 l'application considérée ; le dispositif étant caractérisé en ce qu'il comporte en outre : - des moyens d'analyse et de traitement, adaptés à déterminer, parmi des données d'exécution obtenues par l'exécution d'au moins une fonctionnalité associée à ladite première application (WIDG1), celles qui sont conformes à au moins un type de données d'entrée identifié dans ladite première structure de données (L1) ; 30 - des moyens de déclenchement de l'exécution d'au moins une fonctionnalité d'au moins une seconde application (WIDG2) en appliquant au moins une donnée d'exécution de la première application, déterminée par lesdits moyens d'analyse et de traitement, comme donnée d'entrée pour ladite au moins une seconde application.5 10. Dispositif selon la revendication 9, dans lequel lesdits moyens d'analyse et de traitement incluent : - des moyens de détermination de modules d'extraction, destinés à déterminer, pour chaque type de données d'entrée mémorisé dans ladite première structure de données (L1), un module d'extraction de données adapté à extraire le type de données considéré, et à mémoriser, dans une seconde structure de données (L2), des informations identifiant chaque module d'extraction de données déterminé ; - des moyens de sélection destinés à sélectionner, à partir de ladite seconde structure de données (L2), un ensemble de modules d'extraction de données adaptés à extraire au moins un type de données d'entrée accepté par au moins une seconde application (WIDG2) ; - des moyens d'extraction de données d'exécution, pour appliquer ledit ensemble sélectionné de modules d'extraction de données, aux données d'exécution présentées dans l'interface graphique (G_WIDG1) de ladite première application (WIDG1), et pour extraire des données d'exécution conformes à au moins un type de données d'entrée accepté par ladite au moins une seconde application (WIDG2). 11. Dispositif selon la revendication 10, dans lequel lesdits moyens de déclenchement de l'exécution d'au moins une fonctionnalité, incluent : - des moyens de marquage graphique des données d'exécution de la première application qui ont été extraites suite à l'application dudit ensemble de modules d'extraction de données ; - des moyens pour déclencher, en réponse à la sélection graphique par un utilisateur d'au moins une donnée d'exécution marquée, l'exécution d'au moins une fonctionnalité d'au moins une seconde application avec au moins une donnée d'exécution sélectionnée, comme donnée d'entrée pour chaque fonctionnalité exécutée. 12. Terminal de communication (UT) comportant un dispositif de création d'un lien d'exécution entre applications Web, selon l'une quelconque des revendications 9 à 11. 13. Produit programme d'ordinateur comprenant des instructions de programme adaptées à mettre en oeuvre un procédé de création d'un lien d'exécutionentre applications Web, selon l'une quelconque des revendications 1 à 8, lorsque ce programme est chargé et exécuté par un processeur. 14. Application Web stockée sur un support d'informations ou téléchargeable via un réseau de communication incluant des instructions de programme adaptées à mettre en ceuvre un procédé de création d'un lien d'exécution entre applications Web, selon l'une quelconque des revendications 1 à 8.10