Agence PrestaShop à Villeurbanne : migrer quand vos modules ne suivent pas la nouvelle version

Votre module de paiement n’est pas prévu pour la nouvelle version ? Attendre ne règle rien. Migrer sans plan, c’est risquer une panne le jour des soldes.

Migrer quand vos modules ne suivent pas la nouvelle version : voici comment trancher, comme en atelier.

• Agence PrestaShop à Villeurbanne : migrer quand vos modules ne suivent plus
• Modules incompatibles : adapter, remplacer ou retirer
• Préproduction et sauvegardes limitent le risque de coupure
• Budget et délais : ce qui fait monter la facture
• Foire aux questions

Agence PrestaShop à Villeurbanne : migrer quand vos modules ne suivent plus

Une migration de PrestaShop 1.7 vers 8.1 prend en général 3 à 6 semaines. Ce qui fait traîner le chantier, ce sont les modules sur mesure, le thème et les connexions externes, bien plus que le transfert du catalogue.

À Villeurbanne, la proximité compte moins que la méthode. Une agence lyonnaise peut intervenir à distance si elle vous fournit un environnement de test, un plan de bascule écrit et un support après la mise en ligne. Plusieurs prestataires de la région annoncent des migrations depuis la 1.6 ou la 1.7 vers la 8.x. Vérifiez leurs références avant de signer.

Ne choisissez pas PrestaShop 9 parce qu’il est le plus récent. Si trois de vos modules commerciaux ne sont pas encore prévus pour cette version, visez la 8.1 ou la 8.2. Le risque baisse, et la refonte du thème peut attendre.

Un audit sérieux recense :

• la version actuelle de PrestaShop et la version de PHP
• la base de données et le thème
• chaque module
• les overrides (fichiers modifiés directement dans le cœur de PrestaShop)
• les connexions avec votre ERP, votre transporteur, votre outil d’emailing et votre solution de paiement

L’audit vérifie aussi les tâches planifiées (cron). Il regarde les flux de produits et les comptes administrateurs.

Comptez environ 300 € HT^* pour un audit technique simple.

Décrire mon besoin →

Modules incompatibles : adapter, remplacer ou retirer

Deux familles de modules demandent une attention immédiate :

• Les modules liés à la vente (paiement, transport, taxes, panier) : testez-les en premier.
• Les modules liés à l’exploitation (ERP, stock, facturation, export comptable) : une panne ne se voit pas tout de suite, mais elle coûte cher le mois suivant.

Pour chaque module, trois décisions sont possibles :

• Mise à jour éditeur : la solution la moins risquée, si une version compatible existe et est maintenue.
• Adaptation sur mesure : pertinente pour un module métier indispensable, à condition d’avoir accès au code et de pouvoir rejouer les tests.
• Remplacement ou retrait : préférable pour un module ancien qui double une fonction native ou qui apporte peu de valeur.

PrestaShop 9.1 installe Hummingbird comme thème par défaut sur les nouvelles installations. Il repose sur Bootstrap 5.3, supprime certains hooks (points d’accroche du code) et ne fonctionne pas comme le thème Classic.

Reprendre tel quel un thème 1.7 n’est donc pas une stratégie de migration, c’est souvent le poste qui dérape.

Testez chaque module seul, puis les combinaisons sensibles. Un module de paiement peut fonctionner isolément et échouer dès qu’un module de remise modifie le montant du panier.

Préproduction et sauvegardes limitent le risque de coupure

Sauvegardez d’abord les fichiers et la base de données.

Les fichiers contiennent code, modules, thème et images. La base contient produits, clients, commandes et réglages. Une sauvegarde incomplète vous empêche de revenir en arrière. C’est exactement le scénario à éviter un jour de soldes.

Créez ensuite une préproduction : une copie isolée sur un sous-domaine protégé. Elle doit utiliser une version de PHP proche de la production, une base distincte et des clés de paiement de test. Bloquez son indexation par Google, avec une authentification ou une règle adaptée.

Le cahier de recette doit couvrir au minimum :

• la création de compte, la connexion et la réinitialisation du mot de passe
• l’ajout au panier, les déclinaisons, les promotions et les frais de livraison
• un paiement accepté, un paiement refusé et une commande annulée

