Lorsqu'une mise à jour de WooCommerce intervient, les équipes e-commerce font face à un dilemme classique : adopter le nouveau template par défaut et perdre leur charte graphique personnalisée, ou conserver une surcharge (override) obsolète sans savoir exactement ce qui a changé. La bonne méthode consiste à s'appuyer sur une référence validée dans Migma pour le message souhaité, puis à laisser le développeur de la boutique mettre à niveau le template WooCommerce réel. Aucun export de design ne peut effectuer cette maintenance de code à votre place.
L'objectif est d'obtenir un template à jour, fidèle à l'identité visuelle de votre marque et irréprochable sur les détails de commande. Faire disparaître une alerte dans l'administration, valider une capture d'écran et réussir un envoi d'e-mail sont trois étapes distinctes. Ce guide fournit aux équipes marketing et aux développeurs un cadre de recette partagé.
Publié par Migma. Les informations produit ont été vérifiées le 19 octobre 2026. La méthode décrite ci-dessous constitue une recommandation éditoriale et ne présente aucun module d'installation natif de Migma pour les templates WooCommerce.
Identifier le template réellement concerné
Commencez par demander à l'administrateur de la boutique d'ouvrir WooCommerce → État → État du système (ou WooCommerce → Status → System Status selon la langue de l'interface). Comme l'explique le guide officiel sur les templates obsolètes, ce rapport répertorie l'ensemble des fichiers surchargés par le thème ou le thème enfant et signale les versions dépassées.
Relevez précisément le nom du fichier et la notification affichée. La surcharge d'un e-mail transactionnel ne se gère pas comme celle d'une fiche produit, même si les deux alertes figurent dans le même rapport. Notez également le thème actif, les extensions d'e-mailing installées et la version de WooCommerce ciblée. Ne lancez jamais de refonte graphique sur la seule base du texte de l'avertissement.
Vérifiez qui assure la maintenance du fichier. L'éditeur d'un thème peut fournir directement un correctif, tandis qu'un template développé sur mesure dans un thème enfant exigera qu'un développeur réintègre vos adaptations sur la base du fichier WooCommerce actualisé. La documentation de WooCommerce prévoit explicitement ces deux cas de figure. Choisissez la méthode adaptée au responsable du code au lieu de copier une solution générique en production.
Conserver deux références avant toute modification
Sauvegardez une copie du template en fonctionnement et archivez un e-mail réel représentatif reçu en boîte de réception. Le fichier source préserve les détails techniques de l'implémentation ; l'e-mail reçu témoigne de l'expérience client vécue. Aucun des deux ne remplace l'autre.
Dressez la liste concise des personnalisations voulues : emplacement du logo, hiérarchie de lecture, mentions du support client, pied de page et blocs conditionnels. Distinguez ces choix délibérés des comportements accidentels. Un saut de ligne hérité d'une mise en page vieillissante ne doit pas nécessairement être conservé.
Dans Migma, gardez une maquette validée correspondant au résultat attendu. Si la création d'origine y est déjà stockée, identifiez l'e-mail concerné. Dans le cas contraire, créez un projet de revue à partir des textes validés et d'une référence conforme. Présentez les données de commande sous forme d'exemples explicites, afin que personne ne prenne une maquette statique pour une source de données transactionnelles en direct.
Traiter séparément le code et la création graphique
La procédure officielle de WooCommerce recommande d'identifier les templates obsolètes, de créer une sauvegarde, de repartir de la version par défaut actuelle, puis d'y réintégrer vos personnalisations. Votre développeur doit analyser les écarts de code pertinents et mettre à jour le fichier selon les processus de déploiement habituels du site.
Ne supprimez pas l'avertissement en modifiant simplement le numéro de version dans l'en-tête du fichier sans réviser son contenu. L'intérêt de l'opération est précisément de comprendre et d'intégrer les évolutions du cœur de WooCommerce. De même, ne remplacez jamais un template PHP complet par un simple fichier HTML exporté : la boutique perdrait aussitôt ses variables dynamiques, ses hooks et ses affichages conditionnels.
La documentation sur les exports Migma détaille comment récupérer du code HTML pour d'autres outils et en vérifier le rendu final. Utilisez ce code HTML comme référence graphique lorsque l'intégrateur le juge utile. La logique du template WooCommerce et ses extensions restent seules maîtresses de l'injection des données de commande dans l'e-mail.
Valider la recette sur des commandes complexes
Une commande test idéale ne suffit pas pour valider un gabarit. Définissez un ensemble restreint de scénarios représentatifs avant que le développeur ne commence l'intégration. Choisissez des cas concrets liés à la finalité de la notification, plutôt que de chercher à combiner toutes les options du catalogue dans un seul message.
| Cas test | Éléments à contrôler lors de la revue |
|---|---|
| Plusieurs articles aux libellés longs | La lisibilité du texte reste nette et les totaux demeurent faciles à repérer |
| Données client facultatives manquantes | Aucun libellé vide ni formule de salutation tronquée n'apparaît |
| Remises et frais d'expédition appliqués | L'e-mail restitue fidèlement les montants calculés par la boutique |
| Changement de statut de commande | Le titre du message et l'action suivante décrivent exactement ce statut |
| Écran étroit et blocage des images | Les informations clés de la commande et le lien d'assistance restent compréhensibles |
Ces scénarios servent de guide de relecture et ne constituent pas un compte rendu de test. Ne modifiez pas artificiellement les données réelles d'une commande pour embellir la mise en page. Si une notification ne contient pas nativement un champ spécifique, écartez ce cas plutôt que d'inventer une fonctionnalité inexistante sur la plateforme.
Confronter le rendu technique à la maquette validée
Passez la maquette au crible de Migma Email Preflight pour contrôler la mise en page, les liens, la rédaction et les risques fréquents à l'envoi. Inspectez ensuite séparément l'e-mail produit par WooCommerce via le protocole de test habituel de votre équipe.
Vérifiez d'abord le fond : objectif de la notification, gestion du nom du client, numéro de commande, détail des articles, totaux et accès au support. Contrôlez ensuite la forme : intégration du logo, espacements, contrastes, hiérarchie des titres et lisibilité des boutons d'action. Un léger écart graphique peut être toléré ; en revanche, une modification dans les engagements de paiement ou de livraison exige un arbitrage immédiat.
Observez le résultat réel envoyé sur différentes messageries lors des phases de test. Un aperçu dans un navigateur web ne garantit pas le rendu sur les clients de messagerie, et l'outil Preflight ne peut garantir la délivrabilité en boîte de réception. Archivez les preuves de validation de la version intégrée en les associant au numéro de version du code source correspondant.
Faciliter les prochaines mises à jour
Conservez l'historique des personnalisations directement à côté des consignes de maintenance du template. Consignez le propriétaire du code, le responsable de la validation des textes, l'emplacement de la maquette Migma et les cas tests validés. Évitez les transmissions de consignes qui se résument à une capture d'écran partagée à la va-vite dans une messagerie interne.
Si le nouveau template par défaut de WooCommerce couvre déjà vos besoins grâce à ses réglages natifs, évaluez l'opportunité de supprimer la surcharge. Cette décision technique appartient au gestionnaire de la boutique et au développeur, en accord avec les exigences graphiques validées.
Pour une refonte plus globale, consultez notre guide de revue design des e-mails de commande WooCommerce. Lors d'une mise à jour de routine, restez pragmatique : mettez à niveau le template modifié, préservez les choix structurants de votre marque et validez le message envoyé au client avant toute mise en ligne.
Foire aux questions
Migma met-il à jour automatiquement les surcharges WooCommerce ?
Non, il n'existe pas de processus de mise à jour automatisé de ce type. Migma sert à concevoir le design validé et à exporter le code HTML de référence si besoin ; votre développeur WooCommerce reste responsable du template de la boutique et de sa logique technique.
Suffit-il d'incrémenter le numéro de version du template ?
Non, cela ne garantit en rien que les évolutions de code introduites par la mise à jour ont été prises en compte. Le développeur doit comparer le template actuel avec vos personnalisations délibérées, puis tester l'e-mail obtenu.
Quels éléments archiver avant de modifier un template d'e-mail ?
Conservez une sauvegarde du template en production, un exemple d'e-mail réel reçu en boîte de réception, l'inventaire des personnalisations souhaitées et la maquette validée, en notant pour chacun le responsable et la version correspondante.
Un aperçu satisfaisant dans le navigateur suffit-il à valider la mise à jour ?
Non. Il est indispensable de tester des données de commande et des conditions représentatives dans la notification générée, puis d'inspecter l'e-mail réellement envoyé via le processus de test de votre équipe. Un rendu visuel correct ne prouve pas que la logique technique fonctionne.