Gouvernance des design systems accessibles à l’ère de l’IA - Anna E. Cook

TL;DR :

L’IA et l’accessibilité sont généralement considérées comme un problème d’outillage. Ce n’est pas le cas. C’est un problème de gouvernance — celui qui détermine si votre design system peut supporter l’IA.

Les design systems gouvernaient autrefois ce qui est construit et comment c’est construit. Ils doivent désormais gouverner ce que l’IA est autorisée à générer à partir de ce qui a été construit. Cet article propose un cadre pour penser ce changement : six questions qui déterminent si votre système peut héberger de l’IA sans amplifier ses problèmes :

1. Quels sont mes biais de conception ?
2. Qu’est-ce qui est protégé dans ce système ?
3. À qui appartiennent les sorties de l’IA ?
4. Quelle est l’expérience par défaut ?
5. Quels signaux les utilisateurs envoient-ils déjà ?
6. L’IA peut‑elle réellement résoudre ce problème ?

Ce texte accompagne l’article « AI Doesn’t Fix Accessible Systems. It Depends on Them » . J’ai aussi créé un workbook basé sur ce cadre pour évaluer votre propre système.

Si vous dirigez ou travaillez sur un design system, vous avez probablement eu cette conversation dans les douze derniers mois :

Une équipe produit veut lancer une fonctionnalité IA, et quelqu’un demande qui est responsable de l’accessibilité des sorties de l’IA. La réponse est souvent insatisfaisante — non pas parce que l’équipe ne s’en préoccupe pas, mais parce que la question révèle quelque chose que le système n’a pas été construit pour gérer. Quand un composant statique est cassé, on sait qui corrige. Quand une variante générée par l’IA est cassée, la chaîne de responsabilité s’estompe. Le composant appartient techniquement au design system, le modèle à l’équipe IA. La sortie n’appartient à personne.

Ce n’est pas un problème d’outillage. C’est un problème de gouvernance. Et c’est celui qui détermine si votre système peut porter l’IA.

Si vous vous demandez pourquoi une question sur l’IA devient une question de gouvernance, c’est le sujet de l’article compagnon — « AI Doesn’t Fix Accessible Systems. It Depends on Them ». Cet autre texte explique pourquoi l’accessibilité est la fondation dont l’IA dépend.

Celui‑ci explique comment construire et évaluer cette fondation.

Ce qui change à l’ère de l’IA, ce ne sont pas les composants. Ils doivent toujours être accessibles, documentés et livrés. Ce qui change, c’est l’étendue des décisions que le système doit gouverner. Le système gouvernait ce qui est construit. Maintenant il doit gouverner ce que l’IA est autorisée à générer à partir de ce qui a été construit.

C’est un problème différent, qui requiert un nouvel ensemble de questions. Le reste de ce texte propose six dimensions de gouvernance qui déterminent si votre design system peut héberger l’IA sans amplifier ses problèmes. Pour chacune : ce que la question implique vraiment, à quoi ressemble une bonne pratique, une mauvaise pratique, et les actions opérationnelles pour combler l’écart.

Questions à résoudre

La gouvernance, c’est comment nous protégeons l’utilisabilité et l’accès à grande échelle. Il ne s’agit pas de bureaucratie pour la forme, mais de règles délibérées qui empêchent la dérive.

Ces dernières années, j’ai beaucoup réfléchi à ces problèmes. Ce sont des questions difficiles, mais essentielles pour construire des systems accessibles et pratiques à l’ère de l’IA.

Je partage ici les six questions que j’utilise :

Question 1 : Quels sont nos biais de conception ?

Avant de définir quoi que ce soit, commencez par un examen de soi. La gouvernance requiert des règles intentionnelles, mais définir des règles exige d’examiner les hypothèses qui risquent d’y être intégrées.

Souvent, quand on qualifie quelque chose d’« intuitif », on veut dire que c’était intuitif pour des personnes comme nous. C’est l’hypothèse à interroger avant de concevoir.

Démanteler nos biais est encore plus important aujourd’hui. Quand l’IA fait partie du produit, les biais se propagent plus vite. Le modèle hérite des hypothèses non examinées et les reproduit sur chaque sortie.

Beaucoup de nos conceptions reposent sur l’idée de l’utilisateur « moyen ». Mais l’utilisateur moyen est une fiction. L’US Air Force l’a découvert en concevant des cockpits autour des mensurations du « pilote moyen » et a constaté que ces cockpits ne convenaient à personne.

Le même principe s’applique aux interfaces.

J’ai vu des designers se concentrer sur l’utilisateur « moyen » et le « happy path ». Mais connaissez‑vous vraiment quelqu’un qui corresponde parfaitement à vos personas ?

