IA : Xbot

Agent IA
MCP
Modèle local

xbot-trained-v1 : modèle de langage local pour XBot

XorMon propose son propre modèle de langage pour XBot, xbot-trained-v1, destiné aux installations qui ne doivent envoyer aucune donnée à un fournisseur cloud.
Il s’agit de Qwen3.5-9B affiné sur les outils propres à XorMon. Il s’exécute sur votre serveur dans Ollama. Ollama n’est que le programme qui exécute le modèle ; le modèle lui-même ne figure pas dans le catalogue d’Ollama, vous le téléchargez chez nous.

Prérequis

XorMon 2.4.0 ou version plus récente avec l’agent XBot en fonctionnement, voir Installer l’agent XBot.
Un serveur doté d’un GPU NVIDIA avec au moins 16 Go de mémoire (testé sur une RTX PRO 2000 16 Go), Linux avec systemd, le pilote NVIDIA installé (nvidia-smi doit lister la carte) et environ 25 Go d’espace disque libre.
Le modèle seul occupe environ 10 Go de mémoire GPU, le reste est utilisé par les longues instructions que XBot envoie. Sans GPU le modèle fonctionne, mais les réponses prennent plusieurs minutes.
Ollama 0.34.4 ou version plus récente.
Accès root sur le serveur GPU (toutes les commandes ci-dessous s’exécutent en root ou avec sudo).
Réseau : XorMon doit pouvoir joindre le port 11434 sur le serveur GPU.

Téléchargement

Téléchargez xbot-trained-v1.
Le téléchargement contient :

model-12m4b-q8_0.gguf : le modèle (9 786 060 160 octets)
Modelfile : la façon dont Ollama crée le modèle
xbot-warmup.json : une première requête qui charge en mémoire les instructions de XBot et ses 41 outils
SHA256SUMS : sommes de contrôle

Copiez les fichiers dans un même répertoire sur le serveur GPU, par exemple /opt/xbot-trained-v1, et vérifiez-les à cet endroit :

cd /opt/xbot-trained-v1
sha256sum -c SHA256SUMS

Chaque ligne doit se terminer par OK.

1. Installer Ollama

Si Ollama n’est pas encore installé (voir ollama.com/download) :

curl -fsSL https://ollama.com/install.sh | sh
ollama --version

Le programme d’installation crée le service ollama.service. La version doit être 0.34.4 ou plus récente.

2. Configurer le service Ollama

Ne modifiez pas ollama.service lui-même : une mise à niveau d’Ollama l’écrase. Placez les réglages dans un fichier de surcharge :

mkdir -p /etc/systemd/system/ollama.service.d
cat > /etc/systemd/system/ollama.service.d/override.conf <<'EOF'
[Service]
Environment="OLLAMA_HOST=0.0.0.0:11434"
Environment="LLAMA_ARG_CHECKPOINT_MIN_SPACING_NT=1024"
Environment="OLLAMA_GO_TEMPLATE=1"
Environment="OLLAMA_KEEP_ALIVE=-1"
Environment="OLLAMA_MAX_LOADED_MODELS=1"
Environment="OLLAMA_NUM_PARALLEL=1"
Environment="OLLAMA_FLASH_ATTENTION=1"
Environment="OLLAMA_KV_CACHE_TYPE=q8_0"
EOF
systemctl daemon-reload
systemctl restart ollama
systemctl show ollama -p Environment

La dernière commande doit afficher toutes les variables ci-dessus. Si ce n’est pas le cas, le service ne les utilise pas : le modèle est déchargé au bout d’un moment, ou les longues instructions de XBot sont tronquées.

Rôle des réglages :

