Interopérabilité

Modèle d'information C2 de l'OTAN : mise en œuvre NCIM et échange de données

Par l'équipe d'ingénierie de Corvus Intelligence · À propos de l'équipe →

25 juin 2026 12 min de lecture

Le modèle d'information C2 de l'OTAN — NCIM — est le fondement sémantique canonique sous les normes d'échange de données de commandement et de contrôle de l'Alliance. Là où les structures de données ADatP-34 définissent des formats de messages et où le standard OTAN MIP4 IES pour les forces terrestres définit des protocoles d'échange pour les forces terrestres, NCIM se situe une couche au-dessus des deux : il définit quels types de choses existent dans une opération C2, comment ces choses se relient entre elles et quelles données doivent être enregistrées sur chacune. Chaque norme de mise en œuvre OTAN qui échange des données opérationnelles fait correspondre ses structures à NCIM. Comprendre NCIM n'est donc pas optionnel pour les ingénieurs qui veulent naviguer dans le paysage plus large des normes C2 de l'OTAN — c'est la référence partagée qui donne sa cohérence au reste du guide complet de l'interopérabilité OTAN.

Ce qu'est NCIM et pourquoi il existe

Le problème d'interopérabilité C2 de l'Alliance dans les années 1990 n'était pas principalement un problème de protocole — c'était un problème sémantique. Les nations de l'OTAN avaient mis en œuvre des systèmes C2 qui échangeaient des messages, mais un même champ dans les systèmes de deux nations ne signifiait pas la même chose. Un « statut d'unité » à « OPERATIONAL » dans un système couvrait un seuil de disponibilité différent de celui d'un autre. Quand les systèmes échangeaient des données, les octets étaient reçus mais le sens ne l'était pas. C'est le problème que NCIM a été créé pour résoudre.

NCIM (NATO C2 Information Model) est le modèle de données conceptuel et logique canonique de l'Alliance pour l'information de commandement et de contrôle. Il définit les types d'entités qui participent aux opérations C2, les relations entre ces entités, et les attributs — avec leurs types de données et leurs domaines de valeurs — qui doivent être enregistrés sur chaque type d'entité pour soutenir l'échange d'informations opérationnelles. Il ne définit ni les formats de transmission, ni les protocoles réseau, ni la sérialisation — c'est la responsabilité des normes de mise en œuvre qui désignent NCIM comme leur autorité sémantique.

La généalogie de NCIM passe par plusieurs prédécesseurs. JC3IEDM (Joint Consultation, Command and Control Information Exchange Data Model) fut le premier modèle de données C2 complet de l'Alliance, développé en collaboration par les nations OTAN à la fin des années 1990 comme un modèle relationnel formellement spécifié couvrant tout le spectre des données opérationnelles. JC3IEDM a été suivi de NC2IEDM (NATO C2 Information Exchange Data Model), qui a raffiné le modèle d'entités et l'a étendu aux opérations interarmées dans tous les domaines. NCIM représente l'évolution actuelle : un modèle structuré en couches conceptuelle et logique distinctes, aligné sur les principes modernes d'architecture de l'information, et conçu pour servir de modèle parent duquel les normes de mise en œuvre propres à un domaine dérivent sous forme de profils.

La relation aux autres normes de données de l'OTAN est directe. Le modèle de données MIP4 — qui définit les types d'entités Unit, Equipment, Task et apparentés pour l'échange C2 des forces terrestres — est un profil du domaine terrestre de NCIM. Les structures de messages d'ADatP-34 sont organisées selon la sémantique NCIM : chaque type de message ADatP-34 correspond à un motif d'instances d'entités NCIM. C-BML (Coalition Battle Management Language), le langage XML pour des ordres exploitables par des machines, utilise les types d'entités Activity et Plan de NCIM comme fondation sémantique. Comprendre la hiérarchie des types d'entités et la sémantique des relations de NCIM fournit donc le cadre de référence partagé pour naviguer dans MIP4, ADatP-34 et C-BML comme un système cohérent plutôt que comme trois normes indépendantes.

Hiérarchie des types d'entités NCIM

NCIM définit six types d'entités de premier niveau. Ces six types couvrent ensemble toutes les catégories d'information qui apparaissent dans une opération C2 OTAN, et chaque entité d'un modèle de données de niveau mise en œuvre remonte à exactement un d'entre eux.

Activity est le type d'entité des actions planifiées ou réelles. Missions, tâches, phases d'une opération, engagements et événements rapportés sont tous des Activity dans NCIM. Activity a des sous-types pour différentes catégories d'action : Task (une action dirigée assignée à une Organisation ou à une Resource), Mission (une directive de haut niveau englobant plusieurs Task) et Event (une occurrence spontanée qui est rapportée plutôt qu'assignée). La hiérarchie Activity est la structure principale par laquelle les ordres opérationnels sont représentés dans les systèmes fondés sur NCIM.

OperationalObject couvre les entités qui sont suivies, ciblées ou surveillées mais qui ne sont pas elles-mêmes des acteurs. Cibles, zones d'intérêt, points nommés, évaluations de menace et rapports de renseignement sur des unités ennemies sont des OperationalObject. La distinction avec Organisation et Resource (qui représentent des entités amies ou neutres dont l'identité est connue) est significative : un OperationalObject peut avoir une identité incertaine, une localisation incertaine, et peut être une hypothèse plutôt qu'une observation confirmée.

