Aller au contenu

Traduction automatique

Cet article a été traduit automatiquement depuis la version originale en anglais.

Utilisation des outils par les agents IA en 2026 : MCP, CLI, Skills et exécution de code

Partie 3 de la série Engineering the Agentic Stack

La Partie 1 couvrait les boucles de raisonnement, la Partie 2 couvrait la mémoire. Cet article traite de l’utilisation des outils par les agents IA : comment les agents interagissent avec le monde, et pourquoi la conception des outils compte plus que la plupart des équipes ne l’imaginent.

L’histoire de l’outillage a changé en 2025–2026. MCP est devenu le standard de fait pour les services externes, mais les équipes de production se heurtent régulièrement à ses lacunes de sécurité et à sa surcharge en tokens. L’autre approche qui gagne en adoption est celle des agents qui écrivent et exécutent du code au lieu d’appeler des outils définis en JSON. Anthropic a mesuré une réduction de 98,7 % des tokens sur un workflow représentatif, et l’article CodeAct rapporte des taux de réussite des tâches supérieurs de 20 %.

Cet article compare l’appel d’outils JSON, MCP, Skills, les outils CLI et l’exécution de code, puis les relie aux principes de conception Agent-Computer Interface (ACI) que j’applique dans le Market Analyst Agent.

TL;DR : Il existe cinq modalités d’utilisation des outils par les agents IA, chacune avec son cas d’usage optimal. La stack pratique en 2026 : Skills pour l’expertise, CLI par défaut, MCP pour les services externes, exécution de code pour l’orchestration multi-étapes. Les principes de conception ACI issus de SWE-agent s’appliquent à toutes.

Cinq façons pour les agents IA d’utiliser des outils

Dans la Partie 1, j’ai montré comment les boucles de raisonnement des agents IA décident comment réfléchir. Les modalités d’outils décident comment agir. Il existe désormais cinq approches distinctes, chacune avec des compromis différents en coût de tokens, flexibilité et sécurité.

Panorama des modalités d’outils

1. Appel d’outils JSON — La base

Le schéma d’origine : vous définissez des schémas d’outils en JSON, le LLM émet des appels de fonction structurés, votre code les exécute. C’est bien compris et cela fonctionne correctement pour de petits ensembles d’outils.

# Traditional tool definition — each tool consumes ~550-1,400 tokens (Apideck benchmark)
tools = [
    {
        "name": "get_stock_price",
        "description": "Get the current stock price for a ticker symbol",
        "input_schema": {
            "type": "object",
            "properties": {
                "ticker": {"type": "string", "description": "Stock ticker (e.g., NVDA)"}
            },
            "required": ["ticker"]
        }
    }
]

Avec 5 à 10 outils, cela va. Le problème est le passage à l’échelle : chaque définition d’outil coûte 550 à 1 400 tokens. Avec 20 outils, vous dépensez 15 à 25K tokens avant même que l’agent ne commence à raisonner.

2. MCP — Le standard universel (avec réserves)

Le Model Context Protocol est le standard vers lequel la plupart des fournisseurs ont convergé. Anthropic l’a donné à la Linux Foundation au sein de l’Agentic AI Foundation (AAIF) en décembre 2025, cofondée avec OpenAI et Block, et soutenue par Google, Microsoft et AWS comme membres platinum. OpenAI a ajouté le support de MCP dans sa Responses API. Il existe désormais plus de 10 000 serveurs MCP actifs et plus de 97 M de téléchargements mensuels du SDK.

Là où MCP l’emporte : intégration SaaS multi-fournisseurs (Figma, Notion, Salesforce), gouvernance d’entreprise avec pistes d’audit, services sans équivalent CLI, et environnements nécessitant une orchestration OAuth. Pour ces cas d’usage, MCP est le choix évident.

L’histoire en production est plus compliquée que ne le suggèrent les chiffres affichés.