OLLAMA_HOST=0.0.0.0:11434 : Ollama écoute sur toutes les adresses du serveur, afin que XorMon puisse le joindre. Ollama n’a pas de mot de passe : quiconque atteint le port peut utiliser le modèle. N’autorisez le port 11434 que depuis le serveur XorMon (voir Sécurité). Si XorMon s’exécute sur le même serveur, utilisez 127.0.0.1:11434 à la place.
LLAMA_ARG_CHECKPOINT_MIN_SPACING_NT=1024 : Ollama réutilise d’une question à l’autre les instructions déjà traitées au lieu de les relire. Sans cela, chaque question est plus lente.
OLLAMA_GO_TEMPLATE=1 : Ollama utilise le modèle de formatage issu du Modelfile. Sans cela, le modèle reçoit ses entrées sous une forme différente de celle sur laquelle il a été entraîné et répond mal.
OLLAMA_KEEP_ALIVE=-1 : le modèle reste en permanence dans la mémoire GPU.
OLLAMA_MAX_LOADED_MODELS=1 et OLLAMA_NUM_PARALLEL=1 : une seule copie du modèle, une seule question à la fois. Davantage de copies ne tiennent pas dans la mémoire GPU.
OLLAMA_FLASH_ATTENTION=1 et OLLAMA_KV_CACHE_TYPE=q8_0 : économisent la mémoire GPU. Nécessaires sur une carte de 16 Go ; sur une carte de 24 Go ou plus, vous pouvez omettre ces deux lignes.

3. Créer le modèle

cd /opt/xbot-trained-v1
ollama create xbot-trained-v1 -f Modelfile
ollama list

Le nom doit être exactement xbot-trained-v1 (une étiquette telle que xbot-trained-v1:latest convient). XorMon reconnaît le modèle à ce nom et lui envoie les instructions sous la forme sur laquelle il a été entraîné. Sous tout autre nom, le modèle reçoit les instructions génériques de XorMon et répond mal.

Le Modelfile définit le modèle de formatage et un contexte de 65 536 jetons. N’abaissez pas le contexte : les instructions de XBot seraient tronquées et le modèle ne verrait pas ses outils.

4. Charger les instructions après chaque démarrage (préchauffage)

La première question après un démarrage est lente, car le modèle doit lire les longues instructions de XBot et les descriptions de ses 41 outils. Une requête de préchauffage s’en charge juste après le démarrage du serveur, si bien que la première vraie question est rapide.

Copiez la requête de préchauffage et créez le script :

install -d /usr/local/share/xbot-trained-v1
cp /opt/xbot-trained-v1/xbot-warmup.json /usr/local/share/xbot-trained-v1/
cat > /usr/local/bin/xbot-trained-v1-warmup.sh <<'EOF'
#!/bin/bash
for _ in $(seq 1 60); do
  curl -sf http://127.0.0.1:11434/api/version >/dev/null && break
  sleep 1
done
curl -sf http://127.0.0.1:11434/api/chat \
  -H "Content-Type: application/json" \
  --data-binary @/usr/local/share/xbot-trained-v1/xbot-warmup.json \
  -o /var/lib/xbot-trained-v1-warmup.json
EOF
chmod 755 /usr/local/bin/xbot-trained-v1-warmup.sh

Créez le service qui l’exécute après le démarrage d’Ollama :

cat > /etc/systemd/system/xbot-trained-v1-warmup.service <<'EOF'
[Unit]
Description=Warm up xbot-trained-v1 after Ollama starts
After=ollama.service
Requires=ollama.service

[Service]
Type=oneshot
ExecStart=/usr/local/bin/xbot-trained-v1-warmup.sh
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target
EOF
systemctl daemon-reload
systemctl enable --now xbot-trained-v1-warmup.service

Vérification :

ollama ps

Le modèle xbot-trained-v1 doit apparaître avec 100% GPU, un contexte de 65536 et UNTIL Forever. Si PROCESSOR indique une part CPU, le modèle n’a pas tenu dans la mémoire GPU et les réponses sont lentes.

Le préchauffage s’exécute au démarrage du serveur. Si vous ne redémarrez qu’Ollama, lancez-le manuellement :

systemctl restart xbot-trained-v1-warmup.service

5. Connecter XorMon

Interface ➡ Settings ➡ Application ➡ AI ➡ XBot AI Chat :

LLM Provider : Ollama (auto-hébergé)
Endpoint : http://<gpu-server>:11434/api/chat (http://<gpu-server>:11434 fonctionne aussi)
Modèle : xbot-trained-v1
API Key : laisser vide

