Meilleurs Frameworks et Harnais d'Agents de Code Intégrables en 2026

Vercel AI SDK est le meilleur choix global car l'AI SDK 7 place neuf environnements d'exécution (runtimes) de code derrière une seule surface applicative. Cela peut transformer un futur changement de moteur d'une refonte complète d'interface en une simple décision d'adaptateur, à condition toutefois d'accepter d'administrer votre propre sandbox et d'assumer une frontière de package encore expérimentale.

La réponse courte

Un harnais d'agent de code intégrable est la couche de contrôle appelée par votre application. Il prend en charge, selon les cas, la boucle d'agent, les outils, les permissions, les sessions, la compression de contexte, l'accès aux modèles et l'environnement d'exécution. C'est une décision d'achat radicalement différente du choix d'un agent de code destiné à être utilisé dans un terminal ou un éditeur. Si c'est ce type d'outil interactif que vous recherchez, commencez plutôt par le comparatif des meilleurs agents de code IA.

Pour un nouveau produit TypeScript, Vercel AI SDK HarnessAgent est le meilleur choix global. Il offre à l'application hôte une interface unifiée pour Claude Code, Cline, Codex, Cursor, Deep Agents, fx, Grok Build, OpenCode et Pi. L'intérêt n'est pas de rendre tous ces runtimes identiques. Son apport réside dans le fait que le streaming, le cycle de vie des sessions, l'intégration de l'interface utilisateur et l'instanciation des sandboxes cessent de parasiter chaque fonctionnalité de votre produit ; les capacités spécifiques à chaque adaptateur continuent toutefois de varier.

Le reste du classement dépend de la couche technique que vous souhaitez posséder et exploiter :

1. Vercel AI SDK HarnessAgent : la meilleure couche globale de portabilité
2. Claude Agent SDK : le meilleur runtime propriétaire complet
3. OpenAI Codex SDK : le meilleur pour l'automatisation native avec Codex
4. Cursor SDK : le meilleur runtime propriétaire unifiant local et cloud
5. OpenHands Software Agent SDK : la meilleure stack open source distante
6. OpenCode SDK : la meilleure surface client/serveur typée
7. Pi : le meilleur cœur d'agent minimaliste
8. fx and libfx : la meilleure intégration expérimentale native et navigateur

La règle de décision est directe. Si la capacité de changer de runtime de code ultérieurement représente un avantage stratégique, choisissez Vercel. Si la boucle intégrée d'un fournisseur constitue le cœur de votre valeur produit, utilisez directement Claude ou Codex. Choisissez Cursor lorsqu'un même SDK doit couvrir à la fois des agents locaux et des agents cloud hébergés par Cursor. Si vous avez besoin d'un service distant ouvert, retenez OpenHands ou OpenCode. Si vous souhaitez composer vous-même la boucle la plus légère possible, adoptez Pi. Enfin, utilisez fx lorsque la taille du binaire natif ou l'exécution WebAssembly dans le navigateur constitue l'expérimentation elle-même, et non lorsqu'un calendrier de mise en production impose une frontière de sécurité éprouvée.

Vue d'ensemble

Les tarifs et les capacités ont été vérifiés le 1er septembre 2026. Le « Prix d'entrée » décrit en priorité le SDK ou le package open source. La facturation des tokens de modèle, du calcul, du stockage et du réseau est distincte, car ces coûts découlent de l'architecture que vous déployez.

À quoi ressemble la facture réelle ?

La licence du SDK est rarement la ligne budgétaire déterminante. Ce sont les tokens de sortie des modèles, les contextes volumineux, la durée de vie des sandboxes, les tentatives automatiques (retries) et la revue humaine qui pèsent lourd. Un package gratuit peut piloter un agent particulièrement onéreux, tandis qu'une offre d'hébergement payante peut s'avérer plus économique si elle supprime une charge opérationnelle substantielle.

Prenons une charge de travail standard pour évaluer les ordres de grandeur. Supposons que chaque exécution consomme 20,000 input tokens et 5,000 output tokens, soit lancée 100 times par working day, pendant 22 working days. Cela représente 2,200 runs per month. Il s'agit d'un cadre d'analyse, pas d'un benchmark, et la mise en cache en est volontairement exclue pour rendre les hypothèses transparentes.

Aux tarifs actuels de l'API Claude Sonnet 5 de $2 per million input tokens and $10 per million output tokens, le coût du modèle s'élève à :

• Entrée : 20,000 / 1,000,000 x $2 = $0.04 per run
• Sortie : 5,000 / 1,000,000 x $10 = $0.05 per run
• Total : $0.09 per run, soit $198 per month pour 2,200 exécutions

Au tarif promotionnel actuel de GPT-5.6 Sol fixé à $4 per million input tokens and $20 per million output tokens, la même charge revient à $0.18 per run, soit $396 per month. Cela ne signifie nullement que les deux modèles produisent des résultats équivalents. Cela illustre simplement pourquoi le choix du modèle et la propension de l'agent à relancer des tentatives pèsent bien plus que la licence logicielle.

