AI Ready : notre plugin de données structurées sait maintenant parler directement aux agents IA

1. Un nom qui ne racontait plus toute l'histoire

Depuis plusieurs années, nous faisons tourner un plugin WordPress interne sur pratiquement tous les sites hôteliers et de restauration que nous construisons et gérons. Il s'appelait Mixit7 Structured Data, et son rôle était simple à décrire : piloté par des champs ACF, il génère le schema markup JSON-LD de l'établissement — type Hotel, type Restaurant, avis et notes agrégées via AggregateRating, informations d'entreprise via LocalBusiness, plus des types de schema personnalisés quand un établissement a besoin de décrire quelque chose que les types standards ne couvrent pas bien. Le tout avec un support multilingue complet via WPML, parce qu'un schema qui n'existe qu'en français sur un site bilingue est un schema à moitié fait.

Ce nom décrivait fidèlement ce que le plugin faisait en 2024. Il ne décrit plus tout à fait ce qu'il fait aujourd'hui. Nous l'avons renommé Mixit7 AI Ready, avec une nouvelle description dans son en-tête : « Schema markup, Agent Readiness and AI discoverability for hotel and restaurant websites. » Ce n'est pas un ravalement marketing pour suivre une mode. Le plugin a gagné une capacité nouvelle, et le nom devait suivre la réalité plutôt que l'inverse.

2. Ce qu'il faisait déjà, et qui reste le socle

Le renommage n'a rien enlevé. Tout ce que Mixit7 Structured Data faisait, Mixit7 AI Ready continue de le faire, et c'est toujours l'essentiel de son travail au quotidien. Le schema Hotel complet — adresse, coordonnées GPS, classification étoiles, équipements, horaires d'arrivée et de départ. Le schema Restaurant — type de cuisine, horaires d'ouverture, fourchette de prix. Les avis et notes agrégées, correctement structurés en AggregateRating plutôt qu'affichés seulement en texte sur la page. Les informations d'entreprise en LocalBusiness pour les établissements qui en ont besoin en complément. Et pour les cas qui ne rentrent dans aucune de ces cases, la possibilité de définir des types de schema personnalisés directement depuis l'administration WordPress, sans toucher au code.

Ce socle reste, à notre avis, la fondation correcte. Le schema JSON-LD est un sidecar : un bloc de données à côté de la page, qui dit à un moteur de recherche ou à un système d'IA des faits vérifiables sur l'établissement, sans que la machine ait à deviner ces faits en lisant le rendu visuel de la page. Nous avons écrit ailleurs sur ce blog à quel point cette couche est déterminante pour la visibilité IA. Rien de ce qui suit ne la remplace. Ce qui suit s'ajoute par-dessus.

3. La vraie bascule : la négociation de contenu

Voici ce qui a changé, concrètement. Quand une page de l'un de nos sites hôteliers est demandée, le plugin regarde maintenant qui la demande. Si l'en-tête HTTP Accept de la requête indique qu'un agent IA ou un crawler préfère une représentation textuelle légère plutôt qu'une page HTML complète, le plugin peut répondre avec du Markdown propre à la place du HTML habituel. Nous avons aussi ajouté un paramètre d'URL, ?_m7md=1, qui force cette réponse Markdown quel que soit l'en-tête envoyé — utile pour vérifier nous-mêmes, à tout moment, exactement ce qu'un agent recevrait s'il demandait la page maintenant.

C'est ce qu'on appelle de la négociation de contenu : la même URL, la même page, mais deux représentations possibles selon qui la demande et comment. Un navigateur humain reçoit toujours la page HTML complète, avec sa mise en page, ses images, son JavaScript, son expérience de réservation. Un agent qui envoie le bon signal reçoit une version épurée du même contenu, sans la charpente visuelle qui ne lui sert à rien et qu'il devrait de toute façon ignorer ou mal interpréter.

En tête de chaque réponse Markdown, un bloc de front matter au format YAML porte les métadonnées structurées de la page — le type de contenu, l'identifiant de l'établissement, et selon le cas d'autres champs pertinents pour ce que la page représente. Un exemple simplifié, pour une page de type chambre :

---
type: room
hotel: "Hôtel Le Grand Palais"
room_type: "Suite Deluxe Vue Jardin"
capacity: 2
price_from: "290 EUR"
lang: fr
---

# Suite Deluxe Vue Jardin

45 m², lit king-size, vue sur les jardins...

Le schema JSON-LD dit à une IA : voici les faits sur cette page, dans un vocabulaire standard qu'elle connaît déjà. Le Markdown à la demande va plus loin : il donne à l'agent le contenu lui-même, dans la forme la plus propre possible, avec moins de gaspillage de tokens et beaucoup moins de risque qu'il interprète mal du HTML habillé de CSS et de JavaScript qui n'a jamais été pensé pour être lu par une machine.

