Le contrôleur terminal d'attaque interarmées (JTAC) opère à la jonction la plus critique de l'aviation de combat moderne : le point où l'observation terrestre, la capacité de frappe aérienne et les règles d'engagement convergent vers une autorisation de larguer des munitions à quelques centaines de mètres des forces amies. Les procédures qui régissent cette jonction — le briefing CAS en neuf lignes, la chaîne d'autorisation, la confirmation du type de marquage — ont été conçues pour la radio vocale et ont fonctionné, imparfaitement, pendant des décennies. Les outils numériques ne remplacent pas ces procédures ; ils changent le medium par lequel elles s'exécutent, et ce faisant ils s'attaquent aux modes de défaillance spécifiques que la radio vocale ne peut corriger.
Cet article examine ce que ces outils numériques produisent en pratique : comment fonctionne la génération automatisée des 9 lignes, comment les coordonnées de cible parviennent aux équipages sans cycle de lecture vocale, comment la déconfliction de l'espace aérien est appliquée sans recoupement manuel, comment la vidéo ROVER s'intègre à la représentation terrestre, comment le logiciel de coordination des feux déconflicte le CAS avec le soutien indirect par AFATDS, et ce qui arrive au flux de travail numérique lorsque le réseau tombe. L'architecture décrite ici s'applique aussi bien aux JTAC qui contrôlent des aéronefs d'attaque à voilure fixe qu'aux observateurs de feux interarmées (JFO) qui demandent des feux indirects — le modèle de données sous-jacent et la logique de déconfliction sont les mêmes.
Le flux de travail JTAC de l'acquisition de cible à l'engagement
Une sortie CAS passe par une séquence prévisible de phases quelle que soit la plateforme ou le type de cible. Pour comprendre où les outils numériques interviennent — et où ils n'interviennent pas — il faut cartographier précisément ce flux de travail.
La sortie commence par l'acquisition de cible : le JTAC observe une cible par optique directe, reçoit un transfert numérique depuis une plateforme capteur, ou identifie une cible sur le flux vidéo ROVER. Dans un flux de travail natif numérique, cette observation est immédiatement enregistrée comme marqueur COP provisoire — coordonnée MGRS, type de cible à partir d'une taxonomie structurée, heure d'acquisition et niveau de confiance. Le marqueur COP est la fiche d'origine de tout ce qui suit.
Le JTAC construit ensuite le briefing en 9 lignes. Dans un flux vocal, c'est un exercice mental exécuté à partir d'un format mémorisé. Dans un flux numérique, le formulaire à 9 lignes s'ouvre pré-renseigné avec les données du marqueur COP : localisation de la cible, distance et cap calculés depuis le point initial désigné, et altitude de la cible à partir de la base de données de terrain. Le JTAC passe en revue et complète les champs restants — type de marquage, description de la cible, forces amies — et soumet la demande via la chaîne d'approbation.
La chaîne d'approbation — JTAC vers le contrôleur aérien avancé (AFAC) vers l'autorité habilitante en CAS délibéré, ou JTAC directement vers l'AFAC en CAS temps-critique — s'appuie sur des données cartographiques partagées dans un flux numérique. L'autorité d'approbation voit la même géométrie de kill box que celle assemblée par le JTAC, et non une chaîne de coordonnées qu'elle doit projeter mentalement sur une carte. L'approbation est une action délibérée liée à un affichage spatial visible, et non un accusé vocal qui peut ou non refléter une compréhension complète de la géométrie de la cible.
À l'approbation, la coordonnée de cible est transmise au système de navigation de l'aéronef via liaison de données lorsque la capacité existe, et le JTAC marque la cible avec le type de marquage désigné — laser, pointeur IR ou coordonnée GPS. L'aéronef attaque. Le JTAC observe par vidéo ROVER si disponible, et enregistre l'évaluation des dommages de combat (BDA) dans la fiche de sortie. Si une nouvelle attaque est requise, la saisie BDA génère un nouveau formulaire en 9 lignes pré-renseigné depuis la localisation de cible mise à jour.
Les outils numériques interviennent dans cinq de ces phases : journalisation de l'acquisition, génération des 9 lignes, visualisation de l'approbation, transfert de coordonnées et enregistrement BDA. La phase d'exécution de l'attaque — l'acte physique de marquage et d'observation — reste entièrement entre les mains du JTAC. Cette frontière est intentionnelle : le appui aérien rapproché numérique augmente le jugement humain dans les phases de traitement de l'information ; il n'automatise pas la décision de contrôle terminal.
Logiciel de demande CAS en 9 lignes
Le formulaire de demande CAS en 9 lignes est le document le plus sensible aux défaillances dans l'appui aérien rapproché. Une seule erreur de champ — un chiffre MGRS transposé en ligne 6, un cap incorrect en ligne 2, une distance des forces amies sous-estimée en ligne 8 — peut placer des munitions sur la mauvaise cible ou sur des troupes amies. Le logiciel 9 lignes numérique traite ce risque en remplaçant la transmission radio en texte libre par un schéma structuré qui applique des types, valide la cohérence et fournit une confirmation visuelle pour chaque champ déterminant.
Renseignement automatique des coordonnées. Lorsque le JTAC ouvre le formulaire à 9 lignes avec un marqueur COP actif, la ligne 6 (localisation de la cible) se remplit automatiquement depuis les coordonnées du marqueur en MGRS et en décimal lat-lon. Le système convertit automatiquement entre les formats et stocke les deux représentations avec un étiquetage explicite du datum (WGS84). Une invite de confirmation visuelle affiche la coordonnée sous forme de point sur la carte et demande au JTAC de confirmer : « Est-ce le bon emplacement de cible ? » L'étape de confirmation est obligatoire — le champ ne peut être accepté sans elle — et la confirmation est enregistrée avec l'identité de l'opérateur JTAC et un horodatage.
Calcul de la distance et du cap. Les lignes 2 et 3 (cap d'attaque et distance du point initial à la cible) sont calculées automatiquement depuis les champs IP et localisation de la cible lorsque les deux sont renseignés depuis le COP. Les valeurs calculées sont affichées à côté des champs du formulaire sous forme de diagramme spatial — l'IP, la flèche d'axe d'attaque et le point cible sont représentés sur un encart de mini-carte dans le formulaire — afin que le JTAC puisse vérifier que la géométrie correspond à sa compréhension de la géométrie d'attaque avant de soumettre. Le remplacement manuel est autorisé mais journalisé comme déviation par rapport à la valeur calculée.
Altitude de la cible depuis la base de données de terrain. La ligne 4 (altitude de la cible en pieds MSL) se remplit automatiquement depuis la base de données de terrain pour la coordonnée cible. La source et l'âge des données de terrain sont affichés à côté du champ — un jeu de données DTED Niveau 1 de 2019 exige plus de prudence qu'un MNT récent issu de relevés. Le JTAC accepte ou remplace la valeur de la base de données ; un remplacement nécessite la saisie de la base d'évaluation du JTAC (observation directe des caractéristiques du terrain, imagerie récente, etc.).
Description structurée de la cible. La ligne 5 utilise une taxonomie hiérarchique plutôt que du texte libre : catégorie principale (véhicule, personnel, structure, équipement, infrastructure), classification secondaire au sein de cette catégorie, et un champ de remarques libre pour les détails ne s'intégrant pas dans la taxonomie. La classification structurée permet des vérifications automatisées des ROE au moment de la soumission — le système peut signaler si le type de cible relève des catégories pré-autorisées ou nécessite un routage d'approbation supplémentaire.
Validation croisée des forces amies. La ligne 8 (position des forces amies par rapport à la cible) est le champ à risque de fratricide le plus élevé dans les 9 lignes. Le JTAC saisit un cap et une distance — « 300 mètres au sud » — et le système valide cette entrée par rapport aux positions réelles des pistes amies du COP. Si la piste amie la plus proche dans le COP se trouve à 150 mètres au sud plutôt qu'à 300 mètres, la divergence génère un avertissement. Le JTAC doit reconnaître explicitement la divergence et confirmer quelle valeur est correcte. Cette validation croisée ne bloque pas la soumission — le JTAC dispose d'informations de terrain que le COP peut ne pas refléter — mais elle met en évidence la divergence plutôt que d'accepter silencieusement un champ potentiellement incorrect.
Vérification des erreurs de conversion de coordonnées. Toute saisie de coordonnées — qu'il s'agisse de MGRS, lat-lon ou UTM — est analysée selon les règles de validité du système de coordonnées et vérifiée par rapport à la boîte englobante de la zone opérationnelle. Une référence de grille qui tombe hors du théâtre d'opérations, ou qui échoue à la validation de somme de contrôle, génère une erreur bloquante avant que le JTAC ne puisse soumettre. Cela détecte la catégorie la plus courante d'erreur de transcription : un chiffre techniquement valide comme coordonnée mais qui place la cible dans le mauvais carré MGRS de 100 km.
Transfert de coordonnées de cible et intégration du marquage laser/RFID
Le transfert de coordonnées de cible du JTAC vers l'équipage est l'étape où un flux vocal introduit le dernier risque de transcription et le plus déterminant : le pilote saisit manuellement une grille dans son système de navigation à partir d'une lecture vocale. Le transfert numérique élimine entièrement cette étape pour les plateformes dotées de liaisons de données compatibles.
Transfert de point de guidage via liaison de données. À l'approbation des 9 lignes, le système transmet la coordonnée de cible à l'ordinateur de mission de l'aéronef sous forme de point de guidage via la liaison de données appropriée à la plateforme : Link 16 pour les aéronefs rapides de coalition équipés d'avionique JTIDS, SADL (Situational Awareness Datalink) pour les A-10 Warthog et certaines plateformes à voilure tournante, ou des formes d'onde spécifiques à la plateforme pour l'aviation des forces spéciales. Le point de guidage transmis est désigné avec l'identifiant de sortie afin que le JTAC et le pilote puissent confirmer qu'ils font référence au même enregistrement de cible. Un message de confirmation de l'aéronef — « point de guidage reçu, grille confirmée » — clôture la boucle de transfert dans l'enregistrement numérique.
Lorsque la transmission directe par liaison de données n'est pas disponible — aéronefs anciens, plateformes multi-coalitions sans formes d'onde interopérables — le système génère un fichier de chargement de point de guidage formaté compatible avec le système de planification de mission de l'aéronef, ou un briefing vocal structuré formaté pour minimiser les erreurs de lecture. Dans tous les cas, la coordonnée de cible dans l'enregistrement des 9 lignes approuvées est la source de référence, et toute déviation entre cet enregistrement et le point de guidage chargé est signalée si la liaison de données du pilote prend en charge la confirmation inverse.
Intégration du code laser SOFLAM et IZLID. Lorsque le type de marquage en ligne 7 est laser, le code laser — le code PRF à quatre chiffres que le tracker de spot laser de l'aéronef utilise pour discriminer le désignateur correct parmi tous les lasers sur le champ de bataille — doit parvenir à l'aéronef sans erreur de transmission vocale. Les outils numériques gèrent cela en stockant le code laser dans le profil d'équipement du JTAC, en le renseignant automatiquement dans le champ ligne 7 des 9 lignes, et en l'incluant dans la transmission par liaison de données vers l'aéronef. Si l'intégration SOFLAM ou IZLID est disponible via une interface numérique (certaines variantes prennent en charge la configuration USB ou série), le système peut interroger le réglage de code actuel du désignateur et confirmer automatiquement que le code dans les 9 lignes correspond au code programmé sur le matériel.
Affichage de la boîte de cible et du point de guidage sur ROVER. Lorsque le terminal ROVER du JTAC dispose d'une capacité de superposition cursor-on-target — une fonctionnalité logicielle disponible sur ROVER 6 et les générations ultérieures — le marqueur COP de cible approuvé est géoréférencé sur le flux vidéo ROVER. L'emplacement de la cible apparaît sous forme de réticule en superposition sur l'image vidéo, permettant au JTAC de vérifier visuellement que le capteur de l'aéronef est pointé sur le bon point de visée avant l'autorisation. Si le réticule et le point de visée apparent de l'aéronef divergent, le JTAC dispose d'un indicateur visuel direct d'une erreur de ciblage avant le largage.
Déconfliction de l'espace aérien pour le CAS
La déconfliction de l'espace aérien pour le CAS n'est pas un contrôle unique — c'est un processus continu qui s'étend de la définition de la kill box jusqu'à la libération de l'espace aérien après la frappe. Le logiciel de déconfliction de l'espace aérien automatise les éléments les plus chronophages de ce processus : recoupement de la kill box avec les mesures de contrôle de l'espace aérien actives, calcul des blocs d'altitude et séquençage des utilisateurs en conflit par séparation temporelle.
Définition latérale et verticale de la kill box. La kill box est définie par un point central (l'emplacement de la cible en ligne 6), un rayon latéral (déterminé par le type d'armement, l'estimation des dommages collatéraux et le terrain) et un bloc d'altitude (altitude minimale et maximale pour la passe d'attaque). Ces trois paramètres définissent ensemble le volume tridimensionnel qui doit être déconflicté vis-à-vis de tous les autres utilisateurs de l'espace aérien avant que le JTAC ne puisse procéder à l'approbation.
Coordination des ACM. Les mesures de contrôle de l'espace aérien — zones d'exploitation restreintes, routes à risque minimal, zones interdites de survol, zones d'engagement commun et zones de tir libre — sont maintenues dans la couche de gestion de l'espace aérien et mises à jour depuis les flux de l'ordre de mission aérienne et de l'ordre de contrôle de l'espace aérien. Le module de déconfliction superpose la kill box proposée à toutes les ACM actives au moment de la soumission. Tout chevauchement génère un rapport de conflit spécifique : quelle ACM est violée, quelle est l'autorité de contrôle, quelle est la fenêtre de validité temporelle, et si une demande de coordination peut être acheminée numériquement vers cette autorité. Pour les zones temporairement restreintes et les blocages ATC, la demande de coordination est automatisée — le système envoie une demande à l'interface numérique de l'autorité de contrôle et attend l'approbation ou l'attribution d'une fenêtre alternative.
Gestion du bloc d'altitude. Le bloc d'altitude de la kill box doit être coordonné non seulement vis-à-vis des ACM statiques mais aussi de tous les utilisateurs dynamiques de l'espace aérien : autres sorties CAS dans la même zone, trajectoires d'artillerie (déconflictées via la couche des feux), plateformes ISR en attente à altitude moyenne, et toute couverture radar de défense aérienne nécessitant une notification avant que des aéronefs n'entrent dans un volume défini. Le module de déconfliction maintient une image en temps réel des allocations de blocs d'altitude et attribue à la sortie CAS demandeuse une fenêtre d'altitude sans conflit avec les réservations existantes. Si le bloc d'altitude demandé par le JTAC ne peut être satisfait sans conflit, le module propose la prochaine fenêtre disponible et affiche le temps d'attente.
Déconfliction temporelle. Lorsque deux sorties CAS nécessitent des volumes d'espace aérien se chevauchant mais pas simultanément, la déconfliction temporelle attribue des fenêtres d'exécution plutôt qu'une séparation latérale ou verticale. La première sortie se voit allouer une fenêtre de T+0 à T+8 minutes ; la deuxième attend et prend T+10 à T+18 minutes. Le JTAC voit sa fenêtre attribuée sur l'interface d'approbation et planifie l'exécution de l'attaque en conséquence. Une sortie qui dépasse sa fenêtre génère une alerte tant pour le JTAC que pour le gestionnaire de l'espace aérien, car le dépassement crée un conflit avec la sortie suivante allouée.
Intégration ROVER/TRAC pour le CAS
ROVER (Remotely Operated Video Enhanced Receiver) donne au JTAC ce qu'aucun autre outil ne fournit : la même image visuelle que l'opérateur du capteur de l'aéronef utilise pour identifier et engager la cible. Dans un flux uniquement vocal, le JTAC et le pilote regardent une coordonnée partagée mais pas une image partagée — le JTAC regarde le terrain à travers des jumelles, le pilote à travers une nacelle de ciblage, et les deux images peuvent ne pas s'accorder sur quelle caractéristique est la cible visée. ROVER comble cet écart.
Superposition cursor-on-target. L'intégration numérique entre ROVER et le logiciel C2 CAS ajoute la superposition cursor-on-target au flux vidéo : le marqueur COP de cible approuvé est géoréférencé sur l'image vidéo ROVER en utilisant les métadonnées du capteur de l'aéronef (distance oblique, angle du cardan, position et altitude de l'aéronef). L'emplacement de la cible apparaît sous forme de symbole de réticule sur la vidéo. Si le réticule se trouve sur un bâtiment différent de celui visé par le capteur du pilote, le JTAC peut détecter la divergence avant l'autorisation et initier un guidage vocal pour corriger la visée de l'aéronef.
Affichage du tracker de spot laser. Les variantes ROVER qui incluent la capacité de tracker de spot laser (LST) détectent le spot laser du JTAC sur l'image vidéo et affichent son emplacement sous forme de second symbole sur la superposition cursor-on-target. Le JTAC peut voir, en temps réel, si le spot laser est sur le repère de cible désigné par le réticule ou s'en écarte — un problème courant lorsque le terrain occulte la ligne de visée entre le JTAC et la cible. Si le laser n'est pas sur la cible, le JTAC ajuste la désignation sans nécessiter un échange vocal avec le pilote.
ROVER défini par logiciel (intégration TRAC). TRAC (Tactical Remote Viewing System) et les implémentations ultérieures de récepteurs vidéo définis par logiciel permettent de diffuser le flux du capteur de l'aéronef vers n'importe quel dispositif en réseau — une tablette durcie, un ordinateur portable, un smartphone en cas d'urgence — sans nécessiter un terminal matériel ROVER dédié. Le logiciel C2 CAS reçoit le flux vidéo via RTSP standard ou transport conforme STANAG 4609 MISB et le restitue dans la même interface que le formulaire à 9 lignes et l'affichage COP. Un seul écran montre simultanément au JTAC le statut des 9 lignes, la kill box COP et le flux vidéo de l'aéronef — éliminant les basculements de regard entre un terminal ROVER, une carte et une radio qui caractérisaient la coordination CAS des générations précédentes.
Synchronisation des feux avec AFATDS et le FDC
L'appui aérien rapproché opère rarement de manière isolée par rapport aux feux indirects. Les actifs d'artillerie et de mortier peuvent supprimer des positions ennemies adjacentes, fournir des feux SEAD avant l'entrée de l'aéronef CAS, ou couvrir l'itinéraire de repli du JTAC après la frappe. Déconflicter ces feux simultanés — veiller à ce qu'un projectile d'artillerie n'entre pas dans le bloc d'altitude CAS pendant qu'un aéronef est en finale — nécessite une connexion numérique entre l'outil de coordination CAS du JTAC et le système de commandement et contrôle des feux.
Demande de feux numériques depuis le COP. Lorsqu'un JTAC ou JFO demande un soutien par feux indirects depuis le même enregistrement de cible utilisé pour le CAS, le message CFF numérique est généré depuis le marqueur COP existant — même coordonnée MGRS, même taxonomie de description de cible, même identifiant de sortie pour la référence croisée. Le CFF est acheminé vers le centre de direction des feux (FDC) via AFATDS, avec les informations d'identification de l'observateur de feux et la méthode d'observation (observateur terrestre, UAV, aéronef) en annexe. Si la même cible reçoit à la fois une demande CAS et une demande CFF, les deux sont liées dans la couche de coordination des feux par l'identifiant de sortie partagé, créant un enregistrement unifié de synchronisation des feux.
Déconfliction entre CAS et feux indirects. AFATDS maintient une file des missions de feu actives et planifiées avec leurs trajectoires, fenêtres de temps sur objectif et enveloppes d'altitude. Le module de déconfliction CAS interroge cette file avant d'approuver un bloc d'altitude CAS. Si la trajectoire d'une mission de feu active entre dans le bloc d'altitude CAS sur la zone cible pendant la fenêtre d'attaque planifiée, le module de déconfliction génère une demande de blocage au FDC : « Interrompre la mission [ID] — conflit de bloc d'altitude CAS de T+3 à T+9. » Le FDC ajuste le timing et libère le bloc d'altitude CAS. Le blocage et la libération sont enregistrés avec horodatage dans l'enregistrement de synchronisation des feux.
Coordination SEAD. La suppression des défenses aériennes ennemies avant une passe d'attaque CAS nécessite de séquencer les feux SEAD pour qu'ils arrivent avant que l'aéronef CAS n'entre dans l'enveloppe défendue et pour qu'ils se dégagent avant que l'aéronef ne sorte — pas avant qu'il n'entre. Les outils numériques maintiennent un enregistrement de timing SEAD lié à la sortie CAS : l'emplacement et le type du système de défense aérienne adverse, la mission de feu SEAD assignée pour le supprimer, et la fenêtre pendant laquelle la suppression est confirmée active. Le flux d'approbation CAS vérifie que les missions de feu SEAD sont confirmées dans la file AFATDS avant d'autoriser l'aéronef CAS pour l'entrée. Une mission de feu SEAD retardée ou refusée génère un blocage dans la chaîne d'approbation CAS, avec le JTAC informé spécifiquement de quelle mission SEAD bloque l'autorisation.
L'architecture de synchronisation des feux gère également le cas inverse : les missions de feu indirect qui doivent déconflicté avec des blocs d'altitude CAS actifs déjà réservés dans la couche de gestion de l'espace aérien. L'intégration AFATDS avec le flux de gestion de l'espace aérien permet au FDC de voir les blocs d'altitude CAS actifs avant d'accepter une nouvelle mission de feu, et d'acheminer les nouvelles missions par des trajectoires qui évitent les blocs d'altitude occupés plutôt que de compter sur le JTAC pour détecter et appeler un cessez-le-feu.
Enseignements tirés de l'adoption du CAS numérique
Les outils CAS numériques ont été déployés dans des environnements opérationnels assez longtemps pour révéler des schémas de défaillance cohérents qui informent à la fois l'architecture et la formation. Ces enseignements ne sont pas hypothétiques — ils reflètent des observations récurrentes issues de comptes-rendus post-mission d'opérations CAS où les outils numériques faisaient partie de la chaîne de mort.
Contraintes de connectivité dans les environnements contestés. Les environnements électromagnétiques qui dégradent les communications dégradent également les liaisons de données dont dépendent les outils CAS numériques. La vidéo ROVER est la composante la plus gourmande en bande passante et la première à tomber ; la superposition cursor-on-target devient indisponible sans le flux vidéo. La synchronisation COP TAK nécessite un canal plus étroit et se dégrade plus gracieusement — l'image COP se fige plutôt que de disparaître, affichant les dernières positions connues des pistes amies. La soumission et l'approbation du formulaire à 9 lignes peuvent fonctionner sur des canaux MANET très étroits et des réseaux maillés store-and-forward. La messagerie CFF AFATDS utilise généralement une liaison de données radio tactique résiliente. Les outils doivent être conçus et les JTAC doivent être formés pour comprendre exactement quelles capacités se dégradent à quels seuils de bande passante, et pour passer aux procédures en mode dégradé appropriées sans attendre une panne complète du lien.
Complaisance liée à l'automatisation. Les champs pré-renseignés — localisation de la cible depuis le COP, distance depuis la géométrie, altitude depuis la base de données de terrain — réduisent la charge cognitive pendant le ciblage à tempo élevé mais créent un nouveau mode de défaillance : le JTAC accepte une valeur pré-renseignée sans la vérifier. Dans les comptes-rendus post-mission, des instances de localisation de cible incorrecte ont été attribuées à des erreurs de placement de marqueur COP que le JTAC n'a pas détectées parce que la coordonnée pré-renseignée « semblait correcte » sans vérification délibérée. La conception de l'interface doit rendre les champs pré-renseignés visuellement distincts des champs saisis manuellement, exiger une action de confirmation explicite pour chaque champ à enjeux élevés, et afficher la source de données du champ afin que le JTAC sache ce qu'il confirme.
Confusion de mode dans les flux d'approbation. Le CAS délibéré et le CAS temps-critique nécessitent des flux d'approbation fondamentalement différents, et les JTAC sous pression temporelle tentent systématiquement d'acheminer les demandes temps-critiques via des files CAS délibéré lorsque l'interface ne rend pas la distinction évidente. Le basculement de mode de CAS délibéré à temps-critique doit être un état d'interface persistant et visible — pas une option de menu ou une case à cocher dans un formulaire — car un JTAC qui gère simultanément des communications radio, observe la cible et se coordonne avec l'aéronef ne dispose pas de la bande passante cognitive pour remarquer une différence subtile d'état de l'interface. Si le mode est incorrect, la sortie prend trois minutes de plus que la fenêtre d'engagement ne le permet.
Les procédures en mode dégradé comme compétences primaires. Les JTAC qui s'entraînent exclusivement sur des outils numériques et traitent les 9 lignes vocaux comme une compétence de secours qu'ils « se rappelleront si nécessaire » affichent systématiquement de mauvaises performances lorsque les liaisons numériques tombent dans les exercices d'entraînement — et l'écart de performance est pire sous stress opérationnel qu'à l'entraînement. Les outils CAS numériques doivent être introduits comme un accélérateur pour un JTAC maîtrisant la voix, et non comme un substitut à la compétence vocale. Les programmes de formation qui utilisent les outils numériques dès le premier jour de la qualification CAS forment des JTAC qui maîtrisent les outils mais ne peuvent pas performer efficacement lorsque les outils sont indisponibles. La discipline de traiter l'opération en mode dégradé comme une compétence primaire — et non comme une mesure de contingence — est le principal enseignement en matière de facteurs humains tiré de l'adoption du CAS numérique.