Les applications MCP modifient la forme de cette réponse. Un outil peut désormais renvoyer une interface utilisateur accompagnée de son résumé textuel, et de l’hôte (Claude Desktop, Claude.ai, VS Code Copilot, Cursor) l’affiche directement dans la conversation. Le modèle conserve le texte compact pour l’analyse. L'utilisateur dispose d'une interface interactive et cliquable juste à côté du chat.

Trois caractéristiques distinguent cette approche d’une simple intégration de type « webhook qui renvoie une URL » :

• Préservation du contexte. L'interface utilisateur est intégrée à la conversation. Pas de changement d'onglets, pas de transferts.

• Flux de données bidirectionnel. L'interface utilisateur peut appeler des outils sur le serveur MCP pour obtenir des données actualisées, et l'hôte peut renvoyer de nouveaux résultats de l'agent dans l'interface utilisateur. Aucune couche API séparée ni infrastructure d'authentification.

• Limite de confiance isolée. Les applications MCP fonctionnent dans un iframe contrôlé par l'hôte. Ils ne peuvent pas accéder à la page parent, lire les cookies, ni échapper à leur conteneur.

Les opérations de sécurité reposent sur le triage, les graphes d’investigation et Attack Discovery, où un agent d’IA corrèle des centaines d’alertes pour les regrouper en quelques chaînes d’attaque. Observability repose sur des traces distribuées et des analyses détaillées de séries temporelles. Créer dans Kibana, c’est travailler avec une grille de tableaux de bord. Réduisez tout cela à du texte, et vous perdez ce qui en fait la valeur. Nous avons créé des applications MCP pour les trois domaines et les publions en open source ensemble. Résultat : une même conversation peut passer d’une file de triage à un graphe de dépendances, puis à un tableau de bord en temps réel, sans jamais quitter le chat.

Chacune des trois applications de référence repose sur un serveur MCP unique qui fournit de nombreuses vues interactives, et non un ensemble de produits distincts. À elle seule, l’application de sécurité expose six tableaux de bord reposant sur le même environnement serveur, le même modèle de visibilité des outils et le même pont hôte. Le modèle est minimal ; c’est la surface d’interaction qui crée la valeur.

Application Elastic Security MCP

Pourquoi c’est essentiel pour le SOC

Lorsqu’un agent dit à un analyste SOC : « Il y a 47 alertes sur host-314, voici un résumé », cela n’a rien fait. Il indique simplement où le travail commence. Le travail réel réside dans la liste des alertes, l'arborescence des processus, le graphe d'investigation et le dossier de l'affaire. Vous ne pouvez pas le faire à partir d'un paragraphe de texte.

L’application MCP de sécurité restitue directement le workflow lui-même L'analyste invite l'agent, et l'agent renvoie un tableau de bord interactif dans le chat où l'analyste peut approfondir les alertes, effectuer des exécutions de recherche de menaces, corréler les chaînes d'attaque et ouvrir des dossiers, le tout sans perdre le fil de la conversation. Et comme les résultats, les requêtes et les cas sont tous renvoyés dans Elasticsearch, la même enquête est en cours sur Kibana, où l'analyste pourra répondre une fois la conversation terminée.

Six tableaux de bord interactifs

L'application MCP d'Elastic Security contient six éléments interactifs, un par workflow SOC majeur. Chacun est une interface utilisateur React qui est rendue en ligne lorsque l'agent appelle l'outil correspondant :

Outil

Ce qu'il fait

Interface utilisateur interactive

Tri des alertes

Récupérer, filtrer et classer les alertes de sécurité

Groupement par gravité, cartes de verdict IA, arborescence de processus, événements réseau

Attack Discovery

Analyse de chaîne d'attaque corrélée par IA avec génération à la demande

Cartes narratives des attaques avec un score de confiance, risque d'entité, Mapping MITRE

Gestion des incidents

Créer, rechercher et gérer des cas d'enquête

Liste des cas avec alertes, observables, onglets de commentaires et actions d'IA

Règles de détection

Parcourez, ajustez et gérez les règles de détection

Navigateur de règles avec recherche KQL, validation des requêtes et analyse des règles bruyantes

Chasse aux menaces

Espace de travail ES|QL avec investigation des entités

Éditeur de requêtes, entités cliquables et graphe d’investigation

Exemple de données

Générer des événements de sécurité ECS pour des scénarios d’attaque courants

Sélecteur de scénarios avec quatre chaînes d’attaque prêtes à l’emploi

Chaque outil renvoie un résumé textuel compact sur lequel le modèle peut raisonner, parallèlement à l'interface utilisateur interactive sur laquelle l'analyste agit. L'interface utilisateur peut également récupérer de nouvelles données en arrière-plan via le pont hôte MCP. Le modèle complet de l'outil et l'API de la passerelle se trouvent dans la documentation sur l'architecture du repo.

L’application inclut également les compétences Claude Desktop, des fichiers SKILL.md qui apprennent à l’agent quand et comment utiliser chaque outil. Téléchargez des archives ZIP de compétences précompilées depuis la dernière version.

De l’alerte au cas

Quatre compétences couvrent la boucle du noyau SOC. Chacun récupère une invite, appelle un outil et renvoie un tableau de bord interactif avec un résumé textuel que le modèle analyse. La journée d'un analyste commence généralement par une file d'alerte.

