Médiation

La médiation couvre tout ce que la plateforme fait entre la réception d’un appel et sa transmission au service : router, transformer, composer, protéger. C’est le pilier qui rend la plateforme utile au quotidien, et celui par lequel la logique métier migre hors des services si aucune limite n’est posée.

Le périmètre

Le routage. Un chemin public stable devant une implémentation qui change d’adresse, de version ou de technologie. Le même point d’indirection sert aux migrations progressives, voir interne et externe.

La transformation. Adapter un format, renommer des champs, normaliser des dates. Utile pour absorber un existant, coûteux quand il devient la norme.

La composition. Un appel qui en déclenche plusieurs. Mécanique, elle reste une policy. Dès qu’elle décide, valeur par défaut, gestion différenciée des échecs, elle devient un service.

La protection. Rate limiting, quotas, timeouts, retries, circuit breaker : ce qui empêche un consommateur d’en pénaliser un autre et une panne de se propager. Les mécanismes et leurs réglages sont dans la résilience.

La limite

Une transformation a sa place dans la plateforme quand elle est mécanique et réversible. Elle n’y a plus sa place dès qu’elle contient une décision qu’un métier pourrait vouloir changer.

Le critère tient en une question : si cette règle change, qui doit en être informé ? Si la réponse est un métier, la règle appartient à un service, avec des tests et un propriétaire.

Pourquoi la limite cède

Modifier une policy de gateway prend une heure, modifier le service prend un cycle de livraison. Sous contrainte de délai, l’arbitrage se fait toujours dans le même sens, et il se refait à chaque urgence. Quelques années plus tard, la plateforme contient des dizaines de règles sans tests ni propriétaire, écrites dans un langage de policy que les équipes métier ne lisent pas.

Le contre-feu est procédural : toute policy qui contient une valeur métier passe en revue et porte le nom de son demandeur. L’inventaire de ces policies est un livrable d’audit à part entière.

Les protections, précisément

Le rate limiting protège la capacité sur une fenêtre courte. Il ne protège pas de la mauvaise utilisation : un consommateur qui boucle sous le seuil passe.

Le quota répartit la ressource sur une période longue. Fixer la part de chacun est une décision d’offre, pas un réglage technique, même si elle s’exprime dans la configuration.

Le retry ne vaut que sur les opérations idempotentes. Appliqué à une création, il fabrique des doublons dont le symptôme apparaît des semaines plus tard dans les données.

Le timeout se règle de l’extérieur vers l’intérieur : chaque étage attend un peu moins longtemps que son appelant, sinon les attentes s’empilent au lieu d’échouer proprement.

Le trafic vers les modèles de langage ajoute un cas particulier : le coût d’un appel n’y dépend pas du nombre d’appels mais du volume de jetons consommés. Les quotas doivent alors se compter en jetons, et l’attribution du coût par équipe consommatrice devient une fonction de la plateforme, et les principales gateways du marché le portent désormais.

Traverser un protocole

Exposer une file de messages en REST, un service SOAP en JSON, un flux d’événements en API interrogeable : ces passages relèvent de la médiation et partagent un piège. Ils changent la sémantique en même temps que le format. La garantie de livraison d’une file dépend du courtier et de sa configuration, de l’au-plus-une-fois à l’exactement-une-fois. L’API REST posée devant n’en expose qu’une, souvent la plus flatteuse, et l’écart se paie en doublons chez le consommateur.

Quand la sémantique change, la médiation doit l’exposer plutôt que la masquer : un identifiant d’idempotence dans le contrat coûte une ligne et évite la classe entière de défauts.