# Pourquoi une carte Apple Wallet se met à jour plus tard > Sur Android le compteur change tout de suite ; sur iPhone il change quand le client ouvre son portefeuille. Ce n'est pas un bug, c'est un protocole que Kanz ne peut pas parler depuis là où il tourne. - Source: https://usekanz.com/blog/apple-wallet-mise-a-jour - Langue: fr - Autres langues: [en](https://usekanz.com/en/blog/apple-wallet-pass-updates), [ar](https://usekanz.com/ar/blog/tahdith-apple-wallet) - Format: Markdown, généré depuis la même source que la page. - Publié le: 2026-08-04 - Auteur: Kanz - Sujets: Wallet, Technique, Produit - Temps de lecture: 4 min Tu ajoutes un tampon. Sur un téléphone Android, le compteur de la carte a changé. Sur un iPhone, il changera au moment où le client ouvrira son portefeuille, pas à la seconde où tu scannes. Aucun tampon ne se perd : il est enregistré côté serveur avant que la carte n'en sache quoi que ce soit, et la carte affiche l'état courant dès qu'elle le demande. Ce qui diffère, c'est le déclencheur. Cet article explique pourquoi, parce que la raison est intéressante et parce qu'un produit qui laisse croire à l'instantané finit par se faire reprocher un mensonge plutôt qu'une limite. ## Les deux portefeuilles ne se mettent pas à jour de la même façon Côté Google, mettre à jour une carte est un appel web ordinaire. Kanz appelle, l'objet change, c'est fini. Côté Apple, la carte sur le téléphone ne va pas chercher spontanément son nouvel état. Le serveur est censé envoyer une petite notification silencieuse qui dit à l'iPhone « ta carte a changé, viens la rechercher ». Ce n'est pas une notification visible : c'est un réveil, avec un contenu vide, et c'est le téléphone qui vient ensuite chercher la nouvelle version. Ce réveil passe par le service de notifications d'Apple, qui ne parle **que** le protocole HTTP/2 et refuse HTTP/1.1. ## Là où Kanz tourne, ce protocole n'est pas disponible Kanz s'exécute sur un environnement d'exécution en périphérie de réseau, celui qui rend le scan rapide partout. Cet environnement ne sait pas ouvrir une connexion HTTP/2 vers un serveur arbitraire. Trois façons de s'y prendre ont été essayées, et voici ce que chacune répond : ```text http2.connect(...) → la méthode n'est pas implémentée tls.connect({ ALPNProtocols: ['h2'] }) → l'option n'est pas implémentée fetch('https://api.push.apple.com/…') → connexion réseau perdue ``` Un appel de contrôle vers un site quelconque depuis le même isolat répond 200. Ce n'est donc pas un blocage réseau ni une histoire de pare feu : c'est bien le protocole. Ça élimine aussi les deux réflexes habituels. Réécrire le module avec `fetch` ne marche pas, c'était la première hypothèse et la mesure l'a tuée. Déplacer le code vers l'autre service ne marche pas non plus, parce que c'est le même type d'environnement. ## Ce que ça coûte réellement Uniquement l'immédiateté, et seulement sur iPhone. Le compteur interne de la carte est incrémenté à chaque tampon, donc dès qu'un appareil vient regarder, il reçoit l'état courant. Le client ouvre son portefeuille au comptoir pour présenter sa carte, et c'est précisément ce geste qui déclenche la mise à jour. Dans le cas d'usage principal, celui du passage suivant, la carte est donc à jour au moment exact où quelqu'un la regarde. Ce qui est perdu, c'est le petit plaisir de voir le compteur bouger sous les yeux du client pendant qu'il tient son téléphone. C'est réel et ce n'est pas rien, mais ça n'affecte ni le comptage, ni la récompense, ni la fiabilité. ## Ce qu'il faudrait pour le remettre Un seul petit service ordinaire, hébergé n'importe où, exposant un point d'entrée protégé que Kanz appellerait pour lui faire relayer le réveil. Tout le reste est déjà écrit et correct : la signature du jeton d'authentification, les règles de sujet et de priorité, et le traitement des jetons d'appareils qui ne répondent plus. Autrement dit, ce n'est pas un travail de conception, c'est une brique d'infrastructure en plus. Elle n'a pas été ajoutée parce qu'une pièce mobile supplémentaire, qui peut tomber en panne toute seule, pour gagner quelques secondes sur un compteur que le client regarde de toute façon, n'est pas un bon échange aujourd'hui. ## Trois détails qui font échouer ça silencieusement Pour quiconque construit la même chose, voici les pièges. Chacun produit une réponse positive du serveur d'Apple et une carte qui ne bouge pas, ce qui est la pire combinaison possible à déboguer. Le sujet de la notification doit être **l'identifiant du type de laissez-passer**, et pas l'identifiant d'une application. Le contenu doit être un objet vide : c'est un réveil, pas une notification. Et une notification de type arrière plan exige la priorité basse ; avec la priorité haute, elle est acceptée puis ignorée. ## Pourquoi c'est écrit ici Parce qu'un utilisateur qui remarque le décalage mérite mieux que « ça devrait se mettre à jour tout seul ». Et parce qu'un produit qui documente ses limites là où on peut les lire est plus facile à croire quand il affirme le reste. Le fonctionnement général de la carte, du premier scan à la récompense, est [décrit ici](/blog/carte-fidelite-wallet). ## Créer un compte L'essai dure 30 jours et ne demande aucune carte bancaire. - [Inscription](https://usekanz.com/signup) - [Espace commerçant](https://usekanz.com/panel)