Chaque année, les catastrophes naturelles contraignent les responsables de la gestion des urgences, les commandants militaires et les autorités de sécurité publique à prendre des décisions aux enjeux considérables dans des délais très courts. Ces décisions reposent traditionnellement sur des chaînes d'appel, des feuilles de calcul et des connaissances institutionnelles réparties entre des dizaines de personnes. À elle seule, la surcharge liée à la coordination fait perdre un temps précieux.

Cet article montre comment Elastic permet de disposer d'un système de coordination agentique réactif et autonome pour la réponse aux catastrophes. Ce système détecte une menace, analyse les aspects logistiques et prend des mesures automatiquement. Pour illustrer ce concept, nous avons créé une simulation : un ouragan fictif de catégorie 4 menaçant le littoral de Hampton Roads déclenche le déplacement automatisé de plus de 137 000 personnes réparties sur sept installations militaires.

Avertissement : ceci est un scénario entièrement fictif élaboré à des fins de démonstration. L’ouragan ELARA-26 n’existe pas. Les emplacements des installations reposent sur des données géographiques réelles et accessibles au public issues de l'ensemble de données MIRTA (Military Installations, Ranges and Training Areas) du département de la Défense des États-Unis. Toutes les données opérationnelles, telles que les effectifs, la capacité de logement, les ressources, les adresses e-mail de contact et les profils de mission, sont entièrement fictives. Rien dans cette démonstration ne reflète la préparation opérationnelle, les capacités ou les procédures opérationnelles militaires réelles.

Pourquoi la réponse automatisée aux catastrophes nécessite une coordination géospatiale et agentique

Lorsqu'une catastrophe naturelle menace les infrastructures critiques, le défi de la coordination est immédiat :

• Quelles installations se trouvent dans la zone d'impact ?

• Combien de membres du personnel doivent être déplacés ?

• Où peuvent-ils aller, et ces installations ont-elles la capacité nécessaire ?

• Qui doit être informé immédiatement ?

Ces questions n'attendent pas. Les réponses non plus.

Déploiement du pipeline : prérequis et configuration

Suivez les instructions ici dans le dépôt d'exemples pour déployer un cluster Elastic local avec Elastic Inference Service (EIS) via Cloud Connect.

Fonctionnement du pipeline agentique de réponse aux catastrophes d'Elasticsearch

Le pipeline comporte sept couches qui fonctionnent ensemble de bout en bout :

1. Ingestion de données : les événements de catastrophe du Système mondial d'alerte et de coordination en cas de catastrophe (GDACS) sont envoyés à Elasticsearch.

2. Pipeline d'ingestion : les données GeoJSON sont ingérées et normalisées selon Elastic Common Schema (ECS).

3. Enrichissement géospatial : le polygone de la zone touchée par l'événement est confronté aux limites indexées des installations militaires.

4. Alerting : une règle de détection Kibana se déclenche lorsqu'une catastrophe recoupe une installation.

5. Automatisation du workflow : l'alerte déclenche un workflow Kibana qui lance une conversation avec un agent IA.

6. Raisonnement de l'IA : l'agent analyse les installations concernées, leurs actifs et les installations de soutien les plus proches afin de déterminer la relocalisation de l'ensemble des actifs et du personnel.

7. Notifications par e-mail: l'agent envoie des e-mails à tous les destinataires concernant le personnel et/ou les actifs entrants et sortants.

Passons en revue chaque couche.

Étape 1 : Indexation des installations militaires avec limites géographiques

La base repose sur l'ensemble de données DoD MIRTA provenant de source.coop/seerai/hifld. Cet ensemble fournit une géométrie de type Point pour chaque installation, à savoir des coordonnées de centroïde plutôt que de polygones délimitant l'intégralité du périmètre.

Chaque document d'installation dans l'index 'mitra-facilities' est enrichi de données de profil opérationnel (toutes fictives), au-delà de ce que fournit MIRTA :

