NLWeb, WebMCP, MCP : guide technique pour rendre votre site actionnable par les agents IA

> En bref : ce guide couvre l'implémentation technique du niveau Agent-Ready — architecture d'un endpoint NLWeb, indexation vectorielle, structuration Schema.org, et comment articuler NLWeb avec WebMCP et MCP sur une même stack. Il complète notre guide sur les 4 niveaux de l'optimisation agentique, qui reste la référence conceptuelle et stratégique.

Savoir qu'il faut « devenir agent-ready » ne dit rien de la façon de s'y prendre. Entre la théorie (SEO → GEO → AEO → Agent-Ready) et la mise en production, il y a un pipeline technique concret : structurer les données, indexer un catalogue, exposer un endpoint, sécuriser les actions. C'est ce pipeline que ce guide détaille, avec le retour d'expérience du déploiement NLWeb de busony.com.

Où se branchent NLWeb, WebMCP et MCP dans votre stack

Les trois protocoles ne sont pas interchangeables — ils répondent à des besoins différents et se combinent :

Concrètement : NLWeb répond à « que proposez-vous ? », WebMCP répond à « fais-le pour moi dans cette page », MCP répond à « fais-le pour moi depuis mon assistant, sans que j'ouvre votre site ». Un site agent-ready mature peut déployer les trois, mais NLWeb est généralement le point d'entrée le plus rapide à mettre en production — c'est celui que nous détaillons ici.

Prérequis commun : structurer vos données en Schema.org JSON-LD

Avant d'exposer quoi que ce soit à un agent, vos données doivent exister sous une forme structurée exploitable — pas seulement dans du HTML habillé de CSS. Schema.org en JSON-LD est le format pivot que NLWeb, les moteurs GEO et la plupart des agents savent lire nativement.

{
  "@context": "https://schema.org",
  "@type": "Service",
  "name": "Audit SEO & GEO 360°",
  "description": "Audit complet de votre position sur les 4 niveaux de l'optimisation agentique : SEO, GEO, AEO, Agent-Ready.",
  "provider": { "@type": "Organization", "name": "Busony", "url": "https://busony.com" },
  "areaServed": "France",
  "offers": {
    "@type": "Offer",
    "priceCurrency": "EUR",
    "availability": "https://schema.org/InStock"
  }
}

C'est cette même structure — nom, description, offre, disponibilité — qui alimente ensuite l'index NLWeb, les tools WebMCP et les outils MCP. Un seul travail de structuration, trois protocoles qui en héritent.

Déployer un endpoint NLWeb : architecture et implémentation

Le principe : indexation vectorielle de votre catalogue

NLWeb ne renvoie pas du HTML : il renvoie des résultats structurés classés par pertinence, à partir d'une question en langage libre. Pour ça, chaque service, produit ou contenu de votre site doit être transformé en vecteur (embedding) et stocké dans une base vectorielle interrogeable en quelques millisecondes.

Le pipeline typique :

1. Extraction : chaque service/produit/page devient un document structuré (titre, description, catégorie, métadonnées). 2. Embedding : ce document est transformé en vecteur numérique via un modèle d'embedding. 3. Indexation : le vecteur est stocké dans un moteur vectoriel — busony.com utilise Qdrant — avec les métadonnées associées. 4. Requête : la question de l'agent est elle-même transformée en vecteur, comparée à l'index, et les résultats les plus proches sont renvoyés avec un score de pertinence.

L'endpoint de requête

Un endpoint NLWeb minimal expose une seule route, appelée en GET avec la question en paramètre :

GET /ask?query=services+pour+PME+exportatrice

Réponse (200 OK) :
{
  "query": "services pour PME exportatrice",
  "results": [
    { "name": "Exportik", "score": 94, "type": "Service", "url": "/fr/exportik" },
    { "name": "SEO-GEO pour PME export", "score": 91, "type": "Service", "url": "/fr/secteurs/export" },
    { "name": "Agentic AI Optimization", "score": 87, "type": "Service", "url": "/fr/ai-agents/agentic-optimization" }
  ]
}

Côté implémentation, sur une stack Next.js, ça se résume à une route d'API qui reçoit la requête, l'embed, interroge le moteur vectoriel et formate la réponse :

// app/api/ask/route.js — exemple simplifié
export async function GET(request) {
  const query = new URL(request.url).searchParams.get('query');
  const queryVector = await embed(query);              // même modèle d'embedding que l'indexation
  const matches = await vectorDB.search(queryVector, {  // Qdrant, Pinecone, pgvector...
    limit: 10,
    scoreThreshold: 0.5,
  });
  return Response.json({
    query,
    results: matches.map(m => ({
      name: m.payload.name,
      score: Math.round(m.score * 100),
      type: m.payload.type,
      url: m.payload.url,
    })),
  });
}

Scoring de pertinence : où mettre le seuil

Un score de pertinence sert à filtrer le bruit — inutile de renvoyer un résultat à 20% de similarité, l'agent ne le retiendra pas. Sur busony.com, les résultats affichés se situent entre 85 et 95 : un seuil réaliste pour un catalogue de taille moyenne (15 services) où chaque entrée est bien différenciée. Sur un catalogue e-commerce de plusieurs milliers de références, le seuil doit souvent être plus permissif (60-70%) pour ne pas sur-filtrer des variantes de produits proches.

