Architecture monolithique : définition, avantages, limites et alternatives

Une architecture monolithique est une façon de construire un logiciel sous la forme d’une seule application : l’interface, la logique métier et l’accès aux données vivent dans une même base de code, sont déployés ensemble et partagent généralement une seule base de données. C’est le modèle le plus simple à développer, tester et héberger, et il reste le bon choix pour la grande majorité des projets. Ses limites apparaissent quand l’application et l’équipe grossissent : déploiements plus lourds, montée en charge moins fine, difficulté à faire travailler plusieurs équipes en parallèle.

On voit ici comment fonctionne un monolithe, un exemple concret, ses avantages et ses inconvénients réels, la différence avec les microservices, le « monolithe modulaire » qui fait le lien entre les deux, et comment décider (ou migrer) sans céder à la mode.

• Qu’est-ce qu’une architecture monolithique ?
• Comment fonctionne une application monolithique ?
• À quoi ressemble un exemple d’architecture monolithique ?
• Quels sont les avantages d’une architecture monolithique ?
• Quels sont ses inconvénients ?
• Monolithe ou microservices : quelles différences ?
• Qu’est-ce qu’un monolithe modulaire ?
• Quand choisir une architecture monolithique ?
• Comment sortir d’un monolithe devenu trop lourd ?
• Questions fréquentes
• Sources

Qu’est-ce qu’une architecture monolithique ?

Monolithique signifie ici « d’un seul tenant », comme un bloc de pierre taillé d’une seule pièce. En développement, une architecture monolithique désigne une application construite et déployée comme un bloc unique : tous ses composants sont dans le même programme et s’appellent directement entre eux, sans passer par le réseau.

Chris Richardson, auteur du livre Microservices Patterns et du site de référence microservices.io, la décrit comme une application structurée en un seul composant déployable, qui contient tous les domaines fonctionnels et s’appuie sur une seule base de données. Ses composants sont interconnectés et interdépendants, alors qu’une architecture modulaire distribuée (comme les microservices) sépare ces composants en programmes indépendants, faiblement couplés.

Comment fonctionne une application monolithique ?

Prenons une application web d’entreprise côté serveur. Elle doit servir des clients variés : navigateurs sur ordinateur et sur mobile, applications mobiles natives, parfois des partenaires via une API. Elle peut aussi échanger avec d’autres logiciels (ERP, CRM, service de paiement). Pour chaque requête, elle exécute la logique métier, interroge la base de données, échange éventuellement des messages avec d’autres systèmes, puis renvoie une réponse en HTML ou en JSON.

Dans une architecture monolithique, tout cela tient dans une seule application, souvent organisée en couches :

• la couche présentation : les pages, les templates, les points d’entrée de l’API ;
• la couche métier : les règles de gestion (calculer un prix, valider une commande, vérifier un stock) ;
• la couche d’accès aux données : la lecture et l’écriture dans la base de données, unique et partagée.

Côté technique, le monolithe prend la forme d’un seul artefact : un fichier WAR ou JAR pour une application Java, une seule arborescence de code pour une application Ruby on Rails, Django, Laravel ou Node.js. WordPress en est un exemple familier : une application PHP unique, avec une base de données unique, que l’on étend par des extensions qui s’exécutent dans le même programme.

Pour tenir la charge, on ne découpe pas l’application : on la duplique. Plusieurs copies identiques tournent derrière un répartiteur de charge (load balancer), ce qui améliore aussi la disponibilité si l’une d’elles tombe.

À quoi ressemble un exemple d’architecture monolithique ?

L’exemple classique, repris par microservices.io, est celui d’une boutique en ligne qui prend les commandes, vérifie le stock et le crédit disponible du client, puis expédie. L’application comprend plusieurs modules : l’interface de la boutique (StoreFrontUI dans l’exemple d’origine), un module de vérification du crédit, un module de gestion des stocks, un module d’expédition.

En monolithe, ces modules sont compilés et déployés ensemble. Quand un client valide son panier, le module commande appelle directement la fonction de vérification du stock, puis celle du crédit, dans le même processus et dans la même transaction de base de données. Si le paiement échoue, tout est annulé proprement. Pour absorber un pic de trafic, on lance trois ou quatre copies de l’application derrière le répartiteur de charge.

Quels sont les avantages d’une architecture monolithique ?

