Migration de Prestashop

Migrer sa version Prestashop, un casse-tête ?

Passer vers une nouvelle version de Prestashop a toujours été une étape sensible… mais est-ce que cela l’est encore en 2017 ? Ce matin j’ai effectué une nouvelle migration… voici mon retour d’expérience.

Les migrations c’est pas mon trip !

Dans le domaine de la prestation e-commerce, c’est pas forcément les migrations de boutique que j’affectionne particulièrement. Pourquoi ? Parce qu’il faut quand même être assez organisé pour s’en sortir et tout synchroniser en même temps.

Le principal problème est toujours lié au fait que le client a une boutique en production qu’il doit continuer à laisser tourner et au dernier moment il faut rapatrier toutes les dernières données à jour sur la version de développement pour pouvoir ensuite la passer en production.

Pas de protocole de 20 pages

Au sujet des migrations, j’ai discuté avec d’autres prestataires et certains ont un protocole très long pour effectuer des migrations de boutique. Tout est testé, noté… + complété par des scripts complémentaires pour migrer des données annexes etc…

Du coup, pour chaque boutique qu’ils migrent… ils peuvent rarement « industrialiser » le processus, car il faut toujours prendre beaucoup de variantes en compte. Du coup les migrations deviennent de véritables usines à gaz qu’il est difficile de maîtriser.

Méthode de simplification

Avec ma structure, je ne peux pas me permettre de passer des jours entiers sur des migration à étudier et à analyser (c’est usant)… il faut que ça aille vite et avec le moins de bugs possible. Actuellement je préconise donc toujours la méthode de migration universelle de Prestashop.

Si je regarde la base de ce client je vois plus de 300 tables dans sa base de données, je ne peux pas me permettre de commencer à farfouiller dans les « id » et faire des ajustements à gauche à droite, trop de risques de faire sauter quelque chose ou d’oublier un détail.

Actuellement je suis resté sur une politique de fonctionnement simple :

  1. Je clone la boutique de production, puis je travaille sur la boutique de développement.
  2. Une fois que la version développement est prête je re-transfert, les clients, les commandes et le stock.
  3. Je bascule la version de développement en production.

Pour actualiser les informations au dernier moment je fais ceci :

  • Je refais une copie du site production (sous l’ancienne version) et je refais la mise à jour avec le module One Click Upgrade.
  • Je réalise un export des tables importantes via PHPmyAdmin c’est-à-dire toutes les tables qui commencent par :
    – ps_address
    – ps_cart
    – ps_customer
    – ps_order (sauf order_state / order_state_lang)
    – ps_stock
    * il peut y avoir des variantes selon les modules installés
  • Je supprime ces mêmes tables dans ma version de développement, puis j’importe mon export SQL. Et voilà mon site de développement est à jour avec les dernières infos, j’ai plus qu’à le publier.

Fixer le cadre

Quand une migration est envisagée avec le client, je lui explique clairement ce qu’on va transférer durant la 2ème phase d’actualisation. Il faut que le client plie à un cadre de rigueur, c’est-à-dire que la création de nouveaux produits / catégories par exemple ne sera pas prise en compte.

Autant que le client concentre son énergie dans la nouvelle plateforme, sur sa version production il devra faire le minimum durant tout ce temps. Actuellement je ne pratique pas la migration différée / partielle de catalogue des produits, cela ferait exploser le prix de la migration et n’assurerait pas forcément une garantie de stabilité.

Et si le client n’en veut pas de cette manière de faire ? Jusqu’à présent j’ai eu de la chance d’avoir des clients qui comprennent cette méthode, je cherche la solution « équitable » sur tous les points (le prix, la prise de risque, la praticité).

Bilan

Ah oui il y’a un point que j’ai pas mentionné, il faut que la nouvelle version arrive rapidement, pour éviter que le client se trouve « trop limité » durant une trop longue période. Là encore il s’agit d’un autre problème le « temps de remise du projet », je vous parlerai tout bientôt d’un fonctionnement « Agile » sous Prestashop pour se concentrer sur l’essentiel.

Bien sûr après chacun aura son discours sur le sujet, le mien est basé sur ma taille d’entreprise et sur mon expérience avec Prestashop. Pour des très gros sites, cela peut prendre du temps… mais vous avez aussi des équipes dédiées derrière pour gérer la migration.

Et vous quelle est votre expérience sur la migration de votre boutique Prestashop ?

