L'IA de langue des signes est là • Ce qu'elle devrait apprendre aux auditeurs en accessibilité

Le 12 août 2026, Google DeepMind a annoncé SL2T, un modèle de traduction de la langue des signes vers le texte, désormais intégré à Gboard et Live Transcribe sur Pixel 11, en commençant par la langue des signes américaine (ASL) vers l'anglais.

Le titre s'écrit tout seul : « l'IA sait maintenant traduire la langue des signes ». Et franchement, c'est la partie la moins intéressante de l'histoire.

Ce qui a retenu mon attention, c'est comment ils l'ont construit. Parce que c'est la méthode, pas le modèle, que notre secteur continue de massacrer.

À retenir

• Les langues des signes sont des langues naturelles à part entière, avec leur propre grammaire et leur propre lexique. Ce ne sont pas des langues orales exécutées avec les mains.
• SL2T est entraîné sur plus de 100 000 heures réparties sur plus de 50 langues des signes, et traduit directement à partir de points de repère corporels plutôt que de la vidéo brute.
• Google DeepMind l'a construit avec des experts sourds, des organisations de personnes sourdes et un comité consultatif dédié, puis a publié un rapport d'impact conjoint qui liste les limites.
• La leçon transposable pour les audits d'accessibilité : résultats automatisés plus jugement expert plus implication réelle des utilisateurs. Aucun des trois ne suffit seul.

Ce que fait réellement SL2T

Deux choses méritent d'être comprises avant de parler de pratique de l'accessibilité.

D'abord, il s'agit de traduction, pas de transcription. La reconnaissance vocale fait correspondre du son à des mots écrits, à l'intérieur de la même langue. La langue des signes ne fonctionne pas comme ça. L'ASL n'est pas de l'anglais sur les mains. Elle a sa propre grammaire, son propre lexique, et elle porte du sens par des mouvements simultanés des mains, des bras, du buste, de la tête et du visage, ainsi que par l'usage de l'espace lui-même.

Le modèle doit donc faire de la vraie traduction automatique et de la vision/détection fine par ordinateur sur tout le corps, en même temps. C'est aussi pour ça que les gants traducteurs de langue des signes, qui ressurgissent dans la presse tous les deux ou trois ans, étaient condamnés d'avance : ils captent les mains et passent à côté de tout le reste.

Ensuite, l'architecture est intéressante côté vie privée. Un modèle embarqué (MediaPipe Holistic) convertit le flux de la caméra en points de repère de posture, et seules ces coordonnées géométriques quittent l'appareil. La vidéo est jetée.

L'équipe a aussi écarté les « gloses », ces annotations intermédiaires au niveau du mot sur lesquelles s'appuie la plupart des travaux académiques, pour traduire directement des points de repère vers le texte. Les gloses aplatissent précisément ce qui fait l'expressivité des langues des signes, donc les abandonner supprime un plafond de vocabulaire artificiel.

Le résultat annoncé est un score zero-shot de 70 BLEURT sur le benchmark FLEURS-ASL. Si le score ne vous parle pas, retenez juste que c'est bien au-dessus de tout ce qui avait été publié jusqu'ici.

Pour moi, cela dit, le détail le plus parlant de toute l'annonce est enfoui dans une légende.

Google a publié les cas d'échec : dactylologie rapide mal interprétée (« prey » devenu « grey »), constructions avec classificateurs supprimées, temps verbal perdu faute de contexte. Un tableau de benchmark qui affiche ses propres erreurs, ce n'est pas un choix marketing. C'est un choix professionnel, selon moi. (Bon, il y a certainement un peu de marketing quand même.)

Les décisions d'ingénierie que personne n'aurait prises à partir d'un cahier des charges

Regardez la liste des problèmes sur lesquels l'équipe dit avoir travaillé au-delà du benchmark :