Même les designers bien intentionnés intègrent des biais en essayant de ne pas le faire. Par exemple, beaucoup d’entre nous supposent ce qui serait utile aux utilisateurs de lecteurs d’écran. On écrit alors des labels très verbeux, souvent redondants, parce qu’on ne comprend pas comment ces utilisateurs naviguent dans nos produits.

On ne peut pas supposer les besoins d’autrui quand on ne les partage pas, et même quand on les partage, ils peuvent se manifester différemment.

Le concept d’affordance reflète aussi un biais. Les affordances sont relationnelles, pas universelles. On dit qu’une tasse « permet » de boire, mais cela n’est vrai que pour certains corps, dans certains contextes. Qu’en est‑il d’une personne avec une prise faible ? D’un enfant ? D’une personne avec des sensibilités sensorielles ? Pour eux, la tasse n’offre pas forcément la possibilité de boire.

Que faire pour réduire les biais dans nos systèmes ?

Concevoir pour la variabilité des affordances. Anticiper plusieurs manières valides d’utiliser le même objet : ajouter une paille, une anse, un bouchon, ou repenser la tasse dès l’origine.

Ne pas supposer que l’utilisateur doit s’adapter à l’objet. Permettre à l’objet ou au système de s’adapter à l’utilisateur.

Les systèmes numériques sont identiques. Une zone de texte permet de taper, mais taper n’est pas la voie la plus facile pour tout le monde. On prend donc en charge la saisie vocale, l’autocomplétion, des labels clairs dans le code, des messages d’erreur utiles. Même objectif, plusieurs chemins valides.

Un moyen direct : suivre les WCAG et intégrer des personnes en situation de handicap ou neurodivergentes dans le processus — comme membres permanents de l’équipe ou collaborateurs rémunérés.

Les équipes système et produit voient un retour sur investissement immédiat en pratiquant le design inclusif et le co‑design. Et les biais intégrés au système diminuent.

Quand l’IA fait partie de la construction, les invariants protègent le système contre l’érosion probabiliste. Un modèle peut proposer mille variations de bouton. L’invariant garantit que chaque variation reste opérable, étiquetée et accessible. Sans ce plancher, le modèle ne personnalise pas — il dérive.

La conformité aux WCAG est essentielle, mais elle ne tient que si la structure sous‑jacente est protégée. On ne peut pas réussir un audit sur un système dont les fondations sont négociables. Quand la structure est stable, les systèmes peuvent s’adapter en sécurité. Variabilité sans contraintes = chaos. Variabilité avec garde‑fous = design adaptatif.

Question 2 : Qu’est‑ce qui est protégé dans notre système ?

Avant d’introduire de la variabilité — personnalisation, génération par IA, toute adaptation — définissez nos invariants. Ce sont les éléments qui ne peuvent pas changer, quelle que soit la flexibilité de la surface. Ce sont des garanties pour les personnes qui utilisent notre plateforme.

Imaginez une couche de personnalisation qui conclut « cet utilisateur semble préférer le tactile, l’opérabilité clavier n’est pas nécessaire ». Ce n’est pas de l’adaptation : c’est un invariant qui est écrasé silencieusement par une inférence. L’utilisateur vient de perdre une garantie dont il ignorait l’existence, sans moyen de la récupérer.

Ce sont les éléments dont dépendent les technologies d’assistance pour fonctionner. Ce sont aussi ce dont l’IA a besoin pour interpréter correctement la structure. Quand les invariants tiennent, le système peut se « plier » par-dessus sans danger — pour les utilisateurs voyants, les utilisateurs de lecteurs d’écran, et les modèles qui apprennent des schémas. Quand ils ne tiennent pas, aucune couche de personnalisation ne peut restaurer ce qui a été perdu dans les fondations.

Quelques éléments ne sont pas négociables, par exemple :

• Les paramètres par défaut à plus faible barrière (voir section suivante)
• Hiérarchie sémantique
• Opérabilité au clavier
• Étiquettes programmatiques (et ARIA seulement quand la sémantique HTML est insuffisante)
• Ordre du focus et de lecture

Certains éléments peuvent varier :

• Densité de mise en page (ex. : compacte, confortable)
• Thèmes de couleur (ex. : clair, sombre, contraste élevé)
• Ton du contenu (ex. : bref, détaillé)
• Visuels (ex. : afficher/masquer les visuels, mode niveaux de gris)

Quand l’IA fait partie du produit, ce sont les invariants qui protègent le système de l’érosion probabiliste. Un modèle peut proposer mille variations de bouton : l’invariant garantit que chaque variation reste opérable, étiquetée et atteignable. Sans ce plancher, le modèle ne personnalise pas — il dérive.

La conformité aux WCAG est essentielle, mais elle ne tient que si la structure sous‑jacente est protégée. On ne peut pas réussir un audit sur un système dont les fondations sont négociables. Quand la structure est stable, les systèmes peuvent s’adapter en sécurité. Variabilité sans contraintes = chaos. Variabilité avec garde‑fous = design adaptatif.

