Cursor on Target est le plus petit schéma qui accomplit le plus de travail dans les logiciels tactiques modernes. Un unique document XML — quelques centaines d'octets — transporte une position, une identité, une confiance et une durée de vie, et ce document suffit à placer un marqueur sur chaque carte d'un réseau maillé. Il est né d'un effort du MITRE pour permettre à un opérateur de transmettre une cible d'un système à un autre par un véritable geste du curseur, et il est devenu la lingua franca de l'écosystème TAK. Voici une présentation champ par champ du format Cursor on Target : le modèle event, la taxonomie de types, la géométrie du point, le conteneur detail et les réalités de sa génération et de sa validation correctes.

1. le modèle event de CoT

Chaque message CoT est un unique élément <event>. Il n'y a pas d'enveloppe, pas d'en-tête, pas de registre distinct de types de messages — l'élément racine est le message. C'est le choix de conception délibéré qui rend CoT économique : un seul schéma récursif transporte un soldat ami, un véhicule hostile, une géoclôture, un message de chat, une balise d'urgence et une piste de capteur, sans aucun chemin de code spécifique au type de message sur le réseau.

L'event contient exactement un enfant <point> (où se trouve la chose) et un enfant <detail> optionnel (tout le reste à son sujet). La sémantique d'un event est entièrement déterminée par ses attributs plus le contenu ouvert de <detail>. Un analyseur qui comprend les quatre attributs principaux et le point peut afficher n'importe quel message CoT sur une carte sans comprendre une seule extension detail — cette propriété de dégradation gracieuse est la raison pour laquelle CoT passe à l'échelle entre fournisseurs qui ne se sont jamais coordonnés.

Il vaut la peine de s'attarder sur ce qui n'est pas dans le modèle. Il n'existe aucune distinction au niveau du schéma entre une unité, un marqueur, un message de chat et une piste de capteur — ce sont tous des events, différenciés uniquement par leur type et les enfants detail qu'ils transportent. Il n'y a pas d'accusé de réception, pas de numéro de séquence et pas de session. CoT fonctionne en mode « tire et oublie » ; la fiabilité, l'ordonnancement et la livraison sont repoussés vers le transport (TCP, TLS ou UDP multicast) et l'application au-dessus. Ce minimalisme est la propriété déterminante du schéma : il fait une seule chose — dire où se trouve quelque chose et ce qu'il est, pour une durée bornée — et refuse de développer sa propre pile de protocoles.

2. les attributs de l'event

L'élément <event> porte un ensemble fixe d'attributs. version est la version du schéma, presque toujours 2.0. uid est l'identifiant globalement unique de la chose décrite — pas le message, la chose. Renvoyer une position mise à jour pour la même entité réutilise le même uid ; c'est ainsi qu'un récepteur sait qu'il doit déplacer un marqueur existant plutôt qu'en créer un nouveau. Les UID sont des chaînes libres, mais les clients TAK utilisent par convention un identifiant stable par appareil (par ex. ANDROID-serial) pour les auto-rapports.

type est la chaîne de type MITRE (Section 3). how décrit la provenance des données — comment la position a été dérivée. Les valeurs courantes sont h-g-i-g-o (humain, dérivé du GPS, saisi manuellement) et m-g (machine, GPS). Le champ how est ce qui permet à un moteur de fusion de pondérer différemment un compte rendu de position saisi à la main et un flux GPS en direct.

Le triptyque de cycle de vie est time, start et stale, tous des horodatages ISO 8601 UTC. time est le moment où le message a été produit. start est le moment où l'information devient valide. stale est le moment où elle expire. La fenêtre entre start et stale est la durée de validité de l'event : une fois stale dépassé, un récepteur conforme doit considérer l'event comme expiré et supprimer ou griser le marqueur. Un rapport d'auto-position d'une unité en mouvement pourrait fixer stale à time + 75 secondes ; un point de levé statique pourrait le fixer à plusieurs heures. Bien régler ce triptyque est la source la plus courante de « marqueurs fantômes » — fixez stale trop loin dans le futur et les pistes mortes persistent ; fixez-le trop court et les pistes vivantes clignotent.

Idée clé : CoT n'a pas de message de suppression explicite. On retire une piste en la laissant devenir périmée (stale), ou en envoyant une dernière mise à jour dont l'instant stale est déjà dans le passé. La gestion de l'état dans un réseau CoT est donc un problème de délai d'expiration, et non un problème de transaction — chaque récepteur effectue indépendamment son ramasse-miettes sur sa propre horloge, ce qui explique pourquoi un décalage d'horloge entre nœuds est un danger opérationnel, et non cosmétique.

