Logiciel de déconfliction des feux : libérer les feux interarmées en temps quasi réel

Un champ de bataille moderne est encombré de choses qui volent. Les obus d'artillerie s'élèvent jusqu'à une flèche maximale de plusieurs kilomètres. Les aéronefs à voilure tournante transitent à basse altitude. Les aéronefs à voilure fixe exécutent des profils d'attaque. Les munitions rôdeuses et les drones de reconnaissance occupent les altitudes moyennes. Le tir naval atteint l'intérieur des terres. Lorsque plusieurs de ces éléments sont actifs dans la même zone au même moment, le risque n'est pas abstrait : une seule mission de tir non coordonnée peut envoyer un obus dans le même volume d'espace aérien qu'emprunte un aéronef, ou le faire atterrir sur un hôpital que les règles d'engagement protègent. Le logiciel de déconfliction des feux existe pour s'assurer que cela n'arrive pas – et pour le faire assez vite afin de ne jamais devenir la raison pour laquelle une cible fugace s'échappe. Cet article examine comment ce logiciel fonctionne : coordination de l'espace aérien, listes de cibles interdites et restreintes, workflow d'autorisation de tir, et intégration à la situation opérationnelle commune.

Ce que la déconfliction des feux doit réellement résoudre

La déconfliction comporte deux dimensions distinctes que l'on confond souvent. La première est la déconfliction positionnelle : maintenir les feux et les aéronefs séparés dans l'espace et le temps. La seconde est la déconfliction des cibles : s'assurer que la chose frappée est une cible licite et autorisée et qu'elle n'est pas déjà engagée par quelqu'un d'autre. Un bon logiciel traite ces dimensions comme des contrôles distincts avec des sources de données distinctes, car elles échouent de manières différentes et exigent des résolutions différentes.

La déconfliction positionnelle est fondamentalement un problème de géométrie en quatre dimensions – trois d'espace et une de temps. Une trajectoire d'artillerie n'est pas un point ; c'est un volume courbe qui existe pendant une fenêtre bornée. Un aéronef n'est pas non plus un point ; c'est une piste avec un vecteur vitesse et une bulle de protection autour de lui. Le moteur de déconfliction doit déterminer si ces deux volumes se croisent durant les instants où les deux sont présents. La déconfliction des cibles, en revanche, est un problème de règle et de consultation : ce point visé tombe-t-il à l'intérieur d'une zone protégée, porte-t-il une contrainte de tir, et la même cible est-elle déjà assignée à un autre tireur ?

Le plus dur est de faire tout cela en quelques secondes. Une demande de tir contre une cible mobile et sensible au temps peut disposer d'une fenêtre d'une minute ou moins avant que la cible ne se déplace. Si le processus de déconfliction prend plus de temps que cette fenêtre, il a de fait refusé la mission. Chaque décision de conception d'un logiciel de déconfliction des feux est façonnée par cette contrainte de latence.

Il existe aussi une dimension de coordination que la pure géométrie ignore. Plusieurs tireurs – une batterie de pièces, une section de mortiers, un élément d'aviation d'attaque et un avion de frappe – peuvent tous être désignés sur la même zone par différents états-majors qui ne voient pas les missions des autres. Sans service de déconfliction partagé, chaque demande de tir est autorisée isolément par rapport à une vue partielle de ce qui se passe d'autre, et c'est exactement ainsi que survient un engagement en double ou une quasi-collision entre un obus et un aéronef. Le rôle du logiciel n'est donc pas seulement d'évaluer une mission, mais de l'évaluer par rapport à tous les autres feux et aéronefs actifs dans le même champ de bataille au même instant, tirés d'une seule source de données partagée.

Coordination de l'espace aérien : modéliser la trajectoire

Le cœur de la déconfliction positionnelle est un modèle de trajectoire précis. Lorsqu'un élément d'appui-feu sélectionne une arme, une charge et une cible, le logiciel calcule la trajectoire balistique : le point de départ, la ligne pièce-but, la flèche maximale, l'angle de descente et le temps de vol. Cela produit un volume balayé – un tube d'espace aérien que le projectile occupera – associé à une fenêtre de temps sur objectif pendant laquelle ce volume est dangereux.

