Brevet FR3147892A1 — publié le 20241018

Procédé de traitement d’un message électronique, système de traitement de données associé L’invention concerne un procédé de traitement d’un message électronique destiné à un terminal récepteur (120), ledit message comportant un code graphique encodant des données, dites « données d’accès », représentatives d’un accès à une ressource informatique, ledit procédé comportant des étapes de : - décodage (E70) des données d’accès, - génération (E90) d’un objet interactif dans le message électronique à partir des données d’accès décodées, ledit objet interactif étant configuré pour donner accès à la ressource informatique lorsqu’une interaction est réalisée avec ledit objet interactif. Figure pour l’abrégé : Fig. 3 Procédé de traitement d’un message électronique, système de traitement de données associé La présente invention appartient au domaine général des télécommunications. Elle concerne plus particulièrement un procédé de traitement d’un message électronique destiné à terminal récepteur, ainsi qu’un système de traitement de données configuré pour mettre en œuvre ledit procédé. L’invention trouve une application particulièrement avantageuse, bien que nullement limitative, dans le contexte d’un terminal récepteur de type téléphone intelligent (« smartphone » en anglais). Le code QR, ou code à réponse rapide (« QR code » ou « Quick Response code » en anglais) a été développé au milieu des années 90, et a connu par la suite une utilisation toujours plus importante, qui s’est notamment accélérée avec l’essor massif des usages numériques, en particulier ceux mis en œuvre au moyen d’un smartphone. Un cas typique d’utilisation d’un code QR est de générer ce dernier afin qu’il encode une chaîne de caractères identifiant une ressource de données disponible sur un réseau informatique. A titre d’exemple, il peut classiquement s’agir d’un code QR encodant un identifiant uniforme de ressource URI (« Uniform Ressource Identifier » en anglais) configuré pour donner accès à une ressource informatique du réseau Internet, comme par exemple une page web. En pratique, une fois généré, une utilisation traditionnelle du code QR consiste à afficher ce dernier au moyen d’un objet physique (mur, porte, table, écran publicitaire, etc.) distinct d’un smartphone d’un utilisateur et équipé d’une application logicielle configurée pour la lecture de codes QR. De cette manière, l’utilisateur peut scanner le code QR en question et avoir accès à la ressource informatique correspondante. Si cette manière conventionnelle de procéder ne pose aucun souci pratique d’exécution, il en est tout autrement lorsqu’un code QR est affiché non pas via un objet physique du monde réel distinct du smartphone d’un utilisateur, mais est au contraire affiché par le smartphone lui-même, par exemple lorsque le code QR est incorporé dans un message électronique, comme par un exemple un courriel ou bien un message multimédia de téléphonie mobile encore couramment désigné « MMS » (« Multimedia Messaging Service » an anglais), et est visionné au moyen de l’écran dudit smartphone. En effet, dans ce cas, on comprend que le smartphone ne peut plus être utilisé pour scanner le code QR contenu dans le message. En conséquence, il n’est pas possible d’accéder à la ressource informatique, ce qui rompt l’expérience utilisateur. En définitive, le seul moyen actuel pour remédier à cette problématique consiste, pour un utilisateur, à disposer à portée de main d’un second équipement (smartphone, tablette, etc.) apte à scanner et décoder le code QR contenu dans le message électronique affiché sur l’écran du smartphone. Outre le fait d’être onéreuse, cette solution est particulièrement pénible à mettre en œuvre, si bien qu’en définitive le risque que la ressource informatique ne soit pas consultée est très élevé. La présente invention a pour objectif de remédier à tout ou partie des inconvénients de l’art antérieur, notamment ceux exposés ci-avant, en proposant une solution qui permette d’accéder à une ressource informatique identifiée par un code graphique contenu dans un message électronique de manière plus efficace que les solutions de l’état de la technique. A cet effet, et selon un premier aspect, l’invention concerne un procédé de traitement d’un message électronique destiné à un terminal récepteur, ledit message comportant un code graphique encodant des données, dites « données d’accès », représentatives d’un accès à une ressource informatique, ledit procédé comportant des étapes de : - décodage des données d’accès, - génération d’un objet interactif dans le message électronique à partir des données d’accès décodées, ledit objet interactif étant configuré pour donner accès à la ressource informatique lorsqu’une interaction est réalisée avec ledit objet interactif. Par exemple, l’objet interactif peut être un hyperlien d’accès à la ressource informatique, l’hyperlien étant généré de sorte à être attaché au code graphique et ainsi rendre le code graphique cliquable pour accéder à la ressource informatique. Ainsi, le code graphique contenu dans le message électronique qui, au départ, n’est qu’une image inerte devient, grâce au procédé selon l’invention, une image active avec laquelle il est possible d’interagir par clic. Par « clic », on fait classiquement référence à une interaction qui peut être directe (i.e. une pression du doigt), par exemple sur un écran tactile d’un smartphone, ou bien indirecte, c’est-à-dire au moyen d’un dispositif manié par un utilisateur, comme par exemple une souris ou un stylet. En d’autres termes, le procédé selon l’invention permet, de manière automatique, d’interpréter le code graphique, d’en extraire l’information d’accès à la ressource informatique, et de coupler cette information avec le code graphique. Ainsi, un utilisateur qui consulte le message électronique via le terminal récepteur n’a donc plus besoin de se munir d’un autre équipement pour lire (scanner) le code graphique. Cela facilite donc considérablement l’accessibilité à la ressource de données, et donc accroit fortement la probabilité qu’elle soit consultée. Par ailleurs, le fait de ne pas être obligé de se munir d’un autre équipement participe avantageusement à fournir une solution peu onéreuse du point de vue matériel. Il importe de noter que l’objet interactif ne se limite pas au seul hyperlien destiné à être attaché au code graphique. En effet, il peut également s’agir d’un objet d’une autre nature non destiné à être attaché au code graphique, mais à être incorporé/affiché dans le message électronique en complément du code graphique lors de l’étape de génération dudit autre objet interactif. A titre d’exemple nullement limitatif, un tel autre objet interactif peut correspondre à un symbole, une icône, une image, une photo, etc. En outre, rien n’exclut non plus d’avoir dans le message électronique non seulement un code graphique cliquable comme décrit ci-avant mais également un tel autre objet interactif. Dans des modes particuliers de mise en œuvre, le procédé de traitement peut comporter en outre l’une ou plusieurs des caractéristiques suivantes, prises isolément ou selon toutes les combinaisons techniquement possibles. Dans des modes particuliers de mise en œuvre, le code graphique est l’un quelconque parmi : un code QR, un mini code QR, un code-barres, une matrice de données. Dans des modes particuliers de mise en œuvre, les données d’accès sont représentatives d’un identifiant uniforme de ressource configuré pour donner accès à une ressource informatique du réseau Internet. Dans des modes particuliers de mise en œuvre, ledit procédé comporte en outre, avant la génération de l’objet interactif, des étapes de : - vérification du respect d’un critère de sécurité par la ressource informatique, - si la vérification n’est pas satisfaite, émission d’un message d’alerte. Ces dispositions sont avantageuses dans la mesure où elles permettent d’améliorer la sécurité d’accès à la ressource informatique. Par exemple, le critère de sécurité peut être configuré pour permettre de vérifier que la ressource informatique n’est pas susceptible d’infecter avec un virus le terminal récepteur d’un utilisateur qui consulte le message électronique. Alternativement, le critère de sécurité peut être configuré pour permettre de vérifier que la consultation de la ressource informatique n’est pas susceptible de déclencher un processus d’hameçonnage (« phishing » en anglais) d’informations personnelles de l’utilisateur qui consulte le message électronique. D’une manière générale, aucune limitation n’est attachée à la nature du critère de sécurité, la notion de « sécurité » étant, dans le cadre de la présente invention, caractéristique de tout ce qui est dépourvu de risques et/ou de dangers pour l’intégrité du terminal récepteur et/ou de l’utilisateur du terminal récepteur. En conséquence, aucune limitation n’est non plus attachée à la manière dont le critère peut être vérifié (e.g. consultation d’une base de données listant des ressources de données suspicieuses, faire un diagnostic réseau, par exemple au moyen d’un test de ping d’une ressource de données, etc.). Dans des modes particuliers de mise en œuvre, ledit procédé comporte en outre, suite à une transmission du message électronique au terminal récepteur, des étapes de : - réception, en provenance du terminal récepteur, d’une notification indiquant qu’une interaction a été réalisée avec l’objet interactif, - transmission de la notification à destination d’un terminal émetteur du message électronique, - redirection du terminal récepteur vers la ressource informatique en utilisant les données d’accès. Dans des modes particuliers de mise en œuvre, ledit procédé comporte en outre, après la génération de l’objet interactif, une étape de transmission du message électronique au terminal récepteur. Dans des modes particuliers de mise en œuvre, ledit procédé comporte en outre une étape d’émission d’une notification, ladite notification indiquant que le message électronique a été modifié suite à la génération de l’objet interactif. Dans des modes particuliers de mise en œuvre, ledit procédé comporte en outre, sur réception de la notification, une étape d’incrémentation d’un compteur et/ou d’horodatage de ladite notification. Le fait de réaliser une telle incrémentation auprès d’un compteur permet avantageusement d’établir des statistiques relatives à l’utilisation de services pouvant être proposés par une plateforme de services lorsque celle-ci exécute tout ou partie du procédé de traitement. L’horodatage permet quant à lui de garder une preuve datée de l’utilisation des services ainsi proposés. En outre, le fait de combiner un comptage par incrémentation et un horodatage permet d’améliorer la sécurité des échanges dans la mesure où il devient possible de mettre en œuvre des outils de détection d’intrusion, comme par exemple une attaque par déni de service (« Distributed Denial of Service » ou « DDoS » en anglais). Dans des modes particuliers de mise en œuvre, le message électronique est un courriel, un message multimédia de téléphonie mobile ou bien un message échangé sur une plateforme de messagerie instantanée. Selon un deuxième aspect, l’invention concerne un programme d’ordinateur comportant des instructions pour la mise en œuvre d’au moins les étapes de décodage et de génération d’un procédé de traitement de données selon l’invention lorsque ledit programme d’ordinateur est exécuté par un ordinateur. Ce programme peut utiliser n’importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n’importe quelle autre forme souhaitable. Selon un troisième aspect, l’invention concerne un support d’informations ou d’enregistrement lisible par un ordinateur sur lequel est enregistré un programme d’ordinateur selon l’invention. Le support d'informations ou d’enregistrement peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple un disque dur. D'autre part, le support d'informations ou d’enregistrement peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet. Alternativement, le support d'informations ou d’enregistrement peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question. Selon un quatrième aspect, l’invention concerne un dispositif de traitement de données comportant des moyens configurés pour mettre en œuvre au moins les étapes de décodage et de génération d’un procédé de traitement d’un message électronique selon l’invention. Dans des modes particuliers de réalisation, le dispositif de traitement de données peut comporter en outre l’une ou plusieurs des caractéristiques suivantes, prises isolément ou selon toutes les combinaisons techniquement possibles. Dans des modes particuliers de réalisation, ledit dispositif est intégré à l’un quelconque parmi : - une plateforme de services opérée par un opérateur de communication, - une plateforme de messagerie opérée par un opérateur de messagerie, - un terminal émetteur du message électronique, - un terminal récepteur auquel le message électronique est destiné. Dans des modes particuliers de réalisation, les entités opérant la plateforme de services et la plateforme de messagerie sont différentes ou identiques Selon un cinquième aspect, l’invention concerne un système de traitement de données comportant des moyens configurés pour mettre en œuvre un procédé de traitement de données selon l’invention. Dans des modes particuliers de réalisation, le système de traitement de données peut comporter en outre l’une ou plusieurs des caractéristiques suivantes, prises isolément ou selon toutes les combinaisons techniquement possibles. Dans des modes particuliers de réalisation, ledit système comporte un dispositif de traitement de données appartenant à une plateforme de services opérée par un opérateur de communication, ledit dispositif de traitement de données étant configuré pour mettre en œuvre toutes les étapes du procédé de traitement. Dans des modes particuliers de réalisation, ledit système comporte un terminal émetteur, un terminal récepteur, un premier dispositif de traitement de données appartenant à une plateforme de services opérée par un opérateur de communication, et/ou un deuxième dispositif de traitement de données appartenant à une plateforme de messagerie opérée par un opérateur de messagerie, et dans lequel : - les étapes de détection, d’analyse et de génération sont mises en œuvre par le deuxième dispositif de traitement de données, ou par le terminal émetteur, ou par le terminal récepteur, et - lorsque le procédé comporte des étapes de vérification et de transmission d’un message d’alerte, lesdites étapes sont mises en œuvre par le premier dispositif de traitement de données ou par le deuxième dispositif de traitement de données, - lorsque le procédé comporte des étapes de réception d’une notification indiquant que le code graphique a été cliqué, de transmission de la notification et de redirection du terminal récepteur, lesdites étapes sont mises en œuvre par le premier dispositif de traitement de données ou par le deuxième dispositif de traitement de données, - lorsque le procédé comporte une étape de transmission du message électronique au terminal récepteur, ladite est mise en œuvre par le deuxième dispositif de traitement de données, - lorsque le procédé comporte une étape d’émission de la notification indiquant que le message électronique a été modifié, ladite étape est mise en œuvre par le deuxième dispositif de traitement de données, - lorsque le procédé comporte une étape d’incrémentation et/ou d’horodatage, ladite étape est mise en œuvre par le premier dispositif de traitement de données. Dans des modes particuliers de réalisation, les entités opérant la plateforme de services et la plateforme de messagerie sont différentes ou identiques. D’autres caractéristiques et avantages de la présente invention ressortiront de la description faite ci-dessous, en référence aux dessins annexés qui en illustrent un exemple de réalisation dépourvu de tout caractère limitatif. Sur les figures : la représente schématiquement un mode particulier de réalisation d’un système de traitement de données selon l’invention, ledit système comportant un dispositif de traitement de données ; la représente schématiquement un exemple d’architecture matérielle du dispositif de traitement de données inclus dans le système de la ; la représente, sous forme d’ordinogramme, un mode particulier de mise en œuvre d’un procédé de communication, dit « procédé général », mis en œuvre par le système de la , ledit procédé général englobant un procédé de traitement d’un message électronique selon l’invention qui est mis en œuvre par le dispositif de la ; la représente, sous forme d’ordinogramme, un autre mode particulier de mise en œuvre du procédé général ; la représente, sous forme d’ordinogramme, un autre mode particulier de mise en œuvre du procédé général ; la représente, sous forme d’ordinogramme, un autre mode particulier de mise en œuvre du procédé général ; la représente, sous forme d’ordinogramme, un autre mode particulier de mise en œuvre du procédé général. Description de modes de réalisation La représente schématiquement un mode particulier de réalisation d’un système 100 de traitement de données selon l’invention. Le système 100 de la est configuré pour réaliser des traitements permettant notamment de rendre interactif, plus particulièrement cliquable dans le présent mode de réalisation, un code graphique contenu dans un message électronique MES émis par un terminal émetteur 110 (expéditeur) et reçu par un terminal récepteur 120 (destinataire). Il est à noter que dans le présent mode de réalisation, les deux terminaux 110, 120 appartiennent au système 100. Pour la suite de la description, on considère de manière nullement limitative que les terminaux émetteur 110 et récepteur 120 sont tous deux des smartphones et qu’ils appartiennent à des utilisateurs respectifs distincts. On considère en outre que le message électronique MES transmis du terminal émetteur 110 vers le terminal récepteur 120 est un courriel (encore appelé « email » en anglais). Ce courriel a notamment été rédigé par l’utilisateur en possession du terminal émetteur 110, et est destiné à être consulté (i.e. lu) par l’utilisateur en possession du terminal récepteur 120. Il convient toutefois de noter que ces dispositions ne sont pas limitatives de l’invention. En particulier, aucune limitation n’est attachée à la nature desdites terminaux émetteur 110 et récepteur 120 dès lors qu’ils sont aptes aux échanges de messages électroniques. Ainsi, rien n’exclut d’envisager, par exemple, qu’un terminal (émetteur/récepteur) soit une tablette numérique, un ordinateur portable, un assistant personnel, une montre connectée, une liseuse électronique, etc. De la même manière, aucune limitation n’est attachée à la nature du message électronique MES dès lors qu’il est apte à inclure un code graphique, comme détaillé ci-après. Ainsi, rien n’exclut d’envisager, par exemple, un message multimédia de téléphonie mobile de type « MMS » (« Multimedia Messaging Service » an anglais), ou bien un message dit « instantané », autrement dit un message échangé au cours d’un dialogue en ligne (« tchat » en anglais). Conformément à l’invention, le message électronique MES comporte un code graphique encodant des données, dites « données d’accès » C_CAR, identifiant une ressource informatique. Dit encore autrement, les données d’accès C_CAR forment un lien vers la ressource informatique correspondante. Plus particulièrement, dans le présent mode de réalisation, le code graphique est un code QR et les données d’accès C_CAR sont représentatives d’un identifiant uniforme de ressource URI configuré pour donner accès à une ressource informatique du réseau Internet (référence « WEB » dans les figures), à savoir ici une page web P_WEB. Le fait de considérer un code graphique de type code QR ainsi que des données d’accès C_CAR représentatives d’une ressource de type URI ne constituent pas des limitations de l’invention, d’autres variantes étant envisageables. Par exemple, pour ce qui concerne le code graphique, celui-ci peut prendre toute forme connue en soi utilisée pour véhiculer des informations, comme par exemple : un mini code QR, un code-barres (e.g. de type PDF147, code 128, etc.), une matrice de données (e.g. de type Flashcode, 2D-doc, datamatrix, etc.), etc. Pour ce qui concerne les données d’accès C_CAR, celles-ci peuvent être par exemple représentative d’une adresse URL (« Uniform Ressource locator » en anglais), d’une adresse courte URL (« tiny URL » en anglais), d’une adresse au sein d’un réseau local (e.g. un réseau internet à une entreprise, comme par exemple un Intranet, de sorte à identifier un fichier stocké sur un serveur de l’entreprise), etc. D’une manière conventionnelle, on comprend que les données d’accès C_CAR comportant une ou plusieurs chaînes de caractères permettant de définir l’accès à la ressource informatique. Par ailleurs, s’il est considéré dans le mode de réalisation décrit ici que la ressource informatique est disponible sur un réseau informatique, rien n’exclut d’envisager encore d’autres alternatives dans lesquelles la ressource informatique est disponible sur l’un quelconque des entités formant le système 100, comme par exemple une application logicielle, une photo, une vidéo, etc. stockée dans une mémoire du terminal émetteur 110 ou du terminal récepteur 120. La nature du ou des protocoles de communication utilisés par les différentes entités du système 100 pour permettre la transmission du message électronique MES du terminal émetteur 110 vers le terminal récepteur 120 n’est en rien limitative de l’invention. Ainsi, dans le présent mode de réalisation, pour au moins ce qui concerne les terminaux 110, 120, tout protocole connu de l’homme de l’art pour réaliser des échanges de données dans le cadre de télécommunications sans fil est envisageable (Wi-Fi, 3G, 4G, 5G, etc.). Bien entendu, rien n’exclut d’envisager également que tout ou partie des entités du système 100 communiquent en utilisant un protocole adapté à un réseau de communication filaire. Tel qu’illustré par la , le système 100 comporte, dans le mode de réalisation décrit ici et outre les terminaux 110, 120, une plateforme de messagerie 130. Cette plateforme de messagerie est configurée de manière matérielle et logicielle pour permettre la gestion (réception, envoi, redirection, stockage, archivage, etc.) de courriels, dont en particulier le message électronique MES. Il est à noter que le mode de réalisation de la est décrit en considérant une unique plateforme de messagerie 130. Ces considérations dérivent du fait qu’il est considéré ici, à titre nullement limitatif et dans un but unique de simplification de la description, que les adresses courriels respectivement utilisées par les terminaux émetteur 110, récepteur 120 sont hébergées et gérées au niveau d’une même plateforme de messagerie 130, cette dernière étant opérée par un unique opérateur de messagerie. Cela étant, rien n’exclut d’envisager, suivant d’autres exemples non détaillés ici, que le système 100 comporte deux plateformes de messagerie distinctes et respectivement associées aux deux terminaux émetteur 110, récepteur 120 (e.g. une première plateforme messagerie gérée par Google (gmail) pour le terminal émetteur 110, et une deuxième plateforme de messagerie gérée par Orange (mail Orange) pour le terminal récepteur 120. Dans le mode de réalisation décrit ici, le système 100 comporte également un dispositif de traitement de données 141 appartenant à une plateforme de services 140. Par « plateforme de services », on fait référence ici à une plateforme opérée par un opérateur de communication (e.g. Orange) pour offrir des services de traitement de données échangées, notamment, via la plateforme de messagerie 130. A cet effet, le dispositif 141 est configuré pour réaliser des traitements permettant notamment de rendre interactif (cliquable) le code QR contenu dans le message MES avant que ce dernier n’atteigne le terminal récepteur 120, en mettant en œuvre un procédé de traitement du message MES selon l’invention. Comme il sera également décrit ci-après, le fait de considérer que les traitements précités sont mis en œuvre par le dispositif de traitement 141 ne constitue qu’une variante d’implémentation de l’invention, et rien n’exclut d’envisager d’autres modes dans lesquels tout ou partie de ces traitements sont mis en œuvre par un dispositif configuré de manière appropriée et intégré à la plateforme de messagerie 130, le terminal émetteur 110 ou le terminal récepteur 120. Pour la suite de la description, on considère de manière nullement limitative que les entités opérant respectivement la plateforme de services 140 et la plateforme de messagerie 130 sont différentes. Bien entendu, de telles dispositions ne sont pas limitatives de l’invention, et rien n’exclut d’envisager que ces entités soient identiques ou qu’elles constituent une unique entité (e.g. même société commerciale). La représente schématiquement un exemple d’architecture matérielle du dispositif de traitement de données 141 inclus dans le système 100 de la . Tel qu’illustré par la , le dispositif 141 dispose de l’architecture matérielle d’un ordinateur. Ainsi, le dispositif 141 comporte, notamment, un processeur 1, une mémoire vive 2, une mémoire morte 3 et une mémoire non volatile 4. Il dispose en outre de moyens de communication 5. La mémoire morte 3 du dispositif 141 constitue un support d’enregistrement conforme à l’invention, lisible par le processeur 1 et sur lequel est enregistré un programme d’ordinateur PROG conforme à l’invention, comportant des instructions pour l’exécution d’étapes du procédé de traitement. Le programme PROG définit des modules fonctionnels du dispositif 141, qui s’appuient ou commandent les éléments matériels 1 à 5 du dispositif 141 cités précédemment. Ces modules fonctionnels sont illustrés sur la à titre nullement limitatif, et sont décrits plus en détails ci-après en référence à différents modes de mise en œuvre. Les moyens de communication 5 permettent au dispositif 141 d’échanger (émission/réception) des données avec une ou plusieurs autres entités du système 100. A cet effet, et comme mentionné ci-avant, ces moyens de communication 5 s’appuient sur une interface de communication, qui peut être filaire ou non filaire, utilisant tout protocole de communication connu de l’homme de l’art. La représente, sous forme d’ordinogramme, un mode particulier de mise en œuvre d’un procédé de communication, dit « procédé général », mis en œuvre par le système 100. Ledit procédé général englobe le procédé de traitement du message MES selon l’invention mis en œuvre par le dispositif 141 de la . Tel qu’illustré par la , le procédé général comporte dans un premier temps une étape E10 d’obtention du message MES. Ladite étape E10 est mise en œuvre par le terminal émetteur 110. Selon un exemple plus particulier de mise en œuvre, l’étape E10 d’obtention consiste en une génération complète du message MES. Autrement dit, selon cet exemple, l’utilisateur en possession du terminal émetteur 110 génère le message MES en y incluant le code QR. Selon un autre exemple, l’étape E10 d’obtention comporte tout d’abord une réception d’un message écrit sans code graphique, par exemple en provenance d’un terminal en possession d’un utilisateur différent de celui qui possède le terminal émetteur 110, ainsi qu’une génération partielle du message MES consistant à incorporer le code QR dans le message écrit. Selon encore un autre exemple, l’étape E10 d’obtention comporte une réception du message MES (i.e. le message comportant déjà le code QR), par exemple en provenance d’un terminal en possession d’un utilisateur différent de celui qui possède le terminal émetteur 110. Autrement dit, dans cet exemple, le rôle du terminal émetteur 110 est de réaliser un relais de communication. Le procédé général comporte ensuite une étape E20 d’émission du message MES à destination du terminal récepteur 120. Ladite étape E10 est mise en œuvre par le terminal émetteur 110. Le message MES émis est alors réceptionné par la plateforme de messagerie 130 (étape E30), et transmis par celle-ci (étape E40) au dispositif de traitement de données 141 appartenant à la plateforme de services 140. Sur réception du message MES par le dispositif 141 (étape E50), le procédé général comporte une étape E60 de détection du code QR dans le message MES. Les étapes E50 et E60 sont respectivement mises en œuvre par un module de réception MOD_RX et un module de détection MOD_DETEC équipant le dispositif 141, et font partie du procédé de traitement. Le module de transmission MOD_RX est intégré aux moyens de communication 5 du dispositif 141. La détection du code QR dans le message MES est mis en œuvre selon toute technique connue de l’homme de l’art, notamment en réalisant un balayage (« scan » en anglais) du message MES afin de repérer les contours dudit code QR. Une fois le code QR détecté, le procédé général comporte une étape E70 de décodage des donnes d’accès C_CAR encodées par le code QR. Ladite étape E70 est mise en œuvre par un module de décodage MOD_DECOD équipant le dispositif 141 et fait partie du procédé de traitement. Il importe de noter que les étapes de détection E60 et de décodage E70 sont décrites ici de manière dissociée. Cela étant, rien n’exclut d’envisager d’autres modes de mise en œuvre dans lesquels le décodage du code graphique admet une définition plus large de sorte à intégrer la détection dudit code graphique. Dans le mode de mise en œuvre décrit ici en référence à la , le procédé général comporte également une étape E80 de vérification du respect d’un critère de sécurité CRIT par la ressource informatique, i.e. la page web P_WEB, identifiée par les données d’accès C_CAR. Ladite étape E80 est mise en œuvre par un module de vérification MOD_VERIF équipant le dispositif 141 et fait partie du procédé de traitement. Par exemple, le critère de sécurité CRIT peut être configuré pour permettre de vérifier que la page web P_WEB n’est pas susceptible d’infecter le terminal récepteur 120 avec un virus lorsqu’elle est consultée. Alternativement, le critère de sécurité CRIT peut être configuré pour permettre de vérifier que la consultation de la page web P_WEB n’est pas susceptible de déclencher un processus d’hameçonnage (« phishing » en anglais) d’informations personnelles de l’utilisateur en possession du terminal récepteur 120. D’une manière générale, aucune limitation n’est attachée à la nature du critère de sécurité CRIT, la notion de « sécurité » étant, dans le cadre de la présente invention, caractéristique de tout ce qui est dépourvu de risques et/ou de dangers pour l’intégrité du terminal récepteur 120 et/ou de son utilisateur. En conséquence, aucune limitation n’est non plus attachée à la manière dont le critère peut être vérifié (e.g. consultation d’une base de données listant des ressources de données suspicieuses, faire un diagnostic réseau, par exemple au moyen d’un test de ping d’une ressource de données, etc.). Dès lors, si la vérification effectuée au cours de l’étape E80 n’est pas satisfaite (i.e. le critère CRIT n’est pas respecté), le procédé général peut comporter une étape d’émission d’un message d’alerte (non illustré sur la ). Par exemple, le message d’alerte peut être transmis au terminal récepteur 120 pour le prévenir de ne pas consulter le message MES lorsque ce dernier lui parvient. Un message d’alerte peut également être transmis à l’opérateur de la plateforme de messagerie 130 pour le prévenir du comportement potentiellement frauduleux de l’utilisateur en possession du terminal émetteur 110. Pour la suite de la description, on considère que la vérification de sécurité effectuée à l’étape E80 est satisfaite. Il convient toutefois de noter que cette étape E80 (et donc a fortiori celle consistant à transmettre un message d’alerte le cas échéant) est optionnelle au sens de la présente invention, et présente l’avantage de renforcer la sécurité du traitement du message MES vis-à-vis de l’utilisateur du terminal récepteur 120. Le procédé général comporte alors une étape E90 de génération d’un objet interactif dans le message MES à partir des données d’accès C_CAR décodées, ledit objet interactif étant configuré pour donner accès à la ressource informatique lorsqu’une interaction est réalisée avec ledit objet interactif. Plus particulièrement, dans le mode de mise en œuvre décrit ici et tel qu’illustré par la , l’objet interactif est un hyperlien HYP_L d’accès à la page web P_WEB, l’hyperlien HYP_L étant généré de sorte à être attaché au code QR et ainsi rendre le code QR cliquable pour accéder à la page web P_WEB (dit encore autrement, l’hyperlien HYP_L est inséré dans le code QR). Ladite étape E90 est mise en œuvre par un module de génération MOD_GEN équipant le dispositif 141 et fait partie du procédé de traitement. En d’autres termes, le code QR du message MES qui était jusqu’à présent une image inerte devient, via l’exécution de l’étape E90, une image active avec laquelle il est possible d’interagir par clic. Par « clic », on fait classiquement référence, dans le présent mode de réalisation où le terminal récepteur 120 est un smartphone, à une interaction directe (i.e. une pression du doigt) sur l’écran tactile dudit smartphone. On note cependant que la notion de « clic » peut également faire référence, suivant d’autres modes de réalisation, à une interaction indirecte, c’est-à-dire au moyen d’un dispositif manié par un utilisateur, comme par exemple une souris ou un stylet. En tout état de cause, le fait d’attacher l’hyperlien HYP_L approprié au code QR dans le corps du message MES permet, lorsque ce dernier est reçu par le terminal récepteur 120, de faciliter grandement la consultation de la page web P_WEB. En effet, l’utilisateur en possession du terminal récepteur 120 peut simplement cliquer sur le code QR, et n’est plus obligé d’utiliser un autre équipement pour scanner le code QR. Pour la suite de la description, on désigne par la référence « NEW_MES » le message contenant le code QR auquel l’hyperlien HYP_L est attaché. Dès lors, et comme représenté par la à titre nullement limitatif, le procédé général comporte une étape E100 de transmission du message NEW_MES à la plateforme de messagerie 130. Ladite étape E100 est mise en œuvre par un module de transmission MOD_TX équipant le dispositif 141 et fait partie du procédé de traitement. Le module de transmission MOD_TX est intégré aux moyens de communication 5 du dispositif 141. Le message NEW_MES émis est alors réceptionné par la plateforme de messagerie 130 (étape E110), et transmis par celle-ci (étape E120) au terminal récepteur 120 qui le réceptionne (étape E130). Dès lors, l’utilisateur en possession du terminal récepteur 120 est en mesure d’être dirigé vers la page web P_WEB. Pour cela, ledit utilisateur clique sur le code QR contenu dans le message NEW_MES reçu (étape E140 avec la référence « ACT CODE QR »). Dans le mode de mise en œuvre décrit ici, et tel qu’illustré par la , le procédé général comporte une étape E150 de transmission d’une notification NOTIF au dispositif 141, ladite notification NOTIF indiquant que le code QR a été cliqué. Ladite étape E150 est mise en œuvre par le terminal récepteur 120. On note que dans la mesure où la notification NOTIF est liée au fait que le code QR est cliqué, elle représente alors également un accusé de réception du message initialement transmis par le terminal émetteur 110. Sur réception de la notification NOTIF par le dispositif 141 (étape E160 faisant partie du procédé de traitement dans le présent mode de mise en œuvre), le procédé général comporte, dans le présent mode de mise en œuvre, une étape E170 d’incrémentation d’un compteur et/ou d’horodatage de ladite notification NOTIF. Ladite étape E170 est mise en œuvre par un module de traçage MOD_INC_HOR équipant le dispositif 141 et fait partie du procédé de traitement. L’incrémentation d’un compteur et/ou l’horodatage de la notification NOTIF est par exemple réalisé au niveau d’une base de données stockée et gérée par le dispositif 141. Alternativement, l’étape E170 peut consister en l’envoi d’une commande à un autre dispositif (e.g. une base de données dédiée) de la plateforme de services 140 pour réaliser ladite incrémentation et/ou ledit horodatage. Il convient toutefois de noter que cette étape E170 est optionnelle au sens de la présente invention, et présente différents avantages. En effet, le fait de réaliser une telle incrémentation auprès d’un compteur permet avantageusement à la plateforme de services 140 d’établir des statistiques relatives à l’utilisation des services qu’elle propose. L’horodatage permet quant à lui de garder une preuve datée de l’utilisation services proposés par la plateforme de services 140. En outre, le fait de combiner un comptage par incrémentation et un horodatage permet d’améliorer la sécurité des échanges dans la mesure où il devient possible de mettre en œuvre des outils de détection d’intrusion, comme par exemple une attaque par déni de service (« Distributed Denial of Service » ou « DDoS » en anglais). Outre ladite étape E170 d’incrémentation et/ou d’horodatage, ladite notification NOTIF est transmise (étape E180 faisant partie du procédé de traitement dans le présent mode de mise en œuvre) à la plateforme de messagerie 130 qui la reçoit (étape E190) et la relaie (étape E200) au terminal émetteur 110 qui la reçoit à son tour (étape E210). Le procédé général comporte également une étape E220 de redirection du terminal récepteur 120 vers la page web P_WEB en utilisant l’adresse URI associée aux données d’accès C_CAR. Ladite étape E220 est mise en œuvre par un module de redirection MOD_RED équipant le dispositif 141 et fait partie du procédé de traitement. En d’autres termes, dans le mode de mise en œuvre décrit ici, c’est le dispositif 141 qui fournit au terminal récepteur 120 un accès à la page web P_WEB. Il est à noter que l’étape E220 de redirection a été décrite ici comme étant exécutée après l’incrémentation et/ou l’horodatage d’un compteur (étape E170) ainsi qu’après que la notification NOTIF soit transmise du dispositif 141 au terminal émetteur 110 (étapes E180, E190, E200, E210). Ces dispositions ne sont toutefois pas limitatives de l’invention, l’ordre dans lequel ces étapes sont exécutées étant indifférent. En outre, le procédé général, et donc in fine le procédé de traitement, a été décrit jusqu’à présent en considérant un accès du terminal récepteur 120 à la page web P_WE via une redirection effectuée par le dispositif 141 (accès indirect). Toutefois, rien n’exclut d’envisager d’autres modes de mise en œuvre du procédé général dans lequel le terminal récepteur 120 accède directement à la page web P_WEB dès lors que le code QR a été cliqué. Un tel autre mode de mise en œuvre est illustré à titre nullement limitatif par la , dans lequel les étapes F10 à F140 sont identiques aux étapes E10 à E140. Par ailleurs, comme cela peut être observé dans la , le procédé général comporte alors une étape F150 d’accès direct (référence « D_ACC CODE QR ») à la page web P_WEB par le terminal récepteur 120 suite au fait que le code QR du message NEW_MES est cliqué. En outre, dans ce mode de mise en œuvre de la , aucune notification NOTIF n’est transmise par le terminal récepteur 120. Bien entendu, selon une alternative à ce mode de mise en œuvre, une notification NOTIF peut être transmise par le terminal récepteur 120, comme décrit en référence à la , tout en permettant un accès direct à la page web P_WEB. D’une manière générale, l’invention a été décrite jusqu’à présent en considérant que toutes les étapes du procédé de traitement sont mises en œuvre par le dispositif de traitement de données 141 de la plateforme de services 140. Cela étant, l’invention couvre encore d’autres modes de réalisation qui sont maintenant décrits. La représente, sous forme d’ordinogramme, un autre mode particulier de mise en œuvre du procédé général. Dans cet autre mode de mise en œuvre, on considère que la plateforme de messagerie 130 comporte un dispositif de traitement de données 131, dit « deuxième dispositif de traitement de données 131 », configurée de manière matérielle et logicielle suivant des dispositions techniques similaires à celles décrites ci-avant en référence à la pour le dispositif de traitements de données 141, dit ici « premier dispositif de traitement de données 141 », et appartenant à la plateforme de services 140. Comme cela peut être observé sur la , une fois le message MES obtenu par le terminal émetteur 110 (étape G10), il est transmis (étape G20) au deuxième dispositif 131 qui le réceptionne (étape G30). Le deuxième dispositif 131 réalise la détection du code QR (étape G40), le décodage des données d’accès C_CAR (étape G50), la vérification du critère de sécurité CRIT (étape G60), la génération de l’hyperlien HYP_L (étape G70), pour ensuite transmettre (étape G80) le message NEW_MES au terminal récepteur 120 qui le réceptionne (étape G90). L’utilisateur clique sur le code QR du message NEW_MES (étape G100) ce qui déclenche l’envoi au deuxième dispositif 131 d’une première notification NOTIF_1 indiquant que le code QR a été cliqué (étape G110). Le deuxième dispositif 131 réceptionne la première notification NOTIF_1 (étape G120) et réalise une incrémentation d’un compteur et/ou horodatage de ladite première notification NOTIF_1 (étape G130). A la manière de ce qui avait été décrit pour l’étape E170 de la , il convient de noter que ladite étape G130 est optionnelle, et peut en outre être mise en œuvre par le premier dispositif 141 plutôt que par le deuxième dispositif 131. La première notification NOTIF_1 est ensuite transmise (étape G140) au terminal émetteur 110 qui la réceptionne (étape G150). Par ailleurs, et comme illustré à titre nullement limitatif par la , le deuxième dispositif 131 effectue une émission d’une deuxième notification NOTIF_2 (étape G160), ladite deuxième notification NOTIF_2 indiquant que le message électronique MES a été modifié par attachement de l’hyperlien HYP_L au code QR (i.e. suite à la génération de l’hyperlien HYP_L en tant qu’objet interactif). Cette deuxième notification NOTIF_2 est émise par le deuxième dispositif 131 vers le premier dispositif 141 qui la réceptionne (étape G170) pour, par exemple, la stocker. Une telle deuxième notification NOTIF_2 permet par exemple d’effectuer une supervision (un contrôle) du nombre de fois où des messages contenant des codes graphiques sont modifiés via l’attachement d’hyperliens à ces codes graphiques. Finalement, le deuxième dispositif 131 effectue une redirection du terminal récepteur 120 vers la page web P_WEB en utilisant l’adresse URI associée aux données d’accès C_CAR (étape G180). Il convient de noter que l’émission de la deuxième notification NOTIF_2 a été décrite ici comme étant effectuée après la réception de la première notification NOTIF_1 par le terminal émetteur 110. Il ne s’agit toutefois pas d’une limitation de l’invention, la deuxième notification NOTIF_2 pouvant être émise à n’importe quel moment dès lors que l’étape G70 de génération de l’hyperlien HYP_L a été exécutée. Qui plus est, l’émission de la deuxième notification NOTIF_2 est également optionnelle au sens de la présente invention. On note par ailleurs que le mode de la a été décrit en considérant que les étapes de détection G40, de décodage G50, de vérification G60 et de génération G70 sont mises en œuvre par le deuxième dispositif 131. Rien n’exclut cependant d’envisager que seule une partie de ces étapes soit mise en œuvre par le deuxième dispositif 131, les autres étapes restantes étant quant à elles mises en œuvre par le premier dispositif 141. A titre l’exemple, l’étape de vérification G60 peut être mise en œuvre par le premier dispositif 141. La représente, sous forme d’ordinogramme, encore un autre mode particulier de mise en œuvre du procédé général. Dans le mode de la , les étapes H10 à H100 sont identiques aux étapes G10 à G100. Par ailleurs, comme cela peut être observé dans la , le procédé général comporte alors une étape H110 d’accès direct (référence « D_ACC CODE QR ») à la page web P_WEB par le terminal récepteur 120 suite au fait que le code QR du message NEW_MES est cliqué. En outre, dans ce mode de mise en œuvre de la , la première notification NOTIF_1 n’est pas émise par le terminal récepteur 120, au contraire de la deuxième notification NOTIF_2 qui est émise par le deuxième dispositif 131 (étape H120) et réceptionné par le premier dispositif 141 (étape H130). Les modes des figures 3 à 6 ont été écrits en considérant que les étapes de détection, de décodage, de vérification et de génération de l’hyperlien sont mises en œuvre par un dispositif de traitement de données de la plateforme de services et/ou un dispositif de traitement de données de la plateforme de messagerie. Cela étant, encore d’autres modes peuvent être envisagés dans lesquels au moins une partie de ces étapes (notamment les étapes de détection, de décodage et de génération de l’hyperlien) sont mises en œuvre par le terminal émetteur 110 ou le terminal récepteur 120, par exemple au moyen d’une application logicielle dont les instructions de code sont stockées dans une mémoire du terminal correspondant. Un tel autre mode est par exemple illustré à titre nullement limitatif par la , dans lequel la détection (étape S20), le décodage (étape S30) et la génération de l’hyperlien HYP_L (étape S90) sont mises en œuvre par le terminal émetteur 110. La vérification du critère CRIT (étape S60) est quant à elle effectuée par le dispositif 141 de la plateforme de services 140 sur réception (étape S50) d’une notification NOTIF_3 émise par le terminal émetteur 110 (étape S40) pour requérir ladite vérification, et étant entendu que le dispositif 141 émet une réponse REP_NOTIF_3 à cette requête (étape S70) une fois la vérification effectuée. Bien entendu, il est possible d’envisager une alternative dans laquelle la vérification du critère CRIT est réalisée par la plateforme de messagerie 130 (i.e. par un dispositif de traitement approprié intégré à la plateforme de messagerie 130). On comprend par ailleurs qu’un mode de mise en œuvre similaire à celui de la peut encore être envisagé côté terminal récepteur 120 pour ce qui concerne au moins la détection, le décodage et la génération de l’hyperlien HYP_L. Cet autre mode de mise en œuvre n’est pas décrit ici en détail, l’homme de l’art étant en mesure de le réaliser sur la base de l’ensemble des considérations techniques décrites jusqu’à présent. Par ailleurs, dans les modes de réalisation décrits précédemment, il a été considéré que l’objet interactif généré est un hyperlien attaché au code graphique de sorte à rendre ce dernier cliquable. Cela étant, au sens de la présente invention, l’objet interactif ne se limite pas au seul hyperlien destiné à être attaché au code graphique. En effet, il peut également s’agir d’un objet d’une autre nature non destiné à être attaché au code graphique, mais à être incorporé/affiché dans le message électronique en complément du code graphique lors de l’étape de génération dudit autre objet interactif. A titre d’exemple nullement limitatif, un tel autre objet interactif peut correspondre à un symbole, une icône, une image, une photo, etc. En outre, rien n’exclut non plus d’avoir dans le message électronique non seulement un code graphique cliquable comme décrit ci-avant mais également un tel autre objet interactif. Procédé de traitement d’un message électronique destiné à un terminal récepteur (120), ledit message comportant un code graphique encodant des données, dites « données d’accès », représentatives d’un accès à une ressource informatique, ledit procédé comportant des étapes de : - décodage (E70) des données d’accès, - génération (E90) d’un objet interactif dans le message électronique à partir des données d’accès décodées, ledit objet interactif étant configuré pour donner accès à la ressource informatique lorsqu’une interaction est réalisée avec ledit objet interactif. Procédé selon la revendication 1, dans lequel l’objet interactif est un hyperlien d’accès à la ressource informatique, l’hyperlien étant généré de sorte à être attaché au code graphique et ainsi rendre le code graphique cliquable pour accéder à la ressource informatique. Procédé selon l’une quelconque des revendications 1 à 2, dans lequel le code graphique est l’un quelconque parmi : un code QR, un mini code QR, un code-barres, une matrice de données. Procédé selon l’une quelconque des revendications 1 à 3, dans lequel les données d’accès sont représentatives d’un identifiant uniforme de ressource configuré pour donner accès à une ressource informatique du réseau Internet. Procédé selon l’une quelconque des revendications 1 à 4, ledit procédé comportant en outre, avant la génération de l’objet interactif, des étapes de : - vérification (E80) du respect d’un critère de sécurité par la ressource informatique, - si la vérification n’est pas satisfaite, émission d’un message d’alerte. Procédé selon l’une quelconque des revendications 1 à 5, ledit procédé comportant en outre, suite à une transmission du message électronique au terminal récepteur, des étapes de : - réception (E160), en provenance du terminal récepteur (120), d’une notification indiquant qu’une interaction a été réalisée avec l’objet interactif, - transmission (E180) de la notification à destination d’un terminal émetteur (110) du message électronique, - redirection (E220) du terminal récepteur vers la ressource informatique en utilisant les données d’accès. Procédé selon l’une quelconque des revendications 1 à 5, ledit procédé comportant en outre, après la génération de l’objet interactif, une étape de transmission (E120) du message électronique au terminal récepteur (120). Procédé selon la revendication 7, ledit procédé comportant en outre une étape d’émission d’une notification, ladite notification indiquant que le message électronique a été modifié suite à la génération de l’objet interactif. Procédé selon la revendication 6 ou 8, ledit procédé comportant en outre, sur réception de la notification, une étape (E170) d’incrémentation d’un compteur et/ou d’horodatage de ladite notification. Procédé selon l’une quelconque des revendications 1 à 9, dans lequel le message électronique est un courriel, un message multimédia de téléphonie mobile ou bien un message échangé sur une plateforme de messagerie instantanée. Programme d’ordinateur comportant des instructions pour la mise en œuvre d’au moins les étapes de décodage et de génération d’un procédé de traitement de données selon l’une quelconque des revendications 1 à 10 lorsque ledit programme est exécuté par un ordinateur. Support d’enregistrement lisible par un ordinateur sur lequel est enregistré un programme d’ordinateur selon la revendication 11. Dispositif de traitement de données (131, 141) comportant des moyens configurés pour mettre en œuvre au moins les étapes de décodage et de génération d’un procédé de traitement d’un message électronique selon l’une quelconque des revendication 1 à 10. Dispositif (131, 141) selon la revendication 13, ledit dispositif étant intégré à l’un quelconque parmi : - une plateforme de services opérée par un opérateur de communication, - une plateforme de messagerie opérée par un opérateur de messagerie, - un terminal émetteur du message électronique, - un terminal récepteur auquel le message électronique est destiné. Dispositif (131, 141) selon la revendication 14, dans lequel les entités opérant la plateforme de services et la plateforme de messagerie sont différentes ou identiques.