Gestion des données maîtres pour la défense : résolution d'entités, golden record et cohérence entre systèmes

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

26 juin 2026 12 min de lecture

Un officier logistique de niveau bataillon demande un rapport de disponibilité opérationnelle. Le système C2 recense 47 véhicules affectés à l'unité. Le système de comptabilité des matériels en enregistre 51 sous le même identifiant d'unité. Le système de maintenance suit 44 de ces véhicules sous des formats de numéro de série différents, et trois sont signalés comme immobilisés sous des identifiants qui n'apparaissent dans aucun des deux autres systèmes. Personne ne peut répondre à la question « combien de véhicules opérationnels cette unité possède-t-elle en ce moment ? » sans passer un coup de téléphone — car les mêmes entités physiques sont représentées par des enregistrements différents, des identifiants différents et des valeurs d'attributs différentes dans des systèmes qui n'ont jamais été conçus pour concorder entre eux.

Voilà le problème du MDM de défense dans sa forme la plus courante. La gestion des données maîtres (MDM) est la discipline qui crée une représentation unique faisant autorité de chaque entité centrale — personne, organisation, équipement, lieu — à laquelle tous les systèmes se réfèrent de façon cohérente. Ce n'est ni un outil de reporting ni un entrepôt de données. C'est la couche qui rend les jointures entre systèmes pertinentes, les analyses multi-domaines dignes de confiance et les décisions opérationnelles fondées sur les données fiables. Cet article couvre l'architecture d'un système MDM de défense, du choix du modèle de hub à la résolution d'entités, à la construction des golden records, aux workflows de stewardship et aux exigences de survivabilité qui rendent le MDM viable dans des environnements contestés.

Le problème du MDM de défense — des enregistrements d'équipements dans trois systèmes avec trois identifiants différents, des enregistrements de personnel qui divergent entre HR et C2, le coût de l'incohérence

Les organisations de défense accumulent de manière organique une fragmentation des sources de vérité. Le système de ressources humaines (HR) a été acquis pour gérer l'administration du personnel. Le système C2 a été conçu pour suivre la structure des unités et les affectations tactiques. Le système logistique a été conçu pour gérer l'approvisionnement et la comptabilité des matériels. Chacun a été conçu par un bureau de programme différent, déployé dans une décennie différente et repose sur un modèle de données différent. Aucun n'a été conçu pour interopérer avec les autres au niveau de l'identité des entités.