4. Du Markdown qui comprend ce qu'il décrit

La tentation la plus simple, en construisant une fonctionnalité comme celle-ci, aurait été d'écrire un convertisseur générique : prendre le HTML rendu, retirer les balises, aplatir le résultat en texte, et l'appeler Markdown. Nous avons délibérément évité cette approche, parce qu'elle produit un texte techniquement propre mais sémantiquement pauvre — un agent qui lit ce résultat sait qu'il y a du texte, mais pas ce que ce texte représente.

À la place, le plugin a des gestionnaires d'entités dédiés, chacun sachant représenter correctement un type de contenu spécifique plutôt que de le traiter comme du texte générique. Une page de chambre passe par le gestionnaire chambres, qui sait extraire et présenter la surface, la capacité, le prix de départ, les équipements de la chambre — pas juste les paragraphes descriptifs, mais la structure sous-jacente que ces paragraphes racontent en langage humain. Une page de restaurant passe par le gestionnaire dédié à ce type de contenu, qui sait présenter les horaires, le type de cuisine, le lien de réservation, distinctement du contenu générique de la page. Le contenu FAQ passe par un gestionnaire qui préserve la structure question/réponse plutôt que de la diluer en un bloc de texte continu. Les informations d'entreprise et de contact — adresse, téléphone, horaires — passent par leur propre gestionnaire, qui sait ce que chacun de ces champs signifie plutôt que de les traiter comme des lignes de texte parmi d'autres.

Cette distinction compte. Un agent qui doit répondre à la question « est-ce que cet hôtel a une chambre pour deux avec vue sur jardin sous 300 euros la nuit » se débrouille beaucoup mieux avec un Markdown qui a préservé la structure prix / capacité / caractéristiques qu'avec un paragraphe de prose touristique convertie mécaniquement. Le support WPML s'applique ici aussi : la version Markdown respecte la langue de la page demandée, exactement comme le fait déjà le schema JSON-LD.

5. Les détails qui font la différence

Plusieurs nettoyages pratiques ont accompagné cette bascule, chacun modeste isolément mais réel dans son effet cumulé.

• Nettoyage des liens de réservation dans la sortie Markdown, pour qu'un agent reçoive une URL de réservation propre et fonctionnelle plutôt qu'un lien chargé de paramètres de tracking qui n'ont aucun sens hors du contexte d'une session de navigateur.
• Formatage des numéros de téléphone au format international E.164 (+33...), pour qu'un agent — ou un futur système capable de composer un numéro — n'ait pas à deviner l'indicatif pays à partir d'un numéro écrit à la française.
• Support des codes de distribution GDS, pour les établissements qui veulent exposer leurs identifiants Sabre, Amadeus ou équivalents aux systèmes qui en ont l'usage.
• Une nouvelle page d'administration, « Agent Readiness », qui montre concrètement ce qui est exposé aux agents IA pour chaque page — pas une estimation abstraite, mais un aperçu réel de la sortie Markdown et du front matter tels qu'un agent les recevrait aujourd'hui.

Cette dernière page d'administration compte plus qu'elle n'en a l'air. La couche invisible d'un site n'est utile que si quelqu'un peut vérifier son état sans deviner. Avant, la seule façon de savoir ce qu'un agent IA pourrait extraire d'une page était de lire le HTML rendu et d'imaginer comment une machine l'interpréterait. Maintenant, on peut simplement regarder la sortie réelle.

6. Pourquoi cette couche compte

Nous voyons cette fonctionnalité comme un exemple concret et déjà fonctionnel de ce que certains appellent le web agentique — un web où les machines, de plus en plus, ne se contentent plus d'indexer des pages pensées pour des humains, mais demandent et reçoivent une représentation légère et conçue pour elles. Ce n'est pas une prédiction abstraite. C'est un comportement qu'on peut observer aujourd'hui, en tête de requête, dans l'en-tête Accept.

Cette couche s'ajoute à ce que nous défendons depuis toujours sur ce blog, elle ne le remplace pas. Le robots.txt détermine si un agent peut accéder au site. Le schema JSON-LD lui dit des faits structurés sur ce qu'il trouve. Le llms.txt lui indique comment travailler avec le contenu du site dans son ensemble. Le Markdown à la demande va plus loin encore : il donne à l'agent le contenu lui-même, débarrassé de tout ce qui n'était destiné qu'à des yeux humains et à un navigateur. Chacune de ces couches répond à une question différente. Aucune ne dispense des autres.

C'est ce que nous avons construit pour les sites que nous gérons, et c'est ce qui tourne aujourd'hui, silencieusement, chaque fois qu'un agent IA bien identifié demande une page sur l'un d'entre eux.