> 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/guides-enrolment/fr/inscription/enrolment-form/social-sign-in.md).
# Connexion sociale
Fonctionnement de la connexion sociale sur les formulaires d’inscription avec Apple, Google, LINE et Facebook : identification, règles de correspondance et données client renvoyées.
L’authentification sociale (aussi appelée **connexion sociale**) permet aux clients de s’authentifier sur les formulaires d’inscription. Elle prend en charge **Se connecter avec Apple**, **Connexion Google**, **LINE Login**, et **Facebook Login**.
Elle fonctionne bien pour les parcours mobiles sur **iOS et Android**. Elle identifie les clients tôt dans le parcours. Elle évite la création de mot de passe. Elle réduit les doublons causés par des e-mails mal saisis.
Placez les boutons des fournisseurs au-dessus des champs du formulaire pour encourager la connexion en un clic.
{% hint style="info" %}
Cette page couvre **le fonctionnement de l’authentification sociale** dans The Wallet Crew (UX, correspondance, attentes en matière de données).
Elle ne **pas** couvre pas la configuration de la console du fournisseur. Utilisez ces guides de configuration :
* [Configuration de la connexion Apple](/guides-enrolment/fr/inscription/enrolment-form/social-sign-in/apple-sign-in.md)
* [Configuration de la connexion Google](/guides-enrolment/fr/inscription/enrolment-form/social-sign-in/google-sign-in.md)
* [Configuration de la connexion LINE](/guides-enrolment/fr/inscription/enrolment-form/social-sign-in/line-sign-in.md)
* [Configuration de la connexion Facebook](/guides-enrolment/fr/inscription/enrolment-form/social-sign-in/facebook-sign-in.md)
{% endhint %}
Exemples concrets
* **Inscription par QR en magasin :** Les clients scannent un QR et s’inscrivent en un clic.
* **Inscription d’un membre déjà inscrit :** Faites correspondre le profil et ignorez les champs déjà connus.
### Ce que cela fait
L’authentification sociale ajoute une **étape d’identité fournie par le fournisseur** à un formulaire d’inscription. The Wallet Crew l’utilise pour **résoudre un client tôt**. Ce contexte client change le comportement du formulaire.
Le client appuie sur un bouton de fournisseur. Le fournisseur authentifie le client. Il renvoie une charge utile d’identité. The Wallet Crew extrait les attributs utilisables de cette charge utile. The Wallet Crew applique ensuite les règles de correspondance configurées.
Un seul formulaire peut prendre en charge les nouveaux clients et les clients déjà inscrits. Si une correspondance est trouvée, The Wallet Crew charge le profil. Le client poursuit en tant que client connu. Si aucune correspondance n’est trouvée, le client continue comme nouveau. Un profil est créé lors de la soumission.
Un seul formulaire peut prendre en charge plusieurs fournisseurs d’authentification sociale en même temps (Apple, Google, LINE, Facebook).
### Ce que cette page ne couvre pas
La configuration du fournisseur est volontairement exclue de cette page.
Cette page ne **pas** comprend pas :
* captures d’écran des consoles Apple/Google/LINE/Facebook et configuration étape par étape
* ID client, ID de service, clés, secrets, URL de redirection ou listes d’autorisation de domaines
* Dépannage des erreurs spécifiques au fournisseur (`origin_mismatch`, configuration d’e-mail de relais Apple, etc.)
Utilisez pour cela les guides de configuration du fournisseur liés ci-dessus.
### Avantages
* Inscription plus rapide avec moins de champs saisis.
* Correspondance plus fiable grâce à l’e-mail vérifié par le fournisseur.
* Moins de doublons causés par des fautes de frappe dans l’e-mail.
* Meilleurs taux de complétion sur les parcours mobiles et QR (moins de friction).
* Un seul parcours d’inscription pour les nouveaux clients et ceux déjà inscrits.
#### Modèles UX (inscription rapide, faible friction)
L’authentification sociale fonctionne mieux lorsque le formulaire est conçu autour d’elle. Placez les boutons des fournisseurs **au-dessus** des champs du formulaire. Faites-en le chemin d’entrée par défaut sur mobile.
Après la connexion, masquez le champ e-mail. Ou rendez-le en lecture seule. Gardez une solution de repli comme « Continuer avec e-mail ». Ignorez les champs déjà connus pour les clients correspondants. Gardez le parcours du nouveau client court et ciblé.
{% hint style="warning" %}
Le « Masquer mon e-mail » d’Apple peut renvoyer un e-mail de relais. Évitez des formulations comme « nous avons trouvé votre e-mail personnel ». Les noms peuvent manquer. Ne bloquez pas la soumission sur le prénom/nom.
{% endhint %}
#### Rapidité et efficacité de l’inscription (quoi optimiser)
Optimisez pour un parcours qui se termine en quelques secondes. Supposez que le client est dans une file d’attente. Demandez uniquement ce qui est réellement nécessaire à l’inscription.
Préférez le profilage progressif après l’inscription. Utilisez l’authentification sociale pour capturer la clé de correspondance. Gardez les consentements explicites mais courts. Éloignez les longs textes juridiques du chemin critique. Rendez les erreurs spécifiques et actionnables.
Pour les parcours QR en magasin, supposez une mauvaise connectivité. Évitez les allers-retours réseau supplémentaires. N’ajoutez que les vérifications qui réduisent la vraie fraude.
#### Considérations de sécurité
L’authentification sociale est un fort **signal d’identité**. Ce n’est pas une sécurité complète du compte. Traitez-la comme la preuve que le client contrôle un compte du fournisseur.
Les contrôles du fournisseur, comme la confiance de l’appareil et le MFA, s’appliquent. Un e-mail vérifié est généralement renvoyé. Une règle de **propriété du compte** reste nécessaire dans le CRM. La liaison entre fournisseurs n’est pas automatique.
### Activation
L’authentification sociale est activée à deux endroits :
1. Configurez le fournisseur (Apple / Google / LINE / Facebook).
2. Activez le bouton du fournisseur sur le formulaire d’inscription.
La configuration du fournisseur est une configuration unique par fournisseur. Utilisez ces guides :
Une fois le fournisseur configuré, activez-le sur le formulaire d’inscription concerné. Voir [Formulaire d’inscription](/guides-enrolment/fr/inscription/enrolment-form.md) pour les paramètres du formulaire.
#### Considérations géographiques et de marché (quels fournisseurs proposer)
Le choix du fournisseur est souvent régional. Proposez les boutons que les clients utilisent déjà.
Se connecter avec Apple est une valeur par défaut solide dans les marchés très orientés iOS. Connexion Google est une valeur par défaut solide dans les marchés très orientés Android. Google peut être limité là où les services sont restreints. Connexion LINE est particulièrement pertinent au Japon, à Taïwan et en Thaïlande.
Pour les programmes qui fonctionnent dans plusieurs pays, gardez la simplicité. Utilisez **des formulaires d’inscription séparés par région**. Activez uniquement les fournisseurs pertinents sur chaque formulaire. Cela évite de dérouter les clients avec des boutons inutilisés.
#### Quelles données sont renvoyées
Une adresse e-mail **email** peut être attendue de chaque fournisseur. Le prénom et le nom dépendent du fournisseur. Traitez les noms comme facultatifs.
Concevez les règles de correspondance comme si seul l’e-mail était disponible dans le temps. Apple ne peut renvoyer les noms qu’une seule fois. Apple peut aussi renvoyer des e-mails de relais. Voir [Configuration de la connexion Apple](/guides-enrolment/fr/inscription/enrolment-form/social-sign-in/apple-sign-in.md) pour ces comportements.
{% hint style="info" %}
Facebook ne renvoie pas toujours un e-mail. Certains comptes n’ont pas d’e-mail utilisable, et certaines configurations ne le demandent pas. Conservez une solution de repli comme « Continuer avec e-mail ».
{% endhint %}
### FAQ
Le même client peut-il se connecter avec différents fournisseurs ?
Oui, mais le résultat dépend de la clé de correspondance utilisée. La plupart des configurations correspondent sur l’e-mail.
Si Apple et Google renvoient le **même e-mail**, ils se résolvent vers le même profil. S’ils renvoient des e-mails différents, des doublons peuvent apparaître. Cela arrive souvent avec les e-mails de relais Apple, les e-mails professionnels versus personnels, ou lorsque les clients modifient les paramètres du fournisseur.
Évitez les doublons en liant les identités dans le CRM. Enregistrez l’identifiant du fournisseur (par exemple, le sujet du fournisseur) pour le client lorsque c’est possible. Utilisez un second identifiant pour la correspondance lorsque l’e-mail n’est pas stable. Les choix courants sont l’ID de fidélité, le téléphone ou un code à usage unique.
A-t-on encore besoin de la vérification de l’e-mail ?
Généralement non, car le fournisseur vérifie l’e-mail.
Conservez la vérification de l’e-mail lorsqu’une étape d’assurance supplémentaire est requise. Les cas courants sont les comptes à forte valeur et les programmes réglementés. Un autre schéma courant est la vérification renforcée uniquement lorsque le risque est élevé. Exemple : authentification sociale pour l’inscription, puis vérification OTP avant les modifications du compte ou l’échange de récompenses.
Comment devons-nous gérer le « Masquer mon e-mail » d’Apple ?
Traitez les e-mails de relais Apple comme des e-mails valides. Ils peuvent toujours recevoir des messages. Ne supposez pas qu’ils correspondent à l’e-mail enregistré dans le CRM.
Lorsque des clients existent déjà dans un autre système, évitez la correspondance « e-mail uniquement » pour les publics très orientés Apple. Ajoutez un second identifiant dans le parcours. Utilisez un numéro de membre, un numéro de téléphone ou un code à usage unique. Le client peut aussi confirmer un identifiant connu après la connexion, avant le chargement d’un profil existant.
Que se passe-t-il si le client annule l’authentification sociale ou si le fournisseur échoue ?
Le client reste non authentifié. Le formulaire doit revenir au chemin de saisie alternatif. Une solution de repli courante est « Continuer avec e-mail ».
Gardez le message d’erreur spécifique. Utilisez une formulation comme « La connexion a été annulée » ou « La connexion a échoué ». Évitez les messages ambigus comme « Une erreur est survenue ». Si les échecs sont fréquents, vérifiez les paramètres des cookies tiers, les bloqueurs de fenêtres pop-up et les origines de redirection autorisées configurées chez le fournisseur.
Peut-on limiter les fournisseurs affichés (par pays ou par appareil) ?
Oui. Gardez l’ensemble des boutons minimal pour chaque audience. Proposez les fournisseurs que les clients utilisent déjà sur ce marché.
Pour les programmes déployés dans plusieurs pays, utilisez des formulaires d’inscription séparés par région. Activez uniquement les fournisseurs pertinents sur chaque formulaire. Pour une UX spécifique à l’appareil, mettez Apple en avant sur iOS et Google en avant sur Android, tout en proposant un chemin de repli pour les clients qui ne souhaitent pas utiliser l’authentification sociale.
---
# 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/guides-enrolment/fr/inscription/enrolment-form/social-sign-in.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.
