Brevet FR3013475A1 — publié le 20150522

i DOMAINE DE L'INVENTION L'invention concerne un procédé d'authentification pour accéder à un compte utilisateur d'un service sur un réseau de données, un dispositif mettant en oeuvre un tel service, et un gestionnaire de dispositifs de sécurisation. Elle s'applique, en particulier, à l'authentification multifacteur d'un utilisateur pour accéder à un tel compte utilisateur. CONTEXTE DE L'INVENTION Les services hébergés sur un réseau de données (e.g. réseau Internet) et accessibles par un utilisateur depuis un dispositif ou terminal de consultation également connecté à ce réseau de données, sont de plus en plus nombreux. Ce dispositif de consultation peut être un ordinateur personnel, un téléphone mobile de type intelligent (Smartphone en anglais), une tablette qui est un ordinateur personnel comprenant un écran tactile et typiquement dépourvu de clavier ou tout autre type de terminal connecté à un réseau de communication et permettant à un utilisateur d'interagir avec le service. Un tel service est un ensemble de logiciels hébergés sur un ou plusieurs serveurs connectés au réseau de données. Cet ensemble logiciel est programmé pour recevoir des requêtes provenant du dispositif de consultation et y répondre de façon à fournir le service considéré. Ce service est par exemple un service bancaire, ou encore un réseau social. L'accès à un tel service peut requérir une authentification de l'utilisateur du dispositif de consultation. Dans ce cas, le service fonctionne typiquement en collaboration avec une base de données d'utilisateurs ou de comptes utilisateur. Ainsi, pour accéder au service, l'utilisateur est invité à fournir une ou plusieurs informations d'authentification liées à l'un des comptes utilisateur de la base de données associée au service. Une fois authentifié, l'utilisateur peut par exemple accéder à son compte bancaire si le service est une banque, ou à son profil personnel lorsque le service est un réseau social. L'authentification peut nécessiter la saisie par l'utilisateur d'une information secrète connue de celui-ci, par exemple un mot de passe associé au compte utilisateur de l'utilisateur. Dans ce cas, l'authentification n'est valide que si l'information secrète correspond à celle enregistré pour le compte utilisateur en question dans la base de données associée au service. Toutefois, l'authentification classique d'un utilisateur par une information secrète est parfois insuffisante pour garantir la sécurité de l'accès au service. Par exemple, il est très courant qu'un utilisateur utilise une même information, typiquement un même mot de passe, pour protéger son accès à divers services n'ayant pas nécessairement de lien entre eux. Ainsi, en cas de découverte de cette information, une entité malveillante peut accéder à ce ou ces services en se faisant passer pour l'utilisateur à l'aide du mot de passe. Afin de complexifier l'authentification d'un utilisateur et ainsi d'améliorer la sécurité de l'accès à un service tel que précité, des méthodes d'authentification multifacteur peuvent être mises en oeuvre. Ces méthodes reposent pour la plupart sur l'utilisation conjointe d'une information secrète connue de l'utilisateur (e.g. mot de passe) et d'une information caractérisant l'utilisateur lui-même, typiquement une information biométrique (e.g. empreinte digitale, iris de l'oeil) et/ou d'une information obtenue via un objet appartenant à l'utilisateur (e.g. code affiché sur le terminal de l'utilisateur). Contrairement aux méthodes d'authentification classiques par facteur unique (utilisant un seul type d'information), la découverte d'une de ces informations de différents types par une entité malveillante ne permet généralement pas d'accéder au service protégé. Toutefois, l'obtention de ces informations, si elle permet d'améliorer la sécurité de l'authentification, fait souvent intervenir l'utilisateur souhaitant accéder au service, ce qui peut nuire à l'expérience utilisateur. Il existe donc un besoin d'améliorer la sécurité des processus d'authentification existants, ceci de manière aussi transparente que possible pour l'utilisateur. RESUME DE L'INVENTION La présente invention a ainsi pour objet de pallier au moins un de ces inconvénients. Dans ce contexte, un premier aspect de l'invention concerne un procédé d'authentification pour accéder à un compte utilisateur d'un service sur un réseau de données, le procédé comprenant les étapes suivantes : réception par le service d'une requête de la part d'un dispositif de consultation dudit service, ladite requête comprenant une première information d'authentification, réception par le service d'une information envoyée par un gestionnaire de dispositifs de sécurisation de l'authentification, l'information reçue par le service étant basée sur une deuxième information d'authentification en provenance d'un dispositif de sécurisation associé au compte utilisateur, et authentification par le service, basée sur la première information d'authentification et l'information reçue du gestionnaire de dispositifs de sécurisation de l'authentification. Ainsi, le procédé selon l'invention permet d'améliorer la sécurité de l'authentification. Cela est dû au fait que l'authentification repose notamment sur deux informations d'authentification provenant de deux dispositifs différents, à savoir le dispositif de consultation et le dispositif de sécurisation associé au compte utilisateur. En outre, l'expérience utilisateur est améliorée puisque la requête envoyée par le dispositif de sécurisation déclenche l'obtention d'autres informations nécessaires à l'authentification multifacteur de l'utilisateur, sans que celui-ci n'ait à proposer ou penser de lui-même à l'envoi de cette information supplémentaire. Ainsi, en apparence, le procédé ressemble pour l'utilisateur à un procédé classique d'authentification, alors que l'authentification est en réalité plus sécurisée. La requête n'est pas limitée à l'ouverture ou au démarrage du service. Elle peut viser aussi l'utilisation de ce service par l'utilisateur à partir du dispositif de consultation. D'autres caractéristiques du procédé selon des modes de réalisation de l'invention sont décrites dans les revendications dépendantes. Dans certains modes de réalisation, l'étape d'authentification peut être mise en oeuvre par le gestionnaire, notamment dans des modes où le service intègre les fonctionnalités du gestionnaire. Dans des modes particuliers de réalisation de l'invention, la deuxième information est reçue par le gestionnaire en réponse à une requête envoyée par le gestionnaire au dispositif de sécurisation. En variante, la deuxième information d'authentification est envoyée spontanément par le dispositif de sécurisation au gestionnaire lorsque celui-ci est connecté. Dans des modes particuliers de réalisation de l'invention, ladite information reçue par le service correspond à la deuxième information d'authentification envoyée par le dispositif de sécurisation. Ainsi, le service réalise lui-même la vérification des première et deuxième informations d'authentification en vue d'authentifier l'utilisateur. En variante, le gestionnaire vérifie la deuxième information d'authentification reçue du dispositif de sécurisation et en ce que l'information envoyée au service par le gestionnaire correspond au résultat de cette vérification. Ainsi, le gestionnaire peut vérifier lui-même la deuxième information d'authentification et transmettre le résultat (information) de cette vérification au service. Dans des modes particuliers de réalisation de l'invention, la deuxième information d'authentification comprend une information de localisation du dispositif de sécurisation. Dans des modes particuliers de réalisation de l'invention, l'information de localisation comprend l'adresse d'une passerelle entre un réseau local et le réseau de données hébergeant le service, ledit réseau local connectant le dispositif de sécurisation et le dispositif de consultation. Dans ces modes, le dispositif de consultation et le dispositif de sécurisation appartiennent au même réseau local, et peuvent être caractérisés par une même adresse publique (i.e. l'adresse de la passerelle) vis-à-vis du réseau de données hébergeant le service. En revanche, chacun des dispositifs connectés au réseau local aura sa propre adresse privée dans le réseau local mais cette adresse privée n'est pas toujours connue des dispositifs du réseau de données comme le gestionnaire ou le service. Ainsi, l'adresse de la passerelle entre le réseau local et le réseau de données constitue un facteur supplémentaire d'authentification, ce qui permet de de sécuriser davantage l'accès au service. En variante, l'information de localisation peut être un ensemble de coordonnées géographiques ou encore de repères géographiques. Ces informations peuvent être données par une position GPS, par triangulation GSM (localisation GSM) ou encore localisation Wi-Fi. Dans des modes particuliers de réalisation de l'invention, la deuxième information d'authentification comprend un code à usage unique basé sur un secret mémorisé dans le dispositif de sécurisation. Dans des modes particuliers de réalisation de l'invention, le dispositif de sécurisation est connecté au gestionnaire au moyen d'une connexion persistante initiée par le dispositif de sécurisation. Ainsi, dans ces modes, le gestionnaire et le dispositif de sécurisation peuvent alors communiquer directement, de façon indépendante du dispositif de consultation, à partir duquel l'utilisateur cherche à s'authentifier. Dans des modes particuliers de réalisation de l'invention, l'association du dispositif de sécurisation et du compte utilisateur comprend les étapes suivantes : saisie sur le dispositif de consultation, d'un code présenté par le dispositif de sécurisation, envoi par le dispositif de consultation, du code saisi, au service, et activation de l'association par le service. Ces étapes visent à effectuer l'association préalable du dispositif de sécurisation avec le compte utilisateur. Le code saisi peut être basé sur un identifiant unique du dispositif de sécurisation. Ainsi, le code peut permettre de retrouver le dispositif de sécurisation, par exemple à l'aide d'une table de correspondances. En particulier, le code saisi peut correspondre directement à l'identifiant unique du dispositif de sécurisation. Ainsi, le code désigne directement le dispositif de sécurisation. En variante, le code saisi peut être basée sur un code couleur, ou un numéro affiché sur le dispositif de sécurisation, indépendant du dispositif de sécurisation (ou du moins différent de son identifiant). Ainsi, la saisie et l'envoi de ce code au service par le dispositif de consultation, suite à sa récupération sur le dispositif de sécurisation, permet de montrer que le dispositif de sécurisation est effectivement couplé au compte utilisateur du service. La saisie peut être écrite ou vocale (dictée).Ce code peut être temporaire, par exemple affiché sur le dispositif de sécurisation, ou en variante permanent, par exemple imprimé ou gravé sur le dispositif de sécurisation. Le code saisi et reçu par le service peut être enregistré en association avec le compte utilisateur, dans une base de données associée au service. L'association du dispositif de sécurisation et du compte utilisateur peut comprendre en outre les étapes suivantes : envoi du code reçu par le service à un gestionnaire de dispositifs de sécurisation, et vérification par le gestionnaire du code reçu. Ainsi, l'association du dispositif avec le compte utilisateur est d'autant plus sécurisée. En variante, le service peut lui-même vérifier le code en collaboration avec une base de données qui lui est associée. Le code vérifié par le gestionnaire peut être enregistré en association avec un identifiant du service, dans une base de données associée au gestionnaire. Dans des modes particuliers de réalisation de l'invention, la réception de la deuxième information d'authentification par le gestionnaire requiert la confirmation d'un utilisateur du dispositif de consultation. Par exemple, elle peut ajouter un facteur de localisation de l'utilisateur dans l'authentification. Par exemple, la confirmation peut consister à presser un bouton sur l'autre dispositif, ou encore à fournir une information biologique comme une empreinte digitale. Cela permet de prendre en compte un facteur supplémentaire (e.g. validité de l'empreinte, rétinienne ou autre) pour authentifier l'utilisateur. La validation biométrique apporte un niveau de confiance supplémentaire, elle permet notamment de prouver que l'utilisateur est présent au moment de l'envoi de l'information d'authentification. Par exemple, elle peut ajouter un facteur de localisation de l'utilisateur dans l'authentification. Un deuxième aspect de l'invention concerne un dispositif mettant en oeuvre un service sur un réseau de données, le dispositif comprenant : des moyens de réception d'une requête de la part d'un dispositif de consultation dudit service, ladite requête comprenant une première information d'authentification, des moyens de réception d'une information envoyée par un gestionnaire de dispositifs de sécurisation de l'authentification, l'information reçue par le service étant basée sur une deuxième information d'authentification en provenance d'un dispositif de sécurisation associé au compte utilisateur, et des moyens d'authentification, basés sur la première information d'authentification et l'information reçue du gestionnaire de dispositifs de sécurisation de l'authentification. Un troisième aspect de l'invention concerne un gestionnaire de dispositifs de sécurisation de l'authentification pour accéder à un compte utilisateur d'un service sur un réseau de données, comprenant : des moyens de réception d'une information d'authentification en provenance d'un dispositif de sécurisation, et des moyens d'envoi d'une information au service, basée sur la deuxième information d'authentification. Un tel gestionnaire de dispositifs de sécurisation est typiquement un serveur hébergé sur le réseau de données, capable de gérer une flotte de dispositifs de sécurisation, liés aux comptes utilisateurs d'un ou de plusieurs services également hébergés sur le réseau de données. Les échanges entre le dispositif de sécurisation et le gestionnaire, et/ou entre le service et le gestionnaire, et/ou entre le service et le dispositif de consultation peuvent être conformes à la norme ISO 7816 (trames APDU). Le dispositif de sécurisation peut être par exemple un compagnon de sécurité équipé d'une interface utilisateur (par exemple des leds), une carte à puce ou UICC (Universel Integrated Circuit Card) selon la norme ETSI TR 102 216, ou encore un téléphone intelligent (Smartphone en anglais) exécutant une application sécurisée. Le dispositif de sécurisation peut comprendre un élément sécurisé embarqué (eSE) ou amovible. Les avantages, buts et caractéristiques particulières des dispositifs selon les différents aspects de l'invention sont similaires à ceux du procédé précité. Dans un mode particulier de réalisation, les différentes étapes du procédé précité sont déterminées par des instructions de programmes d'ordinateurs. En conséquence, l'invention vise aussi un programme d'ordinateur sur un support d'informations, ce programme étant susceptible d'être mis en oeuvre par un microprocesseur, ce programme comprenant des instructions adaptées à la mise en oeuvre des étapes du procédé tel que mentionné ci-dessus. Ce programme peut utiliser n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable, par exemple un script. L'invention vise aussi un support d'informations lisible par un microprocesseur, et comprenant des instructions d'un programme d'ordinateur tel que mentionné ci-dessus. Le support d'informations peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comprendre un moyen de stockage, tel qu'une ROM, par exemple une ROM de microcircuit, ou encore un moyen d'enregistrement magnétique, par exemple un disque dur, une mémoire flash, ou un moyen d'enregistrement optique, par exemple CD, DVD ou encore Blu-ray. D'autre part, le support d'informations peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur une plateforme de stockage d'un réseau de type Internet. Alternativement, le support d'informations peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question. Le support d'informations et le programme d'ordinateur précités présentent des caractéristiques et avantages analogues au procédé qu'ils mettent en oeuvre. BREVE DESCRIPTION DES FIGURES D'autres particularités et avantages de l'invention apparaîtront encore dans la description ci-après, illustrée par les figures ci-jointes qui en illustrent des exemples de réalisation dépourvus de tout caractère limitatif. Sur les figures : - La Figure 1 illustre une situation dans laquelle des dispositifs selon les différents aspects de l'invention conformes à des modes particuliers de réalisation, sont représentés, - La Figure 2 représente sous forme de chronogramme, les principaux échanges intervenant au cours du procédé d'authentification selon des modes particuliers de réalisation de l'invention, - La Figure 3 représente sous forme chronogramme, des étapes de l'association d'un dispositif de sécurisation avec un compte utilisateur, conformes à des modes particuliers de réalisation de l'invention. DESCRIPTION DETAILLEE DE L'INVENTION De façon générale, l'invention concerne l'authentification multifacteur d'un utilisateur pour accéder à un compte utilisateur d'un service sur un réseau de données pouvant héberger divers services. L'aspect multifacteur de l'authentification a ici la particularité de faire intervenir deux dispositifs différents, liés au moyen d'un réseau local. Ces deux dispositifs sont typiquement un dispositif de consultation du service, à partir duquel l'utilisateur souhaite utiliser le service, et un dispositif de sécurisation, chargé de sécuriser davantage l'authentification de l'utilisateur. De manière générale, un enjeu de la présente invention est de sécuriser l'authentification de l'utilisateur par l'obtention d'une seconde information d'authentification venant confirmer une première information d'authentification obtenue dans le processus de connexion de l'utilisateur au service, depuis son dispositif de consultation. Cette seconde information d'authentification provient du dispositif de sécurisation, qui a été préalablement associé au compte utilisateur en vue de cette sécurisation de l'authentification. L'opération d'association ou de couplage du dispositif de sécurisation avec le compte utilisateur n'est mise en oeuvre qu'une fois, préalablement aux opérations d'authentification proprement dites. Ce couplage préalable permet de maintenir l'authentification aussi transparente que possible pour l'utilisateur. Dans certains modes de réalisation, la seconde information d'authentification est directement obtenue du dispositif de sécurisation, par le service. Pour ce faire, le dispositif de sécurisation peut ouvrir une connexion persistante auprès du service. Cette connexion permet au service par exemple d'envoyer une requête pour obtenir la seconde information d'authentification et d'en recevoir la réponse de la part dispositif de sécurisation ainsi connecté. Cette connexion persistante, lorsqu'elle est à l'initiative du dispositif de sécurisation, permet en outre de régler les problèmes liés à l'accès limité (par exemple à l'aide d'un pare feu) de dispositifs d'un réseau local à un réseau plus global (réseau de données ici). En variante, la seconde information d'authentification peut être envoyée spontanément par le dispositif de sécurisation, au gestionnaire ou au service. L'envoi spontané de cette seconde information d'authentification peut être périodique. Par exemple, le dispositif de sécurisation peut envoyer la seconde information régulièrement tant qu'il est actif, de sorte que sa déconnexion est facilement détectable puisqu'elle correspond à l'interruption des envois. En variante, l'envoi peut être déclenché par un événement particulier. Cet événement particulier est par exemple une interaction entre l'utilisateur et le dispositif de sécurisation. Par exemple, il peut s'agir de la pression d'un bouton par l'utilisateur. La seconde information peut être envoyée par le dispositif de sécurisation indépendamment de toute requête d'accès. En variante, l'événement particulier peut correspondre à la réception d'une requête d'accès au service. Dans certains modes de réalisation, l'information d'authentification est confirmée si l'adresse source de la réponse du dispositif de sécurisation contenant la deuxième information d'authentification correspond à l'adresse source de la requête d'accès au service, émise par le dispositif de consultation. Cela permet de vérifier que le dispositif de sécurisation et le dispositif de consultation utilisé pour l'accès au service sont connectés au même réseau local (LAN). La similarité attendue des adresses sources est due au fait que typiquement, les différents dispositifs connectés à un même réseau local communiquent avec le réseau de données au travers d'une même passerelle, et que celle-ci implémente typiquement un protocole de traduction d'adresses NAT (Network Address Translation en anglais). Par conséquent, tous les messages issus d'un dispositif connecté au réseau local possèdent alors la même adresse source correspondant à l'adresse de la passerelle sur le réseau de données. L'adresse de la passerelle correspond ici à l'adresse publique des dispositifs connectés au réseau local (ici, au moins le dispositif de sécurisation et le dispositif de consultation), affectée par le fournisseur d'accès à la passerelle. De manière générale, l'invention couvre aussi les modes dans lesquels une information de localisation permettant de localiser un dispositif sécurisé connecté au même réseau local que le dispositif de sécurisation est reçue par le gestionnaire ou par le service comme deuxième information d'authentification du compte utilisateur. Cette information de localisation peut être autre chose qu'une adresse de passerelle entre le réseau local et le réseau de données. Par exemple, il peut s'agir de coordonnées géographiques de la passerelle, par exemple des coordonnées GPS ou des coordonnées obtenues par triangulation GSM ou encore localisation Wi-Fi. Dans certains modes de réalisation, cette seconde information 30 d'authentification est remplacée ou complémentée par une autre information d'authentification émise par le dispositif de sécurisation. Il peut s'agir par exemple d'un mot de passe à usage unique généré par le dispositif de sécurisation ou encore d'une information biométrique demandée par le dispositif à l'utilisateur, par exemple une empreinte digitale ou une lecture d'iris. Dans ce cas, l'utilisateur est mis à contribution dans le but de renforcer encore la sécurité de l'accès au service. Dans ce cas, l'augmentation de la sécurité de l'accès du à cette contribution n'est plus tout à fait transparente pour l'utilisateur, mais peut se justifier pour des services particulièrement sensibles. Ainsi, selon les modes de réalisation, le service ou le gestionnaire est en charge de la vérification de la seconde information de sécurité, par exemple en comparant l'adresse source du message de réponse obtenu du dispositif de sécurisation avec celle de la requête d'accès obtenue et/ou transmise par le service. De manière générale, la terminologie « requête d'accès » utilisée par la suite pour des raisons de simplicité, n'est pas limitée aux requêtes envoyées par le dispositif de consultation au service à l'ouverture ou au démarrage d'une session de communication entre le dispositif de consultation et le service. Elle vise aussi les requêtes envoyées par le dispositif de consultation au service tout au long de (ou durant) l'utilisation de ce service par l'utilisateur. Grâce à l'invention, une simple opération d'association préalable du dispositif de sécurisation avec le compte utilisateur permet ensuite de disposer d'une procédure simple et sécurisée pour authentifier, de manière plus sécurisée, un utilisateur souhaitant accéder à son compte utilisateur d'un service. Un autre avantage de l'invention est que les communications entre le dispositif de sécurisation et le service sont indépendantes du dispositif de consultation. Ainsi, dans le cas où le dispositif de consultation est compromis, par exemple par un virus malveillant, les informations d'authentification supplémentaires (deuxième information d'authentification) fournies par le dispositif de sécurisation ne peuvent pas être découvertes ou manipulées car elles ne transitent jamais par le dispositif de consultation. La Figure 1 illustre une situation dans laquelle des dispositifs selon les différents aspects de l'invention conformes à des modes particuliers de réalisation, sont représentés. Ces dispositifs peuvent mettre en oeuvre un procédé d'authentification conforme à l'invention, dont les étapes seront décrites dans la suite de la description. Sur la Figure 1, un dispositif de consultation 10 est connecté à un réseau local 12 LAN (pour Local Area Network en anglais) au moyen d'un lien de communication 14. Ce dispositif de consultation 10 est par exemple un ordinateur portable ou un terminal mobile (e.g. téléphone ou tablette tactile). Son architecture comprend donc au moins les éléments constitutifs de l'architecture classique de base d'un PC ou d'un terminal. Ces éléments connus ne seront pas décrits plus avant. Selon certains modes de réalisation, le dispositif de consultation 10 peut comprendre en outre un clavier virtuel ou physique, un capteur d'empreinte, un module d'analyse / de reconnaissance vocale, un module de reconnaissance faciale, un module d'analyse rétinienne, ou d'autres modules permettant la fourniture (saisie) d'informations d'authentification par un utilisateur de ce dispositif de consultation 10. Le réseau local 12 peut être par exemple un réseau Ethernet et le lien de communication 14 peut être par exemple un câble Ethernet. En variante, le réseau local 12 peut être un réseau Wi-Fi et le lien de communication 14 peut être alors une connexion sans fil. Le réseau local 12 peut être d'un autre type, de même que le lien de communication 14. Le réseau local 12 peut être un réseau Bluetooth, un réseau domestique ou personnel, ou bien correspondre par exemple à un réseau lntranet d'une entreprise. D'autres dispositifs référencés 16 et 18 peuvent également être connectés au réseau local 12 par l'intermédiaire de liens de communication, respectivement référencés 20 et 22. Ces dispositifs sont des dispositifs de sécurisation de l'authentification, conformes à des modes de réalisation de l'invention. De manière générale, le dispositif de sécurisation est typiquement conforme aux Critères Communs selon la norme internationale ISO/CEI 15408 (FIPS). Dans cet exemple, deux dispositifs de sécurisation sont représentés, toutefois, l'invention couvre également les cas avec un ou plus de dispositifs de sécurisation. Dans cet exemple, le dispositif de sécurisation 16 est par exemple un compagnon de sécurité, par exemple équipé de Leds. Ce compagnon de sécurité 16 peut comprendre un élément sécurisé, par exemple adapté à mettre en oeuvre des instructions correspondant à des étapes d'un procédé d'authentification selon des modes de réalisation de l'invention Ces instructions sont par exemple sous forme d'un applet JavaCard, ou sous forme d'un morceau de code natif. Le dispositif de sécurisation 18 est par exemple un téléphone mobile comprenant en mémoire une application de sécurité pouvant être mise en oeuvre par le téléphone. Par exemple, le téléphone 18 peut embarquer un élément sécurisé, par exemple adapté à mettre en oeuvre des étapes d'un procédé d'authentification selon des modes de réalisation de l'invention. Cet élément sécurisé est par exemple une carte SIM (pour Subscriber Identity Module en anglais), USIM, ou une carte microSIM. Les dispositifs de sécurisations 16 et 18 peuvent également être équipés de d'un capteur d'empreinte, d'un module d'analyse rétinienne, et/ou d'un module de reconnaissance faciale. Pour des raisons de simplicité, dans la suite de la description, les procédés feront référence indifféremment au dispositif de sécurisation 16 et au dispositif 18. Par la suite , ce qui est décrit pour le dispositif de sécurisation 16 en termes de procédé s'applique à tout dispositif susceptible de jouer le rôle de dispositif de sécurisation de l'authentification d'un utilisateur en fournissant ou ajoutant un facteur supplémentaire d'authentification, présentant des caractéristiques similaires à celles décrites en référence aux dispositifs de sécurisation 16 et 18. Le réseau local 12 peut comprendre ou être connecté à une passerelle GTW 24 (pour Gateway en anglais), jouant le rôle d'un routeur pour les paquets de données provenant du réseau local 12, à destination d'un dispositif situé dans un réseau situé à l'extérieur de ce réseau local 12. Par exemple, le réseau local 12 est connecté par l'intermédiaire de la passerelle 24 à un réseau de données WAN 26 (pour Wide Area Network en anglais), par exemple le réseau Internet. En variante, la passerelle 24 peut être directement connectée au réseau de données 26 ou bien faire partie de ce réseau de données 26. Pour effectuer le routage des paquets de données en provenance du réseau local 12 et à destination d'un dispositif du réseau de données 26, la passerelle 24 peut utiliser une technologie de routage de type NAT (pour Network Address Translation en anglais). L'utilisation de cette technologie a notamment pour effet d'estampiller les paquets de données transmis par la passerelle 24 d'une adresse source correspondant à l'adresse de la passerelle 24. Ainsi, du point de vue du réseau de données, les paquets de données émis par les dispositifs connectés au réseau local 12 ont une adresse d'origine commune. L'invention prévoit, dans certains modes de réalisation, d'utiliser cette caractéristique commune comme facteur supplémentaire d'authentification, comme décrit plus en détail par la suite. D'autre part, le réseau local 12 est connecté à un dispositif d'accès à un service 28 par l'intermédiaire de la passerelle 24 et du réseau de données 26, au moyen d'un lien de communication 30. Plusieurs services peuvent être disponibles sur le réseau de données 26, mais pour des raisons de clarté, seul un service 28 est représenté. Il est à la portée de l'homme du métier d'adapter les enseignements relatifs à ce service au cas où plusieurs services sont disponibles sur ce réseau de données, ou encore sur différents réseaux de données. Le service 28 peut comprendre ou bien être lié à une base de données 32 dans laquelle sont stockés des comptes utilisateur en association avec des informations d'authentification, par exemple des couples identifiant / mot de passe ainsi que diverses informations telles que des codes permettant d'identifier des dispositifs associés au compte utilisateur, par exemple intervenant dans l'authentification, comme il sera décrit plus avant par la suite. Le dispositif de consultation 10 peut potentiellement accéder au service 28 grâce aux liens de communication 14 et 30, et à la passerelle 24, sous réserve d'une authentification positive, comme il sera expliqué dans la suite de la description. Un gestionnaire de dispositifs de sécurisation 34 (ou gestionnaire de flotte) peut également être connecté au réseau de données 26. Ce gestionnaire est alors en charge de la gestion d'un ensemble de dispositifs de sécurisation pour un ensemble d'utilisateurs en lien avec un ou plusieurs services. Il est typiquement géré par le fournisseur des dispositifs de sécurisation. Ce gestionnaire permet de dispenser le service de certaines tâches relatives à la sécurité des comptes utilisateur, comme par exemple l'obtention de certaines informations d'authentification, ainsi qu'éventuellement leur traitement. Les services correspondants maintiennent ainsi leur qualité de service, malgré les traitements supplémentaires induits par l'amélioration du niveau de sécurité de l'authentification pour y accéder. Le gestionnaire 34 est caractérisé par un domaine fixe (DNS) et permet, en collaboration avec une base de données 36, de répertorier les dispositifs de sécurisation connectés au réseau de données 26 (e.g. 16 et 18) ainsi que leur état de 35 connexion. Le gestionnaire de dispositifs de sécurisation 34 est en outre connecté au service 28 au moyen d'un lien de communication 38. Ainsi, la base de données 36 associée stocke des identifiants de dispositifs, mais aussi de services. Comme il sera expliqué plus en détail par la suite en référence aux étapes de procédés conformes à l'invention, cette base de données 36 peut également stocker des codes de couplages entre les dispositifs de sécurisation et des comptes utilisateur des services identifiés sur le réseau de données. Le gestionnaire de dispositifs de sécurisation 34 est également connecté au réseau local 12 au moyen du lien 40 avec la passerelle 24. Ainsi, lorsqu'un dispositif du réseau local 12 souhaite accéder au réseau de données, il peut envoyer une requête de connexion avec son identifiant, au gestionnaire 34. En réponse, le gestionnaire 34 peut mémoriser l'identifiant (unique) de ce dispositif dans la base de données 36. Cet identifiant est par exemple l'adresse MAC du dispositif de sécurisation, et permet de retrouver le dispositif de sécurisation dans le réseau local, malgré le fait que l'adresse d'origine de la requête de connexion est commune à tous les dispositifs connectés au réseau local. Le gestionnaire peut ensuite mémoriser un couplage entre ce dispositif de sécurisation et un compte utilisateur d'un service du réseau de données, par exemple le service 28. L'association d'un dispositif de sécurisation avec un compte utilisateur sera décrite en détail par la suite, notamment en référence à la Figure 3. Dans d'autres modes de réalisation, chaque service (e.g. le service 28) est conçu pour gérer lui-même l'association d'un dispositif de sécurisation avec un compte utilisateur. Dans ces modes, lorsqu'un dispositif du réseau local 12 souhaite accéder au réseau de données, il peut envoyer une requête de connexion avec son identifiant, au service 28. Et en réponse, le service 28 peut mémoriser l'identifiant (unique) de ce dispositif dans la base de données 32 associée, par exemple en association avec le ou les comptes utilisateur, s'il y a lieu. Pour des raisons de simplicité, la description se focalise par la suite, de manière non-limitative, sur le cas du réseau de données Internet. Les différents dispositifs sont représentés notamment par leur adresse IP, et les échanges sont conformes au protocole Internet. Dans ce contexte, le service est un service web et peut être accédé au moyen d'un navigateur exécuté sur le dispositif de consultation à partir duquel un utilisateur souhaite accéder au service web. Préférentiellement, les communications entre les dispositifs de sécurisation 16 et 18, et le gestionnaire 34 ou le service 28, sont conformes à un protocole de communication asynchrone nécessitant le maintien d'une connexion persistante, tel que par exemple le protocole WebSocket, TOP, ou encore le protocole XMPP (pour Extensible Messaging and Presence Protocole en anglais) permettant de 'pousser' spontanément les messages vers le destinataire (mode « push »). Les échanges entre le dispositif de consultation 10 et le gestionnaire 34 (via les liens 14 et 40), et/ou entre le dispositif de consultation 10 et le service 28 (via les liens 14 et 30) et/ou entre le service 28 et le gestionnaire 34 (via le lien 38) se font 10 par exemple via des requêtes de type HTTP GET/POST. Ainsi, le protocole permettant les échanges entre le dispositif de consultation 10 et le service 28 est typiquement le protocole HTTP (pour Hyper Text Trans fer Protocol en anglais) et les protocoles associés comme HTTPS pour la version sécurisée. 15 En variante, une technique de découverte virtuelle peut être utilisée pour détecter le dispositif de sécurisation 16 (respectivement 18) en cas de besoin. Dans ce cas, le canal de communication 20-40 n'est ouvert que lorsque le dispositif de sécurisation 16 (respectivement 18) est directement connecté sur un bus local relié (par exemple par un lien USB) au dispositif de consultation 10. La technique de 20 découverte peut aussi utiliser le Wi-Fi ou le Bluetooth Toutefois, l'invention ne se limite pas à ce type d'échanges et de communications. Il peut également s'agir d'autres protocoles de communication pouvant être propriétaires. On décrit maintenant en référence à la Figure 2, des étapes d'un procédé d'authentification selon des modes particuliers de réalisation de l'invention. Il est ici fait 25 référence aux différents dispositifs de la Figure 1, adaptés à mettre en oeuvre ledit procédé de manière conjointe. Au cours d'une étape E10 d'initialisation, le dispositif de sécurisation 16 (respectivement 18) du réseau local 12 contacte le gestionnaire de dispositifs de sécurisation 34 du réseau de données 26 afin de se connecter à ce réseau. 30 En pratique, un identifiant (e.g. adresse MAC, ou secret partagé) du dispositif de sécurisation 16 (respectivement 18) est mémorisé dans la base de données 36 associée au gestionnaire 34, et un statut « actif » lui est associé. Le canal de communication constitué par les liens 20 (respectivement 22) et 40 est ainsi maintenu ouvert. Ce canal de communication peut être un canal dédié, de sorte que lorsque le protocole de communication utilisé le permet, le gestionnaire peut envoyer des notifications « push » au dispositif de sécurisation 16 (respectivement 18) par ce canal de communication. Le dispositif de sécurisation peut être équipé pour spontanément envoyer des données au gestionnaire. Au cours d'une étape E20, un utilisateur susceptible d'avoir un compte utilisateur d'un service du réseau de données 26, typiquement le service web 28, formule une requête pour accéder à son compte utilisateur. L'accès au service 28 n'est possible que dans la mesure où l'utilisateur s'authentifie avec succès auprès du service. En pratique, l'utilisateur peut ouvrir une page web dans un navigateur installé sur le dispositif de consultation 10, cette page web permettant de contacter le service web 28. Il fournit, via la page web, une première information d'authentification et envoie cette première information dans une requête à l'attention du service 28. Cette première information d'authentification en provenance de l'utilisateur est telle que l'obtention par le service 28 prouve l'implication de l'utilisateur dans la fourniture de cette information. Elle permet d'identifier le compte utilisateur visé et d'authentifier l'utilisateur au moins partiellement. Par exemple, il peut s'agir d'une information secrète connue de l'utilisateur, typiquement un mot de passe que celui-ci fournit via la page web. L'information d'authentification peut aussi caractériser l'utilisateur lui- même, de manière biologique. Elle peut consister en une empreinte digitale, résulter d'une reconnaissance faciale ou bien d'une analyse de la rétine de l'utilisateur. Ce type d'information peut être capturé par des capteurs et modules adaptés du dispositif de consultation 10 à partir duquel l'utilisateur tente d'accéder au service 28, par exemple un capteur d'empreinte, un module de reconnaissance faciale ou un module d'analyse rétinienne. La première information d'authentification peut aussi être par exemple une information saisie par l'utilisateur suite à sa prise de connaissance à partir d'un autre dispositif (dispositif de sécurisation 16 ou 18). Cette prise de connaissance peut être visuelle, par exemple par lecture d'un code affiché (code couleur, dessin, mot...) sur l'autre dispositif, ou bien inscrit (par exemple gravé) sur l'autre dispositif. La prise de connaissance peut être également sonore, par exemple par écoute d'un message sonore diffusé par l'autre dispositif. Ainsi, la saisie de la première information d'authentification à travers la page web peut se faire au moyen d'un clavier sur le dispositif de consultation 10. En variante, l'information peut être dictée (saisie vocale), dès lors que le dispositif de consultation 10 comprend des moyens adaptés à la reconnaissance vocale. Une combinaison des deux modes de saisie est aussi couverte par l'invention. A réception de la requête d'accès, le service 28 extrait la première information d'authentification et la traite, à l'aide de la base de données associée 32. Pour ce faire, le service 28 peut vérifier la correspondance entre le compte utilisateur associé à un identifiant présent dans la requête du dispositif de consultation, et l'information d'authentification (e.g. mot de passe, empreinte digitale, rétine), dans la base de données 32. En variante, le service effectue cette vérification plus tard dans le procédé, par exemple au cours de l'étape d'authentification décrite ultérieurement. Le service 28 peut aussi extraire l'adresse d'origine de la requête du dispositif de consultation afin d'éventuellement l'utiliser ultérieurement comme facteur supplémentaire d'authentification de l'utilisateur. Comme expliqué en référence à la Figure 1, cette adresse source correspond à l'adresse de la passerelle 24 entre le réseau local 12 d'où provient la requête (car le dispositif de consultation 10 est connecté à ce réseau local 12 par le lien 14) et le réseau de données 26 auquel le service 28 est connecté au moyen du lien 30. Le service 28 peut extraire ensuite de la base de données 32, un code correspondant à un code de couplage également associé au compte utilisateur. De manière générale, un code de couplage représente l'association entre un compte utilisateur d'un service et un dispositif associé à ce compte en vue de la sécurisation de l'authentification de l'utilisateur. Il permet, soit directement (identifiant), soit indirectement (e.g. code pouvant correspondre à un identifiant par exemple dans une table de correspondance), de qualifier le dispositif de sécurisation. Un compte utilisateur peut avoir plusieurs dispositifs associés, et donc plusieurs codes de couplage associés dans la base de données associée au service. Au cours d'une étape E30, le service génère et envoie une requête d'information, visant à récupérer une information en provenance du dispositif de sécurisation correspondant au code. Dans cet exemple, la requête d'information est envoyée au gestionnaire 34. La requête d'information envoyée au gestionnaire peut comprendre l'adresse d'origine de la requête par le dispositif de consultation, en vue d'une vérification ultérieure de cette adresse, tel qu'expliqué ci-avant. Le code permet au gestionnaire 34 de trouver le dispositif de sécurisation correspondant afin d'obtenir cette information. Pour ce faire, à réception de la requête d'information, le gestionnaire 34 vérifie la présence du code de couplage dans la base de données qui lui est associée 36, et vérifie aussi que ce code est bien associé au service 28. Un dispositif de sécurisation peut être associé à plusieurs services, c'est pourquoi le gestionnaire peut avoir intérêt à vérifier que le code est bien associé au service 28, afin d'éviter toute interférence avec un autre service. Si c'est le cas, le gestionnaire 34 extrait de la base de données 36 l'identifiant du dispositif associé au code de couplage, ici le dispositif de sécurisation 16 (respectivement 18). Sinon, le procédé s'arrête, l'utilisateur n'est pas authentifié et ne peut accéder au service. L'enregistrement du code de couplage, autrement dit l'association du dispositif de sécurisation et du compte utilisateur, sera décrit plus en détail en référence à la Figure 3. Ensuite, le gestionnaire 34 peut éventuellement vérifier le statut de la connexion associé à l'identifiant du dispositif de sécurisation 16 (respectivement 18), de sorte à ce que lorsque le statut de la connexion n'est pas actif, le procédé s'arrête, l'utilisateur n'est pas authentifié et ne peut accéder au service. Dans cet exemple, la communication ouverte à l'étape El 0 est maintenue et le statut associé au dispositif de sécurisation 16 (respectivement 18) est « actif ». Au cours d'une étape E40, le gestionnaire 34 envoi une requête 30 d'authentification au dispositif de sécurisation pour obtenir une information d'authentification (deuxième information d'authentification), via le canal de communication établi à l'étape El O. Cette deuxième information d'authentification constitue un « facteur dispositif » dans l'authentification et sa génération est a priori transparente pour 35 l'utilisateur puisque celui-ci n'intervient pas dans la génération de cette seconde information d'authentification (contrairement à la première information d'authentification insérée dans la requête d'accès envoyée à l'étape E20). La deuxième information d'authentification est par exemple constituée par l'adresse du dispositif de sécurisation 16 (respectivement 18) dans le réseau de données 26, c'est-à-dire l'adresse de la passerelle 24. Ainsi la requête émise à l'étape E40 peut simplement consister à demander un acquittement (une confirmation) au dispositif de sécurisation 16 (respectivement 18) pour s'assurer que le dispositif de sécurisation 16 (respectivement 18) est toujours connecté au réseau de données (par l'intermédiaire de la passerelle 24). Dans d'autres modes de réalisation, un mécanisme de défi-réponse peut être mis en oeuvre entre le gestionnaire et le dispositif de sécurisation, afin de s'assurer que la connexion n'a pas été maintenue pas un dispositif malicieux simulant la présence du dispositif de sécurisation en vue de forcer l'authentification. En variante, le dispositif de sécurisation peut spontanément envoyer des informations d'authentification au gestionnaire, par exemple de manière régulière. En variante, la deuxième information d'authentification peut comprendre un code permettant d'authentifier le dispositif de sécurisation 16 (respectivement 18). Ce code peut être par exemple un code à usage unique et/ou à validité limitée dans le temps (TOTP pour Temporary One Time Password), généré au sein du dispositif de sécurisation 16 (respectivement 18), par exemple par l'élément sécurisé lorsque le dispositif de sécurisation 16 (respectivement 18) dispose d'un tel élément. Ce code peut éventuellement être basé sur un secret partagé avec le gestionnaire 34, le secret partagé ayant été échangé par exemple lors de l'établissement de la connexion à l'étape E10. En variante, ce secret peut être partagé avec le service 28. En pratique, l'établissement du secret peut se produire durant une phase d'initiation d'une session de communication grâce à une technique connue sous le nom de Diffie-Hellman (DH). En variante, le secret peut avoir été établi par le fournisseur du dispositif de sécurisation, ou par le fournisseur du service au cours d'une phase d'association avec le compte utilisateur (voir Figure 3). Le secret peut être mémorisé par exemple dans un élément sécurisé du dispositif de sécurisation. Dans des modes, la deuxième information d'authentification peut comprendre à la fois l'adresse du réseau local et le code précités. Au cours de l'étape optionnelle E45, le dispositif de sécurisation 16 (respectivement 18) peut éventuellement demander confirmation à l'utilisateur (e.g. par l'intermédiaire du clavier ou d'un capteur d'empreinte) pour envoyer la réponse à la requête au gestionnaire 34. Cette confirmation optionnelle constitue un facteur supplémentaire dans l'authentification puisqu'elle assure au gestionnaire que l'utilisateur se trouve à proximité du dispositif de sécurisation 16 (respectivement 18). Le dispositif de sécurisation 16 (respectivement 18) répond au cours d'une étape E50, à la requête d'authentification émise par le gestionnaire 34. Sa réponse peut prendre la forme d'un acquittement dont l'adresse d'origine est l'adresse de la passerelle 24 et/ou d'un message comprenant un code temporaire (ou toute autre information permettant d'authentifier le dispositif de sécurisation 16 auprès du gestionnaire 34). A réception de la réponse du dispositif de sécurisation 16 (respectivement 18), le gestionnaire peut extraire l'adresse d'origine de la réponse et vérifier la correspondance entre celle-ci et l'adresse d'origine de la requête d'accès reçue dans la requête de vérification à l'étape E30. En variante, le gestionnaire peut transférer telle quelle l'adresse d'origine de la réponse au service 28, afin que celui-ci vérifie la correspondance avec l'adresse d'origine de la requête d'accès. Dans ce cas, l'information requise par le service à l'étape E50 correspond à la deuxième information d'authentification émise par le dispositif de sécurisation. Dans le cas où le dispositif de sécurisation 16 (respectivement 18) a envoyé un code pour s'authentifier, le gestionnaire 34 vérifie ce code, par exemple en utilisant le secret partagé si le code est basé sur un tel secret. Le gestionnaire 34 envoie ensuite un message (étape E60) au service 28 pour lui faire savoir si les adresses et le code ont les valeurs attendues ou non. En fonction du contenu du message, le service 28 authentifie ou non l'utilisateur. Par exemple, si le message informe le service 28 que les adresses correspondent et que le code est valide, le service 28 authentifie l'utilisateur et renvoie une autorisation d'accès au cours d'une étape E70, permettant à l'utilisateur d'accéder à son compte utilisateur, par exemple à l'aide du navigateur installé sur son dispositif de consultation 10. En variante, le gestionnaire peut transmettre directement le code au service 28 afin que celui-ci vérifie lui-même la validité du code. Dans ce cas, l'information requise par le service à l'étape E50 correspond à la deuxième information d'authentification émise par le dispositif de sécurisation. L'invention couvre également des modes de réalisation dans lequel chaque service gère lui-même les dispositifs de sécurisation (sans gestionnaire 34). Dans ces modes de réalisation, le service met lui-même en oeuvre les étapes mises en oeuvre par le gestionnaire 34 dans l'exemple décrit ci-avant. En particulier, dans ces modes de réalisation, le dispositif de sécurisation se connecte au service 28 à l'étape E10. Suite à la réception de la requête d'accès (étape E20) par le dispositif de consultation 10, le service 28 vérifie, au cours de l'étape E30, dans sa base de données 32, que le dispositif de sécurisation est bien associé au compte utilisateur. Si tel est le cas, le service envoie une requête d'information directement au dispositif de sécurisation à l'étape E40, afin d'obtenir la seconde information d'authentification. A l'étape E50, le service reçoit en réponse la seconde information d'authentification. Il vérifie sa validité à l'étape E60, par exemple en collaboration avec la base de données 32, puis procède à l'authentification de l'utilisateur lorsque les informations d'authentification ont toutes la valeur attendue. Dans ce cas, le service 28 renvoie une autorisation d'accès au cours d'une étape E70, permettant à l'utilisateur d'accéder à son compte utilisateur, à l'aide du navigateur installé sur son dispositif de consultation 10. Dans tous les cas, le service 28 authentifie l'utilisateur lorsque les facteurs suivants sont vérifiés : - validité de la première information d'authentification contenue dans la requête d'accès reçue à l'étape E20, et - correspondance des adresses sources de la requête d'accès et de la réponse du dispositif de sécurisation 16 (respectivement 18) à la requête en provenance du gestionnaire 34, et/ou - validité du code émis par le dispositif de sécurisation 16 (respectivement 18) s'il y a lieu. L'invention couvre aussi des modes de réalisation combinant les différents modes décrits ci-avant. Par exemple, un mode dans lequel le service réalise le couplage des comptes utilisateur avec les dispositifs de sécurisation, mais délègue le traitement des informations au gestionnaire, ou encore un mode dans lequel le couplage est réalisé par le gestionnaire mais le service traite toutes les données d'authentification, le gestionnaire n'étant dans ce cas en charge de récupérer les informations requises auprès des différents dispositifs de sécurisation. La Figure 3 illustre l'association préalable du dispositif de sécurisation 16 (respectivement 18) avec un compte utilisateur, selon des modes de réalisation de l'invention. Il est fait ici référence aux dispositifs de la Figure 1. L'objet de cette phase d'association est de coupler un compte utilisateur avec un ou plusieurs dispositifs autres que le dispositif utilisé par l'utilisateur pour accéder au service, afin de constituer un facteur supplémentaire d'authentification et de sécuriser davantage l'authentification de l'utilisateur. Ce couplage peut être mis en place essentiellement par le service, ou bien en collaboration avec le gestionnaire. Ce dernier cas est représenté sur la Figure 3, mais les deux cas seront décrits par la suite. Au cours d'une étape E0, le dispositif de consultation 10 envoie une requête d'accès au service 28 du réseau de données 26. Cette étape est similaire à la l'étape E20 décrite en référence à la Figure 2. L'accès à ce service 28 n'est possible que dans la mesure où l'utilisateur du dispositif de consultation 10 s'authentifie avec succès auprès de ce service. En pratique, l'utilisateur peut ouvrir une page web dans un navigateur installé sur le dispositif de consultation 10, cette page web permettant de contacter le service web 28. Il fournit, via la page web, une information d'authentification et envoie cette information dans une requête à l'attention du service 28. Cette information d'authentification peut être similaire à la première information d'identification décrite en référence à la Figure 2 ou bien peut être de nature différente. Dans tous les cas, elle permet au service 28 d'identifier l'utilisateur et sa fourniture au service 28 requiert l'implication de l'utilisateur. Le service 28, en collaboration avec la base de données 32, le service 28 extrait et vérifie l'information d'authentification comprise dans la requête. Pour ce faire, le service 28 peut vérifier la correspondance entre le compte utilisateur associé à un identifiant présent dans la requête d'accès, et l'information d'authentification (e.g. mot de passe, empreinte digitale, rétine). En cas de succès, c'est-à-dire si l'information d'authentification correspond effectivement au compte utilisateur en question, le service 28 transmet au dispositif de consultation 10 une autorisation d'accès, ce qui permet à l'utilisateur d'accéder à son compte utilisateur du service 28. A ce stade, l'authentification multifacteur peut ne pas être encore activée pour ce compte utilisateur. Il s'agit donc de modifier les paramètres du compte utilisateur pour activer cette authentification plus sécurisée. En variante, le compte peut déjà être paramétré avec une authentification multifacteur, auquel cas l'idée est d'augmenter davantage le niveau de sécurité requis pour accéder au service. Il s'agit dans tous les cas de rajouter un facteur supplémentaire d'authentification, en provenance d'un autre dispositif (16 ou 18) que le dispositif de consultation 10 utilisé pour requérir l'accès au service. Pour que cela soit possible, il est nécessaire de coupler ou d'associer cet autre dispositif (dispositif de sécurisation) au compte de l'utilisateur en question. Pour ce faire, l'utilisateur saisi ou dicte au dispositif de consultation 10, un code de couplage entre le compte utilisateur en cours d'utilisation et le dispositif de sécurisation 16 (respectivement 18). La saisie (écrite ou vocale) du code de couplage a été détaillée en référence à la Figure 2. Le code de couplage peut être d'ores et déjà présent dans une base de données du réseau de données, par exemple la base de données 36 du gestionnaire 34 et/ou la base de données 32 du service 28, afin d'être vérifié par le gestionnaire 34 et/ou le service 28 avant l'association proprement dite. Au cours d'une étape E4, le dispositif de consultation 10 transmet le code de couplage saisi ou dicté au service 28. Sur réception de ce code de couplage, le service 28 génère une requête d'activation du couplage, à destination du gestionnaire 34. A ce stade, le code de couplage n'est pas durablement mémorisé dans la base de données 32. Il peut être mémorisé temporairement par exemple dans une mémoire vive liée au service 28. Cette requête d'activation comprend le code de couplage reçu du dispositif de consultation 10 à l'étape E4 et vise à activer l'association entre le dispositif de sécurisation 16 (respectivement 18) et le compte utilisateur en cours d'utilisation. Cette association permet la prise en compte d'informations d'authentification supplémentaires en provenance du dispositif de sécurisation 16 (respectivement 18) dans l'authentification du compte utilisateur, lors de la prochaine tentative de connexion au service 28 par l'utilisateur. En d'autres termes, ce couplage entraine la prise en compte de facteurs supplémentaires dans l'authentification, de sorte à sécuriser davantage l'accès au service à partir du compte utilisateur. Au cours d'une étape E6, le service 28 transmet la requête d'activation au gestionnaire 34. Dans le cas où le code de couplage a été parallèlement envoyé au gestionnaire 34, à réception de la requête d'activation émise par le service 28 à l'étape E6, le gestionnaire 34 peut effectuer un contrôle supplémentaire en vérifiant que le code reçu dans la requête correspond bien au code reçu par ailleurs. Si ces codes de correspondent pas, le procédé s'arrête et le couplage n'a pas lieu. Dans des modes particuliers de réalisation, le gestionnaire 34 vérifie également que le dispositif de sécurisation 16 est bien connecté. Cette vérification peut dans certains modes empêcher l'association si le dispositif de sécurisation n'est pas connecté. Le gestionnaire 34 enregistre le code de couplage en association avec un identifiant du dispositif de sécurisation 16 (respectivement 18) et un identifiant du service 28 ayant émis la requête d'activation, dans la base de données associée 36. Le gestionnaire 34 retourne ensuite (étape E8) au service 28 un message attestant que le couplage entre le compte utilisateur utilisé et le dispositif de sécurisation 16 (respectivement 18) est activé, en d'autres termes, que le dispositif de sécurisation est bien associé au compte utilisateur. Sur réception de ce message de réponse à la requête d'activation envoyée à l'étape E6, le service 28 enregistre dans la base de données 32 le code de couplage en association avec le compte utilisateur. En variante de cet exemple, le service peut gérer lui-même l'association du dispositif de sécurisation avec le compte utilisateur. Pour ce faire, le service active lui-même l'association puis enregistre les informations nécessaires dans la base de données associée 32. Typiquement, dans cette variante, le code de couplage correspond directement à un identifiant du dispositif de sécurisation. La base de données 32 peut en variante mémoriser une table de correspondance entre les codes de couplage et les identifiants de dispositifs de sécurisation. Dorénavant, pour authentifier un utilisateur du compte utilisateur, le service 28 devra obtenir des informations d'authentification de l'utilisateur de la part du dispositif de consultation 10 utilisé par celui-ci (voir étape E20 décrite précédemment), ainsi que des informations d'authentification de la part du dispositif de sécurisation 16 (respectivement 18) couplé au compte utilisateur (voir étape E50 décrite précédemment). Les exemples qui précèdent ne sont que des modes de réalisation de l'invention qui ne s'y limite pas. REVENDICATIONS1. Procédé d'authentification pour accéder à un compte utilisateur d'un service (28) sur un réseau de données (26), le procédé comprenant les étapes suivantes : réception (E20) par le service (28) d'une requête de la part d'un dispositif de consultation (10) dudit service (28), ladite requête comprenant une première information d'authentification, réception (E60) par le service (28) d'une information envoyée par un gestionnaire (34) de dispositifs de sécurisation de l'authentification, l'information reçue par le service (28) étant basée sur une deuxième information d'authentification en provenance d'un dispositif de sécurisation (16 ; 18) associé au compte utilisateur, et authentification par le service (28), basée sur la première information d'authentification et l'information reçue du gestionnaire (34) de dispositifs de sécurisation de l'authentification. 2. Procédé d'authentification selon la revendication 1, caractérisé en ce que la deuxième information d'authentification est envoyée spontanément par le dispositif de sécurisation (16 ; 18) au gestionnaire (34) lorsque celui-ci est connecté. 3. Procédé d'authentification selon l'une quelconque des revendications 1 à 2, caractérisé en ce que ladite information reçue par le service (28) correspond à la deuxième information d'authentification envoyée par le dispositif de sécurisation (16 ; 18). 4. Procédé d'authentification selon l'une quelconque des revendications 1 à 2, caractérisé en ce que le gestionnaire (34) vérifie la deuxième information d'authentification reçue du dispositif de sécurisation (16 ; 18) et en ce que l'information envoyée au service (28) par le gestionnaire (34) correspond au résultat de cette vérification. 5. Procédé d'authentification selon l'une quelconque des revendications 1 à 4, caractérisé en ce que la deuxième information d'authentification comprend une information de localisation du dispositif de sécurisation (16 ; 18). 6. Procédé d'authentification selon la revendication 5, caractérisé en ce que l'information de localisation comprend l'adresse d'une passerelle entre un réseaulocal et le réseau de données (26) hébergeant le service (28), ledit réseau local connectant le dispositif de sécurisation (16 ; 18) et le dispositif de consultation (10). 7. Procédé d'authentification selon l'une quelconque des revendications 1 à 6, caractérisé en ce que la deuxième information d'authentification comprend un code à usage unique basé sur un secret mémorisé dans le dispositif de sécurisation (16; 18). 8. Procédé d'authentification selon l'une quelconque des revendications 1 à 7, caractérisé en ce que le dispositif de sécurisation (16 ; 18) est connecté au gestionnaire (34) au moyen d'une connexion persistante initiée par le dispositif de sécurisation (16 ; 18). 9. Procédé d'authentification selon l'une quelconque des revendications 1 à 8, caractérisé en ce que l'association du dispositif de sécurisation (16 ; 18) et du compte utilisateur comprend les étapes suivantes : saisie sur le dispositif de consultation (10), d'un code présenté par le dispositif de sécurisation (16 ; 18), envoi par le dispositif de consultation (10), du code saisi, au service (28), et activation de l'association par le service (28). 10. Procédé d'authentification selon l'une quelconque des revendications 1 à 9, caractérisé en ce que la réception de la deuxième information d'authentification par le gestionnaire (34) requiert la confirmation d'un utilisateur du dispositif de consultation (10). 11. Dispositif mettant en oeuvre un service (28) sur un réseau de données (26), comprenant : des moyens de réception d'une requête de la part d'un dispositif de 30 consultation (10) dudit service (28), ladite requête comprenant une première information d'authentification, des moyens de réception d'une information envoyée par un gestionnaire (34) de dispositifs de sécurisation de l'authentification, l'information reçue par le service (28) étant basée sur une deuxième information d'authentification en provenance d'un 35 dispositif de sécurisation (16 ; 18) associé au compte utilisateur, etdes moyens d'authentification, basés sur la première information d'authentification et l'information reçue du gestionnaire (34) de dispositifs de sécurisation de l'authentification. 12. Gestionnaire (34) de dispositifs de sécurisation de l'authentification pour accéder à un compte utilisateur d'un service (28) sur un réseau de données (26), comprenant : des moyens de réception d'une information d'authentification en provenance d'un dispositif de sécurisation (16 ; 18), et des moyens d'envoi d'une information au service (28), basée sur la deuxième information d'authentification. 13. Programme d'ordinateur comprenant des instructions pour la mise en oeuvre d'un procédé d'authentification selon l'une quelconque des revendications 1 à 10, lorsqu'il est chargé et exécuté par un microprocesseur. 14. Support d'informations lisible par un microprocesseur, comprenant les instructions d'un programme d'ordinateur pour mettre en oeuvre un procédé selon l'une quelconque des revendications 1 à 10.20