Un monolithe est une application construite et livrée d'un seul tenant. Le catalogue, le panier, le checkout, les comptes clients, les emails et l'administration vivent dans le même code, tournent dans le même programme et partagent le plus souvent une seule base de données. Quand l'équipe publie une nouvelle version, c'est toute l'application qui est mise à jour d'un coup.

Le mot sonne parfois comme un reproche, comme si un monolithe était forcément vieux ou lourd. Ce n'est pas le cas. Beaucoup de produits qui marchent très bien reposent sur un monolithe. Pour un fondateur qui lance un produit ou une marque qui fait développer une boutique sur mesure, c'est souvent l'option la plus rapide, la moins chère et la plus fiable. Ce qui compte, c'est la qualité de son organisation interne, et la capacité à repérer le moment où il devient trop étroit.

Qu'est-ce qu'un monolithe ?

En architecture logicielle, un monolithe est une application dont toutes les fonctionnalités sont assemblées et déployées ensemble, comme une seule unité. Le code peut être réparti en des centaines de fichiers et de modules, mais au bout du compte il devient un seul programme en fonctionnement, ou plusieurs copies identiques de ce programme derrière un répartiteur de charge.

Ses traits habituels :

  • Un seul code source. Toutes les fonctionnalités se trouvent dans le même dépôt, écrites dans le même langage et le même framework.
  • Un seul déploiement. Une modification de la page produit et une modification des remboursements partent en production dans la même version.
  • Une base de données partagée. Les fonctionnalités lisent et écrivent dans la même base, ce qui permet d'enregistrer une commande et la mise à jour du stock dans une seule transaction.
  • Des appels internes. Les parties de l'application s'appellent directement en mémoire, sans passer par le réseau. C'est rapide et facile à déboguer.

Un monolithe n'est pas forcément désordonné. Un monolithe modulaire a des frontières internes nettes : le code du catalogue ne va pas fouiller dans celui des paiements, et chaque module n'expose aux autres qu'un petit nombre de fonctions. À l'inverse, ce que les développeurs appellent une « grosse boule de boue » est un monolithe où tout dépend de tout, et où une modification à un endroit peut casser n'importe quoi ailleurs. Le mode de déploiement est identique, la qualité interne est opposée.

La principale alternative, ce sont les microservices : l'application est découpée en nombreux petits services déployés séparément. Choisir entre les deux fait partie des premières décisions d'architecture. Des approches comme la clean architecture aident à bien structurer l'intérieur d'un monolithe.

Pourquoi c'est important

Pour la plupart des petites entreprises, un monolithe transforme un budget fixe en plus de fonctionnalités et en moins de factures.

Prenons une fondatrice qui dispose de 40 000 euros pour créer un outil de réservation et de boutique destiné aux studios de yoga. Une application unique, avec des modules pour les studios, les cours, les produits, les commandes et les paiements, demande environ 12 semaines à deux développeurs. Elle tourne sur un serveur et une base de données managée pour environ 120 euros par mois. Un seul fichier de logs montre tout ce qui est arrivé à un paiement en échec. Un nouveau développeur peut lancer le produit complet sur son ordinateur dès le premier jour.

Le même périmètre découpé en huit services séparés demande 18 semaines ou plus. Chaque service réclame sa propre configuration, son déploiement, sa sécurité et sa façon de communiquer avec les autres. L'hébergement monte vers 700 euros par mois. Comprendre un paiement raté oblige à le suivre à travers trois services.

Sur la première année, le monolithe économise à peu près 6 semaines de développement, soit environ 12 000 euros, plus 7 000 euros d'hébergement. Surtout, il arrive chez les premiers studios payants 6 semaines plus tôt. Ce sont précisément les semaines où un jeune produit découvre ce que veulent vraiment ses clients, et le monolithe permet de changer de cap à un seul endroit.

Le coût, s'il arrive, arrive plus tard. Quand l'équipe dépasse 20 ou 30 développeurs, ou quand une partie a besoin d'une puissance très différente du reste, un code unique et un cycle de livraison unique finissent par ralentir tout le monde. Un monolithe bien organisé se découpe alors progressivement. Un monolithe emmêlé impose une réécriture. C'est pour cela que la structure interne compte plus que l'étiquette.

Comment ça marche

Un monolithe suit un cycle de vie simple :

  • Un seul projet contient toutes les fonctionnalités. Les développeurs l'organisent en modules par domaine métier, par exemple catalogue, commandes, clients et facturation.
  • Une requête est traitée à un seul endroit. Quand un client ajoute un article au panier, la couche web appelle le module panier, qui interroge le module catalogue pour vérifier le prix et le stock, dans le même processus.
  • Les données sont enregistrées en une transaction. La création de la commande, la réservation du stock et l'enregistrement du paiement réussissent ensemble ou sont annulés ensemble.
  • L'application est construite et testée d'un bloc. Les tests automatisés tournent sur l'application complète avant chaque mise en production.
  • Elle est déployée comme une seule unité. La nouvelle version remplace l'ancienne, souvent sur plusieurs serveurs identiques pour tenir la charge et rester disponible.
  • Elle grandit par duplication. Quand le trafic augmente, on fait tourner davantage de copies de la même application derrière un répartiteur de charge, et on renforce la base de données.

