Pourquoi votre premier audit d’accessibilité risque d’être inutile (et comment faire mieux) ?​

Visionner la rediffusion du webinaire du 5 février 2026 avec Sébastien Delorme (Ideance) et Ronan Robe (Fruggr by Digital4Better).

Un moment de partage pour :

  • Comprendre pourquoi un audit réalisé trop tôt peut s’avérer peu utile.
  • Éviter les erreurs fréquentes liées à une démarche d’accessibilité mal cadrée.
  • Et découvrir comment mettre en place une stratégie d’accessibilité efficace, afin que l’audit devienne un véritable levier d’amélioration et non un simple constat figé.
Transcription de la vidéo

— Ça va nous permettre d’introduire le webinaire du jour,
dont la problématique, ou en tout cas la question
qu’on va essayer d’adresser avec Sébastien,
c’est : pourquoi votre 1er audit d’accessibilité risque d’être inutile ?
Et surtout, comment faire mieux ?
Donc rapide introduction
et je vais d’ailleurs lancer l’enregistrement tout de suite.
Il est déjà lancé. Super.
Je l’ai expliqué, il y a les sous-titres, si vous souhaitez.
Pour ce webinaire, des sous-titres sont proposés.
On va utiliser aujourd’hui la solution Teams.
Mais on va proposer un replay
où les équipes de Sébastien, d’Ideance, d’expertise,
retravailleront le sous-titrage post-webinaire
pour qu’il soit le plus pertinent possible
au regard des propos qu’on pourra adresser aujourd’hui.
On a prévu une session de questions-réponses à la fin,
Donc il y a un petit onglet dans Teams
qui propose un espace pour que vous posiez les questions.
N’hésitez pas à les poser au fur à mesure.
Sébastien et moi, on se fera un plaisir d’y répondre à la fin de ce webinaire.
Pour démarrer, je vais me présenter avant de laisser la parole à Sébastien.
Pour ceux qui ne me connaissent pas,
je m’appelle Ronan Robe, cofondateur de Fruggr.
C’est une plateforme SaaS,
une entreprise engagée dans le numérique responsable,
sur les impacts environnementaux et sociaux du numérique.
Et j’officie en tant que responsable, directeur produit
de notre plateforme SaaS Fruggr.

— De mon côté, Sébastien Delorme,
expert et consultant en accessibilité numérique,
président fondateur de la société Ideance.
Je me permets de présenter Ideance un petit peu plus en détails.
On est un cabinet de conseil spécialisé sur cette thématique,
la prise en compte du handicap dans le numérique, l’accessibilité numérique.
On intervient en France et en Europe,
principalement sur différents périmètres des sujets d’audit,
la thématique du jour.
Différents audits avec des référentiels
qui peuvent être français, internationaux, européens,
mais aussi et surtout sur d’autres périmètres.
On est un cabinet de conseil, on accompagne des projets,
on aide les équipes de conception, de design, de développement
à prendre en compte le sujet le plus tôt possible dans les projets.
On accompagne des référents accessibilité
de groupes de collectivités publiques et territoriales
pour les aider à définir et suivre leur stratégie
et leurs programmes accessibilité.
On est également centre de formation pour tous les métiers du numérique,
contribution, gestion de projet ou équipes de conception UX/UI
à comment mieux et bien prendre en compte l’accessibilité
dans leurs métiers.
Et on a aussi une autre corde à notre arc,
qui est l’aménagement du poste de travail.
Et là, au plus près des utilisateurs et utilisatrices
en situation de handicap,
on forme à l’utilisation de technologies d’assistance,
aux terminaux braille, lecteurs d’écran, etc.
des personnes dans l’entreprise
pour les aider à mieux s’approprier l’utilisation du numérique.
Voilà sur les grandes lignes d’Ideance, on reste un acteur, un petit acteur,
on est une équipe de 20 personnes sur le sujet.
Je te laisse la main pour parler de Fruggr.

— Merci Sébastien. Donc nous, Fruggr,
au-delà d’être une entreprise à mission,
notre mission est de promouvoir un numérique
plus inclusif et respectueux de l’environnement.
C’est une plateforme SaaS, Fruggr,
qui, finalement, existe depuis maintenant bientôt six ans,
on est une quarantaine de collaborateurs en France et au Canada
et on adresse trois verticales à travers notre plateforme.
Une verticale autour de la gouvernance de l’IA,
comment on accompagne les organisations à déployer l’IA à l’échelle
avec la conformité via le RIA
ou d’autres normes telles que l’ISO 42001, etc.
tout en maîtrisant les coûts.
La plateforme permet de centraliser et d’évaluer vos systèmes d’IA.
On a un outil dédié à l’accessibilité numérique, mais j’y reviendrai.
Et puis notre cœur historique, par là où on est nés,
on a un outil qui permet d’évaluer
l’empreinte environnementale du numérique
sur tous ses aspects, matériel, cloud, applications ou workplace,
pour faire en sorte que ce soit un levier de réduction de coûts,
d’amélioration de la performance de l’entreprise
à travers ces critères ESG du numérique.
Et donc, si vous ne connaissez pas forcément,
Fruggr a aussi développé,
on a même sollicité l’expertise de manière ponctuelle
des équipes d’Ideance et de Sébastien
pour construire une solution
à destination de professionnels du numérique,
donc pas forcément à destination des experts d’accessibilité,
mais pour les développeurs, product owners, designers,
afin qu’ils puissent intégrer dans leur quotidien l’accessibilité
de manière simplifiée, accompagnée et pédagogique.
Concrètement, c’est une extension du navigateur
couplée avec une plateforme SaaS
qui permet de réaliser en autonomie des tests d’accessibilité
et de détecter des défauts d’accessibilité
très tôt dans la chaîne de valeur.
On peut travailler dès le début des développements avec Fruggr,
jusqu’au run dans la durée
pour qu’avec le moins d’efforts possible,
on puisse adresser le maximum de problématiques
autour de l’accessibilité numérique
et rentrer dans une démarche d’amélioration continue.
Voilà, c’était la partie présentation pour ceux qui ne connaissaient pas.
On va rentrer dans le vif du sujet dès à présent :
pourquoi tout le monde commence par un audit de conformité
autour de l’accessibilité numérique ?
Je pense que beaucoup de personnes présentes dans ce webinaire
ont déjà fait des audits de conformité, ou ont en tout cas participé,
ont récupéré aussi, ou contribué et autres.
Et ce qu’on observe beaucoup avec Sébastien,
notamment chez beaucoup de nouveaux acteurs qui arrivent,
ils veulent commencer leur démarche par un audit de conformité.
Pourquoi ? En fait, il y a plein de raisons.
Il y a déjà l’obligation réglementaire.
La directive européenne,
tout ce qui est passé en juin dernier en France
a fait peur,
a un peu bousculé, aussi, les entreprises.
Certains, plutôt de manière positive,
se sont dit : « Il faut se mettre en conformité.
Je veux un audit, afficher ma conformité et mon taux du RGAA. »
Très bien, c’est aussi une bonne raison,
pour commencer, en tout cas, de faire un audit de conformité,
la partie réglementaire.
Il y a aussi beaucoup :
« En fait, l’accessibilité numérique, je sais pas vraiment où j’en suis,
on n’a jamais trop traité le sujet, ou au début,
mais je sais pas où j’en suis.
Je veux faire un audit complet pour savoir où on se situe,
ça me permettrait de mieux savoir,
parce que je sais pas si je suis bon ou pas,
si j’ai des points de rupture dans mes parcours, j’en sais rien. »
Et donc l’audit de conformité,
beaucoup de structures commencent par un audit de conformité
pour se situer.
Un peu de dire : « Où j’en suis autour de l’accessibilité numérique ? »
Et puis sinon, ça respecte un schéma simple
et une logique d’achats globalement classique.
Je fais un état des lieux, un diagnostic.
Ensuite, donc l’audit est parfait pour réaliser ce diagnostic,
ensuite, ça me permet de planifier un plan d’action
et après, d’avancer sur un plan de remédiation.
Donc c’est finalement un réflexe logique qui n’est pas fondamentalement mauvais,
mais qui peut être trompeur.
Et c’est ce qu’on veut vous adresser.
Ce n’est pas mal de commencer par un audit de conformité,
mais il y a peut-être d’autres moyens d’adresser l’accessibilité numérique,
en tout cas pour démarrer dans l’accessibilité numérique.

