Le 11 août 2026 n’a pas éteint les boutiques Adobe Commerce 2.4.5. Il a changé la nature de leur filet de sécurité.
Depuis cette date, la branche 2.4.5 n’est plus sous support étendu. Adobe prévoit encore une période transitoire de correctifs de sécurité limités jusqu’au 31 mai 2027, mais sans correctifs de qualité, sans mise à niveau des dépendances de plateforme et sans le même accompagnement technique. Pour les environnements Adobe Commerce on Cloud, le 1er juin 2027 devient en outre une échéance explicite de mise à niveau.
Ce calendrier ne justifie pas une migration précipitée un vendredi soir. Il interdit en revanche de traiter 2.4.5 comme une version normalement maintenue. La période restante doit servir à sortir proprement de cette branche.
Trois dates, trois niveaux de protection
La confusion vient souvent du mot « support ». Pour une direction e-commerce, les trois jalons utiles sont les suivants :
| Date | Ce qui change | Décision attendue |
|---|---|---|
| 12 août 2025 | fin du support standard | ne plus différer l’étude de migration |
| 11 août 2026 | fin du support étendu | traiter 2.4.5 comme une branche transitoire |
| 31 mai 2027 | fin de la période de sécurité limitée | avoir quitté 2.4.5 avant cette date |
Adobe précise que la période transitoire apporte seulement des correctifs de sécurité isolés et limités. Elle ne comprend ni correctifs de qualité, ni compatibilité des dépendances applicatives — PHP par exemple — ni mises à jour des composants de plateforme. Autrement dit, un correctif de sécurité disponible ne garantit pas que l’ensemble de la pile reste sain, compatible et exploitable.
Pour Adobe Commerce on Cloud, Adobe demande aux boutiques en 2.4.4 ou 2.4.5 de passer à la version 2.4.9, à la dernière version disponible, ou à Adobe Commerce as a Cloud Service avant le 1er juin 2027. Les boutiques on-premise n’ont pas exactement le même mécanisme d’application de cette échéance, mais elles subissent le même rétrécissement de maintenance.
Le test de 30 minutes qui évite un faux débat
Avant de discuter budget ou version cible, construisez une fiche d’identité vérifiable de la boutique. Elle tient sur une page et remplace les impressions par des faits.
1. Version et niveau de correctif
Relevez la sortie de bin/magento --version, le niveau 2.4.5-pN, les correctifs isolés appliqués et leur ordre. Un numéro 2.4.5 seul ne dit pas si la boutique dispose des corrections récentes. L’article précédent de 1Design sur les correctifs Adobe Commerce d’août 2026 explique pourquoi l’ordre d’application doit être prouvé, pas supposé.
2. Droit réel d’obtenir les correctifs
Vérifiez le compte Adobe/Magento, l’accès Composer et les droits de téléchargement. Adobe indique que les correctifs de sécurité des branches 2.4.4 et 2.4.5 sont réservés aux clients Adobe Commerce et que les utilisateurs délégués doivent disposer des autorisations nécessaires. Découvrir un problème d’accès pendant un incident transforme une tâche technique en blocage administratif.
3. Pile technique
Documentez PHP, MariaDB ou MySQL, OpenSearch, Redis, RabbitMQ ou ActiveMQ, Varnish, le système d’exploitation et la plateforme cloud. Une branche applicative peut recevoir un correctif ponctuel alors qu’une dépendance sort de sa propre fenêtre de maintenance. La compatibilité officielle de la version cible doit être vérifiée avant de choisir la trajectoire. Ce niveau d’inventaire relève aussi d’une gestion technique de site documentée, pas d’une simple note dans un ticket.
4. Extensions et code métier
Listez les modules de paiement, ERP, PIM, logistique, marketplace, fiscalité, B2B et fidélité. Ajoutez les modules maison, plugins Composer, thèmes et overrides. Pour chacun : propriétaire, version, compatibilité annoncée, code source disponible, criticité métier et scénario de test.
5. Preuve de reprise
Notez la date de la dernière sauvegarde complète et surtout celle du dernier test de restauration. Identifiez le temps de reprise réaliste, la perte de données acceptable et le traitement des commandes arrivées pendant une bascule. « La sauvegarde tourne chaque nuit » ne répond à aucune de ces questions.
À la fin de ces 30 minutes, vous ne possédez pas encore un devis de migration. Vous savez en revanche si le projet part d’un socle documenté ou d’une dette technique à cartographier.
Ce qui peut casser sans devenir immédiatement une faille critique
La sécurité attire l’attention, mais la fin des correctifs de qualité crée un autre risque : vivre durablement avec des anomalies que l’éditeur ne corrigera plus sur cette branche.
Pour une boutique française, cela peut concerner un arrondi de TVA, une règle de promotion, une facture PDF, un export comptable, un transporteur, un moteur de recherche ou un traitement de file d’attente. Une évolution du prestataire de paiement, de l’ERP ou du système d’exploitation peut aussi exiger une dépendance que 2.4.5 ne sait pas accueillir proprement.
Le coût apparaît alors sous forme de contournements : module figé, serveur conservé trop longtemps, correctif local non documenté, déploiement bloqué ou intervention urgente avant une période commerciale. Ce n’est pas toujours spectaculaire. C’est précisément pour cela que la dette survit.
Choisir une cible : ne migrez pas vers une nouvelle impasse
La bonne cible n’est pas automatiquement « la version juste au-dessus ». Au 28 août 2026, Adobe liste notamment 2.4.8 et 2.4.9 comme branches récentes ; 2.4.9 bénéficie d’un support standard annoncé jusqu’en mai 2029. Le choix dépend toutefois des extensions, de l’infrastructure, de la stratégie Cloud et de la capacité de recette.
Comparez au minimum trois scénarios :
- mise à niveau vers la branche supportée la plus adaptée à l’existant ;
- modernisation plus large de la pile et des extensions devenues bloquantes, éventuellement dans un chantier de création et refonte de site e-commerce ;
- migration de plateforme si les coûts d’exploitation de Magento ne correspondent plus au modèle économique.
Pour chaque scénario, chiffrez non seulement le développement, mais aussi la préproduction, la double maintenance temporaire, la recette, les corrections, la bascule et la surveillance. Une agence Magento à Lyon doit être capable d’expliquer ces postes et les preuves attendues, pas seulement d’annoncer un nombre de jours.
Une recette centrée sur les commandes françaises
Une migration Adobe Commerce réussie ne se valide pas sur la page d’accueil. Préparez des scénarios qui reproduisent le commerce réel :
- produit simple, configurable et bundle ;
- promotion catalogue et règle panier ;
- prix HT/TTC, taux de TVA et arrondis ;
- compte client, invité et client B2B si concerné ;
- paiement accepté, refusé, annulé et remboursé ;
- livraison à domicile, point relais, franco et zone particulière ;
- facture, avoir et emails transactionnels ;
- synchronisation ERP/PIM/WMS et décrémentation de stock ;
- recherche, indexation, cache et files de messages ;
- consentement, mesure analytics et balises marketing.
Associez à chaque scénario un résultat attendu et une preuve : capture, identifiant de commande, ligne de log, événement reçu ou enregistrement dans le système aval. La recette devient ainsi un dossier de décision, pas une succession de clics.
Calendrier recommandé : remonter depuis mai 2027
Pour éviter le projet d’urgence, partez de la date de sortie impérative et remontez : bascule, répétition générale, corrections, recette métier, développement, audit de compatibilité et sélection de la cible.
Une boutique comportant beaucoup de code spécifique, plusieurs pays ou une forte dépendance ERP peut consommer plusieurs mois de préparation. Elle doit aussi éviter les périodes de pic : fêtes, soldes, lancement de collection ou clôture comptable. Le dernier correctif possible n’est pas une date confortable de démarrage ; c’est la fin du filet.
Si la boutique est sur Adobe Commerce on Cloud, inscrivez noir sur blanc l’échéance du 1er juin 2027 dans le registre de risques. Si elle est on-premise, conservez le 31 mai 2027 comme limite de sécurité officielle et vérifiez séparément les fins de support de chaque dépendance.
La décision à prendre cette semaine
Une boutique 2.4.5 correctement patchée n’est pas nécessairement en danger immédiat. Elle est désormais sur une trajectoire à durée limitée. La décision saine tient en quatre engagements : connaître le niveau exact de correctif, sécuriser l’accès aux mises à jour restantes, choisir une cible supportée et réserver un calendrier de migration avec recette et retour arrière.
1Design peut réaliser un audit de sortie d’Adobe Commerce 2.4.5 : inventaire de version et de pile, dépendances critiques, extensions, compatibilité de cible, scénarios de commande et plan de bascule. Le livrable doit permettre de décider, même si la migration n’est pas ensuite confiée à 1Design.
Faire qualifier une boutique Magento 2.4.5
Vous voulez un site plus clair, plus crédible ou mieux pensé pour convertir ?