Ajoutons à présent un exemple de tarification Vercel Sandbox. Une sandbox de 1 GB provisionnée pendant 10 minutes avec 2 minutes de CPU actif coûte environ $0.0078 per run aux tarifs actuels de $0.128 per active CPU hour et $0.0212 per provisioned GB-hour. Sur 2,200 exécutions, cela représente environ $17.16 of gross CPU and memory usage, hors transfert de données et stockage. Le plan Vercel Pro coûte $20 per month et inclut $20 of usage credit ; ce profil de calcul particulier est donc intégralement couvert par ce crédit ; 2,200 creations add about $0.00132 au tarif indiqué de $0.60 par million. L'offre Hobby inclut 5,000 créations mais est réservée à un usage personnel et non commercial, sans possibilité d'acheter du volume additionnel.

Comment ces outils ont été sélectionnés

Le critère d'inclusion fondamental était la capacité de contrôle programmatique depuis une application hôte via un SDK documenté, une bibliothèque, un protocole ou une API serveur. Une simple commande de terminal ne suffisait pas. Un plug-in d'éditeur ne suffisait pas. Un framework de benchmark ou un pack de prompts n'était pas retenu, sauf s'il exposait également une surface d'intégration produit officielle et maintenue.

Ce filtre a réduit un secteur foisonnant à huit options clés. De nombreux répertoires compilent pèle-mêle des SDK de runtimes officiels, des bibliothèques de skills, des projets de recherche et des applications destinées aux utilisateurs finaux. Analyser ces huit solutions en profondeur s'avère bien plus utile qu'un catalogue hétérogène, car c'est précisément au niveau de la frontière opérationnelle que ces approches divergent.

Chaque solution a été évaluée selon cinq critères :

• Contrat d'intégration : ce que l'hôte peut déclencher, streamer, reprendre et interrompre
• Frontière d'exécution : le code tourne-t-il in-process, dans un sous-processus, derrière un serveur ou dans une sandbox ?
• Gestion de l'état : qui conserve les historiques d'exécution, les fichiers de travail, les identifiants et les données de reprise ?
• Contrôle des politiques : où sont définies les permissions, la validation des outils, l'isolation multi-tenant et les règles réseau ?
• Coût de sortie : quelle proportion de votre code survit si vous changez de runtime ou de modèle ?

Aucun test applicatif maison n'est revendiqué ici. Ce comparatif s'appuie sur la documentation officielle des éditeurs, leurs grilles tarifaires actuelles, les frontières de sécurité documentées et le modèle de coût détaillé plus haut. Cette approche privilégie un contrat technique robuste plutôt qu'une démonstration spectaculaire, car un choix d'architecture intégrée survit bien plus longtemps qu'une vidéo de lancement.

1. Vercel AI SDK HarnessAgent : la meilleure couche globale de portabilité

Vercel AI SDK HarnessAgent s'impose comme la solution de référence pour un produit TypeScript recherchant une interface applicative unique pour plusieurs runtimes d'agents de code. L'AI SDK 7 prend en charge Claude Code, Cline, Codex, Cursor, Deep Agents, fx, Grok Build, OpenCode et Pi, tandis que son package bas niveau normalise les sessions, le streaming, les autorisations, les skills, la compaction de contexte et l'accès aux sandboxes. Un cas d'usage typique est un outil de revue de code démarrant sur Claude Code mais prévoyant d'évaluer Codex par la suite sans devoir réécrire son interface de chat ni son gestionnaire de jobs. La contrepartie réside dans sa maturité : @ai-sdk/harness demeure explicitement expérimental, et la plupart des adaptateurs reposant sur un pont réseau imposent une sandbox avec des ports ouverts.

Idéal pour : Les équipes TypeScript considérant la portabilité du runtime comme une garantie stratégique
Point fort : Génération et streaming compatibles avec l'AI SDK à travers de multiples runtimes de code
Tarification : Le package Apache-2.0 est open source. Les offres Vercel Hobby et Pro sont respectivement à $0 et $20 par mois ; Pro inclut $20 de crédits d'utilisation et un essai gratuit, tandis qu'Enterprise fait l'objet d'un devis. L'utilisation de Vercel Sandbox commence à $0.128 par heure de CPU actif et $0.0212 par heure de Go provisionné.
Essai gratuit : Vercel propose un essai gratuit de Pro ; la bibliothèque elle-même est open source

La raison majeure de choisir Vercel ne réside pas dans la simple commodité, mais dans le pouvoir de négociation qu'il confère. Si vos prompts, l'état de l'interface, vos schémas de sortie, l'historique des tâches et les événements d'évaluation se situent au-dessus de l'adaptateur, changer de runtime demandera du travail, mais n'exigera pas la réécriture complète de votre produit. C'est un atout crucial lorsqu'un fournisseur modifie ses politiques d'authentification, qu'un modèle devient trop coûteux ou qu'un autre moteur se montre plus performant sur vos dépôts.

Cette abstraction comporte cependant une limite importante. Les adaptateurs reposant sur un pont (bridge) tels que Claude Code, Cline, Codex, Cursor, Deep Agents, fx, OpenCode et Pi nécessitent aujourd'hui une session de sandbox réseau ; Grok Build utilise quant à lui un processus hôte. Ainsi, « portable » ne signifie pas « déployable partout sans aucun ajustement ». Cela garantit la stabilité du contrat applicatif, tandis que la configuration d'exécution reste spécifique à l'adaptateur.