— Effectivement, pour souligner ce que tu viens de dire,
globalement, on le remarque chez Ideance,
puisqu’une partie de notre activité est liée aux audits,
on a de plus en plus, proportionnellement,
de personnes qui nous contactent pour commencer par un audit.
Ce qui était moins le cas il y a quelques années
où on se posait plus la question de la formation,
de l’accompagnement de projet
et moins de l’audit comme point de départ.
C’est aussi pour ça qu’on en discute,
c’est qu’on constate très clairement
que cette volonté ou cette proportion d’audits
qui sont identifiés comme le point de départ de projets,
elle est de plus en plus importante et pose des difficultés.
Elle pose des difficultés,
non pas que l’audit ne soit pas pertinent et pas nécessaire,
mais c’est que la question à se poser,
ça va plutôt être : quand je le déploie ?
Et potentiellement, quel périmètre lui donner ?
Puisque sur un audit, on peut cacher des durées de travail,
des objectifs et des niveaux de détail
qui peuvent être totalement différents d’un objectif à un autre.
Les gros problèmes qu’on va rencontrer
sont souvent liés à l’incompréhension des résultats.
Mine de rien, faire un audit, ça prend beaucoup de temps,
surtout pour des équipes pas préalablement formées.
On va devoir leur expliquer quels sont les problèmes,
pourquoi c’est un problème et comment le corriger.
Tout ce temps qu’on va passer sur un audit,
on le restitue auprès des équipes.
Mais si elles découvrent le sujet de l’accessibilité,
potentiellement, elles vont se retrouver
avec énormément de choses à lire et à comprendre.
Elles vont potentiellement déployer des corrections.
Mais si elles n’ont pas été formées, l’énorme risque,
c’est que ces corrections soient apportées par rapport à l’audit
et pas par rapport à des règles générales d’accessibilité.
En gros, on audite, les équipes corrigent,
sans forcément comprendre tous les enjeux
et on se rend compte que ce qui n’a pas été audité,
ces évolutions fonctionnelles qui arrivent sur un site
ne prennent pas en compte l’accessibilité.
Et c’est un des gros défauts qu’on va rencontrer
et ça peut effectivement décourager des équipes.
Les rapports, c’est long et ça peut être parfois peu actionnable.
D’expérience, même si on l’a très peu mesuré en interne,
et c’est très à la louche,
on a au moins 80 ou 90 % des audits qu’on va faire
pour lesquels tout n’est pas corrigé.
C’est pas critique, c’est pas grave,
on priorise parfois en fonction de l’impact utilisateur
et on va commencer à corriger les choses les plus importantes.
Mais un audit qu’on peut étaler sur 5 à 10 jours, par exemple,
si les corrections s’étalent sur trois, quatre, six ou huit mois,
il faut savoir qu’un projet numérique, ça vit,
et que l’audit que j’aurais fait aujourd’hui,
que je vais avoir corrigé à 50 % dans six ou huit mois,
les 50 % pas corrigés sont probablement caduques entre-temps,
puisque le site a évolué,
les fonctionnalités sont nouvelles, elles ont été refondues, etc.
et on se retrouve avec des rapports qui sont longs ou trop longs
par rapport au temps et au délai de correction
qu’on va pouvoir initier derrière.
La priorisation peut aussi être difficile.
C’est-à-dire que si on se retrouve avec un audit…
J’étais en restitution pas plus tard que quelques heures ce matin,
avec un rapport de pas loin de 100 pages.
Effectivement, on a des captures d’écran,
des exams de code pour illustrer,
mais la question va être : comment je priorise dans tout ça ?
Donc on aide à prioriser les équipes de développement,
mais qui dit priorisation,
dit qu’on pourrait réaffiner ce périmètre de l’audit
et tout de suite le porter sur des choses actionnables rapidement.
Et tout ça, ce que ça va engendrer principalement,
c’est le découragement et les inerties face au chantier.
Et c’est ça le plus gros risque d’avoir un audit trop tôt.
C’est qu’il va être perçu comme étant trop lourd,
trop conséquent à actionner, et ça peut décourager les équipes.
L’objectif de l’audit est pas celui-ci, c’est d’identifier ce qui ne va pas
pour actionner des corrections et des améliorations.
Et là, potentiellement, on a l’effet inverse qui va être engendré.
La conclusion de tout ça, c’est de se dire que l’objectif,
c’est vraiment une démarche d’accessibilité.
Il va falloir qu’on change de perspective
et en gros, l’audit n’est pas forcément un point de départ,
mais ça doit être une photo à un instant T.
On peut passer sur la slide suivante, par exemple.
Une photo à un instant T. En gros, quand j’audite,
je prends une photo à un instant T de mon site
pour savoir ce qui va, ce qui va pas, comment l’améliorer.
Et la démarche, c’est :
comment j’intègre l’accessibilité tout au long du projet ?
Et c’est ça, la grosse différence.
L’accessibilité, c’est une démarche d’amélioration,
d’évaluation, de formation, de montée en compétences.
L’audit est un outil qu’on intègre dans cette démarche.
Mais à quel moment je le mets ?
Avec quel niveau de détail je peux le déployer
pour que ce soit le plus pertinent possible
dans ma démarche de prise en compte de l’accessibilité ?
Et donc de manière concrète,
sur la slide suivante,
on peut donner quelques pistes d’amélioration.
J’en ai déjà parlé brièvement : c’est former les équipes.
C’est vraiment un point fondamental et qui arrive parfois trop tardivement.
Former les équipes de conception, de développement.
Si en audit, on liste ce qui va pas, mais que les équipes sont pas formées,
elles vont corriger ce qu’on leur demande dans l’audit,
sans forcément anticiper les éventuels besoins
de nouvelles fonctionnalités, de nouveau design, etc.
et on se retrouve régulièrement à repartir de zéro.
On a un nombre conséquent d’audits en interne qui sont menés
où quand on recommande aux équipes de se former et monter en compétences,
si ce choix n’est pas pris à un moment donné,
deux ou trois ans plus tard, quand on va réauditer,
on va retomber dans les mêmes travers,
car les équipes ont corrigé ce qu’on leur a demandé,
sans forcément être en mesure d’anticiper.
Il y a de vrais enjeux sur comment je positionne ma formation et mon audit,
puisque l’audit peut avoir un rôle pédagogique.
Dans ce cas, ce sera pas la même démarche d’audit.
On peut former les équipes et faire un audit
pour justement montrer des exemples concrets aux équipes.
Mais les deux sont associés.
On forme les équipes, on audite et on se sert des résultats
pour aider les équipes à monter en compétences.
On peut mettre en place des checklists, des points de contrôle.
Globalement, ce sont effectivement les points de vigilance à avoir
quand je fais des maquettes,
comment mes équipes de conception peuvent tester par elles-mêmes
la prise en compte de l’accessibilité, ça c’est un sujet fondamental.
On nous demande régulièrement et très souvent
d’auditer ou d’analyser, par exemple, des maquettes graphiques.
On sait, en tant qu’experts accessibilité,
que les points majeurs remontés dans des maquettes graphiques
sont des points de contraste.
Notre valeur ajoutée n’est pas tant dans la remontée des points de contraste,
puisque ça peut être testé assez facilement
par les équipes de conception et de design.
On a des outils pour ça, les équipes peuvent être formées,
donc effectivement, ces checklists, on peut les intégrer en se disant :
« Comment on intègre le contrôle des contrastes sur nos interfaces ? »
Et normalement, on n’a pas besoin d’audit
pour savoir si une couleur est suffisamment contrastée.
Donc il y a de vrais enjeux
sur comment j’intègre ces règles-là en amont,
dans les tests fonctionnels ou ceux que je vais mener
pour pouvoir être autonome sans forcément avoir besoin d’un audit
pour remonter le fait que nos couleurs posent problème.
Là où l’audit peut avoir une valeur ajoutée,
ça peut être d’identifier des couleurs ou des points de contrôle oubliés.
Ça, ça peut être une valeur ajoutée.
L’autre point et l’autre enjeu,
il est dans le dimensionnement des audits.
On mène pas loin de quelques centaines d’audits,
probablement par an, en interne.
Les audits ne se ressemblent pas et c’est ça qui va être important.
Il faut savoir ce qu’on veut auditer, pourquoi et dans quel contexte.
Pour donner quelques exemples,
un audit de point de départ sur une démarche d’entreprise
qui n’aurait jamais pris en compte le sujet de l’accessibilité en amont,
qui n’a jamais formé ses équipes et qui veut démarrer par un audit,
par exemple pour sensibiliser en interne ou bousculer les équipes
pour pouvoir se dire : « OK, on veut montrer que le sujet va pas »,
la réponse est donnée avant de démarrer l’audit.
Souvent, on a des structures et des équipes qui viennent nous voir
en sachant qu’ils n’ont pas pris en compte l’accessibilité,
que les résultats de l’audit ne seront pas très bons,
donc on peut se demander :
est-ce que ça vaut le coup de passer 5 à 10 jours pour faire ces audits-là ?
Et est-ce qu’on ne pourrait pas plutôt trouver un autre levier ?
Donc on peut par exemple, et ça nous arrive régulièrement,
auditer sur quelques heures à peine,
lister des points de problème ou de blocage
qui sont majeurs sur une interface,
et on ne fait pas un audit pour calculer précisément un taux de conformité
ou pour lister des corrections,
mais on fait un audit rapide de quelques heures à peine
où on va juste lister des points de blocage fondamentaux,
les montrer sur une réunion pour sensibiliser les équipes
en leur montrant ce qui pose problème,
pourquoi certains ne peuvent pas utiliser le service,
et s’arrêter là.
Et si c’était ça l’objectif,
finalement, en quelques heures à peine, ça peut suffire.
On a aussi par exemple très souvent la question de la priorisation.
C’est quelque chose qui arrive souvent après les audits.
Aujourd’hui, on l’anticipe de plus en plus,
mais quand on reçoit un rapport d’audit, on a régulièrement comme remarque :
comment prioriser, car on pourra jamais tout corriger d’un seul coup,
et comment je priorise ?
Souvent, il y a deux approches. Il y a comment je priorise
pour essayer d’optimiser le taux de conformité rapidement.
De notre côté, on préconisera fortement
une priorisation par l’impact utilisateur.
La question, c’est : si on veut prioriser, corrigeons d’abord
ce qui est le plus bloquant pour les utilisateurs.
Finalement, si on sait d’avance ce qu’on va prioriser
parce qu’on n’a pas la capacité à tout corriger d’un seul coup,
autant se concentrer, lors de l’audit, sur les non-conformités bloquantes
et se dire : « Je fais un audit qui prendra deux fois moins de temps,
mais qui ne listera et détaillera
que les éléments les plus bloquants pour les utilisateurs.
C’est ma première étape. »
Et potentiellement, dans quelques mois, quelques années j’allais dire,
mais plutôt quelques mois,
on va déclencher une autre analyse
pour se concentrer sur les points qui peuvent rester.
Donc on peut tout à fait travailler par itération, par parcours.
Est-ce qu’on audite d’un seul coup 20 pages,
ou est-ce qu’on se concentre pas uniquement sur un parcours
qui correspond à 90 % de l’utilisation du service par exemple, etc.
Les autres alternatives,
ça peut être aussi de faire faire des tests par les équipes.
Très clairement, tout un tas de tests
qu’en tant qu’experts et consultants accessibilité, on mène,
mais qui peuvent être tout à fait menés par les équipes du projet
à l’aide d’outils, à l’aide de plugins, etc.
Et du coup, pour le coup, Ronan en parlait tout à l’heure,
il existe des solutions côté Fruggr, mais il en existe d’autres.
Peut-être que tu peux parler de cette partie « tests automatisés ».

