Ce dont un site web a besoin pour les agents IA : notes de la création de dardo.studio

La réponse courte

Un site prêt pour les agents IA fait trois choses. Les agents IA peuvent y accéder. Ils peuvent le lire sans se perdre dans les menus, les bannières et les scripts. Et, quand c'est pertinent, ils peuvent appeler quelques outils déclarés au lieu de deviner sur quel bouton cliquer.

Nous avons intégré ces trois éléments à dardo.studio début octobre 2026. Voici ce que nous avons mis en ligne et dans quelle mesure les grandes plateformes d'IA documentent leur utilisation, d'après une vérification faite sur le site en ligne le 8 octobre 2026.

Le bilan est moins spectaculaire que la plupart des checklists « prêt pour l'IA ». Les couches les plus anciennes pèsent le plus : l'accès des robots d'exploration et un HTML propre et sémantique. Les copies en markdown et le fichier llms.txt sont des commodités peu coûteuses. MCP, A2A et WebMCP sont de vrais protocoles avec des clients fonctionnels, mais aucune des documentations de crawlers que nous citons, celles d'OpenAI, d'Anthropic, de Perplexity ou de Google, ne décrit des assistants qui découvrent seuls les outils d'un site.

Commencer par l'accès : robots.txt et le edge

Notre robots.txt répète un même groupe de règles pour l'agent par défaut (*) et pour chaque robot de recherche IA et chaque agent de récupération utilisateur que nous nommons :

User-agent: OAI-SearchBot
Allow: /
Disallow: /api/
Content-Signal: search=yes, ai-input=yes

Les mêmes règles s'appliquent à ChatGPT-User, PerplexityBot, Perplexity-User, Claude-SearchBot, Claude-User et Bingbot. Seul /api/ est fermé.

Les robots de recherche et ceux d'entraînement sont distincts

Les grandes entreprises documentent désormais des jetons distincts pour la recherche et pour l'entraînement :

• OpenAI. OAI-SearchBot fait apparaître les sites dans la recherche ChatGPT. Les sites qui le bloquent sont exclus des réponses de recherche de ChatGPT, mais peuvent tout de même figurer sous forme de simples liens de navigation. GPTBot collecte des données d'entraînement. (robots d'OpenAI)
• Anthropic. Claude-SearchBot indexe pour la recherche, ClaudeBot collecte des données d'entraînement, et Claude-User récupère des pages lorsqu'une personne pose une question à Claude. (robots d'Anthropic)
• Perplexity. PerplexityBot fait apparaître les sites et les cite avec des liens dans les résultats de Perplexity, et n'est pas utilisé pour entraîner des modèles de fondation. (robots de Perplexity)
• Google. Google-Extended est un jeton de contrôle pour l'entraînement de Gemini et l'ancrage (grounding) dans d'autres produits Google. Il n'a aucune incidence sur l'inclusion ni sur le classement dans Google Search. (robots d'exploration courants de Google)

Les agents de récupération déclenchés par l'utilisateur sont différents. OpenAI indique que robots.txt peut ne pas s'appliquer à ChatGPT-User, car ces requêtes sont lancées par une personne. Perplexity-User et les agents de récupération déclenchés par l'utilisateur de Google l'ignorent généralement. Ces agents agissent pour une seule personne en temps réel ; quand un blocage fonctionne, il empêche surtout l'assistant de cette personne de lire votre page.

Notre fichier ne nomme pas les robots d'entraînement : ils relèvent donc de * et sont autorisés. C'est une décision d'entreprise, et les éditeurs la documentent comme un contrôle à part : bloquer GPTBot ou ClaudeBot n'est pas la même chose que quitter leurs index de recherche.

Content Signals : une ligne, aucun engagement

La ligne Content-Signal vient de la Content Signals Policy de Cloudflare, qui distingue trois usages : search, ai-input (fournir du contenu à un modèle au moment de la réponse) et ai-train. Nous omettons ai-train, ce qui, selon la politique, n'accorde ni ne restreint cet usage. Cloudflare précise que les signaux expriment des préférences, ne bloquent rien et peuvent être ignorés. Aucune des pages de robots citées ici n'en parle. Cela coûte une ligne ; n'en attendez rien pour l'instant.

Vérifier le edge, pas seulement le fichier

robots.txt énonce une politique ; c'est votre CDN qui décide de ce qui se passe. Lors de nos tests du 2 octobre, la Browser Integrity Check de Cloudflare répondait par un 403 au client HTTP par défaut de Python (Python-urllib) et à libwww-perl, alors que robots.txt autorisait tout. Les scripts écrits par des agents de code utilisent souvent la bibliothèque standard de Python telle quelle.

