Migration Monolithe → Microservices — Domain-Driven Design et Architecture Distribuée

#Quand décomposer un monolithe — Et quand ne pas le faire

La question n'est jamais « faut-il passer aux microservices ? » mais « à quel point mon monolithe est-il un frein réel à la croissance de mon produit et à l'autonomie de mes équipes ? ». Les cinq signaux qui justifient objectivement une décomposition.

Couplage déploiement coûteux. Quand un hotfix sur le module paiement nécessite de redéployer toute l'application en production avec une fenêtre de maintenance, on accumule du risque à chaque release. Les équipes engineering finissent par déployer deux fois par mois au lieu de quatre fois par jour — pas par manque de compétences, mais parce que le coût opérationnel d'un déploiement monolithique décourage les releases fréquentes. C'est le signal le plus mesurable et le plus universel.

Bottleneck scalabilité sur des modules spécifiques. Un module de traitement d'image, un moteur de recherche full-text, un pipeline de calcul de facturation en fin de mois — ces composants ont des profils de charge très différents du reste de l'application. Dans un monolithe, scaler l'un revient à scaler tout le système, avec un coût infrastructure multiplié par 8 à 15 par rapport à une architecture où seul le module sous tension est scalé. Cas concret vu chez nos clients : module de génération de rapports PDF consommant 80 % des ressources CPU en fin de mois, rendant l'application lente pour tous les utilisateurs d'une ETI SaaS B2B 8 équipes.

Bottleneck d'autonomie des équipes. Au-delà de 5 équipes produit sur une même base de code, les conflits de merge, les blocages sur les pipelines CI/CD partagés et la coordination inter-équipe sur les releases deviennent le facteur limitant de la velocity. Conway's Law (Melvin Conway, 1968) est ici impitoyable : vos systèmes logiciels ressemblent à vos structures de communication. Une ETI avec 8 équipes produit autonomes ne peut pas opérer un monolithe partagé sans friction organisationnelle permanente.

Besoin de stacks technologiques différenciées par module. Un module de machine learning a besoin de Python et de GPU. Le reste de l'application est en Java ou PHP. Une extraction en microservice indépendant résout ce mismatch sans réécrire le tout.

Isolation réglementaire (PCI-DSS, HDS, RGPD). Réduire le scope PCI-DSS d'une application de commerce complexe ou isoler des données de santé au travail dans un microservice HDS est souvent impossible dans un monolithe où tout le code a accès à toutes les données. L'extraction du bounded context Facturation/Paiement en microservice dédié peut réduire le scope PCI-DSS de 60 à 70 % — avec des implications budgétaires directes sur les audits QSA.

Quand ne pas décomposer. L'équipe est inférieure à 15-20 ingénieurs : les coûts opérationnels des microservices (observabilité distribuée, service mesh, CI/CD par service, gestion des versions d'API) excèdent largement les bénéfices. Le produit est encore en phase de discovery : une frontière de service mal tracée dans un produit instable coûte cher à retracer — attendez que votre modèle de données soit stable. Le monolithe n'est pas réellement le bottleneck : parfois c'est la base de données, le réseau ou l'organisation qui plafonne la velocity, pas l'architecture applicative elle-même. Diagnostiquer avant de décomposer. Cf. glossaire dette technique pour qualifier objectivement la situation.

#Domain-Driven Design — Identifier les bons bounded contexts

Le Domain-Driven Design d'Eric Evans (2003, ouvrage de référence domainlanguage.com) est la fondation intellectuelle sans laquelle toute migration microservices produit un micro-monolithe : des dizaines de petits services aussi couplés que le monolithe d'origine, mais infiniment plus difficiles à opérer.

Le concept central est le bounded context : une frontière linguistique et métier autour d'un domaine cohérent où un modèle de données a un sens univoque. Dans un e-commerce B2B, le mot « produit » n'a pas le même sens dans le contexte Catalogue (référence, fiche technique, attributs), dans le contexte Commandes (ligne de commande, prix négocié, quantité) et dans le contexte Logistique (article entrepôt, emplacement, poids). Ces trois contextes sont des bounded contexts naturels, avec leurs propres modèles de données, leurs propres équipes et leurs propres services.

