Où se situe Magento 2 dans le paysage des plateformes ?

Commençons par tordre le cou à une lecture trop rapide. Par nombre de boutiques, Magento arrive en 3e position mondiale, autour de 5 à 8 % de part de marché selon les méthodes de comptage, loin derrière WooCommerce (~33 %) et Shopify (~26 %) (sources : mgt-commerce, gyntrix, données Q1 2026 issues de StoreLeads, BuiltWith, 6sense, W3Techs). Ce chiffre est exact, mais il raconte une histoire trompeuse s’il est pris seul.

Pourquoi ce classement trompe : la valeur générée ne suit pas le nombre de boutiques. Magento traite un volume d’affaires annuel (GMV) estimé autour de 173 milliards de dollars, tiré par de gros marchands. Et surtout, parmi les 1 000 premiers e-commerçants américains, Magento équipe environ 20 % des boutiques — soit près de trois fois sa part mondiale (source : mgt-commerce, avril 2026). Autrement dit : peu de boutiques en proportion, mais parmi les plus grosses.

La tendance, sans la cacher : un déclin en nombre, une concentration vers le haut

Soyons transparents, car c’est un point qu’on lit rarement dans la bouche d’un prestataire Magento : le nombre de boutiques actives a reculé, passant d’environ 162 000 en 2021 à près de 111 500 au premier trimestre 2026 (source : StoreLeads via mgt-commerce). Trois causes principales expliquent ce recul : les petits marchands migrent vers Shopify pour sa simplicité, la fin de vie de Magento 1 (juin 2020) a entraîné fermetures et migrations, et le coût d’Adobe Commerce pousse une partie du mid-market vers d’autres solutions.

Mais ce déclin en nombre s’accompagne d’une concentration vers le haut de gamme. Magento perd les petits projets — pour lesquels il était de toute façon surdimensionné — et conserve sa place là où il excelle : l’entreprise et le mid-market exigeant. Pour qui cherche un expert Magento, c’est plutôt rassurant : la plateforme se recentre sur les projets où elle apporte une vraie valeur.

Qui utilise Magento 2 aujourd’hui ?

Des marques dont l’e-commerce a des exigences réelles de catalogue, d’international ou de B2B. Parmi celles confirmées par des relevés techniques récents : Samsung (sa boutique shop.samsung.com), HP, Vodafone, American Express, Nespresso, Peugeot, Fnac — le leader français de l’électronique et des médias — Atlassian, Hanes. Et dans le luxe et l’automobile : Christian Louboutin, Bulgari, Ford (accessoires et pièces), Helly Hansen, qui pilote une trentaine de boutiques internationales depuis Magento, Olympus, Jaguar Land Rover (sources : TechnologyChecker, février 2026 ; recoupements Elogic, Meetanshi).

Une précision d’honnêteté : plusieurs listes qui circulent citent Nike ou le site corporate de Coca-Cola comme utilisateurs de Magento. C’est à nuancer — d’après les relevés techniques de TechnologyChecker, Nike fonctionne sur une infrastructure e-commerce développée sur mesure, et le site principal de Coca-Cola n’utilise pas Magento (seules certaines entités régionales du groupe le font). Nous préférons citer des exemples vérifiables plutôt que de recopier des listes approximatives.

Le cas français : Magento vs PrestaShop, deux mondes qui ne se battent pas sur le même terrain

En France, la vraie comparaison n’est pas Magento contre Shopify, mais Magento contre PrestaShop — deux plateformes open source PHP, au concurrent le plus structurellement proche. Et là, les données françaises sont éclairantes. Une analyse portant sur 155 000 e-commerçants français vérifiés au registre SIREN (source : lebot.in, juin 2026) montre un contraste frappant.

La lecture est limpide : PrestaShop domine massivement en nombre (il est né en France, les marchands français lui sont fidèles), mais Magento génère en moyenne 8,4 fois plus de chiffre d’affaires par boutique. Ce ne sont pas deux concurrents qui se disputent les mêmes clients — ce sont deux segments différents. PrestaShop est le cheval de trait des PME françaises tournées vers le marché national ; Magento est la plateforme des entreprises établies, souvent internationales. Choisir entre les deux, ce n’est pas choisir « le meilleur », c’est identifier à quel segment appartient votre projet.

Pour un nouveau projet : les raisons solides de choisir Magento 2

Un mot sur les standards techniques actuels : en 2026, le thème Hyvä et les architectures headless / API-first sont devenus la norme du secteur pour les nouveaux projets, une part importante des développements récents adoptant une approche découplée. C’est aussi ce qui positionne bien Magento pour le commerce piloté par IA, grâce à la flexibilité de ses API.

Et surtout : quand NE PAS choisir Magento

C’est peut-être la partie la plus utile de cet article, et celle qu’un prestataire honnête se doit d’écrire. Magento n’est pas le bon choix pour tout le monde.

En résumé

Magento 2 en 2026, ce n’est plus la plateforme qu’on choisit par défaut — c’est celle qu’on choisit pour de bonnes raisons. Elle a perdu les projets simples, qu’elle n’aurait jamais dû accueillir, et conservé sa domination là où elle compte : catalogue complexe, multi-région, B2B, gros volumes, contrôle total. Si votre projet coche ces cases et dépasse le seuil de rentabilité, peu de plateformes rivalisent. S’il ne les coche pas, un bon prestataire vous orientera vers plus adapté — et c’est aussi ça, le rôle d’un expert.

L’article Magento 2 en 2026 : pour qui, pourquoi, et quand ne pas le choisir est apparu en premier sur eBusiness360.

Un avertissement avant de commencer : toutes les commandes ci-dessous s’exécutent en SSH sur votre serveur, depuis la racine de votre installation Magento. Si vous n’avez pas d’accès SSH ou si vous n’êtes pas sûr de ce que fait une commande, arrêtez-vous et appelez quelqu’un. Une mauvaise manipulation sur une boutique en production peut aggraver la panne. Toutes ces commandes concernent Magento 2.4.x — pas Magento 1, dont les manipulations sont radicalement différentes et obsolètes.

Réflexe n°0 — activer l’affichage des erreurs pour comprendre

Avant de tenter quoi que ce soit à l’aveugle : une page blanche ou une erreur générique ne vous dit rien. Passez en mode développeur pour voir l’erreur réelle, ou consultez directement les logs.

# Voir le mode actuel
php bin/magento deploy:mode:show

# Consulter les derniers rapports d'erreur
tail -n 50 var/log/exception.log
tail -n 50 var/log/system.log
ls -lt var/report/ | head

