Accessibilité PrestaShop : Rendre son site conforme RGAA

Si vous lisez ces lignes en 2026, vous avez probablement déjà entendu parler de l’European Accessibility Act. Ou de la loi du 9 mars 2023. Ou du RGAA. Ou des trois.

Vous savez que c’est obligatoire depuis le 28 juin 2025. Vous savez vaguement que vous risquez une amende. Vous avez peut-être même installé un de ces petits modules qui ajoutent un bouton « accessibilité » en bas à droite de votre boutique, et vous vous êtes dit que vous étiez tranquille. Vous ne l’êtes pas.

L’accessibilité PrestaShop en 2026 : le rappel à la réalité

J’ai un chiffre à vous montrer. Il vient de la Fédération des Aveugles et Amblyopes de France, publié en janvier 2025 après un audit indépendant : sur 89 sites e-commerce français audités, seulement 2 respectent leurs obligations légales d’accessibilité numérique.

2 sur 89. Soit 2,2 %.

Statistiquement, votre boutique fait partie des 87 autres.

Et ce n’est pas le pire. La même fédération a publié en juin 2025 un autre chiffre, encore plus parlant : 3,4 % seulement des sites internet des grandes entreprises françaises sont accessibles. Les grandes entreprises. Avec leurs équipes dédiées, leurs budgets RSE, leurs prestataires spécialisés. 3,4 %.

Si elles n’y arrivent pas, qu’est-ce que ça donne pour une boutique PrestaShop standard, gérée par un marchand qui a déjà 12 autres priorités ?

Mon conseil avant de commencer : prenez ces chiffres au sérieux. Pas parce que je veux vous vendre quelque chose (cet article ne vend rien, on en parlera à la fin), mais parce que la mécanique judiciaire vient de se mettre en route. Et vous avez plusieurs étapes d’avance à prendre.

Pourquoi cet article maintenant

Le 28 juin 2025, l’European Accessibility Act est entré en vigueur dans toute l’Union européenne. En France, c’est la loi du 9 mars 2023 et l’ordonnance du 6 septembre 2023 qui transposent la directive dans le Code de la consommation (articles L.412-8 et suivants).

Concrètement : toute boutique e-commerce de plus de 10 salariés ou plus de 2 millions d’euros de chiffre d’affaires doit désormais être accessible aux personnes en situation de handicap. Si vous êtes au-dessus d’un seul de ces deux seuils, vous êtes concerné.

Pendant six mois après l’entrée en vigueur, il ne s’est pas passé grand-chose de visible. Les autorités ont laissé un temps de grâce, comme toujours en France quand un nouveau texte sort. Les grandes entreprises ont publié leurs déclarations d’accessibilité (souvent à la dernière minute, parfois bâclées). Les PME ont continué comme avant.

Et puis le 7 juillet 2025, ça a basculé.

Trois associations (ApiDV, Droit Pluriel et le collectif de juristes Intérêt à Agir) ont mis en demeure quatre géants de la grande distribution : Auchan, Carrefour, E. Leclerc et Picard Surgelés. Délai de mise en conformité : 1er septembre 2025. Action en justice annoncée si rien ne bouge.

C’est la première fois en France que des associations actionnent le levier judiciaire de l’EAA contre des acteurs e-commerce. Le précédent est posé. Et il ne va pas s’arrêter aux quatre premiers.

Au passage : la DGCCRF a annoncé monter en puissance sur ces contrôles, et l’ARCOM vise 2 000 contrôles annuels dès 2026. Combinez ça avec le système de signalement citoyen via SignalConso, et vous avez un changement d’échelle : avant, il y avait une loi mais pas de radar. Maintenant, il y a la loi, le radar, et les premières condamnations qui se préparent.

Voilà pourquoi cet article maintenant.

💡 Bon à savoir : la directive prévoit une période transitoire jusqu’au 28 juin 2030 pour les services existants antérieurs à juin 2025. Mais attention : un site internet n’est pas considéré juridiquement comme un « produit ». L’exemption s’applique difficilement aux e-commerces. Ne comptez pas dessus pour gagner cinq ans.

Ce que dit PrestaShop officiellement (et pourquoi c’est révélateur)

J’ai été voir la déclaration d’accessibilité publiée par prestashop.com eux-mêmes en juin 2025. Vous pouvez la lire en bas de leur site, comme c’est obligatoire.

Le chiffre annoncé : 70 % de conformité au RGAA 4.1.2.

Soyons clairs : 70 %, c’est un score honorable. C’est même probablement très au-dessus de la moyenne du marché. Mais ça veut quand même dire que sur les 106 critères du référentiel, 30 % ne sont pas respectés sur le site officiel de l’éditeur.

Et ces 30 %, PrestaShop les liste. Intitulés de liens approximatifs, alternatives textuelles manquantes sur certaines images, tabulation au clavier qui ne se voit pas, langue par défaut absente sur certains contenus. Les fondamentaux.

Pourquoi je vous raconte ça ?

Parce que si l’éditeur lui-même, qui dispose des compétences internes pour le faire correctement, plafonne à 70 % sur son site vitrine, vous devez vous poser deux questions :

1. À combien estimez-vous votre propre boutique sans audit ?
2. Si PrestaShop officiel n’a pas tout corrigé, est-ce que le thème Classic que vous utilisez (ou un thème acheté chez un éditeur tiers) est conforme par défaut ?

Spoiler : non. Le thème Classic, qui sert de base à des dizaines de milliers de boutiques dans le monde, présente plusieurs défauts d’accessibilité documentés depuis des années. L’issue GitHub #34504 (ouverte en 2023, toujours active en 2026) signale par exemple un problème d’attribut role="tablist" sur les fiches produits, détectable directement par Google PageSpeed dans la section Accessibility.

L’issue #38259, ouverte en 2025 spécifiquement sur la conformité EAA, est encore en attente de retour produit.

Ce que ça vous dit : la conformité ne tombera pas du ciel via une mise à jour magique de PrestaShop. C’est à vous de la construire sur votre boutique.

La réalité du terrain : 350 boutiques auditées

Chez CYBERIAL, on accompagne plus de 350 boutiques PrestaShop en France, en Belgique et en Suisse. Maintenance, dépannage, hébergement, support. On voit passer beaucoup de code, beaucoup de thèmes, beaucoup de modules.

Ce qu’on voit chez nos clients en matière d’accessibilité, c’est très simple : personne n’est conforme.

Pas même les marchands qui ont fait l’effort. Pas même ceux qui ont installé un module dédié. Pas même ceux qui ont demandé à leur intégrateur de « rendre le site accessible ». Au mieux, on est sur 30-40 % de conformité sur les fondamentaux, avec des trous béants dans le tunnel de commande, dans les fiches produits, dans les formulaires d’inscription.

Au mieux, on a des sites avec un overlay (un module qui ajoute un bouton flottant en bas à droite) qui dégrade activement l’accessibilité. Oui, dégrade. On y reviendra dans le chapitre 5 : ces solutions « miracles » à 30 € par mois sont en réalité contre-productives, et plusieurs ont été condamnées (notamment AccessiBe, condamné à 1 million de dollars d’amende par la Federal Trade Commission américaine en janvier 2025, pour publicité mensongère).

Ah si: une chose qu’on voit aussi, c’est l’écart entre la perception du marchand et la réalité technique. Beaucoup pensent que parce que leur site est « propre » visuellement, il est accessible. C’est faux. L’accessibilité n’a rien à voir avec le design. C’est une question de structure HTML, de balises ARIA, de navigation au clavier, de contraste calculé, de focus management. Des choses qu’on ne voit pas, mais qui font que le site est utilisable (ou pas) pour une personne aveugle, malvoyante, ou pour quelqu’un qui ne peut pas se servir d’une souris.

📊 Donnée terrain CYBERIAL : sur les 50 dernières boutiques PrestaShop qu’on a auditées, aucune ne dépassait 50 % de conformité RGAA. La moyenne se situe autour de 35-40 %. Les principaux points de blocage sont, dans l’ordre : les formulaires du tunnel de commande, les images de fiches produits sans alternative textuelle pertinente, le contraste insuffisant sur les libellés de prix barrés, et la navigation clavier dans les méga-menus.

Si vous lisez ça et que vous vous dites « bon, je dois être à 60-70 % au minimum » : statistiquement, vous êtes plutôt à 30-40 %. C’est mieux d’en avoir conscience tout de suite que de le découvrir avec un signalement DGCCRF.

Les 14,5 millions de Français que vous ne voyez pas

Avant de plonger dans la technique, un détour par les chiffres humains. Parce que l’accessibilité, ce n’est pas qu’une obligation légale. C’est aussi un marché.

D’après l’INSEE, 14,5 millions de Français vivent en situation de handicap. C’est 18 % de la population, selon APF France handicap. Si on ajoute les seniors (qui ont aussi des besoins d’accessibilité, même sans être officiellement « handicapés »), on monte à environ 20 millions de personnes rien qu’en France.

À l’échelle européenne, ce sont 87 millions d’Européens qui sont concernés. C’est le marché que l’EAA cherche à protéger.

Et ces gens achètent en ligne. D’après les chiffres de Loris Pinna (consultant français spécialisé), 40 % des Français en situation de handicap font des achats e-commerce. Sauf qu’ils abandonnent massivement les sites qui ne fonctionnent pas pour eux.

Une étude américaine de 2025 (eCommerce Accessibility Study) a chiffré la perte : 2,3 milliards de dollars de chiffre d’affaires annuel perdus rien qu’aux États-Unis à cause de tunnels d’achat inaccessibles. 71 % des utilisateurs en situation de handicap abandonnent immédiatement un site e-commerce qui leur pose problème.

Chez vous, ça se traduit comment ? Imaginez un client malvoyant qui ajoute un produit à son panier, navigue jusqu’au checkout, remplit ses informations, et qui se retrouve bloqué à l’étape paiement parce que la case « j’accepte les CGV » n’a pas de label correctement associé. Il ne peut pas la cocher. Il abandonne. Vous ne le voyez même pas dans vos analytics : c’est juste une « commande non finalisée » de plus.

Manuel Pereira, responsable accessibilité numérique de l’Association Valentin Haüy et lui-même aveugle, a livré dans Handicap.fr en mars 2025 une formule qui résume tout : « Il y a presque autant de chances de gagner au loto que de réussir à valider son panier » sur la majorité des sites e-commerce français.

C’est de l’humour noir, mais c’est documenté. Et c’est votre marché qui s’évapore.

Le calendrier à connaître par cœur

Trois dates structurent tout le débat actuel :

Ce que ça veut dire pour vous : la fenêtre où il était possible d’attendre est fermée. Les premières mises en demeure sont tombées. Le RGAA v5 va arriver fin 2026 avec probablement des exigences renforcées. Et la période transitoire jusqu’à 2030 ne s’applique pas vraiment aux sites e-commerce (les juristes sont prudents là-dessus).

Concrètement, vous avez environ 12 mois pour vous mettre en ordre de marche. Pas pour être parfait, mais pour avoir un audit de référence, une déclaration d’accessibilité publiée, un schéma pluriannuel d’actions, et avoir corrigé au moins les fondamentaux qui bloquent les utilisateurs.

Si vous attendez 2027 pour vous y mettre, vous serez en retard.

⚠️ Attention : la déclaration d’accessibilité est obligatoire même si votre site n’est pas conforme. Le texte est très clair : vous devez publier une déclaration qui indique votre niveau réel (non conforme, partiellement conforme, totalement conforme) et lister les contenus non accessibles. Une boutique sans déclaration est en infraction avant même d’être contrôlée sur son contenu.

Ce que vous allez trouver dans cet article

Je vais essayer dans la suite d’être à la fois exhaustif et utilisable. C’est-à-dire que vous pouvez lire cet article en entier (comptez deux à trois heures de lecture attentive), ou venir chercher chapitre par chapitre les informations dont vous avez besoin selon où vous en êtes.

Voici ce qu’on va couvrir :

• Le cadre légal détaillé (chapitre 2) : qui est concerné, quelles sanctions, quelles autorités contrôlent, quelles différences entre les pays UE
• Les 80 points d’audit RGAA appliqués spécifiquement à PrestaShop (chapitre 3), classés par les 13 thématiques du référentiel officiel DINUM
• Le tunnel de commande PrestaShop en 5 étapes (chapitre 4) : c’est l’angle critique, là où les utilisateurs abandonnent, là où les contrôles vont d’abord chercher
• Pourquoi les overlays ne sont pas la solution (chapitre 5) : panorama des modules existants, position des experts mondiaux, cas FTC vs AccessiBe
• Un simulateur d’audit interactif (chapitre 6) pour évaluer votre boutique sur les 80 points
• Le modèle de déclaration d’accessibilité copier-coller (chapitre 7) avec les 10 mentions obligatoires
• Comment se faire accompagner (chapitre 8) : les options possibles, les acteurs français de référence, et comment on travaille chez CYBERIAL

Pour être totalement transparent avec vous : cet article ne vous vend rien. Il n’y a pas de forfait magique à 99 € qui vous rendrait conforme en deux jours. La conformité accessibilité, c’est un vrai travail, qui demande un audit, des corrections techniques sur le code de votre thème PrestaShop, parfois un changement de modules, et un suivi dans le temps. Ça se chiffre après diagnostic, pas en barème.

Si vous voulez en discuter après avoir lu, vous trouverez les coordonnées CYBERIAL en bas de cet article. Mais l’objectif premier est de vous donner les moyens de comprendre ce qui se passe, d’évaluer où vous en êtes, et de prendre des décisions éclairées.

On démarre ?

Voir concrètement ce que ça donne

Avant d’aller plus loin dans la théorie, je vous propose une démonstration concrète. La DINUM (Direction interministérielle du numérique, qui édite le RGAA) a publié une vidéo où Jamshid Kohandel, juriste aveugle de l’équipe DesignGouv, montre comment il navigue sur le web avec un lecteur d’écran. Il met en évidence quelques-uns des problèmes d’accessibilité qu’il rencontre au quotidien.

Une phrase de cette vidéo résume parfaitement la règle d’or du RGAA qu’on va développer plus loin : « Cela montre quand même l’efficacité des mesures d’accessibilité à prévoir sur une page web, mais les petites erreurs peuvent quand même tout compromettre. Même une seule. »

C’est exactement le principe légal du calcul de conformité RGAA : un seul critère défaillant sur une seule page contamine tout l’échantillon. On y reviendra dans le chapitre 3.

🎥 VIDÉO : Comment naviguer sur le web quand on est non-voyant ? — DesignGouv

Source officielle DINUM, vidéo sous-titrée et accompagnée d’une transcription URL à intégrer : https://design.numerique.gouv.fr/articles/2023-06-12-navigation-web-non-voyant/

Si vous prenez le temps de la regarder (5 minutes environ), vous comprendrez en pratique ce que vivent vos clients en situation de handicap visuel sur votre boutique. C’est probablement le meilleur investissement de temps que vous ferez avant de passer aux chapitres techniques.

Le cadre légal et les sanctions : ce que vous risquez vraiment

Soyons directs : la majorité des articles que vous trouverez sur l’accessibilité numérique et les sanctions vous donnent un seul chiffre. Souvent un chiffre rond, qui claque bien : « jusqu’à 75 000 € d’amende » ou « jusqu’à 300 000 € de pénalités ». C’est plus complexe que ça. Et c’est utile de comprendre la mécanique réelle, parce qu’elle change la stratégie de mise en conformité.

Dans ce chapitre, je vais décortiquer le cadre légal français appliqué à votre boutique PrestaShop. Pas dans l’absolu, pas pour les administrations publiques (qui ont leurs propres règles), pas pour les grandes entreprises cotées. Pour vous. Marchand PrestaShop, entre 10 et 250 salariés, entre 2 et 50 millions d’euros de chiffre d’affaires.

