Choisir entre un monolithe modulaire et des microservices ressemble souvent à un débat technique. Pourtant, ça commence rarement par la technique. La vraie question, c'est l'organisation, les contraintes d'exploitation, et le problème concret que l'architecture doit résoudre.
Lancer une dizaine de services, un courtier de messages et un orchestrateur avant d'avoir vraiment trouvé son marché peut donner l'impression de préparer l'avenir. En pratique, ça multiplie surtout les déploiements, les points de panne et le nombre de choses à surveiller. Le résultat ressemble parfois à un monolithe distribué : les composants restent fortement liés, mais chaque échange passe désormais par le réseau.
Dans beaucoup de projets, un monolithe modulaire bien conçu est un point de départ plus simple à tenir. Ça ne veut pas dire que les microservices sont une mauvaise idée. Juste qu'ils doivent répondre à un besoin clair, et que leur coût doit être comparé à la valeur qu'ils apportent réellement.
Voici un cadre pratique pour distinguer les deux approches, poser les bonnes questions avant une extraction, et garder une trajectoire d'évolution sans tout réécrire.
Commencer par le problème, pas par l'architecture
La question utile n'est pas seulement : « Faut-il choisir les microservices ou le monolithe ? » Elle est plus directe : quel problème opérationnel ou organisationnel cette séparation doit-elle régler, et quel prix sommes-nous prêts à payer ?
Cette façon de poser le problème évite de transformer une décision d'architecture en préférence personnelle. Une architecture n'est pas meilleure parce qu'elle utilise plus de composants, ni parce qu'elle ressemble à celle d'une grande plateforme. Elle est meilleure si elle aide l'équipe à livrer un produit fiable, dans les limites de budget, de compétences et de délai.
Deux modèles de déploiement différents
Un monolithe modulaire est une application livrée comme une seule unité, organisée en modules. Chaque module a ses responsabilités et des règles claires. Les autres modules passent par son interface publique plutôt que d'accéder à ses détails internes. Les échanges se font à l'intérieur du même processus.
Les microservices, eux, sont plusieurs unités de déploiement indépendantes. Chaque service peut avoir son propre rythme de livraison et, idéalement, une responsabilité exclusive sur ses données. Les communications passent par des API ou des événements sur le réseau.
La différence ne se résume donc pas au nombre de répertoires. Elle touche le déploiement, l'exploitation, et la façon dont les équipes se coordonnent. Dans un monolithe modulaire, une mise en production concerne l'application entière, même si une partie des changements ne touche qu'un module. Avec des services indépendants, les mises en production peuvent être séparées, mais elles exigent aussi plus d'automatisation et plus de surveillance.
Et surtout : un monolithe modulaire n'est pas « un vieux monolithe » renommé en dossiers. La tenue vient de la discipline : responsabilités explicites, dépendances maîtrisées, limites vérifiées. Sans ça, les modules deviennent des conventions que le prochain changement pressé finira par contourner.
Le monolithe distribué, piège de la transition prématurée
Dans les projets lancés trop tôt en microservices, on sépare souvent le code... sans séparer vraiment les responsabilités. Les services sont mis à part dans le dépôt, mais ils partagent les mêmes données, dépendent les uns des autres pour chaque évolution, et doivent être déployés ensemble. On ajoute alors la complexité du réseau sans gagner l'autonomie attendue.
C'est particulièrement dur pour une petite équipe. Il faut gérer des versions d'API, des secrets et des configurations, comprendre des erreurs qui se trouvent réparties sur plusieurs composants, et maintenir des chaînes de déploiement distinctes. Si une modification simple réclame toujours une coordination entre services, la séparation n'a pas cassé le couplage : elle l'a rendu juste plus difficile à voir et à corriger.
Pour aller plus loin sur la définition de responsabilités métier cohérentes, vous pouvez consulter notre guide sur le découpage d'une application par domaines. Une frontière bien comprise aide autant à modulariser en interne qu'à préparer une extraction plus tard.
Comparer les bénéfices et les coûts réels
Les microservices promettent une forme d'indépendance. Le problème, c'est que cette indépendance a un coût, et qu'elle n'est pas toujours utile à l'échelle de votre produit. Avant de choisir, comparez les bénéfices attendus aux coûts d'exploitation qui apparaissent dès que l'application est distribuée.
Ce que les microservices peuvent réellement améliorer
Une séparation en services a du sens quand elle répond à une contrainte que le monolithe ne traite plus bien :
- Des équipes qui doivent livrer séparément. Si deux équipes se bloquent parce qu'elles doivent déployer ensemble ou toucher aux mêmes composants, une frontière de service peut réduire cette coordination.
- Des profils de charge très différents. Un traitement peut nécessiter cinquante instances quand le reste de l'application tourne à deux. Isoler cette charge évite de dimensionner toute la plateforme pour le cas le plus coûteux.
- Une exigence d'isolation des pannes. Un composant critique (paiements, import massif de données...) peut devoir échouer sans entraîner l'indisponibilité du reste du produit.
- Des contraintes de sécurité ou de conformité. Certaines données réclament des droits d'accès, des journaux d'audit, ou une isolation particulière. Dans un contexte européen, les exigences liées au RGPD doivent se traduire par des choix concrets : accès, conservation, traçabilité.
- Un besoin technologique distinct et démontré. Un calcul intensif peut justifier un langage ou un environnement différent si un test montre un gain réel. Une préférence d'équipe, seule, ne suffit généralement pas.
Dans tous les cas, posez le même filtre : l'indépendance obtenue vaut-elle vraiment la complexité ajoutée ? Si votre objectif est de réduire la durée des mises en production, vérifiez si le blocage vient du couplage technique, ou plutôt d'un processus de validation trop lourd.
Les coûts que l'on oublie dans les comparatifs
Passer aux microservices introduit des contraintes qu'on ne voit pas (ou moins) dans un traitement monolithique.
Réseau et pannes partielles. Un appel qui "marchait" localement devient un appel distant. Vous devez gérer les délais, les tentatives, les interruptions et les réponses incomplètes. Une requête qui traversait auparavant plusieurs fonctions peut maintenant dépendre d'un service indisponible. Les reprises automatiques demandent d'être bien conçues : mal réglées, elles amplifient la panne au lieu de la contenir.
Cohérence des données. Une transaction ACID sur plusieurs domaines ne se transpose pas telle quelle entre services. Il faut parfois accepter une cohérence éventuelle, construire une saga, ou prévoir des opérations compensatoires. Ce n'est pas juste un choix d'infrastructure : c'est un changement de comportement produit.
Observabilité. Pour retrouver l'origine d'une erreur, il faut corréler les journaux, suivre des métriques par service, et avoir des traces distribuées. Sans ça, déboguer une requête qui passe par plusieurs composants devient une enquête. Notre méthode pour améliorer l'observabilité d'une application détaille les signaux à mettre en place avant d'ajouter des composants.
Déploiement et exploitation. Chaque service requiert une chaîne de livraison, des configurations, des secrets et une stratégie de versionnement. L'automatisation aide, mais ne fait pas disparaître le travail. Il faut aussi des compétences et du temps pour maintenir.
Charge cognitive. Il faut comprendre plus de composants, leurs contrats et leurs dépendances. Les frontières créent aussi un coût de coordination entre équipes : si une modification traverse cinq services, les déploiements "indépendants" ne rendent pas automatiquement le changement facile.
Ces coûts sont acceptables s'ils achètent un bénéfice mesurable. Sinon, ils finissent par devenir une dette payée à chaque incident et à chaque évolution.
Construire un monolithe modulaire qui peut Ă©voluer
Un monolithe modulaire, c'est un choix actif, pas une étape provisoire à abandonner dès que le produit grossit. Il peut rester durable si ses frontières sont cohérentes et si les dépendances sont contrôlées. Il aide aussi à apprendre où se trouvent les bons découpages avant qu'ils ne soient trop coûteux à modifier.
Des modules alignés sur les responsabilités métier
Un module doit correspondre à un contexte fonctionnel reconnaissable : facturation, stock, utilisateurs, expédition, par exemple. L'idée rejoint la conception pilotée par le domaine, mais l'objectif n'est pas de plaquer un vocabulaire théorique sur le code. C'est de rendre explicite qui possède une règle métier, et qui a le droit de la modifier.
Concrètement, chaque module devrait :
- exposer un contrat public utilisé par les autres modules ;
- garder une partie interne non accessible depuis l'extérieur ;
- porter ses règles métier, et autant que possible ses données ;
- produire des événements internes quand d'autres domaines doivent réagir à un changement.
Un module de facturation ne devrait pas être modifié directement par l'expédition juste parce qu'il manque un champ. L'expédition doit demander (ou recevoir) l'information via une interface explicite. Ainsi, les dépendances deviennent visibles, et changer le stockage (ou préparer une extraction plus tard) devient plus simple.
Interdire l'accès direct aux données d'un autre module
Partager des tables est souvent le moyen le plus rapide d'annuler les frontières. Si un module fait des jointures sur des tables internes d'un autre, il dépend de la structure de ces tables, même si le code est rangé proprement.
Ça ne veut pas dire qu'il faut interdire toute lecture entre domaines. Ça veut dire que les demandes doivent passer par un contrat défini : le module propriétaire peut ainsi faire évoluer ses données sans casser ses consommateurs. Au début, la règle peut sembler contraignante. Mais elle évite surtout de transformer les détails de stockage en "API implicite", difficile à changer ensuite.
Les événements internes servent à réduire le couplage : quand un module annonce qu'un fait s'est produit (une facture a été émise, une commande expédiée), les autres modules peuvent réagir sans que le producteur doive connaître leur existence. Dans un monolithe, ces événements peuvent rester synchrones ou être traités en arrière-plan selon le besoin. Il n'est pas nécessaire d'ajouter tout de suite un courtier de messages.
Faire respecter les frontières par les outils
Une convention non vérifiée finit souvent par être contournée sous la pression de "livrer vite". Les règles d'architecture doivent donc être contrôlées automatiquement pendant l'intégration continue.
Par exemple, dans un projet Laravel utilisant Pest et un outil de vérification architecturale, vous pouvez interdire aux modules d'utiliser les détails internes les uns des autres :
arch('La facturation ne dépend pas des éléments internes de l'expédition')
->expect('App\\Modules\\Billing')
->not->toUse('App\\Modules\\Shipping\\Internal');
arch('L'expédition ne dépend pas des éléments internes de la facturation')
->expect('App\\Modules\\Shipping')
->not->toUse('App\\Modules\\Billing\\Internal');
Le principe reste le même au-delà de Laravel : l'outil compte moins que le contrôle automatisé. Deptrac, des règles de dépendance ou des tests d'architecture peuvent faire échouer la chaîne d'intégration continue si une limite est franchie. Tant que ce n'est pas vérifié, la frontière n'est qu'une suggestion.
Cette rigueur garde une porte ouverte : si une raison concrète apparaît plus tard, le contrat public du module pourra évoluer vers une API ou des échanges d'événements. L'extraction ne sera pas "gratuite", mais elle sera moins risquée qu'un découpage fait au milieu d'un code déjà entremêlé.
DĂ©cider quand extraire un service
Une extraction n'est pas une récompense de croissance, ni une étape obligatoire. Elle doit répondre à un besoin constaté. Avant de déplacer un module vers un service indépendant, posez les questions ci-dessous avec des exemples récents, pas avec des scénarios "au cas où".
| Question | Si la réponse est non |
|---|---|
| Une équipe doit-elle déployer sans coordonner chaque livraison avec les autres ? | Le service n'est probablement pas nécessaire à ce stade. |
| Le composant a-t-il une charge ou un profil de montée en puissance vraiment différent ? | Dimensionner le monolithe dans son ensemble sera souvent moins cher. |
| Y a-t-il une exigence d'isolation des pannes, de sécurité ou de conformité ? | Des modules bien séparés peuvent suffire. |
| L'observabilité et l'automatisation des déploiements sont-elles suffisamment en place ? | Améliorez-les d'abord : la charge opérationnelle risque de dépasser le bénéfice. |
| La frontière métier est-elle stable et comprise par l'équipe ? | Une extraction prématurée peut figer un mauvais découpage. |
La dernière question est souvent la plus sous-estimée. Dans un monolithe, une frontière mal dessinée se corrige avec une refactorisation. Entre services, une frontière incorrecte peut impliquer une migration de données, des changements de contrats et une période de compatibilité. Le coût du retour en arrière n'est pas le même.
Mesurer les frictions avant de décider
Pour éviter une décision "au ressenti", regardez quelques indicateurs simples :
- fréquence des situations où une équipe attend une autre pour livrer ;
- délai entre la validation d'un changement et sa mise en production ;
- composants qui consomment le plus de ressources ou qui saturent régulièrement ;
- incidents où une fonction entraîne la panne d'une autre ;
- changements qui touchent souvent les mêmes frontières métier.
Ces mesures ne donnent pas une réponse automatique. Elles permettent de distinguer un problème récurrent d'une inquiétude abstraite. Si les déploiements sont bloqués par une validation manuelle partagée, extraire un service ne résoudra probablement pas le fond du problème. En revanche, si un traitement d'import monopolise les ressources et dégrade l'expérience pour tout le monde, l'isoler peut être pertinent.
Faire Ă©voluer l'architecture progressivement
Une trajectoire pragmatique tient en quatre Ă©tapes :
- Démarrer avec des modules clairement séparés. Définir contrats et responsabilités métier avant que les dépendances ne se multiplient.
- Vérifier les règles automatiquement. Ajouter des tests de frontières dans la chaîne de livraison.
- Observer les limites rencontrées. Suivre déploiements, blocages entre équipes, performances et incidents.
- Extraire uniquement le module qui répond à un besoin établi. Son contrat devient une API ou un ensemble d'événements ; les données sont transférées selon une stratégie planifiée.
L'extraction peut s'appuyer sur le modèle du strangler : la nouvelle implémentation prend progressivement en charge une partie des flux pendant que l'ancien reste en place. Ça limite le risque d'une réécriture complète, mais ça demande une période de coexistence et un plan de bascule. C'est particulièrement utile quand on ne peut pas remplacer le système existant en une seule livraison.
Éviter les faux bons découpages
Trois erreurs reviennent souvent.
La première : partager une base de données entre services tout en prétendant qu'ils sont indépendants. Un stockage commun peut dépanner pendant une transition. Mais si ça devient la norme, les services restent couplés par leurs schémas et leurs requêtes.
La deuxième : créer des services trop petits. Multiplier les unités de déploiement pour chaque fonction augmente les coûts de coordination, parfois au point de produire des nanoservices. Une bonne frontière correspond à une responsabilité qui mérite vraiment son autonomie, pas à une classe ou une fonctionnalité isolée.
La troisième : découper le domaine trop tôt. Les frontières métier se confirment en observant ce qui change dans les règles, les données qui sont réellement "possédées" et les équipes qui prennent les décisions. Un diagramme aide à formuler une hypothèse, mais il ne prouve pas que la frontière restera juste.
Enfin, il faut tenir compte de l'organisation. Si une équipe possède plusieurs services et que d'autres dépendent de chacun de ses changements, l'autonomie "théorique" ne devient pas forcément une autonomie réelle. Les frontières techniques et les responsabilités d'équipes doivent être compatibles, sans copier mécaniquement l'organigramme.
Conclusion
Pour la plupart des produits, le choix le plus sain consiste à démarrer avec un monolithe modulaire, des contrats explicites, et des frontières réellement contrôlées (pas juste "promises"). Ça limite les coûts d'exploitation tout en gardant la possibilité d'extraire un service quand le besoin apparaît.
Les microservices sont un outil utile, mais ils s'achètent avec une complexité distribuée. Avant de les adopter, assurez-vous que vous savez précisément quelle friction ils doivent supprimer, comment vous mesurerez le résultat, et si votre équipe peut assumer l'exploitation en plus.
Commencez par mesurer vos blocages réels, puis comparez-les aux critères de cet article. C'est une décision plus solide que "suivre la mode", et une meilleure base pour faire évoluer votre architecture sans tout reconstruire.