FR 3025345 A1 20160304 FR 1458208 A 20140902 1 Procédé de traitement d'une transaction récurrente, dispositif et programme correspondant. 1. Domaine de l'invention L'invention se rapporte au traitement de données transactionnelles. L'invention se rapporte plus particulièrement au traitement récurrent de données transactionnelles. L'invention se rapporte plus spécifiquement au traitement récurrent de données transactionnelles nécessaires à la mise en oeuvre d'un paiement. 2. Art antérieur Par exemple, lorsqu'un utilisateur souhaite s'abonner à un service payant, le vendeur réclame à l'utilisateur un mode de paiement de ce service. Dans la grande majorité des cas, l'utilisateur qui souhaite effectuer un minimum d'opération fournit directement au vendeur des données bancaires (cela évite par exemple de transmettre un chèque par la poste). Ces données prennent principalement la forme de données de carte bancaire (numéro, nom du titulaire, date d'expiration et cryptogramme visuel). Ainsi, le vendeur dispose des données nécessaires pour effectuer le paiement de ses services. La problématique, du point de vue de l'utilisateur, consiste alors à se désabonner de ces services : en effet, lorsque le vendeur dispose des données qui permettent d'effectuer des paiements, il est souvent peu enclin à fournir à son client des moyens faciles de désabonnement à son client. L'intérêt du vendeur est plutôt de continuer à faire payer son service et donc à ne pas permettre à l'utilisateur de se désabonner aisément. En règle générale, l'utilisateur est obligé, pour se désabonner, de contacter le vendeur par courrier, à une échéance déterminée (par exemple 3 mois avant la date de renouvellement) pour faire part de son souhait de ne pas poursuivre l'abonnement au service. Souvent, l'utilisateur oublie et reste captif du vendeur et ce jusqu'à l'expiration des données de la carte bancaire. À ce moment, le vendeur doit nécessairement redemander des données de carte bancaire à l'utilisateur. Cette problématique est moins présente lorsqu'à la place de communiquer ses données de carte bancaires, l'utilisateur communique des données dites « SEPA ». En effet, le traitement du paiement est alors différent : il s'agit d'un traitement SEPA que l'utilisateur peut faire cesser à tout moment en communiquant à son fournisseur de services de paiements (par exemple sa banque) qu'il n'autorise plus de prélèvement SEPA en provenance du vendeur. Bien que plus aisé, cela nécessite quand même une intervention écrite auprès de l'établissement bancaire. Or, il arrive fréquemment que l'utilisateur constate le prélèvement SEPA après que celui-ci soit passé 3025345 2 sur son compte bancaire. Il doit donc entreprendre la démarche de radiation du vendeur après avoir été prélevé. D'un point de vue général, le désabonnement de services souscrits (qu'ils soient gratuits ou payants) est un problème. De par l'essor des moyens de communication, l'accès à 5 l'information est devenu si aisé que le modèle économique de l'information a lui-même évolué. On est passé, en quelques années, d'un modèle majoritairement payant (dans lequel l'utilisateur achète un contenu par l'intermédiaire d'un support physique -livre, journaux-), à un modèle majoritairement gratuit (dans lequel l'utilisateur consomme de l'information ou des données gratuitement en échange d'un profilage publicitaire). Ce changement de modèle, ou de 10 paradigme, n'a cependant pas modifié la manière dont l'utilisateur (ou le client) est perçu par le vendeur : il reste une source de revenus, soit directement soit indirectement. On pourrait croire, en revanche, que l'essor du numérique a rendu les choses plus facile pour l'utilisateur : il n'en est rien. Qu'il soit gratuit ou payant, se désabonner d'un service reste un problème majeur. Le procéder de l'invention vise à faciliter ce processus de désabonnement, en privant le 15 vendeur de sa source de revenus. 3. Résumé de l'invention L'invention ne pose pas au moins certains des problèmes de l'art antérieur. L'invention concerne un procédé de traitement d'une transaction récurrente d'accès à un bien ou un service, par un dispositif de traitement transactionnel, procédé comprenant une étape initiale d'obtention 20 d'une donnée représentative d'une instruction de traitement d'une transaction récurrente. Selon l'invention un tel procédé comprend : une étape de transmission d'un message d'interrogation d'un type donné, ledit message comprenant au moins une donnée d'identification de ladite transaction récurrente, à un terminal d'un utilisateur ayant préalablement souscrit un abonnement audit bien ou audit 25 service ; une étape d'insertion, dans une base de données de traitement différé, de ladite transaction récurrente ; traitement transactionnel en fonction de la survenance de l'un au moins des évènements suivants : 30 réception d'un message en provenance dudit terminal dudit utilisateur ; écoulement du délai pour effectuer ladite transaction récurrente. 3025345 3 Selon une caractéristique particulière, ledit procédé comprend une étape de calcul d'une échéance probable de ladite transaction en fonction d'un profil transactionnel dudit utilisateur. Selon une caractéristique particulière, ledit procédé comprend une étape de calcul d'une échéance probable de ladite transaction en fonction d'un profil transactionnel d'un fournisseur 5 dudit bien ou dudit service. Selon une caractéristique particulière, ledit type dudit message transmis audit terminal dudit utilisateur est un message d'acceptation tacite de ladite transaction récurrente. Ainsi, l'utilisateur peut être averti de la prochaine transaction, sans toutefois qu'il doive effectuer une action pour que celle-ci puisse se dérouler, et ainsi poursuivre l'abonnement au 10 bien ou service Selon une caractéristique particulière, ledit type dudit message transmis audit terminal dudit utilisateur est un message de refus tacite de ladite transaction récurrente. Ainsi, l'utilisateur peut simplement résilier son abonnement au bien ou au service en ne répondant pas au message qui lui est transmis. 15 Selon une caractéristique particulière, ladite d'insertion, dans la base de données de traitement différé comprend, conjointement, l'insertion dudit type dudit message et un délai de mise en oeuvre de ladite transaction. Selon un mode de réalisation particulier, ladite transaction récurrente est une transaction financière. 20 Selon un mode de réalisation particulier, une souscription préalable audit bien ou audit service a été effectuée en ligne en utilisant une carte bancaire. Sous une autre forme, l'invention se rapporte également à un dispositif de traitement d'une transaction récurrente d'accès à un bien ou un service, comprenant des moyens d'obtention d'une donnée représentative d'une instruction de traitement d'une transaction 25 récurrente, dispositif caractérisé en ce qu'il comprend : des moyens de transmission d'un message d'interrogation d'un type donné, ledit message comprenant au moins une donnée d'identification de ladite transaction récurrente, à un terminal d'un utilisateur ayant préalablement souscrit un abonnement audit bien ou audit service ; 30 des moyens d'insertion, dans une base de données de traitement différé, de ladite transaction récurrente ; 3025345 4 des moyens de traitement transactionnel en fonction de la survenance de l'un au moins des évènements suivants : réception d'un message en provenance dudit terminal dudit utilisateur ; écoulement du délai pour effectuer ladite transaction récurrente. 5 Un tel dispositif peut se présenter sou la forme d'un serveur ou d'un terminal. Sous une autre forme, l'invention se rapporte également à un système de traitement d'une transaction récurrente d'accès à un bien ou un service, comprenant des moyens d'obtention d'une donnée représentative d'une instruction de traitement d'une transaction récurrente, système caractérisé en ce qu'il comprend : 10 des moyens de transmission d'un message d'interrogation d'un type donné, ledit message comprenant au moins une donnée d'identification de ladite transaction récurrente, à un terminal d'un utilisateur ayant préalablement souscrit un abonnement audit bien ou audit service ; des moyens d'insertion, dans une base de données de traitement différé, de ladite 15 transaction récurrente ; des moyens de traitement transactionnel en fonction de la survenance de l'un au moins des évènements suivants : réception d'un message en provenance dudit terminal dudit utilisateur ; écoulement du délai pour effectuer ladite transaction récurrente. 20 Dans un tel système, les moyens utilisés sont répartis entre un serveur et un terminal, comme décrit par la suite. Selon une implémentation préférée, les différentes étapes des procédés selon l'invention sont mises en oeuvre par un ou plusieurs logiciels ou programmes d'ordinateur, comprenant des instructions logicielles destinées à être exécutées par un processeur de données d'un module 25 relais selon l'invention et étant conçu pour commander l'exécution des différentes étapes des procédés. En conséquence, l'invention vise aussi un programme informatique, susceptible d'être exécuté par un ordinateur ou par un processeur de données, ce programme comportant des instructions pour commander l'exécution des étapes d'un procédé tel que mentionné ci-dessus. 30 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. 3025345 5 L'invention vise aussi un support d'informations lisible par un processeur de données, et comportant des instructions d'un programme tel que mentionnées ci-dessus. Le support d'informations 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 5 ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple une disquette (floppy disc), un disque dur, un SSD, etc. D'autre part, le support d'information 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 10 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'information peut être un circuit intégré (type ASIC ou FPGA) 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. 15 Selon un mode de réalisation, l'invention est mise en oeuvre au moyen de composants logiciels et/ou matériels. Dans cette optique, le terme "module" peut correspondre dans ce document aussi bien à un composant logiciel, qu'à un composant matériel ou à un ensemble de composants matériels et logiciels. Un composant logiciel correspond à un ou plusieurs programmes d'ordinateur, un ou 20 plusieurs sous-programmes d'un programme, ou de manière plus générale à tout élément d'un programme ou d'un logiciel apte à mettre en oeuvre une fonction ou un ensemble de fonctions, selon ce qui est décrit ci-dessous pour le module concerné. Un tel composant logiciel est exécuté par un processeur de données d'une entité physique (terminal, serveur, passerelle, routeur, etc.) et est susceptible d'accéder aux ressources matérielles de cette entité physique (mémoires, 25 supports d'enregistrement, bus de communication, cartes électroniques d'entrées/sorties, interfaces utilisateur, etc.). De la même manière, un composant matériel correspond à tout élément d'un ensemble matériel (ou hardware) apte à mettre en oeuvre une fonction ou un ensemble de fonctions, selon ce qui est décrit ci-dessous pour le module concerné. Il peut s'agir d'un composant matériel 30 programmable ou avec processeur intégré pour l'exécution de logiciel, par exemple un circuit intégré, une carte à puce, une carte à mémoire, une carte électronique pour l'exécution d'un micrologiciel (firmware), etc. 3025345 6 4. Figures D'autres caractéristiques et avantages de l'invention apparaîtront à la lecture de la description suivante, donnée à titre d'exemple indicatif et non limitatif, et des dessins annexés, dans lesquels : 5 - la figure 1 présente les principales étapes de la technique proposée ; - La figure 2 représente schématiquement un serveur pour la mise en oeuvre du procédé décrit préalablement. 5. Description 5.1. Rappel du principe 10 Comme indiqué préalablement, dans le cadre d'abonnements à des biens ou des services, le paiement de ceux-ci est effectué de manière régulière (par exemple tous les mois, tous les trimestres). Or, bien que l'utilisateur n'ai fourni qu'une seule fois ses données bancaires au vendeur, celui-ci est en mesure de poursuivre le prélèvement sans accord explicite de l'utilisateur, et ceci pendant une période de temps relativement longue. Ainsi, lors de la souscription à 15 l'abonnement, trois parties (au moins) sont impliquées : l'utilisateur (acheteur), le vendeur et le fournisseur de services de paiements (une banque ou un établissement financier). Ensuite, lors du renouvellement (plus ou moins tacite) de l'abonnement, seuls le vendeur et le fournisseur de services de paiements sont impliqués. L'utilisateur n'a en quelque sorte plus de maitrise des débits effectués sur son compte bancaire. Par ailleurs, pour comprendre pleinement la 20 problématique, il faut également considérer le fait qu'au moins un quatrième acteur peut également être impliqué. Il s'agit du prestataire de services de paiement (par exemple une entreprise privée, prestataire technique, indépendante du fournisseur de services de paiements) qui est chargée par le vendeur de la mise en oeuvre effective des paiements, ce qui peut rendre encore plus opaque la situation du point de vue de l'acheteur. 25 Le principe général de l'invention consiste à établir un lien entre le fournisseur de services de paiements et l'utilisateur. Ce lien est utilisé afin de recueillir une autorisation (explicite ou tacite) de mise en oeuvre d'un service et donc de provoquer le paiement de celui-ci. Pour ce faire, les inventeurs ont proposé de requérir l'autorisation de l'acheteur (l'utilisateur) pour effectuer le paiement récurrent. Cette autorisation est soit tacite soit explicite, 30 en fonction de paramètres prédéterminés. Le lien entre l'utilisateur et le fournisseur de service de paiement est créé lors de la saisie, par l'utilisateur, des données nécessaires au paiement. À la différence de la technique actuelle, l'utilisateur est invité à saisir, en plus des données bancaires, 3025345 7 une donnée de contact (par exemple une adresse email ou un numéro de téléphone) et éventuellement des données relatives à la périodicité des paiements (cette périodicité peut également être fournie par le vendeur). L'utilisateur peut également être invité à indiquer s'il souhaite un paiement par défaut ou un refus de paiement par défaut (c'est-à-dire en cas 5 d'absence de réponse au message qui lui sera transmis), en fonction des modes de réalisation choisis. Le principe général de la technique, décrit en relation avec la figure 1, comprend les étapes suivantes : lorsqu'un paiement récurrent doit être effectué (par exemple un paiement trimestriel 10 pour une revue), le fournisseur de services de paiement transmet (100) un message à l'utilisateur (par exemple un courrier électronique ou un SMS). Ce message comprend les données nécessaires à l'identification du paiement à réaliser (bénéficiaire, somme, etc.) ; concomitamment, le fournisseur de services de paiement place (110) cette transaction en attente, pendant une durée prédéterminée (cette durée peut s'échelonner de quelques 15 heures à quelques jours). Cette durée est fonction d'une part de la rapidité avec laquelle le fournisseur de services de paiement est supposé s'acquitter de son obligation de réaliser le paiement et d'autre part de l'anticipation possible du paiement ; traitement transactionnel (120) en fonction de la survenance de l'un au moins des évènements suivants : 20 réception (130) d'un message en provenance de l'utilisateur ; écoulement (140) du délai pour effectuer la transaction. Dans un mode de réalisation complémentaire, dont l'avantage est de rapprocher encore plus l'utilisateur du fournisseur de services de paiements, la technique comprend un calcul d'échéance de renouvellement. Un tel calcul est utilisé afin d'anticiper le renouvellement et offrir 25 à l'utilisateur un délai suffisamment long pour lui permettre de répondre au message transmis. En effet, en fonction des vendeurs, le temps entre le moment où les instructions pour l'exécution du paiement sont transmises et le moment où le paiement doit être effectivement réalisé peut être très court. Dans un tel cas, il est probable que l'utilisateur n'aura pas le temps de transmettre des instructions. Dès lors, sur la base des données saisie par l'utilisateur lors du premier paiement, la 30 technique proposée effectue un calcul des échéances de paiement et transmet le message à l'utilisateur, en amont de la réception des instructions du vendeur. 3025345 8 Ce calcul peut être effectué de plusieurs manières différentes. Dans une première variante, ce calcul est basé sur une périodicité fournit par l'utilisateur (par exemple tous les trimestres). Dans ce cas, le serveur anticipe cette échéance d'un nombre de jours prédéterminé (nombre de jours éventuellement sélectionné par l'utilisateur) Dans cette variante, le calcul de 5 l'échéance est réalisé en fonction du profil transactionnel de l'utilisateur pour ce bien ou service, au moins certaines des données précitées constituant ce profil transactionnel. Dans une deuxième variante, ce calcul est basé sur des paiements similaires ou identiques en provenance du vendeur. Ce calcul comprend alors une étape d'identification, au sein d'une base de données, de transaction émanant du même vendeur et d'un montant identique afin d'en déterminer une 10 périodicité et une étape d'application d'un délai d'anticipation à cette échéance précalculée. Dans cette variante, le calcul de l'échéance est réalisé en fonction du profil transactionnel du fournisseur de bien ou service. S'en suit une transmission, à l'utilisateur, du message d'avertissement. Au moins deux modes de réalisation distincts de cette méthode peuvent être mis en 15 oeuvre. Un premier mode de réalisation peut être mis en oeuvre dans de cadre de traitements transactionnels dits « SEPA ». Un deuxième mode de réalisation peut être mis en oeuvre dans de cadre de traitements transactionnels dits « Carte Non Présente » (c'est-à-dire utilisant une transaction de type paiement par carte bancaire en ligne). Ce deuxième mode de réalisation va être décrit par la suite. Le premier mode de réalisation est sensiblement identique, en termes de 20 traitement, si ce n'est qu'il ne comprend pas de gestion des récurrences chez le fournisseur de services de paiements : c'est le vendeur qui gère la récurrence. Dans ce deuxième mode de réalisation, la gestion interne et anticipée de la récurrence par le fournisseur de services de paiements est donc un avantage concurrentiel supplémentaire pour le fournisseur le fournisseur de services de paiements. 25 Bien entendu, la technique décrite va bien au-delà du traitement des simples paiements. Elle s'inscrit plutôt dans une gestion d'une relation entre un fournisseur de bien et de services (même gratuit) et un utilisateur, lorsque la gestion de l'abonnement est confiée à un tiers. 5.2. Description d'un mode de réalisation Dans ce mode de réalisation le fournisseur de services de paiements (par exemple 30 l'organisme qui se charge d'effectuer la transaction de carte bancaire pour le compte des établissements bancaires, des clients et des vendeurs), met en oeuvre la méthode décrite préalablement par l'intermédiaire d'un serveur de traitement de données transactionnelles 3025345 9 (STDT) tenant compte des échéances des paiements réalisées à partir de données de cartes bancaires (il ne s'agit pas de traitement de type SEPA). Dans un premier mode de réalisation, cette mise en oeuvre consiste à permettre à l'utilisateur (au client payeur) de définir une périodicité de paiement au moment de saisir les 5 données de carte bancaires nécessaires au paiement. Une telle définition de périodicité est variable : elle dépend principalement du terminal mis utilisé pour effectuer le paiement. Dans le cas d'un paiement par l'intermédiaire d'un terminal se connectant à une page web d'un serveur du fournisseur de services de paiements, cette définition peut être mise en oeuvre en utilisant une liste déroulante de définition de périodicité (par exemple toute les semaines, tous les mois, tous 10 les trimestres, tous les ans,...). Dans un deuxième mode de réalisation, cette périodicité peut également faire partie des données fournies par le vendeur. En effet, à quelques exceptions près, le vendeur (en ligne) n'est pas celui qui effectue l'opération de paiement. Cette opération est déléguée à un fournisseur de services de paiement, quand bien même le paiement est répétitif ou récurrent. Deux possibilités peuvent ainsi être mises en oeuvre : soit le vendeur gère seul les 15 paiements récurrents et transmet à chaque échéance (mensuelle, trimestrielle, annuelle) une requête de paiement au serveur de traitement de données transactionnelles (STDT) : le numéro de l'échéance figure parmi les informations transmises au serveur de traitement de données transactionnelles (STDT); soit le vendeur délègue la gestion des paiements récurrents au fournisseur de services de paiements et ce dernier effectue les opérations nécessaires seul à 20 chaque échéance : le serveur de traitement de données transactionnelles (STDT) connaît le numéro de l'échéance. Connaissant ce numéro, le serveur de traitement de données transactionnelles (STDT) est en mesure de requérir une demande de confirmation de la part de l'acheteur. Sur la base notamment de ce numéro, le serveur de traitement de données 25 transactionnelles (STDT) effectue les opérations suivantes : Transmission (100), à un terminal de l'acheteur (TermU), d'un message (Msg) avertissant celui-ci de la transaction à effectuer ; accessoirement, ce message peut également contenir le montant de la transaction et/ou le bénéficiaire et/ou la périodicité. Le message est de deux types possibles : soit il s'agit d'un message d'acceptation tacite ; soit 30 il s'agit d'un message de refus tacite. Le type de message transmis à l'utilisateur est déterminé soit par l'utilisateur lui-même au moment de saisir les données de sa carte 3025345 10 bancaire lors du premier paiement, soit par le vendeur lors de la délégation de paiement au serveur de traitement de données transactionnelles. mise en attente (110) de la transaction ; cette mise en attente est effectuée en insérant la transaction courante (TrC), au sein d'une base de données de traitement différé (BD-TD). 5 Cette mise en attente se caractérise notamment par l'ajout, à l'enregistrement de la transaction courante (TrC) dans la base de données (BD-TD), du type de message (TypM) transmis et d'un délai de réponse à ce message (DeadL). traitement transactionnel (120) lorsque au moins un des évènements suivants se produit : réception (130), de la part d'un terminal de l'utilisateur, d'un message de 10 réponse ; dépassement (140) du délai de réponse au message transmis par le serveur de traitement de données transactionnelles (STDT). Le traitement transactionnel peut prendre deux formes la première forme consiste à effectuer la transaction, selon les modalités prévues ; cette 15 première forme est mise en oeuvre lors de la réception d'un message explicite d'acceptation de la part de l'utilisateur ou lors de l'expiration délai de réponse à un message d'acceptation tacite en provenance du serveur de traitement de données transactionnelles (STDT) ; la deuxième forme consiste à ne pas effectuer la transaction ; cette deuxième forme est 20 mise en oeuvre lors de la réception d'un message explicite de refus de la part de l'utilisateur ou lors de l'expiration délai de réponse à un message de refus tacite en provenance du serveur de traitement de données transactionnelles (STDT) ; La première forme de traitement transactionnel n'appelle pas de remarque particulière. Cette première forme de traitement comprend, en plus des actions usuellement mis en oeuvre 25 (débit/crédit, etc.), une étape de transmission, au terminal de l'utilisateur, d'un message de confirmation du déroulement de la transaction (comprenant le bénéficiaire et le montant débité). La deuxième forme de traitement comprend plusieurs caractéristiques nouvelles. D'une part, le refus de paiement doit être notifié au vendeur. Cette notification de refus de paiement consiste à transmettre, au vendeur, un message indiquant que l'utilisateur à refuser le 30 prélèvement. Ce message doit permettre de déclencher les actions nécessaires au niveau du vendeur afin par exemple de résilier l'abonnement au service. D'autre part, le refus est enregistré dans une base de données du serveur de traitement de données transactionnelles (STDT). Cet 3025345 11 enregistrement est ensuite utilisé pour identifier une éventuelle nouvelle occurrence de la transaction. En effet, il est possible, si ce n'est tout à fait probable, que certains marchands ne soient pas réellement satisfaits de la possibilité offerte à l'utilisateur de se désabonner « facilement » de 5 leurs services en n'acceptant plus les paiements programmés. Ce faisant, lorsque c'est le vendeur qui a l'initiative du paiement récurrent (c'est-à-dire qu'il n'a pas délégué le paiement récurrent au fournisseur de services de paiements, mais fait appel au fournisseur de services de paiements pour effectuer les paiements à la demande), il est envisageable que le vendeur, constatant le rejet du premier paiement, tente de représenter ce paiement une nouvelle fois. Dès lors, 10 l'enregistrement des paiements rejetés dans une base de données permet de vérifier, préalablement à la transmission du message pour le paiement au client, que ce paiement n'a pas déjà été rejeté. Ceci permet ainsi de ne pas solliciter le client inutilement et donc de lui apporter une meilleure expérience utilisateur. Dans un mode de réalisation spécifique, le terminal de l'utilisateur est un smartphone. Ce 15 terminal est utilisé pour gérer les abonnements de l'utilisateur. En d'autres termes, plutôt que de centraliser la transmission des messages au niveau d'un serveur, comme le serveur intermédiaire, cette gestion des abonnements est prise en charge par une application au niveau du terminal, sur communication des abonnements par le serveur. Lors de la première exécution de l'application sur le terminal, un lien sécurisé est créé entre le terminal et le serveur. L'application utilise un 20 identifiant (le même que celui fournit par l'utilisateur lors de la saisie des informations de paiement pour l'abonnement au bien ou service, soit par exemple l'adresse mail ou un numéro de téléphone ou les deux) pour identifier de manière unique l'utilisateur. Une fois que cette identification est réalisée, le serveur transmet, au terminal de l'utilisateur, des données permettant d'identifier les transactions récurrentes associées à cet utilisateur (vendeur, montant, 25 historique des débits antérieurs et date de ces débits, type de message choisi). Sur la base de ces données, l'application met en oeuvre les étapes suivantes : calcul des délais de prévenance en fonction des dates et d'un délai de prévenance défini par l'utilisateur ; déclenchement de l'affichage d'une notification sur le terminal de l'utilisateur lors de la 30 survenance d'un délai de prévenance avec affichage du type de message (acceptation tacite ou refus tacite); traitement transactionnel lorsque au moins un des évènements suivants se produit : 3025345 12 action effectué par l'utilisateur pour accepter ou refuser tacitement la transaction (en fonction du type de message) ; dépassement du délai de réponse au message. Dans ce cas de figure, la transaction n'est bien sûr pas traitée par le terminal de 5 l'utilisateur. Le traitement transactionnel effectué par le terminal se limite à la transmission d'un message à destination du serveur qui va lui-même traiter cette transaction. De manière régulière, l'application installée sur le terminal effectue des mises à jour des transactions récurrentes en établissant des transactions sécurisées avec le serveur. Dans ce mode de réalisation, la mise en oeuvre de la technique proposée est donc sensiblement similaire si ce 10 n'est que l'utilisateur dispose dans son terminal de toutes les données nécessaires aux calculs. 5.3. Serveur intermédiaire On décrit, en relation avec la figure 4, un dispositif mis en oeuvre pour effectuer le traitement des transactions récurrentes selon le procédé décrit préalablement. Par exemple, le serveur comprend une mémoire 41 constituée d'une mémoire tampon, une unité de traitement 15 42, équipée par exemple d'un microprocesseur, et pilotée par le programme d'ordinateur 43, mettant en oeuvre un procédé de traitement. À l'initialisation, les instructions de code du programme d'ordinateur 43 sont par exemple chargées dans une mémoire avant d'être exécutées par le processeur de l'unité de traitement 42. L'unité de traitement 42 reçoit en entrée une ou plusieurs données représentatives d'instructions 20 de traitement de transactions récurrentes. Le microprocesseur de l'unité de traitement 42 met en oeuvre les étapes du procédé selon les instructions du programme d'ordinateur 43 pour générer des messages à destination de de terminaux d'utilisateurs. Pour cela, le dispositif comprend, outre la mémoire tampon 41, des moyens de communications, tels que des modules de communication réseau, des moyens de transmission de 25 donnée et éventuellement un processeur de chiffrement. Ces moyens peuvent se présenter sous la forme d'un processeur particulier implémenté au sein du serveur, ledit processeur étant un processeur sécurisé. Selon un mode de réalisation particulier, ce serveur met en oeuvre une application particulière qui est en charge des calculs. Ces moyens se présentent également comme des interfaces de communications 30 permettant d'échanger des données sur des réseaux de communication, des moyens d'interrogations et de mise à jour de base de données,... 3025345 13 Le dispositif comprend également des modules pour la mise en oeuvre de la technique décrite, qui sont des modules : de transmission d'un message d'interrogation d'un type donné, ledit message comprenant au moins une donnée d'identification de ladite transaction récurrente, à un 5 terminal d'un utilisateur ayant préalablement souscrit un abonnement audit bien ou audit service ; d'insertion, dans une base de données de traitement différé, de ladite transaction récurrente ; de traitement transactionnel en fonction de la survenance de l'un au moins des 10 évènements suivants : réception d'un message en provenance dudit terminal dudit utilisateur ; écoulement du délai pour effectuer ladite transaction récurrente. Ces modules peuvent se présenter sous la forme de modules logiciels ou matériels (comme par exemple des composants électroniques programmables). 15 REVENDICATIONS1. Procédé de traitement d'une transaction récurrente d'accès à un bien ou un service, par un dispositif de traitement transactionnel (DTT), procédé comprenant une étape initiale d'obtention d'une donnée représentative d'une instruction de traitement (iTrR) d'une transaction récurrente (TrR), procédé caractérisé en ce qu'il comprend : une étape de transmission (100) d'un message (Msg) d'interrogation d'un type donné, ledit message (Msg) comprenant au moins une donnée d'identification (Id) de ladite transaction récurrente, à un terminal (TermU) d'un utilisateur ayant préalablement souscrit un abonnement audit bien ou audit service ; une étape d'insertion (110), dans une base de données de traitement différé (BD-TD), de ladite transaction récurrente ; traitement transactionnel (120) en fonction de la survenance de l'un au moins des évènements suivants : réception (130) d'un message (Msg2) en provenance dudit terminal (TermU) dudit utilisateur ; écoulement du délai pour effectuer ladite transaction récurrente (140). 2. Procédé selon la revendication 1, caractérisé en ce qu'il comprend une étape de calcul d'une échéance probable de ladite transaction en fonction d'un profil transactionnel dudit utilisateur. 3. Procédé selon la revendication 1, caractérisé en ce qu'il comprend une étape de calcul d'une échéance probable de ladite transaction en fonction d'un profil transactionnel d'un fournisseur dudit bien ou dudit service. 4. Procédé selon la revendication 1, caractérisé en ce que ledit type dudit message (Msg) transmis audit terminal dudit utilisateur est un message d'acceptation tacite de ladite transaction récurrente. 3025345 15 5. Procédé selon la revendication 1, caractérisé en ce que ledit type dudit message (Msg) transmis audit terminal dudit utilisateur est un message de refus tacite de ladite transaction récurrente. 5 6. Procédé selon la revendication 1, caractérisé en ce que ladite d'insertion (110), dans la base de données de traitement différé (BD-TD) comprend, conjointement, l'insertion dudit type dudit message et un délai de mise en oeuvre de ladite transaction. 7. Dispositif de traitement (DU) d'une transaction récurrente d'accès à un bien ou un 10 service, comprenant des moyens d'obtention d'une donnée représentative d'une instruction de traitement d'une transaction récurrente (TrR), dispositif caractérisé en ce qu'il comprend : des moyens de transmission (100) d'un message (Msg) d'interrogation d'un type donné, ledit message (Msg) comprenant au moins une donnée d'identification (Id) de ladite 15 transaction récurrente, à un terminal (TermU) d'un utilisateur ayant préalablement souscrit un abonnement audit bien ou audit service ; - des moyens d'insertion (110), dans une base de données de traitement différé (BD-TD), de ladite transaction récurrente ; - des moyens de traitement transactionnel (120) en fonction de la survenance de l'un au 20 moins des évènements suivants : réception (130) d'un message (Msg2) en provenance dudit terminal (TermU) dudit utilisateur ; écoulement du délai pour effectuer ladite transaction récurrente (140). 25 8. Produit programme d'ordinateur téléchargeable depuis un réseau de communication et/ou stocké sur un support lisible par ordinateur et/ou exécutable par un microprocesseur, caractérisé en ce qu'il comprend des instructions de code de programme pour l'exécution d'un procédé de traitement selon la revendication 1, lorsqu'il est exécuté par un processeur. 30