Ara est un service en ligne gratuit conçu par DesignGouv, une équipe de la direction interministérielle du numérique (DINUM), pour réaliser des audits de conformité au RGAA, partager le rapport et produire la déclaration d'accessibilité. Son code est public sous licence MIT.

Ara, l'outil d'audit RGAA de l'État : notre retour d'usage

En bref : Ara est l’outil gratuit de la DINUM pour mener un audit RGAA. Nous l’utilisons depuis 2024 pour nos audits clients et nos contre-audits, et nous ne reviendrions pas au tableur. Il lui manque pourtant quatre choses dont nous aurions besoin : le travail à plusieurs, l’historique des versions, un plan d’action ordonné et un livrable à nos couleurs. Son code, ses tickets et sa feuille de route sont publics, ce qui permet de suivre où en est chacun de ces points.

Nous menons nos audits d’accessibilité avec un outil de l’État, gratuit, que tout le monde peut utiliser : Ara (nouvelle fenêtre). Nous l’avons ouvert pour la première fois en juillet 2024, pour un audit client, et nous y avons mené depuis six audits complets, dont celui de notre propre site.

Il existe beaucoup de présentations d’Ara, et elles disent toutes à peu près la même chose : c’est officiel, c’est gratuit, c’est manuel. Nous voulions écrire autre chose : un retour d’usage, avec ce qui nous plaît, ce qui nous manque, et ce que l’équipe d’Ara en dit elle-même dans ses tickets.

Ara en quelques mots

Ara est un service en ligne conçu par DesignGouv, une équipe de la direction interministérielle du numérique (DINUM) (nouvelle fenêtre), avec le soutien du FIPHFP. Il sert à réaliser un audit de conformité au RGAA, à en partager le rapport et à produire la déclaration d’accessibilité.

Quelques repères :

une bêta ouverte le 16 novembre 2022, et une sortie de bêta le 16 décembre 2025 (nouvelle fenêtre)
un outil déjà très utilisé : dès mai 2023, la DINUM évoquait plus de 2 000 audits initiés avec Ara (nouvelle fenêtre)
gratuit et sans démarche : une adresse e-mail suffit pour créer un audit, le compte est optionnel
un code public, sur le dépôt GitHub DISIC/Ara (nouvelle fenêtre), sous licence MIT
trois formats d’audit : rapide (25 critères), complémentaire (50 critères) ou complet (106 critères)
un référentiel : le RGAA 4.1.2, la version en vigueur à la date de rédaction

Ce qu’Ara n’est pas

Ara n’est pas un scanner. Vous ne lui donnez pas une adresse pour recevoir un score. La page d’accueil de l’outil le dit d’emblée : Ara n’audite pas automatiquement votre site, et il demande une bonne connaissance de la méthode technique du RGAA.

C’est une grille de saisie, très bien outillée. L’auditeur teste chaque critère sur chaque page de l’échantillon, à la main, avec ses propres outils : inspecteur du navigateur, analyseur de contraste, lecteur d’écran, validateur de code. Ara enregistre le résultat, les erreurs relevées et les recommandations, puis calcule le taux de conformité.

C’est une limite pour qui cherche un résultat immédiat. C’est surtout un choix honnête : une grande partie des critères ne peut pas être tranchée par une machine. Une image a-t-elle une alternative pertinente ? Un titre décrit-il vraiment son contenu ? Seul un humain peut répondre. Nous détaillons ce qu’un outil peut vérifier, et ce qui reste à faire à la main, dans notre liste des critères RGAA.

Un pré-remplissage avec les tests automatisables de façon fiable est d’ailleurs en préparation (ticket 349 (nouvelle fenêtre), ouvert en 2023, et une proposition de code en septembre 2026 (nouvelle fenêtre)). Il ne remplacera pas l’auditeur, mais lui évitera de cocher à la main ce qu’une machine sait vérifier.

Comment nous menons un audit avec Ara

Chez nous, un audit RGAA complet se déroule ainsi, de la commande à la restitution.

Valider l'échantillon de pages Client et Ouzom

Nous proposons un échantillon représentatif (accueil, contact, pages types, parcours clés comme le compte ou la commande) et le faisons valider par le client avant de commencer. C'est sur cet échantillon que portera le taux.
Se répartir les pages Auditeurs

À deux, nous nous partageons les pages de l'échantillon : chacun audite les siennes dans le même audit Ara. Ce découpage limite un risque d'écrasement que nous détaillons plus bas.
Tester et saisir Auditeurs

Pour chaque critère et chaque page : conforme, non conforme ou non applicable. Pour une non-conformité, nous décrivons l'erreur, la recommandation, l'impact pour l'usager (mineur, majeur ou bloquant) et nous indiquons si elle est facile à corriger.
Relire Auditeurs

