CWIX — Coalition Warrior Interoperability eXercise — se tient une fois par an à Bydgoszcz sous parrainage du JFC Brunssum. Trois semaines. Des centaines de nations et de fournisseurs. De vraies piles partenaires branchées sur le même tissu que la vôtre. C'est le seul endroit sur Terre où un test honnête de l'interopérabilité OTAN se produit à grande échelle, et il est sans pitié. Un code qui « a passé la conformité » à la maison échoue couramment dès la première poignée de main inter-fournisseurs sur le plateau.

La solution n'est pas d'attendre Bruxelles. La solution est un banc d'essai de coalition — un dispositif délibérément conçu qui exerce votre code d'interopérabilité contre des piles partenaires simulées à chaque commit poussé. Cet article est un guide d'ingénierie : ce que contient le banc, quels outils en font partie, et comment l'exécuter pour que le premier jour à CWIX soit ennuyeux plutôt que catastrophique.

Pourquoi un banc d'essai de coalition

L'économie est brutale. Un bug trouvé à CWIX coûte environ deux ordres de grandeur de plus qu'un bug trouvé en CI. L'équipe est en déplacement, la fenêtre de test est figée, et la pile partenaire dont vous avez besoin pour retester peut ne pas être à nouveau disponible avant un an. Pire, la confiance des partenaires s'érode vite — un fournisseur dont la passerelle corrompt une piste de surface Link 16 J3.2 le premier jour sera discrètement contourné pour le reste de l'exercice. Le résultat d'accréditation découle de cette première impression.

Le problème plus profond est que CWIX est généralement la première fois qu'une pile étrangère voit vos messages. Vous avez écrit selon ADatP-3 à la lettre. Vous avez exécuté un outil de conformité STANAG. Vos messages s'analysent proprement dans votre propre émetteur et votre propre consommateur. Rien de tout cela ne prouve que votre code interopère avec une instance JCHAT allemande, une passerelle française SICF-NG, ou un terminal JREAP-C américain piloté par l'interprétation d'un autre fournisseur du même STANAG. Un banc d'essai de coalition déplace cet événement de premier contact de Bruxelles vers votre ordinateur portable. Voir notre guide complet de l'interopérabilité OTAN pour la vue d'ensemble.

Pyramide de tests pour le code d'interopérabilité

Le code d'interopérabilité mérite sa propre pyramide de tests. La forme est familière ; les couches sont spécifiques.

Unitaire — structure du message. Tests purs sur le parseur et sérialiseur du format filaire. Aller-retour d'un tampon d'octets connu-bon vers une structure en mémoire et retour. Les champs frontières (énumérations bit-packées en J-series, identifiants à longueur fixe en ADatP-34) méritent des tests dédiés à base de propriétés avec Hypothesis, jqwik ou fast-check. La couverture à cette couche doit être quasi totale — ces tests sont bon marché et attrapent les bugs de corruption silencieuse que les humains ne repèrent jamais dans un dump hexadécimal.

Intégration — aller-retour mono-protocole. Démarrer la pile de protocole en cours de processus, envoyer un message généré dans votre émetteur, le router via un transport en boucle, et affirmer que le consommateur reconstruit une structure équivalente. C'est là que vous attrapez les erreurs d'endianness, les bugs de conversion temporelle (temps OTAN, UTC, temps GPS, secondes intercalaires), et les erreurs de référentiel de coordonnées (WGS-84 vs MGRS vs UTM). Utilisez Testcontainers si un vrai broker (NATS, ActiveMQ, RabbitMQ pour NFFI) est dans le chemin.

Système — passerelle multi-protocole. La plupart des systèmes de coalition sont des passerelles. Une piste entre en Link 16 J3.2, sort en ADatP-34 NFFI, et est mirroirisée vers un flux CoT/MQTT pour les clients de connaissance situationnelle. La couche système câble l'ensemble du pipeline dans un cluster docker-compose ou k3d, fait entrer des messages, et affirme les invariants inter-protocoles — stabilité de l'ID de piste, fidélité de position dans la tolérance, préservation de la classification.

CWIX — vraies piles partenaires. Le sommet de la pyramide est incontournable : vous ne pouvez pas simuler entièrement une pile partenaire que vous n'avez jamais vue. Mais la pyramide garde ce sommet étroit. Au moment où vous atterrissez à Bydgoszcz, quatre-vingt-quinze pour cent des bugs devraient déjà être morts.

Générateurs de messages

Un banc vit ou meurt sur le réalisme de son trafic généré. Des générateurs à moitié crédibles donnent une fausse confiance.

