Claude Agent SDK et MCP : déployer des agents Anthropic en entreprise

Claude (Anthropic) s'est imposé comme le LLM de référence pour les agents IA en entreprise. Pas seulement pour la qualité de ses réponses, mais pour trois raisons structurelles : un raisonnement nativement supérieur sur les tâches complexes grâce à l'extended thinking, une fenêtre de contexte massive de 200K tokens qui permet d'ingérer des documents entiers sans chunking, et surtout MCP (Model Context Protocol) — le standard ouvert qui permet de connecter un agent à n'importe quel outil métier sans intégration propriétaire.

Ce guide est le premier en français à couvrir le déploiement complet d'agents Claude en entreprise. Architecture, code, MCP servers, extended thinking, computer use, checklist de production : tout ce qu'un ingénieur IA a besoin pour passer du prototype au déploiement.

Pourquoi Claude pour les agents IA entreprise

Extended thinking : le raisonnement en profondeur

Claude peut "réfléchir" avant de répondre. Ce n'est pas un gadget : l'extended thinking active une chaîne de raisonnement interne avant de produire la réponse finale. Pour les tâches enterprise, c'est un changement fondamental.

Concrètement, quand un agent doit analyser un contrat de 80 pages pour identifier les clauses de résiliation anticipée, comparer les conditions avec un référentiel interne, puis produire une recommandation argumentée — le raisonnement linéaire ne suffit pas. L'extended thinking permet à Claude de poser le problème, identifier les sections pertinentes, croiser les informations, et structurer sa réponse avant de l'émettre.

Les cas d'usage les plus impactants en enterprise :

Analyse de contrats : identification de clauses à risque, comparaison avec des standards internes
Diagnostic technique : analyse de logs, corrélation multi-sources, hypothèses et vérification
Arbitrage multi-critères : scoring de fournisseurs, priorisation de backlog, allocation de ressources
Planification multi-étapes : décomposition de projets complexes en séquences d'actions

Fenêtre de contexte 200K tokens

200K tokens, c'est environ 500 pages de texte. En pratique, cela signifie qu'un agent Claude peut ingérer un document complet — contrat, documentation technique, rapport financier — sans avoir besoin de le découper en chunks et de construire un pipeline RAG complexe.

Pour les cas simples (un agent qui analyse UN document), c'est un gain massif en complexité d'architecture. Le RAG reste nécessaire pour les corpus larges (des milliers de documents), mais la fenêtre de contexte élimine une couche d'infra pour beaucoup de cas d'usage enterprise.

MCP natif : le standard ouvert pour les tools

MCP (Model Context Protocol) est un protocole ouvert créé par Anthropic et adopté par l'ensemble de l'écosystème — OpenAI, Google, Microsoft l'ont intégré ou annoncé leur support. C'est le USB-C des agents IA : un standard unique pour connecter un agent à n'importe quel outil.

Claude est le LLM le plus avancé sur MCP : il le supporte nativement, son SDK l'intègre en première classe, et l'écosystème de MCP servers est le plus mature. En enterprise, cela signifie qu'un seul MCP server Salesforce peut être réutilisé par tous vos agents, quel que soit le framework d'orchestration.

Safety et guardrails natifs

Claude est le LLM le plus conservateur en termes de safety — et pour l'enterprise, c'est un avantage. Quand un agent manipule des données sensibles (RH, finance, santé), les guardrails natifs de Claude ajoutent une couche de protection qui réduit le risque de fuite de données ou d'actions non autorisées. Les équipes compliance apprécient.

Computer use : automatiser les interfaces sans API

Claude peut voir un écran et interagir avec : cliquer, taper, naviguer dans une interface graphique. Pour les entreprises qui ont des systèmes legacy sans API (certaines versions de SAP, des ERP métier, des outils internes), c'est la seule option d'automatisation qui ne nécessite pas de développement custom.

Découvrir notre expertise Claude & agents IA

Architecture d'un agent Claude en entreprise

Voici l'architecture type d'un agent Claude déployé en production dans un contexte enterprise :

