Stoneageblog.com

J’ai attendu un moment avant de commencer à parler de Magento sur ce blog, pourtant il y a un an je promettais de parler d’ecommerce plus régulièrement… Bref, il y a une bonne raison à tout cela : le temps !

Le temps, depuis mon arrivée chez Market Editions (mon entreprise actuelle) je l’ai passé (entre autre) à bosser sur la mise en place d’une plateforme ecommerce multi-boutique (multi-lingue et multi-devises) sous Magento pour venir remplacer nos différentes solutions Oscommerce. La réflexion sur ce projet a commencée il y a 2 ans environ avec le choix de la plateforme, et depuis, avec une équipe de choc et quelques bons partenaires, nous avons sorti notre première refonte (mariages-cards.com) il y a presque 1 an, suivie par 3 de nos autre sites (baby-cards.nl, baby-cards.de et foto-cards.com). La migration de l’ensemble de nos sites n’est pas encore terminée (encore 2 sites doivent basculer et nous devons aussi gérer avec les sorties comme nos tout derniers planet-cards.co.uk et planet-cards.es), je vous parle donc d’un projet toujours en cours mais sur lequel je commence à avoir assez de recul pour commencer un petit retour d’expérience personnel.

Lorsqu’on parle de migration ou de refonte, la première chose qui vient très très vite à l’esprit est : « Chouette ! Je vais te leur caler un design tout neuf à la pixelperfect, une ergonomie avec un taux de transfo à 2 chiffres avant la virgule, je vais te leur coller du web2, de l’ajax, de l’html5 et tout ce qui va bien en ce moment, et bien sûr je vais te leur conjuguer Twitter et Facebook à tous les temps… attention ça va déchirer ! »

[...] Petit moment de nostalgie ^^ [...]

Allez, on redescends sur la planète web1 et on se raccroche au wagon IE6 !

C’est certain, l’ergnomie, le design, les technos… tout cela est important mais c’est loin (très loin même) d’être la partie la plus importante et la plus difficile d’un tel projet…

Voilà, le teasing est fait ! Maintenant, afin de me donner une chance de publier un jour cet article je vous préviens qu’il sera scindé en plusieurs « petits » bouts…. Et oui ! Si je peux faire un constat sur ce blog c’est que je ne suis ni très régulier ni très assidu… Et quand le nombre de brouillons sur wordpress dépasse le nombre d’articles publiés c’est qu’il y a un soucis quelque part !

Au programme des réjouissances donc :

1. Vous êtes ici -> Qu’est ce que je fais de mes clients ? (Migration des données)
2. Ok, les clients c’est fait, et mon service client ? (Gestion des commandes)
3. J’ai toutes mes données, maintenant je peux repeindre les murs ? (Réalisation du front office)
4. Ah bon… il fallait aussi que la boutique soit connectée à mon outil d’emailing ? (Intégration des outils tiers)
5. Petit développeur, s’il te plaît, dessine-moi un mouton magento… (Choix de prestataires, dimensionnement de l’équipe, montée en compétence)
6. Bonjour Monsieur Dell, vous me mettrez 2 douzaines de processeurs, 48Go de ram, un loadbalancer et quelques To de disques… (Architecture et dimensionnement de l’hébergement)
7. Euh… on m’avait dit que Magento c’était génial pour le réf nat mais depuis qu’on a migré on a disparu de google ! (Problématiques SEO lors d’une migration : l’importance des redirections 301)
8. Allo Huston, le site est en ligne mais on a plus de commandes… WTF ? (Les moyens de suivi et d’analyse des problèmes éventuels : comment réagir vite et bien !)
9. Le CA du jour ? Ah.. euh… non on a pas prévu de reporting… attendez je vais demander au développeur de nous faire une requête SQL… (Importance du reporting et mise en place d’outils adéquats)
10. Boss, je lance une refonte complète du S.I., ça va prendre 2 ans, coûter beaucoup d’argent et en plus je vais avoir du mal à gérer d’autres projets… (Comment concilier un projet de migration, de l’amélioration continue et des sorties de nouveaux sites : tâche difficile mais nécessaire.)
11. D’ici que j’atteigne le onzième point, j’aurai bien trouvé un titre à cette partie

