Page de données produit agentiques

Objectif : fournir à un agent d’achat IA suffisamment d’informations exactes, actuelles et lisibles par machine pour identifier un article, évaluer une offre, calculer s’il peut être livré, expliquer le risque de retour, et transférer ou finaliser une transaction sans avoir à deviner.

Question principale : « Puis-je acheter ce produit exact pour ce client, à ce prix, dans cet endroit, selon ces conditions de livraison et de retour ? »

Une page de données produit agentiques est une représentation publique stable d’un produit ou d’une famille de variantes conçue à la fois pour l’inspection et l’action. Contrairement à une page produit classique, qui peut s’appuyer sur une hiérarchie visuelle et un contexte persuasif, ce type traite l’identité, l’offre, la disponibilité, la livraison et les retours comme des champs explicites avec un périmètre défini. Les deux formats devraient normalement coexister sur une seule URL canonique : les humains obtiennent des explications et des preuves ; les agents reçoivent les mêmes faits dans un texte visible, un balisage structuré et des interfaces commerciales fiables.

Questions auxquelles elle répond

La page doit permettre à un agent d’achat de répondre à toutes les questions suivantes sans avoir à inférer une valeur manquante :

• Quel produit exact et quelle variante ce dossier décrit-il ?
• Quel SKU marchand, identifiant global, marque, modèle, taille, couleur, capacité et état l’identifient ?
• Quel est le prix actuel, la devise, l’unité, le traitement fiscal et la période d’offre valide ?
• La variante sélectionnée est-elle réellement disponible, en backorder, précommandable ou abandonnée ?
• Peut-elle être expédiée vers la destination du client, à quel coût, par quelle méthode et dans quel délai de livraison ?
• Qui vend et exécute la commande, et où la responsabilité est-elle transférée ?
• Quels articles peuvent être retournés, sous combien de jours, par quelle méthode, aux frais de qui et avec quelles exceptions ?
• Quelle action est désormais valide : acheter, réserver, demander un devis, rejoindre une liste d’attente ou choisir une autre offre ?

La page est prête pour un usage agentique uniquement lorsque l’absence est explicite. « Livraison non précisée » est différent de livraison gratuite ; « disponibilité inconnue » est différent de en stock.

Quand utiliser ce type de page

Utilisez-le lorsqu’un produit peut être sélectionné ou faire l’objet d’une transaction et qu’un client automatisé a besoin de plus qu’une description marketing. Il est particulièrement utile lorsque les variantes, vendeurs, destinations ou exceptions de politique rendent la réponse conditionnelle.

Ne créez pas de « version IA » indexable distincte qui répète la page humaine. La duplication crée des canoniques concurrents et deux endroits où des faits volatiles peuvent diverger. Utilisez une représentation séparée uniquement lorsqu’une négociation de contenu, un endpoint documenté ou une réponse de données non indexable répond à un besoin client réel.

Idéal pour ces types d’entreprises

1. E-commerce . La meilleure adéquation car le prix, la variante, l’inventaire, la livraison et les retours existent déjà dans les systèmes opérationnels. La tâche consiste à les exposer avec les mêmes identifiants et le même périmètre qu’utilisés lors du paiement.
2. Places de marché . Essentiel lorsqu’un produit a plusieurs vendeurs ou conditions. L’identité du produit doit rester séparée de l’identité de l’offre afin qu’un agent n’attache pas le prix d’un vendeur aux conditions de livraison ou de retour d’un autre.
3. Fabricants et entreprises industrielles . Utile pour les numéros de modèle, la compatibilité technique, les quantités de conditionnement, les distributeurs régionaux, les délais et la disponibilité basée sur devis. « Contactez-nous » devrait tout de même exposer ce qui peut être soumis à devis et quels faits varient.
4. SaaS . Utile lorsqu’un forfait, un module complémentaire, un lot de sièges ou un package d’utilisation est réellement achetable. Remplacez les champs de livraison physique par le délai d’activation et l’éligibilité régionale ou de compte, tout en gardant explicites la base tarifaire, le renouvellement, l’annulation et l’identité du vendeur.

Intention de recherche

L’intention se situe à la frontière entre décision et transaction. Les requêtes combinent un produit ou modèle connu avec « prix », « en stock », « livraison vers », « retours », une taille ou couleur, ou une instruction d’achat. Une invite IA peut ajouter des contraintes en une seule phrase : « Trouve le modèle noir 256 Go sous 900 €, livré à Bratislava la semaine prochaine, avec au moins une fenêtre de retour de 30 jours. »

