Microservices : quand le monolithe est en fait meilleur

Vous avez lu les articles Medium. Vous avez vu les talks YouTube. Vous avez entendu dire que Netflix et Uber utilisent les microservices. Donc vous avez décidé : "Nous aussi, on va faire des microservices."

18 mois plus tard, vous avez 47 services. Une trace distribuée qui prend 5 minutes à debug. Des dépendances en spaghetti que personne ne comprend vraiment. Et vous payez CHF 200,000 de plus par an en infrastructure parce que chaque service a besoin de sa propre base de données "pour l'autonomie."

Votre CTO vous regarde et dit : "On aurait peut-être dû garder le monolithe."

Il a raison. Voici pourquoi et quand les microservices ont vraiment du sens.

Le vrai coût des microservices

Les architectes adorent parler des bénéfices des microservices : scalabilité indépendante, déploiement autonome, liberté technologique. C'est tout vrai.

Mais personne ne parle du coût.

Coût 1 : L'observabilité devient difficile

Un monolithe avec un problème ? Vous avez une stack trace, un log de base de données, tout dans un seul endroit. Vous savez d'où vient le problème.

47 microservices avec un problème ? Vous avez besoin de :

• Logging distribué (Elasticsearch, Loki, CloudWatch)
• Distributed tracing (Jaeger, Datadog, Tempo)
• Métriques centralisées (Prometheus, Graphite)
• Alerting intelligent (sinon vous avez 10 000 alertes par jour)
• Correlation IDs partout (pour suivre une requête à travers 15 services)

Coût : CHF 50 000-200 000 par an rien que pour l'observabilité. Une entreprise de 500+ employés sans cette stack en microservices est aveugle (vous ne saurez jamais où sont les bugs).

Coût 2 : Le réseau devient un problème

Un monolithe : tous les appels internes sont en mémoire (< 1ms). Zéro latence.

Microservices : chaque appel traverse le réseau. Vous avez :

