Livre blanc — Microservices & API : architectures modernes pour l’agilité

Livre blanc · Avril 2026

Microservices & API : architectures modernes pour l'agilité

Découper juste, contracter bien, opérer sereinement

« Le but n'a jamais été d'avoir des microservices. Le but est de livrer indépendamment — les microservices n'en sont qu'un moyen, et pas toujours le bon. »

1 question

6 contrats

90 jours

avant de découper : « qui doit pouvoir livrer sans demander la permission ? »

Les règles d'API qui font qu'un écosystème tient : conception, version, données, erreurs, sécurité, cycle de vie

Le plan d'action, de la carte des domaines au premier service extrait en production

Ce livre blanc s'appuie sur les missions d'architecture du réseau Clarendis ; il complète « DevOps à l'échelle », dont il partage les fondations.

Sommaire

Avant-propos 03 Synthèse exécutive — le document en dix affirmations 04 Votre parcours de lecture 06 1 Le malentendu microservices Le but est de livrer indépendamment · Ce que dit le retour d'expérience · Le monolithe n'est pas l'ennemi · Le test des trois conditions 07 2 Les fondations : domaines et frontières Découper par le métier, jamais par la technique · Les contextes bornés · La carte des domaines · Frontières et loi de Conway 13 3 L'API comme contrat Design first · Les six contrats · Versionner sans casser · REST, événements, ou les deux · La gouvernance légère 19 4 L'architecture en pratique Synchrone ou asynchrone · Chacun ses données · La résilience par conception · Le front face à la constellation 25 5 Opérer la constellation La passerelle et le maillage · L'observabilité distribuée · Le déploiement progressif · Ce que la plateforme doit fournir 31 6 Les angles morts Le monolithe distribué · Les transactions qui traversent · Les coûts de la constellation · La sécurité entre les services · Le test des cinq questions 37 7 Le plan d'action 90 jours D'où partez-vous ? · J1-J30 : la carte des domaines · J31-J60 : le contrat et la première extraction · J61-J90 : en production, mesuré · Le tableau de bord en cinq nombres 43 Passer à l'exécution 49 Annexes — Glossaire, références, à propos de Clarendis 50

Avant-propos

Dix ans après la vague, les microservices ont produit deux populations d'organisations : celles qui livrent plus vite qu'avant, et celles qui ont troqué un monolithe compréhensible contre une constellation incompréhensible — plus lente, plus chère, plus fragile. La différence entre les deux ne tient ni au talent ni aux outils : elle tient à l'ordre des décisions. Les premières ont découpé leur métier, puis contracté leurs interfaces, puis outillé l'exploitation. Les secondes ont commencé par la technique.

Ce livre blanc suit le bon ordre. Les frontières d'abord (chapitre 2) : on ne découpe pas un système, on découpe un métier. Les contrats ensuite (chapitre 3) : une API n'est pas de la tuyauterie, c'est une promesse dont d'autres dépendent. L'architecture et l'exploitation enfin (chapitres 4-5), et les angles morts que les conférences ne racontent pas (chapitre 6).

Une précision d'honnêteté intellectuelle : nous ne vendons ni plateforme d'API, ni cloud, ni progiciel — et nous ne croyons pas que les microservices soient la bonne réponse par défaut. Une partie de nos missions consiste précisément à déconseiller le découpage, ou à le limiter. Le chapitre 1 assume cette position, références à l'appui.

Comment lire ce document. Les chapitres sont autonomes. Si le débat « faut-il découper ? » fait rage chez vous, le chapitre 1 le tranchera avec trois conditions vérifiables. Si le découpage est acquis mais que les frontières se disputent, le chapitre 2 est votre méthode. Si vos API se multiplient sans règles, le chapitre 3 est votre gouvernance. Chaque chapitre se clôt par le même encart, ce que ça change pour vous , décliné pour trois lecteurs : le dirigeant, le DSI, l'architecte. C'est volontairement le même sujet vu sous trois angles, car ces architectures échouent là où stratégie, budget et conception ne se parlent pas.

