> 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/infrastructure.md).

# Sécurité et infrastructure

Consultez le modèle de sécurité de The Wallet Crew, l’isolation des locataires, les environnements et la liste blanche des IP sortantes.

## Sécurité et infrastructure

The Wallet Crew est une plateforme Wallet as a Service (WaaS) native du cloud, multilocataire, hébergée sur Microsoft Azure en Europe. Elle alimente la création de cartes et les mises à jour pour Apple Wallet et Google Wallet.

Le trafic public est acheminé via Cloudflare pour la protection WAF et la limitation de débit. Cloudflare fournit également la mise en cache CDN et la terminaison TLS.

<details>

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

* Un partenaire a besoin de l’IP sortante pour autoriser la livraison des webhooks ou le trafic des connecteurs.
* Une équipe de sécurité doit confirmer que `qa` et `prod` sont isolés.
* Un déploiement multimarque doit comprendre si les locataires partagent les identifiants de Wallet ou les bases de données.

</details>

### Pourquoi cette architecture est importante

Les choix d’infrastructure ont un impact direct sur les revues de sécurité, la mise en place des intégrations et le dépannage opérationnel.

L’isolation des locataires définit qui peut accéder aux données et aux identifiants. L’isolation des environnements définit comment les tests et la production restent séparés. Les IP sortantes sont importantes lorsque les systèmes partenaires restreignent le trafic entrant. Les services gérés réduisent la charge opérationnelle tout en gardant la plateforme évolutive et résiliente.

### Vue d’ensemble de la sécurité de la plateforme

The Wallet Crew utilise des services cloud gérés, des contrôles réseau et des contrôles d’accès au périmètre du locataire. La plateforme sépare les données, les identifiants, la configuration et l’accès API de chaque locataire.

Les cartes sont signées avec des identifiants configurés pour le locataire concerné. Les mises à jour Apple Wallet et Google Wallet utilisent leurs services de livraison pris en charge.

<div data-with-frame="true"><figure><img src="https://4179171865-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOnaDC4sjKAx53j0QV843%2Fuploads%2Fm7bGUlTAVnGtb5rTL5dQ%2Fdevelop-infrastructure-wallet-crew-global-architecture-schema.png?alt=media&#x26;token=79683d17-9a04-4f8d-a546-b6daa5d200f2" alt="High-level architecture diagram showing the edge, application, data, and integration layers of The Wallet Crew"><figcaption><p>Architecture de haut niveau de la plateforme à travers les couches edge, application, données et intégration.</p></figcaption></figure></div>

La plateforme prend en charge les intégrations via des connecteurs, des API et des webhooks. Les capacités sont configurées selon les besoins de chaque locataire.

### Locataires

Un locataire est la principale frontière d’isolation dans The Wallet Crew. Toutes les données et opérations de la plateforme sont limitées à un locataire.

* **Données**: les cartes, identifiants, métadonnées, événements et analyses restent limités au locataire.
* **Configuration**: les modèles de carte, les paramètres des connecteurs et les règles opérationnelles sont gérés indépendamment pour chaque locataire.
* **Identifiants**: les identifiants Wallet sont configurés et gérés dans le périmètre du locataire.
* **Utilisateurs et autorisations**: les rôles et autorisations du back-office sont évalués par locataire. Un utilisateur peut être affecté à plusieurs locataires ; chaque affectation à un locataire est indépendante.
* **Appels API**: chaque requête API est évaluée dans son contexte de locataire.

La plupart des clients exploitent un seul locataire. Les programmes plus importants peuvent utiliser des locataires séparés pour les marques, les régions ou d’autres programmes isolés.

### Environnements

The Wallet Crew fournit des environnements séparés d’assurance qualité et de production pour les configurations de locataires prises en charge.

| Environnement | Objectif                          | Accès                                         |
| ------------- | --------------------------------- | --------------------------------------------- |
| `prod`        | Exploitation client en production | Clients, partenaires, utilisateurs finaux     |
| `qa`          | Recette et tests d’intégration    | Utilisateurs clients et partenaires approuvés |

#### Isolation entre les environnements

Les environnements utilisent des données, des identifiants, des clés API et des enregistrements de cartes distincts. Testez avec `qa` avant d’utiliser les identifiants de production et les cartes de production.

#### Portabilité de la configuration

La configuration peut être promue entre les environnements sans copier les données de cartes en production ni l’état du portefeuille installé.

### Adresses IP sortantes

