Accessibilité numérique obligatoire : votre application est-elle concernée ?

Pendant vingt ans, l’accessibilité numérique est restée en France une affaire de sites publics et de très grandes entreprises. Depuis l’été 2025, elle concerne aussi la PME qui vend sur son application. Si vous êtes propriétaire d’une application mobile ou d’un SaaS grand public, voici ce que la loi exige, ce qu’elle n’exige pas, et ce que coûte une mise en conformité.

Que change l’obligation d’accessibilité numérique depuis le 28 juin 2025 ?

Depuis le 28 juin 2025, les sites et applications qui fournissent à des consommateurs un service de commerce en ligne, de banque, de transport de voyageurs, de communications électroniques, d’accès à l’audiovisuel ou de livre numérique doivent être accessibles aux personnes handicapées. Jusque-là, seuls le secteur public et les entreprises de plus de 250 millions d’euros y étaient tenus.

L’Acte européen sur l’accessibilité (European Accessibility Act, ou EAA) est la directive (UE) 2019/882 qui impose des exigences d’accessibilité communes à une liste fermée de produits et de services, applicable depuis le 28 juin 2025 dans toute l’Union.

En France, elle est transposée par l’article 16 de la loi n° 2023-171 du 9 mars 2023, qui crée l’article L. 412-13 du code de la consommation. Le décret n° 2023-931 du 9 octobre 2023 fixe la liste des services et les obligations des entreprises, un arrêté du même jour les exigences techniques.

Les délais qui courent jusqu’au 28 juin 2030 ne protègent pas votre application. L’un vise les produits déjà en service, comme les bornes, et la DGCCRF précise qu’une application n’est pas un produit au sens de la directive. L’autre ne couvre que les contrats grand public signés avant le 28 juin 2025.

Votre application est-elle concernée par l’accessibilité obligatoire ?

Votre application est concernée si trois conditions sont réunies : elle s’adresse à des consommateurs, elle relève d’un des six secteurs listés, et votre entreprise n’est pas une microentreprise. Un SaaS vendu uniquement à des professionnels sort du champ de l’Acte européen, mais un second régime peut le rattraper.

Le piège courant est le commerce électronique, que la directive définit comme un service fourni à distance, à la demande d’un consommateur, en vue de conclure un contrat. Une application qui vend un abonnement peut y entrer pour son parcours d’achat.

L’exemption des microentreprises est étroite. Elle vise les entreprises de services de moins de 10 personnes dont le chiffre d’affaires annuel ou le total du bilan n’excède pas 2 millions d’euros. Une startup de 12 salariés sans chiffre d’affaires est concernée. Une société de 6 personnes à 3 millions de chiffre d’affaires, mais 1,5 million de bilan, reste exemptée.

Deux autres exceptions existent : une modification fondamentale du service, ou une charge disproportionnée, mesurée en ratios de coûts et de chiffre d’affaires. L’évaluation se documente et se déclare à l’autorité de contrôle ; pour la charge disproportionnée, elle se renouvelle au moins tous les cinq ans.

Le second régime est l’article 47 de la loi du 11 février 2005. Il vise les organismes publics et les entreprises dont le chiffre d’affaires moyen en France dépasse 250 millions d’euros sur trois exercices, pour tous leurs services : sites, intranets, extranets, applications et progiciels.

La méthode pour savoir où vous en êtes :

1. Listez qui utilise et paie l’application. Seule la partie grand public compte pour l’Acte européen.
2. Situez le service dans les six secteurs. Une vente en ligne à un particulier, abonnement compris, vous rapproche du commerce électronique.
3. Vérifiez vos chiffres du dernier exercice : effectif, chiffre d’affaires, total du bilan.
4. Regardez vos clients. Un organisme public ou une entreprise de plus de 250 millions d’euros de chiffre d’affaires en France doit rendre accessibles ses progiciels, donc le vôtre.
5. Repérez les contenus exemptés : vidéos et documents bureautiques publiés avant le 28 juin 2025, contenus de tiers que vous ne contrôlez pas, archives figées depuis.

Que demande la loi : quelle norme, quel niveau WCAG, quelle déclaration ?

La loi exige que votre site et votre application soient perceptibles, utilisables, compréhensibles et robustes pour une personne handicapée, que vous publiiez des informations expliquant comment le service respecte ces exigences, et que cette conformité tienne dans le temps. Elle ne cite aucune norme : les normes européennes harmonisées valent présomption de conformité.