Bonne lecture, et bonnes frontières.

Cédric Guittard

Anna Hoang

cedric.guittard@clarendis.com

anna.hoang@clarendis.com

pour l'équipe Clarendis

Synthèse exécutive

Le document en dix affirmations. Chacune est développée dans le chapitre indiqué.

1

2

Les microservices sont un moyen, jamais un but. Le but est la livraison indépendante : que chaque équipe puisse déployer sans demander la permission. Si vous l'obtenez avec un monolithe modulaire, vous avez gagné — en plus simple. (Chapitre 1)

Trois conditions avant de découper : des frontières métier stables, une plateforme d'exploitation qui tient la route, et des équipes capables de posséder leurs services en production. Il en manque une ? Le découpage attend. (Chapitre 1)

3

4

On découpe un métier, pas un système. Les bonnes frontières sont les contextes bornés du domaine — là où le vocabulaire change de sens. Une frontière technique (le « service PDF ») fabrique du couplage ; une frontière métier l'élimine. (Chapitre 2)

L'API est un contrat, pas de la tuyauterie. Elle se conçoit avant de se coder (design first), se versionne sans casser ses consommateurs, et se gère comme un produit — avec ses utilisateurs, sa documentation et son cycle de vie. (Chapitre 3)

5

6

La gouvernance d'API gagnante est légère et outillée : des règles peu nombreuses, vérifiées automatiquement dans le pipeline, un annuaire vivant — pas un comité d'architecture qui relit des PDF. (Chapitre 3)

L'asynchrone est le découplage réel. Deux services qui s'appellent en synchrone tombent ensemble. Les événements découplent les destins — au prix d'une cohérence différée qu'il faut assumer métier par métier. (Chapitre 4)

7

8

Chaque service possède ses données — sans exception. La base partagée est le couplage le plus dur qui soit : elle transforme la constellation en monolithe distribué. La donnée circule par contrats, jamais par accès direct. (Chapitre 4)

Une constellation ne s'opère pas comme un monolithe. Passerelle, observabilité distribuée avec traçage, déploiement progressif : ce socle n'est pas optionnel — c'est le prix d'entrée, et il est fourni par la plateforme, pas réinventé par chaque équipe. (Chapitre 5)

9

10

Le monolithe distribué est le pire des deux mondes. Des services qui se déploient ensemble, s'appellent en cascade et partagent leurs données ont tous les coûts des microservices et aucun bénéfice. Le chapitre 6 donne les tests pour le détecter. (Chapitre 6)

On migre par étranglement, jamais par grand soir. Le premier service s'extrait du monolithe en 90 jours, en production, mesuré — et chaque extraction suivante se justifie par le flux, pas par la pureté architecturale. (Chapitre 7)

Par où commencer selon votre situation :

Le monolithe vous ralentit, le débat fait rage. Chapitre 1 (les trois conditions), puis chapitre 2 : la carte des domaines tranchera mieux que les opinions.

Les services existent, les API prolifèrent sans règles. Chapitre 3 en entier — les six contrats et la gouvernance légère — puis le §6.1 pour vérifier que vous n'avez pas construit un monolithe distribué.

La constellation coûte cher et casse souvent. Chapitres 5 et 6 : le socle d'exploitation et les angles morts — puis le tableau de bord du chapitre 7 pour objectiver la suite.

Votre parcours de lecture Microservices & API

Votre parcours de lecture

Trois itinéraires balisés. Les encarts « Ce que ça change pour vous », en fin de chaque chapitre, sont écrits pour votre siège.

DIR Dirigeant 20 minutes

DSI DSI / CTO 1 h 30

ARC Architecte 2 heures

01 Synthèse exécutive

Document complet recommandé. Votre chemin critique :

Vous concevez les frontières. Votre chemin :

