Agence PrestaShop à Strasbourg : passer de PrestaShop 1.7 à la 9 sans perdre vos données

Un jour de soldes, une commande passée au mauvais moment peut disparaître. Passer de PrestaShop 1.7 à la 9 sans perdre vos données demande une méthode.

Voici comment conduire ce passage, avec les coûts et les pièges.

• Migrer PrestaShop 1.7 vers la 9 à Strasbourg sans perdre vos données
• Inventorier les données avant d’exporter évite les mauvaises surprises
• Les images et fichiers se transfèrent hors de la base
• Chaque module est suspect tant qu’il n’est pas testé
• Serveur et hébergement doivent suivre les exigences de PrestaShop 9
• Les URL et redirections protègent le référencement pendant la bascule
• Une agence strasbourgeoise doit prouver son expérience de migration
• La mise en production prévoit une sauvegarde et un retour arrière
• Foire aux questions

Migrer PrestaShop 1.7 vers la 9 à Strasbourg sans perdre vos données

Une migration de PrestaShop 1.7 vers PrestaShop 9 prend en général 3 à 6 semaines pour une boutique de 500 à 5 000 produits. Le délai varie surtout avec les modules sur mesure, le thème et les données propres à votre métier. Le reste suit une méthode connue.

À Strasbourg, ce passage ne se traite pas comme une simple mise à jour. PrestaShop 9 est une version majeure : Symfony 6.4, PHP 8.1 au minimum, une nouvelle administration. Il faut donc construire une boutique neuve, puis transférer des données contrôlées depuis l’ancienne.

Une migration majeure ne se joue pas comme une mise à jour

Le travail se fait en quatre temps :

1. installation d’une préproduction PrestaShop 9
2. extraction des données de production
3. adaptation des champs, identifiants et relations
4. import, tests, corrections, puis bascule

Sur un projet type de 1 200 produits, 8 modules marchands et un thème personnalisé, comptez souvent entre 7 000 et 14 000 € HT^*. Ce montant suppose une boutique mono-boutique, deux langues, moins de 100 000 commandes et un serveur déjà compatible PHP 8.4 ou 8.5.

L’Assistant de mise à jour ne couvre pas tous les cas

Pour un passage direct de 1.7 à 9, mieux vaut ne pas le retenir par défaut. La documentation officielle décrit surtout la migration manuelle vers PrestaShop 8 : extraction, transformation et chargement des données. Elle détaille les adaptations à faire sur les identifiants, les permissions, les images et les pièces jointes.

Réservez donc l’Assistant aux mises à jour maîtrisées, avec une sauvegarde testée et des modules déclarés compatibles. Pour une migration 1.7 vers 9, préférez une nouvelle installation et un transfert contrôlé. C’est vrai surtout au-delà de 1 000 produits ou de 5 modules spécifiques.

Décrire mon besoin →

Inventorier les données avant d’exporter évite les mauvaises surprises

Avant tout export, comptez les produits, déclinaisons, catégories, clients, adresses, commandes, paniers, stocks, règles de prix et langues. Ce chiffre sert de contrôle. Si 1 248 produits partent, 1 248 doivent arriver, avec les mêmes références et les mêmes déclinaisons.

Séparer les données commerciales des réglages techniques

Distinguez ce qui doit être transféré de ce qui doit être recréé. Produits, catégories, clients, adresses, marques, fournisseurs, commandes et stocks relèvent du métier. Les permissions employés, la configuration générale, les langues, les devises et les contrôleurs du back-office demandent un traitement à part.

Le périmètre apparaît dans le devis, ligne par ligne :

• Produits : nom, référence, prix, TVA, descriptions, catégories, déclinaisons, caractéristiques et état de publication.
• Stocks : quantités, déclinaisons, entrepôts éventuels et règles de disponibilité.

L’export depuis le back-office est pratique. Il ne restitue pourtant que les colonnes affichées. Une information stockée ailleurs dans la base peut donc manquer. L’extraction SQL donne plus de contrôle, à condition de lire les tables et leurs relations avant d’importer quoi que ce soit.

Pour une boutique en français, allemand et anglais, répétez les exports par langue. PrestaShop précise que l’export reprend la langue active du compte employé. Un seul fichier français ne suffit donc pas à reconstruire les textes allemands et anglais.

Les identifiants décident de la suite de l’import

Comparez la structure de la base source et celle de la base cible. Ce contrôle fait apparaître les nouvelles colonnes, les champs déplacés, les index uniques et les changements de type.

