> 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/docs/fr/demarrer/readme/key-concepts.md). # Concepts clés The Wallet Crew s’articule autour d’un petit ensemble de concepts qui apparaissent tout au long de la plateforme. Les comprendre une seule fois rend la navigation sur toutes les autres pages plus rapide. {% hint style="info" %} Les cartes de paiement comme Apple Pay et Google Pay ne sont pas couvertes ici. The Wallet Crew gère des cartes Wallet telles que des cartes de fidélité, des billets, des offres et des cartes-cadeaux — pas des instruments de paiement. {% endhint %}
Exemples concrets * Une marque de distribution peut utiliser un seul tenant, un seul modèle de fidélité et des millions de cartes clients. * Une marque de billetterie peut utiliser un modèle de billet par famille d’événements, puis émettre une Carte par participant. * Un groupe international peut conserver un tenant par pays lorsque les équipes, les identifiants et les données doivent rester séparés.
## Tenant Un tenant est l’espace de travail isolé d’une marque ou d’un programme Wallet dans The Wallet Crew. Tout ce qui y est configuré vit dans ce tenant : les designs Wallet, les cartes, les données et l’accès des équipes. Une façon simple de le voir est comme un bâtiment privé, pas comme un espace ouvert partagé. Ce qui existe dans un tenant ne se mélange pas avec un autre tenant. La plupart des marques ont un seul tenant. Certains groupes en exploitent plusieurs lorsque des marques, des pays ou des programmes distincts doivent rester indépendants, avec leurs propres identifiants Apple et Google, leurs propres données et leurs propres équipes. {% hint style="info" %} Un tenant n’est pas un dossier ni un sous-compte dans un espace de travail partagé. Chaque tenant est un environnement totalement isolé. Il n’y a, par conception, aucun accès aux données entre tenants. {% endhint %} ## Modèle de carte Un modèle de carte est le modèle d’une carte Wallet d’un certain type. Il définit quelle plateforme Wallet est ciblée, à quoi la carte ressemble, quels champs apparaissent, quel format de code-barres est utilisé et comment fonctionne la personnalisation. L’analogie la plus simple est celle d’un plan. Le modèle définit les règles une fois, puis The Wallet Crew réutilise ces règles chaque fois qu’une nouvelle carte est créée à partir de celui-ci. Un modèle n’est pas une carte. Il n’appartient pas à un seul client. C’est la définition réutilisable derrière de nombreuses cartes. Une marque peut utiliser plusieurs modèles en même temps. Une carte de fidélité, une carte-cadeau et un billet d’événement nécessitent généralement chacun leur propre modèle. ## Carte Une carte est une carte Wallet, un billet ou un bon émis à un seul client. Elle est créée à partir d’un modèle et reliée aux systèmes de la marque, tels qu’un CRM, un moteur de fidélité, un point de vente ou une plateforme de billetterie. Si le modèle est le plan, la carte est l’élément final dans le Wallet du client. Un seul modèle peut créer des milliers ou des millions de cartes individuelles. Les cartes suivent un cycle de vie : * **Créée** — la carte existe sur la plateforme. * **Installée** — le client l’a ajoutée à Apple Wallet ou Google Wallet. * **Mise à jour** — le contenu de la carte a changé, comme un solde de points, un statut ou un message. * **Désinstallée** — le client l’a retirée du Wallet. Création et installation sont deux moments différents. Une carte peut exister avant qu’un client l’enregistre dans le Wallet. The Wallet Crew ne stocke pas de données personnelles clients par défaut. Les cartes sont généralement liées par des identifiants stables, tels qu’un ID CRM ou un numéro de fidélité, tandis que les données clients principales restent dans les systèmes de la marque. ## Environnement Les environnements séparent les tests des opérations en direct. En pratique, The Wallet Crew fournit **QA** pour les tests et **la production** pour les vrais clients. QA est la phase de répétition. La production est la phase en direct. QA reproduit de près la production afin que les tests reflètent des conditions réelles avant le lancement. Ces environnements sont entièrement isolés. Une carte créée en QA n’apparaît jamais en production, et les identifiants de production ou les données en direct ne sont pas partagés dans QA. La configuration peut être copiée entre les environnements lorsque c’est nécessaire. Un troisième environnement, **dev**, existe uniquement pour un usage interne d’ingénierie et n’est pas accessible aux clients. ## La suite * Pour comprendre ce que la plateforme peut suivre après l’émission, voir [Suivi](https://docs.thewalletcrew.io/guides-monitoring/fr/). * Pour commencer à configurer un premier modèle, voir [Conception de la carte (couleurs, images et champs)](/configure/fr/advanced-configuration/wallet/template-configuration/cards-design-colors-images-and-fields.md). * Pour un modèle technique plus approfondi, commencez par [Structure](/developers-guides/fr/pass-architecture/structure.md) et la [zone Développeurs.](https://docs.thewalletcrew.io/developers-guides/fr/) area. ## FAQ
Un seul modèle peut-il créer de nombreuses cartes ? Oui. C’est le modèle normal. Un modèle est réutilisé pour émettre de nombreuses cartes individuelles qui partagent la même structure et le même design.
Le même client peut-il avoir plusieurs cartes ? Oui. Un client peut détenir plusieurs cartes de la même marque, comme une carte de fidélité et plusieurs billets d’événement. Chaque carte reste malgré tout son propre enregistrement.
Pourquoi séparer QA et la production ? La séparation réduit les risques. Les équipes peuvent tester les designs, les liens et les flux de données en QA sans affecter les clients en direct ni les identifiants de production.
--- # 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/docs/fr/demarrer/readme/key-concepts.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.