E-commerce
28 juin 2026
Refonte live. Le design est plus moderne, le menu repensé, le panier allégé. Dans la même semaine, le support reçoit : « Je ne trouve plus vos chaussettes », « Où est passé mon compte client ? », « Le bouton payer ne répond plus sur Safari ».
Noibu rappelle que les régressions silencieuses post-refonte (checkout cassé, scripts tiers, lenteur templates) érodent la conversion des semaines avant d'apparaître dans un rapport mensuel (Noibu, monitoring replatforming 2026).
Ce guide #171 couvre le support client post-refonte e-commerce : surveiller bugs, questions et friction via les tickets. Aucun contenu Qstomy ne reliait refonte UX et SAV. Distinct de migration Shopify (#170) (changement plateforme) : ici, l'angle est redesign, navigation et parcours acheteur.
Sommaire
Pourquoi une refonte e-commerce surprend-elle l'équipe support ?
La refonte est validée en comité design et SEO. Le support découvre les conséquences au premier pic de tickets, souvent sans brief ni taxonomie dédiée.
Chocs typiques semaine 1
Navigation : catégories renommées, produits « disparus »
Compte client : nouveau parcours login, reset confus
Panier / checkout : bouton inactif, promo mal placée
Mobile : menu hamburger, filtres, sticky CTA
Contenu : infos livraison déplacées, PDP allégée
Le support comme capteur de friction
LogRocket documente une refonte formulaire où les tickets n'étaient pas des bugs techniques mais de la confusion : « Je ne comprends pas quoi choisir ». Après rebuild centré inbox support, le volume tickets liés au formulaire a chuté de plus de 95 % (LogRocket, refonte formulaire 2025). Vos agents voient la friction que les heatmaps ne nomment pas.
En quoi diffère-t-il du support migration plateforme ?
Le guide #170 traite replatforming Shopify : comptes, historique, macros MIG-*. Ce guide #171 traite le redesign visuel et fonctionnel sur une boutique déjà en place.
Périmètre post-refonte UX
Taxonomie tickets `redesign_*`
Hypercare navigation et découverte produit
Boucle tickets → patch PDP / menu
Corrélation bugs JS et escalade tech
Monitoring friction 60 jours post-lancement
Compléments internes
Voir support page panier (#159), taxonomie tickets (#107), conversations → PDP.
Quels signaux tickets révèlent une friction post-refonte ?
Les signaux support post-refonte se lisent dans la nature des questions, pas seulement le volume.
Cinq familles d'intents redesign
NAV-* : « où trouver X », « catégorie disparue »
PDP-* : « plus d'infos livraison », « contenu du kit flou »
CART-* : promo, regroupement lignes, modification quantité
CHK-* : paiement bloqué, adresse, erreur silencieuse
ACC-* : login, historique, suivi commande
Indices qualitatifs
Enertex avait 83 % de demandes support sur des questions basiques que le site ne répondait plus après refonte : délais livraison, bénéfices produit, filtres shop (Enertex, refonte e-commerce). Si vos tickets passent de WISMO à « comment acheter », le problème est UX, pas logistique.
Règle des 48 h
Comparez top 10 intents J0-J+2 vs baseline 30 jours avant go-live. Tout intent NAV-* ou PDP-* ×2 ou plus = alerte merchandising immédiate.
Comment structurer le tagging tickets redesign ?
Sans tags cohérents, vous noyez les signaux refonte dans le bruit habituel.
Arborescence Gorgias / Zendesk
redesign_nav : menu, recherche, filtres, breadcrumbs
redesign_pdp : contenu manquant, visuels, sélecteur variantes
redesign_cart : drawer, codes promo, upsell
redesign_checkout : paiement, shipping, erreur technique
redesign_account : espace client, commandes, adresses
redesign_bug : comportement cassé confirmé tech
Champs obligatoires ticket redesign
URL page concernée, device (mobile/desktop), navigateur si CHK-*, capture écran client. Macro agent REDESIGN-INTAKE : 4 questions avant réponse longue. Export hebdo pivot tag × URL × device.
Baseline avant go-live
Noibu recommande 30 à 60 jours de baseline avant changement majeur pour distinguer régression réelle du bruit saisonnier (Noibu, baseline monitoring 2026). Exportez la même période l'année N-1 si refonte saisonnière.
Comment organiser l'hypercare de J0 à J+30 ?
L'hypercare post-refonte dure 30 à 60 jours : c'est la fenêtre où les régressions silencieuses se cumulent.
Organisation J0-J+7
Slack #redesign-support : UX + SAV + dev front
Point daily 15 min : top 5 tags, 3 URLs chaudes
Owner support redesign nommé (pas « tout le monde »)
FRT cible CHK-* : < 30 min, escalade tech immédiate
Macros REDESIGN-* publiées avant go-live
J+8 à J+30
Revue hebdo : tickets redesign / total tickets. Objectif J+14 : part redesign < 15 %. Objectif J+30 : retour baseline + corpus bot stabilisé. Patchs UX priorisés par fréquence ticket, pas par opinion interne.
Tableau Notion hypercare
Colonnes : date, volume redesign, top tag, bugs ouverts, pages patchées, CSAT segment redesign. Une ligne par daily suffit.
Comment relier tickets support aux bugs UX et checkout ?
Le support détecte ; la tech corrige. Le lien entre les deux doit être formalisé.
Workflow escalade bug
Agent tague
redesign_bug+ URL + device + navigateurTemplate Jira/Linear : steps to reproduce depuis verbatim client
Dev confirme ou infirme sous 4 h ouvrées en hypercare
Fix déployé → macro REDESIGN-FIXED envoyée aux clients en attente
Post-mortem si CHK-* > 10 tickets même bug
Signaux techniques à croiser
Noibu liste les erreurs post-release les plus léthales : iframe paiement, JS checkout, add-to-cart, sélecteur variantes (Noibu, release monitoring 2026). Croisez tickets CHK-* Safari mobile avec erreurs front monitorées. Un bug silencieux sans message d'erreur client = rage clicks en session replay.
Priorisation par impact revenu
Classez bugs par étape funnel : checkout > panier > PDP > navigation. Un filtre cassé génère plus de tickets qu'un footer mal aligné, mais touche moins le CA immédiat.
Comment analyser navigation et découverte produit via le support ?
Les tickets NAV-* sont une mine d'or pour l'architecture de l'information.
Méthode mining hebdomadaire
Export tickets redesign_nav. Regroupez par produit ou catégorie recherchée. Exemple Seasalt : clients cherchaient les chaussettes sous « Clothing » et non « Accessories » (LJ Hazzard, navigation Seasalt). Chaque cluster ≥5 tickets/semaine = candidat cross-link ou renommage menu.
Cas MANIKO : PDP et panier
MANIKO a redesigné le Starter Set (produit à plus forte marge) parce qu'il générait le plus de tickets care : contenu du kit flou, panier illisible avec 4 lignes séparées. Résultat : moins de questions générales, moins de retours (Anna Rumenova, refonte MANIKO).
Actions merchandising depuis tickets
Patch sous 72 h : lien « Vous cherchez les chaussettes ? » depuis PDP jambes, renommage menu, bloc « contenu du kit » visuel, délais livraison remontés sur PDP si CHK-* pré-checkout. Voir données conversations merchandising (#108).
Comment mettre à jour bot et base de connaissances après refonte ?
Le corpus support doit basculer le jour J, pas quand « on aura le temps ».
Base de connaissances
Articles : nouveau menu, compte client, livraison, retours
Retrait captures et URLs legacy
Page « Bienvenue sur notre nouveau site » avec cartographie
Vidéo 60 s parcours achat si refonte majeure navigation
Chatbot
Intents redesign_nav, redesign_account, redesign_shipping actifs J0-J+45. Sync catalogue Shopify (#140). Handoff avec tag redesign pour reporting. Test gold set 25 questions avant go-live : où trouver catégorie X, reset compte, appliquer promo, modifier panier kit.
Canaux
Message accueil widget : « Site renouvelé, nous vous guidons ». Auto-réponse e-mail J0-J+14 mentionnant refonte + lien aide navigation. Story Instagram pinned : « Nouveau site, voici comment commander ».
Quels KPI support suivre pendant les 60 premiers jours ?
Les KPI support post-refonte mesurent retour à la normale et qualité corrective.
KPI leading (J0 à J+14)
Part tickets redesign : cible < 20 % J+7, < 10 % J+14
Top tag redesign : doit pivoter (NAV → stabilisation)
FRT CHK-* : < 30 min hypercare
Tickets bug confirmés / total redesign : traçabilité escalade
Pages patchées / semaine : vélocité boucle support → UX
KPI lagging (J+30 à J+60)
CSAT segment tickets redesign (cible 4,2+). Contact rate global vs baseline pré-refonte. Taux retour 30 j (alerte si hausse : confusion PDP). Conversion assistée chat sur pages patchées. Noibu recommande de suivre le taux d'erreur checkout et les régressions post-release comme indicateurs revenu, pas seulement le volume tickets (Noibu, métriques monitoring 2026).
Dashboard hebdo (5 minutes)
Volume redesign, top 3 tags, top 3 URLs, bugs ouverts/fermés, 1 action UX prioritaire semaine suivante.
Quelles erreurs support coûtent confiance après redesign ?
Cinq anti-patterns support post-refonte reviennent à chaque lancement UX.
Erreurs fréquentes
Go-live sans brief agents : « le site a changé » sans carte des mouvements
Minimiser la confusion : « vous vous habituerez » au lieu de guider
Tickets non tagués : impossible de prioriser patchs UX
Bot obsolète : chemins ancien menu, anciennes captures
Silence produit : support absorbe sans remonter NAV-* au merchandising
Debrief J+30
Volume redesign, top intents, 5 patchs UX issus tickets, 3 learnings pour prochaine refonte. Voir plan support lancement (#114) pour la logique hypercare transposable.
Comment Qstomy accompagne-t-il le support après une refonte ?
Qstomy transforme les tickets redesign en réponses guidées et remontées structurées.
Fonctionnalités post-refonte
Intents redesign_nav : guide menu et recherche produit
Contexte page : bot sait où le client est bloqué
Corpus switch J0 : policies et parcours à jour
Tag redesign : reporting hypercare automatique
Handoff : transcript + URL + device pour escalade bug
Scénario DTC chiffré
Marque accessoires mode, refonte navigation + panier kit, 12k visites/j. Semaine 1 sans plan : projection 340 tickets redesign (28 % du volume). Prep tags REDESIGN-*, Qstomy intents navigation + mining hebdo vers merchandising : tickets NAV-* -47 % vs semaine 1 brute, déflexion bot « où trouver X » 63 %, 4 patchs menu sous 10 j, CSAT segment redesign 4,1/5 vs 3,4 N-1 refonte interne.
Ce qui a le plus réduit la charge
Intent navigation avec synonymes catégories (ex. « chaussettes » → lien direct collection) a absorbé 63 % des questions menu. Le brief agents « 3 mouvements majeurs du site » a évité les réponses contradictoires sur l'emplacement des promos.
Explorez support IA, Shopify, demander une démo.
Quels playbooks opérationnels déployer après la refonte ?
Playbook 1 : baseline tickets (T-14)
Export 30 j avant go-live : volume, top intents, contact rate. Référence pour comparer J+7.
Playbook 2 : tags et macros REDESIGN-* (T-7)
Créer 6 tags, rédiger REDESIGN-INTAKE, REDESIGN-NAV-01, REDESIGN-CHK-ESC. Formation agents 90 min avec capture nouveau parcours.
Playbook 3 : hypercare J0-J+7
Slack #redesign-support, daily 15 min, owner nommé, escalade CHK-* sous 30 min.
Playbook 4 : mining NAV-* hebdo
Export lundi, clusters produits recherchés, patch menu ou cross-link sous 72 h si ≥5 tickets.
Playbook 5 : boucle bug support → dev
Template Jira, SLA 4 h hypercare, macro REDESIGN-FIXED post-déploiement.
Playbook 6 : debrief J+30
KPI redesign, top patchs UX, update corpus bot, doc learnings Notion pour prochaine refonte.
Maillage utile
Une refonte réussie côté client, ce n'est pas seulement un beau design : c'est un support qui capte la friction et la transforme en corrections visibles en moins de 72 h.
Enzo
28 juin 2026
