Automatiser les workflows de navigateur reproductibles avec la CLI Outils pour les développeurs Chrome

José Luis Zapata
Matthias Rohmer

Les outils de développement Chrome pour les agents incluent une interface de ligne de commande (CLI) qui vous permet, à vous ou à votre agent de codage, d'exécuter les outils de développement en tant que commandes shell standards. Au lieu d'appeler des outils de manière dynamique via le serveur MCP, votre agent écrit les mêmes actions que les commandes shell et peut les enchaîner dans un script que vous pouvez réexécuter à tout moment. Par exemple, votre agent peut générer un script comme celui-ci :

chrome-devtools new_page "https://example.com"
chrome-devtools take_snapshot 1
chrome-devtools fill 1 "1_4" "hello"

Le serveur MCP et la CLI se connectent au même moteur : un daemon d'arrière-plan persistant qui communique avec Chrome via le protocole Chrome DevTools (CDP). La différence réside dans la manière dont votre agent accède à ce moteur :

  • Serveur MCP : votre agent se connecte via l'entrée/la sortie standard à l'aide de JSON-RPC et traite chaque outil de navigateur comme un appel de fonction interactif.
  • CLI : votre agent exécute des commandes shell directement sur le même daemon en arrière-plan.

Vous pouvez utiliser la CLI pour effectuer les opérations suivantes :

  • Conserver un workflow : transformez les actions effectuées par votre agent lors d'une session de débogage exploratoire en un script réutilisable.
  • Reproduire l'état d'une application : réexécutez un script pour ramener le navigateur à un état connu avant de relancer le débogage.
  • Actions par lot : exécutez une séquence de commandes de navigation, de saisie, d'émulation et d'inspection sans tour de conversation entre chaque étape.
  • Exécuter des scripts sans agent IA : exécutez les scripts générés à partir de n'importe quel terminal, sous-shell ou conteneur d'intégration continue pouvant exécuter des scripts shell, sans avoir besoin d'une session LLM active ni d'un client MCP.

Choisir entre la CLI et le serveur MCP

Le choix entre la CLI et le serveur MCP est une décision d'ingénierie qui dépend du coût, du contexte et du workflow.

  • Coût de la fenêtre de contexte : lorsque vous enregistrez le serveur MCP, chaque définition d'outil et schéma JSON est injecté dans l'invite système de votre LLM dans chaque conversation. Avec la compétence CLI, votre agent ne charge qu'un résumé Markdown compact et ne paie le coût des jetons que lorsqu'il décide de lire l'intégralité de la compétence et de construire les commandes dont il a besoin. Pour les sessions d'agent longues et multitours, cette différence s'ajoute au coût et à la latence.
  • Exploration ou exécution : les outils MCP sont parfaits pour le débogage dynamique et exploratoire, lorsque ni vous ni votre agent ne savez encore ce que vous devez inspecter. Comme votre agent connaît tous les outils disponibles à l'avance, il est plus susceptible de les utiliser pour atteindre son objectif. Lorsque le chemin d'accès est déjà connu, la CLI vous permet de n'exécuter que les étapes dont vous avez besoin.
  • Réutilisabilité : vous pouvez enregistrer un script CLI, le réutiliser dans une compétence ou l'exécuter manuellement en dehors d'une boucle d'agent. Vous ne pouvez pas le faire avec les appels d'outils MCP.
Utiliser le serveur MCP lorsque Utilisez la CLI dans les cas suivants :
Vous enquêtez sur un problème inconnu et avez besoin de l'ensemble des outils disponibles. Vous connaissez déjà les étapes et souhaitez les répéter de manière fiable.
Vous souhaitez résoudre les problèmes de manière dynamique et en direct, et bénéficier d'une introspection approfondie du navigateur. Vous souhaitez des compétences d'agent efficaces en termes de jetons ou une automatisation basée sur un terminal.
Votre agent s'exécute dans un IDE ou un client compatible avec MCP. Votre environnement n'est pas compatible avec les clients MCP.