Alertes de triage. Demandez à l'agent de trier par hôte, règle, utilisateur ou fenêtre temporelle. La compétence de triage des alertes affiche un tableau de bord des verdicts d'IA au-dessus de la liste brute des alertes, avec un verdict par règle de détection classant l'activité de cette règle comme bénigne, suspecte ou malveillante, chacune avec un score de confiance et une action recommandée. Cliquez sur n'importe quelle alerte pour ouvrir une vue détaillée avec une arborescence des processus, les événements du réseau, les alertes connexes et les étiquettes MITRE ATT&CK. Pas besoin de basculer de contexte entre la conversation IA et votre tableau de bord d'alertes dans Kibana, tout se passe en temps réel au sein de votre conversation.

Chasser les menaces. Demandez à l'agent de rechercher dans tous vos index. La compétence Threat Hunt renvoie un atelier ES|QL avec la requête pré-remplie et exécutée automatiquement, chaque entité des résultats étant cliquable pour une exploration plus approfondie. Le modèle écrit un court résumé sous le tableau : ce qui est inhabituel, ce qui est connecté, ce qui mérite un examen plus approfondi. Il propose ensuite le prochain pivot : soit approfondir la recherche de menaces, soit commencer une nouvelle compétence au sein de l'application MCP qui complète le travail effectué jusqu'à présent. Ce qui lie tout cela de manière très cohérente, c’est le lancement d’une Découverte d’attaques pour recueillir plus de contexte sur les alertes que vous avez approfondies et les menaces que vous avez recherchées jusqu’à présent.

Lancer la détection des attaques. La compétence Attack Discovery déclenche l'API Attack Discovery et renvoie une liste classée de résultats. Chaque constatation est un ensemble d'alertes connexes regroupées en une chaîne d'attaque, avec les tactiques de MITRE, un score de risque, un label de confiance, et les hôtes et utilisateurs concernés présentés en amont. Le résumé de l’agent se situe en dessous des résultats dans le même ordre de classement, et la conversation contient désormais tout ce qui est nécessaire pour agir : requêtes de recherche, décisions de tri, chaînes corrélées, tout est prêt pour la prochaine étape.

