Agents IA en production : MCP, orchestration et réalité terrain

Depuis fin 2024, les agents IA sont passés du statut de démo Twitter à celui de composant logiciel déployé en production. Anthropic a publié le Model Context Protocol (MCP) en novembre 2024, OpenAI a sorti l'Agents SDK et la Responses API en 2025, et LangGraph s'est imposé comme standard de facto pour les graphes d'agents. Le paysage se stabilise. Voici ce qui marche réellement en entreprise, et ce qui ne marche pas.

MCP : la fin du tool use propriétaire

Avant MCP, chaque agent réimplémentait ses connecteurs : un wrapper pour Jira, un autre pour Snowflake, un troisième pour GitHub. Résultat : duplication, dette technique, et zéro réutilisation entre équipes.

MCP standardise la communication entre un client LLM (Claude Desktop, Cursor, votre agent maison) et des serveurs exposant outils, ressources et prompts. Le protocole est transport-agnostique (stdio, HTTP/SSE) et déjà supporté nativement par Claude, OpenAI, et la plupart des frameworks (LangGraph, LlamaIndex, Pydantic AI).

Concrètement, un serveur MCP minimal en Python avec le SDK officiel :

from mcp.server.fastmcp import FastMCP

mcp = FastMCP("jira-bridge")

@mcp.tool()
def create_ticket(project: str, title: str, description: str) -> dict:
    """Crée un ticket Jira et retourne son ID."""
    # Appel API Jira
    return {"id": "PROJ-1234", "url": "..."}

@mcp.resource("jira://projects/{key}")
def get_project(key: str) -> str:
    return f"Projet {key} : ..."

if __name__ == "__main__":
    mcp.run()

Un même serveur Jira peut alors être branché à Claude Desktop pour vos PMs, à un agent de triage automatique et à Cursor pour vos devs. Une seule base de code à maintenir.

Tool use : ce que personne ne dit

Le tool calling fonctionne bien jusqu'à environ 15-20 outils. Au-delà, la précision chute brutalement : le modèle hallucine des arguments, choisit le mauvais outil, ou enchaîne des appels redondants. Trois patterns pour repousser cette limite :

1. Tool filtering dynamique : on ne présente au LLM que les outils pertinents pour l'étape courante (RAG sur la description des outils).
2. Hiérarchisation : un outil search_tools(query) qui retourne les N outils pertinents, puis un second tour pour l'appel réel.
3. Sous-agents spécialisés : un agent par domaine fonctionnel, chacun avec sa propre toolbox.

Le troisième point nous amène à l'orchestration.

Patterns d'orchestration multi-agents

Quatre patterns dominent en 2025. Voici quand utiliser quoi :

| Pattern | Quand l'utiliser | Outil typique | Coût relatif | |---|---|---|---| | Single-agent + tools | < 20 outils, workflow linéaire | OpenAI Agents SDK | € | | Supervisor / handoff | Domaines disjoints (support, ventes, tech) | LangGraph, Agents SDK | €€ | | Hierarchical (manager → workers) | Tâches décomposables, parallélisables | LangGraph, CrewAI | €€€ | | Swarm / peer-to-peer | Recherche, brainstorming | AutoGen | €€€€ |

Mon retour de terrain : commencez toujours par un single-agent. 70 % des cas d'usage entreprise n'ont pas besoin de plus. Le multi-agent introduit de la latence (chaque handoff = un appel LLM supplémentaire), des coûts en tokens qui explosent, et une observabilité bien plus complexe.

Cas d'usage qui livrent en 2025

Les déploiements rentables que nous voyons chez nos clients tournent autour de quatre familles :

• Triage et routage : classification de tickets support, qualification de leads, dispatch d'incidents. ROI rapide, risque faible.
• Recherche et synthèse interne : agent qui interroge Confluence, Notion, SharePoint et Slack via MCP, puis produit une réponse sourcée. Remplace 30-40 % des questions RH/IT répétitives.
• Code agents : revue de PR automatique, génération de tests, migration de code (ex : Java 8 → 21). Cursor, Claude Code et Devin sont matures.
• Workflows back-office : rapprochement de factures, extraction de données contractuelles, mise à jour CRM. Souvent couplé à un humain en validation.

Les cas qui échouent encore : agents "autonomes" sans humain dans la boucle sur des décisions à fort enjeu, agents commerciaux ouverts au client final (risque réputationnel), et tout ce qui requiert un raisonnement multi-étapes sur > 30 minutes.

Checklist avant de mettre un agent en production

• [ ] Observabilité : tracing complet (LangSmith, Langfuse, Arize). Sans traces, vous ne déboguerez rien.
• [ ] Évals automatisées : dataset de 50-200 cas réels, rejoués à chaque changement de prompt ou de modèle.
• [ ] Guardrails : validation des entrées/sorties (Pydantic, Guardrails AI), détection de prompt injection sur les outils sensibles.
• [ ] Budget tokens : limite dure par session et par utilisateur. Un agent en boucle peut coûter 50 € en une nuit.
• [ ] Human-in-the-loop sur les actions irréversibles (envoi d'email, modification DB, paiement).
• [ ] Fallback déterministe : si l'agent échoue 3 fois, on bascule sur un workflow classique ou un humain.
• [ ] Versioning des prompts et des outils : traités comme du code, pas comme de la config.

À retenir

• MCP est devenu le standard de fait pour exposer outils et données aux LLMs. Investir dans des serveurs MCP internes est rentable dès le second agent.
• Single-agent d'abord, multi-agent ensuite : la complexité d'orchestration se paie en latence, coût et debug.
• Le tool use décroche au-delà de ~20 outils : filtrage dynamique ou sous-agents spécialisés deviennent nécessaires.
• Pas de production sans évals ni tracing : un agent sans observabilité est une bombe à retardement.
• Les cas d'usage rentables sont ennuyeux : triage, recherche interne, code, back-office. Les démos spectaculaires restent rarement en production.