Checklist de recette avant un lancement Shopify

La recette ne commence pas quand le site paraît terminé. Elle commence quand les parcours, les données, les règles commerciales et les intégrations sont assez stables pour être testés de façon reproductible. Sinon, l'équipe ne valide pas une version. Elle poursuit la conception dans un tableur de bugs.

Une recette Shopify utile répond à quatre questions : qu'est-ce qui doit fonctionner, dans quelles conditions, qui le vérifie et quelle preuve permet de fermer le test ? Cette discipline compte autant pour une nouvelle boutique que pour une refonte ou une migration. Elle évite aussi de confondre un détail visuel avec un défaut qui bloque les commandes, les paiements, le tracking ou l'indexation.

Shopify recommande de passer une commande test afin de vérifier le checkout, le traitement des commandes, le stock, l'expédition, les emails et les taxes selon la configuration de la boutique. Son guide de préparation au lancement couvre aussi le domaine, les canaux de vente, les notifications, les politiques et la suppression de la protection par mot de passe. Ces listes donnent un cadre de plateforme. La recette projet doit ajouter le modèle métier, les intégrations, les marchés, le contenu et les responsabilités propres au site.

Avant la checklist : rendre la recette possible

Un environnement instable produit des résultats contradictoires. Avant d'ouvrir la recette client, fixez des critères d'entrée.

• Le périmètre à tester est documenté, y compris les exclusions.
• La version candidate est identifiée par une date, un tag ou un numéro de version.
• Les données de référence sont chargées : produits, variantes, stocks, prix, promotions, clients de test et contenus.
• Les services externes nécessaires sont connectés à un environnement de test ou à une configuration contrôlée.
• Les comptes et moyens de paiement de test sont disponibles sans partager de secrets dans les tickets.
• Les marchés, devises, langues, domaines et règles de livraison en périmètre sont connus.
• Les responsables de chaque flux et l'autorité qui décide du lancement sont nommés.
• Le format de preuve est convenu : capture, vidéo, identifiant de commande de test, log anonymisé ou export.

BlackSwan réalise une QA interne avant la recette client lorsqu'elle fait partie du périmètre. Le client ne doit pas découvrir les défauts élémentaires à la place de l'équipe projet. La recette client se concentre alors sur l'acceptation métier, les contenus, les règles commerciales et les cas propres à ses opérations.

Organiser la recette par flux, pas par page

Tester chaque page sur desktop puis mobile ne suffit pas. Une commande traverse la fiche produit, le panier, le checkout, le paiement, Shopify Admin, les notifications et parfois un ERP, un OMS ou un 3PL. La recette doit suivre ce parcours complet.

Un même test peut avoir plusieurs contributeurs, mais un seul responsable doit confirmer sa fermeture. Sans cela, les tickets restent « à vérifier » jusqu'au jour du lancement.

1. Parcours d'achat et règles commerciales

Testez d'abord les parcours qui génèrent ou modifient une commande. Utilisez une matrice représentative plutôt qu'une combinaison exhaustive impossible à maintenir.

Catalogue et produit

• Les produits attendus sont publiés dans les bons canaux et marchés.
• Les titres, descriptions, médias, variantes, prix et disponibilités correspondent à la source approuvée.
• Les options sélectionnent la bonne variante et mettent à jour prix, média, disponibilité et URL si prévu.
• Les produits indisponibles suivent la règle validée : achat bloqué, précommande ou information dédiée.
• Les métachamps et métaobjets utilisés par les templates sont renseignés ou gèrent proprement l'absence de valeur.
• Les collections automatiques et manuelles contiennent les produits attendus dans l'ordre prévu.
• La recherche, les filtres et le tri renvoient des résultats cohérents.
• Les bundles, abonnements, cadeaux, échantillons ou personnalisations sont testés seulement lorsqu'ils font partie du périmètre.

Panier et promotions

• L'ajout, la suppression et la modification de quantité recalculent correctement le panier.
• Les limites de quantité et règles de disponibilité sont respectées.
• Les remises compatibles s'appliquent dans les conditions prévues.
• Les remises incompatibles ne se cumulent pas par erreur.
• Les seuils de livraison, cadeaux ou avantages utilisent le bon marché et la bonne devise.
• Les messages du panier restent exacts après chaque modification.
• Le panier persiste ou se réinitialise selon le comportement validé entre domaines, langues et sessions.

Checkout et paiement

• Le checkout reçoit les bonnes lignes, quantités, remises, adresses et attributs.
• Les moyens de paiement attendus apparaissent dans les cas éligibles.
• Une transaction réussie crée une commande avec les bons statuts.
• Un paiement refusé affiche un message exploitable et ne crée pas une fausse confirmation.
• Les tests couvrent au moins les adresses, devises et modes de livraison prioritaires.
• Les taxes et totaux affichés correspondent aux règles validées par les responsables compétents.
• Les pages de confirmation et de statut de commande présentent les informations attendues.
• Les commandes de test sont identifiables et supprimées ou annulées selon la procédure prévue.