Chacun relit les pages de l'autre. Les erreurs mal qualifiées et les recommandations trop vagues se repèrent bien mieux à deux.
Livrer Ouzom

Le client reçoit le lien du rapport Ara, l'export CSV des résultats, le lien de la déclaration d'accessibilité et, dans le même message, nos recommandations prioritaires, dans l'ordre où nous conseillons de les traiter.
Restituer Client et Ouzom

Une visio d'environ 30 minutes : rappel du référentiel, présentation des outils et de la méthode, lecture du rapport, puis recommandations et plan de mise en conformité.

Après les corrections, nous proposons un contre-audit. Ara n’a pas de fonction dédiée : nous dupliquons l’audit d’origine et nous refaisons passer les critères. C’est aussi la démarche que décrit l’équipe d’Ara dans un de ses tickets (nouvelle fenêtre).

Nous l’avons fait sur notre propre site. Le premier audit, lancé en juillet 2024, donnait 70 % de conformité, avec 17 critères non conformes. Le contre-audit d’avril 2026, après corrections, donne 93 %, avec 4 critères non conformes, dont aucun bloquant. Le rapport du contre-audit (nouvelle fenêtre) est public, comme notre déclaration d’accessibilité.

Capture d'écran de la grille de saisie d'Ara. À gauche, des filtres (masquer les critères évalués, masquer les tests et références, filtrer par statut) et l'avancement par thématique du RGAA. À droite, le critère 10.4 sur l'agrandissement du texte à 200 %, marqué conforme, avec ses tests 10.4.1 et 10.4.2 dépliés et un lien vers la méthodologie de chaque test. — La grille de saisie : chaque critère s’accompagne de ses tests et de leur méthodologie, sans quitter la page.

Ce que nous aimons

Avant Ara, un audit RGAA se menait avec la grille officielle au format tableur (nouvelle fenêtre), la méthodologie ouverte dans un autre onglet et un rapport mis en page à la main. Ara regroupe tout cela, et quatre points nous font gagner du temps à chaque audit.

1. Le rapport se partage par un lien. Le client consulte le rapport sans compte et sans fichier joint. Il est toujours à jour : si nous corrigeons une coquille après la livraison, le client voit la version corrigée. Chaque non-conformité a même sa propre ancre, pratique pour pointer une erreur précise à un développeur.

2. La déclaration d’accessibilité est produite par l’outil. L’auditeur complète quelques informations (contact, technologies utilisées, environnement de test), et Ara assemble la déclaration avec les résultats de l’audit. Depuis 2026, elle peut aussi intégrer le schéma pluriannuel et les plans d’action. Le client n’a plus qu’à la publier sur son site.

3. Les tests et la méthodologie sont sous les yeux. Chaque critère affiche ses tests, la méthodologie de chaque test, les cas particuliers et les notes techniques du RGAA. Pour un auditeur, c’est moins d’allers-retours avec la documentation. Pour un auditeur qui débute, c’est un garde-fou précieux.

4. Le taux se calcule tout seul. Pas de formule à maintenir ni à vérifier : Ara applique la méthode de calcul du RGAA et l’explique dans le rapport. Quand une page ne contient pas certains éléments, par exemple aucun tableau, on peut passer toute la thématique en non applicable d’un clic, et les critères qui en dépendent suivent automatiquement.

Capture d'écran du rapport public Ara de notre contre-audit : titre « Rapport d'audit accessibilité », URL auditée ouzom.fr, audit de 106 critères sur le RGAA version 4.1.2, boutons « Copier le lien du rapport » et « Télécharger ». La synthèse affiche un taux global de conformité de 93 %, 4 critères non conformes dont 0 bloquant, et 52 critères conformes sur 56 applicables. — Le rapport public de notre contre-audit, tel que le client le reçoit.

Ce travail nous a d’ailleurs inspirés : quand nous avons construit Arriu, notre outil d’audit d’écoconception, nous avons repris plusieurs de ses idées.

Ce qui nous manque

Voici notre liste de souhaits, que nous transmettrons à l’équipe d’Ara. Pour chaque point, nous avons cherché dans le suivi des tickets (nouvelle fenêtre) et dans la feuille de route (nouvelle fenêtre) où en est le sujet. L’état décrit est celui d’octobre 2026.

Travailler à plusieurs sur un même audit

Notre besoin : auditer à deux sans risquer d’effacer le travail de l’autre.