Nous avons ajouté une règle de configuration Cloudflare qui exempte les requêtes GET et HEAD sur le contenu public ; /api/ répond toujours 403. Le même examen a révélé que nos fichiers .txt n'avaient pas de charset, de sorte que certains clients lisaient « Bogotá » comme « Bogotá ». La correction tenait en un en-tête : charset=utf-8.

Testez avec de vraies requêtes sous chaque user agent. Cela montre que rien ne bloque le nom ; cela ne prouve pas que le vrai robot est passé.

Un HTML simple et sémantique : la couche dont dépendent tous les agents

Le guide d'optimisation pour l'IA de Google décrit des agents de navigation qui analysent des captures d'écran, inspectent le DOM et interprètent l'arbre d'accessibilité. Il renvoie les propriétaires de sites aux conseils sur les sites adaptés aux agents de web.dev, qui relèvent surtout du travail d'accessibilité : utiliser <button> et <a> plutôt que des <div> stylisés, relier chaque label à son champ, et éviter que la mise en page ne bouge pendant une capture d'écran.

Sur dardo.studio, chaque page contient un seul <main> et des repères <nav> étiquetés. Les boutons de menu et de thème sont de vrais boutons qui signalent leur état avec aria-expanded et aria-pressed, et les menus fermés sont inert. Chaque champ du formulaire de contact se trouve dans son <label>, ce qui lui donne un nom accessible. web.dev suggère l'attribut for ; envelopper le champ remplit le même rôle.

Cela aide dès aujourd'hui les utilisateurs de lecteurs d'écran, ce qui suffit déjà.

Une copie markdown propre de chaque page

Les agents paient chaque token qu'ils lisent, et une page rendue contient navigation, bannière de cookies, scripts et graphismes décoratifs. Avant ce travail, demander nos pages avec Accept: text/markdown renvoyait tout cela en HTML.

