♿ A11Y Lutèce #6 chez Upfast : l'accessibilité comme process, pas comme backlog

le 16 septembre 2026

Le sixième meetup A11Y Lutèce s'est tenu le mercredi 16 septembre 2026 dans les locaux d'Upfast, 7 rue Blondel à Paris. Un an après le lancement du groupe par Jean-Pierre Gay et Sébastien Bénard, le rendez-vous est devenu bimestriel : six éditions, une salle qui se remplit, et un format simple — une heure et demie de talks, puis un temps d'échange autour d'un verre.

L'accueil ouvre à 18h40, les talks à 19h10. La page Meetup le dit sans détour : il y a un ascenseur, mais pas d'accès PMR ni de toilettes accessibles. Pour un meetup d'accessibilité, c'est une information à traiter comme une donnée d'entrée, pas comme une note de bas de page.

Upfast, cabinet de staffing de freelances IT, accueille l'édition. L'hôte le formule sans jargon marketing : depuis l'European Accessibility Act, l'accessibilité n'est plus un item qu'on pousse en fin de backlog « quand on aura le temps ». Elle est devenue une obligation, donc une compétence qu'on recrute. TF1, BNP, Sanofi, Accor : les clients cités dans la salle sont aussi, pour partie, dans le public.

Trois talks, trois échelles. Nicolas Barcacci raconte comment une équipe mobile a fait entrer le lecteur d'écran dans le process de l'application All Accor. Bertrand Keller élargit au rôle légal du référent et aux indicateurs de maturité chez Sopra Steria. Guillaume Barbier redescend au HTML : un tableau « en strates » peut être sémantiquement correct et malgré tout inutilisable au lecteur d'écran.

Le fil commun n'est pas « il faut faire de l'accessibilité ». C'est plus dur : spécifier ne suffit pas. Un process, un schéma, un attribut headers sont des intentions. L'exécution — sprint, gouvernance, runtime du lecteur d'écran — décide si l'intention arrive jusqu'à la personne qui en a besoin.

Mise en place de l'accessibilité au sein de l'application All Accor

• Speakers : Nicolas Barcacci (LinkedIn)
• Type : Retour d'expérience
• Langue : French
• Créneau : 16/09/2026 · Upfast, Paris

Un talk d'ingénierie mobile, pas une déclaration d'accessibilité. Nicolas Barcacci, développeur Android senior chez Accor, raconte comment l'équipe de l'application All Accor est passée d'une dette constatée en rétro à un process où le lecteur d'écran a une place dans le design, dans les critères d'acceptance, et dans le sprint.

Mise en place de l'accessibilité au sein de l'application All Accor

L'application All Accor est un produit grand public : fiches hôtels, notations, programme de fidélité. Pour une personne qui utilise VoiceOver ou TalkBack, chaque écran est une séquence de focus, pas une composition visuelle. Le talk part de ce décalage, et de la façon dont une équipe mobile a essayé de le rendre visible pour tout le monde — designers compris.

Ce que présente le talk

Le point de départ n'est pas un audit RGAA parachuté. C'est une rétro : trop de problèmes d'accessibilité sur l'application, personne n'avait de méthode. L'équipe commence par un atelier hebdomadaire d'une heure. On monte en compétence, on cherche, on corrige. Puis on se rend compte que corriger écran par écran ne tient pas. Il faut représenter le comportement attendu du lecteur d'écran d'une manière que les voyants puissent annoter.

De là viennent trois mouvements, présentés dans cet ordre : une convention visuelle pour annoter les maquettes, un changement de process pour arrêter de produire de la dette, puis une série de cas concrets — images, regroupement, titres d'écran, contenu backend.

Points techniques importants

Annoter le lecteur d'écran, pas seulement l'écran

L'équipe prend des captures et les annote. Le code couleur présenté en séance n'est pas un design system public ; c'est un langage interne pour dire ce que le runtime d'accessibilité doit faire :

• bleu : structure de navigation rapide — titres / landmarks, le « sommaire » qui permet de sauter un bloc et de parcourir l'écran autrement que nœud par nœud ;
• vert : éléments moins structurants qu'un titre, mais qui doivent être lus dans un seul bloc ;
• gris : comportement prévu pour les personnes voyantes, qu'on ne rejoue pas tel quel pour les personnes non voyantes.