— Oui, en effet.
Alors l’automatisation, je pense que beaucoup sont au courant,
mais pas forcément tous.
On peut pas pleinement automatiser des tests d’accessibilité,
ce n’est pas possible.
L’expertise humaine est nécessaire pour vérifier
si nos dispositifs numériques sont accessibles ou pas.
Par contre, ces outils, il y a certains outils
qui couvrent 15 à 20 % du RGAA qui sont pleinement automatisés,
peuvent être vraiment des aides pour les équipes numériques,
puisqu’avant de solliciter des experts comme dans les équipes de Sébastien,
cet outil automatisé va nous permettre potentiellement de détecter
différents défauts en amont
et faire en sorte que les experts ne soient pas irrités de voir
que des B.A.BA détectables facilement auraient pu être traités en amont.
Il y a ça aussi,
je pense que beaucoup d’experts sont réunis aujourd’hui
et peuvent peut-être se dire : « Payer un expert pour détecter
qu’il y a pas d’alternative texte sur une image clé ou porteuse d’information,
c’est dommage.
Et ces outils de tests automatisés,
en tout cas, peuvent aider aussi à accompagner.
L’approche qu’on a eue avec Fruggr est un peu dans cette même veine-là,
mais on va plus loin que l’automatisation.
Ce qui est automatisable, on va le garder,
mais on va permettre à des équipes non expertes
de traiter en amont et en aval des audits,
en amont et en aval des interventions des experts,
de pouvoir traiter par eux-mêmes,
que je sois product owner, designer, que j’aie dix ou trois ans d’expérience,
d’essayer à mon propre niveau de faire des tests d’accessibilité
de manière manuelle accompagnée, pédagogique,
pour dire : « OK, je comprends.
Dans mon cas, pas besoin d’attendre que l’expert soit disponible
pour répondre à ma question, pour vérifier que mes travaux sont…
…sont accessibles.
C’est aussi la philosophie des outils Fruggr.
Plein d’autres existent.
Nous, on a l’avantage de couvrir à la fois un peu d’automatisation,
et de compléter avec des tests manuels et pédagogiques.
Mais d’autres sont spécialisés, vous les connaissez.
Des extensions comme HeadingsMap, les contrast checkers, etc.
qui sont des super outils à intégrer dans le quotidien des équipes
pour faire en sorte qu’en fait, on corrige plein de défauts
avant de solliciter l’audit,
et les résultats seront que bénéfiques, à la fois pour les utilisateurs,
à la fois pour les résultats d’audit,
mais aussi pour les auditeurs qui vont se concentrer sur les vrais problèmes,
donc des problèmes plus techniques, plus précis, plus d’expertise,
plutôt que sur ce qui est « à la portée de tout un chacun »
désireux d’améliorer l’accessibilité numérique.
C’est ça, la philosophie des outils
qui peuvent être complémentaires dans cette démarche,
avec la formation
et tout ce qu’a expliqué très justement Sébastien.
Donc voilà, nous on le voit, c’est ça qui est hyper important aussi.
C’est une pratique collective.
La qualité est une pratique collective,
les taux de performance, les taux de rebond
ce type d’indicateurs dans la performance numérique au sens large,
c’est une démarche collective.
Et l’accessibilité, ça doit être vu pareil.
C’est pas l’affaire d’experts.
Malheureusement, on voit encore ça :
« On y connaît rien, on va attendre que l’expert intervienne. »
Non, nous la philosophie et comment on peut faire en sorte
que le numérique soit plus inclusif et accessible,
il faut que tous les acteurs qui construisent le numérique
soient vraiment acteurs de ce changement et de ce sujet-là.
Donc c’est pour ça qu’il faut intégrer tous les profils,
que je sois designer, développeur, fonctionnel, testeur…
Et les contributeurs aussi, on a tendance à les oublier,
parce qu’on a beau faire le job jusqu’à l’audit avec un beau résultat,
mais après, des contributeurs viennent alimenter
et intégrer des défauts d’accessibilité,
pas volontairement, mais parce que peut-être pas formés, sensibilisés,
ils ont peut-être pas les outils pour contrôler.
Donc il faut intégrer tous ces profils dans la démarche.
Il faut aussi donner du feedback. En fait, c’est pareil.
Il y a le côté très sanctionnant quand on fait un audit complet,
quand la note fait mal, ça décourage. On se dit : « La marche est trop haute. »
C’est pas grave.
Les sites parfaits ont pas besoin d’être 100 % accessibles.
L’important, c’est de valoriser une démarche d’amélioration continue,
de laisser le droit à l’erreur,
mais d’apporter de la pédagogie pour dire à son collègue designer,
si moi je suis développeur, je vais dire à mon collègue designer :
« Attention, tes contrastes ne sont pas totalement accessibles
et il vaudrait mieux les retravailler. »
Plutôt que de dire : « C’est nul, c’est pas accessible ce que tu fais. »
Apporter du contenu, apporter de la pédagogie,
laisser les gens progresser,
parce qu’on est face à un déficit de compétences sur la thématique.
Il faut laisser les gens progresser tranquillement
et c’est en étant pédagogique et accompagné
qu’on verra durablement des changements
et pas juste sur une photo à un instant T dans la démarche.
Donc Sébastien, le bon moment, c’est quand ?

