> 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 des Cartes

Utilisez la migration de cartes lorsque vous souhaitez changer le système qui **gère** vos cartes, tout en gardant les cartes déjà installées fonctionnelles pour les clients.

Une migration est un changement « en coulisses ». Les clients conservent la même carte dans Apple Wallet ou Google Wallet. Votre objectif est la continuité : la carte reste valide et les mises à jour continuent de fonctionner.

{% hint style="success" %}
Dans la plupart des cas, vous pouvez migrer sans impact pour les clients.

Si vous planifiez la transition et effectuez d’abord des tests, 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 vente au détail migre ses cartes de fidélité en milieu de 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 plateforme unique.

</details>

## Que les clients doivent-ils vivre ?

Lorsqu’une migration est correctement effectuée, 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 QR code utilisé en magasin ou à l’entrée reste identique. La carte continue aussi de recevoir des mises à jour (par exemple : points, niveau, solde, siège, porte ou validité).

La plupart des migrations incluent un court pilote. Vous validez le flux avec un petit lot, puis vous basculez les cartes restantes.

### Plan de migration type

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) Confirmez ce que « en place » signifie pour votre configuration

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

{% step %}

### 2) Exportez les identifiants techniques des cartes

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

{% step %}

### 3) Mappez les champs et lancez un lot pilote

Commencez par un petit lot. Mettez à jour un champ visible et validez-le sur de vrais appareils. Gardez le pilote simple afin de pouvoir itérer rapidement.
{% endstep %}

{% step %}

### 4) Basculez, puis surveillez

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 votre ancien fournisseur le permet.
{% endstep %}
{% endstepper %}

### Coordination et calendrier

Une migration nécessite une coordination entre plusieurs parties. Il s’agit généralement de votre fournisseur actuel et de The Wallet Crew, avec votre propre équipe impliquée lorsque vous gérez les comptes émetteurs et les certificats.

Le travail est rarement « difficile » d’un point de vue 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 votre parcours

* Migration **vers** The Wallet Crew : [Migrer les cartes vers The Wallet Crew](/configure/fr/advanced-configuration/wallet/import-and-export/pass-migration/move-passes-to-the-wallet-crew.md)
* Migration **depuis** 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 de la 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 aussi de l’« adresse » de mise à jour intégrée dans la carte (`webServiceURL`), car les appareils interrogent cette URL pour récupérer les mises à jour.

Si vous pouvez conserver la même identité d’émetteur et rediriger correctement `webServiceURL`, les clients peuvent généralement conserver la même carte installée.

#### Google Wallet

Les migrations Google Wallet dépendent du compte émetteur qui détient les cartes. Si le compte émetteur change, vous devez généralement réémettre les cartes (ce qui implique un nouveau flux d’enregistrement pour les clients).

Si vous conservez le même compte émetteur et les mêmes ID d’objet, 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>

Généralement non. Si vous migrez « en place » (même identité d’émetteur Apple, et Google sous le même compte émetteur), les clients conservent la même carte et elle continue de se mettre à jour.

</details>

<details>

<summary><strong>De quelles données avons-nous généralement besoin de l’ancien fournisseur ?</strong></summary>

Vous avez généralement besoin d’identifiants techniques qui permettent à un nouveau système 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’ID 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. Vous avez besoin de temps pour l’export, le mappage et un petit lot de test.

</details>

<details>

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

Vous avez besoin de votre fournisseur actuel et de The Wallet Crew. Si vous gérez les comptes émetteurs et les certificats, votre é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 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/import-and-export/pass-migration.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.