Votre chatbot IA relève de l’EAA, et sa mention au titre de l’article 50 doit passer par plus d’un canal sensoriel

Si vous ajoutez un chatbot IA à un service en ligne dans l’Union, vous n’avez pas pris une obligation, mais deux, issues de deux textes différents. Et dans la plupart des implémentations, elles échouent au même endroit : le petit badge qui indique que vous parlez à une IA.

Trois erreurs reviennent systématiquement :

• La mention IA n’est rendue que visuellement, parfois en aria-hidden, parfois dans une icône sans équivalent textuel.
• La mention vit dans le placeholder du champ de saisie, disparaît donc au focus et est restituée de façon inconstante par les lecteurs d’écran.
• Il existe un renvoi vers un humain, accessible à la souris et inaccessible au clavier.

Chacun de ces points est en soi un problème d’article 50 du règlement IA. Au titre de l’European Accessibility Act, chacun est en plus un défaut d’accessibilité sur un service soumis depuis le 28 juin 2025.

L’essentiel, ce qu’il faut faire aujourd’hui (60 minutes)

1. Ouvrez le widget et appuyez sur Tab depuis le corps de la page. Si vous n’atteignez pas au clavier le lanceur, la mention et le renvoi vers un humain, arrêtez-vous là.
2. Éteignez l’écran et utilisez un lecteur d’écran. Une mention jamais annoncée n’existe pas pour cette personne.
3. Sortez la mention du placeholder et de toute icône seule, vers un texte permanent dans le nom accessible ou dans le fil de conversation.
4. Vérifiez que la mention se copie. Ce qui n’atteint pas le presse-papiers n’est pas dans un format texte permettant de générer un format auxiliaire.
5. Consignez quelles obligations de l’annexe I vous venez de satisfaire, avec la date. La preuve est la documentation, pas le correctif.

Le widget est une application en ligne connexe, le point c) s’applique déjà

Avant même qu’il soit question de services d’assistance, l’annexe I, section III, point c) couvre le cas :

rendre les sites internet, y compris les applications en ligne connexes, et les services intégrés sur appareils mobiles, y compris les applications mobiles, accessibles d’une manière cohérente et appropriée en les rendant perceptibles, utilisables, compréhensibles et robustes;

Un widget de conversation intégré à votre service est une application en ligne connexe. Qu’un prestataire le fournisse, qu’il s’affiche dans une iframe ou qu’il se charge depuis l’infrastructure d’un tiers n’y change rien. S’il fait partie du service que vous proposez, perceptible, utilisable, compréhensible et robuste s’applique.

Exemple concret : une boutique intègre un chatbot hébergé dont le lanceur est un div doté d’un gestionnaire de clic, sans role, sans tabindex, sans nom accessible. Les personnes voyantes à la souris voient une bulle utile. Au clavier et au lecteur d’écran, il n’y a rien. Le service n’est pas utilisable, et le fait qu’un tiers ait construit le widget ne déplace pas l’obligation hors du prestataire de services.

S’il répond aux questions de support, le point d) s’applique aussi

Le point d) nomme la catégorie explicitement :

le cas échéant, veiller à ce que les services d’assistance (services d’aide, centres d’appel, assistance technique, services de relais et services de formation) fournissent des informations sur l’accessibilité du service et sur sa compatibilité avec les technologies d’assistance, via des modes de communication accessibles.

Relisez l’énumération. Services d’aide. Centres d’appel. Assistance technique. Services de relais. Un chatbot IA qui a remplacé votre support de premier niveau est un service d’aide qui se trouve être automatisé. L’automatisation ne le sort pas de la liste, et la directive ne prévoit aucune exception pour un support rendu par un logiciel plutôt que par une personne.

Notez ce que le point d) oblige réellement, car c’est plus étroit qu’on ne le suppose : le service d’assistance doit fournir des informations sur l’accessibilité du service et sur sa compatibilité avec les technologies d’assistance, via des modes de communication accessibles. C’est un devoir précis sur un sujet précis. Ce n’est pas une règle générale imposant que tout ce que dit le bot respecte une norme.

La règle générale, c’est le point c) ci-dessus. Il vous faut les deux, et ils ne font pas le même travail.

