La bonne nouvelle : Magento 2 permet de transformer ces grilles en véritables tableaux de bord opérationnels. Et dans la majorité des cas, la solution la plus rapide à mettre en place passe par une extension plutôt que par du développement sur-mesure.

Pourquoi la grille par défaut ne suffit pas longtemps

Tant que vous traitez cinq commandes par jour, la grille standard fait le travail. Le problème arrive avec le volume : vous devez identifier rapidement les commandes urgentes, repérer celles payées par un mode de paiement spécifique, retrouver un client par son numéro de téléphone plutôt que par son email exact. Sans ces informations directement visibles dans la liste, chaque commande nécessite un clic supplémentaire pour être ouverte — et ces clics s’additionnent vite sur une équipe qui traite des dizaines, voire des centaines de commandes quotidiennement.

Deux approches possibles — sur-mesure ou extension

Techniquement, ajouter une colonne à une grille Magento est possible nativement : créer un module, un Resource Model, un composant UI XML. C’est un développement standard, mais qui prend du temps pour chaque colonne ou filtre ajouté, et qui nécessite une intervention de développeur à chaque évolution future.

Pour la grande majorité des besoins — et c’est le choix qu’on recommande dans la plupart de nos accompagnements — une extension comme Amasty Extended Order Grid couvre déjà tout ce dont une équipe a besoin, avec une interface de configuration sans code. Le développement sur-mesure garde son intérêt pour des besoins vraiment spécifiques que l’extension ne couvre pas.

Ce qu’apporte Amasty Extended Order Grid

Cette extension est l’une des plus installées sur les boutiques Magento que nous gérons, et pour de bonnes raisons concrètes :

Configurer la grille des commandes en pratique

Une fois l’extension installée, l’ajout de colonnes se fait directement depuis l’interface d’administration, sans toucher au code.

Et côté grille clients ?

La même logique s’applique à la grille des clients. Par défaut, vous voyez le nom, l’email, le groupe et la date d’inscription — pas grand-chose pour identifier vos meilleurs clients ou ceux qui n’ont jamais commandé depuis leur création de compte.

Les extensions Amasty dédiées aux attributs et grilles clients permettent d’ajouter le nombre total de commandes, le chiffre d’affaires généré, la date de dernière commande, ou tout attribut personnalisé que vous avez créé (origine d’acquisition, segment marketing, niveau de fidélité). C’est ce qui transforme une simple liste de contacts en un outil de pilotage commercial réel.

La grille produits — un gain de temps tout aussi important

Si la grille des commandes mérite d’être enrichie, la grille des produits le mérite tout autant — c’est même souvent là que le gain de temps quotidien est le plus net. Modifier un prix, ajuster un stock, changer une visibilité : par défaut, chacune de ces actions oblige à ouvrir la fiche produit complète, l’enregistrer, puis revenir à la liste. Sur un catalogue de plusieurs centaines de références, ces allers-retours représentent des heures perdues chaque mois.

Amasty Extended Product Grid with Editor est l’extension que nous installons systématiquement sur les boutiques avec un catalogue actif. Son principe : permettre l’édition directement depuis la grille, sans ouvrir chaque fiche produit.

L’extension propose deux modes de sauvegarde : cellule par cellule, où chaque modification s’enregistre immédiatement (le plus sûr, recommandé pour des changements ponctuels), et en masse, où vous modifiez plusieurs champs puis validez en une seule fois (plus rapide pour les gros volumes, mais à utiliser avec un peu plus de vigilance pour éviter une erreur de saisie qui s’appliquerait à plusieurs lignes d’un coup).

Autre point pratique : la grille supporte la gestion multi-source si votre boutique gère plusieurs entrepôts ou points de stock — vous pouvez ajuster la quantité disponible par source directement depuis une fenêtre contextuelle, sans changer d’écran.

Combinée à Mass Product Actions

