Deux protocoles dominent le contrôle navigateur par IA : CDP (Chrome DevTools Protocol) et MCP (Model Context Protocol). Ils résolvent des problèmes différents à des couches différentes, mais les développeurs qui construisent des agents navigateur les confondent souvent ou choisissent le mauvais pour leur cas d'usage. Ce guide explique ce que fait chaque protocole, quand utiliser lequel et comment ils fonctionnent ensemble dans un stack d'agents en production.
TL;DR : CDP donne à votre agent un contrôle direct de bas niveau sur un navigateur via une connexion WebSocket. MCP donne à votre LLM des outils navigateur de haut niveau via une interface standardisée de tool-use. CDP est le moteur ; MCP est le volant. La plupart des agents IA en production ont besoin des deux : MCP pour que le LLM décide des actions, CDP en dessous pour que le navigateur fonctionne réellement. Clawbrowser supporte les deux nativement.
Note : « CDP » dans cet article désigne Chrome DevTools Protocol, le standard de contrôle navigateur.
Ce que CDP et MCP sont réellement
CDP : Chrome DevTools Protocol
CDP est un protocole basé sur WebSocket pour contrôler les navigateurs Chromium de manière programmatique. Google l'a créé pour Chrome DevTools (l'inspecteur que vous ouvrez avec F12), mais il est devenu le standard pour l'automatisation navigateur. Playwright, Puppeteer et toutes les grandes bibliothèques d'automatisation utilisent CDP en interne.
Quand vous appelez page.goto() dans Playwright, une commande CDP est envoyée par WebSocket au navigateur. CDP offre un contrôle granulaire : naviguer entre les pages, exécuter du JavaScript, intercepter les requêtes réseau, manipuler les cookies et capturer des screenshots.
# CDP: your code controls the browser directly
from playwright.async_api import async_playwright
async with async_playwright() as p:
browser = await p.chromium.connect_over_cdp("http://127.0.0.1:9222")Pour le guide CDP complet, voir Navigateur CDP pour les agents d'IA : Guide du développeur.
MCP : Model Context Protocol
MCP est un protocole qui standardise la connexion des LLMs aux outils externes. Au lieu d'écrire des définitions de function-call personnalisées pour chaque outil, le LLM découvre les outils disponibles via un MCP server et les appelle via une interface standard.
Pour le contrôle navigateur, un MCP server expose des actions comme navigate, click, type, screenshot et extract en tant qu'outils que le LLM peut invoquer. Le LLM décide quel outil appeler en fonction de la tâche. Pas de code Playwright, pas de sélecteurs CSS, pas de définitions d'outils personnalisées dans votre agent.
{
"mcpServers": {
"clawbrowser": {
"command": "clawctl",
"args": ["mcp", "serve"]Ajoutez cette configuration à Claude Code, Cursor, Gemini CLI ou tout agent compatible MCP. Le LLM obtient immédiatement des outils navigateur.
Pourquoi ils sont confondus
Les deux protocoles connectent un agent IA à un navigateur. Les deux utilisent le mot « protocole ». Les deux apparaissent dans les mêmes conversations sur l'infrastructure des agents IA. Mais ils opèrent à des couches différentes :
- CDP est un protocole au niveau navigateur. Il communique avec Chromium.
- MCP est un protocole au niveau application. Il communique avec les LLMs.
Un MCP server navigateur utilise CDP en interne pour contrôler le navigateur. Ce ne sont pas des alternatives. Ce sont des couches dans le même stack.
Comparaison directe
| CDP (Chrome DevTools Protocol) | MCP (Model Context Protocol) | |
|---|---|---|
| Créé par | Google (équipe Chrome) | Anthropic |
| Type de protocole | Contrôle navigateur (WebSocket) | Utilisation d'outils (stdio/SSE) |
| Qui l'appelle | Votre code (Playwright, Puppeteer, WebSocket brut) | Un LLM (Claude, GPT, Gemini) |
| Niveau de contrôle | Bas niveau : DOM, réseau, exécution JavaScript, cookies | Haut niveau : navigate, click, type, screenshot, extract |
| Configuration | Connexion au port de débogage du navigateur | Configurer un MCP server dans votre agent |
| Flexibilité | Totale : tout ce que le navigateur peut faire | Limitée aux outils exposés par le server |
| Vitesse par action | Millisecondes (pas d'inférence) | 0,5–3 secondes (le LLM décide chaque étape) |
| Gestion des erreurs | Votre code gère les erreurs | Le LLM raisonne sur les erreurs |
| Anti-détection | Non intégrée (dépend du navigateur) | Non intégrée (dépend du navigateur) |
| Idéal pour | Automatisation scriptée, contrôle fin, développement de frameworks | Navigation pilotée par LLM, tâches ouvertes, prototypage rapide |
Aucun des deux protocoles ne gère l'anti-détection. C'est un problème au niveau du navigateur, pas un problème de protocole. Une instance Chrome standard connectée via CDP ou via un MCP server expose les mêmes signaux d'automatisation. L'anti-détection nécessite une solution au niveau du moteur comme Clawbrowser : empreintes gérées sur plus de 20 surfaces, routage proxy intégré et suppression des signaux CDP au niveau du code source Chromium.
Quand utiliser CDP
Utilisez CDP quand vous avez besoin d'un contrôle précis et programmatique sur le navigateur et que vous connaissez les étapes exactes à l'avance.
Scénarios où CDP gagne :
- Scraping structuré. Vous savez quels sélecteurs cibler, quelles données extraire et comment gérer la pagination. Votre code exécute les mêmes étapes à chaque fois.
- Interception réseau. Vous devez bloquer des ressources, modifier des headers de requête, capturer des réponses d'API ou injecter du JavaScript avant le chargement de la page.
- Conditions d'attente complexes. Vous devez attendre des éléments DOM spécifiques, des états d'inactivité réseau ou des changements de variables JavaScript avant d'agir.
- Automatisation critique en performance. Les commandes CDP s'exécutent en millisecondes. Pas de délai d'inférence LLM par action. Un job de scraping de 50 étapes qui prend des secondes via CDP prendrait des minutes avec le raisonnement LLM à chaque étape.
- Développement de frameworks. Vous construisez un framework d'agents, un harnais de test ou une bibliothèque d'automatisation que d'autres utiliseront.
# CDP: full control, full responsibility
await page.wait_for_selector("#login-form")
await page.fill("#email", "[email protected]")
await page.fill("#password", credentials)
await page.click("#submit")Le compromis : vous écrivez et maintenez tout le code d'intégration navigateur. Chaque sélecteur, chaque condition d'attente, chaque gestionnaire d'erreurs. Quand la structure de la page change, votre code casse.
Quand utiliser MCP
Utilisez MCP quand le LLM doit décider quoi faire ensuite en fonction de ce qu'il voit sur la page.
Scénarios où MCP gagne :
- Navigation ouverte. « Trouve la page de tarifs et extrais les détails des plans. » L'agent navigue, lit la page et décide où cliquer sans sélecteurs codés en dur.
- Workflows multi-étapes avec jugement. « Connecte-toi, vérifie s'il y a une nouvelle facture, télécharge-la si le montant dépasse 500 $. » Le LLM gère la logique conditionnelle en lisant le contenu de la page à chaque étape.
- Prototypage rapide. Vous voulez un agent navigateur en cinq minutes sans écrire de code Playwright. Ajoutez la config MCP, décrivez la tâche, c'est fait.
- Utilisateurs non techniques. L'opérateur de l'agent décrit les tâches en langage naturel. Aucun code requis.
- Environnements natifs pour agents. Claude Code, Cursor et Gemini CLI parlent déjà MCP. Ajouter un navigateur se fait avec un seul bloc de configuration.
# MCP: the LLM decides what to do
User prompt: "Go to example.com and tell me the page title"
LLM calls: navigate(url="https://example.com")
LLM calls: screenshot()Le compromis : moins de précision. Le LLM peut cliquer sur le mauvais élément, faire des étapes supplémentaires ou mal lire le contenu de la page. Chaque action entraîne une latence d'inférence LLM. Vous ne pouvez pas intercepter les requêtes réseau ni injecter du JavaScript via les outils MCP navigateur standard.
Quand utiliser les deux ensemble
C'est là que la plupart des agents IA en production finissent. MCP gère l'interface LLM-vers-agent. CDP gère l'interface agent-vers-navigateur. Le MCP server se place entre les deux, traduisant les appels d'outils de haut niveau en commandes navigateur de bas niveau.
LLM ← MCP → MCP Server ← CDP → Browser
(clawctl) (Clawbrowser)Le LLM envoie des appels d'outils MCP (« navigue vers cette URL », « clique sur le bouton de connexion »). Le MCP server les traduit en commandes CDP et les envoie au navigateur. Les résultats remontent la chaîne.
Pourquoi la couche navigateur compte
La plupart des MCP servers navigateur se connectent à une instance Chrome standard via CDP. Le navigateur n'a pas de gestion d'empreinte, pas de routage proxy, pas d'anti-détection. Votre agent fonctionne sur les sites de démonstration mais se fait bloquer sur les sites de production derrière Cloudflare, DataDome ou Akamai.
Le MCP server intégré de Clawbrowser se connecte à son propre moteur Chromium. Quand le LLM appelle navigate, le MCP server envoie une commande CDP à un navigateur qui a déjà des empreintes gérées, un routage proxy géo-aligné et une suppression des signaux CDP au niveau du moteur. Pas de plugins stealth, pas de middleware proxy, pas de code de rotation d'empreintes.
Chemin MCP (piloté par LLM, zéro code d'intégration) :
{
"mcpServers": {
"clawbrowser": {
"command": "clawctl",
"args": ["mcp", "serve"]Chemin CDP (scripté, contrôle total) :
browser = await playwright.chromium.connect_over_cdp(
"http://127.0.0.1:9222"
)Les deux chemins se connectent à la même instance Clawbrowser avec les mêmes empreintes, le même routage proxy et la même anti-détection. Choisissez l'interface qui correspond à votre cas d'usage. Utilisez les deux dans le même projet quand différentes parties du workflow nécessitent différents niveaux de contrôle.
Pour un tutoriel pas à pas pour construire un agent avec les deux protocoles, voir Comment construire un agent IA qui navigue sur le web.
Framework de décision
| Question | CDP | MCP |
|---|---|---|
| Connaissez-vous les étapes exactes à l'avance ? | Oui | Utilisez CDP |
| Le LLM doit-il décider où cliquer ? | Utilisez MCP | Oui |
| Avez-vous besoin d'interception réseau ? | Oui | Non disponible |
| Avez-vous besoin d'une vitesse d'action inférieure à la seconde ? | Oui | Non (latence LLM) |
| Construisez-vous pour des non-développeurs ? | Non | Oui |
| Utilisez-vous Claude Code ou Cursor ? | Disponible | Intégration native |
| Voulez-vous zéro code navigateur ? | Non | Oui |
Si vous avez répondu « oui » des deux côtés, utilisez les deux : MCP pour les parties pilotées par LLM, CDP pour les parties de précision. Clawbrowser gère la couche navigateur pour l'un ou l'autre protocole.
FAQ
Puis-je passer de CDP à MCP sans changer de navigateur ?
Oui, si votre navigateur supporte les deux. Clawbrowser expose un endpoint CDP sur chaque profil et fournit un MCP server intégré. Connectez Playwright à l'endpoint CDP pour l'automatisation scriptée et utilisez le MCP server pour la navigation pilotée par LLM, le tout sur les mêmes profils navigateur avec les mêmes empreintes et sessions. Voir Comment connecter Cursor à un vrai navigateur via CDP pour un guide des deux méthodes de connexion.
Quel protocole est le plus rapide ?
CDP. Les commandes s'exécutent en millisecondes car aucune inférence LLM n'est impliquée. MCP ajoute 0,5–3 secondes par action car le LLM doit décider quel outil appeler et interpréter le résultat. Pour un job de scraping de 50 étapes, CDP termine en secondes. Le même job via MCP prend des minutes. Utilisez CDP pour l'automatisation en masse quand vous connaissez les étapes. Utilisez MCP pour les tâches qui nécessitent du jugement à chaque étape.
Qu'en est-il de WebDriver BiDi ?
WebDriver BiDi est un standard W3C qui vise à remplacer à la fois WebDriver (utilisé par Selenium) et des parties de CDP par un protocole agnostique au navigateur. Il est encore en cours de maturation. Playwright et Puppeteer utilisent toujours CDP en interne. Quand WebDriver BiDi atteindra une adoption complète, il concurrencera CDP au niveau de la couche contrôle navigateur, pas MCP au niveau de la couche tool-use. Le framework de décision CDP-vs-MCP de cet article s'applique indépendamment du protocole navigateur de bas niveau qui s'imposera.
Ai-je besoin d'un navigateur anti-detect pour l'un ou l'autre protocole ?
Oui, si votre agent automatise sur des sites avec protection anti-bot. Ni CDP ni MCP n'inclut d'anti-détection. Ce sont des protocoles pour envoyer des commandes à un navigateur. Si le navigateur expose des signaux d'automatisation (navigator.webdriver, User-Agent headless, hash canvas générique), le site le bloque quel que soit le protocole utilisé. Voir Automatisation navigateur sans se faire bloquer pour le modèle de détection complet.
Commencer à construire
Installez Clawbrowser depuis clawbrowser.ai en collant le prompt d'installation dans votre agent IA.
Chemin MCP (piloté par LLM) : ajoutez la configuration du MCP server Clawbrowser à votre agent et commencez à naviguer en langage naturel.
Chemin CDP (scripté) : connectez Playwright ou Puppeteer à l'endpoint CDP et écrivez votre code d'automatisation.
Les deux : utilisez MCP pour les parties où le LLM raisonne sur quoi faire. Utilisez CDP pour les parties où vous avez besoin d'un contrôle précis, rapide et déterministe. Même navigateur, mêmes empreintes, mêmes sessions.
Pour le guide CDP approfondi, lisez Navigateur CDP pour les agents d'IA : Guide du développeur. Pour un tutoriel complet, lisez Comment construire un agent IA qui navigue sur le web.
Continue exploring
Ask AI how Clawbrowser helps
Poursuivre la lecture
Articles associés
Navigateur CDP pour les agents d'IA: Guide du développeur
Chrome DevTools Protocol est la manière standard de contrôle des agents d'IA navigateurs. Chrome standard est détecté. Voici comment connecter votre agent à un navigateur CDP qui ne se bloque pas.
Lire l’article →
Pourquoi Clawbrowser est construit sur le Chromium
Clawbrowser est basé sur le Chromium parce que l'automatisation des agents d'IA a besoin de compatibilité CDP, un large support de cadre, et une surface d'empreinte digitale du navigateur qui correspond à la majorité du trafic web réel.
Lire l’article →