L'intérêt n'est pas cosmétique. Tant que le lecteur d'écran reste une API invisible, le design ne peut pas le reviewer. Une annotation transforme une intention d'accessibilité en artefact de conception, au même titre qu'un flow ou qu'un état de chargement.

Changer le process avant d'épuiser le backlog

Corriger la dette à côté du delivery, une heure par semaine, a une limite évidente : on passe son temps à réparer ce que le process continue de produire. L'équipe bascule donc l'accessibilité dans les critères d'acceptance. Une user story n'est plus « terminée » tant que les maquettes n'ont pas été affectées, accessibilité comprise.

S'ajoutent des points de contact identifiés :

• des référents accessibilité côté iOS et côté Android, dans l'équipe tech, pas dans une cellule distante ;
• une exigence d'expérience iso entre sous-applications et entre iOS et Android ;
• de la capacité de sprint dédiée aux sujets transverses — pas seulement le ticket du moment.

Le référent ici n'est pas le référent légal du schéma pluriannuel (sujet du talk suivant). C'est un rôle d'équipe : on sait à qui poser la question, on ne disperse pas la connaissance dans trois Slack et un wiki mort.

Images : décoratif ou porteur de sens

Cas simple, et déjà largement cassé en production. Beaucoup d'images d'interface sont décoratives. Les laisser dans l'arbre d'accessibilité pollue une lecture déjà longue. On les ignore.

Certaines images portent l'information. L'exemple de la salle est la notation hôtelière : un « 5 » à côté d'étoiles graphiques. Avant correction, le lecteur d'écran annonçait à peu près « hôtel 5 » — le chiffre, pas l'unité. Les personnes voyantes voient cinq étoiles. Les autres n'ont pas la même information. La correction est universelle, tous langages : une description (content description / accessibility label) pour que le focus dise « hôtel 5 étoiles ».

Regrouper les nœuds, sans avaler l'écran

Un lecteur d'écran mobile avance nœud par nœud, swipe à droite, swipe à gauche. Sans travail, une fiche hôtel est un tas de briques : nom, ville, type, « 5 », image d'étoiles, note. L'exemple donné en séance ressemble à une fiche Sofitel : chaque geste pour avancer d'un atome. Les personnes qui accélèrent la synthèse vocale perdent encore plus de temps sur ces micro-blocs.

La réponse est de regrouper ce qui va ensemble. « Hôtel » + « 5 » + « étoiles » fait sens comme un seul énoncé. Tout l'écran dans un seul bloc ne fait pas sens : si je veux savoir si l'hôtel est dans le programme ALL — Accor Live Limitless — je ne dois pas attendre la fin d'une description-fleuve.

Sur Android, la propriété montrée est le regroupement de descendants — mergeDescendants dans Compose, l'idée étant la même en Vue classique : un groupe, un focus, un libellé. Le point d'ingénierie n'est pas l'API. C'est le jugement : quoi grouper, quoi ne pas grouper.

Titre d'écran, chargement, backend

Trois autres dettes, plus structurelles :

• Beaucoup d'écrans n'ont pas de titre. Une personne voyante scanne. Une personne au lecteur d'écran parcourt. Un titre d'écran résume la page et s'active pour la technologie d'assistance, même s'il n'est pas « vendu » visuellement.
• Un chargement doit s'annoncer. Sinon l'interface est simplement muette pendant que l'application travaille.
• Tant que le texte est produit côté app, l'équipe peut le soigner. Dès que le contenu vient du backend — CMS, libellés métier, textes non maîtrisés — le front ne peut plus réparer. Nicolas pose le sujet ouvertement : il faut que le backend fournisse les textes accessibles, pas seulement les chaînes voyantes.

La démo en séance sert à montrer le résultat dans l'application, pas à dérouler un catalogue d'API.

Ce qu'il faut retenir

L'accessibilité mobile n'est pas une passe de labels en fin de ticket. Chez All Accor, elle commence par rendre le lecteur d'écran visible dans le design, puis par le faire entrer dans la Definition of Done. Les corrections locales — étoiles, regroupement, titres — ne tiennent que si le process arrête de recréer la dette, et si le backend arrête d'envoyer du contenu que le front ne peut pas rendre accessible.

Réflexions Darkwood

