Microservices ou architecture monolithique : choisir l'architecture adaptée à votre projet

Introduction

Tout projet logiciel commence par la même question, d’une simplicité trompeuse : comment devons-nous structurer cela ? Si vous trouvez la bonne réponse, votre équipe livrera plus rapidement, évoluera en douceur et gardera la tête froide. Si vous vous trompez, vous passerez des années à démêler le fouillis que vous aurez vous-même créé.

Le débat opposant l’architecture monolithique aux microservices fait rage depuis plus d’une décennie, et en 2026, il est plus nuancé que jamais. L’engouement initial pour les microservices promettait une évolutivité infinie et une autonomie totale des équipes — puis vint le retour de bâton, avec des entreprises de renom revenant publiquement sur des décompositions trop zélées. Amazon Prime Video a réintégré son service de surveillance dans une architecture monolithique en 2023, réduisant ainsi ses coûts de 90 %. L’équipe SnapCI de ThoughtWorks a, comme on le sait, fusionné ses microservices pour former à nouveau un monolithe après avoir lutté pendant des mois contre des frontières de service instables.

Pourtant, rejeter d’emblée les microservices est tout aussi dangereux. Des entreprises comme Netflix, Spotify et Uber exploitent avec succès des milliers de microservices en production, effectuant des déploiements plusieurs centaines de fois par jour. En réalité, aucune de ces deux approches n’est universellement « meilleure » : chacune résout des problèmes différents à différentes étapes du cycle de vie d’un projet. Cet article vous propose un cadre clair et pratique pour déterminer quelle architecture convient à votre projet, à votre équipe et à votre calendrier, sans céder au battage médiatique.

Qu’est-ce qu’un monolithe, au juste ?

Avant de prendre parti, définissons précisément nos termes. Une architecture monolithique signifie que l’intégralité de votre application — interface utilisateur, logique métier, accès aux données — réside dans une seule unité déployable. Lorsque vous souhaitez publier une modification, vous compilez et déployez l’ensemble. Les architectures monolithiques ne sont pas automatiquement « mauvaises » ni mal structurées. Un monolithe bien conçu utilise des modules internes, des interfaces claires et la séparation des préoccupations. Imaginez-le comme un immeuble d’appartements bien organisé : tout est sous un même toit, mais chaque pièce a une fonction bien définie.

Le problème survient lorsque la discipline vient à manquer. En l’absence de barrière physique que constituent les limites du réseau entre les composants, il devient d’une facilité enfantine de contourner les interfaces des modules. Un développeur soumis à la pression des délais peut importer une classe depuis un module sans aucun rapport, introduire une table de base de données partagée qui couple deux domaines entre eux, ou ajouter une dépendance circulaire qui transforme la base de code en ce que Martin Fowler appelle une « grosse boule de boue ». Cette érosion est progressive : on ne la remarque pas au cours du premier mois, mais au bout de trois ans, chaque modification nécessite d’intervenir sur cinq modules différents, et l’exécution des suites de tests prend 45 minutes.

Les architectures monolithiques vous obligent également à évoluer horizontalement en tant qu’unité unique. Si votre module de traitement des paiements est saturé pendant le Black Friday, vous ne pouvez pas faire évoluer uniquement ce module : vous devez faire évoluer l’ensemble de l’application, y compris la page de connexion et le panneau d’administration que personne n’utilise. C’est inefficace et, à grande échelle, coûteux.

Que sont réellement les microservices ?

Les microservices adoptent l’approche inverse : chaque fonctionnalité métier s’exécute en tant que service indépendant, avec sa propre base de code, sa propre base de données et son propre pipeline de déploiement. Les services communiquent via des API bien définies — généralement HTTP REST ou la messagerie asynchrone — et aucun service ne peut accéder directement à la base de données d’un autre service.

La définition canonique a été formulée par James Lewis et Martin Fowler dans leur article de 2014 qui a catalysé le mouvement : les microservices constituent « une approche consistant à développer une application unique sous la forme d’une suite de petits services, chacun s’exécutant dans son propre processus et communiquant via des mécanismes légers ». Les mots clés sont petit, indépendant et léger. Un microservice doit être suffisamment petit pour qu’une seule équipe puisse en assumer la responsabilité de bout en bout, suffisamment indépendant pour être déployé sans coordination avec d’autres équipes, et communiquer via des protocoles simples plutôt que par le biais de middlewares complexes.