Enregistrez, puis appuyez sur Test. La question de test « How many devices does XorMon monitor ? » doit indiquer que la réponse correspond à XorMon.

Sécurité

Ollama n’a ni comptes utilisateur ni mots de passe. N’autorisez le port 11434 que depuis le serveur XorMon, jamais depuis Internet. Exemple avec ufw :

ufw allow from <xormon-ip> to any port 11434 proto tcp
ufw deny 11434/tcp

Le modèle ne reçoit que les résultats des outils de XBot, lus avec les droits de l’utilisateur qui pose la question. Rien ne sort de votre réseau.

Passer à une nouvelle version du modèle

Téléchargez les nouveaux fichiers, vérifiez-les avec sha256sum -c SHA256SUMS, puis recréez le modèle sous le même nom et préchauffez-le :

cd /opt/xbot-trained-v1
ollama create xbot-trained-v1 -f Modelfile
systemctl restart ollama
systemctl restart xbot-trained-v1-warmup.service

Rien ne change dans XorMon.

Dépannage

Les réponses sont lentes, ollama ps indique une part CPU : le modèle ne tient pas dans la mémoire GPU. Vérifiez que les deux lignes d’économie de mémoire figurent dans le fichier de surcharge et qu’aucun autre modèle n’est chargé (ollama ps).
La première question après un redémarrage est lente : exécutez le préchauffage (étape 4).
Le modèle répond sans utiliser les données de XorMon, ou répond mal : vérifiez le nom du modèle dans XorMon (exactement xbot-trained-v1) et que systemctl show ollama -p Environment liste bien OLLAMA_GO_TEMPLATE=1.
XorMon ne parvient pas à se connecter : sur le serveur XorMon, exécutez curl http://<gpu-server>:11434/api/version. Une absence de réponse signale un pare-feu, une mauvaise adresse, ou OLLAMA_HOST positionné sur 127.0.0.1.
Journaux : Ollama : journalctl -u ollama ; XorMon : server-nest/logs/pyxbot-agent.log et server-nest/logs/pyxbot-agent-error.log.

XorMon 2.4.0 apporte un XBot nettement enrichi, un chat IA intégré à XorMon.
Vous posez vos questions en langage courant (« Quelles VM ont le plus consommé de CPU hier ? », « Affiche la capacité de tous les pools de stockage en TB ») et XBot répond avec des tableaux, des valeurs, des graphiques et des liens vers les pages de XorMon.

Fonctionnement

XBot est un agent : le modèle de langage (LLM) décide quels outils XorMon appeler, et les outils lisent les données via l’API publique de XorMon avec les droits de l’utilisateur qui pose la question. Le modèle ne parcourt jamais la base de données de XorMon et ne voit jamais les objets que l’utilisateur n’a pas le droit de voir.
Les valeurs, les unités et les noms d’objets d’une réponse proviennent de XorMon, pas du modèle.
Avant d’afficher une réponse, XBot la confronte à ce qui a été réellement lu, et le signale lorsqu’une partie de la question n’a pas pu recevoir de réponse.
Les mêmes outils sont proposés aux clients IA externes via MCP, voir MCP.

Installer l’agent XBot

Le chat IA et MCP s’exécutent dans l’agent XBot, un service Python que XorMon démarre à côté de lui (il écoute uniquement sur 127.0.0.1:8610).

Image Docker : l’agent est inclus depuis la v2.4.0, rien à faire
Appliance XorMon : tout est inclus depuis la v2.4.0, rien à faire
Installation Linux : créez une fois l’environnement Python de l’agent, puis redémarrez XorMon.
Python 3.11 ou plus récent avec venv est nécessaire (Debian/Ubuntu : apt install python3-venv).
Sous l’utilisateur xormon :

cd ~/xormon-ng/server-nest
python3 -m venv pyxbotagent/.venv
pyxbotagent/.venv/bin/python -m pip install -r pyxbotagent/requirements.txt

Si python3 --version est antérieur à 3.11, créez l’environnement avec une version plus récente, par exemple python3.11 -m venv pyxbotagent/.venv.
Après un redémarrage, XorMon démarre l’agent automatiquement.

