ADatP-3 (STANAG 5500) : les formats de messages texte de l'OTAN expliqués

ADatP-3 — Allied Data Publication 3, promulgué par le STANAG 5500 — est le système OTAN de formatage des messages texte, connu sous le nom de FORMETS : les règles, constructions et vocabulaire utilisés pour bâtir chaque message formaté de l'OTAN, du rapport de situation à l'ordre de mission aérienne. Les quelque 400 messages construits selon ces règles sont catalogués dans l'APP-11 — 407 Message Text Formats dans l'édition actuelle — et depuis 2008, chacun d'eux existe aussi en XML-MTF.

Qu'est-ce qu'ADatP-3 (STANAG 5500) ?

Officiellement, la publication s'intitule NATO Message Text Formatting System (FORMETS) — Concept of FORMETS (CONFORMETS). Vous la verrez écrite ADatP-3 ou ADatP-03 ; les deux désignent la même Allied Data Publication. La version actuelle est l'Edition A Version 4, promulguée le 1er juillet 2021 sous l'accord de couverture STANAG 5500 Edition 8. Elle est maintenue par l'équipe de capacités OTAN des formats de messages texte (MTF CaT), et ses éditions promulguées figurent dans la base publique du Bureau de normalisation de l'OTAN.

Ce que la norme spécifie se cite le mieux depuis le résumé de l'OTAN lui-même : FORMETS fournit « la syntaxe et les règles régissant la représentation des définitions conceptuelles convenues (champs) et l'arrangement de ces champs en phrases (ensembles) et en textes de message », et il est destiné à tous les messages formatés orientés caractères du commandement et contrôle OTAN. Autrement dit, ADatP-3 est la grammaire de la messagerie formatée OTAN. Il ne définit pas les messages individuels — c'est le rôle du catalogue APP-11 décrit plus bas.

L'objectif de conception explique sa longévité. Un message formaté doit être lisible par un opérateur sur un terminal brut, analysable par un logiciel sur un serveur moderne et assez compact pour une liaison tactique contrainte. Le texte orienté caractères, délimité par des barres obliques, satisfait les trois exigences — c'est pourquoi le trafic ADatP-3 circule encore en 2026 à côté de tout le reste de la pile des normes d'interopérabilité OTAN.

ADatP-3, APP-11, ADatP-34, APP-6 : quelle norme correspond à quoi

Ces quatre publications sont constamment confondues — y compris dans le marketing des fournisseurs — voici donc la correspondance correcte, vérifiée contre les registres publics de normalisation de l'OTAN :

La relation entre les deux premières est précise. Selon la description du NISP par l'OTAN elle-même, la base de données ADatP-03 contient tous les formats de messages texte sous le contrôle de configuration du groupe de travail des formats de message, et « les MTF convenus, une fois publiés dans une ligne de base, seront régulièrement insérés dans le STANAG 7149, Catalogue de messages de l'OTAN — APP-11 ». ADatP-3 est la grammaire ; APP-11 est le dictionnaire des messages écrits dans cette grammaire. ADatP-34 se situe un niveau au-dessus : le NISP indique aux programmes et aux spirales Federated Mission Networking (FMN) quelles normes utiliser — dont ADatP-3 et APP-11 — et ne définit aucun message lui-même. Le rôle du NISP dans le choix des profils est traité dans notre article sur les structures de données ADatP-34, et le volet symbologie dans APP-6 contre MIL-STD-2525.

Structure d'un message formaté : ensembles, champs, séparateurs

Chaque message MTF est une suite d'ensembles ; chaque ensemble est un identifiant d'ensemble suivi de champs. Trois conventions portent presque toute la syntaxe :

• Un ensemble commence par son identifiant — un mnémonique tel que MSGID, REF ou NARR — suivi d'une barre oblique.
• Les champs sont séparés par une barre oblique unique /. Un champ est une entrée codée à format fixe (un groupe date-heure comme 011800Z, une position comme 4040N01100E) ou une entrée codée étiquetée telle que LM:4040N01100E.
• Un ensemble se termine par une double barre oblique //. Les ensembles longs se poursuivent sur les lignes suivantes sans répéter l'identifiant.

L'exemple ci-dessous — un rapport tactique dans le style publié dans la documentation USMTF ouverte, simplifié pour la clarté et qui n'est pas un message opérationnel — montre les trois :

MSGID/TACREP/CTF 124//
MAROP/011800Z/1/US/SUB/CL:WASHINGTON/NAME:SEAROVER/
LM:4040N01100E//
OPSUP/ACTTYP:ASW//
AIROP/020200Z/6/US/FTR/F15/TN:401/LM:4130N01000E/
CRS:180/SPD:600KPH/ALT:12000FT//

