Agents IA en production : MCP, tool use et orchestration

De l'assistant conversationnel à l'agent autonome

En 2024-2025, le marché a basculé. Les LLM ne sont plus des boîtes à dialogue : ils sont devenus le moteur de raisonnement d'agents capables d'appeler des outils, de manipuler des fichiers, d'interroger des bases de données et de coordonner d'autres agents. Anthropic a publié le Model Context Protocol (MCP) en novembre 2024, OpenAI a sorti l'Agents SDK et Responses API en 2025, et des frameworks comme LangGraph, CrewAI ou AutoGen convergent vers un même paradigme : un graphe d'états avec des nœuds qui exécutent des outils typés.

La question pour un CTO n'est plus si il faut adopter des agents, mais comment les industrialiser sans créer une dette technique invisible.

MCP : la fin du connecteur jetable

Avant MCP, chaque intégration LLM ↔ outil métier était une fonction custom, recompilée à chaque changement de modèle. MCP standardise ce contrat : un serveur MCP expose des tools, resources et prompts via JSON-RPC, et n'importe quel client compatible (Claude Desktop, Cursor, un agent maison) peut s'y connecter.

Concrètement, un serveur MCP pour exposer un système de tickets internes :

from mcp.server.fastmcp import FastMCP
import httpx

mcp = FastMCP("jira-bridge")

@mcp.tool()
async def search_issues(jql: str, limit: int = 20) -> list[dict]:
    """Recherche des tickets Jira via JQL."""
    async with httpx.AsyncClient() as client:
        r = await client.get(
            "https://company.atlassian.net/rest/api/3/search",
            params={"jql": jql, "maxResults": limit},
            headers={"Authorization": f"Bearer {TOKEN}"},
        )
        return r.json()["issues"]

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

L'intérêt n'est pas technique, il est organisationnel : une équipe plateforme maintient un catalogue de serveurs MCP (CRM, data warehouse, observabilité, RH), et chaque équipe produit branche son agent sans réinventer l'authentification ni la sérialisation.

Tool use : la discipline du schéma

Un agent qui hallucine un appel de fonction coûte cher. Trois pratiques réduisent drastiquement le taux d'erreur :

1. Schémas stricts : utiliser le strict: true d'OpenAI ou les schémas Pydantic avec Anthropic. Le modèle ne peut plus inventer un champ.
2. Outils idempotents : un create_invoice doit accepter un idempotency_key. Un agent qui retry ne doit pas dupliquer.
3. Outils de lecture séparés des outils d'écriture : on permet la lecture libre, on met les écritures derrière une validation humaine ou une politique OPA.

Orchestration : choisir son pattern

Tous les problèmes ne méritent pas un système multi-agents. Voici une grille de décision :

| Pattern | Quand l'utiliser | Outil typique | |---|---|---| | Single agent + tools | Tâches bornées, < 10 outils, latence critique | OpenAI Agents SDK, Claude + MCP | | Workflow déterministe | Étapes connues à l'avance, audit fort requis | LangGraph, Temporal | | Routeur + spécialistes | Domaines hétérogènes (support, finance, dev) | CrewAI, LangGraph supervisor | | Multi-agents collaboratifs | Recherche, génération de code complexe | AutoGen, Claude Code subagents |

La règle empirique : commencer par un single agent. N'ajouter un second agent que lorsque le prompt système dépasse 4-5k tokens ou que les outils entrent en conflit conceptuel (un agent qui doit à la fois écrire du code et négocier avec un client n'existe pas en RH, il ne devrait pas exister en IA).

Cas d'usage entreprise qui paient réellement

En mission chez nos clients, trois familles d'agents produisent un ROI mesurable en moins de 6 mois :

• Agent de triage support N1 : lit le ticket, interroge la KB via RAG, consulte l'historique client dans le CRM, propose une réponse ou escalade. Gain typique : 30-45 % de tickets résolus sans intervention humaine.
• Agent d'investigation SRE : sur alerte PagerDuty, corrèle logs (Loki/Datadog), métriques (Prometheus) et derniers déploiements (ArgoCD) pour rédiger un pré-rapport d'incident. Réduit le MTTR de 20-40 %.
• Agent de revue de conformité : lit un contrat, le compare au référentiel interne, sort un diff annoté. Remplace 2-3 heures de relecture juridique par 10 minutes de validation.

À l'inverse, les agents "assistant universel pour l'entreprise" échouent quasi-systématiquement : périmètre trop large, métriques de succès floues, données mal gouvernées.

Checklist de mise en production

• [ ] Observabilité : traces structurées (LangSmith, Langfuse, Arize Phoenix) avec coût, latence et tool calls par exécution
• [ ] Évaluation continue : un dataset de 50-200 cas dorés, rejoué à chaque changement de modèle ou de prompt
• [ ] Garde-fous : validation de schéma en sortie, filtre PII (Presidio), rate limiting par utilisateur
• [ ] Budget par session : kill switch à N tool calls ou X € de tokens
• [ ] Human-in-the-loop sur les actions destructrices (suppression, paiement, communication externe)
• [ ] Versioning des prompts comme du code (git, revue, rollback)
• [ ] Plan de fallback : si l'agent échoue, comment l'utilisateur termine sa tâche ?

À retenir

• MCP devient le standard de fait pour connecter des LLM à des systèmes d'entreprise : investir dans un catalogue de serveurs MCP internes est plus rentable que des intégrations point-à-point.
• Le single agent bien outillé bat le multi-agents dans 80 % des cas. Ajouter de la complexité n'est pas une stratégie.
• Les schémas stricts et l'idempotence transforment un POC instable en système de production.
• L'observabilité et l'évaluation ne sont pas optionnelles : sans elles, vous déployez à l'aveugle un système non déterministe.
• Les cas d'usage qui paient sont étroits, mesurables et adossés à un processus existant — pas les "assistants universels".