Meraki et Catalyst Center deviennent interrogeables par des agents IA grâce à MCP

Un collaborateur signale que « le Wi-Fi est lent » dans une partie du bureau. Habituellement, le support doit d’abord retrouver le site, identifier le réseau, vérifier les points d’accès, comprendre l’état des clients et demander plusieurs précisions avant de commencer le diagnostic. Avec les nouveaux serveurs MCP Cisco Meraki et Catalyst Center, une partie de ce contexte peut désormais être collectée par un agent d’intelligence artificielle à partir d’une demande formulée en langage naturel.

Le changement ne consiste pas à ajouter un chatbot dans une nouvelle console. Cisco rend des outils réseau structurés accessibles au travers du Model Context Protocol, ou MCP. Un agent compatible peut ainsi chercher un équipement, examiner son état, rapprocher plusieurs informations et produire une synthèse exploitable dans un portail interne, un outil de ticketing ou l’environnement de travail d’une équipe IT.

Cette ouverture concerne un écosystème beaucoup plus large qu’un seul assistant : Claude, ChatGPT, Codex, GitHub Copilot, Cursor, Gemini CLI, Windsurf, JetBrains AI Assistant et plusieurs autres clients savent déjà utiliser MCP. Mais « compatible MCP » ne signifie ni « certifié par Cisco », ni « automatiquement sûr ». La différence entre le serveur Meraki, volontairement limité à la lecture, et celui de Catalyst Center, dont le catalogue peut exposer des opérations de configuration, doit être comprise avant tout pilote.

Le Model Context Protocol est un standard ouvert qui permet à une application d’IA de se connecter à des outils et à des sources de données. L’image de la prise universelle est utile : le client MCP se trouve du côté de l’agent, tandis que le serveur MCP décrit les fonctions disponibles et traduit les appels vers le système métier.

Dans le cas de Cisco, le serveur se place devant les API Meraki Dashboard ou Catalyst Center. Il publie des outils compréhensibles par la machine, avec un nom, une description et des paramètres attendus. Lorsque l’utilisateur demande « quels points d’accès présentent la plus mauvaise expérience sans fil sur le site de Paris ? », l’agent peut sélectionner les outils pertinents, fournir les identifiants nécessaires, récupérer les résultats puis les résumer.

La chaîne peut se représenter simplement :

MCP ne remplace donc pas l’API. Il lui ajoute une couche standardisée de découverte et d’utilisation par les agents. Une automatisation parfaitement déterministe, répétitive et massive restera souvent plus simple à sécuriser avec un script API classique. MCP devient intéressant lorsque la demande varie, nécessite plusieurs recherches ou doit être formulée par des personnes qui ne développent pas elles-mêmes l’intégration.

Cisco distingue son propre AI Assistant des nouveaux serveurs MCP. L’AI Assistant est adapté lorsque le travail commence dans l’interface Cisco : un administrateur ouvre Meraki, pose une question sur son environnement et poursuit l’exploitation dans ce contexte produit.

MCP répond à un autre besoin. Il permet de faire venir l’information réseau dans l’endroit où le travail a déjà commencé : un ticket de support, un portail en libre-service, un rapport automatisé, une application interne ou un agent qui rapproche plusieurs constructeurs et services.

Cette distinction évite une confusion fréquente. Le serveur MCP ne fournit pas, à lui seul, un écran de support prêt à l’emploi. Il rend des capacités accessibles aux applications que l’entreprise ou son intégrateur construit autour de lui. Les exemples d’interface montrés par Cisco sont des illustrations de ce qu’il devient possible de réaliser, pas des fonctionnalités livrées automatiquement avec le serveur.

Le serveur MCP Meraki officiel relie un client compatible à l’API Dashboard. Il expose actuellement deux outils principaux : une recherche sémantique pour trouver la capacité API correspondant à l’intention, puis un outil d’exécution qui valide et appelle l’opération de lecture sélectionnée.

Deux modes de déploiement sont proposés.

Le point d’accès https://mcp.meraki.com/mcp offre le chemin le plus court. Cisco exploite le serveur et le client lui transmet une clé API Dashboard sous la forme d’un jeton d’authentification. Ce mode évite de maintenir le composant MCP, mais il ne prend en charge que l’environnement Meraki.com standard. Les environnements Federal, GovCloud ou régionalisés ne sont pas compatibles avec le service hébergé au moment de la publication.