Maintenant que j’ai annoncé le menu, je vais peut être me sentir obligé de le cuisiner ! C’est donc parti pour l’entrée…

Petit disclaimer avant de commencer tout de même : je n’ai pas la science infuse et ne prétends pas maitriser le sujet, c’est principalement un retour d’expérience personnel et des écrits suite à nos différents projets, nos succès et nos erreurs évidement. D’ailleurs tout cela n’est pas uniquement le fruit de mon travail, j’en reparlerai donc en partie 5 mais je suis loin d’être le seul intervenant sur ce genre de projet…

1. Migration des données : clients, commandes, paniers, produits, etc.

C’est LA grosse partie du projet, de loin. Pensez y dès le départ, vous avez déjà une boutique existante sur oscommerce, avec un volume de clients, de commandes, de produits et aussi de paniers en cours : il n’est pas pensable de les laisser de côté pour une migration.

Je n’ai pas besoin de vous faire un dessin mais si vous oubliez par exemple tous les paniers en cours lors du passage d’une boutique à l’autre… vous aurez une belle baisse de CA les jours suivants (et croyez moi, il vaut mieux minimiser les causes possible de baisse de CA lors d’un projet de migration… car si baisse il y a, moins vous aurez de sources d’erreurs différentes, moins l’analyse sera complexe ! Mauvaise expérience inside, mais j’y reviendrai.)

Nous avons donc entamé cette migration de données sur notre premier site il y a 1 an et demi, à l’époque aucun outil existant ne permettait d’assister cette migration. Nous sommes donc parti « from scratch » comme on dit dans les milieux autorisés ! Depuis, je n’ai pas vérifié mais il doit exister sur Magento des modules de migration un peu plus adaptés (je ne parle pas du truc par défaut qui est de mémoire tout sauf pratique). D’ailleurs si vous en connaissez et que vous en avez utilisé je vous invite à me laisser quelques notes en commentaires.

1.1 Analyse de l’existant

Nous avons commencé par analyser et identifier l’ensemble des données que nous avions à migrer depuis Oscommerce. Ca peut paraitre simple et évident comme étape mais c’est important d’avoir une cartographie complète de votre base de donnée (et pas seulement les clients, mais aussi l’historique de leur relation avec votre boutique… il serait bête qu’au changement de système vous perdiez tous ce que vous avez mis des mois voir des années même à construire !)

Vous allez donc passer au crible :

• Vos clients
• Vos produits
• Vos commandes
• Vos lignes de commandes
• Vos paniers
• Vos listes d’envies
• Vos trucs spécifiques (nous c’est des personnalisations de produits !)
• Vos historiques de status de commandes
• …et j’en oublie certainement !

Et pour chacun, vous allez identifier ce qui le constitue. Si je prends l’exemple « bateau » du client :

• Son nom
• Son prénom
• Son email
• Son carnet d’adresse
• Ses informations personnelles (oui oui, tout ce que les gars en marketing vous demande de stocker pour faire du one to one )
• Ses informations de connexions (login, mot de passe, date d’ouverture de compte, date de dernière connexion)
• Ses opt-ins (bah oui, si du jour au lendemain vous n’envoyez plus de mail à toute votre base parce que vous avez oublié de migrer les opt-ins…)
• …

Et vous recommencez avec vos paniers, vos commandes, vos trucs spécifiques, etc… Une fois que tout est clair et bien en ordre vous pouvez commencer à vous poser la question « Où c’est que je mets tout ça dans Magento ? »…

1.2 Analyse de la cible (Magento)

Il faut savoir une chose : d’un point de vue données, Magento est juste complètement différent d’oscommerce. Si vous plongez votre nez (et vous devrez le faire !) dans le schéma de base de donnée, vous découvrirez… un truc illisible ! Même pour un habitué des base de données ! Autant sur Oscommerce vous avez une table produits, une table clients, une table commande et une table panier… autant sur magento rien que pour les produits vous devez avoir 10 tables différentes… N’espérez malheureusement pas résoudre votre problématique de migration en 2 ou 3 requêtes SQL bien senties !

