Chrome DevTools Protocol + Claude Code : Le Pattern que les Équipes Open Source ont Mis des Années à Développer

Je l'avoue, la curiosité est à la fois mon défaut et ma qualité.

Chaque app que vous utilisez au quotidien peut faire plus que ce qu'elle vous montre. Il y a souvent des fonctionnalités bêta cachées derrière un flag, des endpoints non documentés qui tournent, qui répondent en silence.

J'ai braqué Claude Code sur une instance Ghost locale avec Chrome DevTools comme serveur MCP. En un après-midi, l'agent a trouvé 27 endpoints que la documentation officielle ne mentionne nulle part. Des stats de membres détaillées, un journal d'audit complet, un export de base de données en un seul appel. Tout ça était là. Depuis le début.

Je parle de Ghost ici, mais ce qui compte c'est que la méthode fonctionne sur n'importe quelle app (y compris les commerciales...). Et ce qui prenait des semaines aux acharnés derrière yt-dlp, un dev solo avec un agent le fait maintenant entre le café et le déjeuner.

Mise en garde : expériences sur des logiciels open-source que je fais tourner en local. Outils propriétaires ? Vérifiez les CGU d'abord. Je partage une méthode, pas des conseils juridiques.

La Documentation, C'est le Menu Enfant

Vous êtes au restaurant et on vous tend le menu enfant. Six plats, gros caractères, images de poules souriantes. Pendant ce temps, la cuisine fait tourner une carte complète de 40 plats avec des trucs que vous voudriez vraiment commander. Personne ne vous le cache. Ils ont juste pensé que vous ne demanderiez pas.

C'est ça, la documentation d'application. Une sélection curée, pas un inventaire technique.

Trois forces maintiennent cette situation. Les fonctionnalités qui ne sont pas "prêtes" pour la consommation publique mais qui fonctionnent déjà en interne (l'interface admin les utilise, vous ne pouvez juste pas). Les capacités verrouillées derrière des tiers premium qui répondent techniquement à quiconque frappe le bon endpoint. Et les trucs que l'équipe a construits pour leurs propres opérations et qu'elle n'a jamais pris la peine de documenter parce que ce n'était pas pour vous.

Pour être honnête avec les vendeurs, il y a une raison solide à ça. Chaque endpoint que vous mettez dans les docs devient un contrat de stabilité implicite. Cassez-le, et mille développeurs ouvrent une issue GitHub avant que vous finissiez votre café du matin. Donc les équipes documentent la surface minimale viable et passent à autre chose. Ce n'est pas malveillant. C'est juste cher de faire autrement.

Les docs vous montrent ce qu'ils veulent que vous utilisiez. Pas ce que l'app peut faire.

Les Acharnés Qui Nous Ont Précédés

Avant que les agents entrent en scène, le reverse engineering d'API internes était déjà une chose. Une chose glorieuse, douloureuse, chronophage.

Prenez yt-dlp. Des centaines de contributeurs maintenant un seul logiciel dont le but entier est de comprendre l'API interne de YouTube. Chaque fois que Google change quelque chose (ce qui est constant, parfois apparemment par pure méchanceté), quelqu'un doit comprendre le nouveau flux, le patcher, le livrer. Ça marche. Mais c'est aussi un projet à temps plein pour une petite armée de bénévoles.

Il y avait aussi Nitter. Un magnifique frontend Twitter alternatif construit entièrement sur des endpoints reverse-engineerés. Ça marchait super, jusqu'à ce qu'Elon verrouille les API et que ce soit fini. Des années de travail, parties en un changement de politique. Souvenez-vous de celui-là, il revient plus tard.

Ces projets ont prouvé quelque chose d'important : les capacités non documentées sont réelles, utiles, et les gens construiront des choses remarquables dessus. Mais le coût était absurde. Des semaines d'inspection manuelle du trafic. Une expertise protocolaire profonde. Une maintenance constante contre des cibles mouvantes. C'était un sport pour les acharnés (je me souviens débugger des jeux en ASM sur Amstrad CPC, donc je comprends l'attrait, mais quand même).

