Depuis les années 90, les systèmes d’information (SI) ont connu une transformation radicale. D’abord bâtis autour de monolithes robustes – ERP, CRM, solutions cœur de métier – ils ont progressivement basculé vers une modularité extrême, souvent présentée comme le remède ultime à la rigidité du passé.
Mais à mesure que les architectures se fragmentent, une réalité s’impose : l’agilité promise se paie cher. Complexité technique, dilution de la logique métier, explosion des coûts, désalignement organisationnel.
À l’aube de 2026, beaucoup d’entreprises découvrent qu’elles ont remplacé une rigidité centralisée… par une instabilité distribuée.
Cet article retrace cette trajectoire, démonte les illusions de l’over-modularité et propose une voie pragmatique et durable pour transformer les SI sans les condamner.
L’héritage des monolithes : une force industrielle devenue contrainte
Dans les années 90 et 2000, les entreprises ont structuré leurs SI autour de grands monolithes :
SAP pour la finance et la logistique, Oracle pour les opérations, Siebel pour la relation client. Ces plateformes centralisées ont joué un rôle fondamental : standardiser, fiabiliser et industrialiser les processus métiers à grande échelle.
À l’image d’une usine bien huilée, un ERP unique pilotait achats, production, ventes et finance, parfaitement aligné avec une organisation hiérarchique par grandes directions. Cette cohérence structurelle a permis une accélération sans précédent de la digitalisation.
Mais au fil des années, ces monolithes ont été surchargés : customisations locales, règles métier spécifiques, interfaces legacy empilées. La dette technique s’est accumulée silencieusement. Lorsque le cloud, l’agilité Scrum et les attentes de time-to-market rapide sont arrivés, le modèle a montré ses limites.
Un simple changement métier nécessitait des mois de tests end-to-end, 70 à 80 % du budget IT partait en maintenance, et le ROI de l’innovation se dégradait.
Des solutions de contournement ont émergé : wrappers, APIs exposant partiellement la logique, rétro-engineering du cœur. Mais ces rustines n’ont jamais réglé le problème fondamental : un couplage excessif qui rend chaque évolution risquée.
Les monolithes, héros de l’industrialisation, sont alors devenus les symboles de la lenteur.
La ruée vers la modularité : quand l’agilité devient un mirage
Face à cette impasse, les DSI ont massivement adopté les architectures modulaires et composables : microservices, serverless, SaaS spécialisés, event-driven.
La promesse est simple et puissante : déployer plus vite, scaler indépendamment, remplacer une brique sans tout reconstruire.
Sur le papier, l’approche est irréprochable. Dans la réalité, l’over-modularité frappe vite.
La logique métier, autrefois centralisée et cohérente, se disperse entre services, APIs, events Kafka, rules engines et orchestrateurs externes. Il n’existe plus de “cerveau” métier clair, seulement des flux.
Conséquences :
- Latence cumulative due aux appels inter-services
- Debugging complexe sur des traces distribuées
- Fragilité systémique : une brique défaillante peut bloquer toute la chaîne
- Explosion des coûts infra et d’observabilité
- Perte de lisibilité métier
Organisationnellement, le choc est tout aussi fort. Les équipes ne sont plus alignées sur des domaines métiers mais sur des composants techniques. Les dépendances explosent, les arbitrages se multiplient, la responsabilité se dilue.
Dans certains groupes, on observe des SI composés de 200 à 300 microservices, incapables de délivrer plus vite qu’avant.La rigidité monolithique a été remplacée par une anarchie distribuée, souvent plus coûteuse, plus fragile et moins compréhensible.
Vers un équilibre pragmatique : penser valeur avant architecture
La question n’est donc pas monolithe ou microservices, mais où, quand et pourquoi découper.
La clé réside dans un découpage guidé par la maturité métier, et non par les tendances technologiques.
- Utiliser le Domain-Driven Design (DDD) pour identifier les bounded contexts réels
- Conserver les monolithes (ERP, core systems) sur les domaines :
- fortement réglementés
- stables
- mutualisés (paie, fiscalité, comptabilité)
- Exposer ces cœurs via des APIs claires et gouvernées
- Modulariser uniquement là où la valeur métier est différenciante ou volatile
Pour l’orchestration, privilégier des outils adaptés :
- BPM pour les processus hybrides humains / systèmes
- Event-driven pour les cas réellement asynchrones
- En se concentrant sur les 80 % de cas métiers structurants, sans sur-ingénierie
Côté organisation, cela implique :
- Une gouvernance d’architecture explicite (ADR, arbitrages assumés)
- Un upskiIling croisé IT / métier
- Des trajectoires progressives : monolithes modulaires, faiblement couplés, capables d’évoluer vers plus de granularité quand la maturité le justifie
Conclusion – 2026 : la fin des dogmes, le retour du discernement
En 2026, les entreprises les plus performantes ne seront ni totalement monolithiques, ni entièrement composables.
Elles seront hybrides par choix, et non par accident.
Elles auront compris que :
- la modularité est un moyen, pas une fin
- l’agilité ne se mesure pas au nombre de microservices
- la vraie dette n’est pas technique, mais métier et organisationnelle
Avec l’essor de l’observabilité avancée, de l’IA d’aide à l’orchestration et du pilotage par la valeur (value stream mapping, TTM réel, coût par capacité métier), une nouvelle maturité émerge : celle du discernement architectural.
Chez Groove, nous observons quotidiennement cette bascule : les organisations qui réussissent sont celles qui réconcilient stratégie métier, architecture et exécution, sans céder aux effets de mode. Elles construisent des SI capables d’évoluer, sans se désintégrer.
L’avenir n’appartient ni aux monolithes figés, ni aux architectures éclatées à l’extrême.
Il appartient aux SI pensés comme des systèmes vivants, équilibrés, gouvernés, et alignés sur ce qui compte vraiment : la valeur créée pour le métier.
