popnetmedia/ai-search-readiness

---

name: ai-search-readiness description: Ce qu'un site commercial doit publier pour être utilisable par la recherche IA et les agents de réservation. À utiliser sur tout site client vendant un service avec prix ou prenant des réservations, en complément de contenu non-commodity. Couvre les trois gestes : publier la fourchette de prix, rendre la planification prête pour les agents avec un vrai schéma, et exploiter les vraies questions des clients pour le contenu. Se déclenche sur les pages de prix, de réservation, de services, le travail sur les schémas, et toute question relative à la capacité de l'IA à trouver ou à interagir avec le site.

Préparation à la recherche IA

Trois gestes. Ils ne concernent pas la qualité du contenu, régie par non-commodity-content. Ils déterminent si le site peut être trouvé, cité et faire l'objet d'une transaction par une machine agissant pour un client.

Un site peut respecter toutes les règles de contenu et rester invisible pour un agent, parce qu'il n'a jamais publié de chiffre ni exposé de point de réservation qu'une machine puisse lire.

---

Gest 1 : publier la fourchette de prix

La règle. Tout site commercial publie ce que coûte son service. Pas un catalogue de prix. Une fourchette avec les deux extrémités et ce qui fait varier le montant entre elles.

Les gens demandent constamment à l'IA combien coûtent les choses. Une IA qui n'a rien à citer les envoie vers un concurrent qui a publié quelque chose. « Appelez pour connaître le prix » est une impasse pour une machine, et de plus en plus pour une personne.

Ce qu'il faut publier, au minimum :

• la limite basse et la limite haute, sous forme de chiffres réels
• ce qui la fait varier : les deux ou trois variables qui déterminent où se situe une prestation dans la fourchette
• la date à laquelle la fourchette a été mesurée, à côté des chiffres
• chaque frais fixe, en intégralité : livraison, installation, caution, nettoyage, minimums, pénalités
• un lien vers la source en direct pour un devis exact

L'objection, et la réponse. Les opérateurs résistent parce que les prix bougent et qu'ils craignent d'être tenus responsables d'un chiffre obsolète. Cette objection concerne un prix fixe unique présenté comme le prix. Ce n'est pas un argument contre une fourchette. Une fourchette datée dont les facteurs de variation sont nommés est plus précise que le silence, et c'est la chose que l'opérateur est le seul à pouvoir indiquer.

La règle qui résout l'objection. Ne publiez jamais un taux nu. Publiez :

Les tarifs nocturnes vont de 106 $ à 175 $ pour l'ensemble de la flotte, mesuré le 18 septembre 2026. Le camping-car et les dates choisis déterminent le prix exact. Vérifiez vos dates pour le tarif précis.

Pas :

Camping-cars à partir de 106 $/nuit.

Ne tapez jamais un prix deux fois. Lisez-le à partir de la source que l'entreprise maintient déjà, au moment de la construction : le flux de la plateforme de réservation, le POS, le tableau des frais publié. Un prix tapé dans une page est un prix qui sera en désaccord avec le paiement dans le mois. Lorsque le nombre est extrait de la propre page de l'opérateur, les deux ne peuvent jamais diverger.

Lorsqu'un tarif ne peut vraiment pas être publié (il est devisé par prestation, ou fixé par un tiers), la page doit quand même au lecteur tout ce qui est adjacent et fixe : le tableau des frais, les minimums, la caution, la pénalité pour modification de réservation. Puis dites clairement que le tarif lui-même est fixé sur devis, et indiquez où l'obtenir. Une page qui dit « nous ne publions pas X, voici pourquoi, voici où l'obtenir, et voici tout ce qui ne bouge pas » bat une page qui ne dit rien.

Liste de vérification pré-publication pour toute page de prix :

• Les deux extrémités de la fourchette sont des chiffres réels, pas « à partir de »
• Les facteurs de variation du prix sont nommés
• La date de mesure se trouve à côté des chiffres
• Chaque frais fixe est publié en intégralité
• Les chiffres sont lus depuis une source au moment de la construction, non tapés
• Les données structurées portent les mêmes nombres que le texte (voir Gest 2)
• Lorsque quelque chose ne peut pas être tarifé, la page le dit et indique le devis

---

Gest 2 : planification prête pour les agents

La règle. Si l'agent d'un client ne voit pas comment effectuer une transaction avec le calendrier, l'entreprise lui est invisible. La réservation agentique est une réalité : un assistant réservera une table, une intervention, une location. Il accède d'abord aux données structurées, puis au DOM.

Trois couches, toutes obligatoires.

1. L'offre, en données structurées. Chaque élément réservable porte une Offer avec un prix réel ou une fourchette priceSpecification, une devise, un état de disponibilité, et un priceValidUntil correspondant à la date de mesure. Un priceRange sur l'entreprise ne suffit pas ; la machine veut l'offre sur l'article qu'on lui demande de réserver.

