Une refonte doit pouvoir faire deux choses à la fois : exprimer l’identité de votre marque et permettre d’acheter sans difficulté. Le bon arbitrage n’oppose donc pas un site spectaculaire à un site dépouillé. Il consiste à décider ce qui aide le client, à vérifier que chaque fonction tient sa promesse et à savoir comment revenir en arrière lorsqu’un changement pose problème.
Ce guide propose une méthode de recette : autrement dit, une façon de vérifier le site avant son ouverture. Elle relie les pages, les interactions et le traitement de la commande. Les scénarios proposés sont des exemples de travail à adapter à votre boutique, pas les résultats d’un audit réalisé par RichCommerce. Ils ne promettent ni hausse de conversion ni score technique garanti.
1. Ne pas valider seulement une façade
Pour juger une maquette, on regarde un écran. Pour juger une boutique, il faut essayer d’accomplir quelque chose : trouver le bon produit, comprendre une option, comparer deux références ou corriger une adresse avant de payer.
Avant de discuter d’une animation ou d’un nouveau menu, écrivez la tâche que cet élément doit faciliter. Une vidéo de démonstration peut répondre à une question que la photographie ne résout pas. Un zoom peut rendre un détail inspectable. Un univers visuel peut donner de la cohérence à une collection. Mais ces choix doivent aussi laisser le prix, les variantes et l’action d’achat accessibles.
Notre proposition d’arbitrage : pour chaque composant important, préciser son utilité, la gêne qu’il pourrait introduire et le scénario qui permettra de le vérifier. Une rubrique éditoriale n’a pas besoin d’être supprimée parce qu’elle n’est pas transactionnelle ; elle doit rester reliée au reste du parcours.
Un exemple historique, sans en faire un audit actuel
Dans une analyse de Dior.com publiée en octobre 2011, Charles Le Prévost décrit des difficultés de navigation, des contrôles peu visibles et des fonctions inopérantes. Son article cite un billet de l’ancien RichCommerce et un avis différent de Web&luxe. Il note aussi que le bouton « précédent » du navigateur fonctionne bien : il ne faut donc pas transformer son témoignage en condamnation de toutes les interactions du site.1
Ce cas invite à tester l’usage au-delà des captures. Il ne prouve ni la façon dont le projet avait été validé en interne, ni une perte de chiffre d’affaires, ni l’état actuel du site Dior. Le projet RichCommerce d’aujourd’hui ne s’attribue pas cet audit historique.
2. Sécuriser quatre moments du parcours d’achat
Les situations suivantes constituent notre proposition de recette. Choisissez des produits, des règles commerciales et des appareils représentatifs de votre activité ; consignez ce que vous avez réellement testé plutôt que d’affirmer que « tout fonctionne ».
Le visiteur peut entrer à n’importe quel moment, par exemple directement sur une fiche produit depuis un lien externe.
-
L’arrivée
Voir le produit et comprendre les choix proposés.
- Prix, navigation et ajout au panier restent visibles.
- Traceurs : avant choix, après refus, après retrait.
-
L’exploration
Comparer sans perdre sa sélection.
- Filtre, tri, recherche, cas sans résultat.
- Clavier et fenêtres modales.
-
La fiche produit
Décider avec la bonne information.
- Variante, prix, disponibilité, livraison.
- Une indisponibilité annoncée par un libellé, pas seulement grisée.
-
Le panier et le paiement
Gérer aussi les échecs.
- Remises, adresses, quantités devenues indisponibles.
- Paiement refusé, interruption, nouvelle tentative.
Les retours en arrière à vérifier aussi
- De la fiche à la liste : retrouver le filtre et une position cohérente.
- Après un passage au panier : l’état affiché n’est pas périmé.
- Après un refus ou une interruption : reprendre sans commande ni débit en double.
Schéma établi d’après la section 2 de ce guide. Le parcours n’est pas une ligne droite : les retours font partie de la recette.
2.1 L’arrivée : voir le produit et comprendre les choix proposés
Commencez par une arrivée directe sur une fiche produit, pas seulement par l’accueil. Observez ce qui prend la place du prix, de la navigation et de l’ajout au panier. Vérifiez ensuite la même page après acceptation ou refus des traceurs concernés, avec et sans ouverture des sollicitations commerciales prévues.
En France, le consentement préalable dépend des traceurs et de leurs finalités : certains sont soumis à consentement, d’autres en sont exemptés. La CNIL prévoit aussi la possibilité d’accepter, de refuser et de retirer son consentement. Il ne faut donc pas présenter un bandeau comme une obligation uniforme de tous les sites européens.2
Exemple de test. Sur un téléphone, ouvrir une fiche depuis un lien externe. Lorsqu’un dispositif de consentement est nécessaire, vérifier le comportement des traceurs avant choix, après refus et après retrait. Examiner séparément la lisibilité des options et leur effet technique : fermer la fenêtre ne suffit pas à démontrer que le choix est respecté. Le protocole et les exemptions applicables restent à valider selon votre situation.
Pour les fenêtres promotionnelles et les widgets, notre recommandation est d’éviter les superpositions qui masquent une action importante. L’objectif n’est pas une règle universelle « une seule fenêtre par session », mais un parcours compréhensible, contrôlable et testable.
2.2 L’exploration : comparer sans perdre sa sélection
Choisissez un parcours concret : sélectionner une catégorie, activer un filtre, trier les résultats, ouvrir un produit puis revenir à la liste. Ajoutez un passage par la recherche interne et un cas sans résultat. Notez l’état que l’utilisateur doit retrouver après chaque retour.
Exemple de test. Dans une collection de chaussures, sélectionner la pointure 42, ouvrir une paire puis utiliser le bouton « précédent ». Notre résultat attendu est de retrouver le filtre et une position cohérente dans la liste, sans devoir reconstruire sa sélection. Refaire le test après avoir modifié la quantité au panier, en vérifiant que l’état affiché n’est pas périmé.
La mémoire des filtres et le cache réseau ne sont pas la même chose. Les règles de cache peuvent imposer une revalidation ou un nouveau chargement légitime. L’absence totale de requêtes réseau n’est donc pas un critère universel de réussite.3 Pour ce guide, le critère fonctionnel est la continuité du parcours ; l’analyse technique sert ensuite à comprendre les rechargements inutiles ou les données obsolètes.
Testez également les interactions au clavier. Pour une fenêtre modale, le modèle W3C prévoit notamment un focus placé à l’intérieur à l’ouverture, une navigation par tabulation contenue dans la fenêtre, une fermeture par Échap et un retour du focus vers le déclencheur, sauf exception justifiée par le parcours.4 Ce comportement doit être vérifié, pas déduit de la présence d’un bouton de fermeture.
2.3 La fiche produit : décider avec la bonne information
Préparez un petit ensemble de fiches représentant les difficultés de votre catalogue : article simple, produit à variantes, combinaison indisponible, personnalisation obligatoire et éventuelle précommande. Pour chacune, écrivez les informations que l’acheteur doit connaître avant de s’engager.
Nous recommandons de contrôler ensemble le titre, la variante choisie, le prix, la disponibilité, les conditions de livraison et les informations utiles au choix. Un champ présent dans l’administration ne garantit pas qu’il soit compréhensible dans la page : la recette doit regarder ce qui est effectivement rendu.
Exemple de test. Sélectionner une couleur disponible puis une taille épuisée. L’interface doit annoncer la situation sans ambiguïté et proposer uniquement les actions prévues pour ce cas. La couleur grisée, seule, n’est pas notre critère de validation : il faut un libellé ou une information accessible. Lorsque l’inventaire peut évoluer, vérifier aussi le refus propre au moment de la validation.
Pour les médias, demandez ce que chaque image ou vidéo apporte. Nous proposons de conserver les contenus utiles, puis d’adapter leur poids et leur chargement. Pour une image identifiée comme élément LCP, la documentation web.dev déconseille le chargement différé et décrit l’usage d’une priorité élevée. Cela ne signifie pas que toutes les images d’un premier écran doivent recevoir la même priorité.5
2.4 Le panier et le paiement : gérer aussi les échecs
La recette ne s’arrête pas à un bouton « payer » visible. Construisez des paniers qui exercent les règles commerciales réellement utilisées : plusieurs catégories d’articles, remise compatible ou incompatible, adresse hors zone desservie, quantité devenue indisponible.
Exemple de test. Saisir un code promotionnel expiré puis corriger une adresse incomplète. Notre résultat attendu est un message utile, associé à la bonne saisie, sans effacement injustifié des autres informations. Vérifier que le total reste cohérent et qu’une attente est signalée, plutôt que de demander un clic « instantané » alors qu’un traitement est en cours.
Ajoutez un paiement refusé, une interruption au retour du prestataire et une nouvelle tentative. Recherchez une commande ou un débit en double, puis contrôlez les confirmations, le stock et le statut de commande. Ces scénarios sont des propositions de recette : leur simulation dépend des fonctions de test de votre prestataire.
Sur Shopify, la documentation prévoit des commandes simulées avec une passerelle ou un mode de test, ainsi qu’un essai réel suivi d’annulation et de remboursement. Ce dernier peut entraîner des frais ; le mode de test empêche les commandes réelles pendant son activation.6 Choisissez donc un protocole adapté à l’environnement, sans rendre un achat payé obligatoire pour chaque contrôle ni activer un mode de test sur une boutique ouverte sans précaution.
3. Mesurer et utiliser l’IA sans leur faire dire plus qu’elles ne savent
3.1 Un score de laboratoire ne décrit pas tout le parcours
Lighthouse produit des audits dans des conditions définies. Sa documentation souligne la variabilité des scores : comparer deux nombres sans connaître les conditions de mesure peut conduire à une mauvaise conclusion.7 Pour votre recette, conservez les rapports, la version de l’outil, la page, la configuration et l’état testé. Notre recommandation est de comparer des mesures répétées dans des conditions comparables.
Un audit de navigation ne constitue pas une commande complète. Mais il serait également faux d’affirmer que Lighthouse est incapable de tester autre chose qu’une page froide : ses parcours programmés permettent d’inclure des interactions, des chargements avec cache et différents modes de mesure.8 Le rapport doit préciser lequel a été utilisé.
CrUX agrège des données d’expérience Chrome sur une fenêtre de 28 jours. L’API est actualisée quotidiennement et expose notamment des distributions et des percentiles. Les 28 jours ne sont donc pas un délai fixe pendant lequel une régression resterait invisible. Après une bascule, la fenêtre peut contenir des observations de l’ancienne et de la nouvelle version ; elle ne permet pas de prédire à elle seule la date d’un changement dans Search Console.9
Notre méthode de suivi : vérifier les parcours dès l’ouverture, suivre les erreurs et les mesures disponibles, puis examiner les tendances sur une période cohérente. En l’absence de données terrain exploitables pour le périmètre étudié, noter cette limite. Un bon résultat technique ne démontre pas une hausse de conversion ; pour parler de ventes, il faut des données marchandes et une analyse adaptée.
Test de laboratoire
Ce qu’il éclaire
Des audits dans des conditions définies : page, configuration, version de l’outil. Des parcours programmés peuvent inclure des interactions et des chargements avec cache.
Ce qu’il ne permet pas de conclure
Deux scores ne se comparent pas sans leurs conditions de mesure. Un audit de navigation ne constitue pas une commande complète.
Données de terrain
Par exemple CrUX9
Ce qu’elles éclairent
L’expérience de visiteurs Chrome, agrégée sur 28 jours, actualisée chaque jour, avec distributions et percentiles.
Ce qu’elles ne permettent pas de conclure
Les 28 jours ne sont pas un délai fixe pendant lequel une régression resterait invisible. Seules, ces données ne prédisent pas la date d’un changement dans Search Console. Après une bascule, la fenêtre peut mêler ancienne et nouvelle version.
Recette du parcours
Les douze contrôles de ce guide
Ce qu’elle éclaire
Si, sur cette version et dans les conditions vérifiées, un client peut choisir, commander et recevoir une confirmation correcte, y compris quand le parcours échoue.
Ce qu’elle ne permet pas de conclure
Elle ne démontre pas une hausse de conversion : pour parler de ventes, il faut des données marchandes et une analyse adaptée.
Schéma établi d’après la section 3.1 et la conclusion de ce guide. Chaque lecture éclaire une partie du parcours, avec les limites décrites dans le texte.
3.2 L’assistant peut aider à modifier ; la recette vérifie le résultat
Le périmètre des assistants varie selon la plateforme, les fonctions disponibles et les autorisations. Shopify documente ainsi des interactions de Sidekick avec les applications tierces compatibles, après approbation. Dans Canvas, lorsqu’une boutique y a accès, il peut aussi construire des blocs absents du thème ou remanier des modèles. Une interdiction générale d’agir sur les outils tiers ou de créer de tels composants serait inexacte.10
Pour notre méthode, l’enjeu n’est pas d’opposer l’IA à l’humain, mais de garder une modification identifiable et réversible. Nous recommandons de demander ce qui a changé, d’enregistrer la version testée et de rejouer les scénarios touchés. Une réponse convaincante de l’assistant n’est pas un résultat d’exécution.
De même, une erreur réseau n’est pas un diagnostic complet. Les statuts HTTP 403 et 404 ne disent pas si une application est encore installée, facturée ou utile.11 Shopify indique que du code peut subsister après une désinstallation et que certaines facturations externes nécessitent une résiliation séparée.12 Il faut vérifier l’origine de l’appel, le rôle du composant, ses dépendances et la facturation avant de décider d’un retrait. La recette ne doit pas devenir une suppression de code à l’aveugle.
4. La grille pratique : douze contrôles, avec un résultat vérifiable
Cette grille est une méthode proposée par RichCommerce, pas une norme ni une certification. Adaptez les scénarios à votre boutique. Pour chaque ligne, conservez la version, l’environnement, le résultat et l’anomalie éventuelle. « Non applicable » doit être justifié ; « non testé » ne doit pas devenir « conforme ».
| Contrôle | Scénario à exécuter | Résultat attendu dans notre méthode |
|---|---|---|
| 1. Arrivée et sollicitations | Ouvrir directement l’accueil, une catégorie et un produit sur mobile. Déclencher les sollicitations prévues. | Prix, navigation et action principale restent accessibles ; aucun écran intermédiaire inutile n’empêche d’avancer. |
| 2. Consentement, si applicable | Tester absence de choix, acceptation, refus et retrait ; contrôler le comportement des traceurs concernés. | Le choix affiché et son effet technique sont cohérents avec les règles applicables. Une fenêtre fermée ne suffit pas comme preuve.2 |
| 3. Navigation et retour arrière | Filtrer, trier, ouvrir un produit et revenir. Faire une recherche sans résultat. | La sélection reste compréhensible ; le visiteur retrouve un état cohérent et dispose d’une issue lorsqu’aucun résultat ne convient. |
| 4. Clavier et fenêtres | Parcourir menu, filtres, variantes et panier sans souris ; ouvrir et fermer une modale. | Les fonctions essentielles sont utilisables, le focus visible et son déplacement cohérent, notamment à la fermeture.4 |
| 5. Lisibilité et stabilité | Examiner les pages et leurs états sur des écrans différents, avec zoom et pendant le chargement. | Aucun texte ou contrôle important n’est perdu ; les changements de mise en page ne détournent pas une action. Les contrôles de contraste restent à mesurer séparément. |
| 6. Information et variantes | Tester produit simple, options, rupture et personnalisation obligatoire. | Prix, variante et disponibilité correspondent à la sélection ; erreurs et états indisponibles sont explicitement annoncés. |
| 7. Médias et contenu riche | Charger, ouvrir et fermer zoom, vidéo, guide ou contenu éditorial ; revenir au produit. | Le contenu aide à comprendre sans faire perdre la navigation. Les chargements observés correspondent aux besoins et aux règles de cache, pas à un objectif aveugle de zéro requête. |
| 8. Panier et calculs | Combiner articles, quantités, remises, adresses et livraisons représentatives. | Les montants et restrictions correspondent aux règles attendues ; les délais de traitement ont un état visible et les commandes restent actionnables. |
| 9. Erreurs et reprise | Saisir une erreur, simuler un refus de paiement et reprendre après interruption. | L’utilisateur comprend comment continuer ; ses données utiles ne sont pas perdues et aucune double commande ou double opération inattendue n’est constatée. |
| 10. Confirmation de commande | Réaliser le protocole de commande de test prévu, puis contrôler les systèmes concernés. | Statuts, stock, notification et traitement correspondent au scénario. Un essai réel éventuel reste distinct, contrôlé et autorisé.6 |
| 11. Réseau et dépendances | Examiner les appels en échec et les composants changés ; comparer leurs rôles et dépendances. | Chaque anomalie significative est expliquée ou prise en charge ; aucun retrait n’est décidé sur le seul code HTTP ou la seule absence d’usage pendant un test.11, 12 |
| 12. Bascule et retour arrière | Identifier la version à publier, la procédure de restauration, le responsable et les contrôles après ouverture. | Le retour arrière a été vérifié dans le périmètre concerné ; les commandes nouvelles et données persistantes ne sont pas écrasées par une restauration improvisée. |
Décider du lancement sans confondre tous les défauts
Nous proposons de classer les écarts en trois catégories. Un défaut qui empêche l’achat, fausse un montant ou compromet des données bloque le parcours concerné. Une dégradation mesurable demande un arbitrage documenté sur son impact et sa correction. Une préférence graphique ne mérite pas automatiquement le même arrêt qu’un paiement défaillant.
Un exemple : un zoom décoratif imparfait n’a pas le même effet qu’une variante impossible à commander au clavier. Inversement, une fonction présentée comme secondaire peut être indispensable à certains utilisateurs. La décision doit porter sur le parcours et ses utilisateurs, pas seulement sur le nom du composant.
Le suivi commence dès la bascule : refaire les scénarios essentiels, vérifier le traitement des premières commandes avec les droits nécessaires et comparer les erreurs à la situation précédente. Prévoir ensuite une revue des tendances. J+28 peut être un rendez-vous de suivi, mais pas une raison d’attendre avant de réagir ni une date garantissant un verdict SEO.
Conclusion : une refonte réussie tient sa promesse d’usage
Une identité visuelle forte et un parcours fiable peuvent faire partie du même projet. Pour les réconcilier, demandez à l’équipe de montrer une tâche réussie, pas seulement un écran réussi.
Retenez quatre principes : partir des décisions que le client doit prendre ; tester les cas d’erreur autant que le parcours idéal ; interpréter chaque mesure dans son périmètre ; préparer la continuité et le retour arrière avant d’ouvrir.
Le livrable de recette utile n’est pas une longue série de cases vertes. C’est une réponse précise à cette question : sur cette version, dans les conditions vérifiées, un client peut-il choisir, commander et recevoir une confirmation correcte — et savons-nous quoi faire lorsque le parcours échoue ?