Le fichier le plus récent dans var/report/ contient souvent l’ID d’erreur affiché à l’écran et la trace complète. C’est votre point de départ. Ne passez jamais une boutique de production en mode développeur de façon permanente — uniquement le temps du diagnostic, puis revenez en production.

Panne n°1 — Erreur 503 / le site est bloqué en maintenance

Symptôme : le site affiche « Service Temporarily Unavailable » ou une page de maintenance, front et back inaccessibles. Cause la plus fréquente : un flag de maintenance qui n’a pas été retiré après une opération (souvent un setup:upgrade interrompu).

# Solution propre
php bin/magento maintenance:disable

# Si la commande ne répond pas, supprimer le flag manuellement
rm -f var/.maintenance.flag

Si le 503 persiste après ça, vérifiez que ce n’est pas votre serveur web ou Varnish qui renvoie l’erreur — dans ce cas le problème est côté infrastructure, pas côté Magento.

Panne n°2 — Page blanche ou erreur 500 après un déploiement

Symptôme classique après un setup:upgrade ou un déploiement : le site charge une page blanche, ou le front s’affiche sans style (page « cassée », sans CSS ni images). Dans 9 cas sur 10, c’est le contenu statique qui n’a pas été redéployé.

# La séquence de récupération après un setup:upgrade
php bin/magento setup:di:compile
php bin/magento setup:static-content:deploy -f fr_FR en_US
php bin/magento cache:flush

Adaptez les codes langue (fr_FR en_US) à ceux réellement configurés sur votre boutique. Si vous utilisez un thème spécifique, précisez-le avec --theme. Point important : la commande setup:static-content:deploy ne peut pas combiner --theme et --exclude-theme dans le même appel — il faut choisir l’un ou l’autre.

Panne n°3 — « Access Denied » en accédant à l’admin

Symptôme : vous êtes connecté au back-office mais chaque page affiche « Access Denied », ou un menu entier a disparu. Cause fréquente : les rôles ACL n’ont pas été correctement régénérés après une mise à jour ou l’ajout d’un module.

# Régénérer et vider
php bin/magento cache:flush
php bin/magento setup:upgrade
php bin/magento cache:flush

Si le problème vient d’un rôle utilisateur mal configuré, allez dans System → Permissions → User Roles, ouvrez le rôle concerné, et vérifiez que les ressources autorisées (« Role Resources ») sont bien cochées. Déconnexion/reconnexion après changement.

Panne n°4 — Mot de passe admin oublié / plus aucun accès

Symptôme : vous ne pouvez plus vous connecter au back-office et la récupération par email ne fonctionne pas. La solution Magento 2 n’est pas de modifier le mot de passe directement en base de données (contrairement à ce qu’on lit sur d’anciens tutoriels Magento 1 — le hash Magento 2 est bien plus complexe et une modification manuelle corromprait le compte). La bonne méthode : créer un nouvel admin en ligne de commande.

php bin/magento admin:user:create \
  --admin-user="nouveladmin" \
  --admin-password="MotDePasseFort123!" \
  --admin-email="admin@votredomaine.com" \
  --admin-firstname="Prenom" \
  --admin-lastname="Nom"

Le mot de passe doit contenir au moins 7 caractères avec lettres et chiffres, sinon Magento le refuse. Une fois connecté avec ce nouveau compte, vous pourrez réinitialiser l’ancien depuis l’interface.

Panne n°5 — Le site est devenu très lent d’un coup

Symptôme : pas de panne franche, mais des temps de chargement qui explosent. Trois causes à vérifier dans l’ordre.

Panne n°6 — Erreur après l’installation d’une extension

Symptôme : vous venez d’installer un module et le site plante. La priorité est de désactiver le module fautif pour rétablir le service, puis de diagnostiquer à froid.

# Désactiver le module problématique
php bin/magento module:disable Vendor_ModuleName
php bin/magento setup:upgrade
php bin/magento setup:di:compile
php bin/magento cache:flush

Remplacez Vendor_ModuleName par le nom réel du module (visible dans app/etc/config.php ou dans le message d’erreur). Ne supprimez pas les fichiers du module manuellement — module:disable est propre et réversible.

Panne n°7 — Impossible de se connecter (cookies rejetés) après changement de domaine

Symptôme : après un changement de domaine ou une migration, la connexion admin tourne en boucle — vous entrez vos identifiants et revenez à la page de login. Le domaine de cookie configuré ne correspond plus à l’URL réelle.

# Mettre à jour les URLs de base
php bin/magento config:set web/unsecure/base_url https://www.nouveaudomaine.com/
php bin/magento config:set web/secure/base_url https://www.nouveaudomaine.com/

# Purger le domaine de cookie hérité (via base de données)
# ATTENTION : sauvegardez la base avant toute requête SQL
php bin/magento cache:flush

Si le blocage persiste, le domaine de cookie est probablement figé dans core_config_data (chemins web/cookie/cookie_domain). La suppression de ces lignes en base résout le problème — mais toute manipulation SQL directe doit être précédée d’une sauvegarde complète de la base.

La commande qui résout une grande partie des cas

Si vous ne deviez retenir qu’une séquence, c’est celle-ci. Après la plupart des opérations qui tournent mal, ce nettoyage complet remet souvent les choses d’aplomb :

php bin/magento setup:upgrade
php bin/magento setup:di:compile
php bin/magento setup:static-content:deploy -f fr_FR
php bin/magento cache:flush

Attention : setup:di:compile et static-content:deploy peuvent prendre plusieurs minutes et générer une brève indisponibilité. À exécuter de préférence en dehors des heures de forte affluence, et jamais à l’aveugle sur une boutique en production si vous n’êtes pas sûr de vous.

FAQ

Je n’ai pas d’accès SSH — comment faire ?

La quasi-totalité de ces commandes nécessitent un accès SSH au serveur. Sans lui, vos options sont très limitées — vous pouvez parfois vider le cache depuis le back-office (System → Cache Management) si celui-ci est accessible, mais c’est tout. Si votre site est en panne et que vous n’avez pas d’accès SSH, contactez votre hébergeur ou un prestataire Magento en urgence.

Ces commandes fonctionnent-elles sur toutes les versions de Magento 2 ?

Oui, sur l’ensemble des versions 2.4.x. La syntaxe des commandes CLI Magento 2 est stable depuis plusieurs versions. En revanche, elles ne s’appliquent pas à Magento 1, dont l’architecture et les commandes sont entièrement différentes — Magento 1 n’est plus supporté depuis juin 2020 et ne devrait plus être en production.

Dois-je sauvegarder avant d’exécuter ces commandes ?

