Claude Code dans Android Studio : comprendre le rôle d’ACP

Vous pouvez changer d’agent de codage sans changer d’éditeur, à condition que les deux prennent en charge Agent Client Protocol (ACP). Pour qui s’intéresse à Claude Code dans Android Studio, la version Rabbit 2 de Google rend ce choix concret : son annonce d’octobre cite plus de 40 agents de codage, sélectionnables directement dans l’IDE. L’intérêt est de conserver son environnement de développement tout en choisissant l’agent qui effectuera le travail.

Ce chiffre vient de l’annonce de Google du 28 octobre 2026 consacrée à Android Studio. Les informations sur la prise en charge et la configuration présentées ci-dessous ont été vérifiées dans la documentation du protocole et des éditeurs le 3 novembre 2026. Ce guide repose sur ces sources documentaires ; il ne s’agit pas d’un comparatif d’agents testés en conditions réelles.

Ce qu’Agent Client Protocol change pour les développeurs

ACP fournit aux éditeurs et aux agents de codage une interface commune pour les prompts, le suivi du travail, les autorisations et les résultats. Un agent est un programme qui s’appuie sur un modèle, des outils et une boucle d’exécution pour mener une tâche à bien. L’éditeur, ou environnement de développement intégré (IDE), est l’endroit où vous examinez le code, vérifiez les modifications et échangez avec ce programme.

Le parallèle avec Language Server Protocol (LSP) aide à comprendre le principe. LSP a standardisé la connexion entre les éditeurs et les serveurs de langage, qui fournissent des fonctions propres à chaque langage, comme les diagnostics. ACP applique cette même séparation aux agents de codage : l’éditeur implémente la connexion côté client, et l’agent prend en charge ACP directement ou par l’intermédiaire d’un adaptateur. Les deux côtés doivent être compatibles. L’introduction à ACP présente cette approche comme un moyen d’éviter de créer une intégration sur mesure pour chaque combinaison.

Pour un développeur qui alterne entre Claude Code d’Anthropic, Codex d’OpenAI et Gemini CLI de Google, le bénéfice est de garder un cadre de travail stable. Il devient possible d’évaluer un autre agent sans inclure le changement d’éditeur dans la migration. Les modalités d’intégration à ACP restent toutefois différentes, comme le montre l’état de la prise en charge ci-dessous.

Qui est à l’origine d’ACP ?

Zed Industries a créé ACP, en travaillant avec Google pour faire de Gemini CLI la première implémentation de référence. Zed a annoncé cette collaboration le 27 août 2025. JetBrains a ensuite rejoint le projet ; sa page actuelle consacrée à ACP présente le protocole comme développé de façon ouverte par JetBrains et Zed. Google est un partenaire des premières implémentations et l’a adopté dans Android Studio. Le billet de lancement de Zed et la page ACP de JetBrains permettent de distinguer ces rôles.

Cette distinction compte pour évaluer la prise en charge. Créer le protocole, maintenir un adaptateur et intégrer un client dans un éditeur sont des contributions différentes.

Quels éditeurs et agents prennent en charge ACP ?

Zed, les IDE JetBrains et Android Studio proposent des intégrations documentées avec les agents ACP. D’autres éditeurs passent par des plugins ou des extensions : vérifiez donc l’intégration que vous comptez réellement installer. La présence dans un annuaire atteste l’existence d’une intégration, sans garantir un comportement identique pour toutes les fonctions.

Les noms des plugins ci-dessus reprennent ceux de l’annuaire des clients ACP. Les précisions sur Zed, JetBrains et Android Studio viennent de leurs documentations respectives, citées ci-dessous. Cette sélection concerne les workflows de développement ; elle ne recense pas tous les clients ACP.

Zed : les agents externes gardent leur propre configuration

Zed donne accès aux agents ACP dans son Agent Panel et sa Threads Sidebar. Sa documentation actuelle cite Claude, Codex, OpenCode, Copilot, Cursor et Pi parmi les agents externes courants, et fournit aussi des instructions de configuration pour Gemini CLI. L’installation passe principalement par l’ACP Registry. La documentation de Zed sur les agents externes explique l’installation et précise quelle configuration relève de chaque composant.

La limite pratique concerne la transmission des paramètres. Les profils de Zed Agent et Zed Skills ne deviennent pas automatiquement les réglages de l’agent externe. Dans la documentation de votre équipe, consignez donc les instructions, les identifiants et les outils propres à cet agent.

