Choisir son modèle : grille de décision, signaux d’alerte et trajectoires de migration

Les trois premiers chapitres ont décrit les modèles ; celui-ci répond à la question pratique : lequel choisir, et comment changer d’avis sans tout casser ? Car c’est la réalité des systèmes : on ne choisit pas une fois pour toutes, on choisit pour un contexte, et le contexte change.

À la fin de ce chapitre, tu sauras pondérer les cinq critères qui dominent la décision, reconnaître les signaux d’alerte du mauvais choix, et dérouler les deux trajectoires de migration éprouvées vers le modèle fédéré.

Les cinq critères qui dominent la décision

Des dizaines de facteurs influencent le choix, mais cinq écrasent tous les autres :

1. La stratégie de distribution. Vendras-tu (ou ouvriras-tu) les services séparément ? C’est le critère le plus discriminant : s’il faut livrer à la découpe, le monolithe intégré est éliminé d’office, quelles que soient ses autres qualités.
2. Le nombre d’équipes. La loi de Conway ne se négocie pas : une ou deux équipes vivent très bien dans un monolithe ; dix équipes sur un noyau partagé se paralysent mutuellement.
3. L’exigence d’intégration. Si la vue unifiée est le produit (tableaux de bord transverses, navigation fluide entre domaines), il faut soit le monolithe, soit un plan de contrôle fédéré ; les services autonomes purs feront payer chaque écran intégré.
4. L’exigence de cohérence. Cohérence immédiate garantie : monolithe. Cohérence à terme acceptable : fédéré. Conventions best effort suffisantes : autonomes.
5. L’existant. Un monolithe sain qui fonctionne est un actif, pas une honte ; des services déjà éparpillés appellent une fédération, pas une réécriture centrale.

Éprouve la grille sur ton propre cas

Réponds aux cinq questions pour ton système (réel ou imaginaire) et observe la tendance. Ta mission : trouve une combinaison de réponses qui élimine le monolithe dès la première question, puis une qui rend le fédéré incontournable.

Les signaux d’alerte du mauvais choix

Les architectures ratées préviennent. Voici les symptômes à reconnaître, chacun pointant vers un diagnostic précis :

Les déploiements en convoi (lockstep). Tes services sont « indépendants » mais chaque release exige de les déployer ensemble, dans un ordre précis, après une réunion de coordination. Diagnostic : monolithe distribué, presque toujours causé par un shared kernel ou des contrats implicites. Tu paies le distribué sans l’autonomie ; il faut soit ré-assumer le monolithe, soit casser le noyau partagé.

Le backlog d’intégration qui enfle. Chaque trimestre, de nouvelles demandes « vue consolidée », « rapport transverse », « suppression globale », et chaque demande est un projet. Diagnostic : services autonomes face à un besoin d’intégration sous-estimé. La réponse durable n’est pas le n-ième écran d’agrégation, c’est un plan de contrôle fédéré.

Les ressources orphelines et les tags incohérents. Personne ne sait dire combien de « boutiques » existent vraiment, les audits trouvent des ressources sans propriétaire. Diagnostic : fédération par convention (tags) sans contrat. Il manque les références externes contractuelles et la réconciliation.

L’équipe-noyau goulot. Toutes les autres équipes attendent les évolutions du module central ; le backlog du noyau a six mois de profondeur. Diagnostic : monolithe au-delà de son échelle organisationnelle. C’est le signal de départ d’une extraction.

Trajectoire 1 : du monolithe vers le fédéré

La migration la plus fréquente, et la plus documentée. Elle suit le pattern du figuier étrangleur (strangler fig) : le nouveau système pousse autour de l’ancien, qui continue de fonctionner jusqu’à devenir remplaçable.

Les étapes, dans l’ordre :