— Le bon moment pour lancer un audit ?
Il n’y a pas de réponse clé, mais il y a plusieurs éléments,
plusieurs questions qu’on peut se poser.
Nos équipes sont-elles sensibilisées et formées ?
Si la réponse est non, si les équipes sont pas formées,
que le sujet avait jamais été pris en compte,
c’est trop tôt pour lancer un audit
et autant d’abord privilégier la sensibilisation, l’information,
pour que les équipes montent en compétences
avant d’aller mesurer ce niveau de conformité ou d’accessibilité
dans les résultats d’un audit.
Il y a un côté frustration qui va être important
et à prendre en ligne de compte.
Un audit, effectivement,
avec un taux de conformité ou un résultat
qui est très mauvais sur l’accessibilité,
il peut être frustrant.
Si les équipes sont formées, à l’inverse, si elles le sont pas,
ça peut être trop tôt.
Donc c’est vraiment quelque chose qui est à actionner et à identifier.
Est-on sensibilisés, formés ? Et a-t-on pris en compte le sujet ?
À l’inverse, ça peut être valorisant.
Des équipes qui ont essayé elles-mêmes de prendre en compte l’accessibilité,
elles ont fait ce qu’elles ont pu, et elles ont envie d’un audit
qui leur permet de faire un état des lieux, de savoir où on en est,
ça va être intéressant, car cet audit-là pourra relever ce qui est bien fait,
souligner ça aux équipes pour qu’elle continuent
et identifier des points de perfectionnement
qui peuvent être nécessaires.
Il y a la question de la capacité à mettre en place des indicateurs.
C’est avant d’actionner tout levier d’audit
ou de savoir ou d’analyser les résultats d’un audit,
quels indicateurs je mets en place ?
Et très souvent, et je le vois dans les discussions,
une question commence à être posée
sur les seuls indicateurs ou le seul indicateur qu’on a,
c’est celui du taux de conformité.
C’est un indicateur qui ne doit pas être pris en compte aujourd’hui
comme un indicateur de progression, comme un indicateur de satisfaction
quant au travail fait.
Donc avant la question de l’audit, il y a la question de la mesure.
Et ça peut être fait en partenariat avec l’auditeur aussi.
Comment on va évaluer que le résultat d’audit sera bon ou mauvais ?
Ça doit pas être uniquement le taux de conformité,
beaucoup trop binaire aujourd’hui
dans la manière dont il est calculé en France,
parce qu’on peut très bien être 99 % conforme
et avoir un seul critère qui pose problème.
Si c’est celui du sous-titre
quand on est une chaîne de télé ou un service de replay télé,
ça a beau être 1 % du référentiel qui est non conforme,
les sous-titres, quand notre contenu, c’est 100 % de vidéo,
on a loupé le tiers de l’accessibilité.
Et puis à l’inverse, on peut avoir 60 % de conformité
et des petites erreurs à gauche, à droite,
qui sont sur des pages peut-être moins importantes,
sur des impacts utilisateur moins importants,
et au final, l’utilisateur aura l’impression
d’avoir plus d’accessibilité sur un site à 60 %
que sur un site à 99.
Dans tous les sens, ça peut fonctionner, mais ce taux-là ne voulant rien dire,
il faut avoir la capacité à mettre en place d’autres indicateurs.
Combien de critères bloquants ?
Quel est notre délai moyen de correction quand on identifie un problème ?
Quel est le nombre de problèmes relevés dans l’audit
avant ou après avoir formé des équipes ? Etc.
C’est la réflexion : quels indicateurs je mets en place ?
D’expérience, les résultats d’un audit,
notamment du taux de conformité qui sera calculé ensuite,
seront déceptifs
et auront du mal à faire avancer le sujet de l’accessibilité.
Aussi, ai-je intégré l’access dans les process ?
Si effectivement, jamais on a intégré la prise en compte de l’accessibilité
dans la rédaction de contenus, par exemple,
ou sur la saisie d’alternatives aux images
par les équipes de contribution,
évidemment, le résultat de l’audit sera négatif sur ce sujet.
Donc est-ce que je l’ai intégré dans les process ?
Quel objectif je veux donner à cet audit ?
Et en fonction de ça, on va pouvoir effectivement
définir un audit avec peut-être des indicateurs différents,
un niveau de détail différent,
un timing qui peut être différent, etc.
C’est vraiment un sujet fondamental.
Et en synthèse éventuellement, Ronan,
je te laisse la synthèse de tout ça.

