Microservices : quand ils valent leur complexité
Les microservices promettent l'agilité. Ils apportent d'abord des réseaux, des versions et des pannes partielles à gérer. La question n'est pas « est-ce moderne ? » mais « quel problème cela résout-il chez nous ? ».
Faut-il passer aux microservices ? La question arrive souvent sous la forme d’une évidence : le système actuel est lent à faire évoluer, les livraisons sont risquées, les concurrents « sont passés aux microservices ». Une architecture microservices découpe une application en services indépendants, déployés séparément, qui communiquent par le réseau. Elle peut résoudre de vrais problèmes. Elle en crée aussi de nouveaux, qui ne disparaissent jamais. Ce guide aide à savoir de quel côté penche la balance chez vous.
Un problème d’organisation avant d’être technique
En 1968, Melvin Conway observait que les organisations conçoivent des systèmes qui reproduisent leur structure de communication. La loi de Conway explique pourquoi les microservices ont d’abord séduit les grandes entreprises du numérique : avec des dizaines d’équipes travaillant sur un même produit, un code unique devenait un goulot. Chaque équipe attendait les autres pour livrer. Découper le système en services alignés sur les équipes permettait à chacune d’avancer à son rythme.
Le corollaire est moins souvent cité : si vous avez une ou deux équipes, le goulot n’existe pas. Vous paierez le coût des microservices sans en tirer leur principal bénéfice.
Les microservices échangent un problème de coordination entre équipes contre un problème de coordination entre machines. L’échange n’est intéressant que si le premier problème existe.
Ce que coûte vraiment un système distribué
Le coût d’une architecture microservices est en grande partie fixe : il faut le payer dès le premier service extrait. Il comprend plusieurs postes que l’on sous-estime souvent.
- Des équipes qui livrent indépendamment.
- Une montée en charge ciblée sur les parties sollicitées.
- Des technologies adaptées à chaque service.
- Une panne confinée, si l’architecture est bien conçue.
- Des appels réseau qui échouent, ralentissent, se répètent.
- Une supervision et un traçage distribués, indispensables pour comprendre un incident.
- Des déploiements entièrement automatisés, faute de quoi la multiplication des services devient ingérable.
- La cohérence des données entre services, qui ne se règle plus par une transaction.
- La gestion des versions d’interface entre équipes.
Le dernier point de la colonne de droite est le plus sournois. Dans un monolithe, une modification qui casse un appel est détectée à la compilation ou aux tests. Entre deux services, elle peut passer inaperçue jusqu’en production, si les contrats d’interface ne sont pas testés.
Les signaux qui justifient le découpage
Plutôt qu’un choix de principe, nous recommandons d’attendre des signaux concrets, observables dans votre organisation.
- Plusieurs équipes modifient le même code et se bloquent mutuellement pour livrer.
- Une partie du système a des besoins de charge ou de disponibilité très différents du reste.
- Une partie doit évoluer beaucoup plus vite que les autres, ou être confiée à une équipe distincte.
- Une frontière métier est stable et bien comprise : on sait ce que fait ce domaine et ce qu’il ne fait pas.
- Vous disposez déjà d’un déploiement automatisé fiable et d’une supervision correcte.
Si aucun de ces signaux n’est présent, ou si seul le premier l’est sans les deux derniers, il est probablement trop tôt.
L’étape intermédiaire : le monolithe modulaire
Entre le monolithe enchevêtré et les microservices, il existe une étape souvent plus rentable : le monolithe modulaire. On garde un seul déploiement, mais on organise le code en modules aux frontières strictes, chacun avec ses données et une interface explicite. Les équipes travaillent sur des modules distincts ; les dépendances interdites sont vérifiées automatiquement.
Cette étape a deux avantages. Elle apporte une partie des bénéfices d’organisation sans le coût du réseau. Et elle prépare le terrain : le jour où un module doit devenir un service, ses frontières sont déjà tracées. Martin Fowler a résumé cette approche sous le nom de « monolith first » : commencer par un monolithe bien structuré, et n’extraire des services que lorsque les frontières se sont révélées.
Si vous décidez de découper
Procédez service par service, en commençant par une frontière claire et un bénéfice mesurable. Extrayez de préférence un domaine en périphérie, pas le cœur du système. Investissez d’abord dans le socle (déploiement, supervision, traçage) avant de multiplier les services. Et fixez dès le départ les règles d’interface : versionnement, rétrocompatibilité, tests de contrat.
Ce type de décision engage l’organisation autant que la technique. C’est pourquoi nous l’abordons dans notre expertise équipes déployées, et dans notre accompagnement de gouvernance des projets numériques, où l’architecture se décide avec ceux qui l’exploiteront.
Pour approfondir : Gouvernance & traçabilité
Questions fréquentes
Un monolithe est-il forcément une mauvaise architecture ?
Non. Un monolithe modulaire, avec des frontières internes claires, se déploie et se supervise simplement, et convient à beaucoup d'organisations. Il devient un problème quand de nombreuses équipes doivent livrer indépendamment, ou quand des parties du système ont des besoins de charge très différents.
Combien d'équipes faut-il pour justifier des microservices ?
Il n'y a pas de seuil universel. Le signal à surveiller est la gêne : des livraisons bloquées parce qu'une autre équipe n'est pas prête, des conflits fréquents dans le même code, des tests qui prennent des heures. Avec une ou deux petites équipes, ce signal apparaît rarement.
Peut-on revenir en arrière après une migration vers les microservices ?
Oui, et certaines organisations l'ont fait en regroupant des services trop fins. Ce retour coûte cher. Il vaut mieux découper progressivement, service par service, en vérifiant à chaque étape que le gain attendu est obtenu.