Le numérique nous envahit de plus en plus et nous presse dans une succession de tâches et d’actions sans fin. Le temps passé, l’oubli du temps qui passe, l’attraction des écrans toujours plus forte sur ces laps de temps où nous n’avons rien de spécial à faire (files d’attente, transports, attendre son café…) nous étreignent sans nous en rendre compte. Par défaut, comme un réflexe, notre nuque se plie à 90 degrés et notre pouce se muscle au scroll. Finis les temps morts, le nez en l’air, et nos vies s’engouffrent dans les interstices de calendriers surbookés.

Aujourd’hui, je mesure à quel point le numérique nous emmaillote, comme le bébé qu’on enveloppe pour le sécuriser et pour qu’il ne se réveille pas. Moi-même bloquée dans la toile, je veux prendre du recul, me détacher de tous ces points de contact instantanés. Mais ce n’est pas facile !

Le numérique mangeur de temps

« Les Français passent en moyenne 2h40 chaque jour sur Internet, contre 2h06 en 2019. Et 4h21 pour les 15-24 ans. »¹

Comme l’explique l’étude, les supports se multiplient, les connexions augmentent, le temps passé sur les écrans explose. Les usages convergent vers une notion de consommation frénétique des contenus qui rythme nos journées et nos nuits. Dans les transports en commun, de plus en plus de téléphones portables sont allumés, pour des scrolls et des “swipe” (balayages) sans fin.
Et pourtant… Scroller à l’infini, est-ce divertissant ? Est-ce une activité qui nous profite, nous sentons-nous plus apaisé·es et mieux sécurisé·es ? Beaucoup d’études révèlent les conséquences aux écrans et pratiques numériques, comme une accentuation du sentiment d’ennui.

Combien de fois ai-je pris mon téléphone pour, cinq minutes après, me poser cette question : « Mais qu’est-ce que je voulais chercher ? »

Impressionnant, quelle magie ! Mon utilisation est pilotée par des automatismes inconscients qui me dépossèdent de mes intentions. Cet appareil n’est-il pas en train de me décérébrer ?

La modernité, c’est aller vite et « performer »

Pour ma part, trois écrans m’accaparent au quotidien et rythment mes interactions (téléphone, ordinateur et deuxième écran). Une vie parallèle non physique qui avale mes ondes cérébrales… Et cela, je ne le sais que trop bien : moi-même, artisane dans le numérique, j’ai traversé une période où, bien déterminée, j’exploitais toutes les combines et autres biais pour obtenir la rétention d’utilisateurices sur les services et produits numériques que je réalisais. Car « nécessité fait loi » : je croyais dur comme fer que le numérique était le progrès nécessaire à notre société, pour le bien commun. Dans un monde où le temps se monnaye, chaque seconde d’attention est un actif qui doit être optimisé afin d’atteindre des objectifs de gain prospects, de fidélisation, de business. Il est toujours de bon ton de gagner du temps, et d’aller vite, et le temps c’est de l’argent : “Time to market”. La course à la concurrence est un impératif économique qui pousse à l'accélération des modes de conception des produits.

L’expression « gagner du temps » a toujours existé ; Montesquieu en parlait déjà dans ses Lettres persanes (1721). Problème humain, problème historique. Mais aujourd’hui, la technologie accélère par strates d’innovations et nous enjoint à prendre de la vitesse et à être efficient, dans des cycles de plus en plus rapides.

La valeur temps, parlons-en. “Time to cost”, c'est toujours une question d'innovation... ou d'agilité : nous devenons des équilibristes en gestion de projet, cherchant à maîtriser sur le même plan les délais, les coûts et la qualité.

Et justement, le numérique est un médium qui permet de valoriser le temps, pour le gagner en le réduisant au maximum. En effet, la rapidité de production et de livraison sont des priorités. Nous créons des applications en temps réel (RTA). Des méthodes à la pelle pour raccourcir nos temps de production, éliminer des étapes trop chères car trop longues. Le marché impose son rythme, les algorithmes agissent en millièmes de seconde… Le numérique nous rend bien des services et nous séduit par son efficacité. Il est en cela devenu une industrie à part entière, qui s’accapare de plus en plus notre temps tout en nous assurant qu’il nous en fait gagner… Y a-t-il finalement tromperie ?

Comme le lapin dans Alice au pays des merveilles : en retard, toujours en retard !

Le numérique joue de notre capacité à performer, entre le temps de chargement extra court et le temps à passer sur nos écrans, pour ne plus nous en détacher. La captation de nos esprits est devenue un art, puis une industrie.

Nous, les architectes de ce monde fractal, nous sommes devenus les grands prêtres d’une religion paradoxale. Nous construisons chaque jour des outils au service d’une urgence du clic, un scroll sans fin, une connexion persistante, des « temps d’engagement », tout en promouvant le temps gagné à des tâches chronophages. Combien d’outils sont à notre service pour gagner du temps, mais le temps de les maîtriser n’est pas mesuré…

Inversement, nous devons aussi suivre le rythme de nos produits, aussi nous courons ensemble après des “deadlines” que nous avons nous-mêmes fixées, nos jours sont des “sprints” sans ligne d’arrivée. Nous optimisons des “user flows” qui nous épuisent.

Personnellement, en tant que lead designer, je suis dans un flux permanent de production : réaliser des fonctionnalités, des produits, gérer les cycles de livraison, organiser les organisations, optimiser les flux et les réunions. Ah les réunions, l’art de passer du temps à en perdre !
Justement, le temps, nous le perdons dans le fantasme de toujours plus vouloir le maîtriser, le distordre.

Ma passion à l’épreuve du temps

Il y a plus de vingt ans je croyais dur comme fer que mon métier de designer numérique était de créer du sens et d’innover pour une société plus juste et inclusive. Aujourd’hui, je me demande si je ne suis pas devenue une noix dans le casse-noix des secondes. En tant qu’artisane du numérique, je me place en actrice responsable et coupable. Aujourd’hui, je prends conscience de cette monétisation de l’attention cognitive comme une cryptomonnaie, où l’on conçoit des interfaces pour voler des micro-instants, où le Graal n’est plus l’innovation, mais l’immédiateté. Un clic. Un “swipe”. Immersion.
Comment poursuivre ma passion du numérique quand l’objectif d’un outil qu’on me demande de concevoir, est de réduire le temps de travail d’un·e employé·e de huit à une heure (sur cinq tâches mesurées dans sa journée) ?

Oh, j’entends à longueur de meetups en ce moment que « gagner du temps est un super objectif à impact ! ».

Pause, je refais le déroulé : grâce à cet outil que nous déploierons auprès de nos employé·es, nous gagnerons sept heures (donc presque un jour-personne)...

Les arguments qui suivent nous parlent de la qualité de travail retrouvée, avec moins de difficultés à exécuter des tâches chronophages et à si peu d’impact…

Avons-nous besoin de nous projeter dans le futur (à court terme) pour poursuivre le raisonnement de cette performance ? L’outil aura réduit à une heure les cinq tâches non plus seulement d’une personne, mais de cinq.

Mathématiquement, il s’agira bien de supprimer les personnes qui n’auront plus rien à faire. Avec plusieurs milliers de licenciements en 2025² , le secteur technologique a franchi un seuil symbolique. Raccourci trop facile ? Une chose est sûre, l’automatisation et l’adoption accélérée de l’IA poussent à repenser les modèles opérationnels.

Libérez-vous des tâches chronophages avec l’IA

« Gagner en productivité, réussir sa transformation, meilleure compétitivité, grande efficience transversale », le numérique est puissant en sémantique d’empouvoirement. Le moteur est en marche et s’emballe quand il s’agit de gagner des parts de marché. L’immédiateté, cette drogue qui nous fait confondre réaction avec action et productivité avec productivisme.
Le numérique ne calcule son ROI (retour sur investissement) que trop souvent à court terme. La dette UX, la dette technique, la dette d’accessibilité… restent des sujets non abordés qui mènent souvent à l’échec des réalisations numériques prometteuses.

Ce n’est pas grave, ce ne sont pas ces problèmes qui peuvent freiner la course, tant pis pour celles et ceux qui restent sur le bas-côté. Nous enchaînons déjà avec la nouvelle technologie disruptive : l’IA ! Les mêmes arguments et les mêmes objectifs se répètent, et revoilà le fameux « gagnons du temps » !
Dans ma tête surgit l’image du hamster dans sa roue. Ces arguments sont entendus depuis que je fais du numérique, et l’IA est un nouveau moyen pour répéter le concept.

Quelques voix s’élèvent pour démontrer que sur des projets réels, l’IA pourrait bien faire perdre du temps (aux développeurs expérimentés) ³ . Mais peu d’espace pour contredire l’inévitable et empêcher la promotion forcenée d’un progrès qu’on nous impose de toutes parts.

Quand le lapin d’Alice se met des piles dans le dos…

Avec le temps, on gagne surtout du recul, et mon avis est qu’on a la fâcheuse manie de ne voir que « le bout du doigt ». On perd la lune.

La technologie sert avant tout une course au progrès au service d’une privatisation.

Au vu des investissements en cours dans l’IA, on peut discerner que les enjeux sont écrasants.

Je ne suis pas un investisseur, je suis un accélérationniste de la tech.
— Elon Musk, posté sur le réseau social X (2024)

L’accélérationnisme est une idéologie techno-politique radicale qui bat son plein depuis début 2025 aux États-Unis.

L’intention peut être louable : résoudre tous les problèmes du monde avec l’adoption des nouvelles technologies en mode TGV. Un peu de contexte, les cinq premières fortunes au monde sont dans la tech (Musk le premier, avec 490,8 milliards de dollars). Cette théorie enjoint à la défense d’un progrès sans limites, ni celles de la planète, ni celles si faibles de l’humain, encore moins à celles éthiques de la démocratie. Et les moyens mis en œuvre par ces hommes de la tech, pour cette idéologie, sont colossaux.

Nous croyons en l’accélérationnisme pour être certains que la spirale ascendante du technocapital continue de monter pour toujours.
— Marc Andreessen, dans le Manifeste techno-optimiste (2024)

Le numérique est décomplexé et impérieux par cette théorie. Le numérique n’est plus neutre, il est issu de l’orchestration d’enjeux bien plus forts comme la souveraineté et l’accaparement des ressources planétaires. L’éthique est atomisée par la destruction des mécanismes institutionnels et la dérégulation.

Grosse Fatigue !

Comment ne pas remettre en question ce progrès si puissant, si intrusif et épuisant.

Oui, je ressens une grande fatigue : épuisement de travailler dans un domaine qui accélère toujours et encore. Une grande lassitude pour la boucle de rétro-action qui anime le techno-solutionnisme et qui détruit nos environnements vivants.

Je recherche de plus en plus le sens et me questionne sur la part d’éthique de toutes ces activités. Comment traiter cette facilité crasse de créer des outils au service de la technologie, avant de servir en premier les personnes qui ont des vrais besoins, celles qui sont dans le besoin, des nécessités de vie.

Le vrai luxe ne serait-il pas de pouvoir, parfois, ne rien faire ?

J’en viens maintenant à éloigner les écrans et certains produits trop intrusifs, trop asservissants, comme pour sauvegarder mon esprit : refuser l’écran le soir, supprimer des réseaux sociaux, couper les connexions automatiques, laisser mon téléphone dans le sac.
Retrouver ce temps lent, celui où les idées mûrissent, où les conversations s’étirent, où l’on ose encore dire : « Je rêve » sans culpabiliser.

Penser à un week-end sans écran, à une conversation sans notifications, à un projet mûri sans pression. Se poser cinq minutes, ne toucher à aucun objet, juste rester dans la matière pure du temps qui passe et calmer cet esprit qui réclame du remplissage.

La meilleure pause se concrétise dans le non-usage.

Où en sommes-nous aujourd'hui ? Ai-je plus de temps ? Ma vie est-elle plus facile ? Est-ce que je me sens plus libre ?

Cultivons l’art de la pause : dans nos vies, dans les services que l’on réalise.

Ainsi, faire du numérique aujourd'hui, est-ce que cela peut être aussi : se passer du numérique ?

Alors que nos magasins physiques devenaient de plus en plus accessibles (allées larges, rampes d’accès, etc.), notre plateforme e-commerce restait encore difficilement utilisable pour des millions de personnes. Une porte restait fermée.

Le diagnostic de performance

Si une personne aveugle ne peut pas sélectionner sa taille de chaussures parce que le bouton n’est pas bien vocalisé ou si une personne qui navigue uniquement au clavier n’arrive pas à valider son panier, avons-nous vraiment rendu le sport accessible à toutes et à tous ? La réponse était claire : non. Cette prise de conscience à incité l’entreprise à mettre en place des dispositifs visant à ce que l’accessibilité numérique passe du statut d’option à celui d’enjeu stratégique.

Dans cet article, je partage mon retour d’expérience en tant que référent accessibilité numérique, fruit du travail d'une équipe passionnée et convaincue dont je me ferai ici le porte-parole. Vous verrez que c’est une histoire de prise de conscience, d’un parcours avec des défis à relever mais aussi d’accélérateurs qui nous permettent aujourd’hui de voir la ligne d’arrivée, même si la course reste longue.

L’échauffement

Tout commence en 2021, lorsque je rejoins l’équipe de notre système de design¹ pour en développer les premiers composants. C’est là que l’étincelle a jailli : l’accessibilité était inscrite comme un pilier fondateur du système. C'est cette exigence locale qui a tout déclenché, alors même qu'à l’époque le sujet n’était pas encore très développé à l’échelle globale de l’entreprise.

Le passage de relais

Il existait bien des audits, initiés par notre équipe de la mission handicap. Cependant, malgré une expertise réelle dans l’accompagnement humain et le recrutement, cette équipe restait novice sur les aspects techniques du numérique. Il était donc nécessaire de reprendre la gestion de ces audits pour apporter une expertise technique et centraliser la connaissance et le savoir.

Le véritable coup d'envoi a été donné au début de 2023 avec la création d’un groupe dédié, un SIG (Special Interest Group). Son objectif ? Officialiser l’existence d’une équipe dédiée, définir des standards et mettre à jour nos processus. Nous avons recruté des membres (majoritairement dans le développement) ayant un fort intérêt pour le sujet et construit une première formation de sensibilisation d’une heure à destination des équipes. La machine était ainsi lancée.

Relever les défis

Si certains obstacles organisationnels et techniques se dressent encore aujourd’hui, ils ne font que renforcer notre détermination à avancer dans ce marathon.

Le vertige du terrain de jeu

Lors de la création du référentiel de tous les produits numériques de Decathlon (internes et publics), l’ampleur de la tâche nous a sauté aux yeux tant le parc applicatif était immense. Si la priorité a été mise logiquement sur les produits grand public (e-commerce), des retards importants se sont fait sentir sur l’aspect technique.

La recherche du capitaine

C’est un défi classique : comment empêcher qu'un sujet transverse ne s'essouffle ? Plutôt que de rester une initiative isolée, nous cherchons depuis 2023 les bons relais pour que l'accessibilité devienne incontournable. Nous construisons des ponts avec nos responsables pour débloquer des moyens, tout en ayant la chance d'avoir le soutien de l’équipe DEI (Diversité, Équité, Inclusion), véritable moteur qui nous pousse à avancer.

Le changement de braquet : l’accélération

Depuis deux ans, plusieurs déclencheurs nous ont permis de passer à la vitesse supérieure.

Anticiper les réglementations

L’évolution imminente du cadre réglementaire européen est venue catalyser et valider la direction que nous avions déjà envisagée. Ce nouveau cadre a ainsi servi d’accélérateur puissant pour nos équipes e-commerce, qui ont décidé de placer la conformité et l’accessibilité au cœur de leurs priorités au début de 2025. Cette étape réglementaire a renforcé notre ambition de dépasser le minimum légal pour offrir la meilleure expérience possible.

La maturité du système de design

Parallèlement, l’équipe du système de design a considérablement gagné en maturité et en adoption depuis 2021. L’accessibilité y est toujours un pilier central, et il est évident qu’avoir un système de design accessible est indispensable pour rendre nos interfaces numériques accessibles à grande échelle.

Mieux encore, une partie de l’équipe se consacre désormais à la rédaction de lignes directrices globales d’accessibilité pour toute l’entreprise. Ces guides incluent des exemples concrets d’impacts utilisateur et un recueil de bonnes pratiques pour faciliter la vie des développeurs, des développeuses et des designers.

Bien s’équiper pour être autonome

Pour ne pas être le goulot d’étranglement, le SIG a produit des outils structurants :

• Création de notre propre matrice de responsabilités de l’accessibilité numérique qui associe chaque critère du RGAA (Référentiel général d’amélioration de l’accessibilité) à un métier spécifique qui en est responsable (développement, design, rédaction, etc.). Cette clarté responsabilise les équipes et les rend autonomes : chacun connaît précisément sa contribution au succès du projet.
• Intégration dans notre Tech Radar ² des outils permettant aux équipes d’auditer leurs produits (manuellement et automatiquement) en autonomie. Ces outils concernent à la fois le web et également le mobile (iOS et Android).
• Accompagnement par des juristes pour l’intégration des clauses d’accessibilité dans nos contrats partenaires et le suivi de l’évolution des réglementations.

Bilan et perspectives : vers une équipe officielle

En cette fin d’année 2025, je porte officiellement, comme le demande la législation, le titre de référent accessibilité numérique. Cette nomination est venue légitimer une réalité opérationnelle déjà bien ancrée.

Aujourd’hui, où en sommes-nous ?

• Nous avons mis en place un tableau de bord permettant de suivre précisément certaines métriques et évaluer notre progression vers l’atteinte de nos objectifs.
• Nous rédigeons actuellement notre schéma pluriannuel d’accessibilité.
• Nous avons embarqué les équipes avec lesquelles nous allons renforcer l’accessibilité. Les prochaines étapes devraient être lancées au début de 2026.

Notre prochain objectif est simple : bâtir une équipe pérenne d'experts et de formateurs. L'accessibilité numérique n'est plus une option, c'est devenu une évidence stratégique, tout comme l'accessibilité de nos produits sportifs. Le marathon ne fait que commencer, mais nous sommes enfin bien chaussés.

Les leçons que j'en tire

Si vous vous lancez dans cette aventure, voici les principaux conseils que je vous donnerais :

• n’attendez pas la permission : ne cherchez pas la légitimité externe pour avancer. Soyez convaincu·e et vous deviendrez convaincant·e ;
• avancez en équipe : ne restez pas seul·e. Connectez-vous, rassemblez d’autres personnes de services et fédérez autour de vous ;
• montrez que le sujet est sérieux et qu’il impacte massivement l’organisation et ses clients ;
• célébrez chaque avancée : il n’y a pas de petites victoires. Chaque action entreprise est un pas de plus vers un numérique plus inclusif ;
• donnez du sens : expliquez le « pourquoi ». Si vous démontrez clairement l’impact humain et la valeur ajoutée de votre travail, les gens vous suivront naturellement ;
• responsabilisez par l’autonomie : si les équipes veulent vous suivre, donnez-leur les moyens de le faire (outils, guides). L’autonomie est la clé de la mise à l’échelle ;
• restez à l’écoute des évolutions réglementaires et embarquez les équipes en anticipation de ces changements ;
• misez sur le système de design : si vous en avez un, utilisez-le comme cheval de Troie pour promouvoir les bonnes pratiques et construire une base de connaissances commune.

Pour finir, rappelez-vous que comme pour le sport, le plus dur dans l’accessibilité, c’est souvent d’enfiler ses baskets et de s'y mettre. Vous n’avez pas besoin d’attendre d’être une multinationale ou d’avoir un budget illimité pour commencer à ouvrir le jeu. Que vous soyez seul·e ou en équipe, chaque action pour l'inclusion est une victoire et agrandit le terrain pour tout le monde. Alors, ne restez pas dans les gradins à regarder le match se jouer sans vous : l'accessibilité est un sport collectif où chaque joueuse, chaque joueur compte. À vous de prendre le relais !

Propulsée par le Covid-19, la télémédecine connaît un second essor grâce à l'explosion des plateformes de téléconsultation comme Qare ou Doctolib. Entre 2023 et 2024, le nombre de téléconsultations a bondi de 18,7 %. Un phénomène à mettre en parallèle avec l'ascension fulgurante des plateformes, qui sont passées de 6 % des consultations totales en 2021 à 40 % en 2024.

Un succès total, alors ? Pas si simple.

En réalité, si elle est parfois présentée comme solution au problème démographique qui frappe la médecine, la télémédecine profite surtout aujourd'hui… aux jeunes urbains connectés.

Un accès aux soins pour toutes et tous ?

La télémédecine n'est pas née hier. Définie légalement en 2009, remboursée en 2018, elle est restée marginale jusqu'au Covid-19. Mais six ans après le boom, la Cour des comptes tire dans son rapport la sonnette d'alarme, pointant des promesses non tenues et une absence de stratégie nationale claire. Le marché, lui, est florissant : plateformes dédiées à la téléconsultation (Qare, Livi), cabines en pharmacie (Medadom, Tessan) et géant de la prise de rendez-vous et téléconsultation (Doctolib).

Croissance, oui ; cap, moins évident.

Pour construire le futur de la télémédecine, en 2025, la Cour des comptes, les Assises de la télémédecine et la fédération des entreprises de télésanté (LET) convergent sur quatre besoins auxquels la télémédecine doit répondre pour devenir un outil au service de soin éthique et pertinent :

• Garantir l'accès aux soins dans les zones sous-denses ou « déserts médicaux ».
  73 départements sur 101 ont vu leur densité médicale se dégrader en dix ans.

• Réduire la tension sur les urgences.
  Diminuer le nombre de passages évitables aux urgences, c'est à la fois libérer du temps pour les soignants, mais également réduire des coûts : une téléconsultation coûte dix fois moins cher qu'un passage aux urgences.

• Assurer la continuité du suivi pour les maladies chroniques.
  Diabète, insuffisance cardiaque, cancer… 13,8 millions de patients ont besoin d'un suivi régulier.
  Les maladies chroniques représentent 66 % des remboursements de l'Assurance maladie.

• Sécuriser l'accès aux soins pour les populations vulnérables.
  Plusieurs publics prioritaires ont des besoins critiques, à commencer par les seniors qui, bien que représentant 22 % de la population, concentrent 45 % des dépenses de santé. L'accès aux soins est également un défi pour les détenus, dont les 69 671 extractions médicales en 2023 (+ 6 % par rapport à 2021) représentent des déplacements aussi lourds que coûteux. De même, seuls 18 % des résidents d’Éhpad¹ avaient accès à la téléconsultation en 2019, tandis que les personnes en situation de précarité (bénéficiaires de la complémentaire santé solidaire ou de l'aide médicale de l'État) restent souvent éloignées du système de soins.

Sur le terrain : ce qui se passe vraiment

Les promesses tenues

La télémédecine apporte aujourd'hui des vrais avantages à la population.

• Elle accélère l'accès aux soins : le délai médian pour obtenir une consultation passe de 3 jours en cabinet à 1 jour grâce aux plateformes de télémédecine.

• La solution est bien adoptée par les populations précaires : en Île-de-France, 17 % des téléconsultations concernent des bénéficiaires de la complémentaire santé solidaire (C2S), dont 60 % via plateforme. Un signe que le numérique peut aussi être un levier d'inclusion.

• Elle permettrait de participer au désengorgement des urgences: la plateforme de télémédecine Qare estime que 25 % à 30 % de ses patients se seraient rendus aux urgences si la téléconsultation n'avait pas été disponible.

Les angles morts : une solution qui reproduit les inégalités d'accès ?

Malgré ses atouts, la télémédecine est une solution qui peut reproduire les inégalités d'accès.

C'est une solution majoritairement urbaine : loin de les corriger, la télémédecine semble reproduire les inégalités existantes. 62 % des téléconsultations ont lieu dans les grands pôles urbains, qui ne représentent que 38 % de la population française.

Un constat qui s'explique notamment par la fracture numérique :

« Certains villages à côté n'ont même pas de réseau téléphonique. »
— témoigne un patient habitant en zone rurale, dans l'étude de Chloé Vitali (2021).

Les grands absents restent les seniors : l'âge moyen du patient en téléconsultation est de 44 ans (vs. 51 ans en présentiel), et les 18-49 ans représentent 78 % des utilisateurs de Doctolib.

« Si le patient ne sait pas se servir de ses outils, ça va être source de stress. Moi, je vois énormément d’utilisateurs qui ne savent pas ne serait-ce que se servir de leur téléphone. »
— explique un médecin, dans la même étude de Chloé Vitali (2021).

Le déploiement en Éhpad et auprès des détenus est aujourd'hui un échec : en Éhpad, l'objectif de couverture n'a pas été atteint du fait du manque de personnel disponible. Côté détenus, la majorité des unités sanitaires ne sont toujours pas équipées pour proposer des actes de télémédecine.

Dès 2020, la Fédération française des médecins généralistes (MG France) avait vu juste : la télémédecine risquait d'aggraver les inégalités en offrant « un service de plus aux patients les mieux équipés ».

Vers une (télé)santé plus accessible ?

Bien que les plateformes de télémédecine soit un marché bien implanté, elle ne répond pas à tous les besoins de santé et met à l'écart une partie importante de la population.

Alors, comment faire mieux ?

Le design seul ne peut résoudre un problème systémique, mais il peut révéler les frictions, proposer des parcours plus inclusifs et donner les outils pour faire les bons choix.

Voici une proposition de trois pivots de design pour réaligner l'usage sur le besoin réel.

1. Inclure celles et ceux qui sont laissés de côté

Le constat : la téléconsultation profite aujourd'hui surtout aux jeunes, connectés et urbains.
Le pivot : cibler les zones sous-dotées et les patients en fracture numérique.

Les pistes :

• UI/UX accessible : respecter des principes d'accessibilité forts (WCAG AAA)² : contrastes élevés, zones d'interaction larges, navigation simple…
• Adaptations spécifiques à certains handicaps : par exemple, restitution écrite en direct pour les personnes malentendantes ou âgées.
• Téléconsultation assistée : facilitation de l'accompagnement sur place (pharmacies, mairies…) et à distance (aidants familiaux, customer care ou service d'assistance…).
• Amélioration des points d'accès physiques: matériel numérique à disposition dans les pharmacies ou les mairies, avec un médiateur numérique.
• Formation des patients : ateliers gratuits et publics pour aider à utiliser l'outil et se sentir en confiance.
• Valorisation des aides-soignants en Éhpad : former et valoriser le personnel pour assister les téléconsultations.
• Alternative audio : proposer une option « audio seul » par téléphone pour les petits actes, afin de redonner accès au domicile pour les personnes non équipées, réfractaires à la vidéo ou en zone à faible couverture réseau.

2. Garantir des soins à distance d'excellence

Le constat : la qualité des soins est parfois questionnée.
Le pivot : assister et valoriser la pertinence clinique, pas seulement le volume et le temps de consultation.

Les pistes :

• Synthèse intelligente : résumer en amont les documents du patient (dossier médical partagé et pièces transmises par le patient) pour que le médecin ait l'essentiel en un coup d'œil avant de débuter.
• Formation : proposer des modules de formations à la télé‑sémiologie (diagnostic à distance), surtout pour les nouveaux médecins.
• Design éthique : concevoir une interface non anxiogène, sans pression temporelle ou dark patterns.³
• Garde-fous : intégrer des alertes intelligentes sur certains médicaments comme les antibiotiques.
• Objets connectés : intégrer les données d'objets connectés (stéthoscope, tensiomètre…) pour enrichir l'examen, notamment dans les points d'accès physiques.

3. Préserver le lien médecin-patient

Le constat : une téléconsultation isolée peut entraîner une moins bonne prise en charge du patient.

Le pivot : favoriser les modèles de continuité et garantir la relation soignant‑patient quand c'est possible.

Les pistes :

• Continuité facilitée : priorisation du même praticien.
• Intégration systémique : concevoir des outils qui s'intègrent au système de santé existant (médecin traitant, dossier médical partagé…), plutôt que de le court-circuiter.
• Alimentation du dossier médical partagé : quand un médecin rédige une ordonnance ou un compte-rendu, l'information pertinente devrait être envoyée vers le dossier en un seul clic, afin que ces diverses consultations alimentent le même document.
• Gestion documentaire : faciliter l'envoi de documents par les patients (PDF, photos…) avant la consultation.

  ---

Bilan : construire la télémédecine de demain

La téléconsultation a prouvé ses bénéfices : dix fois moins cher qu'un passage aux urgences, délais de consultation divisés par trois, augmentation du nombre de patients par médecins, atteinte des populations précaires… Ces victoires ont prouvé l'apport du numérique au service du soin.

Mais son rôle reste flou. Face à la multiplication des plateformes commerciales, les réserves demeurent : et si ce n'était qu'un outil de convenance pour les populations déjà bien loties ? Que peut vraiment apporter la télémédecine au système de santé français ?

Sources

• ARS Normandie (juin 2025), Livre blanc des Assises de la télémédecine.
• Assurance Maladie (juillet 2024), Les bénéficiaires du dispositif des affections de longue durée (ALD) en 2022 et les évolutions depuis 2005.
• Chloé Vitali (2021), Téléconsultation : vécu et ressenti de patients ayant eu recours à la télé-médecine dans le Var (PDF - 5,95 Mo).
• Cour des comptes (avril 2025), Les téléconsultations : une place limitée dans le système de santé, une stratégie à clarifier pour améliorer l’accès aux soins (PDF - 4,38 Mo).
• Doctolib (juin 2025), La téléconsultation - État des lieux et usages en médecine de ville (PDF - 5,05 Mo).
• Qare (mars 2025), L’essor de la téléconsultation : vers une adoption généralisée en France (PDF - 295 Ko).
• UFC-Que Choisir (juin 2025), Fracture sanitaire, une dynamique mortifère continue depuis 10 ans.

Le travail n’est jamais fini

Jardiner, ça ne s’arrête jamais. Le jardinage, c’est une succession de cycles. Préparer les semis, nourrir les oiseaux, faire pousser les plantes, récolter les légumes, tailler les arbres, encore et encore et encore… Chaque cycle est un peu différent. Cette année, il y a beaucoup de limaces, trop de pluie, pas assez de pluie, de très belles tomates, mais les haricots ne sont pas au top… C’est un écosystème vivant et complexe, qui demande soin et respect constants pour se laisser influencer, tant à ton profit qu’à celui de la faune. Et une fois que tu commences, tu ne peux plus t’arrêter, ou tous tes efforts seront réduits à néant.

Un produit web n’est jamais terminé non plus. C’est le piège du développement web : devoir gérer une liste de tâches sans fin. Il y a toujours une nouvelle chose à faire, plus importante que la précédente, celle que tu avais gardée pour plus tard parce qu’elle était moins urgente que celle que tu as faite en premier ; et ça ne s’arrête jamais. Ça ne s’arrête jamais parce qu’un produit évolue. Le but d’un produit, c’est de fournir un service à un certain public. Ces personnes changent, les tendances changent, les habitudes changent, de nouvelles technologies et de nouvelles idées émergent et rebattent les cartes. Et cet écosystème continue de grandir et d’évoluer en permanence. Tout comme un jardin.

Je m’aperçois que cette entrée en matière peut donner comme un sentiment de submersion, mais rassure-toi, mon objectif n’est pas de te pousser à la reconversion, au contraire, et si tu restes jusqu’au bout, je te promets une conclusion qui saura peut-être t’inspirer.

L’apprentissage n'est jamais fini non plus

L’erreur est humaine. Mon domaine de prédilection, le frontend, qui consiste à gérer les interactions entre l'être humain derrière son écran et l'application, a ceci de rassurant que le champ des erreurs possibles est gentillet. Comment me blâmer, moi, de la disparition impromptue d’une base de données ? Le pire qui me soit arrivé, ce doit être quand, jeune junior livrée à elle-même, le studio qui m’employait a promu un jeu vidéo devenu très vite inaccessible car je n’avais pas réalisé que notre forfait gratuit sur la plateforme Kongregate limitait le nombre de joueurs. Mais revenons à nos bourgeons.

Les erreurs au jardin sont plus frustrantes, parce que contrairement aux pixels, les plantes sont des êtres vivants. Une plante qui meurt est un évènement autrement plus triste qu’un bouton qui ne fait rien quand on clique dessus. Pour s’améliorer, il faut donc apprendre à mieux s’occuper de ses plantes ; certes. Mais l’essentiel n’est pas là. En réalité, cultiver une plante en particulier, réussir ou échouer à la maintenir en bonne santé, n’est qu’une très petite partie du travail. Le jardinage, c’est surtout entretenir un écosystème entier : équilibrer la biodiversité sur le long terme, planter les bonnes essences au bon endroit, tailler un arbre à la bonne période, etc. L’impact de tes erreurs est plus complexe à analyser que l’état d’une seule plante et quand tu fais des erreurs, ton écosystème n’est tout simplement pas aussi bon qu’il pourrait l’être — ce qui signifie moins de plantes différentes, moins d’animaux, moins de légumes, moins d’équilibre, moins de plaisir à s’asseoir et à observer. Et, au contraire, plus l’écosystème est globalement résilient, moins une seule erreur ponctuelle a d’impact.

Un projet de développement suit la même logique : les erreurs ponctuelles ont en réalité moins d’importance que leur accumulation à l’échelle du projet, et leur impact n’est pas binaire, c’est-à-dire qu’on est souvent sur quelque chose de plus subtil qu’un simple « ça marche » ou « ça ne marche pas ». Les erreurs classiques en frontend sont une interface utilisateur difficile à lire, des fonctionnalités qui ne marchent pas sur certains navigateurs, des problèmes d’accessibilité qui rendent l’application inutilisable pour certaines personnes, des données qui chargent avec une approche peu performante, une structure du code mal pensée qui ne tient pas compte de la maintenance à long terme, entraînant davantage de bugs plus compliqués à corriger… Bref, une somme de problèmes touchant à différents aspects — produit, design, implémentation, organisation des tâches, communication au sein de l’équipe, etc — qui, pris ensemble, compromettent l’efficacité globale de ton écosystème, qui n’est pas aussi bon qu’il pourrait l’être.

Si tu as obtenu ton premier emploi il y a déjà plus de dix ans, alors tu te débrouilles mieux à ce jeu-là que si tu viens d'acheter ton premier sécateur, et c’est normal. Que ce soit dans ton jardin ou devant ton écran, faire mieux est généralement une question d’expérience. Fais plein d’erreurs, apprends d’elles et tout ira très bien.

C’est payant, mais pas au point de vendre un membre de ta famille

Alors, prêt⸱e à te lancer dans le jardinage ? Bien sûr, il va y avoir quelques coûts initiaux que tu ne paies qu’une fois. Par exemple, tu achètes une bêche, une pioche, un sécateur et quelques autres outils, et une fois que tu as les outils, tu les as. On pourrait comparer ça à ton ordinateur professionnel et peut-être aussi au temps passé à créer un dépôt partagé pour une nouvelle base de code. Mais il y a aussi des coûts annuels, parce que — tu te souviens ? — le jardinage fonctionne par cycles. Chaque année, il te faut des semis ou des jeunes plants à planter ; chaque année, il te faut de la terre pour les planter ; chaque année, il te faut de l’eau pour arroser tes cultures ; chaque année, des gens qui ne comprennent pas encore très bien comment fonctionne la nature se sentent obligés d’acheter d’autres produits chimiques nocifs pour ne pas avoir dépensé tout cet argent juste pour nourrir les limaces et autres bestioles. Si, après plusieurs cycles, tout ça te coûte encore beaucoup trop cher, méfie-toi : il te faut prendre un meilleur chemin.