Pour les commandes de cache et de réindexation, le risque est faible. Pour tout ce qui touche à la base de données (requêtes SQL, changement de configuration critique) ou à la structure (setup:upgrade), une sauvegarde préalable de la base et des fichiers est fortement recommandée. Sur une boutique de production, la règle est simple : sauvegarde systématique avant toute opération non triviale.

L’article Mon site Magento est en panne : le guide de dépannage d’urgence (Magento 2) est apparu en premier sur eBusiness360.

Précision méthodologique : il n’existe pas de statistique publique fiable classant « les thèmes les plus installés » sur Magento 2. Les seuls chiffres d’adoption documentés concernent Hyvä, et ils varient selon les sources. Cet article ne propose donc pas un classement, mais un panorama des thèmes les plus répandus et de ce qu’ils apportent réellement.

Deux familles de thèmes, deux philosophies opposées

Avant de comparer, il faut comprendre une distinction fondamentale. Le paysage des thèmes Magento 2 s’est structuré autour de deux approches radicalement différentes (source : WeltPixel, avril 2026 ; mgt-commerce, avril 2026).

Cette distinction change tout : comparer Porto et Hyvä sur les « fonctionnalités incluses » n’a pas de sens, puisque Hyvä est conçu pour être une base minimale et rapide, pas un catalogue de fonctions.

Porto — le polyvalent riche en fonctionnalités

Porto est le thème Magento 2 le plus téléchargé sur ThemeForest, avec plus de 20 layouts de page d’accueil, pour un prix d’environ 129 $ (source : WeltPixel, avril 2026). Il s’adapte à de nombreux secteurs — mode, électronique, mobilier, accessoires — et embarque nativement les fonctionnalités que la plupart des marchands attendent.

La limite est structurelle et honnête : tout thème multipurpose devient lourd si l’on active trop de démos, scripts, sliders ou extensions. Porto contient beaucoup plus de code que Hyvä et se charge donc moins vite (source : liquidweb, mai 2026 ; humcommerce, février 2026). C’est le compromis assumé du thème « riche » : polyvalence contre performance brute.

Hyvä — la performance avant tout

Hyvä a été créé par Willem Wigman, développeur néerlandais, et lancé en 2021 (source : Qarbi, avril 2026). Son principe : remplacer la pile JavaScript historique de Luma par Alpine.js et Tailwind CSS, réduisant le poids du frontend de l’ordre de 80 à 90%. En pratique, le frontend passe d’environ 900 KB (Luma) à 100-150 KB, avec des scores Lighthouse fréquemment au-dessus de 90 (source : mgt-commerce, avril 2026).

Bonne nouvelle côté budget : le thème Hyvä est désormais gratuit et open source. Annoncé le 6 novembre 2025 lors du Meet Magento Netherlands et effectif depuis le 10 novembre 2025, Hyvä Theme est relicencié sous OSL-3.0 + AFL-3.0 — les mêmes licences que Magento Open Source — et disponible librement sur GitHub (source : blog officiel Hyvä, hyva.io, 6 novembre 2025). Il était auparavant commercialisé sous licence payante annuelle par boutique. Attention toutefois : seul le thème est gratuit. Les autres produits de la gamme restent payants — Hyvä UI (250 € one-off), Hyvä Checkout (1 000 €), Hyvä Commerce (3 000 €/an) et Hyvä Enterprise (7 500 €/an) (source : hyva.io, tarifs consultés en juillet 2026).

La contrepartie de Hyvä est réelle et doit être posée clairement : ce n’est pas une solution clé en main. À éviter si votre équipe n’est pas à l’aise avec Tailwind CSS, si vous voulez un thème prêt à l’emploi avec des démos, ou si vous dépendez d’extensions tierces qui n’ont pas encore de module de compatibilité Hyvä (source : WeltPixel, avril 2026). La compatibilité Page Builder est en revanche complète depuis la version 1.3 (source : mgt-commerce, avril 2026).

C’est une conséquence directe de la reconstruction du frontend : parce que Hyvä remplace la couche Luma, une extension qui affiche quelque chose côté client ne fonctionne pas telle quelle — elle a besoin d’un module de compatibilité Hyvä spécifique. La bonne nouvelle : les éditeurs d’extensions sérieux indiquent désormais explicitement la compatibilité Hyvä sur leurs fiches produit. Avant toute migration vers Hyvä, il faut donc auditer chacune de vos extensions et vérifier qu’une version compatible existe — sans quoi la fonctionnalité concernée devra être redéveloppée.

Breeze (Swissup) — le compromis vitesse sans reconstruction

Breeze, développé par Swissup Labs, occupe une position intermédiaire intéressante : il remplace le frontend JavaScript de Magento pour gagner en vitesse, mais sans imposer la reconstruction complète qu’exige Hyvä. La brique Breeze de base est gratuite depuis son lancement en 2022 (source : swissuplabs.com, consulté en juillet 2026).

La gamme Swissup Breeze se décline en plusieurs produits (source : swissuplabs.com/breeze-extensions-and-templates.html, consulté en juillet 2026 — tarif exact à vérifier sur le site officiel car susceptible d’évoluer) :

L’intérêt de Breeze : obtenir un gain de performance significatif tout en restant dans un environnement plus familier que Hyvä, sans réécrire tout le frontend en Tailwind. C’est une voie médiane pour les boutiques qui veulent accélérer sans lancer un chantier de migration lourd.

Lequel pour quel projet ?

Un point que tous les comparatifs oublient : la performance réelle ne dépend pas que du thème. Elle dépend aussi de l’hébergement, du cache, des extensions installées, du poids des images, de la qualité du développement et de la maintenance (source : liquidweb, mai 2026). Un excellent thème sur un serveur mal configuré donnera de mauvais résultats. Le thème est une brique — pas une garantie.

FAQ

Peut-on changer de thème sans tout casser sur une boutique existante ?

Changer de thème Luma-based vers un autre thème Luma-based (ex : Luma vers Porto) est relativement direct. Passer vers Hyvä est un chantier de migration à part entière : le frontend étant reconstruit en Tailwind/Alpine, vos personnalisations et l’affichage de vos extensions doivent être refaits ou vérifiés un à un. Prévoir un environnement de staging et un audit de compatibilité des extensions avant toute décision.

Un thème gratuit vaut-il un thème payant ?

Ça dépend de ce que vous cherchez. Un thème gratuit bien maintenu (Breeze Evolution, ou Hyvä si son modèle open source est confirmé) peut parfaitement convenir. Avant de choisir un thème gratuit, vérifiez le support, l’historique des mises à jour, la documentation et la compatibilité avec votre version de Magento (source : liquidweb, mai 2026). Un thème sans mise à jour depuis plus de 6 mois est un signal d’alerte.

