Hyvä, PWA ou rester sur Luma ? Un cadre de décision front-end Magento avec coûts réels

Si vous exploitez une boutique Magento 2, on vous a déjà dit que votre front-end posait problème. C’est souvent exact. Luma — le thème par défaut de Magento — charge RequireJS et Knockout.js pour chaque visiteur, et sur un Android milieu de gamme, cette pile seule peut vous coûter deux secondes avant l’affichage de la moindre image produit.

Mais le front-end est lent n’est qu’un symptôme, pas une solution. Les trois options — migrer vers Hyvä, construire une vitrine PWA ou optimiser le thème Luma existant — varient d’un ordre de grandeur en coût et à peu près autant en risque. Se tromper de choix est l’une des erreurs les plus coûteuses pour un marchand Magento, et ceux qui vous conseillent vendent généralement une seule des trois options.

Nous réalisons les trois. Voici le cadre d’analyse que nous utilisons en interne avant toute proposition, y compris lorsque nous recommandons de ne rien dépenser.

Les trois options, sans détour

Option 1 : optimiser le thème Luma existant

L’option que personne ne propose, car c’est la facture la plus faible. Luma est lent principalement à cause de ce qui lui a été ajouté : extensions tierces injectant leur propre JavaScript, modules RequireJS non regroupés, médias non optimisés, cache pleine page qui échoue plus souvent qu’on ne le croit, et configuration Varnish adaptée il y a trois ans.

Un passage d’optimisation rigoureux — audit des extensions, CSS critique, JavaScript différé, pipeline d’images, préchauffage du cache, réglage de la base de données et de Redis — permet régulièrement de faire passer une boutique Luma d’un échec à l’évaluation Core Web Vitals à une validation. Pas à un score Lighthouse de 100. À une validation, ce qui impacte réellement le classement et la conversion.

• Coût typique : 8 000–25 000 £ selon la dette d’extensions existante
• Durée typique : 4 à 8 semaines, livrées de façon incrémentale sur boutique en ligne
• Risque : faible — chaque modification est réversible et la structure de la vitrine ne change pas
• Limite : réelle. Il y a un plancher à la vitesse de Luma, et les pages catégories lourdes resteront lentes

C’est le travail que nous réalisons dans le cadre de l’optimisation de la vitesse des pages, et c’est notre point de départ sur la plupart des missions — y compris celles qui aboutissent ensuite à une migration front-end complète. Distinguer les problèmes liés au thème de ceux liés aux extensions vaut la peine avant de dépenser dix fois plus.

Option 2 : migrer vers Hyvä

Hyvä remplace la couche thème de Luma par Tailwind CSS et Alpine.js. Le catalogue, les prix, le panier, le paiement et l’administration restent inchangés — il s’agit d’un échange de front-end, pas d’une refonte complète. Cela supprime en général la majorité du JavaScript livré par Luma et produit une vitrine qui s’affiche rapidement côté serveur par défaut, sans nécessiter d’optimisation poussée.

La contrainte, et c’est la principale : toute extension avec interface vitrine doit être adaptée. Hyvä dispose d’un écosystème de modules de compatibilité couvrant les éditeurs majeurs, mais la longue traîne — votre configurateur sur mesure, ce moyen de paiement régional, le widget fidélité d’un éditeur non mis à jour depuis 2023 — constitue le vrai périmètre du projet. Nous avons vu la même boutique chiffrée à des montants très différents selon que l’agence a compté ou non les extensions.

• Coût habituel : 30 000–90 000 £ pour un catalogue de taille moyenne, plus la licence Hyvä
• Durée habituelle : 10 à 20 semaines
• Risque : modéré — la refonte du storefront impose de re-tester l’ensemble du parcours client
• Potentiel : élevé. C’est la vitesse maximale atteignable sur un storefront Magento classique.

Nous avons réalisé cette conversion suffisamment de fois pour en connaître les enjeux. Lors de notre conversion Shirt Tuning de Luma vers Hyvä, le catalogue, la tarification et la logique de paiement sont restés inchangés, seul le front-end a été remplacé — cette séparation rend la migration gérable. Sur PriceGuru, nous avons construit sur Hyvä dès le départ, ce qui est nettement plus simple que de convertir une boutique existante.

Option 3 : créer une vitrine PWA

Une architecture headless : Magento devient une API, et le storefront une application JavaScript distincte — PWA Studio, ou de plus en plus souvent un front-end Next.js sur mesure interagissant avec GraphQL. Vous gagnez une liberté totale de conception, une navigation type application, et la possibilité de placer un storefront devant plusieurs backends e-commerce.

