La radio vocale est la colonne vertébrale de la coordination CAS depuis la Seconde Guerre mondiale. Un contrôleur terminal d'attaque interarmées (JTAC) lit un briefing à neuf lignes en HF ou VHF au pilote, le pilote le répète, et si les neuf champs ont survécu aux parasites et à l'alphabet phonétique sans erreur de transcription, l'attaque est exécutée. La simplicité procédurale est trompeuse : le taux d'erreur dans les conditions opérationnelles réelles est nettement supérieur à celui observé à l'entraînement, la relecture coûte des minutes, et il n'y a aucune confirmation visuelle que le pilote et le JTAC voient le même point sur le terrain.
Le logiciel de coordination CAS numérique résout ces trois problèmes simultanément. Un formulaire structuré remplace la transmission radio en texte libre, la localisation de l'objectif est liée à un marqueur sur l'image opérationnelle commune (COP) en temps réel, et la chaîne d'approbation — du JTAC à l'AFAC jusqu'à l'autorité habilitée — laisse une piste d'audit immuable de la demande initiale à l'évaluation des dommages après l'impact.
Le cas échéant, l'article fait référence à la façon dont TAKpilot résout ces problèmes dans un flux de travail CAS natif TAK.
Le problème du flux de travail JTAC : pourquoi le message 9 lignes vocal échoue sous pression
Le champ de localisation de l'objectif — le champ le plus critique du briefing — est une chaîne de coordonnées, généralement au format MGRS. Prononcée sur un canal radio dégradé à tempo élevé, une référence de grille à six chiffres peut être mal entendue. Le logiciel CAS numérique élimine la relecture phonétique des coordonnées, remplit automatiquement la localisation de l'objectif à partir d'un marqueur COP et affiche la zone d'engagement sur une carte commune visible simultanément par le JTAC et l'autorité approbatrice.
Structure numérique du message 9 lignes : du texte libre au schéma typé
Chacun des neuf champs correspond à un type structuré avec des règles de validation appliquées lors de la saisie.
Ligne 1 — PI/Décalage. Le point initial est stocké comme UID d'objet COP ou comme coordonnée avec étiquette. Le décalage est un relèvement en degrés magnétiques et une distance en mètres.
Ligne 2 — Cap. Relèvement entier en degrés magnétiques. Le système affiche l'axe d'attaque comme une flèche sur la superposition de la zone d'engagement.
Ligne 3 — Distance. Distance entière en mètres du PI à l'objectif. Calculée automatiquement lorsque les deux champs sont remplis depuis le COP.
Ligne 4 — Altitude de l'objectif. Altitude entière en pieds MSL. Remplie automatiquement depuis la base de données de terrain.
Ligne 5 — Description de l'objectif. Type structuré : catégorie principale avec sous-classification et champ de remarques en texte libre.
Ligne 6 — Localisation de l'objectif. Le champ le plus critique. Stocké en MGRS et en degrés décimaux. Lors de la saisie des coordonnées, le système affiche le point sur la carte et invite le JTAC à confirmer visuellement.
Ligne 7 — Type de marquage. Énumération : laser (avec code), pointeur infrarouge, fumée (avec couleur), GPS, grille, aucun.
Ligne 8 — Forces amies. Position déclarée des forces amies les plus proches par rapport à l'objectif. Validée croisément avec les positions réelles des pistes dans le COP.
Ligne 9 — Dégagement. Direction de dégagement prévue de l'aéronef après la passe d'attaque.
Intégration COP : relier le message 9 lignes à la carte en temps réel
Lorsqu'un JTAC soumet une demande, le logiciel de coordination crée un ensemble d'objets COP : marqueur de localisation de l'objectif, superposition de la zone d'engagement, flèche d'axe d'attaque et segment de ligne PI-objectif. Toutes les superpositions sont transmises au serveur TAK et apparaissent sur tous les clients ATAK ou WinTAK connectés. L'AFAC et l'autorité approbatrice voient la même géométrie que le JTAC.
Flux d'approbation : de la demande JTAC à la revue AFAC jusqu'à l'autorisation SMEAC
Le CAS planifié suit la chaîne SMEAC complète. Le CAS urgent réduit la chaîne à une seule autorisation AFAC. Le logiciel numérique doit implémenter les deux flux de travail avec des mises en page de formulaires différentes, un routage d'approbation différent et des comportements de délai d'attente différents.
Déconfliction : espace aérien, prévention des tirs fratricides et conformité ROE
Avant l'approbation, le bloc d'altitude de la zone d'engagement est vérifié par rapport aux réservations d'espace aérien actives. Une vérification automatique de toutes les pistes amies dans le COP est effectuée au moment de l'approbation. Les classifications structurées des objectifs permettent des vérifications ROE automatisées.
Intégration TAKpilot : de la demande en langage naturel au message 9 lignes structuré
TAKpilot accepte une demande CAS en langage naturel — « engager le véhicule à la grille 37T EL 441528, laser 1688, forces amies à 300 m au sud » — et génère automatiquement un projet de message 9 lignes pré-rempli. Après confirmation, TAKpilot soumet le message 9 lignes au flux d'approbation et transmet simultanément le marqueur de localisation de l'objectif et la superposition de la zone d'engagement vers CloudTAK via l'API REST du serveur TAK.
Évaluation des dommages après impact : documenter la situation post-frappe
Le formulaire de saisie d'évaluation des dommages de combat (BDA) s'active automatiquement lorsque le statut de la sortie passe à « attaque terminée ». Le JTAC saisit : l'heure d'impact (UTC), le type et la quantité d'armement, l'effet observé, la localisation du cratère en MGRS, l'évaluation PT/PT et l'évaluation préliminaire des dommages collatéraux.
Après l'opération : journal des sorties, archive des messages 9 lignes et reconstruction de la chronologie
Le journal des sorties fournit une vue chronologique de toute l'activité CAS. La reconstruction de la chronologie pour le compte rendu utilise les transitions d'état horodatées pour générer une chronologie d'événements pouvant être superposée à l'archive de pistes COP. Le public du compte rendu peut parcourir la sortie seconde par seconde.