La bonne réponse n’est pas une recommandation générale. C’est une offre respectant les contraintes : variante exacte, vendeur exact, total actuel, éligibilité de destination, estimation de livraison, conditions de retour et une action stable. Si une condition ne peut être vérifiée, la réponse doit identifier l’écart au lieu de le réduire silencieusement.

Structure de la page

Les fourchettes de mots maintiennent les explications proportionnées. Le contenu le plus critique est constitué de données de champ, pas de prose, et doit être généré à partir de sources gouvernées plutôt que copié dans un texte éditorial.

Éléments requis

Le positionnement suit la dépendance : une offre ne peut être évaluée tant que l’identité n’est pas stable, et une promesse de livraison ne peut être évaluée tant que l’offre et le périmètre de destination ne sont pas connus.

Frontmatter

Suivez la spécification du frontmatter . Sur cette page de spécification, utilisez entity = "post-type-agentic-product-data" et schemaTypes = [ "Article", "FAQPage" ] car la page explique un type de page plutôt que de vendre l’exemple fictif.

Sur une page commerciale produite, entity doit identifier le produit stable, comme northstar-travel-charger-65w, tandis que le SKU et les identifiants globaux identifient les variantes vendables. Utilisez Product pour le produit et Offer pour l’offre achetable d’un vendeur ; utilisez AggregateOffer uniquement lorsque la page visible résume véritablement plusieurs offres. Ajoutez les propriétés de livraison et de politique de retour marchand applicables. Une page produit contenant du contenu FAQ visible peut également être éligible pour FAQPage, sous réserve des règles actuelles des moteurs de recherche, mais le balisage FAQ ne remplace pas les données Product et Offer.

La source de vérité devrait également régir les flux, API et le paiement. Les champs opérationnels requis incluent la devise, le marché, le vendeur, le responsable de l’exécution, le SKU sélectionné, la validité du prix, l’horodatage de disponibilité, le périmètre de destination de livraison, le périmètre de la politique de retour, l’URL canonique et le responsable des données. L’exhaustivité du schéma signifie que les champs décisionnels requis sont à la fois renseignés et corrects — pas que toutes les propriétés possibles apparaissent.

Exemple complet

Cette page fictive illustre le contrat de transaction minimum. Ses valeurs sont des exemples, pas des affirmations concernant un vrai commerçant.

# Chargeur de voyage Northstar 65 W — UE, noir

Le chargeur de voyage Northstar 65 W, SKU NS-65-EU-BLK et GTIN 09506000134352, est vendu neuf par Northstar Direct pour 49,00 € TVA incluse. Cette variante UE noire est en stock. La livraison standard en Slovaquie coûte 4,90 € et est estimée entre le 1er et le 3 septembre 2026 lorsqu'elle est commandée avant 14h00 CEST le 27 août.

## Identité du produit

| Champ | Valeur |
|---|---|
| Marque | Northstar |
| Modèle | Chargeur de voyage 65 W |
| SKU marchand | NS-65-EU-BLK |
| GTIN-14 | 09506000134352 |
| Variante | Prise UE, noir |
| État | Neuf |
| Inclus | Chargeur et câble USB-C de 1 m |

## Offre

| Vendeur | Prix | Devise | Taxe | Disponibilité | Valable jusqu'au |
|---|---:|---|---|---|---|
| Northstar Direct | 49,00 | EUR | TVA incluse | En stock | 31 août 2026, 23h59 CEST |

Le prix s'applique à une unité NS-65-EU-BLK. La quantité maximale en ligne est de quatre par commande. Le vendeur et le prestataire d'exécution sont Northstar Direct.

## Livraison en Slovaquie

| Méthode | Coût | Traitement | Transit | Livraison estimée |
|---|---:|---|---|---|
| Standard suivi | 4,90 € | Même jour ouvré avant 14h00 CEST | 2–4 jours ouvrés | 1–3 septembre 2026 |
| Express suivi | 12,90 € | Même jour ouvré avant 14h00 CEST | 1–2 jours ouvrés | 31 août–1er septembre 2026 |