• la latence en streaming
• les hallucinations quand la caméra voit quelqu'un qui ne signe pas
• l'équité pour les 10 % environ de signeurs gauchers
• la signation à une seule main, parce que l'autre tient le téléphone
• les variations entre langues, dialectes et niveaux de maîtrise

Je pense sincèrement que cette liste est la chose la plus utile de tout l'article pour les gens qui auditent des interfaces.

Aucun de ces points ne sort d'une liste de conformité. Aucun n'apparaît dans un scan automatisé. Ils viennent de l'observation de vraies personnes utilisant l'outil dans de vraies conditions. « Signer à une main parce que l'autre tient le téléphone », ce n'est pas une intuition technique. C'est une intuition d'observation, et elle vaut de l'or.

Cette distinction, c'est exactement l'écart entre une interface qui passe (conformité) et une interface qui fonctionne (accessibilité).

Construire avec, pas pour

La partie sur laquelle je reviens sans cesse : les perspectives des personnes sourdes ont façonné chaque étape.

Le concept vient d'un Googler sourd. La collecte de données est passée par des partenaires sourds. L'évaluation est passée par des études auprès d'utilisateurs sourds. Et Google a mis en place un comité consultatif sur l'IA et la langue des signes réunissant des organisations de Sourds du monde entier, puis a cosigné un rapport d'impact conjoint documentant ce que la technologie peut et ne peut pas faire aujourd'hui.

Est-ce aussi de la bonne communication ? Bien sûr. La big tech ne publie pas un rapport d'impact par pur altruisme, et une bonne dose de scepticisme est toujours la bienvenue quand une plateforme sort des fonctionnalités d'accessibilité liées à un appareil vitrine.

Mais le schéma reste le bon, et je préfère le voir copié que balayé d'un revers de main.

Parce que le mode d'échec de notre secteur est tellement prévisible. Une équipe décide de ce dont les utilisateurs handicapés ont besoin, livre, ajoute une icône, et passe à autre chose. C'est exactement la logique derrière les overlays d'accessibilité et leurs promesses non tenues : une solution conçue à partir de suppositions sur le handicap plutôt qu'à partir du vécu des personnes handicapées, vendue comme un raccourci pour éviter le travail.

Impliquer les utilisateurs, c'est plus lent. C'est aussi la seule chose qui vous dise de façon fiable si vous avez construit la bonne chose.

Pourquoi cela compte pour les audits d'accessibilité

Voilà où ça atterrit pour celles et ceux qui font des audits pour vivre.

Une interface peut satisfaire tous les critères de succès applicables et rester pénible à utiliser. J'ai déjà écrit sur pourquoi les audits comptent plus que la conformité, et cette annonce en est une bonne illustration, prise par l'autre bout. Google aurait pu livrer un modèle qui cartonne sur FLEURS-ASL et qui frustre tous les signeurs gauchers dès le premier jour. Le benchmark ne l'aurait pas vu.

Nos benchmarks ont le même angle mort. Une cartographie systématique de la littérature sur les outils automatisés, les inspections expertes et les tests utilisateurs le dit clairement : ces trois méthodes font remonter des types différents de problèmes. Elles se recouvrent bien moins qu'on ne l'imagine. Le scan automatisé trouve une part. L'inspection experte trouve une part plus large et différente. Les utilisateurs trouvent des choses que ni l'une ni l'autre ne produira jamais.

Alors quand un éditeur vous dit que l'IA va s'occuper de votre audit, la réponse honnête est que l'IA s'occupe d'une portion de la détection, et que la détection n'a jamais été la partie difficile. Le jugement, si. Le contexte, si. Savoir si une alternative techniquement valide est réellement utilisable, si.

C'est la philosophie derrière la façon dojt j'ai construit CheckFox : automatiser les parties mécaniques, puis laisser à l'auditeur la place d'exercer son jugement, de documenter son raisonnement et de collaborer sur ce qui exige un humain. L'outil doit rendre l'expert plus rapide, pas prétendre le remplacer.

Deux points de vigilance pour les auditeurs