Pour aller plus loin, Amasty propose une extension complémentaire — Mass Product Actions — qui permet d’appliquer des opérations encore plus poussées sur une sélection de produits : ajuster un prix de +10€ sur toute une catégorie en une seule action, dupliquer une image vers plusieurs fiches produit, changer un jeu d’attributs en masse. La combinaison des deux extensions couvre la quasi-totalité des besoins de gestion catalogue au quotidien, sans jamais ouvrir une fiche produit individuellement.

Les limites à connaître

Les extensions de grille ne sont pas une solution magique universelle. Pour des besoins vraiment spécifiques — un calcul métier complexe affiché en colonne, une logique conditionnelle propre à votre activité — un développement sur-mesure reste parfois nécessaire. De même, l’ajout de nombreuses colonnes calculées peut légèrement ralentir le chargement de la grille sur un très gros volume de commandes ; un bon prestataire saura identifier l’équilibre entre richesse d’information et performance.

FAQ

Cette extension fonctionne-t-elle avec Magento 2.4.8 et 2.4.9 ?

Amasty maintient ses extensions à jour avec les dernières versions Magento — vérifiez toujours la compatibilité exacte sur la fiche produit avant l’achat, car les correctifs de compatibilité sont publiés progressivement après chaque sortie majeure de Magento.

Faut-il un développeur pour l’installer ?

L’installation initiale (déploiement du module, mise en cache) nécessite un accès technique standard à votre serveur. Une fois installée, la configuration quotidienne des colonnes et filtres se fait sans aucune compétence en développement.

Peut-on revenir à la grille par défaut si besoin ?

Oui — les colonnes ajoutées sont simplement décochables depuis le menu Columns, et l’extension peut être désactivée sans perte de données sur vos commandes ou vos clients.

L’article Améliorer les grilles commandes et clients Magento 2 avec Amasty est apparu en premier sur eBusiness360.

Magento 2.4.8 et 2.4.9 ont chacune leurs propres exigences serveur. Mal configurées, elles laissent filer de la performance et exposent votre boutique à des risques évitables. Bien configurées — et surveillées dans le temps —, elles deviennent un avantage silencieux mais réel sur vos concurrents.

Pourquoi le serveur reste invisible jusqu’au jour où il ne l’est plus

Un serveur bien réglé, c’est un peu comme une bonne assurance : on ne pense jamais à elle jusqu’au jour où on en a besoin. Tant que votre boutique tourne, vous ne voyez pas la différence entre un PHP-FPM mal dimensionné et un PHP-FPM optimisé. La différence apparaît au pire moment : un pic de trafic pendant une promotion, un Black Friday, une campagne publicitaire qui fonctionne mieux que prévu — et là, votre boutique ralentit ou plante, pendant que les commandes auraient dû s’enchaîner.

Ce qui change concrètement entre 2.4.8 et 2.4.9

Sans entrer dans tous les détails techniques — ce n’est pas l’objet de cet article ni votre rôle de les maîtriser —, voici ce qu’il faut retenir : ces deux versions n’ont pas les mêmes exigences serveur, et un paramétrage pensé pour l’une n’est pas automatiquement optimal pour l’autre.

Le point important n’est pas que vous mémorisiez ces différences, mais que vous compreniez qu’elles existent — et qu’elles ont un impact réel sur la vitesse de votre boutique, sur votre référencement (Google pénalise les sites lents), et sur votre taux de conversion.

Les trois piliers d’un serveur Magento bien réglé

Pour vous donner une idée de ce qui se cache derrière « optimiser le serveur » sans vous noyer dans le jargon, voici les trois grands axes sur lesquels un prestataire technique travaille en continu.

Le dimensionnement — donner au serveur ce qu’il lui faut, ni plus ni moins