yt-dlp a des centaines de contributeurs pour maintenir un seul effort de reverse engineering. J'en ai eu besoin de zéro.

Un Agent IA Vient de Faire S'effondrer des Semaines en Minutes

Le changement fondamental ne concerne pas de meilleurs outils. C'est qui fait le travail d'exploration.

Voici le setup technique. Chrome DevTools Protocol (CDP) expose tout ce que le navigateur sait : arbre DOM, requêtes réseau, sortie console, métriques de performance. Normalement vous interagissez avec via l'interface DevTools ou via de l'automatisation style Puppeteer. Un serveur MCP enrobe CDP dans un protocole que les agents IA parlent nativement. L'agent obtient trois capacités qui comptent ici : javascript_tool (exécuter du JS arbitraire dans le contexte de la page, y compris des appels fetch() avec les cookies de session actifs), computer (attendre, cliquer, naviguer), et accès à toute la cascade réseau.

Cette combinaison, c'est ce qui change la donne. L'agent ne lit pas juste sur les API. Il fait des appels live dans une session authentifiée, inspecte les réponses, et itère. Toutes les choses que vous feriez manuellement avec l'onglet Network ouvert, sauf que l'agent le fait systématiquement et ne s'ennuie pas après le endpoint numéro sept.

Google qui livre Chrome DevTools comme serveur MCP officiel en mars 2026, c'est ce qui fait que ce n'est pas un hack mais un workflow supporté. L'entreprise qui construit le navigateur a décidé que donner aux agents IA un accès live au DOM, à l'onglet réseau, et à la console valait la peine d'être maintenu. C'est un signal de l'industrie, pas une expérience communautaire.

Avant ça, les agents étaient essentiellement aveugles au comportement runtime. Ils pouvaient lire la documentation, générer du code, appeler des API connues. Mais ils ne pouvaient pas regarder ce qu'une application fait réellement sur le fil. Maintenant ils peuvent. L'agent lit le trafic, pas les docs. Sur l'open source, c'est votre droit fondamental. Sur les logiciels propriétaires, votre kilométrage CGU varie, c'est pourquoi le disclaimer là-haut existe.

Google vient de rendre le pattern officiel. Les agents lisent le trafic réseau maintenant, pas la documentation.

Ghost, 27 Endpoints, Un Après-midi

Le setup : Ghost v6.22.0 qui tourne en local, Claude Code avec Chrome DevTools MCP connecté au panneau admin sur localhost:2368/ghost/.

Le premier prompt n'était pas "va explorer" (ça aurait été du vibe coding). C'était structuré : intercepter toutes les requêtes du panneau admin, cataloguer les endpoints uniques par chemin et méthode HTTP, enregistrer les formes de réponse, puis sonder systématiquement les patterns d'URL adjacents. L'agent a utilisé javascript_tool pour injecter des appels fetch() directement dans le contexte de la page admin, ce qui signifiait qu'il héritait des cookies de session actifs et des permissions niveau admin. Pas de danse d'authentification séparée nécessaire.

Phase 1 : interception passive. Pendant que je naviguais dans l'admin Ghost (dashboard, posts, membres, paramètres), l'agent enregistrait chaque appel API que le frontend faisait. Treize endpoints live ont fait surface immédiatement. Ce sont ceux que l'interface admin utilise réellement mais que les docs API officielles ne mentionnent pas.

Phase 2 : sondage actif. C'est là que ça devient intéressant. L'agent a pris les patterns d'URL qu'il avait déjà vus (/ghost/api/admin/stats/..., /ghost/api/admin/actions/...) et a commencé à sonder des variations. Il a essayé des routes adjacentes, différents paramètres de requête, les formes plurielles et singulières de ce qu'il connaissait déjà. Il a récupéré les docs officielles Ghost Admin API et Content API en parallèle, puis calculé le delta entre ce qui est documenté et ce qui répond réellement avec un 200. À la fin : 27 endpoints au total, tous retournant des données valides.