Depuis le 31 août 2026, l'adaptateur officiel @ai-sdk/harness-fx de Vercel a fait de fx le neuvième harnais supporté, en utilisant le protocole ACP entre HarnessAgent et fx. L'adaptateur préserve l'interface standardisée, mais fx ne gère ni les sorties structurées, ni la compaction manuelle, ni le guidage en cours d'exécution (mid-turn steering), ni le filtrage d'outils intégré à travers cette couche. Ces compromis sont détaillés dans notre analyse de l'adaptateur Vercel fx pour AI SDK.

Le package actuel @ai-sdk/harness atteint la version 1.0.96. Une progression aussi rapide des numéros de version au sein d'un périmètre expérimental impose une discipline stricte : figez les versions de vos dépendances, exécutez des tests de contrat avant chaque mise à niveau et persistez les événements bruts du runtime pour pouvoir les rejouer.

1. 1

   Définissez d'abord le contrat produit

   Formalisez les entrées, le périmètre autorisé du dépôt, le schéma de sortie JSON attendu, le comportement en cas d'annulation et le budget maximum sans faire référence à un runtime en particulier. Un bon premier cas d'usage consiste en une réparation de test unitaire échoué, devant retourner les fichiers modifiés, le statut des tests et une note de risque concise.

2. 2

   Démarrez avec un seul adaptateur

   Installez l'AI SDK 7 dans un service Node.js 22 en ESM, sélectionnez un adaptateur et allouez un répertoire de travail isolé à chaque session. Ne concevez pas encore de sélecteur de runtime dans votre interface.

3. 3

   Rendez l'isolation explicite

   Pour un adaptateur reposant sur un pont, réservez une sandbox réseau, définissez le répertoire de travail, n'installez que des dépendances reproductibles et détruisez ou arrêtez la session via le cycle de vie documenté. Maintenez les identifiants en dehors de l'espace de travail de l'agent.

4. 4

   Mesurez les quatre indicateurs de décision

   Pour chaque tâche, enregistrez le taux d'accomplissement, les refus d'autorisations, la consommation de tokens et le temps d'horloge. Ces valeurs révéleront si un changement d'adaptateur réduit réellement vos coûts ou ne fait que déplacer les anomalies.

5. 5

   Rejouez les scénarios avec un second runtime

   Branchez un second adaptateur derrière le même contrat applicatif et rejouez les mêmes tâches de code. Conservez le premier runtime jusqu'à ce que le second fasse la preuve de sa supériorité sur votre charge réelle, et non sur un benchmark générique.

2. Claude Agent SDK : le meilleur runtime propriétaire complet

Claude Agent SDK est le choix le plus pertinent lorsque la boucle complète de Claude Code représente la fonctionnalité elle-même et non un simple détail d'implémentation. Il expose la même logique d'agent, la gestion du contexte, les outils sur les fichiers, l'exécution de commandes, la recherche web, MCP et le contrôle des permissions en Python et TypeScript. Un service d'audit de sécurité nécessitant une politique stricte d'autorisations et de longues sessions interactives sur un dépôt y trouvera une suite de fonctionnalités bien plus mature qu'avec une boucle élémentaire. Le coût de cette exhaustivité réside dans la dépendance au fournisseur ainsi qu'un modèle de sous-processus et d'isolation multi-tenant que l'hôte doit gérer méticuleusement.

Idéal pour : Les produits dont la proposition de valeur repose sur la boucle et les outils natifs de Claude Code
Point fort : La boucle d'agent et la gestion de contexte identiques à Claude Code, programmables en Python et TypeScript
Tarification : Facturation à l'usage. Les paliers actuels de l'API Claude sont Fable 5 à $10/$50, Opus 5 à $5/$25, Sonnet 5 à $2/$10 et Haiku 4.5 à $1/$5 par million de tokens d'entrée/sortie.
Essai gratuit : Aucun essai distinct n'est proposé pour l'Agent SDK

Claude s'avère particulièrement pertinent lorsque vous souhaitez limiter le nombre de briques à concevoir. L'hôte bénéficie immédiatement d'une boucle de développement éprouvée plutôt que de devoir réinventer l'enchaînement des outils, la gestion de la saturation de contexte et les invites d'autorisation. Cela réduit le volume de code applicatif, mais lie étroitement vos fonctionnalités au cycle de déploiement d'un fournisseur unique.

En production, le dimensionnement des processus est la première contrainte. Anthropic recommande un socle de départ de 1 GiB RAM, 5 GiB disk, and 1 CPU per agent, qui constitue une base minimale et non un plafond. Chaque session tournant dans son propre sous-processus, un conteneur mutualisant de nombreuses sessions simultanées doit impérativement instaurer un plafond de mémoire par session et un contrôle d'admission strict, plutôt que de compter sur une règle d'autoscaling approximative.

La persistance des données constitue un autre point d'attention. Si SessionStore peut répliquer les historiques vers S3, Redis, Postgres ou un adaptateur sur mesure, il ne conserve pas les fichiers mémoire CLAUDE.md ni le contenu de l'espace de travail. En cas d'anomalie de réplication, l'événement mirror_error est levé et la requête se poursuit. Si votre application promet des sessions reprenables à l'utilisateur, lever des alertes sur cet événement et synchroniser les artefacts du workspace sont des impératifs techniques.

