Créer ou reprendre

Parce qu'il arrive avec quarante fonctions dont vous en utiliserez trois, et que chacune alourdit toutes les pages, même celles qui ne s'en servent pas. Et parce qu'on finit toujours par le modifier : sans copie séparée qui hérite de l'original — un « 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 : ses modules sont mûrs et stables. La 9 se défend en création, où l'on part de zéro sans passif — à 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 le rangement et les index — le classement interne qui permet de retrouver un produit rapidement — suivent. Ce n'est pas le nombre de produits qui pose problème mais la façon dont ils sont organisé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 soigné, monté en copie qui hérite de l'original pour survivre aux mises à jour ; 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 — la table qui renvoie chaque ancienne adresse vers la nouvelle — est fait avant la migration et non après. Shopify impose ses adresses en /products/ et /collections/ que PrestaShop ne reprend pas : sans ces renvois, chaque page connue de Google aboutit à une erreur « page introuvable ». 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 refasse le tour du site.

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. Seul le basculement du nom de domaine est instantané, et Shopify reste en ligne pendant les quelques heures où il se propage.

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 stockés sous une forme brouillée, illisible même pour Shopify. Vos clients reçoivent donc un email les invitant à en choisir un nouveau à leur première connexion. Les 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 d'origine. Le vrai coût de WooCommerce, c'est cet empilement d'extensions, plus le temps passé à les faire cohabiter à chaque mise à jour.

Oui, intégralement. Les données de WooCommerce sont directement accessibles, donc commandes, lignes de commande, adresses, statuts et historique se migrent sans limite de volume — contrairement à une plateforme fermée, qui ne laisse sortir les données qu'au compte-goutte et à son 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 travaillent sur chaque page et d'un stockage interne devenu énorme au fil des ans. Repartir sur une base conçue pour le commerce, sans cet empilement, change l'ordre de grandeur avant même le premier réglage fin.

C'est le risque de toute migration, et c'est celui qui se maîtrise le mieux ici. WordPress laisse la main sur l'adresse de chaque page, la structure est donc souvent reproductible presque à l'identique. Quand elle ne l'est pas, la table des renvois d'anciennes adresses vers les nouvelles 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 tous les tests validés. 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.

Pour les cas où le logiciel tout prêt devient un frein : vitesse critique, très forte montée en charge, règles métier très particulières, connexions complexes avec vos autres logiciels, sécurité élevée. Si vous devez tordre votre projet pour le faire entrer dans un CMS, c'est souvent le signe qu'il n'est pas adapté.

Première version simple (MVP) : 15 000 à 35 000 €. Application web complète : 35 000 à 100 000 €. Plateforme par abonnement (SaaS) ou projet complexe : 80 000 à 250 000 €+. Au temps passé (600 à 800 € par jour) ou au forfait, selon votre préférence.

Première version : 2 à 4 mois. Application complète : 4 à 8 mois. Projets très complexes : 8 à 18 mois. Je travaille par étapes courtes, avec des livraisons intermédiaires pour valider l'avancement régulièrement.

Cela dépend du projet. Application web classique : PHP 8.2 avec Laravel ou Symfony, base de données MySQL ou PostgreSQL. Échanges en temps réel : Node.js (WebSocket). Plateforme par abonnement appelée à grandir : Next.js avec une interface de données séparée. Je recommande la technologie adaptée à votre contexte, pas celle à la mode.

Correction des bugs, ajout de nouvelles fonctions, surveillance du site 24h/24. Forfait de maintenance ou facturation au temps passé. Je remets une documentation complète pour que vous restiez autonome.

Absolument. Le code vous appartient et vit dans votre propre espace de code (Git). Documentation complète. Aucune dépendance forcée envers moi ou un outil, contrairement à certaines plateformes fermées. C'est un de mes engagements.

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. Une surcharge est un fichier ajouté qui remplace un morceau du logiciel d'origine. Le problème, c'est celle qui n'est pas documentée : découverte trois ans plus tard lors d'une montée de version, sans savoir ce qu'elle corrigeait ni si on peut la supprimer.

Le thème enfant hérite du thème officiel et en reçoit les correctifs ; le thème Addons remplace tout et vous lie à son auteur. Pour une boutique qui doit durer, le premier.

Classic sur 1.7 et 8, éprouvé et couvert par tous les modules. Hummingbird à partir de la 8.1, plus moderne, encore inégalement pris en charge par les modules tiers : on vérifie les vôtres avant de choisir.

Le thème enfant n'existe pas en 1.6 et la version ne reçoit plus de correctifs. On parle d'abord migration vers la 8 ; le thème sur mesure fait partie du même chantier.

Six à neuf semaines du cadrage à la mise en ligne, entre 4 000 et 10 000 € HT selon le nombre de types de pages (accueil, catégorie, fiche produit). Prix fixe après cadrage.