MOBILE

Le référentiel RAAM

Le RAAM est le référentiel qui permet d’évaluer l’accessibilité d’une application mobile native, critère par critère. Édité au Luxembourg, aligné sur la norme européenne, c’est aujourd’hui la méthode utilisée en France, faute d’équivalent national. Voici ce qu’il couvre.

Auditer mon application mobile Voir notre audit mobile
DÉFINITION

Qu’est-ce que le RAAM ?

Le RAAM – référentiel d’évaluation de l’accessibilité des applications mobiles – est une méthode de test publiée par le Service information et presse (SIP) du Grand-Duché de Luxembourg. Il traduit les exigences d’accessibilité applicables aux applications mobiles natives en critères vérifiables, un par un.

Sa version en vigueur est la version 1.1, publiée le 24 février 2025. Elle compte 108 critères de contrôle et couvre les exigences de la norme européenne EN 301 549 dans sa version 3.2.1. Le référentiel est diffusé en licence ouverte CC‑BY 3.0 LU et développé publiquement sur GitHub – n’importe qui peut consulter, réutiliser ou commenter ses critères.

Au Luxembourg, il sert de socle d’évaluation aux organismes du secteur public soumis à la loi du 28 mai 2019, et il est mobilisé dans le cadre de la loi du 8 mars 2023 qui transpose l’European Accessibility Act. Sa portée technique, elle, n’a rien de national : elle est européenne.

POURQUOI

Pourquoi la France utilise un référentiel luxembourgeois

En France, les applications mobiles des acteurs publics et des grandes entreprises doivent être accessibles depuis le 23 juin 2021. L’obligation existe donc depuis cinq ans. La méthode pour la vérifier, elle, n’existe pas : le RGAA 4.1.2 est une méthode de test écrite pour le web, et il ne propose aucun protocole applicable à une interface mobile native. Deux voies s’ouvrent alors : auditer directement sur le chapitre 11 de l’EN 301 549, au prix d’un travail d’interprétation important, ou s’appuyer sur un référentiel qui a déjà fait ce travail. C’est ce qu’apporte le RAAM, et c’est la raison pour laquelle il s’est imposé comme la référence de fait des auditeurs francophones – Ipedis compris.

Le RGAA 5, attendu fin 2026, doit intégrer des critères dédiés aux applications mobiles. Il ne rend pas ce choix caduc : il le confirme.

Notre position est explicite

Nous auditons les applications mobiles natives avec le RAAM, aligné sur l’EN 301 549. Vous obtenez un taux de conformité opposable, des non-conformités hiérarchisées et une méthode documentée, plutôt qu’une évaluation au jugé.

PÉRIMÈTRE

Ce que le RAAM évalue

Le RAAM ne se limite pas aux écrans. Il couvre six sections de l’EN 301 549, ce qui en fait un référentiel plus large que la seule interface graphique.

section 05

Exigences génériques

Ce que cela vérifie dans 
l’application : Fonctions d’accessibilité activables et préservées, biocompatibilité, absence de blocage des fonctions d’assistance du système.

section 06

Communication vocale bidirectionnelle

Ce que cela vérifie dans 
l’application : Appels audio et visio intégrés à l’application : qualité, alternatives, restitution.

section 07

Capacités vidéo

Ce que cela vérifie dans 
l’application : Sous-titres, audiodescription et pistes alternatives dans les lecteurs intégrés.

section 10

Documents non web

Ce que cela vérifie dans 
l’application : Documents produits ou affichés par l’application : PDF, justificatifs, conditions générales.

section 11

Logiciels

Ce que cela vérifie dans 
l’application : Le cœur du référentiel : structure, libellés, focus, gestes, contrastes, restitution par VoiceOver et TalkBack.

section 12

Documentation et services support

Ce que cela vérifie dans 
l’application : Aide, FAQ, service client : l’accessibilité de l’assistance elle-même.

Deux enseignements pratiques. D’abord, un audit d’application sérieux inclut les documents que l’application délivre – c’est le point le plus souvent oublié, et il relève de l’accessibilité de vos PDF. Ensuite, il inclut vos canaux de support : une application accessible dont l’aide en ligne ne l’est pas laisse l’utilisateur sans recours.

COMPARATIF

RAAM, RGAA, WCAG, EN 301 549 : qui couvre quoi

Comparatif des référentiel / norme, support visé, portée et sur une application mobile
Référentiel / norme Support visé Portée Sur une application mobile
RAAM 1.1 Applications mobiles natives (iOS, Android) Luxembourg (SIP) Méthode de test directement applicable. 108 critères, tests documentés.
RGAA 4.1.2 Contenus web France (DINUM) Aucune méthode de test mobile. Utilisable uniquement pour les vues web embarquées.
WCAG 2.2 Contenus web Internationale (W3C) Socle conceptuel. Transposition hors web via WCAG2ICT, pas de protocole de test natif.
EN 301 549 V3.2.1 TIC au sens large Européenne (norme harmonisée) Référence légale, notamment son chapitre 11. Exige un travail d’interprétation.

