Agent Client Protocol : un standard pour les agents de code IA

Si vous avez utilisé Claude Code, Codex CLI, Gemini CLI et une poignée d'agents intégrés aux éditeurs cette dernière année, vous avez ressenti la même friction : chaque agent parle son propre dialecte, embarque sa propre interface et vous enferme dans un seul outil. Changer d'éditeur, c'était réapprendre l'agent. Construire un éditeur, c'était réintégrer chaque agent à la main.

L'Agent Client Protocol (ACP) corrige cela. C'est un standard ouvert fondé sur JSON-RPC qui permet à n'importe quel agent de code IA de dialoguer avec n'importe quel éditeur de code. Voyez-le comme le Language Server Protocol (LSP), mais pour les agents : implémentez-le une fois, et votre agent fonctionne partout. Ce guide explique le fonctionnement d'ACP, montre une configuration réelle et détaille pourquoi il est devenu l'un des standards développeurs majeurs de 2026.

Le problème que résout ACP

Avant ACP, l'écosystème du code assisté par IA ressemblait à un enchevêtrement d'intégrations point à point. Chaque éditeur devait bâtir un connecteur sur mesure pour chaque agent, et chaque agent devait livrer des extensions pour chaque éditeur. Avec N éditeurs et M agents, l'industrie était condamnée à N × M intégrations — un casse-tête combinatoire qui ralentissait tout le monde et piégeait les développeurs dans des jardins clos.

C'est exactement le problème que le Language Server Protocol a résolu pour l'outillage des langages il y a dix ans. Au lieu que chaque éditeur implémente séparément l'intelligence Python, Rust et Go, LSP a défini un protocole unique afin qu'un seul serveur de langage serve tous les éditeurs compatibles. ACP applique la même intuition aux agents de code autonomes : définissez le contrat une fois, et le problème en N × M s'effondre en N + M.

Comment fonctionne ACP

ACP standardise la communication entre deux rôles :

Le client — un éditeur interactif comme Zed, un IDE JetBrains, Neovim, Emacs, ou même un notebook tel que marimo.
L'agent — un programme qui utilise l'IA générative pour lire, raisonner et modifier le code de façon autonome, comme Claude Code ou Gemini CLI.

Les deux communiquent via JSON-RPC 2.0, généralement à travers les flux d'entrée et de sortie standard du sous-processus de l'agent. L'éditeur lance l'agent comme processus enfant et ils échangent des messages structurés. Comme le transport se limite à stdio, il n'y a aucun port à gérer, aucun serveur à déployer et aucune configuration réseau — l'agent tourne localement, aux côtés de votre éditeur.

Le cycle de vie des messages

Une session ACP typique suit un déroulement prévisible :

Initialisation — Le client et l'agent procèdent à une poignée de main, négocient un protocolVersion et annoncent leurs capacités. La version stable actuelle du protocole est 1, et la compatibilité est déterminée par cette valeur négociée plutôt que par les numéros de version des paquets.
Authentification — Si l'agent exige des identifiants, le client les fournit.
Création de session — Le client appelle session/new pour démarrer une conversation à état liée à un répertoire de travail.
Invite (prompting) — Le client envoie la requête utilisateur via session/prompt, qui porte l'instruction et le contexte pertinent.
Mises à jour en flux — Pendant qu'il travaille, l'agent renvoie des notifications session/update à l'éditeur : texte de raisonnement, appels d'outils, diffs de fichiers et progression. L'éditeur les affiche en temps réel, avec coloration syntaxique et « suivi de l'agent », pour que vous observiez le travail en train de se faire.
Demandes d'autorisation — Avant une action sensible, l'agent appelle session/request_permission, et l'éditeur vous demande d'approuver ou de refuser. Cela maintient un humain dans la boucle pour les opérations risquées.

Accès aux fichiers et au terminal

Point crucial : l'agent ne touche pas directement votre système de fichiers. Il demande à l'éditeur de le faire via des méthodes du protocole comme fs/read_text_file et fs/write_text_file. C'est un choix de conception délibéré : l'éditeur possède déjà vos tampons non enregistrés, vos observateurs de fichiers et votre historique d'annulation. Acheminer les opérations de fichiers par le client signifie que l'agent voit exactement ce que vous voyez, et que chaque changement passe par les mécanismes habituels de revue et d'annulation de l'éditeur, plutôt que de modifier les fichiers à votre insu.

Configurer un agent ACP

Le protocole étant uniforme, brancher un nouvel agent consiste surtout à indiquer à votre éditeur comment le lancer. Dans Zed, les agents externes personnalisés se déclarent sous la clé agent_servers du fichier settings.json :

{
  "agent_servers": {
    "my-agent": {
      "type": "custom",
      "command": "node",
      "args": ["~/projects/agent/index.js", "--acp"],
      "env": {}
    }
  }
}

Les champs sont minimaux : command est l'exécutable, args les arguments de lancement (ici un drapeau --acp pour démarrer le programme en mode protocole), et env permet d'injecter des variables d'environnement comme des clés d'API. Une fois enregistré, l'agent apparaît dans le panneau d'agents et est prêt à recevoir des invites. Les IDE JetBrains, Neovim et Emacs suivent le même schéma via leurs propres surfaces de configuration.