Exportez les anciennes URL : produits, catégories, pages CMS et fichiers importants. Associez chaque adresse à sa nouvelle version. Prévoyez une redirection 301 quand l’URL change. Gardez ces redirections au moins un an.

C’est la partie que l’on oublie le plus souvent. Elle coûte pourtant le plus cher en trafic perdu.

Après la mise en ligne, contrôlez :

• les codes HTTP
• les balises canoniques
• les règles noindex
• le fichier robots.txt
• le sitemap
• les liens internes

Le plan de retour arrière doit préciser qui décide de l’annulation, dans quel délai et avec quelle sauvegarde. Prévoyez une fenêtre de bascule de deux à quatre heures, hors pic commercial. Gelez les modifications pendant le transfert final. Surveillez les commandes, les paiements, les erreurs PHP et les stocks pendant 72 heures.

Décrire mon besoin →

Budget et délais : ce qui fait monter la facture

Les offres publiques de migration commencent autour de 1 200 € HT^* pour un périmètre très limité.

Pour une boutique PrestaShop 1.7 de taille moyenne (catalogue standard, peu de modules, pas de refonte graphique), prévoyez plutôt 3 000 à 8 000 € HT^*.

Ces montants couvrent en général le cadrage, la copie de test, le transfert des données, la configuration de la version cible, la recette et la mise en production. Ils excluent souvent la réécriture du thème, la création d’un module métier, la correction de données historiques et les licences éditeur. Demandez-le noir sur blanc dans le devis.

Un calendrier type pour une migration de taille moyenne :

• Semaine 1 : audit, inventaire, choix de la version cible, validation du devis
• Semaines 2 et 3 : installation, transfert des données, adaptation des modules, reprise du thème
• Semaine 4 : tests fonctionnels, SEO, paiements, flux, corrections
• Semaine 5 : recette finale, gel des données, bascule, contrôles
• Semaine 6 : support renforcé et corrections de lancement

Une boutique avec plusieurs modules sur mesure, un ERP et un thème ancien peut atteindre 8 à 12 semaines. C’est surtout vrai si les éditeurs répondent lentement. C’est aussi vrai si les tests révèlent des règles métier que personne n’avait documentées.

Un intégrateur devient utile dès que la boutique compte plus de 10 modules. Il l’est aussi pour un paiement personnalisé, un ERP, une activité B2B, une base de commandes importante ou un chiffre d’affaires très sensible à une coupure.

Une mise à jour mineure d’une boutique standard peut rester interne, avec sauvegarde vérifiée et préproduction. Pour une migration majeure, évitez la mise en production directe. Ce conseil vaut quelle que soit la compétence de l’équipe.

Pour une approche headless (une vitrine séparée du moteur e-commerce), ou des flux vers plusieurs marketplaces, documentez dès maintenant votre architecture d’échanges. Notez qui envoie quoi, à quelle fréquence et vers quel outil.

PrestaShop 9 propose une Admin API basée sur OAuth, API Platform et CQRS. Elle est bien plus propre que l’empilement de scripts historiques. C’est le bon moment pour poser ces bases, pas après la bascule.

Si vos modules ne suivent pas encore la nouvelle version, ne migrez pas avant d’avoir inventorié chacun d’eux et choisi pour lui une issue : mise à jour, adaptation ou retrait. Exigez de votre prestataire un devis détaillé, une préproduction et un plan de bascule écrit, puis planifiez la mise en ligne hors pic commercial.

Décrire mon besoin →

Foire aux questions

Pourquoi quitter PrestaShop cette année ?

Non, il n’y a pas d’obligation. Votre boutique peut rester en place tant que sa version, ses modules et son hébergement restent maintenables. La migration devient rationnelle quand PHP, le paiement, le thème ou plusieurs modules ne peuvent plus évoluer sans adaptation lourde.

Une migration vers PrestaShop 9 impose-t-elle Hummingbird ?

Non. Une boutique existante peut garder son thème actuel après une migration vers PrestaShop 9. Hummingbird est le thème par défaut des nouvelles installations PrestaShop 9.1, et si vous l’adoptez, il faut vérifier les hooks, les modules et les styles.

Peut-on garder un module sans support éditeur ?

Oui, mais seulement après une revue du code et une recette complète. Si le module touche au paiement, au panier, aux stocks ou aux commandes, mieux vaut une adaptation documentée ou un remplacement maintenable.

* 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.