Update Assistant bloqué : réparer une mise à jour PrestaShop 9

Une mise à jour qui échoue laisse la boutique dans un état instable

L'Update Assistant PrestaShop est un excellent outil quand tout se passe bien. Quand il s'arrête au milieu, le site se retrouve avec des fichiers en version 9 et une base en version 8, ce qui produit des erreurs 500 illisibles. La première règle est donc simple : on ne lance jamais une mise à jour sans sauvegarde restaurable et testée.

Voici les échecs que nous rencontrons le plus souvent en intervention, avec leur cause et leur contournement.

« Can't empty cache directory »

C'est l'erreur la plus fréquente sur les passages 9.0.x vers 9.1.x, en particulier sous PHP 8.4.

Le module tente de vider var/cache/ et se heurte à des fichiers appartenant à un autre utilisateur système, typiquement parce que des commandes ont été lancées en SSH avec un compte différent de celui du serveur web.

Contournement :

rm -rf var/cache/prod var/cache/dev
chown -R www-data:www-data var/

Adaptez l'utilisateur à votre hébergement. Ne supprimez jamais var/cache lui-même : seulement son contenu.

« has a dependency on a non-existent service mbo.modules.repository »

Cette erreur, qui renvoie un HTTP 500 pendant l'étape de vérification de version, vient du conteneur d'injection de dépendances de Symfony resté incohérent : le module MBO (marketplace intégrée) est déclaré mais ses services ne sont pas construits.

Trois actions dans l'ordre :

1. Mettre à jour le module Update Assistant lui-même avant toute chose. Une version ancienne du module reste la première cause d'échec.
2. Supprimer le contenu de var/cache/ et vérifier que le dossier app/cache/ existe et est accessible en écriture.
3. Désactiver temporairement ps_mbo dans ps_module, puis relancer.

Le processus s'arrête sans message

Sur les mutualisés, l'Update Assistant se heurte à trois limites invisibles : max_execution_time, la mémoire, et le timeout du serveur web lui-même. L'interface affiche alors une roue qui tourne indéfiniment.

La solution consiste à passer par la ligne de commande, qui ne connaît pas le timeout HTTP :

php modules/autoupgrade/bin/console update:start --config-file-path=config.json

Vérifiez au préalable que symlink() n'est pas dans la liste disable_functions de votre configuration PHP : sans elle, la bascule des dossiers échoue silencieusement. Passez memory_limit à -1 pour la durée de l'opération.

Le piège de la reprise manuelle

Quand la mise à jour échoue à mi-parcours, la tentation est de rejouer « à la main » les fichiers SQL de migration. C'est un piège.

Ces fichiers contiennent des directives PHP encapsulées dans des commentaires SQL, de la forme /* PHP:add_column(...) */. Exécutés dans phpMyAdmin, ces commentaires sont ignorés : la structure de base paraît migrée alors que des colonnes et des données manquent. Les symptômes apparaissent des semaines plus tard, sur une fonctionnalité rarement utilisée.

Si la migration échoue, restaurez la sauvegarde et recommencez proprement. Ne réparez jamais une migration à moitié appliquée.

La préparation qui évite 80 % des échecs

Avant de lancer quoi que ce soit :

• Sauvegarder fichiers et base, et tester la restauration sur un environnement séparé.
• Désactiver tous les modules non natifs. Un module qui plante pendant la phase de mise à jour interrompt tout le processus. Vous les réactiverez un par un ensuite.
• Repasser sur le thème Classic le temps de l'opération, en particulier si votre thème surcharge des templates du cœur.
• Vérifier la version de PHP. PrestaShop 9 exige PHP 8.1 au minimum et accepte jusqu'à 8.4. Une mise à jour lancée sur du PHP 7.4 échouera immanquablement.
• Vérifier l'espace disque. Le processus duplique l'intégralité du site : il faut au moins deux fois la taille actuelle.
• Lister les modules incompatibles. PrestaShop 9 a retiré Guzzle, League Tactician et Swift Mailer. Tout module qui en dépend produira une erreur fatale après la bascule.

Après la mise à jour : la recette qui compte

Une mise à jour « réussie » n'est validée qu'une fois ces points vérifiés :

1. Passer une commande de bout en bout, paiement réel inclus.
2. Vérifier la réception des emails transactionnels, souvent cassés lors du passage en 9 à cause du changement de bibliothèque d'envoi.
3. Contrôler les transporteurs et les widgets de point relais au tunnel de commande.
4. Régénérer les miniatures et vérifier l'affichage des images produit.
5. Relire var/logs/ : les avertissements de dépréciation d'aujourd'hui sont les pannes de la prochaine version.

Si le passage en version 9 vous inquiète, notre article sur la fin de support de PrestaShop 8 vous aidera à décider du bon moment, et notre page migration PrestaShop détaille notre méthode.

Mise à jour bloquée en ce moment ?

Nous reprenons les migrations interrompues, y compris quand la boutique est déjà hors ligne. Diagnostic gratuit, réponse sous 1h, 9h-22h 7j/7.