La surface de sécurité est le premier problème. Le Vulnerable MCP Project suit 50 vulnérabilités sur des serveurs MCP, dont 13 classées Critical, signalées par 32 chercheurs en sécurité. Les classes d’attaque couvrent l’injection de prompt, les échecs de validation d’entrée, les lacunes d’authentification et les failles de sécurité réseau. Le premier serveur MCP malveillant observé en conditions réelles est apparu en septembre 2025 : un package nommé postmark-mcp qui mettait en BCC chaque email sortant vers l’adresse d’un attaquant, affectant selon les estimations 300 à 500 organisations avant sa découverte.

L’empoisonnement d’outils est la classe d’attaque qui m’inquiète le plus. Invariant Labs a démontré que des outils MCP empoisonnés peuvent exfiltrer des données même lorsqu’ils ne sont jamais invoqués. Le simple fait que le modèle lise les métadonnées de l’outil suffit à déclencher l’attaque. Les benchmarks MCPTox, qui testent 20 agents LLM contre 45 serveurs MCP réels, ont trouvé des taux de réussite d’attaque allant jusqu’à 72,8 %.

La surcharge en tokens est le problème opérationnel. Une équipe exploitant des serveurs MCP pour GitHub, Slack et Sentry (~40 outils au total) a constaté 55 000 tokens de définitions de schémas injectées avant même qu’un utilisateur ne pose une question. Une autre a rapporté que 143 000 des 200 000 tokens disponibles (72 %) étaient consommés par les seules définitions d’outils.

Comparaison de la surcharge en tokens

Les mitigations fonctionnent, mais elles confirment le problème sous-jacent. Le Tool Search Tool d’Anthropic réduit la surcharge des schémas de 85 %. Le chargement dynamique d’outils (3 à 5 outils pertinents par tâche) permet une réduction de 96 %. Ce sont des contournements pour un protocole qui n’a pas été conçu avec les budgets de tokens en tête.

3. Skills (SKILL.md) — L’expertise, pas l’exécution

Fin 2025 a vu la standardisation des skills d’agents comme format ouvert (lancé en octobre 2025, publié comme standard ouvert en décembre 2025). La distinction est importante : les outils fournissent des capacités (ce que les agents peuvent faire), et les skills fournissent de l’expertise (ce que les agents savent sur la façon d’accomplir des tâches complexes).

Le standard SKILL.md définit une skill comme un fichier markdown avec un frontmatter YAML :

---
name: deploy
description: Deploy the application to production
argument-hint: "[environment]"
user-invocable: true
---
Deploy the application to the $0 environment (default: staging).
Steps:
1. Run the test suite
2. Build the production bundle
3. Deploy using the deploy script
4. Verify the deployment health check

Les skills utilisent la divulgation progressive : seules les métadonnées (~100 tokens pour le frontmatter YAML) sont chargées au démarrage, et les instructions complètes sont chargées lorsque la skill est activée. Comparez cela à MCP, où ~40 outils répartis sur des services typiques consomment ~55 000 tokens avant même que le raisonnement ne commence. L’adoption cross-platform en mars 2026 inclut Claude Code, OpenAI Codex CLI, Cursor, GitHub Copilot, Gemini CLI, Goose, Windsurf et Roo Code, une tendance que Victor Dibia a explorée dans son analyse du passage des outils vers des actions d’agents pilotées par le code.

Quand les skills l’emportent : transfert d’expertise métier, procédures complexes en plusieurs étapes, workflows récurrents comme les migrations de base de données ou les intégrations de paiement, et toute tâche où l’agent doit savoir comment faire plutôt que seulement quoi faire.

4. CLI/Bash — La renaissance Unix

Le terminal Unix s’est révélé être l’interface agent la plus efficace en tokens. Le calcul est sans appel : un manifeste d’outil CLI coûte environ 100 tokens, alors que les schémas du serveur MCP équivalent consomment plus de 50 000 tokens. C’est une différence de 4x à 32x mesurée par Scalekit sur 75 exécutions de benchmark (32x pour des tâches comme l’identification du langage d’un repo ou de sa licence).

