Écosystème TAK et intégration C2 : étendre ATAK avec des plugins personnalisés

L'écosystème Team Awareness Kit (TAK) est l'une des plateformes logicielles tactiques les plus largement déployées par les forces terrestres alliées aujourd'hui. Reposant sur un protocole ouvert et une architecture client extensible par plugins, il permet aux équipes de développement logiciel de défense d'ajouter des capacités spécialisées — flux de capteurs, connectivité aux backends C2, données logistiques, coordination des feux — sans dupliquer l'application principale. Cet article explique comment l'écosystème est structuré, comment fonctionne l'API de plugin, et ce qu'il faut pour créer un plugin qui s'intègre de manière fiable à un système de commandement et de contrôle existant.

Architecture de l'écosystème TAK

L'écosystème TAK est une famille de clients de conscience situationnelle et de logiciels serveur. Au niveau de la couche client : ATAK (Android Team Awareness Kit) fonctionne sur des appareils Android durcis et constitue le facteur de forme dominant pour les forces à pied. WinTAK est l'équivalent Windows, couramment utilisé aux postes de commandement et aux stations de travail montées sur véhicule où la taille de l'écran et la puissance de traitement sont moins contraignantes. iTAK fonctionne sur iOS et est utilisé dans certains rôles d'observateur et d'aviation. Les trois clients partagent le même modèle de données et le même protocole, de sorte qu'une position signalée depuis un appareil ATAK apparaît immédiatement sur une console WinTAK connectée au même serveur.

TAK Server — disponible en tant que projet open source FreeTAKServer et sous plusieurs distributions commerciales dont CloudTAK — se trouve au centre de l'architecture. Son rôle est de fédérer les flux d'événements Cursor on Target (CoT) : accepter les CoT des clients connectés via TCP/TLS, distribuer ces événements aux autres clients connectés, persister l'image opérationnelle, et permettre aux clients connectés via WAN de partager la même image opérationnelle commune (COP) que les unités connectées localement par maillage.

La fédération étend encore davantage cette capacité. Deux instances de TAK Server peuvent établir un lien de fédération, de sorte que les événements du pool de clients d'un serveur deviennent visibles sur l'autre — le mécanisme par lequel les forces alliées partagent une COP partielle sans fusionner l'intégralité de leurs réseaux. Les backends C2 personnalisés se branchent dans cette architecture au niveau de la couche TAK Server, non au niveau de la couche client, ce qui signifie qu'une intégration C2 bien conçue ne nécessite aucune modification de l'application ATAK elle-même.

Architecture des plugins : comment fonctionnent les plugins ATAK

Un plugin ATAK est un APK Android qui s'installe aux côtés de l'application hôte ATAK. Au moment de l'installation, ATAK lit le manifeste du plugin, l'enregistre dans le gestionnaire de plugins et rend le point d'entrée du plugin accessible depuis le tiroir de plugins d'ATAK. Le plugin ne remplace aucune partie d'ATAK — il l'étend. ATAK continue de fonctionner pleinement si le plugin est désinstallé ou désactivé.

Hooks de cycle de vie

Le point d'entrée du plugin étend AbstractPlugin et implémente deux méthodes de cycle de vie principales. onCreate est appelée lorsqu'ATAK charge le plugin — le plugin y enregistre ses outils, ses couches de superposition et ses écouteurs d'événements, et démarre les services en arrière-plan dont il a besoin. onDestroy est appelée lorsqu'ATAK décharge le plugin — toutes les ressources doivent être libérées proprement ici, y compris les threads en arrière-plan, les connexions réseau et les couches de carte. Les fuites mémoire dans onDestroy sont la source la plus fréquente d'instabilité d'ATAK causée par des plugins tiers.

Points d'extension de l'interface utilisateur

ATAK fournit trois points d'extension principaux pour l'interface utilisateur des plugins. Le menu radial — le menu contextuel circulaire qui apparaît lors d'un appui long sur un élément de carte — peut se voir injecter des actions de plugin, de sorte qu'un clic droit sur un rapport de position peut déclencher un flux de travail spécifique au plugin, comme la génération d'une mission de feu à partir d'un point cible. La barre d'outils du plugin permet au plugin d'ajouter un bouton à la barre d'outils principale d'ATAK qui ouvre un panneau déroulant personnalisé. Des fragments en plein écran peuvent être empilés sur la pile de navigation d'ATAK pour des flux de travail plus complexes tels que les formulaires de saisie de données.

Toute l'interface utilisateur du plugin doit être conçue pour une utilisation à une main, compatible avec des gants. Les cibles tactiles inférieures à 56dp ne sont pas acceptables. Tout flux de saisie de données nécessitant plus de trois interactions pour être complété doit être reconsidéré — les opérateurs au contact n'ont pas le temps pour des formulaires complexes.