En pratique : la norme dit ce qui est exigé, le RAAM dit comment le vérifier sur une interface native. Pour comprendre l’articulation générale entre textes et référentiels, voir Réglementation & référentiels.

MÉTHODE

Ce que change un audit RAAM, concrètement

Un audit conduit avec le RAAM ne se déroule pas comme un audit web. Trois différences structurent la mission.

L’échantillon se raisonne en parcours, pas en pages

Une application n’a pas d’URL : on sélectionne des parcours fonctionnels complets – inscription, recherche, paiement, contact – et l’on teste chaque écran traversé, dans les deux orientations.

La restitution se vérifie avec les technologies d’assistance du système

VoiceOver sur iOS, TalkBack sur Android, avec les réglages système d’agrandissement, de contraste et de taille de texte. Ce que dit le code compte moins que ce qu’entend et perçoit l’utilisateur.

Les deux plateformes sont auditées séparément

Un même écran peut être conforme sur Android et bloquant sur iOS : les API d’accessibilité ne se comportent pas de la même façon. Un audit qui n’en couvre qu’une n’est pas un audit d’application.

Le résultat

Un taux de conformité par plateforme, des non-conformités priorisées par impact utilisateur réel, et des recommandations formulées dans les termes de vos développeurs – pas dans ceux du référentiel.

CALENDRIER

RAAM 2 : ce qui arrive en janvier 2027

Le référentiel va évoluer, et le calendrier est public.

  • Février 2025 Publication du RAAM 1.1
    Version en vigueur, 108 critères.
  • Automne 2026 Publication attendue de l’EN 301 549 V4.1.1
    Qui intègre les WCAG 2.2 et élargit sensiblement le périmètre de la norme. La version juridiquement en vigueur reste aujourd’hui la V3.2.1.
  • Début janvier 2027 Publication annoncée du RAAM 2 par le SIP
    Aligné sur la nouvelle version de la norme.

Faut-il attendre ?

Non. Les critères qui bloquent réellement vos utilisateurs – libellés, focus, gestes, contrastes – ne changent pas de nature d’une version à l’autre. Reporter un audit d’un an, c’est reporter d’un an la correction des obstacles, et arriver en 2027 avec le même retard.

ACCOMPAGNEMENT

Auditer votre application mobile avec Ipedis

Connaître le référentiel ne suffit pas : il faut l’appliquer à votre application, dans votre contexte technique. Orchestrateur de l’accessibilité numérique, Ipedis est à la fois le chef d’orchestre de solutions techniques et le chef de cœur d’un collectif d’experts. Nous concevons l’accessibilité « by design », et parce que rares sont les projets qui partent d’une page blanche, nous accompagnons aussi « on the way ».

Audit d'accessibilité d'application mobile

Audit RAAM sur iOS et Android, taux de conformité, non-conformités priorisées, feuille de route.

Solutions logicielles

Axe DevTools pour détecter au plus tôt, dans le poste du développeur et dans votre chaîne d'intégration continue.

Coder et développer accessible (app mobile)

Former vos équipes iOS et Android aux critères qu'elles rencontrent réellement.

Accompagnement à la mise en conformité

Remédiation post-audit et pilotage, jusqu'à l'autonomie de vos équipes.

Pionniers de l'accessibilité numérique depuis 2006 : nous faisons de votre conformité un levier de performance durable.

Auditer mon application mobile
faq

Questions fréquentes

Non. Aucun texte français ne l'impose. La loi exige un résultat - une application accessible - et laisse le choix de la méthode d'évaluation. Le RAAM s'est imposé parce qu'il est le seul référentiel francophone documenté pour les interfaces natives, et parce qu'il est aligné sur la norme européenne EN 301 549, elle-même référencée par le droit français et européen.

108 critères de contrôle dans la version 1.1, publiée le 24 février 2025. Ils couvrent six sections de l'EN 301 549 : exigences génériques, communication vocale bidirectionnelle, capacités vidéo, documents non web, logiciels et documentation / services support.

Pas au sens strict. Le RGAA 4.1.2 est une méthode de test écrite pour les contenus web : il ne propose pas de protocole applicable à une interface native. Il reste utile pour les vues web embarquées dans l'application. Le RGAA 5, attendu fin 2026, doit intégrer des critères dédiés au mobile.

Tout sur le RGAA

Les WCAG fixent les objectifs d'accessibilité, mais elles ont été écrites pour le web ; leur transposition hors web passe par les orientations WCAG2ICT. Le RAAM fait ce travail de transposition et le rend testable : il donne, pour chaque critère, la manière de le vérifier sur iOS et sur Android.

Les règles WCAG

Oui. Ce que le référentiel évalue, c'est la restitution effective de l'interface par les API d'accessibilité du système d'exploitation. Que l'application soit développée nativement ou avec un framework multiplateforme ne change pas l'exigence : elle change seulement la manière de corriger.

Non. Une nouvelle version d'un référentiel affine des critères, elle ne réécrit pas le socle : les obstacles corrigés le restent. Un audit conduit aujourd'hui garde sa valeur ; il demandera, après la publication du RAAM 2, une actualisation ciblée sur les critères modifiés - pas un nouvel audit complet.