Un client m'appelle un lundi matin, panique dans la voix. Son site e-commerce affiche des ventes correctes, mais son taux de conversion s'est effondré de 3,1 % à 1,8 % en six semaines. Personne ne sait pourquoi. Ni lui, ni son agence, ni le développeur qui a livré la refonte du tunnel de commande. Je passe deux jours à creuser. Le coupable : un script de tracking tiers bloqué par le consentement, qui gelait le rendu de la page panier pendant 2,4 secondes sur mobile. Rien de spectaculaire. Aucun rapport d'erreur. Juste un audit technique complet pour site e-commerce qui n'avait jamais été fait.
C'est toujours ça, la vraie raison pour laquelle on commande un audit. Pas pour cocher des cases, mais parce qu'un chiffre ne colle plus et qu'on ne comprend pas pourquoi. Et dans le commerce en ligne, un problème technique invisible coûte de l'argent toutes les heures.
Points clés à retenir
- Un audit technique e-commerce réussi se juge sur les seuils chiffrés qu'il fixe, pas sur le nombre de pages de son rapport.
- Les Core Web Vitals (LCP, INP, CLS) sont un point de départ, pas une fin : un site rapide peut très bien perdre des commandes.
- Le crawl, le rendu JavaScript et la gestion des facettes d'URL sont les angles morts les plus fréquents.
- Le livrable doit être un backlog priorisé par impact et effort, pas une liste de 200 problèmes.
- Chaque plateforme a ses pièges : Shopify, WooCommerce et PrestaShop n'échouent jamais de la même façon.
- Sans indicateurs de suivi post-audit, votre audit sera périmé dans trois mois.
Un audit technique complet pour site e-commerce commence par un périmètre, pas par des outils
La plupart des prestataires vous envoient une checklist. Technique, SEO, UX, sécurité, performance. C'est propre, c'est rassurant, et dans 80 % des cas ça ne sert à rien, parce que personne n'a défini ce qu'on cherchait avant d'ouvrir les outils.
Un audit commence par une question économique. Qu'est-ce qui vous coûte de l'argent aujourd'hui ? Un panier abandonné sur mobile ? Un trafic organique qui stagne malgré de nouveaux articles ? Un pic de charge qui fait tomber le site pendant les soldes ? La réponse détermine quels axes on creuse à fond et lesquels on survole.
Quels axes prioriser selon votre situation
Voici comment je répartis l'effort, en pourcentage du temps total d'audit :
- Performance et Core Web Vitals — 30 % du temps si votre trafic est majoritairement mobile.
- Crawl et indexation — 25 % dès que le catalogue dépasse quelques centaines de références, ou que vous gérez des variantes et des filtres.
- Tunnel de commande et paiement — 25 %, systématiquement. C'est là que l'argent se perd.
- Sécurité et conformité des données clients — 10 %, ou plus si vous stockez des moyens de paiement.
- Dette technique et maintenabilité — le reste, variable selon l'âge du projet.
Ce découpage n'est pas une vérité révélée. C'est un point de départ à ajuster. Sur une boutique de cosmétiques avec 400 produits et un trafic Instagram, je vais passer beaucoup plus de temps sur la vitesse mobile que sur le crawl. À l'inverse, un revendeur de pièces auto avec 60 000 références verra ses problèmes d'indexation avant tout le reste.
Les seuils chiffrés qu'on ne vous donne presque jamais
C'est l'information qui manque partout. Un audit sans seuil n'est pas un audit, c'est une opinion. Les cibles que j'utilise et que je vous conseille d'exiger :
| Indicateur | Cible à viser | Seuil d'alerte |
|---|---|---|
| LCP (affichage du plus gros élément) | moins de 2,5 s | au-delà de 4 s sur mobile |
| INP (réactivité aux interactions) | moins de 200 ms | au-delà de 500 ms |
| CLS (stabilité visuelle) | moins de 0,1 | au-delà de 0,25 |
| Poids de la page produit | moins de 1,5 Mo | au-delà de 4 Mo |
| Requêtes HTTP au premier rendu | moins de 50 | au-delà de 120 |
Ces valeurs viennent des seuils publics de Google pour les Core Web Vitals, que je complète par ce que je constate sur le terrain. Le poids de page et le nombre de requêtes, personne ne les encadre officiellement, et pourtant ce sont souvent eux qui plombent tout le reste.
Les axes techniques que tout le monde oublie
Les liens brisés, les images non compressées, les balises méta manquantes : tous les rapports les listent. Ils représentent rarement plus de 5 % du problème réel.
Le crawl et la gestion des facettes d'URL
Une boutique avec filtres de couleur, taille et prix peut générer des dizaines de milliers d'URL uniques. Si vous n'avez pas de règles claires sur les paramètres d'URL, les robots d'indexation passent des semaines à explorer des combinaisons de filtres sans intérêt. Pendant ce temps, vos vraies pages produit attendent.
Ce que je vérifie concrètement : le contenu du robots.txt, la présence d'un sitemap à jour et segmenté, la gestion des paramètres par canonical, et le comportement des facettes qui renvoient un code 200 alors qu'elles devraient être en noindex. Sur une boutique que j'ai auditée, le sitemap produits contenait 12 000 URL dont 4 000 en 404. Le crawl budget partait directement à la poubelle.
Le rendu JavaScript
Si votre site est en headless ou en composable commerce, le contenu est souvent injecté côté client. Résultat : les robots voient une page vide, ou une version dégradée. Je teste toujours en désactivant JavaScript. Si la page produit ne montre ni le prix, ni le titre, ni la disponibilité, vous avez un problème d'indexation que rien d'autre ne compensera.
Le test le plus rapide et le plus révélateur : ouvrez votre fiche produit la plus vendue dans un navigateur avec JavaScript coupé. Ce que vous voyez, c'est ce que voient les robots.
Le maillage interne et les redirections
Un maillage interne mal pensé enterre vos pages les plus rentables. Je regarde combien de clics séparent la page d'accueil d'une fiche produit, et si les pages catégories pointent vers les produits à forte marge ou vers les derniers ajoutés. Dans la majorité des cas, la réponse est : vers les derniers ajoutés, sans aucune logique commerciale.
Les redirections, elles, accumulent de la dette silencieuse. Chaque refonte de site en crée. Un an plus tard, vous avez des chaînes de trois redirections 301 qui pointent vers une page qui n'existe plus.
Les Core Web Vitals suffisent-ils à garantir la performance d'une boutique ?
Non, et c'est une erreur que j'ai commise moi-même au début. Pendant des mois, j'ai optimisé des scores jusqu'à obtenir des LCP sous les 2,5 secondes, persuadé que les ventes suivraient. Elles n'ont pas toujours suivi.
Le problème, c'est que les Core Web Vitals mesurent la vitesse perçue par le navigateur, pas l'expérience réelle d'achat. Un site peut afficher son LCP en 2 secondes et bloquer complètement le bouton « Ajouter au panier » pendant trois secondes de plus à cause d'un script tiers. Les métriques sont vertes. Le client, lui, est parti.
Ce que j'ajoute systématiquement dans mes audits :
- Le temps réel entre le clic sur « Ajouter au panier » et la mise à jour visible du panier.
- Le comportement du tunnel de paiement sur une connexion 4G dégradée.
- Le poids des scripts tiers (tracking, chat, avis clients) et leur impact sur le fil principal d'exécution.
- La tenue du site sous une charge simulée proche d'un pic de soldes.
Sur une boutique de vêtements que j'ai suivie, la suppression d'un seul script de personnalisation a fait remonter le taux de conversion de 1,9 % à 2,7 % en un mois. Aucun changement visuel. Uniquement du temps de réactivité récupéré.
À quoi doit ressembler le livrable d'un audit technique e-commerce
Un rapport de 150 pages ne sert à rien. Personne ne le lit, et encore moins ne l'applique. Je livre désormais un document de dix à quinze pages maximum, structuré autour d'une matrice de criticité.
La matrice impact / effort
Chaque problème détecté est positionné sur deux axes : l'impact estimé sur le chiffre d'affaires, et l'effort de correction. Quatre catégories en sortent :
- Quick wins — impact fort, effort faible. À traiter dans les deux semaines.
- Chantiers structurants — impact fort, effort élevé. À planifier sur le trimestre.
- Améliorations mineures — impact faible, effort faible. À glisser dans le flux de maintenance.
- À ignorer — impact faible, effort élevé. Oui, on écrit noir sur blanc ce qu'il ne faut pas faire.
Cette dernière catégorie est la plus utile. Elle vous évite de dépenser 8 000 euros sur une refonte de composant qui ne changera rien à vos ventes.
Les indicateurs de suivi post-audit
Un audit sans plan de suivi est un document mort. Je fixe toujours trois ou quatre indicateurs à surveiller, avec une fréquence de mesure et une valeur cible. Par exemple : LCP mobile sous 2,5 s d'ici six semaines, taux d'abandon panier sous 65 %, temps de réponse du tunnel de paiement sous 800 ms.
Sans ces repères, vous ne saurez jamais si les corrections ont produit un effet, ou si une amélioration vient simplement d'une campagne marketing réussie.
Shopify, WooCommerce, PrestaShop : les pièges ne sont pas les mêmes
On m'a souvent demandé si un audit technique se déroule de la même façon selon la plateforme. La méthode, oui. Les points de friction, non. Voici ce que je constate le plus souvent :
| Plateforme | Faiblesse récurrente | Point de vigilance |
|---|---|---|
| Shopify | Accumulation d'applications tierces | Chaque app ajoute des scripts ; le poids grimpe vite |
| WooCommerce | Extensions mal codées ou abandonnées | Les requêtes base de données explosent avec le catalogue |
| PrestaShop | Thèmes lourds et modules non optimisés | Le cache doit être configuré finement, sinon rien ne change |
| Headless / composable | Rendu côté client | Sans rendu serveur, l'indexation des produits souffre |
Sur Shopify, la question centrale est toujours la même : combien d'applications tournent, et lesquelles bloquent le rendu ? J'ai vu des boutiques avec 14 apps actives, dont 9 injectant du JavaScript dans l'en-tête. Le site était correct sur desktop et catastrophique sur mobile.
Sur WooCommerce, c'est la base de données qui souffre. Une boutique avec 5 000 produits et des dizaines d'extensions mal écrites peut mettre trois secondes à répondre à une simple requête de catégorie.
Trois erreurs que j'ai commises en auditant
La première : livrer un rapport exhaustif sans hiérarchie. Le client a fixé les 30 problèmes faciles, ignoré les 3 qui comptaient vraiment, et conclu que l'audit ne servait à rien.
La deuxième : auditer sans accès aux données réelles. Analyser un site sans regarder ses entonnoirs de conversion, c'est deviner. Depuis, je refuse tout audit où je n'ai pas accès aux statistiques de trafic et aux données de vente.
La troisième, la plus bête : mesurer une seule fois. Un site e-commerce change chaque semaine, entre les mises à jour, les nouvelles apps et les campagnes. Une mesure unique est une photographie d'un instant qui n'existe déjà plus.
Ce qui reste après l'audit
Le vrai bénéfice d'un audit technique complet pour site e-commerce n'est pas la liste de problèmes qu'il produit. C'est la capacité qu'il vous donne à savoir, dans six mois, pourquoi un chiffre bouge. Parce que votre site bougera, et vous n'aurez pas toujours quelqu'un sous la main pour identifier le script qui a fait basculer le taux de conversion de 3 % à 2 %.
Un audit bien fait vous laisse trois choses : des seuils précis, un backlog qualifié, et une méthode pour mesurer. Le reste, franchement, c'est du remplissage.
