Depuis le 28 juin 2025, l’European Accessibility Act (EAA) s’applique dans toute l’Union européenne. Cette directive impose des exigences d’accessibilité aux produits et services numériques, y compris les logiciels professionnels. Pour les entreprises qui utilisent un ERP au quotidien, la question n’est plus théorique : les interfaces métiers (saisie de commandes, validation de factures, tableaux de bord) doivent être accessibles aux personnes en situation de handicap.
Environ 87 millions de personnes dans l’UE vivent avec une forme de handicap, soit près d’un adulte sur quatre selon Eurostat. L’enjeu dépasse la conformité réglementaire : un ERP accessible profite à l’ensemble des utilisateurs (meilleure ergonomie, navigation au clavier, lisibilité).
Cet article détaille le cadre réglementaire, l’état de préparation des principaux éditeurs, et propose une méthodologie concrète pour auditer et améliorer l’accessibilité de votre ERP.
Qu’est-ce que l’European Accessibility Act et pourquoi elle concerne les ERP
La directive 2019/882 en bref
L’European Accessibility Act (directive 2019/882) a été adoptée le 17 avril 2019. Elle harmonise les exigences d’accessibilité pour les produits et services numériques dans l’ensemble de l’UE. Le périmètre est large : commerce électronique, services bancaires, transports, livres numériques, mais aussi les “services fournis par voie électronique” au sens général.
La directive exclut les micro-entreprises (moins de 10 salariés et CA ou bilan inférieur à 2 millions d’euros) et prévoit une clause de charge disproportionnée pour les cas où la mise en conformité entraînerait un coût manifestement excessif par rapport au bénéfice attendu.
Date clé : les obligations s’appliquent aux nouveaux produits et services depuis le 28 juin 2025. Les produits déjà sur le marché bénéficient d’une période de transition jusqu’au 28 juin 2030, à condition qu’ils ne subissent pas de modification substantielle.
Transposition nationale : calendrier et différences entre pays
Chaque État membre a transposé la directive dans son droit national avant la date limite du 28 juin 2022 :
| Pays | Loi nationale | Référentiel technique | Organisme de contrôle |
|---|---|---|---|
| France | Loi 2023-171 du 9 mars 2023 | RGAA 4.1 (basé WCAG 2.1 AA) | ARCOM |
| Allemagne | BFSG (Barrierefreiheitsstärkungsgesetz) | EN 301 549 / WCAG 2.1 AA | Marktüberwachungsbehörde (autorités régionales) |
| Italie | D.Lgs. 82/2022 | EN 301 549 | AgID |
| Espagne | Real Decreto 193/2023 | EN 301 549 / UNE-EN 301549 | Ministerio de Asuntos Económicos |
| Pays-Bas | Wet implementatie EU-richtlijn toegankelijkheid | EN 301 549 | Nederlandse Voedsel- en Warenautoriteit |
Le référentiel technique commun au niveau européen est la norme EN 301 549, qui reprend les critères de succès WCAG 2.1 niveau AA. Certains pays (France, Allemagne) y ajoutent des spécifications nationales.
L’ERP est-il un “service numérique” au sens de l’EAA ?
La directive vise les “services fournis par voie électronique” destinés aux consommateurs. Un ERP interne (back-office) utilisé exclusivement par les employés n’entre pas directement dans le périmètre de l’EAA en tant que “service au consommateur”.
Toutefois, trois situations rendent l’accessibilité ERP juridiquement pertinente :
- Portails clients et fournisseurs : un portail de commande en ligne, un extranet fournisseur ou un service client accessible via navigateur tombe sous le périmètre de l’EAA
- Obligation employeur : le droit du travail européen et national (en France, loi 2005-102) impose déjà des aménagements raisonnables pour les salariés handicapés, ce qui inclut les outils numériques de travail
- Marchés publics : la directive européenne 2014/24/UE sur les marchés publics exige des critères d’accessibilité dans les cahiers des charges, ce qui touche directement les ERP déployés dans le secteur public ou para-public
En pratique, même pour un ERP strictement interne, l’accessibilité devient une exigence de fait pour toute entreprise employant des personnes en situation de handicap ou répondant à des appels d’offres publics.
WCAG 2.2 niveau AA : le référentiel technique applicable
Les 4 principes appliqués à un ERP
Le référentiel WCAG 2.2 (Web Content Accessibility Guidelines) du W3C s’organise autour de quatre principes, chacun ayant des implications spécifiques pour un ERP :
- Perceptible : les informations doivent être présentables sous des formes que l’utilisateur peut percevoir. Dans un ERP, cela signifie des contrastes suffisants dans les formulaires de saisie, des alternatives textuelles pour les graphiques de reporting, des indicateurs non uniquement basés sur la couleur (par exemple, un statut “en retard” ne peut pas être signalé uniquement en rouge)
- Utilisable : l’interface doit être navigable et utilisable sans souris. Les tableaux de bord ERP, les grilles de saisie et les workflows d’approbation doivent être entièrement opérables au clavier. Les délais de session doivent être suffisants ou paramétrables
- Compréhensible : les formulaires doivent comporter des labels explicites, les messages d’erreur doivent être clairs et contextuels, et la navigation doit être cohérente d’un module à l’autre
- Robuste : le code HTML/ARIA doit être correctement structuré pour fonctionner avec les technologies d’assistance (lecteurs d’écran, logiciels de grossissement, commutateurs)
Exemples concrets dans un ERP
Navigation clavier dans les tableaux de bord. Un utilisateur doit pouvoir naviguer entre les widgets d’un tableau de bord (chiffre d’affaires, commandes en cours, alertes) en utilisant Tab et les touches fléchées, sans se retrouver piégé dans un composant (notion de “focus trap”).
Contraste dans les formulaires de saisie. Le ratio de contraste minimum exigé par WCAG AA est de 4,5:1 pour le texte et 3:1 pour les éléments d’interface (bordures de champs, icônes actionnables). Les thèmes ERP à fond gris clair avec texte gris moyen sont fréquemment non conformes.
Lecteur d’écran sur les workflows. Quand un utilisateur valide une facture dans un workflow d’approbation, le changement de statut doit être annoncé au lecteur d’écran via des régions ARIA live. Un bouton “Approuver” sans label accessible sera invisible pour NVDA ou JAWS.
État des lieux : où en sont les éditeurs ERP
SAP : Fiori en avance, SAP GUI en retard
SAP est l’éditeur le plus avancé en matière d’accessibilité ERP. L’interface SAP Fiori est conçue selon les principes WCAG et inclut la navigation clavier, le support des lecteurs d’écran et le respect des ratios de contraste. SAP publie des Accessibility Conformance Reports (ACR) basés sur le format VPAT pour ses produits cloud.
La bibliothèque SAPUI5 vise la conformité WCAG 2.2, avec un travail spécifique sur les nouveaux critères (alternatives au glisser-déposer, minimisation des saisies redondantes).
Le problème : les entreprises qui utilisent encore SAP GUI (l’interface classique Windows) ou des transactions ABAP legacy ne bénéficient pas de ces avancées. L’accessibilité de SAP GUI est structurellement limitée par son architecture technique. Pour les entreprises en cours de migration vers S/4HANA, c’est un argument supplémentaire en faveur de la bascule vers Fiori.
Oracle : conformité documentée, expérience variable
Oracle publie des VPAT/ACR pour l’ensemble de ses produits cloud, y compris Oracle Cloud ERP. La conformité déclarée couvre EN 301 549 et WCAG 2.1. En pratique, les retours utilisateurs signalent des écarts entre la conformité documentée et l’expérience réelle, notamment sur les modules de reporting et les interfaces de configuration.
Oracle bénéficie néanmoins d’une gouvernance d’accessibilité structurée et d’un programme dédié (Oracle Accessibility Program) qui intègre les tests d’accessibilité dans le cycle de développement.
Odoo, Sage, Dynamics 365 : maturité inégale
Microsoft Dynamics 365 bénéficie de l’investissement massif de Microsoft dans l’accessibilité. L’interface web respecte globalement les standards WCAG, et Microsoft publie des Conformance Statements. Les modules Power Apps personnalisés doivent cependant être audités séparément.
Sage n’a pas publié de programme d’accessibilité aussi visible que SAP ou Oracle. Les interfaces Sage varient fortement selon le produit (Sage 100, Sage X3, Sage Intacct) et la génération technologique. Les versions cloud récentes sont généralement mieux positionnées que les clients lourds legacy.
Odoo est un cas particulier. Le framework web d’Odoo a progressé sur l’accessibilité dans les versions récentes, mais le vaste écosystème de modules communautaires (plus de 40 000 sur l’Odoo App Store) n’est soumis à aucun contrôle d’accessibilité. Un module tiers qui ajoute un écran de saisie personnalisé peut casser l’accessibilité de l’ensemble.
Le piège des personnalisations qui cassent l’accessibilité
C’est le point aveugle de la plupart des projets ERP. Même si l’éditeur livre un produit conforme, les personnalisations réalisées lors du déploiement (écrans custom, rapports ABAP, vues Crystal Reports, tableaux de bord Power BI intégrés, modules communautaires) ne sont presque jamais auditées pour l’accessibilité.
Un ERP “conforme en théorie” peut devenir non conforme en production si les équipes de développement internes ou l’intégrateur n’ont pas intégré les exigences d’accessibilité dans leurs processus.
Auditer l’accessibilité de votre ERP : méthodologie
Outils d’audit automatisé
Les outils automatisés permettent de détecter rapidement les problèmes les plus courants :
- axe DevTools (extension navigateur Deque Systems) : détecte les violations WCAG dans les interfaces web, idéal pour les ERP cloud ou les portails web
- Lighthouse (intégré à Chrome DevTools) : fournit un score d’accessibilité et identifie les éléments critiques (contraste, labels manquants, structure des titres)
- WAVE (Web Accessibility Evaluation Tool) : outil visuel qui superpose les erreurs et alertes directement sur la page
Ces outils couvrent environ 30 à 40 % des critères WCAG. Ils ne remplacent pas l’audit manuel, mais permettent de prioriser les corrections.
Tests manuels indispensables
Les tests automatisés ne peuvent pas évaluer l’expérience réelle d’un utilisateur handicapé. Les tests manuels suivants sont incontournables :
- Navigation clavier complète : parcourir chaque écran critique (saisie commande, validation facture, consultation stock) en utilisant uniquement Tab, Entrée, Échap et les touches fléchées. Vérifier que le focus est visible et que l’ordre de tabulation est logique
- Lecteur d’écran : tester avec NVDA (gratuit, Windows) ou JAWS (commercial, Windows) les principaux parcours utilisateur. Vérifier que les intitulés de champs, les messages d’erreur et les changements de statut sont correctement annoncés
- Grossissement 200 % : agrandir l’interface à 200 % et vérifier qu’aucune information n’est tronquée ou inaccessible (reflow)
- Mode contraste élevé : activer le mode contraste élevé du système d’exploitation et vérifier que l’interface reste utilisable
Grille d’évaluation : 10 points critiques dans un ERP
- Tous les champs de formulaire ont un label HTML associé (
<label for="...">) - Les messages d’erreur de saisie identifient le champ concerné et la nature de l’erreur
- Le ratio de contraste respecte 4,5:1 pour le texte et 3:1 pour les composants d’interface
- La navigation au clavier couvre tous les écrans sans “piège de focus”
- Les tableaux de données utilisent
<th>,scopeet<caption>pour la structure - Les graphiques et indicateurs visuels ont une alternative textuelle ou tabulaire
- Les changements de contexte (popups, onglets, redirections) sont annoncés aux technologies d’assistance
- Les délais de session sont paramétrables ou prévenus 20 secondes avant expiration
- La structure de titres (
h1àh6) est hiérarchique et cohérente par page - Le site/application passe les tests axe DevTools avec zéro violation critique
Plan d’action : rendre votre ERP conforme en 5 étapes
1. Inventorier les interfaces utilisées
Listez l’ensemble des interfaces ERP exposées aux utilisateurs : back-office interne, portail client (e-commerce B2B, suivi de commande), portail fournisseur, application mobile. Chaque interface a potentiellement des obligations différentes selon qu’elle est destinée aux consommateurs (EAA) ou aux salariés (droit du travail).
2. Prioriser les écrans critiques
Concentrez l’effort sur les parcours à fort impact : saisie de commande, validation de facture, consultation de stock, reporting de gestion. Un audit exhaustif de centaines d’écrans est irréaliste en première intention. Ciblez les 20 écrans les plus utilisés et les portails externes en priorité.
3. Travailler avec l’éditeur vs corriger en interne
Pour le produit standard, sollicitez l’éditeur. Demandez ses VPAT/ACR, sa roadmap accessibilité, et les correctifs prévus. Pour les personnalisations, la responsabilité vous incombe : intégrez les critères WCAG AA dans vos spécifications de développement et vos cahiers des charges intégrateur.
4. Former les équipes UX/dev internes
L’accessibilité ne peut pas être traitée en fin de projet. Formez les développeurs internes et les key users aux bases de l’accessibilité web : structure sémantique HTML, attributs ARIA, tests clavier. Un investissement de 2 à 3 jours de formation par développeur suffit pour couvrir les fondamentaux. La conduite du changement est un levier essentiel, comme nous le détaillons dans notre guide pratique de conduite du changement ERP.
5. Documenter la déclaration d’accessibilité
En France, la publication d’une déclaration d’accessibilité est obligatoire pour les services publics et sera étendue au secteur privé via l’EAA. Cette déclaration doit indiquer le niveau de conformité atteint, les non-conformités identifiées, et les moyens de contact pour les utilisateurs rencontrant des difficultés. Un schéma pluriannuel de mise en accessibilité renforce la crédibilité de la démarche.
Sanctions et risques en cas de non-conformité
Amendes par pays
Les sanctions varient selon les transpositions nationales :
- France : l’ARCOM peut imposer des amendes jusqu’à 50 000 euros par manquement (ordonnance du 6 septembre 2023). Le non-respect des obligations complémentaires (déclaration d’accessibilité, schéma pluriannuel) est passible de 25 000 euros
- Allemagne : le BFSG prévoit des amendes de 10 000 à 100 000 euros selon la gravité, avec une procédure graduée (mise en demeure, audition, puis sanction)
- Italie : amendes administratives proportionnelles, avec possibilité de retrait du marché pour les produits non conformes
- Espagne : sanctions de 10 001 à 100 000 euros pour les infractions graves
Au-delà des amendes, les concurrents et associations de consommateurs peuvent engager des actions en cessation (cease-and-desist) dans plusieurs États membres.
Risque réputationnel et exclusion des marchés publics
Le risque financier direct (amendes) est souvent inférieur au risque indirect. Une entreprise dont le portail client n’est pas accessible s’expose à une exclusion de fait des marchés publics, où les critères d’accessibilité sont désormais intégrés dans les cahiers des charges. Le risque réputationnel est également réel : les associations de personnes handicapées et les médias spécialisés publient régulièrement des classements et des signalements.
L’accessibilité comme levier de qualité logicielle
L’accessibilité n’est pas qu’une contrainte réglementaire. Les principes WCAG, appliqués à un ERP, améliorent l’expérience de tous les utilisateurs : navigation plus rapide au clavier, messages d’erreur plus clairs, meilleure lisibilité des tableaux de bord. Pour une population active vieillissante, ces améliorations ont un impact direct sur la productivité.
Le coût d’un audit initial varie de 5 000 à 20 000 euros selon la complexité de l’ERP et le nombre d’écrans. Le coût de remédiation dépend du volume de personnalisations. Ces investissements sont à comparer aux amendes potentielles et, surtout, à l’amélioration durable de la qualité du logiciel.
Pour aller plus loin, consultez notre checklist de tests de recette ERP (intégrez les critères d’accessibilité dans vos UAT) et notre guide de conformité RGPD pour les ERP (la logique de conformité réglementaire est similaire : inventaire, audit, plan d’action, documentation).
Pour valider une hypothèse d’adoption, partez sur un POC 3 mois sur 1 processus cible (achat, compta, CRM). Budget typique : 15-30 K euros. Résultat : décision Go/No-Go avec chiffres concrets, pas avec un Excel de promesses commerciales.
