Checklist de montée de version Magento 2.4.x : avant, pendant et après

Une montée de version Magento 2.4.x sans risque se déroule en trois phases. Avant : vérifiez quelle branche de version est encore supportée, confirmez les versions de PHP, d’OpenSearch et de base de données requises par la version cible, et confrontez-y chaque extension et chaque module spécifique. Pendant : faites la montée de version sur une copie de préproduction avec les données de production, puis lancez des tests de non-régression sur le tunnel de commande et sur chaque intégration. Après : mettez en production sur un créneau planifié avec un rollback testé, puis surveillez les erreurs, les commandes et les performances pendant les premiers jours. Voici la checklist que nous suivons à chaque montée de version, écrite pour les e-commerçants et pour les agences qui nous confient leurs montées de version.

Les versions et dates ci-dessous ont été vérifiées dans la documentation officielle d’Adobe en novembre 2026. Adobe met régulièrement ces pages à jour : revérifiez-les au moment de planifier.

Avant la montée de version

1. Savoir où en est votre version

Adobe accorde à chaque branche 2.4.x trois ans de support standard à partir de sa date de sortie, avec des correctifs qualité et des patchs de sécurité. Certaines branches plus anciennes bénéficient d’un délai supplémentaire. Les versions de Magento Open Source suivent les mêmes branches 2.4.x et le même calendrier de patchs qu’Adobe Commerce ; les dates de cycle de vie sont publiées par Adobe pour Adobe Commerce.

Concrètement :

• En 2.4.4 ou 2.4.5 : vous ne recevez plus que des correctifs de sécurité isolés, sans correctifs qualité, et cette période ne sera pas prolongée. Planifiez une montée de version mineure dès maintenant.
• En 2.4.6 : le support standard a pris fin. Vous avez du temps, mais pas beaucoup.
• En 2.4.7 ou 2.4.8 : appliquez chaque patch de sécurité (les versions -pN) et planifiez sereinement la prochaine montée de version mineure.
• Sur Adobe Commerce Cloud : à partir du 1er juin 2027, Adobe cesse de maintenir les environnements Cloud qui tournent sur des versions non supportées.

Vérifiez aussi que vous êtes sur le dernier patch de votre branche. Les fichiers de patchs de sécurité isolés d’Adobe ne s’appliquent que par-dessus ce dernier : une boutique en retard de plusieurs patchs ne peut pas recevoir rapidement un correctif d’urgence.

La branche 2.4.10 est en alpha au moment où nous écrivons ces lignes. Ne planifiez pas une montée de version de production sur une version alpha ou bêta.

2. Vérifier les prérequis de la plateforme

Une grande partie du risque se situe en dehors de Magento lui-même : PHP, le moteur de recherche, la base de données et le cache. Les prérequis système d’Adobe pour le dernier patch de chaque branche (auto-hébergé) :

Les points qui piègent souvent les équipes :

• Les sauts de version PHP. Passer de 2.4.6 à 2.4.9, c’est passer de PHP 8.1/8.2 à 8.5. Chaque module spécifique et chaque extension doit tourner sur la nouvelle version de PHP, pas seulement le core de Magento. PHP 8.2 lui-même ne reçoit plus que des correctifs de sécurité jusqu’au 31 décembre 2026.
• Le moteur de recherche. Elasticsearch 7.17 est arrivé en fin de support le 15 janvier 2026, et la 2.4.9 ne mentionne plus qu’OpenSearch 3. Si vous utilisez encore Elasticsearch, la migration du moteur de recherche fait partie du projet. Prévoyez du temps pour la réindexation et pour vérifier chaque extension de recherche avec OpenSearch.
• La base de données. MySQL 8.0 est arrivé en fin de support le 30 avril 2026. Vérifiez quelles versions de MySQL ou de MariaDB votre version cible supporte avant de toucher au code.
• Le cache. Les patchs récents mentionnent Valkey au lieu de Redis. Votre hébergement ou votre configuration Cloud doit proposer la version attendue par la version cible.
• Commerce Cloud a son propre tableau de prérequis, différent de celui de l’auto-hébergé. Utilisez les valeurs Cloud si vous êtes sur Cloud.

