> 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/move-passes-to-the-wallet-crew.md).
# Déplacer les Cartes vers The Wallet Crew
Utilisez ce guide lorsque vous souhaitez migrer **déjà installées** des cartes Apple Wallet et Google Wallet d’un autre fournisseur vers The Wallet Crew.
L’objectif est d’assurer la continuité pour les clients. Lorsque la migration est effectuée correctement, ils conservent la même carte sur leur appareil, ne réinstallent rien, et votre flux de codes-barres et d’utilisation reste inchangé.
L’essentiel du travail relève de la coordination, et non de l’implémentation. Vous alignez les identifiants de l’émetteur, exportez les identifiants techniques reliant chaque carte à son enregistrement Apple/Google existant, validez avec un petit pilote, puis effectuez une bascule contrôlée.
Si vous avez besoin du flux inverse, consultez [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).
Exemples concrets
* Une marque décide de changer de fournisseur de cartes Wallet, mais souhaite que les clients conservent leurs cartes installées.
* Une marque remplace une configuration Wallet interne par The Wallet Crew afin de bénéficier d’une couche opérationnelle plus fiable.
* Une marque change de système sous-jacent (CRM, fidélité, billetterie, POS) et doit transférer les cartes actives en toute sécurité.
## Avant de commencer
La plupart des migrations réussissent ou échouent selon les contraintes des plateformes et selon la personne qui contrôle les identifiants de l’émetteur.
Si vous souhaitez obtenir des informations sur les identifiants et les données de carte, consultez [Structure.](/developers-guides/fr/pass-architecture/structure.md)
### Configurez votre projet The Wallet Crew avant la migration
Vous ne pouvez pas démarrer une migration avant que votre projet The Wallet Crew ne fonctionne déjà de bout en bout.
La migration ne consiste pas à « recréer des cartes ». Elle consiste à importer les identifiants qui permettent à The Wallet Crew de prendre en charge les mises à jour des cartes déjà installées sur les appareils. Si votre projet n’est pas configuré, les cartes importées existeront, mais elles ne se mettront pas à jour de manière fiable après la bascule.
Avant d’importer quoi que ce soit, assurez-vous que :
* Vous avez connecté les fournisseurs de Wallet et pouvez signer/détenir des cartes (Apple Carte Type ID et certificats, accès au compte émetteur Google Wallet).
* Vous avez décidé quels **identifiants externes** vous utiliserez pour relier les cartes à vos systèmes (ID client, ID de billet, numéro d’adhérent, ID de commande, ...). Ils doivent être stables dans le temps.
* Vous pouvez calculer le contenu des cartes à partir de votre source de référence (intégration API, processus basé sur des fichiers ou processus opérationnel).
* Vous pouvez exécuter un cycle de vie complet sur des cartes de test : émettre, mettre à jour un champ visible et vérifier la mise à jour sur un appareil réel.
Liste de vérification de préparation à la migration
Utilisez cette liste comme liste de validation avant de toucher aux cartes de production.
* [ ] Vous savez quel Apple Carte Type ID signe les cartes existantes.
* [ ] Vous disposez des identifiants Apple nécessaires pour conserver la même identité d’émetteur.
* [ ] Vous connaissez le Google Wallet `issuerId` qui possède les cartes existantes.
* [ ] Vous avez accès à ce compte émetteur dans la Google Pay & Wallet Console.
* [ ] Votre fournisseur actuel peut exporter une ligne par carte avec les identifiants requis.
* [ ] Votre fournisseur actuel peut envoyer une « mise à jour finale » Apple (voir l’étape de bascule).
* [ ] Vous disposez d’un lot pilote de 2 à 3 cartes réelles par plateforme.
* [ ] Vous disposez d’un plan de retour arrière pour Apple (s’il est pris en charge par l’ancien fournisseur).
{% hint style="info" %}
Prévoyez au moins un cycle pilote. La plupart des retards proviennent des exports, des approbations et de la planification de la bascule.
{% endhint %}
{% hint style="info" %}
Prévoyez au moins un cycle pilote. La plupart des retards proviennent des exports, des approbations et de la planification de la bascule.
{% endhint %}
### Ce que vous importez : les identifiants de carte (plateforme + externes)
Vous ne recréez pas de cartes lors d’une migration. Vous importez les identifiants afin que The Wallet Crew puisse mettre à jour les cartes qui sont **déjà installées** sur les appareils.
Vous importez deux types d’identifiants :
* **Identifiants de plateforme**. Ils pointent vers l’enregistrement de carte Apple/Google existant.
* Apple : `serialNumber` + `authenticationToken`
* Google : objet **ID de ressource** (souvent appelé ID d’objet)
* **Identifiants externes**. Ils relient une carte à vos propres systèmes.
* Exemples : ID client, ID de billet, numéro d’adhérent, ID de commande
Les identifiants de plateforme permettent à The Wallet Crew de mettre à jour la même carte sur l’appareil. Les identifiants externes vous permettent d’associer la carte au bon enregistrement client et de garantir des mises à jour correctes après la bascule.
Une même carte peut avoir plusieurs identifiants externes. Cela est utile lorsque vous rapprochez des données entre plusieurs systèmes.
### Déterminez si vous pouvez migrer « sur place »
Apple et Google n’autorisent pas les mêmes modèles de migration.
#### Apple Wallet (la migration sur place est généralement possible)
Vous pouvez généralement migrer sans réinstallation si vous conservez la même identité d’émetteur Apple (même Carte Type ID / identité de signature) et redirigez le point de terminaison de mise à jour de la carte (`webServiceURL`).
Cela exige généralement que votre fournisseur actuel envoie au moins une « mise à jour finale » aux cartes installées. Cette mise à jour intègre The Wallet Crew `webServiceURL` afin que les appareils commencent à appeler The Wallet Crew pour les futures mises à jour.
#### Google Wallet (uniquement si vous conservez le même compte émetteur)
Les cartes Google Wallet sont liées à un compte émetteur Google Pay & Wallet Console (`issuerId`).
Si les cartes existantes ont été créées sous un compte émetteur que vous ne contrôlez pas, vous ne pouvez pas les transférer sur place. Vous devez prévoir un flux de réémission (nouveaux liens d’enregistrement, nouveaux objets).
{% hint style="warning" %}
Pour Google Wallet, planifiez la migration autour de votre compte émetteur.
Si votre fournisseur actuel a émis des cartes sous un compte émetteur que vous ne contrôlez pas, prévoyez un flux de réémission.
{% endhint %}
### Ce dont vous avez besoin de la part de votre fournisseur actuel
Demandez une ligne d’export par carte. Vous l’utiliserez pour associer The Wallet Crew à la carte *existante* installée.
Au minimum, obtenez :
* **Apple Wallet**: `serialNumber` et `authenticationToken`
* **Google Wallet**: objet **ID de ressource** (souvent appelé « ID de ressource » ou « ID d’objet »)
* Un identifiant client stable (e-mail, ID client, ID de billet). C’est ainsi que vous associez les cartes aux clients.
{% hint style="info" %}
Si votre fournisseur actuel peut également partager l’Apple Carte Type ID et le Google `issuerId`, cela accélère la vérification d’éligibilité.
{% endhint %}
## Étapes de migration
### Vue d’ensemble de la séquence (ce qui se passe de bout en bout)
Ces diagrammes présentent les points de contrôle nécessaires à une bascule propre. L’idée clé est simple : vous importez des identifiants dans The Wallet Crew, puis vous vous assurez que les appareils commencent à récupérer les mises à jour depuis The Wallet Crew.
{% tabs %}
{% tab title="Apple Wallet" %}
La migration Apple sur place fonctionne généralement si vous conservez le même Carte Type ID et que votre fournisseur actuel peut envoyer une « mise à jour finale » qui modifie la carte `webServiceURL` vers The Wallet Crew.
```mermaid
sequenceDiagram
autonumber
participant Brand as Systèmes de la marque
participant Old as Ancien fournisseur
participant TWC as The Wallet Crew
participant Device as Appareil du client (Apple Wallet)
Brand->>Old: Demander l’export (serialNumber, authenticationToken, ID externes)
Old-->>Brand: Fichier / flux d’export
Brand->>TWC: Importer les identifiants
Brand->>Old: Demander une « mise à jour finale » définissant webServiceURL = The Wallet Crew
Old->>Device: Envoyer une notification de mise à jour
Device->>Old: Récupérer le package de carte mis à jour
Old-->>Device: Carte mise à jour avec le nouveau webServiceURL
Brand->>TWC: Mettre à jour les données de la carte après la bascule
TWC->>Device: Envoyer une notification de mise à jour
Device->>TWC: Récupérer le package de carte mis à jour
TWC-->>Device: Contenu de carte mis à jour
```
{% endtab %}
{% tab title="Google Wallet" %}
La migration Google sur place fonctionne uniquement si les cartes existantes appartiennent à un `issuerId` que vous contrôlez. Dans ce cas, The Wallet Crew met à jour les mêmes ID de ressources d’objet.
```mermaid
sequenceDiagram
autonumber
participant Brand as Systèmes de la marque
participant Old as Ancien fournisseur
participant TWC as The Wallet Crew
participant Google as Google Wallet
participant Device as Appareil du client (Google Wallet)
Brand->>Old: Demander l’export (ID de ressource d’objet, ID externes)
Old-->>Brand: Fichier / flux d’export
Brand->>TWC: Importer les identifiants (ID de ressources)
Brand->>TWC: Mettre à jour les données de la carte après la bascule
TWC->>Google: Mettre à jour l’objet existant (même issuerId)
Google-->>Device: Le client voit le contenu de la carte mis à jour après la synchronisation
```
{% endtab %}
{% endtabs %}
{% stepper %}
{% step %}
### Configurer les identifiants de l’émetteur The Wallet Crew
Vous avez besoin que The Wallet Crew s’authentifie comme le même « émetteur » que les cartes existantes.
* Pour Apple, utilisez le même Carte Type ID que votre fournisseur actuel dans la mesure du possible. Configurez ensuite les certificats.\
Suivez : [Certificats Apple Wallet](/configure/fr/advanced-configuration/wallet/apple-and-google-wallet/apple-wallet-certificates.md).
* Pour Google, confirmez quel compte émetteur Google Wallet possède les cartes existantes. Vous avez besoin d’accéder à ce compte émetteur.\
Suivez : [Compte Google Wallet](/configure/fr/advanced-configuration/wallet/apple-and-google-wallet/google-wallet-account.md).
{% endstep %}
{% step %}
### Exportez les identifiants techniques des cartes depuis votre fournisseur actuel
Demandez à votre fournisseur actuel une ligne d’export par carte.
Au minimum, exportez :
* Apple : **numéro de série** et **jeton d’authentification**
* Google : **ID de ressource** (ou ID d’objet)
* Vos identifiants externes (afin d’associer chaque carte au bon client)
{% endstep %}
{% step %}
### Importez ces cartes dans The Wallet Crew
Importez les identifiants exportés dans The Wallet Crew afin que chaque enregistrement de carte puisse être lié à ses identifiants Apple/Google existants.
Commencez par [Importation et exportation](/configure/fr/advanced-configuration/wallet/import-and-export.md). Si vous avez besoin d’un flux de mise à jour en masse basé sur des fichiers, consultez [Mettre à jour une carte à l’aide de fichiers plats](/configure/fr/advanced-configuration/wallet/import-and-export/update-pass-using-flat-files.md).
{% hint style="info" %}
Les imports de migration nécessitent souvent des colonnes supplémentaires (jeton d’authentification Apple, ID de ressource Google).
Si vous ne savez pas comment mapper ces champs dans votre tenant, demandez à l’équipe The Wallet Crew de confirmer le format de fichier attendu.
{% endhint %}
{% endstep %}
{% step %}
### Effectuez la bascule : redirigez les mises à jour des cartes Apple vers The Wallet Crew
Les cartes Apple Wallet récupèrent les mises à jour depuis le `webServiceURL` intégré dans la carte.
Pour migrer sans réinstallation, votre fournisseur actuel doit mettre à jour `webServiceURL` sur les cartes existantes et déclencher une mise à jour afin que les appareils téléchargent la nouvelle version de la carte.
{% hint style="warning" %}
N’arrêtez pas le service web Apple de votre ancien fournisseur avant d’avoir validé la bascule sur des appareils réels.
Si l’ancien point de terminaison cesse de répondre avant que les appareils reçoivent la « mise à jour finale », les cartes peuvent cesser de se mettre à jour.
{% endhint %}
Demandez à votre ancien fournisseur de mettre à jour en masse toutes les cartes existantes afin que leur `webServiceURL` corresponde à The Wallet Crew `webServiceURL` :
> `https://api-passd.neostore.cloud/api//passes/apple`
remplacez `` par votre tenantId, confirmez la valeur auprès de l’équipe d’assistance The Wallet Crew.
{% endstep %}
{% step %}
### Validez sur un petit échantillon
Choisissez 2 à 3 cartes sur chaque plateforme.
Mettez à jour un champ visible via The Wallet Crew. Vérifiez ensuite qu’il se met à jour sur les appareils.
Si vous devez accélérer le rafraîchissement pendant les tests, lancez une mise à jour push depuis The Wallet Crew. Cela est utile sur les deux plateformes : les appareils Apple récupèrent le package de carte mis à jour, et les utilisateurs Google voient l’objet mis à jour plus tôt.
{% endstep %}
{% step %}
### Surveillez après la bascule
Surveillez les mises à jour et l’utilisation pendant quelques jours. Conservez une option de retour arrière si votre fournisseur précédent la prend en charge.
Pour Apple, le retour arrière signifie généralement rediriger `webServiceURL` à nouveau et déclencher une mise à jour. N’essayez pas ceci à moins de disposer d’un point de terminaison confirmé et fonctionnel chez l’ancien fournisseur.
{% endstep %}
{% endstepper %}
## Pièges fréquents
Les échecs Apple et Google se présentent différemment. Ces vérifications permettent de détecter la plupart des problèmes rapidement.
### Apple Wallet
Si les clients signalent que les cartes cessent de se mettre à jour après la bascule, il s’agit généralement de l’un des cas suivants :
* Le `webServiceURL` n’a pas été mis à jour sur les cartes installées.
* L’ancien fournisseur a mis à jour `webServiceURL` mais n’a pas déclenché de mise à jour push.
* Les identifiants Apple de The Wallet Crew ne correspondent pas à l’identité de la carte d’origine (Carte Type ID / certificat).
### Google Wallet
Si les mises à jour échouent sur Google, il s’agit généralement de l’un des cas suivants :
* Les cartes existantes appartiennent à un autre `issuerId`.
* L’« ID de ressource » exporté ne correspond pas aux ID d’objet mis à jour.
* Les autorisations de la Google Pay & Wallet Console ne permettent pas les mises à jour à partir des identifiants The Wallet Crew.
## FAQ
Les clients doivent-ils réinstaller leur carte ?
En général, non.
Si vous redirigez correctement le `webServiceURL` Apple, les cartes existantes continuent de se mettre à jour sur place.
Pour Google, si vous conservez le même compte émetteur et les mêmes ID de ressources, les utilisateurs conservent généralement la même carte.
Pourquoi avons-nous besoin du jeton d’authentification Apple ?
Apple utilise le jeton d’authentification pour authentifier les demandes de mise à jour pour un numéro de série donné.
Sans lui, un nouveau fournisseur ne peut pas fournir de manière fiable des mises à jour à la même carte installée.
Pouvons-nous migrer des cartes Google Wallet entre des comptes émetteurs ?
Pas sur place.
Les cartes Google Wallet sont liées au compte émetteur. Si l’émetteur change, prévoyez un flux de réémission.
Comment savoir si la bascule Apple a fonctionné ?
Mettez à jour un champ visible dans The Wallet Crew et confirmez le changement sur un appareil réel. Si vous le pouvez, confirmez également que la carte installée appelle le point de terminaison The Wallet Crew en vérifiant les journaux du serveur ou en demandant à l’assistance The Wallet Crew de confirmer le trafic.
Que se passe-t-il si nous ne pouvons pas conserver le même Apple Carte Type ID ?
Prévoyez une réémission.
Si l’identité d’émetteur Apple change, les clients doivent généralement ajouter une nouvelle carte. Effectuez un déploiement contrôlé et conservez l’ancienne carte valide pendant une période de transition lorsque cela est possible.
Que se passe-t-il si notre fournisseur actuel ne peut pas envoyer la « mise à jour finale » Apple ?
Vous ne pourrez peut-être pas migrer les cartes Apple sur place.
Sans mise à jour finale, les cartes installées continuent d’appeler l’ancien `webServiceURL`. Dans ce cas, vous devez soit maintenir l’ancien point de terminaison actif, soit prévoir un flux de réémission.
Devons-nous modifier les codes-barres ou la logique d’utilisation ?
Pas nécessairement.
Si vous conservez les mêmes identifiants de carte et générez la même charge utile de code-barres, votre flux de scan en magasin ou au portique peut rester inchangé. Validez-le explicitement pendant le pilote en scannant les cartes migrées dans des conditions réelles.
Que devons-nous communiquer aux clients pendant la migration ?
Si la migration est effectuée sur place, vous n’avez généralement rien à communiquer. Les clients conservent la même carte et elle continue de se mettre à jour.
Si vous devez réémettre des cartes, communiquez clairement et suffisamment tôt le nouveau flux « Ajouter à Wallet ». Restez concis et concentrez-vous sur ce que les clients doivent faire.
---
# 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/move-passes-to-the-wallet-crew.md?ask=&goal=
```
`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.