L'atelier Event Storming (méthode d'Alberto Brandolini, référence dans la communauté DDD) est l'outil pratique que Nehos utilise pour extraire ces bounded contexts du cerveau des experts métier. Format type : 2 jours de travail intensif avec 8 à 15 participants (experts métier, développeurs seniors, product managers, architects), animé sur un tableau blanc de 10 mètres de papier kraft. Déroulé en 4 phases : (1) cartographier les domain events (tout ce qui se passe dans le système au passé composé : « Commande passée », « Paiement validé », « Stock décrémenté », « Facture émise »), (2) identifier les commands qui déclenchent ces events (actions utilisateur ou système), (3) grouper autour des aggregates (entités racines qui garantissent la cohérence), (4) tracer les bounded contexts en identifiant les ruptures de langage métier entre groupes d'events. Output typique sur une ETI SaaS B2B de taille moyenne : 6 à 12 bounded contexts clairement délimités avec leur carte de contexte (context map) — Identité/Auth, Facturation, Catalogue Produits, Commandes, Expédition, Notifications, Analytics, Reporting, Admin, Recherche, Intégrations Tierces.

Les relations entre bounded contexts doivent être modélisées explicitement (context map DDD) : partnership (deux équipes coordonnent étroitement), customer-supplier (upstream/downstream avec SLA d'API défini), conformist (downstream subit le modèle upstream), Anti-Corruption Layer (ACL — couche de traduction pour isoler un bounded context d'un système legacy mal conçu ou tiers), Open Host Service (API publiée standardisée). La context map est l'artefact architectural central de toute migration microservices réussie.

L'anti-pattern micro-monolithe mérite une vigilance constante. Il survient quand la décomposition est guidée par la technique (un service par table de base de données, ou un service par endpoint REST) plutôt que par le domaine métier. Résultat : 40 microservices qui se couplent via des appels synchrones en cascade, des transactions distribuées impossibles à déboguer, et une complexité opérationnelle sans bénéfice de scalabilité ni d'autonomie d'équipe. La règle empirique Nehos : pas moins de 5 et rarement plus de 15 microservices pour une ETI SaaS B2B standard — la bonne granularité découle du DDD, pas d'une cible chiffrée.

#Pattern Strangler Fig — Migration progressive

Le Strangler Fig pattern (Martin Fowler, article fondateur 2004) tire son nom du figuier étrangleur tropical qui pousse progressivement autour d'un arbre hôte jusqu'à le remplacer complètement — sans jamais interrompre la croissance de l'arbre original pendant la transition. C'est l'approche exacte pour migrer un monolithe sans downtime et sans la version « big bang rewrite » qui tue des projets depuis les années 2000.

Principe opérationnel. L'API Gateway (Kong, Traefik ou AWS API Gateway selon contexte) est la clé de voûte : il route les requêtes entrantes soit vers le monolithe (comportement actuel, par défaut), soit vers le nouveau microservice (comportement cible) selon le chemin de la requête ou des règles de feature flag. Le monolithe tourne en parallèle pendant toute la durée de la migration — jamais éteint avant que le microservice soit en production, validé et stabilisé.

Ordre d'extraction recommandé par Nehos. (1) Service d'authentification/identité en premier : périmètre bien délimité, API publique simple (token JWT), peu de couplage avec la logique métier, bénéfice immédiat pour la sécurité (rotation des secrets, MFA centralisé, SSO). (2) Service de notifications (email, SMS, push, webhooks) : nature asynchrone naturelle (découplage via message broker), zéro dépendance de lecture sur d'autres domaines, peut être extrait sans changer le monolithe (event-driven dès le départ). (3) Service de facturation/paiement : isolation PCI-DSS, généralement bien circonscrit dans le monolithe, bénéfice réglementaire immédiat après extraction. (4) Modules métier spécifiques par ordre de valeur business et de complexité d'extraction, guidé par la context map DDD produite lors de l'Event Storming.