L’entreprise peut aussi exécuter le code dans son propre environnement, l’auditer et l’adapter. Ce choix donne davantage de contrôle sur le déploiement et permet de viser les autres environnements Meraki. Il ne rend toutefois pas le Dashboard autonome ni isolé d’Internet : les données restent hébergées dans le cloud Meraki et le serveur local doit continuer à appeler son API.

Dans les deux cas, la version actuelle du serveur ne propose que des lectures. Cisco ajoute néanmoins une réserve importante : si l’agent reçoit une clé Dashboard disposant de droits d’écriture et s’il possède par ailleurs un moyen d’appeler directement l’API, il pourrait contourner cette limite fonctionnelle. La protection ne doit donc pas reposer uniquement sur le catalogue MCP. La clé doit appartenir à un administrateur Meraki réellement limité à la lecture.

Ce principe rejoint les précautions déjà nécessaires pour toute automatisation de l’environnement Cisco Meraki : un secret dédié, un périmètre minimal et des journaux permettant de retrouver ce qui a été demandé.

Le serveur MCP Catalyst Center suit une logique différente. Il se déploie localement, en conteneur, et publie un catalogue d’outils aligné sur la version du contrôleur. L’agent peut interroger l’inventaire, la santé des équipements, l’expérience sans fil, les versions logicielles ou les informations de conformité.

Cette architecture convient aux organisations qui veulent maintenir le serveur MCP, le contrôleur et éventuellement le modèle d’IA dans un périmètre maîtrisé. Elle peut aussi répondre à des contraintes de souveraineté ou à un réseau isolé. Le dépôt prévoit un transport HTTP local ou un lancement direct en STDIO par le client.

La frontière de sécurité est cependant différente de celle de Meraki. Le serveur s’authentifie avec le nom d’utilisateur et le mot de passe du compte Catalyst Center configuré. Il n’ajoute aucune autorisation propre et n’impose pas la lecture seule. Son catalogue généré peut contenir des opérations qui modifient la configuration.

Autrement dit, la phrase « utilise uniquement les outils de lecture » dans un prompt constitue une consigne, pas une barrière technique. Le compte de service doit disposer seulement des permissions nécessaires. Le point d’accès MCP doit rester privé, protégé par les contrôles réseau et d’authentification de l’entreprise, et le contrôle des certificats TLS ne doit pas être désactivé en production.

Il faut distinguer les clients pour lesquels Cisco fournit une configuration, et l’écosystème MCP plus large.

Pour Meraki, Cisco donne des exemples prêts à adapter pour Claude Code, Cursor, VS Code avec GitHub Copilot et Codex. Pour Catalyst Center, le dépôt ajoute Claude Desktop à cette liste.

Une limite mérite d’être signalée : Claude Desktop sait utiliser des serveurs MCP locaux et des connecteurs distants, mais sa configuration actuelle des serveurs distants ne prend pas en charge la clé API requise par le service Meraki hébergé. Il peut en revanche lancer le serveur Meraki local en STDIO. Catalyst Center, lui aussi local, dispose d’une configuration Claude Desktop documentée.

Les produits suivants disposent eux aussi d’une prise en charge officielle de MCP. Cela ne signifie pas que Cisco a testé chaque combinaison avec ses serveurs :

La formulation juste est donc « utilisable avec de nombreux hôtes MCP connus », pas « compatible avec tous les agents IA ». Un client peut connaître le protocole sans accepter le transport choisi par le serveur, son système d’authentification ou les en-têtes nécessaires. Une fonction peut également dépendre d’une version récente, d’un abonnement ou d’une activation par l’administrateur.

Un agent peut partir du site et de l’identité de l’utilisateur, rechercher les données disponibles, identifier les points d’accès concernés et joindre au ticket un état synthétique. Le technicien reçoit alors un dossier mieux qualifié au lieu d’un simple « ça coupe ».

L’objectif n’est pas de laisser le modèle décréter seul la cause d’un incident. Il est de réduire la collecte manuelle et d’associer à chaque hypothèse les données qui la soutiennent : expérience client, état de la borne, SSID, période concernée et anomalies observées.

Une équipe multisite peut demander chaque matin la liste des équipements dégradés, des problèmes de conformité ou des sites qui méritent une vérification. L’agent transforme un volume de télémétrie en liste priorisée, tandis que les données détaillées restent disponibles pour le réseau.

