On connaît dans l'état de la technique l'offre de la société NETCENTIVES, décrite notamment dans les brevets américains US05774870 ou US06009412.

On connaît aussi le brevet PCT W09921103 qui concerne un procédé et un système d'application de programmes d'incitation dans un réseau informatique dans lequel un hôte peut permettre à des sociétés de parrainage : - d'acheter des programmes d'incitation conditionnés à l'avance ou auto-générés ; - d'offrir ces programmes d'incitation à des consommateurs ; - de permettre à des sociétés de parrainage et à des revendeurs d'associer des récompenses aux programmes d'incitation ; - de proposer des récompenses intéressantes à des compagnies de parrainage, des revendeurs et des consommateurs ; - et de mémoriser et manipuler des bases de données contenant tout ce qui précède.

Un autre brevet PCT W09946708 divulgue un système permettant de définir, de distribuer électroniquement, d'afficher dynamiquement à l'attention d'un consommateur, d'échanger et de compenser des incitations promotionnelles sur un réseau. Un ou plusieurs paramètres associés à des promotions peuvent tre déterminés dynamiquement en fonction d'une ou plusieurs caractéristiques du consommateur, notamment sa localisation sur le réseau ou la promotion est visualisée.

Le brevet PCT W00060517 décrit un système et un procédé électronique de primes informatisé pour lequel le ciblage, la distribution, la sélection, la mémorisation, l'échange, la compensation, le remboursement et la gestion des données se fait électroniquement. Le système met les primes à disposition dans un système central de primes situé dans un système informatique, cible les primes sur des consommateurs ou groupes de consommateurs spécifiques, permet aux consommateurs de sélectionner les primes. Le système mémorise les noms ou numéros identifiant les consommateurs en regard des primes sélectionnées par les consommateurs, transmet les achats des consommateurs lorsque le consommateur fait un achat auprès d'un détaillant, et donne au détaillant l'identification du consommateur. Le détaillant se connecte ensuite au système central de primes et compare les achats aux primes sélectionnées mémorisées pour le consommateur. En cas de concordance, il y a application de la prime, et compensation automatique du consommateur. Le système prévoit également le remboursement automatique du détaillant. En outre, les données d'achat et d'échange de primes du consommateur sont gardées en mémoire et utilisées pour le ciblage de primes futures à destination du consommateur ou d'un groupe auquel appartient le consommateur. L'invention vise à proposer un système et un procédé permettant d'organiser l'attribution de points en temps réel, avec une grande sécurité contre les fraudes, par l'intermédiaire d'un serveur central et de ressources informatiques installées sur les serveurs de marchands affiliés d'une part, et de clients identifiés d'autre part.

A cet effet, l'invention concerne selon son acception la plus générale un procédé pour la fidélisation de clients caractérisé en ce qu'il comporte une étape d'enregistrement de données numériques d'identification des visiteurs de sites dans une première base de données

comportant une table d'enregistrement sur un serveur de fidélisation des identifiants uniques des visiteurs enregistrés et de données spécifiques, et d'enregistrement sur l'équipement du visiteur d'un fichier numérique contenant l'identifiant qui lui est attribué, et en ce qu'il comporte en outre des étapes d'enregistrement sur le serveur d'un site marchand affilié d'un fichier numérique produisant l'affichage d'un pictogramme actif comportant un lien vers un programme informatique de gestion de points, ledit fichier comportant un identifiant unique du marchand affilié, et des étapes d'attribution de points dé récompense consistant à enregistrer dans une base de données une table comportant un identifiant du visiteur et un compteur de points attribués, à préparer, en réponse à une activation par un utilisateur dudit lien apparaissant dans la page du site marchand, un fichier comportant au moins l'identifiant numérique du marchand et un identifiant du visiteur, à transmettre ce fichier au serveur de fidélisation, à procéder à une recherche de l'identifiant du visiteur, à incrémenter le compteur de points en fonction des informations contenues dans le fichier numérique dans le cas où le visiteur est déjà enregistré, et à transmettre un formulaire numérique d'enregistrement dans le cas contraire.

Selon un mode de réalisation préféré, le procédé selon l'invention comporte une étape de comparaison du fichier numérique transmis par l'équipement du visiteur avec un fichier numérique d'anomalies enregistré sur le serveur, et d'incrémentation du compteur du visiteur seulement lorsque ladite comparaison est positive.

