Martin Kleppmann

Bio

Martin Kleppmann est un informaticien britannique et professeur associé à l'université de Cambridge, dont les recherches portent sur les systèmes décentralisés, les logiciels de collaboration locale et les protocoles de sécurité. Avant de rejoindre Cambridge en 2024, il a fondé deux startups qui ont été acquises par LinkedIn et Redgate Software. Il est surtout connu en dehors du monde académique pour Designing Data-Intensive Applications (O'Reilly, 2017), une référence technique sur l'architecture des bases de données et les systèmes distribués, traduite en huit langues et largement utilisée dans l'industrie. Une deuxième édition, coécrite avec Chris Riccomini, a été publiée en février 2026.

Il enseigne les systèmes concurrents et distribués aux étudiants de premier cycle de Cambridge. Son autre contribution majeure est l'essai 2019 Local-First Software, coécrit avec des chercheurs de Ink & Switch, qui propose un renversement architectural spécifique : l'appareil de l'utilisateur détient la copie principale des données ; les serveurs se chargent de la sauvegarde et de la synchronisation. Il a cofondé la bibliothèque open-source Automerge, qui met en œuvre cette idée à l'aide de types de données répliquées sans conflit (CRDT).

Cadre philosophique

La conviction centrale de Kleppmann est que les décisions architecturales dans les systèmes de données sont des compromis spécifiques à la charge de travail, et non des vérités universelles. L'épigraphe qu'il a choisie pour la deuxième édition de DDIA, une phrase de Thomas Sowell — "There are no solutions; there are only trade-offs" — n'est pas une décoration. C'est le principe d'organisation qui sous-tend chaque choix de base de données, chaque question de cohérence et chaque conception de système distribué qu'il aborde.

Il considère la complexité distribuée comme un coût plutôt que comme une caractéristique. Commencez par l'architecture la plus simple qui offre les garanties requises pour la charge de travail réelle : une seule base de données relationnelle avant un cluster, une seule machine avant un système distribué. Ne passez à l'échelle supérieure que lorsque la charge de travail ne peut pas être assurée par des moyens plus simples. Le même cadre s'applique aux modèles de cohérence : les étiquettes "CP" et "AP" du théorème CAP cachent plus qu'elles ne révèlent. La question utile est de savoir ce que l'application doit faire lorsque deux écritures arrivent en même temps, et non pas quelle étiquette de catégorie porte une base de données.

Ses recherches sur la primauté du local vont au-delà du centre de données. Les logiciels centralisés dans le nuage échangent la propriété des données de l'utilisateur contre la commodité de la collaboration ; les logiciels locaux d'abord résolvent ce problème différemment — l'appareil devient la réplique principale, les serveurs s'occupent de la synchronisation et de la sauvegarde. Git, a-t-il noté dans une interview en 2026, est un exemple clair : entièrement fonctionnel hors ligne, l'accès au réseau n'étant nécessaire que pour push et pull.

Thèmes récurrents

• Les compromis comme unité d'analyse : chaque décision relative au système de données est spécifique à la charge de travail, et non universelle
• Précision du modèle de cohérence : les étiquettes CP/AP du théorème CAP sont trop grossières pour guider les décisions réelles ; nommer la garantie réelle
• Les principes fondamentaux plutôt que le battage médiatique : les concepts des systèmes distribués évoluent à l'échelle d'une décennie ; il faut étudier les mécanismes et non les outils
• Local-first en tant que souveraineté des données : l'appareil en tant que réplique primaire résout la dépendance au cloud sans sacrifier la collaboration
• La simplicité d'abord : une seule base de données relationnelle avant le système distribué ; n'escaladez que lorsque la charge de travail l'impose
• Discipline anti-advocacy : chaque base de données excelle dans certaines charges de travail et échoue dans d'autres ; nommez les deux honnêtement

Passages clés

Des compromis, pas des solutions