L'isolation multi-tenant exige également des configurations explicites. Un processus partagé risquerait sans cela de lire les fichiers de configuration ou la mémoire d'un autre tenant. L'architecture de production documentée impose d'utiliser un répertoire de configuration et un workspace propres à chaque tenant, de désactiver la mémoire automatique, de purger les sources de configuration locales et d'appliquer le filtrage réseau en dehors de l'agent. C'est ce qui sépare l'intégration saine d'un agent d'une faille de sécurité majeure.

3. OpenAI Codex SDK : le meilleur pour l'automatisation native avec Codex

OpenAI Codex SDK représente l'approche directe la plus fluide pour exploiter les threads Codex, streamer l'avancement et encadrer le travail sur les dépôts par des schémas stricts. Le package TypeScript officiel encapsule le CLI Codex et échange des flux JSONL via les entrées et sorties standard (stdin/stdout). Un bot de release devant retourner un objet JSON rigide détaillant les fichiers modifiés, le statut des tests et une note de version s'y prête parfaitement. La limite tient à son couplage architectural : le SDK instancie un processus CLI enfant, et sa politique par défaut requiert impérativement un dépôt Git.

Idéal pour : Les produits déjà adossés à l'écosystème Codex et à l'authentification OpenAI
Point fort : Threads persistants avec événements structurés en streaming et sortie au format JSON Schema
Tarification : Le SDK est sous licence Apache-2.0. La tarification API de GPT-5.6 Sol est actuellement au tarif promotionnel de $4 par million de tokens d'entrée et $20 par million de tokens de sortie.
Essai gratuit : Non applicable au SDK open source ; la facturation des modèles ou abonnements est distincte

Codex n'arrive après Claude dans ce classement que parce que nous privilégions ici une offre d'hébergement intégré plus globale. Pour une application qui pilote déjà des tâches Codex, il peut être le choix le plus logique. L'API fournit les primitives indispensables : le thread préserve l'état de la session, runStreamed() expose l'avancement en temps réel, et les schémas de validation permettent à votre code de rejeter immédiatement un format invalide au lieu d'avoir à parser du texte brut.

L'architecture basée sur des sous-processus n'est pas un défaut en soi. L'échange de JSONL via stdin et stdout facilite le débogage, reste indépendant du langage à la frontière du système et isole le SDK des évolutions internes du CLI. Cela implique cependant d'intégrer dans vos procédures d'exploitation le temps de démarrage des processus, la présence effective du CLI, la gestion rigoureuse de stdout et les signaux d'arrêt. Une requête HTTP ne doit jamais générer un sous-processus orphelin sans contrôle de cycle de vie.

L'état des threads est persisté par défaut dans ~/.codex/sessions en TypeScript. Cette approche locale est pratique pour un poste de développement, mais s'avère risquée comme unique stratégie de persistance dans un conteneur éphémère. Associez les identifiants de threads aux identifiants de tâches de vos clients, configurez le chemin racine de Codex et copiez les données nécessaires vers un stockage durable avant l'extinction des instances.

Si votre arbitrage porte sur la façon dont les ingénieurs utilisent Codex par rapport à Claude Code ou Cursor, notre comparatif Codex vs Claude Code vs Cursor aborde ces flux de travail interactifs. La question posée par ce SDK est différente : votre propre application doit-elle initier et superviser des threads Codex de manière autonome ?

4. Cursor SDK : le meilleur runtime propriétaire unifiant local et cloud

Cursor SDK s'affirme désormais comme un contrat d'intégration officiel à part entière, et non plus comme une simple extension pour éditeur. Ses SDK TypeScript et Python pilotent le même agent selon deux modes d'exécution : les agents locaux tournent au sein de l'environnement de l'application appelante, tandis que les agents cloud s'exécutent dans des machines virtuelles isolées et infogérées par Cursor. Une application peut lancer un agent cloud persistant, streamer son déroulement, stopper son exécution, ou privilégier l'exécution locale quand le code source ne doit pas quitter la machine du développeur. La limite réside dans le périmètre du fournisseur : les deux modes utilisent les moteurs de Cursor, et les outils locaux nécessitent des hooks ou une politique de sandbox stricts avant toute exposition en production.

Idéal pour : Les équipes cherchant un SDK unique pour orchestrer l'exécution locale et l'exécution cloud infogérée
Point fort : Une interface d'agent identique ciblant au choix un processus local ou un agent distant hébergé par Cursor
Tarification : L'usage du SDK dépend des forfaits et pools de requêtes de Cursor. Le plan Hobby est gratuit avec des requêtes Agent restreintes ; Pro est à $20 par mois ; Teams à $40 par utilisateur et par mois ; Enterprise sur devis.
Essai gratuit : Le forfait Hobby est accessible sans souscription payante

Cursor se positionne en retrait des SDK natifs de Codex et Claude, car sa force réside dans la souplesse de ses modes de déploiement et non dans sa neutralité technologique. C'est une solution adaptée pour concevoir une plateforme de développement nécessitant le même comportement sur un poste local et sur une infrastructure cloud managée. En revanche, elle est moins indiquée si l'auto-hébergement, l'audit du code source ou l'indépendance vis-à-vis du fournisseur sont des exigences contractuelles.

