L'IA de défense a un problème de données que l'IA commerciale n'a pas. Les données opérationnelles qui rendraient un modèle réellement utile — imagerie IR de véhicules adverses, retours SAR de terrain contesté, captures EO de sorties ISR, collections de spectre RF d'engagements réels — sont presque toujours classifiées au niveau FOUO, SECRET ou supérieur. Les ingénieurs qui entraînent le modèle détiennent rarement l'habilitation, le poste de travail ou la connexion réseau nécessaires pour y toucher. Les données synthétiques sont la façon dont les programmes livrent malgré tout.

Ce n'est pas un contournement. C'est désormais la stratégie d'entraînement dominante pour la plupart des programmes défense de vision par ordinateur et d'IA capteur, les données classifiées servant uniquement à la validation finale. La discipline qui rend l'approche crédible réside dans l'ingénierie de simulation, le pont sim-to-real et les preuves de validation — pas dans l'architecture du modèle.

Le problème des données classifiées

La version honnête de la contrainte : un bureau de programme défense dispose de milliers d'heures de données de mission sur des réseaux classifiés. Le fournisseur d'ingénierie a des individus habilités — parfois un ou deux — qui peuvent y accéder sur un poste de travail SCIF, les étiqueter lentement à la main, et ne rien expédier hors de l'enclave. L'entraînement GPU dans le cloud n'est pas une option. Les outils d'étiquetage qui appellent à la maison ne sont pas une option. L'équipe finit avec peut-être trente exemples représentatifs pour une classe qui en exige dix mille.

C'est la réalité des « 30 exemples » qui motive toute la discipline des données synthétiques. Un détecteur d'objets moderne a besoin de classes équilibrées sur l'éclairage, la distance, l'aspect, l'occlusion, la saison et le mode capteur. Les vraies données classifiées sont biaisées vers ce que les plateformes de collecte ont survolé, les jours où elles ont volé. Même quand le volume existe, la distribution est mauvaise. Les données synthétiques sont le seul moyen de fermer la longue traîne.

Catégories de données synthétiques

Rendu par moteur de jeu. Unreal Engine 5, Unity et NVIDIA Omniverse Replicator sont désormais les outils de référence pour générer de l'imagerie synthétique photoréaliste. Les programmes construisent des jumeaux numériques de terrains pertinents (souvent à partir de DTED public, Sentinel-2 et tuiles Maxar), les peuplent de modèles haute fidélité de véhicules et d'aéronefs, et rendent sous éclairage, météo et paramètres capteur contrôlés. L'API de randomisation d'Omniverse Replicator est le standard pour générer des millions d'images étiquetées avec boîtes englobantes vérité-terrain, masques de segmentation et cartes de profondeur incluses.

Génération par GAN et diffusion. StyleGAN3, fine-tunes de Stable Diffusion et modèles de diffusion conditionnels dédiés génèrent de l'imagerie directement. L'avantage est le photoréalisme sans effort de modélisation ; l'inconvénient est que les étiquettes ne viennent pas gratuitement et que les artefacts statistiques peuvent empoisonner les modèles en aval. En usage défense, l'imagerie générée par GAN est surtout utile pour l'augmentation — perturber des images existantes — plutôt que comme données d'entraînement primaires.

Augmentation depuis sources publiques. Les jeux de données publics (xView, DOTA, FMOW, RarePlanes, SpaceNet) fournissent une base d'imagerie aérienne sous licences permissives. Les programmes défense les augmentent en compositant des véhicules synthétiques, en appliquant une dégradation réaliste du capteur et en remappant les spectres. Le résultat est de la donnée hybride — substrat public, avant-plan synthétique — avec provenance auditable.

Pipelines hybrides. Les programmes de production combinent les trois. Une pile typique : Omniverse génère un million d'images IR étiquetées sur un espace de scénarios paramétré, un modèle de diffusion perturbe textures et atmosphère pour la diversité, et le compositage à partir de sources publiques comble les manques pour des classes spécifiques que les simulateurs ne couvrent pas encore. La sortie est un seul jeu de données, avec un étiquetage cohérent et un registre de provenance unique.

Pipelines de simulation

La pile d'ingénierie derrière un pipeline IR/EO/SAR crédible a quatre couches. Terrain. Cartes d'altitude depuis SRTM ou DTED fourni par le programme, matériaux de surface depuis les classifications de couverture du sol Sentinel-2, et végétation procédurale placée par écotype. Cesium ion et Houdini sont courants pour l'authoring de terrain ; Omniverse et Unreal ingèrent le résultat.