• Latence réseau (5-20ms par saut)
• Risque de timeouts
• Défaillances partielles (le service A répond, mais le service B timeout)
• Tempêtes de retry (si vous n'avez pas de circuit breakers intelligents)

Une application qui faisait 10 appels internes en 10ms en monolithe, ça devient 100ms+ en microservices. Vous devez repenser l'architecture pour regrouper les requêtes, mettre en cache agressivement, etc.

Coût en performance : 10x plus lent sans optimisation. Et l'optimisation ? CHF 30 000-100 000 en temps d'engineering.

Coût 3 : Le déploiement devient complexe

Un monolithe : vous déployez 1 chose. Vous testez 1 chose. Si ça casse, vous rollback 1 chose.

47 microservices : vous avez 47 pipelines CI/CD. 47 points de défaillance potentiels. Vous devez orchestrer les déploiements (le service A dépend de la version X du service B, vous ne pouvez pas déployer B d'abord sans casser A).

Et les dépendances ? Elles changent tout le temps. Le service C qui dépendait du service D veut maintenant appeler le service E aussi. Ça s'appelle un "monolithe distribué" : tous les services sont étroitement couplés mais le couplage n'est pas visible.

Coût : 1 personne à plein temps juste pour gérer les déploiements.

Coût 4 : Les tests deviennent un cauchemar

Un monolithe : vous testez tout ensemble. Test d'intégration = lancer l'app et tester.

Microservices : pour tester vraiment, vous devez lancer les 47 services localement. Ou vous simulez les dépendances (et vos simulations divergent du comportement réel). Ou vous avez un environnement de staging qui ressemble à la prod (coûteux).

Contract testing, tests d'intégration inter-services, tests end-to-end... ça va coûter CHF 100 000+ en automatisation et infrastructure de test.

Coût 5 : La cohérence des données devient une philosophie

Un monolithe : une base de données, une transaction ACID, c'est gagné.

Microservices : chaque service a sa propre base de données (sinon pourquoi les avoir séparés ?). Donc comment garantir la cohérence ?

Saga patterns, event sourcing, transactions distribuées : c'est avancé, complexe, et beaucoup de CTO se trompent sur l'implémentation.

Résultat : des race conditions subtiles qui causent du downtime une fois par trimestre.

Total du coût caché

Voici ce que les microservices coûtent vraiment, au-delà de l'infrastructure :

Plus les coûts d'infrastructure compute habituels (CHF 200 000-400 000). Un système de 47 microservices coûte vite CHF 630 000-830 000 par an pour une entreprise de 500 personnes.

Un monolithe bien architecturé ? CHF 200 000-300 000 par an. Différence : CHF 300 000-500 000.

Ça veut dire que les microservices doivent apporter un bénéfice de CHF 300 000+ par an juste pour se justifier. Quel bénéfice ? Rarement clairement mesuré.

Quand les microservices ont VRAIMENT du sens

Maintenant, les microservices ne sont pas mauvais. Il y a des cas où c'est la bonne réponse :

Cas 1 : Très grande équipe, très gros système

Netflix a 5 000+ ingénieurs. Chaque équipe a ~10 personnes. Pour que 500 équipes ne se marchent pas dessus, il faut de l'autonomie. Donc microservices.

Mais vous avez 20 ingénieurs ? Vous n'avez pas ce problème. Un monolithe décent qu'on peut déployer 20 fois par jour, c'est meilleur que 20 microservices qu'on ne peut déployer que 2 fois par mois.

Règle empirique : Moins de 40 ingénieurs, oubliez les microservices. Plus de 100 ingénieurs, c'est justifié.

Cas 2 : Besoins de scaling vraiment différents

Vous avez un service utilisé par 1 million de requêtes par seconde et un autre avec 10 requêtes par seconde.

Si vous les mélangez dans un monolithe, vous devez tout scaler (même s'il ne faut scaler que le service à fort trafic). Coûteux.

Si vous les séparez en microservices, vous ne scalez que le service à fort trafic. Économie d'infrastructure.

Mais attention : ce cas est rare. 90 % des services ont des besoins de scaling similaires.

Cas 3 : Technologies vraiment différentes

Votre équipe data science veut Python + TensorFlow. Votre équipe backend veut Go. Votre équipe frontend veut Node.js.

Dans un monolithe, quelqu'un perd. Vous faites tout en Python ou tout en Go.

En microservices, chaque équipe a sa technologie.

Mais honnêtement ? Si vous avez besoin de 3 langages, c'est le symptôme d'un problème d'organisation, pas une solution. Et c'est souvent résoluble avec des bibliothèques partagées.

Cas 4 : Vraiment besoin de déploiements très fréquents et indépendants

Si vous devez déployer une fonctionnalité dans le service A 10 fois par jour sans toucher aux autres services, les microservices aident.

Mais combien d'équipes ont vraiment ce cas ? Peut-être 5 % des entreprises.

L'alternative : le monolithe modulaire

Il y a une architecture entre monolithe et microservices qui a mieux fonctionné pour nous : le monolithe modulaire.

Idée : Un codebase, une base de données, un déploiement, mais organisé en interne en modules indépendants avec des frontières claires.

monolith/
  ├── user_module/
  │   ├── handlers.go
  │   ├── service.go
  │   ├── repository.go
  │   └── tests/
  ├── payment_module/
  │   ├── handlers.go
  │   ├── service.go
  │   ├── repository.go
  │   └── tests/
  └── shared/
      ├── database.go
      └── logger.go

Bénéfices :

• Observabilité triviale (tout est dans un seul processus)
• Performance facile (appels internes en mémoire)
• Tests simples (lancer l'app une fois)
• Déploiement simple (une seule chose à déployer)

Flexibilité :

• Si plus tard un module a vraiment besoin de scaler indépendamment, vous le sortez en microservice. Mais vous avez les interfaces claires.
• Les équipes peuvent travailler sur des modules différents sans chaos.

Vous avez 80 % des bénéfices des microservices, 20 % du coût.

Arbre de décision pour la migration

Voici comment décider si c'est le moment de passer aux microservices :

Avez-vous > 100 ingénieurs ?
  Non -> Arrêtez ici. Monolithe ou monolithe modulaire.
  Oui -> Continuer.

Avez-vous des services avec des besoins de scaling radicalement différents ?
  Non -> Arrêtez ici. Le monolithe modulaire suffira.
  Oui -> Continuer.

Avez-vous mesuré le coût d'observabilité et d'infrastructure supplémentaire ?
  Non -> Allez mesurer. Peut-être changerez-vous d'avis.
  Oui et c'est justifié par le bénéfice ? -> Allez-y avec les microservices.

Checklist de décision : monolithe, monolithe modulaire ou microservices

Avant de prendre votre décision architecturale, passez cette checklist en revue avec votre équipe technique :

Commencez par un monolithe si :

• Votre équipe engineering compte moins de 15 personnes
• Votre produit est en phase de discovery (pivots fréquents)
• Vous n'avez pas encore validé votre product-market fit
• Votre budget ops annuel est inférieur à CHF 100,000
• Vous avez besoin de time-to-market rapide (< 6 mois)

Passez au monolithe modulaire si :

• Votre équipe grandit (15-50 engineers) et les conflits de merge augmentent
• Vous avez identifié 3-5 domaines métier distincts dans votre application
• Les déploiements prennent plus de 30 minutes (build + test + deploy)
• Vous voulez préparer une migration future vers microservices sans le coût immédiat

Justifiez les microservices uniquement si :

• Vous avez 50+ engineers et les équipes se bloquent mutuellement
• Au moins 2 services ont des besoins de scaling 10x différents
• Vous avez le budget pour CHF 400,000+/an d'infrastructure et ops supplémentaires
• Vous avez déjà une équipe platform/SRE en place (ou prévoyez d'en créer une)
• Vos SLAs exigent des déploiements indépendants par service (zero-downtime rolling updates)

Signaux d'alerte : revenez en arrière si :

• Vous avez plus de 30 microservices mais moins de 40 engineers
• Votre distributed tracing ne fonctionne pas (vous debuggez à l'aveugle)
• Un changement business nécessite de modifier 5+ services simultanément
• Votre MTTR a augmenté depuis la migration (signe de complexité non-maîtrisée)

En résumé

Les microservices sont séduisants sur le papier. En réalité, ils coûtent CHF 400 000-500 000/an de plus qu'un monolithe, et ce n'est justifié que si vous avez :

• 100+ ingénieurs
• Des besoins de scaling très différents par service
• Ou un besoin de déploiements ultra-fréquents et indépendants

Pour tous les autres (et c'est 95 % des entreprises suisses) : un monolithe modulaire est meilleur. Moins cher, plus rapide à construire, plus facile à opérer.

Si vous hésitez ? La réponse correcte est probablement de rester simple. La complexité est une dette qu'il faut rembourser pendant toute la durée de vie de votre application.

À lire aussi :

• Kubernetes pour les PME suisses : par où commencer ?
• Zero-downtime deployments : guide pour les CTO

Cet article vous a été utile ? Découvrez comment Hidora peut vous accompagner : Professional Services · Managed Services · SLA Expert