5. OpenHands Software Agent SDK : la meilleure stack open source distante

OpenHands Software Agent SDK constitue la référence open source dès lors que vous recherchez à la fois une API d'agent et un service d'exécution distant prêt à être déployé. Ses interfaces Python et REST couvrent des déploiements locaux, Docker et Kubernetes, tandis que son Agent Server diffuse les événements via WebSocket. Une plateforme d'ingénierie soumise à de fortes contraintes réglementaires peut ainsi maintenir les espaces de travail au sein de son propre périmètre tout en exposant un endpoint compatible OpenAI à ses clients internes. La contrepartie réside dans l'empreinte opérationnelle : client, serveur d'agents, isolation des espaces de travail, routage des modèles et stockage persistant deviennent des briques que vous devez administrer vous-même.

Idéal pour : Les équipes Python ayant besoin d'un service d'agents de code autonome et auto-hébergé
Point fort : Une même API de conversation pour des environnements d'exécution locaux, Docker ou distants
Tarification : Gratuit sous licence MIT ; coûts des modèles, conteneurs, réseau et stockage en sus
Essai gratuit : Non applicable ; le SDK est entièrement gratuit et open source

OpenHands fait la différence lorsque « l'auto-hébergement » doit aller plus loin que l'installation d'un binaire sur une machine locale. Son architecture distante sépare nettement trois composants : le client Python, l'Agent Server (exposé en HTTP et WebSocket) et un workspace isolé. Basculer d'une exécution locale vers Docker ou une API distante modifie simplement l'objet workspace, sans altérer la logique de conversation.

Ce découpage facilite l'intégration pour de multiples consommateurs. Une application web, un IDE, un système vocal ou tout client compatible avec l'API OpenAI peuvent interroger ce service sans dépendre de Python. L'équipe peut ainsi centraliser l'authentification, les quotas, les journaux d'audit et le routage géographique directement à l'entrée du service. C'est le socle open source le plus abouti de ce classement pour bâtir une plateforme interne.

Cette richesse fonctionnelle a un coût en temps d'ingénierie. Il vous revient de mettre à jour les images de conteneurs, de borner les ressources des espaces de travail, de renouveler les clés d'API, de superviser les connexions WebSocket et de définir les règles de purge des dépôts clonés. La licence MIT répond à la question juridique, mais pas à celle du coût total de possession (TCO).

L'arbitrage face à Vercel se résume au niveau de contrôle recherché. Vercel fournit un plan de contrôle TypeScript et des sandboxes infogérées. OpenHands offre l'accès au code source et une totale liberté de déploiement, au prix d'une infrastructure plus lourde à maintenir. Si la localisation des données ou l'indépendance vis-à-vis des modèles sont des exigences non négociables, cet investissement est justifié. S'il s'agit d'intégrer rapidement une fonctionnalité d'assistance dans un produit SaaS, cette complexité peut devenir un frein.

6. OpenCode SDK : la meilleure surface client/serveur typée

OpenCode SDK constitue la solution autonome la plus élégante pour un environnement JavaScript ou TypeScript souhaitant piloter un serveur OpenCode via un client rigoureusement typé. La méthode createOpencode() instancie simultanément le serveur et le client, tandis que createOpencodeClient() permet de se connecter à une instance de serveur préexistante. Une application de bureau ou un portail interne peut ainsi initialiser des sessions, écouter les flux d'événements, valider des permissions, lancer des commandes shell, explorer des répertoires et requêter des sorties structurées via des types générés. La contrepartie découle de son architecture : il s'agit d'une relation client/serveur, confiant à l'application hôte la responsabilité du cycle de vie du serveur, de l'exposition des ports, de l'isolation multi-tenant et de la sécurité.

Idéal pour : Les produits JavaScript et TypeScript recherchant un serveur d'agent explicite avec un client typé
Point fort : Des types générés depuis la spécification OpenAPI couvrant les sessions, fichiers, commandes, permissions et événements
Tarification : Gratuit sous licence MIT ; coûts des modèles et des serveurs en sus
Essai gratuit : Non applicable ; le SDK est entièrement open source

La configuration locale par défaut est délibérément accessible : 127.0.0.1, port 4096, et un timeout d'initialisation de 5,000 ms. Ces paramètres conviennent à une application Electron, à des scripts locaux ou à des outils de développement. Ils ne doivent en aucun cas être déployés tels quels en production. Un serveur exposé à plusieurs utilisateurs nécessite une couche d'authentification en amont, une isolation stricte des espaces de travail par tâche et un filtrage précis des commandes système et des accès aux fichiers.

Le point fort d'OpenCode réside dans son inspectabilité. La création de sessions, l'envoi de requêtes, l'interruption, le partage, la génération de résumés, les appels système, les validations de permissions, les manipulations de fichiers et la souscription aux flux d'événements sont tous exposés sous forme de méthodes explicites. Cela simplifie considérablement le développement d'une console d'administration par rapport à un package « boîte noire » se résumant à un échange de prompts et de réponses.