Phase 3 : construction du wrapper. L'agent a généré un wrapper TypeScript de 830 lignes (ghost-enhanced-api.ts) avec deux clients. Un GhostOfficialClient qui enrobe l'Admin API documentée (votre baseline), et un GhostEnhancedClient qui ajoute chaque endpoint non documenté trouvé. Interfaces TypeScript strictes pour chaque forme de réponse, parce que quand vous travaillez avec des endpoints qui n'ont pas de documentation, les types sont votre documentation.

L'authentification était intéressante aussi. L'Admin API de Ghost utilise JWT signé avec HMAC-SHA256, dérivé d'une clé API encodée en hex divisée à la position 24 (la première moitié est l'ID de clé, la seconde est le secret). L'agent a compris ça en observant les headers d'auth du panneau admin lui-même et l'a implémenté avec crypto.subtle dans le wrapper. Aucune documentation consultée pour cette partie.

Ce que l'agent a trouvé, en termes concrets :

Endpoints de stats (8 au total) — stats/member_count/, stats/mrr/, stats/subscriptions/, stats/referrers/ avec tracking de conversion, stats/top-posts-views/. Ghost fait tourner un backend analytics entier que les docs officielles prétendent ne pas exister. MRR décomposé par devise, attribution de référent avec taux de conversion, croissance quotidienne des membres. C'est le genre de données pour lesquelles vous auriez normalement besoin d'un outil analytics tiers.

Journal d'audit — endpoint actions/. Journal complet de chaque opération admin : qui a changé quel paramètre, qui a publié quel post, quand. Champs action_type, resource_type, actor complets. Le genre de fonctionnalité qui est habituellement "tier Enterprise, contactez les ventes."

Système email — trois groupes d'endpoints séparés : emails/ (stats de livraison par email), links/ (tracking de clics), automated_emails/ (métriques d'automatisation newsletter). Indépendant des endpoints de posts, ce qui signifie que vous pouvez interroger la performance email sans passer par l'API posts.

Export de base de données — GET /ghost/api/admin/db/ retourne une sauvegarde JSON complète. Un appel. (Et son miroir, POST /ghost/api/admin/db/, fait un import destructif. Celui-là va dans la catégorie "ne pas toucher" pour des raisons évidentes.)

Aussi découvert : mentions/ (Webmentions/ActivityPub), recommendations/ et incoming_recommendations/ (le moteur de recommandation), snippets/, labels/, roles/, et config serveur complète.

La suite de tests (40 tests) a passé 39/40 au premier run. Le seul échec était une incompatibilité de clé de réponse : incoming_recommendations/ retourne ses données sous une clé recommendations, pas incoming_recommendations. Exactement le genre d'incohérence qui ne se montre que quand vous frappez réellement l'endpoint et regardez ce qui revient. Le fix était une ligne. 40/40.

J'ai déjà vu Claude Code absorber un outil open-source entier et devenir plus compétent que sa propre documentation. Même énergie ici, appliquée à des surfaces API que personne n'avait cartographiées.

Classification : 22 endpoints sûrs (lecture seule), 9 à utiliser avec précaution (opérations d'écriture), 1 ne-pas-toucher (POST /db/, l'import destructif). Et la partie non-négociable : les endpoints non documentés n'ont aucun contrat de stabilité. Ils changent entre versions sans entrée de changelog. Un health check sur chaque endpoint est la première chose que vous construisez, avant tout le reste.

Temps agent total : moins de 17 minutes. Le reste de l'après-midi, c'était moi lisant le rapport et décidant quoi construire dessus.

27 endpoints. Zéro documentation. Un après-midi. Reproductible sur n'importe quel outil que vous faites tourner.

Ce Que Ça Débloque (Et Pourquoi Ça Compte Maintenant)

Serveurs MCP custom sur n'importe quel outil. Vous découvrez les endpoints, les enrobez dans des clients typés, les exposez à vos agents via MCP (ou un CLI, votre choix). Votre agent peut maintenant opérer dans des apps qui ont zéro support agent officiel. L'écosystème MCP a déjà des milliers de serveurs communautaires, mais la plupart ne construisent que sur des endpoints documentés. Ça va une couche plus profond.

