Hyvä est devenu le standard front moderne de Magento 2 : Alpine.js et Tailwind à la place de RequireJS et Knockout, des Core Web Vitals nettement meilleurs, une expérience développeur plus simple. Mais une migration Hyvä n'est pas un « changement de thème » — c'est une réécriture du front. Voici ce que je cadre avant de chiffrer un projet.
1. Inventaire des personnalisations front
Tout ce qui touche le front Luma doit être recensé : templates .phtml surchargés, composants Knockout custom, widgets JS, blocs CMS spécifiques, surcharges de layout XML. C'est cet inventaire — pas le nombre de pages — qui détermine la charge réelle. Une boutique « simple » avec dix ans de surcharges accumulées coûte plus cher qu'un gros catalogue resté proche du standard.
2. Audit des modules tiers
Chaque extension qui injecte du front (sliders, filtres de recherche, configurateurs, pop-ups marketing) doit être classée :
- Compatible Hyvä : un module Hyvä existe ou l'éditeur le fournit.
- À porter : la logique est saine, le front est à réécrire en Alpine/Tailwind.
- À remplacer ou abandonner : module obsolète ou redondant.
Cet audit évite la plus grosse mauvaise surprise des migrations Hyvä : un module critique (souvent le moteur de recherche ou le checkout tiers) sans équivalent Hyvä.
3. Le checkout : le point chaud
Le checkout est presque toujours le bloc le plus personnalisé et le plus risqué. Deux options : Hyvä Checkout (un module commercial séparé, à licencier) ou la réutilisation du checkout Luma existant via un module de compatibilité. Le choix dépend du niveau de personnalisation existant (étapes custom, paiements spécifiques, B2B). À trancher tôt : c'est un poste de charge majeur.
4. Estimer l'effort honnêtement
Un cadrage sérieux découpe la charge par domaine : pages catalogue, page produit, panier, checkout, CMS/home, composants transverses (header, footer, recherche). Mieux vaut un devis ferme par phase qu'une enveloppe globale floue. Et il faut prévoir une ligne recette : une migration front non testée régresse en production.
5. Plan de migration par phases
Je recommande une migration itérative plutôt qu'un big bang :
- Socle Hyvä + design system (couleurs, typo, composants de base).
- Pages catalogue et produit (le plus gros du trafic).
- Panier et checkout.
- CMS, home, pages annexes.
- Recette complète + go-live.
Chaque phase est livrable et testable. On valide les Core Web Vitals à chaque étape — la migration doit prouver son gain de performance, pas seulement le promettre.
En résumé
Une migration Hyvä réussie se joue avant la première ligne de code : inventaire, compatibilité des modules, stratégie de checkout, découpage par phases. C'est exactement ce que couvre mon cadrage Migration Hyvä — 30 minutes gratuites pour savoir si c'est le bon moment et ce que ça implique. Parlons-en.