FR 3097672 A1 20201225 FR 1906735 A 20190621 Description Titre de l'invention : Système d'applications de servicepour terminaux de paiement Domaine technique [0001] La présente invention concerne le domaine des applications de service pour terminaux de paiement. Technique antérieure [0002] Un terminal de paiement (ou terminal de paiement virtuel) est un dispositif in- formatique permettant à un professionnel de gérer le paiement électronique d'un bien ou d'un service par un client. Le paiement s'effectue typiquement à l'aide d'une carte bancaire, smartphone ou tout autre support embarquant un moyen de paiement. La carte, son porteur et la transaction sont authentifiés et validés par le terminal de paiement auprès d'un service bancaire, après présentation de la carte au terminal, ou saisie manuelle des informations relatives à l'identification du porteur (numéro de carte, date d'expiration, identifiant du porteur, etc.). Le terminal de paiement peut être constitué d'un dispositif informatique dédié, être constitué d'un dispositif informatique généraliste, comme par exemple un téléphone mobile, une tablette informatique, un ordinateur personnel doté d'un moyen de lecture d'une carte à puce, d'une carte à piste magnétique, sans contact et de manière générale de lecture d'une information sur un support permettant l'identification d'un client au service bancaire (y compris code barre ou QR code), ou d'une application permettant l'accès au service de paiement (exemple : navigateur interne° et connecté à un réseau informatique. Le dispositif informatique dispose d'une application de service dédiée à la gestion des transactions. [0003] Le contexte actuel du paiement est marqué par l'apparition de nouveaux moyens de paiement comme, par exemple, les solutions de paiement utilisant des objets connectés comme les téléphones intelligents (smartphones en anglais) dotés de capacités de paiement. On peut citer les solutions Apple Pay (marque déposée), Android Pay (marque déposée), des solutions de portefeuille électroniques internationaux, régionaux ou atTinitaires comme AliPay (marque déposée), WeChat Pay (marque déposée), Paypal (marque déposée), BlueCode (marque déposée), Paylib (marque déposée), etc. [0004] De nombreuses marques de paiement se développent également comme, par exemple, VISA (marque déposée), VISA Electron (marque déposée), Mastercard (marque déposée), Maestro (marque déposée), Union Pay (marque déposée), Discover (marque déposée), American Express (marque déposée), Cartes bancaires (marque déposée), MultiBanco (marque déposée), Giromat (marque déposée), Giropay (marque déposée), etc. 2 100051 Les services autour du paiement se développent également, comme l'offre de paiement en plusieurs fois, le paiement en devise (DCC), le paiement différé, etc. [0006] Les services annexes à la transaction proprement dite se développent aussi, comme l'offre d'assurances sur le bien ou le service acheté, les extensions de garantie, la prise en charge du pourboire. Ces services annexes peuvent également concerner la relation client, comme par exemple les programmes de fidélité, l'offre de coupons de réductions, la collecte d'avis client ou autres. D'autres services encore peuvent concerner la connaissance du consommateur et de son comportement. Les possibilités de services autour du paiement ne cessent de s'accroitre chaque jour. [0007] Pour pouvoir être offerts à ses clients dc façon plus simple, intuitive et ergonomique, ces services doivent être intégrés à l'application de gestion du terminal du paiement par le professionnel. Pour ce faire, il est nécessaire de faire appel à des intégrateurs ou directement au fabricant du terminal de paiement pour développer une application spécifique correspondant aux besoins du professionnel. Ces développements sont longs, coûteux, et doivent ensuite être maintenus par un professionnel. Ce coût, ces délais et le manque de flexibilité sont un obstacle à l'adoption rapide par les professionnels des services disponibles ou à venir. Exposé de l'invention [0008] La présente invention a pour but de résoudre les inconvénients précités en proposant une platefortne de services pouvant être intégrés à une solution dc paiement ou d'interaction client. La plateforme offre également un outil de programmation graphique dc solutions de paiement qui permet à un utilisateur de la plateforrne de définir les solutions dc paiement en intégrant les services souhaités et en les paramétrant. Cet outil de programmation graphique peut être utilisé sans nécessiter de connaissance informatique. L'outil de programmation graphique permet de générer au moins deux logiciels, par exemple à base de scripts, l'un destiné à être exécuté sur le terminal dc paiement et à collaborer avec l'autre sur un serveur dc b platcforme de services pour fournir une solution de paiement. [0009] Ainsi, un professionnel peut facilement et rapidement définir la solution de paiement adaptée à ses besoins. Cette solution peut être déployée rapidement. Elle peut également être modifiée à tout moment par le professionnel de façon à suivre les évolutions de ses besoins. Brève description des dessins 100101 Ifie.11 La figure 1 illustre l'architecture d'un système de services pour terminaux de paiement selon un exemple de réalisation de l'invention. 100111 Ifie.21 La figure 2 illustre un exemple d'interface de programmation des applications de services pour terminaux de paiement. 3 100121 Ifie.31 La figure 3 illustre un service tel qu'il apparait dans la fenêtre d'édition selon un exemple de réalisation de l'invention. [0013] [fig.4] La figure 4 illustre le déploiement de l'application de service selon un mode de réalisation de l'invention. [0014] [fig.5] La figure 5 illustre le déroulement d'un service, ici le service de paiement, selon un exemple de réalisation de l'invention. [0015] [fig.6] La figure 6 illustre les principales étapes de l'exécution d'une application de service dans un mode de réalisation de l'invention. [0016] [fig.7] La figure 7 illustre l'architecture logicielle du terminal de paiement dans un exemple de réalisation de l'invention. [0017] [fig.8] La figure 8 illustre l'architecture logicielle de la plateforme serveur dans un exemple de réalisation de l'invention. [0018] [fig.9] La figure 9 est un bloc-diagramme schématique d'un dispositif de traitement de l'information pour la mise en oeuvre d'un terminal de paiement ou d'un serveur pouvant implémenter la plateforme de service pour terminaux de paiement selon plusieurs modes de réalisation de l'invention. Description détaillée l0019] La Figure 1 illustre l'architecture d'un système de services pour terminaux de paiement selon un exemple de réalisation de l'invention. l0020] Le système comprend une plateforme de service 103. Cette plateforme de service comprend un premier module d'exécution 105 qui permet l'opération des services de paiement à un terminal de paiement 101. La plateforme de service 103 comprend également un module de programmation des services de paiement 104 auquel un utilisateur, c'est-à-dire une personne opérant un terminal de paiement 101 peut se connecter depuis un dispositif de traitement de l'information 102. Ce dispositif peut typiquement être constitué d'un ordinateur personnel, d'une tablette, ou de tout terminal pouvant se connecter à un réseau de communication de données du type Internet. Le dispositif de traitement de l'information dispose typiquement d'un client Internet, tel qu'un navigateur web, permettant à l'utilisateur d'interagir avec le module de programmation des services de paiement 104. [0021] La plateforme de service 103 est décrite ici de manière logique. Elle peut être constituée d'un ou de plusieurs serveurs interagissant pour fournir le service déciit. De même, seuls les aspects essentiels à la définition puis à l'exécution des applications de service de paiement sont décrites. La plateforme comprend également des services annexes comme, par exemple, l'authentification et la gestion des utilisateurs qui ne sont pas décrits en détail. [0022] Le module de programmation des services de paiement 104 permet à l'utilisateur de programmer de façon simple, intuitive et rapide, un service de paiement sur la base de services de base offerts par la plateforme de service 103. Selon un exemple de réalisation de l'invention, le module de programmation des services de paiement offre une programmation graphique par agencement de services élémentaires, leur connexion et la définition de leurs paramètres. Ainsi, un utilisateur peut facilement concevoir une application complète pour un terminal de paiement. Cette application complète, une fois définie, est constituée de deux modules logiciels destinés l'un à s'exécuter sur le terminal de paiement 101 et l'autre sur le module d'exécution 105. Les deux modules logiciels interagissent alors pour exécuter ensemble l'application. Dans certains modes de réalisation, l'application implique plus de deux modules logiciels s'exécutant sur différents dispositifs informatiques et interagissant entre eux. [0023] Au moins certains des services élémentaires constituant l'application pour terminal de paiement peuvent faire appel à un ou plusieurs services externes 106 à 109. Ces services externes comprennent par exemple des fournisseurs de services de paiement (PSP pour Payaient Service Provider en anglais), des services de courrier électronique, des services de messagerie par message texte court (SMS pour Short Message Service en anglais), des services de collecte et d'analyse d'avis clients, des services d'animation commerciale (programme de fidélité, de gestion de coupons...), des services d'identification du client (ex : gestion de tokens) ou autres. [0024] Ainsi, un utilisateur opérant un terminal de paiement peut utiliser la plateforme pour définir une application complète pour terminal de paiement. Cette définition ne nécessite pas de connaissance particulière en programmation, elle est rapide et aisée à utiliser. Une fois l'application définie, la plateforme génère tous les modules logiciels devant s'exécuter sur le terminal de paiement. La plateforme génère également un second module logiciel qui s'exécute sur la plateforme elle-même. Les modules logiciels destinés au terminal de paiement ou, de manière plus générale, tout dispositif informatique, sont déployés sur ceuxci. Lors de l'utilisation du terminal de paiement, le module logiciel déployé sur le terminal s'exécute, se connecte à la plateforme et coopère avec le module logiciel s'exécutant sur la plateforme pour fournir les services composant l'application. Certains de ses services peuvent utiliser des services externes qui interagissent avec la platefonne de service. [0025] L'utilisateur peut donc, à tout moment, définir ou modifier son application de paiement pour s'adapter à l'évolution de ses besoins et offrir le niveau de service souhaité à ses clients. De nouveaux services apparaissant sur le marché peuvent être offerts rapidement par intégration à la plateforme de service. Dès cette intégration faite, les utilisateurs peuvent les intégrer à leur application pour terminal de paiement. [0026] La Figure 2 illustre un exemple d'interface de programmation des applications de services pour terminaux de paiement. [0027] L'application de programmation graphique permettant la programmation des ap- plications de service fonctionne sur un mode client-serveur entre le client 102 utilisé par l'utilisateur et le module de programmation 104 sur la platcforme de service. L'exemple ici décrit est basé sur l'utilisation d'un navigateur web standard sur le client 102 interagissant avec un module de programmation 104 développé sous la forme d'un service web sur la plateforme. Toute autre implémentation est bien sûr envisageable comme un client natif interagissant avec une application native côté serveur par exemple. [0028] Dans cet exemple, l'interface de programmation comprend une fenêtre principale 201 qui comprend deux sous-fenêtres. [0029] Une première sous-fenêtre 202 comprend une liste des services élémentaires 203 dis- ponibles. Avantageusement cette liste peut être ordonnée par type de services. Avantageusement, la liste peut être hiérarchisée et permettre de n'afficher que les services d'une même catégorie à un instant donné pour faciliter l'identification du service recherché, si le nombre total de services est grand. [0030] Une seconde sous-fenêtre 204 permet l'édition de l'application de service pour terminaux de paiement. Dans cette fenêtre d'édition 204, l'utilisateur peut agencer des services 205 sélectionnés dans la liste des services 202. Typiquement, l'utilisateur peut sélectionner un service dans la liste des services 202 et le glisser-déposer dans la fenêtre d'édition 204. Le service 205, une fois déposé dans la fenêtre d'édition expose au moins un point d'entrée et au moins un point de sortie, ainsi que d'éventuels points de branchement (hooks en anglais). L'utilisateur peut alors connectés les points d'entrée et de sortie des différents services pour constituer son application. Les services 205 exposent également, si nécessaire, un ensemble de paramètres permettant à l'utilisateur de personnaliser le service selon ses besoins. [0031] L'interface comprend également, non représenté sur la figure, les contrôles permettant la sauvegarde d'une application ainsi que la génération et le déploiement des modules logiciels générés sur le terminal de paiement et sur la platefonne. Avantageusement, le déploiement du module logiciel destiné au terminal de paiement peut être fait sur un ensemble de terminaux de paiement, par exemple dans le cas d'un magasin comportant un ensemble de terminaux de paiement ou dans le cas d'une chaine de magasins. [0032] La Figure 3 illustre un service 301 tel qu'il apparait dans la fenêtre d'édition 204 selon un exemple de réalisation de l'invention. [0033] Le service comprend au moins un point d'entrée 304 et au moins un point de sortie 305. Selon le service, plusieurs points de sortie (ex : point de sortie n°1 = transaction validée, point de sortie n°2 = transaction en erreur, point de sortie n°3 = transaction annulée par le client) peuvent être présents. Ce sont ces points d'entrée et de sortie qui 6 permettent de connecter les différents services entre eux pour constituer l'application. Cette connexion est avantageusement faite en tirant une connexion entre deux points à la souris. [0034] Un ou plusieurs points de branchement 306 peuvent être présents. Ces points de branchement permettent d'interrompre le déroulement du service à un moment donné pour déclencher le déroulement d'un ou de plusieurs autres services connectés à ce point de branchement. Lorsque ces services se terminent, le service interrompu est repris. [0035] Dans l'exemple de réalisation, le service comprend une zone d'identification 302. Cette zone d'identification peut comprendre le nom du service, un identifiant du service ainsi qu'une description longue du service. Avantageusement, un bouton dans cette zone permet d'ouvrir une page d'aide qui donne des détails sur le fonctionnement du service à l'utilisateur. [0036] Une zone de pararnétrage du service 303 est présente si le service peut être paramétré. Cette zone de paramétrage comprend typiquement des contrôles, comme des menus déroulants, des cases à cocher à sélection multiple ou exclusive, des champs numériques ou textuels etc... L'utilisateur peut alors facilement pararnétrer chaque service en fonction de ses besoins. [0037] Par exemple, un service de paiement pourra permettre à l'utilisateur de choisir le type de carte acceptée parmi les cartes à puce avec contact, sans contact, les cartes magnétiques et saisie manuelle, etc. Il peut également permettre de choisir les solutions acceptées parmi, par exemple, les solutions VISA, Mastercard, American Express, Discover, JCB.... Les types de paiement acceptés peuvent également être paramétrés parmi différents types (exemple : débit, crédit, remboursement...). Des paramètres par défaut peuvent également être paramétrés. Des points de branchement peuvent être offerts pour permettre d'insérer des services autres à certains moments de l'exécution d'un service (e.g. le paiement) paiement comme, par exemple, avant l'insertion de la carte, après l'insertion de la carte, avant la sélection de l'application et après la sélection de l'autorisation. [0038] Par exemple, si l'utilisateur souhaite apporter la possibilité à ses clients de payer en utilisant leur propre devise en lieu et place de la devise par défaut de l'utilisateur, un service de conversion de devise peut être branché sur le point de branchement intervenant après l'insertion de la carte. Ainsi, après l'insertion de la carte, le client se verra proposer la sélection d'une devise, par exemple le dollar américain, au lieu de la devise par défaut du commerçant, par exemple l'euro. Le client peut alors 1h-e sur le terminal le montant net qui lui sera prélevé sur son compte bancaire dans sa devise et incluant les frais éventuels comme le taux de change et la commission de change. [0039] La Figure 4 illustre le déploiement de l'application de service selon un mode de réa- 7 lisation de l'invention. [0040] Une fois l'application de service 401 définie par l'utilisateur en utilisant le module de programmation 104 à l'aide de l'interface 201, plusieurs modules logiciels tels que 402 et 403 sont générés. Le module logiciel 402 est destiné à s'exécuter sur le terminal de paiement 404 (ou autre dispositif informatique) sous le contrôle d'un orchestre de service 406. Le module logiciel 403 est destiné à s'exécuter sur le serveur (ou autre dispositif informatique) au sein du module d'exécution des service 405, correspondant au module illustré dans la Figure 1 sous la référence 105. Le module logiciel 403 s'exécute sous le contrôle d'un orchestre de service 407. [0041] Dans un mode de réalisation, les modules logiciel 402 et 403 sont composés d'un ensemble de ressources comprenant des scripts, des fichiers (ex : images, fichier de configuration...), et d'un flux de travail (workflow en anglais) qui définit l'ordonnancement des services. Chaque script est paramétré en fonction des paramètres définis par l'utilisateur. Chaque service utilisé se traduit donc par un premier script s'exécutant sur le terminal de paiement (ou autre dispositif informatique) et un second script s'exécutant sur la plateforme (ou autre dispositif informatique). Au moins un dispositif informatique est obligatoire. Ces scripts coopèrent au travers de la connexion 408 entre les dispositifs informatiques. Le script peut également coopérer avec des services externes comme expliqué en rapport avec la Figure 1. Ainsi, l'utilisateur du terminal de paiement utilise une application qui lui semble exécutée sur ledit terminal mais qui met en oeuvre finalement des modules logiciels locaux au terminal, d'autres sur la plateforme de service et potentiellement des services externes. [0042] Les orchestres de service 406 et 407, s'exécutant respectivement sur les dispositifs informatiques, sont en charge de l'exécution des différents scripts composant les différents services en accord avec le flux de travail défini. Ces orchestres de service, exécutent également les scripts avec les paramètres correspondant à la programmation de l'application faite dans le module de programmation 104. [0043] Les scripts qui s'exécutent sur les dispositifs informatiques peuvent être programmés dans le même langage de script où alors dans des langages différents selon les modes de réalisations de l'invention. Ce choix dépend des choix logiciels, en termes de système d'exploitation et d'environnement logiciel faits pour le terminal de paiement et pour la plateforme. Ces langages de script comprennent, par exemple, Javasciipt, Lua, Python, Kotlin Groovy ou autres. Dans certains modes de réalisation, de véritables exécutables peuvent être compilés en lieu et place des scripts. [0044] La Figure 5 illustre le déroulement d'un service, ici le service de paiement, selon un exemple de réalisation de l'invention. [0045] Le terminal initie l'exécution du service par le bloc de traitement 501. Lors de ce traitement, il est d'abord vérifié que le montant et la devise sont fournis au démarrage 8 du service et que les valeurs sont correctes. Par exemple, le montant doit être supérieur à un euro et la devise doit être Peur°. Ensuite, le bloc de traitement 501 demande l'insertion de la carte au client. La carte est alors lue et la devise par défaut de la carte est extraite. Si un service externe est connecté au point de branchement « après insertion de la carte », alors ce service est déclenché. Le code PIN du client est ensuite vérifié. En cas de succès de la vérification du code PIN du client, une requête en autorisation 502 est transmise au script correspondant qui s'exécute sur la plateforme. [0046] Ce script s'exécutant sur la plateforme effectue un bloc de traitement 503. Cc bloc de traitement se charge de sélectionner la banque devant traiter le paiement. Pour ce faire, le script s'exécutant sur la plateforme doit faire appel à d'autres services disponibles sur cette plateforme. Par exemple, la plateforme comporte une base de données contenant la référence des banques avec lesquelles le commerçant a signé un contrat d'acquisition. Cette base de données contient également les informations techniques de connexion aux banques, telles que les adresses IP principale et secondaire et les identifiants de connexion. Avantageusement, les contrats d'acquisition peuvent être modélisés afin de pouvoir évaluer quelle banque est la plus compétitive pour un type de transaction donné. Par exemple, un paiement international «VISA» peut être moins cher auprès d'une banque alors qu'un paiement « Mastercard » sera moins cher auprès d'une autre banque. [0047] En fonction de toutes ces informations, le module de traitement 503 choisit une banque et lui transmets la requête en paiement 504. La banque choisie, traite alors la requête lors d'un traitement 505. A l'issue de ce traitement, le paiement est validé ou refusé. La banque transmet ce résultat lors d'une réponse 506 à destination de la plateforme. La plateforme, lors d'un traitement 507 retransmet la réponse 508 au terminal de paiement. [0048] La Figure 6 illustre les principales étapes de l'exécution d'une application de service dans un mode de réalisation de l'invention. [0049] Dans une étape 601, une transaction est lancée. [0050] Dans une étape 602, l'orchestre de services du terminal de paiement lance le premier script composant l'application. L'orchestre de services de terminal est en charge du lancement successif des services au fur et à mesure de leur exécution sur le terminal de paiement ou le dispositif informatique. [0051] Lors d'une étape 603, l'application s'exécute. [0052] Lors d'une étape 604, lorsqu'un des services nécessite une connexion à la plateforme, cette connexion est initiée par le service. Pour ce faire, une authentification forte oeut être utilisée pour authentifier le terminal de paiement auprès de la plateforme. Avantageusement, cette authentification utilise un système cryptographique (ex : clés asymétriques) géré au sein d'un module matériel sécurisé. Ce 9 module matériel sécurisé est composé d'une partie physique et d'une partie logicielle dont le rôle est de protéger les clés et les opérations cryptographiques. Toute tentative d'intrusion logique ou physique d'un module matériel sécurisé peut mener à l'effacement immédiat des clés cryptographiques qu'il contient. Un tel module matériel sécurisé est fonctionnellement très proche d'une carte à puce tout en disposant d'une capacité de traitement plus importante. [0053] Lors de l'étape 605, le contexte applicatif, c'est-à-dire, typiquement, la liste des données capturées et/ou générées par l'application, est transférée au serveur. Lors de l'étape 607, l'orchestre de services de la plateforme identifie le script serveur correspondant à l'application de service sur la base de l'identification du terminal de paiement et le lance avec les paramètres associés. [0054] Lors de l'étape 608, l'application s'exécute par orchestration des différents scripts de service sur le terminal de paiement et sur la plateforme. Au besoin, les scripts s'exécutant sur la plateforme font appel aux services externes comme décrit en relation avec la Figure 5. [0055] Lors de l'étape 609, symétrique de l'étape 604, une connexion au client est initiée par le serveur. [0056] Lors de l'étape 610, symétrique de l'étape 605, le contexte applicatif serveur est transféré au client. [0057] Les étapes 602 à 610 peuvent s'exécuter un nombre quelconque de fois en fonction des besoins de l'application. [0058] Lors de l'étape 606, à la fin de l'application, le script client initie la fin d'exécution. La plateforme est notifiée de la fin d'exécution et peut alors libérer les ressources utilisées par le script sur la plateforme. [0059] Dans un mode de réalisation, un même orchestre de services est déployé sur le client et le, ou les, serveur. L'application est alors vue comme un ensemble d'un ou plusieurs modules logiciels s'exécutant sur un ou plusieurs dispositifs informatiques et collaborant entre eux en fonction des besoins de l'application. Le passage du contrôle d'un dispositif à l'autre se fait comme illustré par la figure 6 entre le client et le serveur. La transaction peut alors être initiée indifféremment par l'un ou l'autre de ces modules logiciels. [0060] Dans un premier exemple, une enseigne de magasin pourrait déployer une instance de l'orchestre de services sur chacun des terminaux de paiement, une instance de l'orchestre de service sur un serveur au sein de chaque magasin et une instance sur un serveur central distant. L'application serait alors constituée de l'ensemble des modules logiciels exécutés sur chacune de ces instances de l'orchestre de services. [0061] Dans un second exemple, une instance de l'orchestre de service serait déployée sur chaque terminal de paiement, un seul de ces terminaux serait connecté à intemet. L'instance déployée sur le terminal de paiement connecté à internet agirait alors en proxy pour les autres instances. Plusieurs terminaux collaborent alors à la réalisation de la transaction. [0062] Dans un troisième exemple, un magasin dispose d'un écran doté d'un moyen de lecture NEC, d'un terminal de paiement disposant dc tous les moyens de valider un paiement qui communique avec un serveur distant. Ces trois dispositifs sont dotés d'une instance dc l'orchestre de services et collaborent pour réaliser la transaction. [0063] La Figure 7 illustre l'architecture logicielle du terminal de paiement dans un exemple de réalisation de l'invention. [0064] Dans l'exemple de réalisation de l'invention ici décrit, le terminal de paiement fonctionne sous le contrôle du système d'exploitation Android de Google (marques déposée). Ce système d'exploitation 700 permet de faire fonctionner un ensemble de modules logiciels nécessaires au fonctionnement des applications de service selon l'exemple de réalisation de l'invention. Ces modules sont implémentés sous la forme d'une ou plusieurs applications Android selon les modes de réalisation. [0065] Le module central est l'orchestre de services 704. C'est ce module qui charge les différents scripts constituant l'application de service, qui permet de les exécuter et de les ordonnancer. Pour cc faire, l'orchestre de services 704 comporte un moteur d'exécution du langage de script choisi : Le terminal est amené à traiter des scripts qu'il est le seul à pouvoir exécuter car ils font appel à des ressources uniquement disponibles dans le terminal (ex : communication avec le lecteur de carte à puce). A l'inverse, d'autres scripts ne peuvent être exécutés que par le serveur (ex : connexion à un service tiers hébergé à l'extérieur de l'environnement du serveur et non accessible par le terminal. Dans certains cas, certains scripts peuvent s'exécuter indifféremment sur le terminal ou le serveur. [0066] Une transaction se compose donc de 3 éléments majeurs : Un worktlow qui décrit l'enchainement des scripts et leur portée (i.e. exécution exclusive par le terminal, le serveur ou indifférenciée) Un ensemble de scripts (clients et serveur) Un « contexte » contenant l'ensemble des données capturées ou générées pendant une transaction. [0067] Les scripts sont disponibles dans les 2 environnements (i.e. terminal et serveur) avant le démarrage d'une transaction afin de réduire le délai de démarrage de la transaction. Cependant, il est aussi possible que le terminal télécharge les scripts et le « worktlow » au démarrage d'une transaction. [0068] L'orchestre de services est responsable du transfert du contexte du terminal vers le 11 serveur (et vice versa) lors du «passage de relais ». Les applications de service partagent un certain nombre de fonctionnalités communes mises à disposition soit par le terminal, soit par le serveur. Elles doivent toutes accéder au lecteur de carte de paiement intégré au terminal, communiquer avec la plateforme de service, gérer l'interface du terminal ou encore gérer des opérations dc cryptographie dans le cadre de leur authentification auprès dc la plateforme par exemple. Ces fonctionnalités communes sont fournies par un ensemble de modules logiciels typiquement rassemblés en une ou plusieurs applications Android, ou services « serveur ». [0069] Un module d'interface homme machine (IHM) 702 offre les fonctions de gestion de l'écran du terminal de paiement ainsi que du clavier. Ce module permet les interactions avec le client utilisateur du terminal. [0070] Un module de sécurité 705 gère les opérations de cryptographie liées au fonc- tionnement des services. Ces opérations comprennent les authentifications auprès dc la plateforme et si nécessaire auprès de services tiers. Ce module de sécurité peut interagir avec un microcontrôleur sécurisé 708 présent dans le terminal et agissant comme un élément de sécurité (secure eleinent en anglais), c'est-à-dire un composant matériel chargé des opérations cryptographiques proprement dites et du stockage des clés, ce composant étant dotés de fonctionnalités dc sécurité visant à le rendre inviolable. [0071] Le module d'intégration lecteur de carte 703 offre les interactions avec le ou les lecteurs de carte présents dans le terminal de paiement. Ces lecteurs peuvent être filaires ou sans fil. [0072] Le module d'interface plateforme 706 offre les communications avec la plateforme. C'est typiquement le module qui va permettre à un script client de communiquer avec le script serveur correspondant et via ce script serveur avec d'éventuels services tiers. [0073] Un module de mise-à-jour 701 permet de mettre les workflows, les scripts et les différents modules à jour lorsque de nouvelles versions sont disponibles. [0074] Un module de communication 707 gère les communications entre ces différents modules et l'extérieur du terminal de paiement et notamment le lecteur de carte et la plateforme de service. C'est ce module qui établit les tunnels de communication sécurisé, par exemple avec la plateforme. [0075] La Figure 8 illustre l'architecture logicielle de la plateforme serveur dans un exemple de réalisation de l'invention. Cette figure n'illustre pas le module de programmation 104 mais uniquement l'architecture utile à l'exécution des applications de service. [0076] Le coeur 800 de la plateforme est constitué d'un ensemble de modules. Ces modules centraux comprennent l'orchestre de service 803 qui gère le chargement, l'exécution et l'ordonnancement des scripts serveur de l'application de service. C'est le pendant côté serveur de l'orchestre de service 704 sur le terminal. 12 [0077] De manière similaire à l'architecture du terminal, les scripts s'exécutant sur la plateforme peuvent utiliser un ensemble de services à leur disposition sous la forme de modules logiciels accessibles. [0078] Ces services comprennent un module d'authentification 801 qui gère les authenti- fications. Cc module coopère typiquement avec un module matériel sécurisé 809 (FISM pour Hardware Secure Module en anglais). Ce module d'authentification va gérer les opérations cryptographiques pour le compte de tous les modules qui le nécessitent. [0079] Les modules 801 et 802 permettent sont le point d'accès au module 809. Ils se chargent de préparer et optimiser les opérations déléguées au module 809 (ex : conversion des données du format XML ou ISON en un format unique binaire adapté au HSM). [0080] Un module 804 de surveillance, permet de surveiller l'exécution des scripts et l'utilisation des différents modules et des scripts en cours d'exécution pour détecter de possibles anomalies pouvant provenir de dysfonctionnements ou d'éventuelles attaques de la plateforme. [0081] D'autres modules sont également présents, non représentés, comme par exemple un module d'enregistrement des opérations techniques et métiers effectuées (log en anglais), un module éventuel de traduction de protocole si nécessaire pour interagir avec certains services tiers, un module de mise à jour des composants logiciels. Cette liste n'est pas exhaustive. [0082] Ces services s'appuient également sur une base de données 808 qui contient, entre autres : Les caractéristiques des services tiers (adresse IP, token d'authentification...) Les configurations de chaque banque autorisée pour chaque terminal (ex: numéro du contrat commerçant, devises autorisées, montants plafonds...) La liste des services autorisés pour chaque terminal Le workflow actif (et les scripts associés) pour chaque terminal Etc. [0083] La plateforme coopère dans son fonctionnement avec des entités externes. Elle est donc dotée de services gérant la communication avec ces entités externes. Un module 805 gère les communications de la plateforme avec les commerçants. C'est ce module qui gère la communication avec les terminaux de paiement 810 dans le cadre de l'exécution des applications de service. C'est aussi ce module qui gère l'administration par un commerçant de son service à partir d'un terminal d'administration 811. [0084] Un module 806 gère les communications de la plateforme avec les services tiers. Ces services sont typiquement sollicités par les scripts exécutés par le service d'orchestration de la plateforme lors de l'exécution des applications de service. On peut citer parmi ces services tiers, un service 812 de gestion des courriers élec- 13 troniques, des services bancaires 813 comme les services de paiement, les services électroniques marchands. Parmi ces services, on trouve aussi des services tel que l'extranct 814 d'un commerçant. En effet, certaines applications de services peuvent nécessiter des données propres au commerçant, par exemple pour appliquer des règles telles que l'attribution d'une promotion selon des critères propres au commerçant, ou encore la proposition d'un questionnaire aux clients ayant dépensés au moins 100 euros dans le mois. [0085] La plateforme comporte également un module 807 qui donne un accès au gérant de la plateforme pour son administration. [0086] Dans l'exemple de réalisation, ces différents modules sont implémentés sous la forme de services dans une architecture orientée service (SOA pour Service Oriented Architecture en anglais). Tous ces services communiquent, par exemple, par le biais d'un service de messages (message broker en anglais). [0087] Dans un exemple de réalisation, le système d'exploitation est Linux, l'hyperviscur gérant la virtualisation des serveurs est Proxmox en développement et VMWare en production, les services sont gérés par Kubernetes/Docker, le service de messages est ActiveMQ, les services sont développés en Java/Spring, Node.js et/ou C/C++, la base de données peut être Cassandra. MongoDB ou ElasticSearch. [0088] Ainsi, le système proposé permet à un commerçant de définir rapidement une ap- plication de service (aussi appelé « workflow ») pour ses terminaux de paiement, de la déployer sans délai. Ensuite, cette application peut être modifiée à tout moment. De nouveaux services apparaissant sur le marché peuvent être intégrés à la plateforme et rendu disponibles aux commerçants qui peuvent alors l'intégrer à leur application de paiement. Tout ceci peut être fait sans devoir supporter les coûts est les délais afférents aux développements d'applications de service propriétaires. [0089] La figure 9 est un bloc-diagramme schématique d'un dispositif de traitement de l'information 900 pour la mise en oeuvre d'un ou plusieurs modes de réalisation de l'invention. Le dispositif 900 de traitement de l'information peut être un périphérique tel qu'un micro-ordinateur, un poste de travail ou un terminal mobile de télécommunication. Le dispositif 900 comporte un bus de communication connecté à : [0090] - une unité centrale de traitement 901, tel qu'un microprocesseur. notée CPU ; [0091] - une mémoire à accès aléatoire 902. notée RAM, pour mémoriser le code exécutable du procédé de réalisation de l'invention ainsi que les registres adaptés à enregistrer des variables et des paramètres nécessaires pour la mise en oeuvre du procédé selon des modes de réalisation de l'invention ; la capacité de mémoire du dispositif peut être complétée par une mémoire RAM optionnelle connectée à un port d'extension, par exemple ; [0092] - une mémoire morte 903, notée ROM, pour stocker des programmes informatiques 14 pour la mise en oeuvre des modes de réalisation de l'invention ; [0093] - une interface réseau 904 est normalement connectée à un réseau de communication sur lequel des données numériques à traiter sont transmis ou reçus. L'interface réseau 904 peut être une seule interface réseau, ou composée d'un ensemble d'interfaces réseau différentes (par exemple filaire et sans fil, interfaces ou différents types d'interfaces filaires ou sans fil). Des paquets de données sont envoyés sur l'interface réseau pour la transmission ou sont lues à partir de l'interface de réseau pour la réception sous le contrôle de l'application logiciel exécuté dans le processeur 901 ; [0094] - une interface utilisateur 905 pour recevoir des entrées d'un utilisateur ou pour afficher des informations à un utilisateur ; [0095] - un dispositif de stockage 906 tel que décrit dans l'invention et noté HD ; [0096] - un module d'entrée/sortie 907 pour la réception / l'envoi de données depuis / vers des périphériques externes tels que disque dur, support de stockage amovible ou autres. [0097] Le code exécutable peut être stocké dans une mémoire morte 903, sur le dispositif de stockage 906 ou sur un support amovible numérique tel que par exemple un disque. Selon une variante, le code exécutable des programmes peut être reçu au moyen d'un réseau de communication, via l'interface réseau 904, afin d'être stocké dans l'un des moyens de stockage du dispositif de communication 900, tel que le dispositif de stockage 906, avant d'être exécuté. [0098] L'unité centrale de traitement 901 est adaptée pour commander et diriger l'exécution des instructions ou des portions de code logiciel du programme ou des programmes selon l'un des modes de réalisation de l'invention, instructions qui sont stockées dans l'un des moyens de stockage précités. Après la mise sous tension, le CPU 901 est capable d'exécuter des instructions de la mémoire RAM principale 902, relatives à une application logicielle. Un tel logiciel, lorsqu'il est exécuté par le processeur 901, provoque l'exécution des procédés décrits. [0099] Dans ce mode de réalisation, l'appareil est un appareil programmable qui utilise un logiciel pour mettre en oeuvre l'invention. Toutefois, à titre subsidiaire, la présente invention peut être mise en oeuvre dans le matériel (par exemple, sous la forme (l'un circuit intégré spécifique ou ASIC). [0100] Naturellement, pour satisfaire des besoins spécifiques, une personne compétente dans le domaine de l'invention pourra appliquer des modifications dans la description précédente. [0101] Bien que la présente invention ait été décrite ci-dessus en référence à des modes de réalisation spécifiques, la présente invention n'est pas limitée aux modes de réalisation spécifiques, et les modifications qui se trouvent dans le champ d'application de la présente invention seront évidentes pour une personne versée dans l'art. [Revendication 1] [Revendication 2] [Revendication 3] [Revendication 4] [Revendication 5] [Revendication 6] [Revendication 7] REVENDICATIONSPlateforme dc service pour terminaux dc paiement caractérisée en cc qu'elle comprend - des moyens (104) de programmation graphique d'une application de service à partir d'un ensemble dc services élémentaires accessibles depuis un terminal distant ; - des moyens dc générer à partir d'une application de service, un module logiciel client destiné à s'exécuter sur un terminal de paiement et un modifie logiciel serveur destiné à s'exécuter sur la plateforme de service ; - des moyens de transmission du module logiciel client sur le terminal de paiement ; et - des moyens d'exécuter le module logiciel serveur, le module logiciel serveur lorsqu'il est exécuté coopérant avec le module logiciel client exécuter sur le terminal de paiement pour réaliser l'application de service. Plateforme de service pour terminaux de paiement selon la revendication 1, caractérisée en ce que le module logiciel client est composé d'un ensemble d'au moins un script client. Plateforme de service pour terminaux de paiement selon la revendication 1, caractérisée en ce que : - le module logiciel serveur est composé d'un ensemble d'au moins un script serveur ; et - elle comporte un module orchestre de service pour ordonnancer et exécuter l'ensemble des scripts serveur. Plateforme de service pour terminaux de paiement selon la revendication 1, caractérisée en ce qu'elle comprend en outre des moyens (806) de communiquer avec des services externes accessible depuis le module logiciel serveur. Plateforme de service pour terminaux de paiement selon la revendication I. caractérisée en ce qu'elle comprend en outre des moyens (807) d'administration de la plateforme de service. Plateforme de service pour terminaux de paiement selon la revendication I. caractérisée en ce qu'elle comprend en outre un module (805) de gestion des communications avec le terminal de paiement et le terminal distant. Plateforme de service pour terminaux de paiement selon la reven- 16 dication 1, caractérisée en ce qu'elle comprend en outre un module matériel sécurisé (809). [Revendication 8] Plateforme de service pour terminaux de paiement selon la reven- dication 1, caractérisée en ce qu'elle comprend en outre une base de données (808). [Revendication 9] Plateforme de service pour terminaux de paiement selon la reven- dication 1, caractérisée en ce que les moyens de programmation graphique comprennent une liste de services élémentaires pouvant être sélectionnés. [Revendication 10] Plateforme de service pour terminaux de paiement selon la reven- dication 9, caractérisée en ce que chaque service élémentaire est représenté par un objet graphique comportant au moins une entrée et au moins une sortie, une sortie d'un objet graphique pouvant être connectée à une entrée d'un autre objet graphique. [Revendication 11] Plateforme de service pour terminaux de paiement selon la reven- dication 10, caractérisée en ce que au moins un objet graphique comprend en outre un point de branchement, le point de branchement pouvant être connecté à une entrée d'un autre objet graphique et une sortie d'un autre objet graphique pouvant être connecté au point de branchement. [Revendication 12] Plateforme de service pour terminaux de paiement selon la reven- dication 10, caractérisée en ce qu'au moins un objet graphique comporte au moins un contrôle permettant de définir un paramètre du service élémentaire représenté. [Revendication 13] Terminal de paiement caractérisé en ce qu'il comprend : - des moyens de connexion à une plateforme de service pour terminaux de paiement selon l'une des revendications 1 à 12 ; et - des moyens d'exécuter un module logiciel client transmis par la plateforme. [Revendication 14] Terminal de paiement selon la revendication 13, caractérisée en ce que le module logiciel client est composé d'un ensemble d'au moins un script client. [Revendication 15] Terminal de paiement selon la revendication 14, caractérisée en ce qu'il comporte un module orchestre de service pour ordonnancer et exécuter l'ensemble des scripts client. [Revendication 16] Système d'application de service pour terminaux de paiement ca- ractérisé en ce qu'il comporte : - une platetbrme de service pour terminaux de paiement selon l'une des 17 [Revendication 17] [Revendication 18] [Revendication 19] revendications 1 à 12 ; et - au moins un terminal de paiement selon l'une des revendications 13 à 15. Procédé d'exécution d'une application de service au sein d'un système d'application de service pour terminaux de paiement selon la revendication 16, caractérisé en ce qu'il comprend : - une étape de lancement d'un module logiciel client par le terminal de paiement ; - une étape de connexion du terminal de paiement à la plateforme de service pour terminaux de paiement ; - une étape de lancement d'un module logiciel serveur sur la plateforme de service pour terminaux de paiement ; - une étape d'exécution du module logiciel client et du module logiciel serveur, le module logiciel client et le module logiciel serveur coopérant pour réaliser l'application de service. Procédé selon la revendication 17, caractérisé en ce qu'il comporte en outre une étape de terminaison de l'application par le module logiciel client. Procédé selon la revendication 17, caractérisé en ce qu'il comporte en outre une étape de coopération du module logiciel serveur avec au moins un service externe à la plateforme de service pour terminaux de paiement.