Les modèles parlent nativement CLI. Leurs données d’entraînement incluent des milliards d’interactions terminal issues de Stack Overflow, de dépôts GitHub et de documentation. Ils comprennent nativement git, docker, kubectl, gh, curl et jq sans aucune définition de schéma.

Le guide d’Ugo Enyioha \"Writing CLI Tools That AI Agents Actually Want to Use\" a formalisé huit règles de conception :

  1. Une sortie structurée est obligatoire — prendre en charge --json
  2. Les codes de sortie sont le contrôle de flux — utiliser des codes distincts pour différents types d’erreurs
  3. Les commandes doivent être idempotentes
  4. Auto-documentation --help avec des exemples réalistes
  5. Concevoir pour la composabilité — --quiet pour les valeurs brutes, support de stdin
  6. Fournir les options --dry-run et --yes
  7. Prendre en charge l’inspection de version
  8. Gérer l’authentification via des variables d’environnement

Les compromis sont réels. CLI n’offre ni la sûreté de typage de MCP, ni l’orchestration OAuth intégrée, ni la découverte d’outils, ni la piste d’audit. Le schéma vers lequel la plupart des équipes convergent selon ce que j’observe : CLI par défaut pour le développement et les opérations locales, MCP pour l’intégration de services externes et la gouvernance d’entreprise.

5. Exécution de code — Le grand basculement

C’est le changement dans l’outillage des agents que je considère comme le plus important. Au lieu que le LLM émette un JSON structuré pour invoquer des fonctions prédéfinies une à une, l’agent écrit un script Python ou bash complet qui appelle plusieurs outils, traite les résultats avec des boucles et des conditions, puis ne renvoie que les résumés finaux dans le contexte du modèle.

Anthropic a formalisé cela avec Programmatic Tool Calling (PTC), désormais GA dans l’API Claude. Le fondement académique est l’article CodeAct (Wang et al., ICML 2024), qui a testé 17 LLM et montré que les actions basées sur le code obtenaient jusqu’à 20 % de réussite en plus sur les tâches et 30 % d’étapes en moins que les alternatives JSON.

Flux d’exécution de code

Les preuves en production :

  • Vercel a reconstruit son agent d0 text-to-SQL en supprimant 80 % de ses outils (de 15 à 2 : ExecuteCommand et ExecuteSQL). Le taux de réussite des tâches est passé de 80 % à 100 %, le temps d’exécution a chuté d’un facteur 3,5, et l’usage des tokens a baissé de 40 %. Leur formule : \"The best agents might be the ones with the fewest tools.\"

  • Cloudflare a développé \"Code Mode,\", qui permet aux agents d’écrire du TypeScript pour appeler leur API au lieu de définir des schémas d’outils, ce qui réduit la surcharge de contexte. Leur raisonnement : \"LLMs have an enormous amount of real-world TypeScript in their training set, but only a small set of contrived examples of tool calls.\"

Voici le schéma tiré de la documentation PTC d’Anthropic. L’appel d’outils traditionnel pour l’analyse des dépenses exige plus de 20 passes d’inférence séparées, une par membre d’équipe, avec toutes les données intermédiaires transitant par le contexte. Un workflow consommant ~150 000 tokens avec l’appel d’outils direct a été réimplémenté pour ~2 000 tokens, soit une réduction de 98,7 %. Avec l’exécution de code, l’agent écrit un script unique :

# Agent generates this code, executes in sandbox
import json
members = get_team_members("engineering")
over_budget = []
for m in members:
    expenses = get_expenses(m["id"], "Q3")
    total = sum(e["amount"] for e in expenses)
    if total > 5000:
        custom = get_custom_budget(m["id"])
        limit = custom["limit"] if custom else 5000
        if total > limit:
            over_budget.append({"name": m["name"], "spent": total, "limit": limit})
