Microservices et Kubernetes B2B 2026 : le guide déploiement pratique

#Microservices en 2026 : quand ça fait sens pour une ETI B2B

Les microservices ne sont pas une évolution naturelle vers laquelle tout système doit tendre. Ce sont une réponse à des problèmes spécifiques — et les adopter sans que ces problèmes se posent revient à ajouter de la complexité sans contrepartie.

#Les trois signaux qui légitiment la migration

Signal 1 — La loi de Conway vous frappe. Votre monolithe est développé par 4 équipes de 5 personnes qui se marchent dessus sur le même dépôt Git. Chaque merge crée des conflits. Les revues de code sont paralysées parce que personne ne maîtrise tout le code. Les releases sont bloquées par des dépendances inter-équipes. C'est le signal le plus fiable qu'une décomposition en services alignée sur les équipes apporterait de la valeur.

Signal 2 — Scalabilité hétérogène. Le module de génération de rapports PDF consomme 16 vCPU pendant les exports mais reste dormant 22 heures sur 24. Le service de notifications doit tenir 5 000 requêtes/seconde pendant les campagnes marketing mais zéro en dehors. Scaler le monolithe entier pour ces besoins ponctuels coûte 4x trop cher. La décomposition en services permet de scaler indépendamment chaque domaine.

Signal 3 — Fréquence de déploiement incompatible. L'équipe "catalogue produits" déploie 3 fois par jour. L'équipe "comptabilité" déploie une fois par trimestre après une batterie de tests réglementaires. Dans un monolithe, la fréquence de déploiement de tout le système est alignée sur la plus lente des équipes. Les microservices permettent des cycles de livraison indépendants.

#Les préconditions à satisfaire avant de commencer

Migrer vers les microservices sans ces fondations en place mène systématiquement à l'échec :

• CI/CD mature : chaque service doit avoir son pipeline de build, test et déploiement automatisé. Sans CI/CD, la complexité opérationnelle des microservices est ingérable.
• Observabilité : dans un monolithe, un stack trace identifie immédiatement l'origine d'une erreur. Dans une architecture microservices, une requête traverse 5 à 8 services — sans tracing distribué, le débogage devient un cauchemar.
• Tests d'intégration : les interfaces entre services doivent être testées automatiquement. Le contract testing (Pact) est indispensable.
• Équipe DevOps/SRE dédiée : Kubernetes et l'infrastructure microservices demandent une expertise opérationnelle permanente. Une équipe de développement seule ne peut pas absorber cette charge en plus de la livraison produit.

#Le contre-argument : le monolithe modulaire

Pour les ETI de moins de 15 développeurs ou avec un domaine métier cohérent, un monolithe modulaire (modules bien délimités avec des interfaces internes claires, dans un seul déploiement) offre 80 % des bénéfices de conception des microservices à 20 % de la complexité opérationnelle. C'est la recommandation Nehos par défaut — voir notre analyse complète dans l'article monolith vers microservices : quand faut-il migrer.

#Architecture type : décomposition d'un monolithe en 6 services métier

Illustrons la décomposition avec un cas concret : un ERP e-commerce B2B (commandes, catalogue, facturation, expéditions, gestion clients, analytics) initialement développé comme un monolithe Rails. L'équipe est passée de 4 à 22 développeurs en 3 ans — le signal 1 est activé.

#Les 6 services métier identifiés

La décomposition suit les bounded contexts du Domain-Driven Design (DDD) :

#Principes de découpage appliqués

Principe 1 — Chaque service possède sa propre base de données. Le order-service n'accède jamais directement à la table products du catalog-service. Il conserve une copie dénormalisée des données produits dont il a besoin au moment de la création de commande. Cette règle est non-négociable — un schéma de base partagé est un monolithe distribué avec les inconvénients des deux mondes.

Principe 2 — Communication synchrone minimisée. Les appels HTTP synchrones entre services créent du couplage temporel. Quand le catalog-service est en maintenance, l'order-service ne doit pas tomber. La communication asynchrone via événements (Kafka ou RabbitMQ) est privilégiée pour tout ce qui n'est pas critique au milliseconde. L'event-driven architecture est le complément naturel des microservices.