Il en résulte un ensemble de schémas d'identifiants incompatibles par conception. Une personne peut être identifiée par son matricule dans le système HR, par la combinaison de son code de spécialité militaire et de son grade dans le système C2, et par son identifiant de détenteur de matériel dans le système logistique — trois identifiants pour un seul être humain, sans aucune correspondance maintenue par un système entre eux. Pour les équipements, c'est pire : un char M1A2 peut porter un numéro tactique (bumper number) peint au pochoir sur la caisse (utilisé par l'équipage et les opérateurs C2), un code d'adresse d'activité du Department of Defense dans le système logistique, un code-barres d'identifiant unique d'article (UII) dans la comptabilité des matériels et un numéro d'ordre de travail de maintenance dans le système de gestion de la maintenance. Aucun de ces identifiants n'a le même format, et les systèmes qui les utilisent n'ont pas été conçus pour traduire de l'un à l'autre.

Le coût de cette incohérence ne se limite pas à un simple désagrément. Lorsqu'un analyste de la disponibilité opérationnelle joint les données d'affectation d'unités du C2 aux données d'approvisionnement logistique pour calculer le score de capacité opérationnelle d'une unité, la jointure ne parvient pas à apparier les enregistrements qui désignent le même équipement physique sous des identifiants différents. Le score de capacité obtenu est faux — et il est faux dans un sens que l'analyste ne peut pas détecter sans vérifier indépendamment chaque système, ce qui annule l'intérêt du modèle analytique. Pour une vue d'ensemble de la manière dont ces défaillances d'intégration se manifestent dans l'architecture de données au sens large, consultez notre traitement des modèles d'intégration des données de défense.

La divergence des enregistrements de personnel entre les systèmes HR et C2 est un problème supplémentaire et distinct. Le système HR tient le dossier administratif : grade permanent, poste occupé, unité d'affectation, niveau d'habilitation, historique de formation. Le système C2 tient la situation opérationnelle : quelle personne est physiquement présente dans quelle unité, quel rôle elle remplit dans l'articulation opérationnelle actuelle, sur quels systèmes elle est habilitée à opérer. En situation stable de garnison, ces enregistrements concordent raisonnablement bien. Pendant les opérations — lorsque du personnel est rattaché à d'autres unités, lorsque l'articulation opérationnelle s'écarte du tableau d'organisation et d'équipement (TO&E), lorsque des affectations temporaires créent des rattachements secondaires — les deux enregistrements divergent rapidement. Un système MDM qui gère l'entité personne doit réconcilier les représentations administrative et opérationnelle en un golden record cohérent, utile à la fois pour l'établissement des rapports de disponibilité opérationnelle et pour la planification opérationnelle.

Architecture du hub MDM — modèles de hub registre, consolidation et coexistence, critères de choix pour les environnements de défense, placement du hub pour les données classifiées et non classifiées

Trois modèles de hub dominent les déploiements MDM en production, chacun ayant une relation distincte avec les systèmes sources qu'il dessert et un ensemble différent de compromis opérationnels qui comptent dans les environnements de défense.

Le modèle de registre ne stocke que la table de références croisées — une correspondance entre chaque identifiant de système source et l'identifiant d'entité global attribué par le MDM — sans répliquer ni stocker aucun attribut d'entité dans le hub lui-même. Lorsqu'un consommateur a besoin de données d'entité, il interroge le hub pour obtenir l'identifiant global, puis interroge les systèmes sources appropriés à l'aide des identifiants propres à chaque source renvoyés par les références croisées. Le modèle de registre a l'empreinte de données la plus faible et ne nécessite aucune synchronisation des données d'attributs vers le hub, ce qui le rend attrayant pour les environnements où la réplication de données classifiées vers un emplacement central pose des problèmes d'autorisation. Sa limite est qu'il oblige chaque consommateur à résoudre les entités sur plusieurs systèmes sources au moment de la requête, ce qui est opérationnellement irréaliste pour des requêtes opérationnelles à haute fréquence.

Le modèle de consolidation copie et normalise les attributs d'entité de tous les systèmes sources contributeurs vers le hub, exécute la résolution d'entités pour rattacher les doublons et sert aux consommateurs une vue d'entité unifiée. Les systèmes sources ne sont pas modifiés — le hub est un consommateur des données sources optimisé pour la lecture, et non un système qui réécrit dedans. Ce modèle est le plus pratique pour les environnements de défense, car il ne nécessite pas de droits de modification sur les systèmes sources (les systèmes C2, HR et logistiques ne sont généralement pas modifiables par le programme MDM) et il concentre le calcul de la résolution d'entités dans le hub plutôt que de le répartir entre les consommateurs. L'architecture d'un data lake militaire consomme généralement les golden records du hub de consolidation MDM comme couche de référence consolidée (curated), plutôt que de joindre directement les tables sources brutes.

Le modèle de coexistence ajoute au modèle de consolidation une capacité de réécriture (write-back) : le hub construit le golden record, puis propage les valeurs d'attributs faisant autorité vers les systèmes sources, en écrasant les valeurs maintenues localement par la valeur faisant autorité déterminée par le hub. Ce modèle produit la cohérence la plus forte entre les systèmes, mais exige que chaque système source participant accepte les écritures initiées par le hub — une exigence fréquemment bloquée par les contraintes d'autorisation des systèmes, les processus de contrôle des changements des fournisseurs et l'aversion au risque opérationnel sur les systèmes en production.

Le placement du hub pour les données classifiées et non classifiées exige des instances de hub distinctes à chaque frontière de classification. Un hub MDM unique traitant à la fois des données d'entités classifiées et non classifiées devrait fonctionner au niveau de classification le plus élevé, ce qui empêcherait les consommateurs non classifiés d'accéder à la moindre donnée d'entité du hub — et irait à l'encontre de son objectif. L'architecture pratique déploie un hub non classifié pour les entités qui existent entièrement dans des systèmes sources non classifiés (données de référence générales, données de lieux non classifiées, enregistrements de fournisseurs commerciaux) et un hub classifié, au niveau de classification approprié, pour les entités portant des attributs classifiés. La résolution d'entités entre niveaux de classification — déterminer qu'une entité du système non classifié correspond à la même entité physique dans un système classifié — exige une passerelle spécialisée de solution inter-domaines (cross-domain solution guard) qui ne transporte à travers la frontière de classification que la référence croisée des identifiants, jamais les attributs classifiés eux-mêmes.

Types d'entités dans le MDM de défense — personne (personnel militaire), organisation (unité/commandement), équipement (plateforme/article fini), lieu (infrastructure/position)

Le MDM de défense gère quatre grands domaines d'entités, chacun avec ses propres systèmes sources, schémas d'identifiants, structures d'attributs et défis de qualité des données.

Le domaine de l'entité personne couvre le personnel militaire, les prestataires et les partenaires de coalition. Les principaux systèmes sources sont le système de gestion du personnel (dossier administratif, affectation permanente, grade), le système C2 (affectation opérationnelle actuelle, position dans l'articulation opérationnelle) et le système de gestion des habilitations (niveau d'habilitation, autorisations de compartiments, dates d'expiration des accès). La principale difficulté d'identification tient à ce qu'une même personne peut apparaître sous son unité d'affectation permanente dans le système HR tout en étant rattachée opérationnellement à une autre unité dans le C2 — les deux enregistrements sont corrects dans leurs systèmes respectifs, mais ils représentent deux états opérationnels différents de la même entité. La construction du golden record pour le domaine des personnes doit capturer les états administratif et opérationnel comme des groupes d'attributs distincts, plutôt que de les réduire à un seul champ d'affectation d'unité.

Le domaine de l'entité organisation couvre les unités, commandements, sous-unités et task forces. Dans les environnements de défense, les organisations ont une structure hiérarchique parent-enfant (la brigade contient des bataillons, le bataillon contient des compagnies) et une dimension temporelle (les task forces sont créées, fusionnent, se réorganisent et se dissolvent à l'échelle de temps des opérations). Le système MDM doit maintenir la hiérarchie organisationnelle actuelle, ses états historiques à des horodatages passés, et les relations entre la structure administrative du TO&E et l'articulation opérationnelle actuelle. Les systèmes sources sont la hiérarchie des unités dans le système C2, le TO&E dans le système de gestion du personnel et l'enregistrement de l'élément de commandement dans les systèmes logistiques.

Le domaine de l'entité équipement couvre les plateformes, véhicules, systèmes d'armes et inventaires d'articles finis. C'est, en pratique, le domaine le plus fragmenté en matière d'identifiants : un même objet physique porte généralement quatre schémas d'identifiants distincts, ou davantage, selon les systèmes qui le gèrent. L'UII (identifiant unique d'article) est le code-barres mondialement unique, standard du Department of Defense, pour les équipements sérialisés ; il devrait servir d'identifiant maître du domaine des équipements, mais les systèmes hérités antérieurs à la norme UII utilisent des identifiants propriétaires qui nécessitent une table de correspondance pour être reliés à l'espace UII. L'appariement entre systèmes exige un appariement flou sur les champs de numéro de série, qui peuvent comporter des caractères séparateurs différents, des zéros de tête ou des préfixes de code constructeur selon le système qui a enregistré l'identifiant.

Le domaine de l'entité lieu couvre les infrastructures, installations, zones d'intérêt nommées et positions tactiques. L'appariement des lieux est fondamentalement un problème géospatial : un même lieu physique peut être référencé par des coordonnées MGRS dans un système, par des coordonnées géographiques en degrés décimaux dans un autre et par un toponyme en langage naturel dans un troisième. Le blocage géospatial regroupe les enregistrements de lieux candidats par proximité à l'aide d'une grille geohash, et l'appariement détermine si deux enregistrements spatialement proches désignent la même infrastructure ou des lieux distincts voisins. Les entités lieu ont aussi une dimension temporelle — la classification de l'infrastructure, son statut opérationnel et la force qui la contrôle évoluent avec le temps — ce qui impose au golden record de porter des intervalles de validité temporelle pour les principaux attributs de lieu. La couche de fusion du renseignement en temps réel qui met en corrélation les détections ISR avec des lieux connus dépend directement de l'exactitude et de l'exhaustivité de la table maître des entités lieu.

