Monolithe intégré et services autonomes : deux réponses opposées au partage de concepts

Imagine une suite logicielle de commerce en ligne : un service de catalogue, un service de paiement, un service d’expédition, un service de support client. Très vite, une évidence s’impose : tous ces services parlent des mêmes choses. Une « boutique ». Un « client ». Une « commande ». L’utilisateur, lui, n’en voit qu’une : sa boutique, qui a des produits, des transactions, des colis et des tickets de support.

Ce problème n’a rien de spécifique au commerce. Une suite bureautique partage le « document » et l’« espace de travail » entre édition, partage et messagerie. Un ERP partage le « client » et la « commande » entre ventes, comptabilité et logistique. Une plateforme de développement partage le « projet » et l’« environnement » entre gestion de code, déploiement et feature flags. Un système d’information bancaire partage le « compte » et le « titulaire » entre des dizaines d’applications. Partout, la même question structure l’architecture : qui est propriétaire des concepts que tout le monde manipule ?

La réponse engage tout : la capacité à livrer les services séparément, la fluidité de l’expérience intégrée, le coût d’évolution du système, et jusqu’à l’organisation des équipes. À la fin de ce chapitre, tu sauras reconnaître les deux modèles canoniques qui dominent le marché, expliquer leurs forces et leurs faiblesses, manipuler leurs trade-offs sur des scénarios concrets, et comprendre pourquoi aucun des deux ne suffit quand on veut à la fois des briques autonomes et une expérience intégrée.

Le problème des concepts transverses

Commençons par préciser le problème, parce qu’il est plus subtil qu’il n’en a l’air.

Le service de paiement a besoin de rattacher ses transactions à quelque chose : appelons-le une boutique. Le service de catalogue organise ses produits par boutique aussi. Le service d’expédition rattache ses colis à des commandes, elles-mêmes passées dans une boutique. Ces concepts se ressemblent énormément. Même nom, même intuition, même position dans la hiérarchie : l’organisation possède des boutiques, la boutique contient des ressources.

La tentation est immédiate : « c’est le même concept, modélisons-le une seule fois ». C’est précisément cette tentation qu’il faut examiner, parce que les deux grandes familles d’architecture du marché y répondent de manière opposée. Et aucune des deux réponses n’est une erreur : ce sont deux optimisations cohérentes d’objectifs différents.

Modèle 1 : le monolithe intégré

Le premier modèle est celui des suites logicielles intégrées : ERP, forges de développement tout-en-un, suites de gestion. Le concept partagé y est une entité centrale unique, stockée une seule fois, dont toutes les fonctionnalités dépendent : le catalogue pend de la boutique, les transactions pendent de la boutique, les expéditions pendent de la boutique, les tickets pendent de la boutique.

Les bénéfices sont réels et immédiats :

• Intégration parfaite. Une page « boutique » affiche les produits, les ventes, les colis et les tickets sans appel inter-services, sans synchronisation, sans incohérence possible. La navigation est fluide parce que tout est déjà joint.
• Un seul modèle à apprendre. Pour l’utilisateur comme pour le développeur, il n’existe qu’une définition de « boutique », avec un seul cycle de vie.
• Transactions triviales. Créer une boutique et son catalogue par défaut dans la même transaction de base de données : aucun protocole distribué à inventer.
• Cohérence garantie par construction. Une transaction ne peut pas référencer une boutique inexistante : la contrainte d’intégrité est dans le schéma.

Le coût est tout aussi réel, mais différé :

• Impossible de livrer une brique séparément. Le service de paiement ne peut pas exister sans le noyau qui définit la boutique. Tu ne peux pas le proposer en produit autonome, ni le remplacer par un meilleur composant du marché, ni l’ouvrir à une adoption indépendante.
• Couplage d’évolution. Toute modification de l’entité centrale impacte potentiellement toutes les fonctionnalités. Le schéma de la « boutique » devient le goulot d’étranglement de toutes les équipes.
• Échelle organisationnelle limitée. Dix équipes qui travaillent sur le même noyau se marchent dessus.

La variante disciplinée : le monolithe modulaire

Avant de passer au modèle opposé, mentionnons une variante importante : le monolithe modulaire. Même livrable unique, même base de données, mais des frontières logiques strictes entre modules : le module paiement n’accède au module boutique que par une interface interne explicite, jamais en joignant ses tables directement.

C’est un excellent choix de départ : il garde les bénéfices du monolithe (transactions, intégration, simplicité opérationnelle) tout en préparant les frontières qui permettront, un jour, d’extraire un module en service. La plupart des migrations réussies vers les modèles distribués partent d’un monolithe modulaire, pas d’un monolithe spaghetti. Retiens cette idée : les frontières logiques précèdent les frontières physiques ; nous y reviendrons au chapitre 4.

Modèle 2 : les services autonomes

Le second modèle est celui des grands fournisseurs de cloud public et des écosystèmes best-of-breed. Ici, chaque service possède ses propres ressources et ne connaît rien des autres. Le service de stockage a ses conteneurs, le service de calcul a ses instances, le service de base de données a ses clusters. Il n’existe aucune entité globale que les services partageraient.

Comment l’utilisateur s’y retrouve-t-il ? Par trois mécanismes de fédération a posteriori :