Utilisateur (Slack, Teams, UI interne)
         ↓
   Agent Claude
   ├── System prompt (rôle, contraintes, format)
   ├── Extended Thinking (raisonnement interne)
   └── Tool Use (décision d'action)
         ↓
   MCP Client (connecteur)
         ↓
   ┌─────────────────────────────────────────────┐
   │              MCP Servers                     │
   ├── CRM (Salesforce, HubSpot)                 │
   ├── ERP (SAP, Odoo)                           │
   ├── Docs (Confluence, SharePoint, Notion)     │
   ├── Database (PostgreSQL, BigQuery)           │
   ├── Email (Gmail, Outlook)                    │
   └── API internes (custom)                     │
   └─────────────────────────────────────────────┘
         ↓
   Réponse structurée + citations sources
         ↓
   Observabilité (LangFuse)

Le flux est le suivant : l'agent reçoit une instruction utilisateur, active l'extended thinking pour raisonner sur la meilleure approche, décide quels outils appeler, les invoque via MCP, reçoit les résultats, et synthétise une réponse avec les sources citées.

La différence fondamentale avec un chatbot : un chatbot répond. Un agent agit. Il peut lire un email, chercher dans le CRM, vérifier une information dans l'ERP, rédiger une réponse, et l'envoyer — le tout dans une seule exécution. L'humain valide les actions critiques (human-in-the-loop), mais l'agent fait le travail.

MCP (Model Context Protocol) : le standard pour les tools

Architecture MCP

MCP définit trois rôles :

Host : l'application qui héberge l'agent (votre backend, Claude Desktop, un orchestrateur)
Client : le connecteur MCP qui gère la communication avec les servers (un client par server)
Server : le service qui expose des capacités — tools, resources, prompts

Un MCP server expose trois types de capacités :

Tools : des fonctions que l'agent peut appeler (ex: search_contacts, create_order, send_email)
Resources : des données que l'agent peut lire (ex: liste de produits, documentation, contexte utilisateur)
Prompts : des templates de prompts réutilisables (ex: format d'analyse de contrat)

MCP servers enterprise : exemples concrets

CRM (Salesforce, HubSpot) :

search_contacts(query, filters) — rechercher des contacts par nom, entreprise, deal stage
get_opportunity(id) — récupérer les détails d'une opportunité
update_deal_stage(id, stage) — avancer un deal dans le pipeline
create_activity(contact_id, type, notes) — logger une interaction

ERP (SAP, Odoo) :

check_inventory(product_id, warehouse) — vérifier le stock disponible
create_purchase_order(items, supplier) — créer un bon de commande
get_invoice(invoice_id) — récupérer une facture

Documentation (Confluence, SharePoint) :

search_documents(query, space) — recherche sémantique dans la base documentaire
get_page(page_id) — récupérer le contenu d'une page
Ce MCP server fonctionne typiquement comme un RAG : indexation vectorielle + recherche hybride

Base de données :

execute_query(sql, database) — exécuter une requête SQL (en lecture seule, avec validation)
get_schema(table) — récupérer le schéma d'une table

Email (Gmail, Outlook) :

search_emails(query, folder, date_range) — rechercher des emails
draft_email(to, subject, body) — créer un brouillon (validation humaine avant envoi)

Sécurité MCP en enterprise

La sécurité est le point critique pour tout déploiement enterprise :

OAuth 2.1 : chaque MCP server est protégé par un flux OAuth, avec des scopes qui limitent les permissions de l'agent
Scoping des permissions : un agent peut avoir le droit de lire le CRM mais pas d'écrire, ou d'écrire uniquement dans certains champs
Audit log : chaque tool call est loggué — quel agent, quel tool, quels paramètres, quel résultat, à quel moment
Rate limiting : les MCP servers implémentent leur propre rate limiting pour éviter les abus
Validation des inputs : les schémas JSON des tools servent de première couche de validation

Guide complet sur les MCP servers en entreprise

Construire un agent Claude : guide pas à pas

Step 1 : Installer le SDK

pip install anthropic

Le SDK Python d'Anthropic est la base. Pour les projets TypeScript :

npm install @anthropic-ai/sdk

Step 2 : Définir les tools

Chaque tool est défini par un nom, une description, et un schéma JSON pour les paramètres d'entrée. La description est critique : c'est ce que Claude lit pour décider quand et comment utiliser le tool.

tools = [
    {
        "name": "search_documents",
        "description": (
            "Recherche dans la base documentaire interne. "
            "Utiliser pour trouver des procédures, des specs techniques, "
            "ou des documents de référence. Retourne les 5 résultats "
            "les plus pertinents avec leur contenu."
        ),
        "input_schema": {
            "type": "object",
            "properties": {
                "query": {
                    "type": "string",
                    "description": "Requête de recherche en langage naturel"
                },
                "space": {
                    "type": "string",
                    "enum": ["engineering", "product", "hr", "legal"],
                    "description": "Espace documentaire à cibler"
                },
                "max_results": {
                    "type": "integer",
                    "default": 5,
                    "description": "Nombre max de résultats"
                }
            },
            "required": ["query"]
        }
    },
    {
        "name": "create_ticket",
        "description": (
            "Crée un ticket dans le système de suivi (Jira/Linear). "
            "Utiliser quand l'utilisateur demande de créer une tâche, "
            "un bug report, ou une demande de feature. "
            "Toujours demander confirmation avant de créer."
        ),
        "input_schema": {
            "type": "object",
            "properties": {
                "title": {
                    "type": "string",
                    "description": "Titre concis du ticket"
                },
                "description": {
                    "type": "string",
                    "description": "Description détaillée"
                },
                "priority": {
                    "type": "string",
                    "enum": ["critical", "high", "medium", "low"]
                },
                "assignee": {
                    "type": "string",
                    "description": "Email de la personne assignée"
                }
            },
            "required": ["title", "description", "priority"]
        }
    }
]

Step 3 : Créer l'agent avec instructions

Le system prompt est l'ADN de l'agent. En enterprise, il doit être structuré et explicite sur les contraintes.

import anthropic

client = anthropic.Anthropic()  # ANTHROPIC_API_KEY en env var

system_prompt = """Tu es un assistant technique interne pour l'équipe engineering.

## Rôle
- Répondre aux questions techniques en t'appuyant sur la documentation interne
- Créer des tickets quand on te le demande
- Toujours citer tes sources quand tu utilises des documents

## Contraintes
- Ne jamais inventer d'information : si tu ne trouves pas dans la doc, dis-le
- Demander confirmation avant toute action d'écriture (création de ticket, etc.)
- Ne pas accéder aux espaces 'hr' ou 'legal' sauf demande explicite
- Répondre en français

## Format de réponse
- Structurer avec des titres et bullet points
- Citer les documents sources entre crochets [Doc: titre]
- Pour les tickets créés, afficher le lien
"""

response = client.messages.create(
    model="claude-sonnet-4-20250514",
    max_tokens=8096,
    system=system_prompt,
    tools=tools,
    messages=[
        {"role": "user", "content": "Quelle est la procédure de déploiement en prod ?"}
    ]
)

Step 4 : La boucle agentique

C'est le coeur de l'agent : une boucle qui continue tant que Claude demande à utiliser des tools.

def run_agent(user_message: str, conversation: list = None):
    if conversation is None:
        conversation = []
    
    conversation.append({"role": "user", "content": user_message})
    
    while True:
        response = client.messages.create(
            model="claude-sonnet-4-20250514",
            max_tokens=8096,
            system=system_prompt,
            tools=tools,
            messages=conversation,
        )
        
        # Si Claude a fini (pas de tool use), retourner la réponse
        if response.stop_reason == "end_turn":
            assistant_text = next(
                (block.text for block in response.content 
                 if block.type == "text"),
                ""
            )
            conversation.append({"role": "assistant", "content": response.content})
            return assistant_text, conversation
        
        # Si Claude veut utiliser un tool
        if response.stop_reason == "tool_use":
            conversation.append({"role": "assistant", "content": response.content})
            
            tool_results = []
            for block in response.content:
                if block.type == "tool_use":
                    # Exécuter le tool
                    result = execute_tool(block.name, block.input)
                    tool_results.append({
                        "type": "tool_result",
                        "tool_use_id": block.id,
                        "content": result
                    })
            
            conversation.append({"role": "user", "content": tool_results})
            continue
        
        # Cas inattendu — sortir de la boucle
        break
    
    return None, conversation


def execute_tool(name: str, params: dict) -> str:
    """Dispatch les appels tools vers les implémentations."""
    if name == "search_documents":
        return search_in_confluence(params["query"], params.get("space"))
    elif name == "create_ticket":
        return create_jira_ticket(params)
    else:
        return f"Tool inconnu : {name}"

Step 5 : Activer l'extended thinking

Pour les tâches complexes, l'extended thinking améliore significativement la qualité :

response = client.messages.create(
    model="claude-sonnet-4-20250514",
    max_tokens=16000,
    thinking={
        "type": "enabled",
        "budget_tokens": 10000  # Limiter le budget de réflexion
    },
    system=system_prompt,
    tools=tools,
    messages=conversation,
)

# Le thinking est dans les blocs de type "thinking"
for block in response.content:
    if block.type == "thinking":
        print(f"[Raisonnement interne] {block.thinking}")
    elif block.type == "text":
        print(f"[Réponse] {block.text}")

Step 6 : Connecter via MCP (production)

En production, les tools ne sont plus définis statiquement : l'agent les découvre dynamiquement via des MCP servers.

# Avec le SDK Anthropic + MCP
from anthropic import Anthropic
from anthropic.types import ToolUseBlock

# Configuration des MCP servers
mcp_servers = {
    "crm": {
        "url": "https://mcp-crm.internal.company.com",
        "auth": "oauth2",
        "scopes": ["contacts:read", "opportunities:read", "activities:write"]
    },
    "docs": {
        "url": "https://mcp-docs.internal.company.com",
        "auth": "oauth2",
        "scopes": ["pages:read", "search"]
    },
    "ticketing": {
        "url": "https://mcp-jira.internal.company.com",
        "auth": "oauth2",
        "scopes": ["issues:read", "issues:write"]
    }
}

# L'agent découvre les tools disponibles au démarrage
# Chaque MCP server expose sa liste de tools via le protocole
available_tools = []
for server_name, config in mcp_servers.items():
    mcp_client = MCPClient(config["url"], auth=config["auth"])
    server_tools = mcp_client.list_tools()
    available_tools.extend(server_tools)
    print(f"[MCP] {server_name}: {len(server_tools)} tools découverts")

# L'agent utilise ces tools dynamiquement
# Pas besoin de coder en dur la liste des tools

Extended Thinking : quand et comment l'utiliser

L'extended thinking est le "temps de réflexion" de Claude. Quand il est activé, Claude raisonne en chaîne avant de produire sa réponse — exactement comme un expert humain qui prend le temps de poser le problème avant de répondre.

Quand l'activer

Analyse de documents complexes : contrats, rapports financiers, specs techniques
Arbitrages multi-critères : évaluation de fournisseurs, priorisation, allocation
Planification multi-étapes : décomposition de projets, séquençage d'actions
Debugging : analyse de logs, corrélation d'erreurs, identification de root cause
Rédaction structurée : rapports, propositions commerciales, documentation technique

Quand NE PAS l'activer

Q&A simple : questions factuelles, lookup dans une base de données
Extraction de données : parsing de documents structurés, extraction d'entités
Tâches déterministes : reformatage, traduction, conversion de format
Conversations courtes : le surcoût en tokens ne se justifie pas

Impact en production

L'extended thinking consomme entre 30 et 50% de tokens supplémentaires. En contrepartie, la qualité des réponses augmente de 40 à 60% sur les tâches de raisonnement complexe (mesuré sur nos déploiements clients).

La bonne pratique : configurer un budget_tokens pour le thinking. Cela évite que Claude "réfléchisse" pendant 50K tokens sur une question simple. Un budget de 5K-10K tokens est suffisant pour la majorité des cas enterprise.

thinking={
    "type": "enabled",
    "budget_tokens": 8000  # Max 8K tokens de réflexion
}

Computer Use : automatiser les interfaces legacy

Principe

Claude peut recevoir un screenshot d'écran, analyser visuellement l'interface, et produire des actions : cliquer sur un bouton, taper dans un champ, naviguer dans des menus. C'est de l'automatisation UI pilotée par un LLM.

Cas d'usage enterprise

Saisie dans SAP : un agent qui remplit des formulaires SAP à partir de données structurées, sans avoir besoin d'une intégration BAPI/RFC
Extraction depuis un ERP legacy : lire des données affichées à l'écran dans un système sans API exportable
Tests UI automatisés : parcourir une application web et vérifier que les parcours utilisateur fonctionnent
Migration de données : extraire des données d'un ancien système en navigant dans l'interface

Limites

Computer use n'est pas adapté à toutes les situations :

Lent : chaque action nécessite un screenshot, une analyse visuelle, et une décision — compter 2 à 5 secondes par action
Fragile : un changement d'interface (nouvelle version, thème différent) peut casser l'automatisation
Coût : chaque screenshot consomme des tokens vision

Best practice

Utiliser computer use uniquement pour les systèmes sans API. Si une API existe (même partielle), c'est toujours préférable : plus rapide, plus fiable, moins coûteux. Computer use est une solution de dernier recours pour les systèmes legacy, pas un remplacement d'intégration.

response = client.messages.create(
    model="claude-sonnet-4-20250514",
    max_tokens=4096,
    tools=[
        {
            "type": "computer_20250124",
            "name": "computer",
            "display_width_px": 1920,
            "display_height_px": 1080,
        }
    ],
    messages=[
        {
            "role": "user",
            "content": [
                {
                    "type": "text",
                    "text": "Connecte-toi à SAP et crée un bon de commande pour le fournisseur ACME, article REF-4521, quantité 100."
                },
                {
                    "type": "image",
                    "source": {
                        "type": "base64",
                        "media_type": "image/png",
                        "data": screenshot_base64
                    }
                }
            ]
        }
    ]
)

Claude en production : checklist

Avant de passer un agent Claude en production, vérifiez chaque point :

Infrastructure

Rate limiting configuré : respecter les limites Anthropic (RPM/TPM selon le tier), implémenter un rate limiter côté client pour éviter les erreurs 429
Budget tokens par exécution : définir un max_tokens raisonnable et un budget_tokens pour l'extended thinking — un agent qui dérape peut consommer des centaines de milliers de tokens en une seule exécution
Retry avec backoff exponentiel : les API LLM ont des erreurs transitoires — implémenter un retry avec backoff (1s, 2s, 4s, 8s) sur les erreurs 429 et 500
Fallback provider : si Claude est down, basculer automatiquement sur GPT-4 via un gateway comme LiteLLM ou un proxy custom. Ne pas dépendre d'un seul provider
Timeout par tool call : un MCP server qui ne répond pas ne doit pas bloquer l'agent indéfiniment — configurer un timeout de 30s par tool call

Observabilité

Traces complètes : logger chaque exécution avec les messages, tools calls, résultats, et la réponse finale. LangFuse est le standard pour ça — en savoir plus sur LangFuse
Métriques de coût : suivre le coût par exécution, par agent, par utilisateur. Les tokens d'extended thinking peuvent représenter 30-50% du coût total
Latence par étape : mesurer le temps de chaque tool call, du thinking, et de la réponse. Identifier les goulots d'étranglement
Alerting : configurer des alertes sur les erreurs récurrentes, les dépassements de budget, et les latences anormales

Sécurité et compliance

PII detection avant envoi : filtrer les données sensibles (numéros de sécurité sociale, cartes bancaires, données de santé) avant de les envoyer à l'API Anthropic
Audit log de tous les tool calls : chaque action de l'agent doit être loggée — qui a demandé quoi, quel tool a été appelé, avec quels paramètres, quel résultat
Human-in-the-loop sur les actions destructives : envoi d'email, création de commande, modification de données — toujours demander une validation humaine avant d'exécuter
Versioning des system prompts : gérer les prompts comme du code, avec versioning, review, et rollback. Un changement de prompt peut changer le comportement de l'agent

Performance

Caching des réponses stables : embeddings, extractions récurrentes, résultats de recherche — si le résultat ne change pas souvent, le cacher pour réduire les appels API
Prompt optimization : un prompt trop long consomme des tokens inutilement. Mesurer et optimiser régulièrement
Streaming : activer le streaming pour les réponses longues afin d'améliorer l'expérience utilisateur (premier token visible en < 1s)

Claude vs GPT pour les agents enterprise

Comparaison honnête des deux principaux LLMs pour les agents enterprise :

Critère	Claude (Anthropic)	GPT-4o / o3 (OpenAI)
Raisonnement complexe	Extended thinking natif	Chain of thought (o3)
Fenêtre de contexte	200K tokens	128K tokens
Tools standard (MCP)	Support natif, écosystème mature	En cours d'adoption
Code execution	Via tool use	Code Interpreter natif
Computer use	Disponible	Non disponible
Multimodal	Vision (images)	Vision + audio + vidéo
Guardrails natifs	Très conservateur (pro-compliance)	Modéré
Coût	Comparable (Sonnet = GPT-4o tier)	Comparable
Stabilité API	Très stable, peu de breaking changes	Stable
SDK enterprise	Python + TypeScript, bien documenté	Python + TypeScript, plus de wrappers

Verdict pragmatique :

Claude est meilleur pour : le raisonnement sur des documents longs, les agents avec MCP, les contextes enterprise où la compliance compte, l'automatisation UI via computer use
GPT-4o/o3 est meilleur pour : le multimodal avancé (audio, vidéo), le code execution natif, les cas où l'écosystème OpenAI est déjà en place

En pratique, les déploiements enterprise les plus robustes utilisent les deux : Claude comme provider principal (raisonnement + MCP), GPT-4 en fallback, et parfois Mistral pour les cas où la souveraineté des données est un critère.

Comment Origin 137 déploie Claude en entreprise

Origin 137 déploie Claude en production depuis ses premières versions. Nos ingénieurs IA utilisent le Claude Agent SDK et MCP au quotidien chez nos clients — c'est notre stack de référence pour les agents enterprise.

Notre stack

Claude (Anthropic) : LLM principal pour le raisonnement et les agents
LangGraph : orchestration des agents multi-étapes (graphes d'état, parallélisme, sous-agents)
MCP : connexion aux outils métier (CRM, ERP, docs, bases de données)
LangFuse : observabilité complète (traces, coûts, latence, évaluation qualité)

Notre approche

On ne déploie jamais un "super-agent" d'emblée. L'approche qui fonctionne en enterprise :

Commencer simple : un agent, un tool, une tâche. Exemple : un agent qui répond aux questions techniques en cherchant dans Confluence
Mesurer : taux de réponse correcte, temps de réponse, coût par exécution, satisfaction utilisateur
Étendre progressivement : ajouter des tools (CRM, ticketing), activer l'extended thinking sur les cas complexes, brancher de nouveaux MCP servers
Industrialiser : CI/CD des prompts, monitoring en continu, fallback multi-provider, alerting

Fallback multi-provider

Aucun LLM n'a 100% d'uptime. Notre architecture standard :

Primary : Claude (Anthropic) — meilleur raisonnement, MCP natif
Fallback : GPT-4o (OpenAI) — si Claude est down ou rate limited
Souverain : Mistral (via Scaleway/OVH) — pour les clients avec des contraintes de localisation des données

La bascule est automatique via un gateway LLM (LiteLLM ou custom), avec des métriques de qualité pour s'assurer que le fallback ne dégrade pas l'expérience.

Nos ingénieurs

Nos Forward Deployed Engineers s'intègrent directement dans les équipes clients. Ce ne sont pas des consultants qui produisent des slides : ce sont des ingénieurs seniors qui codent, déploient, et opèrent les agents en production.

Staffing IA — intégration d'ingénieurs IA senior dans vos équipes
Projets IA — conception et déploiement d'agents de bout en bout
Expertise agents IA — conseil, architecture, audit de vos agents existants

Conclusion

Claude est le LLM le mieux positionné pour les agents IA enterprise en 2025-2026. L'extended thinking apporte un raisonnement de qualité sur les tâches complexes, MCP standardise la connexion aux outils métier, et la fenêtre de 200K tokens simplifie l'architecture pour les cas documentaires.

Mais la technologie ne suffit pas. Le vrai défi est le déploiement : sécurité, observabilité, human-in-the-loop, fallback multi-provider, gestion des prompts comme du code. C'est là que l'expertise engineering fait la différence.

Besoin de déployer des agents Claude en production ? Nos ingénieurs déploient Claude + MCP au quotidien chez des ETI et grands groupes. Architecture, développement, mise en production — on intervient en régie dans vos équipes.

Discuter de votre projet