On parle beaucoup de MCP depuis quelques temps, (et également des « skills » de Claude depuis peu). Le Model Context Protocol est un mécanisme standardisé pour brancher des sources de données externes sur un LLM et lui donner accès à des informations qu’il ne pourrait pas avoir autrement. C’est utile, voire, dans de nombreux cas, essentiels.
Les Skills (Agent Skills) sont des capacités modulaires contenant des instructions, des scripts, des templates, ou des métadonnées permettant d’encadrer une tâche lorsque Claude trouve la capacité utile.
Les Skills peuvent, avec une bonne documentation source, faire le travail du MCP.
Mais il y a un angle mort dans cette conversation, et il concerne la donnée elle-même.
Un MCP n’est pas une couche d’intelligence, c’est l’apport à un outil de données et du cadrage de cette donnée par un autre outil. Ce qu’il transporte (la qualité, la fiabilité, la documentation de cette donnée, donc) détermine à peu près tout ce que le LLM sera capable d’en faire.
Le problème de fond : un LLM ne sait pas ce qu’il ne sait pas
Les hallucinations génératives ne sont pas un bug qu’on corrige avec une mise à jour. Elles sont le comportement naturel d’un système conçu pour produire des enchaînements de tokens plausibles, et non pour vérifier des faits.
Par exemple, il est « plausible » pour ChatGPT de dire que Victor Hugo est né en mars 1802 à Dijon (exemple classique d’hallucination), mais c’est pourtant non factuel. Il est plus correct de dire qu’il est né le 26 février 1802 à Besançon.
De la même façon, lorsque j’ai commencé la production du MCP de Babbar, Claude ne comprenait pas mes instructions sur l’interprétation des données de duplication, et il a fallu éditer pour réaliser une bonne définition : il pensait qu’un taux de duplication inférieur à 87% restait suspect ou dangereux (même si je lui disais clairement que d’après nos tests, en dessous de 87%, aucun problème) : en définissant cette métrique il a mieux compris la notion de seuil.
Quand le modèle n’a pas d’information fiable sur laquelle s’appuyer, il complète, et il complète de manière convaincante (voir A Survey on Hallucination in Large Language Models: Principles, Taxonomy, Challenges, and Open Questions).
En SEO, ça pose un problème précis. Demandez à un LLM sans accès externe d’analyser le profil de liens d’un site, d’évaluer l’autorité d’un concurrent ou d’identifier des opportunités netlinking : il va produire quelque chose. Ce quelque chose aura l’apparence d’une analyse. Il sera structuré, argumenté, raisonnable. Et il sera, en tout ou partie, inventé.
Ce n’est pas vraiment la faute du modèle (quoique). C’est la faute de celui qui lui a posé la question sans lui donner les moyens d’y répondre correctement (et vous pouvez éviter ça).
Ce qui fait une donnée utilisable par un LLM
Brancher un MCP ne résout pas ce problème par magie. Il le déplace. La question n’est plus « le modèle a-t-il de la donnée ? » mais « la donnée qu’on lui donne est-elle de qualité suffisante pour qu’il en fasse quelque chose d’utile ? » Pour qu’une source de données soit réellement exploitable par un LLM dans un contexte de travail SEO, elle doit réunir trois conditions.
Elle doit être fiable.
Fiable au sens mesurable : on sait comment la métrique est calculée, on peut la reproduire, on peut expliquer une variation. Une donnée opaque, un score composite dont la formule est inconnue, n’est pas exploitable de manière rigoureuse. Le modèle ne peut pas raisonner sur ce qu’il ne comprend pas, et vous non plus.
Elle doit être documentée.
C’est la condition la plus sous-estimée. Un LLM ne se contente pas de lire des chiffres : il a besoin de contexte pour les interpréter. Qu’est-ce que signifie une valeur de 40 sur cette métrique ? Est-ce bon ou mauvais ? Par rapport à quoi ? Si la documentation de la source de données ne répond pas à ces questions, le modèle va combler les trous, et on revient au problème de départ.
Elle doit être structurée et actuelle.
Une API avec des réponses JSON prévisibles, des endpoints bien définis et des données régulièrement mises à jour est infiniment plus utilisable qu’un export CSV mensuel ou qu’un outil dont le format de sortie change selon la version. Le MCP n’est qu’un relais et la lisibilité de ce qu’il transporte est une contrainte amont.
Pourquoi c’est important maintenant
La prolifération des MCPs pour outils SEO produit beaucoup de promesses. « Connectez votre outil SEO à votre LLM préféré et automatisez vos audits. » L’intention est bonne, l’exécution peut être inégale.
La différence entre un MCP qui apporte de la valeur réelle et un MCP qui produit de la fausse confiance se jouera essentiellement sur deux points : la qualité intrinsèque de la donnée exposée, et la qualité de sa documentation.
Un LLM équipé d’un MCP bien documenté et connecté à une source de données rigoureuse peut effectivement accélérer des tâches d’analyse qui prenaient des heures. Un LLM équipé d’un MCP connecté à une source opaque ou malcalibrée va produire des analyses plausibles mais non vérifiables, ce qui est probablement pire que de ne rien produire du tout.
Si vous réalisez un MCP pour votre outil SEO, faites preuve de transparence sur ce que sont réellement les données. Allez dans le détail sur les définitions de chaque élément.
Ce que ça change dans le choix des outils
En pratique, ça signifie que la valeur d’un MCP SEO est indexée sur la valeur de l’outil sous-jacent, et plus précisément sur la transparence de sa mécanique. Un outil dont on comprend comment les métriques sont calculées, dont les évolutions sont tracées, dont les limitations sont documentées, est un bien meilleur candidat à une intégration LLM qu’un outil dont le score global est une boîte noire.
Ce n’est pas un critère nouveau dans le choix d’un outil SEO. Mais il devient décisif dès qu’on veut automatiser une partie du travail d’analyse : un MCP exporte autant les forces de l’outil sous-jacent que ses zones d’ombre. Ça reste un critère qui devient décisif dès qu’on veut réaliser une partie du travail d’analyse, et à fortiori d’autant plus critique lorsqu’on veut l’automatiser.
La question pratique devient : « la donnée de cet outil est-elle calibrée pour qu’un LLM puisse en faire quelque chose d’utile ? ».
Aujourd’hui, le même engouement arrive sur les skills de Claude, mais le sujet de fond ne change pas : quelle donnée fournissez-vous au LLM, et comment encadrez-vous l’usage de ces données ?
Le MCP, les skills, Claude Code et tout ce qui suivra sont des révélateurs utiles. Ils forcent une question que beaucoup d’équipes SEO n’ont jamais eu à formuler explicitement : pourquoi utilisez-vous cette donnée dans votre LLM plutôt qu’une autre ? Qu’est-ce qui fait que vos outils fournissent une donnée de bonne qualité ?
Savoir répondre à ces questions, c’est comprendre ce qu’on automatise vraiment et ce qu’on ne devrait pas automatiser encore. Derrière chaque MCP, il y a une définition implicite de la qualité de la donnée. Autant la rendre explicite avant de brancher quoi que ce soit.
C’est exactement la logique qui a guidé la construction de Babbar, Yourtext Guru et les MCP qui y sont connectés : documenter les métriques, poser les seuils d’interprétation, définir les limites, avant d’exposer la donnée à un modèle.
Deux points de départ concrets si vous voulez creuser : les métriques Babbar et le filtre QBST de YourTextGuru.
