Audit EAA d’un e-commerce : cadrer le service et les parcours

Mis à jour le 1er octobre 2026 · Rédaction : Plein Accès

Définir le service vendu au consommateur

Un audit d’accessibilité e-commerce doit suivre ce que le client essaie de faire, au-delà de la page d’accueil. Il recherche un produit, compare les variantes, vérifie une information, choisit une livraison et confirme sa commande. Une difficulté dans une seule de ces étapes peut empêcher l’achat. Décrivez donc les actions principales avant de choisir les pages à tester. Les interfaces du compte client et du service après-vente méritent aussi une place dans l’inventaire lorsqu’elles font partie du service proposé.

Le champ EAA se vérifie à partir du service et de l’organisation responsable. Le guide RGAA et EAA traite cette qualification, notamment la distinction avec le seuil de l’article 47. Ici, l’objectif est de préparer le travail technique et la coordination des équipes. Les sources DGCCRF liées à cette page permettent de rapprocher les parcours du cadre applicable, sans transformer un audit web en certificat général du service.

Inventorier les familles de pages et les états

Commencez par les catégories, les résultats de recherche et les fiches produits. Une liste de produits peut changer après un filtre ou un tri. Une fiche peut proposer une taille indisponible, une promotion ou une combinaison de variantes. Il faut permettre à l’auditeur de rencontrer ces états plutôt que de lui fournir uniquement les exemples les plus simples. Choisissez des données fictives ou des produits de test qui déclenchent les interactions pertinentes.

Ajoutez le panier, les moyens de livraison, les étapes de commande et les messages de confirmation. Prévoyez un résultat vide, une erreur de saisie et un incident de paiement simulé. Si le site utilise plusieurs langues ou plusieurs présentations de commande, notez les différences qui affectent les composants. Un modèle de page partagé peut réduire le travail répétitif, mais il ne prouve pas que tous les contenus ni toutes les variantes sont utilisables.

Tester la compréhension et la progression

L’audit doit examiner comment un client repère le produit et comprend les informations utiles à son choix. Les variantes ne devraient pas dépendre seulement d’une couleur ou d’une image sans explication. Les commandes de tri et de filtre doivent être identifiables, et leurs résultats doivent rester compréhensibles après actualisation. Demandez au prestataire d’expliquer les tests retenus et de fournir les conditions nécessaires à leur reproduction.

Pour la progression, observez la navigation au clavier, les annonces d’état et le traitement des erreurs. Une action « ajouter au panier » doit être suivie d’une information que le client peut percevoir. Un refus de validation doit orienter vers le champ concerné sans effacer les données utiles. Le guide du tunnel d’achat détaille la recette jusqu’au paiement ; il évite de réduire ce parcours à quelques captures de formulaires.

Répartir les responsabilités de correction

Le thème, les modules et les contenus appartiennent parfois à des interlocuteurs différents. Identifiez le propriétaire de chaque élément avant de lancer la remédiation. L’équipe éditoriale peut corriger une alternative d’image, tandis qu’un développeur doit modifier la restitution d’un sélecteur. Un module de paiement peut exiger une demande à son fournisseur. Le rapport doit permettre de distinguer ces causes afin que les tâches atteignent la bonne personne.

Demandez une matrice de responsabilité dans l’offre : qui propose le correctif, qui l’intègre, qui le déploie et qui le vérifie ? Pour les boutiques Shopify, PrestaShop et WooCommerce, les limites techniques ne sont pas identiques. Le candidat doit annoncer celles qu’il a constatées, sans garantir à l’avance qu’il pourra modifier tous les écrans de votre service.

Préparer les preuves et la maintenance

Un dossier exploitable relie le service examiné, la version de la boutique et les résultats des tests. Conservez les scénarios, la liste des composants et les corrections acceptées. Pour les interactions dépendantes d’un fournisseur, gardez la demande transmise et l’état du traitement. Ces pièces permettent de savoir ce qui a effectivement changé lors du contre-audit. Elles servent aussi à préparer les informations de conformité dont votre organisation doit examiner la publication.

La boutique évolue après le projet : nouveau module, nouvelle campagne ou modification de la commande. Intégrez des contrôles dans la recette des mises à jour. Une équipe peut commencer par les parcours qui risquent de bloquer une action, puis élargir la vérification selon son inventaire. Le plan de maintenance doit prévoir les contenus autant que le code ; un thème corrigé ne protège pas une nouvelle vidéo ou un tableau produit mal structuré.

Questions sur la boutique

Peut-on auditer sans effectuer de commande réelle ?

Oui, si une recette ou un dispositif de simulation permet d’atteindre les étapes pertinentes. Documentez les limites lorsque l’état final n’est pas accessible dans cet environnement.

Le paiement tiers est-il à exclure du parcours ?

Il faut le repérer et examiner l’expérience de passage. Une limite d’accès au code n’enlève pas automatiquement le besoin de vérifier le parcours ni d’interroger le fournisseur.

Un thème annoncé accessible garantit-il la boutique ?

Non. Les personnalisations, les modules et les contenus peuvent modifier le résultat. L’évaluation doit porter sur votre service effectivement configuré et sur les états retenus.

Sources vérifiées le 1er octobre 2026

DGCCRF : information officielle