• Simple à développer. Une seule base de code, un seul projet à ouvrir, des outils de développement (IDE, frameworks) pensés pour ce cas.
• Simple à tester et à déboguer. On lance l’application entière sur un poste, on suit une requête de bout en bout. Moins de pièces, moins de variables.
• Simple à déployer. Un seul artefact à mettre en production, un seul serveur (ou un petit groupe de serveurs identiques) à surveiller.
• Performant pour les échanges internes. Les composants s’appellent par des appels de fonction, sans latence réseau ni sérialisation entre services.
• Transactions fiables. Une base de données unique permet des transactions ACID classiques : une commande et la mise à jour du stock réussissent ou échouent ensemble.
• Moins cher à exploiter. Pas d’orchestrateur de conteneurs, pas de supervision distribuée, pas de gestion des pannes réseau entre services : l’hébergement et la maintenance restent à la portée d’une petite équipe.

Quels sont ses inconvénients ?

Les limites d’un monolithe ne se voient pas au début. Elles s’aggravent à mesure que l’application et l’équipe grandissent :

• Une base de code qui devient difficile à comprendre. Sans frontières strictes entre modules, les dépendances se croisent avec le temps. Les nouveaux développeurs mettent plus longtemps à être productifs, chaque changement devient plus risqué et la qualité baisse : c’est une spirale descendante.
• Des outils et des démarrages plus lents. Plus le code est volumineux, plus la compilation, les tests et le démarrage de l’application prennent du temps, ce qui ralentit chaque cycle de développement.
• Un déploiement tout ou rien. Pour modifier un seul composant, il faut redéployer toute l’application (et non la réécrire, contrairement à une idée reçue). Chaque mise en production interrompt aussi les tâches de fond et fait courir un risque à des parties qui n’ont pas changé. Résultat : les équipes déploient moins souvent, ce qui freine l’intégration et le déploiement continus.
• Une montée en charge dans une seule dimension. On peut multiplier les copies de l’application, mais pas dimensionner séparément un module gourmand en calcul et un autre gourmand en mémoire. Chaque copie embarque tout, même ce qui n’est pas sollicité.
• Un obstacle au travail en équipes séparées. Quand plusieurs équipes (catalogue, paiement, logistique) partagent un même code et un même calendrier de déploiement, elles doivent se coordonner en permanence.
• Un engagement long sur une pile technique. Tout le monolithe utilise le même langage et souvent la même version du framework. Adopter une nouvelle technologie pour une seule partie est difficile, et migrer un framework devenu obsolète se fait d’un bloc.
• Une panne peut tout emporter. Une fuite de mémoire ou une erreur grave dans un module peut faire tomber l’application entière.

Monolithe ou microservices : quelles différences ?

L’architecture de microservices est l’alternative la plus citée. Dans l’article qui a popularisé le terme (mars 2014), James Lewis et Martin Fowler la décrivent comme une façon de développer une application sous forme d’un ensemble de petits services, chacun tournant dans son propre processus et communiquant par des mécanismes légers, souvent une API HTTP. Nous y consacrons un article complet : l’architecture de microservices.

Critère	Monolithe	Microservices
Déploiement	Un seul artefact, déployé d’un bloc	Chaque service déployé indépendamment
Base de données	Généralement une seule, partagée	Idéalement une par service
Communication interne	Appels de fonction dans le même processus	Appels réseau (HTTP, messages)
Montée en charge	Duplication de toute l’application	Service par service, selon les besoins
Complexité au démarrage	Faible	Élevée (réseau, supervision, orchestration)
Transactions	ACID classiques	Transactions distribuées plus complexes
Organisation des équipes	Adaptée à une ou quelques équipes	Adaptée à de nombreuses équipes autonomes
Choix technologiques	Une pile pour tout	Une pile par service possible

Il existe d’autres approches encore, comme le serverless, où l’on déploie des fonctions à la demande sans gérer de serveur ; voyez notre guide de l’architecture serverless. Aucune n’est supérieure dans l’absolu : chacune déplace la complexité à un endroit différent.

Qu’est-ce qu’un monolithe modulaire ?

Le monolithe modulaire est un compromis de plus en plus répandu : l’application reste déployée d’un bloc, mais son code est découpé en modules aux frontières strictes, organisés par domaine métier (commandes, livraison, facturation), qui ne communiquent que par des interfaces définies.

Shopify en est l’exemple le plus documenté. Dans un article de février 2019, son équipe technique explique avoir choisi de réorganiser son monolithe Ruby on Rails (plus de 6 000 classes Ruby, développé depuis plus de dix ans par plus de 1 000 développeurs) en composants par domaine métier plutôt que de le découper en microservices. On garde la simplicité d’un seul déploiement et d’une seule base de code, tout en retrouvant une partie de l’autonomie des équipes.

Quand choisir une architecture monolithique ?

Dans un billet de juin 2015 intitulé Monolith First, Martin Fowler résume une position aujourd’hui largement partagée : il ne faut pas démarrer un nouveau projet en microservices, même si l’on est sûr que l’application deviendra assez grosse pour que cela en vaille la peine. Il observe que les adoptions réussies de microservices partent presque toujours d’un monolithe devenu trop gros, et que les systèmes conçus en microservices dès le départ rencontrent souvent de sérieux problèmes. La raison : tracer les bonnes frontières entre services est difficile tant qu’on ne connaît pas bien le métier et l’usage réel.