Vous allez voir que c’est à la fois plus nuancé et plus inquiétant que les titres tape-à-l’œil.

La pile législative française expliquée

L’accessibilité numérique en France, ce n’est pas une seule loi. C’est un empilement de textes, qui s’appliquent ensemble, et qui ont chacun leur logique. Voici la pile, du plus ancien au plus récent.

• Loi du 11 février 2005 « pour l’égalité des droits et des chances » (loi Handicap). Article 47. C’est le texte fondateur. À l’origine, il visait surtout les administrations publiques, et il a été complété plusieurs fois.
• Décret du 24 juillet 2019 relatif à l’accessibilité aux personnes handicapées des services de communication au public en ligne. Il pose les obligations concrètes pour les organismes publics et certaines grandes entreprises privées (au-delà de 250 millions d’euros de CA).
• Directive européenne 2019/882 du 17 avril 2019, dite European Accessibility Act (EAA). C’est le texte européen qui change tout pour le secteur privé.
• Loi française n° 2023-171 du 9 mars 2023, dite loi DDADUE. C’est elle qui transpose l’EAA en droit français.
• Ordonnance n° 2023-859 du 6 septembre 2023 prise en application de la loi DDADUE. Elle codifie les obligations dans le Code de la consommation, articles L.412-8 et suivants.
• Décret n° 2023-931 du 9 octobre 2023 et arrêté du 9 octobre 2023 qui précisent les exigences techniques applicables aux produits et services.

Pour vous, marchand PrestaShop, retenez que ce sont les articles L.412-8 et suivants du Code de la consommation qui définissent vos obligations directes depuis le 28 juin 2025. Le RGAA (Référentiel Général d’Amélioration de l’Accessibilité) est le référentiel technique que vous devez respecter, édité par la DINUM. Sa version actuelle est la 4.1.2, et la version 5 est prévue pour fin 2026.

Ah si: une précision importante. Le RGAA s’appuie sur la norme européenne harmonisée EN 301 549, qui elle-même reprend les WCAG 2.1 niveau AA (Web Content Accessibility Guidelines, le standard international édité par le W3C). Donc quand vous lisez un article qui parle de WCAG, ou un autre qui parle de RGAA, ou un troisième qui parle d’EAA, ce sont les mêmes exigences techniques de fond. Trois noms différents pour la même grille de référence.

💡 Bon à savoir : si vous êtes conforme RGAA, vous êtes conforme EAA. Si vous êtes conforme WCAG 2.1 AA, vous êtes conforme aux deux. Pas la peine de paniquer face à la multiplication des sigles : c’est un seul corpus technique avec trois étiquettes selon la couche réglementaire qu’on regarde.

Êtes-vous concerné ? Le test des deux seuils

C’est la première question à poser, et c’est aussi celle où il y a le plus d’erreurs d’interprétation dans les articles que je lis sur le sujet.

L’EAA prévoit une exemption pour les microentreprises. Pour être considéré comme microentreprise et bénéficier de cette exemption, vous devez cumuler deux conditions :

• Moins de 10 salariés
• Moins de 2 millions d’euros de chiffre d’affaires annuel OU de bilan annuel

Si vous dépassez un seul de ces deux seuils, vous n’êtes plus microentreprise au sens de l’EAA. Vous êtes soumis aux obligations.

Quelques cas concrets pour clarifier :

L’erreur classique, c’est de penser qu’il faut dépasser les deux seuils pour être concerné. C’est l’inverse : il suffit d’en dépasser un seul.

Et pour le calcul de l’effectif salarié, on prend l’équivalent temps plein moyen sur l’exercice, pas le headcount brut. Les apprentis, stagiaires et certains contrats aidés sont comptabilisés selon des règles spécifiques. Les saisonniers comptent prorata temporis.

Mon conseil: si vous êtes proche d’un seuil, faites le calcul précisément avec votre comptable. Il y a une jurisprudence française sur la qualification de microentreprise pour d’autres dispositifs (RGPD notamment) qui peut éclairer les cas limites.

Ce qu’on voit chez nos clients: la grande majorité des boutiques PrestaShop qu’on accompagne est soumise. Sur 350 clients, les vrais microentrepreneurs sont une minorité (artisans, créateurs solo, très jeunes structures). Dès que vous avez une équipe (commerciaux, logistique, marketing) ou un volume sérieux, vous passez la barre.

Les sanctions françaises décortiquées

Voilà la partie qui intéresse vraiment tout le monde. Et c’est là où il faut faire attention aux raccourcis.

L’amende de base

Le manquement à l’obligation d’accessibilité est qualifié de contravention de 5e classe. Le tarif :

• 7 500 € pour une personne morale (votre société)
• 15 000 € en cas de récidive
• 1 500 € pour une personne physique (rare en e-commerce)

Cette amende s’applique par infraction constatée. C’est-à-dire que si un contrôle révèle 12 défauts d’accessibilité majeurs sur votre boutique, l’amende théorique peut être multipliée. En pratique, les autorités regroupent souvent les manquements similaires, mais le principe du cumul existe.

Les astreintes

C’est la mécanique la plus impressionnante. En cas de non-conformité persistante après mise en demeure, vous pouvez être condamné à payer 3 000 € par jour jusqu’à régularisation.

Le plafond global des astreintes est fixé à 300 000 €. C’est ce chiffre qu’on retrouve dans la plupart des articles, et c’est lui qui fait peur. Mais attention à ne pas le présenter comme une amende immédiate : c’est une astreinte cumulative, qui n’est due que si vous ne corrigez rien après mise en demeure formelle.

Dit autrement : si vous recevez une mise en demeure et que vous mettez votre boutique en conformité dans les 30 jours, vous ne paierez pas 90 000 € (3 000 × 30). Vous échapperez aux astreintes en démontrant la régularisation.

La récidive aggravée

Pour les manquements répétés et systémiques, le maximum documenté monte à 250 000 €. C’est rare, et ça concerne plutôt les grandes entreprises en récidive après plusieurs mises en demeure non respectées.

Le cumul avec la loi Handicap de 2005

C’est l’angle souvent oublié. La loi Handicap prévoit ses propres pénalités, pouvant aller jusqu’à 50 000 € pour les organismes qui n’ont pas publié leur déclaration d’accessibilité ou qui présentent un taux de conformité RGAA insuffisant.

Pour les acteurs concernés à la fois par l’EAA (en tant que vendeurs) et par la loi Handicap (en tant qu’éligibles à un autre titre), les sanctions peuvent se cumuler.

⚠️ Attention : la sanction la plus douloureuse n’est pas forcément financière. C’est la publication du manquement. Quand la DGCCRF sanctionne une entreprise, elle peut accompagner la décision d’une publication officielle (sur son site, dans la presse). Pour une marque e-commerce qui dépend de sa réputation et de son SEO, c’est potentiellement plus coûteux que l’amende elle-même.

Le résumé chiffré

Pour synthétiser ce qui peut vous tomber dessus :

• Amende de base : 7 500 € par infraction, 15 000 € en récidive
• Astreintes : 3 000 €/jour, plafond 300 000 €
• Récidive aggravée : jusqu’à 250 000 €
• Loi Handicap cumulable : jusqu’à 50 000 €
• Risque réputationnel : publication du manquement, conséquences SEO et marque non chiffrables

C’est l’addition potentielle de tous ces postes qui peut faire monter une affaire à plusieurs centaines de milliers d’euros. Pas une seule amende isolée.

Les autorités de contrôle et leurs prérogatives

Connaître qui contrôle, c’est aussi savoir qui peut vous mettre en demeure. En France, quatre autorités se partagent le contrôle de l’accessibilité numérique selon les secteurs.

• DGCCRF (Direction générale de la concurrence, de la consommation et de la répression des fraudes). C’est elle qui contrôle le commerce électronique. Pour vous marchand PrestaShop, c’est l’autorité de référence. La DGCCRF peut effectuer des contrôles sur signalement (via SignalConso) ou de manière programmée. Elle peut émettre des injonctions de mise en conformité, infliger des sanctions, et publier les manquements.
• ARCOM (Autorité de régulation de la communication audiovisuelle et numérique). Elle intervient sur les médias audiovisuels, les plateformes vidéo, et certains services publics en ligne. L’ARCOM s’est fixé un objectif de 2 000 contrôles annuels dès 2026. Elle a moins de prise directe sur les boutiques e-commerce classiques, mais peut intervenir sur les modules vidéo intégrés à votre site.
• ARCEP (Autorité de régulation des communications électroniques, des postes et de la distribution de la presse). Elle intervient sur les opérateurs télécoms et les services de communication électronique. Vous n’êtes probablement pas concerné directement.
• ACPR (Autorité de contrôle prudentiel et de résolution) et AMF (Autorité des marchés financiers). Elles interviennent sur les services bancaires et financiers. Pas votre sujet sauf si vous vendez des produits financiers.

Pour 95 % des marchands PrestaShop, le radar à surveiller, c’est la DGCCRF. Et elle a maintenant un outil grand public puissant : SignalConso.

📊 Donnée terrain CYBERIAL

Depuis l’entrée en vigueur de l’EAA en juin 2025, on commence à voir passer les premiers signalements DGCCRF. Pas encore de mises en demeure massives, mais des demandes d’information envoyées par courrier, demandant à l’entreprise de produire sa déclaration d’accessibilité et son schéma pluriannuel sous 30 jours.

C’est l’étape qui précède la mise en demeure formelle. Si vous recevez ce courrier et que vous n’avez aucun document à produire, vous êtes mal parti !

Les premiers cas français documentés

Le 7 juillet 2025 restera une date à retenir. C’est ce jour-là que les associations ApiDV (Accompagner, Promouvoir, Intégrer les Déficients Visuels) et Droit Pluriel, accompagnées du collectif de juristes Intérêt à Agir, ont mis en demeure les quatre géants de la grande distribution française : Auchan, Carrefour, E. Leclerc et Picard Surgelés.

La méthode est intéressante à analyser, parce qu’elle préfigure ce qui va arriver à plus petite échelle. Voici comment ça s’est passé :

1. Appel à témoignage lancé auprès des personnes en situation de handicap visuel pour identifier les sites e-commerce les plus problématiques.
2. Comité de test constitué de personnes aveugles compétentes en informatique. Elles ont audité les quatre sites de manière circonstanciée.
3. Constat clair établi : ces quatre acteurs étaient parmi les plus défaillants identifiés.
4. Mise en demeure formelle notifiée le 7 juillet 2025, avec délai de mise en conformité fixé au 1er septembre 2025.
5. Annonce d’action en justice si rien ne bouge dans le délai imparti.

Les associations ont précisé qu’elles avaient ciblé les acteurs qui avaient eu deux ans pour se préparer (depuis la transposition française de mars 2023). L’argument est imparable : on ne peut pas dire qu’on n’avait pas le temps.

Pour vous, marchand PrestaShop de taille intermédiaire, ce cas est instructif sur plusieurs points :

• La pression peut venir des associations, pas seulement des autorités publiques. Et les associations ont un budget et une volonté politique.
• Les témoignages d’utilisateurs handicapés sont la base du dossier. Si un client malvoyant signale qu’il ne peut pas finaliser un achat sur votre site, c’est un point de départ légal.
• Les délais sont courts : deux mois entre la mise en demeure et la menace de procès.
• Le précédent est posé. Les associations vont continuer, et descendre la chaîne en taille d’entreprise.

Au passage : la fédération Free a aussi été condamnée en 2025 pour discrimination via inaccessibilité numérique, selon plusieurs sources juridiques (notamment Haas Avocats). C’est un précédent encore plus récent à creuser si vous voulez documenter le risque jurisprudentiel.

Et si vous vendez à l’étranger ?

Beaucoup de boutiques PrestaShop livrent dans toute l’Union européenne. Si c’est votre cas, vous êtes soumis aux régimes de sanctions de chaque pays où vous avez des clients. Et les transpositions nationales de l’EAA varient massivement.

Voici un panorama indicatif pour les principaux marchés européens :

Pays	Sanction maximale documentée
Espagne	Jusqu’à 1 000 000 €
Pays-Bas	900 000 € ou 10 % du CA
Suède	Environ 900 000 €
France	250 000 € en récidive aggravée
Belgique	200 000 € par infraction
Allemagne	100 000 € par violation (cumulatif)
Italie	5 % du CA annuel
Irlande	60 000 € + sanctions pénales possibles

Le système allemand est particulièrement inquiétant pour les marchands transfrontaliers : 100 000 € par violation, sans plafond global. Si une autorité allemande identifie 10 défauts majeurs sur votre site, vous pouvez théoriquement vous retrouver face à 1 million d’euros d’amende, dans un pays où vous avez peut-être un faible chiffre d’affaires.

Mon conseil pour les marchands qui vendent en UE : priorisez le régime français. Et documentez précisément vos efforts (audit, déclaration d’accessibilité, schéma pluriannuel) parce que cette documentation vous servira de défense dans tous les pays UE en cas de signalement.

Le calendrier opérationnel à intégrer

Pour clore ce chapitre, je rappelle le calendrier qui doit guider votre planification 2026-2030 :

1. 28 juin 2025 : entrée en vigueur effective. C’est passé. Si vous lisez cet article en 2026, vous êtes déjà en infraction technique si vous n’avez rien fait.
2. Été 2025 à printemps 2026 : phase d’observation par les autorités. La DGCCRF a privilégié les courriers d’information, les rappels, les contrôles ciblés sur les acteurs les plus visibles. C’est la fenêtre où il fallait commencer à agir.
3. À partir de l’été 2026 : montée en puissance attendue des contrôles. L’ARCOM vise ses 2 000 contrôles annuels, et la DGCCRF intensifie. Les premières condamnations significatives sont attendues sur cette période.
4. Fin 2026 : publication prévue du RGAA version 5. Probablement avec des exigences renforcées (notamment sur le mobile, l’IA, et certains composants modernes). Cela ne remettra pas en cause les efforts de mise en conformité au RGAA 4.1.2 : la base reste valable, le V5 ajoute principalement des critères.
5. 28 juin 2030 : fin de la période transitoire prévue par l’EAA pour les services existants antérieurs à juin 2025. Au-delà, plus aucune tolérance. Mais attention : cette période transitoire concerne surtout les produits (terminaux, équipements), pas les services en ligne. Les juristes interprètent prudemment cette disposition pour les sites e-commerce. Ne comptez pas dessus.

⚠️ Attention : la déclaration d’accessibilité est obligatoire dès maintenant, indépendamment du niveau réel de conformité de votre site. Vous pouvez avoir un site à 30 % de conformité et être en règle administrativement si vous publiez une déclaration honnête qui dit « 30 % de conformité ». Mais vous ne pouvez pas être en règle si vous ne publiez aucune déclaration. C’est l’absence de déclaration qui sera sanctionnée en premier, avant même le contenu.

Ce qu’il faut retenir de ce chapitre

Trois choses :

1. Vous êtes probablement concerné. Le seuil microentreprise est très bas. Si vous avez plus de 10 salariés ou plus de 2 millions d’euros de CA, vous tombez dans le filet.
2. Les sanctions sont moins effrayantes qu’on le dit, mais plus complexes. Pas de gros bâton à 300 000 € qui tombe d’un coup. Plutôt une mécanique progressive : signalement → demande d’information → mise en demeure → astreinte → publication. À chaque étape, vous pouvez sortir du couloir si vous documentez vos efforts.
3. Le risque réputationnel et la dynamique associative sont les vrais accélérateurs. Les premières mises en demeure françaises viennent des associations, pas du gouvernement. Et la publication des manquements est plus douloureuse pour une marque que l’amende elle-même.