La mention article 50 est une information sur le fonctionnement du service

C’est ici que les deux textes se rencontrent sur un seul élément.

L’article 50, paragraphe 1, du règlement (UE) 2024/1689 exige que les personnes soient informées qu’elles interagissent avec un système d’IA. Il s’applique depuis le 2 août 2026. Les lignes directrices de la Commission sur l’article 50, du 20 juillet 2026, précisent ce que la mention doit véhiculer, notamment la nature artificielle de l’interlocuteur et l’identité du responsable.

Placez cela à côté de l’annexe I, section III, point b), qui régit l’information sur le fonctionnement du service :

en mettant à disposition les informations au moyen de plusieurs canaux sensoriels;

et :

en mettant à disposition le contenu informatif dans des formats texte permettant de générer d’autres formats auxiliaires pouvant être présentés de différentes manières par les utilisateurs et par l’intermédiaire de plusieurs canaux sensoriels;

Une mention IA est une information sur le fonctionnement du service. Elle dit à la personne à quoi elle a affaire et ce que valent les réponses. Donc, au titre du i), elle doit passer par plusieurs canaux sensoriels, et au titre du iv) exister dans un format texte convertible en formats auxiliaires.

C’est le test précis auquel un badge visuel échoue. Pas au sens de « ce serait mieux s’il était accessible ». Il atteint exactement un canal sensoriel, et s’il est enfermé dans une icône, un sprite ou un canvas, il n’est convertible en rien.

Exemple concret : une équipe livre une pastille grise portant « IA » à côté du nom de l’assistant, stylée en CSS et marquée aria-hidden="true" pour ne pas encombrer la sortie du lecteur d’écran. Cette décision passe la revue de design et enfreint les deux obligations d’un coup. L’article 50 n’est pas satisfait, car une personne aveugle n’apprend jamais qu’une machine répond. Le point b) i) n’est pas satisfait, car l’information n’existe que sur un canal.

Le correctif est banal et prend dix minutes : placez la mention dans le nom accessible de l’assistant et comme véritable message texte dans le fil, pour qu’elle soit lue, copiée et traduite comme n’importe quel autre texte.

Les services de relais, la ligne que presque personne ne lit

Le point d) nomme explicitement les services de relais parmi les services d’assistance. Les services de relais sont la façon dont beaucoup de personnes sourdes et malentendantes atteignent un support : un intermédiaire, humain ou automatisé, se place entre la personne et votre canal.

Si votre unique voie de support est un widget IA qu’un opérateur de relais ne peut pas parcourir, vous n’avez pas seulement construit une expérience malcommode. Vous avez fermé le canal dont la directive présuppose l’existence.

C’est aussi l’endroit où la réponse « mais nous avons un renvoi vers un humain » s’effondre le plus souvent. Un renvoi qui exige de cliquer une icône non étiquetée, ou qui ouvre une fenêtre modale piégeant le focus, n’en est pas un pour les personnes les plus susceptibles d’en avoir besoin.

Ce que « modes de communication accessibles » veut dire concrètement

La directive ne vous fournit pas de liste de contrôle, et aucune norme harmonisée n’est citée au Journal officiel au titre de l’EAA : il n’existe donc aucune présomption de conformité sur laquelle s’appuyer. Nous l’avons détaillé dans EN 301 549 ne vous rend pas conforme à l’EAA.

Ce que le texte donne, en revanche, est opérationnel, à condition de le lire comme des exigences et non comme des intentions :

Exemple concret : un bot répond à « votre tunnel de paiement est-il utilisable au lecteur d’écran ? » par un repli générique et sans escalade. C’est un manquement au point d) à l’état pur, car le seul sujet que le point d) nomme explicitement est précisément celui que le service d’assistance ne sait pas traiter.

La surveillance, sans fard

Personne ne vous infligera d’amende la semaine prochaine pour un badge de conversation inaccessible, et méfiez-vous de qui prétend le contraire.

En Allemagne, au titre du BFSG, l’autorité de surveillance du marché est la Marktüberwachungsstelle der Länder für Barrierefreiheit von Produkten und Dienstleistungen. Son mode opératoire est déclenché par les signalements, et les consommateurs comme les organismes qualifiés peuvent saisir. La séquence réaliste est un signalement, une demande d’informations, un délai pour remédier, puis une escalade seulement si vous l’ignorez.

