> 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/guides-design/fr/conception/pass-types-and-templates.md).

# Types de Carte et modèles

Comprenez les modèles de Carte et choisissez le bon type de Carte Apple Wallet et Google Wallet pour chaque cas d'utilisation.

Un modèle définit la structure et la conception d'une Carte Wallet. Il contrôle la mise en page, les libellés, les images et les données qui apparaissent sur la Carte.

Dans The Wallet Crew, chaque modèle part d'un **type de Carte**. Le type de Carte définit la forme de base et les contraintes requises par Apple Wallet et Google Wallet. Le modèle applique ensuite l'image de marque et les règles de mappage par-dessus.

<details>

<summary><strong>Exemples concrets</strong></summary>

* Fidélité en magasin : une Carte de fidélité affiche l'identifiant du membre, le niveau, les points et un code-barres.
* Cartes cadeau : une Carte à valeur stockée affiche le solde actuel et se met à jour après chaque utilisation.
* Coupons : une Carte d'offre affiche une date d'expiration et un code scannable, puis passe en état utilisé.
* Événements et visites : une Carte de billet d'événement affiche le lieu et l'heure, et prend en charge une lecture rapide à l'entrée.
* Adhésion et services : une Carte générique prend en charge les badges du personnel, les cartes de garantie ou les justificatifs de retrait.

</details>

## Modèle

Un modèle est la couche de configuration appliquée au-dessus d'un type de Carte Apple Wallet / Google Wallet. C'est là que l'image de marque et le mappage des champs sont définis une seule fois, puis réutilisés pour toutes les Cartes émises.

#### Ce qu'un modèle contrôle

Un modèle contrôle l'apparence de la Carte et la façon dont les données sont présentées :

* Conception visuelle (couleurs, logos, images).
* Disposition des champs (champs de face, champs de dos, messages).
* Libellés, ordre et formatage (y compris les traductions).
* Configuration du code-barres/QR et valeur affichée.
* Contraintes spécifiques au fournisseur (Apple vs Google).

#### Ce qu'un modèle ne contrôle pas

Un modèle n'est pas la source de vérité pour l'état métier. La validité, les soldes, les droits et les règles d'utilisation restent dans les systèmes en amont (CRM, moteur de fidélité, POS, billetterie, e-commerce ou backend).

The Wallet Crew affiche et met à jour la Carte Wallet à partir de ces données de source de vérité. Cela permet de garder la Carte cohérente avec les opérations, tout en bénéficiant de l'UX Wallet (accès hors ligne, présentation native à l'appareil et mises à jour).

#### Pourquoi un modèle est nécessaire

Apple Wallet et Google Wallet n'affichent pas de données arbitraires. Ils affichent une Carte qui suit un modèle prédéfini. Un modèle est le moyen pratique de garder ce modèle stable dans le temps.

Les modèles permettent de :

