L’affirmation : un agent IA qui n’a jamais entendu parler d’AX peut découvrir, apprendre et parler le langage machine de ce site en une seule conversation — sans SDK, sans documentation, sans clé d’API.
Ne nous croyez pas sur parole. Collez l’invite ci-dessous dans n’importe quel agent capable de récupérer des URL — ChatGPT, Claude, Gemini ou le vôtre — et observez.
Fetch https://rainz.ai/llms.txt and read the "For AI agents" section at the end. Then execute what it teaches, zero-shot: 1. GET https://rainz.ai/wp-json/ax/v1/x?s=ax1+q.svc.pr+n%3D3 and show the raw reply. 2. Decode the reply using only the protocol's own hints. 3. Follow the nxu URL from the reply (GET, show raw). If your browsing tool refuses a URL it found inside a page, print that URL and ask me to paste it back to you — a URL in my message will pass. 4. If an nxx referral to another site appears, do the same with it. GET requests only — do not POST anything. Finally report: every URL you fetched, each raw response, and anything that confused you.
L’agent reçoit une réponse en texte brut comme celle-ci — offres, disponibilité et actions suivantes en un seul GET, environ 80 % de jetons en moins que l’exploration JSON équivalente :
ax1 ok op=o n=3 cov=1 cb=2 nx="a.quote i=<sku>; a.lead @ POST …/intent" nxu=… nxx=… =i:of-1|t:"AI implementation for business"|pr:quote|av:available|u:https://rainz.ai/ …
Il décode ensuite chaque champ correctement — parce que le protocole enseigne sa propre syntaxe : une requête mal formée renvoie un exemple corrigé, l’en-tête de réponse indique cov= (quelle part de votre requête a été comprise), et chaque réponse porte l’étape suivante sous forme d’URL littérale.
Certains agents hébergés (dont le navigateur de ChatGPT) refusent d’ouvrir toute URL découverte à l’intérieur d’une page récupérée — une règle de sécurité sur la provenance, indépendamment de l’URL elle-même. Le protocole se dégrade gracieusement : l’agent vous montre l’URL de l’étape suivante, vous la lui recollez, la chaîne continue. Les agents disposant d’un véritable accès HTTP (Claude, agents par API, robots d’exploration, clients MCP) parcourent toute la chaîne sans aide.
https://rainz.ai/wp-json/rainz-axs/v1/mcpcurl "https://rainz.ai/wp-json/ax/v1/x?s=ax1+q.svc.pr+n%3D3"Votre agent a-t-il réussi ? Dites-le-nous — envoyez un lead par le protocole lui-même : c’est l’action a.lead que votre agent vient d’apprendre.
Le défi zero-shot n’est pas un test de l’agent. C’est un test du protocole et du site qui l’implémente. Un agent qui n’a jamais rencontré AX reçoit une tâche et rien d’autre : soit la spécification est suffisamment auto-descriptive pour qu’il réussisse, soit elle ne l’est pas. Ce cadrage compte, car il signifie qu’un échec est une information sur la conception plutôt qu’un verdict sur le modèle.
Trois choses sont sous observation. L’agent peut-il trouver le point d’entrée sans qu’on lui dise où il se trouve ? Une fois le manifeste en main, peut-il en déduire la structure sans documentation externe ? Et peut-il mener la tâche de bout en bout sans qu’un humain clarifie quoi que ce soit en cours de route ? Un protocole qui exige un tutoriel pour être utilisable a échoué précisément là où il devait réussir.
Les normes sont généralement évaluées en se demandant si un ingénieur compétent peut les implémenter à partir du document. Ce test est bien trop indulgent pour un protocole dont les consommateurs sont des agents. Un agent qui arrive sur votre site n’a pas lu la spécification, ne connaît pas vos conventions et ne vous posera aucune question de clarification. Il n’a qu’un seul passage sur la matière, et si celle-ci est ambiguë, il devinera.
La performance zero-shot est donc l’approximation la plus proche des conditions réelles. Elle a aussi un effet secondaire utile : parce que l’exigence est élevée, elle expose exactement le type de savoir implicite sur lequel les auteurs de spécifications s’appuient sans s’en rendre compte. Chaque endroit où un agent trébuche est un endroit où le document a supposé quelque chose qu’il n’a jamais énoncé.
Vous pouvez reproduire cela sur votre propre site en quelques minutes. Ouvrez une conversation neuve avec n’importe quel modèle capable, ne lui donnez que votre domaine et une tâche qu’un vrai client pourrait avoir, et regardez où il va. N’aidez pas. Ne corrigez pas. Toute la valeur réside dans l’observation du premier point où il se trompe.
Utilisez une nouvelle conversation à chaque fois, car un modèle déjà corrigé une fois ne fonctionne plus en zero-shot. Et variez la tâche : un agent à qui l’on demande de résumer votre activité sollicitera des parties de votre site complètement différentes de celui à qui l’on demande vos tarifs ou si vous desservez tel marché.
L’erreur courante consiste à traiter le score comme une note. Le chiffre importe bien moins que la question de savoir où exactement l’agent s’est arrêté. Un agent qui découvre le manifeste mais interprète mal la structure des services vous dit quelque chose de tout à fait différent de celui qui n’a jamais trouvé le point d’entrée. Le premier est un problème de formulation, le second un problème de découverte, et les correctifs n’ont rien en commun.
Gardez aussi à l’esprit que le résultat dépend du modèle qui exécute le test. Les modèles arrivent avec des connaissances préalables différentes, et un agent qui rencontre le protocole pour la première fois se comporte autrement qu’un agent ayant déjà vu des structures similaires. La comparaison pertinente n’est donc pas entre votre site et celui d’un autre, mais entre votre site aujourd’hui et votre site le mois dernier, sur le même modèle et la même invite.
L’exercice ne justifie le temps investi que s’il produit une liste d’actions. Notez le point précis où l’agent s’est trompé, changez une seule chose, puis recommencez. Changer plusieurs choses à la fois peut améliorer le score mais ne vous dira pas ce qui a produit l’amélioration. Trois ou quatre itérations suffisent généralement pour passer d’un site où les agents se perdent à un site où ils accomplissent la tâche du premier coup — ce qui est, au bout du compte, le seul résultat qui compte commercialement.
Une exécution qui se termine par un échec est plus utile qu’une réussite, à condition de noter où elle s’est arrêtée. Les échecs se regroupent en quatre familles. Les échecs de découverte signifient que l’agent n’a jamais trouvé de point d’entrée — le manifeste est absent, mal placé ou bloqué. Les échecs de compréhension signifient qu’il a trouvé le manifeste mais n’a pas su déterminer le sens des champs, ce qui relève du nommage plutôt que de la structure. Les échecs de navigation signifient qu’il a compris la structure mais n’a pas pu atteindre le contenu, généralement parce qu’une page liée redirige ou exige l’exécution de scripts. Les échecs d’achèvement signifient qu’il a tout obtenu et a quand même produit la mauvaise réponse, ce qui est presque toujours un problème de contenu plutôt que de protocole.
Classez l’échec avant de changer quoi que ce soit. L’instinct de corriger la dernière chose que vous avez vue mal tourner est fort et généralement mal orienté : un agent qui donne une mauvaise réponse à l’étape quatre l’a souvent fait à cause d’une ambiguïté introduite à l’étape un.