Agents IA en production : du MCP à l'orchestration

Depuis fin 2024, les agents IA sont sortis de la démo Twitter pour atterrir dans des backlogs sérieux. Anthropic a publié le Model Context Protocol (MCP) en novembre 2024, OpenAI a suivi avec les Assistants API puis les Agents SDK en 2025, et des frameworks comme LangGraph, CrewAI ou AutoGen stabilisent leurs API. Le sujet n'est plus "est-ce que ça marche ?" mais "comment on industrialise sans se tirer une balle dans le pied ?".

Cet article fait le point sur les briques qui comptent vraiment et sur les patterns qu'on voit tenir en production chez nos clients.

Ce qu'est vraiment un agent (et ce qu'il n'est pas)

Un agent LLM, au sens strict, c'est une boucle : le modèle décide d'une action (appeler un outil, répondre, déléguer), observe le résultat, puis recommence jusqu'à atteindre un objectif. Rien de magique — c'est un while avec un LLM comme routeur.

Ce qui change en 2025, c'est la qualité du tool use (Claude 3.5 Sonnet, GPT-4.1, Gemini 2.5) et la standardisation des interfaces. Un agent utile en entreprise combine généralement quatre couches :

1. Un LLM raisonneur (Claude, GPT, Llama 3.3, Mistral Large)
2. Des outils (API internes, recherche vectorielle, exécution de code)
3. Une mémoire (court terme = contexte, long terme = vector store ou KV store)
4. Un orchestrateur (LangGraph, Temporal, un simple state machine maison)

MCP : pourquoi ça change la donne

Avant MCP, chaque framework avait sa propre convention d'outils. Résultat : un connecteur Jira écrit pour LangChain ne marchait pas dans AutoGen. MCP standardise le contrat entre un agent (le client) et une source de contexte ou un outil (le serveur) via JSON-RPC.

Concrètement, un serveur MCP expose trois primitives : resources (données lisibles), tools (actions) et prompts (templates). Claude Desktop, Cursor, Zed et désormais les Agents SDK d'OpenAI parlent MCP nativement.

Exemple minimal d'un serveur MCP en Python exposant un outil de recherche interne :

from mcp.server.fastmcp import FastMCP

mcp = FastMCP("dct-knowledge")

@mcp.tool()
def search_confluence(query: str, space: str = "ENG") -> list[dict]:
    """Recherche dans Confluence et retourne les 5 meilleurs résultats."""
    results = confluence_client.cql(
        f'text ~ "{query}" AND space = "{space}"', limit=5
    )
    return [{"title": r.title, "url": r.url, "excerpt": r.excerpt} for r in results]

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

L'intérêt pour un DSI : un seul connecteur réutilisable par Claude Desktop pour les analystes, par un agent backend pour l'automatisation, et par l'IDE des développeurs.

Mono-agent vs multi-agent : choisir sans religion

Le réflexe est de multiplier les agents ("un pour le PM, un pour le dev, un pour le QA"). Dans la pratique, un agent unique avec de bons outils bat souvent une équipe de cinq agents bavards. Anthropic l'a documenté dans son retour d'expérience sur Claude Code : moins d'agents, plus de contexte partagé.

| Pattern | Quand l'utiliser | Risque principal | |---|---|---| | Single-agent + tools | Tâches < 20 étapes, domaine homogène | Context window saturé | | Orchestrator-workers | Tâches parallélisables (veille, crawl) | Coût token × N | | Hiérarchique (supervisor) | Workflows métier multi-domaines | Latence, debug difficile | | Swarm / handoff | Support client, routage | Boucles infinies |

Règle empirique : commencer mono-agent, passer au multi-agent seulement quand on identifie des frontières de contexte claires (sécurité, domaine métier, coût).

Cas d'usage qui passent en production

Ce qu'on voit réellement déployé aujourd'hui, au-delà des chatbots :

• Triage de tickets L1/L2 : un agent lit le ticket, consulte la KB via MCP, propose une résolution ou escalade. ROI mesuré : 30-40 % de tickets clôturés sans intervention humaine.
• Revue de code assistée : agent branché sur GitHub Actions, qui analyse les diffs, lance les tests et commente les PR. Outils : Claude Code, Cursor Background Agents, Aider.
• Data engineering conversationnel : text-to-SQL + exécution sandbox + visualisation. Patterns LangGraph avec human-in-the-loop sur les requêtes destructives.
• Onboarding RH/IT : orchestration de la création de comptes (Okta, Google Workspace, Jira) à partir d'une fiche d'arrivée. Temporal pour la durabilité des workflows.

La checklist avant de mettre un agent en prod

• [ ] Budget tokens plafonné par run (max_iterations, max_tokens_total)
• [ ] Sandbox pour l'exécution de code (Firecracker, E2B, Daytona)
• [ ] Allow-list stricte des outils et des domaines réseau
• [ ] Human-in-the-loop sur toute action irréversible (DELETE, paiement, email externe)
• [ ] Traces structurées (LangSmith, Langfuse, Arize) avec replay
• [ ] Évaluations automatisées sur un dataset figé avant chaque déploiement
• [ ] Kill switch et rate limiting au niveau du gateway LLM
• [ ] Audit log immuable des tool calls (compliance, forensics)

Le vrai coût caché : l'évaluation

Le piège classique : un agent qui marche sur 10 cas de test et dérape sur le 11ᵉ en production. Sans eval harness, vous naviguez à vue. Minimum viable : un jeu de 50 à 200 cas annotés, une métrique par étape (tool choice correct, argument correct, résultat final correct), et un run automatique en CI. Des frameworks comme Braintrust, Langfuse ou Promptfoo font le job.

Comptez 15 à 25 % de l'effort total du projet sur l'évaluation. C'est ce qui distingue un POC d'un produit.

À retenir

• MCP est en train de devenir le USB-C des agents : investissez dans des serveurs MCP réutilisables plutôt que dans des intégrations spécifiques à un framework.
• Commencez mono-agent avec des outils bien conçus ; le multi-agent se justifie par des frontières métier, pas par esthétique.
• Les garde-fous (sandbox, allow-list, HITL) ne sont pas optionnels dès qu'un agent touche à des systèmes de production.
• L'évaluation continue est le vrai différenciant entre une démo et un produit fiable.
• Mesurez le coût par tâche résolue, pas le coût par token : c'est la seule métrique qui parle à un COMEX.