> 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
## 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 la 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 même que le système source a 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 rend une carte dans quatre cas.
1. **Ajouter à Wallet** — un client appuie sur un bouton d’ajout et The Wallet Crew génère le fichier Apple `.pkpass` 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 avertit 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 pas les sources et ne reconstruit pas les cartes selon un calendrier. 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 la 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 du fournisseur** — 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 du 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 [le moteur de templating](/developers-guides/fr/integration-guides/wallet/liquid-templating.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 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 des fournisseurs sont récupérées au moment du rendu. The Wallet Crew ne met pas en cache à l’avance la sortie des fournisseurs sur l’enregistrement de la carte. Une carte rendue reflète les dernières données source 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 dépasse le délai d’attente, 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" %}
L’échec du fournisseur est la cause la plus courante 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 du fournisseur 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 prend une valeur vide et l’erreur est consignée. La génération de la carte se poursuit. La carte peut toujours ê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 même le début de l’appel à un fournisseur.
### Historique de la carte
La plateforme enregistre un événement de cycle de vie chaque fois qu’une carte est rendue, mise à jour ou livrée. Ces événements peuvent être interrogés via [l’API Insights](/developers-guides/fr/integration-guides/insights-api.md) et sont également exposés dans l’espace de supervision.
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 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 les systèmes source en continu. 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.
Par où faut-il commencer le dépannage du rendu ?
Commencez par les identifiants stockés, l’état de santé du fournisseur et les chemins des champs du modèle. Ces trois domaines 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 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/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 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.