Étude de cas
Des microservices au monolithe.
Une plateforme LegalTech découpée en de nombreux services NestJS, une équipe d'une douzaine de personnes. Nous la rassemblons dans un monolithe, dans un seul dépôt.
- Rôle
- Décision d'architecture et pilotage de la migration
- Équipe
- Ingénierie, Qualité, Infra
- Outils
- pnpm workspaces, Turborepo, Biome, Storybook, Cypress
- Statut
- En cours
01Le point de départ
La plateforme s'est construite service par service : un service par domaine métier, chacun avec son dépôt, sa configuration et son pipeline. Ce découpage avait du sens au départ. Avec le temps, il a surtout multiplié ce qu'il faut maintenir.
Une évolution métier traverse souvent plusieurs services. Il faut alors coordonner plusieurs dépôts, plusieurs versions et plusieurs déploiements pour une seule fonctionnalité. La configuration, le lint et les dépendances divergent d'un service à l'autre, et chaque mise à jour de sécurité se répète autant de fois qu'il y a de dépôts.
02Le choix
Les microservices règlent des problèmes d'organisation que nous n'avons pas : plusieurs équipes autonomes qui livrent indépendamment, des besoins de montée en charge très différents d'un domaine à l'autre. Pour une seule équipe produit, leur coût dépasse ce qu'ils apportent.
Nous avons choisi un monolithe dans un monorepo pnpm piloté par Turborepo. Un seul dépôt, une seule chaîne de validation, des frontières entre modules vérifiées par l'outillage plutôt que par le réseau.
03Les règles du dépôt
Un monolithe sans règles redevient vite un plat de spaghettis. Nous en avons fixé quelques-unes, écrites dans le dépôt et vérifiées en CI.
Une app n'importe jamais une autre app
Le code partagé entre applications vit dans un package. Un package ne dépend jamais d'une app.
Pas de package spéculatif
On n'extrait un package qu'à l'arrivée d'un second consommateur. Pas d'abstraction « au cas où ».
Une seule chaîne de validation
Format, lint, typage et couverture de tests passent dans chaque workspace avant tout commit, exactement comme en CI.
Des décisions écrites
Chaque choix structurant fait l'objet d'un ADR, et le vocabulaire métier est fixé dans un glossaire partagé.
04Comment on migre
Pas de big bang. Le nouveau dépôt accueille d'abord le front-end client, avec son design system, ses tests et son pipeline. Les autres applications et le back-end le rejoignent ensuite, une par une, pendant que l'existant continue de tourner.
Chaque étape doit laisser la plateforme dans un état livrable. C'est plus lent sur le papier, mais les clients ne voient pas la migration, et l'équipe continue de livrer la roadmap en parallèle.
05Ce que j'en retiens
Le choix d'architecture compte moins que les règles qui l'accompagnent. Un monorepo sans frontières vérifiées ne vaut pas mieux que des microservices mal découpés.
Une partie de mon rôle consiste à rendre ces règles évidentes pour l'équipe : écrites au même endroit que le code, vérifiées automatiquement, expliquées dans les revues plutôt qu'imposées.