Résolution d'entités : appariement entre systèmes sources — stratégies de blocage pour les grands ensembles d'entités de défense, modèles d'appariement par ML, appariement déterministe et probabiliste

La résolution d'entités est le processus qui détermine quels enregistrements, répartis entre plusieurs systèmes sources, désignent la même entité du monde réel et les rattache à un identifiant global commun. À l'échelle d'un grand jeu de données de défense — des millions d'enregistrements d'équipements répartis entre des systèmes de logistique, de maintenance et de comptabilité des biens ; des centaines de milliers d'enregistrements de personnel répartis entre des systèmes RH, de C2 et d'habilitation — la comparaison naïve par paires de chaque enregistrement avec tous les autres est irréalisable sur le plan du calcul. Le pipeline d'appariement doit être structuré en deux étapes : le blocage, qui ramène l'espace des paires candidates à une taille traitable, puis l'appariement, qui évalue les paires candidates avec une précision suffisante pour distinguer les vrais appariements des quasi-correspondances.

Les stratégies de blocage pour les domaines d'entités de défense s'appuient sur des clés de partitionnement propres à chaque domaine afin de regrouper les enregistrements susceptibles de désigner la même entité. Pour les enregistrements de personnel, le blocage phonétique sur le champ du nom de famille, à l'aide de l'algorithme Soundex ou Double Metaphone, regroupe les enregistrements pour lesquels différents systèmes ont transcrit le même nom avec des graphies variantes, des espaces superflus ou des différences de trait d'union — autant de défauts courants dans les systèmes de gestion du personnel antérieurs à la normalisation Unicode. Pour les enregistrements d'équipements, le blocage par préfixe sur les six premiers caractères du numéro de série (après normalisation des espaces et de la casse) regroupe les enregistrements provenant de systèmes qui représentent un même numéro de série avec des conventions de séparateurs différentes. Pour les enregistrements de localisation, une grille geohash au niveau de précision 6 (cellules d'environ 1,2 km de large) regroupe les enregistrements spatialement proches tout en excluant les emplacements manifestement distincts. La conception du blocage doit être validée avant le déploiement sur un jeu de données étalon d'appariements connus : l'étape de blocage doit conserver au moins 95 % des paires appariées réelles dans l'ensemble candidat, faute de quoi le pipeline de résolution produira des erreurs d'omission systématiques pour les types d'enregistrements exclus.

Au sein de chaque bloc candidat, le modèle d'appariement évalue chaque paire :

L'appariement déterministe applique un ensemble de règles fixes qui produit une décision binaire d'appariement ou de non-appariement. Exemple de règle déterministe pour les enregistrements d'équipements : deux enregistrements correspondent si et seulement si leurs codes-barres UII sont identiques (après suppression des caractères non alphanumériques), ou si leurs numéros de série sont identiques et que leurs numéros de stock nationaux concordent jusqu'aux neuf premiers chiffres. Les règles déterministes ne nécessitent aucune donnée d'entraînement, sont entièrement auditables et ne produisent aucun faux positif lorsque la règle est correctement spécifiée. Elles conviennent aux attributs conçus pour être globalement uniques et maintenus sous des contrôles de saisie des données.
L'appariement probabiliste calcule un score d'appariement composite à partir de métriques de similarité pondérées au niveau des champs. Une comparaison d'enregistrements de personnel peut appliquer la similarité de Jaro-Winkler sur le prénom, un appariement phonétique sur le nom de famille, une correspondance exacte sur la date de naissance et un appariement approximatif sur l'abréviation du grade (pour gérer les variations de format), le tout combiné à un classifieur de type régression logistique ou arbres de décision à gradient boosté, entraîné sur des paires étiquetées appariées ou non appariées issues des systèmes sources réels. Le modèle entraîné apprend l'importance relative de chaque champ dans l'environnement spécifique de données « sales » — dans certains systèmes sources, la date de naissance est très fiable ; dans d'autres, son taux d'erreur de 3 % en fait un critère discriminant faible.
Les modèles d'appariement par apprentissage automatique (ML) prolongent l'appariement probabiliste par des représentations apprises du texte des attributs d'entité. Un réseau de neurones siamois entraîné sur des paires de noms de personnel apprend une représentation vectorielle des noms telle que des noms proches sur le plan phonétique ou orthographique ont des vecteurs proches — ce qui permet de capturer des motifs de similarité que les métriques de distance de chaînes conçues à la main ne détectent pas. Les modèles ML exigent des jeux de données étiquetés plus volumineux pour l'entraînement et sont plus difficiles à auditer que les règles déterministes, mais ils surpassent les modèles probabilistes classiques sur les ensembles d'entités très bruités, où les schémas d'erreurs de saisie sont complexes et non uniformes d'un système source à l'autre.

Pour chaque paire candidate, le pipeline d'appariement produit en sortie une décision d'appariement (appariement / non-appariement / revue) et un score de confiance. Les paires situées au-dessus du seuil d'appariement sont automatiquement rattachées à un identifiant global d'entité commun. Les paires de la zone de revue — celles dont le score de confiance se situe entre le seuil de non-appariement et le seuil d'appariement — sont orientées vers un data steward humain pour arbitrage, au lieu d'être résolues automatiquement.

Construction et maintenance de l'enregistrement de référence (golden record) — règles de survivance pour les attributs sources en conflit, score de confiance de l'enregistrement de référence, résolution automatisée ou assistée par un data steward

Une fois que la résolution d'entités a rattaché les enregistrements de plusieurs systèmes sources au même identifiant global d'entité, le système MDM construit l'enregistrement de référence : la représentation unifiée et faisant autorité de cette entité, dont les attributs proviennent, pour chaque champ, de la meilleure source disponible. L'enregistrement de référence n'est pas une simple fusion de tous les attributs sources — lorsque les sources divergent, une règle de survivance doit déterminer la valeur que porte l'enregistrement de référence.

Les règles de survivance sont définies par attribut et par domaine d'entités ; elles encodent la hiérarchie d'autorité applicable à cet attribut :

# Entité équipement — règles de survivance par attribut serial_number: source_priority=[property_acct, maintenance, logistics] national_stock_num: source_priority=[property_acct, logistics] unit_assignment: source_priority=[c2_system, logistics] maintenance_status: source_priority=[maintenance, logistics] condition_code: source_priority=[maintenance, property_acct] location_mgrs: most_recent_update # C2 ou logistique, selon la source mise à jour en dernier end_item_code: source_priority=[property_acct] # Source faisant autorité unique # Entité personnel — règles de survivance par attribut permanent_rank: source_priority=[hr_system] operational_unit: source_priority=[c2_system, hr_system] clearance_level: source_priority=[clearance_mgmt] duty_position: most_recent_update # RH ou C2 selon le type d'affectation name_legal: source_priority=[hr_system] name_preferred: most_complete # La source avec le moins de champs de nom nuls l'emporte
            

Chaque attribut de l'enregistrement de référence porte trois champs de métadonnées en plus de sa valeur : une référence de source (le système source qui a fourni cette valeur et l'identifiant de l'enregistrement source concerné), un horodatage de mise à jour (le moment où le système source a confirmé cette valeur pour la dernière fois) et un score de confiance (une valeur normalisée reflétant la fiabilité de la source et la qualité de l'appariement qui a rattaché cet enregistrement à l'entité de référence). Un score de confiance de 1,0 indique un appariement déterministe sur un identifiant globalement unique issu d'une source très fiable ; des scores plus faibles reflètent des résultats d'appariement probabilistes, des sources présentant des problèmes connus de qualité des données, ou des attributs dont la survivance a été contestée entre des sources aux valeurs contradictoires.

Le score de confiance n'est pas un simple ornement — il a une portée opérationnelle. Un analyste de la disponibilité opérationnelle qui élabore une évaluation de capacités peut filtrer la requête sur l'enregistrement de référence pour exclure les attributs situés sous un seuil de confiance, ou bien la couche analytique peut pondérer la contribution de chaque enregistrement d'équipement au score de disponibilité opérationnelle de l'unité par la confiance accordée à son attribut d'état de maintenance. Un analyste qui reçoit un indicateur de disponibilité opérationnelle sans visibilité sur les scores de confiance sous-jacents ne peut pas distinguer une évaluation à haute confiance d'un chiffre assemblé à partir d'appariements de faible qualité et de données sources périmées.

La maintenance de l'enregistrement de référence est un processus continu, et non une opération par lots ponctuelle. Lorsqu'un système source met à jour un enregistrement d'entité, le pipeline d'ingestion MDM reçoit la mise à jour, réévalue la survivance pour tous les attributs concernés et met à jour l'enregistrement de référence en conséquence. Si la mise à jour modifie l'enregistrement de référence pour un attribut que des systèmes en aval ont consommé, une notification de changement est publiée sur le bus d'événements MDM afin que les systèmes consommateurs puissent interroger à nouveau l'enregistrement de référence mis à jour. La notification de changement transporte l'identifiant global de l'entité, la liste des attributs modifiés et les valeurs avant/après — assez d'informations pour qu'un système consommateur détermine si le changement affecte l'une de ses données opérationnelles actives, sans devoir récupérer à nouveau l'intégralité de l'enregistrement de référence.

Flux de travail de data stewardship — affectation des data stewards par domaine (data steward équipements, data steward personnes), flux de travail de résolution des litiges, piste d'audit des modifications de l'enregistrement de référence

La résolution d'entités automatisée et les règles de survivance traitent la majorité des cas d'appariement et de conflit d'attributs dans un système MDM en production — typiquement, 85 à 95 % des enregistrements peuvent être résolus sans intervention humaine lorsque le pipeline d'appariement est bien calibré sur les données des systèmes sources concernés. Les 5 à 15 % de cas restants — appariements à faible confiance, valeurs d'attributs contestées pour lesquelles plusieurs sources revendiquent une autorité égale, et scissions ou fusions d'entités qui exigent un jugement — doivent être soumis pour arbitrage à un data steward humain.

Le data stewardship est organisé par domaine d'entités : chaque domaine est confié à un data steward qui détient à la fois l'expertise métier du domaine et l'autorité d'accès aux systèmes nécessaire pour trancher les litiges :

Data steward équipements — généralement intégré à la fonction de comptabilité des biens ou de logistique, il a autorité pour déterminer l'enregistrement d'équipement correct lorsque les systèmes divergent sur les numéros de série, l'affectation à une unité ou le code d'état. Le data steward équipements dispose d'un accès direct aux enregistrements physiques et peut vérifier la vérité terrain en consultant la trace papier d'origine ou en se coordonnant avec les dépositaires du matériel.
Data steward personnel — généralement intégré à la fonction RH ou de gestion du personnel, il a autorité pour résoudre les divergences d'orthographe des noms, les doublons d'enregistrements de personnel (fréquents lorsqu'une personne se réengage et reçoit un nouvel identifiant généré par le système) et les écarts d'affectation entre les enregistrements administratifs et opérationnels.
Data steward organisations — généralement la cellule d'état-major J1 ou J3, il a autorité pour lever les ambiguïtés de hiérarchie des unités lors des changements d'organisation opérationnelle, pour confirmer les dates d'activation et de désactivation des unités, et pour trancher l'affectation à l'unité mère lorsque des sous-unités sont temporairement rattachées à plusieurs états-majors.
Data steward localisations — généralement la fonction de renseignement géospatial ou de gestion des infrastructures, il a autorité pour confirmer si deux enregistrements spatialement proches représentent la même installation ou des installations distinctes colocalisées, et pour établir les coordonnées et le nom canoniques d'un lieu qui apparaît sous des désignations différentes selon les systèmes.

Le flux de travail de résolution des litiges présente chaque cas soumis au data steward sous la forme d'un dossier structuré. Ce dossier contient : les enregistrements candidats de chaque système source que le système MDM estime susceptibles de désigner la même entité, les scores de similarité au niveau des champs pour chaque attribut comparé, la recommandation automatisée du système MDM (appariement, non-appariement ou valeur gagnante recommandée pour un attribut contesté) et un affichage clair des points sur lesquels les sources concordent et divergent. Le data steward choisit parmi les options de résolution disponibles — confirmer la recommandation automatisée, la remplacer par une autre résolution, ou signaler que le cas nécessite des informations complémentaires avant de pouvoir être résolu. Un champ de justification en texte libre permet au data steward de documenter le raisonnement qui sous-tend les décisions non évidentes.

La piste d'audit des modifications de l'enregistrement de référence consigne chaque transition d'état dans l'historique de l'enregistrement de référence, que la modification ait été déclenchée par une mise à jour automatique de survivance ou par une décision manuelle d'un data steward. Chaque enregistrement d'audit contient :

L'identifiant global de l'entité et le domaine d'entités
Le ou les attributs modifiés et les valeurs avant/après pour chacun
Le déclencheur de la modification : règle de survivance automatique (avec l'identifiant et la version de la règle), mise à jour entrante d'une source (avec l'identifiant du système source et celui de l'enregistrement source) ou décision d'un data steward (avec l'identifiant du dossier du data steward)
L'identité authentifiée de l'acteur responsable de la modification — le compte de service système pour les modifications automatiques, l'identité authentifiée du data steward pour les décisions manuelles
L'horodatage de la modification (valeur d'horloge logique pour les déploiements distribués, horloge physique pour les déploiements à hub unique)

Les enregistrements d'audit sont écrits sur un stockage en ajout seul et ne peuvent plus être modifiés après écriture. Cette immuabilité permet au système MDM de reconstituer l'état complet de n'importe quel enregistrement de référence à n'importe quel moment du passé, en rejouant la piste d'audit depuis la création initiale de l'enregistrement — une capacité opérationnellement nécessaire lorsque des analystes doivent évaluer ce que le système MDM tenait pour vrai au sujet d'une entité à un instant historique précis, et une exigence de conformité pour les systèmes classifiés de gestion d'entités.

Survivabilité du MDM en environnements déconnectés — cache MDM local pour les systèmes déployés en avant, résolution des conflits à la reconnexion, modèle de cohérence à terme pour les nœuds déconnectés

Un hub MDM centralisé qui exige une connectivité réseau avec l'échelon arrière pour chaque requête sur une entité est inutilisable sur le plan opérationnel dans un environnement contesté où les communications sont dégradées ou rompues. Les systèmes de C2 déployés en avant, les systèmes logistiques et les outils de planification opérationnelle dépendent tous de la résolution d'entités pour fonctionner correctement — si le hub MDM est injoignable, ils doivent se rabattre sur les identifiants sources bruts, qui peuvent ne pas correspondre d'un système à l'autre, ramenant l'image opérationnelle à l'état antérieur au MDM, celui d'une identité d'entité fragmentée. La conception de la survivabilité du MDM évite cette régression en déployant un cache local à l'avant et en définissant un protocole de synchronisation rigoureux pour la phase de reconnexion.

Le cache MDM avancé est une réplique en lecture prépositionnée des enregistrements de référence et de la table de références croisées pour le sous-ensemble d'entités pertinent au regard du périmètre opérationnel de l'élément avancé. Le « périmètre pertinent » est défini selon deux dimensions : la zone d'opérations géographique (toutes les entités de localisation situées dans la ZO, toutes les entités d'équipement dont la dernière localisation connue se trouve dans la ZO) et l'organisation opérationnelle (toutes les entités de personnes, d'organisations et d'équipements associées aux unités de l'organisation opérationnelle de l'élément avancé). Le cache est alimenté avant le déploiement de l'élément avancé, à partir d'un export d'instantané du hub central. Il est déployé sur un matériel qui fonctionne indépendamment du réseau étendu — un serveur durci colocalisé avec le nœud C2 avancé, ou intégré à l'environnement informatique du poste de commandement tactique.

