Lectures: 7
Résumé – La quête de modernisation pousse souvent à éclater le SI en microservices pour gagner en scalabilité et résilience, mais un découpage purement technique sans limites métier claires génère un « monolithe distribué » : couplages invisibles, flux synchrones, incidents en cascade et pipelines CI/CD hypertrophiés. Les déploiements synchronisés et l’inefficacité des cycles de développement finissent par gripper l’agilité promise. Vous perdez en robustesse et en vitesse d’évolution.
Solution : adopter un monolithe modulaire structuré par domaines fonctionnels, déployé comme un artefact unique, avec schémas de données isolés et gouvernance claire, puis extraire progressivement les composants réellement critiques.
Dans un contexte où la modernisation des systèmes d’information est perçue comme un enjeu stratégique, les microservices s’imposent souvent comme une solution miracle. Scalabilité, résilience, déploiements indépendants : les promesses séduisent les directions IT et les métiers. Pourtant, nombre de projets se retrouvent paradoxalement englués dans une complexité accrue et dans des incidents récurrents.
Cet article examine l’antipattern du « monolithe distribué » et met en lumière ses racines, ses impacts et ses remèdes. Nous verrons pourquoi un découpage technique sans réflexion métier transforme l’agilité promise en enfer opérationnel. Puis nous défendrons une approche alternative : le monolithe modulaire, un cadre plus maîtrisé pour évoluer à votre rythme.
Les racines du monolithe distribué
Le monolithe distribué naît d’un découpage technique qui ne correspond pas aux limites métier. Sans frontières claires, chaque service devient un point d’échec et une source de dépendances invisibles.
Frontières de services mal définies
Lorsque les frontières de vos services sont tracées uniquement sur des critères techniques, vous passez à côté des véritables domaines métier. Un découpage réalisé sans analyse des processus fonctionnels engendre des services qui s’appuient constamment les uns sur les autres, recréant un couplage étroit malgré la distribution.
Ce découpage imparfait mène à des flux d’appels synchrones entre clusters de services qui auraient dû être isolés. Chaque nouvelle fonctionnalité génère une cascade d’ajustements dans plusieurs services, ce qui ralentit l’évolution globale du système.
Le manque de cartographie métier accentue le problème : les équipes ne parlent pas le même langage, les termes techniques masquent des fonctionnalités partagées. À terme, on assiste à la multiplication des réunions d’arbitrage et à l’inefficacité croissante des cycles de développement.
Couplage fonctionnel malgré distribution
Techniquement, les services sont séparés, mais fonctionnellement ils restent indissociables. On observe souvent des bases de données partagées ou des contrats API non évolutifs qui verrouillent tout changement. Cette situation déporte la complexité logicielle sur l’infrastructure et sur l’exploitation.
Les équipes finissent par déployer plusieurs microservices simultanément pour garantir la cohérence des données ou des workflows. Le gain de vélocité espéré disparaît, remplacé par la nécessité d’orchestrer des orchestrateurs et de gérer une multitude de pipelines CI/CD.
Chaque incident sur un service entraîne un effet domino sur les autres. L’exploitation doit alors surveiller non pas un monolithe, mais un écosystème distribué tout aussi fragile, où l’absence d’un composant ou l’incompatibilité d’une version peut paralyser l’ensemble.
Exemple de découpage technique sans réflexion métier
Une entreprise suisse de taille moyenne dans le secteur manufacturier a fragmenté son ancienne application ERP en dix microservices en moins de six mois. Les équipes ont suivi un modèle générique de découpage, sans aligner chaque service sur un domaine fonctionnel précis.
Résultat : chaque déploiement nécessitait la mise à jour de huit services sur dix pour garantir la cohérence des données et des transactions. Ce projet a montré qu’un découpage purement technique aboutit à un monolithe distribué, sans aucun gain d’autonomie pour les équipes et avec un surcoût d’exploitation de plus de 30 %.
Les conséquences opérationnelles et organisationnelles
Un système distribué mal conçu cumule les inconvénients du monolithe et ceux du distribué. Les déploiements synchronisés, les incidents en cascade et la lenteur d’évolution en sont la marque.
Déploiements synchronisés
Plutôt que d’observer des livraisons indépendantes, les équipes orchestrent des vagues de déploiement. Chaque modification fonctionnelle exige la coordination de plusieurs pipelines CI/CD et plusieurs équipes d’exploitation.
Cette synchronisation forcée génère un allongement des fenêtres de maintenance, une augmentation du temps d’indisponibilité et des risques accrus d’erreurs humaines. Les procédures deviennent lourdes, avec des check-lists interminables avant toute mise en production.
À terme, l’agilité promise se transforme en inertie. Les métiers attendent des évolutions tandis que l’équipe IT craint de déclencher un incident majeur à chaque changement, réduisant ainsi la fréquence des déploiements.
Incidents en cascade
Dans un monolithe distribué, l’isolement des pannes est illusoire. Un appel synchrone ou une faute sur la base partagée peut propager une panne à l’ensemble des services.
Les alertes se multiplient, l’équipe d’exploitation perd du temps à identifier l’origine réelle d’un incident dans un maillage complexe. Les temps de rétablissement s’allongent, et la fiabilité perçue du système s’effondre.
Sans mécanismes de résilience bien architecturés (circuit breaker, timeouts, isolation des dépendances), chaque service exposé multiplie les points de fragilité, au détriment de l’expérience utilisateur et de la confiance des métiers.
Exemple d’impacts sur une chaîne de distribution
Une chaîne de magasins suisse a migré sa plateforme de gestion des stocks vers une architecture microservices. Les services de commande, de facturation et de reporting partageaient une même base de données, sans isolation des transactions.
Lors d’un pic d’activité, un décalage de version a provoqué une surcharge sur le service de facturation, rendant l’ensemble des commandes impossibles pendant plusieurs heures. Cette panne a montré que la distribution sans découpage métier crée un effet domino et aggrave sensiblement l’impact des incidents.
Edana : partenaire digital stratégique en Suisse
Nous accompagnons les entreprises et les organisations dans leur transformation digitale
Pression organisationnelle et objectifs déconnectés
La migration vers les microservices devient parfois un objectif en soi, détaché des enjeux réels du produit. Cette pression peut conduire à ignorer l’analyse métier et à multiplier les antipatterns.
Objectif microservices versus besoin métier
Nombre d’organisations fixent un KPI « nombre de services » ou un jalon « passage au distribué » sans s’interroger sur l’adéquation avec la roadmap fonctionnelle. Cette vision technique prime sur la valeur délivrée.
Les décisions d’architecture se font alors sur la base de benchmarks de concurrents ou de recommandations génériques, plutôt que sur l’analyse des cas d’usage spécifiques et des charges réelles du système.
Le risque est de transformer l’architecture en un catalogue de services déconnectés, dont la maintenance et l’évolution demandent une coûteuse organisation transversale, sans bénéfice concret pour les utilisateurs.
Absence de Domain-Driven Design
Sans DDD, les services ne s’alignent pas sur les agrégats métier. On retrouve des fonctionnalités dupliquées, des transactions réparties mal conçues et une gouvernance des données inconsistante.
Le DDD permet de définir des contextes bornés et des modèles de données autonomes. À l’inverse, sans cette discipline, chaque équipe crée sa propre vision du domaine, renforçant le couplage et la dette technique.
Cela se traduit par des allers-retours permanents entre équipes fonctionnelles et techniques, par des modifications globales dès qu’un cas d’usage évolue et par l’incapacité à monter en charge de manière isolée.
Exemple d’une plateforme de santé hospitalière
Un groupe hospitalier suisse a déployé plusieurs microservices sans cartographier les contextes métiers, ce qui a conduit à des doublons dans la gestion des rendez-vous, des dossiers patients et des facturations.
Les équipes ont finalement dû réécrire la couche d’accès aux données et regrouper les services autour de trois contextes clairement définis, montrant qu’un investissement initial en DDD aurait évité cet effondrement organisationnel et ce refactoring majeur.
Monolithe modulaire : une alternative pragmatique
Avant de se lancer dans le distribué, explorer un monolithe modulaire peut préserver la lisibilité et réduire la complexité. Une structure modulaire alignée sur le domaine métier favorise l’évolution progressive et sécurisée de votre SI.
Principes du monolithe modulaire
Le monolithe modulaire consiste à organiser le code en modules clairement découpés par domaine métier, tout en restant dans une seule base de déploiement. Chaque module bénéficie de sa propre couche de responsabilité et d’API internes.
Cette approche limite les dépendances circulaires et facilite la compréhension du système. Les tests unitaires et d’intégration restent simples à mettre en place, sans nécessiter une infrastructure distribuée.
Le CI/CD déploie un artefact unique, ce qui simplifie la gestion des versions et la synchronisation entre équipes. L’ajout d’un nouveau module se fait par extension du monolithe, industrialiser votre delivery sans rupture ni alignement complexe de plusieurs services.
Gouvernance du code et de la donnée
Dans un monolithe modulaire, la base de données peut être partagée, mais chaque module dispose de ses schémas ou de ses namespaces dédiés, réduisant ainsi le risque de conflit ou de migration massive.
La gouvernance impose des conventions de nommage, des revues de code transversales et une documentation claire sur les frontières et les responsabilités de chaque module.
À terme, le monolithe modulaire permet de repérer facilement les zones à extraire vers des services indépendants lorsque le besoin se fera réellement sentir, garantissant un passage au distribué plus mûr et préparé.
Exemple d’une institution financière suisse
Une grande institution financière suisse a consolidé son application métier en un monolithe modulaire, structuré selon cinq domaines fonctionnels clés. Les modules communiquaient via un bus interne et partageaient une base de données segmentée.
Après plusieurs années, ils ont extrait deux modules critiques vers des microservices, sur la base d’indicateurs concrets de charge et d’évolutivité. Cette trajectoire graduelle a validé la modularité et limité les risques opérationnels.
Repensez votre stratégie d’architecture : modularité avant distribution
La tentation des microservices doit être mesurée et justifiée par des cas d’usage réels. Le monolithe distribué n’est pas une fatalité : mieux vaut investir dans une modularité métier pour conserver lisibilité, performance et maîtrise des coûts. Un monolithe modulaire offre un terrain d’apprentissage solide avant de franchir le pas vers la distribution.
Nos experts Edana, architectes de solutions IT, vous accompagnent dans l’analyse de vos domaines fonctionnels, la définition de frontières claires et la mise en place d’une architecture contextuelle, évolutive et sécurisée. Ensemble, nous déterminons la meilleure trajectoire pour votre entreprise, ni par effet de mode, ni par dogme.
