La simulation d'entraînement militaire est architecturalement distincte des autres catégories de logiciels de défense. Le défi de conception fondamental n'est pas le débit, la latence ou la fiabilité — c'est le compromis déterminisme-réalisme. Une simulation d'entraînement entièrement déterministe (les mêmes entrées produisent toujours les mêmes résultats) est facile à tester et à certifier, mais produit des scénarios prévisibles que les stagiaires expérimentés apprennent rapidement à exploiter. Une simulation entièrement réaliste est imprévisible et riche, mais peut être trop coûteuse en calcul, trop variable pour des besoins de formation contrôlés, ou trop difficile à valider par rapport aux normes doctrinales.
Chaque décision architecturale dans les logiciels de simulation militaire est façonnée par la position du système sur ce spectre, et cette position est une décision de conception de l'entraînement, pas une décision technologique. L'architecte logiciel doit comprendre les objectifs d'entraînement avant de spécifier l'architecture.
Le compromis déterminisme vs réalisme
Les systèmes de simulation d'entraînement se répartissent en trois grandes catégories selon leur position sur l'axe déterminisme-réalisme. Les simulations constructives (JCATS, MUSE, JTLS) sont fortement scriptées : le comportement de l'OpFor suit des arbres de décision programmés, les résultats sont déterministes pour des entrées définies, et la simulation est conçue pour être rejouée à des fins de comparaison. Ce sont le bon choix pour l'entraînement à la prise de décision au niveau des états-majors où la variable clé est les choix du stagiaire, pas le comportement de la simulation.
Les systèmes à forces semi-automatisées (SAF) se situent au milieu : les entités pilotées par IA suivent des modèles comportementaux avec des éléments stochastiques (probabilité de touche probabiliste, effets moraux, effets du terrain sur les mouvements), produisant une variation réaliste tout en restant suffisamment prévisibles pour être contrôlables par une Cellule Blanche (équipe de contrôle d'exercice). JANUS et OneSAF sont des exemples de cette catégorie.
Les simulateurs haute-fidélité (VESNA pour les pilotes UAV, simulateurs d'artillerie pour les équipages de chars) privilégient le réalisme de l'environnement physique et sensoriel sur la contrôlabilité du scénario. Ils utilisent des modèles physiques pour la balistique, l'aérodynamique et la simulation de capteurs, et sont utilisés pour l'entraînement aux compétences individuelles plutôt que pour les scénarios d'entraînement collectif.
Modèles de comportement OpFor pilotés par IA
Le comportement de l'OpFor (force opposée) en simulation est implémenté comme un système d'agents IA. Chaque entité OpFor (un véhicule, un groupe de combat, un quartier général) exécute un modèle comportemental qui observe l'état de la simulation, prend des décisions selon son modèle doctrinal, et émet des commandes de mouvement et d'engagement. La qualité de l'entraînement dépend fortement de la qualité de ces modèles comportementaux.
L'architecture standard pour l'IA OpFor est un planificateur de réseau de tâches hiérarchique (HTN) : un plan de mission de niveau supérieur (avancer, défendre, retarder) est décomposé en sous-tâches (se déplacer vers une position, établir un périmètre défensif, engager les menaces détectées) qui sont encore décomposées en actions primitives (déplacer le véhicule, tirer l'arme, demander un soutien). Le planificateur réévalue continuellement le plan actuel par rapport à l'état de la simulation et replanie lorsque les conditions changent.
Les systèmes modernes ajoutent des composants d'apprentissage par renforcement au comportement de l'OpFor : l'entité OpFor apprend, sur de nombreuses exécutions d'entraînement, quels choix tactiques réussissent contre les tactiques spécifiques utilisées par les stagiaires, produisant une opposition adaptative qui empêche les stagiaires d'exploiter des schémas scriptés. Cela augmente considérablement le réalisme de l'entraînement mais nécessite une contrainte soigneuse pour empêcher l'IA d'adopter un comportement tactiquement surhumain qui serait irréaliste et démoralisant plutôt qu'éducatif.
Moteurs de script de scénarios
Les concepteurs d'exercices ont besoin de créer et modifier des scénarios d'entraînement sans écrire de code. Le moteur de script de scénarios est l'interface entre les concepteurs d'exercices et la simulation : il fournit un environnement graphique pour placer les unités, définir les objectifs, scripter les déclencheurs (lorsque l'unité X atteint la position Y, injecter l'événement Z), et configurer les paramètres de comportement de l'OpFor.
Le moteur de script doit prendre en charge à la fois les éléments de scénario pré-planifiés (la disposition initiale des forces, les injects scriptés de la Cellule Blanche) et la modification dynamique du scénario (la Cellule Blanche ajuste le scénario en temps réel au fur et à mesure que l'exercice se développe, sans arrêter la simulation). Ce dernier nécessite une API d'injection d'événements qui permet à des entrées autorisées de modifier l'état de la simulation sans invalider la cohérence interne de la simulation.
Les formats de fichiers de scénarios devraient utiliser des schémas ouverts contrôlés en version (XML ou JSON) compatibles avec d'autres systèmes de simulation. Les formats de scénarios binaires propriétaires créent une dépendance et empêchent la réutilisation des scénarios entre les systèmes — un problème significatif pour les organisations d'entraînement qui exploitent plusieurs plateformes de simulation.
Systèmes de compte-rendu après action (AAR)
Le compte-rendu après action (AAR) est là où la valeur d'entraînement est réalisée. Un système AAR bien conçu doit rejouer l'exercice à partir de n'importe quel moment, annoté avec les décisions prises, les informations disponibles pour les décideurs à chaque instant, et les résultats. Cela nécessite un enregistrement continu de l'état de la simulation avec une résolution temporelle suffisamment élevée pour soutenir un rejeu précis.
La base de données AAR enregistre chaque changement d'état d'entité (position, statut, engagements) avec des horodatages à une résolution minimale de 1 seconde, et idéalement inférieure à la seconde pour les événements critiques (tirs d'armes, destructions de véhicules, transmissions de commandement). Le moteur de rejeu doit reproduire l'état exact à tout horodatage interrogé, supportant à la fois le rejeu en vitesse normale et en ralenti avec la possibilité de mettre en pause et d'interroger des entités spécifiques.
La capacité AAR la plus précieuse est le rejeu en perspective : montrer l'exercice depuis la perspective du décideur — quelles informations il avait à un moment spécifique (pas ce qui était vrai, mais ce que ses capteurs lui rapportaient) — plutôt que depuis une perspective omnisciente. Cela permet une analyse précise de pourquoi une décision a été prise et si elle était appropriée compte tenu des informations disponibles au moment, et pas seulement si le résultat était favorable.
Insight clé : Les normes High Level Architecture (HLA) et Distributed Interactive Simulation (DIS) existent précisément pour permettre l'interopérabilité des simulations — permettant à différents systèmes de simulation de partager un environnement synthétique commun. Construire un runtime de simulation propriétaire lorsqu'une simulation fédérée conforme HLA est nécessaire crée une charge de maintenance à long terme et un problème d'intégration. Utilisez les normes sauf s'il existe une raison technique impérieuse de ne pas le faire.
Moteurs de terrain et de physique
La simulation militaire nécessite une fidélité des données de terrain que les moteurs de jeux commerciaux ne priorisent pas : représentation précise des DTED (Digital Terrain Elevation Data), modèles de praticabilité de la végétation et du sol pour les déplacements hors-route, masquage des capteurs (l'unité A peut-elle détecter l'unité B compte tenu du terrain interposé ?), et calcul de la ligne de visée pour l'emploi des armes. La plupart des systèmes de simulation militaire utilisent un moteur de terrain dédié ou étendent un moteur de jeu commercial (Unreal, Unity) avec des modules de terrain spécifiques à la défense.
Les modèles balistiques doivent être calibrés sur les tables des systèmes d'armes — une simulation utilisant des modèles de projectiles linéaires génériques plutôt que des données de balistique extérieure spécifiques aux armes produira un entraînement qui enseigne des attentes de portée incorrectes. Pour l'entraînement aux armes à servants multiples, la précision du modèle balistique est une préoccupation directe de sécurité de l'entraînement.
Simulation de communications dégradées
L'une des capacités de simulation d'entraînement les plus sous-implémentées est la modélisation précise des communications dégradées. Les exercices s'exécutent généralement sur des réseaux simulés propres qui n'ont aucune ressemblance avec l'environnement RF contesté d'un conflit entre pairs. Une simulation qui injecte une dégradation réaliste des communications — basée sur les effets du terrain, les modèles de brouillage et la contention de bande passante — force les commandants et les états-majors à exercer les compétences décisionnelles dont ils auront réellement besoin en opérations. Cela nécessite une couche de simulation des communications qui modélise la propagation des signaux, les conflits de fréquences et les limites de bande passante, et applique ces contraintes au flux d'information dans la simulation.