Suivi de forces amies Android : ATAK, CoT et architecture réseau

Par l'équipe d'ingénierie de Corvus Intelligence · À propos de l'équipe →

25 juin 2026 11 min de lecture

Le suivi de forces amies (BFT) est l'une des capacités les plus importantes qu'une unité débarquée puisse emporter : la possibilité de voir, en quasi temps réel, où se trouve chaque élément ami sur la carte. Pendant des années, cette capacité était le domaine exclusif de terminaux dédiés coûteux. Les plateformes Android exécutant ATAK (Android Team Awareness Kit) ont changé la donne — un smartphone ou une tablette durcis avec une radio MANET délivre désormais un BFT permanent à une fraction du coût du matériel hérité, avec une architecture de plug-ins ouverte qui permet à des flux de capteurs personnalisés, des couches IA et des outils de planification de mission de coexister avec la couche de suivi. Cet article couvre la pile BFT complète : schéma d'événements de position CoT, configuration SA ATAK, gestion des flux du TAK Server, intégration du transport radio MANET, profilage cadence de mise à jour / batterie, et comportement du système en cas de perte de connectivité.

Exigences BFT pour les unités tactiques

Avant de toucher à la configuration logicielle, un déploiement BFT exige une base d'exigences explicite. Les paramètres qui guident chaque décision ultérieure sont la précision de position, la fréquence de mise à jour, la latence d'affichage, et les contraintes imposées par les appareils et radios en usage.

Précision de position. Le BFT d'infanterie débarquée vise une erreur circulaire probable (CEP) de 10 mètres ou mieux — suffisant pour le désengagement en terrain urbain où la résolution au niveau du bâtiment compte. Le BFT monté sur véhicule accepte typiquement CEP 50 m. Les appareils Android à GNSS multi-constellations (GPS + GLONASS + Galileo) atteignent 3 à 5 m de CEP en terrain dégagé ; une canopée dense ou les canyons urbains le dégradent à 15 à 30 m sans augmentation. Le SBAS (WAAS/EGNOS) assiste les récepteurs GNSS des appareils compatibles ATAK, resserrant encore la précision dans les zones géographiques prises en charge.

Fréquence de mise à jour. La cadence de mise à jour de position détermine la fraîcheur des traces sur les cartes des unités adjacentes. Des intervalles de 5 à 10 secondes sont la norme pour les unités au contact direct ou menant des opérations de proximité. Des intervalles de 30 à 60 secondes conviennent aux unités en appui ou en réserve. La cadence de mise à jour multiplie directement la charge du canal : chaque doublement du nombre d'unités ou chaque division par deux de l'intervalle double la consommation de bande passante sur le réseau radio partagé.

Latence d'affichage. La latence d'affichage de bout en bout — de l'événement de position généré sur l'appareil source à l'apparition de la trace sur tous les affichages connectés — doit rester sous 3 secondes pour les opérations où le désengagement dépend de la position en temps réel. Les contributions à la latence incluent le temps de fix GPS, la génération d'événement CoT, la transmission radio, le traitement serveur et le rendu client. Sur un MANET bien configuré avec TAK Server local, la latence totale se situe typiquement entre 500 ms et 1.5 s. Les configurations à backhaul satellite ajoutent 600 ms à 1.2 s de délai aller simple.

Contraintes d'appareils et de radios. Les appareils Android durcis utilisés pour le BFT — Samsung XCover Pro, Kyocera DuraForce Pro 2, Getac PS336 — portent des batteries dimensionnées pour des services de 8 à 16 heures, mais le GPS et les transmissions radio puisent fortement dans cette capacité. Les radios MANET se connectent typiquement via USB OTG ou point d'accès Wi-Fi ; la connexion en point d'accès ajoute elle-même une charge d'antenne et de RF. Les limites thermiques en environnement chaud réduisent la puissance d'émission soutenue sur l'appareil Android et sur la radio, réduisant potentiellement la portée effective et imposant donc des intervalles de mise à jour plus courts pour compenser la perte de paquets accrue.

Événements de position Cursor on Target (CoT)

La norme CoT définit un schéma d'événements XML que chaque élément du réseau BFT parle. Comprendre ce schéma est essentiel pour diagnostiquer les pannes BFT et pour écrire des plug-ins personnalisés qui injectent ou consomment des données de position.

Schéma XML CoT pour les événements SA

