> 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/developers-guides/fr/integration-guides/wallet/enrolment-flows.md).
# Flux d'inscription
Comprendre comment les flux d'inscription créent des Cartes et quand les identifiants sont associés à une Carte.
## Parcours d'inscription
Un flux d’inscription est le moment où une Carte est créée et liée à un véritable dossier client ou entreprise. C’est à ce moment que les identifiants externes sont rattachés à la Carte pour la première fois. Cette étape est importante, car les rendus ultérieurs dépendent de ces identifiants pour récupérer les données en direct depuis les systèmes sources.
L’inscription n’est pas une étape de synchronisation ultérieure. La Carte est créée pendant le flux lui-même, puis l’artefact Wallet peut être construit à partir de ce nouvel enregistrement de Carte. Si les identifiants sont manquants ou incorrects au moment de l’inscription, les données fournies par les connecteurs manqueront lors des rendus ultérieurs.
Exemples concrets
* Un flux d’inscription au programme de fidélité crée une Carte après la création d’un compte client dans un CRM.
* Un flux d’achat de billet crée une Carte après le paiement et y associe l’ID du billet.
* Un flux de renouvellement d’adhésion crée une Carte de remplacement et la relie à l’enregistrement client existant.
### Ce que fait un flux d’inscription
Un flux d’inscription crée une Carte et y associe les données minimales nécessaires aux rendus futurs.
En pratique, cela signifie généralement :
1. Un système source ou un flux front-end identifie le client ou la transaction.
2. Le flux crée une Carte ou déclenche la création de Carte.
3. Les identifiants externes sont rattachés à la Carte au moment de la création.
4. La Carte peut ensuite être rendue pour l’installation dans Wallet.
L’enregistrement de Carte créé lors de l’inscription est volontairement léger. Il stocke les identifiants, des données supplémentaires facultatives et des champs internes de la plateforme. Les données sources restent dans les systèmes en amont.
Si vous avez besoin d’un rappel sur le modèle de données de Carte, commencez par [Données de Carte et synchronisation](/developers-guides/fr/pass-architecture/pass-data-and-sync.md).
### Schémas courants d’inscription
#### Flux Cinto SDK
Le Cinto SDK est l’option principale lorsqu’un flux web ou applicatif personnalisé doit créer des Cartes directement pendant l’inscription.
Ce schéma est courant lorsqu’un front-end gère déjà l’inscription, le paiement, l’enregistrement ou la finalisation du profil. Le SDK crée la Carte dans le cadre de ce flux et fournit les identifiants externes dont les connecteurs auront besoin plus tard.
Utilisez le [la documentation du SDK Cinto](/guides-enrolment/fr/inscription/on-your-website.md) pour le flux d’implémentation.
#### Inscription pilotée par le backend (API personnalisée)
Utilisez ce schéma lorsqu’un backend crée l’enregistrement client, commande, adhésion ou billet. Les identifiants externes doivent exister dans ce backend avant la création de la Carte.
Appelez `POST /cartes` avec ces identifiants pour créer la Carte. Voir [Cycle de vie de la Carte → Création d’une Carte](/developers-guides/fr/integration-guides/wallet/pass-lifecycle.md).
Construisez l’URL de livraison résultante avec un identifiant externe signé. Voir [URLs de livraison de Carte](/guides-enrolment/fr/inscription/download-pages.md).
#### Formulaire d’inscription intégré
La plateforme inclut également un formulaire d’inscription intégré avec une étape dédiée à la Carte.
Ce schéma est utile lorsque le projet souhaite un flux d’inscription hébergé plutôt qu’une implémentation entièrement personnalisée. La même règle s’applique : la Carte est créée pendant le flux, et les identifiants doivent être disponibles à ce moment-là.
{% hint style="info" %}
Cette page se concentre sur le moment de création et sur les identifiants requis. Les détails de configuration de l’interface utilisateur peuvent être documentés séparément si nécessaire.
{% endhint %}
#### Création déclenchée par la source
Certains projets créent des Cartes à partir d’un événement côté source plutôt qu’à partir d’un formulaire destiné à l’utilisateur. Dans ce modèle, un événement système externe déclenche la création de la Carte et le client installe la Carte plus tard.
Ce schéma est traité dans [Création de carte déclenchée par un connecteur](/developers-guides/fr/integration-guides/wallet/connector-triggered-pass-creation.md).
### Ce qui doit exister au moment de la création
L’entrée la plus importante au moment de l’inscription est l’ensemble des identifiants externes.
Sans eux, les connecteurs ne peuvent pas localiser le bon enregistrement client, commande, adhésion ou billet lors des rendus ultérieurs. Une Carte peut exister sans identifiants utiles, mais elle se comportera comme un enregistrement isolé, sans moyen fiable de récupérer les données source.
Des données supplémentaires peuvent également être définies au moment de la création lorsqu’une valeur doit résider sur la Carte elle-même. C’est utile pour des remplacements au niveau de la Carte ou pour des valeurs qui n’existent dans aucun système source.
Utilisez le [la documentation du SDK Cinto](/guides-enrolment/fr/inscription/on-your-website.md) pour les détails d’implémentation lorsque le flux crée des Cartes directement, et utilisez [Données de Carte et synchronisation](/developers-guides/fr/pass-architecture/pass-data-and-sync.md) pour savoir comment les identifiants et les données supplémentaires sont utilisés plus tard.
### Ce qui se passe après l’inscription
La création de la Carte ne crée pas de lien en arrière-plan qui maintienne automatiquement le contenu de Wallet à jour.
Après l’inscription, le contenu de Wallet ne change que lorsqu’un déclencheur de rendu se produit, comme l’installation, l’aperçu ou la mise à jour push. Chaque rendu récupère à nouveau les données en direct du connecteur en utilisant les identifiants stockés lors de l’inscription.
Utilisez [Premiers pas avec l’API](/developers-guides/fr/integration-guides/getting-started-with-the-api.md) pour les premiers appels de mise à jour propres au tenant une fois qu’une Carte existe déjà.
### Liste de vérification de validation
Un flux d’inscription valide doit confirmer trois choses.
* La Carte est créée avec succès.
* Les identifiants externes attendus existent sur la Carte.
* Un rendu ultérieur peut récupérer les données source à l’aide de ces identifiants.
Un schéma de validation rapide consiste à créer une Carte de test, à inspecter les identifiants dans le back-office, puis à déclencher un rendu ou une mise à jour push et à confirmer que les champs alimentés par le connecteur se résolvent correctement.
### FAQ
Les identifiants externes peuvent-ils être rattachés plus tard s’ils manquaient au moment de l’inscription ?
Ils doivent être considérés comme des données de création. Un flux est plus fiable lorsque les identifiants sont corrects au moment où la Carte est créée.
L’inscription stocke-t-elle les données client dans The Wallet Crew ?
Non. L’inscription crée l’enregistrement de Carte et stocke les identifiants ainsi que toutes les valeurs au niveau de la Carte qui doivent être conservées. Les données client restent dans les systèmes sources.
La création de Carte actualise-t-elle automatiquement le contenu de Wallet par la suite ?
Non. Les actualisations ultérieures dépendent toujours d’un déclencheur de rendu tel que l’installation, l’aperçu ou la mise à jour push.
---
# 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/developers-guides/fr/integration-guides/wallet/enrolment-flows.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.