Concrètement, d’après la fiche de la DGCCRF destinée aux professionnels : un équivalent textuel pour tout contenu non textuel, toutes les fonctions utilisables au clavier, assez de temps pour agir, une compatibilité avec les technologies d’assistance. Pour le commerce en ligne, l’identification et le paiement doivent suivre.

Le décret impose au prestataire de services de :

• concevoir et fournir un service conforme ;
• publier dans ses conditions générales, ou un document équivalent, comment le service est accessible, et conserver ces informations tant qu’il existe ;
• rester conforme à chaque évolution, corriger et informer les autorités en cas d’écart.

La DGCCRF renvoie vers trois références. Les WCAG (Web Content Accessibility Guidelines) sont des règles internationales publiées par le W3C qui décrivent comment rendre un contenu numérique utilisable par les personnes handicapées, en trois niveaux : A, AA et AAA. La norme EN 301 549 est la norme européenne d’accessibilité des produits et services numériques qui reprend les critères A et AA des WCAG 2.1 et ajoute des exigences pour les logiciels. Le RGAA (référentiel général d’amélioration de l’accessibilité) est la méthode officielle française qui traduit ces règles en 106 critères de contrôle testables. La cible est donc le niveau AA des WCAG 2.1.

Le RGAA s’applique-t-il à une application mobile ?

Pas directement. D’après l’introduction de la méthode du RGAA, le RGAA 4.1 vérifie des pages web en HTML et ne couvre pas les applications mobiles natives : elles se contrôlent avec la norme EN 301 549, notamment sa partie logiciels. Le RGAA 5, annoncé pour fin 2026, doit ajouter des tests pour les applications mobiles et intégrer les WCAG 2.2.

Faut-il publier une déclaration d’accessibilité ?

Une déclaration d’accessibilité est un document public qui indique le niveau de conformité d’un site ou d’une application, liste les contenus non accessibles et donne un moyen de signaler un défaut. Elle est obligatoire sous l’article 47 : totalement conforme, partiellement conforme à partir de 50 % des critères du RGAA respectés, non conforme sinon. Sous l’Acte européen seul, reprenez ce format : la DGCCRF cite le rapport d’audit RGAA comme exemple d’information à publier.

Quelles sanctions en France si votre application n’est pas accessible ?

Pour les services grand public visés par l’Acte européen, la DGCCRF peut enjoindre la mise en conformité, avec astreinte et publicité éventuelles, et chaque manquement est une contravention de 5e classe punie de 7 500 € d’amende, cumulable avec les autres infractions constatées. Les contrôles ont commencé le 28 juin 2025, notamment sur signalement.

Le code de la consommation distingue plusieurs infractions : fournir un service non conforme, ne pas publier les informations d’accessibilité, ne pas informer les autorités, ne pas transmettre les justificatifs. Une application inaccessible qui ne publie rien cumule déjà deux infractions.

Sous l’article 47, l’ARCOM met en demeure publiquement, puis peut sanctionner jusqu’à 50 000 € un organisme public au service inaccessible, et jusqu’à 25 000 € l’absence de déclaration ou de schéma pluriannuel, y compris pour les entreprises de plus de 250 millions d’euros. La sanction peut être renouvelée si le manquement dure six mois de plus.

Le risque ne vient pas que de l’administration : depuis fin 2025, des associations de personnes déficientes visuelles assignent en justice de grandes enseignes du commerce en ligne pour l’inaccessibilité de leurs sites et applications.

Que permettent Flutter et le web pour rendre une application accessible ?

Flutter et le web fournissent les briques de l’accessibilité, mais aucun des deux ne rend une application conforme tout seul. Flutter décrit chaque écran aux lecteurs d’écran d’iOS et d’Android ; le HTML porte nativement le sens des titres, des boutons et des formulaires. La conformité se joue dans la conception, puis dans les tests de chaque version.

Un lecteur d’écran est un logiciel d’assistance qui lit à voix haute le contenu de l’écran et permet de naviguer par gestes ou au clavier, comme VoiceOver sur iPhone et TalkBack sur Android.

Ce que la documentation officielle de Flutter permet d’affirmer :

• les widgets standards génèrent automatiquement ce que lisent VoiceOver et TalkBack ; un composant maison se décrit à la main avec le widget Semantics ;
• le texte suit la taille de police du téléphone, mais chaque écran doit garder la place de l’afficher en très grand ;
• des tests automatisés vérifient la taille des zones tactiles (48 × 48 sur Android, 44 × 44 sur iOS), les libellés et le contraste ;
• sur le web, l’accessibilité de Flutter est désactivée par défaut, pour des raisons de performance, sauf si l’équipe l’active dans le code.

