FR 3080478 A1 20191025 FR 1853535 A 20180423 Paiement sans contact perfectionné, utilisant un terminal de type smartphone ou autre La présente invention concerne notamment un procédé sécurisé de paiement bancaire, à partir de dispositifs mobiles. On entend ici par « dispositif mobile » un terminal mobile communiquant via un réseau, par exemple le téléphone mobile d'un utilisateur passant une transaction financière. Les paiements par un dispositif mobile concernent toutes les transactions financières effectuées depuis ce dispositif mobile et débitées : - sur un compte bancaire, - sur la facture d'un opérateur du réseau auquel est connecté ce dispositif mobile ou - sur un compte prépayé (« porte-monnaie électronique »), qui peut être alimenté avec un dépôt auprès d'un agent ou d'un commerçant. On connait globalement trois grandes catégories de paiement par dispositif mobile (dit « paiement mobile » ci-après) : - les paiements à distance comme le paiement par dispositif mobile sur les sites de commerce électronique par exemple, - les paiements de proximité devant une borne ou un terminal de paiement, ou - les transferts de sommes d'argent de mobile à mobile. Chaque catégorie de service peut utiliser des technologies spécifiques selon les usages. Les technologies suivantes sont par exemple utilisées pour le paiement mobile : - serveur vocal interactif, - la confirmation par SMS ou « 3D-Secure », - l'Internet mobile, - par NFC, - par QR code, - ou encore par Bluetooth, - la technologie de transmission de données par ultrasons dite NSDT (pour « Near sound data transfer »). Actuellement, lors de règlement en boutique ou d'une prestation de service, l'opération se réalise majoritairement avec une carte bancaire et un code de sécurité à quatre chiffres. Cette opération est toujours réalisée avec un Terminal de Paiement (TPE) acheté ou loué par le commerçant. Cela 2 implique ainsi la saisie du code précité par le payeur, dans un environnement possiblement non sécurisé. Lors d'un paiement en ligne, outre l'affichage d'une page sécurisée (par exemple HTTPS), il est 5 souvent associé l'envoi d'un code unique sur le mobile du client via SMS (dans la technologie 3D- Secure). Il existe aussi de nombreux services bancaires générant des numéros de cartes de crédit virtuelles, qui peuvent être utilisés pour un unique achat sur un site internet. Cette réalisation est plus sécurisée mais nécessite de nombreuses étapes et alourdit le procédé de paiement. 10 Le paiement sans contact n'est pas encore massivement utilisé et rencontre encore quelques réticences de la part des utilisateurs. En effet, pour ce qui concerne la technologie sans contact et NFC notamment, en France typiquement, environ dix millions d'utilisateurs sont équipés d'un dispositif mobile compatible avec une 15 communication en champ proche ou « NFC » et plus de trente millions d'utilisateurs sont porteurs d'une carte bancaire sans contact. Il existe environ 300 000 terminaux de paiement seulement à disposition des commerçants (ou « TPE ») compatibles avec la technologie NFC sur 1,5 millions de terminaux. 20 La portée radiofréquence du NFC est de l'ordre du mètre, et ce de façon non directive, ce qui peut justifier la réticence des utilisateurs payeurs à l'emploi de cette technique. Par ailleurs et plus généralement, les technologies existantes pour les paiements sans contact sont souvent liées à un matériel spécifique, avec souvent une technologie propriétaire, sans garantie de 25 présence d'un terminal de paiement selon cette technologie auprès de tous les commerçants. La présente invention vient améliorer la situation. Elle propose à cet effet un procédé pour transmettre des données relatives à une transaction bancaire 30 entre un terminal de fournisseur et un terminal de client. Les terminaux sont équipés chacun de : - un émetteur de lumière, - un capteur de lumière, et - une interface homme machine pour une visualisation et saisie par un utilisateur d'informations relatives à la transaction. 35 En particulier, chaque terminal comporte un module logiciel au moins pour : 3 - piloter l'émetteur de lumière du terminal en vue d'une transmission d'un flux lumineux en espace libre, modulé en amplitude ou en fréquence lumineuse pour coder des données relatives à la transaction bancaire, et - interpréter un flux lumineux en espace libre, modulé en amplitude ou en fréquence lumineuse, que 5 reçoit le capteur de lumière, pour en décoder des données relatives à la transaction bancaire. Le procédé comporte alors au moins : - Une transmission d'un premier flux du terminal du fournisseur au terminal du client, le premier flux étant modulé pour coder au moins un montant de transaction, 10 - Sur réception du premier flux par le capteur du terminal du client, une animation de l'interface homme machine du terminal du client pour une demande de validation du montant de transaction par le client via l'interface homme machine du terminal du client, - En cas de validation par le client, une transmission d'un deuxième flux du terminal du client au terminal du fournisseur, le deuxième flux étant modulé pour coder au moins des données de validation 15 du client. On entend par « transmission d'un flux » ici la transmission d'un flux lumineux en espace libre, en particulier sans utilisation nécessaire d'un support optique quelconque tel qu'une fibre optique entre les deux terminaux. 20 Grâce à ces dispositions, les communications entre les deux terminaux (du client et du fournisseur) sont bien apparentes, puisqu'une lumière peut être produite par l'émetteur de lumière précité, ce qui permet à un utilisateur de constater visuellement la transmission effective des données de transaction. En effet, la modulation de lumière, en amplitude, peut être obtenue à partir d'une diode clignotante 25 (blanche par exemple), ou d'un écran à photodiodes clignotant. La modulation en fréquence peut être obtenue par changement de couleur des photodiodes de l'écran (ou par illumination sélective d'une diode de couleur choisie parmi plusieurs diodes produisant ensemble une lumière blanche). En outre, comme les deux terminaux sont face-à-face préférentiellement à une courte distance l'un de 30 l'autre, le terminal recevant les données forme écran à la lumière émise par l'autre terminal, ce qui empêche des terminaux tiers de recevoir aussi ces données de transaction. Ainsi, la confidentialité est assurée par ce moyen de communication par voie optique. De plus, contrairement aux flux électromagnétiques utilisés dans les modes sans contact de la technique antérieure tel que NFC, la trajectoire des flux lumineux est reconnaissable par les utilisateurs. Il leur est possible de détecter dans 4 cette trajectoire la présence d'un appareil ou d'un équipement électronique étranger à la transaction. Dans une telle situation suspecte, il leur est également possible d'interrompre immédiatement le flux lumineux en détournant l'un des terminaux, ou en y interposant un objet ou une main, par exemple. En outre, les terminaux peuvent être de type Smartphone, tablette, ou équivalent de sorte qu'il n'est 5 pas nécessaire de prévoir un matériel spécifique pour ce type de communication, comme on le verra dans les exemples de réalisation présentés ci-après. En effet, dans une réalisation, le terminal du client et/ou le terminal du fournisseur sont de type parmi un smartphone, une tablette, un ordinateur ou équivalent, et sont alors naturellement équipés d'un module de prise de vue comportant : 10 - une diode électroluminescente pour produire un flash photographique, et - une matrice de photorécepteurs pour recevoir des données d'image. Ainsi, le module logiciel précité pilote la diode électroluminescente en tant qu'émetteur de lumière en vue d'une transmission de flux lumineux modulé en amplitude et interprète un flux lumineux modulé en amplitude que reçoit la matrice de photorécepteurs. 15 En variante, le terminal du client et/ou le terminal du fournisseur étant encore de type parmi un smartphone, une tablette, un ordinateur ou équivalent, ils sont naturellement équipés d'un écran d'affichage à diodes photoémettrices et d'un module de prise de vue comportant une matrice de photorécepteurs pour recevoir des données d'image. 20 Ainsi, dans cette réalisation encore, le module logiciel peut piloter l'écran d'affichage en tant qu'émetteur de lumière en vue d'une transmission de flux lumineux modulé en amplitude et interpréter un flux lumineux modulé en amplitude que reçoit la matrice de photorécepteurs. Une telle réalisation est présentée sur la figure 2 commentée plus loin. 25 Par ailleurs, les données de la transaction, elles-mêmes, peuvent respecter des protocoles standards dans le domaine des transactions bancaires et prendre une forme générale d'une succession de bits à « zéro » ou « un ». Toutefois, il convient de coder ces valeurs binaires successives par une modulation de la lumière émise. Dans une forme de réalisation pertinente notamment dans le cas où l'émetteur de lumière est une diode électroluminescente utilisée habituellement comme flash d'appareil 30 photographique, il est choisi que la lumière émise soit produite sous forme d'impulsions lumineuses qui se suivent dans le temps. 5 Ainsi, dans une première forme de réalisation, les données relatives à la transaction bancaire étant codées en binaire sur une succession de bits à « 0 » ou « 1», les flux lumineux modulés en amplitude comportent chacun une succession d'impulsions lumineuses, et en particulier : - une impulsion lumineuse dans la succession correspond à une valeur binaire de « 1», 5 - tandis que l'émetteur de lumière est inactif pour transmettre une ou plusieurs valeurs binaires de «o » entre deux impulsions lumineuses. Ainsi, une pulsion lumineuse correspond à une valeur de « un », tandis qu'un « trou » sans lumière entre deux impulsions correspond à un « zéro ». Une telle réalisation est illustrée sur la figure 3A commentée plus loin. 10 Dans une réalisation alternative, les données relatives à la transaction bancaire étant codées en valeurs binaires, les flux lumineux modulés en amplitude comportent chacun une succession d'impulsions lumineuses. En particulier dans cette réalisation, ce sont les positions temporelles de chaque impulsion dans la succession qui sont définies en fonction des valeurs binaires par une modulation de position d'impulsion. Une telle réalisation est illustrée sur la figure 3B qui sera commentée plus loin. 15 On peut alternativement réaliser un codage par modulation de fréquence d'une succession binaire en prévoyant typiquement que les «o » et « 1» sont codés par deux couleurs différentes, ou encore, par deux suites de couleurs différentes pour plus de robustesse dans le codage. Par exemple un premier intervalle de temps pendant lequel l'émetteur de lumière émet à une première couleur A peut indiquer le début d'un bit, et s'il est suivi d'un intervalle avec une deuxième couleur B alors le bit est un « 0 », et 20 s'il est suivi d'un intervalle avec une troisième couleur C alors le bit est un « 1», et on revient à la couleur A pour indiquer le bit suivant. Dans l'un ou l'autre des modes de réalisation ci-dessus, on peut choisir avantageusement qu'une succession d'impulsions puisse comporter alors une succession d'occurrences avec une impulsion lumineuse ou une absence d'impulsion lumineuse, et en particulier les occurrences de cette succession 25 sont espacées d'un pas temporel inférieur à une milliseconde. En effet, d'après les tests réalisés sur des smartphones classiques, les performances en termes de réponse du capteur de lumière et de fréquence de clignotement de la diode peuvent permettre un pas temporel inférieur à 1 ms, voire inférieur à 0,1 ms, soit 10kHz en fréquence d'opération de la diode, ce qui est largement assez et suffisamment rapide pour communiquer 20 à 100 octets (ce qui représente 30 habituellement la taille classique des données d'une transaction bancaire (pour un achat en boutique typiquement) à transmettre). 6 Dans une forme de réalisation possible, l'un au moins des terminaux parmi le terminal du fournisseur et le terminal du client comporte en outre une interface via un réseau de communication avec un serveur bancaire distant en vue d'obtenir du serveur une autorisation de la transaction. Les données de validation du client comportent alors des données d'authentification du client, en vue d'une demande 5 d'autorisation de transaction transmise au serveur bancaire avec les données d'authentification du client via le réseau de communication. Cette réalisation peut être avantageuse par exemple pour des paiements d'un montant supérieur à un seuil nécessitant une vérification par un serveur bancaire. Néanmoins, il peut être prévu des réalisations dans lesquelles aucun des terminaux n'a besoin d'être en communication avec un serveur 10 bancaire: - notamment lorsque les montants des transactions sont inférieurs à un seuil (comme en communication via NFC, aucune vérification n'étant faite par le terminal du fournisseur auprès du serveur bancaire), et - dans une application de porte-monnaie électronique où le terminal stocke un montant 15 disponible pour des transactions et qui est décrémenté d'un montant de transaction après chaque transaction : le deuxième flux du terminal comprend alors dans cette réalisation, en plus des données de validation, des données représentatives du montant en monnaie électronique. 20 La présente invention vise aussi un système pour la mise en oeuvre du procédé ci-avant, comportant alors un terminal de client et un terminal de fournisseur, les terminaux étant équipés chacun de: - un émetteur de lumière, - un capteur de lumière, et - une interface homme machine pour une visualisation et saisie par un utilisateur d'informations 25 relatives à la transaction. En particulier, chaque terminal comporte un module logiciel au moins pour : - piloter l'émetteur de lumière du terminal en vue d'une transmission d'un flux lumineux, modulé en amplitude lumineuse pour coder des données relatives à la transaction bancaire, et - interpréter un flux lumineux, modulé en amplitude lumineuse, que reçoit le capteur de lumière, pour 30 en décoder des données relatives à la transaction bancaire. Un exemple de réalisation d'un tel système est illustré sur la figure 1 commentée plus loin et faisant apparaitre les deux terminaux précités. 7 La présente invention vise aussi un terminal d'un client, d'un système du type ci-avant et comportant en particulier un module logiciel pour la mise en oeuvre du procédé au sens de l'invention. La présente invention vise aussi un terminal d'un fournisseur, d'un système du type ci-avant et 5 comportant en particulier un module logiciel pour la mise en oeuvre du procédé au sens de l'invention. La présente invention vise aussi un programme informatique comportant des instructions pour la mise en oeuvre du procédé au sens de l'invention, lorsque ces instructions sont exécutées par un processeur. Ces instructions peuvent alors être réparties entre le terminal du client et le terminal du fournisseur, 10 comme on le verra en référence à la figure 4 commentée plus loin, et qui présente les principale étapes algorithmique de ce programme informatique. D'ailleurs, d'autres avantages et caractéristiques de l'invention apparaitront à la lecture de la description d'exemples de réalisation donnés ci-après et à l'examen des dessins annexés sur lesquels : 15 - la figure 1 illustre un système à deux terminaux échangeant des données par transmission optique pour une transaction bancaire, - la figure 2 illustre une variante de réalisation où l'écran d'affichage d'un terminal est utilisé comme source de lumière, alors qu'une diode électroluminescente (utilisée habituellement en tant que flash) est prévue comme source de lumière dans le mode de réalisation de la figure 1, 20 - la figure 3A montre un premier exemple de codage des données de transaction par une succession d'impulsions lumineuses, - la figure 3B montre un deuxième exemple de codage des données de transaction par une succession d'impulsions lumineuses, - la figure 4 illustre les différentes étapes du procédé au sens de l'invention, et 25 - La figure 5 montre un exemple de pile protocolaire pouvant être utilisée pour la mise en oeuvre du procédé proposé. L'invention propose une transmission de données de transaction pour un paiement bancaire, par flux lumineux échangés entre deux terminaux. 30 En référence à la figure 1 en particulier, un fournisseur (de produit, de prestation, de service, ou autre ; par exemple un commerçant ou autre) dispose d'un terminal Ti, de type smartphone, tablette, ordinateur (portable ou non), ou équivalent. Un terminal de ce type est équipé typiquement d'une caméra intégrée pour des prises de vues, avec par exemple une diode électroluminescente El pour opérer un flash et un capteur Cl à matrice de photorécepteurs pour acquérir les données d'image. De 35 même, un client du fournisseur souhaitant lui effectuer un paiement par transaction bancaire peut 8 disposer aussi d'un terminal T2 comportant de mêmes équipements ou similaires (une diode E2 et un capteur C2). Ainsi, de façon avantageuse, la mise en oeuvre de l'invention ne nécessite pas un matériel spécifique : des terminaux préexistants, par exemple mobiles, peuvent être utilisés moyennant une programmation 5 particulière de l'unité de traitement que comporte ces terminaux pour mettre en oeuvre les étapes du procédé selon l'invention. Néanmoins, il s'agit d'un exemple de réalisation et alternativement, il est possible de prévoir un dispositif spécifique intégrant un capteur et une diode ou autre moyen d'illumination, se connectant par exemple sur un port USB d'un équipement de type ordinateur par exemple (un « dongle USB » 10 typiquement). L'unité de traitement que comporte chacun des terminaux T1 et T2 comprend typiquement : - une mémoire (MEM1, respectivement MEM2) stockant des données temporaires ou non, et en particulier des données d'instructions d'un programme informatique au sens de l'invention ; ces données d'instructions peuvent être réparties alors entre les deux terminaux pour mettre en 15 oeuvre des étapes spécifiques pour le terminal du fournisseur d'une part, et des étapes spécifiques pour le terminal du client d'autre part, et - un processeur (PROC1, respectivement PROC2) coopérant avec la mémoire précitée pour y lire les données d'instructions et exécuter ainsi des étapes du procédé. 20 En particulier, l'unité de traitement que comporte le terminal Ti du fournisseur comprend en outre une interface COM, reliée au processeur PROC1, pour communiquer avec notamment un serveur bancaire distant SER, via un réseau de communication RES (filaire ou radiofréquence). Ainsi, il est possible de n'utiliser que deux smartphones, tablettes ou autres (pour le client et le 25 fournisseur) afin de réaliser une transaction financière. Cette opération se réalise dans un mode opérationnel pair-à-pair pour transférer les données bancaires sécurisées entre les deux terminaux. Cette solution peut remplacer ainsi l'usage des terminaux de paiement classique (dits « TPE »). L'invention propose de réaliser une communication optique sans fil bilatérale sécurisée, utilisable par 30 exemple pour effectuer un paiement en boutique ou autre, avec une utilisation judicieuse des fonctions optiques d'un smartphone, d'une tablette ou d'un ordinateur de type « laptop » par exemple. Il est considéré ici un cas classique où les données relatives à la transaction bancaire sont constituées d'une succession de valeurs binaires à « zéro » ou « un », comme illustré sur la partie supérieure de la 35 figure 3A. Dans une forme de réalisation, la diode électroluminescente El ou E2 de l'un des terminaux Ti et T2 peut alors « clignoter » et transmettre ainsi un flux lumineux défini par une succession 9 d'occurrences tl, t2, t3, t4, t5, t6 ..., régulièrement espacées dans le temps et où, pour chaque occurrence : - la diode E allumée pour transmettre une impulsion lumineuse si la valeur binaire correspondante à transmettre est « un » 5 - ou la diode E éteinte si la valeur binaire correspondante à transmettre est « zéro », comme illustré sur la partie du bas de la figure 3A. Bien entendu, il s'agit d'un exemple de réalisation et, dans un autre exemple de réalisation illustré sur la figure 3B, on peut prévoir une succession d'occurrences tl, t' 1, t2, t'2, t3, t'3, t4, t'4, t5, t'5, t6, t'6 10 ..., avec ici un codage sur la position d'une impulsion lumineuse à émettre parmi une occurrence ti ou une occurrence t'. Par exemple : - si la valeur binaire est « un », l'impulsion lumineuse est émise à la première occurrence ti, - et si la valeur binaire est « zéro », l'impulsion lumineuse est émise à la deuxième occurrence t' qui suit la première occurrence ti. 15 Bien entendu, d'autres réalisations sont encore possibles : par exemple un codage sur deux niveaux d'amplitude lumineuse (un niveau bas pour les « zéro » et un niveau « haut » pour les « un » par exemple), ou autres. 20 Le type de données relatives à la transaction, elles-mêmes, typiquement sous la forme d'un train binaire (valeurs à « zéro » et « un »), ne diffère pas particulièrement par rapport à celui des données de transaction habituellement échangées avec un TPE classique (sans contact ou par lecture directe d'une carte bancaire). 25 En revanche, le programme informatique précité, exécuté par les processeurs PROC1 et PROC2, et formant ce qui est appelé ici « un module logiciel » permet de piloter la diode électroluminescente et le capteur de chaque terminal pour l'échange des données relatives à la transaction entre les deux terminaux Ti et T2. Cela se traduit par exemple par une utilisation particulière des fonctions optiques des terminaux Ti et T2 et de couches physiques ou de bas niveau (PHY - MAC) dans le protocole 30 applicatif des terminaux. La figure 5 illustre les différentes couches habituelles d'une pile protocolaire d'un terminal, avec typiquement : - en couches (« layers ») 6 et 7, des couches d'applications de communication, - en couche 5, une couche de session (l'application au sens de l'invention étant alors susceptible d'utiliser le « middleware » existant), 35 - en couches 3 et 4 des couches de transport et réseau, - en couches 1 et 2, des couches physique (PHY) et de liaison de données (MAC), avec ici en particulier la possibilité de contrôler « l'optique » des terminaux pour la transmission de données par 10 moyens optiques en espace libre, c'est-à-dire sans fil ou autre guide d'onde (en émission et en réception). Les paquets contenant les données de transaction peuvent se baser ainsi sur les recommandations ou 5 standards existants (par exemple la certification EMV, les recommandations EAL4+ - « Paiement sur mobile » ou RFC 2404 pour les aspects de cryptage des données), sans modification nécessaire. Les paquets de valeurs binaires précitées peuvent être alors encapsulés dans des trames de communications optiques sans fil, à l'instar du protocole NFC par exemple. 10 Le terminal du fournisseur Ti, communiquant avec ce type de trame et selon la pile protocole illustrée sur la figure 5, est capable ainsi de communiquer dans un exemple de réalisation, à la fois avec le terminal du client T2 et avec le serveur bancaire SER, comme illustré dans l'exemple de réalisation commenté maintenant en référence à la figure 4. À l'étape Si de la figure 4, le fournisseur lance l'application au sens de l'invention sur son terminal 15 Ti, pour une demande de validation d'un paiement au terminal T2 d'un client. Le terminal du fournisseur Ti exécute en tant que première étape Si une animation de l'interface homme machine IHM1 du terminal Ti, pour que le fournisseur saisisse les premières données de la transaction (notamment par exemple le prix de la transaction, et éventuellement une référence du fournisseur). 20 Ensuite, à l'étape S2, le terminal Ti transmet sous la forme d'impulsions lumineuses le montant de la transaction avec une demande de validation de son montant, au terminal T2 du client. De la même manière, sur réception de ce type de message, le terminal T2 lance l'application au sens de l'invention, de paiement par impulsions lumineuses, et la première étape S3 du lancement de cette application sur le terminal du client T2, consiste à animer une interface homme machine IHM2 du terminal T2 afin 25 que le client puisse valider ou non (confirmer ou infirmer le paiement, avec éventuellement la saisie d'un code PIN). Si le client valide la transaction via l'interface IHM2, le terminal T2 transmet au terminal Ti à l'étape S4 une validation de la transaction avec une authentification du terminal T2 du client. Sur réception de cette authentification, le terminal Ti transmet au serveur bancaire SER, à l'étape S5, 30 une demande de validation/enregistrement de la transaction avec : - les données du client (identité, authentification), - les données de la transaction (montant, date, etc.), - les données du fournisseur (identité, notamment). Le serveur SER, après validation/enregistrement, transmet au terminal Ti du fournisseur un message 35 de validation de la transaction à l'étape S6, ce qui provoque sur le terminal Ti : - une animation de l'interface homme-machine IHM1 pour afficher au fournisseur, à l'étape S7, l'information de validation de la transaction par le serveur, 11 - ainsi qu'un envoi à l'étape S8 d'un message de validation de la transaction au terminal du client T2. À l'étape S9, sur réception de ce message sur le terminal T2, l'interface IHM2 peut s'animer pour signifier au client que la transaction a bien été enregistrée pour son paiement. 5 On peut relever ici que les étapes S5 et 6 sont optionnelles. Par exemple, le terminal du fournisseur Ti peut stocker toutes les données de transaction et les transmettre ultérieurement au serveur bancaire pour leur enregistrement. Alternativement, elles peuvent être exécutées par le terminal du client T2, par exemple en extrayant toutes les données nécessaires à l'identification et l'authentification du client utilisateur du terminal T2 auprès du serveur. Par ailleurs, les données du fournisseur peuvent être 10 transmises à l'étape S2 au terminal T2 pour qu'elles soient enregistrées auprès du serveur bancaire. Par ailleurs, l'étape S8 de transmission d'un message d'enregistrement de transaction auprès du serveur bancaire peut être menée directement depuis le ou un serveur bancaire (par exemple du serveur bancaire du client) vers le terminal du client T2, par communication via des réseaux radiofréquences classiques, en recevant ce message par exemple sous la forme d'un SMS (à la manière 15 du 3dsecure mais après transaction). En particulier, les étapes S2, S4 au moins, d'interactions entre les deux terminaux par voie optique, peuvent être effectuées en disposant les deux terminaux Ti et T2 dos à dos, comme illustré sur la figure 1, à quelques centimètres l'un de l'autre. Dans ce cas, l'un des terminaux forme écran pour 20 d'autres terminaux au signal lumineux qu'il reçoit. Ainsi, la communication optique ne peut être reçue que par le terminal formant cet écran. Par ailleurs, les utilisateurs en portant leur terminal, voient l'éclairement provoqué par la transmission des données et se rassurent ainsi quant à l'effectivité de la communication des données de transaction. 25 Par ailleurs, on a illustré sur la figure 2 une variante de la réalisation consistant à disposer les terminaux Ti et T2 différemment et non plus dos à dos. En particulier ici, le terminal du fournisseur Ti (ou même le terminal T2 du client) dispose classiquement, dans son interface homme machine IHM sur sa face avant, d'un écran d'affichage ECR et cet écran ECR remplace au moins pour une étape (par exemple l'étape S2), la diode électroluminescente (El ou E2). 30 Ainsi, dans un exemple de réalisation, le terminal du fournisseur Ti, lorsqu'il présente le montant de la transaction à l'étape S2, peut animer l'écran d'affichage ECR pour afficher le prix de la transaction, comme illustré sur la figure 2. Cet affichage (ou un affichage complémentaire tel qu'une barre lumineuse s'affichant au-dessus du montant), avec par exemple une lumière blanche suffisamment intense, peut clignoter en respectant un train d'impulsions définies pour communiquer ce montant de 35 transaction, avec par exemple des données du fournisseur, afin que ces données soient reçues par le terminal T2 du client donnant alors dos au terminal Tl. Dans ce cas, un capteur de lumière CC du terminal Ti, qui est habituellement utilisé en mode « selfie » ou « webcam », peut s'animer pour 12 recevoir les impulsions lumineuses correspondant aux données de validation du terminal T2 à l'étape S4. On comprendra ainsi que cette forme de réalisation peut être avantageuse si le terminal Ti du fournisseur (par exemple un PC classique, portable ou non, équipé d'une webcam par exemple) n'est 5 pas équipé d'un appareil de prise de vue habituellement présent sur les Smartphones et tablettes. Bien entendu, le terminal du client Ti peut utiliser aussi son écran d'affichage comme moyen d'éclairage pour la transmission des données de transaction, si nécessaire. Plus généralement, la présente invention n'est pas limitée aux formes de réalisation décrites ci-avant à 10 titre d'exemple ; elle s'étend à d'autres variantes. Ainsi, on comprendra par exemple que les formes de modulation de lumière présentées sur les figures 3A et 3B admettent d'autres variantes encore. Les étapes successives de paiement bancaire présentées en référence à la figure 4 admettent aussi des variantes qui peuvent dépendre du type de transaction souhaitée (en fonction d'un montant plafond par 15 exemple, avec en cas de dépassement, la demande de saisie d'un code d'identification). REVENDICATIONS1. Procédé pour transmettre des données relatives à une transaction bancaire entre un terminal de fournisseur (Ti) et un terminal de client (T2), les terminaux étant équipés chacun de : - un émetteur de lumière (El, E2), - un capteur de lumière (Cl, C2 ; CC), et - une interface homme machine (IHM1, IHM2) pour une visualisation et saisie par un utilisateur d'informations relatives à la transaction, Dans lequel chaque terminal comporte un module logiciel au moins pour : - piloter l'émetteur de lumière du terminal en vue d'une transmission d'un flux lumineux en espace libre, modulé en amplitude ou en fréquence lumineuse pour coder des données relatives à la transaction bancaire, et - interpréter un flux lumineux en espace libre, modulé en amplitude ou en fréquence lumineuse, que reçoit le capteur de lumière, pour en décoder des données relatives à la transaction bancaire, Le procédé comportant au moins : - Une transmission d'un premier flux (S2) du terminal du fournisseur au terminal du client, le premier flux étant modulé pour coder au moins un montant de transaction, - Sur réception du premier flux par le capteur du terminal du client, une animation de l'interface homme machine du terminal du client pour une demande de validation (S3) du montant de transaction par le client via l'interface homme machine du terminal du client (IHM2), - En cas de validation par le client, une transmission (S4) d'un deuxième flux du terminal du client au terminal du fournisseur, le deuxième flux étant modulé pour coder au moins des données de validation du client. 2. Procédé selon la revendication 1, dans lequel le terminal du client et/ou le terminal du fournisseur sont de type parmi un smartphone, une tablette, un ordinateur ou équivalent, et sont équipés d'un module de prise de vue comportant : - une diode électroluminescente pour produire un flash photographique, et - une matrice de photorécepteurs pour recevoir des données d'image, et le module logiciel pilote ladite diode électroluminescente en tant qu'émetteur de lumière en vue d'une transmission de flux lumineux modulé en amplitude et interprète un flux lumineux modulé en amplitude que reçoit la matrice de photorécepteurs. 14 3. Procédé selon la revendication 1, dans lequel le terminal du client et/ou le terminal du fournisseur sont de type parmi un smartphone, une tablette, un ordinateur ou équivalent, et sont équipés d'un écran d'affichage à diodes photoémettrices et d'un module de prise de vue comportant une matrice de photorécepteurs pour recevoir des données d'image, 5 et le module logiciel pilote l'écran d'affichage en tant qu'émetteur de lumière en vue d'une transmission de flux lumineux modulé en amplitude et interprète un flux lumineux modulé en amplitude que reçoit la matrice de photorécepteurs. 4. Procédé selon l'une des revendications précédentes, dans lequel les données relatives à la transaction 10 bancaire sont codées en binaire sur une succession de bits à « 0 » ou « 1» et les flux lumineux modulés en amplitude comportent chacun une succession d'impulsions lumineuses, une impulsion lumineuse dans ladite succession correspondant à une valeur binaire de « 1 », tandis que l'émetteur de lumière est inactif pour transmettre une ou plusieurs valeurs binaires de « 0 » entre deux impulsions. 5. Procédé selon l'une des revendications 1 à 3, dans lequel les données relatives à la transaction 15 bancaire sont codées en valeurs binaires et les flux lumineux modulés en amplitude comportent chacun une succession d'impulsions lumineuses, Et dans lequel les positions temporelles de chaque impulsion dans la succession sont définies en fonction des valeurs binaires par une modulation de position d'impulsion. 6. Procédé selon l'une des revendications 4 et 5, dans lequel une succession d'impulsions comporte 20 une succession d'occurrences avec une impulsion lumineuse ou une absence d'impulsion lumineuse, et les occurrences sont espacées d'un pas temporel inférieur à une milliseconde. 7. Procédé selon l'une des revendications précédentes, dans lequel l'un au moins des terminaux parmi le terminal du fournisseur (Ti) et le terminal du client (T2) comporte en outre une interface (COM) via un réseau de communication (RES) avec un serveur bancaire distant (SER) en vue d'obtenir du 25 serveur une autorisation de la transaction, et dans lequel les données de validation du client comportent des données d'authentification du client, en vue d'une demande d'autorisation de transaction (S5) transmise au serveur bancaire avec les données d'authentification du client via le réseau de communication. 8. Système pour la mise en oeuvre du procédé selon l'une des revendications précédentes, comportant 30 un terminal de client et un terminal de fournisseur, les terminaux étant équipés chacun de: - un émetteur de lumière (El, E2), - un capteur de lumière (Cl, C2 ; CC), et 15 - une interface homme machine (eIM1, IHM2) pour une visualisation et saisie par un utilisateur d'informations relatives à la transaction, Dans lequel chaque terminal comporte un module logiciel au moins pour : - piloter l'émetteur de lumière du terminal en vue d'une transmission d'un flux lumineux, modulé en 5 amplitude lumineuse pour coder des données relatives à la transaction bancaire, et - interpréter un flux lumineux, modulé en amplitude lumineuse, que reçoit le capteur de lumière, pour en décoder des données relatives à la transaction bancaire. 9. Terminal d'un client, d'un système selon la revendication 8, comportant un module logiciel pour la 10 mise en oeuvre du procédé selon l'une des revendications 1 à 7. 10. Terminal d'un fournisseur, d'un système selon la revendication 8, comportant un module logiciel pour la mise en oeuvre du procédé selon l'une des revendications 1 à 7. 15 11. Programme informatique comportant des instructions pour la mise en oeuvre du procédé selon l'une des revendications 1 à 7, lorsque lesdites instructions sont exécutées par un processeur.