3. la hiérarchie de types MITRE

L'attribut type encode ce qu'est la chose à l'aide de la taxonomie pointée et tiretée du MITRE. La famille la plus importante est le type atom, préfixé a-. Un type atom se lit comme une séquence de jetons séparés par des tirets : a-f-G-U-C.

Le premier jeton après a est l'affiliation : f ami, h hostile, n neutre, u inconnu, p en attente, plus des variantes supposées/suspectes. Le jeton suivant est la dimension de bataille : G terrestre, A aérien, S surface (mer), U sous-marin, P spatial, F forces spéciales. Les jetons restants descendent dans la hiérarchie de symboles MIL-STD-2525 — a-f-G-U-C est une unité terrestre amie, de combat, et ainsi de suite. Un joker a-f-G-* signifie « une chose terrestre amie, non précisée au-delà », et les moteurs de rendu se rabattent sur le symbole défini le plus proche. Les familles non-atom utilisent des préfixes différents : b- pour les bits (données de capteur/géométrie, par ex. b-m-p-s-p-i pour un point d'intérêt de capteur), t- pour les tâches et y- pour les réponses. Le génie de la taxonomie pointée est qu'elle est décodable par préfixe : un client qui ne connaît que a-f-G peut tout de même placer une icône générique de terrestre ami et se dégrader gracieusement sur la fin qu'il ne reconnaît pas.

4. l'élément point

L'élément <point> est obligatoire et porte cinq attributs, tous requis. lat et lon sont des degrés décimaux WGS-84. hae est la hauteur au-dessus de l'ellipsoïde en mètres — notez « au-dessus de l'ellipsoïde », pas au-dessus du niveau moyen de la mer ; mélanger HAE et hauteur orthométrique (le décalage du géoïde peut dépasser 30 m) est un bug classique d'erreur verticale lorsque CoT rencontre un système qui attend le MSL.

ce est l'erreur circulaire — le rayon d'incertitude horizontale à 1 sigma en mètres. le est l'erreur linéaire — l'incertitude verticale en mètres. Ensemble, ils permettent à un récepteur de tracer un cercle de précision plutôt qu'un point trompeusement précis. La valeur sentinelle 9999999 (souvent écrite 9999999.0) signifie « inconnu » — ce n'est pas une véritable mesure, c'est le null du schéma. Un point déposé manuellement sans précision relevée porte ce="9999999" le="9999999", et la logique de fusion doit traiter cette valeur comme un cas particulier plutôt que comme une erreur de dix mille kilomètres.

Comme chaque attribut est requis, il n'existe pas de point sans hauteur ou sans estimation d'erreur — le schéma force le producteur à faire une affirmation, même si cette affirmation est « inconnu ». C'est une décision de conception discrètement bonne : un récepteur n'a jamais à deviner si un champ manquant signifie zéro, inconnu ou valeur par défaut. Soit il dispose d'un nombre réel, soit il dispose de la sentinelle, et les deux sont sans ambiguïté. Le coût est que les encodeurs paresseux codent en dur hae="0.0" pour tout, ce qui est pire que la sentinelle car cela ressemble à une véritable mesure au niveau de la mer. Si vous ne connaissez pas la hauteur, dites-le avec 9999999 ; n'affirmez pas zéro.

5. l'élément detail

L'élément <detail> est le conteneur d'extension ouvert, et c'est là que vit réellement l'écosystème de CoT. Le schéma ne place aucune contrainte sur ses enfants — tout XML bien formé est légal — ce qui a permis à TAK de superposer un riche protocole applicatif au-dessus d'un format SA générique sans le forker.

Les sous-éléments conventionnels sont largement respectés. <contact> porte un callsign lisible par un humain et, pour TAK, l'adressage d'extrémité pour la messagerie directe. <track> porte course et speed pour les entités en mouvement, transformant un point statique en vecteur. <remarks> est du texte libre. <status> rapporte des choses comme le niveau de batterie. <__group> (double tiret bas) attribue l'unité à une couleur et un rôle d'équipe TAK — Cyan, Team Member — déterminant la couleur de l'icône sur l'écran de chaque coéquipier. <takv> rapporte la version du client TAK, l'appareil et la plateforme. Parce que detail est ouvert, un récepteur ignore simplement les enfants qu'il ne reconnaît pas, ce qui constitue toute la base de l'interopérabilité CoT et TAK entre clients hétérogènes.