Ne saisissez jamais de vraie carte bancaire dans une capture ou un ticket. Shopify documente plusieurs méthodes de commande test selon le fournisseur de paiement et la configuration. Choisissez la méthode compatible avec la boutique et vérifiez les effets induits avant de lancer le test.

2. Livraison, taxes, stock et opérations

Le storefront peut afficher un résultat correct alors que l'administration ou un système connecté reçoit une donnée incorrecte. La recette doit donc vérifier l'écriture puis la lecture en retour.

• Chaque zone de livraison prioritaire propose les tarifs et services attendus.
• Les adresses hors zone suivent le message prévu.
• Les restrictions de produits, poids, valeur ou localisation sont testées.
• Les délais affichés proviennent de la règle approuvée et ne créent pas de promesse non contractualisée.
• Les taxes sont revues par le client ou son conseil compétent. La recette vérifie l'implémentation, pas la conformité juridique à elle seule.
• Le stock initial est réconcilié par variante et emplacement.
• Une commande réduit ou réserve la bonne quantité selon le flux prévu.
• Une annulation, un remboursement ou un retour produit l'effet attendu sur la commande et le stock.
• Les statuts de préparation et d'expédition circulent vers les systèmes en périmètre.
• Les notifications client utilisent la bonne langue, les bonnes données et des liens fonctionnels.

Pour chaque intégration, définissez une clé de corrélation entre Shopify et le système externe. Le test doit pouvoir relier une commande, un client ou un produit aux enregistrements correspondants sans exposer de données personnelles dans le compte rendu.

3. Comptes, contenus et accessibilité

• La connexion, la récupération d'accès, l'historique de commandes et les adresses suivent le modèle de compte choisi.
• Les retours, annulations et demandes de contact atteignent le bon outil lorsqu'ils sont en périmètre.
• Les emails de compte, commande, expédition et remboursement utilisent la bonne langue et des liens valides.
• Chaque gabarit prioritaire est testé avec un contenu court, long, incomplet et traduit.
• Les images, vidéos, titres, boutons, formulaires et états d'erreur ont le contenu prévu.
• Le clavier, le focus, le zoom, le contraste et les lecteurs d'écran sont contrôlés selon le standard retenu par le projet.

Testez les composants réutilisables sur des cas limites. Un défaut dans le design system peut se propager sur toute la boutique.

4. Mobile, navigateurs et performance

Exécutez les parcours prioritaires sur la matrice de navigateurs, appareils et tailles d'écran convenue. Vérifiez les contrôles tactiles, claviers mobiles, modales, médias, erreurs JavaScript et requêtes critiques. Pour chaque mesure de performance, conservez l'URL, la date, l'appareil, le réseau, l'outil et le contexte de consentement. Notre page Performance Shopify et Core Web Vitals détaille cette méthode.

5. SEO et migration

Une boutique protégée, un canonical erroné ou une série de redirections cassées peut annuler une partie du travail de lancement. Le point de contrôle SEO doit être explicite.

• Les title et meta descriptions des gabarits prioritaires suivent les règles validées.
• Un seul H1 pertinent est présent lorsque le template l'exige.
• Les canonicals pointent vers les URL attendues.
• Les directives robots et meta robots correspondent à l'environnement public.
• Le sitemap contient les ressources publiées attendues.
• Les pages internes prioritaires sont accessibles par des liens crawlables.
• Les données structurées sont valides et correspondent au contenu visible.
• Les hreflang relient les bonnes variantes de langue et de marché.
• Les pages supprimées ou consolidées suivent la décision documentée.
• Le plan de redirections est importé, réexporté et testé.
• Le domaine canonique, les propriétés Search Console et le plan de suivi sont prêts.

Pour une migration, utilisez le plan de redirections Shopify comme registre séparé. La checklist de lancement confirme son exécution, mais ne remplace pas le mapping URL par URL.

6. Analytics, consentement et marketing

Un événement visible dans la console n'est pas encore une donnée fiable. Vérifiez son déclenchement, ses paramètres, son unicité et son comportement selon le consentement.

• Les environnements de test et de production utilisent les identifiants prévus.
• Les pages vues et étapes e-commerce prioritaires sont observées dans l'outil cible.
• Une action ne déclenche pas plusieurs événements d'achat ou d'ajout au panier.
• Les montants, devises, produits, quantités et remises transmis correspondent à la commande test.
• Les paramètres de campagne sont conservés selon le plan de mesure.
• Le consentement modifie réellement le chargement ou l'envoi des outils concernés.
• Le retrait ou changement de consentement suit le comportement prévu.
• Les pixels publicitaires sont testés sans inclure de données interdites.
• Les formulaires marketing affichent la bonne information et enregistrent la bonne préférence.
• Les équipes analytics et acquisition ont signé le plan de marquage en périmètre.

La conformité juridique ne se déduit pas d'un test technique. Le client et ses conseils valident les textes, finalités, durées et bases applicables. L'équipe projet vérifie que la configuration approuvée fonctionne comme prévu.