Maintenant que le cadre est posé, on peut passer à la partie technique. Le chapitre suivant détaille les 80 points d’audit RGAA appliqués spécifiquement à PrestaShop, classés par les 13 thématiques officielles du référentiel. C’est le chapitre le plus long de l’article. C’est aussi celui qui vous donnera la grille opérationnelle pour évaluer votre boutique et planifier vos corrections.

Les 80 points d’audit RGAA appliqués à PrestaShop

C’est le chapitre central de l’article. Le plus long, le plus dense, mais aussi le plus utile.

Avant d’entrer dans le détail, deux clarifications de méthode. Le RGAA officiel contient 106 critères de contrôle répartis en 13 thématiques. Tous ne s’appliquent pas systématiquement à une boutique PrestaShop (la thématique « Cadres » ne concerne que les pages utilisant des <iframe>, par exemple). En pratique, sur un audit type d’e-commerce PrestaShop, on évalue entre 75 et 90 critères applicables. C’est pour ça qu’on parle de « 80 points » dans cet article : c’est l’ordre de grandeur réel de ce qui vous concerne.

La deuxième clarification : pour chaque thématique, je vais vous donner les critères les plus importants, ceux qu’on retrouve systématiquement chez nos clients en non-conformité. Ce n’est pas un substitut à l’audit complet, mais c’est l’essentiel pour comprendre où sont les vrais blocages.

Mon conseil avant de plonger : ne lisez pas ce chapitre d’une traite. Il est conçu comme une grille de référence. Identifiez les thématiques qui vous parlent le plus, lisez-les en priorité, revenez sur les autres plus tard.

Comprendre la grille officielle DINUM

Avant de regarder les thématiques une par une, vous devez comprendre comment fonctionne le calcul de conformité. Sinon, les chiffres que vous verrez en audit ne voudront rien dire.

Pour chaque critère, sur chaque page de votre échantillon, l’auditeur attribue un statut parmi quatre :

• NT (Non Testé) : critère pas encore évalué. Si un seul critère reste en NT, le taux global ne peut pas être calculé.
• NA (Non Applicable) : l’objet du critère n’existe pas sur la page. Par exemple, si une page ne contient aucun tableau, tous les critères de la thématique « Tableaux » seront en NA.
• C (Conforme) : le critère passe le test avec succès.
• NC (Non Conforme) : le critère échoue au test.

La règle d’or, et c’est elle qu’il faut graver dans le marbre :

Un critère est validé pour l’échantillon entier UNIQUEMENT s’il est validé sur TOUTES les pages. Un seul critère NC sur une seule page rend le critère NC pour le site entier.

C’est exactement ce que disait Jamshid Kohandel dans la vidéo DesignGouv qu’on a vue au chapitre 1 : « les petites erreurs peuvent quand même tout compromettre. Même une seule. » Vous avez 2 000 vidéos sous-titrées sauf une ? Le critère « présence de sous-titres » est NC pour tout votre site.

Cette règle change tout dans la stratégie de mise en conformité. Vous ne pouvez pas vous contenter de corriger « la majorité » des cas. Vous devez corriger tous les cas.

Le taux de conformité officiel se calcule comme suit :

Taux global = nombre de critères validés (C) / nombre de critères applicables (C + NC)

C’est ce taux qui doit obligatoirement figurer dans votre déclaration d’accessibilité, sous la formule officielle « [nn] % des critères du RGAA version 4 sont respectés ». C’est le seul taux qui fait foi légalement. Méfiez-vous des outils qui vous présentent un « taux moyen » par page : c’est manipulable et déconseillé par les agences sérieuses (notamment Access42, qui en a fait un article très clair).

💡 Bon à savoir : trois niveaux de conformité officiels existent. Non conforme = moins de 50 %. Partiellement conforme = entre 50 % et 99 %. Totalement conforme = 100 %. La grande majorité des boutiques PrestaShop tombent dans la catégorie « non conforme » ou « partiellement conforme ». Atteindre 100 % est extrêmement rare et coûteux.

Maintenant qu’on a posé les règles du jeu, on peut regarder les 13 thématiques en détail.

Thématique 1 — Images

C’est la thématique la plus intuitive et paradoxalement la plus violée. 55,5 % des homepages mondiales ont des images sans alternative textuelle, selon le WebAIM Million 2025. Sur les boutiques PrestaShop qu’on audite, le chiffre est probablement encore plus haut, parce que les images de fiches produits sont souvent importées en masse depuis des fournisseurs tiers (ERP, Caisse, Excel) sans alt text.

Les critères clés à vérifier :

Critère 1.1 — Chaque image a-t-elle une alternative textuelle ?

Toute image porteuse d’information (donc votre photo de produit, votre logo, vos pictogrammes informatifs) doit avoir un attribut alt rempli avec une description pertinente. Les images purement décoratives doivent avoir un alt="" (vide, pas absent).

Dans PrestaShop, le fichier à auditer en priorité est /themes/classic/templates/catalog/_partials/product-images.tpl pour les fiches produits, et /themes/classic/templates/checkout/_partials/cart-detailed-product-line.tpl pour le panier.

Critère 1.2 — Les alternatives textuelles sont-elles pertinentes ?

Avoir un alt text ne suffit pas, il faut qu’il soit utile. Pour une chemise blanche en lin manches longues, l’alt « image » ou « produit » ne sert à rien. Il faut « Chemise blanche en lin manches longues, col italien ». Un client malvoyant a besoin de la même information décisionnelle qu’un client voyant : la couleur, la coupe, le matériau, les détails distinctifs.

Critère 1.3 — Les images-textes sont-elles évitées ?

Vos bannières promo « -50 % sur la collection été » avec le texte gravé dans une image JPG sont un problème. Le lecteur d’écran ne lit pas le texte d’une image. Il faut soit éviter les images-textes (privilégier du HTML stylé en CSS), soit fournir le texte équivalent en alt complet.

Critère 1.4 — Les images complexes (graphiques, infographies) ont-elles une description longue ?

Si vous avez des graphiques (statistiques produit, comparatifs, schémas techniques), un alt court ne suffit pas. Il faut une description longue accessible, soit dans le texte adjacent, soit via aria-describedby.

Ce qu’on voit chez nos clients : 90 % des fiches produits PrestaShop ont des alt soit vides, soit génériques (« image », « produit », nom du fichier comme « IMG_4521.jpg »). C’est le quick win numéro un en accessibilité PrestaShop. Et c’est aussi du SEO pur : Google adore les alt pertinents.

---

Thématique 2 — Cadres

Cette thématique concerne les <iframe>. Sur une boutique PrestaShop, vous en avez principalement à trois endroits : les modules de paiement (Stripe, PayPal qui injectent des iframes sécurisées), les vidéos embed (YouTube, Vimeo), et certaines cartes Google Maps si vous affichez vos points de retrait.

Critère 2.1 — Chaque cadre a-t-il un titre ?

Tout <iframe> doit avoir un attribut title qui décrit son contenu. Pas le nom du service, mais ce qu’il fait. « Formulaire de paiement Stripe » est un bon title. « iframe » ou « Stripe » sont insuffisants.

Critère 2.2 — Le contenu des cadres est-il pertinent ?

Les iframes doivent fonctionner correctement avec les technologies d’assistance. C’est principalement la responsabilité du fournisseur de service (Stripe, PayPal le font correctement, YouTube aussi, certains modules tiers moins). Si vous utilisez un module obscur qui injecte une iframe non accessible, vous êtes responsable du résultat.

C’est une thématique généralement peu coûteuse à corriger : ajouter les titres prend quelques minutes par template.

---

Thématique 3 — Couleurs

Le contraste est l’erreur d’accessibilité la plus fréquente au monde. 79 % des homepages mondiales ont du texte à faible contraste (WebAIM Million 2025), et la moyenne est de 30 instances par page.

Critère 3.1 — Information par couleur seule ?

Vous ne pouvez pas indiquer une information uniquement par la couleur. Si vos prix barrés sont en gris et vos prix soldés en rouge, un daltonien ne verra pas la différence. Il faut un signal complémentaire : un libellé textuel (« Prix barré : », « Prix soldé : »), une icône, ou une mise en forme distincte.

Critère 3.2 — Les contrastes texte/fond respectent-ils les ratios WCAG AA ?

C’est le critère le plus testé et le plus violé. Les ratios minimaux à respecter :

• 4,5:1 pour le texte standard (en dessous de 18px non gras, ou 14px gras)
• 3:1 pour le grand texte (à partir de 18px non gras, ou 14px gras)
• 3:1 pour les composants d’interface (bordures de boutons, icônes)

Pour mesurer : utilisez WebAIM Contrast Checker (gratuit) ou les outils intégrés à axe DevTools / Lighthouse.

Sur PrestaShop, les zones critiques sont les libellés gris clair (caractéristiques produits, mentions légales en footer), les boutons d’action avec fond pastel, et les liens dans le footer noir. Le thème Classic par défaut a plusieurs zones à risque.

Critère 3.3 — Le contraste des composants d’interface est-il suffisant ?

Les bordures de vos champs de formulaire, les icônes du panier, les indicateurs de statut (nouveau, soldé, indisponible) doivent eux aussi respecter le ratio 3:1 minimum.

📊 Donnée terrain CYBERIAL : sur les boutiques PrestaShop qu’on audite, le contraste est le deuxième point de blocage le plus fréquent après les alt text d’images. Les responsables marketing aiment les nuances pastel, les designers vont au-delà des ratios pour des raisons esthétiques. Résultat : des sites qui passent les autres critères mais qui calent sur le contraste, parfois sur des dizaines d’instances.

---

Thématique 4 — Multimédia

Cette thématique concerne les vidéos et l’audio sur votre boutique. Si vous avez des vidéos produit (démo, déballage), des vidéos témoignages clients, ou des intégrations YouTube, vous êtes concerné.

Critère 4.1 — Sous-titres synchronisés présents ?

Toute vidéo doit avoir des sous-titres synchronisés pour les utilisateurs sourds ou malentendants. Pour une intégration YouTube, vérifiez que la vidéo source a bien des sous-titres (et pas juste les sous-titres automatiques, qui ne sont pas conformes).

Critère 4.2 — Audiodescription présente pour les vidéos avec contenu visuel important ?

Si vos vidéos contiennent des informations qui ne sont pas dans la bande audio (texte affiché, démonstration silencieuse), il faut une audiodescription. Pour la plupart des vidéos e-commerce simples, ce n’est pas applicable.

Critère 4.3 — Transcription textuelle disponible ?

Une alternative textuelle complète à la vidéo doit être accessible quelque part (idéalement sur la même page, sous la vidéo, dans un bloc dépliant).

Critère 4.4 — Contrôles utilisables au clavier ?

Les boutons play/pause, volume, plein écran doivent être atteignables et activables au clavier. C’est natif sur YouTube et la plupart des players modernes, mais à vérifier sur les players custom.

Si vous n’avez pas de vidéo sur votre boutique, toute cette thématique passe en NA et vous gagnez du temps.

---

Thématique 5 — Tableaux

Trois types de tableaux à distinguer sur PrestaShop : les tableaux de données (panier, historique commandes, comparateur), les tableaux de mise en forme (souvent dans les emails transactionnels, déconseillés), et les tableaux complexes (rares en e-commerce).

Critère 5.1 — En-têtes correctement déclarés ?

Les tableaux de données doivent avoir des <th> pour les en-têtes, pas des <td> mis en gras. Le <th> doit avoir un attribut scope qui indique s’il s’agit d’un en-tête de colonne (scope="col") ou de ligne (scope="row").

Critère 5.2 — Le résumé est-il pertinent ?

Pour les tableaux complexes, un résumé textuel doit décrire la structure et le contenu général.

Critère 5.3 — Tableaux de mise en forme ?

Si vous utilisez encore des <table> pour faire votre mise en page (ce qui devrait être impossible sur PrestaShop moderne, mais on en voit encore dans des emails), c’est non conforme. La mise en page se fait en CSS.

Sur PrestaShop, les fichiers à auditer en priorité sont cart.tpl (panier), history.tpl (historique commandes client), et tous les emails transactionnels (généralement dans /mails/fr/).

---

Thématique 6 — Liens

C’est une thématique sous-estimée. 45 % des homepages mondiales contiennent des liens vides ou ambigus (WebAIM Million 2025). Les conséquences sont importantes : un utilisateur de lecteur d’écran navigue souvent en listant tous les liens d’une page. Si vos liens s’appellent tous « En savoir plus » ou « Cliquez ici », il ne peut rien faire avec cette liste.

Critère 6.1 — Chaque lien a-t-il un intitulé pertinent ?

L’intitulé doit décrire la destination ou la fonction. « Voir la fiche détaillée de la chemise blanche col italien » est bon. « Cliquez ici » est mauvais. « Lire la suite » est mauvais sauf si le contexte immédiat clarifie.

Critère 6.2 — Les liens vides sont-ils évités ?

Un lien qui ne contient qu’une image sans alt (ou avec alt vide), ou qu’un pictogramme sans texte alternatif, est considéré comme vide. Le lecteur d’écran annonce « lien » sans savoir où il mène.

Critère 6.3 — Les liens identiques mènent-ils à la même destination ?

Si vous avez 10 boutons « En savoir plus » sur votre page d’accueil qui mènent à 10 pages différentes, c’est non conforme. Soit vous différenciez les intitulés, soit vous ajoutez un attribut aria-label qui précise la destination de chacun.

Sur PrestaShop, les zones critiques sont la page d’accueil (modules slider, modules « catégories vedettes » avec « Voir » répété), le footer (qui contient souvent des liens orphelins), et les fiches produits (« Ajouter », « Voir », « Comparer » sans précision).

Au passage : c’est aussi un sujet SEO. Google pénalise les liens non descriptifs depuis des années. Vous faites de l’accessibilité et vous gagnez en SEO. Double bénéfice.

---

Thématique 7 — Scripts

C’est la thématique la plus technique. Elle concerne tout ce qui est généré ou modifié par JavaScript sur votre site : popups, sliders, ajout au panier en Ajax, validation de formulaires en temps réel, mise à jour dynamique du panier, mega-menus.

Critère 7.1 — Compatibilité avec les technologies d’assistance ?

Tous les composants JavaScript doivent rester utilisables avec un lecteur d’écran. Si votre menu déroulant n’apparaît pas dans l’arbre d’accessibilité quand on l’ouvre au clavier, c’est non conforme.

Critère 7.2 — Scripts conçus pour être contrôlables au clavier ?

Tout ce qui se fait à la souris doit pouvoir se faire au clavier. Survol → focus. Clic → Entrée. Glisser-déposer → alternative.

Critère 7.3 — Messages annoncés correctement ?

Quand vous ajoutez un produit au panier en Ajax, le lecteur d’écran ne voit rien se passer si le message « Produit ajouté » n’est pas annoncé via un aria-live. Pour le marchand voyant, le compteur du panier passe de 2 à 3, c’est évident. Pour l’utilisateur aveugle, c’est invisible.

⚠️ Attention : c’est ici que la majorité des modules tiers PrestaShop posent problème. Les modules de wishlist, de comparateur, de recherche dynamique, de filtres à facettes utilisent massivement du JavaScript et oublient presque toujours les aria-live. Avant d’installer un module qui modifie l’interface dynamiquement, demandez à son éditeur s’il est conforme RGAA. Vous serez surpris du nombre de « non » embarrassés.

Critère 7.4 — Pas de focus invisible après action JavaScript ?

Quand un utilisateur valide une action, le focus clavier doit aller à un endroit logique : sur le message de confirmation, sur le champ suivant à remplir, sur le résultat de l’action. Beaucoup de scripts laissent le focus sur un élément masqué, et l’utilisateur clavier perd ses repères.

---

Thématique 8 — Éléments obligatoires

