Les 7 parcours critiques à tester absolument sur un site e-commerce

On a accompagné des dizaines de sites e-commerce, du DTC à 50 k€/mois au marketplace à 2 M€/mois. Le constat est constant : 80% du chiffre d'affaires passe par 7 parcours. Voici lesquels, comment les tester et quels signaux surveiller.

1. Comment prioriser les parcours à tester

Une matrice simple, à appliquer à chaque parcours candidat :

• Impact CA - combien d'euros par jour passent par ce parcours ?
• Visibilité d'un échec - le bug est-il bloquant pour l'utilisateur, ou silencieux ?
• Probabilité de régression - le code change-t-il souvent ? Les dépendances sont-elles externes (paiement, livraison) ?
• Coût d'instrumentation - le test est-il facile à écrire et à maintenir ?

Les parcours qui combinent fort impact, échec silencieux et forte probabilité de régression sont vos priorités absolues.

2. Parcours #1 : le checkout invité (sans création de compte)

Le parcours qui transforme. Sur la majorité des sites, 40 à 70% des conversions passent par un checkout invité. Si une étape casse, vous perdez la vente sans savoir pourquoi.

Ce qu'il faut tester :

1. Page produit → ajout au panier → vue panier → checkout.
2. Saisie des informations de livraison (adresse, ville, code postal valides ET invalides).
3. Choix du mode de livraison (calcul des frais, délais).
4. Saisie des informations de paiement.
5. Validation de la commande.
6. Page de confirmation avec numéro de commande affiché.

3. Parcours #2 : le paiement (par moyen de paiement)

Le paiement est le parcours le plus critique et le plus dépendant de tiers (Stripe, Adyen, PayPal, Apple Pay). Une simple mise à jour de la lib SDK peut casser silencieusement.

Stratégie de test :

• Un test par moyen de paiement actif (CB, Apple Pay, PayPal, Bancontact, etc.).
• Utilisez les cartes de test fournies par votre PSP (Stripe, Adyen ont des numéros dédiés).
• Testez le 3D Secure (étape d'authentification, redirection back).
• Testez les échecs intentionnels : carte expirée, fonds insuffisants, code refusé.

Exemple Playwright avec Stripe en test mode :

// 4242 4242 4242 4242 = carte Stripe de test "always succeeds"
await page.frameLocator('iframe[name^="__privateStripeFrame"]')
  .getByPlaceholder("Card number").fill("4242424242424242");
await page.getByTestId("submit-payment").click();
await expect(page).toHaveURL(/\/order\/confirmed/);

4. Parcours #3 : la création de compte

Souvent négligé parce que "moins fréquent que le checkout", mais critique pour le LTV (lifetime value). Un signup cassé bloque la fidélisation.

Couvrez :

• Le formulaire avec validation côté front (email, mot de passe).
• L'unicité de l'email (essayer de créer le même compte deux fois → message d'erreur clair).
• Le mail de confirmation reçu (testable via un service comme MailHog ou un mailbox de test).
• Le clic sur le lien de confirmation → activation du compte.
• La connexion juste après l'activation.

5. Parcours #4 : la recherche produit

Si la recherche est cassée ou retourne du vide, le visiteur quitte. Or les outils de recherche sont souvent externalisés (Algolia, Elastic) et donc soumis à des pannes ou des changements d'API.

Tests à mettre en place :

• Recherche d'un produit qui existe → résultats affichés.
• Recherche d'un produit qui n'existe pas → message "aucun résultat" propre, pas d'erreur 500.
• Filtres latéraux (catégorie, prix, marque) → la liste se met à jour.
• Tri (prix croissant / décroissant, popularité, nouveautés).
• Pagination ou scroll infini.

6. Parcours #5 : l'ajout au panier (et les variants produits)

Bug classique : un produit avec variantes (taille, couleur) où la sélection ne se met pas à jour correctement. Le client ajoute "T-shirt M" mais reçoit "T-shirt L". SAV en pagaille.

Tests à écrire :

• Sélection de variantes → le prix et la disponibilité se mettent à jour.
• Ajout au panier d'une variante précise → la variante apparaît dans le panier (pas le défaut).
• Modification de quantité depuis le panier.
• Suppression d'un produit du panier.
• Cas du produit en rupture → l'ajout est bloqué avec message clair.

7. Parcours #6 : les codes promo et offres

Un code promo qui ne s'applique plus = une campagne marketing qui flop, des clients en colère sur les réseaux sociaux, et beaucoup d'argent perdu en SAV.

Tests indispensables :

• Application d'un code promo valide → réduction visible immédiatement.
• Application d'un code expiré ou invalide → message d'erreur clair, pas de plantage.
• Conditions d'application (montant minimum, catégorie spécifique).
• Cumul de plusieurs codes (selon votre politique).
• Affichage final dans le récap commande et dans le mail de confirmation.

8. Parcours #7 : la confirmation par email

Souvent oublié dans les tests automatisés parce qu'il sort du périmètre du site. Pourtant, un mail de confirmation qui ne part pas, c'est un client qui appelle le SAV et qui annule sa carte par méfiance.

Comment tester :

• Connectez votre suite à une boîte mail de test (Mailtrap, MailHog, ou un alias dédié).
• Après chaque commande de test, vérifiez la réception du mail dans les 60 secondes.
• Vérifiez que le contenu contient les éléments clés : numéro de commande, total, articles, lien de suivi.

Exemple de pattern Playwright :

// Apres avoir passe une commande...
const orderId = await page.getByTestId("order-id").textContent();
const mail = await waitForEmail({ to: "qa+order@prod-watch.com", timeout: 60000 });
expect(mail.subject).toContain("Confirmation de votre commande");
expect(mail.body).toContain(orderId!);

9. Bonus : tout tester aussi sur mobile

En 2026, 60 à 75% du trafic e-commerce vient du mobile. Et pourtant, la majorité des suites E2E ne testent que le desktop.

Avec Playwright, c'est trivial :

// playwright.config.ts
projects: [
  { name: "desktop", use: { ...devices["Desktop Chrome"] } },
  { name: "iphone", use: { ...devices["iPhone 14"] } },
  { name: "android", use: { ...devices["Pixel 7"] } },
]

Vos tests tournent automatiquement sur les trois projets. Au minimum, le checkout et le paiement doivent être couverts en mobile.