Un serveur sous-dimensionné plante dès qu’il y a un peu d’affluence. Un serveur surdimensionné, c’est de l’argent dépensé pour rien chaque mois. Le juste équilibre dépend de votre trafic réel, de la saisonnalité de votre activité, et des pics que vous connaissez (soldes, fêtes, campagnes marketing). C’est un calcul qui se fait avec des données concrètes — pas à l’intuition — et qui doit être réévalué régulièrement à mesure que votre boutique grandit.

La mise en cache — la différence entre 0,2 seconde et 3 secondes

Chaque fois qu’un visiteur charge une page de votre boutique, le serveur peut soit tout recalculer depuis zéro, soit servir une version déjà préparée et stockée en mémoire. La seconde option est dix à vingt fois plus rapide. Les systèmes de cache adaptés à Magento 2.4.8 et 2.4.9 ne se configurent pas de la même façon — encore une fois, ce n’est pas à vous de le savoir, c’est à votre prestataire de s’en assurer.

La surveillance continue — le vrai métier derrière l’optimisation

C’est l’aspect le plus sous-estimé. Un serveur bien configuré aujourd’hui peut devenir mal adapté dans six mois si votre catalogue a doublé, si votre trafic a augmenté, ou si une mise à jour Magento a changé certains comportements internes. La surveillance continue, c’est repérer ces dérives avant qu’elles ne deviennent un problème visible — un panier qui n’arrive pas à se valider, une fiche produit qui met trois secondes à s’afficher, un pic d’erreurs serveur la nuit pendant un import automatique.

Ce que vous risquez à ne pas avoir ce suivi

Ce qu’on fait concrètement chez eBusiness360

Sur les boutiques que nous accompagnons, l’optimisation et la surveillance serveur ne sont pas un service ponctuel facturé une fois — c’est un suivi continu. Concrètement, cela veut dire des vérifications régulières des temps de réponse, une vigilance sur les nouvelles exigences à chaque montée de version Magento, et des ajustements proactifs quand on détecte qu’un seuil commence à être tendu, plutôt que d’attendre que ça casse.

L’objectif n’est pas que vous deveniez expert serveur. C’est que vous puissiez vous concentrer entièrement sur votre activité — votre catalogue, vos clients, votre marketing — en sachant que la partie technique est entre des mains qui la maîtrisent et la surveillent activement.

FAQ

Mon hébergeur ne s’occupe-t-il pas déjà de ça ?

Pas forcément, et c’est une confusion fréquente. La plupart des hébergeurs garantissent que le serveur fonctionne et reste accessible — ils ne configurent pas spécifiquement les réglages propres à Magento ni ne surveillent les performances de votre boutique en particulier. C’est un métier différent, qui nécessite de connaître Magento de l’intérieur.

Comment savoir si ma boutique a un problème de ce type aujourd’hui ?

Les signes les plus courants : des pages qui mettent plus de 2-3 secondes à charger, des ralentissements pendant vos pics de trafic, des erreurs occasionnelles non expliquées au checkout, ou simplement le sentiment que « ça pourrait être plus rapide ». Un audit technique permet de objectiver la situation en quelques heures.

Est-ce nécessaire même pour une petite boutique ?

Oui, dans une mesure adaptée à votre taille. Une petite boutique n’a pas besoin du même niveau de surveillance qu’un site à fort trafic, mais les bases (cache correctement configuré, version PHP à jour, sauvegardes fonctionnelles) restent indispensables quelle que soit la taille de l’activité.

L’article Serveur Magento 2.4.8 / 2.4.9 : le paramétrage qui fait la différence est apparu en premier sur eBusiness360.

Redis, Varnish, OPcache — ces trois outils forment le triptyque de performance de toute boutique Magento sérieuse. Voici comment ils fonctionnent, comment les configurer, et comment mesurer les gains.

Comment Magento gère le cache — vue d’ensemble

Avant de plonger dans la configuration, il faut comprendre qu’il existe plusieurs niveaux de cache dans Magento, chacun ayant un rôle différent. Les confondre, c’est souvent la source de configurations sous-optimales.

