Pour la grande majorité des PME et ETI qui lancent une application métier, le bon choix par défaut est un monolithe bien structuré — pas des microservices. Les microservices résolvent un problème d’organisation (plusieurs équipes qui doivent déployer indépendamment), pas un problème de performance. Tant que votre équipe technique tient dans une seule pièce, un monolithe modulaire sera plus rapide à livrer, moins coûteux à exploiter et plus simple à faire évoluer.
Ce n’est pas qu’une opinion. En 2023, l’équipe de surveillance vidéo d’Amazon Prime Video a publiquement documenté être revenue d’une architecture microservices/serverless vers un monolithe pour un de ses services internes — réduisant son coût d’infrastructure de plus de 90 % tout en augmentant sa capacité de montée en charge (Prime Video Tech, 2023). Si même une équipe aux ressources d’Amazon peut sur-architecturer un service, le risque est au moins aussi réel pour une PME avec une équipe de 3 à 10 développeurs.
Ce que les microservices apportent réellement
Les microservices ont une vraie utilité : ils permettent à plusieurs équipes autonomes de déployer leur périmètre sans se marcher dessus, et de scaler indépendamment un composant précis qui subit une charge disproportionnée (un moteur de recherche, un service de paiement très sollicité). Netflix, Uber ou Amazon en ont besoin parce qu’ils ont des centaines d’ingénieurs organisés en dizaines d’équipes produit.
Le problème n’est pas l’architecture en elle-même, c’est son coût d’entrée : observabilité distribuée, gestion des pannes en cascade, cohérence des données entre services, complexité de déploiement. Ce coût est fixe — il pèse autant sur une équipe de 50 personnes que sur une équipe de 4.
Le coût caché pour une équipe de taille PME
Avec une petite équipe, les microservices transforment des problèmes simples en problèmes distribués :
- Débogage plus lent. Une erreur qui traverse 5 services demande de corréler des logs sur 5 systèmes différents, contre une simple stack trace dans un monolithe.
- Latence réseau ajoutée. Chaque appel entre services passe par le réseau au lieu d’un appel de fonction en mémoire — un coût invisible au début, mesurable à l’échelle.
- Déploiement multiplié. Versionner, tester et déployer 8 services indépendants demande une infrastructure CI/CD que peu de PME ont les moyens de maintenir correctement.
- Transactions complexes. Une opération qui touchait une seule base de données doit désormais gérer la cohérence entre plusieurs bases, souvent via des patterns comme la saga — une complexité disproportionnée pour la plupart des besoins métier.
Pour une équipe de moins de 10 développeurs, cette complexité ralentit la livraison de fonctionnalités au lieu de l’accélérer — exactement l’inverse de l’objectif recherché.
Pourquoi le monolithe modulaire reste le bon point de départ
Shopify, l’un des plus gros acteurs mondiaux du e-commerce, fait toujours tourner l’essentiel de sa plateforme sur un monolithe Ruby on Rails — organisé en modules internes stricts plutôt qu’éclaté en services réseau. Basecamp, à l’origine du terme “majestic monolith” popularisé par David Heinemeier Hansson (créateur de Rails), défend la même approche depuis quinze ans : un seul déploiement, une seule base de code, des frontières internes claires entre modules métier.
Un monolithe bien modularisé donne l’essentiel des bénéfices organisationnels des microservices — séparation claire des responsabilités, code testable par module — sans le coût opérationnel du réseau distribué.
Tableau comparatif
| Critère | Monolithe modulaire | Microservices |
|---|---|---|
| Taille d’équipe adaptée | 1 à ~15 développeurs | Plusieurs équipes autonomes (30+) |
| Vitesse de livraison initiale | Rapide | Lente (infrastructure à mettre en place) |
| Coût d’exploitation | Faible à modéré | Élevé (observabilité, orchestration) |
| Débogage | Simple (une seule stack trace) | Complexe (traces distribuées) |
| Scalabilité fine par composant | Limitée | Possible |
| Déploiement indépendant par équipe | Non | Oui |
| Risque de sur-ingénierie | Faible | Élevé si l’équipe est petite |
Les signaux qui justifient réellement de passer aux microservices
Le passage a du sens quand un ou plusieurs de ces signaux apparaissent concrètement — pas par anticipation :
- Plusieurs équipes produit distinctes se gênent mutuellement en déployant sur la même base de code plusieurs fois par jour.
- Un composant précis (traitement d’images, calcul de recommandations, paiement) a des besoins de scaling radicalement différents du reste de l’application.
- Des contraintes de conformité ou de sécurité imposent d’isoler un périmètre de données sensibles dans son propre service.
- La base de code est devenue un frein mesurable : temps de build qui explose, déploiements qui échouent fréquemment faute d’isolation entre modules.
En dehors de ces cas, découper prématurément revient à payer le prix de la complexité distribuée sans en retirer le bénéfice organisationnel.
Le monolithe modulaire comme voie intermédiaire
La pratique qui monte chez les équipes expérimentées n’est pas un choix binaire : c’est le monolithe modulaire. On structure le code en modules métier fortement découplés, avec des interfaces internes strictes, exactement comme on le ferait pour des microservices — mais sans les déployer séparément. Si un module doit un jour devenir un service indépendant, l’extraction est largement facilitée parce que les frontières existent déjà dans le code.
C’est l’approche que nous recommandons par défaut sur les projets que nous démarrons : construire pour pouvoir découper plus tard, sans payer le coût de la découpe avant d’en avoir besoin.
Notre recommandation
Démarrez en monolithe modulaire, quelle que soit votre ambition à long terme. Mesurez les vrais points de friction au fur et à mesure que votre équipe et votre trafic grandissent, et n’extrayez un service indépendant que lorsqu’un signal concret — pas une intuition — le justifie. L’architecture la plus sophistiquée n’est jamais celle qui impressionne le plus sur un schéma, c’est celle qui laisse votre équipe livrer vite sans s’effondrer sous sa propre complexité.
Vous démarrez un projet d’application métier et vous hésitez sur l’architecture à adopter ? Discutons de votre projet → — chez Shortcut, on cadre l’architecture en fonction de votre équipe et de votre trajectoire réelle, pas d’un effet de mode.