Cette architecture est née d’un réel problème rencontré par des entreprises comme Amazon, où, au début des années 2000, la base de code monolithique était devenue si volumineuse qu’un seul déploiement nécessitait la coordination de dizaines d’équipes. Jeff Bezos a rendu célèbre son « mandat API » vers 2002 : toutes les équipes devaient exposer leurs données et leurs fonctionnalités via des interfaces de service, sans exception. Cela a imposé la modularité par le biais de la structure organisationnelle — l’essence même de la loi de Conway mise en pratique.

Netflix a suivi une voie similaire, passant d’une application monolithique hébergée en centre de données à des centaines de microservices fonctionnant sur AWS, après une corruption catastrophique de la base de données en 2008 qui avait paralysé son service d’expédition de DVD pendant trois jours. L’entreprise a mis en open source une grande partie de ses outils (Eureka, Hystrix, Zuul), qui sont devenus la référence pour les premiers adeptes des microservices.

Les véritables compromis

Le cadre de analyse des compromis liés aux microservices de Martin Fowler identifie trois avantages et trois inconvénients ; il est essentiel de les comprendre avant de prendre toute décision architecturale.

Avantages :

Premièrement, des limites de modules bien définies. Lorsque les modules sont séparés par des appels réseau, le coût lié au contournement d’une interface est immédiatement visible : cela nécessite un nouveau point de terminaison API, une authentification et de la documentation. Cette friction empêche l’érosion progressive qui afflige les architectures monolithiques. Comme le dit Fowler, « l’utilisation des microservices augmente la probabilité d’obtenir une meilleure modularité ».

Deuxièmement, un déploiement indépendant. Chaque service peut être déployé selon son propre calendrier. Un correctif de sécurité critique pour votre service d’authentification ne nécessite pas de reconstruire et de redéployer l’intégralité de votre plateforme de commerce électronique. Cela réduit considérablement la portée de chaque changement et permet des cycles de mise en production plus rapides.

Troisièmement, la diversité technologique. À chaque problème correspond un outil adapté. Votre moteur de recommandation pourrait tirer parti de l’écosystème d’apprentissage automatique de Python, tandis que votre système de traitement des paiements nécessite la sécurité de types offerte par Go ou Rust. Les microservices permettent à chaque équipe de choisir le langage, le framework et la base de données les mieux adaptés à son problème spécifique.

Coûts :

Premièrement, les difficultés liées à la distribution. Les appels réseau sont d’un ordre de grandeur plus lents que les appels de méthode intra-processus. Chaque communication entre services doit gérer les délais d’expiration, les nouvelles tentatives, les disjoncteurs de circuit et les défaillances partielles. Ce qui n’était autrefois qu’un simple appel de fonction devient une danse complexe d’ingénierie des systèmes distribués.

Deuxièmement, la cohérence éventuelle. Dans une architecture monolithique, une seule transaction de base de données peut garantir la cohérence entre vos systèmes de commande et de gestion des stocks. Avec les microservices, chaque service dispose de sa propre base de données ; vous devez donc concevoir votre système en tenant compte de la cohérence éventuelle — un domaine où les données peuvent être temporairement désynchronisées, et où votre logique métier doit gérer cela avec souplesse. C’est véritablement difficile à maîtriser.

Troisièmement, la complexité opérationnelle. Déployer dix services n’est pas dix fois plus difficile que d’en déployer un seul — cela peut l’être cent fois plus. Vous avez besoin d’une orchestration de conteneurs (Kubernetes), d’une découverte de services, d’une journalisation centralisée, d’un traçage distribué, de pipelines CI/CD automatisés, et d’une équipe qui maîtrise tout cela. Sans ces fondements opérationnels, les microservices deviennent un cauchemar.

Quand les microservices ont du sens

Les microservices prennent tout leur sens dans des conditions spécifiques. La première est la taille de l’équipe. Lorsque vous avez plus de 15 à 20 développeurs travaillant sur une seule base de code, la charge de coordination grimpe en flèche. Les conflits de fusion se multiplient. Des files d’attente de déploiement se forment. Les microservices vous permettent de diviser l’organisation en petites équipes autonomes, chacune étant responsable de ses services de bout en bout — un modèle qu’Amazon appelle les « équipes deux pizzas ».

