Le 28 juin 2025 a marqué l’entrée en vigueur du European Accessibility Act (directive UE 2019/882) pour la plupart des produits et services e-commerce vendus à des consommateurs européens. Un an plus tard, le constat de terrain est limpide : la majorité des boutiques PrestaShop opérant en France ne sont pas conformes — et la plupart des marchands l’ignorent encore.
Le sujet n’est pas qu’éthique. C’est désormais un risque juridique, commercial (perte de marchés publics, B2B sensibles) et de réputation. Cet article fait le point sur le cadre légal réel, les sanctions effectivement appliquées en France depuis un an, et la feuille de route technique pour mettre une boutique PrestaShop 8 ou 9 en conformité sans refondre le thème.
Le cadre légal qui s’applique à une boutique PrestaShop en 2026
L’EAA est transposé en droit français par l’ordonnance du 6 septembre 2023, modifiant le Code de la consommation. Le périmètre est large : tout service e-commerce destiné à des consommateurs européens est concerné — site web, application mobile, processus d’achat, communication post-vente.
Deux exemptions structurantes :
- Les micro-entreprises au sens européen (moins de 10 salariés ET chiffre d’affaires ou bilan inférieur à 2 M€) sont exemptées pour leurs services. Attention : le seuil s’apprécie au niveau du groupe.
- Les contenus tiers non maîtrisés (commentaires utilisateurs bruts, par exemple) ne sont pas dans le périmètre, mais le marchand reste responsable de la structure d’accueil de ces contenus.
La norme technique de référence en France est le RGAA 4.1 (qui s’aligne sur WCAG 2.1 niveau AA). En pratique, la norme internationale qui guide le travail au quotidien est WCAG 2.2, publiée en octobre 2023, qui ajoute neuf critères de succès — notamment le focus visible (2.4.11), les cibles de pointage suffisamment grandes (2.5.8) et la persistance des éléments d’aide (3.2.6). Une boutique conforme WCAG 2.2 AA est conforme RGAA 4.1.
Les sanctions effectivement appliquées en France depuis un an
Le contrôle est réparti entre la DGCCRF (volet consommateur) et l’ARCOM (volet contenu numérique). En un an, le constat est le suivant :
- Phase pédagogique majoritaire : les premiers contrôles 2025 ont surtout débouché sur des mises en demeure et des engagements correctifs. Peu d’amendes fermes.
- Durcissement à partir du T1 2026 : plusieurs amendes administratives ont été notifiées, échelonnées de 5 000 € à 75 000 € selon la taille de l’opérateur et la gravité (absence totale de déclaration d’accessibilité notamment).
- Le plafond légal est élevé : jusqu’à 250 000 € pour une personne morale en cas de récidive ou de manquement caractérisé.
- Risque indirect probablement supérieur : exclusion des marchés publics, refus de référencement par des centrales d’achat B2B, signalements clients sur les comparateurs.
L’obligation visible la plus systématiquement contrôlée est la déclaration d’accessibilité, qui doit être publiée sur le site, datée, et indiquer le niveau de conformité atteint (totalement / partiellement / non conforme) ainsi qu’un schéma pluriannuel de mise en conformité. Une boutique sans cette page est immédiatement repérée.
L’audit terrain : ce qui pèche réellement sur PrestaShop
Sur la base des audits que nous menons sur des thèmes Classic, Hummingbird, Warehouse et thèmes sur mesure, les non-conformités récurrentes se concentrent sur six familles :
1. Contraste insuffisant (critère WCAG 1.4.3 / 1.4.11)
Le gris clair sur fond blanc utilisé pour les prix barrés, les mentions « TVA incluse », ou les pictos de réassurance échoue presque systématiquement le ratio 4.5:1 (texte normal) ou 3:1 (texte large et interfaces). Une passe d’audit avec Lighthouse ou axe-core sort en général 15 à 40 défauts de contraste sur une fiche produit standard.
2. Navigation clavier cassée
Le menu déroulant top, les filtres de la facette à gauche, le sélecteur de quantité custom, le popup newsletter — tous ces composants sont fréquemment inaccessibles au clavier seul (touche Tab + Entrée + Espace). Le focus visible disparaît dans la moitié des thèmes premium. C’est un critère bloquant.
3. Formulaire de checkout non étiqueté correctement
Champ sans attribut label associé, indication d’erreur en couleur seule (rouge), pas d’attribut aria-describedby pour les contraintes (« 8 caractères minimum »), récapitulatif inaccessible au lecteur d’écran. Le checkout one-page natif PrestaShop 8 a fait des progrès mais reste à compléter, surtout dès qu’un module de paiement ou un sélecteur d’adresse tiers est ajouté.
4. Images sans texte alternatif structuré
Le bon vieux problème : tous les visuels produit ont un attribut alt vide ou répété (nom du produit copié-collé). La logique correcte : alt vide pour les visuels purement décoratifs (alt= » »), alt descriptif et différencié pour les vues secondaires (« vue de dos », « détail couture »). PrestaShop ne le fait pas automatiquement, c’est au marchand de le saisir à l’import catalogue.
5. Vidéos et carrousels automatiques
Carrousel home qui défile tout seul sans bouton pause, vidéo produit en autoplay : violation directe du critère 2.2.2 (Mise en pause, arrêt, masquage). Et techniquement, pour un visiteur avec un trouble vestibulaire, le défilement automatique peut déclencher un malaise.
6. Captcha bloquant et popups intrusifs
reCAPTCHA v2 « cochez la case » sans alternative pour utilisateurs de lecteurs d’écran, popup newsletter sans piège à focus, modale cookies impossible à fermer au clavier. Trois classiques que tout audit DGCCRF relève en quelques minutes.
Feuille de route de mise en conformité — sans refondre le thème
Bonne nouvelle : la majorité des boutiques peuvent atteindre une conformité substantielle WCAG 2.2 AA en 4 à 8 semaines de travail ciblé, sans refonte complète. Voici la séquence qui fonctionne :
Semaine 1 — Audit chiffré
Lancer un audit automatisé (axe DevTools, WAVE, Lighthouse) sur 10 pages représentatives : accueil, catégorie, fiche produit, panier, étape de livraison, étape de paiement, confirmation, blog, contact, déclaration légale. Doubler avec un test manuel clavier seul + un test lecteur d’écran (NVDA gratuit sur Windows, VoiceOver sur Mac). Sortir une matrice « critère / page / sévérité » avec scores.
Semaines 2 à 3 — Corrections de surface à fort impact
- Reprise de la palette de couleurs pour atteindre les ratios de contraste — souvent une variable CSS à ajuster, voire deux ou trois.
- Ajout d’un focus visible global et lisible (outline 2 pixels avec une couleur contrastée).
- Reprise des libellés alt sur le catalogue : règle automatisable via un script SQL ou un module dédié.
- Suppression des autoplay et ajout d’un contrôle de pause sur le carrousel.
Semaines 4 à 5 — Composants critiques
- Refonte du menu principal avec gestion clavier complète (Tab, Entrée, Échap, flèches).
- Étiquetage ARIA correct des filtres facette, du sélecteur de quantité, des notifications panier.
- Reprise des formulaires : labels associés, indications d’erreur en texte ET en couleur, focus sur le premier champ en erreur.
Semaines 6 à 7 — Conformité éditoriale et déclaration
- Audit des pages CMS et articles de blog (structure de titres, images alt).
- Rédaction et publication de la déclaration d’accessibilité conforme au modèle officiel (état de conformité, dérogations justifiées, retour utilisateur, voie de recours).
- Schéma pluriannuel de mise en conformité publié sur la même page.
Semaine 8 — Test utilisateur et documentation
Un test avec un utilisateur réel en situation de handicap (déficience visuelle ou motrice) reste le seul moyen de valider qu’on n’a pas raté un critère subtil. C’est aussi un argument en cas de contrôle : prouver une démarche d’amélioration continue.
Le piège des modules tiers
L’angle mort majeur : les modules tiers ajoutent en permanence des éléments non audités. Une popup wishlist, un module de cross-sell avec carrousel, un widget d’avis tiers — chaque ajout peut casser la conformité acquise. La règle saine : auditer chaque nouveau module avec axe-core avant déploiement, et exiger du développeur une déclaration de compatibilité WCAG 2.2 AA.
Côté DataFirefly, l’ensemble des modules récents (panier latéral, alertes, recherche live, page builder) sont testés axe-core et lecteur d’écran avant publication, et la déclaration de conformité technique est fournie sur demande pour les marchands en contrôle DGCCRF.
Conclusion : le risque n’est plus théorique
L’argument « personne ne contrôle » n’est plus tenable un an après l’entrée en vigueur de l’EAA. Les amendes commencent à tomber, la déclaration d’accessibilité est devenue le minimum visible, et la pression B2B s’intensifie (centrales d’achat, marchés publics, donneurs d’ordres grand compte exigent désormais des engagements WCAG dans leurs contrats).
Le bon angle stratégique pour un marchand PrestaShop n’est pas de faire le minimum cosmétique, mais d’utiliser la mise en conformité comme un audit UX général : la majorité des correctifs accessibilité améliorent aussi la conversion (lisibilité, contraste, navigation clavier appréciée des power-users, structure sémantique meilleure pour le SEO et l’AEO). Un investissement de 4 à 8 semaines qui sert plusieurs objectifs.