— Il y a beaucoup de messages qui ont été partagés aujourd’hui.
Finalement, vous pouvez commencer par un audit,
mais c’est pas forcément le point de départ universel.
On le considère utile quand il arrive au bon moment.
C’est-à-dire au bon moment, en fonction de la maturité de l’équipe,
en fonction de la formation,
de si vous êtes prêts à accueillir tout ce qui va se passer après l’audit.
L’important, c’est aussi de créer la maturité des équipes
et créer de la valeur.
L’équipe va gagner en maturité à travers les audits et leurs résultats.
Mais il y a plein de manières.
La formation outillage, leur donner les moyens d’agir,
parce que des fois, les équipes n’ont pas les moyens d’agir.
Donc c’est important aussi
que les sponsors valident
de la charge de travail dédiée pour améliorer l’accessibilité.
Sinon, voilà, ça restait théorique.
On l’a dit, l’audit, c’est comme le contrôle technique.
J’ai vu dans les commentaires un parallèle automobile.
En effet, l’audit c’est pareil.
alors que finalement, l’accessibilité, c’est une dynamique,
ça se construit dans le temps, au fil des projets, des pratiques,
quelle que soit la nature du projet,
même si sa version, son socle est livré depuis trois ans,
en fait, il faut toujours travailler l’accessibilité au quotidien,
en tout cas en permanence.
C’est comme tout. Vaut mieux agir tôt qu’auditer trop tôt,
parce que c’est justement hyper important.
Plus on attend, plus ça fait mal,
et plus ça coûte cher de corriger les défauts d’accessibilité.
Ça nous parait évident.
Je fais souvent le parallèle avec le monde du bâtiment,
quand on construit un lieu public,
si on met pas de rambarde dans une entrée où il y a des marches,
ça coûte très cher de corriger le problème,
pour construire un moyen d’accès
pour des personnes en situation de mobilité réduite.
C’est pareil avec les sites web et les plateformes web.
C’est un objet vivant
et plus tôt on détecte les défauts, moins ça va coûter cher.
Car après, les défauts seront partout et coûteront bien plus cher à corriger.
Donc il faut agir tôt plutôt qu’auditer trop tôt.
Et sinon, Sébastien l’a bien conclu tout à l’heure,
bien positionné, ça peut vraiment être un accélérateur,
si c’est structuré, inscrit dans une démarche globale
et pas que sur un projet one shot.
On va laisser la parole aux questions-réponses.
Il y a aussi les leviers,
c’est la petite minute auto-promo avec Sébastien.
En tout cas, si vous souhaitez être accompagné
tant par de l’expertise pour poser des feuilles de route,
pour démarrer, poser une stratégie globale,
faire des audits aussi,
les équipes de Sébastien sont là.
Et si vous souhaitez aussi vous outiller,
essayer d’agir par vos propres moyens
sans forcément avoir besoin ou recours à des auditeurs, des experts.
on est là aussi, Fruggr, cet outil.
On est même une solution freemium aujourd’hui,
donc gratuite,
qui vous permet de valider, d’appréhender, en tout cas,
l’accessibilité numérique par vos propres moyens.
Donc n’hésitez pas à nous solliciter,
on sera ravis, avec Sébastien,
de partager et de vous accompagner dans ces démarches qui sont clé
en tout cas pour promouvoir un numérique plus accessible et plus inclusif.
Voilà. On va avoir…
On va passer aux questions-réponses.
Il y en a eu beaucoup.
Il y a eu beaucoup de réponses directement dans le chat.
Je regarde dans l’onglet Questions-Réponses.

