Son tunnel de vente était cassé et il ne pouvait pas le voir

Le client m'a appelé parce que ses ventes étaient à zéro depuis plusieurs jours. Pour lui, c'était incompréhensible : il avait ouvert son site le matin même, tout fonctionnait, il avait même refait le parcours d'achat en entier.

C'est exactement là que se trouvait le problème.

Il voyait un site qui marche, ses clients voyaient une page morte

La page de commande s'affichait blanche pour tous les visiteurs. Pas une erreur, pas un message : une page vide.

Lui ne l'a jamais vue. Il était connecté en administrateur, et les réglages de cache excluent systématiquement les utilisateurs connectés. Il recevait donc une version du site différente de celle servie à tout le monde. Son parcours de test fonctionnait parfaitement, pendant que personne ne pouvait acheter.

C'est le genre de panne qui peut durer des semaines. Rien n'alerte. Le site est en ligne, il répond, il est joli. Seul le chiffre d'affaires s'arrête, et on met du temps à faire le lien.

Depuis, la première chose que je fais sur n'importe quel site, c'est de l'ouvrir en navigation privée. Trente secondes, et on voit ce que voient les clients.

Trois causes empilées, découvertes une par une

Je pensais trouver un problème. J'en ai trouvé trois, superposés, dont chacun suffisait à casser la vente.

Le premier : les boutons ne mettaient rien dans le panier. Les appels à l'action envoyaient bien vers la page de commande, mais sans le paramètre qui ajoute le produit. Le visiteur arrivait donc sur une commande vide. Le lien avait l'air correct, il menait à la bonne adresse, et il ne servait à rien.

Le deuxième : une erreur JavaScript fatale. Un plugin de suivi publicitaire levait une erreur qui interrompait le rendu de la page. Tout ce qui devait s'afficher après ce point ne s'affichait plus. C'est le mécanisme le plus traître : un seul script qui échoue, et la page entière s'arrête, sans message.

Le troisième : le contenu avait perdu ses métadonnées. Lors d'une duplication du site, la page avait été copiée mais pas les données que le constructeur de page utilise pour savoir quoi afficher. Le contenu existait en base, il n'était simplement plus rendu.

Ce qui rend ce type de panne difficile, c'est justement l'empilement. On corrige la première cause, on teste, la page reste blanche, et on croit s'être trompé. Il faut aller au bout des trois.

Et un quatrième coupable, sur le même site

Une fois la page réparée, elle a recassé. Cette fois, la cause venait d'un plugin d'optimisation : l'agrégation et le report du JavaScript cassaient la page de commande.

C'est un cas classique. Ces outils regroupent les scripts pour accélérer le site, ce qui fonctionne très bien sur des pages ordinaires. La page de commande, elle, est la plus fragile de tout un site marchand : elle fait cohabiter le paiement, la gestion du panier et des scripts sensibles à l'ordre d'exécution. Les toucher casse.

Le diagnostic a pris trente secondes : il suffit d'ajouter le paramètre de désactivation de l'outil à l'adresse de la page. Si la page revient, le coupable est identifié. C'est le premier réflexe à avoir quand une page casse après une optimisation.

Ce que j'en retiens, et ce que vous pouvez faire ce soir

Testez votre site déconnecté. Navigation privée, ou un autre navigateur. C'est le seul moyen de voir ce que voient vos clients. Faites-le après chaque mise à jour, chaque installation d'extension, chaque intervention.

Allez au bout du parcours. Pas seulement la page d'accueil : ajoutez au panier, allez jusqu'à la page de paiement. C'est là que ça casse, et c'est la seule page dont la panne coûte directement de l'argent.

Ouvrez la console de votre navigateur. Une erreur en rouge sur une page de commande n'est jamais anodine. Vous n'avez pas besoin de la comprendre, il suffit de la signaler.

Méfiez-vous des optimisations sur les pages sensibles. La plupart des outils permettent d'exclure certaines pages du traitement. Panier et commande devraient toujours en faire partie.

Questions fréquentes

Pourquoi le cache exclut-il les utilisateurs connectés ?

Parce qu'un utilisateur connecté voit des contenus personnalisés qu'il ne faut surtout pas servir aux autres. C'est un réglage sain. L'effet de bord, c'est que le gérant d'un site ne voit jamais la version publique s'il reste connecté.

Comment savoir qu'une page est cassée sans la surveiller en permanence ?

Le signal le plus fiable reste vos ventes. Une chute brutale sans explication doit déclencher un test du parcours complet, déconnecté, avant toute autre hypothèse. C'est plus rapide que de chercher du côté du marketing.

Faut-il désinstaller les plugins de suivi publicitaire ?

Non, mais il faut vérifier leur effet sur les pages de paiement après chaque mise à jour. Une extension qui fonctionnait hier peut lever une erreur demain, en particulier quand elle dépend d'un service externe.

En résumé

Ce site avait l'air de fonctionner et ne vendait rien. Le gérant ne pouvait pas s'en rendre compte, parce qu'il testait connecté en administrateur, sur une version du site que ses clients ne recevaient jamais.

Trois causes empilées, puis une quatrième après réparation. La leçon tient en une phrase : votre site, vous devez le voir comme vos clients le voient, pas comme votre navigateur vous le montre.

Si vous voulez un regard extérieur sur le vôtre, notre audit gratuit vous donne un score en trente secondes. Le premier appel de trente minutes est gratuit.