Corvus.Head en détail : architecture du tableau de bord pour la fusion de données ISR en temps réel

Les données de renseignement, de surveillance et de reconnaissance parviennent à un poste de commandement depuis une douzaine de directions simultanément. La télémétrie des UAV transite par une liaison radio dédiée. Les capteurs de guerre électronique transmettent des événements d'interception via un flux TCP chiffré. Les observateurs d'artillerie transmettent des références de grille par voix ou messagerie numérique. Les plateformes SIGINT produisent des rapports d'entités enrichis à des intervalles irréguliers. Chacune de ces sources a son propre format, sa propre cadence de mise à jour et son propre profil de fiabilité. Le défi ne réside pas dans l'acquisition des données — il réside dans leur compréhension en temps utile pour que l'information puisse influencer les décisions.

Corvus.Head est le tableau de bord de renseignement opérationnel de Corvus Intelligence, conçu pour consolider précisément ce type de données de champ de bataille multi-sources dans une interface unique et structurée destinée aux commandements militaires, aux équipes de renseignement et aux planificateurs opérationnels. Cet article est un compte rendu technique de l'architecture du système : le pipeline d'ingestion qui normalise les flux hétérogènes, l'intégration PowerBI qui pilote les visualisations analytiques, le moteur géospatial qui rend les cartes thermiques et les points chauds, la couche de prévision de tendances, et la topologie d'hébergement Azure qui maintient la latence dans les tolérances opérationnelles.

Couche d'ingestion des données : normalisation des flux de capteurs hétérogènes

La première décision architecturale dans tout système ISR multi-sources est de savoir comment absorber la diversité des formats de données en amont sans permettre à cette diversité de se propager vers les couches de traitement et de visualisation. Corvus.Head utilise un modèle d'adaptateur de source : chaque type de capteur ou de flux dispose d'un service adaptateur dédié dont la seule responsabilité est de se connecter à la source, d'analyser son format natif et d'émettre des événements canoniques normalisés sur un bus de messages interne.

Le schéma d'événement canonique est intentionnellement minimal. Chaque événement contient : un identifiant d'entité unique, une étiquette de type de source, la latitude et la longitude en degrés décimaux WGS-84, l'altitude en mètres au-dessus du niveau moyen de la mer (null si la source ne rapporte pas l'altitude), le cap et la vitesse lorsque disponibles, une étiquette de classification (ami, hostile, inconnu, neutre, en attente), un horodatage UTC à l'origine de l'événement, et un objet de métadonnées libre pour les champs spécifiques à la source qui ne correspondent pas au schéma de base. Les champs qu'une source ne peut pas fournir sont définis à null plutôt qu'estimés — fabriquer des données au niveau de la normalisation est plus dangereux que de gérer des valeurs null en aval.

Les adaptateurs se connectent à leurs sources via des sockets TCP, des abonnements MQTT, des boucles de sondage REST ou des observateurs de dépôt de fichiers selon ce que chaque source prend en charge. L'échec de connexion est géré à l'intérieur de l'adaptateur avec un recul exponentiel ; un adaptateur défaillant ne bloque jamais les autres adaptateurs ni le bus de messages. Chaque adaptateur publie sur son propre sujet nommé sur le bus afin que les consommateurs en aval puissent s'abonner sélectivement par type de source. La technologie de bus utilisée est Apache Kafka sur Azure Event Hubs : la sémantique des groupes de consommateurs de Kafka permet au moteur de fusion, au pipeline analytique et au moteur géospatial de consommer chacun indépendamment le même flux sans coordination.

Intégration PowerBI : pourquoi il a été choisi pour les tableaux de bord de défense

La couche de visualisation analytique de Corvus.Head — graphiques, courbes de tendance, comparaisons de périodes et répartitions par domaine — est construite sur Microsoft PowerBI Embedded fonctionnant sur Azure. Le choix d'utiliser PowerBI plutôt qu'une pile de graphiques personnalisée est délibéré et mérite une explication, car il est contre-intuitif pour les ingénieurs qui associent PowerBI à la business intelligence plutôt qu'aux applications de défense.