Repères et exemples

Un monolithe va beaucoup plus loin que sa réputation ne le laisse croire.

  • Petites boutiques et outils pour créateurs : une seule application encaisse sans difficulté plusieurs milliers de commandes par mois sur un hébergement modeste.
  • Produits SaaS en croissance : un monolithe bien construit sert couramment des dizaines de milliers d'utilisateurs avec une équipe de 5 à 15 développeurs.
  • Grandes plateformes : plusieurs entreprises connues font tourner depuis des années de très gros monolithes, avec des centaines de développeurs, en investissant beaucoup dans les frontières entre modules et dans l'outillage.

Quelques signes qu'un monolithe est en bonne santé : un nouveau développeur livre une petite modification dès sa première semaine, la suite de tests complète tourne en quelques minutes et non en heures, et les mises en production ont lieu au moins une fois par semaine sans appréhension. Les signes de tension : des versions retardées parce que des équipes sans rapport se bloquent mutuellement, une fonctionnalité lourde comme la recherche ou les rapports qui ralentit le checkout de tout le monde, ou une compilation qui dépasse 30 minutes. Ce sont des raisons d'extraire une partie, pas de tout réécrire par réflexe.

Erreurs fréquentes

  • Laisser les frontières s'effacer. Sans discipline, les modules se mettent à appeler les rouages internes des autres, et le monolithe devient une grosse boule de boue chargée de dette technique.
  • Réécrire au lieu d'extraire. Jeter un monolithe qui fonctionne pour repartir de zéro en microservices prend souvent deux fois plus de temps que prévu et fait perdre des règles métier que personne n'avait documentées.
  • Découper trop tôt. Passer aux services avant que l'équipe et le trafic ne l'exigent ajoute des coûts sans rien apporter.
  • Faire les traitements lourds dans les requêtes. Lancer un gros export ou le traitement d'images pendant la requête d'un client ralentit tous les autres. Ces tâches doivent passer en arrière-plan, dans le même code.
  • Laisser tous les modules toucher à toutes les tables. Même dans un monolithe, chaque module devrait posséder ses propres tables, pour qu'un découpage reste possible plus tard.

Bonnes pratiques

  • Organisez le code par domaine métier. Un dossier pour le catalogue, un pour les commandes, un pour les paiements, un pour les clients, plutôt qu'un dossier de « modèles » et un dossier de « contrôleurs ».
  • Faites respecter les frontières entre modules. Chaque module expose un petit ensemble de fonctions documentées. Les autres ne touchent ni à son fonctionnement interne ni à ses tables.
  • Automatisez les tests et le déploiement. Un monolithe qui part en production sans risque chaque jour reste sain bien plus longtemps.
  • Utilisez des tâches en arrière-plan. Emails, exports et traitements lourds tournent en dehors de la requête du client.
  • Mesurez avant de découper. N'extrayez un service que lorsque les chiffres montrent un vrai goulot d'étranglement, par exemple un module qui consomme dix fois plus de ressources que le reste.
  • Interrogez votre agence sur la modularité. Quand vous commandez un développement sur mesure, une réponse du type « monolithe modulaire » est en général un signe de pragmatisme, pas de retard technique.

Dans Roctify

Avec Roctify, vous ne construisez et ne faites tourner aucune application, qu'elle soit monolithique ou non. Roctify est un SaaS : la plateforme héberge votre boutique, la maintient à jour et sert chaque page en HTTPS avec un certificat SSL gratuit. Les déploiements, les serveurs et les correctifs de sécurité sont gérés pour vous.

Ce que vous retrouvez de l'idée du monolithe, c'est son principal avantage pour un vendeur : tout est au même endroit. Votre page lien en bio et votre boutique complète partagent un seul catalogue de produits, variantes, SKU, stocks, prix, clients et commandes, et le stock se met à jour partout en même temps. Les paiements par Stripe, PayPal ou paiement à la livraison, les codes promo, les taxes et, à partir du plan Creator, l'email marketing s'appuient sur les mêmes données. Vous n'avez pas à assembler des outils séparés.

FAQ

Un monolithe, est-ce dépassé ?

Non. C'est un mode de déploiement avec des atouts nets : rapidité de développement, faible coût de fonctionnement et débogage facile. Beaucoup d'équipes recommandent aujourd'hui de démarrer avec un monolithe modulaire et de ne découper que lorsque la taille de l'équipe ou la charge l'exige.

Un monolithe peut-il supporter beaucoup de trafic ?

Oui, dans la grande majorité des cas. On fait tourner plusieurs copies derrière un répartiteur de charge et on optimise la base de données. Les limites viennent généralement de l'organisation, avec trop d'équipes dans un même code, bien avant que le volume de trafic ne pose problème.

Comment passer d'un monolithe à des microservices ?

Progressivement. L'équipe choisit une partie bien délimitée, comme la recherche ou les notifications, l'extrait dans un service et y redirige le trafic, puis recommence si besoin. Cette méthode garde le produit en ligne pendant toute la transition et évite le risque d'une réécriture complète.