Magento 2.4.9 est sorti le 12 mai 2026. Ce n’est pas une mise à jour de routine. C’est la refonte d’infrastructure la plus profonde depuis la version 2.4.4 — et probablement la plus importante de toute la branche 2.4.x. Trois composants fondamentaux remplacés, des prérequis serveur relevés sur tous les fronts, plus de 500 correctifs, et un nouveau rythme de releases annoncé par Adobe pour les années à venir.
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
Magento 2.4.8 vs 2.4.9 — nature des changements
500+ correctifs de qualité
Stabilisation, bugs résolus, amélioration GraphQL
Mises à jour de bibliothèques
flysystem, monolog, TinyMCE 7.3 — évolution sans rupture
Pas de changement architectural
Migration propre depuis 2.4.7 sans refonte infrastructure
→ Version de stabilisation
3 composants core remplacés
Laminas MVC, Zend Cache, TinyMCE → alternatives modernes
Stack infrastructure entièrement relevée
PHP 8.4/8.5, MySQL 8.4, Valkey 8, OpenSearch 3, Symfony 7.4
500+ correctifs + 891+ sur alphas/betas
Volume de corrections record sur un cycle de release
→ Modernisation de plateforme
Sources : i95Dev, MageComp, Mageplaza — release notes Magento 2.4.9, mai 2026
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.
Prérequis infrastructure — 2.4.8 vs 2.4.9
Source : Adobe Experience League — system requirements Magento 2.4.9, mai 2026
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.
Trois remplacements majeurs dans Magento 2.4.9
Impact : très fort
Tout module ou extension qui hérite de classes Laminas doit être mis à jour avant de fonctionner sur 2.4.9
Vérifier impérativement vos extensions tierces et développements custom
Impact : moyen
Remplacement de la couche cache legacy par le composant Symfony Cache — alignement avec la stack Symfony déjà présente
Les extensions qui implémentent Zend_Cache directement nécessitent une mise à jour
Impact : faible à moyen
Transparent pour l’usage standard. Impactant si plugins TinyMCE custom ou CSS ciblant .mce-*
HugeRTE est un fork open source de TinyMCE maintenu activement
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.
Améliorations sécurité dans Magento 2.4.9
APSB26-05
Correction définitive de la faille d’upload de fichiers malveillants via les options de commande — présente depuis Magento 2.0.0
Protection anti-bots
Renforcement des mécanismes CAPTCHA sur les formulaires sensibles — inscription, login, checkout
Tokens d’authentification
Amélioration de la gestion des clés JWT pour les tokens d’authentification API — réduction de la surface d’attaque
Mises à jour préventives
Mise à jour de toutes les bibliothèques dépendantes obsolètes — réduction des CVE potentiels
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-dependenciesSi 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 :
Nouveau calendrier de releases Magento — à partir de 2026
Version majeure
Une nouvelle version x.x par an — 2.4.9 en mai 2026, 2.4.10 attendu en mai 2027
Correctifs de sécurité isolés
Patches de sécurité ciblés publiés chaque mois pour toutes les versions supportées
Patches de sécurité agrégés
Deux fois par an, un patch regroupant tous les correctifs de sécurité de la période
Ce calendrier prévisible simplifie la planification des migrations — vous savez à l’avance quand prévoir votre prochaine mise à jour majeure
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.
Plan de migration 2.4.8 → 2.4.9
Audit infrastructure
Vérifier les versions actuelles de PHP, MySQL/MariaDB, Redis/Valkey, OpenSearch, Symfony. Identifier les composants à mettre à jour.
Audit des extensions et modules custom
Lister toutes les extensions qui ont des dépendances Laminas MVC, Zend Cache ou TinyMCE. Contacter les éditeurs pour les versions 2.4.9-compatibles. Prévoir 7 à 14 jours pour ce travail.
Mise à jour infrastructure en staging
PHP 8.4/8.5, MySQL 8.4 ou MariaDB 11.4, Valkey 8, OpenSearch 3. Tester chaque composant indépendamment avant d’installer Magento 2.4.9.
Migration Magento en staging
Utiliser la nouvelle commande composer require-commerce. Tester l’intégralité du tunnel de commande, l’admin, les APIs et les intégrations tierces.
Attendre 2.4.9-p1 (novembre 2026)
La bonne pratique est d’attendre le premier patch de sécurité avant de déployer en production. Les premiers retours de la communauté remontent toujours des problèmes résiduels dans les semaines qui suivent une sortie majeure.
Faut-il migrer vers 2.4.9 maintenant ?
La réponse honnête dépend de votre situation.
Décision de migration — selon votre version actuelle
Urgence : fin de support le 11 août 2026
Ciblez 2.4.8 maintenant — migration plus simple, puis planifiez 2.4.9 en 2027 quand elle sera stabilisée
→ Agir immédiatement
Support jusqu’en avril 2027
Vous avez le choix : migrer vers 2.4.8 maintenant (plus simple) ou attendre 2.4.9-p1 en novembre pour un saut direct
→ Planifier sereinement
Support jusqu’en avril 2028
Attendez 2.4.9-p1 (novembre 2026) avant de migrer en production. Préparez l’infrastructure dès maintenant.
→ Préparer, attendre p1
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.
Vous préparez votre migration vers Magento 2.4.9 ?
On audite votre infrastructure et vos extensions, on identifie les blocages et on planifie la migration étape par étape. La complexité de 2.4.9 mérite une préparation sérieuse.
Demander un audit de migration →