# Only this final summary returns to the LLM context
print(json.dumps(over_budget))

Le LLM ne voit que le résumé JSON final, pas les milliers de lignes de dépenses traitées dans la sandbox. L’efficacité en tokens, la composabilité native (boucles et conditions sont gratuites), une vraie gestion des erreurs (try/except au lieu d’un raisonnement en langage naturel sur les erreurs) et la confidentialité (les données sensibles restent dans la sandbox) s’améliorent toutes en même temps.

Quand l’appel d’outils JSON reste pertinent : opérations atomiques uniques, environnements sans infrastructure de sandboxing, modèles plus petits avec une génération de code faible, ou exigences d’audit nécessitant l’enregistrement de chaque invocation d’outil individuelle.

Tableau comparatif de l’appel d’outils pour agents IA

Dimension Appel d’outils JSON MCP Skills (SKILL.md) CLI/Bash Exécution de code (PTC)
Idéal pour Actions simples et uniques SaaS multi-fournisseurs Expertise métier Workflows dev, ops locales Orchestration multi-étapes
Surcharge en tokens Moyenne (schémas par requête) Très élevée (550-1 400/outil) Très faible (~100 tokens) Quasi nulle Faible (2 méta-outils)
Taux de réussite Référence Similaire à la référence N/A (couche d’expertise) Plus élevé pour les tâches natives CLI +20 % vs référence
Composabilité Faible (séquentiel) Faible (séquentiel) Élevée (connaissance procédurale) Élevée (pipes, chaînage) Très élevée (code natif)
Surface de sécurité Modérée Élevée (50+ CVE) Faible (basé prompt) Élevée (accès shell) Élevée (nécessite du sandboxing)
Complexité de setup Faible Moyenne (déploiement serveur) Très faible (markdown) Très faible (CLI existantes) Moyenne (infra sandbox)
Latence par action 1 inférence/appel 1 inférence + transport 0 (injection de contexte) 1 inférence/appel 1 passe pour N appels
Débogage Bon (E/S structurées) Modéré (couche transport) Bon (markdown lisible) Excellent (visible) Bon (code lisible)

Par composabilité, on entend ici la facilité avec laquelle plusieurs opérations s’enchaînent dans un workflow plus large. Faible signifie que chaque appel d’outil nécessite un aller-retour LLM séparé ; élevé signifie que la modalité prend en charge nativement l’enchaînement des résultats (pipes Unix, variables de code, étapes procédurales).

L’Agent-Computer Interface (ACI) pour les outils d’agents IA

Le terme \"Agent-Computer Interface\" (ACI) a été introduit par John Yang, Carlos E. Jimenez et leurs collègues de Princeton dans leur article SWE-agent (NeurIPS 2024). L’idée est simple : de la même façon que les humains bénéficient d’interfaces bien conçues (HCI), les agents LM constituent \"a new category of end users with their own needs and abilities, and would benefit from specially-built interfaces.\"

Les résultats d’ablation l’ont confirmé. SWE-agent avec son ACI complet a atteint 18,0 % sur SWE-bench Lite contre 7,3 % avec seulement un shell Linux standard, soit une amélioration de 10,7 points de pourcentage due à la seule conception d’interface. Le garde-fou de linting à lui seul représentait 3 points de pourcentage : 51,7 % des modifications de l’agent comportaient au moins une erreur détectée par le linter avant de pouvoir se propager.

Principes de conception ACI

Anthropic a adopté l’ACI comme concept fondamental dans son guide \"Building Effective Agents\", en le listant comme l’un des trois principes clés : \"Carefully craft your agent-computer interface through thorough tool documentation and testing.\" Leur conseil pratique : \"One rule of thumb is to think about how much effort goes into human-computer interfaces, and plan to invest just as much effort in creating good agent-computer interfaces.\"