Varnish — le cache full-page qui fait la vraie différence

Varnish est un serveur de cache HTTP qui se place devant votre serveur web. Quand un visiteur arrive sur une page de votre boutique, Varnish vérifie si cette page est en cache. Si oui, il la renvoie directement — sans que PHP, Magento ou MySQL aient à faire quoi que ce soit. Le temps de réponse passe de plusieurs secondes à quelques dizaines de millisecondes.

C’est de loin la configuration qui a le plus d’impact sur la performance perçue par vos clients. Une boutique Magento sans Varnish en production, c’est comme rouler sur autoroute en première.

Pour activer Varnish sur Magento, la configuration se fait dans Stores → Configuration → Advanced → System → Full Page Cache. Sélectionnez « Varnish Cache » comme moteur, renseignez l’adresse et le port de votre serveur Varnish, et générez le fichier VCL depuis l’interface admin — Magento le génère automatiquement selon votre configuration.

# Vérifier que Varnish est actif et répond
varnishstat -1 | grep cache_hit
# Un ratio cache_hit / cache_miss > 80% est un bon indicateur

Un point important : Varnish ne cache que les pages accessibles sans authentification. Les pages de compte client, le panier et le checkout sont toujours servis par PHP — c’est le comportement normal et attendu.

Redis — le cache applicatif qui soulage votre base de données

Redis est une base de données en mémoire ultra-rapide. Sur Magento, il joue deux rôles distincts qu’il faut configurer séparément : le cache applicatif (configuration, blocs, layout) et le stockage des sessions clients.

Sans Redis, Magento stocke son cache dans des fichiers sur le disque — ce qui est lent et peu efficace sur un catalogue volumineux. Avec Redis, les données fréquemment accédées sont en RAM, réduisant drastiquement les requêtes vers MySQL.

La configuration se fait dans le fichier app/etc/env.php de votre installation Magento :

'cache' => [
    'frontend' => [
        'default' => [
            'backend' => 'Magento\Framework\Cache\Backend\Redis',
            'backend_options' => [
                'server' => '127.0.0.1',
                'port' => '6379',
                'database' => '0',
            ],
        ],
        'page_cache' => [
            'backend' => 'Magento\Framework\Cache\Backend\Redis',
            'backend_options' => [
                'server' => '127.0.0.1',
                'port' => '6379',
                'database' => '1',
            ],
        ],
    ],
],
'session' => [
    'save' => 'redis',
    'redis' => [
        'host' => '127.0.0.1',
        'port' => '6379',
        'database' => '2',
    ],
],

Notez l’utilisation de trois bases Redis différentes (database 0, 1 et 2) pour séparer le cache applicatif, le cache full-page et les sessions. C’est une bonne pratique qui évite les collisions et facilite le diagnostic.

OPcache — le booster PHP invisible

PHP compile vos fichiers source en bytecode à chaque exécution — ou du moins, c’est ce qu’il fait sans OPcache. OPcache garde ce bytecode en mémoire après la première compilation. Résultat : les requêtes suivantes sont servies sans recompilation, ce qui réduit significativement la charge CPU.

OPcache est intégré à PHP depuis la version 5.5 — pas besoin de l’installer. Il suffit de le configurer correctement dans votre php.ini ou dans le fichier de configuration de votre pool PHP-FPM :

opcache.enable=1
opcache.memory_consumption=512
opcache.interned_strings_buffer=64
opcache.max_accelerated_files=60000
opcache.revalidate_freq=0
opcache.save_comments=1
opcache.enable_cli=0

Le paramètre opcache.memory_consumption=512 alloue 512 Mo à OPcache — une valeur adaptée à une boutique Magento standard. Sur un catalogue très large avec de nombreuses extensions, 512 Mo peut ne pas suffire et mérite d’être augmenté. La valeur opcache.max_accelerated_files=60000 couvre la grande majorité des installations Magento.

