> 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/how-a-pass-is-rendered.md).
# Comment une Carte est rendue
Comprenez quand The Wallet Crew rend une Carte, quelles données sont utilisées et comment se comportent les échecs de rendu.
## Comment une Carte est rendue
Lorsque The Wallet Crew livre une Carte à Apple Wallet ou Google Wallet, il construit l’artefact Wallet à partir de trois entrées : l’enregistrement de la Carte, le modèle de Carte et les données récupérées depuis les systèmes connectés. Cette page explique quand le rendu est déclenché, comment le pipeline s’exécute et ce qui se passe en cas d’échec.
Exemples concrets
* Un solde de fidélité change dans le CRM, mais la Carte installée ne change qu’après une mise à jour push ou un nouveau rendu.
* Un délai d’attente du connecteur empêche une mise à jour de billet d’atteindre Apple Wallet, alors que le système source possède déjà la nouvelle porte.
* Un chemin de modèle est incorrect, donc la Carte est livrée avec un champ vide au lieu d’échouer complètement.
### Lorsque le rendu est déclenché
La plateforme effectue le rendu d’une Carte dans quatre cas.
1. **Ajouter à Wallet** — un client appuie sur un bouton d’ajout et The Wallet Crew génère l’Apple `.pkpass` fichier ou crée ou met à jour l’objet Google Wallet.
2. **Mise à jour push** — une mise à jour est déclenchée via un appel API ou un connecteur, la plateforme reconstruit la Carte, puis notifie Apple via APNs ou Google via l’API Google Wallet.
3. **Aperçu** — un aperçu est demandé depuis le back-office ou depuis le point de terminaison de l’API d’aperçu.
4. **API de rendu du modèle** — l’API de rendu est appelée explicitement avec un modèle et un contexte de données.
Le rendu n’est pas continu. La plateforme n’interroge ni ne reconstruit les Cartes selon une planification. Une Carte reflète l’état des données au moment où le dernier rendu a été déclenché.
### Le pipeline de rendu
Le pipeline de rendu suit une séquence fixe.
1. **Charger l’enregistrement de la Carte** — The Wallet Crew récupère l’enregistrement de la Carte depuis la base de données, y compris ses identifiants externes, ses métadonnées et ses données supplémentaires.
2. **Charger le modèle de Carte** — le modèle YAML du type de Carte est chargé. Il définit le mappage des champs, les expressions Liquid, la configuration du code-barres, les images et les fournisseurs de données à appeler.
3. **Récupérer les données des fournisseurs** — tous les fournisseurs de données configurés sont appelés en parallèle. Chaque fournisseur utilise les identifiants de la Carte et renvoie des données externes qui sont fusionnées dans le contexte de rendu.
4. **Appliquer les modèles Liquid** — chaque champ du modèle est évalué par rapport au contexte de rendu. Cela produit les valeurs finales utilisées pour les champs Wallet.
5. **Générer l’artefact Wallet** — les valeurs résolues, les images et les paramètres du code-barres sont assemblés dans le bundle Apple `.pkpass` ou dans la charge utile de la classe et de l’objet Google Wallet.
6. **Livrer** — la Carte Apple signée est renvoyée à l’appelant. L’objet Google est créé ou mis à jour de serveur à serveur.
Pour les filtres et balises Liquid pris en charge dans The Wallet Crew, utilisez [Moteur de templating](/developers-guides/fr/integration-guides/wallet/templating-engine.md). Pour le comportement Liquid standard au-delà des extensions personnalisées, utilisez la [documentation DotLiquid](https://github.com/dotliquid/dotliquid/wiki/DotLiquid-for-Designers).
### Quelles données sont disponibles pour le modèle
Le contexte Liquid dépend du modèle de Carte et des fournisseurs de données configurés. Les sources courantes sont l’enregistrement de la Carte, les données supplémentaires stockées sur la Carte et les sorties des fournisseurs récupérées au moment du rendu.
* Champs de l’enregistrement de la Carte tels que l’ID de la Carte, le type de Carte, la date de création et la date de mise à jour.
* Données supplémentaires stockées sur la Carte.
* Sorties des fournisseurs telles que `customer.firstName`, `loyaltyBalance`, ou `offerTitle`.
{% hint style="info" %}
Les données du fournisseur sont récupérées au moment du rendu. The Wallet Crew ne met pas en cache à l’avance la sortie du fournisseur sur l’enregistrement de la Carte. Une Carte rendue reflète les données source les plus récentes disponibles lors du dernier rendu réussi.
{% endhint %}
{% hint style="warning" %}
Les métadonnées sont utilisées pour la segmentation opérationnelle et le reporting. Elles ne doivent pas être considérées comme une source d’affichage du Wallet.
{% endhint %}
### Que se passe-t-il en cas d’échec
#### Fournisseur de données indisponible
Si un fournisseur de données renvoie une erreur ou expire, tout le rendu échoue. La plateforme ne revient pas à une valeur précédente du fournisseur. L’appel de mise à jour renvoie une erreur et la Carte installée n’est pas modifiée.
{% hint style="warning" %}
La défaillance du fournisseur est la cause la plus fréquente d’une mise à jour de Carte qui n’atteint pas les appareils. Si une mise à jour semble échouer silencieusement, vérifiez que les points de terminaison des fournisseurs sont accessibles depuis les IP sortantes de The Wallet Crew répertoriées sur [Infrastructure](/developers-guides/fr/pass-architecture/infrastructure.md).
{% endhint %}
#### Variable Liquid manquante
Si une expression Liquid référence une variable qui n’est pas présente dans le contexte de rendu, le champ est résolu avec une valeur vide et l’erreur est consignée. La génération de la Carte se poursuit. La Carte peut quand même être livrée avec un champ vide.
#### Modèle manquant ou invalide
Si le modèle du type de Carte est manquant ou contient un YAML invalide, la génération échoue avant que tout appel au fournisseur ne commence.
### Historique de la Carte
La plateforme enregistre un événement du cycle de vie chaque fois qu’une Carte est rendue, mise à jour ou livrée. Ces événements peuvent être interrogés via [API Insights](/developers-guides/fr/integration-guides/insights-api.md) et sont également exposés dans l’espace de surveillance.
La plateforme ne stocke pas d’instantané du contenu de la Carte rendue. Lorsqu’une piste d’audit des valeurs rendues est nécessaire, la source de vérité reste les systèmes en amont qui ont fourni les données.
### FAQ
Pourquoi un changement de source n’apparaît-il pas immédiatement sur la Carte ?
La plateforme n’interroge pas en continu les systèmes sources. Un déclenchement de rendu reste nécessaire avant que la Carte installée ne change.
Une variable manquante fait-elle toujours échouer le rendu ?
Non. Les variables manquantes se résolvent généralement en valeurs vides. Les défaillances des fournisseurs et les modèles invalides sont plus susceptibles d’arrêter complètement le rendu.
Où le dépannage du rendu doit-il commencer ?
Commencez par les identifiants stockés, l’état des fournisseurs et les chemins des champs du modèle. Ces trois zones expliquent la plupart des défauts 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/how-a-pass-is-rendered.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.