Lorsque vous utilisez la CLI, tenez compte des points suivants :

  • Couverture des outils : la CLI est compatible avec la plupart des outils des Outils de développement Chrome pour les agents pour l'automatisation basée sur l'interface système. Pour obtenir la liste complète des commandes, consultez la documentation de référence sur les compétences de la CLI.
  • Démarrage implicite : le serveur d'arrière-plan démarre automatiquement lors de la première utilisation. Vous n'avez pas besoin d'exécuter start, status ou stop avant chaque commande.
  • État persistant : l'état du navigateur persiste d'une commande à l'autre. Ainsi, une page que vous ouvrez dans une commande est toujours disponible dans la suivante si elle n'est pas explicitement fermée.
  • ID de page et UID d'élément : la plupart des commandes utilisent un ID de page comme premier argument. Exécutez chrome-devtools list_pages pour le trouver et chrome-devtools take_snapshot pour obtenir les UID des éléments avec lesquels vous souhaitez interagir.
  • Format de sortie : par défaut, la sortie est au format texte brut de type Markdown. Transmettez --output-format=json si vous souhaitez utiliser les résultats dans d'autres scripts ou pipelines d'intégration continue.
  • Accès aux fichiers : par défaut, la CLI dispose d'un accès complet au système de fichiers pour les paramètres d'enregistrement des fichiers et upload_file. Transmettez --allowUnrestrictedPaths=false pour limiter l'accès aux fichiers au répertoire temporaire de l'OS.
  • Lighthouse dans l'intégration continue : vous pouvez exécuter lighthouse_audit à partir de la CLI, mais la CLI Lighthouse autonome et ses actions GitHub sont plus légères si vous n'avez besoin que des scores Lighthouse dans l'intégration continue.
  • Abstraction plus simple que les scripts d'automatisation du navigateur : contrairement à l'écriture de scripts Puppeteer ou Playwright complets en JavaScript ou TypeScript, la CLI DevTools fournit une surface d'API limitée et très ciblée. Cette syntaxe de shell est plus facile à lire et à gérer pour les humains, et nettement plus facile à générer de manière fiable et sans hallucinations, même pour les modèles de niveau inférieur.

Prérequis

Avant d'utiliser la CLI, assurez-vous de disposer des éléments suivants :

  • Outils de développement Chrome pour les agents installés : suivez le guide de démarrage. Les plug-ins et extensions spécifiques à l'agent (par exemple, l'extension Gemini CLI) incluent les compétences agentiques en plus du serveur MCP.
  • La CLI disponible dans votre shell : l'installation est une étape unique et ne fait pas partie du workflow standard de l'agent. Consultez la documentation de référence sur l'installation.
  • La compétence chrome-devtools-cli (installée avec les outils de développement Chrome pour les agents) : cette compétence apprend à votre agent à écrire des scripts shell ou à exécuter des commandes shell avec la CLI.

Structure de la commande

Les commandes suivent le modèle chrome-devtools <tool> [arguments] [flags]. Les arguments obligatoires sont positionnels, et les arguments facultatifs utilisent des options. Utilisez --help sur n'importe quelle commande pour obtenir des détails.

Exemple :

chrome-devtools new_page "https://example.com"      # Open a page
chrome-devtools list_pages                          # Find the page ID
chrome-devtools take_snapshot 1                     # Get element UIDs for page 1
chrome-devtools fill 1 "1_4" "hello"                # Fill an input
chrome-devtools click 1 "1_7" --includeSnapshot true
chrome-devtools list_console_messages 1 --types error
chrome-devtools take_screenshot 1 --filePath "result.png"

Cas d'utilisation de la CLI des outils pour les développeurs Chrome

Demandez à votre agent de capturer les étapes qu'il a déjà identifiées sous forme de script, au lieu de résoudre à nouveau le même flux de navigateur à chaque session.

Conserver une session de débogage en tant que script réutilisable

Après une session de débogage exploratoire via MCP, vous ne pouvez souvent pas garantir que le même problème ne se reproduira pas. Plutôt que de réexpliquer les étapes de reproduction la prochaine fois, demandez à votre agent de noter le flux qu'il vient d'exécuter.

Exemple de prompt :