Comment mesurer les gains ?

Avant de toucher quoi que ce soit, mesurez votre baseline. L’outil de référence est PageSpeed Insights (pagespeed.web.dev) — il vous donne les Core Web Vitals réels (LCP, INP, CLS) mesurés sur de vrais utilisateurs, et les métriques lab pour diagnostiquer les problèmes.

Les erreurs de configuration les plus fréquentes

Varnish configuré mais non utilisé

C’est plus courant qu’on ne le pense : Varnish est installé, Magento est configuré pour l’utiliser, mais le trafic ne passe pas réellement par Varnish. La cause la plus fréquente est une mauvaise configuration des headers X-Forwarded-Proto ou des trusted_proxies dans env.php — Magento ne reconnaît pas les requêtes comme venant de Varnish et génère un bypass. Résultat : performance dégradée et cache jamais utilisé.

Redis saturé faute de politique d’éviction

Redis stocke tout en RAM. Sans politique d’éviction configurée, il finit par saturer et commence à rejeter les écritures — ce qui se manifeste par des erreurs inexpliquées et un Magento qui ralentit brusquement. Configurez toujours maxmemory-policy allkeys-lru dans votre redis.conf pour que Redis supprime automatiquement les entrées les moins récentes quand il approche de sa limite.

OPcache vidé automatiquement trop souvent

Le paramètre opcache.revalidate_freq=0 désactive la revalidation automatique des fichiers en production — PHP ne vérifie plus si les fichiers source ont changé. C’est optimal en production (les fichiers ne changent pas entre deux déploiements), mais attention : il faudra vider manuellement l’OPcache après chaque déploiement, sinon PHP continue d’exécuter l’ancien code.

FAQ

Mon hébergeur mutualisé supporte-t-il ces configurations ?

Rarement. Varnish nécessite un serveur dédié ou un VPS avec accès root. Redis est parfois disponible en option sur certains hébergeurs managés. OPcache est généralement activé par défaut mais avec des paramètres peu adaptés à Magento. Si votre boutique génère un chiffre d’affaires significatif, un serveur dédié ou un VPS bien configuré est indispensable.

Faut-il tout configurer en même temps ?

Non — et c’est même déconseillé. Commencez par OPcache (le plus simple, souvent déjà actif), puis Redis, puis Varnish. Cette progression vous permet de mesurer l’impact de chaque composant séparément et de diagnostiquer plus facilement si quelque chose se passe mal.

L’article Performances Magento 2 : Redis, Varnish et OPcache en pratique est apparu en premier sur eBusiness360.

Cet article s’adresse aux développeurs Magento débutants qui veulent monter un environnement local fonctionnel sans passer trois jours à déboguer leur configuration Docker.

La stack — pourquoi DDEV sur WSL2 ?

Travailler directement sous Windows avec XAMPP ou Laragon est possible, mais Magento 2 souffre de performances médiocres sur le système de fichiers Windows natif. La bonne approche est de faire tourner tout l’environnement dans WSL2 (Windows Subsystem for Linux), qui offre des performances proches d’un Linux natif, tout en gardant vos outils Windows (VS Code, navigateur, FileZilla) accessibles.

Pour l’IDE, VS Code avec l’extension « Remote – WSL » est le choix le plus simple : vous éditez les fichiers directement dans WSL depuis Windows, sans friction. PhpStorm fonctionne aussi avec une configuration remote interpreter pointant vers le conteneur DDEV.

Les étapes de l’installation

Écueil n°1 — La reconstruction des conteneurs DDEV

Quand vous modifiez un Dockerfile ou une configuration de service DDEV, le réflexe Docker classique est d’utiliser --build. C’est faux avec DDEV. La bonne commande pour forcer la reconstruction complète en ignorant le cache :

ddev restart --no-cache

Écueil n°2 — L’enfer de la syntaxe YAML