Ouvrez des dossiers sans quitter le chat. Approuvez les découvertes en masse ou demandez à l'agent d'ouvrir des cas pour des alertes spécifiques. La compétence de gestion des cas crée un cas par découverte approuvée (alertes sources jointes, tactiques MITRE héritées de la chaîne d'attaque) et affiche la liste des cas en direct. Cliquez sur un cas pour afficher sa vue détaillée, qui comprend une série de boutons d'action IA : Résumer le cas, Suggérer les prochaines étapes, Extraire les IOC et Générer une chronologie. Chacun renvoie une invite structurée dans le chat, de sorte que l'agent reprenne le contexte du cas sans avoir besoin d'une réintroduction. Le résumé de l'agent se trouve sous la liste des cas et couvre l'intégralité de la file d'attente IR, y compris les cas récemment ouverts et les découvertes antérieures qui nécessitent encore une action.

Chaque étape de ce parcours suit la même boucle : une requête arrive, la compétence la prend en charge, l’outil renvoie un résumé textuel concis que le modèle peut exploiter, accompagné d’une interface utilisateur interactive sur laquelle l’analyste agit. Enchaînez les compétences, et elles s’assemblent en un flux SOC de bout en bout — chasse, triage, corrélation, ouverture de cas et pilotage des pivots suivants — le tout avec un modèle qui conserve le contexte de session à chaque étape. Utilisez n’importe laquelle de ces fonctionnalités individuellement, et vous accédez toujours à un tableau de bord complet, centré sur le segment de données de votre choix. Dans tous les cas, le travail s’accumule dans la conversation : aucun changement d’onglet, aucun copier-coller, aucun transfert.

Deux fonctionnalités supplémentaires complètent l’application : un navigateur de règles de détection pour ajuster les règles bruyantes, et un générateur de données d’exemple pour produire des événements ECS réalistes sur un cluster vierge. Un prochain article approfondira l’ensemble des six fonctionnalités : graphe d’investigation, canevas de flux d’attaque et parcours de bout en bout.

Fonctionnement

Chaque application MCP est un petit serveur Node.js dont les outils renvoient à la fois un résumé textuel compact pour le modèle et une interface utilisateur React que l’hôte rend en ligne. Parce qu'il est construit sur la spécification ouverte de l'application MCP, le même serveur fonctionne sur n'importe quel hôte compatible — voir la documentation sur l'architecture du dépôt pour la conception complète.

Faites l'essai

Nécessite Elasticsearch 9.x avec Security activé, ainsi que Kibana pour les cas, les règles et la Découverte d'attaques. Le chemin le plus rapide est le bundle .mcpb en un clic de la dernière version — double-cliquez dessus dans Claude Desktop, et vous serez invité à fournir votre URL Elasticsearch et votre clé API. Les guides d’installation pour Cursor, VS Code, Claude Code, Claude.ai et la compilation à partir du code source se trouvent dans le dépôt.

Elastic Search MCP App : des tableaux de bord créés à partir de la conversation

Tous les utilisateurs de Kibana connaissent ce détour par les tableaux de bord : quitter leur tâche en cours, ouvrir Kibana, choisir un index, sélectionner des champs, créer une visualisation, ajuster, puis enregistrer. C'est cinq changements de contexte avant qu'un seul graphique ne soit à l'écran.

La nouvelle application de référence example-mcp-dashbuilder résume tout cela en une invite. Demandez à l’agent de « me construire un tableau de bord avec des indicateurs de revenus, des tendances des commandes et des découpes par catégorie » et le tableau de bord revient dans la conversation sans avoir besoin de changer d’onglet.

Derrière cette invite, l'agent explore vos données Elasticsearch via ES|QL et sélectionne des types de graphiques pour correspondre aux données : des barres pour les comparaisons, des lignes pour les tendances, des cartes de métriques pour les KPI et des cartes thermiques pour les modèles bidimensionnels. Il dispose les panneaux sur la grille à 48 colonnes de Kibana en utilisant le thème Borealis de l'interface utilisateur Elastic, et le résultat est entièrement interactif : vous pouvez faire glisser, redimensionner et regrouper les panneaux en sections repliables directement dans le chat. Lorsque le tableau de bord a l'apparence voulue, un seul appel d'outil l'exporte vers Kibana, en préservant les requêtes ES|QL et les couleurs personnalisées. Vous pouvez également importer des tableaux de bord Kibana existants dans le chat pour une édition assistée par l'IA.

Le principe est le même que celui derrière l'application de sécurité : lorsque l'artefact est le produit, le renvoyer dans la conversation ferme la boucle entre la description de ce que vous voulez et le fait de le voir.

Sous le capot, elle suit le même schéma que l’application MCP. Un serveur Node.js enregistre un outil view_dashboard orienté modèle ainsi qu’un ensemble d’outils uniquement d'application que l’interface utilisateur appelle directement (récupération des données, persistance de la mise en page, détection des champs temporels, exportation/importation). La vue du tableau de bord est un fichier HTML autonome intégré à vite-plugin-singlefile et servi comme ressource pour l’application MCP. Les développeurs qui dupliquent le dépôt obtiennent le même shell serveur et le même pont hôte que ceux vus dans l’application Security, dirigés vers une tâche différente. Le fichier README example-mcp-dashbuilder contient l’architecture complète et la référence des types de graphiques.

Elastic Observability MCP App

La troisième application de référence, Elastic Observability MCP application, s'attaque à la version SRE du même problème de forme. Lorsque quelque chose se brise en production, la réponse dont l'ingénieur de garde a besoin n'est pas un graphique, mais un diagnostic assemblé à partir des métriques K8s, de la topologie APM, des anomalies ML et de l'évaluation des risques. La forme de la réponse est une histoire causale : ce qui a échoué, pourquoi, ce qui en dépend, et ce qu'il faut faire ensuite.

Six outils facilitant le workflow d'investigation en observabilité

Outil

Dépendance

Fonctionnalités

observer

Universel

Primitive d’accès transitoire ES|QL + ML pour les anomalies — exécutez une requête ponctuelle, échantillonnez une métrique en temps réel ou bloquez l’exécution jusqu’à ce qu’un seuil ou une anomalie soit déclenché(e).

gérer les alertes

Universel

Créer, lister, obtenir et supprimer des règles d'alerting à seuil personnalisé Kibana. Omettez l'URL Kibana pour une exécution en lecture seule.

détection des anomalies basée sur le ML

Tâches de ML

Interrogez les enregistrements d’anomalies ML et ouvrez une vue explicative d’anomalie en ligne.

Résumé de l'état de santé APM

Elastic APM

Cumul de santé au niveau du cluster via télémétrie APM ; couches dans K8s et contexte ML quand disponibles.

dépendances-service-apm

Elastic APM

Graphe de dépendance des services — en amont/en aval, protocoles, volume d'appels.

rayon d'explosion K8s

Indicateurs Kubernetes

Impact de la panne de Node — panne complète, dégradée, non affectée, faisabilité de replanification.

Cumul d'intégrité du cluster

Demandez « Qu'est-ce qui ne fonctionne pas ? » ou « Donnez-moi un rapport d'état » et obtenez une orientation unique : badge de santé globale, services dégradés avec raisons, principaux consommateurs de mémoire pod, répartition de la gravité des anomalies et débit du service — le tout en une seule vue en ligne. C'est le point de départ lorsque quelque chose ne va pas, mais vous ne savez pas où regarder. La vue s'adapte en fonction de ce que votre déploiement prend en charge. L'APM vous offre la santé de vos services. Les indicateurs Kubernetes ajoutent le contexte du pod et du Node. Couche des tâches ML dans les anomalies.

Graphe des dépendances des services

Demandez « quel est le nom de la caisse ? » ou « montrez-moi la topologie » et obtenez un graphe de dépendances en couches — appelants en amont, dépendances en aval, protocoles, volume d'appels et latence par arête. Demandons à Claude de « me montrer les dépendances de service du frontend » :

Utilisez le zoom, le déplacement et le survol pour obtenir tous les détails nécessaires à la compréhension des relations complexes entre les services :

Évaluez les risques à l’aide d’un rayon d’impact

Demandez « que se passe-t-il si mon nœud k8s tombe en panne ? » et obtenez un diagramme d’impact radial : le nœud cible au centre, les déploiements totalement indisponibles en rouge, dégradés en orange, et non affectés en gris. Une carte de synthèse flottante affiche les pods à risque ainsi que les possibilités de replanification. Les déploiements à instance unique sont signalés comme des points uniques de défaillance. 

Observer

Le principal mécanisme d’accès de l’agent pour Elastic — un outil, trois modes pour trois besoins distincts. Dites « que fait le CPU en ce moment ? » et une requête ES|QL est exécutée une seule fois, avec un tableau en résultat. Dites « montre-moi la latence du frontend pendant les 60 prochaines secondes » et la métrique est échantillonnée en temps réel, avec mise à jour du graphique sur place. Dites « préviens-moi lorsque la mémoire passe sous 80 MB » ou « surveille toute anomalie pendant les 10 prochaines minutes » et l’exécution reste en attente jusqu’à ce que la condition soit remplie ou que la fenêtre expire. La vue s’adapte au mode : un tableau de résultats pour les requêtes ponctuelles, un graphique de tendance en temps réel avec statistiques actuelles/de pointe/de référence pour l’échantillonnage et les seuils, et une carte de déclenchement avec score de gravité pour le mode anomalie.

Fonctionnement

Même modèle d'application MCP que les applications Security et Search : un serveur Node.js, six outils orientés modèle connectés à six ressources de vue à fichier unique. Les outils sont regroupés par back-end de déploiement (Universel, dépendant de l'APM, dépendant de K8s, dépendant du ML), afin que l'agent et l'utilisateur sachent à l'avance quels outils s'appliquent à un déploiement donné au lieu de découvrir des lacunes de capacité au moment de l'appel. L'application MCP inclut également un exemple de workflow Agent Builder : k8s-crashloop-investigation-otel qui peut être déclenché par une alerte Kubernetes et renvoyer un résumé structuré des causes profondes avant que vous n'ayez ouvert un seul tableau de bord.

