Montée de version de PHP pour PrestaShop : changer de PHP sans arrêter la boutique

Une boutique PrestaShop change de version de PHP sans arrêt quand la version visée entre dans la plage de sa version de PrestaShop, que la bascule a d’abord tourné sur une copie, modules et thème compris, et que l’ancienne version reste sélectionnable pour revenir en arrière. Hors de la plage, PrestaShop change de version en premier.

• La version de PHP visée se choisit sur le calendrier de php.net
• Au-delà de sa plage, une boutique PrestaShop change de version avant de changer de PHP
• Les modules et le thème de PrestaShop dépendent de leurs auteurs, pas de l’éditeur
• La bascule se répète sur une copie de la boutique PrestaShop, journaux ouverts
• Le retour arrière d’une montée de PHP se prépare avant la bascule
• Le prestataire livre un inventaire, une copie testée et une procédure de retour
• Une montée de PHP sur PrestaShop échoue par l’attente, le masquage et le debug oublié
• Sources consultées
• Foire aux questions

La version de PHP visée se choisit sur le calendrier de php.net

Selon php.net, consulté le 14 octobre 2026, chaque version de PHP reçoit deux ans de corrections complètes, puis deux ans de correctifs de sécurité seuls. Visez la plus récente que votre version de PrestaShop accepte : elle repousse le plus loin la bascule suivante.

Faites le calcul sur la troisième colonne. Scénario : une boutique en 9.1 qui passe en PHP 8.2 en octobre 2026 n’aura plus de correctifs de sécurité après le 31 décembre 2026 ; en PHP 8.5, sa prochaine échéance tombe le 31 décembre 2029.

Au-delà de sa plage, une boutique PrestaShop change de version avant de changer de PHP

Hors de la plage de votre PrestaShop, une version de PHP ne se teste pas : elle attend une montée de version de PrestaShop. Le plafond tient parfois à une version mineure. La documentation de l’éditeur arrête une 1.7.6 à PHP 7.2 et une 1.7.8 à PHP 7.4. De même, une 9.0 s’arrête à PHP 8.4, alors que la 9.1 et la 9.2 acceptent PHP 8.5. Relevez le numéro complet, à quatre chiffres plutôt que « 1.7 » : une mise à jour mineure suffit parfois. Au sein de la branche 8, rien ne bouge : PrestaShop 8 s’arrête à PHP 8.1, que php.net ne corrige plus depuis le 31 décembre 2025. PHP 8.1 appartient aussi à la plage de la branche 9. La boutique y passe sans changer de PHP, puis monte PHP dans un second temps (voir la migration de PrestaShop 8 vers 9). La 1.7.8 plafonne à PHP 7.4 et la 9 commence à PHP 8.1 : aucune version commune. D’après ces tableaux, PrestaShop 8 est la seule branche qui partage une version de PHP avec chacune d’elles, un point central d’une migration de PrestaShop 1.7 vers 9. La 1.6, elle, s’arrête à PHP 7.1, version sans correctif depuis le 1er décembre 2019. Procédez couche par couche : quand PHP et PrestaShop changent dans la même opération, une erreur devient difficile à rattacher à sa cause.

Les modules et le thème de PrestaShop dépendent de leurs auteurs, pas de l’éditeur

L’éditeur publie la plage de PHP de son cœur. Pour un module tiers ou un thème, seul son auteur peut répondre. Le manuel de PHP liste, pour chaque version, ce qui change. Une fonction supprimée arrête le script : PHP 8.0 a retiré « each() » et « create_function() », qu’un module écrit pour PHP 5 ou 7 peut encore appeler. Une fonction dépréciée, c’est-à-dire annoncée pour un retrait futur, produit seulement un avertissement. PHP 8.1 déprécie le passage de la valeur « null » à certains paramètres de fonctions internes, PHP 8.2 la création de propriétés dynamiques. Le journal se remplit, sans que la boutique s’arrête en principe. L’inventaire classe chaque module non natif : compatible selon son auteur, à mettre à jour, à corriger ou à remplacer. Un outil d’analyse du code comme PHPCompatibility, extension de PHP_CodeSniffer, repère une partie des incompatibilités ; ses auteurs reconnaissent une couverture incomplète. L’essai sur copie tranche.

La bascule se répète sur une copie de la boutique PrestaShop, journaux ouverts

Le prestataire copie fichiers et base vers une adresse de test réglée sur la version de PHP visée. Il vérifie d’abord les extensions : la documentation de PrestaShop 9 en exige treize, de cURL à Zip, et une version de PHP fraîchement installée n’en active pas forcément la totalité. Sur cette copie seulement, il active le mode debug, par Paramètres avancés > Performances ou par la constante _PS_MODE_DEV_, interrupteur du mode développeur, dans le fichier « config/defines.inc.php ». Les réglages par défaut cachent les messages d’erreur du serveur ; le mode debug les affiche. Le scénario de test suit le chemin de l’argent. Après une mise à jour, la liste de vérification de l’éditeur demande de créer un compte et de passer une commande. Ajoutez le paiement en mode test, un changement de statut de commande, l’édition d’un produit et chaque export vers un logiciel extérieur. Viennent ensuite les journaux. L’écran Paramètres avancés > Logs remonte les erreurs PHP de la boutique et classe ses entrées sur quatre niveaux de gravité, de l’information à l’erreur critique. Le journal d’erreurs du serveur, dans le panneau de l’hébergeur, complète la liste. Chaque ligne se rattache à un module, à un fichier du thème ou à une surcharge (du code tiers qui remplace une partie du cœur), et reçoit une décision écrite. Les tâches planifiées lancées en ligne de commande peuvent tourner sous une autre version de PHP que le site, selon le réglage du panneau de l’hébergeur : à confirmer avec lui.

