ATAK-CIV vs ATAK-MIL : choisir et déployer le bon client TAK

Le Team Awareness Kit se décline en deux versions. ATAK-CIV est le client civil ouvert que chacun peut télécharger et utiliser ; ATAK-MIL est la version militaire contrôlée, réservée aux seuls utilisateurs gouvernementaux autorisés. Elles se ressemblent presque à l'écran, partagent le même moteur cartographique et parlent le même langage Cursor on Target — pourtant, choisir la mauvaise version, ou déployer l'une ou l'autre sans précaution, produit le même résultat : une image tactique qui ne se fédère pas, des plugins qui échouent au chargement, ou des données sensibles sur un appareil qui n'a jamais été accrédité pour les détenir. Cet article détaille ce qui distingue réellement les deux variantes, quand chacune est le bon choix, et comment déployer celle que vous retenez sur une flotte afin que chaque appareil du réseau affiche la même image de confiance.

Deux versions, un seul noyau

La chose la plus importante à comprendre sur ATAK-CIV et ATAK-MIL, c'est qu'il s'agit de versions du même produit, et non de deux produits différents. Les deux sont issus du même code source maintenu par le TAK Product Center. Les deux affichent la carte avec le même moteur, les deux utilisent le même cadre de plugins et les deux échangent des données de conscience situationnelle sous forme d'événements Cursor on Target. Si vous avez lu notre introduction au développement de plugins ATAK, cette architecture s'applique de manière identique aux deux variantes — la surface d'API qu'un plugin cible est partagée.

Ce qui distingue les deux, c'est le canal de distribution et l'ensemble de capacités ajoutées au-dessus du noyau commun. ATAK-CIV est publié librement. C'est la version utilisée par les premiers intervenants, les équipes de sécurité d'infrastructures critiques, les organisations de recherche et sauvetage, les unités de volontaires alliés et les développeurs qui construisent et testent des plugins. ATAK-MIL est soumis à un contrôle d'accès, distribué via des canaux gouvernementaux aux seuls utilisateurs autorisés, et ajoute des capacités délibérément absentes de la version civile : gestion des marquages de données classifiées, modules cryptographiques supplémentaires, intégration de formats de messages restreints, et une symbologie et des superpositions spécifiques à l'armée.

Parce que la divergence est additive plutôt que structurelle, le modèle mental est simple : ATAK-MIL est ATAK-CIV auquel s'ajoute une couche de capacités contrôlées et un canal de distribution contrôlé. Tout ce que vous pouvez faire dans CIV, vous pouvez le faire dans MIL ; l'inverse n'est pas vrai, et l'écart est régi autant par l'accréditation et la politique que par le code.

Différences de fonctionnalités et de licences

Sur l'axe des fonctionnalités, les différences pratiques se regroupent en trois domaines. Premièrement, la gestion des données : ATAK-MIL comprend les marquages de classification et les workflows qui leur sont associés — étiqueter le contenu, appliquer les caveats de diffusion et maintenir les données marquées séparées. ATAK-CIV traite tout le contenu comme non classifié. Deuxièmement, la cryptographie : la version militaire peut incorporer des modules cryptographiques approuvés et des intégrations de gestion de clés exigées par les environnements accrédités, tandis qu'ATAK-CIV s'appuie sur le chiffrement de transport standard — TLS vers le serveur — qui convient aux usages non classifiés mais sensibles. Troisièmement, les packs de contenu : certains jeux de symboles, superpositions et intégrations de formats de messages ne sont inclus que dans la version militaire.

Sur l'axe des licences, la différence porte sur qui peut obtenir et utiliser chaque version. ATAK-CIV est distribué selon des conditions autorisant un usage public large, ce qui explique pourquoi un tout un écosystème de plugins et d'intégrations tiers s'est développé autour de lui. ATAK-MIL est réservé aux utilisateurs gouvernementaux autorisés ; l'obtenir en dehors de ce canal n'est pas légal, et aucune relation commerciale ne change cela. Pour toute équipe non gouvernementale, la réponse en matière de licence est donc aussi la réponse en matière de déploiement : le seul client que vous pouvez légitimement déployer est ATAK-CIV.

Interopérabilité : partager une image commune

Étant donné que les deux variantes utilisent le même modèle de données Cursor on Target et peuvent se connecter au même serveur TAK, un appareil CIV et un appareil MIL sur la même fédération se verront mutuellement leurs positions et événements. Au niveau du protocole, il n'y a pas de barrière — un événement CoT publié par l'un est consommable par l'autre, de même que les superpositions géospatiales et le trafic de messagerie qui circulent sur le bus CoT. Pour un aperçu approfondi du fonctionnement de ce bus et de ses contrats de données en pratique, notre vue d'ensemble de l'écosystème TAK open source couvre le serveur, les formats de messages et les intégrations qui s'y rattachent.

La vraie contrainte sur les déploiements mixtes est politique, et non protocolaire. Un serveur TAK accrédité pour transporter du trafic classifié n'admettra pas de clients civils, à juste titre — admettre un appareil CIV dans une image classifiée exposerait des données marquées à un client sans accréditation pour les détenir. Lorsqu'un déploiement nécessite réellement que les deux mondes interopèrent, la réponse est une frontière de domaine de données délibérée : soit une solution interdomaine qui assainit et libère vers le bas le contenu approuvé, soit un serveur non classifié séparé qui ne reflète que le sous-ensemble diffusable de l'image. L'interopérabilité est une décision de déploiement que vous concevez, accréditez et documentez — non pas une case à cocher dans l'application.