La pile agentique, interactive

Trois caractéristiques de ce modèle méritent d’être présentées clairement. Premièrement, le résultat de l’outil n’est plus la fin du travail, mais son point de départ : la conversation renvoie une interface sur laquelle vous pouvez agir, et non un résumé à partir duquel vous devez agir. Deuxièmement, un même agent, un même contexte de modèle et un même fil de conversation peuvent désormais naviguer entre les interfaces de Security, Search et Observability sans quitter la conversation. Troisièmement, cela fonctionne uniquement parce qu’Elasticsearch et Kibana exposent déjà les API. L’application MCP constitue une fine couche interactive au-dessus des fonctionnalités produit que nous proposons déjà.

Attack Discovery alimente déjà la vue des résultats corrélés dans cette application. Au sein de la stack, ce même modèle agentique va encore plus loin : Elastic Workflows automatise les étapes déterministes (enrichissement des entités, création de cas, isolement des hôtes), tandis qu’Agent Builder analyse les données et invoque ces workflows comme des outils. L'application MCP apporte cette même surface de sécurité à la conversation externe ; les flux de travail et Agent Builder l'approfondissent au sein de la pile. Différents points d'entrée, les mêmes API Elastic en dessous.

Essayez :

• Sécurité : example-mcp-app-security

• Rechercher et tableaux de bord : exemple-mcp-dashbuilder

• Observability : exemple-mcp-observabilité

Vous n'avez pas encore de cluster Elasticsearch ? Démarrer un essai gratuit d'Elastic Cloud. Pour en savoir plus sur les éléments de base de l’application de sécurité, consultez les publications associées de Security Labs sur Elastic Workflows et Agent Builder, Agent Skills, et Attack Discovery.

C'est pourquoi nous mettons en open source les compétences Elastic Agent : une expertise native de la plateforme pour Elasticsearch, Kibana, Elastic Observability et Elastic Security. Ajoutez-les dans l'environnement d'exécution de l'agent que vous utilisez déjà, et améliorez votre agent en le faisant passer d'un statut de "généraliste" qui devine un grand nombre de syntaxes à un statut d'expert, capable par exemple d'utiliser un grand nombre de normes architecturales comme le font les équipes d'ingénieurs d'Elastic. Cette première version technique se concentre sur les compétences avec une compatibilité maximale pour Elastic Cloud Serverless, mais évoluera rapidement pour inclure une meilleure prise en charge des anciennes versions de la pile.

De plus, Elastic résout ce problème sur les deux fronts. Pour les agents sur la plateforme Elastic, Elastic Agent Builder (désormais disponible en version générale) vous permet de créer et de discuter avec des agents IA qui héritent des contrôles d'accès de vos données, utilisent des outils de recherche et d'analyse intégrés, et travaillent en contexte aux côtés de vos tableaux de bord, alertes et investigations. Nous travaillons dur pour garantir des expériences exceptionnelles d’agent sur la plateforme Elastic. Mais tous les agents ne se trouvent pas au sein d’Elastic. Votre équipe utilise déjà Cursor, Claude Code ou d'autres environnements d'exécution, et ces agents doivent également maîtriser Elastic. C'est là que les compétences des agents entrent en jeu.

Pourquoi les agents rencontrent-ils des difficultés avec les plateformes spécialisées

Les grands modèles de langage (LLM) sont des généralistes remarquablement compétents. Ils peuvent écrire en Python, expliquer les manifestes Kubernetes et restructurer les composants React car leurs données d'entraînement sont riches en exemples. Mais lorsqu’il s’agit de travaux spécifiques à la plateforme, ceux qui impliquent des langages de requête propriétaires, des interfaces API complexes et des bonnes pratiques spécifiques à un domaine, ils échouent de manière prévisible.

Pour Elasticsearch, l'écart se manifeste concrètement :

• Le langage de requête Elasticsearch (ES|QL) est un nouveau domaine. Les LLM sont fortement entraînés au SQL, mais ES|QL est un langage de requête canalisé avec une syntaxe différente, des fonctions différentes et une sémantique différente. Les agents écrivent fréquemment des requêtes qui semblent plausibles mais ne s'analysent pas. Ils confondent WHERE et | WHERE, inventent des fonctions qui n'existent pas et passent complètement à côté du modèle de composition canalisé.

• Les surfaces API sont larges et profondes. Elasticsearch, Kibana et Elastic Security exposent des centaines d'API dans les domaines de la recherche, de l'ingestion, de l'alerting, des règles de détection, de la gestion des cas, des tableaux de bord et plus encore. Un agent ne disposant que de données d'entraînement générales doit deviner quel point de terminaison appeler, à quoi ressemble le corps de la requête et comment gérer la réponse. Il se trompe suffisamment souvent pour éroder la confiance.

