Input Manager, gérer les périphériques d’entrée du navigateur

Le besoin : centraliser les entrées sans multiplier les écouteurs dispersés

Dans un petit script, ajouter un événement sur le clavier ou la souris ne pose aucun problème. On écoute une touche, on récupère une position et on déclenche immédiatement une action. Mais lorsque plusieurs écrans ou composants utilisent les mêmes périphériques, le code commence à se fragmenter. Chaque partie de l’application ajoute ses propres écouteurs, conserve son propre état et interprète les données à sa manière. On obtient alors des événements répartis partout, des comportements difficiles à désactiver et des erreurs qui apparaissent lorsqu’un écran n’est plus visible mais continue pourtant à écouter.

Le problème devient encore plus évident lorsqu’on ajoute le tactile, une manette, le microphone ou la caméra. Ces API ne fonctionnent pas toutes de la même façon, certaines demandent une autorisation et d’autres doivent être interrogées régulièrement. Au lieu de laisser chaque fonctionnalité gérer ces différences, l’InputManager crée un point d’entrée unique. L’application ne dialogue plus directement avec les périphériques : elle consulte un état commun et reçoit des informations déjà normalisées.

Le principe : transformer des événements bruts en un état simple à consulter

Le clavier produit des événements lorsqu’une touche est enfoncée ou relâchée. La souris fournit une position, des boutons et une molette. Le tactile peut contenir plusieurs points de contact, tandis qu’une manette expose des axes et une liste de boutons. L’InputManager écoute ces sources puis conserve leur état courant dans des objets simples. Le reste du code peut alors demander si une touche est active, connaître la position du pointeur ou lire la valeur d’un stick sans recréer la logique nécessaire à chaque fois.

Cette séparation évite que les composants dépendent directement des API du navigateur. Un bouton, un jeu ou un outil de dessin peut utiliser la même information sans savoir si elle vient d’une souris ou d’un écran tactile. On obtient une interface commune, plus facile à comprendre et à remplacer. C’est également utile pour les tests, car il devient possible de simuler un état d’entrée sans déclencher de véritables événements dans la page.

Le clavier et la souris : conserver un état continu plutôt qu’un simple événement

Un événement indique ce qui vient de se produire, mais il ne répond pas toujours à la question la plus utile : « cette touche est-elle encore enfoncée ? ». L’InputManager conserve donc un ensemble de touches actives et le met à jour à chaque pression ou relâchement. Le code applicatif peut consulter cet ensemble à n’importe quel moment. Cette approche convient aussi bien à un raccourci clavier qu’au déplacement continu d’un objet, car elle distingue clairement le début, la durée et la fin d’une action.

Pour la souris, le gestionnaire mémorise la position relative à la zone de démonstration, l’état des boutons et le dernier mouvement de molette. Les coordonnées sont calculées dans le repère utile à l’application et non dans celui de la fenêtre entière. On évite ainsi les corrections répétées liées aux marges, au défilement ou à la position du composant. La souris devient un pointeur normalisé que le reste du projet peut consulter sans connaître les détails du navigateur.

Le tactile : gérer plusieurs points de contact avec la même logique

Les Pointer Events permettent de traiter la souris, le tactile et le stylet avec une base commune. Chaque contact reçoit un identifiant, une position et un type de pointeur. L’InputManager conserve ces informations dans une collection et les supprime lorsque le contact se termine. L’application peut ainsi savoir combien de doigts sont posés, suivre leur déplacement et construire ensuite un glissement, un zoom ou une rotation.

La ressource ne cherche pas à imposer des gestes complexes. Elle fournit d’abord une représentation propre des contacts. Les comportements métiers restent dans l’application : déplacer un élément, dessiner, sélectionner ou contrôler un personnage. Cette frontière est importante, car le gestionnaire doit décrire les entrées sans décider ce qu’elles signifient.

La manette : lire les boutons et les axes sans événement classique

L’API Gamepad fonctionne différemment du clavier. Le navigateur expose une liste de manettes, mais leur état doit être relu régulièrement. L’InputManager interroge donc la première manette disponible à chaque rafraîchissement de la démonstration. Il extrait les boutons pressés et les valeurs des axes, puis les présente dans un format facile à utiliser. Une zone morte est appliquée aux sticks pour éviter que de petites variations physiques soient interprétées comme un déplacement.

Le gestionnaire ne suppose pas qu’une manette possède une forme précise. Il présente les index des boutons et des axes tels qu’ils sont fournis par le navigateur. L’application peut ensuite créer ses propres associations : bouton principal, saut, validation ou déplacement. On sépare ainsi la lecture du périphérique de la signification des commandes.

Le micro et la caméra : demander une autorisation explicite et maîtriser leur arrêt

Le microphone et la caméra accèdent à des données sensibles. Ils ne doivent donc jamais démarrer automatiquement. La démonstration propose un bouton distinct pour chaque source et laisse le navigateur afficher sa demande d’autorisation. Une fois le micro actif, un analyseur audio calcule un niveau sonore approximatif afin d’alimenter un vumètre. La caméra affiche simplement le flux vidéo reçu, sans enregistrement ni envoi vers un serveur.

L’arrêt est aussi important que le démarrage. Fermer l’affichage ne suffit pas : les pistes du flux doivent être arrêtées pour libérer réellement le périphérique et éteindre son indicateur. L’InputManager conserve donc les flux actifs et sait les couper proprement. Cette gestion centralisée évite les périphériques laissés ouverts lorsqu’un utilisateur change d’écran ou ferme un outil.

Le résultat : une API cohérente pour des périphériques très différents

Un InputManager n’a pas pour rôle de décider des actions de l’application. Il collecte, normalise et expose les entrées disponibles. Le clavier, la souris, le tactile, la manette, le micro et la caméra gardent leurs particularités, mais leur accès est regroupé dans une seule classe. Le code métier devient plus lisible, car il manipule des états clairs au lieu d’accumuler des abonnements, des autorisations et des formats différents.

Cette organisation convient aux jeux, mais aussi aux outils de dessin, interfaces tactiles, tableaux de bord, applications multimédias ou formulaires avancés. Elle permet d’ajouter une nouvelle source sans modifier toutes les fonctionnalités existantes. En plaçant les périphériques derrière un gestionnaire commun, on réduit le couplage et on prépare l’application à évoluer sans reconstruire sa gestion des entrées.