"offers": {
  "@type": "Offer",
  "priceCurrency": "USD",
  "priceSpecification": {
    "@type": "UnitPriceSpecification",
    "priceCurrency": "USD",
    "minPrice": 106,
    "maxPrice": 175,
    "unitCode": "DAY",
    "referenceQuantity": { "@type": "QuantitativeValue", "value": 1, "unitCode": "DAY" }
  },
  "availability": "https://schema.org/InStock",
  "priceValidUntil": "2026-12-31",
  "url": "https://example.com/book"
}

2. L'action. L'entité porte un potentialAction nommant le point de réservation, la cible HTTP et les entrées requises. C'est la partie que presque personne ne publie et dont un agent a réellement besoin.

"potentialAction": {
  "@type": "ReserveAction",
  "name": "Réserver ce camping-car",
  "target": {
    "@type": "EntryPoint",
    "urlTemplate": "https://example.com/book?rental_id={rental_id}&from={checkin}&to={checkout}",
    "actionPlatform": [
      "https://schema.org/DesktopWebPlatform",
      "https://schema.org/MobileWebPlatform"
    ],
    "httpMethod": "GET"
  },
  "result": { "@type": "Reservation", "name": "Réservation de location de camping-car" },
  "object": { "@type": "Product", "name": "2023 Jayco Jay Flight" }
}

Choisissez le type d'action qui correspond au verbe : ReserveAction pour une réservation ou un rendez-vous, ScheduleAction pour un rendez-vous, OrderAction pour un achat, RsvpAction pour un événement.

3. Les contraintes, exprimées en données, pas en prose. Un agent qui réserve un séjour que l'entreprise ne peut pas honorer fait perdre du temps à tout le monde. Publiez les règles qui feraient échouer une réservation :

• durée minimale et maximale
• délai de préavis et date butoir (availabilityStarts, advanceBookingRequirement)
• éligibilité (âge minimum, permis, caution)
• zone de service (areaServed), et son coût pour chaque partie
• créneaux d'ouverture ou de livraison, lorsque l'heure d'arrivée est contrainte par un tiers

Placez chacun de ces éléments dans le schéma là où une propriété existe, et en phrases claires sur la page là où ce n'est pas le cas. Les deux, toujours : l'agent lit l'un, la personne lit l'autre, et ils doivent concorder.

Rendu lisible par les agents. Contenu critique rendu côté serveur, HTML sémantique, vrais titres, texte alternatif, tableaux sous forme de <table>. Un agent lit le DOM et l'arbre d'accessibilité. Un contenu qui n'apparaît qu'après une récupération côté client est un contenu que l'agent n'a pas vu.

Ne simulez pas de capacité. Ne publiez une ReserveAction que vers un point de réservation qui accepte réellement une réservation. Une action pointant vers un formulaire de contact est un mensonge sur lequel un agent agira, et le client le découvre au pire moment. Lorsque la réservation se fait vraiment par téléphone, publiez le numéro de téléphone dans le schéma et aucune action de réservation.

Les couches de protocole, et laquelle construire

Il existe trois couches. Elles ne sont pas alternatives, elles s'empilent, et l'ordre est important car les couches inférieures sont lues aujourd'hui et les couches supérieures ne le sont généralement pas encore.

Couche 1 : données structurées (construisez ceci en premier, toujours). Offer plus potentialAction, comme ci-dessus. C'est ce que les assistants d'aujourd'hui consomment réellement lorsqu'ils répondent à une question sur une entreprise et lorsqu'ils suivent un lien pour agir. Cela coûte une page de JSON-LD et fonctionne immédiatement.

Couche 2 : un flux lisible par machine. Une URL JSON stable contenant le catalogue : ce qui est à louer ou à vendre, le prix de chacun, les contraintes, l'URL de réservation et la date de mesure. Aucun engagement de protocole, aucun point de réservation à défendre, lisible par tout agent, robot ou site frère. Peu coûteux, et ce qui fait de la couche 3 une tâche d'une matinée plus tard.

Couche 3 : A2A (Agent2Agent). Le protocole ouvert pour la délégation de tâches d'agent à agent : une carte d'agent à une URL bien connue décrivant l'identité, les compétences et l'authentification de l'agent, et un point de réservation parlant JSON-RPC sur HTTPS qui accepte des tâches et renvoie des résultats. C'est la bonne réponse lorsque l'assistant d'un client doit pouvoir poser des questions et obtenir des réponses, plutôt que de lire une page.

Soyez honnête sur sa position actuelle. À fin 2026, il n'existe aucun registre que les assistants grand public explorent systématiquement pour les cartes d'agent, donc en publier une est un pari sur l'arrivée de la découverte, pas une source de réservations pour ce trimestre. Construisez-la lorsque l'entreprise a quelque chose qu'un agent a réellement besoin de demander et qu'un flux statique ne peut pas répondre, généralement la disponibilité en direct.