Pendant le fonctionnement déconnecté, les systèmes tactiques interrogent le cache local exactement comme ils interrogeraient le hub central — la même API, le même format de réponse. Les requêtes de résolution d'entités sont servies à partir de la table de références croisées locale. Les requêtes sur les enregistrements de référence renvoient les valeurs d'attributs en cache accompagnées d'un horodatage de fraîcheur indiquant à quand remonte la dernière confirmation de chaque attribut par le hub central. Il incombe aux systèmes tactiques de présenter cet horodatage de fraîcheur aux utilisateurs lorsque les données peuvent être périmées, plutôt que de présenter les données en cache comme si elles étaient à jour.

Toutes les créations, mises à jour, fusions et scissions d'entités qui surviennent pendant la période de déconnexion sont écrites dans un journal local des modifications — une file d'attente ordonnée et bornée d'événements de modification d'entités. Chaque événement porte un horodatage par horloge vectorielle, qui établit un ordre partiel des événements entre les nœuds déconnectés sans exiger d'horloges physiques synchronisées. La capacité du journal des modifications limite la durée du fonctionnement déconnecté : un journal dimensionné pour 72 heures de cadences typiques de mise à jour d'entités en opérations offre 72 heures de fonctionnement indépendant avant que la synchronisation ne devienne obligatoire pour éviter le débordement du journal. Le processus de planification opérationnelle doit tenir compte de cette contrainte.