— Il y a beaucoup de questions.
J’ai commencé à répondre à une par écrit,
je vais la donner à l’oral aussi.
Il y a beaucoup de questions
sur la loi qui impose la publication d’une déclaration d’accessibilité,
donc de calculer un taux, et donc l’audit est obligatoire.
Je vais répondre en plusieurs lignes,
mais toutes les lois en France et en Europe
ne demandent pas forcément l’affichage d’un taux.
Cette obligation de déclaration et d’affichage d’un taux
se limite aux organismes publics
et aux entreprises qui dépassent 250 millions d’euros de CA.
La directive européenne et sa transposition en France
n’impose pas la publication d’une déclaration de conformité
avec un taux de conformité, elle impose l’accessibilité.
Et donc, pour la personne qui précisait
« c’est une loi d’obligation de moyen », non, c’est une obligation de résultat,
les sites doivent être conformes et justifier en quoi ils sont conformes.
Pour effectivement la loi française qui concerne le secteur public
et les entreprises qui dépassent 250 millions de CA,
il y a obligation de publier une déclaration de conformité
qui est soit non conforme en l’absence d’audit,
soit qui affiche le taux de conformité en présence d’audit.
À quoi bon faire un audit si on sait qu’on est non conforme ?
Vous avez des sites qui affichent avec un très haut niveau de détail
le fait qu’ils ont 22,7 % de conformité, et donc qu’ils sont non-conformes.
Si on sait quand on démarre l’audit qu’on n’est pas conforme,
autant publier une déclaration de non-conformité en l’absence d’audit.
Et par contre, du coup, réallouer le budget de l’audit
à la formation des équipes, à la mise en place d’un plan d’amélioration.
On n’est pas obligés de calculer le taux de conformité
de manière très précise.
Et même du point de vue de l’utilisateur,
il y a effectivement la loi,
mais on prend en compte l’accessibilité pour les utilisateurs.
Je pense que les personnes
qui vont rencontrer des difficultés d’accessibilité sur le site,
préféreront qu’on travaille à améliorer l’accessibilité de ce site
plutôt que de savoir très précisément que vous êtes à 53,7 % conforme,
plutôt qu’à 57,6.
Il y a un vrai enjeu d’accessibilité et le calcul du taux,
il est fondamentalement pas indispensable.
Légalement, il l’est. Mais ça peut se calculer.
Si vraiment votre objectif,
c’est de le calculer précisément pour être dans les clous sur cette partie-là,
un audit et un calcul de taux,
ça se fait en quelques heures sur une interface,
puisque 95 % de l’audit,
c’est identifier les problèmes, proposer des corrections,
les expliquer, les détailler, les prioriser.
Calculer le taux de conformité est la partie la plus rapide de l’audit.
Donc si vraiment vous en voulez absolument un,
je conseille dans ces cas-là
de faire un audit dont l’objectif est juste de calculer le taux
et ensuite, on aménage des budgets
pour former, monter en compétences, mettre en place un plan d’action,
faire de la recette d’accessibilité, des tests utilisateurs, etc.
Et après, je n’ai pas suivi les questions dans le chat.

— Je vais répondre celle de Jean-Baptiste et on va remonter.
À partir de quel moment on est accessible ?
Il y a un pourcentage minimum à atteindre ?
Le cadre de la loi dit qu’en-dessous de 50 %, on est non accessible,
on est partiellement conforme si on est entre 50 et 99
et on est conforme si on est à 100 %.
Comme l’a dit Sébastien, on peut être à 99 %
et ne pas être accessible,
parce que typiquement sur les sites de médias, de vidéo,
s’il n’y a pas la fonctionnalités des sous-titres,
on est 99 % conforme,
mais on est non accessible in fine pour les utilisateurs.
C’est là où il n’y a pas de vraie réponse ferme, je pense,
sur le pourcentage à atteindre.
L’important pour moi, c’est d’améliorer les choses
et sur les parcours clés, sur les problèmes les plus bloquants,
le pourcentage suivra naturellement.
Il faut vraiment regarder l’utilisabilité de la solution
plus qu’un taux de conformité.

— Il y a une toute petite remarque, qui précise, je cite :
« La problématique dit que le principal, c’est l’amélioration continue.
Mais la loi ne semble pas assez souple pour ça. »
Qui a été sanctionné ?
Qui a été condamné, en termes de structure,
pour la non-prise en compte du référentiel d’accessibilité ?
Personne. Donc à mon sens,
la loi est au contraire bien trop souple.
Et entre ce qui est écrit et ce qui est demandé,
publier des déclarations et être 100 % conforme
et le risque de sanctions administratives derrière,
l’écart est monstrueux.
Donc on a quand même en réalité suffisamment de souplesse.
Et aujourd’hui, on accompagne un certain nombre d’entreprises
qui ne publient pas leur déclaration de conformité, qui ne font pas d’audit,
avec des taux de conformité qui s’améliorent
et qui ont pris le parti de se dire : « Si on est sollicités par l’Arcom,
par un organisme de contrôle qui dit qu’on affiche pas le taux de conformité,
on sera capables, dans ce cas, de le calculer pour leur montrer.
Mais on préfère mettre les budgets sur l’amélioration continue. »
Et ça peut être un choix qui se défend tout à fait.
Je termine juste.
« Quand on fait un audit rapidement pour calculer un taux,
ça prend 5 à 10 jours. » Non, en moins d’une journée,
on calcule un taux de conformité sur un site assez facilement.
Ça dépend de la complexité du site,
mais en réalité, juste calculer un taux,
un ou deux jours au grand maximum, on est en mesure de le faire.