1. Des identifiants normalisés. Chaque ressource possède un nom unique structuré selon une convention globale (un schéma d’URI ou de nom hiérarchique). N’importe quel outil peut désigner n’importe quelle ressource de n’importe quel service sans ambiguïté.
2. Des étiquettes (tags). Des paires clé-valeur libres, posées sur les ressources. L’équivalent décentralisé du regroupement : tu poses boutique=ma-boutique sur tes ressources dans chaque service, et un outil de regroupement les retrouve.
3. Une console d’agrégation. Une couche de présentation au-dessus des services, qui interroge chacun et reconstruit une vue unifiée. L’intégration n’est pas dans le modèle de données : elle est recalculée à l’affichage.

Les bénéfices sont symétriques aux coûts du monolithe :

• Chaque service vit sa vie. Il se conçoit, se déploie, se versionne et se vend séparément. Une équipe par service, des cycles de release indépendants.
• Évolution locale. Modifier le modèle interne d’un service n’impacte personne, tant que les identifiants restent stables.
• Remplaçabilité. Le client peut composer son système avec le meilleur service de chaque catégorie, et en changer.
• Échelle organisationnelle prouvée. C’est le modèle qui a permis à des catalogues de centaines de services de croître pendant vingt ans.

Et les coûts sont symétriques aux bénéfices du monolithe :

• L’expérience intégrée est un chantier permanent. Chaque vue transverse (facturation par boutique, suppression d’une boutique entière, droits d’accès par boutique) doit être construite explicitement au-dessus des services, et maintenue.
• La cohérence est molle. Rien ne garantit qu’une étiquette boutique=ma-boutique est posée partout, ni orthographiée pareil. Les ressources orphelines et les regroupements incomplets sont le quotidien.
• Le concept partagé n’existe nulle part. La « boutique » n’est qu’une convention. Aucun service ne peut s’appuyer dessus contractuellement.

Manipule les trade-offs

La théorie est posée ; maintenant, éprouve-la. Pour chaque scénario ci-dessous, compare ce qui se passe dans chacun des deux modèles. Ta mission : trouve le scénario où le monolithe gagne nettement, puis celui où il perd définitivement.

L’incompatibilité fondamentale

Pose les deux modèles côte à côte et le dilemme apparaît :

	Monolithe intégré	Services autonomes
Concept partagé	Entité unique, centrale, contractuelle	Inexistant (convention de tags)
Livrer une brique seule	Impossible	Naturel
Expérience intégrée	Native	Reconstruite, coûteuse
Cohérence transverse	Garantie par le schéma	Molle, best effort
Évolution d’un service	Couplée au noyau	Libre
Échelle organisationnelle	Une équipe-noyau goulot	Une équipe par service

Si ta stratégie exige les deux : des briques autonomes, adoptables et remplaçables une à une, et une expérience intégrée où le concept partagé existe vraiment, alors aucun des deux modèles canoniques ne suffit. Il en faut un troisième, qui emprunte aux deux sans hériter de leurs défauts rédhibitoires. C’est le modèle fédéré, objet du prochain chapitre.

Vérifie ta compréhension

Quiz

1. 1. Dans le monolithe intégré, pourquoi est-il impossible de livrer une brique séparément ?

   • Parce que le code est trop volumineux pour être extrait
   • Parce que chaque fonctionnalité dépend structurellement de l'entité centrale partagée
   • Parce que les licences logicielles l'interdisent
   • Parce que les services n'ont pas d'API
   Valider

2. 2. Qu'est-ce qui distingue le monolithe modulaire du monolithe classique ?

   • Il est déployé dans plusieurs conteneurs
   • Il a une base de données par module
   • Des frontières logiques strictes entre modules, qui ne communiquent que par interfaces explicites
   • Il est écrit dans plusieurs langages
   Valider

3. 3. Dans le modèle services autonomes, comment l'utilisateur regroupe-t-il des ressources de services différents ?

   • Grâce à une entité partagée par tous les services
   • Il ne peut pas : les ressources sont définitivement isolées
   • Par des identifiants normalisés et des étiquettes, agrégés par une couche de présentation
   • Par une base de données commune à tous les services
   Valider

4. 4. Que prédit la loi de Conway pour un système dont le noyau est partagé entre dix équipes ?

   • Le système sera plus robuste grâce aux revues croisées
   • Chaque évolution du noyau deviendra une négociation inter-équipes, et le noyau un goulot
   • Les équipes convergeront naturellement vers un modèle unique
   • La loi de Conway ne s'applique qu'aux microservices
   Valider

Ce qu’il faut retenir

• Les concepts transverses (client, boutique, commande, projet) sont la question structurante de tout système multi-services : qui en est propriétaire ?
• Le monolithe intégré centralise : intégration et cohérence parfaites, mais aucune brique ne peut vivre seule et le noyau devient le goulot des évolutions et des équipes.
• Le monolithe modulaire est la variante disciplinée : mêmes bénéfices, frontières logiques prêtes pour une extraction future.
• Les services autonomes décentralisent : chaque service est libre, livrable et remplaçable seul, mais l’expérience intégrée doit être reconstruite et la cohérence transverse reste molle.
• Les deux modèles optimisent des objectifs opposés ; quand la stratégie exige les deux à la fois, il faut un troisième modèle : la fédération, au chapitre suivant.