Face à OpenHands, la différence se joue sur le langage et l'ambition d'infrastructure. OpenCode fournit un client JS/TS très propre autour de son serveur. OpenHands propose un SDK centré sur Python complété par une gestion poussée des workspaces distants conteneurisés. Optez pour OpenCode si votre socle technique est TypeScript et que le serveur OpenCode correspond à vos besoins. Préférez OpenHands si vous recherchez une plateforme d'agents ouverte et la portabilité des environnements d'exécution avant tout.

7. Pi : le meilleur cœur d'agent minimaliste

Pi s'impose lorsque votre produit a besoin d'une boucle d'agent légère et malléable plutôt que d'une plateforme de développement prête à l'emploi. Le package @earendil-works/pi-agent-core prend en charge l'état, l'exécution des outils, le streaming des événements, l'alternance de modèles, le guidage en cours d'exécution, la file d'attente d'instructions et les hooks d'outils ; le projet propose également un SDK Node.js et une interface RPC en JSONL. Un service spécialisé dans la migration de code peut ainsi définir strictement les outils et les événements dont il a besoin, sans s'encombrer d'un agent de terminal complet. La contrepartie réside dans l'effort d'intégration : la persistance, les outils d'édition, l'isolation et les politiques de sécurité restent entièrement à votre charge.

Idéal pour : Les équipes souhaitant garder la maîtrise totale de la boucle d'exécution et de la politique des outils
Point fort : Un moteur avec gestion d'état, streaming d'événements et hooks d'outils, sans architecture serveur imposée
Tarification : Gratuit sous licence MIT ; modèles, stockage et infrastructure de calcul en sus
Essai gratuit : Non applicable ; Pi est entièrement open source

La force de Pi réside dans sa neutralité : il évite d'imposer des choix d'architecture prématurés. Son cœur sait streamer les messages des modèles, appeler des outils, gérer des interruptions, empiler des consignes, réécrire le contexte avant une inférence et s'interrompre proprement après un tour d'exécution. C'est amplement suffisant pour concevoir un workflow sur mesure sans devoir repartir d'appels HTTP bruts aux API de modèles.

Cette sobriété a son revers : la persistance des sessions et l'isolation des sandboxes ne sont pas gérées par le composant central. Les outils doivent être déclarés par l'appelant. L'empreinte reste minimale et hautement portable, mais chaque omission technique implique une phase de conception supplémentaire pour votre équipe.

Cela fait de Pi un composant remarquable pour des agents spécialisés à périmètre étroit. Imaginez un microservice chargé uniquement de lire le manifeste d'un dépôt, de mettre à jour une dépendance, d'exécuter une suite de tests et de générer un rapport signé. Quatre outils strictement délimités et un connecteur de persistance basique seront bien plus sûrs et véloces qu'un agent généraliste surchargé de fonctionnalités. En revanche, cette approche est moins séduisante pour développer un outil de type IDE requérant d'emblée des sessions partagées, un gestionnaire de compétences, des terminaux interactifs et une console d'administration complète.

Pi est par ailleurs intégré derrière l'adaptateur Vercel. Si vous souhaitez exploiter la légèreté de Pi aujourd'hui tout en conservant la faculté de tester d'autres moteurs plus tard, Vercel peut faire office de contrat applicatif stable. Si votre objectif est précisément de refuser toute couche d'abstraction supplémentaire, importer directement le core de Pi est l'approche logique.

8. fx et libfx : la meilleure intégration expérimentale native et navigateur

fx and libfx représentent la proposition expérimentale la plus stimulante pour un produit nécessitant un binaire natif ultra-léger, le support du protocole ACP, une intégration Node.js directe, une boucle d'agent exécutée au sein d'un navigateur moderne ou une utilisation de fx derrière Vercel HarnessAgent. Le site officiel présente la v0.0.7 comme un agent de code de 6.19 MiB, agnostique quant aux modèles et sous licence Apache-2.0, tandis que libfx expose un agent autonome (headless) et un terminal interactif via des modules natifs Node ou en WebAssembly. Un outil pour développeurs axé sur le local (local-first), recherchant un cœur natif compact et une démonstration dans le navigateur, y trouvera un candidat naturel. La réserve est cependant de taille : le projet reste expérimental, l'intégration web requiert JSPI, la compilation WASM fait l'impasse sur des fonctionnalités natives majeures, et les contrôles de sandbox pour les commandes locales ont été retirés depuis la v0.0.5.

Idéal pour : La recherche appliquée sur des agents ultra-compacts ciblant le natif, ACP, Node ou le navigateur
Point fort : Un cœur unique en Zig décliné en binaire autonome, modules natifs Node, fx-core.wasm et fx-term.wasm
Tarification : Gratuit sous licence Apache-2.0 ; clés d'accès aux modèles ou calcul local en sus
Essai gratuit : Non applicable ; fx est entièrement open source

