On nous vend des assistants IA capables de « transformer les opérations IT ». Dans la pratique, quand on demande à un LLM générique de vérifier l’état de nos ressources Azure ou d’auditer les certificats SSL de nos clients, on obtient des réponses théoriques, des commandes approximatives et zéro contexte métier. On se retrouve à copier-coller des sorties PowerShell dans un chat, à reformuler trois fois la même question, et au final on aurait été plus rapide en le faisant soi-même.

Le problème n’est pas l’intelligence du modèle. C’est son isolation. Un LLM sans accès à vos systèmes, c’est un consultant brillant qu’on enferme dans une salle sans téléphone ni ordinateur. Il peut théoriser, mais il ne peut pas agir, et surtout il ne peut pas vérifier ce qu’il avance.

Claude Teams combiné au protocole MCP change cette équation. On a déployé cette stack sur nos environnements de gestion, on a cadré un framework de mise en production, et on a identifié les pièges à éviter. Cet article est un retour d’expérience complet : ce qu’on a mis en place, pourquoi, et comment vous pouvez faire pareil — en gardant le contrôle sur vos données et votre infrastructure.

Claude Teams — ce que ça change vraiment

Commençons par clarifier un point : Claude Teams n’est pas « un ChatGPT de plus avec un abonnement entreprise ». La confusion est fréquente chez nos clients, et elle mène à de mauvaises décisions d’architecture. Voici les trois différences structurantes pour un usage professionnel en infrastructure.

Siège nominatif avec cloisonnement réel des données. Chaque collaborateur dispose de son propre espace de conversation. Les échanges ne sont ni partagés entre utilisateurs, ni utilisés pour entraîner le modèle. Concrètement, quand un de nos techniciens discute d’un problème sur le tenant Azure d’un client, cette conversation reste strictement privée. Pour un MSP qui manipule quotidiennement des données de dizaines de clients différents, ce n’est pas un bonus marketing — c’est un prérequis contractuel. Sans cette garantie, impossible de respecter nos engagements de confidentialité.

Accès API intégré à l’abonnement. L’abonnement Teams inclut l’accès à l’API Anthropic, ce qui permet d’intégrer Claude dans des scripts, des pipelines CI/CD ou des outils internes. On passe du chat interactif — utile mais limité — à l’automatisation programmable. Dans notre cas, ça signifie par exemple qu’un script Python peut appeler Claude pour analyser les résultats d’un audit et générer un rapport structuré, sans intervention humaine au milieu de la chaîne. Le modèle devient un composant de notre toolchain, pas juste un assistant conversationnel.

Le socle nécessaire pour les connexions MCP. C’est le point le plus sous-estimé et pourtant le plus transformateur : Claude Teams est la fondation qui permet de déployer des MCP — ces connecteurs qui donnent à Claude un accès encadré et contrôlé à votre infrastructure. Sans cette base, pas de connexion possible à vos systèmes. Et sans connexion à vos systèmes, l’IA reste un outil générique de plus.

Dans notre pratique quotidienne, c’est cette dernière capacité qui a tout changé. Le jour où Claude a pu interroger directement nos ressources Azure au lieu de deviner, on est passé d’un gadget à un vrai outil de production.

C’est quoi un MCP, concrètement ?

MCP — Model Context Protocol — est un standard ouvert, initié par Anthropic et adopté par un écosystème croissant, qui permet à Claude d’appeler des tools (outils) exposés par vos propres services. La meilleure analogie : pensez-y comme un système de plugins pour votre assistant IA.

La distinction avec un « bot autonome » est fondamentale et souvent mal comprise. Un MCP ne fait rien de lui-même. Il ne tourne pas en arrière-plan, il ne prend pas de décisions, il n’exécute rien de façon proactive. C’est Claude qui décide d’appeler un tool quand c’est pertinent dans le contexte d’une conversation, reçoit le résultat structuré, et le synthétise pour l’utilisateur. Le flux est toujours supervisé, toujours initié par une demande humaine :