Générateurs Link 16 J-series. Construisez un générateur paramétré par famille de messages J-series — J2 surveillance, J3.2 piste de surface, J7 gestion de l'information, J12 gestion de mission. La fidélité au bit compte : un défaut de champ réservé incorrect passera votre décodeur et échouera chez un partenaire. Des outils comme la sortie du simulateur MIDS-LVT et le catalogue de messages J-Series publié par la NSA sont la référence. Enveloppez-les dans un fuzzer qui varie la classification déclarée, le TN source et la qualité de piste.

Émetteurs ADatP-34 (NFFI). Messages NFFI 1.3 / IP1 / IP2 sur SOAP ou REST. Construisez des émetteurs qui produisent à la fois des charges conformes et intentionnellement quasi conformes — les parseurs des partenaires varient en rigueur, et votre banc doit exposer la rigueur de votre consommateur également. Les XSDs NFFI publiés par la NCIA OTAN sont le contrat ; validez chaque message généré contre eux avant transmission.

Injection CoT et MQTT. Cursor-on-Target XML sur TCP ou MQTT est la lingua franca des clients tactiques SA (ATAK, WinTAK, iTAK). Générez des événements CoT avec des temps de péremption réalistes, des étendues géo-clôturées et des extensions de détail variées. Mosquitto en conteneur gère le côté broker ; pour une plus haute fidélité, exécutez TAK Server CE.

Fabriques de messages MIP4-IES. La spécification d'échange d'information MIP4 du Multilateral Interoperability Programme (anciennement connue sous JC3IEDM au niveau du modèle de données) pilote l'échange C2 structuré. Les fabriques de messages MIP4 sont plus lourdes — triplets RDF et assertion à base SPARQL — mais indispensables si votre code touche un système C2 national.

Simulateurs de piles partenaires

Aucun simulateur unique ne couvre le spectre. Combinez-les.

Simulateurs de terminaux JREAP-C. JREAP (Joint Range Extension Applications Protocol) transporte Link 16 sur IP. Plusieurs fournisseurs livrent des simulateurs de terminal JREAP-C ; le kit de test ouvert NavyJTIDS de l'US Navy et les offres commerciales de ViaSat ou Ultra sont courants. Écart de fidélité : la temporisation — les vrais terminaux introduisent une dynamique de créneaux de synchronisation J-series que les simulateurs purement logiciels aplatissent.

JISR-Lite. Implémentation de référence Joint Intelligence, Surveillance and Reconnaissance de l'OTAN. Excellent pour les métadonnées d'imagerie en mouvement STANAG 4609 et la requête/récupération de produits CSD STANAG 4559. Exécutez-le dans une VM ; pointez votre code vers ses endpoints. Écart de fidélité : l'échelle du catalogue — les vrais CSD de coalition contiennent des ordres de grandeur de produits supérieurs au jeu de données de référence.

Piles de référence NCI Server. La NCIA publie des implémentations de référence pour plusieurs services de spirale FMN — annuaire, messagerie, publication/abonnement de connaissance situationnelle. Ce ne sont pas des piles partenaires certifiées, mais elles exposent les formats filaires et les flux d'authentification que vous devez correspondre. Écart de fidélité : les chaînes de confiance de certificats — les vrais nœuds FMN se terminent sur des hiérarchies PKI que vous ne pouvez pas répliquer parfaitement sans AC de coalition.

Nœuds FMN simulés. Montez un nœud FMN minimal en utilisant les services de référence NCIA plus une PKI locale (step-ca ou smallstep) pour le tissu de confiance. Configurez les profils de service FMN Spiral 4 ou Spiral 5 selon l'exercice que vous préparez. Parcourez cette configuration avec la discipline d'un dossier de preuves d'accréditation — voir accréditation CWIX.

Suites de tests de conformité

Les rapports de conformité STANAG OTAN sont nécessaires et insuffisants. Ils prouvent que vos messages correspondent aux règles syntaxiques et sémantiques du standard. Ils ne prouvent pas qu'un partenaire allemand comprendra votre intention.

Exécutez les suites quand même. Les catalogues de messages ADatP-3 livrent des validateurs ; les métadonnées de confidentialité STANAG 4774/4778 ont les leurs. La validation XSD NFFI est non négociable. Les portes de conformité FMN par spirale sont conditionnées à des preuves documentées — votre banc devrait émettre ces preuves comme artefact de build. Associez les rapports de conformité avec les preuves de qualité logicielle OTAN AQAP-2110 pour faire avancer les réviseurs d'accréditation ; voir notre guide AQAP-2110.

L'écart entre « passe le test » et « interopère avec les humains » n'est comblé que par la répétition avec les piles partenaires. Une piste de surface J3.2 parfaitement conforme mais utilisant un espace de numérotation entrant en collision avec l'allocation d'un partenaire échouera à l'interopérabilité jugée par des humains dès le premier jour. Documentez explicitement les négociations d'allocation dans la configuration de votre banc ; traitez-les comme des données de test.