Le thème influence-t-il vraiment le référencement ?

Oui, indirectement mais réellement. Les signaux d’expérience de page de Google (Core Web Vitals) influencent le classement, et ces scores dépendent directement de la vitesse et de la légèreté du frontend — donc du thème (source : WeltPixel, avril 2026). C’est pour cela que le choix du thème est une décision business, pas seulement esthétique.

L’article Thèmes Magento 2 : Porto, Hyvä, Breeze — ce qu’ils apportent vraiment est apparu en premier sur eBusiness360.

Note de transparence : je n’ai pas encore déployé Mage-OS en production sur les boutiques que je gère. Cet article est une analyse technique basée sur la documentation officielle et le code source, pas un retour d’expérience terrain. Je vous le dis parce que la différence compte.

Mage-OS, c’est quoi exactement ?

Mage-OS est une distribution indépendante et à but non lucratif de Magento Open Source, portée par l’association Mage-OS et une communauté de contributeurs (netz98, Elgentos, Swissup, integer_net, entre autres). Le projet n’est affilié ni à Adobe ni à Magento. L’idée : garantir la pérennité de Magento Open Source en dehors des décisions stratégiques d’Adobe, et livrer des fonctionnalités que la communauté attend depuis longtemps.

Mage-OS 3.0 est construit sur Magento Open Source 2.4.9. Autrement dit : vous gardez tout ce que vous connaissez de Magento, plus une couche de fonctionnalités et d’outillage. La prochaine version fonctionnelle est prévue pour octobre 2026, et Mage-OS 3.1.0 est déjà sorti le 18 juin 2026 comme mise à jour drop-in à faible risque. (Source : mage-os.org, release notes du 18 mai et 18 juin 2026.)

Ce que Mage-OS 3 apporte que Magento n’a pas

Deux autres points valent d’être signalés. D’abord un indicateur « Update available » directement dans le footer admin, qui vérifie en arrière-plan vos dépôts Composer. Ensuite une distribution Minimale (mage-os/product-minimal-edition) : une installation allégée à environ 98 packages de base, où vous n’ajoutez que ce que vous utilisez. Intéressant pour les équipes qui veulent optimiser chaque milliseconde, mais qui demande de savoir composer sa propre stack.

L’argument qui compte : l’indépendance vis-à-vis d’Adobe

Le vrai différenciateur n’est pas dans les fonctionnalités — c’est dans le modèle. Mage-OS maintient un miroir public (mirror.mage-os.org) présenté comme un remplacement direct de repo.magento.com, installable sans identifiants Adobe Marketplace. (Source : release note officielle du 18 mai 2026.) Pour quiconque a déjà galéré avec les clés d’authentification Adobe et les changements de conditions de Marketplace, c’est un argument concret.

Sur la sécurité, Mage-OS incorpore les patches de sécurité de Magento Open Source dans ses propres releases — la version 2.3.0 (13 mai 2026) a par exemple intégré les correctifs de sécurité de 2.4.8-p5. Le projet a aussi traité une vulnérabilité critique d’upload dans sa version 2.2.1 du 18 mars 2026. (Source : mage-os.org, release notes.) Je ne dispose pas de données comparatives fiables sur les délais de réponse aux failles entre Mage-OS et Adobe — je ne vais donc pas affirmer que l’un est plus rapide que l’autre sans preuve.

Les breaking changes à connaître avant tout upgrade

Le passage Symfony 6 → 7 est le point le plus sensible : si vous utilisez des extensions tierces qui étendent des commandes CLI ou manipulent les composants Symfony, elles risquent de casser. À auditer impérativement avant toute migration.

Faut-il migrer ? Mon analyse

Ma position, sans détour : Mage-OS est un projet sérieux, porté par des acteurs reconnus de l’écosystème Magento, et son existence est une bonne nouvelle pour tout le monde — y compris ceux qui resteront sur Magento Open Source, car elle met une pression saine sur Adobe. Mais migrer une boutique en production n’est jamais anodin. Pour une boutique qui fonctionne sans friction, le principe « on ne change pas une équipe qui gagne » s’applique. Pour un nouveau projet, ou une boutique qui souffre de la dépendance Adobe, Mage-OS mérite une évaluation sérieuse.

La bonne démarche : tester Mage-OS sur un environnement de staging, cloner votre boutique existante, auditer la compatibilité de vos extensions avec Symfony 7 et PHP 8.3+, et mesurer ce que vous gagnez réellement. C’est exactement le type d’évaluation qu’on peut mener ensemble avant toute décision.

FAQ

Mage-OS est-il compatible avec mes extensions Magento actuelles ?

En théorie oui, puisque Mage-OS 3.0 est basé sur Magento Open Source 2.4.9 et conserve la même architecture. En pratique, le passage à Symfony 7 et PHP 8.3 minimum peut casser certaines extensions non maintenues. Il faut auditer chaque extension tierce avant migration — il n’y a pas de réponse universelle.

Peut-on revenir à Magento Open Source après avoir migré vers Mage-OS ?

Je ne dispose pas d’information officielle claire sur une procédure de retour arrière documentée. Comme pour toute migration, la sauvegarde complète avant opération et un environnement de staging sont indispensables. À vérifier auprès de la documentation Mage-OS ou via un test réel avant de s’engager sur une boutique de production.

Mage-OS est-il gratuit ?

Oui — c’est une distribution open source à but non lucratif, comme Magento Open Source. Vous ne payez pas de licence. Les coûts restent ceux de l’hébergement, du développement et de la maintenance, comme sur n’importe quelle installation Magento self-hosted.

L’article Mage-OS 3 : le fork communautaire de Magento — faut-il s’y intéresser ? est apparu en premier sur eBusiness360.

Ce bug a mis 17 mois à obtenir un patch officiel dans le Quality Patches Tool d’Adobe, sous la référence ACSD-63326. Il est corrigé nativement en 2.4.8. C’est un exemple parfait de ce que sont les quality patches — et de pourquoi savoir les utiliser est une compétence clé dans la maintenance d’une boutique Magento.

Quality patches vs patches de sécurité — la distinction fondamentale

Adobe publie deux types de correctifs pour Magento, qu’il ne faut pas confondre :

Le QPT est livré sous forme de package Composer et s’installe en une commande. Il permet de lister les patches disponibles pour votre version, de les appliquer et de les annuler sans toucher au code core de Magento.

# Installer le QPT
composer require magento/quality-patches