Le modèle de risque honnête n’est donc pas la sanction surprise. C’est qu’un signalement arrive, qu’on vous demande quelle évaluation vous avez menée, et que vous n’ayez rien de daté à produire. L’EAA est autant un régime de documentation qu’une exigence de conception, exactement comme le piège de la charge disproportionnée que nous avons traité dans La charge disproportionnée n’est pas une porte de sortie.

Pièges fréquents, et comment les éviter

• Supposer que l’obligation appartient au fournisseur. Qui intègre, propose. Le remède est contractuel : exiger la conformité du fournisseur ou remplacer le widget. Ce n’est pas une clause de non-responsabilité dans votre déclaration d’accessibilité.
• Traiter l’article 50 comme un sujet de page juridique. C’est de l’UX produit. Une mention que personne ne perçoit n’a pas été faite.
• Utiliser la mauvaise déclaration. La déclaration de l’annexe V pour les prestataires privés n’est pas celle du secteur public, et elle doit aussi être disponible oralement. Voir la déclaration d’accessibilité que vous copiez est la mauvaise.
• Compter sur le statut de microentreprise. L’exonération vise les microentreprises fournissant des services, sur un test d’effectif et de chiffre d’affaires actualisé, et ce n’est pas une période transitoire. Voir le test des microentreprises.
• Corriger sans rien consigner. Une correction non documentée est indiscernable de la chance quand on vous demande ce que vous avez évalué, et quand.

L’EAA s’applique-t-il aux chatbots ?

Pas en tant que catégorie nommée. Il s’applique au service dont le chatbot fait partie. Un widget de conversation sur un service couvert est une application en ligne connexe au sens de l’annexe I, section III, point c), et s’il fonctionne comme un service d’aide, aussi un service d’assistance au sens du point d).

Une mention IA doit-elle être accessible ?

La mention est une information sur le fonctionnement du service, donc l’annexe I, section III, point b) s’applique : plusieurs canaux sensoriels, présentation compréhensible, et format texte permettant de générer d’autres formats auxiliaires. Un badge purement visuel n’y répond pas.

Un badge « Powered by AI » suffit-il pour l’article 50 ?

L’article 50, paragraphe 1, exige que la personne soit informée qu’elle interagit avec un système d’IA. Les lignes directrices de la Commission du 20 juillet 2026 traitent de la nature artificielle et de l’identité du responsable. Un badge décoratif, masqué aux technologies d’assistance, ou ambigu sur le responsable, n’y satisfait pas.

Puis-je m’appuyer sur la déclaration de conformité de mon fournisseur de chatbot ?

Non. L’obligation pèse sur le prestataire qui propose le service dans l’Union. Une assurance du fournisseur est un élément de preuve utile et un levier contractuel, pas un transfert d’obligation.

Et le renvoi vers un humain ?

Le point d) nomme les services de relais parmi les services d’assistance. Une voie de renvoi qui n’est pas atteignable au clavier, qui n’est pas annoncée, ou qui piège le focus, n’en est pas une pour celles et ceux qui en ont le plus besoin.

Les obligations sous-jacentes

Chacune de ces pages porte le texte de l’obligation, qui elle lie, et à partir de quand. Elles sont générées depuis un corpus daté, non rédigées à la main.

• Exigences en matière d’accessibilité
• Article 13, obligations des prestataires de services
• Article 2, champ d’application
• Les 256 obligations de la directive (UE) 2019/882
• Article 50 : obligations de transparence

Textes officiels

• Directive (UE) 2019/882, JO L 151 du 7.6.2019 : EUR-Lex HTML · ELI
• Règlement (UE) 2024/1689, article 50 : EUR-Lex HTML
• Barrierefreiheitsstärkungsgesetz (BFSG) : gesetze-im-internet.de
• Marktüberwachungsstelle der Länder (MLBF) : mlbf-barrierefrei.de

Avertissement

Les documents Legalithm sont une orientation opérationnelle et ne constituent pas un conseil juridique. Les textes authentiques sont ceux publiés au Journal officiel de l’Union européenne et prévalent sur cette présentation dans tous les cas.