Les batteries au lithium ne sont pas incluses. Les estimations de livraison excluent les corrections d'adresse et les perturbations du transporteur. Recalculez la livraison après un changement de destination ou de quantité dans le panier.

## Retours et garantie

Les produits non utilisés peuvent être retournés dans les 30 jours calendaires suivant la livraison via le formulaire de retour en ligne. Le client paie les frais de retour sauf si le produit est défectueux ou incorrect. L'emballage ouvert est accepté lorsque le chargeur, le câble et la documentation sont complets et non endommagés. Les remboursements sont effectués sur le moyen de paiement d'origine après inspection. Une garantie limitée de deux ans couvre les défauts de fabrication mais pas les dommages accidentels ou liquides.

## État de la transaction

Vérifié par rapport aux systèmes de catalogue, d'inventaire, de livraison et de retours à 10h00 CEST le 27 août 2026. Revalidez le prix, le stock, l'éligibilité de la destination, l'estimation de livraison et le périmètre de retour immédiatement avant le paiement.

[Acheter la variante UE noire]

L’exemple maintient le prix et la validité ensemble, sépare le traitement du transit, nomme le payeur du retour et définit le périmètre de chaque affirmation volatile. Un humain peut le lire ; un agent peut le mapper à des champs sans interpréter une phrase promotionnelle.

Galerie de designs

Utilisez le même produit, variante, vendeur, destination et horodatage dans chaque design afin que les tests de révision évaluent la compréhension des données plutôt que des exemples différents.

Liste de contrôle qualité

• Une seule identité produit canonique est séparée des variantes au niveau SKU et des offres au niveau vendeur.
• Les valeurs SKU, GTIN, ISBN ou numéro de pièce fabricant appartiennent à la variante exacte ; aucun identifiant n’est inféré ou fabriqué.
• Le nom du produit, la marque, le modèle, l’état, les attributs sélectionnés et l’URL canonique concordent dans le contenu visible, le schéma, le flux et le paiement.
• Le prix inclut la devise, l’unité ou la base de facturation, le périmètre fiscal, le vendeur, la règle de quantité et la validité lorsque pertinent.
• La disponibilité décrit le SKU et le vendeur sélectionnés, pas le produit parent ou un enregistrement d’entrepôt adjacent.
• La livraison indique le périmètre de destination, le coût, le seuil, le délai de traitement, le temps de transit, la livraison estimée et les restrictions sans traiter une estimation comme une garantie.
• Les retours indiquent le délai, l’événement déclencheur, l’état accepté, la méthode, les frais, le chemin de remboursement et les exceptions produit ou régionales.
• Les valeurs inconnues sont identifiées comme inconnues ; les cellules vides n’impliquent jamais gratuit, inclus ou disponible.
• Les faits volatiles proviennent de systèmes opérationnels et exposent une heure de vérification significative.
• Les réponses avec et sans JavaScript exposent toutes deux les faits critiques d’identité et d’offre nécessaires aux clients visés.
• Le balisage Product et Offer correspond au contenu visible et utilise la variante, le vendeur, la devise et le périmètre de politique corrects.
• L’action d’achat ou de transfert préserve la variante, l’offre, la destination, la quantité et l’attribution.
• Les états de rupture de stock, précommande, sur devis et abandonné modifient à la fois le message et l’action autorisée.
• Des tests automatisés détectent les discordances entre la page, le schéma, le flux, l’API et le paiement avant qu’une offre obsolète n’atteigne un agent.
• Une révision humaine vérifie le libellé des exceptions, les affirmations réglementées et les cas inhabituels de livraison ou de retour que la validation de champ ne peut juger.

Erreurs courantes

Traiter le schéma comme une copie produit cachée. Les données structurées décrivent des faits visibles ; elles ne doivent pas introduire un meilleur prix, une évaluation différente, une disponibilité plus large ou une promesse de retour différente de ce que la page affiche.

Utiliser un SKU parent pour chaque variante. Un vêtement bleu en taille moyenne et un vêtement noir en grande taille sont des sélections vendables différentes. Liez les identifiants, le prix, l’image, le stock et l’action à la variante sélectionnée.

Publier un prix sans périmètre. « 49 € » est incomplet lorsque la taxe, l’unité, la période d’abonnement, le vendeur, la quantité minimum, le marché ou l’expiration modifient le montant.

Qualifier une livraison inconnue de gratuite. La livraison doit être calculée ou explicitement indisponible pour la destination. Une valeur zéro est une promesse commerciale, pas un espace réservé.

