Comment un studio de simulateurs de défense entretient depuis des décennies des jumeaux numériques 3D dans Unity

i3 Corps développe des simulateurs virtuels et des outils de productivité pour les ingénieurs à destination des administrations américaines. L'entreprise a créé dans Unity des centaines de scénarios de formation : ils couvrent la majeure partie de la formation aéronautique qu'elle assure, ainsi que des plateformes de l'US Navy et des véhicules terrestres. Les applications parviennent jusqu'aux salles de cours des bases militaires via une plateforme de distribution gouvernementale que l'entreprise a elle-même conçue et qui fonctionne dans un cloud gouvernemental sécurisé. Mais la véritable complexité ne se trouve pas dans les applications : elle se cache en dessous, dans la bibliothèque de modèles 3D.

Dans le développement 3D classique, un asset est considéré comme terminé dès la sortie du produit. Ici, c'est tout autre chose : les modèles sont des jumeaux numériques d'équipements réels, et ces équipements évoluent sans cesse. De nouveaux composants entrent en service, les fabricants révisent des pièces, les clients envoient de nouveaux paquets de données CAO. Le modèle d'un seul avion compte 80 000 composants, jusqu'aux écrous et aux boulons. L'équipe ajoute dix à quinze modèles par an, et chacun est ensuite maintenu pendant huit à neuf ans. Chaque nouveau lot de données d'ingénierie soulève les mêmes questions : quelles pièces remplace-t-il, quel modèle met-il à jour et quelles applications déjà déployées dépendent de ce modèle. La provenance compte aussi : les modèles sont construits à partir de données CAO de sources diverses et de photogrammétrie réalisée en interne, et une seule campagne de prise de vues peut produire des millions de photos d'un même véhicule.

Les variantes multiplient le problème. Le UH-60 Black Hawk existe dans les versions de l'US Army UH-60A, L, M et V, dans la version d'évacuation sanitaire HH-60M MEDEVAC et dans des versions destinées aux forces d'opérations spéciales, sans compter les configurations pour la Navy, l'Air Force et les clients étrangers. La plupart partagent le fuselage, la poutre de queue, les ensembles du rotor principal et le train d'atterrissage. Le UH-60V conserve en grande partie la cellule de la version L, mais dispose d'un cockpit numérique, et le HH-60M est un UH-60M auquel on a ajouté des systèmes médicaux et de mission. C'est pourquoi chaque variante n'est pas modélisée à partir de zéro : on part d'une base commune de composants réutilisables, et chaque variante n'ajoute que ses différences, qu'il s'agisse de la structure, des systèmes mécaniques, de l'avionique ou des équipements de mission.

L'espace disque constitue une autre contrainte stricte. Les ordinateurs du gouvernement peuvent être anciens, fortement sécurisés et limités en capacité de stockage, alors qu'un seul PC de salle de formation peut accueillir tous les cours d'une même plateforme. Si les modèles étaient intégrés à chaque build, cela représenterait des centaines de gigaoctets de géométrie presque identique. Unity Addressables résout ce problème : les modèles sont stockés dans un catalogue, chargés à la demande et mis en cache localement, de sorte qu'un asset utilisé par quinze applications n'est stocké qu'une seule fois. Une application ne change que lorsque son code change, et un développeur n'a pas besoin de disposer localement de toute la bibliothèque pour assembler une scène. Le niveau de classification détermine où un asset peut résider : les contenus classifiés ne vont jamais dans le cloud, tandis que les CUI le peuvent, mais dans une enveloppe protégée empêchant leur extraction. La propriété du modèle, i3 ou le gouvernement, détermine s'il peut être réutilisé dans de futurs contrats.

Les plateformes commerciales de gestion d'assets soit ne correspondaient pas à ce modèle de données, soit étaient proposées sous des licences inadaptées aux marchés publics, et aucune option pour le cloud gouvernemental n'existait. Un système maison, composé d'une base de données et d'un moteur de recherche superposés au contrôle de version et à l'automatisation existants, aidait à retrouver les assets, mais l'intégration au moteur, l'automatisation du pipeline, le suivi des dépendances et une maintenance illimitée dans le temps n'étaient plus justifiables. L'entreprise a donc déployé Unity Asset Manager dans un environnement cloud gouvernemental, ce qui permet aux artistes et aux développeurs de rester dans Unity. Dès à présent, le catalogue répond aux questions suivantes : qu'est-ce qui a été modélisé, où est-ce utilisé, l'accès est-il restreint et à qui cela appartient-il.

La volatilité reste un défi non résolu : dix équipes d'artistes modifient des assets chaque semaine, voire chaque jour, et chaque modification se propage le long de longues chaînes de dépendances sur lesquelles reposent des animations de maintenance complexes. L'objectif est d'indiquer précisément aux artistes ce qui a changé, plutôt que de publier de nouvelles versions de tout ce qui dépend de la modification. i3 Corps y travaille avec Unity. Les enjeux vont encore plus loin : le gouvernement détient d'immenses volumes de données CAD et paramétriques dans lesquelles il est pratiquement impossible de retrouver quoi que ce soit, tandis que la demande se déplace vers la simulation, la visualisation et la génération de contenu assistée par l'IA. Tout cela exige une bibliothèque consultable que les machines peuvent elles aussi interroger.