Audit d’une application mobile : préciser normes et environnements

Mis à jour le 1er octobre 2026 · Rédaction : Plein Accès

Distinguer web mobile et application native

Une page web sur téléphone et une application native n’utilisent pas nécessairement la même méthode d’évaluation. La DINUM indique que la méthode technique RGAA 4.1 ne couvre pas les applications mobiles natives. L’audit doit examiner directement les dispositions pertinentes de la norme de référence selon le cadre applicable. N’achetez donc pas une simple transposition de la grille web sans explication du périmètre normatif et des tests adaptés à la plateforme.

Décrivez l’application : native, hybride ou principalement web, plateformes proposées et fonctions principales. Une interface hybride peut demander plusieurs approches selon les écrans. Le candidat doit expliquer comment il traitera les composants natifs et les contenus web intégrés. Le guide RGAA et EAA aide à qualifier les obligations du service avant de définir cette couverture technique.

Préparer les versions et les appareils

Donnez les versions de l’application et les environnements accessibles en recette. Précisez les systèmes et les appareils prévus au test, puis les lecteurs d’écran natifs retenus. L’auditeur doit pouvoir installer une version identifiable et accéder aux parcours sans utiliser de compte personnel réel. Préparez des données fictives et un moyen de remettre l’application dans son état initial après chaque scénario.

Une mise à jour du système ou de l’application peut changer la restitution. Le rapport doit donc conserver les versions observées. Une preuve sur une seule plateforme ne doit pas laisser croire que l’autre a été testée. Si les différences de code ou de composants sont importantes, demandez une sélection propre à chaque environnement. Les moyens de saisie et les réglages utiles au public doivent aussi être envisagés au cadrage.

Choisir les écrans à partir des tâches

Inventoriez les actions : identification, recherche, consultation, envoi d’une demande et réception d’une confirmation. Ajoutez les autorisations, les erreurs et les états de chargement. Un dialogue système peut faire partie du parcours même s’il n’est pas développé par votre équipe. L’auditeur doit expliquer ce qu’il observe et ce qui relève de la plateforme. L’échantillon doit permettre de suivre les tâches jusqu’à leur résultat.

Certains écrans apparaissent seulement après un geste ou une donnée particulière. Documentez ces conditions avec un scénario reproductible. Pour un service de vente, préparez une transaction simulée. Pour une démarche, évitez toute transmission administrative réelle. Un test sans l’état d’erreur ou sans la fin du processus peut laisser une limite majeure ; elle doit être annoncée dans la restitution plutôt que masquée par la liste des écrans ouverts.

Examiner la restitution et les interactions

Les tests peuvent porter sur le nom des commandes, leur ordre de lecture, les états et les changements après action. L’utilisateur doit pouvoir retrouver le contexte et comprendre les informations nouvelles dans les environnements retenus. Le prestataire doit préciser sa méthode et rattacher les constats aux exigences applicables. Une recommandation générale sur la taille d’un bouton ne remplace pas cette justification.

Les gestes complexes et les composants personnalisés demandent des scénarios dédiés. Demandez comment le candidat vérifiera les moyens de réaliser l’action avec les technologies d’assistance. L’audit doit également examiner le contenu : titres, messages et documents restent nécessaires à la compréhension du service. Le guide du rapport aide à définir des preuves que les équipes mobiles pourront reproduire.

Corriger et suivre chaque plateforme

Attribuez les constats aux équipes qui possèdent les composants. Une modification partagée peut affecter plusieurs écrans, tandis qu’une correction native peut ne concerner qu’un système. Le backlog doit garder cette relation pour éviter de fermer une anomalie sur les deux plateformes après une seule livraison. Rejouez les scénarios dans les versions corrigées et vérifiez les comportements proches.

Les publications W3C sur WCAG2Mobile et WCAG2ICT peuvent éclairer la pratique. Leur statut doit être distingué de celui des textes et normes applicables. Les annonces sur le RGAA 5 ne permettent pas d’affirmer qu’une nouvelle méthode est déjà publiée. Le contre-audit doit documenter la version vérifiée et les limites restantes. Demandez au prestataire une veille sur les références pertinentes, sans suspendre les corrections des obstacles déjà identifiés.

Questions sur les applications

Un audit RGAA web suffit-il pour une application native ?

La DINUM précise que la méthode technique actuelle ne la couvre pas. Demandez l’examen de la norme de référence et des tests adaptés aux plateformes concernées.

Peut-on tester seulement une plateforme ?

Le contrat peut limiter la prestation, mais la restitution doit le dire. Les résultats ne doivent pas être présentés comme une évaluation de l’autre plateforme.

Les notes W3C créent-elles une nouvelle obligation française ?

Leur publication ne suffit pas à modifier le droit applicable. Elles peuvent guider le travail technique ; le référentiel contractuel et les textes doivent être identifiés séparément.

Sources vérifiées le 1er octobre 2026

DINUM : référentiel et obligations