Intégration API entre Cegid Y2 et ShippingBo : un middleware sur mesure pour automatiser la supply chain internationale de Fauré Le Page

Sommaire du projet

1. 1. Contexte et enjeux : harmoniser ERP, OMS et logistique internationale
2. 2. Architecture générale du middleware : ingestion, transformation et orchestration
3. 3. Cegid Y2 comme source de vérité : gestion des fichiers RFE et Azure Blob Storage
4. 4. Le cœur du système : parsing, validation métier et transformation des flux
5. 5. Intégration ShippingBo : publication API, statuts logistiques et boucle d’information
6. 6. Cartographie complète des flux : commandes, transferts, achats, stocks et réceptions
7. 7. Command Bus et planification : un moteur d’exécution robuste et rejouable
8. 8. Supervision temps réel : interface de monitoring, logs et rejouabilité
9. 9. Module Fournisseurs & ASN : un portail dédié pour les partenaires
10. 10. Sécurité, qualité et traçabilité : contrôles, tests et reprise après incident
11. 11. Stack technique : Symfony 7, Docker, Azure, API REST et outils internes
12. 12. Méthodologie projet : collaboration agile entre Dawap, FLP et ShippingBo
13. 13. Résultats : automatisation, fiabilité et supply chain unifiée
14. 14. Une architecture prête pour l’avenir : évolutivité, extensions et nouveaux flux

1. Contexte et enjeux : harmoniser ERP, OMS et logistique internationale

Une maison de luxe avec une réalité opérationnelle très technique

Maison de luxe française fondée en 1717, Fauré Le Page s’est construite sur la précision, le détail et l’exigence. Cette exigence ne s’arrête pas aux ateliers et aux boutiques : elle se retrouve aussi au cœur de l’architecture de son système d’information. Derrière l’élégance de la marque, on trouve une réalité opérationnelle complexe : un ERP Cegid Y2 comme socle historique, un OMS moderne ShippingBo pour piloter la logistique et une supply chain internationale opérée avec un prestataire logistique global.

Le défi pour Fauré Le Page était de faire dialoguer ces mondes hétérogènes sans rupture : Cegid Y2 parle fichiers RFE structurés, séquentiels et très orientés ERP, tandis que ShippingBo repose sur une logique API REST et JSON, temps réel et événementielle. L’enjeu : construire une passerelle fiable, traçable et évolutive pour que la donnée circule avec la même précision que les produits sortent des ateliers.

Un triptyque critique : ERP, OMS, logistique internationale

Le système d’information de Fauré Le Page repose sur trois briques majeures :

• Cegid Y2 : ERP central, utilisé pour la gestion commerciale, comptable et stock.
• ShippingBo : OMS moderne, orchestrant les flux logistiques, les entrepôts et le prestataire logistique (DHL).
• Un environnement logistique international : entrepôts, flux inter-boutiques, boutiques physiques et e-commerce.

Historiquement, ces systèmes ne communiquaient que partiellement, avec des échanges manuels ou des scripts isolés. Fauré Le Page avait besoin d’un socle d’intégration unique pour fluidifier les échanges et fiabiliser la donnée sur l’ensemble de la chaîne.

Les enjeux métier : une colonne vertébrale numérique pour la supply chain

Au-delà de la technique, les enjeux du projet étaient profondément métier. La maison souhaitait :

• Automatiser les échanges entre Cegid Y2, ShippingBo et le prestataire logistique.
• Assurer une cohérence parfaite des données : commandes, transferts, achats, stocks, réceptions.
• Réduire les manipulations manuelles et les risques d’erreurs associés.
• Offrir aux équipes internes une vision claire et traçable de tous les flux.
• Poser un socle réutilisable pour de futurs flux, partenaires ou points de vente.

Autrement dit : construire une colonne vertébrale numérique pour la supply chain, capable de suivre le rythme d’une maison de luxe internationale.

Pourquoi un middleware sur mesure et pas un simple connecteur ?

Le projet ne pouvait pas se contenter d’un “pont” technique minimal. Cegid Y2 et ShippingBo n’ont ni la même grammaire, ni la même vision des processus :

• Cegid Y2 : logique ERP batch / fichiers RFE, hautement structurée et orientée contrôles comptables.
• ShippingBo : logique API REST / JSON, orientée évènements logistiques et temps réel.
• DHL & logistique : contraintes de terrain (réceptions, transferts, statuts colis, délais, anomalies).

Il fallait donc un middleware intelligent, capable de comprendre les flux métier, de les valider, de les transformer, et de les tracer de bout en bout. Un simple connecteur “fichier → API” n’aurait pas permis le niveau de contrôle, de supervision et d’évolutivité recherché.

L’approche Dawap : d’abord le métier, ensuite le code

Dawap est intervenu en tant que partenaire d’intégration, avec un rôle d’architecte entre ERP, OMS et logistique. Avant de poser la moindre ligne de code, le travail a consisté à décortiquer les flux métier : comprendre ce que signifie une commande, un transfert, un stock qualité, une réception, côté Cegid comme côté ShippingBo, et comment ces notions devaient se répondre.

Cette approche s’est structurée autour de quatre principes clés :

• Compréhension métier avant tout : chaque flux correspond à un besoin opérationnel précis.
• Clarté architecturale : une brique par responsabilité, pas de logique cachée.
• Traçabilité totale : aucun traitement implicite, chaque action est journalisée.
• Évolutivité : chaque flux peut être étendu, désactivé ou remplacé sans refonte globale.

Un projet conduit en mode agile, au rythme du métier

Le projet a été mené en méthodologie agile, avec des sprints courts et des livraisons fréquentes :

• Sprints hebdomadaires : objectifs clairs, incréments fonctionnels concrets.
• Reviews régulières avec les équipes Fauré Le Page et ShippingBo.
• Ajustements continus en fonction des retours métier et des tests flux réels.
• Documentation progressive et structurée à mesure de la stabilisation des flux.

Ce rythme a permis de concilier rigueur ERP (Cegid Y2) et agilité OMS (ShippingBo), tout en gardant le cap sur un middleware sobre, fiable et lisible.

La section suivante détaillera l’architecture générale du middleware : comment les fichiers RFE sont ingérés, transformés, validés, puis publiés dans ShippingBo avant d’être renvoyés dans Cegid Y2 pour fermer la boucle.

2. Architecture générale du middleware : ingestion, transformation et orchestration

Un middleware indépendant, interconnecté mais non intrusif

Le middleware conçu par Dawap a été pensé comme un système autonome, capable de dialoguer avec Cegid Y2, ShippingBo et Azure sans jamais imposer de modification lourde aux systèmes existants. Il fonctionne comme un chef d’orchestre : il observe, récupère, transforme, pousse et historise les flux, tout en respectant les contraintes et les langages propres à chaque brique (fichiers RFE côté Cegid, JSON/API côté ShippingBo).

Concrètement, le middleware est une application Symfony 7 containerisée via Docker, connectée à Azure Blob Storage, à l’API REST de ShippingBo et à une base MySQL d’historisation. Chaque flux (commandes, transferts, achats, stocks, réceptions) est encapsulé dans un module dédié, exécuté selon une logique d’orchestration propre.

Bloc 1 – Ingestion : surveillance d’Azure Blob Storage et récupération des fichiers RFE

