Si votre plateforme d’engagement client ne propose pas de wallet passes natifs, vous avez deux options. Connecter un outil de cartes et garder deux systèmes synchronisés, ou passer à une plateforme qui émet les cartes Apple et Google Wallet sur le même profil client. La première démarre plus vite. La seconde est plus simple à exploiter dès que le wallet fait partie de vos parcours.
Cet article s’adresse aux équipes qui utilisent des plateformes comme Braze, OneSignal ou CleverTap et qui veulent des wallet passes sans tout reconstruire. Pour une vue fournisseur par fournisseur, consultez le comparatif Wallet passes.
Votre point de départ
La prise en charge du wallet varie beaucoup d’une plateforme d’engagement à l’autre. Braze ajoute le wallet via des partenaires comme PassKit. OneSignal ne propose pas de wallet passes natifs. Vérifiez la documentation actuelle de votre propre plateforme avant de planifier, car cela évolue.
Sans prise en charge native, la carte vit dans un système et le client dans un autre. Chaque carte que vous émettez, mettez à jour ou ciblez a besoin des données des deux.
Option A : garder votre CEP et ajouter un outil de cartes
Vous conservez votre plateforme actuelle pour le push, l’e-mail et les segments, et vous connectez un outil de cartes autonome pour Apple et Google Wallet.
En pratique, cela fonctionne généralement ainsi. Votre CEP ou votre backend appelle l’API de l’outil de cartes pour émettre les cartes, souvent via des webhooks. Si l’outil de cartes expose des événements, ils remontent dans votre CEP pour que vous puissiez segmenter les détenteurs.
L’avantage est réel. Rien ne migre. Votre équipe garde ses outils et ses parcours, et vous pouvez commencer par un seul cas d’usage, comme une carte de fidélité.
L’inconvénient s’accumule avec le temps. Deux bases de données à synchroniser, deux abonnements, deux revues de sécurité et de conformité au RGPD. Chaque scénario qui combine une mise à jour de carte et un message, comme «vos points expirent bientôt», se construit sur deux outils.
Pour une équipe française, la revue RGPD n’est pas une formalité : chaque outil ajouté est un sous-traitant de plus, avec son propre DPA à négocier et ses propres transferts de données à documenter. Avec l’option A, cette charge est doublée dès le premier jour.
Option B : passer à une plateforme avec wallet natif
Vous transférez votre messagerie vers une plateforme qui émet les wallet passes nativement, sur le même profil que le push, l’in-app, l’e-mail et le SMS.
Les cartes sont émises par User ID dans la plateforme. Les segments, les parcours et les canaux voient tous le détenteur de la carte comme un seul client. Une étape de parcours émet la carte, et la suivante envoie le lien.
Vous obtenez un seul profil, un seul parcours et un seul contrat. Les mises à jour de cartes et les messages partent du même déclencheur, et il n’y a pas de couche de synchronisation à surveiller.
Sur le marché français, où iOS et Android sont à peu près à parité, ce point compte : la même étape de parcours doit servir aussi bien les clients Apple Wallet que Google Wallet, sans deux flux à maintenir en parallèle.
Le coût, c’est la migration elle-même : modifications du SDK, import des données, reconstruction des parcours et des modèles. Elle est rentable quand le wallet est un canal de long terme, pas une campagne ponctuelle.
| Option A : CEP + outil de cartes | Option B : wallet natif | |
|---|---|---|
| Délai avant la première carte | Rapide | Dépend de la migration |
| Systèmes à maintenir | 2, plus une couche de synchronisation | 1 |
| Parcours avec mises à jour de cartes | Construits sur 2 outils | 1 parcours |
| Segmentation des détenteurs | Via des données synchronisées | Même profil |
| Contrats et revues fournisseurs | 2 | 1 |
| Adapté à | Un seul cas d'usage wallet | Le wallet comme canal de fidélisation |
Grille de décision
Évaluez votre situation sur 4 questions.
-
Périmètre
Le wallet est-il une seule campagne, ou un canal que vous exploiterez pendant des années ? Une seule campagne oriente vers l'option A.
-
Canaux
Combien de scénarios combinent une carte avec le push, l'e-mail ou le SMS ? Beaucoup oriente vers l'option B.
-
Équipe
Avez-vous des développeurs pour construire et maintenir une couche de synchronisation ? Sinon, l'option A devient coûteuse avec le temps.
-
Résidence des données
Avez-vous besoin d'un hébergement en UE et de moins de sous-traitants pour le RGPD ? Chaque fournisseur supplémentaire est un sous-traitant de plus à examiner.
Si au moins deux de vos réponses sont «long terme», «beaucoup», «pas de développeurs» ou «moins de sous-traitants», regardez sérieusement l’option B. Si aucune ne l’est, l’option A est un très bon choix, et vous pourrez y revenir dans un an.
Calculer le coût de deux outils
L’option A paraît moins chère le premier jour, parce que rien ne bouge. Sur une année, ajoutez ce qui n’apparaît jamais sur la facture du fournisseur de cartes : la construction de l’intégration, la maintenance de la synchronisation, le travail de parcours en double et une seconde revue fournisseur.
L’option B concentre le coût au début : le travail de migration, puis un seul abonnement plateforme. Comparez les deux sur 12 à 24 mois, pas sur 1.
Checklist de migration
Si vous choisissez l’option B, organisez la migration autour du client, pas de l’outil.
- Inventoriez ce que vous envoyez. Listez les campagnes push, e-mail, SMS et in-app, les parcours et les segments à migrer.
- Cartographiez vos données. User ID, tags, événements et enregistrements de consentement. C’est le User ID qui relie une carte à un client.
- Configurez le wallet une seule fois. Un certificat Apple Pass Type ID (compte Apple Developer, 99 $ par an) et un Google Issuer ID, avec le compte de service Pushwoosh invité sur votre émetteur.
- Intégrez le SDK. Remplacez l’ancien SDK dans votre application et testez le push avant de basculer le trafic.
- Reconstruisez d’abord les parcours clés. Bienvenue, panier abandonné, réactivation, puis les nouveaux scénarios wallet.
- Préparez le lancement des cartes. Émettez les cartes depuis une étape de parcours et envoyez le lien par e-mail, SMS ou push.
- Faites tourner les deux plateformes brièvement. Gardez l’ancienne plateforme pendant une courte période de recouvrement, puis désactivez-la.
Pendant la migration, utilisez l’API pour émettre les cartes depuis votre propre backend.
Pour un e-commerçant, le calendrier compte autant que la checklist. Évitez de basculer en pleines Soldes d’hiver, pendant les French Days fin avril ou à l’approche du Black Friday : visez une période creuse, pour que vos parcours de relance panier et vos premières cartes soient rodés avant le prochain temps fort.
Simplifiez votre stack avec Pushwoosh
Pushwoosh émet des cartes Apple et Google Wallet natives sur les mêmes User ID, segments et parcours que le push, l’in-app, l’e-mail, le SMS et WhatsApp. C’est une seule plateforme, hébergée sur sa propre infrastructure en Allemagne et aux États-Unis, conforme au RGPD et certifiée SOC 2 Type 2. Voyez où se situe Pushwoosh parmi les options wallet.
Ajouter le wallet ne devrait pas vouloir dire greffer un outil de plus. Cela devrait vouloir dire un seul profil client sur lequel chaque canal peut agir.