Les quatre principes en pratique

1. Les actions doivent être simples et faciles à comprendre. L’erreur la plus courante consiste à encapsuler les endpoints d’API en un-à-un. Au lieu de list_users, list_events, create_event, implémentez schedule_event qui trouve les disponibilités et planifie en un seul appel. Au lieu de read_logs, implémentez search_logs qui renvoie uniquement les lignes pertinentes avec le contexte.

2. Les actions doivent être compactes et efficaces. Consolidez les opérations importantes en aussi peu d’actions que possible. Dans le Market Analyst Agent, je combine la récupération des prix avec des métriques de base dans un seul outil get_stock_snapshot plutôt que d’exiger des appels séparés pour le prix, le volume, la capitalisation boursière et le ratio PE.

3. Le feedback de l’environnement doit être informatif mais concis. Évitez de renvoyer du HTML brut ou des payloads API complets. Résolvez les identifiants cryptiques en noms sémantiques. Les tests d’Anthropic ont montré que l’ajout d’un enum response_format permettant aux agents de demander des réponses concises (~72 tokens) ou détaillées (~206 tokens) — soit une différence de coût de 3x en tokens — améliorait sensiblement les performances en conditions réelles.

4. Les garde-fous doivent limiter la propagation des erreurs. La détection automatique des erreurs aide les agents à reconnaître et corriger rapidement les erreurs. Dans SWE-agent, un éditeur de fichiers personnalisé avec linting intégré rejette automatiquement les erreurs de syntaxe, interceptant 51,7 % des erreurs d’édition de l’agent avant qu’elles ne se cumulent. J’applique le même principe dans le Market Analyst Agent en validant les arguments des outils avec des schémas Pydantic avant exécution :

from pydantic import BaseModel, Field, field_validator

class StockQuery(BaseModel):
    """Validated input for stock queries.

    Pydantic catches malformed tickers before the API call,
    preventing error propagation through the reasoning loop.
    """
    ticker: str = Field(description="Stock ticker symbol (e.g., NVDA)")
    period: str = Field(default="1mo", description="Time period: 1d, 5d, 1mo, 3mo, 1y")

    @field_validator("ticker")
    @classmethod
    def validate_ticker(cls, v: str) -> str:
        v = v.upper().strip()
        if not v.isalpha() or len(v) > 5:
            raise ValueError(f"Invalid ticker format: {v}")
        return v

    @field_validator("period")
    @classmethod
    def validate_period(cls, v: str) -> str:
        valid = {"1d", "5d", "1mo", "3mo", "6mo", "1y", "5y"}
        if v not in valid:
            raise ValueError(f"Invalid period: {v}. Must be one of {valid}")
        return v

Patterns de conception d’outils pour agents IA qui fonctionnent

Le guide d’Anthropic \"Writing effective tools for agents\" présente les outils comme \"a new kind of software reflecting a contract between deterministic systems and non-deterministic agents.\" Voici les patterns qui se sont cristallisés à partir de l’expérience de production.

Traiter les descriptions d’outils comme du prompt engineering

Les descriptions doivent faire au minimum 3 à 4 phrases, en couvrant quand utiliser l’outil, les paramètres requis versus optionnels, le format de sortie et les cas limites. Le namespacing avec des préfixes (asana_search, jira_search) a des \"non-trivial effects\" sur la précision de sélection des outils. Dans les expériences d’Anthropic, des descriptions d’outils optimisées pour Claude ont surpassé celles rédigées par des experts humains sur les benchmarks d’évaluation.

# Bad: vague, no context for when to use
tools = [{
    "name": "search",
    "description": "Search for items",
}]