Le protocole de synchronisation à la reconnexion se déroule en trois phases lorsque l'élément avancé rétablit la connectivité réseau avec le hub central :

Phase 1 — Transmission du journal des modifications : le nœud avancé transmet l'intégralité de son journal des modifications au hub central. Le hub accuse réception et attribue à chaque événement un numéro de séquence global. Le nœud avancé continue de servir les requêtes locales depuis son cache pendant cette phase. Phase 2 — Détection et résolution des conflits : le hub rejoue le journal des modifications du nœud avancé par rapport à l'état courant de ses entités. Pour chaque événement du nœud avancé, le hub vérifie si le même attribut a été mis à jour au niveau du hub ou d'un autre nœud avancé pendant la période de déconnexion. Aucun conflit : la modification du nœud avancé est appliquée telle quelle. Conflit (même attribut mis à jour par deux sources) : appliquer la règle de survivance configurée (source la plus fiable, horloge logique la plus récente). Si la règle de survivance ne désigne aucun gagnant clair : orienter vers la file d'attente des data stewards. Phase 3 — Resynchronisation du cache : le hub transmet au cache avancé l'état fusionné des entités après résolution des conflits. Le cache avancé remplace son instantané par l'état fusionné. Le hub transmet le journal des modifications résolu à tous les autres caches avancés afin qu'ils reçoivent eux aussi les mises à jour issues de ce nœud avancé. Tous les nœuds confirment la réception avant que le hub ne marque le cycle de synchronisation comme terminé.
            

