C2 de réponse aux drones
Installez le pack OSINT Intelligence, déployez le workflow d'ingestion des détections et pilotez une boucle en direct détecter-classifier-évaluer-décider-répondre avec le process flow Drone Response (Rapid Triage).
L'exemple C2 de réponse aux drones illustre le modèle de commandement et de contrôle de Scrydon : les détections des capteurs arrivent par webhook, une instance de process flow s'ouvre automatiquement, et un opérateur de situation aérienne classifie le contact sur une carte tactique en direct avant qu'un analyste de permanence IA produise un avis de menace et qu'un commandant de permanence rende une décision de réponse.
Toute la boucle — détecter → trier → évaluer → décider → répondre — est pilotée par un unique pack OSINT Intelligence installé depuis une source de packs Git. Aucun code sur mesure.
Ce que le pack provisionne
| Élément | Détail |
|---|---|
| Ontologie | 21 types d'objets (Track, TrackObservation, Aircraft, Drone, MilitaryBase, …) reliés à des tables de sources de données en direct ; types de liens de référence et de proximité entièrement connectés |
| 31 sources de données | Aviation, géophysique, météo spatiale, cyber-vulnérabilités, satellites, marchés — par interrogation périodique et statiques |
| Workflow C2 — Detection Ingest | Déclenché par webhook ; valide un POST c2.detection, insère ou met à jour une ligne Track, ajoute une ligne TrackObservation, ouvre (ou dédoublonne) une instance de process flow Drone Response |
| Process flow Drone Response (Rapid Triage) | Modèle en quatre stages TRIAGE → ASSESS → DECIDE → RESPOND avec des workflows inline à déclenchement automatique |
Prérequis
- Un déploiement Scrydon avec les surfaces agentic, ontology et analytics activées.
- Une intégration LLM configurée (requise par l'agent d'avis de menace IA du stage ASSESS).
- Une source de packs Git pointant vers
https://github.com/scrydon/packs(ou un miroir) ; refmain; chemin du cataloguescrydon.yaml.
Étape 1 — Installer le pack OSINT Intelligence
https://github.com/scrydon/packs, ref main, chemin du catalogue scrydon.yaml, authentification Aucune.example.osint-intelligence apparaît dans le catalogue.Les sources de données commencent immédiatement à accumuler des lignes. Laissez 2 à 5 minutes aux flux d'aviation et de géophysique avant d'ouvrir la carte de l'ontologie — les couches Track et Aircraft resteront vides tant que les premiers cycles d'ingestion n'auront pas abouti.
Étape 2 — Déployer le workflow d'ingestion des détections
<your-agentic-url>/api/webhooks/trigger/<path>.Étape 3 — Envoyer une détection (le notebook Marimo)
Le pack fournit un notebook Marimo pour piloter la démonstration. Depuis la racine de la source du pack :
marimo run src/osint-intelligence/_notebooks/drone-detection-driver.pyCollez l'URL de votre webhook et définissez un Track ID (par défaut DRONE-TEST-001). Deux boutons :
| Bouton | Ce qu'il envoie |
|---|---|
| Send single detection | Une détection aux coordonnées initiales du corridor de Suwałki (54,30° N, 23,10° E). À utiliser pour vérifier que le webhook est bien câblé. |
| Simulate incursion | 20 détections à 2 secondes d'intervalle, progressant vers la zone d'une base de l'OTAN au cap 215° à 72 m/s. |
Après le premier POST, surveillez Process Flows — une instance « Drone response — DRONE-TEST-001 » apparaît. Les POST répétés avec le même trackId mettent à jour la même instance au lieu de créer des doublons. Les lignes Track et TrackObservation s'accumulent dans les tables de l'ontologie OSINT.
Si le webhook de démonstration utilise Authentication: None pour une mise en place sans friction,
passez-le en Bearer Token avant la production. Un Webhook nouvellement créé
génère automatiquement un jeton Bearer ; copiez-le depuis Monitor et transmettez-le dans
l'en-tête Authorization du capteur.
Vous pouvez aussi envoyer directement la charge utile de détection avec curl :
curl -X POST "<your-webhook-url>" \
-H "Content-Type: application/json" \
-d '{
"trackId": "DRONE-TEST-001",
"source": "webhook-demo",
"lat": 54.30,
"lng": 23.10,
"altitudeMeters": 180,
"headingDeg": 215,
"speedMps": 72,
"observedAt": "2026-07-03T12:00:00Z"
}'Étape 4 — TRIAGE : classifier la situation aérienne
Ouvrez l'instance Drone response — DRONE-TEST-001. La première tâche est Classify the airspace picture, attribuée au persona Air Picture Operator.
La tâche affiche une carte tactique en direct avec deux couches géographiques :
| Couche | Source | Affiche |
|---|---|---|
| Track | track — détections ingérées | La situation en direct : le contact que vous venez d'envoyer, plus les deux pistes de démonstration pré-alimentées par le pack |
| DroneObservation | osint_drone_observation — télémétrie de flotte synthétique | Contexte de la flotte : les six positions de drones pré-alimentées autour du corridor de Suwałki |
La couche de contexte de flotte est le type d'objet DroneObservation (ce sont les observations de télémétrie qui portent les coordonnées), et non le registre de la flotte Drone — la liaison du registre ne mappe que l'identité et les métadonnées de cellule, elle ne peut donc jamais produire d'éléments cartographiques.
Le contact Track détecté est présélectionné (mis en évidence au chargement), car le workflow d'ingestion initialise le contexte de l'instance avec trackRef.
Sélectionnez une classification :
- Friendly — moyen connu.
- Hostile — déclarer une menace.
- Unknown — données insuffisantes ; l'évaluation IA signalera les informations manquantes.
Ajoutez des notes (par exemple « Cap 215° à 72 m/s, en approche du corridor de la base de l'OTAN ») et cliquez sur Submit.
À la soumission, la plateforme écrit la classification dans la ligne track en direct via un upsert api-table gouverné (l'écriture traversante). Si l'upsert échoue — par exemple parce que la surface analytics n'est pas joignable — l'action reste ouverte avec un bouton Retry ; vos notes et votre classification ne sont jamais perdues.
Mise à jour en direct du COP. Si un autre opérateur a la liste des process flows ou une vue cartographique ouverte dans son navigateur au même moment, il reçoit un signal léger indiquant que la Track a été classifiée et relit automatiquement les données gouvernées — aucun rafraîchissement de page n'est nécessaire. Le flux temps réel ne pousse jamais de coordonnées brutes ; les abonnés relisent toujours via le même endpoint gouverné.
Étape 5 — ASSESS : avis de menace IA
À la fin du TRIAGE, le workflow inline threat-assessment se déclenche automatiquement. L'analyste de permanence IA lit la classification et les notes de l'opérateur et produit un avis structuré :
THREAT LEVEL: LOW | MEDIUM | HIGH
RATIONALE:
<2–5 sentences grounded in the triage evidence>
MISSING INFO:
- <gap 1> OR noneBoucle de questions en retour. Si l'avis signale des éléments sous MISSING INFO :
- L'avis apparaît sous forme de bannière au-dessus de l'action cartographique suivante dans DECIDE.
- L'opérateur peut cliquer sur Revise and re-run sur l'action ASSESS, compléter les notes de classification du triage et soumettre à nouveau.
- L'agent s'exécute de nouveau sur la classification mise à jour. Itérez jusqu'à ce que l'avis soit exploitable.
Si votre intégration LLM n'est pas encore configurée, l'action échoue avec LLM_NOT_CONFIGURED. Configurez une intégration LLM sous Paramètres → Plateforme → Extensions et cliquez sur Retry.
Étape 6 — DECIDE : décision cartographique du commandant
La tâche Command decision est attribuée au persona Duty Commander. Elle affiche le même contact Track ciblé depuis la table track — mais cette fois avec la bannière de l'avis IA en haut de la carte.
Quatre options :
| Décision | Ce qui se passe |
|---|---|
| Dismiss | Aucune mission. Le stage RESPOND enregistre « dismissed » et le flow se termine. |
| Recon | RESPOND déclenche automatiquement une tâche « Recon tasking — scramble F-16 ». |
| Engage | RESPOND déclenche automatiquement une tâche « Engage tasking — weapons authorization ». |
| Re-triage | Les notes sont enregistrées comme preuves ; le flow rouvre TRIAGE pour une nouvelle classification — l'action DECIDE reste ouverte. |
Ajoutez les notes du commandant pour la piste d'audit, puis soumettez.
Re-triage est une branche arrière. Sélectionner Re-triage ne termine pas l'action DECIDE — le flow revient à TRIAGE et le commandant reverra la carte DECIDE une fois que l'opérateur aura reclassifié le contact. La classification et l'avis précédents sont conservés dans l'enregistrement de preuves de l'action.
Étape 7 — RESPOND : mission déclenchée automatiquement
Le workflow respond-tasking se déclenche automatiquement à la fin de DECIDE. Aucun déclenchement manuel n'est nécessaire.
- Dismiss → une note « dismissed » est écrite dans la sortie du bloc de réponse.
- Recon → une tâche « Recon tasking — scramble F-16 » apparaît dans la liste des tâches de l'instance.
- Engage → une tâche « Engage tasking — weapons authorization » apparaît.
Re-triage ne termine pas DECIDE : ce stage ne se déclenche donc jamais dans ce cas.
Ouvrez la liste des tâches de l'instance et vérifiez que la tâche créée correspond à la décision du commandant.
Simuler une incursion
Lancez Simulate incursion dans le notebook pour envoyer 20 détections en 40 secondes. Chaque détection met à jour la ligne Track (dernière position) et ajoute une ligne TrackObservation (historique complet des positions). L'instance de process flow est dédoublonnée — le même trackId se résout toujours vers la même instance ouverte, de sorte que l'opérateur peut classifier à mesure que les contacts évoluent au lieu de gérer 20 instances distinctes.
Une fois l'incursion terminée, la carte de l'ontologie affiche la position finale du contact Track ; le graphe Instances relie la Track à chacun de ses enregistrements TrackObservation via le type de lien TrackedBy.
Liste de contrôle pour la mise en production
| Sujet | Action |
|---|---|
| Authentification du webhook | Sélectionnez Bearer Token sur le bloc Detect → copiez le jeton généré depuis Monitor → transmettez Authorization: Bearer <token> depuis le capteur |
| Comptes de service | Créez un compte de service avec la portée de capacité process-flow:write ; ajoutez-le comme membre de l'espace de travail ; utilisez son jeton client-credentials dans le capteur ou le notebook |
| Modèle LLM | Vérifiez qu'une intégration LLM de production est activée ; la démonstration fonctionne avec n'importe quel modèle activé ; utilisez un modèle plus rapide/moins coûteux pour l'étape d'avis si la latence compte |
| Classification des Tracks | Les lignes Track et TrackObservation sont actuellement enregistrées avec la classification par défaut (UNCLASSIFIED). L'application de la classification par ligne EG-020 est une amélioration prévue — contactez votre équipe commerciale pour la feuille de route |
| Mise à niveau du pack | Le pack est livré avec required: false sur le process flow, afin que les mises à niveau de la partie sources de données s'installent proprement même si le modèle Drone Response n'est pas utilisé. Une mise à niveau avec le flow actif préserve les instances en cours |
Voir aussi
- Actions cartographiques — référence complète du type d'action
map, dewriteTarget, dereturnToStageet de la bannière d'avis. - Webhooks — comment le bloc Detect s'intègre dans le pipeline d'ingestion ; authentification par jeton ; sécurité face au rejeu.
- Requête géographique sur l'ontologie — comment les couches cartographiques résolvent les coordonnées et les types de liens.
- Comptes de service — identité d'ingestion en production.
Un flow de ciblage délibéré en boucle OODA pour le C2 maritime — six stages, plusieurs personas, documents à diffusion restreinte par classification.
Anatomie d'un modèle — types d'actions, familles de méthodologies, pipeline build / inspect / upload.
Rédigez les types d'objets Track, Aircraft et MilitaryBase ou étendez l'ontologie OSINT avec vos propres types métier.