Plateforme web multi-marques — groupe hôtelier européen
En production depuis 20198 marques, une seule codebase Next.js + GraphQL. Mission Tech Lead React / Next.js depuis 2019.
- Next.js (custom server)
- TypeScript
- React 18
- Apollo Client
- GraphQL
- Styled Components
- Express 4
- Jest + Enzyme
- Cypress 14
- Azure DevOps
Plateforme white-label du site marchand d'un grand groupe hôtelier européen : une seule base Next.js qui build 8 apps en parallèle, une par marque, avec sa config, son thème Styled Components et son port dédié. Architecture custom server Express + middlewares applicatifs, Apollo Client SSR, GraphQL backend orchestrant Drupal (CMS) + SynXis (booking) + Adyen (paiement 3DS1/3DS2) + Mapbox + TripAdvisor. Atomic design strict (57 atoms + 118 molecules + 96 organisms), tests Jest + Cypress, déploiement Azure DevOps avec cycle de release hebdo. C'est sur cette plateforme que vit aussi le POC chatbot IA décrit dans le projet voisin.
Le problème
Gérer 8 marques différentes — chacune avec sa charte graphique, son catalogue d'hôtels, sa langue principale, son tunnel SEO et ses spécificités produit — sans dupliquer 8 fois la codebase. Le piège classique : finir avec 8 forks divergents qui se réparent au bug-par-bug et où plus personne ne sait quel correctif s'applique à quelle marque.
À l'opposé, le piège du monolithe : un site générique qui ne sent appartenir à aucune marque, où chaque token couleur devient une condition métier, et où ajouter une marque coûte un sprint entier.
La solution
Architecture white-label : une codebase Next.js unique avec un système de configuration multi-brand. Chaque marque a son dossier `config/<brand>/` (variables d'env, feature flags, redirects), son dossier `themes/<brand>/` (tokens C1…C26, polices, icônes font, injectés via ThemeProvider Styled Components), et son port local dédié en dev. Le build orchestre 8 builds Next.js en parallèle avec `NODE_OPTIONS=--max_old_space_size=4096`.
Côté runtime, un custom server Express monte une chaîne de middlewares applicatifs avant de déléguer à `next()` : résolution de locale (cookie → URL → Accept-Language) + fetch GraphQL des traductions, Apollo SSR + XSRF, CMS Drupal via API, Azure File Share pour sitemap/robots/flux SEO, mapping route → page Next, Azure App Insights + OpenTelemetry pour le tracing.
Ce qui tourne en prod
- 8 marques + 16 sous-brands, une codebase unique
- Paiement Adyen 3DS1/3DS2 + Drop-in, retour banque sécurisé
- Multi-locale runtime (cookie → URL → Accept-Language)
- Apollo Client SSR + XSRF + codegen near-operation-file
- Atomic design strict — 57 atoms / 118 molecules / 96 organisms
- Pages HIM (microsite par hôtel) + StayConfigurator (critical path booking)
- PWA (@ducanh2912/next-pwa) + service worker, Mapbox interactif
- Tests Jest 29 + Enzyme + Cypress 14, gates CI Azure DevOps
- Cycle release hebdo : tag merge → Recette mardi → Prod jeudi
- Logs Winston + Loggly + App Insights + OpenTelemetry distribué
Process IA dans le delivery quotidien
Depuis 2024, l'équipe utilise Claude Code en mode binôme sur le quotidien : compréhension de code legacy, scaffolding de composants atomic design (les 5 fichiers conventionnels : .tsx + .styled.ts + .types.ts + .test.tsx + index.ts), code review IA en pré-commit, génération des tests Enzyme `shallow`, rédaction des commits conventionnels en français. CLAUDE.md tenu à jour pour cadrer le contexte (conventions de release hebdo, critical paths fragiles : StayConfigurator, Booking 3DS, Auth, server.ts).
Pour les changements structurants (3DS, refonte d'un parcours, ajout d'une brand) on applique le workflow Superpowers : writing-plans avant executing-plans, revue humaine du plan, exécution task-par-task. Le POC chatbot décrit dans le projet voisin a été livré avec exactement cette méthode.
- Claude Code (Anthropic)
- Superpowers (Jesse Vincent)
- Conventional Commits FR