Un événement de position minimal d'une unité terrestre amie ressemble à ceci :

<?xml version="1.0" standalone="yes"?>
<event version="2.0"
  uid="ANDROID-BFT-ALPHA-1"
  type="a-f-G-U-C"
  time="2026-06-25T08:30:00.000Z"
  start="2026-06-25T08:30:00.000Z"
  stale="2026-06-25T08:30:45.000Z"
  how="m-g">
  <point lat="49.8391" lon="24.0297"
         hae="320.0" ce="9.0" le="999999.0"/>
  <detail>
    <contact callsign="ALPHA-1"/>
    <uid Droid="ALPHA-1"/>
    <group name="Cyan" role="Team Member"/>
    <status battery="72"/>
    <track speed="1.4" course="045.0"/>
    <precisionlocation geopointsrc="GPS" altsrc="GPS"/>
  </detail>
</event>

Les champs clés pour le BFT sont :

uid — identifiant unique de la trace. Doit rester stable d'une mise à jour de position à l'autre ; ATAK utilise l'IMEI de l'appareil ou un UUID généré.
type — code de type CoT (voir ci-dessous) codant l'appartenance, la dimension et le type de plateforme.
time / start — horodatage de génération de l'événement en ISO 8601 UTC. La précision de l'horloge ici est critique : un décalage d'horloge provoque un rejet pour expiration sur le serveur récepteur.
stale — horodatage après lequel l'événement est considéré expiré. ATAK règle stale sur time + (intervalle de mise à jour × 3) par défaut, laissant trois mises à jour manquées avant que la trace ne devienne fantôme.
how — méthode d'entrée de la position : m-g (GPS machine), h-g-i-g-o (GPS saisi par l'humain), m-g-i (GPS inféré).
point — coordonnées WGS84 : lat/lon en degrés décimaux, hae (hauteur au-dessus de l'ellipsoïde WGS84) en mètres, ce (erreur circulaire) et le (erreur linéaire) en mètres.

Codes de type CoT pour ami, hostile et neutre

Les codes de type CoT suivent un schéma hiérarchique : a-[appartenance]-[dimension de combat]-[fonction]. Pour le BFT, le caractère d'appartenance est le discriminateur critique :

Préfixe de type	Appartenance	Couleur d'icône ATAK	Exemple
`a-f-`	Ami	Bleu	`a-f-G-U-C` — unité terrestre amie, combat
`a-h-`	Hostile	Rouge	`a-h-G-U-C` — unité terrestre hostile, combat
`a-n-`	Neutre	Vert	`a-n-G-E-V-C` — véhicule terrestre neutre, civil
`a-u-`	Inconnu	Jaune	`a-u-G-U` — unité terrestre inconnue

Gestion du délai d'expiration (stale)

L'horodatage d'expiration est le mécanisme principal de nettoyage des traces sur la situation opérationnelle commune. Le multiplicateur d'expiration par défaut d'ATAK est de 3× l'intervalle de mise à jour SA configuré : à une cadence de 10 secondes, stale est réglé 30 secondes dans le futur. Si trois événements de position consécutifs sont perdus (perte de paquets, black-out radio, extinction de l'appareil), la trace entre en état périmé et ATAK la restitue avec une icône estompée. Après un délai de grâce configurable par l'opérateur (5 minutes par défaut dans la plupart des déploiements), la trace périmée est retirée de la carte.

Pour le BFT dans les environnements à forte perte de paquets (urbain dense, canopée jungle, liaisons à backhaul SATCOM), augmentez le multiplicateur d'expiration à 6 à 10× pour éviter un fantomatage excessif des traces. Cela se configure par appareil dans ATAK sous Paramètres → Réseau → Rapports SA → Minuteur d'expiration. Côté TAK Server, le seuil d'expiration propre au serveur (600 secondes par défaut) contrôle combien de temps le serveur conserve une trace dans sa base de données avant de l'expirer — les clients qui se connectent récemment ne recevront pas les traces ayant dépassé le seuil d'expiration du serveur.

ATAK comme client BFT

ATAK gère le BFT entièrement via son sous-système SA (connaissance de la situation). Aucun plug-in supplémentaire n'est requis pour le BFT de base — la capacité est intégrée à l'application ATAK de base. Les plug-ins étendent le BFT avec des sources de données personnalisées, des couches d'affichage et des chemins de transmission au-delà des options standard serveur et multidiffusion.