Vérification : interface ➡ Settings ➡ Application ➡ AI.
Si l’agent est absent ou arrêté, la page l’indique et en donne la raison.
La carte MCP liste également les outils disponibles (« Tools : N tools available »).
Journaux : server-nest/logs/pyxbot-agent.log et server-nest/logs/pyxbot-agent-error.log.

Connecter un modèle de langage

Interface ➡ Settings ➡ Application ➡ AI ➡ XBot AI Chat : activez « AI chat enabled », choisissez le fournisseur, l’endpoint, la clé API et le modèle, enregistrez, puis appuyez sur Test (cela vérifie que le chat peut utiliser le modèle).

Fournisseurs pris en charge : Anthropic (Claude), OpenAI, Ollama (auto-hébergé), DeepSeek et WatsonX. Le modèle doit prendre en charge l’appel d’outils.

Quel modèle choisir : le plus coûteux n’est pas nécessaire

XBot effectue la lecture, le filtrage et les calculs dans son propre code. Le modèle choisit les outils et rédige les phrases. C’est pourquoi un modèle petit et rapide suffit pour la plupart des questions :

Démarrage recommandé : un modèle de petite ou moyenne taille, par exemple Claude Haiku 4.5 ou Claude Sonnet.
Lors de nos tests, les réponses de Haiku et de Sonnet étaient d’aussi bonne qualité.
Les grands modèles (par exemple Claude Opus) coûtent plusieurs fois plus cher par question et sont rarement nécessaires pour des questions de supervision.
Auto-hébergé (Ollama) : vos données restent dans vos locaux. Utilisez un modèle dont l’appel d’outils est fiable ; les petits modèles locaux répondent de façon moins fiable.

Données et sécurité

Le modèle ne reçoit que les résultats des outils, lus avec les droits de l’utilisateur qui pose la question, jamais la base de données.
La clé API du fournisseur du modèle est stockée dans les réglages de XorMon et n’est plus jamais affichée après l’enregistrement.
L’agent écoute uniquement sur l’interface locale (127.0.0.1) ; les clients externes utilisent MCP via l’API HTTPS de XorMon avec une clé API utilisateur.

XorMon expose ses outils XBot via le Model Context Protocol (MCP).
Un client IA que vous utilisez déjà, comme Cursor, VS Code avec GitHub Copilot, Claude Code, Claude Desktop ou Codex, peut alors interroger XorMon sur votre infrastructure. Il voit exactement ce que votre utilisateur XorMon a le droit de voir.

Ce qu’il vous faut

L’agent XBot installé et en cours d’exécution : les outils de MCP s’exécutent dans l’agent XBot, un service Python que XorMon démarre à côté de lui.
L’image Docker et l’appliance XorMon l’incluent ; une installation Linux nécessite de l’installer une fois, voir Installer l’agent XBot.
MCP ne nécessite aucune clé LLM dans XorMon : votre client apporte son propre modèle.
MCP activé : interface ➡ Settings ➡ Application ➡ AI ➡ MCP enabled. Un administrateur le fait une fois.
L’adresse du serveur : https://<xormon>/api/public/v1/llm/mcp. La même page de réglages l’affiche, prête à copier, sous Client JSON.
Votre propre clé API : profil utilisateur ➡ API Keys. La clé agit avec les droits de votre utilisateur, chaque personne doit donc utiliser la sienne.

Le client envoie la clé dans l’en-tête HTTP apiKey.

Outils

Une quarantaine d’outils couvrent les objets et la recherche, les métriques, les alertes et la santé, les relations et la topologie, les résultats et les sélections, ainsi que l’aide. La liste actuelle, avec la description de chaque outil, se trouve dans interface ➡ Settings ➡ Application ➡ AI (MCP ➡ Tools ➡ show), et tout client MCP les liste après connexion.

Deux façons de se connecter

En direct. Le client appelle lui-même l’adresse et envoie l’en-tête apiKey. Cela nécessite un certificat auquel le client fait confiance, voir Certificat.
Via mcp-remote. Une petite passerelle que le client démarre sur votre ordinateur (npx mcp-remote, elle nécessite Node.js). Utilisez-la pour Claude Desktop, et pour tout client tant que XorMon conserve son certificat auto-signé par défaut.