C’est la thématique des fondamentaux HTML. Souvent négligée parce qu’elle paraît évidente, et pourtant régulièrement violée.

Critère 8.1 — Le doctype est-il présent et valide ?

Votre page doit commencer par <!DOCTYPE html>. Sur PrestaShop moderne, c’est natif. Sur des thèmes très anciens ou bricolés, à vérifier.

Critère 8.2 — Le titre de page est-il présent et pertinent ?

Chaque page doit avoir une balise <title> unique et descriptive. Les fichiers head.tpl du thème en sont responsables. Vérifiez que vos pages produits ne s’appellent pas toutes « Boutique » ou « Produit ».

Critère 8.3 — La langue principale est-elle déclarée ?

L’attribut lang doit être présent sur la balise <html>. Pour une boutique française, ce sera <html lang="fr">. Cette information permet aux lecteurs d’écran de prononcer correctement les mots dans la bonne langue. Sans cet attribut, un lecteur d’écran français lira votre page en accentuant comme s’il s’agissait d’anglais (ou inversement).

Critère 8.4 — Les changements de langue sont-ils signalés ?

Si une partie de votre page est dans une autre langue (un témoignage en anglais, une marque internationale citée), il faut le préciser : <span lang="en">Made in USA</span>.

Critère 8.5 — Le code HTML est-il valide ?

Pas d’erreurs de balisage majeures (balises non fermées, attributs dupliqués, ID en doublon). C’est testable avec le validateur W3C. Sur PrestaShop, les erreurs viennent souvent des modules qui injectent du HTML dans le <head> ou en fin de page.

---

Thématique 9 — Structuration de l’information

La structure de votre HTML est ce qui permet au lecteur d’écran de comprendre l’organisation de votre page. C’est la colonne vertébrale.

Critère 9.1 — Hiérarchie de titres cohérente ?

Vos <h1> à <h6> doivent suivre une hiérarchie logique : pas de saut de niveau (pas de h1 directement suivi d’un h3). Un seul <h1> par page (le titre principal). Les sous-sections en <h2>, leurs sous-parties en <h3>, etc.

C’est un critère très important parce que les utilisateurs de lecteurs d’écran naviguent souvent en parcourant les titres avec la touche H. Si vos titres sont mal structurés, ils ne peuvent pas se repérer.

Critère 9.2 — Listes correctement balisées ?

Vos listes doivent utiliser <ul>, <ol>, <li>. Pas des <div> avec des puces graphiques. Pour une fiche produit qui liste les caractéristiques, c’est <ul> obligatoire.

Critère 9.3 — Citations balisées ?

Si vous avez des témoignages clients ou des citations, utilisez <blockquote> pour les citations longues et <q> pour les citations courtes en ligne.

Critère 9.4 — Landmarks ARIA ou éléments HTML5 sémantiques utilisés ?

Votre page doit utiliser <header>, <nav>, <main>, <aside>, <footer> (ou les rôles ARIA équivalents). Cela permet aux lecteurs d’écran de proposer une navigation directe vers chaque grande zone.

Pour une boutique PrestaShop type :

<header>
  <nav aria-label="Navigation principale">...</nav>
</header>

<main>
  <h1>Titre de la page</h1>
  <!-- Contenu principal -->
</main>

<aside aria-label="Filtres produits">
  <!-- Filtres latéraux -->
</aside>

<footer>
  <nav aria-label="Pied de page">...</nav>
</footer>

Sur PrestaShop Classic, certaines de ces balises sont natives, d’autres manquent ou sont mal positionnées. C’est un audit à faire fichier par fichier sur les templates de mise en page (/themes/classic/templates/layouts/).

---

Thématique 10 — Présentation de l’information

C’est la thématique CSS et mise en forme. Elle concerne la façon dont l’utilisateur peut adapter l’affichage à ses besoins.

Critère 10.1 — La présentation est-elle gérée par CSS ?

Pas de balises de mise en forme HTML obsolètes (<font>, <center>, <b> quand on veut dire <strong>, etc.). Toute la mise en forme passe par CSS.

Critère 10.2 — Le contenu reste-t-il lisible avec les CSS désactivées ?

Test pratique : si vous désactivez les CSS de votre boutique, le contenu doit rester lisible et cohérent (juste sans la mise en forme). Si tout part en sucette parce que des <div> génériques portent toute la structure, c’est un problème.

Critère 10.3 — Le zoom à 200 % fonctionne-t-il sans perte de contenu ?

Un utilisateur malvoyant peut avoir besoin d’agrandir l’affichage. À 200 % de zoom, votre site doit rester utilisable : pas de débordements, pas de texte coupé, pas de boutons inaccessibles.

Critère 10.4 — Le focus est-il visible ?

Quand un utilisateur navigue au clavier (touche Tab), l’élément actuellement sélectionné doit être visuellement distinct. Beaucoup de thèmes utilisent outline: none dans leur CSS, ce qui supprime l’indicateur de focus par défaut sans le remplacer. C’est non conforme, et c’est très facile à corriger : utilisez :focus-visible avec un style distinctif.

Critère 10.5 — L’espacement du texte peut-il être ajusté ?

L’utilisateur doit pouvoir augmenter l’espacement entre lignes, mots, lettres sans casser la mise en page. C’est un critère technique qui se vérifie avec une extension type « Stylus ».

Critère 10.6 — Les textes restent lisibles à différentes tailles ?

Pas de texte qui devient illisible quand on agrandit (à cause de containers à largeur fixe en pixels qui ne s’adaptent pas).

---

Thématique 11 — Formulaires

C’est LA thématique critique en e-commerce. Tout votre tunnel de commande, votre création de compte, votre formulaire de contact, votre recherche : c’est du formulaire. Et c’est là que les utilisateurs handicapés abandonnent massivement.

48 % des homepages mondiales ont des champs de formulaire sans label (WebAIM Million 2025). Sur les formulaires de tunnel, la proportion est encore plus haute.

Critère 11.1 — Chaque champ a-t-il une étiquette (label) ?

Tout <input>, <select>, <textarea> doit être associé à un <label> via l’attribut for qui correspond à l’id du champ.

<!-- BIEN -->
<label for="email">Adresse email</label>
<input type="email" id="email" name="email">

<!-- MAL : pas de label -->
<input type="email" name="email" placeholder="Votre email">

<!-- MAL : label sans for -->
<label>Adresse email</label>
<input type="email">

Critère 11.2 — Chaque étiquette est-elle pertinente ?

L’étiquette doit dire clairement ce qu’on attend. « Email » est mieux que « Adresse ». « Code postal (5 chiffres) » est mieux que « CP ».

Critère 11.3 — Les placeholders ne remplacent pas les labels ?

Le placeholder (le texte gris dans un champ vide) n’est pas un label. Il disparaît dès que l’utilisateur tape quelque chose. Et les lecteurs d’écran ne l’annoncent pas de manière fiable. C’est une erreur ultra-fréquente sur PrestaShop, notamment dans les formulaires de connexion et de checkout.

Critère 11.4 — Les champs obligatoires sont-ils signalés ?

Visuellement (par un astérisque par exemple) ET techniquement (via l’attribut required ou aria-required="true").

Critère 11.5 — Les regroupements logiques sont-ils faits ?

Pour les groupes de champs liés (adresse de livraison, choix de transporteur en radios), utilisez <fieldset> et <legend>. C’est ce qui permet au lecteur d’écran d’annoncer « Section adresse de livraison : champ Prénom » au lieu de « champ Prénom » sans contexte.

Critère 11.6 — Les erreurs sont-elles correctement gérées ?

Quand l’utilisateur soumet un formulaire avec une erreur, plusieurs choses doivent se passer :

• Le message d’erreur doit être annoncé immédiatement au lecteur d’écran (via role="alert" ou aria-live="assertive")
• Le champ en erreur doit être marqué avec aria-invalid="true"
• Le message d’erreur doit être lié programmatiquement au champ via aria-describedby
• Le focus doit être déplacé sur le premier champ en erreur

Voici à quoi ça ressemble en HTML :

<label for="email">Adresse email</label>
<input type="email" id="email"
       aria-describedby="email-error"
       aria-invalid="true">
<span id="email-error" role="alert">
  Format d'email invalide. Exemple : nom@domaine.fr
</span>

Critère 11.7 — Les messages d’erreur sont-ils précis ?

Pas de « Erreur dans le formulaire ». Pas de « Veuillez vérifier les champs en rouge » (c’est inutile pour un daltonien). Il faut « Le code postal doit comporter 5 chiffres » ou « Le mot de passe doit contenir au moins 8 caractères dont 1 chiffre ».

Critère 11.8 — Les suggestions de correction sont-elles fournies ?

Quand c’est possible, suggérez la correction. « Vouliez-vous dire jean@gmail.com ? » est mieux que « Email invalide ».

Critère 11.9 — Le contrôle de soumission est-il possible ?

L’utilisateur doit pouvoir vérifier ses données avant validation finale (notamment pour les commandes). C’est ce que fait par défaut PrestaShop avec l’étape de récapitulatif avant paiement.

📊 Donnée terrain CYBERIAL : sur les 50 dernières boutiques PrestaShop qu’on a auditées, toutes avaient au moins un manquement majeur en thématique formulaires. Le plus fréquent : le placeholder utilisé comme label. Le plus dommageable : l’absence d’annonce vocale des erreurs (l’utilisateur pense que sa commande est validée, alors qu’elle est rejetée). C’est cette thématique qu’il faut traiter en priorité absolue.

Tous ces points seront détaillés étape par étape dans le chapitre 4 sur le tunnel de commande PrestaShop.

---

Thématique 12 — Navigation

Cette thématique vise à donner à l’utilisateur plusieurs moyens d’atteindre l’information qu’il cherche.

Critère 12.1 — Plusieurs moyens d’accès ?

Votre boutique doit proposer plusieurs façons d’accéder aux contenus : moteur de recherche, plan du site, navigation par catégories. Pas tout en même temps obligatoirement, mais au moins deux moyens distincts.

Critère 12.2 — Le plan du site est-il pertinent ?

Si vous proposez un plan du site (ce qui est recommandé), il doit refléter la structure réelle de votre boutique et être à jour.

Critère 12.3 — Le fil d’Ariane est-il utilisable ?

Le breadcrumb doit indiquer où on se trouve dans la hiérarchie. Sur PrestaShop, c’est généralement bien fait nativement, mais vérifiez qu’il est présent sur toutes les pages profondes.

Critère 12.4 — Le menu de navigation est-il accessible au clavier ?

C’est un point critique pour les méga-menus. L’ouverture des sous-niveaux doit se faire au clavier (touche Entrée ou Espace), pas seulement au survol souris. La fermeture doit se faire avec Escape. Le aria-expanded doit être mis à jour dynamiquement.

Critère 12.5 — Un mécanisme d’évitement (skip link) est-il présent ?

C’est un lien généralement caché qui apparaît au premier focus clavier, et qui permet de sauter directement au contenu principal en évitant le header et le menu. Pour un utilisateur clavier, c’est un gain de temps énorme : il évite de tabuler à travers 30 liens du header à chaque page.

<a href="#main-content" class="skip-link">
  Aller au contenu principal
</a>

Avec le CSS qui le rend invisible par défaut mais visible au focus.

Critère 12.6 — La page courante est-elle indiquée dans la navigation ?

L’item de menu correspondant à la page actuelle doit être visuellement distinct ET techniquement marqué : aria-current="page".

---

Thématique 13 — Consultation

C’est la thématique « divers » qui regroupe plusieurs critères variés mais importants.

Critère 13.1 — Les limites de temps sont-elles ajustables ?

Si vous avez une session qui expire (panier conservé X minutes, paiement à confirmer dans Y secondes), l’utilisateur doit pouvoir prolonger ou désactiver cette limite. Sinon, un utilisateur qui prend du temps à remplir le formulaire (déficience cognitive, motrice, ou simplement débutant) sera bloqué.

Critère 13.2 — Les contenus en mouvement sont-ils contrôlables ?

Vos sliders, carrousels, animations en boucle doivent avoir un bouton pause/play visible. Idéalement, ils s’arrêtent automatiquement au focus clavier ou au survol.

Critère 13.3 — L’ouverture de nouvelles fenêtres est-elle signalée ?

Si un lien ouvre une nouvelle fenêtre ou un nouvel onglet, c’est une bonne pratique de le signaler dans l’intitulé du lien (« Ouvrir le PDF des CGV — nouvelle fenêtre »).

Critère 13.4 — Les fichiers téléchargeables ont-ils leur format précisé ?

Un lien vers un PDF doit indiquer qu’il s’agit d’un PDF, idéalement avec son poids. « Télécharger le guide d’utilisation (PDF, 2,3 Mo) ».

Critère 13.5 — Les pop-ups modales sont-elles correctement gérées ?

Quand une modal s’ouvre (votre popup d’ajout au panier, par exemple), plusieurs comportements sont obligatoires :

• Le focus doit être déplacé dans la modal à l’ouverture
• Le focus doit être « trappé » dans la modal (pas de Tab vers l’arrière-plan)
• La touche Escape doit fermer la modal
• Le focus doit retourner sur l’élément déclencheur à la fermeture
• Le contenu de fond doit être passé en inert ou aria-hidden="true"

Critère 13.6 — Les animations peuvent-elles être désactivées ?

Les animations excessives peuvent provoquer des malaises chez certaines personnes (épilepsie photosensible, vertiges). Vous devez respecter la préférence système prefers-reduced-motion.

@media (prefers-reduced-motion: reduce) {
  * {
    animation: none !important;
    transition: none !important;
  }
}

C’est trois lignes de CSS, et ça vous évite un point de blocage.

Ce qu’il faut retenir de ce chapitre

C’est dense, je sais. Voici les trois angles à garder en tête :

1. Les thématiques ne sont pas équivalentes en risque.

Si vous deviez n’en traiter que quatre, ce serait dans cet ordre : Formulaires (thématique 11), Images (thématique 1), Couleurs (thématique 3), Scripts (thématique 7). Ce sont les zones où vous perdez vos clients et où les contrôles vont chercher en premier.

2. La règle « un seul NC contamine tout » change la stratégie.

Vous ne pouvez pas vous contenter de corriger « la majorité » des cas. Si vous avez 200 fiches produits et 5 sans alt text, votre conformité sur ce critère est NC pour le site entier. Il faut corriger les 5.

3. Beaucoup de critères sont peu coûteux à corriger.

Sur la centaine de critères existants, une bonne partie se règle avec quelques modifications de templates Smarty et un peu de CSS. Le gros des coûts vient de la thématique formulaires (refonte du tunnel, gestion des erreurs) et de la thématique scripts (modules tiers à remplacer).

Le chapitre suivant va se concentrer précisément sur la zone la plus critique : le tunnel de commande PrestaShop en 5 étapes. Avec les corrections concrètes étape par étape, fichier par fichier.

Le tunnel de commande PrestaShop en 5 étapes : le point critique

S’il y a un endroit où votre boutique PrestaShop perd des clients tous les jours sans que vous le sachiez, c’est dans le tunnel de commande. Pas seulement à cause de l’accessibilité. Mais l’accessibilité y joue un rôle énorme, parce que c’est l’endroit où chaque petit défaut se transforme en abandon.

Quelques chiffres pour cadrer l’enjeu. 77 % des poursuites pour inaccessibilité numérique aux États-Unis visent l’e-commerce. 71 % des utilisateurs en situation de handicap abandonnent immédiatement un site qui leur pose problème. L’étude eCommerce Accessibility 2025 chiffre à 2,3 milliards de dollars par an le manque à gagner uniquement dû aux tunnels d’achat inaccessibles.

Pour vous, marchand, ces abandons sont invisibles. Vous voyez juste un taux de conversion en baisse. Vous suspectez le prix, la concurrence, les frais de port. Rarement l’accessibilité. Pourtant, c’est probablement la cause la plus structurelle.

