Imaginez une boutique où tous les tableaux de bord semblent corrects. La page d’accueil est indexée, Lighthouse est vert et le validateur de données structurées n’affiche aucune erreur. Mais au même moment, le prix dans Google Shopping ne correspond pas au prix dans le panier, le tiroir de filtres mobile piège les utilisateurs au clavier et chaque achat est enregistré deux fois.
Rien de tout cela n’apparaît dans un contrôle de santé rapide. C’est parce qu’une boutique en ligne est un système connecté, pas une simple collection de pages. Les données produit alimentent la page, les données structurées et les flux shopping. Les scripts et les balises tierces décident de la vitesse de chargement. Le tunnel de commande transforme l’intérêt en chiffre d’affaires, et l’analytique est censée enregistrer tout le parcours avec exactitude. Quand une partie casse, elle peut discrètement fausser tout le reste.
C’est pourquoi un audit e-commerce utile suit l’acheteur, pas le plan du site. La checklist ci-dessous commence par la découverte de la boutique et se termine par une commande finalisée. Elle vous donnera une liste hiérarchisée de vrais problèmes, chacun avec des preuves, un responsable et un test clair pour savoir quand il est corrigé.
Quand réaliser cet audit, et pourquoi l’ordre compte
Réalisez l’audit complet lorsque vous reprenez un nouveau client e-commerce, après une refonte ou une migration de plateforme, avant un gros effort de croissance, ou lorsqu’un contrôle de routine révèle une régression à l’échelle de la boutique. Prévoyez trois à six heures pour une passe légère, ou un à deux jours pour un audit standard qui teste correctement chaque template important. Les investigations approfondies sur les logs, les flux ou l’analytique nécessitent généralement un temps séparé.
L’ordre est délibéré. Cela n’a aucun sens de juger les frictions de conversion si Google ne peut pas indexer les pages de catégorie, et cela n’a aucun sens de faire confiance au rapport d’entonnoir si la balise d’achat se déclenche deux fois.
Un événement d’achat dupliqué n’est pas la preuve de ventes supplémentaires, et une page produit rapide n’est pas saine si le prix vu par Google diffère du prix dans le panier. C’est pourquoi l’audit avance par étapes. Il commence par la première découverte, puis passe à la vérité des produits, à la vitesse et à l’achat lui-même, et ne se tourne qu’ensuite vers la mesure.
Avant de commencer, rassemblez ce dont vous avez besoin. C’est-à-dire un accès à :
- Search Console,
- Analytics,
- un gestionnaire de balises,
- la source du catalogue ou du flux,
- Merchant Center,
- une liste des changements récents apportés au site.
Étape 1 : Les moteurs de recherche peuvent-ils trouver le catalogue ?
1. Construisez un échantillon qui représente toute la boutique
La plupart des bugs e-commerce se nichent dans les templates partagés et les états de produit inhabituels. Une page d’accueil propre ne vous dit rien des catégories filtrées, de la logique des variantes, des ruptures de stock ou du tunnel de commande. C’est pourquoi vous devez d’abord confirmer que vous testez le site de production en direct, sur le bon marché, la bonne devise et la bonne langue. Choisissez ensuite au moins une URL pour chacun de ces éléments :
- la page d’accueil
- une catégorie prioritaire
- une catégorie plus profonde ou une page de filtre approuvée
- un produit typique
- un produit avec variantes
- un produit en rupture de stock ou arrêté
- une page de résultats de recherche interne, dont une qui ne renvoie aucun résultat
- le panier, le tunnel de commande et la page de confirmation de commande
Ajoutez un exemple délicat ou inhabituel pour tout template qui semble risqué. Votre rapport d’analytique sur les pages d’atterrissage et un export du catalogue vous aideront à choisir.
Vous avez terminé lorsque chaque template important et chaque état du tunnel de commande dispose d’une URL de test nommée, et que tout ce que vous n’avez pas pu tester est marqué « non testé ».
2. Vérifiez l’explorabilité, l’indexation, les canoniques et les sitemaps
Si le chemin d’exploration est cassé, publier plus de produits ne fera que multiplier le nombre d’URL concernées. Les signaux contradictoires rendent aussi les problèmes plus difficiles à diagnostiquer. Les règles robots peuvent dire une chose, tandis que les balises canoniques et le sitemap peuvent dire quelque chose de complètement différent.
Passez en revue le robots.txt, les sitemaps XML, les codes de réponse, les balises meta robots et les en-têtes, les balises canoniques, la pagination et les liens internes. Utilisez l’inspection d’URL dans Search Console pour voir quelle canonique Google a réellement choisie pour vos pages échantillons. Comparez ensuite le sitemap à la réalité. Il doit lister des pages en ligne et indexables qui renvoient un statut 200, pas des redirections, des erreurs, des pages en noindex ou des doublons.
Vous avez terminé lorsque vos pages d’atterrissage prévues renvoient un 200, peuvent être explorées, suivent une politique cohérente de canonique et d’indexation, et apparaissent dans le sitemap. Chaque exclusion significative doit avoir une explication ou un responsable.
3. Suivez les liens : redirections, erreurs et JavaScript
Une boutique peut sembler complète dans un navigateur alors que les crawlers et les technologies d’assistance en voient une version bien plus pauvre. Lancez un crawler pour trouver les liens internes cassés, les chaînes de redirection, les boucles et les faux 404. Comparez ensuite la page rendue avec le HTML brut. Les cartes produit, la pagination, les fils d’Ariane et les liens de catégorie doivent être réels et explorables, et le contenu important ne doit pas dépendre uniquement de JavaScript.
Vous avez terminé lorsque les liens internes pointent directement vers leur destination finale, que les pages d’erreur renvoient le bon code de statut et que les produits prioritaires peuvent être trouvés sans dépendre du défilement infini.
4. Testez les catégories, les filtres, la pagination et la recherche sur le site
Les systèmes de catégories et de filtres peuvent créer des pièges d’exploration pour les moteurs de recherche et de la frustration pour les acheteurs en même temps. Une page peut être techniquement indexable et rester une faible page d’atterrissage si la moitié des produits qu’elle contient ne sont pas pertinents.
Essayez les filtres sur desktop et mobile. Vérifiez la sélection multiple, le bouton « tout effacer », les compteurs de résultats, le tri, la pagination ou le « charger plus », et les combinaisons de filtres qui ne renvoient rien. Regardez les URL que les filtres génèrent et comparez-les à la politique d’indexation de la boutique. Remarquez aussi si un long bloc de texte de catégorie repousse la grille de produits sous la ligne de flottaison.
Vous avez terminé lorsque les contrôles se comportent de manière cohérente, que des combinaisons de filtres aléatoires ne deviennent pas des pages d’atterrissage accidentelles et que les acheteurs peuvent annuler un filtre sans perdre leur place.
Prêt à développer votre entreprise?
Commencez votre essai gratuit aujourd'hui et voyez les résultats en quelques jours.
Étape 2 : Les données produit disent-elles la vérité ?
5. Rapprochez l’identité du produit, le prix, le stock et les variantes
Un seul champ erroné peut non seulement induire un acheteur en erreur, mais aussi aller jusqu’à provoquer une incohérence au moment du paiement. Par ailleurs, les données peuvent être parfaitement formatées et rester fausses.
Pour une poignée de produits représentatifs, comparez le nom, la marque, le SKU, le GTIN ou l’EAN, la variante sélectionnée, le prix, la devise, la disponibilité, les images et les caractéristiques clés partout où ils apparaissent. Vérifiez ce qui est affiché sur la page, dans les données structurées, dans le flux marchand, dans le panier et au moment du paiement. Incluez les articles en promotion, les variantes, les ruptures de stock, les précommandes et les produits arrêtés.
Vous avez terminé lorsque les faits échantillonnés concordent sur toutes les surfaces, et que toute différence intentionnelle, comme la marque par rapport au fabricant, est explicite dans le modèle de données.
6. Validez les données structurées par rapport à ce que voient les acheteurs
Les données structurées n’aident que lorsqu’elles décrivent la page avec exactitude. Un validateur acceptera volontiers « InStock » alors que la page et le tunnel de commande indiquent tous deux que le produit est indisponible. C’est pourquoi vous devez passer chaque état de produit dans le Google Rich Results Test ou le validateur Schema.org. Comparez ensuite les valeurs balisées avec le contenu visible et le flux source. Pour les produits avec variantes, vérifiez que votre approche de balisage et votre configuration canonique correspondent à la façon dont les pages sont réellement construites.
Vous avez terminé lorsque les pages éligibles échantillonnées n’ont aucune propriété requise manquante, que le balisage correspond à ce qui est visible et que les avis et notes ne sont balisés que lorsque les acheteurs peuvent les voir sur ce produit.
Étape 3 : La boutique est-elle rapide pour de vrais acheteurs ?
7. Mesurez d’abord les Core Web Vitals à partir des données de terrain
Les données d’utilisateurs réels et une simple exécution de Lighthouse répondent à des questions différentes. Lighthouse vous aide à reproduire un problème, mais il ne peut pas vous dire si les vrais acheteurs réussissent ou échouent.
Commencez par PageSpeed Insights et le rapport Core Web Vitals dans Search Console. Notez si des données de terrain existent pour l’URL exacte ou seulement pour l’ensemble du site. Les seuils « bons » de Google, mesurés au 75e percentile, sont :
- LCP (chargement) : 2,5 secondes ou moins
- INP (réactivité) : 200 millisecondes ou moins
- CLS (stabilité visuelle) : 0,1 ou moins
Regardez le mobile et le desktop séparément. S’il n’y a pas de données de terrain, enregistrez le résultat comme inconnu et considérez les résultats de laboratoire comme provisoires. Inconnu n’est pas synonyme de vert.
Vous avez terminé lorsque chaque template prioritaire a un verdict de terrain par appareil, ou une absence de données clairement indiquée, avec la source et la plage de dates enregistrées.
8. Trouvez la cause, pas seulement le score
Les conseils génériques comme « compressez vos images » ou « réduisez le JavaScript » passent souvent à côté du vrai goulot d’étranglement et créent un travail qui ne fait pas bouger la métrique en échec. Trouvez l’élément, la requête ou le script spécifique responsable.
Identifiez l’élément LCP et ce qui le retarde. Vérifiez ensuite les suspects habituels, comme le dimensionnement des images, le lazy-loading sur les images au-dessus de la ligne de flottaison, le CSS bloquant le rendu, le chargement des polices, les scripts tiers, les tâches longues, la mise en cache, le temps de réponse du serveur, les sources de décalage de mise en page et les balises chargées deux fois.
Lancez des tests répétés dans les mêmes conditions et comparez une statistique cohérente, pas votre meilleure exécution. Rappelez-vous que le Total Blocking Time est un signal de laboratoire utile, mais que ce n’est pas l’INP.
Vous avez terminé lorsque chaque constat de performance significatif nomme la métrique en échec, le template concerné, une cause reproductible et un responsable.
Rejoignez notre newsletter
Recevez gratuitement les derniers conseils, tendances et offres.
Étape 4 : Les gens peuvent-ils réellement acheter quelque chose ?
9. Testez l’ergonomie mobile et l’accessibilité sur de vrais contrôles d’achat
Les scores automatisés ne couvrent pas toutes les interactions. Une boutique peut réussir un scan alors que le tiroir de filtres piège le focus clavier, que la bannière de cookies recouvre le bouton d’ajout au panier ou que le sélecteur de taille n’a pas de libellé accessible.
Testez à des largeurs de téléphone de 360 à 390 pixels, zoomez le texte et essayez tout le parcours au clavier uniquement. Observez l’ordre de focus et la visibilité dans les menus, tiroirs et boîtes de dialogue. Vérifiez que les libellés, les boutons, les erreurs de formulaire et les cibles tactiles restent compréhensibles.
Vous avez terminé lorsqu’un acheteur peut parcourir le trajet principal sans contrôles cachés ni pièges de focus, et que rien sur mobile ne masque le prix, la disponibilité, le choix de variante, le bouton d’ajout au panier ou le tunnel de commande.
10. Exécutez le panier et le tunnel de commande comme un test contrôlé
Un bouton de commande visible ne prouve pas que le tunnel de commande fonctionne. Les bugs du tunnel de commande sont des incidents commerciaux, et ils fragilisent aussi votre analytique.
Pour tester cela, ajoutez un produit normal et une variante au panier. Modifiez la quantité, supprimez un article et appliquez un code promo (ou un code volontairement invalide) si vous en avez un. Testez ensuite la commande en tant qu’invité et avec un compte, les options de livraison, le choix du paiement, les erreurs de validation, le bouton retour et la mise en page mobile. Utilisez une commande de test ou un parcours approuvé sans facturation. Ne passez jamais une vraie commande sans autorisation.
Vous avez terminé lorsque l’achat se finalise ou atteint la limite de test convenue, que les totaux restent corrects, que les messages d’erreur indiquent aux gens quoi faire, et que tout parcours bloqué est documenté avec des preuves et un impact commercial.
Étape 5 : Mesurez-vous correctement le parcours ?
11. Vérifiez l’analytique, les balises en double et le consentement
Les balises en double gonflent les pages vues, les événements d’ajout au panier et les achats. Des valeurs manquantes ou mal formées rendent les rapports de chiffre d’affaires dangereux comme base de décision. L’objectif est simple : une action d’acheteur doit produire un événement, avec le bon produit, la bonne valeur, la bonne devise, le bon identifiant de transaction et le bon état de consentement.
Listez chaque conteneur de gestionnaire de balises, balise Google, pixel publicitaire, script d’affiliation et intégration côté serveur. Puis, dans une session contrôlée, tracez view_item, add_to_cart, begin_checkout et purchase. Comparez ce que le navigateur envoie avec GA4 DebugView et l’enregistrement de la commande dans le back-end. Testez avant et après que l’acheteur fait un choix de consentement.
Vous avez terminé lorsque chaque action déclenche son événement exactement une fois, que les achats portent un identifiant de transaction stable, que les valeurs et la devise concordent avec le back-end et que les balises non essentielles respectent la politique de consentement.
12. Rapprochez Search Console et Merchant Center de ce que vous avez trouvé
Un test local de page ne peut pas vous montrer chaque canonique indexée, chaque avertissement de sitemap, chaque produit désapprouvé ou chaque requête de recherche perdue. Une alerte de tableau de bord, en revanche, peut décrire un problème déjà corrigé.
Inspectez vos URL prioritaires dans Search Console, examinez les rapports sur les produits et les fiches marchands, et vérifiez les diagnostics de Merchant Center par rapport à ce que vous avez observé sur le site en direct. Notez les dates, car le réexploration et le traitement des flux sont en retard sur les déploiements.
Vous avez terminé lorsque chaque problème significatif d’un tableau de bord correspond à des preuves en direct ou est marqué comme en attente de propagation, et que chaque problème ouvert a un responsable.
Étape 6 : Un acheteur ferait-il confiance à cette boutique ?
13. Vérifiez les signaux de confiance, les coordonnées, la livraison et les retours
Des informations commerciales cachées ou contradictoires font hésiter les acheteurs et augmentent les tickets de support. Comparez l’en-tête et le pied de page, la page de contact, le tunnel de commande et les pages de politique.
Vous avez terminé lorsque l’identité de l’entreprise est claire, que les affirmations sur la livraison, les retours et le paiement concordent tout au long du parcours et qu’aucun badge de confiance n’est invérifiable.
14. Vérifiez le HTTPS, le contenu mixte et l’hygiène front-end
Il ne s’agit pas d’un test d’intrusion, mais d’une question d’hygiène de base des données. Confirmez que le HTTP redirige vers HTTPS en un seul saut, que le certificat est valide, qu’il n’y a pas de contenu mixte et que les formulaires sont soumis correctement. Vérifiez la console pour les erreurs graves. Si quelque chose ressemble à une véritable vulnérabilité de sécurité, transmettez-le à un spécialiste plutôt que de le diagnostiquer à partir d’un avertissement générique.
Vous avez terminé lorsque les pages prioritaires et le tunnel de commande se chargent de manière sécurisée, que les redirections prennent un seul saut et que les formulaires se comportent comme prévu.
Des constats aux corrections
15. Transformez les constats en une file de remédiation avec responsables
Un audit qui se termine par des captures d’écran ou un score ne réduit pas le risque. Cinquante symptômes causés par un seul template cassé ne doivent pas devenir cinquante tickets sans lien. Regroupez les constats par cause racine. Notez s’il s’agit du composant, du template, de la règle de flux ou de la configuration du suivi. Conservez les URL concernées comme preuves. Priorisez ensuite :
- P0 : une défaillance active qui bloque l’activité, ou un problème critique à l’échelle du site
- P1 : un défaut significatif dont vous êtes sûr
- P2 : un problème important à portée limitée
- P3 : une amélioration à surveiller
Vous avez terminé lorsque chaque constat significatif a un responsable, une échéance, un test définissant « corrigé » et une date pour le vérifier à nouveau après la mise en production.
Le livrable
Remettez un document ou un tableur versionné avec une ligne par constat et un court résumé en haut. Chaque ligne doit couvrir :
- Le comportement,
- le comportement attendu,
- les URL concernées,
- les preuves et la date à laquelle vous les avez collectées,
- la gravité et le niveau de confiance,
- la cause probable,
- la correction recommandée,
- le responsable et le test qui prouve que c’est fait.
Mais rappelez-vous que vous ne devez pas marquer un problème comme corrigé parce que quelqu’un a fermé le ticket. Marquez-le comme vérifié lorsque le test passe en production.
Les outils pour le travail
Vous n’avez besoin d’aucun abonnement pour réaliser avec succès une solide première passe. Il vous suffit de ces outils gratuits :
- Google PageSpeed Insights pour les données de terrain (là où elles existent) et les diagnostics Lighthouse
- Google Search Console pour l’indexation, les sitemaps, l’inspection d’URL, les Core Web Vitals et les rapports de données structurées
- Google Rich Results Test et le validateur Schema.org pour les données structurées
- Chrome DevTools et Lighthouse pour le réseau, la performance, les décalages de mise en page, l’accessibilité et les vérifications de la console
- Google Tag Assistant et GA4 DebugView pour le suivi des événements
- SSL Labs Server Test pour la configuration TLS
Si vous souhaitez un raccourci, AmICited vous permettra de rassembler toutes ces preuves et de conserver la référence pour plus tard. La vue Performance Impact compare les templates par LCP, INP, CLS et temps de réponse du serveur. URL Inspection et Sitemaps and Indexing suivent l’indexation des URL prioritaires. Products et Assortment montrent quelles parties du catalogue pèsent le plus commercialement. Les annotations dans le Reports Hub relient chaque mise en production à ce qui s’est passé ensuite. Les outils fournissent les preuves. Le propriétaire de la boutique, le développeur ou l’analyste décide toujours de ce qui est correct et des compromis acceptables.
Après l’audit
Envoyez chaque problème confirmé vers le workflow spécialisé capable de le clôturer : les problèmes d’exploration et de rendu à un audit SEO technique , les échecs de performance de terrain à la remédiation des Core Web Vitals , les problèmes de facettes et d’état de stock à une revue des catégories et des produits , et les problèmes de suivi à la personne responsable de l’analytique.
Il n’est pas nécessaire de relancer tout l’audit après chaque correction. Retestez la zone concernée, annotez la mise en production pour voir ce qui a changé ensuite, et laissez le contrôle de santé régulier détecter la prochaine régression.
Retour à la boutique où tout semblait correct
Vous souvenez-vous de la boutique du début ? Sa page d’accueil était indexée, Lighthouse était vert et le validateur était propre. Pourtant, Google Shopping affichait le mauvais prix, le tiroir de filtres piégeait les utilisateurs au clavier et chaque vente était comptée deux fois.
Aucun tableau de bord n’a signalé quoi que ce soit. Cette checklist aurait attrapé les trois : l’incohérence de prix à l’étape 5, le piège de focus à l’étape 9 et l’achat compté deux fois à l’étape 11. Chacun casse quelque part le long du parcours de l’acheteur, et c’est exactement là que l’audit regarde.
Voilà ce que vous apporte le fait de suivre l’acheteur plutôt que le plan du site. Vous cessez de demander « le site semble-t-il sain ? » et commencez à poser quatre questions plus difficiles. Les gens peuvent-ils trouver le produit ? Ce que la boutique dit à son sujet est-il vrai ? Peuvent-ils réellement l’acheter ? Et pouvez-vous voir qu’ils l’ont fait ? Une boutique qui peut répondre oui aux quatre est en meilleure forme qu’une boutique au score parfait.
Alors choisissez vos URL d’échantillon, bloquez le temps nécessaire et commencez par l’étape 1. La première passe est la plus lente. Ensuite, le travail consiste surtout à s’assurer que ce que vous avez corrigé reste corrigé.