Configuration SA dans ATAK

Les commandes de configuration BFT principales se trouvent sous Paramètres → Réseau → Préférences de rapports :

Reporting Rate (Moving) — intervalle de transmission CoT quand l'appareil est en mouvement. Réglez sur 5 à 10 s pour l'infanterie débarquée, 3 à 5 s pour le monté sur véhicule avec alimentation externe.
Reporting Rate (Stationary) — intervalle quand l'appareil n'a pas dépassé le seuil de mouvement. Réglez sur 30 à 120 s pour économiser la batterie pendant les phases statiques.
Dynamic SA Reporting — une fois activé, ATAK bascule automatiquement entre les cadences en mouvement et à l'arrêt selon l'accéléromètre. C'est le mode recommandé pour tous les déploiements BFT opérationnels.
My Team — assigne l'appareil à un groupe (Cyan, Magenta, Yellow, etc.), qui détermine la couleur d'icône que les autres unités voient pour cette trace et contrôle le filtrage de groupe côté serveur.
My Role — définit le sous-type de fonction dans le code de type CoT (Team Member, Team Leader, HQ, Medic, Forward Observer, etc.).

Types de connexion réseau

ATAK prend en charge trois types de connexion réseau pour la livraison des données BFT :

TCP/TLS vers TAK Server (port 8089). C'est le mode opérationnel standard. ATAK établit une connexion TLS persistante authentifiée par un certificat client PKCS#12. Le serveur délivre toutes les traces abonnées au client via cette connexion et reçoit les événements de position du client pour distribution. TCP assure une livraison fiable et prend en charge de grandes charges utiles de messages (paquets de mission, paquets de données) en plus des événements CoT.

Multidiffusion UDP. ATAK peut diffuser et recevoir des événements CoT sur une adresse de multidiffusion UDP (par défaut 239.2.3.1:6969). Ce mode fonctionne sans aucune infrastructure serveur — les appareils se découvrent via le groupe de multidiffusion partagé. Il convient au BFT pair à pair sur des segments réseau locaux (point d'accès Wi-Fi ou espace IP local radio MANET) mais ne prend pas en charge la fédération, le filtrage ni l'historique persistant des traces. Les pertes de paquets en mode multidiffusion ne sont pas retransmises : un événement de position manqué n'apparaît tout simplement pas.

Flux TCP (hérité). Un ancien mode de flux XML non chiffré, désormais obsolète au profit de TLS. À n'utiliser dans aucun déploiement opérationnel.

Architecture de plug-ins pour des flux BFT personnalisés

L'API de plug-in d'ATAK permet à des applications tierces d'injecter des événements CoT dans la carte ATAK locale sans passer par le serveur. Un plug-in BFT personnalisé peut recevoir des données de position d'une forme d'onde radio propriétaire, d'un dispositif de suivi matériel (via USB série), ou d'une estimation de position dérivée de l'IA, et l'injecter comme événement CoT standard visible sur l'affichage ATAK. Le plug-in communique avec le noyau ATAK via l'interface d'intent CotMapComponent, en publiant des intents de diffusion com.atakmap.android.maps.COT_RECEIVER avec la charge utile XML CoT. Consultez notre guide sur ATAK integration field operations pour un parcours détaillé de développement de plug-in.

Gestion des flux SA du TAK Server

Le TAK Server est le hub qui agrège les événements de position BFT de tous les clients ATAK connectés et les distribue aux abonnés. Une configuration serveur correcte est aussi importante que les paramètres client pour un BFT fiable.

Fédération de serveurs pour une SA inter-unités

Quand le BFT doit couvrir plusieurs instances TAK Server indépendantes — par exemple un serveur de compagnie et un serveur de bataillon, ou un échelon avant et arrière — TAK server federation setup fournit l'interconnexion. La fédération transmet les types CoT sélectionnés à travers la frontière de serveur en quasi temps réel. Pour le BFT, configurez le filtre de fédération pour laisser passer les événements a-f- (atom ami) de façon bidirectionnelle. Ne passez pas les a-h- (hostiles) à travers les frontières de fédération sauf si le traitement de classification aux deux extrémités est vérifié — le renseignement de position hostile est souvent plus sensible que les données de position amies.

Abonnement aux flux SA et isolation de groupe

Le TAK Server gère quels clients reçoivent quelles traces via son système de groupes. Quand un client ATAK se connecte avec un certificat assigné au groupe « PLATOON-1 », il reçoit automatiquement tous les événements CoT des autres clients du même groupe, plus tous les groupes que PLATOON-1 est configuré pour voir (par ex. « COMPANY-HQ »). Ce modèle d'abonnement basé sur les groupes élimine le besoin de toute configuration d'abonnement de trace par client — l'appartenance à un groupe détermine l'ensemble de la situation SA.

L'isolation des groupes d'utilisateurs est aussi le mécanisme de séparation de classification. Assignez les clients ATAK du réseau SECRET à un groupe sans chevauchement de visibilité avec les groupes UNCLASSIFIED. Le serveur n'acheminera jamais de traces SECRET vers des clients UNCLASSIFIED quel que soit le type ou le contenu CoT. Pour des frontières de classification strictes, exécutez des instances TAK Server entièrement séparées sur des segments réseau physiquement distincts, sans lien de fédération entre elles.

Configuration des flux SA CloudTAK

# Create a user group for BFT population
curl -s -X POST https://tak.yourdomain.com:8443/api/groups \
  -H "Authorization: Bearer $ADMIN_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "PLATOON-1",
    "direction": "BOTH",
    "description": "1st Platoon BFT group",
    "bitpos": 0
  }'

