> 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/configure/fr/advanced-configuration/wallet/wallet-card-security.md).

# Sécurité de la carte Wallet

## Sécurité des cartes Wallet Apple Wallet et Google Wallet

The Wallet Crew est une plateforme Wallet as a Service (WaaS) en marque blanche. Nous aidons les marques à émettre des cartes sécurisées **cartes wallet mobiles** et **cartes Wallet**. Ces cartes fonctionnent dans **Apple Wallet** et **Google Wallet**.

Les cas d’usage courants incluent les cartes de fidélité, les cartes-cadeaux, les coupons et les billets.

Cette page couvre la sécurité de bout en bout des cartes Wallet :

* confidentialité et conformité (RGPD, CCPA)
* hébergement dans l’UE et résidence des données
* chiffrement en transit et au repos
* authentification de l’API, limitation du débit et protection contre les abus
* distribution sécurisée des cartes (e-mail, web, QR, NFC)
* flux de mise à jour Apple Wallet vs Google Wallet

## Conformité et protection des données (RGPD, CCPA)

La sécurité et la confidentialité sont intégrées à la plateforme. The Wallet Crew est conforme aux exigences du RGPD et du CCPA.

Les données personnelles identifiables (PII) ne sont pas stockées par défaut. Lorsque le traitement de PII est nécessaire, il est piloté par votre configuration et votre cas d’usage.

Notre infrastructure fonctionne sur Microsoft Azure en Europe. Cela répond aux exigences de résidence des données de l’UE pour de nombreuses organisations.

#### Références

* Nous maintenons un Security Insurance Plan (SIP) documenté. Il couvre les contrôles de sécurité et la gestion des risques. Lisez-le ici : [Plan d’assurance sécurité (SIP)](/policies/fr/privacy-and-security/security-insurance-plan.md).
* Nous fournissons également un modèle d’accord de traitement des données (DPA). Il définit les responsabilités en matière de conformité. Lisez-le ici : [modèle d’accord de traitement des données](/policies/fr/privacy-and-security/data-processing-agreement-model.md).
* Pour des détails pratiques sur la confidentialité, voir : [FAQ sur la protection des données](/policies/fr/privacy-and-security/data-protection-faq.md).
* Pour la collecte du consentement et les preuves, voir : [Consentements et conformité au RGPD](/guides-animation/fr/engager-and-animer/automatisation/notifications-push/consentements-et-conformite-au-rgpd.md).

## Architecture de sécurité

The Wallet Crew est une plateforme multitenante avec une isolation stricte des locataires. Les données et les opérations sont séparées entre les marques. La limitation du débit par locataire réduit les abus et les risques liés au « voisin bruyant ».

L’authentification de l’API prend en charge **OAuth 2.0** et **clés API**. L’accès back-office utilise **Auth0** pour la gestion des identités et des accès.

Les services internes s’exécutent dans un **Azure Virtual Network**. Ce réseau n’est pas accessible publiquement. Le trafic public est acheminé via **Cloudflare**. Cloudflare fournit un CDN, **WAF**, une protection DDoS et une limitation du débit.

Nous prenons en charge **des domaines personnalisés** pour la distribution des cartes. Les marques peuvent utiliser un sous-domaine sur leur propre domaine. Les certificats TLS sont gérés par défaut via Cloudflare. Les marques peuvent également fournir leur propre certificat et configuration DNS.

