Le 4 juin 2026, le tribunal judiciaire de Caen a ordonné à Carrefour France de rendre son site et son application mobile pleinement accessibles aux personnes déficientes visuelles, sous six mois et sous astreinte. Pour beaucoup de dirigeants, cette décision fait basculer l'accessibilité numérique du rayon des bonnes intentions vers celui du risque juridique mesurable. Voici ce que cela implique concrètement quand on édite une application mobile, et par où commencer si la vôtre existe déjà.

Une décision de justice qui déplace le curseur

L'action avait été portée par les associations apiDV et Droit Pluriel, avec le soutien du collectif de juristes Intérêt à Agir. Le tribunal a enjoint à Carrefour France de rendre accessibles son site et son application mobile dans un délai de six mois, avec une astreinte de 500 euros par jour de retard et 10 000 euros de dommages et intérêts.

Deux enseignements comptent bien au-delà du commerce alimentaire. D'abord, l'application mobile est visée au même titre que le site : elle n'est pas un canal secondaire que l'on traite plus tard. Ensuite, le tribunal a écarté l'argument d'un taux de conformité déjà atteint, l'entreprise faisant valoir environ 71 pour cent de critères respectés. Un tableau de bord d'audit qui progresse ne constitue donc pas, à lui seul, une défense.

Qui est concerné, et qui ne l'est pas

Le cadre vient de la directive européenne 2019/882, dite European Accessibility Act, transposée en droit français notamment par le décret n° 2023-931. Les obligations s'appliquent depuis le 28 juin 2025 à une liste de services rendus au public : commerce électronique, services bancaires, transport de voyageurs, communications électroniques, livres numériques et services de médias audiovisuels. En cas de manquement, l'autorité de contrôle peut prononcer une sanction pécuniaire pouvant atteindre 50 000 euros par service non conforme, renouvelable si la situation n'est pas corrigée.

Une exemption existe pour les microentreprises de services, sous deux conditions cumulatives : moins de 10 salariés et moins de 2 millions d'euros de chiffre d'affaires annuel. Elle est automatique, mais franchir durablement l'un de ces seuils fait basculer l'entreprise dans le champ de l'obligation.

Trois situations très différentes se cachent derrière la même question :

  • Une application grand public qui vend, réserve, encaisse ou diffuse des contenus entre dans le champ de l'EAA dès lors que l'entreprise dépasse le seuil microentreprise.
  • Une application d'une collectivité ou d'un organisme public relève, elle, de l'article 47 de la loi du 11 février 2005, avec déclaration d'accessibilité et schéma pluriannuel à publier.
  • Une application interne réservée aux salariés n'est pas un service au public au sens de l'EAA. L'employeur reste toutefois tenu de prendre les mesures appropriées pour permettre à un salarié handicapé d'exercer son emploi, outils de travail compris. Et de plus en plus de cahiers des charges, publics comme privés, exigent un niveau d'accessibilité sur les outils internes.

Ce que veut dire accessible sur mobile

La référence technique n'est pas le RGAA, conçu pour le web, mais la norme européenne EN 301 549, dont le chapitre consacré aux logiciels couvre les applications natives. Pour l'évaluer en français, les équipes s'appuient sur le RAAM, référentiel d'évaluation de l'accessibilité des applications mobiles publié par le Luxembourg, qui traduit la norme en critères vérifiables écran par écran.

Concrètement, une application accessible reste utilisable quand l'utilisateur active les réglages d'assistance de son téléphone : lecteur d'écran VoiceOver sur iOS ou TalkBack sur Android, agrandissement des textes, contraste renforcé, réduction des animations. Rien de tout cela n'est une fonctionnalité supplémentaire à développer : il s'agit d'abord de ne pas casser ce que le système fournit déjà.

Les cinq écarts qui font échouer un audit mobile

Sur les applications que nous reprenons, les mêmes causes reviennent :

  1. Les composants maison non étiquetés. Un bouton icône sans libellé accessible est annoncé comme un simple bouton par le lecteur d'écran. C'est la première cause de blocage, et souvent la plus rapide à corriger.
  2. Les tailles de texte figées. Une mise en page calée au pixel près déborde dès que l'utilisateur augmente la police système : le contenu se tronque, ou le bouton de validation sort de l'écran.
  3. L'ordre de lecture incohérent. Fenêtres modales, panneaux glissants et surcouches qui ne retiennent pas le focus renvoient l'utilisateur au hasard dans l'écran précédent.
  4. L'information portée par la seule couleur. Un statut signalé uniquement par une pastille rouge ou verte, sans libellé ni forme distincte, disparaît pour une partie des utilisateurs.
  5. La vue web embarquée. Une application qui affiche des pages du site dans une WebView hérite mécaniquement des défauts de ce site. C'est le point le plus souvent oublié dans les devis de mise en conformité.

