Les monolithes modulaires remplacent les microservices dans les équipes d'ingénierie de taille moyenne

Pendant la plus grande partie de la dernière décennie, découper une application en microservices était considéré comme la décision responsable, celle qu'on prenait une fois que l'échelle devenait vraiment importante. En 2026, un nombre croissant d'équipes d'ingénierie inverse discrètement cette décision, non pas en abandonnant les frontières de service, mais en les regroupant à nouveau dans une seule unité déployable avec une séparation interne stricte : le monolithe modulaire.

L'exemple public le plus clair reste l'équipe Prime Video d'Amazon, qui en 2023 a déplacé son service d'analyse de qualité vidéo d'un pipeline distribué basé sur Lambda et des microservices vers un unique processus monolithique. L'équipe a rapporté une réduction d'environ 90 % des coûts d'infrastructure pour ce service spécifique, ainsi qu'un débogage bien plus simple.

Pourquoi le pendule est revenu en arrière

Les microservices résolvent un problème précis : la capacité de déploiement et de mise à l'échelle indépendantes pour des équipes suffisamment grandes pour qu'une base de code partagée devienne un goulot d'étranglement de coordination. Pour une organisation d'ingénierie de 200 personnes divisée en dizaines d'équipes autonomes, ce compromis a du sens. Mais pour une équipe de 15 personnes gérant 40 microservices, la surcharge opérationnelle engloutit le bénéfice supposé.

Basecamp et Shopify ont tous deux publiquement décrit le fait de rester dans, ou de revenir à, un modèle de «monolithe majestueux» plutôt que de se diviser en dizaines de services, citant le même raisonnement : la plupart de leurs chemins de requête n'ont pas besoin de mise à l'échelle indépendante.

À quoi ressemble réellement un monolithe modulaire

Un monolithe modulaire n'est pas «abandonner et écrire du code spaghetti dans un seul fichier». C'est une application unique déployable organisée en interne en paquets ou modules avec des frontières explicites et appliquées, généralement un module par domaine métier (facturation, inventaire, notifications). Chaque module possède sa propre couche d'accès aux données et expose une interface interne étroite aux autres modules.

Cela procure la plupart des avantages que les gens voulaient initialement des microservices, sans la taxe des systèmes distribués : aucune latence réseau entre les modules, aucune gestion d'échec partiel pour des appels qui étaient auparavant des appels de fonction.

Quand les microservices justifient encore leur coût

L'argument honnête en faveur des microservices existe toujours. Si un composant doit évoluer indépendamment 50 fois plus que le reste du système, le séparer est la bonne décision. La règle pratique qui a émergé parmi les équipes en 2026 : par défaut, optez pour un monolithe modulaire, et n'extrayez un service que lorsque vous pouvez nommer l'exigence spécifique de mise à l'échelle, de langage ou d'autonomie d'équipe qui le justifie.

Conclusions pour les équipes qui reconsidèrent leur architecture

Si votre équipe compte environ 50 ingénieurs ou moins et exécute plus d'une poignée de services, auditez quels services ont réellement des besoins de mise à l'échelle indépendants par rapport à ceux qui ont été divisés pour des raisons organisationnelles qui ne s'appliquent plus. Conservez les frontières de modules ; supprimez les sauts réseau.