FR 3067499 A1 20181214 FR 1755832 A 20170626 La présente invention se rapporte au domaine du paiement en ligne et des interfaces de paiement en ligne lors d'une transaction entre un utilisateur et un serveur de paiement sécurisé. De façon particulière, on s'intéressera aux applications mobiles d'achat, de paiement, de commerce conversationnel via par exemple des interfaces de messagerie instantanée, ou bien de façon plus classique via une connexion à des sites Web marchand. Lors d'une demande d'achat de produit ou de service entre un site marchand et un utilisateur d'un terminal, le site marchand fait appel à un site de paiement pour valider la transaction et récupérer le paiement. Pour cela, le site de paiement demande à l'utilisateur de s'authentifier avant de valider le paiement. Il s'agit, pour le site de paiement, de vérifier que l'utilisateur 15 est bien le possesseur du compte bancaire ou du compte de paiement. Lors de l'inscription de l'utilisateur sur le site de paiement (par exemple lors de la création d'un compte « Orange cash » ou d'un compte « Paypal »), 'Identité de l'utilisateur est vérifiée et est associée à un mot de passe ou un code de type code PIN (pour « Personnal Identification Number » en anglais) que l'utilisateur doit créer 20 à cette occasion. Lors du paiement, l'utilisateur est redirigé vers une interface du site de paiement et il doit prouver son identité par la saisie du mot de passe ou du code. Si le site de paiement est capable de s'assurer de l'authentification de l'utilisateur de la transaction, il n'en est pas de même pour l'utilisateur qui n'a pas de 25 moyen efficace pour s'assurer de la validité de l'interface de paiement qui lui est proposé. En effet, avant d'entrer son code PIN ou bien son mot de passe, il peut être utile de s'assurer que ces informations ne tomberont pas aux mains de faussaires malveillants. 30 A l'heure actuelle, une façon de vérifier que l'interface de paiement est valide, lorsque cette interface est ouverte sur un navigateur, est de vérifier que le protocole utilisé est bien un protocole sécurisé « https » certifiant la validité du nom du domaine sur lequel est hébergé l'interface de paiement. Cette information du nom de domaine est affichée sur l'interface et est associée à une illustration sous la forme 35 d'un cadenas fermé sur l'interface de navigation. 2 Cependant, il existe différentes possibilités de tromper l'utilisateur d'une telle interface. Cette illustration de cadenas n'est pas très visible et l'utilisateur ne remarque pas nécessairement qu'elle n'est pas présente. Dans le cas où l'utilisateur est dirigé vers un faux site de paiement, le 5 faussaire peut prévoir sur son interface falsifiée, l'illustration d'un même cadenas et ainsi tromper l'utilisateur qui ne sait pas nécessairement reconnaitre un nom de domaine valide d'un autre falsifié, surtout s'ils sont volontairement ressemblants. Dans le cas d'une interface mobile de paiement, la taille de l'écran étant limitée, il n'est pas toujours prévu d'afficher ce nom de domaine et cette certification 10 de nom de domaine. De plus, dans le cas de transactions initiées par des services de commerce conversationnel, via des interfaces de messagerie instantanée, par exemple, ces certifications Web ne sont pas prévues sur l'interface de paiement proposée à l'utilisateur. Celui-ci n'a donc pas de moyen de vérification de la validité de l'interface de paiement. Il existe donc un besoin, pour l'utilisateur d'une interface de paiement, lors d'une transaction, de vérifier la validité de l'interface de paiement avant de valider le paiement par l'entrée de ses données personnelles d'authentification. La présente invention vient améliorer la situation. Elle propose à cet effet, un procédé de contrôle de validité d'une interface de paiement à distance sur un terminal. Le procédé est tel que, lors d'une transaction de paiement entre un utilisateur et un site de paiement à distance, il comporte les étapes suivantes : - réception d'au moins une donnée historique de transaction entre l'utilisateur et le site de paiement ; - envoi d'un code de validation de la transaction dans le cas où la au moins un donnée historique est vérifiée comme étant valide. Ainsi, les données historiques de transaction de l'utilisateur avec le site de paiement permettent à l'utilisateur ou au terminal de l'utilisateur de s'assurer que le site de paiement est bien un site de paiement que l'utilisateur a déjà utilisé pour des transactions passées. Ce site de paiement n'est donc pas frauduleux et l'utilisateur peut alors insérer son code de validation de paiement en toute confiance. Les différents modes particuliers de réalisation mentionnés ci-après peuvent être ajoutés indépendamment ou en combinaison les uns avec les autres, aux étapes du procédé de contrôle défini ci-dessus. 3 Dans un mode de réalisation particulier, la au moins une donnée historique reçue est affichée sur une interface de paiement comprenant une demande de code de validation. Ainsi, juste avant de rentrer son code de validation de paiement, l'utilisateur 5 peut vérifier que les informations historiques sont valides. L'affichage sur une même interface de la demande de code et des données historiques assure l'utilisateur que c'est bien le même serveur qui envoie ces deux informations. Les données historiques affichées correspondent bien au site de paiement qui demande le code de validation. 10 De même, de façon à alerter l'utilisateur de l'importance des données affichées, l'affichage de la au moins une donnée historique est associé à l'affichage d'une information de mise en garde de l'utilisateur en cas de non validité de la au moins une donnée historique. Dans un mode de réalisation particulier, la au moins une donnée historique 15 est restituée vocalement à l'utilisateur via une interface vocale du terminal. Dans un mode de réalisation possible, la au moins une donnée historique comporte des données de date et de montant de la dernière transaction ou de plusieurs dernières transactions ou encore une adresse de livraison de l'utilisateur. Ces données permettent d'identifier de façon simple les transactions passées 20 ou le lien que le site de paiement a déjà eu avec l'utilisateur. Bien évidemment, toutes autres informations sur des transactions passées peuvent être retrouvées et obtenues par le terminal pour vérifier leur validité avant validation du paiement. Dans un mode de réalisation particulier, la vérification que la au moins une 25 donnée historique est valide, comprend une étape de comparaison de données de transactions mémorisées dans le terminal et d'affichage d'un message de validation de la vérification sur une interface de paiement. Cette étape est alors effectuée de façon automatique par le terminal qui contient en mémoire les données de transactions passées avec un ou plusieurs sites 30 de paiement. Le terminal recevant les données historiques peut alors comparer en fonction du site de paiement, si les informations reçues sont bien celles mémorisées et peut alors afficher un message à l'utilisateur confirmant la validité des informations reçues, afin que celui-ci puisse rentrer le code de validation de paiement en toute confiance. 4 Dans un autre mode de réalisation, la vérification que la au moins une donnée historique est valide est effectuée par l'utilisateur par la visualisation des données historiques affichées ou par l'écoute des données historiques restituées, avant une étape d'interaction avec l'interface de paiement pour entrer des données 5 de validation de la transaction. L'utilisateur doit alors se rappeler des dernières transactions qu'il a effectuées avec le site de paiement. S'il ne reconnait pas la ou les données historiques qui sont affichées alors il ne rentre pas le code de validation de paiement et la transaction échoue. 10 Corrélativement, l'invention vise également un procédé d'envoi de données de validation d'un site de paiement vers un terminal. Le procédé est tel que, lors d'une transaction de paiement entre l'utilisateur du terminal et le site de paiement, il comporte les étapes suivantes : - obtention de données historiques de transaction entre l'utilisateur et le 15 site de paiement ; - envoi d'au moins une donnée historique obtenue au terminal ; - attente de réception d'un code de validation de la transaction de l'utilisateur du terminal avant de valider le paiement, la réception du code de validation étant conditionnée à la vérification de validité de la au moins 20 une donnée historique envoyée. Le serveur de paiement retrouve ainsi les données historiques de transactions déjà passées entre lui et l'utilisateur qui souhaite valider le paiement. Par l'envoi de ces informations au terminal de l'utilisateur, il permet à celui-ci de vérifier que ce site n'est pas un site frauduleux. La transaction pourra ainsi être finalisée par la réception 25 du code de validation de l'utilisateur. Dans un mode de réalisation particulier, la au moins une donnée historique est envoyée avec une interface de paiement comportant une demande de code de validation de la transaction. L'envoi simultanée de l'interface de la demande de code et des données 30 historiques permet d'assurer l'utilisateur que c'est bien le même serveur qui envoie ces deux informations. Les données historiques envoyées au terminal de l'utilisateur correspondent donc bien au site de paiement qui demande le code de validation. A la réception de ces deux informations, l'utilisateur pourra vérifier la validité des données historiques et pourra saisir le code de validation du paiement. 5 L'invention vise un dispositif de contrôle de validité d'une interface de paiement à distance. Ce dispositif comporte un circuit de traitement comportant un processeur et étant apte à contrôler: - un module d'affichage d'une interface de transaction de paiement lors 5 d'une transaction de paiement entre un utilisateur et un site de paiement à distance ; - un module de communication apte à recevoir au moins une donnée historique de transaction entre l'utilisateur et le site de paiement et à envoyer un code de validation de la transaction via une interaction avec 10 l'interface de paiement, dans le cas où la au moins une donnée historique est vérifiée comme valide. L'invention se rapporte également à un terminal de communication comportant un dispositif tel que décrit. Le dispositif et le terminal ainsi décrits comportent les mêmes avantages que 15 le procédé de contrôle décrit qu'ils mettent en oeuvre. Corrélativement, l'invention vise un serveur d'un site de paiement. Ce serveur, comporte un circuit de traitement comportant un processeur et étant apte à contrôler lors d'une transaction de paiement entre un utilisateur et le site de paiement : 20 - une mémoire comportant des données historiques de transaction entre l'utilisateur et le site de paiement et un module d'obtention d'au moins une de ces données ; - un module de communication apte à envoyer au terminal la au moins une donnée historique obtenue et à recevoir un code de validation de 25 la transaction de l'utilisateur du terminal, la réception du code de validation étant conditionnée à la vérification de validité de la au moins donnée historique envoyée; - un module de validation du paiement après vérification du code de validation. 30 Le serveur ainsi décrit comporte les mêmes avantages que le procédé d'envoi de données de validation décrit qu'il met en oeuvre. L'invention vise un programme informatique comportant des instructions de code pour la mise en oeuvre des étapes du procédé de contrôle de validité d'une interface de paiement à distance tel que décrit précédemment ainsi qu'un 35 programme informatique comportant des instructions de code pour la mise en oeuvre 6 des étapes du procédé d'envoi de données de validation d'un site de paiement tel que décrit, lorsque ces instructions sont exécutées par un processeur. Enfin l'invention se rapporte à un support de stockage, lisible par un processeur, mémorisant un programme informatique mettant en oeuvre un procédé 5 de contrôle de validité d'une interface de paiement à distance tel que décrit précédemment, ainsi qu'un programme informatique mettant en oeuvre un procédé de d'envoi de données de validation d'un site de paiement tel que décrit précédemment. Le support de stockage peut être n'importe quelle entité ou dispositif capable 10 de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple un disque dur. D'autre part, le support de stockage peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par 15 radio ou par d'autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet. Alternativement, le support de stockage 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. 20 D'autres caractéristiques et avantages de l'invention apparaîtront plus clairement à la lecture de la description suivante, donnée uniquement à titre d'exemple non limitatif, et faite en référence aux dessins annexés, sur lesquels : la figure 1 illustre un système comportant notamment un terminal et un 25 serveur de paiement mettant en oeuvre l'invention dans un mode de réalisation ; la figure 2 illustre sous forme d'organigramme les principales étapes d'un mode de réalisation d'un procédé de contrôle de validité d'une interface de paiement mis en oeuvre par le terminal et d'un procédé d'envoi de 30 données de validation mis en oeuvre par un serveur de paiement ; les figures 3a, 3b et 3c illustrent des interfaces de paiement affichés sur un terminal dans des modes de réalisation particuliers de l'invention ; la figure 4 illustre schématiquement une représentation matérielle d'un terminal comportant un dispositif de contrôle de validité et mettant en 7 oeuvre un procédé de contrôle de validité selon un mode de réalisation de l'invention ; et la figure 5 illustre une représentation matérielle d'un serveur de paiement mettant en oeuvre un procédé d'envoi de données de validation selon un 5 mode de réalisation de l'invention. On se réfère tout d'abord à la figure 1 sur laquelle on a représenté un terminal de communication TA. Le terminal TA, ici représenté par un terminal mobile, comporte une interface de communication pour communiquer vers le réseau R où 10 sont représentés deux serveurs, un serveur marchand SM hébergeant un site marchand proposant à l'achat des produits ou services et un serveur de paiement apte à recevoir des ordres de paiement pour les produits ou services demandés et à valider ces paiements auprès des banques concernées ou plus généralement auprès d'un compte de paiement, le compte de paiement pouvant être hébergé chez un tiers 15 de paiement n'offrant pas nécessairement de service bancaires. Dans un mode particulier de réalisation, le serveur marchand et le serveur de paiement peuvent être confondus. Le réseau R est un réseau de communication, par exemple de type IMS, qui permet l'établissement de communications entre des terminaux et des serveurs tels 20 que représenté ici. Le terminal TA peut communiquer vers les serveurs SM ou SP via un service de commerce conversationnel basé sur une application de messagerie instantanée enrichie, installée sur le terminal et qui permet d'échanger avec un robot adapté au site marchand, par exemple, pour commander des biens ou des services. Les utilisateurs de telles applications de messagerie instantanée enrichie, n'ont alors 25 plus besoin de télécharger des applications dédiées à chaque site marchand ou d'accéder à leur site Web pour passer commande. Des boutons d'actions ou des liens hypertextes peuvent également être prévus sur l'interface de commerce conversationnel pour déclencher une action d'achat ou bien de consultation de pages web. 30 L'invention n'est pas limitée au cadre des réseaux IMS. Le réseau de communication R peut être un réseau de télécommunication GSM (Global System for Mobile communication) permettant l'établissement de communications vocales et l'échange de messages textuels par le biais de SMS (short Message Service) par exemple. Le réseau R est par exemple aussi le réseau internet auquel le terminal TA 8 peut se connecter pour échanger des données et accéder, entre autre, aux pages web du site marchand et effectuer ses commandes. Le réseau R peut également correspondre à plusieurs réseaux distincts et interconnectés à partir desquels les serveurs SM et SP sont accessibles. Par exemple, 5 le terminal TA peut établir des communications vocales par l'intermédiaire d'un réseau fixe commuté ou un réseau cellulaire et des communications textuelles ou échange de données via un réseau d'accès WiFi, 2G, 3G ou 4G. Le terminal TA est ici un téléphone mobile de type « smartphone » disposant de moyens de communications adaptés pour se connecter à un ou plusieurs réseaux 10 de communication, tels que des réseaux Wifi ou des réseaux cellulaires, ainsi que d'une mémoire et d'un processeur adaptés pour exécuter des instructions de programme d'ordinateur. L'invention décrite ci-après peut toutefois être mise en oeuvre sur d'autres terminaux, tels que sur une tablette, un objet connecté, un tableau de bord de véhicule ou encore un ordinateur personnel. Le terminal TA est 15 par exemple adapté pour communiquer selon au moins un protocole de messagerie instantanée avec d'autres terminaux ou dispositifs. Par exemple, le terminal TA peut émettre et recevoir des messages de type SMS (Short Message Service) par l'intermédiaire d'un réseau cellulaire, ou encore mettre en oeuvre le standard RCS (Rich Communication Suite), le protocole SIP SIMPLE, Jabber ou tout autre protocole 20 adapté pour envoyer et recevoir des messages. En particulier, le terminal TA peut échanger des messages instantanés avec le serveur SM au travers du réseau R. La figure 2 représente les étapes (E20 à E23) d'un procédé de contrôle de validité d'une interface de paiement mises en oeuvre dans le terminal TA, dans un mode de réalisation, ainsi que les étapes (E27 à E33) d'un procédé d'envoi de 25 données de validation d'un site de paiement mises en oeuvre, par exemple, dans un serveur de paiement SP. La figure 2 représente aussi les étapes mises en oeuvre sur un serveur marchand SM proposant des produits ou services à l'utilisateur du terminal TA. Ce serveur marchand peut être également un agent (ou robot) conversationnel 30 permettant de proposer à l'utilisateur des biens ou services de différents marchands par l'intermédiaire d'une messagerie instantanée. Dans un mode possible de réalisation, le serveur marchand et le serveur de paiement peuvent être un seul et même serveur. A l'étape E20, l'utilisateur du terminal TA, après consultation d'un site Web 35 du site marchand ou bien après échange d'une conversation par messagerie 9 instantanée proposant l'achat de service ou de produit, décide de valider une commande en validant la création d'un panier par exemple. Il effectue en E20 une commande, qu'il transmet au serveur SM pour qu'il la valide et déclenche l'envoi d'un ordre de paiement. Le serveur du site marchand, SM, 5 reçoit cette commande en E24 et transmet l'ordre de paiement à un serveur de paiement SP pour que celui-ci interagisse avec l'utilisateur du terminal TA pour valider le paiement. Le serveur de paiement reçoit cet ordre de paiement en E27. Dans une variante de réalisation de ces étapes d'échange, par exemple pour 10 une application de commerce conversationnel installée sur le terminal TA, lors de la validation d'une commande par l'utilisateur du terminal, celui-ci peut recevoir, en provenance de l'agent conversationnel du serveur SM, un lien ou bouton d'action qui lui permet de payer et le met en relation directement avec le serveur de paiement. Ce bouton d'action, lorsque l'utilisateur du terminal l'actionne, met en oeuvre une 15 application permettant d'échanger les identifiants à la fois de l'utilisateur du terminal TA et du site marchand ainsi que les informations sur la transaction demandée pour la commande en cours. Le serveur de paiement, SP, recevant cet ordre de paiement en E27, consulte une base de donnée interne ou externe dans laquelle sont stockées des informations 20 des dernières transactions réalisées en correspondance avec un identifiant de l'émetteur de la commande. A l'étape E28, le serveur de paiement consulte donc dans sa base de données et obtient les données de transaction passées correspondant à l'identifiant de l'utilisateur qui a émis la commande pour cet ordre de paiement. 25 Il envoie au moins une de ces données historiques au terminal TA (étape E29). Ces données historiques sont par exemple, la date et le montant du dernier ou bien des 2 ou 3 derniers paiements que l'utilisateur a effectués sur ce site de paiement. Il peut y voir également le nom du site marchand correspondant. 30 Une autre donnée peut être l'adresse de livraison utilisée pour les derniers achats et transactions effectués par cet utilisateur. Toute information liée à l'utilisateur et aux dernières transactions peut être ainsi retrouvée et envoyée au terminal pour validation. Ces données historiques sont des données multimédia, elles peuvent être 35 sous la forme de texte, d'image ou de son et toujours relatives à l'utilisateur. 10 Bien entendu, les données historiques de transaction ainsi décrites, n'existent que si l'utilisateur a déjà effectué un paiement via ce site de paiement. Dans le cas où aucune transaction passée n'a été effectuée avec le serveur de paiement, une donnée personnelle de l'utilisateur peut alors être envoyée comme 5 donnée historique. Cette donnée personnelle a par exemple été enregistrée sur le serveur lorsque l'utilisateur a créé son compte auprès du serveur de paiement. Il peut s'agir d'une réponse à une question personnelle ou bien une information personnelle sur son identité. En E21, le terminal TA reçoit ces données historiques des transactions 10 passées avec le site de paiement. Ces données historiques sont, dans un mode de réalisation, affichées sur l'interface de paiement et sur l'écran du terminal. Dans un autre mode de réalisation, elles sont restituées vocalement à l'utilisateur via une interface vocale du terminal. 15 Elles peuvent être affichées ou restituées simultanément avec une demande d'entrée d'un code de validation du paiement sur l'interface de paiement. Ainsi, juste avant de rentrer son code de validation de paiement, l'utilisateur peut vérifier que les informations historiques sont valides. L'affichage sur une même interface de la demande de code et des données historiques assure l'utilisateur que 20 c'est bien le même serveur qui envoie ces deux informations. Les données historiques affichées correspondent bien au site de paiement qui demande le code de validation. Dans un mode de réalisation particulier, et de façon à alerter l'utilisateur de l'importance des données affichées, l'affichage des données historiques est associé à 25 l'affichage d'une information de mise en garde de l'utilisateur en cas de non validité de ces données historiques. Une étape E22 de vérification de la validité de ces données est effectuée. Cette étape est, dans un mode de réalisation possible, effectuée par l'utilisateur lui-même, par la visualisation sur l'interface de paiement des données historiques de 30 transactions affichées ou par l'écoute des données historiques restituées. L'utilisateur s'assure alors que le site de paiement est bien un site de paiement que l'utilisateur a déjà utilisé pour des transactions passées. Ce site de paiement n'est donc pas frauduleux et l'utilisateur peut alors insérer son code de validation de paiement en toute confiance en interagissant avec l'interface de paiement pour entrer ses 35 données de validation de la transaction. 11 Dans un autre mode de réalisation, l'utilisateur peut demander au serveur de paiement une autre information historique en réponse à ce premier envoi, dans le cas où il n'est pas sûr de pouvoir valider ces premières données. L'interface peut ainsi prévoir un bouton d'action déclenchant la demande 5 d'une autre donnée au serveur. Le serveur de paiement récupère ainsi au moins une autre donnée historique qui concerne l'utilisateur et effectue un deuxième envoi de ces données à l'utilisateur. Un nombre limité de demandes successives peut être prévu. Passé ce 10 nombre, la transaction est automatiquement annulée. Lorsque les données de validation ont été entrées, elles sont ensuite envoyées au serveur de paiement SP à l'étape E23. Dans un autre mode de réalisation, l'étape E22 de vérification, que les données historiques sont valides, comprend une étape de comparaison de données 15 de transactions mémorisées dans le terminal et d'affichage d'un message de validation de la vérification sur l'interface de paiement. Ces étapes sont effectuées alors par le terminal lui-même qui a enregistré en mémoire les dernières données de transaction et qui peut ainsi les comparer avec les données historiques reçues. Pour cela, le terminal met en oeuvre cette étape via par 20 exemple son système d'exploitation interne ou bien dans un mode de réalisation particulier et dans le cas de la mise en oeuvre de commerce conversationnel, via la plateforme logicielle de messagerie instantanée. Cette comparaison est effectuée avant l'affichage de demande de code de validation sur l'interface de paiement. Cet affichage est alors accompagné d'un 25 message confirmant que le terminal a bien vérifié les données historiques qu'il a reçues. L'utilisateur peut alors en toute confiance, saisir son code de validation. Dans le cas où les données historiques sont considérées comme non valides, alors la transaction échoue, l'utilisateur ne rentrant pas son code de validation. Lorsque le serveur de paiement reçoit le code de validation en E30, il vérifie 30 en E31 que ce code de validation correspond bien aux données d'authentification de l'utilisateur pour cette commande et valide la transaction lorsque cette vérification est positive. Dans le cas contraire, la transaction échoue. Une information de validation du paiement peut alors être envoyée en E33 au serveur marchand SM qui la reçoit en E26 pour ensuite délivrer la commande de 35 l'utilisateur. 12 Un exemple d'interface de paiement reçue sur le terminal TA est illustré aux figures 3a à 3c. La figure 3a montre une interface de paiement auprès d'un serveur de paiement « Orange Cash », affichée sur le terminal d'un utilisateur qui a effectué une commande auprès d'un marchand M3 dont l'adresse est affichée. Le numéro de 5 commande est également affiché ainsi que le montant associé. Le compte de l'utilisateur qui va permettre d'effectuer le paiement est aussi affiché. Pour effectuer le paiement, l'utilisateur actionne le bouton « payer » sur cette interface. S'il annule cette commande, il actionne le bouton « annuler ». L'action sur le bouton « payer » permet le déclenchement du procédé de 10 contrôle de validité de l'interface de paiement sur le terminal ainsi que la mise en oeuvre du procédé correspondant d'envoi de données de validation sur le serveur de paiement. Le serveur de paiement consulte sa base de données pour retrouver les dernières données de transactions que l'utilisateur a eues avec ce site de paiement. 15 Ces données sont envoyées au terminal qui les affiche selon un exemple illustré en figure 3b. On voit en effet que les deux dernières transactions sont affichées, une première ayant été effectuée le 25.05.2017 chez le marchand M1 pour un montant de 10,87E et la deuxième ayant été effectuée le 03.06.2017 chez le marchand M2 20 pour un montant de 53E. Ces données peuvent être accompagnées d'un premier message explicatif (MESS 1) du type « Vérifiez que vous pouvez valider les informations ci-dessous avant de valider le paiement ». Un message de mise en garde peut également être affiché (MESS 2) du type 25 « Si ces informations ne sont pas les vôtres ou ne vous correspondent pas, NE SAISISSEZ PAS VOTRE CODE PIN ». La saisie du code PIN en question peut alors se faire dans les carrés prévus à cet effet sur l'interface. Avec cette interface, c'est à l'utilisateur lui-même d'effectuer la vérification 30 des données historiques. Il doit se rappeler des dernières données de transactions qu'il a effectuées avec ce site de paiement pour entrer son code PIN et ainsi valider le paiement. Dans un autre mode de réalisation où la vérification de la validité des données historiques envoyées est effectuée de façon automatique par le terminal, 35 l'interface de paiement peut être un peu différente comme illustrée à la figure 3c. 13 Ici, un message MESS 3 peut informer que le terminal a bien effectué sa vérification. Ce message peut être du type « Les données historiques des dernières transactions reçues et affichées ci-dessous ont bien été validées ». Et un message «MESS 4 » peut confirmer que l'utilisateur peut entrer son 5 code PIN en toute confiance. Ce message peut être du type « Le site de paiement est valide, vous pouvez entrer votre code PIN en toute confiance ». Les données historiques peuvent ne pas être affichées dans ce mode de réalisation puisque c'est le terminal qui effectue la vérification avec les données qu'il a en mémoire. Dans ce cas, le message MESS 3 ne comporte pas les mots « et 10 affichées ci-dessous ». Si les données sont également affichées, comme illustré en figure 3c, alors une double vérification peut être effectuée, par le terminal et par l'utilisateur avant qu'il n'entre le code PIN demandé. Dans une variante de réalisation, les interfaces visuelles ainsi représentées 15 peuvent être transformées en interfaces vocales. Les données historiques reçues sont ainsi vocalisées ainsi que les messages les accompagnant. De même, l'interface de paiement peut être une interface vocale dans laquelle il est demandé à l'utilisateur d'entrer vocalement son code de validation de paiement après qu'il ait vérifié les données historiques. 20 De la même façon, ces interfaces peuvent être constituées d'une partie vocale, par exemple les données historiques reçues et restituée vocalement et d'une partie visuelle, par exemple l'interface de paiement, l'entrée du code de validation par l'utilisateur s'effectuant alors par un clavier tactile ou non du terminal. La figure 4 illustre à présent une représentation matérielle d'un dispositif de 25 contrôle de validité d'une interface de paiement à distance TA selon un mode de réalisation de l'invention. Ce dispositif peut être intégré à un terminal de communication par exemple terminal de communication mobile, de type « smartphone », ordinateur, tablette, objet connecté ou autre équipement. Ce dispositif met en oeuvre le procédé de contrôle de validité d'une interface 30 de paiement décrit en référence à la figure 2 par les étapes principales E20 à E23. Matériellement, ce dispositif TA comporte un circuit de traitement 42 comportant un processeur et coopérant avec un bloc mémoire BM comportant une mémoire de stockage et/ou de travail MEM. Le processeur pilote des modules de traitement aptes à mettre en oeuvre le 35 procédé de contrôle de validité décrit en référence à la figure 2. 14 Le terme module peut correspondre aussi bien à un composant logiciel qu'à un composant matériel ou un ensemble de composants matériels et logiciels, un composant logiciel correspondant lui-même à un ou plusieurs programmes ou sous-programmes d'ordinateur ou de manière plus générale à tout élément d'un 5 programme apte à mettre en oeuvre une fonction ou un ensemble de fonctions telles que décrites pour les modules concernés. De la même manière, un composant matériel correspond à tout élément d'un ensemble matériel (ou hardware) apte à mettre en oeuvre une fonction ou un ensemble de fonctions pour le module concerné (circuit intégré, carte à puce, carte à mémoire, etc.) 10 Le bloc mémoire peut avantageusement comporter un programme informatique (prog1.) comportant des instructions de code pour la mise en oeuvre des étapes du procédé de contrôle de validité d'une interface de paiement à distance au sens de l'invention, lorsque ces instructions sont exécutées par le processeur PROC et notamment, lors d'une transaction de paiement entre un utilisateur et un 15 site de paiement à distance, les étapes de réception d'au moins une donnée historique de transaction entre l'utilisateur et le site de paiement et d'envoi d'un code de validation de la transaction dans le cas où la au moins un donnée historique est vérifiée comme étant valide. Ce programme peut utiliser n'importe quel langage de programmation, et être 20 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. À l'initialisation, les instructions du programme d'ordinateur (prog.1) sont par exemple chargées dans une mémoire RAM (Randonn Access Memory en anglais) 25 avant d'être exécutées par le processeur de l'unité de traitement 42. Le processeur de l'unité de traitement 42 met en oeuvre les étapes du procédé de contrôle tel que décrit selon les instructions du programme d'ordinateur. Typiquement, la description de la figure 2 reprend les étapes d'un algorithme d'un tel programme informatique. Le programme informatique peut également être 30 stocké sur un support mémoire lisible par un lecteur du dispositif ou téléchargeable dans l'espace mémoire de celui-ci. La mémoire MEM enregistre de manière générale, toutes les données nécessaires à la mise en oeuvre du procédé de contrôle et notamment, dans un mode de réalisation du procédé de contrôle, des données concernant les dernières 35 transactions passées en correspondance avec les sites de paiement concernés. 15 Le dispositif possède également un écran 43 apte à afficher les interfaces de commande et les interfaces de transaction de paiement. L'écran est ainsi apte à afficher les données historiques de transaction reçues d'un serveur de paiement et d'afficher simultanément une demande de saisie de code de validation de paiement. 5 Des exemples de telles interfaces sont illustrés en référence aux figures 3a à 3c. Le dispositif comporte également une interface utilisateur 44 (par exemple une interface tactile sur l'écran ou bien une interface de type clavier physique) permettant à l'utilisateur d'interagir lors d'une commande ou d'un paiement, par 10 exemple en saisissant un code de validation de paiement dans le cas où les données historiques de transaction ont été vérifiées comme valides. L'interface utilisateur 44 peut également, dans un mode de réalisation, être une interface vocale qui traduit les messages reçus et en particulier les données historiques reçues, en message vocaux via des moyens de restitution vocale de type 15 haut-parleurs non représentés ici. De même, cette interface vocale permet de recevoir des messages vocaux de l'utilisateur via des moyens de captation du son tels que des microphones non représentés ici. Le dispositif TA comprend aussi un module de communication apte à recevoir 20 une ou plusieurs données historiques de transaction entre l'utilisateur et le site de paiement et à envoyer un code de validation de la transaction via une interaction avec l'interface utilisateur 44 et l'interface de paiement affichée, dans le cas où les données historiques de transaction ont été vérifiées comme valides. Ce module de communication 41 est par exemple une interface réseau COM 25 (par exemple une interface WiFi, 3G, 4G ou ethernet), permettant au dispositif de se connecter à un réseau de télécommunication R et d'échanger des données avec d'autres dispositifs ou des serveurs de type serveur marchand et serveur de paiement, par l'intermédiaire du réseau de télécommunications. Ce module de communication permet en particulier d'échanger des messages avec un agent 30 conversationnel dans le cas d'une mise en oeuvre par commerce conversationnel. La figure 5 illustre à présent une représentation matérielle d'un dispositif SP d'envoi de données de validation d'un site de paiement selon un mode de réalisation de l'invention. Ce dispositif peut être intégré à un serveur de paiement dans un réseau de communication. 16 Ce dispositif met en oeuvre le procédé d'envoi de données de validation d'un site de paiement décrit en référence à la figure 2 par les étapes principales E27 à E33. Il possède un module de communication 51 permettant de communiquer avec 5 d'autres équipements du réseau de communication, par exemple avec le terminal TA. Le module de communication 51 peut être par exemple une interface réseau WiFi, 3G, 4G ou encore une interface Ethernet et permet au dispositif de transmettre des messages vers le terminal TA ou vers un autre serveur du réseau, par exemple un serveur marchand SM. Il permet d'envoyer des données historiques de 10 transaction au terminal et d'envoyer des interfaces de paiement pour recevoir en retour des données de validation de paiement. Matériellement, ce dispositif SP comporte un circuit de traitement 52 comportant un processeur et coopérant avec un bloc mémoire BM comportant une mémoire de stockage et/ou de travail MEM. 15 Le processeur pilote des modules de traitement aptes à mettre en oeuvre le procédé d'envoi de données de validation selon l'invention. Ainsi, ce dispositif comporte une mémoire comportant des données historiques de transaction entre l'utilisateur et le site de paiement. Cette mémoire peut être sous la forme d'une base de données 55 interne au serveur ou bien externe à celui-ci. Le module de 20 traitement faisant alors appel à cette base de données par l'intermédiaire du module de communication 51. Le dispositif ou serveur SP comporte un module 54 d'obtention d'au moins une de ces données, piloté par le circuit de traitement et apte à lire dans la base de données ces données historiques mémorisées en correspondance avec des 25 identifiants d'utilisateur. Le module de communication 51 est apte à envoyer au terminal TA, les données historiques obtenues et à recevoir un code de validation de la transaction de l'utilisateur du terminal, la réception du code de validation étant conditionnée à la vérification de validité des données historiques envoyées. 30 Le dispositif SP comporte un module 53 de validation du paiement après vérification du code de validation selon des données d'authentification de l'utilisateur qu'il possède en mémoire MEM ou dans la base de données 55. Le bloc mémoire peut avantageusement comporter un programme informatique (prog2.) comportant des instructions de code pour la mise en oeuvre 35 des étapes du procédé d'envoi de données de validation d'un site de paiement vers 17 un terminal, lorsque ces instructions sont exécutées par le processeur PROC du module de traitement 52 et notamment, lors d'une transaction de paiement entre l'utilisateur du terminal et le site de paiement, les étapes d'obtention de données historiques de transaction entre l'utilisateur et le site de paiement, d'envoi d'au moins 5 une donnée historique obtenue au terminal, d'attente de réception d'un code de validation de la transaction de l'utilisateur du terminal avant de valider le paiement, la réception du code de validation étant conditionnée à la vérification de validité de la au moins une donnée historique envoyée. Ce programme peut utiliser n'importe quel langage de programmation, et être 10 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. À l'initialisation, les instructions du programme d'ordinateur (prog.2) sont par exemple chargées dans une mémoire RAM (Random Access Memory en anglais) 15 avant d'être exécutées par le processeur de l'unité de traitement 52. Le processeur de l'unité de traitement 52 met en oeuvre les étapes du procédé d'envoi de données de validation tel que décrit selon les instructions du programme d'ordinateur. Typiquement, la description de la figure 2 reprend les étapes d'un algorithme d'un tel programme informatique. Le programme informatique peut également être 20 stocké sur un support mémoire lisible par un lecteur du dispositif ou téléchargeable dans l'espace mémoire de celui-ci. La mémoire MEM enregistre de manière générale, toutes les données nécessaires à la mise en oeuvre du procédé d'envoi REVENDICATIONS1. Procédé de contrôle de validité d'une interface de paiement à distance sur un terminal, caractérisé en ce que, lors d'une transaction de paiement entre un utilisateur et un site de paiement à distance, le procédé comporte les étapes suivantes : - réception (E21) d'au moins une donnée historique de transaction entre l'utilisateur et le site de paiement ; - envoi (E23) d'un code de validation de la transaction dans le cas où la au moins un donnée historique est vérifiée (E22) comme étant valide. 2. Procédé selon la revendication 1, dans lequel la au moins une donnée historique reçue est affichée sur une interface de paiement comprenant une demande de code de validation. 3. Procédé selon la revendication 2, dans lequel l'affichage de la au moins une donnée historique est associé à l'affichage d'une information de mise en garde de l'utilisateur en cas de non validité de la au moins une donnée historique. 4. Procédé selon la revendication 1, dans lequel la au moins une donnée historique est restituée vocalement à l'utilisateur via une interface vocale du terminal. 5. Procédé selon l'une des revendications 1 à 4, dans lequel la au moins une donnée historique comporte des données de date et de montant de la dernière transaction ou de plusieurs dernières transactions. 6. Procédé selon l'une des revendications 1 à 5, dans lequel une donnée de transaction est une adresse de livraison de l'utilisateur. 7. Procédé selon l'une des revendications 1 à 6, dans lequel la vérification que la au moins une donnée historique est valide, comprend une étape de comparaison de données de transactions mémorisées dans le terminal et 19 d'affichage d'un message de validation de la vérification sur une interface de paiement. 8. Procédé selon l'une des revendications 2 à 6, dans lequel la vérification 5 que la au moins une donnée historique est valide est effectuée par l'utilisateur par la visualisation des données historiques affichées ou par l'écoute des données historiques restituées, avant une étape d'interaction avec l'interface de paiement pour entrer des données de validation de la transaction. 10 9. Procédé d'envoi de données de validation d'un site de paiement vers un terminal, caractérisé en ce que, lors d'une transaction de paiement entre l'utilisateur du terminal et le site de paiement, le procédé comporte les étapes suivantes : 15 - obtention (E28) de données historiques de transaction entre l'utilisateur et le site de paiement ; - envoi (E29) d'au moins une donnée historique obtenue au terminal ; - attente de réception (E30) d'un code de validation de la transaction de l'utilisateur du terminal avant de valider (E32) le paiement, la réception du 20 code de validation étant conditionnée à la vérification de validité de la au moins une donnée historique envoyée. 10. Procédé selon la revendication 8, dans lequel la au moins une donnée historique est envoyée avec une interface de paiement comportant une 25 demande de code de validation de la transaction. 11. Dispositif de contrôle de validité d'une interface de paiement à distance, caractérisé en ce qu'il comporte un circuit de traitement (42) comportant un processeur et étant apte à contrôler: 30 - un module d'affichage (43) d'une interface de transaction de paiement lors d'une transaction de paiement entre un utilisateur et un site de paiement à distance ; - un module de communication (41) apte à-recevoir au moins une donnée historique de transaction entre l'utilisateur et le site de paiement et à 35 envoyer un code de validation de la transaction via une interaction avec 20 l'interface de paiement, dans le cas où la au moins un donnée historique est vérifiée comme étant valide. 12. Terminal de communication comportant un dispositif selon la 5 revendication 11. 13. Serveur d'un site de paiement, caractérisé en ce qu'il comporte un circuit de traitement comportant un processeur et étant apte à contrôler lors d'une transaction de paiement entre un utilisateur et le site de paiement : 10 - une mémoire (55) comportant des données historiques de transaction entre l'utilisateur et le site de paiement et un module d'obtention (54) d'au moins une de ces données ; - un module de communication (51) apte à envoyer au terminal la au moins une donnée historique obtenue et à recevoir un code de validation 15 de la transaction de l'utilisateur du terminal, la réception du code de validation étant conditionnée à la vérification de validité de la au moins donnée historique envoyée; - un module de validation (53) du paiement après vérification du code de validation. 20 14. Programme informatique comportant des instructions de code pour la mise en oeuvre des étapes du procédé de contrôle de validité d'une interface de paiement à distance selon l'une des revendications 1 à 8 et/ou du procédé d'envoi de données de validation d'un site de paiement 25 selon l'une des revendications 9 à 10, lorsque ces instructions sont exécutées par un processeur. 15. Support de stockage, lisible par un processeur, sur lequel est enregistré un programme informatique comportant des instructions de code pour 30 l'exécution des étapes du procédé de contrôle de validité d'une interface de paiement à distance selon l'une des revendications 1 à 8 et/ou du procédé d'envoi de données de validation d'un site de paiement selon l'une des revendications 9 à 10. 35