Par où commencer quand l'application existe déjà

Auditer une application complète d'un seul tenant produit un rapport long, cher et décourageant. Nous procédons en quatre temps.

1. Délimiter les parcours critiques. Trois à cinq parcours portent l'essentiel de la valeur : se connecter, rechercher, commander, payer, contacter le service client. Un seul parcours interrompu rend l'application inutilisable, même si le reste est irréprochable.

2. Tester avant d'auditer. Activer VoiceOver ou TalkBack et parcourir ces trajets prend une demi-journée, ne coûte rien et révèle déjà l'essentiel des blocages. L'audit formel vient ensuite, sur un périmètre réduit.

3. Corriger par gravité, pas par écran. On traite d'abord ce qui empêche d'aboutir, ensuite ce qui gêne, enfin ce qui alourdit. Cette hiérarchie est aussi celle qui se défend le mieux face à une mise en demeure.

4. Ancrer les règles dans le cycle de développement. Vérification automatisée dans la chaîne d'intégration, revue des maquettes sur les contrastes et la taille des zones tactiles, passage au lecteur d'écran ajouté à la recette de chaque version. Sans cette dernière étape, la conformité se dégrade dès la mise à jour suivante.

Les entreprises soumises à l'EAA doivent aussi publier une déclaration d'accessibilité. Ce volet formel est souvent traité en dernier, alors qu'il est le premier élément regardé en cas de contrôle.

Combien cela coûte, et à quel moment le traiter

Nous ne publions pas de grille type : la charge dépend du nombre d'écrans, de la part de composants développés sur mesure et de la présence de contenus web embarqués. Une chose est sûre en revanche : l'accessibilité intégrée dès la conception coûte une fraction de la même exigence traitée après coup, puisqu'elle n'entraîne ni reprise des maquettes ni campagne de non-régression supplémentaire.

Deux moments sont naturellement favorables : la refonte ou la modernisation d'une application existante, et le lancement d'une version majeure. À défaut, la mise en conformité progressive des parcours critiques reste la voie la plus économique.

Questions fréquentes

Mon application mobile interne est-elle concernée par l'European Accessibility Act ?

Non : l'EAA vise les services rendus au public, pas les outils réservés aux salariés. L'employeur doit en revanche prendre les mesures appropriées pour qu'un salarié handicapé puisse exercer son emploi, outils de travail compris.

Un taux de conformité de 70 pour cent est-il suffisant ?

La décision du tribunal judiciaire de Caen du 4 juin 2026 montre que non. Carrefour France faisait valoir un taux d'environ 71 pour cent et a tout de même été enjoint de rendre son site et son application accessibles sous six mois, sous astreinte. Le taux mesure une progression, il ne vaut pas conformité.

Faut-il faire un audit RGAA pour une application mobile ?

Le RGAA a été conçu pour les sites web. Pour une application native, la référence est la norme européenne EN 301 549, évaluée en pratique à l'aide du référentiel RAAM. Si votre application affiche des pages web dans une vue intégrée, ces pages relèvent en revanche bien des critères web.

Combien de temps faut-il pour mettre une application existante en conformité ?

Cela dépend du nombre d'écrans et de la part de composants sur mesure. Sécuriser trois à cinq parcours critiques représente un chantier de quelques semaines, la couverture complète se planifiant ensuite sur plusieurs versions.

Les surcouches automatiques d'accessibilité règlent-elles le problème ?

Elles corrigent des points de surface, mais ne réparent ni un ordre de lecture incohérent, ni un composant sans libellé, ni une mise en page qui casse à l'agrandissement. Elles ne dispensent donc ni des corrections dans le code, ni de la documentation exigée.

Vous éditez une application mobile et vous vous demandez si elle vous expose ? Nous auditons vos parcours critiques, chiffrons les corrections et les intégrons à votre cycle de versions. Parlons de votre projet.