La règle d'honnêteté s'applique ici le plus strictement. Une carte d'agent déclare des compétences, et un autre agent les appellera. Ne déclarez que ce que le point de réservation fait vraiment. La plupart des petits opérateurs ne peuvent pas du tout effectuer une réservation d'agent à agent, car le paiement, l'assurance et le contrat de location se trouvent au sein d'une plateforme tierce. C'est très bien, et la carte doit le dire :

{
  "name": "Assistant de réservation Exemple Rentals",
  "description": "Répond aux questions de disponibilité et de prix pour une flotte. Ne peut pas prendre de paiement.",
  "skills": [
    { "id": "check-availability", "description": "Quelles unités sont libres entre deux dates" },
    { "id": "quote-stay", "description": "Total pour une unité et des dates, incluant la livraison par ville" }
  ],
  "capabilities": { "streaming": false, "pushNotifications": false }
}

Une carte revendiquant une compétence book-stay qui se termine par une redirection est le même échec qu'une ReserveAction pointant vers un formulaire de contact, avec une machine à l'autre bout au lieu d'une personne.

Paiements. Les rails de paiement agentiques (AP2 en tant qu'extension A2A, et les spécifications concurrentes de commerce agentique) évoluent rapidement et ne sont pas pris en charge par la plupart des plateformes de réservation. Ne concevez pas un processus de paiement autour d'eux. Déléguez au processus de paiement de la plateforme et dites-le dans la carte.

Liste de vérification pré-publication pour toute page réservable :

• Offer avec prix ou fourchette de prix, devise, disponibilité, priceValidUntil
• potentialAction avec un EntryPoint réel qu'un agent peut appeler
• Les paramètres du modèle d'URL de l'action sont ceux que le système de réservation prend réellement
• Les minimums, délais, éligibilité et zone de service publiés comme données et comme prose
• Chaque chiffre dans le schéma correspond au chiffre dans le texte
• La page affiche ses informations de réservation côté serveur
• Aucune action n'est publiée pour une capacité qui n'existe pas

---

Gest 3 : contenu issu de questions réelles

La règle. Les questions que les clients posent réellement sont le contenu. Chaque appel téléphonique, chaque email, chaque question « avant de réserver » est une page ou une section, répondue publiquement, dans les mots du client.

Les propres directives de Google disent que les conseils génériques (« 7 astuces pour l'été ») ne gagnent pas. Ce qui gagne est hyper-spécifique et réel. La question qu'un client a posée ce matin est les deux, par construction, car un concurrent écrivant à partir de sources publiques ne sait pas qu'elle a été posée.

L'habitude opérationnelle :

1. Capturez la question mot pour mot. Les mots du client, pas le jargon du secteur. « Pouvez-vous le déposer chez moi pendant qu'ils réparent le toit » est la requête. « Logistique de placement résidentiel » ne l'est pas. C'est la même règle que d'écrire le nom du chercheur.
2. Répondez-y là où le lecteur la trouve. Sur la page où la question se pose, pas dans un article de blog que personne ne consulte.
3. Répondez avec une source. Une réponse sans source est une opinion ; c'est le frais fixe, la règle publiée, le chiffre mesuré qui la rend digne d'être citée.
4. Dites quand la réponse n'est pas la vôtre à donner. Lorsque la réponse appartient à un tiers, un conseil, un assureur, un parc, dites-le et nommez qui demander. Cette phrase est un atout.
5. Tenez une liste de ce que seul l'opérateur sait. Chaque projet tient un fichier de questions ouvertes. Ces réponses sont le contenu que personne ne peut copier, et le fichier est le programme d'entretien.

Les blocs FAQ sont pour les lecteurs, avec le balisage FAQPage car il indique clairement à quoi la page répond. Ils ne sont pas le levier qui permet d'obtenir des citations. La spécificité de première main l'est.

---

Comment les trois s'articulent

Un lecteur arrive depuis une réponse IA qui a cité la fourchette. La page confirme le chiffre, nomme ce qui le fait varier et répond à la question qu'il avait réellement. Son agent réserve alors, parce que l'offre et l'action ont été publiées comme données.

L'absence d'un seul élément brise la chaîne. Un site avec un excellent contenu et aucun prix publié n'est pas cité. Un site avec un prix et aucune action ne peut faire l'objet d'une transaction. Un site avec les deux et un contenu générique ne vaut pas la peine d'être cité en premier lieu.

Sources

1. Discours liminaire de Danny Sullivan, Google Search Central Live Toronto, avril 2026, sur le contenu non-commodity.
2. Guide d'optimisation IA, Google Search Central, sur la lisibilité par les agents et l'éclatement des requêtes.
3. schema.org Offer, UnitPriceSpecification, ReserveAction, EntryPoint.
4. Protocole A2A (Agent2Agent), Linux Foundation, pour la carte d'agent et l'interface de tâches JSON-RPC.