Brevet FR3052284A1 — publié le 20171208

Contrôle perfectionné d'une requête de transaction à partir d'un dispositif à bouton-poussoir La présente invention concerne le contrôle d'une transaction opérée à partir d'un simple bouton de commande tel qu'illustré sur la figure 6. Il s'agit d'un dispositif, à bouton poussoir unique 10 (figure 1), sans autre interface plus sophistiquée. Ce dispositif DIS comporte en outre des moyens de communication COM via un réseau, à destination d'une plateforme notamment pour la commande d'un bien (par exemple un produit (objet à acheter en ligne) ou un service (places de théâtre ou de concert, selon un abonnement prédéfini, ou autre). Ainsi, un actionnement de ce bouton par un utilisateur provoque l'émission d'un message à destination de la plateforme de transaction, ce message comportant un identifiant ID1 du dispositif. À partir de cet identifiant ID1, un serveur SER connecté à la plate-forme détermine le type de bien à fournir, ainsi que l'utilisateur qui doit recevoir ce bien. 15 Plus particulièrement, en référence à la figure 1, le dispositif DIS comporte un processeur 11 coopérant avec une mémoire 12, ainsi qu'avec une interface de communication COM. Le processeur est relié en outre à une interface INT connectée au bouton-poussoir 10, pour recevoir notamment des ordres de commande, et, de là, mettre en forme un message de commande comportant l'identifiant ID1 20 du dispositif (stocké préalablement dans la mémoire 12, par exemple). Ainsi, un appui sur le bouton-poussoir 10 provoque l'envoi d'une requête de transaction pour une commande auprès du serveur SER. Cette requête est transmise via le réseau NET (flèche F1). Il peut s'agir d'une communication via un réseau de type LoRa®, Sigfox®, ou encore via un réseau Wifi 25 (communautaire par exemple), ou autre. Le message de commande (flèche Fl) transite via le réseau NET (et éventuellement via la plateforme de transaction) jusqu'au serveur SER, et comporte l'identifiant du dispositif ID1. 30 Le serveur SER gère une base de données d'identifiants ID1, ID2, etc., de dispositifs de commande stockés chacun en correspondance de données relatives à l'utilisateur du dispositif référencé dans la base (US1). Ces données peuvent comporter : - un identifiant de bien à livrer, associé au dispositif (le dispositif étant, dans une réalisation, configuré pour la commande d'un unique type de bien, par exemple un nouveau pack d'une même boisson, ou 35 une nouvelle place dans un même théâtre le premier samedi du mois à 20 heures, ou autre), - une adresse de livraison du bien (l'adresse physique de l'utilisateur, ou l'adresse virtuelle d'un terminal SM à sa disposition), 10 3052284 2 - des coordonnées bancaires de facturation de la transaction, - des coordonnées de contact d'un terminal SM à disposition de l'utilisateur pour vérifier que l'utilisateur n'infirme pas la commande après une temporisation choisie. 5 Ces données relatives à l'utilisateur sont stockées dans la base de données du serveur, préalablement au cours d'une étape d'initialisation. Par exemple, un appui long sur le bouton-poussoir 10 provoque l'établissement d'une communication courte portée (Bluetooth par exemple) avec le terminal SM de l'utilisateur (par exemple de type Smartphone), comme illustré sur la figure 1 par la flèche F2. Le dispositif DIS transmet au terminal son identifiant ID1 et une interface homme-machine IHM s'anime sur le terminal SM, pour demander à l'utilisateur par exemple le type de bien PDT1 qu'il souhaite recevoir régulièrement, son adresse personnelle ADR1 pour la livraison de ce bien, ses coordonnées bancaires, etc. Le terminal SM envoie ces données ADR1 au serveur SER (flèche F3), avec : - ses coordonnées de contact SM1, et - avec l'identifiant ID1 qu'il a reçu du dispositif DIS. Le serveur SER, sur réception de l'identifiant ID1 du dispositif avec ces données, stocke alors l'identifiant ID1, en correspondance : - du type de bien PDT1 à livrer pour de futures transactions, sur réception d'une requête comportant l'identifiant ID1, - d'une adresse de livraison ADR1 de ce bien, et - des coordonnées d'un terminal SM1, à contacter préalablement et attendre une annulation de la commande pendant une durée de temporisation choisie. En effet, l'utilisateur dispose d'un certain délai pour éventuellement annuler sa commande. Toutefois, dans une telle réalisation, dans le cas où le dispositif est dérobé à son utilisateur habituel, un utilisateur malveillant peut appuyer plusieurs fois sur le bouton du dispositif, déclencher une multitude de commandes, sans que l'utilisateur puisse réagir à temps. La présente invention vient améliorer la situation. Elle propose à cet effet un procédé mis en oeuvre par des moyens informatiques pour contrôler une transaction de biens sur une plateforme de transaction en ligne. En particulier, dans cette transaction, un dispositif connecté, actionnable par un utilisateur, émet, sur commande de l'utilisateur, une requête de transaction comprenant un identifiant du dispositif connecté, via un réseau de communication. Ainsi, le procédé, mis en oeuvre par un serveur de la plateforme de transaction, comprend : 3052284 3 - une étape initiale d'élaboration d'une base de données mettant en correspondance : * d'une part, un identifiant de dispositif connecté, et, * d'autre part, un identifiant de bien, * ainsi qu'un identifiant d'utilisateur apte à commander ce bien en opérant ladite transaction 5 via ce dispositif connecté, - et des étapes courantes de : - réception via le réseau de communication d'une requête de transaction comprenant un identifiant de dispositif connecté, et - de traitement de la requête reçue en retrouvant, le cas échéant, en fonction de l'identifiant de 10 dispositif connecté dans la requête, l'utilisateur de ce dispositif connecté et le bien à délivrer à cet utilisateur. En particulier selon l'invention, le dispositif connecté est apte à communiquer avec un réseau local avec une adresse MAC propre au dispositif connecté. La base de données répertorie en outre une 15 adresse MAC propre à un dispositif connecté en correspondance de l'identifiant de ce dispositif connecté. Le serveur reçoit en outre une première adresse MAC de dispositif connecté, avec une requête de transaction issue de ce dispositif connecté, et vérifie dans la base de données une correspondance, en outre, entre : * ladite première adresse MAC, et 20 * une deuxième adresse MAC, associée dans la base de données à l'identifiant du dispositif connecté que comprend la requête de transaction. Ainsi, l'adresse MAC est ici un moyen supplémentaire pour contrôler la requête de transaction. Comme le dispositif connecté est destiné à rester dans un environnement local dans lequel des 25 équipements peuvent être connectés à un réseau local relié à une passerelle domestique par exemple, si l'adresse MAC qui est reçue avec la requête ne correspond pas à celle préenregistrée en correspondance de l'identifiant du dispositif connecté, c'est alors que l'identifiant est erroné ou que le dispositif a été déplacé sans mettre en oeuvre une étape de mise à jour faisant intervenir un terminal contrôlé par l'utilisateur présumé du dispositif (comme décrit en détails plus loin en référence à la 30 figure 4). Dans une forme de réalisation, le dispositif connecté est un dispositif de commande à bouton-poussoir unique, dont l'actionnement par un utilisateur provoque l'émission de la requête de transaction et de la première adresse MAC (comme présenté sur la figure 6 par exemple). 35 Comme la complexité et les ressources d'un tel dispositif sont assez limitées, la mise en oeuvre de l'invention par simple vérification de l'adresse MAC et un moyen avantageusement simple mais néanmoins très efficace. 3052284 4 Dans ce type de dispositif connecté, l'actionnement court du bouton poussoir provoque l'émission de la requête de transaction et de la première adresse MAC, tandis qu'un actionnement long du bouton poussoir provoque une étape d'initialisation du dispositif comportant: 5 - l'émission d'une première requête d'enregistrement dans la base de données d'une correspondance entre l'identifiant du dispositif et ladite première adresse MAC. Cette première requête d'enregistrement peut être émise par exemple via le réseau local et à destination du serveur gérant la base de données. 10 Concomitamment, l'étape d'initialisation du dispositif comporte en outre : - l'émission d'une seconde requête d'enregistrement dans la base de données d'une correspondance entre l'identifiant du dispositif et au moins l'identifiant de l'utilisateur. Cette seconde requête d'enregistrement peut être émise par exemple via un terminal de type smartphone communiquant par exemple via une liaison Bluetooth avec le dispositif de commande (le 15 smartphone comportant une interface de saisie permettant à un utilisateur de saisir par exemple le type de bien qu'il souhaite commander régulièrement, une adresse personnelle de livraison de ce bien, un moyen de paiement, etc.). Ainsi, dans une réalisation, le serveur rejette d'abord une requête de transaction si le serveur ne 20 retrouve pas dans la base de données l'identifiant de dispositif connecté que comprend cette requête. En outre, le serveur rejette une requête de transaction si le serveur n'identifie pas la première adresse MAC reçue d'un dispositif connecté comme étant identique à la deuxième adresse MAC correspondant dans la base de données à l'identifiant de dispositif connecté que comprend la requête 25 émise par ce dispositif connecté. Dans un premier mode de réalisation illustré sur la figure 2, le dispositif connecté est agencé pour émettre : - un premier message via le réseau de communication et comportant ladite requête de transaction, à 30 destination de la plateforme de transaction, et - un deuxième message comportant la première adresse MAC, via le réseau local et une passerelle du réseau local pour atteindre la plateforme de transaction. Préférentiellement, les premier et deuxième messages sont émis dans un premier intervalle de temps 35 (aussi court que possible selon les ressources du dispositif connecté). De son côté, le serveur compare en outre des moments de réception des premier et deuxième messages auprès de la plateforme de transaction, pour rejeter une requête de transaction issue d'un dispositif connecté si le deuxième 3052284 5 message issu de ce dispositif connecté a été reçue avant ou après le premier message issu de ce dispositif connecté, dans un second intervalle de temps, maximum, prédéterminé. Dans un deuxième mode de réalisation illustré sur la figure 3, le réseau de communication comprend 5 un tronçon du réseau local, et la requête de transaction comporte ladite première adresse MAC du dispositif connecté dans le réseau local. Avantageusement, la base de données peut stocker en outre des coordonnées de terminal à disposition de l'utilisateur, en correspondance de l'identifiant de l'utilisateur. Ainsi, la plateforme envoie un 10 message au terminal de l'utilisateur annonçant, le cas échéant, que la requête de transaction est acceptée. Avantageusement, on peut prévoir en outre qu'une deuxième requête de transaction issue d'un dispositif connecté est rejetée si cette deuxième requête succède une première requête de transaction 15 reçue de ce dispositif connecté dans un intervalle de temps inférieur à une durée prédéterminée. La présente invention vise aussi un système pour contrôler une transaction de biens sur une plateforme de transaction en ligne, comportant un dispositif connecté agencé pour se connecter au moins à un réseau local avec une adresse MAC, et un serveur relié à une base de données pour la mise en oeuvre 20 du procédé ci-avant. Un tel système est illustré à titre d'exemple sur l'une des figures 2 ou 3 commentées plus loin. La présente invention vise aussi un dispositif connecté d'un tel système, et agencé pour émettre une requête de transaction. En particulier, le dispositif est apte à être connecté à un réseau local dans lequel 25 il a une première adresse MAC, la requête de transaction comportant alors cette première adresse MAC. La présente invention vise aussi un serveur d'un tel système, comportant un circuit informatique programmé (typiquement un processeur coopérant avec une mémoire programmée et des interfaces 30 d'entrée/sortie) pour la vérification de requêtes de transaction par utilisation des données de la base de données précitée. La présente invention vise aussi un programme informatique comportant des instructions pour la mise en oeuvre du procédé, lorsque ce programme est exécuté par un processeur d'un circuit informatique. 35 Ces instructions peuvent être distribuées entre le dispositif connecté et le serveur. Typiquement, les ordinogrammes des figures 4 et 5 peuvent illustrer un algorithme général d'un tel programme. 3052284 6 D'autres avantages et particularités de l'invention apparaîtront à la lecture de la description d'exemples de réalisation ci-après, et à l'examen des dessins annexes sur lesquels : - la figure 1, relative à l'art antérieur, illustre des échanges entre un dispositif de commande DIS, un serveur SER gérant une base de données du type précité, et un terminal SM à disposition d'un 5 utilisateur, - la figure 2 illustre des échanges entre un dispositif de commande DIS au sens de l'invention, un serveur SER gérant une base de données au sens de l'invention, et un terminal SM à disposition d'un utilisateur, selon un premier mode de réalisation, - la figure 3 illustre des échanges entre un dispositif de commande DIS au sens de l'invention, un 10 serveur SER gérant une base de données au sens de l'invention, et un terminal SM à disposition d'un utilisateur, selon un deuxième mode de réalisation, - la figure 4 illustre les étapes d'un procédé au sens invention, mises en oeuvre pour contrôler la commande d'un bien, - la figure 5 illustre les étapes d'un procédé au sens invention, mises en oeuvre pour mettre à jour 15 l'identification d'un dispositif DIS auprès du serveur SER, - la figure 6 représente un dispositif de commande DIS comportant un simple bouton-poussoir. Sur les figures 2 et 3, les éléments comportant les mêmes références que celles de la figure 1 sont identiques ou de nature similaire, et ne sont pas décrits ici à nouveau. 20 En particulier comme apparent sur la figure 2, le dispositif DIS communique ici en outre avec une passerelle PAS d'un réseau local LAN auquel le dispositif DIS est connecté. Ainsi, le dispositif DIS est associé physiquement à l'habitat de l'utilisateur, dans lequel la passerelle domestique PAS anime le réseau local LAN auquel peuvent se connecter les équipements dans cet habitat. 25 Plus précisément, le dispositif de commande DIS envoie une requête de transaction comportant son identifiant ID1 via le réseau NET (flèche Fl, comme commenté précédemment en référence à la figure 1), mais aussi une requête complémentaire à la passerelle PAS (flèche F4) pour que cette dernière PAS transmette l'adresse MAC (pour « Media Access Control ») du dispositif DIS dans le réseau local 30 LAN, à destination du serveur SER (flèche F14). Ainsi, la vérification de la transaction auprès du serveur SER peut porter à la fois sur l'identifiant ID1 du dispositif de commande, mais aussi sur son adresse pré-identifiée dans un réseau. Le choix de l'adresse MAC en particulier pour cette vérification peut se justifier comme suit. Le serveur SER peut 35 être communément dans une architecture de type REST (pour « Representational State Transfer ») et peut au mieux associer des adresses virtuelles de type IPV6 aux dispositifs DIS dont il gère les requêtes de transaction. Or, de telles adresses IPV6 varient en permanence. En revanche, l'adresse 3052284 7 MAC d'un équipement dans un réseau local ne varie pas. Ainsi, le serveur SER reçoit toujours la même adresse MAC avec une requête de transaction et peut établir une correspondance entre l'adresse MAC qu'il reçoit et l'identifiant de dispositif ID1 qu'il reçoit en outre dans la requête. 5 Dans un premier mode de réalisation illustré sur la figure 2, lors d'un appui sur le bouton 10 pour une commande, le dispositif DIS envoie simplement son identifiant ID1 (et éventuellement l'adresse du serveur SER sur le réseau NET) à la passerelle PAS (flèche F4). Celle-ci y ajoute l'adresse MAC (MAC1) du dispositif DIS dans le réseau local et envoie les deux données ID1 et MAC1 (flèche F44) au serveur SER. Parallèlement, le dispositif DIS envoie une requête de transaction comportant son 10 identifiant ID1 (flèche Fl) classiquement via le réseau NET, à destination du serveur SER. Le serveur SER, sur réception de l'un des deux messages (F1 ou F44), peut procéder à une temporisation pour vérifier qu'un deuxième message lui parvient (respectivement F44 ou F1). Il vérifie ensuite si l'identifiant ID1 est bien répertorié dans la base, avec l'adresse MAC1 correspondante. Sinon, il ne traite pas la requête F 1 reçue du dispositif DIS, comme décrit en détails plus loin en référence à la 15 figure 5. Dans un deuxième mode de réalisation illustré sur la figure 3, plus simple, lors d'un appui sur le bouton 10 pour une commande, le dispositif DIS envoie directement la requête de transaction (flèche Fl) à la passerelle PAS, avec donc son identifiant ID1 (et éventuellement l'adresse du serveur SER sur 20 le réseau NET). Celle-ci y ajoute l'adresse MAC (MAC1) du dispositif DIS dans le réseau local et envoie les deux données ID1 et MAC1 (flèche F14) au serveur SER. Le serveur SER, sur réception de ces deux identifiants (F1 ou F44) peut vérifier immédiatement si l'identifiant ID1 est bien répertorié dans la base, avec une adresse MAC1 correspondant à l'adresse MAC du dispositif DIS, reçue dans la requête. Dans le cas contraire, le serveur SER ne traite pas la requête. 25 On se réfère à la figure 4 pour décrire le procédé d'appairage du dispositif DIS avec la passerelle PAS, lors d'une mise à jour de son identifiant ID1 auprès du serveur SER. Ainsi, si un appui long est détecté sur le bouton-poussoir à l'étape S10, le dispositif envoie une requête à la passerelle à l'étape S14, pour que celle-ci transmette à l'étape 515 un message destiné au serveur SER et incluant l'identifiant du 30 dispositif ID1, avec l'adresse MAC (MAC1) du même dispositif dans le réseau local. L'appui long à l'étape S10 provoque aussi l'initialisation du dispositif auprès du terminal SM de l'utilisateur. Le dispositif DIS envoie son identifiant ID1 au terminal SM (via Bluetooth par exemple) et, à l'étape S11, l'interface homme-machine IHM du terminal SM s'anime pour que l'utilisateur du terminal rentre son adresse de livraison ADR1, le type de bien PDT1 souhaité pour les futures transactions, etc. 35 A l'étape S12, ces données PDT1, ADR1 sont transmises au serveur, par le terminal SM, avec ses coordonnées de contact SM1 et l'identifiant du dispositif ID1. À l'étape S 13, le serveur SER reçoit ces 3052284 8 données ID1, SM1, ADR1, PDT1, éventuellement avec le message issu de la passerelle à l'étape S15 et comportant les données ID1 et MAC1, ou déclenche à l'étape S16 une temporisation pour s'assurer de la réception de ces deux messages. À l'étape S17 ensuite, le serveur stocke dans la base de données la correspondance entre l'identifiant de dispositif ID1, avec son adresse MAC1, ainsi que les données 5 de l'utilisateur US1 : ADR1, PDT1, SM1. On se réfère maintenant à la figure 5 pour décrire les étapes qui suivent un appui court sur le bouton-poussoir 10, pour émettre une commande du bien PDT1. L'appui court sur le bouton à l'étape S20 provoque l'émission via la passerelle, à l'étape S22, d'un message comportant l'adresse MAC (MAC1) 10 du dispositif, avec son identifiant ID1. L'appui court sur le bouton à l'étape S20 provoque aussi l'émission (éventuellement aussi via la passerelle PAS comme décrit en référence à la figure 3) l'envoi de la requête de transaction avec l'identifiant ID1 du dispositif à l'étape S21. Ces données sont reçues par le serveur SER à l'étape S24, pour contrôler la requête de transaction. 15 Ainsi, à l'étape S25, le serveur vérifie tout d'abord si l'identifiant ID1 du dispositif est bien répertorié dans la base. Le cas échéant, à l'étape S26, le serveur vérifie en outre si l'adresse MAC du dispositif, reçu de la passerelle, correspond bien à l'adresse MAC1 stocké dans la base en correspondance de l''identifiant ID1. Le cas échéant, à l'étape S27, le serveur peut vérifier en outre si l'utilisateur référencé dans la base en correspondance de l'identifiant ID1 peut effectivement recevoir le bien PDT1 20 commandé. Ce test S27 peut prévoir aussi d'exécuter une temporisation pour vérifier qu'une requête reçue ultérieurement du dispositif DIS ne succède pas une première requête de transaction déjà reçue de ce dispositif DIS dans un intervalle de temps inférieur à une durée prédéterminée (par exemple 24 heures). Dans ce cas, la requête ultérieure est rejetée et n'est pas traitée. 25 Dans le cas où tous les tests sont positifs, à l'étape S28, le serveur valide la vérification des identifiants et envoie, à l'étape S29, à destination du terminal de coordonnées SM1 (référencées dans la base en correspondance de l'identifiant ID1), un message d'acceptation de la commande. Sur réception de ce message auprès du terminal SM, l'interface IHM s'anime pour afficher le message à l'étape S30 et l'utilisateur peut par exemple confirmer la commande en utilisant l'interface IHM à l'étape S31. 30 On comprendra ainsi que la vérification à la fois de l'identifiant ID1 du dispositif, et de son adresse MAC, invariable dans le réseau local LAN (le dispositif étant censé se situer dans la zone de couverture de ce réseau local dans l'application visée), permet de contrôler, de façon plus sécurisée que dans l'art antérieur, des requêtes de transaction que peut émettre ce dispositif. 35 Bien entendu, la présente invention ne se limite pas aux formes réalisation décrites ci-avant à titre d'exemple ; elle s'étend à d'autres variantes. 3052284 9 Ainsi, par exemple, on a décrit ci-avant une requête émise depuis le dispositif DIS et directement destinée à un serveur SER. Dans une variante possible, le dispositif de commande peut permettre la commande de plusieurs produits. Ainsi, le dispositif DIS peut contacter dans un premier temps le 5 terminal de l'utilisateur pour validation de la commande de l'un de ces produits, et la requête correspondant à ce produit particulier peut être émis au serveur capable de traiter une telle commande. REVENDICATIONS1. Procédé mis en oeuvre par des moyens informatiques pour contrôler une transaction de biens sur une plateforme de transaction en ligne, transaction dans laquelle un dispositif connecté, actionnable par un utilisateur, émet, sur commande de l'utilisateur, une requête de transaction comprenant un identifiant du dispositif connecté, via un réseau de communication, le procédé étant mis en oeuvre par un serveur de la plateforme de transaction et comprenant - - une étape initiale d'élaboration d'une base de données mettant en correspondance : * d'une part, un identifiant de dispositif connecté, et, * d'autre part, un identifiant de bien, * ainsi qu'un identifiant d'utilisateur apte à commander ce bien en opérant ladite transaction via ce dispositif connecté, - et des étapes courantes de : - réception via le réseau de communication d'une requête de transaction comprenant un identifiant de dispositif connecté, et - de traitement de la requête reçue en retrouvant, le cas échéant, en fonction de l'identifiant de dispositif connecté dans la requête, l'utilisateur de ce dispositif connecté et le bien à délivrer à cet utilisateur, caractérisé en ce que le dispositif connecté est apte à communiquer avec un réseau local avec une adresse MAC propre au dispositif connecté, en ce que la base de données répertorie en outre une adresse MAC propre à un dispositif connecté en correspondance de l'identifiant de ce dispositif connecté, et en ce que le serveur reçoit en outre une première adresse MAC de dispositif connecté, avec une requête de transaction issue de ce dispositif connecté, et vérifie dans la base de données une correspondance, en outre, entre : * ladite première adresse MAC, et * une deuxième adresse MAC, associée dans la base de données à l'identifiant du dispositif connecté que comprend la requête de transaction. 2. Procédé selon la revendication 1, caractérisé en ce que le dispositif connecté est un dispositif de commande à bouton poussoir unique, dont l'actionnement par un utilisateur provoque l'émission de la requête de transaction et de la première adresse MAC. 3. Procédé selon la revendication 2, caractérisé en ce qu'un actionnement court du bouton poussoir provoque l'émission de la requête de transaction et de la première adresse MAC, tandis qu'un actionnement long du bouton poussoir provoque une étape d'initialisation du dispositif comportant: 3052284 11 - l'émission d'une requête d'enregistrement dans la base de données d'une correspondance entre l'identifiant du dispositif et ladite première adresse MAC. 4. Procédé selon la revendication 3, caractérisé en ce que l'étape d'initialisation du dispositif comporte 5 en outre : - l'émission d'une requête d'enregistrement dans la base de données d'une correspondance entre l'identifiant du dispositif et au moins l'identifiant de l'utilisateur. 5. Procédé selon l'une des revendications précédentes, caractérisé en ce que le serveur rejette une 10 requête de transaction si le serveur ne retrouve pas dans la base de données l'identifiant de dispositif connecté que comprend cette requête. 6. Procédé selon l'une des revendications précédentes, caractérisé en ce que le serveur rejette une requête de transaction si le serveur n'identifie pas la première adresse MAC reçue d'un dispositif 15 connecté comme étant identique à la deuxième adresse MAC correspondant dans la base de données à l'identifiant de dispositif connecté que comprend la requête émise par ce dispositif connecté. 7. Procédé selon l'une des revendications précédentes, caractérisé en ce que le réseau de communication comprend un tronçon du réseau local, et en ce que la requête de transaction comporte 20 ladite première adresse MAC du dispositif connecté dans le réseau local. 8. Procédé selon l'une des revendications 1 à 6, caractérisé en ce que le dispositif connecté est agencé pour émettre : - un premier message via le réseau de communication et comportant ladite requête de transaction, à 25 destination de la plateforme de transaction, et - un deuxième message comportant la première adresse MAC, via le réseau local et une passerelle du réseau local pour atteindre la plateforme de transaction. 9. Procédé selon la revendication 8, caractérisé en ce que les premier et deuxième messages sont émis 30 dans un premier intervalle de temps, et en ce que le serveur compare en outre des moments de réception des premier et deuxième messages auprès de la plateforme de transaction, pour rejeter une requête de transaction issue d'un dispositif connecté si le deuxième message issu de ce dispositif connecté a été reçue avant ou après le premier message issu de ce dispositif connecté, dans un second intervalle de temps, maximum, prédéterminé. 35 10. Procédé selon l'une des revendications précédentes, caractérisé en ce que la base de données stocke en outre des coordonnées de terminal à disposition de l'utilisateur, en correspondance de l'identifiant 3052284 12 de l'utilisateur, et en ce que la plateforme de transaction envoie un message au terminal de l'utilisateur annonçant, le cas échéant, que la requête de transaction est acceptée. 11. Procédé selon l'une des revendications précédentes, caractérisé en ce qu'une deuxième requête de 5 transaction issue d'un dispositif connecté est rejetée si cette deuxième requête succède une première requête de transaction reçue de ce dispositif connecté dans un intervalle de temps inférieur à une durée prédéterminée. 12. Système pour contrôler une transaction de biens sur une plateforme de transaction en ligne, 10 comportant un dispositif connecté agencé pour se connecter au moins à un réseau local avec une adresse MAC, et un serveur relié à une base de données pour la mise en oeuvre du procédé selon l'une des revendications précédentes. 13. Dispositif connecté d'un système selon la revendication 12, agencé pour émettre une requête de 15 transaction, caractérisé en ce qu'il est apte à être connecté à un réseau local dans lequel il a une première adresse MAC, la requête de transaction comportant ladite première adresse MAC. 14. Serveur d'un système selon la revendication 12, caractérisé en ce qu'il comporte un circuit informatique programmé pour la vérification de requêtes de transaction par utilisation des données de 20 ladite base de données. 15. Programme informatique caractérisé en ce qu'il comporte des instructions pour la mise en oeuvre du procédé selon l'une des revendications 1 à 11, lorsque ce programme est exécuté par un processeur d'un circuit informatique. 25