Aller au contenu principal
Cline publie son SDK open source : un runtime d'agents qui alimente désormais son CLI et son Kanban, avec migration des extensions IDE
OutilsMarkTechPost6sem· 2 min de lecture

Cline publie son SDK open source : un runtime d'agents qui alimente désormais son CLI et son Kanban, avec migration des extensions IDE

Source originale ↗·

Cline, l'agent de codage IA open-source utilisé par des millions de développeurs, a annoncé cette semaine une refonte architecturale majeure avec la sortie de @cline/sdk, un runtime d'agent TypeScript désormais disponible en open-source. Concrètement, l'équipe a extrait le coeur du moteur agentique, jusqu'ici étroitement couplé à l'extension VS Code, pour en faire un SDK indépendant, modulaire, sur lequel tous ses produits sont désormais reconstruits : l'extension VS Code, JetBrains, le CLI et le tableau Kanban. Le SDK est structuré en couches strictement ordonnées : @cline/shared (types, schémas, utilitaires), @cline/llms (passerelle vers Anthropic, OpenAI, Google, AWS Bedrock, Mistral, LiteLLM et tout endpoint compatible OpenAI), @cline/agents (boucle d'exécution stateless, compatible navigateur), et @cline/core (orchestration Node.js, sessions, stockage, télémétrie, plugins). Chaque couche est installable séparément, ce qui permet par exemple d'utiliser uniquement @cline/llms comme proxy LLM sans embarquer tout le runtime.

Cette architecture redéfinie apporte des gains concrets mesurables. Avec Cline 2.0, l'équipe a reécrit les prompts, simplifié la boucle agentique et amélioré la gestion du contexte. Les résultats publiés sur Terminal Benchmark 2.0 (tbench.ai) au 8 mai 2026 sont frappants : sur claude-opus-4.7, le CLI Cline atteint 74,2% contre 69,4% pour Claude Code d'Anthropic sur le même modèle. Sur claude-opus-4.6, l'écart est similaire, 71,9% contre 65,4%. Sur les modèles open-weight, Cline marque 55,1% sur Kimi-K2.6, contre 37,1% pour OpenCode et 45,5% pour Pi-Code. Côté stabilité, les sessions agentiques longues ne meurent plus lors d'un redémarrage de l'interface : la boucle reste stateless et portable, tandis que la persistance est gérée séparément par le runtime.

Cette sortie s'inscrit dans une tendance plus large : celle de la fragmentation et de la standardisation de l'outillage agentique. Pendant des années, les agents IA étaient construits comme des monolithes liés à une interface spécifique, VS Code, un navigateur, un SaaS. Le choix de Cline de découpler son moteur de ses surfaces d'affichage ouvre la voie à une nouvelle génération d'outils où le même agent peut s'exécuter dans un IDE, un terminal, un serveur serverless ou un environnement browser sans réécriture. Le système de plugins intégré au SDK permet en outre aux équipes tierces d'enregistrer leurs propres outils, d'observer les événements du cycle de vie de l'agent et d'étendre ses capacités. Pour les éditeurs et startups qui cherchent à construire sur une base agentique robuste sans repartir de zéro, @cline/sdk représente une fondation crédible, et son positionnement open-source face à des alternatives propriétaires comme Claude Code ou Cursor pourrait accélérer l'adoption dans les environnements d'entreprise.

Impact France/UE

Le SDK intègre Mistral nativement comme fournisseur LLM, ce qui facilite l'adoption par les équipes européennes souhaitant une alternative open-source aux outils propriétaires soumis au CLOUD Act.

Cet article vous a été utile ?

Vu une erreur factuelle dans cet article ? Signalez-la. Toutes les corrections valides sont publiées sur /corrections.

À lire aussi

OpenAI publie Symphony en open source : un SPEC.md pour l'orchestration d'agents de codage autonomes
1InfoQ AI 

OpenAI publie Symphony en open source : un SPEC.md pour l'orchestration d'agents de codage autonomes

OpenAI a publié en open source Symphony, un orchestrateur d'agents de codage autonomes accompagné d'une spécification formelle baptisée SPEC.md. Le système utilise des outils de gestion de projet, comme les gestionnaires de tickets, comme plan de contrôle pour coordonner plusieurs agents travaillant en parallèle. Concrètement, Symphony découpe le travail en "tâches" distinctes, chacune confiée à un agent dédié qui progresse jusqu'à l'achèvement sans intervention humaine continue. Une fois la tâche terminée, un développeur humain examine le résultat avant de valider ou corriger. Ce modèle rompt avec l'approche actuelle où les développeurs supervisent activement chaque session de codage assistée par IA. Avec Symphony, un ingénieur peut déléguer simultanément plusieurs blocs de travail à une flotte d'agents autonomes, ce qui multiplie potentiellement la capacité de production d'une équipe sans augmenter ses effectifs. Pour les entreprises tech, cela annonce des pipelines de développement logiciel beaucoup plus automatisés, où l'humain intervient surtout en phase de validation plutôt qu'en pilotage continu. Symphony émerge dans un contexte de compétition intense autour des agents de codage autonomes. OpenAI affronte Anthropic et son assistant Claude, Google avec Gemini Code Assist, ainsi que des startups comme Cognition AI dont l'agent Devin cible explicitement ce marché. En diffusant Symphony sous forme de spécification ouverte, OpenAI tente d'influencer les standards de l'industrie et d'encourager l'adoption de son approche d'orchestration par d'autres équipes et plateformes. La prochaine étape sera de voir si SPEC.md s'impose comme référence, ou si chaque acteur développe son propre modèle propriétaire.

💬 OpenAI publie une spec ouverte, pas juste du code, et c'est exactement la stratégie qu'on adopte quand on veut que l'industrie entière s'aligne sur ton modèle d'orchestration plutôt que sur celui du voisin. Le truc intéressant dans Symphony, c'est ce glissement : le dev ne pilote plus en continu, il valide à la fin, comme un lead qui fait des code reviews plutôt que du pair-programming permanent. Ça ressemble à du vrai changement de workflow, pas du gadget.

OutilsOutil
1 source
AgentCore : optimisation de la qualité des agents, désormais en préversion
2AWS ML Blog 

AgentCore : optimisation de la qualité des agents, désormais en préversion

Amazon a annoncé ce 5 mai 2026 l'intégration de nouvelles capacités d'optimisation automatique dans AgentCore, sa plateforme de déploiement d'agents IA, désormais disponibles en préversion. Ces fonctionnalités couvrent trois mécanismes complémentaires : les Recommandations, l'évaluation par lots (batch evaluation) et les tests A/B. Le moteur de recommandations analyse les traces de production et les résultats d'évaluation pour proposer des améliorations concrètes des prompts système ou des descriptions d'outils, en ciblant un critère de performance défini par le développeur. L'évaluation par lots permet ensuite de valider ces suggestions sur un jeu de données de test prédéfini, en mesurant des scores agrégés pour détecter d'éventuelles régressions. Enfin, les tests A/B comparent deux versions d'un agent en production via AgentCore Gateway, en répartissant le trafic réel selon un pourcentage configurable et en restituant les résultats avec intervalles de confiance et significativité statistique. L'ensemble s'appuie sur un système de traçabilité OpenTelemetry géré par AgentCore Observability, qui capture chaque appel au modèle, chaque invocation d'outil et chaque étape de raisonnement. Ces nouvelles capacités répondent à un problème structurel bien connu des équipes IA en production : la dégradation silencieuse des agents au fil du temps. Lorsque les modèles évoluent, les comportements utilisateurs changent, ou les prompts sont réutilisés dans des contextes imprévus, la qualité baisse sans signal d'alerte clair. Jusqu'ici, le cycle de correction restait entièrement manuel : un utilisateur se plaint, un développeur lit des traces, formule une hypothèse, réécrit le prompt, teste quelques cas et pousse un correctif qui peut en créer un autre. AgentCore ferme cette boucle en remplaçant l'intuition du développeur par des données systématiques, avec un signal de récompense configurable : taux de succès des objectifs, précision de sélection des outils, pertinence, sécurité. Yoshiharu Okuda, directeur de la stratégie IA générative chez NTT DATA, a confirmé que des processus qui nécessitaient auparavant plusieurs semaines de réglage manuel se transforment désormais en cycles rapides et reproductibles. AgentCore est la plateforme d'Amazon Web Services pour construire, connecter et optimiser des agents IA à grande échelle, avec des milliers de développeurs déjà actifs. Cette annonce s'inscrit dans une course plus large entre les grands fournisseurs cloud pour proposer des outils d'opérationnalisation des agents, au-delà de la simple inférence. Google Vertex AI, Microsoft Azure AI et AWS se disputent les équipes qui passent de la phase expérimentale à la production à grande échelle, là où la maintenance de la qualité devient un défi d'ingénierie à part entière. En automatisant la boucle observer-évaluer-améliorer, AWS positionne AgentCore comme une infrastructure de fond pour les organisations qui ne peuvent pas se permettre des équipes dédiées à l'optimisation manuelle de prompts sur des cycles hebdomadaires, alors que leurs agents dérivent chaque jour en production.

OutilsActu
1 source
Databricks publie Omnigent en open source : un orchestrateur d'agents IA qui unifie Claude Code, Codex et Pi
3MarkTechPost 

Databricks publie Omnigent en open source : un orchestrateur d'agents IA qui unifie Claude Code, Codex et Pi

Databricks a publié Omnigent, un "meta-harness" open source placé au-dessus des agents IA existants comme Claude Code, Codex et Pi. Développé en collaboration avec Neon et distribué sous licence Apache 2.0, Omnigent ne remplace pas ces outils : il s'installe une couche au-dessus d'eux pour les orchestrer comme des pièces interchangeables d'un même système. Concrètement, un "harness" est l'enveloppe logicielle qui transforme un modèle de langage en agent capable d'agir. Omnigent standardise l'interface de ces harnesses, messages entrants, fichiers, flux de texte et appels d'outils sortants, pour qu'ils deviennent substituables sans réécriture de code. L'outil s'installe via deux alias CLI identiques, omnigent et omni, et lance au démarrage une interface web locale sur localhost:6767, synchronisée en temps réel avec le terminal et accessible depuis un téléphone. Pour les équipes d'ingénieurs qui jonglent déjà entre quatre ou cinq agents simultanément en copiant du texte entre des outils de code, des moteurs de recherche et Slack, Omnigent apporte trois capacités structurantes. La composition permet de combiner modèles et harnesses sans toucher au code : un simple changement d'une ligne suffit à basculer de Claude Code à Codex. Le contrôle introduit des politiques stateful, par exemple, mettre un agent en pause après chaque dépense de 100 dollars, ou exiger une validation humaine avant un git push si l'agent a installé un nouveau paquet npm. La collaboration permet de partager une session d'agent en direct par URL : les coéquipiers peuvent observer, commenter des fichiers, co-piloter ou bifurquer la conversation. Un sandbox système appelé Omnibox assure la sécurité sous-jacente, notamment en injectant les tokens GitHub uniquement via un proxy de sortie approuvé, sans les exposer à l'agent. Le projet embarque deux agents d'exemple révélateurs de la philosophie de l'outil. "Polly" est un orchestrateur multi-agents qui ne génère aucun code lui-même : il planifie, puis délègue en parallèle à des sous-agents dans des worktrees git distincts, avec une revue croisée assurée par un agent d'un fournisseur différent de celui qui a écrit le code. "Debby" est un partenaire de brainstorming à deux têtes, Claude et GPT, qui répond en parallèle à chaque question et peut déclencher un débat contradictoire entre les deux via la commande /debate. Ces exemples illustrent une tendance de fond : avec la multiplication des agents spécialisés, la compétition ne se joue plus seulement au niveau du modèle, mais à celui de l'orchestration. Omnigent positionne Databricks sur ce terrain en proposant une couche de gouvernance neutre, ouverte, et potentiellement universelle pour l'écosystème des agents de développement.

💬 Le truc qui m'a accroché, c'est pas la couche d'orchestration générique, c'est les politiques de contrôle : mettre un agent en pause après 100 dollars de dépenses, bloquer un git push si un nouveau paquet npm s'est glissé sans validation humaine, c'est le maillon qui manquait depuis qu'on jongle avec cinq agents en même temps. Databricks parie que la bataille se joue à la gouvernance plutôt qu'au modèle, et ce pari-là je le trouve solide. Apache 2.0, Neon dans la boucle, reste à voir si l'écosystème suit vraiment.

OutilsOutil
1 source
Comment construire un système d'agents IA avec routage dynamique des outils, planification et injection de contexte
4MarkTechPost 

Comment construire un système d'agents IA avec routage dynamique des outils, planification et injection de contexte

Un tutoriel récemment publié détaille la construction complète d'un système d'agent IA de type MCP (Model Context Protocol) en Python, depuis la configuration jusqu'à l'exécution de tâches réelles. Le système repose sur un serveur d'outils modulaire qui expose des capacités structurées : recherche web via DuckDuckGo, récupération de documents locaux par similarité TF-IDF, chargement de jeux de données et exécution de code Python. Le tout s'appuie sur l'API OpenAI avec le modèle gpt-4.1-mini, et mobilise des bibliothèques comme Pydantic pour la validation des schémas, scikit-learn pour la recherche vectorielle, et Rich pour l'affichage console. Les paramètres globaux limitent volontairement l'agent à trois appels d'outils maximum par tâche, cinq résultats web, et trois documents récupérés, afin de maintenir des performances prévisibles. Ce que ce tutoriel apporte de concret, c'est une réponse au problème central des agents IA en production : comment éviter qu'un agent appelle n'importe quel outil dans n'importe quel contexte. Le système implémente un routeur hybride qui combine des heuristiques simples et du raisonnement LLM pour décider dynamiquement quels outils rendre visibles selon la tâche en cours. Un agent qui répond à une question factuelle simple ne voit pas les outils d'exécution de code ; un agent qui analyse des données n'a pas accès à la recherche web si elle est inutile. Cette exposition sélective réduit les coûts d'inférence, améliore la traçabilité des décisions, et limite la surface d'erreur, trois enjeux critiques pour quiconque déploie des agents dans un environnement professionnel. Le Model Context Protocol, popularisé par Anthropic en novembre 2024 comme standard ouvert pour connecter les LLM à des outils externes, cherche à résoudre un problème de fragmentation : chaque développeur réinventait sa propre façon de brancher des modèles à des APIs ou des bases de données. Ce tutoriel illustre comment les principes MCP, notamment l'injection de contexte structuré, les politiques de routage et le contrôle d'accès aux outils, peuvent être implémentés sans framework propriétaire, en Python pur. À mesure que les systèmes multi-agents se multiplient dans les entreprises, cette approche d'exposition minimale et contrôlée des capacités s'impose comme une bonne pratique d'architecture, opposée aux agents monolithiques qui ont accès à tout et dont le comportement devient difficile à auditer ou à reproduire.

💬 Le routage sélectif des outils, c'est exactement ce qui manque à 90% des démos d'agents qu'on voit tourner. Un agent qui n'expose que ce dont il a besoin pour la tâche en cours, c'est pas glamour, mais c'est ce qui fait la différence entre un prototype et quelque chose qu'on peut vraiment auditer en prod. Reste à voir si les gens implémentent ça sérieusement ou si c'est encore du "best practice" qu'on lit le dimanche et qu'on oublie le lundi.

OutilsTuto
1 source

Recevez l'essentiel de l'IA chaque jour

Une sélection éditoriale quotidienne, sans bruit. Directement dans votre boîte mail.

Recevez l'essentiel de l'IA chaque jour

Gratuit · 1 email le matin, rédigé par un humain · désinscription en un clic