Brevet FR3003058A1 — publié le 20140912

Système et procédé de gestion d'au moins une application en ligne, objet portable utilisateur USB et dispositif distant du système DOMAINE TECHNIQUE DE L'INVENTION La présente invention se rapporte au domaine de la sécurisation des échanges de données entre un hôte et un client, par exemple entre un serveur et un objet électronique portable et connectable. Plus précisément, l'invention se rapporte à un système comprenant un dispositif portable USB pouvant gérer des applications en ligne. Une application possible se situe dans le cadre de jeux en ligne, par exemple, un jeu de football en ligne, de handball, de basketball, de Formule 1, etc. pour permettre à des utilisateurs de jouer en sélectionnant à l'aide d'une interface affichée sur un terminal un joueur ou un sportif connu mémorisé sur le serveur dans l'application et en se faisant représenter dans le jeu par ce joueur. ARRIÈRE-PLAN TECHNOLOGIQUE DE L'INVENTION L'échange de données numériques réalisé entre différents dispositifs connectés via un réseau local ou étendu pose un véritable problème de sécurité par une utilisation frauduleuse du dispositif portable, par exemple. En effet, plusieurs problèmes peuvent se poser. Par exemple, il existe le problème de savoir comment être sûr que le dispositif portable est connecté ou permet une connexion d'un terminal au serveur distant. En effet, un utilisateur pourrait utiliser un terminal dans lequel il entre l'adresse URL du serveur pour se connecter au serveur distant et, ainsi, utiliser frauduleusement des applications dédiés au propriétaire du dispositif portable physique. D'autre part un dispositif portable comprenant un marqueur tel qu'un code à barres lu par un lecteur spécifique à un serveur permet d'authentifier un utilisateur, mais ne permet pas de s'assurer que le terminal également connecté au serveur est utilisé par l'utilisateur qui s'est authentifié. Enfin même si le lecteur est intégré au terminal ceci nécessite l'adjonction de matériel et logiciel. Il existe également le problème de savoir comment contrôler le nombre de fois pour lesquelles le dispositif portable est utilisé pour obtenir les applications auxquelles le dispositif portable donne droit. DESCRIPTION GÉNÉRALE DE L'INVENTION La présente invention a donc pour objet de pallier un ou plusieurs des inconvénients de l'art antérieur en proposant un système simple permettant de contrôler la connexion physique d'un dispositif portable au terminal sans adjonction de matériel ou de logiciel et la possession physique du dispositif portable par un utilisateur, tout en permettant de contrôler l'utilisation du dispositif portable sur un terminal pour l'installation d'objets sur une page Internet. À cet effet, l'invention concerne un système de gestion d'au moins une application en ligne. Le système est caractérisé en ce qu'il comprend au moins deux dispositifs jouant le rôle d'hôte ou de client, dont au moins le dispositif client est portable, un terminal communiquant avec un réseau via des moyens de connexion ou de communication du terminal, le dispositif client se connectant au terminal par une interface du terminal comme périphérique clavier, chaque dispositif comportant au moins une zone mémoire permanente non volatile programmable et des moyens de traitements des données, le terminal comprenant une zone mémoire et des moyens de traitement des données, le système comprenant un algorithme d'authentification, la zone mémoire du dispositif client comprenant un identifiant unique et des messages enregistrés en code clavier et traités comme tel par le terminal, la zone mémoire du dispositif hôte comprenant au moins un algorithme d'identification de l'utilisateur, un algorithme de vérification de validité du dispositif client et un algorithme d'exécution d'application, la zone mémoire du dispositif hôte comprenant en outre une base de données comprenant au moins un premier fichier ou tableau associant les identifiants d'utilisateurs avec les mots de passe de chaque utilisateur, un deuxième fichier ou tableau associant au moins un état d'utilisation du dispositif client avec l'identifiant unique d'un dispositif client, un troisième fichier ou tableau associant l'adresse URL du dispositif hôte avec un identifiant de l'application, un quatrième fichier ou tableau associant les identifiants d'utilisateurs avec au moins un identifiant de l'application, le dispositif hôte étant identifié par une adresse URL, la zone mémoire du dispositif hôte comprenant en outre au moins une application. Selon une autre particularité, l'interface du terminal est de type USB. Selon une autre particularité, la zone mémoire du dispositif client comprenant un premier compteur incrémenté par la génération d'un mot de passe et une clef secrète partagée utilisés par un module de l'algorithme d'authentification dans le dispositif client, la zone mémoire du dispositif client comprenant en outre au moins l'adresse URL du dispositif hôte ainsi qu'une indication de l'identification de l'application en code interprété par le terminal comme un code clavier, la zone mémoire du dispositif hôte comprenant en outre la clef secrète partagée avec le dispositif client associé à un utilisateur et un cinquième fichier ou tableau associant un deuxième compteur avec l'identifiant unique de chaque dispositif client. Selon une autre particularité, l'algorithme d'authentification comprend : un premier module mis en oeuvre par les moyens de traitement du dispositif client générant un premier mot de passe à partir de la clef secrète partagée et du premier compteur à un rang n, le premier module incrémentant le premier compteur à un rang n+1 lorsque le premier mot de passe est généré, le premier module étant stocké dans la zone mémoire du dispositif client, un deuxième module mis en oeuvre par les moyens de traitement du dispositif hôte générant un deuxième mot de passe à partir de la clef secrète partagée et du deuxième compteur à un rang p, le deuxième compteur étant celui associé à l'identifiant du dispositif client à partir cinquième fichier ou tableau, le deuxième module étant stocké dans la zone mémoire du dispositif hôte, un troisième module mis en oeuvre par les moyens de traitement du dispositif hôte comparant le premier mot de passe généré par les moyens de traitement du dispositif client et le deuxième mot de passe généré par les moyens de traitement du dispositif hôte, le premier mot de passe ayant été envoyé au dispositif hôte par le dispositif client, le troisième module incrémentant le deuxième compteur à un rang p+1 lorsque le deuxième mot de passe est généré, le troisième module étant stocké dans la zone mémoire du dispositif hôte. Selon une autre particularité, le dispositif client comprend un fichier d'utilisation stocké dans une zone mémoire secrète du dispositif client, le fichier d'utilisation comprenant une information d'état d'utilisation du dispositif client : un état correspondant à un état d'utilisation « utilisé » du dispositif client et un état correspondant à un état d'utilisation « non utilisé », la zone mémoire secrète de la zone mémoire étant accessible au dispositif hôte par un canal sécurisé entre le dispositif client et le dispositif hôte, le canal sécurisé étant ouvert par un algorithme d'ouverture d'un canal sécurisé. Selon une autre particularité, la zone mémoire du dispositif hôte comprend un algorithme d'ouverture d'un canal sécurisé, une application d'installation d'un algorithme d'ouverture d'un canal sécurisé entre le dispositif client et le dispositif hôte et un jeu de trois clefs secrètes, l'application d'installation étant destinée à être envoyée au dispositif client pour installer l'algorithme d'ouverture sur le terminal pour commander, par des messages envoyés au dispositif client via l'interface, la modification de l'information du fichier d'utilisation stocké dans la zone mémoire secrète du dispositif client, la zone mémoire du dispositif hôte comprenant également un algorithme de changement de l'information contenue dans le fichier d'utilisation. Selon une autre particularité, la zone mémoire du dispositif client comprend un jeu de trois clefs secrètes identique au jeu de trois clefs secrètes du dispositif hôte, le terminal comprenant l'algorithme d'ouverture d'un canal sécurisé. Selon une autre particularité, l'application envoie des commandes ou messages au terminal permettant l'affichage d'une image stockée dans la zone mémoire du dispositif hôte par les moyens d'affichage du terminal selon des coordonnées de placement de l'image dans l'affichage d'une page Internet. Selon une autre particularité, l'application envoie des commandes ou messages au terminal permettant l'affichage d'une animation stockée dans la zone mémoire du dispositif hôte par les moyens d'affichage du terminal selon des coordonnées de placement de l'animation dans l'affichage d'une page Internet. Selon une autre particularité, l'invention concerne également un procédé de gestion d'au moins une application mis en oeuvre par le système selon l'invention, le terminal comprenant au moins une connexion à un réseau Internet, un moyen de saisie et un moyen d'affichage caractérisé en ce que procédé comprend au moins : une étape de connexion à l'adresse URL du dispositif hôte (H) fournie par un dispositif client lu par le terminal, une étape d'authentification du dispositif client mise en oeuvre par l'algorithme d'authentification, si le dispositif client est authentifié, le procédé comprenant en outre une étape d'identification de l'utilisateur mise en oeuvre par l'algorithme d'identification de l'utilisateur, si l'utilisateur est identifié, le procédé comprenant en outre une étape de vérification de validité du dispositif client, si le dispositif client est validé, le procédé comprenant en outre une étape d'exécution de l'application. Selon une autre particularité, l'étape de connexion à l'adresse URL du dispositif hôte comprend : - une étape de connexion du dispositif client à l'adresse URL du dispositif hôte fournie par l'information stockée dans la zone mémoire du dispositif client par l'intermédiaire d'une connexion au terminal, - une étape d'envoi par le dispositif client vers le dispositif hôte de l'identifiant unique du dispositif client. Selon une autre particularité, l'étape d'authentification mise en oeuvre par l'algorithme d'authentification comprend : - une étape de génération, par le premier module mis en oeuvre par les moyens de traitement du dispositif client, d'un premier mot de passe à partir de la clef secrète partagée et du premier compteur à un rang n, - une étape d'incrémentation du premier compteur à un rang n+1, - une étape de génération, par le deuxième module mis en oeuvre par les moyens de traitement du dispositif hôte, d'un deuxième mot de passe à partir de la clef secrète partagée et du deuxième compteur à un rang p le deuxième compteur étant celui associé à l'identifiant unique du dispositif client à partir du cinquième fichier ou tableau, - une étape d'envoi par le dispositif client au dispositif hôte du premier mot de passe via le terminal, - une étape de comparaison, par le troisième module, du premier mot de passe et du deuxième mot de passe ; si le premier mot de passe est identique au deuxième mot de passe, le deuxième compteur étant incrémenté à un rang p+1 et le dispositif client étant authentifié. Selon une autre particularité, l'étape d'identification mise en oeuvre par l'algorithme d'identification de l'utilisateur comprend les sous-étapes suivantes : - une étape d'affichage par le moyen d'affichage du terminal d'au moins deux zones de saisie, l'affichage étant commandé par l'algorithme d'identification, - une étape de saisie d'un identifiant de l'utilisateur par les moyens de saisie du terminal dans la première zone de saisie, - une étape de saisie d'un mot de passe associé à l'identifiant par les moyens de saisie du terminal dans la deuxième zone de saisie, - une étape de cryptage par les moyens de traitement du terminal et d'envoi de l'identifiant et du mot de passe au dispositif hôte, - une étape de décryptage par les moyens de traitement du dispositif hôte et de vérification de l'identifiant et du mot de passe par l'algorithme d'identification à partir du premier fichier ou tableau de la base de données stockée dans la zone mémoire du dispositif client ; si le premier fichier ou tableau de la base de données comprend l'identifiant de l'utilisateur associé avec le mot de passe saisi par l'utilisateur, l'utilisateur étant identifié. Selon une autre particularité, l'étape de vérification de validité du dispositif client mise en oeuvre par l'algorithme de vérification de validité comprend : - une étape de vérification, dans le deuxième tableau, de l'état d'utilisation du dispositif client à partir de l'identifiant unique du dispositif client ; si l'état d'utilisation correspond à un état « utilisé », le procédé comprenant : - une étape de vérification d'une ou plusieurs applications associées à un autre ou d'autres dispositifs client à partir de l'identifiant de l'utilisateur d'après le quatrième tableau, - une étape d'exécution par les moyens de traitement du terminal ou les moyens de traitement du dispositif hôte de la ou des autres applications associées à un autre ou d'autres dispositifs client sans l'exécution de l'application associée au dispositif client ; si l'état d'utilisation correspond à un état « non utilisé », le dispositif client étant validé. Selon une autre particularité, l'étape de vérification de validité du dispositif client mise en oeuvre par l'algorithme de vérification de validité comprend : - une étape de vérification, dans le fichier d'utilisation stocké dans la zone mémoire secrète du dispositif client, de l'information de l'état d'utilisation du dispositif client après une étape d'ouverture d'un canal sécurisé par un algorithme d'ouverture d'un canal sécurisé ; si l'état d'utilisation correspond à un état « utilisé », le procédé comprenant : - une étape de vérification d'une ou plusieurs applications associées à un autre ou d'autres dispositifs client à partir de l'identifiant de l'utilisateur d'après le quatrième tableau, - une étape d'exécution par les moyens de traitement du terminal ou les moyens de traitement du dispositif hôte de la ou des autres applications associées à un autre ou d'autres dispositifs client sans l'exécution de l'application associée au dispositif client ; si l'état d'utilisation correspond à un état « non utilisé », le dispositif client étant validé. Selon une autre particularité, l'étape d'exécution de l'application mise en oeuvre par l'algorithme d'exécution d'application comprend : - une étape de vérification de l'application à exécuter à partir de l'indication comprise dans ou associé à l'adresse URL stockée dans la zone mémoire du dispositif client d'après le troisième tableau, - une étape d'envoi de commande par le dispositif hôte pour permettre l'affichage sur le moyen d'affichage du terminal d'une fenêtre présentant un choix d'exécution ou non de l'application à exécuter, la fenêtre représentant au moins une touche matérielle ou virtuelle permettant l'exécution de l'application et une touche matérielle ou virtuelle permettant le refus d'exécution de l'application, - une étape de choix par les moyens de saisie du terminal par l'utilisateur, si l'utilisateur actionne le moyen de saisie de telle manière que la touche matérielle ou virtuelle permettant le refus d'exécution est validée, le procédé comprend une étape d'exécution par les moyens de traitement du terminal ou les moyens de traitement du dispositif hôte de la ou des applications associées à un autre ou d'autres dispositifs client sans l'exécution de l'application associée au dispositif client ; si l'utilisateur actionne le moyen de saisie de telle manière que la touche matérielle ou virtuelle permettant l'exécution est validée, le procédé comprenant : - une étape d'exécution par les moyens de traitement du terminal ou les moyens de traitement du dispositif hôte de la ou des applications associées à un autre ou d'autres dispositifs client sans l'exécution de l'application associée au dispositif client, - une étape d'exécution de l'application par les moyens de traitement du terminal ou les moyens de traitement du dispositif hôte de l'application associée au dispositif client, - une étape de modification de l'information d'utilisation de l'état « non utilisé » pour passer l'information d'utilisation à l'état « utilisé ». Selon une autre particularité, l'étape d'authentification est suivie d'une étape d'installation par les moyens de traitement du terminal d'un algorithme d'ouverture d'un canal sécurisé, une application d'installation de l'algorithme d'ouverture d'un canal sécurisé ayant été envoyée par le dispositif hôte. Selon une autre particularité, lors de l'étape de choix, si l'utilisateur actionne le moyen de saisie de telle manière que la touche permettant l'exécution est validée, l'étape de modification de l'information d'utilisation de l'état « non utilisé » en état « utilisé » correspond à la modification de l'information du fichier d'utilisation stocké dans la zone mémoire secrète du dispositif client après une étape d'ouverture d'un canal sécurisé par un algorithme d'ouverture d'un canal sécurisé mis en oeuvre par les moyens de traitement du dispositif hôte et du terminal. Selon une autre particularité, l'algorithme d'ouverture d'un canal sécurisé est réalisée via un algorithme triple DES et un jeu de trois clefs secrètes selon un protocole de sécurité spécifié du type GlobalPlatform, l'algorithme triple DES et le jeu de trois clefs secrètes étant enregistrés dans la zone mémoire du dispositif hôte et du dispositif client, l'algorithme d'ouverture d'un canal sécurisé comprend : a) une étape d'ouverture de session par les moyens de traitement du dispositif hôte, suivi de la génération d'un compteur de session par le dispositif client envoyé au dispositif hôte, le compteur de session étant incrémenté à chaque ouverture d'une nouvelle session, b) une étape de dérivation des clefs secrètes enregistrées dans la mémoire du dispositif client, réalisé par les moyens de traitement dudit dispositif via l'algorithme triple DES utilisant le compteur de session et un nombre aléatoire hôte généré et envoyé au dispositif client par les moyens de traitement du dispositif hôte, c) une étape de génération de cinq clefs dérivées S-ENC, R-ENC, CMAC, R-MAC et S-DEK qui utilisées avec l'algorithme triple DES, permettent respectivement de chiffrer les commandes envoyées à un dispositif, de chiffrer les réponses du dispositif, de générer une signature pour chaque commande, de générer une signature pour chaque réponse, et de chiffrer des données confidentielles, d) une étape de génération par les moyens de traitement du dispositif client d'un cryptogramme client, via l'algorithme triple DES utilisant la clef dérivée S-ENC, le nombre aléatoire hôte et un nombre aléatoire client généré par les moyens de traitement du dispositif client, e) une étape d'envoi par les moyens de traitement du dispositif client vers le dispositif hôte, du compteur de session, du nombre aléatoire client et du cryptogramme client calculé à l'étape précédente, suivi du calcul et de la génération des cinq clefs dérivées par les moyens de traitement du dispositif hôte, f) une étape de génération, par les moyens de traitement du dispositif hôte, du cryptogramme client via l'algorithme triple DES utilisant la clef dérivée S-ENC, le nombre aléatoire hôte et le nombre aléatoire client généré par les moyens de traitement du dispositif client, g) une étape de comparaison par les moyens de traitement du dispositif hôte des cryptogrammes client respectivement calculés par le dispositif client et le dispositif hôte, suivi de l'authentification du dispositif client si les deux calculs du cryptogramme client sont identiques, h) une étape de génération par les moyens de traitement du dispositif hôte (H) d'un cryptogramme hôte, via l'algorithme triple DES utilisant la clef dérivée S-ENC, le nombre aléatoire hôte et le nombre aléatoire client, i) une étape d'envoi par les moyens de traitement du dispositif hôte vers le dispositif client, du cryptogramme hôte calculé à l'étape précédente, j) une étape de génération, par les moyens de traitement du dispositif client, du cryptogramme hôte via l'algorithme triple DES utilisant la clef dérivée S-ENC, le nombre aléatoire hôte et le nombre aléatoire client, k) une étape de comparaison par les moyens de traitement du dispositif client des cryptogrammes hôte respectivement calculés par le dispositif hôte et le dispositif client, suivi de l'authentification du dispositif hôte si les deux calculs du cryptogramme hôte sont identiques, I) une étape de confirmation de l'ouverture d'une session et du canal sécurisé à travers lequel les prochaines commandes et/ou réponse générées par les dispositifs hôte et client seront réalisées. Selon une autre particularité, lors de l'étape de choix, si l'utilisateur actionne le moyen de saisie de telle manière que la touche permettant l'exécution est validée, l'étape de modification de l'information d'utilisation de l'état « non utilisé » en état d'utilisation « utilisé » correspond à la modification de l'état en association avec l'identifiant unique du dispositif client sur le deuxième fichier ou tableau. L'invention concerne également un dispositif portable utilisateur formant un dispositif client du système selon l'invention et comprenant une zone mémoire sécurisée non volatile, des moyens de connexion à une interface terminal et des moyens de traitement de données, la zone mémoire comprenant au moins un identifiant unique et des messages enregistrés en code clavier et traités comme tel par le terminal. Selon une autre particularité, les moyens de connexion sont de type USB. Selon une autre particularité, la zone mémoire du dispositif portable comprend un premier compteur incrémenté par la génération d'un mot de passe et une clef secrète partagée, la zone mémoire du dispositif portable comprenant en outre au moins l'adresse URL du dispositif hôte ainsi qu'une indication de l'identification de l'application et l'identifiant unique du dispositif portable en code interprété par le terminal comme un code clavier. Selon une autre particularité, la zone mémoire du dispositif portable comprend un premier module mis en oeuvre par les moyens de traitement du dispositif portable générant un premier mot de passe à partir de la clef secrète partagée et du premier compteur à un rang n, le premier module incrémentant le premier compteur à un rang n+1 lorsque le premier mot de passe est généré. Selon une autre particularité, le dispositif portable comprend un fichier d'utilisation stocké dans une zone mémoire secrète du dispositif portable, le fichier d'utilisation comprenant une information d'état d'utilisation du dispositif portable : un état correspondant à un état d'utilisation « utilisé » du dispositif portable et un état correspondant à un état d'utilisation « non utilisé », la zone mémoire secrète comprenant le fichier d'utilisation étant accessible au serveur par un canal sécurisé entre le dispositif portable et le dispositif distant, le canal sécurisé étant ouvert par un algorithme d'ouverture d'un canal sécurisé. Selon une autre particularité, la zone mémoire du dispositif portable comprend un algorithme d'ouverture d'un canal sécurisé et un jeu de trois clefs secrètes identique au jeu de trois clefs secrètes du dispositif distant. L'invention concerne également un dispositif distant formant un dispositif hôte du système selon l'invention, comprenant une zone mémoire 10 sécurisée non volatile, des moyens de communication et des moyens de traitement de données, le dispositif distant étant caractérisé en ce que le dispositif distant est identifié par une adresse URL, la zone mémoire du dispositif distant comprenant au moins un algorithme d'identification de l'utilisateur, un algorithme de vérification de 15 validité du dispositif portable, un algorithme d'exécution d'application, la zone mémoire du dispositif distant comprenant en outre une base de données comprenant au moins un premier fichier ou tableau associant les identifiants d'utilisateurs avec les mots de passe de chaque utilisateur des dispositifs client, un deuxième fichier ou tableau associant au moins un état 20 d'utilisation du dispositif portable avec l'identifiant unique d'un dispositif portable, un troisième fichier ou tableau associant l'adresse URL du dispositif distant avec un identifiant de l'application, un quatrième fichier ou tableau associant les identifiants d'utilisateurs avec au moins un identifiant de l'application, 25 la zone mémoire du dispositif distant comprenant en outre au moins une application. Selon une autre particularité, la zone mémoire du dispositif distant comprend : un cinquième fichier ou tableau associant un deuxième compteur avec 30 l'identifiant unique de chaque dispositif client, un deuxième module mise en oeuvre par les moyens de traitement du dispositif distant générant un deuxième mot de passe à partir de la clef secrète partagée et du deuxième compteur à un rang p, un troisième module comparant le premier mot de passe généré par les moyens de traitement du dispositif portable et le deuxième mot de passe généré par les moyens de traitement du dispositif distant, le premier mot de passe ayant été étant envoyé au dispositif distant par le dispositif portable, le troisième module incrémentant le deuxième compteur à un rang p+1 lorsque le deuxième mot de passe est généré. Selon une autre particularité, la zone mémoire du dispositif hôte comprend un algorithme d'ouverture d'un canal sécurisé, une application d'installation d'un algorithme d'ouverture d'un canal sécurisé entre la zone mémoire secrète du dispositif client et le dispositif hôte et un jeu de trois clefs secrètes, l'application d'installation étant destinée à être envoyée au dispositif client pour installer l'algorithme d'ouverture sur le terminal pour commander, par des messages envoyés au dispositif client via l'interface, la modification de l'information du fichier d'utilisation stocké dans la zone mémoire secrète du dispositif client. L'invention, avec ses caractéristiques et avantages, ressortira plus clairement à la lecture de la description faite en référence aux dessins annexés dans lesquels : La figure 1 illustre le dispositif portable dans un mode de réalisation. La figure 2 illustre le système de gestion dans un mode de réalisation. La figure 3 représente un organigramme illustrant la première partie du 25 procédé. La figure 4 représente la suite de l'organigramme de la figure 3 illustrant le procédé. La figure 5 illustre un exemple de page internet représentant un terrain de football sur laquelle aucune image de joueur n'a été installée. La figure 6 illustre l'exemple de la figure 5 dans lequel une image de joueur a été installée. La figure 7 illustre les étapes d'ouverture d'un canal sécurisé ayant les spécifications GlobalPlatform. DESCRIPTION DES MODES DE RÉALISATION PRÉFÉRÉS DE L'INVENTION L'invention va être décrite en référence aux figures énumérées ci- dessus. Le système de gestion d'au moins une application en ligne comprend au moins deux dispositifs jouant le rôle d'hôte (H) ou de client (Cl), dont au moins le dispositif client (Cl) est portable Le système peut comprendre un terminal (2) qui communique avec un réseau (22) via des moyens de connexion ou de communication du terminal (2) On comprendra que le terminal (2) est un moyen informatique personnel qui peut être un ordinateur PC portable ou de bureau, une tablette, un smartphone ou autre moyen équivalent. Ce moyen informatique est connectable à un réseau (22) tel qu'Internet par des moyens de connexion ou communication et comprenant au moins une interface, par exemple USB, permettant de connecter un périphérique ou tout autre dispositif connectable à Internet, un moyen d'affichage (21) et un moyen de saisie (23). Le moyen de saisie (23) est connecté par un bus aux moyens de traitement du moyen informatique et à un connecteur ou moyen de connexion selon la même norme. Les moyens de traitement, tel qu'un processeur, permettent l'exécution de lignes de commande envoyées au moyen informatique. On comprendra que le moyen de saisie (23) peut être par exemple un clavier d'ordinateur. Le moyen d'affichage peut être un écran tactile ou non tactile. Dans le cas d'un écran tactile, le moyen de saisie peut être affiché sur l'écran. Le terminal (2) peut également comprendre une zone mémoire comprenant au moins un système d'exploitation et des programmes tel qu'un navigateur Internet. Chaque dispositif du système, client (Cl) et hôte (H), comporte au moins une zone mémoire permanente non volatile programmable et des 5 moyens de traitements des données. Le système comprend un algorithme d'authentification permettant, par exemple, de s'assurer que l'utilisateur utilise le dispositif client (Cl). La zone mémoire du dispositif client (Cl) comprend un identifiant unique. L'identifiant unique peut être le numéro de série du dispositif client. 10 La zone mémoire du dispositif client (Cl) comprend en outre des messages enregistrés en code HID de type clavier et traités comme tel par le terminal (2). La zone mémoire du dispositif hôte (H) comprend au moins un algorithme d'identification de l'utilisateur, un algorithme de vérification de 15 validité du dispositif client (Cl) et un algorithme d'exécution d'application. La zone mémoire du dispositif hôte (H) comprend en outre une base de données comprenant au moins un premier fichier ou tableau associant les identifiants d'utilisateurs avec les mots de passe de chaque utilisateur, un deuxième fichier ou tableau associant au moins un état d'utilisation du 20 dispositif client (Cl) avec l'identifiant unique d'un dispositif client (Cl), un troisième fichier ou tableau associant l'adresse URL du dispositif hôte (H) avec un identifiant de l'application, un quatrième fichier ou tableau associant les identifiants d'utilisateurs avec au moins un identifiant de l'application. Dans la suite de la description, le mot tableau est à comprendre 25 comme étant un fichier ou un tableau. Le dispositif hôte (H) peut être identifié par une adresse URL. Cette adresse peut être associée à une indication identifiant l'application à exécuter. Par exemple, l'adresse URL peut comprendre l'indication identifiant l'application à exécuter sur la page internet. Par exemple, l'adresse URL peut être de la forme « http://adresse.du.serveur.com/ADFR » où « adresse.du.serveur.com » une ligne de caractères représentant l'adresse du dispositif hôte (H) et « ADFR » est une ligne de caractères donnant une indication de l'objet à installer sur la page Internet. La zone mémoire du dispositif hôte (H) comprend en outre au moins une application à exécuter. L'application peut être l'envoi de lignes de commandes ou messages au terminal (2) permettant l'affichage d'une image stockée dans la zone mémoire du dispositif hôte (H) par les moyens d'affichage du terminal (2) selon des coordonnées de placement de l'image dans l'affichage d'une page Internet. L'application peut être l'envoi de lignes de commandes ou messages au terminal (2) permettant l'affichage d'une animation stockée dans la zone mémoire du dispositif hôte (H) par les moyens d'affichage du terminal (2) selon des coordonnées de placement de l'animation dans l'affichage d'une page Internet. D'autres types d'applications peuvent être stockées dans la zone mémoire du dispositif hôte. Le dispositif client (Cl) ou autrement appelé dispositif portable peut être connectable au terminal (2), par exemple un ordinateur personnel, relié au réseau local ou étendu. Par dispositif portable on entend un dispositif pouvant être mis par exemple dans une poche de vêtement. Le dispositif client (Cl) portable est par exemple compris dans une carte à puce (1) comprenant un corps en matériau synthétique classique, par exemple en ABS (Acrylonitrile Butadiène Styrène) ou en PVC (Polychlorure de Vinyle). Selon une variante de réalisation, le corps de la carte (1) peut être réalisé en matière biodégradable. Dans un mode de réalisation, le dispositif client (Cl) peut être une étiquette en papier ou un autocollant. Dans un mode de réalisation, la carte (1) comprend une partie détachable prédécoupée destinée à former un objet portable utilisateur. La partie détachable de la carte (1) est délimitée par un évidemment linéaire (D), et est accrochée au reste du corps de la carte (1) grâce à des moyens de liaison frangible interrompant donc l'évidemment linéaire. Le dispositif client (Cl) communique avec le dispositif hôte (H) par le terminal (2). L'objet portable utilisateur peut être connecté à un hôte informatique via une interface de type USB, ou toute autre interface équivalente. L'hôte informatique est de façon non limitative le terminal (2) d'un utilisateur. Selon un mode de réalisation, le dispositif portable (Cl) utilisateur comprend notamment un dispositif électronique solidarisé au corps de l'objet par exemple à l'aide d'un adhésif classique pendant une étape d'intégration du dispositif électronique. Le dispositif électronique comprend des moyens de connexion (30) de type bus informatique à transmission série. Dans certains modes de réalisation, le dispositif électronique est une puce électronique reliée électriquement selon la norme USB (de l'anglais, Universal Serial Bus) à une vignette à plages de contact électriquement disjointes, fabriqué selon un procédé connu de l'homme du métier : la puce électronique est placée sous la vignettes à plages de contact, puis les contacts électriques de la puce sont ensuite reliés aux plages de contact de ladite vignette. Selon un mode de réalisation, la puce électronique peut comprendre, par exemple et de façon non limitative, au moins un microcontrôleur, comme par exemple et de façon non limitative un microprocesseur comprenant une mémoire volatile, un contrôleur USB, un ou plusieurs espaces mémoires, par exemple des mémoires sécurisées permanente non volatiles programmables intégrées ou non dans le microcontrôleur. Contrairement au cas des puces réalisées selon la norme ISO 7816, les signaux d'horloge, des périphériques de type USB, ne sont pas transmis par le connecteur USB, la puce comportera donc son circuit d'horloge intégré ou non dans un microcontrôleur. Ce circuit d'horloge pourra, par exemple et de façon non restrictive, comporter un résonateur ou un quartz. Dans un mode de réalisation, les plages de contact sont réalisées par une vignette à huit contacts. Contrairement aux vignettes au format ISO 7816 classiquement utilisées sur une carte (1) à puce, les plages de contact correspondant aux contacts ISO Cl à C4 ont été rallongées de façon à faire correspondre les dimensions des plages de contact de la vignette avec ceux d'un connecteur USB tout en respectant la norme 7816-2 relative aux dimensions et emplacement des contacts. Pour cela, la longueur des plages de contact correspondant aux contacts ISO C5 à C8 a été raccourcie. Un connecteur USB ne comprenant que quatre pistes, les plages de contact correspondant aux contacts ISO C5 à C8 ne seront donc pas utilisées. Suivant un premier mode de réalisation, ces plages de contact seront chacune isolées entre elles mais ne seront pas câblées au microcircuit. Suivant un autre mode de réalisation, les plages de contact correspondant aux contacts ISO C5 à C8 pourront être isolées des contacts ISO C2 à C4 mais ne seront pas isolées entre elles et seront reliées au contact ISO Cl de façon à ne former qu'une seule plage de contacts. Ainsi, l'objet portable utilisateur forme un organe informatique connectable selon la norme USB, un microcontrôleur de la puce électronique étant programmé par des moyens de programmation de telle sorte que ledit objet portable se comporte comme une interface homme/machine, par exemple de type clavier, une fois connecté, par exemple à un terminal (2). Le système de gestion d'application selon l'invention comprend donc au moins deux dispositifs jouant le rôle d'hôte ou de client, dont au moins le dispositif client (Cl) est portable, communiquant par un terminal (2) avec un réseau (22) via des moyens de connexion ou de communication du terminal (2). La zone mémoire du dispositif client (Cl) peut comprendre au moins une adresse URL du dispositif hôte (H) ainsi qu'une indication identifiant l'application à exécuter. Comme vu précédemment, l'adresse URL peut comprend l'indication identifiant l'application à exécuter. La zone mémoire du dispositif client (Cl) comprend également un premier compteur incrémenté par la génération d'un mot de passe, une clef partagée entre le dispositif client et le dispositif hôte et un identifiant unique du dispositif client (Cl). Le premier compteur et la clef partagée sont utilisés par l'algorithme d'authentification. La zone mémoire du dispositif hôte (H) peut comprendre également un cinquième fichier ou tableau associant un deuxième compteur avec l'identifiant unique de chaque dispositif client pour mettre en oeuvre l'algorithme d'authentification et la clef secrète partagée entre le dispositif client (Cl) et le dispositif hôte (H). Ainsi, le cinquième fichier comprend une pluralité de deuxièmes compteurs dont chacun est associé à un dispositif client (Cl). Selon un mode de réalisation, le cinquième fichier ou tableau peut associer chaque dispositif client à un deuxième compteur et une clef secrète partagée entre le dispositif hôte (H) et un dispositif client (Cl). L'algorithme d'authentification du système peut être du type à mot de passe à usage unique ou « One-Time Password ». Cet algorithme peut être basé, pour la génération des mots de passe, sur l'algorithme HOTP (HMACbased One-Time Password) publié par l'IETF (Internet Engineering Task Force) conforme à la spécification RFC 4226. L'algorithme HOTP est lui-même basé sur la fonction d'HMAC (Hashed Message Authentification Code) et l'algorithme SHA-1 (Secure Hash Algorithm). L'algorithme d'authentification peut comprendre un premier module mis en oeuvre par les moyens de traitement du dispositif client (Cl) générant un premier mot de passe à partir de la clef secrète partagée et du premier compteur à un rang n. Le premier module incrémente le premier compteur à un rang n+1 lorsque le premier mot de passe est généré. Ce premier module est stocké dans la zone mémoire du dispositif client (Cl), L'algorithme d'authentification peut comprendre en outre un deuxième module mise en oeuvre par les moyens de traitement du dispositif hôte (H) générant un deuxième mot de passe à partir de la clef secrète partagée et du deuxième compteur à un rang p. Le deuxième compteur est celui associé à l'identifiant unique du dispositif client (Cl) à partir du cinquième fichier ou tableau. Selon un mode de réalisation, la clef secrète partagée peut être aussi associée à l'identifiant unique du dispositif client (Cl). Le deuxième module est stocké dans la zone mémoire du dispositif hôte (H). L'algorithme d'authentification peut comprendre en outre un troisième module comparant le premier mot de passe généré par les moyens de traitement du dispositif client (Cl) et le deuxième mot de passe généré par les moyens de traitement du dispositif hôte (H). Pour pouvoir être comparé, le premier mot de passe est envoyé au dispositif hôte (H) par le dispositif client (Cl). Le troisième module incrémente le deuxième compteur à un rang p+1 lorsque le deuxième mot de passe est généré. Le troisième module est stocké dans la zone mémoire du dispositif hôte (H). Les mots de passe sont créés à partir de l'algorithme HOTP. Dans un mode de réalisation particulier, le dispositif client (Cl) comprend un fichier d'utilisation stocké dans une zone mémoire secrète du dispositif client (Cl). Cette zone mémoire secrète peut être comprise dans la zone mémoire du dispositif client ou être une zone mémoire indépendante du dispositif client (Cl). Cette zone mémoire secrète n'est accessible que par un canal sécurisé. Le fichier d'utilisation comprend portant une information d'état d'utilisation du dispositif client (Cl) : un état correspondant à un état d'utilisation « utilisé » du dispositif client (Cl) et un état correspondant à un état d'utilisation « non utilisé ». Le fichier est accessible au dispositif hôte (H) par un canal sécurisé entre le dispositif client (Cl) et le dispositif hôte (H). Ce canal sécurisé est ouvert par un algorithme d'ouverture d'un canal sécurisé. Dans ce mode de réalisation particulier, la zone mémoire du dispositif hôte (H) comprend l'algorithme d'ouverture d'un canal sécurisé. Sa zone mémoire comprend également une application permettant l'installation de cet algorithme d'ouverture d'un canal sécurisé entre le dispositif client (Cl) et le dispositif hôte (H) et un jeu de trois clefs secrètes. L'application d'installation est destinée à être envoyée au dispositif client (Cl) pour installer l'algorithme d'ouverture sur le terminal (2) afin de commander, par des messages envoyés au dispositif client (Cl) via l'interface, la modification de l'information du fichier d'utilisation stocké dans la zone mémoire du dispositif client (Cl). Dans ce mode de réalisation particulier, la zone mémoire du dispositif client (Cl) peut déjà comprendre un jeu de trois clefs secrètes identiques au jeu de trois clefs secrètes du dispositif hôte (H). De même, la zone mémoire du terminal peut déjà comprendre un algorithme d'ouverture d'un canal sécurisé. Ce cas de figure peut se rencontré quand, par exemple, le dispositif client (Cl) a déjà été connecté au dispositif hôte (H) via le même terminal (2). L'invention concerne également un procédé de gestion d'au moins une application. Ce procédé est mis en oeuvre par le système selon l'invention. Le procédé comprend une étape de connexion à l'adresse URL du dispositif hôte (H) fournie par un dispositif client (Cl) lu par le terminal. Selon un mode de réalisation, après l'insertion du dispositif client (Cl) dans l'interface du terminal, un programme du dispositif client (Cl) commande l'envoi d'un message incluant des codes par les moyens de traitement du dispositif client de telle sorte que le dispositif client se comporte comme une interface homme/machine de type clavier et que la zone mémoire du terminal (2) comprend au moins un identifiant destiné à identifier le dispositif client (Cl) connecté comme étant une interface homme/machine clavier. Le programme commande aussi l'envoi d'un message incluant des codes (NID generic) par les moyens de traitement du dispositif client de telle sorte que le dispositif client se comporte comme une interface homme/machine de contrôle gérant les informations en provenance du terminal. Selon un mode de réalisation, après que le dispositif client (Cl) est relié au terminal (2), le système d'exploitation du terminal (2) peut exécuter automatiquement une connexion du dispositif client (Cl) à l'adresse URL stockée dans la zone mémoire du dispositif client (Cl). Par exemple, dans un système d'exploitation tel que Windows, un fichier autoruninf est compris à la racine de la zone mémoire du dispositif client (Cl). Ce programme permet, par exemple, d'ouvrir un programme navigateur Internet compris, par exemple, dans la zone mémoire du terminal (2) sur la page correspondant à l'adresse URL stockée dans la zone mémoire du dispositif client (Cl). Selon un mode de réalisation, après que le dispositif client (Cl) est relié au terminal (2), l'utilisateur recherche dans la zone mémoire du dispositif client (Cl) un fichier permettant l'ouverture d'un programme navigateur Internet compris dans la zone mémoire du terminal (2) sur la page correspondant à l'adresse URL stockée dans la zone mémoire du dispositif client (Cl). D'autres modes de réalisation sont envisageables. Le procédé comprend également une étape d'authentification du dispositif client (Cl) mise en oeuvre par l'algorithme d'authentification, Si le dispositif client (Cl) est authentifié, le procédé comprend en outre une étape d'identification de l'utilisateur mise en oeuvre par l'algorithme d'identification de l'utilisateur. Si l'utilisateur est identifié, le procédé comprend en outre une étape de vérification de validité du dispositif client (Cl). Si le dispositif client (Cl) est validé, le procédé comprend en outre une étape d'exécution de l'application. Lors de l'étape (100) de connexion, le dispositif client (Cl) est connecté à l'adresse URL (100a) du dispositif hôte (H) stockée dans la zone mémoire du dispositif client (Cl) par l'intermédiaire d'une connexion au terminal (2). Ainsi, lorsque le dispositif client (Cl) est relié au terminal (2), le système d'exploitation du terminal (2) peut identifier (100b) le dispositif client (Cl) qui envoie un identifiant unique du dispositif client (Cl) au dispositif hôte (H). L'étape qui suit est une étape (101) d'authentification du dispositif client (Cl) par l'algorithme d'authentification. Cette étape peut être déclenchée par le dispositif hôte (H) lorsque le dispositif client (Cl) est connecté au dispositif hôte (H). Cet algorithme comprend au moins une étape (1011) de génération, par le premier module qui est mis en oeuvre par les moyens de traitement du dispositif client (Cl), d'un premier mot de passe à partir de la clef secrète partagée et du premier compteur à un rang n. Lorsque le premier mot de passe a été généré, l'algorithme exécute une étape (1012) d'incrémentation du premier compteur à un rang n+1. Parallèlement, une étape (1013) de génération, par le deuxième module qui est mis en oeuvre par les moyens de traitement du dispositif hôte (H), d'un deuxième mot de passe à partir de la clef secrète partagée et du deuxième compteur à un rang p. Le deuxième compteur est celui associé à l'identifiant unique du dispositif client (Cl) connecté à partir du cinquième fichier ou tableau. Lorsque le premier mot de passe a été généré, l'algorithme exécute une étape (1016) d'envoi par le dispositif client (Cl) au dispositif hôte (H) du premier mot de passe. Dans une étape (1015) de comparaison, par le troisième module mis en oeuvre par les moyens de traitement du dispositif hôte (H), le premier mot de passe est comparé avec le deuxième mot de passe. Si le premier mot de passe est identique au deuxième mot de passe (1019), le deuxième compteur étant incrémenté (1020) à un rang p+1. Les moyens de traitement du dispositif hôte modifient alors le cinquième fichier en modifiant le rang du deuxième compteur du rang p au rang p+1. Le dispositif client (Cl) est alors authentifié (1021). En revanche, si le premier mot de passe est différent du deuxième mot de passe (1017) ou si aucun mot de passe n'est fourni par le dispositif client (Cl), le procédé est arrêté et la connexion au dispositif hôte (H) est rejetée (1018). Cette étape (101) d'authentification permet donc de contrôler qu'un dispositif client (Cl) est relié physiquement au terminal (2). En effet, pour que le dispositif client (Cl) puisse se connecter au dispositif hôte (H), l'adresse URL du dispositif hôte (H) n'est pas suffisante. Le premier mot de passe est nécessaire pour que la connexion soit effective. Par exemple, si un utilisateur entre l'adresse URL du dispositif hôte (H) dans un programme navigateur internet sans qu'un dispositif client (Cl) ne soit connecté, aucun mot de passe n'est envoyé au dispositif hôte (H), la connexion est rejetée. Comme il a déjà été décrit ci-avant, la génération des mots de passe 25 peut être basée sur l'algorithme HOTP (HMAC-based One-Time Password) publié par l'IETF (Internet Engineering Task Force) conforme à la spécification RFC 4226. Si le dispositif client (Cl) est authentifié (1021), le procédé comprend en outre une étape d'identification (1022) de l'utilisateur par l'algorithme d'identification de l'utilisateur. L'algorithme envoie des commandes au terminal pour exécuter les étapes suivantes par les moyens de traitement du terminal. Une étape d'affichage par le moyen d'affichage (21) du terminal (2) d'au moins deux zones de saisie, l'affichage étant commandé par l'algorithme d'identification. Un curseur affiché sur la première zones de saisie permet de réaliser l'étape (1023) de saisie d'un identifiant de l'utilisateur par les moyens de saisie du terminal (2) dans la première zone de saisie. Après que l'identifiant est saisi dans la première zone de saisie, le curseur est affiché dans la deuxième zone de saisie pour réaliser l'étape de saisie (1023) d'un mot de passe associé à l'identifiant de l'utilisateur par les moyens de saisie du terminal (2) dans la deuxième zone de saisie. Après que l'identifiant est saisi dans la première zone de saisie et que le mot de passe associé à l'identifiant est saisi dans la deuxième zone de saisie, l'utilisateur valide l'identifiant et le mot de passe à l'aide du moyen de saisie (23) en appuyant par exemple sur une touche de validation du moyen de saisie (23). Avant d'être envoyé au dispositif hôte (H), le mot de passe et/ou l'identifiant peuvent être cryptés (1024) par les moyens de traitement du dispositif client (Cl). Après le cryptage (1024), l'identifiant et/ou le mot de passe cryptés sont envoyés (1025) au dispositif hôte (H). Si l'identifiant et/ou le mot de passe sont cryptés, une étape (1026) de décryptage est exécutée par les moyens de traitement du dispositif hôte (H). L'identifiant et le mot de passe sont alors vérifiés par l'algorithme d'identification à partir du premier tableau de la base de données stockée dans la zone mémoire du dispositif client (Cl). Si la base de données comprend l'identifiant de l'utilisateur associé avec le mot de passe saisi par l'utilisateur, l'utilisateur est identifié (1029). Sinon, l'utilisateur n'est pas identifié (1027) et la connexion est rejetée (1028). L'algorithme d'identification peut également donner la possibilité d'ajouter un compte d'utilisateur par des commandes envoyées au terminal permettant d'exécuter les étapes suivantes. Lors de l'affichage par le moyen d'affichage (21) du terminal (2) d'au moins deux zones de saisie, l'affichage peut comprendre aussi la possibilité d'ajouter un compte. L'affichage peut, par exemple, présenté un lien qui amène à une page Internet affichant un formulaire d'inscription demandant au moins un identifiant de l'utilisateur ainsi que le mot de passe de l'utilisateur. Après avoir rempli le formulaire d'inscription par les moyens de saisie du terminal (2) et après la validation du formulaire d'inscription par les moyens de saisie du terminal (2), les informations entrées par l'utilisateur sont stockées dans la zone mémoire du dispositif client (Cl). L'identifiant et le mot de passe de l'utilisateur sont stockés dans le premier tableau de la base de données du dispositif hôte (H). L'algorithme d'identification peut également donner la possibilité de ne pas s'identifier. Dans ce cas, l'utilisateur n'est pas identifié et la connexion est 20 rejetée. Si l'utilisateur est identifié (1029), le procédé comprend en outre une étape de vérification de validité du dispositif client (Cl). Cette étape de vérification est exécutée par l'algorithme de vérification de validité du dispositif client (Cl) mise en oeuvre par les moyens de traitement 25 du dispositif hôte (H). L'étape de vérification (1030) de validité du dispositif client (Cl) permet de savoir si l'application a déjà été exécutée ou non. Ainsi, un même dispositif client (Cl) ne permet pas d'exécuter l'application associée au dispositif client (Cl) à partir d'autres identifiants d'utilisateur. L'étape de vérification peut comprendre au moins une étape d'envoi par le dispositif client (Cl) vers le dispositif hôte (H) de l'identifiant unique du dispositif client (Cl). Cette étape d'envoi peut être également réalisée avant l'étape d'authentification (101) ou avant l'étape d'identification (1022) de l'utilisateur. Les moyens de traitement du dispositif hôte (H) exécutent ensuite une vérification, à partir du deuxième tableau, de l'état d'utilisation du dispositif client (Cl) à partir de l'identifiant unique du dispositif client (Cl). Ce deuxième tableau associe les identifiant uniques des dispositifs clients à leur état d'utilisation ou information d'utilisation. L'état d'utilisation correspond au fait que l'application associée au dispositif client (Cl) a été déjà exécutée ou non. Si l'application associé au dispositif client (Cl) a déjà été exécutée, l'état associé à l'identifiant unique du dispositif client (Cl) indiqué dans le deuxième tableau est l'état « utilisé », par exemple « 0 ». En revanche, si l'application n'a jamais été exécutée, l'état associé à l'identifiant unique du dispositif client (Cl) indiqué dans le deuxième tableau est l'état « non utilisé », par exemple « 1 ». Si l'état d'utilisation correspond à un état « utilisé » (1031), une étape de vérification (1032) pour vérifier que l'identifiant de l'utilisateur est associé dans le quatrième tableau à l'identifiant ou les identifiants d'une autre ou d'autres applications associées à un ou d'autres dispositifs client. Cette étape peut être suivie d'une étape (1033) d'exécution éventuelle de l'éventuelle ou des éventuelles autres applications par les moyens de traitement du dispositif hôte ou du terminal. Ainsi, l'application associée à un dispositif client ne peut pas être exécutée une un autre compte d'utilisateur si elle a déjà été exécutée une fois. Le nombre d'exécutions peut être supérieure à une fois en ajoutant dans le quatrième tableau une information indiquant le nombre de fois l'application peut être exécutée. Si l'état d'utilisation correspond à un état « non utilisé » (1034), le dispositif client (Cl) est validé. Selon le mode de réalisation particulier, l'étape de vérification (1030a) consiste en la vérification, dans le fichier d'utilisation stocké dans zone mémoire secrète du dispositif client (Cl), de l'information de l'état d'utilisation du dispositif client (Cl) après une étape d'ouverture (1030b) d'un canal sécurisé par un algorithme d'ouverture d'un canal sécurisé. L'ouverture d'un canal sécurisé est décrite ci-après. Après avoir vérifié que le dispositif client (Cl) est validé, l'application est exécutée par l'algorithme d'exécution d'application suivant les étapes 10 suivantes. - une étape de vérification de l'application à exécuter à partir de l'indication dans l'adresse URL du dispositif hôte (H) stockée dans la zone mémoire du dispositif client (Cl) d'après le troisième tableau, - une étape (1036) d'affichage sur le moyen d'affichage (21) du terminal 15 (2) d'une fenêtre présentant un choix d'exécution ou non de l'application à exécuter, la fenêtre représentant au moins une touche matérielle ou virtuelle permettant l'exécution de l'application et une touche matérielle ou virtuelle permettant le refus d'exécution de l'application, - une étape (1035) de choix par les moyens de saisie du terminal (2) par 20 l'utilisateur. Si l'utilisateur actionne le moyen de saisie (23) de telle manière que la touche matérielle ou virtuelle permettant le refus d'exécution est validée (1036b), le procédé comprend une étape d'exécution par les moyens de traitement du terminal ou les moyens de traitement du dispositif hôte de la ou 25 des applications associées à un autre ou d'autres dispositifs client sans l'exécution de l'application associée au dispositif client (Cl). Si l'utilisateur actionne le moyen de saisie (23) de telle manière que la touche matérielle ou virtuelle permettant l'exécution est validée (1036a), le procédé comprend : - une étape (1037a) d'exécution par les moyens de traitement du terminal ou les moyens de traitement du dispositif hôte de la ou des applications associées à un autre ou d'autres dispositifs client sans l'exécution de l'application associée au dispositif client (Cl), - une étape (1037b) d'exécution par les moyens de traitement du terminal ou les moyens de traitement du dispositif hôte de l'application associée au dispositif client (Cl) - une étape (1038, 1039) de modification de l'information d'utilisation de l'état « non utilisé » pour passer l'information d'utilisation à l'état « utilisé ». Cette étape peut aussi précéder l'étape d'affichage. Le procédé peut également comprendre les étapes suivantes. Lors de l'étape de choix pendant l'étape d'exécution de l'application, si l'utilisateur actionne le moyen de saisie (23) de telle manière que la touche permettant l'exécution est validée (1036a), l'étape (1038) de modification de l'état d'utilisation « non utilisé » en état d'utilisation « utilisé » correspond à la modification de l'information d'utilisation de l'état « non utilisé » est modifié en état d'utilisation « utilisé » correspondant à la modification de l'état en association avec l'identifiant unique du dispositif client (Cl) sur le deuxième fichier ou tableau. Selon le mode de réalisation particulier représenté par les blocs en pointillés des figure 3 et 4, l'étape d'authentification peut être suivie d'une étape d'installation (100d) par les moyen de traitement du terminal (2) d'un algorithme d'ouverture d'un canal sécurisé dans la zone mémoire du terminal (2), l'algorithme d'ouverture ayant été envoyé (100c) par le dispositif hôte (H). Cet algorithme peut être une applet programmée en Java ou une application de type Plugin ou bien un logiciel installé directement sur la zone mémoire du terminal (2) et lis en oeuvre par les moyens de traitement du terminal (2). Selon le mode de réalisation particulier, lors de l'étape de choix pendant l'étape d'exécution de l'application, si l'utilisateur actionne le moyen de saisie (23) de telle manière que la touche permettant l'exécution est validée, l'étape de modification de l'information d'utilisation de l'état « non utilisé » en état « ut i I isé » correspond à la modification (1039) de l'information du fichier d'utilisation stocké dans la zone mémoire du dispositif client (Cl) par un algorithme de changement de l'information contenue dans le fichier d'utilisation après une étape d'ouverture (1039) d'un canal sécurisé par un algorithme d'ouverture d'un canal sécurisé mis en oeuvre par les moyens de traitement du dispositif hôte (H) et du terminal (2). Ceci est réalisé pour savoir si l'application associée au dispositif client (Cl) a déjà été exécutée ou non. Dans ce mode de réalisation particulier, pour permettre l'ouverture de ce canal sécurisé, les dispositifs hôte (H) et client (Cl) comprennent au moins un algorithme de chiffrement/déchiffrement des données et au moins un jeu de clefs de chiffrements enregistrées dans la zone mémoire secrète du dispositif client (Cl), cette zone étant non accessible de l'extérieur. Par exemple et de façon non limitative, les clefs de chaque jeu sont symétriques. Par exemple, l'algorithme de chiffrement/déchiffrement utilisé est un algorithme dit triple DES (3-DES, 20 DES venant de l'anglais « Data Encryption stantard »). Chaque jeu de clefs secrètes comprend par exemple trois clefs secrètes 3-DES, notées ENC, MAC et DEK. La clef ENC est une clef secrète de chiffrement des données, assurant la confidentialité des données échangées. La clef secrète MAC est une clef d'intégrité. L'algorithme 3-DES utilisant la clef secrète MAC sur une donnée génère une signature numérique accompagnant chaque donnée chiffrée par l'algorithme et la clef MAC. Cette signature numérique garanti que les données transférées d'un dispositif à l'autre ne sont pas corrompues. Enfin, la clef DEK est une clef secrète de chiffrement de données confidentielles, et apporte une protection supplémentaire à des données sensibles, par exemple et de façon non limitative contenant des informations concernant des données utilisateur. Dans ce mode de réalisation particulier, les dispositifs hôte (H) et client (Cl) peuvent comprendre un système d'exploitation, mise en oeuvre par les moyens de traitement, comportant les algorithmes et les commandes nécessaires à l'ouverture d'un canal sécurisé ayant les spécifications GlobalPlatform permettant l'échange sécurisé de données entre le client, par exemple un objet portable utilisateur (Cl), et l'hôte (H), par exemple un serveur. Dans ce mode de réalisation particulier et en référence à la figure 7, le procédé d'ouverture d'un canal sécurisé ayant les spécifications GlobalPlatform entre le dispositif client (Cl) et le dispositif hôte (H) va maintenant être décrit. L'ouverture de ce canal est réalisé via un algorithme 3- DES enregistré dans une zone mémoire sécurisée non volatile du dispositif hôte et du dispositif client, et un jeu de trois clefs secrètes ENC, MAC ET DEK enregistrées dans une zone mémoire secrète de chaque dispositif (H, Cl), non accessible de l'extérieur. Au cours de la première étape, les moyens de traitement du dispositif hôte (H) commandent l'ouverture d'une nouvelle session. Une information indiquant l'ouverture de la session est envoyé au dispositif client (Cl) par les moyens de traitement du dispositif hôte (H). À réception de cette information, les moyens de traitement du dispositif client, génèrent (60) un compteur de session (SC) incrémenté à chaque ouverture d'une nouvelle session. Ce compteur de session est stocké dans une zone mémoire du dispositif client (Cl). Au cours de la deuxième étape, les moyens de traitements du dispositif client (Cl) réalisent une opération de dérivation (501) des trois clefs secrètes ENC, MAC ET DEK, via l'algorithme 3-DES utilisant le compteur de session (SC) et un nombre aléatoire hôte (HC) généré par les moyens de traitement du dispositif hôte (H), ledit nombre aléatoire (HC) étant envoyé (61) au dispositif client (Cl) et enregistré dans la mémoire du dispositif client. Suite à cette étape de dérivation, cinq clefs dérivées secrètes sont générées (90) par les moyens de traitement du dispositif client (Cl), et enregistrées dans une zone mémoire du dispositif (Cl). La première clef, nommée S-ENC, permet de chiffrer les commandes envoyées à un dispositif (H, Cl) par l'autre dispositif (H, Cl). La deuxième clef, nommée R-ENC, permet de chiffrer les réponses envoyées à un dispositif par l'autre dispositif. Les deux clefs nommées C-MAC et R-MAC permettent respectivement de générer une signature pour chaque commande et pour chaque réponse envoyée, assurant ainsi l'intégrité des données transférées. Enfin, la cinquième clef, nommée SDEK, permet de chiffrer les données confidentielles, qu'il s'agisse de commandes ou de réponses. Au cours de la quatrième étape, les moyens de traitement du dispositif client (Cl) génèrent (504) un cryptogramme client (Ccryptoc), via l'algorithme 3-DES utilisant la clef dérivée S-ENC ainsi que le nombre aléatoire hôte (HC) et un nombre aléatoire client (CC) généré par les moyens de traitement du dispositif client (Cl). Au cours de la cinquième étape, ce cryptogramme client (Ccryptoc), le compteur de session (SC) et le nombre aléatoire client (CC) sont envoyés au dispositif hôte (H) par les moyens de traitement du dispositif client (Cl). Le cryptogramme client (Ccryptoc), le compteur de session (SC) et le nombre aléatoire client (CC) sont enregistrés dans une zone mémoire du dispositif hôte (H). Parallèlement, les moyens de traitement du dispositif hôte (H) calculent (500, 80) les cinq clefs dérivées S-ENC, R-ENC, C-MAC, R-MAK et S-DEK via l'algorithme triple DES utilisant le compteur de session (SC) et le nombre aléatoire hôte (HC). Avec les données reçues à la cinquième étape, les moyens de traitement du dispositif hôte (H) calculent (503) le cryptogramme client 25 (CcryptoH) via l'algorithme triple DES utilisant la clef dérivée S-ENC, le nombre aléatoire hôte (HC) et le nombre aléatoire client (CC). Au cours de la septième étape, les moyens de traitement du dispositif hôte (H) comparent les cryptogrammes client (Ccryptoc, CcryptoH) respectivement calculés par le dispositif client (Cl) et le dispositif hôte (H). Si les deux cryptogrammes client (Ccryptoc, CcryptoH) sont identiques, alors le dispositif client (Cl) est authentifié par les moyens de traitement du dispositif hôte (H). Au cours de la huitième étape, les moyens de traitement du dispositif hôte (H) calcule (502) un cryptogramme hôte (HcryptoH), via l'algorithme 3- DES utilisant la clef dérivée S-ENC, le nombre aléatoire hôte (HC) et le nombre aléatoire client (CC). Ce cryptogramme hôte (HcryptoH) est enregistré dans une zone mémoire du dispositif hôte (H). Au cours de la neuvième étape, ce cryptogramme hôte (HcryptoH) est envoyé (62) au dispositif client (Cl) par les moyens de traitement du dispositif hôte (H). Le cryptogramme hôte (HcryptoH) est enregistré dans une zone mémoire du dispositif client (Cl). Avec les données reçues à la neuvième étape, les moyens de traitement du dispositif client (Cl) calculent (505) le cryptogramme hôte (Hcryptoc) via l'algorithme 3-DES utilisant la clef dérivée S-ENC, le nombre aléatoire hôte (HC) et le nombre aléatoire client (CC). Au cours de la onzième étape, les moyens de traitement du dispositif client (Cl) comparent les cryptogrammes hôte (HcryptoH, Hcryptoc) respectivement calculés par le dispositif client (Cl) et le dispositif hôte (H). Si les deux cryptogrammes hôte (HcryptoH, Hcryptoc) sont identiques, alors le dispositif hôte (H) est authentifié par les moyens de traitement du dispositif client (Cl). Ce procédé se conclut par la confirmation de l'ouverture d'un canal sécurisé (OSCS), à travers lequel les prochaines commandes et/ou réponse générées par les dispositifs hôte (H) et client (Cl) peuvent être réalisées. Ce canal de sécurité permet, par exemple, aux moyens de traitement du dispositif hôte (H) de modifier le fichier d'utilisation stocké dans la mémoire du dispositif client (Cl). Ainsi, il est possible de connaître l'état d'utilisation du dispositif client d'au moins deux modes différents qui peuvent être mis en oeuvre ensemble ou seul. Selon un mode de réalisation, l'identifiant unique du dispositif client est associé à l'état d'utilisation du dispositif client dans le deuxième fichier ou tableau stocké dans la zone mémoire du dispositif hôte. Selon le mode de réalisation particulier, un fichier d'utilisation stocké dans la zone mémoire du dispositif client (Cl). Le fichier d'utilisation comprend une information d'état d'utilisation du dispositif client (Cl) : un état correspondant à un état d'utilisation « utilisé » du dispositif client (Cl) et un état correspondant à un état d'utilisation « non utilisé ». L'information d'état d'utilisation est modifiée par l'algorithme de changement de l'information contenue dans le fichier d'utilisation installée dans la zone mémoire du terminal (2). Les figures 5 et 6 représentent des exemples de réalisation du procédé. L'application est une application permettant d'installer un objet telle qu'une image sur une page Internet (2000, 2001). La figure 5 représente un terrain de football sur lequel des images de joueurs peuvent être installées. Dans la page Internet (2000) de la figure 5, aucun joueur n'a été installé. Seuls sont représentés les emplacements (2003) des images des joueurs. Lorsqu'un utilisateur connecte un dispositif client sur son terminal et que ce dispositif client n'a jamais été utilisé pour installer une image de joueur, il a la possibilité ou non d'installer une image de joueur associée à son dispositif client. Par exemple, le dispositif client peut avoir la forme ou représenté une image du joueur dont l'image peut être installée sur le terrain de football représenté sur la page Internet. La figure 6 représente la page internet (2001) avec une image (2002) de joueur installée grâce à son dispositif client. Par la suite, si cet utilisateur reconnecte son dispositif client sur son terminal, il n'aura plus la possibilité d'installer une autre image du joueur déjà installée grâce à ce dispositif client, ni l'image d'un autre joueur. Mais, la connexion de son dispositif client déjà utilisé lui permettra d'aller directement sur la page Internet avec ses images de joueur déjà installées avec l'utilisation par exemple de sont mot de passe. Selon un autre mode de réalisation, l'application peut donner la possibilité de choisir le joueur à ajouter sur la page internet. Ainsi, l'application envoie aux moyens de traitement du terminal des commandes permettant d'afficher une fenêtre représentant plusieurs choix de joueurs sélectionnables avec des informations permettant de désigner la position du joueur sélectionné sur le terrain affiché par les moyens d'affichage du terminal. Le joueur peut être sélectionné par des moyens de sélection. Ces moyens de sélection peuvent être au moins une touche virtuelle correspondant au joueur du moyen de saisie du terminal ou au moins touche virtuelle correspondant au joueur des moyens d'affichages du terminal si le moyen d'affichage est, par exemple, un écran tactile. Un fichier ou un tableau peut associer le nom du joueur avec l'identifiant, le nom ou le prénom de l'utilisateur. La présente demande décrit diverses caractéristiques techniques et avantages en référence aux figures et/ou à divers modes de réalisation. L'homme de métier comprendra que les caractéristiques techniques d'un mode de réalisation donné peuvent en fait être combinées avec des caractéristiques d'un autre mode de réalisation à moins que l'inverse ne soit explicitement mentionné ou qu'il ne soit évident que ces caractéristiques sont incompatibles. De plus, les caractéristiques techniques décrites dans un mode de réalisation donné peuvent être isolées des autres caractéristiques de ce mode à moins que l'inverse ne soit explicitement mentionné. Il doit être évident pour les personnes versées dans l'art que la présente invention permet des modes de réalisation sous de nombreuses autres formes spécifiques sans l'éloigner du domaine d'application de l'invention comme revendiqué. Par conséquent, les présents modes de réalisation doivent être considérés à titre d'illustration, mais peuvent être modifiés dans le domaine défini par la portée des revendications jointes, et l'invention ne doit pas être limitée aux détails donnés ci-dessus. REVENDICATIONS1, Système de gestion d'au moins une application en ligne caractérisé en ce qu'il comprend au moins deux dispositifs jouant le rôle d'hôte (H) ou de client (Cl), dont au moins le dispositif client (Cl) est portable, un terminal (2) communiquant avec un réseau (22) via des moyens de connexion ou de communication du terminal (2), le dispositif client (Cl) se connectant au terminal (2) par une interface du terminal comme périphérique clavier, chaque dispositif (H, Cl) comportant au moins une zone mémoire permanente non volatile 10 programmable et des moyens de traitements des données, le terminal comprenant une zone mémoire et des moyens de traitement de données, le système comprenant un algorithme d'authentification, la zone mémoire du dispositif client (Cl) comprenant un identifiant unique 15 et des messages enregistrés en code clavier et traités comme tel par le terminal (2), la zone mémoire du dispositif hôte (H) comprenant au moins un algorithme d'identification d'un utilisateur, un algorithme de vérification de validité du dispositif client (Cl) et un algorithme d'exécution d'application, 20 la zone mémoire du dispositif hôte (H) comprenant en outre une base de données comprenant au moins un premier fichier ou tableau associant des identifiants d'utilisateurs avec des mots de passe de chaque utilisateur, un deuxième fichier ou tableau associant au moins un état d'utilisation du dispositif client (Cl) avec l'identifiant unique d'un dispositif client (Cl), un troisième fichier 25 ou tableau associant l'adresse URL du dispositif hôte (H) avec un identifiant de l'application, un quatrième fichier ou tableau associant les identifiants d'utilisateurs avec au moins un identifiant de l'application, le dispositif hôte (H) étant identifié par une adresse URL, la zone mémoire du dispositif hôte (H) comprenant en outre au moins 30 une application. 2. Système selon la revendication 1, caractérisé en ce que l'interface du terminal est de type USB. 3. Système selon la revendication 1, caractérisé en ce que la zone mémoire du dispositif client (Cl) comprenant un premier 5 compteur incrémenté par une génération d'un mot de passe et une clef secrète partagée utilisés par un module de l'algorithme d'authentification dans le dispositif client (Cl), la zone mémoire du dispositif client (Cl) comprenant en outre au moins l'adresse URL du dispositif hôte (H) ainsi qu'une indication de l'identification de io l'application en code interprété par le terminal comme un code clavier, la zone mémoire du dispositif hôte (H) comprenant en outre la clef secrète partagée avec le dispositif client associé à un utilisateur et un cinquième fichier ou tableau associant un deuxième compteur avec l'identifiant unique de chaque dispositif client (Cl). 15 4. Système selon les revendications 1 à 3, caractérisé en ce que l'algorithme d'authentification comprend : un premier module mis en oeuvre par les moyens de traitement du dispositif client (Cl) générant un premier mot de passe à partir de la clef secrète partagée et du premier compteur à un rang n, le premier module incrémentant 20 le premier compteur à un rang n+1 lorsque le premier mot de passe est généré, le premier module étant stocké dans la zone mémoire du dispositif client (Cl), un deuxième module mis en oeuvre par les moyens de traitement du dispositif hôte (H) générant un deuxième mot de passe à partir de la clef secrète partagée et du deuxième compteur à un rang p, le deuxième compteur 25 étant celui associé à l'identifiant du dispositif client (Cl) à partir cinquième fichier ou tableau, le deuxième module étant stocké dans la zone mémoire du dispositif hôte (H), un troisième module mis en oeuvre par les moyens de traitement du dispositif hôte (H) comparant le premier mot de passe généré par les moyens 30 de traitement du dispositif client (CI) et le deuxième mot de passe généré par les moyens de traitement du dispositif hôte (H), le premier mot de passe ayantété envoyé au dispositif hôte (H) par le dispositif client (Cl), le troisième module incrémentant le deuxième compteur à un rang p+1 lorsque le deuxième mot de passe est généré, le troisième module étant stocké dans la zone mémoire du dispositif hôte (H). 5. Système selon la revendication 1, caractérisé en ce que le dispositif client (Cl) comprend un fichier d'utilisation stocké dans une zone mémoire secrète du dispositif client (CI), le fichier d'utilisation comprenant une information d'état d'utilisation du dispositif client (Cl) : un état correspondant à un état d'utilisation « utilisé>) du dispositif client (Cl) et un état correspondant à ro un état d'utilisation « non utilisé », la zone mémoire secrète étant accessible au dispositif hôte (H) par un canal sécurisé entre le dispositif client (Cl) et le dispositif hôte (H), le canal sécurisé étant ouvert par un algorithme d'ouverture d'un canal sécurisé. 6. Système selon les revendications 1 et 5, caractérisé en ce que la 15 zone mémoire du dispositif hôte (H) comprend un algorithme d'ouverture d'un canal sécurisé, une application d'installation d'un algorithme d'ouverture d'un canal sécurisé entre le dispositif client (Cl) et le dispositif hôte (H) et un jeu de trois clefs secrètes, l'application d'installation étant destinée â être envoyée au dispositif client (Cl) pour installer l'algorithme d'ouverture sur le terminal (2) 20 pour commander, par des messages envoyés au dispositif client (Cl) via l'interface, une modification de l'information du fichier d'utilisation stocké dans la zone mémoire secrète du dispositif client (Cl), la zone mémoire du dispositif hôte (H) comprenant également un algorithme de changement de l'information contenue dans le fichier d'utilisation. 25 7. Système selon les revendications 1, 5 et 6, caractérisé en ce que la zone mémoire du dispositif client (Cl) comprend un jeu de trois clefs secrètes identique au jeu de trois clefs secrètes du dispositif hôte (H), le terminal (2) comprenant l'algorithme d'ouverture d'un canal sécurisé. 8. Système selon la revendication 1, caractérisé en ce que l'application 30 envoie des commandes ou messages au terminal permettant un affichaged'une image stockée dans la zone mémoire du dispositif hôte (H) par des moyens d'affichage du terminal (2) selon des coordonnées de placement de l'image dans l'affichage d'une page Internet. 9. Système selon la revendication 1, caractérisé en ce que l'application envoie des commandes ou messages au terminal permettant un affichage d'une animation stockée dans la zone mémoire du dispositif hôte (H) par des moyens d'affichage du terminal (2) selon des coordonnées de placement de l'animation dans l'affichage d'une page Internet. 10. Procédé de gestion d'au moins une application mis en oeuvre par le système selon au moins une des revendications 1 à 9, le terminal (2) comprenant au moins une connexion à un réseau (22) Internet, un moyen de saisie (23) et un moyen d'affichage (21) caractérisé en ce que procédé comprend au moins : une étape (100) de connexion à l'adresse URL du dispositif hôte (H), 15 l'adresse URL du dispositif hôte (H) étant fournie par un dispositif client (Cl) lu par le terminal (2), une étape (101) d'authentification du dispositif client (Cl) mise en oeuvre par l'algorithme d'authentification, si le dispositif client (Cl) est authentifié (1021), le procédé comprenant en 20 outre une étape (1022, 1023, 1024, 1025, 1026, 1027, 1028, 1029) d'identification de l'utilisateur mise en oeuvre par l'algorithme d'identification de l'utilisateur, si l'utilisateur est identifié (1029), le procédé comprenant en outre une étape (1030) de vérification de validité du dispositif client (Cl), 25 si le dispositif client (Cl) est validé (1034), le procédé comprenant en outre une étape (1037b) d'exécution de l'application. 11. Procédé selon la revendication 10, caractérisé en ce que l'étape (100) de connexion à l'adresse URL (100a) du dispositif hôte (H) comprend : - une étape (100) de connexion du dispositif client (Cl) à l'adresse URL 30 du dispositif hôte fournie par l'information stockée dans la zone mémoire du dispositif client (Cl) par l'intermédiaire d'une connexion au terminal (2),- une étape (100b) d'envoi par le dispositif client (Cl) vers le dispositif hôte (H) de l'identifiant unique du dispositif client (Cl). 12. Procédé selon la revendication 10, caractérisé en ce que l'étape -(101) d'authentification mise en oeuvre par l'algorithme d'authentification 5 comprend : - une étape (1011) de génération, par le premier module mis en oeuvre par les moyens de traitement du dispositif client (CI), d'un premier mot de passe à partir de la clef secrète partagée et du premier compteur à un rang n, - une étape (1012) d'incrémentation du premier compteur à un rang n+1, 10 - une étape (1013) de génération, par le deuxième module mis en oeuvre par les moyens de traitement du dispositif hôte (H), d'un deuxième mot de passe à partir de la clef secrète partagée et du deuxième compteur à un rang p le deuxième compteur étant celui associé à l'identifiant unique du dispositif client (CI) à partir du cinquième fichier ou tableau, 15 - une étape (1016) d'envoi par le dispositif client (Cl) au dispositif hôte (H) du premier mot de passe via le terminal (2), - une étape (1015) de comparaison, par le troisième module, du premier mot de passe et du deuxième mot de passe ; si le premier mot de passe est identique au deuxième mot de passe 20 (1019), le deuxième compteur étant incrémenté à un rang p+1 (1020) et le dispositif client (Cl) étant authentifié (1021). 13. Procédé selon la revendication 10, caractérisé en ce que l'étape (1022) d'identification mise en oeuvre par l'algorithme d'identification de l'utilisateur comprend les sous-étapes suivantes : 25 - une étape d'affichage par le moyen d'affichage (21) du terminal d'au moins deux zones de saisie, l'affichage étant commandé par l'algorithme d'identification, - une étape (1023) de saisie d'un identifiant de l'utilisateur par le moyen de saisie du terminal (2) dans la première zone de saisie, 30 - une étape (1023) de saisie d'un mot de passe associé à l'identifiant par le moyen de saisie du terminal (2) dans la deuxième zone de saisie,- une étape (1024) de cryptage par les moyens de traitement du terminal (2) et d'envoi (1025) de l'identifiant et du mot de passe au dispositif hôte (H), - une étape (1026) de décryptage par les moyens de traitement du dispositif hôte (H) et de vérification de l'identifiant et du mot de passe par l'algorithme d'identification à partir du premier fichier ou tableau de la base de données stockée dans la zone mémoire du dispositif hôte (H) ; si le premier fichier ou tableau de la base de donnée comprend l'identifiant de l'utilisateur associé avec le mot de passe saisi par l'utilisateur, l'utilisateur étant identifié (1029). 14. Procédé selon la revendication 10, caractérisé en ce que l'étape (1030) de vérification de validité du dispositif client (Cl) mise en oeuvre par l'algorithme de vérification de validité comprend : une étape de vérification, dans le deuxième tableau, de l'état d'utilisation du dispositif client (Cl) à partir de l'identifiant unique du dispositif client (Cl) ; si l'état d'utilisation correspond à un état « utilisé » (1031), le procédé comprenant : - une étape (1032) de vérification d'une ou plusieurs applications associées à un autre ou d'autres dispositifs client à partir de l'identifiant de l'utilisateur d'après le quatrième tableau, - une étape (1033) d'exécution par les moyens de traitement du terminal ou les moyens de traitement du dispositif hôte (H) de la ou des autres applications associées à un autre ou d'autres dispositifs client sans l'exécution de l'application associée au dispositif client (Cl) ; si l'état d'utilisation correspond à un état « non utilisé » (1034), dispositif client (Cl) étant validé. 15. Procédé selon la revendication 10, caractérisé en - ce que l'étape (1030) de vérification de validité du dispositif client (Cl) mise en oeuvre par l'algorithme de vérification de validité comprend : - une étape de vérification (1030a), dans le fichier d'utilisation stocké dans la zone mémoire secrète du dispositif client (Cl), de l'information del'état d'utilisation du dispositif client (Cl) après une étape (1030b) d'ouverture d'un canal sécurisé par un algorithme d'ouverture d'un canal sécurisé ; si l'état d'utilisation correspond à un état « utilisé », le procédé 5 comprenant : - une étape (1032) de vérification d'une ou plusieurs applications associées à un autre ou d'autres dispositifs client à partir de l'identifiant de l'utilisateur d'après le quatrième tableau, - une étape (1033) d'exécution par les moyens de traitement du terminal io ou les moyens de traitement du dispositif hôte (H) de la ou des autres applications associées à un autre ou d'autres dispositifs client sans l'exécution de l'application associée au dispositif client (Cl) ; si l'état d'utilisation correspond à un état « non utilisé » (1034), dispositif client (Cl) étant validé. 15 16. Procédé selon la revendication 10, caractérisé en ce que l'étape d'exécution de l'application mise en oeuvre par l'algorithme d'exécution d'application comprend : - une étape de vérification de l'application à exécuter à partir de l'indication comprise dans ou associé à l'adresse URL stockée dans la zone 20 mémoire du dispositif client (Cl) d'après le troisième tableau, une étape d'envoi de commande par le dispositif hôte (H) pour permettre l'affichage sur le moyen d'affichage (21) du terminal (2) d'une fenêtre présentant un choix d'exécution ou non de l'application à exécuter, la fenêtre représentant au moins une touche matérielle ou virtuelle permettant l'exécution 25 de l'application et une touche matérielle ou virtuelle permettant le refus d'exécution de l'application, - une étape (1036) de choix par le moyen de saisie du terminal (2) par l'utilisateur, si l'utilisateur actionne le moyen de saisie (23) de telle manière que la 30 touche matérielle ou virtuelle permettant le refus d'exécution est validée (1036b), le procédé comprend une étape d'exécution par les moyens detraitement du terminal (2) ou les moyens de traitement du dispositif hôte (H) de la ou des applications associées à un autre ou d'autres dispositifs client sans l'exécution de l'application associée au dispositif client (Cl) ; si l'utilisateur actionne le moyen de saisie (23) de telle manière que la touche matérielle ou virtuelle permettant l'exécution est validée (1036a), le procédé comprenant : une étape (1037a) d'exécution par les moyens de traitement du terminal ou les moyens de traitement du dispositif hôte (H) de la ou des applications associées à un autre ou d'autres dispositifs client sans l'exécution de l'application associée au dispositif client (Cl), - une étape (1037b) d'exécution de l'application par les moyens de traitement du terminal ou les moyens de traitement du dispositif hôte de l'application associée au dispositif client (Cl) - une étape (1038) de modification de l'information d'utilisation de l'état « non utilisé » pour passer l'information d'utilisation à l'état « utilisé ». 17. Procédé selon les revendications 10 et 12 caractérisé en ce que l'étape d'authentification est suivie d'une étape d'installation (100d) par les moyen de traitement du terminal (2) d'un algorithme d'ouverture d'un canal sécurisé, une application d'installation de l'algorithme d'ouverture d'un canai sécurisé ayant été envoyée (100c) par le dispositif hôte (H). 18. Procédé selon la revendication 15 et 16, caractérisé en ce que, lors de l'étape (1036) de choix, si l'utilisateur actionne le moyen de saisie (23) de telle manière que la touche permettant l'exécution est validée, l'étape (1039) de modification de l'information d'utilisation de l'état « non utilisé » en état « utilisé » correspond à la modification de l'information du fichier d'utilisation stocké dans la zone mémoire secrète du dispositif client (Cl) après une étape (1040) d'ouverture d'un canal sécurisé par un algorithme d'ouverture d'un canal sécurisé mis en oeuvre par les moyens de traitement du dispositif hôte (H) et du terminal (2). 19. Procédé selon les revendications 15 et 18, caractérisé en ce que l'algorithme d'ouverture d'un canal sécurisé est réalisée via un algorithme tripleDES et un jeu de trois clefs secrètes (ENC, MAC, DEC) selon un protocole de sécurité spécifié du type GlobalPlatform, l'algorithme triple DES et le jeu dé trois clefs secrètes (ENC, MAC, DEC) étant enregistrés dans la zone mémoire du dispositif hôte et du dispositif client (Cl), l'algorithme d'ouverture d'un canal sécurisé comprend : a) une étape d'ouverture de session par les moyens de traitement du dispositif hôte (H), suivi (60) de la génération d'un compteur de session (SC) par le dispositif client (Cl) envoyé (70) au dispositif hôte (H), le compteur de session étant incrémenté à chaque ouverture d'une nouvelle session, b) une étape de dérivation (501) des clefs secrètes (ENC, MAC, DEK) enregistrées dans la mémoire du dispositif client (Cl), réalisé par les moyens de traitement dudit dispositif via l'algorithme triple DES utilisant le compteur de session (SC) et un nombre aléatoire hôte (HC) généré et envoyé (61) au dispositif client (Cl) par les moyens de traitement du dispositif hôte (H), c) une étape de génération (90) de cinq clefs dérivées S-ENC, R-ENC, C-MAC, R-MAC et S-DEK qui utilisées avec l'algorithme triple DES, permettent respectivement de chiffrer (S-ENC) les commandes envoyées à un dispositif, de chiffrer (R-ENC) les réponses du dispositif, de générer une signature (CMAC) pour chaque commande, de générer une signature (R-MAC) pour chaque réponse, et de chiffrer (S-DEK) des données confidentielles, d) une étape de génération (504) par les moyens de traitement du dispositif client (Cl) d'un cryptogramme client (Ccryptoc), via l'algorithme triple DES utilisant la clef dérivée S-ENC, le nombre aléatoire hôte (HC) et un nombre aléatoire client (CC) généré par les moyens de traitement du dispositif client (Cl), e) une étape d'envoi (70, 71, 72) par les moyens de traitement du dispositif client (Cl) vers le dispositif hôte (H), du compteur .de session (SC), du nombre aléatoire client (CC) et du cryptogramme client (Ccryptoc) calculé à l'étape précédente, suivi du calcul (500) et de la génération (80) des cinq clefs dérivées (S-ENC, R-ENC, C-MAC, R-MAC, S-DEK) par les moyens de traitement du dispositif hôte (H),f) une étape de génération (503), par les moyens de traitement du dispositif hôte (H), -du cryptogramme client (CcryptoH) via l'algorithme triple DES utilisant la clef dérivée S-ENC, le nombre aléatoire hôte (HC) et le nombre aléatoire client (CC) généré par les moyens de traitement du dispositif client (Cl), g) une étape de comparaison par les moyens de traitement du dispositif hôte (H) des cryptogrammes client (Ccryptoc, CcryptoH) respectivement calculés par le dispositif client (Cl) et le dispositif hôte (H), suivi de l'authentification du dispositif client (Cl) si les deux calculs du cryptogramme 10 client (Ccryptoc, CcryptoH) sont identiques, h) une étape de génération (502) par les moyens de traitement du dispositif hôte (H) d'un cryptogramme hôte (HcryptoH), via l'algorithme triple DES utilisant la clef dérivée S-ENC, le nombre aléatoire hôte (HC) et le nombre aléatoire client (CC), 15 i) une étape d'envoi (62) par les moyens de traitement du dispositif hôte (H) vers le dispositif client (Cl), du cryptogramme hôte (HcryptoH) calculé à l'étape précédente, j) une étape de génération (505), par les moyens de traitement du dispositif client (Cl), du cryptogramme hôte (Hcryptoc) via l'algorithme triple 20 DES utilisant la clef dérivée S-ENC, le nombre aléatoire hôte (HC) et le nombre aléatoire client (CC), k) une étape de comparaison par les moyens de traitement du dispositif client (Cl) des cryptogrammes hôte (HcryptoH, Hcryptoc) respectivement calculés par le dispositif hôte (H) et le dispositif client (Cl), suivi de 25 l'authentification du dispositif hôte (H) si les deux calculs du cryptogramme hôte (HcryptoH, Hcryptoc) sont identiques, I) une étape de confirmation de l'ouverture d'une session et du canal sécurisé (OSCS) à travers lequel les prochaines commandes et/ou réponse générées par les dispositifs hôte et client seront réalisées. 30 20. Procédé selon la revendication 16, caractérisé en ce que, lors de l'étape de choix, si l'utilisateur actionne le moyen de saisie (23) de telle manièreque la touche permettant l'exécution est validée, l'étape de modification de l'information d'utilisation de l'état « non utilisé » en état d'utilisation « utilisé » correspond à la modification de l'état en association avec l'identifiant unique du dispositif client (Cl) sur le deuxième fichier ou tableau. 21. Dispositif portable (Cl) utilisateur formant un dispositif client (Cl) du système selon au moins une des revendications 1 à 9 et comprenant une zone mémoire sécurisée non volatile, des moyens de connexion à une interface terminal et des moyens de traitement de données, la zone mémoire comprenant au moins un identifiant unique et des io messages enregistrés en code clavier et traités comme tel par le terminal. 22. Dispositif portable (Cl) utilisateur selon la revendication caractérisé en ce que les moyens de connexion sont de type USB. 23. Dispositif portable (Cl) utilisateur selon les revendications 21 et 22, caractérisé en ce que 13 la zone mémoire du dispositif portable (Cl) comprend un premier compteur incrémenté par la génération d'un mot de passe et une clef secrète partagée, la zone mémoire du dispositif portable (Cl) comprenant en outre au moins l'adresse URL du dispositif hôte (H) ainsi qu'une indication de 20 l'identification de l'application et l'identifiant unique du dispositif portable (Cl) en code interprété par le terminal comme un code clavier. 24. Dispositif portable (Cl) selon les revendications 21 à 23, caractérisé en ce que la zone mémoire du dispositif portable (Cl) comprend un premier module mis en oeuvre par les moyens de traitement du dispositif portable (Cl) 25 générant un premier mot de passe à partir de la clef secrète partagée et du premier compteur à un rang n, le premier module incrémentant le premier compteur à un rang n+1 lorsque le premier mot de passe est généré. 25. Dispositif portable (Cl) utilisateur selon la revendication 21, caractérisé en ce que le dispositif portable (Cl) comprend un fichier d'utilisation 30 stocké dans une zone mémoire secrète du dispositif portable (Cl), le fichierd'utilisation comprenant une information d'état d'utilisation du dispositif portable (Cl) : un état correspondant à un état d'utilisation « utilisé » du dispositif portable (Cl) et un état correspondant à un état d'utilisation « non utilisé », la zone mémoire secrète comprenant le fichier d'utilisation étant accessible au dispositif distant (H) par un canal sécurisé entre le dispositif portable (Cl) et le dispositif distant (H), le canal sécurisé étant ouvert par un algorithme d'ouverture d'un canal sécurisé. 26. Dispositif portable (Cl) utilisateur selon les revendications 21 et 25, caractérisé en ce que la zone mémoire du dispositif portable (Cl) comprend un 10 algorithme d'ouverture d'un canal sécurisé et un jeu de trois clefs secrètes identique au jeu de trois clefs secrètes du dispositif distant (H). 27. Dispositif distant (H) formant un dispositif hôte (H) du système selon au moins une des revendications 1 à 9, comprenant une zone mémoire 15 sécurisée non volatile, des moyens de communication et des moyens de traitement de données, le dispositif distant (H) étant caractérisé en ce que le dispositif distant (H) est identifié par une adresse URL, la zone mémoire du dispositif distant (H) comprenant au moins un algorithme d'identification de l'utilisateur, un algorithme de vérification de 20 validité du dispositif portable (Cl), un algorithme d'exécution d'application, la zone mémoire du dispositif distant (H) comprenant en outre une base de données comprenant au moins un premier fichier ou tableau associant les identifiants d'utilisateurs avec les mots de passe de chaque utilisateur des dispositifs client, un deuxième fichier ou tableau associant au moins un état 25 d'utilisation du dispositif portable (Cl) avec l'identifiant unique d'un dispositif portable (Cl), un troisième fichier ou tableau associant l'adresse URL du dispositif distant (H) avec un identifiant de l'application, un quatrième fichier ou tableau associant les identifiants d'utilisateurs avec au moins un identifiant de l'application, 30 la zone mémoire du dispositif distant (H) comprenant en outre au moins une application. 28. Dispositif distant (H) selon la revendication 27 caractérisé en ce que la zone mémoire du dispositif distant (H) comprend : un cinquième fichier ou tableau associant un deuxième compteur avec l'identifiant unique de chaque dispositif client (Cl), un deuxième module mise en oeuvre par les moyens de traitement du dispositif distant (H) générant un deuxième mot de passe à partir de la clef secrète partagée et du deuxième compteur à un rang p, un troisième module comparant le premier mot de passe généré par les moyens de traitement du dispositif portable (Cl) et le deuxième mot de passe Io généré par les moyens de traitement du dispositif distant (H), le premier mot de passe ayant été étant envoyé au dispositif distant (H) par le dispositif portable (Cl), le troisième module incrémentant le deuxième compteur à un rang p+1 lorsque le deuxième mot de passe est généré. 29. Dispositif distant (H) selon les revendications 27 et 28, caractérisé 15 en ce que la zone mémoire du dispositif hôte (H) comprend un algorithme d'ouverture d'un canal sécurisé, une application d'installation d'un algorithme d'ouverture d'un canal sécurisé entre la zone mémoire secrète du dispositif client (Cl) et le dispositif hôte (H) et un jeu de trois clefs secrètes, l'application d'installation étant destinée à être envoyée au dispositif client (Cl) pour installer 20 l'algorithme d'ouverture sur le terminai (2) pour commander, par des messages envoyés au dispositif client (Cl) via l'interface, la modification de l'information du fichier d'utilisation stocké dans la zone mémoire secrète du dispositif client (Cl).