# Good: specific, with input examples and edge cases
tools = [{
    "name": "stock_search_news",
    "description": (
        "Search for recent news articles about a specific stock or company. "
        "Use this tool when the user asks about recent events, earnings, "
        "announcements, or market-moving news for a specific ticker. "
        "Returns up to 10 articles sorted by relevance. "
        "For broad market news (not ticker-specific), use market_overview instead."
    ),
    "input_schema": {
        "type": "object",
        "properties": {
            "query": {
                "type": "string",
                "description": "Search query. Examples: 'NVDA earnings Q3 2025', 'Tesla delivery numbers'"
            },
            "max_results": {
                "type": "integer",
                "description": "Max articles to return (1-10, default 5)",
                "default": 5
            }
        },
        "required": ["query"]
    }
}]

Les tests internes ont montré que les exemples d’entrée (champ input_examples) amélioraient nettement la précision sur la gestion de paramètres complexes.

Renvoyer une sortie à fort signal et lisible par machine

Évitez les identifiants de bas niveau (uuid, mime_type). Résolvez les identifiants cryptiques en noms sémantiques. Structurez la réponse pour que l’agent puisse raisonner dessus sans parser de boilerplate :

# Bad: raw API response dumped to agent
def get_stock_price(ticker: str) -> dict:
    response = api.get(f"/v1/quotes/{ticker}")
    return response.json()  # 500+ tokens of nested JSON

# Good: high-signal summary the agent can immediately reason about
def get_stock_price(ticker: str) -> dict:
    data = api.get(f"/v1/quotes/{ticker}").json()
    return {
        "ticker": ticker,
        "price": data["regularMarketPrice"],
        "change_pct": round(data["regularMarketChangePercent"], 2),
        "volume": data["regularMarketVolume"],
        "market_cap_b": round(data["marketCap"] / 1e9, 1),
        "pe_ratio": data.get("trailingPE"),
        "summary": f"{ticker} at ${data['regularMarketPrice']:.2f} "
                   f"({'up' if data['regularMarketChangePercent'] > 0 else 'down'} "
                   f"{abs(data['regularMarketChangePercent']):.1f}%)"
    }

Concevoir la gestion des erreurs pour la résilience

Le pattern qui a tenu en production est une tolérance aux pannes en quatre couches :

  1. Retry avec backoff exponentiel pour les erreurs transitoires
  2. Chaînes de fallback de modèles pour les indisponibilités de fournisseurs
  3. Routage par classification d’erreurs — les erreurs transitoires sont rejouées, les erreurs récupérables par LLM sont renvoyées à l’agent avec contexte, les erreurs nécessitant un humain sont escaladées
  4. Reprise sur checkpoint pour survivre aux crashes

Les équipes rapportent une baisse des échecs irrécupérables de 23 % à moins de 2 % avec cette approche à quatre couches, comme documenté dans les patterns de résilience des outils d’Anthropic.

from tenacity import retry, stop_after_attempt, wait_exponential

@retry(
    stop=stop_after_attempt(3),
    wait=wait_exponential(multiplier=1, min=2, max=10),
)
def call_stock_api(ticker: str) -> dict:
    """Fetch stock data with automatic retry on transient failures.

    Layer 1: Exponential backoff handles rate limits and network blips.
    If all retries fail, the error propagates to the agent with
    enough context to decide whether to try a different approach.
    """
    response = httpx.get(
        f"https://api.example.com/v1/quotes/{ticker}",
        timeout=10.0,
    )
    response.raise_for_status()
    return response.json()

Application de ces patterns : le Market Analyst Agent

Voyons comment ces principes se combinent dans le Market Analyst Agent de la Partie 1.

Consolidation des outils

L’article de la Partie 1 montre la surface simplifiée à 5 outils après ce refactoring. Avant ce nettoyage, la conception initiale comportait plus de 10 outils : get_stock_price, get_company_metrics, get_market_cap, get_pe_ratio, get_volume, etc. Chacun était un simple wrapper autour d’un endpoint d’API. L’agent devait raisonner sur la combinaison à appeler pour chaque requête.