La deuxième condition concerne les besoins de mise à l’échelle indépendants. Si certaines parties de votre système subissent une charge disproportionnée, les isoler dans des services distincts vous permet de faire évoluer la capacité précisément là où c’est nécessaire. Un service de transcodage vidéo qui sollicite le processeur à 100 % pendant les heures de pointe n’a pas besoin d’entraîner dans son sillage votre service de profils utilisateur.

La troisième condition concerne les domaines bien cernés. Sam Newman, auteur de Building Microservices, souligne que se tromper sur les limites des services coûte cher. L’équipe SnapCI de ThoughtWorks a d’abord développé un ensemble de microservices, avant de se rendre compte que leurs limites ne correspondaient pas au domaine du problème réel, et a passé des mois à lutter contre les modifications impliquant plusieurs services. Elle a finalement tout fusionné à nouveau en un monolithe, stabilisé le modèle de domaine, puis extrait les services par la suite — avec succès, cette fois-ci. Si vous en êtes encore à découvrir ce qu’est réellement votre produit, ne le décomposez pas tout de suite.

Une règle empirique utile : presque toutes les réussites en matière de microservices commencent par un monolithe devenu trop volumineux et qui a été décomposé intentionnellement. Presque tous les projets de microservices « greenfield » que j’ai vus ont fini par rencontrer de graves difficultés. Fowler appelle cela le « Monolith First » (le monolithe d’abord) et, bien que ce ne soit pas une loi absolue, ce schéma est suffisamment frappant pour être considéré comme la stratégie par défaut.

Quand opter pour un monolithe

Pour la plupart des projets — en particulier les nouveaux —, un monolithe n’est pas un compromis ; c’est le choix optimal. Les start-ups qui développent leur premier produit ne disposent ni de l’effectif nécessaire, ni de la maturité opérationnelle, ni de la clarté métier suffisante pour justifier le recours aux microservices. Un monolithe bien structuré vous permet d’itérer rapidement, de refactoriser librement et de cerner votre activité avant d’investir dans la distribution.

Même à une échelle surprenante, les monolithes peuvent fonctionner. Shopify exploite l’un des plus grands monolithes Ruby on Rails au monde, traitant des milliards de dollars de transactions. L’entreprise a massivement investi dans la modularisation au sein du monolithe : des limites de modules clairement définies, des modèles d’accès à la base de données rigoureux et un pipeline d’intégration continue (CI) sophistiqué. Son approche prouve qu’il est possible d’obtenir une forte modularité sans frontières réseau si votre culture d’ingénierie l’impose.

Pour les PME belges qui développent des outils internes, des portails clients ou des plateformes B2B, un monolithe est presque toujours le bon point de départ. Votre équipe est probablement de petite taille. Votre domaine d’activité évoluera à mesure que vous tirerez des enseignements des utilisateurs. La charge opérationnelle liée à Kubernetes, aux maillages de services et au traçage distribué vous ralentira davantage que l’élégance architecturale ne vous fera gagner en rapidité. Commencez par construire un monolithe propre et modulaire. Extrayez les services plus tard, lorsque — et seulement lorsque — vous aurez une raison claire de le faire.

Le monolithe modulaire : un juste milieu pragmatique

Si le choix binaire entre monolithe et microservices semble contraignant, c’est parce qu’il existe une troisième option qui a connu un essor considérable ces dernières années : le monolithe modulaire.

Un monolithe modulaire est structuré en interne comme un ensemble de microservices — chaque domaine métier possède son code, ses tables de base de données et son interface publique — mais il s’exécute comme un seul processus déployable. Les frontières sont imposées par des conventions et des outils (tests d’architecture, vérifications des dépendances entre modules en CI) plutôt que par la topologie du réseau. Cela permet une séparation claire des préoccupations sans la charge opérationnelle des systèmes distribués.