Magento est basé sur le modèle EAV cela lui confère une souplesse importante mais une difficulté d’appréhension toute aussi grande. A part si vous avez déjà travaillé avec des outils comme EzPublish (qui est/était au CMS de site internet ce que Magento est au CMS de ecommerce) vous allez traverser une looooongue phase d’adaptation !

Le secret, c’est le « reverse engineering » : pour faire simple, vous regardez votre base de donnée magento, vous allez sur votre boutique de démo, vous créez un compte client, puis vous retournez sur votre base de donnée et vous regardez ce qui a bougé Après avoir fait cela de longues heures journées semaines vous aurez une meilleure connaissance de ce qu’est Magento d’un point de vue « données ».

Vous avez ensuite 2 orientations possibles, si votre oscommerce est encore jeune et léger, vous pouvez entammer votre migration en passant par l’API de développement Magento. En gros, ça doit donner un truc comme « pour chaque client oscommerce, je crée un objet magento de type client auquel j’assigne toute les bonnes valeurs et je finis par le sauver dans la base de donnée ». Avantage : pas besoin d’être un expert en SQL, la seule manipulation de l’API vous permettra de « ranger » toutes les informations de vos clients oscommerce au bon endroit dans votre magento, c’est incontestablement la méthode la plus propre ! Inconvénient : c’est une solution impensable si vous avez 100000 clients et quelques heures pour réaliser la migration le jour J, et oui… Magento et son abstraction via son API c’est top, mais c’est lourd

Nous sommes donc parti vers une solution maison à base de mapping entre les 2 bases de données…

1.3 Le pont entre Oscommerce et Magento (… c’est un peu notre pont de la rivière kwai à nous !)

Une fois les 2 maillons de la chaîne assimilés il a donc fallu construire un « pont » entre les deux. Nous avons utilisé pour cela un « ETL » (Talend) dont le rôle est d’extraire (E) les données d’un côté, les transformer (T) et les charger (Load) de l’autre côté.

Chacune des étapes est importante, le E et le L sont facilitées si vous avez correctement analysé vos données et bien compris où elles devront être chargées dans Magento. Le T, soit l’étape de transformation peut elle se révéler bien plus complexe selon votre historique sur Oscommerce. En effet les données que vous avez enregistrées au fil du temps sur votre boutique ne sont pas forcément « propres » et cohérentes (Rappelez vous le jour où vous avez décidé de changer le taux de TVA à l’export, ou encore le jour où vous avez décidé de payer la TVA sur vos frais de port… vous êtes vous assuré que votre historique de commande s’adaptait bien à toute ces nouvelles règles ?). Il faut donc mettre en forme chaque donnée et la vérifier méticuleusement d’un point de vue logique mais aussi comptable afin d’être certain que la cohérence soit conservée au moment du changement de système.

C’est une partie du projet qu’il faut réaliser avec attention car vous êtes en train de manipuler les données clients. Il est primordial qu’une fois que la boutique aura migré, vos clients puissent toujours s’identifier par exemple ! C’est facile à dire comme ça, mais la problématique des mots de passe n’est pas légère… bien souvent, les manières de les enregistrer diffèrent selon les outils ecommerce. Ceci n’est qu’un des innombrables problèmes potentiels qui se présenteront sur votre chemin : TVA, coupons, frais de port, paniers en cours, liste d’envies, commandes, lignes de commandes, totaux, HT, etc… ce sont autant de mots clés que vous croiserez lors de cette phase de migration et croyez moi, chacun d’eux vous donnera du fil à retordre !

Petite note pour ceux qui, comme nous, sont dans un environnement multi-boutique : vous souhaitez passer de vos N sites oscommerce (avec leurs N bases de données bien séparées et leur N codes sources bien différents) à une seule belle et robuste boutique Magento : /!\ les problématiques de migration seront décuplées /!. En effet, en plus des problématiques « classiques » de migration vous aurez des problématique nouvelles de fusion des informations. Petit exemple rapide, j’ai 2 boutiques oscommerce différentes, le client Dupont est client de mes 2 boutiques, il faudra alors penser à :