7. Marchés, langues et domaines

Une vérification menée uniquement depuis la France, en français et en euros ne valide pas un déploiement international.

Créez une matrice par marché prioritaire avec domaine, langue, devise, catalogue, prix, disponibilité, moyen de paiement, livraison, taxes, consentement et notifications. Testez chaque combinaison retenue avec une adresse et une commande contrôlées.

• Le bon domaine affiche le bon storefront.
• Le sélecteur conserve ou change le marché selon la règle validée.
• Les traductions couvrent le thème, le contenu, les emails et les messages d'erreur.
• Le catalogue et les prix correspondent au marché.
• Les produits non disponibles ne réapparaissent pas par recherche ou lien direct.
• Les moyens de paiement et tarifs de livraison suivent l'éligibilité prévue.
• Les liens entre domaines conservent une destination valide.
• Les canonicals et hreflang ne mélangent pas les variantes.
• Les équipes locales ont validé les contenus et règles qui leur appartiennent.

Shopify documente la gestion des domaines et des domaines internationaux. Vérifiez la documentation à la date du projet, car les capacités et libellés de l'administration peuvent évoluer.

8. Sécurité, exploitation et journal de défauts

• Les comptes sont individuels, les rôles sont limités et les accès temporaires ont une date de retrait.
• Aucun secret ne figure dans le code, les tickets, les captures ou les documents publics.
• La procédure de lancement nomme les responsables qui surveillent commandes, paiements, stocks, intégrations, erreurs et trafic.
• Les actions de reprise sont documentées pour les risques couverts, dans le cadre prévu au contrat.
• La protection par mot de passe est retirée au moment convenu.

Un ticket doit contenir un identifiant, la version, l'environnement, les préconditions, les étapes, le résultat observé, le résultat attendu, la sévérité, le responsable, la preuve et le nouveau test. Distinguez la sévérité technique de la priorité commerciale.

La décision de lancement

La décision finale ne consiste pas à compter les tickets ouverts. Elle évalue leur effet et les mesures de contrôle disponibles.

Organisez une revue courte avec les responsables. Présentez les blocages, les tests non exécutés, les risques acceptés et le plan de surveillance. Une case cochée sans preuve vaut moins qu'un test fermé avec un identifiant de commande et un contrôle confirmé dans le système cible.

Checklist du jour de lancement

• La version candidate approuvée est celle qui sera publiée.
• Le gel des contenus, handles, données et configurations est actif selon la procédure de lancement.
• Les commandes et comptes de test ont été traités selon la procédure.
• Le domaine et les certificats répondent comme prévu.
• Les redirections prioritaires sont actives.
• Le robots.txt, les meta robots, canonicals, hreflang et sitemaps sont contrôlés sur le domaine public.
• Une commande de contrôle est passée sur les parcours prioritaires.
• Les événements analytics sont observés une dernière fois.
• Les intégrations reçoivent et renvoient les statuts attendus.
• Les équipes e-commerce, support, opérations et technique connaissent le canal de suivi.
• Les tableaux de bord et alertes prévus sont ouverts.
• Le journal de lancement consigne chaque action, heure, responsable et résultat.

Après la mise en ligne, continuez à tester. Surveillez les commandes, paiements, stocks, erreurs HTTP, intégrations, analytics et signaux SEO selon la cadence définie dans la procédure de lancement. Le lancement ne ferme pas la recette. Il ouvre la phase d'observation sur le trafic réel.

Questions fréquentes

Combien de temps faut-il prévoir pour la recette Shopify ?

Il n'existe pas de durée universelle. Elle dépend du nombre de parcours, marchés, intégrations, règles commerciales et acteurs. Estimez la charge à partir de la matrice de tests, du temps de correction et du nouveau test. Un délai annoncé sans ce périmètre serait trompeur.

Qui doit réaliser la recette ?

L'agence ou l'équipe projet effectue la QA technique et fonctionnelle prévue au contrat. Le client valide les contenus, règles métier, opérations et obligations qui lui appartiennent. Les partenaires SEO, analytics, paiement ou intégration interviennent sur leur périmètre. Un responsable unique ferme chaque test.

Peut-on lancer avec des anomalies ouvertes ?

Oui pour certains écarts non bloquants, si le risque, la solution temporaire, le responsable, l'échéance et la surveillance sont acceptés. Une anomalie qui touche le paiement, les totaux, la sécurité, les commandes ou une fonction critique demande en principe une correction et un nouveau test avant le lancement.

Une commande test suffit-elle ?

Non. Elle vérifie un scénario. La matrice doit couvrir les principaux marchés, paiements, livraisons, promotions, statuts et intégrations. Shopify recommande la commande test, mais le projet doit définir les cas représentatifs de son modèle.[1]

Préparer votre lancement Shopify

Nous intégrons la recette à notre méthode projet : QA interne, matrice d'acceptation, responsables, preuves et procédure de lancement selon le périmètre convenu. Vous gardez une vue claire des blocages et des décisions à prendre.

Échanger sur votre migration ou lancement Shopify