Une IA peut-elle transformer votre main en commande pour un appareil réel ?

Imaginez que vous tendez la main au-dessus d’un synthétiseur et demandez à un casque d’associer la hauteur de vos doigts à la fréquence de coupure du filtre. Vous savez déjà ce que le geste doit faire. La difficulté tient au lien entre la main qui bouge et le véritable bouton, surtout si l’instrument communique en MIDI et que le casque voit seulement un boîtier sur une table.

ControlAnything, prototype de recherche décrit dans une prépublication de Bektur Ryskeldiev datée du 5 novembre 2026, reporte une partie de ce travail au moment où vous en avez besoin. La personne sélectionne une cible dans la vue d’un Meta Quest 3, donne une instruction et attend qu’un agent sur MacBook écrive le connecteur. Il peut renvoyer des commandes virtuelles, un programme qui lit les mouvements de la main, ou les deux. Le projet propose le code et des démonstrations, dont une simulation sur ordinateur.

L’enregistrement Quest 3 de l’auteur Bektur Ryskeldiev montre des commandes générées pour l’OP-1 Field pendant l’évaluation. Telli.sh a redimensionné l’image. Prépublication et image originale · Notice MIT de la vidéo du projet

Le casque peut créer une commande pour une tâche précise. Reste à savoir comment le système établit ce qui s’est réellement passé. Un accusé de réception MIDI, un bouton généré qui répond et un changement de son du synthétiseur sont trois éléments de preuve distincts.

Montrer un appareil lance la demande

Le prototype associe un client WebXR, un serveur sur le portable, un agent de programmation et quelques modes d’accès aux appareils. SAM 3.1 dessine les contours des objets possibles dans le casque. Un pincement peut transformer un objet en repère, et Muse Spark peut proposer une identification. La prépublication présente cette identification comme une hypothèse à comparer à des indices, par exemple le nom d’un port MIDI ou la réponse d’un appareil. Le repère sert à désigner la cible. Le port, la passerelle du navigateur ou l’exécuteur de touches permet au portable d’agir dessus. Prépublication ControlAnything, sections 3–4

De la cible sélectionnée à un résultat visible ou audible. Illustration originale de Telli.sh.

Un repère ressemble à une étiquette de bagage. Il nomme ce que vous voulez déplacer, tandis que le trajet et la destination restent à établir. La séance du 5 novembre illustre cette distinction. Toutes les demandes s’adressaient au repère du MacBook que l’auteur avait créé auparavant. Quand la vraie cible était le synthétiseur OP-1 Field ou le stabilisateur DJI Osmo Mobile 4, l’auteur la nommait dans sa demande. La séance porte donc sur la connexion à des appareils que le système savait déjà joindre. Sélectionner un synthétiseur ou un stabilisateur inconnu reste une expérience à faire.

Le système disposait déjà d’éléments utiles avant le premier geste. Le projet documente MIDI, Bluetooth et la simulation des touches. Les notes conservées par l’agent contenaient le nom du port de l’OP-1, les numéros de contrôleur du filtre et les instructions de mouvement du stabilisateur avant la séance. Une image peut suggérer que l’objet est un synthétiseur. Ces renseignements indiquent au programme quelle valeur envoyer, où l’envoyer et comment rester dans la plage prévue.

Le modèle construit la commande une fois, le programme gestuel tourne en continu

Le prototype sépare le travail coûteux de création d’une interaction de son exécution répétée. Une demande vocale est transcrite. L’agent écrit un connecteur et le serveur vérifie qu’il fonctionne et que chaque commande renvoyée correspond à une action déclarée. Le programme lit des signaux dérivés des articulations à chaque image et émet des valeurs ou des événements. Le modèle intervient à la configuration. Le casque exécute ensuite le programme lorsque vous bougez. Implémentation dans la prépublication

La différence compte pour une commande continue comme le son ou le cadrage. Si un modèle de langage devait choisir chaque valeur, chaque image entraînerait une décision lente. Un petit programme peut associer la hauteur de la main à un paramètre, limiter la plage et réagir quand vous relâchez le geste. Pour avancer dans une vidéo, il pourrait demander un mouvement délibéré et attendre le retour en position neutre avant de se réarmer. Ces exemples illustrent les possibilités de conception ouvertes par l’approche. Ils ne décrivent pas une mesure du prototype.

