Le probleme des standards haptiques : pourquoi le retour de force a reussi et le vibrotactile non

Tue, 14 Apr 2026 00:00:00 +0000

Il y a un schema dans le domaine de l’haptique dont on ne parle pas assez : une moitie du domaine a un grave probleme de standardisation, et l’autre moitie l’a resolu presque par accident.

La fragmentation vibrotactile

Du cote vibrotactile (moteurs de vibration, actuateurs lineaires resonants, le type d’haptique qu’on trouve dans les manettes de jeu et les telephones), il y a de serieux efforts pour unifier les choses. Le Haptics Industry Forum coordonne une grande partie de ce travail, en lien avec MPEG, le Khronos Group, l’IEEE et l’ISO. L’effort phare est du cote de MPEG, qui traite desormais l’haptique comme un type de media de premier ordre, au meme titre que l’audio et la video, avec une representation codee a la fois des signaux haptiques et des experiences haptiques interactives. Autour, on trouve une page d’usage HID pour que les appareils decrivent leurs propres capacites, ainsi que des API de plateforme via Khronos (OpenXR, glTF) et l’IEEE P2861.3. Tout vise la meme chose : definir comment encoder et transmettre des signaux haptiques peu importe le materiel (combien d’actuateurs, ou ils sont places, quelle reponse en frequence ils ont), pour qu’un createur puisse produire un contenu une seule fois et le voir fonctionner sur de nombreux appareils.

Ce travail est important parce que le monde vibrotactile a un probleme chronique : l’innovation materielle depasse largement le support logiciel.

Tous les quelques annees, une nouvelle manette ou un nouvel accessoire sort avec des capacites haptiques vraiment interessantes. Et ensuite presque personne ne developpe de logiciel pour l’exploiter.

Le cimetiere du gaming

Le schema est peniblement coherent a travers les consoles :

Xbox One est sortie avec des impulse triggers, des moteurs dans chaque gachette capables de creer des vibrations directionnelles nuancees. Du materiel veritablement innovant. Une poignee de jeux de lancement les supportait. Puis Microsoft a semble oublier leur existence. La plupart des jeux sont sortis avec du rumble basique ou rien.

PlayStation 5 a introduit le DualSense avec des gachettes adaptatives et un retour haptique haute fidelite. Les studios first-party de Sony l’ont utilise magnifiquement, et Astro’s Playroom etait une veritable vitrine. Les developpeurs tiers ? La plupart ont livre le meme rumble generique qu’avant.

Nintendo Switch a le HD Rumble que les propres jeux de Nintendo utilisent avec soin et coherence. Le support tiers est clairseme.

L’economie est brutale : implementer un retour haptique correct pour chaque plateforme signifie developper le contenu plusieurs fois avec des APIs specifiques a chaque plateforme. C’est environ le triple de l’effort pour une fonctionnalite que la plupart des joueurs ne remarqueront pas consciemment. Alors les studios passent, les joueurs ne decouvrent jamais ce que le materiel peut faire, et la generation suivante fait face a la meme indifference.

C’est un probleme de la poule et de l’oeuf que les standards essaient de resoudre en rendant le contenu portable entre appareils. Ecrire une fois, ressentir partout. Mais on n’en est pas encore la.

Le retour de force : le standard accidentel

Maintenant comparons avec le retour de force, le type d’haptique utilise en teleoperation, simulation chirurgicale et recherche. Ici, quelque chose d’interessant s’est passe : la standardisation a emerge naturellement, sans que personne n’ecrive de specification formelle.

La raison, c’est la physique.

Quand on construit un systeme qui simule une interaction physique (toucher une surface virtuelle, teleoperer un bras robotique, s’entrainer a une procedure chirurgicale), le format de donnees est presque predetermine :

Entree : Position en coordonnees cartesiennes (X, Y, Z en metres), optionnellement des rotations (quaternions ou angles d’Euler)
Sortie : Forces (X, Y, Z en Newtons), optionnellement des couples

C’est tout. Chaque appareil a retour de force, d’une simple interface haptique de bureau 3 DDL a un simulateur chirurgical complexe, parle ce meme langage. La physique dicte le format.

Cela signifie que convertir une simulation d’un appareil a un autre est direct. La simulation renvoie des forces en Newtons ; un appareil different lit des positions en metres et rend des forces en Newtons. La seule chose qui change, c’est la couche de transport (USB, Bluetooth, port serie) et la cinematique propre a l’appareil.

CHAI3D : la preuve que ca marche

La meilleure preuve que ce standard de facto fonctionne, c’est CHAI3D, un framework de rendu haptique cree il y a une vingtaine d’annees. Des le debut, il a ete concu pour supporter plusieurs appareils haptiques via une abstraction commune.

Ajouter un nouvel appareil a CHAI3D signifie implementer une fine couche de pilote qui traduit entre l’interface position/force du framework et le protocole de communication de l’appareil. Le code de simulation ne change pas. Le moteur physique ne change pas. On remplit un template bien defini, et le nouvel appareil fonctionne avec toutes les simulations existantes.

Vingt ans plus tard, CHAI3D reste une reference pertinente. Des simulations ecrites il y a dix ans tournent encore sur du materiel qui n’existait pas quand elles ont ete creees. C’est la puissance d’une interface stable basee sur la physique.

L’experience de pensee du convertisseur

Cette standardisation naturelle ouvre une possibilite interessante : on n’a meme pas besoin de toucher au code de simulation pour supporter un nouvel appareil.

Puisqu’on sait que les donnees qui circulent dans le systeme sont des positions dans un sens et des forces dans l’autre, on pourrait construire un convertisseur qui se place dans la chaine de communication (interceptant le trafic USB par exemple) et traduit entre appareils. L’information essentielle (positions, forces) reste la meme ; seul l’emballage change.

Certains appareils envoient des angles articulaires bruts qui necessitent une cinematique directe pour produire des positions cartesiennes. D’autres envoient directement des positions cartesiennes. Mais une fois qu’on sait quel format un appareil utilise, la conversion est mecanique.

C’est fondamentalement different du monde vibrotactile, ou le contenu lui-meme (quel motif jouer, a quelle frequence, sur quel actuateur) est intrinsequement specifique a l’appareil.

Deux mondes, un seul domaine

Le contraste est frappant :

	Vibrotactile	Retour de force
Standard	Fragmente, efforts actifs de standardisation	De facto, impose par la physique
Portabilite du contenu	Faible (specifique a l’appareil)	Elevee (interface position/force)
Integration nouvel appareil	Necessite nouveau contenu	Necessite seulement un pilote
Adoption industrielle	Large mais superficielle	Etroite mais profonde
Defi principal	Support logiciel du materiel	Accessibilite du materiel

Le cote vibrotactile a une portee massive (milliards de telephones et manettes) mais n’arrive pas a convaincre les createurs de contenu d’investir dans un support correct. Le cote retour de force a un marche minuscule mais une interoperabilite quasi parfaite entre appareils.

Il y a quelque chose a apprendre du succes accidentel du retour de force. Quand l’interface est dictee par le domaine (la physique, dans ce cas) plutot que par des fabricants individuels, la standardisation arrive gratuitement. Les efforts de standardisation vibrotactile essaient de creer cette meme inevitabilite : definir une representation au niveau du domaine qui transcende tout materiel specifique.

C’est un travail difficile. Mais le monde du retour de force montre que c’est possible. Parfois le standard n’a pas besoin d’etre ecrit. Il a juste besoin d’etre evident.