JetBrains : vérifier les règles de l’organisation et l’environnement

JetBrains AI Assistant donne accès aux agents ACP dans AI Chat. Vous pouvez installer un agent depuis Settings > Tools > AI Assistant > Agents, ou ajouter un agent personnalisé avec acp.json. La documentation indique également que les agents ACP ne sont actuellement pas pris en charge dans Windows Subsystem for Linux (WSL) et que les administrateurs peuvent limiter les entrées du registre ou les agents personnalisés. La documentation ACP de JetBrains fait référence pour ces contraintes.

Pour un responsable d’équipe de développement, il faut donc vérifier l’environnement des postes avant de recommander cette intégration. Un fonctionnement correct sur le portable d’un collègue ne prouve pas que votre workflow WSL administré est pris en charge.

Agents : distinguer prise en charge native et adaptateur

L’annuaire des agents ACP décrit précisément les intégrations concernées :

• Claude Agent y figure via l’adaptateur SDK de Zed. C’est le nom retenu par l’annuaire pour l’intégration de Claude ; cela ne signifie pas que le CLI Claude Code prend lui-même ACP en charge nativement.
• Codex CLI y figure via l’adaptateur d’ACP. Incluez cet adaptateur dans l’inventaire des composants lancés par votre éditeur.
• Gemini CLI est présenté comme un agent implémentant le protocole, sans mention d’adaptateur.
• GitHub Copilot est explicitement signalé comme étant en préversion publique sur cette page.

La même page répertorie aussi Augment Code, Cline, Cursor, cagent de Docker, Factory Droid, Goose, Hermes Agent, Junie de JetBrains, Kimi CLI, Kiro CLI, Mistral Vibe, OpenCode, OpenHands et Qwen Code. Pi y figure via un adaptateur pi-acp. Cette sélection reprend les noms employés par l’annuaire ; la liste complète se trouve sur la page liée.

N’interprétez pas cet annuaire comme une garantie de compatibilité avec tous les éditeurs. La combinaison utilisable dépend de l’agent, de son éventuel adaptateur, de l’intégration dans votre éditeur et des capacités négociées entre eux.

Android Studio : ce que permet Bring Your Own Agent

Android Studio permet de choisir l’agent de codage tout en conservant ses outils de développement Android. L’annonce de la version stable de Google cite Claude Agent, Codex, Junie et Google Antigravity, et précise que les agents peuvent accéder à Android Emulator, aux systèmes de build, à Logcat et aux skills Android. Logcat est l’outil de consultation des journaux des applications et du système Android. L’annonce de Google sur Rabbit 2 documente cet accès aux outils.

Prenons le cas d’un développeur Android qui cherche la cause d’un plantage : il souhaite que l’agent travaille avec les outils de build et de diagnostic du projet, tout en gardant son environnement habituel pour examiner le correctif. BYOA permet de dissocier le choix de l’agent de cet espace de travail. La qualité du diagnostic fourni par l’agent choisi reste à évaluer.

Pour un responsable d’équipe, cela permet de mener un essai pilote plus pertinent. Gardez le même dépôt, la même tâche et le même processus de revue, puis comparez les agents approuvés dans cet environnement. Évaluez le correctif produit, les commandes demandées et les éléments qui étayent la réponse. Réussir la connexion ne suffit pas à réussir le déploiement.

D’abord en préversion, désormais en version stable

Google a présenté BYOA en préversion le 24 septembre 2026, à partir d’Android Studio Rabbit 2 Canary. Le 28 octobre 2026, l’entreprise a annoncé la version stable de Rabbit 2, avec BYOA. Cette annonce plus récente remplace le statut de préversion indiqué au lancement. Annonce de la préversion, annonce de la version stable.

Associez toujours la mention de préversion au composant concerné. La version stable d’Android Studio ne met pas fin à la préversion publique d’un autre agent et ne garantit pas qu’un adaptateur offre toutes les mêmes fonctions.

Comment se déroule une session ACP ?

L’éditeur démarre l’agent et échange avec lui des messages structurés. Avec le transport local, l’éditeur lance un sous-processus, c’est-à-dire un autre programme exécuté par le système d’exploitation. La connexion utilise JSON-RPC 2.0, un format de requêtes, de réponses et de notifications, sur stdio, les flux d’entrée et de sortie standard du processus. Il s’agit donc d’une communication structurée, et non d’une lecture du texte affiché dans un terminal. Vue d’ensemble du protocole, spécification des transports.