1. Modulariser d’abord. Tracer les frontières logiques dans le monolithe (chapitre 1 : le monolithe modulaire). Aucune infrastructure nouvelle ; tout le travail est dans le code et les interfaces internes.
2. Extraire le module le plus autonome, celui qui a le moins de dépendances entrantes. Lui donner sa propre projection locale du concept partagé, alimentée au début par des appels au monolithe.
3. Introduire le contrat de fédération sur le service extrait : référence externe, upsert idempotent. Le monolithe devient son premier plan de contrôle de fait.
4. Répéter module par module, en commençant toujours par le plus découplé.
5. Promouvoir le noyau restant en plan de contrôle : quand il ne reste au centre que la topologie (organisations, boutiques, utilisateurs), le monolithe est devenu, sans bascule brutale, le référentiel central du modèle fédéré.

La beauté de cette trajectoire : chaque étape a de la valeur même si la migration s’arrête là. Un monolithe modulaire est meilleur qu’un spaghetti ; un service extrait rend de l’autonomie à une équipe ; le contrat de fédération sert aussi aux outils d’infrastructure.

Trajectoire 2 : des services autonomes vers le fédéré

Le chemin inverse, typique des écosystèmes qui ont grandi en mode best-of-breed et dont les clients réclament l’expérience unifiée.

1. Publier le langage commun : le vocabulaire minimal et le schéma d’identifiants (chapitre 3). C’est une décision de gouvernance, pas du code.
2. Ajouter le contrat de fédération à chaque service : champs external_ref et managed_by, upsert idempotent. Chaque service reste 100 % autonome ; il devient simplement fédérable.
3. Construire le plan de contrôle, d’abord en lecture (inventaire consolidé), puis en écriture (provisionnement).
4. Adopter l’existant : la procédure d’adoption du chapitre 2 apparie les entités historiques avec le référentiel, service par service, sans migration de données.

Vérifie ta compréhension

Quiz

1. 1. Quel critère élimine d'office le monolithe intégré, quelles que soient ses autres qualités ?

   • Plus de trois équipes de développement
   • La nécessité de vendre ou d'ouvrir les services séparément
   • Un besoin de haute disponibilité
   • Un budget d'infrastructure limité
   Valider

2. 2. Que diagnostiquent des déploiements systématiquement coordonnés entre services « indépendants » ?

   • Une infrastructure de CI/CD insuffisante
   • Un monolithe distribué : des services techniquement séparés mais logiquement soudés
   • Un manque de tests automatisés
   • Une équipe trop petite
   Valider

3. 3. Pourquoi la trajectoire du figuier étrangleur est-elle préférée au big bang ?

   • Elle est plus rapide à exécuter
   • Chaque étape produit de la valeur seule, et le système fonctionne en continu pendant la migration
   • Elle ne nécessite aucune modification du monolithe
   • Elle évite d'avoir à former les équipes
   Valider

4. 4. Pourquoi le shared kernel « transitoire » est-il un piège de migration ?

   • Parce qu'il est trop coûteux à développer
   • Parce que le provisoire qui fonctionne devient permanent : on construit un monolithe distribué en croyant migrer
   • Parce qu'il empêche les tests unitaires
   • Parce qu'il oblige à utiliser le même langage de programmation
   Valider

Ce qu’il faut retenir, du cours entier

• Chapitre 1 : le monolithe intégré et les services autonomes optimisent des objectifs opposés (intégration et cohérence contre autonomie et échelle) ; le choix structure le produit ET l’organisation.
• Chapitre 2 : le modèle fédéré réconcilie les deux : plan de contrôle souverain sur la topologie, services souverains sur leurs ressources, convergence par réconciliation idempotente.
• Chapitre 3 : les bounded contexts légitiment les définitions locales ; entre eux circulent identifiants et messages d’un langage publié, jamais des types partagés.
• Chapitre 4 : on choisit avec cinq critères (distribution, équipes, intégration, cohérence, existant), on surveille les signaux d’alerte, et on migre par étapes qui ont chacune leur valeur propre : jamais en big bang, jamais via un noyau partagé « transitoire ».
• La compétence durable n’est pas de connaître le « meilleur » modèle : c’est de savoir lire la stratégie d’un produit dans son architecture, et réciproquement.