J’ai consolidé cela en 5 outils de haut niveau, conformément au principe ACI d’actions compactes et efficaces :

Avant (10+ outils) Après (5 outils) Pourquoi
get_stock_price + get_company_metrics + get_pe_ratio get_stock_snapshot Un seul appel renvoie tout le nécessaire pour l’analyse de base
get_price_history + get_volume_history get_price_history Combiné avec période et indicateurs configurables
search_news + search_press_releases search_news Recherche unifiée avec filtrage par source
search_competitors + get_sector_data search_competitors Renvoie les concurrents avec des métriques relatives
get_financials + get_balance_sheet + get_cash_flow get_financials Unifié avec paramètre statement_type

Cela a réduit sensiblement la surcharge des schémas d’outils et rendu la sélection d’outils par l’agent plus fiable, car il y a moins de choix ambigus à faire.

Sorties structurées pour les résultats d’outils

Chaque outil du Market Analyst Agent renvoie une réponse validée par Pydantic. Cela applique le principe ACI de garde-fous à la frontière de l’outil :

class StockSnapshot(BaseModel):
    """Structured tool response — the agent never sees raw API noise."""
    ticker: str
    price: float
    change_pct: float
    volume: int
    market_cap_b: float
    pe_ratio: float | None
    summary: str  # Human-readable one-liner for direct use in reports

class NewsResult(BaseModel):
    """Each news item is pre-processed for agent consumption."""
    headline: str
    source: str
    date: str
    relevance_score: float  # Pre-ranked so the agent doesn't waste tokens sorting
    key_points: list[str]  # Extracted by the tool, not the agent

Le champ summary est celui qui compte le plus. Il fournit à l’agent une chaîne prête à l’emploi qui peut être insérée directement dans un rapport sans traitement supplémentaire. Les key_points dans NewsResult sont extraits côté serveur, ce qui évite à l’agent de dépenser des tokens d’inférence à parser les corps d’articles.

Compromis et considérations

Au-delà des réserves spécifiques à chaque modalité ci-dessus, quelques préoccupations transverses orientent le choix :

  • Le coût opérationnel varie selon la dimension. L’exécution de code économise des tokens mais ajoute une latence de cold start de sandbox. MCP fait gagner du temps de développement pour les intégrations SaaS mais ajoute la surcharge du déploiement serveur. CLI est gratuite au démarrage mais plus difficile à gouverner à grande échelle. Optimisez pour votre véritable goulot d’étranglement, qu’il s’agisse du coût en tokens, de la latence ou de la complexité opérationnelle.

  • Les compétences de l’équipe comptent. L’exécution de code suppose que vos agents (et les modèles qui les sous-tendent) peuvent générer du Python ou du TypeScript fiable. CLI suppose une familiarité avec les conventions Unix. MCP exige de comprendre les protocoles de transport et les flows OAuth. Faites correspondre la modalité aux points forts de votre équipe.

  • La consolidation des outils peut aller trop loin. Si vous fusionnez tout en un méga-outil, l’espace des paramètres devient trop complexe pour que l’agent puisse s’y retrouver. Le bon compromis est de 5 à 10 outils bien cadrés pour la plupart des systèmes d’agents.

  • Les skills sont basées sur des prompts, pas imposées. Une skill correspond à des instructions que l’agent devrait suivre, pas à des garde-fous qu’il doit suivre. Pour les workflows critiques, combinez les skills avec une validation déterministe.

  • Les exigences d’audit influencent le choix. Si vous avez besoin d’un journal complet de chaque invocation d’outil et de son résultat, MCP et l’appel d’outils JSON fournissent des pistes d’audit structurées nativement. L’exécution de code produit un script et sa sortie, ce qui est utile mais plus difficile à décomposer en actions individuelles pour le reporting de conformité.

Où va l’ergonomie des outils

Trois directions méritent d’être suivies.