Cursor

Fichier ~/.cursor/mcp.json (tous les projets) ou .cursor/mcp.json (un seul projet) :

{
  "mcpServers": {
    "xormon": {
      "url": "https://<xormon>/api/public/v1/llm/mcp",
      "headers": { "apiKey": "<your-api-key>" }
    }
  }
}

Il s’agit du Client JSON de la page de réglages XorMon. Avec le certificat auto-signé par défaut, placez plutôt dans ce même fichier la forme mcp-remote décrite dans Claude Desktop.

Documentation Cursor : https://cursor.com/docs/mcp

VS Code avec GitHub Copilot

Fichier .vscode/mcp.json dans l’espace de travail, ou exécutez MCP : Open User Configuration pour tous les espaces de travail. VS Code demande la clé une fois et la garde hors du fichier :

{
  "inputs": [
    { "type": "promptString", "id": "xormon-api-key", "description": "XorMon API key", "password": true }
  ],
  "servers": {
    "xormon": {
      "type": "http",
      "url": "https://<xormon>/api/public/v1/llm/mcp",
      "headers": { "apiKey": "${input:xormon-api-key}" }
    }
  }
}

Utilisez les outils dans Copilot Chat en mode Agent. Avec le certificat auto-signé par défaut, définissez le serveur avec "type": "stdio" et les clés command, args et env de Claude Desktop.

Documentation VS Code : https://code.visualstudio.com/docs/agent-customization/mcp-servers

GitHub Copilot dans Visual Studio et les IDE JetBrains

Visual Studio 2022 17.14 ou ultérieur : fichier %USERPROFILE%\.mcp.json (toutes les solutions) ou .mcp.json dans le dossier de la solution, avec le même bloc "servers" que pour VS Code et la clé inscrite dans "headers".
IDE JetBrains : ouvrez mcp.json depuis les réglages de Copilot. Les en-têtes se placent sous requestInit :

{
  "servers": {
    "xormon": {
      "url": "https://<xormon>/api/public/v1/llm/mcp",
      "requestInit": { "headers": { "apiKey": "<your-api-key>" } }
    }
  }
}

Documentation : https://learn.microsoft.com/en-us/visualstudio/ide/mcp-servers et https://docs.github.com/en/copilot/how-tos/provide-context/use-mcp/extend-copilot-chat-with-mcp (couvre aussi Eclipse et Xcode).

Claude Code

claude mcp add --transport http xormon https://<xormon>/api/public/v1/llm/mcp --header "apiKey: <your-api-key>"

Vérifiez avec claude mcp list. Avec le certificat auto-signé par défaut, ajoutez plutôt le serveur via mcp-remote, afin que le réglage ne s’applique qu’à ce serveur :

claude mcp add --env NODE_TLS_REJECT_UNAUTHORIZED=0 --transport stdio xormon -- npx -y mcp-remote https://<xormon>/api/public/v1/llm/mcp --header apiKey:<your-api-key> --transport http-only

Documentation Claude Code : https://code.claude.com/docs/en/mcp

Claude Desktop

Ouvrez interface ➡ Settings ➡ Developer ➡ Edit Config. Le fichier est ~/Library/Application Support/Claude/claude_desktop_config.json sous macOS et %APPDATA%\Claude\claude_desktop_config.json sous Windows :

{
  "mcpServers": {
    "xormon": {
      "command": "npx",
      "args": [
        "-y", "mcp-remote",
        "https://<xormon>/api/public/v1/llm/mcp",
        "--header", "apiKey:<your-api-key>",
        "--transport", "http-only"
      ],
      "env": { "NODE_TLS_REJECT_UNAUTHORIZED": "0" }
    }
  }
}

Omettez la ligne env dès que XorMon dispose d’un certificat de confiance. Quittez ensuite complètement Claude Desktop et relancez-le. Les Connectors de Claude (Customize ➡ Connectors) ne peuvent pas joindre XorMon, voir Non pris en charge.

Documentation : https://modelcontextprotocol.io/docs/develop/connect-local-servers et https://github.com/geelen/mcp-remote