# Lister les patches disponibles pour votre version
./vendor/bin/magento-patches status

# Appliquer un patch
./vendor/bin/magento-patches apply ACSD-63326

# Annuler un patch
./vendor/bin/magento-patches revert ACSD-63326

ACSD-63326 — Calendar.php et ICU 74+ (le bug du fil rouge)

La cause : la bibliothèque ICU, utilisée par l’extension PHP intl, a supprimé les balises AM/PM pour les langues qui n’en ont pas besoin (format 24h, comme le français). Magento cherchait $localeData['calendar']['gregorian']['AmPmMarkers']['0'], obtenait null, et PHP 8 transformait cet accès en exception fatale.

Trois solutions selon votre contexte :

CosmicSting — CVE-2024-34102 (CVSS 9.8)

CosmicSting est la vulnérabilité Magento la plus exploitée de 2024. Une faille d’injection XML externe (XXE) dans l’API REST permettait à un attaquant non authentifié de lire des fichiers arbitraires sur le serveur — dont le fichier app/etc/env.php qui contient la clé de chiffrement. Avec cette clé, l’attaquant pouvait forger des tokens JWT valides et obtenir un accès admin complet, puis enchaîner avec une exécution de code à distance via une faille glibc (CVE-2024-2961).

Cette vulnérabilité a conduit à plus de 4 275 boutiques compromises, réparties entre sept groupes d’attaquants distincts. Elle affectait toutes les versions de Magento jusqu’à 2.4.7 inclus avant le patch.

Un point crucial souvent négligé : appliquer le patch ne suffit pas si votre boutique a déjà été exposée avant. La clé de chiffrement peut avoir été lue. Il faut dans ce cas effectuer une rotation de clé via php bin/magento encryption:key:change (disponible nativement en 2.4.8, nécessite un patch sur les versions antérieures) et vérifier l’absence de backdoor dans les fichiers.

SessionReaper — CVE-2025-54236 (CVSS 9.1)

Plus récent et tout aussi préoccupant : SessionReaper est une faille de validation d’entrée dans l’API REST de Magento qui permettait à un attaquant de détourner des comptes clients et d’obtenir un accès serveur par exécution de code à distance. Plus de 250 boutiques ont été compromises dans les 24 heures suivant la publication du patch en octobre 2025. Six semaines après la sortie du correctif, 62% des boutiques Magento restaient encore vulnérables.

phpspreadsheet — CVEs sur la librairie d’import/export

Magento utilise la bibliothèque phpoffice/phpspreadsheet pour toutes les opérations d’import et d’export de données (produits, clients, commandes). Cette bibliothèque a été affectée par plusieurs CVEs en 2024-2025, dont des failles permettant l’injection de formules dans les fichiers Excel générés (CSV injection) et des failles de traversée de répertoire.

Ces vulnérabilités ne sont pas des patches Magento à proprement parler — elles se corrigent en mettant à jour la version de phpspreadsheet dans le composer.json de votre projet. La version 1.30.4+ (pour Magento 2.4.7 et antérieur) ou 2.x (pour les projets qui peuvent migrer) corrige les CVEs documentées. C’est un point systématiquement vérifié dans nos interventions de maintenance.

ACSD-51892 — Config files chargés plusieurs fois

Ce patch corrige un problème de performance où les fichiers de configuration Magento étaient chargés plusieurs fois lors d’un même cycle de requête, entraînant une dégradation notable des temps de réponse de l’admin sur les boutiques avec une configuration volumineuse. Il a été absorbé nativement dans les patches 2.4.6-p2 et 2.4.6-p3 — si vous êtes encore sur 2.4.6-p1, ce patch seul peut régler des lenteurs inexpliquées dans le back-office.

Tableau récapitulatif — patches par version

Comment utiliser le QPT efficacement

Quelques règles de bonne pratique issues de notre usage quotidien du QPT sur des boutiques en production :

La vraie difficulté : savoir quels patches s’appliquent à vous

Le QPT liste des centaines de patches disponibles. La commande ./vendor/bin/magento-patches status filtre automatiquement ceux compatibles avec votre version — mais elle ne vous dit pas lesquels vous concernent réellement. Un patch qui corrige un bug sur les produits téléchargeables n’est pas pertinent si vous ne vendez que du physique. Un patch de performance sur GraphQL n’a pas d’intérêt si vous n’utilisez pas d’application headless.

C’est là que l’expérience terrain fait la différence. Savoir identifier les patches pertinents selon la configuration d’une boutique spécifique — ses extensions, ses personnalisations, son usage de l’API — c’est une partie non négligeable du travail de maintenance proactive.

FAQ

Les patches QPT sont-ils écrasés lors d’un upgrade Magento ?

Les patches QPT modifient les fichiers vendor via un mécanisme de patching Composer — ils sont donc effectivement écrasés lors d’un composer update. C’est une des raisons pour lesquelles il faut documenter les patches appliqués et vérifier, après chaque upgrade, si les patches sont toujours nécessaires (parfois le bug est corrigé nativement dans la nouvelle version) et si oui, les réappliquer.

Comment savoir si mon site a déjà été compromis via CosmicSting ?

Les indicateurs à vérifier : présence de fichiers PHP suspects dans pub/media/ ou pub/static/, comptes admin créés récemment que vous ne reconnaissez pas, modifications dans les blocs CMS de la page checkout. L’outil Sansec Ecomscan est une référence pour détecter les traces de compromission sur une boutique Magento. Si vous avez un doute, une analyse approfondie par un prestataire spécialisé est recommandée avant de simplement appliquer le patch.

Faut-il appliquer tous les patches ACSD disponibles pour ma version ?

Non — et Adobe le déconseille explicitement. Appliquer un grand nombre de patches augmente la complexité du code et rend les futurs upgrades plus difficiles. La bonne approche est de cibler les patches qui correspondent à des bugs réellement rencontrés sur votre boutique, ou aux quelques patches de performance/qualité reconnus comme bénéfiques pour la majorité des installations.

L’article Quality Patches Magento 2 : les correctifs incontournables sur 2.4.6 → 2.4.8 est apparu en premier sur eBusiness360.

Si vous gérez une boutique Magento, vous devez comprendre ce que cette version change — même si vous ne migrez pas tout de suite. Ce guide couvre l’intégralité des changements depuis Magento 2.4.8, avec notre analyse terrain sur ce que ça implique concrètement.

Vue d’ensemble — pourquoi 2.4.9 est différente

Les nouveaux prérequis infrastructure — le changement le plus impactant