L'argument pratique se résume à trois capacités. Premièrement, le moteur DAX de PowerBI fournit une couche de calcul mature et bien testée pour les métriques calculées : taux d'événements par cellule de grille par heure, scores de fiabilité des sources, variations en pourcentage d'une période à l'autre et moyennes mobiles. Reproduire la sémantique de calcul de niveau DAX dans une pile de graphiques JavaScript personnalisée représente un effort d'ingénierie de plusieurs années qui détourne des ressources du travail d'intégration de capteurs qui différencie réellement la plateforme.

Deuxièmement, PowerBI Embedded prend en charge le mode DirectQuery contre Azure Synapse Analytics, ce qui signifie que le tableau de bord peut interroger des tables analytiques pré-agrégées sans charger les données d'événements brutes dans le navigateur. Cela maintient les temps de réponse aux requêtes en dessous de 1,5 seconde pour des fenêtres analytiques de 90 jours couvrant des millions d'événements — une performance qui nécessiterait un investissement d'infrastructure significatif à réaliser avec une approche sur mesure.

Troisièmement, la gestion des versions du modèle de données et le chemin de mise à jour des rapports de PowerBI sont compris par les gestionnaires de programmes de défense qui ont besoin de maintenir des rapports analytiques sur des contrats pluriannuels. La définition de rapport PowerBI (.pbix) devient un artefact versionné qui peut être mis à jour, examiné et approuvé sans redéployer le logiciel de plateforme sous-jacent.

L'architecture d'intégration utilise le SDK JavaScript PowerBI Embedded pour rendre les rapports à l'intérieur d'iframes dans le shell Corvus.Head. Les filtres de sécurité au niveau des lignes sont appliqués au moment de l'intégration en utilisant les attributs d'habilitation de l'utilisateur issus du jeton de session, garantissant que les rapports PowerBI n'affichent que les données que l'utilisateur demandeur est autorisé à consulter — même si le jeu de données PowerBI lui-même contient le corpus complet.

Moteur géospatial : cartes thermiques, points chauds et densité d'événements

La couche d'affichage géospatial remplit un objectif différent des graphiques analytiques. Là où PowerBI montre des tendances agrégées dans le temps, la couche cartographique montre où les choses se passent en ce moment et où l'activité s'est concentrée au cours de la dernière période de veille. Corvus.Head rend trois types de superpositions géospatiales au-dessus d'une couche de carte de base : les pistes de position d'entités (mises à jour via push WebSocket), les cartes thermiques de densité d'événements et les marqueurs de points chauds discrets.

Les cartes thermiques de densité d'événements sont calculées côté serveur à l'aide d'une grille de hachage spatial avec une taille de cellule configurable (500 mètres par défaut). Chaque événement qui arrive via le pipeline d'ingestion incrémente le score de densité de la cellule contenant sa position, pondéré par une fonction de décroissance de récence — les événements de plus de six heures contribuent exponentiellement moins au score de la cellule. La décroissance empêche l'activité historique de biaiser définitivement la carte thermique et garantit que la visualisation reflète l'image opérationnelle actuelle plutôt que l'image historique cumulative.

La grille de carte thermique est recalculée selon un calendrier configurable (par défaut toutes les 60 secondes) et envoyée aux clients sous forme de GeoJSON FeatureCollection de polygones de cellules avec des attributs de densité. Le navigateur rend cela en utilisant une couche de carte WebGL avec une rampe de couleurs à cinq arrêts allant du bleu foncé (faible densité) en passant par l'ambre jusqu'au rouge (forte densité). Les opérateurs peuvent appliquer des filtres de domaine — afficher uniquement les événements EW, ou uniquement les observations UAV — ce qui déclenche un recalcul de la grille côté serveur filtré sur les types de sources sélectionnés. Cela évite un re-rendu complet de la géométrie de carte sous-jacente côté navigateur.

Les marqueurs de points chauds sont des points discrets générés automatiquement lorsqu'un ensemble d'événements dans une seule cellule de grille dépasse un seuil configurable dans une fenêtre temporelle glissante. Le détecteur de points chauds s'exécute comme un microservice séparé qui s'abonne au bus d'événements canoniques et évalue un algorithme de clustering variant du DBSCAN sur une fenêtre d'événements glissante de 30 minutes. Lorsqu'un cluster franchit le seuil, un enregistrement de point chaud est écrit dans la base de données et diffusé aux clients du tableau de bord connectés via le canal push WebSocket. Les points chauds expirent automatiquement lorsque l'activité du cluster tombe en dessous du seuil pendant une période soutenue.

Prévision de tendances : périodes quotidiennes, hebdomadaires et mensuelles

