Architecture & Sécurité
Qu’est-ce que Microservices ?
Style d’architecture où l’application est découpée en services autonomes déployables séparément, communiquant par réseau (HTTP, messages) — pour scaler et faire évoluer des domaines métier indépendamment.
Définition simple
C'est comme remplacer un grand restaurant tout-en-un par des stands spécialisés reliés par des couloirs : chaque stand peut changer sa recette sans fermer les autres. Chaque microservice possède souvent sa base ou schéma dédié, son cycle de release et son équipe. Communication synchrone ([API REST](/lexique/api-application-programming-interface), gRPC) ou asynchrone (files). S’oppose à l’[architecture monolithique](/lexique/architecture-monolithique) où tout vit dans un déploiement unique.
Comment ça marche ?
Découpage par bounded context (DDD) ; gateway API ; service mesh optionnel ; CI/CD par service ; contrats versionnés ; sagas pour transactions distribuées. [Webhooks](/lexique/webhook) et messages relient souvent le monde externe.
Impact business
Bien calibrés, les microservices permettent de scaler par domaine (pic paiement vs catalogue) et d’accélérer les équipes autonomes — les études industrielles montrent aussi coût opérationnel et complexité réseau plus élevés : beaucoup d’organisations sous-estiment de 30 % à 50 % l’effort observabilité et déploiement les premières années.
Bonnes pratiques
- Commencer monolithe modulaire ; extraire quand friction équipe/scale le justifie ; observabilité unifiée ; SLIs par service ; documentation contrats.
Erreurs communes
- Découper trop tôt (« microservice pour chaque table SQL »). Oublier traçabilité distribuée (correlation IDs). Latence en cascade sans timeouts.
Prompt IA
Contexte : scale-up [marketplace]. Liste trois services candidats microservice et trois raisons de rester monolithe modulaire pour l’instant ; un risque (latence chaîne) par service choisi.
SERVICE LIÉ
Passer de la définition à un projet concret.
Application web & SaaS
Approfondir ce sujet dans le cadre d’un accompagnement adapté à votre contexte.
À LIRE AUSSI
Guides plus complets sur le blog.
QUESTIONS FRÉQUENTES
Aller plus loin sur Microservices.
Souvent overkill : la complexité réseau dépasse les gains avant product-market fit ; monolithe discipliné migré plus tard est courant.
Non toujours : fonctions serverless peuvent composer une architecture micro, mais la grille est taille équipe/cycle de vie, pas seulement packaging.
Éviter base SQL unique « fourre-tout » partagée ; préférer possession claire des données par service avec événements de synchro.