Le modèle de cohérence à terme qui sous-tend cette architecture offre une garantie : après la reconnexion et l'achèvement réussi du protocole de synchronisation, tous les nœuds de la topologie MDM — le hub central et tous les caches avancés — détiennent un état d'entités identique. Pendant une période de déconnexion, les nœuds peuvent diverger. Le protocole de synchronisation est conçu pour que cette divergence soit bornée, détectable et résoluble sans perte de données — aucune mise à jour d'entité effectuée pendant la période de déconnexion n'est rejetée ; elle est seulement réordonnée et éventuellement supplantée par une règle de survivance qui applique la hiérarchie d'autorité définie par l'organisation.

L'implication opérationnelle est que les analystes et les systèmes qui utilisent le cache avancé pendant une période de déconnexion doivent comprendre qu'ils travaillent à partir d'un instantané dont l'actualité est incertaine. Le cache avancé devrait exposer un champ « dernier horodatage de synchronisation » au niveau du cache et un horodatage « dernière confirmation » au niveau de chaque attribut des enregistrements de référence, afin de fournir aux systèmes en aval les informations nécessaires pour assortir leurs présentations de réserves de confiance appropriées lorsque des décisions opérationnelles reposent sur des données d'entités qui n'ont pas été confirmées récemment par le hub central. Une évaluation de disponibilité opérationnelle d'unité fondée sur des enregistrements de référence d'équipements issus d'un instantané vieux de 12 heures et d'une période de déconnexion de 71 heures justifie un niveau de confiance différent de celui d'une évaluation fondée sur des enregistrements synchronisés 30 minutes avant sa génération. Rendre cette distinction visible dans les données — plutôt que de la masquer derrière une présentation uniforme des attributs des enregistrements de référence — est ce qui rend le MDM utile plutôt que trompeur dans des environnements opérationnels contestés.

Questions fréquentes

Qu'est-ce que la gestion des données de référence (MDM) dans un contexte de défense ?

La gestion des données maîtres dans un contexte de défense est la discipline consistant à créer et à maintenir une version unique et faisant autorité de chaque entité centrale — personne, organisation, équipement et lieu — que tous les systèmes opérationnels s'accordent à utiliser comme référence. Sans MDM, un militaire apparaît dans le système de ressources humaines (HR) sous un matricule, dans le système C2 sous un autre identifiant attribué par l'unité et dans le système logistique sous un troisième identifiant lié à l'allocation du matériel. Lorsqu'un analyste joint ces systèmes, il ne peut pas déterminer si trois enregistrements désignent la même personne ou trois personnes différentes. Le MDM résout ce problème en exécutant un processus de résolution d'entités qui compare les enregistrements entre les systèmes, rattache les doublons à un identifiant global unique et construit un golden record représentant l'état le mieux connu de chaque entité. Tous les systèmes d'analyse et opérationnels en aval consomment le golden record via une API partagée, au lieu d'interroger chaque système source séparément. Il en résulte des références d'entités cohérentes entre C2, logistique, HR et ISR, condition préalable à toute image situationnelle multi-domaines fiable.

Quels sont les trois modèles de hub en MDM et lequel convient le mieux à la défense ?

Les trois modèles de hub MDM standard sont le registre, la consolidation et la coexistence. Dans le modèle de registre, le hub MDM ne stocke que la table de références croisées — une correspondance entre les identifiants des systèmes sources et l'identifiant d'entité global — sans stocker lui-même aucune donnée d'attributs maîtres. Chaque système conserve sa propre copie des attributs d'entité, et les consommateurs interrogent directement les systèmes sources en s'appuyant sur les références croisées pour résoudre l'identité. Dans le modèle de consolidation, le hub copie et stocke les attributs d'entité de tous les systèmes sources, les enrichit et les dédoublonne, puis sert le résultat consolidé ; les systèmes sources ne sont pas modifiés. Dans le modèle de coexistence, le hub à la fois stocke la référence consolidée et réécrit les attributs du golden record dans les systèmes sources, créant un état faisant autorité partagé entre toutes les applications participantes. Pour les environnements de défense, le modèle de consolidation est le plus pratique : il n'exige pas la modification des systèmes sources faisant autorité (les systèmes HR, logistiques et C2 sont rarement modifiables), n'impose pas que tous les systèmes acceptent des écritures initiées par le hub (l'autorisation de réécriture est complexe dans les environnements classifiés) et offre néanmoins un point central où les systèmes d'analyse et de renseignement peuvent interroger des données d'entités cohérentes. Le modèle de registre convient lorsque la réplication du stockage est impossible en raison des exigences de cloisonnement par classification.

Quels types d'entités un système MDM de défense gère-t-il ?

Un système MDM de défense gère quatre grands domaines d'entités. Le domaine des personnes couvre le personnel militaire — soldats, officiers, prestataires et partenaires de coalition — avec des attributs issus des systèmes HR, de gestion du personnel, de gestion des habilitations et C2. Le domaine des organisations couvre les unités, commandements, sous-unités et task forces, y compris leurs relations hiérarchiques et la structure actuelle de leur articulation opérationnelle, qui change fréquemment pendant la planification opérationnelle. Le domaine des équipements couvre les plateformes, véhicules, systèmes d'armes et inventaires d'articles finis, avec des attributs issus des systèmes de logistique, de maintenance et de comptabilité des matériels ; chaque équipement possède un numéro de série et un identifiant unique d'article (UII) qui doivent être appariés entre des systèmes pouvant enregistrer des formats d'identifiant différents. Le domaine des lieux couvre les infrastructures, installations, zones d'intérêt nommées et positions tactiques, ce qui exige une réconciliation entre des systèmes qui désignent le même lieu physique à l'aide de coordonnées du système de référence de grille militaire (MGRS), de coordonnées géographiques ou de toponymes en langage naturel. Chaque domaine exige des algorithmes d'appariement et des affectations de stewardship spécifiques, car les attributs, les schémas d'identifiants et les profils de qualité des données diffèrent sensiblement d'un domaine à l'autre.

