Architecture modulaire : structurer une application pour la scalabilité
Obtenez un résumé intelligent et des insights personnalisés
Une architecture modulaire application découpe une application en modules indépendants aux frontières claires. Elle ne demande pas forcément de distribuer le système en microservices. Le modular monolith applique ce principe à l’intérieur d’un seul déploiement. Il combine la simplicité opérationnelle du monolithe et la clarté organisationnelle des microservices.
Beaucoup d’équipes techniques posent la question au mauvais moment. En effet, elles choisissent entre monolithe et microservices avant même d’avoir structuré leurs domaines métier. Le symptôme est toujours le même : un simple correctif sur un module met en risque tout le reste de l’application. De plus, chaque déploiement devient un événement redouté plutôt qu’une routine. Pourtant, il y a une troisième voie plus pragmatique. D’ailleurs, elle a fait ses preuves chez des acteurs comme Shopify. Découvrons les patterns de découpage à connaître et la méthode pour faire évoluer votre architecture sans tout reconstruire. AquilApp vous accompagne.
Faut-il vraiment choisir entre une architecture Monolithe vs microservices ?
Choisir entre monolithe et miccroservices pour votre architecture modulaire application est un faux dilemme.
Quelles sont les vraies limites du monolithe non structuré dans une architecture modulaire application ?
Un monolithe pose problème quand son code manque de frontières internes. Une équipe modifie une fonctionnalité de facturation. Elle casse sans le vouloir le module des notifications. Alors, le déploiement redevient risqué. En effet, chaque mise en production engage l’application entière, pas seulement la partie modifiée.
Le symptôme technique le plus visible est le temps de build et de test qui s’allonge avec la taille du code. Une équipe attend parfois plusieurs minutes, voire plusieurs dizaines de minutes, pour valider un changement mineur.
La deuxième conséquence touche la prise en main du projet par un nouveau développeur. Il doit comprendre l’ensemble du système avant de contribuer sereinement à une seule fonctionnalité. Pourquoi ? Parce que les frontières internes délimitent son périmètre.
Ce constat pousse beaucoup d’équipes vers les microservices par réflexe. Elles y voient une solution automatique au couplage. Pourtant, c’est une erreur de diagnostic fréquente. En effet, le problème vient rarement du monolithe en tant que tel. Il vient de l’absence de structure à l’intérieur de ce monolithe.
Que résolvent les microservices résolvent et combien coûtent-ils ?
Les microservices apportent un vrai bénéfice. À savoir : ils imposent une frontière physique entre les équipes et les déploiements. Ainsi, chaque service évolue et se déploie indépendamment. Cette isolation devient précieuse à grande échelle, quand plusieurs équipes travaillent en parallèle sur le même produit.
Néanmoins, ce bénéfice a un coût. Les microservices ajoutent de la complexité distribuée :
- Latence réseau
- Gestion des pannes partielles
- Cohérence des données entre services
- Et l’observabilité multipliée.
Martin Fowler alerte sur ce point depuis 2015 dans son article de référence MonolithFirst :
« démarrer un nouveau projet directement en microservices revient souvent à payer le coût de la distribution avant même de connaître les bonnes frontières entre services »
Dans un article complémentaire, Don’t start with a monolith, il précise que l’enjeu réel n’est pas le choix entre monolithe et microservices. Il s’agit plutôt de la capacité de l’équipe à construire un système bien structuré, quelle que soit l’architecture retenue.
Donc, le vrai choix d’architecture modulaire application n’oppose donc pas monolithe et microservices. Il oppose plutôt structure et une absence de structure. C’est ce constat qui a donné naissance au modular monolith.
Pourquoi le modular monolith est-il le meilleur choix ?
Un modular monolith est une application déployée comme un seul bloc. Cependant, elle est organisée en modules internes indépendants. Chacune possède ses propres données, sa propre logique métier et une interface publique claire vers les autres modules.
Qu’apporte concrètement le modular monolith ?
Cette approche conserve les avantages opérationnels du monolithe :
- Un seul processus à déployer
- Une seule base de code à surveiller.
Vous n’avez pas de réseau à traverser entre deux modules. Elle importe en parallèle la discipline des microservices. Donc, chaque module a une responsabilité précise. Elle n’accède pas directement aux données d’un autre module.
Le résultat : votre équipe garde la simplicité d’exploitation d’un monolithe. En plus, elle gagne la lisibilité et l’évolutivité d’un système découpé. Enfin, elle conserve la possibilité d’extraire un module en service indépendant plus tard, si un besoin métier ou technique le justifie vraiment.
Cas réel : comment Shopify a modularisé son monolithe Rails ?
Shopify illustre bien cette trajectoire. Selon Shopify Engineering, l’entreprise gère l’un des plus gros codebases Ruby on Rails au monde. À savoir : plus de 2,8 millions de lignes de code et plus de 500 000 commits.
Plutôt que de migrer vers les microservices, l’équipe technique a choisi de restructurer son monolithe en composants métier isolés. C’est un projet nommé en interne « Componentization ».
Donc, chaque composant charge explicitement les autres composants dont il dépend. Un composant ne peut plus accéder au code d’un autre sans passer par une interface publique déclarée. Cette discipline a permis à Shopify de continuer à déployer une application unique, tout en réduisant le couplage entre équipes.
Tableau comparatif des trois approches architecturales
| Critère | Monolithe classique | Modular monolith | Microservices |
|---|---|---|---|
| Déploiement | Un seul bloc, souvent couplé | Un seul bloc, modules découplés | Multiples déploiements indépendants |
| Couplage interne | Fort, souvent implicite | Faible, imposé par le code | Faible, imposé par le réseau |
| Coût d’infrastructure | Faible | Faible | Élevé (orchestration, réseau, observabilité) |
| Courbe d’apprentissage équipe | Faible | Moyenne (discipline de découpage) | Élevée (systèmes distribués) |
| Scalabilité indépendante par module | Non | Limitée | Oui |
| Effort d’extraction future | Élevé (code enchevêtré) | Faible (frontières déjà posées) | Non applicable |
Sources : Martin Fowler, « MonolithFirst », martinfowler.com, 2015 ; Shopify Engineering, « Deconstructing the Monolith », shopify.engineering, 2019 ; Sam Newman, Building Microservices, 2nd edition, O’Reilly.
Consultez aussi notre autre article sur l’architecture event-driven pour découpler vos services.
Quels sont les patterns de découpage : Bounded Contexts et DDD
Un Bounded Context est une frontière explicite autour d’un modèle métier cohérent. À l’intérieur de celle-ci, chaque terme métier garde un sens unique et stable.
Identifier ses domaines métier avant de coder
Le concept vient du Domain-Driven Design (DDD), formalisé par Eric Evans dans son ouvrage de référence Domain-Driven Design (2003). Martin Fowler synthétise cette idée dans sa fiche Bounded Context : un même mot peut désigner des réalités différentes selon le domaine métier concerné. Exemple : le mot « client » ne recouvre pas la même chose côté facturation et côté support. Ainsi, le découpage en modules doit suivre ces frontières métier, pas une logique purement technique.
Avant d’écrire du code, votre équipe cartographie donc les domaines de l’application :
- Catalogue
- Commande
- Paiement
- Expédition
- Et notification.
Chaque domaine devient un candidat naturel pour un module.
Traduire un Bounded Context en module technique
Vous avez identifié vos domaines ? La règle est simple : un module correspond à un Bounded Context. Il possède ses propres tables ou schémas de données. De plus, il expose une interface publique pour les autres modules. Tel est le cas pour les fonctions, les événements ou l’API internes. Aucun autre module n’accède directement à ses données.
Prenons un exemple concret : Une plateforme e-commerce compte typiquement un module Catalogue, Commande, Paiement et un module Expédition. Le module Commande ne lit jamais directement la base de données du module Paiement. Il appelle l’interface publique que ce module expose. Ou, il réagit à un événement que ce module publie. Cette règle simple évite la majorité des couplages accidentels observés dans les monolithes non structurés.
Les erreurs fréquentes de découpage
Deux erreurs reviennent souvent.
- La première : découper par couche technique (« modules » contrôleurs, services, repositories) plutôt que par domaine métier. Cette organisation ne réduit pas le couplage, elle le déplace.
- La seconde : laisser deux modules dépendre l’un de l’autre dans les deux sens. Cette dépendance circulaire empêche toute extraction future et rend le système aussi rigide qu’un monolithe non structuré.
Pour aller plus loin, consultez aussi notre autre article sur comment découper votre frontend avec les micro-frontends.
Comment se passe la communication entre les modules : événements et contrats
Vous avez plusieurs choix possibles pour une bonne architecture modulaire application.
L’appels directs vs API internes vs événements asynchrones
Trois mécanismes permettent à deux modules de communiquer.
- L’appel direct de fonction reste le plus simple. Cependant, il crée une dépendance forte au moment de la compilation.
- L’API interne (une interface définie et versionnée) réduit ce couplage et garde un appel synchrone.
- L’événement asynchrone découple encore davantage : un module publie un événement, les autres modules réagissent sans connaître l’émetteur.
Le choix dépend de votre besoin. Exemple :
- Vous avez une opération qui exige une réponse immédiate ? Exemple : vérifier un stock avant validation de commande. Vous aurez souvent besoin d’un appel synchrone.
- Une opération qui déclenche une suite d’actions indépendantes se prête bien à l’événement asynchrone. Exemple : envoyer une notification après une commande validée
Prenons l’exemple d’une commande validée. Dans ce cas :
Le module Commande publie un événement « commande validée ».
La Facturation réagit en générant une facture.
Celui du Notification réagit en envoyant un e-mail de confirmation.
Le module Commande n’a besoin de connaître ni le format de la facture, ni le canal de notification utilisé. Cette absence de dépendance directe facilite l’ajout d’un nouveau comportement plus tard, sans modifier le module Commande.
Le module comme fournisseur d’un contrat stable
Chaque module expose un contrat : les données et fonctions qu’il rend disponibles aux autres modules. Ce contrat doit rester stable dans le temps. Un changement impacte tous les modules qui en dépendent, exactement comme un changement d’API publique impacterait des clients externes.
Les outils de mesure et d’enforcement
La discipline de découpage tient rarement sur la seule bonne volonté de l’équipe. Des outils d’analyse statique aident à vérifier que les frontières entre modules sont respectées dans le code.
Par exemple, Shopify a développé Packwerk. C’est un outil open source qui détecte les références directes entre composants non autorisées. Ce type d’outil transforme une règle de conception en contrainte vérifiable automatiquement, à chaque build.
Comment se passe la migration progressive d’une architecture modulaire application vers les microservices si nécessaire ?
Oui. Vous pouvez changer l’architecture modulaire application. D’ailleurs, vous devez migrer vers les microservices quand le modular monolith ne suffit plus.
Quels sont les signaux qui justifient une extraction ?
Un module mérite une extraction en service indépendant quand un signal métier ou technique concret apparaît. Trois cas reviennent le plus souvent :
- Une charge de calcul isolée qui doit scaler indépendamment du reste de l’application
- Une équipe dédiée qui a besoin de déployer sans dépendre du cycle de release global
- Ou une contrainte réglementaire qui impose d’isoler certaines données (paiement, santé).
En dehors, extraire un module reste une décision coûteuse pour un bénéfice incertain. Posez-vous simplement la bonne question : « pourrions-nous passer aux microservices ? », mais « quel problème précis cette extraction résout-elle aujourd’hui ? ».
Trois questions aident à trancher avant toute extraction.
- Ce module consomme-t-il des ressources disproportionnées par rapport au reste de l’application (calcul intensif, traitement d’images, indexation) ?
- Une équipe dédiée bloque-t-elle sur le cycle de déploiement global pour livrer ses changements ?
- Une obligation réglementaire impose-t-elle une isolation technique stricte des données concernées ?
Si aucune de ces réponses n’est positive, le module reste un excellent candidat pour rester dans le modular monolith.
Comment extraire un module déjà bien délimité ?
C’est ici que le modular monolith prend tout son sens. Un module conçu avec une frontière claire et un contrat stable s’extrait sans réécriture profonde. En effet, ses données sont déjà isolées. De plus, son interface publique est déjà définie. Alors, l’extraction devient un projet d’infrastructure, pas un projet de refonte du domaine métier.
Un monolithe non structuré impose l’inverse. Donc, il faut d’abord démêler les dépendances. Puis découpez les données, avant même de pouvoir extraire quoi que ce soit.
Comment AquilApp structure vos applications ?
Chez AquilApp, le cadrage d’un projet commence par la cartographie des domaines métier, avant toute ligne de code. Cette étape identifie les frontières naturelles de votre application : catalogue, gestion des utilisateurs, facturation, intégrations tierces.
Notre position est tranchée :
- Nous recommandons par défaut un modular monolith pour la grande majorité des projets, quelle que soit leur taille.
- Par ailleurs, nous réservons les microservices aux cas où un signal métier ou technique précis le justifie : charge isolée, contrainte réglementaire, équipe dédiée à un périmètre. Cette approche limite les coûts d’infrastructure au démarrage. Elle garde la porte ouverte à une extraction ciblée le jour où votre application en a réellement besoin.
Concrètement, un atelier de cadrage réunit vos équipes métier et notre équipe technique autour d’une cartographie des domaines. Il dure en général une à deux journées. Il produit un premier découpage en modules, validé avec vos experts métier avant l’écriture de la moindre ligne de code. Ce travail en amont évite les refontes d’architecture coûteuses six ou douze mois après le lancement. En effet, il vaut mieux créer une application scalable dès le départ.
FAQ sur l'architecture modulaire d'une application
* **Scalabilité asymétrique :** Une fonctionnalité ou un module précis subit une charge massive et nécessite un dimensionnement individuel de ses ressources de calcul sans devoir dupliquer l’intégralité du monolithe.
* **Organisation des équipes (Loi de Conway) :** Plusieurs équipes de développement autonomes ont besoin de déployer leurs périmètres fonctionnels respectifs en continu, sans être ralenties par un calendrier de mise en production global.
* **Isolation et résilience ciblées :** Un composant critique ou soumis à une réglementation stricte exige une isolation totale (sécurité, tolérance aux pannes) pour éviter qu’une défaillance n’entraîne la chute de toute l’application.
* **Monolithe modulaire (*Modular Monolith*) :** Les modules métiers sont isolés de manière logique au niveau du code source (ex. via des packages, modules ou espaces de noms distincts), mais l’ensemble est compilé et déployé sous la forme d’un **artéfact unique** exécuté dans un seul processus (les communications s’effectuent directement en mémoire).
* **Microservices :** Chaque module constitue un service autonome, exécuté dans son propre processus (généralement conteneurisé), disposant idealement de sa propre base de données et déployable de façon indépendante. La communication s’effectue à travers le **réseau** (via API REST, gRPC ou bus d’événements asynchrones).
Conclusion
L’architecture modulaire application n’oppose pas monolithe et microservices. D’abord, elle règle la question du découpage par domaine métier. Le modular monolith offre le meilleur point de départ : simplicité opérationnelle, frontières claires, extraction possible plus tard si un besoin réel apparaît. C’est le cas pour la majorité des projets.
Vous préparez une refonte ou un nouveau projet applicatif ou souhaitez développer un logiciel sur mesure ? Demandez un audit d’architecture applicative à l’équipe AquilApp.