# Assign a user certificate to the group
curl -s -X PUT https://tak.yourdomain.com:8443/api/users/alpha-1/groups \
  -H "Authorization: Bearer $ADMIN_TOKEN" \
  -H "Content-Type: application/json" \
  -d '["PLATOON-1", "COMPANY-HQ"]'

Le champ direction contrôle si le groupe est un groupe d'entrée (les événements circulent EN provenance de ce client), un groupe de sortie (les événements circulent VERS ce client), ou BOTH. Régler BOTH est la norme pour le BFT — chaque appareil contribue et reçoit des traces dans ses groupes assignés.

Transport radio maillé pour le BFT

La liaison radio est l'élément le plus contraint opérationnellement de la pile BFT Android. Les radios MANET fournissent le réseau IP pair à pair qui connecte les appareils ATAK quand l'infrastructure Wi-Fi et la couverture cellulaire sont indisponibles. Comprendre comment ATAK s'intègre au matériel MANET est critique pour des performances BFT prévisibles en opérations débarquées. Notre article sur le military mesh network MANET couvre la couche réseau sous-jacente en détail ; cette section se concentre sur l'intégration ATAK spécifiquement.

Intégration des radios MANET avec ATAK

Harris RF-7800W (Falcon III). Le RF-7800W se connecte à l'appareil Android via USB OTG, exposant une interface réseau RNDIS (USB Ethernet). L'adresse IP de la radio sur cette interface est typiquement 192.168.100.1. ATAK traite l'interface RNDIS comme une interface réseau standard — aucun pilote ni application compagnon spécial n'est requis. Configurez la connexion serveur d'ATAK pour pointer vers l'adresse IP du TAK Server telle qu'elle est joignable via le réseau maillé de la radio. Pour un BFT pair à pair local sans serveur, configurez la sortie de multidiffusion UDP d'ATAK sur l'adresse de l'interface RNDIS.

Persistent Systems MPU5. Le MPU5 fonctionne comme point d'accès Wi-Fi ou comme périphérique USB RNDIS. En mode point d'accès, l'appareil Android se connecte au SSID Wi-Fi du MPU5 ; l'adresse IP de gestion de la radio est accessible à 10.168.1.1 par défaut. Persistent Systems fournit une application Android compagnon (Wave Relay Mobile) qui s'intègre à ATAK pour exposer l'état de la forme d'onde, la carte des nœuds et les métriques de qualité de lien en tant que couche ATAK native. Les événements CoT ATAK circulent via le chemin TCP ou UDP standard à travers le maillage IP du MPU5.

Allocation de bande passante pour le trafic SA

Quantifier le budget de bande passante BFT avant le déploiement évite de surcharger le maillage au pire moment possible. Un seul événement de position CoT avec bloc de détails complet fait 800 à 1200 octets. À un intervalle de mise à jour de 10 secondes pour une escouade de 12 personnes :

Units:          12
Event size:     1000 bytes
Update rate:    10 seconds
Raw BFT load:   12 × 1000B / 10s = 1200 B/s ≈ 9.6 kbps