La langue des signes est un vrai sujet RGAA/WCAG, et elle est sous-testée. WCAG 2.1 et 2.2 comportent un critère AAA (1.2.6) qui exige une interprétation en langue des signes pour les contenus audio préenregistrés.

La plupart des organisations le zappent parce qu'il est AAA, et je comprends la réalité budgétaire. Mais il vaut la peine de se rappeler pourquoi il existe : pour beaucoup de personnes sourdes, la langue écrite est une langue secondaire, et les sous-titres n'en sont pas un équivalent complet. Si vous n'avez jamais questionné cette supposition dans un audit, ça vaut le coup d'y revenir, en parallèle de ce qui a changé avec WCAG 2.2.

Ne laissez pas les fonctionnalités d'IA devenir le nouveau raccourci vers la conformité. Les sous-titres automatiques n'ont jamais satisfait aux exigences WCAG pour les contenus préenregistrés, et une fonctionnalité d'IA en langue des signes sur le téléphone d'un utilisateur ne rend pas votre vidéo accessible non plus. La responsabilité reste celle du fournisseur de contenu. À mesure que les obligations européennes se resserrent avec l'European Accessibility Act, attendez-vous à voir sortir l'argument du « l'appareil de l'utilisateur sait gérer ». Ce n'en est pas un.

Rendre à César, et rester critique

Pour être clair sur le périmètre : SL2T, c'est un seul sens (des signes vers le texte), un seul couple de langues (ASL vers anglais), sur une seule famille d'appareils au lancement. La génération de texte vers langue des signes est sur la feuille de route, pas entre vos mains. La communauté sourde jugera la qualité réelle bien mieux que moi, et le rapport d'impact conjoint existe précisément parce que les limites sont réelles.

Mais la méthode tient la route. Comprendre les gens. Comprendre leur langue et leurs comportements. Les impliquer tout du long. Puis construire la technologie autour de cette réalité, et publier ce qu'elle rate encore.

C'est une exigence plus élevée que celle appliquée à la plupart des travaux d'accessibilité, y compris à pas mal de travaux d'accessibilité vendus par des entreprises d'accessibilité.

Et c'est une question légitime à emporter dans votre prochain audit : mesurez-vous la conformité, ou mesurez-vous si les gens arrivent réellement à faire ce qu'ils ont à faire ?

FAQ

Qu'est-ce que SL2T ?

SL2T (sign-language-to-text) est un modèle de traduction de Google DeepMind qui convertit la langue des signes en texte écrit. Il alimente la dictée en langue des signes dans Gboard et Live Transcribe, avec au lancement l'ASL vers l'anglais sur Pixel 11.

Est-ce qu'une IA de langue des signes rend mon site accessible ?

Non. C'est une fonctionnalité d'assistance sur l'appareil de l'utilisateur, pour la saisie et la conversation. Elle ne remplace ni les sous-titres, ni les transcriptions, ni l'interprétation en langue des signes de vos propres contenus, et elle ne transfère pas vos obligations légales à l'utilisateur.

La langue des signes est-elle exigée par WCAG ?

Le critère de succès 1.2.6 exige une interprétation en langue des signes pour les contenus audio préenregistrés, au niveau AAA. Les niveaux A et AA exigent plutôt des sous-titres et de l'audiodescription. Beaucoup d'organisations visent AA, mais les critères AAA restent pertinents quand votre audience compte un nombre significatif d'utilisateurs de la langue des signes.

L'IA peut-elle remplacer un audit d'accessibilité ?

Non. Les outils automatisés, les inspections expertes et les tests utilisateurs font remonter des catégories de problèmes différentes, et la recherche montre que le recouvrement est plus faible que ne le pensent la plupart des équipes. L'IA peut accélérer la détection et la restitution. Elle ne peut pas prendre les décisions contextuelles dont dépend un audit.

Sources :

• Google DeepMind, « Putting sign language AI into users' hands »
• Rapport d'impact conjoint AISLAC pour SL2T 1.0