Certains ensembles génériques reviennent dans le trafic opérationnel et administratif : MSGID (identification du message — type, expéditeur, numéro de série), EXER et OPER (identification de l'exercice et de l'opération), REF avec son compagnon NARR (références et leur développement narratif), SUBJ, POC, et GENTEXT, qui porte du texte général sous un spécificateur de contenu (GENTEXT/REMARKS/…//). La composition exacte en ensembles de chaque message — quels ensembles, dans quel ordre, combien de fois — est définie pour chaque message dans l'APP-11.

Chaque ensemble d'une entrée du catalogue porte une information d'occurrence (obligatoire, ou conditionnée à un autre contenu) et une répétabilité (combien de fois il peut apparaître — un message citant trois références porte trois ensembles REF). Les champs ont des formats prescrits et, pour les champs codés, des tables de valeurs définies. Physiquement, les ensembles sont disposés de façon linéaire (les champs suivent l'identifiant, comme dans l'exemple) ou en lignes en colonnes — les lignes de tâches de l'ordre de mission aérienne en sont l'exemple classique : une ligne alignée délimitée par des barres obliques par mission ou sortie. Le tout est du texte en majuscules, orienté caractères, dans un jeu de caractères imprimables restreint — c'est ce qui lui permet de survivre à tout terminal et tout support.

Lignes de base et éditions : quel catalogue vise votre analyseur

« Sur quel ADatP-3 êtes-vous ? » est la première question d'interopérabilité. Le catalogue de messages évolue par lignes de base versionnées, et la flotte déployée s'étale sur deux décennies :

Cette chronologie est compilée depuis l'historique public des éditions publié par la communauté de maintenance du catalogue et depuis les registres publics de l'OTAN. Deux changements de l'APP-11(E) comptent pour les intégrateurs : le WGS 84 est devenu le seul système géodésique autorisé pour l'information de position (l'option d'en sélectionner un autre a été retirée), et des entités géographiques auparavant codées sont devenues du texte libre régi par des listes propres à l'opération. Derrière le catalogue, le recueil de règles lui-même est passé du STANAG 5500 Edition 4 (l'ère de la ligne de base de 1999) par l'Edition 7 (2010) à l'Edition 8 actuelle, sous laquelle ADatP-03 Edition A Version 4 a été promulguée en 2021.

Opérationnellement, la ligne de base en vigueur est fixée par la chaîne de désignation des missions — le plan d'opération, les messages de désignation maritime ou aérienne, ou la spécification de spirale FMN à laquelle l'opération s'affilie. Le profil FMN des opérations aériennes, par exemple, a fait passer la prise en charge des messages formatés des définitions héritées ATO/ACO de la Baseline 11 (documentées dans d'anciennes publications alliées) à l'APP-11(E). La même discipline régit les opérations de liaisons de données, où l'OPTASK LINK dote tout le réseau — voir comment l'OPTASK LINK régit Link 16.

XML-MTF : le même message en XML

Jusqu'en 2008, les messages formatés n'existaient qu'en texte à barres obliques. Depuis, le catalogue APP-11 inclut aussi des définitions XML-MTF, avec une correspondance délibérée un-à-un entre les représentations textuelle et XML — l'avantage de bande passante de la forme textuelle est préservé tandis que l'outillage XML standard devient utilisable. La partie concept d'ADatP-3 (CONFORMETS) spécifie la famille de spécifications techniques XML-MTF telle qu'elle s'applique aux MTF ADatP-03 pour produire des formats XML dérivés équivalents.

Deux conséquences pratiques pour les ingénieurs :

• L'outillage XML standard fonctionne. Les schémas du catalogue peuvent piloter des analyseurs validants, l'extraction XPath et le rendu XSLT au lieu de code de message sur mesure.
• La nomination est gérée. L'OTAN a enregistré un espace de noms URN formel (urn:nato:) dans le RFC 7467, avec les artefacts de formats de messages texte comme type de ressource nommé, si bien que les espaces de noms et schémas XML reçoivent des identifiants persistants et sans collision.

La représentation XML est aussi le chemin de maintenance : le travail actuel sur le catalogue comprend la mise à jour du XML vers les dernières règles de nomination et de conception OTAN et l'introduction d'une variante JSON des messages. Si vous venez du monde TAK, notez que XML-MTF est une convention bien plus lourde que le XML Cursor on Target qu'échangent les applications de conscience tactique — des exemples CoT annotés montrent à quel point ce format est minimal en comparaison, et les passerelles entre les deux mondes sont un projet d'intégration à part entière.

USMTF (MIL-STD-6040) : l'équivalent américain et ses liens avec l'OTAN

Les États-Unis mènent leur propre programme de formatage des messages texte, USMTF, régi par le MIL-STD-6040 (depuis 2008 la série MIL-STD-6040B, avec le catalogue livré en schémas XML-MTF) et géré sous l'instruction du président des chefs d'état-major interarmées CJCSI 6241.04E (octobre 2023). L'instruction est explicite sur la correspondance : l'équivalent OTAN des règles et conventions MIL-STD-6040 est ADatP-3, et APP-11 est l'équivalent du catalogue de messages USMTF. L'USMTF est obligatoire pour tous les besoins d'échange de messages formatés orientés caractères dans les systèmes américains, sauf exclusion expresse par accord multinational.