Les identifiants demandent une décision nette. Si vous conservez les identifiants produits, les liens avec les images et les déclinaisons restent simples. Si PrestaShop 9 en génère de nouveaux, dressez une table de correspondance entre l’ancien et le nouveau numéro de chaque élément.

Les doublons reviennent souvent sur les références produits, les adresses e-mail, les noms de catégories et les combinaisons. Traquez-les avant l’import, puis vérifiez les clés uniques après coup.

Une règle d’unicité ajoutée dans la cible peut bloquer une table entière. Il suffit que deux lignes portent la même combinaison de valeurs.

L’ordre d’import suit les dépendances :

1. langues, devises et boutiques
2. catégories, marques et fournisseurs
3. produits et déclinaisons
4. caractéristiques, attributs et stocks
5. clients et adresses
6. commandes, paniers et relations annexes

Les comptes employés ne se copient pas tels quels. Le système de permissions a été remanié avec Symfony. Il faut donc recréer comptes et profils dans PrestaShop 9, puis faire valider les droits par le responsable de la boutique.

Décrire mon besoin →

Les images et fichiers se transfèrent hors de la base

Une base complète ne suffit pas. Vos images, pièces jointes, fichiers téléversés, thème et modules sont sur le serveur. Leurs liens avec les produits, eux, sont dans la base. Il faut donc transférer les deux.

Si les identifiants changent, il faut mettre à jour les références dans les tables d’images avant l’import. Sinon, vos photos ne s’affichent pas.

Les miniatures se régénèrent après le transfert. L’image originale peut donc être là, alors que les formats de la fiche produit, du panier ou des listes de catégories manquent encore. Vérifiez-le.

Contrôlez ensuite 20 à 50 fiches réparties dans plusieurs catégories, sur ordinateur et sur mobile :

• Image principale
• Déclinaisons
• Zooms
• Images secondaires
• Pièces jointes et fichiers clients

Chaque module est suspect tant qu’il n’est pas testé

Considérez chaque module comme incompatible jusqu’à preuve du contraire. Une compatibilité annoncée avec PrestaShop 8 ne garantit rien pour PrestaShop 9. Cette version modifie le socle technique, la version de PHP prise en charge et certaines interfaces.

Les modules sur mesure font varier le devis

Pour chaque module, vérifiez :

• sa version compatible avec PrestaShop 9
• la version de PHP prise en charge
• sa compatibilité avec le thème retenu
• ses appels externes vers ERP, CRM, transporteurs ou marketplaces
• son comportement en multiboutique et en multilingue

Pour un module acheté, demandez la version PrestaShop 9 ou une confirmation écrite de l’éditeur. Pour un module développé en interne, prévoyez une revue de code et des tests sous PHP 8.4 ou 8.5.

Ne reconduisez jamais un override ancien sans l’avoir identifié et justifié.

Le thème se valide comme une application

Le thème concentre les risques visibles. Ce sont le panier, le menu, la recherche, les fiches produits, le compte client, le tunnel de commande et l’affichage mobile. PrestaShop 9 introduit aussi le thème Hummingbird. Un thème 1.7 ne passe pas pour autant sans adaptation.

Comptez généralement 3 000 à 8 000 € HT^* pour adapter un thème simple, et 8 000 à 20 000 € HT^* pour une refonte avec maquettes, composants spécifiques et plusieurs parcours B2B. Ces prix supposent des contenus et des règles métier stables.

La préproduction reçoit des comptes de test, des produits représentatifs et les mêmes moyens de paiement qu’en production. Testez :

• la création de compte et la connexion
• l’adresse, le panier et les déclinaisons
• les codes promo et la commande
• le paiement et le transport
• la facture et les e-mails

Décrire mon besoin →

Serveur et hébergement doivent suivre les exigences de PrestaShop 9

PrestaShop 9 exige PHP 8.1 au minimum. PrestaShop 9.0 accepte PHP 8.1 à 8.4, et la documentation recommande PHP 8.4 pour la 9.0 et PHP 8.5 pour la 9.1. La version cible se fixe après contrôle des modules, pas seulement en prenant la plus récente.

Demandez à l’hébergeur une confirmation écrite :

• version PHP disponible
• mémoire par processus
• extensions activées
• accès SSH
• tâches planifiées
• taille maximale des imports

Un hébergement mutualisé peut suffire pour 200 produits et 20 000 visites par mois. Mieux vaut l’éviter pour une boutique B2B avec imports quotidiens et trafic irrégulier.