DDEV utilise des fichiers YAML pour les configurations de services additionnels (.ddev/docker-compose.*.yaml). Deux erreurs très fréquentes :

• Les tabulations — YAML n’accepte que des espaces. Si votre éditeur insère des tabs, DDEV plantera avec une erreur did not find expected key peu explicite.
• L’attribut version — les anciens tutoriels commencent par version: "3". Avec Docker Compose V2, cet attribut est obsolète et génère des erreurs. Supprimez-le.

Écueil n°3 — L’alerte SSL sous Firefox

DDEV génère ses propres certificats SSL pour les domaines *.ddev.site. Sous WSL2, Firefox Windows ne communique pas avec le store de certificats WSL et affiche une alerte rouge « Risque potentiel de sécurité ».

Ne perdez pas de temps à faire communiquer les stores de certificats Windows et WSL. La solution pragmatique : cliquer sur « Avancé » puis « Continuer (risqué) » dans Firefox. Sur un domaine *.ddev.site qui pointe uniquement vers 127.0.0.1, c’est 100% sécurisé. Firefox ajoute une exception permanente.

Écueil n°4 — Le bug Calendar.php et ICU 74+

Sur Magento 2.4.6 et 2.4.7 avec PHP 8.x et ICU ≥ 74.1, tenter d’accéder au back-office en français produit une page blanche :

Warning: Trying to access array offset on value of type null
in vendor/magento/framework/View/Element/Html/Calendar.php on line 114

ICU 74+ a supprimé les marqueurs AM/PM pour les langues qui utilisent le format 24h. Le patch rapide sur le fichier vendor :

// Avant (ligne 114)
$this->assign('am', $this->encoder->encode($localeData['calendar']['gregorian']['AmPmMarkers']['0']));
$this->assign('pm', $this->encoder->encode($localeData['calendar']['gregorian']['AmPmMarkers']['1']));

// Après
$this->assign('am', $this->encoder->encode($localeData['calendar']['gregorian']['AmPmMarkers']['0'] ?? 'AM'));
$this->assign('pm', $this->encoder->encode($localeData['calendar']['gregorian']['AmPmMarkers']['1'] ?? 'PM'));

Ce bug est corrigé nativement en Magento 2.4.8. Si vous modifiez ce fichier, documentez-le — un composer update l’écrasera silencieusement.

Post-migration — les deux bloqueurs classiques

Bloqueur n°1 — Les cookies rejetés, impossible de se connecter à l’admin

La base contient encore le domaine de production dans core_config_data. Le piège classique : bin/magento config:set web/cookie/cookie_domain "" — Bash supprime les guillemets vides et la commande plante silencieusement.

La méthode imparable :

ddev mysql -e "DELETE FROM core_config_data WHERE path IN ('web/cookie/cookie_domain', 'web/cookie/cookie_path');"
ddev exec php bin/magento cache:flush

Bloqueur n°2 — Les images en 404

Télécharger l’intégralité de pub/media/ de production est inenvisageable. La solution : un fallback Nginx qui va chercher les images manquantes sur la prod de façon transparente. À ajouter dans .ddev/nginx_full/nginx-site.conf :

location /media/ {
    try_files $uri $uri/ @production_fallback;
}

location @production_fallback {
    proxy_pass https://www.votre-site-de-prod.com;
    proxy_ssl_server_name on;  # Indispensable si prod derrière Cloudflare ou CDN
    proxy_http_version 1.1;
    proxy_set_header Host www.votre-site-de-prod.com;
}

Le paramètre proxy_ssl_server_name on est essentiel si votre prod est derrière Cloudflare ou un CDN — sans lui, la connexion SSL est rejetée avec une erreur 502. Après modification :

ddev restart

Cheat sheet — les commandes DDEV indispensables

Un point important sur les modifications vendor/