Utilisateur → Claude → MCP Server → Votre système (Azure, Zabbix, GLPI…)
                 ↑                         |
                 └─── Résultat structuré ──┘

En pratique, un serveur MCP est un petit service (quelques centaines de lignes de code) qui expose une liste de tools déclaratifs. Chaque tool a un nom explicite, une description en langage naturel (que Claude utilise pour comprendre quand l’appeler), et des paramètres typés. Voici ce que ça donne dans un contexte MSP :

  • list_resource_groups(subscription_id) — inventaire des groupes de ressources Azure d’un tenant
  • audit_certificates(domain) — vérification de l’expiration, de l’émetteur et de la chaîne SSL d’un domaine
  • get_active_alerts(client_name) — alertes en cours depuis votre plateforme de supervision (Zabbix, Centreon, Azure Monitor)
  • query_logs(resource_id, timespan) — extraction de logs Azure Monitor sur une période donnée
  • list_vms(subscription_id, status_filter) — inventaire des VMs avec filtrage par état (running, deallocated, stopped)

Claude lit la description de chaque tool disponible et décide lequel appeler en fonction de la question posée. L’intelligence est dans la sélection et l’enchaînement : si vous demandez « quels certificats expirent dans les 30 prochains jours chez le client Dupont ? », Claude va d’abord identifier les domaines du client concerné, puis appeler audit_certificates pour chacun d’entre eux, agréger les résultats, et vous répondre avec un résumé clair — en français, en langage naturel, avec les dates et les actions recommandées.

Ce qui est remarquable, c’est que Claude gère naturellement les cas limites : si un domaine ne répond pas, il le signale. Si un certificat est auto-signé, il le mentionne. Il ne se contente pas de retranscrire des données brutes — il les interprète dans le contexte de votre question.

Deux modes de déploiement

Dans notre expérience, deux architectures couvrent 90 % des cas de figure. Le choix entre les deux dépend essentiellement du nombre d’utilisateurs et de votre maturité sur le sujet.

Local (stdio) — le point de départ idéal

Claude Code tourne sur un VPS ou un poste de travail. Le serveur MCP est un process local (Python, Node.js) qui se lance automatiquement avec la session Claude Code. La communication se fait directement via stdin/stdout — pas de réseau, pas de ports à ouvrir, pas de certificats à gérer.

C’est l’architecture qu’on utilise en interne pour le développement et le prototypage. En moins de 30 minutes, un développeur peut avoir un MCP fonctionnel qui interroge Azure. L’inconvénient : c’est limité à une seule session, sur une seule machine. C’est parfait pour tester, insuffisant pour une équipe.

Hébergé (HTTP/SSE) — pour l’équipe

Le serveur MCP tourne dans un container (Azure Container Apps, Docker sur une VM dédiée, ou même un simple service systemd) et expose un endpoint HTTP avec Server-Sent Events (SSE). Plusieurs utilisateurs Claude Teams y accèdent simultanément depuis claude.ai, chacun dans sa propre conversation.

Cette architecture demande plus de travail initial — authentification, certificats, monitoring du service — mais elle permet un vrai déploiement d’équipe. C’est celle qu’on vise pour nos clients en production.

Local (stdio)

  • Mise en place : 30 minutes
  • Multi-utilisateurs : Non — une seule session à la fois
  • Sécurité réseau : périmètre machine uniquement, pas d’exposition réseau
  • Scalabilité : 1 session
  • Coût infra : ~0 € (tourne sur une machine existante)
  • Cas d’usage : prototypage, validation de concept, usage individuel

Hébergé (HTTP/SSE)

  • Mise en place : 2-4 heures (plus si RBAC complexe)
  • Multi-utilisateurs : Oui — accès concurrent via claude.ai
  • Sécurité réseau : Managed Identity + RBAC Azure + TLS
  • Scalabilité : illimitée (scaling horizontal du container)
  • Coût infra : ~15-30 €/mois (Azure Container Apps consumption plan)
  • Cas d’usage : équipe, production, multi-clients

Notre recommandation : commencez systématiquement en local pour valider le concept et affiner vos tools. Ne passez en hébergé que lorsque deux personnes ou plus doivent y accéder. Trop de projets IA échouent parce qu’on commence par l’architecture cible au lieu de valider la valeur d’abord.

Cas d’usage concrets pour un MSP

La théorie c’est bien, mais ce qui compte c’est ce qu’on en fait au quotidien. Voici cinq scénarios que nous avons implémentés ou cadrés pour nos clients, avec pour chacun le contexte du problème et ce que le MCP apporte concrètement.

Audit Azure cross-tenant Tools : list_resource_groups, list_resources — Source : Azure Resource Manager

Le problème classique du MSP : vous gérez 15, 20, 50 tenants Azure pour autant de clients. Vérifier l’état des ressources implique de se connecter à chaque portail, naviguer dans les menus, exporter des données. Avec un MCP connecté à Azure Resource Manager via une app registration multi-tenant, Claude peut consolider l’inventaire de tous les tenants en une seule conversation. « Montre-moi toutes les VMs deallocated depuis plus de 30 jours, tous clients confondus » — réponse en 30 secondes, là où il fallait une demi-journée.

Monitoring certificats SSL Tool : audit_certificates — Source : OpenSSL + DNS

Un certificat expiré, c’est un site client en erreur et un appel de panique un vendredi soir. Notre MCP vérifie en temps réel l’expiration, le mismatch SAN, les chaînes incomplètes et les protocoles obsolètes. On peut demander à Claude « quels certificats expirent dans les 15 prochains jours ? » et obtenir une liste priorisée avec les actions à prendre. Plus besoin de maintenir un tableur Excel de suivi.

Rapport client automatisé Tools : get_metrics, get_alerts — Source : Zabbix / Azure Monitor

Nos clients attendent un rapport mensuel sur l’état de leur infrastructure. Avant, c’était 2 à 3 heures de travail par client : export des données, mise en forme, rédaction des commentaires. Avec le MCP, Claude extrait les métriques, identifie les tendances (augmentation du CPU, pics de latence, incidents récurrents) et génère un rapport structuré en français. Le technicien relit, ajuste si nécessaire, et envoie. On est passé de 3 heures à 30 minutes par rapport.

Onboarding client Tools : run_audit_script, generate_doc — Source : scripts internes

Quand on signe un nouveau client MSP, la phase d’audit initial est critique et chronophage : inventaire des ressources, vérification des configurations de sécurité, état des backups, conformité des policies. Notre MCP orchestre le lancement de nos scripts d’audit existants et agrège les résultats. Claude génère ensuite un document d’onboarding structuré qui sert de base au plan d’action. Ce qui prenait 2 jours se fait en une demi-journée.

Détection d’anomalies Tools : query_dead_letters, get_alerts — Source : Service Bus, Log Analytics

C’est peut-être le cas d’usage le plus impressionnant. Les dashboards de monitoring montrent des métriques individuelles, mais la corrélation entre signaux faibles reste un exercice humain. Claude, avec accès aux DLQ (dead letter queues), aux alertes et aux logs, peut identifier des patterns que personne ne cherche activement. « Pourquoi le traitement des commandes ralentit depuis mardi ? » — Claude corrèle une augmentation des dead letters sur un topic Service Bus avec un changement de configuration déployé lundi soir. Ce genre de diagnostic prend des heures à un humain qui n’a pas le contexte complet.

Un exemple de code concret

Voici un tool MCP en Python, volontairement simplifié, pour illustrer la facilité de mise en œuvre :

# Tool : audit des certificats SSL d'un domaine
@mcp.tool()
async def audit_certificates(domain: str) -> dict:
    """Vérifie le certificat SSL d'un domaine : expiration, émetteur, SAN."""
    import ssl, socket
    from datetime import datetime
    ctx = ssl.create_default_context()
    with ctx.wrap_socket(socket.socket(), server_hostname=domain) as s:
        s.settimeout(5)
        s.connect((domain, 443))
        cert = s.getpeercert()
    expiry = datetime.strptime(cert['notAfter'], '%b %d %H:%M:%S %Y %Z')
    return {"domain": domain, "expires": expiry.isoformat(),
            "days_left": (expiry - datetime.now()).days,
            "issuer": dict(x[0] for x in cert['issuer'])}

Dix lignes de code métier. Le décorateur @mcp.tool() et la docstring suffisent à Claude pour comprendre quand et comment utiliser ce tool. Pas de configuration XML, pas de schéma complexe — la description en langage naturel fait le travail.

Ce qu’il faut mettre en place AVANT de déployer

L’enthousiasme est compréhensible — les premiers résultats sont bluffants. Mais un MCP mal cadré, c’est une porte ouverte sur votre infrastructure avec un modèle d’IA qui décide quoi faire. Nous avons formalisé un framework en 5 points non-négociables avant toute mise en production.

1. Managed Identity, jamais de secrets dans le code. Chaque serveur MCP s’authentifie auprès d’Azure via une identité managée (Managed Identity). Aucune clé API, aucun mot de passe, aucun secret dans le code source ni dans les variables d’environnement du container. C’est la règle zéro, celle dont on ne déroge jamais. En cas de compromission du container, l’attaquant n’a pas de credentials à exfiltrer — l’identité est liée à la ressource Azure elle-même et les tokens sont éphémères.

2. Read-only par défaut, sans exception. Un MCP en production commence avec des permissions de lecture seule. Point. On n’ouvre l’écriture que pour des cas spécifiques, validés en comité, avec un circuit d’approbation explicite documenté. Pourquoi cette rigidité ? Parce que Claude peut halluciner des paramètres. Si un tool accepte une action delete et que Claude, mal interprétant une demande, passe ce paramètre — les conséquences sont irréversibles. En read-only, le pire scénario est une lecture inutile. C’est un coût acceptable.

3. Validation stricte des inputs côté serveur. Chaque tool valide ses paramètres avant toute exécution. Format du subscription_id (UUID v4), existence du client_name dans un référentiel, plage de dates cohérente. Si Claude passe un paramètre qui ne correspond pas au format attendu, le tool rejette l’appel avec un message d’erreur explicite. Ne faites jamais confiance aux paramètres générés par le modèle — traitez-les exactement comme vous traiteriez une entrée utilisateur dans une API web.

4. Logs centralisés vers Log Analytics (ou équivalent). Chaque appel de tool est journalisé avec : l’identité de l’utilisateur qui a initié la conversation, le nom du tool appelé, les paramètres passés, le résultat retourné, et le temps d’exécution. Ces logs sont envoyés vers Azure Log Analytics (ou votre SIEM). C’est indispensable pour l’audit de sécurité, le debugging en cas de problème, et la conformité réglementaire. Un MCP sans logs, c’est un accès non tracé à votre infrastructure — inacceptable.

5. Fiche MCP par service déployé. Un document de gouvernance formalisé pour chaque MCP en production : périmètre d’accès exact, données exposées et leur classification, évaluation RGPD, propriétaire technique, fréquence de revue. Sans cette fiche validée, le MCP ne passe pas en production. Ce n’est pas de la bureaucratie — c’est ce qui vous permet de répondre quand un client ou un auditeur demande « qui a accès à quoi, et comment c’est contrôlé ? ».

RGPD & NIS2 — les questions à se poser

Avant de connecter Claude à vos systèmes, quatre questions de conformité que tout DSI ou responsable IT doit se poser. Elles ne sont pas théoriques — elles conditionnent la faisabilité légale de votre déploiement.