— Il y a Claire qui pose la question : que pensez-vous d’auditer
par composant design atomique et non par page ?
Fruggr, en l’occurrence, permet ce type de test, en tout cas de démarche.
Et oui, c’est une bonne démarche, en effet.
C’est complémentaire, c’est-à-dire qu’il faut pas oublier la page,
mais d’auditer dans les design systems,
dans toutes ces méthodologies, du design et du développement
qui permettent de créer des composants réutilisables,
si le composant n’est pas accessible par défaut,
il sera propagé partout
et les défauts d’accessibilité seront propagés dans les pages
qui implémentent ce composant. Donc oui, c’est intéressant.
Après, ça sert à rien d’auditer un composant sur les 106 critères.
C’est pas l’objet.
Mais ça peut être efficace, en effet, d’avoir cette démarche,
de valider composant par composant,
et après vérifier l’intégration dans une page complète
de tous ces composants avec le reste.
Et là, ce sera utile aussi
et ce sera pertinent.
Je regarde, on a…
Quel discours… Je vais te laisser répondre.
Quel discours pour les clients qui, d’un côté,
ont une obligation de déclaration de conformité,
mais qui ne sont pas prêts pour l’audit ?
Je pense qu’on a répondu, c’est l’audit un peu rapide.
Hamza, dans les commentaires,
a expliqué qu’on peut faire un audit juste pour donner un taux,
et après un audit complet.
Ça, ça permet de répondre en une journée,
un peu comme tu le disais, Sébastien,
à cette obligation légale d’afficher un taux
et après de prendre le temps de travailler plus en profondeur
pour améliorer les choses et former les gens
pour qu’ils soient vraiment prêts à accueillir les résultats de l’audit.
Il y a Michaël, je vais te laisser répondre :
comment estimer le coût et le temps de réalisation d’un audit,
et quels critères peuvent jouer sur le prix ?

— Ça va dépendre de l’objectif qu’on va se fixer.
Est-ce que l’objectif,
c’est simplement de faire acte de transparence
et de publier une déclaration de conformité ?
Est-ce que l’objectif, ça va être
d’identifier les corrections de manière très précise
pour ouvrir des tickets et ensuite suivre ces corrections ?
C’est là où généralement, ça va prendre le plus de temps.
Et donc globalement, un audit, c’est entre 3 et 4 jours de travail
sur un site qui est relativement simple.
Parfois plus de 10 jours sur des sites extrêmement complexes.
Mais ça va dépendre du niveau de détail qu’on veut lui donner.
L’objectif est d’avoir la liste des corrections
ou juste de pointer les éléments les plus bloquants et la correction
que sur les points les plus bloquants pour avancer par étape ?
Ça va être ça, mais c’est une question à se poser en amont.
Quel niveau de détail je veux pour avancer sur le sujet ?
Ça dépend aussi du niveau d’accessibilité initial,
parce qu’un site pas du tout accessible aura plein de problèmes,
donc on devra écrire plein de préconisations correctives,
versus quelque chose de très accessible,
sur lequel on va passer peut-être plus de temps à analyser,
car quand tout va très bien,
on passe encore plus de temps à chercher, justement, ce qui va pas,
moins de préconisations correctives, donc plus le site est accessible,
techniquement, moins l’audit sera coûteux,
parce qu’on aura moins de choses à dire.

— Il y a Théo qui pose la question…
Beaucoup de questions, ça fait plaisir, beaucoup de retours et d’interactions.
Comment prioriser la criticité des éléments non accessibles ?
Certains points bloquants pour certains ne le sont pas forcément pour d’autres.
Je pense que les tests d’utilisabilité
par des personnes en situation de handicap,
si vous avez les moyens ou les capacités de le faire,
sont clés.
C’est ça qui va vous permettre de définir les points bloquants.
Encore une fois, au-delà des critères,
de la validité de la conformité d’un critère,
c’est vraiment l’utilisabilité en conditions réelles
qui fera que vous saurez prioriser les points de correction.
Si vous décider de corriger que les critères,
tous les problèmes du critère 1.1,
il y en a peut-être certains qui sont bloquants,
mais peut-être que la plupart ne vont pas être bloquants.
Vraiment, je recommande aussi,
c’est peut-être luxueux, il faut en avoir les moyens,
mais de faire des tests d’utilisabilité en conditions réelles
avec des personnes en situation de tout type de handicap,
parce que chaque handicap a aussi ses particularités,
ses besoins et ses caractéristiques.
Tu peux peut-être compléter.

— Oui, sur la priorisation, c’était très complet.
Par rapport à la question,
certains points bloquants le sont pour certains,
pas forcément pour d’autres,
je rappelle souvent qu’on parle d’accessibilité
et c’est parce qu’on adresse une minorité de personnes
et que ça reste un sujet qui n’est pas ou peu pris en compte,
parce qu’il adresse une minorité de personnes.
Donc à mon sens, le nombre d’utilisateurs concernés
ne doit pas rentrer en compte dans l’évaluation de la criticité.
À partir du moment où c’est bloquant pour une personne,
le critère peut être évalué comme bloquant.
Même si c’est une personne parmi des millions,
l’enjeu de l’accessibilité est de ne pas avoir de points de blocage.
Donc on évalue, on a une grille d’évaluation de la criticité en interne
qui, à partir du moment où au moins une personne sur le site,
quel que soit son handicap ou son moyen d’accès,
ne peut pas utiliser la fonctionnalité, elle est considérée bloquante.
Dès qu’il y a une solution de contournement possible,
où elle peut arriver à l’utiliser
moyennant des difficultés de compréhension,
moyennant de passer par un autre moyen,
le point va être important, mais pas forcément bloquant.
Et puis si l’utilisateur ne se rend pas vraiment compte de la différence,
par exemple entre le critère qui serait conforme ou pas,
on peut le considérer mineur.
On intègre le volume dans cette histoire.
À partir du moment où un point est bloquant,
c’est bloquant.
Mais plusieurs points d’accessibilité qui posent des problèmes majeurs,
qui sont pas forcément bloquants,
s’il y en a qu’une fois ou 100 fois sur le parcours,
à un moment donné, ça peut devenir bloquant.
Donc on évalue l’impact pour l’utilisateur,
mais si c’est utilisateur ou utilisatrice au singulier.
Et ensuite, le nombre d’occurrences d’erreurs,
c’est la position dans le parcours utilisateur.
Sur un un site, je sais pas, sur un site e-commerce, effectivement,
un point sera plus bloquant s’il est sur le parcours d’achat
et il sera probablement moins bloquant s’il est sur une page de contenu
qui ne répond pas au besoin principal du site,
qui est de consulter des produits et faire un achat.
Donc il y a ces éléments-là qu’on rentre en ligne de compte.
Et j’enchaîne sur la question des tests utilisateurs.
Peut-on démarrer par des tests utilisateurs ?
Ça dépend du niveau de maturité et du niveau d’accessibilité.
Faire tester à des utilisateurs quelque chose de pas accessible,
j’aurais tendance à dire, à quoi bon, à quoi vont servir ces retours-là ?
Sauf, peut-être, si c’est pour sensibiliser et éveiller un peu
les équipes de conception et développement.
Mais encore une fois,
on peut faire le parallèle avec l’accessibilité du bâti.
Si j’ai trois marches devant un immeuble,
à quoi bon demander à quelqu’un en fauteuil roulant
si le site est accessible ? Je sais que ça posera un problème.
Ça peut engendrer de la frustration
pour la personne à qui on demande son avis inutilement
et pour les équipes qui vont se dire :
« OK, le retour de l’utilisateur, il est quand même évident. »
Donc il vaut mieux avoir de bonnes bases en termes d’accessibilité,
avant de lancer des tests utilisateurs qui pointeront du doigt
des choses qui ont un vrai impact
et qui auront peut-être pas été identifiées dans des audits,
dans des analyses, dans des revues de code, etc.

