# Types de cartes et modèles

Un modèle définit la structure et le design d'une Carte Wallet. Il contrôle la mise en page, les libellés, les images et les points de 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'identité visuelle et les règles de correspondance par-dessus.

<details>

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

* Fidélité retail : une carte de fidélité affiche l'identifiant du membre, le niveau, les points et un code-barres.
* Cartes-cadeaux : 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 devient utilisée.
* Événements et visites : une carte de billet d'événement affiche le lieu et l'heure, et prend en charge un scan rapide à l'entrée.
* Adhésions 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 par-dessus un type de carte Apple Wallet / Google Wallet. C'est là que l'identité visuelle et le mappage des champs sont définis une 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 devant, champs derrière, messages).
* Libellés, ordre et formatage (y compris les traductions).
* Configuration du code-barres/QR et sa valeur affichée.
* Contraintes spécifiques au fournisseur (Apple vs Google).

#### Ce que 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 de validation restent dans les systèmes en amont (CRM, moteur de fidélité, PDV, billetterie, e‑commerce ou un backend).

The Wallet Crew rend et met à jour la Carte Wallet à partir de ces données sources. Cela maintient la Carte cohérente avec les opérations, tout en bénéficiant de l'expérience Wallet (accès hors ligne, présentation native sur l'appareil et mises à jour).

#### Pourquoi un modèle est requis

Apple Wallet et Google Wallet ne rendent pas de données arbitraires. Ils affichent une Carte qui suit un modèle prédéfini. Un modèle est la façon pratique de maintenir 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 le devant vs l'arrière.
* Maintenir une identité visuelle cohérente entre les Cartes émises.
* Valider les contraintes tôt (champs obligatoires, formats supportés, 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 se mettre à jour dans le temps.

Le contenu typique inclut un identifiant de membre, le niveau/statut, des points ou tampons, et des liens d'assistance. La validation se fait souvent par un code‑barres/QR scanné au PDV, suivi d'une mise à jour des points ou du niveau.

Plus de détails : [Configuration du modèle de carte de fidélité](https://app.gitbook.com/s/WLc8AHXW4tdrAXUBfrYF/design/loyalty-card-template-configuration).

#### Billet d’événement

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

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

Plus de détails : [Billet d’événement](https://app.gitbook.com/s/WLc8AHXW4tdrAXUBfrYF/design/event-ticket).

#### Carte cadeau

Utilisez une carte‑cadeau lorsque la Carte représente une valeur stockée qui doit diminuer ou augmenter dans le temps.

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

Plus de détails : [Carte cadeau](https://app.gitbook.com/s/WLc8AHXW4tdrAXUBfrYF/design/gift-card).

#### Offre

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

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

Plus de détails : [Offre](https://app.gitbook.com/s/WLc8AHXW4tdrAXUBfrYF/design/offer).

#### Générique

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

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

Plus de détails : [Générique](https://app.gitbook.com/s/WLc8AHXW4tdrAXUBfrYF/design/generic).

### 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 locataire.
* Produits différents avec une densité d'information différente (standard vs VIP, basique vs premium).
* Texte légal ou contacts du support client différents par programme.
* Langues différentes nécessitant des libellés et une structure de contenu différents.
* Stratégies de codes‑barres ou contextes de scan différents (PDV vs contrôle d'accès).

### Prochaines étapes

La création et la conception du modèle se font généralement une fois, puis s'itèrent avec des retours opérationnels réels.

* Commencez par [Comment créer un modèle](https://app.gitbook.com/s/WLc8AHXW4tdrAXUBfrYF/configure/wallet/template-configuration/how-to-create-a-template).
* Pour les règles de mise en page et les exigences d'actifs, utilisez [Conception de la Carte (couleurs, images et champs)](https://app.gitbook.com/s/WLc8AHXW4tdrAXUBfrYF/configure/wallet/template-configuration/card-design-colors-images-and-fields).
* Pour les programmes multilingues, utilisez [Comment traduire un modèle](https://app.gitbook.com/s/WLc8AHXW4tdrAXUBfrYF/configure/wallet/template-configuration/how-to-translate-a-template).

## 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'identité visuelle, les champs et les règles de mappage.

Une Carte est l'objet individuel installé par un client. Elle utilise un modèle à la fois et peut être mise à jour au cours 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é cœur des Wallets. The Wallet Crew met à jour la même Carte installée, les clients n'ont donc pas besoin de la réajouter.

</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 commune. Plusieurs modèles sont utiles lorsque des mises en page ou règles de contenu différentes sont requises.

</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>