La première est le tool RAG pour le passage à l’échelle. Quand les ensembles d’outils atteignent des centaines ou des milliers d’éléments, la précision de sélection naïve des outils se dégrade jusqu’à 13,62 %. L’article RAG-MCP a montré qu’appliquer la retrieval-augmented generation à la sélection d’outils (indexation des descriptions d’outils dans une base vectorielle et récupération uniquement des outils pertinents par requête) permet d’atteindre 43,13 % de précision, soit une amélioration de 3,2x, tout en réduisant d’environ 50 % les tokens du prompt.

La deuxième est celle des agents qui créent leurs propres outils. Le framework LATM (\"LLMs As Tool Makers\") a établi un paradigme en deux phases dans lequel un LLM puissant crée des fonctions Python réutilisables et un LLM léger les utilise. ToolMaker (ACL 2025) transforme de façon autonome des dépôts GitHub en outils compatibles LLM avec un taux de réussite de 80 %. La frontière se déplace de l’usage des outils vers la création d’outils, puis vers la gestion de bibliothèques d’outils.

La troisième est la stack à double protocole A2A + MCP. Le protocole Agent2Agent (A2A) de Google traite ce que MCP ne peut pas traiter : la communication agent-à-agent. MCP gère l’intégration agent-outil ; A2A gère la découverte entre agents, la négociation et la délégation de tâches. La formule combinée : construisez avec votre framework, équipez avec MCP, communiquez avec A2A.

Points clés à retenir

  1. L’utilisation des outils comporte cinq modalités distinctes, chacune avec un cas d’usage idéal clair. Ne prenez pas MCP par défaut pour tout ; alignez la modalité sur la tâche.

  2. Le remplacement de l’appel d’outils JSON par l’exécution de code est le plus grand changement dans l’outillage des agents. Le PTC d’Anthropic, la réduction d’outils de Vercel et le Code Mode de Cloudflare convergent tous vers la même idée : laisser les agents écrire du code au lieu d’appeler des schémas.

  3. La surcharge en tokens est le goulot d’étranglement opérationnel. Plus de 55K tokens pour ~40 outils MCP contre ~100 tokens pour des manifests CLI, ce n’est pas une différence marginale. C’est la différence entre un agent qui dispose de 65 % versus 95 % de son contexte pour raisonner.

  4. Les principes de conception ACI comptent plus que le protocole. SWE-agent a montré que la seule conception d’interface représentait 10,7 points de pourcentage sur les benchmarks. Actions simples, feedback concis et garde-fous intégrés s’appliquent que vous utilisiez MCP, CLI ou l’exécution de code.

  5. Consolidez les outils de manière agressive. Cinq outils bien conçus surpassent vingt outils granulaires. Chaque outil est un choix que vous forcez le modèle à faire ; réduisez donc l’espace de décision.

  6. Traitez les descriptions d’outils comme du prompt engineering. Les exemples d’entrée améliorent nettement la précision. Les descriptions optimisées pour Claude surpassent celles écrites par des experts humains. Investissez autant d’effort dans l’UX des outils que dans l’UX humaine.

  7. La stack pratique en 2026 est Skills + CLI + MCP + exécution de code, superposée selon le cas d’usage. Skills pour l’expertise, CLI pour les ops locales, MCP pour les services externes, exécution de code pour l’orchestration multi-étapes.

Et ensuite

Dans la Partie 4, AI Agent Security in 2026, je couvre la couche de politique autour des agents : comment prévenir les actions destructrices, les appels d’outils hallucinés et les fuites de données sensibles via les réponses d’outils.

Références

Articles scientifiques

Ingénierie Anthropic

Études de cas industrie

Sécurité

Conception CLI

Projet de démonstration

Le code complet du Market Analyst Agent, y compris les conceptions d’outils décrites dans cet article, est sur GitHub.

Série : Engineering the Agentic Stack