Ces tests ne remplacent pas le passage au lecteur d’écran. Une application web en HTML, comme une application web installable (PWA), part avec un avantage : le RGAA s’applique directement à ses pages.

Notre position : pour une application grand public sur les stores, Flutter convient, avec un test au lecteur d’écran dans la recette de chaque version. Pour un site marchand ou un SaaS grand public dans un navigateur, préférez le HTML, en Vue.js chez Krafter, à Flutter web. Flutter tourne chez nous en production depuis 2024, notamment sur Melimelo et ses plus de 50 versions publiées : notre pratique de Flutter détaille la méthode.

Les erreurs que nous retrouvons sur les applications reprises :

• des boutons réduits à une icône, sans libellé ;
• du texte gris clair sous le contraste de 4,5:1 recommandé pour le texte courant ;
• des écrans qui coupent le texte dès que la police grossit ;
• des conditions générales sans une ligne sur l’accessibilité.

Combien coûte la mise en accessibilité d’une application ?

Le coût dépend de l’état de départ. Une application récente et bien construite se corrige au temps passé, entre 700 et 1 100 € HT par jour chez Krafter. Une application faite ailleurs commence par un audit de 1 à 3 jours, soit 700 à 3 300 € HT. Une application trop ancienne se reconstruit.

Une seule infraction constatée coûte 7 500 €, plus que l’audit le plus long. Le plancher à 6 000 € vaut quand les écrans et les règles sont déjà définis. Il s’explique par un socle open source, deux associés seniors qui s’appuient sur l’IA et relisent chaque ligne, et l’absence de couche commerciale. Le détail figure dans notre article sur le coût d’une application mobile pour une entreprise.

Prenons un scénario type. Une enseigne régionale de 25 salariés vend en ligne par une application Flutter développée en 2023 par un prestataire parti. Elle n’est pas une microentreprise : son parcours d’achat relève de l’Acte européen. L’audit de reprise, mené en deux jours, soit 1 400 à 2 200 € HT, relève des boutons sans libellé, des prix barrés trop pâles et un paiement qui casse quand la police grossit. Le plan chiffré traite d’abord le parcours d’achat, au temps passé, puis un test au lecteur d’écran entre dans la recette de chaque version.

Pour situer votre cas, le simulateur de budget donne une fourchette en 8 questions. Pour un produit web, voyez notre approche du développement SaaS.

Quand l’accessibilité n’est-elle pas obligatoire, et faut-il s’en occuper quand même ?

L’accessibilité n’est pas obligatoire pour un SaaS vendu uniquement à des professionnels, pour une microentreprise de services, ni pour une application grand public hors des six secteurs visés. Elle reste utile dans trois cas : vos clients sont publics ou très grands, votre croissance va vous faire franchir les seuils, ou une intervention sur l’application est déjà prévue.

Vos clients d’abord : un organisme public ou une entreprise de plus de 250 millions d’euros de chiffre d’affaires en France doit rendre accessibles ses progiciels, votre SaaS compris. Comme pour la conformité RGPD d’un SaaS, la question arrive par l’acheteur avant toute autorité. Votre croissance ensuite : une startup qui passe à 10 personnes sort de l’exemption, mieux vaut être prêt avant. Votre calendrier enfin : si l’application doit de toute façon être mise à jour pour l’obligation Android 16 de Google Play, traitez l’accessibilité dans le même chantier.

Ce que nous déconseillons : payer un audit RGAA complet pour un MVP professionnel de 20 utilisateurs. Commencez par les fondamentaux, qui coûtent peu s’ils sont prévus dès la maquette : libellés, contrastes, tailles de texte, navigation au clavier. Et pour un audit opposable, destiné à un appel d’offres ou à une déclaration, choisissez un auditeur indépendant : l’équipe qui corrige ne devrait pas certifier son propre travail.

Cette semaine, appliquez les cinq étapes ci-dessus. Si votre application est concernée, activez VoiceOver ou TalkBack et tentez un achat complet sans regarder l’écran : dix minutes suffisent. Puis parlez-nous de votre application : un des deux fondateurs vous répond sous 24 à 48 heures, avec un avis honnête sur ce qui doit être corrigé et ce qui peut attendre.