With TCP/TLS overhead (≈15%): ~11 kbps
With zlib CoT compression (≈50% reduction): ~5.5 kbps

MPU5 capacity (typical multi-hop mesh):  500 kbps–5 Mbps
RF-7800W capacity (typical):             200–500 kbps

BFT as % of RF-7800W at 200 kbps:        ~5.5% — acceptable
BFT as % of HF/SATCOM backhaul (32 kbps): ~17% — significant

À l'échelle d'une compagnie (100+ unités à intervalles de 10 secondes), la charge BFT brute dépasse 80 kbps avant les surcharges — une fraction significative de tout backhaul HF ou SATCOM. Dans ces environnements, augmentez les intervalles de mise à jour à l'arrêt à 120+ secondes et appuyez-vous sur des rafales déclenchées par le mouvement pour maintenir la charge agrégée sous 20 kbps sur la liaison de backhaul.

Cadence de mise à jour de position / autonomie

La cadence de mise à jour de position est le paramètre de configuration BFT le plus impactant pour l'autonomie. L'acquisition GPS et la transmission radio sont les deux plus gros prélèvements de puissance sur un appareil BFT ATAK ; les deux évoluent directement avec la fréquence de mise à jour.

Profilage de la batterie en conditions opérationnelles

Sur un Samsung Galaxy XCover Pro (batterie 4050 mAh) exécutant ATAK avec verrouillage GPS continu :

Cadence de mise à jour	Prélèvement GPS	Prélèvement radio (point d'accès MPU5)	Autonomie BFT estimée
5 s (agressif)	~120 mA	~180 mA	~8–9 h
10 s (standard)	~120 mA	~120 mA	~10–12 h
30 s (patrouille)	~90 mA	~60 mA	~15–18 h
120 s (statique)	~60 mA	~20 mA	~22–26 h

Le prélèvement GPS est relativement stable quelle que soit la cadence de mise à jour car ATAK maintient le récepteur GPS en mode de suivi continu pour garantir que la position est toujours à jour quand une mise à jour se déclenche. La variable est le cycle de service de transmission radio : à des intervalles de 5 secondes, la radio est active presque en continu ; à des intervalles de 120 secondes, les rafales de transmission n'occupent que 1 à 2 % du cycle de service.

Stratégies de cadence de mise à jour adaptative

Le mode Dynamic SA Reporting d'ATAK implémente une stratégie adaptative à deux cadences. Une approche plus sophistiquée utilise des plug-ins ATAK ou des commandes de push côté serveur pour ajuster les cadences de mise à jour selon le contexte opérationnel :

Bascule de cadence basée sur le mouvement — déclenchée par accéléromètre : si l'appareil a bougé de plus de 10 m depuis la dernière transmission, transmettre immédiatement quel que soit l'intervalle planifié. ATAK implémente cela nativement en mode Dynamic SA.
Rafales de mise à jour déclenchées par géorepérage — quand une unité franchit une frontière de géorepérage définie (entrée en zone objectif, franchissement de ligne de phase), déclencher une cadence de mise à jour en rafale de 5 secondes pendant 60 secondes, puis revenir à la cadence de fond. Configurez les déclencheurs de géorepérage via les plug-ins de géorepérage ATAK ou l'API de géorepérage du TAK Server.
Escalade de cadence déclenchée par le contact — quand le TAK Server détecte une trace hostile dans un rayon défini d'une unité amie, il envoie une notification push au client ATAK de l'unité amie via le canal CoT serveur-vers-client, déclenchant le basculement du client vers sa cadence de mise à jour rapide. Cela exige un plug-in côté serveur personnalisé ou une couche d'intégration IA.
Réduction de cadence sur seuil de batterie — un agent de gestion d'appareil (profil MDM ou plug-in ATAK) surveille la batterie de l'appareil et relève automatiquement l'intervalle SA quand la batterie descend sous 30 %, troquant la fraîcheur de position contre la poursuite de l'opération à travers une phase critique.

Connaissance de la situation en mode déconnecté

Aucun réseau radio MANET ne fonctionne parfaitement sur toute une zone opérationnelle. Le masquage par le terrain, la guerre électronique, les pannes radio et l'emcon délibéré (contrôle d'émission) produisent tous des périodes d'opération déconnectée. Une conception BFT robuste doit définir exactement ce que fait le système quand la liaison radio est absente.

Affichage de la dernière position connue