6 réflexions au sujet de « Migrer sa version Prestashop, un casse-tête ? »

  1. Salut ! J’ai lu ton article avec attention en quête d’une solution miracle pour les updates Prestashop… mais non, on fait la même chose, autant au niveau technique que relationnel client.

    Bien obligé de charger pas mal le client pour une mise à jour majeure Prestashop (puisque c’est beaucoup de boulot), et de le faire accepter une phase d’instabilité.

    Aujourd’hui, j’en viens à refuser des projets car le CMS ne me plait pas. Encore aujourd’hui, j’ai refusé un joli contrat qui aurait dû se faire sur Joomla. « Désolé, mais si vous voulez que je bosse pour vous efficacement, avec flexibilité et des tarifs attractifs, ça sera WP. »

    Ma dernière prestation m’a dégouté de Prestashop. Un truc tout simple à faire qui m’a pris la journée entière (derrière je facture 2 heures au client, faut pas déconner). Et on voit les prix des plugins, c’est du délire parfois : 200€ pour une fonctionnalité qui devrait être native. Et il faudra racheter le plugin à 100% du prix pour la prochaine mise à jour majeure !

    Je n’hésite plus à me retourner sur le client : « Ah oui monsieur, c’est long et c’est assez cher, mais bon… vous avez voulu absolument Prestashop, alors… ».

    Désolé pour le coup de gueule 🙂
    @+

    1. Hello,

      Effectivement je soulève ce point pour Prestashop, mais rare sont les outils qui permettent des migrations rapides et sans trop de problèmes. Même avec WordPress, si on n’a pas bien structuré son projet, thème enfant… des tas de plugins, lors de la migration c’est un vrai challenge.

      Après je pense qu’il y’a aussi un problème de comportement… un module Prestashop vendu 50 EUR en temps de travail ça représente quoi ? 1/2 heure de travail en coût horaire dans la vie réelle (si on travaille à 100 EUR de l’heure).

      Donc le client doit aussi comprendre que mettre en place un module, le configurer l’ajuster… ça prendra peut-être quelques heures et le prix initial du module n’a rien à voir avec le prix final qu’il va payer.

      Sur internet il y’a encore cette vision du « tout » pour « rien », il faut payer le tarif horaire d’un professionnel et c’est ça le plus cher dans le processus. C’est comme chez un garagiste une fois qu’il a la pièce qui coûte déjà cher… il doit faire son travail et ça prendra pas 5 minute même s’il a la bonne pièce.

      Ce problème est généralisé, j’ai des clients qui ne peuvent pas migrer pour des raisons de coût… mais à qui la faute ? Je ne pense pas que ce soit l’outil en soi, mais le fait qu’on pense que sur le web tout est simple et qu’il suffit de cliquer sur un bouton pour faire tout le travail.

      Voilà, il reste plus qu’à méditer ! Merci pour votre visite 😉 !

      1. D’accord avec tout ça.

        J’ai uniquement envie de rebondir sur un point :

        Je cherche tout le temps cette possibilité de Child Theme dans Prestashop et le moyen « d’override » certaines fonctionnalités en mettant du code dans des fichiers qu’il ne faudrait pas rétablir à la prochaine update (ex : functions.php de WP). Mais non… Si vous modifiez le code du thème Prestashop, il faudra réappliquer votre travail lors de la mise à jour de ce fameux thème…

        Non, vraiment… je ne peux plus 😀

        Mais j’admets volontiers que Prestashop a certaines qualités, par rapport à WooCommerce par exemple. J’ai écrit un article sur cela d’ailleurs, cherchez : woocommerce vs prestashop mr wp, dans Google. 😉

        Espérons que PS soit inspiré pour la version 2.0. 🙂 La concurrence saine est toujours appréciable.

        1. Hello,

          Effectivement dans Prestashop il n’y a pas cette notion de « thème enfant », on peut overrider le comportement du shop… les CSS… les modules… mais le thème c’est pas encore ça.

          Il manque encore des normes pour que tout soit vraiment bien carré, mais sous WordPress aussi y’a encore à faire… Par contre sous WP il faut dire que les migrations ça fonctionne assez bien (WordPress anticipe pas mal de paramètres et reste prudent lors de certains processus).

          Pour les intéressés, voici le lien vers l’article : https://www.mister-wp.com/plugin/woocommerce/

          Merci pour ce retour !

  2. Merci pour ce retour d’expérience très intéressant !
    Le fonctionnement que tu mentionnes est semblable aux mises à jour majeures de TYPO3.

    C’est encore appréciable de pouvoir mettre à jour le CMS entre versions majeures. Ce n’est pas forcément le cas de Drupal.

    Guillaume

    1. Hello,

      Les mises à jour sont en général toujours délicates… jusqu’à ce jour j’ai jamais entendu que c’était simple (surtout en plus quand on a un site avec un business solide et qui fonctionne bien).

      Où cela marche le mieux c’est sur les solutions « propriétaires » où tout est déjà automatisé et finalement l’utilisateur n’intervient pas dans les sources (version CLOUD).

      Sur ce point, j’avoue que ces solutions SAAS / CLOUD offrent un gros avantage, car on n’a plus la problématique technique à gérer… bien sûr il y’a beaucoup d’autres limitations… mais c’est une manière de ne pas avoir la problématique des mises à jour à gérer.

      Merci pour votre visite !

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *