MCP : comment connecter vos agents Claude à votre SI assurantiel

Le problème que MCP résout

Vous avez déployé Claude dans votre organisation. Vos équipes l'utilisent pour rédiger, résumer, analyser. Mais Claude ne sait rien de votre SI. Il ne peut pas consulter votre GED de sinistres, interroger votre base contrats, ni appeler l'API de votre outil de gestion. Il travaille en aveugle.

C'est exactement le problème que résout le Model Context Protocol (MCP).

Qu'est-ce que MCP ?

MCP (Model Context Protocol) est un protocole ouvert créé par Anthropic qui définit comment un modèle de langage peut interagir avec des outils et des sources de données externes de manière standardisée et sécurisée.

Concrètement : MCP permet à Claude de "brancher" des outils sur votre SI — comme on branche des plugins sur un navigateur web. Chaque outil est exposé via un serveur MCP, que Claude peut appeler de manière contrôlée.

L'architecture MCP : 3 composants

1. Le client MCP — C'est Claude (ou votre application Claude). Il envoie des requêtes aux serveurs MCP et traite les réponses.

2. Le serveur MCP — C'est le code que vous écrivez pour exposer vos outils. Un serveur MCP peut exposer des ressources (données accessibles en lecture), des outils (actions pouvant être exécutées) et des prompts (templates de messages prédéfinis).

3. Le transport — La couche de communication entre client et serveur (stdio pour du local, HTTP/SSE pour du distant).

Cas d'usage concrets en assurance

Cas 1 — Agent de consultation de contrats

Un agent Claude avec accès à l'API GED de votre système de gestion contrats. Un conseiller peut demander : "Récupère le contrat de M. Dupont et résume les garanties incendie applicables."

Serveur MCP à créer : un outil 'get_contract(contract_id)' qui appelle votre API interne et retourne les données du contrat formatées.

Complexité : faible. Deux semaines de développement pour un développeur Python senior.

Cas 2 — Agent d'instruction de sinistres simples

Un agent qui instruite automatiquement les sinistres "simples" (dégâts des eaux < 5 000€, sans litige apparent). Il consulte le contrat, vérifie les garanties, calcule l'indemnisation préliminaire, génère le projet de lettre de décision.

Serveurs MCP nécessaires :

Complexité : moyenne. 4 à 6 semaines de développement. Supervision humaine obligatoire sur la décision finale.

Cas 3 — Agent de veille réglementaire

Un agent qui surveille les évolutions réglementaires (ACPR, EIOPA, CNIL) et alerte les équipes compliance sur les dispositions applicables à votre organisation.

Serveurs MCP :

Sécurité : les 5 principes que j'applique

1. Principe du moindre privilège. Chaque serveur MCP n'expose que les données et les actions strictement nécessaires pour son cas d'usage. Un agent de lecture de contrats n'a pas besoin d'un outil de modification.

2. Authentification à deux niveaux. L'accès au serveur MCP est protégé (API key, JWT). Les accès aux données sous-jacentes utilisent les droits de l'utilisateur — pas un super-compte.

3. Journalisation exhaustive. Chaque appel MCP est loggé : qui, quoi, quand, résultat. Indispensable pour la conformité et le debugging.

4. Validation des paramètres. Le serveur MCP valide strictement les paramètres reçus de Claude. Une injection de paramètre malformé ne doit pas pouvoir atteindre votre SI.

5. Rate limiting. Limitez le nombre d'appels par session et par utilisateur. Un agent qui "s'emballe" peut générer une charge inattended sur vos API internes.

Guide de démarrage : votre premier serveur MCP

Le SDK officiel Anthropic propose des packages Python et TypeScript pour créer des serveurs MCP. Voici la structure minimale en Python :

L'implémentation d'un outil simple prend 10 à 30 lignes de code. La vraie complexité est dans la gestion des erreurs, la sécurité et l'intégration avec vos API existantes.

Ce que MCP change pour l'architecture des agents

Avant MCP, chaque déploiement d'agent IA était un développement sur mesure : l'intégration SI était codée directement dans l'agent, les outils n'étaient pas réutilisables, et chaque nouvel agent nécessitait de recoder les mêmes intégrations.

Avec MCP, vous construisez une bibliothèque de serveurs MCP réutilisables. Votre GED exposée en MCP peut être utilisée par 5 agents différents. Vos APIs core business deviennent des ressources partagées.

C'est le passage d'un modèle "projet IA" à un modèle "plateforme IA" — et c'est là que se trouve le vrai retour sur investissement.

Conclusion

MCP est la pièce manquante pour passer des agents IA en sandbox aux agents IA en production dans un SI réel. Il impose une discipline d'architecture — ce qui est une bonne chose — et crée les conditions d'une industrialisation à l'échelle.

Pour les architectes SI que je conseille : commencez par un inventaire des API internes que vous souhaitez exposer à Claude. Priorisez par valeur métier et par maturité de l'API. Et surtout : impliquez votre RSSI dès le début.