La prépublication rapporte une durée médiane de 32,5 secondes pour les neuf demandes arrivées à l’état prêt, avec une plage de 24,9 à 57,8 secondes. La mesure part de la prise en charge par le serveur et exclut la transcription de la voix. Les appels au modèle représentent une médiane de 89,9 % de cette durée. L’auteur précise que la séance n’a pas mesuré le délai entre le mouvement de la main et la réponse de l’appareil. Résultats de la prépublication

Ces mesures donnent un prix concret à la souplesse. Une demi-minute peut convenir si elle remplace un connecteur qui demanderait un après-midi de développement et servirait pendant toute une répétition. Elle se justifie moins pour une tâche qui prend cinq secondes avec la télécommande existante. Le meilleur cas probable est une commande utilisée souvent, même si elle n’est configurée qu’une seule fois.

Deux demandes proches sur la simulation d’eau ont pris 31,6 et 32,5 secondes, chacune produisant un connecteur neuf. Le cache de la consigne a fourni 91,7 % des jetons d’entrée de la séance, mais le premier connecteur n’a pas été réutilisé comme commande prête. Enregistrer un mappage vérifié et laisser la personne choisir de le réutiliser réduirait une autre partie du coût de préparation. Le suivi des versions deviendrait important, car le connecteur réutilisé doit encore correspondre à l’appareil, au compte et à la plage pour lesquels il a été testé.

Filtre, stabilisateur et navigateur demandent des preuves différentes

La séance du 5 novembre comportait dix demandes sur cinq cibles et une seule personne portait le casque, l’auteur. Neuf demandes ont atteint l’état prêt, et il a arrêté la dernière. C’était un essai technique exploratoire. Les demandes étaient libres, certaines reprenaient des objectifs précédents et le dispositif s’appuyait sur une connaissance préalable des appareils. Le nombre décrit le déroulement de cette séance. La capacité d’un débutant à connecter un appareil inconnu est une autre mesure. Tableau et méthode de la prépublication

Un accusé de réception et un effet mesuré répondent à deux questions différentes. Illustration originale de Telli.sh.

Prenez le synthétiseur. MIDI peut transmettre une commande de filtre valide alors que le réglage de son réagit autrement ou que la réception MIDI est coupée. La prépublication décrit un cas antérieur où des messages confirmés restaient sans effet audible jusqu’à l’activation de la réception. Un changement sonore enregistré avec une note de test connue en dirait plus qu’une deuxième copie du même message de journal.

Le stabilisateur donne une autre version de la même leçon. La passerelle a relevé 889 réponses de rotation positives, y compris des commandes d’arrêt et de relâchement. Cela montre que la communication a accepté des commandes pendant une interaction prolongée. Le journal ne contient pas d’angle fiable. Dans un autre essai, on pourrait définir une cible sans risque et comparer l’angle demandé à une vidéo ou un repère. On saurait alors si le mouvement est exact, reproductible et reste dans les limites attendues.

Les touches simulées ajoutent un problème d’identité. Une frappe peut réussir au niveau du système et arriver dans la mauvaise fenêtre. Un test dans le navigateur devrait contrôler l’onglet actif, confirmer que le contenu attendu a changé et vérifier que les autres fenêtres n’ont pas bougé. Plus l’interface du connecteur est abstraite, plus une définition claire de la fin de tâche devient utile.

L’arrêt doit fonctionner avant que le geste inspire confiance

L’arrêt de ControlAnything est indépendant du modèle. La personne peut interrompre la génération, présenter les deux paumes pendant l’utilisation ou employer une commande du menu au poignet. L’hôte peut désactiver le connecteur et émettre des signaux neutres, comme arrêter le stabilisateur ou libérer l’état MIDI. Le programme gestuel s’exécute dans un processus restreint sur le casque et passe une vérification sur 480 images synthétiques avant déploiement. L’implémentation limite aussi les actions déclarées et les plages que le programme peut émettre. Sécurité et arrêt dans la prépublication

