Refonte du SI et bascule en big bang

Pourquoi une entreprise de pièces détachées remplace tout son SI d’un coup

Mecatechnic vend en ligne des pièces détachées pour véhicules anciens et youngtimers. Le catalogue dépasse 105 000 références, réparties sur plus de quinze constructeurs, dont environ 55 000 produits en stock. Sur ce marché de niche, la concurrence ne se joue pas sur le prix : elle se joue sur la disponibilité réelle de la pièce et sur le conseil. La profondeur du catalogue est l’avantage commercial. Tout ce qui touche à la donnée produit et au stock touche donc directement au métier.

Deux systèmes portaient cette activité. Un ERP sur AS/400 d’un côté. De l’autre, un site e-commerce Symfony monolithique dans lequel la vitrine, la logique métier et l’administration ne formaient qu’une seule application. Entre les deux, des flux écrits sur mesure en ASP que plus personne dans l’entreprise ne maîtrisait. Le symptôme le plus visible pour un client était l’écart récurrent entre le stock réel et le stock affiché. Sur un catalogue dont l’argument de vente est « la pièce existe et elle est disponible », ce n’est pas un détail d’affichage.

À quoi ressemble l’architecture qui a remplacé le monolithe

La cible retenue est une architecture headless. Sylius, sur Symfony, porte le back-office et le catalogue ; il est alimenté par le PIM Pimcore. La vitrine a été entièrement redéveloppée en Next.js et ne partage plus de code avec l’administration. Côté gestion, l’ERP Flex de Cegid remplace l’AS/400. Les flux passent par le middleware ApiZr, à la place du code sur mesure que personne ne relisait plus.

Aucune de ces briques n’existait au départ. Le SI a été remplacé de bout en bout, ERP compris, sur une durée de dix-huit mois.

Comment le projet a été mené, et avec quel effectif

L’organisation était celle d’un projet produit classique : sprints de deux semaines et cérémonies agiles complètes. Deux prestataires travaillaient sur place, Widop sur Sylius et LCS sur Flex.

Le fait marquant est ailleurs. L’équipe est passée d’une dizaine de personnes à trois au cours du projet. Sur le front, nous étions deux développeurs, puis un seul. À effectif constant, un projet de cette taille se pilote par le périmètre ; à effectif décroissant, il se pilote par l’arbitrage permanent entre ce qui doit être en place le jour de la bascule et ce qui peut attendre après.

Ce que j’ai fait, et ce qui a été fait collectivement

Le projet était collectif, et l’essentiel de ce qui précède est le travail d’une équipe et de ses prestataires. Ma contribution porte sur deux choses.

La première est la vitrine Next.js, développée puis maintenue de bout en bout : tunnel de commande, module de devis, pages promotionnelles, espace client, mise en cache, optimisation de l’usage des ressources et du shell HTML de Next.js, et tests end-to-end contre les régressions. La seconde est un ensemble de choix d’architecture sur ce périmètre. Trois d’entre eux ont donné lieu à des études de cas distinctes : la suppression de Strapi au profit de Sylius CMS, la saturation mémoire après la mise en production et le remplacement des Server Actions par un BFF.

Depuis, sur le service informatique, j’ai travaillé sur l’infrastructure AWS de la nouvelle plateforme et sur les pipelines GitLab CI, avec des images stateless pour fiabiliser les déploiements.

Pourquoi la date de bascule était le point faible du plan

La bascule a été faite en big bang, le 19 mai 2026 : ancien SI arrêté, nouveau SI démarré, sans période de double fonctionnement. Elle s’est donc placée juste en amont de la haute saison estivale.

Les deux semaines qui ont suivi ont été des semaines de production dégradée ou surdimensionnée, sous surveillance permanente. Le constat a été identifié et documenté après coup : une bascule de cette ampleur ne se place pas juste avant le pic d’activité. La marge nécessaire pour absorber un incident est précisément ce qui manque à ce moment de l’année.

C’est l’enseignement le plus transposable du projet. La date de bascule ne se choisit pas sur la date à laquelle le produit est prêt, mais sur la période où l’entreprise peut encaisser deux semaines difficiles.

Ce qui fonctionne aujourd’hui et ce qui reste ouvert

Le nouveau SI est en production et l’architecture headless est en place. La stabilisation post-bascule a été traitée, et la facture cloud a été divisée par trois après stabilisation.

Le chantier n’est pas terminé pour autant, et le dire est plus utile que de conclure sur un bilan net.

• Le SEO reste le point faible du projet. Une alerte avait été remontée à plusieurs reprises et deux audits indépendants l’ont ensuite confirmée.
• Le GEO est en cours de déploiement, mis en place sur les taxons et sur les articles de blog. Sa généralisation au catalogue produit est un travail long.
• La production tourne toujours sur une version canary de Next.js, dette assumée et documentée dans l’étude de cas correspondante.
• La modernisation de l’infrastructure, sur AWS, est en cours.

Ce que je retiens d’une refonte de SI de cette ampleur : le travail difficile n’est pas de construire la cible, il est de choisir ce qu’on n’emporte pas, et de choisir quand on bascule.