• Les bonnes pratiques ne figurent pas dans les données d'entraînement. Quand devez-vous utiliser semantic_text plutôt qu'un pipeline de plongement personnalisé ? Comment structurer un pipeline d'ingestion pour un CSV de 10 Go ? Quelle est la bonne syntaxe de règle de détection pour une technique MITRE ATT&CK ? Les agents polyvalents ne disposent pas de connaissances spécifiques à Elastic organisées et structurées de manière fiable et chargées par défaut. Ils devraient aller les chercher, et même s'ils le faisaient, les documents bruts ne reflètent pas toujours les jugements et les bonnes pratiques que les praticiens qualifiés appliquent.

Résultat : les développeurs passent plus de temps à corriger les sorties des agents qu'à écrire le code eux-mêmes. Ce n'est pas l'expérience pour laquelle ils se sont engagés.

Compétences des agents : connaissances de la plateforme, destinées aux agents

Les compétences des agents sont des répertoires autonomes d'instructions, de scripts et de matériel de référence que les environnements d'exécution des agents peuvent charger de manière dynamique. Lorsqu’une compétence est active, l’agent a accès au bon contexte au bon moment : syntaxe de requête, modèles d’API, logique de validation, exemples pratiques, afin de pouvoir exécuter correctement les tâches du premier coup.

Chaque compétence suit la spécification ouverte agentskills.io : un dossier avec un fichier SKILL.md contenant des métadonnées et des instructions structurées. Aucun format propriétaire, pas de dépendance. Les compétences fonctionnent à travers les environnements d'exécution des agents, notamment Cursor, Claude Code, GitHub Copilot, Windsurf, Gemini CLI, Cline, Codex, et bien d’autres.

Contenu de la version initiale v0.1.0

Le premier ensemble de compétences couvre cinq domaines de l’Elastic Stack :

• Interagir avec les API Elasticsearch (recherche, indexation, clustering)

• Création et gestion de contenu Kibana tels que les tableaux de bord, les alertes, les connecteurs et plus encore.

• Expertise de domaine pour Elastic Observability

• Expertise de domaine pour Elastic Security

• Créer des agents efficaces dans Agent Builder

Les compétences sont composables

Les compétences ne sont pas monolithiques. Elles sont modulaires de par leur conception. Votre agent charge uniquement les compétences pertinentes pour la tâche en cours. Vous travaillez sur une requête ES|QL ? La compétence ES|QL est activée. Vous souhaitez créer un tableau de bord à partir de ces résultats ? La compétence tableaux de bord se lance. Évaluer la santé de votre application ? La compétence de santé des services entre en jeu. Enquêter sur une alerte de sécurité ? Les compétences de triage s'enchaînent avec celles de gestion de cas et de réponse au fur et à mesure que l'enquête progresse.

Cette composabilité signifie que vous n'avez pas besoin d'une invite unique et massive qui tente de tout couvrir. Chaque compétence comporte exactement le contexte requis par son domaine, ni plus ni moins.

Pour les développeurs d'applications de recherche et d'IA

Si vous chargez des données dans Elasticsearch, que vous rédigez des requêtes ou que vous migrez des index, les compétences réduisent le cycle de génération de code, de détection d'erreurs et de recherche dans la documentation pour trouver ce qui n'a pas fonctionné.

Demandez à votre agent de charger un fichier CSV ; celui-ci utilisera un outil d’ingestion en continu qui gérera la contre-pression et déduira les mapping à partir des données. Il ne s'agit pas d'une boucle _bulk exécutée à la main qui épuise la mémoire dès le premier fichier volumineux. Demandez-lui de faire une requête auprès d’ES|QL, et il découvre vos véritables noms d’index et schémas de champs, puis écrit des requêtes valides canalisées avec la bonne syntaxe, les agrégations appropriées et la sélection de fonctionnalités adaptée à la version, et non une supposition SQL nécessitant trois tours de débogage. Demandez-lui de réindexer sur plusieurs clusters, et il suit le workflow complet : il crée la destination avec des mappings explicites, ajuste les paramètres de débit, effectue l'exécution de la tâche de manière asynchrone et restaure les paramètres de production une fois celle-ci terminée, et non pas un simple appel _reindex qui saute la moitié des étapes qu’un opérateur expérimenté suivrait.

Au lieu d'un agent qui vous donne un point de départ plausible à corriger, vous en obtenez un qui encode la discipline opérationnelle qui permet à la sortie de fonctionner réellement.

Exemples d'impacts de l'utilisation des compétences d'Elastic Agent

Eval

Ce que la compétence a changé

es-requêtes-d'audit-échecs-de-connexion

Utilisation des modèles de requête du log d'audit à partir de la compétence au lieu d'une recherche générique

es-autorisation-mapping-de-rôle-ldap

Émission de la structure correcte de l'appel d'API de mapping des rôles

esql-requête-de-base

Écriture de la syntaxe canalisée d'ES|QL via Query DSL

esql-gestion-des-erreurs

Priorité au schéma au lieu de deviner les noms des champs

esql-découverte de schéma

Ne devinez jamais le nom d'un index

es-ingestion-csv-avec-inférence

Utilisation de --infer-mapping uniquement, évitant de le combiner avec --source-format CSV qui crée un index vide

es-ingestion-fichier-json

Utilisation d'une approche d'ingestion robuste capable de traiter des fichiers volumineux

es-réindexer-local-asynchrone

Création de l’index de destination avec les répliques : 0 et refresh_interval : « -1 », puis réindexation asynchrone. Base : pas de préparation