C'est cet index riche qui permet à l'agent IA de prendre des décisions d'affectation intelligentes. Il ne s'agit pas simplement d'identifier des bases à proximité, mais de repérer celles qui disposent de capacités de logement disponibles, de types de missions compatibles et de la logistique nécessaire pour accueillir les ressources entrantes.

Étape 2 : Ingestion et normalisation des événements GDACS

GDACS publie des données GeoJSON en temps réel concernant les séismes, les cyclones tropicaux, les inondations, les feux de forêt, les volcans et les sécheresses. Nous intégrons ce flux dans un flux de données (logs-gdacs.events-*) à l'aide d'un pipeline d'ingestion personnalisé qui normalise les données GeoJSON brutes au format de champs ECS.

À noter que le pipeline d'ingestion GDACS effectue plusieurs opérations :

Extraction de la géométrie : le centroïde est stocké sous forme de 'geo_point' pour l'affichage cartographique, et le polygone d'impact est stocké sous forme de 'geo_shape' dans 'gdacs.affected_area', un champ qui sera utilisé ultérieurement pour les requêtes de recoupement.

Normalisation de la gravité : chaque type de catastrophe présente une échelle de gravité différente. Un cyclone tropical se mesure par la vitesse du vent en km/h, tandis qu'un séisme s'évalue selon la magnitude de Richter. Le pipeline convertit toutes ces mesures en un score normalisé allant de 0 à 100 :

Le score de gravité normalisé est ensuite associé à une étiquette de niveau de gravité (faible, moyen, élevé, critique) utilisée pour la correspondance du niveau de gravité de l'alerte dans la règle de détection.

Alignement ECS : event.kind : alerte, event.category : menace, horodatages mappés sur event.start/event.end et un _id stable basé sur une empreinte pour la déduplication.

Étape 3 : Enrichissement géospatial - identifier les installations affectées au moment de l'indexation

La politique d'enrichissement 'geo_match' d'Elasticsearch fait correspondre le polygone de la zone sinistrée à chaque périmètre d'installation lors de l'indexation, sans nécessiter de jointure au moment de la requête. Au lieu d'effectuer une requête lors de la recherche, nous utilisons un processeur d'enrichissement dans le pipeline d'ingestion pour faire correspondre le polygone d'impact de la catastrophe avec chaque limite d'installation au moment où le document est indexé.

La politique d'enrichissement est une politique 'geo_match' :

Le processeur s'exécute à la fin du pipeline d'ingestion :

INTERSECTS permet de détecter toute installation dont la limite touche ou chevauche le polygone de la catastrophe, y compris en cas d'intersection partielle. Par conséquent, chaque document d'événement GDACS est enregistré avec un tableau imbriqué 'affected_facilities' indiquant précisément quelles installations se trouvent dans la zone d'impact. Aucune requête de jointure n'est nécessaire.

Étape 4 : Règle de détection – alerting en cas d'impact sur les installations

Une règle de détection Kibana surveille le flux de données logs-gdacs.events-* et se déclenche lorsqu'un événement GDACS a été enrichi avec au moins une infrastructure affectée :

La règle s'exécute selon une planification horaire (couvrant une fenêtre allant de 'now-1h' à 'now') et utilise une correspondance dynamique de la gravité ; le champ 'gdacs.severity_level', calculé par le pipeline d'ingestion, détermine automatiquement la gravité de l'alerte.

La gravité de l'alerte détermine également le score de risque via le mapping de champs :

Lorsque la règle se déclenche, elle transmet à un workflow Kibana l'intégralité du contexte de l'alerte, y compris le tableau 'affected_facilities' enrichi contenant les noms, types et emplacements des installations.

Étape 5 : Automatisation des workflows – relier l'alerte à l'agent

Les workflows Kibana gèrent la transition entre la détection et la réponse. Le workflow de réponse aux catastrophes naturelles est déclenché par l'alerte :