Si vous modifiez un fichier dans vendor/ pour corriger un bug local, documentez-le immédiatement — dans un fichier PATCHES.md à la racine du projet. Un composer install ou composer update écrasera silencieusement vos modifications.

La solution pérenne est de gérer ce type de correctif via cweagans/composer-patches qui réapplique automatiquement les modifications après chaque mise à jour. C’est l’approche recommandée pour tout correctif sur les fichiers vendor dans un projet sérieux.

FAQ

Pourquoi ne pas utiliser XAMPP ou Laragon directement sous Windows ?

Magento 2 souffre de performances très dégradées sur le système de fichiers Windows natif. La compilation, la génération des assets statiques et les opérations d’indexation peuvent être deux à cinq fois plus lentes que sous Linux. WSL2 + DDEV offre des performances comparables à un serveur Linux réel.

Peut-on utiliser DDEV avec une version Magento antérieure à 2.4 ?

Oui — DDEV permet de configurer des versions PHP anciennes. Pour Magento 2.3.x, configurer PHP 7.4 dans .ddev/config.yaml. La plupart des fonctionnalités DDEV restent disponibles, mais certains services comme Elasticsearch peuvent nécessiter une version spécifique.

Comment gérer plusieurs projets Magento en parallèle ?

DDEV gère nativement plusieurs projets simultanément — chaque projet a son propre répertoire avec son propre .ddev/config.yaml, son propre domaine local et ses propres conteneurs, sans conflit de ports. La commande ddev list affiche tous les projets et leur état.

L’article Faire tourner Magento 2 en local sous Windows 11 : DDEV + WSL2, le guide de survie est apparu en premier sur eBusiness360.

On va parcourir ensemble la procédure complète : de la préparation à la mise en production, en passant par les pièges à éviter et la marche à suivre si quelque chose se passe mal. Basé sur notre expérience de plusieurs dizaines de mises à jour sur des boutiques en production.

Avant de toucher quoi que ce soit — la checklist de préparation

La grande majorité des problèmes lors d’une mise à jour Magento viennent d’une préparation insuffisante. Ne jamais commencer une mise à jour sans avoir coché ces points :

La procédure complète — étape par étape

Voici la séquence que nous appliquons systématiquement sur toutes les boutiques que nous maintenons. L’ordre est important — ne pas le modifier.

Étape 1 — Mettre Magento en mode maintenance

Avant toute manipulation, activer le mode maintenance empêche vos clients d’accéder à la boutique pendant la mise à jour. Ça évite les commandes passées au mauvais moment et les erreurs visibles côté client.

php bin/magento maintenance:enable

Étape 2 — Mettre à jour les dépendances avec Composer

C’est ici que le patch est téléchargé et appliqué. La commande varie selon le type de mise à jour — patch de sécurité mineur ou montée de version complète :

# Pour un patch de sécurité (ex : 2.4.7-p4 → 2.4.7-p5)
composer require magento/product-community-edition 2.4.7-p5 --no-update
composer update magento/product-community-edition --with-dependencies

# Pour une montée de version (ex : 2.4.7 → 2.4.8)
composer require magento/product-community-edition 2.4.8 --no-update
composer update --with-all-dependencies

Étape 3 — Lancer les migrations de base de données

Cette commande applique les modifications de schéma en base de données apportées par la nouvelle version. Elle est obligatoire — ne jamais la sauter.

php bin/magento setup:upgrade

Étape 4 — Recompiler l’injection de dépendances

Magento utilise un système d’injection de dépendances qui doit être recompilé après chaque mise à jour. C’est ce qui génère les fichiers dans generated/.

php bin/magento setup:di:compile

Étape 5 — Déployer les fichiers statiques

Cette étape génère tous les assets frontend (CSS, JS, images) pour votre thème. C’est souvent l’étape la plus longue — comptez entre 5 et 20 minutes selon la taille de votre boutique.