La prévision de tendances donne aux commandants une base quantitative pour anticiper le tempo opérationnel plutôt que d'y réagir. Corvus.Head présente des prévisions pour l'activité d'événements sur trois périodes — quotidienne, hebdomadaire et mensuelle — calculées à l'aide d'un modèle de décomposition saisonnière appliqué aux données de séries temporelles par cellule.

Le pipeline de prévision s'exécute sur Azure Databricks sur une base planifiée (toutes les heures pour les prévisions quotidiennes, chaque nuit pour les prévisions hebdomadaires et mensuelles). Il récupère les 90 derniers jours de comptages d'événements agrégés par cellule de grille et par intervalle de temps depuis Azure Synapse, applique la décomposition STL (décomposition Saisonnalité-Tendance par LOESS) pour extraire les composantes saisonnières et de tendance, et génère des projections prospectives avec des intervalles de confiance dérivés de la variance résiduelle. Les résultats sont réécrits dans Synapse sous forme de colonnes de prévision pré-calculées que PowerBI peut interroger via DirectQuery sans exécuter la décomposition en direct.

Le choix du pré-calcul plutôt que du calcul à la demande est délibéré. La décomposition STL sur 90 jours de données à travers des milliers de cellules de grille est coûteuse en calcul — l'exécuter à la demande en réponse à une requête de tableau de bord produirait une latence inacceptable. Le pré-calcul transfère le coût à un traitement par lots planifié et maintient les temps de réponse aux requêtes du tableau de bord inférieurs à 1,5 seconde pour toute requête de prévision qu'un utilisateur pourrait émettre.

Architecture de filtrage : exploration par domaine et période

Un tableau de bord qui montre tout est aussi inutile sur le plan opérationnel qu'un tableau de bord qui ne montre rien. L'architecture de filtrage détermine si les commandants peuvent rapidement isoler le signal pertinent pour leur décision actuelle du bruit environnant d'une image multi-sources complète.