Question 3 : À qui appartiennent les sorties de l’IA ?

Une fois les invariants définis, la question suivante est qui est responsable de les faire respecter — pas en théorie, mais le jour où un modèle livre une variante cassée un vendredi à 16 h.

Quand un composant statique tombe en panne, la chaîne de responsabilité est claire : un designer ou ingénieur possède le composant, une équipe design system possède le pattern, et le processus de release attrape la régression. Quand une variante générée par l’IA échoue, la chaîne s’effiloche. Le composant appartient techniquement à l’équipe design system. Le modèle appartient techniquement à l’équipe IA. La sortie n’appartient techniquement à personne.

Cette ambiguïté est la défaillance.

La propriété ne peut pas être héritée de surfaces adjacentes ; elle doit être assignée. Sans propriétaire, la sortie de l’IA opère hors gouvernance — même quand le reste du système est bien gouverné. Le modèle devient une quatrième équipe qui publie dans votre produit sans manager.

Imaginez une équipe design system qui a passé deux ans à rendre ses composants conformes à WCAG 2.2 AA, avec documentation et cadres pour assurer une bonne utilisation par les consommateurs du système. Puis, une fonctionnalité IA génère un nouveau pattern de mise en page, le publie, et casse silencieusement les labels programmatiques sur tout le tableau de bord. L’équipe produit publie, et six mois plus tard, un auditeur découvre les bugs d’accessibilité.

L’information finit peut‑être par revenir à l’équipe design system. Celle‑ci ouvre un ticket. L’équipe IA répond que le modèle produit des patterns dans les paramètres fournis. L’équipe design system révise les paramètres. Le modèle produit d’autres patterns qui respectent ces paramètres mais introduisent une régression d’accessibilité différente. Répéter. Des mois passent. Personne n’a tort. Rien ne s’améliore.

Cette boucle ne se brise que lorsque quelqu’un a une autorité explicite sur les sorties IA — y compris l’autorité de les bloquer avant livraison.

Ce que la propriété des sorties IA exige réellement :

• Un propriétaire nommé (ou des propriétaires), par rôle, pour les artefacts générés par l’IA. Pas le modèle. Une personne.
• Un périmètre d’autorité clair : que peut bloquer le propriétaire, que peut‑il réviser, que doit‑il escalader ?
• Une relation définie entre la propriété des sorties IA et les équipes existantes (design system, accessibilité, IA/ML). Qui consulte qui, et sur quoi ?
• Un chemin pour que les sorties IA entrent dans les mêmes processus de revue et de correction que les artefacts humains, y compris la capacité d’empêcher la release quand l’accessibilité échoue.
• Un enregistrement documenté de ce que l’IA a généré, quand, et des changements effectués en réponse aux problèmes. La même trace d’audit qu’on attendrait pour un travail humain.

Quand on demande « qui possède la sortie de l’IA », on demande en réalité si quelqu’un a le pouvoir de dire non. Si personne ne l’a, le modèle a plus de droits décisionnels que les personnes responsables du produit.

Question 4 : Quelle est l’expérience par défaut ?

Une fois nos invariants clairs, définissons l’expérience par défaut. Un défaut est une base — l’expérience avec le plus faible niveau de barrières possible, accessible à tous sans configuration ni personnalisation.

Chaque système a des paramètres par défaut. La question est de savoir si le chemin accessible est le défaut, ou s’il s’agit d’un réglage que l’utilisateur doit connaître pour l’activer. Le défaut est ce que reçoit tout utilisateur avant toute personnalisation, inférence IA ou demande d’accommodement — et c’est l’expérience sur laquelle on doit pouvoir compter sans médiation par l’IA.

La décision de GitHub d’identifier les liens par un soulignement par défaut en est un exemple simple : cela garantit que les liens sont distincts pour les utilisateurs qui s’appuient sur des indices visuels au‑delà de la couleur. Puis ils ont rendu ce choix personnalisable. Mais l’état à plus faible barrière vient d’abord.

Comparez cela au défaut de la plupart des CAPTCHA : le chemin « le plus simple » est visuel. L’alternative clavier ou audio est plus difficile, plus lente, et souvent cassée. Le chemin accessible existe, mais ce n’est pas le défaut. C’est un système où l’accessibilité est une option, pas une fondation.

Même si l’IA personnalise notre système, il doit toujours exister une base prévisible : un état de référence testable, une expérience partagée qui fonctionne sans médiation IA. L’accessibilité garantit que le système fonctionne avant d’ajouter l’IA.

Si l’IA devine qu’un utilisateur « préfère une interface minimaliste » et supprime les soulignements de lien, elle réintroduit une barrière. Le défaut doit pouvoir annuler ce que l’IA devine.

