Standardisation du modèle de données C2 : pourquoi les schémas propriétaires fragmentent la connaissance de l'espace de bataille

Deux unités alliées occupent des secteurs adjacents. Toutes deux disposent de systèmes C2 modernes alimentant des pistes vers une image opérationnelle partagée. Mais l'image partagée est incomplète : les systèmes d'une nation rapportent les identifiants d'unité sous forme de désignateurs NATO STANAG 2019, l'autre sous forme de codes alphanumériques nationaux. L'une encode la localisation en MGRS, l'autre en degrés décimaux WGS-84. L'une horodate les événements en UTC avec une résolution à la milliseconde ; l'autre utilise l'heure locale avec une résolution à la seconde. Le résultat est qu'une piste créée dans un système n'apparaît pas dans l'autre ou y apparaît comme un doublon avec une position contradictoire. Ce n'est pas un problème de réseau. C'est un problème de schéma, et il se manifeste dans chaque opération de coalition où les systèmes C2 ont été acquis indépendamment. Cet article examine les racines techniques de cette fragmentation et les approches de standardisation qui y répondent -- en commençant par les décisions fondatrices de modèle de données qui déterminent si un système C2 peut interopérer tout court.

Le coût des modèles de données propriétaires dans les opérations de coalition

Chaque grand exercice de coalition depuis les années 1990 a produit des comptes rendus de retour d'expérience citant des échecs de partage de données qui remontent directement à l'incompatibilité des schémas. Le schéma est constant : chaque nation acquiert un système C2 selon ses propres exigences, le fournisseur implémente un modèle de données propriétaire optimisé pour la doctrine et la structure de force de cette nation, et le système fonctionne bien lors des exercices nationaux. Les problèmes surgissent dès l'instant où deux systèmes de ce type ou plus doivent partager une image opérationnelle commune. Les champs qui représentent des concepts logiquement identiques -- le statut opérationnel d'une unité, la position rapportée d'une piste, la priorité assignée à une tâche -- sont encodés différemment dans chaque schéma propriétaire. Convertir de l'un à l'autre nécessite une couche de traduction qu'aucun fournisseur n'avait initialement prévue et qui doit être ré-élaborée pour chaque nouvel appariement de systèmes.

Le coût opérationnel s'accumule de deux manières. La première est la latence : chaque étape de traduction qui ne peut pas être automatisée ajoute du temps à la boucle capteur-tireur. Une piste qui met 45 secondes à se propager d'un nœud capteur à l'affichage d'un commandant allié est tactiquement inutile dans un engagement à évolution rapide. Le second coût est la perte de fidélité : les champs qui n'ont aucun équivalent dans le schéma de destination sont supprimés en silence. Un statut opérationnel codé « TACON » (contrôle tactique) dans un système devient un champ vide ou un indicateur générique « actif » dans un autre, privant le commandant récepteur d'une information qui était présente dans la source. Sur un grand exercice ou une grande opération, cette perte de données accumulée dégrade la connaissance de la situation de façons difficiles à mesurer mais significatives sur le plan opérationnel.

Le coût économique est également substantiel. Les estimations issues des programmes multinationaux d'intégration C2 montrent systématiquement que les couches de traduction bilatérales sur mesure -- construites une fois par paire de systèmes, maintenues séparément pour chaque mise à niveau de version -- représentent 20 à 40 % du budget total d'intégration d'un programme C2 de coalition. Ces ressources sont consacrées à un travail qui ne produit aucune nouvelle capacité : elles compensent simplement l'absence d'un schéma partagé.

Standards établis : JC3IEDM, APP-6, MIP Data Model -- couverture et lacunes

Le Multilateral Interoperability Programme (MIP) a produit les standards de modèle de données les plus largement adoptés pour le C2 de coalition. JC3IEDM (Joint Command, Control and Consultation Information Exchange Data Model), ratifié comme standard ISO, définit un schéma relationnel normalisé couvrant les unités, les équipements, les installations, les actions, les plans et leurs relations opérationnelles. Sa structure entité-relation a été conçue pour l'échange base de données à base de données, où les deux systèmes maintiennent des copies des mêmes tables relationnelles et synchronisent les changements via un protocole de réplication défini. JC3IEDM a connu une adoption significative au milieu des années 2000 comme schéma canonique pour l'intégration C2 de coalition, en particulier dans les programmes impliquant plusieurs forces terrestres européennes.