es-sécurité-403-privilèges

Suivi d'un workflow de diagnostic de la compétence pour les erreurs de privilège au lieu de conseils génériques.

Pour les équipes de sécurité

Security répète quotidiennement les mêmes workflows opérationnels : trier les alertes, ajuster les règles de détection, gérer les dossiers. Les compétences de l'agent encodent ces connaissances procédurales afin que votre agent IA puisse exécuter correctement ces workflows, en appelant les bonnes API dans le bon ordre et avec les bons noms de champ. Pour une présentation pratique qui vous permettra de passer de zéro à un environnement Elastic Security complet sans quitter votre IDE, consultez la section Prise en main d'Elastic Security depuis votre agent d'IA.

Pour les équipes d'observabilité et d'opérations

Les nouvelles compétences des agents pour Elastic Observability réduisent les tâches opérationnelles liées à l'instrumentation de systèmes complexes, à la gestion des SLO, au tri des données complexes et à l'évaluation de l'état des services. L'intégration de l'expertise native d'Elastic directement dans les agents IA permet aux équipes d'exécuter des workflows d'observabilité complexes en utilisant un langage naturel simple. Cela permet aux équipes SRE et chargées des opérations de résoudre les incidents plus rapidement et d'assurer la maintenance de systèmes fiables plus facilement. Pour en savoir plus, consultez cet article de blog.

Open source, spécifications ouvertes, piloté par la communauté

Nous publions les compétences d'agent sous la licence Apache 2.0, car nous pensons que les connaissances des agents doivent être ouvertes. La spécification agentskills.io que suivent les compétences est un standard ouvert, et non un format propriétaire d'Elastic. Nous voulons que les compétences soient le fruit d'un effort communautaire, et non d'un lieu clos.

Une partie d'un tableau plus vaste

Agent Skills fait partie d'une initiative plus vaste visant à faire d'Elasticsearch la plateforme de données la plus adaptée aux agents disponible sur le marché. Pour les agents hébergés sur la plateforme Elasticsearch, Agent Builder va plus loin en reprenant les contrôles d'accès et les autorisations de vos données, en fournissant des outils intégrés et personnalisés pour la recherche et l'analyse, et en permettant aux utilisateurs d'interagir avec les agents en contexte, au sein de leurs tableaux de bord, alertes et enquêtes. Enfin, la prise en charge des compétences sera bientôt disponible dans Agent Builder, offrant aux développeurs la flexibilité nécessaire pour tirer parti des compétences Elastic Agent ainsi que de celles provenant de toute autre source, afin de permettre un chat sécurisé et enrichi par le contexte, ainsi qu'une automatisation sur la plateforme Elasticsearch.

Pour les agents qui vivent ailleurs, nous investissons dans l'écosystème ouvert :

• Extension du serveur Model Context Protocol (MCP) : Extension du point de terminaison MCP dans Agent Builder avec davantage d'outils au-delà des opérations actuelles de recherche, ES|QL et d'index.

• Améliorations de l'authentification : faciliter la connexion sécurisée des agents, dans le but d'éliminer le copier-coller manuel des clés API.

• Documentation lisible par LLM : publication des fichiers llms.txt et AGENTS.md afin que les agents puissent découvrir et comprendre les API Elastic par eux-mêmes.

• Une interface de ligne de commande (CLI) pour les flux de travail des agents : Un outil de ligne de commande qui facilite la gestion des connexions et les opérations courantes pour les agents.

Les compétences sont la partie que vous pouvez utiliser aujourd'hui. Le reste est à venir.

Lancez-vous

Avant de commencer : Les agents de codage d’IA fonctionnent avec de vraies informations d’identification, un véritable accès au shell et, souvent, avec toutes les autorisations de l’utilisateur qui les exécute. Lorsque ces agents sont orientés vers des workflows de sécurité, les enjeux sont plus élevés : vous confiez à un système automatisé l’accès à la logique de détection, aux actions de réponse et aux télémétries sensibles. Le profil de risque de chaque organisation est différent. Avant d’activer les workflow de sécurité pilotés par l’IA, évaluez les données auxquelles l’agent peut accéder, les actions qu’il peut entreprendre et ce qui se passe s’il se comporte de manière inattendue.

Installez les compétences Elastic Agent dans votre environnement d'exécution de l'agent :

npx skills add elastic/agent-skills

Cela détecte automatiquement vos agents d'exécution installés et place les compétences dans le répertoire de configuration approprié. A partir de là, votre agent les récupère automatiquement.

Vous pouvez également consulter directement le catalogue de compétences et installer manuellement des compétences individuelles en copiant le dossier de compétences dans le répertoire de configuration de votre agent.

Vous n'avez pas encore de cluster Elasticsearch ? Démarrer un essai gratuit d'Elastic Cloud. Il faut environ une minute pour obtenir un environnement entièrement configuré.

Explorez le projet :

• Répertoire des compétences des agents

• Spécifications d'agentskills.io

• Documentation Elasticsearch

• Essai gratuit d'Elastic Cloud

Nous avons tous été témoins de l’essor des agents d’IA. Ils se révèlent particulièrement performants pour le résumé de textes, l’écriture de scripts et l’extraction de réponses issues de bases documentaires. Pourtant, dans les domaines du DevOps et de la fiabilité système (SRE), nous faisions face à un obstacle particulièrement frustrant. L’immense majorité des agents reste confinée au modèle du support client. S’ils analysent et échangent, ils demeurent incapables d’intervenir directement sur les couches d’infrastructure dont ils ont la charge.