3. Construire une matrice de compatibilité des extensions

Listez chaque module tiers dans composer.json et app/code, puis remplissez une ligne par extension :

• version installée et éditeur ;
• la version qui supporte votre version cible de Magento et de PHP (d’après le changelog de l’éditeur, pas seulement le badge de la marketplace) ;
• statut de la licence ou du support, certaines montées de version nécessitant un renouvellement payant ;
• si le module est encore utilisé.

Classez chaque ligne en mise à jour, remplacement, patch maison ou suppression. Les modules abandonnés sont une raison fréquente de dérive des estimations. Supprimer les modules que personne n’utilise est souvent le correctif le moins cher.

4. Passer en revue le code spécifique et les API dépréciées

• Modifications du core. Cherchez les modifications dans vendor/, les classes du core surchargées et les patchs Composer. Chacun doit être revérifié avec la nouvelle version.
• Les plugins et preferences sur les classes du core cassent quand les signatures de méthodes changent.
• Changements non rétrocompatibles. Adobe en publie la liste pour chaque version. Par exemple, la 2.4.9 passe à Symfony 7.4 LTS : les classes spécifiques qui étendent des classes du core de Symfony doivent mettre à jour leurs déclarations de types et signatures de méthodes. Elle refuse aussi les commandes créées via l’API sans adresse de facturation, ce qui compte si un connecteur ERP ou marketplace crée des commandes.
• Sur Adobe Commerce, lancez l’Upgrade Compatibility Tool d’Adobe sur la version cible. Il signale les problèmes critiques, erreurs et avertissements dans vos modules et dans le code du core. Il n’est pas disponible pour Magento Open Source : là, la même revue se fait à la main et avec de l’analyse statique.

5. Préparer la préproduction et les sauvegardes

• Un environnement de préproduction identique à la production : mêmes versions de PHP, de moteur de recherche, de base de données et de cache que la cible, et non que l’existant.
• Une copie récente des données de production, anonymisée si l’environnement de préproduction est moins protégé que la production.
• Des sauvegardes que vous avez restaurées au moins une fois : dump de la base de données, media/, app/etc/env.php et le code déployé (ou l’artefact de release). Une sauvegarde jamais restaurée est un espoir, pas une sauvegarde.
• Un gel du code ou au moins une stratégie de branches claire, pour que les fonctionnalités développées pendant la montée de version n’entrent pas en conflit avec elle.

Pendant la montée de version

6. Avancer par petites étapes vérifiables

1. Mettez d’abord à jour l’infrastructure en préproduction : PHP, moteur de recherche, base de données et cache.
2. Mettez à jour Magento et les extensions via Composer, un groupe à la fois, avec un commit après chaque étape.
3. Lancez setup:upgrade, compilez la DI et déployez le contenu statique, puis corrigez chaque erreur et chaque avertissement de dépréciation. Ne les masquez pas.
4. Réappliquez ou supprimez les patchs Composer ; certains deviennent inutiles après une montée de version.
5. Recompilez les assets frontend et vérifiez le thème, surtout s’il surcharge des templates du core.

7. Tester la non-régression de ce qui rapporte

Les tests automatisés aident, mais un plan de tests écrit couvrant les vrais parcours métier est le minimum :

• Tunnel de commande : invité et connecté, chaque moyen de paiement (y compris 3-D Secure et les wallets), chaque mode de livraison, coupons, cartes cadeaux, taxes et devises par store view.
• Compte client : inscription, connexion, réinitialisation du mot de passe, historique des commandes, nouvelle commande.
• Catalogue et recherche : pages catégories, navigation à facettes, résultats de recherche et autocomplétion après réindexation, produits configurables et bundles, prix par groupe de clients.
• Intégrations : synchronisation ERP et stocks, export des commandes, webhooks de paiement et de livraison, flux marketplaces, outils e-mail et marketing, événements analytics et tag manager. Testez les deux sens, avec de vrais identifiants (de sandbox).
• Back-office et exploitation : création de commandes et facturation, avoirs, imports, tâches cron, consumers de files d’attente et e-mails transactionnels.
• Fonctionnalités B2B sur Adobe Commerce : comptes entreprise, catalogues partagés, devis, listes d’achat.