Combiner traitement et transit. Un service de transporteur de deux jours expédié après cinq jours n’est pas une livraison en deux jours. Stockez et affichez les deux intervalles, puis calculez une fourchette de dates estimée.

Lier uniquement vers une page de retours générique. L’agent a besoin du délai applicable et des exceptions sur la page d’offre, plus une URL de politique stable pour les détails. Les exclusions de catégorie ne doivent pas être cachées derrière le lien.

Mettre en cache le stock comme un contenu éditorial. L’inventaire peut changer entre le crawl et le paiement. Utilisez des durées de vie de cache appropriées, une invalidation, des horodatages et une revalidation obligatoire avant l’engagement.

Créer une deuxième « page produit IA ». Les pages indexables parallèles divergent et fragmentent les signaux. Privilégiez une seule source canonique humain-et-machine avec des représentations alternatives uniquement pour un besoin technique documenté.

Faire mentir le CTA. Un article en rupture de stock ne peut pas avoir de bouton « Acheter maintenant » actif. Remplacez-le par une alerte de stock, une précommande, un devis ou une alternative qui reflète l’état réel.

Liens internes

Liez vers le haut vers la page catégorie lorsqu’un agent doit choisir parmi des produits, et latéralement vers la spécification de la page produit canonique lorsque l’équipe de production a besoin de règles d’évidence et de persuasion destinées aux humains. Liez vers un article de documentation pour l’installation, les détails de compatibilité, l’entretien ou l’utilisation après achat au lieu d’encombrer les champs de transaction avec des instructions.

Dans la fiche produit, gardez les liens adjacents à la condition qui crée la question suivante : la politique de retour complète à côté de la règle de retour résumée, les restrictions de livraison à côté de l’expédition, et les accessoires compatibles à côté de la spécification concernée. Utilisez un module de liens internes uniquement pour un petit ensemble d’alternatives expliquées ou de pages de support. Ne faites pas parcourir à un agent plusieurs liens vagues « en savoir plus » pour reconstituer une transaction.

Chaque offre liée doit préserver le contexte de variante et de vendeur. Les sélections paramétrées doivent se résoudre de manière prévisible, et les règles canoniques doivent empêcher les états de filtre, de devise et de destination de se multiplier en URL indexables en double.

Comment mesurer les résultats

Mesurez la résolution fiable des produits et la progression des transactions, pas seulement le trafic de la page. Établissez une référence par marché, appareil, client, produit, variante et vendeur lorsque le volume le permet.

Suivez :

• les produits valides et variantes vendables avec des identifiants complets ;
• les enregistrements Product et Offer passant la validation technique et le rapprochement commercial ;
• les discordances de prix, devise, stock, vendeur, livraison, retours et SKU sélectionné entre la page, le schéma, le flux, l’API et le paiement ;
• les requêtes de crawl ou d’agent recevant des données critiques utilisables sans échec de script, consentement, authentification ou délai d’attente ;
• les réponses d’achat et citations qui préservent les conditions de variante, vendeur, prix, disponibilité, destination, livraison et politique ;
• les événements de sélection de produit, ajout au panier, début de paiement, devis, réservation et commande finalisée attribués au client d’origine ou au transfert ;
• les transferts échoués causés par un stock obsolète, un prix modifié, une destination non prise en charge, une variante invalide, une session expirée ou un désaccord de politique ;
• les annulations, retours et contacts service client causés par un fait que l’agent a présenté incorrectement ou omis ;
• le temps entre le changement dans le système source et la représentation publique corrigée.

Utilisez l’Accessibilité IA et préparation des agents pour tester si les clients automatisés peuvent atteindre et interpréter la surface commerciale. Ouvrez le AmICited Cockpit pour comparer la visibilité, les sources citées, l’activité d’atterrissage et les résultats commerciaux sur la même fenêtre d’observation.

Suivez comment nous mesurons les résultats pour séparer la découverte, la représentation correcte, l’engagement, la progression de la transaction et les revenus. Annotez les migrations de catalogue, les campagnes de prix, les événements de stock, les changements de politique et les versions de protocole avant d’attribuer des mouvements. Une réponse produit citée n’est pas un succès si son offre ne peut pas survivre à la validation du paiement.

FAQ

Questions fréquemment posées