Lors de notre récent hackathon, nous avons pris le parti de briser définitivement cette contrainte.

Nous avons conçu l’Infrastructure augmentée : un copilote d’infrastructure qui ne se contente pas de vous conseiller, mais qui crée, déploie, surveille et répare également votre environnement de production.

Le problème : copier, reformater, coller

Les agents standards fonctionnent en vase clos. Face à une panne majeure représentant une perte de 5 millions de dollars, l’assistance d’un agent standard se limite à la simple lecture du protocole de remise en service. Mais c’est toujours à vous d’effectuer le travail. Il vous reste encore à extraire le code, à en assurer la compatibilité avec votre environnement, puis à procéder manuellement à sa saisie dans la console.

Nous recherchions un agent capable de faire la part des choses entre le discours sur Kubernetes et l’exécution technique sur Kubernetes.

Au cœur du système : présentation d’Elastic Agent Builder.

Pour concevoir cette solution, nous ne sommes pas partis d’une page blanche. Nous l’avons conçue sur la base d’Elastic Agent Builder. À titre de rappel, Elastic Agent Builder est une architecture logicielle dédiée au développement rapide d’agents, agissant comme interface entre un modèle de langage (LLM), tel que Google Gemini, et les données propriétaires hébergées dans Elasticsearch.

Agent Builder peut être utilisé pour l’IA conversationnelle en l’ancrant sur des données internes, comme des documents ou des logs. Mais sa fonctionnalité la plus puissante est la possibilité d’assigner des outils. Ces outils permettent au LLM de sortir de l’interface de discussion pour accomplir des tâches spécifiques. Nous avons compris qu’en exploitant tout le potentiel de cette fonction, l’Agent Builder pourrait devenir un véritable pilier de l’automatisation.

Mise en œuvre : création de la première version

Dès le début du projet, notre ambition était de permettre aux agents d’exercer une action concrète sur leur environnement externe. Une idée a germé : pourquoi ne pas créer un « runner », un logiciel chargé d’exécuter sur la machine hôte toutes les instructions générées par l’agent ? Puis, nous avons envisagé ceci : et si les « runners », Elastic Agent Builder et l’utilisateur communiquaient en temps réel, comme lors d’une conférence téléphonique ?

Nous avons commencé par concevoir un projet Python, Augmented Infrastructure Runners, qui consistait essentiellement en une boucle while(true) qui interrogeait chaque seconde l’API des conversations d’Elastic Agent Builder pour y détecter une syntaxe spécifique que nous avions créée :

Nous avons ensuite mis à jour l’invite pour l’enseigner sur notre nouvelle syntaxe d’appel d’outil. Bill contribue à la maintenance de FastMCP, la solution de référence en Python pour le développement de serveurs conformes au Model Context Protocol (MCP). Il a entrepris d’utiliser le client FastMCP conjointement avec ce nouveau runner afin de coupler les serveurs MCP et d’exposer leurs outils au sein de l’environnement d’exécution. Lorsque l’agent voyait cela, il exécutait l’appel de l’outil et publiait les résultats dans la conversation, comme si l’utilisateur lui-même les avait envoyés. Cela incitait le LLM à répondre au résultat, et c’est ainsi que tout a commencé !

C’était génial mais cela posait deux problèmes principaux :

1. L’agent se contenterait de projeter l’intégralité des données JSON au beau milieu de l’échange avec l’utilisateur.

2. Dans l’API des conversations, les messages n’étaient accessibles qu’une fois le tour de parole terminé, soit après l’émission de la réponse par le LLM.

Nous nous sommes alors attachés à trouver comment déporter cette tâche en tâche de fond.

Nous avons ensuite choisi de donner à l’agent un outil appelé call_external_tool avec deux arguments : le tool_name et les arguments JSON sous forme de chaîne de caractères. Cet appel d’outil externe ne renvoie rien, mais il est important de noter qu’il est visible dans la requête GET envoyée à l’API des conversations. Nous avons ensuite donné aux runners l’autorisation d’écrire des documents directement dans Elasticsearch, que l’agent Elastic Agent Builder pouvait récupérer si nécessaire. L’agent fonctionne toujours en réponse à un message d’utilisateur. Nous devons donc démarrer l’agent avec un message d’utilisateur afin qu’il recherche des résultats et poursuive le traitement. Aussi, nous avons demandé aux agents d’insérer un court message dans le chat pour reprendre la conversation :

Ainsi, nous avions désormais des appels d’outils externes. Cependant, en raison du deuxième problème mentionné ci-dessus, nous avons dû supprimer cette dernière partie de démarrage. Sinon, chaque appel à un outil externe nécessitait un cycle complet de conversation pour récupérer les résultats !

Pour aller plus loin : présentation des workflows

En plus des appels d’outils via ES|QL et la recherche d’index, les agents d’Agent Builder peuvent solliciter des outils Elastic basés sur des workflows. Les workflows Elastic offrent une méthode flexible et simple à gérer pour exécuter une séquence arbitraire d’actions et de logiques. Dans notre cas, le rôle du workflow se limite à l’enregistrement d’une demande d’outil externe dans Elasticsearch et à la transmission d’un identifiant (ID) pour le suivi des résultats. Le résultat est une définition de workflow simple, articulée comme suit :

Ainsi, au lieu de compter sur l’écriture de la requête d’appel d’outil dans la conversation, les runners peuvent simplement interroger l’index Elasticsearch distributed-tool-requests pour de nouvelles requêtes d’outils externes et faire un rapport des résultats dans un autre index Elasticsearch avec l’execution.id fourni.

Cela élimine les deux principaux problèmes mentionnés ci-dessus :

