datacampus.fr est devenu un site « agent-native »

En mars, on a lancé un serveur MCP intégré au site. Aujourd'hui, on est allés au bout de l'idée : faire de datacampus.fr un site nativement compréhensible par les agents IA, pas juste par les humains.

L'occasion : isitagentready.com, un scanner qui vérifie 19 standards de découverte et d'intégration agent. On l'a passé une première fois en début d'après-midi : niveau 1 sur 5. Quelques heures plus tard, après une série de petits commits ciblés : niveau 5 « Agent-Native » à un check près.

Ce qu'on a ajouté concrètement

Découvrabilité pour humains et bots

• Content-Signal dans robots.txt — on déclare formellement notre posture vis-à-vis des crawlers IA : ai-train=yes, search=yes, ai-input=yes. On n'a rien à cacher, autant le dire avec un standard plutôt qu'un commentaire libre.
• En-têtes Link RFC 8288 sur la home, pointant vers les ressources machine-readable : service-desc → MCP Card, describedby → A2A Agent Card, service-doc → index Agent Skills.
• Négociation de contenu Accept: text/markdown — n'importe quelle page du site renvoie une version Markdown propre quand un agent la demande. Implémenté en ~150 lignes de PHP vanilla, conversion à la volée via ob_start + DOMDocument, pas de dépendance, pas de fichier statique généré.

Cartes d'identité pour agents

• MCP Server Card à /.well-known/mcp.json — déjà en place depuis mars, signale notre serveur MCP et ses tools.
• A2A Agent Card à /.well-known/agent-card.json — spec Agent-to-Agent (Google) qui décrit Datacampus comme un agent invocable, avec ses cinq capacités et son endpoint streamable-http.
• Agent Skills index à /.well-known/agent-skills/ — trois SKILL.md documentés (estimer une configuration, recommander une offre, lister le catalogue) avec leurs schémas d'entrée et exemples curl. Format agentskills.io 0.2.0 avec digests sha256.
• API Catalog à /.well-known/api-catalog — format application/linkset+json (RFC 9727) qui référence le serveur MCP et l'API d'intensité carbone temps-réel.

Auth, signatures, et exécution dans le navigateur

• OAuth 2.0 discovery (RFC 8414) à /.well-known/oauth-authorization-server et Protected Resource Metadata (RFC 9728) à /.well-known/oauth-protected-resource — un agent qui voudra demain un accès authentifié au MCP saura quoi faire.
• Web Bot Auth — un JWKS Ed25519 publié à /.well-known/http-message-signatures-directory. Si on doit demain envoyer des requêtes en tant que bot, les sites cibles pourront vérifier nos signatures.
• WebMCP — un petit script (~110 lignes) qui appelle navigator.modelContext.registerTool() au chargement de la home et expose les cinq outils MCP directement au navigateur de l'agent. Spec WebMCP (encore en draft, support Chrome AI built-in).

Le résultat

Sur les 15 checks pertinents pour un site éditorial comme le nôtre, 14 passent au vert immédiatement après déploiement. Le quinzième (Content-Signal) est en cache côté scanner et passera au prochain rafraîchissement. Les checks « commerce » (x402, UCP, AP2) restent neutres : on ne vend rien à la pièce, ils n'ont pas de sens pour un hébergeur.

Pour un projet zéro-framework, sans Cloudflare devant, sans CDN, sans build tool exotique, c'est plutôt un bon résultat. Tout est servi par un Apache + PHP vanilla qui tient sur un VPS modeste.

Pourquoi on a fait ça

Trois raisons, dans cet ordre :

1. Cohérence. On parle de souveraineté numérique, d'open standards, de stack ouverte. Si un standard agent existe et qu'il est raisonnable, on l'implémente. C'est la même logique que pour les certifications (Positive Company, Green Web Foundation) : si on s'aligne sur des référentiels publics, autant le faire à fond.
2. Découvrabilité. Les agents qui crawlent le web cherchent ces signaux. Plus on est lisible par eux, plus on remonte dans les recommandations qu'ils font à leurs utilisateurs. C'est du SEO, version 2026.
3. Banc d'essai. Tous nos clients qui hébergent leur stack chez nous vont se poser ces questions dans les 12 prochains mois. Autant qu'on ait creusé chaque standard nous-mêmes, avec ses pièges (des rel types non IANA qui ne passent pas, des champs requis dans A2A qui ne sont pas évidents, des détails de Content-Type qui font la différence). On peut maintenant accompagner.

Ce qu'on n'a pas fait

On a sciemment laissé deux choses de côté :

• Les protocoles de paiement agent (x402, UCP, ACP, AP2) — on n'est pas un site de e-commerce. Ils n'ont pas leur place ici.
• Une vraie infrastructure OAuth en production sur le MCP. On a publié les métadonnées de découverte, mais le serveur MCP reste public et anonyme pour l'instant. Le jour où on aura besoin de scopes (mcp:write par exemple, pour créer des tickets ou modifier une configuration), tout est déjà câblé pour brancher datacampus.ninja en authorization server.

Vérifier par soi-même

Le rapport public, en temps réel : isitagentready.com/datacampus.fr. Et tous les fichiers /.well-known/* sont accessibles directement, sans authentification. Bonne fouille.