FR 2923337 A1 20090508 FR 0758864 A 20071107 La présente invention concerne le domaine informatique et plus particulièrement l'échange de données entre un serveur hébergé dans une entité électronique et un serveur distant. L'essor des technologies de télécommunication a permis la convergence du monde de la téléphonie mobile avec celui de l'Internet. Ainsi, depuis quelques années, il est possible d'accéder, au travers du réseau de téléphonie mobile, à des sites Internet depuis un navigateur Web embarqué sur un téléphone mobile. On connaît notamment le développement du protocole WAP ("Wireless Application Protocof' selon la terminologie anglo-saxonne) à l'aide duquel un navigateur Web embarqué envoie une requête HTTP ("Hypertext Transfer Protocof' selon la terminologie anglo-saxonne) à destination d'un serveur Web du réseau Internet. Cette requête est convoyée sur le réseau de téléphonie mobile et transmise au réseau Internet par l'intermédiaire d'une passerelle ad hoc. Le serveur Web répond alors à la requête en envoyant, par le même trajet, au navigateur Web embarqué une page dans un format que ce dernier connaît, par exemple WML ("Wireless Markup Language") ou XTML ("eXtensible Telephony Markup Language"). D'autres formats tels que le HTML ("Hypertext Markup Language"), PHP (acronyme récursif PHP: Hypertext Preprocessor), XML ("Extensible Markup Language"), Javascript ou équivalents peuvent également être utilisés. A réception, le navigateur Web exécute la page reçue pour former un affichage sur un écran de rendu, en général l'écran du téléphone mobile. Ici, et pour la suite du document, l'exécution d'une page par un navigateur peut être entendue comme l'interprétation des instructions formant la page, par exemple des balises HTML, de sorte à rendre un affichage correspondant au contenu de la page. Une part grandissante des applications mettant en oeuvre les téléphones mobiles est effectuée à l'intérieur de la carte SIM ("Subscriber Identity Module") embarquée, pour des raisons de sécurité. Ainsi, il est apparu des serveurs Web dans des cartes à puce, appelés "Smart Card Web Serveur" selon la terminologie anglo-saxonne ainsi que dans un grand nombre d'entités électroniques de poche, type clé USB ("Universal Serial Bus") ou carte à microcircuit (carte à puce). On constate que l'accès à ces serveurs embarqués dans une entité électronique est généralement aisé depuis un navigateur type Web exécuté sur 10 le téléphone mobile auquel est liée l'entité électronique. En revanche, la communication entre le serveur d'une telle carte à puce liée au téléphone mobile et un serveur distant dans le réseau Internet nécessite une adaptation du navigateur et/ou du téléphone mobile. Notamment, le serveur distant doit pouvoir disposer d'une adresse IP ("Internet Protocof') du 15 serveur embarqué pour communiquer avec ce dernier. Une transaction bancaire pendant laquelle un serveur bancaire pilote un processus d'authentification avec une carte à puce est un exemple d'application où ce problème peut se rencontrer. On connaît, par le document Guthery et al. ("How to turn a GSM SIM 20 into a Web Server", Scotte Guthery, Roger Kehr et Joachim Possega, disponible à l'adresse http://www.scdk.com/websim.pdf), une solution répondant à cette problématique par l'utilisation de SMS ("Short-Message Service"). En détail, le serveur distant envoie des requêtes au serveur de la carte à puce à l'aide de messages SMS avec commande dans l'enveloppe. Il en résulte une 25 communication directe entre les deux serveurs et la possibilité, pour le serveur distant, de piloter l'exécution de commande par la carte à puce. Néanmoins, cette solution requiert un serveur spécifique pour la conversion des requêtes en message SMS et des moyens correspondants au niveau de la carte à puce pour convertir les messages SMS reçus en 30 commandes. En outre, cette solution présente également l'inconvénient de réaliser des transactions lentes du fait de la vitesse de propagation des messages SMS de l'ordre de plusieurs secondes (voir paragraphe 2.3.3. de ce document). Il existe donc un besoin de fournir un mécanisme d'échange de données plus efficace, notamment plus rapide et/ou ne requerrant pas d'équipement supplémentaire. Dans ce dessein, l'invention vise notamment un procédé d'échange de données entre un premier serveur hébergé dans une entité électronique liée à un appareil programmable et un deuxième serveur distant, lesdits premier et deuxième serveurs étant chacun adressables individuellement par l'appareil programmable au moyen d'adresses cibles respectives, le procédé comprenant les étapes suivantes : a. réception par l'appareil programmable d'une réponse à une première requête, ladite réponse comprenant les données et une desdites 15 adresses cibles ; b. exécution de ladite réponse par un navigateur, par exemple de type web, mis en oeuvre sur l'appareil programmable de manière à entraîner l'émission des données vers ladite adresse cible. On entend par "distant" le fait que pour atteindre le deuxième serveur 20 il y ait besoin de s'appuyer sur un réseau de communication, par exemple un réseau de téléphonie mobile ou Internet. En particulier, le deuxième serveur est distant de l'entité électronique (et de l'appareil qui lui est lié) en ce que l'adresse de ce serveur n'est pas référencée comme une adresse locale pour l'entité électronique. 25 On entend par "entité liée" toute entité électronique qui est intégrée dans l'appareil programmable ou qui est en position connectée à l'appareil lorsque l'entité est amovible. Dans la configuration intégrée, des moyens de liaison, notamment des connecteurs électriques, par exemple des fils d'or, sont utilisés pour relier l'entité électronique à d'autres composants de l'appareil. 30 Dans la configuration amovible, il est commun que l'appareil programmable et l'entité possèdent des interfaces correspondantes de réception de l'autre équipement, ces interfaces officiant comme moyens de liaison et comprenant des connecteurs avec l'autre équipement pour assurer une connexion avec les composants de l'autre équipement. Ainsi, cette liaison comprend une connexion physique et électrique entre l'appareil et l'entité. En réponse à une première requête préalable, l'un des serveurs émet ainsi une réponse qui est convertit par le navigateur de l'appareil programmable en une seconde requête pour la transmission des données vers l'adresse cible fournie, qui correspond selon toute vraisemblance à l'autre serveur. Ainsi, les deux serveurs communiquent entre eux par l'intermédiaire du navigateur qui joue un rôle de passerelle. La terminologie requête/réponse renseigne que le navigateur présente un rôle central de pilotage des échanges entre les deux serveurs. Une requête correspond à une demande du navigateur à l'un des serveurs, alors qu'une réponse correspond à un message fourni par un serveur requêté au navigateur. De par la fonction centrale du navigateur, il est possible également d'établir un échange de données tripartite voire entre plus de trois serveurs. L'invention peut notamment s'appuyer sur les mécanismes de navigateur web déjà existants pour créer cette fonction de passerelle. On obtient ainsi un procédé d'échange de données qui ne nécessite pas l'adjonction d'un serveur ou d'un module supplémentaire. En outre, les mécanismes d'un navigateur n'introduisent pas de temps de latence comparé à un réseau par message SMS. Ainsi, l'invention procure un procédé rapide. On note que le procédé selon l'invention s'applique dans les deux sens de communication entre les deux serveurs. Dans un mode de réalisation, la première requête préalable provient éventuellement d'une réponse préalable de l'autre serveur audit navigateur. Ainsi, on prévoit que les étapes a) et b) sont réitérées, et ladite émission d'une itération comprend la transmission de ladite première requête de l'itération suivante. On réalise ainsi un bouclage continu des requêtes et réponses entre le navigateur et les serveurs, rendant possible l'établissement d'échanges complexes de données entre serveurs. Dans un mode de réalisation, ladite réponse est transmise selon le protocole HTTP. Le premier ou deuxième serveur émetteur des données et de 5 la réponse est alors un serveur HTTP. Dans un mode de réalisation, ladite émission des données (requête émise par le navigateur) vers l'adresse cible est effectuée selon le protocole HTTP. Dans ce cas, le premier ou deuxième serveur destinataire des données est un serveur web mettant en oeuvre le protocole HTTP. 10 Dans une variante, ladite émission des données vers l'adresse cible est effectuée selon le protocole FTP ("File Transfer Protocof'). Dans ce cas, le premier ou deuxième serveur destinataire des données est un serveur FTP. Dans un mode de réalisation, ladite réponse comprend une commande agencée pour être exécutée par ledit navigateur. On prévoit 15 notamment que cette commande s'appuie sur les mécanismes classiques, par exemple HTTP et HTML, d'un navigateur web de telle sorte qu'aucune extension ("plug-in" selon la terminologie anglo-saxonne) ne soit nécessaire. Selon une caractéristique particulière, ladite commande est incluse dans le corps de ladite réponse, c'est-à-dire que la commande est dans une 20 page prévue pour contenir les données à transmettre. Cette page est notamment établie selon des normes conventionnelles, par exemple une page HTML, une page XML, une page XHTML (acronyme de "eXtensible HyperText Markup Language"), avec ou sans script JavaScript (nom commercial). De façon plus précise, la commande peut également être dans le corps de la page 25 considérée, le corps peut par exemple être délimité par des balises ad hoc, par exemple et en langage HTML. Eventuellement, la commande est placée dans l'en-tête de la page considérée. Egalement, la commande peut être incluse dans un script JavaScript. En variante, ladite commande est incluse dans l'en-tête de ladite 30 réponse. Il convient alors de prévoir que le navigateur web soit adapté à interpréter l'en-tête de la réponse pour exécuter la commande. Une solution consisterait à modifier la norme HTTP pour y inclure un champ spécifique dédié à une commande à exécuter. Selon une autre caractéristique particulière, ladite commande comprend ladite adresse cible, par exemple comme paramètre. La commande peut également comprendre les données, par exemple comme paramètre. Selon une autre caractéristique particulière, ladite commande comprend une commande d'envoi d'une requête HTTP. En particulier, ladite commande d'envoi comprend un lien externe vers un serveur HTTP. Notamment, ce lien externe peut être sous la forme d'une redirection d'adresse URL (acronyme de "Uniform Resource Locator"), par exemple selon le format : où TEMPS est un délai (en secondes) de rafraîchissement à fixer. Dans ce cas, selon le sens de communication entre les serveurs, le serveur destinataire est un serveur HTTP. Particulièrement, on prévoit que ladite requête est selon le protocole sécurisé HTTPS. Selon une autre caractéristique particulière, ladite commande comprend une commande d'envoi d'une requête FTP. En particulier, ladite commande d'envoi comprend un lien externe vers un serveur FTP. Notamment, ce lien externe peut être sous la forme d'une redirection d'adresse URL (utilisation de l'URL au format ftp://ftp.example.com/). Dans ce cas, selon le sens de communication entre les serveurs, le serveur destinataire est un serveur FTP. Dans un mode de réalisation, on prévoit que ladite commande agencée pour être exécutée par ledit navigateur comprend une commande locale agencée pour être exécutée au niveau du serveur destinataire des données, par exemple une commande APDU (pour "application protocol data unit"). Ainsi, le navigateur exécutant la première commande citée, va transmettre la commande locale au serveur destinataire pour exécution en local, soit directement par le serveur soit par une application destinataire. Notamment, ladite commande locale est de préférence conforme à la norme ISO 7816. Egalement, lesdites données sont passées en paramètre de la commande locale. Dans un mode de réalisation, ladite émission des données comprend la transmission d'une requête, par exemple HTTP ou FTP, et le procédé comprend alors une étape de conversion de ladite requête en une commande compatible avec des moyens de communication prévus dans ladite entité électronique. La conversion peut être de type encapsulation de ladite requête dans un paquet compatible avec une norme de communication avec l'entité électronique, ou de type reformatage des instructions et données en une commande compatible, ou un mixte des deux. Notamment, il peut s'agir d'une conversion compatible avec l'une des normes OMA (Open Mobile Alliance), par exemple la norme OMA-TS-Smartcard_Web_Server-V1. Dans un mode de réalisation, ladite entité électronique comprend un serveur HTTP. Dans un mode de réalisation, ladite entité électronique est agencée pour se connecter de façon amovible audit appareil programmable, par exemple au moyen d'une interface USB ou d'une interface ISO 7816. Ainsi, le procédé peut comprendre une étape préalable de connexion de ladite entité électronique audit appareil programmable de sorte à former une liaison pour communiquer. Dans un mode de réalisation, ladite entité électronique est dépourvue d'alimentation autonome. On obtient ainsi une entité électronique de taille réduite, qui s'embarque ou se connecte facilement à l'appareil programmable. Ainsi, on peut prévoir que ladite entité électronique comprend une clé USB. En variante, ladite entité électronique comprend une carte à microcircuit. Selon une caractéristique particulière, ladite carte est conforme à la norme ISO 7816. Selon une autre caractéristique particulière, ladite carte comprend une carte mémoire, par exemple de type MMC (acronyme de "Multimedia 5 Memory Car/"). Dans une autre variante, ladite entité électronique comprend une carte de téléphonie mobile. Dans ce cas, ladite carte peut être de type SIM, notamment de type USIM ("Universal Subscriber Identity Module"). On peut alors envisager que l'appareil programmable est un téléphone mobile. 10 En alternative à l'amovibilité de l'entité, on prévoit que ladite entité électronique comprend un module de microcircuit intégré dans ledit appareil programmable et hébergeant ledit premier serveur. Le système résultant présente une simplicité de conception et d'intégration accrue, ainsi les coûts de fabrication qui en découlent sont diminués. 15 En particulier, ledit module de microcircuit est apte à communiquer sans fil, par exemple conformément à la norme NFC ("Near Field Communication"). Cette configuration permet, d'une part, au module de converser avec, par exemple, un lecteur externe ou terminal, et d'autre part, de solliciter un échange de données avec un deuxième serveur distant. 20 En alternative, on peut prévoir que les moyens de communication NFC et le premier serveur sont hébergés sur deux modules de microcircuit distincts interconnectés. Dans un mode de réalisation, on prévoit que ladite entité électronique est sécurisée conformément aux critères communs ou à la norme 25 FIPS. Selon une caractéristique de l'invention, ladite entité électronique comprend des moyens cryptographiques, notamment une clé cryptographique. Dans un mode de réalisation, ledit appareil programmable comprend un ordinateur personnel. En particulier, ledit appareil programmable est un 30 téléphone mobile. Dans un mode de réalisation, ledit deuxième serveur distant et ledit appareil programmable communiquent au travers d'au moins un réseau de télécommunication. Notamment, ledit réseau de télécommunication comprend un réseau de télécommunication mobile, auquel cas on peut envisager que l'appareil programmable est un téléphone mobile. Selon une configuration de l'invention, ladite entité électronique est amovible portable et/ou de poche. On entend par équipement de poche tout équipement facilement transportable par un utilisateur dans une poche, notamment de taille réduite vérifiant un volume inférieur à 100 ml et une plus grande longueur inférieure à 15 cm, de préférence vérifiant un volume inférieur à 20 ml et une plus grande longueur inférieure à 5 cm. On accroît ainsi la portabilité, par exemple, de moyens d'authentification et on simplifie, pour un utilisateur, le transport, sur lui, d'informations d'authentification propres. Dans un mode de réalisation, au moins une desdites adresses comprend une adresse IP. Ce mode de réalisation permet de s'appuyer sans difficulté sur les infrastructures et mécanismes déjà existants pour gérer le protocole IP. L'invention concerne également un procédé d'authentification entre un premier et un deuxième serveur, comprenant un échange de token basé sur un mécanisme de Challenge- Response (mécanisme conventionnel d'authentification) par l'échange de données conformément à au procédé décrit ci-dessus. L'invention a également trait à un système d'échange de données entre un premier et un deuxième serveurs, le système comprenant un premier serveur hébergé dans une entité électronique liée à un appareil programmable et un deuxième serveur distant, lesdits premier et deuxième serveurs étant chacun adressables individuellement par l'appareil programmable au moyen d'adresses cibles respectives, l'appareil programmable comportant : - des moyens de réception d'une réponse à une première requête, ladite réponse comprenant les données et une desdites adresses cibles ; et - un navigateur agencé pour exécuter ladite réponse de manière à entraîner l'émission des données vers ladite adresse cible. Les avantages de ce système sont similaires à ceux du procédé correspondant. De façon optionnelle, le système peut comprendre des moyens se rapportant aux caractéristiques de procédé d'échange de données présentées ci-dessus. Notamment, ledit navigateur peut être agencé pour émettre lesdites données sous forme d'une requête, et ledit système comprend alors des moyens de conversion de ladite requête en une commande compatible avec des moyens de communication prévu dans ladite entité électronique. En distinguant plus précisément les rôles, d'un côté, de premier serveur hébergé, et de l'autre côté, du deuxième serveur distant, l'invention vise également un procédé d'émission de données depuis un serveur distant à destination d'un serveur hébergé dans une entité électronique adressable au moyen d'une adresse cible par un appareil programmable mettant en oeuvre un navigateur. Le procédé d'émission comprend notamment une étape d'émission, en réponse à une première requête, par le serveur distant et à destination de l'appareil programmable, d'une réponse lisible par le navigateur et comprenant les données, l'adresse cible et une instruction de redirection des données à l'adresse cible. Ainsi, le navigateur de l'appareil programmable joue également, par l'effet de l'instruction de redirection qu'il met en oeuvre, un rôle de passerelle entre les deux serveurs. Des avantages similaires à ceux du procédé d'échange de données ci-dessus sont ainsi obtenus par ce procédé d'émission. De façon optionnelle, le procédé peut comprendre tout partie des caractéristiques de procédé d'échange de données présentées ci-dessus. Notamment, l'instruction de redirection peut prendre la forme d'une commande au niveau de la réponse, par exemple HTTP. Ainsi, on peut prévoir que la redirection comprend un lien externe vers un serveur HTTP ou FTP. Dans un mode de réalisation, ladite commande comprend une commande locale apte à être exécutée par l'entité électronique. Le terme "locale" se réfère à l'entité électronique, de telle sorte que la commande locale puisse être interprétée et exécutée par une application mise en oeuvre par l'entité électronique. Cette réalisation permet au serveur distant d'envoyer, de façon efficace, des commandes à l'entité électronique et ainsi de la piloter. Selon une caractéristique particulière, ladite commande locale est conforme à la norme ISO 7816. Dans cette réalisation, le serveur hébergé récupère et extrait, d'une requête ultérieure transmise par le navigateur en réaction à la commande de redirection, la commande locale et la transmet à un système d'exécution de commande conforme à la norme ISO 7816, par exemple au système d'exploitation de l'entité électronique, pour l'exécution de cette commande. Selon une autre caractéristique particulière, lesdites données sont passées en paramètre de ladite commande locale. Cette réalisation permet, au serveur distant, de piloter efficacement et précisément l'entité électronique, notamment en jouant sur les données à transmettre, c'est-à-dire sur les paramètres de la commande locale qui est, à terme, exécutée par l'entité électronique. Dans un mode de réalisation, ladite entité électronique comprend un serveur FTP. Cette réalisation correspond préférentiellement au cas de figure où la commande comprend une commande d'envoi d'une requête FTP (au serveur en question). L'invention a également trait à un serveur comprenant des moyens d'émission agencés pour émettre, en réponse à une première requête et à destination d'un appareil programmable mettant en oeuvre un navigateur, une réponse lisible par le navigateur et comprenant des données, une adresse cible d'un deuxième serveur hébergé par une entité électronique liée audit appareil programmable et une instruction de redirection des données à l'adresse cible. De façon optionnelle, le serveur peut comprendre des moyens se rapportant aux caractéristiques de procédé d'émission de données présentées ci-dessus. De l'autre côté, l'invention vise également un procédé d'émission de données depuis un premier serveur hébergé dans une entité électronique liée à un appareil programmable mettant en oeuvre un navigateur, à destination d'un deuxième serveur distant ayant une adresse cible. Le procédé comprend notamment une étape d'émission, en réponse à une première requête, par ledit premier serveur et à destination de l'appareil programmable, d'une réponse lisible par le navigateur et comprenant les données, l'adresse cible et une instruction de redirection des données à l'adresse cible. Ainsi, le navigateur de l'appareil programmable joue également, par l'effet de l'instruction de redirection qu'il met en oeuvre, un rôle de passerelle entre les deux serveurs. Des avantages similaires à ceux du procédé d'échange de données ci-dessus sont ainsi obtenus par ce procédé d'émission. De façon optionnelle, le procédé peut comprendre tout partie des caractéristiques de procédé d'échange de données présentées ci-dessus. Dans un mode de réalisation, le procédé comprend une étape préalable de traitement effectuée par ladite entité électronique de sorte à générer lesdites données. Ainsi, les données transmises par le procédé selon l'invention sont issues d'un traitement sur l'entité électronique. Notamment, le traitement peut comprendre un traitement cryptographique, par exemple de type encryptage/décryptage ou signature/authentification, utilisant une clé mémorisée dans l'entité électronique et des moyens cryptographiques prévus à cet effet dans l'entité. Egalement, ledit traitement peut mettre en oeuvre des données tierces reçues par l'entité électronique selon le procédé d'émission depuis un serveur distant à destination du serveur hébergé, objet de l'invention. On observe ainsi que l'invention permet de définir un procédé d'échange de données dans les deux sens de communication entre le serveur distant et le serveur hébergé. Il est ainsi possible d'envoyer des commandes à une entité électronique, par exemple une carte, qui, en retour, fournit une réponse au serveur distant. L'invention a également trait à une entité électronique comprenant un premier serveur et des moyens de liaison à un appareil programmable mettant en oeuvre un navigateur, ledit premier serveur comprenant : - des moyens d'émission agencés pour émettre, en réponse à une première requête et à destination de l'appareil programmable, une réponse lisible par le navigateur et comprenant des données, une adresse cible d'un deuxième serveur distant et une instruction de redirection des données à l'adresse cible. De façon optionnelle, l'entité peut comprendre des moyens se 5 rapportant aux caractéristiques de procédés d'émission de données présentées ci-dessus. Dans un mode de réalisation, lesdits moyens de liaison comprennent une interface USB. Selon une variante, lesdits moyens de liaison comprennent une 10 interface conforme à la norme ISO 7816. Les caractéristiques et avantages de la présente invention apparaîtront plus clairement à la lecture d'un mode préféré de réalisation illustré par les dessins joints, dans lesquels : - la figure 1 illustre un exemple de système pour la mise en oeuvre 15 de la présente invention - la figure 2 représente, sous forme d'un logigramme, les différentes étapes de traitement réalisées par le navigateur web de la figure 1 ; et - la figure 3 représente, sous forme d'un logigramme, les 20 différentes étapes de traitement réalisées par les deux serveurs web de la figure 1. En référence à la figure 1, on a représenté un exemple de système pour la mise en oeuvre de l'invention. Cet exemple s'appuie sur une solution de téléphonie mobile et d'accès à Internet lors d'une transaction bancaire. Il va de 25 soi que les explications fournies ci-après peuvent s'appliquer à tout type d'appareil programmable, pas uniquement un téléphone mobile, à tout type de réseau et pour tout type d'application requerrant un échange de données entre deux serveurs. Dans l'exemple de la figure 1, un utilisateur est représenté par un 30 téléphone mobile 100 et un opérateur de transaction bancaire, par exemple une banque, est représenté par un serveur 110, par exemple un serveur Web HTTP ou un serveur FTP. Les deux équipements 100 et 110 sont interconnectés par l'intermédiaire d'un ou plusieurs réseaux 120. Bien que la figure 1 ne représente qu'un seul nuage comme réseau, il est classique, au vu des applications déjà existantes d'accès à Internet depuis un téléphone mobile, que les deux équipements soient interconnectés au travers d'un réseau de téléphonie mobile type GSM ("Global System for Mobile Communications") (auquel se connecte directement le téléphone mobile 100) et d'un réseau IP (auquel est connecté le serveur web 110). Les deux réseaux sont reliés au moyen d'une passerelle adaptée à convertir des données depuis l'un des formats vers l'autre format des deux réseaux (non représentée). Ainsi, le téléphone mobile 100 et le serveur web 110 peuvent échanger des données via les deux réseaux 120. Le serveur web 110 est un serveur bancaire classique qui met en oeuvre, en plus de moyens de serveur web aptes à gérer des requêtes HTTP, des moyens d'authentification et des moyens de transaction (non représentés), et qui possède des moyens de communication sur le réseau 120. L'accès à ce serveur, depuis le réseau 120, est effectué par l'intermédiaire d'une page web atteignable à l'aide d'une adresse Internet, par exemple https://www.mybank.com/HomeBanking.cgi. L'application HomeBanking.cgi met notamment en oeuvre le processus de transaction bancaire. Le téléphone mobile est doté de composants de fonctionnement, notamment une unité centrale de traitement CPU 101, un écran d'affichage 102, une ou plusieurs mémoires 103, par exemple une mémoire morte et une mémoire vive, des moyens de communication 104 avec le réseau 120 et une interface 105 avec une entité électronique 130. Ces composants sont interconnectés au moyen d'un bus de données 106. L'unité centrale 101 est apte à exécuter des applications contenues en mémoire 103, notamment un système d'exploitation embarqué (non représenté) permettant le fonctionnement classique d'un téléphone mobile. La mémoire 103 comprend également une application de type navigateur Web 107 connu, exécutable par l'unité centrale de traitement 101, pour permettre à l'utilisateur d'accéder au réseau Internet distant, par exemple via le protocole WAP précédemment évoqué. Un clavier ou dispositif de saisie (non représenté) pourvu sur le téléphone mobile 100 permet à l'utilisateur d'interagir avec le navigateur web 107 lorsque celui-ci est exécuté par l'unité centrale 101. Le rendu fourni par le navigateur web 107 est affiché sur l'écran 102 du téléphone 100. L'interface de connexion 105 permet l'interconnexion de l'entité électronique 130 avec le bus 106 et donc avec les autres composants du téléphone. Différents types d'interfaces 105 peuvent être prévues seules ou en combinaison, selon notamment les entités 130 utilisées. On peut noter les interfaces USB aptes à recevoir des entités USB amovibles, les interfaces ISO 7816 prévoyant des plots de connexion pour recevoir des microcircuits ou cartes SIM respectant cette norme, les interfaces MMC. L'entité électronique 130 est notamment dépourvue de moyens d'alimentation autonomes, c'est-à-dire de batterie ou équivalent, et est alimentée, pour son fonctionnement et via l'interface 105, par l'alimentation (non représentée) du téléphone mobile 100. L'entité électronique 130 peut être amovible, afin de permettre une maintenance aisée et/ou un remplacement facilité afin d'obtenir de nouvelles fonctionnalités apportées par cette entité. Cependant, l'invention s'applique également à des entités 130 fixes dans le téléphone mobile 100. Pour la suite de la description, on considère une unique entité électronique 130 de type carte à puce SIM telle qu'on en trouve actuellement dans les téléphones mobiles. La carte à puce ou toute entité électronique 130 comprend un serveur de carte à puce 131, par exemple un serveur web ("Smart Card Web Serveur"), un moyen d'exécution type CPU 132, une mémoire 133 pour stocker des applications (notamment l'application serveur web, mais également des applications dédiées telles qu'une application d'authentification) et des moyens de communication 134 avec l'interface 105. Dans l'exemple décrit, le serveur 131 permet d'exécuter une application qui comprend, stockées en mémoire 133, une page d'accueil 201.html, une page d'authentification initAuthent et une page processAPDU. Les moyens de communication 134 comprennent la connexion physique, par des contacts électriques, de la carte SIM 130 à l'interface 105 ainsi qu'une application (non représentée) en mémoire et apte à communiquer de façon applicative avec les composants du téléphone mobile 100. Pour les communications avec les composants du téléphone mobile 100, et notamment le navigateur web 107, la carte SIM 130 est identifiée à l'aide d'une adresse normalisée selon la norme OMA-TS- Smartcard Web Server-V1 Par exemple, on prend l'adresse réseau 127.0.0.1:3516 pour identifier la carte SIM 130 sur un canal TCP ("Transmission Control Protocof') classique et l'adresse réseau 127.0.0.1:4116 pour identifier la carte SIM 130 sur un canal TCP sécurisé (canal TLS, "Transport Layer Security"). En pratique, la norme OMA peut être mise en oeuvre à l'aide d'un logiciel (non représenté) exécuté, de préférence en permanence, sur le téléphone mobile 100. Le logiciel supporte le protocole BIP ("Bearer Independent Protocof', notamment selon la norme ETSI TS 102 223) pour gérer la communication avec la carte SIM 130. Le logiciel écoute en continu les ports 3516 et 4116 de l'adresse 127.0.0.1. Il convertit les requêtes HTTP émises par le navigateur 107 en commandes APDU à destination du serveur 131 de la carte SIM 130, et les transmet à la carte, et convertit les réponses APDU émises par la carte 130 en réponses HTTP pour les transmettre au navigateur 107. Dans cette configuration, le serveur 131 peut prendre la forme d'une applet ad hoc. Une autre norme envisageable est d'utiliser le nom "localhost" comme référant de l'ordinateur en local et connu des systèmes d'exploitation. On prévoit ainsi les adresses correspondantes Iocalhost:3516 et Iocalhost:4116. Encore un autre adressage envisagé comprend l'utilisation du nom "smartcard", a priori non connu du système local, pour identifier la carte SIM 130. Il convient alors de prévoir des moyens de résolution d'adresse IP pour associer ce nom à l'adresse IP correspondante, par exemple 127.0.0.1:4116 pour un canal TCP sécurisé. On utilise notamment un serveur DNS ("Domain Name System") supplémentaire pour effectuer cette opération de résolution, ce serveur étant de préférence hébergé dans le téléphone mobile 100. L'exemple applicatif de transaction bancaire mettant en oeuvre l'invention est maintenant décrit à l'aide de corps de pages HTML. Bien que cet exemple s'appuie sur des unités de données de protocole d'application (APDU), il est possible d'envisager l'utilisation d'actions mentionnées dans les requêtes envoyées à et traitées par le serveur web 131. Pour accéder à l'application de transaction, l'utilisateur charge la page 201.html suivante dans le navigateur web 107 de son téléphone 100: Smart Web Banking Lorsque l'utilisateur clique sur le lien Banking, la page initAuthent est appelée et la carte génère en conséquence une réponse HTTP comprenant cette page. Cette page a pour fonction de vérifier le PIN ("Persona/ identification number"), par exemple à quatre chiffres: Home banking PIN L'utilisateur saisit alors son PIN dans le formulaire affiché par le navigateur 107 et valide le formulaire, ce qui transmet une requête http vers la serveur 131 hébergé dans la carte SIM 130. Le PIN est alors vérifié par la carte SIM 130. Si le PIN est bon, la carte SIM 130 va initier une liaison (pour la transaction) avec le serveur de transaction 110 en générant une réponse HTTP à la requête, la réponse contenant la page HTML suivante. Le navigateur 107 affiche cette page à l'utilisateur sur l'écran 102. PIN correct Veuillez patienter, application carte sélectionnée... On remarque ici que la méta-donnée identifiée par la balise comprend une redirection automatique, ici au bout de content=1 seconde, vers l'adresse du serveur bancaire 110, ici https://www.mybank.com/HomeBanking.cgi, selon un canal sécurisé. Ainsi, au terme de ce délai de 1 seconde, le navigateur émet une requête HTTP à l'adresse spécifiée précédemment, ici le serveur bancaire 110 et sa page principale. A réception de la requête, le serveur de transaction 110 entreprend alors un processus d'identification de la carte SIM 130 par l'exécution de l'application HomeBanking.cgi appelée. Ce processus met en oeuvre un processus d'authentification interne impliquant l'envoi d'une valeur aléatoire à la 18 carte SIM 130. En réponse à la requête, le serveur bancaire 110 renvoie, au navigateur 107, une réponse HTTP comprenant la page HTML suivante: Authentification de la carte Veuillez patienter, authentification carte en cours... On note ici que la donnée est contenue dans la commande APDU aléatoire 03880000089A52C6B767932ED500 à transmettre à la carte SIM 130. La valeur aléatoire est ainsi passée en paramètre de la commande de redirection délimitée par la balise . Le message compris entre les balises s'affiche à l'écran 102 de l'utilisateur, puis au bout d'une seconde (content=1), le navigateur émet une requête HTTP à destination de la carte SIM 130 et appelant la page processAPDU. La donnée ID=123 permet d'identifier la carte à puce 131 avec laquelle une transaction est en cours, sachant que le serveur bancaire 110 peut réaliser plusieurs transactions simultanées avec diverses cartes SIM 131. On retrouve ainsi cette identifiant 123 dans les différents échanges de données entre ces deux serveurs. A réception, le serveur web de carte à puce 131 exécuté cette page en tenant compte des paramètres passés, ici en particulier le nombre aléatoire contenu dans la commande APDU. Selon un processus conventionnel, la carte SIM 130 chiffre ce nombre aléatoire à l'aide d'une clé symétrique (en alternative l'utilisation de clés asymétriques permet d'aboutir à une authentification similaire) qu'elle mémorise dans sa mémoire et à l'aide de moyens cryptographiques propres, puis renvoie cette donnée chiffrée à destination du serveur bancaire 110. Pour ce faire, une réponse HTTP est émise vers le navigateur 107, comprenant la page HTML suivante: Carte authentifiée Veuillez patienter, carte authentifiée... Le navigateur 107 affiche ainsi le message " Veuillez patienter, carte authentifiée..." à l'utilisateur. Au bout de 1 seconde, le navigateur 107 génère une nouvelle requête HTTP à destination du serveur bancaire 110 (https://www.mybank.com/) et comprenant la donnée chiffrée dans la réponse APDU 672F9DD49000. A réception, le serveur bancaire 110 peut vérifier cette donnée chiffrée à l'aide de la clé symétrique du serveur 110 de sorte à valider l'authentification des parties pour que s'en suivre la transaction bancaire à proprement parler. Cette vérification consiste notamment à calculer la valeur chiffrée à l'aide de la clé symétrique du serveur et du nombre aléatoire envoyé, et de comparer cette valeur chiffrée avec la valeur reçue. Ainsi, lorsque la carte SIM 130 est identifiée, le serveur bancaire 130 affiche la page d'accueil du service de banque à domicile en ayant garanti la présence de la carte SIM 130. En variante, cette authentification permet de déclencher une opération de transaction bancaire ou financière, par exemple conforme à la norme EMV (Europay Mastercard Visa). Lors d'opérations sensibles (transfert de compte à compte par exemple), le serveur 110 est de la même façon en mesure de communiquer avec la carte SIM 130 pour valider cette opération (qui ne sera ainsi possible qu'en ayant l'élément de sécurité et le PIN associé). L'initiation des échanges de données conformément à l'invention peut faire suite à des opérations plus complexes que le simple clic sur un lien d'une page HTML. A titre d'exemple, l'entité électronique 130 peut être un module microcircuit sécurisé NFC intégré parmi les composants du téléphone mobile 100. Le module NFC est utilisé dans une application de transaction bancaire avec un terminal de paiement sans fil. De par la portée courte distance spécifiée dans la norme NFC, l'utilisation d'un tel module NFC garantit l'accord implicite de l'utilisateur dans la transaction avec le terminal. Lorsque l'utilisateur souhaite payer un achat, il approche son téléphone 100 muni du module NFC 130 près d'un terminal de paiement du vendeur. Une communication s'établit de façon classique entre les deux équipements pour réaliser la transaction. Notamment, cette transaction peut comprendre la vérification, par le terminal, de données d'identification ou de validité présentes dans le module sécurisé NFC 130. Dans le cas où ces données sont périmées ou que d'autres données sont nécessaires pour poursuivre la transaction, le module NFC 130 initie alors une procédure de récupération de ces données auprès d'un serveur distant 110 conformément à l'objet de l'invention. Cette initiation de la procédure de récupération peut comprendre une commande d'exécution du navigateur 107 émise par le module NFC 130. Par exemple, cette commande spécifie au navigateur de charger une page HTML qui comprend, dans son entête, une redirection automatique vers la page initAuthent du module NFC 130. Ainsi, par cette commande, le module NFC 130 lance une première 30 requête HTTP émise par le navigateur 107 à laquelle réponses et autres requêtes HTTP s'enchaîneront conformément à l'invention. Afin de garantir un niveau élevé de confiance dans un module de traitement NFC ou entité équivalente 130, on s'assure que celui-ci ou celle-ci est sécurisé(e) conformément soit aux critères communs, soit à la norme FIPS. Ainsi, l'accès aux données du module NFC 130 par un serveur distant 110 est d'autant plus difficile et l'invention maintient une communication possible entre ces deux entités 130 et 110. Selon une alternative de réalisation, on peut prévoir que les fonctionnalités du module NFC 130 ci-dessus sont réparties sur deux modules distincts interconnectés; d'une part une entité serveur, par exemple une carte à puce, et d'autre part, une entité NFC pour communiquer avec le terminal externe. En référence à la figure 2, on a représenté à l'aide d'un diagramme le comportement du navigateur web 107 dans l'exemple de la figure 1 pour l'échange de données entre les deux serveurs 131 et 110. A l'étape 200, l'utilisateur lance le navigateur web 107 qui initie alors un contexte d'exécution propre et affiche une page demandée par l'utilisateur (201.html dans l'exemple ci-dessus). A l'étape 202, l'utilisateur sélectionne une action de la page affichée, ici clique sur le lien Banking. A l'étape 204, le navigateur 107 envoie une réponse HTTP à une requête précédente, à destination d'un des serveurs 131 et 110 selon la demande de l'utilisateur, ici à la carte SIM 131. Puis le navigateur 107 se met en attente (étape 206). A l'étape 208, le navigateur web 107 reçoit une requête HTTP de l'un ou l'autre des deux serveurs 131 et 110. A l'étape 210, le navigateur 107 lit les informations contenues dans la réponse. En pratique, il interprète les balises d'une page HTML. A l'étape 212, le navigateur 107 procède à l'affichage immédiat, sur l'écran 102, des messages (par exemple "Veuillez patienter, carte authentifiée...") contenus dans le corps de la page HTML. On attend ensuite un délai de content=1 seconde (fonction des paramètres passés dans la requête HTTP) à l'étape 214. Puis à l'étape 216, le navigateur 107 exécute l'instruction de redirection contenue dans la balise . Cette exécution provoque l'émission (étape 218) d'une nouvelle requête HTTP (par exemple GET https://www.mybank.com/HomeBanking.cgi?ID=123&Answer=672F9DD49000) à destination de l'autre serveur 131 ou 110. Dans cette requête, on note la transmission d'une ou plusieurs données passée(s) en paramètre de l'appel de la page HomeBanking.cgi. Il est toutefois envisageable de transmettre ces données d'une autre manière, par exemple par la transmission d'un fichier contenant ces données et que le navigateur 107 envoie dans la requête HTTP (ou FTP selon une autre réalisation) à destination de l'autre serveur. Le navigateur 107 retourne alors dans un état d'attente (étape 206) jusqu'à réception d'une autre réponse HTTP, généralement la réponse provenant dudit autre serveur. En référence à la figure 3, on a représenté le comportement similaire des deux serveurs web 131 et 110. A l'étape 300, le serveur considéré reçoit une requête HTTP en provenance du navigateur 107. Cette requête comprend notamment des données passées en paramètre (nombre aléatoire chiffré ou non, dans l'exemple ci-dessus). A l'étape 302, le serveur exécute, éventuellement en appelant d'autres applications en local, un traitement (ici la génération d'un nombre aléatoire pour le serveur 110 et le chiffrement de ce nombre pour le serveur 131) à l'aide par exemple des données passées en paramètre. A l'étape 304, le serveur considéré émet une réponse HTTP à destination du navigateur 107. Dans l'exemple précédent, cette réponse comprend une page HTML comportant notamment une instruction de redirection vers l'autre serveur et le résultat du traitement précédent comme donnée passée en paramètre de cette instruction. A l'étape 306, le serveur se met en attente d'une nouvelle requête (traitée à l'étape 300). Ainsi, il est possible de faire communiquer efficacement deux serveurs distants appartenant à des environnements (réseaux) distincts sans faire appel à de nouveaux modules ou équipements absents des appareils programmables actuels. On note que les étapes d'authentification décrites dans l'exemple ci-dessus constitue une première phase qui peut être suivie d'une phase de transaction financière ou bancaire, à proprement parler, qui n'est pas décrite de façon détaillée ici et qui peut, néanmoins, s'appuyer sur des échanges de données (de transaction) conformément à l'objet de l'invention. Les exemples qui précédent ne sont que des modes de réalisation de l'invention qui ne s'y limite pas. En particulier, l'entité électronique 130 peut être un dispositif de stockage de masse, par exemple de type clé USB ou carte mémoire (par exemple MMC). Dans ce cas, on prévoit que le microcontrôleur du dispositif de stockage de masse soit adapté et prévu pour exécuter une application serveur web allégée. On prévoit également que le téléphone mobile 100 met en oeuvre, en permanence, un logiciel permettant la communication (et les conversion de format qui vont bien) entre le navigateur 107 et le dispositif de stockage de masse 130 selon un protocole compatible. Par exemple, une solution adoptée consiste à ce que le logiciel convertisse les requêtes et réponses http (depuis et vers le navigateur 107) vers et depuis un fichier de données stocké dans la mémoire de masse en utilisant les commandes de base d'écriture/lecture d'un dispositif de stockage de masse. Ainsi, il est aisé au microcontrôleur de lire ce fichier (respectivement d'écrire dans ce fichier) et de récupérer (resp. transmettre) le contenu d'une requête HTTP émise par le navigateur (resp. d'une réponse à destination du navigateur). REVENDICATIONS 1. Procédé d'échange de données entre un premier serveur (131) hébergé dans une entité électronique (130) liée à un appareil programmable (100) et un deuxième serveur distant (110), lesdits premier et deuxième serveurs étant chacun adressables individuellement par l'appareil programmable au moyen d'adresses cibles respectives, le procédé comprenant les étapes suivantes : a. réception (208) par l'appareil programmable d'une réponse à une première requête, ladite réponse comprenant les données et une desdites adresses cibles ; b. exécution (216) de ladite réponse par un navigateur (107) mis en oeuvre sur l'appareil programmable de manière à entraîner l'émission (218) des données vers ladite adresse cible. 2. Procédé selon la revendication 1, dans lequel les étapes a) et b) sont réitérées, et ladite émission (218) d'une itération comprend la transmission de ladite première requête de l'itération suivante. 3. Procédé selon la revendication 1 ou 2, dans lequel ladite réponse 20 est transmise selon le protocole HTTP. 4. Procédé selon la revendication précédente, dans lequel le serveur émetteur (131, 110) de la réponse est un serveur HTTP. 5. Procédé selon l'une des revendications 3 et 4, dans lequel ladite réponse comprend une page HTML de vérification d'un code PIN d'utilisateur. 25 6. Procédé selon l'une des revendications 1 à 5, dans lequel ladite émission (218) des données vers l'adresse cible est effectuée selon le protocole HTTP. 7. Procédé selon la revendication précédente, dans lequel le serveur destinataire correspondant à l'adresse cible est un serveur web mettant en 30 oeuvre le protocole HTTP. 8. Procédé selon l'une des revendications précédentes, dans lequel ladite réponse comprend une commande agencée pour être exécutée par ledit navigateur (107). 9. Procédé selon la revendication 8, dans lequel ladite commande est incluse dans le corps de ladite réponse. 10. Procédé selon l'une quelconque des revendications précédentes, dans lequel ladite commande comprend ladite adresse cible. 11. Procédé selon l'une quelconque des revendications 1 à 10, dans lequel ladite commande comprend une commande d'envoi d'une requête HTTP. 12. Procédé selon la revendication précédente, dans lequel ladite commande d'envoi comprend un lien externe vers un serveur HTTP. 13. Procédé selon la revendication précédente, dans lequel ladite requête est selon le protocole sécurisé HTTPS. 14. Procédé selon l'une des revendications 8 à 13, dans lequel ladite commande agencée pour être exécutée par ledit navigateur comprend un commande locale agencée pour être exécutée au niveau du serveur destinataire des données. 15. Procédé selon la revendication précédente, dans lequel ladite commande locale est conforme à la norme ISO 7816. 16. Procédé selon l'une des revendications 14 et 15, dans lequel lesdites données sont passées en paramètre de la commande locale. 17. Procédé selon l'une des revendications précédentes, dans lequel ladite émission (218) des données comprend la transmission d'une requête, le procédé comprenant une étape de conversion de ladite requête en une commande compatible avec des moyens de communication prévus dans ladite entité électronique. 18. Procédé selon l'une quelconque des revendications précédentes, dans lequel ladite entité électronique (130) comprend un serveur HTTP (131). 19. Procédé selon l'une quelconque des revendications précédentes, dans lequel ladite entité électronique (130) est agencée pour se connecter de façon amovible audit appareil programmable (100), et le procédé comprend uneétape préalable de connexion de ladite entité électronique audit appareil programmable de sorte à former une liaison pour communiquer. 20. Procédé selon la revendication 19, dans lequel ladite connexion est effectuée au moyen d'une interface USB. 21. Procédé selon la revendication 19, dans lequel ladite connexion est effectuée au moyen d'une interface ISO 7816. 22. Procédé selon l'une quelconque des revendications précédentes, dans lequel ladite entité électronique (130) est dépourvue d'alimentation autonome. 23. Procédé selon l'une quelconque des revendications 1 à 22, dans lequel ladite entité électronique (130) comprend une clé USB. 24. Procédé selon l'une quelconque des revendications 1 à 22, dans lequel ladite entité électronique (130) comprend une carte à microcircuit. 25. Procédé selon la revendication 24, dans lequel ladite carte est conforme à la norme ISO 7816. 26. Procédé selon la revendication 24, dans lequel ladite carte comprend une carte mémoire. 27. Procédé selon l'une quelconque des revendications 1 à 22, dans lequel ladite entité électronique (130) comprend une carte de téléphonie mobile. 28. Procédé selon la revendication précédente, dans lequel ladite carte comprend une carte SIM. 29. Procédé selon l'une quelconque des revendications 1 à 18, dans lequel ladite entité électronique (130) comprend un module de microcircuit intégré dans ledit appareil programmable (100) et hébergeant ledit premier serveur (131). 30. Procédé selon la revendication 29, dans lequel ladite entité électronique (130) comprend des moyens de communication sans fils conformes à la norme NFC intégrés audit module de microcircuit. 31. Procédé selon la revendication 29, dans lequel ladite entité électronique (130) comprend des moyens de communication sans fils conformes à la norme NFC intégrés à un deuxième module de microcircuit interconnecté au premier module de microcircuit. 32. Procédé selon l'une quelconque des revendications précédentes, dans lequel ladite entité électronique (130) est sécurisée conformément aux critères communs ou à la norme FIPS. 33. Procédé selon l'une quelconque des revendications précédentes, dans lequel ledit appareil programmable (100) comprend un ordinateur personnel. 34. Procédé selon la revendication précédente, dans lequel ledit appareil programmable (100) est un téléphone mobile. 35. Procédé selon l'une des revendications 33 et 34, dans lequel ladite entité électronique est un équipement amovible de poche. 36. Procédé selon l'une quelconque des revendications précédentes, dans lequel ledit deuxième serveur distant (110) et ledit appareil programmable (100) communiquent au travers d'au moins un réseau de télécommunication (120). 37. Procédé selon la revendication précédente, dans lequel ledit réseau de télécommunication (120) comprend un réseau de télécommunication mobile. 38. Procédé selon l'une quelconque des revendications précédentes, dans lequel au moins une desdites adresses comprend une adresse IP. 39. Procédé selon l'une quelconque des revendications précédentes, dans lequel lesdites données sont des données de transaction bancaire. 40. Procédé d'authentification entre un premier et un deuxième serveur, comprenant un échange de token basé sur un mécanisme de Challenge-Response par l'échange de données selon l'une quelconque des revendications 1 à 39. 41. Système d'échange de données entre un premier et un deuxième serveurs, le système comprenant un premier serveur (131) hébergé dans une entité électronique (130) liée à un appareil programmable (100) et un deuxième serveur distant (110), lesdits premier et deuxième serveurs étant chacun adressables individuellement par l'appareil programmable (100) au moyen d'adresses cibles respectives, l'appareil programmable comportant :- des moyens de réception d'une réponse à une première requête, ladite réponse comprenant les données et une desdites adresses cibles ; et - un navigateur (107) agencé pour exécuter ladite réponse de manière à entraîner l'émission des données vers ladite adresse cible. 42. Système selon la revendication précédente, dans lequel ledit navigateur est agencé pour émettre lesdites données sous forme d'une requête, ledit système comprenant des moyens de conversion de ladite requête en une commande compatible avec des moyens de communication prévu dans ladite entité électronique. 43. Procédé d'émission de données depuis un serveur distant (110) à destination d'un serveur (131) hébergé dans une entité électronique (130) adressable au moyen d'une adresse cible par un appareil programmable (100) mettant en oeuvre un navigateur (107), caractérisé par une étape d'émission (304), en réponse à une première requête, par le serveur distant et à destination de l'appareil programmable, d'une réponse lisible par le navigateur (107) et comprenant les données, l'adresse cible et une instruction de redirection des données à l'adresse cible. 44. Procédé selon la revendication précédente, dans lequel l'instruction de redirection comprend une commande agencée pour être exécutée par ledit navigateur. 45. Procédé selon la revendication précédente, dans lequel ladite commande comprend une commande locale apte à être exécutée par l'entité électronique. 46. Procédé selon la revendication précédente, dans lequel ladite 25 commande locale est conforme à la norme ISO 7816. 47. Procédé selon la revendication 45 ou 46, dans lequel lesdites données sont passés en paramètre de ladite commande locale. 48. Serveur (110) comprenant des moyens d'émission agencés pour émettre, en réponse à une première requête et à destination d'un appareil 30 programmable mettant en oeuvre un navigateur, une réponse lisible par le navigateur et comprenant des données, une adresse cible d'un deuxièmeserveur hébergé par une entité électronique liée audit appareil programmable et une instruction de redirection des données à l'adresse cible. 49. Procédé d'émission de données depuis un premier serveur (131) hébergé dans une entité électronique (130) liée à un appareil programmable (100) mettant en oeuvre un navigateur (107), à destination d'un deuxième serveur distant (110) ayant une adresse cible, caractérisé par une étape d'émission (304), en réponse à une première requête, par ledit premier serveur (131) et à destination de l'appareil programmable (100), d'une réponse lisible par le navigateur (107) et comprenant les données, l'adresse cible et une instruction de redirection des données à l'adresse cible. 50. Procédé selon la revendication précédente, comprenant une étape préalable de traitement effectuée par ladite entité électronique de sorte à générer lesdites données. 51. Procédé selon la revendication précédente, dans lequel ledit traitement comprend un traitement cryptographique. 52. Procédé selon la revendication précédente, dans lequel ledit traitement met en oeuvre des données tierces reçues par l'entité électronique selon le procédé d'émission selon l'une quelconque des revendications 43 à 47. 53. Entité électronique (130) comprenant un premier serveur (131) et des moyens de liaison (134) à un appareil programmable (100) mettant en oeuvre un navigateur (107), ledit premier serveur comprenant : - des moyens d'émission agencés pour émettre, en réponse à une première requête et à destination de l'appareil programmable, une réponse lisible par le navigateur et comprenant des données, une adresse cible d'un deuxième serveur distant et une instruction de redirection des données à l'adresse cible. 54. Entité électronique (130) selon la revendication 53, dans laquelle lesdits moyens de liaison comprennent une interface USB. 55. Entité électronique (130) selon la revendication 53, dans laquelle 30 lesdits moyens de liaison comprennent une interface conforme à la norme ISO 7816. 6. Entité électronique (130) selon l'une des revendications 53 à 55, comprenant des moyens cryptographiques agencés pour générer lesdites données. 57. Entité électronique (130) selon la revendication précédente, 5 comprenant au moins une clé cryptographique mise en oeuvre par lesdits moyens cryptographiques. 58. Entité électronique (130) selon l'une des revendications 53 à 57, dans laquelle ledit premier serveur (131) est un serveur HTTP. 59. Entité électronique (130) selon l'une des revendications 53 à 58, 10 comprenant des moyens de connexion amovible agencés pour se connecter de façon amovible audit appareil programmable (100). 60. Entité électronique (130) selon la revendication précédente, dans laquelle les moyens de connexion comprennent des bornes d'alimentation électrique à une source d'alimentation externe. 15 61. Entité électronique (130) selon la revendication 59 ou 60, dans lequel les moyens de connexion comprennent une interface USB. 62. Entité électronique (130) selon la revendication 59 ou 60, dans lequel les moyens de connexion comprennent une interface conforme à la norme ISO 7816. 20 63. Entité électronique (130) selon l'une des revendications 53 à 62, comprenant un module de microcircuit intégré dans ledit appareil programmable (100) et hébergeant ledit premier serveur (131). 64. Entité électronique (130) selon la revendication 63, comprenant des moyens de communication sans fils conformes à la norme NFC intégrés 25 audit module de microcircuit 65. Entité électronique (130) selon la revendication 63, comprenant des moyens de communication sans fils conformes à la norme NFC intégrés à un deuxième module de microcircuit interconnecté au premier module de microcircuit. 30 66. Entité électronique (130) selon l'une des revendications 53 à 65, de type équipement amovible de poche.67. Entité électronique (130) selon l'une des revendications 53 à 65, dans laquelle l'entité électronique est une clé USB. 68. Entité électronique (130) selon l'une des revendications 53 à 65, dans laquelle l'entité électronique est une carte à microcircuit. 69. Entité électronique (130) selon l'une des revendications 53 à 65, dans laquelle l'entité électronique est une carte de téléphonie mobile. 70. Entité électronique (130) selon la revendication précédente, dans laquelle l'entité électronique est une carte SIM.10