Points d'attention critiques pendant la migration. Les données : chaque microservice doit avoir sa propre base de données (database per service pattern) — partager une base PostgreSQL entre microservices annule tous les bénéfices du découplage. La cohérence éventuelle : les transactions ACID distribuées n'existent pas à l'échelle — on les remplace par des sagas (voir section dédiée). La rétrocompatibilité des API : versionner les API dès le premier déploiement (v1, v2) et maintenir les anciennes versions pendant la transition. Les données de référence : certaines données partagées (pays, devises, paramètres globaux) nécessitent une stratégie explicite (service dédié, réplication, ou dénormalisation acceptée).

#Infrastructure microservices — API Gateway, Kafka, Service Mesh

#API Gateway — Kong, Traefik, AWS API Gateway

L'API Gateway est le point d'entrée unique de tout le système microservices. Il regroupe des responsabilités qui, sans lui, seraient dupliquées dans chaque service : authentification et autorisation (validation des tokens JWT, vérification des scopes OAuth2), rate limiting (protection contre les abus et les pics de charge imprévus), circuit breaking (isolation des pannes — si un service downstream est dégradé, le circuit breaker évite l'effet cascade sur tout le système), routage et load balancing, transformation de requêtes/réponses, logging centralisé des accès.

Kong (open source, très extensible via plugins, communauté large) est le choix Nehos par défaut sur Kubernetes. Traefik (nativement conçu pour Kubernetes, configuration via annotations et CRDs, très simple à opérer) est préféré sur les architectures plus légères. AWS API Gateway si le client est already all-in AWS. OVHcloud Managed Kubernetes si souveraineté France requise.

#Message Broker — Kafka vs RabbitMQ

Un message broker est indispensable dès que des services doivent communiquer de manière asynchrone (ce qui est la règle, pas l'exception dans une architecture microservices saine). Kafka (Apache Kafka, maintenant Confluent Cloud ou Aiven Kafka) est le choix pour l'event streaming haute disponibilité : rétention durable des events (les consumers peuvent rejouer l'historique), throughput très élevé (millions d'events/seconde), ordered partitions par clé, consumer groups. Idéal pour : event sourcing, CQRS, analytics temps réel, audit log immuable, intégration entre domaines via domain events. RabbitMQ est plus simple à opérer, mieux adapté aux queues de tâches traditionnelles (job queues, work queues avec ACK/NACK), au routage complexe par topic/header. À choisir quand le use case est simple (file de traitement d'emails, notifications asynchrones sans besoin de replay) et que l'équipe n'a pas les compétences Kafka.

#Service Mesh — Istio, Linkerd

Le service mesh devient pertinent 10+ microservices en production. Il ajoute une couche de proxy sidecar (Envoy pour Istio, linkerd2-proxy pour Linkerd) à chaque pod Kubernetes qui gère transparaitement : le mutual TLS (mTLS) entre tous les services (chiffrement du trafic interne, authentification service-to-service sans modifier le code applicatif), le traffic management (canary deployments, A/B testing sur le trafic interne, retries, timeouts, circuit breaking au niveau réseau), l'observabilité (traces, métriques, logs automatiques pour tout le trafic interne sans instrumentation manuelle).

Istio est plus complet mais plus complexe à opérer. Linkerd est plus léger, plus simple, performant et suffisant pour la plupart des architectures ETI.

#Container Orchestration — Kubernetes OVHcloud

Kubernetes (K8s) est devenu le standard de fait pour l'orchestration des microservices. Pour les clients Nehos qui ont des contraintes de souveraineté France (hébergement de données personnelles RGPD, données de santé HDS, secteur public), OVHcloud Managed Kubernetes offre un plan de contrôle managé sur des datacenters français avec SLA 99,95 %, sans transfert hors UE. Voir service Modernisation Legacy pour le détail de l'infrastructure Kubernetes souveraine.

#Observabilité distribuée — OpenTelemetry + Prometheus + Grafana

Un monolithe se débogue avec un stack trace. Un système de 9 microservices se débogue avec de l'observabilité. La différence est fondamentale : dans un système distribué, une requête utilisateur peut traverser 8 services différents avant d'aboutir à une erreur — sans tracing distribué, identifier le service fautif prend des heures, parfois des jours.

Les trois piliers de l'observabilité distribuée doivent être mis en place dès le premier microservice en production :

Traces distribuées — OpenTelemetry est le standard ouvert (CNCF) qui instrumente le code applicatif pour propager les span IDs entre services. Couplé à Jaeger ou Grafana Tempo comme backend de stockage, il permet de visualiser l'intégralité du parcours d'une requête à travers tous les microservices avec les durées, les erreurs et les attributs métier. Cas concret : une requête de checkout qui met 8 secondes au lieu de 800 ms — le waterfall de traces montre immédiatement que 7,2 secondes sont consommées dans un appel synchrone vers le service de vérification de stock qui interroge la base à chaque requête sans cache.

Métriques par service — Prometheus scrape les métriques exposées par chaque microservice (RED metrics : Rate, Errors, Duration) et les métriques système (CPU, mémoire, réseau). Grafana visualise les dashboards SLO/SLI par bounded context. Chaque équipe produit propriétaire d'un microservice est responsable de ses propres SLOs (ex : service Commandes — 99,9 % de disponibilité, p95 latence < 200 ms, taux d'erreur < 0,1 %).

Logs centralisés — Grafana Loki (stack Grafana native, très économique) ou ELK (Elasticsearch + Logstash + Kibana, plus puissant mais plus coûteux à opérer). Les logs de tous les microservices agrégés dans un seul backend avec les correlation IDs propagés depuis OpenTelemetry — ce qui permet de passer d'une trace à ses logs et inversement.

Les correlation IDs sont le lien entre les trois piliers : chaque requête reçoit un trace ID unique à l'entrée du système (API Gateway) qui est propagé dans tous les headers HTTP et tous les messages Kafka entre services. Sans eux, corréler une trace, ses métriques et ses logs est impossible à l'échelle.

#Patterns de cohérence — Saga, CQRS, Event Sourcing

Le passage d'un monolithe à des microservices brise les transactions ACID classiques : il n'y a plus de transaction SQL qui span plusieurs services avec rollback automatique. C'est le défi le plus souvent sous-estimé par les équipes qui se lancent dans la migration.

Saga pattern — Gérer les transactions distribuées. Une saga est une séquence de transactions locales, chacune mise à jour dans sa propre base de données, avec des compensating transactions en cas d'échec. Exemple : passer une commande avec réservation de stock + débit paiement + création expédition. Deux variantes : choreography (chaque service publie un event après sa transaction locale, les autres services réagissent en s'abonnant — simple à implémenter, difficile à déboguer quand ça déraille) et orchestration (un service orchestrateur central appelle les services dans l'ordre et gère les compensations — plus visible, plus testable, recommandé par Nehos sur les sagas complexes à 4+ étapes).

CQRS — Command Query Responsibility Segregation. Séparer le modèle d'écriture (Commands) du modèle de lecture (Queries). La partie write est optimisée pour la cohérence et la traçabilité, la partie read est optimisée pour la performance (vues dénormalisées, cache, ElasticSearch pour la recherche full-text). Très puissant combiné à Event Sourcing, nécessite une complexité d'implémentation non négligeable — à réserver aux bounded contexts avec des contraintes de lecture/écriture très différentes (ex : service Analytics, service Reporting).

Event Sourcing — L'historique comme source de vérité. Au lieu de stocker l'état courant d'une entité, on stocke tous les events qui ont conduit à cet état (append-only event log). L'état courant est reconstitué en rejouant les events depuis le début (ou depuis un snapshot). Avantages : audit log immuable complet, capacité à rejouer l'historique pour déboguer, time-travel debugging. Complexité : le schéma des events doit être versionné avec soin, la reconstruction d'état peut être coûteuse sur de longs historiques. À utiliser avec discernement : Kafka est un excellent event store pour cet usage.

#Organisation des équipes — Conway's Law et Team Topologies

La loi de Conway (1968) n'est pas une observation anodine : « Les organisations qui conçoivent des systèmes sont contraintes de produire des designs qui sont des copies de la structure de communication de ces organisations. » Dit autrement : si vous voulez une architecture microservices découplée, vous avez besoin d'équipes autonomes découplées. Sinon votre architecture microservices ressemblera à votre organigramme — avec des dépendances inter-équipes aussi couplées que le monolithe que vous venez de décomposer.

Team Topologies (Matthew Skelton et Manuel Pais, 2019) offre le cadre le plus opérationnel pour aligner organisation et architecture microservices :

Stream-aligned teams (équipes orientées flux de valeur) : chaque équipe possède un ou plusieurs bounded contexts end-to-end (conception, développement, déploiement, exploitation, on-call). Elle est autonome pour déployer son service sans coordination externe. C'est la structure cible pour les bounded contexts métier (Commandes, Facturation, Catalogue, etc.).

Platform team (équipe plateforme) : elle fournit l'internal developer platform (IDP) — CI/CD standardisé, Kubernetes, monitoring, service mesh, API Gateway, secrets management, templates de projets. Elle traite les équipes stream-aligned comme ses clients internes. Son objectif : réduire la cognitive load des équipes produit en leur évitant de réimplémenter les fondations techniques dans chaque service.

Enabling teams (équipes habilitantes) : équipes temporaires qui aident les équipes stream-aligned à adopter de nouvelles pratiques (migration vers OpenTelemetry, adoption du service mesh, DDD avancé). Elles se dissoudent une fois la compétence intégrée.

La transition organisationnelle est souvent le vrai projet : Nehos inclut systématiquement un volet organisationnel dans ses missions de migration monolithe → microservices, car l'architecture distribuée sans organisation distribuée produit des résultats décevants.

#Méthodologie Nehos — De l'Event Storming au déploiement Kubernetes

La méthodologie Nehos sur les projets de migration monolithe vers microservices se déroule en quatre phases successives avec des jalons d'architecture mesurables.

Phase 1 — Audit architecture et DDD (4-6 semaines). Analyse du monolithe existant : cartographie du code (AST analysis, dependency graph, hotspots git par module — les fichiers les plus modifiés sont souvent les bounded contexts les plus actifs), mesure de la dette technique sur les modules candidats à l'extraction (cf. glossaire dette technique), identification des bottlenecks mesurés (profiling, APM existant, données de monitoring). Animation de l'atelier Event Storming de 2 jours avec les parties prenantes métier et techniques. Output livrable : context map DDD avec 6-12 bounded contexts, backlog d'extraction priorisé, proposal d'architecture cible (stack, patterns, infrastructure), chiffrage phaseé du projet.

Phase 2 — Infrastructure fondatrice (3-5 semaines). Mise en place de l'infrastructure Kubernetes (OVHcloud Managed Kubernetes par défaut pour la souveraineté France), pipelines CI/CD par service (GitHub Actions ou GitLab CI), API Gateway (Kong ou Traefik), observabilité de base (OpenTelemetry + Prometheus + Grafana + Loki), message broker (Kafka ou RabbitMQ selon le profil du projet), structure de repositories (voir glossaire monorepo Turborepo/Nx pour le choix mono vs poly-repo). Cette infrastructure est opérationnelle avant le premier microservice extrait.

Phase 3 — Extractions successives (10-20 mois). Application itérative du pattern Strangler Fig par bounded context, dans l'ordre défini par la context map et le backlog d'extraction. Chaque extraction suit le même cycle : définition du contrat d'API du nouveau service, implémentation et tests (unit, integration, contract testing avec Pact), déploiement en shadow mode (trafic dupliqué vers l'ancien et le nouveau service pour comparaison des résultats), bascule progressive du trafic via API Gateway (10 % → 25 % → 50 % → 100 %), monitoring pendant 2 semaines post-bascule, suppression du code correspondant dans le monolithe.

Phase 4 — Optimisation et autonomie des équipes (3-6 mois). Fine-tuning de l'observabilité (SLOs définis et monitorés par bounded context), adoption du service mesh (Istio ou Linkerd) si le nombre de services le justifie, mise en place des runbooks par service, formation des équipes aux pratiques DevOps distribuées (on-call par domaine, chaos engineering léger avec Chaos Mesh), documentation de l'architecture finale dans le ADR (Architecture Decision Records). Cf. service Development Nehos pour les projets combinant modernisation legacy et refonte frontend.

#ROI mesurable — Cas scale-up SaaS 8 équipes

Cas client référence : scale-up SaaS B2B française (logiciel de gestion documentaire, 8 équipes produit, 120 000 lignes de code PHP, monolithe Symfony 3.4 déployé depuis 2016). Symptômes initiaux : fréquence de déploiement de 2 fois par mois (trop risqué de déployer plus souvent), incidents de production majeurs toutes les 3 semaines (MTTR moyen 4h30), 3 équipes bloquées sur les releases des 5 autres, impossible de scaler le module de génération de rapports sans scaler toute l'application. Mission Nehos sur 18 mois : Event Storming (9 bounded contexts identifiés), mise en place infrastructure Kubernetes OVHcloud + Kong + Kafka + OpenTelemetry, extraction progressive par Strangler Fig de 9 microservices (Auth, Notifications, Billing/Paiement, Documents Core, Recherche, Reporting, Analytics, Webhooks, Admin). Investissement total : 521 k€ HT sur 18 mois. Résultats mesurés à 18 mois : fréquence de déploiement 2 fois par mois → 4 fois par jour (multiplication par 60), MTTR incidents -68 % (de 4h30 à 1h26 en médiane), 8 équipes autonomes sur leurs bounded contexts respectifs sans coordination de release, coûts infrastructure divisés par 3 sur les pics de charge (scaling indépendant du module Reporting). Voir cas scale-up SaaS B2B monolithe microservices DDD.

#Tarification — 60 à 711 k€ HT

Trois fourchettes selon la taille du monolithe et la profondeur de la migration.

Extraction ciblée (3-4 bounded contexts) sur un monolithe de taille modeste (< 60 KLOC, 3-4 équipes) avec infrastructure Kubernetes de base et sans service mesh : 60 à 211 k€ HT sur 9 à 14 mois. Typique pour une ETI ou une scale-up qui extrait les services les plus critiques (Auth, Paiement, Notifications) sans refonte complète de l'architecture.

Migration structurelle (6-9 bounded contexts) sur un monolithe de taille intermédiaire (60-150 KLOC, 5-8 équipes) avec infrastructure Kubernetes complète, Kafka ou RabbitMQ, observabilité distribuée OpenTelemetry + Prometheus + Grafana et API Gateway productionné : 712 k€ HT sur 14 à 20 mois. C'est le scope le plus fréquent chez nos clients ETI SaaS B2B.

Refonte architecture complète (9-15 bounded contexts) sur un monolithe critique de grande taille (> 150 KLOC, 8+ équipes) avec service mesh (Istio ou Linkerd), event sourcing sur les domaines critiques, CQRS sur les bounded contexts à fort différentiel lecture/écriture, multi-régions OVHcloud pour la haute disponibilité : 220 à 711 k€ HT sur 18 à 24 mois.

Dans tous les cas, le forfait MCO mensuel post-migration (monitoring, audits architecturaux trimestriels, mises à jour sécurité Kubernetes, évolutions des pipelines CI/CD) est de2 15 872 € HT/mois selon la taille de l'infrastructure.

Estimation précise en 30 minutes — [réserver un RDV architecture microservices](https://calendly.com/raphael-poirier_/decouverte15min-nehos-groupe