Si votre boutique tourne encore sous PrestaShop 1.5, vous avez probablement déjà entendu les deux discours : « surtout n’y touchez pas, ça marche » et « il faut tout refaire ». Les deux sont à moitié vrais, et c’est précisément ce qui rend la décision difficile.
Voici ce que je constate sur le terrain : une 1.5 fonctionne encore, parfois très bien, jusqu’au jour où un élément extérieur bouge — l’hébergeur retire une version de PHP, un prestataire de paiement change son API, un robot trouve une faille connue. Ce jour-là, la migration n’est plus un projet : c’est une urgence.
Cet article explique pourquoi la mise à jour n’existe pas vraiment pour la 1.5, ce qu’il faut faire à la place, et comment préparer la sortie sans perdre vos données ni votre référencement.
Réponse rapide
Il n’existe pas de chemin de mise à jour fiable entre PrestaShop 1.5 et les versions actuelles (8 et 9). La 1.5 date de 2012, elle repose sur des versions de PHP abandonnées, et son thème comme ses modules sont incompatibles avec l’architecture Symfony introduite en 1.7. La seule méthode qui tienne est une installation neuve de PrestaShop 9, vers laquelle on migre les données (produits, déclinaisons, clients, commandes, contenus), avec un thème reconstruit, des modules remplacés et un plan de redirections pour conserver le référencement. L’ancienne boutique reste en ligne jusqu’à la bascule. Comptez plusieurs semaines, pas un week-end.
Pourquoi le bouton « mise à jour » ne vous sauvera pas
PrestaShop a connu une rupture d’architecture majeure entre la 1.6 et la 1.7 : le passage à Symfony, la refonte du système de thèmes, la réécriture du back-office. Les modules écrits pour la 1.5 ou la 1.6 ne s’exécutent pas sur les versions modernes, et le thème encore moins.
Entre une 1.5 et une 9, les sauts à franchir sont donc multiples : 1.5 → 1.6, puis 1.6 → 1.7, puis 1.7 → 8, puis 8 → 9. Chacun de ces sauts a ses propres incompatibilités, et l’outil de migration officiel n’a jamais été conçu pour enchaîner une telle série sur une boutique réelle, chargée de modules et de surcharges accumulés depuis dix ans.
J’ai vu des boutiques essayer. Le résultat est toujours le même : une base de données à moitié convertie, des prix ou des déclinaisons corrompus, un back-office inaccessible, et une sauvegarde à restaurer en catastrophe. Le temps perdu dépasse largement celui d’une migration propre.
La bonne nouvelle, c’est que la partie qui compte vraiment — vos données — se migre très bien. Ce sont le thème et les modules qui ne se transportent pas, et ceux-là ont de toute façon dix ans.
Ce que vous risquez concrètement en restant
La sécurité
La branche 1.5 n’est plus maintenue depuis longtemps : aucun correctif officiel n’est publié, et les failles connues sont documentées publiquement. Les robots qui balaient le web ne cherchent pas votre boutique en particulier — ils cherchent une signature de version. Les conséquences classiques : injection de code dans les fichiers, page de paiement détournée pour capter les numéros de carte, serveur transformé en relais de spam.
L’hébergement
Une 1.5 demande du PHP 5. Les hébergeurs ont retiré ces versions de leur parc, ou les facturent en option de support étendu. Le jour où la vôtre disparaît, la boutique s’arrête net — et vous migrez dans l’urgence.
Les paiements et les transporteurs
Les prestataires font évoluer leurs API et abandonnent leurs vieux modules. Un module de paiement qui cesse de fonctionner, ce n’est pas un désagrément : c’est un tunnel de commande cassé, donc zéro chiffre d’affaires jusqu’à la correction.
La conformité
Entre les obligations de protection des données, les exigences d’authentification forte sur les paiements et les règles d’information du consommateur, une boutique de 2012 n’a pas été conçue pour le cadre actuel.
Le référencement et le mobile
Un thème 1.5 date d’avant la généralisation du mobile et avant que la vitesse de chargement ne pèse sur le classement. Vous perdez des positions sans le voir, parce que la concurrence, elle, a changé de décennie.
Les trois chemins possibles, et comment choisir
1. Migrer vers PrestaShop 9
Le chemin naturel si votre activité repose sur des spécificités PrestaShop : multiboutique, gestion fine des déclinaisons, tarifs par groupe de clients, transporteurs particuliers, liaison avec un ERP. Vous retrouvez vos habitudes de back-office, vos données, votre logique métier — sur un socle moderne (Symfony 6.4, PHP 8.1 minimum).
2. Migrer vers WooCommerce
Pertinent si votre boutique est de taille modeste, que le contenu éditorial compte autant que le catalogue, et que vous voulez un écosystème plus large et moins coûteux en développement spécifique. C’est le chemin que décrit la page PrestaShop vers WooCommerce.
3. Migrer vers Shopify
Pertinent si vous ne voulez plus entendre parler de serveur, de mise à jour ni de sauvegarde, et que votre catalogue entre dans le modèle de Shopify. Vous échangez de la liberté technique contre de la tranquillité, et un abonnement contre des frais d’hébergement et de maintenance. Voir PrestaShop vers Shopify.
Il n’y a pas de bonne réponse universelle. Ce qui tranche, dans l’ordre : la complexité de votre catalogue, vos intégrations existantes, votre capacité à payer du développement spécifique, et ce que vous voulez gérer vous-même. Si vous hésitez, le diagnostic e-commerce est fait exactement pour ça — et il coûte toujours moins cher qu’un mauvais choix de plateforme.
La méthode, étape par étape
- Inventaire. Version exacte, liste des modules avec leur rôle réel, surcharges présentes dans
override/, modifications de thème, intégrations externes, volume du catalogue et des commandes. C’est ce document qui détermine le budget, pas la taille apparente du site. - Inventaire des URLs. Export complet des adresses indexées, avec leur trafic. Cette liste est la matière première du plan de redirections — et la raison pour laquelle on ne la fait jamais après la bascule.
- Installation neuve de la version cible, sur un domaine ou un sous-domaine de travail, pendant que la 1.5 continue de vendre.
- Migration des données : produits, déclinaisons, images, catégories, clients, commandes, pages de contenu. Puis contrôle par échantillons — on ne « croit » pas une migration, on la vérifie fiche par fiche sur un panel représentatif.
- Thème reconstruit sur un thème moderne, en reprenant votre identité visuelle. C’est l’occasion de corriger ce qui freinait les ventes sur mobile.
- Modules : chaque fonction est reprise par un module maintenu, un développement spécifique, ou abandonnée si elle ne sert plus. Vous seriez surpris du nombre de modules installés « au cas où » depuis dix ans.
- Plan de redirections 301, de chaque ancienne URL vers sa nouvelle. Produits, catégories, pages, et même les anciennes URL de recherche si elles reçoivent du trafic.
- Recette complète : parcours d’achat de bout en bout, paiement en conditions réelles, emails transactionnels, exports comptables, mobile et ordinateur.
- Bascule à un moment creux, avec un gel des modifications côté ancienne boutique pour ne perdre aucune commande.
- Surveillance les semaines suivantes : erreurs 404, courbe d’indexation, taux de conversion, journaux de paiement.
Combien de temps, combien ça coûte
Je ne peux pas donner un prix sans avoir regardé la boutique, et personne ne le peut honnêtement. Ce que je peux donner, ce sont les facteurs qui pèsent, par ordre d’importance :
- Les modules et surcharges spécifiques. C’est le premier poste, loin devant le nombre de produits. Une boutique avec quinze modules maison coûte plus cher à migrer qu’un catalogue de dix mille références standard.
- La propreté des données. Déclinaisons incohérentes, doublons, champs détournés de leur usage : tout cela se nettoie, mais cela se paie.
- Les intégrations. ERP, logiciel de caisse, marketplace, transporteur : chaque liaison est un chantier en soi.
- Le niveau de design attendu : thème professionnel adapté à vos couleurs, ou maquette entièrement dédiée.
Les points de départ sont publiés sur la page tarifs, et l’estimateur donne un ordre de grandeur en une minute. Pour une 1.5, comptez un projet de plusieurs semaines : l’essentiel du temps passe dans la reprise des données et la recette, pas dans l’installation.
Si vous ne pouvez pas migrer tout de suite
Parfois le budget n’est pas là, ou la saison interdit de toucher à quoi que ce soit. Dans ce cas, réduisez la surface d’exposition sans attendre :
- Sauvegardes automatiques, fichiers et base, stockées ailleurs que sur le serveur de la boutique — et dont vous avez testé la restauration au moins une fois.
- Back-office protégé : dossier d’administration renommé, mots de passe renouvelés, comptes inutilisés supprimés, et si possible restriction d’accès par adresse IP.
- Modules inutiles désactivés puis supprimés. Chaque module ancien est une porte d’entrée supplémentaire.
- Pare-feu applicatif devant la boutique : il ne corrige pas les failles, mais il bloque une partie des attaques automatisées.
- Surveillance des fichiers modifiés et des erreurs du serveur : une intrusion se repère souvent à un fichier apparu la nuit.
Ce sont des mesures d’attente, pas une solution. Elles vous donnent quelques mois pour organiser la sortie dans de bonnes conditions — ce qui est exactement le but.
Checklist
- Relever la version exacte et la version de PHP du serveur
- Lister les modules, leur rôle réel et ceux qui ne servent plus
- Lister les surcharges présentes dans
override/et les modifications de thème - Exporter la liste complète des URLs indexées, avec leur trafic
- Vérifier que la sauvegarde existe et se restaure
- Choisir la plateforme cible avant de chiffrer quoi que ce soit
- Préparer le plan de redirections 301 avant la bascule, jamais après
- Garder l’ancienne boutique en ligne jusqu’à la recette complète
- Surveiller 404, indexation et paiements pendant les semaines suivantes
Questions fréquentes
Puis-je passer de 1.5 à 1.6 d’abord, pour gagner du temps ?
Cela ne vous avance pas : la 1.6 n’est pas maintenue non plus, et vous devrez refaire une migration complète ensuite. Autant viser directement une version actuelle, avec un seul chantier de reprise de données et une seule recette.
Vais-je perdre mon référencement ?
Pas si le plan de redirections est préparé avant la bascule. Une migration bien menée se traduit par une fluctuation de quelques semaines, puis un retour au niveau antérieur — souvent au-dessus, parce qu’un site moderne est plus rapide et mieux structuré. Ce qui détruit un référencement, c’est une bascule sans inventaire d’URLs.
Et mes clients, leurs comptes et leur historique ?
Comptes, adresses, historique de commandes et avoirs se migrent. Les mots de passe, eux, sont stockés sous forme chiffrée avec un algorithme ancien : selon les cas, ils sont repris tels quels ou vos clients doivent en définir un nouveau à leur première connexion. Cela s’annonce par un email, et cela se prépare.
Ma boutique a été piratée. Puis-je migrer la base telle quelle ?
Non, pas sans nettoyage. Une base issue d’une boutique compromise peut contenir des scripts injectés dans des descriptions produit ou des pages de contenu. On nettoie avant d’importer, sinon la nouvelle boutique naît infectée.
Combien de temps la boutique sera-t-elle inaccessible ?
Quelques minutes à une heure, le temps de la bascule technique, pas plus. Tout le travail se fait en parallèle sur une installation séparée : l’ancienne boutique continue de vendre jusqu’au dernier moment.