L'intégralité de la charge utile de l'alerte (type de catastrophe, gravité, zone touchée et liste des installations impactées) est transmise à l'agent IA en tant que contexte initial. L'agent prend ensuite le relais.

Étape 6 : L'agent IA – des données à l'action coordonnée

L'agent mitra.response utilise l'intégralité de la charge utile d'alerte et, au cours d'une seule boucle agentique, évalue le périmètre, trouve les établissements d'accueil, affecte le personnel et envoie des notifications d'évacuation et de prise en charge, le tout sans intervention humaine.

L'agent dispose de deux outils :

• mitra.nearest_facilityinterroge l'index mitra-facilities à l'aide d'une requête geo_shape, triée par distance par rapport à une coordonnée donnée, et renvoie jusqu'à 50 installations actives à proximité disposant de capacités d'accueil.

• mitra.send_email itère sur un tableau JSON d'objets d'installation et transmet des notifications formatées d'évacuation ou de réception.

L'ensemble d'instructions de l'agent définit un workflow clair :

1. Évaluer la situation. Analyser l'alerte, identifier les installations touchées et déterminer l'ampleur de la catastrophe.

2. Faire l'inventaire de ce qui doit être déplacé. Effectifs, ressources critiques, besoins en hébergement par établissement.

3. Rechercher les installations de destination. Appeler mitra.nearest_facility pour chaque installation concernée, en excluant celles qui se trouvent encore dans la zone de danger.

4. Prendre des décisions d'allocation. Raisonner sur les solutions monosite par rapport aux solutions multisites, la compatibilité des branches, la capacité d'hébergement, le support technique des actifs.

5. Envoyer les e-mails de coordination. Transmettre les ordres d'évacuation aux établissements d'origine et les notifications d'admission aux établissements d'accueil.

6. Générer un rapport récapitulatif. Produire un court résumé, à transmettre dans le chat pour examen, de toutes les installations concernées, de l'effectif total, des actifs déplacés, des installations de destination et de toute préoccupation.

La logique d'affectation de l'agent respecte des contraintes réelles : ne pas dépasser la capacité d'hébergement, privilégier les réaffectations au sein d'une même branche lorsque c'est possible, utiliser des bases interarmées pour les excédents multibranches et prioriser la distance afin de minimiser le temps de trajet.

L'outil d'installation la plus proche

La requête de workflow sous-jacente utilise geo_shape avec un filtre de cercle et un tri _geo_distance :

La capacité disponible est calculée au moment de la requête via un champ de script qui soustrait l'effectif actuel de la capacité d'hébergement. L'agent utilise cette information pour répartir le personnel entre les différentes destinations sans dépasser les limites.

Ouragan ELARA-26 : coordination agentique de 137 000 personnes, de bout en bout

L'ouragan ELARA-26 est une tempête de catégorie 4 (vitesse maximale de 213 km/h) dont l'arrivée sur les côtes est prévue dans la région de Hampton Roads, en Virginie. Lors de l'intégration de l'événement GDACS, le polygone de la zone touchée recoupe sept installations militaires majeures de la région. La règle de détection se déclenche. Le workflow initie une conversation entre agents.

Au sein d'une seule boucle agentique, l'agent :

• a identifié sept installations dans la zone d'impact pour un total de 137 372 membres du personnel ;

• a appelé mitra.nearest_facility pour trouver des établissements d'accueil situés en dehors de la trajectoire de la tempête ;

• a réparti le personnel entre neuf établissements d'accueil en fonction de la capacité d'hébergement disponible et de la distance ;

• a généré et envoyé des ordres d'évacuation aux sept installations concernées ;

• a généré et envoyé des notifications d'admission aux neuf installations destinataires ;

• a généré un récapitulatif complet de coordination, semblable à ce qui suit :

Sites évacués :

Installation

Personnel

Base navale de Norfolk

50 000

Base expéditionnaire interarmées Little Creek-Fort Story

18 000

Base aéronavale Oceana

15 355

Annexe Dam Neck de la base aéronavale d'Oceana

17 509