Patterns d'accès aux données

Les plugins accèdent aux données cartographiques via MapView, qui fournit des méthodes pour ajouter, mettre à jour et supprimer des éléments de carte. Les éléments ponctuels (marqueurs de position, contacts capteurs) sont des instances de PointMapItem. Les éléments de zone et de ligne sont des sous-classes de Shape. Chaque élément de carte porte un UID qui doit être stable entre les mises à jour — modifier un UID crée un élément dupliqué plutôt que de mettre à jour l'existant, ce qui constitue l'un des bugs de plugins les plus courants dans les systèmes en production.

Analyse approfondie de CoT : le protocole qui connecte tout

Cursor on Target est le protocole d'événements basé sur XML qui sous-tend tous les échanges de données dans l'écosystème TAK. Chaque objet sur la carte ATAK est représenté sous forme d'événement CoT. Comprendre CoT en profondeur est un prérequis pour tout travail d'intégration C2.

Structure des événements

Un événement CoT comprend trois éléments de premier niveau obligatoires. L'élément racine event porte le type d'événement (une taxonomie séparée par des points commençant par a- pour les atomes, b- pour les bits, ou t- pour les tâches), l'UID, les horodatages time/start/stale, le how (comment l'événement a été généré — machine ou humain), et les attributs access et qos pour la classification et la qualité de service. L'élément point porte la latitude, la longitude, l'erreur circulaire (ce), l'erreur linéaire (le) et la hauteur au-dessus de l'ellipsoïde (hae). L'élément detail est un conteneur extensible pour tout le reste.

Le bloc detail est là où résident les données spécifiques à l'intégration. Les sous-éléments standard incluent contact (indicatif d'appel et adresse de point de terminaison), __group (nom et rôle du groupe), status (batterie, état de préparation) et remarks (texte libre). Les données personnalisées sont portées dans des sous-éléments avec espacement de noms : un plugin d'appui-feu pourrait ajouter un élément <fireMission> avec le numéro de cible, la méthode d'engagement et le rayon de danger proche. Le rendu standard d'ATAK traite ces éléments personnalisés comme des détails inconnus et les ignore ; un plugin compagnon qui connaît le schéma les affiche correctement.

Types d'événements clés pour l'intégration C2