02 chapitre 1 (les trois conditions — et le coût d'un découpage prématuré)

01 chapitre 1 (le cadre de décision, à faire adopter tel quel)

01 chapitre 2 en entier (contextes bornés, carte des domaines)

03 chapitre 6, §6.3 (ce que coûte réellement une constellation)

02 chapitre 2 (la carte des domaines : l'atelier à organiser)

02 chapitre 3 (les six contrats, le versionnement)

04 chapitre 7, §7.4 (les cinq nombres à mettre à votre ordre du jour).

03 chapitre 4 (sync/async, données, résilience)

03 chapitre 5 (le socle que votre plateforme doit fournir)

04 les sept encarts « Architecte », en fin de chapitre.

Vous saurez quand dire oui, quand dire non, et comment vérifier.

04 chapitre 6 (coûts, sécurité, monolithe distribué)

05 chapitre 7 en entier — le plan est le vôtre.

Ce que vous êtes venu chercher

Besoin

Où

Sous quelle forme

Trancher le débat « faut-il découper ? »

Chapitre 1

Trois conditions vérifiables, et l'alternative du monolithe modulaire, assumée

Une méthode de découpage

Chapitre 2

Les contextes bornés sans jargon, et l'atelier « carte des domaines » en une journée

Des règles d'API qui tiennent

Chapitre 3

Les six contrats, le versionnement sans casse, la gouvernance légère outillée

Un plan exécutable demain

Chapitre 7

90 jours en trois temps, la première extraction en production, cinq nombres de pilotage

Chapitre 1

Le malentendu microservices

1

Avant de découper quoi que ce soit, il faut savoir pourquoi on découpe — et accepter que la réponse honnête soit parfois : on ne découpe pas.

1.1 Le but est de livrer indépendamment

L e mot « microservices » décrit une forme — des petits services déployés séparément — et la forme a fini par masquer la fonction. La fonction, la seule qui justifie le coût, tient en une phrase : permettre à chaque équipe de livrer sa partie sans coordonner, sans attendre, sans demander la permission. C'est une propriété organisationnelle avant d'être une propriété technique — la livraison indépendante, celle-là même que mesure le lead time de notre livre blanc « DevOps à l'échelle ».

Cette reformulation change tout, parce qu'elle rend le but atteignable par plusieurs chemins. Un monolithe bien modularisé, avec des frontières internes nettes et un déploiement rapide, offre une large part de la livraison indépendante — sans réseau entre les modules, sans cohérence distribuée, sans constellation à opérer. Les microservices n'ajoutent qu'une chose : l'indépendance de déploiement et de mise à l'échelle . Si vous n'avez pas besoin de cette chose précise, vous n'avez pas besoin de leurs coûts.

La question de gouvernance n'est donc jamais « faut-il faire des microservices ? » mais : « qui, chez nous, doit pouvoir livrer sans demander la permission — et qu'est-ce qui l'en empêche aujourd'hui ? » Si la réponse est « les frontières du code », le chapitre 2 vous concerne. Si la réponse est « les validations et les environnements », c'est un problème DevOps, et le découpage ne le résoudra pas : il le multipliera.

1

Chapitre 1 — Le malentendu microservices Microservices & API

1.2 Ce que dit le retour d'expérience — dix ans après la vague

Le corpus est désormais riche : les textes fondateurs (Lewis & Fowler, 2014 ; Sam Newman, Building Microservices ), dix ans de retours publics — y compris les retours en arrière assumés de grandes plateformes qui ont re-fusionné des services trop fins — et nos propres missions. Quatre constats robustes :

Le bénéfice est organisationnel

Le coût est permanent

Là où les microservices réussissent, le gain constaté est d'abord humain : des équipes autonomes, des mises en production banalisées, un recrutement facilité. Le gain purement technique (mise à l'échelle fine) ne concerne qu'une minorité de systèmes.

Réseau entre les modules, cohérence différée, observabilité distribuée, versionnement de contrats : ces coûts ne s'amortissent pas — ils durent autant que la constellation. Ils doivent être payés par un bénéfice qui dure aussi.

La taille des services n'est pas le sujet

Le retour en arrière est honorable

« Micro » a fait beaucoup de dégâts : des services de cinquante lignes, par centaines. Le bon grain de découpe est le contexte métier (chapitre 2) — souvent bien plus gros qu'on ne croit. Mieux vaut huit services justes que quatre-vingts services fins.

Re-fusionner deux services trop bavards n'est pas un échec : c'est de l'architecture. Les organisations matures refactorent leurs frontières comme leur code — dans les deux sens.

1.3 Le monolithe n'est pas l'ennemi

Le vrai adversaire n'a jamais été le monolithe : c'est le couplage non maîtrisé — et il prospère aussi bien dans une constellation que dans un monolithe. Un monolithe modulaire, aux frontières internes alignées sur les domaines (chapitre 2), déployé plusieurs fois par jour, est une excellente architecture — et le meilleur point de départ d'une éventuelle extraction future : les modules bien bornés d'aujourd'hui sont les services faciles à extraire de demain. C'est la stratégie que nous recommandons par défaut aux organisations qui n'ont pas encore les trois conditions du §1.4 : modularisez d'abord, extrayez ensuite, si et quand le besoin se prouve.

1

Chapitre 1 — Le malentendu microservices Microservices & API

1.4 Le test des trois conditions

Trois conditions, toutes vérifiables, toutes nécessaires. Le découpage ne se lance que quand les trois sont vertes — et chacune se construit si elle manque :

1.

Des frontières métier stables et connues. Vous savez dessiner la carte des domaines (chapitre 2), et elle ne change pas tous les trimestres. Un métier encore en exploration — produit jeune, pivots fréquents — se découpe trop tôt : les frontières bougeront, et refactorer à travers un réseau coûte dix fois plus qu'à travers un module.

2.

Une plateforme d'exploitation qui tient la route. Pipeline unique vers la production, environnements à la demande, observabilité avec traçage, déploiement progressif (chapitre 5). Sans ce socle, chaque service ajouté est une charge d'exploitation artisanale de plus — c'est le prérequis DevOps, au sens strict.

3.

Des équipes capables de posséder leurs services en production. « You build it, you run it » avec ses conditions (astreinte outillée, rotation suffisante) : un service sans propriétaire de production devient un orphelin — et les orphelins peuplent les post-mortems.

La conviction qui structure ce document

Le découpage se justifie par le flux, jamais par la mode. Chaque frontière créée doit rendre une livraison indépendante à une équipe nommée — sinon elle ajoute du réseau sans retirer de couplage. Les frontières d'abord (chapitre 2), les contrats ensuite (chapitre 3), la technique en dernier (chapitres 4-5).

Un mot sur le cas le plus fréquent en mission : le monolithe légitimement vieillissant, que tout le monde veut quitter d'un coup. La réponse est la même qu'au livre blanc DevOps : le figuier étrangleur — on extrait un premier contexte, en production, mesuré (chapitre 7), et chaque extraction suivante se décide sur les chiffres de la précédente. Le grand soir de réécriture, lui, a un taux d'échec qui ne se discute plus.

1

Chapitre 1 — Le malentendu microservices Microservices & API

La décision en une carte

Découper, moduler ou attendre — l'arbre de décision

« Qui doit pouvoir livrer sans demander la permission — et qu'est-ce qui l'en empêche ? »

L'empêchement est le processus

L'empêchement est le code, les 3 conditions manquent

L'empêchement est le code, les 3 conditions sont vertes

Validations, environnements, pipeline : problème DevOps. Traitez le flux d'abord — le découpage multiplierait le problème.

Monolithe modulaire : frontières internes par domaines, déploiement rapide — et on reparle d'extraction dans un an.

Extraction par étranglement : un contexte à la fois, en production, mesuré (chapitre 7).

1

3

8 > 80

But : la livraison indépendante — les microservices n'en sont qu'un moyen

Conditions avant de découper : frontières stables, plateforme solide, équipes propriétaires

Huit services justes valent mieux que quatre-vingts services fins

Ce que ça change pour vous

DIR

DSI

ARC

Dirigeant. Refusez tout budget « migration microservices » qui ne répond pas à la question du §1.1 : qui pourra livrer sans permission, et qu'est-ce qui l'en empêche aujourd'hui ? C'est le test à cent mille euros la minute.

DSI. Faites adopter l'arbre de décision ci-dessus comme cadre officiel : il dépassionne le débat, il donne un chemin honorable au monolithe modulaire — et il vous protège des découpages de conférence.

Architecte. Votre livrable de ce chapitre : la liste de ce qui empêche la livraison indépendante, classée code / processus / organisation. Elle décide de tout le reste — et elle vaut plus que n'importe quel schéma cible.

1

Chapitre 1 — Le malentendu microservices Microservices & API

Deux trajectoires, sur le terrain

Cas A — le découpage prématuré

Une scale-up B2C, 40 développeurs, un produit encore en pivot : 60 services en deux ans, découpés par « fonctionnalités » au fil des sprints. Résultat : chaque évolution métier traverse cinq services, les mises en production se coordonnent par tableur, et deux personnes seulement comprennent la topologie. Le retour : re-fusion en 9 contextes métier, un an de travail — le coût du découpage prématuré est celui d'un aller-retour.

Cas B — l'extraction disciplinée

Un acteur du e-commerce B2B, monolithe de douze ans, 80 développeurs : carte des domaines d'abord, modularisation interne pendant six mois, puis extraction du contexte « tarification » — celui qui bloquait le plus de livraisons. Un service en production à J90, lead time de l'équipe tarification divisé par trois, et une règle d'or : pas d'extraction suivante tant que la précédente n'a pas prouvé son gain en chiffres. Quatre ans plus tard : onze services, pas un de plus — et un monolithe résiduel en paix.

La différence entre les deux cas ne tient ni à la taille ni au secteur : elle tient à l'ordre des décisions — et au courage de dire non. C'est exactement ce que les chapitres suivants outillent : les frontières (chapitre 2), les contrats (chapitre 3), puis seulement la technique.

Le test du tableur de mise en production

Un diagnostic gratuit : si vos mises en production se coordonnent dans un tableur ou un fil de discussion — quel que soit le nombre de services — vous n'avez pas de livraison indépendante. Vous avez un monolithe, distribué ou non. Le nombre de lignes de ce tableur est votre premier indicateur : il doit tendre vers zéro.

1

Chapitre 1 — Le malentendu microservices Microservices & API

Vocabulaire — les cinq mots du document

Terme

Ce qu'il désigne ici

Livraison indépendante

La capacité d'une équipe à mettre en production sa partie sans coordination avec les autres — le but de tout le document

Constellation

L'ensemble des services et de leurs liens — le mot rappelle qu'on n'opère pas des étoiles isolées, mais leurs relations

Monolithe modulaire

Un déployable unique aux frontières internes strictes, alignées sur les domaines — l'alternative honorable, et le meilleur point de départ

Contexte borné

La frontière métier à l'intérieur de laquelle un vocabulaire garde un sens unique — le bon grain de découpe (chapitre 2)

Monolithe distribué

Des services qui se déploient ensemble et tombent ensemble — tous les coûts, aucun bénéfice (chapitre 6)

Le lien avec la collection

Ce document suppose les fondations de « DevOps à l'échelle » : la plateforme, la golden path, les métriques DORA. Si votre chaîne de livraison n'est pas en place, lisez-le d'abord — des microservices sans plateforme, c'est une constellation sans télescope.

Chapitre 2

Les fondations : domaines et frontières

2

On ne découpe pas un système : on découpe un métier. Ce chapitre donne la méthode — les contextes bornés sans le jargon, et l'atelier d'une journée qui produit la carte des domaines.

2.1 Découper par le métier, jamais par la technique

Le réflexe naturel des équipes techniques est de découper par couches ou par fonctions techniques : le « service PDF », le « service notifications », le « service données clients ». Chacun semble raisonnable ; l'ensemble est un piège, car chaque évolution métier traverse alors plusieurs services — une nouvelle offre commerciale touche le service catalogue, le service prix, le service PDF et le service notifications, qui doivent se coordonner et se déployer ensemble. On a recréé le couplage, avec du réseau en plus.

La bonne unité de découpe est inverse : un périmètre métier complet, verticalement — ses écrans, sa logique, ses données — tel qu'une évolution typique de ce métier reste à l'intérieur. C'est l'intuition du Domain-Driven Design (Eric Evans, 2003), dont un seul concept suffit à ce document : le contexte borné.

Le test pratique, sans jargon : prenez vos vingt dernières évolutions métier et comptez combien de services (ou de modules) chacune a traversés. La médiane doit être 1. À 2-3, vos frontières sont discutables ; au-delà, elles sont fausses — quel que soit le soin mis à les implémenter.

2

Chapitre 2 — Domaines et frontières Microservices & API

2.2 Le contexte borné, sans le jargon

L'idée tient en une observation : dans toute entreprise, les mêmes mots changent de sens selon les équipes. Un « client » n'est pas la même chose pour le commerce (un prospect avec un pipeline), pour la facturation (un compte avec un SIREN et des conditions de paiement) et pour le support (un contrat avec des droits ouverts). Forcer ces trois « clients » dans un modèle unique produit l'objet obèse que tout le monde connaît — cinquante champs, dont chaque équipe n'utilise que dix, et que personne n'ose modifier.

Le contexte borné prend l'observation au sérieux : la frontière passe là où le vocabulaire change de sens. À l'intérieur d'un contexte, chaque terme a une définition unique et un modèle taillé pour son usage ; entre les contextes, on traduit — explicitement, par contrat (chapitre 3). Le « client » du commerce et celui de la facturation deviennent deux modèles distincts, reliés par un identifiant commun et des événements.

Pourquoi c'est la bonne frontière de service : parce qu'elle est stable (le sens des mots d'un métier change lentement), humaine (elle correspond à des équipes et à des experts identifiables — la loi de Conway travaille pour vous), et vérifiable (le test des vingt évolutions du §2.1). Aucune frontière technique n'a ces trois propriétés.

Les indices d'une frontière — à chercher dans vos réunions

— Le glossaire diverge : deux équipes emploient le même mot en se comprenant de travers, ou deux mots pour la même chose.

— Les experts changent : la personne qui fait autorité n'est plus la même — vous avez changé de domaine.

— Les rythmes divergent : un pan du système change chaque semaine, l'autre deux fois par an — les marier dans un même déployable, c'est imposer le rythme du plus lent.

— Les exigences divergent : disponibilité, conformité, volumétrie — des contraintes différentes justifient des frontières.

2

Chapitre 2 — Domaines et frontières Microservices & API

2.3 La carte des domaines : l'atelier d'une journée

La carte des domaines est le livrable central du chapitre — une page qui nomme les contextes, leurs frontières et leurs relations. Elle se produit en un atelier d'une journée, avec les bonnes personnes : les experts métier de chaque périmètre (pas seulement leurs managers), les tech leads, un animateur qui sait se taire. La technique d'animation la plus efficace à notre connaissance est l'event storming (Alberto Brandolini) : on raconte le métier comme une suite d'événements — « commande passée », « paiement reçu », « colis expédié » — sur un mur, et les frontières apparaissent d'elles-mêmes là où les événements changent de vocabulaire et d'acteurs.

Trois règles font la qualité du résultat :

1.

Le mur raconte le métier, pas le système. Interdiction de nommer des tables, des écrans ou des services existants pendant la première moitié : l'existant contaminerait la carte — c'est précisément lui qu'on veut pouvoir juger.

2.

Les désaccords sont des données. Quand deux experts se disputent le sens d'un mot, ne tranchez pas : notez — vous venez probablement de trouver une frontière.

3.

Chaque contexte reçoit trois attributs : un propriétaire (une équipe, pas un comité), un statut stratégique (cœur différenciant / support / générique — on n'investit pas pareil dans les trois), et un rythme de changement constaté. Ces attributs décident de l'ordre des extractions (chapitre 7).

Le piège de l'exercice : viser la carte parfaite. Une carte à 80 % juste, produite en un jour et corrigée en marchant, vaut mieux que six mois de modélisation — les frontières se valident en livrant, pas en délibérant.