6. CoT face à Link 16 et VMF

CoT occupe le même espace conceptuel que la série J et VMF, mais avec des priorités de conception opposées. Les J-messages Link 16 sont des mots à format fixe et à bits compactés, dimensionnés pour un créneau TDMA ; VMF (MIL-STD-6017) est un format variable mais étroitement orienté bits pour les porteurs à faible bande passante. CoT est un XML verbeux conçu pour les réseaux IP où les octets sont bon marché et le temps de développeur ne l'est pas.

La correspondance entre CoT et un J-message est avec perte dans les deux sens. L'affiliation et la dimension de bataille de CoT se mappent proprement sur les champs de piste J3.x et sur les champs d'identité VMF, et lat/lon/hae se traduisent directement. La discordance d'impédance réside dans la précision et la sémantique : une qualité de piste de la série J est une valeur énumérée discrète, là où les ce/le de CoT sont des mètres continus ; le <detail> ouvert de CoT n'a aucun équivalent à format fixe et est abandonné en bloc au niveau d'une passerelle. À l'inverse, des champs de la série J comme des modes IFF spécifiques ou la participation réseau dérivée de la PPLI n'ont pas d'emplacement CoT natif et doivent être glissés dans des extensions detail personnalisées. Les passerelles qui font le pont entre CoT et les liaisons de données tactiques portent donc une carte de champs opiniâtre et maintenue à la main — le même problème du traducteur-avec-des-opinions qui apparaît partout dans le C2 de l'OTAN.

7. le streaming et TAK

En production, CoT est un flux, pas un document. TAK Server multiplexe les events CoT entre clients : le rapport d'auto-position d'une unité remonte par une connexion TCP persistante (souvent TLS) à un rythme configurable — couramment toutes les 1 à 10 secondes selon le mouvement et le réglage « dynamic reporting » — et le serveur le diffuse vers les abonnés, éventuellement filtré par mission, groupe ou géoclôture. Mesh SA, le mode sans serveur, diffuse en multicast les mêmes events sur UDP sur le réseau local de sorte qu'une escouade opère sans aucune infrastructure.

Les débits de messages dictent l'ingénierie. Un exercice à 200 nœuds où chacun rapporte toutes les 2 secondes représente 100 events/seconde rien qu'en auto-position, avant les pistes de capteurs. Le serveur ne maintient aucun protocole de suppression pour tout cela ; à la place, chaque client effectue indépendamment son ramasse-miettes sur les horodatages stale qu'il a vus. Le ramasse-miettes piloté par stale est élégant — pas de leader, pas de consensus — mais cela signifie qu'un client qui perd la connectivité verra toute son image vieillir et disparaître à l'heure prévue, ce qui est généralement le comportement correct et occasionnellement une mauvaise surprise pendant un black-out des communications.

8. valider et générer du CoT

Le format réseau est indulgent, ce qui facilite l'émission de CoT subtilement défectueux. Validez par rapport au schéma Event.xsd publié pendant le développement, mais connaissez ses limites : le XSD vérifie que point existe et que les attributs de cycle de vie sont présents et bien typés, mais il ne peut pas vous dire que votre stale est antérieur à votre start, que votre jeton type est dénué de sens, ou que votre hae est une hauteur géoïdale se faisant passer pour une hauteur ellipsoïdale.

Les bugs récurrents de message mal formé sont prévisibles. Des horodatages sans le Z final ou avec des décalages de fuseau local — l'heure CoT est UTC, point final, et un Z manquant envoie les marqueurs dans le passé ou le futur. Des durées de vie inversées où stale précède start, produisant des events morts à l'arrivée. La réutilisation d'un seul uid pour des entités distinctes, ce qui fait s'effondrer deux pistes réelles en un seul marqueur clignotant. L'émission d'un ce d'apparence réelle au lieu de la sentinelle 9999999 pour un point non relevé, ce qui trompe la fusion en lui faisant croire à des données fausses. Lorsque vous construisez un encodeur CoT, faites du triptyque de cycle de vie un type de première classe qui impose start ≤ stale et restitue l'UTC avec le Z, générez les UID à partir d'une clé d'entité stable plutôt que d'un compteur par message, et émettez explicitement la sentinelle d'inconnu. Réussissez ces quatre invariants et votre CoT interopérera avec des clients que vous n'avez jamais vus — ce qui est tout l'intérêt du format.