Accepter une régression fonctionnelle, plutôt que reproduire tous les flux avant la migration.

Repartir de zéro sur les intégrations, accepter de ne pas retrouver toutes les fonctionnalités à la mise en production, puis reconstruire progressivement sur une architecture maîtrisée.

02

Le
contexte

Changer de plateforme sans reproduire la complexité existante.

Tediber engageait une migration de Sylius vers Shopify. Sylius communiquait directement avec le WMS et Odoo. Côté Odoo, une brique supplémentaire avait été mise en place par l’intégrateur.

Les flux étaient devenus complexes et difficiles à maintenir. Rebrancher Shopify sur cette architecture aurait permis de conserver davantage d’existant, mais aussi sa complexité.

La migration devenait l’occasion de repartir de zéro sur les intégrations. Côté Odoo, la brique intermédiaire existante a été supprimée au profit des API pour simplifier la compréhension des échanges.

Entreprise: Tediber — Marque e-commerce en croissance continue.
Système: Sylius · Shopify · RabbitMQ · Odoo · WMS
Contrainte: Migrer vers Shopify en garantissant les enjeux du business.
Durée: 8 mois

03

Le point
de bascule

Tout reconstruire avant la migration aurait reproduit un autre risque.

Repartir de zéro signifiait perdre les flux existants, leur logique métier et leur connectivité. Certaines fonctionnalités pouvaient ne pas être identifiées avant la migration et disparaître temporairement.

Le flux indispensable à la mise en production était la connexion avec le WMS. La connexion fiable avec Odoo pouvait arriver dans un second temps.

La décision a été de ne pas attendre d’avoir reconstruit tout l’existant. Le périmètre nécessaire à la mise en production serait livré en premier. Le reste serait ajouté progressivement.

Tout reconstruire avant de migrer aurait réduit le risque fonctionnel.
Mais cela aurait retardé un système maîtrisé.

04

Les
options

Deux trajectoires.

La continuité des échanges pouvait être reconstruite directement entre les outils ou portée par une couche dédiée.

Contexte: Shopify devait communiquer avec le WMS puis Odoo. La logique métier propre à Tediber nécessitait cependant des informations et des traitements qui ne relevaient pas directement de ces systèmes.
Options envisagées: A Connecter directement Shopify au WMS et à Odoo. Répartir la logique métier et la connaissance nécessaire aux flux entre les systèmes. Évite de créer et d’exploiter un middleware dédié.

B Créer Octopus avec sa propre base de données. Abandonner les flux existants et reconstruire leur logique et leur connectivité. Renonce à conserver l’existant comme base de la migration.
Décision: Option B. Créer Octopus pour porter la logique métier nécessaire aux intégrations, reconstruire d’abord la connexion indispensable avec le WMS, puis compléter progressivement les autres flux.

A	Connecter directement Shopify au WMS et à Odoo.	Répartir la logique métier et la connaissance nécessaire aux flux entre les systèmes.	Évite de créer et d’exploiter un middleware dédié.
B	Créer Octopus avec sa propre base de données.	Abandonner les flux existants et reconstruire leur logique et leur connectivité.	Renonce à conserver l’existant comme base de la migration.

L’intégration directe évitait une couche supplémentaire. Elle obligeait cependant à répartir entre Shopify, le WMS et Odoo une logique métier qui nécessitait sa propre connaissance.

Octopus fournissait cette couche et sa propre base de données. Ce choix impliquait de ne pas reprendre les flux existants et d’accepter qu’une partie des fonctionnalités ne soit reconstruite qu’après la migration.

05

Le
compromis

Ce que cette décision a coûté.

Le prix de la simplification était de ne pas chercher la parité fonctionnelle avant la mise en production.

Perdre l’existant.

Les flux précédents, leur logique métier et leur connectivité n’ont pas servi de socle à la nouvelle architecture.
Accepter une régression fonctionnelle.

Certaines fonctionnalités existantes pouvaient ne pas être identifiées ou reconstruites pour la mise en production.
Reconstruire dans le temps.

Seuls les besoins prioritaires pour la migration ont été traités en premier. Les autres fonctionnalités devaient revenir progressivement.

06

Le
résultat

Ce qui est devenu possible.

Le système a été mis en production en septembre 2025 avec la connexion au WMS nécessaire au fonctionnement de l’e-commerce. Les autres intégrations ont ensuite pu être ajoutées progressivement.

01

Le web reste indépendant des systèmes connectés.

Une indisponibilité d’Octopus ou d’un outil connecté n’empêche pas Shopify de continuer à vendre.
02

Les systèmes peuvent être connectés progressivement.

La connexion au WMS a été priorisée pour la mise en production. Les autres intégrations ont pu être ajoutées dans un second temps.
03

Les responsabilités sont séparées.

La logique métier nécessaire aux intégrations est portée par Octopus plutôt que répartie directement entre Shopify, le WMS et Odoo.
04

Les données de commande destinées à Odoo sont fiabilisées.

Les montants, les lignes de commande, les données de commande et les transactions financières sont transmis avec les informations nécessaires à leur exploitation comptable.
05

L’indisponibilité d’un système connecté est absorbée.

RabbitMQ met de côté les messages lorsqu’un système est indisponible afin qu’ils puissent être rejoués lorsqu’il redevient disponible.

07

La règle que nous en avons tirée.

Avec ce que nous savons aujourd’hui.

Le choix de repartir de zéro et de reconstruire progressivement est maintenu. La dépendance aux API du WMS est le point que nous traiterions différemment.

Ce que nous garderions: Accepter un périmètre fonctionnel réduit à la migration pour construire une architecture stable, maîtrisée et complétée progressivement.
Ce que nous changerions: Réduire davantage la dépendance d’Octopus aux API du WMS. Leur évolution peut aujourd’hui imposer une réécriture importante des intégrations concernées.
Ce que nous en avons tiré: RabbitMQ reste adapté au besoin de résilience. L’indisponibilité temporaire d’un système connecté ne provoque pas la perte du message, qui peut être rejoué lorsqu’il redevient disponible.

08

Prochaine
étape

Une migration ne doit pas nécessairement attendre la parité fonctionnelle.

Toutes les histoires

Parlons de la prochaine décision qui compte