Codex (CLI et extension IDE)

La CLI Codex et son extension VS Code partagent ~/.codex/config.toml :

[mcp_servers.xormon]
url = "https://<xormon>/api/public/v1/llm/mcp"
env_http_headers = { "apiKey" = "XORMON_API_KEY" }

Codex lit la clé dans la variable d’environnement XORMON_API_KEY. Pour conserver la clé dans le fichier, écrivez plutôt http_headers = { "apiKey" = "<your-api-key>" }.

Avec le certificat auto-signé par défaut :

[mcp_servers.xormon]
command = "npx"
args = ["-y", "mcp-remote", "https://<xormon>/api/public/v1/llm/mcp", "--header", "apiKey:<your-api-key>", "--transport", "http-only"]

[mcp_servers.xormon.env]
NODE_TLS_REJECT_UNAUTHORIZED = "0"

Sous Windows, écrivez command = "C:\\Program Files\\nodejs\\npx.cmd".

Documentation Codex : https://learn.chatgpt.com/docs/extend/mcp?surface=cli

Autres clients

Un client qui appelle une adresse avec ses propres en-têtes : utilisez l’adresse et l’en-tête apiKey.
Un client qui démarre une commande locale : npx -y mcp-remote https://<xormon>/api/public/v1/llm/mcp --header apiKey:<your-api-key> --transport http-only

Certificat

Le certificat par défaut de XorMon est auto-signé et émis pour localhost. Un client qui se connecte par adresse IP ou par nom d’hôte le refuse.

Recommandé : téléversez un certificat émis pour le nom que vous utilisez pour joindre XorMon (UI ➡ Settings ➡ Application ➡ SSL Cert). Les configurations directes fonctionnent alors telles quelles.
Sinon : connectez-vous via mcp-remote avec NODE_TLS_REJECT_UNAUTHORIZED=0. Cela désactive la vérification du certificat pour ce pont uniquement. À n’utiliser que sur un réseau de confiance.

Remarques pour Windows

Installez Node.js LTS depuis https://nodejs.org/. Il fournit npx.
Certains clients exigent le chemin complet C:\Program Files\nodejs\npx.cmd ; c’est le cas de Codex.
Écrivez l’en-tête sans espace : apiKey:<your-api-key>. Sur Windows, Cursor, Codex et Claude Desktop ne gèrent pas les arguments contenant des espaces.

Non pris en charge

Les connecteurs cloud, c’est-à-dire les Claude Connectors (claude.ai, Customize ➡ Connectors) et les connecteurs ChatGPT, appellent le serveur depuis le cloud de l’éditeur.
Un XorMon situé sur le réseau de votre entreprise n’est pas joignable depuis là, et ces connecteurs ne proposent pas l’en-tête apiKey.
Utilisez un client qui s’exécute sur votre ordinateur.

Sécurité

La clé agit avec vos droits XorMon. Ne la partagez pas et ne versionnez pas les fichiers de configuration qui la contiennent.
Gardez la clé hors du fichier lorsque le client le permet : inputs pour VS Code, env_http_headers pour Codex.
Supprimez les clés que vous n’utilisez plus : User profile ➡ API Keys.

Passer de la version 2.3.x à la version 2.4.0

Le point d’accès MCP conserve son adresse (/api/public/v1/llm/mcp) et l’en-tête apiKey, mais depuis la 2.4.0 il expose les outils de l’agent XBot (environ 40) au lieu des 12 outils de l’ancien serveur intégré.

Redémarrez ou reconnectez votre client MCP une fois après la mise à niveau, afin qu’il charge la nouvelle liste d’outils.
MCP nécessite désormais que l’agent XBot soit installé et en cours d’exécution sur le serveur XorMon. Si UI ➡ Settings ➡ Application ➡ AI affiche « Tools unavailable », l’agent n’est pas en cours d’exécution.
Lorsque MCP est désactivé, le point d’accès répond 503 (auparavant : 400).

Vérifier la connexion