Mon MCP expose-t-il des données personnelles ? Si votre tool remonte des noms d’utilisateurs, des adresses email, des numéros de téléphone ou des logs contenant des adresses IP, vous êtes dans le périmètre RGPD. La question n’est pas « est-ce que ça arrive ? » mais « est-ce que ça peut arriver ? ». Minimisez les données exposées par design : un tool qui remonte des métriques d’utilisation n’a pas besoin de retourner les noms des utilisateurs. Anonymisez ou pseudonymisez quand c’est possible, filtrez à la source.

Suis-je dans un périmètre NIS2 ? La directive européenne NIS2, entrée en application en 2024, élargit considérablement le périmètre des entités concernées. Si vous gérez des infrastructures pour des secteurs critiques (énergie, santé, transports, administrations, fournisseurs numériques), les exigences de sécurité et de notification d’incidents sont renforcées. Un MCP qui accède à ces systèmes doit être traité comme un composant critique de la chaîne d’approvisionnement numérique.

Mes clients savent-ils que leurs données transitent via une API tierce ? Si les données d’infrastructure de vos clients passent par l’API Anthropic — même pour de la lecture seule — un DPA (Data Processing Agreement) est nécessaire. Vos clients doivent être informés, et votre registre de traitements doit être mis à jour. Ce n’est pas optionnel, c’est une obligation légale.

Les conditions d’usage Anthropic sont-elles compatibles avec mon activité ? Point positif : Anthropic ne réentraîne pas ses modèles sur les données transmises via l’API. C’est un engagement contractuel clair. Vérifiez néanmoins les conditions de rétention temporaire des données (pour le debug et la sécurité) et la localisation des serveurs de traitement (principalement aux États-Unis, ce qui implique des clauses contractuelles types pour les transferts hors UE).

Par où commencer ?

Si cet article vous a convaincu de l’intérêt de la démarche, voici le chemin que nous recommandons. Il est volontairement progressif — chaque étape valide la suivante.

Étape 1 — Installer la base. Souscrivez à Claude Teams pour votre équipe. Installez Claude Code sur un VPS de développement (pas de production). Utilisez-le pendant une à deux semaines sur des tâches courantes : écriture de scripts, analyse de logs, génération de documentation technique. L’objectif est de comprendre le modèle d’interaction avant d’y connecter quoi que ce soit. Vous allez découvrir les forces de Claude (raisonnement, synthèse, compréhension du contexte) et ses limites (hallucinations occasionnelles, tendance à être trop confiant).

Étape 2 — Le premier MCP read-only. Développez un MCP qui fait une seule chose, bien. Notre recommandation : un tool list_resource_groups qui inventorie les groupes de ressources d’un tenant Azure de test. C’est simple, c’est read-only, c’est vérifiable manuellement. Déployez-le en mode local (stdio). Testez pendant une semaine. Comparez les résultats avec ce que vous voyez dans le portail. Identifiez les cas où Claude interprète mal les données — ils existent, et c’est normal.

Étape 3 — Cadrer avant d’ouvrir. Avant d’étendre l’accès aux collaborateurs ou d’ajouter des tools, formalisez les 5 points du framework de sécurité. Rédigez la fiche MCP. Validez la conformité RGPD avec votre DPO ou votre conseil juridique. Ce travail de cadrage prend une à deux semaines, mais c’est exactement ce qui sépare un POC qui impressionne en démo d’un outil qui tient en production.

L’IA opérationnelle en infrastructure, ce n’est pas de la science-fiction et ce n’est pas non plus un simple chatbot avec un joli logo. C’est un outil de productivité concret, mesurable, qui change la façon dont une équipe IT interagit avec les systèmes qu’elle gère. Mais comme tout outil puissant, il exige de la rigueur dans sa mise en œuvre — la même rigueur qu’on applique à n’importe quel composant de production.

On accompagne les MSP et les équipes IT dans cette démarche — du cadrage initial au premier MCP en production, en passant par la formation des équipes et la mise en conformité. Si le sujet vous intéresse, parlons-en.

Photo : Brett Sayles via Pexels