De même, lancer un nouveau projet web de zéro a un coût. Ce coût est plus élevé quand tu fais les choses bien, car il y a des fondations à construire que tu peux ignorer quand tu fais les choses mal. Ici, par bien ou mal, j’entends trouver au plus tôt le bon équilibre entre l’expérience utilisateur (UX) et l’expérience développeur (DX). Délivrer un prototype initial est certes essentiel, mais tu ne peux pas te contenter d’empiler de nouvelles fonctionnalités par-dessus sans fondations solides. Si tu n’investis pas dans la mise à jour des dépendances, ton projet pourrait finir avec des failles de sécurité ; si tu n’investis pas dans la maintenance et le nettoyage du code, tu vas te retrouver avec un plat de spaghettis où chaque nouvelle fonctionnalité en casse deux autres ; si tu n’investis pas dans l’écriture de tests, tu ne remarqueras même pas que les fonctionnalités ont cassé et tu seras sous pression pour implémenter des correctifs rapides — et potentiellement plus de bugs — qu’il faudra déployer en urgence ; si tu n’investis pas dans l’automatisation des systèmes de build et de déploiement, chaque déploiement, urgent ou non, prendra un temps considérable et sera plus sujet aux erreurs. C’est pourquoi tu dois vite recentrer ton attention sur la DX pour continuer à développer ton produit à un coût raisonnable. Sinon, le coût deviendra déraisonnable et tes utilisateur⸱ices et toi en paierez le prix.

Que ce soit en ingénierie ou en jardinage, il existe une bonne façon de réduire les coûts : investir dans un écosystème plus solide et autonome. En web, ça signifie investir dans la DX : tout ce qui rend l’équipe plus efficace en lui permettant de passer moins de temps à écrire du code ou à exécuter des actions répétitives, moins de temps à passer sur la maintenance, moins de temps à déboguer, moins de temps à rendre la dernière version de l’application disponible en ligne, etc. La DX fait aussi partie de l’UX, car l’équipe de développement aura davantage de bande passante pour se concentrer sur ce qui compte vraiment : réfléchir à la manière dont chaque nouvelle fonctionnalité sera apprise, perçue et utilisée,pour livrer des fonctionnalités de meilleure qualité plus rapidement.

Investis dans un avenir solide et autonome

Tu te souviens du « chaque année les semis, chaque année la terre, chaque année, chaque année, chaque année… » dont je parlais plus haut ? Dans un jardin où tu n’investis pas, ces coûts représentent littéralement une somme d’argent que tu dois dépenser à nouveau à chaque cycle : payer pour les semis, payer pour la terre, payer pour l’eau, etc. Investir, c’est construire sur ce que tu as déjà pour réduire les coûts année après année. Par exemple, au lieu d’acheter des plants hybrides, trouve des associations qui vendent des semences reproductibles et assure-toi de laisser croître quelques légumes pour en récolter les graines. Au lieu d’acheter toujours plus de terreau, composte tes épluchures et utilise ton compost en surface pour nourrir ta terre sur le long terme. Année après année, elle deviendra plus riche et plus fertile, tu auras plus de légumes avec moins de terreau. Investis une seule fois dans un récupérateur d’eau de pluie et tu pourras utiliser une eau de pluie gratuite pour arroser tes plantes. Si tu achètes et utilises des produits chimiques, beaucoup d’organismes vivants vont mourir et l’équilibre sera rompu. Tu devras alors compter sur de nouveaux produits chimiques pour protéger tes plantes, car la nature ne pourra plus réguler les ravageurs. Accepte la présence des ravageurs, accepte de perdre une grande partie de tes récoltes les premières années et crée un jardin favorable à la biodiversité. La présence des ravageurs attirera leurs prédateurs et tu auras de meilleures récoltes une fois que ces prédateurs seront installés durablement dans ton jardin.

Investir dans l’expérience développeur (DX) fonctionne de la même manière : accepte les coûts initiaux pour un avenir meilleur. Crée une suite de tests ; elle détectera les régressions et garantira que les modifications de code n’impactent pas les fonctionnalités déjà implémentées. Mettre en place une telle suite réduira le nombre de bugs et donc le temps passé à déboguer tout au long du cycle de vie du projet. Plusieurs fonctionnalités partagent un comportement similaire ? Factorise-les pour qu’elles utilisent littéralement le même code : si une nouvelle fonctionnalité a aussi besoin de ce code, elle sera bien plus rapide à développer. Configure une intégration continue (CI) ; elle évitera les tâches manuelles et répétitives qui peuvent être oubliées, comme vérifier que les tests passent avant de fusionner une branche. La CI peut aussi gérer le déploiement automatisé et bien d’autres choses, l’imagination est la seule limite. Partager de bonnes pratiques pour écrire du code maintenable n’est pas facile ; implémenter un linter peut aider. Les linters définissent des règles concernant les syntaxes qui peuvent ou ne peuvent pas être écrites au-delà de ce que le langage autorise. Il existe bien d’autres éléments connus pour améliorer la DX et bien d’autres à inventer en fonction de ton projet et de ton équipe. Mais pour mettre tout ça en place, il faut accepter le coût initial et admettre le calcul : après plusieurs années — voire seulement plusieurs mois —, le coût global du produit est bien inférieur à ce qu’il serait sans une DX adaptée.

Je suis développeuse web : je m’occupe de mon jardin. À moins que je ne sois jardinière : je développe des applications web ? Je ne me souviens plus l’ordre exact, mais ce que je sais, c’est que le travail n’est jamais terminé, qu’il évolue et que nous évoluons avec lui. Je sais aussi que mettre en place des fondations solides peut être difficile et prendre du temps, mais une fois que tu les as et que tu construis dessus, tu peux t’asseoir à ta fenêtre ou à ton bureau, regarder l’ensemble et te dire : « Je fais quand même du sacré bon boulot. »

Les faits

« Les alternants ont commencé à râler quand ils n'ont pas pu se connecter à Brawl Stars (jeu sur smartphone), ça m'a mis la puce à l'oreille. » (Témoignage sur la liste de diffusion FRnog).

AWS est un gros hébergeur de serveurs, très utilisé dans le monde. Comme son nom l'indique, il est propriété d'Amazon.

Amazon a publié une description assez détaillée de l'incident. La panne était purement logicielle et affectait un des innombrables services d'AWS, DynamoDB. Ce service est à son tour utilisé par bien des services Amazon, comme EC2 qui gère les machines virtuelles. Résultat, beaucoup de problèmes un peu partout sur l'Internet, pour le Web, bien sûr, mais pas uniquement puisque la messagerie sécurisée Signal a également souffert. La panne a duré plusieurs heures, avec des conséquences plus ou moins fortes selon le moment. Comme presque toujours dans le monde numérique, il n'y a pas eu d'étude indépendante et publique de la panne, contrairement à ce qui se fait, par exemple, dans l'aviation et il faut donc être prudent, on n'est pas sûr de tous les faits.

Tout AWS n'était pas en panne, loin de là. Les services d'AWS sont répartis en régions, elles-même comprenant une ou plusieurs AZ² . Le client choisit région et AZ. Ce 20 octobre, seule la région us-east-1 (côte Est des États-Unis) était affectée et donc seuls les services qui avaient choisi de s'installer là étaient touchés.