Atmosphérique. Nuages volumétriques, brume, précipitations et éclairage selon l'heure du jour. Pour l'IR spécifiquement, cela signifie modéliser la transmittance atmosphérique par bande avec MODTRAN ou un substitut plus rapide, pas seulement ajouter du brouillard comme effet visuel. Les programmes qui sautent l'atmosphérique basé sur la physique livrent des modèles qui fonctionnent par temps clair et échouent à l'aube.

Modèles capteur. Intrinsèques caméra, focale, exposition, plancher de bruit, MTF et courbes de réponse spécifiques à chaque bande. Pour le SAR, cela signifie un simulateur électromagnétique complet (RaySAR, SARviz ou des outils commerciaux comme CohRaS) produisant des retours avec speckle correct plutôt que des « niveaux de gris d'allure SAR ». Le modèle capteur est ce qui sépare les données d'entraînement qui transfèrent de celles qui ne transfèrent pas.

Catalogues de cibles. Modèles 3D de véhicules, aéronefs et infrastructures pertinents, avec plaques de signature thermique pour l'IR et propriétés électromagnétiques de matériaux pour le SAR. Les dépôts CAO publics couvrent les classes commerciales ; les modèles spécifiques défense sont commandés à des fournisseurs comme TurboSquid Pro, RocketBox, ou construits en interne par photogrammétrie. Chaque modèle porte une note de fidélité — géométrie seule, géométrie+matériaux, géométrie+matériaux+signatures — et le jeu de données enregistre quelle note a été utilisée pour chaque image.

Écart sim-to-real du domaine

Un modèle entraîné purement sur données synthétiques et testé sur données réelles échoue presque toujours. L'écart est le problème « sim-to-real », et le fermer est le problème d'ingénierie le plus dur de cette discipline.

La randomisation de domaine est le premier et plus fiable outil. Plutôt que d'essayer de rendre l'imagerie synthétique réaliste, randomisez agressivement sur les textures, l'éclairage, les paramètres caméra et l'atmosphérique afin que le domaine réel ne ressemble plus qu'à un autre échantillon. La recherche de NVIDIA sur la randomisation de domaine pour la détection d'objets — et les premiers travaux de Tesla sur la conduite — ont tous deux démontré que la randomisation bat le photoréalisme pour le transfert.

L'adaptation de domaine est le second outil. La traduction d'images style CycleGAN déplace les images synthétiques vers la distribution réelle ; les méthodes d'adaptation au niveau des features (DANN, ADDA, CDAN) alignent les représentations apprises. En usage défense, la contrainte est que le côté « réel » de l'adaptation doit être non classifié ou accessible sous les mêmes contrôles que le modèle — ce qui signifie généralement utiliser un petit jeu de référence réel libérable plutôt que le corpus classifié complet.

L'écart de validation. Les pipelines naïfs rapportent la précision test sur synthétique, voient quatre-vingt-dix pour cent et plus, et livrent. Puis le modèle rencontre les vraies données et s'effondre. La seule métrique qui compte est la précision mesurée sur des données réelles en distribution. La précision test synthétique est une vérification de bon sens, pas un seuil de livraison.

Point clé : Les programmes de données synthétiques qui réussissent traitent le simulateur comme du code sous contrôle de changement — versionné, revu, et accompagné d'un registre de notes de version. Les programmes qui échouent le traitent comme un rendu de pipeline artistique ponctuel. Le premier est de l'ingénierie ; le second de la production de contenu.

Validation contre données réelles

La validation contre données réelles classifiées est là où la discipline des données synthétiques gagne ou perd la confiance. Le schéma qui fonctionne : l'équipe d'ingénierie entraîne entièrement sur le corpus synthétique non classifié, livre le modèle à l'enclave classifiée comme artefact scellé, et l'équipe de validation habilitée exécute l'évaluation contre un petit jeu réel mis de côté du côté classifié. Les métriques — précision, rappel, courbes de calibration, confusion par classe — sont rétrocédées à l'équipe d'ingénierie sous forme de nombres, pas d'imagerie.

La calibration compte autant que la précision. Un modèle qui prédit « char » à 99 % de confiance sur une cible qu'il n'a jamais vue de manière fiable est dangereux. Les pipelines de validation défense incluent les diagrammes de fiabilité et l'erreur de calibration attendue (ECE) en plus de la précision globale. Les programmes opérant en aval d'un triage analyste ont besoin que les nombres de confiance signifient quelque chose.

