Application pilotée au regard pour un centre hospitalier

Le contexte

Un centre hospitalier universitaire accompagne des patients qui ont perdu l’usage de leurs mains — maladies neurodégénératives, paralysies, suites d’accident. Pour eux, un écran tactile n’est pas une interface : c’est un mur.

Il existe des oculomètres — des capteurs qui suivent le regard et permettent de désigner un point de l’écran avec les yeux. Le matériel existe. Ce qui manquait, c’était une application conçue dès le départ pour ce mode d’interaction.

L’enjeu

Une application pilotée au regard ne s’obtient pas en ajoutant le support d’un capteur à une application classique. Tout change.

Il n’y a pas de clic. Désigner et valider sont le même geste, ce qui impose un mécanisme de validation par fixation — regarder une cible assez longtemps pour confirmer. Trop court, l’utilisateur déclenche des actions sans le vouloir en parcourant l’écran du regard. Trop long, chaque interaction devient épuisante.

Les cibles doivent être grandes et espacées. La précision du regard n’est pas celle d’un doigt, encore moins celle d’une souris. Une interface dense, avec des petits boutons proches les uns des autres, est inutilisable.

Aucune erreur n’est neutre. Un utilisateur qui ne peut ni annuler d’un geste, ni fermer une fenêtre par réflexe, se retrouve bloqué. Chaque écran doit offrir une sortie, atteignable au regard.

Et la fatigue est le vrai adversaire. Le public visé se fatigue vite. Le nombre d’interactions nécessaires pour arriver à un résultat n’est pas un détail de confort : c’est le critère de réussite du produit.

Ce que nous avons fait

• Intégration de l’oculomètre comme mode d’entrée principal — non pas comme une option ajoutée, mais comme l’hypothèse de départ de toute l’interface.
• Un parcours guidé par étapes, avec une progression explicite. L’utilisateur sait toujours où il en est et combien il reste — ce qui compte doublement quand chaque étape demande un effort.
• Synthèse vocale et retours sonores. Le son porte l’information de confirmation, parce qu’un retour visuel discret passe inaperçu quand le regard est déjà mobilisé par la navigation.
• Une adaptation à la taille physique de l’écran, et non à sa résolution. Une cible doit faire la même taille réelle en centimètres quel que soit l’appareil — c’est la précision du regard qui commande, pas le nombre de pixels.
• Une architecture en couches séparant les données, le métier et l’interface, avec injection de dépendances et gestion d’état explicite.

Le résultat

Une application dont le mode d’interaction principal est le regard, livrée à un établissement hospitalier.

Sur ce projet, le choix d’architecture mérite un mot. Il aurait été plus rapide de tout mettre dans les écrans. Mais une application livrée à un CHU a vocation à être reprise, auditée, étendue par d’autres — parfois des années plus tard, parfois par une équipe interne. Séparer proprement les couches n’était pas une coquetterie technique : c’est ce qui rend le projet transmissible.

C’est aussi le projet qui rappelle le plus directement pourquoi l’accessibilité n’est pas une case à cocher en fin de développement. Ici, elle était le produit.