Un ticket arrive dans votre file : «Ajoutez un bouton Apple Wallet à l’e-mail de confirmation.» Simple en apparence, jusqu’à ce que vous découvriez les règles de badge imposées par Apple, le .pkpass signé, et la question de savoir vers quoi ce bouton doit réellement pointer. Le bouton en lui-même est la partie facile ; le relier à un pass réel et bien le positionner, c’est là que les équipes bloquent.
Voici l’essentiel pour qui doit livrer ce bouton : où le placer entre e-mail, web et application, les règles imposées par Apple et Google, et comment le relier à un lien d’installation actif qui enregistre réellement un pass. Bien fait, ce bouton augmente votre taux d’installation au lieu de dormir, ignoré, dans un template.
Où le bouton a vraiment sa place (e-mail, web, in-app)
Le bouton fonctionne à trois endroits, chacun avec une place naturelle liée au moment où le pass prend de la valeur.
Dans l’e-mail, il figure dans le message de confirmation ou d’offre : un reçu de commande, la confirmation d’un billet, une inscription à un programme de fidélité. Un point d’attention : le client peut ouvrir l’e-mail sur un ordinateur, où le bouton ne fonctionnera pas — ajoutez donc une ligne du type «Ouvrez cet e-mail sur votre iPhone pour ajouter le pass».
Sur le web, il a sa place sur les pages de confirmation et d’offre, à proximité immédiate de ce qui est enregistré : juste après le paiement, sur une confirmation de réservation, sur une page de coupon dédiée. Pour une boutique sous PrestaShop, Shopify ou WooCommerce — les trois plateformes les plus répandues en France —, le bouton trouve naturellement sa place sur la page de confirmation de commande.
Dans l’application, il apparaît partout où l’information du pass est déjà visible, juste après l’action qui le génère : un achat, une inscription, l’émission d’un billet. Les applications natives utilisent le contrôle bouton propre à Apple plutôt qu’une image.
Les règles officielles du bouton Apple
Apple considère ce badge comme une œuvre protégée par le droit des marques, les règles sont donc strictes — les respecter évite un rejet lors de la revue de l’application ou un bouton à l’aspect cassé.
Utilisez le SVG téléchargeable fourni par Apple pour le web et l’e-mail, et la version EPS pour les supports imprimés avec QR code. Ne créez pas votre propre version, et ne recolorez, ne pivotez, n’animez et n’ajoutez pas d’ombre au badge. Dans les applications natives, utilisez le contrôle PKAddPassButton, qui affiche automatiquement le bon rendu et la bonne langue.
Côté mise en page, conservez un espace de respiration minimum autour du badge équivalent à un dixième de sa hauteur, et placez-le sur un fond blanc ou clair. Pour les fonds sombres, Apple fournit une version en contour. Le badge doit rester secondaire par rapport à votre contenu principal, jamais dominer la mise en page.
Pour le nommage, écrivez «Apple Wallet» à la première mention puis «Wallet» ensuite, et incluez la mention de marque déposée d’Apple partout où vous affichez un texte légal. Ces règles de nommage font partie de ce qu’Apple vérifie.
Quelques erreurs font rejeter les boutons ou les rendent silencieusement inefficaces. Un badge personnalisé à la place de l’officiel échoue en revue, et un badge caché là où son utilité n’est pas claire est ignoré.
Un lien vers un pass non signé ou mal formé ne produit rien au tap, et un nommage incohérent comme «enregistrer sur le portefeuille iPhone» enfreint les règles de marque. Tout cela s’évite avec les visuels fournis et un pass correctement signé.
Bouton Add to Google Wallet : même mission, règles différentes
Si vous prenez en charge les deux portefeuilles — ce que la plupart des commerces devraient faire —, vous placerez un bouton Google à côté du bouton Apple. La mission est identique, les règles diffèrent.
Le bouton Google existe en XML Android, SVG et PNG, en noir uniquement, avec des variantes primaire et condensée. L’espace de respiration est fixé à 8dp sur tous les côtés, et le bouton doit mesurer au minimum 48dp de hauteur. Une règle facile à manquer : si d’autres boutons partagent la page, le bouton Add to Google Wallet doit être égal ou plus grand qu’eux, jamais plus petit.
Le bouton doit appeler un flux de l’API Google Wallet, qui ouvre l’application Google Wallet pour que l’utilisateur enregistre le pass sur son appareil Android et son compte Google. Pour le nommage, écrivez «Google Wallet» avec des majuscules à G et W, et utilisez le texte de bouton localisé fourni par Google plutôt que le vôtre.
Ce sont donc deux boutons et deux jeux de règles à gérer dans un même template. Créez le pass pour les deux standards, placez les deux badges côte à côte, et l’appareil du client fait le reste.
Relier le bouton à un lien d’installation actif
Un badge n’est qu’une image tant qu’il ne pointe pas vers un pass réel et signé. Trois éléments le relient à quelque chose que le client peut vraiment enregistrer.
-
Générer le lien d'installation par utilisateur
Le bouton pointe vers une URL d'installation qui résout vers un pass signé. Vous pouvez produire ce pass de deux façons : le construire vous-même avec le framework PassKit d'Apple, ce qui implique de générer et signer le .pkpass et de faire tourner un service pour héberger le lien, ou utiliser une plateforme de pass qui s'occupe de la signature et de l'hébergement pour vous. La première option donne un contrôle total et convient aux équipes disposant de ressources back-end ; la seconde est plus rapide pour la plupart des équipes marketing et produit. Avec une plateforme comme Pushwoosh Wallet passes, hébergée en UE, vous créez le pass une fois et générez ce lien d'installation sans gérer vous-même la signature du .pkpass. Pour un pass partagé, comme un coupon générique, un seul lien sert à tout le monde. Pour un pass personnalisé, comme une carte de fidélité avec les points d'un client précis, vous générez un lien unique par utilisateur afin que le pass enregistré porte ses données — un point qui touche directement à la protection des données personnelles et relève donc du RGPD.
-
Intégrer le bouton dans votre template ESP
Dans votre plateforme d'e-mail, placez le badge SVG Apple (et le bouton Google, si vous prenez en charge les deux) et pointez son lien vers l'URL d'installation. Pour un pass personnalisé, la plupart des plateformes d'e-mail permettent d'insérer le lien unique comme variable de personnalisation, afin que le bouton de chaque destinataire pointe vers son propre pass. Ajoutez la mention «à ouvrir sur votre iPhone», et gardez le badge sur un fond clair conformément aux règles d'Apple.
-
Suivre les enregistrements, pas seulement les clics
Un clic sur le badge n'est pas un enregistrement ; le client doit encore confirmer l'ajout du pass. Suivez l'ajout réel comme un événement à part afin de mesurer le taux d'installation, pas seulement le taux de clic. Ce chiffre vous dit si l'emplacement et l'offre fonctionnent, et c'est la métrique à optimiser, puisqu'un pass enregistré est celui qui reste sur le téléphone.
Un lien, tous les canaux
Générer un lien d’installation unique par utilisateur et le copier-coller à la main dans chaque canal ne tient pas au-delà de quelques campagnes. Le lien est le même actif, qu’il circule dans un e-mail, un push ou un SMS — l’approche efficace consiste donc à le générer une fois et à le réutiliser partout.
Avec Pushwoosh Wallet passes, vous créez le pass, générez le lien d’installation, et le distribuez sur push, e-mail et SMS depuis un seul endroit. Les données sont hébergées en UE et aux États-Unis, sur une infrastructure certifiée SOC 2 Type I et ISO 27001:2022 et conforme au RGPD. Les boutons Apple et Google pointent vers le même pass, et vous gérez les enregistrements et mises à jour sans jamais toucher à un fichier .pkpass.
Augmentez votre taux d’installation de wallet pass avec Pushwoosh
Livrez le bouton une fois et réutilisez le lien partout. Pushwoosh Wallet passes génère le lien d’installation pour Apple Wallet et Google Wallet et le distribue sur push, e-mail et SMS depuis un seul tableau de bord, avec hébergement des données en UE.