On reconnaît ici un problème d'orchestration plus que de widgets. L'équipe avait des gens, une heure par semaine, et une liste de bugs. Ce n'était pas un workflow : pas de critère d'entrée, pas de DoD, pas de points de contact, pas de capacité réservée. Dès que l'accessibilité devient une étape nommée du delivery — au même titre que le dark mode ou le big font dans le fil de conception — elle cesse d'être un héros du vendredi soir.

Le regroupement des nœuds est la même leçon, à l'échelle du runtime : trop de granularité, et l'utilisateur paie chaque geste ; trop d'agrégation, et l'information utile est enterrée. C'est un problème de frontière de step, pas de « plus d'ARIA ». Les agents IA qui génèrent des écrans sans ce jugement reproduiront la fiche hôtel atomisée, en plus vite. Si l'accessibilité n'est pas dans le rituel de conception — maquette annotée, critère d'acceptance, skill de prompt — elle disparaîtra du code généré exactement comme elle disparaissait du backlog.

Page de l'événement

REX stratégie accessibilité Sopra Steria, construire des indicateurs de pilotage

• Speakers : Bertrand Keller (site · LinkedIn)
• Type : Retour d'expérience / stratégie
• Langue : French
• Créneau : 16/09/2026 · Upfast, Paris

Bertrand Keller a changé le titre en séance. Moins le slogan du Meetup, plus la question réelle : obligation d'évaluer, capacité à progresser, stratégie. Le talk ne promet pas un kit d'audit. Il décrit ce que la loi demande à un référent, pourquoi un seul référent n'y arrive pas, et pourquoi moyenne des scores RGAA n'est pas un indicateur de maturité.

Obligation d'évaluer : le référent, le schéma, et ce que les scores RGAA ne mesurent pas

Bertrand Keller fait beaucoup de DevFest. Il le dit d'entrée : l'accessibilité y finit souvent en petite salle. Ici, la salle est déjà convertie. Il peut donc parler gouvernance sans passer vingt minutes à justifier l'existence du sujet.

Ce que présente le talk

Deux concepts, tenus jusqu'au bout. Faut-il prévoir avant d'agir ? Pas toujours — mais pour un référent, la loi répond plutôt oui. Et un référent d'accessibilité, concrètement, c'est quoi ?

Le poste est dans la loi. L'accessibilité numérique est l'une des rares disciplines rendues obligatoires : services publics, et entreprises au-delà du seuil de chiffre d'affaires prévu pour les obligations de service au public (Bertrand cite 250 millions d'euros). L'European Accessibility Act ajoute un autre régime ; le talk n'entre pas dans le détail des textes. Le cœur opérationnel, lui, est clair :

1. un schéma pluriannuel (gouvernance, intentions, maximum trois ans) ;
2. des plans d'action annuels ;
3. des évaluations.

Ce n'est pas un rituel interne de qualité. C'est le cycle que la loi transpose d'un fonctionnement international : schéma, plan, évaluation — et c'est l'évaluation qui débloque les moyens. L'analogie de Bertrand, volontairement décalée, est celle des bailleurs de fonds et des indicateurs d'égalité : on ne vous impose pas la matrice d'un autre contexte ; on vous demande de construire les vôtres, pour prouver une montée en maturité.

Le schéma pluriannuel Sopra Steria 2025-2027 est le livrable de cette mission : premier schéma publié par le groupe, référent nommé, rattachement RSE / numérique responsable.

Points techniques importants

Le référent n'est pas un auditeur avec un titre

Le schéma n'est pas libre. La loi en fixe les grandes parties — Bertrand parle de « H2 » obligatoires. Le référent doit ensuite faire tenir, souvent seul :

• le pilotage du schéma (périmètre, prérogatives, nom) ;
• les achats : dans un grand groupe, 80 à 90 % des produits sont achetés ; la loi vise aussi les outils internes (congés, RH, intranet), pas seulement ce qu'on vend ;
• les offres commerciales, quand on répond avec des prestataires ;
• les RH : circuit d'embauche numérisé, mais aussi l'accueil physique (PMR, bruit, couleur) ;
• la formation de toute l'entreprise, pas seulement des développeurs — y compris un e-learning qui doit lui-même être accessible, parfois multilingue ;
• les budgets, souvent absents ;
• les audits et la montée en expertise.