Corvus.Head implémente le filtrage selon deux axes : le domaine (type de source ou classification d'entité) et la période (dernière heure, dernières 6 heures, dernières 24 heures, derniers 7 jours, ou plage personnalisée). Les filtres sont appliqués à trois couches : la couche de requête API (qui ne récupère que les événements correspondants depuis Synapse), la couche d'abonnement au bus de messages (qui ne s'abonne qu'aux sujets de types de sources pertinents pour le flux WebSocket en direct), et la couche de rapport PowerBI (qui applique le contexte de filtre DAX à toutes les mesures). Cette approche à trois couches garantit que les changements de filtre se reflètent de manière cohérente sur tous les composants visuels sans nécessiter un post-traitement côté navigateur d'un ensemble de données complet.

L'état du filtre est maintenu dans le shell du tableau de bord sous forme d'objet d'état sérialisable en URL, permettant aux commandants d'enregistrer et de partager des vues filtrées spécifiques avec leur personnel. Un officier de renseignement de brigade peut envoyer une vue filtrée spécifique — événements EW, dernières 6 heures, secteur nord — à ses subordonnés sous forme d'URL, et les destinataires voient une vue filtrée identique lorsqu'ils ouvrent le lien.

Topologie d'hébergement Azure et considérations de latence

Corvus.Head est hébergé sur Azure Government Cloud (Azure pour le gouvernement aux États-Unis, régions cloud souveraines équivalentes pour les nations partenaires). La topologie d'hébergement est conçue autour de trois budgets de latence : quasi-temps-réel pour les mises à jour de position des entités (objectif : moins de 3 secondes de bout en bout), réponse aux requêtes analytiques (objectif : moins de 1,5 seconde pour les requêtes pré-agrégées), et livraison des tuiles cartographiques (objectif : moins de 500ms pour les tuiles en cache).

Les adaptateurs d'ingestion et le bus de messages (Azure Event Hubs en mode compatible Kafka) s'exécutent dans la même région Azure que les sources de données classifiées, minimisant le saut réseau entre les systèmes de capteurs et la couche de normalisation. Le moteur de fusion et la passerelle WebSocket sont déployés en tant que charges de travail Azure Kubernetes Service dans la même région. La capacité PowerBI Embedded et l'espace de travail Azure Synapse Analytics sont provisionnés dans la même région pour éviter la latence de transfert de données inter-régions sur les appels DirectQuery.

La livraison des tuiles cartographiques utilise Azure Blob Storage avec l'accélération Azure CDN pour les tuiles de couche de base non classifiées. Les tuiles de superposition classifiées — couches d'annotation de renseignement, superpositions de disposition des forces amies — sont servies depuis un serveur de tuiles dédié au sein du périmètre sécurisé qui n'utilise pas le CDN. Les objectifs de temps de réponse du serveur de tuiles sont appliqués par un moniteur de santé qui alerte l'équipe des opérations si la livraison de tuiles au p95 dépasse 800ms.

Pour les configurations de déploiement avancé où la connectivité Azure n'est pas disponible ou peu fiable, Corvus.Head prend en charge un mode de déploiement sur serveur unique conteneurisé utilisant Docker Compose. Dans ce mode, la pile complète — adaptateurs d'ingestion, moteur de fusion, serveur de tuiles, un courtier Kafka local et une base de données PostgreSQL remplaçant Synapse — s'exécute sur un serveur durci au sein du réseau tactique. PowerBI est remplacé par un moteur analytique léger utilisant des spécifications de graphiques Vega-Lite pré-construites soutenues par une API REST locale. Le profil de latence change significativement dans ce mode : sans les services gérés d'Azure, l'équipe des opérations est responsable de la surveillance et de la mise à l'échelle de l'infrastructure locale, et certaines fonctionnalités analytiques avec une profondeur historique de 90 jours sont réduites à un cache local de 30 jours.

Étape par étape : intégrer une nouvelle source de données dans Corvus.Head

L'architecture d'adaptateur fait de l'intégration de nouveaux types de capteurs un processus d'ingénierie reproductible plutôt qu'un projet d'intégration sur mesure à chaque fois. Les étapes suivantes décrivent le chemin d'intégration standard.

Étape 1 — Définir le schéma de la source et la cadence de mise à jour. Documenter le format de données (CoT XML, JSON, protocole binaire), le taux de mise à jour attendu en messages par seconde, et les noms de champs faisant autorité pour la position, l'heure, le type d'entité et la classification. Cette définition de schéma devient le contrat de l'adaptateur.

Étape 2 — Implémenter l'adaptateur d'ingestion. Écrire un adaptateur spécifique à la source qui se connecte au flux et émet des événements canoniques normalisés sur le bus de messages. L'adaptateur gère les nouvelles tentatives de connexion, le réassemblage des messages partiels et l'authentification spécifique à la source. Il ne doit jamais bloquer le bus en cas d'échec de connexion.

Étape 3 — Mapper les champs vers le schéma d'événement canonique. Transformer chaque message entrant vers le format d'événement canonique de Corvus.Head. Les champs qui ne correspondent pas sont supprimés à l'adaptateur. Les champs que la source ne peut pas fournir sont définis à null plutôt que fabriqués.

Étape 4 — Configurer les règles d'association du moteur de fusion. Ajouter le nouveau type de source à la table de règles d'association du moteur de fusion. Spécifier le seuil de proximité spatiale et la fenêtre temporelle utilisés pour associer les rapports de cette source aux pistes existantes, et définir le poids de précision de la source pour l'estimateur de position.

Étape 5 — Enregistrer la source dans le modèle de données PowerBI. Ajouter le nouveau type de source en tant que valeur de dimension dans la table SourceType. Vérifier que les segments et mesures DAX existants gèrent la nouvelle valeur sans casser les rapports existants.

Étape 6 — Valider la latence et le débit en préproduction. Exécuter l'adaptateur sur une relecture de données sources historiques à 2x la vitesse en temps réel. Mesurer la latence de bout en bout de la réception du message à l'affichage sur le tableau de bord. Confirmer que la latence au p99 reste inférieure à 3 secondes et que la profondeur de file d'attente du bus de messages ne croît pas de manière illimitée sous charge soutenue.

Étape 7 — Activer et surveiller en production. Déployer l'adaptateur avec un contrôle par indicateur de fonctionnalité afin qu'il puisse être désactivé sans retour arrière si des problèmes surviennent. Surveiller la file d'attente des lettres mortes, le taux d'événements par source, et le taux d'association piste-rapport du moteur de fusion. Une baisse du taux d'association en dessous de 80 % indique généralement une inadéquation de schéma introduite par une mise à jour du microprogramme de la source.

Foire aux questions