Principe 3 — Strangler Fig pour la migration. On ne rewrite pas le monolithe en une fois. Le strangler fig pattern extrait un service à la fois, derrière un reverse proxy qui route progressivement le trafic vers le nouveau service ou l'ancien selon le domaine.

Principe 4 — APIs versionnées entre services. Les interfaces entre services sont des contrats — modifiez-les sans versioning et vous créerez des incidents en production. Chaque service expose une API OpenAPI versionnée, même pour les communications internes.

#Kubernetes pour les néophytes : les concepts essentiels en 10 minutes

Kubernetes (K8s) est un système d'orchestration de conteneurs : il prend en charge le placement des conteneurs sur les noeuds du cluster, leur redémarrage automatique en cas de crash, leur scaling selon la charge, la gestion de la configuration et des secrets, et le networking entre les services.

#Les 8 ressources Kubernetes à connaître

Pod : l'unité de base. Un Pod encapsule un ou plusieurs conteneurs qui partagent le même réseau et le même stockage. En pratique, un Pod = un conteneur applicatif (+ éventuellement des sidecars). Les Pods sont éphémères — ne pas stocker d'état dans un Pod sans PersistentVolume.

Deployment : gère le cycle de vie des Pods applicatifs. Un Deployment garantit que N réplicas du Pod sont toujours en cours d'exécution. Il pilote les rolling updates (mise à jour progressive sans downtime) et les rollbacks.

