Le tunnel d’achat qui perd tout le monde sans afficher une seule erreur

Une boutique en ligne qui plante affiche une erreur. On la voit, on la corrige, on perd une journée. Le cas dangereux n’est pas celui-là. C’est celui où tout fonctionne techniquement, où aucun message d’alerte ne s’affiche, où les journaux du serveur sont propres — et où le client ne peut pas payer. Il n’ouvre pas de ticket. Il ferme l’onglet.

Le cas que j’ai eu chez moi

Autant commencer par le mien, il est plus instructif que n’importe quel exemple inventé.

Pendant un temps, la boutique de ce site a proposé deux moyens de paiement au client : la carte bancaire, via une passerelle qui était hors service, et le « virement bancaire », dont les coordonnées n’avaient jamais été renseignées. Deux portes. Une en panne, une sans serrure.

Aucune erreur PHP. Aucune ligne dans les journaux. La page de paiement s’affichait parfaitement, avec deux options bien présentées. Un client qui arrivait là ne rencontrait pas un problème identifiable : il rencontrait le vide. Il choisissait « virement bancaire », cherchait le RIB, ne le trouvait pas, et partait en se demandant si le site était sérieux.

Un tunnel ne casse pas toujours en faisant du bruit. La panne la plus coûteuse est celle qui ressemble à un fonctionnement normal.

Le plus troublant, avec le recul : cette configuration a duré. Non par négligence sur le sujet du paiement, mais parce qu’elle n’était détectable par aucun des outils censés surveiller un site. Le serveur allait bien, le site répondait vite, aucun formulaire ne renvoyait d’erreur. Tout allait bien, sauf la seule chose qui compte.

Pourquoi les outils de surveillance ne voient rien

Il y a une raison structurelle. Les outils de surveillance vérifient que le système fait ce qu’on lui a demandé. Ils ne vérifient pas que ce qu’on lui a demandé a du sens.

Cinq feux verts, et une boutique qui n’encaisse rien. Aucune de ces vérifications n’est inutile ; aucune ne remplace le fait d’acheter soi-même.

Les cinq pannes silencieuses les plus fréquentes

1. Deux moyens de paiement, dont un cassé

Le plus courant, et le plus paradoxal : c’est souvent l’abondance d’options qui crée la panne. Un site qui propose une seule méthode fonctionnelle vend. Un site qui en propose trois dont deux sont mortes perd les clients qui choisissent mal — et un client sur trois choisira mal.

Le correctif que j’ai mis en place tient en une règle : un seul moyen de paiement actif à la fois, et un réglage unique qui le décide. Toutes les autres passerelles sont masquées au client, même si elles restent activées dans les réglages de la boutique. Deux portes, c’est deux fois plus de chances qu’une soit mauvaise.

2. Le champ de configuration vide

Un moyen de paiement par virement activé sans coordonnées bancaires. Une adresse d’expédition d’e-mails non vérifiée. Un mode de livraison sans zone géographique associée — le grand classique : le client remplit tout, arrive au dernier écran, et lit « aucun mode de livraison disponible ». Il ne comprend pas, il ne peut rien y faire, il part.

Ces champs sont vides parce que rien n’oblige à les remplir. Le système accepte l’activation d’une fonction incomplète, et personne ne le lui reprochera jamais.

3. Les liens morts dans le catalogue

Un produit renommé, une catégorie réorganisée, une fiche supprimée. Les anciennes adresses continuent de circuler : dans un message WhatsApp partagé l’an dernier, dans les résultats de recherche, dans un e-mail de relance. Elles mènent à une page d’erreur.

Un lien partagé dans un groupe ne se rattrape pas. Quand vous changez une adresse, gardez l’ancienne vivante par une redirection — ça coûte une ligne et ça sauve des ventes dont vous n’auriez jamais soupçonné l’existence.

4. L’e-mail qui part mais n’arrive pas

Confirmation de commande, lien de téléchargement, accès à un espace membre. L’envoi est enregistré comme réussi côté serveur, et le message atterrit dans les indésirables. Le client attend, puis écrit pour réclamer — dans le meilleur des cas. Dans le cas fréquent, il demande le remboursement en pensant s’être fait avoir.

Le test : commandez avec une adresse Gmail, une adresse Outlook, et une adresse professionnelle chez un hébergeur mutualisé. Les trois se comportent différemment. Vérifiez le dossier des indésirables sur chacune.

5. Le tunnel qui marche au bureau et pas dehors

Le site est testé sur un grand écran, en wifi, avec un navigateur où l’on est déjà connecté et où les cookies sont acceptés depuis longtemps. Le client, lui, arrive sur un téléphone, en réseau mobile, sans historique, et rencontre d’abord un bandeau de cookies qui recouvre le bouton d’achat.

Un bandeau de consentement mal placé sur mobile est une des pannes silencieuses les plus rentables à corriger, parce qu’elle est invisible depuis n’importe quel poste de travail.

Le protocole de vérification : quinze minutes, une fois par mois

Il n’existe aucun outil qui remplace ceci. C’est ennuyeux et c’est irremplaçable.

1. Achetez votre propre produit, en payant réellement

   Votre carte, votre argent. Vous rembourserez après. Un achat en mode test ne traverse pas la même plomberie qu’un achat réel — c’est justement le principe d’un mode test.

2. Faites-le depuis un téléphone, en réseau mobile

   Pas le wifi du bureau. Pas votre navigateur habituel : une fenêtre privée, sans historique, où le bandeau de cookies apparaîtra comme pour un inconnu.

3. Allez jusqu’à l’accès au produit, pas jusqu’au paiement

   Le paiement n’est pas la fin du tunnel. La fin, c’est le moment où le client a ce qu’il a acheté entre les mains. Tout ce qui se passe après le paiement fait partie du tunnel, et c’est la portion la moins surveillée.

4. Vérifiez les indésirables des trois messageries

   Gmail, Outlook, un hébergeur mutualisé. Un e-mail parti n’est pas un e-mail lu.

5. Refaites-le après chaque mise à jour

   Un site vivant reçoit des mises à jour d’extensions, de thème, de moteur. Chacune peut réinitialiser un réglage. La vérification n’est pas un projet, c’est une habitude.

Ce que révèle une commande sans suite

Un dernier point, moins technique. Quand le paiement se fait par virement annoncé, la commande arrive en attente, et c’est la réception du reçu qui déclenche la livraison. Ce fonctionnement est volontaire : livrer avant d’avoir vu le virement revient à offrir le produit.

Mais il crée une responsabilité nouvelle. Une commande en attente qui reste en attente n’est pas un incident technique : c’est une vente qui a réussi et qui n’a pas été honorée. Personne ne vous alertera. Le client, lui, a payé et attend.

Si votre tunnel comporte une étape manuelle — et beaucoup de tunnels au Maroc en comportent une, pour de bonnes raisons — alors la surveillance de cette étape fait partie du tunnel. Une commande en attente depuis plus de vingt-quatre heures doit vous être signalée, comme le serait une erreur serveur.

Questions fréquentes

La leçon générale

Ce que cette histoire m’a appris ne concerne pas le commerce en ligne. Elle concerne la différence entre « ça marche » et « c’est vérifié ». La première formule décrit une croyance ; la seconde décrit un acte qu’on a posé, à une date, avec un résultat.

C’est la même distinction qui traverse la grille de pré-mortem — sa quatrième question, « est-ce que je peux encaisser demain matin ? », est née exactement de cet épisode. Et c’est aussi celle qui décide de la valeur d’un prix : une offre parfaitement calibrée sur un tunnel en panne vaut zéro.