AIEndpoint — un standard ouvert de point de terminaison `/ai` pour que les agents IA comprennent instantanément tous les services web

Bonjour.

En développant avec l’IA et en consultant d’autres sites ou tests de services, il m’est souvent arrivé d’épuiser très vite mes tokens et de devoir attendre une réinitialisation.
En y réfléchissant, je me suis dit que l’IA était peut-être en train de « regarder un écran lisible par des humains, avec des yeux humains ».
Je me suis donc demandé s’il ne fallait pas une alternative standard pour réduire les tokens et accélérer le temps de réponse de l’IA.

Aujourd’hui, les agents IA procèdent essentiellement de trois façons pour lire un service web :

1. Scraping HTML — plus de 80 % du contenu renvoyé n’est que bruit publicitaire, navigation et scripts (~ dizaines de milliers de tokens)
2. Lecture de la documentation d’API puis hardcoding — dès que le service change, tout casse
3. Utilisation de MCP — très peu de services le proposent, et c’est orienté développeurs

J’ai donc créé ce projet en open source pour proposer la convention suivante.

• robots.txt (1994) → dire au crawler « ne venez pas ici »
• sitemap.xml (2005) → dire au crawler « c’est ici »
• /ai (2026) → dire à l’agent IA « voici ce que nous pouvons faire » ← c’est ce qui manquait

(En travaillant dessus, j’ai découvert que robots.txt avait lui aussi été proposé à l’origine par le logiciel engineer néerlandais Martijn Koster. Il aurait été conçu à l’époque pour résoudre le problème des premiers crawlers web qui surchargeaient trop les serveurs.)

Je voulais que les propriétaires de services web implémentent GET /ai afin que :

• les agents IA puissent lire immédiatement des informations structurées
• ils puissent évoluer vers l’appel direct des API
• sans scraping, sans parsing de documentation, sans gaspillage de tokens

Vous pouvez le vérifier ici.

curl https://api.aiendpoint.dev/ai | jq .  

Voici ce qui a été réalisé jusqu’à présent (avec Claude, Codex)

• Spécification ouverte (Apache 2.0) — https://github.com/aiendpoint/platform
• Registre — aiendpoint.dev (inscription·recherche)
• Validateur — aiendpoint.dev/validate (score de 0 à 100)
• Serveur MCP — recherche directe dans le registre depuis Claude/Cursor
• Compétence Claude Code — ajout automatique de /ai à un service existant (10 minutes)

Sans serveur MCP, le registre n’est qu’un simple site web.
Avec un serveur MCP, si vous demandez à Claude « trouve-moi une API météo utilisable sans authentification »,
il fournit immédiatement une réponse structurée. L’idée centrale était de boucler cette boucle.

Les retours sur la spécification sont les bienvenus.
De quoi aurait-on besoin pour amener les services à implémenter /ai ?
J’aimerais que nous rejoignions cette initiative et que nous construisions ensemble ce standard.
Tout comme robots.txt a été proposé pour la première fois aux Pays-Bas, ne pourrions-nous pas, nous aussi, créer une nouvelle dynamique ?

GitHub: https://github.com/aiendpoint/platform

[aliveornot]

llm.txt a déjà été proposé, et il existe aussi un article de recherche qui étudie sa validité. Selon Naver, du moins pour l’instant, on dirait que les agents ne le consultent pas vraiment non plus.

[aliveornot]

D’après Naver, donc… il a écrit ça en dormant ? Il faut écrire : « Selon l’article en question ».

[bejoyfuuul]

Haha, c’est tout à fait vrai.
Si llms.txt met l’accent sur la description pour aider les agents à « comprendre » un service,
/ai, lui, se concentre sur la manière pour l’IA de « l’utiliser ». En gros, ça lui dit : « l’API de notre service s’appelle comme ça ». Et si on utilise MCP avec ça, on peut d’abord « parcourir » la façon d’utiliser le site concerné (en économisant des tokens) avant de commencer.

Comme il est difficile de faire participer directement tout le monde, nous avons d’abord séparé des versions « enregistrement direct » et « communauté ». Du coup, lors de l’utilisation de /ai MCP, les sites qui ont déjà été « explorés » par quelqu’un peuvent être abordés de manière plus légère et plus rapide !

Merci pour votre remarque ~

[vndk2234]

Si /ai se standardise, est-ce qu’on ne pourrait pas voir apparaître, à l’inverse, un outil qui se contente d’extraire /ai pour afficher une page agréable à lire, sans publicité ?

[dohyun682]

C’est intéressant ! Du coup, on risque aussi de voir apparaître des publicités glissées dans /ai, non ?

[bejoyfuuul]

Dans ce cas, il faudra donc ajouter une logique qui fait baisser le score lorsqu’un contenu publicitaire est détecté !

[bejoyfuuul]

Oui, c’est tout à fait possible. Je pense aussi qu’en raison de l’usage des agents (trafic), du traitement, du coût des tokens, etc., le web lui-même pourrait, d’une certaine manière, redevenir plus léger, un peu comme à l’époque de telnet. (Se concentrer sur le contenu plutôt que sur l’habillage.) Un peu comme le GeekNews actuel, d’ailleurs. (C’est une supposition !)