theKB.eu : anatomie d'un site construit pour les humains et pour les agents

theKB.eu publie 347 fiches de veille sur l'IA, les agents de codage et l'évolution du SDLC, en 5 langues, soit environ 7 500 pages. Et pourtant il n'y a ni CMS, ni back-office, ni base de données éditée à la main. Le tout tient en trois étages : une base de connaissance en fichiers, un pipeline de publication, et un serveur MCP sans interface graphique. Voici comment, et surtout pourquoi, c'est construit ainsi.

1. La base de connaissance : des fichiers, pas une base de données

Tout part d'un dépôt git privé, mon « second cerveau » de veille. Chaque article lu devient une fiche : un fichier Markdown avec 10 sections canoniques dans un ordre figé (titre, date, URL, mots-clés, auteurs, ton, pense-bêtes, résumé de 400 mots… et un graphe de connaissance). Le graphe de connaissance est la vraie particularité : chaque fiche déclare ses entités (typées selon une ontologie fermée de 8 types : personne, organisation, technologie, concept, méthodologie, événement, lieu, document) et ses triples sujet-prédicat-objet, avec un registre fermé de 30 prédicats. Aujourd'hui : 2 827 entités et 4 983 triples, tissés à travers les 347 fiches.

Le dépôt suit une architecture médaillon logique : les fiches sont le bronze, et des scripts Python (sans aucune dépendance, stdlib uniquement) régénèrent les artefacts silver : index, catalogue tabulaire, base de connaissance consolidée. Règle d'or : les artefacts dérivés ne s'éditent jamais à la main, ils se régénèrent. Un linter bloquant garantit le format ; un « doctor » vérifie la cohérence globale. C'est une base de connaissance conçue pour être manipulée par des IA, à coût en tokens minimal : tout se cherche au grep avant de lire le moindre fichier.

Pourquoi cet investissement dans une ontologie maison, alors que les modèles savent « tout » ? Parce que c'est précisément ce qui ne se commoditise pas. Tony Seale le formule bien, et nous en avons tiré le même diagnostic côté SFEIR : les frameworks d'agents s'effondrent les uns après les autres, mais l'ontologie et les données restent le seul actif non-commodité d'un système sémantique. Et c'est la mécanique du compounding knowledge décrite par Kieran Klaassen, celle-là même du Compound Engineering : une connaissance capturée une fois, structurée, continue de payer, à condition d'être stockée là où on la retrouve et maintenue vraie par des gates automatiques.

2. La création de contenu : un pipeline, pas un CMS

Le site n'est qu'une couche de publication au-dessus de ce dépôt. Une seule commande (npm run publish) déroule toute la chaîne :

1. Export et normalisation : un script rejoue la logique de parsing du dépôt de veille et produit trois fichiers JSON validés par schéma : fiches, entités, triples. Critère de succès : 100 % des fiches parsées sans perte de section, graphe reconstruit à l'identique.
2. Traduction 100 % automatique : le français est la source, traduit vers l'anglais, puis l'anglais sert de pivot vers l'allemand, l'espagnol et l'italien. Aucune relecture humaine : la qualité vit dans le pipeline, avec deux garde-fous. Un glossaire non-traduisible contraignant (les termes comme « Compound Engineering », les noms propres, les noms d'entités du graphe sont injectés dans le prompt et vérifiés après coup ; un terme protégé traduit fait rejeter et re-traduire la fiche). Et une passe de QA par LLM qui note fidélité, terminologie et hallucination ; une fiche qui ne passe pas reste noindex, hors sitemap.
3. Build statique : Astro génère les ~7 500 pages avec tout l'attirail SEO/GEO : JSON-LD (TechArticle relié aux entités du graphe par @id), hreflang sur 5 langues, sitemaps segmentés, RSS par langue et par thème, llms.txt, et un jumeau Markdown de chaque fiche ({url}.md) servi en text/markdown.
4. Double destination : le même build alimente le site (Cloudflare Pages) et le plan de données du serveur MCP (D1 pour le requêtable, R2 pour les blobs Markdown, Vectorize pour les embeddings). Une assertion finale vérifie que le commit de veille exposé par le MCP est exactement celui du build du site : une seule version de la vérité pour les deux surfaces.

Le slug d'une fiche est identique dans les 5 langues, seul le préfixe de langue change. C'est un identifiant technique stable, copiable-collable par un agent, et le hreflang devient un simple échange de préfixe.

3. Le serveur MCP : la troisième surface

