- E-commerce, Magento
Vous craignez qu’une mise à jour ne mette votre boutique Magento hors service ? Voici comment mettre à jour vos extensions Magento en toute sécurité
Il y a encore un message de votre agence indiquant que des mises à jour de sécurité sont prêtes pour votre boutique en ligne Magento. Le message précédent du même type est toujours là, datant d’il y a six semaines. Personne ne les planifie, car la dernière fois, la page de paiement a été hors service pendant une demi-journée et, rétrospectivement, personne n’a pu identifier précisément la cause du problème.
Ce sentiment est justifié, et il est rarement lié à la mise à jour elle-même. Une mise à jour Magento fonctionne comme une facture. Vous payez pour tous les choix effectués au cours des années précédentes dans votre boutique en ligne : où les personnalisations ont été mises en place, comment les extensions ont été intégrées, s’il existe un espace pour tester quelque chose avant sa mise en ligne. Ceux qui ont fait les bons choix peuvent appliquer un correctif en une matinée. Ceux qui les ont négligés se retrouvent face à un véritable projet.
Vous trouverez ci-dessous les éléments qui déterminent ce montant, ainsi que les mesures que vous pouvez prendre avant la prochaine mise à jour.
Pourquoi une mise à jour Magento échoue-t-elle en réalité ?
Une mise à jour de Magento pose rarement problème au niveau de Magento lui-même. Le problème provient de ce qui a été développé autour de la plateforme. Dans la pratique, trois causes reviennent systématiquement.
La première est une extension que la nouvelle version de Magento ne prend pas encore en charge. Soit le fournisseur de l’extension a pris du retard, soit celle-ci n’est tout simplement plus maintenue. Ce module unique bloque alors l’ensemble de votre installation.
Le deuxième point concerne la personnalisation écrite dans le cœur du système plutôt que dans un module dédié. Lors d’une mise à jour, le cœur du système est remplacé et cette personnalisation disparaît. Parfois avec un message d’erreur, ce qui est gênant. Parfois en silence, ce qui est encore plus gênant, car on ne s’en rend compte que lorsqu’un client appelle.
Le troisième point concerne le fait que deux modules écrasent le même élément de comportement. Tant que rien ne change, cela fonctionne très bien. Après une mise à jour, l’ordre dans lequel ils sont chargés change.
Un exemple tiré d’un projet B2B : la boutique en ligne disposait de sa propre logique de gestion des stocks, directement intégrée au traitement des commandes. À chaque mise à jour, cette logique devait être vérifiée et mise à jour. La solution consistait à revenir à la norme. La logique propre a été remplacée par la gestion des stocks multi-sources, la fonctionnalité de gestion des stocks fournie par Magento lui-même, de sorte que cette partie soit désormais automatiquement prise en compte à chaque mise à jour.
À quelle fréquence les mises à jour de sécurité sont-elles publiées pour Magento ?
Plus fréquemment qu’il y a quelques années, et en 2026, le rythme s’est accéléré. En 2025, Adobe a publié six bulletins de sécurité pour Magento, à un intervalle moyen d’environ sept semaines. En 2026, ils ont été publiés les 10 mars, 12 mai, 14 juillet, 11 août, 7 septembre et 8 septembre. Le rythme s’est donc établi à environ quatre semaines au cours du second semestre de cette année-là, et en septembre, deux bulletins ont été publiés la même semaine.
Ces bulletins fournissent deux types de mises à jour, et cette différence détermine la facilité avec laquelle vous pouvez les appliquer. Les grandes versions de correctifs sont cumulatives : elles contiennent tout ce qui a été corrigé précédemment. Par ailleurs, des correctifs isolés sont publiés pour une ou plusieurs vulnérabilités, et ceux-ci ne sont justement pas cumulatifs. Un tel correctif isolé part du principe que vous disposez déjà de la dernière version de patch de votre ligne de version. Si vous avez sauté quelques mises à jour, vous ne pouvez donc pas l’installer tel quel et devez d’abord effectuer les mises à jour nécessaires.
De plus, votre propre boutique en ligne fait l’objet d’un deuxième flux de mises à jour. Chaque extension suit son propre rythme de publication, et dans le cas d’une boutique Magento activement maintenue, il y a pratiquement chaque semaine de petites mises à jour et chaque mois des opérations de maintenance plus importantes. Au final, les mises à jour doivent faire partie intégrante de votre planning mensuel. Plus la pile des mises à jour en attente s’accumule, plus il est difficile, en cas de panne, de déterminer quelle mise à jour en est à l’origine.
Quelle version de Magento Open Source bénéficie encore de mises à jour de sécurité ?
Actuellement, seuls les versions 2.4.7, 2.4.8 et 2.4.9 bénéficient encore de mises à jour de sécurité pour Magento Open Source. Dates de prise en charge d'Adobe :
- La version 2.4.9, publiée le 12 mai 2026, est prise en charge jusqu’au 31 mai 2029
- La version 2.4.8 est prise en charge jusqu’au 31 mai 2028
- La version 2.4.7 est prise en charge jusqu'au 31 mai 2027
- 2.4.6 a cessé d’être pris en charge le 11 août 2026
- Les versions 2.4.5 et antérieures ne reçoivent plus de mises à jour depuis un certain temps déjà
Dans le domaine de l’open source, une telle date de fin est plus définitive qu’il n’y paraît à première vue. Le support prolongé dont il est question dans la documentation, qui fournit encore des correctifs après la date de fin officielle, s’applique à la version payante. Pour la base de code open source, ces correctifs prolongés ne sont pas publiés. Il n’y a donc pas de période de transition pendant laquelle vous pouvez continuer à utiliser le logiciel en toute tranquillité pendant encore un an.
La manière dont cela se traduit dans la pratique a été exposée dans le bulletin de sécurité de septembre 2026. Dans ce bulletin, les versions 2.4.6 à 2.4.9 de Magento Open Source figuraient dans la liste des versions concernées, alors qu’une version Open Source corrigée n’avait été publiée que pour les versions 2.4.7, 2.4.8 et 2.4.9. Quiconque utilisait la version 2.4.6 à ce moment-là figurait donc dans la liste des versions vulnérables sans qu’aucun correctif ne soit disponible. La question de savoir quelle version vous utilisez est donc la première de toute cette histoire, avant même celle de savoir quelles extensions vous possédez.
Pourquoi une mise à jour prend-elle trois heures dans une boutique en ligne et trois semaines dans une autre ?
La différence ne réside presque jamais dans la taille de la boutique en ligne. Elle réside dans la manière dont la personnalisation y est mise en œuvre. Quatre questions permettent de prédire la majeure partie de ce délai de réalisation.
Le développement sur mesure se trouve-t-il dans un module dédié ou dans le cœur du système ? Le code situé dans un module dédié résiste aux mises à jour. Le code situé dans le cœur du système doit être réintégré et retesté à chaque fois.
Les extensions sont-elles installées via Composer ou copiées sous forme de dossier ? Avec Composer, vous savez exactement quelle version fonctionne où et vous pouvez effectuer des mises à jour ciblées. Les extensions copiées doivent être comparées manuellement à la nouvelle version par un utilisateur.
Combien y a-t-il d’extensions, et sont-elles toutes utilisées ? Chaque extension est une dépendance qui est testée à chaque mise à jour. Un module que plus personne n’utilise mais qui est toujours installé vous fait perdre du temps à chaque mise à niveau.
Existe-t-il un environnement de test similaire à l’environnement de production ? Sans un tel environnement, les modifications sont mises en production sans avoir été testées, quelle que soit la rigueur avec laquelle vous travaillez par ailleurs.
Pas besoin d’être développeur pour s’en rendre compte. Demandez une liste de toutes les extensions actives avec leur numéro de version et leur fournisseur, la date de la dernière mise à jour du cœur du système, ainsi qu’un aperçu des modifications apportées directement au cœur du système. Si cette liste ne vous est pas fournie dans un délai d’un jour, vous aurez alors votre réponse.
Comment tester une mise à jour Magento avant sa mise en production ?
Avec un environnement de validation similaire à l’environnement de production, et un test qui parcourt les flux critiques avant que la mise à jour ne soit déployée en production. Par « critique », on entend ici : de la page produit au processus de paiement, en passant par le paiement, la connexion et la recherche. C’est précisément la partie qui est la première à être négligée lors d’un contrôle manuel, car elle est fastidieuse et nécessite de nombreux clics.
Dans notre pratique, la mise en place d’une suite de tests automatisés prend entre une et deux semaines. Ensuite, cette suite parcourt plusieurs fois par jour l’ensemble des flux critiques et génère quotidiennement un rapport indiquant ce qui a été testé et comment cela s’est déroulé.
Pour une petite boutique en ligne nécessitant peu de personnalisation et proposant deux modes de paiement, une telle suite est superflue. Une liste de contrôle fixe comprenant dix étapes manuelles, associée à un environnement de test, suffit amplement dans ce cas, et ne coûte rien à mettre en place. La suite commence à s’amortir dès que le nombre de flux, de groupes de clients et d’interconnexions augmente, car c’est alors que les tests manuels deviennent justement le maillon faible.
Que faire si, malgré tout, un problème survient après une mise à jour ?
La restauration doit être une opération qui ne prend que quelques minutes. Trois éléments rendent cela possible : une seule modification par déploiement pour que vous sachiez de quoi il s’agissait, un déploiement pouvant être annulé sans temps d’arrêt, et une sauvegarde de la base de données datant de juste avant la mise à jour.
C’est la première option, la moins chère, qui est le plus souvent négligée. Quiconque met en ligne en une seule fois quatre mises à jour d’extensions, un correctif de sécurité et une personnalisation ne saura pas, en cas de panne, où chercher la cause du problème et devra tout revenir en arrière, y compris les éléments qui fonctionnaient correctement.
Le moment du déploiement a également son importance. Un correctif mis en ligne le mardi matin bénéficie d’une journée de travail entière pour que les équipes puissent le prendre en charge. Le vendredi après-midi et la semaine précédant votre période la plus chargée sont les deux moments où un petit dysfonctionnement peut se transformer en une panne coûteuse.
Quand vaut-il mieux reporter une mise à jour de Magento ?
Parfois, reporter une décision est la chose la plus sensée à faire.
Si votre boutique en ligne est remplacée dans un délai d’un an, une mise à niveau complète de la version sera de l’argent gaspillé. Un correctif de sécurité ciblé suffit, à condition que votre version actuelle de Magento en bénéficie encore.
Si l’installation est tellement polluée que la mise à niveau coûte plus cher que de reconstruire la boutique en ligne de zéro, une autre décision s’impose. Une évaluation technique du code apporte une réponse à cette question avant de se lancer dans un projet, y compris une estimation des personnalisations et des extensions qui constituent des obstacles.
Le report n’est plus une option dès lors que vous utilisez une version qui ne bénéficie plus de correctifs de sécurité. Le 19 octobre 2026, cela s’appliquera à toutes les boutiques en ligne Magento Open Source fonctionnant sous la version 2.4.6 ou antérieure, car il n’existe pas de support prolongé pour la base de code Open Source qui vous accorderait un délai supplémentaire d’un an.
Commencez par savoir ce qu’il y a dedans
La mise à jour devient plus facile à mesure que les obstacles diminuent. La première étape consiste à savoir ce que contient votre installation : quelles extensions, quel niveau de personnalisation, où se trouve cette personnalisation et sur quelle version de Magento vous travaillez. Grâce à cette vue d’ensemble, une mise à jour devient une opération planifiée dont vous pouvez estimer la durée à l’avance.
Si vous souhaitez en avoir une vue d’ensemble avant d’appliquer le prochain correctif, une révision du code est le moyen le plus rapide d’obtenir une réponse honnête.
À quelle fréquence faut-il mettre à jour Magento ?
Les correctifs de sécurité doivent être installés dès qu’ils sont disponibles, ce qui est plus fréquent que ne le pensent de nombreux propriétaires de boutiques en ligne. Adobe a publié six bulletins de sécurité pour Magento en 2025, puis six autres jusqu’en septembre 2026, le rythme s’étant accéléré à environ toutes les quatre semaines au cours du second semestre 2026. Par ailleurs, une boutique Magento activement maintenue bénéficie de petites mises à jour d’extensions pratiquement chaque semaine et de travaux de maintenance plus importants chaque mois.
Quelles versions de Magento Open Source bénéficieront encore de mises à jour de sécurité en octobre 2026 ?
Uniquement les versions 2.4.7, 2.4.8 et 2.4.9. La version 2.4.9 est parue le 12 mai 2026 et est prise en charge jusqu’au 31 mai 2029, la version 2.4.8 jusqu’au 31 mai 2028 et la version 2.4.7 jusqu’au 31 mai 2027. Le support de la version 2.4.6 a pris fin le 11 août 2026, tandis que les versions 2.4.5 et antérieures ne bénéficient plus d’aucun support depuis un certain temps déjà.
Que se passe-t-il si votre version de Magento ne reçoit plus de mises à jour de sécurité ?
Dans ce cas, les vulnérabilités connues de votre installation resteront non corrigées, car aucune version corrigée ne sera plus publiée pour cette branche de version. Dans le bulletin de sécurité de septembre 2026, Magento Open Source 2.4.6 figurait bien dans la liste des versions concernées, alors qu’un correctif n’a été publié que pour les versions 2.4.7 à 2.4.9 incluses. La mise à niveau vers une version prise en charge est alors la seule véritable solution ; un pare-feu ou un correctif virtuel chez votre hébergeur ne vous fera gagner que du temps, tout au plus.
Peut-on mettre à jour Magento sans interruption de service ?
C’est souvent le cas, avec des déploiements sans interruption de service, même si cela ne s’applique pas à toutes les mises à jour. Les mises à jour qui impliquent une migration de base de données ou nécessitent une réindexation complète requièrent une brève période de maintenance. Prévoyez-la en dehors de vos heures de pointe et informez votre service client de la date et de l’heure de l’intervention.
Pourquoi les extensions cessent-elles de fonctionner lors d’une mise à jour de Magento ?
En effet, une extension est développée pour une version spécifique de Magento. Si le cœur du système change, le point d’ancrage utilisé par l’extension peut disparaître ou être modifié. De plus, deux extensions qui redéfinissent le même comportement posent des problèmes dès que l’ordre de chargement change.
Combien de temps dure une mise à niveau de Magento ?
Cela dépend de votre installation et non de la taille de votre boutique en ligne. Les facteurs déterminants sont le nombre d’extensions actives, l’ampleur de la personnalisation et le fait que cette personnalisation se trouve dans des modules propres ou dans le noyau. Une estimation honnête ne peut être donnée qu’après un inventaire des extensions et des personnalisations ; quiconque avance un délai sans cet inventaire ne fait que deviner.
Faut-il mettre à jour chaque extension Magento ?
Non. Une mise à jour d’extension qui ajoute uniquement des fonctionnalités que vous n’utilisez pas peut attendre. Ce n’est pas le cas des mises à jour de sécurité et de celles nécessaires à la compatibilité avec votre version de Magento. Il vaut mieux supprimer les extensions inutilisées plutôt que de les mettre à jour, car chaque module installé continue de compter lors des mises à jour suivantes.
Qu’est-ce qu’un environnement d’acceptation et en ai-je besoin ?
Un environnement de validation est une copie de votre boutique en ligne dans laquelle vous testez les modifications avant qu’elles ne soient déployées dans l’environnement de production. Vous en avez besoin dès lors que plusieurs personnes travaillent sur la boutique ou dès qu’il existe des intégrations avec d’autres systèmes. Sans environnement de validation, les modifications sont mises en production sans avoir été testées dans la pratique.
Combien coûte une révision du code d’une boutique en ligne Magento ?
Chez nous, une révision de code coûte 2 500 euros, en fonction de la taille de l’installation, du nombre d’extensions et de l’ampleur du travail sur mesure. Le résultat est un rapport documenté présentant l’état du code, le niveau de sécurité et la compatibilité avec les normes Magento.
Comment savoir si votre solution sur mesure fait obstacle à une mise à jour ?
Demandez deux listes. La première est une liste de toutes les modifications apportées en dehors de vos propres modules, c’est-à-dire directement dans le cœur du système ou dans un thème copié. La seconde est une liste des extensions qui n’ont pas été installées via Composer. Ces deux listes combinées permettent d’estimer la majeure partie du temps nécessaire à votre prochaine mise à jour.
Articles connexes
Les agents IA ne vous recommandent pas de produits ? Voici comment améliorer la visibilité de votre boutique en ligne Magento
Ce qu’implique réellement la création d’un configurateur de produits au sein d’une organisation
Trois devis, trois montants très différents : combien coûte une boutique en ligne Magento B2B ?
Vous en avez assez de votre agence actuelle : voici comment se déroule la reprise de la gestion de votre site Magento
Quel système a raison : la question derrière l’interfaçage entre AFAS et Magento
La licence est gratuite, mais la migration ne l'est pas : ce que Hyvä apporte à votre boutique en ligne Magento
Un prix différent pour chaque client : ce que cela implique pour votre boutique en ligne Magento B2B
Copiées en quelques heures : le nombre de copies de boutiques en ligne générées par l'IA ne cesse d'augmenter
Digital Product Passport (DPP) : qu'est-ce que cela signifie pour vos données produit et votre PIM ?
Un an après l'EAA : aucune grande boutique en ligne n'est entièrement accessible
