@Work
L’Agile, clé de voûte d’un numérique plus accessible
Par Laurent Delattre, publié le 29 septembre 2025
Anticiper les exigences d’accessibilité dès la phase de design permet d’éviter des surcoûts et d’améliorer l’efficacité des équipes. D’autant que l’accessibilité numérique, désormais encadrée par la directive européenne, impose aux entreprises d’intégrer les normes WCAG dès la conception. Les pratiques Agiles facilitent cette intégration continue et collective autour de l’utilisateur.
De Cynthia Thibault-Larouche, Cheffe de service, accessibilité et design inclusif, Ciao Technologies
La directive européenne sur l’accessibilité, en application depuis le 28 juin 2025, stipule que tout nouveau site ou nouvelle application, créé par une entreprise proposant des produits ou services numériques, comptant plus de 10 salariés et faisant plus de 2 M€ de chiffre d’affaires, devra être utilisable par les personnes souffrant de handicap, qu’il soit visuel, moteur ou cognitif. Quant aux sites et applications existants, ils ont jusqu’au 28 juin 2030 pour s’y conformer. En cas de manquement, des amendes de 50 000 € par service non conforme pourront être appliquées, renouvelables tous les six mois si les carences persistent. Il s’agit certes d’une nouvelle contrainte, mais l’accessibilité peut améliorer l’expérience de tous. Au Royaume-Uni, le site de e-commerce Tesco a vu son chiffre d’affaires augmenter significativement suite à son travail sur l’accessibilité. 30 K€ investis ont généré 1 M€ de recettes supplémentaires sur un an, gagnés notamment auprès des clients seniors.
Pour mettre toutes les chances de réussite de leur côté, les entreprises ont tout intérêt à regarder de près les apports de la méthodologie Agile. Favorisant un développement itératif, collaboratif et centré sur l’utilisateur, elle peut se révéler particulièrement efficace pour intégrer l’accessibilité numérique dès le début du projet et garantir une application utilisable par tous, y compris les personnes en situation de handicap.
Prendre en compte l’accessibilité au plus tôt
Comme pour tout projet, plus la notion d’accessibilité est prise en compte en amont, et mieux c’est. L’intégrer dès la phase de conception évite de défaire et refaire, ce qui engendrerait des surcoûts et une baisse de productivité.
Il est donc conseillé de définir les critères d’accessibilité dès le backlog produit, d’inclure les personnes en situation de handicap dans les personas et les tests utilisateurs, et de former les designers et développeurs aux normes WCAG (Web Content Accessibility Guidelines) et aux bonnes pratiques d’accessibilité. Par exemple, avant de coder une interface, il faudra être particulièrement attentif au contraste des couleurs, à la navigation clavier, et au balisage sémantique.
À tout moment, il faut penser l’accessibilité et se mettre du côté de l’utilisateur. Dès le backlog et au cours des user stories, il est nécessaire d’ajouter des critères d’acceptation spécifiques, de prioriser les tâches d’accessibilité dans le backlog et utiliser la syntaxe given/when/then pour la formaliser.
Par exemple, il faut se dire qu’un utilisateur malvoyant veut pouvoir naviguer sur le site avec un lecteur d’écran afin d’accéder aux informations sans difficulté. Il faut alors faire en sorte que tous les éléments interactifs aient un libellé clair ainsi que des attributs ARIA (Accessible Rich Internet Applications) appropriés, et que le site soit navigable au clavier car ce type d’utilisateur ne peut pas travailler avec une souris, basée sur la perception visuelle.
Une responsabilité collective
Côté tests, il faudra en prévoir trois types pour vérifier l’accessibilité d’un site ou d’une application. Les tests automatiques utilisant des outils comme Axe, Lighthouse ou WAVE permettent de détecter les erreurs courantes : de contrastes, de balises HTML, ARIA… Les tests manuels vérifient la faisabilité d’une navigation au clavier et avec des lecteurs d’écran tels que NVDA ou VoiceOver. Et bien sûr, il faut faire des tests utilisateurs avec des personnes en situation de handicap.
Surtout, toutes les équipes doivent être sensibilisées et formées aux bonnes pratiques d’accessibilité : développeurs, designers, chefs de produit, en priorité. Il est possible de faire intervenir des experts dans les sprint reviews et d’organiser des hackathons d’accessibilité pour sensibiliser et tester. Ainsi, un développeur pourra proposer un correctif sur une fonctionnalité mal implémentée après une démonstration utilisateur en revue de sprint.
Le processus d’amélioration est continu et le recueil des remarques des utilisateurs en situation de handicap, l’ajout de correctifs dans les futurs sprints et l’évaluation régulière avec un audit, permettent de conserver l’accessibilité d’un site ou d’une application. Par exemple, si, lors d’une rétrospective, l’équipe réalise que les vidéos n’ont pas de sous-titres, elle peut décider d’en ajouter pour le prochain sprint.
De manière globale, appliquer l’accessibilité de manière itérative et collaborative avec la méthodologie Agile, en intégrant les bonnes pratiques dès le début, c’est l’assurance de diminuer le nombre de corrections et donc les coûts, d’offrir une meilleure expérience pour tous les utilisateurs et de favoriser une culture inclusive dans l’équipe de développement. Pour cela, un mot d’ordre à retenir : tester tôt, tester souvent, et impliquer de vrais utilisateurs !
À LIRE AUSSI :
À LIRE AUSSI :
À LIRE AUSSI :
