IA en langue des signes sur téléphone : accessibilité au-delà de la voix

Ce que l’IA en langue des signes permet aujourd’hui sur téléphone

L’IA en langue des signes sur téléphone vient de franchir une étape concrète : le système SL2T de Google DeepMind permet de dicter en langue des signes américaine, ou ASL, puis d’obtenir du texte en anglais dans Gboard et Transcription instantanée. Cette disponibilité commence sur Pixel 11. Elle ne concerne donc pas encore tous les téléphones Android, toutes les langues des signes ni toutes les langues écrites.

Le parcours est utile pour saisir un message, effectuer une recherche ou contribuer à une conversation affichée à l’écran sans passer par la parole. Une personne signe devant la caméra ; le téléphone produit du texte qui peut ensuite être relu, corrigé ou inséré dans un champ compatible. Dans Transcription instantanée, cette entrée peut aussi faciliter un échange entre une personne signante et une personne qui parle, à côté des fonctions existantes de transcription de la parole et des sons.

La présentation de SL2T par Google DeepMind décrit l’ASL vers l’anglais comme le premier déploiement produit. Google présente l’extension à davantage d’appareils et de langues comme une direction future. Cette distinction compte : un modèle entraîné avec des données multilingues ne rend pas automatiquement chaque langue disponible dans le produit.

Ce jalon apporte avant tout une nouvelle méthode d’entrée. Le texte obtenu n’accorde aucune permission et ne déclenche pas, à lui seul, une action Android. Pour envoyer un message, modifier un réglage ou appeler un contact, le téléphone doit encore comprendre l’intention, choisir la bonne application, résoudre la cible et présenter un résultat vérifiable. C’est précisément là que l’accessibilité rejoint la conception des agents mobiles.

Pourquoi traduire une langue des signes diffère d’une transcription vocale

Une langue des signes n’est ni une suite universelle de gestes ni une représentation mot à mot d’une langue orale. Il existe plus de 200 langues des signes, avec leurs grammaires, leurs lexiques et leurs conventions culturelles. L’ASL, la langue des signes française et la langue des signes britannique sont distinctes, même lorsque les communautés environnantes utilisent des langues écrites apparentées.

La parole se déroule principalement sous forme de signal sonore séquentiel. Une langue des signes peut exprimer plusieurs informations en même temps : configuration et orientation des mains, emplacement dans l’espace, mouvement, posture du corps, direction du regard et expression du visage. Un mouvement des sourcils ou de la bouche peut porter une fonction grammaticale. L’espace peut servir à installer puis à rappeler des personnes, des objets ou des relations.

La traduction doit donc reconstruire le sens d’un énoncé visuel complet. Elle ne peut pas se limiter à reconnaître une forme de main puis à lui associer un mot. Les systèmes fondés uniquement sur des gants, quelques gestes prédéfinis ou un petit vocabulaire de commandes répondent à d’autres usages ; ils ne couvrent pas la richesse linguistique d’une conversation signée.

Cette réalité change notre manière de concevoir un assistant mobile pour personnes sourdes. La caméra doit cadrer les éléments pertinents, le modèle doit conserver les relations temporelles et spatiales, et l’interface doit afficher une traduction modifiable. Une incertitude doit devenir visible avant qu’elle ne se transforme en destinataire erroné ou en action non souhaitée. La traduction est ainsi une étape linguistique à part entière, avec ses propres mécanismes de vérification.

Comment fonctionne SL2T et où passent les données

SL2T sépare l’analyse de l’image et la traduction. D’après Google DeepMind, MediaPipe Holistic extrait sur le téléphone des repères géométriques décrivant la pose, le visage et les mains. La vidéo brute est ensuite écartée, tandis que les coordonnées géométriques nécessaires à la traduction sont envoyées vers un serveur. Le traitement ne se déroule donc pas entièrement sur l’appareil.

Le modèle traduit directement ces séquences de repères vers le texte. Cette architecture évite de réduire la langue à une succession de signes isolés et lui permet d’exploiter le contexte de la phrase. L’entraînement annoncé couvre plus de 100 000 heures de données et plus de 50 langues des signes. La fonction proposée aux utilisateurs commence néanmoins par l’ASL vers l’anglais sur l’appareil prévu pour ce lancement.

La distinction entre vidéo et coordonnées reste importante pour faire un choix éclairé. Les coordonnées corporelles constituent encore des données issues d’une scène filmée ; leur traitement à distance mérite d’être compris selon le contexte d’usage. Une conversation banale, un rendez-vous médical et un échange professionnel n’exposent pas les mêmes informations. L’utilisateur doit savoir quand la caméra fonctionne, quel résultat part vers un service et comment interrompre la capture.