Concevoir la frontière de domaine de données

L'architecture la plus courante pour les opérations mixtes CIV/MIL fait fonctionner deux serveurs. Le serveur classifié fédère les clients MIL et l'image marquée. Un garde ou un processus de libération transfère uniquement les pistes diffusables — généralement les positions des forces amies et un ensemble sélectionné de points d'intérêt — vers un serveur non classifié séparé auquel se connectent les clients CIV. Les rapports issus de CIV remontent dans l'image classifiée comme entrées non classifiées. Cela maintient le flux de données sensibles unidirectionnel à la frontière et donne aux accréditors un point de contrôle unique et auditable sur lequel raisonner, plutôt qu'un maillage de clients à différents niveaux de confiance.

Compatibilité des plugins entre les variantes

Les plugins sont la principale raison pour laquelle les équipes déploient ATAK, et leur comportement entre les variantes est donc important. Un plugin est un paquet Android compilé pour une version spécifique du SDK ATAK ; au chargement, l'application hôte vérifie le niveau d'API déclaré par le plugin et sa signature par rapport à ses propres attentes. Étant donné que la surface d'API des plugins est partagée entre les versions CIV et MIL de la même version, un plugin construit pour le SDK CIV se chargera généralement sur la version MIL correspondante — et vice versa — à condition que les versions correspondent.

Des problèmes apparaissent dans deux situations. La première est un décalage de version : un plugin construit pour un SDK plus ancien ou plus récent que l'hôte est rejeté proprement, raison pour laquelle fixer la version du client sur toute une flotte est non négociable. La deuxième est une dépendance de capacité : un plugin qui appelle une fonction présente uniquement dans la version militaire échouera sur CIV, et un plugin qui suppose la signature ou la liste d'autorisation plus laxiste d'une version CIV peut être refusé par une version MIL qui impose une validation de paquet plus stricte. La discipline qui évite les deux est de traiter chaque combinaison variante-version cible comme une cible de build distincte — compiler le plugin pour elle et le tester sur elle, plutôt que de supposer qu'un plugin testé sur CIV est automatiquement prêt pour MIL. Là où la signature et la résistance à la falsification sont une préoccupation, notre guide sur le durcissement de la sécurité des plugins ATAK couvre les protections qui doivent accompagner le plugin quelle que soit la variante qui l'héberge.

Posture de sécurité et accréditation

Il est tentant d'associer « MIL » à « sécurisé » et « CIV » à « non sécurisé », mais la réalité est plus nuancée. Le code de l'application est en grande partie commun ; la différence de sécurité réside dans l'infrastructure qui entoure chaque variante. ATAK-MIL est conçu pour s'intégrer dans des environnements accrédités — il prend en charge des modules cryptographiques approuvés, des marquages de données classifiées et les contrôles de gestion des appareils et d'audit qu'imposent ces environnements. Mais il n'est sécurisé que dans la mesure où le provisionnement, la distribution de clés et le serveur accrédité derrière lui le sont. Installez une version MIL sur un appareil non géré avec une gestion négligente des clés et vous aurez compromis les contrôles mêmes que la version est censée soutenir.

ATAK-CIV, à l'inverse, est tout à fait approprié pour les opérations non classifiées mais sensibles lorsqu'il est accompagné d'une pratique rigoureuse : TLS vers un serveur TAK correctement configuré, appareils durcis, gestion soigneuse des certificats et des clés, et gestion des appareils mobiles appliquée. L'écart entre les deux postures est, en d'autres termes, principalement une question d'infrastructure de support accréditée, et non d'APK installé. Un déploiement CIV bien géré peut être nettement plus sécurisé qu'un déploiement MIL mal géré.

Modèles de déploiement à l'échelle

Quelle que soit la variante choisie, la discipline de déploiement est la même, et elle commence par une image de référence. Une flotte d'appareils Android robustes doit être prouvablement identique : la même variante du client à une version fixée, le même ensemble de plugins validés construits pour ce SDK exact, les mêmes paquets cartographiques hors ligne, les mêmes profils de connexion au serveur et la même posture en matière de certificats. Construisez cette image une fois, signez-la, enregistrez son manifeste et déployez-la sur chaque appareil. Les flottes hétérogènes — assemblées à la main, appareil par appareil — sont le terreau des décalages de version de plugins et des échecs de connexion.

La distribution et le cycle de vie passent ensuite par la gestion des appareils mobiles. Le MDM pousse l'image, fait tourner les certificats, applique la politique de durcissement des appareils et vous permet de désactiver à distance un appareil perdu. Les mécanismes pour faire cela à grande échelle — enrôlement, provisionnement de flotte et gestion continue — font l'objet de notre traitement dédié à la gestion des appareils Android ATAK, et s'appliquent également aux flottes CIV et MIL. La décision de variante change ce que vous mettez dans l'image ; elle ne change pas la nécessité de gérer cette image comme un artefact unique, versionné et auditable sur toute la flotte.

La validation clôt la boucle. Avant qu'un déploiement soit considéré comme « terminé », confirmez de bout en bout que les clients apparaissent sur le serveur, que le CoT circule dans les deux sens, que chaque plugin inclus se charge, et — point critique — que l'image survit à une perte de connectivité et se resynchronise au retour du lien. Un client TAK qui ne fonctionne que lorsqu'il est connecté n'est pas un outil tactique, et ce test est le même que le badge de la version indique CIV ou MIL.