L'agent est intelligent. Le problème, c'est que le web est sale.
À 2 heures du matin, votre agent IA se connecte à un site pour vérifier les prix d'un concurrent. Mais le site affiche un CAPTCHA, modifie sa structure HTML et bloque les bots. L'agent ne panique pas. Il invente plutôt quelque chose de plausible. L'utilisateur croit cette hallucination comme un fait.
Dès que vous exposez un agent au web pendant l'exécution, vous livrez l'incertitude directement sous les yeux de l'utilisateur.
Le cœur du problème n'est pas « combien vous récupérez ». C'est la manière dont vous contractualisez l'interface de données que l'agent va consommer. Cet article ne parle pas de performance, mais de contrat d'interface.
TL;DR
- Le véritable enjeu pour connecter des données web à des agents IA et des serveurs MCP n'est pas l'ampleur de la collecte, mais la conception du contrat de données que l'agent consommera (interface orientée machine).
- Si l'agent navigue directement sur le web à chaque appel, les risques de blocage, de latence et d'hallucination se répercutent tels quels dans la réponse. En consultant un flux préalablement nettoyé comme ressource MCP, les réponses deviennent cohérentes et faciles à citer.
- Ne placez pas l'incertitude dans le runtime de l'agent ; déplacez-la vers le contrat backend. Hashscraper absorbe la collecte et la gestion des blocages via un backend managé, et ne transmet à l'agent que des flux contractualisés.
Table des matières
- Qu'est-ce que MCP ? — La prise standard des agents
- Deux voies : navigation directe ou flux contractualisé
- Tableau comparatif : non pas la performance, mais la localisation de la responsabilité
- Rédigez le schéma comme un contrat — tool et resource
- Les 4 principes d'ancrage contre les hallucinations
- Les 5 éléments d'un contrat pour les machines
- Les 5 étapes de conception de l'intégration
- Autodiagnostic en 5 questions
- FAQ
- Conclusion
- Commencer dès maintenant
Qu'est-ce que MCP ? — La prise standard des agents
Définition 1. MCP (Model Context Protocol) est un protocole qui définit une manière standardisée pour les agents IA de se connecter à des outils externes (tool, action) et à des données (resource, consultation).
Il est facile de l'imaginer comme une prise électrique. Si les fiches ont une forme différente dans chaque pays, il faut fabriquer un adaptateur à chaque fois. MCP est une prise standard qui unifie cette norme. Il suffit à l'agent de s'y brancher pour communiquer de la même façon avec n'importe quel backend.
MCP expose deux types de câbles. Un tool est une action qui signifie « exécute quelque chose », tandis qu'une resource est une donnée qui signifie « consulte quelque chose ». Pour connecter des données web, nous nous concentrons sur la seconde : la resource. C'est ici que l'orientation de la conception diverge.
Deux voies : navigation directe ou flux contractualisé
Il existe principalement deux façons de connecter le web à un agent.
Voie A — L'agent navigue directement sur le web à chaque appel. Lorsqu'un utilisateur pose une question, l'agent se rend alors sur le site. Cela semble flexible, mais les blocages, CAPTCHA, modifications de structure et latences du site se déversent intégralement dans la qualité de réponse. La réponse à la même question diffère entre hier et aujourd'hui. Si le site bloque l'accès, l'agent ne s'arrête pas : il invente quelque chose de plausible. C'est un terreau d'hallucinations.
Voie B — L'agent consulte un flux préalablement collecté et nettoyé comme ressource MCP. Le backend a déjà achevé la collecte, et l'agent ne récupère que les résultats structurés conformément au contrat. Les réponses sont cohérentes, et les sources jointes facilitent les citations.
La navigation directe consiste à envoyer l'agent dans la nature à chaque fois ; le flux contractualisé consiste à lui remettre des documents depuis un guichet nettoyé.
Ne nous méprenons pas. Il ne s'agit pas de savoir « quelle voie est la plus rapide ». Il s'agit de savoir où l'incertitude s'accumule. La voie A accumule l'incertitude dans le runtime de l'agent, juste devant l'utilisateur. La voie B repousse l'incertitude derrière le contrat backend.
Tableau comparatif : non pas la performance, mais la localisation de la responsabilité
Définition 2. Un contrat de données (data contract) est un engagement orienté machine qui fixe à l'avance les champs, types, significations et métadonnées des données que recevra l'agent, afin que les deux parties puissent se fier à cette spécification.
| Axe | Navigation directe (voie A) | Flux de ressources MCP (voie B) |
|---|---|---|
| Risque de blocage | Exposé tel quel au runtime de l'agent | Isolé derrière le contrat backend |
| Latence | Survient au moment de l'appel, imprévisible | Consultation stable sur la base d'un flux nettoyé |
| Coût | Nouvelle collecte à chaque appel | Une collecte, répartie sur de nombreuses consultations |
| Cohérence des réponses | Varie à chaque appel | Même entrée → même résultat |
| Risque d'hallucination | Invention en cas d'échec | Réduit par l'indication de résultats vides et des sources |
| Maintenance | Collecte couplée à la logique de l'agent | Gestion séparée dans la couche contractuelle |
Une seule conclusion traverse ce tableau. La différence ne réside pas dans l'axe de performance, mais dans la localisation de la responsabilité. Faut-il faire porter à l'agent la responsabilité des blocages, de la latence et des hallucinations, ou au contrat ?
Des agents légers, des contrats épais.
Rédigez le schéma comme un contrat — tool et resource
Pour qu'un contrat inspire confiance, sa formulation doit être précise. Il en va de même pour les schémas MCP tool et resource.
Fixez les types et la signification des champs. Le schéma doit préciser si price est une chaîne ou un entier, quelle est la devise et quelle valeur représente « rupture de stock ». Dès que l'agent doit deviner le sens d'une valeur, le contrat est rompu.
Ajoutez obligatoirement les métadonnées qui permettent la citation. Trois éléments sont indispensables.
- URL source — Pour que l'agent puisse citer dans sa réponse « d'où cela provient ».
- Heure de collecte — Pour pouvoir évaluer et afficher la fraîcheur des données.
- Identifiant (id) — Pour pouvoir consulter à nouveau le même objet et éliminer les doublons.
Une donnée sans source, horodatage ni identifiant est, pour un agent, semblable à une rumeur sans fondement.
Ces trois lignes de métadonnées créent la citabilité (citability). L'objectif du contrat est de permettre à l'agent de répondre non pas « le prix est de 12 000 wons », mais « le prix est de 12 000 wons (source : X, collecte : aujourd'hui à 9 heures) ».
Les 4 principes d'ancrage contre les hallucinations
Les hallucinations d'un agent surviennent généralement « parce qu'il ne peut pas dire qu'il revient les mains vides ». Le contrat supprime cette marge d'ambiguïté.
- Répondez en JSON structuré. Du JSON conforme au schéma, pas du texte libre. Cela supprime la place laissée à l'agent pour imaginer des éléments lors de l'analyse.
- Imposez les champs de source. Un enregistrement sans source viole le contrat. Les données impossibles à citer ne doivent pas apparaître dans la réponse.
- Indiquez explicitement les résultats vides. Retournez « aucun résultat » comme valeur explicite. Le silence appelle l'hallucination.
- Indiquez la fraîcheur. Transmettez l'heure de collecte afin que l'agent puisse indiquer lui-même « à quelle date » l'information est valable.
Les hallucinations ne viennent pas du fait que les données sont erronées, mais du fait qu'on laisse l'agent combler les blancs.
Les 5 éléments d'un contrat pour les machines
Contrairement à une API destinée aux humains, un contrat orienté machine appelé de manière répétée par un agent requiert cinq éléments.
- Idempotence (idempotency) — Envoyer plusieurs fois la même requête doit produire les mêmes résultats et effets secondaires. C'est une base essentielle dans un environnement d'agents où les nouvelles tentatives sont fréquentes.
- rate limit — Contrôle les pics d'appels au niveau du contrat, afin de protéger à la fois le backend et l'agent.
- Jetons et périmètres d'autorisation — Limite par périmètre les ressources auxquelles chaque agent peut accéder.
- Versionnage du schéma — Signale les modifications de champs par une version. Ne modifiez pas silencieusement le contrat.
- Convention d'erreurs — Retourne les échecs avec des codes et formats prédéfinis. Ainsi, l'agent ne confond pas un échec avec des « données vides réussies ».
Un contrat révèle sa vraie valeur non pas quand tout va bien, mais quand quelque chose se passe mal.
Les 5 étapes de conception de l'intégration
- Définir l'usage — Commencez par déterminer ce que l'agent fera avec ces données : comparaison de prix, synthèse de réputation, etc. L'usage détermine le schéma.
- Choisir l'architecture — Navigation directe (voie A) ou flux contractualisé (voie B) ? La plupart des agents en production suivent la voie B.
- Finaliser le schéma — Fixez le type et la signification des champs, et rendez obligatoires les métadonnées de source, heure de collecte et identifiant.
- Ajouter les éléments contractuels — Ajoutez l'idempotence, le rate limit, les périmètres d'autorisation, le versionnage et les conventions d'erreurs.
- Vérifier l'ancrage — Testez que les résultats vides, les champs source et la fraîcheur sont réellement imposés, et que l'agent n'invente rien.
Une bonne intégration ne commence pas par le code, mais par le contrat.
Précisons une chose. Ces cinq étapes concernent toutes la couche du contrat d'interface. La performance de collecte — « récupérer en quelle quantité et à quelle vitesse » — relève d'une couche distincte, traitée dans l'article [Pipeline de collecte massive en temps réel (023)]. Ici, nous ne concevons que le contrat que l'agent consommera.
Autodiagnostic en 5 questions
Vérifiez si la connexion entre votre agent et les données web est réellement contractuelle.
- [ ] Les données transmises à l'agent comportent-elles toujours une URL source, une heure de collecte et un identifiant ?
- [ ] En l'absence de résultat, retournez-vous « aucun résultat » comme valeur explicite ? (L'agent n'invente-t-il rien ?)
- [ ] La réponse est-elle un JSON à schéma fixe plutôt que du texte libre ?
- [ ] S'agit-il d'un contrat idempotent produisant le même résultat pour une même requête répétée ? Disposez-vous d'un rate limit et de périmètres d'autorisation ?
- [ ] Lorsque les champs changent, en informez-vous l'agent par une version de schéma et une convention d'erreurs ?
Si trois éléments ou moins s'appliquent, vous n'avez pas connecté des données : vous chargez l'incertitude dans le runtime de l'agent et la livrez à l'utilisateur.
FAQ
Q. Comment connecter des données web en temps réel à un agent IA ou à un serveur MCP ?
R. Ne laissez pas l'agent naviguer directement sur les sites à chaque appel ; concevez le système pour qu'il consulte, comme ressources MCP, des données préalablement collectées et nettoyées. L'essentiel est le contrat de données. Fixez les types et significations des champs, rendez obligatoires les URL sources, heures de collecte et identifiants comme métadonnées, puis ajoutez l'idempotence, le rate limit, les périmètres d'autorisation, le versionnage du schéma et les conventions d'erreurs. Il est plus stable de laisser un backend managé absorber la collecte et la gestion des blocages, tandis que l'agent ne consomme que des flux contractualisés.
Q. Quelle est la différence entre tool et resource ?
R. Un tool est une action qui signifie « exécuter », tandis qu'une resource est une donnée qui signifie « consulter ». Pour transmettre un flux nettoyé lors d'une intégration de données web, on l'expose principalement comme resource. Il est préférable de séparer en tool les actions qui modifient l'état, par exemple le déclenchement d'une collecte, afin de garder un contrat clair.
Q. Mon agent invente souvent des données inexistantes. Que dois-je corriger ?
R. Imposez un contrat d'ancrage. Répondez en JSON structuré, rendez le champ source obligatoire, retournez les résultats vides sous forme de valeurs explicites et indiquez la fraîcheur par l'heure de collecte. Les hallucinations surviennent généralement non parce que les données sont erronées, mais parce qu'on laisse l'agent « combler les blancs ».
Q. Comment gérer dans l'agent le problème des sites qui bloquent continuellement l'accès ?
R. Ne le gérez pas dans l'agent. La bonne pratique est de déplacer la gestion des blocages vers le backend managé situé derrière le contrat. Hashscraper absorbe la collecte et la gestion des blocages dans un backend managé, puis ne transmet à l'agent que des flux déjà nettoyés, conformément au contrat. Cette structure évite de placer l'incertitude dans le runtime de l'agent.
Conclusion
Un agent n'est pas conçu pour assumer l'intégralité du web. Gérer la saleté du web est le rôle du backend ; le rôle de l'agent est de recevoir des documents nettoyés depuis un guichet contractualisé et de les citer avec précision.
C'est pourquoi le centre de gravité de la conception n'est pas « combien récupérer », mais « comment contractualiser ». Un contrat qui fixe les champs, joint la source, l'heure et l'identifiant, indique explicitement les résultats vides et intègre l'idempotence, le versionnage et les conventions d'erreurs. Ce seul contrat repousse les hallucinations et l'instabilité des réponses de l'agent derrière le backend.
Ne placez pas l'incertitude dans le runtime de l'agent. Déplacez-la vers le contrat backend. Des agents légers, des contrats épais.
La collecte et la gestion des blocages sont absorbées par un backend managé. Hashscraper propose une collecte managée qui absorbe la collecte, la gestion des blocages et le nettoyage ; l'agent n'a plus qu'à consommer les flux contractualisés.
Pour un contexte plus large, consultez Comparaison des services coréens de collecte de données (la véritable carte de 2026) et Le monitoring n'est pas la collecte, c'est l'alerte — Créer une boucle de réponse avec les données de prix et de réputation.
Commencer dès maintenant
Si vous souhaitez ajouter un contrat de données web stable à un agent IA ou à un serveur MCP, le plus rapide est de commencer par un backend managé qui absorbe la collecte, les blocages et le nettoyage. Laissez l'agent ne consommer que des flux contractualisés, et confiez le web sauvage au backend.
Hashscraper absorbe le web sauvage côté backend grâce à son expérience de collecte sur plus de 5 000 sites coréens, ses proxys dans 195 pays et sa précision de 99,7 %, puis ne transmet à l'agent que des flux nettoyés conformément au contrat. L'entreprise a travaillé avec plus de 500 sociétés et maintenu zéro incident juridique. À l'inscription, vous recevez 50 000 crédits.
