OpenIDE ajoute ACP : comment le protocole de JetBrains et Zed change la façon dont les agents AI travaillent dans les IDE

ACP devient une nouvelle couche de compatibilité entre l'IDE et les agents IA : au lieu d'une intégration séparée pour chaque outil, l'éditeur et l'agent s'accordent sur un protocole commun. OpenIDE a déjà mis en œuvre le support de base d'ACP et se prépare aux tests bêta.

Qu'est-ce que l'ACP

Au cours de la dernière année, le marché des outils IA pour le développement s'est transformé en un fouillis d'écosystèmes séparés. Claude Code, Codex, Cursor, Windsurf, Kilo Code, Qwen Code et d'autres agents peuvent écrire, corriger et refactoriser le code, mais presque chacun vient avec son propre schéma de connexion à l'éditeur. En conséquence, le développeur choisit non seulement l'agent le plus puissant, mais aussi l'éditeur pour lequel une intégration a déjà été écrite.

ACP tente de briser cette dépendance. Dans son concept, ACP est très similaire à LSP, qui a autrefois libéré les éditeurs du besoin d'implémenter séparément le support de chaque langage. Si à cette époque un protocole unifié connectait l'éditeur au serveur de langage, une telle couche de compatibilité apparaît maintenant entre l'IDE et l'agent IA.

Le protocole décrit comment les parties échangent des messages, le contexte, les demandes d'action et l'état d'exécution. En pratique, cela signifie qu'un agent peut être connecté entièrement — avec sa logique, ses outils et sa façon de fonctionner, plutôt que de simplement envoyer des requêtes au modèle sélectionné via API.

Pourquoi sans norme c'est difficile

Le problème principal du marché actuel est que de nombreuses intégrations restent sur mesure. Un éditeur peut fonctionner avec un agent, un autre avec deux, un troisième nécessite un plugin séparé ou un script semi-officiel. Tant que cela semble tolérable si vous utilisez un seul outil.

Mais dès que vous voulez comparer plusieurs agents, vous vous heurtez rapidement à des incompatibilités, des configurations supplémentaires et un verrouillage du fournisseur. Pour les équipes, c'est encore plus pénible : changer un éditeur ou un agent commence à nécessiter une migration supplémentaire des processus. ACP est nécessaire précisément pour diviser les rôles.

L'IDE est responsable de l'environnement de développement : navigation dans le code, mise en évidence, diffs, refactorisation, travail avec les fichiers et le terminal. L'agent est responsable de la logique autonome : comment construire un plan, quels outils appeler, comment apporter des modifications et quand demander une confirmation. Dans la description officielle du protocole, à la fois les étapes de base comme l'initialisation et la transmission de l'invite, et des choses plus pratiques — lecture et écriture de fichiers, création de terminal, mises à jour de tâches et demandes de permissions d'action.

Un autre point important : connecter un modèle via API n'est pas la même chose que connecter un agent. Lorsque vous fournissez simplement une clé à un LLM, l'éditeur lui-même reste l'orchestrateur et envoie simplement des demandes au fournisseur. ACP vous permet d'intégrer un agent prêt à l'emploi dans l'IDE en tant qu'entité séparée.

Pour le développeur, c'est plus pratique : vous pouvez utiliser votre éditeur préféré sans perdre les fonctionnalités d'un outil IA spécifique. En d'autres termes, la norme apporte non seulement un modèle à l'IDE, mais sa boucle de travail entière.

Ce qui apparaîtra dans OpenIDE

Haulmont écrit que l'implémentation de base d'ACP dans OpenIDE est déjà prête, et l'étape suivante est les tests bêta. Pour les utilisateurs, ce n'est pas un abstrait « on le supportera d'une manière ou d'une autre », mais une étape tout à fait pratique vers un IDE où un agent est connecté en tant que composant standard. Si le support atteint une version stable sans limitations graves, OpenIDE pourra adopter plus rapidement de nouveaux agents compatibles sans intégrations personnalisées séparées pour chacun d'eux.

• Le support de base d'ACP est déjà implémenté
• La fonctionnalité fera partie d'OpenIDE Pro
• Pendant la période bêta, la compatibilité est promise dans la version de base d'OpenIDE
• Les intéressés peuvent demander un accès anticipé et une configuration à l'avance

La logique est claire : au lieu de maintenir manuellement un nombre croissant de plugins IA séparés, l'IDE reçoit une interface unique pour les agents externes. En même temps, OpenIDE lui-même continue de s'appuyer sur les choses familiales aux développeurs — l'éditeur, la navigation, la refactorisation, le terminal et l'écosystème des plugins. L'article souligne spécifiquement que l'environnement est actuellement conçu pour Java, Spring, Python, Go, JavaScript et TypeScript, et peut également fonctionner avec Docker et les extensions d'une place de marché compatible. ACP dans ce schéma ne ressemble pas à un complément à la mode, mais à la prochaine couche d'infrastructure.

Ce que cela signifie

Si ACP s'impose de la manière qu'a imposée LSP, le marché du codage IA deviendra notablement plus ouvert. Les développeurs pourront choisir le meilleur agent indépendamment de leur IDE préféré, et les créateurs d'agents dépenseront moins d'efforts dans des dizaines d'intégrations individuelles. Pour OpenIDE, c'est une chance de connecter plus rapidement les outils populaires, et pour tout l'écosystème, un pas d'un zoo chaotique de plugins IA vers une norme plus cohérente. Ce sont généralement ces protocoles qui déterminent quelles approches deviennent grand public et lesquelles restent nichées.