Ce volume est ensuite vérifié par rapport à l'espace aérien tel qu'il est actuellement structuré. Les mesures de coordination de l'espace aérien (ACM) divisent l'espace aérien en régions gérées : zones d'opérations restreintes, altitudes de coordination, routes de transit à basse altitude et routes aériennes d'usage standard pour les aéronefs de l'armée de terre. Les aéronefs apparaissent également comme des pistes en temps réel issues de la situation C2, chacune avec une position, un cap, une vitesse et un volume d'incertitude qui croît avec l'âge de la piste. Le moteur croise le tube du projectile à la fois avec les ACM statiques et les pistes dynamiques.

Lorsque la trajectoire perce un volume occupé ou restreint pendant la fenêtre de tir, le système soulève un conflit. Surtout, il ne dit pas simplement « non ». Il propose des résolutions classées par impact opérationnel : une séparation temporelle (tirer après que l'aéronef a dégagé), une restriction latérale d'espace aérien, un blocage d'altitude (une restriction de flèche maximale qui peut imposer une charge ou une trajectoire différente), un changement de position de tir, ou – en dernier recours – une suspension. Le coordinateur d'appui-feu choisit, et la trajectoire choisie devient celle qui est autorisée et tirée.

Pourquoi la flèche maximale est importante

Un échec courant des outils de déconfliction naïfs consiste à traiter la trajectoire comme une ligne pièce-but rectiligne. Le tir indirect ne se déplace pas en ligne droite ; une mission de mortier à angle élevé peut atteindre un apogée bien au-dessus de l'altitude de croisière d'un hélicoptère en transit qui n'est ni près de la pièce ni de la cible. Une déconfliction qui ignore la flèche maximale autorisera une mission qui est en fait dangereuse. Le modèle de trajectoire doit porter l'arc complet, y compris l'altitude de l'apogée, et le contrôle d'espace aérien doit être effectué par rapport à cet arc, et non à une ligne simplifiée. C'est la propriété d'exactitude la plus importante d'un moteur de déconfliction de l'espace aérien.

Listes de cibles interdites et restreintes

La déconfliction des cibles commence par deux jeux de données de référence. La liste de cibles interdites (no-strike list, NSL) énumère les entités protégées contre tout engagement délibéré au titre du droit des conflits armés et des règles d'engagement : installations médicales, lieux de culte, biens culturels, écoles, barrages et autres structures protégées. La liste de cibles restreintes (restricted target list, RTL) contient les cibles qui ne peuvent être engagées que sous contraintes – une autorité d'approbation spécifique, une arme particulière, un seuil de dommages collatéraux ou une limite temporelle (par exemple, un pont qui ne peut être frappé avant une heure nommée).

Dans le logiciel, les deux listes sont stockées sous forme d'enregistrements géolocalisés : chaque entrée comporte une emprise, un type de protection ou de restriction, et une fenêtre temporelle de validité. Lorsqu'une cible est résolue, le logiciel étend le point visé du rayon d'effets attendu de l'arme – sa zone létale et de dommages collatéraux – et teste cette emprise étendue par rapport à la NSL et à la RTL. Une intersection avec la liste de cibles interdites bloque la mission et fait apparaître l'entité protégée à l'opérateur. Une intersection avec la liste de cibles restreintes ne bloque pas ; elle fait remonter, en joignant la contrainte applicable et en acheminant la mission vers l'autorité d'approbation requise.

La discipline ici est que les listes doivent faire autorité et être à jour. Une NSL obsolète est pire qu'aucune NSL, car elle crée une fausse confiance. Le logiciel de déconfliction des feux versionne donc ces listes, horodate chaque mise à jour et refuse de libérer des feux par rapport à une liste plus ancienne qu'un seuil d'obsolescence configurable – forçant un acquittement humain délibéré plutôt que de procéder silencieusement sur des données périmées.

Le workflow d'autorisation de tir

L'autorisation de tir est l'énoncé faisant autorité qu'une mission est déconflictée, licite et approuvée pour le tir. C'est le moment de la responsabilité, et dans le logiciel elle doit être modélisée comme un workflow explicite et auditable plutôt que comme un effet de bord implicite d'une pression sur un bouton.

Le workflow enchaîne les pièces. Une demande de tir numérique entre dans le système. Le moteur exécute les contrôles de cible (NSL/RTL, engagement en double) et les contrôles d'espace aérien (trajectoire contre ACM et pistes), en joignant ses conclusions à la mission. La mission, avec ses conclusions, est acheminée vers les autorités requises – le coordinateur d'appui-feu, et tout commandant de manœuvre dont les forces ou la zone d'opérations sont affectées. Chaque autorité voit les mêmes conclusions de conflit et enregistre une décision explicite d'autorisation ou de refus. Ce n'est que lorsque toutes les autorisations requises sont enregistrées que le système libère la mission vers l'unité de tir.

Deux propriétés rendent ce workflow digne de confiance. Premièrement, chaque résultat de contrôle automatisé et chaque décision humaine est horodaté et écrit dans un journal immuable, de sorte que l'autorisation peut être reconstituée et examinée a posteriori – essentiel à la fois pour l'entraînement et la responsabilité. Deuxièmement, le workflow a des rôles et des autorités explicites ; le logiciel impose qui est autorisé à libérer quoi, de la même manière qu'une COP impose un accès aux données fondé sur les rôles. Un officier d'appui-feu peut autoriser dans le cadre de l'autorité déléguée ; une mission touchant la liste de cibles restreintes est remontée à l'autorité d'approbation nommée et ne peut être autorisée en dessous de ce niveau.

Intégration à la situation C2

La déconfliction des feux ne peut pas fonctionner sur un îlot de données privé. Le contrôle d'espace aérien ne vaut que ce que valent les données de pistes et d'espace aérien qui l'alimentent, et la seule source faisant autorité de ces données est la situation C2. Le moteur de déconfliction s'abonne donc à la situation opérationnelle commune pour les pistes d'aéronefs en temps réel et les pistes de forces amies, et ingère les mesures de coordination de l'espace aérien et les mesures de coordination de l'appui-feu (FSCM) sous forme de calques cartographiques entretenus par les cellules d'espace aérien et de feux.

Il publie également en retour. Lorsqu'une mission est autorisée, la mesure de coordination active – le volume et la fenêtre d'espace aérien que le feu occupe – est publiée vers la COP au moyen des formats de message Cursor on Target et des formats de feux alliés, afin que les unités et aéronefs voisins voient l'espace aérien comme chaud pendant la fenêtre de tir. Cela boucle la boucle : le système qui décide si un feu est sûr travaille à partir de, et contribue à, la même situation faisant autorité que voient la cellule d'artillerie, la cellule d'espace aérien et le commandant de manœuvre. C'est la même discipline d'intégration qui relie plus largement les systèmes de conduite de tir à la situation C2.

Les formats de message comptent pour l'interopérabilité. Dans une coalition, les données de feux et d'espace aérien doivent circuler entre les systèmes nationaux. S'appuyer sur les jeux de messages de feux et d'espace aérien définis par STANAG, et sur Cursor on Target pour le compte rendu de position, permet à un moteur de déconfliction de consommer les routes aériennes d'une unité alliée et de publier ses propres mesures de coordination sans adaptateurs sur mesure pour chaque partenaire.

Des communications dégradées modifient la situation d'intégration mais ne suspendent pas l'exigence de déconflicter. Les cellules de feux avancées opèrent fréquemment sur des liaisons à faible débit et intermittentes où la COP complète ne peut pas être diffusée en temps réel. Un moteur de déconfliction robuste conserve une copie localement mise en cache des mesures d'espace aérien, des listes interdites et restreintes, et des pistes récentes, et il marque chaque élément mis en cache d'un âge. Lorsque la connectivité tombe, le moteur continue de libérer les feux par rapport aux données mises en cache – mais il accentue la prééminence du seuil d'obsolescence, marquant les pistes et listes qui ont vieilli au-delà de leur fenêtre de confiance afin que le coordinateur d'appui-feu autorise en pleine connaissance de ce que le système peut et ne peut actuellement voir. Le principe de conception est que la perte du réseau doit dégrader la confiance de l'opérateur, visiblement, plutôt que de dégrader silencieusement la sécurité de l'autorisation.

La déconfliction des feux n'est qu'une pièce d'une situation de feux interarmées plus large qui s'étend à l'artillerie, à l'appui aérien rapproché et aux effets multidomaines – voyez comment le même défi de coordination apparaît dans la coordination CAS numérique et dans un tableau de bord des opérations multidomaines.