Mise en conformité de votre accessibilité numérique

En corrigeant d’abord, en mesurant ensuite. Nous passons vos écrans en revue sur le référentiel — le RGAA pour le web, le RAAM pour les applications mobiles — et chaque blocage constaté devient un ticket : la page, le composant, ce qui ne va pas, qui ça empêche et à quel point, ce qu’on peut faire, et comment vérifier que c’est fait.

Le lot est versé dans votre outil de suivi (Jira, Azure DevOps, GitHub, GitLab ou Monday, par exemple). Vos équipes corrigent ; nous restons joignables pendant toute la phase et nous répondons quand un ticket les bloque. Quand une correction est faite, nous rejouons la technique de test inscrite dans le ticket avant de le fermer. Le taux de conformité, lui, vient après, de l’audit qui suit la correction.

Le déroulé en trois temps

On rend un site accessible en corrigeant, à la source, ce qui empêche des personnes en situation de handicap de s’en servir : dans le code, les maquettes et les contenus. Il n’y a pas de raccourci. Une surcouche d’accessibilité, ce script qui promet de rendre un site accessible sans toucher à son code, ne remplace pas ces corrections, et nous en dénonçons l’existence.

Le travail suit toujours le même ordre. On relève les blocages écran par écran, chacun devient un ticket, vos équipes corrigent, puis les corrections sont recontrôlées avant d’être fermées. Un audit mesure ensuite ce qui a été obtenu et produit le taux de conformité.

Pour que le résultat tienne, ceux qui font évoluer le site doivent savoir pourquoi il est accessible : c’est le rôle de la formation à l’accessibilité numérique. Pour comprendre le sujet avant de décider, voir ce qu’est l’accessibilité numérique.

Non, et c’est souvent l’inverse de ce qu’on croit. Un audit mené avant la correction mesure ce que vous savez déjà — que votre service n’est pas accessible — et son chiffre est périmé dès le premier écran corrigé. Vous auriez payé pour une photographie que la première semaine de travail rend fausse.

L’audit devient utile après : il valide ce qui a été corrigé, il produit un taux daté sur un service qui a bougé, et il donne le chiffre que vous publierez. L’ordre s’inverse quand il vous faut un taux tout de suite : pour compléter une déclaration manquante ou périmée, par exemple, ou pour une raison qui ne dépend pas de vous.

Ce sont vos équipes, ou le prestataire qui fait déjà évoluer votre service. Pas nous. Ce qui part en production est écrit par ceux qui connaissent le code : c’est ce qui fait qu’ils savent refaire le même geste la fois suivante.

Notre rôle est autour de la correction. Nous produisons les tickets, nous répondons quand une correction bloque, et nous recontrôlons avant de fermer. Il nous arrive de fournir un exemple de code pour débloquer une équipe, mais nous ne faisons pas la remédiation à sa place.

L’appui dure six mois, compris dans le forfait : c’est du service après-vente, pas une livraison. Chaque ticket porte sa technique de test, donc la correction se vérifie sans avoir à nous croire sur parole.

Cela dépend de qui vous êtes. Pour un organisme public, l’Arcom peut sanctionner jusqu’à 25 000 € un document non publié, et jusqu’à 50 000 € un défaut d’accessibilité numérique, avec une mise en demeure publique avant. Pour un service vendu aux consommateurs, la DGCCRF peut enjoindre de corriger et infliger une amende.

Ce qui pèse d’abord est la mise en demeure, qui est publique : en juin 2026, la première visait un site qui s’annonçait « totalement conforme » sans audit à l’appui. Un service qui n’est pas conforme, mais qui le dit et date ce qui est prévu pour y remédier, n’est pas dans cette situation.

Le détail des sanctions, des seuils et des autorités est sur notre page cadre légal et obligations.

Pour un site existant, oui, à condition de le dire. La déclaration d’accessibilité n’attend pas la fin des corrections : elle indique l’état de conformité du service, y compris s’il n’est pas conforme. Ce qui est prévu pour y remédier s’écrit dans le plan d’actions de l’année, où s’inscrit la correction engagée et dont nos tickets sont la matière. Vous pouvez donc faire les deux, publier et corriger.

Le taux, lui, est le résultat d’un audit : il se mesure, il ne s’estime pas, et il porte une date. C’est pour ça qu’il vient après la correction plutôt qu’avant — un chiffre mesuré sur un service qu’on s’apprête à modifier ne vaut que jusqu’à la première modification. Une fois les tickets fermés, l’audit part de vos écrans tels qu’ils sont alors : il ne reprend pas la liste des tickets, il mesure.

L’audit d’accessibilité numérique

Six mois d’appui sont compris dans le forfait, et nous répondons à vos équipes sous deux jours ouvrés. La revue des écrans se fait sur le périmètre convenu au cadrage, mais la correction avance au rythme de vos équipes, et c’est elle qui donne la durée réelle ; au-delà de six mois, la suite se cadre avec vous.

Ce qui dépend de nous est borné — la production des tickets, les réponses pendant la correction, le recontrôle. Ce qui dépend de vous ne l’est pas, et nous ne faisons pas semblant de le maîtriser. Sur une application mobile, ajoutez le rythme de vos publications : une correction n’atteint vos utilisateurs qu’à la version suivante, donc les tickets sont ordonnés sur vos cycles de publication autant que sur leur gravité.

À partir de 9 000 € HT, au forfait. Il comprend la revue des écrans, les tickets, six mois d’appui pendant la correction et le recontrôle. Le périmètre est fixé au cadrage : c’est lui qui fait varier le forfait, pas le nombre de blocages trouvés.

Il ne comprend pas le taux de conformité, qui vient de l’audit mené une fois les écrans corrigés. Il ne comprend pas non plus la correction elle-même : le coût principal est le temps de développement que vos équipes y consacrent. Nous ne le facturons pas, mais nous ne faisons pas comme s’il n’existait pas.

Nous ne donnons pas d’ordre de grandeur pour ce temps avant d’avoir vu vos écrans : il dépend de la façon dont ils sont construits, et il se constate sur le premier lot de tickets.