Mise à jour de PrestaShop : que vérifier avant le devis ?

Pour établir un devis fiable de mise à jour PrestaShop, il faut la version complète de la boutique, l’environnement serveur, le thème, les modules clés et la description des modifications personnalisées. Le simple numéro de version ne détermine pas l’ampleur du travail. Deux boutiques sur la même version peuvent nécessiter une préparation totalement différente si l’une utilise les fonctions standard, tandis que l’autre dispose d’un checkout modifié, d’une intégration d’entrepôt et de règles tarifaires personnalisées.

Ce guide aide à préparer une demande de mise à jour et à convenir des critères de réception. Ce n’est pas une instruction pour lancer l’outil de mise à jour sans sauvegarde préalable ni vérification des dépendances.

La version de PrestaShop et celle de PHP doivent former un ensemble pris en charge

Notez la désignation complète de la version actuelle et de la version cible de la boutique. Vérifiez la version de PHP qui prend en charge le site ainsi que celle utilisée par CRON et les commandes console. L’hébergement peut proposer des versions différentes selon ces modes d’exécution. Modifier le paramètre dans le panneau du domaine ne change pas forcément l’interpréteur utilisé par les tâches planifiées.

D’après la documentation vérifiée le 13 septembre 2026, PrestaShop 9.0 prend en charge PHP 8.1–8.4, et PrestaShop 9.1 — PHP 8.1–8.5. Les versions recommandées de PHP diffèrent également entre ces branches. C’est un exemple qui montre pourquoi l’information « prend en charge PrestaShop 9 » est insuffisante pour choisir l’environnement. Source : exigences officielles de PrestaShop 9.

Le fait que l’environnement soit pris en charge par le moteur de la boutique ne confirme pas encore la compatibilité du thème ni des modules. Avant de passer à une version supérieure de PHP, vérifiez aussi leurs exigences, les extensions serveur, les limites de mémoire et le mode d’exécution des intégrations. Ne commencez pas par changer PHP en production uniquement parce qu’un numéro plus récent semble plus avantageux.

Inventaire : commencez par les fonctions critiques

La liste de tous les modules est utile, mais le prestataire doit avant tout savoir quelles fonctions assurent les ventes quotidiennes. Indiquez les paiements, les livraisons, les points de retrait, la facturation, l’entrepôt, les imports de prix et de stocks, les réservations ainsi que les règles B2B spécifiques. Ajoutez l’information sur la personne ou l’équipe qui maintient chaque intégration.

Au stade du premier contact, les informations techniques et la description du processus suffisent. N’inscrivez pas de mots de passe, de clés API ni de données clients dans un document accessible au public. Si un accès à une copie est nécessaire, convenez du mode de transmission et du niveau d’autorisations.

Qu’est-ce qui reste, qu’est-ce que nous mettons à jour, et qu’est-ce que nous remplaçons ?

Chaque élément important doit faire l’objet d’une décision et de sa justification. « Reste en place » signifie une utilité confirmée dans la configuration prévue. « À vérifier » est un statut correct avant l’analyse ; une certitude feinte complique le devis et la réception ultérieure.

N’évaluez pas un module uniquement selon le fait qu’il peut être installé. L’installation ne confirme ni le calcul de la remise, ni l’enregistrement du point de retrait, ni la fin de la communication avec l’entrepôt. De même, une page d’accueil correcte ne constitue pas une preuve de mise à jour correcte de la boutique.

Modifications personnalisées : le plus grand risque est parfois invisible dans le panneau

Interrogez les personnes qui maintiennent la boutique sur les modifications créées au fil des années : champs supplémentaires, statuts de commande atypiques, changements de prix, désactivation de transporteurs ou exports spécifiques. Une partie d’entre elles peut exister en dehors des modules visibles dans le panneau.

Une brève description du comportement est utile : « pour ce groupe de clients, le prix est calculé ainsi », « ces produits excluent ce transporteur », « après ce statut, nous envoyons le document au système ». À partir d’une telle description, il est possible de préparer un test de réception. Le simple nom du fichier override n’explique pas sa signification métier.

