Ce que l'industrie appelle "coordination" est, dans la plupart des cas, une compensation humaine déguisée en architecture.

Ce n'est pas une critique des ingénieurs qui ont construit ces systèmes. C'est une observation sur l'axiome qui les sous-tend.

Ce qu'on appelle coordination

Quand un service A doit attendre que B soit prêt avant d'agir, on dit qu'ils se "coordonnent". Quand Kafka rebalance ses consumer groups après une panne, on dit que le cluster se "réorganise". Quand un orchestrateur Kubernetes redémarre un pod tombé, on dit que le système "s'autorépare".

Regardons ce qui se passe réellement.

A attend B parce qu'un humain a écrit un healthcheck, une boucle de retry, un backoff exponentiel. Kafka rebalance parce qu'un humain a défini des partitions, des consumer groups, des règles de réattribution. Kubernetes redémarre parce qu'un humain a écrit un runbook qui a été traduit en manifest YAML.

La "coordination" n'est pas une propriété émergente du système. C'est le résultat d'une intention humaine encodée dans des couches de configuration, d'opération et de discipline.

La stack comme accumulation de compensations

Une architecture distribuée classique ressemble à ceci : un broker pour transporter les messages, une base de données pour persister l'état, un cache pour compenser la latence de la base, un orchestrateur pour compenser les pannes des services, un système d'observabilité pour compenser l'opacité de l'ensemble, une équipe ops pour compenser ce que l'observabilité ne couvre pas.

Chaque couche compense une limite de la précédente. Ce n'est pas de la résilience. C'est de la dette structurelle rendue opérationnelle.

Kafka est un exemple particulièrement révélateur. C'est un outil remarquablement bien conçu pour ce qu'il fait : transporter des flux de données de façon durable et scalable. Mais Kafka ne garantit pas la cohérence sémantique. Il ne sait pas ce que signifient les messages qu'il transporte. La sémantique — l'intention, la causalité, l'idempotence — est laissée à la charge des équipes qui l'utilisent. Ce sont elles qui "coordonnent". Kafka transporte.

Pourquoi ça tient quand même

Ces systèmes fonctionnent. C'est indéniable. Des milliers d'entreprises font tourner des architectures de ce type en production, à grande échelle, depuis des années.

Ils fonctionnent parce que les équipes qui les opèrent sont compétentes, disciplinées, et disponibles. Parce que les runbooks sont maintenus. Parce que les alertes sont calibrées. Parce que quelqu'un répond à 3h du matin.

Ce n'est pas un défaut humain. C'est un défaut d'axiome. L'axiome implicite de ces architectures est : la cohérence sera maintenue par l'effort combiné de la structure et des humains. L'effort humain n'est pas un supplément optionnel. Il est structurellement requis.

Une question d'axiome, pas d'outil

Le problème n'est pas Kafka. Pas Kubernetes. Pas les service meshes. Ces outils résolvent correctement les problèmes qu'ils ont été conçus pour résoudre, dans le cadre de l'axiome qui les a produits.

L'axiome est celui-ci : un système distribué est un ensemble de services qui s'échangent des messages, dont la cohérence est garantie par coordination externe.

Ce que j'explore avec Sphaera est une rupture axiomatique : un système distribué est un ensemble d'entités souveraines dont la cohérence émerge de contraintes locales, sans coordination centrale, sans vérité globale, sans arbitre.

Dans ce modèle, il n'y a rien à coordonner. Chaque entité observe localement ce dont elle dépend. Elle existe si les conditions sont réunies. Elle disparaît si elles ne le sont plus. La cohérence n'est pas maintenue : elle est déduite.

Ce que ça change

Quand la résilience est structurelle et non opérationnelle, le coût change de nature. On ne paie plus en discipline humaine permanente. On paie en rigueur axiomatique initiale.

Ce déplacement n'est pas sans exigences. Concevoir sans coordinateur central demande de penser autrement — non pas en termes de flux à orchestrer, mais en termes d'invariants à respecter.

La coordination n'a pas disparu. Elle n'a jamais existé comme propriété du système. Elle a toujours été une projection humaine sur une structure qui en avait besoin.

Changer l'axiome, c'est concevoir une structure qui n'en a pas besoin.