Les réactions dans les médias ont, comme d'habitude, été assez sensationnalistes (« la moitié de l'Internet est en panne ») et souvent mal informés, malgré le compte-rendu très précis techniquement qu'a publié Amazon. Même chose après la panne de Cloudflare le 18 novembre, pourtant là aussi bien analysée par l'hébergeur. Les leçons tirées sur le moment ont souvent été plutôt simplistes (« c'est un scandale », « que fait le gouvernement ? », « il aurait fallu faire ceci ou cela »). Le but de cet article est de creuser la question et de voir ce que cet incident nous apprend.

Un exemple de mauvaise analyse ? Les innombrables articles disant que la panne AWS était « un problème DNS³  ». Il s'agissait en fait d'une bogue dans un de leurs programmes qui assurent le fonctionnement de la plate-forme. Que ce programme gérait des enregistrements DNS est un détail : le DNS, comme système global, marchait parfaitement.

Amazon était-il en tort ?

Gérer un système de la taille d'AWS ou de Cloudflare est vraiment très difficile. Beaucoup de ceux qui se sont exprimés sur la panne en s'indignant de ce qu'un service aussi important qu'AWS ne soit pas « mieux géré » auraient dû être plus prudents dans leur indignation. On parle quand même d'un système technique qui n'a pas beaucoup de précédents dans l'histoire, les pannes sont inévitables.

On sait comment faire des systèmes plus robustes (qui ont quand même des pannes, mais beaucoup moins). Cela implique notamment de diminuer leur complexité en offrant moins de services. Mais le marketing s'y opposerait : le nombre et la variété des services sur AWS est justement un des arguments de vente les plus forts d'Amazon. Il faut donc savoir ce qu'on veut. La personne énervée qui crie sur Twitter que cette panne est intolérable serait sans doute la première à ne pas vouloir choisir un concurrent d'AWS qui offre davantage de robustesse mais moins de services.

Et puis, comme je l'ai dit plus haut, Amazon a bien communiqué pendant la panne et a finalement produit un retour d'expérience vraiment détaillé (mais pas forcément sincère : il n'a pas été évalué de manière indépendante), ce que très peu d'entreprises françaises feraient, dans le cas d'une panne équivalente ; on peut admirer un contre-exemple chez CleverCloud.

Mais a-t-on vraiment besoin de tant de robustesse ?

Malgré ce que le marketing essaie de faire croire, en abusant de termes éthérés comme « cloud », « serverless » et « virtuel », le Web dépend de ressources bien concrètes et des personnes qui les font fonctionner.

Arrivé là, il faut se poser une question : a-t-on besoin de tant de robustesse ? Si Snapchat est en panne quelques heures, est-ce tellement grave ? La question va être compliquée, d'autant plus qu'AWS héberge à la fois des services de distraction et des services bien plus critiques.

On évalue souvent la robustesse en pourcentage de temps de panne. Une robustesse de 99 % veut dire qu'on accepte plus de trois jours complets de panne par an. Une robustesse de 99,9 % signifie qu'on ne tolère que moins de neuf heures de panne dans l'année (AWS ne pourra pas atteindre cet objectif en 2025). Et une robustesse de 99,99 % oblige à ne pas avoir plus de cinquante minutes de panne dans toute l'année. (Notez que certains opérateurs « trichent » en ne comptant pas comme panne les maintenances planifiées. Ce n'est évidemment pas très acceptable : imagine t-on AWS annoncer « le 11 novembre, tout sera arrêté de 1500 UTC à 2200 UTC » ?)

Le point important est que passer de 99 % à 99,9 % coûte très cher. Un tel objectif ne laisse guère de marge d'erreur et nécessite donc un système soigneusement conçu, avec des doublons partout. Réclamer qu'un prestataire ait une telle robustesse, pourquoi pas, mais il faut être prêt à en payer le prix.

Bref, il n'y a pas de mal à accepter une certaine dose de pannes, pour des services qui ne sont pas critiques, mais il faut en être conscient et assumer de prendre des risques.

L'autre problème caché derrière celui-ci est qu'on se rend parfois dépendant de l'Internet sans bonne raison. Pendant la panne AWS, des utilisateurs de lits connectés (!) ont été réveillés car le lit faisait n'importe quoi lorsqu'il n'arrivait pas à joindre le serveur de l'entreprise qui les fabriquait. Ici, la solution n'aurait pas été d'augmenter la disponibilité d'AWS mais de faire des lits qui arrivent à fonctionner, quitte à ce que ce soit en mode un peu dégradé, pendant une coupure de l'accès distant. Face à ce genre de conséquences, on ne peut pas se dire autre chose que « il faudrait une régulation bien plus stricte des gadgets connectés, et tant pis si on est accusé de freiner l'innovation ».

De la même façon, supprimer les accès physiques aux services publics et imposer le passage par un service en ligne n'est pas une conséquence inévitable de lois scientifiques, c'est un choix politique et dont une des conséquences est la vulnérabilité de ces services en cas de panne. (Cela dit, je n'ai pas entendu parler de service public français en ligne injoignable pendant cette panne particulière d'AWS.)

L'autonomie numérique

Un autre sujet important, que la panne d'AWS avait fait ressortir, est celui de l'autonomie numérique. Je ne vais pas parler de « souveraineté numérique », à la fois parce que ce terme est souvent indicatif d'un certain positionnement politique (vers la droite…) et parce qu'il est en général restreint à la souveraineté du pays, identifié à son gouvernement. Si on comprend qu'un pays souhaite garder sa souveraineté et ne pas être dépendant de services Web étrangers (qui peuvent lui couper l'accès ou bien capter des données), il faut aussi se rappeler que l'État national n'est pas toujours bienveillant et qu'il faut aussi défendre la souveraineté du citoyen ou de la citoyenne. Les appels à défendre « la souveraineté », de la part des gouvernements, sont souvent hypocrites. Je vais donc plutôt parler d'autonomie, aussi bien celle de la France vis-à-vis des États-Unis que celle de la citoyenne ou du citoyen vis-à-vis de son gouvernement. ⁴

D'abord, relativisons un peu le problème. Contrairement aux titres sensationnalistes de bien des médias, on n'avait pas « la moitié de l'Internet en panne ». De nombreuses personnes ne se sont même aperçues de rien et ont continué à travailler comme avant. D'accord, la panne était sérieuse et touchait bien des services, mais elle était loin d'être totale. Les médias et les analystes bon marché ont tendance à réduire l'Internet au Web et le Web à la dizaine de services centralisés étasuniens qu'ils connaissent, mais l'Internet reste divers et décentralisé (malgré des tendances très claires à la centralisation). Gardons donc la tête froide : la panne d'une des AZ d'AWS, ou celle de Cloudflare, ne nous ramène pas aux années 1970, avant l'Internet.

Ensuite, plusieurs commentateurs ont critiqué la dépendance vis-à-vis d'un service étasunien et insisté sur la nécessité de disposer de services « souverains » et de les utiliser. Il faut distinguer ici le problème pratique (le risque de panne) et le problème de sécurité. Les acteurs français ou européens tombent en panne aussi (et peut-être davantage : Amazon a plutôt un bon bilan). Migrer vers un service « souverain » dans l'espoir de ne pas avoir de panne serait naïf. En outre, des mauvaises pratiques d'Amazon, par exemple en matière de surveillance et de captation des données, peuvent également être utilisées par un acteur national. Un hébergeur français peut aussi vous censurer, par exemple à la demande du très puissant lobby des ayants droit. C'est un bon exemple de l'importance de distinguer souveraineté nationale et autonomie des individus et organisations.

Est-ce que ça veut dire que la situation actuelle, avec de nombreuses organisations qui dépendent d'AWS est satisfaisante et qu'il ne faut rien faire ? Non, je ne le pense pas. Quand un acteur a un rôle crucial, il a du pouvoir, et il va forcément en abuser. Il est donc très important, non pas de remplacer AWS par un « AWS souverain » qui poserait les mêmes problèmes mais de décentraliser l'Internet et le Web. Il faut qu'il y ait de nombreux prestataires, à la fois pour que les pannes (inévitables) de l'un d'eux n'aient pas de conséquence trop graves et pour éviter la concentration du pouvoir dans une seule entreprise (ou un seul État). Comme le disait ma grand-mère « mettre tous ses œufs dans le même panier, c'est pratique, mais si le panier tombe, tout est cassé ».

Concernant les conséquences des pannes, il faut quand même noter que le décideur pourrait estimer que choisir l'acteur dominant pour son hébergement présente un gros avantage, celui de l'irresponsabilité. Si un·e DSI⁵ choisit AWS, lorsque AWS est en panne, on ne pourra rien lui reprocher puisque « la moitié de l'Internet était en panne ». Si ielle choisit au contraire un petit acteur peu connu, gageons que ce choix sera fortement critiqué lorsque cet acteur aura un problème technique.

En conclusion

Il n'y a pas de solution parfaite : les pannes techniques existeront toujours. On peut limiter leur probabilité (par exemple en préférant des services simples et limités, plus faciles à fiabiliser) et leurs conséquences (en décentralisant) mais on ne peut pas les supprimer.

Déjà, il faut essayer de connaître son graphe de dépendance, les services dont on dépend, parfois transitivement (on dépend de A qui lui-même dépend de B, ce dont on ne s'apercevra que lorsque B sera en panne). Beaucoup d'acteurs du Web ne sont pas réellement conscients des dépendances de leur site. Ce n'est pas grave si c'est le site Web du boulanger du coin de la rue mais c'est plus inquiétant s'il s'agit d'un service important.

On peut alors au moins essayer de produire des messages d'erreur clairs. Un site Web moderne fabrique souvent ses pages en combinant des résultats venus de plusieurs (micro-)services différents, et une panne va souvent produire des effets qui sont surprenants pour l'utilisateur (pensez à une panne d'un gros CDN⁶ qui héberge les CSS). Il faut donc également analyser ce qui se passe en cas de panne partielle.

Ensuite, il faut se préparer à la grande panne : a-t-on un plan B ? Que se passerait-il si X ou Y était en panne ? Veille-t-on à ne pas mettre tous ses œufs dans le même panier ? On a vu plus haut que, même si on reste uniquement chez AWS, il existe plusieurs régions et seule us-east-1 était en panne. Bien des services affectés par la panne auraient eu moins de problèmes s'ils avaient, comme Amazon le conseille, répartis leur service sur plusieurs AZ. Oui, cela coûte plus cher. Il faut donc analyser le risque de panne et mettre cela en rapport avec le coût de la robustesse. Le résultat dépendra évidemment de la criticité du service. (Personnellement, je pense qu'une panne de TikTok de douze heures ne serait pas grave. Mais, le lendemain de la panne, la BBC titrait « Snapchat et les banques repartent », mettant les deux sur un pied d'égalité.)

Et, pour les services les plus critiques, il faut prévoir des solutions non numériques. C'est le cas par exemple pour les services publics qui, pour cette raison et d'autres, ne devraient jamais être 100 % en ligne.

Cet article n’était initialement pas prévu parmi les cases du calendrier de cette édition. Mais entre annulations multiples et consommation totale de la réserve des sujets de secours, nous avons fait appel à l’une de nos compétences d’équipe d’organisation, acquise au fur et à mesure de nos expériences et du temps : la capacité d’adaptation.

À noter aussi que les contenus de cet article sont en partie issus du lightning talk donné par Luc, le président de l’association, lors de Paris Web 2025.¹

Paris Web a 20 ans

Aujourd’hui est une date importante pour Paris Web : c’est notre anniversaire !

Le 19 décembre 2005, la création de l’association « Paris-Web » a été déclarée à la sous-préfecture de Palaiseau.²

Pour marquer ces 20 ans, nous allons partager avec vous quelques éléments de la recette de la longévité de Paris Web.

Mais avant ça, nous allons revenir sur quelques épreuves traversées, dont certaines auraient pu signer la fin de l’association.

Un long fleuve (pas si) tranquille

Un départ sur le bon pied

Dès la première édition en 2006, ça commençait fort. Les conférences devaient se dérouler dans une salle mise à disposition par l’entreprise dans laquelle travaillait l’un des fondateurs. Mais à une semaine du jour J, il s’est révélé que la salle n’était pas du tout réservée…

Après quelques sueurs froides et coups de fil, la salle a quand même pu être utilisée comme prévu. L’équipe avait cependant comme contrainte de libérer la place pour 18 heures tapantes, car un événement était prévu en soirée.

Au final, ça l’a fait quand même, mais cet épisode fut précurseur de ce qui nous attendait les années suivantes.

Annulation de dernière minute

On pourrait sans doute faire plusieurs chapitres de toutes les péripéties au fil de chacune des années, mais faisons un saut dans le temps jusqu’en 2018.

Trois jours avant l’événement, l’hôtel que nous avions réservé pour les orateurices et le staff nous annonce qu’il ne peut finalement pas honorer notre réservation car le lieu est en travaux. Panique à bord : on a une cinquantaine de personnes à reloger, comment on fait ?

Heureusement, avec un peu de diplomatie, nous avons pu maintenir notre réservation. Nous avons juste dû nous accommoder du sol en béton brut dans les couloirs. Ce n’était pas si terrible et après coup on en a bien rigolé en se disant qu’on ne pourrait pas faire pire.

On ne peut pas faire pire

Au début de l’été 2019, on apprend qu’on ne pourra finalement pas faire la journée d’ateliers dans l’école prévue. Après plusieurs reports, elle sera en plein déménagement au moment de l’événement. Mais bon, il nous restait encore quelques mois pour nous retourner et trouver un nouveau lieu, ce n’était pas pire que l’annulation de l’hôtel à trois jours de l’événement.

Toujours en 2019, un mois avant les conférences, le lieu censé les accueillir nous annonce que non, finalement, les conférences ne pourront pas avoir lieu dans leurs locaux. Ils ne pouvaient plus accueillir de public tant que certains travaux n’auraient pas été réalisés et ces derniers ne pourront pas être terminés d’ici là. À ce moment-là, nous nous sommes dit que l’annulation de l’hôtel, ce n’était finalement pas si pire…

Nous avons dû complètement revoir toute l’organisation de l’événement, à commencer par trouver un nouveau lieu en quelques semaines alors qu’il faut généralement plutôt une année ; trouver un nouvel hôtel à proximité du nouveau lieu ; revoir toute la logistique pour le traiteur, les stands, la régie vidéo… Bref, nous avons souffert comme jamais.

Cette fois c’est sûr, on ne peut pas faire pire

Nous vous laissons deviner ce qui nous tombe dessus l’année suivante, en 2020 ? Une petite pandémie mondiale bien sûr !

Après la réorganisation de tout l’événement en un mois, nous avons dû cette fois complètement revoir le format pour passer d’un événement présentiel à un événement distanciel. Ça n’a franchement pas été facile, mais nous l’avons fait tout en maintenant le niveau d’accessibilité que le public attend de nous. Nous avons même suffisamment bien réussi pour réitérer la formule en ligne en 2021.

Mais depuis, nous avons définitivement arrêté de dire « on ne peut pas faire pire ».

Pas de pitié pour les croissants

Une autre source de trouble dans l’organisation : la bouffe.

C’est le sujet sur lequel nous recevons le plus de critiques négatives, tous les ans. Et c’est compréhensible, le public a besoin d’énergie pour tenir toute une journée de conférences. Si les repas et pauses ne sont pas en quantité ou qualité suffisante, il y a de quoi entacher l’expérience de l’événement.

Mais il faut savoir que, très souvent, nous sommes contraints de choisir un traiteur parmi une liste imposée par le lieu accueillant l’événement. C’est le cas à l’Institut Pasteur, notamment, où nos conférences se déroulent depuis trois ans.

Cette limitation forte dans le choix du traiteur nous empêche de proposer des options qui nous sont demandées par le public ou que nous souhaiterions proposer.

Ça a été le cas en 2022 par exemple. Alors que nous demandions d’avoir davantage de pièces végétariennes pour le buffet, le traiteur a simplement remplacé des pièces carnées par des pièces de poisson. Car tout le monde sait que le poisson, ce n’est pas de la viande bien sûr !

Cet exemple est une bonne illustration des difficultés que nous pouvons rencontrer pour gérer des demandes qui peuvent être considérées comme simples. Et cela fait partie des nombreuses contraintes dont on n’a souvent pas conscience avant de se retrouver dans l’équipe d’organisation.

Bref, ceci est une liste non exhaustive de faits marquants que nous avons pu traverser au fil des ans.

Pour conclure, nous vous partageons quelques ingrédients grâce auxquels Paris Web est encore là aujourd’hui, selon nous.

Les ingrédients de notre recette

Comme base pour notre recette, nous nous appuyons sur une ligne éditoriale inchangée depuis 2006 : la promotion d’un web de qualité et accessible au plus grand nombre et une volonté affirmée de créer des ponts entre tous les métiers de la chaîne de production web. À cela s’ajoutent quelques ingrédients supplémentaires.

Prise de recul permanente

Un premier ingrédient de notre longévité est que nous n’avons jamais cédé aux sirènes de la mode, tout en essayant de garder une vision prospective des évolutions du web, des outils et de nos métiers.

Un exemple très concret car d’actualité : le sujet de l’intelligence artificielle, qu’on nous vend littéralement à toutes les sauces depuis deux ou trois ans et l’arrivée de ChatGPT.

À l’image de l’effervescence ambiante, nous avons reçu beaucoup de propositions sur ce thème pendant l’appel à sujets et nous en avons éliminé sans peine une grande partie car la plupart de ces propositions étaient trop artificielles.

Mais ça ne veut pas dire que nous ne considérons pas l’IA comme un vrai sujet. Au contraire, nous l’avons traité à Paris Web bien avant que tout le monde ne s’asticote dans tous les sens à ce propos : entre 2017 et 2023, nous avions déjà proposé six conférences traitant directement ou indirectement du sujet.

Volonté d’inclusion de tous et toutes

Un autre ingrédient important est une volonté réelle d’inclusion de tous et toutes.

Si l’accessibilité est au cœur de notre mission, l’inclusion plus largement est un sujet que nous prenons très au sérieux. Même si nous ne sommes pas parfaits et qu’on peut toujours s’améliorer, nous faisons de notre mieux pour lever le plus possible de barrières à l’accès à nos événements.

Et c’est avec un immense plaisir que nous voyons de plus en plus d’événements suivre cette voie et proposer des services d’accessibilité tels que la vélotypie ou la retranscription textuelle automatique.

Organisation rigoureuse

Derrière notre apparence de bisounours plein de bienveillance, c’est surtout une organisation affûtée au fil des années et transmise « de génération en génération » par les bénévoles, qui permet à l’événement de perdurer.

Au long de l’année, les missions sont réparties entre les membres sous forme de « pôles » d’activité principale : les relations avec les orateurices, la logistique des conférences, le développement des applications, la recherche de partenariats… Nous avons aussi des « escouades » pour les activités transverses ou ponctuelles (pour les 24 jours de web par exemple).

Aux jours J, chacun·e a sa partition précise rythmant son activité pour la journée, de l’accueil des auditeurices à la mise en place de l’apéro en passant par le passage de micro ou la gestion du temps.

Quand de nouveaux membres nous rejoignent, iels découvrent souvent avec stupeur l’ampleur du travail qui se cache derrière la scène, avec une liste de pôles et de tâches bien définies, requérant rigueur et professionnalisme de l’équipe dans son ensemble et de chacun de ses membres individuellement.

D’ailleurs, les gestionnaires des lieux que nous occupons nous félicitent généralement pour ces qualités, alors même que nous sommes juste bénévoles et qu’aucune personne dans l’équipe ne fait de l’événementiel. Et nous prenons évidemment ces retours avec une certaine fierté.

Abnégation des bénévoles

Enfin, un ingrédient essentiel de la résilience de l’événement, ce sont les bénévoles qui donnent de leur temps chaque année pour que Paris Web puisse continuer à exister.

Parce que partager et promouvoir des idées et des convictions, c’est bien, mais il faut investir du temps et de l’énergie dans des actions concrètes pour que cela serve vraiment à quelque chose.

Au-delà de l’investissement personnel, les membres de l’équipe doivent aussi être capables de faire preuve de réactivité pour gérer les grains de sable dans l’engrenage qui peuvent enrayer toute la machine. Comme, au hasard, faire face à des annulations d’articles à quelques jours de leur publication.

En bref, cette belle aventure ne serait pas possible sans toutes les personnes qui ont composé, composent encore et, espérons, composeront encore longtemps notre équipe.

Un slogan séduisant

Dans les communautés de l’accessibilité numérique en France comme à l’étranger, une phrase revient continuellement : La conformité, ce n’est pas de l’accessibilité. On lit cette phrase sur les réseaux sociaux, on l’entend dans des conférences, des débats d’expertes et experts, dans des échanges informels.

Cette phrase est attirante. Elle sonne comme une douce révolte contre la bureaucratie, un rappel que ce qui compte c’est l’expérience humaine, et pas le référentiel. Évidemment, en un sens, cette phrase est vraie. Une personne aveugle ne se réjouit pas parce que le critère 7.1 est conforme sur un site ; elle se réjouit parce qu’elle peut consulter son compte en banque ou inscrire son enfant à l’école sans difficultés.

Mea culpa, chez Tanaguru aussi on a parfois utilisé ce slogan, souvent avec une bonne dose de pédagogie pour expliquer la différence entre conformité et accessibilité. En tant que consultant et consultante en accessibilité numérique, il nous semble indispensable d’expliquer pourquoi ce slogan si séduisant peut être contre-productif. Merci à 24 jours de web de nous donner l'opportunité de porter plus loin ce message à travers cet article.

Un slogan réducteur qui prête à confusion

Les slogans simplifient des choses qui ne sont pas simples. En simplifiant à l’extrême un sujet aussi délicat que l’accessibilité, on perd des informations.

On entend parfois parler de la véritable accessibilité qui impliquerait que la conformité serait une fausse accessibilité. D’autres fois, on entend parler du RGAA (Référentiel Général d’Amélioration de l’Accessibilité) comme d’une accessibilité normative, qui renverrait à une simple démarche administrative.

Il n’y a qu’un pas pour penser que si les référentiels ne garantissent pas une expérience d’utilisation parfaite, on peut peut-être s’en passer. Croire cela, c’est mal comprendre la situation réelle.

Un slogan détaché du réel

Aujourd’hui, très peu de sites web sont effectivement conformes aux référentiels, très peu s’approchent de cette conformité. Dans la plupart des organisations, le défi n’est pas de dépasser la conformité mais simplement de l’atteindre. La conformité implique une sémantique correcte, une véritable navigation clavier, des alternatives textuelles ou une structure prédictible. Sans ce socle, construire un contenu qui fait sens est impossible.

Les critères d’accessibilité des WCAG (Web Content Accessibility Guidelines, les standards sur lesquels repose le RGAA) n’ont pas été écrits par des techniciens ou techniciennes seules dans leur coin, ce n’est pas une checklist sortie de nulle part. C’est un travail commun entre des experts du web et des personnes handicapées.

Quand l’expérience vécue contredit l’expertise

L’histoire vraie d’un produit inaccessible, vanté pour son accessibilité

Parfois, les utilisations contredisent les avis experts. Une expérience que Frédéric a vécue il y a quelques années, illustre parfaitement cette situation.

Frédéric analysait l’accessibilité d'un dictionnaire en ligne dont l’interface comportait de très nombreuses non-conformités au RGAA. Après des semaines de discussions avec l’éditeur du dictionnaire sur ces sujets, Frédéric est tombé sur un message d’un utilisateur aveugle vantant l’accessibilité de la nouvelle version de cet outil.

La contradiction avec son évaluation l’intrigua. Frédéric a contacté l’utilisateur.

Le coût (cognitif) de l’inaccessibilité

L’utilisateur lui raconta ses techniques pour utiliser le dictionnaire. Il connaissait exactement le nombre de tabulations nécessaires pour atteindre le champ de recherche. Il avait mémorisé la position de tous les champs de formulaires sans labels. Il avait inventé des moyens mnémotechniques pour compenser les incohérences de la structure de l’outil.

Il était capable d’utiliser ce dictionnaire, mais au prix d’efforts cognitifs intenses. Les tâches que les personnes voyantes effectuaient facilement lui demandaient une attention soutenue, une excellente mémoire et un temps important. Sa réussite individuelle n’était pas une preuve de l’accessibilité de l’outil.

L’expérience unique ne fait pas loi

L’expérience d’une personne, même sincère et positive, n’est jamais suffisante pour garantir l’accessibilité pour tous les utilisateurs et utilisatrices. Une personne peut compenser ou tolérer un mode de fonctionnement défaillant. Une autre personne, avec un handicap ou un profil cognitif différent, qui s’appuie sur d’autres outils, qui est plus fatiguée ou moins patiente, ne pourra pas s’adapter. L’accessibilité ne peut pas reposer sur la résilience, et encore moins sur la résilience d’une seule personne.

Les histoires comme celle-ci montrent que la conformité est mesurable, l’accessibilité subjective.

Comment l’industrie des surcouches exploite un slogan

La phrase « au-delà de la conformité » est particulièrement appréciée de certains vendeurs d’outils de surcouche pour l’accessibilité. Leur narratif marketing est presque toujours le même : la conformité est archaïque et rigide alors que leur produit est moderne et léger. Presque émancipateur. Pour les organisations submergées par les obligations légales et le RGAA, la promesse est irrésistible : un simple script permettrait de rendre le site instantanément accessible (« accessible », pas « conforme »).
Les outils de surcouche envahissent les sites web qui peinent à atteindre les prérequis d’accessibilité les plus basiques. Souvent, la structure de ces sites web est complètement défaillante : sémantique absente, titres chaotiques, interactions illisibles, composants inaccessibles.

Aucune surcouche ne peut résoudre ces problèmes : aucune surcouche ne peut donner de sémantique à un élément HTML <div> qui aurait dû être un <button>, reconstruire l’ordre logique d’une navigation avec un lecteur d’écran, ou corriger un comportement clavier inaccessible. Certains outils créent même de nouveaux problèmes.

Les surcouches dépendent de la confusion entre la conformité et l’expérience. Elles donnent l’illusion que l’accessibilité peut se greffer sans revoir la structure, modifier le code, sans réfléchir. En plus d’être impossible, ces croyances retardent inévitablement la mise en conformité des services : Pourquoi travailler sur l’accessibilité de son site si un outil le fait déjà automatiquement ?

Fausse bonne idée : éliminer la contrainte pour réduire la pression

Comme très peu de sites web atteignent une conformité totale aujourd’hui, le fossé entre les attentes et la réalité quotidienne peut sembler impossible à combler. Quand quelqu’un arrive en disant qu’on peut se passer du référentiel, ce message donne l’impression qu’on évite la partie difficile. C’est parfois presque un soulagement : plus besoin de liste de critères, les tests avec des personnes concernées suffisent.

Pourtant, sans conformité, les tests d'utilisabilité deviennent totalement inutiles, un correctif de dernière minute. Récemment encore, nous avons entendu une personne handicapée qui avait été sollicitée pour le test d’un site web déclarer : j’ai parcouru la page d’accueil, il n’y avait pas de titres, les formulaires n’avaient pas de noms, les images pas d’alternatives. Nous aurions pu éviter à cette personne de tester un service non conforme. L’ensemble des remontées se limitait à des éléments couverts par le RGAA. Si le site avait été conforme, le test utilisateur aurait permis de se focaliser sur l’expérience plutôt que sur les non-conformités.

Améliorer l’accessibilité : le rôle du référentiel ?

En opposant conformité et accessibilité, on supprime la seule référence stable sur laquelle les équipes peuvent s’appuyer. Pourtant, sans cette référence stable, les priorités, les responsabilités et les méthodes deviendraient confuses. Au lieu d’aider les équipes à aller de l’avant, on rendrait encore plus difficile d’identifier ce que mieux, plus accessible, signifie.

La conformité n’est pas l’objectif final, mais sans conformité on ne peut pas commencer.

Avec Romy Duhem-Verdière, consœur experte en accessibilité numérique, on s’est interrogées sur le nom du RGAA : ne serait-il pas mal nommé ? Le Référentiel général d’amélioration de l’accessibilité peut laisser penser qu’il nous permet de prendre en compte l’accessibilité de façon progressive, nous laissant le temps d’améliorer. Non, nous avons la conviction que la conformité est un socle, une base, un RGMA : un Référentiel général du minimum d’accessibilité.

Pourquoi opposer conformité et accessibilité est tentant ?

La conformité semble technique et rigide. À l’inverse, l’accessibilité semble humaine, flexible, empathique. Mais dans les faits, l’une ne va pas sans l’autre.

Les équipes font face à des listes d’obligations croissantes : RGPD, qualité, sécurité, écoconception. Ces obligations sont rarement accompagnées de temps supplémentaire, de formation ou de recrutements dédiés. Dans ce contexte, l’accessibilité est perçue comme une contrainte supplémentaire, qui s’ajoute à une longue liste.

La conformité comme bouc émissaire, ou l’histoire de l’échec d’un projet

Le problème ne vient pas forcément des référentiels eux-mêmes, mais de la façon dont les organisations les utilisent. Un fonctionnement en particulier est très courant, au moins dans les projets français :

1. En phase de design, l’accessibilité est oubliée.
2. Pendant les développements, l’accessibilité est ignorée.
3. L’accessibilité est toujours absente lors des premières phases de recette.

Deux semaines avant le lancement, quelqu’un se souvient que la conformité au RGAA est obligatoire. C’est seulement à ce moment-là que l’on se préoccupe du référentiel. Résultat : difficile d’implémenter l’accessibilité sereinement.

Les conséquences de ce process sont d’autant plus dramatiques que les équipes sont rarement formées et peu expérimentées sur le sujet de l’accessibilité. Elles ne savent souvent pas quelles sont les attentes légales ou d’expérience d’utilisation. On leur demande d’appliquer des règles à peine comprises, dans des conditions dans lesquelles personne ne peut réussir.

Un audit réalisé dans la précipitation et sans préparation met en lumière toutes les lacunes du projet, de ce qui est passé inaperçu. L’équipe se retrouve du jour au lendemain avec une somme inimaginable de tickets à corriger. Si l’on se lance dans les corrections après l’audit, le calendrier et le budget en prennent inévitablement un coup. On déclare alors que faire un audit, c’est trop compliqué ou l’accessibilité coûte trop cher.

Un audit à la fin d’un projet ne mesure pas l’accessibilité : il montre l’accumulation de la dette d’accessibilité. Cette dette se crée insidieusement au fil des mois par des décisions prises sans penser à l’accessibilité. Le problème n’est pas la conformité mais bien la façon dont l’audit est encore trop souvent utilisé.

Le dilemme de l’audit : quand la conformité contraint l’expertise

Les professionnels de l’accessibilité numérique ont souvent deux missions : le conseil d’expertise et l’audit de conformité.

Le conseil d’expertise couvre un périmètre de l'accessibilité plus large que les audits. Il permet de soulever des non-conformités directement en lien avec le RGAA mais également des éléments qui vont directement impacter l’utilisabilité, en proposant des bonnes pratiques ou en guidant les choix de design.
L’audit de conformité, lui, est contraint par la logique de conformité ou de non-conformité des critères du RGAA. Lorsque cet audit arrive en fin de process, sans maitrise ou accompagnement préalable, l’audit se limite à vérifier la conformité au référentiel.

Lorsqu’ils sont conduits par des consultants ou consultantes confirmées, les audits peuvent créer une certaine frustration : des freins à l’utilisation sont identifiés mais ne constituent pas pour autant des non-conformités au référentiel. Difficile voire impossible de remonter ces incohérences ou anomalies dans la grille d’audit. Dans ces situations, l’audit remonte des centaines d’erreurs et proposer des améliorations hors référentiel est souvent peine perdue.

On rencontre régulièrement cette situation avec des profils formés initialement à la qualité web (via Opquast notamment). Lors des audits RGAA, ils fulminent à ne pouvoir invalider des éléments qui contreviennent à des bonnes pratiques fonctionnelles ou ergonomiques .

Nous remontons même souvent des bugs de fonctionnement applicatifs à la marge de l’audit, ce qui démontre parfois un manque de recette dans les projets.

Conformité + utilisabilité = la clé de la réussite du projet

Dès que l’on cesse d’opposer conformité et utilisabilité, une perspective plus constructive émerge. La conformité définit le minimum requis, l’accessibilité étend ces conditions à l’expérience vécue. Pour réussir un projet, l’une comme l’autre doivent être intégrées tout au long du process :

• Formation de base : l’accessibilité fait partie de la culture de l’équipe. Les équipes formées partagent cette compétence, ce n’est pas la responsabilité d’une seule personne.
• Conception pour tous et toutes : l’accessibilité est pensée dès le début du projet, en intégrant les besoins des personnes en situation de handicap.
• Validation précoce par les utilisateurs : les prototypes et maquettes sont testées avec des personnes en situation de handicap, validant les hypothèses avant d’initier les développements.
• Transmission structurée entre les différents profils : les designers annotent les maquettes pour l’accessibilité, intégrant notamment les labels, rôles, descriptions et ordres de lecture attendus.
• Contrôles automatisés : les pipelines CI intègrent des outils de tests automatiques pour détecter les erreurs avant qu’elles ne s’accumulent. Même si l’automatisation ne détecte que 20 à 30 % des critères, elle permet d’assurer une qualité de code constant, de détecter les erreurs.
• Vérifications en continu : la vérification de l’accessibilité est effectuée à la fin de chaque sprint, pour limiter la création d’une dette technique.
• Audit initial comme vérification : l’audit de conformité a lieu lors de la phase finale de validation. Il révèle uniquement des erreurs résiduelles ou des oublis mineurs, rien de bloquant ni d’insurmontable.
• Remédiation : les corrections en phase de remédiation sont implémentées rapidement et améliorent significativement le niveau d'accessibilité du projet.

Ces pratiques concilient conformité technique et utilisabilité. En remplaçant les corrections dans l’urgence par une attention continue, ces pratiques facilitent la collaboration entre les rôles et disciplines et réduisent l’accumulation de la dette d’accessibilité. Résultat : les utilisateurs et utilisatrices gagnent en autonomie et en expérience d’utilisation.

Cette opposition entre les référentiels et l'expérience réelle est d'ailleurs au cœur des réflexions sur les futures WCAG 3.0. L'objectif de cette prochaine version (encore lointaine) sera de passer d’une évaluation technique à un système plus nuancé, reflétant mieux la qualité réelle des parcours utilisateurs. Cela prouve bien une chose : l'objectif a toujours été l'expérience utilisateur. Mais en attendant cette évolution majeure, nous ne pouvons pas jeter le RGAA sous prétexte qu'il ne mesure pas tout.



Un message pour les décisionnaires

L’accessibilité est souvent présentée comme un sujet pour les équipes de design, de développement ou les expertes et experts. Les retombées financières, légales et opérationnelles concernent tout autant les équipes dirigeantes : la responsabilité de permettre sa mise en œuvre leur revient.

Les équipes ne peuvent pas produire des résultats accessibles par magie. Elles ont besoin de temps, de ressources et de compétences. Les équipes dirigeantes doivent créer les conditions propices à la réussite : allouer des budgets pour les formations et les outils, ajuster les feuilles de route pour permettre d’intégrer les contrôles qualité, et accepter que l’accessibilité soit une exigence-clé, pas une variable d’ajustement.

Seul ce soutien stratégique permettra des actions fondamentales : former les équipes, faire accompagner les projets par des personnes expertes de l’accessibilité, ou encore réaliser des tests avec les personnes concernées.

C’est un investissement préalable nécessaire qui a un coût. Mais il est généralement moins élevé que de tenter, parfois vainement, de résoudre a posteriori la dette d’accessibilité. Combien de projets peuvent aujourd’hui se targuer d’avoir le budget ne serait-ce que pour de simples tests utilisateurs, sans parler de ceux impliquant des personnes en situation de handicap ?

Conclusion : pas d’accessibilité sans conformité

Oui, la conformité n’est pas l’accessibilité. Confondre les deux est une erreur, mais les opposer est pire. La conformité doit être considérée comme un point de départ : la base saine sur laquelle l’accessibilité peut se développer.

L’accessibilité est la destination : l’expérience vécue d’un produit qui ne demande aucune résilience pour être utilisé. Mais sans conformité, cet objectif est impossible à atteindre.

Et puis une femme, Agnès Chebrou, a mis en ligne la page du physicien Paul Héroult et Wikipédia en français était lancée.

Ne pas avoir peur de commencer

C'est un geste discret et anonyme, réalisé en mai 2001 et présent uniquement sur les archives d'internet. Pourtant, 41 000 héritiers et héritières le font perdurer tous les mois. Tels des petits lutins de Noël, ils se jouent des fuseaux horaires pour créer en continu de nouveaux contenus. De nouvelles pages bien sûr, mais aussi un inlassable travail d'amélioration des 2,7 millions maintenant présentes sur l'encyclopédie en ligne. S'il est discret, ce travail n'est pas secret. On peut les entendre ici corriger une vilaine coquille, ajuster une mise en page, améliorer la formulation d'une phrase, enrichir un paragraphe ou ajouter une illustration.

Il n'y a pas de petite ou de grosse contribution, juste une volonté de participer ensemble à l'amélioration de cette incroyable encyclopédie. Wikipédia sait d'ailleurs enchanter les plus spécialisées en les dotant de petits noms : les wikiFées pour l'ajout d'images, les wikiTarentules pour l'organisation des articles, les wikiBardes pour parler du travail réalisé sur Wikipédia… Une parcelle de magie dans un projet qui en est rempli : tout le monde peut choisir de se transformer en un de ces lutins.

Ne jamais sous-estimer son influence

Est-ce pour cela que Wikipédia est moquée, raillée, dégradée pour s'amuser ou par pure malveillance ? Qu'on l'a mise à rude épreuve par des pics de consultations et qu'on a parfois fait subir de douloureux tourments à ses petits lutins ? Ces actes ressemblent à ceux des malfrats qui cambriolent des associations pour dérober les cadeaux qui ont patiemment été rassemblés afin d'être offerts à Noël.

La manière dont on est invitées à mobiliser ses écrits et réutiliser ses textes a pourtant permis à Wikipédia d'irriguer profondément le web. Il faut dire que le contenu de l'encyclopédie est une ode à la curiosité qui inspire chaque jour les créateurs et créatrices.

À tout moment, et surtout les plus délicats, Wikipédia est là, prête à offrir le meilleur. Sur sa page d'accueil, c'est chaque jour le calendrier de l'Avent avec des contenus sélectionnés pour leur qualité, leur contenu drôle, touchant ou étonnant. En un instant on bascule dans Un chant de Noël, aux côtés d'Elizabeth Bennet, sur les traces de Pluton ou de l'Histoire de Lyon, on découvre la Mésange nonnette ou l'intelligence du cheval, après une plongée parmi les Cétacés de Méditerranée, on revit Pokémon Rouge et Bleu ou Yuri on ice en dévorant le Beurre de tourbière ou la cuisine de la pomme de terre. Tous les savoirs y sont bienvenus et ils appartiennent à toutes et tous grâce à ce travail collectif.

Wikipédia est la plus grande œuvre de coopération internationale au monde dédiée la connaissance. Ce qui était une utopie fête ses 25 ans l'an prochain.

Cultiver la résilience

Alors que des personnes sont nées avec Wikipédia, on a tendance à oublier que c'est petit à petit que toute son infrastructure s'est construite. Ses cinq principes fondateurs sont ainsi apparus au pied du sapin après sa fondation. Ils sont suffisamment robustes pour tracer ses limites et larges pour laisser de la liberté dans la contribution. Mais cela n'empêche pas d'en pointer les failles !

Face aux légitimes critiques sur sa fiabilité, depuis 2006 les sources sont devenues obligatoires sur Wikipédia. Elles permettent d'appuyer les informations présentes dans les articles et de mettre davantage à distance les potentielles malices de ses lutins. L'objectif est de s'effacer derrière le contenu en acceptant que d'autres amendent les textes. C'est accepter qu'il faille respecter l'expression des différents points de vue des sources sur un sujet et tenir compte du consensus scientifique. Cet effacement de façade cache une transparence totale dans l'historique des contributions. Elle permet à tout le monde de comprendre les suites de choix des lutins, d'y revenir au besoin et de discuter sur une base factuelle.

Une base de l'intégralité de son contenu, Wikipédia en propose une chaque jour au téléchargement. Certaines personnes en font régulièrement des copies, craintives d'une potentielle défaillance d'origine technique ou politique. Grâce à l'omniprésence du texte, son poids est très léger. Il est donc très improbable que Wikipédia puisse disparaître totalement du jour au lendemain. Les lutins veillent.

La veille est également dans ses failles : Wikipédia annonce de manière parfaitement claire les imperfections produites par ses lutins. Elle invite à vérifier la présence des informations dans les sources données. Elle propose des défis pour combler ses biais de genre et ses biais géographiques. Les articles à problèmes ont des guirlandes accrochées pour prévenir de leurs faiblesses, de l'orange au rouge en fonction de l'importance des failles. On dit même des plus décorés, littéralement enguirlandés sous les bandeaux d'avertissements, qu'ils sont de vrais sapins de Noël.

Cette capacité à s'adapter en restant la même, en intégrant les critiques et en réaffirmant de manière constante ses valeurs, permet à Wikipédia de maintenir la confiance dans son projet et ainsi de souffler le 15 janvier, partout dans le monde avec vous, ses 25 bougies.

Accepter de se laisser étonner

Sans participer, il est parfois difficile de se rendre compte de l'effet que Wikipédia peut produire sur soi. Contribuer à Wikipédia rend heureuse. On se laisse surprendre par l'étendue d'un sujet, on voyage avec lui dans le temps et dans l'espace en ramenant la joie pure de partager ce que l'on a découvert.

Comme le père Noël, on se pose mille questions : est-ce que cela plaira ? Est-ce bien expliqué ? La source utilisée est-elle fiable ? Le texte correctement écrit ? Vers quelles ressources complémentaires renvoyer ? On apprend à rester humble devant la somme des réalisations. On sollicite d'autres ateliers de lutins, comme OpenStreetMap pour les cartes ou Internet Archives pour des références tombées dans l'oubli.

C'est une aventure profondément humaine où l'on décide de faire confiance aux autres, un chemin qui insuffle de l'optimisme et de l'audace. On ne sait jamais jusqu'où Wikipédia peut nous amener, si ce n'est la vision floue que l'on contribue à l'avenir du savoir.

Alors n'hésitez pas à participer, pour un instant (corriger ici une coquille) ou très régulièrement (ajouter une référence). Nous vous attendons.

Notes et références

• Les statistiques de Wikipédia en français utilisées pour l'article.
• Les magnifiques photos de cet article viennent de Wikimédia Commons. Recevoir quotidiennement son image du jour ici.
• La discussion sur la date anniversaire de Wikipédia en français et la vidéo des 25 ans de Wikipédia.
• Débuter sur Wikipédia : une aide pour faire vos premières contributions.
• Des événements pour apprendre à contribuer près de chez vous avec des personnes expérimentées.

Un service numérique responsable, c’est quoi ?

Un service numérique responsable est une solution numérique qui vise à être utile, sobre, accessible et respectueuse, en tenant compte de ses impacts sur l’environnement, les utilisateurs et la société.

Un service numérique responsable repose sur quatre piliers fondamentaux :

• L’accessibilité : garantir que les services numériques soient utilisables par tous, indépendamment des capacités physiques ou cognitives des utilisateurs.
• La sobriété : minimiser l'empreinte environnementale des services numériques en réduisant leur consommation d’énergie et de ressources tout au long du cycle de vie.
• La confidentialité : assurer la protection des données et éviter toute exploitation abusive des informations personnelles.
• Le respect des libertés : concevoir des services numériques éthiques et non intrusifs, sans manipulation des utilisateurs.

Ces principes de conception s’appuient sur des référentiels concrets, soutenus par des acteurs publics tels que l'Arcep¹ , l'Arcom² , l'ADEME³ et la DINUM⁴ . Ces organismes ont développé des cadres réglementaires et des bonnes pratiques pour guider les entreprises et les institutions.

Parmi ces référentiels, certains existent depuis plusieurs années, comme le RGAA⁵ ou le RGPD⁶ . D'autres sont plus récents, comme le RGESN⁷ , publié en 2024 par l'Arcep et l'Arcom, qui remet au centre de l’attention les enjeux d’écoconception.

Il est donc à noter que concevoir un service numérique responsable n’est plus seulement un engagement moral ou une initiative portée par une communauté engagée, mais bien un enjeu réglementaire et stratégique à long terme.

Un engagement de cohérence pour le produit SNCF Connect

Chez SNCF Connect & Tech, notre raison d’être « Innover pour rendre les mobilités durables accessibles à tous » guide l’ensemble des actions. Elle traduit notre volonté de concevoir des solutions numériques plus responsables, inclusives et sobres.

S'engager dans la mise en place d'une stratégie numérique responsable, pour un service grand public comme SNCF Connect, se trouve à la conjoncture de trois enjeux :

1. Alignement à la mission d'entreprise : favoriser les mobilités et comportements durables au travers d'un produit numérique accessible, sobre, respectueux de la vie privée.
2. Alignement à la responsabilité numérique de l'entreprise : développer un service numérique tout en prenant en compte ses impacts à court et long terme sur ses utilisateurs et la société.
3. Alignement à la responsabilité professionnelle des métiers du numérique : agir en concordance avec les engagements éthiques des métiers du numérique.

Bonnes pratiques d'une stratégie numérique responsable

Au-delà de l’ambition, comment déployer ces engagements ? La suite de cet article présente les différentes actions de notre stratégie numérique responsable, éprouvées sur ces six dernières années, dans une organisation produit. Cette stratégie sera illustrée par la mise en place de l'écoconception numérique — le concept pouvant se décliner sur les différents piliers du numérique responsable.

Stratégie d'entreprise

Bonne pratique : définir les engagements numérique responsable par directions.

Relier les actions des métiers à une stratégie d'entreprise est un élément clé. À ce titre, nous avons engagé une démarche de labellisation numérique responsable⁸ , qui nous a permis d'auditer nos pratiques actuelles, d'engager des ambassadeurs par directions et d'identifier les actions clés à mener sur une période de trois ans. Cette initiative nous a permis de créer une dynamique collective, et un cadre d'action clair et partagé en mobilisant le comité de direction et les équipes. C'est une action essentielle pour inscrire la démarche dans la durée, avec les bonnes ressources associées.

Gouvernance


Bonne pratique : identifier des ambassadeurs et experts métiers.

Sans acteur clairement identifié, pas d'actions concrètes ! Notre gouvernance s'est construite dans le temps et sur plusieurs niveaux :

• à l'échelle des directions, par l'identification d'ambassadeurs en charge de suivre ou de conduire les actions numérique responsable ;
• à l'échelle de l'équipe « Produit, Marketing et Commerciale », avec des experts Design et Tech, spécialisés sur les enjeux d'accessibilité et d'écoconception. L'équipe a notamment mis en place un dispositif de « référents » qui conduisent des actions de formation, de mesure, de conception et d'audit.

Formation

Bonne pratique : former les métiers pour une base de compétence commune.

Les compétences dites « numérique responsable » — à savoir accessibilité, écoconception, vie privée — sont des expertises pointues et parfois de niche. Il est important de pouvoir les démocratiser à tous les métiers qui interviennent dans le produit : product designer / product manager / développeur… C'est une action que nous menons dans les équipes pour permettre une montée en compétence collective et ainsi avoir de réelles applications dans les phases de delivery et discovery des parcours. De même, il est essentiel d'embarquer les métiers de la communication et de la régie (visuels, publicités…) pour démocratiser l'approche aux autres départements.

Processus et outils


Bonne pratique : intégrer l’écoconception à chaque étape du cycle produit en delivery et discovery.

Après la formation, il faut outiller les équipes au quotidien pour permettre une réelle adoption et action des bonnes pratiques d'accessibilité et écoconception. Cela demande d'actualiser le processus delivery par :

• la mise en place de nouveaux outils — comme une checklist écoconception et design review pour s'assurer de la conformité du parcours par les products designers ;
• l'actualisation des process produit — notamment la création de labels accessibilité et écoconception sur JIRA (le fameux) permettant aux équipes de prioriser ces actions ;
• la mise en place de mesure par domaines produit — avec l'outil Fruggr permettant de suivre des mesures précises de temps de chargement, poids de page… sur les parcours clés du produit
• par la réalisation d'audits de conformité de notre accessibilité et écoconception — RGAA sur le web, RAAM⁹ sur mobile, et RGESN — pour s'assurer de la bonne conformité du produit numérique et identifier les actions d'amélioration dans notre démarche de déclaration d'accessibilité et d'écoconception.

Toutes ces actions sont à mener de manière conjointe avec les équipes DesignOps, ProductOps et Tech pour les ancrer durablement dans les processus et outils des équipes.

Action


Bonne pratique : développer des projets pilotes pour tester et améliorer les parcours.

Pour concrétiser les engagements numérique responsable, nous avons mis en place des projets pilotes permettant d'appliquer l’écoconception sur des cas concrets. Ces projets permettent aux métiers d’expérimenter et d'intégrer les bonnes pratiques progressivement, pour ensuite les adopter à grande échelle. Cette approche est à adopter en fonction du niveau de maturité des équipes et de la discipline à intégrer au processus de conception. C'est par des expérimentations répétées que ces bonnes pratiques s'ancrent dans le référentiel des métiers et des équipes.

Mesure


Bonne pratique : mesurer et analyser l’impact de nos services au travers de référentiels d'État.

Pour améliorer en continu les parcours, il est nécessaire de réaliser des audits réguliers. Sur une temporalité annuelle, nous nous basons sur les référentiels d'État :

• concernant l'accessibilité, un groupe d'experts conduit des audits RGAA/RAAM annuellement ;
• concernant l'écoconception, nous expérimentons le RGESN au travers d'un audit interne pour nous situer sur le score d'avancement et définir les processus à mettre en place pour amélioration.

Ces audits sont complétés par une mesure plus quotidienne par domaines, avec des outils dédiés comme Fruggr. Ces actions de mesures sont nécessairement à raccrocher à un objectif à long terme de l'entreprise — avec une ambition de score d'avancement et d'OKR¹⁰ dédié pour en faire une réelle démarche collective et d'entreprise.

Voici un modèle de bonnes pratiques à appliquer en fonction du niveau de maturité de votre organisation. Toutes les étapes ne se sont pas nécessairement à faire dans un ordre chronologique. Chaque contexte est différent, en fonction de l'équipe, des expertises présentes, et des moyens à disposition. L’objectif est de cibler la première action qui semble la plus évidente à mettre en place à court terme et de nourrir les suivantes.

Pour se lancer : convaincre de la valeur de la responsabilité

Cette stratégie vous donne des premières clés et vous voulez vous lancer ! Au-delà des bonnes pratiques, il faut avant tout convaincre les parties-prenantes de s’engager. Voici quelques arguments pour montrer la valeur de la démarche.

• Une amélioration de l’expérience utilisateur : par la montée en exigence sur des principes d'expérience tels que l’écoconception, l'accessibilité, RGPD… le parcours utilisateur et les éléments de l’interface participent à une meilleure utilisabilité du service pour les usagers.

• Anticiper les régulations gouvernementales : en France, la loi REEN¹¹ (loi visant à réduire l’empreinte environnementale du numérique en France) a été adoptée en novembre 2021, et vise à faire converger la transition écologique et la transition numérique. Des référentiels d’État tels que le RGESN ou le RGAA amènent à publier des déclarations d’accessibilité et d'écoconception.

• Réduction des coûts : un service numérique optimisé apportera une économie directe sur les frais d’infrastructure (espaces d’hébergement, utilisation de la bande passante…), particulièrement sur les produits à fort trafic. Concernant l'accessibilité et le RGPD, c'est avant tout éviter des amendes de non-conformité.

• Augmenter la valeur de marque : face aux dérives du « greenwashing »¹² , les marques sont scrutées dans l’ensemble de leur politique. La prise en compte des préoccupations de numérique responsable dans la conception des services numériques accentue l’image d’une marque non seulement engagée mais aussi cohérente.

• Un levier d’engagement interne : le numérique responsable est un fort levier interne de motivation pour les métiers du numérique. Face aux enjeux environnementaux et sociaux actuels, ce défi permet aux équipes de se mobiliser autour de valeurs fédératrices et d’être fières de leurs contributions.

Et pourtant si. Ne connaissant personne et n’ayant aucun sujet particulier sur lequel engager la conversation (à part « j’aime beaucoup ce que vous faites »), j’ai suivi Paris Web comme un zombie, mais avec un fort intérêt. Une chose était sûre, j’avais fait un premier pas dans la machine communautaire et je ne comptais pas en repartir.

Paris Web n’était pas ma première incursion dans le milieu, j’avais déjà fait des tentatives par le passé (je suis dans le web et dans le numérique depuis 1997 ; ça fait un bail). Vers 2004, je me souviens m’être inscrite sur le forum d’Alsacréations, mais aussi avoir été membre d’un truc nommé Affinitiz (sorte d’ancêtre de Slack ou Discord) où j’ai créé une communauté nommée « Webmasters éditoriaux », et surtout d’avoir tout laissé tomber parce que ça ne m’apportait pas grand chose.

Ce qui avait changé avec Paris Web, c’était sans doute le présentiel qui offrait une nouvelle perspective : on voit des gens en vrai et ça foisonne pendant deux jours. Et puis sur la fin de l’événement, j’ai eu une petite discussion avec LA personne¹ qui m’a redonné l’envie de faire et m’a confirmé que j’aimais ce milieu (même si je n’aimais pas mon job à ce moment). Je me suis promis que j’allais moi aussi prendre part à tout ça. Je ne savais juste pas comment.

À l’époque, il n’y avait aucun guide pour aider les nouvelles et nouveaux qui auraient aimé participer d’une façon ou d’une autre. Le monde était un peu en mode Yoda : « fais-le ou ne le fais pas, il n’y a pas d’essai ».

Alors, désolée maître Yoyo, mais un petit coup de pouce pour me guider dans ce qu’il était possible de faire aurait été le bienvenu. Et en voyant resurgir récemment ces questions dans mon entourage, j’ai eu envie de partager mon expérience.

Le sujet est vaste, mais j’ai décidé de ne donner que les points d’entrée les plus simples et les plus abordables. Exit donc les « et si j’écrivais un livre ? », « et si je créais un logiciel machin ? » ou encore « et si je devenais une star vulgarisatrice sur YouTube ? ».

Parées à vous lancer ?

Des projets simples en veux-tu, en voilà

Quand on parle contribution, on pense souvent projets libres ou open source. On pourrait alors croire qu’il n’y en a que pour les développeurs, mais en fait non.

Les projets libres sont ouverts à de nombreux profils, y compris ceux qui n’ont aucune connaissance technique. Quelques exemples pour démarrer :

Common voice de Mozilla

En quoi ça consiste ? Juste à enregistrer votre voix en lisant les phrases proposées sur votre écran. Rien de plus. Le but est de faciliter la diversité des voix, tons, accents ou prononciations pour l’élaboration de systèmes vocaux. Cela prend deux minutes si vous faites juste le petit jeu de textes proposés.

Street Complete pour OpenStreetMap

Là encore, un projet où il n’est nullement besoin de se triturer le cerveau sur votre légitimité. Si vous êtes adepte des petites balades en ville, vous êtes apte à participer. Lancez l’application, celle-ci va vous proposer de compléter des éléments de type : y a-t-il un passage piéton ici ? Ou un abribus ? Les horaires de ce bar sont-ils toujours corrects ? Rien de bien sorcier.

Allez piocher sur Contribulle

Ce sympathique site a pour vocation de recenser des projets qui ont besoin d’aide, et des personnes (comme vous) qui aimeraient contribuer mais ne savent pas à quoi. Développement, graphisme, traduction, communication, relecture, il y en a pour tous les goûts. Le site liste également des idées faciles de contributions.

Vous ne signez pas pour la vie

On ne le répète pas assez mais s’investir dans une communauté ne signifie pas s’engager à vie. 

Si je prends mon propre parcours :

• J’ai commencé tard, après 40 ans : il n’y a pas d’âge pour se lancer.
• J’ai fait des pauses de plusieurs années : personne ne m’en a tenu rigueur.
• J’ai pris le temps de réfléchir avant de revenir.
• J’ai repris un projet… mais j’aurais tout aussi bien pu m’arrêter là en me disant : « J’ai fait ma part, et j’en suis fière. »

Contribuer peut être ponctuel, bref, ou unique. Une journée, une heure, une envie passagère : tout cela compte. Il n’existe aucun engagement minimum, aucune obligation de durée.

Conclusion

Au fond, contribuer, c’est proposer des choses, un petit pas après l’autre, selon son énergie, son temps et ses envies. Il n’y a pas de bonne manière de faire ou de parcours idéal. Il y a vous et ce que vous avez envie d’apporter, même si cela vous semble minuscule. Les communautés se construisent aussi grâce à ces petites touches, pas seulement grâce aux experts.

Si vous avez envie de tenter quelque chose, faites-le. Si vous avez besoin de souffler, faites-le aussi.

L’important n’est pas de réussir sa contribution, mais d’y trouver du sens, du plaisir et même un peu de réconfort.

Alors allez-y : poussez une petite porte, observez, testez, bidouillez, participez… ou pas. Vous resterez toujours aux commandes. Et qui sait ? Vous pourriez bien, un jour, être la personne qui donnera à quelqu’un d’autre l’élan qu’on vous a donné.

Les tableaux existent depuis que le web est web… Même si à l’époque nous les avons surtout utilisés pour disposer librement le contenu de nos pages¹ (qui se souvient d’Image Ready²  ?… OK, je suis vieux). Aujourd’hui, la plupart des personnes qui développent ont abandonné ces usages³ et ne ressortent la balise <table> que pour intégrer des tableaux de données.

Mais alors, pourquoi produisons-nous encore aujourd’hui des tableaux inaccessibles ?

J'ai identifié deux raisons :

• un souci de culture numérique ;
• des limitations techniques.

Un souci de culture numérique

Beaucoup de personnes font encore la confusion entre structurer de l’information dans un tableau de données et présenter cette information dans un damier ressemblant (vaguement) à un tableau. Il suffit d’ouvrir quelques fichiers Excel partagés entre collègues pour s’en rendre compte (sauf si tou·tes vos collègues maîtrisent VBA et les tableaux croisés dynamiques).

De plus, toutes les personnes intégrant des tableaux sur le web ne sont pas des expertes du HTML/CSS, et sont encore moins expertes en accessibilité. De nombreuses personnes qui utilisent des CMS produisent des tableaux sans entrer une ligne de code (si c’est votre cas, ne partez pas ! Je me suis efforcé de rester sur les concepts et de mettre le moins de code possible).

Au cas où, je préciserai donc que nous nous intéressons ici aux tableaux de données :

• ces tableaux présentent l’information de manière structurée ;
• cette structuration est obtenue en plaçant des cellules d’en-têtes qui vont nous informer sur le sens des autres cellules.

Des limitations techniques

Même en intégrant nos tableaux avec une structure correcte de l’information et en respectant à la lettre la documentation MDN, nous pouvons nous heurter aux limites de la machine :

• certaines combinaisons de navigateurs d’écran et lecteurs d’écran provoquent d’étranges anomalies de restitution ;
• certaines structures semblent être tout simplement trop complexes pour les lecteurs d’écran (à moins que ce ne soit les navigateurs qui échouent à construire un accessibility tree cohérent ? Peut-être un peu des deux).

C’est en lisant la rubrique « tables » du blog d’Adrian Roselli que j’ai découvert l’étendue du problème. Dans ses articles, Adrian explore des cas extrêmes, poussant navigateurs et lecteurs d’écrans dans leurs retranchements et mettant en avant des anomalies de restitution assez problématiques. J’ai poursuivi mes lectures jusqu’à avoir une bonne idée de ce qui ne marche pas (ou du moins ne marchait pas⁴ ) mais il me restait difficile de définir quels tableaux sont véritablement accessibles en 2025.

Je me suis donc retroussé les manches pour entreprendre une synthèse des connaissances sur le sujet et vous présenter différents motifs⁵ de tableaux pouvant être utilisés « les yeux fermés ». J’évoquerais aussi quelques motifs à éviter (et des conseils pour les restructurer afin d’obtenir des tableaux plus accessibles).

Remarque : les problématiques évoquées dans cet article concernent essentiellement les critères sur la structuration de l’information⁶ mais les tableaux peuvent impacter d’autres critères, notamment les critères 1.4.10 Redistribution (Reflow, en anglais) et 2.5.7 Mouvements de glissement. Pour éviter que les tableaux fournis en exemple de cet article ne provoquent des erreurs sur ces critères, je leur ai appliqué une petite technique pensée pour éviter que nos tableaux ne déforment nos pages sur les écrans étroits de nos smartphones.
Cette technique est décrite dans cet article de Steve Faulkner.
Si le sujet vous intéresse, cet autre article de Bogdan Cerovac se penche sur les impacts concrets de ces critères pour des utilisateurs et utilisatrices avec différents types de handicaps.

Les spécifications face à la réalité

Préambule : rappel rapide des spécifications

Je ne vous ferai pas un cours complet sur l’implémentation d’un tableau, d’autres ressources le font déjà très bien :

• Documentation MDN : Table accessibility
• Access42 : « Tableaux de données complexes : comment les intégrer de manière accessible en HTML ? », par Maïa Kopff

Ce qu’il faut retenir c’est que deux méthodes sont proposées pour renseigner les lecteurs d’écrans sur la structure d’un tableau (et comment la restituer à leurs utilisateurs et utilisatrices) :

1. déclarer sur chaque en-tête son « périmètre d’action » (scope) ;
2. associer les cellules une à une avec les différents en-têtes.

La méthode par « périmètre d’action » (scope) :

C’est la méthode la plus simple et la moins lourde à mettre en place. Avec cette méthode, on indique sur chaque en-tête d’un tableau si celle-ci concerne sa colonne, sa ligne, ou son groupe de colonnes ou de lignes (quand l’en-tête est une cellule fusionnée).

La méthode par association manuelle des cellules

Cette méthode est plus versatile et peut s’appliquer aux tableaux les plus complexes. Elle s’applique en deux temps :

1. on assigne un ID (identifiant) unique à chaque en-tête
2. on ajoute à chaque cellule un attribut headers listant les ID de tous les en-têtes associées à cette cellule.

Avec cette méthode, il faut intervenir sur toutes les cellules du tableau, ce qui la rend assez lourde à mettre en place (sans compter qu’il faut aussi définir des identifiants uniques à chaque en-tête).

J’aimerais vivre en théorie, parce qu’en théorie tout se passe bien

Avec des méthodes aussi complètes, en théorie nous devrions pouvoir garantir l’accessibilité de n’importe quel tableau assez facilement, quelle que soit leur complexité !

… sauf que l’implémentation de ces spécifications est imparfaite et irrégulière !

Tout va (à peu près) bien tant que l’on reste sur des tableaux simples, mais dès qu’on commence à tester des tableaux complexes, certaines combinaisons navigateurs/lecteurs d’écran commencent à « se prendre les pieds dans le tapis », même quand le HTML du tableau respecte à la lettre les spécifications.

L’enjeu va donc être de réussir à définir les motifs de tableau qui fonctionnent à peu près correctement (ou échouent le mieux, question de point de vue). Pour cela, j’ai testé les différents exemples fournis dans cet article sur un panel de test restreint, détaillé en annexe, que j’ai voulu le plus représentatif possible⁸ .

Ce qui marche : tableaux avec des colonnes fusionnées

Cas d’usage

Pour les colonnes fusionnées, le cas le plus fréquent est probablement celui où nous avons besoin de regrouper des colonnes de données en différentes catégories qui formeront des « super-colonnes ». Imaginons un cas simple avec un tableau commençant par deux lignes d’en-têtes :

• la première ligne comporte des en-têtes fusionnés, nos catégories, valables pour plusieurs colonnes ;
• les en-têtes de la seconde ligne indiquent les données correspondant à chaque colonne.

Dans ce tableau, les en-têtes sont structurés ainsi :

<thead>
  <tr>
    <th colspan="2" scope="colgroup">Produits</th>
    <th colspan="3" scope="colgroup">Caractéristiques</th>
  </tr>
  <tr>
    <th scope="col">Nom</th>
    <th scope="col">Numéro de modèle</th>
    <th scope="col">Norme</th>
    <th scope="col">Dimensions</th>
    <th scope="col">Couleur</th>
  </tr>
</thead>

La restitution

Les colonnes fusionnées sont assez bien restituées par les lecteurs d’écrans (du moins pas plus mal que les colonnes d’un tableau simple… oui Android, c’est de toi dont je parle !). Sur les navigateurs testés sur ordinateur, les deux niveaux d’en-têtes sont bien restituées lorsqu’on change de cellules.

Quelques comportements qui peuvent surprendre mais sont parfaitement normaux :

• la colonne fusionnée n’est énoncée que lorsqu’on « entre dedans » : dans mon exemple, « Produits » ne sera annoncé que lorsque j’arrive dans une cellule de la colonne « Nom » et non lorsque je passe sur la colonne « Numéro de modèle » ;
• l’association par « périmètre d’action » (scope) ne crée pas de liens hiérarchiques entre le premier niveau d’en-tête et le second¹¹  :
  • ainsi quand nous arrivons sur « Caractéristiques », l’en-tête de niveau 2 « Norme » est aussi restitué,
  • par contre les autres en-têtes des autres colonnes sur lesquelles s’étend « Caractéristiques » ne sont pas restitués à ce moment-là (pour l’algorithme de parcours du tableau, nous sommes sur la colonne trois et seuls les en-têtes déclarés dans cette colonne doivent être restitués).

Je trouve les deux derniers points peu satisfaisants (difficile de comprendre la structure du tableau sans une certaine hiérarchisation des en-têtes), mais c’est le comportement attendu.

Note : C’est pour cela qu’il est nécessaire de décrire la structure des tableaux complexes (voir W3C WAI, Caption and Summary in Tables Tutorial ou HTML Specifications for tables - Description techniques).

Les colonnes fusionnées peuvent donc être utilisées, avec quelques précautions.

Support incomplet sur iOS

Sur iOS, les niveaux multiples d’en-tête de colonne sont mal restitués. Dans notre exemple, seuls les premiers en-têtes « Produit » et « Dimensions » sont restitués, laissant l’utilisateur ou l’utilisatrice se débrouiller avec les numéros de colonne et sa mémoire pour se souvenir à quoi correspond chaque cellule. C’est mieux que sur Android mais pas tout à fait satisfaisant non plus.

Méfiance avec les colonnes « orphelines »

En effet, si vous omettez d’assigner un en-tête à une de vos colonnes, certains motifs de tableaux seront étrangement restitués sur certains navigateurs. J’ai ainsi eu un souci avec Chrome et Safari sur Mac (avec VoiceOver). La restitution de mon tableau de test (voir schéma ci-dessus) était incohérente :

• soit un des en-têtes de colonne existants était assigné (à tort) à ma colonne orpheline,
• soit un de mes en-têtes de colonne se retrouvait affublé d’une association incohérente avec un des en-têtes de lignes du tableau.

Mon problème ? J’avais désigné les cellules de ma colonne « orpheline » comme des en-têtes de lignes, et Chrome et Safari sur Mac n’ont pas trop apprécié !

Après quelques recherches additionnelles, voici les conditions à suivre pour ne pas avoir de mauvaises surprises avec des cellules orphelines :

• si vous avez une colonne orpheline : ne placez jamais d’en-tête de ligne dedans ;
• les cellules vides en haut de votre colonne orpheline doivent être des cellules de données (<td>), jamais des cellules d’en-tête (<th>) ;
• et n’oubliez pas de vous poser la question : « ai-je besoin de cette colonne que je n’arrive pas à nommer ? ».

Remarque : on pourrait d’ailleurs critiquer la pertinence de mon choix : un index numérique n’est pas forcément un en-tête de ligne très pertinente.

Bien choisir ses en-têtes de lignes

En dehors d’éviter les anomalies de restitutions sur certains tableaux, il est important de bien choisir ses en-têtes de lignes (<th scope="row">). Celles-ci sont l’un des deux moyens d’identifier à quelle ligne se rapporte la cellule visitée lorsqu’on se déplace verticalement dans le tableau, l’autre moyen étant le décompte des lignes.

Inutile de vous dire que sur un tableau de plus de quelques lignes, le décompte des lignes peut être considéré comme insuffisant pour se repérer et différencier deux lignes.

Il faut donc choisir des en-têtes de lignes réunissant les conditions suivantes :

• uniques (si la donnée se répète sur d’autres entrées de notre tableau, le risque de confusion est grand) ;
• mémorables et identifiables.

Il est possible de désigner plusieurs cellules d’en-tête pour une ligne (notamment pour assurer l’unicité de la dénomination de chaque ligne) mais attention :

• ces en-têtes se répéteront à chaque navigation verticale, si trop de cellules ont été intégrées comme des en-têtes de ligne, la restitution peut devenir pénible ;
• nous l’avons déjà évoqué, Safari et VoiceOver sur iPhone ne restituent actuellement qu’un seul en-tête par colonne et par ligne.

Pour revenir sur notre exemple de liste de fruits, j’aurais probablement dû utiliser les cellules de la colonne « Fruits » comme en-tête de ligne : si je navigue verticalement dans la colonne « Saison », il est beaucoup plus intéressant de m’entendre restituer « Pomme » ou « Abricot » que « 1 » ou « 2 ».

Ce qui marche : tableaux avec des lignes fusionnées

Cas d’usage

Pour les lignes fusionnées, au lieu de regrouper des colonnes de données, notre cas d’usage classique va nécessiter de regrouper des entrées de notre tableau ensemble, pour mettre en avant une donnée que ces entrées ont en commun.

Dans ce tableau, les en-têtes des lignes sont marqués ainsi :

<tr>
    <th colspan="3" scope="rowgroup">Groupe B</th> <!-- Le nombre dans l’attribut colspan dépend du nombre d’élèves dans ce groupe -->
    <th scope="row">Nom d’un élève</th>
    <!-- notes -->
  </tr>
  <tr>
    <!-- pas de cellules pour la première colonne -->
    <th scope="row">Nom d’un autre élève</th>
    <!-- notes -->
  </tr>

La restitution

Les lignes fusionnées sont assez bien restituées par les lecteurs d’écrans (comme pour les colonnes fusionnées).

On retrouve les mêmes comportements un peu surprenants que l'on avait avec les colonnes fusionnées.

Les lignes fusionnées peuvent donc être utilisées, avec les mêmes précautions que les colonnes fusionnées.

Ce qui marche moins bien : le mélange de colonnes et lignes fusionnées

Maintenant que nous savons faire des tableaux avec des colonnes ou des lignes fusionnées, il est tentant de mélanger, d’ajouter un peu de complexité.

Sur beaucoup de combinaisons navigateur/lecteurs d’écran, la restitution sera satisfaisante (tant qu’on évite l’écueil des colonnes « orphelines »), mais quelques comportements bizarres observés avec VoiceOver (en combinaison avec Safari ou Chrome) m’amènent à recommander de se tenir à un seul type de fusion : colonnes ou lignes.

En effet sur Mac, Chrome et Safari m’ont fait d’étranges associations sur mes en-têtes de colonnes, les associant parfois à des en-têtes de lignes qui ne sont ni sur la même colonne ni sur la même ligne. Selon la structure de votre information cela peut être plus ou moins perturbant, mais en général je recommanderais d’éviter de placer vos utilisateurs et vos utilisatrices dans cette situation.

Si vous souhaitez voir jusqu’à quel point on peut rendre illisible la restitution d’un tableau en fusionnant colonnes et lignes, je vous invite à lire cet article d’Adrian Roselli (oui, encore lui) : Avoid Spanning Table Headers.

Et si je fusionne seulement des cellules de données ?

Contrairement aux cellules d’en-têtes, la fusion de cellules de données au sein du tableau ne risque de fausser la compréhension de la structure du tableau par les lecteurs d’écran. En revanche elles peuvent déstabiliser l’utilisateur ou l’utilisatrice lors de sa navigation dans le tableau.

Avec la plupart des lecteurs d’écrans, les cellules de données fusionnées ne sont lues que lorsque l’utilisateurice arrive sur la première de nos cellules fusionnées  : lorsque l’utilisateurice poursuit sa navigation et qu’iel arrive à la colonne ou ligne sur laquelle une cellule a été étendue, la cellule est sautée et iel est envoyé directement à la colonne/ligne suivante.

Avec le lecteur d’écran NVDA, la navigation est plus satisfaisante : les cellules fusionnées ne sont pas sautées et la navigation se poursuit bien dans la bonne colonne/ligne. En revanche, la restitution peut surprendre l’utilisateurice (le lecteur d’écran ne va pas restituer l’en-tête de la colonne/ligne dans laquelle se trouve l’utilisateurice mais celle de la cellule avec laquelle la cellule ciblée a été fusionnée).

Si l’on se base sur les spécifications, ces comportements sont relativement normaux, mais l’expérience utilisateur n’est pas très satisfaisante.

Et l’association manuelle ? Si j’ai un tableau très compliqué et que je suis motivé, ça marche ?

En ce qui concerne l’association manuelle avec des identifiants et des attributs headers, les navigateurs et lecteurs d’écran gèrent aussi bien cette méthode d’intégration que celle par « périmètre d’action » : elle fonctionne bien (sauf sur Android) tant qu’on évite de fusionner des en-têtes de colonnes et des en-têtes de lignes dans le même tableau, ainsi que les colonnes « orphelines ».

Elle marche aussi bien que la méthode par « périmètre d’action », pas mieux.

Mais compte tenu de la lourdeur de sa mise en place (et de la facilité à faire une erreur), elle n’est pas très intéressante sur les cas relativement simples que nous avons présentés jusqu’ici¹² . C’est sur les tableaux les plus complexes qu’elle devrait briller… Sauf que plus un tableau est complexe, plus le risque d’anomalies de restitution est grand ! (Sans compter qu’à partir d’un certain niveau de complexité, on peut s’interroger sur la pertinence du tableau en tant que vecteur d’information).

Simplifier ses tableaux pour les améliorer

Les limites techniques que nous avons explorées dans la partie précédente nous forcent à simplifier nos tableaux pour garantir leur accessibilité au plus grand nombre. Mais ces contraintes peuvent aussi être des opportunités de les améliorer pour tous. Dans cette partie, nous allons parcourir ensemble quelques cas de tableaux (trop) complexes, et les façons dont nous pouvons optimiser leur restitution.

Le tableau en « strates »

Ici nous avons initialement scindé notre tableau en plusieurs « strates » de données, regroupées en thématiques. C’est visuellement satisfaisant et les voyant·es parmi nous comprennent bien la structure de l’information, mais même en prenant mille précautions dans notre intégration, le résultat est compliqué à suivre dans un lecteur d’écran !

Toutes mes excuses aux personnes qui utilisent un lecteur d’écran, le tableau qui suit est pénible (promis, les prochains seront plus agréables). Si vous le souhaitez, vous pouvez évitez ce tableau et passer à la suite de l’article.

Retourner au texte avant le tableau Pour ce genre de cas, deux options s’offrent à nous, qui pourront être plus ou moins adaptées selon l’usage que nous faisons de ce tableau :

• l’aplanir ;
• le découper.

Aplanir le tableau

Aplanir le tableau consiste à « rétrogader » nos strates de supers en-têtes découpant le tableau en une simple colonne de données :

Découper le tableau

Si nous avons ressenti le besoin d’insérer des « strates », peut-être est-ce parce que nous avons plusieurs sets de données (plus ou moins) indépendants à afficher. Dans ce cas, pourquoi ne pas le découper en plusieurs tableaux ?

Note : par défaut ces tableaux ne seront pas aussi joliment alignés que dans notre premier exemple (les largeurs des colonnes dépendant de leur contenu), mais avec un peu de CSS il ne devrait pas être trop compliqué d’harmoniser tout cela !

Le tableau condensé

La tentation est souvent forte de condenser notre tableau à l’extrême, généralement pour des raisons esthétiques, parfois jusqu’au point où l’on sort presque du tableau de données.

C’est le cas dans mon prochain exemple : les résultats des élections d’un CSE (comité social et économique) fictif (listes, nombre de sièges obtenus, détails des votes…) ont été réorganisés au point que la structure de l’information n’est plus visible (l’auteur se repose sur la capacité de son lectorat voyant à deviner le lien en fonction du contexte).

Mise en garde : si vous utilisez un lecteur d’écran, l’intégration du tableau suivant est farfelue et celui-ci est absolument incompréhensible (les tableaux qui le suivent contiennent la même information et sont mieux construits). Si vous le souhaitez, vous pouvez évitez ce tableau et passer à la suite de l’article.

Retourner au texte avant le tableau

Revenir à un tableau de données brutes

Pour comprendre pourquoi les personnes qui ont conçu ce tableau sont arrivées à ce résultat (et leur proposer des alternatives qui les satisferont), il faut repartir de la donnée brute :

Nous avons donc :

• deux informations permettant d’identifier la liste :
  • le nom de la tête de liste ;
  • le nom de la liste ;
• le résultat de l’élection (le nombre de sièges attribués à chaque liste) ;
• les données de dépouillement (qui justifient le résultat) :
  • le pourcentage de voix obtenu (sur le nombre de votants) ;
  • le nombre de voix récolté par chaque liste.

Remarque : il semble que pour notre cible, l’élément déterminant pour identifier une liste n’est pas son nom mais sa tête de liste (vu que c’est cette information qui a été choisie comme en-tête de ligne).

Simplifier en regroupant les données

Si nous souhaitons conserver une structure de tableau de données mais en le condensant, nous pouvons regrouper plusieurs données dans une même cellule et ainsi réduire le nombre de colonnes (tout en nous donnant un peu de latitude pour organiser visuellement ces données). Mais pour que la restitution reste cohérente, il faut aussi retravailler la dénomination des colonnes restantes pour qu’elle soit pertinente pour l’ensemble de la donnée qu’elle contient.

Avec cette structure simplifiée, le tableau est moins monotone qu’un simple tableau de données mais reste cohérent lors de la restitution.

Remarques :

• Notre en-tête fonctionne si notre lectorat a le contexte culturel nécessaire pour déduire le nom de la tête de liste et le nom de la liste elle-même.
  Dans certains cas, il peut être nécessaire d’ajouter des libellés (ou des éléments graphiques accompagnés de textes masqués) pour expliciter les données dans chaque cellule d’en-têtes.
• Comme nous avons placé le nom de la liste et celui de sa tête de liste dans l’en-tête de ligne, la restitution sera un peu bavarde quand l’utilisateur ou l’utilisatrice changera de ligne (l’intégralité du texte de l’en-tête étant lu).
  • C’est d’ailleurs pour cela que nous n’avons pas davantage compacté notre tableau en intégrant le nombre de sièges dans l’en-tête de ligne.
  • Note : une autre solution aurait été d’encore plus simplifier le tableau, en supprimant les en-têtes de ligne et ainsi le réduire à deux colonnes de super-cellules de données.

Alternative : abandonner la structure de tableau

Une autre option que nous aurions pu explorer est de tout simplement abandonner la notion de tableau et simplement agencer les différentes informations avec du CSS. Cette approche est très souple mais attention ! Sans la structure du tableau pour informer les personnes qui utilisent un lecteur d’écran, il sera probablement nécessaire d’ajouter des textes cachés pour clarifier les informations restituées.

Par exemple :

• sans structure de tableau, pour la première ligne, les lecteurs d’écrans restitueront probablement (à condition que l’ordre des libellés dans le HTML soit à peu près logique) : « Martine Laval CGT 9 sièges 40 % 120 voix » ;
• pour améliorer la compréhension, il faudra probablement agrémenter notre texte mise en forme comme un tableau de quelques libellés masqués pour obtenir une restitution plus explicite : « Martine Lavel et la liste CGT 9 sièges au CSE, suffrages récoltés 40 % avec 120 voix ».
  (Dans certains cas, il peut être plus simple de masquer complètement le bloc correspondant aux lecteurs d’écrans et de fournir en remplacement un texte masqué décrivant précisément les informations… mais attention à ne pas oublier de mettre à jour ce texte lorsque les données du tableau sont modifiées !).

Attention ! Pour s’assurer que le résultat est bien compréhensible, il est nécessaire de tester avec plusieurs navigateurs et lecteurs d’écran ce genre d’intégrations exotiques.

Alternative : tableau de données brutes lourdement remanié en CSS

La dernière alternative que je n’ai pas explorée ici est de partir de notre tableau de données brutes et d’en conserver la structure et d’ensuite le « recomposer » à force de CSS (avec l’API flexbox) et de masquage accessible (voir le dernier article de Gaël Poupard sur le sujet).

Mais cette approche a plusieurs inconvénients :

• elle est très spécifique (il vous faudra probablement faire du CSS spécifique à chaque configuration de tableau) ;
• comme pour toute intégration « exotique » :
  • des tests multi-contextes (appareils, navigateurs,…) seront nécessaires pour garantir un affichage correct en toute situation ;
  • cette intégration sera aussi moins robuste dans le temps (plus de risques de régressions dues à une évolution des navigateurs ou de notre propre code).

Conclusion

Nous sommes loin d’avoir abordé tous les cas de figure possibles mais j’espère que les quelques cas étudiés vous auront donné les éléments de réflexions nécessaires pour concevoir et intégrer des tableaux vraiment accessibles, quelles que soient la richesse et la complexité des informations à fournir.

Si vous ne deviez retenir qu’une seule chose, ce serait :

Faites simple ou préparez-vous à une batterie de tests.

Mais si une liste de points à retenir plus détaillée vous intéresse, alors :

• un tableau sert à communiquer : interrogez-vous toujours sur l’information que vous voulez transmettre, sur ce qui lie les données entre elles. L’intention est clef pour produire des contenus accessibles ;
• cherchez la simplicité :
  • un tableau simple est un tableau facile à comprendre ;
  • plus un tableau est simple, plus il est robuste (moins de risque d’anomalies de restitution) ;
  • ne pas hésiter à redécouper en plusieurs tableaux ;
• pas de colonnes orphelines : essayez d’avoir la même densité d’en-tête sur vos colonnes ;
• cellules d’en-têtes fusionnées, mieux vaut choisir : colonnes ou lignes ;
• intégration :
  • optez pour l’attribut scope :
    • simple et rapide à intégrer ;
    • les tableaux trops complexes pour l’utiliser seront de toute manière probablement mal restitués ;
  • l’association manuelle (avec le couple id/headers) fonctionne aussi :
    • mais elle est plus lourde à intégrer et maintenir ;
    • elle permet de gérer des cas très complexes mais :
      • il est probable que ces tableaux soient mal restitués ;
      • il sera nécessaire de faire des tests poussés pour vérifier le résultat ;
  • autres alternatives (données non structurées, structure simple remaniée en CSS) : si la complexité de votre tableau vous force dans ces extrémités, rappelez-vous tout de même de bien le tester avec plusieurs configurations.

Crédits

Les schémas de cet article ont gracieusement été réalisés par Myriam Nguyen-The.

« Comme vous le savez, nous avons retravaillé notre identité visuelle, en nous assurant que celle-ci soit inclusive et accessible. Nous avons reçu de nombreux courriers des enfants et parents du monde entier, nous remerciant du travail que nous avons fait. Nous avons aussi eu de très bons retours de la part des lutins et lutines et de nos fournisseurs de jouets. En revanche, beaucoup mentionnent aussi que notre plateforme n’est pas encore accessible. Qu’en pensez-vous ? Par où devrions-nous commencer ? »

Le Père Noël plante ses deux coudes sur son immense bureau et dépose son visage rond dans ses mains, un sourcil relevé.
Le lutin et la lutine expliquent au Père Noël que la plateforme de la Fabrique de Noël est très dense, avec de nombreuses fonctionnalités. Certaines s’adressent aux fournisseurs de jouets, d’autres aux lutins et lutines de la fabrique.

Oli Daynight explique qu’un bon moyen de commencer serait de travailler sur les composants du design system ¹ car ils représentent une bonne partie des éléments présents dans la plateforme.

« Qu’est ce que c’est un Design System ? », demande le Père Noël, un peu vexé car habituellement, c’est lui qui sait tout.

« Pour faire simple, un design system est un ensemble de composants que l’on retrouve de manière récurrente sur un site ou une application. Cela permet d’unifier le design de ces composants récurrents, voire d’en créer une version codée, que les personnes s’occupant du design ou du développement peuvent intégrer dans les pages. », explique Oli.

Any Goodcookie intervient, expliquant que ce n’est malheureusement pas magique, que c’est un bon moyen de commencer mais que cela ne rendra pas la plateforme totalement accessible immédiatement. Pour atteindre ce but, il faudra revoir les différentes pages, modifier les autres composants, les interactions entre eux ainsi qu’entre les pages. Si les moyens le permettent, ce travail pourra être fait en parallèle. Sinon, il faudra le faire par la suite.

État des lieux

Oli et Any s’attèlent à faire un état des lieux de ce qu’il faut mettre en place pour ce gros projet.

Former les équipes

Any insiste sur le fait qu’avant toute chose il est important de mettre en place une nouvelle série de formations pour les équipes de lutins et lutines chargé·es du design et du développement de la plateforme. La lutine organise alors des sessions de formation avec Candy Canes pour chaque typologie de métiers (exemple : lutins et lutines designers, lutins développeurs et lutines développeuses, lutins et lutines gestionnaires de projets…).

Audit ou refonte immédiate ?

Oli demande à Any d’auditer les différents composants afin de pouvoir estimer l’étendue du travail à faire. Après réflexion, Any ne trouve pas cela très efficace : comme les composants doivent être retravaillés dans leur intégralité suite au changement d’identité visuelle, et au vu du peu de temps imparti, la lutine trouve plus pertinent d’appliquer l’accessibilité directement dès le début du travail sur chacun des composants.
Le lutin n’est pas convaincu car cela implique qu’ils n’auront plus de traces des composants initiaux, plus aucun moyen de savoir quel était leur niveau d'accessibilité de départ.

« En effet. Mais, si tu y réfléchis bien, tu n’as pas eu besoin de mesurer la hauteur du fauteuil avant de t’asseoir, n’est-ce pas ? Tu savais de toute façon à vue d’œil qu’il était haut. Et pourtant, tu l’as escaladé directement pour pouvoir t’y asseoir confortablement, non ? C’est un peu pareil ici.
La marche est haute, mais si nous la grimpons directement nous pourrons y arriver plus rapidement. Nous pourrons alors évaluer notre niveau d’accessibilité tout en sachant que ce sera un niveau déjà relativement confortable », explique Any Goodcookie avec un clin d’œil.

Avec ces arguments, la lutine réussit non seulement à convaincre son confrère, mais également le Père Noël : pour lui, le plus vite sera le mieux ! (Et à moindre coût en plus car un audit lui coûterait cher en cookies et sucreries…)

Conformité ou accessibilité ?

Any pose la question à Oli et au Père Noël : souhaitent-ils :

• uniquement se conformer aux référentiels d’accessibilité, assurant ainsi un accès sans points bloquants à leurs utilisateurs et utilisatrices ainsi que le respect des différentes lois pour l’accessibilité et l’inclusion à travers le monde ?
• ou se conformer aux référentiels et, au-delà, vers plus d’accessibilité et d’utilisabilité pour un réel confort de tous leurs utilisateurs et utilisatrices ?

Bien qu’ils préfèrent tous la deuxième solution, le temps restant avant Noël ne le leur permet pas. Oli propose donc d’assurer la conformité, tout en tentant, par petites touches, sur le design notamment, d’assurer une meilleure accessibilité et utilisabilité, tant que cela ne leur demande pas trop de travail supplémentaire.

Une fois cette décision actée, Any propose d’utiliser les Web Content Accessibility Guidelines (WCAG)² comme référentiel principal. En effet, la Fabrique de Noël travaillant avec des fournisseurs de jouets à travers le monde, elle se doit de respecter un référentiel reconnu légalement à travers le monde. De plus, ce référentiel a récemment été reconnu comme étant une norme ISO (ISO/IEC 40500).

La mise en pratique

Intégrer l’accessibilité dans les processus

Any explique également à Oli et au Père Noël que, pour s'assurer que les composants soient le plus accessibles possibles, il est important qu’elle soit impliquée à chaque étape : de la conception au développement, mais aussi lors de la phase de tests.

Any devient au fur et à mesure la lutine préférée des lutins et lutines designers, développeurs et développeuses. Elle est toujours présente pour les aider en saupoudrant un peu de connaissances par ici, veiller avec bienveillance par là ou encore faire s’envoler de nouvelles idées…

Saupoudrer un peu de connaissances

Pour chaque composant, Any rédige une documentation incluant des recommandations de base pour les designers et pour les développeurs et les développeuses.
Cette documentation sera disponible pour toutes les équipes, pas seulement pour l’équipe du design system. Ainsi, les autres équipes pourront commencer à rendre accessibles tous les composants custom³ sur la base de cette documentation.

Veiller avec bienveillance

Pour accompagner au mieux les lutins et lutines, Any a mis en place des points de contrôle à deux niveaux. Dès que les designers ou les développeurs et développeuses commencent à avoir quelque chose de concret à présenter, Any y jette un œil.

Cela lui permet souvent de:

• les aider à corriger immédiatement les plus grosses erreurs d’accessibilité,
• de repérer immédiatement les points de frustration que pourraient avoir les utilisateurs et utilisatrices en situation de handicap par exemple face à un composant trop complexe,
• ou encore de repérer les soucis de fonctionnement techniques.

Elle vérifie également leurs travaux juste avant la validation finale de chaque étape, afin d’être sûre que rien n’a été oublié.

Phases de tests

Any et Oli auraient bien aimé organiser des tests utilisateurs en rassemblant les différents utilisateurs et utilisatrices en situation de handicap de la plateforme de la Fabrique, lutin·es et fournisseurs de jouets.

« Nous manquons de temps car Noël approche à grands pas ! Nous pourrons le faire après Noël, sur une phase d’amélioration », dit le Père Noël. « Les jouets que je crée ne sont jamais parfaits au premier essai ! J’observe toujours les enfants jouer avec, afin de les améliorer l’année suivante. Faisons pareil dans ce cas ! », ajoute-t-il avec un clin d’œil.

Any explique que la phase de tests reste importante en accessibilité. D’autant que la fabrique de Noël ne possède pas d’équipe de test, par conséquent, les designers, développeurs et développeuses utilisent souvent la technique anglosaxone du « peer review »⁴ , en faisant tester leurs travaux par les autres membres de l’équipe.

Any a alors l’idée de créer des sessions de tests en commun, qu’elle a appelées « Dans leurs chaussons », en référence à l’expression anglaise « to put yourself in someone’s shoes »⁵ , où les lutins designers, développeurs et développeuses devront tester les travaux de leurs pairs. Any leur propose quelques idées magiques :

• une poudre rouge et verte permettant de simuler certaines typologies de daltonisme et de malvoyance,
• une poudre arc-en-ciel pour faire ressortir les erreurs de code,
• un clavier magique empêchant la souris de fonctionner,
• une poudre dorée faisant parler l’ordinateur…

Any leur fournit également une checklist de choses à vérifier durant ces séances.

Bilan

Nous voici au mois de novembre, Noël est au pas de la porte et le Père Noël convoque de nouveau Oli Daynight et Any Goodcookie afin qu’il et elle lui expliquent où en est le projet.

Le lutin et la lutine exultent : quasiment la totalité des composants du design system ont été révisés et sont maintenant en majeure partie accessibles.

Même si la plateforme n’est pas encore totalement accessible, de beaux efforts ont été fournis et les composants du design system apportent une base solide à l’accessibilité de la plateforme. Les processus mis en place par Any ont porté leurs fruits, et les sessions « Dans leurs chaussons » ont apporté un avantage imprévu : tout cela a permis aux équipes de continuer à apprendre sur l’accessibilité !
En effet, la mise en pratique et les conseils quotidiens d’Any pour trouver des solutions et tester ont permis aux équipes d’en apprendre bien plus que lors de leurs formations initiales.

Durant l’année, certains lutins et lutines des autres équipes de design et de développement ont suivi le mouvement, contactant Any pour lui demander de l’aide pour améliorer les quelques pages dont ils et elles étaient responsables.

Le Père Noël est très content car la magie opère à un tout autre niveau : par la volonté et l’engouement des lutins pour l’accessibilité !

Mais il reste conscient qu’il y a encore du travail à faire et des étapes à suivre pour que la plateforme de la Fabrique de Noël soit totalement accessible. Il assure à Any Goodcookie que l’année suivante, tout le monde s’attèlera au reste du travail à faire — il en a déjà informé Léna Candelight, la lutine responsable de la plateforme dans son intégralité (la manager d’Oli), — mais aussi qu’il aimerait bien organiser ces fameux tests utilisateurs. Any s’en réjouit : elle sait déjà qu’elle recommandera Molly Chamalow.

Note de l'auteur : remerciements à ma lutine Eléa pour les illustrations ! 🥰

Mais reprenons les choses au début.

L’attribut title, à quoi ça sert ?

Selon la définition de Mozilla Developer Network (MDN), l’attribut universel title contient un texte d’information lié à l’élément auquel il est rattaché¹ .

Historiquement, l’attribut title est utilisé pour afficher des infobulles, fournir un nom accessible à un élément, ou les deux.

Afficher une infobulle

Si l’on survole avec une souris un élément avec un attribut title, au bout d’un instant, le contenu de l’attribut title apparaît dans un cadre flottant à proximité de l’élément.

C’est principalement utilisé pour préciser la signification d’une icône ou d’un pictogramme, ou encore pour ajouter des informations complémentaires utiles à la compréhension.

Fournir un nom accessible

L’autre usage courant consiste à fournir un intitulé accessible à un élément interactif (lien, bouton, champ de formulaire, etc.). Cette technique est reconnue comme conforme par le Référentiel général d’amélioration de l’accessibilité (RGAA).
Par exemple, le nom accessible d’un lien est déterminé selon l’ordre suivant :

• texte associé via aria-labelledby ;
• sinon, contenu de l’attribut aria-label ;
• sinon, contenu textuel du lien ;
• sinon, contenu de l’attribut title.

Source : Intitulé (ou nom accessible) de lien sur le site du RGAA - ouvre une nouvelle page

Exemple d’utilisation de l’attribut title pour donner un nom accessible à un lien contenant uniquement un pictogramme :

<a href="https://exemple.com/espace-personnel" title="Espace Personnel">
    <span aria-hidden="true" class="fa-solid fa-user"></span>
</a>

Exemple d’utilisation de l’attribut title pour donner du contexte supplémentaire à un lien contenant déjà un texte :

<a href="https://exemple.com/mentions-legales" title="Mentions légales - ouvre une nouvelle page">
    Mentions légales
</a>

C’est quoi le problème ?

Limites de l’utilisation de l’attribut title pour afficher une infobulle

L’information est cachée et nécessite de deviner son existence

Si vous utilisez cette technique pour expliciter la signification de votre icône, c’est comme si vous jouiez aux devinettes avec vos utilisateurs et vos utilisatrices.

Rien n’indique a priori aux personnes qu’une infobulle est disponible. Elles doivent tester : Tiens, et s’il se passait quelque chose si je survole cette icône avec ma souris ?.

Zone avec six pictogrammes, le cinquième pictogramme est un chat et possède un attribut title « Miaou ! ».

Les textes des attributs title obligent à patienter

Admettons que les personnes qui visitent votre site soient fans d’escape game : elles pourraient tenter l’expérience, mais alors, elles devront attendre… car l’apparition de l’infobulle n’est pas instantanée.

Transcription

Présente un extrait de page web. La zone comporte six pictogrammes. Lorsque la souris passe sur le cinquième, qui représente un chat, une infobulle affichant le texte « Miaou ! » apparaît après un court délai.

Sensible au moindre mouvement

Et pour se voir récompensés par l’apparition d’une infobulle, ils devront être adroits : ils vont devoir introduire le curseur de leur souris dans la zone exacte de l’élément qui la porte, et y laisser leur souris sans bouger : l’infobulle n’apparaît que si la souris est parfaitement immobile. Et si vous déplacez votre souris, elle disparaît.

Transcription

Présente un extrait de page web contenant une phrase où l’abréviation « API » est soulignée en pointillé.

La souris passe dessus mais reste en mouvement, ce qui n’entraîne aucune action. Lorsqu’elle se stabilise suffisamment longtemps, une infobulle affichant « Application Programming Interface » apparaît. Toutefois, le message disparaît dès que la souris bouge légèrement, même si elle reste dans la zone de l’abréviation.

Cela crée une barrière pour les personnes qui ne peuvent pas manipuler la souris avec précision.

L’infobulle n’est pas adaptable

Certaines personnes ont besoin d’agrandir le texte, d’augmenter le contraste, d’utiliser un thème sombre ou des feuilles de style personnalisées. Or, l’infobulle générée par l’attribut title ne respecte ni le zoom, ni le thème, ni les styles appliqués par les personnes concernées.

Transcription

Présente un extrait de page web en mode clair, contenant un lien intitulé « Connexion à l’espace professionnel ».

Lorsque la souris se stabilise, une infobulle affichant le même texte apparaît.

L’écran est ensuite zoomé : la taille du texte double, mais celle de l’infobulle reste inchangée et ne s’adapte pas. Le thème de la page passe ensuite en mode sombre ; l’ensemble de l’interface bascule alors en sombre, sauf l’infobulle qui reste claire.

Les textes des infobulles ne sont pas sélectionnables

Le contenu des infobulles générées par l’attribut title ne peut pas être sélectionné ni copié.

Inaccessible au clavier

Cela exclut également les personnes qui naviguent uniquement au clavier. Les infobulles générées par l’attribut title ne sont pas accessibles via le clavier, même sur un lien ou un élément interactif.

Inutilisable sur tablettes et smartphones

Si la navigation se fait sur une tablette ou un smartphone, il est impossible d’afficher les infobulles générées par l’attribut title.
Cela signifie que toute information uniquement présente dans cette infobulle sera totalement inaccessible sur ces terminaux.

Problèmes liés à l’utilisation de l’attribut title pour donner un nom accessible

L’utilisation de l’attribut title pour fournir un nom accessible vise principalement les personnes naviguant avec un lecteur d’écran. Bien que cette technique soit considérée comme valide par le RGAA, elle présente plusieurs limites et problèmes d’accessibilité.

Lecture aléatoire par les lecteurs d’écran selon le contexte et les réglages

Le principal problème est que l’attribut title n’est pas toujours restitué par les lecteurs d’écran² .

Par exemple, avec NVDA, le texte des attributs title présents sur un lien ou un bouton est vocalisé lorsque l’on navigue entre les éléments interactifs, mais ne l’est pas lors de la lecture linéaire du contenu de la page :

Transcription

Un extrait de page web contient le texte : « Par exemple, avec NVDA, le texte des attributs title présents sur un lien ou un bouton est vocalisé lorsque l’on navigue entre les éléments interactifs, mais ne l’est pas lors de la lecture linéaire du contenu de la page. »

Dans ce texte, « lien » est un lien et « bouton » est un bouton. La navigation commence par un déplacement d’un élément interactif à l’autre : le lecteur vocalise le contenu des éléments et leurs title. Ensuite, la navigation se fait de façon linéaire : seul l’intitulé visible est vocalisé.

Texte prononcé par le lecteur d’écran :

« lien, visité, même page, lien – Ce lien possède un attribut title avec du texte

bouton bouton – Ce bouton possède un attribut title avec du texte

Par exemple, avec NVDA, le texte des attributs title présents sur un visité, même page, lien lien ou un bouton bouton est vocalisé lorsque l’on navigue entre les éléments interactifs, mais ne l’est pas lors de la lecture linéaire du contenu de la page. »

Risque de répétitions

Lorsque vous utilisez un attribut title sur un lien qui contient déjà du texte (par exemple pour ajouter du contexte), il existe un risque de doublon.

Selon la configuration des lecteurs d’écran, le contenu du title et le texte du lien peuvent être vocalisés. Ce n’est pas bloquant, mais cela ralentit la lecture, augmente la charge cognitive et allonge le temps de restitution…

Transcription

Un extrait de page web présente un titre intitulé « Informations légales », suivi d’une liste de liens :

• Charte avis en ligne
• Données personnelles
• Informations sur les cookies
• Conditions générales de réparation du service après-vente en magasins
• Rappel produits
• Notifier un contenu illicite / sécurité
• Accessibilité : non conforme
• Digital Service Act

Lors de la navigation avec un lecteur d’écran, chaque lien est annoncé deux fois : la seconde occurrence comporte le suffixe « nouvelle fenêtre ». La souris survole ensuite deux liens pour montrer que ces secondes occurrences correspondent au contenu du title associé à ces liens.

Texte annoncé par le lecteur d’écran :

« liste de 9 éléments
Charte avis en ligne, lien
Charte avis en ligne (nouvelle fenêtre)

Données personnelles, lien
Données personnelles (nouvelle fenêtre)

Informations sur les cookies, lien
Informations sur les cookies (nouvelle fenêtre)

Conditions générales de réparation du service après-vente en magasins, lien
Conditions générales de réparation du service après-vente en magasins (nouvelle fenêtre) »

Le pire, c’est lorsque l’attribut title reprend exactement la même information que celle déjà présente dans le lien.

Problèmes de traduction et de prononciation

Certains navigateurs proposent une fonctionnalité de traduction qui ne fonctionne pas sur le contenu des attributs title.

Certains lecteurs d’écran ne respectent pas la langue définie dans la page et lisent le texte du title avec la voix par défaut du système.

Transcription

Extrait d’une page web : cette page est en anglais et contient un bouton ainsi qu’un lien.

La navigation commence par un survol des éléments interactifs pour afficher des infobulles :

• « Text explaining the button’s role placed in a title attribute » pour le bouton ;
• « Text explaining the link’s role placed in a title attribute » pour le lien.

Ensuite, le lecteur d’écran lit le texte avec une voix anglaise et un accent impeccable.

Puis, lors de la navigation entre les éléments interactifs, la voix passe en français avec un accent français, ce qui rend la compréhension difficile.

Texte prononcé par le lecteur d’écran :

Voix anglaise : Example of a page in English (the HTML tag includes a lang="en" attribute). The screen reader pronounces the technical elements in the user’s language (French in this example) and reads the text using the language defined by the page (English). If an element contains a title attribute, like this

Voix française : bouton

Voix anglaise : button

Voix française : bouton Text explaining the button’s role placed in a title attribute

Voix anglaise : link

Voix française : visité même page lien Text explaining the button’s role placed in a title attribute. visité même page lien

Voix anglaise : link. it is pronounced with a French accent

Risque d’inaccessibilité avec les logiciels de commande vocale

Une des techniques principales pour activer un lien via un logiciel de commande vocale est de prononcer le texte du lien, par exemple : « cliquer sur François-Xavier Lair ».
Si le contenu de l’attribut title ne reprend pas ce texte, il existe un risque que le lien ne puisse pas être activé par commande vocale, ce qui rend la navigation impossible pour les personnes utilisant ces assistances.

Exemple avec un lien de connexion ayant un title « Espace personnel » et un texte visible « François-Xavier Lair » :

<a href="https://exemple.com/espace-personnel" title="Espace Personnel">
    <span aria-hidden="true" class="fa-solid fa-user"></span>
    François-Xavier Lair
</a>

En résumé, l’attribut title est non seulement totalement inaccessible pour toutes les personnes qui naviguent au clavier, sur tablette ou sur smartphone, mais il présente également des difficultés pour de nombreux usages et profils.

Quelles solutions pour remplacer l’attribut title ?

Après avoir passé en revue l’ensemble des limites et des risques liés à l’attribut title, une question se pose naturellement : par quoi le remplacer ?

Dans cette deuxième partie, nous allons présenter les principales solutions, leurs avantages, ainsi que les points de vigilance à garder en tête pour garantir une accessibilité optimale.

Fournir un texte accessible

aria-label ?

L’attribut aria-label - ouvre une nouvelle page peut remplacer title, mais il présente aussi plusieurs limites :

• problèmes de traduction : comme pour title, certains navigateurs ne traduisent pas le contenu de l’attribut aria-label.
• remplacement du texte visible : aria-label substitue le texte affiché, ce qui peut entraîner les mêmes risques que title (nom accessible différent du texte visible).
• problèmes de maintenance : intégré directement dans le HTML, aria-label peut être oublié lors des mises à jour. De plus, toutes les personnes impliquées dans la production ne maîtrisent pas les mécanismes de génération du nom accessible.

Il est également important de rappeler un principe clé d’ARIA : il est recommandé de privilégier les solutions natives en HTML plutôt que d’ajouter des attributs ARIA lorsqu’ils ne sont pas nécessaires³ .

Pour approfondir le sujet, Eric Bailey l’explique en détail dans son article intitulé aria-label is a code smell - ouvre une nouvelle page.

Utiliser du texte masqué visuellement

C’est la solution la plus fiable. Elle consiste à ajouter un texte caché visuellement, mais correctement restitué par les lecteurs d’écran.
Pour cela, on utilise une classe de masquage accessible — souvent nommée visually-hidden ou sr-only — comme celles proposées par Bootstrap⁴ ou ffoodd⁵ .

<a href="https://exemple.com" class="icon-link">
    <span class="visually-hidden">Accéder à la page d’exemple</span>
    <svg aria-hidden="true" focusable="false" width="24" height="24">
        <!-- Icone SVG -->
    </svg>
</a>

Ainsi, le texte est intégré directement au contenu de l’élément HTML qu’il complète, garantissant une sémantique claire et évitant les problèmes liés à l’utilisation de title ou aria-label.

Infobulles

Passons maintenant aux méthodes permettant de remplacer l’utilisation de l’attribut title pour créer des infobulles.

Rendre l’information visible d’emblée

La solution la plus simple et la plus efficace consiste à ne pas utiliser d’infobulles : affichez l’information directement.

Souvent, l’infobulle n’est qu’une tentative de rattrapage d’un pictogramme ambigu.

Si vous pensez devoir préciser le rôle d’un pictogramme ou d’une icône via un attribut title, pourquoi ne pas l’afficher clairement ?

Combien de fois vous êtes-vous demandé : « Quel est le rôle de ce bouton ? » Combien de fois avez-vous cliqué sur un bouton composé uniquement d’un pictogramme, pour constater que l’action n’était pas celle attendue ?

Par exemple, savez-vous à quelles actions correspondent les deux icônes ci-dessous ?

Si vous connaissiez la réponse, pensez-vous que votre mère l’aurait su ? Et votre grand-mère ?

Un pictogramme peut sembler évident… mais pas pour tout le monde. Parfois, c’est culturel⁶ .

S’il vous plaît, mettez des labels à vos icônes.

Dans le même ordre d’idée, si vous utilisez des infobulles pour fournir un contexte supplémentaire, demandez-vous si cette information ne devrait pas être affichée directement, sans passer par un mécanisme caché.

Popover

Si l’usage d’une infobulle est vraiment nécessaire, autant le faire avec les éléments HTML dédiés.
L’API Popover est un nouveau standard qui permet d’afficher du contenu en superposition par rapport au reste de la page. Ce contenu peut être contrôlé à l’aide d’attributs HTML ou via JavaScript.

Implémentation de base

Placez le texte à afficher dans un élément avec l’attribut popover et un identifiant unique pour pouvoir le cibler :

<div popover id="toggletip">
    A11y est un acronyme numérique pour <span lang="en">Accessibility</span> (accessibilité en anglais)
</div>

Ensuite, utilisez un élément <button> relié à ce premier élément grâce au nouvel attribut popovertarget. Cet attribut doit contenir l’id de l’élément cible :

<button type="button" popovertarget="toggletip">
    A11y
</button>

Le popover s’affiche lorsque vous actionnez le bouton.
La touche Échap est même prise en charge pour fermer le popover.

Tester l’implémentation de base sur CodePen - ouvre une nouvelle page.

Gestion de la sémantique

L’attribut popover n’a pas de rôle intégré. Après tout, ce n’est pas un élément. Son objectif est uniquement d’ajouter un comportement de popover et peut être appliqué sur différents types d’éléments (menu, dialogue, notifications de type toast, etc.).
Il est donc nécessaire de lui attribuer un rôle. Le rôle le plus approprié est tooltip.

Cependant, ce rôle n’est pas encore pris en charge par les lecteurs d’écran. Il est donc nécessaire d’ajouter un attribut aria-describedby pour que le contenu du popover soit correctement restitué.

<button type="button" aria-describedby="toggletip" popovertarget="toggletip">
    A11y
</button>
<div popover role="tooltip" id="toggletip">
    A11y est un acronyme numérique pour <span lang="en">Accessibility</span> (accessibilité en anglais)
</div>

Tester sur CodePen l’exemple de popin avec une structure sémantique de base. - ouvre une nouvelle page.

Gestion de la souris et du clavier

Pour reproduire le comportement attendu d’une infobulle, il est nécessaire d’ajouter un peu de JavaScript afin de gérer son affichage au survol de la souris.

const trigger = document.querySelector(’[popovertarget]’);
const tooltip = document.querySelector(’[popover]’);

// Gestion souris
trigger.addEventListener(’mouseover’, tooltip.showPopover());
trigger.addEventListener(’mouseout’, tooltip.hidePopover());

// Gestion clavier
trigger.addEventListener(’focusin’, tooltip.showPopover());
trigger.addEventListener(’focusout’, tooltip.hidePopover());           

Cela permet également de corriger l’un des problèmes des infobulles générées via l’attribut title : l’absence d’affichage lors de la navigation au clavier.
L’API Popover met à disposition les méthodes showPopover et hidePopover pour cela.

Tester sur CodePen l’exemple de popin avec un JavaScript de base - ouvre une nouvelle page.

Personnalisation des styles et du comportement

Par défaut, le popover s’affiche centré dans la fenêtre.
Pour reproduire le comportement classique des infobulles — affichage à proximité de l’élément déclencheur —, il faut ajouter un peu de CSS.

Ce type de placement a longtemps été complexe à gérer (superpositions, zoom, ajustement selon la taille de la fenêtre), mais le nouveau module CSS Anchor Positioning - ouvre une nouvelle page simplifie désormais grandement cette tâche.

Il permet de positionner un élément par rapport à un autre en définissant une ancre avec la propriété anchor-name et de placer un élément en s’y référant via position-anchor.
La propriété position-area détermine comment l’élément se positionne par rapport à son ancre (au-dessus, en dessous, à gauche, etc.), et il est même possible de définir des positionnements de secours si l’espace initial n’est pas disponible, grâce à la propriété position-try-fallbacks.

[popovertarget] {
  anchor-name: --triger-tooltip;
}
[popover] {
  overflow: visible;
  position-anchor: --triger-tooltip;
  position-area: top;
  position-try-fallbacks: flip-inline, bottom, top;
}

Tester sur CodePen l’exemple de popin avec personnalisation des styles - ouvre une nouvelle page.

Ressource : tutoriel alsacréations Le positionnement par ancre : anchor positioning - ouvre une nouvelle page

Limitation actuelle : CSS Anchor Positioning n’est pas encore largement pris en charge en dehors de Chrome et Safari.
Il est donc nécessaire de prévoir une solution de secours en JavaScript pour gérer le positionnement.
La solution la plus simple consiste à utiliser une bibliothèque comme Floating UI - ouvre une nouvelle page.

Tester sur CodePen un exemple plus complet avec une solution de secours pour les navigateurs ne supportant pas CSS Anchor Positioning - ouvre une nouvelle page.

Support

Le support de l’API Popover est désormais excellent. Elle est largement prise en charge par les principaux navigateurs d’après Can I Use - ouvre une nouvelle page.

Limites de la solution

L’objectif de cet article n’est pas de fournir une implémentation générique et totalement accessible d’infobulles, mais d’alerter sur les risques liés à l’attribut title.
Les extraits de code présentés ne doivent pas être utilisés tels quels en production : ils servent uniquement de base de réflexion.

Un point de vigilance concerne la manière dont l’information est restituée aux lecteurs d’écran. Grâce à l’attribut aria-describedby, la personne qui utilise un lecteur d’écran aura bien accès au contenu de l’infobulle. Cependant, cette information sera annoncée systématiquement, alors que le reste du public peut choisir d’afficher ou non l’infobulle.

Autre limite : le lecteur d’écran restitue cet élément comme un motif plié/déplié, en annonçant « développé » ou « réduit » lorsque le bouton est activé, alors même que le contenu associé n’est pas forcément contigu.

<label for="search-input-md" class="visually-hidden">Rechercher dans le site…</label>
<input placeholder="Rechercher dans le site…" title="Rechercher dans le site…" id="search-input-md" type="search" name="texte">
<button title="Rechercher" type="submit"><span class="fr-sr-only">Rechercher</span></button>

<iframe title="Contenu publicitaire tiers" src="https://bb99d6a.safeframe.googlesyndication.com/" id="google_ads_iframe"></iframe>

Conclusion

L’attribut title peut sembler pratique pour afficher des infobulles ou fournir un nom accessible, mais, sauf rares exceptions, il reste un faux ami de l’accessibilité.

• Il n’est pas fiable pour les lecteurs d’écran.
• Sa fonctionnalité d’infobulle ne fonctionne ni sur mobile ni sur tablette, et elle n’est pas accessible au clavier.
• Il pose des difficultés aux personnes naviguant sur votre site, qu’elles soient en situation de handicap ou non.

Privilégiez des solutions inclusives :

• Affichez l’information directement lorsque c’est possible.
• Sinon, utilisez des solutions basées sur les standards HTML.

Une infobulle ne doit jamais être indispensable pour comprendre ou utiliser une interface. L’accessibilité repose sur la clarté, la visibilité et la compatibilité avec toutes les technologies d’assistance.

Pour l’année 2026 qui commence bientôt, prenez une bonne résolution : laissez l’attribut title derrière vous et adoptez des alternatives réellement accessibles pour toutes et tous.

Dans le cadre de notre mutuelle, près de 80 designers sont répartis dans différentes équipes, projets et produits. La guilde n’est pas un échelon hiérarchique : je ne suis pas manager, je ne choisis ni n’influence les projets et produits sur lesquels travaillent les designers, mais je peux (et je dois) les aider dans leur pratique.

Comme dans tout organisme qui grandit, évolue et se diversifie, la question de l’organisation se pose à un moment. Inspiré du DevOps (aide opérationnelle apportée au développement), le DesignOps s’est imposé pour améliorer la pratique du design, le ResearchOps concerne lui la recherche utilisateur. Le cadre de la guilde est un bon terrain pour mettre en place ces pratiques.

Note : il n’est pas nécessaire d’avoir vu la série The Bear pour lire cet article, mais ce serait dommage de vous en priver.

The bear, une série télévisée américaine réalisée par Christopher Storer, nous fait découvrir la vie mouvementée d’une sandwicherie familiale de quartier, et de l’arrivée de Carmy, jeune chef ayant fait ses armes dans la grande cuisine étoilée, avec l’ambition de transformer une restauration rapide moribonde, mais populaire, en établissement culinaire d'exception. Sur quatre saisons, on peut suivre les hauts et surtout les bas d’un collectif disparate, avec des histoires et des motivations différentes et les chemins pris pour atteindre un objectif commun.

On manque de tout, sauf de chaos
— Carmy, dans The Bear.

Dans notre entreprise, la guilde design existe depuis 2019 ; j’ai pour ma part pris le rôle de référent en 2023 et mon premier travail a été de bien comprendre ce qui existait, ce qu’il fallait garder, ce qu’il fallait renforcer et éventuellement ce à quoi on pouvait renoncer. Un enjeu de notre guilde est de faciliter la transversalité. En effet les designers sont regroupés au sein de trois équipes et autant de spécificités :

• La Digital Factory produit les sites, parcours et services web et mobiles destinés à nos clients et prospects.
• La DSI (direction des systèmes d'information) produit les interfaces, outils et parcours destinés aux collaborateurs et collaboratrices internes.
• Les designers de service conçoivent des parcours et services transverses, pas uniquement numériques, avec une phase de recherche et de cadrage importante.

La tentation d’unifier les outils et méthodes à marche forcée pourrait être grande, comme Carmy peut tenter de le faire en arrivant dans la cuisine de la sandwicherie, avec une efficacité mitigée. Les équipes ont déjà des pratiques en place, adaptées à leurs habitudes, avec lesquelles elles sont à l’aise, et qui « font le job ». Carmy, tout à son obsession de faire de la « grande cuisine », impose une liste de « non négociables ».

Parmi ces règles, certaines sont évidentes :

• Avoir une hygiène personnelle irréprochable.
• Plier les cartons avant de les mettre à la benne.

Mais ces règles ne sont ni suivies ni rappelées, à part par Sydney, la bonne élève.

D’autres sont de plus contradictoires :

• Changer le menu tous les jours.
• Jamais deux fois le même ingrédient.
• Éviter les surprises.
• Respecter la tradition.
• Repousser les limites.

Ces deux dernières règles pourraient s’entendre, mais ni la tradition ni les limites ne sont définies, et encore moins partagées par Carmy.

Le résultat est bien évidemment plus de chaos, plus de tensions, et ce qui fonctionnait (faire des sandwichs) ne fonctionne plus, quand ce qui est visé (faire de la grande cuisine) n’est pas pour autant rendu possible.

C'est une question de respect. C'est un hommage. On doit garder l'histoire, mec.
— Richie, dans The Bear.

Dans notre contexte, cela se matérialise par :

• Des équipes avec une ancienneté et une histoire différentes.
• Deux design systems différents.
• Des outils plus ou moins officiels et maîtrisés pour concevoir, documenter, stocker, analyser et restituer les recherches utilisateur.
• Des initiatives et compétences individuelles qui mériteraient de devenir collectives.
• Des bonnes pratiques et des templates méthodologiques pas ou peu partagés.
• Des ressources et veilles pertinentes pas ou peu mises en commun.

Je vais détailler dans la suite de cet article comment nous avons mis en place une organisation transversale des pratiques du design ces dernières années, en m’appuyant sur quelques moments clefs de la série télévisée.

Les outils, le cadre

Dans la série, Carmy vient avec un ensemble de règles et d’exigences issus de ses expériences professionnelles : des couteaux parfaitement affûtés, un espace de travail organisé et propre, des produits étiquetés. Sydney, la jeune cheffe, lui propose ensuite des modalités d’organisation pour la commande en salle (un nouveau logiciel, dans l’espoir de diminuer les hurlements entre la cuisine et le service). Le restaurant devra affronter une inspection d’hygiène qui lui vaudra l’affichage honteux d’un « C » en boutique à cause d’un paquet de cigarettes oublié sur un plan de travail et d’une aération défaillante.

Des systèmes. On a besoin de systèmes.
— Sydney, dans The Bear.

Dans notre cadre, nous avons centralisé la gestion des licences des outils, avec plusieurs personnes administratrices pour éviter le “bus factor” (conférence de Laurence Wagner à Sud Web en 2016).

Nous avons aussi rédigé des bonnes pratiques quant à l’hébergement de données sensibles, sur quelle plateforme et pourquoi, et nous évaluons les demandes de tests de nouveaux outils selon ces critères :

• Avons-nous déjà un outil disponible pour couvrir l’aspect fonctionnel ?
• Cet outil est-il sécurisé ?
• Quels sont les coûts, y compris les coûts cachés ?

Je suis moi-même « un enfant qui adore les nouveaux jouets », mais cette centralisation nous permet de maîtriser les risques, les coûts, et de pouvoir nous former entre nous en développant des expertises internes et en documentant plus simplement.

Pour la recherche utilisateur, nous avons documenté le processus pour questionner nos clients, faire appel à un panel, stocker les informations personnelles... en accord avec les services internes (achats, RGPD Règlement Général sur la Protection des Données).

Un principe : objectiver le « non négociable », sur les outils, la sécurité, les données personnelles.

L’adaptation, les marges de manœuvre

Dans la série, après plusieurs tentatives de gérer les deux types de restauration avec la même équipe, les activités de sandwicherie et de service en salle sont séparées en deux équipes, avec leurs propres méthodes de travail, leur rythme, leur gestion de stock. Les clients habituels retrouvent leur comptoir accessible depuis la rue et ce retour à la tradition n'empêche pas l'innovation : ils utilisent un drone roulant autonome pour la livraison (je crains toutefois que ce soit un placement de produit…).

Dans notre cadre, nous avons acté que deux design systems étaient nécessaires, avec leurs différences : on ne traite pas de la même manière les parcours clients finaux et les parcours collaborateurs internes, les deux n'ont pas les mêmes fréquence d'usage, expertise et courbe d'apprentissage.
Avec cette marge de manœuvre les deux équipes peuvent échanger des enseignements et des astuces de conception, apprendre l’une de l’autre, partager des ressources (styles, pictogrammes, composants) en gardant un périmètre spécifique.

Un principe : définir les communs par leur réelle utilité et accepter les adaptations nécessaires.

L’opérationnel, un appui invisible ?

Dans la série, Nathalie, la sœur de Carmy, va assurer une comptabilité globale ; elle ne cuisine pas mais donne les moyens de réalisation. Sydney, au-delà de ses talents de cuisinière, propose un cadre fonctionnel à l’équipe, et co-construit avec elle une organisation. Neil Fak, l’homme à (plus ou moins bien) tout faire, s'occupe de la tuyauterie, l'électricité, l'approvisionnement. Au bout du compte, la cuisine et le service sont les tâches visibles, appuyées par de nombreuses tâches invisibles.

On doit faire ça dans les règles, Carmy. Les licences, les permis...
— Natalie, dans The Bear.

Dans notre cadre, nous avons mis en place un dépôt de recherche pour centraliser la connaissance utilisateur, organisé dans un index.
Pour mieux rechercher et croiser ces ressources, nous avons construit des agents de recherche utilisant l’intelligence artificielle générative (des RAG, plus précisément).
Pour aider à la phase de restitution d’une recherche, nous avons conçu (via des ateliers de mise en commun de nos meilleures pratiques) un template documenté et disponible dans Figma et Powerpoint, pour s’adapter aux cas d’usages et aux habitudes.

Nous avons mis en place un onboarding pour les nouvelles et nouveaux designers, pour leur présenter les différentes ressources et outils disponibles dans la guilde (un trombinoscope, une liste d’outils, un historique du design dans l’entreprise…) et leur permettre de rencontrer d’autres designers.

Ouverture et curiosité, une culture commune

Dans la série, le principal problème du collectif est la communication. La première saison est une succession de scènes d'engueulades, de hurlements, d’incompréhensions. Carmy veut imposer sa vision de la restauration, comme une vengeance personnelle, pour réparer une blessure narcissique (son frère décédé ne lui avait pas fait la place qu’il attendait dans le restaurant familial). Richie, le « cousin » colérique, est réfractaire à tout changement, malgré les besoins évidents d’évolutions. Il craint en particulier la perte de la culture et de l’histoire du restaurant familial dans le quartier. Tina, la cuisinière, a du mal à suivre le rythme et les nouvelles méthodes amenées par Carmy et Sydney et va se fermer et se vexer.

Dans la deuxième saison et la troisième saison, les personnages vont évoluer en allant vivre des expériences à l’extérieur du restaurant : Richie va suivre une formation de service en salle dans un restaurant étoilé ; il en reviendra avec des nouvelles compétences utiles et surtout une confiance en soi dont il avait besoin. Marcus, le boulanger, va se former à la pâtisserie auprès d’un grand chef (Luca) au Danemark. Tina et Ebraheim vont suivre une formation en école de cuisine.

Je veux juste savoir ce que tu fais. Tout. Je veux juste apprendre, tu vois ?
— Marcus à Luca, dans The Bear.

Dans notre cadre, nous avons mis en place des temps d’échanges internes et des ouvertures vers l'extérieur. Voici quelques actions :

• Des « vis ma vie » entre les trois équipes, dont les enseignements ont été partagés au collectif. L’occasion de mieux identifier ce que nous pouvions améliorer ensemble (la documentation commune, les temporalités d’interventions différentes entre le design de service, parfois très en amont des projets, et le design numérique, en fin de course).
• Les « cafés les designers », moments d'échanges informels et sucrés.
• Les « pitch design » des retours d’expérience et présentations de travaux.
• Les « crousty conférences », des conférences en vidéo autour d’un déjeuner.
• Des visites internes et externes (le studio vidéo, le service d’aménagement des locaux, un laboratoire de test autour de la prévention…).
• Une veille collaborative.

Nous pouvons parfois faire intervenir des designers extérieurs, pour des événements internes comme pour des événements ouverts au public : deux éditions de la France Design Week : 2023 et 2024.

En externe, nous sommes sponsors d’événements comme les UX Days, les UX Camp de FLUPA, Paris Web.

Nous encourageons les designers à y participer, en tant que public mais aussi en tant que speakers ou en proposant des ateliers.

Nous avons aussi un blog collaboratif, qui regroupe des articles autour du développement, de la data et du design.

Les designers peuvent participer à des podcasts ou des interviews externes, comme Ines Khoudja ou Cécile Couetard.

Un principe : décentrer son regard est souvent un bon moyen d’y voir plus clair.

Designer est un métier, mais il regroupe plusieurs rôles, compétences, postures : pilote, lanceur d’alerte, chamboule-tout, outilleur, artisan… Dans The Bear, chaque personnage incarne une posture :

• Carmy, le visionnaire obsédé par la qualité → le pilote.
• Sydney, la stratège qui structure → l’outilleuse.
• Richie, qui découvre la haute gastronomie → l’explorateur.
• Natalie, la facilitatrice invisible → la DesignOps.
• Marcus, l’artisan passionné → le créatif centré sur la qualité de réalisation.

Chacun de ces personnages, à un moment de la série, a « raison tout seul », mais les avancées et résolutions viennent toujours des moments de collaboration, qui passent par une observation honnête des dysfonctionnements et la prise en compte des intérêts, expertises et attachements symboliques des individus.

Je crois qu'on pourrait être bons ensemble.
— Sydney à Carmy, dans The Bear.

Si notre contexte professionnel est loin de celui d’un restaurant de quartier et que les tensions dans la série sont extrêmes et s'incarnent dans une histoire familiale, je suis sûr d’une chose après ces deux années passées sur les sujets de DesignOps, ResearchOps et animation d’un collectif : les bonnes réponses sont celles qui émergent de nos échanges.
Les outils, processus et méthodes ont plus de valeur lorsqu’ils sont construits et validés ensemble que lorsqu’ils sont imposés. Pour ça, le meilleur moyen est de trouver ses allié·es, sa « meute » comme dirait Tamara Sredojevic (ou sa brigade, pour rester dans le culinaire).
Il nous reste bien sûr bien plus de travail à faire que ce qui a été fait, et l’avenir apportera son lot de chamboulements, de nouveaux outils qu’il faudra cadrer (coucou l’IA générative qui rentre par les portes, les fenêtres et les robinets…) mais nous ferons en sorte d'aborder les enjeux de façon collective.

Ce sera mon conseil, en conclusion : prenez soin de vos communs ! c'est vrai en design comme dans tout collectif.

Quelques ressources :

• DevOps : histoire et origines.
• Design Ops : le guide issu de mon retour d'expérience.
• Design Ops : et si on redevenait créatif.
• Le Design Ops, designer pour les designers.
• The Bear, pourquoi Carmy échoue à sauver son restaurant.

Il y a cinq ans, on m'a diagnostiqué une cataracte précoce sur mes deux yeux. Quand je l'ai découvert, j'ai été stupéfaite car je pensais que seules les personnes âgées pouvaient être concernées. J'avais vu mes grands-parents et mes parents se faire opérer de la cataracte. Et moi je suis jeune, dans ma trentaine.

J'ai eu envie d'écrire cet article pour raconter les conséquences de cette maladie sur mon utilisation du web et de comment ça a changé mon regard de professionnelle.

Qu’est-ce que la cataracte ?

Selon Ameli :

La cataracte est une opacification de tout le cristallin ou d'une partie de celui-ci, altérant la vision et responsable d’une diminution de la qualité de la vie. Elle peut apparaître dans un œil mais en général, elle affecte les deux yeux. On parle de cataracte lorsque la correction optique par des lunettes n'est plus suffisante pour corriger la gêne visuelle..

Lorsqu'elle évolue et qu'elle n'est pas traitée chirurgicalement, la cataracte entraîne une baisse progressive et irréversible de la vision.

Toujours selon Ameli, la cataracte touche plus de 20 % de la population après 65 ans et plus de 60 % des personnes après 85 ans. Je n'ai pas trouvé de chiffres concernant ma catégorie d'âge mais, ayant cette maladie, je ne peux que constater que la cataracte ne touche pas que les seniors.

On ne peut pas pour l'instant m'opérer pour des raisons médicales. Du coup, j'ai appris à vivre avec. Avec le temps, j'ai constaté quelques répercussions au fur et à mesure que la cataracte évoluait.

Il existe plusieurs formes de cataracte. Celle que j'ai diffère celle de mes grands-parents et parents, qui n'ont pas rencontré les mêmes problèmes que moi. Pour eux, c'était les couleurs qui devenaient fades et ils ne s'en rendaient pas compte. Pour ma part, les symptômes sont différents.

Les conséquences de ma cataracte

J'ai développé une photophobie, une grosse sensibilité à la lumière. Petit à petit, j'ai dû mettre le thème sombre sur toutes mes applications, car le thème clair me fait très mal aux yeux et me donne parfois des migraines si je l'utilise trop longtemps.
Pendant un temps, je ne pouvais pas rester trop longtemps sur l'application mobile de LinkedIn parce qu'il n'y avait pas de thème sombre et le thème clair me gênait fortement. Quand le thème sombre est arrivé, ça m'a soulagée !

Je sais qu'il y a un gros débat entre le thème clair et le thème sombre¹ . Étant directement impactée, je pense que les deux doivent être proposés sur les sites afin de donner le choix à l'utilisateur ou à l'utilisatrice en fonction de ses besoins. Nous ne savons jamais qui est derrière l'écran.

J'ai un ami sourdaveugle qui, lui, préfère le thème inversé ! Ni le thème clair, ni le thème sombre. Il se sent plus à l'aise quand il voit le texte en jaune avec un fond bleu² . Il perçoit mieux le texte lorsque tout est en couleurs vives car le texte se distingue alors plus facilement.

J'avais découvert l'extension Dark Reader qui me permet d'afficher, par défaut, les sites en version sombre, même quand ils n'ont pas prévu ce thème. C'est très pratique mais n'est pas une solution miracle. Comme tout outil, il a parfois des ratés. Parfois, il rend le texte totalement illisible en appliquant des couleurs insuffisamment contrastées.
Un jour, j'avais fait un copier-coller d'un texte. Étant en thème sombre automatiquement, je voyais le texte en blanc et j'avais envoyé le mail. On m'a répondu que le texte était illisible. Effectivement, quand j'ai désactivé Dark Reader, le texte sous le fond blanc était en gris très clair. Pour m’en rendre compte, il aurait fallu que je vérifie que le texte reste lisible sans le plugin. Ainsi, cette extension a beau m'aider, elle m’impose une charge de travail supplémentaire.

Sur mon iPhone, configuré sur l'apparence sombre, j’utilise la fonctionnalité Afficher le lecteur quand je consulte un article qui n’a pas de thème sombre sur Safari. Le lecteur n'affiche que le texte, blanc sur un fond sombre, et les images. Cette fonctionnalité m’aide beaucoup et me permet de lire confortablement le contenu de la page. Je peux aussi aussi masquer les animations qui me gênent.

Avec ma cataracte, je me suis rendue compte que naviguer sur Internet présente quelques défis. Je suis régulièrement confrontée aux mêmes erreurs d’accessibilité :

• si le texte n'est pas suffisamment contrasté, je le distingue très mal et j'ai des difficultés à le lire ;
• si le texte ou la page est d'une couleur très vive, j'ai tout de suite une gêne oculaire ;
• si les animations défilent à toute vitesse avec les couleurs éclatantes, cela me gêne énormément ;
• si la page est toute blanche, j'ai une fatigue oculaire et une migraine qui se présentent au bout d'un petit moment.

Avant ma cataracte, je n'avais pas du tout ces soucis !

Sous-titres

Sur les réseaux sociaux, je ne supporte plus les vidéos sous-titrées n'importe comment. Quand les sous-titres ne sont pas suffisamment contrastés, sont de couleurs vives ou clignotent dans tous les sens, je zappe.

Pour l'édition 2019 des 24 jours de web, j'avais écrit l’article Comment bien sous-titrer vos vidéos ? À cette époque, il n'y avait pas ces effets. Les sous-titres étaient principalement en blanc avec un bandeau noir ou sans bandeau avec des contours noirs sur les caractères.

Puis, une mode pour animer les sous-titres est arrivée afin de rendre la vidéo « plus attractive ». En 2023, j'avais écrit un nouvel article Comment continuer à bien sous-titrer vos vidéos ? sur mon blog en constatant qu'avec ma cataracte je ne supportais plus les effets spéciaux sur les sous-titres. Ces effets me donnent des migraines et des gênes oculaires. Ils sont particulièrement distrayants, ce qui empêche de bien se concentrer sur le contenu de la vidéo.

Les sous-titres « ennuyeux » restent le meilleur moyen pour rendre les vidéos accessibles à tous et toutes.

Liquid Glass

J'ai un autre exemple tout récent avec la nouvelle interface des iPhones : Liquid Glass. Jusque-là, Apple était à la pointe sur les questions d'accessibilité. Quand Liquid Glass est arrivé avec ses interfaces ultra-transparentes avec effets de flou et d'animation, c'était une grande déception et surtout une régression en termes d'accessibilité. Tout d'un coup, mes écrans étaient transparents. Je discernais très mal les textes blancs sur les fonds transparents. L'illusion optique me perturbait.

J'ai dû modifier mes réglages dans les paramètres d'accessibilité (Réglages > Accessibilité > Affichage et taille du texte) pour réduire la transparence et augmenter le contraste. J'ai même coché « boutons avec contours » car je ne discernais plus les boutons.

Vous pouvez constater l'avant et l'après des réglages sur ces images :

La différence est très flagrante.

Ces changements ont été déstabilisants, il a fallu que je me réhabitue à ces réglages. D'ailleurs, je ne suis pas la seule à être perturbée par le Liquid Glass. De nombreux utilisateurs et nombreuses utilisatrices n'ayant pas forcément de handicap visuel ont critiqué la nouvelle interface parce qu'ils ne voyaient plus les textes à cause de leurs fonds d'écrans.

En appliquant ces paramètres, ça a eu un impact sur les applications qui n'ont pas pensé à les prendre en compte, comme le montrent ces photos avant/après lorsque je tente de choisir Sophie pour lui écrire un SMS :

Après ces retours très critiques, Apple a décidé d'ajouter une nouvelle option teintée pour Liquid Glass dans la version d'IOS 26.1. Cette option ne peut pas être appliquée si on a les réglages « réduire la transparence » et « augmenter le contraste » cochés.

Malheureusement, la version teintée n’a corrigé qu’une partie du problème. Les notifications sont maintenant en version sombre se calant sur mon réglage « apparence sombre » par défaut alors qu'avant, c'était totalement transparent. Par contre, les groupes des icônes d'applications restent transparentes. Pour éviter ça, j'ai décoché la version option teintée et j'ai coché uniquement « réduire la transparence » pour éviter la transparence de ces groupes d'icônes. Comme l'apparence sombre est maintenant prise en compte sur mes notifications, je n'ai plus eu besoin de cocher « augmenter le contraste ». Je reste mitigée.

Surcouche d'accessibilité

Qu'est-ce qu'est un outil de surcouche d'accessibilité ? Voici une définition claire de l'agence Boscop :

Les surcouches d’accessibilité sont des applications qui s’intègrent sur un site existant, pour en modifier l’affichage, selon les paramètres choisis par l’utilisateur. Elles s’installent comme un simple plug-in ou module complémentaire, avec un script intégré dans le code. Les fonctionnalités de ces outils permettent donc de personnaliser l’affichage des pages, par exemple en accentuant le contraste des couleurs ou en agrandissant la taille du texte.

J'ai évidemment testé certains outils de surcouche d'accessibilité pour mettre le thème sombre ou utiliser l'option cataracte. Cela ne m'a pas du tout aidée.

Sur certains sites ayant ces outils, en appliquant les options, cela donne des résultats un peu bizarres.

Par exemple, l'option thème sombre devrait être appliquée sur toute la page. Au lieu de ça, ce n'est appliqué que sur les paragraphes et titres. Souvenez-vous, le blanc me gêne. Une mixité du noir et du blanc comme vous pouvez le constater sur cette capture d'écran n'aide pas.

De plus, il y a quelques soucis de contrastes.

Je préfère largement utiliser l'extension Dark Reader, qui bien qu'imparfaite est plus efficace que les surcouches d'accessibilité. D'autant que les surcouches d'accessibilité ne sont pas conformes au Référentiel général d’amélioration de l’accessibilité (RGAA), elles ne permettent pas de rendre accessible un site internet dans sa globalité.

Nouveau regard sur l’accessibilité numérique

Ces obstacles m'ont permis d'aborder l'accessibilité numérique d'une autre manière parce que j'ai été directement impactée. En accessibilité numérique, on met souvent l’accent sur les lecteurs d’écrans ; mais ça ne se résume pas à ça.

Quand j’ai commencé ce métier, je ne pouvais pas prévoir que j’aurais la cataracte. Ce handicap temporaire a changé ma façon de naviguer sur Internet.

J’étais déjà très attentive à l’accessibilité numérique mais je le suis encore plus depuis que j'ai la cataracte. Cela m’a fait prendre conscience que tous ces critères du RGAA ont une utilité. Il y a une centaine de critères à respecter et je trouvais cela très fastidieux. Avec du recul, je sais que c'est nécessaire parce qu'ils permettent de couvrir l'ensemble des handicaps et des besoins. Quand une personne débute dans l'accessibilité numérique, tomber sur une centaine de critères peut être décourageant. C'était le cas à mes débuts.

Selon l'Observatoire du respect des obligations d'accessibilité, seulement moins de 5 % des sites web sont accessibles pour les personnes handicapées et selon WebAIM, l'erreur la plus fréquente est le manque de contraste sur les textes !

En voyant tous ces chiffres, en tant que développeuse, je n'hésite plus à partager mon expérience. Ça a renforcé ma détermination à sensibiliser les acteurs et actrices du web sur la nécessité de rendre accessibles les sites web à tous et toutes et de collaborer avec ces personnes. Ce ne sont pas l'intelligence artificielle, les extensions comme Dark Reader ou les surcouches d'accessibilité qui vont corriger les erreurs d'accessibilité sur les sites web.

Conclusion

L'accessibilité ne doit pas être une option mais une nécessité surtout qu'elle concerne douze millions de personnes handicapées³ sans compter les personnes âgées et les personnes en difficulté avec le numérique (illectronisme). Face à internet, il est important de ne pas se retrouver en situation de handicap⁴ .

Chaque critère RGAA a du sens. Il est nécessaire de ne pas en négliger car le handicap, qu’il soit permanent ou temporaire, peut survenir n’importe quand chez n’importe qui. Je ne m'attendais pas à développer une cataracte si tôt et pourtant elle est là, présente jusqu'à une opération qui se fera le moment venu. Je n'aurais pas besoin de toutes ces adaptations si le web était totalement accessible.

Je plaisante en disant que, grâce à ma cataracte, j'ai développé un nouveau super-pouvoir : je repère tout de suite les mauvais contrastes en consultant un site internet. Pas besoin de vérifier si c'est conforme, mes yeux font le boulot.

Techniquement, un Web Component repose sur trois autres standards : les custom elements¹ qui permettent de définir de nouvelles balises ; les HTML templates² qui servent de base à leur structure ; et le shadow DOM³ qui encapsule et isole le style et la logique interne du composant.

Cette isolation est une force, elle garantit qu’un composant ne sera pas impacté par les styles externes. Mais elle complique également la tâche des scripts qui veulent interagir avec le contenu encapsulé.

Lors de ma conférence « Les Web Components et l’accessibilité » à Paris Web, j’ai évoqué le fait que certains outils d’accessibilité ne détectent pas les éléments présents dans le shadow DOM.
Plusieurs personnes m’ont ensuite demandé comment faire pour corriger ça dans leurs propres scripts. Cet article est l’occasion d’y répondre plus en détail.

Les particularités du shadow DOM

Le contenu d’un Web Component n’est pas directement accessible avec des sélecteurs habituels comme document.querySelector.
Pour accéder au contenu d’un Web Component, il faut d’abord cibler l’élément, puis explorer son shadowRoot :

// Pour accéder au shadow DOM du custom element <24-jours-de-web>
const element = document.querySelector('24-jours-de-web');
const shadow = element.shadowRoot;

Mais attention, cela ne fonctionne que si le shadow DOM a été créé en mode open. En mode closed le contenu restera inaccessible.⁴

Dans la suite de l’article, nous partirons donc du principe que les composants utilisent un shadow DOM open.

Parcourir les Web Components dans un script

Pour illustrer la prise en compte des Web Components dans vos scripts, partons d’un cas simple : récupérer tous les champs <input/> présents dans une page.

Le cas classique

Quand aucun Web Component n’est utilisé, les éléments sont directement présents dans le DOM principal.
Dans ce contexte, un sélecteur CSS classique suffit :

const inputs = document.querySelectorAll('input');

Avec des Web Components

Les choses se compliquent lorsque des input se retrouvent encapsulés dans un shadow DOM.
Dans ce cas, document.querySelectorAll('input') ne les verra pas.

Pour résoudre le problème, il faut d’abord être capable d’identifier les Web Components présents dans la page.

Identifier les Web Components

Pour éviter les conflits avec les balises HTML natives, le nom d’un Custom Element doit obligatoirement contenir un tiret (-).
C’est une règle du standard et c’est aussi un moyen simple et fiable de les détecter.

const findCustomElements = () => {
  // On recherche tous les éléments de la page
  return [...document.querySelectorAll('*')].filter(elm => {
    // On ne retourne que ceux dont la balise contient un tiret
    return elm.tagName.includes('-');
  });
}

Cette fonction renvoie tous les Web Components présents dans le DOM principal mais pas leur contenu, qui reste encapsulé dans leur shadowRoot.

Parcourir leur shadow DOM

Une fois un Custom Element détecté, il faut vérifier qu’il possède un shadow DOM, puis s’assurer qu’il est en mode open, condition indispensable pour y accéder depuis un script externe :

const findInputsInShadow = (element) => {
  // Si pas de shadowRoot (ou en mode closed), on s’arrête là
  if (!element.shadowRoot) return [];
  // À partir d’ici, on peut interroger librement le contenu du shadow DOM
  return [...element.shadowRoot.querySelectorAll('input')];
}

Cette approche fonctionne, mais uniquement à un niveau d’imbrication.

C’est une situation plutôt courante, un composant peut en contenir un autre, qui lui-même en contient un autre, etc. Et chacun possède potentiellement son propre shadow DOM.
Il faut donc répéter ce travail à chaque niveau, ce qui impose une approche récursive.

Récupérer tous les input, dans le DOM et dans tous les shadow DOM

Pour couvrir tous les cas, il faut récupérer les champs présents dans le DOM principal et ceux encapsulés dans les shadow DOM accessibles.
On peut commencer par écrire une première fonction capable de descendre dans tous les niveaux d’imbrication :

const findAllInputs = (root = document) => {
  // Inputs visibles à ce niveau du DOM
  const inputs = [...root.querySelectorAll('input')];

  // Web Components présents à ce même niveau
  const customElements = findCustomElements(root);

  // Pour chaque Web Component, on accède au shadowRoot
  for (const element of customElements) {
    if (!element.shadowRoot) continue;
    inputs.push(...findAllInputs(element.shadowRoot));
  }
  return inputs;
};

Cette première étape permet déjà de retrouver tous les input de la page, même ceux encapsulés dans des Web Components.
Mais on peut aller plus loin et généraliser le principe, pourquoi se limiter aux champs ?

Vers un deepQuerySelectorAll()

L’idée suivante découle assez naturellement, écrire un équivalent de document.querySelectorAll(), mais capable de traverser tous les Shadow DOM, quels que soient leur profondeur ou leur nombre.

La structure va être la même que précédemment, mais on remplace simplement le sélecteur 'input' par n’importe quel sélecteur CSS passé en paramètre :

const deepQuerySelectorAll = (selector, root = document) => {
  // Éléments trouvés dans le DOM courant
  const results = [...root.querySelectorAll(selector)];

  // Détection des Custom Elements déjà écrite plus haut
  const customElements = findCustomElements(root);

  // On explore chaque Shadow DOM accessible
  for (const el of customElements) {
    if (!el.shadowRoot) continue;
    results.push(...deepQuerySelectorAll(selector, el.shadowRoot));
  }

  return results;
}

Avec cette nouvelle fonction, on peut par exemple récupérer tous les boutons d’une page, y compris ceux encapsulés dans le Shadow DOM. Exactement comme on le ferait naturellement avec document.querySelectorAll().

const buttons = deepQuerySelectorAll('button');

Et le querySelectorDeep() ?

La suite logique serait de proposer l’équivalent de document.querySelector(), qui s’arrête au premier résultat.
Je ne vais pas m’attarder dessus, le principe est le même et je pense que l’idée générale est désormais claire.

Pour rendre tout cela plus pratique, j’ai regroupé ces fonctions dans une petite librairie dédiée : @dume/webcomp-utils.

Voici à quoi cela ressemble :

import { deepQuerySelectorAll, deepQuerySelector } from '@dume/webcomp-utils';

const emailInput = deepQuerySelector('#email');
const fields = deepQuerySelectorAll('.field');

Conclusion

Maintenant que vous avez toutes les clés pour parcourir les Web Components, n’oubliez pas qu’un shadow DOM n’est accessible que s’il est en mode open. En closed son contenu reste totalement isolé et aucun script extérieur ne pourra le toucher.

L’isolation apportée par le shadow DOM est volontaire, elle protège le composant et garantit qu’il ne sera pas perturbé par des styles ou scripts externes. Les fonctions que nous avons vues permettent d’accéder au contenu encapsulé, mais elles ne sont pas destinées à le modifier. Utilisez-les avec précaution.

Avec ces outils en main, vous pouvez désormais aller mettre à jour vos scripts et interagir avec vos Web Components comme si l’encapsulation n’existait pas. 😉

• en tant que salariée chargée de prévention des risques professionnels¹ , j'aide le collectif à améliorer ses conditions de travail pour, in fine, réduire l’impact du travail sur la santé des salarié·es ;
• en tant qu’étudiante en master 2 de sociologie « santé et conditions de travail » de l’université de Nantes, j’observe le collectif avec des lunettes de sociologue pour rédiger un mémoire de recherche.

Une structure autogestionnaire

Dans la promotion du master, nous sommes toutes et tous ou presque en alternance, avec cette double casquette. Mes camarades travaillent pour des collectivités locales, un entrepôt logistique ou de l’agroalimentaire… Et moi dans une coopérative sans chef·fe où chaque salarié·e travaille de façon autonome pour des client·es.

Mais, comment ça peut marcher ?
— Certaines de mes camarades, dubitatives.

Concrètement, au sein de Codeureuses en liberté, tout le monde sauf moi :

• travaille comme indépendant·e pour des client·es en tant que prestataire informatique (en développement, design...) ;
• est salarié·e en contrat à durée indéterminée de la structure Codeureuses en liberté, qui le ou la rémunère en fonction de ce qu’iels facturent, mais aussi de mécanismes de solidarité internes à la coopérative ;
• est sociétaire et a donc un droit de vote dans la gouvernance de la structure suivant le principe « une personne = une voix ».

Au-delà du vote, on essaye de faire émerger des consensus dans la mesure du possible. Il n’y a pas d’organigramme. Nous avons un·e président·e par obligation légale, qui change tous les ans et n’a pas de pouvoir.

Nous travaillons de chez nous, dans des espaces partagés ou dans les locaux de la structure cliente. Nous gardons des liens avec les autres membres de Codeureuses en Liberté via des outils collaboratifs en ligne, mais aussi des temps synchrones (un tour de table hebdomadaire pour savoir qui fait quoi, une demi-journée mensuelle pour avancer les chantiers de la coopérative et un ou deux séminaires par an). On l’aura compris, le terme « liberté » n’est pas choisi par hasard dans le nom de l’entreprise.

Comme l’un de nos buts est de valoriser et d’expliquer au maximum le modèle coopératif auprès des travailleureuses du numérique, nous avons aussi créé CodeCodeCoop, où vous pouvez trouver des ressources et des témoignages sur le sujet ² .

Pas de subordination, pas de souffrance ?

Les premiers jours, j’ai été accueillie par une visio d’accueil conviviale. Le hasard du calendrier a fait que j’ai pu enchaîner plusieurs temps synchrones avec les autres salarié·es. C’était super, j’étais portée par l’enthousiasme, les chouettes rencontres et puis… Le lundi suivant est arrivé, je pouvais m’organiser comme je voulais, le Mattermost (outil libre de conversation instantanée) était particulièrement peu bavard et… je me suis sentie terriblement isolée.

Parce que l’isolement, dans les structures comme la nôtre où éloignement géographique rime avec autonomie, c’est un problème ! Je le savais, mais ce n’est pas exactement la même chose de le vivre (observation participante, vous vous rappelez ?).

Heureusement, plusieurs facteurs m’ont permis de ne pas rester seule.

Mon potentiel isolement était au sein de Codeureuses en liberté un sujet d’inquiétude, nous en avions beaucoup parlé en amont de mon alternance. Je savais donc que c’était une problématique liée à la structure et non à ma personne. Ça faisait par ailleurs écho à des cours que je pouvais avoir à l’université, sur le fait que — sociologie oblige — les risques professionnels sont analysés comme des questions collectives et systémiques, liées aux organisations et non aux individus.

Par ailleurs, Codeureuses en liberté est un projet qui dès le début, a été pensé comme un espace d’expérimentation pour les travailleureuses qui le composent, avec la volonté de documenter le processus au maximum. On me l’a présenté comme « l’entreprise dont vous êtes l’héroïne » et je l’ai moi aussi abordé de la même manière : étant moi-même soumise à des risques professionnels, j’ai pris ma propre situation comme exemple à documenter et à analyser.

Je me suis sentie légitime donc à exprimer mes difficultés et mes besoins, notamment le fait qu’il me faut plus de temps synchrones et/ou en présentiel que ce qui était envisagé au départ.

Rendre collectifs les enjeux de santé au travail

On le voit au travers de cet exemple : au sein de Codeureuses en liberté, la question de la santé au travail repose avant tout sur une responsabilité individuelle. C’est moi qui ai identifié que j’étais isolée, qui l’ai partagé avec les autres salarié·es et qui ai proposé une piste de résolution. Tout cela a été accueilli avec écoute et bienveillance et on a trouvé des solutions pour diminuer mon isolement. Il n’existe pas de cadre collectif formalisé sur les risques professionnels, mais des espaces de discussion où le sujet est légitime et une envie partagée de mieux faire.

Le rôle que je me suis donné, avec mes outils de préventrice et d’apprentie sociologue, est de rendre ces questions collectives. Pour mener à bien cette mission, je me suis d'abord intéressée au cadre réglementaire.

L’employeur a des obligations concernant la sécurité et la santé des salarié·es. Cela s’incarne notamment dans un document obligatoire³ qui porte le doux nom de DUERP (document unique d’évaluation des risques professionnels), où sont recensés l’ensemble des risques auxquels sont exposé·es les travailleureuses et les actions prévues pour les prévenir.

Depuis les années 1970, où l’amélioration des conditions de travail est montée en force grâce notamment à la CFDT⁴ , la santé et la sécurité au travail sont devenues plus visibles. Mais cette dynamique s’est accompagnée d’une redéfinition de la prévention. Les métiers de la santé et de la sécurité au travail sont devenus pour beaucoup des métiers gestionnaires, où il faut formaliser, documenter, quantifier, auditer, tandis que le pouvoir des salarié·es dans les organisations a baissé ⁵ .

De mon côté, j’aborde ma mission en me demandant comment je peux donner du pouvoir aux salarié·es et améliorer leurs conditions de travail. J’ai proposé que la formalisation du DUERP soit un des livrables de mon alternance. Pourquoi, alors que je critiquais les dynamiques gestionnaires juste au-dessus ? Parce qu’un outil n’est pas neutre et qu'on peut tout à fait utiliser sa rédaction comme une excuse pour mettre le sujet sur la table et sortir de l'invisibilisation des risques (« on n'est pas exposé·es car on ne manipule pas de machine dangereuse ») ou de leur naturalisation (« ça fait partie des risques du métier »). Mais pour cela, certaines conditions sont indispensables : il faut que son contenu soit réfléchi avec les salarié·es et il est indispensable de partir du travail réel (ce que font les travailleur·euses et non le cahier des charges d’un client).

Et alors, vos risques, à Codeureuses en liberté ?

J’ai animé un atelier lors d'un séminaire il y a quelques semaines. Son but était de commencer à lister les risques auxquels les salarié·es de Codeureuses en liberté sont exposé·es et d’en faire un temps d’échange et de débat sur ce sujet.

Pour commencer, chacun·e a été invité·e à lister les différents risques auxquels iel pense être exposé·e. Je leur ai proposé de prendre une dizaine de minutes pour cela, pour que chacun·e ait la possibilité de partir de sa propre situation. Le groupe a ensuite posé ses post-it en tentant de les regrouper et en expliquant aux autres ce qu’il avait écrit.

Je galère à jongler quand j'ai plusieurs missions, mais avec la vie perso et potentiellement les trucs de la coopérative, (...) régulièrement, je galère à m'en sortir.

Il y a des fois, il y a des projets où on perd un peu le lien avec les utilisateurs finaux et on développe un peu dans le vide. Et puis, des fois, un truc un peu de bore-out où t'as l'impression de travailler un peu dans un vide total et je pense que ça rejoint un peu les trucs de dépression où ça te met dans un endroit qui est pas agréable.

Je trouve qu'on fait tous un peu le même métier, on est tous un peu dans le même secteur. Et donc là on sent un peu la crise économique ou le resserrement des budgets de plein de gens. Il y a des questions sur l'intelligence artificielle qui peut pousser certaines boîtes à virer des gens. Qu'est-ce qui se passe si collectivement on se retrouve dans un secteur beaucoup moins porteur qu'avant ? On sait qu'on a de la solidarité entre nous mais ça ne fonctionne que si c'est quelqu'un qui a un coup de mou mais pas si tout le monde est en galère.

Au final, quatre thèmes se sont dessinés :

• un autour du stress financier ;
• un sur l’isolement et le télétravail ;
• un autour des risques physiques, comme les troubles musculo-squelettiques, la fatigue visuelle ou les accidents de vélo ;
• un autour du stress lié au boulot : charge mentale, urgences, manque de sens…

Pour construire l’atelier, je me suis beaucoup appuyée sur le site de l’INRS (Institut national de recherche et de sécurité), association adossée à la Sécurité sociale dont le rôle est de prévenir les accidents du travail et maladies professionnelles, et celui de l’ANACT (Agence nationale pour l'amélioration des conditions de travail), qui dépend du ministère du Travail. J’ai galéré à trouver des outils adaptés à la réalité de Codeureuses en liberté, qui n’est pas une boîte « normale » : pas de liens de subordination, une autonomie très forte et plusieurs collectifs de travail (les projets chez leurs clients, la coopérative…). Aucun outil clé en main ne pouvait s’utiliser tel quel : j’ai donc pioché dans les ressources relatives aux petites entreprises, aux indépendant·es, au travail sur écran et au télétravail. J’ai adapté le questionnaire Faire le point pour aller un peu plus loin sur les risques psycho-sociaux.

Cela a permis de se raconter pas mal de choses, c’était un moment très chouette, on a bien ri. J’ai vu comment des termes qui peuvent s’appliquer à n’importe quelle situation de travail — comme la charge de travail, la surveillance des travailleureuses ou les exigences émotionnelles — étaient discutés. Le questionnaire a fait ressortir sans surprise que parmi les facteurs de risques, l’insécurité de la situation de travail prime sur le reste. Cela a permis aussi de commencer à poser les premières réflexions sur une différenciation des risques : une DevOps va avoir plus de pression liée aux urgences, un junior sera potentiellement plus en difficulté pour hiérarchiser ses priorités, avoir du recul sur les directives reçues et donc gérer sa charge de travail, une personne qui vient de finir une mission et en cherche une autre va avoir plus de stress financier…

Si t'es débutant, jeune, tu as peut-être tendance à prendre trop sur toi, à vouloir faire les choses qu'on te demande de faire et plus tu prends l'expérience, plus tu sais organiser, dire « cette tâche-là est prioritaire par rapport à l'autre », « elle est vraiment importante à faire tout de suite », « celle-là elle peut attendre », « elle peut être déléguée », du coup elle te stresse moins et tu peux rassurer tes clients par rapport à ça.

Au cours de cet atelier, nous avons au final assez peu abordé les risques internes à la coopérative, autour de la gouvernance ou de la gestion au quotidien de la structure. Cela fera partie des éléments que la suite de mon alternance va approfondir.

Et si vous parliez travail ?

Peut-être que ce billet vous a donné envie de creuser le sujet de la santé au travail et d’en parler avec vos collègues, pairs, copaines… Si tel est le cas, voici quelques idées pour alimenter votre réflexion :

• Vous pouvez organiser des temps de discussion comme nous l’avons fait. L’essentiel est d’avoir un cadre collectif qui garantit la confidentialité des échanges et pas de liens hiérarchiques entre vous.
• Les syndicats sont des outils puissants de mise en commun de ces problématiques et de formation ! Cécile et Thomas expliquent dans ce billet pourquoi se syndiquer dans l’informatique.
• L’INRS propose un MOOC sur les bases de la santé et sécurité au travail et je vous le recommande chaudement ! Il a été conçu pour des personnes n’ayant pas de connaissances sur le sujet et permet de faire un tour d’horizon des liens entre santé et travail, ce que sont les accidents de travail ou les maladies professionnelles et d’acquérir des bases en prévention.
• Mais surtout, vous pouvez participer à la démarche initiée au sein de Codeureuses en liberté que nous voulons le plus collective possible !

Je vais publier au fur et à mesure mes travaux et réflexions sur le blog de Codeureuses en liberté ou Code code coop. J'aimerais pouvoir animer en 2026 des espaces de discussion et de partage de pratiques entre coopératives numériques, pour pouvoir mettre en commun et créer des ressources qui permettent d’améliorer nos conditions de travail. Donc si vous êtes intéressé·es, contactez-nous !

Sur Internet, j’ai eu mille pseudos, tout autant de sites personnels. Il y a quelques années, j’avais un blog qui réunissait de nombreux lecteurs, je racontais ma vie, mes voyages, mes astuces déco et DIY¹. Instagram était mon terrain de jeu préféré : prendre le temps de peaufiner le feed (grille de mes publication), retoucher les photos, partager des stories²...

Et pourtant, il y a moins d’un an, j’ai tout quitté, sans regret.

Pourquoi ce retournement de situation ? Les réseaux tels que je les ai connus ont bien changé.

J’ai vu les plateformes se transformer (et pas que par un changement de nom), les publicités et posts³ sponsorisés prendre de plus en plus de place.
J’ai vu les interactions être dirigées par ces réseaux. Vous savez, ce lien qui se maintient que si on a vu et réagi à la bonne story, ou le bon post.

J’ai vu aussi les actualités, les conjonctures politiques, l’intelligence artificielle à tout-va, les données personnelles qui le sont de moins en moins.
J’ai commencé par désinstaller l’application X (anciennement Twitter), pour ne plus être tentée d’un coup d’œil sur les dernières tendances et hashtags⁴.

Puis j’ai réfléchi à quitter Meta, mais là, c’est une autre histoire, il me fallait un plan.

F comme Meta

Dans GAFAM, il y a un F, comme Meta : le groupe qui détient Facebook, Instagram et WhatsApp.

La dernière fois que j’ai ouvert Facebook, c’était pour changer ma photo de profil il y a quelques années. Mais pour Instagram, c’est une autre histoire. Je ne comptais plus mes heures à scroller⁵, regarder du contenu, et le plus souvent de comptes que je ne suivais même pas.

Mais par où commencer ?

1. Limiter le temps d’utilisation de l’application. J’avais besoin de le réduire drastiquement, c’était devenu un réflexe inconscient de prendre mon téléphone et scroller vers le haut. Dans les paramètres de mon téléphone, j'ai pu mettre en place une limite de 20 puis 10 minutes par jour. Juste pour l'expérience, je vous encourage à tester !
2. Faire la liste des comptes qui comptent : ceux qui avaient fini par rentrer dans ma routine des 10 minutes par jour. J’en ai profité pour vérifier si je ne pouvais pas trouver l’information ailleurs (site Internet, autre profil sur les réseaux sociaux, flux RSS…). Pour les autres, j’ai sauvegardé l’URL du compte pour y jeter un œil directement d’un navigateur.
3. Faire une sauvegarde. Désactiver son compte, c’est aussi dire adieu à des années d’images partagées, de montages, et de souvenirs.

Après ça, il ne me restait plus qu’à faire la demande de suppression du compte. Pour que ce soit effectif, il fallait attendre 30 jours, le timing parfait pour préparer ma fuite de WhatsApp.

Dire adieu à WhatsApp

Comme beaucoup, vis-à-vis de WhatsApp, j’étais insouciante. C’est pratique, tout le monde est dessus : les amis, la famille. Un mariage, un anniversaire, un verre, on créé un groupe WhatsApp. C’est presque devenu un nom commun, comme Sopalin, Scotch ou Nutella.
Et puis ils ont commencés à mettre de l’IA, il fallait, presque tous les 3 mois, cocher des cases et remplir des formulaires pour avoir la paix. Une date limite était annoncée, je n’avais plus le choix.

Je venais de quitter Facebook et Instagram, j’étais si proche de sortir Meta de ma vie, pourquoi ne pas essayer ?

1. En parler autour de moi. « Et toi, tu en penses quoi de WhatsApp ? Signal, tu connais ? »
2. Faire le tri. Chaque occasion a son groupe, qui une fois la date passée, il ne vit plus, à part pour les notifications « Pierre Paul Jacques a quitté la conversation ».
3. En parler autour de moi. « Et si je quitte WhatsApp, tu me suis ? Je crée un nouveau groupe et je t’invite, tu verras, c’est super simple ».

Je sais, j’ai eu de la chance, je n’avais pas de conversation active pour le boulot, ou avec mes voisins. À force d’en parler, les gens m’ont suivi. Ils n’ont pas quitté WhatsApp, mais j’ai gardé le lien. Si mes parents l’ont fait, alors pourquoi pas toi ?

Oui mais demain ?

Ce que je n’ai pas dit au début de mon article, c’est qu’avant d’initier ma séparation avec Meta, j’ai commencé un gros chantier en avril dernier : me passer de Google.
Je me souviens encore de mon premier pouet sur Mastodon, je ne savais pas par où commencer, je savais que ça serait long, mais j’étais bien naïve sur la quantité de choses à penser. Se passer de Google, c’est se passer de Gmail, de Google Maps, du PlayStore, Google Drive… Il y a déjà trop de Google dans cette phrase. Je ne suis même pas sûre d’y arriver un jour.

1. Trouver un nouveau service pour une transition une douceur. Je suis passé chez Infomaniak, avec l’offre payante KSuite + nom de domaine. Si un jour je veux partir de chez eux, je garderai mon adresse.
2. Faire du tri. J’ai passé des heures à trier, classer, sauvegarder, supprimer, des années de mails, fichiers et photos stockées. Profiter de chaque mail reçu pour me désinscrire des newsletters. J’ai même fini par me faire un modèle de demande de suppression de compte.
3. Changer d’adresse. Déménager, à coté c’est de la rigolade. J’ai fait une première liste à partir de mon gestionnaire de mot de passe. Et puis ensuite, c’est au compte-gouttes : un mail reçu, une tâche administrative à faire, une commande à passer. C’est pour cette étape que je me suis laissé 1 an avant de supprimer définitivement mon compte.

Et voilà, j’en suis là. Plus libre qu’hier, avec encore tellement à accomplir, comprendre, et apprendre. Comme pour une rupture : on se dit qu’on y arrivera jamais, qu’on ne s’en passera pas, que ça restera. Et puis un pas après l’autre, on se reconstruit, on s’adapte, et le temps fait son œuvre.

Et pour la suite, j’y réfléchis encore. J’ai entamé une transition qui a et qui va changer beaucoup de mes habitudes. Je ne suis pas parfaite, loin de là : il me reste une adresse Gmail pour mon utilisation du PlayStore, un Windows pour jouer aux jeux vidéos, et un Google Maps rempli de bonnes adresses. Ces services restent ancrés dans notre quotidien, et c’est un équilibre à trouver.

À ce jour, il n’existe pas de balise <carousel> portant une sémantique à toute épreuve. Chaque équipe intègre donc ces contenus comme elle peut, au risque de créer de nouveaux défis pour les personnes handicapées.
La Web Accessibility Initiative (WAI)² propose un guide des composants ARIA qui contient des implémentations permettant de rendre l’expérience en partie accessible aux personnes qui se servent d’une technologie d’assistance.

Cet article présente les points critiques qui peuvent créer des situations de handicap. Il apporte aussi des solutions pour produire des carrousels accessibles sur le web.

Le terme « carrousel » désigne ici les blocs dont on fait défiler les contenus au fur et à mesure pour n’en afficher qu’une partie à la fois et le terme « diapositive » désigne leurs sous-éléments.

Cet article fait des références au Référentiel général d’amélioration de l’accessibilité (RGAA) 4. Si vous êtes soumis à une norme ou à un référentiel différent (par exemple WCAG³ , EN 301 549⁴ , RAWeb⁵ ou RAAM⁶ ), vous pouvez faire la correspondance avec votre norme depuis la partie « Références » des critères cités.

Si vous ne pouvez pas lire tout l’article, vous pouvez retrouver les points essentiels à retenir dans la conclusion.

Bonnes pratiques pour concevoir un carrousel accessible

Prévoir un moyen d’arrêter les carrousels animés

Si votre carrousel défile automatiquement et qu’il n’y a pas encore de bouton permettant d’arrêter le mouvement, alors il pose un premier problème d’accessibilité. De nombreuses personnes handicapées vont être gênées par ce défilement intempestif, notamment :

• des personnes sensibles au mouvement, dont les personnes sujettes à la cybercinétose⁷  ;
• des personnes ayant un trouble de l’attention. Le mouvement du carrousel peut les empêcher de se concentrer sur une zone voisine de l’interface ;
• des personnes malvoyantes, mais aussi des personnes qui ont des difficultés de lecture et des personnes ayant un handicap mental. Pour toutes ces personnes, essayer de lire du contenu en mouvement peut être particulièrement compliqué s’il n’est pas possible d’interrompre l’animation.

Utiliser des animations dans une page web est autorisé à condition de respecter cette règle essentielle d’accessibilité : les internautes doivent pouvoir contrôler le mouvement, par exemple au moyen d’un bouton « pause ».

Le nom de ce bouton doit indiquer l’action qu’il permet de réaliser, par exemple : « lecture » quand le carrousel est à l’arrêt et « pause » lorsque le carrousel est en mouvement.

Ce bouton doit apparaître sur toutes les résolutions, y compris lorsque les internautes agrandissent la page à 200 % ou à 400 %⁸ .

Attention : certaines bibliothèques de composants permettent de mettre le carrousel sur pause lorsqu’une personne le survole à l’aide de la souris ou prend le focus sur un des éléments qu’il contient. Cette solution est insuffisante pour l’accessibilité :

• Les personnes qui utilisent un logiciel de contrôle visuel ou un logiciel de contrôle vocal en raison d’un handicap moteur pourraient avoir des difficultés à réaliser ce type d’action ;
• Les utilisateurs et utilisatrices pourraient être en train d’interagir avec une zone différente de l’interface tout en percevant l’animation du carrousel dans leur champ visuel.

Pour bien comprendre le problème, le site Access & Use propose des extraits vidéo de tests utilisateurs montrant les difficultés rencontrées par des personnes handicapées face à des carrousels animés.

Faciliter la navigation dans les carrousels

Gestes et boutons de navigation

Si votre carrousel est animé, il doit donc s’accompagner d’un bouton « lecture/pause ». Mais ce n’est probablement pas le seul bouton à prévoir…

En effet, dans certains carrousels, le passage d’une diapositive à l’autre se fait uniquement au moyen d’un geste de glissement, par exemple :

• sur mobile : avec un doigt posé sur l’écran allant de la droite vers la gauche ;
• sur ordinateur : en faisant défiler le contenu grâce au pavé tactile (touchpad).

Or, bon nombre de personnes handicapées peuvent rencontrer des difficultés pour réaliser ce type de mouvement. Citons notamment :

• les personnes paraplégiques dont le périphérique est fixé à leur fauteuil roulant ;
• les personnes déficientes visuelles qui ne voient pas l’interface, mais qui interagissent avec elle au moyen d’une plage braille ou d’un lecteur d’écran ;
• les personnes ayant un trouble cognitif ou des difficultés d’apprentissage, qui ne comprendront pas forcément l’action à réaliser.

Par ailleurs, toutes les technologies d’assistance ne permettent pas de réaliser des gestes de glissement : les contacteurs (qui reprennent les actions du clavier), les logiciels de contrôle visuel ou vocal, les lecteurs d’écran, les plages braille, etc.

Votre carrousel doit donc proposer des boutons de navigation visibles et utilisables au moyen d’un clic simple. Ainsi ils pourront être activés par tout le monde, que ce soit au clavier, à la voix, avec un système de contrôle visuel, etc. Il peut s’agir de boutons « Précédent » et « Suivant », de puces permettant de choisir la diapositive précise que l’on souhaite afficher, d’images miniatures, etc.

Ces boutons doivent eux aussi apparaître sur toutes les résolutions, donc également pour les personnes qui zooment à 200 % ou à 400 %.

Navigation au clavier et ordre d’accès aux éléments

Votre carrousel commence à prendre forme !

Vous disposez maintenant du contenu de votre carrousel (probablement des images, des textes et/ou des éléments interactifs tels que des liens), de boutons de navigation et peut-être d’un bouton lecture/pause.

Dans quel ordre les personnes handicapées devraient-elles interagir avec ces différents éléments ?

Distinguons ici l’affichage et l’ordre d’accès au clavier ou avec une technologie d’assistance qui lit la page de manière linéaire.

Il est préférable de permettre aux internautes d’interagir d’abord avec le bouton lecture/pause, parce qu’il s’agit de l’une des fonctionnalités les plus critiques des carrousels.

Les éléments suivants seront les boutons de navigation de votre carrousel. En effet, le fait de placer ces éléments avant le contenu du carrousel dans le code source permettra aux personnes qui naviguent au clavier d’afficher la ou les diapositives qui les intéressent avant d’y accéder.

Placer les boutons de navigation avant les diapositives permet de réduire le nombre de manipulations au clavier en évitant aux utilisateurs et utilisatrices de revenir en arrière pour interagir avec la ou les diapositives qui les intéressent.

Il est donc possible d’utiliser un ordre d’affichage et un ordre d’accès au clavier différents, tant que la mise en forme ne laisse pas de doute sur la relation entre ces éléments, par exemple en utilisant la proximité.

Ne pas masquer les carrousels d’images

Si votre carrousel ne contient que des images, elles devraient être décrites, même si elles vous semblent décoratives.

Dans les fiches produit, les images peuvent véhiculer des informations telles que la couleur d’un produit, l’angle de vue, une fiche technique, etc.

Le fait d’intégrer les images de manière décorative (par exemple à l’aide d’un attribut alt="" sur une balise <img>) ne fait a priori pas disparaître le carrousel, qui est composé d’au moins un bouton « suivant » en plus de son contenu, aux technologies d’assistance.

Masquer vos images aux technologies d’assistance reviendrait donc à proposer un composant aux personnes aveugles et malvoyantes qui ne contiendrait que des boutons de navigation, mais pas de contenu.

Il reste donc préférable de toujours décrire les images. Si les images n’apportent pas d’information essentielle, il est possible de rédiger des descriptions courtes telles que « vue du produit de face » « toute notre équipe pose devant notre bâtiment » ou « paysage de montagnes ».

Attention : masquer entièrement le carrousel (c'est-à-dire à la fois les images et les boutons de navigation) aux technologies d’assistance à l’aide de l’attribut aria-hidden="true", n’est pas non plus souhaitable.
Le carrousel ne serait effectivement plus annoncé aux personnes aveugles et malvoyantes ; mais il ne serait plus non plus possible d’interagir avec son bouton lecture/pause ni ses boutons de navigation pour les personnes qui se servent d’autres types de technologie d’assistance, notamment les personnes qui utilisent le contrôle vocal en raison d’un handicap moteur.

Développer un carrousel accessible avec ARIA

Le site ARIA Authoring Practices Guide propose de nombreux exemples de composants interactifs et des manières de les rendre accessibles. Certains de ces exemples sont tout de même à sélectionner avec soin. Lisez toujours les avertissements accompagnant les différents motifs de conception.

Permettre l’utilisation du carrousel avec les technologies d’assistance

Le motif de conception ARIA Carousel a l’avantage de proposer deux exemples presque « clé-en-main » qui incluent une navigation au clavier cohérente :

• un carrousel « basique » avec des boutons « précédent » et « suivant ». Ce code est relativement simple ;
• un carrousel dont le fonctionnement s’apparente à celui d’un système d’onglets, avec des puces de navigation. C’est cet exemple dont vous auriez intérêt à vous servir pour développer un carrousel dont la navigation se fait à l’aide de numéros ou d’images miniatures. Le code est un peu plus complexe (attributs et interactions au clavier supplémentaires à implémenter en JavaScript).

Heureusement, la documentation est claire et des exemples de code HTML, CSS et JavaScript sont proposés.

Nom, rôle et changements d’état

Les carrousels sont des composants interactifs dans la mesure où l’on peut interagir avec différentes parties de la zone (notamment les boutons de navigation) pour en faire défiler le contenu.

Les éléments interactifs doivent posséder un nom, un rôle et leurs changements d’état doivent être signalés aux personnes qui se servent de technologies d’assistance.

Utilisez le rôle region (implicite sur la balise <section>) ou le rôle group. Une fois nommé avec un attribut aria-label ou un attribut aria-labelledby, les lecteurs d’écran annonceront le début et la fin du composant⁹ .

<section aria-labelledby="carousel-heading">
  <h2 id="carousel-heading">Galerie photos</h2>
  […]
</section>

<div role="region" aria-label="Actualités">
  […]
</div>

<div role="group" aria-labelledby="testimonies-header">
  <h2 id="testimonies-header">Témoignages</h2>
  […]
</div>

Note : les régions nommées (rôle region ou balise <section>) proposent un raccourci qui peut être utilisé au moyen d’un lecteur d’écran ou d’une extension de navigateur pour les personnes qui naviguent au clavier. Ce rôle devrait être réservé aux zones principales de la page.

Les rôles region et group restent des rôles généraux qui n’indiquent pas nécessairement l’interactivité de votre carrousel. Le guide des composants ARIA propose d’utiliser l’attribut aria-roledescription pour expliciter le rôle du carrousel aux personnes qui consultent votre site à l’aide d’une technologie d’assistance.

Il est donc suggéré d’ajouter un attribut aria-roledescription="carousel" sur votre carrousel (là où vous avez utilisé une balise <section>, un rôle region ou group) et dans le cas d’un carrousel « basique », un attribut aria-roledescription="slide" sur chacune des diapositives.

Certains lecteurs d’écran remplacent le rôle de l’élément par la valeur de l’attribut. D’autres lecteurs d’écrans ajoutent la valeur au rôle de l’élément. Ils annonceront donc par exemple « Actualités, carousel » ou « 1 sur 6, groupe, slide ».

Attention : la valeur de l’attribut aria-roledescription est restituée telle quelle, elle doit donc être traduite ! En effet, le terme « slide » n’est a priori pas connu des dictionnaires français. Sa prononciation par les lecteurs d’écran risque donc d’être hasardeuse.
Dans ce cas, utilisez par exemple aria-roledescription="diapositive".

Certains carrousels indiquent visuellement la diapositive active dans les boutons de navigation au moyen d’une couleur, d’une bordure, d’un arrière-plan ou d’une autre mise en forme. Cette indication doit également être transmise aux personnes qui se servent d’une technologie d’assistance.

Pour transmettre une information visuelle à une personne qui se sert d’un lecteur d’écran, il est possible d’utiliser un attribut title sur un élément interactif (bouton), un texte positionné hors écran¹⁰ ou un attribut ARIA permettant de transmettre un état.

Le motif de conception ARIA Carousel propose un exemple avec puces de navigation qui utilise l’attribut aria-selected sur la puce qui indique la diapositive active du carrousel.

Note : l’utilisation des attributs ARIA correspond à des rôles précis. Consultez la documentation ARIA avant d’ajouter ce type d’attribut à votre code.

Restituer des informations « en direct »

Vous avez positionné les boutons qui permettent de naviguer dans votre carrousel avant les diapositives dans le code source afin de faciliter la navigation pour les personnes qui naviguent au clavier.

Il reste à informer les personnes qui se servent d’un lecteur d’écran du contenu de la nouvelle diapositive à chaque activation de l’un des boutons de navigation.

Le motif de conception ARIA Carousel propose justement une utilisation intéressante de l’attribut aria-live qui permet de gérer des régions « en direct ». À chaque fois qu’un changement de contenu se produit dans la zone qui possède l’attribut aria-live="polite" (dans notre cas : l’affichage d’une nouvelle diapositive), les lecteurs d’écran restituent ces changements.

Attention : dans le cas d’un carrousel qui défilerait automatiquement, la restitution des changements gênerait les utilisateurs et utilisatrices. L’exemple y répond bien : lorsque le carrousel défile automatiquement, l’attribut aria-live="polite" devient un attribut aria-live="off".

Pour mieux comprendre les bonnes pratiques d’utilisation de l’attribut aria-live, lisez l’article « Live regions ARIA : bonnes et mauvaises pratiques ».

Gérer les carrousels avec de multiples diapositives

La limite principale du motif de conception ARIA Carousel est l’absence d’exemple pour les carrousels qui affichent plusieurs contenus en même temps.

Ce type de carrousels permet généralement de faire défiler un contenu à la fois ou l’ensemble des contenus visibles à l’écran. Il est donc possible d’observer le déplacement de quatre diapositives en même temps.

En l’absence de proposition du guide des composants ARIA permettant de gérer ce type de carrousel, il est possible de s’inspirer des principes déjà évoqués tout en adaptant l’intégration à notre besoin, en s’assurant que :

• votre carrousel dispose bien d’un rôle et d’un nom pertinents et ses changements d’état sont signalés ;
• l’attribut aria-live restitue le contenu de la ou les dernières diapositives visibles, mais ne restitue pas des éléments dont la visibilité n’est pas modifiée ;
• les nouveaux éléments affichés sont bien accessibles aux technologies d’assistance.

Pour l’attribut aria-live, vous pouvez continuer à utiliser la valeur aria-live="polite" dans votre carrousel. Il faudra éviter d’ajouter l’attribut aria-atomic="true" qui aurait pour effet de restituer l’ensemble du carrousel, y compris les diapositives dont la visibilité n’a pas été modifiée. Si l’attribut aria-atomic doit être présent, vérifiez que sa valeur est bien aria-atomic="false". Pour plus d’informations sur l’attribut aria-atomic, lisez l’article « Live regions ARIA : aria-live et ses analogues alert, log, status ».

Ne masquez pas de diapositives visibles avec l’attribut aria-hidden="true". Cet attribut empêche les personnes qui se servent d’une technologie d’assistance d’interagir avec le contenu ou de le vocaliser, y compris celles qui voient l’écran et qui utilisent un logiciel de contrôle vocal, une loupe d’écran vocalisée ou un lecteur d’écran.

Même si une seule diapositive est considérée comme « active » dans le code, les internautes pourraient tenter d’interagir avec n’importe laquelle des diapositives affichées.

Les carrousels avec CSS sont-ils accessibles ?

Au mois de mars 2025, Chrome a commencé à communiquer sur des carrousels réalisés sans JavaScript, grâce à la spécification CSS Overflow 5. Le site Carousel Gallery propose plusieurs exemples de zones défilantes implémentant ces fonctionnalités¹¹ .

Sara Soueidan a écrit un article détaillé et très pédagogique sur l’accessibilité de ces « carrousels CSS ».

Bien que la navigation au clavier soit impressionnante sur les pseudo-éléments CSS interactifs, les carrousels CSS ne proposent pas une expérience suffisamment accessible aux personnes handicapées pour l’instant.

Pour aller plus loin

• Dans l’article What's an interactive element?, Manuel Matuzović s’interroge sur ce qui définit un élément interactif. Les carrousels, qui embarquent des boutons de navigation, rentrent bien dans ce cas. Voir aussi son livre Web Accessibility Cookbook. O’Reilly, qui donne des recettes de code accessible accompagnées d’explications sur les impacts utilisateur.
• Dans l’article Horizontal Scrolling Containers Are Not a Content Strategy, Adrian Roselli s’intéresse aux blocs de contenu défilants… qui ne sont pas des carrousels ! Ceux-ci représentent de nouveaux défis pour les utilisateurs et utilisatrices.
• Dans son guide A Content Slider, Heydon Pickering explore l’accessibilité des carrousels avec des exemples de code. Il a aussi écrit le livre Inclusive Components. Smashing Magazine où il propose des exemples de code accessible pour d’autres composants interactifs.
• Dans l’article Carrousels LinkedIn avec Canva : peut-on les rendre accessibles ?, Coryse Quibel s’intéresse à l'accessibilité des carrousels sur les réseaux sociaux qui peuvent également être rendus accessibles, moyennant l’ajout d’une alternative.

Quand on développe depuis longtemps, on paramètre son IDE (Environnement de Développement Intégré) préféré, on installe ses extensions préférées, on sauvegarde des dizaines (voire des centaines) de favoris « parce que ça peut servir », on automatise certaines tâches. Bref, on travaille dans un espace maîtrisé.
En devenant auditrice, j’ai découvert un tout autre univers. On ne produit plus, mais on observe, analyse et évalue. Et surtout, j’ai découvert un métier où l’environnement de travail n’est plus toujours entre nos mains. Et c’est là que les choses se compliquent.

Auditer

Auditer un site, en France, c’est évaluer sa conformité au regard du Référentiel Général d’Amélioration de l’Accessibilité (RGAA 4.1.2) . Notre rôle est de relever les points bloquants pour les personnes en situation de handicap (visuel, auditif, cognitif, moteur, etc.) puis d’accompagner les équipes techniques et métiers dans la mise en conformité de leurs sites.

La sécurité c’est important

Les règles de sécurité sont bien sûr essentielles partout, mais s’il existe un secteur des plus stricts, c’est bien celui de la banque et de l’assurance. La protection des données est une priorité absolue et les politiques de sécurité y sont très encadrées.

Pour effectuer nos audits dans ce contexte, il existe deux scénarios.

• Soit nous nous rendons directement dans les locaux du client, avec un accès encadré à leur environnement. L’audit se déroule alors sur leurs machines, parfois en présence d’un membre de l’équipe technique.
• Soit le client met à disposition un ordinateur dédié, équipé des accès nécessaires via le VPN (Réseau Privé Virtuel) afin que nous puissions travailler à distance.

Dans tous les cas, avant de pouvoir récupérer une machine, je dois généralement passer par l’étape incontournable : la demi-journée d’intégration sécurité. Oui, même si je suis là pour trois jours, même si les demandes ont été faites deux mois avant.
Badge temporaire, présentation du plan d’évacuation, rappel des procédures, validation du test de sécurité, et me voilà en possession d’un ordinateur sûrement impeccable côté sécurité, mais généralement beaucoup moins côté outils d’audit. La plupart du temps, les logiciels nécessaires sont inconnus, les extensions ne sont pas autorisées. Pourtant, une liste de besoins avait été envoyée en amont, un ticket technique ouvert, validé, revalidé, contresigné par une hiérarchie que je ne rencontrerai probablement jamais.

Il est fréquent de passer plusieurs journées en échanges avec le support technique, à chercher des solutions, à redemander des autorisations, à reformuler les besoins.

Petits exemples :

• après avoir constaté que le centre de logiciels n’autorisait pas l’installation du lecteur d’écran NVDA, et avec l’accord du support technique, nous avons dû installer une machine virtuelle sur le poste fourni, uniquement pour pouvoir installer le logiciel et contourner la restriction ;
• chez un autre client, et avec l’accord de l’équipe de développement, j’ai installé la version portable de Firefox, non prévue chez eux. Chaque jour, un script de sécurité passait le désinstaller à 14 h.

Cette réalité m’a appris une chose : dans les environnements sécurisés, auditer un site ne se résume pas à tester des contrastes ou des alternatives textuelles. Mais aussi à tester sa patience en composant avec les contraintes d’organisation.

Le code source

En tant qu’ancienne développeuse, mon premier réflexe est de passer par le code (inspecter le DOM — Document Object Model —, ouvrir la console, lancer quelques petites fonctions JavaScript pour retrouver les éléments). Mais effectuer les tests manuels est très chronophage surtout pour des vérifications qui en temps normal avec les extensions adaptées ne prennent que quelques secondes.
On se retrouve à lire le code source ligne par ligne pour reconstituer la hiérarchie des titres ou vérifier la présence d’alternatives, lire les attributs et chercher leur correspondance à la main. On finit par bricoler de petits scripts maison pour parser le code, lister les éléments focusables, repérer les listes, etc.

Ces méthodes de contournement sont possibles, mais elles demandent une connaissance technique plus avancée qui ne devrait pas être indispensable pour un audit standard. Le but d’un audit est avant tout d’évaluer l’accessibilité dans des conditions proches de l’utilisation réelle.
Sans un minimum d’outillage, l’audit perd en efficacité, en précision et souvent en fiabilité. On détecte certains des problèmes, mais il y a aussi de grandes chances que l’on passe à côté de beaucoup d’autres. Ce n’est clairement pas suffisant.

Ponctuellement, lire le code source, écrire des bouts de script dans la console pour retrouver ou vérifier la présence d’éléments, pourquoi pas. Le répéter à chaque audit « sécurisé », c’est rébarbatif. Pour cela, il existe déjà une solution légère, simple et parfaitement adaptée à ces contextes : les bookmarklets.

Les bookmarklets

Je connaissais déjà le principe des bookmarklets : on m’en avait parlé, j’avais trouvé ça intéressant, mais je pense qu’à l’époque, je n’avais pas pleinement percuté à quel point cet outil pouvait être utile dans un contexte d’audit.

Un bookmarklet, c’est simplement un petit script JavaScript enregistré comme un favori dans votre navigateur. Au lieu de pointer vers une page web, le favori déclenche du code directement dans la page que vous êtes en train de consulter. Aucune installation, aucun droit administrateur : un simple glisser-déposer dans votre barre de favoris suffit.
Ce faible niveau d’intrusion en fait un outil particulièrement pratique dans les contextes où chaque installation doit être validée par une multitude de services.

En condition d’audit, les bookmarklets ont plusieurs avantages très appréciables. Ils ne nécessitent aucune installation, ils fonctionnent dans la plupart des navigateurs et permettent de faire des tests directement dans la page (un peu comme les extensions, mais en version plus légère et plus facilement maîtrisable).
Bien sûr, ils n’offrent pas toutes les fonctionnalités et ils sont souvent moins « jolis » mais ils suffisent pour réaliser l’analyse de certains critères efficacement.

On trouve de nombreuses bibliothèques de bookmarklets partagées par la communauté ou des initiatives reconnues telle que ANDI, qui regroupent des dizaines de petits scripts utiles pour l’audit et la sensibilisation.

De même, il est tout à fait possible de faire ses propres bookmarklets pour répondre à ses habitudes de travail personnel ou à un critère précis :

• afficher la hiérarchie des titres de la page ;
• mettre en évidence les liens et leurs intitulés ;
• afficher les alternatives des images ;
• visualiser la structure des tableaux présents dans la page.

Exemple :

Un bookmarklet au final ce n’est qu’un petit bout de JavaScript :

// Lister toutes les balises <ul>, <ol> et les éléments qui ont un rôle "list" puis leur mettre une bordure rouge
document.querySelectorAll("ul, ol, [role='list']").forEach(el => {
  el.style.border = "2px solid red";
});

Pour faire un bookmarklet, il suffit de l’encapsuler dans une fonction anonyme auto-exécutable, puis de le réduire sur une seule ligne et de l’ajouter à ses favoris :

javascript:(() => {/\* Votre code \*/})();

Faites le test et glissez ce lien dans votre barre de favori et en l’activant, vous pourrez voir les listes de la page encadrée de rouge :

Listes : entourer en rouge

Bien sûr ceci n’est qu’un exemple et cela pourrait être bien plus complexe avec une présentation plus travaillée. Voir les ressources en bas de page.

Quelques limites à garder en tête

Les bookmarklets ne sont pas une solution parfaite. Certains sites appliquent une politique de sécurité de contenu (CSP) stricte qui bloque l’exécution de scripts injectés dans la page. Dans ces cas-là, le bookmarklet ne fonctionnera pas. Et, comme pour tout script, il faut rester vigilant : ne jamais exécuter un code dont on ne connaît pas la source et privilégier des bookmarklets simples, audités et issus de ressources fiables.
Malgré ces limites, ils restent un outil précieux : léger, portable, facilement adaptable et surtout extrêmement pratique dans les environnements où tout est restreint.

Voici quelques sites (en anglais) qui proposent des bookmarklets :

• Liste d’outils d’accessibilité
• The University of Texas Medical Branch
• Department for Education (UK)
• Paul Jadam (ressources un peu datée mais toujours utiles)

Un peu de contexte

Pour comprendre les intentions visées ici, je me dois de vous donner un peu de contexte.

Je m’appelle Maxime, je suis ingénieur. Cela fait plus de vingt ans que je travaille dans le numérique.

Peu avant le Covid, je me suis intéressé à la synthèse du cinquième rapport du Groupe d’experts intergouvernemental sur l’évolution du climat (GIEC) et à l’analyse systémique de nos sociétés (limites de la croissance¹ ). Ce fut pour moi une sorte de révélation. Certaines de ces informations venaient ainsi exprimer ce qui était jusqu’alors chez moi un ressenti, un malaise diffus. Dès lors, je n’ai eu de cesse de chercher à comprendre les incidences et, en bon ingénieur, à chercher des solutions aux problèmes que je découvrais.

J’ai entrepris de transmettre ces nouveaux savoirs, notamment à travers l’atelier « Inventons nos vies bas carbonne ». La compréhension générale des impacts du numérique que j’avais à l’époque m’a même fait envisager d’abandonner le secteur. J’ai toutefois décidé de faire face. J’ai alors entrepris d’affiner ma compréhension spécifique du numérique (toujours selon une approche systémique) pour tenter d’en limiter les impacts, éventuellement d’en rediriger les usages. J’ai donc lu des rapports scientifiques, des enquêtes… J’ai ingéré des statistiques à n’en plus finir. J’ai tenté d’intégrer la mouvance du « numérique responsable ». N’y voyant qu’une démarche partielle, j’ai encore creusé pour découvrir le concept plus abouti du numérique acceptable² , qui s’inscrit dans la lignée des analyses technocritiques du numérique.

Une autre évidence m’est alors apparue : depuis toutes ces années, j’étais utilisateur, consommateur du numérique et jamais je n’en ai questionné les fondements ni les destinations qu’on lui vouait. J’étais ce qu’on pourrait appeler un mouton numérique³ . Il était donc temps que j’entame ce questionnement philosophique auquel nous, ingénieurs, ne sommes pas acculturés. J’avais débuté ce travail avec Ivan Illich⁴ et la mouvance low-tech⁵ . Mais le numérique restant « high-tech », il me fallait un autre angle de réflexion et un retour à des fondamentaux de la philosophie : notre rapport au bonheur et, plus exactement, la confrontation de l’outil numérique au bonheur. C’est là qu’intervient l’ataraxie numérique.

Ataraxie

L’ataraxie (du grec ἀταραξία, signifiant « absence de troubles »), au sens épicurien, consiste en un état de profonde quiétude, impliquant l’absence de tout trouble ou souffrance.

Profitons-en ici pour faire une petite (é)piqûre de rappel : l’épicurisme est un courant issu de la philosophie antique ayant pour objectif principal l’atteinte du bonheur par la satisfaction des seuls désirs « naturels et nécessaires ».⁶

L’ataraxie numérique serait alors, littéralement, l’absence de trouble par le numérique.

Il me faut transposer ce concept philosophique à notre ère moderne car les philosophes de la Grèce antique vivaient dans un monde moins complexe, sans ordinateurs.

Je m’intéresse plus particulièrement ici au rapport que nous entretenons avec la technologie et par extension à la technique, et dans quelle mesure celle-ci participe à notre bonheur et notre bien-être.

Bonheur ≠ plaisir

Le plaisir n’est pas toujours une composante du bonheur. Dans le numérique, on le constate avec l’exploitation des travaux scientifiques menés pendant des décennies sur le cerveau, notamment au sujet de la dopamine. Cette exploitation a mené à des dérives dont certains dark patterns (PDF, 142 Ko)⁷ ainsi qu’à diverses addictions. En somme, certains mécanismes, encore à l’étude, contribueraient à une forme de récompense que nous pourrions assimiler au plaisir⁸ . Sommes-nous de ce fait plus heureux ? Pas franchement ! N’ayant pas d’indice du bonheur, nous ne pouvons affirmer que notre bonheur est en berne. Néanmoins, nous savons que la civilisation moderne a produit de nouvelles forme de pauvreté⁹ auxquelles le numérique participe au moins indirectement.

À défaut de me lancer dans une thèse à ce sujet, j’ai plutôt choisi de faire un tour d’horizon des troubles qu’on peut d’ores et déjà attribuer au numérique afin de les contrer ou de les éviter.

Troubles numériques

La liste des troubles générés par le numérique est longue et s’étend régulièrement. Non content d’aggraver certains maux déjà existants, le numérique en crée de nouveaux, à l’image de la « dette cognitive »¹⁰ .

L’objet n’est pas de faire une analyse exhaustive de ces maux, mais de comprendre les tendances et grands groupes de nuisances provoquées.

• Santé : mobilité/sédentarité, mental, sommeil, pollutions…
• Éducation : troubles du comportement, visuels, anxiodépressifs, atrophie cognitive, perte de compétence…
• Social : liberté, libre arbitre (PDF, 1 Mo), influence, ingérence/géopolitique, surveillance (PDF, 1,28 Mo), (néo-)colonialisme, stigmatisation…
• Empouvoirement¹¹ : obsolescence logicielle, technique et marketing, enfermement technologique, techno-feodalisme…
• Information : fake news, emmerdification du web¹² , infobésité…

À cette liste nous devons ajouter les incidences indirectes du numérique sur l’humain :

• Énergie : explosion de la consommation, emploi massif d’énergies fossiles…
• Eau : explosion de la consommation d’eau, stress hydrique…
• Environnement : artificialisation des sols, dérégulation, accaparement des ressources, pollutions (PFAS), augmentation des Déchets d’équipements électriques et électroniques (DEEE)…

Le spectre des troubles s’avère large et complexe. Plus que les individus, il touche les sociétés, les États et la planète. Lutter contre chaque trouble semble une tâche interminable, presque insurmontable. C’est la raison pour laquelle le réseau de recherche européen Digitalization for Sustainability (D4S) suggérait en 2023 dans son rapport “Digital Reset, Redirecting Technologies for the Deep Sustainability Transformation” la remise à plat de l’outil numérique dans son ensemble. Il manquait cependant à ce rapport la dimension philosophique.

Si on revient à Épicure, celui-ci énonçait que la clef du bonheur est de connaître ses propres limites. Nos troubles pourraient alors être assimilés aux limites planétaires¹³ et sociales, les éléments clés de l’économie du Donut de Kate Raworth¹⁴ .

Description détaillée

Le schéma représente un graphique concentrique séparé en trois grandes zones :

• Un élément en forme de donut (qui donne son nom au schéma), décrit comme « l’espace sûr et juste pour l’humanité ».
• À l'intérieur du donut, on trouve les limites humaines (« plancher social ) : eau, nourriture, santé, égalité des sexes, équité sociale, énergie, emplois, voix, résilience, éducation, revenu.
• À l’extérieur du donut, on trouve les limites de l’environnement (« plancher environnemental ») : changements climatiques, utilisation d’eau douce, cycles de l’azote et du phosphore, acidification des océans, pollution chimique, charge atmosphérique en aérosols, appauvrissement de l'ozone, appauvrissement de la biodiversité, changements d’occupation du sol.

Risquons-nous à préciser ces limites pour le domaine numérique.

Limites numériques

L’étape préalable à la définition des limites est de généraliser la pensée techno-critique, c’est-à-dire trouver un moyen de penser pour mieux vivre avec nos objets techniques. Il nous faut donc considérer le discernement technologique comme moyen nécessaire.

On pourrait statuer démocratiquement sur toutes les innovations techniques et avoir pour règle : « Tu ne te conformeras point à ce monde qui t’entoure. »¹⁵

Certains ont déjà éprouvé ce principe. On le retrouve par exemple dans la démarche low-tech, le numérique acceptable cité plus haut, le perma-computing, la désescalade numérique, la décroissance numérique et plus récemment le decomputing.

Une fois cette disposition mentale prise, on peut définir les limites sous forme de contraintes. Celles-ci peuvent dans un premier temps être construites en réponse aux troubles identifiés. Voici quelques pistes :

• Contrainte matérielle (durable, réparable, recyclable…) ;
• Contrainte logicielle (libre, open source, faible impact environnemental, démocratiquement choisi…) ;
• Contrainte d’usage (temps, destination, cycle de vie…).

Pour guider nos choix, on peut s’appuyer sur une matrice inspirée du travail de Stéphane Crozat (qui m’a également inspiré cet article)¹⁶  :

Les règles sont les suivantes :

1. En premier lieu, réinterroger les techniques nécessaires pour les besoins non nécessaires ;
2. Eviter le couplage entre techniques nécessaires et besoins nécessaires ;
3. Garantir l’approbation démocratique des techniques non nécessaires aux besoins nécessaires ;
4. Substituer au mieux les techniques non nécessaires pour les besoins non nécessaires. Elles peuvent tout de même être évaluées au regard de leur impact environnemental et leur potentiel d’addiction.

Prenons un exemple : il nous faut éviter la pleine dépendance aux outils numériques pour notre alimentation (deuxième règle). On peut cependant décider démocratiquement de l’emploi de certains outils numériques pour nous assister dans cette tâche (troisième règle). Un autre exemple plus concret dans ses conséquences est celui des sanctions américaines imposées au juge français à la Cour pénale internationale, Nicolas Guillou. Il démontre que le numérique placé comme élément nécessaire à l’accès à de nombreux services, dont les services bancaires, peut devenir handicapant voire nuisible lorsqu’il n’est plus disponible.

Ce que ces règles et contraintes énoncent mal, c’est la nécessité de réduction. C’est d’ailleurs une des principales difficultés auxquelles nous sommes confronté·es : l’acceptation de ne pas faire, de faire moins, de soustraire plutôt que d’ajouter. Comme l’énonce Philippe Derouette : la disposition mentale à la frugalité est la prémisse nécessaire à la sobriété censée¹⁷ , à la médéité¹⁸ .

Médéité numérique

Concevoir un numérique vertueux, juste milieu entre deux excès opposés (entre techno-solutionnisme béat et anti-tech).

Dépassons désormais l’abstraction du concept philosophique et regardons les réalisations concrètes qui semblent aller dans le sens de l’ataraxie.

Pas d’ataraxie sans désescalade

Mon cheminement philosophique m’a amené à un constat douloureux : le numérique dans sa forme actuelle doit être pleinement repensé. Il doit (re)trouver une fonction de convivialité et ne plus gêner notre recherche de quiétude.

La difficulté principale à laquelle nous faisons face est la nécessité de changer l’idéologie dominante. Nous devons rompre avec l’emprise des Big Techs dont l’influence dépasse le pouvoir des États, mais aussi avec le modèle de croissance infinie et le rapport qu’il sous-tend à la nature. C’est la raison pour laquelle je pense que la sensibilisation et l’éducation sont les piliers de cette transformation.

La low-tech me semble également un outil puissant dans cette transformation. Elle a l’avantage de faciliter un réempouvoirement par la base, par les citoyen·nes. Elle peut également être une piste pour la transformation calculée des entreprises²¹ .

Il est temps de redéfinir les fonctions du numérique pour qu’il soigne plus qu’il ne détruise. C’est la définition même du decomputing.

Ce que le decomputing propose est un parcours vers des sociétés construites sur des relations de soin, dont les attributs ne sont pas l’abstraction et la manipulation, mais l’entraide et la solidarité.
— Dan McQuillan

Aujourd’hui, j’écris pour dire quelque chose d’aussi simple qu’oublié : l’accessibilité ne suffit pas. L’inclusion passe aussi par notre culture Sourde.

Et surtout par notre langue. Pas « la langue des Sourds ». La langue des signes française (LSF) : notre langue.

Sourd(e) avec un S majuscule

Dans mes textes, j’écris Sourde avec un S majuscule, parce que je ne parle pas de la surdité comme d’une déficience. Je parle de culture. On confond souvent les deux.

• sourd(e) (minuscule) désigne quelqu’un qui n’entend pas.
• Sourd(e) (majuscule) désigne quelqu’un qui vit la langue des signes, partage nos codes, et fait partie d’une communauté vivante.

C’est exactement comme dire Français, Breton, Basque ou Kabyle. On ne décrit pas un manque. On nomme une culture.

Quand je me présente comme Sourde, je ne dis pas que je n’entends pas. Je dis que je parle une autre langue, que je pense autrement, que j’apprends autrement, et que ce « autrement » n’a rien d’inférieur. Il a juste été ignoré, trop longtemps.

La LSF : ma langue n’est pas un outil, c’est une vision du monde

La LSF n’est pas une traduction du français avec des gestes. C’est une langue à part entière, avec sa syntaxe, son espace, ses expressions, son humour, sa façon de penser en 3D.

Je me souviens d’un prof, au collège, persuadé de faire « ce qu’il faut ». Il écrivait, écrivait, écrivait. Des paragraphes entiers de français très soutenu. Il me regardait parfois avec fierté, comme pour dire tu vois, je t’aide. Je faisais semblant de suivre. Je souriais. Mais je lisais sans vraiment comprendre. Je traduisais. J’analysais. Je perdais une phrase, un mot, puis tout le sens. Je n’apprenais pas : je décodais. C’est très différent.

Aujourd’hui encore, quand j’assiste à une conférence avec des sous-titres « accessibles », j’ai parfois l’impression de revenir dans cette classe. C’est lisible. C’est techniquement correct. Mais ça ne parle pas à ma langue, ni à ma culture.

Accessibilité et pédagogie : deux chemins différents

Lire un texte long, suivre des sous-titres en français, consulter la transcription, suivre un cours donné par un(e) formateur(rice) qui n’est pas formé(e), je sais ce que ça fait. Pour une personne Sourde, c’est apprendre dans une langue qui n’est pas la sienne, on suit, on traduit, on analyse, on s’adapte, ce n’est pas naturel.

La pédagogie qui fait grandir, je l’ai vécue et pratiquée : enseigner en LSF avec mes mains, mes regards et mon espace, montrer, expliquer, faire voir et faire sentir. C’est apprendre ensemble, observer et partager, comme dans la communauté Sourde.

Et là tout change, l’apprentissage devient plus clair, l’accès se transforme en compréhension et la compréhension devient inclusion.

Pour moi, la vraie inclusion ne se limite pas à rendre accessible, elle passe par notre culture, par notre langue, nos codes et notre manière unique dont nous percevons et apprenons le monde.

Ma pédagogie est née dans mes mains

Plus tard, je suis devenue formatrice UX/UI, puis coordinatrice pédagogique. J’ai continué mes études jusqu’à devenir ingénieure pédagogique, pour structurer ce que j’avais appris… avec mes yeux, mes mains, ma culture.

Et là, j’ai vu quelque chose d’inoubliable.

Un jour, un apprenant essayait de comprendre cette notion : le CTA (Call To Action). Il savait la définition, il l’avait lue mille fois. Rien n’y faisait. Je lui ai simplement montré le bouton dans l’espace, en LSF. J’ai placé un rectangle imaginaire devant nous. J’ai exagéré l’intention, l’action, le mouvement du clic. Et là, il a fait : Ah !
Ce « ah » là, je le connais. Ce n’est pas le « je comprends intellectuellement ». C’est le « je comprends dans ma langue, dans mon corps, dans mon espace ».

Depuis, j’ai intégré la culture Sourde dans toute ma pédagogie :

• l’espace devient tableau,
• les mains deviennent outils,
• le regard devient connexion,
• le partage devient méthode.

Et les résultats parlent d’eux-mêmes : depuis plusieurs années, mes apprenant(e)s en formation numérique reconnue par France compétence affichent 80 % de réussite à l’examen oral. Le jury ne connaissait pas la culture Sourde. Un(e) interprète en LSF était présente pour assurer la traduction entre l’apprenant(e) et le jury, et permettre une communication fluide et équitable.
Et pourtant, les apprenant(e)s ont brillé.

Les personnes Sourdes sont tout aussi capables, talentueuses et passionnées que n’importe qui ! C’est juste de la pédagogie dans la bonne langue.

La pédagogie à hauteur de mains

J’ai travaillé plusieurs années comme coordinatrice pédagogique et formatrice, et j’ai vu de mes yeux les limites des sous-titres et des supports visuels. Même avec les meilleures intentions, cela ne suffit pas.

Apprendre dans une langue qui n’est pas la sienne, c’est comme essayer de danser sans musique : on peut suivre le rythme, mais on ne le ressent pas vraiment.

Dans la vie quotidienne, la culture Sourde se vit partout :

• on signe en faisant les courses, en rigolant entre ami(e)s, en expliquant une recette. Nos mains, nos expressions, tout parle !
• on préfère les échanges directs, les regards, les visages expressifs. C’est vivant, c’est naturel.
• on observe beaucoup, on anticipe. Cela forge une autre manière de comprendre le monde.
• et surtout, on apprend ensemble. Dans la communauté Sourde, le partage fait partie de la vie : un conseil, un geste, une explication… tout circule.

Et la LSF… c’est une fierté !
Une preuve qu’on peut penser, créer, enseigner et apprendre autrement avec notre empreinte et notre identité Sourde, et toute la richesse qu’elles portent.

À force de signes, j’ai trouvé ma méthode

Cette conviction, je l’ai mise au cœur de mon parcours.
J’ai suivi une formation en ingénierie responsable pédagogique et je l’ai réussie !

Cette étape m’a permis de structurer mes méthodes, d’allier exigence, bienveillance et humanité, tout en gardant la culture Sourde au centre de chaque apprentissage.

La LSF au cœur de l’inclusion

L’accessibilité, c’est une porte.
L’inclusion, c’est l’accueil derrière cette porte.

Je rêve d’un web où la LSF et tous les moyens de communication vivent ensemble.

Un web qui ne se contente pas d’être accessible, mais qui soit vraiment inclusif, vivant, humain. Un web qui regarde la diversité non pas comme une contrainte, mais comme une richesse immense.

C’est pour cela que, avec mon équipe, nous avons créé l’association Académie des Sourdoués : une école 100 % inclusive pour les formations numériques, pensée en LSF et en lien étroit avec la communauté Sourde.

Un lieu où chaque personne peut apprendre à son rythme, dans sa langue, avec fierté.

Parce que l’inclusion, la vraie, c’est celle qui met de la chaleur, de l’humour et de l’humanité dans chaque apprentissage.

Mes mains parlent depuis toujours. Aujourd’hui, elles forment, elles transmettent, elles ouvrent des portes. C’est ça, pour moi, l’inclusion.

Joyeux Noël, rempli de rires, de chaleur et de beaux moments partagés !

Mes premières notions d’éco-conception remontent à mon cursus d’étudiante en design, au début des lointaines années 2010. On nous parlait surtout d’impression, de typo à trou pour économiser l’encre, de format optimisé pour limiter les chutes à la découpe et bien entendu de papier recyclé pour sauver les arbres.

Le problème avec le papier recyclé, c’est qu’il est brun, trop rugueux, ou trop fin, en tout cas possède des caractéristiques différentes de celles que l’on attend d’un papier de qualité. On nous avait présenté une super solution : un papier recyclé, mais d’une blancheur parfaite, indiscernable d’un papier de qualité classique.

Pourtant, cette innovation n’avait pas trouvé son public. Pourquoi ? Les client·es choisissaient d’imprimer leur catalogue, emballage ou flyer sur du papier recyclé pour que ça se voie. L’objectif réel était de (dé)montrer leur engagement écoresponsable vis-à-vis de leur public. Un papier recyclé qui n’en a pas l’air, à quoi bon ?

C’était le marketing vert, déjà bien ancré commercialement, mais quasi-inexistant dans le monde du web.

J’y vois un parallèle avec mon expérience dans la conception, et surtout la vente, de sites web éco-conçus, en ce qui concerne l’esthétique de l’interface :

• Pourquoi rejette-t-on le papier recyclé ? Parce que c’est « moche », que ça fait « bas de gamme », parce que ça change de l’habitude, que ça pourrait rebuter l’usager. Ou parce qu’on ne s’est pas posé la question.
• Pourquoi rejette-t-on l’interface sobre ? Parce que c’est « moche », que ça fait « bas de gamme », parce que ça change de l’habitude, que ça pourrait rebuter l’usager. Ou parce qu’on ne s’est pas posé la question.

Impacts numériques

Aujourd’hui, la prise de conscience de l’impact écologique et social du numérique émerge lentement dans la conscience collective. Lorsque j’en parle en dehors du milieu de la tech — et parfois en dedans ! —, c’est peu dire que mes interlocuteurices rament pour raccrocher les wagons. Iels me parlent parfois d’hébergement « vert », ou de la trop grande consommation d’électricité des centres de données.

Mais la plupart des gens ne font pas le lien entre leur consommation de contenu, les heures passées sur les réseaux, et un éventuel impact environnemental ou social. Au contraire, le numérique porte souvent une aura écologique, car il remplace le papier et le papier tue les arbres, alors qu’Internet paraît magique et immatériel.

Dématérialisation accélérée, généralisation de l’intelligence artificielle, connexion permanente, popularité du format vidéo, résolution toujours plus poussée… la tendance est au contraire à l’explosion de notre consommation de données, au « toujours plus ».

Papier blanc


En conséquence, le client lambda arrive souvent avec une certaine vision de son site web idéal : il veut que ça bouge, que ça brille, que ça en jette.

C’est pour cela que dans notre pratique¹ , on est plutôt team papier blanc innovant. On cherche à rendre invisible le travail d’éco-conception, à proposer une interface attractive et dans la norme.

S’il suffisait de connaître les bonnes pratiques de Green IT ou d’apprendre le RGESN par cœur pour réaliser des sites web à faible impact, ça se saurait. Le plus difficile n’est pas la technique, mais de convaincre les décisionnaires.

Négocier avec les boomers

Votre client·e est-il un boomer ? Parfois, oui. Au sens premier du terme. Nous travaillons avec des personnes nées avant le numérique, qui l’ont vu grandir et portent parfois une vision différente sur le progrès et la modernité.

Accueillir ce décalage est essentiel pour une négociation réussie, sans culpabilisation ni confrontation. Comprendre la vision du ou de la cliente, pour proposer des alternatives pertinentes.

Soyons honnêtes : chaque génération a ses difficultés avec la sobriété. Pour les plus jeunes, biberonnés au format vidéo, au défilement infini et à la stimulation permanente, il peut s’agir de la difficulté à se concentrer sur un contenu fixe et sans visuel, à lire un texte long² .

C’est tout un bagage sociétal à déconstruire, notre héritage de l’illusion de la croissance infinie et de l’abondance, ainsi que les conséquences de décennies de captation d’attention de plus en plus agressive³ , et ce combat concerne bien d’autres domaines que le numérique.


Papier brun

Cependant, récemment, une découverte surprenante m’a fait reconsidérer l’option papier recyclé rustique.

Le site d’une agence de communication « engagée » propose la création de sites « à faible impact carbone ». Le graphisme du site reprend consciencieusement les codes de la sobriété numérique :

• peu d’éléments par page ;
• typographie simple sur fond uni ;
• images rares et de petites tailles ;
• micro-animations discrètes.

Pourtant, le site est créé avec un CMS non optimisé et son éco-score est terriblement mauvais : E avec l’ÉcoIndex, G avec Website Carbone Calculator… Ignorance ? Manque de compétences techniques ? Indifférence ? Quoi qu’il en soit, ce n’est plus la « forme qui suit la fonction ».

La sobriété de cette interface n’a qu’une fonction sémantique, marketing, sans application pratique. Osera-t-on appeler cela un discours écologique de façade, plus connu sous le terme anglais greenwashing ? Absolument.

En effet, dans le guide anti greenwashing de l’ADEME⁴ , le terme « représentation graphique » revient trente-quatre fois. On y apprend par exemple qu’un message est concerné par le greenwashing s’il contient [une] ou plusieurs des […] représentations visuelles suivantes — des éléments naturels tels que les océans, les forêts, les animaux, etc.

Et ce, dès lors que l’objectif de la communication serait de rendre un produit ou un service plus écologique […], moins « impactant » sur l’environnement ou encore de présenter la démarche de l’entreprise comme plus « responsable », sans lien avec des actions réelles et concrètes.


La reprise de l’esthétique de la sobriété pourrait être considérée comme une variante plus subtile, plus moderne, des dessins de feuilles vertes, de forêts luxuriantes ou d’insectes joyeux.

Nouveau départ pour la sobriété numérique ?

Mon sursaut d’indignation passé, j’ai pensé que l’arrivée de ce « sobre washing » était une excellente nouvelle pour l’éco-conception web.

Bien qu’un tel message ne soit pas encore perceptible par la majorité de la population (encore faudrait-il faire le test), l’existence d’un tel décalage entre le fond (technologie non-optimisée) et la forme (graphisme sobre) laisse à penser qu’une démocratisation de la sobriété est en cours.

En termes de performance, les résultats seront toujours meilleurs avec une interface minimale — et le papier recyclé plus blanc que blanc cachait sûrement un processus de fabrication moins vertueux.

Si la sobriété graphique dans le web se normalise et devient désirable, alors nous pourrons convaincre plus facilement de sa viabilité, aller plus loin et plus vite vers la généralisation d’un numérique responsable.

Rendre désirable

Pourquoi a-t-on moins envie de commander la pizza « végétarienne » de la carte ? Dans végétarienne, terme générique et sans saveur, on entend surtout sans la viande, ou bien par défaut, ou juste moins. En revanche, la pizza chèvre-miel-tomate confite, la pizza patate douce-oignons caramélisés ou encore la pizza pesto-courgette-pêche ne font-elles pas saliver ?

Il s’agit de donner de la valeur intrinsèque à l’éco-conception numérique. Par défaut, elle s’écrit en contraintes, en négatif, en creux. Moins de visuels, moins de pixels, moins d’éléments, moins de possibilités.

Apprenons à parler d’éco-conception en possibles et en relief : plus d’espace, plus de clarté, une meilleure UX, une vitesse de chargement imbattable !

De même sous l’angle du marketing : plus d’engagement et de fidélisations de l’usager, un meilleur SEO, une meilleure image de marque grâce à la RSE numérique, une audience élargie grâce à l’accessibilité et à la simplicité d’utilisation !

Valoriser et varier les possibilités, donner le choix. Parlera-t-on un jour des éco-conceptions ?

Au menu, nous avons, une interface brutaliste-sauce-Bahaus, un motion-design-alimenté-CSS, ou bien notre spécialité, l’illustration-vectorielle-interactive-faite-maison. Tout ceci labellisé A tout droit de notre ferme écoindex bien sûr.

Interface « minimaliste » ou « techno-solutionniste » ?

On pourrait déjà différencier deux « courants » en front-end éco-conçu : l’interface minimaliste d’une part, en rupture avec les tendances populaires et visant l’impact écologique minimal et, d’autre part, l’interface « techno-solutionniste » cherchant à se rapprocher des tendances populaires avec des techniques écoresponsables.

• D’un côté, on part du néant — l’absence de site, l’impact zéro — et l’on n’y ajoute que ce que l’on juge strictement nécessaire.

• De l’autre côté, on part d’un site « classique » et l’on cherche à supprimer ou à remplacer des éléments et technologies, pour réduire l’impact.

L’interface minimaliste a beaucoup d’avantages, à commencer par celui de l’efficacité en termes d’impact. Mais aussi : la clarté à l’utilisation, la baisse des coûts, l’accessibilité.

Cependant, elle ne répond pas à toutes les situations. Lorsqu’un site web a pour objectif de séduire son utilisateurice, de différencier une marque ou encore de créer de la valeur ajoutée par une esthétique forte, d’autres chemins doivent être empruntés.

Quelques pistes en design

Typographie : la base

À mon époque⁵ , la formation de design graphique était bien plus portée sur le print que le web et lorsque l’on mettait un texte en page, c’était au millimètre près. Compter les caractères, réagencer les lignes pour un drapeau harmonieux, paramétrer minutieusement les options de justification, traquer sans pitié la veuve et l’orphelin.

En passant au web, j’ai dû accepter l’aléatoire, la flexibilité et l’imperfection. Lâcher prise, ne serait-ce que pour préserver la santé mentale de ma développeuse. Cependant, il me semble que beaucoup de sites web passent à côté de l’enjeu de la gestion du texte. Hiérarchie absente, interlignage serré, choix de police éclaté, ou lignes à rallonge.

Je crois qu’en faisant un petit effort, en revoyant nos classiques, simplement avec du texte, on pourrait améliorer le confort de lecture, l’ergonomie, l’esthétique de nos interfaces… et éviter à ma prof de graphisme de se retourner dans sa tombe — d'autant plus qu’elle est encore bien vivante.

S’inspirer de courants artistiques

Le style graphique suisse, développé dans les années cinquante, vise la fonctionnalité et une certaine rigueur. La mise en page s’appuie sur l’asymétrie, sur des typographies sans sérif (on peut utiliser des web fonts), des formes géométriques (coucou le SVG super léger) et des grilles de mise en page. Une récente mise à jour de Figma a intégré les grilles à l’auto-layout, ce qui rend son utilisation plus aisée dans les maquettes.

De Stijl, « le style » en néerlandais, est né dans les années vingt : des lignes droites, des rectangles, des couleurs primaires et beaucoup d’espace blanc. Ce style partage la rigueur géométrique et la recherche de clarté du style suisse, mais expérimente davantage avec la typographie, la traitant parfois comme élément plastique au même titre que les formes colorées.

Les livres anciens agrémentaient leur mise en page d’ornements plus ou moins tombés en désuétude aujourd’hui : feuille aldine, lettrine, filet ; frises florales réalistes ou stylisées et typographies manuscrites. C’est souvent un peu chargé, mais en passant tout ça à la moulinette du modernisme, on peut arriver à des résultats très intéressants. Le CSS permet d’intégrer des lettrines et on trouve des polices de caractères ornementales, comme la Bodoni Ornament.

Devenir un peu développeureuse

Connaître les possibilités offertes par les langages HTML et CSS, en parler avec les développeureuses, permet de se lancer dans une création low-tech. Les translations ou rotations pour de la micro-animation, l’effet de parallaxe pour donner du relief lors du défilement, ou encore des filtres de couleur, de flou, de bruit… à appliquer aux fonds ou aux images.

Quelques pistes en développement⁷

Les fonctionnalités natives

HTML et CSS sont des langages qui ont beaucoup évolué ces dernières années. En éco-conception, les fonctions natives sont cruciales. Elles sont optimisées par le navigateur, elles économisent le CPU, elles sont moins lourdes.

Le HTML permet par exemple de différer le chargement des images avec le lazy-loading, de gérer les différentes tailles d’images grâce aux balises <picture> et <source>, de signaler le contenu critique pour qu’il soit priorisé avec fetchpriority = high, de créer des boîtes de dialogue avec la balise <dialog>, le tout sans recourir à des bibliothèques JavaScript tierces.

Le CSS permet de faire des animations variées — accélérées par le GPU — et par étapes grâce a @keyframes ; currentColor permet de récupérer la couleur du texte pour l’utiliser sur des bordures, des fonds ou du SVG ; les pseudo-classes :has() ou :is() simplifient la logique.

Avant d’ajouter une dépendance externe, il est conseillé de vérifier si une solution native existe. Elle sera souvent plus légère, plus rapide et plus durable.

Bien intégrer les fichiers SVG

Les SVG peuvent être intégrés de plusieurs manières : avec la balise <img>, en inline en copiant directement le code du SVG dans le HTML, ou regroupés dans un sprite SVG (un fichier unique contenant plusieurs SVG) qui va être pré-chargé et auquel on va pouvoir se référer grâce aux identifiants de chaque SVG dans le sprite.

Le sprite est particulièrement intéressant en éco-conception, car il n’y a qu’un fichier à télécharger, avec une mise en cache optimale et une possibilité de styliser différemment chaque instance d’un même SVG lors de son importation dans le code.

Mes conseils sont de privilégier le sprite pour la plupart des SVG, de réserver l’inline aux contenus critiques (au-dessus de la ligne de flottaison) et d’utiliser la balise <img> en cas de SVG lourd pour que la mise en cache soit isolée.

La collaboration design-dev

Au-delà des compétences respectives au design graphique et au développement, ce sont les capacités de collaboration entre les deux métiers qui permettront d’avancer.

On peut limiter les données chargées avec les images, mais il faut communiquer sur la re-dimension, les points de rupture et le rôle de chacun·e dans le projet. On peut créer du motion design low-tech avec du SVG et du CSS, mais cela requiert une maîtrise du graphisme autant que du code et des possibilités qu’il offre.

Profils hybrides ou bidouilles en duo, créons plus de ponts entre ces deux métiers.

Mettre les mains dans le cambouis

Je crois surtout que, designer comme développeureuse, il est urgent d’apprendre (ou réapprendre ?) à mettre les mains dans le cambouis. Laissons l’IA de côté un moment, revenons aux bases.

En développement, requestionner ses choix techniques, l’utilité d’une librairie, la pertinence de chaque dépendance et redécouvir ce que HTML et CSS savent déjà faire. En design, revenir au vectoriel, aux grilles de mise en page, à la maîtrise typographique, à l’histoire de l’art.

L’esthétique de l’éco-conception web a besoin d’innovation, de low-tech, de débrouille et de créativité. Tout est encore à écrire !

Aujourd’hui, tous les matins, je scrolle les titres sur mon téléphone pour avoir un résumé de l’état du monde. Je clique sur quelques articles. J’échange des liens avec des collègues et ami·es. Je réagis, like, commente et partage sur les réseaux. Je m’abonne pour pouvoir lire des enquêtes plus approfondies, plus longues, détaillées.

Ce n’est pas juste une histoire personnelle. Les Françaises et Français aiment lire, sur papier mais aussi de plus en plus dans des formats numériques.

Les médias d’information doivent-ils être accessibles ?

J’ai une réponse simple et courte : oui.

En 2024, la presse française a diffusé 2,6 milliards d’exemplaires et ses sites et applications ont enregistré 78 millions de visites par jour, soit 28,3 milliards de visites dans l’année. Près de 70 % des exemplaires vendus sont numériques, d’après le ministère de la Culture, et 44 % de la diffusion payée passe par l’abonnement. L’information écrite est devenue massivement une expérience numérique¹ .

Moi, même avec mes lunettes épaisses en culs de bouteilles, j’ai une bonne aisance sur le web et j’y accède sans trop de difficultés : je suis valide.

Ce n’est pas le cas pour toutes et tous.

En France, 15,4 % des personnes de plus de quinze ans sont en situation d’illectronisme. Cela représente environ 7,7 millions de la population vivant en France. Ces personnes n’utilisent pas internet ou ne possèdent pas les compétences numériques de base. 28 % ont des compétences numériques jugées faibles² .
C’est autant de personnes qui n’ont pas les clefs pour s’informer en ligne, même quand l’information existe.

On peut aussi parler du handicap : 28 % des personnes de plus de quinze ans, soit 14,5 millions, déclarent une limitation fonctionnelle sévère d’après un rapport de la Direction de la recherche, des études, de l’évaluation et des statistiques (DREES) de 2024 ³ .

Toutes ne sont pas systématiquement en situation de handicap face au numérique, mais si on ajoute les limitations cognitives, les problèmes de vision, de mobilité, de fatigue, d’attention, etc., cela concerne un grand nombre de personnes et plus seulement une « minorité » comme on l’entend parfois.

L’accessibilité numérique est devenue la condition d’accès à l’information pour toutes et tous... et donc la mission première de la presse.

Et tout ça se passe dans un contexte ou l’accessibilité numérique est encadrée par plusieurs lois, depuis 2005. La plus récente, l’European Accessibility Act s’applique depuis juin 2025 aux services numériques tels que e-commerce, e-book, banque et surtout : les médias⁴ .

À la lumière de tout cela, on peut se reposer la question autrement : est-ce qu’un média d’information peut vraiment se permettre d’être inaccessible ?

C’est ce que nous allons voir ensemble.

Le cadre légal : de la loi de 2005 à l’European Accessibility Act

Ce n’est pas nouveau, l’État encadre l’accessibilité numérique depuis la loi du 11 février 2005. Son article 47 impose des obligations d’accessibilité aux services de communication au public en ligne d’un certain nombre d’acteurs :

• les personnes morales de droit public (État, collectivités, établissements publics) ;
• des organismes privés qui assurent une mission de service public ou qui répondent à des besoins d’intérêt général, largement financés ou contrôlés par des organismes et fonds publics ;
• les entreprises du privé dont le chiffre d’affaires annuel dépasse 250 millions d’euros.

Dans ce cadre, plusieurs médias sont directement concernés.

C’est évidemment le cas pour les organismes publics diffusant de l’information comme France Télévisions, Radio France, France Médias Monde, Arte France, l’Institut national de l’audiovisuel (l’INA), les chaines parlementaires LCP-Assemblée nationale, Public Sénat ⁵ (oui, c’est aussi un média, j’en apprends des choses en vous rédigeant cet article !), qui diffusent aussi leurs contenus et leurs programmes sur le web.
C’est aussi le cas de certains acteurs privés : on peut assez raisonnablement considérer que des grands groupes comme TF1, M6, Le Figaro, Ouest-France, ou encore Le Monde, avec leur poids économique, leur chiffre d’affaires, leurs sites et applications et, souvent, les aides qu’ils reçoivent, entrent dans la catégorie des entreprises soumises à ces obligations.

Dans ces cas, on ne parle pas juste de bonnes pratiques, on parle bien d’obligations.
Concrètement, ça veut dire :

• publier une déclaration d’accessibilité à jour, accessible depuis la page principale de leur site ;
• rendre public un schéma pluriannuel et un plan d’action ;
• viser une conformité au Référentiel général d’amélioration de l’accessibilité (RGAA) avec un niveau AA de leurs sites et applications mobiles.

Les risques ne sont pas nuls : ça peut aller jusqu’à 25 000 € d’amende pour défaut de publication des informations obligatoires (déclaration, schémas, etc.), et jusqu’à 50 000 € d’amende pour défaut d’accessibilité pour les organismes publics ou assimilés⁶ .

À cela s’ajoutent les médias qui reçoivent d’une façon ou d’une autre des aides de l’État, au titre du soutien à la presse et du pluralisme de l’information.

Quand on parle de pluralisme de l’information, on parle de la possibilité pour plusieurs médias, avec des lignes éditoriales différentes, de coexister et de donner accès à des points de vue variés. C’est une condition de base pour un débat démocratique un peu sérieux.

En 2024, 527 titres ont touché un total de 175,2 millions d’euros d’aides directes à la presse, dont 23 millions au titre des six aides au pluralisme ⁷ .

Quand un média se présente comme un acteur du pluralisme de l’information et reçoit des subventions pour jouer ce rôle, ça devient compliqué de justifier que son site ou application soit inaccessible pour une partie de la population.

Et ce n’est pas tout. L’European Accessibility Act vient ajouter une nouvelle couche.

Cette directive européenne impose des exigences d’accessibilité pour certains produits et services comme le e-commerce, les services d’accès à des médias audiovisuels, les e-books, etc. Une partie des offres des médias d’information entrent dans ce périmètre⁸ :

• les abonnements numériques vendus en ligne ;
• les applications web et mobiles ;
• les magazines au format PDF ou e-books ;
• les plateformes vidéo ou audio.

Là encore, l’accessibilité n’est pas un bonus, c’est une condition légale pour pouvoir proposer ces services sur le marché.

De plus, les médias ne peuvent pas se contenter d’un truc « à peu près accessible » si les parcours d’abonnement et de désabonnement utilisent des interfaces tordues que l’on nomme joyeusement les dark patterns.

Il y a des règles qui protègent les consommateurices, et les contrôles de la Direction générale de la concurrence, de la consommation et de la répression des fraudes (DGCCRF) visent de plus en plus les dark patterns. On parle des boutons de résiliation cachés, de parcours de désinscription volontairement complexes, d’options payantes ajoutées par défaut qu’il faut décocher avant de payer, et j’en passe⁹ …

Quand pour se désabonner il faut cliquer sur six écrans, chercher un lien minuscule en gris clair sur un fond gris foncé, confirmer trois fois des phrases à double négation et faire des sacrifices de chatons au dieu monstre spaghetti géant en sautant à cloche-pied autour d’un caillou qui baigne dans de l’eau bénite un soir de pleine lune, c’est à la fois un problème de loyauté commerciale et un énorme problème d’accessibilité.

Qu’est-ce que ça veut dire, rendre accessible ?

Rendre votre média accessible, c’est permettre à chacun et chacune d’y accéder, de comprendre, d’agir, quelles que soient ses capacités physiques, sensorielles et cognitives.

L’accessibilité sert d’abord les personnes handicapées, mais elle profite à toutes et tous.

Quand on n’en fait pas au quotidien, je vous l’accorde, « accessibilité » peut paraître flou. On en parle beaucoup, mais concrètement, ça veut dire quoi ?

Contenus écrits (articles, dossiers, newsletters...)

Pour les contenus écrits, tout commence par une structure claire.

Utiliser les balises HTML de manière cohérente : des titres hiérarchisés, de vrais paragraphes, de vraies listes. Pas juste des textes dans une forêt de div mises en forme. Ces structures sont importantes pour les outils d’assistance comme les lecteurs d’écran mais aussi pour toute personne qui pourrait avoir besoin de se repérer rapidement dans un texte long.

Il faut aussi soigner la lisibilité :

• une police lisible ;
• un écart entre les lignes suffisant pour que le texte respire ;
• des contrastes suffisants ;
• une mise en page qui suit le sens de la lecture.

Ce sont des détails qui ne sont pas si complexes à mettre en place, qui font aussi la différence entre un article qu’on peut lire jusqu’au bout sans fatigue ou qu’on abandonne au bout de trois lignes par manque de clarté visuelle et sémantique.

On doit aussi chercher la transparence sur ce qui entoure et contextualise l’article :

• les liens doivent indiquer clairement où ils mènent (« lire notre dossier sur [...] » plutôt qu’un « cliquez ici ») ;
• les images contenant des informations absentes dans le texte doivent comporter une description alternative (un alt) ;
• on évite de cacher des éléments importants dans un survol de souris ou une infobulle, qui sont inaccessibles au clavier… et sur mobile.

PDF, e-books et contenus enrichis

Un PDF ne doit pas juste être un scan en images de vos articles papier. Un PDF accessible, c’est :

• du texte sélectionnable ;
• une structure avec les mêmes exigences sémantiques que sur le site (hiérarchie des titres, listes, tableaux correctement balisés) ;
• des métadonnées minimales (titre, langue du document, etc.).

Les e-books doivent être dans un format qui permet d’ajuster la taille du texte, naviguer par chapitre, changer de police en fonction des besoins. Et, dans un monde idéal, on évite certaines solutions techniques ou digital rights management (DRM) mal pensées, qui peuvent casser les fonctions d’accessibilité des liseuses et applications.

Et si vos PDF et e-books sont vendus en ligne, ils entrent dans le périmètre de l’European Accessibility Act. L’accessibilité ne relève pas juste de la bonne action, c’est aussi une obligation réglementaire.

Audio, vidéo, podcast

Concernant les audios et vidéos, les bases de l’accessibilité sont souvent connues mais assez peu appliquées :

• proposer une transcription textuelle des podcasts ;
• fournir des sous-titres pour les vidéos ;
• relire et corriger les transcriptions si vous choisissez d’utiliser des outils de transcription automatique.

Le lecteur audio ou vidéo doit être utilisable entièrement au clavier, avec des libellés compréhensibles sur chaque bouton pour qu’on puisse connaître leur fonction sans les voir.
Au passage, la lecture automatique au chargement de la page est à bannir ou a minima être une option que l’utilisateurice choisit dans ses paramètres.

On peut aussi contextualiser par écrit le média audio ou vidéo, avec une description courte qui permet d’en connaitre le sujet et une partie du contenu sans avoir à lancer la vidéo ou mettre le son. Ce n’est pas seulement pour accommoder les personnes sourdes, malvoyantes ou aveugles, ce sont aussi des détails méga pratiques pour les personnes qui n’ont pas d’écouteurs ou qui aimeraient s’informer discrètement dans le métro ou pendant une réunion ennuyeuse.

Parcours de services : abonnement, achat, compte, dons

Si votre média vit d’abonnements ou de dons, comment vous passer de l’accessibilité de vos formulaires d’inscription ? Quelques bases :

• les champs doivent être navigables au clavier ;
• les messages d’erreur doivent être clairs, pas seulement signalés par la couleur ;
• un récapitulatif de l’engagement clair avant la validation (montant, durée, modalités de reconduction, etc.) ;
• et la possibilité de retrouver la gestion du compte sans chercher dans vingt-cinq sous-menus.

Des formulaires clairs, faciles à lire et à comprendre, sans jargon, ça aide le plus grand nombre, dont les personnes qui ne sont pas forcément à l’aise avec le numérique.

« De toutes façons, on n’a pas de lectorat handicapé. » Vraiment ?

C’est une phrase que j’entends souvent quand je signale des problèmes d’accessibilité sur un site ou une appli : « De toutes façons, nous, on n’a pas d’utilisateurs handicapés. »

C’est peut être vrai dans vos dashboards.

Sauf qu’en général, ce n’est pas que ces personnes n’existent pas, juste qu’elles n’apparaissent pas dans vos metrics.

Il ne faut pas confondre cause et conséquence : si votre site n’est pas accessible, il y a toutes chances que les personnes handicapées essaient… puis abandonnent. Elles n’arrivent pas à s’inscrire, à lire vos contenus, à passer un paywall qui piège la navigation clavier, à gérer leur abonnement... alors elles tentent ailleurs.

Dans vos statistiques, ça se traduit par un taux d’abandon de page ou de formulaire, pas par un bandeau clignotant indiquant « cette personne est partie parce que votre site était inutilisable avec un lecteur d’écran ».

D’ailleurs, des études côté e-commerce le montrent très bien. D’après le baromètre 2025 de l’accessibilité de la Contentsquare Foundation, 35 % des utilisateurices n’atteignent même pas l’étape de paiement. Les pages produits et les parcours de commandes sont trop difficiles à naviguer et comprendre : c’est un manque d’accessibilité¹⁰ .

Plus le parcours est compliqué à lire, comprendre, utiliser, plus les personnes décrochent avant la fin, et les premiers et premières concerné·es sont celleux qui ont déjà des poids et des contraintes quotidiennes (handicap, fatigue, charge mentale, difficulté de concentration, limitations cognitives).

On ne parle pas d’une petite partie de la population. On l’a vu plus haut, on parle d’un tiers des adultes qui déclarent au moins une limitation fonctionnelle et d’une personne sur six en situation d’illectronisme ou de faible compétence numérique.
Une grande part de votre lectorat qui vous lit déjà peut aussi se retrouver en situation de handicap temporaire ou contextuel, avec de la fatigue, des troubles de l’attention, une vue qui baisse, un contexte de lecture dégradé.

Pour un média, rendre son site accessible, c’est améliorer la capacité de tout le monde à aller jusqu’au bout du parcours : lire un article, renouveler son abonnement, faire un don, vous contacter, envoyer des paillettes quand l’article le mérite.

Est-ce que ça ne touche pas la corde sensible ? Savoir que l’accessibilité joue directement avec vos chiffres préférés ? Moins de frictions, c’est moins d’abandons de formulaires, des conversions à l’abonnement et à l’achat plus élevées, une meilleure rétention, plus de lecteurices, moins de gens qui lâchent l’affaire au milieu d’un paywall incompréhensible.

Et ça nous mène tout droit vers la partie suivante : ça change quoi côté business ?

Les retombées économiques de rendre son contenu accessible

Quand on s’y intéresse peu, on entend surtout parler de l’accessibilité sous l’angle des droits, d’obligations, de lois, de justice sociale, des valeurs… Mais j’ai bien conscience que pour certains le bon argument c’est le portefeuille, et sur ce point on a pas mal de chiffres et d’études qui montrent que rendre ses sites accessibles, c’est aussi une meilleure performance pour se remplir les fouilles, ou au moins avoir un modèle économique qui permet un peu plus votre indépendance.

Un site accessible, ce sont des utilisateurices plus satisfait·es, qui restent abonné·es plus longtemps, qui recommandent vos contenus.

Coté e-commerce, la Contentsquare Foundation rappelle qu’aujourd’hui, en 2025, 94 % des parcours d’achat en ligne restent inaccessibles aux personnes handicapées¹¹ .

Quand on a des contraintes ou des handicaps, qu’on trouve un site qui répond à nos besoins tout en étant accessible, c’est tellement rare qu’on en parle à nos potes pour qu’ielles puissent profiter d’un des rares acteurs qui pensent à eux pour leur rendre la vie plus facile. C’est un avantage concurrentiel non négligeable. L’étude souligne aussi que :

un site accessible touche jusqu’à 25 % de clients en plus et améliore l’expérience utilisateur pour 100 % des visiteurs, y compris ceux sans handicap. L’accessibilité devient donc un avantage concurrentiel et non plus une simple obligation légale. Étude Contentsquare Foundation 2025¹² .

C’est aussi un enjeu de réputation et d’image de marque. Plusieurs études sur la consommation responsable montrent qu’environ un français sur deux se dit plus réceptif aux engagements de responsabilité sociale des entreprises (RSE) d’une marque au moment de l’achat, et que plus les années passent, plus ces critères sont intégrés dans les décisions d’achat.
Pour un média qui parle de société, de politique, d’écologie, de droit, prendre au sérieux l’accessibilité numérique fait partie de ces engagements visibles, crédibles, impactants.

J’en ai déjà parlé plus haut, ne pas respecter les obligations d’accessibilité, c’est un risque juridique et financier, de 25 000 € d’amende pour des défauts d’accessibilité ou d’absence d’informations obligatoires et, dans le cadre de l’European Accessibility Act, des sanctions qui peuvent atteindre jusqu’à 300 000 € d’amende si les manquements persistent, sans compter la mauvaise presse qui vient avec les sanctions publiques. Avoir une image d’un média qui respecte son public, il me semble que c’est important pour un acteur qui revendique une mission d’information.

À l’inverse, un média qui a une démarche d’accessibilité visible, même imparfaite, mais sincèrement engagée et progressive, c’est un signal positif. Vous montrez que vous comprenez que votre public n’est pas un groupe homogène, que vous prenez au sérieux votre mission d’information et que vous investissez sur la qualité des usages.

Ce sont des choses qui peuvent peser dans vos appels à projet, dans des campagnes de dons, dans vos partenariats, vos annonceurs, lecteurs et lectrices, surtout lorsqu’ils sont engagé·es.

L’accessibilité rejoint la mission des médias d’information : le devoir d’informer toutes et tous, le droit d’être informé·e

Finalement, au-delà des lois, des modèles économiques, de peaufiner son image pour « avoir l’air bien », la question de l’accessibilité, pour un média d’information, ne serait-elle pas juste faire son boulot jusqu’au bout ?

Donner accès, vraiment, à l’information que vous produisez, à toutes et tous.

Quelque part, c’est ça, le cœur du sujet, on ne peut pas d’un coté proclamer la liberté d’informer, défendre le droit d’enquêter, se battre pour la pluralité des médias… et de l’autre laisser de côté une partie de son public.

Quel sens prend cette mission d’information si elle est inaccessible à une partie de la population ?

Si la mission journalistique c’est d’éclairer, de relier, de transmettre, alors rendre le média accessible, ce n’est pas juste un petit bonus, ce n’est pas juste un geste citoyen : c’est un prérequis. Une question de cohérence autant que d’éthique.

C’est aussi une question de respect. Respect de celleux qui veulent s’informer, respect du débat public, respect du métier que vous exercez.

Sans compter que l’on peut toutes et tous, vous y compris, passer de ce côté : un accident de la vie, une maladie, la vue qui baisse, un dommage collatéral pendant une manifestation, un enfant qui joue avec une poupée vaudou, et vous risquez de vous retrouver du côté des gens que vous avez oubliés.

Rendre le monde numérique plus accessible, c’est aussi prendre soin de vous-mêmes plus tard.

Rendre ses contenus accessibles, ce n’est pas un coût pour s’adresser à « une minorité », c’est élargir son audience, tenir ses engagement et ses promesses.

C’est juste aligner ses actions avec les valeurs qu’on revendique.
C’est simplement assurer sa mission d’information.