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 :
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.