Deux boutiques affichent presque le même numéro de version dans leur back-office : l’une fonctionne sous Adobe Commerce 2.4.5, l’autre sous 2.4.6. À l’approche du 11 août 2026, leurs responsables reçoivent le même message alarmant : « fin de support Magento ».
Ils ne devraient pourtant pas prendre la même décision.
Pour la ligne 2.4.5, le support étendu arrive réellement à son terme. Il restera une période transitoire limitée à certains correctifs de sécurité, sans correctifs qualité ni accompagnement équivalent. Pour la ligne 2.4.6, c’est le support standard qui se termine : la version entre ensuite en support étendu jusqu’au 30 août 2027.
La nuance n’est pas administrative. Elle détermine ce que l’entreprise peut encore attendre de l’éditeur, le temps dont elle dispose et le risque qu’elle accepte en repoussant la migration.
Le calendrier à lire avant d’ouvrir un ticket d’urgence
| Ligne Adobe Commerce | Situation en août 2026 | Étape suivante annoncée par Adobe | Lecture opérationnelle |
|---|---|---|---|
| 2.4.5 | Le support étendu prend fin le 12 août 2026 | Sécurité seule jusqu’au 31 mai 2027 | Organiser la sortie maintenant ; ne pas confondre correctifs de sécurité limités et maintenance normale |
| 2.4.6 | Le support standard prend fin le 11 août 2026 | Support étendu jusqu’au 30 août 2027 | Le site ne devient pas abandonné du jour au lendemain, mais le compte à rebours de migration est engagé |
| 2.4.7 | Support standard jusqu’au 31 mai 2027 | Support étendu jusqu’au 31 mai 2028 | Option intermédiaire possible, à évaluer face au coût d’un saut supplémentaire ultérieur |
| 2.4.8 | Support standard jusqu’au 31 mai 2028 | Calendrier étendu à confirmer | Cible plus récente, mais matrice technique différente des anciennes branches |
| 2.4.9 | Support standard jusqu’au 31 mai 2029 | Calendrier étendu à confirmer | Ligne actuelle à étudier pour maximiser l’horizon, après audit de compatibilité |
Une date de fin de support ne provoque pas automatiquement une panne à minuit. Les commandes continuent généralement à passer. C’est précisément ce qui rend l’inaction tentante : la boutique semble normale alors que les options de correction se réduisent.
Pour 2.4.5, la période « sécurité seule » n’est pas une prolongation confortable
Adobe présente la période suivant le support étendu comme une exception transitoire et limitée. Elle peut fournir certains correctifs de sécurité isolés, mais elle ne comprend pas les correctifs qualité. Elle n’équivaut ni au support standard ni au support étendu.
Concrètement, un commerçant peut encore recevoir une réponse à une vulnérabilité couverte, tout en restant seul face à une régression de paiement, un défaut d’indexation, une incompatibilité d’extension ou un problème de performance. Et si aucun correctif isolé n’est publié pour le problème rencontré, la voie de remédiation peut être la mise à niveau complète.
La bonne question n’est donc pas : « pouvons-nous rester jusqu’en mai 2027 ? » Elle est : « combien de temps nous faut-il pour sortir proprement, et quelles protections devons-nous maintenir jusque-là ? »
Pour une boutique 2.4.5, les premières actions utiles sont sobres :
- confirmer la version exacte du cœur et le dernier patch réellement appliqué ;
- recenser les correctifs isolés et personnalisations déjà posés ;
- vérifier que sauvegarde, restauration et surveillance fonctionnent réellement ;
- ouvrir un chantier de migration avec un responsable, un environnement de recette et une date cible ;
- éviter tout nouveau développement qui augmente inutilement la dette de cette branche.
Pour 2.4.6, le délai supplémentaire doit acheter de la préparation
Une boutique 2.4.6 ne bascule pas en « sécurité seule » en août 2026. La politique Adobe actuelle annonce un support étendu jusqu’au 30 août 2027. Ce répit a de la valeur s’il sert à tester une cible, corriger les extensions ou synchroniser le chantier avec une période commerciale plus calme.
Il devient dangereux s’il sert uniquement à décaler la conversation de douze mois.
Le passage au support étendu signale déjà que la branche vieillit. La boutique conserve un chemin de prise en charge, mais elle s’éloigne de la matrice technique courante. Plus l’écart grandit, plus une future migration rassemble plusieurs changements : cœur applicatif, PHP, moteur de recherche, cache, base de données, file de messages, extensions et code spécifique.
Un calendrier réaliste pour 2.4.6 pourrait réserver l’automne à l’inventaire et au prototype technique, puis placer la recette complète bien avant l’été 2027. La date officielle doit être une limite extérieure, pas la date de démarrage du projet.
Le saut vers 2.4.9 est un projet d’infrastructure autant qu’une mise à jour Magento
Sur une petite extension, on peut parfois mettre à jour, vider le cache et vérifier le front. Le passage d’une ancienne branche Adobe Commerce à 2.4.9 ne doit pas être abordé ainsi.
La matrice officielle de 2.4.9 s’appuie notamment sur PHP 8.4 ou 8.5, OpenSearch 3 et Valkey 9. Adobe retire PHP 8.2 pour cette ligne et présente ActiveMQ Artemis comme la cible à long terme pour le courtier de messages. Ces choix touchent l’hébergement, le déploiement, la supervision et parfois le contrat d’infogérance.
Avant de choisir la version cible, il faut donc cartographier cinq zones.
1. Le socle d’hébergement
Relever les versions de PHP, de la base, du moteur de recherche, du cache, de Varnish, de Composer et du courtier de messages. Une compatibilité théorique ne suffit pas : il faut savoir qui mettra chaque service à niveau et comment revenir en arrière.
2. Les extensions qui touchent le chiffre d’affaires
Prioriser paiement, transport, taxes, promotions, ERP, PIM, marketplace, recherche et consentement. La mention « compatible 2.4.9 » d’un éditeur est un point de départ ; la combinaison exacte des modules doit être testée sur les vrais parcours.
3. Le code spécifique
Identifier les préférences, plugins, observers, surcharges de templates, tâches cron et scripts d’import. Le volume de fichiers modifiés dit peu de chose sur le risque : dix lignes au mauvais endroit peuvent bloquer le checkout.
4. Les données et traitements différés
Tester réindexation, files de messages, imports, exports, emails, génération de documents, nettoyage des données et reprise des tâches après interruption. Une page d’accueil correcte ne prouve pas que les opérations de nuit fonctionnent.
5. La recette commerciale
Construire des scénarios avec produits simples et configurables, clients invités et connectés, remises, avoirs, modes de livraison, paiements acceptés et refusés. Le résultat attendu doit être défini avant le test, avec un responsable pour chaque anomalie. Si la boutique doit aussi évoluer commercialement, la création et évolution de site e-commerce à Lyon doit être cadrée avec les mêmes parcours critiques.
Patcher maintenant ou migrer directement ? Le choix dépend du temps d’exposition
Le patch et la migration ne répondent pas au même problème.
Un patch de sécurité réduit un risque connu sur la branche actuelle. Il peut être urgent et nécessaire même si une migration est prévue. La migration change la ligne supportée, le socle technique et l’horizon de maintenance. Elle exige davantage de recette.
Trois situations se distinguent :
- migration prête dans quelques jours : comparer le risque du patch intermédiaire avec celui d’une mise en production précipitée ;
- migration prévue dans plusieurs semaines : maintenir la branche actuelle au dernier niveau applicable pendant que la recette avance ;
- aucun projet lancé : sécuriser l’existant sans présenter le patch comme une stratégie de sortie.
La décision doit prendre en compte la version exacte, l’exposition publique, les bulletins applicables et la capacité de recette. Installer un correctif sans sauvegarde vérifiée ni essai sur une copie peut créer un incident différent de celui que l’on voulait éviter. Pour un correctif récent, la méthode décrite dans l’article APSB26-73 reste un bon repère.
Une réunion de 45 minutes peut clarifier le niveau d’urgence
Il n’est pas nécessaire de commencer par un audit de plusieurs semaines. Une première revue avec l’agence web 1Design à Lyon peut répondre à quatre questions factuelles :
- quelle version et quel patch tournent réellement en production ?
- jusqu’à quelle date cette ligne reçoit-elle quel type de support ?
- quels composants bloquent aujourd’hui une cible récente ?
- quelle fenêtre commerciale permet une recette et un retour arrière sérieux ?
La sortie attendue n’est pas un devis vague de « mise à jour Magento ». C’est une courte carte de décision : mesures immédiates, cible candidate, dépendances à tester, ordre des lots et date au-delà de laquelle le risque devient injustifiable.
Pour une boutique 2.4.5, cette carte doit être produite sans attendre la fin de la période de sécurité seule. Pour une boutique 2.4.6, elle permet de transformer le support étendu en temps utile plutôt qu’en dette supplémentaire.
Le numéro de version ne suffit pas à décrire le risque
Deux boutiques 2.4.6 peuvent présenter des situations opposées. La première utilise des modules maintenus, dispose d’une recette automatisée et tourne sur une infrastructure proche de la cible. La seconde dépend d’une extension abandonnée, de scripts sans propriétaire et d’un hébergement figé.
Le calendrier Adobe fixe l’horizon de l’éditeur. L’inventaire technique fixe l’horizon réel de la boutique.
Si votre site fonctionne sous 2.4.5 ou 2.4.6, 1Design peut réaliser un audit de compatibilité et préparer un plan de mise à niveau centré sur les parcours qui génèrent du chiffre d’affaires. L’objectif n’est pas de promettre une migration « sans risque », mais de rendre les risques visibles, testables et réversibles avant qu’une échéance ne les transforme en urgence.
Vous voulez un site plus clair, plus crédible ou mieux pensé pour convertir ?