De préférence, le procédé comporte une étape postérieure de transmission à l'équipement du visiteur par le serveur d'un fichier produisant la visualisation d'un message d'information de l'état du compteur du visiteur.

Selon une autre variante, le procédé comporte une étape de personnalisation des règles d'attribution de récompense consistant à sélectionner au moins un paramètre depuis le poste marchand et à enregistrer dans une table du serveur contenant l'identifiant du marchand et les paramètres d'attribution de récompenses.

La présente invention sera mieux comprise à la lecture de la description d'un exemple non limitatif de réalisation qui suit : La description qui suit concerne un exemple non limitatif de réalisation. Le procédé de fidélisation met en oeuvre un serveur de fidélisation relié au réseau Internet, ainsi que des serveurs marchands et des serveurs clients Les serveurs marchands sont constitués par les équipements informatiques reliés au réseau Internet, exploités par des affiliés du serveur de fidélisation.

Le système de fidélisation prévoit une première étape d'affiliation d'un nouveau marchand. Cette étape consiste à enregistrer sur une base de données un identifiant unique du nouveau marchand, ainsi que des informations relatives à son identité. Dans cette base de données sont également enregistrés des paramètres spécifiques à un programme de fidélisation sélectionné par ce marchand. Ces paramètres définissent les modalités et conditions d'attribution des récompenses : - action du visiteur déclenchant l'attribution de points, - durée de l'action et conséquence - autorisation de répétition ou non de l'action - périodicité des actions donnant lieu à une récompense Ces paramètres sont définis à l'aide d'un formulaire numérique transmis par le serveur au poste marchand, permettant de sélectionner les valeurs

correspondant à des procédures enregistrées dans une bibliothèque de procédures.

Cette étape de personnalisation du programme de fidélisation par le marchand va donner lieu à l'enregistrement d'un profil associé à l'identifiant du marchand, et à la transmission par le serveur d'un fichier numérique qui sera enregistré dans le site marchand. Ce fichier correspond par exemple à une ligne de code HTML inscrite dans la page du site marchand pour produire l'affichage d'un pictogramme lors de l'accès d'un visiteur à cette page. En outre, ce pictogramme sera associé à un lien mettant le visiteur en liaison avec le serveur de fidélisation.

Lorsque le visiteur active le lien, il provoque l'exécution d'un script réalisant l'envoi d'un fichier contenant un éventuel identifiant du visiteur, enregistré sous la forme d'un « cookie » et de l'identifiant du marchand.

Lorsque le serveur reçoit un message dans lequel l'identifiant du visiteur est inexistant, il transmet au poste visiteur un formulaire numérique lui permettant de s'inscrire. Cette inscription consiste à enregistrer dans une base de données des informations associées à un identifiant unique du visiteur.

Dans le cas où le visiteur est déjà enregistré, le serveur procède à une détection d'anomalies consistant à analyser le fichier de connexion, ainsi que les fichiers de connexion antérieurs provenant du mme visiteur, et à comparer ses fichiers avec un fichier d'anomalies. Dans le cas où cette comparaison fait apparaître que le nouveau fichier se révèle anormal, le processus d'attribution de récompense est interrompu.

Une anomalie consiste par exemple en un nombre excessif d'actions sur le mme lien par un mme visiteur, par exemple par utilisation d'un automate pour la

génération de requtes. Dans ce cas, pour éviter l'attribution injustifiée de récompenses, il conviendra d'interdire l'octroi de récompenses lorsque le nombre de requte dépasse une valeur seuil correspondant à une démarche abusive.

La description qui suit concerne un exemple de mise en oeuvre particulier de l'invention, visant à - simplifier le plus possible l'intégration des outils spécifiques à l'invention dans les sites affiliés, - éliminer le plus possible les transactions entre les sites affiliés et le serveur afin d'offrir un confort (vitesse) de navigation, - obtenir un risque de fraude proche du zéro.