Quand ATAK perd la connectivité au TAK Server (ou perd la réception multidiffusion en mode pair à pair), il continue d'afficher toutes les traces à leurs dernières positions reçues. La différenciation visuelle entre traces à jour et traces périmées est contrôlée par l'horodatage d'expiration CoT : une fois le temps d'expiration d'une trace dépassé, ATAK la restitue avec un voile de transparence et une annotation d'horodatage indiquant depuis combien de temps la position a été reçue pour la dernière fois. Les traces persistent dans cet état périmé jusqu'à ce qu'elles atteignent le seuil de suppression par expiration de la carte ATAK (configurable par déploiement ; 5 minutes par défaut).

Les opérateurs doivent être formés à reconnaître et à agir sur les indicateurs de trace périmée. Une position de trace vieille de 3 minutes pour une unité débarquée se déplaçant au pas d'infanterie peut représenter 180 à 360 mètres de déplacement réel — suffisant pour créer un risque de tir ami si elle est traitée comme à jour. Les SOP doivent préciser que les traces périmées ne servent qu'à la connaissance générale d'une zone, et non au désengagement de l'appui-feu.

Intégration de l'affichage par estime (dead reckoning)

ATAK prend en charge l'extrapolation de trace par estime via l'élément de détail track des événements CoT, qui porte la vitesse et le cap. Quand une trace devient périmée, un plug-in d'estime peut projeter la position actuelle estimée de la trace à partir du dernier point connu en utilisant les vecteurs de vitesse et de cap rapportés. La position projetée est affichée avec une icône distincte (généralement un symbole ouvert/pointillé) pour la distinguer d'une position confirmée par GPS.

La précision de l'estime se dégrade rapidement pour l'infanterie débarquée (vitesse et cap changent constamment) et est plus fiable pour les véhicules sur des réseaux routiers connus. N'implémentez l'affichage par estime que lorsque les opérateurs comprennent ses limites et que le SOP distingue clairement les positions projetées des positions confirmées.

Reconnexion et réconciliation SA

Quand ATAK se reconnecte au TAK Server après une période déconnectée, le serveur effectue un push complet d'état SA : il délivre l'événement CoT actuel (ou le plus récent) pour chaque trace des groupes abonnés du client. Cette mise à jour en rafale écrase les dernières positions connues périmées sur la carte client avec les données actuelles détenues par le serveur. Le processus de réconciliation s'achève en 1 à 3 secondes pour des tailles d'unité typiques (moins de 200 traces).

# Verify reconnection burst via CloudTAK events WebSocket
# (Use wscat or a browser WebSocket client for testing)
# wss://tak.yourdomain.com:8443/api/events?groups=PLATOON-1
#
# On reconnect, expect a rapid burst of CoT events — one per known
# track — within the first 2–3 seconds of the WebSocket session.
# Monitor the event count to confirm all expected tracks are delivered.
#
# If the burst is partial, check server-side stale threshold:
# GET /api/config/cot-stale-seconds
# Default: 600s — tracks older than 10 min are not pushed to reconnecting clients

Un cas limite à anticiper : si la période déconnectée dépasse le seuil d'expiration du serveur (600 secondes par défaut pour CloudTAK), le serveur a déjà expiré les traces périmées de son stockage actif. À la reconnexion, ces traces n'apparaîtront pas dans la mise à jour en rafale et ne réapparaîtront que lorsque les appareils sources transmettront de nouveaux événements de position. Pour les opérations où les reconnexions peuvent suivre des black-out de communications de plusieurs heures, augmentez le seuil d'expiration du serveur pour l'aligner sur la durée maximale de black-out attendue.

Implémentez le BFT pour votre unité ou organisation

Nous concevons et déployons des systèmes de suivi de forces amies basés sur ATAK pour la défense et les organisations gouvernementales — y compris la configuration de TAK Server, l'intégration de radios MANET, le copilote IA TAKpilot, et le développement de plug-ins spécifiques à la mission.

TAKpilot AI Copilot → Book a Briefing

Cette analyse a été préparée par les ingénieurs de Corvus Intelligence qui développent des logiciels critiques pour les organisations de défense et gouvernementales. En savoir plus sur notre équipe →

Questions fréquentes

Qu'est-ce que le suivi de forces amies sur Android militaire ?