Vous devez aussi gérer une seconde application, avec son propre hébergement, pipeline de déploiement, supervision, gestion des dépendances et — point crucial — sa propre surface SEO à optimiser manuellement. Chaque comportement natif du storefront Magento devient alors sous votre responsabilité. Les équipes métier qui pouvaient éditer une page dans l’admin ne le peuvent souvent plus.

• Coût habituel : 80 000–250 000 £ et plus
• Durée habituelle : 5 à 9 mois
• Risque : élevé — il s’agit d’une nouvelle application, pas d’un thème, et cela modifie l’organisation de votre équipe
• Potentiel : maximal, et seule option permettant d’intégrer d’autres backends que Magento par la suite

Le cadre de décision

Procédez dans cet ordre. Le premier oui honnête est généralement la bonne réponse.

1. Avez-vous réellement mesuré, ou réagissez-vous simplement à un score Lighthouse ?

Un seul test Lighthouse sur votre poste n’est pas une mesure. Consultez les données Core Web Vitals issues du terrain dans Search Console — visiteurs réels, appareils réels — et segmentez-les par gabarit. La plupart des boutiques Magento que nous auditons ont une page d’accueil qui passe et des pages catégorie qui échouent nettement : c’est un problème ciblé, pas un problème généralisé.

Si vos données terrain montrent un LCP défaillant sur 60 % des vues de pages catégorie mais que vos fiches produit sont correctes, le problème vient des pages catégorie. Il vaut mieux diagnostiquer cela avant d’envisager une migration.

2. Quelle part de la lenteur provient des extensions ?

Désactivez les extensions tierces sur un clone de préproduction, par groupe, puis mesurez à nouveau. Nous constatons régulièrement qu’un seul gestionnaire de tags, widget d’avis ou script de personnalisation génère plus de temps de blocage que tout le framework Luma. Si c’est votre cas, une migration Hyvä sera décevante : vous paierez pour une nouvelle couche de thème, mais continuerez à charger le même script problématique.

3. Allez-vous de toute façon modifier le design ?

Si un rebranding ou une refonte complète est déjà financé, l’équation change totalement. Refaire les gabarits Luma pour suivre un nouveau design coûte presque autant que les construire sous Hyvä, mais vous restez sur une pile lente. Quand le design est déjà prévu, Hyvä s’impose généralement, même si la performance seule ne l’aurait pas justifié.

4. À quoi ressemble votre inventaire d’extensions ?

Recensez chaque extension qui affiche un élément visible par le client. Pour chacune, vérifiez si une version compatible Hyvä existe, si l’éditeur est toujours actif, et si la fonctionnalité est encore utile. D’après notre expérience, une boutique avec moins de quinze extensions côté storefront migre sans difficulté ; au-delà de trente, la compatibilité devient le principal poste du projet et doit être chiffrée comme tel.

5. Avez-vous réellement besoin d’un front end séparé ?

Une PWA se justifie par des besoins que le templating Magento ne peut satisfaire : storefront multi-backends, expérience web et application partagée sur une même base de code, parcours client réellement applicatif plutôt que catalogue, ou feuille de route prévoyant de quitter Magento. Vouloir une stack JavaScript moderne n’est pas un besoin, mais une préférence — et une préférence coûteuse à financer sur le budget storefront.

Si l’architecture headless est réellement votre objectif, il vaut la peine de comparer ce que vous construiriez sur Magento avec un moteur headless dédié — nous détaillons cette comparaison dans notre travail de sélection de plateforme.

6. Pouvez-vous vous permettre de vous tromper ?

Un échec d’optimisation Luma coûte quelques semaines. Un échec de migration Hyvä coûte un trimestre et du capital confiance. Un projet PWA raté a déjà coûté des postes. Évaluez les options selon les conséquences d’un échec, pas seulement selon les bénéfices attendus.

Quand nous conseillons à nos clients de rester sur Luma

C’est la partie que les présentations commerciales omettent, donc la voici clairement. Nous recommandons de rester sur Luma lorsque :

• Les Core Web Vitals terrain sont déjà conformes et que la pression vient d’un score synthétique, pas des visiteurs réels
• La boutique est sur une version Magento à mettre à jour d’abord — faites la mise à niveau, mesurez à nouveau, puis décidez
• Une refonte de plateforme est prévue sous deux ans — inutile d’investir six chiffres dans un front-end voué à être remplacé
• Le parc d’extensions est très important et majoritairement spécifique, et le travail de compatibilité dépasserait la valeur du gain de vitesse
• Le vrai goulot d’étranglement est côté serveur — un temps-to-first-byte lent dû à une base de données sous-dimensionnée ou un cache froid n’est pas un problème de thème, et aucun front-end ne le masquera
• Les conditions commerciales rendent le risque inacceptable à court terme — il ne faut jamais migrer un storefront six semaines avant la haute saison

