Démonter le monolithe ou le stabiliser ? Critères de décision pour une modernisation modulaire

Lundi matin, 9h10 : un service métier signale un « petite modification » dans le processus de commande. L’IT jette un œil rapide au contenu du ticket, cela semble faisable. Deux heures plus tard, l’ambiance a changé. Le build prend plus de temps que prévu, un job secondaire est lié au même paquet de release, et en regardant la base de données il devient clair : cette modification touche plus de tables et de triggers que prévu. À ce stade, la question qui revient régulièrement dans de nombreuses équipes se pose : Démanteler le monolithe ou le stabiliser ?

Qui répond sur le réflexe « Microservices ! » passe souvent à côté de l’essentiel : il ne s’agit pas d’un label d’architecture, mais de capacité de livraison et de sûreté d’exploitation. Ce guide pratique propose un examen pragmatique, expose des critères de décision pour la modernisation modulaire et décrit des étapes réalisables. Il présente également des scénarios d’erreur typiques ainsi que des points d’arrêt et d’escalade clairs — pour que la modernisation ne devienne pas un projet interminable sans effet mesurable.

Démanteler le monolithe ou le stabiliser : d’abord le symptôme, ensuite l’architecture

« Le monolithe est responsable » sonne catégorique, mais est rarement suffisamment précis pour fonder une décision. Un monolithe (une application livrée comme un artefact de déploiement unique) peut fonctionner très fiablement — ou provoquer des frictions permanentes. Il en va de même pour les Microservices (de nombreux petits services déployables séparément) : ils peuvent réduire les délais de livraison, mais ils entraînent inévitablement davantage de tâches opérationnelles.

Martin Fowler situe cette réalité de manière factuelle : les microservices sont principalement une autre empreinte opérationnelle — autrement dit un effort d’exploitation différent, avec plus de composants, plus de déploiements, plus de sources d’erreur et un besoin accru d’automatisation.^[Quelle] La limite de cette affirmation : elle ne remplace pas l’analyse de votre système. La conclusion pratique reste claire : déclarer « Microservices » comme objectif avant d’avoir décrit précisément le goulot d’étranglement, c’est moderniser rapidement au mauvais endroit.

Critères de décision : quand la décomposition aide vraiment — et quand elle ne le fait pas

La pression pour moderniser est réelle : les exigences de sécurité augmentent, les interfaces se multiplient, les équipes changent, et le logiciel métier doit continuer de fonctionner tout en évoluant. La décomposition peut être une étape pertinente — mais seulement si elle adresse le goulot d’étranglement et ne se contente pas d’embellir le diagramme d’architecture.

Critère 1 : maturité opérationnelle — votre exploitation peut‑elle supporter l’empreinte ?

À chaque unité déployable supplémentaire, le besoin d’une livraison et d’une supervision rigoureuses augmente : CI/CD (chaîne automatisée de build/test/deploy), Observability (métriques, logs et traces pour le diagnostic), processus d’incident, Runbooks et responsabilités clairement définies. AWS l’exprime comme un arbitrage : une segmentation plus fine peut apporter des avantages en fiabilité et en scalabilité, mais accroît la complexité opérationnelle avec le nombre de composants.^[Quelle] Limite : il s’agit d’une garde‑fou, pas d’une garantie de succès. Conclusion : si vous avez déjà aujourd’hui des difficultés à mener un déploiement de manière stable, un paysage de services multipliera ce problème.

Points de vérification concrets à ne pas écarter :

• Capacité de mise en production : Rollback/Backout sont définis, fenêtres de maintenance et communication établies.
• Monitoring et alertes : les alertes sont orientées action (pas « tout en rouge »), les sources d’erreur sont localisables.
• Gestion des incidents : il existe un rythme pour les postmortems et les mesures, pas seulement des interventions ad hoc.
• Responsabilités : qui décide des interfaces, qui priorise, qui assume l’exploitation et la qualité ?

Critère 2 : découplage des modifications — les exigences se bloquent‑elles mutuellement ?

