OKF et ARD : ce que Google a vraiment publié, et ce que ça change pour votre visibilité IA

L'Open Knowledge Format n'est pas un levier de citation IA : rien ne va le chercher sur le web. Le format qui compte pour votre visibilité s'appelle ARD, et il définit cinq mécanismes de découverte. Analyse factuelle, versions et dates à l'appui.

Depuis la publication de l'Open Knowledge Format par Google Cloud en juin 2026, une idée circule : il faudrait publier des fichiers OKF pour être mieux cité par les IA. C'est faux, et la confusion est facile à lever. OKF est un format de connaissance interne qui ne prévoit aucun moyen d'être découvert sur le web. Le format qui concerne réellement votre visibilité s'appelle ARD, il est arrivé quelques semaines plus tard, et presque personne n'en parle.

La réponse courte

Si vous n'avez que trente secondes, voici l'essentiel.

OKF (Open Knowledge Format) sert à décrire ce que votre organisation sait, pour ses propres agents internes. Aucun moteur ne va chercher un bundle OKF sur votre site. Ce n'est pas un levier de citation.
ARD (Agentic Resource Discovery) sert à rendre vos ressources trouvables par des agents extérieurs. Vous publiez un manifeste sur votre domaine, des registres le parcourent et l'indexent. C'est un sujet de visibilité.
Les deux se combinent : une entrée ARD peut pointer vers un bundle OKF. C'est précisément de là que vient la confusion ambiante.
ARD reste au statut de proposition. Il n'y a aucune urgence, mais il y a une raison de comprendre le sujet avant vos concurrents.

Qu'est-ce que l'Open Knowledge Format exactement ?

L'OKF est une spécification ouverte publiée par l'équipe Data Cloud de Google Cloud. La version 0.1 date du 12 juin 2026, la version 0.2 du 25 juillet 2026. Le dépôt de référence est GoogleCloudPlatform/open-knowledge-format ; la copie que l'on trouve dans le dépôt knowledge-catalog est un instantané figé, qui n'est plus maintenu.

Techniquement, c'est d'une simplicité assumée : des fichiers Markdown avec un frontmatter YAML, organisés en dossiers. Le frontmatter porte des champs comme type, title, description, resource, tags, sources, status ou stale_after. Le corps du fichier contient de la prose, des schémas, des exemples de requêtes.

À quoi cela sert-il ? À écrire noir sur blanc ce qu'une organisation sait de ses propres données : ses métriques, ses tables, ses jeux de données, ses API, ses procédures d'exploitation. L'objectif est qu'un agent IA interne puisse lire cette connaissance directement, sans qu'on ait à la reconstruire dans chaque outil. Google décrit un format neutre, non lié à un fournisseur, à un framework ou à un modèle particulier.

C'est une bonne idée, et c'est utile. Mais ce n'est pas du référencement.

Pourquoi OKF n'améliorera pas votre citation par ChatGPT ou Perplexity

La raison tient en une phrase : la spécification ne définit aucun mécanisme de découverte. Il n'y a pas d'URI bien connue, pas de convention de sitemap, pas de balise à poser dans vos pages. Le dépôt officiel décrit des bundles qui circulent en dépôt git, en archive tar, ou montés sur un système de fichiers, et qui sont synchronisés d'un système à l'autre.

Autrement dit, même si vous publiez un bundle OKF parfaitement rédigé à la racine de votre site, aucun crawler n'a de raison d'aller le chercher, parce que rien dans la spécification ne lui dit qu'il existe ni où le trouver. Le contraste avec les fichiers que nous auditons habituellement est net : robots.txt, sitemap.xml et llms.txt sont trouvés parce qu'un chemin conventionnel les rend prévisibles.

Le contexte de publication le confirme. OKF a été annoncé du côté Data Analytics de Google Cloud, pas du côté Search. La cible affichée, ce sont les équipes data et les catalogues d'entreprise du type Dataplex, Unity Catalog ou Collibra. Ce sont des outils internes.