L’avantage décisif réside dans le fait que la refactorisation des limites est peu coûteuse. Dans une architecture à microservices, le déplacement d’une fonctionnalité d’un service à un autre implique une migration en plusieurs étapes, avec gestion des versions d’API, synchronisation des données et déploiements coordonnés. Dans un monolithe modulaire, il s’agit d’une simple refactorisation du code. Lorsque vous en êtes encore à découvrir votre domaine — ce qui, pour la plupart des projets, dure bien plus longtemps que quiconque ne veut bien l’admettre —, cette flexibilité est inestimable.

Le monolithe modulaire sert également de tremplin idéal vers les microservices. Une fois que les limites se sont stabilisées et qu’un module spécifique nécessite véritablement une évolutivité indépendante ou une pile technologique différente, vous extrayez uniquement ce module pour en faire un service distinct. Le reste du système reste monolithique, et vous n’avez ajouté que la complexité dont vous avez réellement besoin. C’est ainsi que fonctionne Shopify, et c’est ainsi que de nombreuses équipes pragmatiques choisissent de travailler en 2026.

Le cadre décisionnel

Voici un cadre pratique pour prendre cette décision, adapté à partir des connaissances combinées de Fowler et Newman, ainsi que de nombreuses années d’expérience dans le secteur :

Commencez par un monolithe si :

• Votre équipe compte moins de 15 développeurs
• Vous développez un nouveau produit et en êtes encore à découvrir le domaine
• Vos besoins en matière d’évolutivité sont prévisibles et modérés
• Vous ne disposez pas d’une infrastructure opérationnelle (Kubernetes, pipelines CI/CD, surveillance)
• Vous devez livrer rapidement et itérer en fonction des retours des utilisateurs

Envisagez un monolithe modulaire si :

• Votre équipe s’agrandit mais n’a pas encore atteint l’échelle des microservices
• Vous disposez de domaines métier clairement définis mais souhaitez simplifier le déploiement
• Vous souhaitez vous préparer à une future extraction sans payer dès maintenant le prix fort des systèmes distribués
• Votre application est intrinsèquement complexe mais n’atteint pas une échelle massive

Extrayez des microservices si :

• Certains modules ont réellement besoin d’une évolutivité indépendante
• Différentes parties du système tirent profit de piles technologiques différentes
• Plusieurs équipes doivent se déployer de manière indépendante selon des calendriers différents
• Vous disposez de limites de domaine claires et stables
• Votre maturité opérationnelle vous permet de gérer des systèmes distribués

Commencez par des microservices si :

• Votre équipe possède une expérience significative des microservices
• Vous remplacez un système hérité bien compris, aux limites stables
• Votre organisation est déjà structurée autour d’équipes autonomes
• Le domaine est bien établi et peu susceptible d’évoluer de manière significative

Un modèle mental utile : le coût d’extraction d’un service d’un monolithe bien structuré est inférieur à celui de la fusion de microservices mal délimités. Il est presque toujours plus prudent de privilégier une approche plus simple au départ.

Contexte belge concret

Pour les entreprises belges, le choix architectural implique des considérations spécifiques. L’écosystème technologique belge est dominé par les PME, dont beaucoup gèrent de petites équipes de développement composées de trois à dix personnes. La complexité opérationnelle des microservices — gestion des clusters Kubernetes, des maillages de services, du traçage distribué et de l’intégration et du déploiement continus (CI/CD) multi-services — nécessite des compétences coûteuses et rares sur le marché belge.

Cela dit, les entreprises belges actives dans la logistique, la fintech et le commerce électronique sont souvent confrontées à de réels défis d’évolutivité. Une plateforme logistique bruxelloise assurant le suivi en temps réel de milliers d’envois transitant par le port d’Anvers pourrait réellement tirer profit de l’extraction de ses services de suivi et de notification en tant que composants indépendants. L’essentiel est de laisser les besoins métier dicter l’architecture, et non de laisser l’enthousiasme pour l’architecture dicter les choix métier.

La Belgique possède également une solide tradition d’ingénierie pragmatique. L’approche « d’abord un monolithe modulaire, puis extraction si nécessaire » s’inscrit parfaitement dans la culture d’entreprise belge, qui privilégie les investissements mesurés et réfléchis plutôt que de courir après les tendances de la Silicon Valley. C’est une approche qui respecte les contraintes budgétaires tout en laissant la porte ouverte à une croissance future.

