Le bouton qui ne marchait que sur Samsung

Le buzzer fonctionnait partout. Sur mon Mac, sur mon iPhone, sur l’Android de test, sur trois navigateurs et deux tailles d’écran. Puis quelqu’un a rejoint une partie depuis un Galaxy A33, et rien ne s’est passé.

Ce que je croyais

Le premier réflexe est toujours le mauvais. J’ai cherché du côté du réseau, parce que c’est là que se cachent les problèmes de temps réel. Latence, perte de connexion, message qui n’arrive pas. J’ai instrumenté le serveur, ajouté des journaux, vérifié les horodatages. Tout était propre. Le message n’était jamais envoyé, parce que le clic n’était jamais détecté.

Ce que c’était

Le navigateur Samsung Internet traite l’ordre des événements tactiles différemment de Chrome. Le gestionnaire était accroché via la délégation d’événements de React, et l’annulation du comportement par défaut intervenait avant l’appel réel. Sur tous les autres navigateurs, l’ordre masquait le problème.

// avant : dépend de l'ordre d'événements du navigateur
onTouchStart={(e) => { e.preventDefault(); buzz(); }}

// après : l'action d'abord, l'annulation ensuite
onPointerDown={(e) => { buzz(); e.preventDefault(); }}

Deux lignes. Trois jours.

Ce que j’en retiens

Les outils d’IA écrivent ce gestionnaire correctement dans quatre-vingt-quinze pour cent des cas. Les cinq pour cent restants ne sont pas des erreurs de code : ce sont des différences de comportement entre navigateurs, qui n’apparaissent que sur un appareil que personne dans l’équipe ne possède. Aucun modèle ne vous préviendra, parce que la question ne se pose que quand un vrai utilisateur avec un vrai téléphone appuie sur un vrai bouton.

La vitesse de construction a été multipliée. Le temps passé à vérifier que ça marche vraiment, lui, n’a pas bougé d’un pouce.

C’est, je crois, la chose la plus importante à comprendre sur cette période. On ne gagne pas du temps sur la qualité. On en gagne sur la frappe.