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

Le passage à l'âge adulte des agents IA

En 2024, les démos d'agents autonomes impressionnaient sur Twitter mais s'effondraient en production. En 2025, la donne a changé : Anthropic a publié le Model Context Protocol (MCP), OpenAI a stabilisé son Agents SDK, et des frameworks comme LangGraph, CrewAI ou PydanticAI ont mûri. Les équipes qui livrent des agents en production ne misent plus sur un LLM monolithique avec un prompt géant : elles assemblent des composants, contraignent les sorties et instrumentent tout.

Voici ce qui fonctionne aujourd'hui dans nos missions chez DCT, et ce qui reste un piège.

MCP : le port USB-C des LLM

Le Model Context Protocol standardise la façon dont un modèle accède à des outils, des sources de données et des prompts externes. Avant MCP, chaque équipe réimplémentait son propre système de function calling avec un schéma propriétaire. Résultat : du code jetable à chaque changement de modèle.

Avec MCP, un serveur expose des tools, resources et prompts via un protocole JSON-RPC. N'importe quel client compatible (Claude Desktop, Cursor, votre propre orchestrateur) peut s'y connecter.

from mcp.server.fastmcp import FastMCP

mcp = FastMCP("crm-server")

@mcp.tool()
def get_customer(customer_id: str) -> dict:
    """Récupère les informations d'un client depuis le CRM."""
    return crm_client.fetch(customer_id)

@mcp.tool()
def create_ticket(customer_id: str, subject: str, priority: str) -> str:
    """Crée un ticket de support. priority: low|medium|high"""
    return zendesk.create(customer_id, subject, priority)

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

L'intérêt concret : un même serveur MCP "CRM" est consommé par votre agent de support, votre copilote commercial et votre IDE pour les développeurs. Une seule surface d'audit, un seul endroit pour gérer les permissions.

Tool use : la qualité prime sur la quantité

Une erreur fréquente : donner 40 outils à un agent. Au-delà de 15-20 outils, la précision de sélection chute fortement, même avec Claude Sonnet 4.5 ou GPT-4.1. Trois patterns qui marchent :

• Hierarchical tool use : l'agent appelle d'abord un outil search_tools(query) qui ne retourne que les 3-5 outils pertinents.
• Tool namespacing : préfixer (crm.get_customer, billing.create_invoice) pour aider le modèle à raisonner par domaine.
• Schémas stricts : utiliser Pydantic ou Zod pour valider chaque argument avant exécution. Un argument hallucinant un UUID inexistant doit échouer côté code, pas côté base de données.

Orchestration multi-agents : choisir son pattern

Tous les problèmes ne nécessitent pas une nuée d'agents. Voici les quatre patterns que nous rencontrons le plus, et quand les utiliser :

| Pattern | Quand l'utiliser | Outil typique | Risque | |---|---|---|---| | Single agent + tools | Tâches < 10 étapes, domaine cadré | OpenAI Agents SDK | Aucun, c'est la bonne base | | Supervisor / workers | Sous-tâches parallélisables et indépendantes | LangGraph, CrewAI | Coût en tokens élevé | | Sequential pipeline | Workflow déterministe avec étapes IA | Temporal + LLM | Sur-ingénierie si IA seule suffit | | Network (peer-to-peer) | Recherche ouverte, exploration | AutoGen | Boucles infinies, dérive |

Notre règle empirique : commencer single-agent, mesurer, puis décomposer uniquement si la latence ou la qualité l'imposent. Un graph LangGraph à 7 nœuds résout rarement ce qu'un bon prompt avec 8 outils ne résout pas.

Cas d'usage entreprise qui livrent vraiment

Les déploiements qui passent en production en 2025 partagent une caractéristique : ils sont étroitement cadrés.

1. Triage de tickets support N1 : un agent classe, enrichit avec le contexte client (via MCP CRM), répond aux cas simples, escalade le reste. ROI typique : 30-45% de tickets résolus sans humain, sur du périmètre bien défini.
2. Revue de Pull Requests : agents type CodeRabbit ou implémentations maison qui commentent style, sécurité et tests manquants. Économise 15-20 min par PR sur des bases > 50 dev.
3. Préparation de réunions commerciales : agrégation CRM + LinkedIn + actualités + historique d'échanges, livrée en briefing 5 min avant le call.
4. Réconciliation comptable : matching factures/paiements avec règles métier, l'agent ne traite que les cas non-déterministes.

Ce qui ne marche pas encore de façon fiable : agents autonomes long-running (> 1h) sans humain dans la boucle, génération de code de bout en bout sur des codebases complexes, négociation contractuelle.

Checklist de mise en production

• [ ] Chaque outil retourne des erreurs structurées (pas de stack traces brutes au LLM)
• [ ] Limite stricte de tokens et d'itérations par run (max_steps=15 typiquement)
• [ ] Tracing avec LangSmith, Langfuse ou OpenTelemetry GenAI
• [ ] Évaluations automatisées sur un dataset d'au moins 50 cas réels avant chaque déploiement
• [ ] Garde-fous d'autorisation : RBAC appliqué côté serveur MCP, pas côté prompt
• [ ] Mode dry-run pour les outils à effet de bord (envoi d'email, paiement)
• [ ] Budget de coût par session monitoré, alerte si dépassement
• [ ] Plan de rollback : feature flag par tenant, possibilité de couper l'agent en 30 secondes

À retenir

• MCP devient le standard de fait pour connecter LLM et systèmes internes ; commencer à l'adopter dès maintenant évite une dette d'intégration.
• Le multi-agent est rarement la bonne première réponse : un single-agent avec 10-15 outils bien conçus surpasse souvent une orchestration complexe.
• Les cas d'usage qui livrent sont étroits et instrumentés ; les agents "généralistes autonomes" restent expérimentaux.
• L'observabilité (tracing, evals, coûts) n'est pas optionnelle : sans elle, vous pilotez à l'aveugle un système non-déterministe.
• Les garde-fous vivent dans le code, pas dans le prompt système : autorisation, validation et limites doivent être appliquées par votre infrastructure.