Une nouvelle option de saisie, repérée dans une version récente de Gboard, suggère que Google prépare un mode Sign-to-Text capable de convertir la langue des signes en texte via la caméra du smartphone. Le projet s’inscrit dans les travaux de Google DeepMind sur l’interprétation des gestes. Des garde-fous de confidentialité sont évoqués, avec de la vidéo traitée localement et un envoi limité de données gestuelles.
Après la frappe, le glissé et la dictée vocale, le clavier Android pourrait ouvrir un nouveau canal d’écriture, pensé d’abord pour l’accessibilité, mais potentiellement utile à bien plus de situations du quotidien.
Gboard ajoute des indices d’un mode Sign-to-Text
Les signaux proviennent d’une exploration d’une mise à jour de Gboard, le clavier de Google largement diffusé sur Android. Dans ce type d’analyse, des éléments de code, des libellés ou des écrans non activés publiquement laissent entrevoir des fonctions en préparation. Ici, la présence d’une mention Sign-to-Text indique que le clavier se préparerait à accepter une entrée fondée sur la capture de gestes, puis à la convertir en texte dans le champ de saisie.
Le positionnement est cohérent avec l’objectif historique de Gboard, réduire la friction entre l’intention et le texte produit. Google propose déjà plusieurs méthodes, la saisie classique, le Glide (glissé sur les lettres) et la dictée vocale. La langue des signes constituerait un quatrième mode, avec une logique différente, la caméra devenant le capteur principal, et l’IA jouant le rôle de traducteur gestuel.
Sur le plan produit, l’intégration au clavier est un choix stratégique. Gboard est une couche transversale, utilisée dans les messageries, les e-mails, les navigateurs et de nombreuses applications. Si un mode de saisie en langue des signes est déployé, il pourrait fonctionner partout où le clavier s’affiche, sans dépendre d’une application dédiée. Pour les utilisateurs, l’intérêt est immédiat, rédiger un message sans passer par un outil tiers, ni copier-coller depuis une autre interface.
Reste la question des contraintes matérielles. L’usage d’une caméra frontale implique un cadrage stable des mains et du haut du corps, selon la langue des signes visée. Les smartphones récents disposent d’optiques et de capteurs plus performants, mais aussi d’unités de calcul dédiées à l’IA. Le déploiement pourrait donc être progressif, en commençant par des appareils récents ou par certaines régions, avant une généralisation.
Google n’a pas officialisé de calendrier public dans les éléments évoqués. Comme souvent avec les fonctions repérées en amont, l’existence d’un prototype n’implique pas une sortie immédiate. Mais le fait que le clavier se prépare à accepter ce type d’entrée suggère un niveau d’avancement supérieur à une simple expérimentation de laboratoire.
Les recherches de Google DeepMind sur l’interprétation gestuelle
Le travail attribué à Google DeepMind s’inscrit dans une tendance plus large, appliquer l’apprentissage automatique à la compréhension du mouvement humain. Interpréter la langue des signes ne revient pas à reconnaître des postures fixes, il faut analyser une séquence, la vitesse, la trajectoire, l’orientation des mains, la configuration des doigts, et souvent des indices du visage ou du buste. La difficulté est comparable, sur le plan technique, à la reconnaissance vocale, mais avec une grammaire visuo-gestuelle.
Les outils d’IA actuels sont capables d’extraire des points clés du corps, puis de les convertir en données structurées. Dans ce cadre, un système peut transformer une vidéo en squelette de points articulaires, puis tenter d’identifier des signes et des transitions. Les éléments mentionnés autour de Gboard évoquent justement un flux où la vidéo resterait sur l’appareil, tandis que des données brutes de gestes pourraient être envoyées à une IA dans le cloud. Cette séparation est importante, elle réduit l’exposition de l’image, mais elle n’élimine pas les enjeux de confidentialité.
La langue des signes n’est pas universelle. Il existe des langues distinctes, comme l’ASL (American Sign Language), la LSF (langue des signes française) et de nombreuses variantes nationales. Même à l’intérieur d’un pays, des différences régionales existent. Pour un produit grand public, Google devra préciser quelles langues sont prises en charge, et comment l’IA gère les dialectes, les niveaux de formalité et les registres. Une approche plausible consiste à commencer par une ou deux langues très documentées, puis à étendre progressivement.
La conversion signe vers texte pose aussi une question linguistique, traduire n’est pas transcrire. Les structures syntaxiques de certaines langues des signes diffèrent de celles des langues écrites. Un système naïf pourrait produire un texte grammaticalement étrange, ou perdre des nuances. Un système plus ambitieux devrait intégrer une étape de reformulation, proche de la traduction automatique, tout en conservant l’intention. Cette étape est délicate, car elle risque d’introduire des interprétations erronées, surtout dans des échanges sensibles.
Dans ce contexte, l’intégration à Gboard peut offrir un avantage, l’IA peut s’appuyer sur le contexte de saisie, la langue du clavier, le dictionnaire personnel, et les corrections habituelles. Mais la promesse d’accessibilité impose une fiabilité élevée, car l’utilisateur doit pouvoir corriger rapidement, et comprendre ce qui a été interprété. Les choix d’interface, comme l’affichage des segments reconnus, la possibilité de valider signe par signe, ou de revenir en arrière, seront déterminants pour l’adoption.
Confidentialité: traitement local de la vidéo et envoi de gestes au cloud
Les protections évoquées reposent sur une idée simple, conserver la vidéo sur l’appareil et n’envoyer au serveur que des informations abstraites, décrites comme des données brutes de gestes. Sur le papier, cela limite le risque de fuite d’images, qui peuvent contenir un visage, un intérieur de domicile, ou des éléments sensibles en arrière-plan. C’est un point essentiel pour une fonction qui exige d’activer la caméra dans un contexte de messagerie.
Mais l’expression données brutes de gestes mérite une clarification. Selon la mise en uvre, il peut s’agir de coordonnées de points clés (mains, doigts, poignets), de vecteurs de mouvement, ou d’une représentation compressée issue d’un modèle local. Même sans vidéo, ces données peuvent être suffisamment riches pour reconstruire partiellement une séquence, ou pour identifier des habitudes gestuelles. L’anonymisation dépendra du niveau de détail, de la durée conservée, et des politiques de stockage.
Un autre enjeu tient au partage entre traitement local et traitement cloud. Les smartphones modernes disposent d’accélérateurs IA, ce qui permet de faire tourner des modèles sur l’appareil. Google pourrait choisir une reconnaissance intégralement locale, mais cela implique des modèles optimisés et une consommation énergétique maîtrisée. Un traitement hybride, avec une première extraction locale puis une interprétation cloud, peut améliorer la qualité, mais augmente la dépendance au réseau et la surface d’exposition des données.
Dans un déploiement réel, les paramètres doivent être explicites. L’utilisateur devra savoir quand la caméra est active, quelles données sortent de l’appareil, et comment désactiver la fonction. Les précédents de Google sur la confidentialité, comme les traitements on-device pour certaines fonctions de Pixel, montrent une direction, mais chaque nouvelle fonctionnalité est un cas particulier. Pour une saisie en langue des signes, l’acceptabilité sociale dépendra fortement de la transparence, car la caméra dans un clavier est un scénario sensible.
Il existe aussi un risque de perception, même si la vidéo ne quitte pas l’appareil, l’idée d’un clavier qui regarde peut inquiéter. Un indicateur visuel permanent, une activation volontaire et une documentation claire seront nécessaires. Les régulateurs, en Europe notamment, pourraient s’intéresser à la qualification des données, au consentement, et à la minimisation. Pour Google, l’enjeu est d’éviter qu’une avancée d’accessibilité ne soit freinée par un déficit de confiance.
Accessibilité: usages concrets et limites attendues sur smartphone
Le bénéfice le plus direct concerne la communication des personnes sourdes ou malentendantes qui utilisent la langue des signes. Pouvoir produire du texte en signant face à la caméra peut réduire les frictions dans les situations où la dictée vocale est inutile ou inadaptée. Dans un environnement bruyant, dans un transport, ou dans un lieu où parler n’est pas souhaitable, cette méthode pourrait offrir une alternative pratique.
L’usage ne se limite pas à la communication. Un mode Sign-to-Text intégré pourrait servir à remplir un formulaire, rédiger un e-mail, ou interagir avec des services, tout en conservant le confort d’une langue gestuelle. Pour des échanges rapides, l’intérêt dépendra de la vitesse de reconnaissance et de la latence. Si le texte apparaît avec un décalage trop important, l’expérience risque d’être frustrante. Le clavier devra aussi gérer les corrections, car les erreurs de reconnaissance seront inévitables, surtout au début.
Les limites techniques sur smartphone sont connues. Le champ de la caméra frontale peut être étroit, ce qui oblige à se placer à une distance précise. La lumière joue un rôle majeur, contre-jour, faible luminosité, ou lumière artificielle peuvent dégrader la détection des mains. Les accessoires, comme des bagues, des manches amples, ou des gants, peuvent également perturber l’analyse. Google devra probablement recommander des conditions d’usage, ce qui peut restreindre l’intérêt en mobilité.
La question de la compatibilité linguistique est centrale. Si Google commence par une langue des signes dominante, une partie du public restera exclue. Dans un pays comme la France, une prise en charge de la LSF serait attendue, mais elle demande des données d’entraînement adaptées et une validation avec des communautés locales. L’accessibilité ne se décrète pas, elle se construit avec des tests utilisateurs, des associations, et des itérations, faute de quoi l’outil risque de mal comprendre des signes courants ou des variantes.
Enfin, une saisie en langue des signes sur clavier pose un défi d’ergonomie. Le clavier est une interface de texte, pas une surface de capture vidéo. Il faudra décider où s’affiche l’aperçu caméra, comment on déclenche l’enregistrement, et comment on passe rapidement d’un mode à l’autre. Si Google parvient à intégrer cela sans alourdir Gboard, la fonction pourrait devenir un repère important de l’accessibilité sur Android, et un terrain d’émulation pour les concurrents sur iOS et sur les claviers tiers.