Les exemples officiels montrent aussi des erreurs résiduelles sur des signes rares, l’épellation digitale rapide, certains classificateurs, les constructions passives et le temps grammatical. Cette transparence fournit une bonne règle pratique : relire le texte traduit avant toute action conséquente. Un score de référence mesure un ensemble de tests ; il ne garantit pas la même précision pour chaque personne, chaque éclairage, chaque cadrage ou chaque variante linguistique.

Pour les agents mobiles, la leçon est nette. L’architecture doit conserver une frontière visible entre les données observées, le texte interprété et l’action proposée. Chacune de ces étapes possède son propre niveau d’incertitude et son propre bouton d’arrêt.

Choisir une modalité accessible selon la tâche

L’accessibilité au-delà de la voix repose sur une combinaison de modalités. Aucune entrée ni aucune sortie ne convient à toutes les situations. Le bon choix dépend de la tâche, du contexte physique, des préférences de la personne et des fonctions réellement disponibles sur son appareil.

Transcription instantanée convertit la parole et les sons proches en texte et permet aussi de saisir une réponse. Sous-titres instantanés ajoute des sous-titres à certains contenus audio et appels sur les appareils compatibles. Le RTT maintient une conversation textuelle pendant un appel, tandis que l’accès par contacteurs offre une navigation adaptée aux personnes qui utilisent un ou plusieurs contacteurs plutôt que l’écran tactile.

Les personnes aveugles ou malvoyantes rencontrent d’autres combinaisons d’entrée et de sortie. Notre guide Téléphone Android à la voix pour personnes aveugles ou malvoyantes : TalkBack, Voice Access et FoneClaw approfondit ces parcours sans confondre leurs besoins avec ceux des personnes sourdes ou signantes.

Un agent mobile accessible doit permettre de changer de modalité en cours de tâche. Si la caméra perd le cadrage, le texte saisi reste disponible. Si le réseau disparaît, un clavier ou une autre entrée prend le relais. Si le son n’est pas utilisable, l’état et les demandes d’approbation restent lisibles à l’écran et perceptibles par vibration.

Passer d’une consigne accessible à une action sûre

Supposons qu’une personne signe une phrase traduite par « envoie à Sam que j’arrive dans dix minutes ». Le texte est une représentation de la demande, pas encore une instruction exécutable. Qui est Sam ? Faut-il utiliser un SMS, une messagerie ou un courriel ? Le texte doit-il partir immédiatement ou rester en brouillon ? L’agent doit résoudre ces questions avant de toucher au téléphone.

Le parcours sûr comprend plusieurs états visibles : texte interprété, intention, application cible, capacité retenue, permission requise, aperçu de l’action, approbation, exécution et résultat. Le routage choisit une capacité adaptée ; il n’accorde pas l’autorité d’agir. Notre guide sur le Routage des capacités d’un agent IA Android : AutoAttach, Suggest et Fallback détaille cette sélection technique.

Pour une action à fort impact, l’aperçu doit être accessible sans dépendre du son. Un message demande l’affichage du destinataire et du contenu. Un appel demande le nom, le numéro ou le service choisi. Une modification système demande l’état actuel et l’état attendu. La correction doit permettre de revenir au texte traduit, de changer la cible ou d’annuler sans recommencer tout le parcours.

Les permissions restent elles aussi séparées de la compréhension linguistique. Une phrase correctement traduite n’autorise pas l’accès aux contacts, à la caméra ou aux messages. L’architecture présentée dans Identité des agents IA : permissions, approbation par outil et piste d’audit montre comment rattacher chaque action à une capacité, une autorité et un résultat vérifiables.

Enfin, la reprise doit préserver le travail déjà validé. Si la traduction, le réseau ou une permission échoue, l’agent peut conserver le brouillon, expliquer l’état en texte et proposer une entrée alternative. Une nouvelle tentative aveugle risquerait de répéter l’action ou de choisir une autre cible.

Évaluer FoneClaw au-delà de la commande vocale

Le périmètre actuel de FoneClaw ne revendique ni reconnaissance de la langue des signes ni intégration SL2T. Nous présentons cette frontière en premier parce qu’une entrée signée fiable constitue une capacité linguistique spécialisée. Les fonctions que nous livrons aujourd’hui commencent après cette étape : interaction textuelle, contexte sélectionné par l’utilisateur, choix de capacités Android, règles d’approbation, état visible des tâches, arrêt et récupération.

Notre expérience de construction de FoneClaw nous a appris qu’un agent de téléphone ne doit pas dépendre d’une seule modalité. L’utilisateur peut écrire sa demande, ajouter volontairement une pièce jointe ou partager le contexte de l’écran actuel lorsque cette fonction est disponible. L’assistant flottant peut prolonger un parcours depuis une autre application, tout en gardant l’attachement de l’écran sous le contrôle de l’utilisateur. L’article Assistant IA flottant Android : comprendre et agir depuis l’écran actuel explique ce parcours plus en détail.