Comment fonctionne la résolution d'entités à l'échelle d'un grand jeu de données de défense ?

La résolution d'entités à l'échelle de la défense — des millions d'enregistrements d'équipements, des centaines de milliers d'enregistrements de personnel répartis sur plusieurs systèmes sources — exige une étape de blocage (blocking) avant toute comparaison par paires. Le blocage répartit l'ensemble complet des enregistrements en groupes candidats plus petits, au sein desquels tous les enregistrements pourraient plausiblement désigner la même entité. Sans blocage, comparer chaque enregistrement à tous les autres a un coût quadratique et devient infaisable en calcul sur de grands jeux de données. Les stratégies de blocage pour les ensembles d'entités de défense comprennent le blocage phonétique sur les champs de nom de famille (Soundex, Metaphone) pour les enregistrements de personnel, le blocage par préfixe sur les champs de numéro de série pour les enregistrements d'équipements et le blocage par geohash pour les enregistrements de lieux. Après le blocage, un modèle d'appariement évalue chaque paire candidate au sein d'un bloc. L'appariement déterministe applique un ensemble de règles fixes — si deux enregistrements ont un numéro de série strictement identique et le même numéro de stock national, ils correspondent. L'appariement probabiliste calcule un score de confiance d'appariement à partir d'une combinaison pondérée de scores de similarité au niveau des champs et le compare à un seuil. L'appariement fondé sur le ML entraîne un classifieur sur des paires étiquetées appariées/non appariées issues du jeu de données concerné, en apprenant le poids relatif de chaque champ et les schémas d'erreurs de saisie propres aux systèmes sources de l'environnement.

Qu'est-ce qu'un enregistrement de référence (golden record) et comment est-il construit à partir de données sources contradictoires ?