Réserve militaire d'État de la Garde nationale Camp Pendleton

9 707

Base interarmées Langley-Eustis

15 000

Base d'armement naval de Yorktown

11 801

Installations d'accueil :

Installation

Distance

Personnel entrant

Fort Gregg-Adams

97 km

~40 000

Base du Corps des Marines de Quantico

148 km

~30 000

Installation de soutien naval d'Indian Head

151 km

~30 000

Base interarmées Andrews

180 km

~30 000

Base aéronavale de Patuxent River

141 km

~10 000

Camp Butner de la Garde nationale

174 km

~5 000

Site d'entraînement de la Garde nationale Bethany Beach

209 km

~4 707

Base de Rivanna

140 km

~7 500

Centre d'approvisionnement général de la Défense

22 km

~6 000

Les moyens redéployés comprennent des véhicules de transport, des hélicoptères, des patrouilleurs, des unités médicales, des engins du génie, des groupes électrogènes, des remorques-citernes, des kits d'hébergement et des systèmes de communication.

Notifications par e-mail automatisées

Une fois son plan d'affectation finalisé, l'agent a appelé mitra.send_email et a envoyé 16 e-mails en une seule opération : des ordres d'évacuation destinés aux sept installations concernées et des avis d'admission adressés aux neuf établissements d'accueil. Chaque message précisait l'établissement de destination, le nombre de personnes transférées, les ressources à déplacer ainsi qu'un contact de coordination. Ce qui aurait nécessité des heures de chaînes d'appels téléphoniques a été accompli automatiquement dès que l'agent a achevé son raisonnement.

Extension de la réponse agentique aux catastrophes avec la RAG et l'ancrage des politiques

Cette démo repose uniquement sur des données structurées, telles que les capacités, les distances et l'état opérationnel. Les fonctionnalités de recherche sémantique et de génération augmentée par récupération (RAG) d'Elastic contribuent à rendre l'agent nettement plus intelligent, grâce à deux ajouts :

Récupération des réponses historiques : indexation des anciens rapports post-intervention, des résumés d'incidents de l'Agence fédérale de gestion des urgences (FEMA) et des archives de réponse aux catastrophes sous forme d'embeddings vectoriels. Lorsqu'un nouvel événement se déclenche, l'agent peut effectuer une recherche sémantique sur la manière dont des événements similaires ont été traités, afin d'éclairer les décisions d'allocation grâce aux connaissances institutionnelles plutôt qu'aux seuls calculs de capacité.

Ancrage dans les politiques et la doctrine : indexation des directives de gestion des urgences du DoD, des plans de continuité des opérations des installations et des orientations du commandement. L'agent peut récupérer et citer les politiques réelles régissant une réponse, garantissant ainsi que chaque décision est fondée sur la doctrine plutôt que sur une inférence.

Ces deux fonctionnalités suivent la même approche Elastic native : un pipeline d'inférence génère des embeddings au moment de l'indexation, et un outil de recherche sémantique est exposé à l'agent. Le pipeline de coordination reste le même. L'agent devient simplement plus intelligent.

Pourquoi Elasticsearch est la plateforme idéale pour la réponse agentique dans le secteur public

Ce n'est pas un chatbot. Ce n'est pas un tableau de bord. C'est un système de workflow agentique réactif, lequel a détecté une menace, analysé un problème logistique complexe et coordonné le déplacement de 137 000 personnes sans intervention humaine. Ce type de résultat n'est possible que parce que chaque fonctionnalité dont il dépend repose sur une plateforme unique et unifiée.

La prise en charge géospatiale d'Elasticsearch (geo_point, geo_shape, stratégies d'enrichissement et tri basé sur la distance) gère le raisonnement spatial qui rend possibles la détection des recoupements et la recherche d'installations à grande échelle. La recherche sémantique et les embeddings vectoriels ancrent les agents dans la réalité, garantissant que le raisonnement de l'IA repose sur ce qui se trouve réellement dans vos données plutôt que sur des hypothèses hallucinées. Le moteur de détection de Kibana, Workflows, Agent Builder et les outils d'Agent Builder connectent l'ensemble au sein d'un pipeline allant de l'événement brut à l'action coordonnée, sans nécessiter le moindre code de liaison externe.