Les deux recueils de règles sont proches : les directives publiées par la communauté de maintenance décrivent des règles très semblables avec seulement des différences mineures, et un certain nombre de messages ont été harmonisés entre les deux catalogues. Les lignes de base USMTF déployées (1998, 2000 et 2004 dans les systèmes hérités) sont parallèles à l'histoire des lignes de base OTAN. Pour l'intégrateur, la leçon pratique est qu'un même moteur MTF peut traiter les deux — mais il doit être piloté par le bon pack de catalogue, APP-11 OTAN ou USMTF, pour la ligne de base que le partenaire exploite réellement. Et ne confondez ni l'un ni l'autre avec le VMF (MIL-STD-6017), un format binaire orienté bits pour les liaisons radio, pas un format de messages orienté caractères.

Comment un logiciel traite les MTF : analyseur, validateur, générateur — et la route vers l'image C2

Le trafic de messages formels est une charge utile, pas un transport : il voyage sur la messagerie militaire (MMHS, STANAG 4406), sur le relais hérité ACP 127, ou simplement en pièce jointe d'un e-mail ou d'un chat — les profils FMN autorisent explicitement les messages formatés comme charge utile sur plusieurs transports. Notre article compagnon sur la messagerie militaire OTAN couvre la couche de traitement. Ce que le système C2 doit au message à son arrivée est un pipeline de traitement :

• Analyse pilotée par la grammaire. Tokenisez le texte en ensembles par identifiant, découpez les champs sur le séparateur, recousez les lignes de continuation et construisez l'arbre du message. La grammaire est stable dans tout le catalogue, donc un seul analyseur couvre chaque type de message.
• Validation pilotée par le catalogue. Identifiez le type de message depuis MSGID, puis vérifiez l'ordre des ensembles, l'occurrence et la répétabilité, les formats de champs et les valeurs codées contre les définitions de la ligne de base convenue. Les erreurs doivent être rapportées avec la position d'ensemble et de champ, car l'expéditeur doit les retrouver.
• Conversion et mapping. Convertissez entre le texte à barres obliques et le XML-MTF (un à un), puis mappez les champs vers le modèle de données du système. L'OTAN maintient des modèles de référence pour cela — le modèle d'information C2 OTAN (NCIM) et les spécifications MIP — et des mappings concrets existent déjà dans les normes : la norme de suivi des forces amies ADatP-36 spécifie la correspondance entre les formats de messages texte FFI et NFFI, et un profil de médiation FMN traduit le MTF FFI vers le modèle de données du fantassin.
• Génération via le même catalogue. En sortie, des éditeurs à formulaires générés depuis les modèles du catalogue imposent les champs obligatoires et les tables de valeurs à la saisie ; le générateur sérialise en texte ou XML-MTF, valide l'aller-retour et appose le groupe date-heure, la priorité et l'adressage.

Parce que les deux sens sont pilotés par les mêmes définitions lisibles machine, le catalogue est de fait le contrat entre émetteur et destinataire — c'est pourquoi l'échange de messages formatés est un point de test de premier plan à l'événement annuel d'interopérabilité de l'OTAN, où s'exercent les profils FMN de messages formatés air, mer, cyber et évacuation médicale. S'y préparer est une discipline en soi : voir notre guide de certification CWIX et la façon dont nous exposons les résultats de tests de coalition dans l'Interoperability Dashboard.

Pièges qui brisent l'interopérabilité MTF

La plupart des défaillances de messages formatés ne sont pas exotiques :

• Décalage de ligne de base. Un partenaire encore sur APP-11(D) envoie un message que votre validateur APP-11(E) rejette — ou accepte tout en lisant de travers un champ retiré. La transition APP-11(E) a retiré 40 messages et fait de WGS 84 le seul système autorisé ; un analyseur qui honore encore d'autres systèmes corrompra les coordonnées. Fixez la ligne de base dans les instructions de transmissions de l'opération et détectez celle de l'expéditeur depuis l'identification du message.
• Extensions nationales. Les nations ajoutent ensembles et champs dans des variantes nationales. La stratégie robuste est accepter-et-signaler : analysez ce que le catalogue connaît, mettez en quarantaine et journalisez ce qu'il ne connaît pas, et montrez la différence à un opérateur — ne jamais jeter silencieusement.
• Mésusage du texte libre. Pousser des données structurées dans la prose GENTEXT ou NARR parce que les champs codés « ne tiennent pas » détruit le traitement machine pour chaque destinataire. Si l'information compte pour l'automatisation, elle appartient aux champs codés ; si un nouveau champ codé est réellement nécessaire, c'est une proposition de changement au catalogue, pas un hack local.
• Modèles d'éditeur obsolètes. Des formulaires non régénérés depuis la ligne de base courante laissent les opérateurs omettre des champs devenus obligatoires ; la validation échoue alors en aval chez le partenaire au lieu de la saisie.