Étude de cas : le déploiement NLWeb de busony.com

busony.com est en production sur NLWeb depuis juin 2026 : 15 services indexés dans Qdrant, scores de pertinence 85–95, réponses en moins de 200ms. Le déploiement initial — indexation du catalogue de services, mise en place de l'endpoint, tests de requêtes — a représenté une journée de travail pour un premier POC fonctionnel. La maintenance ensuite consiste à ré-indexer à chaque ajout ou modification de service, pour que l'index ne diverge jamais du contenu réellement publié sur le site.

Bonnes pratiques de maintenance

• Ré-indexation automatique : déclenchée à chaque publication ou modification de contenu, pas seulement en batch nocturne — un agent qui reçoit une offre expirée ou un prix obsolète nuit à la confiance.
• Granularité fine : indexer au niveau du service ou du produit, pas de la page entière — un agent cherche une réponse précise, pas un document de 2000 mots à résumer lui-même.
• Métadonnées de filtrage : catégorie, zone géographique, disponibilité en métadonnées permet à l'agent de filtrer sans requête supplémentaire.
• Monitoring des requêtes entrantes : logger les questions posées par les agents révèle des intentions de recherche que votre contenu ne couvre pas encore.

Exposer des actions avec WebMCP

NLWeb couvre la lecture — WebMCP couvre l'action déclenchée depuis le navigateur, dans la session de l'utilisateur (ajout au panier, réservation, soumission de formulaire), via l'API navigator.modelContext.registerTool(). C'est un protocole encore en DevTrial (Chrome 146), avec un modèle de sécurité spécifique — same-origin, CSP, confirmation utilisateur obligatoire pour les actions sensibles. Nous avons documenté son implémentation en détail, avec exemples de code, dans notre guide WebMCP dédié.

Connecter des agents via un serveur MCP

Pour qu'un agent Claude ou compatible interagisse avec vos systèmes sans jamais ouvrir votre site — recherche de disponibilité, préparation de devis, interrogation de votre base de connaissances — il faut un serveur MCP dédié, backend, avec sa propre authentification (OAuth 2.1 ou clés API). MCP répond à un besoin différent de WebMCP : il ne dépend pas d'une page ouverte dans un navigateur. Le positionnement de MCP face aux autres protocoles agentiques est détaillé dans notre article MCP vs UDP.

Sécuriser la couche agent : checklist technique

Exposer des données et des actions à des agents autonomes change le modèle de menace. Quelques principes à appliquer avant toute mise en production :

• Distinguer lecture, recommandation et exécution : un endpoint qui renvoie des informations ne doit jamais partager son niveau de permission avec un endpoint qui déclenche une action réelle.
• Authentification et scopes par action : chaque outil exposé (NLWeb, WebMCP, MCP) doit avoir ses propres permissions, pas un accès global à toute l'API.
• Validation humaine sur les actions sensibles : paiement, annulation, modification de données personnelles — une confirmation explicite reste nécessaire, même si l'agent est autorisé à initier l'action.
• Rate limiting dédié aux agents : le trafic agentique a un profil différent du trafic humain (requêtes plus fréquentes, plus régulières) — un rate limiting mal calibré casse l'expérience agent ou laisse la porte ouverte à l'abus.
• Logs d'audit par agent et par action : en cas d'anomalie, pouvoir retracer quel agent a fait quelle requête, à quel horodatage, avec quel résultat.
• Synchronisation temps réel des données sensibles : prix, stock, disponibilité — un agent qui transmet une information obsolète à son utilisateur nuit à votre marque autant qu'à sa confiance dans l'agent.

Checklist de déploiement technique

• Données structurées en Schema.org JSON-LD pour chaque service ou produit
• Pipeline d'indexation (extraction → embedding → base vectorielle) documenté et automatisé
• Endpoint NLWeb testé avec un jeu de requêtes représentatives, scores de pertinence validés
• Ré-indexation automatique déclenchée à chaque publication de contenu
• Actions sensibles exposées via WebMCP ou MCP protégées par confirmation humaine
• Authentification et scopes définis par outil, pas par accès global
• Rate limiting et logs d'audit spécifiques au trafic agentique
• Monitoring des requêtes entrantes pour identifier les intentions de recherche non couvertes

Conclusion

Le niveau Agent-Ready n'est pas une fonctionnalité qu'on coche une fois — c'est une infrastructure qui se maintient, se ré-indexe et se sécurise en continu, au même titre qu'un site web classique. La bonne nouvelle : la brique la plus rentable à déployer en premier, un endpoint NLWeb, ne demande ni refonte du site ni changement d'architecture profond — juste un pipeline d'indexation propre et un endpoint bien conçu.

Busony déploie NLWeb, prépare WebMCP et connecte MCP pour ses clients — sur la base de ce que nous avons construit et mesuré pour busony.com lui-même.

Demander un audit technique Agent-Ready →