Construire un agent ACP

Si vous êtes de l'autre côté — à construire un agent plutôt qu'à en consommer un — des SDK officiels existent pour les langages que vous utilisez probablement déjà :

Rust via la crate agent-client-protocol
TypeScript via le paquet npm @agentclientprotocol/sdk
Des SDK Python, Java et Kotlin sont également disponibles

Le SDK gère la plomberie JSON-RPC — encadrement des messages, corrélation requête/réponse et distribution des notifications — pour que vous implémentiez les gestionnaires qui comptent : répondre à initialize, accepter un session/prompt, émettre des notifications session/update au fil du raisonnement du modèle, et demander l'autorisation avant les actions destructrices. La surface du protocole est assez réduite pour qu'un agent minimal tienne en quelques centaines de lignes, tout en restant assez expressive pour des flux agentiques complets.

Le registre ACP : implémentez une fois, distribuez partout

Un protocole n'est que la moitié de l'histoire ; la découverte et la distribution sont l'autre moitié. Le 28 janvier 2026, le projet a lancé le registre ACP (ACP Registry) pour combler ce vide.

Avant le registre, même un agent compatible ACP affrontait un casse-tête de distribution : les développeurs devaient le publier comme extension distincte pour chaque client, ou demander aux utilisateurs de l'installer à la main. Le registre centralise tout cela. L'auteur d'un agent suit le guide de soumission et ouvre une pull request vers le dépôt du registre ; de cette seule action, l'agent devient disponible sur tous les clients compatibles.

Côté consommation, Zed embarque une page de registre ACP intégrée pour parcourir et installer des agents, et les IDE JetBrains ont ajouté la même capacité via un partenariat continu. Parcourez, cliquez sur installer, et vous disposez toujours de la dernière version. Le registre recense déjà Claude Code, Codex CLI, GitHub Copilot CLI, OpenCode, Gemini CLI et une liste grandissante d'autres. C'est ce qui a enfin concrétisé la promesse initiale d'ACP : « implémentez une fois, fonctionne partout ».

Comment ACP se situe par rapport à MCP et A2A

Les développeurs qui suivent l'espace des standards d'agents demandent à juste titre où se place ACP face au Model Context Protocol (MCP) et au protocole Agent-to-Agent (A2A). Ils sont complémentaires, non concurrents :

MCP relie un agent aux outils et aux données — bases de données, API, stockages de fichiers et services externes. Il répond à : « que peut utiliser l'agent ? »
A2A relie un agent à d'autres agents pour la délégation et la collaboration. Il répond à : « comment les agents se parlent-ils ? »
ACP relie un agent à l'éditeur et à l'humain qui le pilote. Il répond à : « comment l'agent me montre-t-il son travail, et comment je le dirige ? »

Un même agent de code peut parler les trois à la fois : ACP pour afficher son raisonnement dans votre éditeur, MCP pour atteindre votre base de données, et A2A pour confier une sous-tâche à un agent spécialisé. Ils occupent des couches différentes de la même pile.

Pourquoi cela compte pour les développeurs et les équipes de la région MENA

Pour les développeurs de Tunisie, d'Arabie saoudite et de la région MENA au sens large, ACP offre un gain stratégique au-delà du simple confort. Comme le protocole découple l'agent de l'éditeur, votre choix d'agent n'est plus un verrouillage à long terme. Si la tarification change, qu'un modèle se voit restreint à l'export ou qu'un meilleur agent apparaît, vous remplacez l'entrée dans settings.json et conservez votre éditeur, vos automatismes et votre flux de travail intacts.

Cette portabilité compte dans une année où l'accès aux modèles de pointe est devenu imprévisible — bridé par des contrôles à l'export, des approbations client par client et des tarifs mouvants. Un éditeur qui parle ACP peut router vers un agent de pointe hébergé aujourd'hui et vers un agent à poids ouverts auto-hébergeable demain, sans réoutillage. Pour les équipes qui standardisent leur pile d'ingénierie, miser sur le protocole ouvert plutôt que sur un fournisseur unique est le choix le plus résilient.

Pour commencer

Pour essayer ACP en moins de dix minutes :

Installez un éditeur compatible ACP comme Zed ou un IDE JetBrains récent.
Ouvrez le registre ACP intégré et installez un agent comme Claude Code ou Gemini CLI.
Ouvrez un projet, appelez le panneau d'agents et envoyez une invite — observez les mises à jour en flux et approuvez les actions au fur et à mesure.
Quand vous voulez un agent personnalisé, ajoutez une entrée agent_servers pointant vers votre exécutable.

En résumé

ACP fait pour les agents de code IA ce que LSP a fait pour l'intelligence des langages : transformer un fouillis d'intégrations point à point en un standard ouvert et propre qui profite à tous. Les éditeurs accèdent à tous les agents. Les agents atteignent tous les éditeurs. Et les développeurs choisissent librement leurs outils, les échangent sans douleur et gardent un humain solidement dans la boucle. Dans le paysage agentique mouvant de 2026, cette portabilité n'est pas un luxe — c'est la façon d'éviter de se retrouver enfermé dans le mauvais pari.