La session suit une séquence précise :

1. Démarrage et négociation. L’éditeur lance l’agent ou l’adaptateur et envoie initialize. Les deux parties échangent leurs versions du protocole et leurs capacités.
2. Authentification si nécessaire. L’utilisateur suit la méthode d’authentification annoncée par l’agent. Une connexion réussie avec l’éditeur ne fournit pas de compte pour l’agent.
3. Ouverture de la conversation. L’éditeur envoie session/new avec le répertoire de travail et les éventuels serveurs MCP qu’il met à disposition. L’agent renvoie un identifiant de session.
4. Envoi de la tâche et suivi de l’avancement. L’éditeur envoie session/prompt ; l’agent transmet ses messages et l’activité des outils via des notifications session/update.
5. Traitement des actions demandées. Lorsque l’agent demande une autorisation, l’éditeur présente les choix disponibles et lui renvoie la décision. Le tour se termine par une réponse indiquant la raison de l’arrêt.

Cette séquence correspond au flux de messages et aux règles de création d’une session documentés. Une session est une conversation de l’agent avec son propre contexte et son propre état ; ce n’est pas un fichier de conversation universel partagé par tous les fournisseurs.

Modification des fichiers et commandes du terminal

L’accès aux fichiers et au terminal fait partie des capacités négociées. Lorsqu’elles sont prises en charge, l’agent peut utiliser fs/read_text_file pour lire un fichier par l’intermédiaire de l’éditeur, y compris ses modifications non enregistrées, et fs/write_text_file pour y écrire. Ce point compte lorsque le contenu affiché à l’écran diffère du fichier enregistré sur disque. Spécification du système de fichiers ACP.

Pour les commandes, terminal/create demande au client de démarrer un processus. Les méthodes associées permettent de récupérer la sortie, d’attendre la fin de l’exécution, d’arrêter la commande et de libérer le terminal. L’agent doit vérifier que le client a annoncé la prise en charge du terminal avant d’utiliser ces méthodes. Spécification des terminaux ACP.

Un agent peut aussi signaler des modifications sous forme de diffs et transmettre l’avancement des outils via ACP tout en effectuant lui-même ses opérations. Voir l’activité dans l’éditeur ne signifie donc pas que celui-ci a exécuté chaque opération. Spécification des appels d’outils.

ACP vs MCP : quel protocole relie quoi ?

ACP relie l’éditeur à l’agent ; Model Context Protocol (MCP) relie une application ou un agent d’IA à des outils et à des données. Les deux peuvent fonctionner ensemble dans une même session. Cette comparaison s’appuie sur la spécification des sessions ACP et l’introduction à MCP.

Lorsqu’un outil manque, examinez sa connexion en plus de celle de l’éditeur. JetBrains propose par exemple des réglages distincts pour transmettre aux agents les serveurs MCP personnalisés et son serveur IntelliJ MCP intégré. La seule prise en charge d’ACP n’active pas tous les outils. Les paramètres du registre de JetBrains documentent ces réglages.

Si vous concevez l’interface du service sous-jacent, l’article MCP vs API traite d’une autre décision : comment exposer les fonctionnalités d’une application. Si vous construisez une application autour d’agents de codage, le guide de l’adaptateur ACP du Vercel AI SDK explique cette couche d’intégration.

Claude Code dans Android Studio : connecter Claude Agent

Passez par le sélecteur d’agents d’Android Studio, puis authentifiez-vous auprès du fournisseur de l’agent. Le parcours actuel de Google passe par la fenêtre des agents ou par Settings > Tools > AI > Agents. Les instructions de lancement prévoient une connexion au compte ou la saisie d’une clé API ; les offres de compte compatibles dépendent du fournisseur. Parcours de configuration actuel, instructions d’authentification.

1. 1

   Utiliser une version qui inclut BYOA

   Utilisez Android Studio Rabbit 2 stable ou une version ultérieure dont la documentation mentionne BYOA. L’instruction initiale qui imposait Canary correspondait au lancement en préversion.

2. 2

   Sélectionner Claude Agent

   Ouvrez la fenêtre des agents et sélectionnez Claude Agent. Vous pouvez aussi choisir les agents dans Settings > Tools > AI > Agents.

3. 3

   S’authentifier auprès de cet agent

   Suivez le parcours de connexion de l’agent ou fournissez une clé API si cette option est proposée. Utilisez le compte et le mode d’accès approuvés pour votre projet. Connecter un autre agent exige une authentification et des droits d’accès propres à cet agent.