Prévoyez 150 à 500 € HT^* pour un audit serveur simple. Pour une préparation complète, comptez 800 à 2 500 € HT^* : préproduction, réglages PHP, accès SSH, sauvegardes et procédure de restauration. Ces montants supposent un hébergement déjà choisi, sans changement de fournisseur.

Les URL et redirections protègent le référencement pendant la bascule

Commencez par exporter les URL qui reçoivent du trafic. Notez leurs titres, descriptions, balises canoniques, codes HTTP et liens internes. Une migration SEO se prépare avant l’import des produits, pas après l’ouverture de la boutique.

PrestaShop permet de définir les URL simplifiées des produits, catégories et pages CMS. Elles peuvent rester identiques. Pourtant, un changement de thème, de route ou de structure de catégories peut modifier les adresses existantes.

Deux options se présentent :

• conserver le schéma actuel, ce qui réduit le nombre de redirections
• changer les URL pour corriger une structure trop longue ou incohérente

Vérifiez aussi la balise canonique et la présence éventuelle d’un noindex. Contrôlez le fichier robots.txt, le sitemap et les liens internes. Sitemap et consignes d’exploration doivent correspondre au domaine, au protocole HTTPS et au chemin réel de la boutique.

Après la bascule, surveillez les erreurs 404 dans Google Search Console pendant quatre semaines au minimum. Corrigez en priorité les pages qui recevaient des visites, des liens externes ou des commandes.

Décrire mon besoin →

Une agence strasbourgeoise doit prouver son expérience de migration

Un prestataire local peut piloter le projet depuis Strasbourg. La proximité ne prouve pas la compétence. Demandez des références vérifiables : boutiques passées de PrestaShop 1.7 à 8 ou 9, avec un volume de produits, de commandes et de modules proche du vôtre.

Le prestataire doit savoir traiter les données, le référencement et l’infrastructure. Une équipe spécialisée dans le seul thème peut livrer une belle préproduction et oublier les commandes historiques, les règles de prix ou les redirections.

Vérifiez ces points avant de confier votre migration PrestaShop 1.7 vers la 9

Cochez ce qui est déjà clair pour votre boutique, et repérez ce qui reste à demander à votre prestataire.

• Savez-vous combien de produits, déclinaisons, clients et commandes votre boutique compte aujourd’hui ?

  Ce chiffre sert de contrôle : chaque volume exporté doit retrouver le même nombre après l’import.

• Connaissez-vous la liste de vos modules et leur compatibilité avec PrestaShop 9 ?

  Une compatibilité annoncée avec PrestaShop 8 ne garantit rien pour la 9. Demandez une confirmation écrite de l’éditeur.

• Votre boutique est-elle en français seul, ou aussi en allemand ou en anglais ?

  Chaque langue doit être exportée séparément, sinon les textes traduits se perdent.

• Votre hébergeur peut-il confirmer par écrit la version de PHP, la mémoire et l’accès SSH disponibles ?

  PrestaShop 9 exige PHP 8.1 au minimum. Un hébergement mutualisé est souvent insuffisant pour une boutique B2B.

• Avez-vous exporté la liste de vos URL qui reçoivent du trafic, avec leurs redirections prévues ?

  Une migration sans redirections 301 peut faire chuter votre référencement dès l’ouverture.

• Votre prestataire peut-il citer des boutiques passées de PrestaShop 1.7 à 8 ou 9, d’un volume proche du vôtre ?

  La proximité géographique ne prouve pas la compétence technique sur les données et les redirections.

• Avez-vous défini par écrit vos critères de retour arrière avant la mise en production ?

  Il est trop tard pour les écrire le jour du lancement, quand une commande est déjà bloquée.

• Savez-vous comment les commandes passées pendant la bascule seront reprises sans être perdues ?

  Une fenêtre de gel ou une procédure de reprise doit être prévue, sinon une commande peut disparaître.

Points cochés : sur 8. Rien n'est envoyé ni enregistré : la liste reste dans votre navigateur.

Demandez notamment :

• un exemple avec plusieurs langues
• un livrable de rapprochement des volumes
• un rapport de tests avant mise en production

Un devis sérieux détaille, dans cet ordre :

1. le cadrage
2. l’inventaire
3. la préproduction
4. l’extraction
5. l’adaptation
6. l’import
7. le thème
8. les modules
9. le SEO
10. les tests
11. la bascule
12. le suivi après lancement

