Architecture cloud-native : les patterns qui tiennent en production

La première décision d'architecture n'est pas « comment découper en microservices » mais « faut-il découper ». Un monolithe modulaire, bien structuré en domaines internes avec des frontières nettes, reste le choix le plus efficace pour une équipe de taille modérée : un seul déploiement, une seule base de code, un débogage simple. Le découpage en services se justifie quand plusieurs équipes doivent livrer indépendamment, quand des composants ont des besoins de montée en charge très différents, ou quand des contraintes de résilience imposent d'isoler des périmètres critiques. Découper trop tôt, c'est payer immédiatement le coût de la distribution — latence réseau, cohérence des données, complexité opérationnelle — sans en percevoir les bénéfices organisationnels.

Pour faire évoluer un système existant, le pattern du strangler fig demeure la stratégie la plus sûre : placer une couche de routage devant le système historique, puis en extraire les capacités une à une vers de nouveaux services, en commençant par celles qui évoluent le plus souvent. Chaque extraction est une étape courte, réversible et mesurable. À l'opposé, la réécriture intégrale en parallèle — le big bang — cumule les risques : effet tunnel, double maintenance prolongée et bascule brutale. Le critère de découpage le plus fiable reste le domaine métier, au sens du domain-driven design : un service par capacité métier cohérente, jamais un service par table de base de données ni par écran.

Relier des services par des appels synchrones en cascade recrée un monolithe distribué : la panne du maillon le plus faible se propage à l'ensemble. L'architecture événementielle — via un bus de messages tel que Kafka ou NATS — découple les producteurs des consommateurs : un service publie un fait métier, les autres y réagissent à leur rythme. On y gagne en résilience et en extensibilité, au prix d'une exigence nouvelle : accepter la cohérence à terme, concevoir des consommateurs idempotents et outiller le rejeu des messages. Ce compromis mérite d'être explicité aux équipes métier, car il change la manière dont le système se comporte en cas d'incident.

Dans un système distribué, comprendre un incident exige de suivre une requête à travers des dizaines de services. Les trois piliers — journaux structurés, métriques, traces distribuées — doivent être en place dès le premier service, pas après le premier incident majeur. OpenTelemetry s'est imposé comme le standard d'instrumentation, avec l'avantage décisif de découpler la collecte du choix de l'outil d'analyse. Quant au service mesh (Istio, Linkerd), il apporte le chiffrement mutuel entre services, les politiques de réessai et la télémétrie sans modifier le code applicatif ; il se justifie pleinement à partir de quelques dizaines de services, rarement avant.

Le sujet qui décide réellement du succès d'une architecture en services est la gestion des données. Le principe d'une base de données par service protège l'autonomie des équipes, mais il fait disparaître deux commodités du monolithe : les transactions globales et les jointures entre domaines. Il faut donc concevoir explicitement ce qui les remplace — des sagas pour orchestrer les processus qui traversent plusieurs services, avec des compensations en cas d'échec ; et des vues de lecture dédiées, alimentées par les événements, pour les besoins de requêtage transverse et de restitution. Négliger cette conception conduit au pire des deux mondes : des services officiellement indépendants mais reliés en sous-main par une base partagée, qui cumule le couplage du monolithe et la complexité du distribué. Mieux vaut assumer un découpage plus grossier que des frontières de données mal tracées.

La loi de Conway se vérifie systématiquement : l'architecture d'un système finit par refléter la structure de communication de l'organisation qui le construit. Découper un système en vingt services confiés à une équipe unique de six personnes produit de la friction sans autonomie ; à l'inverse, faire travailler huit équipes sur un monolithe unique produit des files d'attente de livraison. Le bon ordre des opérations consiste à définir d'abord les périmètres de responsabilité des équipes, puis à aligner les frontières logicielles sur ces périmètres. En dernière analyse, une architecture cloud-native réussie est moins une affaire d'outillage que de cohérence entre le système, les équipes et le rythme de livraison visé.