Un portail interne peut répondre à une demande simple avant l’ouverture d’un ticket : vérifier si un incident connu touche le site, contrôler l’état général du réseau ou recommander quelques tests non destructifs. Si l’escalade reste nécessaire, le portail joint les éléments collectés au dossier.

MCP prend tout son sens lorsque l’agent utilise plusieurs serveurs : données réseau, outil ITSM, documentation interne et inventaire de parc. Cette ouverture permet un workflow transversal, mais agrandit aussi la frontière de confiance. Une donnée malveillante présente dans un ticket ou une documentation peut chercher à influencer l’agent ; chaque serveur doit donc conserver ses propres contrôles d’accès.

Le mouvement dépasse déjà le réseau : le blog BoucheCousue a présenté Logitech Sync MCP pour les salles de réunion et Neat Pulse MCP pour la gestion agentique. Cisco étend maintenant cette logique aux infrastructures qui transportent ces usages.

La possibilité d’ajouter un serveur dans Cursor, Claude ou Copilot ne vaut pas validation par la DSI. L’entreprise doit choisir les hôtes autorisés, les modèles utilisables, le lieu de traitement des données et les catégories d’informations réseau qui peuvent quitter son périmètre.

Pour Meraki, la clé doit appartenir à un administrateur en lecture seule. Pour Catalyst Center, le compte doit être créé avec le plus petit jeu de permissions compatible avec le scénario. Un compte personnel d’administrateur complet n’est pas une solution acceptable pour tester plus vite.

Une clé API ou un mot de passe ne doit jamais être collé dans un prompt, placé dans un fichier versionné ou exposé dans les journaux de l’agent. Le secret doit être fourni au processus par le trousseau du système, un gestionnaire de secrets ou un mécanisme d’injection adapté à l’environnement.

Quand le client le permet, l’administrateur doit n’activer que les outils nécessaires. Les opérations sensibles restent soumises à une confirmation humaine. Côté Catalyst Center, ce filtrage dans le client améliore l’usage mais ne remplace pas les permissions du compte, qui constituent la véritable barrière.

Un pilote doit comparer les résultats de l’agent avec la console et les méthodes habituelles. Il faut suivre la justesse des correspondances, les éléments manquants, les conclusions trop affirmatives, les appels inutiles, le temps gagné et les cas où l’agent sait s’arrêter.

Les journaux d’événements Meraki restent essentiels : l’interface conversationnelle ne doit pas rendre l’exploitation moins traçable.

Commencez par un seul environnement, une équipe support restreinte et deux ou trois demandes réelles. La première étape consiste uniquement à lire : inventaire, état de santé et enrichissement de tickets. Chaque réponse est vérifiée manuellement.

La deuxième étape ajoute un workflow, par exemple la création automatique d’une note privée dans l’outil ITSM ou d’un rapport quotidien. L’agent prépare le contenu ; une personne conserve la décision d’escalade.

La troisième étape n’est pertinente qu’après avoir mesuré les résultats. Pour Meraki, le serveur officiel reste de toute façon limité à la lecture. Pour Catalyst Center, toute ouverture d’écriture doit passer par un compte distinct, un scénario borné, une approbation explicite et une procédure de retour arrière.

Les serveurs MCP Cisco réduisent la distance entre la télémétrie réseau et le moment où une décision doit être prise. Un agent peut rassembler des faits, enrichir un ticket, produire un rapport et relier le réseau à d’autres systèmes sans qu’une intégration spécifique soit reconstruite pour chaque assistant.

Le gain potentiel est réel, surtout pour les équipes qui exploitent plusieurs sites. Il dépend cependant moins du nombre d’agents compatibles que de la qualité du périmètre : comptes dédiés, lecture seule, secrets protégés, outils filtrés, réponses vérifiables et journalisation.

MCP ne remplace ni la conception Wi-Fi, ni l’expertise de diagnostic, ni la responsabilité du changement. Il donne aux agents une nouvelle façon d’accéder aux outils. À l’entreprise de décider lesquels ils peuvent réellement utiliser.

Vous souhaitez évaluer Meraki MCP ou Catalyst Center MCP dans un workflow de support sans ouvrir trop largement votre infrastructure ? BoucheCousue peut vous accompagner pour choisir l’architecture, cadrer les identités techniques et construire un pilote en lecture seule sur des cas d’usage mesurables.