Pour une boutique de 500 produits, comptez souvent 4 000 à 8 000 € HT^*. Pour 5 000 produits, 15 modules et deux flux externes, 12 000 à 25 000 € HT^* est plus réaliste.

Le devis précise aussi ce qui reste à votre charge : licences de modules, abonnement serveur, rédaction, traduction, validation juridique des e-mails, recette métier. Vos équipes doivent aussi être disponibles. Les modules sur mesure et les connecteurs tiers se chiffrent séparément.

Une promesse de « migration sans interruption » mérite une précision. La boutique peut rester accessible pendant la préparation. La synchronisation finale des commandes, clients et stocks exige une fenêtre de gel ou un mécanisme de reprise. Sans cela, une commande passée entre l’extraction et la bascule peut disparaître.

La mise en production prévoit une sauvegarde et un retour arrière

Copiez la sauvegarde complète hors du serveur public. Un fichier laissé dans un dossier accessible au navigateur peut exposer des données clients, des commandes ou des identifiants techniques.

Une sauvegarde ne protège rien tant que vous n’avez pas testé sa restauration. Restaurez la base et les fichiers sur un environnement séparé. Puis vérifiez la connexion, les images, le back-office, le panier et une commande de test.

Pour une boutique active, prévoyez une extraction initiale, une période de tests, puis une extraction finale. Pendant cette dernière synchronisation, la boutique passe en maintenance. Sinon, les commandes récentes sont reprises selon une procédure écrite.

Le jour de la bascule, l’ordre est en général le suivant :

1. sauvegarde complète de la boutique 1.7
2. export des commandes et modifications récentes
3. mise en maintenance
4. import final dans PrestaShop 9
5. contrôle des volumes et des montants
6. changement de domaine ou de configuration serveur
7. ouverture progressive
8. contrôle des commandes, paiements et e-mails

Pour une boutique de moins de 2 000 produits sur un serveur bien préparé, comptez 30 à 90 minutes d’indisponibilité. Une multiboutique, un export lourd ou un stock connecté en temps réel peut demander deux à quatre heures.

Les critères de retour arrière s’écrivent avant le lancement :

• paiement refusé sur plusieurs moyens
• commandes impossibles
• écarts de stock
• erreurs 500
• images absentes en masse
• redirections critiques cassées
• perte de données

Une simple baisse de trafic le premier jour ne justifie pas une restauration.

La responsabilité se partage. L’agence prépare la procédure et réalise les opérations techniques. L’hébergeur garantit l’accès serveur. Le commerçant valide les données métier et décide du retour arrière dans un délai convenu.

Avant de signer un devis, demandez par écrit la compatibilité PrestaShop 9 de chaque module, la procédure de restauration testée et la fenêtre de gel des commandes pendant la bascule. Fixez dès maintenant vos critères de retour arrière, car le jour du lancement, il est déjà trop tard pour les écrire.

Décrire mon besoin →

Foire aux questions

Comment réparer PrestaShop après une erreur ?

Commencez par repérer la dernière modification faite avant le problème, puis lisez les journaux d’erreurs. Testez la correction sur une copie de test de votre boutique, en activant temporairement le mode débogage ; PrestaShop propose des commandes en ligne de commande pour vider le cache, gérer les modules, reconstruire l’index et afficher la configuration. Désactivez le mode débogage en production dès que la réparation est terminée.

Quels sont les meilleurs modules PrestaShop ?

Il n’existe pas de meilleur module dans l’absolu : le bon choix dépend de votre boutique. Retenez un module compatible avec votre version exacte de PrestaShop et de PHP, maintenu par son éditeur, documenté et testable sur une copie de test. Pour le paiement, la livraison ou la comptabilité, prévoyez aussi une solution de remplacement.

Pourquoi PrestaShop a-t-il été piraté ?

Une boutique peut être piratée à cause d’une faille du cœur de PrestaShop, d’un module non mis à jour, d’un mot de passe compromis, d’un serveur mal configuré ou d’un fichier sensible laissé accessible en ligne. En cas d’intrusion, isolez la boutique, gardez les journaux, changez tous les accès et vérifiez les fichiers. Ne remettez le site en ligne qu’après l’avoir restauré à partir d’une sauvegarde saine.

* Tarifs et prix moyens constatés en décembre 2025, sur des retours d'appels d'offres provenant de freelances et d'agences. Ces chiffres ne sauraient être une référence de négociation, car les sources varient selon la taille du site et la séniorité du prestataire.