Une entrée textuelle pourrait provenir d’un clavier, d’une transcription, d’une technologie d’assistance ou d’un autre service compatible. FoneClaw traite ensuite cette entrée comme une demande à interpréter. Le routage peut attacher un contexte pertinent, suggérer une capacité ou proposer une continuité lorsque la correspondance reste incertaine. Cette sélection ne déclenche pas l’action et ne remplace ni la permission Android ni la politique d’approbation de l’outil.

Nous séparons aussi l’autorité du modèle et celle des outils. Les capacités peuvent être activées ou désactivées, les règles d’approbation peuvent varier selon l’outil, et une tâche peut être arrêtée. Lorsqu’une permission manque, la récupération guide l’utilisateur vers l’étape nécessaire puis reprend le parcours visible. Ce modèle soutient déjà des usages au-delà de la voix, même si l’entrée en langue des signes reste en dehors de notre périmètre présent.

La prochaine exigence n’est pas simplement d’accepter davantage de formats. Nous voulons continuer à améliorer la lisibilité des aperçus, des erreurs, des états d’attente et des confirmations, afin que chaque parcours reste utilisable sans dépendre d’un signal sonore. Une véritable évaluation d’accessibilité exige toutefois des essais avec les personnes concernées et leurs technologies habituelles.

Auditer un agent mobile avec les personnes sourdes

Google DeepMind indique que des personnes sourdes ont participé à la conception, à la collecte des données, à l’évaluation et à l’étude des effets du système, avec l’appui d’un comité consultatif. Cette participation ne remplace pas tous les tests futurs, mais elle établit une méthode essentielle : les personnes concernées interviennent dans les décisions, pas seulement dans une démonstration finale.

Un audit utile commence par la couverture linguistique. Il précise la langue des signes, les variantes, les régions, les contextes et les profils représentés. La diversité doit inclure des vitesses et styles de signature différents, des personnes gauchères, la signature à une main, diverses morphologies, teintes de peau, tenues et conditions d’éclairage. Une seule personne ne peut pas représenter toute une communauté linguistique.

Le test physique compte autant que le modèle. Le téléphone peut-il cadrer les mains, le visage et le buste sans exiger une position pénible ? L’utilisateur voit-il simultanément le retour caméra et le texte ? Peut-il tenir l’appareil, signer et corriger le résultat ? Une caméra posée, un écran pliable ou un support peuvent modifier entièrement l’expérience.

• Vérifier la langue et les variantes réellement prises en charge.
• Tester le cadrage, la lumière, la latence et les mouvements rapides.
• Expliquer quelles représentations quittent l’appareil et quand la caméra s’arrête.
• Afficher les passages incertains sans interrompre toute la phrase.
• Permettre la correction du texte, de la cible et de l’action proposée.
• Fournir des confirmations visuelles et tactiles indépendantes du son.
• Conserver une solution de remplacement par texte, contacteurs ou autre entrée choisie.

Les mesures doivent suivre le parcours complet : qualité de traduction, temps nécessaire pour réparer une erreur, proportion de bonnes cibles, compréhension de l’aperçu, réussite de l’arrêt et récupération après une panne. Un excellent résultat linguistique peut encore produire une mauvaise expérience si l’action suivante reste ambiguë ou inaccessible.

Tester un parcours accessible et réversible

Avant de compter sur un agent mobile accessible, choisissez une tâche à faible risque, par exemple ouvrir une application ou créer un mémo sans l’envoyer. Utilisez l’entrée réellement prévue au quotidien : texte saisi, technologie d’assistance ou fonction de transcription compatible. Si une traduction depuis une langue des signes est disponible, vérifiez chaque mot important avant de poursuivre.

1. Confirmez que le texte affiché correspond à l’intention et corrigez toute ambiguïté.
2. Vérifiez que l’agent montre l’application, la cible et la capacité qu’il compte utiliser.
3. Refusez une permission pendant le premier essai afin d’observer le parcours de récupération.
4. Relancez la tâche, approuvez-la et contrôlez le résultat visible sur le téléphone.
5. Testez l’arrêt, puis recommencez avec la caméra ou le réseau indisponible pour valider la solution de remplacement.

Ce test ne prouve pas une fiabilité universelle. Il révèle toutefois si les étapes critiques restent compréhensibles dans votre configuration réelle. Pour une action plus engageante, comme un message ou un appel, gardez l’aperçu et la confirmation visuelle jusqu’à ce que le parcours ait été éprouvé avec les personnes qui l’utiliseront.

L’accessibilité au-delà de la voix devient concrète lorsque l’utilisateur peut choisir son entrée, comprendre l’interprétation, contrôler l’autorité donnée au téléphone et récupérer son travail après un échec. La traduction de l’ASL vers le texte constitue un jalon important ; l’agent mobile accessible se construit dans toutes les étapes qui suivent.