L'invention propose différentes méthodes pour qu'un visiteur acquière des points de fidélité, c'est-à- dire qu'un affilié cède des points de fidélités à un visiteur : automatiquement depuis le site du serveur de points de fidélité (après un questionnaire, à date anniversaire, etc.) : aucun problème de sécurité puisque aucune transaction ne transite à travers le réseau. lors de la consultation d'une page Web (clic sur un lien, fréquence de visite, etc.) : voir partie « cessions indirectes ». suite à une action spécifique auprès du site affilié (achat en ligne, achat en boutique, jeu-concours etc.) : voir partie « cessions directes » A l'inscription sur le site du serveur, le visiteur (internaute souhaitant bénéficier des avantages proposés) reçoit un cookie indiquant son numéro de visiteur (ID). Ce numéro n'est lisible que par le site du serveur.

Il peut également tre lu ou modifié par l'utilisateur,

mais la seule conséquence d'un tel changement est de faire bénéficier un autre visiteur de ses gains.

Si le visiteur utilise plusieurs navigateurs ou qu'il perd sa configuration, un choix lui permet, sur le site du serveur, de redéfinir son cookie par simple ré- identification (login + mot de passe).

1. Cessions indirectes Les cessions indirectes ne sont pas gérées par l'affilié mais par le serveur.

Tout d'abord, l'affilié fournit au serveur une liste de conditions de gains ; par exemple : la condition portant le nom ACCUEIL01 est valable du ler avril 2000 au 30 avril 2000 et fait gagner au visiteur 5 points à raison d'un gain par semaine au plus.

Il s'agit d'une table vierge fournit au site affilié par le serveur : NomCo Date HeureD Date HeureF Type Valeur Acte Debut ebut Fin in Points Period Period Gen accue30/0 01/04/00 00 : 00 4/00 23 : 59 5 semaine 1 500 conco15/0 01/05/00 00 : 00 5/00 23 : 59 10 unique 1 283 Intégration des conditions de gain (cessions indirectes) Une condition de gain est représentée par : - nom condition : un identifiant choisi par l'affilié sur 40 caractères au plus. Seuls les chiffres et les lettres sont acceptés (pas de ponctuation ; ni d'accentuation, ni d'espace). Le serveur distinguera les majuscules/minuscules.

- une date et une heure de début de validité de la condition

une date et une heure de fin de validité de la condition le nombre de maxipoints gagnés la périodicité du gain : celle-ci se décompose en type de périodicité : minute, jour, semaine, mois, unique, datefixe minute nombre de minutes à attendre avant de gagner à nouveau jour nombre de jours semaine nombre de semaines mois une fois par mois unique on ne gagne qu'une fois datefixe on peut gagner une fois le dd/mm valeur périodicité : une valeur numérique ou dd/mm pour le type de périodicité « date fixe ». par exemple : type=semaine, valeur=2 signifie qu'il est possible de gagner 1 fois toutes les deux semaines le code « acte générateur » : dans la plupart des cas, il s'agira du code 500. Si le site affilié propose de gagner des Maxipoints suite à un jeu-concours, il faudra définir une (et une seule) condition portant ce code (283).

La liste de code, des actes générateur figure dans le tableau suivant : Code Actes générateurs 100 Achat 110 Annulation d'achat 220 Surf-offre spéciale 230 Achat-offre spéciale 500 Surf 520 Questionnaire 550 Bonus de parrainage 560 Bonus de bienvenue 600 Inscription newsletter 620 Inscription forum 901 Tirage au sort 902Quiz 903 Jeux-concours Afin d'éviter les erreurs en cascade, si une condition de gain porte le mme nom qu'une précédente condition, la seconde remplace la première.

Intégration sur le site affilié L'intégration des cessions indirectes est équivalente à l'intégration d'un tag HTML pour une bannière de publicité : L'affilié place sur son site un lien vers une image se trouvant sur le site du serveur. Cette image porte le nom ACCUEIL01. Le serveur reconnaît : - le visiteur par son ID unique stocké dans son cookie, - l'affilié par les en-ttes transmis par le navigateur - la condition par son nom"ACCUEIL01" Le serveur vérifie ensuite que la condition ACCUEIL01 est bel et bien remplie (dates de validité, périodicité, etc.). Dans les trois cas qui se présentent alors, les images résultantes sont intégrées au site Web de l'affilié et l'opération est transparente pour le visiteur : Les conditions de gain sont remplies : le visiteur est immédiatement crédité et le serveur lui envoie une image indiquant qu'il a gagné 5 points.

Le visiteur a déjà gagné les 5 points dans la semaine et il reçoit une image qui indique qu'il a déjà gagné pour cette condition.