Le suivi de forces amies (BFT) sur Android militaire désigne l'affichage et la transmission en temps réel des positions d'unités amies sur une carte numérique partagée. ATAK (Android Team Awareness Kit) est le client BFT principal : il lit la position GPS de l'appareil, l'empaquette en événement XML Cursor on Target (CoT), et transmet cet événement à un TAK Server ou directement aux appareils pairs en multidiffusion ou radio MANET. Le serveur agrège les événements de position de toutes les unités connectées et les diffuse à chaque client ATAK, de sorte que chaque soldat voit toutes les traces amies simultanément. Les cadences de mise à jour, la symbologie cartographique et les chemins de connectivité sont tous configurables dans les paramètres SA d'ATAK.

Qu'est-ce que Cursor on Target et comment est-il utilisé pour le BFT ?

Cursor on Target (CoT) est un format de message basé sur XML, à l'origine développé par l'US Air Force pour partager des données tactiques de position et de statut entre systèmes hétérogènes. Pour le BFT, le type d'événement CoT clé est l'événement « atom » (préfixe de type « a- »), qui porte un élément point avec coordonnées lat/lon/hae, un horodatage d'expiration (stale) indiquant quand la position expire, et un bloc de détails contenant l'indicatif, la couleur d'équipe et le rôle. ATAK génère ces événements automatiquement depuis le GPS de l'appareil à un intervalle configurable (typiquement toutes les 5 à 30 secondes) et les transmet au TAK Server, qui les rediffuse à tous les clients abonnés. L'horodatage d'expiration garantit que, si une unité cesse d'émettre, sa trace disparaît automatiquement de l'affichage des autres unités après la fenêtre d'expiration définie.

Quelle cadence de mise à jour configurer pour le BFT ATAK en opérations tactiques ?

La cadence de mise à jour BFT optimale dépend du type de mission, de la bande passante radio et des contraintes de batterie. Pour l'infanterie débarquée au contact, une cadence de 5 à 10 secondes assure une position suffisamment fraîche ; pour les unités montées sur véhicule avec alimentation externe, 3 à 5 secondes est praticable. Sur des liens MANET contraints en bande passante, augmentez l'intervalle à 30 à 60 secondes pour les unités non manœuvrantes et appuyez-vous sur des rafales déclenchées par le mouvement (événements de sortie de géorepérage) pour des mises à jour immédiates quand une unité se déplace. La fonction de rapports SA adaptatifs d'ATAK peut basculer automatiquement entre une cadence lente en arrière-plan et une cadence rapide au contact, sur la base de la vitesse de mouvement détectée par l'accéléromètre de l'appareil.

Comment ATAK se connecte-t-il à un TAK Server pour le BFT ?

ATAK prend en charge trois types de connexion principaux pour le BFT : (1) flux TCP — une connexion TCP/TLS persistante vers le port 8089 du TAK Server, utilisée pour une livraison unicast fiable avec authentification par certificat ; (2) multidiffusion UDP — événements CoT diffusés sur une adresse de multidiffusion dans un segment réseau local, adaptés aux environnements LAN ou MANET sans infrastructure serveur ; et (3) Streaming XML — un mode TCP hérité utilisant des flux XML non chiffrés, désormais obsolète. Pour les déploiements opérationnels, TCP/TLS vers un TAK Server est la norme. Les paramètres réseau d'ATAK acceptent un nom d'hôte de serveur, un port et un ensemble de certificats PKCS#12 pour l'authentification TLS mutuelle.

Quelles radios MANET s'intègrent à ATAK pour le BFT ?

ATAK s'intègre aux radios MANET via USB OTG Android ou l'application Android compagnon de la radio. Les radios couramment intégrées incluent Harris RF-7800W (série Falcon III), Persistent Systems MPU5, Domo Tactical PRC-ACM et Silvus StreamCaster. Chaque radio expose une interface réseau virtuelle ou un service de relais CoT qu'ATAK reconnaît comme liaison de données TAK. La radio gère le routage IP sur le maillage, et ATAK envoie des paquets UDP multidiffusion ou TCP CoT standard vers l'adresse IP locale de la radio. Certaines radios exposent aussi une API de gestion de forme d'onde que les plug-ins ATAK peuvent interroger pour surveiller la qualité du lien et adapter en conséquence les paramètres de transmission SA.

Comment le TAK Server gère-t-il les flux SA pour le BFT ?

