Brevet FR2950716A1 — publié le 20110401

Procédé de communication entre applications exécutées dans des navigateurs distincts La présente invention concerne un procédé permettant de faire dialoguer et/ou interopérer des applications Web indépendantes, exécutées simultanément dans un 5 premier et au moins un deuxième navigateur Web. L'invention permet ainsi à une première application Web exécutée dans un premier navigateur Web, d'exécuter certaines opérations en réaction à des services mis en oeuvre par au moins une deuxième application exécuté dans un deuxième navigateur. 10 Pour être exécutées, de telles applications web sont généralement hébergées dans une page web développée d'une façon modulaire à partir d'une pluralité de modules distincts et indépendants plus communément appelés "portlets", "widgets" ou "gadgets". De tels modules ou portlets, aptes à servir de conteneur dans une page Web 15 pour l'exécution et/ou l'affichage d'applications Web, sont notamment utilisés dans des développements de services ou d'applications du type Web 2.0, par exemple en s'appuyant sur les techniques AJAX (pour "Asynchronous JavaScript And )(MU - ou " XML et Javascript asynchrones "). A titre informatif, AJAX désigne une méthode informatique de 20 développement d'applications Web. Il ne s'agit aucunement d'une technologie en elle-même, mais simplement d'un terme qui évoque l'utilisation conjointe d'un ensemble de technologies couramment utilisées sur le web, à savoir notamment : ^ le langage HTML (pour "HyperText Markup Language"), ou le langage XHTML (pour "Extensible HyperText Markup Language") pour ce qui 25 concerne la définition de la structure sémantique des informations contenues dans une page web ; ^ le modèle DOM (pour "Document Object Model" en anglais "Modèle objet de document" en français), et JavaScript pour afficher et interagir dynamiquement avec l'information présentée. DOM est une recommandation du W3C qui 30 permet notamment de décrire une interface indépendante de tout langage de programmation et de toute plate-forme et qui pet met à des programmes informatiques et à des scripts d'accéder ou de mettre à jour le contenu, la ^ structure ou le style de documents ; ^ le langage JavaScript (marque déposée), dont l'objet XMLHttpRequest qui caractérise le coté asynchrone d'Ajax, notamment et non exclusivement, pour ce qui concerne l'échange et la manipulation, des données avec un serveur Web. Cet objet permet notamment d'obtenir des données au format XML, mais aussi au format HTML, ou plus simplement encore au format texte, par l'invocation de simples requêtes de type HTTP (pour "Hypertext Transfer Protocol" en anglais, ou "protocole de transfert hypertexte" - protocole de communication client-serveur développé pour le World Wide Web). Or, si de telles portlets permettent de faire cohabiter plusieurs composants applicatifs (encore appelés dans la suite et pour raison de simplification, applications) au sein d'une même page Web, et ceci de façon personnalisable (en termes de graphisme, d'agencement, etc.), elles présentent cependant pour principal inconvénient de ne pas permettre une connexion et/ou une interopérabilité entre plusieurs applications Web hébergées chacune dans des portlets exécutées dans des navigateurs distincts, de sorte qu'il n'est pas possible, par exemple, de faire réagir dynamiquement une première application exécutée dans un premier navigateur à l'exécution d'un service mis en oeuvre par une deuxième application (ou "portlets") exécutée dans un deuxième navigateur. Par service, le lecteur comprendra toute fonction applicative susceptible de générer en sortie au moins une valeur de paramètre (une valeur d'évènement ou de données, par exemple et de façon non limitative), une telle valeur de paramètre étant susceptible de servir de paramètre d'entrée pour l'exécution d'une opération (un autre service, un processus, etc.) mise en oeuvre et exécutée par une autre application hébergée dans une même, ou une autre page web (par exemple, une page d'un portail web). Pour tenter de pallier cet inconvénient, les inventeurs ont proposé dans la demande de brevet WO2008152296 un procédé de communication inter-portlets basé sur une action de "glisser/ déposer", ou "drag and drop" en anglais, lequel permet à un utilisateur de sélectionner une donnée générée en sortie d'un premier service applicatif exécuté dans une première portlet, avant de faire glisser cette donnée sélectionnée vers un champ d'un deuxième service applicatif exécuté dans une autre portlet, pour déclencher l'exécution de ce deuxième service, en tenant compte de la donnée sélectionnée ayant fait l'objet de l'action de "glisser/ déposer". Un inconvénient de cette dernière technique est lié au fait qu'elle limite l'interopérabilité à des applications Web exécutées uniquement dans différentes portlets hébergées d'une même page HTML d'un même navigateur Web. Or, de nombreux contextes d'utilisation, le plus souvent liés au fait qu'un même utilisateur possède plusieurs terminaux de différentes catégories (téléphone mobile, assistant personnel numérique, terminal PC, télévision numérique, etc.), nécessiteraient d'étendre l'interopérabilité à des applications Web qui seraient exécutées dans des navigateurs Web distincts, ces derniers pouvant également être exécutés soit sur un même terminal (deux instances distinctes d'un navigateur), soit sur des terminaux distincts appartenant à un même utilisateur (terminal PC, terminal mobile, terminal TV, etc.), voir à une communauté d'utilisateurs. A cet effet, l'invention concerne un procédé de communication entre une première application et au moins une deuxième application, lesdites première et deuxième applications étant respectivement exécutées dans un premier et deuxième navigateur Internet. Selon l'invention, un tel procédé comprend : ^ une étape d'activation d'un canal de communication unique entre lesdits premier 20 et deuxième navigateurs ; ^ une étape de souscription dynamique de ladite première application à au moins un service de ladite au moins une deuxième application, par l'intermédiaire dudit canal de communication ; ^ une étape d'exécution par ladite première application, d'au moins une opération 25 tenant compte d'une valeur d'au moins un paramètre généré par l'exécution dudit au moins un service, ladite valeur étant transmise par ladite deuxième application à ladite première application par l'intermédiaire dudit canal de communication. Un tel procédé permet donc avantageusement de favoriser l'interopérabilité 30 dynamique et la communication/ l'échange d'informations entre applications Web (portlets) hébergées respectivement dans des pages Web distinctes, affichées par différents navigateurs exécutés respectivement, soit sur un même terminal, soit sur des terminaux distincts et/ ou indépendants. Une telle approche permet ainsi d'étendre le service offert à l'usager en lui donnant la possibilité de combiner l'exécution de différentes applications Web hétérogènes, ou tout le moins développées de façon indépendantes les unes des autres. Elle offre en outre à un même utilisateur, voir à des groupes d'utilisateurs appartenant à une même communauté d'utilisateurs, de nouvelles possibilités de manipulation et d'interaction entre des services proposés par des applications qui seraient exécutées simultanément auxquelles il peut accéder dans une même page web d'un navigateur, beaucoup plus intuitive. En effet, de part la mise en ceuvre d'un mécanisme de souscription d'une première application à au moins un service offert par au moins une autre application hébergées toutes deux dans une même page Web, il devient possible de créer un lien de communication entre des applications Web exécutées à l'intérieur d'au moins deux instance distinctes d'un navigateur Internet, ces dernières étant exécutées sur un même terminal ou sur des terminaux distinct, par exemple un premier terminal du type téléphone mobile et, un deuxième du type terminal PC. Grâce à ce lien de communication établi dans un canal de communication dédié, ces applications vont ainsi pouvoir "se connaître" et donc par suite, interopérer au bénéfice d'un ou plusieurs utilisateurs. A titre informatif, la valeur du paramètre générée par l'exécution dudit service de la deuxième application pourra être représentative d'un évènement ou d'une donnée susceptible de servir de paramètre d'entrée pour l'exécution de ladite opération. Dans un mode de réalisation avantageux de l'invention, ledit procédé comprend les étapes préalables: d'activation d'un premier module de communication apte à gérer des communications impliquant des applications exécutées à l'intérieur dudit premier navigateur Internet; et - d'activation d'un deuxième module de communication apte à gérer des communications impliquant des applications exécutées à l'intérieur dudit 30 deuxième navigateur Internet. L'activation de tels modules permet notamment : - de connaître en temps réel les différentes applications chargées par l'utilisateur dans un premier navigateur et dans un deuxième navigateur distinct. Le transfert d'informations entre applications Web hébergées à l'intérieur de pages web publiées par le premier et le deuxième navigateur, respectivement, s'effectue alors directement et dynamiquement entre ces dernières, dès lors qu'elles ont souscrites respectivement au(x) service(s) (évènements et/ou données générés) d'au moins une autre application. Ainsi, un autre avantage de cette approche selon l'invention, provient du fait qu'elle n'implique pas que l'utilisateur connaisse à l'avance l'opération à réaliser entre les premières et deuxième applications, ce qui favorise la simplicité d'usage et le caractère intuitif de l'utilisation des différents services qui lui sont proposés. Dans un mode de réalisation possible de l'invention, ledit procédé comprend suite auxdites étapes d'activation, des étapes de connexion respectives desdits premier et deuxième modules de communication audit canal de communication, par l'intermédiaire d'une entité de gestion de canaux de communication. Cette étape s'avère particulièrement intéressante en ce qu'elle permet de maintenir actif entre les premier et deuxième modules de communication, un lien de communication, sur le temps d'une session, c'est-à-dire d'exécution d'au moins un navigateur, par exemple un navigateur Internet. Préférentiellement, un tel procédé selon l'invention comporte une étape de transmission par ladite deuxième application audit deuxième module de communication, d'une première liste associant à chaque service proposé par ladite deuxième application, au moins un type de paramètre dont une valeur sera générée à l'exécution dudit service. Dans un mode de réalisation avantageux de l'invention, ladite étape de souscription comprend les sous-étapes suivantes de : ^ enregistrement de ladite première application auprès dudit deuxième module de communication, par l'intermédiaire dudit canal de communication ; ^ transmission par ladite première application audit deuxième module, d'une 30 deuxième liste de paramètres associés, respectivement, à au moins une opération susceptible d'être exécutée par ladite première application; ^ création par ledit deuxième module d'une troisième liste de souscription de services propre de ladite première application, laquelle associe à chaque service de ladite première liste au moins une opération susceptible d'être exécutée par ladite première application, par mise en correspondance des types de paramètre contenus respectivement dans lesdites premières et deuxièmes listes. Selon l'invention, la création de cette liste de souscription de services propre de ladite première application permet au deuxième module associée à la deuxième application, de ne transmettre par l'intermédiaire dudit canal de communication, que des données ou évènements issus de l'exécution de ladite deuxième application et susceptibles de constituer un paramètre d'entrée pour l'exécution de ladite première application. Ces étapes du procédé de communication selon l'invention sont donc particulièrement importantes en ce qu'elles permettent une mise en correspondance, au niveau de chacun des modules de communication activés, de chaque service de ladite première liste avec au moins une opération susceptible d'être exécutée par ladite première application. La mise en correspondance s'effectue entre les types de paramètres (données ou évènements) répertoriés respectivement dans lesdites premières et deuxièmes listes. Une telle liste, laquelle se met à jour de manière dynamique en fonction des connexions/ déconnexions d'applications dans la page Web et en fonction des souscriptions/ dé souscriptions à des services, permet de créer un lien de communication entre les différentes applications hébergées et exécutées dans une même page Web, sans que ces dernières n'aient eu préalablement à se connaître et sans que ces dernières n'aient été développées spécifiquement pour pouvoir interagir et/ou interopérer entre les unes avec les autres, ce qui constitue un avantage certain propre à la présente invention. Avantageusement, cette troisième liste sert de base au déclenchement d'une opération (service ou processus, etc.) exécutée par la première application, sur la base de la génération d'une valeur de donnée et/ou d'évènement par un service de la deuxième application. Pour une sécurisation accentuée des communications entre les première et deuxième applications qui ne se "connaissent" pas à la base, des critères de sélection et/ou de contrôle des paramètres échangés entre les première et deuxième applications pourront être vérifiés par l'entité de gestion, voir dans un mode de réalisation possible, par la première application, pour conditionner l'exécution de ladite opération à une vérification préalable desdits critères précités. Dans une variante possible de réalisation de l'invention, ladite étape de souscription entre lesdites premières et deuxième applications est matérialisé par un élément d'une interface homme machine propre à ladite deuxième application au moyen duquel un utilisateur de ladite deuxième application peut interagir pour déclencher l'exécution de ladite opération par l'intermédiaire de ladite première application et dudit canal de communication. Ainsi, un utilisateur disposera en outre de la possibilité de déclencher lui-même l'exécution d'une opération propre de la première application, en interagissant avec un élément de l'interface homme-machine (MM) propre de la deuxième application et représentatif de la première, ce qui tend à favoriser encore un peu plus le caractère intuitif de l'interopérabilité entre applications mis à la disposition de l'utilisateur. Avantageusement, préalablement à ladite étape d'exécution, il comprend une étape de transmission par ledit deuxième module de communication audit premier module de communication d'au moins un message de déclenchement dynamiquement d'une exécution de ladite opération par ladite première application, ledit message étant transmis suite à l'exécution dudit service par ladite deuxième application au travers ledit canal de communication unique. Dans une variante possible de mise en oeuvre de l'invention, ledit message est du type appel de fonction à distance tenant compte d'une valeur dudit paramètre généré à l'exécution du service propre de ladite deuxième application. Une telle approche technique a pour avantage de facilité la mise en oeuvre du lien de 25 communication entre les différentes applications exécutées sur une même page Web, ou sur des pages Web distinctes. Il est bien entendu possible d'imaginer tout autre type de modalité de mise en oeuvre du lien de communication, par exemple en s'appuyant sur des fonctions de communication de type Flash (marque déposée) ou Java (marque déposée). 30 Un tel procédé de communication selon l'invention permet ainsi de maintenir un lien de communication entre lesdites première et deuxième applications, de façon à déclencher l'exécution de ladite opération au niveau de ladite première application, suite à l'exécution dudit service par ladite deuxième application. Ce lien de communication est maintenu actif entre les premiers et deuxième modules de communication associés respectivement au premier et deuxième navigateur entre les première et deuxième applications, de telle sorte que suite à la génération d'une nouvelle valeur de paramètre (donnée ou évènement) par un service de la deuxième application, une commande correspondante de déclenchement d'au moins une opération (un processus, un service, etc.) tenant compte de ladite nouvelle valeur, sera transmise par l'intermédiaire dudit canal de communication et des premier et deuxième modules, à la première application. Une telle approche permet ainsi avantageusement de favoriser une interopérabilité entre applications hébergées dans des portlets/ applications web distinctes exécutées à l'intérieur de pages web affichées par des navigateurs distincts, alors même que celles-ci ont été développées indépendamment l'une de l'autre. Un tel procédé selon l'invention permet donc avantageusement de favoriser l'interopérabilité dynamique et la communication/ l'échange d'informations entre des applications Web (portlets) hébergées respectivement dans des pages web distinctes (par exemple du type pages HTML) exécutées respectivement sur un premier et au moins un deuxième navigateur distincts. Ces navigateurs distincts pourront indifféremment être exécutés sur un même terminal (exécution de deux instances distinctes de navigateur) ou bien sur des terminaux distincts connectés l'un à l'autre par l'intermédiaire d'au moins un réseau de communication. Une telle interopérabilités permet d'étendre les services offerts à l'utilisateur, en créant un lien de communication entre portlets ou applications Web exécutées dans des navigateurs distincts pouvant être exécutés eux-mêmes sur des terminaux distincts, de façon que des données ou évènements générés par l'exécution d'une application, puissent être automatiquement utilisés en tant que paramètres d'entrée d'une autre application exécutée dans un autre navigateur d'un même ou d'un autre terminal. Elle offre en outre à l'utilisateur des possibilités de manipulation et d'interaction avec les services proposés par chacune des applications auxquelles il peut accéder, de façon beaucoup plus intuitive. En effet, de part la mise en oeuvre d'un mécanisme de souscription d'une première application à au moins un service offert par au moins une autre application exécutées respectivement dans des navigateurs distincts, il devient possible de créer un lien de communication entre au moins certaines de ces applications. Grâce à ce lien de communication, ces applications vont pouvoir "se connaître" et ainsi interopérer, au bénéfice de l'utilisateur. En particulier, une fois réalisée l'étape de souscription de la première application à au moins un service d'au moins une deuxième application, ladite première application sera apte à déclencher automatiquement l'exécution d'une opération prédéterminée qui tiendra compte d'une valeur d'au moins une donnée mise à jour par l'exécution dudit au moins un service fourni par ladite deuxième application. Cette valeur de donnée de type prédéterminée générée par un service de la deuxième application sera en effet communiquée dynamiquement par cette dernière à la première application ayant préalablement souscrit au service, avant d'être prise en compte par cette dernière qui déclenchera l'exécution d'une opération spécifique en tenant compte de cette valeur comme paramètre d'entrée. Le transfert d'informations entre applications Web hébergées dans des navigateurs distincts s'effectue alors directement et dynamiquement entre ces dernières, dès lors qu'elles ont souscrites respectivement au(x) service(s) (évènements et/ou données générés) d'au moins une autre application, par l'intermédiaire du canal de communication établi entre le premier module de communication associé à la première application et le deuxième module de communication associé à la deuxième application. Ainsi, un autre avantage de cette approche selon l'invention, provient du fait qu'elle n'implique pas que l'utilisateur connaisse à l'avance l'opération à réaliser entre ladite première portlet (application web) et ladite deuxième portlet (application web), ce qui favorise la simplicité d'usage et le caractère intuitif de l'utilisation des différents services qui lui sont proposés. Il est bien entendu possible d'envisager sans limitation aucune, toutes autres 30 combinaisons des caractéristiques précitées propres du procédé de communication selon l'invention; de telles autres combinaisons entreront dans le champ de lé protection demandée. L'invention concerne également un système de communication entre une première application et au moins une deuxième application, lesdites première et deuxième applications étant respectivement exécutées dans un premier et deuxième navigateur Internet. Avantageusement, ledit système comprend : ^ des moyens d'activation d'un canal de communication unique entre lesdits premier et deuxième navigateurs ; ^ des moyens de souscription dynamique de ladite première application à au moins un service de ladite au moins une deuxième application, par 10 l'intermédiaire dudit canal de communication ; ^ des moyens d'exécution par ladite première application, d'au moins une opération tenant compte d'une valeur d'au moins un paramètre généré par l'exécution dudit au moins un service, ladite valeur étant transmise par ladite deuxième application à ladite première application par l'intermédiaire dudit 15 canal de communication. L'invention concerne aussi un produit programme d'ordinateur téléchargeable depuis un réseau de communication et/ou stocké sur un support d'information lisible par ordinateur et/ou exécutable par un microprocesseur, comprenant des instructions de code pour l'exécution d'un procédé de communication tel que celui mentionné ci- 20 dessus, lorsqu'il est exécuté sur un ordinateur. Les caractéristiques et avantages techniques de la présente invention ressortiront mieux de la description suivante, faite à titre indicatif et non limitatif, au regard des dessins annexés sur lesquels : ^ la figure 1 est ordinogramme résumant les grandes étapes du procédé de 25 communication selon l'invention ; ^ la figure 2 décrit le principe de la souscription/ communication entre des applications hébergées/ exécutées respectivement à l'intérieur dans des navigateurs distincts exécutés sur des terminaux distincts; ^ les figures 3 et 4 présentent un exemple d'interface d'activation d'un module de 30 communication pour la communication inter applications hébergées/ exécutés dans des navigateurs distincts. La présente invention propose une solution favorisant la communication et l'échange d'information, et donc l'interopérabilité dynamique entre applications Web. On décrit ci-après de façon détaillée, un mode de réalisation possible de l'invention. Dans le cadre de la présente invention, une application hébergée dans une page Web possède un cycle de vie pouvant se résumer de la façon suivante : une première phase d'initialisation de ladite application essentiellement basée sur les trois étapes suivantes : o se faire connaître par les autres applications (encore dénommées portlets) hébergées dans une même page Web, ou sur des pages Web distinctes, et rattachées respectivement à une même session û par session, on entend une période d'activation d'au moins deux navigateurs distincts, soit activés simultanément sur un même terminal, soit exécuté simultanément sur des terminaux distincts d'un même utilisateur et reliés entre eux par l'intermédiaire d'un canal de communication unique propre de ladite session; o souscrire aux services d'autres applications susceptibles de générer des valeurs de paramètres (évènement et/ou données) qui l'intéressent; et o connaître les souscriptions des autres applications (les données et évènements auxquels les autres applications peuvent réagir). Cette étape permet de gérer le contexte dans le sens ou chaque application connaît l'ensemble des services qui lui sont liés et qui sont chargés par l'utilisateur. une deuxième phase durant laquelle les différentes applications ayant souscrites aux différents services d'autres applications, peuvent communiquer entre elles selon un mode de publication/ réception d'évènements et/ou de données de type prédéterminé, par l'intermédiaire d'un canal de communication unique, propre de ladite session de communication ; puis une troisième phase initiée lors de la déconnexion ou de l'interruption de l'exécution d'une application à l'intérieur d'une page Web d'un navigateur, de transmission aux autres applications hébergées dans la même page Web ou sur une page Web d'un autre navigateur distinct, d'une information de déconnexion/ interruption, de façon que les applications restant actives puissent mettre à jour leurs informations relatives à des applications qui avaient préalablement souscrits à l'un au moins de leurs services (respectivement) et qui dont l'exécution a été depuis interrompue. Ces différentes phases propres de l'invention sont détaillées ci-dessous dans la suite 5 de la description. On résume ici en relation avec la figure 1, les grandes étapes du procédé de communication entre applications exécutées respectivement dans des portlets hébergées chacune à l'intérieur de pages web gérées par des navigateurs distincts. On résume ici en relation avec la figure 1, les grandes étapes du procédé de 10 communication entre une première application et au moins une deuxième application, lesdites première et deuxième applications étant respectivement exécutées dans un premier et deuxième navigateur Internet. Selon l'invention, un tel procédé comprend : ^ une étape 101 d'activation d'un canal de communication unique entre lesdits 15 premier et deuxième navigateurs ; ^ une étape 104 de souscription dynamique de ladite première application à au moins un service de ladite au moins une deuxième application, par l'intermédiaire dudit canal de communication ; ^ une étape 106 d'exécution par ladite première application, d'au moins une 20 opération tenant compte d'une valeur d'au moins un paramètre généré par l'exécution dudit au moins un service, ladite valeur étant transmise par ladite deuxième application à ladite première application par l'intermédiaire dudit canal de communication. Le procédé selon l'invention comprend les étapes préalables: 25 ^ d'activation 1001 d'un premier module de communication apte à gérer des communications impliquant des applications exécutées à l'intérieur dudit premier navigateur Internet; et ^ d'activation 1002 d'un deuxième module de communication apte à gérer des communications impliquant des applications exécutées à l'intérieur dudit 30 deuxième navigateur Internet. Il comprend également suite auxdites étapes 1001, 1002 d'activation, des étapes 1021, 1022 de connexion respectives desdits premier et deuxième modules de communication audit canal de communication, par l'intermédiaire d'une entité de gestion de canaux de communication. Il comporte encore une étape 103 de transmission par ladite deuxième application audit deuxième module de communication, d'une première liste associant à chaque service proposé par ladite deuxième application, au moins un type de paramètre dont une valeur sera générée à l'exécution dudit service. Ladite étape 104 de souscription comprend les sous-étapes suivantes de : ^ enregistrement 1041 de ladite première application auprès dudit deuxième module de communication, par l'intermédiaire dudit canal de communication ; ^ transmission 1042 par ladite première application audit deuxième module, d'une deuxième liste de paramètres associés, respectivement, à au moins une opération susceptible d'être exécutée par ladite première application; création 1043 par ledit deuxième module d'une troisième liste de souscription de services propre de ladite première application, laquelle associe à chaque service de ladite première liste au moins une opération susceptible d'être exécutée par ladite première application, par mise en correspondance des types de paramètre contenus respectivement dans lesdites premières et deuxièmes listes. Préalablement à ladite étape 106 d'exécution, le procédé selon l'invention comprend une étape 105 de transmission par ledit deuxième module de communication audit premier module de communication d'au moins un message de déclenchement dynamiquement d'une exécution de ladite opération par ladite première application, ledit message étant transmis suite à l'exécution dudit service par ladite deuxième application au travers ledit canal de communication unique. Dans un mode de réalisation possible de l'invention, ledit message est du type appel de fonction à distance tenant compte d'une valeur dudit paramètre généré à l'exécution du service propre de ladite deuxième application. De façon plus détaillée, ladite étape 104 de souscription entre lesdites premières 30 et deuxième applications est matérialisé par un élément d'une interface homme machine propre à ladite deuxième application au moyen duquel un utilisateur de ladite deuxième application peut interagir pour déclencher l'exécution de ladite opération par l'intermédiaire de ladite première application. En cas de désactivation/ activation d'une application dans un navigateur rattachée à une session de communication, le procédé selon l'invention comprend une étape 107 de mise à jour dynamique de ladite troisième liste de souscription de services gérée par ledit deuxième module, suite à la transmission audit deuxième module, par ledit premier module, d'un message de notification d'une déconnexion de ladite première application, par l'intermédiaire dudit canal de communication. Selon l'invention, ladite première application est exécutée dans un premier navigateur exécuté sur un premier terminal et, en ce que ladite deuxième application est exécutée dans un deuxième navigateur exécuté sur un deuxième terminal. Comme illustré sur la figure 2, l'invention consiste à étendre le principe de communication et d'interopérabilité entre des applications Web non plus hébergées à l'intérieur d'une même page web d'un même navigateur Internet, mais hébergées/ exécutées respectivement dans des pages web d'instance distinctes de navigateurs Internet exécutés indifféremment sur un même terminal ou sur des terminaux distincts, voir hétérogènes. Ainsi, de façon non limitative, un service chargé sur une session A d'un navigateur X, peut très bien communiquer/ interopérer avec un autre service, chargé sur une session B d'un navigateur Y ; même si, les deux navigateurs sont chargés sur des machines différentes. Ce mécanisme permet notamment d'implémenter des scenarios du genre : • l'utilisateur final reçoit des vidéos en pièce jointe sur une widget email (chargée sur un PC) et les lit sur une widget player vidéo chargée sur sa télé. ^ ou bien, chercher un contact dans la widget annuaire chargée sur le PC, et le 25 rajouter sur les contacts du téléphone mobile à travers la widget contact chargée sur le mobile. Dans l'exemple de mise en oeuvre de la figure 2, on considère l'établissement de quatre sessions de navigateurs (200, 201, 202, 203) exécutés respectivement sur quatre terminaux (204, 205, 206, 207) pouvant appartenir indifféremment à un même 30 utilisateur, ou à plusieurs utilisateurs. Ces terminaux disposent d'un moyen de connexion à au moins un réseau de communication. Par session d'un navigateur, on entend un période d"exécution/ activation d'une instance d'un navigateur sur un terminal donné. Pour mettre en oeuvre le procédé selon l'invention et comme illustré sur la figure 2, à chaque lancement d'une session d'un navigateur (200, 201, 202, 203) sur un terminal (204, 205, 206, 207), un module de communication (208, 209, 210, 211) spécifique, est activée à l'intérieur du navigateur (200, 201, 202, 203) correspondant. Cette solution consiste donc à rajouter un module de communication se présentant sous la forme d'une application exécutable par un utilisateur à l'intérieur de son navigateur, ou widget spéciale (figure 2) dans l'environnement de l'utilisateur. Cette widget spéciale a pour fonction d'assurer la connexion entre les différentes applications (W l à W7) exécutées respectivement dans le cadre de chaque session des navigateurs 200, 201, 202 et 203, respectivement Les widgets (208, 209, 210, 211) spéciales peuvent être : ^ simple en étant juste un relais entre différentes sessions du même utilisateur (on 15 peut déduire que deux sessions sont du même utilisateur en effectuant une authentification), ^ elles peuvent aussi embarquer une certaine intelligence, permettant à des widgets d'un utilisateur, de communiquer avec les widgets d'un autre utilisateur appartenant à une même communauté virtuelle (réseaux sociaux). 20 Dans ce mode de réalisation nous avons choisi d'illustrer comment faire communiquer des applications chargées sur deux terminaux distincts du même utilisateur. Dans le cadre du procédé selon l'invention, on associe respectivement à chaque application ou widget (W1 à W7), deux identifiants. Le premier identifiant permet 25 d'identifier un widget de façon unique à l'intérieur d'une session propore d'un navigateur donnée. Le deuxième identifiant permet d'identifier la session du navigateur à laquelle elle se rattache. Ces l'association de ces deux identifiants permet d'identifier de manière unique une application web (ou widget) au sein des différentes sessions de navigateur, de 30 façon à pouvoir faciliter leur interopérabilité/ communication, par l'intermédiaire de canaux 212 de communications uniques établis par l'intermédiaire d'un réseau de communication et d'une entité de gestion de canaux de communication inter modules de communication, entité située côté serveur 213 de gestion communications inter applications. Les applications W 1 à W7 (exemple de la figure 2) sont situées côté 214 clients. La solution proposée offre aussi une API qui permet même le développement 5 d'applications ou de services qui communiquent à travers des sessions différentes propres de navigateurs distincts chargées sur un ou plusieurs terminaux. Les communications entre applications exécutées dans des navigateurs distincts s'effectue par l'intermédiaire des modules de communication (ou widgets spéciales) respectivement activées relativement à chaque session d'un navigateur donné et par 10 l'intermédiaire de canaux de communication établis respectivement entre un premier module de communication propre d'une session d'un premier navigateur et, un deuxième module de communication propre d'une session d'un deuxième navigateur. Ainsi, dans l'exemple de la figure 2, un premier utilisateur d'un terminal PC1 204 a chargé/ exécuté dans un navigateur 200, trois applications ou widgets W1, W2 et 15 W3. Ce même utilisateur (voir un autre distinct) d'un terminal PC2 205 a chargé/ exécuté dans un navigateur 201, deux applications ou widgets W4 et W5. Après activation par cet ou ces utilisateurs, respectivement sur chacun des terminaux 204 et 205, des modules 208 et 209 de communication inter applications (dites widgets 20 spéciales), les applications WI et W5 vont souscrire respectivement aux données et/ou évènements générés par l'exécution de leur(s) service(s) respectif(s), de façon qu'elles puissent ensuite interopérer au bénéfice du ou de leurs utilisateurs, par l'intermédiaire d'un canal 215 de communication spécifiques et unique établis entres mes modules 208 et 209 de communications. 25 Un tel canal 215 de communication est un canal similaire au mécanisme de publish/subscribe. Il permet à une entité logicielle de se souscrire à un type de message, à une autre de publier des messages d'un certain type. Ainsi, l'entité qui est souscrite à un type de message X sera prévenue à chaque fois qu'un message de type X est publié par une autre entité. 30 Les widgets spéciales, encore appelés modules de communication propre d'une session d'un navigateur, se souscrivent à des types de message sur l'entité «canal de communication. ». Au chargement de la widget spéciale, et après authentification de l'utilisateur «USER ID », elle effectue un certain nombre de souscription auprès du canal de communication afin de communiquer avec les autres widgets chargées sur différentes sessions du même utilisateur. La table 1 suivante précise l'ensemble des souscriptions effectuées par la widget spéciale auprès du canal de communication. Canal de souscription Description /USER_ID/subscriptions Ce canal permet à la widget spéciale de recevoir toutes les souscriptions effectuées dans les autres sessions (e.g. si une widget annuaire, chargée sur une autre session, souscrit au type de donnée emailAddress, ce canal permet à la widget spéciale de recevoir cette information, afin de la propager aux autres widgets). Cette information est publiée par une widget spéciale correspondante à la widget qui effectue la souscription à un type de donnée. /USER ID/publications Ce canal permet à la widget spéciale de connaître les données que les autres widgets, présente sur d'autre session, peuvent publier. /USER ID/unsubscriptions Ce canal permet à la widget spéciale de recevoir les demandes de dé-souscription des autres widgets, présentes sur d'autres terminaux. /USER_ID/publish Ce canal permet à la widget spéciale de recevoir une publication d'une autre widget, chargée sur une autre session. /USER ID/synchronizationrequest Une demande de synchronisation est effectuée lorsqu'une widget spéciale souhaite recevoir : la liste des widgets chargée sur une autre session, les donnée et évènements qu'elles génèrent, ainsi que l'ensemble de leurs souscriptions. Ce canal permet donc de recevoir ce type de demande. Table L Une fois que la widget spéciale a effectué l'ensemble de ces souscriptions, débute une phase de découverte de son environnement. Cette phase inclut d'une part la découverte de son environnement local au sein du navigateur auquel elle est associée. Elle débute d'autre part une phase de découverte de l'ensemble des applications hébergées/ exécutées à l'intérieur du navigateur auquel elle est rattachée, leurs publications potentielles, ainsi que leurs souscriptions. Ces informations sont ensuite propagées vers les modules de communication (widgets spéciales) associés au navigateurs exécutés sur d'autres terminaux et connecté audit canal de communication spécifique à l'utilisateur identifié par « USER ID » . Elle débute enfin une phase de découverte de l'environnement des autres sessions : La découverte de l'ensemble de widgets chargées dans les autres sessions, leurs publications potentielles, ainsi que leurs souscriptions. Ces informations sont ensuite propagées vers les autres widgets de la même session. L'étape de phase de découverte de son environnement consiste à récupérer la liste L1 et L2 de chaque widget qui se trouve dans la même session que la widget spéciale. (Rappelons que L1 d'une widget X est la liste des souscriptions de cette widget X, et L2 d'une widget X est la liste des publications potentielles de la widget X). Une fois la widget spéciale ait récupérée ces deux listes de chaque widget, elle les propage vers le canal de communication. Ainsi, la liste LI est publiée dans le canal «/USER ID/subscriptions », et la liste L2 et publiée dans le canal «/USER ID/publications ». L'entité «canal de communication », transmet à son tour, ces deux listes à toutes les entités (typiquement les widgets spéciales) ayant souscrit respectivement aux canaux «/USER ID/subscriptions » et «/USER ID/publications » (i.e. aux widgets spéciales des terminaux du même utilisateur identifié par USER ID). Lorsque les widgets spéciales d'autres sessions reçoivent les listes LI et L2, elles les propagent vers les widgets de la même session. Les widget ordinaire, qui reçoivent ces deux listes LI et L2 mis à jours leurs deux listes L3 et L4. (Rappelons que L3 d'une widget X est la liste des souscriptions d'autre widget aux services que la widget X génère, et L4 d'une widget X est la liste des widgets qui génèrent des services auxquels la widget X est souscrite) La mise à jour de L3 s'effectue en réalisant une mise en correspondance (mapping) entre la liste LI reçue et la liste L2 local ; on détecte si la widget émettrice de la liste LI est souscrite aux services que génèrent la widget réceptrice; si c'est le cas alors rajouter les souscriptions dans la liste L. La mise à jour de L4 s'effectue en faisant le mapping entre la liste L2 reçue et la liste LI local ; on détecte si la widget émettrice de la liste L2 génère des services auxquelles la widget réceptrice est souscrite; si c'est le cas alors rajouter cette widget à la liste L4. A chaque insertion ou suppression d'une souscription dans la liste L3 on enclenche la mis à jours de la couche présentation de la widget en insérant l'icône correspondante à la souscription. La phase de découverte de l'environnement des autres sessions consiste à récupérer l'ensemble des souscriptions, et publications potentielles des applications chargées sur d'autre session. Pour faire ça, la widget spéciale publie une requête dans le canal « /USER ID/synchronizationrequest ». L'entité « canal de communication » transmet cette requête à toutes les widgets spéciales qui sont chargées sur d'autres sessions et qui ont souscrit à ce canal (i.e. le canal /USER ID/synchronizationrequest). Les widgets spéciales qui reçoivent cette requête, irons récupérer les liste, LI et L2 de chaque widget ordinaire qui est chargée dans la même session que cette widget spéciale. Une fois récupérées, la widget spéciale transmet ces deux listes à l'entité «canal de communication» à travers les canaux «/USER ID/subscriptions» et « /USER ID/publications » respectivement, en spécifiant l'identifiant de la session émettrice de la requête «/USER ID/synchronizationrequest » comme session de destination. Ainsi, l'entité « canal de communication » transmet ces deux listes respectives qu'à la widget spéciale qui les a sollicitées. Une mise à jour de la liste L3 s'effectue en faisant le mapping entre la liste LI reçue et la liste L2 local ; on détecte si la widget émettrice de la liste LI est souscrite aux services que génèrent la widget réceptrice; si c'est le cas alors rajouter les souscriptions dans la liste L3. A chaque insertion ou suppression d'une souscription dans la liste L3 on enclenche la mis à jours de la couche présentation de la widget en insérant l'icône correspondante à la souscription. Dans la suite de la description et relativement aux figures 2 et 3, sera illustré le mécanisme de communication entre applications Web ou widgets, respectivement chargées dans le cadre de sessions actives de navigateurs distincts. Par session, on entendra la période d'activation/ exécution d'une instance d'un navigateur sur un terminal donné, par exemple un téléphone mobile, un ordinateur PC, un assistant personnel numérique, etc. Dans cette illustration nous allons prendre pour exemple un utilisateur qui possède deux terminaux : un premier terminal du type ordinateur PC et un deuxième 5 du type téléphone mobile. Comme illustré sur l'exemple de la figure 3, l'utilisateur a chargé un agrégateur 301 de services sur son téléphone mobile et un autre 300 sur son ordinateur PC, c'est-à-dire des espaces de type page Web lui permettant d'activer/ exécuter une ou plusieurs applications Web (encore appelée widgets, indifféremment) à l'intérieur d'une instance 10 d'un navigateur. Dans cet exemple, un utilisateur a chargé une widget « Annuaire » 302 en relation avec une session d'un navigateur 304 exécuté sur le terminal PC, et une widget 303 « GoogleMap » (marque déposée) en relation avec une session d'un navigateur 305 exécuté sur son terminal mobile. 15 Le but de l'invention et d'offrir à l'utilisateur la possibilité de connecter ces deux widgets 302, 303. Ainsi sur l'exemple, l'utilisateur aura un icon sur la widget «annuaire» pour chercher l'adresse affiché sur l'annuaire dans la widget « Google Map ». Pour faire cela, l'utilisateur a à sa disposition un certain nombre de widgets 20 spéciales comme le montre la figure 4. Dans cet exemple, l'utilisateur dispose d'une widget 400 formant module de connexion, laquelle lui permet de connecter ses différents terminaux, et une autre qui lui permet de se connecter avec des terminaux des utilisateurs appartenant à une même communauté. Dans cet exemple en occurrence l'utilisateur veut connecter des widgets 25 chargées sur ses différents terminaux, donc il charge la widget « Connecter vos terminaux » sur chaque terminal (c'est-à-dire chaque session du navigateur). Au moment du chargement de la widget spéciale, celle-ci demande à l'utilisateur un identifiant et un mot de passe. Cet identifiant et mots de passe permettent à la widget spéciale de créer (ou de joindre) un canal de transmission 30 unique est commun au terminaux du même utilisateur. Ce canal de transmission est crée auprès d'une entité serveur qu'on appellera «multi-teilninal bridge ». Le mot de passe est nécessaire pour des raisons de sécurité. Il permet en occurrence de bien vérifier que login fourni appartient bien à l'utilisateur qui accède à ce terminal. L'étape 1 est l'authentification de l'utilisateur. En fournissant son identifiant et un mot de passe, la widget spéciale vérifie dans la base de donnée si les données d'authentification sont correct. L'étape 2, on renvoi à la widget spéciale le résultat de l'authentification. Si l'authentification est correct, alors la widget spéciale crée ou rejoint (si déjà crée) le canal de transmission auprès du composant « multi-terminal bridge ». Le canal crée est spécifique à l'utilisateur qui vient de s'authentifier. Le composant «bridge multi-canal» a crée un canal tagué : canalTag qui est spécifique à l'utilisateur dont l'identifiant est canalTag. La widget spéciale chargée sur le terminal mobile fait exactement la même chose (i.e. elle authentifie l'utilisateur, et rejoint le canal canalTag dans le composant «bridge multi-terminal »). Ceci signifie que si la widget spéciale chargée sur le terminal PC veut communiquer avec la widget spéciale chargée sur mobile (du même utilisateur), elle n'a qu'à envoyer des données au composant «bridge multi-terminal » avec un tag « canalTag». C'est cette fonctionnalité que nous exploitons afin de permettre aux widgets chargée sur le terminal mobile (ici en occurrence GoogleMap), de connaître et de communiquer avec les widgets chargées sur le terminal PC (ici en occurrence Annuaire), et vis-versa. Supposons que la widget spéciale du terminal PC est chargée avant la widget spéciale du mobile. La widget spéciale qui est chargée sur le terminal PC récupère auprès de la widget « Annuaire » l'ensemble des souscriptions de la widget «Annuaire » (appelée LI) ainsi que les donnée que la widget «Annuaire » publie (appelée L2). La widget spéciale transmet ensuite au composant «bridge multi-terminal » ces deux liste tagué avec « canalTag ». À titre d'exemple, supposons que la widget « annuaire » souscrit aux données 30 de type « nom » (LI = [nom»), et qu'elle génère des donnée de type « carte de visite » (L2 = [carte de visite»). A ce stade rien ne se passe parce que la widget spéciale du mobile n'est pas encore chargée. Les mêmes actions sont aussi réalisées au chargement de la widget spéciale sur le mobile. La widget spéciale récupère auprès de la widget « GoogleMap » l'ensemble des souscriptions de la widget « Annuaire » (appelée L1) ainsi que les donnée que la widget « Annuaire » publie (appelée L2). La widget spéciale transmet ensuite au composant « bridge multi-teiniinal » ces deux liste tagué avec « canalTag». À titre d'exemple, supposons que la widget «googleMap » souscrit aux 10 données de type «carte de visite » (LI = [carte de visite»), et qu'elle ne génère pas de données (L2 = [J). Dans ce deuxième cas, y'à déjà la widget spéciale du terminal PC qui à crée et rejoint le canal «canalTag», donc la widget spéciale du mobile en publiant les deux liste (Ll et L2) auprès du composant « bridge multi-terminal », ce dernier transmet les 15 listes à toutes les widgets spéciale qui ont rejoint le canal tagué «canalTag». En occurrence, le composant «bridge multi-terminal » transmet ces deux listes à la widget spéciale du terminal PC de l'utilisateur. Quand la widget spéciale du terminal PC reçoit les deux listes (Ll et L2) des souscriptions et des données générées par des widgets chargées sur le mobile, elle les 20 transmet vers les widgets qui sont chargées sur le terminal PC. Ainsi, la widget « annuaire » recevra bien l'information que la widget «googleMap », chargée sur le mobile, est souscrite aux données de type «carte de visite » ; des données que la widget « Annuaire » peut générer. A ce titre, à chaque fois que la widget « annuaire » génère des données de type « carte de visite », elle insère un 25 l'icon « googleMap » qui permettra à l'utilisateur de déclencher une action sur la widget «googleMap ». L'icon inséré est récupéré dans les données de souscription (chaque souscription contient un icon). Une fois les liste L1 et L2 sont transmises aux différentes widgets du terminal PC, il est important d'informer la widget spéciale du mobile (qui vient juste d'être 30 chargée) de l'ensemble des souscriptions et des publication potentielles des widgets chargées sur le terminal PC. Pour cela, la widget spéciale du terminal PC récupère les souscriptions (LI) et les publications potentielles (L2) de la widget « Annuaire » (et d'autre widgets si présentes dans le terminal PC). Ces deux listes sont transmises à la widget spéciale du mobile à travers le composant «bridge multi-canal ». Quand la widget spéciale du terminal mobile reçoit les deux listes (L1 et L2) des souscriptions et des données générées par des widgets chargées sur le terminal PC, elle les transmet vers les widgets qui sont chargées sur le mobile. L'une des particularités du mécanisme est que les liens qui sont crées entre les widgets (que ce soit dans le même terminal ou sur différents terminaux), sont dynamiques. C'est-à-dire, si on rajoute une widget «envoi de SMS » sur la session chargée sur le mobile, celle si est prise automatiquement par la widget « Annuaire », qui elle est chargée sur le terminal PC. Pour réaliser cette fonctionnalité, au moment du chargement de la widget «envoi de SMS », celle-ci envoie la liste de ses souscriptions (LI) ainsi que la liste des publications potentielles (L2) à la widget spéciale du mobile. À titre d'exemple, supposons que la widget « envoi de SMS » souscrit aux données de type « carte de visite » (LI = [carte de visite»), et qu'elle ne génère pas de données (L2 = [J). Ensuite, la widget spéciale du mobile envoi la liste L1 et L2 aux autres terminaux du même utilisateur à travers le composant «bridge multi-terminal ». Dans cet exemple, y'a qu'un seul autre terminal qui est le terminal PC. Ainsi, la widget spéciale du terminal PC reçoit la liste des souscriptions de la widget « envoi de SMS ». Quand la widget spéciale du terminal PC reçoit les deux listes (LI et L2) des souscriptions et des données générées par des widgets chargées sur le mobile, elle les transmet vers les widgets qui sont chargées sur le terminal PC. Ainsi, la widget « annuaire » recevra bien l'information que la widget « envoi de SMS », chargée sur le mobile, est souscrite aux données de type « carte de visite » ; des données que la widget « Annuaire » peut générer. A ce titre, à chaque fois que la widget « annuaire » génère des données de type « carte de visite », elle insère une icone « envoi SMS » qui permettra à l'utilisateur de déclencher une action sur la widget «envoi de SMS ». L'icone inséré est récupéré dans les données de souscription (chaque souscription contient un icone). Pour continuer notre illustration du mécanisme, et afin montrer comment l'utilisateur peut enclencher des actions dans des widgets chargées sur le mobile à partir de widgets chargées sur le terminal PC, supposons que l'utilisateur a chargé une fiche annuaire d'une personne (i.e. une carte de visite qui contient nom, prénom, N° Tel, adresse de travail, et adresse email). La widget «Annuaire» sais maintenant qu'il y'a des widgets dans d'autre terminaux qui ont souscrits à des données de type «carte de visite » et donc insère les icones correspondantes comme illustré précédemment. Quand l'utilisateur click sur un des icons (e.g. sur l'icon «googleMap »), la widget « annuaire » notifie la widget spéciale du terminal PC en spécifiant la widget à enclencher ainsi que l'URL ou récupérer la carte de visite qui vient d'être générée. Ensuite, la widget spéciale du terminal PC transmet ces informations aux widgets spéciales d'autres terminaux (dans notre exemple y'a que le terminal mobile comme `autres terminaux'). La widget spéciale du mobile reçoit ces informations (la widget enclenchée (« googleMap ») ainsi que l'URL des données générées). Quand la widget spéciale du mobile reçoit les informations (comme quoi la widget Annuaire veut enclencher la widget googleMap, et les donnée générée par Annuaire), elle invoque la widget « googleMap » avec les donnée générée par la widget « Annuaire » comme inputs. Comme déjà mentionné précédemment, la particularité du procédé selon l'invention repose sur le fait que les liens qui sont crées entre les widgets (que ce soit dans le même terminal ou sur différents terminaux), sont dynamiques. Ceci veut aussi dire que lorsque l'utilisateur supprime une widget dans l'un de ses terminaux, ceci est reflété dans d'autres terminaux. Par exemple, lorsque l'utilisateur supprime la widget « googleMap » de son mobile, le lien, préalablement crée entre la widget « annuaire » et « googleMap » doit être supprimé. Pour réaliser cette fonctionnalité, au moment de la suppression de la widget « googleMap », celle-ci envoi un message de déconnexion à la widget spéciale. Ce message de déconnexion est transmit aux autres widgets spéciales, d'autre terminaux du même utilisateur à travers l'entité «bridge inter-terminal ». L'entité «bridge multi-terminal » de gestion des canaux de communication transmet le message aux autres widgets spéciales, d'autre terminaux du même utilisateur (dans notre cas vers la widget spéciale du terminal PC). La widget spéciale du terminal PC transmet l'information aux widgets du terminal PC (dans notre cas vers la widget « Annuaire »). La widget «Annuaire» supprime les liens correspondants à la widget qui vient de se déconnecter (« googleMap »). Revendications1. Procédé de communication entre une première application et au moins une deuxième application, lesdites première et deuxième applications étant respectivement exécutées dans un premier et deuxième navigateur Internet, caractérisé en ce que ledit procédé comprend : ^ une étape (101) d'activation d'un canal de communication unique entre lesdits premier et deuxième navigateurs ; ^ une étape (104) de souscription dynamique de ladite première application à au moins un service de ladite au moins une deuxième application, par l'intermédiaire dudit canal de communication ; ^ une étape (106) d'exécution par ladite première application, d'au moins une opération tenant compte d'une valeur d'au moins un paramètre généré par l'exécution dudit au moins un service, ladite valeur étant transmise par ladite deuxième application à ladite première application par l'intermédiaire dudit canal de communication. 2. Procédé selon la revendication 1, caractérisé en ce qu'il comprend les étapes préalables : ^ d'activation (1001) d'un premier module de communication apte à gérer des communications impliquant des applications exécutées à l'intérieur dudit premier navigateur Internet; et ^ d'activation (1002) d'un deuxième module de communication apte à gérer des communications impliquant des applications exécutées à l'intérieur dudit deuxième navigateur Internet. 3. Procédé selon la revendication 2, caractérisé en ce qu'il comprend suite auxdites étapes (1001,1002) d'activation, des étapes (1021,1022) de connexion respectives desdits premier et deuxième modules de communication audit canal de communication, par l'intermédiaire d'une entité de gestion de canaux de communication. 4. Procédé selon la revendication 3, caractérisé en ce qu'il comporte une étape (103) de transmission par ladite deuxième application audit deuxième module de communication, d'une première liste associant à chaque service proposé par ladite deuxième application, au moins un type de paramètre dont une valeur sera générée à l'exécution dudit service. 5. Procédé selon la revendication 4, caractérisé en ce que ladite étape (104) de souscription comprend les sous-étapes suivantes de : ^ enregistrement (1041) de ladite première application auprès dudit deuxième module de communication, par l'intermédiaire dudit canal de communication ; ^ transmission (1042) par ladite première application audit deuxième module, d'une deuxième liste de paramètres associés, respectivement, à au moins une opération susceptible d'être exécutée par ladite première application; ^ création (1043) par ledit deuxième module d'une troisième liste de souscription de services propre de ladite première application, laquelle associe à chaque to service de ladite première liste au moins une opération susceptible d'être exécutée par ladite première application, par mise en correspondance des types de paramètre contenus respectivement dans lesdites premières et deuxièmes listes. 6. Procédé selon la revendication 5, caractérisé en ce que préalablement à ladite 15 étape (106) d'exécution, il comprend une étape (105) de transmission par ledit deuxième module de communication audit premier module de communication d'au moins un message de déclenchement dynamiquement d'une exécution de ladite opération par ladite première application, ledit message étant transmis suite à l'exécution dudit service par ladite deuxième application au travers ledit canal de 20 communication unique. 7. Procédé selon la revendication 4, caractérisé en ce que ledit message est du type appel de fonction à distance tenant compte d'une valeur dudit paramètre généré à l'exécution du service propre de ladite deuxième application. 8. Procédé selon la revendication 1, caractérisé en ce que ladite souscription entre 25 lesdites premières et deuxième applications est matérialisé par un élément d'une interface homme machine propre à ladite deuxième application au moyen duquel un utilisateur de ladite deuxième application peut interagir pour déclencher l'exécution de ladite opération par l'intermédiaire de ladite première application. 9. Procédé selon la revendication 5 caractérisé en ce qu'il comprend une étape 30 (107) de mise à jour dynamique de ladite troisième liste de souscription de services gérée par ledit deuxième module, suite à la transmission audit deuxième module, par ledit premier module, d'un message de notification d'une déconnexion de ladite première application, par l'intermédiaire dudit canal de communication. 10. Procédé selon la revendication 1, caractérisé en ce que ladite première application est exécutée dans un premier navigateur exécuté sur un premier terminal et, en ce que ladite deuxième application est exécutée dans un deuxième navigateur exécuté sur un deuxième terminal. 11. Système de communication entre une première application et au moins une deuxième application, lesdites première et deuxième applications étant respectivement exécutées dans un premier et deuxième navigateur Internet, caractérisé en ce que ledit système comprend : ^ des moyens d'activation d'un canal de communication unique entre lesdits premier et deuxième navigateurs ; des moyens de souscription dynamique de ladite première application à au moins un service de ladite au moins une deuxième application, par 15 l'intermédiaire dudit canal de communication ; ^ des moyens d'exécution par ladite première application, d'au moins une opération tenant compte d'une valeur d'au moins un paramètre généré par l'exécution dudit au moins un service, ladite valeur étant transmise par ladite deuxième application à ladite première application par l'intermédiaire dudit 20 canal de communication. 12. Produit programme d'ordinateur téléchargeable depuis un réseau de communication et/ou stocké sur un support d'information lisible par ordinateur et/ou exécutable par un microprocesseur, caractérisé en ce qu'il comprend des instructions de code pour l'exécution d'un procédé de communication conforme à l'une quelconque des 25 revendications 1 à 10, lorsqu'il est exécuté sur un ordinateur.