Le retour arrière d’une montée de PHP se prépare avant la bascule

Dans la plage, revenir en arrière consiste à resélectionner l’ancienne version de PHP, si l’hébergeur la propose encore, avec une sauvegarde complète prise avant la bascule. L’éditeur a lui-même indiqué ce geste en septembre 2025 : sur une boutique PrestaShop 8 en PHP 8, installer le correctif 8.2.3 imposait de repasser en PHP 7.4 le temps de la mise à jour, ou d’utiliser l’archive locale.

Le prestataire livre un inventaire, une copie testée et une procédure de retour

Exigez par écrit quatre pièces : l’inventaire des modules avec leur statut, les erreurs relevées sur la copie et leur traitement, la date et l’heure de la bascule, la procédure de retour arrière. Après la bascule en production, le même scénario de test se rejoue. Faites écrire au devis que, si la boutique casse malgré tout, le prestataire qui a basculé restaure à sa charge. Aucun montant ne tient avant l’inventaire. Le prix dépend de deux familles de facteurs. Côté code : le nombre de modules non natifs, les surcharges, les modules sur mesure sans auteur joignable. Côté projet : l’écart entre version actuelle et version visée, une éventuelle montée de PrestaShop préalable, l’échéance fixée par l’hébergeur. Un serveur incapable de proposer la version visée pose une autre question, celle de l’hébergement de la boutique.

Décrire mon besoin →

Une montée de PHP sur PrestaShop échoue par l’attente, le masquage et le debug oublié

Attendre la date de l’hébergeur : la bascule peut alors se faire à son heure, sans copie ni retour arrière préparés. Masquer les avertissements au lieu de les traiter. Un code déprécié tourne encore, mais une version future de PHP peut le retirer, et l’erreur fatale surgirait à la bascule suivante. Laisser le mode debug actif en production. La documentation développeur indique qu’il produit une perte de performance significative, et il montre aux clients des messages techniques que les réglages par défaut leur cachent.

Reportez dans le message du formulaire de cette page la version complète de PrestaShop, la version de PHP actuelle, celle que l’hébergeur impose et sa date.

Sources consultées

• php.net, « Supported Versions », consulté le 14 octobre 2026.
• php.net, « Unsupported Branches », consulté le 14 octobre 2026.
• php.net, manuel de PHP, « Backward Incompatible Changes » (passage à PHP 8.0) et « Deprecated Features » (PHP 8.1 et 8.2), consulté le 14 octobre 2026.
• PrestaShop, documentation développeur, « System requirements », versions 1.7, 8 et 9, consulté le 14 octobre 2026.
• PrestaShop, « PrestaShop 9.2 is available », consulté le 14 octobre 2026.
• PrestaShop, « PrestaShop 8.2.3 is available », consulté le 14 octobre 2026.
• PrestaShop, documentation développeur, « Configuring PrestaShop » (version 9) et « Post-update checklist » (version 8), consulté le 14 octobre 2026.
• PrestaShop, documentation utilisateur (version 8), « Informations de configuration » et « Paramètres de log », consulté le 14 octobre 2026.
• PHPCompatibility, dépôt « PHPCompatibility » sur GitHub, consulté le 14 octobre 2026.

Foire aux questions

Où voir la version de PHP utilisée par la boutique ?

Dans le back-office, l’écran Paramètres avancés > Informations affiche la version de PHP du site, avec celles de PrestaShop et de MySQL. Le panneau de l’hébergeur peut indiquer une autre version pour la ligne de commande : comparez les deux avant de commander quoi que ce soit.

Faut-il viser la toute dernière version de PHP ?

Visez la plus récente de votre plage, sous réserve de l’essai sur copie, jamais au-delà. La documentation de PrestaShop recommande PHP 8.4 pour la 9.0 et PHP 8.5 pour la 9.1.

L’hébergeur peut-il changer la version de PHP sans prévenir ?

Cela dépend de ses conditions générales. Demandez-lui par écrit la date, la version imposée et s’il garde l’ancienne version sélectionnable pendant une période de transition. Sans cette période, la copie de test et l’inventaire des modules doivent être prêts avant la date annoncée.

Que faire d’un module sur mesure dont l’auteur a disparu ?

Son code reste sur votre serveur et se corrige comme n’importe quel code PHP, à condition d’en avoir les droits d’usage. Le prestataire chiffre deux options : corriger les fonctions supprimées ou dépréciées, ou remplacer le module par un équivalent maintenu, selon ce que le module fait d’unique pour votre boutique.