> 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 de Carte et synchronisation
Comprenez ce qu’une Carte stocke, quand les données du connecteur sont récupérées et comment fonctionnent les déclencheurs de rendu.
## 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 des systèmes स्रोत. Lorsqu'une Carte est rendue 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 de récupération 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 d'appel de connecteur ne modifient jamais ce que voit un client, et pourquoi la disponibilité des connecteurs a un impact direct sur 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 rendue.
* Une Carte d'événement stocke un ID de billet et récupère les dernières données de siège ou de porte lorsque une mise à jour est déclenchée.
* Une Carte d'adhésion stocke une surcharge locale dans les 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 API |
| Identifiants externes | Paires clé-valeur reliant la Carte aux systèmes source | Oui | Recherches du connecteur au moment du rendu |
| Données supplémentaires | Paires clé-valeur stockées directement sur la Carte | Oui | Enrichir 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 | Uniquement pour la segmentation et le reporting |
{% 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 source 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 source. Ils indiquent à chaque connecteur quel enregistrement récupérer lorsque la Carte est construite.
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. Chaque valeur est l'identifiant utilisé par ce système source.
Les identifiants externes ne sont pas affichés sur la Carte. Leur seul objectif est de permettre aux connecteurs de récupérer le bon enregistrement.
Si une Carte n'a 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 servent aussi à localiser une Carte dans l'API. La plupart des points de terminaison d'écriture acceptent `id.{key}={value}` comme 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](/api-reference/pass-management/pass.md) pour connaître toutes les règles de recherche.
Pour utiliser des identifiants externes dans une URL de livraison de Carte, voir [Pages de téléchargement](/guides-enrolment/fr/inscription/download-pages.md).
{% hint style="warning" %}
Un identifiant externe manquant ou incorrect empêche silencieusement un connecteur de récupérer des 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 par 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](/guides-enrolment/fr/inscription/on-your-website.md).
* **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 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 attache ensuite.
### Comment les connecteurs utilisent les identifiants externes
Les connecteurs récupèrent les données des systèmes source. Ils sont configurés et activés par locataire dans le cadre de la configuration de l'intégration.
Lorsqu'une Carte est rendue, 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 exacts des champs dépendent du connecteur et sont documentés dans la référence de ce connecteur.
L'appel du connecteur se produit au moment du rendu, et non à la création de la Carte. Il n'existe aucun job en arrière-plan qui pousse 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 du connecteur varient selon l'intégration. Utilisez la référence du connecteur pour les champs exposés par chaque connecteur.
{% endhint %}
### Données supplémentaires
Les données supplémentaires sont la solution de secours pour les valeurs qui ne proviennent pas d'un connecteur.
Il s'agit d'un magasin clé-valeur attaché directement à la Carte. Contrairement aux données de 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 avec 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](/api-reference/pass-management/pass.md) 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 attribution de magasin 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 du 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 portefeuille et la Carte est construite 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 [Premiers pas avec 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 le pipeline de rendu complet.
### FAQ
Les données client peuvent-elles être envoyées une seule fois et stockées dans The Wallet Crew ?
Non. La plateforme stocke uniquement 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 source, 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 la Carte installée à lui seul. Un déclencheur de rendu reste nécessaire, par exemple une mise à jour push ou une nouvelle installation.
Quelle est la première chose à 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 by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
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 what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
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.