Déployer un patch Magento 2 sans casser la production : procédure pas à pas

Un nouveau patch de sécurité vient de sortir pour Magento. Votre prestataire ou votre équipe technique doit l’appliquer — mais comment faire sans risquer de bloquer votre boutique en pleine journée ? C’est la question que tout e-commerçant se pose, et c’est exactement ce que couvre ce tutoriel.

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 :

Checklist avant toute mise à jour Magento

✓ Sauvegarde complète

Base de données + fichiers (pub/media, app/etc)

✓ Environnement de test prêt

La mise à jour doit être testée avant la prod

✓ Créneau de faible trafic

Nuit ou week-end — jamais en journée de pointe

✓ Extensions vérifiées

Compatibilité de chaque extension avec la nouvelle version

✓ Version PHP vérifiée

Compatibilité PHP requise par le patch

✓ Plan de rollback défini

Savoir comment revenir en arrière en urgence — avant de commencer

Six points à valider avant toute mise à jour — aucun n’est facultatif

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.

Séquence complète de déploiement

1. Maintenance

Activer le mode maintenance

2. composer update

Télécharger et appliquer le patch

3. setup:upgrade

Migrations base de données

4. di:compile

Recompiler l’injection de dépendances

5. static:deploy

Déployer les assets CSS/JS

6. cache:flush

Vider OPcache + caches Magento

7. Tests tunnel

Catalogue → panier → checkout → confirmation

Les 7 étapes dans l’ordre — ne pas en sauter une seule

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.