Dans ce chapitre, je vais vous emmener étape par étape dans le tunnel PrestaShop standard (5 étapes), avec pour chaque étape : ce qui se passe techniquement, ce qui pose problème en accessibilité, et comment corriger.

Pourquoi le tunnel est l’enjeu numéro un

Avant d’entrer dans le détail technique, écoutez ce témoignage de Manuel Pereira. C’est lui qu’on cite régulièrement dans cet article. Il est responsable du pôle accessibilité numérique du Certam-AVH (Centre d’Évaluation et de Recherche sur les Technologies pour les Aveugles et les Malvoyants), rattaché à l’Association Valentin Haüy. Il est lui-même aveugle de naissance et utilise quotidiennement les sites e-commerce français.

🎥 VIDÉO : Manuel Pereira chez CECIAA – Durée : environ 1 heure (vous pouvez naviguer dans le live)

Sa formule reste pour moi la plus marquante de tout le débat français sur l’accessibilité e-commerce : « Il y a presque autant de chances de gagner au loto que de réussir à valider son panier » sur la majorité des sites e-commerce français.

Cette formule n’est pas une boutade. Elle décrit littéralement ce qui se passe : un utilisateur aveugle qui veut acheter un produit sur votre boutique parcourt votre catalogue, ajoute un produit au panier, démarre le tunnel de commande, et se heurte à un mur quelque part. Parfois à l’étape 1 (formulaire de connexion), parfois à l’étape 4 (case à cocher CGV mal labellisée), parfois à l’étape 5 (page de confirmation totalement vide pour le lecteur d’écran).

Michael Taylor, contributeur régulier du blog UsableNet et lui aussi utilisateur de lecteur d’écran, a publié entre décembre 2025 et mars 2026 une série d’articles décortiquant son expérience d’achat sur des sites e-commerce. Sa conclusion est sans ambiguïté : toutes les étapes du tunnel posent problème, à des degrés divers, sur la quasi-totalité des sites qu’il teste.

C’est ce qu’on va corriger.

L’architecture PrestaShop : OrderController vs OrderOpcController

Petit point technique pour comprendre ce qu’on manipule. Le tunnel PrestaShop est géré par deux contrôleurs PHP alternatifs, selon la configuration de votre boutique :

OrderController : c’est le tunnel multi-étapes classique. L’utilisateur passe d’une page à une autre (panier → identification → adresses → livraison → paiement → confirmation). C’est le standard PrestaShop.

OrderOpcController : c’est le tunnel One Page Checkout natif. Toutes les étapes sont sur une seule page, mises à jour dynamiquement en Ajax. C’est une option dans le back-office (Préférences > Commande > Type de tunnel).

Les deux contrôleurs héritent de ParentOrderController qui contient la logique commune.

Pour l’accessibilité, le tunnel multi-étapes est plus simple à rendre accessible que le OPC. Avec le multi-étapes, chaque page est isolée, le focus se réinitialise naturellement à chaque chargement, et les annonces sont plus faciles à gérer. Avec l’OPC, vous devez gérer les mises à jour dynamiques avec des aria-live, le déplacement de focus à chaque étape, et la cohérence de l’état pour le lecteur d’écran.

Mon conseil: si votre boutique est compliquée et si l’accessibilité est une priorité, restez sur le tunnel multi-étapes natif au moins le temps de la mise en conformité. Vous gagnerez en taux de conversion sur l’OPC plus tard, mais commencez par sécuriser l’essentiel.

Les fichiers à connaître pour les corrections :

/themes/classic/templates/checkout/
├── checkout.tpl                              # Template principal du tunnel
├── _partials/
│   ├── steps/
│   │   ├── personal-information.tpl          # Étape 1 : identification
│   │   ├── addresses.tpl                     # Étape 2 : adresses
│   │   ├── shipping.tpl                      # Étape 3 : livraison
│   │   └── payment.tpl                       # Étape 4 : paiement
│   ├── cart-detailed.tpl                     # Récapitulatif panier
│   └── cart-detailed-product-line.tpl        # Une ligne produit
└── order-confirmation.tpl                    # Étape 5 : confirmation

Tous ces fichiers se surchargent dans un thème enfant pour ne pas modifier le core. C’est la méthode propre.

Étape 0 — La page panier

Avant le tunnel proprement dit, il y a la page panier. C’est l’antichambre. Si elle est mal accessible, l’utilisateur n’arrive même pas au checkout.

Fichier à auditer : /themes/classic/templates/checkout/cart.tpl et ses partials.

Les checks RGAA prioritaires :

• Tableau du panier correctement structuré. Le récapitulatif des produits est généralement présenté comme un tableau. Il doit avoir des <th> pour les en-têtes (Produit, Quantité, Prix unitaire, Total), avec scope="col". Beaucoup de thèmes utilisent des <div> à la place, ce qui prive le lecteur d’écran de tout contexte.
• Boutons de quantité accessibles. Les boutons « + » et « − » pour modifier la quantité doivent être de vrais <button> avec un label explicite (« Augmenter la quantité de [nom du produit] » plutôt que juste « + »). Et ils doivent fonctionner au clavier (touches Entrée et Espace).
• Bouton de suppression labellisé. « Supprimer » sans précision ne dit pas quoi est supprimé. Préférez « Supprimer le produit Chemise blanche du panier ». Vous pouvez utiliser un aria-label pour ne pas alourdir visuellement.
• Annonce des modifications du panier. Quand l’utilisateur change une quantité, le total se met à jour en Ajax. Le lecteur d’écran ne s’en aperçoit pas si vous n’utilisez pas un aria-live. Ajoutez une zone vocale pour annoncer « Quantité mise à jour. Nouveau total : 47,50 € ».
• Code promo correctement géré. Le champ pour entrer un code promo doit avoir un <label> clair. Le message d’erreur ou de succès doit être annoncé via role="alert".

📊 Donnée terrain CYBERIAL : on voit beaucoup de boutiques où le panier est techniquement correct côté visuel (le total se met à jour, le bouton supprimer fonctionne), mais où le lecteur d’écran ne reçoit aucune information. Pour l’utilisateur aveugle, il a l’impression que rien ne se passe. Beaucoup abandonnent à ce stade en pensant que le site est cassé.

Étape 1 — Identification

C’est la première étape du tunnel proprement dit. L’utilisateur choisit entre se connecter, créer un compte, ou commander en invité.

Fichier à auditer : /themes/classic/templates/checkout/_partials/steps/personal-information.tpl et /themes/classic/templates/customer/_partials/login-form.tpl pour le formulaire de connexion.

Les checks RGAA prioritaires :

• Formulaire de connexion accessible. Email et mot de passe doivent avoir des <label for="..."> explicites. Pas de placeholder seul. Le bouton « Se connecter » doit être un vrai <button type="submit">.
• Bascule invité / création de compte clavier. Les onglets ou boutons radio qui permettent de choisir entre invité, connexion, création doivent être navigables au clavier avec les flèches et activables avec Espace ou Entrée. Si vous utilisez le pattern ARIA tablist, suivez la spécification W3C.
• Lien « Mot de passe oublié » avec contexte. Pas juste « Oublié ? ». Préférez « Mot de passe oublié ? Récupération par email ».
• Boutons de connexion sociale (si présents). Si vous proposez Facebook Connect, Google Sign-In, Apple Sign-In, chaque bouton doit avoir un aria-label explicite (« Se connecter avec Google »). L’icône seule ne suffit pas.
• Gestion des erreurs. Si l’email est invalide, le mot de passe trop court, ou les identifiants incorrects, l’erreur doit être : Annoncée immédiatement via role="alert" ; Liée au champ via aria-describedby ; Visible textuellement (pas juste un encadrement rouge) ; Le focus doit être déplacé sur le premier champ en erreur.

<label for="email">Adresse email</label>
<input type="email" id="email"
       aria-describedby="email-error"
       aria-invalid="true">
<span id="email-error" role="alert">
  Cet email n'est pas reconnu. Vérifiez l'orthographe ou créez un compte.
</span>

Étape 2 — Adresses

L’utilisateur saisit ou sélectionne son adresse de livraison et de facturation. C’est l’étape avec le plus de champs, donc la plus exposée aux problèmes d’accessibilité.

Fichier à auditer : /themes/classic/templates/checkout/_partials/steps/addresses.tpl et /themes/classic/templates/customer/_partials/address-form.tpl.

Les checks RGAA prioritaires :

• Tous les champs ont des labels visibles ET techniques. Prénom, nom, société (si applicable), adresse, complément d’adresse, code postal, ville, pays, téléphone. Chaque label avec for correctement lié à l’id du champ.
• Le sélecteur de pays est un vrai <select>. Pas une combobox custom JavaScript qui réinvente la roue. Un <select> natif est nativement accessible avec les flèches haut/bas, la frappe au clavier pour aller à un pays, etc. Si vous avez vraiment besoin d’un combobox enrichi (recherche dans la liste), utilisez le pattern ARIA combobox du W3C, mais c’est complexe à implémenter correctement.
• Les suggestions Google Maps Autocomplete sont annoncées. Si vous utilisez l’autocomplétion d’adresse, les suggestions doivent être annoncées au lecteur d’écran. C’est un point de blocage classique : visuellement on voit une liste déroulante, le lecteur d’écran ne perçoit rien. La solution est d’ajouter un aria-live="polite" sur le conteneur des suggestions, et de gérer la navigation au clavier (flèches haut/bas, Entrée pour sélectionner, Escape pour fermer).
• La case « adresse de facturation identique » est explicite. Pas juste une case sans label. Le label doit être clair : « Utiliser la même adresse pour la facturation ».
• La gestion des erreurs est exemplaire. À la validation, si plusieurs champs sont en erreur, le focus va sur le premier, un message global annonce le nombre d’erreurs (« Le formulaire contient 3 erreurs »), et chaque champ en erreur a son message lié.
• Les regroupements logiques utilisent fieldset/legend. Dans le formulaire, les blocs « Adresse de livraison » et « Adresse de facturation » doivent être encadrés par :

<fieldset>
  <legend>Adresse de livraison</legend>
  <!-- les champs -->
</fieldset>

Le <legend> est annoncé par les lecteurs d’écran à chaque fois que l’utilisateur entre dans un champ du fieldset. Ça donne le contexte sans répétition visuelle.

⚠️ Attention : sur PrestaShop, l’autocomplétion d’adresse Google Maps est gérée par un module (généralement gsitemap ou un module tiers de Mondial Relay, etc.). Quand vous changez de module, vérifiez systématiquement que l’accessibilité est préservée. C’est l’un des points les plus régressifs au fil des mises à jour.

Étape 3 — Livraison

L’utilisateur choisit son transporteur. C’est typiquement une liste de boutons radio.

Fichier à auditer : /themes/classic/templates/checkout/_partials/steps/shipping.tpl.

Les checks RGAA prioritaires :

• Liste de transporteurs en <input type="radio"> natifs. Pas une réinvention en <div> avec JavaScript. Les radios natifs sont accessibles automatiquement, navigables avec les flèches, regroupables via le même name.
• Logos transporteurs avec alt descriptif. « Logo Colissimo » est mieux que « Colissimo ». Encore mieux : « Colissimo, livraison en 48h ouvrées ».
• Délai et prix annoncés textuellement. Pas seulement par mise en forme. « Colissimo : 48h ouvrées, 5,90 € » doit être lisible par le lecteur d’écran sans chercher dans des éléments masqués.
• Frais de port mis à jour annoncés. Quand l’utilisateur change de transporteur, le total commande change. Cette mise à jour doit être annoncée via aria-live dans la zone de récapitulatif.
• Champ commentaire avec label. Le champ pour ajouter une note (« Sonner à l’interphone », « Laisser chez le voisin ») doit avoir un <label> explicite, pas juste un placeholder « Ajouter un commentaire ».

Étape 4 — Paiement

C’est l’étape la plus critique légalement et la plus complexe techniquement, parce qu’elle combine vos formulaires PrestaShop avec les iframes des prestataires de paiement.

Fichier à auditer : /themes/classic/templates/checkout/_partials/steps/payment.tpl et tous les modules de paiement installés.

Les checks RGAA prioritaires :

• Méthodes de paiement en <input type="radio"> natifs. Comme pour les transporteurs. Le choix entre carte bancaire, PayPal, virement, Stripe, etc. doit utiliser des radios natives.
• Logos cartes bancaires avec alt. « Visa », « Mastercard », « American Express » accessibles. Si vous affichez aussi des logos de sécurité (3D Secure, Verified by Visa), ils doivent eux aussi avoir des alt explicites.
• Iframes de paiement avec title. Stripe, PayPal et la plupart des prestataires sérieux gèrent leurs iframes accessibles eux-mêmes. Vérifiez quand même que l’attribut title est présent sur l’iframe injectée. « Formulaire de paiement sécurisé Stripe » est un bon title.
• Bouton « Commander » avec libellé explicite. Pas « Confirmer », pas « Valider », pas « Payer ». Préférez « Passer la commande » ou « Régler 47,50 € » qui est encore plus clair (l’utilisateur sait ce qu’il s’apprête à faire).
• Erreurs de paiement annoncées. Si la carte est refusée, si le 3D Secure échoue, si l’iframe Stripe renvoie une erreur, ces erreurs doivent être annoncées via role="alert" dans le contenu PrestaShop, pas juste dans l’iframe (que le lecteur d’écran ne traite pas toujours).
• Case CGV avec label clair. C’est le point qui bloque le plus d’utilisateurs aveugles. Le label doit dire exactement ce qui est accepté :

<input type="checkbox" id="cgv" required>
<label for="cgv">
  J'ai lu et j'accepte les
  <a href="/cgv">conditions générales de vente</a>
</label>

Le lien vers les CGV doit être à l’intérieur du label, ou clairement associé.

⚠️ Attention : sur l’étape paiement, vous combinez votre code PrestaShop ET le code des prestataires. Vous êtes responsable de l’accessibilité de votre code, et techniquement vous restez responsable du résultat global même si l’iframe est gérée par Stripe. En pratique, les grands prestataires (Stripe, PayPal, Adyen) sont accessibles. Les petits prestataires régionaux ou des modules obscurs sont à auditer cas par cas.

Étape 5 — Confirmation et email transactionnel

L’étape oubliée par tous les audits, et pourtant critique. C’est ici que l’utilisateur veut savoir : « Ma commande est-elle bien passée ? Quel est mon numéro de commande ? Quand vais-je recevoir mon colis ? »

Fichier à auditer : /themes/classic/templates/checkout/order-confirmation.tpl et tous les emails dans /mails/fr/.

Les checks RGAA prioritaires sur la page de confirmation :

• Numéro de commande dans un titre lisible. Mettez le numéro de commande dans un <h1> ou <h2> accessible. Beaucoup de thèmes le mettent dans un simple <p> ou <span>, ce qui le rend invisible pour la navigation par titres au lecteur d’écran.
• Récapitulatif structuré. Les produits commandés, l’adresse de livraison, le mode de paiement utilisé doivent être présentés dans une structure HTML sémantique (listes, sections clairement identifiées).
• Liens d’action accessibles. « Suivre ma commande », « Retour à l’accueil », « Imprimer la confirmation » doivent être des liens explicites, pas des « Cliquez ici ».
• Annonce vocale du succès. Une zone aria-live="polite" peut annoncer « Votre commande numéro 1234 a bien été enregistrée. Vous recevrez un email de confirmation dans les prochaines minutes. »

Les checks RGAA prioritaires sur les emails transactionnels :

C’est un sujet souvent négligé. Vos emails de confirmation, de suivi de colis, de relance sont aussi soumis à l’accessibilité, parce qu’ils sont des « contenus numériques » au sens de la loi.

