Pourquoi la latence entre Paris et Saint-Etienne a-t-elle doublé cet après-midi ? D’où viennent ces pics de trafic anormaux sur le VLAN 250 ? Pourquoi l’utilisateur n’arrive-t-il pas à se connecter à Microsoft Teams ? etc
Et si, au lieu d’ouvrir une dizaine de dashboards, de croiser manuellement les données et de perdre plusieurs minutes / heures à reconstituer le puzzle, vous pouviez simplement interroger votre infrastructure comme vous le feriez avec ChatGPT d’OpenAI, Le Chat de Mistral AI, etc ?
Nous utilisons tous des LLM pour nos questions du quotidien (rédiger un email, analyser du code, comprendre un concept, etc). Et si nous pouvions utiliser un LLM pour interagir avec notre infrastructure ?
Dans son article Faites entrer vos opérations dans l’ère de l’IA agentique avec AI Canvas, Jérôme DURAND présente AI Canvas, la solution clé en main de Cisco.
Ici, nous allons prendre une autre voie : comprendre les principes de base d’AI Canvas en construisant notre propre solution (très simplifiée).
Le besoin
Quand j’échange avec mes clients, j’ai souvent le même retour :
Trop de dashboards
Avec l’explosion des volumes de données et la complexité croissante des infrastructures, les dashboards se multiplient dans les organisations.
Le résultat ? Une navigation laborieuse entre des dizaines d’interfaces différentes qui ralentit l’analyse et la prise de décision. Chaque minute compte quand une urgence survient (faille de sécurité, panne système, pic de charge, etc). Parcourir plusieurs dashboards pour reconstituer une vision globale fait perdre un temps précieux.
Dashboards statiques
Même avec un dashboard centralisé qui agrège toutes les données, un défi majeur persiste : comment anticiper tous les KPI pertinents ? Les métriques configurées aujourd’hui reflètent notre compréhension actuelle du système, mais elles peuvent s’avérer insuffisantes face à un incident.
Et si l’indicateur clé pour résoudre le problème n’était pas celui qu’on surveille habituellement ? Et si une corrélation inattendue entre deux métriques révélait la root cause ? Les dashboards statiques, figés dans leur configuration initiale, risquent de nous faire passer à côté d’informations essentielles.
La solution
Model Context Protocol (MCP)
Le Model Context Protocol (MCP) est un protocole open-source développé par Anthropic permettant aux LLM (comme ceux de Mistral AI, OpenAI, etc) de communiquer directement avec des outils externes pour enrichir leur contexte.
L’analogie entre MCP et l’USB-C est souvent utilisée : tout comme l’USB-C a standardisé la connexion entre les appareils, MCP standardise la connexion entre les LLM et les outils.
L’architecture MCP repose sur trois composants simples :
- Le serveur MCP : un serveur qui expose les fonctionnalités de l’infrastructure (Catalyst Center, Meraki, Splunk, etc) sous forme d’outils standardisés.
- Le client MCP : un client qui permet au LLM d’aller consommer les fonctionnalités de l’infrastructure.
- Le protocole de communication : un format standardisé JSON-RPC qui permet au client et au serveur de dialoguer de manière sécurisée.
La bonne nouvelle ? Avec un contrôleur dans votre infrastructure (comme Catalyst Center, Meraki, Splunk, etc), aucune implémentation complexe n’est nécessaire. Les éditeurs comme Cisco ont désormais pour stratégie d’intégrer nativement des serveurs MCP dans leurs solutions. Certes, il faudra du temps avant que toutes les plateformes en disposent, mais des exemples concrets émergent déjà : Splunk propose son serveur MCP officiel, disponible dès maintenant sur Splunkbase.
En pratique (simplifiée)
Cette section a pour but d’expliquer comment les différents composants interagissent avec MCP.
Imaginons un scénario très simple : un utilisateur veut voir les VLAN actifs sur un Cisco Smart Switch 9350. Habituellement, il se connecterait au switch en CLI via SSH et taperait la commande “show vlan brief” :
Maintenant, voyons comment faire la même chose en utilisant un LLM et MCP :
Sous le capot, voici ce qu’il se passe :
 |
Le client MCP demande au serveur MCP la liste des outils disponibles. |
 |
Le serveur MCP répond au client MCP avec la liste des outils. |
 |
L’utilisateur demande au client MCP : “Quels sont les VLAN du switch 192.168.2.25 ?”. |
 |
Le client MCP agrège la requête utilisateur avec la liste des outils disponibles, puis transmet l’ensemble au LLM |
 |
Le LLM analyse la requête et détermine qu’il ne dispose pas des informations nécessaires dans son contexte actuel. Il identifie l’outil approprié : execute_cisco_commands. |
 |
Le client MCP sollicite le serveur MCP pour exécuter l’outil execute_cisco_commands |
 |
Le serveur MCP exécute l’outil, qui s’appuie sur une fonction Netmiko en Python. La commande CLI transmise en paramètre est : show vlan brief. Cette commande est exécutée sur l’équipement cible (switch 192.168.2.25). |
 |
Le serveur MCP reçoit le résultat de l’exécution de la fonction Netmiko (le show vlan brief). |
 |
Le serveur MCP transfère le résultat au client MCP |
 |
Le client MCP transfère le résultat au LLM |
 |
Le LLM intègre le résultat dans son contexte et formule une réponse listant les VLANs identifiés. Cette réponse est transmise au client MCP. |
 |