Le TAK Server maintient un stockage d'événements CoT en mémoire pour tous les clients connectés. Quand un nouvel événement de position CoT arrive, le serveur : (1) écrit l'événement dans la base de données persistante ; (2) évalue les règles de groupe et de filtre pour déterminer quels clients doivent le recevoir ; (3) pousse l'événement vers toutes les connexions clientes abonnées. Pour le BFT spécifiquement, le serveur suit le dernier événement de position par UID et le sert aux clients qui se connectent récemment, afin qu'ils reçoivent immédiatement une situation opérationnelle commune à jour dès la connexion. Les abonnements aux flux SA sont gérés via le système de groupes du serveur — les clients assignés au même groupe partagent automatiquement les traces BFT sans configuration d'abonnement manuelle.

Comment empêcher que les traces BFT n'apparaissent simultanément sur des instances ATAK classifiées et non classifiées ?

La séparation de classification dans un environnement TAK BFT est obtenue par une combinaison d'isolation de groupe côté serveur et de séparation physique du réseau. Sur le TAK Server, assignez les unités classifiées à un groupe non visible des clients non classifiés (par ex. un groupe « SECRET » sans fédération ni abonnement au groupe « UNCLASSIFIED »). Pour une séparation stricte, exécutez deux instances TAK Server entièrement séparées — une sur un segment réseau classifié et une sur un segment non classifié — sans lien de fédération entre elles. Ne vous fiez jamais uniquement aux filtres de groupe logiciels pour la séparation de classification ; une séparation physique ou cryptographique du réseau est nécessaire pour satisfaire les normes d'assurance de l'information.

Que deviennent les traces BFT quand ATAK perd la connectivité au TAK Server ?

Quand ATAK perd la connectivité au serveur, il entre en mode déconnecté. La carte continue d'afficher les dernières positions reçues pour toutes les traces, visuellement différenciées par un indicateur d'expiration (généralement une icône estompée ou une annotation d'horodatage) une fois le temps d'expiration (stale) CoT de la trace dépassé. ATAK continue aussi d'émettre sa propre position par tout chemin de diffusion local disponible (multidiffusion UDP, radio MANET). Quand la connectivité est rétablie, ATAK se reconnecte automatiquement et le serveur pousse l'état actuel de toutes les traces sous forme de mise à jour en rafale, écrasant les dernières positions connues périmées. Les administrateurs doivent définir des délais d'expiration adaptés à leur tempo tactique — une fenêtre d'expiration de 10 minutes empêche le fantomatage des traces dans les environnements à faible connectivité.

Quelle bande passante le BFT sur ATAK consomme-t-il sur un lien MANET ?

Un seul événement de position CoT ATAK (XML CoT avec bloc de détails) fait environ 800 à 1200 octets. Avec un intervalle de mise à jour de 10 secondes pour une section de 20 unités, le trafic BFT total est d'environ 20 × 1000 octets / 10 s = 2 kB/s, soit environ 16 kbps. Cela reste bien dans la capacité des radios MANET modernes (le MPU5 fournit 1 à 10 Mbps par nœud), mais s'accumule vite dans les grandes formations. Pour une compagnie de 100 unités à intervalles de 10 secondes, le trafic BFT brut approche 80 kbps — gérable mais significatif sur des liaisons de backhaul HF ou satellite. La compression CoT (zlib sur le flux TCP) réduit généralement la taille de charge utile de 40 à 60 %, et les cadences de mise à jour adaptatives peuvent réduire la charge d'un ordre de grandeur pendant les phases statiques.

Quels appareils Android sont certifiés pour le BFT militaire avec ATAK ?

ATAK MIL (la variante militaire distribuée via TAK.gov) tourne sur une gamme d'appareils Android durcis. Les plateformes couramment utilisées incluent le Samsung Galaxy XCover Pro, le Getac PS336, le Kyocera DuraForce Pro 2 et les tablettes Dell Latitude Rugged. Pour le BFT spécifiquement, les critères de choix d'appareil incluent la sensibilité du chipset GPS (pour les canyons urbains et la pénétration du feuillage), la capacité de batterie (ou la possibilité de changement à chaud), la plage de température de fonctionnement, et la résistance aux chocs et à l'eau MIL-STD-810. Les appareils à GNSS multi-constellations (GPS + GLONASS + Galileo) fournissent des positions plus fiables en environnement dégradé par rapport aux chipsets GPS seuls.