> 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/commencer/readme/key-concepts.md). # Concepts clés Comprenez les concepts clés de The Wallet Crew : tenant, modèle de Carte, Carte et environnement. The Wallet Crew est conçu autour d’un petit ensemble de concepts qui apparaissent dans toute la plateforme. Les comprendre une seule fois rend chaque autre page plus rapide à parcourir. {% hint style="info" %} Les cartes de paiement comme Apple Pay et Google Pay ne sont pas concernées ici. The Wallet Crew gère des cartes Wallet comme les cartes de fidélité, les billets, les offres et les cartes-cadeaux — pas des instruments de paiement. {% endhint %}
Exemples concrets * Une marque de distribution peut exploiter un seul tenant, un seul modèle de fidélité et des millions de cartes client. * 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é pour une marque ou un programme Wallet au sein de The Wallet Crew. Tout ce qui y est configuré vit dans ce tenant : conceptions Wallet, cartes, données et accès de l’équipe. Une façon simple de le voir est comme un bâtiment privé, et non 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 exploitent plusieurs tenants 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é. Par conception, il n’y a aucun accès croisé aux données entre tenants. {% endhint %} ## Modèle de Carte Un modèle de Carte est le modèle d’une catégorie de carte Wallet. Il définit quelle plateforme Wallet est ciblée, à quoi ressemble la carte, 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 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 POS ou une plateforme de billetterie. Si le modèle est le plan, la carte est l’élément fini dans le Wallet du client. Un seul modèle peut créer des milliers ou des millions de cartes individuelles. Les cartes passent par 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 supprimée du Wallet. Créée et installée sont deux moments différents. Une carte peut exister avant qu’un client l’enregistre dans le Wallet. The Wallet Crew ne stocke pas, par défaut, les données personnelles des clients. Les cartes sont généralement relié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 production. En pratique, The Wallet Crew fournit **QA** pour les tests et **production** pour les vrais clients. La QA est la phase de répétition. La production est la phase en direct. La QA reproduit de près la production afin que les tests reflètent les conditions réelles avant le lancement. Ces environnements sont totalement 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 avec la QA. La configuration peut être copiée entre les environnements si nécessaire. Un troisième environnement, **dev**, existe uniquement pour un usage interne d’ingénierie et n’est pas accessible aux clients. ## Ce qui vient ensuite * Pour comprendre ce que la plateforme peut suivre après l’émission, voir [Surveillance](https://docs.thewalletcrew.io/guides-monitoring/fr/). * Pour commencer à configurer un premier modèle, voir [Conception de 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/) . ## 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.
Un 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 toutefois un enregistrement distinct.
Pourquoi garder la QA et la production séparées ? La séparation réduit les risques. Les équipes peuvent tester les conceptions, les liens et les flux de données en QA sans affecter les clients en direct ni les identifiants en direct.
--- # 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/docs/fr/commencer/readme/key-concepts.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.