• Email avec contenu textuel, pas que des images. Beaucoup de boutiques font de jolis emails « tout image » avec mise en forme graphique. C’est inaccessible : un client malvoyant qui reçoit un email n’a aucun contenu. Il faut un contenu texte structuré, avec les informations clés (numéro de commande, montant, lien de suivi) en HTML, pas en image.
• Lien de suivi de colis accessible. Pas juste un bouton image. Un vrai lien <a> avec un libellé textuel.
• Code promo en texte. Si vous offrez un code de réduction dans un email marketing, il doit être en texte (pour pouvoir être copié-collé), pas dans une image.
• Lien de désabonnement explicite. Obligation RGPD doublée d’une obligation accessibilité.

Sur PrestaShop, les templates d’emails sont dans /mails/fr/ (et les autres langues). C’est un audit à faire séparément du site web.

Et les modules One Page Checkout ?

Beaucoup de marchands PrestaShop utilisent des modules de One Page Checkout (OPC) pour améliorer leur taux de conversion. Les principaux :

Module	Éditeur	Compatibilité	Notes accessibilité
One Page Checkout PS	PresTeamShop	1.7 → 9.x	8 000+ stores, à auditer
The Checkout Module	Prestasmart (Zelarg)	1.7 → 9.x	Mises à jour fréquentes, à auditer
One Page Checkout	Webkul	1.7 → 9.x	À auditer
Easycheckout	Sunnytoo	1.7 → 8.x	Pas d’override files (bonne base technique)

Le constat important : aucun de ces modules ne se positionne explicitement sur l’accessibilité RGAA ou EAA. Ils visent tous la conversion. Quand on les audite, on trouve systématiquement des problèmes :

1. Les radios de transporteurs réinventées en JavaScript (souvent inaccessibles au clavier)
2. Les mises à jour Ajax non annoncées (l’utilisateur ne sait pas que le total a changé)
3. Les messages d’erreur non liés aux champs
4. Le focus management cassé entre les sections de la page

Mon conseil: si vous utilisez un module OPC, testez-le impérativement avec NVDA + Firefox (gratuit) avant de le déployer en production. Si vous constatez que l’expérience clavier ou lecteur d’écran est cassée, contactez l’éditeur pour exiger une version conforme. Si l’éditeur ne répond pas, changez de module ou retournez au tunnel multi-étapes natif.

Au passage : la communauté PrestaShop attend depuis longtemps que la version officielle du tunnel soit nativement plus accessible. L’issue GitHub #38259 ouverte en 2025 spécifiquement sur la conformité EAA reste en attente. Ne comptez pas sur une mise à jour magique.

Ce qu’il faut retenir de ce chapitre

1. Le tunnel est l’angle critique absolu. Si vous ne deviez auditer qu’une seule partie de votre boutique, ce serait celle-là. C’est là que vous perdez vos clients handicapés, et c’est aussi là que les contrôles vont chercher en premier (parce que c’est l’acte d’achat protégé par le Code de la consommation).

2. Les 5 étapes ont chacune leurs spécificités. Identification, adresses, livraison, paiement, confirmation. Chacune a son fichier .tpl, ses checks prioritaires, ses pièges classiques. Pas de copier-coller possible : il faut auditer page par page.

3. Les modules tiers sont souvent le maillon faible. OPC, modules de paiement obscurs, modules d’autocomplétion d’adresse, modules de wishlist : tous sont des risques d’accessibilité. Auditez-les avant de les déployer, et changez-les s’ils dégradent l’expérience.

4. Les emails comptent aussi. N’oubliez pas vos templates d’emails transactionnels. C’est un audit séparé, mais obligatoire.

Le chapitre suivant aborde un sujet sensible : les modules d’accessibilité miracles (les overlays). Ces solutions à 30 € par mois qui promettent de rendre votre site conforme en 5 minutes. On va voir pourquoi elles ne fonctionnent pas, pourquoi elles aggravent même votre risque légal, et pourquoi tous les experts mondiaux sont unanimes contre elles.

Pourquoi les overlays ne sont pas la solution

C’est le chapitre où je vais être le plus tranché. Pas par parti pris, mais parce que sur ce sujet précis, la communauté mondiale de l’accessibilité numérique est dans une convergence rare. Les experts indépendants, les associations de personnes handicapées, les autorités publiques (FTC américaine, Commission européenne, Department of Justice US), tout le monde dit la même chose.

Les overlays d’accessibilité ne fonctionnent pas. Pire : ils peuvent vous exposer juridiquement et dégrader l’expérience de vos utilisateurs handicapés.

Si vous avez déjà installé un de ces modules (AccessiBe, UserWay, FACIL’iti, ou un équivalent), ce chapitre va peut-être vous gêner. Lisez-le quand même. Vous ferez vos choix après.

Qu’est-ce qu’un overlay exactement ?

Un overlay d’accessibilité est un script JavaScript tiers que vous installez sur votre site. Il ajoute généralement deux choses :

• Un bouton flottant (en bas à droite ou à gauche de l’écran), avec une icône représentant le handicap (silhouette dans un cercle, oeil barré, etc.)
• Un panneau de réglages qui s’ouvre quand l’utilisateur clique sur le bouton, et qui propose des options : agrandir le texte, changer les couleurs, activer un mode dyslexie, lire la page à haute voix, naviguer au clavier, etc.

L’argument commercial est simple : « Une seule ligne de code à ajouter sur votre site, et il devient accessible aux personnes handicapées. Conformité WCAG / RGAA / ADA garantie. » MENSONGE !

Ils sont tous bâtis sur le même principe. Et c’est précisément ce principe qui pose problème.

Le panorama des overlays disponibles pour PrestaShop

J’ai cartographié pour vous les principaux modules d’accessibilité disponibles dans l’écosystème PrestaShop. C’est un panorama indicatif, surtout pas une recommandation.

Module	Éditeur	Tarif indicatif	Approche
PrestaShow Accessibility PRO	PrestaShow (Pologne)	Achat unique ~80 €	Overlay configurable
EAA Accessibility Checker Pro	WePresta	Variable	Audit + auto-fix prétendus
DockWCAG	Indépendant	Gratuit	Insertion script overlay
AccessiBe	AccessiBe	49-490 €/mois	Overlay AI
UserWay	UserWay	49-490 €/mois	Overlay configurable
Skynet Technologies All-in-One	Skynet Tech	Variable	Overlay multi-normes
Equally AI	Equally AI	Variable	Overlay AI
AllAccessible	AllAccessible	Variable	Overlay AI

Tous ces modules ont en commun de promettre une mise en conformité « en quelques clics » ou « en une seule ligne de code ». La plupart annoncent une couverture WCAG, RGAA, EAA, ADA, parfois même les normes brésiliennes ou japonaises. Une seule solution qui résoudrait tout, partout, pour tout le monde.

Pour mémoire, le RGAA contient 106 critères dont 70-80 % ne peuvent pas être testés ou corrigés automatiquement. Si une solution prétend couvrir l’intégralité du référentiel via un script JavaScript, elle ment.

💡 Bon à savoir : PrestaShow Accessibility PRO, qui est l’un des modules les plus vendus dans l’écosystème PrestaShop, reconnaît explicitement dans sa propre fiche produit que « le module ne fournit pas une conformité complète et que des modifications programmatiques du template restent nécessaires ». Honnêteté commerciale rare. Le module est honnête, c’est le marketing global de la catégorie qui ne l’est pas.

Le consensus mondial des experts contre les overlays

La communauté mondiale de l’accessibilité numérique est unanime. Pas « majoritairement défavorable ». Unanime.

Voici les positions documentées des grandes voix internationales :

• WebAIM (l’autorité scientifique mondiale, organisation universitaire à but non lucratif). Position : les overlays sont « souvent contre-productifs et peuvent dégrader l’expérience utilisateur réelle ». Leur enquête auprès des utilisateurs de lecteurs d’écran a révélé que 72 % des personnes en situation de handicap trouvent les overlays « pas du tout » ou « pas très » efficaces. Seulement 2,4 % les trouvent « très efficaces ».
• Adrian Roselli (membre de l’ARIA Working Group au W3C). Auteur de la série la plus documentée au monde sur les overlays, avec des titres explicites : « #accessiBe Will Get You Sued », « #FACILiti Will Get You Sued », « #Accesstive Will Get You Sued ». Sa thèse centrale : les overlays ajoutent des erreurs WCAG au lieu d’en enlever, en injectant de l’ARIA mal utilisée qui multiplie les problèmes pour les lecteurs d’écran.
• Karl Groves (auteur du Overlay Fact Sheet). Document fondateur de la position anti-overlay mondiale, signé par plus de 800 professionnels accessibility dans le monde. Le document liste de manière documentée pourquoi les overlays ne fonctionnent pas et pourquoi ils peuvent même nuire.
• Léonie Watson (TetraLogical, Royaume-Uni). L’une des voix les plus respectées au monde, elle-même utilisatrice de lecteur d’écran. Position publique constante contre les overlays.
• Lainey Feingold (avocate américaine spécialisée en accessibilité numérique). Auteure de l’article de référence « Honor the ADA: Avoid Web Accessibility Quick-Fix Overlays ». Sa position : les overlays exposent juridiquement plus qu’ils ne protègent.
• Steve Faulkner (éditeur de la spécification ARIA chez le W3C). Position documentée dans « Bolt-on Accessibility – 5 gears in reverse » : les overlays vont à rebours d’une vraie démarche d’accessibilité.

Côté institutionnel :

• National Federation of the Blind (États-Unis). Résolution officielle de juin 2021 stipulant que les fournisseurs d’overlays font « des affirmations trompeuses, non prouvées et non éthiques ».
• European Disability Forum + International Association of Accessibility Professionals. Déclaration commune publiée en mai 2023 contre les overlays.
• Commission européenne. Guide officiel EAA déclarant les overlays non conformes aux standards européens.
• Department of Justice US. Un représentant officiel a qualifié l’usage d’overlays de « committing legal suicide » (suicide juridique), formule reprise par toutes les ressources spécialisées.
• Federal Trade Commission (FTC). A condamné AccessiBe à 1 million de dollars d’amende en janvier 2025 pour publicité mensongère. On y revient juste après.
• Illinois Department of Innovation & Technology. Recommande officiellement de ne pas utiliser d’overlays sur les sites publics de l’État.

Côté français :

L’écosystème français est aligné sur la position internationale. Aurélien Levy (Temesis), Frédéric Halna (Tanaguru), Sébastien Delorme (Atalan), Romy Duhem-Verdière, Julie Moynat (auteure de l’article fondateur français « Web accessibility overlay tools: lies and gum balls ») : tous publient régulièrement contre les overlays.

Vous remarquerez l’absence dans cette liste de toute voix indépendante en faveur des overlays.

Ce sont UNIQUEMENT leurs éditeurs qui les défendent. Les éditeurs qui gagnent de l’argent en les vendant !

Le cas FTC vs AccessiBe : 1 million de dollars d’amende

Janvier 2025. La Federal Trade Commission, autorité fédérale américaine de la consommation, condamne AccessiBe à payer 1 million de dollars d’amende pour publicité mensongère.

Les motifs documentés dans la décision FTC :

1. Publicité mensongère sur la conformité WCAG/ADA garantie
2. Usage de fausses critiques clients (faux témoignages publiés sur des plateformes d’avis)
3. Photos d’utilisateurs satisfaits identifiées comme générées par IA (via TinEye et UIFaces)
4. Affirmations non prouvées sur l’efficacité de leur technologie « AI-powered »

C’est un précédent juridique majeur. Pour la première fois, une autorité publique nationale sanctionne un éditeur d’overlay pour ses pratiques commerciales.

Ce cas est important pour vous, marchand PrestaShop, à deux titres :

1. Premièrement, il valide les critiques techniques portées depuis des années par la communauté accessibility. Ce n’est plus seulement Adrian Roselli ou WebAIM qui le disent. C’est désormais une autorité fédérale américaine.
2. Deuxièmement, il établit que utiliser un overlay ne vous protège pas juridiquement. Au contraire : si vous vous appuyez sur un overlay pour démontrer votre conformité, et que cet overlay s’avère inefficace, vous restez responsable de l’inaccessibilité de votre site.

Pourquoi les overlays peuvent aggraver votre risque légal

C’est le point le plus contre-intuitif. Vous installez un module pour réduire votre risque, et statistiquement il l’augmente. Pourquoi ?

1. Premier mécanisme : les avocats spécialisés ADA aux États-Unis ont identifié que les sites équipés d’overlays sont des cibles plus faciles. Pour deux raisons. D’une part, le bouton flottant signale visuellement à l’avocat (ou à son outil de détection automatique) que le site « se prétend » accessible alors qu’il ne l’est pas. C’est un point de vulnérabilité juridique. D’autre part, l’utilisateur handicapé qui rencontre des problèmes sur un site équipé d’overlay est encore plus enclin à signaler, parce qu’il s’estime trompé par la promesse affichée.
2. Deuxième mécanisme : les overlays ajoutent des erreurs WCAG au lieu d’en supprimer. WebAIM Million 2025 a mesuré que les pages utilisant ARIA de manière inadéquate (comme le font les overlays par injection automatique) ont 34 % d’erreurs détectées en plus que les pages sans ARIA. Vous installez l’overlay pour réduire vos erreurs, vous en ajoutez en réalité.
3. Troisième mécanisme : les utilisateurs en situation de handicap bloquent eux-mêmes les overlays. Plusieurs extensions navigateur ont été créées par la communauté handicap spécifiquement pour bloquer les scripts d’overlay, parce qu’ils interfèrent avec les technologies d’assistance que les utilisateurs ont déjà configurées. Quand un overlay est bloqué, votre site est aussi inaccessible qu’avant, mais vous avez payé pour l’illusion.

Pourquoi techniquement ça ne fonctionne pas

Au fond, le problème des overlays est structurel. Voici les six raisons techniques principales pour lesquelles ils ne peuvent pas, par construction, garantir l’accessibilité :

1. L’application automatique de texte alternatif est non fiable. L’IA peut deviner « image d’une chemise », mais elle ne peut pas deviner « chemise blanche en lin manches longues, col italien, modèle à porter en intérieur ». Le contexte commercial échappe aux algorithmes.
2. La réparation automatique des labels de formulaire est non fiable. Un overlay qui essaie de deviner ce qu’un champ représente à partir de son contexte HTML va régulièrement se tromper, surtout sur les formulaires complexes du tunnel de commande.
3. La réparation automatique de la navigation au clavier est non fiable. Les comportements clavier dépendent du contexte d’usage, du pattern UI, des attentes de l’utilisateur. Un script générique ne peut pas anticiper tous les cas.
4. Les frameworks JavaScript modernes (React, Vue, Angular) cassent les overlays. Quand le contenu de la page change dynamiquement (ce qui est le cas constant en e-commerce moderne), l’overlay ne peut pas suivre les changements en temps réel sans dégradation de performance majeure.
5. Les overlays ralentissent significativement le chargement de la page. Le script tiers est hébergé sur les serveurs de l’éditeur, ajoute des dizaines de kilo-octets, déclenche des analyses au chargement. Impact direct sur vos Core Web Vitals et votre SEO.
6. Les overlays ne fonctionnent pas sur les contenus non-HTML. PDF, vidéos, images Canvas, SVG complexes : aucune réparation possible.

Ce sont des limites structurelles. Aucun éditeur ne peut les contourner, parce qu’elles tiennent à la nature même de l’accessibilité (qui est une propriété du code source, pas une couche qu’on superpose).

Que faire si vous avez déjà un overlay installé ?

Si vous avez installé un overlay sur votre boutique PrestaShop, voici ma recommandation pratique :