Avant toute chose, il faut comprendre que la migration vers 2.4.9 est avant tout une migration d’infrastructure. Si votre serveur ne remplit pas les nouvelles exigences, vous ne pouvez pas migrer — indépendamment de l’état de votre code Magento.

PHP 8.5 — première mondiale pour Magento

Magento 2.4.9 est le premier release Magento à supporter PHP 8.5 dès le jour de sa sortie. C’est une première dans l’histoire de la plateforme — habituellement, le support d’une nouvelle version PHP arrivait plusieurs mois après la sortie de PHP lui-même. PHP 8.4 reste entièrement supporté. PHP 8.3 est supporté uniquement pour les migrations en cours, pas pour de nouveaux déploiements. PHP 8.2 est définitivement supprimé.

MySQL 8.0 supprimé — et ce n’est pas une surprise

MySQL 8.0 a atteint sa fin de vie officielle le 30 avril 2026. Magento 2.4.9 ne le supporte donc plus. Si votre serveur tourne encore sur MySQL 8.0 — ce qui est très courant sur les installations hébergées depuis 2020-2022 — la migration vers 2.4.9 implique obligatoirement une montée de version de votre base de données vers MySQL 8.4 LTS ou MariaDB 11.4 LTS.

Valkey 8 remplace Redis — les détails

En 2024, Redis a modifié sa licence pour passer d’un modèle open source à un modèle propriétaire. La Linux Foundation a réagi en forgeant Valkey, un fork open source 100% compatible avec Redis au niveau protocole. Magento 2.4.9 adopte officiellement Valkey 8 comme backend de cache.

La bonne nouvelle : Valkey est compatible à l’identique avec Redis au niveau des commandes et du protocole wire. La migration se fait en remplaçant le serveur Redis par un serveur Valkey, sans toucher à la configuration Magento. Pour les nouvelles installations, Valkey est le choix par défaut. Redis 7.2 reste techniquement fonctionnel mais n’est plus supporté officiellement.

Apache ActiveMQ Artemis — alternative à RabbitMQ

Magento 2.4.9 introduit le support d’Apache ActiveMQ Artemis comme alternative à RabbitMQ pour la gestion des files de messages (message queues). RabbitMQ reste supporté et fonctionnel — c’est un ajout, pas un remplacement. Pour les équipes qui préfèrent l’écosystème Apache ou qui ont déjà ActiveMQ dans leur infrastructure, c’est une option bienvenue.

Les trois remplacements de composants core

C’est le cœur de ce qui rend 2.4.9 si différente des versions précédentes. Trois bibliothèques historiques du framework Magento sont remplacées par des alternatives modernes.

Le remplacement de Laminas MVC — ce que ça signifie vraiment

Laminas MVC (anciennement Zend Framework) était le framework MVC sur lequel Magento s’appuyait depuis ses origines. Son remplacement par une implémentation MVC native PHP est le changement le plus structurant pour les développeurs.

Concrètement, tout module ou extension qui étend des classes comme Laminas\Mvc\Controller\AbstractActionController, Laminas\Http\Request ou qui utilise le système d’événements Laminas devra être mis à jour. La plupart des grandes extensions tierces (Amasty, Mageworx, Mageplaza) ont déjà annoncé des versions compatibles. Les développements spécifiques à votre boutique sont à auditer avant la migration.

Symfony 7.4 LTS — l’alignement avec l’écosystème PHP moderne

Magento utilisait déjà des composants Symfony (Console, EventDispatcher, DependencyInjection). Avec 2.4.9, l’ensemble des dépendances Symfony passe à la version 7.4 LTS, qui est supportée jusqu’en novembre 2027. C’est un alignement bienvenu qui simplifie la maintenance et apporte les performances de la branche Symfony 7.

Pour les développeurs qui utilisent des composants Symfony dans leurs modules custom, c’est une mise à jour à anticiper. Les APIs Symfony 7 ont évolué par rapport à la v6 sur certains composants — consulter le guide de migration Symfony officiel avant de démarrer.

Sécurité — les correctifs embarqués

Magento 2.4.9 inclut les correctifs du bulletin de sécurité APSB26-05, qui couvre notamment la correction définitive de la faille PolyShell dans le core (upload de fichiers malveillants via les options de commande). C’est le correctif natif que la communauté attendait depuis plusieurs années.

Braintree — nouvelles méthodes de paiement locales

Le module Braintree natif de Magento reçoit des améliorations significatives dans la version 2.4.9 :

• Nouvelles méthodes de paiement locales — ajout de méthodes régionales selon les marchés (Pay by Bank, méthodes locales européennes)
• Meilleure gestion des paiements récurrents — amélioration du support des abonnements et paiements fractionnés
• Mise à jour du SDK Braintree — compatibilité avec les dernières APIs PayPal/Braintree

Si votre boutique utilise Braintree natif (et non une extension tierce), ces améliorations sont disponibles sans développement supplémentaire après migration.

La nouvelle commande Composer — à ne pas oublier

C’est un point pratique critique que beaucoup ratent lors des premières tentatives de migration : la commande Composer a changé pour Magento 2.4.9.

# Ancienne commande — produit des erreurs de résolution sur 2.4.9
composer require magento/product-community-edition=2.4.9 --no-update

# Nouvelle commande requise pour 2.4.9
composer require-commerce magento/product-community-edition=2.4.9 --no-update
composer update --with-all-dependencies

Si vous avez des scripts de déploiement automatisés ou des pipelines CI/CD, mettez-les à jour avant de lancer la migration. L’ancienne commande produit des erreurs de résolution de dépendances sans message d’erreur très explicite — source de confusion pour beaucoup d’équipes.

Le nouveau calendrier de releases Adobe

À partir de 2026, Adobe a restructuré le rythme de publication de Magento. La prévisibilité est enfin au rendez-vous :

Chaque version 2.4.x bénéficie d’un support de 3 ans à partir de sa date de sortie. La 2.4.9 est donc supportée jusqu’en mai 2029.

Plan de migration recommandé depuis 2.4.8

Vous êtes sur 2.4.8 et vous envisagez 2.4.9 ? Voici la séquence à suivre pour une migration réussie.

Faut-il migrer vers 2.4.9 maintenant ?

La réponse honnête dépend de votre situation.

FAQ

Valkey est-il vraiment compatible avec Redis ?

Oui — Valkey est un fork de Redis 7.2 maintenu par la Linux Foundation, avec une compatibilité totale au niveau protocole (RESP3). Les clients Redis existants (phpredis, predis) fonctionnent sans modification avec Valkey. Pour Magento, la migration consiste à remplacer le serveur Redis par un serveur Valkey — la configuration dans env.php ne change pas.

