Publier, votre marque lisible par les assistants

Diffuser, c'est vous qui ouvrez la conversation. Publier, c'est l'inverse : un assistant déjà ouvert vient chercher votre version, parce qu'on lui a demandé quelque chose qui vous concerne.

Les deux referment la même boucle, par les deux bouts.

Le contexte public

Tout part du même endroit : un contexte que vous écrivez, et qui décrit des faits. Il est servi à une adresse publique, dans trois formes qui viennent de la même source et ne peuvent donc pas se contredire.

Cette dernière adresse est celle qu'on oublie toujours. Sans elle, un agent qui arrive sur votre marque doit deviner les adresses de vos sujets. Avec elle, il sait en une requête ce que vous publiez, et depuis quand.

Le fichier robots.txt d'Oyya ouvre nommément ces pages aux agents des principaux éditeurs. Ce sont des pages écrites pour être lues par des machines : il n'y a ni challenge, ni limitation de débit, ni piège.

Le serveur MCP de votre marque

Le Model Context Protocol est la façon dont un assistant se branche à une source extérieure. Oyya expose un serveur par marque, à une adresse unique :

https://oyya.fr/mcp/votre-marque

Il n'y a aucune authentification, et c'est un choix plutôt qu'un oubli : ce serveur ne sert que du contenu déjà public sous /c/. C'est ce qui permet de le brancher en collant une adresse, sans compte, sans clé et sans discussion avec une équipe technique.

Le jour où un outil touchera à autre chose que du contenu publié, un jeton deviendra nécessaire, et ce sera un autre produit. Nous préférons le dire maintenant.

Les quatre outils

• lister_contextes rend les sujets que vous publiez, avec leur date de mise à jour. C'est le premier appel d'un assistant qui ne connaît pas encore votre marque.
• lire_contexte rend un sujet complet : identité, objet, faits, questions fréquentes, conditions, liens.
• chercher cherche dans tout ce que vous avez publié. La méthode est une correspondance sur les radicaux des mots, et le serveur le dit à l'assistant dans sa réponse : un outil qui laisserait croire à une recherche sémantique ferait conclure à tort que l'information n'existe pas.
• liens_utiles rend les adresses vers lesquelles vous souhaitez orienter, à proposer après la réponse et jamais à sa place.

Tous sont en lecture. Aucun n'écrit quoi que ce soit, nulle part.

Ce que le serveur dit de lui-même

Un serveur MCP peut envoyer des instructions à l'assistant qui s'y branche. C'est un pouvoir considérable, et c'est exactement là que se logent les abus.

Le nôtre décrit ce qu'il contient et sa limite. Il ne demande jamais à l'assistant de privilégier votre marque, de la citer comme source de référence, ni de retenir quoi que ce soit pour plus tard. Il précise même que les informations qu'il rend engagent la marque et ne sont pas vérifiées par un tiers, et qu'elles doivent être présentées comme votre position, en vous citant.

C'est la même règle que pour le lien : une consigne cachée se retourne toujours contre celui qui l'a posée.

Ce qui est mesuré

Chaque appel d'outil est enregistré comme un moment de la boucle, au même titre qu'un clic ou qu'une lecture de contexte. Sans cela, le MCP serait le seul canal invisible de votre tableau de bord, et vous ne sauriez jamais s'il sert.

Où en est ce chantier, exactement

Le serveur est en ligne et il répond. Vous pouvez le vérifier tout de suite sur le nôtre : oyya.fr/mcp/oyya.

Ce qui n'est pas prouvé, et qu'il faut savoir : aucun assistant grand public n'a encore été branché dessus de bout en bout par nos soins. Le protocole est respecté, la négociation de version fonctionne, les outils répondent. La chaîne complète, depuis un assistant réel jusqu'à une réponse citant votre marque, reste à démontrer.

C'est pour cette raison que ce pilier porte la mention « en construction » sur la page d'accueil, et non « disponible ».