> 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/importation-et-exportation/migration-des-cartes/migrer-les-cartes-vers-wallet-crew.md).
# Migrer les cartes vers Wallet Crew
Utilisez ce guide lorsque vous souhaitez migrer **déjà installées** les 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, n’ont rien à réinstaller, et votre code-barres ainsi que votre flux d’utilisation restent inchangés.
La majeure partie du travail relève de la coordination, pas de l’implémentation. Vous alignez les identifiants d’émetteur, exportez les identifiants techniques qui relient chaque carte à son enregistrement Apple/Google existant, validez avec un petit pilote, puis procédez à une bascule contrôlée.
Si vous avez besoin du flux inverse, voir [Exporter des cartes de The Wallet Crew vers un autre fournisseur](/configure/fr/advanced-configuration/wallet/importation-et-exportation/migration-des-cartes/exporter-les-cartes-de-twc-vers-un-autre-fournisseur.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 d’obtenir une couche d’exploitation plus fiable.
* Une marque change de système sous-jacent (CRM, fidélité, billetterie, caisse) et doit transférer les cartes actives en toute sécurité.
## Avant de commencer
La plupart des migrations réussissent ou échouent en fonction des contraintes de la plateforme et de qui contrôle les identifiants d’émetteur.
Si vous voulez un contexte sur les identifiants et les données de carte, lisez [Structure.](/developers-guides/fr/architecture-de-carte/structure.md)
### Configurez votre projet The Wallet Crew avant de migrer
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 ». Il s’agit d’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 Wallet et pouvez signer/posséder les cartes (ID de type de Carte Apple 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ésion, ID de commande, ...). Ceux-ci doivent rester stables dans le temps.
* Vous pouvez générer le contenu de la carte à partir de votre source de vérité (intégration API, flux de 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 vrai appareil.
Liste de contrôle de préparation à la migration
Utilisez ceci comme liste de décision avant de toucher aux cartes de production.
* [ ] Vous savez quel ID de type de Carte Apple signe les cartes existantes.
* [ ] Vous disposez des identifiants Apple nécessaires pour conserver la même identité d’émetteur.
* [ ] Vous connaissez l’ `issuerId` qui détient 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 « dernière mise à jour » Apple (voir l’étape de bascule).
* [ ] Vous disposez d’un lot pilote de 2 à 3 vraies cartes par plateforme.
* [ ] Vous avez un plan de retour arrière pour Apple (si 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 : identifiants de carte (plateforme + externes)
Vous ne recréez pas les cartes pendant une migration. Vous importez des identifiants afin que The Wallet Crew puisse mettre à jour des 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ésion, 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 conserver des mises à jour correctes après la bascule.
Une seule carte peut avoir plusieurs identifiants externes. C’est utile lorsque vous rapprochez des données entre systèmes.
### Déterminez si vous pouvez migrer « à l’identique »
Apple et Google n’autorisent pas les mêmes modèles de migration.
#### Apple Wallet (la migration à l’identique 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 ID de type de Carte / identité de signature) et si vous redirigez le point de terminaison de mise à jour de la carte (`webServiceURL`).
Cela nécessite généralement que votre fournisseur actuel envoie au moins une « dernière mise à jour » aux cartes installées. Cette mise à jour intègre The Wallet Crew `webServiceURL` afin que les appareils commencent à interroger 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 de la 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 à l’identique. 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 rattacher The Wallet Crew à la *existante* carte 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 aussi partager l’ID de type de Carte Apple et le `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 montrent les points de contrôle nécessaires pour une bascule propre. L’idée clé est simple : vous importez les 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 à l’identique fonctionne généralement si vous conservez le même ID de type de Carte et si votre fournisseur actuel peut envoyer une « dernière mise à jour » 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, identifiants externes)
Old-->>Brand: Fichier / flux d’export
Brand->>TWC: Importer les identifiants
Brand->>Old: Demander le paramètre de « dernière mise à jour » en 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 à l’identique ne fonctionne que si les cartes existantes appartiennent à un `issuerId` que vous contrôlez. Dans ce cas, The Wallet Crew met à jour les mêmes ID de ressource 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, identifiants externes)
Old-->>Brand: Fichier / flux d’export
Brand->>TWC: Importer les identifiants (ID de ressource)
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 synchronisation
```
{% endtab %}
{% endtabs %}
{% stepper %}
{% step %}
### Configurez les identifiants d’émetteur de 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 ID de type de Carte que celui de votre fournisseur actuel chaque fois que possible. Configurez ensuite les certificats.\nSuivez : [Certificats Apple Wallet](/configure/fr/advanced-configuration/wallet/apple-wallet-et-google-wallet/certificats-apple-wallet.md).
* Pour Google, confirmez quel compte émetteur Google Wallet détient les cartes existantes. Vous avez besoin d’un accès à ce compte émetteur.\nSuivez : [Compte Google Wallet](/configure/fr/advanced-configuration/wallet/apple-wallet-et-google-wallet/compte-google-wallet.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 de pouvoir 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 relié à ses identifiants Apple/Google existants.
Commencez par [Importation et exportation](/configure/fr/advanced-configuration/wallet/importation-et-exportation.md). Si vous avez besoin d’un flux de mise à jour en masse basé sur des fichiers, voir [Mettre à jour une carte à l’aide de fichiers plats](/configure/fr/advanced-configuration/wallet/importation-et-exportation/mettre-a-jour-la-carte-a-laide-de-fichiers-plats.md).
{% hint style="info" %}
Les importations de migration nécessitent souvent des colonnes supplémentaires (jeton d’authentification Apple, ID de ressource Google).
Si vous ne voyez pas comment mapper ces champs dans votre tenant, demandez à l’équipe The Wallet Crew de confirmer le format de fichier attendu.
{% endhint %}
{% endstep %}
{% step %}
### Basculez : redirigez les mises à jour de carte Apple vers The Wallet Crew
Les cartes Apple Wallet récupèrent les mises à jour depuis le `webServiceURL` point de terminaison intégré à la carte.
Pour migrer sans réinstallation, votre fournisseur actuel doit mettre à jour `webServiceURL` 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’éteignez pas le service web Apple de votre ancien fournisseur avant d’avoir validé la bascule sur de vrais appareils.
Si le point de terminaison ancien cesse de répondre avant que les appareils reçoivent la « dernière mise à jour », 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`
remplacer `` par votre tenantId, confirmez la valeur avec l’équipe support de 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. Puis vérifiez que la mise à jour apparaît sur les appareils.
Si vous avez besoin d’accélérer l’actualisation pendant les tests, lancez une mise à jour push depuis The Wallet Crew. C’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 les utilisations 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 consiste généralement à rétablir `webServiceURL` et à déclencher une mise à jour. N’essayez pas cela sauf si vous disposez d’un point de terminaison confirmé et fonctionnel chez l’ancien fournisseur.
{% endstep %}
{% endstepper %}
## Pièges courants
Les échecs Apple et Google ne se manifestent pas de la même façon. Ces vérifications détectent la plupart des problèmes tôt.
### Apple Wallet
Si les clients signalent que les cartes cessent de se mettre à jour après la bascule, c’est généralement l’un de ces cas :
* 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 carte d’origine (ID de type de Carte / certificat).
### Google Wallet
Si les mises à jour échouent sur Google, c’est généralement l’un de ces cas :
* 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 l’Apple `webServiceURL` les cartes existantes continuent à se mettre à jour sur place.
Pour Google, si vous conservez le même compte émetteur et les mêmes ID de ressource, les utilisateurs gardent 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 requêtes de mise à jour pour un numéro de série donné.
Sans lui, un nouveau fournisseur ne peut pas servir de manière fiable les mises à jour de la même carte installée.
Pouvons-nous migrer des cartes Google Wallet entre comptes émetteurs ?
Pas à l’identique.
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 la modification sur un vrai appareil. Si possible, confirmez également que la carte installée appelle bien le point de terminaison The Wallet Crew en vérifiant les journaux serveur ou en demandant à l’assistance The Wallet Crew de confirmer le trafic.
Que faire si nous ne pouvons pas conserver le même ID de type de Carte Apple ?
Prévoyez une réémission.
Si l’identité d’émetteur Apple change, les clients doivent généralement ajouter une nouvelle carte. Déployez de manière contrôlée et, si possible, conservez l’ancienne carte valide pendant une période de transition.
Que faire si notre fournisseur actuel ne peut pas envoyer la « dernière mise à jour » Apple ?
Il se peut que vous ne puissiez pas migrer les cartes Apple à l’identique.
Sans dernière mise à jour, les cartes installées continuent d’interroger l’ancien `webServiceURL`. Dans ce cas, vous devez soit laisser le point de terminaison ancien en service, 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 que vous continuez à générer la même charge utile de code-barres, votre flux de scan en magasin ou à l’entrée peut rester inchangé. Validez-le explicitement pendant le pilote en scannant des cartes migrées dans des conditions réelles.
Que devons-nous communiquer aux clients pendant la migration ?
Si la migration se fait à l’identique, 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 tôt le nouveau flux « Ajouter à Wallet ». Restez bref 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/importation-et-exportation/migration-des-cartes/migrer-les-cartes-vers-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.