Please write a chrome-devtools CLI script for this user flow, and save it as test.sh.

Exemple d'exécution de l'agent : votre agent examine les étapes de navigation, de saisie et d'inspection qu'il a effectuées au cours de la session et les traduit en une séquence de commandes chrome-devtools, par exemple new_page, take_snapshot, fill, click et list_console_messages. Il enregistre le script sous le nom test.sh. La prochaine fois que vous déboguerez cette zone, vous pourrez pointer votre agent vers le script pour atteindre à nouveau le même état, ou l'exécuter en dehors d'une boucle d'agent pour déboguer manuellement.

Reproduire l'état d'une application avant d'enquêter

Les états complexes, tels qu'un paiement en plusieurs étapes ou un tableau de bord filtré, sont coûteux à reconstruire de manière conversationnelle à chaque fois pour un agent. Utilisez un script enregistré comme point de départ d'une nouvelle investigation.

Exemple de prompt :

Run ./scripts/checkout-flow.sh to get the browser into the payment step, then check why the "Pay now" button stays disabled after I select Google Pay.

Exemple d'exécution de l'agent : votre agent exécute le script, qui accède au paiement, remplit le formulaire d'adresse et sélectionne une option de livraison. Étant donné que l'état du navigateur persiste entre les commandes, votre agent utilise ensuite take_snapshot et evaluate_script sur la même page pour inspecter l'état du bouton et les gestionnaires d'événements associés au sélecteur de paiement.

Vérifications visuelles par lot dans les fenêtres d'affichage

La vérification d'un changement de mise en page sur plusieurs tailles d'écran est répétitive et s'effectue généralement manuellement. Demandez à votre agent un script qui applique les paramètres d'émulation et capture des preuves pour chacun d'eux en une seule exécution.

Exemple de prompt :

Write a chrome-devtools CLI script that opens http://localhost:3000/pricing, captures a full-page screenshot at 375x667, 768x1024, and 1920x1080, and saves them to ./screenshots with the viewport size in the filename.

Exemple d'exécution de l'agent : votre agent écrit une boucle qui appelle chrome-devtools emulate 1 --viewport "<size>", puis chrome-devtools take_screenshot 1 --fullPage true --filePath "./screenshots/pricing-<size>.png" pour chaque fenêtre d'affichage. Vous pouvez réexécuter le script après chaque modification du CSS sans ouvrir de conversation.

Effectuer un test de détection de fumée sur un flux où aucun client MCP n'est disponible

Certains environnements, tels que les conteneurs d'intégration continue ou les configurations d'entreprise verrouillées, ne sont pas compatibles avec les clients MCP. Pratiquement tous les terminaux, sous-shells, conteneurs d'intégration continue et frameworks d'agents sont compatibles avec l'exécution de scripts shell standards et la lecture de stdout, ce qui rend la CLI adaptée aux vérifications légères dans ces emplacements.

Exemple de prompt :

Create a shell script that opens the sign-up page on the staging URL passed as the first argument, submits the form with test data, and exits with a non-zero code if any console errors are logged. Use --output-format=json so the script can parse the result.

Exemple d'exécution de l'agent : votre agent écrit un script qui utilise new_page, take_snapshot, fill et click, puis appelle list_console_messages 1 --types error --output-format=json et analyse la sortie JSON pour décider du code de sortie.

Empaqueter un workflow en tant que compétence légère

Si un flux est utile à plusieurs projets ou coéquipiers, votre agent peut encapsuler le script dans une compétence. C'est la compétence CLI DevTools : une référence légère qui permet à votre agent d'exécuter des commandes de navigateur spécifiques sans payer le coût initial du jeton pour tous les outils.

Exemple de prompt :

Turn ./scripts/checkout-flow.sh into a skill named "reproduce-checkout" with a short description of when to use it, so I can invoke it in future sessions.

Exemple d'exécution d'agent : votre agent crée un SKILL.md avec un nom, une description d'une ligne indiquant quand la compétence s'applique et des instructions qui font référence au script. Lors des sessions ultérieures, l'agent ne lit la compétence complète que lorsque la tâche correspond à sa description.

Étapes suivantes