> For the complete documentation index, see [llms.txt](https://docs.thewalletcrew.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.thewalletcrew.io/configure/fr/advanced-configuration/enrolment-form/enable-email-check-in-on-enrolment-forms.md).
# Activer l'enregistrement par e-mail sur les formulaires d'inscription
Vérifiez si un client existe déjà à partir de son e-mail, puis sécurisez l'accès avec une vérification facultative avant l'émission d'une carte.
La plupart des formulaires d'inscription sont remplis par des personnes qui sont déjà clientes. Quelqu'un qui a rejoint un programme de fidélité il y a deux ans, a changé de téléphone et scanne maintenant un code QR en magasin n'a aucun souvenir d'avoir un compte, et aucune raison de penser que le formulaire lui demande d'en créer un deuxième. Sans vérification, c'est exactement ce qui se produit : un profil dupliqué, une deuxième Carte, et un solde de points réparti entre deux enregistrements que le support doit fusionner manuellement.
La vérification par e-mail empêche cela. Elle place l'adresse e-mail en premier, avant toute autre collecte, et l'utilise pour déterminer dans quel parcours se trouve le client. Une adresse reconnue poursuit comme client déjà connu. Une adresse non reconnue poursuit comme nouvelle inscription. Le client voit un seul formulaire dans les deux cas.
Comme une adresse e-mail seule ne prouve pas la propriété, reconnaître quelqu'un n'est pas la même chose que lui en donner l'accès. On demande à un client de retour de confirmer l'adresse avant que le profil existant et sa Carte ne soient transmis.
Exemples réels
* Un détaillant lance une campagne QR en magasin. La moitié des personnes qui le scannent sont déjà dans le programme de fidélité ; la vérification par e-mail renvoie leur Carte existante au lieu d'en créer une deuxième.
* Une marque qui migre d'un système de cartes plastiques permet aux clients de récupérer leur compte existant par e-mail plutôt que de se réinscrire à partir de zéro.
* Un programme offrant des avantages à forte valeur exige un code de vérification à chaque vérification, afin qu'une adresse mal saisie ou devinée ne puisse pas faire apparaître le solde de quelqu'un d'autre.
* Un formulaire de campagne ne demande qu'une adresse e-mail et ne collecte les autres champs que lorsque l'adresse est nouvelle.
## Comment le parcours se scinde
Le formulaire s'ouvre sur un seul champ e-mail. Lorsque l'adresse est soumise, The Wallet Crew recherche un profil client correspondant et le parcours se scinde.
Si aucun profil ne correspond, le formulaire continue comme une inscription normale : les autres champs sont collectés, un profil est créé, et la Carte est émise à la fin du flux.
Si un profil correspond, le client est mis au défi de prouver que l'adresse lui appartient. Le défi est envoyé par e-mail, soit sous forme de code à usage unique à saisir dans le formulaire, soit sous forme de lien qui renvoie le client au flux déjà authentifié. Une fois le défi réussi, le profil existant est réutilisé et sa Carte est émise ou réémise, plutôt qu'un nouvel enregistrement ne soit créé.
{% hint style="info" %}
L'identification n'est pas le consentement. Reconnaître un client de retour ne dit rien sur le fait qu'il ait accepté le marketing. Le consentement est recueilli explicitement, et séparément, dans le formulaire.
{% endhint %}
## Ce qui doit être en place d'abord
La vérification par e-mail dépend de trois éléments configurés sur le tenant.
Un **fournisseur d'e-mails** doit être connecté, car le défi est délivré sous forme d'e-mail. Tous les fournisseurs pris en charge fonctionnent ; le parcours concerné est l'e-mail de défi qui authentifie un client avec un code de vérification ou un lien. Sans fournisseur, l'étape de vérification peut reconnaître un client mais ne peut pas terminer le défi.
Le **configuration de sécurité** contient les deux paramètres qui régissent le comportement. `accountChallengers` déclare comment un client peut être mis au défi, et `checkInSecurityMode` détermine avec quelle rigueur la vérification est appliquée. `checkInSecurityMode` est défini sur full par défaut, ce qui constitue le point de départ sûr : un profil correspondant n'est jamais libéré sans réussite du défi.
Le **formulaire d'inscription** doit exécuter un flux qui inclut l'étape de vérification. Les formulaires sont configurés depuis Paramètres → Inscription, où chaque formulaire est lié au flux qu'il exécute.
{% hint style="warning" %}
Assouplir `checkInSecurityMode` en dessous de sa valeur par défaut signifie qu'un profil correspondant peut être renvoyé sur la seule foi d'une adresse e-mail. Quiconque devine ou saisit mal l'adresse d'un client voit alors les données de ce client. Traitez toute modification de ce paramètre comme une décision de sécurité, et non comme une optimisation de conversion.
{% endhint %}
## Personnaliser l'e-mail de défi
Le courriel de défi est un e-mail standard du tenant et est traduit via les mêmes fichiers de localisation que le reste du formulaire d'inscription. Les programmes qui ont besoin de faire varier le message — un modèle différent par campagne, par langue ou par type de Carte — peuvent le faire avec le `runtime.emailAccountChallenger.templateFinder` hook de script, qui sélectionne le modèle à utiliser au moment où le défi est envoyé.
Le choix des mots compte ici plus qu'ailleurs. Un client qui a demandé une Carte de fidélité et reçoit un code sans explication risque de l'ignorer, et l'inscription est perdue à la dernière étape. Le message doit nommer la marque, dire à quoi sert le code et indiquer combien de temps il reste valide.
## Vérifiez la configuration
Testez les deux branches avant la mise en ligne du formulaire, en utilisant deux adresses qui peuvent réellement recevoir des e-mails.
Avec une adresse qui est **pas** dans la base clients, remplissez le formulaire et confirmez qu'un nouveau profil est créé, qu'une Carte est émise et qu'aucun e-mail de défi n'est envoyé.
Avec une adresse qui **est** dans la base clients, soumettez le formulaire et confirmez que l'e-mail de défi arrive, que le code ou le lien fonctionne, et que la Carte renvoyée ensuite appartient au profil existant plutôt qu'à un nouveau profil créé. Vérifiez ensuite la liste des clients : un second profil pour la même adresse signifie que l'étape de vérification ne s'est pas exécutée.
Enfin, soumettez l'adresse reconnue et abandonnez le défi. Le profil existant ne doit pas être libéré, et aucune Carte ne doit être émise.
## Pièges courants
Un e-mail de défi qui arrive en spam ressemble pour le client à un formulaire défectueux. La réputation de l'expéditeur et les enregistrements d'authentification sur le domaine d'envoi comptent autant que le formulaire lui-même.
Une base clients qui contient déjà des doublons ne sera pas dédupliquée en activant la vérification. L'étape empêche la création de nouveaux doublons ; elle ne fusionne pas les doublons existants.
Lorsque la connexion sociale est également activée sur le formulaire, le fournisseur a généralement déjà vérifié l'adresse, de sorte qu'un défi e-mail supplémentaire a tendance à ajouter de la friction sans ajouter de garantie. Ne gardez les deux que lorsque le programme a réellement besoin d'un second facteur, par exemple avant un échange à forte valeur.
## FAQ
La vérification par e-mail ralentit-elle l'inscription ?
Pour un nouveau client, non : aucun défi n'est envoyé et le formulaire se comporte comme toujours. Pour un client de retour, cela ajoute une étape, généralement plus rapide que de ressaisir une inscription complète et cela évite un compte dupliqué qu'il faudrait fusionner plus tard.
Que se passe-t-il si un client n'ouvre jamais l'e-mail de défi ?
Le flux ne se termine pas et aucune Carte n'est émise. Le profil existant reste inchangé. Le client peut recommencer le formulaire et demander un nouveau défi.
La vérification par e-mail peut-elle être utilisée avec la connexion sociale ?
Oui, et les deux identifient tôt un client de retour. La connexion sociale est généralement la plus fluide des deux sur mobile, car le fournisseur a déjà vérifié l'adresse. La vérification par e-mail est l'alternative lorsqu'un client n'utilise pas, ou ne veut pas utiliser, un compte social.
L'étape de vérification est-elle obligatoire ?
Par défaut, oui : `checkInSecurityMode` est définie sur full, donc un profil correspondant n'est libéré qu'après un défi réussi. Le paramètre peut être assoupli, mais le faire expose les données client existantes à toute personne qui soumet la bonne adresse e-mail.
À quelle adresse e-mail la correspondance s'effectue-t-elle ?
L'adresse stockée sur le profil client. Un client qui s'est inscrit avec une adresse et se connecte avec une autre est traité comme un nouveau client, ce qui est généralement la raison pour laquelle un doublon apparaît encore après l'activation de la vérification.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://docs.thewalletcrew.io/configure/fr/advanced-configuration/enrolment-form/enable-email-check-in-on-enrolment-forms.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.