Aucune autre plateforme ne réunit ces capacités comme le fait Elastic. L'alliance de l'indexation en temps réel, de la précision géospatiale, de la recherche sémantique et de l'orchestration par agents, le tout au sein d'une même pile technologique intégrant sécurité et observabilité de niveau entreprise, distingue Elastic des outils qui excellent dans un seul de ces domaines tout en vous obligeant à assembler vous-même les autres éléments.

Réponse géospatiale agentique pour la gestion des urgences, les services d'incendie, les forces de l'ordre et la santé publique

La même architecture s'applique partout où les personnes, les installations, et les événements en temps réel se recoupent. Les données spécifiques changent. Le pipeline ne change pas.

Gestion des urgences : la FEMA et les services de gestion des urgences des États peuvent cartographier l'emplacement des abris, les zones de déploiement et les populations vulnérables en regard des polygones de conditions météorologiques extrêmes émis par le National Weather Service (NWS), déclenchant ainsi le prépositionnement automatisé des ressources avant qu'une tempête ne touche terre.

Services d'incendie et de secours d'urgence : les services d'incendie peuvent superposer l'emplacement des unités et les zones d'intervention aux périmètres des feux de forêt ou aux clusters d'incendies de structures, en acheminant automatiquement les demandes d'entraide vers les unités disponibles les plus proches dotées de l'équipement adapté.

Forces de l'ordre : les organismes peuvent corréler les lieux d'incidents en cours avec les zones scolaires, les infrastructures critiques et la position des agents, déclenchant ainsi des notifications de confinement géolocalisées ou le déploiement de ressources sans attendre un tri manuel.

Sécurité des établissements scolaires : les districts scolaires peuvent monitorer les flux de menaces en temps réel par rapport au périmètre des campus. Lorsqu'une menace franchit le périmètre d'une école, un agent peut immédiatement avertir l'administration, déclencher les communications de confinement et coordonner la réponse des forces de l'ordre, avant même qu'un coordinateur ne décroche son téléphone.

Santé publique : les services de santé peuvent comparer les données de surveillance des maladies ou les zones de risques environnementaux avec les emplacements des établissements de soin, les couches de densité de population et les inventaires des dépôts de fournitures afin d'acheminer les ressources là où elles sont le plus nécessaires.

Secteur

Cas d'utilisation

Capacité Elastic

Gestion des urgences

Croiser les emplacements des abris aux polygones de phénomènes météorologiques violents du NWS

Enrichissement geo_shape + workflows Kibana

Incendie et SMU

Superposer les emplacements des unités aux périmètres des feux de forêt

Routage géospatial + requête de recherche de l'installation la plus proche

Application de la loi

Corréler les incidents avec les zones scolaires et les positions des agents

Règles d'alerte tenant compte de la géolocalisation + répartition des agents

Sécurité des établissements scolaires

Monitorer les flux de menaces par rapport aux périmètres de campus

Règles de détection + notification automatisée

Santé publique

Croiser les zones de danger avec les emplacements des établissements de soin et les dépôts de ravitaillement

Recherche sémantique + enrichissement géospatial

Les données varient selon les scénarios, mais le schéma sous-jacent reste identique : ingestion, enrichissement lors de l'indexation, détection des recoupements, déclenchement d'une réponse agentique et exécution de l'action. Elastic fournit aux organismes du secteur public une plateforme permettant de concevoir cette solution une seule fois et de l'adapter partout.

La publication et la date de publication des fonctionnalités ou fonctions décrites dans le présent article restent à la seule discrétion d'Elastic. Toute fonctionnalité ou fonction qui n'est actuellement pas disponible peut ne pas être livrée à temps ou ne pas être livrée du tout.