4. 4

   Commencer par un prompt au périmètre précis

   La configuration décrite par Google se termine par l’envoi d’un prompt. Pour commencer, vous pouvez demander : « Explique comment ce projet est compilé et identifie la tâche de test pertinente. Ne modifie aucun fichier. » Ce prompt est une suggestion de départ, pas le résultat d’un test réalisé par le fournisseur.

5. 5

   Vérifier le workflow avant d’élargir le périmètre

   Demandez ensuite une petite modification facile à vérifier, sur une branche de travail. Examinez la modification proposée, les choix d’autorisation et toute commande demandée. Assurez-vous de comprendre le résultat avant de confier une tâche plus importante. Ce conseil de déploiement va au-delà des étapes de connexion du fournisseur.

Si l’authentification échoue, corrigez la configuration du compte ou de la clé de l’agent sélectionné. Si l’agent se connecte mais ne peut pas utiliser un outil, examinez les capacités exposées par cette intégration. Ces pannes surviennent à des endroits différents : distinguez-les dans vos notes de configuration.

Les limites à prendre en compte en équipe

Standardisez la connexion, puis vérifiez le comportement de chaque agent. Le protocole évite de refaire les mêmes intégrations, sans rendre les agents interchangeables dans tous les détails de leur fonctionnement.

Chaque agent conserve sa propre authentification. Prévoyez une connexion ou une clé API distincte pour chaque fournisseur retenu. Une implémentation peut réutiliser des identifiants existants, mais ACP ne constitue ni un compte partagé ni une réserve commune de quotas. Zed documente par exemple l’authentification des agents externes et leurs relations propres avec les fournisseurs. Périmètre de configuration dans Zed.

La reprise d’une session dépend de la prise en charge. L’opération session/load du protocole exige que l’agent dispose de la capacité loadSession. Elle permet de charger une session existante lorsque cette fonction est implémentée ; elle ne garantit pas qu’un autre fournisseur puisse récupérer l’état privé de l’agent d’origine. Avant de promettre un changement d’agent sans friction, vérifiez précisément le traitement de l’historique dans la combinaison retenue. Spécification du chargement des sessions.

L’utilisation à distance doit être vérifiée pour chaque implémentation. La page actuelle sur les transports définit stdio et indique qu’un transport Streamable HTTP est en cours de spécification. Les transports personnalisés sont autorisés. Ne supposez pas qu’une intégration locale fonctionnelle peut automatiquement se connecter à un agent distant. Spécification des transports ACP.

Une demande d’autorisation n’est pas un bac à sable

ACP définit le format des messages de décision d’autorisation ; il n’impose pas de cloisonnement au niveau du système d’exploitation. La spécification indique que l’agent s’exécute avec les permissions de son processus, que les demandes d’autorisation ont une valeur consultative et que l’agent est responsable du respect des décisions. De son côté, le client exécute les méthodes de système de fichiers et de terminal demandées au titre de ses propres capacités. Considérations de sécurité d’ACP.

Une demande peut proposer d’autoriser ou de refuser une action ponctuellement, ou de mémoriser la décision. L’agent définit la portée et la durée de conservation des décisions mémorisées. Lisez l’option proposée avant de supposer que « toujours » ne concerne que la commande ou le répertoire en cours. Sémantique des options d’autorisation.

Pour un responsable de plateforme, il faut vérifier le binaire de l’agent, l’environnement d’exécution et la politique d’autorisation en parallèle de la configuration de l’éditeur. Une boîte de dialogue d’approbation apporte de la visibilité, mais sa présence ne suffit pas à établir que l’exécution est isolée.

Quelles promesses relativiser, et qui a intérêt à s’y mettre ?

Le bénéfice crédible est une moindre dépendance entre l’éditeur et l’agent. La prise en charge d’ACP ne prouve pas qu’un agent écrit un meilleur code, que la configuration d’un autre agent lui est transférable ou que toutes les combinaisons proposent le même workflow. Évaluez directement ces résultats.

Les développeurs qui changent déjà d’agent ont intérêt à essayer dès maintenant. Testez un agent compatible dans l’éditeur que vous utilisez déjà. Le critère décisif est de savoir si la revue des modifications, la visibilité des commandes et la gestion du contexte vous aident à terminer une tâche représentative.