La version 0.0.7 apporte le guidage pendant le tour d'exécution (active-turn steering), la configuration MCP au niveau du projet, la découverte des capacités MCP et un contrôle plus strict de la confiance envers ces serveurs. Une modification majeure d'architecture demeure : depuis la v0.0.5, les commandes système approuvées (qu'elles soient capturées, en arrière-plan ou surveillées) s'exécutent comme des sous-processus standard de la machine hôte, et les anciennes directives de configuration de sandbox ont disparu.

Ce n'est pas un point de détail. Dans une application pour poste de travail, toute commande validée s'exécute directement sur le système d'exploitation de l'utilisateur, à moins que l'application hôte n'instancie son propre mécanisme de confinement. Sur le plan budgétaire, cela impose d'ajouter une ligne de coûts pour le filtrage des commandes, les quotas de processus, le cloisonnement des répertoires et éventuellement une sandbox tierce. Il ne faut pas confondre un « callback d'autorisation » avec une véritable « sandbox d'isolation ».

L'environnement d'exécution dans le navigateur comporte d'autres garde-fous. libfx exige Chrome or Edge 137 or later avec JSPI pour faire tourner le module WebAssembly. Ce runtime WASM omet délibérément les processus système, le sandboxing au niveau OS, les serveurs MCP natifs, les sous-agents ou skills, les mises à niveau automatiques, l'accès direct aux fichiers via WASI et l'accès réseau ouvert. L'application hôte peut exposer une interface restreinte pour exécuter des commandes, mais c'est à elle qu'incombe la charge de filtrer ces instructions, de limiter les ressources et de tronquer les données retournées.

La gestion des identifiants API appelle également une grande prudence, y compris lors d'un simple proof of concept. La documentation rappelle formellement de ne jamais exposer une clé API pérenne dans le code client d'un navigateur. Il est indispensable de recourir à des jetons éphémères ou à un proxy d'authentification côté serveur. Si ce proxy, l'adaptateur de workspace et la politique de contrôle des commandes ne sont pas déjà en place, le module WASM ne suffit pas à lui seul pour constituer une architecture viable.

L'usage le plus pertinent à ce jour réside dans des prototypes internes manipulant des dépôts non critiques avec un jeu d'outils réduit. Le scénario le plus risqué consiste à concevoir une application web grand public embarquant une clé API longue durée, en ouvrant un pont de commandes permissif et en présumant que le binaire WASM assure l'isolation nécessaire. fx mérite toute sa place dans ce comparatif pour son audace technique, mais sa maturité actuelle justifie son rang en queue de liste.

Qui devrait choisir quoi ?

Optez pour Vercel AI SDK HarnessAgent si votre application doit pouvoir changer de runtime de code à l'avenir sans tout reconstruire. Cette transition ne sera pas instantanée, mais disposer d'un contrat d'interface stable préserve vos écrans, vos schémas JSON, vos historiques de session et vos jeux de tests au-dessus de l'adaptateur. Écartez Vercel si votre organisation refuse les packages logiciels en version expérimentale ou si l'adaptateur masque une fonctionnalité native indispensable propre à un fournisseur.

Optez pour Claude Agent SDK si la boucle d'exécution de Claude Code constitue votre principal avantage concurrentiel et que votre infrastructure sait gérer un sous-processus par session active. C'est l'offre clé en main la plus aboutie. Préférez Codex si les threads structurés et l'authentification native OpenAI sont prépondérants, ou Vercel si la réversibilité du fournisseur est une exigence contractuelle.

Optez pour OpenAI Codex SDK si votre stack technique repose déjà sur OpenAI et nécessite des threads persistants, un streaming d'événements machine et des résultats strictement conformes à un schéma. Délaissez-le si la gestion de sous-processus CLI est proscrite dans votre environnement ou si une interface agnostique compte plus qu'un accès direct.

Optez pour Cursor SDK si un workflow applicatif unique doit s'exécuter indifféremment sur la machine du développeur ou au sein d'agents cloud infogérés par Cursor. Fuyez-le si l'auto-hébergement et l'indépendance technologique sont inscrits dans votre cahier des charges.

Optez pour OpenHands si plusieurs applications doivent s'interfacer avec une plateforme d'agents de code ouverte, déployée au sein de votre propre infrastructure. La dissociation claire entre client, serveur et espace de travail conteneurisé est idéale pour une équipe plateforme. Orientez-vous vers OpenCode si votre préférence va à un serveur piloté en TypeScript, ou vers Pi si une architecture distante complète est disproportionnée par rapport à votre cas d'usage.

Optez pour OpenCode SDK si votre objectif est de vous appuyer sur un client typé manipulant explicitement un serveur OpenCode. C'est une architecture idéale pour des logiciels desktop ou des portails internes d'entreprise. Délaissez-le si votre application ne peut pas prendre en charge le monitoring et la sécurisation réseau du serveur.

Optez pour Pi lorsqu'une boucle minimaliste et personnalisable est requise, et que vous souhaitez implémenter vous-même la logique d'état, les outils et les règles de sécurité. Tournez-vous vers un runtime plus packagé si ces composants ne représentent aucune différenciation métier.

Ne retenez fx que si la taille ultra-réduite du binaire natif, l'intégration ACP ou le WebAssembly en navigateur constituent l'objet premier de votre R&D. Son modèle d'exécution actuel et les spécificités de son runtime navigateur réclament bien plus de développements d'infrastructure autour de l'hôte que ses quelques mégaoctets ne le laissent supposer.

Pour un déploiement transverse à l'échelle d'une entreprise plutôt que l'intégration d'un composant applicatif, consultez notre guide des agents de code pour l'entreprise. Les enjeux d'achats, de gestion des identités, d'audit et d'adoption par les développeurs y pèsent bien plus lourd que l'interface du SDK.

Les solutions à éviter

Écarter un outil de ce comparatif ne signifie pas qu'il est inefficace pour écrire du code. Cela signifie qu'il ne propose pas le contrat d'intégration requis pour ce type de projet.

Aider comme dépendance intégrée à un produit. Aider est un outil remarquable pour le pair-programming dans un terminal et peut se connecter à des modèles distants ou locaux. Un CLI peut être automatisé par script, mais l'automatisation d'un sous-processus ne remplace pas un contrat d'intégration stable, documenté et pourvu de garanties sur les sessions, les permissions, le cycle de vie et le format des sorties. Utilisez Aider pour vos besoins interactifs en console. Pour un produit logiciel, privilégiez un SDK ou une API serveur officiellement maintenus.

SWE-agent pour une nouvelle intégration. Le dépôt de SWE-agent indique désormais qu'il est supplanté par mini-SWE-agent et recommande ce dernier projet pour tout nouveau travail. Si SWE-agent conserve toute sa valeur pour la recherche académique et la reproduction de benchmarks, baser une architecture produit pérenne sur un projet officiellement dépassé créerait une dette technique immédiate.

Évitez également tout wrapper dont l'unique proposition de valeur repose sur le nom d'un modèle d'IA. Les modèles évoluent bien plus vite que vos schémas de session, vos politiques de sécurité, vos jeux d'évaluation et les workflows métiers de vos clients. Votre couche de contrôle technique doit précisément protéger et valoriser ces actifs durables.

Le plan d'action pour lundi

Ne commencez pas votre semaine en essayant d'intégrer huit SDK en parallèle. Rédigez un contrat de validation neutre et rejouez-le sur deux solutions concurrentes.

Sélectionnez trois scénarios représentatifs de la valeur délivrée à vos utilisateurs :

• Un test unitaire en échec nécessitant une correction ciblée
• Une montée de version de dépendance avec génération d'une note de migration
• Une tâche de revue en lecture seule devant référencer des fichiers précis sans appliquer de modifications

Pour chaque scénario, délimitez le périmètre du dépôt, les commandes exécutables autorisées, le temps d'exécution maximal, le budget de tokens plafond, le schéma JSON de sortie obligatoire et les règles d'escalade vers un humain. Mesurez pour chaque tentative le succès de la tâche, le résultat des tests, les fichiers touchés, les outils rejetés, les tokens consommés, les retries nécessaires et le temps requis pour obtenir la validation humaine. Exécutez ce protocole sur le candidat favori, puis sur son alternative la plus crédible.

Le livrable doit être une note de cadrage décisionnelle, et non un simple score de benchmark. Si Vercel préserve l'intégrité de votre contrat applicatif et que les runtimes sous-jacents affichent des performances comparables, la portabilité l'emporte. Si Claude réussit les tâches complexes avec beaucoup moins d'itérations, la dépendance envers le fournisseur sera rapidement rentabilisée. Si OpenHands garantit l'isolation réglementaire sans imposer de service cloud tiers, votre équipe d'infrastructure pourra justifier son empreinte plus lourde. Enfin, si fx requiert le développement d'une sandbox personnalisée avant le premier déploiement client, cette charge doit être inscrite au budget immédiatement.

FAQ

Quel est le meilleur harnais d'agent de code pour les LLM locaux ?

OpenHands représente la stack open source la plus complète lorsque des modèles locaux nécessitent une architecture client/serveur avec des espaces de travail isolés. Pi est plus adapté si vous recherchez une boucle compacte et prévoyez d'apporter vous-même les outils, la persistance et la sandbox. fx est également agnostique sur les modèles, mais son statut expérimental le réserve à la recherche.

Quel harnais d'agent de code obtient les meilleurs scores aux benchmarks ?

Aucun benchmark public ne permet d'évaluer l'adéquation d'un outil pour une intégration logicielle. Un benchmark mesure des taux de réussite selon ses propres prompts, jeux d'outils, dépôts tests et limites d'exécution. Les équipes d'ingénierie doivent tester leurs dépôts réels avec leurs propres règles de sécurité, puis comparer le succès, les retries, la dépense en tokens et le temps de validation humaine.

OpenCode est-il un véritable harnais d'agent de code intégrable ?

Oui. Le SDK d'OpenCode permet d'instancier un serveur et son client, ou de connecter un client typé à un serveur existant. Sa frontière d'intégration repose donc sur une architecture client/serveur plutôt que sur une boucle d'agent exécutée in-process.

Quel est le meilleur harnais d'agent de code intégrable et gratuit ?

OpenHands est la stack complète la plus robuste sous licence libre MIT ; Pi est le meilleur moteur minimaliste sous licence MIT. OpenCode et fx sont également open source. La notion de gratuité concerne ici la licence logicielle, mais n'inclut pas les tokens des modèles, le calcul, le stockage, le réseau ni le temps passé par vos ingénieurs à administrer la solution.

Mots-clés

frameworks et harnais d agents de code integrables, agent de code integrable, sdk agent de code, vercel ai sdk harnessagent, claude agent sdk, openai codex sdk, cursor sdk, openhands software agent sdk, opencode sdk

La checklist d'audit des flux de travail IA pour l'entreprise

Téléchargez notre checklist gratuite pour identifier les processus prêts à être confiés à un agent et ceux nécessitant encore une validation humaine.

---