Lorsque The Wallet Crew effectue des requêtes API sortantes (trafic sortant) vers des systèmes partenaires ou des fournisseurs tiers, ces requêtes proviennent d’adresses IP publiques fixes. Ce sont les IP sources utilisées par les requêtes qui quittent The Wallet Crew. Elles apparaissent comme l’IP client ou l’IP source dans la passerelle, le WAF ou les journaux de l’application de réception.

Ces IP s’appliquent aux appels initiés par The Wallet Crew, tels que les requêtes des connecteurs, la livraison des webhooks et tout rappel serveur-à-serveur configuré sur le locataire.

Ces IP ne sont nécessaires que lorsque l’accès entrant aux points de terminaison de réception est restreint. C’est courant pour les pare-feu d’entreprise, les passerelles API et les API partenaires privées.

{% hint style="info" %}
Les appels aux API de The Wallet Crew n’ont généralement pas besoin de mise sur liste d’autorisation. Ce trafic sortant provient du réseau appelant.
{% endhint %}

Mettez sur liste d’autorisation l’IP de l’environnement utilisé. Lorsque plusieurs environnements sont utilisés, mettez sur liste d’autorisation chaque IP pertinente.

* **Production (`prod`)**: `20.111.54.22`
* **Assurance qualité (`qa`)**: `51.11.248.115`

#### Webhooks : ne vous fiez pas uniquement aux IP

La mise sur liste d’autorisation des IP réduit le bruit et bloque le trafic non sollicité évident. Cela ne prouve pas que la requête est authentique.

L’authenticité du webhook doit toujours être vérifiée au niveau de l’application.

The Wallet Crew peut signer les requêtes webhook à l’aide de `x-neostore-signature` (HMAC SHA-256). La signature prouve que la charge utile a été envoyée par The Wallet Crew et n’a pas été modifiée.

Voir [Webhooks](/developers-guides/fr/integration-guides/webhooks.md) pour la configuration et la vérification de la signature.

### Gestion des données

The Wallet Crew stocke la configuration et les données opérationnelles des cartes nécessaires au fonctionnement du service. La source de vérité métier reste généralement dans les systèmes de la marque et y est accessible via des intégrations. Cela inclut les plateformes de CRM, de ticketing, de fidélité et d’automatisation marketing.

Les données personnelles identifiables (PII) ne sont pas stockées par défaut. Lorsque le stockage de PII est nécessaire, il est défini par la configuration du locataire et le cas d’usage.

La gestion des données dépend de la configuration du locataire et du cas d’usage. N’intégrez pas de données personnelles inutiles dans les champs des cartes, les identifiants, les charges utiles des webhooks ou les journaux d’intégration.

### FAQ

<details>

<summary>The Wallet Crew utilise-t-il une seule IP pour tout ?</summary>

Non. Cela varie selon l’environnement. Certaines intégrations peuvent également avoir des points de terminaison dédiés selon la manière dont elles sont déployées et activées.

</details>

<details>

<summary>Je vois une autre IP source. Que dois-je faire ?</summary>

Vérifiez d’abord que la requête atteint le bon environnement. Vérifiez aussi que les journaux affichent la vraie IP client. Certaines configurations consignent à la place les IP intermédiaires du proxy.

Si cela diffère toujours, contactez le support avec le point de terminaison et un horodatage.

</details>

<details>

<summary>The Wallet Crew peut-il se connecter à nos systèmes via un VPN ?</summary>

Oui, cela peut être configuré à la demande pour des contraintes réseau strictes. Il s’agit généralement d’une configuration dédiée avec une surcharge opérationnelle supplémentaire. Cela peut aussi introduire des coûts supplémentaires d’infrastructure et de support.

La plupart des clients préfèrent plutôt la mise sur liste d’autorisation des IP et la signature des requêtes.

</details>

<details>

<summary>Existe-t-il un Security Insurance Plan (SIP) ?</summary>

Oui. Le SIP résume la gouvernance, les contrôles et les responsabilités en matière de sécurité pour l’exploitation de The Wallet Crew. C’est le meilleur point de départ pour les revues de sécurité des fournisseurs et l’évaluation interne des risques.

Le Security Insurance Plan est disponible sur demande.

</details>

<details>

<summary>Existe-t-il une référence d’architecture plus détaillée ?</summary>

Une référence complète d’architecture technique et de sécurité est disponible pour les équipes informatiques des clients et les partenaires techniques. Contactez le support ou l’équipe commerciale pour en faire la demande.

</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/developers-guides/fr/pass-architecture/infrastructure.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.
