> 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/import-and-export/pass-migration.md).

# Migration de Cartes

Déplacez les Cartes entre fournisseurs tout en continuant à faire fonctionner les Cartes installées : planification, contraintes Apple et Google, pilote et bascule.

Utilisez la migration de cartes pour changer le système qui **gère** les cartes, tout en continuant à faire fonctionner les cartes déjà installées pour les clients.

Une migration est une modification « en coulisses ». Les clients conservent la même Carte dans Apple Wallet ou Google Wallet. L’objectif est la continuité : la Carte reste valide et les mises à jour continuent de fonctionner.

{% hint style="success" %}
Dans la plupart des cas, une migration est possible sans impacter les clients.

Avec une bascule planifiée et testée au préalable, les clients conservent la même Carte et elle continue de se mettre à jour.
{% endhint %}

<details>

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

* Une marque de distribution migre ses cartes de fidélité en pleine saison sans demander aux clients de les réinstaller.
* Un organisateur de spectacle change de prestataire de billetterie après un pilote.
* Une marque regroupe plusieurs fournisseurs de cartes sur une seule plateforme.

</details>

## Que doivent vivre les clients ?

Lorsqu’une migration est effectuée correctement, les clients ne réinstallent rien. Ils conservent la même Carte sur leur appareil et peuvent continuer à l’utiliser comme d’habitude.

En pratique, cela signifie que le code-barres ou le code QR utilisé en magasin ou à l’entrée reste le même. La Carte continue également de recevoir des mises à jour (par exemple : points, niveau, solde, siège, porte ou validité).

La plupart des migrations comprennent un court pilote. Le flux est validé sur un petit lot, puis les cartes restantes sont basculées.

### Plan de migration typique

Les étapes exactes dépendent de la direction (vers ou depuis The Wallet Crew) et des contraintes de la plateforme. Le flux ci-dessous reste globalement valable dans la plupart des projets.

{% stepper %}
{% step %}

### 1) Confirmer ce que « en place » signifie pour la configuration

Confirmez quelle identité d’émetteur Apple signe les cartes, et quel compte d’émetteur Google Wallet les détient. C’est ce qui détermine si les clients peuvent conserver la même Carte, ou si un flux de réémission est nécessaire.
{% endstep %}

{% step %}

### 2) Exporter les identifiants techniques de la Carte

Le nouveau système a besoin des identifiants qui lui permettent de se rattacher aux cartes existantes (par exemple les numéros de série Apple + les jetons d’authentification, ou les identifiants de ressource/identifiants d’objet Google).
{% endstep %}

{% step %}

### 3) Mapper les champs et exécuter un lot pilote

Commencez par un petit lot. Mettez à jour un champ visible et validez-le sur des appareils réels. Gardez le pilote simple pour permettre une itération rapide.
{% endstep %}

{% step %}

### 4) Procéder à la bascule, puis surveiller

Exécutez le plan de bascule, puis surveillez les mises à jour et l’utilisation pendant quelques jours. Conservez une option de retour arrière si le fournisseur précédent le prend en charge.
{% endstep %}
{% endstepper %}

### Coordination et calendrier

Une migration nécessite une coordination entre les parties. Elle implique généralement le fournisseur actuel et The Wallet Crew, avec l’équipe de la marque lorsqu’elle contrôle les comptes d’émetteur et les certificats.

Le travail est rarement « difficile » sur le plan technique. La majeure partie du temps est consacrée à l’alignement sur le format d’export, le mappage des champs, les validations de sécurité et le plan de bascule. Prévoyez quelques semaines pour un projet typique. Les délais varient selon le fournisseur et les cycles d’approbation.

### Choisissez une voie

* Aller **vers** The Wallet Crew: [Déplacer les cartes vers The Wallet Crew](/configure/fr/advanced-configuration/wallet/import-and-export/pass-migration/move-passes-to-the-wallet-crew.md)
* Aller **depuis** de The Wallet Crew: [Exporter les cartes depuis The Wallet Crew vers un autre fournisseur](/configure/fr/advanced-configuration/wallet/import-and-export/pass-migration/export-passes-from-twc-to-another-provider.md)

### Contraintes clés (Apple vs Google)

Apple Wallet et Google Wallet ont des règles différentes. Ces règles expliquent pourquoi les migrations nécessitent une coordination et pourquoi un lot de test est important.

#### Apple Wallet

Les migrations Apple Wallet dépendent de l’identité d’émetteur utilisée pour signer les cartes. Elles dépendent également de l’« adresse » de mise à jour intégrée dans la Carte (`webServiceURL`), car les appareils appellent cette URL pour récupérer les mises à jour.

Lorsque la même identité d’émetteur est conservée et `webServiceURL` qu’elle est correctement redirigée, les clients peuvent généralement conserver la même Carte installée.

#### Google Wallet

Les migrations Google Wallet dépendent du compte d’émetteur qui possède les cartes. Si le compte d’émetteur change, les cartes doivent généralement être réémises (ce qui implique un nouveau flux d’enregistrement pour les clients).

Lorsque le même compte d’émetteur et les mêmes identifiants d’objet sont conservés, les clients peuvent généralement conserver la même Carte.

### FAQ

<details>

<summary><strong>Les clients doivent-ils réinstaller leur Carte pendant une migration ?</strong></summary>

En général non. Avec une migration « en place » (même identité d’émetteur Apple, et Google sous le même compte d’émetteur), les clients conservent la même Carte et elle continue de se mettre à jour.

</details>

<details>

<summary><strong>Quelles données avons-nous généralement besoin d’obtenir du fournisseur précédent ?</strong></summary>

Le nouveau système a généralement besoin d’identifiants techniques qui lui permettent de se rattacher à la Carte existante.

* Pour Apple, il s’agit généralement du numéro de série et du jeton d’authentification.
* Pour Google, il s’agit généralement de l’identifiant de ressource (ID d’objet).

</details>

<details>

<summary><strong>Combien de temps prend généralement une migration ?</strong></summary>

Prévoyez quelques semaines. La majeure partie du temps est consacrée à la coordination, pas à l’implémentation. Du temps est nécessaire pour l’export, le mappage et un petit lot de test.

</details>

<details>

<summary><strong>Qui doit être impliqué ?</strong></summary>

Le fournisseur actuel et The Wallet Crew. Lorsque la marque contrôle les comptes d’émetteur et les certificats, son équipe est également impliquée.

</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/configure/fr/advanced-configuration/wallet/import-and-export/pass-migration.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.
