FR 3156957 A1 20250620 FR 2314252 A 20231215 La présente invention concerne un procédé d’authentification d’un individu pour la mise en œuvre d’une transaction sur un terminal marchand (2) connecté via un réseau (20) à un serveur de validation de transaction (3), le procédé étant caractérisé en ce qu’il comprend la mise en œuvre, par des moyens de traitement de données (12) d’un terminal client (1) dudit individu également connecté au serveur (3) via ledit réseau (20), d’étapes de : (c) Réception d’une requête d’authentification dudit individu émise par ledit terminal marchand (2) via un canal de communication de proximité entre le terminal client (1) et le terminal marchand (2), ladite requête d’authentification dudit individu contenant une clé secrète dudit serveur (3) ; (d) Etablissement d’un canal de communication sécurisé entre le terminal client (1) et le serveur (3), dit second canal sécurisé, en utilisant ladite clé secrète dudit serveur (3) ; (e) Transmission de données d’authentification dudit individu au serveur (3), via ledit second canal sécurisé, en réponse à ladite requête d’authentification. Fig. 1 Procédé d’authentification d’un individu pour la mise en œuvre d’une transaction sur un terminal marchand. DOMAINE TECHNIQUE GÉNÉRAL La présente invention se rapporte au domaine du paiement par carte. Plus précisément, elle concerne un procédé d’authentification d’un individu pour la mise en œuvre d’une transaction sur un terminal marchand connecté via un réseau à un serveur de validation de transaction. ETAT DE L’ART Les terminaux de paiement utilisés par les marchands requièrent habituellement une communication sécurisée par cryptographie symétrique avec un serveur distant, impliquant le partage préalable d’une clé privée ou de matériel cryptographique permettant de la dériver. Pour éviter toute interception, les deux participants doivent communiquer dans un environnement sécurisé, et dans le cas d’un terminal physique de type POS, une possibilité est de précharger directement la clé privée en usine. Alternativement, il est aujourd’hui courant d’utiliser des terminaux mobiles grand public, tels que des smartphones, comme terminaux de paiement de marchands, notamment en téléchargeant et installant une application de paiement. Il est alors nécessaire d’obtenir la clé privée à distance. Une solution apportant satisfaction est que toutes les applications distribuées aient la même base de code, et contiennent une toolbox mettant en œuvre une technologie de type « boite blanche » (en anglais « whitebox » hébergeant de manière sécurisée une même clé secrète dite initiale (« obfuscation » de la clé dans le code – la cryptographie boite blanche permet de garantir la sécurité des clés même si les états internes de l’application sont visibles). Cette même clé initiale est utilisée pour établir une communication initiale avec le serveur, qui permet le téléchargement de matériel cryptographique pour dériver d’autres clés privées, cette fois propres à chaque terminal mobile et à chaque instanciation de l’application. Cette solution n’est pas parfaite puisque si la clé secrète initiale venait à être compromise (la boite blanche reste inéluctablement perçable), l’intégralité des communications initiales viendrait à être compromise, dans la mesure cette clé est virtuellement réutilisée dans tous les terminaux mobiles utilisant la même application, mais on limite le risque de sécurité en changeant la clé initiale régulièrement, en mettant à jour l’application et le contenu de sa Toolbox. Cependant, il est maintenant proposé une configuration dite « personnal PIN pad » dans laquelle, en complément du terminal mobile du marchand, l’utilisateur peut utiliser son propre terminal mobile pour mettre en œuvre au moins une partie de la transaction, par exemple la saisie de son PIN, notamment lorsqu’on dépasse le seuil de paiement sans contact. Une telle configuration est très appréciée car l’utilisateur a confiance dans son terminal, et cela permet d’améliorer l’hygiène (ne pas toucher un terminal tiers) et la sécurité (faire son PIN de manière discrète) de la transaction Cependant, cela implique également l’installation d’une application sur le terminal client et l’obtention de la clé privée. Cependant il y a des centaines de fois plus de terminaux client que de terminaux marchands, de sorte que le risque de compromission de la clé existant dans la solution précédente (clé secrète commune obfusquée dans le code de toutes les applications) devient trop élevé pour être gérable par des simples mises à jour. La présente invention vient améliorer la situation. PRÉSENTATION DE L’INVENTION La présente invention se rapporte donc selon un premier aspect à un procédé d’authentification d’un individu pour la mise en œuvre d’une transaction sur un terminal marchand connecté via un réseau à un serveur de validation de transaction, le procédé étant caractérisé en ce qu’il comprend la mise en œuvre, par des moyens de traitement de données d’un terminal client dudit individu également connecté au serveur via ledit réseau, d’étapes de : (c) Réception d’une requête d’authentification dudit individu émise par ledit terminal marchand via un canal de communication de proximité entre le terminal client et le terminal marchand, ladite requête d’authentification dudit individu contenant une clé secrète dudit serveur ; (d) Etablissement d’un canal de communication sécurisé entre le terminal client et le serveur, dit second canal sécurisé, en utilisant ladite clé secrète dudit serveur ; (e)Transmission de données d’authentification dudit individu au serveur, via ledit second canal sécurisé, en réponse à ladite requête d’authentification. Selon des caractéristiques avantageuses et non limitatives : Ladite clé secrète du serveur est chiffrée avec une clé de transport partagée entre le terminal client et le serveur, l’étape (d) comprenant en outre le déchiffrement préalable de ladite clé secrète du serveur. Les étapes (d) et (e) sont mises en œuvre au moyen d’une application installée sur ledit terminal client, ladite clé de transport étant enfouie dans le code de ladite application. L’étape (c) entraîne l’ouverture de ladite application si elle est déjà installée, et sinon son téléchargement depuis le réseau puis son installation. Ladite requête d’authentification dudit individu contient en outre un jeton d’authentification, l’étape (e) comprenant la transmission du jeton signé avec la clé secrète du serveur. Ladite transaction est de type paiement par carte bancaire et la requête d’authentification est une requête de saisie d’un code PIN de carte bancaire sur une interface dudit terminal client ; et lesdites données d’authentification sont des données dérivées dudit code PIN. Ledit canal de communication de proximité entre le terminal client et le terminal marchand n’est pas via le réseau. Ledit canal de communication de proximité entre le terminal client et le terminal marchand est un canal optique ou un canal radio en champ proche. Le procédé comprend la mise en œuvre, par des moyens de traitement de données du terminal marchand d’étapes préalables de : (a) établissement d’un canal de communication sécurisé entre le terminal marchand et le serveur, dit premier canal sécurisé ; (b) Récupération depuis le serveur, via ledit premier canal sécurisé, de ladite clé secrète du serveur. L’étape (b) comprend également la récupération depuis le serveur du jeton d’authentification, et l’étape (e) comprend la vérification par des moyens de traitement de données du serveur dudit jeton signé. L’étape (b) comprend la transmission au serveur d’une requête de clé secrète pour le terminal client, la génération par des moyens de traitement de données du serveur de ladite clé secrète du serveur, et si nécessaire, d’un jeton d’authentification. L’étape (b) comprend le chiffrement par les moyens de traitement de données du serveur avec la clé de transport de ladite clé secrète du serveur généré, l’étape (b) comprend de préférence également la récupération depuis le serveur d’un identifiant de ladite clé de transport. Selon un deuxième aspect, l’invention concerne un procédé de mise en œuvre d’une transaction sur un terminal marchand connecté via un réseau à un serveur de validation de transaction, comprenant le déclenchement de la transaction par un individu sur ledit terminal marchand puis la mise en œuvre du procédé d’authentification dudit individu selon le premier aspect, l’étape (b) comprenant en outre la transmission audit serveur de données descriptives de ladite transaction. Selon des caractéristiques avantageuses et non limitatives : L’étape (b) comprend la détermination par les moyens de traitement de données du terminal marchand que l’authentification dudit individu est nécessaire en fonction desdites données descriptives de la transaction. Ladite transaction est de type paiement par carte bancaire sans contact, ladite carte bancaire étant dématérialisée sur le terminal client, un même canal radio en champ proche étant utilisé pour ledit déclenchement de la transaction et l’étape (c). Selon un troisième aspect, l’invention concerne un terminal client d’un individu, connecté via un réseau à un serveur de validation de transaction, caractérisé en ce qu’il comprend des moyens de traitement de données configurés pour : Recevoir, lors d’une transaction sur un terminal marchand également connecté via le réseau au serveur de validation de transaction, une requête d’authentification dudit individu émise par le terminal marchand via un canal de communication de proximité entre le terminal client et le terminal marchand, ladite requête d’authentification dudit individu contenant une clé secrète dudit serveur ; Etablir un canal de communication sécurisé entre le terminal client et le serveur, dit second canal sécurisé, en utilisant ladite clé secrète dudit serveur ; Transmettre des données d’authentification dudit individu au serveur, via ledit second canal sécurisé, en réponse à ladite requête d’authentification. Selon un troisième aspect, l’invention concerne un ensemble d’au moins un terminal client (1) et dudit terminal marchand (2), le terminal marchand (2) comprenant des moyens de traitement de données (21) configurés pour : établir un canal de communication sécurisé entre le terminal marchand (2) et le serveur (3), dit premier canal sécurisé ; Récupérer depuis le serveur (3), via ledit premier canal sécurisé, ladite clé secrète du serveur (3). Selon des caractéristiques avantageuses et non limitatives, l’ensemble comprend en outre ledit serveur de validation de transaction. Selon une quatrième et un cinquième aspects, l’invention propose un produit programme d’ordinateur comprenant des instructions de code pour l’exécution d’un procédé selon le premier aspect d’authentification d’un individu pour la mise en œuvre d’une transaction sur un terminal marchand connecté via un réseau à un serveur de validation de transaction ou d’un procédé selon le deuxième aspect de mise en œuvre d’une transaction sur un terminal marchand connecté via un réseau à un serveur de validation de transaction ; et un moyen de stockage lisible par un équipement informatique sur lequel est enregistré un produit programme d’ordinateur comprenant des instructions de code pour l’exécution d’un procédé selon le premier aspect d’authentification d’un individu pour la mise en œuvre d’une transaction sur un terminal marchand connecté via un réseau à un serveur de validation de transaction ou d’un procédé selon le deuxième aspect de mise en œuvre d’une transaction sur un terminal marchand connecté via un réseau à un serveur de validation de transaction. PRÉSENTATION DES FIGURES D’autres caractéristiques et avantages de la présente invention apparaîtront à la lecture de la description qui va suivre d’un mode de réalisation préférentiel. Cette description sera donnée en référence aux dessins annexés dans lesquels : FIG. 1 la FIG. 1 est un schéma d’un système pour la mise en œuvre du procédé selon l’invention ; FIG. 2 la FIG. 2 est un logigramme illustrant les étapes d’un mode de réalisation du procédé d’authentification selon un aspect de l’invention ; FIG. 3 la FIG. 3 représente schématiquement la mise en œuvre d’un mode de réalisation préféré du procédé d’authentification selon un aspect de l’invention ; FIG. 4 la FIG. 4 est un logigramme illustrant les étapes d’un mode de réalisation du procédé de mise en œuvre d’une transaction selon un autre aspect de l’invention. DESCRIPTION DÉTAILLÉE Architecture La présente invention concerne un procédé d’authentification d’un individu pour la mise en œuvre d’une transaction sur un terminal marchand 2, dans un système tel que représenté sur la FIG. 1 , et avantageusement le procédé de mise en œuvre de la transaction comprenant ledit procédé d’authentification. Ladite transaction est initiée par ledit individu, au profit d’un marchand possesseur du terminal marchand 2. Entre d’autres termes il s’agit d’une transaction entre ledit individu et le marchand, valisée par ledit serveur 3. Elle est de type paiement par carte bancaire chez ledit marchand, i.e. une carte bancaire ou un terminal mobile (désigné terminal client 1) émulant une carte bancaire (de l’individu) est connecté au terminal marchand 2 assurant un rôle de terminal de paiement électronique (TPE). Cette connexion est de plus en plus souvent sans-contact (NFC), mais elle peut toujours être par insertion de la carte dans un lecteur. Le terminal marchand 2 est connecté via un réseau 20 (en particulier le réseau internet) à un serveur de validation de transaction 3, en particulier un serveur bancaire, généralement distant. De manière classique une transaction de type paiement par carte bancaire utilise un chiffrement symétrique, c’est-à-dire qu’une clé privée est associé à la carte bancaire (physique ou dématérialisée), la clé privée étant d’une part stockée directement sur la puce de la carte si elle est physique ou dans une mémoire du terminal si elle est dématérialisée, et d’autre part stockée par le serveur de validation 3. Avantageusement, des données descriptives de la transaction sont saisies par le marchand sur le terminal marchand 2, et envoyées à la carte/terminal dudit individu pour apposition de ladite signature en fonction de la clé privée, et le serveur 3 pourra vérifier que cette signature est valide, et autoriser la transaction. Le terminal client 1 et le terminal marchand 2 disposent chacun de moyens de traitement de données 11, 21 (typiquement un processeur) et de moyens de stockage de données 12, 22 (une mémoire, par exemple flash). Chacun peut en outre comporter une interface (par exemple un écran), des moyens de communication sans-fil de proximité (par exemple NFC, voir plus loin), et une caméra. Chacun des terminaux 1 et 2 (et en particulier le terminal marchand) est avantageusement un terminal mobile de type smartphone (et les éléments précédents tel qu’une caméra sont habituels pour tout terminal mobile), même si alternativement ou en complément le terminal marchand 2 peut être un terminal plus imposant (un TPE classique), disposant notamment d’un lecteur de carte. Comme expliqué, on a en outre le serveur de validation 3, typiquement un serveur bancaire, connecté aux terminaux 1 et 2 par le réseau 20. Le serveur 3 dispose également de moyens de traitement de données 31 (typiquement un processeur) et de moyens de stockage de données 32 (une mémoire, par exemple un disque dur). Principe Par authentification, on entend la vérification que l’individu souhaitant la transaction est bien celui qu’il prétend être, i.e. le possesseur de la carte/du terminal 1. Une authentification dudit individu peut être demandée par exemple : Parce que le montant de la transaction dépasse le seuil de paiement sans contact ; Parce qu’il a inséré sa carte dans le terminal marchand 2 même pour un montant plus faible ; Ou simplement parce que l’individu/le marchand/la transaction exige un niveau de protection plus élevé. De manière classique, l’utilisateur peut s’authentifier en saisissant son code PIN sur le terminal marchand 2, mais on se place ici dans le contexte évoqué dans l’introduction où l’on souhaite utiliser le terminal 1 du l’individu, notamment pour des questions de confiance (l’individu a confiance en son propre terminal), de confidentialité (il peut taper discrètement son code) ou d’hygiène (personne d’autre que lui ne touche son terminal). Ainsi, de manière préférée, l’authentification consiste la saisie dudit code PIN sur le terminal client 1, mais des techniques d’authentification alternatives pourront être utilisées comme une authentification biométrique. En outre ladite authentification peut être une authentification forte en vérifiant (outre l’identité de l’utilisateur) que le terminal client 1 appartient bien à l’individu via un identifiant unique. Pour ce faire, et comme expliqué, le terminal client 1 utilise préférentiellement une application dédiée, téléchargée classiquement depuis un store. Le présent procédé évite toute nécessité d’enfouir une clé privée dans le code de l’application, au mieux on a éventuellement une clé de transport enfouie, qui même si elle était compromise ne mettrait pas en péril les communications. La solution proposée est d’exploiter d’une part l’existence d’un canal de communication sécurisé entre le terminal marchand 2 et le serveur 3, dit première canal sécurisé (par la toute méthode de l’art y compris la clé privée enfouie dans le code de l’application de paiement du terminal marchand 2 – dont on rappelle qu’elle est partagée seulement entre les terminaux marchand 2, qui sont des centaines de fois moins nombreux que les terminaux client 1), et d’autre part la proximité nécessaire entre le terminal marchand 2 et le terminal client 1 lors d’une transaction : La clé privée (dite clé secrète du serveur 3) nécessaire à l’établissement d’un canal de communication sécurisée entre le terminal client 1 et le serveur 3, dit second canal sécurisé, peut ainsi être transmise du serveur 3 au terminal client 1 d’abord via le premier canal sécurisé, puis via un canal de communication de proximité entre le terminal client 1 et le terminal marchand 2, certes non sécurisé, mais quasiment impossible à intercepter puisque uniquement local. Procédé – coté terminal marchand En référence aux figures 2 et 3 , le présent procédé commence par une étape préalable optionnelle (a), mis en œuvre par les moyens de traitement de données 21 du terminal marchand 2, d’établissement du canal de communication sécurisé entre le terminal marchand 2 et le serveur 3, dit premier canal sécurisé (notée (1) sur la FIG. 3 ). Cette méthode peut être mise en œuvre de toute manière connue, et on note que le canal peut être établi bien avant et qu’il n’est pas nécessaire d’établir un nouveau premier canal à chaque occurrence du présent procédé. Ensuite, dans une étape (b) également optionnelle, les moyens de traitement de données 21 du terminal marchand 2 récupérèrent depuis le serveur 3 (et pour le terminal client 1), via ledit premier canal sécurisé, ladite clé secrète du serveur 3 qui sera utilisée pour l’établissement du second canal sécurisé. De manière préférée, sont récupérés en même temps un jeton d’authentification et/ou un identifiant de clé de transport (voir plus loin). A noter que cette étape (b) reste également optionnelle, car il est possible que le terminal marchand récupère occasionnellement des paquets de clés secrètes, voire les génère grâce à du matériel cryptographique fournie par le serveur 3. Selon un mode de réalisation préférée, l’étape (b) est mise en œuvre à chaque transaction nécessitant une authentification et comprend tout d’abord la détermination que l’authentification dudit individu est nécessaire, en particulier en fonction desdites données descriptives de la transaction, que ce soit par exemple parce qu’il a dépassé le seuil de paiement sans contact ou parce qu’un niveau supplémentaire de sécurité est requis (pour une raison quelconque : politique du marchand, préférence du client, objet de la transaction « sensible », etc.). A noter que l’authentification pourrait être systématique. Dans tous les cas, l’étape (b) comprend avantageusement l’émission d’une requête de clé secrète pour le terminal 1, via ledit premier canal sécurisé, auprès du serveur 3 (notée (2) sur la FIG. 3 ). Cette requête peut être conjointe avec la transmission habituelle de données descriptives de ladite transaction (identifiants client/marchand, montant, etc., voir plus haut). En réponse à cette requête les moyens de traitement 31 de données du serveur 3 génèrent ((3) dans la FIG. 3 ) la clé secrète et le cas échéant un jeton du client qui sera comme l’on verra utilisé pour établir le second canal sécurisé, potentiellement aléatoirement (à noter qu’on peut alternativement avoir un stock pré-généré de clés). De manière préférée, une clé de transport est partagée entre le terminal client 1 et le serveur 3, en particulier en étant enfouie (i.e. stockée de manière obfusquée conformément aux principes de cryptographie boite blanche) dans le code d‘une application du terminal 1. Dans ce cas, ladite clé secrète du serveur 3 est chiffrée par les moyens de traitement de données 31 du serveur 3 avec ladite clé de transport (ce qui est noté (4) sur la FIG. 3 ), ce qui permet garder protégée et d’éviter un transfert en clair entre le terminal marchand 2 et le terminal client 1. A noter qu’il peut y avoir plusieurs clés de transports, d’où l’idée de joindre un identifiant de la clé de transport (par exemple un haché). En résumé, le serveur 3 transfère : La clé secrète avantageusement chiffrée Optionnellement un jeton d’authentification du client Optionnellement un identifiant de la clé de transport utilisée pour chiffrer la clé secrète. Enfin l’étape (b) peut comprendre la préparation desdits données qui viennent d’être reçues, et en particulier la génération d’une requête d’authentification de l’individu (notée (5) sur la FIG. 3 ), on verra comment plus bas. Procédé – coté terminal client La partie principale du procédé est alors mise en œuvre par les moyens de traitement de données 11 du terminal client 1. Dans une étape (c), est transmise la requête d’authentification dudit individu émise par ledit terminal marchand 2 via ledit canal de communication de proximité entre le terminal client 1 et le terminal marchand 2, ladite requête d’authentification dudit individu contenant une clé secrète dudit serveur 3 et le cas échéant le jeton les éventuels jeton d’authentification et/ou identifiant de clé de transport. Comme expliqué, on suppose que le terminal marchand 2 a déterminé que l’individu devait s’authentifier par exemple en saisissant son PIN, mais sur son propre terminal 1. On note que la requête a un double usage : elle indique au terminal client 1 qu’il doit réaliser l’authentification et elle transporte la clé sécrète qui va permettre de communiquer à ce sujet avec le serveur 3. Par « canal de communication de proximité » on entend un canal de communication à courte portée qui tire parti du fait que l’individu doit être présent et même accéder au terminal marchand 2 pour initier la transaction (par exemple en insérant sa carte), avantageusement ne passant via le réseau 20 (bien que chacun des terminaux 1 et 2 soit de son côté connecté au réseau 20). De manière préférée, ledit canal de communication de proximité est un canal sans fil en particulier choisi parmi un canal optique et un canal radio en champ proche, mais ce pourrait être par exemple simplement un canal filaire (en connectant les terminaux 1 et 2 par un câble). Dans le mode de réalisation « canal optique », la requête d’authentification prend la forme d’un signal visuel, en particulier un code barre 2D, et en particulier un QR code émis par le terminal marchand 2 (affiché par un écran) et capté par une caméra du terminal client 1. Plus précisément, le code barre 2D s’affiche et l’individu est invité à le scanner avec son terminal 1. Dans le mode de réalisation « canal radio en champ proche », la requête d’authentification prend la forme d’un signal radio, en particulier un signal NFC (mais ce pourrait par exemple alternativement être du Bluetooth, etc.), transféré entre les terminaux 1 et 2 en les mettant l’un contre l’autre. Dans un mode de réalisation particulièrement préféré, on couple paiement sans contact avec une carte dématérialisée sur le terminal 1 et requête d’authentification en utilisant un même canal NFC : L’utilisateur approche son terminal 1 du terminal marchand 2 pour payer sans contact (potentiellement même si l’on dépasse la limite du paiement sans contact !) ; Le terminal marchand 2 échange avec le terminal client 1 via le canal NFC de sorte à obtenir et signer les données de transaction de manière classique, et détermine qu’une authentification de l’individu est nécessaire pour cette transaction ; Il met en œuvre les étapes (b) puis (c) de sorte à récupérer la clé privée du serveur 3 et transférer la requête d’authentification via le canal NFC toujours ouvert : ces étapes se sont faites en une fraction de seconde pendant que les deux terminaux 1 et 2 étaient proches, de sorte que l’expérience n’est pas plus compliquée que d’habitude et l’utilisateur ne fait pas la différence avec un paiement sans contact ordinaire. Ensuite, le procédé comprend une étape (d) d’établissement du canal de communication sécurisé entre le terminal client 1 et le serveur 3, dit second canal sécurisé, en utilisant ladite clé secrète dudit serveur 3. L’étape (d) comprend en pratique (avant ou après l’établissement du canal) l’authentification de l’individu (i.e. le traitement de la requête), comme expliqué en lui demandant la saisie du PIN, la vérification d’un trait biométrique, etc.). De manière préférée et comme évoqué, les étapes (d) et comme on verra (e) sont mises en œuvre au moyen d’une application installée sur ledit terminal client 1, l’éventuelle clé de transport étant le cas échéant enfouie dans le code de ladite application. Alors (et ce quel que soit le canal de communication de proximité) l’étape (c) entraîne avantageusement automatiquement l’ouverture de ladite application si elle est déjà installée, ou du moins son téléchargement depuis le réseau 20 puis son installation (notée (6) sur la FIG. 3 ). Ainsi, pour revenir sur le mode de réalisation full NFC présenté, au lieu d’avoir une information de fin de transaction, l’application s’ouvre et affiche une interface d’authentification de l’individu (par exemple affichage du clavier pour la saisie du PIN, ou demande de vérification du visage de l’individu). En ce qui concerne l’établissement du deuxième canal sécurisé, il pourra être mis en œuvre de toute façon connue en utilisant ladite clé secrète du serveur 3. Par exemple, dans le mode de réalisation dans lequel un jeton d’authentification est transmis également dans la requête, l’étape (d) peut comprendre la signature du jeton avec ladite clé privée du serveur 3 et la transmission du jeton signé au serveur 3 (notée (7) sur la FIG. 3 ). Ce dernier vérifie la signature et le jeton (par comparaison avec la clé et le jeton qu’il a transmis - notée (8) sur la FIG. 3 ), et autorise l’établissement du canal si la vérification est concluante (notée 9) sur la FIG. 3 ). Dans tous les cas, l’étape (d) peut comprendre le déchiffrement préalable de ladite clé secrète du serveur 3 (avec la clé de transport en particulier enfouie dans l’application – le cas échéant identifiée avec l’éventuel identifiant de clé de transport transmis dans la requête d’authentification). Enfin, le procédé comprend une étape (e) de transmission de données d’authentification dudit individu au serveur 3, via ledit second canal sécurisé, en réponse à ladite requête d’authentification. Par données d’authentification on entend toute preuve de ladite authentification nécessaire au serveur 3, par exemple des données dérivées dudit code PIN (que ce soit le code PIN en lui-même, un haché ou un chiffré du code PIN, une preuve qu’un code PIN correct a été saisi, etc.). Ce peut être alternativement une donnée garantissant qu’une donnée biométrique candidate coïncidant avec une donnée biométrique de référence a été acquise ou toute autre donnée prouvant l’identité dudit individu etc. Transaction Selon un deuxième aspect, en référence à la FIG. 4 , l’invention propose le procédé de mise en œuvre d’une transaction sur un terminal marchand 2 connecté via un réseau 20 à un serveur de validation de transaction 3, comme expliqué typiquement une transaction de type paiement par carte bancaire. Ce procédé comprend le déclenchement de la transaction par un individu sur ledit terminal marchand 2 (par exemple en insérant sa carte dans le terminal marchand 2, ou l’approchant en sans-contact), puis la mise en œuvre du procédé d’authentification dudit individu selon le premier aspect. Dans le but de mettre en œuvre la transaction, l’étape (b) comprend en outre la transmission audit serveur 3 de données descriptives de ladite transaction. Si le résultat de l’authentification est positif, la transaction est bien traitée du coté serveur 3, et le procédé comprend avantageusement une étape (f) de réception, de la part du serveur 3 (par le terminal client 1 et/ou le terminal marchand 2, préférentiellement les deux) d’une notification de confirmation de la transaction. Bien entendu, si aucune donnée d’authentification dudit individu au serveur 3 n’est transmise au serveur 3 à l’étape (e), ou des données incorrectes, le serveur 3 rejette la transaction et une notification d’échec de la transaction est reçue. On suppose également que si les données descriptives de la transaction transmises à l’étape (b) sont incorrectes (par exemple signature fausse qui témoigne d’une carte falsifiée) ou si la transaction est impossible (par exemple compte non provisionné), on passe directement à la notification d’échec de la transaction. De manière préférée, l’étape (b) comprend la détermination par les moyens de traitement de données 21 du terminal marchand que l’authentification dudit individu est nécessaire en fonction desdites données descriptives de la transaction. Si c’est bien le cas, alors l’étape (b) comprend comme expliqué l’envoi au serveur de la requête de clé privée pour le terminal client 1 (outre les données de la transaction), et les étapes (c) à (e) du procédé sont mises en œuvre. Sinon (pas d’authentification de l’individu nécessaire, par exemple car paiement simple sans contact) on passe directement à l’étape (f) de réception d’une notification de confirmation de la transaction si tout est bon (ou d’échec – voir avant). De manière particulièrement préférée, comme déjà évoqué, si ladite transaction est de type paiement par carte bancaire sans contact et ladite carte bancaire étant dématérialisée sur le terminal client 1 (i.e. la transaction est déclenchée en approchant le terminal client 1 du terminal marchand 2), un même canal radio en champ proche (NFC) est utilisé pour ledit déclenchement de la transaction et l’étape (c), de sorte que l’utilisateur se voie automatiquement demandé sur le terminal client 1 l’authentification. Terminaux Selon un troisième aspect, l’invention concerne le terminal client 1 pour la mise en œuvre du procédé selon le premier aspect (d’authentification). Ainsi, ce terminal 1 comprend comme expliqué au moins des moyens de traitement de données 11 et une mémoire 12, et avantageusement une caméra et/ou des moyens de communication en champ proche. Il s’agit typiquement d’un terminal mobile de type smartphone de l’individu à l’origine de la transaction (le porteur de la carte bancaire). Les moyens de traitement de données 11 sont configurés pour mettre en œuvre des étapes consistant à : Recevoir, lors d’une transaction sur un terminal marchand 2 également connecté via le réseau 20 au serveur de validation de transaction 3, une requête d’authentification dudit individu émise par le terminal marchand 2 via un canal de communication de proximité entre le terminal client 1 et le terminal marchand 2, ladite requête d’authentification dudit individu contenant une clé secrète dudit serveur 3 ; Etablir un canal de communication sécurisé entre le terminal client 1 et le serveur 3, dit second canal sécurisé, en utilisant ladite clé secrète dudit serveur 3 ; Transmettre des données d’authentification dudit individu au serveur 3, via ledit second canal sécurisé, en réponse à ladite requête d’authentification. Selon un quatrième aspect, l’invention propose un ensemble comprenant au moins un terminal client 1 selon le troisième aspect et le terminal marchand 2. Ce terminal 2 comprend également comme expliqué au moins des moyens de traitement de données 21 et une mémoire 22, et avantageusement des moyens d’affichage et/ou des moyens de communication en champ proche, potentiellement en outre un lecteur de carte. Il peut s’agir également d’un terminal mobile de type smartphone du marchand, ou de tout TPE. Les moyens de traitement de données 21 sont configurés pour mettre en œuvre des étapes consistant à : établir un canal de communication sécurisé entre le terminal marchand 2 et le serveur 3, dit premier canal sécurisé ; Récupérer depuis le serveur 3, via ledit premier canal sécurisé, ladite clé secrète du serveur 3. Ledit ensemble peut en outre comprendre ledit serveur de validation de transaction 3. Cet ensemble, et en particulier les moyens de traitement de données 11, 21 des terminaux 1, 2, sont avantageusement également pour la mise en œuvre du procédé selon le deuxième aspect (de mise en œuvre de la transaction), i.e. les moyens de traitement de données 21 du terminal marchand 2 sont également configurés pour autoriser le déclenchement de la transaction par un individu sur ledit terminal marchand 2. Produit programme d’ordinateur Selon un quatrième et un cinquième aspects, l’invention concerne un produit programme d’ordinateur comprenant des instructions de code pour l’exécution (sur les moyens de traitement de donnés 11, 21 des terminaux 1 et 2) d’un procédé selon le premier aspect d’authentification d’un individu pour la mise en œuvre d’une transaction sur un terminal marchand 2 connecté via un réseau 20 à un serveur de validation de transaction 3, ou d’un procédé selon le deuxième aspect de mise en œuvre d’une transaction sur un terminal marchand 2 connecté via un réseau 20 à un serveur de validation de transaction 3 ; ainsi que des moyens de stockage lisibles par un équipement informatique (par exemple les moyens de stockage de données 11, 22 des terminaux 1 et 2) sur lequel on trouve ce produit programme d’ordinateur. Procédé d’authentification d’un individu pour la mise en œuvre d’une transaction sur un terminal marchand (2) connecté via un réseau (20) à un serveur de validation de transaction (3), le procédé étant caractérisé en ce qu’il comprend la mise en œuvre, par des moyens de traitement de données (12) d’un terminal client (1) dudit individu également connecté au serveur (3) via ledit réseau (20), d’étapes de : (c) Réception d’une requête d’authentification dudit individu émise par ledit terminal marchand (2) via un canal de communication de proximité entre le terminal client (1) et le terminal marchand (2), ladite requête d’authentification dudit individu contenant une clé secrète dudit serveur (3) ; (d) Etablissement d’un canal de communication sécurisé entre le terminal client (1) et le serveur (3), dit second canal sécurisé, en utilisant ladite clé secrète dudit serveur (3) ; (e) Transmission de données d’authentification dudit individu au serveur (3), via ledit second canal sécurisé, en réponse à ladite requête d’authentification. Procédé selon la revendication 1, dans lequel ladite clé secrète du serveur (3) est chiffrée avec une clé de transport partagée entre le terminal client (1) et le serveur (3), l’étape (d) comprenant en outre le déchiffrement préalable de ladite clé secrète du serveur (3). Procédé selon la revendication 2, dans lequel les étapes (d) et (e) sont mises en œuvre au moyen d’une application installée sur ledit terminal client (1), ladite clé de transport étant enfouie dans le code de ladite application. Procédé selon la revendication 3, dans lequel l’étape (c) entraîne l’ouverture de ladite application si elle est déjà installée, et sinon son téléchargement depuis le réseau (20) puis son installation. Procédé selon l’une des revendications 1 à 4, dans lequel ladite requête d’authentification dudit individu contient en outre un jeton d’authentification, l’étape (e) comprenant la transmission du jeton signé avec la clé secrète du serveur (3). Procédé selon l’une des revendications 1 à 5, dans lequel ladite transaction est de type paiement par carte bancaire et la requête d’authentification est une requête de saisie d’un code PIN de carte bancaire sur une interface dudit terminal client (1) ; et lesdites données d’authentification sont des données dérivées dudit code PIN. Procédé selon l’une des revendications 1 à 6, dans lequel ledit canal de communication de proximité entre le terminal client (1) et le terminal marchand (2) n’est pas via le réseau (20). Procédé selon la revendication 7, dans lequel ledit canal de communication de proximité entre le terminal client (1) et le terminal marchand (2) est un canal optique ou un canal radio en champ proche. Procédé selon l’une des revendications 1 à 8, comprenant la mise en œuvre, par des moyens de traitement de données (21) du terminal marchand (2) d’étapes préalables de : (a) établissement d’un canal de communication sécurisé entre le terminal marchand (2) et le serveur (3), dit premier canal sécurisé ; (b) Récupération depuis le serveur (3), via ledit premier canal sécurisé, de ladite clé secrète du serveur (3). Procédé selon les revendications 5 et 9 en combinaison, dans lequel l’étape (b) comprend également la récupération depuis le serveur (3) du jeton d’authentification, et l’étape (e) comprend la vérification par des moyens de traitement de données (31) du serveur (3) dudit jeton signé. Procédé selon l’une des revendication 9 et 10, dans lequel l’étape (b) comprend la transmission au serveur (3) d’une requête de clé secrète pour le terminal client (1), la génération par des moyens de traitement de données (31) du serveur (3) de ladite clé secrète du serveur (3), et si nécessaire, d’un jeton d’authentification. Procédé de mise en œuvre d’une transaction sur un terminal marchand (2) connecté via un réseau (20) à un serveur de validation de transaction (3), comprenant le déclenchement de la transaction par un individu sur ledit terminal marchand (2) puis la mise en œuvre du procédé d’authentification dudit individu selon l’une des revendications 9 à 11, l’étape (b) comprenant en outre la transmission audit serveur (3) de données descriptives de ladite transaction. Terminal client (1) d’un individu, connecté via un réseau (20) à un serveur de validation de transaction (3), caractérisé en ce qu’il comprend des moyens de traitement de données (11) configurés pour : Recevoir, lors d’une transaction sur un terminal marchand (2) également connecté via le réseau (20) au serveur de validation de transaction (3), une requête d’authentification dudit individu émise par le terminal marchand (2) via un canal de communication de proximité entre le terminal client (1) et le terminal marchand (2), ladite requête d’authentification dudit individu contenant une clé secrète dudit serveur (3) ; Etablir un canal de communication sécurisé entre le terminal client (1) et le serveur (3), dit second canal sécurisé, en utilisant ladite clé secrète dudit serveur (3) ; Transmettre des données d’authentification dudit individu au serveur (3), via ledit second canal sécurisé, en réponse à ladite requête d’authentification. Ensemble d’au moins un terminal client (1) selon la revendication 13 et dudit terminal marchand (2), le terminal marchand (2) comprenant des moyens de traitement de données (21) configurés pour : établir un canal de communication sécurisé entre le terminal marchand (2) et le serveur (3), dit premier canal sécurisé ; Récupérer depuis le serveur (3), via ledit premier canal sécurisé, ladite clé secrète du serveur (3). Ensemble selon la revendication 14, comprenant en outre ledit serveur de validation de transaction (3). Produit programme d’ordinateur comprenant des instructions de code pour l’exécution d’un procédé selon l’une des revendications 1 à 11 d’authentification d’un individu pour la mise en œuvre d’une transaction sur un terminal marchand (2) connecté via un réseau (20) à un serveur de validation de transaction (3) ou d’un procédé selon la revendication 12 de mise en œuvre d’une transaction sur un terminal marchand (2) connecté via un réseau (20) à un serveur de validation de transaction (3), lorsque ledit programme est exécuté sur un ordinateur. Moyen de stockage lisible par un équipement informatique sur lequel est enregistré un produit programme d’ordinateur comprenant des instructions de code pour l’exécution d’un procédé selon l’une des revendications 1 à 11 d’authentification d’un individu pour la mise en œuvre d’une transaction sur un terminal marchand (2) connecté via un réseau (20) à un serveur de validation de transaction (3) ou d’un procédé selon la revendication 12 de mise en œuvre d’une transaction sur un terminal marchand (2) connecté via un réseau (20) à un serveur de validation de transaction (3).