Supprimer Strapi au profit de Sylius CMS
Un POC comparatif Strapi, WordPress et Payload conclut que le problème n’est pas l’outil mais le fait d’avoir un CMS séparé de la plateforme e-commerce.
Avant la mise en production
Pourquoi un CMS séparé avait été retenu au démarrage
Au démarrage de la refonte, l’équipe a retenu Strapi pour la gestion de contenu. La raison était de calendrier : un CMS prêt à l’emploi permettait d’avancer vite sans développer de fonctionnalités d’édition dans la plateforme e-commerce.
Quels problèmes Strapi posait sur ce projet
Trois catégories de problèmes sont apparues à l’usage.
Des pertes d’images, sans cause identifiée. Sur un site marchand où le visuel est un argument de vente, une image qui disparaît est un défaut visible par le client.
De la rigidité dès qu’il fallait du spécifique métier. Le gain de départ s’inversait à chaque besoin qui sortait du modèle prévu par l’outil.
Et surtout, le rattachement des contenus aux produits. Dans Strapi, il fallait saisir les références à la main. Sur un catalogue de plus de 105 000 références, c’est ingérable, et ce n’est pas un défaut de l’outil : Strapi n’a aucune raison de connaître le catalogue. Sylius, lui, connaît nativement les produits et les taxons.
À cela s’ajoutaient la tenue en charge, et le coût permanent de maintenir deux back-offices et d’interroger deux sources de données.
Ce que le POC comparatif a réellement montré
La question de départ était « quel CMS mettre à la place de Strapi ». Nous avons monté un POC comparatif entre Strapi, WordPress et Payload pour y répondre.
La conclusion a invalidé la question. Le problème n’était pas Strapi. Il venait du fait d’avoir un CMS séparé de la plateforme e-commerce : aucun outil externe ne peut connaître nativement le catalogue, donc aucun des trois candidats ne réglait le point qui coûtait le plus cher. Changer de CMS revenait à déplacer le problème.
La décision et sa mise en œuvre
J’ai porté la décision de supprimer Strapi, de tout ramener dans Sylius CMS, et d’assumer le développement spécifique que le choix initial avait justement cherché à éviter.
Le calendrier a facilité la migration : il y avait peu de contenu avant la mise en production. Le travail réel n’a donc pas porté sur la reprise de données, mais sur deux chantiers : le rebranchement du front sur la nouvelle source de contenu, et le développement des fonctionnalités de gestion de contenu dans le back-office Sylius.
Ce que ce changement a rendu possible
Rattacher une promotion à une page est devenu immédiat, puisque le CMS et le catalogue partagent le même modèle de données. Les pages statiques ont pu être créées rapidement pendant les perturbations qui ont suivi la bascule, à un moment où la vitesse de publication comptait. Et il ne reste qu’un seul outil à maintenir et à héberger, au lieu de deux back-offices et de deux sources à interroger.
Ce que je retiens de cette comparaison d’outils
Un POC comparatif sert autant à valider un choix qu’à découvrir que la question était mal posée. Ici, les trois candidats évalués avaient tous la même limite structurelle, et c’est cette limite commune, et non le classement entre eux, qui portait la réponse. Le second enseignement est plus inconfortable : un raccourci pris pour aller vite au démarrage se paie généralement au moment où le volume de données réel arrive. Sur un catalogue de plus de 105 000 références, aucune saisie manuelle ne tient.