Points clés à retenir

L’architecture suit l’organisation, et non l’inverse. La structure de votre système doit refléter celle de votre équipe : c’est la loi de Conway, et l’ignorer mène tout droit à l’échec architectural.

Le « monolithe d’abord » n’est pas un compromis ; c’est une stratégie. Presque toutes les implémentations réussies de microservices ont commencé par un monolithe bien structuré. Commencer par des microservices sur un projet entièrement nouveau est l’un des moyens les plus sûrs de se mettre dans une impasse en sur-ingénierie.

Le monolithe modulaire est votre meilleur allié. Vous pouvez bénéficier de 80 % des avantages des microservices (limites claires, autonomie des équipes, code facile à maintenir) pour seulement 20 % du coût opérationnel. C’est la voie pragmatique à suivre pour la plupart des PME belges.

Extrayez des services pour une raison valable, pas simplement parce que c’est à la mode. L’évolutivité indépendante, la diversité technologique et l’autonomie des équipes sont des raisons valables. « Parce que Netflix le fait » n’en est pas une. Chaque service extrait ajoute une complexité opérationnelle qui doit être justifiée par un avantage métier clair.

Les limites du domaine sont primordiales. Se tromper sur les limites des services coûte plus cher que n’importe quel choix architectural. Consacrez du temps à comprendre votre domaine — utilisez la conception orientée domaine (Domain-Driven Design), l’event storming, ou toute autre méthode qui fonctionne — avant de procéder à la distribution.

Prochaines étapes

Cette semaine : auditez votre architecture actuelle. Si vous disposez d’une architecture monolithique, évaluez honnêtement sa modularité. Existe-t-il des limites de modules claires et documentées ? Un nouveau développeur peut-il comprendre la structure du code en une journée ? Si ce n’est pas le cas, commencez par modulariser en interne avant d’envisager l’extraction.

Ce mois-ci : menez un exercice de cartographie du domaine avec votre équipe. Identifiez vos contextes délimités à l’aide d’ateliers d’Event Storming ou de Domain-Driven Design. Le résultat n’est pas du code : c’est une compréhension commune de l’emplacement de vos limites naturelles.

D’ici trois mois : si vous avez identifié un module qui nécessite véritablement un déploiement ou une évolutivité indépendants, planifiez une seule extraction. Extrayez un service, stabilisez-le et tirez les leçons de cette expérience opérationnelle avant d’en extraire un deuxième. Résistez à la tentation de tout extraire d’un seul coup.

D’ici six mois : Évaluez. L’extraction a-t-elle réellement amélioré la vitesse de déploiement ou l’évolutivité ? La charge opérationnelle a-t-elle justifié ce changement ? Adaptez votre stratégie en fonction de données réelles, et non d’un dogme architectural.

Besoin des conseils d’un expert ? Le choix de la bonne architecture est l’une des décisions les plus cruciales en génie logiciel. Chez Omnistack, nous aidons les entreprises belges à concevoir, construire et faire évoluer des architectures logicielles adaptées à leur équipe, à leur budget et à leurs ambitions. Contactez-nous pour discuter de votre projet.

Conclusion

Le débat « monolithique contre microservices » a évolué d’une guerre de religion vers une discussion technique concrète, et c’est une bonne chose. En 2026, les meilleures équipes ne sont pas celles qui choisissent un camp et le défendent — ce sont celles qui comprennent les compromis et font des choix réfléchis en fonction de leur contexte spécifique.

Commencez par la simplicité. Intégrez la modularité dès le premier jour, même si tout s’exécute dans un seul processus. Laissez votre architecture évoluer au fur et à mesure que votre équipe et votre compréhension s’enrichissent. Extrayez des services lorsque vous en avez une raison claire, pas avant. Cette approche peut ne pas paraître aussi impressionnante lors des conférences, mais elle permet de livrer des logiciels qui fonctionnent, qui s’adaptent lorsque cela est nécessaire, et qui maintiennent votre équipe productive et satisfaite.

Après tout, la meilleure architecture n’est pas celle qui comporte le plus de services ni celle dont le schéma est le plus épuré. C’est celle qui vous aide à apporter de la valeur à vos utilisateurs, aujourd’hui comme demain.