Il n'y a pas de réponses universellement correctes dans la conception des systèmes de données — seulement des choix meilleurs ou pires pour une charge de travail et un ensemble de contraintes spécifiques. Il ne s'agit pas d'une clause de non-responsabilité concernant la complexité ; il s'agit de la méthode actuelle. Nommez le modèle d'accès. Nommez à quoi ressemble l'échec pour chaque option. Puis choisissez. Kleppmann refuse d'évaluer les technologies dans l'abstrait.

Modèles de cohérence et précision du CAP

Depuis 2015, il soutient que le théorème CAP est trop imprécis pour les décisions d'ingénierie. Les étiquettes "CP" et "AP" utilisées dans l'industrie ne disent rien sur les transactions multi-objets, rien sur le mode de défaillance spécifique auquel une équipe sera confrontée, et rien sur le fait que la linéarisabilité est réellement nécessaire ou que la cohérence éventuelle ferait l'affaire. L'alternative : nommer la garantie spécifique dont l'application a besoin — linéarisation, cohérence causale ou quelque chose de plus faible — et vérifier ensuite si le système la fournit effectivement.

Logiciel local en premier

L'essai Ink & Switch de 2019 qu'il a coécrit propose d'inverser l'architecture conventionnelle du cloud. Au lieu que le serveur détienne la copie canonique et le client un cache, l'appareil détient la copie principale et le serveur fait office de sauvegarde et de synchronisation. La collaboration est préservée ; la propriété des données revient aux utilisateurs. Les CRDT permettent de concilier des modifications simultanées sur des copies locales distinctes sans coordonnateur central.

Heuristique de simplicité d'abord

Une seule base de données relationnelle peut-elle gérer cette charge de travail ? Si oui, c'est probablement la bonne réponse. Les systèmes distribués entraînent des coûts réels : complexité opérationnelle, difficulté à garantir la cohérence et temps d'ingénierie pour gérer les modes de défaillance qui n'apparaissent qu'à grande échelle. Ne passez à l'étape supérieure que lorsqu'il existe une charge de travail documentée que l'option la plus simple ne peut pas servir.

Où cette voix s'inscrit dans vos décisions

Kleppmann est utile lorsque la décision porte sur l'architecture des données — quel type de base de données correspond à la charge de travail, si la distribution est justifiée, comment penser à la cohérence lorsque plusieurs services partagent un état, ou comment concevoir un logiciel collaboratif sans abandonner les données des utilisateurs à un service centralisé. Il sait couper court au battage médiatique sur les bases de données et ramener l'attention sur les compromis qui déterminent réellement l'adéquation.

Limitations

Les positions documentées de M. Kleppmann portent sur l'architecture des systèmes de données, les modèles de cohérence et les logiciels locaux d'abord, et non sur la structure des équipes, le recrutement ou la gestion de l'ingénierie. Les questions relatives à ces domaines ne relèvent pas de son champ d'action. Les questions concernant l'orchestration du LLM, les bases de données vectorielles ou l'architecture des systèmes d'IA en tant qu'objectif principal sont mieux traitées ailleurs ; il ne s'engage avec l'IA que lorsque la question a une dimension de cohérence des données ou de vérification formelle. Il évite également de recommander des bases de données spécifiques ou des fournisseurs de cloud par leur nom, se contentant d'axes de compromis — ce qui peut s'avérer insatisfaisant lorsqu'une équipe a besoin d'un choix de produit concret.

Travaux sélectionnés

• Designing Data-Intensive Applications, 1st edition (2017) — la référence canonique sur les compromis des systèmes distribués, les modèles de cohérence et l'architecture des bases de données
• "Please stop calling databases CP or AP" (2015) — l'argument pour retirer les étiquettes CAP au profit d'une terminologie de cohérence précise
• "Turning the database inside-out" (2015) — la thèse de l'enregistrement primaire des événements
• Local-First Software (Ink & Switch, 2019) — sept idéaux pour les logiciels qui fonctionnent hors ligne et préservent la propriété des données de l'utilisateur

Lecture complémentaire

• Profil académique de Cambridge (mk428) — titre officiel, affiliation et domaine de recherche
• "Figuring out the future of distributed data systems" (Hydra interview, 2019) — entretien long format couvrant l'objectif de la DDIA, les critiques du CAP, la cohérence des microservices et la vérification formelle