Les responsables d’équipe devraient mener un essai pilote avant de standardiser. Gardez la même tâche et les mêmes critères d’acceptation pour tous les agents. Documentez l’authentification, les outils disponibles, la reprise des sessions et le comportement des autorisations. Choisissez en fonction du travail produit et du contrôle que vous gardez, pas de la taille du registre.

Les responsables de plateforme devraient attendre lorsqu’un environnement indispensable n’est pas pris en charge. La limitation de WSL documentée par JetBrains en est un exemple concret. Un workflow distant qui dépend d’un comportement de transport non établi justifie lui aussi de valider la combinaison avant le déploiement.

Un développeur satisfait de son workflow dans le terminal est peu concerné. L’existence d’un protocole ne justifie pas, à elle seule, un changement d’interface. Si vous cherchez encore quel agent travaille le mieux sur vos tâches, le comparatif Codex vs Claude Code vous aidera à cadrer ce choix ; évaluez ensuite les agents sur votre dépôt.

Questions fréquentes

Qu’est-ce qu’Agent Client Protocol ?

Agent Client Protocol est l’interface commune entre un agent de codage et un éditeur ou un autre client. Il permet aux implémentations compatibles d’échanger des prompts, des informations d’avancement et des actions sans créer une intégration sur mesure pour chaque combinaison.

Quelle différence entre ACP et MCP ?

ACP gère la connexion entre l’éditeur et l’agent. MCP relie une application ou un agent d’IA à des outils et à des données externes. Une session ACP peut fournir des configurations de serveurs MCP : les deux protocoles peuvent donc participer au même workflow.

Quelle différence entre A2A et MCP ?

Agent2Agent (A2A) standardise la communication entre agents indépendants. MCP relie les applications d’IA à des capacités et à des données externes. A2A concerne la collaboration entre agents, tandis que l’ACP présenté dans cet article concerne la connexion à l’éditeur. Consultez la présentation du projet A2A.

Claude Code prend-il en charge Agent Client Protocol ?

L’entrée exacte de l’annuaire est Claude Agent, via l’adaptateur SDK de Zed. Utilisez l’intégration prise en charge et documentée par votre éditeur ; n’y voyez pas une confirmation que chaque exécutable de Claude Code gère ACP nativement. Zed présente Claude Agent comme un agent externe disposant de sa propre authentification.

Claude Code est-il toujours le meilleur agent de codage ?

La prise en charge d’ACP ne permet pas de répondre à cette question. Comparez les agents sur votre dépôt avec la même tâche, les mêmes critères de revue et les mêmes outils autorisés. Privilégiez celui dont vous pouvez valider les modifications et dont le workflow convient aux tâches que vous effectuez régulièrement.

Qui a développé Agent Client Protocol ?

Zed a créé ACP et s’est associé à Google pour faire de Gemini CLI sa première implémentation de référence. JetBrains a rejoint le projet, et sa documentation actuelle présente ACP comme développé de façon ouverte par JetBrains et Zed.

Quelle différence entre Agent Client Protocol et Agent Communication Protocol ?

Ce sont deux projets distincts qui partagent le même sigle. Agent Client Protocol relie les éditeurs aux agents de codage. Agent Communication Protocol d’IBM concernait la communication entre agents ; IBM Research indique désormais qu’il fait partie d’A2A.

Comment fonctionne ACP ?

Pour une session locale, l’éditeur lance l’agent comme sous-processus et communique avec lui en JSON-RPC sur stdio. Ils négocient les capacités, effectuent l’authentification éventuellement requise, ouvrent une session, puis échangent des prompts, des mises à jour et des décisions d’autorisation.

Que signifie ACP dans le contexte de l’IA agentique ?

Dans une intégration à un éditeur, ACP désigne généralement Agent Client Protocol. Vérifiez le nom complet lorsque vous lisez une architecture ou choisissez une bibliothèque : le sigle d’Agent Communication Protocol renvoie à un autre projet.

Pour votre prochaine session de travail

Gardez votre éditeur, choisissez un agent ACP approuvé et commencez par une petite tâche sur le dépôt dont vous pourrez vérifier le résultat. Notez l’agent et l’adaptateur utilisés, la méthode d’authentification, les outils disponibles et le comportement des autorisations. N’élargissez l’essai pilote qu’une fois le cycle de travail complet bien compris, y compris ce qui se passe lorsque vous refusez une action.

Pour recevoir des guides pratiques sur l’évolution des workflows de développement, abonnez-vous à la newsletter.