Intégration continue pour l'interopérabilité

Le banc doit s'exécuter sur chaque pull request. S'il ne tourne que de nuit, l'équipe a déjà accepté des semaines de dérive au moment où CWIX arrive.

Intégrez le banc dans un seul job CI : GitHub Actions, GitLab CI ou Azure DevOps Pipelines fonctionnent tous. Utilisez des simulateurs conteneurisés pour que le job soit hermétique. Capturez un corpus de messages déterministe — un ensemble curé de messages J-series, NFFI, CoT et MIP4 avec des résultats attendus connus-bons — et rejouez-le à chaque build. Snapshot-régression de toute sortie au format filaire : un changement d'un octet dans un sérialiseur est exactement le bug qui casse un partenaire.

La provenance compte. Chaque exécution du banc devrait émettre un bundle d'artefacts signés — rapports de conformité, version du corpus de messages, versions des simulateurs, votre SBOM. Liez ceci aux contrôles de chaîne d'approvisionnement décrits dans l'application du SBOM dans les pipelines de défense.

Point clé : Le banc n'est pas un projet séparé. C'est une partie du codebase, versionnée avec le code, détenue par les ingénieurs qui écrivent la logique d'interopérabilité. Les bancs externalisés deviennent obsolètes ; les bancs internes évoluent à chaque PR et attrapent les régressions le jour où elles atterrissent.

Tests négatifs

La plupart des bugs d'interopérabilité surfacent sur le chemin malheureux. Le banc doit le piloter délibérément.

Messages malformés. Tronquez les trames Link 16 J-series en milieu de champ. Corrompez les énumérations bit-packées en valeurs réservées. Envoyez des charges NFFI avec des XSDs délibérément invalides. Votre consommateur doit rejeter, journaliser et continuer — jamais planter, jamais accepter silencieusement, jamais propager.

Superpositions de sécurité. Variez les métadonnées de confidentialité STANAG 4774 : envoyez un message taggé NATO SECRET à un consommateur habilité seulement à NATO RESTRICTED. Le consommateur doit refuser et auditer, pas dégrader. Les violations de liaison STANAG 4778 — incohérence de signature sur une charge liée aux métadonnées — doivent échouer en fermeture.

Mauvaise gestion de la classification. Les erreurs inter-domaines mettent fin à des carrières dans les opérations de coalition. Injectez des lots à classification mixte dans votre passerelle et affirmez que la règle de la classification la plus élevée vaut pour l'ensemble du lot. Injectez des messages dépourvus de métadonnées de classification — votre code doit rejeter, jamais utiliser de valeur par défaut.

Cas limites de décalage temporel. Les horloges dérivent, le temps GPS et l'UTC divergent aux secondes intercalaires, et les systèmes partenaires rapportent parfois le temps dans des champs qui ne correspondent pas à leur spécification filaire. Pilotez votre banc avec des horodatages délibérément décalés (positifs et négatifs) et affirmez que votre code clampe, rejette ou journalise selon l'exigence — jamais n'accepte silencieusement un message daté de l'année prochaine.

Préparation CWIX

Six semaines avant, le cycle de répétition commence. Gelez la portée du banc ; pas de nouvelles fonctionnalités jusqu'après Bruxelles. Organisez un « mini-CWIX » interne — un événement fermé sur deux ou trois jours où chaque équipe de l'entreprise qui touche le système se branche simultanément. Le but n'est pas de trouver de nouveaux bugs ; le but est de rendre les équipes d'opérations et de déplacement fluides sur le flux du plateau avant qu'elles ne rencontrent un vrai partenaire.

Quatre semaines avant, exécutez une répétition partenaire. Coordonnez avec un fournisseur ami ou une unité alliée pour un échange virtuel d'une journée. Même une seule connexion externe expose des hypothèses cuites dans votre banc. Capturez chaque pcap, chaque log ; les leçons alimentent le corpus du banc de l'année suivante.

Deux semaines avant, verrouillez l'artefact. Étiquetez le build. Gravez l'ensemble d'images simulateur sur les ordinateurs portables voyageant à Bydgoszcz. Pré-positionnez chaque rapport de conformité, chaque SBOM, chaque bundle de preuves signées dans le format que les réviseurs d'accréditation du JFC Brunssum attendent.

Sur le plateau, la discipline est la journalisation. Capturez chaque octet sur chaque interface, classifiée et non classifiée, avec des horloges synchronisées. Triez en temps réel mais ne résolvez rien de manière destructive — la valeur de CWIX n'est pas les bugs que vous corrigez pendant l'exercice ; ce sont les bugs que vous corrigez dans le banc ensuite pour qu'ils ne se reproduisent jamais. Le cycle de retour d'expérience, exécuté fidèlement, est ce qui alimente la course propre de l'année suivante et celle d'après.