Que se passe‑t‑il si l’IA suppose qu’une personne qui préfère une UI minimale n’a pas besoin d’un contraste élevé ? Ou si elle modifie sans consentement l’espacement et la mise en page ? Que fait l’utilisateur quand le modèle devine ses besoins, change sans demander et masque les réglages ?

Même quand l’IA agit ainsi, le défaut et les réglages contrôlables par l’utilisateur offrent un chemin de retour. Le modèle peut deviner. Les utilisateurs doivent pouvoir inverser. Le système doit soutenir les deux.

Les utilisateurs doivent pouvoir accéder à notre plateforme sans médiation IA, sans divulgation de données personnelles, et sans ajustement probabiliste. L’accessibilité garantit que le système fonctionne que l’IA soit présente ou non.

Question 5 : Que signalent déjà les utilisateurs ?

Une fois la base stable, les premiers signaux à interpréter sont ceux que les utilisateurs nous ont déjà donnés — explicitement, au niveau de l’OS ou du navigateur, sans qu’on ait à demander.

Imaginez une application de productivité alimentée par l’IA qui détecte qu’un utilisateur a bougé sa souris doucement pendant deux minutes et décide que son réglage prefers‑reduced‑motion était « probablement accidentel ». Elle réactive les animations en parallaxe que l’utilisateur avait désactivées au niveau de l’OS — animations qui provoquent chez lui des nausées vestibulaires. Le modèle n’a pas demandé. Il a inféré. L’utilisateur doit désactiver les animations encore et encore à chaque session.

L’inférence IA est conçue pour trouver des patterns dans le comportement. Il est tentant de laisser le modèle « apprendre » qu’un utilisateur « n’a pas vraiment besoin » de reduced motion parce qu’il ne la désactive pas manuellement pendant une session. Mais le réglage au niveau OS est le commutateur. L’utilisateur a appuyé sur le bouton. Le modèle n’a pas le droit de le remettre en question.

Ce sont des préférences déclarées par l’utilisateur. Elles sont l’indication la plus directe de ce dont quelqu’un a besoin — sans entretiens ni inférence. Il suffit de respecter ces signaux.

Interrogez‑vous : notre plateforme respecte‑t‑elle des signaux comme :

• prefers‑reduced‑motion
• modes de couleur
• réglages haut contraste
• mise à l’échelle des polices
• préférences de langue
• préférences de cookies et de partage des données

Rappel : l’IA ne doit jamais outrepasser un choix explicite de l’utilisateur. Elle ne doit jamais contredire des réglages d’accessibilité au niveau du système.

La différence entre adaptation et supposition, c’est le consentement. Une personnalisation basée sur des signaux donnés par l’utilisateur est du design adaptatif. Une personnalisation basée sur une inférence non autorisée par l’utilisateur n’est qu’une imposition bien présentée.

Question 6 : L’IA peut‑elle réellement résoudre ce problème ?

Après avoir examiné nos biais, protégé nos invariants, défini un défaut stable et promis de respecter les signaux réels — posez la question plus difficile :

L’IA résout‑elle réellement un problème ici ? Ou concevons‑nous un problème pour justifier la solution que nous avons déjà construite ?

Évitons‑nous le travail structurel lent ? La gouvernance n’est pas spectaculaire. Le refactoring n’est pas toujours excitant. Nettoyer la sémantique ne fait pas la une. Pourtant, c’est le travail. L’IA ne le remplace pas. Elle apprend à partir de la structure qu’on lui donne. Elle ne corrige pas cette structure.

Il y a aussi une question de consentement. Si l’IA est intégrée aux workflows de base, les utilisateurs peuvent‑ils vraiment se désengager ? Ou le fait d’opter‑out dégrade‑t‑il l’expérience au point de supprimer le choix réel ? Certains utilisateurs veulent le contrôle total. D’autres aucun IA. L’accessibilité est fondamentalement une question d’agence — et l’imposition, même bien conçue, n’en est pas.

Nous devons aussi reconnaître que l’IA ajoute des coûts : financiers, opérationnels et environnementaux. Mal utilisée, elle introduit des risques — biais, sécurité, fiabilité. Elle a des limites documentées dans son état actuel. La pression pour l’intégrer partout ne doit pas primer sur la question de sa pertinence.

Les décisions technologiques ne sont pas neutres. Elles déterminent qui bénéficie, qui porte les risques et qui est exclu. Je ne dis pas d’utiliser ou non l’IA. Mais je vous encourage à choisir délibérément.

Décidez de manière responsable si l’IA a sa place dans le système — et si oui, comment l’intégrer. Si vous l’utilisez, faites‑le avec des contraintes claires, une structure protégée et une gouvernance explicite.

L’IA amplifie la structure qu’on lui donne. Y compris nos échecs.