Shopware 6.7 est sortie fin 2024 avec ce que la documentation officielle qualifie de « major release with multiple breaking changes ». Pour les boutiques en 6.6, la migration est obligatoire à terme — Shopware ne maintient en parallèle que la dernière version stable et la version précédente, donc rester sur 6.5 ou 6.6 trop longtemps coupe l’accès aux correctifs de sécurité. Pour les plugins développés en 6.6, plusieurs API critiques ont changé de signature ou ont été supprimées entre 6.6 et 6.7.
Cet article est un retour d’expérience direct sur la migration 6.6 → 6.7 que nous avons menée sur plusieurs boutiques en 2025-2026, avec les vrais pièges techniques qu’on a rencontrés et les patches que nous avons dû produire pour adapter nos plugins propres et tiers. L’objectif : éviter à d’autres équipes le mois de debugging que nous avons passé sur certaines régressions silencieuses.
Ce qui change vraiment dans Shopware 6.7
Au-delà du marketing release, voici les changements 6.7 qui ont un impact concret sur les plugins existants.
Refonte de l’API Payment Handler. L’interface AsynchronousPaymentHandlerInterface est supprimée en 6.7. Tout plugin de paiement qui implémentait cette interface en 6.6 doit migrer vers AbstractPaymentHandler. Les méthodes pay() et finalize() ont une signature différente : la struct AsyncPaymentTransactionStruct est remplacée par PaymentTransactionStruct, plus minimaliste et orientée DDD.
Tags de service modifiés. Le tag shopware.payment.method.async qui distinguait les payments synchrones et asynchrones est supprimé au profit d’un tag unifié shopware.payment.method. Si vos services.xml utilisaient l’ancien tag, le payment handler ne se déclare plus correctement et le mode de paiement disparaît du checkout sans erreur visible.
Migration admin Vue 2 → Vue 3. L’admin Shopware 6.7 est portée sur Vue 3 (alors que 6.6 était sur Vue 2 avec compat layer). Les composants sw-* (legacy) sont en cours de remplacement par les composants mt-* (Meteor design system). Beaucoup de composants sw-* sont marqués deprecated et seront supprimés dans une release 6.x ultérieure. Les plugins admin qui utilisaient les composants sw-* doivent migrer.
Système de traduction admin modifié. Les méthodes $tc() (translation choice, gestion du pluriel) ont été remplacées par $t() avec gestion native du pluriel. Vos templates admin qui faisaient {{ $tc('mon.plugin.label') }} doivent passer à {{ $t('mon.plugin.label') }}.
Build admin via Vite. L’admin compile désormais via Vite avec un manifest.json structuré différemment de la 6.6. Les plugins qui injectaient leur JS admin via le mécanisme historique doivent adapter leur build pipeline pour générer le bon manifest, sinon l’admin charge un JS vide au lieu de votre code.
Storefront : Bootstrap 5.3 généralisé. Le passage à Bootstrap 5.3 dans le storefront active le support natif de data-bs-theme, ce qui simplifie les implémentations de mode sombre — sujet de notre plugin DataFirefly Dark Mode qui exploite cette convention. Les thèmes custom basés sur Bootstrap 5.2 ou antérieur peuvent avoir des variables SCSS qui ne mappent plus.
Compatibilité PHP et MySQL. 6.7 demande PHP 8.2+ (PHP 8.1 sorti, PHP 8.3 recommandé) et MySQL 8.0+ ou MariaDB 11.4 LTS. Les hébergements encore en MySQL 5.7 ou MariaDB 10.x doivent migrer leur DB avant l’upgrade applicatif.
Les breaking changes plugin par plugin que nous avons rencontrés
Sur les boutiques que nous avons migrées, voici les bugs concrets découverts à l’upgrade 6.6 → 6.7.
MoptWorldline (paiement Worldline / SaferPay). Le plugin de paiement Worldline en version 6.6 implémentait AsynchronousPaymentHandlerInterface. Au passage 6.7, le plugin ne charge plus correctement, et les méthodes de paiement Worldline disparaissent du checkout. Le patch demande de migrer vers AbstractPaymentHandler et de réécrire les méthodes pay() et finalize() avec la nouvelle signature PaymentTransactionStruct. Travail estimé : 2-4 jours pour un dev Shopware expérimenté.
Plugins admin custom avec composants sw-*. Sur nos plugins MySmartBook et autres, plusieurs composants admin custom utilisaient sw-card, sw-button, sw-text-field, etc. En 6.7, ces composants existent encore mais sont marqués deprecated. Les composants mt-card, mt-button, mt-text-field les remplacent. La migration est mécanique mais demande une revue exhaustive de tous les fichiers admin.
Snippets et traductions. Les fichiers de snippets en 6.6 utilisaient parfois la structure pluralisée que $tc() consommait. En 6.7 avec $t(), certaines structures de snippets ne marchent plus identiquement. À tester systématiquement, surtout sur les snippets avec compteurs (« 1 produit » / « N produits »).
Custom field customer et synchronisation. Notre plugin Dark Mode pour Shopware stocke la préférence utilisateur dans un custom field df_dark_mode_preference sur l’entité customer. La migration 6.7 a conservé la compatibilité custom fields, mais l’API de synchronisation a une signature légèrement différente. À tester systématiquement après upgrade.
OpenSearch 2.19+ obligatoire. Si votre boutique utilise la recherche fulltext avec OpenSearch (ex-Elasticsearch dans les versions Shopware antérieures), 6.7 demande OpenSearch 2.19 minimum. Les versions OpenSearch 1.x ne sont plus supportées. Migration cluster OpenSearch à prévoir avant l’upgrade applicatif.
La checklist de migration en 8 étapes
Pour une migration 6.6 → 6.7 maîtrisée, voici l’ordre que nous suivons en interne.
Étape 1 — Audit des plugins installés. Listez tous les plugins activés sur votre boutique. Pour chacun, vérifiez sur le store ou sur GitHub si une version compatible 6.7 existe. Les plugins non-mis à jour sont des risques majeurs : à désactiver temporairement, ou à patcher en interne, ou à remplacer.
Étape 2 — Audit du thème custom. Si vous utilisez un thème custom (et non le thème Storefront natif), vérifiez la compatibilité avec Bootstrap 5.3, les changements de structure base layout, et le système Vite admin si votre thème injecte du JS admin custom.
Étape 3 — Mise à jour environnement infrastructure. PHP 8.2+, MySQL 8 ou MariaDB 11.4 LTS, OpenSearch 2.19+ si utilisé, Node.js récent (18+ ou 20 LTS). À faire avant l’upgrade applicatif Shopware.
Étape 4 — Backup complet. Base de données + dossier files + fichiers config/. C’est l’étape qu’on a tendance à négliger jusqu’au moment où l’upgrade casse irrémédiablement quelque chose. À faire systématiquement avant tout changement.
Étape 5 — Migration sur environnement de staging. Cloner la prod sur un staging identique, faire l’upgrade 6.7 sur le staging, valider exhaustivement avant de toucher la prod. Ce n’est pas une option — sur les boutiques que nous avons migrées, 30 % ont eu des bugs critiques découverts uniquement en staging.
Étape 6 — Upgrade applicatif Shopware. Via le SUM (Shopware Update Manager) en CLI : bin/console system:update:prepare, puis bin/console system:update:finish. Bien lire la documentation officielle pour les options (skip-asset-build, etc.). Compter 30 min à 2 h selon la taille de la base.
Étape 7 — Recompilation thème et admin. Après l’upgrade core, recompiler le thème (bin/console theme:compile) et rebuild l’admin (bin/build-administration.sh). Sur Shopware 6.7, l’admin se compile via Vite ; la commande historique theme:compile ne suffit plus pour l’admin.
Étape 8 — Test exhaustif post-upgrade. Parcours complet : navigation catalogue, fiche produit, ajout panier, checkout, paiement (chaque méthode de paiement testée individuellement), espace client, admin (chaque module installé). Sur les boutiques B2B, tester aussi devis, comptes hiérarchiques, prix par client.
Les pièges silencieux qu’on a rencontrés en vrai
Au-delà des breaking changes documentés, voici les bugs subtils qui ne se voient pas immédiatement après l’upgrade.
Le payment handler qui ne déclare plus. Comme mentionné plus haut, un plugin de paiement avec ancien tag shopware.payment.method.async ne s’enregistre plus en 6.7. Le mode de paiement disparaît du checkout, mais aucune erreur n’est levée — le payment_method_id correspondant existe toujours en base, simplement le handler n’est plus instancié. Symptôme côté client : la méthode est affichée à l’admin (configuration / sales channels / payment methods) mais n’apparaît pas au checkout.
Le composant admin custom qui rend vide. Un composant qui utilisait $tc() sans aucune translation associée (cas des labels hardcodés) ne rend plus rien en 6.7. Pas d’erreur dans la console, simplement un placeholder vide. À détecter par revue manuelle des écrans admin custom après upgrade.
Le manifest Vite qui ne se génère pas. Si votre plugin admin custom était buildé avec un script personnalisé en 6.6 (webpack ou rollup direct), ce build peut ne pas générer le manifest.json attendu par Shopware 6.7. Symptôme : l’admin charge mais votre JS plugin n’est pas exécuté. Solution : adapter le build pour exporter un manifest compatible Vite.
Les snippets pluralisés qui ne se traduisent plus. Si vous aviez des snippets avec structure {count} | une chose | {count} choses consommés par $tc(), le passage à $t() demande une syntaxe différente. Les snippets non-migrés affichent la chaîne template brute au lieu de la traduction.
Le custom field qui n’existe plus en API. Quelques modifications de l’API DAL (Data Abstraction Layer) en 6.7 ont changé la sérialisation de certains custom fields complexes (multi-select, JSON). Les valeurs en base existent toujours, mais sont lues différemment. À tester sur les custom fields critiques.
Conclusion : une migration nécessaire mais à anticiper
La migration Shopware 6.6 → 6.7 n’est pas une simple update mineure. Elle introduit des breaking changes significatifs qui demandent un travail réel sur les plugins (paiement notamment), l’admin custom, et l’infrastructure. Les boutiques qui font cette migration en 1 journée « parce qu’on a juste cliqué sur Update » découvrent les bugs en production des semaines plus tard, parfois avec impact direct sur le CA (paiement cassé, admin inutilisable).
L’investissement temps réaliste pour une boutique avec 5-10 plugins tiers et un thème custom est de 5 à 15 jours-homme pour un développeur Shopware expérimenté, plus quelques jours de recette. Anticiper le sujet, faire l’upgrade en staging, tester exhaustivement avant la prod, c’est ce qui distingue une migration maîtrisée d’une migration en crise.
Pour les sujets techniques connexes, parcourez nos catégories Actualités e-commerce et Performance & Core Web Vitals. Et si vous cherchez des plugins Shopware 6.7 français, performance-first et bien maintenus, notre plugin Dark Mode est compatible Shopware 6.7 dès la sortie et illustre les patterns techniques alignés sur la nouvelle architecture (anti-FOUC, custom field customer, événements JS pour synchronisation tierce).