Agents IA en entreprise : MCP, tool use et orchestration

L'année 2024 a marqué le passage des assistants conversationnels aux agents autonomes capables d'invoquer des outils, de raisonner sur plusieurs étapes et de collaborer. En 2025, la question n'est plus est-ce que ça marche, mais comment industrialiser. Voici un état des lieux pragmatique des briques techniques et des patterns d'orchestration qui tiennent la route en production.

Du tool use au protocole MCP

Le tool use (ou function calling) est devenu un standard depuis les API d'OpenAI, Anthropic et Google. Le modèle reçoit un schéma JSON des fonctions disponibles et décide quand les appeler. Le problème : chaque intégration est ad hoc, chaque équipe réinvente ses connecteurs vers Jira, GitHub, Snowflake ou un ERP interne.

C'est précisément ce que résout le Model Context Protocol (MCP), publié par Anthropic fin 2024 et adopté par OpenAI, Google DeepMind et plusieurs IDE (Cursor, Zed, Windsurf) en 2025. MCP standardise la façon dont un agent découvre et appelle des outils, ressources et prompts exposés par un serveur tiers.

{
  "name": "search_tickets",
  "description": "Recherche des tickets Jira par projet et statut",
  "inputSchema": {
    "type": "object",
    "properties": {
      "project": {"type": "string"},
      "status": {"type": "string", "enum": ["open", "in_progress", "done"]}
    },
    "required": ["project"]
  }
}

Concrètement, un serveur MCP pour votre SI interne devient réutilisable par n'importe quel client compatible : Claude Desktop, un agent LangGraph, un workflow n8n ou votre propre orchestrateur. Fini les N×M intégrations.

Orchestration : single-agent, multi-agent, ou workflow ?

La hype autour des systèmes multi-agents (CrewAI, AutoGen, Swarm d'OpenAI) masque une réalité observée chez nos clients : un agent unique bien outillé suffit dans 70 % des cas. Le multi-agent introduit de la latence, des coûts en tokens et des modes de défaillance difficiles à déboguer.

Voici une grille de décision testée sur plusieurs projets :

| Pattern | Quand l'utiliser | Outils typiques | |---|---|---| | Workflow déterministe | Étapes connues, peu de branchement | LangGraph, Temporal, Prefect | | Single-agent + tools | Tâches variées, raisonnement court | SDK Anthropic, OpenAI Agents SDK | | Multi-agent hiérarchique | Domaines experts distincts (code, data, rédaction) | CrewAI, AutoGen, LangGraph Supervisor | | Multi-agent collaboratif | Recherche ouverte, exploration parallèle | OpenAI Swarm, AutoGen GroupChat |

Le pattern supervisor-worker de LangGraph est particulièrement robuste : un agent superviseur route les sous-tâches vers des workers spécialisés, chacun avec son propre jeu d'outils MCP. On garde la traçabilité d'un workflow tout en bénéficiant de la flexibilité du LLM pour le routage.

Cas d'usage entreprise qui livrent vraiment

En 2025, les déploiements qui passent en production partagent un trait commun : un périmètre étroit et mesurable. Quelques exemples concrets issus de missions DCT :

• Triage de tickets support N1 : un agent lit le ticket, interroge la base de connaissances via MCP, propose une réponse et l'envoie en revue humaine. Gain mesuré : –40 % de temps moyen de traitement, taux d'acceptation des suggestions à 68 %.
• Revue de Pull Requests : agent connecté à GitHub + SonarQube via MCP, qui commente les PR sur des règles métier (conventions internes, dette technique ciblée). Complémentaire à Copilot, pas concurrent.
• Préparation de devis : agent qui croise CRM, catalogue produit et historique client pour pré-remplir un devis. L'humain valide et ajuste.
• Analyse de logs et runbook automation : agent SRE qui corrèle alertes Datadog, logs Loki et runbooks Confluence pour proposer un diagnostic.

Le point commun : l'humain reste dans la boucle sur les décisions à fort impact. Les agents 100 % autonomes en production restent l'exception.

Checklist de mise en production

Avant de pousser un agent en prod, vérifiez ces points :

• [ ] Observabilité : tracing complet des appels LLM et outils (LangSmith, Langfuse, Arize Phoenix)
• [ ] Budget de tokens et de temps : timeout dur, max iterations, alerte sur dépassement
• [ ] Sandboxing des outils : les actions destructives (DELETE, write) passent par une couche d'approbation
• [ ] Évaluations automatisées : jeu de cas de test avec scoring (LLM-as-judge + métriques déterministes)
• [ ] Garde-fous de sécurité : prompt injection testée (cf. OWASP Top 10 for LLM Applications), permissions minimales sur chaque serveur MCP
• [ ] Fallback humain : un chemin d'escalade clair quand l'agent échoue ou hésite
• [ ] Versioning des prompts et tools : traiter les prompts comme du code (revue, tests, déploiement)

Le coût réel

Un agent multi-étapes consomme facilement 20 à 50 fois plus de tokens qu'un simple chat. Sur Claude Sonnet 4.5 ou GPT-4.1, un workflow de triage peut coûter 0,05 à 0,30 € par exécution. À 10 000 exécutions/jour, cela représente 1 500 à 9 000 €/mois. La mise en cache des prompts (jusqu'à 90 % d'économies sur les parties statiques) et le routage vers des modèles plus petits (Haiku, GPT-4.1 mini) pour les sous-tâches simples deviennent des optimisations indispensables.

À retenir

• MCP est en train de devenir le standard de facto pour connecter agents et systèmes d'entreprise : investir maintenant dans des serveurs MCP internes paie sur la durée.
• Commencez single-agent, passez au multi-agent uniquement quand la séparation des rôles apporte une valeur mesurable.
• L'observabilité n'est pas optionnelle : sans tracing détaillé, déboguer un agent en production est impossible.
• Cadrez serré : les cas d'usage qui réussissent ont un périmètre étroit, des métriques claires et un humain dans la boucle.
• Surveillez les coûts dès le POC : caching, model routing et limites d'itérations sont des leviers de rentabilité, pas des optimisations tardives.