L'utilisateur n'est pas reconnu comme visiteur : on lui propose de devenir visiteur ou, s'il l'est déjà, de redéfinir son cookie (image"à Gagner").

Un décompte précis des cessions indirectes sera fourni en fin de mois à chaque affilié afin que celui-ci puisse contrôler les transferts de points et réapprovisionner son compte lorsqu'il arrive à court de points.

Les conditions de gain seront transmises par l'affilié au moyen d'un message électronique chiffré.

Les données transmises au serveur seront toujours constituées de fichiers textes ASCII 7 bits. Si des caractères accentués doivent tre transmis, l'encodage pourra tre étendu à 8 bits et utiliser la norme ISO 8859- 1.

Les exemples indiqués concernent un affilié fictif « ACME » Toutes les données transmises par message électronique de l'affilié au serveur sont encodées avec la clé publique du serveur et signées de la clé privée de l'affilié.

Le sujet du message contiendra : [Conditions] lorsque le message électronique est une liste de conditions de gains Le corps du message contiendra les données à transmettre, chiffrées et signées.

La procédure de chiffrement est spécifique de l'environnement de l'affilié et de son choix d'implémentation (directement sur la machine serveur http ou sur une autre machine).

Transmission des conditions de gains

Le serveur fournit au site affilié un document de type table vierge contenant les champs à remplir.

L'affilié remplira cette grille (tous les champs sont obligatoires), l'exportera dans un fichier texte qu'il transmettra au serveur par message électronique à l'adresse électronique de l'administrateur du serveur, de façon chiffrée comme indiqué dans la procédure d'utilisation d'un cryptosystème.

L'affilié remplit cette table pour définir ses paramètres et la transmet au serveur. Un accusé de réception sera renvoyé au site affilié. Il indiquera : - les ajouts de conditions, - les remplacements de conditions, -les rejets : si une condition n'a pas pu tre traitée par l'automate Maxipoints, celui-ci indique la cause du rejet et l'affilié doit à nouveau envoyer cette condition après rectification.

Pour qu'un visiteur gagne des points lorsqu'il visionne une page html affiliée, celui-ci intègre à sa page un appel CGI au serveur sous la forme d'une image délocalisée (<IMG SRC="xxxx">). L'image renvoyée par le serveur dépend de la satisfaction (ou non) de la condition de gain (voir § cessions indirectes).

La page html de l'affilié inclut : <ATARGET="_blank"HREF="http ://www. maxipoints. co m/join. php ? FROM=identifiantaffilié"> <IMG SRC="http ://www. maxipoints. com/maxibanner. php ? identifi ant_affilié/NomCondition"WIDTH="118"ALIGN="BOTTOM" BORDER="0"></A> L'identifiant_affilié est délivré par le serveur.

Les images affichées seront d'un premier type "déjà gagné" :

- Lorsque le visiteur gagne 100 points ou est déjà passé sur une page gagnante.

- Lorsque le visiteur n'est pas reconnu comme un visiteur enregistré.

Une autre image pourra tre intégrée mais cette fois manuellement par l'affilié afin d'indiquer sur quelle rubrique le visiteur pourra gagner des points.

D'autres éléments graphiques pourront tre intégrés dans les pages du site affilié pour mettre en valeur le serveur sur son site.

2. Cessions directes Pour les achats en ligne notamment, les cessions de points seront codifiées par le serveur affilié et transmises par message électronique de façon chiffrée.

L'intért principal des cessions directes réside dans la libre intégration du principe de points sur le site web de l'affilié. Ce système ne se limite pas aux achats. Il est d'une grande souplesse, puisque l'affilié peut décider des actions qui engendreront un gain en fonction de son service. Par exemple, la rédaction d'un message dans un forum peut engendrer un gain de 50 points pour la personne qui rédige le message, et un gain de 5 points pour cette mme personne, chaque fois que quelqu'un ira lire son message... Ce système peut aussi s'appliquer à un jeu-concours organisé par l'affilié qui fera gagner différents lots après tirage au sort etc...

Cette souplesse implique simplement que le site affilié recueille l'identifiant du visiteur points pour pouvoir lui appliquer le gain. Cette démarche peut se réaliser de plusieurs façons, soit lors d'un achat, par exemple, lors de l'inscription des coordonnées de la personne, une fois les articles choisis, il est possible d'ajouter un champ « identifiant » à remplir, dans ce cas pour chaque achat, par le visiteur.

