Un test réalisé en juillet auprès de 200 restaurants d'Amsterdam a montré que les assistants IA actuels ne parviennent pas à finaliser une réservation de table car le widget de réservation est caché à l'intérieur d'un iframe.

Pourquoi l'iframe bloque les agents

La plupart des outils de réservation en ligne sont fournis sous la forme d'un iframe intégré. Un visiteur clique sur un bouton « Réserver », un calendrier s'affiche, et l'utilisateur sélectionne un créneau horaire. Pour un humain, le processus fonctionne ; pour un agent IA, il s'interrompt.

  • L'agent analyse la page HTML principale.
  • Le bouton de réservation pointe vers une URL sur un domaine différent.
  • Le navigateur charge cette URL à l'intérieur d'un iframe, l'isolant ainsi de la page parente.

Comme la politique de même origine (same-origin policy) empêche les scripts de la page parente de lire le DOM de l'iframe ou d'intercepter ses appels réseau, un agent IA qui lit le contenu de la page et envoie des requêtes HTTP ne voit que le bouton. Il ne voit jamais le calendrier, les créneaux horaires ou le flux de confirmation. Même s'il clique sur le bouton, il doit encore résoudre des captchas, s'adapter aux changements de mise en page ou contourner les défenses anti-automatisation employées par de nombreux services de réservation.

Le lien lisible par machine manquant

Un audit distinct portant sur 163 sites de restaurants fonctionnels n'en a trouvé que neuf qui exposaient des données de réservation lisibles par machine. Ces neuf sites listaient des informations de base — nom et adresse — en utilisant le balisage schema.org, mais aucun n'incluait d'actions de réservation qu'un agent pourrait invoquer. Schema.org définit des types tels que ReserveAction à cette fin, pourtant la plupart des sites ne publient que des métadonnées descriptives, et non des instructions exploitables.

En pratique, un assistant recherche des données structurées qui lui indiquent comment accomplir une tâche, et pas seulement quelle est la tâche. Sans un ReserveAction ou un point de terminaison (endpoint) comparable, l'agent en revient à simuler un clic humain, ce qui, comme décrit précédemment, est peu fiable.

Une solution pratique qui ne dénature pas l'interface utilisateur

  1. Publier une API de réservation – Créez un point de terminaison HTTP léger qui accepte des requêtes JSON pour les requêtes de disponibilité et la création de réservations. L'API renvoie des champs tels que la date, l'heure, la taille du groupe et le code de confirmation. N'importe quel agent peut la consommer sans avoir à rendre une page.
  2. Rendre l'API découvrable – Placez un pointeur dans un emplacement bien connu, tel que /.well-known/booking, ou intégrez une entrée ReserveAction dans le balisage schema.org de la page. Cela indique aux agents qu'« il existe un moyen programmatique de réserver ici » sans nécessiter de scraping.
  3. Adopter le Model Context Protocol (MCP) – Le MCP permet aux assistants d'invoquer directement des outils externes, en transmettant des entrées et en recevant des sorties structurées. Les principaux fournisseurs d'IA prennent déjà en charge le MCP ; ainsi, un restaurant qui implémente un point de terminaison compatible MCP peut être appelé par des agents comme s'il s'agissait d'une fonction intégrée.

Ces étapes permettent de conserver l'iframe visuel pour les utilisateurs humains tout en offrant aux agents un chemin propre et fiable vers les mêmes données de réservation.

À retenir

L'intégration d'un calendrier dans un iframe protège le flux visuel pour les humains, mais laisse les assistants IA dans l'obscurité. L'ajout d'une API de réservation modeste et bien documentée, et sa promotion via des métadonnées standard ou le MCP, ouvre un nouveau canal de réservation sans avoir à refondre le site web. Cet effort booste la visibilité auprès de la prochaine génération d'assistants numériques, et le risque peut être géré avec les mêmes contrôles de sécurité que ceux déjà utilisés sur l'interface utilisateur existante.