Le connecteur sur le portable est dans une autre situation. La prépublication décrit un processus Node ordinaire avec les permissions de l’utilisateur du portable, sans bac à sable pour ce processus généré. Le SDK peut limiter les commandes envoyées par l’itinéraire prévu, tandis qu’un connecteur capable d’exécuter du code général conserve les droits du compte utilisé. Une version destinée à la production limiterait ces privilèges au niveau du système et restreindrait l’accès aux appareils nécessaires.

Imaginez une installation avec deux dispositifs mobiles. L’interface peut sembler rassurante si elle n’en nomme qu’un seul. Il reste à savoir si le connecteur peut découvrir l’autre et agir dessus. Dans une démonstration maîtrisée, seule la cible du test est joignable. On vérifie l’arrêt indépendamment, on laisse à l’opérateur la place de s’écarter et on observe ce qui se passe si le suivi ou la connexion de l’appareil est perdu.

La distinction vaut aussi pour le code généré qui lit son environnement. Le prototype demande au modèle de traiter les textes des images ou des réponses d’outils comme des données. L’instruction peut guider le comportement. Les permissions et les voies de communication déterminent ce qu’une erreur peut affecter. Avant d’utiliser de vrais appareils ou des comptes actifs, les deux questions méritent une réponse distincte.

Commencez sur une cible simulée et limitez l’essai

Le README présente une simulation sur ordinateur avec Node 22.12 ou une version plus récente et Chrome. Sans clé API, le serveur rejoue selon le projet des réponses enregistrées dans un mode de test clairement signalé. Cela permet d’observer le parcours du repère aux commandes générées avant d’ajouter casque, appels au modèle ou matériel. Une réponse rejouée montre un chemin connu dans l’interface. Une évaluation en direct commence quand la cible, le geste ou la réponse du modèle change. Instructions de démonstration de ControlAnything

1. Lisez les instructions du dépôt et lancez la simulation documentée dans un environnement jetable. Ouvrez le simulateur et l’émulateur du casque, puis marquez le portable simulé qui exécute le synthétiseur virtuel.
2. Sélectionnez la demande de boutons proposée et vérifiez que l’indicateur du mode de test est visible. Notez comment l’interface représente la cible et quand les commandes apparaissent.
3. Bougez un bouton virtuel, vérifiez le changement sur la cible simulée et essayez l’arrêt documenté. Séparez l’observation de l’interface et les journaux du connecteur.
4. Pour un futur essai physique, choisissez un appareil à faible risque avec une commande réversible. Écrivez le résultat attendu avant l’envoi. Prévoyez un moyen indépendant de voir ou d’entendre le changement et d’arrêter l’appareil.

Pour un atelier, commencez par le synthétiseur visuel avant d’essayer une fonction qui ouvre un service réel ou simule des touches sur l’ordinateur hôte. Le README distingue explicitement le parcours Instagram Reels de la simulation. Si vous cherchez à comprendre le mappage, une cible locale délimitée rend l’observation plus nette.

Sur du matériel réel, mesurez à part le temps de mise en place et la qualité de la commande. Chronométrez l’arrivée à l’état prêt. Observez le délai entre le geste et l’effet, une éventuelle dérive lorsque la main quitte la zone suivie et le résultat quand la personne change d’avis. Une étude plus longue pourrait aussi montrer si un débutant sélectionne la bonne cible sans aide.

Une commande utile se crée et se vérifie

L’idée centrale de ControlAnything est de laisser une personne décrire une interaction physique sans devoir préparer une interface sur mesure. L’évaluation montre comment cela fonctionne sur des cibles connues et un seul casque. Une commande réutilisable doit aller au-delà d’une connexion réussie. Elle doit identifier l’appareil, limiter ses pouvoirs et rendre l’effet assez visible pour que la personne qui porte le casque sache ce qui s’est produit.

Sources

• Prépublication ControlAnything, déposée le 5 novembre 2026
• Implémentation complète, évaluation et limites
• Dépôt du projet, démonstrations et instructions du simulateur

---

Pour retrouver les notes et les décisions d’une séance de prototypage, créez un compte Telli.sh.