Ce dernier point compte plus qu’on ne le pense. Nous avons déjà refusé des migrations en septembre. Le bon projet au mauvais moment reste un mauvais projet.

Construire le modèle de retour sur investissement

Quel que soit votre choix, le raisonnement économique repose sur le même calcul. Il vous faut quatre chiffres, dont trois sont déjà connus.

1. Sessions mensuelles sur les gabarits concernés — pas sur l’ensemble du site, uniquement ceux à modifier
2. Taux de conversion actuel sur ces gabarits, par type d’appareil, car l’écart se situe presque toujours sur mobile
3. Panier moyen, toujours sur ces gabarits
4. Gain de conversion attendu — c’est la seule estimation, à traiter avec prudence

Pour ce quatrième chiffre, méfiez-vous des pourcentages annoncés sans nuance. La réalité est que l’amélioration de la vitesse corrèle avec celle de la conversion, que l’effet est plus marqué sur mobile et sur connexions lentes, et que son ampleur varie fortement selon la catégorie et le panier. Modélisez un scénario prudent et un optimiste, et basez la décision sur le prudent.

Divisez ensuite le coût du projet par le gain mensuel de marge brute dans le scénario prudent. Si la période de retour est inférieure à douze mois, la décision est solide. Entre douze et vingt-quatre mois, elle se défend si le storefront a d’autres objectifs — refonte, canal B2B, nouveau marché. Au-delà de vingt-quatre mois, vous achetez autre chose qu’un retour sur investissement.

Le coût réel de chaque option

Le coût de construction est celui que tout le monde compare. Le coût de possession est celui qui détermine si vous regretterez votre choix.

Luma n’entraîne aucun coût supplémentaire de possession, mais tout le coût de maintenance : chaque nouvelle extension risque de réintroduire le JavaScript que vous aviez éliminé, donc l’optimisation devient une charge récurrente, non un projet ponctuel.

Hyvä implique une licence annuelle et un faible coût de compatibilité continue — chaque nouvelle extension doit exister en version Hyvä, et l’offre est plus restreinte. En contrepartie, les régressions de performance sont bien plus rares, car la structure est allégée.

Une PWA vous impose une seconde application à vie : hébergement séparé, déploiements distincts, mises à jour de dépendances, correctifs de sécurité, et des compétences front-end à maintenir en interne. Prévoyez une allocation d’ingénierie continue, pas seulement un forfait de maintenance. C’est le coût que la plupart des business cases PWA omettent, et celui qui pèse à partir de la deuxième année.

Un ordre logique

Pour la plupart des commerçants Magento, la bonne séquence d’actions est peu spectaculaire :

1. Passez sur une version Magento actuelle et maintenue : tout devient plus simple et moins coûteux à partir de la 2.4.9.
2. Auditez et réduisez votre parc d’extensions : supprimez celles qui ne servent plus et remplacez celles qui ne peuvent pas être optimisées.
3. Intervenez côté serveur : taux de mise en cache, optimisation de la base de données, traitement des images, configuration de l’hébergement.
4. Reprenez les mesures des Core Web Vitals sur le terrain pour constater ce qui reste à corriger.
5. Puis décidez si l’écart restant justifie une migration du front-end.

Les commerçants qui suivent cette séquence découvrent parfois que la migration n’est pas nécessaire. Ceux qui passent directement à l’étape cinq le découvrent parfois après l’avoir déjà payée.

Si vous souhaitez un avis indépendant sur la situation réelle de votre boutique, notre équipe de développement Magento réalisera la mesure et vous indiquera en toute transparence laquelle des trois réponses vos données justifient — y compris lorsque c’est aucune pour l’instant. Cette rigueur s’applique à l’ensemble de nos prestations Magento, et pour les marques de distribution, elle s’amortit généralement dès le premier trimestre après lancement.

Mesurez avant de demander un devis

Avant tout investissement, le plus utile est d’identifier si vos problèmes viennent du thème. Nous réalisons cet audit et vous donnons la réponse, même si cela signifie que vous n’avez pas besoin de nous. Contactez notre équipe — réponse sous un jour ouvré.