mcp.thekb.eu expose la base de connaissance en Model Context Protocol : 11 outils en lecture seule. Sept outils cœur, anonymes : recherche, récupération de fiche, dernières publications, thématiques, tags, statistiques. Et quatre outils graphe, sous clé API : fiches liées, recherche d'entités, fiche d'entité, voisinage de graphe. La recherche est hybride : plein-texte BM25 (avec dé-diacritisation, pour un corpus bilingue) en parallèle d'une recherche sémantique multilingue par embeddings, fusionnées par Reciprocal Rank Fusion, avec dégradation silencieuse en lexical pur si le vectoriel est indisponible.

Point d'architecture important : le worker MCP ne lit jamais le dépôt de veille. Il ne connaît que D1 et R2, alimentés par le build. C'est ce qui garantit qu'un agent et un humain qui consultent theKB au même moment voient exactement le même corpus.

Détail signifiant : les entités « mineures » (citées moins de 3 fois) n'ont pas de page web (elles alourdiraient le site pour un intérêt SEO nul), mais restent entièrement résolvables via le MCP. Surface curée pour les humains, graphe exhaustif pour les agents.

4. La vision : pas d'IHM

C'est le choix le plus délibéré du projet : le serveur MCP n'a pas d'interface graphique, et n'en aura pas. Pas de barre de recherche « pour tester », pas de playground, pas de console web. L'interface, c'est l'agent de l'utilisateur. On s'y connecte depuis n'importe quel outil compatible MCP (Claude Code, un IDE, un agent maison), et les demandes se font en langage naturel, en ligne de commande :

claude mcp add --transport http thekb https://mcp.thekb.eu/

> que dit theKB sur le compound engineering ?

Ce parti pris s'appuie sur une conviction que ma veille documente depuis deux ans. D'abord, MCP est en train de remplacer le navigateur comme couche d'interaction : quand un agent peut interroger un service directement, l'interface web devient un rendu optionnel, pas le point d'entrée. Ensuite, les environnements s'effondrent vers le terminal : Cobus Greyling décrit l'effondrement de l'IDE face au CLI agentique. La couche d'abstraction visuelle disparaît dès que l'intention peut s'exprimer en langage naturel. Enfin, le contenu lui-même migre vers des formats natifs agents : Cloudflare pousse le Markdown comme format de réponse pour les agents via la négociation de contenu HTTP, exactement ce que font les jumeaux .md et le llms.txt de theKB.

Il existe un courant inverse : MCP-UI, porté par Block/Goose, réinjecte des composants web interactifs dans les conversations d'agents. C'est pertinent pour du commerce ou des dashboards. Pour une base de connaissance, j'assume l'inverse : le savoir n'a pas besoin de widgets, il a besoin d'être interrogeable, citable et vérifiable. D'autant que la découverte elle-même se déplace : l'Answer Engine Optimization supplante le SEO classique : être cité par les moteurs de réponse compte désormais autant qu'être visité. D'où la double ergonomie de theKB : les humains ont un site rapide et lisible ; les crawlers IA ont un accès explicitement autorisé (licence CC BY 4.0, attribution requise) ; les agents ont un protocole.

En guise de conclusion : la mise en abyme

Le test ultime de cette architecture, c'est cet article lui-même : j'ai retrouvé les arguments de la section précédente en interrogeant theKB via son propre serveur MCP, depuis un terminal, sans ouvrir une seule page web. La boucle est bouclée : une base de connaissance construite par des agents, publiée pour des humains, et interrogeable par les agents des autres.

---

Sources

• theKB.eu : 347 fiches, 2 827 entités, 4 983 triples, 5 langues. Contenu sous licence CC BY 4.0. Serveur MCP : https://mcp.thekb.eu/, documentation sur thekb.eu/developers/mcp.
• Fiches de veille citées (theKB.eu, CC BY 4.0) : Tony Seale sur l'ontologie comme actif non-commodité ; Kieran Klaassen sur le cycle de compounding knowledge ; « MCP remplace le navigateur » (LogRocket) ; Cobus Greyling sur l'effondrement IDE/CLI ; Cloudflare sur le Markdown pour agents ; Block/Goose sur MCP-UI ; Graphite sur l'Answer Engine Optimization.

Note : theKB.eu est un projet personnel de veille de Didier Girard, distinct du site sfeir.com. Les chiffres (347 fiches, 2 827 entités, 4 983 triples) sont ceux du corpus à la date de publication et évoluent à chaque vague de veille.