Organisation représente des regroupements structurés de personnel avec des relations de commandement. Les unités militaires à tous les échelons (peloton, compagnie, bataillon, brigade, division) sont des Organisation. La hiérarchie Organisation capture la structure de commandement à travers des relations parent-enfant entre instances d'Organisation, chaque Organisation ayant une désignation standard, un type organisationnel issu de la taxonomie ORBAT de l'OTAN et une relation de commandement avec son Organisation parente (commandement, soutien, contrôle opérationnel, contrôle tactique).

Resource couvre le matériel et le personnel comme éléments individuels plutôt que comme groupes organisés. Un véhicule précis, un système d'armes, un dispositif de communication ou une personne agissant dans un rôle spécifique est une Resource. Les Resource sont associées aux Organisation par des relations d'affectation et d'équipement — un bataillon (Organisation) possède des véhicules associés (Resource), et la relation d'équipement porte le statut d'affectation et la plage de dates. La distinction entre Organisation et Resource correspond approximativement à celle entre unités et équipements dans un ordre de bataille.

Location est le type d'entité pour toutes les informations positionnelles et géométriques. La décision de conception de NCIM de faire de Location un type d'entité à part entière — plutôt que d'intégrer des coordonnées comme attributs d'autres types d'entités — a d'importantes conséquences sur la mise en œuvre. Une instance de Location porte la géométrie (point, polyligne, polygone, corridor ou composite), le système de référence de coordonnées, une estimation d'incertitude positionnelle, une fenêtre de temps de validité et un indicateur de source de position. Les autres types d'entités référencent Location par identifiant plutôt que par coordonnées intégrées. Cette conception permet à la même Location d'être référencée par plusieurs entités, d'attacher des métadonnées d'incertitude et de validité aux données positionnelles, et de modéliser l'historique des positions comme une séquence d'instances de Location associées à une seule Organisation ou Resource.

Plan est le type d'entité des produits de planification opérationnelle. Un plan d'opération, un ordre fragmentaire, un ordre de transition de phase ou un document de concept des opérations est un Plan dans NCIM. Le type d'entité Plan a des sous-types pour différentes catégories de produits de planification et porte des relations vers les Activity qu'il dirige, les Organisation qu'il met à contribution et les Location qu'il assigne comme objectifs.

La structure d'héritage au sein de chacun de ces six types est significative pour la mise en œuvre. Au sein d'Activity, par exemple, la chaîne d'héritage complète est : Activity → Task → ControlMeasureTask (une tâche qui dirige la pose ou le retrait d'une mesure de contrôle) — chaque niveau ajoute des attributs propres à ce sous-type tout en héritant de tous les attributs de son parent. Les normes de mise en œuvre sélectionnent la profondeur d'héritage dont elles ont besoin : MIP4 met en œuvre Task et plusieurs de ses sous-types ; C-BML met en œuvre la hiérarchie Activity complète jusqu'aux types de tâches élémentaires de la taxonomie tactique OTAN.

Structures des plans opérationnels dans NCIM

Le type d'entité Plan et ses relations avec les instances d'Activity forment l'ossature de la représentation NCIM des produits de planification opérationnelle. Comprendre cette structure est essentiel pour mettre en œuvre tout système C2 OTAN qui doit échanger des plans, des ordres ou leur statut d'exécution.

Au niveau supérieur, une instance Plan représente un produit de planification opérationnelle complet — un OPLAN, un OPORD, un FRAGO ou un CONOPS. Un Plan porte un identifiant unique, une étiquette de classification et de diffusion, une autorité (l'Organisation qui l'a émis), une période de validité et un statut (projet, approuvé, remplacé). Les Plans sont reliés entre eux par une chaîne de remplacement : un FRAGO qui modifie un OPLAN existant référence l'OPLAN qu'il remplace, créant un historique de plans qui permet aux systèmes de reconstituer l'évolution du schéma opérationnel.