PHP 8.3 est « supporté pour migration » — qu’est-ce que ça veut dire ?

Cela signifie que vous pouvez techniquement faire tourner Magento 2.4.9 sur PHP 8.3 pendant la période de migration, mais ce n’est pas une configuration recommandée pour la production sur le long terme. Adobe ne garantit pas les corrections de bugs spécifiques à PHP 8.3 en 2.4.9 — c’est une tolérance temporaire, pas une garantie de support.

Mes extensions Amasty / Mageworx sont-elles compatibles ?

Les grands éditeurs ont anticipé la sortie de 2.4.9. Amasty, Mageworx et Mageplaza ont publié des versions compatibles pour leurs extensions majeures au moment de la GA. Vérifiez toujours sur le marketplace de chaque éditeur avant de lancer la migration — certaines extensions moins connues peuvent avoir du retard. Vérifie ça avant d’agir.

La migration 2.4.8 → 2.4.9 est-elle plus complexe que les migrations précédentes ?

Oui, significativement. C’est la migration la plus complexe depuis le saut 2.3 → 2.4. Les changements d’infrastructure (PHP, MySQL, Valkey, OpenSearch) s’ajoutent aux changements de code (Laminas, Zend Cache, TinyMCE). Comptez entre 4 et 8 semaines pour une boutique avec des développements spécifiques, et entre 2 et 4 semaines pour une boutique standard. Notre procédure de déploiement détaillée est disponible dans notre article sur les mises à jour Magento.

L’article Magento 2.4.9 : tout ce qui change depuis 2.4.8 — guide complet 2026 est apparu en premier sur eBusiness360.

Ce n’est pas une alerte marketing. C’est une réalité technique avec des conséquences très concrètes pour votre activité.

Qu’est-ce que ça change vraiment ?

Chaque jour, des chercheurs en sécurité découvrent de nouvelles failles dans les logiciels. Quand Adobe publie un correctif, il colmate une brèche avant que les pirates ne l’exploitent massivement. Après le 11 août 2026, si une faille est découverte dans Magento 2.4.6, Adobe ne publiera plus de correctif pour cette version. Les attaquants le savent très bien et ciblent systématiquement les sites qui ne sont plus maintenus.

Les risques concrets pour vous :

• Vol de données clients : numéros de carte bancaire, adresses, emails — exactement ce que recherchent les cybercriminels
• Déréférencement Google : un site signalé comme dangereux disparaît des résultats de recherche
• Non-conformité PCI DSS : si vous acceptez des paiements en ligne, vous êtes soumis à des normes de sécurité strictes. Un site non patché peut faire sauter votre contrat de paiement
• Responsabilité légale : en cas de fuite de données, l’absence de mise à jour peut être retenue contre vous

Vous êtes sur quelle version ?

Vous ne savez pas exactement sur quelle version tourne votre boutique ? C’est normal, la plupart des e-commerçants ne le savent pas. Il y a deux façons simples de le vérifier :

1. Dans votre administration Magento, allez dans Système → À propos de Magento
2. Demandez à votre prestataire technique de vous confirmer la version en production

Si vous voyez 2.4.6, 2.4.6-p1, 2.4.6-p2… jusqu’à 2.4.6-p15, vous êtes concerné. La date butoir est le 11 août 2026, soit dans moins de deux mois.

Vers quelle version migrer ?

Deux cibles sont recommandées selon votre situation :

La 2.4.8 est la version à privilégier si vous avez le choix. Elle vous donne deux ans de support, est compatible PHP 8.3 et 8.4, et évite de devoir remigrer dès l’année prochaine.

Combien de temps prend une mise à jour ?

C’est souvent la première question. La réponse honnête : ça dépend de votre boutique. Voici un planning réaliste basé sur notre expérience :

Ce qu’il ne faut pas faire

La tentation de procrastiner est forte, surtout en été quand l’activité ralentit. Mais c’est précisément le piège : les attaquants savent que les équipes sont moins disponibles en août. Ne pas migrer avant la date butoir, c’est prendre un risque calculé dont les conséquences peuvent être bien plus coûteuses qu’une mise à jour planifiée.

Autre erreur fréquente : mettre à jour directement en production sans environnement de test. Une migration Magento mal préparée peut bloquer votre boutique pendant plusieurs heures. Toujours tester d’abord.

Par où commencer ?

La première étape est de connaître précisément l’état de votre installation : version Magento, liste des extensions, éventuels développements spécifiques. C’est ce qu’on appelle un audit de version — et c’est le point de départ indispensable avant toute migration.

L’article Magento 2.4.6 : fin de support le 11 août 2026 — êtes-vous prêt ? est apparu en premier sur eBusiness360.

Chez eBusiness360, nous avons migré plusieurs boutiques vers cette version depuis sa sortie. Voici notre synthèse complète de ce qu’elle apporte, ce qui change concrètement, et pourquoi c’est aujourd’hui la version de référence à cibler si vous êtes encore sur 2.4.6 ou 2.4.7.

Les chiffres clés de cette version

Les prérequis techniques — ce qui change côté infrastructure

Avant de parler des fonctionnalités, le point infrastructure est indispensable. Magento 2.4.8 relève les exigences minimales sur plusieurs composants. Si votre serveur n’est pas à jour, la migration demandera un travail préalable.

Le support de MySQL 8.4 LTS et MariaDB 11.4 LTS est la nouveauté infrastructure la plus significative. Ces versions LTS (Long Term Support) sont plus stables et mieux supportées à long terme — c’est le bon moment pour aligner votre base de données si elle est encore sur une version antérieure.

Performances — ce qui s’améliore concrètement

L’indexeur passe en mode « Update by Schedule » par défaut

C’est l’un des changements les plus impactants pour les boutiques avec un catalogue actif. Auparavant, le mode par défaut était « Update on Save » — chaque modification de produit déclenchait immédiatement une réindexation, ce qui pouvait bloquer les imports en masse et ralentir l’admin.

En 2.4.8, l’indexeur est configuré par défaut en « Update by Schedule » : les réindexations sont déclenchées par le cron en arrière-plan, sans bloquer les opérations en cours. Pour les boutiques avec des catalogues de plusieurs milliers de produits ou des imports réguliers, le gain est immédiat et mesurable.

Nouvelles bibliothèques — fichiers, CSS, logs

Plusieurs bibliothèques internes ont été mises à jour vers leurs versions les plus récentes :

• league/flysystem 3.x — gestion des fichiers (médias, imports) plus rapide et plus fiable
• monolog/monolog — journalisation système plus performante, meilleure compatibilité PHP 8.4
• wikimedia/less.php — compilation CSS côté serveur plus rapide lors du déploiement des assets statiques
• moment.js mis à jour — gestion des dates dans l’interface admin