Le jeu de validation lui-même est traité comme un actif géré. Il doit être représentatif de la distribution de déploiement, figé entre versions de modèle pour la comparabilité, et rafraîchi périodiquement à mesure que l'environnement opérationnel change. Un jeu de validation trop petit ou périmé produit une fausse confiance ; un trop dynamique rend la détection de régression impossible.

Provenance et auditabilité

Chaque image d'un jeu de données synthétiques défense doit être traçable. Le registre de provenance enregistre : quelle version de simulateur l'a produite, quels paramètres de scénario, quelle note de fidélité du modèle de cible, quel modèle atmosphérique, quelle graine aléatoire et quel profil capteur. Lorsque le modèle échoue plus tard en déploiement, l'équipe doit pouvoir demander « avons-nous jamais entraîné sur quoi que ce soit ressemblant à cette scène ? » — et répondre par des preuves, pas par des suppositions.

Les fiches de modèle sont la couche de documentation. Une fiche de modèle défense divulgue la composition des données d'entraînement — pourcent synthétique par catégorie, pourcent public, pourcent hybride, pourcent réel — aux côtés des preuves de validation sur le jeu réel. C'est de plus en plus une exigence d'accréditation, pas un nice-to-have. La directive Responsible AI du DoD, NATO STO TR-IST-178 et plusieurs régimes nationaux d'accréditation IA attendent tous une traçabilité documentée des données comme condition préalable à la mise en service.

Contraintes légales et éthiques

Synthétique ne veut pas dire sans contrainte. Les droits d'image comptent pour les pipelines hybrides : les jeux publics portent des licences, la photogrammétrie d'objets réels a des implications de droits d'auteur, et les places de marché commerciales de modèles 3D ont des clauses spécifiques interdisant l'usage dans des systèmes d'armes. Les programmes qui ignorent les termes de licence créent une exposition juridique en aval qui ressort à la revue d'accréditation, pas pendant le développement.

Classification des sorties synthétiques. L'imagerie synthétique d'un système réel sensible — même rendue depuis CAO publique — peut elle-même devenir classifiée une fois qu'elle reproduit fidèlement des signatures qui étaient classifiées. Les programmes ont besoin d'un guide de classification pour leurs sorties de données synthétiques, validé par l'officier de sécurité du client, avant le début de la génération. La classification rétroactive est coûteuse.

Considérations à double usage. Les pipelines de données synthétiques qui entraînent des modèles de reconnaissance de cible sont par construction à double usage. Les contrôles à l'export (ITAR, EAR, UE 2021/821) s'appliquent aux outils de simulation, aux modèles de cibles et aux poids entraînés. L'équipe d'ingénierie a besoin d'une revue de contrôle à l'export à trois points : choix d'outils, assemblage du catalogue de cibles et publication du modèle.

Ce qui fonctionne en production

Le schéma qui a émergé dans les programmes d'IA de défense crédibles en 2025–2026 est l'entraînement fédéré : pré-entraînement à grande échelle sur données synthétiques sur infrastructure non classifiée, fine-tuning au bord classifié sur données réelles que l'équipe d'ingénierie ne voit jamais. Le modèle pré-entraîné porte plus de quatre-vingt-dix pour cent de la capacité ; le fine-tune classifié comble le dernier écart. L'architecture s'aligne naturellement avec les schémas d'apprentissage fédéré déjà utilisés pour les réseaux de capteurs.

Le rafraîchissement continu des données synthétiques est l'habitude opérationnelle qui sépare les programmes sérieux des livraisons one-shot. À mesure que l'image opérationnelle change — nouvelles variantes de véhicules adverses, nouveaux environnements d'opération, nouvelles charges utiles capteur — le simulateur produit de nouvelles tranches d'entraînement à cadence mensuelle ou trimestrielle. Le modèle est ré-entraîné, revalidé contre le jeu classifié et redéployé. Les programmes qui traitent l'entraînement comme un événement unique voient leur précision décroître invisiblement.

Pour le contexte complet de la place des données synthétiques dans la pile IA défense plus large, voir notre guide complet de l'IA en défense et la discussion sur l'emplacement des modèles dans le tier sensor-edge. La discipline des données synthétiques n'est pas un sujet de recherche ; c'est désormais le schéma de livraison par défaut, et les programmes qui la traitent avec rigueur d'ingénierie sont ceux dont les modèles fonctionnent réellement quand les vraies données arrivent enfin.