C'est hétérogène. Une personne jugée sur l'ensemble de ces axes en même temps est « sèche » dès qu'un axe sort de son histoire personnelle. Faire exister une formation interne accessible peut être un temps plein. Or il reste tout le reste. Le référent travaille avec les RH, la com, le contenu. Il est rattaché à la DSI, ou à la com, ou à la direction — et son manager ne connaît souvent pas l'accessibilité.

Sopra Steria : commencer par le schéma, pas par la moyenne des audits

Sopra Steria, dans la bouche de Bertrand : « une petite boîte » à ~5 milliards de chiffre d'affaires, ~20 000 personnes en France, ~50 000 dans le monde, dont une filière indienne. Le challenge n'était pas « le groupe France ». C'était le groupe. Il arrive sous la RSE, volet numérique responsable, dans un contexte CSRD : les entreprises soumises doivent publier des données sociales, et la loi française de 2016 prévoyait déjà un référent.

Le piège organisationnel est immédiat. Les interlocuteurs voient l'accessibilité comme une chaîne d'audits. La loi impose des déclarations, donc des audits, donc le référent « doit auditer ». Bertrand inverse : sa mission, c'est le schéma. Les plans d'action et les évaluations viennent après. Sans schéma, on empile des scores.

Les matrices de maturité ne se copient pas

Plusieurs modèles existent. Bertrand en ouvre au moins trois dans la salle :