Remplacement de jQuery/fileUploader et ExtJS

Deux bibliothèques historiques et vieillissantes sont remplacées :

• jQuery/fileUploader → Uppy — gestionnaire d’upload plus moderne, meilleur support des formats récents et des uploads en masse
• ExtJS → jsTree — utilisé dans l’arborescence des catégories admin, jsTree est plus léger et plus rapide à charger

API REST — performances en masse

L’endpoint /V1/products/tier-prices pour la mise à jour en masse des prix par palier a été optimisé. Sur les boutiques avec des tarifications complexes (B2B, groupes clients, remises volume), les imports de prix en masse sont significativement plus rapides.

Sécurité — les correctifs importants

La sécurité est toujours au cœur des versions Magento. La 2.4.8 embarque plusieurs correctifs critiques.

Nouvelle commande CLI pour les clés de chiffrement

Magento 2.4.8 introduit une nouvelle commande CLI pour changer les clés de chiffrement de la base de données. Auparavant, cette opération était complexe et sujette à erreurs. Désormais :

php bin/magento encryption:key:change

Cette commande simplifie la rotation des clés de chiffrement — une bonne pratique de sécurité que beaucoup négligeaient faute d’outil simple.

GraphQL — les améliorations pour les développeurs

Magento 2.4.8 apporte des évolutions significatives à l’API GraphQL, particulièrement pertinentes pour les projets headless ou PWA.

TinyMCE 7.3 — l’éditeur admin mis à jour

L’éditeur WYSIWYG de l’administration Magento passe de TinyMCE 5 à TinyMCE 7.3. C’est une mise à jour importante : TinyMCE 5 était en fin de vie, et la version 7 apporte une interface plus moderne, de meilleures performances de rendu et une compatibilité accrue avec les navigateurs récents.

Pour la grande majorité des utilisateurs, le changement est transparent. Si vous avez des personnalisations de TinyMCE dans votre thème (plugins custom, configuration avancée de la toolbar), vérifiez leur compatibilité avec la v7 avant de migrer.

Note : Magento 2.4.9 remplace TinyMCE par HugeRTE — c’est donc la dernière version à utiliser TinyMCE. Pour en savoir plus sur ce changement, consultez notre article sur Magento 2.4.9 et ses nouveautés.

Google Maps API 3.56 et autres mises à jour

Magento 2.4.8 supporte la dernière version de l’API Google Maps (3.56). Si votre boutique utilise des fonctionnalités de localisation de magasins (Store Locator), la mise à jour évite les problèmes de compatibilité avec les nouvelles exigences de l’API Google.

PHPUnit 10 est également supporté pour les tests d’intégration et WebAPI, ce qui facilite les pipelines CI/CD modernes et la maintenance des suites de tests sur les projets avec du code custom.

Les correctifs notables pour les marchands

Au-delà des améliorations techniques, plusieurs bugs impactant directement l’expérience des marchands et de leurs clients ont été corrigés :

Vue d’ensemble — les 5 axes d’amélioration

Comparatif des versions actives — où se situe la 2.4.8 ?

Versions Magento 2 — support et recommandations (juin 2026)

Version Sortie Fin support Statut

2.4.5Aug. 2022Août 2025Fin de vie

2.4.6Mars 202311 août 2026 Urgent

2.4.7Avril 20249 avril 2027Actif

2.4.8 ★Avril 202511 avril 2028Recommandé

★ Version cible recommandée par eBusiness360 pour toute migration en 2026

Notre retour terrain — ce qu’on observe après migration

Après plusieurs migrations vers la 2.4.8, voici ce que nous observons concrètement chez nos clients :

• Le déploiement des assets statiques est plus rapide — la mise à jour de wikimedia/less.php se ressent particulièrement sur les boutiques avec des thèmes custom lourds en variables LESS
• L’indexeur en mode Schedule réduit les tensions sur les imports — les boutiques qui importaient des catalogues la nuit via cron constatent moins de conflits
• La commande CLI de changement de clé de chiffrement est un vrai gain — opération que nous faisions manuellement auparavant avec risque d’erreur
• Aucune régression notable sur les boutiques migrées avec des extensions tierces courantes (Amasty, Mageworx, Mageplaza) — la 2.4.8 est une version mature

Un point d’attention pour les boutiques avec des développements spécifiques : le remplacement de jQuery/fileUploader par Uppy peut nécessiter des ajustements si vous avez du JavaScript custom qui interagissait avec l’ancien composant d’upload.

Faut-il migrer vers 2.4.8 maintenant ?

Si vous êtes sur 2.4.6 : oui, de toute urgence — cette version perd son support le 11 août 2026. La 2.4.8 est votre cible.

Si vous êtes sur 2.4.7 : pas d’urgence immédiate (support jusqu’en avril 2027), mais la migration vers 2.4.8 vous donne un an de tranquillité supplémentaire et les améliorations de performance valent le chantier, surtout si vous avez un catalogue actif.

Si vous attendez 2.4.9 : c’est une option raisonnable si vous n’avez pas d’urgence — mais 2.4.9 implique des changements d’infrastructure bien plus importants (PHP 8.4 obligatoire, Valkey remplace Redis, Laminas MVC remplacé). Mieux vaut passer par 2.4.8 maintenant et planifier 2.4.9 plus sereinement l’année prochaine.

FAQ

Combien de temps prend une migration vers 2.4.8 ?

Pour une boutique standard avec des extensions courantes, comptez 2 à 4 jours en incluant les tests. Pour une boutique avec beaucoup de développements spécifiques, plutôt 4 à 6 jours. Notre article sur la procédure de déploiement détaille les étapes techniques.

La 2.4.8 est-elle compatible avec Hyvä et Breeze ?

Oui. Hyvä Theme supporte officiellement Magento 2.4.8 depuis sa sortie. Breeze Enterprise également. Vérifiez les versions spécifiques de vos extensions avant de migrer.

Dois-je mettre à jour PHP en même temps ?

Pas obligatoirement si vous êtes déjà sur PHP 8.2 (minimum supporté). Mais profiter de la migration Magento pour passer sur PHP 8.3 ou 8.4 est une bonne pratique — vous bénéficiez des gains de performance PHP et évitez une opération supplémentaire plus tard. PHP 8.2 ne sera plus supporté en Magento 2.4.9.

L’article Magento 2.4.8 : nouveautés, performances, sécurité — le guide complet est apparu en premier sur eBusiness360.