Ou encore, si le site gère des comptes pour ses propres visiteurs, ajouter dans sa fiche visiteur un champ spécifique pour l'identifiant, ainsi il n'est plus nécessaire de demander cet identifiant à chaque gain, le serveur sera capable de regarder au travers de sa fiche visiteur si la personne est enregistrée ou pas, afin d'attribuer un gain.

Lorsqu'un affilié souhaitera effectuer un don de points à un visiteur, il devra : codifier la cession selon la norme précisée au paragraphe Transmission des ventes (cessions directes) » ; le document indiquera le nom d'accès du visiteur, la date et l'heure de la cession (afin de gérer les cessions de maxipoints via maxipoints. com avec rétrocessions) et le nombre de maxipoints cédés.

- ce document sera ensuite chiffré avec la clé publique de Maxipoints, signé avec la clé privée de l'affilié et envoyé à une adresse message électronique Maxipoints spécifique : admin@maxipoints. com A réception de messages sur ce compte message électronique spécifique, le serveur va : - vérifier que l'émetteur du message est bien l'affilié (grâce à la signature), - déchiffrer le document avec la clé privée du serveur, - vérifier la validité du don (date de la condition, nombre de gains par période, etc.) - mettre le crédit en attente de validation : une fois la vente vérifiée par l'affilié, celui-ci validera (ou invalidera) le gain de points. Cette validation sera également

chiffrée et envoyée au serveur par message électronique. ou valider directement le gain si l'affilié peut s'assurer immédiatement de la validité de l'achat.

Un état mensuel récapitulera pour l'affilié l'ensemble des dons validés par le serveur.

Transmission des ventes (cessions directes) Si l'affilié doit s'assurer de la validité de la vente avant de reverser les points, il enverra d'abord via message électronique un fichier texte ayant le format suivant : (chaque ligne se termine par un retour chariot) AFFILIÉ : <nomduaffilié> LOGINVISITEUR : <login_du visiteur> TIMECODE : <date-et-heure_de_la_vente> NBPOINTS : <nombredepointsgagnés> CATEGORIE : <catégoriedevente> IDENTIFIANT : <identifiant_vente_du_affilié> DESCRIPTIF : <descriptif personnalisé de la transaction> DATEVALID : <date de validation de la transaction> <ligne_vide> Il est possible d'envoyer simultanément plusieurs cessions (par exemple une à chaque fin de journée). Pour cela, il suffit d'ajouter à la suite les informations de cessions en prenant soin de toujours laisser une ligne vide entre deux cessions.

Les valeurs transmises sont : <nomduaffilié> Ce nom est fourni par le serveur au site affilié. (identifiant affilié) Exemple : AFFILIÉ : ACME <login_du_visiteur>

Identifiant de l'utilisateur (saisi au moment de l'achat en ligne) ; Cet identifiant est composé au maximum de 20 signes alphanumériques.

Exemple : LOGINVISITEUR : PIERRE201 <date-et-heure-de-la-vente> Date et heure de la vente codé selon le masque : DD/MM/YYYY HH : MN : SS Exemple : TIMECODE : 21/05/2000 12 : 34 : 56 <nombredepointsgagnés> Nombre de points acquis suite à la vente Exemple : NBPOINTS : 50 <catégorie_de_vente> La catégorie de vente est le code correspondant au type de produit/service vendu selon la table ci-dessous.

Exemple (la vente correspond à des jouets) : CATEGORIE : 580 <identifiantventeduaffilié> Identifiant unique généré par l'affilié au moment de la vente (par exemple numéro de la facture) qui servira à valider la vente. Cet identifiant peut comporter jusqu'à 80 caractères alphanumériques (chiffres, lettres avec respect de la casse, ponctuation sur 7bits) Exemple : IDENTIFIANT : A45678_BA ? 12300/1220-2 DESCRIPTIF : <descriptif personnalisé de la transaction> Descriptif détaillé de la transaction qui sera indiquée au visiteur lors de la consultation de son compte.

Exemple : DESCRIPTIF : Jean-Hugues Mansard de Douomond.

Voyage Paris-Brives La Gaillarde le 18 nov 2000. Prix= 390 Francs. Ref : 123456789.