1. Étape 1 — Faites un audit de votre site sans l’overlay. Désactivez temporairement le module et auditez votre site avec axe DevTools, WAVE, et un test au lecteur d’écran. Vous verrez votre niveau de conformité réel.
2. Étape 2 — Faites le même audit avec l’overlay activé. Comparez. Vous verrez probablement que le score est globalement similaire, parfois pire, rarement nettement meilleur. Sur certains points (contraste forcé par exemple), il peut améliorer. Sur d’autres (structure ARIA), il dégrade généralement.
3. Étape 3 — Décidez d’un plan de désinstallation. Si l’overlay coûte 50 € par mois, vous payez 600 € par an pour une protection inexistante voire négative. Cet argent serait mieux investi dans un audit RGAA professionnel et des corrections ciblées.
4. Étape 4 — Communiquez la transition à votre direction. Si vous avez vendu en interne l’overlay comme « mise en conformité », vous allez devoir expliquer pourquoi vous le retirez. Le cas FTC vs AccessiBe est un argument frappant. La position de la Commission européenne aussi.

⚠️ Attention : ne désinstallez pas brutalement un overlay sans avoir un plan de remédiation. Si votre site dépend de l’overlay pour certains aspects de présentation (réglages de contraste sauvegardés par les utilisateurs récurrents, par exemple), vous risquez de générer des plaintes de vos clients. Préparez la transition : audit en parallèle, plan de corrections, communication aux utilisateurs si nécessaire.

Les vraies alternatives

La position « anti-overlay » ne signifie pas « ne rien faire ». Au contraire. Voici ce qui fonctionne réellement :

Audit RGAA professionnel. Un auditeur formé identifie vos non-conformités, les hiérarchise, et produit un rapport actionnable. Tarifs du marché français : 1 400 à 6 900 € HT pour un audit complet selon le prestataire (AccessProd, Eficiens, Access42, Tanaguru, Atalan, Temesis).

Remédiation ciblée des points critiques. Vous traitez en priorité ce qui bloque vraiment les utilisateurs (formulaires, alt text, contraste, navigation clavier). Le reste vient progressivement dans le cadre d’un schéma pluriannuel.

Modules accessibility ciblés (pas overlays). Certains modules apportent une vraie valeur sans prétendre tout résoudre : aide à la rédaction d’alt text dans le back-office, vérification automatique des contrastes lors de la mise en page, alertes de régression. Ce ne sont pas des overlays, ce sont des outils internes pour vos équipes.

Formation de vos équipes. Le coût d’une formation accessibility (1 à 3 jours selon le profil) est inférieur au coût annuel d’un overlay et apporte un bénéfice durable.

Le chapitre 8 reviendra en détail sur les options d’accompagnement.

Ce qu’il faut retenir de ce chapitre

1. Le consensus mondial est sans ambiguïté. Tous les experts indépendants, toutes les associations de personnes handicapées, plusieurs autorités publiques nationales (FTC, DOJ, Commission européenne) déconseillent les overlays.

2. Le précédent FTC vs AccessiBe valide juridiquement la critique. 1 million de dollars d’amende pour publicité mensongère, avec décision documentée. Ce n’est plus une opinion technique, c’est un précédent légal.

3. Statistiquement, les overlays attirent les poursuites au lieu de les éviter. 22,6 % des poursuites US au S1 2025 ciblent des sites équipés d’overlays. Le bouton flottant est un signal de vulnérabilité, pas de protection.

4. La conformité réelle se construit dans le code source. C’est plus long, c’est plus cher, c’est plus exigeant. Mais c’est la seule approche qui fonctionne réellement et qui vous protège juridiquement.

Maintenant qu’on a couvert le périmètre légal, technique, et qu’on a démystifié les fausses solutions, il est temps de passer à un outil pratique. Le chapitre suivant vous donne accès à un simulateur d’audit accessibilité PrestaShop. Vous allez pouvoir évaluer votre boutique sur les 80 points critiques en quelques minutes.

Le simulateur d’audit accessibilité PrestaShop

Maintenant qu’on a posé le cadre légal, parcouru les 13 thématiques techniques, détaillé le tunnel de commande et démystifié les fausses solutions, il est temps de passer à la pratique.

Le simulateur ci-dessous va vous permettre d’évaluer votre boutique PrestaShop sur les 80 points d’audit critiques. C’est une grille de référence basée sur les 13 thématiques officielles du RGAA 4.1.2 et adaptée aux spécificités d’une boutique e-commerce sous PrestaShop.

Comment utiliser ce simulateur

Pour chaque point, vous avez quatre choix possibles, qui correspondent aux quatre statuts officiels du RGAA :

• Oui (Conforme) : le critère est respecté sur l’ensemble de votre boutique
• Partiel : le critère est respecté sur certaines pages ou certains éléments mais pas tous
• Non (Non Conforme) : le critère n’est pas respecté
• N/A (Non Applicable) : votre boutique ne contient pas ce type d’élément

Important à savoir : selon la règle officielle DINUM, un critère partiellement respecté est considéré comme non conforme pour le calcul du taux de conformité. Si vous avez 199 fiches produits avec alt text correct et 1 sans, le critère « alt text des images de produit » est NC pour votre site entier.

Le simulateur calcule trois choses à la fin :

• Votre taux de conformité global estimé (selon la formule officielle critères validés / critères applicables)
• Votre score par thématique (pour identifier vos points faibles prioritaires)
• Une liste de corrections priorisées selon l’impact utilisateur et la facilité de mise en œuvre

À la fin du parcours, vous pourrez exporter les résultats en PDF pour les partager avec votre équipe technique ou votre prestataire.

Important : ce simulateur n’est pas un audit légal

Le simulateur est un outil d’auto-évaluation. Il vous donne une vue d’ensemble de votre situation, vous aide à identifier les points faibles, et structure votre démarche. Mais il ne remplace pas un audit RGAA professionnel réalisé par un auditeur formé, avec test sur lecteurs d’écran réels et grille officielle DINUM.

Si vous voulez publier votre déclaration d’accessibilité légale, vous devez vous appuyer sur un audit conforme à la méthodologie DINUM, pas sur ce simulateur.

Mon conseil pratique : utilisez le simulateur en interne pour comprendre où vous en êtes, lancez les corrections évidentes en autonomie, et faites appel à un auditeur professionnel pour les zones complexes et pour la production de votre déclaration officielle.

Le simulateur

🛠️ 80 questions structurées par les 13 thématiques RGAA

Simulateur d’accessibilité PrestaShop CYBERIAL

Le simulateur s’ouvre en pleine largeur. Comptez 15 à 25 minutes pour le parcourir si vous connaissez bien votre boutique. Si vous découvrez les questions, comptez 30 à 45 minutes (vous aurez peut-être besoin d’aller vérifier certains points sur votre site en parallèle).

Que faire avec votre score ?

Une fois le simulateur terminé, vous aurez un score global. Voici comment l’interpréter :

Moins de 50 % de conformité. Vous êtes en situation « non conforme » au sens officiel. La déclaration d’accessibilité que vous publierez devra mentionner cet état. C’est l’état de la majorité des boutiques PrestaShop aujourd’hui. Pas de panique, mais une prise en main est nécessaire à court terme.

Entre 50 % et 80 % de conformité. Vous êtes en « partiellement conforme ». C’est déjà un effort sérieux. Vos corrections prioritaires sont à identifier dans la grille du simulateur. Avec un plan d’action sur 6 à 12 mois, vous pouvez monter à 90 %+.

Plus de 80 % de conformité. Vous êtes dans le haut du panier français. Pour comparaison : le baromètre accessibilitenumerique.com, qui audite 48 sites e-commerce français de référence, montre que le meilleur du panel (Veepee) plafonne à 78 %. Si vous êtes à 80 %, vous faites mieux que la quasi-totalité du marché. Reste à viser le 100 % pour les pages les plus visibles.

100 % de conformité. Bravo, et félicitations. C’est extrêmement rare en e-commerce. Maintenez le niveau dans le temps, c’est l’autre défi.

Le modèle de déclaration d’accessibilité copier-coller

La déclaration d’accessibilité est un document obligatoire que votre boutique PrestaShop doit publier, indépendamment de votre niveau de conformité réel. Ce point est crucial à comprendre : vous pouvez avoir un site à 30 % de conformité et être en règle administrativement si vous publiez une déclaration honnête. Vous ne pouvez pas être en règle si vous ne publiez aucune déclaration, même si votre site est à 95 %.

Dans ce chapitre, je vais vous donner :

• Les 10 mentions obligatoires officielles selon la DINUM
• Un modèle copier-coller complet que vous pourrez personnaliser et publier
• Les obligations connexes (schéma pluriannuel, plan annuel d’actions)
• Où placer votre déclaration sur PrestaShop
• À quelle fréquence la mettre à jour

C’est un chapitre dense en contenu pratique. Prenez votre temps.

Les 10 mentions obligatoires DINUM

La déclaration d’accessibilité suit un modèle officiel défini par la DINUM. Pour être valide, elle doit contenir les 10 mentions suivantes :

1. L’engagement formel. Une phrase qui engage votre entité à rendre son service accessible, conformément à l’article 47 de la loi du 11 février 2005.

2. Le service concerné. L’URL exacte du site auquel s’applique la déclaration. Si vous avez plusieurs sites (multi-boutique PrestaShop, par exemple), une déclaration par site.

3. L’état de conformité. Un des trois libellés officiels :

• Non conforme : moins de 50 % des critères respectés
• Partiellement conforme : entre 50 % et 99 %
• Totalement conforme : 100 %

4. Les résultats des tests. La formule officielle : « [nn] % des critères du RGAA version 4 sont respectés ».

5. La date d’établissement. Date à laquelle l’audit a été réalisé et la déclaration produite. Doit être mise à jour si vous refaites un audit.

6. La méthodologie utilisée. Audit interne ou externe, version du RGAA appliquée (4.1.2 actuellement), environnement de test (navigateurs et lecteurs d’écran utilisés).

7. Les contenus non accessibles. Liste détaillée des non-conformités identifiées, avec leurs motifs (nature du défaut, raison technique). Les dérogations éventuelles doivent être justifiées.

8. Les coordonnées de contact. Email, formulaire ou adresse postale qui permet à un utilisateur de signaler une difficulté d’accès. C’est un mécanisme de signalement obligatoire.

9. La voie de recours. Mention obligatoire du Défenseur des droits comme recours en cas de non-réponse satisfaisante de votre part. Avec son adresse et son site.

10. Le lien vers le schéma pluriannuel. Lien vers votre schéma pluriannuel d’accessibilité (que je détaille plus bas).

Le modèle de déclaration prêt à utiliser

Voici le modèle complet, découpé en 9 sections logiques. Chaque bloc dispose d’un bouton « Copier » : vous récupérez le texte et vous le collez dans votre éditeur Gutenberg ou Elementor sans toucher à la mise en forme. Les champs entre crochets [...] sont à compléter avec vos données.

Bloc 1 — En-tête et état de conformité

Bloc 2 — Résultats des tests

Bloc 3 — Non-conformités

Bloc 4 — Dérogations et contenus non soumis

Bloc 5 — Établissement de la déclaration

Bloc 6 — Pages auditées

Bloc 7 — Retour d’information et contact

Bloc 8 — Voies de recours

Bloc 9 — Mention de mise à jour

---

Ce modèle est conforme aux exigences DINUM. Il est volontairement long parce qu’il liste tous les éléments obligatoires. Vous pouvez le mettre en page plus joliment, mais ne supprimez aucune section obligatoire.

⚠️ Attention : la rubrique « Contenus non accessibles » est celle où la plupart des marchands trichent. Soit en sous-déclarant (« quelques images sans alt », alors qu’il y en a 200), soit en survolant (« nous travaillons à améliorer l’accessibilité »). Soyez honnête et précis. Une déclaration mensongère est une fragilité juridique : si un utilisateur se plaint de quelque chose qui n’est pas mentionné dans votre déclaration, vous êtes en faute aggravée.

Le schéma pluriannuel d’accessibilité

C’est un document obligatoire complémentaire à la déclaration. Il décrit votre stratégie d’accessibilité sur 3 ans maximum.

Voici la structure type :

1. Engagement et politique générale. Comment l’accessibilité s’intègre dans la stratégie numérique de votre entreprise et dans votre politique RSE.

2. Organisation et gouvernance. Qui pilote l’accessibilité dans votre entreprise ? Quel est le rôle du référent accessibilité (poste obligatoire pour les grandes entreprises, fortement recommandé pour les autres). Quel est le sponsor au niveau de la direction.

3. Ressources affectées. Le budget annuel dédié à l’accessibilité (formation, audit, remédiation, prestations externes). Les équivalents temps plein internes mobilisés.

4. Compétences et recrutement. Comment l’accessibilité est intégrée aux fiches de poste et au processus de recrutement (notamment pour les profils tech, design, contenu).

5. Formation et sensibilisation. Plan de formation des équipes sur 3 ans. Quelles équipes formées (dev, design, marketing, support), à quel niveau, par qui.

6. Recours à des expertises externes. Quels prestataires audit, quels prestataires formation, quelles communautés.

7. Méthodes et outils. Quels outils de test utilisés en continu (axe DevTools intégré au CI/CD, validateurs, lecteurs d’écran). Quels processus internes pour intégrer l’accessibilité dès la conception.

8. Périmètre concerné. Les services numériques couverts par le schéma (votre boutique, vos applications mobiles si applicable, vos emails, vos documents PDF).

9. Recensement des audits prévus. Le calendrier des audits sur les 3 ans, avec les périmètres et les budgets.

10. Communication et concertation. Comment vous communiquez sur l’accessibilité avec vos utilisateurs et avec les associations de personnes handicapées.

Pour une PME, ce schéma peut tenir en 5 à 10 pages. Pour un grand compte, c’est plus volumineux. Le format est libre, mais le contenu doit couvrir les 10 sections.

Le plan annuel d’actions

Le plan annuel décline le schéma pluriannuel pour l’année en cours. C’est plus opérationnel.

Structure type :

Bilan de l’année écoulée. Ce qui a été réalisé, ce qui n’a pas été réalisé et pourquoi.

Tableau des actions de l’année en cours. Pour chaque action :

• Description
• Responsable
• Échéance
• État d’avancement
• Indicateur de succès

Indicateurs de pilotage. Le taux de conformité actuel, le taux cible en fin d’année, le nombre d’audits prévus, le nombre de formations.

Budget alloué. Si possible avec une décomposition par poste (formation, audit, remédiation, outils).

Le plan annuel se met à jour chaque année, idéalement en début d’année.

Où placer ces documents sur votre boutique PrestaShop

L’emplacement des documents est encadré par la réglementation. Voici les bonnes pratiques :

1. Lien dans le footer du site. C’est obligatoire. Le lien doit s’appeler « Accessibilité : [état de conformité] ». Par exemple « Accessibilité : partiellement conforme ». Pas juste « Accessibilité ». L’état de conformité doit apparaître dans l’intitulé du lien.
2. Page CMS dédiée. La déclaration en elle-même doit être sur une page dédiée de votre boutique. Sur PrestaShop, vous pouvez créer cette page via le back-office (Apparence > Pages > Ajouter une nouvelle page). Slug recommandé : /accessibilite/.
3. Schéma pluriannuel et plan annuel sur des pages séparées. Vous pouvez les héberger en PDF accessible, ou en pages CMS dédiées. Slugs recommandés : /accessibilite/schema-pluriannuel/ et /accessibilite/plan-annuel-2026/.
4. Lien depuis la déclaration vers les autres documents. La déclaration d’accessibilité doit pointer explicitement vers le schéma pluriannuel et vers le plan annuel.