# Adapter les locales et thèmes à votre configuration
php bin/magento setup:static-content:deploy -f   --theme Magento/luma   --theme Vendor/your-theme   fr_FR en_US -j4

Étape 6 — Vider les caches

Deux actions distinctes : vider l’OPcache PHP (qui met en cache le bytecode PHP) et vider les caches Magento (config, full-page, layout…).

# Vider l'OPcache PHP (si vous avez un script dédié)
curl https://votre-boutique.fr/clear_opcache.php

# Vider les caches Magento
php bin/magento cache:flush

Étape 7 — Désactiver le mode maintenance et tester

php bin/magento maintenance:disable

Votre boutique est de nouveau accessible. Avant d’annoncer que tout est bon, parcourir rapidement le tunnel de commande complet : navigation catalogue → fiche produit → ajout au panier → checkout → confirmation. C’est le test minimal qui valide que rien n’est cassé côté client.

Les pièges les plus fréquents

L’OPcache qui garde l’ancien code en mémoire

C’est le piège numéro un. PHP met en cache le bytecode de vos fichiers pour aller plus vite. Après une mise à jour, si l’OPcache n’est pas vidé, PHP continue d’exécuter l’ancienne version du code — même si les fichiers ont été mis à jour sur le disque. Le symptôme : des erreurs étranges qui disparaissent après un redémarrage PHP-FPM ou un vidage d’OPcache.

Le static content deploy incomplet

Si vous avez plusieurs store views avec des locales différentes, vous devez déployer les assets pour chaque locale. Oublier une locale, c’est avoir des pages sans CSS ou avec des images manquantes sur certaines versions de votre boutique. Toujours vérifier que toutes vos locales sont incluses dans la commande de déploiement.

Les permissions de fichiers incorrectes

Après un composer update, certains nouveaux fichiers peuvent appartenir à l’utilisateur root si la commande a été lancée en sudo. Magento a besoin que ses fichiers appartiennent à l’utilisateur web (www-data, nginx…). Un problème de permissions se manifeste souvent par des erreurs 500 inexpliquées ou des pages blanches après la mise à jour.

Et si quelque chose se passe mal ?

Ça arrive, même avec la meilleure préparation. L’essentiel est de ne pas paniquer et d’avoir prévu le rollback avant de commencer. Concrètement, un rollback sur Magento c’est :

1. Restaurer la sauvegarde base de données
2. Restaurer les fichiers depuis la sauvegarde (ou via git checkout si vous utilisez Git)
3. Vider l’OPcache et les caches Magento
4. Désactiver le mode maintenance

Avec une sauvegarde récente et un plan clair, revenir en arrière prend rarement plus de 15 minutes. C’est pour ça que la sauvegarde est le premier point de la checklist — pas le dernier.

FAQ

Faut-il forcément un environnement de test ?

Pour un patch de sécurité mineur (ex : 2.4.7-p4 → 2.4.7-p5), le risque est limité et certaines équipes appliquent directement en production avec une bonne sauvegarde. Pour une montée de version majeure (ex : 2.4.6 → 2.4.8), un environnement de test est indispensable — les risques de casse sont bien plus élevés.

Combien de temps dure une mise à jour ?

Pour un patch de sécurité sur une boutique standard : 30 à 60 minutes. Pour une montée de version complète avec plusieurs extensions : comptez 2 à 4 heures de travail effectif, hors tests. La durée du mode maintenance côté client est généralement de 10 à 30 minutes si tout se passe bien.

Peut-on automatiser ces mises à jour ?

Partiellement. Les patches de sécurité mineurs peuvent être semi-automatisés avec des scripts de déploiement. Mais une validation humaine reste recommandée après chaque mise à jour — notamment pour vérifier que le tunnel de commande fonctionne correctement. L’automatisation complète sans supervision augmente le risque de laisser passer un problème silencieux.

L’article Déployer un patch Magento 2 sans casser la production : procédure pas à pas est apparu en premier sur eBusiness360.