---
title: "Fleurance Nature - Refonte Plateforme E-Commerce"
description: "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."
locale: "fr"
canonical: "https://portfolio.josedacosta.info/fr/realisations/fleurance-nature-refonte-ecommerce"
source: "https://portfolio.josedacosta.info/fr/realisations/fleurance-nature-refonte-ecommerce.md"
html_source: "https://portfolio.josedacosta.info/fr/realisations/fleurance-nature-refonte-ecommerce"
author: "José DA COSTA"
date: "2017"
type: "achievement"
slug: "fleurance-nature-refonte-ecommerce"
tags: ["PHP 5.3", "Magento EE 1.10", "ElasticSearch", "Zend Framework", "MySQL", "Varnish", "Apache", "WordPress", "Solr", "LXC", "Pentaho Kettle", "Git"]
generated_at: "2026-04-23T15:44:11.375Z"
---

# 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.

**Date:** Juillet 2017 - Septembre 2017  
**Duration:** 3 mois  
**Role:** Senior Software Engineer - Full-Stack  
**Technologies:** PHP 5.3, Magento EE 1.10, ElasticSearch, Zend Framework, MySQL, Varnish, Apache, WordPress, Solr, LXC, Pentaho Kettle, Git

### Key Metrics

- Modules custom: **-** - Modules Magento custom
- Fichiers PHP: **-** - Modifies ou créés
- Sites web: **-** - FR, International, Mincifine
- Articles blog: **-** - Migres depuis WordPress via RSS
- Environnements: **-** - Du local a la production
- Pages de specs: **-** - Document de spécifications final (v1.6)

## Présentation

_Périmètre du projet et contexte métier_

### Domain

E-commerce B2C - produits naturels et biologiques (sante, beaute, complements alimentaires)

### Target Users

Consommateurs finaux (France et international) achetant des produits naturels en ligne. Utilisateurs back-office gérant le catalogue, les commandes et les promotions.

**Content:** **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.

**Domain:** Domaine

**Target Users:** Utilisateurs cibles

**Functional Scope:** Périmètre fonctionnel

## Objectifs, Contexte & Risques

_Objectifs stratégiques et contraintes_

### Context

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.

- 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)

**Objectives:** Objectifs

**Context:** Contexte

**Risks:** Risques identifiés

**Risk1 Title:** Compatibilite descendante

**Risk1 Desc:** 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.

**Risk2 Title:** Seuils de performance

**Risk2 Desc:** 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.

**Risk3 Title:** Fragilite de l'intégration blog

**Risk3 Desc:** 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.

**Risk4 Title:** Volumetrie des flux ERP

**Risk4 Desc:** 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_

- Phase 1 - Flux ERP & 1000mercis
- Phase 2 - Conception graphique & Wireframing
- Phase 3 - Specifications & Développement
- Phase 4 - Recette & Livraison
- Phase 5 - Garantie

**Phase1 Period:** Janvier - Juillet 2017

**Phase2 Period:** Février - Juin 2017

**Phase3 Period:** Juillet - Octobre 2017

**Phase4 Period:** Septembre 2017 - Janvier 2018

**Phase5 Period:** Décembre 2017 - Mars 2018

## L'équipe & les parties prenantes

_Organisation du projet et interactions_

### Validation

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.

**Content:** 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.

**Team Composition:** Équipe Smile

**Stakeholders:** Parties prenantes externes

**Stakeholder Client:** Philippe B. - Contact projet client chez Fleurance Nature

**Validation Process:** Processus de validation

## Résultats

_Compétences acquises et livrables_

**For Project:** Livrables

**For Me:** Compétences acquises

## La suite du projet

_Ce qui s'est passe après la livraison_

**Content:** 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_

### Strength

- [object Object]
- [object Object]
- [object Object]

### Improvement

- [object Object]
- [object Object]
- [object Object]

### Lesson

- 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

**Strengths:** Ce qui a bien fonctionne

**Improvements:** Ce qui aurait pu etre amélioré

**Lessons:** Leçons durables