💡 Bon à savoir : si vous publiez en PDF, le PDF lui-même doit être accessible (balisé, avec une structure de titres, des alt text sur les images). Un PDF non accessible publié dans une déclaration d’accessibilité est une faute manifeste.

À quelle fréquence mettre à jour

La déclaration d’accessibilité doit être mise à jour :

• Annuellement, même sans changement majeur (mention de l’année en cours, validation de l’état)
• Après chaque audit réalisé sur votre site
• Après toute modification substantielle de la boutique (refonte du thème, changement majeur de modules, mise à jour majeure de PrestaShop)

Le plan annuel d’actions se met à jour chaque année (en début d’année).

Le schéma pluriannuel se révise tous les 3 ans (mais les actions sont actualisées en continu).

Si vous ne mettez jamais à jour, votre déclaration devient obsolète et techniquement non conforme aux exigences réglementaires. Une déclaration de 2025 qui dit « 100 % conforme » et qui n’a pas bougé en 2026 alors que votre site a été refait est plus inquiétante qu’une déclaration honnête à 60 % bien tenue à jour.

Ce qu’il faut retenir de ce chapitre

1. La déclaration est obligatoire, indépendamment du niveau de conformité. Mieux vaut une déclaration honnête à 40 % qu’aucune déclaration. C’est l’absence de déclaration qui sera sanctionnée en premier.

2. Le modèle officiel est exigeant mais clair. Les 10 mentions obligatoires doivent toutes y figurer. Vous ne pouvez pas faire plus court sous prétexte que vous êtes une PME.

3. La déclaration s’accompagne du schéma pluriannuel et du plan annuel. Ces deux documents complémentaires montrent que vous prenez le sujet au sérieux et que vous avez une trajectoire d’amélioration.

4. L’emplacement est encadré. Lien dans le footer avec état de conformité dans l’intitulé. Page CMS dédiée. Liens vers le schéma et le plan.

5. La mise à jour est annuelle au minimum. Une déclaration figée dans le temps perd sa valeur juridique.

Le chapitre suivant et dernier de cet article aborde la question pratique : comment vous faire accompagner. Quelles sont les options possibles, qui sont les acteurs français de référence, et comment on peut travailler ensemble si vous le souhaitez.

Comment se faire accompagner

Vous avez parcouru les 7 chapitres précédents. Vous comprenez maintenant le cadre légal, les sanctions, les 13 thématiques RGAA, le tunnel de commande, les overlays, le simulateur, la déclaration. C’est dense.

La question pratique qui se pose maintenant est simple : par où commencer, et avec qui ?

Dans ce dernier chapitre, je vais vous présenter les options possibles pour avancer, vous donner un panorama de l’écosystème français des spécialistes de l’accessibilité, et vous expliquer comment CYBERIAL peut vous accompagner spécifiquement sur les enjeux PrestaShop.

Soyons clairs sur ma posture : je ne vais pas vous vendre un forfait magique. La mise en conformité accessibilité n’est pas un produit standard. C’est un travail qui demande un audit, des corrections techniques sur le code de votre thème, parfois un changement de modules, et un suivi dans le temps. Le coût se chiffre après diagnostic, pas en barème publié.

Les 4 options qui s’offrent à vous

Pour un marchand PrestaShop confronté à l’enjeu accessibilité, il y a essentiellement quatre options. Aucune n’est universellement bonne ou mauvaise : ça dépend de votre taille, de votre niveau technique interne, de votre budget, et de votre urgence.

Option 1 — Faire l’audit et les corrections en autonomie

C’est viable si vous avez des compétences techniques internes (au moins un développeur PrestaShop expérimenté), du temps à y consacrer (compter 5 à 15 jours-homme pour un audit + corrections de base), et la motivation pour vous former à l’accessibilité.

Les outils gratuits permettent d’aller assez loin (voir section dédiée plus bas). Le simulateur du chapitre 6 vous donne une grille d’autoévaluation. La documentation officielle DINUM est libre d’accès.

Les limites : sans formation accessibility, vous risquez de passer à côté de problèmes importants, de mal interpréter certains critères, et d’avoir une déclaration d’accessibilité qui ne tiendrait pas face à un contrôle. C’est viable pour démarrer, ce n’est pas une fin en soi.

Option 2 — Acheter un overlay (déconseillé)

J’en ai parlé en détail au chapitre 5. Pour résumer : ne le faites pas. Le consensus mondial des experts est sans ambiguïté, et le précédent FTC vs AccessiBe (1 million de dollars d’amende) confirme que ce n’est pas une protection juridique réelle.

Option 3 — Faire appel à un cabinet d’audit RGAA expert

C’est la voie « royale » : vous mandatez un cabinet spécialisé qui réalise un audit complet selon la méthodologie DINUM, produit votre déclaration d’accessibilité officielle, et vous accompagne sur les corrections.

Par contre, ils sont parfois très théorique et n’ont aucune approche technique et aucun conseil intéressant pour votre CMS. C’est normal, ils n’ont jamais mis les mains dans le code de PrestaShop.

Si vous avez le budget, allez-y et appelez nous ensuite ! Sinon, commencez par utiliser notre simulateur d’audit accessibilité pour corriger 90% des recommandations.

Tarifs publics du marché français pour un audit complet (15-20 pages auditées, rapport, déclaration) :

• AccessProd : 1 400 à 4 200 € HT selon le périmètre
• Eficiens : 6 900 € HT pour 10 pages WordPress (équivalent transposable)
• Access42 : sur devis (entre 5 000 et 15 000 € HT selon volume)
• Tanaguru : sur devis (offres SaaS + audit manuel)
• Atalan : sur devis (orienté grands comptes)
• Temesis : sur devis (orienté grands comptes)
• Urbilog : sur devis

À cela s’ajoutent les coûts de remédiation (les corrections techniques sur votre site), généralement assurées par votre prestataire technique habituel ou par le cabinet d’audit lui-même. Le coût des corrections varie énormément selon l’état initial, mais comptez plusieurs jours à plusieurs semaines de développement pour un site PrestaShop standard.

Option 4 — Faire appel à CYBERIAL

C’est notre proposition. Nous ne sommes pas un cabinet d’audit RGAA pur (nous ne nous présentons pas comme tels), mais nous sommes un expert technique PrestaShop qui maîtrise l’audit accessibilité et la remédiation sur cette plateforme spécifique. C’est une différence importante : nous travaillons en profondeur sur le code Smarty, les hooks, les overrides, les modules. Nous identifions les problèmes spécifiquement liés à votre thème, vos modules, votre configuration.

Notre approche : un diagnostic personnalisé selon votre boutique, une proposition de remédiation chiffrée selon les priorités identifiées, et un suivi dans le temps si vous souhaitez. Le coût est fonction du périmètre, pas un forfait standard.

La méthodologie d’audit en 7 étapes

Que vous fassiez l’audit en interne ou que vous le déléguiez, voici la méthodologie qu’on applique chez CYBERIAL et qui correspond aux bonnes pratiques de la profession.

Étape 1 — Constitution de l’échantillon. 15 à 20 pages représentatives de votre boutique : accueil, 2 catégories, 3 fiches produits différentes (simple, déclinaisons, pack), panier, les 5 étapes du tunnel de commande, espace client (création + connexion + commandes), 2 pages CMS (CGV, contact), une page de résultats de recherche, une page 404. C’est l’échantillon recommandé par DINUM pour un e-commerce.

Étape 2 — Audit automatisé. Lancement sur chaque page de l’échantillon des outils axe DevTools, WAVE, Lighthouse. Identification des problèmes détectables automatiquement (alt manquants, contraste insuffisant, labels absents, hiérarchie de titres cassée). Couvre 20 à 30 % des critères RGAA.

Étape 3 — Test au clavier. Parcours de chaque page en n’utilisant que le clavier (Tab, Shift+Tab, Entrée, Espace, Escape, flèches). Vérification que tous les éléments interactifs sont atteignables, activables, et que le focus reste visible.

Étape 4 — Test avec NVDA + Firefox sur Windows. Parcours complet de l’accueil au paiement avec un lecteur d’écran réel. C’est l’étape la plus révélatrice : c’est là qu’on découvre les vrais blocages.

Étape 5 — Test avec VoiceOver + Safari sur iPhone. Parcours mobile complet. L’accessibilité mobile est souvent négligée dans les audits, alors que la majorité des achats se font sur smartphone aujourd’hui.

Étape 6 — Tests manuels complémentaires. Vérification des alt text en termes de pertinence (pas juste de présence), calcul des contrastes sur les zones douteuses, validation de la cohérence des messages d’erreur, vérification de l’ordre de tabulation.

Étape 7 — Calcul du taux et production de la déclaration. Application de la formule officielle (critères validés / critères applicables), production du rapport détaillé avec les non-conformités hiérarchisées, génération de la déclaration d’accessibilité conforme au modèle DINUM.

Compter 3 à 5 jours-homme pour un audit complet sur une boutique PrestaShop standard.

Les outils gratuits indispensables

Si vous démarrez en autonomie, voici les outils que vous pouvez (et devez) installer immédiatement. Tous sont gratuits.

Pour les audits automatisés :

• axe DevTools (Deque) : extension Chrome/Firefox/Edge. La référence mondiale. Couverture la plus complète des critères automatisables.
• WAVE (WebAIM) : extension Chrome/Firefox. Très visuel, idéal pour comprendre rapidement les problèmes.
• Lighthouse : intégré nativement à Chrome DevTools. Section Accessibility. Score global de 0 à 100.
• HeadingsMap : extension Chrome/Firefox. Visualise la hiérarchie de titres de la page.

Pour le test au lecteur d’écran :

• NVDA (Windows, gratuit) : à installer en priorité. À utiliser avec Firefox pour l’audit RGAA officiel.
• VoiceOver (macOS et iOS, intégré) : déjà installé sur votre Mac et votre iPhone. À activer dans les Réglages.
• TalkBack (Android, intégré) : déjà installé sur votre Android.

Pour la vérification de contraste :

• WebAIM Contrast Checker (en ligne) : pour calculer le ratio entre deux couleurs.
• Stark (extension navigateur) : intègre la vérification de contraste dans votre workflow.

Pour la vérification HTML :

• Validateur W3C (en ligne) : valide la conformité HTML de vos pages.

Avec ces outils, vous pouvez réaliser un audit RGAA partiel suffisant pour identifier les principaux problèmes et démarrer les corrections. Pour un audit officiel produisant une déclaration légalement valide, vous aurez besoin d’un auditeur formé (option 3 ou 4).

L’écosystème français de l’accessibilité numérique

L’écosystème français de l’accessibilité est riche et professionnalisé. C’est utile de connaître les acteurs principaux.

Les agences d’audit et conseil :

• Access42 (access42.net) : audit RGAA, formation, conseil stratégique
• Tanaguru (tanaguru.com) : outil d’audit + service expert
• Atalan (atalan.fr) : conseil et formation, AcceDe Web
• Temesis (temesis.com) : qualité et accessibilité web
• Ideance (ideance.net) : agence engagée, blog actif
• Qelios : audit et conseil
• Urbilog : audit et formation
• Abilitis (abilitis.fr) : audit et conseil
• AccessProd (accessprod.com) : audit et accompagnement, tarifs publics

Le mouvement professionnel :

En 2025, a11y France a été créée comme association professionnelle structurant le secteur. Membres fondateurs : Temesis, Tanaguru, Ideance. L’association travaille sur des certifications professionnelles dédiées à l’accessibilité numérique (UX/UI designers, développeurs, chefs de projet). C’est un signal fort que la profession se structure et se professionnalise.

Les associations de personnes handicapées à connaître :

• APF France handicap : référence historique, large action sociale
• Association Valentin Haüy (AVH) et son Certam : pôle accessibilité numérique référent (Manuel Pereira)
• ApiDV : Accompagner, Promouvoir, Intégrer les Déficients Visuels (à l’origine des mises en demeure de juillet 2025)
• Droit Pluriel : collectif de juristes spécialisés handicap
• FAAF (Fédération des Aveugles et Amblyopes de France) : Observatoire de l’accessibilité numérique
• CNCPH (Conseil National Consultatif des Personnes Handicapées) : instance officielle
• BrailleNet : pionnière française

Les autorités publiques :

• DINUM (Direction Interministérielle du Numérique) : éditeur officiel du RGAA
• DGCCRF : autorité de contrôle pour le secteur e-commerce
• ARCOM : autorité de contrôle pour les médias et services audiovisuels
• Défenseur des droits : voie de recours en cas de litige

Mon conseil : que vous travailliez avec CYBERIAL, avec un cabinet spécialisé, ou en autonomie, inscrivez-vous au moins à la newsletter d’un acteur de l’écosystème (Access42, Atalan, Ideance, Tanaguru ont tous des contenus de qualité gratuits). Ça vous tiendra à jour sur les évolutions du référentiel, les nouvelles décisions, les bonnes pratiques émergentes.

Pourquoi CYBERIAL pour votre accessibilité PrestaShop ?

Notre positionnement est précis : nous sommes une agence PrestaShop spécialisée, certifiée Partenaire Expert PrestaShop, qui accompagne 350+ boutiques en France, Belgique et Suisse depuis 8 ans.

L’accessibilité n’est pas notre métier exclusif (nous ne sommes pas Access42 ou Tanaguru), mais c’est un domaine où nous sommes opérationnels parce que nous maîtrisons en profondeur le code PrestaShop. Concrètement, ce que nous savons faire :

1. Audit accessibility ciblé PrestaShop. Nous appliquons la grille RGAA, mais nous savons identifier précisément quels fichiers Smarty modifier, quels hooks utiliser, quels overrides écrire. Nous ne vous renvoyons pas vers « votre développeur » avec un rapport générique.
2. Remédiation technique sur votre thème. Nous corrigeons les non-conformités directement dans votre thème enfant ou via des modules custom, en respectant les bonnes pratiques PrestaShop (pas de modification du core, surcharges propres, compatibilité avec les mises à jour).
3. Audit des modules tiers. Nous testons l’accessibilité de vos modules installés (OPC, paiement, autocomplétion, wishlist, etc.) et nous identifions ceux qui posent problème. Si nécessaire, nous proposons des alternatives ou nous développons des corrections.
4. Production de votre déclaration d’accessibilité. Nous générons votre déclaration conforme au modèle DINUM, avec les non-conformités identifiées et hiérarchisées, prête à publier.
5. Accompagnement dans le temps. Pour les boutiques qui souhaitent un suivi régulier, nous intégrons les vérifications accessibility dans nos prestations de maintenance.

Nos terrains de référence : maintenance PrestaShop, hébergement, dépannage, support, SEO. L’accessibilité s’intègre naturellement à ce périmètre, parce que c’est un travail de fond sur le code et la configuration.

📞 Pour nous contacter :

• Téléphone : 09 72 03 59 17 (du lundi au dimanche)
• Email : via le formulaire de contact sur cyberial.fr

Pour conclure

Vous avez maintenant tous les éléments pour décider. Vous savez :

• Pourquoi vous êtes concerné par l’EAA et le RGAA
• Quelles sanctions vous risquez réellement
• Sur quels critères techniques vous serez évalué
• Quels sont les points critiques de votre tunnel de commande
• Pourquoi les overlays ne sont pas la solution
• Comment évaluer votre boutique avec le simulateur
• Comment produire votre déclaration d’accessibilité officielle
• Quels sont les acteurs vers qui vous tourner

L’accessibilité numérique n’est plus une option en 2026. C’est une obligation légale, et c’est aussi une opportunité commerciale (14,5 millions de Français concernés en France, 87 millions d’Européens). Les boutiques qui prennent le sujet au sérieux maintenant en tireront un avantage compétitif durable. Les autres rattraperont leur retard sous la contrainte, dans des conditions moins favorables.

Pour toute question, nous sommes joignables. Bonne mise en conformité.