UI ➡ Settings ➡ Application ➡ AI affiche Tools : N tools available lorsque XorMon liste ses outils MCP ; show les énumère.
Le bouton Test de cette page vérifie le modèle du chat IA, pas MCP.
Depuis un terminal sous macOS ou Linux (-k ignore la vérification du certificat pour ce seul test) :

curl -k -X POST https://<xormon>/api/public/v1/llm/mcp -H "apiKey: <your-api-key>" -H "Content-Type: application/json" -H "Accept: application/json, text/event-stream" -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'

Une liste JSON d’outils signifie que l’adresse et la clé fonctionnent.

401 « Missing API key » ou « Bad or expired API key » : la clé est absente, mal saisie ou expirée.
406 « Not Acceptable » : le client doit accepter à la fois application/json et text/event-stream.
503 : MCP est désactivé dans XorMon.
Côté client : claude mcp list dans Claude Code ; Claude Desktop écrit mcp*.log dans ~/Library/Logs/Claude (macOS) ou %APPDATA%\Claude\logs (Windows).

Serveur Model Context Protocol (MCP)

Le produit permet d’activer un serveur MCP (Model Context Protocol) intégré, qui assure un partage sécurisé et contrôlé de tous les outils internes disponibles avec des systèmes de chat IA externes.
Une fois le serveur MCP activé, les clients IA externes peuvent accéder à l’ensemble des outils tout en restant dans les limites de sécurité et d’autorisation définies.

Cette fonctionnalité simplifie l’automatisation et l’intégration en permettant aux processus pilotés par l’IA d’interagir directement avec les capacités du produit, tout en maintenant une séparation nette entre la logique interne et les interfaces externes.

L’activation du serveur MCP se fait via UI ➡ Settings ➡ Application ➡ AI Chat et ne demande aucune étape de déploiement supplémentaire.

Xormon permet de connecter en toute simplicité votre propre modèle de langage (LLM) ou des fournisseurs tiers (tels qu’OpenAI) directement à la plateforme.
Vous bénéficiez ainsi de la puissance de l’IA conversationnelle tout en donnant au modèle un accès contrôlé aux données et aux capacités de Xormon.

Veuillez noter que XorMon v2.4.0 (sept. 2026) intègre un agent IA nettement amélioré.

Fonctionnement

Xormon utilise un mécanisme d’appel d’outils qui expose au LLM certaines fonctions de l’application. Au lieu d’accorder un accès direct aux données brutes, le modèle interagit avec Xormon au moyen d’outils prédéfinis. Ces outils peuvent interroger les données, exécuter des actions et renvoyer des résultats structurés, que le LLM interprète ensuite et présente à l’utilisateur sous une forme naturelle et conversationnelle.

Concrètement, cela signifie :

Vous pouvez connecter votre propre modèle hébergé ou vous intégrer à un fournisseur comme OpenAI.
Le LLM ne peut appeler que les fonctions que vous exposez explicitement.
Les résultats sont renvoyés de façon structurée, ce qui garantit une intégration fiable et sûre.
Le modèle se charge de la présentation, tandis que Xormon assure une récupération des données sûre et exacte.

Avantages

Souplesse : choisissez n’importe quel fournisseur de LLM ou utilisez votre propre déploiement.
Sécurité : contrôle fin des fonctions que le modèle peut appeler.
Cohérence : les données proviennent toujours des sources vérifiées de Xormon.
Expérience fluide : les utilisateurs dialoguent naturellement avec le modèle tout en obtenant des résultats précis.

Exemples de cas d’usage

Interroger votre infrastructure pour savoir quels serveurs ou machines virtuelles sont en cours d’exécution, leur état et leur état de santé.
Rechercher et filtrer les ressources selon des paramètres comme le WWN, les alertes ou les métriques de performance.
Mettre en forme la sortie dans des structures lisibles, par exemple des fichiers CSV, en vue d’analyses complémentaires.

Modèles LLM testés

Ollama
OpenAI
Deepseek
WatsonX

Vous pouvez rattacher les modèles prédéfinis ci-dessus ou tout autre modèle fondé sur un LLM.

Implications en matière de sécurité

L’IA rattachée n’analyse pas la base de données XorMon.
Elle sert uniquement à traduire des mots et des phrases en requêtes et à restituer le résultat.