Un Plan est structuré en instances de Phase — chaque Phase représentant une période discrète d'opérations avec des conditions de transition définies. Dans NCIM, Phase est un sous-type d'Activity associé à un Plan par une relation planContains. Les instances de Phase sont séquencées par des conditions de transition : une instance de Phase B a une startCondition qui référence soit un temps (J+3), soit un événement (achèvement de l'objectif de la Phase A). Les structures de niveau Phase apparaissent dans le format de message OPLAN d'ADatP-34 et sont directement mises en œuvre dans la représentation des ordres de C-BML.

Au sein de chaque Phase, des instances de Task représentent les actions assignées. Une Task NCIM porte : un identifiant unique, un type de tâche issu de la taxonomie tactique OTAN (SEIZE, ATTACK, DEFEND, SCREEN, COVER, SUPPORT BY FIRE, et des dizaines d'autres), l'Organisation ou la Resource mise à contribution, la Location objectif (qui peut être un point, une zone ou un lieu nommé), les contraintes temporelles (début au plus tôt, début au plus tard, achèvement requis), l'autorité émettrice et la référence au Plan émetteur. La relation Task-to-Organisation est l'expression NCIM de « l'unité X est chargée de l'objectif Y » — l'échange d'informations C2 fondamental.

Les instances d'Objective dans NCIM précisent la finalité de la Task : un Objective porte le but opérationnel spécifique que la Task est conçue pour atteindre, exprimé comme une condition à établir (terrain saisi, ennemi détruit, route dégagée) plutôt que comme une simple localisation géographique. La distinction compte pour les ordres exploitables par des machines : un système C-BML qui reçoit une tâche peut utiliser le type de condition de l'Objective pour déterminer quand la tâche est achevée, ce qui permet un rapport de progression automatisé sans interprétation humaine.

Les instances de Constraint attachent des conditions limitatives aux Task et aux Plan. Les Constraint dans NCIM sont typées : une contrainte temporelle limite la fenêtre temporelle d'une activité ; une contrainte géographique limite la zone dans laquelle une ressource peut opérer ; une contrainte de ressources limite les moyens utilisables pour une tâche. Les Constraint sont référencées aussi bien par des instances de Task (limitant une tâche précise) que par des instances de Plan (s'appliquant à toute l'opération). Le modèle de contraintes NCIM est la base sémantique du codage des règles d'engagement dans les systèmes C2 de coalition qui doivent garantir l'interopérabilité avec les politiques nationales de règles d'engagement.

<!-- NCIM Plan / Phase / Task hierarchy — simplified XSD sketch -->
<xs:complexType name="PlanType">
  <xs:sequence>
    <xs:element name="planId"      type="ncim:UniqueIdType"/>
    <xs:element name="authority"   type="ncim:OrganisationRefType"/>
    <xs:element name="phase"       type="ncim:PhaseType" minOccurs="1"
                                   maxOccurs="unbounded"/>
    <xs:element name="constraint"  type="ncim:ConstraintType"
                                   minOccurs="0" maxOccurs="unbounded"/>
  </xs:sequence>
</xs:complexType>

<xs:complexType name="PhaseType">
  <xs:sequence>
    <xs:element name="phaseId"         type="ncim:UniqueIdType"/>
    <xs:element name="phaseNumber"     type="xs:integer"/>
    <xs:element name="startCondition"  type="ncim:ConditionType"/>
    <xs:element name="task"            type="ncim:TaskType"
                                       minOccurs="0" maxOccurs="unbounded"/>
  </xs:sequence>
</xs:complexType>

<xs:complexType name="TaskType">
  <xs:sequence>
    <xs:element name="taskId"        type="ncim:UniqueIdType"/>
    <xs:element name="taskType"      type="ncim:TacticalTaskCodeType"/>
    <xs:element name="taskedUnit"    type="ncim:OrganisationRefType"/>
    <xs:element name="objectiveLoc"  type="ncim:LocationRefType"/>
    <xs:element name="timeWindow"    type="ncim:TimeWindowType"/>
    <xs:element name="objective"     type="ncim:ObjectiveType"
                                     minOccurs="0"/>
  </xs:sequence>
</xs:complexType>

Modélisation des ressources et des équipements

La hiérarchie du type d'entité Resource dans NCIM fournit les structures pour représenter les plateformes, les ensembles d'équipements et les unités organisationnelles comme des éléments de matériel et du personnel individuels. La modélisation des Resource est critique pour les systèmes C2 de coalition qui doivent échanger des données d'ordre de bataille incluant le statut des équipements et les déclarations de capacités.

Platform est le principal sous-type de Resource pour les systèmes physiques — véhicules, aéronefs, navires et systèmes d'armes. Une instance de Platform dans NCIM porte une référence de type de plateforme (issue d'un vocabulaire contrôlé aligné sur les codes OTAN de classification des équipements), un identifiant de série ou d'immatriculation, un code de statut opérationnel (entièrement apte à la mission, partiellement apte à la mission, inapte à la mission) et une référence vers sa Location courante. Les instances de Platform sont liées aux instances d'Organisation par une relation d'Equipage qui porte la période d'affectation et le type d'affectation (organique, rattaché, contrôle opérationnel). C'est l'expression NCIM d'une entrée d'ordre de bataille : l'Organisation est le bataillon, les instances de Platform sont les véhicules, et les relations d'Equipage enregistrent quels véhicules sont actuellement affectés à quelles unités.

Pour les cas où les plateformes individuelles ne sont pas suivies séparément (courant pour les armes légères, les équipements de communication et certains matériels de soutien), NCIM fournit EquipmentSet : un sous-type de Resource qui représente une quantité d'articles homogènes plutôt que des articles suivis individuellement. Un EquipmentSet porte le type d'article, une quantité, une unité de mesure et un état de disponibilité agrégé. Les instances d'EquipmentSet apparaissent dans les scénarios de rapport logistique où les quantités globales sont plus pertinentes opérationnellement que le suivi individuel des articles.

OrganisationUnit fait le pont entre les types d'entités Resource et Organisation pour les cas où une équipe, un équipage ou une section spécifique doit être représenté à la fois comme une ressource (avec équipement) et comme un élément organisationnel (avec relations de commandement). Un équipage d'hélicoptère, par exemple, est une OrganisationUnit : il a un aéronef affecté (relation Resource) et une hiérarchie de rapport (relation Organisation). Le sous-type OrganisationUnit de NCIM permet cette double identité sans créer d'incohérence dans le modèle de données.

La déclaration de capacités est un cas d'usage significatif de la modélisation des Resource en coalition. NCIM prend en charge Capability comme catégorie d'attributs à la fois sur Organisation et sur Resource, à l'aide d'un vocabulaire contrôlé aligné sur la taxonomie de capacités de l'OTAN. La déclaration de capacités d'une unité — indiquant les types de mission pour lesquels elle est équipée et entraînée — est représentée comme un ensemble de références de Capability sur l'instance d'Organisation. Lors de la planification en coalition, le processus d'affectation Task-to-Organisation utilise les références de Capability pour apparier les tâches avec des unités dotées des capacités appropriées. Dans les systèmes C2 automatisés, cet appariement peut être exécuté par la machine ; dans les systèmes pilotés par l'opérateur, les données de capacité informent la sélection d'unités par l'opérateur dans le flux de désignation des tâches.

<!-- NCIM Resource / Equipage — illustrative XML fragment -->
<ncim:Resource xsi:type="ncim:PlatformType">
  <ncim:resourceId>{a4c12f88-3e7b-4d1a-b962-9f0d55c12e34}</ncim:resourceId>
  <ncim:platformType>NATO_EQPT_CODE:CV90</ncim:platformType>
  <ncim:serialId>SE-CV90-0147</ncim:serialId>
  <ncim:operationalStatus>FMC</ncim:operationalStatus>
  <ncim:currentLocation ref="{loc-uuid-0a1b2c}"/>
  <ncim:confidentiality>NATO RESTRICTED</ncim:confidentiality>
  <ncim:releasability>NATO</ncim:releasability>
</ncim:Resource>

<ncim:Equipage>
  <ncim:organisation ref="{org-uuid-battalion-42}"/>
  <ncim:resource     ref="{a4c12f88-3e7b-4d1a-b962-9f0d55c12e34}"/>
  <ncim:assignmentType>ORGANIC</ncim:assignmentType>
  <ncim:validPeriod>
    <ncim:startDTG>2026-06-01T06:00:00Z</ncim:startDTG>
  </ncim:validPeriod>
</ncim:Equipage>

Sérialisation XML et JSON

NCIM est un modèle conceptuel et logique — il définit des sémantiques, pas des octets. La sérialisation vers des formats de transmission est la responsabilité des normes de mise en œuvre qui utilisent NCIM comme modèle parent. Comprendre comment les sémantiques NCIM sont mappées vers XML et, de plus en plus, vers JSON est essentiel pour les développeurs qui construisent des couches d'échange entre systèmes de coalition.

Le principal format de sérialisation pour l'échange fondé sur NCIM est XML. Le XML Schema de NCIM est structuré comme un ensemble de modules XSD, un par groupe de types d'entités NCIM, organisés sous une hiérarchie d'espaces de noms commune. L'espace de noms de premier niveau est urn:int:nato:ncim:3 (pour NCIM version 3.x), avec des sous-espaces de noms pour chaque module de domaine : urn:int:nato:ncim:3:core pour les types d'entités de base, urn:int:nato:ncim:3:land pour les extensions du domaine terrestre, et ainsi de suite. Les normes de mise en œuvre qui sont des profils de NCIM définissent leurs propres espaces de noms, qui importent les modules NCIM pertinents et ajoutent des contraintes de niveau mise en œuvre (champs obligatoires, restrictions de vocabulaire contrôlé, resserrement des cardinalités).

La gestion des espaces de noms dans le XML NCIM est un défi pratique. Un message C2 de coalition typique référençant des entités de plusieurs modules NCIM portera cinq à huit déclarations d'espaces de noms actives dans l'élément racine. Le risque est la collision de préfixes d'espaces de noms lorsque des messages de sources multiples sont assemblés en une image combinée : deux messages peuvent tous deux déclarer le préfixe ncim mais le mapper vers des espaces de noms de modules NCIM différents. L'approche correcte consiste à normaliser les préfixes d'espaces de noms à l'ingestion des messages — résoudre toutes les déclarations d'espaces de noms vers leur URI canonique et utiliser des cartes d'espaces de noms indexées par URI plutôt que par préfixe dans tout le pipeline de traitement.

Pour les réseaux tactiques à bande passante limitée, la verbosité du XML est un désavantage significatif. Une entité NCIM sérialisée en XML complet avec toutes les déclarations d'espaces de noms et les balises ouvrantes et fermantes peut être quatre à six fois plus volumineuse que les données utiles essentielles. Trois approches sont utilisées en pratique :

EXI (Efficient XML Interchange) : un codage XML binaire du W3C qui préserve toute la sémantique XML tout en réduisant la taille de 80 à 95 % selon la densité du schéma. EXI est l'approche préférée pour les liaisons tactiques contraintes lorsque l'aller-retour XML est requis. Les schémas NCIM sont compatibles EXI sans modification.
Compression informée par le schéma : appliquer une compression DEFLATE ou LZ4 sensible au schéma au flux d'octets XML. Elle atteint de bons taux de compression (réduction de taille de 60 à 75 %) avec un coût de calcul plus faible qu'EXI, mais sans la portabilité d'un vrai format binaire.
Sérialisation JSON : la liaison RESTful de MIP4-IES utilise JSON pour la représentation des objets individuels, en mappant les attributs d'entités NCIM vers des propriétés d'objets JSON. Les charges utiles JSON sont de 30 à 40 % plus petites que l'XML équivalent et s'intègrent plus naturellement aux bibliothèques clientes REST modernes. La contrepartie est que l'outillage de schéma JSON pour NCIM est moins mature que l'outillage XSD, et la validation d'aller-retour contre le modèle normatif NCIM exige une gestion rigoureuse des schémas.

// NCIM Organisation — JSON representation (MIP4-IES REST binding)
{
  "@type": "ncim:Organisation",
  "objectId": "b7e4a312-9c0f-4a1e-8d53-1f3a8b0c9e21",
  "creatorId": "SYS-NLD-C2-01",
  "createdDTG": "2026-06-25T08:00:00Z",
  "modifiedDTG": "2026-06-25T09:14:37Z",
  "validity": "ACTIVE",
  "designation": "42 BN 1 INF BDE",
  "organisationType": "NATO_ORG:INFANTRY_BATTALION",
  "parentOrganisation": {"ref": "org-uuid-brigade-1"},
  "commandRelationship": "ORGANIC",
  "operationalStatus": "OPERATIONAL",
  "currentLocation": {"ref": "loc-uuid-7f3c2d"},
  "capability": ["CAP:DIRECT_FIRE", "CAP:DEFENSIVE_OPERATIONS"],
  "confidentiality": "NATO CONFIDENTIAL",
  "releasability": ["NLD", "DEU", "POL", "NATO"]
}

Mise en œuvre de NCIM dans un système C2 de coalition

La plupart des systèmes C2 de coalition atteignent la mise en œuvre de NCIM par l'un de deux chemins : un système neuf conçu dès le départ autour des sémantiques NCIM, ou un système national hérité adapté à l'interopérabilité de coalition. Le second cas est de loin le plus courant et le plus difficile.

La conception d'adaptateurs pour les modèles de données nationaux est l'approche pratique pour l'intégration de systèmes hérités. Plutôt que de remanier le modèle de données interne d'un système C2 national pour le faire correspondre à NCIM — un effort pluriannuel au risque opérationnel significatif — le pattern adaptateur concentre toutes les décisions de correspondance NCIM dans un composant adaptateur séparé. L'adaptateur traduit entre le modèle national et les représentations conformes à NCIM pour tous les échanges de données externes : les données de coalition entrantes sont traduites vers le modèle national pour un usage interne ; les données nationales sortantes sont traduites vers NCIM pour l'échange en coalition. L'adaptateur est la frontière d'interopérabilité et le seul composant qui doit changer lorsque la référence NCIM est mise à jour.

La décision la plus importante dans la conception de l'adaptateur est de déterminer quels types d'entités NCIM exigent une traduction complète ou une traduction superficielle. La traduction complète — où chaque attribut NCIM a une représentation interne correspondante — est requise pour les types d'entités qui apparaissent dans un échange de données bidirectionnel. La traduction superficielle — où seuls les identifiants clés et les codes de statut sont mappés — est acceptable pour les types d'entités que le système consomme mais ne modifie ni ne crée jamais. Priorisez la traduction complète pour Organisation, Resource (Platform), Activity (Task) et Location ; la traduction superficielle suffit généralement pour Constraint et Objective au niveau de l'adaptateur.

La correspondance NCIM-vers-CoT est requise pour les systèmes qui échangent des données avec des plateformes utilisant Cursor on Target (CoT), le schéma XML utilisé par ATAK, WinTAK et les outils de connaissance situationnelle apparentés. CoT n'est pas dérivé de NCIM, mais une correspondance entre les deux est bien définie en pratique. L'élément <event> de CoT correspond à NCIM Resource (pour les plateformes et le personnel) ou OperationalObject (pour les pistes et contacts), l'attribut type se mappant sur le type d'entité NCIM et la référence de type de plateforme. L'élément <point> de CoT correspond à NCIM Location (sous-type Point) avec transformation de coordonnées si nécessaire (CoT utilise des degrés décimaux WGS-84, conformes au système de référence de base de NCIM). La principale différence structurelle est que CoT intègre les données de position dans l'élément event, tandis que NCIM les externalise comme une entité Location — l'adaptateur doit créer une instance de Location à partir de chaque point CoT lors de la traduction entrante et intégrer les coordonnées de la Location référencée dans le point CoT lors de la traduction sortante.

La passerelle NCIM-vers-MIP est l'exigence d'adaptation de coalition la plus courante pour les systèmes C2 terrestres. Le modèle de données de MIP4 est un profil du domaine terrestre de NCIM : la correspondance n'est donc pas une traduction entre modèles sans rapport — c'est une projection d'un modèle plus large (NCIM) vers un profil contraint (MIP4). Les principales différences qui exigent une logique de correspondance sont : MIP4 utilise l'OID (identifiant globalement unique fondé sur l'UUID) comme identifiant principal, tandis que NCIM utilise un UniqueId générique dont l'encodage peut différer dans d'autres normes de mise en œuvre ; le modèle d'inactivation de BaseObject de MIP4 (indicateur de validité) correspond à l'attribut de validité d'entité de NCIM ; et le modèle de Location de MIP4 utilise une représentation de l'incertitude légèrement différente du type GeometricExtent de NCIM. Ces différences sont franchissables sans perte de données, mais exigent une mise en œuvre soigneuse des cas limites.

Test d'équivalence sémantique : avant toute participation à CWIX, les systèmes devraient conduire des tests d'équivalence sémantique — échanger un jeu normalisé d'instances d'entités NCIM avec un système partenaire et vérifier que la représentation interne des données reçues chez le partenaire correspond à l'intention de l'émetteur. La conformité syntaxique (XML valide, schéma correct) ne garantit pas l'équivalence sémantique (même sens). Les erreurs opérationnelles causées par une divergence sémantique — un statut d'unité lu OPERATIONAL quand l'émetteur voulait dire DEPLOYED AWAITING ORDERS — sont plus difficiles à détecter et plus lourdes de conséquences que les erreurs syntaxiques.

Évolution et gouvernance de NCIM

NCIM est maintenu par le Conseil C3 de l'OTAN (C3B), l'organe de gouvernance de l'Alliance pour les normes des systèmes de communications et d'information. Le C3B fonctionne à travers une structure de groupes de travail : le C2 Information Exchange Working Group (C2IEWG) est l'organe responsable de la maintenance de NCIM, avec la participation des ministères de la défense des nations OTAN, des agences nationales TIC de défense et de représentants de l'industrie via le processus du forum industriel de l'OTAN.

Le cycle de vie des normes NCIM suit le processus normatif de l'Alliance : une proposition de changement est soumise au C2IEWG avec une justification et une évaluation d'impact ; le groupe de travail examine la proposition au regard de la cohérence avec les normes dépendantes (puisque un changement de NCIM se répercute sur MIP4, ADatP-34 et C-BML, l'évaluation d'impact doit couvrir les trois) ; après approbation du groupe de travail, la proposition entre dans une période de commentaire des nations membres ; et après résolution des commentaires, le changement est inclus dans la révision NCIM suivante et publié via la NCIA. Les incréments de version majeure (NCIM 2.x vers 3.x) ont des délais de plusieurs années en raison de l'impact en cascade sur les normes de mise en œuvre ; les révisions mineures au sein d'une version majeure sont publiées annuellement.

Le mécanisme de profils est l'outil principal pour des extensions propres à une mission sans altérer le modèle de base. Un profil est une vue contrainte ou étendue de NCIM, formellement définie, pour un domaine ou un type de mission spécifique. Les profils sont publiés par le C3B comme annexes de NCIM après avoir suivi le même processus d'examen et d'approbation que les changements du modèle de base. L'avantage du mécanisme de profils est que les exigences propres à une mission peuvent être satisfaites — ajouter des attributs de type de navire pour un profil C2 maritime, ou des attributs de contact de guerre électronique pour un profil d'image EW — sans gonfler le modèle de base ni créer d'incompatibilités entre systèmes qui mettent en œuvre des profils différents. Les systèmes qui mettent en œuvre plusieurs profils doivent gérer l'union de leurs jeux de types d'entités et traiter élégamment le cas où un système partenaire ne met en œuvre qu'un sous-ensemble des profils utilisés.

Le NATO Interoperability Test Toolkit (NITT) est l'outil principal pour valider la conformité des mises en œuvre fondées sur NCIM. NITT contient des scripts de test organisés par type d'entité NCIM et par scénario d'échange (échange bilatéral de l'image terrestre, distribution d'OPORD, rapport de statut logistique). Chaque script de test spécifie les instances d'entités NCIM exactes qui doivent être échangées, le format de sérialisation et les assertions qui doivent tenir côté récepteur. Les résultats NITT sont la principale entrée des évaluations de préparation à CWIX : les systèmes qui échouent à NITT pour un scénario ne sont pas autorisés pour ce scénario à CWIX.

Pour les équipes de programme qui suivent l'évolution de NCIM, le conseil pratique est : abonnez-vous aux publications du C2IEWG via votre autorité nationale de normalisation de défense, examinez les changements proposés au stade de la proposition quant à leur impact sur votre couche d'adaptateurs (les changements sont bien moins coûteux à traiter avant leur approbation), et traitez l'alignement des versions NCIM comme un point contractuel dans les accords d'exercices de coalition — spécifier la référence NCIM que tous les systèmes participants doivent mettre en œuvre prévient la dérive sémantique qui survient lorsque les partenaires sont sur des versions mineures différentes.

La trajectoire plus large de la gouvernance NCIM reflète le virage de l'Alliance vers des architectures orientées services et centrées données. L'évolution récente de NCIM s'est concentrée sur l'alignement avec le cadre de services FMN (Federated Mission Networking), la prise en charge explicite de la sérialisation JSON en plus du XML, et l'introduction de patterns de données liées (représentations RDF/OWL des types d'entités NCIM) qui soutiennent l'intégration web sémantique pour le partage de données alliées à travers les frontières de classification. Ces directions indiquent que NCIM continuera de croître en portée et en pertinence à mesure que l'infrastructure d'information C2 de l'OTAN se modernise — ce qui en fait une référence de plus en plus importante pour tous les programmes logiciels de défense visant l'interopérabilité en coalition.

Discutez de votre projet

Nous concevons et mettons en œuvre des couches de données conformes à NCIM et des adaptateurs d'intégration C2 de coalition pour des programmes de défense visant l'interopérabilité OTAN.

Développement C2 → Réserver un briefing

Cette analyse a été préparée par les ingénieurs de Corvus Intelligence, qui construisent des logiciels critiques pour la mission pour des organisations de défense et gouvernementales. Découvrez notre équipe →

Questions fréquentes

Qu'est-ce que le modèle d'information C2 de l'OTAN (NCIM) ?

NCIM est le modèle de données conceptuel et logique canonique de l'Alliance pour l'échange d'informations de commandement et de contrôle. Il définit les types d'entités, les relations et la sémantique des attributs qui fondent toutes les normes de données C2 de l'OTAN — dont MIP4, ADatP-34 et C-BML — en établissant un cadre d'information commun pour que les données échangées selon différentes normes OTAN soient interprétées sans ambiguïté par les partenaires de la coalition. NCIM ne définit pas les formats de transmission ; il se situe au-dessus des spécifications de niveau protocole comme référence sémantique partagée à laquelle les normes de mise en œuvre se raccordent.

Comment NCIM se rapporte-t-il à MIP4 et à ADatP-34 ?

NCIM est le modèle parent duquel dérivent à la fois MIP4 et ADatP-34. Le modèle de données de MIP4 — couvrant les types d'entités Unit, Equipment, Task et apparentés pour le C2 des forces terrestres — est un profil de NCIM restreint au domaine terrestre. Le catalogue de messages d'ADatP-34 structure ses champs selon la sémantique NCIM. Un développeur qui comprend la hiérarchie des types d'entités de NCIM peut naviguer dans MIP4 et ADatP-34 bien plus vite qu'en les traitant comme des normes indépendantes. La correspondance entre objets MIP4 et champs de messages ADatP-34 est très largement une affaire de parcours des relations NCIM.

Quels sont les types d'entités de premier niveau dans NCIM ?

NCIM définit six types d'entités de premier niveau : Activity (actions planifiées ou réelles, y compris tâches, missions et événements), OperationalObject (cibles, zones d'intérêt et contacts rapportés), Organisation (hiérarchies de commandement et unités organisationnelles), Resource (plateformes, ensembles d'équipements et personnel), Location (positions géographiques, zones, corridors et limites) et Plan (plans opérationnels, phases et les relations entre eux). Chaque entité d'un échange de données C2 OTAN remonte à exactement un de ces six types.

Quels formats de sérialisation NCIM prend-il en charge ?

NCIM lui-même est indépendant du format — c'est un modèle conceptuel, pas une spécification de sérialisation. Les normes de mise en œuvre définissent leurs propres sérialisations : MIP4-IES utilise XML avec une liaison JSON RESTful, ADatP-34 utilise le binaire VMF pour les liaisons radio héritées et la NATO XML Message Specification pour les réseaux IP, et C-BML utilise un format XML spécialisé. Lors de la construction d'un système C2 de coalition, l'implémentateur choisit la sérialisation adaptée au réseau cible et aux systèmes partenaires, mais toutes les sérialisations se raccordent aux mêmes entités NCIM sous-jacentes.

Comment les profils NCIM sont-ils utilisés pour des extensions propres à une mission ?

NCIM prend en charge un mécanisme de profils qui permet des extensions propres à une mission ou à un domaine sans altérer le modèle de base. Un profil spécifie une vue contrainte ou étendue de NCIM pour un cas d'usage particulier — par exemple, un profil C2 maritime ajoute des attributs propres aux navires au type d'entité Resource tout en laissant hors périmètre les attributs du domaine terrestre. Les profils sont formellement enregistrés auprès du Conseil C3 de l'OTAN et suivent un cycle de vie défini. Les équipes de mise en œuvre doivent identifier les profils NCIM approuvés qui s'appliquent à leur programme et ne mettre en œuvre que les attributs et types d'entités dans le périmètre.

Quelle est la différence entre les couches conceptuelle et logique de NCIM ?

NCIM est structuré en deux couches. La couche conceptuelle définit les types d'entités de haut niveau et leurs relations à l'aide de diagrammes de classes UML — elle répond à la question « quels types de choses existent dans une opération C2 OTAN ? ». La couche logique raffine chaque type d'entité en attributs avec des types de données définis, des contraintes de cardinalité et des références de domaines de valeurs — elle répond à « quelles données doivent être enregistrées sur chaque entité ? ». Les développeurs travaillent principalement avec la couche logique lors de la mise en œuvre des modèles de données ; les architectes système utilisent la couche conceptuelle pour vérifier l'équivalence sémantique entre les modèles de données de deux systèmes avant de tester l'échange de données.

Comment NCIM gère-t-il la localisation et la géométrie ?

Location est un type d'entité à part entière dans NCIM plutôt qu'un attribut d'autres entités. Une Unit n'a pas d'attribut coordonnée — elle a une relation vers une entité Location qui porte la coordonnée, l'estimation d'incertitude, la fenêtre de temps de validité et la source de la position. La même entité Location peut être référencée par plusieurs entités Activity, Organisation et Resource. Les types de géométrie incluent Point, Polyline, Polygon, Corridor et le GeometricExtent abstrait. Les systèmes de référence de coordonnées suivent ISO 19111 avec WGS-84 comme système de référence de base pour l'échange en coalition.

Qu'est-ce que C-BML et quel est son rapport avec NCIM ?

C-BML (Coalition Battle Management Language) est un langage XML pour exprimer des tâches, des ordres et des comptes rendus militaires sous forme exploitable par des machines, conçu pour permettre aux systèmes C2 d'analyser automatiquement un ordre et d'en extraire les tâches. Les structures de tâches et d'ordres de C-BML s'appuient sur les types d'entités Activity et Plan de NCIM, les éléments XML de C-BML correspondant directement aux attributs NCIM. Un système qui met en œuvre C-BML pour l'échange d'ordres et MIP4-IES pour l'échange de l'image terrestre utilise dans les deux cas la même sémantique NCIM sous-jacente, ce qui rend l'intégration de données entre protocoles considérablement plus tractable.

Comment la conformité de mise en œuvre de NCIM et les tests sont-ils organisés ?

La conformité NCIM est testée à travers les normes de mise en œuvre qui l'utilisent. L'exercice Coalition Warrior Interoperability de l'OTAN (CWIX) est le lieu principal où les mises en œuvre fondées sur NCIM sont testées les unes contre les autres. Le NATO Interoperability Test Toolkit (NITT) fournit des scripts de test automatisés pour les échanges MIP4-IES et C-BML qui vérifient la conformité sémantique vis-à-vis des définitions NCIM — et pas seulement la validité syntaxique du XML. Les programmes doivent participer à au moins un cycle CWIX pour démontrer la conformité opérationnelle ; un test de conformité national préalable est fortement recommandé.

Quel organe de gouvernance maintient NCIM et à quelle fréquence est-il mis à jour ?

NCIM est maintenu par le Conseil C3 de l'OTAN (C3B) à travers le C2 Information Exchange Working Group (C2IEWG), avec la participation des ministères de la défense des nations OTAN, des agences nationales TIC de défense et de représentants de l'industrie. Les incréments de version majeure ont des délais de plusieurs années en raison de l'impact en cascade sur MIP4, ADatP-34 et C-BML ; les révisions mineures sont publiées annuellement. Les équipes de mise en œuvre devraient s'abonner aux publications du C2IEWG via leur autorité nationale de normalisation de défense et traiter l'alignement des versions NCIM comme un point contractuel dans les accords d'exercices de coalition.

Comment NCIM gère-t-il la classification et les droits de diffusion des données ?

NCIM inclut un attribut Confidentiality sur chaque type d'entité, qui porte une étiquette de classification alignée sur les niveaux de classification OTAN (UNCLASSIFIED, NATO RESTRICTED, NATO CONFIDENTIAL, NATO SECRET, COSMIC TOP SECRET) et un indicateur de Releasability précisant quelles nations ou quels groupes peuvent recevoir l'entité. Ces attributs sont l'expression au niveau NCIM des étiquettes exigées par STANAG 4774 (Confidentiality Metadata Label) et STANAG 4778 (Metadata Binding). Lors de la sérialisation d'entités NCIM en XML pour un échange sur un réseau de coalition, la norme de sérialisation doit porter ces étiquettes à une position et dans un format permettant au système récepteur d'appliquer des filtres de diffusion avant tout transfert vers des systèmes partenaires. Un système qui supprime ou ignore les attributs de confidentialité NCIM est non conforme et présente un risque de divulgation d'informations.

NCIM peut-il être utilisé hors de l'OTAN — par exemple dans l'écosystème C2 de l'Ukraine ?

Oui, et c'est de plus en plus courant. Les nations non membres de l'OTAN mais opérant en coalition avec les forces de l'Alliance utilisent des normes dérivées de NCIM pour atteindre l'interopérabilité des échanges de données. Les programmes ukrainiens de technologies de défense, y compris des systèmes participant au cluster de technologies de défense Brave1, utilisent des interfaces MIP4-IES et ADatP-34 — qui mettent toutes deux en œuvre la sémantique NCIM — pour échanger des données opérationnelles avec des systèmes partenaires OTAN. L'implication pratique pour les développeurs hors OTAN est la même que pour les membres de l'Alliance : alignez le modèle de données interne sur les types d'entités et les relations NCIM, mettez en œuvre le profil pertinent pour la norme d'échange visée, et validez à CWIX ou lors d'un événement d'interopérabilité d'une nation partenaire.

Quels outils sont disponibles pour travailler avec les schémas et modèles NCIM ?

Le jeu d'outils principal pour le travail NCIM est le NATO Interoperability Test Toolkit (NITT), qui comprend des validateurs de schémas, des générateurs de messages et des séquences de test automatisées pour MIP4-IES et C-BML. Pour le travail sur le modèle de données, le modèle UML de NCIM est publié au format XMI et peut être chargé dans des outils de modélisation basés sur Eclipse ou dans Sparx Enterprise Architect pour la navigation et l'analyse de lacunes. Les définitions XML Schema des formats d'échange fondés sur NCIM sont distribuées via le dépôt de normes de la NCIA. Des outils commerciaux de Systematic (SitaWare), General Dynamics Mission Systems et Thales intègrent des couches de données conformes à NCIM et peuvent servir de mises en œuvre de référence pour le développement d'adaptateurs — bien que leurs API soient propriétaires, les structures de données observables qu'ils échangent doivent être conformes à la sémantique NCIM et peuvent servir de référence de vérité pour la conformité.