La taxonomie des types d'événements couvre des milliers de types spécifiques. Pour l'intégration C2, les plus pertinents sont : a-f-G-U-C (unité terrestre amie, combattant — la piste de force bleue standard), a-h-G (piste terrestre hostile), a-u-G (sol inconnu), b-m-p-w (point de cheminement), b-r-f-h-c (demande d'appui-feu) et t-x-m-c (message de discussion). Comprendre la hiérarchie des types — les lettres de préfixe encodent l'affiliation, la dimension de combat et la fonction — permet à un plugin de générer des icônes correctement rendues sans aucun élément graphique d'icône spécifique au plugin.

Gestion des événements obsolètes

Chaque événement CoT porte un horodatage stale. ATAK supprime les événements de la carte lorsqu'ils deviennent obsolètes, ce qui constitue le mécanisme de vieillissement automatique des pistes de force bleue. Un plugin générant des rapports de position doit les rafraîchir avant qu'ils ne deviennent obsolètes — les mises à jour de position typiques sont envoyées toutes les 30 à 60 secondes avec une fenêtre stale de 5 minutes. Un plugin qui génère un événement une seule fois sans le rafraîchir verra ses éléments disparaître de la carte, ce qui est un bug courant dans les premières versions des intégrations C2.

Patterns d'intégration C2

Il existe deux patterns principaux pour intégrer un système C2 à l'écosystème TAK. Le pattern passerelle opère au niveau de la couche TAK Server sans nécessiter de plugin sur l'appareil. Le pattern plugin s'exécute sur l'appareil ATAK et est approprié lorsque l'intégration doit répondre aux actions de l'opérateur sur l'appareil.

Pattern passerelle : TAK Server vers backend C2

La passerelle est un service autonome qui se connecte au flux CoT de TAK Server (via l'API de fédération ou en tant que plugin TAK Server) et à l'API du système C2. Lorsqu'un nouveau rapport de position arrive depuis TAK Server, la passerelle le traduit du XML CoT au format de piste du système C2 et le publie dans l'API C2. Lorsque le système C2 génère un nouveau contact ou une nouvelle tâche, la passerelle génère un événement CoT et le publie sur TAK Server, où il se propage à tous les clients ATAK connectés.

Cette approche ne nécessite aucun plugin sur l'appareil ni aucune modification de l'application ATAK. C'est le bon choix lorsque l'intégration est principalement de serveur à serveur et que le système C2 fait autorité. Le principal défi est la latence : un cycle de mise à jour de position qui passe par ATAK device → TAK Server → passerelle → API C2 → passerelle → TAK Server → ATAK device introduit des délais pouvant atteindre plusieurs secondes selon les intervalles d'interrogation et les conditions réseau. Pour le partage de pistes en quasi-temps réel, le modèle d'abonnement TAK Server utilisant des connexions WebSocket est préférable à l'interrogation REST.

Pattern plugin : intégration C2 sur l'appareil

Le pattern plugin exécute l'intégration C2 directement sur l'appareil ATAK. Le plugin maintient une connexion à l'API C2 (REST ou WebSocket) et injecte des événements CoT directement dans le bus d'événements interne d'ATAK, contournant entièrement TAK Server pour le flux de données entrant. Cela élimine un saut réseau et permet au plugin d'ajouter un contexte spécifique à l'appareil — la position actuelle de l'opérateur, les éléments de carte sélectionnés, les tâches actives — aux rapports C2 sortants.

Le flux inverse — d'ATAK vers le système C2 — fonctionne en s'abonnant au bus d'événements CoT d'ATAK via CotEventListener. L'écouteur reçoit tous les événements CoT visibles par ATAK, y compris ceux provenant d'autres appareils. Le plugin doit filtrer avec soin : il ne doit transmettre que les événements originés par l'appareil actuel (vérifier le préfixe UID), et il ne doit pas retransmettre les événements qui sont arrivés du système C2 via la passerelle, sous peine de créer une boucle de rétroaction qui inonde le C2 de pistes dupliquées.

Sécurité : signature, certificats et gestion de la classification

La sécurité des plugins ATAK est appliquée à deux niveaux : l'exigence de signature du plugin et l'exigence de chiffrement du transport CoT. Les deux doivent être traités pour tout plugin destiné à un usage opérationnel.

Signature des plugins

ATAK dans les configurations gouvernementales exige que les plugins soient signés par une autorité de certification de confiance. Cela est distinct de la signature Google Play — l'ancre de confiance est l'autorité de certification du TAK Server, non Google. L'APK du plugin doit être signé avec un certificat de cette autorité de certification avant qu'ATAK ne le charge. Le flux de travail est le suivant : générer une paire de clés, soumettre une demande de signature de certificat à l'administrateur TAK Server, intégrer le certificat signé dans le keystore du plugin, et signer l'APK avec ce keystore. Les plugins non signés ou signés par une autorité de certification non approuvée sont rejetés silencieusement.

Dans les environnements de développement, il est courant d'utiliser une autorité de certification auto-signée et de distribuer le certificat de l'autorité aux appareils de test manuellement. En production, l'autorité de certification est généralement la même infrastructure PKI utilisée pour l'authentification client sur les connexions TLS de TAK Server.

Transport CoT chiffré

Le trafic CoT dans les environnements de production circule sur TLS avec authentification mutuelle — le client et le serveur présentent tous deux des certificats. Cela signifie que chaque appareil ATAK a besoin d'un certificat client émis par l'autorité de certification TAK Server, et que le TAK Server a besoin d'un certificat serveur approuvé par les clients. L'inscription des certificats est gérée via le point de terminaison d'inscription de TAK Server, qui émet des certificats clients sur la base d'un mot de passe ou d'un jeton d'inscription pré-partagé.

Un plugin qui ouvre ses propres connexions réseau vers le backend C2 doit également utiliser TLS avec épinglage de certificat. Permettre au plugin de revenir au texte clair — même temporairement, pendant le développement — crée une habitude qui persiste en production. Construire avec TLS dès le premier jour.

Marquages de classification dans CoT

Les événements CoT portant des données classifiées utilisent le sous-élément detail/classification pour marquer l'événement avec un niveau de classification. Le rendu standard d'ATAK ne distingue pas visuellement les événements classifiés des événements non classifiés — il revient au plugin et à l'administrateur système de s'assurer que les événements classifiés ne sont transmis que sur des réseaux classifiés et stockés uniquement sur des appareils approuvés. Un plugin conçu pour les environnements classifiés doit vérifier la classification des événements qu'il reçoit avant de les afficher ou de les transmettre, et doit refuser de transmettre des événements classifiés à des systèmes qui ne sont pas autorisés à les recevoir.

Cas d'utilisation courants des plugins

Les plugins ATAK les plus précieux sur le plan opérationnel suivent un pattern récurrent : ils font le pont entre une source de données spécialisée et l'image opérationnelle commune, réduisant le nombre d'écrans séparés qu'un opérateur doit surveiller.

Superposition vidéo UAV. Le plugin reçoit un flux vidéo d'un GCS (station de contrôle au sol) UAV via RTSP ou HLS et l'affiche dans un panneau ATAK. Simultanément, il reçoit la télémétrie du GCS — position de l'UAV, azimut et angle de dépression du cardan, champ de vision du capteur — et rend un polygone d'empreinte sur la carte ATAK montrant exactement ce que la caméra UAV regarde actuellement. Les opérateurs peuvent appuyer sur un point dans l'empreinte pour obtenir des coordonnées précises, permettant un transfert rapide de cible sans station GCS séparée.

Affichage de contacts SIGINT. Un récepteur de radiogoniométrie rapporte des lignes de relèvement — la direction depuis un point de collecte connu vers un émetteur d'intérêt. Le plugin les convertit en événements CoT de lignes de relèvement et les affiche sur la carte ATAK sous forme de lignes rayonnantes avec des cônes d'incertitude. Lorsque deux lignes de relèvement ou plus se croisent, le plugin peut calculer et afficher une position estimée de l'émetteur. Cette capacité s'intègre directement dans l'image tactique sans nécessiter une station de travail SIGINT séparée. Pour plus d'informations sur l'intégration de sources de données RF, voir notre article sur l'intégration de logiciels radio tactiques.

Suivi logistique et de ravitaillement. Un plugin logistique se connecte au système de chaîne d'approvisionnement de l'unité et affiche la position actuelle des véhicules de ravitaillement, leur heure d'arrivée estimée à la ligne avant et le contenu de chaque véhicule. Les demandes de ravitaillement soumises via le plugin génèrent des événements CoT structurés qui remontent vers le système logistique via la passerelle C2, bouclant le cycle demande-livraison sans trafic radio vocal.

Suivi des victimes. Un plugin de statut médical permet aux médecins d'enregistrer les événements de victimes — catégorie (urgente, prioritaire, routinière), mécanisme de blessure, traitement administré, statut d'évacuation — directement sur la carte ATAK au point de blessure. L'événement est un point CoT avec un bloc de détail médical. Il parvient en temps réel à l'affichage WinTAK du médecin de bataillon et au système de coordination MEDEVAC via la passerelle C2, éliminant le rapport radio à 9 lignes comme seul moyen de transmettre des données sur les victimes sous le feu.

Demandes d'appui-feu. Un plugin de feux numériques automatise la préparation et la transmission des demandes d'appui-feu. L'opérateur sélectionne une cible sur la carte ATAK, remplit un formulaire de demande structuré (description de la cible, méthode d'attaque, marquage de danger proche) et le plugin génère un événement CoT de feux normalisé. L'événement parvient simultanément à l'affichage de l'officier d'appui-feu et au système C2 de feux, sans ressaisie. Le plugin peut recevoir des accusés de réception d'appel de feu et des messages de tir en retour du C2 de feux et les afficher sur l'appareil de l'opérateur.

Pour un traitement détaillé de la façon dont CloudTAK sert de colonne vertébrale serveur pour ces intégrations dans les environnements en réseau, voir notre guide sur l'intégration de l'API CloudTAK.

Tests et déploiement

Tester un plugin d'intégration ATAK C2 nécessite un environnement de test représentatif : une instance TAK Server, au moins deux appareils ATAK (l'un générant des événements, l'autre les observant) et une instance de test ou un simulateur du système C2. Les défaillances d'intégration les plus fréquentes — événements obsolètes non rafraîchis, UIDs dupliqués, boucles de rétroaction dans le flux inverse — ne se manifestent que sous charge avec plusieurs appareils actifs simultanément.

Le déploiement est géré via les paquets de données TAK Server. Un paquet de données est une archive ZIP contenant l'APK du plugin, le fichier de configuration du plugin (pré-rempli avec les adresses serveur et les identifiants) et le certificat de l'autorité de certification requis pour TLS. L'opérateur installe le paquet de données depuis le gestionnaire d'importation d'ATAK, et tous les composants sont provisionnés en une seule étape. Cela est nettement plus fiable que l'installation manuelle d'APK et l'inscription de certificats dans les conditions terrain.

Les tests d'impact sur la batterie méritent une attention particulière. Un plugin maintenant une connexion WebSocket persistante à une API C2 peut ajouter 15 à 25 % de consommation de batterie supplémentaire sur un appareil durci typique. Utiliser l'outil battery historian d'Android pour mesurer et optimiser les patterns de wake lock et d'activité réseau du plugin avant le déploiement. Les opérateurs remarqueront — et désactiveront — un plugin qui vide leur appareil notablement plus vite que l'ATAK de base.