La recréation d’une fonction manquante peut nécessiter un travail distinct. Cela doit être identifié dans le périmètre ou explicitement indiqué comme dépendance à clarifier, au lieu d’apparaître seulement après la bascule de la boutique.

Copie de test et critères de réception

La mise à jour est d’abord réalisée sur une copie avec des intégrations contrôlées. La préparation de la copie comprend aussi la protection de l’accès, l’arrêt des envois de production et la séparation de la configuration des services externes. La copie doit permettre de tester le processus, et non de reproduire inconsciemment le fonctionnement de la boutique de production.

Le guide officiel de mise à jour depuis le panneau décrit l’utilisation de l’outil de mise à jour. Le périmètre de réception doit en outre refléter les fonctions de la boutique ; le point de référence est la liste de contrôle après mise à jour.

• Comparez des produits sélectionnés, les déclinaisons, les prix et les stocks.
• Vérifiez le compte client, le panier, les adresses ainsi que les méthodes importantes de livraison et de paiement.
• Contrôlez le résultat de la commande dans le panneau et dans les systèmes où elle doit parvenir.
• Lancez des tests contrôlés d’imports, d’exports et de tâches CRON.
• Comparez les URL importantes, les balises canoniques, les redirections, les versions linguistiques et les plans de site.
• Consignez les erreurs, les décisions et les conditions d’acceptation, et pas seulement un vague « tests terminés ».

Vous trouverez une fiche de contrôle plus détaillée du processus d’achat dans le guide sur le changement de checkout. Pour les travaux sur les adresses, utilisez également le texte existant sur la conservation des anciens liens et les redirections.

Le plan de bascule et de retour doit tenir compte des nouvelles commandes

Avant les travaux, définissez le moment de la création de la copie finale des fichiers et de la base, la manière de limiter les modifications de données ainsi que l’ordre d’arrêt et de reprise des intégrations. Désignez la personne qui prendra la décision de remettre la boutique en ligne et les conditions dans lesquelles vous reviendrez à la version précédente.

Le retour à une sauvegarde antérieure à la mise à jour peut supprimer de la base actuelle des commandes ou des modifications enregistrées plus tard. C’est pourquoi une sauvegarde sans point de restauration défini ne constitue pas un plan d’urgence complet. Il faut aussi tenir compte des paiements qui peuvent être confirmés avec retard, ainsi que des données envoyées aux systèmes externes.

Les principes de préparation d’une copie sont présentés dans la documentation de sauvegarde PrestaShop. Pour une boutique donnée, précisez en plus qui a vérifié la possibilité de restauration et comment seront conciliées les modifications apparues pendant les travaux. Ne supposez pas d’emblée une mise à jour sans interruption.

De quoi se compose le devis ?

Le devis peut inclure l’analyse et l’inventaire, la préparation de la copie, la mise à jour proprement dite, l’adaptation du code et du thème, les tests, la bascule ainsi que le support après mise en ligne. Il faut indiquer séparément les licences, les mises à jour payantes des modules externes et les fonctions à recréer.

Demandez un périmètre clair, les dépendances et les critères de fin. Un prix fixe a du sens pour un travail identifié ; en présence de modifications inconnues, une phase d’analyse préalable peut être utile. Il n’existe pas de montant unique et honnête pour chaque boutique marquée « PrestaShop 1.7 » ou « PrestaShop 8 ».

Préparez la version de la boutique, le nom du thème et la liste des intégrations clés. Sur cette base, il est possible de commencer à planifier la mise à jour de la boutique PrestaShop, de définir les vérifications nécessaires et de préparer un périmètre qui pourra être facturé.

Vérification de fond : 13 septembre 2026. Les exigences de version ont été vérifiées dans la documentation PrestaShop. La matrice de décision est donnée à titre d’exemple ; le chemin cible et la compatibilité des intégrations sont définis pour chaque boutique concrète.