Côté ERP, Cegid Y2 reste la source de vérité. Il continue de produire des fichiers RFE pour l’ensemble des flux : commandes B2B, transferts, transferts boutiques, achats fournisseurs, stocks qualité, etc. Ces fichiers sont déposés dans un conteneur Azure Blob Storage dédié, que le middleware surveille en continu via des tâches planifiées.

Pour chaque type de flux, un processus d’ingestion spécifique est défini :

• Détection de nouveaux fichiers dans le blob cible (par pattern, préfixe ou répertoire).
• Téléchargement sécurisé du fichier RFE.
• Contrôle basique (taille, encodage, structure globale.
• Référencement du fichier dans la base d’historisation (type, date, statut initial).

Aucun fichier n’est traité “à la volée” sans journalisation : dès son arrivée, il est identifié, tracé et rattaché à un flux métier précis.

Bloc 2 – Parsing & validation métier : transformer le RFE en objets métier

Une fois ingéré, chaque fichier passe dans un moteur de parsing interne qui décode sa structure RFE pour la transformer en objets métier Symfony (Command, Transfer, PurchaseOrder, StockMovement…). Ce parsing ne se contente pas de découper les lignes : il reconstruit la logique métier de Cegid Y2.

Vient ensuite une étape clé : la validation métier. Avant d’envisager un envoi vers ShippingBo, le middleware vérifie :

• la cohérence des statuts (commande, transfert, réception…) ;
• la correspondance des SKU avec les référentiels attendus côté ShippingBo ;
• la présence des informations indispensables (entrepôt, boutique, quantités, dates) ;
• l’intégrité du flux (pas de lignes orphelines, pas d’enregistrements tronqués).

En cas d’erreur, le flux est immédiatement marqué comme en anomalie, logué et visible dans l’interface de supervision, sans jamais polluer ShippingBo avec des données incomplètes ou incorrectes.

Bloc 3 – Transformation : du langage Cegid au langage ShippingBo

Une fois validés, les objets métier sont transformés en payloads JSON conformes aux spécifications de l’API REST de ShippingBo. Cette étape de transformation est au cœur du middleware : elle traduit la grammaire ERP (codifications, types de lignes, statuts, codes de mouvement) en une grammaire logistique moderne compréhensible par ShippingBo.

• Mapping précis des champs Cegid → ShippingBo (commandes, transferts, achats, stocks).
• Conversion des formats (dates, nombres, codes pays, statuts).
• Gestion des cas particuliers (boutiques, transferts inter-entrepôts, stocks qualité).
• Enrichissement éventuel (ajout de métadonnées, références internes, tags).

Chaque transformation est horodatée, historisée et consultable dans le back-office, afin de garder une traçabilité complète des décisions prises par le middleware.

Bloc 4 – Orchestration & publication : Command Bus et appels API ShippingBo

L’envoi vers ShippingBo est orchestré par un Command Bus interne : chaque flux correspond à une commande Symfony dédiée (par exemple : SyncOrdersFromERPToShippingBoCommand, SyncTransfersToShippingBoCommand, etc.). Ces commandes sont planifiées par un scheduler interne (ou via cron), qui gère la fréquence, les priorités et les dépendances entre flux.

Lors de l’exécution, chaque commande :

• récupère les flux prêts à être envoyés ;
• appelle l’API REST ShippingBo avec un token sécurisé ;
• interprète la réponse (succès, warning, erreur) ;
• met à jour l’état du flux dans la base d’historisation ;
• déclenche, si besoin, un flux retour (par exemple pour les réceptions).

En cas d’erreur API, le flux est placé dans une file dédiée, prêt à être rejoué, sans jamais être perdu.

Bloc 5 – Retour d’information : ShippingBo → Middleware → Cegid Y2

L’architecture n’est pas unidirectionnelle. Le middleware récupère également les informations logistiques en retour de ShippingBo : statuts de réception, transferts effectués, mouvements de stock confirmés… Ces données sont à leur tour retransformées et réinjectées dans Cegid Y2 sous forme de fichiers CSV/RFE ou formats attendus, fermant ainsi la boucle d’information complète.

Cette boucle ERP ↔ Middleware ↔ OMS garantit que les équipes Fauré Le Page disposent d’une vision exacte et synchronisée de leurs opérations, tant côté ERP que côté logistique.

Une architecture modulaire et extensible par design

Chaque flux est isolé dans ses propres commandes, services et règles, ce qui permet :

• d’ajouter un nouveau type de flux (ex : nouveau type de mouvement) sans impacter les autres ;
• de désactiver temporairement un flux en phase de test ou de migration ;
• d’ajuster la fréquence d’exécution en fonction des besoins opérationnels ;
• de réutiliser cette architecture pour d’autres projets Cegid/ShippingBo ou d’autres ERP.

Cette architecture générale constitue la charpente technique du projet : elle rend possible la mise en place de tous les flux détaillés dans la section suivante, depuis les commandes B2B jusqu’aux réceptions logistiques et aux modules fournisseurs.

3. Cegid Y2 comme source de vérité : gestion des fichiers RFE et Azure Blob Storage

Cegid Y2, le socle ERP et la source d’information principale

Dans l’architecture de Fauré Le Page, Cegid Y2 reste la source de vérité. C’est depuis lui que partent les informations structurantes : commandes B2B, transferts d’entrepôts, achats fournisseurs, mouvements de stock, statuts qualité. Le middleware a été conçu pour respecter cette hiérarchie : il n’invente rien, il réplique et orchestre les données émises par l’ERP dans des formats compatibles avec ShippingBo.

Cegid Y2 s’appuie sur un mécanisme historique mais extrêmement fiable : les fichiers RFE (Récapitulatif de Flux d’Échange). RFE est un format de fichier structuré, séquentiel et normé, utilisé depuis des années dans les environnements ERP retail pour transmettre des données de manière robuste. Chaque fichier RFE correspond à un flux précis, avec une syntaxe stricte et des lignes codées par type (entête, détail, totaux).

Un format RFE rigoureux mais exigeant

Les fichiers RFE produits par Cegid sont particulièrement exigeants : le moindre caractère manquant ou mal positionné peut rendre un fichier inutilisable. C’est pourquoi le middleware doit :

• interpréter les entêtes et pieds de fichier avec précision ;
• décoder les lignes de données suivant leurs index exacts ;
• déterminer le type de flux (commande, transfert, stock, achat…) via les champs métier ;
• identifier les lignes invalides ou incomplètes ;
• reconstruire la structure métier pour la transformer en objets internes.

Cette rigueur est un atout : elle garantit l’intégrité de la donnée depuis l’ERP. Mais elle impose une logique de parsing avancée, totalement encapsulée dans le middleware Dawap.

Azure Blob Storage : la zone d’échange sécurisée avec l’ERP

Plutôt que d’échanger des fichiers via FTP ou réseau interne, Fauré Le Page a fait le choix d’un stockage moderne : Azure Blob Storage. C’est là que Cegid dépose en temps réel les fichiers RFE, et c’est là que le middleware vient les récupérer.

Ce choix apporte trois avantages majeurs :

• Haute disponibilité : Azure garantit une accessibilité continue et redondée.
• Traçabilité native : chaque dépôt est horodaté et identifiable.
• Sécurisation des flux : accès par tokens, droits fins, isolation des conteneurs.

Le middleware surveille les blobs grâce à un système de polling intelligent, combiné à des tâches planifiées. Dès qu’un fichier arrive, il est récupéré, analysé, enregistré dans la base d’historisation puis traité selon son type.

Un mécanisme d’ingestion robuste et traçable

L’ingestion est conçue comme un pipeline contrôlé, avec des étapes clairement séparées :

• Détection : le middleware identifie un nouveau fichier grâce à ses métadonnées Azure.
• Téléchargement : le fichier est rapatrié dans un espace temporaire sécurisé.
• Historisation : un enregistrement est créé en base (nom, taille, type, statut “nouveau”).
• Pré-validation : contrôle basique (encodage, taille, structure RFE générale).
• Taggage automatique : le fichier est affecté au bon flux métier.

Grâce à cette pipeline, aucun fichier n’est perdu, doublonné ou oublié : le middleware peut suivre en temps réel ce qui a été récupéré, ce qui est en attente de traitement, et ce qui a été rejeté ou traité avec succès.

Une séparation stricte entre ingestion et traitement

L’ingestion se limite volontairement à la collecte et à l’identification des fichiers. Le traitement (parsing, validation, transformation) est confié à un autre module du middleware, exécuté via commandes Symfony dédiées. Ce découpage permet :

• une meilleure scalabilité (chargement possible en parallèle) ;
• une reprise automatique après interruption ;
• une traçabilité claire pour les équipes Fauré Le Page ;
• une isolation des erreurs (ingestion OK ≠ parsing OK).

La pierre angulaire de toute l’intégration

En centralisant tous les flux dans Cegid Y2 et en les rendant exploitables via Azure Blob Storage, Fauré Le Page dispose d’une architecture stable, lisible et évolutive. L’ingestion des RFE constitue la première étape essentielle du voyage de la donnée, voyage qui se poursuivra dans le parsing, la validation et la transformation, avant d’être envoyé intelligemment vers ShippingBo.

4. Le cœur du système : parsing, validation métier et transformation des flux

Un moteur interne conçu pour comprendre la logique Cegid

Le cœur du middleware repose sur un moteur de parsing avancé, spécialement conçu pour décoder la structure complexe des fichiers RFE produits par Cegid Y2. Chaque fichier est lu ligne par ligne, et chaque ligne est interprétée selon son rôle exact (entête, détail, pied, segment particulier). Le but : reconstituer fidèlement les objets métier tels qu’ils existent dans l’ERP, sans perdre la sémantique métier indispensable à une synchronisation fiable avec ShippingBo.

Le parsing ne se contente pas d'extraire du texte : il transforme les enregistrements bruts en objets typés (Commande, Transfert, Mouvement de stock, Achat fournisseur…), enrichis avec métadonnées, dates normalisées et informations critiques issues du RFE.

Une couche de validation métier stricte et intelligente

Une fois le parsing effectué, chaque flux passe par une étape déterminante : la validation métier. C’est ici que le middleware applique les règles spécifiques de Fauré Le Page, ainsi que celles imposées par les standards Cegid Y2 et ShippingBo. Cette validation garantit que seules des données cohérentes et utilisables sont transmises en aval.

• Vérification de la cohérence des statuts (ex. : “shipped”, “received”, “emitted”).
• Contrôle strict de la correspondance SKU avec le référentiel ShippingBo.
• Validation de la structure des lignes : quantités, montants, codes magasins.
• Contrôles spécifiques FLP : boutiques, entrepôts, types de transferts.
• Gestion des cas particuliers : commandes partielles, transferts multi-lignes, statuts qualité.
• Détection automatique des anomalies (valeurs manquantes, fichiers tronqués, formats incorrects).

Chaque erreur est loguée, historisée et visible dans l’interface de supervision afin que les équipes puissent analyser rapidement un flux rejeté et le rejouer en un clic après correction.

Une transformation maîtrisée : du monde ERP au monde logistique

Une fois validés, les objets métier sont convertis dans un format exploitable par ShippingBo. Là encore, ce n’est pas un simple mapping technique : c’est une véritable traduction fonctionnelle entre deux univers qui n’ont ni les mêmes codes, ni les mêmes logiques.

• Conversion des fichiers RFE en JSON structurés.
• Mapping détaillé entre champs Cegid et endpoints ShippingBo.
• Normalisation des dates, codes pays, montants et identifiants internes.
• Transformation des mouvements en entités ShippingBo (order, transfer, stockMovement…).
• Gestion des cas métier complexes (multi-dépôts, boutiques internationales, stocks qualité).
• Ajout de métadonnées critiques pour faciliter le retour d’information.

Une logique modulaire : un flux = un module indépendant

Chaque flux bénéficie d’un module dédié dans le middleware, permettant une évolutivité maximale :

• Commandes : transformation des ordres clients.
• Transferts : gestion inter-entrepôts et boutiques.
• Achats : suivi des bons d’achat fournisseurs.
• Stocks : synchronisation des quantités et statuts qualité.
• Réceptions : boucle de retour logistique ShippingBo → Cegid.

Cette modularité rend le middleware robuste et pérenne : l’ajout d’un nouveau flux ou la modification d’un format ne perturbe jamais les autres chaînes de traitement.

Traçabilité totale : rien n’est implicite, tout est journalisé

Chaque étape — parsing, validation, transformation — est consignée dans une base d’historisation. Cette transparence permet aux équipes Fauré Le Page de suivre, comprendre et rejouer n’importe quel flux, avec un niveau de détail rarement atteint dans les projets ERP.

Ce cœur du système est la pierre angulaire du middleware Dawap : sans lui, impossible d’assurer une communication fiable entre un ERP traditionnel et un OMS moderne. La section suivante détaillera justement la publication API et la gestion des retours côté ShippingBo.

5. Intégration ShippingBo : publication API, statuts logistiques et boucle d’information

Une intégration API pensée pour la fiabilité avant la vitesse

Une fois les flux Cegid analysés, validés et transformés, ils doivent être injectés dans ShippingBo, l’OMS qui orchestre l’ensemble des opérations logistiques de Fauré Le Page. Dawap a construit une couche d’intégration API REST robuste et sécurisée, capable de traiter des dizaines de flux différents tout en garantissant un niveau maximum de fiabilité.

Chaque flux métier (commande B2B, transfert, mouvement de stock, achat, réception…) correspond à un endpoint ShippingBo spécifique, avec sa propre structure, ses champs obligatoires et sa logique de statut. Le middleware agit comme traducteur permanent entre la logique ERP de Cegid et l’API orientée JSON de ShippingBo.

Un Command Bus interne pour orchestrer les envois vers ShippingBo

L’envoi des données vers ShippingBo est orchestré par un Command Bus Symfony. Chaque flux dispose de sa commande dédiée, par exemple :

• SyncOrdersFromERPToShippingBoCommand : injection des commandes ERP.
• SyncTransfersToShippingBoCommand : envoi des transferts inter-entrepôts et boutiques.
• SyncPurchaseOrdersToShippingBoCommand : publication des bons d’achat fournisseurs.
• SyncStockMovementsToShippingBoCommand : mise à jour des niveaux de stock et statuts qualité.

Chaque commande suit un cycle précis : sélection des flux prêts à l’envoi → construction du payload JSON → appel API → interprétation de la réponse → mise à jour du statut en base. Ce fonctionnement modulaire permet d'augmenter indépendamment la fréquence ou les priorités de chaque flux selon les besoins métier.

Gestion des erreurs API et système de rejouabilité

La logistique ne tolère pas les approximations. C’est pourquoi l’intégration avec ShippingBo inclut un système d’erreurs contrôlé, capable de détecter, consigner et corriger automatiquement les anomalies API.

• Analyse du code HTTP et du message d’erreur.
• Stockage du payload envoyé ainsi que de la réponse complète de ShippingBo.
• Historisation du flux en statut “erreur” ou “à rejouer”.
• Relance manuelle possible depuis l’interface de supervision.
• Rejouabilité automatique via tâche planifiée pour les erreurs temporaires.

Aucun flux n’est perdu : même un échec API est conservé, traçable et relançable avec un niveau extrême de transparence.

Interopérabilité complète : transferts, commandes, achats, stocks

Une fois publiées dans ShippingBo, les données entrent dans le cycle logistique opéré par le prestataire : préparation, expédition, réception, mouvements d’inventaire, contrôles qualité. Le middleware s’assure que chaque flux Cegid est correctement traduit en pan logistique ShippingBo, notamment pour les flux les plus sensibles :

• Commandes B2B : injection structurée, préparation logistique, suivi d’expédition.
• Transferts : mouvements inter-boutiques, boutiques ↔ entrepôts, entrepôts ↔ DHL.
• Achats fournisseurs : envoi des bons d'achat pour préparer les réceptions.
• Stocks qualité : distinction entre “libre”, “bloqué”, “qualité”, “réceptionné”.

Grâce à cette normalisation poussée, ShippingBo peut exploiter les données issues de l’ERP avec une précision identique à celle utilisée par les équipes internes de Fauré Le Page.

Boucle d’information : retour des statuts ShippingBo vers Cegid Y2

L’intégration ne s’arrête pas à l’envoi vers ShippingBo. Le middleware gère également la remontée des statuts logistiques, afin que Cegid Y2 soit continuellement synchronisé avec le terrain :

• Statuts de réception : quantités reçues, dates, anomalies.
• Transferts réalisés : confirmation des envois et des réceptions.
• Mouvements de stock : ajustements validés par ShippingBo.
• Statuts opérationnels : shipped, received, cancelled…

Ces informations sont reformatées en RFE ou CSV selon les attentes de Cegid, puis redéposées sur Azure pour être réintégrées nativement dans l’ERP. Le résultat : une boucle fermée, continue et cohérente entre ERP ↔ middleware ↔ OMS.

Une fondation solide pour la suite : supervision et extension ASN

L’intégration ShippingBo constitue le pivot de tout le système : elle assure que la donnée circule du métier à la logistique, puis de la logistique au métier, sans perte et sans ambiguïté. C’est cette stabilité qui a permis d’ajouter ensuite des fonctionnalités plus complexes comme le module fournisseur et la gestion des ASN, détaillés dans les prochaines sections.

6. Cartographie complète des flux : commandes, transferts, achats, stocks et réceptions

Une vision unifiée des échanges ERP ↔ OMS ↔ Logistique

Le middleware développé pour Fauré Le Page a été conçu pour orchestrer l’ensemble des échanges entre Cegid Y2, ShippingBo et le prestataire logistique. Chaque flux répond à un objectif métier clair et suit un pipeline complet : ingestion → parsing → validation → transformation → publication → retour d’information. Cette cartographie garantit une cohérence totale des données à chaque étape de la supply chain.

1. Commandes B2B : du bon de commande à l’expédition

Les commandes clients B2B sont générées dans Cegid Y2 puis transmises au middleware sous forme de fichiers RFE. Le système les convertit ensuite en payloads JSON ShippingBo afin de déclencher :

• la préparation logistique par le prestataire ;
• la génération des colis et documents de transport ;
• le suivi d’expédition ;
• la remontée des statuts d’envoi et de livraison.

Chaque commande suit une boucle complète : ERP → middleware → ShippingBo → logistique → retour ERP.

2. Transferts : mouvements entre boutiques, entrepôts et logistique

Les transferts occupent une place centrale dans les opérations de Fauré Le Page : mouvements inter-entrepôts, rotations boutiques, ouvertures de magasin, réapprovisionnements stratégiques. Cegid Y2 génère des flux RFE dédiés, que le middleware analyse pour les transmettre à ShippingBo sous forme de transfers.

• Transferts boutiques ↔ entrepôts.
• Transferts boutiques ↔ boutiques.
• Mouvements vers les prestataires logistiques.
• Transferts nécessitant des validations intermédiaires.

Le flux miroir (ShippingBo → Cegid) assure que l’ERP est continuellement synchronisé avec la réalité du terrain.

3. Achats fournisseurs : orchestrer les bons d’achat et les réceptions attendues

Les bons d'achat fournisseurs générés dans Cegid Y2 doivent être connus de ShippingBo afin de préparer les futures réceptions. Le middleware extrait les données d'achat, vérifie les SKU, quantités, codes fournisseurs, puis génère le bon d’achat ShippingBo correspondant.

Cette étape est essentielle : elle permet au prestataire logistique de connaître en amont les articles attendus, facilitant ainsi le contrôle qualitatif et quantitatif à la réception.

4. Stocks & statuts qualité : synchroniser l’état réel des produits

Les mouvements de stock — libres, bloqués, en contrôle qualité — sont pilotés dans Cegid Y2, mais exécutés côté logistique via ShippingBo. Le middleware garantit que les états se reflètent dans les deux systèmes grâce à des flux RFE dédiés et des endpoints ShippingBo spécialisés.

• Mouvements d’inventaire (augmentation, réduction, réajustement).
• Changement de statut : libre → qualité, qualité → libre, bloqué → libre…
• Synchronisation des quantités multi-entrepôts.
• Remontée des statuts d’anomalie ou de contrôle.

Cette synchronisation offre une vision unique du stock aux équipes internes, quelles que soient les opérations menées côté logistique.

5. Réceptions logistiques : fermer la boucle avec fiabilité

Lorsque les marchandises arrivent dans l’entrepôt du prestataire logistique, ShippingBo transmet au middleware les réceptions validées. Ces données sont transformées en fichiers conformes à Cegid Y2 puis redéposées sur Azure, afin que l’ERP puisse mettre à jour ses inventaires officiels.

• Quantités réceptionnées par ligne.
• Différences entre quantités attendues et reçues.
• Anomalies détectées (manquants, erreurs, articles non prévus).
• Rapprochement avec les bons d’achat ou transferts.

Avec ce flux retour, Cegid Y2 reste toujours aligné avec les opérations réelles, garantissant une comptabilité et un suivi de stock impeccables.

Une cartographie évolutive et prête pour de nouveaux flux

Cette cartographie complète des flux a permis de bâtir une chaîne d'information totalement unifiée entre ERP, OMS et logistique. Elle constitue également un socle évolutif : de nouveaux flux (retours clients, inventaires automatisés, échanges boutiques) pourront s’y greffer sans impact sur les flux existants.

7. Command Bus et planification : un moteur d’exécution robuste et rejouable

Un moteur d’orchestration conçu pour absorber la complexité

Au cœur du middleware développé pour Fauré Le Page se trouve un moteur d'exécution basé sur un Command Bus Symfony. Cette architecture permet de piloter chaque flux (commandes, transferts, achats, stocks, réceptions) comme une commande indépendante, orchestrée et totalement maîtrisée. Plutôt qu’un traitement monolithique, Dawap a opté pour une approche modulaire dans laquelle chaque flux est une brique isolée, simple à surveiller, à rejouer et à faire évoluer.

Cette modularité permet d’affronter les contraintes naturelles des environnements ERP/logistique : variations de volume, traitements qui durent plus longtemps, dépendances métiers, flux prioritaires… C’est le Command Bus qui absorbe cette complexité et garantit une exécution stable et prévisible.

Un flux = une commande dédiée et isolée

Chaque flux métier est encapsulé dans une commande Symfony dédiée. Par exemple :

• SyncOrdersFromERPToShippingBoCommand
• SyncTransfersToShippingBoCommand
• SyncPurchaseOrdersToShippingBoCommand
• UpdateStockFromShippingBoCommand
• LoadEmittedTransfertsToERPFromShippingBO_TR3_Command (retour logistique → ERP)

Cette granularité offre plusieurs avantages majeurs :

• Isolation des erreurs : une erreur sur un flux n’impacte jamais les autres.
• Monitoring précis : chaque commande laisse une trace exploitable dans le back-office.
• Facilité d’évolution : ajouter un flux = ajouter une nouvelle commande.
• Testabilité : chaque flux est testable individuellement, en automated ou manuel.

Un scheduler interne pour exécuter les flux au bon moment

Le Command Bus est associé à un scheduler interne, chargé d’exécuter les commandes à intervalle régulier (toutes les minutes, toutes les 5 minutes, toutes les heures selon le flux). Ce système permet d’ajuster finement la cadence en fonction des besoins métier :

• Exécuter les flux critiques (commandes B2B) très fréquemment.
• Planifier les flux lourds (stocks, achats fournisseurs) à intervalles plus espacés.
• Déclencher certains flux manuellement depuis le back-office.
• Geler un flux temporairement lors de tests ou maintenance.

Ce scheduler interne a l’avantage d’être totalement intégré au middleware : pas de dépendance externe, pas de cron dispersé, pas de configuration système à gérer côté serveur.

Rejouabilité totale : aucune donnée perdue, jamais

Dans le domaine logistique, les erreurs sont inévitables : latences API, fichiers incomplets, SKU incorrects, typage inattendu, etc. Plutôt que d’essayer de les masquer, Dawap a conçu un système où chaque flux est rejouable à volonté.

Grâce à ce mécanisme :

• aucun flux n’est perdu, même en cas d’erreur API ShippingBo ;
• chaque fichier RFE reste historisé et peut être retraité ;
• les erreurs temporaires peuvent être relancées automatiquement ;
• les erreurs bloquantes peuvent être corrigées via le back-office puis rejouées.

Cette résilience est indispensable dans un système connecté à un ERP traditionnel comme Cegid Y2, où toute perte de flux pourrait avoir des conséquences immédiates sur la comptabilité, les stocks ou les livraisons.

Une supervision native des traitements

Chaque commande exécutée laisse une empreinte dans la base de logs et dans l’interface d’administration du middleware. Les équipes Fauré Le Page peuvent ainsi :

• voir l’historique complet des traitements ;
• inspecter les payloads envoyés à ShippingBo ;
• analyser les réponses API et erreurs éventuelles ;
• relancer un flux en un clic ;
• identifier les flux en attente, en erreur ou en succès.

Ce moteur d’exécution basé sur un Command Bus rejouable est l’une des signatures techniques du middleware Dawap : fiabilité, traçabilité et maîtrise complète. La pierre de fondation idéale pour des flux ERP–logistique qui tournent chaque jour sans interruption.

8. Supervision temps réel : interface de monitoring, logs et rejouabilité

Rendre visible l’invisible : un back-office dédié au pilotage

Dans un projet d’intégration ERP–OMS, la technique ne suffit pas : les équipes doivent pouvoir voir, comprendre et contrôler ce qui se passe. Dawap a donc développé une interface de supervision temps réel, pensée pour les opérationnels comme pour les équipes IT. Elle rend visibles tous les flux circulant entre Cegid Y2, ShippingBo et le prestataire logistique, grâce à des tableaux clairs, des filtres puissants et un système de logs détaillés.

Une vue globale de tous les flux en circulation

L’interface présente une vision consolidée des flux traités par le middleware. Chaque ligne correspond à un traitement unique, avec un accès direct à ses détails. Les équipes peuvent filtrer par :

• type de flux (commandes, transferts, achats, stocks, réceptions) ;
• statut (succès, en attente, en cours, erreur) ;
• date de traitement ou période ;
• source (Cegid → ShippingBo ou ShippingBo → Cegid) ;
• identifiants métier (numéro de commande, transfert, SKU…).

Cette vue macro permet aux équipes Fauré Le Page de surveiller la santé globale des flux en quelques secondes.

Logs complets : chaque flux est traçable de bout en bout

Chaque traitement est accompagné d’un journal détaillé, permettant d’auditer l’intégralité du parcours d’un flux — depuis l'arrivée d’un fichier RFE sur Azure jusqu’à la publication API dans ShippingBo (ou l’inverse). Le middleware enregistre systématiquement :

• l’horodatage complet du traitement ;
• le fichier d’origine (nom, taille, hachage) ;
• le payload JSON envoyé à ShippingBo ;
• la réponse API complète de ShippingBo ;
• les erreurs éventuelles avec détails techniques ;
• la commande Symfony ayant exécuté le flux ;
• l’historique des statuts et transitions (nouveau → en cours → success / error).

Aucun flux n’est un “boîte noire” : il est possible d’expliquer chaque résultat, chaque erreur et chaque traitement.

Un module de rejouabilité puissant et granulaire

Le middleware possède une fonction essentielle dans un environnement ERP/logistique : la rejouabilité fine des flux. Si une erreur survient (format incorrect, SKU manquant, panne API ShippingBo, données incomplètes…), le flux n’est pas perdu. L’interface permet :

• de voir précisément la cause de l’erreur ;
• de corriger la donnée métier dans Cegid ou ShippingBo si nécessaire ;
• de rejouer le flux individuellement ;
• de relancer un groupe de flux similaires (ex. : tous les transferts en erreur) ;
• de laisser le scheduler réessayer automatiquement pour les erreurs temporaires.

Cette rejouabilité supprime le besoin d’interventions techniques complexes à chaque incident : les équipes métier gardent la main et reprennent le contrôle en toute autonomie.

Un tableau de bord vivant pour comprendre l’état du système

Au-delà des listes et logs, Dawap a conçu un dashboard analytique permettant de visualiser instantanément l’état global de la chaine d’intégration. On y retrouve notamment :

• nombre de flux traités aujourd’hui ;
• flux en attente de traitement ;
• flux en erreur (par type) ;
• temps moyen de traitement ;
• graphe d’évolution des erreurs ;
• répartition par type de flux (commandes, transferts, achats…).

Cette vision macro permet à la direction logistique et aux équipes IT d’anticiper les anomalies, d'améliorer les processus et d’évaluer la performance globale du middleware.

Un outil d’exploitation autant qu’un outil technique

L’interface de supervision n’est pas un simple tableau de logs : c’est un véritable outil d’exploitation quotidien. Les équipes Fauré Le Page s’en servent pour piloter la supply chain, identifier les points d’attention, documenter les anomalies et valider que les flux critiques ont bien été traités. Couplée au moteur d’exécution rejouable, elle fait du middleware Dawap une solution fiable, transparente et opérationnelle, parfaitement adaptée à un environnement ERP exigeant.

9. Module Fournisseurs & ASN : un portail dédié pour les partenaires

Donner la main aux fournisseurs : une extension stratégique du middleware

Après la stabilisation des flux ERP ↔ OMS, Fauré Le Page a souhaité franchir une nouvelle étape : impliquer directement ses fournisseurs dans la chaîne logistique. Dawap a donc développé un module ASN (Advanced Shipping Notice) intégré au middleware, permettant aux partenaires externes de déclarer leurs livraisons en autonomie, tout en garantissant une traçabilité totale jusqu’à Cegid Y2 et ShippingBo.

Un portail sécurisé avec authentification fournisseur

Chaque fournisseur accède à un espace dédié grâce à un compte utilisateur spécifique (rôle : ROLE_SUPPLIER). Cet espace a été conçu pour être simple, fluide et orienté vers les opérations quotidiennes. Au sein de ce portail, un fournisseur peut :

• consulter les commandes d’achat en attente de livraison ;
• visualiser le détail des lignes : SKU, quantités attendues, descriptions ;
• remplir les quantités livrées pour chaque ligne ;
• générer un ASN (avis d’expédition) en un clic ;
• suivre l’évolution de chaque livraison dans le temps.

Cette interface permet de fiabiliser les communications entre la marque et ses partenaires, en supprimant les échanges manuels ou non structurés (emails, fichiers Excel, confirmations orales…).

Génération automatique des ASN : standardisation et traçabilité

Une fois les quantités renseignées par le fournisseur, le middleware génère automatiquement un ASN complet, conforme aux exigences du prestataire logistique et de ShippingBo. Le document inclut :

• les identifiants de commande d’achat ;
• les lignes et leurs quantités prévues vs livrées ;
• le fournisseur et l’utilisateur ayant saisi l’ASN ;
• la date et l’heure de déclaration ;
• les éventuelles anomalies détectées lors de la saisie.

Cet ASN est ensuite transmis au middleware, puis injecté dans ShippingBo, permettant aux équipes logistiques d’anticiper la réception et de préparer l’espace de stockage.

Un suivi en temps réel des livraisons fournisseurs

Les fournisseurs disposent d’un tableau de bord clair leur permettant de suivre l'état de leurs livraisons :

• ASN générés ;
• ASN en cours de traitement par la logistique ;
• réceptions validées et quantités réellement stockées ;
• écarts détectés (manquants, surplus, références inconnues).

Cette transparence réduit les incertitudes opérationnelles et fluidifie les échanges entre les fournisseurs et les équipes logistiques.

Une interface administrateur complète pour Fauré Le Page

Côté Fauré Le Page, les équipes internes disposent d’un espace d’administration beaucoup plus complet, leur permettant de piloter l’ensemble du module :

• gestion des fournisseurs et de leurs utilisateurs ;
• visualisation des commandes d’achat en attente et des ASN déclarés ;
• taux de livraison et indicateurs de performance ;
• historique complet grâce à ActivityLog ;
• filtres par fournisseur, date, statut ou commande.

Un modèle de données pensé pour la clarté et l’évolutivité

Ce module s’appuie sur des entités propres au middleware, inspirées du DDD (Domain-Driven Design). Les principales entités incluent :

• Supplier : informations du fournisseur ;
• User (ROLE_SUPPLIER) : comptes liés aux fournisseurs ;
• OrderSupplier : commande d’achat issue de Cegid Y2 ;
• OrderSupplierItem : lignes de commande ;
• ActivityLog : journalisation des actions et événements ;
• ASN : avis d’expédition généré.

Ces structures permettent au module de rester parfaitement aligné avec les flux ERP et logistiques, tout en restant ouvert à de futures évolutions (ajout de packing list, gestion des retours fournisseurs, traçabilité pallet-level…).

Un outil qui commence chez le fournisseur — et finit dans l’ERP

Grâce à ce module ASN, le middleware n’est plus seulement un connecteur technique : il devient un véritable hub collaboratif, reliant Cegid Y2, ShippingBo, la logistique et désormais les fournisseurs eux-mêmes. Cette extension fluidifie la supply chain, améliore la précision des réceptions et offre une visibilité totale sur l'ensemble du cycle d’approvisionnement.

10. Sécurité, qualité et traçabilité : contrôles, tests et reprise après incident

Une intégration critique exige un niveau de fiabilité irréprochable

Dans un environnement où circulent des commandes internationales, des transferts inter-boutiques, des achats fournisseurs et des données logistiques sensibles, la sécurité et la fiabilité ne sont pas optionnelles. Le middleware développé par Dawap intègre un ensemble de mécanismes avancés garantissant que chaque flux ERP ↔ OMS ↔ logistique est contrôlé, audité et parfaitement traçable, tout en offrant des outils de reprise automatique en cas d’incident.

Contrôles métiers stricts : rien ne passe sans être validé

Avant toute transmission vers ShippingBo ou réintégration dans Cegid Y2, chaque flux passe par une série de contrôles métiers destinés à garantir l’intégrité de la donnée. Ces contrôles incluent :

• vérification de la cohérence des SKU ;
• contrôle des quantités, formats numériques et unités ;
• validation des codes boutiques / entrepôts ;
• identification des statuts ERP correspondant aux statuts logistiques ;
• contrôle des données de stock : libre, bloqué, qualité ;
• correspondance des champs obligatoires entre RFE et API REST ShippingBo ;
• vérification des fichiers RFE (structure, colonnes, ordre, format, intégrité).

Un flux ne part jamais s’il ne respecte pas strictement les règles métier définies avec Fauré Le Page.

Tests unitaires et fonctionnels sur les flux critiques

Les flux les plus sensibles — commandes B2B, transferts, réceptions, achats fournisseurs — font l’objet de tests unitaires et fonctionnels systématiques. Ces tests permettent de valider :

• la transformation RFE → JSON ShippingBo ;
• les comportements en cas de données manquantes ;
• la gestion des erreurs API ShippingBo ;
• la rejouabilité des flux ;
• la persistance correcte des logs ;
• la cohérence des statuts métiers.

Cette couverture de tests garantit que les flux fonctionnent comme prévu même sous forte charge ou dans des scénarios inattendus.

Gestion centralisée des erreurs : pas de zones d’ombre

Si une anomalie survient (erreur ERP, API, format ou logique métier), le middleware l’enregistre dans un mécanisme centralisé de gestion d’erreurs. Chaque erreur est :

• horodatée ;
• contextualisée (type de flux, fichier, commande) ;
• documentée avec message détaillé et payload associé ;
• classée : erreur bloquante, temporaire, fonctionnelle ;
• visible depuis l'interface de supervision.

Aucun incident ne passe sous le radar : chaque opération est inspectable et explicable.

Reprise automatique et rejouabilité : une résilience intégrée

Le système a été conçu pour continuer à fonctionner même en cas d’incident externe (API indisponible, fichier corrompu, SKU manquant). Grâce au moteur interne de planification et de rejouabilité, le middleware peut :

• réessayer automatiquement un flux en erreur temporaire ;
• mettre en file d’attente les flux impactés ;
• relancer les traitements échoués manuellement depuis l’interface ;
• reprendre un flux partiellement traité sans dupliquer les données ;
• rejouer un fichier RFE complet ou une seule ligne spécifique.

Cette résilience garantit que la chaîne ERP ↔ OMS ↔ logistique ne se bloque jamais — une exigence vitale pour un réseau international comme Fauré Le Page.

Traçabilité totale : tout est journalisé

Chaque action effectuée par le middleware — ingestion, parsing, transformation, publication API, écriture de fichier, retour logistique — est enregistrée dans une base de logs structurée. Cette historisation permet :

• de retracer une commande depuis sa création dans Cegid jusqu’à sa réception logistique ;
• d’analyser les API calls exacts envoyés à ShippingBo ;
• d’auditer les flux pour répondre à des contraintes internes ou réglementaires ;
• d’accélérer l’analyse en cas d’incident ou de litige fournisseur ;
• d’offrir une transparence totale aux équipes internes.

Séparation des environnements : stabilité et sérénité

Pour garantir la stabilité des opérations quotidiennes, Dawap a mis en place une séparation stricte des environnements :

• DEV — développement et tests internes ;
• PREPROD — validations fonctionnelles avec les équipes FLP ;
• PROD — environnement entièrement isolé, avec monitoring renforcé.

Grâce à cette architecture sécurisée, le middleware assure un fonctionnement silencieux, stable et parfaitement prévisible, indispensable pour un acteur du luxe opérant à l’international.

11. Stack technique : Symfony 7, Docker, Azure, API REST et outils internes

Une architecture moderne, performante et pensée pour l’intégration

Pour connecter Cegid Y2, ShippingBo et la logistique internationale, Dawap a construit un middleware reposant sur une stack technique à la fois robuste, évolutive et orientée intégration. Chaque choix technologique a été guidé par trois priorités : fiabilité, traçabilité et capacité à absorber des flux hétérogènes en volume variable.

Symfony 7 : le cœur applicatif

L’application est bâtie sur Symfony 7, dernière version du framework PHP, offrant :

• un moteur de commandes solide (Command Bus) ;
• un container de services flexible pour organiser le code métier ;
• une architecture modulaire adaptée aux flux multiples ;
• une gestion optimisée des événements, erreurs et logs ;
• des performances élevées pour des traitements planifiés fréquents.

Symfony permet également de structurer les flux dans des services dédiés, garantissant une excellente testabilité et une évolutivité sans refonte.

Docker & Docker Compose : un environnement isolé et reproductible

L’ensemble du middleware est conteneurisé avec Docker, assurant un environnement parfaitement stable et identique sur toutes les machines (dev, préprod, prod). Docker Compose orchestre plusieurs services :

• l’application Symfony ;
• la base de données MySQL ;
• le worker d’exécution des commandes ;
• les containers dédiés aux jobs planifiés ;
• le moteur de logs et supervision.

Cette isolation garantit que chaque flux tourne dans un environnement contrôlé, sans perturbations externes.

Azure Blob Storage : la passerelle entre Cegid Y2 et le middleware

Les fichiers RFE envoyés par Cegid Y2 sont stockés dans un conteneur Azure Blob Storage. Ce service cloud offre :

• un stockage hautement disponible des fichiers ERP ;
• une surveillance continue par le middleware ;
• une intégration sécurisée grâce aux clés SAS ;
• un historique complet pour la rejouabilité des flux.

Ce choix technologique permet de créer un pont fiable entre les traitements batch de Cegid et l’univers API de ShippingBo.

API REST ShippingBo : un dialogue structuré et performant

Le middleware communique avec ShippingBo via son API REST sécurisée par token. Les payloads générés suivent strictement les schémas attendus :

• création de commandes ;
• transmission des transferts ;
• mise à jour des stocks ;
• création des bons d’achat fournisseurs ;
• remontée des statuts de réception.

Le middleware est capable d’interpréter les réponses, de gérer les erreurs et de relancer automatiquement un flux en cas d’indisponibilité temporaire.

Doctrine ORM & MySQL : stockage structuré des logs et traitements

La base de données MySQL, pilotée par Doctrine ORM, stocke :

• les logs de traitements ;
• les payloads API pour audit ;
• l’historisation des retours ShippingBo ;
• les comptes fournisseurs (pour le module ASN) ;
• les ActivityLogs ;
• les configurations internes du middleware.

Chaque action du middleware laisse une trace persistante, essentielle pour la supervision et la rejouabilité des flux.

Outils internes : Command Bus, scheduler, monitoring et fixtures

Dawap a développé plusieurs briques internes pour renforcer la fiabilité de l’ensemble :

• Command Bus pour orchestrer les flux de manière isolée et indépendante ;
• scheduler interne pour exécuter les commandes planifiées ;
• monitoring centralisé pour visualiser les flux traités ;
• moteur de rejouabilité pour relancer les flux en erreur ;
• fixtures automatiques (Faker) pour générer des jeux d’essai ;
• ActivityLog pour tracer toutes les actions utilisateur ;
• module ASN entièrement intégré au système.

L’ensemble forme une stack technique solide, moderne et parfaitement adaptée aux besoins d’un système d’intégration critique, où performance, fiabilité et extensibilité sont essentielles.

12. Méthodologie projet : collaboration agile entre Dawap, FLP et ShippingBo

Aligner des univers différents autour d’un objectif commun

Un projet d’intégration entre Cegid Y2, ShippingBo et un prestataire logistique international nécessite une coordination fine entre toutes les parties. Dawap a mis en place une méthodologie agile, centrée sur la communication, l’itération rapide et la validation fonctionnelle continue. L’objectif : garantir que chaque flux corresponde exactement au besoin métier, tout en sécurisant la stabilité technique du middleware.

Une équipe tripartite organisée et réactive

Le projet a réuni trois pôles aux rôles complémentaires :

• Fauré Le Page (FLP) : expertise métier, validation fonctionnelle, définition des règles business.
• ShippingBo : support API, bonnes pratiques OMS, validation des schémas d’import.
• Dawap : architecture, développement, intégration et supervision du projet.

Cette organisation fluide a permis de réduire les cycles de décision et d'avancer rapidement même sur des sujets techniques complexes ou soumis à forte contrainte métier.

Un rythme structuré : sprints courts et pilotage hebdomadaire

Le projet a été conduit selon un rythme d’agilité pragmatique, adapté aux enjeux ERP/logistique. Chaque sprint durait une semaine et comprenait :

• Sprint planning : définition des flux à intégrer ou améliorer.
• Daily meetings : synchronisation rapide et résolution immédiate des blocages.
• Développement & tests : implémentation des flux, logs, conversions RFE, API calls.
• Déploiement préproduction : démonstration en fin de sprint.
• Sprint review : validation par Fauré Le Page avec données réelles.
• Rétrospective : ajustements techniques et organisationnels.

Ce rythme soutenu mais maîtrisé a permis d’avancer rapidement sur un périmètre large, tout en assurant une compréhension progressive des spécificités métier de Fauré Le Page.

Déploiements fréquents et validations continues

Pour un projet aussi transversal, Dawap a adopté une politique de déploiements fréquents en préproduction : chaque évolution, chaque flux, chaque correction était livrée dès qu’elle atteignait un niveau suffisant de stabilité.

Cela a permis :

• une validation métier accélérée ;
• une détection rapide des écarts ou incompréhensions ;
• une montée en compétence progressive des équipes FLP ;
• une réduction massive des risques au moment de la mise en production.

Documentation et communication : clarté et transparence

Un projet qui touche à un ERP comme Cegid Y2 nécessite une documentation rigoureuse. Dawap a donc centralisé l’ensemble des éléments :

• spécifications des flux RFE ;
• schémas JSON pour ShippingBo ;
• cartographie métier des flux ;
• diagrammes d’architecture ;
• guide de rejouabilité ;
• audit des erreurs types et comportements attendus.

Les échanges entre Dawap, FLP et ShippingBo ont été organisés via Teams, GitLab et des points réguliers, garantissant une communication fluide, transparente et documentée.

Une collaboration exemplaire au service du résultat

Grâce à cette méthodologie agile et structurée, le projet a pu être mené avec une grande réactivité tout en maintenant une exigence élevée de qualité. La relation de confiance entre les équipes — Fauré Le Page pour la vision métier, ShippingBo pour la logique OMS, et Dawap pour l’architecture et l’intégration — a été déterminante. Le résultat : un middleware fiable, robuste et parfaitement aligné avec les besoins d’une supply chain internationale de maison de luxe.

13. Résultats : automatisation, fiabilité et supply chain unifiée

Une chaîne ERP → OMS → logistique enfin fluide et cohérente

Grâce au middleware développé par Dawap, Fauré Le Page dispose désormais d’une infrastructure d’intégration robuste, capable de synchroniser en continu les données entre Cegid Y2, ShippingBo et le prestataire logistique. Là où les équipes faisaient face à des manipulations manuelles, des risques d’erreurs et des ruptures d’information, la chaîne est aujourd’hui automatisée, lisse et parfaitement alignée.

Une automatisation totale des flux stratégiques

Les flux essentiels — commandes B2B, transferts inter-boutiques, achats fournisseurs, mouvements de stock, réceptions — sont désormais entièrement automatisés. Cette automatisation se traduit concrètement par :

• une baisse massive du temps de traitement quotidien ;
• une réduction drastique des erreurs humaines ;
• une meilleure fluidité dans les échanges entre systèmes ;
• une traçabilité parfaite de chaque étape de la supply chain.

Une visibilité totale grâce au monitoring intégré

Le back-office de supervision développé par Dawap transforme le middleware en véritable tour de contrôle de la supply chain. Les équipes Fauré Le Page bénéficient d’une vision immédiate de l’état des flux, des erreurs éventuelles et des traitements réussis. Résultat : une maîtrise opérationnelle forte et une capacité à réagir en quelques minutes plutôt qu’en plusieurs heures.

Une qualité de données fortement améliorée

Les contrôles métiers, la validation des fichiers RFE et les conversions automatiques ont amélioré la qualité de la donnée circulant dans l’ensemble du système. Les stocks sont fiables, les commandes bien structurées, les transferts correctement alignés, et chaque réception logistique remonte proprement dans Cegid Y2.

Cette qualité nouvelle permet aux équipes de prendre des décisions plus sûres, basées sur des données fiables, récentes et cohérentes.

Un socle technique durable et évolutif

L’architecture mise en place repose sur des standards modernes (Symfony 7, Docker, APIs REST, Azure Blob Storage), ce qui en fait un socle pérenne et extensible. Le middleware est déjà prêt à accueillir :

• de nouveaux flux Cegid Y2 ;
• de nouveaux partenaires logistiques ;
• de nouvelles boutiques ou pays ;
• des fonctionnalités avancées autour des retours, inventaires ou ASN étendus.

Le système grandira avec les ambitions de Fauré Le Page, sans refactoring majeur.

Un middleware au service d’une maison d’excellence

En créant une passerelle puissante entre Cegid Y2 et ShippingBo, Dawap a permis à Fauré Le Page de passer d’une chaîne d’information fragmentée à une supply chain internationale maîtrisée, automatisée et traçable. C’est une infrastructure silencieuse, précise et fiable — à l’image de la Maison elle-même. Une base solide sur laquelle pourront se construire les futures évolutions logistiques et digitales du groupe.

14. Une architecture prête pour l’avenir : évolutivité, extensions et nouveaux flux

Un middleware pensé pour durer et accompagner la croissance

Le middleware conçu par Dawap n’est pas une simple interconnexion entre Cegid Y2 et ShippingBo : c’est une véritable plateforme d'intégration, capable d’évoluer au rythme de la Maison Fauré Le Page et de ses ambitions internationales. Grâce à son architecture modulaire, chaque flux, chaque module et chaque partie du système peut évoluer indépendamment, sans impact sur l'existant.

Une architecture modulaire, extensible et indépendante

Le choix d’une structure basée sur Symfony 7, un Command Bus dédié, des services spécialisés et un découpage clair des responsabilités permet d’ajouter facilement de nouveaux flux. Le système est conçu pour accueillir :

• de nouveaux types de fichiers RFE ;
• de nouveaux schémas d’import/export côté ShippingBo ;
• de nouveaux prestataires logistiques ;
• de nouvelles boutiques, régions ou entrepôts ;
• des flux métiers supplémentaires (retours clients, inventaires, échanges boutiques).

Chaque extension peut être intégrée comme un nouveau “bloc” dans la chaîne d’orchestration, sans refonte complète.

Un socle technique adapté à l'internationalisation

Avec son réseau de boutiques internationales et ses flux logistiques multi-pays, Fauré Le Page a besoin d’un système capable de gérer :

• des règles fiscales évolutives selon les régions ;
• des formats de fichiers différents selon les marchés ;
• des prestataires logistiques multiples ;
• des transferts inter-boutiques multilingues ;
• des fréquences de mise à jour variables selon les zones géographiques.

Le middleware a été conçu pour absorber ces contraintes : configurations centralisées, transformations dynamiques, contrôles renforcés… autant d’éléments qui rendent la solution adaptée à l’expansion internationale.

Une base solide pour intégrer de nouveaux partenaires métiers

Grâce au découpage clair des flux et aux abstractions internes, le système est déjà prêt pour intégrer :

• de nouveaux prestataires de transport ;
• des systèmes de gestion retail (POS) ;
• des outils d’analyse ou de BI ;
• des modules d’audit, d’inventaire ou de contrôle qualité ;
• des intégrations e-commerce supplémentaires.

Le middleware devient ainsi un hub central capable de fédérer l’ensemble de l’écosystème digital de la marque.

Un socle conçu pour accueillir des modules métiers avancés

L’extension ASN n’est qu’un premier pas. L’architecture permet déjà de prévoir des modules métiers plus avancés, tels que :

• gestion des retours fournisseurs ;
• workflow d’inventaires automatisés ;
• connexion à un WMS tiers ;
• gestion des kits, bundles ou séries limitées ;
• sécurisation avancée des flux critiques ;
• indicateurs de performance logistique enrichis.

Le middleware devient un terrain fertile pour construire progressivement un système d'information logistique complet et hautement personnalisable.

Un investissement stratégique pour l’avenir

L’architecture développée par Dawap ne résout pas uniquement les besoins actuels : elle pose les fondations d’une supply chain scalable, collaborative et résiliente, capable de soutenir les ambitions futures de la Maison Fauré Le Page. Qu’il s’agisse d’ouvrir de nouveaux marchés, d’intégrer de nouveaux outils ou d’automatiser encore davantage, le middleware est déjà prêt. Un socle technique pensé pour durer — et pour accompagner durablement l’excellence d’une maison tricentenaire.