Créer ou reprendre

Parce qu'il arrive avec quarante fonctions dont vous en utiliserez trois, et que chacune charge son CSS et son JavaScript partout. Et parce qu'on finit toujours par le modifier : s'il n'est pas monté en thème enfant, ces modifications disparaissent à la première mise à jour. Un thème acheté n'est pas exclu, mais il se monte proprement.

La 8 pour la grande majorité des projets : son écosystème de modules est mûr et stable. La 9 se défend en création, où l'on part sans dette technique — à condition de vérifier d'abord que les modules dont vous dépendez y sont disponibles.

PrestaShop tient des catalogues de plusieurs dizaines de milliers de références, à condition que la structure et les index suivent. Ce n'est pas le nombre de produits qui pose problème mais la façon dont ils sont rangés — d'où le temps passé au cadrage.

C'est le but. La formation se fait sur vos propres produits et vos propres commandes, et le code est documenté pour qu'un autre développeur PrestaShop puisse le reprendre. Une boutique qu'on n'ose pas modifier n'est pas livrée.

Non, et c'est même l'erreur la plus coûteuse. PrestaShop traite nativement la TVA par pays, les grilles de port, les états de commande, les groupes de clients et les promotions. Chaque module ajouté est du code non maîtrisé qui s'exécute sur chaque page et qu'il faudra maintenir.

Six à huit semaines pour un catalogue structuré et un thème enfant soigné, davantage si le catalogue est complexe ou s'il faut développer des modules spécifiques. Le cadrage donne une date, et c'est elle qui figure au contrat.

Pas si le plan de redirection est fait avant la migration et non après. Shopify impose ses préfixes /products/ et /collections/ que PrestaShop ne reprend pas : sans correspondance 301, chaque page référencée tombe en 404. Avec la table complète posée le jour de la bascule, les positions se transfèrent, avec une fluctuation de deux à trois semaines le temps que Google recrawle.

Aucune. La boutique PrestaShop est montée en parallèle sur un autre domaine, testée, puis remplie une dernière fois avec les commandes et les clients de la veille. Seule la bascule DNS est instantanée, et Shopify reste en ligne pendant sa propagation.

Non, les comptes, adresses et historiques sont repris. En revanche Shopify ne restitue pas les mots de passe — personne ne peut les exporter, ils sont hachés. Les clients reçoivent donc un email les invitant à en choisir un nouveau à leur première connexion. Prévenir en amont fait toute la différence sur le taux de reconnexion.

On les passe en revue une par une, et le tri est souvent sévère : une bonne partie couvre des fonctions natives de PrestaShop, une autre ne sert plus vraiment, et il reste deux ou trois besoins réels qui deviennent des modules. Un module se développe une fois ; une app se loue tant que la boutique existe.

Oui, et il faut le dire clairement : Shopify gère les mises à jour, la sécurité et l'hébergement à votre place. Avec PrestaShop, quelqu'un doit s'en charger. C'est le prix de la maîtrise du code, et c'est exactement ce que couvre un contrat de maintenance mensuel — mises à jour, sauvegardes, surveillance et correctifs.

Le calcul se fait sur l'abonnement, la commission hors Shopify Payments et le total des apps mensuelles. Au-delà de quelques centaines d'euros par mois de plateforme, l'amortissement se compte en mois plutôt qu'en années. En dessous, la vraie raison de migrer n'est pas le coût mais le besoin de sortir du cadre — et c'est une raison suffisante.

Parce que la licence est gratuite mais que la boutique ne l'est pas : la plupart des fonctions commerciales sérieuses passent par des extensions payantes, souvent en abonnement annuel, et il en faut plusieurs pour couvrir ce que PrestaShop fait nativement. Le vrai coût de WooCommerce est celui de sa pile, plus le temps passé à la faire cohabiter à chaque mise à jour.

Oui, intégralement. La base WooCommerce est accessible directement, donc commandes, lignes de commande, adresses, statuts et historique se migrent sans limite de volume — contrairement à une migration depuis une plateforme fermée où l'API dicte le rythme.

Deux options selon le volume et l'usage. Peu d'articles et une publication occasionnelle : on les reprend dans le module de contenu de PrestaShop, une seule interface à administrer. Un vrai blog alimenté régulièrement : on garde WordPress sur un sous-répertoire pour lui seul, en conservant les URL et donc le référencement acquis.

Presque toujours, et le gain vient moins du moteur que du ménage. Une boutique WooCommerce lente l'est en général à cause d'une trentaine d'extensions qui s'exécutent sur chaque page et d'une table de métadonnées devenue énorme. Repartir sur un schéma dédié, sans cette pile, change l'ordre de grandeur avant même la première optimisation.

C'est le risque de toute migration, et c'est celui qui se maîtrise le mieux ici. WooCommerce laissant la main sur les permaliens, la structure est souvent reproductible presque à l'identique. Quand elle ne l'est pas, la table de 301 est établie et testée avant la bascule, jamais après.

De trois semaines pour un catalogue simple et peu d'extensions, à deux mois pour une boutique chargée avec du développement spécifique. L'audit initial donne la fourchette réelle : c'est le nombre d'extensions à remplacer, pas le nombre de produits, qui fait la durée.

Pas systématiquement, et je préfère le dire avant de vendre une migration. Si le site est d'abord éditorial et vend quelques produits en marge, une solution de paiement bien intégrée suffit largement. La bascule se justifie quand le commerce devient l'activité principale et que vous passez du temps à contourner l'outil plutôt qu'à vendre.

Non. Les pages et les articles sont repris avec leurs URL, ce qui est précisément le point sur lequel une migration se juge. Et si le blog est un actif important, l'option la plus sûre reste de le laisser sous WordPress sur un sous-répertoire : ses URL ne bougent alors pas du tout.

Oui, c'est même fréquent et cela fonctionne très bien. PrestaShop sert la boutique sur la racine du domaine, WordPress garde le blog sur un sous-répertoire. Chaque outil fait ce pour quoi il est bon, et le référencement des deux reste sur le même domaine, donc il continue de se renforcer mutuellement.

Cela dépend surtout du catalogue et du contenu à reprendre, pas du moteur de départ. La journée d'analyse préalable donne un chiffrage ferme plutôt qu'une fourchette de principe, et si elle conclut que la migration n'est pas justifiée, elle n'est pas facturée.

Non. La boutique se construit en parallèle sur une autre adresse et n'est mise en ligne qu'une fois la recette terminée. Le site WordPress reste en service jusqu'à la bascule, et disponible en secours après.

Oui, à condition d'être accompagné au début. Le back-office est plus riche que celui de WordPress parce qu'il traite des commandes et des stocks, mais la prise en main se fait sur vos propres données pendant le mois qui suit la mise en ligne, pas sur une documentation générale.

L'extension d'abord, si elle existe et si son auteur la maintient encore. Le sur-mesure se justifie quand le besoin est propre à votre métier, ou quand l'empilement d'extensions coûterait plus cher à l'année que le développement.

Il est à vous, documenté, et écrit pour qu'un autre développeur PrestaShop puisse le reprendre. C'est une exigence que vous devriez poser à n'importe quel prestataire.

Pas en soi. Ce qui pose problème, c'est une surcharge non documentée, découverte trois ans plus tard au moment d'une montée de version, sans que personne sache ce qu'elle corrigeait ni si on peut la supprimer.