Le monolithe est donc le choix par défaut raisonnable quand :

• vous lancez un nouveau produit, un MVP ou une application métier dont le périmètre va encore bouger ;
• une seule équipe (ou quelques développeurs) travaille sur le code ;
• la charge est prévisible et peut être absorbée en dupliquant l’application ;
• le budget d’hébergement et de maintenance doit rester maîtrisé.

Les microservices deviennent pertinents quand plusieurs équipes doivent livrer indépendamment, quand certains modules ont des besoins de charge ou de disponibilité très différents, ou quand le monolithe freine clairement les mises en production. C’est ce raisonnement, et non la mode, qui guide le choix d’architecture sur les applications web sur mesure que l’on conçoit.

Les erreurs à éviter

• Découper trop tôt. Des microservices mal délimités produisent un « monolithe distribué » : tous les inconvénients du réseau, sans l’indépendance promise.
• Laisser le monolithe sans structure. Sans modules clairs, le passage à l’échelle ou une future migration coûteront beaucoup plus cher.
• Négliger l’automatisation. Tests automatisés et déploiement scripté rendent un monolithe beaucoup plus confortable à faire évoluer ; c’est le sujet de notre article sur le DevOps.

Comment sortir d’un monolithe devenu trop lourd ?

Réécrire tout le système d’un coup (le « big bang ») est la stratégie la plus risquée. La méthode la plus citée est celle du figuier étrangleur (Strangler Fig), décrite par Martin Fowler : comme la plante qui pousse autour d’un arbre hôte jusqu’à le remplacer, on construit progressivement de nouveaux composants à côté de l’ancien système, souvent en commençant par de nouvelles fonctionnalités, puis on y transfère petit à petit les fonctions existantes jusqu’à ce que l’ancien code ne serve plus.

1. Cartographier le monolithe : domaines métier, dépendances, zones qui changent souvent ou qui posent des problèmes de charge.
2. Modulariser d’abord : isoler les domaines à l’intérieur du monolithe. Souvent, cette étape suffit.
3. Extraire un premier service peu risqué et bien délimité (envoi d’e-mails, génération de PDF, recherche).
4. Router le trafic progressivement vers le nouveau composant, en gardant la possibilité de revenir en arrière.
5. Mesurer : si l’extraction n’apporte pas de gain visible (déploiements plus rapides, meilleure tenue en charge), inutile de continuer.

Des services très connus sont passés par là. Selon microservices.io, Netflix, Amazon.com et eBay reposaient à l’origine sur une architecture monolithique, comme la plupart des applications web avant 2012. Leur migration a répondu à une croissance hors norme, pas à un principe : la plupart des entreprises n’en ont jamais besoin.

Vous hésitez sur l’architecture d’un projet ou sur le devenir d’une application existante ? Écrivez-nous à contact@osmova.com ou via le formulaire de contact.

Questions fréquentes

Une architecture monolithique est-elle obsolète ?

Non. C’est le modèle recommandé pour démarrer la plupart des projets, et de grandes entreprises comme Shopify ont fait le choix assumé de garder un monolithe, bien structuré en modules.

Un monolithe peut-il supporter beaucoup de trafic ?

Oui, en faisant tourner plusieurs copies derrière un répartiteur de charge, avec du cache et une base de données bien optimisée. La limite vient plutôt de l’organisation des équipes et des besoins de charge très différents entre modules.

WordPress est-il une architecture monolithique ?

Dans sa forme classique, oui : une application PHP unique, une base de données, des extensions qui s’exécutent dans le même programme. On peut toutefois l’utiliser en mode headless, découplé de son affichage.

Quelle différence entre monolithe et monolithe modulaire ?

Les deux se déploient d’un bloc. Le monolithe modulaire impose en plus des frontières strictes entre domaines métier dans le code, ce qui limite l’enchevêtrement et facilite une éventuelle extraction future.

Faut-il passer aux microservices pour faire du déploiement continu ?

Non. Un monolithe avec de bons tests automatisés et un pipeline de déploiement peut être mis en production plusieurs fois par jour. Les microservices aident surtout quand plusieurs équipes se gênent mutuellement.

Sources

• Chris Richardson, microservices.io : Pattern Monolithic Architecture
• Chris Richardson, microservices.io : Pattern Microservice Architecture
• James Lewis et Martin Fowler, Microservices (mars 2014)
• Martin Fowler, Monolith First (juin 2015)
• Martin Fowler, Strangler Fig Application
• Shopify Engineering, Deconstructing the Monolith (février 2019)