SaaSApplication métierPMEContratMéthode
Accessibilité d’un SaaS et European Accessibility Act : qui est concerné, quoi faire ?
10 min de lecture
L'European Accessibility Act (directive (UE) 2019/882) s'applique en France depuis le 28 juin 2025. Il impose l'accessibilité aux personnes handicapées d'une liste fermée de produits et de services destinés aux consommateurs, dont le commerce électronique. Un SaaS vendu au grand public est donc souvent concerné ; un SaaS purement B2B l'est rarement de façon directe, mais peut l'être à travers ses clients. Les microentreprises qui fournissent des services sont exemptées. Voici comment savoir où vous en êtes, et ce qu'il faut faire, d'après les textes officiels consultés le 6 novembre 2026.
Ce guide donne une lecture générale des textes ; il ne remplace pas l'analyse d'un juriste sur votre cas précis.
Le cadre en France, en quatre textes
- La directive (UE) 2019/882, dite European Accessibility Act (EAA), fixe les produits et services visés et les exigences d'accessibilité.
- La loi n° 2023-171 du 9 mars 2023 (article 16) l'a transposée, principalement dans le code de la consommation (article L. 412-13).
- Le décret n° 2023-931 et un arrêté du 9 octobre 2023 fixent la liste des services et les exigences techniques. L'article D. 412-57 du code de la consommation détaille les obligations des prestataires de services.
- Un décret n° 2026-883 du 23 septembre 2026 est venu renforcer l'application de ces dispositions. Vérifiez le texte consolidé sur Légifrance avant toute décision : le cadre bouge encore.
La fiche de la DGCCRF présente ces obligations aux professionnels, et la page de la Commission européenne donne la vue d'ensemble européenne.
Ne confondez pas avec une obligation plus ancienne : l'article 47 de la loi du 11 février 2005 impose déjà l'accessibilité des services en ligne au secteur public et à certaines grandes entreprises, avec le RGAA comme référentiel. L'EAA élargit le sujet à des entreprises privées qui n'étaient pas visées jusque-là.
Votre SaaS est-il concerné ? Trois questions
1. Vendez-vous à des consommateurs ?
La directive ne vise pas « le logiciel » en général. Elle vise des services fournis aux consommateurs, dans six familles :
| Service visé | Exemple de SaaS ou d'application concernée |
|---|---|
| Commerce électronique | Abonnement en ligne à une application grand public, boutique, réservation payante |
| Services bancaires aux consommateurs | Application de gestion de compte, de crédit, de paiement |
| Communications électroniques | Messagerie, téléphonie par internet |
| Accès aux services de médias audiovisuels | Plateforme de vidéo à la demande, guide de programmes |
| Transport de voyageurs (aérien, bus, rail, maritime) | Site, application mobile, billet électronique, information en temps réel |
| Livres numériques | Liseuse logicielle, plateforme de lecture |
La famille qui concerne le plus d'éditeurs est le commerce électronique : un service fourni à distance, par voie électronique, à la demande d'un consommateur, en vue de conclure un contrat avec lui. Un SaaS grand public qui se souscrit en ligne entre dans ce cadre, au moins pour son parcours d'achat. La portée exacte pour le reste de l'application fait encore débat ; la lecture prudente consiste à rendre accessible tout ce que le consommateur utilise.
2. Votre SaaS sert-il un service visé chez votre client ?
Un SaaS B2B, réservé à des comptes professionnels, sort en principe du champ direct. Mais si votre logiciel fournit la page de réservation d'un transporteur, le tunnel de commande d'un commerçant en ligne ou l'espace client d'une banque, c'est votre client qui est soumis à l'obligation, et c'est sur votre interface qu'elle porte. Attendez-vous alors à une clause d'accessibilité dans le contrat, avec une exigence de conformité à la norme EN 301 549. Notre article sur le contrat SaaS, les CGV et le SLA aide à préparer ce type de clause.
Deux autres situations font entrer l'accessibilité dans un SaaS B2B, hors EAA : la vente au secteur public, où l'accessibilité figure dans les exigences des acheteurs, et les clients qui ont eux-mêmes une politique d'inclusion pour leurs salariés.
3. Êtes-vous une microentreprise ?
Pour les services, une entreprise qui emploie moins de 10 personnes et dont le chiffre d'affaires annuel ou le total de bilan ne dépasse pas 2 millions d'euros est exemptée des exigences d'accessibilité (article L. 412-13 du code de la consommation, qui reprend l'article 4 de la directive). Trois précisions :
- l'exemption vaut pour les services, pas pour les produits ;
- elle se perd dès que l'un des seuils est franchi : une jeune pousse qui recrute ou qui lève des fonds doit anticiper ;
- une entreprise exemptée qui vend des services à une entreprise soumise reste exposée aux exigences contractuelles de cette dernière.
Le texte prévoit aussi deux portes de sortie, à documenter si vous les invoquez : l'exigence qui modifierait fondamentalement la nature du service, et la charge disproportionnée, évaluée selon des critères fixés par décret. Elles ne s'appliquent pas « par défaut » et ne couvrent pas un simple manque de budget.
Les dates à connaître
| Date ou délai | Ce qui s'applique |
|---|---|
| 28 juin 2025 | Exigences applicables aux services fournis et aux produits mis sur le marché |
| Jusqu'au 28 juin 2030 | Les contrats de services conclus avant le 28 juin 2025 peuvent courir jusqu'à leur terme, au plus tard à cette date |
| Jusqu'au 28 juin 2030 | Les produits déjà utilisés pour fournir un service avant le 28 juin 2025 peuvent continuer à servir |
La période transitoire ne vaut pas pour une nouvelle souscription, ni pour une nouvelle version du service mise en ligne depuis. Un SaaS grand public lancé ou refondu en 2026 est attendu conforme dès son ouverture.
Les référentiels : WCAG, EN 301 549, RGAA
Trois noms reviennent, et ils s'emboîtent :
- WCAG : les règles du W3C pour le contenu web. La version 2.1 au niveau AA est le socle commun ; la version 2.2 ajoute quelques critères utiles (taille des cibles, aide à l'authentification).
- EN 301 549 : la norme européenne d'accessibilité des produits et services numériques. Pour le web, elle reprend les WCAG 2.1 AA ; elle couvre aussi les logiciels, les documents et les applications mobiles. C'est la référence pour présumer la conformité.
- RGAA : le référentiel général d'amélioration de l'accessibilité, méthode française de test en 106 critères, obligatoire pour le secteur public. La version 4.1.2 est en vigueur ; la version 5 est en cours de rédaction, avec une publication annoncée pour fin 2026. Pour un éditeur privé, c'est une méthode d'audit pratique et reconnue en France.
Ce que l'EAA impose concrètement à un éditeur
Un service utilisable par tous
Les exigences reprennent les quatre principes des WCAG : perceptible, utilisable, compréhensible, robuste. Pour un SaaS, cela se traduit par des contrôles très concrets :
- tout le parcours se fait au clavier, avec un focus visible ;
- les contrastes de texte et d'éléments d'interface sont suffisants ;
- chaque champ de formulaire a une étiquette et des messages d'erreur explicites, annoncés aux lecteurs d'écran ;
- les images utiles ont un texte alternatif, les icônes seules ont un nom accessible ;
- les composants riches (menus, fenêtres modales, onglets, sélecteurs de date) respectent les rôles et états attendus ;
- l'interface supporte le zoom à 200 % et l'affichage étroit sans perte de contenu ;
- les tableaux et graphiques ont une alternative lisible ;
- les délais (expiration de session, paiement) peuvent être prolongés ;
- l'authentification n'exige pas de mémoriser ou recopier un code sans aide.
Une information publique sur l'accessibilité
L'article D. 412-57 impose au prestataire d'établir des informations qui expliquent comment le service respecte les exigences, de les rendre accessibles au public, par écrit et oralement, et de les conserver tant que le service est proposé. En pratique, une page dédiée ou une section des conditions générales, accessible elle-même, décrit le service, les fonctions d'accessibilité et les éventuelles limites.
Une conformité suivie dans le temps
Le prestataire doit avoir des procédures pour rester conforme quand le service évolue, prendre des mesures correctives en cas de non-conformité et coopérer avec les autorités de contrôle sur demande motivée. Pour un SaaS qui livre chaque semaine, cela signifie des tests d'accessibilité dans le cycle de développement, pas un audit annuel isolé.
Le plan d'action, dans l'ordre
- Qualifiez votre situation : clientèle (consommateurs ou professionnels), service visé, taille, contrats en cours. Datez la conclusion.
- Faites un audit sur un échantillon représentatif : inscription, connexion, paiement, écrans principaux, formulaires les plus longs. Combinez outils automatiques et tests manuels au clavier et au lecteur d'écran : les outils seuls ne détectent qu'une partie des problèmes.
- Corrigez d'abord les bloquants : ce qui empêche de s'inscrire, de payer, de résilier ou d'utiliser la fonction principale.
- Corrigez à la source : un composant de bouton ou de formulaire corrigé une fois répare des centaines d'écrans. C'est là que se joue l'essentiel du coût.
- Publiez l'information d'accessibilité et un moyen de signaler un problème.
- Intégrez des contrôles dans la livraison continue : tests automatiques sur les composants, recette manuelle sur les parcours clés.
- Formez l'équipe produit et design : un écran accessible se dessine accessible.
Si l'audit révèle une interface trop ancienne pour être corrigée écran par écran, la question devient celle d'une refonte. Notre article sur l'audit d'une application existante explique comment trancher.
Les erreurs fréquentes
- Compter sur une surcouche d'accessibilité ajoutée par un script : elle ne corrige pas le code de l'interface, et ne rend pas conforme à la norme.
- Croire que « B2B » veut dire « hors sujet » alors que votre client vend à des consommateurs à travers votre interface.
- Traiter le site vitrine et oublier l'application : c'est le parcours de souscription et d'usage qui compte.
- Oublier les documents : factures et exports en PDF, e-mails transactionnels, aide en ligne.
- Auditer une fois et livrer ensuite sans contrôle : chaque nouvelle fonction peut réintroduire des défauts.
Intégrer l'accessibilité dès la conception
Corriger un SaaS existant coûte d'autant plus cher que les composants ont été écrits sans y penser. Dans un projet neuf, l'accessibilité se décide dans le choix de la bibliothèque de composants, dans la maquette et dans la recette, pour un surcoût modeste. C'est aussi un argument commercial auprès des grands comptes et des acheteurs publics. Notre article sur le coût de développement d'un SaaS donne les ordres de grandeur d'un projet, et celui sur le choix entre application web, PWA ou native rappelle que chaque support a ses propres règles d'accessibilité.
LPR Studio conçoit des applications web avec des composants accessibles dès le départ, et ce site lui-même est contrôlé automatiquement sur ses pages clés. Si vous préparez un SaaS ou la refonte d'une interface, nous vous présentons en visio, sous 5 jours ouvrés, un prototype gratuit de vos écrans principaux : c'est le principe de voir son logiciel avant de le payer.