La décomposition vaut le coup lorsque des modifications indépendantes dans le monolithe deviennent régulièrement interdépendantes alors qu’elles sont séparées sur le plan métier. Exemple typique : une zone portail nécessite des ajustements fréquents, tandis que la partie facturation doit rarement être modifiée et exige une grande rigueur. Si les deux figurent toujours dans le même cycle de release, elles se freinent mutuellement.

Inversement, la décomposition est souvent contre‑productive lorsque presque chaque modification traverse de nombreux domaines (autorisations, logique tarifaire, reporting, nettoyage des données). On crée alors du trafic d’interfaces au lieu de découplage — et la coordination augmente au lieu de diminuer.

Critère 3 : Couplage des données – la complexité réside-t‑elle dans la base de données ?

De nombreux systèmes sont moins couplés par le code que par les données : tables partagées, triggers, enchaînements transactionnels et jobs batch. Sam Newman souligne dans ses patterns de décomposition que le véritable défi réside souvent dans la stratégie de données et d’intégration – et que les projets « Big Bang » deviennent particulièrement risqués.^[Source]

Conséquence pratique pour l’exploitation : si plusieurs composants écrivent sans règles sur les mêmes tables, des effets de bord apparaissent et sont difficilement annulables proprement. Une modernisation modulaire exige donc des décisions précoces sur la souveraineté des données, la cohérence et le découplage du reporting.

Critère 4 : Stabilité et valeur métier – que faut‑il préserver ?

Dans les solutions numériques d’entreprise qui ont évolué au fil du temps se trouve souvent une logique de domaine correctement modélisée : cas particuliers, règles commerciales, exceptions de processus, procédures de nettoyage de données héritées. Ce n’est pas de la « camelote héritée », mais fréquemment la raison pour laquelle l’activité fonctionne. La modernisation devient économiquement viable lorsqu’elle ne jette pas ce patrimoine à la légère — et identifie simultanément les éléments qui rendent l’exploitation et l’évolution disproportionnément coûteuses.

Faire un choix : trois scénarios cibles qui fonctionnent en entreprise

Entre « tout reste » et « tout devient microservices » se trouvent des scénarios pratiques qui rendent la modernisation planifiable. AWS Prescriptive Guidance recommande explicitement d’examiner, avant la décomposition, quelles parties devraient effectivement être décomposées, et de privilégier des approches incrémentales.^[Source]

Guide pratique : De l’évaluation à la mise en œuvre (avec points Stop/Go)

1) Rendre visibles les frontières du système – assez petites pour être exploitées

Vous n’avez pas besoin d’une documentation système de 80 pages pour décider. Ce qui aide, c’est une carte compacte : processus principaux, interfaces critiques (p. ex. portails, EDI, exportations de fichiers, REST-APIs), jobs batch, ainsi que les points à forte susceptibilité aux incidents. Objectif : pouvoir prendre des décisions, pas archiver du savoir.

Une vue qui réunit l’exploitation et le métier a fait ses preuves : « Quelle chaîne de processus est critique pour l’activité, et de quoi dépend-elle techniquement ? » On voit alors rapidement où une extraction serait risquée – et où elle pourrait effectivement apporter un soulagement.

2) Définir des métriques de référence – sinon cela reste une question de foi

Une modernisation sans baseline revient à une optimisation de performance sans mesure. Les indicateurs essentiels couvrent à la fois la livraison et l’exploitation : fréquence de déploiement, lead time (de la demande à la mise en production), change failure rate (incidents après changements), MTTR (mean time to recovery) et classes d’incidents récurrentes. Les métriques n’ont pas besoin d’être académiquement parfaites – mais elles doivent être collectées de façon cohérente pour qu’un Stop/Go soit possible.

3) Découper les candidats – par domaine, pas par couches techniques

Un démarrage raté fréquent est le découpage par couches (« UI-Service », « DB-Service »). Cela génère de nouvelles dépendances au lieu de les réduire. Le découpage par domaine signifie : un module prend en charge un périmètre fonctionnel incluant règles et données. Pour les équipes, c’est généralement plus concret qu’une séparation purement technique.

Si vous n’êtes pas capable de nommer les limites fonctionnelles, ce n’est pas une raison pour découper plus vite – mais un signal pour stabiliser et modulariser d’abord dans le monolithe : clarifier les termes, comprendre les flux de données, identifier les fonctions transverses.

