Tout système SIGINT finit par se heurter au même problème : les besoins de collecte sont plus nombreux que les capteurs disponibles pour y répondre. Les capteurs ont une couverture fréquentielle limitée, une capacité de tasking simultané restreinte, et des contraintes géographiques qu'aucune ingénierie ne supprime entièrement. La gestion de la collecte est la discipline qui fait le lien entre ce que les commandants ont besoin de savoir et ce que la flotte de capteurs peut physiquement observer.
Cet article traite de l'architecture logicielle et des algorithmes qui mettent en œuvre la gestion de la collecte au niveau système : comment les besoins se transforment en plans de tasking, comment les conflits sont résolus, et comment le système mesure ses propres performances et s'adapte en temps réel.
Ce qu'est la gestion de la collecte
La gestion de la collecte se situe entre le processus des besoins en renseignement et le capteur individuel. D'un côté, les analystes et les commandants génèrent un flux de questions : Quelles fréquences utilise le réseau radar de défense aérienne de l'adversaire ? Le nœud logistique suspecté émet-il ? Quelles unités sont actives dans le carreau XY ? De l'autre côté, on dispose d'un ensemble fini de capteurs avec des fenêtres de couverture spécifiques, des plages de fréquences et des limites de capacité simultanée.
La fonction de gestion de la collecte traduit les besoins en ordres de tasking de capteurs exécutables, surveille l'exécution par rapport au plan et renvoie les résultats aux propriétaires des besoins. Sans cette fonction, un besoin prioritaire entre en compétition aveuglément avec des tâches de routine de faible priorité. Les capteurs sont orientés vers de mauvaises cibles. Des fenêtres de collecte critiques sont manquées parce que deux collecteurs étaient taskés sur la même cible pendant qu'un troisième n'avait rien à faire.
Le problème logiciel central est celui d'une planification de ressources contraintes en situation d'incertitude. Les besoins arrivent en continu. La disponibilité des capteurs évolue avec le déplacement des plateformes, l'état de maintenance et la qualité des liaisons de communication. L'environnement lui-même — brouillage, masquage par le terrain, effets atmosphériques — influe sur ce que chaque collecteur peut observer. Un système de gestion de la collecte doit maintenir un modèle précis de toutes ces variables et mettre à jour les plans de tasking en permanence.
Gestion des besoins de collecte
Les besoins entrent dans le système de gestion de la collecte selon une hiérarchie structurée. Les Priority Intelligence Requirements (PIR) expriment les besoins en renseignement les plus prioritaires du commandant au niveau stratégique ou opérationnel. Les PIR sont décomposés en Intelligence Requirements (IR) — des questions plus précises liées à des cibles particulières, des zones géographiques ou des fenêtres temporelles. Les IR sont ensuite décomposés en Specific Collection Requirements (SIR) — des tâches atomiques et actionnables par le capteur, spécifiant quel signal rechercher, dans quelle bande de fréquences, à quel endroit, et dans quelle fenêtre temporelle.
Le cadre COLISEUM (Collection Operations Intelligence Schedules and Execution Unified Management), utilisé dans les systèmes de renseignement de l'OTAN, formalise cette hiérarchie et ajoute des champs pour le demandeur, la priorité, la justification et le calendrier de collecte requis. Les enregistrements de besoins au format COLISEUM portent un identifiant unique qui persiste tout au long de la chaîne collecte-rapport, permettant une traçabilité de bout en bout, de la question du commandant au produit de renseignement résultant.
En termes logiciels, une base de données des besoins stocke chaque SIR comme un enregistrement avec les champs clés suivants : identifiant de la cible, plage de fréquences ou classe de signal, zone géographique d'intérêt (polygone ou point-rayon), fenêtre temporelle (horodatages au plus tôt et au plus tard), niveau de priorité (généralement 1 à 5 ou P1 à P5), unité demandeuse, et critères de satisfaction — ce qui constitue un succès de collecte. Le moteur de planification lit cette base de données comme entrée et tente de construire un plan de tasking de capteurs satisfaisant autant de besoins que possible dans les limites de la flotte de capteurs disponible.
Inventaire des capteurs et modélisation des capacités
Une planification efficace nécessite un modèle précis et en temps réel de la flotte de capteurs. Le système de gestion de la collecte maintient un registre de capteurs qui recense les attributs suivants pour chaque collecteur :
Couverture fréquentielle. Chaque capteur dispose d'une plage accordable (par exemple, 20 MHz à 3 GHz) et d'une largeur de bande simultanée (par exemple, 40 MHz de couverture instantanée). Un capteur ne peut pas couvrir simultanément des fréquences qui dépassent sa largeur de bande instantanée, de sorte que les besoins à large bande peuvent nécessiter plusieurs capteurs ou des passages d'accord séquentiels.
Empreinte de couverture. Pour les systèmes directionnels aéroportés ou au sol, l'empreinte de couverture est une fonction de la position de la plateforme, de l'orientation de l'antenne et de la portée de détection. Le modèle de capteur calcule l'empreinte sous forme de polygone, mis à jour en continu à mesure que la plateforme se déplace. Un besoin est satisfaisable par un capteur donné uniquement si la cible se trouve dans l'empreinte du capteur pendant la fenêtre temporelle du besoin.
Capacité de tasking simultané. Un récepteur multicanal peut traiter N tâches simultanées. Un récepteur monocanal n'en traite qu'une. Le modèle de capteur suit le nombre de créneaux de tasking disponibles à chaque pas de temps. Planifier une nouvelle tâche sur un capteur saturé crée une condition de sur-tasking, que le système doit détecter et signaler.
État et santé actuels. Les capteurs signalent leur état opérationnel via un message de battement de cœur ou de santé et d'état. Un capteur qui se déconnecte, entre en mode dégradé ou perd sa liaison de communication doit être immédiatement marqué comme indisponible. Les tâches en attente sur ce capteur nécessitent une replanification. Le système doit propager ce changement d'état dans le plan de tasking en quelques secondes, pas en minutes.
Les données de position de la plateforme alimentent directement le calcul de l'empreinte. Pour les capteurs mobiles au sol, les traces GPS s'intègrent dans le modèle de capteur. Pour les plateformes aéroportées, le système de gestion de vol fournit la position, le cap et l'altitude. Les empreintes de couverture sont recalculées à chaque cycle de mise à jour du modèle — généralement toutes les 5 à 30 secondes selon la vitesse de la plateforme.
Algorithmes de tasking et de planification
Le problème central de planification est une variante de la planification par intervalles avec ressources. Chaque besoin dispose d'une fenêtre temporelle pendant laquelle il doit être satisfait. Chaque capteur dispose d'un ensemble de créneaux horaires, chacun avec une limite de capacité. Les contraintes de fréquence associent les besoins aux capteurs : un besoin pour un signal VHF ne peut pas être assigné à un capteur à couverture uniquement HF. Les contraintes géographiques limitent davantage quels capteurs peuvent couvrir quelles cibles. L'objectif est de maximiser le taux de satisfaction pondéré par priorité sur l'ensemble des besoins.
L'approche pratique la plus simple utilise un planificateur glouton ordonné par priorité. Les besoins sont triés par niveau de priorité, puis par urgence de fenêtre temporelle (les besoins à l'échéance la plus proche en premier dans chaque niveau). Le planificateur itère sur la liste triée et assigne chaque besoin au meilleur capteur disponible — celui avec la marge signal-bruit la plus élevée pour cette cible, ou celui ayant la capacité simultanée restante la plus importante. Cela s'exécute en O(R log R + R·S) où R est le nombre de besoins et S le nombre de capteurs, et produit de bonnes solutions assez rapidement pour des mises à jour en temps réel.
Pour des horizons de planification plus longs, les formulations par programmation par contraintes (CSP) ou programmation linéaire en nombres entiers mixtes (MILP) produisent des plans globalement meilleurs. Un planificateur MILP minimise le total des besoins pondérés par priorité non satisfaits sous réserve de : contraintes de capacité par capteur, contraintes de faisabilité fréquentielle, contraintes de couverture géographique, et faisabilité de la fenêtre temporelle. Des solveurs commerciaux (GLPK, HiGHS, CBC) résolvent des instances de taille pratique — des centaines de besoins, des dizaines de capteurs — en moins d'une minute. Le planificateur glouton gère les mises à jour en temps réel ; le MILP s'exécute comme un traitement périodique par lot pour optimiser l'horizon de planification à venir.
La détection de sur-tasking est un sous-système obligatoire. Lorsque le nombre de tâches assignées à un capteur dépasse sa capacité simultanée, ou lorsque la charge de tasking agrégée sur la flotte ne laisse à un besoin aucune assignation capteur-temps faisable, le système génère une alerte de sur-tasking. L'alerte porte l'identifiant du besoin affecté, le niveau de priorité, et la fenêtre temporelle la plus proche à laquelle la capacité se libérera. Les gestionnaires ISR utilisent cette information pour accepter la lacune ou escalader le besoin en vue d'une allocation supplémentaire de capteurs.
Déconfliction
La déconfliction est le processus qui empêche deux ordres de tasking de produire une collecte conflictuelle ou redondante. Deux types de conflits surviennent dans la gestion de la collecte SIGINT.
Déconfliction fréquentielle. Deux collecteurs accordés sur des bandes de fréquences qui se chevauchent dans la même zone géographique peuvent s'interférer mutuellement, notamment si l'un est un émetteur haute puissance ou si les deux utilisent des techniques de goniométrie active dans le même spectre. Le système vérifie chaque nouvel ordre de tasking par rapport à toutes les tâches actives pour détecter un chevauchement fréquentiel combiné à une proximité géographique. Si deux tâches se trouvent dans le rayon d'interférence — fonction de la puissance d'émission et du gain d'antenne — le système signale un conflit et propose un segment de fréquence alternatif ou un décalage temporel.
Déconfliction géographique et de cible. Deux collecteurs taskés sur la même cible dans la même fenêtre temporelle produisent une collecte dupliquée. C'est du gaspillage lorsque la capacité des capteurs est rare. Le moteur de déconfliction maintient une base de données de tâches indexée par identifiant de cible et fenêtre temporelle. Avant d'assigner un second capteur à une cible, il vérifie si la couverture existante est déjà adéquate. Si la couverture existante offre une qualité de signal et une géométrie de géolocalisation suffisantes, la seconde assignation est bloquée et le capteur est libéré pour des besoins non satisfaits.
La géométrie de géolocalisation est un facteur clé dans la déconfliction de cible. Un seul capteur fournit une ligne de relèvement, pas un point de fix. Deux capteurs fournissent un fix uniquement si leur base géométrique par rapport à la cible produit une dilution de précision (DOP) acceptable. Le moteur de déconfliction autorise donc — et recommande activement — l'assignation multi-capteurs à la même cible lorsque la précision de géolocalisation est un objectif de collecte, à condition que les deux capteurs soient positionnés pour fournir une séparation angulaire adéquate. Il s'agit d'une couverture coordonnée plutôt que redondante, et les deux cas nécessitent un traitement différent dans la logique de déconfliction.
Les résultats de déconfliction sont stockés sous forme d'un enregistrement de déconfliction liant les identifiants de tâches affectées, le type de conflit et l'action de résolution prise. Ce journal alimente la piste d'audit de l'architecture de la plateforme et est disponible pour l'analyse post-mission.
Retasking en temps réel
Un plan de collecte qui ne peut pas s'adapter en cours de mission est opérationnellement inutile. Les événements dynamiques invalident constamment les hypothèses du plan : une plateforme cible change de position, un nouvel émetteur apparaît dans une bande précédemment silencieuse, un capteur perd sa liaison de communication, ou un commandant émet un besoin prioritaire flash qui supplante le plan actuel.
Le retasking en temps réel requiert une architecture pilotée par les événements. Le système de gestion de la collecte s'abonne à un flux d'événements de changement d'état provenant des capteurs, des systèmes de renseignement et de la couche de commandement. Chaque événement déclenche une mise à jour ciblée du plan plutôt qu'une replanification complète. La procédure de mise à jour est :
Premièrement, identifier quelles tâches actuelles sont affectées par l'événement — les tâches dont le capteur est désormais indisponible, ou dont la cible s'est déplacée hors de l'empreinte du capteur actuel. Marquer ces tâches comme en attente de replanification. Deuxièmement, réévaluer les besoins affectés par rapport à l'état actuel des capteurs et recalculer les assignations à l'aide du planificateur glouton. Troisièmement, générer des ordres de retasking pour les capteurs affectés et les transmettre via la liaison de commandement. L'ensemble du cycle devrait se terminer en moins de deux secondes pour des tailles d'événements typiques.
Les besoins prioritaires flash — tâches P1 émises en réponse à un événement critique dans le temps — nécessitent une préemption. Le planificateur compare le besoin flash avec la tâche active de plus basse priorité sur le meilleur capteur candidat. Si la priorité du besoin flash dépasse celle de la tâche active, la tâche active est préemptée : le capteur reçoit un ordre d'arrêt de tâche pour la tâche de priorité inférieure, la tâche est retournée dans la file d'attente non planifiée, et le besoin flash est assigné immédiatement. Le propriétaire de la tâche préemptée reçoit une notification avec la raison de la préemption et la fenêtre de reprise la plus proche.
L'interface de commande et contrôle du capteur doit prendre en charge une livraison de tâche à faible latence. Les ordres de retasking envoyés via des liaisons à haute latence — SATCOM satellite avec 600 ms aller-retour — imposent au planificateur de tenir compte du délai de propagation des commandes lors du calcul du temps de retasking possible le plus tôt. Une tâche ordonnée à T ne doit pas être planifiée pour commencer avant T plus le délai de propagation plus le temps de traitement côté capteur.
Métriques et retour d'information
Un système de gestion de la collecte qui ne mesure pas ses propres performances ne peut pas s'améliorer. La couche de métriques ferme la boucle entre la collecte planifiée et la collecte exécutée.
La métrique principale est le taux de succès de collecte : la fraction des tâches planifiées qui ont été exécutées et ont produit un produit de renseignement utilisable dans la fenêtre temporelle du besoin. Le taux de succès est calculé par niveau de priorité, par capteur, par type de cible et par période. Un taux de succès P1 inférieur à 90 % est un problème au niveau système qui justifie une investigation immédiate. Un taux de succès P4 de 60 % peut être acceptable compte tenu de la flotte de capteurs contrainte.
L'analyse des échecs catégorise chaque échec de collecte par cause racine. Le système distingue : les échecs côté capteur (indisponibilité de la plateforme, défaillance de liaison, panne mécanique), les échecs de couverture (la cible s'est déplacée hors de l'empreinte avant le début de la collecte), les échecs fréquentiels (la cible n'émettait pas dans la bande requise pendant la fenêtre de collecte), les échecs de plan (le besoin n'a pas été planifié en raison de contraintes de capacité), et les échecs de qualité (la collecte a eu lieu mais le produit résultant ne répondait pas aux critères de satisfaction, par exemple une précision de géolocalisation insuffisante). Chaque catégorie d'échec entraîne une action corrective différente.
La boucle de retour plan-versus-réel compare le plan de tasking au début de chaque période de planification avec l'enregistrement d'exécution à la fin. Les lacunes persistantes — besoins répétitivement non satisfaits sur plusieurs cycles de planification — sont signalées comme des déficits chroniques et escaladées pour augmentation de la flotte de capteurs ou reclassification des priorités des besoins. Ce retour d'information alimente également le modèle de capacité des capteurs : un capteur qui rate systématiquement des cibles en bordure de son empreinte nominale dispose d'un modèle de couverture trop optimiste qui doit être corrigé.
L'efficacité de collecte — le ratio du temps que les capteurs passent en collecte active par rapport au temps d'inactivité ou de repositionnement — est une métrique secondaire qui révèle les gaspillages de planification. Un capteur inactif pendant que des besoins ne sont pas satisfaits indique un échec de planification, soit dans la modélisation de l'empreinte, soit dans la logique d'association besoin-capteur. Le suivi de l'efficacité par type de capteur fait apparaître quels types de collecteurs sont sursouscrits et lesquels ont de la marge, ce qui informe les futures décisions de structure de force.
Ces métriques sont les plus utiles lorsqu'elles sont présentées sous forme de tableau de bord en direct visible par le gestionnaire ISR et mis à jour au même rythme que le cycle de planification. Un tableau de bord affichant le taux de succès par niveau de priorité, les alertes de sur-tasking actuelles et le pourcentage de conformité au plan fournit au gestionnaire ISR les informations nécessaires pour prendre des décisions d'allocation de ressources pendant la mission plutôt que de découvrir les lacunes lors du bilan post-mission.
Si vous construisez ou évaluez un logiciel de gestion de la collecte SIGINT, les décisions d'ingénierie qui comptent le plus sont la fidélité du modèle de capteur, la latence de l'algorithme de planification sous charge dynamique, et le pipeline de retasking piloté par les événements. Réussir ces trois points détermine si le système aide les gestionnaires ISR à combler les lacunes de collecte ou se contente de les documenter après coup.
Pour en savoir plus sur la plateforme plus large dans laquelle s'intègre la gestion de la collecte, consultez nos articles sur les composants de la plateforme SIGINT et la conception de l'architecture de la plateforme SIGINT.
Discutez de votre projet
Nous développons des logiciels de gestion de la collecte SIGINT — moteurs de planification, modélisation de capteurs, logique de déconfliction et pipelines de retasking en temps réel pour les systèmes ISR opérationnels.