Ce qui se passe aujourd’hui : toute personne qui a le lien d’édition peut modifier l’audit, mais Ara ne synchronise pas les saisies en temps réel. Si deux personnes travaillent en même temps, l’une peut écraser les modifications de l’autre, sans alerte. Le problème est décrit dans le ticket « Perte de données dans le cadre d’un audit collaboratif » (nouvelle fenêtre), ouvert en octobre 2024.

Notre contournement : nous découpons l’audit par pages, chacun les siennes, et nous évitons de modifier les mêmes éléments en même temps. Cela limite le risque sans le supprimer.

Où en est le sujet : en juillet 2024, l’équipe annonçait le travail collaboratif parmi ses prochains chantiers (nouvelle fenêtre), avec les exports et les tests automatiques. Il figure aujourd’hui dans la section « Plus tard » de la feuille de route, sous le nom « Collaboration multi-auditeurices ». En attendant, des choses bougent sur le partage : depuis juin 2026, on peut transférer un audit à un autre compte, et un chantier est en cours pour rendre les audits privés par défaut et choisir avec qui les partager (ticket 1403 (nouvelle fenêtre)).

Garder l’historique d’un audit

Notre besoin : retrouver l’état d’un audit à une date donnée, et comparer un contre-audit à l’audit d’origine.

Ce qui se passe aujourd’hui : Ara ne conserve pas d’historique des versions. La seule façon de figer un état est de dupliquer l’audit, ce que nous faisons à chaque contre-audit en ajoutant un numéro de version à son nom. Depuis début 2026, la duplication ne copie plus la déclaration d’accessibilité, pour éviter d’afficher une déclaration périmée : une bonne décision, qui oblige toutefois à la ressaisir.

Ce qui nous aiderait : une vue « avant / après » entre deux audits du même site, critère par critère. C’est exactement ce que le client veut voir après des corrections, et ce que nous reconstituons aujourd’hui à la main.

Où en est le sujet : nous n’avons trouvé ni ticket ni ligne de feuille de route sur ce point. Ce sera le premier retour que nous enverrons.

Ordonner les corrections

Notre besoin : remettre au client un plan d’action dans l’ordre où traiter les erreurs.

Ce qui se passe aujourd’hui : Ara fait déjà une bonne partie du chemin. Chaque erreur porte un impact pour l’usager (bloquant, majeur ou mineur) et une mention « facile à corriger », et le rapport permet de filtrer les non-conformités sur ces deux critères. Depuis juillet 2026, on peut aussi saisir plusieurs erreurs pour un même critère. En revanche, le rapport reste organisé par page et par critère : il ne propose pas de liste ordonnée des corrections.

Notre contournement : nous rédigeons nous-mêmes les quatre ou cinq priorités dans le message de livraison, et nous les reprenons en restitution.

Où en est le sujet : un « rapport centré sur les erreurs » est en cours de développement selon la feuille de route, ainsi qu’un mode d’audit « par non-conformités » à venir. L’export vers des outils de tickets, qui permettrait d’envoyer les corrections directement aux développeurs, est prévu plus tard.

Capture d'écran de l'onglet « Détails des non-conformités » du rapport Ara. À gauche, la navigation par page (éléments transverses, accueil, contact, page d'audit, page d'article) et des filtres par impact de l'erreur : bloquant (0), majeur (3), mineur (4), impact non renseigné (0), ainsi qu'une case « Uniquement les erreurs faciles à corriger ». À droite, le critère 3.2 sur le contraste, avec une non-conformité étiquetée « Impact majeur » et « Facile à corriger », la description de l'erreur et la recommandation. — Les non-conformités se filtrent par impact et par facilité de correction, mais restent classées par page.

Un livrable à nos couleurs

Notre besoin : remettre un rapport à l’identité de notre agence, et un document que le client peut archiver ou joindre à un marché.

Ce qui se passe aujourd’hui : le rapport porte l’identité de l’État et n’accepte ni logo ni mise en forme. Le bouton « Télécharger » du rapport propose un fichier CSV des résultats, pas de PDF. Une demande d’export du rapport, ouverte en 2023, a été fermée en août 2026 (nouvelle fenêtre) comme non prévue.

Notre contournement : le lien du rapport, plus le CSV pour qui veut retraiter les données, plus notre message de livraison. Cela convient à la plupart de nos clients. Les acheteurs publics, qui demandent souvent un document daté et figé, restent un cas plus délicat.

Où en est le sujet : un « export des livrables » (grille d’audit et rapport) figure dans la section « À venir » de la feuille de route, et des tickets plus précis sont ouverts (export complet au format tableur (nouvelle fenêtre), export des anomalies (nouvelle fenêtre)). La personnalisation de l’apparence n’y figure pas, ce qui se comprend pour un service de l’État.