Si un prestataire vous propose aujourd'hui une prestation de mise en conformité OKF présentée comme un gain de visibilité dans les réponses IA, demandez-lui quel moteur va lire ces fichiers. Il n'y a pas de réponse à cette question.

ARD : le format qui, lui, concerne votre visibilité

L'Agentic Resource Discovery répond à la question que l'OKF laisse ouverte : comment un agent découvre-t-il une ressource qu'il ne connaît pas encore ?

La distinction avec les protocoles existants mérite d'être posée. Le Model Context Protocol décrit comment un agent appelle un outil. ARD intervient une étape plus tôt : comment l'agent trouve cet outil, et comment il vérifie à qui il appartient avant de s'y connecter.

Le mécanisme est familier à quiconque a déjà travaillé un fichier robots.txt. Vous publiez sur votre domaine un manifeste lisible par machine qui décrit vos ressources agentiques : serveurs MCP, agents, jeux de données, API. Des registres parcourent ces manifestes et les indexent. Quand un agent formule une demande, le registre lui renvoie les ressources correspondantes accompagnées des métadonnées permettant d'identifier l'éditeur.

Ce sont, littéralement, des moteurs de recherche pour le web des agents.

Qui porte cette spécification

ARD est publiée sous licence Apache 2.0 et s'appuie sur un modèle de données maintenu par un groupe de travail hébergé par la Linux Foundation. Elle est développée par Microsoft en collaboration avec Cisco, Databricks, GitHub, GoDaddy, Google, Hugging Face, Nvidia, Salesforce, ServiceNow et Snowflake.

Cette liste est le fait le plus intéressant du dossier. Une spécification de découverte portée simultanément par Microsoft et Google, avec les principaux hébergeurs de modèles et de code, a une probabilité d'adoption qui n'a rien à voir avec celle d'une initiative isolée.

Où se publie le manifeste

Le chemin canonique est /.well-known/ard.json. La spécification impose au consommateur de le récupérer, et de tenir compte d'un lien portant l'attribut rel="ard".

Attention à un détail qui piège déjà les articles publiés cet été : le fichier s'est d'abord appelé /.well-known/ai-catalog.json. Ce nom antérieur reste toléré, mais il n'est plus qu'optionnel pour les consommateurs. Si vous lisez un guide qui ne mentionne que ai-catalog.json, il a été écrit avant la révision de la spécification et vous enverra au mauvais endroit.

Les cinq mécanismes de découverte

La spécification prévoit cinq façons pour un registre de trouver vos ressources. Quatre sont vérifiables par une simple requête HTTP.

Le manifeste servi sur /.well-known/ard.json
Du balisage JSON-LD directement dans vos pages
Une directive Agentmap dans votre robots.txt
Une balise <link rel="ard"> dans l'en-tête de vos pages
Des enregistrements DNS Service Binding

La ressemblance avec la boite à outils du référencement classique est frappante : un fichier à un chemin conventionnel, une directive dans robots.txt, une balise link, du balisage structuré. Ce sont les mêmes gestes, appliqués à un nouveau type de ressource.

À quoi ressemble une entrée

Le manifeste est un document JSON contenant un tableau entries. Chaque entrée doit porter quatre éléments : un identifier sous forme d'URN au format urn:air suivi de l'éditeur, de l'espace de noms et du nom de la ressource ; un displayName lisible par un humain ; un type exprimé comme media type IANA ; et exactement un champ url ou data, jamais les deux.

La spécification recommande fortement d'ajouter deux à cinq representativeQueries par entrée, c'est-à-dire des exemples de demandes formulées en langage naturel. Ce champ mérite votre attention : c'est lui qui fait le lien entre ce que cherche un agent et ce que vous proposez. Un praticien de l'AEO y reconnaîtra un exercice familier, celui de la requête cible, transposé au monde des agents.