— Avant de passer sur une question qui va me concerner
autour de Fruggr et de l’IA,
peut-être un truc qui peut susciter pas mal d’échanges aussi ensuite,
c’est : parfois on nous demande
de retirer des documents ou des fonctionnalités
pour remonter le taux d’accessibilité.
On prive donc tout le monde. Qu’en pensez-vous ?
Moi, je pense que la simplicité est au service de l’accessibilité
et ça va aussi avec les conceptions à ce sujet
qu’on adresse aussi beaucoup chez Fruggr.
C’est cette notion qu’à chaque fois qu’on va avoir une fonctionnalité,
on va se poser trois questions.
C’est la règle des 3 U, simple à comprendre.
Ce contenu, cette fonctionnalité, ce document est-il Utile ?
Répond-il à un besoin et pas une envie ?
Est-il est Utilisé ?
Ça, c’est bien, on a des analytics qui permettent de dire,
si on supprime cette fonctionnalité,
ça touche quelle part de notre audience ?
Et est-ce Utilisable ?
Et en fait, en se posant ça aussi,
certaines fois, oui, ça va priver du monde
de certaines informations structurantes hyper importantes.
Parfois c’est pas grave, au contraire, ça simplifie l’expérience utilisateur.
Moins de richesse d’information,
donc pour des personnes qui ont des troubles dys
ou des problèmes cognitifs avec une surcharge d’informations,
des sites web trop complexes,
supprimer des fonctionnalités sous couvert de réduire un taux
va permettre de faciliter et renforcer l’utilisabilité de la solution,
de la rendre moins lourde, donc là, ça va être positif.
Mais évidemment, si c’est pour enlever les conditions d’accès,
je sais pas,
d’une salle de concert ou d’une salle de théâtre,
et on dit que le bloc qui affiche les conditions d’accès
n’est pas accessible,
donc plutôt que de corriger le problème, on le supprime, c’est problématique.
C’est un bon exemple de là où il faut conserver la fonctionnalité
et la corriger plutôt que la supprimer pour améliorer un taux.
Et comme on arrive bientôt au bout, je pense qu’on pourrait tenir longtemps,
j’ai une belle question de prospective.
Est-ce que Fruggr utilise un peu d’IA ou fait juste du parsing de code ?
Fruggr, aujourd’hui, il faudrait une démonstration complète
pour expliquer le fonctionnement.
Ça fait du parsing de code,
c’est une extension qui va regarder dans le navigateur,
isoler les images,
poser des questions en lien avec le code source à analyser…
Oui, aujourd’hui et c’est très récent, on a intégré de l’IA.
Ça veut dire que Fruggr, il y a des critères automatiques,
c’est des questions algorithmiques.
J’ai posé à l’utilisateur la question :
cette image est-elle porteuse d’information
ou de décoration ?
On va avoir un test automatique qui va être vérifié
s’il y a une alternative texte.
Par contre, ce qu’on a rajouté, c’est récent,
c’est de demander à l’utilisateur non-expert ou qui se pose des questions
ce qu’en pense l’IA.
Et là, on va afficher à l’utilisateur une suggestion,
que l’IA considère à 90 % que cette image est porteuse d’information,
ou que l’alternative texte, elle est pertinente ou pas.
On va donner les justifications, l’impact environnemental de l’action,
car c’est pas neutre en termes d’impact environnemental.
Et c’est dans ce sens-là qu’on a intégré un peu d’IA dans Fruggr,
pour aller plus loin dans l’accompagnement
et l’autonomisation des équipes, pour faire des tests d’accessibilité,
mais toujours avec, je vais utiliser un anglicisme, excusez-moi,
« Human-In-The-Loop », l’humain dans la boucle,
pour ne pas remplacer un robot,
parce qu’une IA n’est pas parfaite et regarde,
ce sont encore des sujets immatures,
ça progresse, ça améliore, on fait améliorer nos algorithmies,
nos systèmes qui vont permettre de faire de l’évaluation.
Mais déjà, le 100 % automatisé n’est pas possible.
Mais il y a certains critères qu’on arrive un petit peu à faciliter,
la validation ou l’invalidation grâce à de l’intelligence artificielle.
Mais avec parcimonie et prudence.
Et je regarde, je pense qu’on a fait le tour des questions.
Donc je vous propose peut-être de conclure ici.
Si vous avez envie, en tout cas, de prolonger les échanges
tant avec Sébastien qu’avec moi,
n’hésitez pas à nous recontacter via LinkedIn, e-mails et autres.
On va vous proposer un replay dans quelques jours
pour celles et ceux qui souhaiteraient revoir ce webinaire
ou celles et ceux qui n’ont pas pu y participer.
Comme dit en introduction, il sera sous-titré.
Et on est ravis, en tout cas, d’y avoir participé.
Merci de votre présence, on est ravis d’avoir échangé avec vous
et d’avoir partagé notre vision sur les audits.

— Je suis ravi également. Merci à tous.
Pardon, j’étais en train de poursuivre les réponses dans la messagerie.
Effectivement, comme tu l’as dit,
si vous avez des questions, n’hésitez pas.
Le plus important, c’est collectivement d’arriver à trouver les bons leviers
pour faire améliorer l’accessibilité pour les utilisateurs
des services numériques sur lesquels on adresse le sujet.

— Belle journée à tous, en tout cas, et bon appétit.
Et à très bientôt j’espère, pour parler d’accessibilité et d’impact.
Au revoir.

— Au revoir. Bonne journée.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée.

Les champs obligatoires sont indiqués par *.