* Définir un schéma stable (quels champs existent et ce qu'ils signifient).
* Décider de ce qui apparaît sur la face avant par rapport à l'arrière.
* Conserver une image de marque cohérente sur les Cartes émises.
* Valider les contraintes tôt (champs obligatoires, formats pris en charge, tailles d'images).

### Choisir le bon type de Carte

The Wallet Crew prend en charge plusieurs types de Carte. Le bon choix dépend du flux opérationnel et des données qui doivent rester à jour.

#### Carte de fidélité

Utilisez une Carte de fidélité lorsque la Carte représente une relation client continue et doit être mise à jour au fil du temps.

Le contenu typique comprend un identifiant de membre, le niveau/statut, les points ou tampons, et des liens d'assistance. L'utilisation se fait généralement par code-barres/QR scanné au POS, suivi d'une mise à jour des points ou du niveau.

Plus de détails : [Configuration du modèle de carte de fidélité](/guides-design/fr/conception/loyalty-card-template-configuration.md).

#### Billet d'événement

Utilisez un billet d'événement lorsque le flux principal est un contrôle d'accès avec une lecture rapide à l'entrée.

Le contenu typique comprend le nom de l'événement, le lieu, la date/l'heure, le siège/la zone, la porte et un code-barres/QR. Les mises à jour sont utiles pour les changements d'horaire, les changements de siège ou les messages opérationnels.

Plus de détails : [Billet d'événement](/guides-design/fr/conception/event-ticket.md).

#### Carte cadeau

Utilisez une Carte cadeau lorsque la Carte représente une valeur stockée qui doit diminuer ou augmenter au fil du temps.

Le contenu typique comprend un identifiant de Carte, le solde et la devise, la date d'expiration le cas échéant, et un code-barres/QR de remboursement (ou NFC lorsque pris en charge). La mise à jour du solde après utilisation est l'exigence essentielle.

Plus de détails : [Carte cadeau](/guides-design/fr/conception/gift-card.md).

#### Offre

Utilisez une offre pour des coupons ou promotions limités dans le temps, généralement utilisables une seule fois.

Le contenu typique comprend un titre d'offre, une date d'expiration, des conditions et un code d'utilisation (code-barres/QR ou code promo). L'offre peut être mise à jour pour refléter l'état d'utilisation.

Plus de détails : [Offre](/guides-design/fr/conception/offer.md).

#### Générique

Utilisez une Carte générique lorsqu'aucun type de Carte dédié ne correspond au cas d'utilisation, mais qu'un justificatif scannable ou présentable reste nécessaire.

Les cas courants incluent les cartes d'adhésion qui ne sont pas des programmes de fidélité, les badges du personnel, les cartes de garantie, les réservations de service ou les justificatifs de retrait.

Plus de détails : [Générique](/guides-design/fr/conception/generic.md).

### Quand plusieurs modèles ont du sens

La plupart des projets commencent avec un modèle par type de Carte. Plusieurs modèles sont utiles lorsque les Cartes nécessitent des mises en page différentes, des contraintes différentes ou des règles de contenu différentes.

Les raisons courantes incluent :

* Plusieurs marques, programmes ou unités commerciales sous un même tenant.
* Des produits différents avec une densité d'information différente (standard vs VIP, basique vs premium).
* Des mentions légales ou des contacts d'assistance client différents selon le programme.
* Des langues différentes nécessitant des libellés et une structure de contenu différents.
* Des stratégies de code-barres ou des contextes de lecture différents (POS vs contrôle d'accès).

### Étapes suivantes

La création et la conception du modèle sont généralement faites une seule fois, puis itérées avec un retour opérationnel réel.

* Commencez par [Comment créer un modèle](/configure/fr/advanced-configuration/wallet/template-configuration/how-to-create-a-template.md).
* Pour les règles de mise en page et les exigences relatives aux ressources, utilisez [Conception des cartes (couleurs, images et champs)](/configure/fr/advanced-configuration/wallet/template-configuration/cards-design-colors-images-and-fields.md).
* Pour les programmes multilingues, utilisez [Comment traduire un modèle](/configure/fr/advanced-configuration/wallet/template-configuration/how-to-translate-a-template.md).

## FAQ

<details>

<summary><strong>Quelle est la différence entre un type de Carte, un modèle et une Carte ?</strong></summary>

Le type de Carte est le modèle de base requis par Apple Wallet et Google Wallet (fidélité, offre, carte cadeau, billet d'événement, générique).

Un modèle est une instance configurée de ce type de Carte dans The Wallet Crew. Il définit l'image de marque, les champs et les règles de mappage.

Une Carte est l'objet individuel installé par un client. Elle utilise un seul modèle à la fois et peut être mise à jour tout au long de son cycle de vie.

</details>

<details>

<summary><strong>Une Carte peut-elle être mise à jour après l'installation ?</strong></summary>

Oui. Les mises à jour sont une fonctionnalité essentielle de Wallet. The Wallet Crew met à jour la même Carte installée, donc les clients n'ont pas besoin de l'ajouter à nouveau.

</details>

<details>

<summary><strong>Un seul modèle suffit-il pour tout un programme ?</strong></summary>

Souvent oui. Un modèle par type de Carte est une base courante. Plusieurs modèles sont utiles lorsque différentes mises en page ou règles de contenu sont nécessaires.

</details>

<details>

<summary><strong>Un modèle décide-t-il si une Carte est valide ?</strong></summary>

Non. La validité et l'état métier restent dans les systèmes sources. Le modèle contrôle la façon dont cet état est affiché dans Apple Wallet et Google Wallet.

</details>


---

# 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/guides-design/fr/conception/pass-types-and-templates.md?ask=<question>&goal=<user_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.