• le W3C Accessibility Maturity Model, plutôt tourné vers les pratiques, avec des niveaux du type Launch / Integrate ;
• un modèle plutôt organisationnel (intégration dans l'entreprise) ;
• un modèle plutôt design / produit (l'acronyme DAM / AMM entendu en séance désigne cette famille, aux côtés du modèle Microsoft).

Chacun pèse lourd — il avance l'ordre de grandeur de 150 critères, parfois sur 5 niveaux (non lancé, réactif, anticipatif, proactif, généralisé) et 7 dimensions qui ne se recouvrent pas. Un référent seul ne « coche » pas ça. Les universités ont des matrices qui intègrent les étudiants. Une petite structure a besoin d'une matrice à sa taille. Microsoft, producteur d'OS et de machines, ne mesure pas la même chose qu'une ESN.

On peut mesurer des capacités, des pratiques, des résultats. Ce n'est pas interchangeable. La loi, telle que Bertrand la lit, demande de construire ses indicateurs — pas d'importer une grille.

Le périmètre réel dépasse les sites publics : réseaux sociaux d'entreprise, mails, PowerPoint, PDF internes. Tout ça devrait être accessible. On est alors dans les process et la culture. Le frein le plus net du talk : les dirigeants sont loin du terrain, ne connaissent pas l'accessibilité, et arbitrent souvent IA ou accessibilité, pas les deux.

La moyenne RGAA n'est pas un pilotage

Tous les sites, apps, intranets concernés doivent avoir une déclaration, donc un audit. Le RGAA produit un score. Ce que font les organisations : lister, auditer, moyenne, viser 100 %.

Bertrand est net : ça ne marche pas. Ça mesure une conformité imposée, pas une maturité. La maturité ne peut pas être imposée par la loi parce qu'elle est propre à l'organisation. Mesurer pour mesurer n'informe pas sur ce qui progresse. Le rôle du référent est de savoir ce qui avance, pas d'afficher une moyenne.

L'IA casse le rituel d'accessibilité du monde d'avant

Le dernier tiers est le plus actuel. Tout ce qui a été conçu pour l'accessibilité — audits, checklists, formation des équipes de dev — cible le monde d'avant. Aujourd'hui, « le dev, c'est un gars qui parle dans une boîte » et qui fait porter au modèle une part croissante du logiciel.

Questions laissées ouvertes, volontairement :

• l'accessibilité est où, dans ce flux ?
• le référent mesure quoi ?
• faut-il une partie supplémentaire dans le schéma pluriannuel ?
• le prompt contient-il l'accessibilité ?
• y a-t-il une skill, et est-ce qu'elle s'oublie au fil de la conversation ?
• les tests utilisateurs, lents, survivent-ils à du code IA très rapide ?

La conclusion organisationnelle : un seul référent, sans budget, sans experts, avec une mauvaise lecture de la loi, n'avance pas. Ce n'est pas un mystère. C'est un système sous-doté.

Ce qu'il faut retenir

Le référent n'est pas l'auditeur de service. La loi demande un schéma, des plans, des évaluations — un cycle de maturité, pas une moyenne de scores RGAA. Les matrices W3C / éditeurs sont des inspirations, pas des checklists à appliquer seul. Et le rituel d'accessibilité conçu pour des équipes qui écrivent le code à la main n'est pas transposé, aujourd'hui, dans les flux agentiques.

Réflexions Darkwood

C'est le talk le plus proche de ce que Darkwood appelle un workflow. Le schéma pluriannuel est une orchestration : étapes nommées, propriétaires, indicateurs, échecs. L'erreur classique des organisations — commencer par l'audit parce que c'est le livrable visible — est la même que lancer dix agents sans définir la Definition of Done. On obtient de l'activité (des scores, des traces) sans throughput (de la maturité).

L'IA rend le trou plus large. Un agent qui code vite n'a pas le rituel lent du test utilisateur. Si l'accessibilité n'est pas une étape du graphe — prompt, skill, revue, test — elle n'existe pas, exactement comme elle n'existait pas dans le backlog « on verra plus tard ». Le référent qui ne mesure que du RGAA ne verra pas ce trou : le score d'hier ne dit rien du code généré ce matin.

Schéma pluriannuel Sopra Steria 2025-2027

Quand les tableaux cassent : les tableaux en strates

• Speakers : Guillaume Barbier (Paris Web · 24 jours de web)
• Type : Talk technique
• Langue : French
• Créneau : 16/09/2026 · Upfast, Paris

Guillaume Barbier, business analyst chez Razorfish, revient pour la deuxième fois à A11Y Lutèce. Sa spécialité : des CMS qui ne produisent pas trop d'inaccessibilité quand les contributeurs ne sont pas formés. Les tableaux complexes ont été, de son aveu, un échec récurrent. Le talk isole un motif : le tableau découpé en strates.

Quand les tableaux cassent : les tableaux en strates

Un tableau de données n'est pas un damier Excel collé dans une page. C'est une structure d'en-têtes qui donne un sens aux cellules. Le motif « en strates » a l'air simple pour qui voit : des bandes-titres qui coupent le tableau en groupes. Pour un lecteur d'écran, ces bandes sont souvent de l'implicite non tenu.

Ce que présente le talk

Le cas d'étude tient en une grille. Trois colonnes — nom, emploi, responsable hiérarchique — sept lignes. Quatre employés, plus deux lignes « pleine largeur » : Direction des systèmes d'information (DSI), puis Service marketing. Visuellement, on rattache en une seconde Abdel Cherif, développeur, à Nathalie Nguyen et à la DSI ; Samia Réno, admin système, au même service.

Rien de tout cela n'est dans les cellules d'employé. C'est une association spatiale. Pour la recréer dans le code, Guillaume associe chaque cellule à ses en-têtes : colonne « Nom », strate « DSI », colonne « Emploi », et le rappel que le développeur, c'est Abdel Cherif. En HTML, c'est la méthode lourde : id sur les en-têtes, headers sur les cellules. Il demande à la salle de lui faire confiance sur le balisage. Puis il lance le lecteur d'écran.

Ça ne marche pas.

Points techniques importants

L'implicite visuel n'est pas dans l'arbre

Les voyants croisent colonnes du haut et bande de strate sans y penser. Le lecteur d'écran n'a que ce que l'arbre d'accessibilité lui donne. Recoder cette association est le vrai travail — pas « faire un tableau ». Guillaume refuse le cours HTML de 20 minutes. Le sujet est fonctionnel : ai-je rendu explicite ce que mon œil fait tout seul ?

C'est le même problème que les étoiles Accor, à l'échelle d'une grille : l'information est dans la mise en page.

Un balisage correct peut encore échouer au runtime

La démo est le moment du talk. Le lecteur annonce un tableau 3 colonnes, 7 lignes, puis associe à la première cellule des en-têtes que Guillaume n'a pas liés — DSI et service marketing d'un coup. Plus bas, Samia Réno se retrouve collée à la DSI « comme une enquête ». Tant qu'on reste dans une colonne, ça tient à peu près. Dès qu'on change de ligne, la restitution part.

Le constat, sans effet de manche : la structure sémantique est faite, le lecteur d'écran ne s'y retrouve pas. Guillaume n'a pas le temps d'expliquer le pourquoi moteur (navigateur, accessibility tree, combinaisons AT). Il en tire la leçon d'ingénierie : au-delà d'un certain motif, « bien faire le HTML » n'est pas une garantie de restitution. Les tableaux trop complexes cassent, même spécifiés.

C'est documenté plus longuement dans son article Des tableaux de données complexes accessibles, c'est possible ? (24 jours de web, 2025). Le meetup en est la version démontrée, sur le motif strates.

Deux issues : aplanir, ou découper

Plutôt que d'empiler plus d'id/headers, prendre du recul : a-t-on besoin de cette complexité ? La même information peut être donnée de façon plus robuste.

Aplanir. Les strates redeviennent une colonne comme une autre — « Service ». On perd le grouping visuel instantané. On gagne une grille régulière, que les lecteurs d'écran savent parcourir.

Découper. Un tableau par strate. Un <caption> rappelle le service (DSI, marketing), comme le lecteur l'annonce en entrant dans le tableau. Moins compact. Plus simple. Deux jeux de données indépendants n'avaient peut-être pas à cohabiter dans une seule grille.

Dans les deux cas, on arrête de demander au runtime d'accessibilité d'exécuter une chorégraphie que les navigateurs ne tiennent pas.

Ce qu'il faut retenir

Un tableau en strates est confortable pour l'œil et hostile pour le lecteur d'écran, y compris bien balisé. La sortie n'est pas plus d'attributs. C'est une autre forme : colonne de service, ou plusieurs tableaux avec caption. La complexité visuelle n'est pas un invariant métier.

Réflexions Darkwood

Encore une fois : la spécification n'est pas l'exécution. headers et id sont un contrat. Le lecteur d'écran est le runtime. Si le runtime ne honore pas le contrat, le système est faux pour l'utilisateur, quel que soit le respect de la spec.

C'est le même diagnostic que Flow ou qu'un agent : orchestrer des steps trop fins, ou un graphe trop dense, produit une trace illisible. Aplanir (une colonne de plus) ou découper (deux workflows) sont des choix d'architecture. Les CMS qui laissent les contributeurs fusionner des cellules « pour que ce soit joli » génèrent de l'inaccessibilité par construction — Guillaume le dit depuis dix ans. Les agents qui pondent des <table> à partir d'un Excel feront la même chose, plus vite, sauf si le workflow interdit le motif.

Guillaume anime le 24 septembre 2026 à Paris Web l'atelier Penser l'implicite, penser l'invisible. Le meetup en était déjà le teaser : l'implicite visuel, une fois non dit, est une barrière.

Article 24 jours de web

Ce que la soirée tient ensemble

Trois échelles, une seule fracture.

Chez Accor, le lecteur d'écran n'existait pas dans le process : on l'a rendu visible (annotations), puis obligatoire (DoD), puis outillé (référents, iso iOS/Android, capacité de sprint). Chez Sopra Steria, l'audit existait trop : on a dû remonter au schéma, aux indicateurs de maturité, et admettre qu'un référent seul ne porte pas achats + RH + formation + IA. Chez Guillaume, le HTML existait trop : le motif strates est « correct » et cassé.

L'accessibilité n'avance pas faute de checklist. Elle avance quand on arrête de confondre activité et résultat : moyenne RGAA, attributs posés, tickets fermés. Le résultat, c'est une personne qui comprend la fiche hôtel, qui peut embaucher, qui peut lire un tableau. Le reste est de l'orchestration.

L'IA, dans les trois talks, n'est pas un chapitre bonus. C'est le nouveau runtime du logiciel. Si on ne met pas l'accessibilité dans le graphe — maquette, critère, prompt, skill, test utilisateur — elle sera générée comme on générait les tableaux en strates : joli, implicite, et muet.

Merci à Jean-Pierre Gay, Sébastien Bénard, à Upfast pour l'accueil, et aux trois speakers. Le groupe continue sur un rythme bimestriel ; les propositions de talks restent ouvertes. Pizza, chips, bière : le networking n'est pas un à-côté. C'est là qu'on recrute les compétences que l'EAA a rendues non négociables.

Meetup #6 A11Y chez Upfast