Summary

  • Le premier projet Gamepad donnait aux jeux web les valeurs des boutons et des axes. Une manette réduite aux touches d’un clavier ou aux gestes d’une souris perdait ses nuances et demandait des logiciels supplémentaires.
  • Le projet W3C de 2025 garde la liste des manettes vide jusqu’à un véritable geste du joueur. La politique d’autorisations constitue une autre porte ; un stick qui tremble tout seul ne doit pas sonner à la place de la personne.

Un joueur branche une manette et lance un jeu. Le clavier sait dire qu’une touche est enfoncée, pas jusqu’où l’on tire une gâchette. La souris traduit encore moins bien un volant tourné d’un quart. Le premier projet public du W3C, en mai 2012, évitait ces déguisements. Il donnait au script des axes, des boutons, un identifiant, un rang et le moment où l’état avait changé. Des événements annonçaient la connexion et le retrait. La manette pouvait cesser de se faire passer pour du matériel de bureau.

Les valeurs étaient concrètes : de -1 à 1 pour un axe, de 0 à 1 pour un bouton. Une gâchette pressée à moitié restait pressée à moitié. id aidait à reconnaître le type de commande, l’index à distinguer plusieurs joueurs sur un canapé. Ces données servent le jeu. Elles ressemblent aussi à un petit registre de matériel. Si la page peut le lire avant qu’une partie commence, un site de passage apprend ce qui est posé près de l’ordinateur sans que personne ait voulu jouer.

La manette peut faire elle-même les présentations. Le projet W3C du 10 juillet 2025 indique que navigator.getGamepads() renvoie une liste vide tant qu’un geste de l’utilisateur sur une manette n’a pas été observé. Le texte cite explicitement la limitation du fingerprinting. L’appareil est peut-être branché ; la page n’en reçoit pas encore la liste. Une pression volontaire ou un mouvement franc d’un stick qui revient au centre fait commencer la conversation. La main du joueur passe avant la curiosité du site.

Une sonnette paraît simple jusqu’à ce qu’on examine les ressorts. Certains boutons restent bloqués en position active, et certains sticks frémissent autour de leur point de repos. Ni un interrupteur maintenu ni un bruit aléatoire ne doit constituer un nouveau bonjour. Le projet demande donc de reconnaître le passage depuis un état neutre : un bouton déjà vu relâché devient pressé, ou un axe précédemment proche du centre franchit un seuil. Une vieille manette ne devrait pas présenter toute seule son propriétaire à chaque page du quartier.

D’autres verrous restent en place. Un document qui n’est pas pleinement actif reçoit une liste vide. S’il n’est pas autorisé par la Permissions Policy gamepad, getGamepads() lève SecurityError. Le geste conditionne la visibilité de la manette pour le script ; il ne distribue pas une permission universelle à toutes les pages intégrées. Le navigateur choisit quels documents accèdent à la fonction, l’application décide ce que fait un bouton, la personne accomplit le premier geste. Trois rôles, une seule manette.

Après cette introduction, le jeu a besoin de lire l’état rapidement. Le tableau de getGamepads() contient les commandes connectées avec lesquelles il y a eu interaction ; une place libérée peut contenir null. Les événements signalent les arrivées et les départs. L’index est un emplacement de gestion, réutilisable après un retrait, pas une identité éternelle. Les axes et les boutons servent à sauter, tourner, freiner ou piloter depuis le canapé une interface de salon. L’API transporte le mouvement, pas le scénario.

L’historique des publications du W3C part du projet de 2012 et va jusqu’à la version de 2025. Ces dates décrivent les textes, pas une adoption simultanée par tous les navigateurs. La trajectoire, elle, est nette : un jeu a besoin d’une véritable entrée de manette ; la page qui ne joue pas n’a pas besoin d’en faire l’appel avant même que le joueur la prenne en main.

Enfin un doigt appuie, et le personnage bouge. Le navigateur ouvre la porte au bon moment : après que la personne tenant la manette a sonné.