Brevet FR3156960A1 — publié le 20250620

La présente invention concerne un procédé de dématérialisation d’un ticket de transaction suite à la mise en œuvre d’une transaction entre un marchand et un utilisateur, le procédé étant caractérisé en ce qu’il comprend la mise en œuvre par des moyens de traitement de données (31) d’un terminal mobile (3) dudit utilisateur d’étapes de : Réception d’un ensemble de données fourni par le marchand, contenant un lien vers une application web et des premières données représentatives de ladite transaction ; Appel dudit lien de sorte à mettre en œuvre ladite application web ; Transmission à un serveur (2) d’une requête de ticket de transaction dématérialisé, générée en fonction desdites premières données représentatives de ladite transaction ; Réception en retour par ladite application web dudit ticket de transaction dématérialisé. Fig. 1 Procédé de dématérialisation d’un ticket de transaction suite à la mise en œuvre d’une transaction entre un marchand et un utilisateur. DOMAINE TECHNIQUE GÉNÉRAL La présente invention se rapporte au domaine des terminaux de paiement. Plus précisément, elle concerne un procédé de dématérialisation d’un ticket de transaction suite à la mise en œuvre d’une transaction entre un marchand et un utilisateur. ETAT DE L’ART Dans le cadre de la lutte contre le gaspillage, la fin de l’impression automatique des tickets de caisse et de carte bancaire s'applique en France à partir du 1 er août 2023. Certains marchands ont ainsi mis en place une solution de tickets dématérialisés, par exemple reçus par e-mail. Le problème est qu’il faut donner au marchand son adresse ou du moins avoir un compte client chez lui. Il existe une solution plus universelle, basée sur l’association du ticket et de l’utilisateur via un jeton, dit « token CRM », calculé sur la base du PAN (Primary Account Number) de la carte bancaire, mais elle est plus complexe et nécessite d’installer une application dédiée sur un smartphone puis scanner un QR code affiché par la caisse via cette application pour enfin parvenir au ticket, ce qui rebute les utilisateurs. De plus, elle est limitée aux marchands qui ont implémenté cette technologie, et souvent des marchands différents utilisent des applications différentes (l’injection de clés uniques par marchand est nécessaire), ce qui complique encore les choses. Il serait souhaitable de disposer d’une nouvelle solution de récupération d’un ticket dématérialisé de transaction, qui soit totalement universelle, et bien plus simple à utiliser La présente invention vient améliorer la situation. PRÉSENTATION DE L’INVENTION La présente invention se rapporte donc selon un premier aspect à un procédé de dématérialisation d’un ticket de transaction suite à la mise en œuvre d’une transaction entre un marchand et un utilisateur, le procédé étant caractérisé en ce qu’il comprend la mise en œuvre par des moyens de traitement de données d’un terminal mobile dudit utilisateur d’étapes de : Réception d’un ensemble de données fourni par le marchand, contenant un lien vers une application web et des premières données représentatives de ladite transaction ; Appel dudit lien de sorte à mettre en œuvre ladite application web ; Transmission à un serveur d’une requête de ticket de transaction dématérialisé, générée en fonction desdites premières données représentatives de ladite transaction ; Réception en retour par ladite application web dudit ticket de transaction dématérialisé ; Selon des caractéristiques avantageuses et non limitatives : L’étape (b) comprend la lecture d’un identifiant de l’utilisateur stocké dans une mémoire du terminal, et l’étape (d) comprend l’association dudit identifiant de l’utilisateur audit ticket de transaction dématérialisé. Le procédé comprend une étape (e) de fourniture d’un historique de tickets de transaction dématérialisés associés audit identifiant de l’utilisateur. Ledit identifiant de l’utilisateur est contenu dans un cookie. L’étape (b) comprend, si l’identifiant de l’utilisateur n’est pas trouvé, la création d’un nouvel identifiant de l’utilisateur et son stockage dans ladite mémoire du terminal par l’application web. Ladite application web est de type PWA. L’étape (b) comprend, si l’identifiant de l’utilisateur n’est pas trouvé, une proposition d’installation de ladite application web de type PWA sur le terminal de l’utilisateur. Le serveur dispose de deuxièmes données représentatives de ladite transaction, le ticket de transaction dématérialisé étant généré par des moyens de traitement de données du serveur en fonction des premières et des deuxièmes données représentatives de ladite transaction. Ledit ensemble de données est reçu à l’étape (a) depuis un terminal de point de vente du marchand au moyen duquel ladite transaction a été mise en œuvre. L’étape (a) comprend la transmission au serveur des deuxièmes données représentatives de ladite transaction par ledit terminal de point de vente du marchand. L’étape (a) est mise en œuvre par lecture d’un code QR encapsulant ledit ensemble de données ou via une communication sans-fil de proximité. Ledit terminal de point de vente du marchand comprend un terminal de paiement électronique, ladite transaction étant une transaction de paiement par carte bancaire via ledit terminal de paiement électronique, l’étape (a) comprenant l’affichage par le terminal de paiement électronique dudit code QR ou l’émission par le terminal de paiement électronique dudit ensemble de données au terminal via ladite communication sans-fil de proximité. Selon un deuxième aspect, l’invention concerne un terminal mobile d’un utilisateur, caractérisé en ce que le terminal comprend des moyens de traitement de données configurés pour, en vue de la dématérialisation d’un ticket de transaction suite à la mise en œuvre d’une transaction entre un marchand et ledit utilisateur : Recevoir un ensemble de données fourni par le marchand, contenant un lien vers une application web et des premières données représentatives de ladite transaction ; appeler ledit lien de sorte à mettre en œuvre ladite application web ; transmettre à un serveur une requête de ticket de transaction dématérialisé, générée en fonction desdites premières données représentatives de ladite transaction ; Recevoir en retour dans ladite application web ledit ticket de transaction dématérialisé. Selon un troisième aspect, l’invention concerne un système de dématérialisation d’un ticket de transaction suite à la mise en œuvre d’une transaction entre un marchand et un utilisateur, comprenant un serveur et un terminal de point de vente du marchand pour la mise en œuvre de ladite transaction, caractérisé en ce que : Le terminal de point de vente comprend des moyens de traitement de données configurés pour transférer, à un terminal mobile dudit utilisateur, un ensemble de données fourni par le marchand, contenant un lien vers une application web et des premières données représentatives de ladite transaction ; en vue de l’appel dudit lien de sorte à mettre en œuvre ladite application web par le terminal mobile ; Le serveur comprend des moyens de traitement de données configuré pour recevoir depuis ladite application web une requête de ticket de transaction dématérialisé, et transmettre en retour à ladite application web ledit ticket de transaction dématérialisé, généré en fonction de la requête et de deuxièmes données représentatives de ladite transaction. Selon un quatrième et un cinquième aspects, l’invention concerne un produit programme d’ordinateur comprenant des instructions de code pour l’exécution d’un procédé selon le premiers aspect de dématérialisation d’un ticket de transaction suite à la mise en œuvre d’une transaction entre un marchand et un utilisateur ; et un moyen de stockage lisible par un équipement informatique sur lequel est enregistré un produit programme d’ordinateur comprenant des instructions de code pour l’exécution d’un procédé selon le premier aspect de dématérialisation d’un ticket de transaction suite à la mise en œuvre d’une transaction entre un marchand et un utilisateur. PRÉSENTATION DES FIGURES D’autres caractéristiques et avantages de la présente invention apparaîtront à la lecture de la description qui va suivre d’un mode de réalisation préférentiel. Cette description sera donnée en référence aux dessins annexés dans lesquels : FIG. 1 la FIG. 1 est un schéma d’un système pour la mise en œuvre du procédé selon l’invention ; FIG. 2 la FIG. 2 est un logigramme illustrant les étapes d’un mode de réalisation du procédé selon l’invention. DESCRIPTION DÉTAILLÉE Architecture En référence à la FIG. 1 , la présente invention concerne un procédé de dématérialisation d’un ticket de transaction suite à la mise en œuvre d’une transaction entre un marchand et un utilisateur. Par « dématérialisation », on entend obtention d’une version numérique du ticket (dit ticket dématérialisé) sur un terminal mobile 3 de l’utilisateur, par opposition à une version papier. A noter qu’il tout à fait possible que le ticket papier soit en outre imprimé et donné à l’utilisateur (s’il le réclame), mais de manière préférée le présent procédé remplace complètement le ticket papier. Le ticket de transaction dont il est question peut être tout ticket dont l’émission est d’intérêt suite à la transaction, ce que l’on appelle généralement un « ticket de paiement », avantageusement un reçu de ladite de transaction. Il s’agit typiquement un ticket de caisse ou un ticket de carte bancaire (dans le cas où la transaction est un paiement par carte bancaire), mais ce peut être également un ticket relatif à un échec de paiement ou une opération annulée, un ticket de crédit, voire même un ticket valant remise promotionnelle, etc. A noter que la transaction est typiquement un paiement par carte bancaire de l’utilisateur via un terminal de paiement électronique 10 (TPE) du marchand (avec ou sans contact sur le TPE 10), la carte bancaire étant potentiellement dématérialisée sur le terminal mobile 3 de l’utilisateur, mais il peut tout à fait s’agir d’une transaction par chèque ou en liquide (et alors il n’y a pas de TPE 10). Le présent procédé est mis en œuvre par le terminal 3, et implique un serveur 2 généralement distant et connecté au terminal 3, ainsi qu’avantageusement à un terminal de point de vente 1 (TPV) du marchand, par un réseau 20 tel que le réseau internet. Ledit TPV 1, communément appelé caisse enregistreuse est l’équipement permettant en pratique ladite transaction. Il comprend des moyens de traitement de données 11, l’éventuel TPE 10 et/ou des moyens d’interface 13 (comme l’on verra, ce peut être un écran et/ou des moyens de communication sans fil de proximité, typiquement un lecteur NFC/RFID). A noter qu’en présence d’un TPE 10, les moyens de traitement de données 11 et les moyens d’interface 13 du TPV 1 peuvent être confondus avec le TPE 10 (i.e. on utilise le processeur, l’écran du TPE 10 et son lecteur NFC pour les paiements sans contact). Le serveur 2 dispose également de moyens de traitement de données 21 (typiquement un processeur) et de moyens de stockage de données 22 (une mémoire, par exemple un disque dur). Le terminal mobile 3 est un terminal personnel à l’utilisateur, en particulier un smartphone, le cas échéant dématérialisant une carte bancaire et pouvant être utilisé pour la mise en œuvre de la transaction. Il dispose également de moyens de traitement de données 31 (typiquement un processeur) et de moyens de stockage de données 32 (une mémoire, par exemple flash), et potentiellement une caméra. Procédé En référence à la FIG. 2 , le présent procédé est mis en œuvre par les moyens de traitement de données 31 du terminal mobile 3, et commence par une étape (a) de réception d’un ensemble de données fourni par le marchand (avantageusement depuis le TPV 1 du marchand), contenant un lien vers une application web et des premières données représentatives de ladite transaction. Cette étape peut être mise en œuvre de manière connue, par lecture d’un code QR ou par communication sans-fil de proximité, en utilisant les moyens du TPV 1 : Selon un premier mode de réalisation, un code QR encapsulant ledit ensemble de données est affiché par l’interface 13 du TPV 1 ou directement le TPE 10. L’utilisateur met en œuvre l’étape (a) en scannant ledit code QR avec une caméra de son terminal 3. Selon un deuxième mode de réalisation, ledit ensemble de données est transmis au terminal 3 communication sans-fil de proximité. L’utilisateur met en œuvre l’étape (a) en approchant son terminal de l’interface 13. Dans un mode de réalisation particulièrement préféré, l’utilisateur met en œuvre la transaction avec son terminal 3 sur le TPE 10 en sans contact (via une carte bancaire dématérialisé), et l’étape (a) est mise en œuvre directement dans la foulée de la transaction, en utilisant la même communication sans-fil de proximité, i.e. l’utilisateur approche son terminal 3 pour payer, la transaction est mise en œuvre et il reçoit directement ledit ensemble de données contenant le lien vers l’application web et les premières données représentatives de ladite transaction. La présente invention ne sera limitée à aucune façon de mettre en œuvre l’étape (a). Il peut d’ailleurs y avoir plusieurs façons mises en œuvre simultanément de recevoir ledit ensemble de données, ce qui est le cas dans la FIG. 1 (affiche du code QR sur l’écran 13 + communication NFC avec le TPE 10). A noter que l’étape (a) peut comprendre une invitation préalable de l’utilisateur par le TPV 1 (sous la forme d’un pictogramme ou d’un message visuel et/ou audio) à accomplir une action pour déclencher la réception dudit ensemble de données et donc la dématérialisation du ticket de transaction, par exemple « Veuillez scanner le code QR affiché par la caisse pour récupérer votre ticket de caisse dématérialisé ». L’utilisation d’une application web évite toute application mobile spécifique à un OS et toute installation complexe, puisque les application web sont supportées par tous les navigateurs de manière native sans intervention sur le terminal 3. De plus, comme l’on verra plus loin, l’utilisation astucieuse d’un témoin de connexion ou « cookie », permise par tout navigateur web, permet d’éviter toute utilisation d’un service de tokenisation CRM. A ce titre, ledit lien vers l’application web contenu dans l’ensemble de données réceptionné à l’étape (a) est défini par une adresse URL (Uniform Resource Locator). Un appel dudit lien vient « exécuter » l’application dans un navigateur en accédant à la page web distante. De manière préférée, ladite application web est de type PWA (progressive web app, en français application web progressive). Une PWA est une application web permettant une expérience utilisateur similaire à celle d'une application mobile, sans les contraintes de cette dernière. Plus précisément, les pages web de l’application apparaissent à l'utilisateur sur son terminal 3 de la même manière que les applications mobiles, de sorte que ce dernier ne fait pas visuellement la différence. On peut même « installer » une application web PWA sur le terminal 3, installation consistant en la création d’un raccourci vers l’URL de l’application web (avantageusement ledit lien défini ci-avant), une icône étant alors ajoutée sur l’écran d’accueil du terminal 3 de la même manière que pour toute application ordinaire. Si l’utilisateur appuie sur cette icône de la PWA, c’est en fait le navigateur qui se lance avec un appel dudit raccourci URL. De manière préférée, ledit lien est indépendant de la transaction et donc desdites premières données représentatives de ladite transaction. Cela permet donc des paiements de nature différente (carte bancaire, argent liquide, etc.) chez des marchands différents, de manière totalement universelle. On rappelle que jusque-là le mécanisme de dématérialisation était spécifique à une carte bancaire et un marchand du fait de l’utilisation de clés pour lier l’utilisateur à un PAN. Lesdites premières données de la transaction comprennent préférentiellement au moins un identifiant du marchand et un identifiant unique de transaction, et potentiellement une partie des informations constituant le ticket, variant selon le type de ticket à dématérialiser (montant, horodatage, informations de paiement, détail des achats, etc.). On a de manière préférée des deuxièmes données représentative de la transaction, avec les conditions suivantes : L’ensemble des premières et des deuxièmes données contient toutes les informations du ticket (i.e. on peut générer intégralement le ticket à partir des premières et deuxièmes données) ; L’intersection des premières et deuxièmes données est non vide, i.e. on a des données communes, par exemple un identifiant unique de la transaction, de sorte à permettre le lien entre les premières et les deuxièmes données. On suppose que le serveur 2 dispose desdites deuxièmes données représentatives de ladite transaction. A ce titre, l’étape (a) peut également comprendre la réception par le serveur 2, avantageusement également depuis le TPV 1, via le réseau 20, desdites deuxièmes données représentatives de ladite transaction. Cette transmission suit le paiement et est typiquement concomitante avec l’affichage d’un code QR ou autre Dans une étape (b), ledit lien est appelé par les moyens de traitement de données 31 du terminal 3 de sorte à mettre en œuvre ladite application web. Comme expliqué, de manière connue, l’appel du lien lance automatiquement le navigateur et l’affichage des pages qui compose l’application web, de manière identique à une application mobile normale si c’est une application web PWA. L’étape (b) peut différer selon si c’est la première fois que l’utilisateur met en œuvre le présent procédé sur ce terminal 3. De manière préférée, l’étape (b) comprend à ce titre la lecture (s’il existe) d’un identifiant de l’utilisateur stocké dans une mémoire 32 du terminal 3. On suppose que si le procédé a déjà été mis en œuvre, un tel identifiant existe. Si au contraire, l’identifiant de l’utilisateur n’est pas trouvé, l’étape (b) comprend avantageusement la création d’un nouvel identifiant de l’utilisateur et son stockage dans ladite mémoire 32 du terminal 3. Ledit identifiant de l’utilisateur est très préférentiellement contenu dans un cookie : si le cookie existe, le navigateur y accède loirs de la mise en œuvre de l’application web, et s’il n’existe pas il le crée, de manière totalement transparente pour l’utilisateur, et il y stocke ledit identifiant utilisateur, par exemple généré aléatoirement. A noter que si l’utilisateur refuse ou efface ses cookies, ce n’est pas grave, la seule conséquence sera qu’à la prochaine mise en œuvre du présent procédé l’application web ne trouvera pas d’identifiant utilisateur (voir plus loin). A noter que l’étape (b) peut comprendre, si l’identifiant de l’utilisateur n’est pas trouvé, une proposition d’installation de ladite application web de type PWA sur le terminal 1 de l’utilisateur (i.e. la création d’un raccourci), par exemple grâce à un fichier manifeste. Si l’utilisateur appelle le lien alors qu’un raccourci est déjà créé, cela l’ouvre directement. Ensuite, le procédé comprend une étape (c) de transmission au serveur 2 d’une requête de ticket de transaction dématérialisé, générée en fonction desdites premières données représentatives de ladite transaction. Tout se passe dans ladite application web, qui va interagir avec le serveur 2, typiquement en lui fournissant tout ou partie des premières données représentatives de ladite transaction, au moins celles dont il a besoin pour faire le lien avec les deuxièmes données, et celles qui lui manqueraient pour générer le ticket dématérialisé. On suppose que le serveur 2 est capable de générer le ticket dématérialisé en fonction de toutes les données dont il dispose, il s’agit essentiellement de mise en forme, par exemple en HTML ou en PDF. A noter que l’étape (c) peut être réalisée automatiquement par l’application web dès que cette dernière est mise en œuvre suite à l’étape (b), i.e. le ticket est directement requis et récupéré suite à l’action de l’utilisateur à l’étape (a), soit elle est mise en œuvre suite à une action de l’utilisateur dans l’application web, par exemple appuyer sur un bouton « récupérer le ticket ». Dans tous les cas, toutes les informations nécessaires pour interagir avec le serveur 2 sont fournies par ladite application web, l’utilisateur n’a rien à faire, et le terminal 3 n’a pas besoin d’être préconfiguré en aucune façon (les informations reçues à l’étape (a) suffisent pour mettre en œuvre toute la suite du procédé). En retour, ladite application web reçoit depuis le serveur 2 ledit ticket de transaction dématérialisé dans une étape (d), pour affichage sur le terminal 3, et le cas échéant stockage local sur les moyens de stockage 32 du terminal 3. A noter qu’en complément ledit ticket reste avantageusement stocké sur des moyens de stockage 22 du serveur 2, en vue d’une nouvelle consultation ultérieure. A ce titre, l’étape (d) peut comprendre la génération par les moyens de traitement de données 21 du serveur 2 en fonction des données de la requête et les deuxièmes données représentatives de la transaction dont il dispose. De manière préférée, si l’utilisateur a accepté le cookie, l’étape (d) comprend l’association dudit identifiant de l’utilisateur audit ticket de transaction dématérialisé, sur le serveur 2 et/ou le terminal 3. Cela permet un accès aisé aux précédents tickets dématérialisés : le procédé comprend avantageusement une étape (e) de fourniture d’un historique de tickets de transaction dématérialisés associés audit identifiant de l’utilisateur, par exemple au moyen d’un bouton ou d’une page dédiée dans l’application web. Dans la mesure où l’identifiant de l’utilisateur est une donnée stockée uniquement sur son terminal 3 et générée de manière aléatoire, personne d’autre que lui n’est capable d’accéder à ses tickets. Comme expliqué, si l’utilisateur efface son cookie au bout d’un certain temps, il perd son identifiant et donc cet historique, ce qui fait que les vieux tickets concernés ne sont plus accessibles par personne, et un nouvel identifiant sera créé à la prochaine dématérialisation. Terminal et système de dématérialisation Selon un deuxième aspect, l’invention concerne le terminal mobile 3 d’un utilisateur pour la mise en œuvre du procédé selon le premier aspect. Le terminal 3 comprend des moyens de traitement de données 31, et généralement une mémoire 32 et possiblement une caméra. Les moyens de traitement de données 31 sont configurés pour, en vue de la dématérialisation d’un ticket de transaction suite à la mise en œuvre d’une transaction entre un marchand et ledit utilisateur : Recevoir un ensemble de données fourni par le marchand, contenant un lien vers une application web et des premières données représentatives de ladite transaction (par exemple en scannant un code QR encapsulant ledit ensemble de données ou en acceptant un communication sans-fil de proximité) ; appeler ledit lien de sorte à mettre en œuvre ladite application web ; transmettre à un serveur 2 (auquel il est connecté via le réseau 20) une requête de ticket de transaction dématérialisé, générée en fonction desdites premières données représentatives de ladite transaction ; Recevoir en retour dans ladite application web ledit ticket de transaction dématérialisé ; On note que c’est en pratique la réception dudit ensemble de données fourni par le marchand, contenant un lien vers une application web et des premières données représentatives de ladite transaction qui entraîne la configuration du terminal 3 pour mettre en œuvre les autres actions. Selon un troisième aspect, l’invention concerne le système de dématérialisation d’un ticket de transaction suite à la mise en œuvre d’une transaction entre un marchand et un utilisateur également pour la mise en œuvre du procédé selon le premier aspect. Il comprend un serveur 2 et un terminal de point de vente 1 du marchand pour la mise en œuvre de ladite transaction, le terminal de point de vente 1 (TPV) comprennent typiquement un TPE 10 et/ou une interface 13. Le TPV 1 (ou en particulier le TPE 10) est configuré pour transférer à un terminal mobile 3 dudit utilisateur (ou du moins « mettre à disposition », car c’est au final à l’utilisateur de faire le nécessaire pour permettre le transfert), un ensemble de données fourni par le marchand, contenant un lien vers une application web et des premières données représentatives de ladite transaction (par exemple en affichant un code QR à scanner par le terminal 3 ou en autorisant une communication sans-fil de proximité avec le terminal 3) ; en vue de l’appel dudit lien de sorte à mettre en œuvre ladite application web par le terminal mobile 3. Le TPV 1 est généralement également configurer pour transmettre au serveur 2 des deuxièmes données représentatives de ladite transaction. Le serveur (2) comprend des moyens de traitement de données 21 configuré pour recevoir depuis ladite application web une requête de ticket de paie transaction ment dématérialisé, et transmettre en retour à ladite application web ledit ticket de transaction dématérialisé, généré en fonction de la requête (qui contient en général une partie des premières données représentatives de la transaction) et de deuxièmes données représentatives de ladite transaction. Ledit système de dématérialisation comprend avantageusement au moins un terminal mobile 3 selon le deuxième aspect. Produit programme d’ordinateur Selon un quatrième et un cinquième aspects, l’invention concerne un produit programme d’ordinateur comprenant des instructions de code pour l’exécution (sur les moyens de traitement de donnés 11, 21, 31 du TPV 1, du serveur 2 et/ou du terminal 3) d’un procédé selon le premier aspect de dématérialisation d’un ticket de transaction suite à la mise en œuvre d’une transaction entre un marchand et un utilisateur, ainsi que des moyens de stockage lisibles par un équipement informatique (par exemple les moyens de stockage de données 12, 22, 33 du TPV 1, du serveur 2 et/ou du terminal 3) sur lequel on trouve ce produit programme d’ordinateur. Procédé de dématérialisation d’un ticket de transaction suite à la mise en œuvre d’une transaction entre un marchand et un utilisateur, le procédé étant caractérisé en ce qu’il comprend la mise en œuvre par des moyens de traitement de données (31) d’un terminal mobile (3) dudit utilisateur d’étapes de : Réception d’un ensemble de données fourni par le marchand, contenant un lien vers une application web et des premières données représentatives de ladite transaction ; Appel dudit lien de sorte à mettre en œuvre ladite application web ; Transmission à un serveur (2) d’une requête de ticket de transaction dématérialisé, générée en fonction desdites premières données représentatives de ladite transaction ; Réception en retour par ladite application web dudit ticket de transaction dématérialisé. Procédé selon la revendication 1, dans lequel l’étape (b) comprend la lecture d’un identifiant de l’utilisateur stocké dans une mémoire (32) du terminal (3), et l’étape (d) comprend l’association dudit identifiant de l’utilisateur audit ticket de transaction dématérialisé. Procédé selon la revendication 2, dans lequel le procédé comprend une étape (e) de fourniture d’un historique de tickets de transaction dématérialisés associés audit identifiant de l’utilisateur. Procédé selon l’une des revendications 2 et 3, dans lequel ledit identifiant de l’utilisateur est contenu dans un cookie. Procédé selon l’une des revendications 2 à 4, dans lequel l’étape (b) comprend, si l’identifiant de l’utilisateur n’est pas trouvé, la création d’un nouvel identifiant de l’utilisateur et son stockage dans ladite mémoire (32) du terminal (1) par l’application web. Procédé selon l’une des revendications 1 et 5, dans lequel ladite application web est de type PWA. Procédé selon les revendications 5 et 6 en combinaison, dans lequel l’étape (b) comprend, si l’identifiant de l’utilisateur n’est pas trouvé, une proposition d’installation de ladite application web de type PWA sur le terminal (1) de l’utilisateur. Procédé selon l’une des revendications 1 à 7, dans lequel le serveur (2) dispose de deuxièmes données représentatives de ladite transaction, le ticket de transaction dématérialisé étant généré par des moyens de traitement de données (22) du serveur (2) en fonction des premières et des deuxièmes données représentatives de ladite transaction. Procédé selon l’une des revendications 1 à 8, dans lequel ledit ensemble de données est reçu à l’étape (a) depuis un terminal de point de vente (1) du marchand au moyen duquel ladite transaction a été mise en œuvre. Procédé selon les revendications 8 et 9 en combinaison, dans lequel l’étape (a) comprend la transmission au serveur (2) des deuxièmes données représentatives de ladite transaction par ledit terminal de point de vente (1) du marchand. Procédé selon l’une des revendications 1 à 10, dans lequel l’étape (a) est mise en œuvre par lecture d’un code QR encapsulant ledit ensemble de données ou via une communication sans-fil de proximité. Procédé selon les revendications 9 et 11 en combinaison, dans lequel ledit terminal de point de vente (1) du marchand comprend un terminal de paiement électronique (10), ladite transaction étant une transaction de paiement par carte bancaire via ledit terminal de paiement électronique (10), l’étape (a) comprenant l’affichage par le terminal de paiement électronique (10) dudit code QR ou l’émission par le terminal de paiement électronique (10) dudit ensemble de données au terminal (3) via ladite communication sans-fil de proximité. Terminal mobile (3) d’un utilisateur, caractérisé en ce que le terminal (3) comprend des moyens de traitement de données (31) configurés pour, en vue de la dématérialisation d’un ticket de transaction suite à la mise en œuvre d’une transaction entre un marchand et ledit utilisateur : Recevoir un ensemble de données fourni par le marchand, contenant un lien vers une application web et des premières données représentatives de ladite transaction ; appeler ledit lien de sorte à mettre en œuvre ladite application web ; transmettre à un serveur (2) une requête de ticket de transaction dématérialisé, générée en fonction desdites premières données représentatives de ladite transaction ; Recevoir en retour dans ladite application web ledit ticket de transaction dématérialisé. Système de dématérialisation d’un ticket de transaction suite à la mise en œuvre d’une transaction entre un marchand et un utilisateur, comprenant un serveur (2) et un terminal de point de vente (1) du marchand pour la mise en œuvre de ladite transaction, caractérisé en ce que : Le terminal de point de vente (1) comprend des moyens de traitement de données (11) configurés pour transférer, à un terminal mobile (3) dudit utilisateur, un ensemble de données fourni par le marchand, contenant un lien vers une application web et des premières données représentatives de ladite transaction ; en vue de l’appel dudit lien de sorte à mettre en œuvre ladite application web par le terminal mobile (3) ; Le serveur (2) comprend des moyens de traitement de données (21) configuré pour recevoir depuis ladite application web une requête de ticket de transaction dématérialisé, et transmettre en retour à ladite application web ledit ticket de transaction dématérialisé, généré en fonction de la requête et de deuxièmes données représentatives de ladite transaction. Produit programme d’ordinateur comprenant des instructions de code pour l’exécution d’un procédé selon l’une des revendications 1 à 12 de dématérialisation d’un ticket de transaction suite à la mise en œuvre d’une transaction entre un marchand et un utilisateur, lorsque ledit programme est exécuté sur un ordinateur. Moyen de stockage lisible par un équipement informatique sur lequel est enregistré un produit programme d’ordinateur comprenant des instructions de code pour l’exécution d’un procédé selon l’une des revendications 1 à 12 de dématérialisation d’un ticket de transaction suite à la mise en œuvre d’une transaction entre un marchand et un utilisateur.