Migrer un catalogue de 40 000 pièces de moto depuis un ancien système FileMaker vers une plateforme e-commerce moderne, ça paraît simple – jusqu’au moment où tu réalises que l’ancien système concentre des décennies de logique métier qu’on ne peut absolument pas se permettre de casser.
C’était là le nœud du problème dans notre collaboration avec BMW Classic : comment moderniser sans perturber une activité hautement spécialisée qui expédie dans le monde entier ? Voici ce qui s’est réellement passé, et ce qu’on en a tiré.
Le vrai problème, ce n’était pas l’ancienne technologie
BMW Classic gère l’une des boutiques en ligne les plus spécialisées du monde de la moto – des pièces d’origine pour tout, des classiques des années 1920 aux modèles actuels, avec des expéditions partout dans le monde. La plateforme en place avait bien fait son travail pendant des années, mais elle avait atteint ses limites :
- Le référencement naturel (SEO) était pratiquement inexistant. Le site était à peine indexé, ce qui signifiait que les clients recherchant des pièces de niche – souvent des requêtes très spécifiques – ne trouvaient tout simplement pas la boutique.
- Les mises à jour de contenu étaient lentes et risquées.
- Le système n’était pas conçu pour soutenir des workflows marketing modernes ni offrir une expérience d’achat fluide.
La complexité cachée : une grande partie de la logique métier vivait dans FileMaker, un système de base de données hérité qui avait accumulé des années de savoir opérationnel – structures de produits, règles de compatibilité, logique de traitement des commandes. Ce n’est pas quelque chose qu’on éteint du jour au lendemain.
Maintenir l’activité tout en la reconstruisant
La décision architecturale la plus importante qu’on a prise dès le début était claire : ne pas remplacer FileMaker en une seule fois. Construire autour, avec soin.
Concrètement, ça impliquait de concevoir une couche de synchronisation (sync layer) dédiée – une intégration structurée qui relie FileMaker à la nouvelle boutique sur mesure, maintient les données produit et catalogue à jour, et protège la boutique des risques liés aux sources de données héritées. Si FileMaker devient temporairement indisponible, la boutique continue de tourner. Cette stabilité n’est possible que grâce à la couche d’abstraction qui les sépare.
Ce que ça nous a appris : la préparation et la compréhension du système existant comptent plus que la technologie vers laquelle on migre. On a passé beaucoup de temps avec les architectes de l’ancienne boutique avant d’écrire la moindre ligne de code de la nouvelle. Cet investissement s’est directement traduit par la qualité de l’intégration.
Deux systèmes, deux responsabilités : pourquoi Payload CMS était le bon choix
Une boutique comme BMW Classic a besoin de deux choses fondamentalement différentes qui fonctionnent en parallèle : une couche commerce structurée pour les données produit, les prix, la compatibilité et les stocks – et une couche de contenu flexible pour les pages d’accueil, les campagnes et le storytelling éditorial.
Essayer de tout regrouper dans un seul système crée des compromis dans les deux sens. On les a donc séparés intentionnellement.
Payload CMS est devenu le cerveau du contenu. Il a permis à l’équipe de BMW Classic de publier et mettre à jour du contenu marketing, de créer des pages de campagne et de gérer le contenu éditorial sans avoir besoin d’un développeur pour chaque modification. Ce genre d’autonomie opérationnelle est essentiel – surtout pour une équipe qui gère un catalogue de cette envergure.
La couche commerce sur mesure s’est chargée du reste : données produit, paiement, tarification et flux de commande. Reliés par la couche de synchronisation, les deux systèmes ont ensemble apporté à BMW Classic quelque chose qu’ils n’avaient pas auparavant – la rapidité sans risque.
Le référencement naturel (SEO) comme exigence produit, pas comme une réflexion après coup
L’une des décisions les plus claires qu’on a prises dès le départ : traiter le SEO comme une exigence fondamentale, et non comme une couche ajoutée après le développement. Pour une boutique qui vend plus de 40 000 pièces détachées, la visibilité organique n’est pas un simple bonus. C’est la différence entre capter la demande de recherche à longue traîne et la rater complètement.
En pratique, ça signifiait :
- Une structure d’URL et de navigation propre et indexable dès le premier jour
- Un chargement rapide des pages grâce à Next.js et à l’infrastructure Digital Ocean
- Une architecture de métadonnées et de contenu évolutive qui grandit avec le catalogue
- Un modèle de navigation conçu autour de la façon dont les clients cherchent réellement – par famille de modèles, puis par catégorie, puis par pièce
L’ancienne plateforme n’avait pratiquement aucune base SEO. Corriger ça de manière structurelle, plutôt que de simplement colmater les brèches, a été l’une des choses les plus pertinentes sur le plan commercial qu’on ait faites dans ce projet.
Ce qu’on referait de la même façon – et ce qu’on surveillerait de plus près
Le design et l’architecture technique ont bien tenu le coup. Construire une boutique autour du véritable parcours de l’acheteur – trouver le bon modèle, naviguer dans les catégories en toute confiance, valider les détails de la pièce, acheter sans friction – c’est la bonne approche pour une boutique de pièces de cette envergure.
Ce qu’on surveillerait de plus près la prochaine fois : une documentation encore plus rigoureuse des structures de données FileMaker avant le début de la migration. Les systèmes hérités contiennent souvent des cas limites qui n’apparaissent que dans des conditions réelles. Plus tu cartographies l’ancien système de manière approfondie dès le départ, moins il y a de surprises lors des tests de synchronisation.
L’autre enseignement clé – et ça s’applique bien au-delà de BMW Classic – c’est qu’une couche de synchronisation n’est pas juste une solution de contournement technique. C’est en réalité une fonctionnalité architecturale à long terme. Les futures migrations, ajouts ou remplacements de n’importe quel composant ne nécessiteront pas de reconstruire toute la plateforme. C’est un vrai avantage à mesure que l’entreprise évolue.
Où en sommes-nous ?
La boutique est en ligne, stable et continue de se développer. On poursuit les améliorations SEO, les optimisations UX et l’enrichissement de la couche de contenu. Un projet comme celui-ci ne s’arrête pas au lancement – il entre dans une phase de croissance, et les fondations doivent être suffisamment solides pour la soutenir.
S’il y a une chose à retenir de ce projet, c’est que le plus difficile dans la migration d’un système existant, ce n’est pas la nouvelle technologie. C’est de respecter et de bien comprendre l’ancienne pour pouvoir construire autour d’elle en toute sécurité.
Tu travailles avec une plateforme riche en contenu ou tu envisages une migration CMS ? Nos services Payload CMS sont conçus précisément pour ce type de projets – données complexes, indépendance éditoriale et aucun risque de « big bang ».
À lire aussi : Découvre comment on a développé un connecteur ERP et fusionné la boutique en ligne de Rokker.
