Fleurance Nature - Refonte Plateforme E-Commerce
Refonte complète de fleurancenature.fr sur Magento Enterprise Edition - migration Solr vers ElasticSearch, refonte des flux ERP, architecture multi-site avec 60 modules custom sur 3 sites.
Modules custom
60+
Modules Magento custom
Fichiers PHP
1040
Modifies ou créés
Sites web
3
FR, International, Mincifine
Articles blog
512
Migres depuis WordPress via RSS
Environnements
8
Du local a la production
Pages de specs
50
Document de spécifications final (v1.6)
Présentation
Périmètre du projet et contexte métier
Fleurance Nature est une entreprise française fondée en 1972, spécialisée dans les produits naturels et biologiques (sante, beaute, complements alimentaires). La société vend via son site fleurancenature.fr, qui tourne sur Magento Enterprise Edition 1.10.
Le projet consistait en une refonte complète de la plateforme e-commerce, réalisée chez Smile (agence Open Source Solutions). Le périmètre couvrait 3 sites web (Fleurance Nature France, International, Mincifine), une migration de Solr vers ElasticSearch pour le moteur de recherche, et une refonte complète des flux de données ERP.
Le code existant était fortement personnalisé avec 60 modules Magento, 1040 fichiers PHP et des règles de tarification complexes impliquant 4 groupes clients sur 3 boutiques. Le modèle B2C cible les consommateurs a la recherche de produits de sante et beaute naturels.
Une part importante du travail portait sur l'architecture de base de données EAV (Entity-Attribute-Value) de Magento - un schéma ou les attributs produits sont stockés sous forme de lignes dans des tables separees plutot que comme colonnes dans une seule table. Cette approche offre une flexibilite maximale pour ajouter des attributs produits custom (comme "actifs naturels", "poids min/max", "identifiants de categories virtuelles") sans modifier le schéma de base. La contrepartie est la complexité des requêtes : une simple lecture de produit peut nécessiter des JOINs sur 6+ tables (une par type d'attribut : varchar, int, decimal, text, datetime, plus la table entite principale).
Le système de configuration et de surcharge de classes par XML de Magento était tout aussi central. Chaque comportement de module dans Magento 1 est déclaré via des fichiers XML (config.xml, system.xml, layout XML). Pour personnaliser un comportement natif - par exemple, la façon dont les prix sont indexés ou dont les résultats de recherche sont triés - le développeur créé une déclaration XML dans son module custom qui surcharge ("rewrite") la classe originale. Le système charge tous les fichiers XML des modules au démarrage et construit un arbre de configuration fusionné. Ce mécanisme a permis aux 60 modules custom de Fleurance Nature de modifier le comportement natif de Magento a tous les niveaux (modèles, blocs, controleurs, helpers) sans modifier une seule ligne du code source de Magento. Le revers de la médaille : le débogage exige de tracer la chaine de configuration XML pour comprendre quelle classe est réellement chargée a l'exécution.
E-commerce B2C - produits naturels et biologiques (sante, beaute, complements alimentaires)
Consommateurs finaux (France et international) achetant des produits naturels en ligne. Utilisateurs back-office gérant le catalogue, les commandes et les promotions.
- Recherche autocomplete avec ElasticSearch
- Navigation a facettes et categories virtuelles
- Refonte responsive mobile
- Vitrine internationale avec tarification localisée
- Intégration du blog WordPress via flux RSS (512 articles)
- Recherche par référence SKU pour les clients fidèles
- Regles tarifaires complexes (4 groupes x 3 sites)
- Flux de données ERP bidirectionnels
Objectifs, Contexte & Risques
Objectifs stratégiques et contraintes
Refondre le front-end et le back-office des 3 sites Magento avec un theme responsive moderne
Migrer le moteur de recherche de Solr vers ElasticSearch avec autocomplete et navigation a facettes
Intégrer le blog WordPress dans Magento via synchronisation de flux RSS
Refondre les flux de données ERP pour la synchronisation catalogue, stocks et commandes
Mettre en place l'intégration de la plateforme marketing 1000mercis (tracking, emailing, analytics)
La plateforme tournait sur Magento Enterprise Edition 1.10, une version déjà vieillissante en 2017. Le code avait accumulé 60 modules custom au fil des années, rendant les mises a jour difficiles et risquees.
La tarification était particulièrement complexe : 4 groupes clients (anonymes, general, abonnes fidèles, comites d'entreprise) avaient chacun des catalogues de prix différents sur 3 sites. Cela créait une matrice de 12 combinaisons tarifaires, chacune avec ses propres règles et promotions.
Les spécifications sont passées par 7 versions en 2 mois (de la v1.0 a 30 pages a la v1.6 a 50 pages), reflétant la découverte progressive des cas limites et règles métier caches dans le code existant.
Compatibilite descendante
Avec 60 modules custom, chaque modification risquait de casser des fonctionnalités existantes. Chaque changement nécessitait des tests de régression sur les 3 sites.
Seuils de performance
Le site de production servait de vrais clients quotidiennement. Une dégradation de performance pendant la migration était inacceptable - le cache Varnish devait rester opérationnel tout au long du processus.
Fragilite de l'intégration blog
L'intégration WordPress vers Magento reposait sur le parsing de flux RSS - une approche artisanale sans garantie transactionnelle. 512 articles devaient migrer sans perte de données.
Volumetrie des flux ERP
Les flux ERP géraient la synchronisation complète du catalogue produits. Toute erreur dans le flux pouvait corrompre les données produits, les prix ou les niveaux de stock sur les 3 boutiques.
Phases de réalisation
Découpage chronologique sur 13 mois
- Retro-ingénierie des flux ERP existants pour documenter tous les formats d'échange
- Reconception de la synchronisation bidirectionnelle (produits, stocks, commandes, clients)
- Implémentation de l'intégration de la plateforme marketing 1000mercis (pixels de tracking, déclencheurs email)
- Construction de tests automatisés pour la validation des flux avant déploiement en production
- Création des wireframes pour toutes les pages clés (accueil, categorie, produit, panier, tunnel de commande)
- Conception des mises en page responsives pour mobile, tablette et desktop
- Validation des maquettes visuelles avec le client via des cycles de revue iteratifs
- Production des spécifications graphiques pour 3 themes de sites distincts
- Rédaction des spécifications fonctionnelles détaillées (7 versions, de 30 a 50 pages)
- Migration du moteur de recherche de Solr vers ElasticSearch avec autocomplete et facettes
- Développement des modules de categories virtuelles et navigation a facettes
- Implémentation de l'intégration du blog WordPress via synchronisation de flux RSS
- Construction du theme front-end responsive sur les 3 boutiques
- Execution de la recette interne chez Smile sur les 3 sites web
- Gestion de la recette client avec signature formelle de PV
- Phase de contribution : migration de 512 articles blog et données produits
- Coordination du déploiement en production sur 8 environnements
- Support post-lancement pendant la periode de garantie de 58 jours
- Correction des anomalies de production signalees par le client et les utilisateurs
- Suivi des métriques de performance et stabilité de l'indexation ElasticSearch
- Transmission de la documentation et des procedures de maintenance a l'équipe TMA
Specification document grew from 30 to 50 pages across 7 versions (Jul-Sep)
L'équipe & les parties prenantes
Organisation du projet et interactions
Le projet suivait un workflow structure d'agence avec des portes de validation formelles. Chaque livrable nécessitait un procès-verbal (PV) signe avant de passer a la phase suivante. Cette approche réduisait l'ambiguite mais ajoutait du temps a chaque cycle d'iteration.
La communication passait par des reunions de suivi hebdomadaires, un système de tickets partage et des revues formelles de spécifications. Le client avait un contact projet dédié (Philippe B.) qui centralisait toutes les decisions métier.
Nicolas C.
Chef de projet - Planning, relation client, suivi budgetaire
Richard B.
Rédacteur de spécifications - Analyse fonctionnelle, recueil de besoins, rédaction de specs
Jose DA COSTA
Développeur - Développement Magento, migration ElasticSearch, personnalisation de modules
Philippe B. - Contact projet client chez Fleurance Nature
1000mercis - Fournisseur de plateforme marketing (tracking, emailing)
Fournisseur ERP - Synchronisation catalogue produits et commandes
Ideematic - Partenaire externe pour des integrations spécifiques
Validation formelle avec des documents PV (procès-verbal) a chaque phase. Specifications revues et approuvees avant le développement. Recette client avec validation écrite avant le déploiement en production.
Résultats
Compétences acquises et livrables
Moteur de recherche ElasticSearch avec autocomplete et navigation a facettes sur 3 sites
Refonte responsive complète de fleurancenature.fr, international et Mincifine
Flux de données ERP bidirectionnels refondus (produits, stocks, commandes, clients)
Intégration de la plateforme marketing 1000mercis (tracking, emailing, analytics)
Theme responsive mobile avec support de la vitrine internationale
Migration du blog WordPress (512 articles) intégrée dans Magento via RSS
Maîtrise approfondie de l'architecture de base de données EAV de Magento - comprendre comment les données produits sont réparties sur 6+ tables par type d'attribut, ecrire des requêtes optimisees qui joignent les tables d'entites aux tables de valeurs d'attributs, créer des attributs EAV custom avec leurs propres source models et backend types
Expertise pratique du système de surcharge de classes par XML de Magento - declarer des rewrites de modules dans config.xml pour modifier les modèles, blocs et controleurs natifs sans toucher au code source ; debugger l'arbre de configuration XML fusionné pour tracer les chaines de resolution de classes a travers 60+ modules
Experience pratique d'ElasticSearch (indexation, mapping, requêtes, autocomplete, facettes)
Complexité de la tarification e-commerce (multi-groupes, multi-sites, règles catalogue, règles panier)
Workflow d'agence (specs formelles, signature de PV, livraison structurée, periodes de garantie)
Rédaction de spécifications (contribution a 7 versions sur 50 pages d'exigences fonctionnelles)
Gestion de déploiement multi-environnements (8 environnements du local a la production)
8 environments from local development to production - each with distinct configuration
4 customer groups x 3 websites = 12 unique pricing combinations
La suite du projet
Ce qui s'est passe après la livraison
Le site redesigne a été mis en production et a continue de servir les clients de Fleurance Nature. La migration ElasticSearch a amélioré la pertinence de la recherche et les temps de réponse de l'autocomplete par rapport a l'ancienne configuration Solr.
Magento 1 a atteint sa fin de vie officielle en juin 2020. Adobe (qui a rachete Magento en 2018) a cesse de fournir des correctifs de sécurité, forcant tous les marchands Magento 1 a planifier une migration vers Magento 2 ou une plateforme alternative.
Pour Fleurance Nature, cela signifiait que les 60 modules custom construits pendant la refonte devaient etre réécrits ou remplaces. La forte personnalisation qui rendait la plateforme performante rendait aussi la migration éventuelle nettement plus coûteuse et chronophage.
Regard critique
Analyse rétrospective honnete
Qualité des spécifications
Le processus de spécifications en 7 versions (de 30 a 50 pages) a détecté la plupart des cas limites avant le développement. Cet investissement initial a fait gagner du temps pendant l'implémentation et réduit les surprises lors de la recette client.
Approche de compatibilité descendante
L'approche méthodique pour préserver les fonctionnalités existantes a travers 60 modules a porte ses fruits. La production est restee stable tout au long de la migration, et aucune régression majeure n'a touche les utilisateurs finaux.
Pipeline de déploiement structure
Le pipeline a 8 environnements (du local a la production) avec validation formelle a chaque étape a donne confiance dans chaque release. Les problèmes étaient détectés tot en intégration ou en preprod, pas en production.
Rester sur Magento 1 en 2017
Magento 2 était déjà disponible. Lancer un projet de 13 mois sur Magento 1 en 2017 signifiait construire sur une plateforme avec seulement 3 ans de support restant. Une migration vers Magento 2 aurait été plus pérenne, bien que significativement plus coûteuse a l'époque.
Intégration artisanale du blog
L'intégration WordPress vers Magento via parsing de flux RSS était fragile. Une intégration par API ou un CMS headless aurait été plus fiable pour les 512 articles.
Complexité tarifaire
La matrice tarifaire 4 groupes x 3 sites (12 combinaisons) a été documentée mais jamais simplifiee. Les règles métier auraient pu etre rationalisees avant implémentation plutot que de reproduire fidelement toute la complexité existante.
Des spécifications bien écrites reduisent les surprises pendant le développement - le processus en 7 versions a prouve sa valeur malgre l'investissement en temps
La compatibilité descendante multiplie la complexité de façon exponentielle - chaque nouveau module interagit avec tous les existants, et la couverture de tests croit de façon quadratique
La tarification e-commerce est toujours plus complexe que ce que le brief initial laisse penser - les règles cachees émergent pendant l'implémentation, pas pendant le recueil de besoins
Parcours associe
Experience professionnelle liee a cette realisation
Competences mobilisees
Competences techniques et humaines appliquees
Competences techniques
Galerie d'images
Captures et visuels du projet