4) Strangler statt Big Bang – rediriger de manière contrôlée, désactiver de façon conséquente

Lorsque la disponibilité compte et que les risques doivent être maîtrisés, le Strangler-Fig-Pattern est une voie robuste : les fonctions sont remplacées progressivement à côté du système existant ; le trafic est redirigé de manière contrôlée jusqu’à ce que les anciens chemins soient désactivés.^[Source]

L’important est la discipline derrière le modèle : décisions de routage claires, compatibilité des données et des interfaces, monitoring sur les deux voies – et un vrai « Done » lorsque l’ancien chemin est supprimé. Sinon, le fonctionnement en parallèle devient un état permanent.

5) Définir tôt la stratégie de données et de reporting

Dans la pratique, la modernisation se joue souvent sur deux questions : qui « possède » quelles données — et comment est effectué le reporting ? Si le reporting accède directement aux tables opérationnelles, il bloque les changements. Si plusieurs composants « partagent » des données sans règles, des incohérences apparaissent.

Planifiez donc explicitement :

• Souveraineté des données : quel module est responsable de quelle entité (client, commande, facture …) ?
• Exigences de cohérence : où une cohérence forte est-elle nécessaire, où Eventual Consistency suffit-elle ?
• Découplage du reporting : comment alimenter les analyses sans rigidifier les modèles opérationnels ?

6) Définir la sécurité et l’exploitation par module — ne pas les ajouter après coup

À chaque nouvelle composante, la surface d’attaque augmente : communication service-à-service, secrets, autorisations, traces d’audit. Clarifiez tôt comment authentification (p. ex. centralisée via SSO) et autorisation (par rôles/permissions par domaine) interagissent. Au quotidien, il faut aussi veiller à ce que les logs soient utiles pour le diagnostic, sans enfreindre les règles de protection des données et de conservation. Ces points doivent figurer dans les runbooks et la documentation d’exploitation — pas seulement dans des diagrammes d’architecture.

Liste de contrôle en 8 étapes pour une décision Go/No-Go fiable

1. Identifier le goulot d’étranglement : qu’est-ce qui doit précisément s’améliorer (durée des releases, stabilité, montée en charge, développement parallèle) ?
2. Mesurer la ligne de base : quelles métriques décrivent l’état actuel (Lead Time, Change Failure Rate, MTTR etc.) ?
3. Vérifier l’opérationnalité : CI/CD, monitoring, alerte, runbooks, processus d’incident, Ownership.
4. Esquisser le découpage par domaine : où se trouvent les frontières fonctionnelles naturelles ? Quels sont les sujets transverses ?
5. Concevoir la stratégie de données : souveraineté des données, cohérence, reporting, parcours de migration.
6. Inventorier les dépendances : jobs, interfaces, exportations de fichiers, groupes d’utilisateurs, permissions.
7. Planifier un slice : un petit lot livrable incluant rollback et objectifs de monitoring.
8. Définir les critères Stop/Go : quels signaux arrêtent la découpe ou imposent une étape de stabilisation ?

Situations d’erreur typiques — voici à quoi elles ressemblent en exploitation

Erreur 1 : Plus de composants, mais pas d’ownership

Si personne n’est responsable bout en bout (priorisation, qualité, exploitation), le découplage devient un problème de coordination. En cas d’incident, cela entraîne de longues séries de consultations, des décisions floues et le réflexe de redéployer « tout ensemble ». Contre-mesure : un cercle clair de propriétaires par module, des remises de responsabilité définies et un journal de décisions pour les interfaces et la souveraineté des données.

Erreur 2 : Données partagées sans règles

L’anti-pattern est bien connu : les services sont séparés mais continuent d’écrire dans les mêmes tables ou utilisent des accès directs à la base de données à travers les domaines. Cela rompt l’isolation, complique les audits et rend les rollbacks peu fiables. Contre-mesure : accès aux données via des interfaces définies, responsabilité claire des données et — là où c’est nécessaire — synchronisation contrôlée (p. ex. événements).