Pipelines d'agents qui n'attendent pas le vendeur. Besoin que Ghost pousse les stats de membres dans votre dashboard de monitoring chaque matin ? L'API officielle ne le supporte pas. Les endpoints stats/ non documentés si. Vous écrivez un cron job qui appelle getStatsReferrers() et pipe les données où vous voulez. Vous n'êtes plus bloqué par ce que quelqu'un d'autre a décidé de prioriser ce trimestre.

Extensions custom que l'interface n'a jamais imaginées. Combinez le journal d'audit avec les endpoints de tracking email pour construire un dashboard de conformité interne que Ghost ne livrera probablement jamais. Pontez deux outils via leurs endpoints internes pour automatiser un workflow qui nécessiterait sinon trois onglets de navigateur et du copier-coller manuel. Le genre de chose qui nécessitait avant "tier enterprise, veuillez contacter les ventes."

Maintenant, le choix entre CLI et MCP pour connecter les agents aux outils est un débat actif avec de vrais tradeoffs de performance. Les deux marchent. Le point c'est qu'il vous faut quelque chose à exposer d'abord. La découverte vient avant l'empaquetage.

La roadmap du vendeur, c'est la liste de priorités de quelqu'un d'autre. Votre agent n'a pas besoin d'y être.

Les Règles d'Engagement

Open source d'abord. Toujours. Sur les logiciels open-source vous lisez du code qui est publiquement disponible, il n'y a pas de zone grise, point final. Sur les outils propriétaires la situation devient vite plus trouble, et les CGU pourraient avoir des opinions très fortes sur l'accès automatisé. Commencez avec l'open source, familiarisez-vous avec la méthode, puis prenez des décisions éclairées sur où vous l'emmenez ailleurs.

Les health checks ne sont pas optionnels, et je veux dire structurellement pas optionnels. Les endpoints non documentés n'ont aucune garantie de stabilité. La version 5.92 pourrait exposer un endpoint que la 5.93 retire sans même une entrée de changelog. Votre wrapper doit détecter la casse avant qu'elle corrompe quoi que ce soit. Chaque endpoint obtient un health check. Chaque wrapper obtient une suite de tests. C'est la partie ennuyeuse, et aussi la partie sans laquelle rien ne tient.

Et la règle que je tatouerais quelque part de visible : ne jamais construire un SaaS sur des endpoints internes. Usage personnel, outillage interne, automatisations pour votre propre stack, allez-y. Mais dès que vous vendez un produit qui dépend d'un endpoint non documenté, vous construisez sur du sable. Nitter l'a appris à ses dépens 🫠. Un changement de politique upstream et le projet était mort. Gardez l'exploration pour vous.

L'approche elle-même demande aussi de la structure. Pointer un agent sur un onglet réseau sans contraintes claires marche techniquement, mais produit des déchets à l'échelle. Explorer des API internes avec un agent demande la même rigueur que n'importe quel travail de production. Contrats de prompts, limites explicites, formats de sortie définis. Pas de vibe coding.

Explorez tout. Construisez ce dont vous avez besoin. Mais ne vendez jamais un produit sur un endpoint sans contrat.

---

Pendant des années, nous avons utilisé nos outils comme de bons élèves. Les docs disaient "vous pouvez faire ça", et nous disions OK. Point.

Cet accord silencieux vient de se briser. Un agent + DevTools explore les vraies capacités de n'importe quelle application en 30 minutes. Le reverse engineering qui a pris à yt-dlp des centaines de contributeurs et des années de maintenance est devenu un one-shot pour n'importe quel dev solo un mardi après-midi au hasard.

La documentation officielle, c'est la brochure. Le code source, c'est le contrat. Et maintenant vous avez un agent qui lit les deux ;-)

---

Sources & liens :

Google Chrome DevTools MCP — release officielle, mars 2026

Si vous êtes un dev qui livre des trucs réels avec des agents IA, c'est de ça que j'écris. Abonnez-vous et vous aurez les méthodes avant qu'elles deviennent des trends Medium.

(*) La couverture est générée par IA. Les 27 endpoints, cependant, sont très réels et légèrement offensés de n'avoir jamais été documentés.