Toutes les communications utilisent TLS 1.2 ou TLS 1.3. Les données au repos sont stockées dans Azure Cosmos DB et chiffrées par Azure. Les données d’analyse sont stockées dans Azure Data Explorer et chiffrées par Azure. Voir [Insights API](https://docs.thewalletcrew.io/api-reference/) pour les schémas d’accès d’utilisation et d’analytique.

Le trafic de service à service à l’intérieur du réseau virtuel est également chiffré avec TLS.

Pour les détails d’hébergement, voir [Infrastructure](/developers-guides/fr/pass-architecture/infrastructure.md).

## Sécurité de distribution des cartes Wallet (liens, e-mail, QR, NFC)

The Wallet Crew prend en charge la distribution sécurisée des cartes aux utilisateurs finaux. Tous les canaux imposent HTTPS et utilisent des paramètres signés. Cela empêche la falsification, les attaques par rejeu et les accès non autorisés.

Chaque carte de notre système est associée à deux types d’identifiants :

* **Identifiant interne**: Un UUID opaque et non séquentiel généré par The Wallet Crew. Il est unique et impossible à deviner. Il peut être utilisé pour une récupération directe en toute sécurité.
* **Identifiant externe**: Fourni par vos systèmes. Les exemples incluent les numéros de fidélité, les numéros de billet et les identifiants de carte-cadeau. Ces valeurs sont souvent séquentielles ou prévisibles. Les identifiants prévisibles doivent être protégés afin d’empêcher les attaques d’énumération (IDOR).

Pour sécuriser la récupération basée sur des identifiants externes, nous prenons en charge plusieurs mécanismes. Ils sont conçus pour prévenir les attaques d’énumération et de rejeu.

* Signature HMAC-SHA256\
  Calculez un HMAC avec SHA-256 et un secret partagé spécifique au locataire. Votre système signe l’identifiant externe. The Wallet Crew vérifie la signature avant d’accorder l’accès.
* Jeton de secret partagé\
  Générez un jeton à l’aide d’un secret partagé avec The Wallet Crew. Envoyez le jeton avec l’identifiant. Notre API le valide avant de renvoyer toute donnée de carte.
* JWT (JSON Web Token)\
  Utilisez un JWT signé qui inclut l’identifiant externe comme claim. Signez avec HMAC ou une paire de clés asymétriques (RSA/ECDSA). The Wallet Crew valide la signature, l’expiration et les claims.

Ces contrôles s’appliquent à la récupération via l’API et aux liens de distribution. Cela inclut les e-mails, les codes QR et les tags NFC. Les identifiants dans les URL sont inutiles sans jeton valide.

Les cartes peuvent être distribuées par e-mail à l’aide de liens sécurisés « Ajouter au Wallet ». Les flux e-mail s’intègrent aux principaux outils d’automatisation marketing. Voir [Par e-mail](/guides-enrolment/fr/inscription/via-email.md) et [Intégrations](https://www.thewalletcrew.com/en/integrations).

Pour la distribution web, nous fournissons un SDK pour un bouton « Ajouter au Wallet ». Le SDK maintient le flux du navigateur vers la plateforme sécurisé. Voir [Sur votre site web](/guides-enrolment/fr/inscription/on-your-website.md).

Nous fournissons également des formulaires d’inscription sécurisés. Ils peuvent ajouter des étapes de vérification avant l’accès à la carte. Voir [Conception du formulaire d’inscription](/guides-enrolment/fr/inscription/enrolment-form.md).

Vous pouvez également intégrer des liens sécurisés dans des points de contact physiques. Utilisez des codes QR sur des flyers ou des tags NFC sur des cartes plastiques. Ces liens sont signés et peuvent être à usage unique ou limités dans le temps. Nous proposons également une application web qui affiche des codes QR temporaires. Contactez le support pour choisir la configuration adaptée à votre cas d’usage.

## Flux de données du Wallet mobile et confidentialité

The Wallet Crew est conçu pour minimiser le stockage des PII. Les PII ne sont pas conservées par défaut.

Pour des raisons de performance, certains connecteurs peuvent utiliser un cache temporaire facultatif. La durée typique du cache est inférieure à 15 minutes. Les données du cache peuvent être supprimées via l’API The Wallet Crew. Les demandes de suppression de données peuvent également être traitées par notre équipe support.

Notre architecture garantit que les opérations sensibles se déroulent dans des périmètres sécurisés.

![Schéma des flux de données](/files/885df7b79620aecf84eb4f0a9539c59896946528)

## Flux de communication Apple Wallet et Google Wallet

La communication avec les fournisseurs de Wallet diffère entre Apple et Google.

* Apple Wallet\
  Les cartes sont installées sur l’appareil de l’utilisateur. Elles ne sont pas stockées par défaut sur les serveurs d’Apple. Les mises à jour sont déclenchées via le service de notifications push Apple (APNs). APNs indique à l’appareil de récupérer la carte mise à jour de manière asynchrone. Les cartes peuvent se synchroniser via iCloud, mais nous ne pouvons pas accéder au contenu iCloud.

  ![Flux Apple Wallet](/files/83af660e0bb2e2296b34a31c816aeaea136e224e)
* Google Wallet\
  Les cartes sont stockées dans le compte Google de l’utilisateur. Les mises à jour sont gérées via l’API Google Wallet à l’aide d’identifiants OAuth. La livraison et l’actualisation sur l’appareil sont prises en charge par Google.

  ![Flux Google Wallet](/files/8282c57574d3ee7ba056e2d5dae52af504bf86d2)

## Sécurité de l’API (authentification, limitation du débit, journaux d’audit)

Nos API sont protégées par une limitation du débit par locataire. Des contrôles supplémentaires atténuent les attaques par force brute et les abus de jetons.

Les journaux d’audit sont disponibles sur demande pour la conformité et l’analyse médico-légale. Les signaux d’utilisation de la plateforme sont disponibles via le[ Insights API](/developers-guides/fr/integration-guides/insights-api.md).

## Surveillance et réponse aux incidents

Nous utilisons Azure Application Insights pour la surveillance et la détection d’anomalies. Les alertes sont automatisées et ajustées pour détecter les schémas suspects.

Nous maintenons un processus de réponse aux incidents et un plan de reprise d’activité.

## Atténuation des risques

Nous imposons HTTPS et des URL signées sur tous les canaux de distribution. Les codes QR et les tags NFC peuvent être configurés en usage temporaire ou unique. L’isolation des locataires et la limitation du débit réduisent encore les abus et les accès non autorisés.

## FAQ rapide sur la sécurité

<details>

<summary>The Wallet Crew stocke-t-il des données personnelles (PII) ?</summary>

Par défaut, non. The Wallet Crew est conçu pour que les PII ne soient pas conservées. Certains connecteurs peuvent utiliser un cache facultatif de courte durée.

</details>

<details>

<summary>Les cartes Apple Wallet sont-elles stockées sur les serveurs d’Apple ?</summary>

Les cartes Apple Wallet sont installées sur l’appareil de l’utilisateur. Les mises à jour sont déclenchées via APNs. The Wallet Crew ne peut pas accéder au contenu des cartes stocké dans iCloud.

</details>

<details>

<summary>Comment les liens « Ajouter au Wallet » sont-ils sécurisés ?</summary>

Tous les liens de distribution utilisent HTTPS. Les liens sont signés et validés côté serveur. Nous prenons en charge HMAC-SHA256, les jetons de secret partagé et les JWT. Cela empêche la falsification et l’énumération des cartes.

</details>

<details>

<summary>Comment The Wallet Crew empêche-t-il l’abus de vos API ?</summary>

Nous utilisons une limitation du débit par locataire et des protections supplémentaires contre les abus. Nous surveillons les anomalies et maintenons un processus de réponse aux incidents. Des journaux d’audit peuvent être fournis sur 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 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/configure/fr/advanced-configuration/wallet/wallet-card-security.md?ask=<question>&goal=<endgoal>
```

`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.
