Mettre à jour PrestaShop en ligne de commande sans l'interface graphique
Publié le par Alexandre Normand révisé le 27/05/2026
L'interface graphique du module AutoUpgrade de Prestashop est pratique, mais elle a une limite concrète : elle tourne dans le navigateur. Une mise à jour qui dure 20 minutes sur un serveur lent peut se terminer par un timeout HTTP, une page blanche, ou pire, un site cassé
La CLI ne souffre pas de ce problème. Elle tourne directement sur le serveur, sans navigateur, sans timeout, et elle laisse un log complet.
Ce guide couvre la mise à jour en ligne de commande avec le module AutoUpgrade 7.x, disponible à partir de PrestaShop 8.x et compatible avec PrestaShop 9.x.
Prérequis
Avant de commencer, quelques vérifications indispensables.
Version du module AutoUpgrade : La CLI est disponible uniquement à partir de la version 7.0. Vérifie la tienne :
cat modules/autoupgrade/autoupgrade.php | grep "\$this->version" | head -1
Si tu es en dessous de 7.0, mets d'abord à jour le module via le back-office ou en téléchargeant la dernière version sur l'addons PrestaShop.
Accès SSH : Tu en auras besoin pour toutes les commandes de ce guide.
PHP en CLI : Vérifie que PHP est accessible et en version compatible
php -v
- PrestaShop 9.x requiert PHP 8.1 minimum. PrestaShop 8.x fonctionne avec PHP 7.4 à 8.2.
- Mémoire PHP : Les opérations de mise à jour sont gourmandes. Toujours préfixer tes commandes avec -d memory_limit=2G pour éviter les erreurs d'allocation mémoire en cours de route.
Étape 1 : Sauvegarder avant tout
C'est l'étape que tout le monde zappe et que tout le monde regrette. Une mise à jour PrestaShop modifie des fichiers core, des fichiers de configuration Symfony, et peut altérer la structure de la base de données. Sans backup, un rollback est impossible.
Personnellement, je passe cet étape, car j'ai déjà un système de sauvegarde automatique.
Sauvegarder la base de données
mysqldump -u TON_USER -p TON_NOM_BDD > backup_bdd_$(date +%Y%m%d_%H%M).sql
Les identifiants sont dans app/config/parameters.php si tu ne les as pas sous la main.
Sauvegarder les fichiers critiques
L'AutoUpgrade sauvegarde les fichiers core, mais il ne touche pas à ton thème enfant ni à tes overrides. Ces répertoires sont les tiens, archive-les :
tar -czf backup_theme_$(date +%Y%m%d).tar.gz themes/nom-de-ton-theme/
tar -czf backup_override_$(date +%Y%m%d).tar.gz override/
tar -czf backup_modules_$(date +%Y%m%d).tar.gz modules/
Le module AutoUpgrade propose aussi sa propre commande de backup :
php -d memory_limit=2G modules/autoupgrade/bin/console backup:create admin_dev
Remplace admin_dev par le nom réel de ton dossier d'administration. Pour le trouver :
ls -d */ | grep -i admin
Pour lister les backups existants :
php -d memory_limit=2G modules/autoupgrade/bin/console backup:list admin_dev
Le backup de l'AutoUpgrade couvre les fichiers core et la base de données, mais il peut atteindre plusieurs centaines de Mo selon la taille de ta boutique. Garde tes propres archives en parallèle, elles sont plus légères et plus rapides à restaurer sur des éléments ciblés.
Étape 2 : Vérifier la disponibilité des mises à jour
php -d memory_limit=2G modules/autoupgrade/bin/console update:check-new-version admin_dev
La commande retourne un tableau indiquant la version disponible, le canal (stable, beta), et le type de mise à jour (patch, minor, major). Pour une mise en production, reste sur le canal online_recommended.
Étape 3 : Vérifier les prérequis
Personnellement, les étapes 3 et 4, je préfère les faire avec l'interface visuelle.
php -d memory_limit=2G modules/autoupgrade/bin/console update:check-requirements admin_dev
Cette commande passe en revue les points bloquants : version PHP, extensions PHP manquantes, permissions de fichiers, espace disque disponible. Règle tout ce qui est marqué comme erreur avant de continuer. Les avertissements (warnings) ne bloquent pas la mise à jour mais méritent attention.
Étape 4 : Vérifier la compatibilité des modules
php -d memory_limit=2G modules/autoupgrade/bin/console update:check-modules admin_dev
Cette commande liste tes modules et indique lesquels sont compatibles avec la version cible. Les modules incompatibles peuvent être désactivés automatiquement pendant la mise à jour. Ce comportement par défaut est raisonnable pour éviter les erreurs 500, mais si tu veux garder la main dessus, vérifie les options disponibles :
php -d memory_limit=2G modules/autoupgrade/bin/console update:start --help
Étape 5 : Lancer la mise à jour
php -d memory_limit=2G modules/autoupgrade/bin/console update:start admin_dev --no-interaction 2>&1 | tee upgrade_log.txt
Quelques précisions sur cette commande :
- --no-interaction évite que la commande s'arrête en attente d'une confirmation manuelle. Indispensable si tu lances ça depuis un script ou une session SSH qui peut se fermer.
- 2>&1 redirige les erreurs PHP (stderr) dans le même flux que la sortie standard, pour qu'elles apparaissent dans le log.
- | tee upgrade_log.txt enregistre tout dans un fichier tout en affichant la progression dans le terminal. En cas de problème, tu as une trace complète.
Combien de temps ça prend ?
Difficile de donner un chiffre exact, ça dépend du serveur, du nombre de fichiers, de la taille de la base de données, et du nombre de modules installés. En pratique :
- Mise à jour patch (ex. 9.1.1 → 9.1.3) sur un VPS standard : entre 5 et 15 minutes
- Mise à jour minor (ex. 9.0.x → 9.1.x) : entre 15 et 40 minutes
- Mise à jour major (ex. 8.x → 9.x) : entre 30 minutes et plus d'une heure
La phase la plus longue est généralement la copie des fichiers core et la régénération du cache Symfony. Sur des hébergements mutualisés avec peu de RAM, ça peut prendre deux fois plus longtemps.
Ne ferme pas le terminal pendant l'opération. Si ta session SSH risque de timeout, utilise screen ou tmux pour lancer la commande dans une session persistante :
screen -S upgrade
# lance ta commande, puis Ctrl+A D pour détacher
screen -r upgrade # pour reprendre
Étape 6 : Vider le cache après la mise à jour
La mise à jour régénère partiellement le cache, mais un vidage manuel reste recommandé pour s'assurer que rien de l'ancienne version ne subsiste :
php -d memory_limit=1G bin/console cache:clear --env=prod
Si tu travailles en environnement de développement :
php -d memory_limit=1G bin/console cache:clear --env=dev
Que faire si ça tourne mal ?
Erreur 500 après la mise à jour
Active le mode debug pour voir l'erreur réelle. Dans config/defines.inc.php, passe _PS_MODE_DEV_ à true, ou modifie .htaccess temporairement. Le message d'erreur affiché dans le navigateur est souvent trop vague pour diagnostiquer quoi que ce soit.
Le vendor est incomplet
Si tu vois des erreurs du type Failed to open stream: No such file or directory pointant vers vendor/, Composer n'a pas terminé son travail correctement. Relance :
php -d memory_limit=2G /usr/local/bin/composer install --optimize-autoloader --no-interaction
Si Composer se plaint d'un conflit entre composer.json et composer.lock, régénère d'abord le lock file :
php -d memory_limit=2G /usr/local/bin/composer update --lock --no-interaction
Puis relance l'install.
Un package spécifique est corrompu
Si un répertoire dans vendor/ existe mais est vide ou incomplet (juste un fichier LICENSE par exemple), force la réinstallation du package :
php -d memory_limit=2G /usr/local/bin/composer reinstall symfony/nom-du-package --optimize-autoloader
Rollback complet
Si la mise à jour a créé trop de dégâts et que tu veux revenir à l'état précédent :
php -d memory_limit=2G modules/autoupgrade/bin/console backup:restore admin_dev
La commande liste les backups disponibles et te demande lequel restaurer.
Sources
Astuces
Faire la mise à jour en heures creuses. Même si le site continue de fonctionner pendant la mise à jour pour la plupart des opérations, certaines phases (notamment la mise à jour de la BDD) peuvent créer des incohérences temporaires. Planifie ça en dehors des heures de trafic.
Tester en staging d'abord. Si tu as un environnement de recette, applique toujours la mise à jour là-bas avant la production. Les incompatibilités de modules se détectent bien mieux à froid que sous le feu du service.
Ne pas mettre à jour core et modules en même temps. Fais la mise à jour PrestaShop, vérifie que tout fonctionne, puis mets à jour tes modules séparément. Mélanger les deux rend le diagnostic impossible en cas de problème.
Vérifier les overrides après mise à jour. Les fichiers dans override/ ne sont pas supprimés, mais si PrestaShop a modifié la classe que tu surcharges, ton override peut silencieusement casser un comportement. Passe en revue override/classes/ et override/controllers/ après chaque mise à jour majeure.
Surveiller les logs. Après remise en service, garde un oeil sur var/logs/ pendant quelques heures. Les erreurs qui ne génèrent pas de 500 visibles (erreurs dans des hooks, modules qui plantent silencieusement) se retrouvent là.
Vérifier la version installée. Pour confirmer que la mise à jour a bien abouti, va dans le back-office sous Paramètres avancés > Informations.
Test le parcours d'un client. Utilise ta boutique comme un client, de la connexion au paiement.
Avertissement
Cet article a été rédigé avec l'assistance d'une IA (Claude, développé par Anthropic), à partir d'un cas concret de mise à jour de PrestaShop 9.1.1 vers 9.1.3 réalisée en conditions réelles.
Les commandes présentées ont été testées dans ce contexte spécifique. Selon votre environnement (version PHP, hébergeur, configuration serveur, modules installés), certaines peuvent nécessiter des adaptations. En cas de doute ou de problème, LEXPROD ne pourra être tenu responsable.
Si vous n'êtes pas à l'aise avec les lignes de commande, il est tout à fait possible de vous faire assister par une IA pour ce type d'opération. Pour ce travail, nous recommandons Claude. Gardez cependant à l'esprit qu'un tel outil doit être correctement configuré et prompté pour produire des réponses fiables dans votre contexte précis.