APP-6 (NATO Military Symbols for Land Based Systems) aborde un problème plus restreint : comment représenter de manière cohérente les icônes d'unités militaires et leurs attributs sur les affichages alliés. APP-6D définit une structure de code d'identification de symbole (SIDC), une hiérarchie de types d'unités depuis le niveau d'échelon jusqu'au type d'équipement, et des modificateurs standard pour le statut, la taille et l'affiliation. Bien qu'APP-6 soit strictement un standard de symbologie plutôt qu'un modèle de données complet, il définit les ensembles d'énumérations sur lesquels un modèle de données C2 doit s'appuyer pour représenter les types d'unités sans ambiguïté. Un système C2 qui utilise les SIDC APP-6 comme identifiant canonique de type d'unité peut échanger la symbologie d'unité avec tout système allié qui fait de même, sans aucune traduction d'énumération.

Le MIP Data Model (MIM), successeur de JC3IEDM, adopte une structure de modèle objet fondée sur UML qui se rattache plus directement aux schémas d'échange orientés message des architectures C2 modernes. Plutôt que d'exiger un accès partagé à la base de données, le MIM définit un binding XML qui permet aux systèmes conformes d'échanger des données via des transports standard. Le MIM introduit également un versionnement formel et une structure modulaire de groupes de concepts qui simplifie le processus d'extension. Toutefois, le MIM conserve une complexité importante : le modèle d'information complet contient plusieurs centaines de classes de concepts, et implémenter une interface MIM conforme exige encore des mois d'ingénierie d'intégration. Les extensions nationales -- que chaque nation implémentatrice a ajoutées -- signifient que deux systèmes conformes au MIM peuvent malgré tout échouer à échanger des données correctement si l'un utilise une extension nationale que l'autre n'a pas implémentée.

Comment la divergence des schémas crée de la latence dans les boucles capteur-tireur

Le chemin allant d'une détection par capteur à une piste exploitable sur un affichage allié passe par plusieurs étapes de transformation de données, et la divergence des schémas peut injecter des délais à chacune d'elles. Considérons un radar terrestre qui détecte une piste de véhicule et la rapporte à son système C2 national. Le système C2 stocke la piste dans son schéma propriétaire, puis tente de la partager avec un système allié via une liaison de coalition. Si la liaison de coalition utilise un format d'échange défini (tel qu'un message Link 16 de la série J ou une instance XML MIM), le système C2 national doit d'abord traduire son schéma interne vers le format d'échange. Si cette traduction n'est pas implémentée correctement -- ou si le schéma national porte des champs qui n'ont aucun équivalent dans le format d'échange -- l'étape de traduction échoue en silence ou perd des données.

Du côté récepteur, le système C2 allié doit traduire le format d'échange entrant vers son propre schéma interne. Si le système récepteur utilise une version différente du standard d'échange, ou a ajouté des extensions nationales que l'expéditeur ne renseigne pas, la piste reçue peut être stockée avec des champs manquants ou aux valeurs par défaut. Une position de piste qui arrive au format MGRS mais est stockée en interne en UTM ne sera convertie correctement que si la logique de conversion gère tous les cas limites de zones UTM -- une exigence qui paraît triviale mais a causé de réelles erreurs dans des systèmes déployés près des limites de zones. Chacune de ces étapes de traduction prend du temps : une traduction automatisée bien implémentée ajoute des millisecondes ; une mauvaise, qui doit mettre en file d'attente des enregistrements incertains pour revue humaine, peut ajouter des minutes.

L'effet cumulatif est que la latence induite par les schémas dans une chaîne C2 de coalition à sauts multiples -- capteur vers système national, système national vers passerelle de coalition, passerelle de coalition vers système national allié, système allié vers affichage -- peut facilement atteindre 30 à 90 secondes pour une piste qui devrait se propager en moins de deux secondes. Pour les cibles à intérêt temporel et les menaces à délai critique, c'est la différence entre une piste utile et un enregistrement historique. Comme évoqué dans le contexte de la justification de conception du format Cursor on Target, les formats d'échange les plus efficaces sont ceux qui minimisent la distance de traduction entre le schéma source et le format de transmission.

Les ontologies OWL/RDF comme voie vers l'interopérabilité sémantique

Les modèles de données relationnels et fondés sur UML comme JC3IEDM et le MIM définissent la structure -- quels champs existent et comment ils se relient -- mais ne définissent pas le sens sous une forme sur laquelle les machines peuvent raisonner. Deux champs nommés différemment dans deux schémas peuvent représenter le même concept ; deux champs nommés à l'identique peuvent représenter des concepts subtilement différents. Détecter et résoudre ces équivalences et distinctions sémantiques nécessite soit une expertise humaine, soit une couche sémantique formelle qui rend les relations lisibles par la machine. OWL (Web Ontology Language) et RDF (Resource Description Framework) fournissent cette couche.