Le client MCP délivre la réponse finale à l’utilisateur. |
Cette approche transforme l’interaction avec votre infrastructure. Vous passez d’un ChatBot isolé qui ne peut que discuter, à un Agent IA capable d’agir sur votre infrastructure.
L’agent peut explorer des KPI auxquels vous n’auriez pas pensé, identifier des corrélations inattendues, et vous fournir une analyse complète sans que vous ayez à naviguer manuellement entre plusieurs interfaces.
Attention, ouvrir son infrastructure à des LLMs pose des questions de sécurité et de confidentialité importantes. Nous l’aborderons dans un prochain article.
En pratique (détaillée)
L’objectif de cette section est de voir plus en détail comment les différents éléments échangent avec MCP lorsque vous posez la question : “Quels sont les VLAN du device 192.168.2.25 ?”
Étape A et B : Le client MCP récupère la liste d’outils auprès du serveur MCP
Exemple :
MCP Client > MCP Server { "method": "tools/list", "jsonrpc": "2.0", "id": 1 }
MCP Server > MCP Client { "jsonrpc": "2.0", "id": 1, "result": { "tools": [ { "name": "execute_cisco_commands", "description": "Execute commands on a Cisco device using Netmiko. Args: host (str): IP address or hostname of the device, commands (list or str): Single command or list of commands to execute, device_type (str): Device type (default: \"cisco_ios\", Returns: dict: Dictionary with command as key and output as value", "inputSchema": { "properties": { "host": { "title": "host", "type": "string" }, "commands": { "title": "commands", "type": "string" }, "device_type": { "default": "cisco_ios", "title": "device_type", "type": "string" } }, "required": [ "host", "commands" ], "title": "execute_cisco_commandsArguments", "type": "object" } } ] } }
Étape 1 : L’utilisateur envoie son prompt au client MCP
Exemple :
Xavier > MCP Client { "model": "mistral-large-latest", "messages": [ { "role": "user", "content": "Quels sont les VLAN du device 192.168.2.25 ?" } ] }
Étape 2 : Le client MCP envoie le prompt avec la liste des outils au LLM
Exemple :
MCP Client > LLM { "model": "mistral-large-latest", "messages": [ { "role": "user", "content": "Quels sont les VLAN du device 192.168.2.25 ?" } ], "tools": [ { "name": "execute_cisco_commands", ...}, ... ] }
Étape 3 : Le LLM décide d’utiliser un outil et fait une requête au client MCP
Exemple :
LLM > MCP Client { "method": "tools/call", "params": { "name": "execute_cisco_commands", "arguments": {"host": "192.168.2.25", "commands": "show vlan brief"} }, "jsonrpc": "2.0", "id": 2 }
Étape 4 : Le client MCP appelle l’outil auprès du serveur MCP
Exemple :
MCP Client > MCP Server { "method": "tools/call", "params": { "name": "execute_cisco_commands", "arguments": {"host": "192.168.2.25", "commands": "show vlan brief"} }, "jsonrpc": "2.0", "id": 2 }
Étape 5, 6 et 7 : Le serveur MCP exécute l’outil et partage la réponse avec le client MCP
Exemple :
MCP Server > Tool (Switch)
# Connect to device
net_connect = ConnectHandler(**device)
# Execute each command
output = net_connect.send_command("show vlan brief")
Tool (Switch) > MCP Server > MCP Client
Output for 'show vlan brief' on 192.168.2.25:
VLAN Name Status Ports
---- -------------------------------- --------- -------------------------------
1 default active
142 DATA active
199 MANAGEMENT active
1002 fddi-default act/unsup
1003 token-ring-default act/unsup
1004 fddinet-default act/unsup
1005 trnet-default act/unsup
Étape 8 : Le client MCP partage la réponse au LLM
Exemple :
MCP Client > LLM { "model": "mistral-large-latest", "messages": [ { "role": "user", "content": "Quels sont les VLAN du device 192.168.2.25 ?" }, { "role": "assistant", "tool_calls": [ { "id": "call_123456789", "type": "function", "function": { "name": "execute_cisco_commands" } } ] }, { "role": "tool", "tool_call_id": "call_123456789", "content": "<LIST VLAN FROM STEP 5>" } ], "tools": [...] }
Étape 9 et 10 : Le LLM répond à l’utilisateur avec le contexte obtenu par MCP
Exemple avec Le Chat de Mistral AI :
LLM > Xavier
Conclusion
Ce n’est que le début
Nous n’avons fait qu’effleurer ce qu’il est possible d’accomplir en connectant l’IA à votre infrastructure. Dans un prochain article, nous verrons un cas d’usage concret qui sera résolu via le Serveur MCP de Splunk avec de multiples recherches (ThousandEyes, Meraki, …)
L’IA évolue à une vitesse impressionnante, et cela redéfinit profondément les métiers de l’IT. Les compétences d’hier ne suffiront plus face aux défis qui arrivent. Comprendre les LLM, savoir automatiser intelligemment, déployer des agents IA au cœur de nos infrastructures : autant de savoir-faire indispensables pour rester pertinents. Se former dès aujourd’hui, c’est se donner les moyens de répondre aux besoins de demain.
L’avenir avec AI Canvas
Comme Jérôme DURAND l’a présenté dans l’article Faites entrer vos opérations dans l’ère de l’IA agentique avec AI Canvas, Cisco AI Canvas est une solution particulièrement avancé sur ce sujet. Cette solution pousse le concept de MCP beaucoup plus loin. Là où nous avons parlé de poser des questions à votre infrastructure, AI Canvas promet une interface générative, alimentée par Cisco AI Assistant, le Deep Network Model et MCP :
Authors