DATEVALID : <date de validation de la transaction> Date de validation de la transaction sur le compte du visiteur selon le masque : YYYYMMDD Exemple : DATEVALID : 20000109 Transmission des validations de ventes en ligne (cessions directes) Après vérification de la vente débouchant sur un gain de points ou si l'affilié n'a pas à attendre pour valider la vente, il enverra via message électronique une confirmation sous la forme d'un fichier texte ayant le format suivant : AFFILIÉ : <nomduaffilié> LOGINVISITEUR : <login_du_visiteur> TIMECODE : <date_et_heure_de_la_vente> NBPOINTS : <nombre_de_points_gagnés> CATEGORIE : <catégoriedevente> IDENTIFIANT : <identifiantventeduaffilié> VALIDATION : <OUI ou NON> <lignevide> Ces champs seront rigoureusement identiques à ceux envoyés lors de la transmission de la vente (voir ce augmentés du champ « validation » <OUI ou NON> Les 3 caractères de la réponse. Oui indique que la vente est validée et le visiteur est crédité de façon définitive ; Non indique que la vente a été refusée et les points ne sont pas crédités.

Exemple : VALIDATION : OUI Si la ligne VALIDATION est absente ou vide, le gain est mis en attente de validation et ne sera crédité que passé le délai prévu par l'affilié (minimum de 8 jours). Si dans cette période le gain est refusé (refus de

paiement, refus de livraison etc.), l'affilié doit retourner le mme fichier, avec la ligne VALIDATION : NON pour annuler le gain.

Là encore, il est possible de confirmer plusieurs ventes en séparant les informations par une ligne vide.

Retour des erreurs Si l'affilié nous indique une adresse message électronique de réponse pour les transactions, il pourra recevoir l'identique du fichier qu'il a transmis avec une ligne supplémentaire de résultat. Cette ligne de résultat s'explique de la façon suivante : Result : 0 tout est OK Result : 1 Login visiteur inconnu Result : 2 Nombre de points <=0 Result : 3 Affilié invalide Result : 4 Problème interne Result : 5 Exception pendant la mise à jour des fiches (date invalide etc.) Conventions Les données transmises seront toujours constituées de fichiers textes ASCII 7 bits. Si des caractères accentués doivent tre transmis, l'encodage pourra tre étendu à 8 bits et utiliser la norme ISO 8859- 1.

Les exemples indiqués concernent un affilié fictif « ACME » Chiffrement et transmissions de données via message électronique Toutes les données transmises par message électronique de l'affilié seront encodées avec la clé publique du serveur et signées de la clé privée de l'affilié.

Le sujet du message contiendra :

[Gain] lorsque le message électronique concerne une cession directe Le corps du message contiendra les données à transmettre, chiffrées et signées.

La procédure de chiffrement est spécifique de l'environnement de l'affilié et de son choix d'implémentation (directement sur la machine serveur http ou sur une autre machine).

4. Contrôle de l'affiliation Il s'agit de déterminer si les personnes ayant cliqué sur les liens affiliés du site du serveur arrivent bien sur le site de l'affilié demandé et si la page de cet affilié est bien vue en entier par l'internaute.

Lorsque l'internaute choisit de se rendre chez un des affiliés, il clique sur le lien de l'affilié correspondant.

Ce lien appelle une page du serveur qui permet, entre autres, de tracer les demandes d'accès vers le sites affiliés puis de les diriger vers le site affilié demandé.

Cependant, il est impossible de savoir si la demande a bien abouti et si l'internaute a bien vu la page de l'affilié en entier.

Le système mis en place, consiste à mettre sur le site de l'affilié, un marqueur (TAG) HTML à la fin de la page appelée depuis le serveur. Ce TAG appelle un script situé sur le site du serveur.

Ce script vérifiera si cette demande fait suite à la demande d'accès à un site affilié depuis le site du serveur, et le tracera en conséquence.

L'intégration sur le site affilié consiste à placer le TAG HTML suivant en fin de page : <IMG SRC="http ://www. maxipoints. com/maxiblanc. p hp ? identifiantaffilié" ALIGN="BOTTOM"BORDER="0">

Visuellement cette intégration n'affiche rien et ne modifie pas l'esthétique du site de l'affilié.

L'invention est décrite dans ce qui précède à titre d'exemple de réalisation et de mise en oeuvre du procédé de fidélisation.