1. L’historique de la conversation n’est plus encombré par les données de transfert des appels d’outils externes.

2. Comme les runners interrogent l’index Elasticsearch au lieu de l’historique de conversation, ils ne sont plus bloqués par l’achèvement du cycle d’échange pour que les requêtes d’outils externes deviennent visibles.

L’intérêt principal de ce deuxième point est que l’exécution des requêtes vers les outils externes débute pendant que l’agent « réfléchit », sans attendre que le tour de parole soit terminé. Cela nous permet d’instruire le LLM, via le prompt système, d’interroger les résultats de l’outil externe jusqu’à ce qu’ils soient disponibles, éliminant ainsi le besoin d’un message de relance. Dans l’ensemble, cette approche fluidifie l’interaction : le LLM est désormais capable de gérer simultanément plusieurs appels d’outils externes lors d’une seule itération. Cela lui permet de traiter des requêtes utilisateur complexes de manière groupée, plutôt que de fragmenter le processus.

Mise en place

Pour rapprocher le LLM et la baie de serveurs, nous avons développé une architecture spécifique en exploitant les fonctionnalités des outils d’Agent Builder :

1. Les runners de l’infrastructure augmentée : Nous avons déployé des runners légers à l’intérieur des environnements cibles (serveurs, clusters Kubernetes, comptes cloud). Ces runners sont connectés directement à Elastic, en utilisant des endpoints sécurisés et des secrets accessibles uniquement à chacun des runners.

2. Récupération ES|QL : Le copilote utilise ES|QL d’Elastic pour effectuer des recherches hybrides. Il ne se contente pas de rechercher des connaissances, il recherche des capacités. Il interroge les exécuteurs connectés pour voir quels outils sont disponibles (par exemple, list_ec2_instances, install_helm_chart).

3. Exécution du workflow : Une fois que l’agent a décidé d’un plan d’action, il crée un workflow structuré.

4. Boucle de rétroaction : Les runners exécutent la commande localement et rapportent les résultats dans Elasticsearch. Le copilote lit le résultat de l’index et décide de l’étape suivante.

Démonstration : transformer un incident critique en levier d’observabilité

Dans la vidéo, nous avons présenté deux scénarios distincts démontrant la puissance de cette architecture.

Scénario 1 : DevOps à la rescousse

Le point de départ est un incident critique : un utilisateur confronté à une perte de 5 millions de dollars due à un défaut de visibilité dans son cluster Kubernetes.

• La demande : « Comment m’assurer que cela ne se reproduise plus ? »

• Action : L’agent ne s’est pas contenté de fournir un tutoriel. Il a identifié le cluster, créé les espaces de nom nécessaires, généré des secrets Kubernetes, installé l’opérateur OpenTelemetry et a immédiatement fourni un lien vers un tableau de bord APM en direct.

• Le résultat : Une observabilité complète de Kubernetes et des informations sur les applications sans que l’utilisateur n’écrive une seule ligne de YAML.

Scénario 2 : Transfert de Security

En sécurité des infrastructures, un principe de base prévaut : l’impossibilité de protéger ce qui échappe à notre visibilité. En pleine intervention de secours DevOps, l’agent identifie une occasion d’optimiser la sécurité globale de l’infrastructure.

En s’appuyant sur une alerte générée lors d’une analyse Elastic Observability, nous illustrons la capacité d’un analyste sécurité à interagir en langage naturel avec son infrastructure. L’objectif est double : recenser précisément les ressources cloud existantes et mettre en œuvre les solutions de protection indispensables.

• Découverte : Le copilote a énuméré les ressources AWS pour le spécialiste de la sécurité et a identifié une lacune critique : une instance Amazon Elastic Compute Cloud (EC2) et un cluster Amazon Elastic Kubernetes Service (EKS) avec des points de terminaison publics dépourvus de protection des points de terminaison.

• Remédiation : Avec une simple approbation, le copilote a déployé Elastic Security détection et réponse étendues (XDR) et détection et réponse cloud (CDR) sur les ressources vulnérables, assurant la sécurité de l’environnement en temps réel.

• Le résultat : Protection des ressources AWS déployées avec une sécurité totale à l’exécution.

Perspectives : Vers une infrastructure intégralement augmentée

Ce projet démontre la capacité d’Elastic Agent Builder à agir comme le centre de pilotage de vos opérations distribuées. Notre champ d’action dépasse désormais le cadre strict de l’infrastructure. Les capacités de notre technologie de runner s’étendent à :

• Synthetics augmenté : Diagnostiquer les erreurs TLS chez les runners du monde entier.

• Développement augmenté : Création de requêtes d’extraction et implémentation de CAPTCHA sur les services frontend.

• Opérations augmentées : reconfiguration automatique des résolveurs DNS en cas de panne.

Essayez par vous-même

Nous pensons que l’avenir de l’IA ne se limite pas à l’assistance par chat, mais aussi à une infrastructure augmentée. Il s’agit d’avoir un partenaire qui peut déployer, réparer, observer et protéger à vos côtés.

Consultez le code et essayez-le par vous-même avec des runners distribués (GitHub) et Elastic Agent Builder sur Elastic Cloud Serverless dès aujourd'hui !

• Créez un projet sans serveur sur Elastic Cloud.

• Déployez le code vers un runner.

• Configurez le runner.

• Configurez votre fichier mcp.json.

• Démarrez l’agent, qui créera automatiquement votre agent et ses outils.

• Dialoguez avec un agent capable de raisonner, de planifier et d’exécuter des actions sur vos runners distribués !

L’équipe : Alex, Bill, Gil, Graham et Norrie