Erreur 3 : la latence réseau et les cascades d’erreurs sont « prises en compte » mais pas testées

Ce qui, dans le monolithe, était un appel en processus devient dans les architectures distribuées un appel réseau avec timeouts, retries et potentielles cascades d’erreurs. Sans timeouts clairs, corrélation (IDs de requête) et tests bout en bout réalistes, l’analyse des erreurs devient nettement plus difficile. Contre-mesure : SLOs clairs (objectifs de service mesurables), timeouts définis, corrélation des traces et tests de charge le long de parcours complets de processus.

Erreur 4 : découpage selon l’organigramme au lieu de la logique métier

Si les services représentent surtout les frontières d’équipes, mais traversent fonctionnellement les processus, le couplage demeure — simplement à un autre niveau. Contre-mesure : découpage strict par domaine, même si cela crée d’abord des frictions. Si cela n’est pas possible sur le plan organisationnel, un monolithe modulaire est souvent une meilleure étape intermédiaire.

Points d’arrêt et d’escalade : quand la stabilisation devient la meilleure décision

Un projet de modernisation a besoin de règles d’arrêt, sinon il absorbe le budget et l’attention. Ces signaux constituent des raisons solides de basculer délibérément :

• Surcharge opérationnelle : flot d’alertes, MTTR en hausse, astreintes non couvertes.
• Aucune amélioration mesurable : Lead Time, Change Failure Rate ou stabilité ne s’améliorent pas de façon perceptible.
• La complexité des interfaces explose : versioning non clarifié, Breaking Changes se multiplient, le débogage devient un exercice de conjecture.
• Conflits de données : incohérences, vérités dupliquées, écarts de rapports difficilement explicables.
• La propriété reste floue : les décisions traînent, personne n’assume la responsabilité de l’exploitation et de l’évolution.

L’escalade ne signifie pas «retour au précédent», mais : prioriser la stabilisation. Mesures typiques : mettre en place des tests de régression pour les processus centraux, améliorer l’observabilité, consolider les accès aux données, affiner les frontières des modules dans le monolithe — et n’évaluer qu’ensuite à nouveau si une extraction apporte vraiment un bénéfice.

Ce que «stabiliser» signifie concrètement — et pourquoi cela agit souvent plus rapidement

La stabilisation n’est pas un coup de balai cosmétique. En production, elle se traduit par moins de surprises et des releases planifiables. Leviers concrets que les équipes ressentent immédiatement :

• Mécanique de release : build reproductible, environnements cohérents, procédure de rollback rodée.
• Transparence : standards de logging, classification des erreurs, corrélation des requêtes à travers les chemins de traitement.
• Focus sur les tests : tests de régression de bout en bout pour les flux centraux (pas seulement des tests isolés).
• Frontières de module dans le monolithe : API internes définies, accès aux données discipliné, responsabilités claires.
• Hygiène des données : sources de données de référence uniques, effets secondaires des tâches documentés, logique des cas particuliers réduite.

Le résultat est souvent un monolithe modulaire résilient : le logiciel reste exploitable comme unité, mais est internement mieux découpé. Les équipes récupèrent ainsi déjà beaucoup de ce qu’elles attendent d’une décomposition — sans multiplier immédiatement la complexité opérationnelle.

Dernière question à se poser avant de décider

Si vous décomposiez aujourd’hui : pourriez-vous demain matin, en cas d’incident, dire rapidement quelle partie est responsable, qui réagit, quelle métrique prouve l’erreur et comment vous effectuez le rollback ? Si cette question reste gênamment ouverte, la décision n’est généralement pas «plus d’architecture», mais «plus de sécurité d’exploitation».

Si vous souhaitez évaluer votre situation de départ de manière structurée et définir une feuille de route de modernisation avec des points Stop/Go clairs, vous pouvez nous solliciter à cette fin de manière ponctuelle et ciblée :

La modernisation des systèmes legacy et le pattern Strangler Fig sont également importants pour ce sujet. L’article remet ces aspects en contexte de manière compréhensible et montre ce qui importe au quotidien.

Discuter d’un projet ou d’une initiative de modernisation avec Net-Base.