Une ontologie OWL pour les données C2 militaires peut représenter la taxonomie d'entités JC3IEDM sous forme de hiérarchie de classes avec des relations de subsomption formelles. Elle peut affirmer qu'« ARMD-REGT » (un régiment blindé dans la taxonomie de types d'unités de JC3IEDM) est une sous-classe de « LAND-UNIT », elle-même sous-classe de « MILITARY-UNIT ». Un système consommateur qui ne connaît que le concept « MILITARY-UNIT » peut tout de même traiter correctement un enregistrement entrant typé « ARMD-REGT » parce que les axiomes de subsomption de l'ontologie indiquent au moteur d'inférence que tout « ARMD-REGT » est un « MILITARY-UNIT ». Cette capacité d'inférence est particulièrement précieuse pour gérer les extensions nationales aux taxonomies standard : un type d'extension défini par le système C2 d'une nation peut être mappé vers la classe parente standard la plus proche dans l'ontologie partagée, permettant aux systèmes consommateurs qui ne connaissent pas l'extension de la traiter avec grâce plutôt que de rejeter l'enregistrement.

L'adoption pratique d'OWL/RDF dans les systèmes C2 opérationnels a été limitée par des préoccupations de performance et d'outillage. Le raisonnement OWL sur de grands jeux de données opérationnels est coûteux en calcul, et la latence de raisonnement est incompatible avec le traitement de pistes en temps réel. L'approche la plus pratique consiste à utiliser les ontologies OWL au moment de la conception pour vérifier et générer les règles de traduction qui sont ensuite compilées en code d'exécution efficace -- en utilisant la sémantique formelle de l'ontologie pour détecter les erreurs de mappage avant le déploiement plutôt que pendant les opérations. Plusieurs programmes de recherche NATO ont démontré cette approche, produisant des jeux de règles de traduction dérivés d'ontologies qui surpassent les mappages écrits à la main en complétude comme en exactitude.

Schémas de passerelle API pour la traduction de schéma à l'exécution

Quel que soit le modèle de données canonique choisi, le défi pratique est d'exécuter la traduction de schéma à la vitesse exigée par l'environnement opérationnel. Un schéma de passerelle API -- un service de traduction placé entre chaque système source et le bus de schéma canonique -- fournit la solution la plus éprouvée sur le plan opérationnel. L'intégration de chaque système source est encapsulée dans un adaptateur dédié qui traduit, en temps réel, du schéma natif de ce système vers le schéma canonique. L'adaptateur est le seul composant qui doit connaître le format propriétaire du système source ; tous les autres composants de l'architecture C2 de coalition ne parlent que le schéma canonique.

Le registre de schémas est le composant d'infrastructure critique qui rend le schéma de passerelle API maintenable à grande échelle. Chaque version de schéma -- tant pour les systèmes source que pour le modèle canonique -- est enregistrée avec un identifiant de version. Chaque règle de traduction est étiquetée avec la paire (version-source, version-cible) spécifique à laquelle elle s'applique. Lorsqu'un système source met à niveau son schéma, seul l'adaptateur de ce système doit être mis à jour ; le schéma canonique et tous les autres adaptateurs ne sont pas affectés. Le registre de schémas sert aussi de piste d'audit : chaque enregistrement qui transite par la couche de traduction porte des métadonnées de provenance -- identifiant du système source, version du schéma source, version de la règle de traduction, horodatage -- qui permettent l'investigation a posteriori de tout problème de qualité de données.

Pour les environnements de coalition où le schéma canonique est lui-même soumis à des extensions nationales, la passerelle API doit aussi gérer le sens inverse : traduire du schéma canonique vers le schéma propriétaire d'un système national pour consommation. Cette exigence de traduction bidirectionnelle double le jeu de règles de traduction et introduit le défi supplémentaire de représenter les champs canoniques qui n'ont aucun équivalent dans le schéma national de destination. L'approche standard consiste à encoder ces champs dans un blob d'extension structuré attaché à l'enregistrement de destination, préservant les données pour toute mise à niveau future du système de destination tout en garantissant que le système actuel peut tout de même ingérer l'enregistrement sans erreurs. Le choix de l'architecture du bus de messagerie affecte directement la propreté avec laquelle ces blobs d'extension peuvent être attachés et transmis.

Gouvernance : qui possède le modèle de données canonique dans une coalition

Les solutions techniques à l'interopérabilité des schémas sont nécessaires mais non suffisantes. Tout programme réussi de standardisation de modèle de données de coalition a exigé une structure de gouvernance définissant qui peut proposer des changements au schéma canonique, qui les approuve, comment les extensions nationales sont enregistrées et partagées, et quel est le processus de résolution des conflits entre exigences nationales. Sans gouvernance, le schéma canonique dérive : l'équipe d'intégration de chaque nation apporte des modifications locales pour accommoder les exigences de son système, les modifications ne sont jamais reportées vers le standard partagé, et en deux ans le schéma « canonique » compte autant de variantes qu'il y a de nations implémentatrices.

Le modèle de gouvernance du MIP offre une référence utile. Le MIP fonctionne via un comité de programme composé de représentants nationaux, un comité de contrôle de configuration qui examine et approuve les changements de schéma, et un cycle de publication publié avec des engagements de rétrocompatibilité définis. Les changements au schéma de base requièrent un consensus multinational ; les extensions nationales sont autorisées mais doivent être enregistrées dans un registre d'extensions partagé et examinées en vue d'une éventuelle incorporation au schéma de base à chaque cycle de publication. Ce modèle de gouvernance a soutenu JC3IEDM et le MIM pendant plus de deux décennies d'usage opérationnel dans des dizaines de nations implémentatrices, ce qui prouve que le modèle est viable même sous les contraintes de coordination d'un programme multinational.

Pour les coalitions plus petites ou les programmes bilatéraux qui ne peuvent pas soutenir une structure de gouvernance à l'échelle du MIP, une alternative plus légère est un rôle désigné de gardien du modèle de données au sein de l'une des organisations participantes, avec un processus formel de demande de changement qui exige l'aval de tous les propriétaires de systèmes affectés avant tout déploiement de changement de schéma. L'exigence clé est que le processus de gestion du changement soit documenté et suivi avec cohérence -- un changement non documenté du schéma canonique qui casse l'adaptateur de traduction d'une nation sans avertissement est exactement le genre d'événement qui érode la confiance dans le programme de standardisation et renvoie les nations vers des solutions bilatérales sur mesure.

Migration incrémentale : envelopper les systèmes hérités sans les réécrire

La plupart des efforts de standardisation de modèle de données C2 affrontent la même contrainte : les systèmes hérités qui doivent interopérer ne peuvent pas être réécrits. Ils ont été acquis sous des contrats à long terme, ils portent des années de personnalisation opérationnelle, et leurs échéances de remplacement se mesurent en décennies. Toute approche de standardisation exigeant une réécriture complète du système ne sera pas mise en œuvre. La seule voie viable est la migration incrémentale par couches d'adaptateurs -- un schéma « strangler fig » appliqué à l'intégration C2 militaire.

L'approche « strangler fig » fonctionne comme suit. Un adaptateur de traduction est déployé aux côtés du système hérité. L'adaptateur expose un point d'extrémité API conforme aux standards -- parlant le schéma canonique -- à tous les consommateurs externes. En interne, l'adaptateur lit la base de données ou le bus de messages du système hérité, applique les règles de traduction au niveau des champs documentées lors de l'audit de schéma, et publie des messages conformes au schéma canonique vers le courtier partagé. Les systèmes externes s'intègrent à l'interface canonique de l'adaptateur, jamais directement au schéma hérité. Le système hérité continue de fonctionner sans changement. Au fil du temps, à mesure que les sous-systèmes fonctionnels individuels au sein de la plateforme héritée atteignent leur fin de vie, ils peuvent être remplacés par de nouvelles implémentations qui parlent nativement le schéma canonique, et les règles de traduction correspondantes dans l'adaptateur sont retirées. À terme, l'adaptateur peut être retiré entièrement, mais les interfaces externes sont restées stables tout du long.

Les défis pratiques de cette approche se concentrent sur l'étape d'audit de schéma. Les systèmes C2 hérités ont fréquemment des champs non documentés, des conventions implicites encodées dans la logique applicative plutôt que dans le schéma, et des problèmes de qualité de données que l'adaptateur de traduction doit gérer avec grâce -- chaînes tronquées, valeurs numériques hors plage, champs nuls qui ne devraient jamais l'être. Un adaptateur de traduction robuste doit inclure une logique de validation et d'assainissement qui détecte ces problèmes à la frontière et soit les corrige (pour les cas bien compris comme les espaces de fin ou une casse incorrecte), soit les journalise pour revue humaine (pour les cas où l'interprétation correcte est ambiguë). Construire cette logique de validation nécessite un accès direct aux données du système hérité pendant une période d'exécution en mode fantôme -- l'adaptateur tournant en parallèle du chemin d'échange existant et comparant les sorties champ par champ jusqu'à ce que le taux de concordance sur les champs critiques sur le plan opérationnel soit suffisamment élevé pour justifier la bascule.