Un outil qui évolue en public

Ara se construit à découvert, et c’est sans doute ce que nous apprécions le plus.

Le code est public et le dépôt est actif : une demi-douzaine de personnes y ont contribué ces douze derniers mois.
Les notes de version (nouvelle fenêtre) retracent chaque évolution. Il n’y a pas de numéro de version, mais une entrée datée par nouveauté.
La feuille de route (nouvelle fenêtre) distingue ce qui est en cours, à venir et prévu plus tard.
Les tickets montrent les arbitrages : ce qui est accepté, ce qui est refusé, et pourquoi.

Pour un prestataire, cela permet d’anticiper ce qui arrive et de savoir où faire remonter un besoin. Si vous utilisez Ara, deux canaux existent : les tickets GitHub (nouvelle fenêtre) si vous avez un compte, ou le formulaire « Donner mon avis » et l’adresse ara@design.numerique.gouv.fr indiqués sur le site.

Et le RGAA 5 ?

À la date de rédaction de cet article, Ara est en RGAA 4.1.2. L’intégration du RGAA 5 figure dans la section « À venir » de la feuille de route. Les tickets préparent le terrain : enregistrer la version du référentiel dans chaque audit (ticket 1050 (nouvelle fenêtre)), pour que les anciens audits restent en RGAA 4.1.2 et que les nouveaux puissent passer au RGAA 5, en version web, mobile ou bureautique.

En pratique, un audit fait aujourd’hui sur le RGAA 4.1.2 garde sa valeur : la DINUM a annoncé que les déclarations publiées avant le RGAA 5 resteront valables 18 mois, dans la limite de 3 ans.

Faut-il utiliser Ara ?

Si vous êtes auditeur ou auditrice RGAA, oui, sans hésiter. Ara ne vous fera pas gagner de temps sur les tests eux-mêmes, mais il vous en fera gagner sur tout le reste : saisie, calcul, rapport, déclaration. Prévoyez seulement un contournement pour le travail à plusieurs et pour le livrable final.

Si vous êtes une organisation qui veut savoir où en est son site, Ara n’est pas fait pour vous seul. Il suppose de maîtriser la méthode du RGAA. Pour un premier aperçu, notre analyseur gratuit contrôle automatiquement une partie des critères. Pour un audit complet, avec un taux de conformité, un plan d’action ordonné et une déclaration prête à publier, nous réalisons des audits RGAA, avec Ara.

Nous enverrons cet article à l’équipe d’Ara, avec nos suggestions. Nous le mettrons à jour quand les points ci-dessus évolueront.

Questions fréquentes sur Ara

Qu’est-ce qu’Ara ?

Ara est un service en ligne gratuit conçu par DesignGouv, une équipe de la DINUM, pour réaliser des audits de conformité au RGAA, partager le rapport et produire la déclaration d’accessibilité. Son code est public sous licence MIT.

Ara audite-t-il un site automatiquement ?

Non. Ara est une grille de saisie : c’est l’auditeur qui teste chaque critère et qui renseigne les résultats. Un pré-remplissage avec les tests automatisables de façon fiable est en préparation, mais il n’est pas disponible à la date de rédaction.

Ara est-il réservé au secteur public ?

Nous n’avons trouvé aucune restriction de ce type. L’outil est gratuit et une adresse e-mail suffit pour créer un audit. En revanche, il suppose une bonne connaissance de la méthode technique du RGAA.

Peut-on exporter un rapport Ara en PDF ?

Non. Le rapport se partage par un lien, et l’export se limite à un fichier CSV des résultats par critère. La demande d’export PDF a été fermée par l’équipe en août 2026, et un export des livrables figure dans la section « À venir » de la feuille de route.

Ara gère-t-il le RGAA 5 ?

À la date de rédaction, Ara est en RGAA 4.1.2. L’intégration du RGAA 5 figure dans la section « À venir » de la feuille de route, et des tickets prévoient d’enregistrer la version du référentiel dans chaque audit.

Transparence : comment cet article a été produit

Nous utilisons l’intelligence artificielle dans notre travail éditorial, et nous préférons le dire clairement.

Pour cet article, elle a servi à parcourir le dépôt public d’Ara (tickets, notes de version, feuille de route), à rechercher les articles existants sur l’outil et à proposer une première rédaction. Le retour d’usage, lui, est le nôtre : nos audits, nos contournements et nos souhaits.

Chaque affirmation sur Ara a été vérifiée dans le dépôt, dans l’outil ou sur les sites de la DINUM, et renvoie à sa source. Les captures d’écran proviennent de notre propre audit dans Ara.

Ressources

← Tous les articles