Service : expose un ensemble de Pods derrière une adresse stable (DNS interne au cluster). Sans Service, les Pods sont inaccessibles depuis les autres services du cluster. Types principaux : ClusterIP (interne au cluster), LoadBalancer (expose vers l'extérieur via un load balancer cloud).

Ingress : règles de routing HTTP/HTTPS vers les Services du cluster. Un Ingress Controller (Nginx, Traefik, Kong) interprète les ressources Ingress et configure le proxy. C'est le point d'entrée des requêtes externes vers le cluster.

ConfigMap : configuration non-sensible montée dans les Pods comme variables d'environnement ou fichiers. Les URLs de services tiers, les feature flags, les configurations applicatives non-secrètes.

Secret : configuration sensible (mots de passe, tokens, certificats). Par défaut encodée en base64 dans etcd — ce qui n'est pas du chiffrement. La sécurisation des Secrets nécessite un traitement spécifique (voir la section sécurité).

HorizontalPodAutoscaler (HPA) : scale automatiquement le nombre de réplicas d'un Deployment en fonction de métriques (CPU, mémoire, métriques custom via Prometheus Adapter). L'analytics-service peut ainsi scaler de 2 à 20 réplicas pendant les exports de nuit.

PersistentVolume (PV) / PersistentVolumeClaim (PVC) : stockage persistant pour les workloads avec état. Les bases de données en Kubernetes utilisent des PVC backed par des disques cloud (OVHcloud Block Storage, AWS EBS, Azure Disk).

#La distinction plan de contrôle / plan de données

Kubernetes est composé d'un plan de contrôle (API Server, etcd, Controller Manager, Scheduler) qui prend les décisions d'orchestration, et d'un plan de données (Worker Nodes avec kubelet et container runtime) qui exécute les charges de travail. Les clusters Kubernetes managés (OVHcloud, EKS, AKS) prennent en charge la gestion du plan de contrôle — ce qui élimine la charge opérationnelle la plus critique.

#Helm charts et GitOps : déploiement reproductible avec ArgoCD

#Helm : le gestionnaire de paquets Kubernetes

Helm est à Kubernetes ce que npm est à Node.js — un gestionnaire de paquets qui template les manifestes YAML Kubernetes et gère les versions des déploiements. Un Helm Chart est un répertoire structuré contenant des templates YAML paramétrables et un fichier values.yaml qui expose les variables configurables.

# values.yaml du order-service
replicaCount: 3
image:
  repository: registry.nehos.io/order-service
  tag: "1.4.2"
resources:
  limits:
    cpu: "500m"
    memory: "512Mi"
  requests:
    cpu: "100m"
    memory: "256Mi"
autoscaling:
  enabled: true
  minReplicas: 2
  maxReplicas: 10
  targetCPUUtilizationPercentage: 70
env:
  DATABASE_URL:
    valueFrom:
      secretKeyRef:
        name: order-service-secrets
        key: database-url

Les Helm values par environnement permettent de surcharger les valeurs pour chaque cluster (développement, staging, production) : helm upgrade order-service ./charts/order-service -f values-prod.yaml. Un chart bien conçu est la fondation du déploiement reproductible.

#GitOps : l'état du cluster déclaré dans Git

Le GitOps est le principe selon lequel l'état souhaité du cluster Kubernetes est entièrement décrit dans un dépôt Git. Tout changement d'infrastructure passe par une PR Git — pas de kubectl apply manuel en production. Un opérateur GitOps (ArgoCD ou Flux) surveille le dépôt Git et réconcilie l'état réel du cluster avec l'état déclaré.

#ArgoCD : la référence GitOps en 2026

ArgoCD est l'opérateur GitOps le plus adopté en entreprise selon le CNCF Survey 2025. Son architecture est simple : une Application ArgoCD pointe vers un dépôt Git (et un chemin de manifestes ou un Chart Helm) et un cluster Kubernetes cible. ArgoCD surveille le dépôt en continu et applique automatiquement (ou après approbation manuelle) les changements détectés.

# Application ArgoCD pour order-service en production
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: order-service-prod
  namespace: argocd
spec:
  project: production
  source:
    repoURL: https://github.com/nehos/k8s-manifests
    targetRevision: main
    path: apps/order-service/overlays/production
  destination:
    server: https://kubernetes.default.svc
    namespace: order-service
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
      - CreateNamespace=true

Avantages mesurés par Nehos sur 8 projets Kubernetes en production :

• 0 déploiement manuel en production depuis l'adoption ArgoCD
• Rollback en 90 secondes via revert Git (vs 20 minutes de kubectl manuel)
• Auditabilité complète : chaque changement de configuration est tracé dans l'historique Git avec l'auteur, la date et le diff
• Détection de drift : si quelqu'un modifie le cluster directement (sans passer par Git), ArgoCD alerte et peut auto-corriger

#La structure du dépôt Git GitOps

La structure recommandée pour un projet multi-environnement avec Kustomize + Helm :

k8s-manifests/
├── apps/
│   ├── order-service/
│   │   ├── base/           # Manifestes communs tous env
│   │   └── overlays/
│   │       ├── staging/    # Surcharges staging
│   │       └── production/ # Surcharges production
│   └── catalog-service/
│       └── ...
├── infrastructure/
│   ├── cert-manager/
│   ├── ingress-nginx/
│   └── monitoring/         # Prometheus, Grafana
└── argocd/
    └── applications/       # Définitions ArgoCD Applications

#Service mesh : Istio ou Linkerd pour les ETI, différences pratiques

Un service mesh est une couche d'infrastructure qui gère la communication entre les services : chiffrement TLS mutuel automatique (mTLS), circuit breaking, retry automatique, load balancing avancé, et observabilité fine des flux inter-services. Il opère via des proxies sidecar injectés dans chaque Pod.

#Istio : puissant mais complexe

Istio est le service mesh le plus complet de l'écosystème. Ses capacités incluent le traffic management granulaire (canary deployments avec répartition 90/10 du trafic, A/B testing, fault injection), le mTLS automatique entre tous les services, les politiques d'autorisation L7 (service A peut appeler service B sur /api/orders mais pas /api/admin), et l'intégration native avec Prometheus et Jaeger.

Le coût opérationnel d'Istio est réel. Istiod (le plan de contrôle) et les proxies Envoy consomment environ 0,5 vCPU et 50 MB de RAM par Pod. Sur un cluster de 50 Pods, c'est 25 vCPU et 2,5 GB de RAM ajoutés pour l'infrastructure mesh seul. La courbe d'apprentissage est significative — comptez 2 à 3 semaines pour qu'une équipe DevOps maîtrise Istio en profondeur.

Istio est recommandé pour les clusters de plus de 15 services avec des exigences strictes de sécurité inter-services, des canary deployments automatisés, ou une conformité PCI-DSS qui impose le chiffrement en transit entre tous les workloads.

#Linkerd : minimaliste et performant

Linkerd a fait le choix inverse d'Istio : un périmètre fonctionnel délibérément réduit pour maximiser la simplicité opérationnelle. Linkerd implémente le mTLS automatique, l'observabilité (métriques par route HTTP, P99 par service pair), le load balancing EWMA (exponentially weighted moving average) et le retry automatique — et rien d'autre.

L'overhead Linkerd est ~3x inférieur à Istio (proxies Rust ultra-légers vs Envoy C++). L'installation prend 10 minutes, pas 3 heures. La surface d'attaque est réduite.

Linkerd est recommandé pour les ETI qui débutent avec les service meshes : il apporte les bénéfices essentiels (mTLS, observabilité réseau) sans la charge cognitive d'Istio. Si les besoins évoluent vers du traffic management avancé, la migration Linkerd → Istio est documentée et réalisable.

#Décision pour les ETI

→ Vous évaluez vos options ? Utilisez notre estimateur de budget en ligne pour obtenir une fourchette en 2 minutes, ou consultez nos tarifs détaillés.

#Observabilité Kubernetes : Prometheus, Grafana, OpenTelemetry

Dans un système distribué, l'observabilité n'est pas optionnelle — c'est la condition pour maintenir un SLA. Le pilier des 3 signaux (métriques, logs, traces) s'applique à chaque service individuellement et à l'architecture dans son ensemble.

#Prometheus : métriques time-series

Prometheus collecte les métriques en mode pull (il scrape les endpoints /metrics des applications et des composants Kubernetes à intervalles réguliers). Le format d'exposition est standardisé — tous les composants Kubernetes exposent leurs métriques nativement pour Prometheus.

Les métriques critiques à surveiller par service :

# Taux de requêtes HTTP par code de réponse
rate(http_requests_total{service="order-service"}[5m])

# Latence P99 par endpoint
histogram_quantile(0.99,
  rate(http_request_duration_seconds_bucket
    {service="order-service"}[5m])
)

# Erreurs 5xx en pourcentage du trafic
rate(http_requests_total{status=~"5.."}[5m])
/ rate(http_requests_total[5m]) * 100

kube-state-metrics expose l'état des ressources Kubernetes (Pods en état CrashLoopBackOff, Deployments en cours de rollout, HPA à saturation) — indispensable pour l'alerting infra.

#Grafana : dashboards et alertes

Grafana visualise les métriques Prometheus et centralise l'alerting. En 2026, Grafana Mimir remplace la stack Prometheus standalone pour les architectures multi-cluster : stockage long-terme des métriques, haute disponibilité, et query distribuée sans limiter à l'espace disque d'un seul serveur.

Les dashboards essentiels :

• USE Method par noeud (Utilization, Saturation, Errors) — détecte les noeuds saturés
• RED Method par service (Rate, Errors, Duration) — détecte les régressions de performance
• Dashboard Kubernetes Cluster (ID Grafana officiel : 6417) — état global du cluster
• Dashboard par service métier — métriques business spécifiques (commandes créées/min, paiements traités)

L'observabilité monitoring agents IA requiert les mêmes fondations — un cluster Kubernetes correctement monitoré via Prometheus/Grafana est directement réutilisable pour monitorer les workloads IA.

#OpenTelemetry : le standard de l'instrumentation en 2026

OpenTelemetry (OTel) est le standard CNCF pour l'instrumentation des applications : traces distribuées, métriques et logs avec un SDK unique, indépendamment du backend d'observabilité cible. Instrumenter une fois avec OTel, envoyer vers n'importe quel backend (Grafana Tempo, Jaeger, Datadog, New Relic) sans modifier le code applicatif.

// Instrumentation NestJS avec OpenTelemetry
import { NodeSDK } from '@opentelemetry/sdk-node';
import { OTLPTraceExporter } from '@opentelemetry/exporter-trace-otlp-http';
import { getNodeAutoInstrumentations } from '@opentelemetry/auto-instrumentations-node';

const sdk = new NodeSDK({
  traceExporter: new OTLPTraceExporter({
    url: 'http://otel-collector:4318/v1/traces',
  }),
  instrumentations: [getNodeAutoInstrumentations()],
});
sdk.start();

L'OTel Collector est déployé comme DaemonSet Kubernetes — il collecte les signaux de tous les Pods du noeud et les route vers les backends. Cette architecture découple l'instrumentation applicative des backends d'observabilité.

#Sécurité : RBAC, network policies, secrets management (Vault, SOPS)

La sécurité Kubernetes est un domaine où les configurations par défaut sont délibérément permissives pour faciliter l'onboarding — ce qui signifie que les clusters en production non durcis présentent des surfaces d'attaque significatives. La sécurité des agents IA et des APIs s'appuie sur les mêmes fondations.

#RBAC : principe du moindre privilège

Le RBAC (Role-Based Access Control) Kubernetes contrôle qui peut faire quoi sur quelles ressources du cluster. Trois primitives : Role (permissions dans un namespace), ClusterRole (permissions cluster-wide), RoleBinding/ClusterRoleBinding (association d'un Role à un sujet).

# Role pour le pipeline CI/CD — deployer uniquement dans son namespace
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: ci-deployer
  namespace: order-service
rules:
- apiGroups: ["apps"]
  resources: ["deployments"]
  verbs: ["get", "list", "patch", "update"]
- apiGroups: [""]
  resources: ["configmaps"]
  verbs: ["get", "list", "create", "update"]

Erreurs RBAC fréquentes en production : cluster-admin donné au service account des pipelines CI/CD (donne un accès total au cluster), absence de RBAC sur les namespaces de staging (permettant des accès croisés accidentels), ServiceAccounts avec des tokens à durée de vie infinie.

#Network Policies : micro-segmentation du trafic

Par défaut, tous les Pods Kubernetes peuvent communiquer avec tous les autres Pods du cluster. Les Network Policies permettent la micro-segmentation : définir précisément quels Pods peuvent parler à quels autres Pods, sur quels ports.

# order-service peut uniquement être appelé par api-gateway et par order-worker
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: order-service-ingress
  namespace: order-service
spec:
  podSelector:
    matchLabels:
      app: order-service
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: api-gateway
    - podSelector:
        matchLabels:
          app: order-worker
    ports:
    - protocol: TCP
      port: 3000

Les Network Policies requièrent un CNI compatible (Calico, Cilium, Weave) — Flannel ne les supporte pas. Cilium est la recommandation Nehos en 2026 : eBPF natif, performances supérieures, et observabilité réseau intégrée.

#Gestion des secrets : Vault et SOPS

Les Kubernetes Secrets par défaut sont encodés en base64 dans etcd — ce n'est pas du chiffrement. Quiconque a accès à etcd ou aux droits get secrets dans RBAC peut lire tous les secrets en clair.

HashiCorp Vault est la solution enterprise pour la gestion des secrets : stockage chiffré, rotation automatique des credentials de base de données, PKI interne, audit log complet de chaque accès. L'intégration Kubernetes se fait via l'External Secrets Operator (ESO) : les Secrets Kubernetes sont peuplés dynamiquement depuis Vault, avec renouvellement automatique.

# ExternalSecret — synchronise un secret Vault vers Kubernetes
apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: order-service-db-credentials
  namespace: order-service
spec:
  refreshInterval: 1h
  secretStoreRef:
    name: vault-backend
    kind: SecretStore
  target:
    name: order-service-secrets
  data:
  - secretKey: database-url
    remoteRef:
      key: secret/order-service/prod
      property: database-url

SOPS (Secrets OPerationS) est l'alternative légère pour les équipes qui n'ont pas besoin de Vault : chiffrement des fichiers de secrets Git avec une clé AWS KMS, GCP KMS, ou une clé PGP. Les secrets chiffrés peuvent être commités dans Git (GitOps friendly) — seuls les opérateurs avec accès à la clé KMS peuvent les déchiffrer.

La dette technique liée à la gestion des secrets (secrets en clair dans les variables d'environnement CI/CD, rotation manuelle annuelle) est l'une des plus coûteuses à résoudre après coup — c'est un sujet à traiter dès le démarrage du projet Kubernetes.

#Kubernetes managé : OVHcloud vs AWS EKS vs Azure AKS pour les entreprises françaises

Gérer le plan de contrôle Kubernetes (API Server, etcd, Scheduler) soi-même en production est une charge opérationnelle que peu d'équipes ETI peuvent absorber. Les trois services managés pertinents pour les entreprises françaises en 2026 :

#OVHcloud Managed Kubernetes

Forces : hébergement en France (Roubaix, Gravelines, Strasbourg) avec garantie RGPD native, conformité SecNumCloud en cours de certification pour certains produits, tarification prévisible en euros sans risque de change, support francophone, intégration native avec l'écosystème OVHcloud (Object Storage S3-compatible, Block Storage, Registry Docker privé, Databases managées PostgreSQL/MySQL).

Limites : fonctionnalités enterprise moins complètes qu'EKS/AKS sur certains aspects (autoscaling de noeuds moins mature, écosystème d'add-ons plus restreint), présence régionale limitée à l'Europe. Pour les projets avec exigences de cloud souverain France, OVHcloud est souvent le choix par défaut.

#AWS EKS

Forces : maturité maximale, intégration profonde avec l'écosystème AWS (IAM pour RBAC, ALB Ingress Controller, EBS CSI Driver, ECR), node autoscaling Karpenter performant, largest écosystème d'add-ons certifiés, SLA 99,95 % sur le plan de contrôle.

Limites : coût du plan de contrôle ($0,10/heure par cluster = $876/an), facturation en dollars, données stockées hors France (sauf régions eu-west-3 Paris), complexité IAM elevée, vendor lock-in significatif sur les composants AWS-spécifiques.

Recommandation : EKS pour les projets déjà ancrés dans l'écosystème AWS, ou pour les entreprises avec des filiales hors UE nécessitant une présence globale.

#Azure AKS

Forces : intégration native avec Azure Active Directory (RBAC Kubernetes piloté par Azure AD), bon support des workloads Microsoft (.NET, SQL Server), présence régionale Europe West et France Central, Azure Policy pour la gouvernance des clusters.

Limites : historique de fiabilité du plan de contrôle AKS moins exemplaire qu'EKS (incidents majeurs en 2023-2024), coût total souvent supérieur à EKS pour des workloads équivalents, complexité de la tarification.

Recommandation : AKS pour les entreprises dont l'IT est fortement Azure/Microsoft (Active Directory, Office 365, Azure DevOps), la cohérence de la stack cloud justifie les limitations.

#Tableau de synthèse

La productivité développeur sur un projet Kubernetes dépend aussi du choix de la plateforme cloud — l'écosystème d'outils, la qualité de la documentation et la réactivité du support influencent directement la vélocité de l'équipe.

#Sécurité avancée : Pod Security Standards et image scanning

Deux niveaux de sécurité supplémentaires indispensables en production :

#Pod Security Standards

Depuis Kubernetes 1.25, les Pod Security Standards remplacent le PodSecurityPolicy déprécié. Trois profils : privileged (tout est permis), baseline (politiques minimales), restricted (hardening maximal). Appliquer au niveau du namespace :

apiVersion: v1
kind: Namespace
metadata:
  name: order-service
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted

Le profil restricted interdit : les conteneurs root, les volumes hostPath, les capacités Linux supplémentaires, les conteneurs privileged. La grande majorité des applications métier peuvent fonctionner en mode restricted avec quelques ajustements de configuration.

#Image scanning dans la CI/CD

Chaque image Docker déployée en production doit être scannée pour les vulnérabilités CVE avant déploiement. Trivy (open source, CNCF) est le scanner de référence en 2026 — intégrable en 5 lignes dans n'importe quel pipeline GitHub Actions ou GitLab CI. Snyk Container est l'alternative SaaS avec des fonctionnalités de remédiation guidée.

La qualité du code assurée par l'IA inclut désormais la détection des dépendances vulnérables — les pipelines CI/CD modernes bloquent les merges si des CVE critiques sont détectées dans les images.

#Décision finale : monolithe modulaire vs microservices vs serverless en 2026

#Le triangle des compromis

Aucune architecture n'est universellement supérieure — chaque choix optimise certains paramètres au détriment d'autres :

Monolithe modulaire :

• Complexité opérationnelle : faible
• Overhead de communication : zéro (appels de fonctions en mémoire)
• Scalabilité granulaire : impossible (scale du monolithe entier)
• Vitesse de démarrage : rapide (une équipe, un déploiement)
• Limite : ~15 développeurs avant que la coordination devienne le goulot d'étranglement

Microservices sur Kubernetes :

• Complexité opérationnelle : élevée (Kubernetes, service mesh, observabilité distribuée)
• Overhead de communication : réel (latence réseau, sérialisation, résilience)
• Scalabilité granulaire : totale (chaque service scale indépendamment)
• Vitesse de démarrage : lente (investissement initial 3-6 mois avant productivité)
• Optimum : 15 à 200 développeurs avec équipe DevOps dédiée

Serverless (AWS Lambda, Azure Functions, OVHcloud Functions) :

• Complexité opérationnelle : faible (pas de cluster à gérer)
• Overhead de communication : variable (cold start 100-500ms pour certains runtimes)
• Scalabilité : automatique et instantanée
• Coût : pay-per-use (excellent pour les workloads imprévisibles, cher pour les workloads constants)
• Optimum : fonctions event-driven, traitements asynchrones, workloads très imprévisibles

#La recommandation Nehos par profil

Startup / scale-up < 15 devs → Monolithe modulaire (Rails, NestJS monorepo) avec déploiement sur VM ou PaaS (Render, Heroku, OVHcloud Public Cloud Instance). Revisitez dans 18 mois si l'équipe double.

ETI 15-50 devs, domaines métier distincts → Architecture de services (3 à 6 services) sur Kubernetes managé OVHcloud ou EKS. Helm + ArgoCD dès le départ. Linkerd si mTLS requis. Évitez Istio à ce stade.

Enterprise 50+ devs, SLA contractuels → Microservices complets avec service mesh Istio, observabilité complète (Prometheus/Grafana/Tempo), Vault pour les secrets, Cilium pour le networking, GitOps strict ArgoCD. Le niveau de maturité DevOps requis impose une équipe SRE dédiée.

Workloads event-driven, IA, batch → Kubernetes + serverless hybride : les APIs et les services métier sur Kubernetes, les fonctions event-driven (traitement d'images, envoi d'emails, webhooks) en serverless. Cette combinaison est le pattern Nehos pour les architectures cloud-native B2B modernes.

#Les anti-patterns à éviter absolument

Le monolithe distribué : découper en microservices sans découper les bases de données. Résultat : la complexité opérationnelle des microservices + le couplage du monolithe. C'est pire que les deux alternatives.

Le service trop granulaire : un service par table de base de données. Résultat : des centaines de micro-services de 50 lignes qui ne peuvent pas fonctionner indépendamment. Le bon niveau de granularité est le bounded context métier, pas la table SQL.

La migration big bang : réécrire le monolithe entier avant de passer en production. L'approche correcte est le strangler fig pattern — extraire un service à la fois, le valider en production, passer au suivant.