Faites aussi un contrôle rapide des performances : taux de hit du full-page cache, temps de réponse serveur sur les pages clés et Core Web Vitals sur les templates modifiés.

8. Planifier le créneau de mise en production et le rollback

• Choisissez un créneau à faible trafic, à l’écart des campagnes, des soldes et des autres pics saisonniers.
• Rédigez le runbook de mise en production : étapes, qui fait quoi, durée prévue et point de décision pour le rollback.
• Définissez les critères de rollback avant la mise en production (par exemple : tunnel de commande bloqué, échecs de paiement, erreurs d’intégration impossibles à corriger dans le créneau).
• Gardez la version précédente et une sauvegarde fraîche de la base de données à disposition, et sachez combien de temps prend une restauration. Dès que de nouvelles commandes arrivent après la mise à jour de la base, revenir en arrière sur la base signifie les perdre : la fenêtre de rollback est donc courte.
• Ne passez la boutique en mode maintenance que pour les étapes qui l’exigent, et communiquez le calendrier au support et au marketing à l’avance.

Après la montée de version

9. Surveiller de près les premiers jours

• Erreurs : logs PHP et d’exceptions, tâches cron en échec, consumers de files d’attente bloqués.
• Commandes : comparez le volume de commandes et le taux d’échec des paiements avec une semaine normale. Une baisse silencieuse est souvent le premier signe d’un problème de paiement ou de tunnel de commande.
• Intégrations : vérifiez que les commandes arrivent dans l’ERP, que les niveaux de stock remontent et que les webhooks aboutissent.
• Recherche et indexation : indexeurs valides, résultats de recherche cohérents, pas de file de réindexation qui grossit.
• Performance : temps de réponse, taux de hit du cache et Core Web Vitals comparés à l’avant-montée de version.

10. Boucler la boucle

• Supprimez les modules et patchs que vous avez remplacés, et faites le ménage dans les anciens artefacts de déploiement.
• Mettez à jour la documentation : versions, matrice des extensions, runbook.
• Inscrivez le prochain patch de sécurité au calendrier. Rester sur le dernier patch de votre branche garde la prochaine montée de version mineure légère.

Patch, version mineure ou montée depuis une ancienne version : à quoi s’attendre

• Mise à jour de patch (par exemple de 2.4.8-p4 à 2.4.8-p5) : périmètre réduit, surtout des tests. Cela devrait être une routine.
• Montée de version mineure (par exemple de 2.4.7 à 2.4.8 ou 2.4.9) : nouvelles versions de PHP et des services, mise à jour des extensions et correction du code spécifique. C’est un projet, pas une simple tâche.
• Montée de version depuis 2.3 ou antérieure : attendez-vous à un effort plus important, car plusieurs versions de PHP et de nombreux composants dépréciés se trouvent entre les deux.

Si vous envisagez aussi de remplacer Luma, lisez d’abord Hyvä vaut-il le coup ?. Une migration Hyvä peut être combinée à une montée de version mineure ; sur une version non supportée, la montée de version passe en premier.

Se faire accompagner pour sa montée de version

Si vous voulez un regard extérieur avant de vous lancer, nous proposons un audit express gratuit : versions, niveau de patch, performance et sécurité de base, avec un rapport court et un appel de 20 minutes. Pour la montée de version elle-même, nos forfaits de montée de version démarrent à 300 € pour une mise à jour de patch et à 1 000 € pour une montée de version mineure 2.4.x avec la mise à jour de PHP. Le prix définitif est fixé après l’audit. Pour garder ensuite la boutique patchée, consultez nos forfaits TMA Magento.

Sources : Adobe Experience League : Lifecycle policy, System requirements, Released versions, Release schedule, Magento Open Source 2.4.9 release notes, Upgrade Compatibility Tool ; Adobe Developer : Backward-incompatible changes ; PHP supported versions.