Désormais, une étape de build écrit un fichier index.md à côté de chaque page indexable. Il commence par un front matter (titre, description, URL canonique, langue, version dans l'autre langue et date de mise à jour), puis reprend le contenu de <main> de la page, sans scripts, boutons, images décoratives ni sommaire interne. Les réponses de la FAQ sont conservées. Les formulaires deviennent une liste de leurs champs et de leurs choix, pour qu'un agent puisse indiquer à une personne ce que demande notre formulaire de contact sans y toucher.

Il y a trois façons d'obtenir cette copie :

• Envoyez Accept: text/markdown à l'URL habituelle. Ces réponses contiennent Vary: Accept, afin que les caches séparent bien les versions.
• Demandez le fichier : /en/services/seo/index.md.
• Ajoutez .md au chemin de la page (/en/services/seo.md). Pour les URL qui se terminent par une barre oblique, la proposition llms.txt utilise index.md, la forme présentée plus haut.

Chaque page HTML renvoie aussi vers sa copie grâce à <link rel="alternate" type="text/markdown">.

Renvoyer les moteurs de recherche vers le HTML

Le guide de Google indique qu'il peut explorer et indexer de nombreux types de fichiers en plus du HTML, sans les traiter de façon particulière. Une copie markdown pourrait concurrencer sa propre page : chaque réponse markdown désigne donc la page HTML comme canonique :

$ curl -sI https://dardo.studio/en/services/seo/index.md
content-type: text/markdown; charset=utf-8
link: <https://dardo.studio/en/services/seo/>; rel="canonical", ...

Qui lit ces copies ? Cloudflare a créé Markdown for Agents pour convertir le HTML en périphérie quand une requête préfère le markdown, ce qui laisse penser que des agents en demandent. Cloudflare ne précise pas quels clients envoient l'en-tête, et nous n'avons pas non plus de liste vérifiée. Si vous utilisez la fonctionnalité de Cloudflare, elle ajoute Content-Signal: ai-train=yes, search=yes, ai-input=yes sauf si votre serveur d'origine définit le sien. Nous générons nos copies au moment du build pour qu'elles correspondent exactement à la page.

llms.txt : un index utile, sans effet sur le référencement

llms.txt est une proposition de Jeremy Howard, publiée pour la première fois en septembre 2024 et toujours ouverte aux contributions de la communauté : un fichier markdown placé à /llms.txt, avec le nom du site, un court résumé et des listes de liens qu'un agent peut souhaiter consulter.

Le nôtre, à /llms.txt et /es/llms.txt, est généré à partir des mêmes données que les pages, il ne peut donc pas diverger. Il présente les faits sur le studio (Bogotá, fondé en 2026, une équipe de trois personnes, la façon dont les projets sont tarifés, les moyens de contact), liste les services et les réalisations, et explique comment récupérer les copies markdown. llms-full.txt contient le texte intégral des pages studio, services, réalisations et contact.

Une ligne mentionne des entreprises au nom similaire qui ne sont pas nous. Quand nous avons vérifié le 2 octobre, elles dominaient les résultats de recherche pour « dardo studio ». Cette ligne est peut-être la plus utile du fichier.

Où en est-on, en toute simplicité :

• Google affirme qu'il n'est pas nécessaire d'avoir un llms.txt pour apparaître dans la Recherche ou dans ses fonctionnalités d'IA, que la Recherche l'ignore et que le conserver n'aide ni ne nuit.
• OpenAI, Anthropic et Perplexity n'indiquent pas dans la documentation de leurs robots que ceux-ci lisent les llms.txt d'autres sites. Les sites de documentation d'OpenAI, d'Anthropic et de Perplexity en publient bien un, pour les agents qui lisent leur documentation.

Gardez-en un s'il est généré et exact. Il aide les agents de code et les outils qui le recherchent. Ce n'est pas un levier de visibilité.

Des outils que les agents peuvent appeler : MCP, A2A et le catalogue d'API

Nous avons publié deux outils en lecture seule :

• list_services renvoie nos services publiés, leur périmètre, leurs livrables et leurs URL sources, en anglais ou en espagnol, filtrés par un mot-clé facultatif.
• get_project_brief renvoie les questions auxquelles répondre avant de nous contacter et le lien de contact localisé pour ce service.

Une seule implémentation se cache derrière plusieurs points d'entrée :

Chaque réponse HTML et markdown envoie un en-tête Link pointant vers le catalogue, l'index des compétences d'agent et les deux fiches, de sorte que n'importe quelle page mène au reste.

Les règles de conception que nous appliquerions de nouveau

• Lecture seule et public. Les outils MCP déclarent readOnlyHint: true et lisent le même catalogue publié que le HTML, sans base de données derrière. get_project_brief n'envoie rien, ne réserve rien et ne chiffre rien ; c'est une personne qui relit et envoie.
• Entrées limitées. Le corps des requêtes est plafonné à 8 KiB, les en-têtes Origin des navigateurs sont vérifiés (la spécification MCP l'exige) et les appels ont leur propre limite de débit.
• Sans état. L'agent A2A répond immédiatement, ne conserve aucune tâche, a le streaming désactivé et ne récupère ni les fichiers ni les URL qu'on lui envoie.
• Des conditions claires. /auth.md indique qu'aucun identifiant n'est nécessaire et que lire des données publiques n'autorise ni l'envoi d'un message ni un paiement.

Nous avons aussi laissé des choses de côté. Les outils d'évaluation de la préparation vérifient la présence de protocoles de commerce et de la découverte OAuth. Nous ne vendons rien via un tunnel de paiement et ne protégeons aucune ressource ; les publier décrirait donc des fonctionnalités qui n'existent pas.

Qui utilise ces outils aujourd'hui : des clients MCP que quelqu'un a connectés à /mcp, et des clients A2A à qui l'on a donné notre fiche. Pour un studio, l'intérêt est modeste : une réponse précise à « que fait Dardo, et que faut-il leur envoyer ? » Le cas est plus solide pour un site avec des données en direct sur lesquelles on pose des questions, comme le stock, la disponibilité ou la documentation produit. Les agents qui écrivent des données nécessitent une authentification et des étapes de validation ; cela relève de l'automatisation par l'IA.

WebMCP : les mêmes outils dans le navigateur

WebMCP permet à une page d'enregistrer des outils qu'un agent IA dans le navigateur peut appeler. C'est un Draft Community Group Report du W3C Web Machine Learning Community Group, qui précise qu'il ne s'agit pas d'un standard W3C. web.dev indique qu'il est en développement actif, qu'il peut changer et qu'on peut l'essayer dans Chrome via un origin trial.

Nos pages enregistrent les deux mêmes outils via document.modelContext (ou navigator.modelContext dans les anciennes préversions). Sans l'API, le navigateur n'exécute rien de plus. Comme les outils existaient déjà, cela a pris environ 40 lignes. À considérer comme une expérience.

Chaque couche, et si elle en vaut la peine

Ce que nous referions

Dans l'ordre : HTML sémantique, accès des robots testé, copies markdown avec en-têtes canoniques, un llms.txt généré, et des outils seulement quand il y a quelque chose qui mérite d'être appelé. Ensuite, mesurez. Les journaux du serveur montrent quels agents récupèrent les copies markdown ou appellent /mcp. Une récupération n'est pas une citation, et rien de tout cela ne garantit qu'un système d'IA parlera de vous.

La préparation aux agents fait partie de notre travail d'optimisation pour la recherche IA, avec le contenu et la mesure qui déterminent si les réponses de l'IA vous citent. Pour l'intégrer à votre site, parlez-nous de votre projet.