Un bloc trustManifest optionnel permet de rattacher cryptographiquement la ressource à son éditeur. Notez cependant qu'ARD ne définit pas sa propre procédure de signature : elle délègue la vérification au cadre de confiance déclaré.

Faut-il agir maintenant ?

Voici la partie où beaucoup d'articles vous diront de tout arrêter pour publier un manifeste. Ce n'est pas notre avis, et voici pourquoi.

La spécification ARD porte le numéro de version 0.91 et le statut de proposition, dans une révision datée du 26 août 2026. Elle a déjà changé le nom de son fichier principal une fois. L'adoption réelle par les éditeurs n'est pas démontrée : à ce jour, l'immense majorité des sites ne publie aucun manifeste, y compris parmi les grandes marques.

Notre lecture est donc la suivante.

Si vous exposez déjà des API, des agents ou des serveurs MCP, publier un manifeste ARD est un geste peu coûteux, de l'ordre de l'heure de travail, avec un retour possible et une perte nulle. Servez-le aux deux chemins tant que les registres migrent.
Si vous êtes un site de contenu ou une PME sans ressource agentique à exposer, il n'y a rien à faire aujourd'hui. Un manifeste vide ne vous apportera rien, et votre temps est mieux investi dans les fondamentaux qui produisent des citations dès maintenant : données structurées, structure de réponse, autorité.
Dans tous les cas, ne confondez pas les deux formats, et méfiez-vous des offres qui vendent OKF comme un levier de référencement.

Pour savoir ce que votre site expose actuellement, notre audit AEO détecte désormais les quatre mécanismes ARD vérifiables en HTTP et valide le contenu de votre manifeste, entrée par entrée. Le résultat est présenté à titre informatif : il n'entre pas dans votre score, précisément parce que la spécification n'est pas stabilisée. Nous ne pénalisons personne pour un standard qui peut encore bouger.

Ce que ce dossier dit du métier

Il y a une leçon plus large dans cette histoire. Deux spécifications sont publiées à six semaines d'intervalle. La première, portée par un nom connu et facile à raconter, déclenche une vague d'articles qui lui prêtent des effets qu'elle n'a pas. La seconde, qui produit réellement les effets annoncés, passe inaperçue parce que son nom est moins parlant.

La différence entre les deux se vérifie en dix minutes : il suffit d'ouvrir la spécification et de chercher si elle décrit un mécanisme de découverte. C'est le genre de vérification qui distingue un conseil d'une répétition.

Questions fréquentes

OKF remplace-t-il schema.org ?

Non. Schema.org décrit le contenu d'une page pour des moteurs qui la parcourent déjà. OKF décrit la connaissance interne d'une organisation pour ses propres agents, et rien ne le parcourt sur le web. Les deux ne sont pas en concurrence, ils ne s'adressent pas au même public.

Dois-je publier un fichier ai-catalog.json ou ard.json ?

Le chemin canonique est /.well-known/ard.json. Le nom ai-catalog.json est celui de la version antérieure ; il reste toléré, mais un consommateur conforme n'est plus tenu de le lire. Si vous publiez déjà sous l'ancien nom, servez le même document aux deux chemins.

Les IA lisent-elles mon llms.txt et mon manifeste ARD de la même façon ?

Non, et l'amalgame est répandu. Le fichier llms.txt s'adresse à un modèle qui lit votre contenu éditorial. Un manifeste ARD s'adresse à un registre qui indexe des ressources exécutables comme des API ou des agents. Publier l'un ne dispense pas de l'autre, et ils ne produisent pas le même effet.

Combien de temps avant que cela compte vraiment ?

Personne ne peut le dire honnêtement, et il faut se méfier de qui l'affirme. Le signal à surveiller n'est pas le nombre d'annonces, c'est l'apparition de registres réellement interrogés par des agents en production. Tant que ce maillon n'existe pas à l'échelle, publier un manifeste reste un pari raisonnable mais un pari.

Nous suivons ce dossier et mettrons cet article à jour à chaque révision de la spécification.