Un golden record est la représentation unifiée et faisant autorité d'une entité unique dans le système MDM, assemblée à partir des attributs fournis par tous les systèmes sources qui contiennent des enregistrements pour cette entité. Lorsque deux systèmes sources ou plus fournissent des valeurs différentes pour un même attribut — par exemple, l'unité d'affectation d'un équipement diffère entre le système logistique et le système C2 — une règle de survivance (survivorship) détermine quelle valeur source l'emporte. Les règles de survivance courantes sont : la plus récente l'emporte (la source qui a mis à jour l'attribut le plus récemment prévaut), la source la plus fiable l'emporte (un classement de priorité fixe des sources définit les valeurs de quel système font autorité pour chaque type d'attribut) et la plus complète l'emporte (la valeur de la source présentant le taux de valeurs nulles le plus faible pour cet attribut est privilégiée). En pratique, un système MDM de production combine les règles : l'unité d'affectation fait autorité depuis le système C2, l'état de maintenance fait autorité depuis le système logistique, et les attributs d'identification (numéro de série, nomenclature) font autorité depuis le système de comptabilité des matériels. Chaque attribut du golden record porte un score de confiance et une référence de provenance indiquant quelle source a fourni la valeur et quand elle a été confirmée pour la dernière fois. Les attributs issus d'appariements de faible confiance ou de sources présentant des problèmes connus de qualité des données reçoivent des scores de confiance plus faibles, ce que voient les consommateurs en aval qui évaluent la fiabilité des données d'entité.

Qu'est-ce que le data stewardship et comment fonctionne-t-il dans un déploiement MDM de défense ?

Le data stewardship est la couche humaine de gouvernance qui résout les conflits d'appariement et d'attributs que le système MDM automatisé ne peut pas trancher avec une confiance suffisante. Un data steward est une personne disposant d'une expertise métier et d'une autorité d'accès au système, qui examine les appariements ambigus, arbitre les valeurs d'attributs contradictoires et approuve ou rejette les constructions de golden record proposées. Dans un déploiement MDM de défense, le stewardship est organisé par domaine d'entités : un steward des équipements détient l'autorité sur le domaine des équipements et est généralement intégré à la fonction de comptabilité des matériels ou de logistique ; un steward du personnel détient l'autorité sur le domaine des personnes et est généralement intégré à la fonction de ressources humaines ou de gestion du personnel. Un workflow de résolution des litiges achemine les décisions d'appariement de faible confiance et les conflits d'attributs à forte valeur vers la file d'attente du steward approprié, avec un dossier de cas structuré : les enregistrements candidats de chaque source, les scores de similarité de chaque champ apparié, la recommandation automatisée et les résolutions alternatives entre lesquelles le steward peut choisir. La décision du steward est consignée dans la piste d'audit du MDM avec son identité, la décision prise et sa justification. Cette piste d'audit est à la fois un enregistrement opérationnel et un artefact de gouvernance démontrant que le golden record a été examiné par un expert métier autorisé.

Comment concevoir l'architecture du MDM pour qu'il survive dans un environnement déconnecté déployé en avant ?

La survivabilité du MDM en environnement déconnecté exige une architecture à niveaux dans laquelle un cache MDM léger est déployé à l'avant, aux côtés des systèmes tactiques qu'il dessert, tandis que le hub MDM faisant autorité reste à l'échelon arrière. Le cache avancé contient un instantané prépositionné de la table maître des entités — les golden records et la table de références croisées des entités pertinentes pour la zone d'opérations et l'articulation opérationnelle de l'élément avancé. Les systèmes tactiques de l'environnement déconnecté interrogent le cache local pour la résolution d'entités, au lieu d'exiger une connexion réseau au hub central. Lorsque l'élément avancé opère en mode déconnecté, toute modification des enregistrements d'entités est écrite dans un journal des modifications local — une file bornée d'opérations de création/mise à jour/fusion/scission — au lieu d'être perdue. À la reconnexion, le journal des modifications est transmis au hub central, qui applique un protocole déterministe de résolution des conflits pour fusionner les mises à jour de l'avant avec les changements survenus au niveau du hub ou d'autres nœuds avancés pendant la période de déconnexion. La résolution des conflits applique par défaut un ordonnancement fondé sur l'horodatage, avec une résolution assistée par un steward pour les conflits où le même attribut d'entité a été mis à jour des deux côtés pendant la fenêtre de déconnexion.

Quelle est la différence entre l'appariement d'entités déterministe et probabiliste ?

L'appariement déterministe applique un ensemble de règles fixes dans lequel la décision d'appariement est binaire — deux enregistrements satisfont tous les critères d'appariement ou ne les satisfont pas. Une règle déterministe pour les enregistrements d'équipements pourrait être la suivante : deux enregistrements correspondent si et seulement si leurs numéros de série sont identiques après suppression des espaces et normalisation de la casse, et si leurs numéros de stock nationaux (NSN) concordent sur les neuf premiers chiffres. Les règles déterministes sont faciles à auditer, ne produisent aucun faux positif lorsque la règle est correctement spécifiée et ne nécessitent aucune donnée d'entraînement. Elles constituent le choix approprié pour les attributs destinés à être des identifiants globalement uniques maintenus par des sources faisant autorité. L'appariement probabiliste calcule un score composite pondéré à partir de plusieurs comparaisons de champs, dont chacune produit une valeur de similarité partielle plutôt qu'un oui/non binaire. Une comparaison d'enregistrements de personnel pourrait pondérer la similarité phonétique du nom de famille à 0,35, la similarité du prénom à 0,25, la correspondance exacte de la date de naissance à 0,30 et l'unité d'affectation à 0,10, ce qui donne un score composite comparé à un seuil d'appariement configurable. Les enregistrements au-dessus du seuil sont des appariements candidats ; ceux situés dans une zone de revue juste en dessous du seuil sont acheminés vers un steward. L'appariement probabiliste gère la réalité des données imparfaites des systèmes de défense — enregistrements comportant des fautes de frappe, des variantes d'orthographe des noms, des champs manquants ou un encodage incohérent — là où les règles déterministes produiraient des taux d'appariements manqués inacceptables.

Comment les modifications de l'enregistrement de référence sont-elles auditées dans un système MDM de défense ?

Toute modification d'un golden record dans un système MDM de défense doit être consignée dans une piste d'audit immuable qui enregistre l'état complet, avant et après, des attributs concernés, la source de la modification (règle de survivance automatisée, décision manuelle d'un steward ou mise à jour entrante d'un système source), l'identité du principal ayant autorisé la modification (compte de service du système pour les modifications automatisées, identité humaine authentifiée pour les décisions des stewards), l'horodatage de la modification et une référence à l'événement source qui l'a déclenchée (l'identifiant du lot d'ingestion pour les mises à jour automatisées, l'identifiant du dossier du steward pour les décisions manuelles). La piste d'audit est stockée en ajout seul — les enregistrements d'audit existants ne peuvent jamais être modifiés ni supprimés, seuls de nouveaux enregistrements peuvent être ajoutés. Cette immuabilité est garantie au niveau de la couche de stockage, grâce au verrouillage d'objet (object lock) ou à des politiques d'écriture unique au niveau de la base de données, plutôt que de reposer uniquement sur un contrôle au niveau de la couche applicative. La piste d'audit rend possibles deux cas d'usage opérationnels essentiels : la reconstitution de l'état du golden record de n'importe quelle entité à n'importe quel moment passé (en répondant à la question « que croyait le système MDM à propos de l'équipement de cette unité à 06:00 à une date donnée ») et le traçage de la provenance d'une valeur d'attribut précise du golden record actuel jusqu'à la mise à jour du système source et à l'événement d'ingestion qui l'a introduite.

Comment fonctionne la cohérence à terme dans un système MDM de défense comportant plusieurs nœuds déconnectés ?

La cohérence à terme dans un déploiement MDM de défense signifie que, si tous les nœuds de la topologie MDM — le hub central et tous les caches avancés — sont garantis de converger vers le même état d'entité après reconnexion et synchronisation, ils peuvent détenir des états divergents pendant une période de déconnexion. Le modèle de cohérence est volontairement assoupli par rapport à la cohérence forte (où tous les nœuds s'accordent à tout moment sur l'état courant), car la cohérence forte exige une connectivité réseau continue, ce qui est incompatible avec l'exigence de fonctionnement déconnecté. Dans le modèle de cohérence à terme, chaque nœud traite les mises à jour localement et les consigne dans son journal des modifications. Les journaux des modifications utilisent des horloges vectorielles ou des horloges logiques hybrides, plutôt que des horodatages d'horloge murale (wall-clock), pour établir un ordre partiel des événements entre les nœuds sans exiger d'horloges synchronisées — une contrainte réaliste dans les environnements déployés à l'avant, où la synchronisation NTP peut être indisponible. À la reconnexion, le hub collecte les journaux des modifications de tous les nœuds, les fusionne en appliquant l'ordre partiel et produit un état convergé du golden record qui intègre toutes les mises à jour de tous les nœuds. Lorsque deux nœuds ont effectué des mises à jour contradictoires du même attribut pendant la fenêtre de déconnexion (situation détectable en examinant l'ordre partiel des horloges vectorielles), le conflit est résolu par la règle de survivance configurée (source la plus fiable, la plus récente selon l'horloge logique) ou escaladé vers un steward si la règle de survivance ne désigne pas de gagnant clair. Après la convergence, le hub rediffuse l'état fusionné à tous les nœuds afin qu'ils se resynchronisent sur la vue cohérente.

Qu'est-ce qu'un golden record et comment est-il construit à partir de données sources contradictoires ?

Comment architecturer le MDM pour survivre dans un environnement déconnecté déployé à l'avant ?

Comment les modifications d'un golden record sont-elles auditées dans un système MDM de défense ?