• Ne pas l’écraser lors de la migration de la seconde boutique (sur quoi je me base pour le reconnaitre ? email ? nom et prénom ?… et si sur la boutique 1 il a utilisé le nom de sa femme et sur la boutique 2 son propre nom, je garde lequel ?)
• Mettre à jour son carnet d’adresse avec ses nouvelles informations si et seulement si ces informations sont plus récentes que celles de la boutique 1
• Vérifier qu’il n’a pas utilisé 2 mots de passes différents sur chacune des boutiques et si c’est le cas, et bien il faudra soit décider lequel garder, soit lui permettre d’utiliser les 2…
• et ce n’est qu’un aperçu des problématiques nouvelles que cela amène, il y en a des dizaines bien particulières à l’environnement multi-boutique mais « mono base de donnée » de Magento…. Le jeu en vaut pourtant la chandelle, si cette fusion est bien faite, vous profiterez pleinement (plus tard) des possibilités de Magento en terme de CRM !

1.4 Testez, testez, testez…

Il est important de garder en tête que l’outil qui réalisera la migration des données le jour J doit pouvoir être lancé régulièrement (en effet, il n’est pas question de migrer les données 1 mois avant la date de sortie du site et de laisser sur le carreaux les clients inscrits depuis !). Vous devrez donc établir un plan de migration à l’avance, commencez probablement à migrer vos données en amont où au moins faire des tests en conditions quasi réelle pour vous assurez que le jour J tout se passera bien.

Enfin, n’oubliez pas non plus que pour la migration vous n’aurez qu’un espace de temps restreint (une nuit au maximum !). Et oui, tout le monde ne peut pas se permettre de fermer son (Apple) store en pleine journée

Votre outil doit donc être assez performant… Cela va dépendre de la façon de le coder mais aussi et surtout du volume d’information à traiter. Ne lésinez pas sur les tests, qu’ils soient de cohérence (même basiques : nombre de comptes clients oscommerce avant migration = nombre de compte clients sur magento après migration) ou de performances (1h de migration pour 10000 clients, j’ai 100000 clients : ça passe pas en une nuit !).

Je vous promets, lorsqu’arrive le jour J (enfin la nuit N dans notre cas) c’est assez frustrant et difficile de regarder tout le monde autour de soi et d’annoncer une petite heure avant le levé du jour « on abandonne, ça passera pas » à une équipe qui vient de passer une journée complète de boulot suivie par une nuit intense de migration et qui devra le lendemain assurer comme elle peut sa journée… (PME style !). Bref, tous les tests que vous pouvez faire, faites les avant et faites les biens

Pour ceux qui se posent la question : oui, c’est de l’histoire vécue, c’était notre première migration (mariages-cards.com) et cette première tentative était… douloureuse. Heureusement le lendemain tout est rentré dans l’ordre et la migration a aboutie ! Je reparlerais souvent d’ailleurs de ce site, en effet en tant que première boutique Market Editions migrée, il a essuyé à peu prêt tous les plâtres

1.4 Et… ça coûte cher la migration ?

Je ne parlerai pas en € car ce n’est pas très représentatif. Mais pour raisonner en terme de gestion de projet, il faut considérer que cette problématique de migration représente presque 1/3 du projet en terme de charge. En d’autres termes, si vous êtes maintenant en train de préparer votre projet de migration Oscommerce -> Magento et que vous avez prévu d’y passer 3 mois en tout et pour tout, si vous ne vous sentez pas encore sensibilisé à tout ce que j’ai raconté plus haut : vous pouvez allègrement prévoir 1 mois de boulot supplémentaire !

Pour résumer : oui, ça coûte cher, c’est pas la phase la plus « marrante » et c’est de loin la plus critique mais si vous ne la prenez pas à bras le corps, vous risquez d’en pâtir plus tard ou tout simplement de ne pas aboutir !