> 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/pass-architecture/pass-data-and-sync.md).
# Données et synchronisation de la Carte
## Données et synchronisation de la Carte
Une Carte dans The Wallet Crew est un enregistrement léger. Elle stocke des identifiants et une petite quantité de données de remplacement spécifiques à la Carte. Elle ne conserve pas les données client provenant des systèmes sources. Lorsqu’une Carte est générée pendant l’installation, une mise à jour push ou un aperçu, les connecteurs interrogent les systèmes externes en direct pour récupérer les données nécessaires à la construction de la Carte.
Comprendre ce modèle d’extraction est essentiel avant de travailler avec l’API ou de configurer un modèle. Il explique pourquoi [les identifiants externes](/developers-guides/fr/pass-architecture/structure.md) sont le champ le plus critique d’une Carte, pourquoi les mises à jour qui ne déclenchent pas un appel de connecteur ne changent jamais ce qu’un client voit, et pourquoi la disponibilité des connecteurs affecte directement la livraison de la Carte.
Exemples concrets
* Une Carte de fidélité stocke un ID CRM et récupère le dernier solde uniquement lorsque la Carte est générée.
* Une Carte événementielle stocke un ID de billet et récupère les dernières données de siège ou de porte d’embarquement lorsqu’une mise à jour est déclenchée.
* Une Carte d’adhésion stocke une surcharge locale dans des données supplémentaires lorsqu’aucun système connecté n’expose cette valeur.
### Ce qu’une Carte stocke
Un enregistrement de Carte contient uniquement les données nécessaires pour identifier la Carte, récupérer les données externes et conserver de petites valeurs spécifiques à la Carte.
| Type de champ | Description | Persisté ? | Utilisé pour |
| ----------------------- | -------------------------------------------------------------------- | -------------------------------------- | ------------------------------------------------------------------------------------ |
| ID de la Carte | Identifiant interne de la plateforme. Opaque. Assigné à la création. | Oui | Références internes, certains points de terminaison de l’API |
| Identifiants externes | Paires clé-valeur reliant la Carte aux systèmes sources | Oui | Recherches de connecteurs au moment du rendu |
| Données supplémentaires | Paires clé-valeur stockées directement sur la Carte | Oui | Enrichissement de la Carte lorsque les données du connecteur ne sont pas disponibles |
| Métadonnées | Paires clé-valeur calculées automatiquement lorsque nécessaire | Recalculées, non définies manuellement | Segmentation et reporting uniquement |
{% hint style="info" %}
The Wallet Crew ne stocke pas de données personnelles par défaut. Les noms, soldes, points de fidélité et autres données client restent dans les systèmes sources et sont récupérés au moment du rendu.
{% endhint %}
### Identifiants externes
Les identifiants externes sont le pont entre une Carte et les données sources. Ils indiquent à chaque connecteur quel enregistrement récupérer lorsque la Carte est générée.
Utilisation [Structure](/developers-guides/fr/pass-architecture/structure.md) pour la vue back-office de l’emplacement de ces identifiants sur une Carte.
Une Carte peut contenir plusieurs identifiants externes, souvent un par système connecté. Une Carte de fidélité peut utiliser un ID client CRM, un ID client Shopify et un numéro de programme de fidélité comme identifiants distincts. Chaque clé est une chaîne de caractères. Chaque valeur est l’identifiant utilisé par ce système source.
Les identifiants externes ne s’affichent pas sur la Carte. Leur seul but est de permettre aux connecteurs de récupérer le bon enregistrement.
Si une Carte ne possède pas d’identifiant externe pour un connecteur utilisé par le modèle, ce connecteur n’a rien à interroger. Ses champs ne sont pas disponibles au moment du rendu.
Les identifiants externes sont également utilisés pour localiser une Carte dans l’API. La plupart des points de terminaison d’écriture acceptent `id.{key}={value}` des paramètres de requête pour cibler une Carte sans connaître son ID interne, par exemple `id.shopify.customerId=12345`. Plusieurs `id.*` paramètres sont combinés avec des conditions `ET` . Utilisez la [référence de l’API](https://docs.thewalletcrew.io/api-reference/pass-management/pass) pour les règles complètes de recherche.
Pour utiliser des identifiants externes dans une URL de livraison de Carte, consultez [Pages de téléchargement](/guides-enrolment/fr/inscription/pages-de-telechargement.md).
{% hint style="warning" %}
Un identifiant externe manquant ou incorrect empêche silencieusement un connecteur de récupérer les données. Si une Carte s’affiche avec des champs vides, vérifiez que les identifiants externes corrects sont définis sur la Carte.
{% endhint %}
### Comment une Carte est créée
Les Cartes sont créées via des flux d’inscription, et non via une étape ultérieure d’importation de données.
Les principaux chemins de création sont :
* **Cinto SDK** — un développeur appelle le SDK pendant un flux d’inscription et fournit les identifiants externes au moment de la création. Utilisez la [documentation du Cinto SDK](https://docs.thewalletcrew.io/guides-enrolment/enrolment/on-your-website#npm-module).
* **Connecteur** — certains connecteurs peuvent créer automatiquement des Cartes lorsqu’un événement pertinent se produit dans le système source. Le connecteur définit les identifiants externes dans le cadre de la création de la Carte. Utilisez la [création de Carte déclenchée par un connecteur](/developers-guides/fr/integration-guides/wallet/connector-triggered-pass-creation.md).
* **Formulaire d’inscription** — la plateforme inclut un formulaire d’inscription intégré avec une étape de Carte. Utilisez les [flux d’inscription](/developers-guides/fr/integration-guides/wallet/enrolment-flows.md).
Dans tous les cas, les identifiants externes sont définis à la création. Il n’existe pas d’étape distincte de chargement des données qui les rattache ensuite.
### Comment les connecteurs utilisent les identifiants externes
Les connecteurs récupèrent les données des systèmes sources. Ils sont configurés et activés par tenant dans le cadre de la configuration de l’intégration.
Lorsqu’une Carte est générée, chaque connecteur configuré reçoit l’identifiant externe pertinent et appelle le système source. La réponse devient disponible dans le contexte de rendu sous forme de champs nommés tels que `firstName`, `loyaltyBalance`, ou `offerTitle`. Les noms de champs exacts dépendent du connecteur et sont documentés dans la référence de ce connecteur.
L’appel au connecteur se produit au moment du rendu, et non à la création de la Carte. Il n’existe aucun job d’arrière-plan poussant les données client dans The Wallet Crew. La Carte reflète ce que les connecteurs ont renvoyé lors du dernier rendu réussi.
{% hint style="info" %}
Les noms de champs des connecteurs varient selon l’intégration. Utilisez la référence du connecteur pour connaître les champs exposés par chaque connecteur.
{% endhint %}
### Données supplémentaires
Les données supplémentaires sont la solution de repli pour les valeurs qui ne proviennent pas d’un connecteur.
Il s’agit d’un magasin clé-valeur rattaché directement à la Carte. Contrairement aux données du connecteur, les données supplémentaires sont conservées dans l’enregistrement de la Carte. Elles ne dépendent pas d’un appel de connecteur pour être disponibles au moment du rendu.
Utilisez les données supplémentaires lorsqu’une valeur n’existe dans aucun système connecté ou lorsqu’une surcharge au niveau de la Carte doit être stockée directement sur la Carte.
Les champs de données supplémentaires sont disponibles dans le contexte de rendu sous la forme `additionalData.fieldName`.
Les données supplémentaires peuvent être définies de ces façons :
* Lors de la création de la Carte via le Cinto SDK, un flux d’inscription intégré ou un flux de connecteur qui définit des valeurs au niveau de la Carte
* Mises à jour par Carte via `PATCH /api/{tenantId}/passes/{passId}` ou `PATCH /api/{tenantId}/passes`
* Mises à jour en masse via `POST /api/{tenantId}/passes/pushUpdate`
* Modifiées manuellement dans le back-office
Les mises à jour sont fusionnées dans les données supplémentaires existantes. Les clés non incluses dans une requête sont conservées.
Utilisez la [référence de l’API](https://docs.thewalletcrew.io/api-reference/pass-management/pass) pour les détails du corps de la requête.
### Métadonnées
Les métadonnées sont un ensemble de paires clé-valeur calculées automatiquement par la plateforme. Elles ne sont pas définies manuellement et ne sont pas affichées sur la Carte.
Les métadonnées servent à la segmentation et au reporting. Elles permettent de regrouper, filtrer et cibler les Cartes avec des valeurs calculées telles qu’un niveau, une affectation de boutique ou une fenêtre d’expiration.
Les métadonnées sont recalculées automatiquement lorsque nécessaire pendant le rendu, les mises à jour et les flux de génération de données. Les déclencheurs exacts sont internes et peuvent changer. Si un connecteur échoue et que les données requises ne sont pas disponibles, le recalcul des métadonnées peut également échouer.
{% hint style="warning" %}
Les métadonnées sont réservées à un usage opérationnel. Ne les utilisez pas pour afficher des informations sur une Carte. Les valeurs de métadonnées ne sont pas disponibles pour les champs d’affichage de Wallet.
{% endhint %}
### Quand les données sont récupérées
Les données du connecteur sont récupérées dans quatre situations :
1. **Installation de la Carte** — un client ajoute la Carte à un wallet et la Carte est générée pour la première fois.
2. **Mise à jour push** — une mise à jour est déclenchée via l’API ou par un événement d’intégration. Pour les premiers appels API, commencez par [Prise en main de l’API](/developers-guides/fr/integration-guides/getting-started-with-the-api.md).
3. **Aperçu back-office** — un aperçu de Carte est demandé depuis le back-office.
4. **API de rendu** — le point de terminaison de rendu est appelé explicitement.
Il n’y a pas de sondage en arrière-plan. En dehors de ces déclencheurs, la Carte installée sur un appareil ne change pas.
Utilisation [Comment une Carte est rendue](/developers-guides/fr/pass-architecture/how-a-pass-is-rendered.md) pour l’ensemble du pipeline de rendu.
### FAQ
Les données client peuvent-elles être envoyées une seule fois et stockées dans The Wallet Crew ?
Non. La plateforme ne stocke que l’enregistrement de la Carte, les identifiants, les données supplémentaires et les métadonnées calculées. Les données client restent dans les systèmes sources, sauf si une intégration spécifique est conçue autrement.
Pourquoi une Carte affiche-t-elle encore d’anciennes données après une mise à jour de la source ?
Un changement dans la source ne met pas à jour à lui seul la Carte installée. Un déclencheur de rendu reste nécessaire, par exemple une mise à jour push ou une nouvelle installation.
Quel est le premier champ à vérifier lorsque les données du connecteur sont manquantes ?
Vérifiez d’abord les identifiants externes sur la Carte. Si le connecteur ne peut pas faire correspondre un enregistrement source, ses champs seront absents du contexte de rendu.
---
# 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/pass-architecture/pass-data-and-sync.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.