Le mot simulation peut induire en erreur. Il ne s’agit ici ni de reconstituer une bataille complète, ni de faire « comme si » un système militaire existait déjà. Dans le domaine des drones et du cyber, la simulation peut remplir une fonction plus sobre et plus utile : servir de banc d’essai à la chaîne qui relie le capteur à la décision. On rejoue une mission simple, on introduit une perturbation connue dans les données ou les communications, puis on mesure ce que l’opérateur voit, comprend et décide. L’objet n’est pas de promettre un nouveau moteur complexe. Il est de décrire un dispositif qui peut être assemblé à partir de briques disponibles, puis complété, lorsque cela est nécessaire, par des essais sur matériel ou en vol contrôlé.
La guerre en Ukraine a rendu visible l’emploi massif des drones : il est estimé qu’environ 10 000 appareils sont engagés chaque jour par les deux camps1. Dès 2021, le Sénat français soulignait que ces systèmes étaient devenus incontournables et appelés à occuper une place croissante dans les zones de guerre2. Mais l’enjeu ne tient pas seulement au nombre de plates-formes. Chaque drone ajoute un capteur, une liaison, un logiciel, des métadonnées et une interface. Il augmente donc à la fois la capacité d’observation et le nombre de points où une situation peut être déformée avant d’arriver au chef.
La question utile n’est donc pas : peut-on simuler la guerre des drones ? Une telle ambition serait trop large et produirait rapidement un démonstrateur spectaculaire mais peu probant. La question réaliste est plus précise : comment tester, de manière répétable, la robustesse d’une chaîne capteur-transmission-interface-décision lorsqu’une information plausible devient inexacte, tardive ou contradictoire ?
Ne pas simuler la guerre : éprouver la chaîne capteur-décision
Un drone n’est pas seulement une cellule, un moteur, une charge utile et une liaison radio. Dans une mission de renseignement ou d’appui, il participe à une chaîne cyber-physique qui associe des capteurs, du calcul, des communications et une action dans le monde physique3. L’état réellement utile n’est pas celui du drone pris isolément, mais celui de l’ensemble : position du capteur, heure de la mesure, qualité de la liaison, traitement embarqué, fusion avec d’autres sources, présentation sur l’écran et procédure de validation.
Cette chaîne peut se dégrader sans panne franche. Une position GNSS peut dériver progressivement ; une image peut rester authentique tout en étant associée à une mauvaise coordonnée ; une trame peut être rejouée avec un horodatage plausible ; plusieurs pistes peuvent sembler se confirmer alors qu’elles proviennent de la même source. Les travaux sur le spoofing montrent précisément que la falsification ne se limite pas au brouillage : elle peut imiter ou déplacer le signal attendu4. Dans ce cas, le système continue de fonctionner. Le danger vient de sa crédibilité.
Pour éprouver cette vulnérabilité, il n’est pas nécessaire de reproduire la technique d’intrusion employée par un adversaire. Le banc d’essai peut se limiter à reproduire l’effet observable au point où il entre dans la chaîne. Une dérive de position peut être introduite dans la télémétrie ; un décalage temporel peut être ajouté à un flux ; une perte ou une duplication de paquets peut être imposée sur la liaison ; une contradiction peut être créée entre deux sources. Cette distinction est essentielle. Elle évite de transformer l’étude en programme de cyberattaque et permet de travailler sur ce qui intéresse directement l’emploi : la manière dont la chaîne réagit.
Une information fausse ne produit un effet militaire que lorsqu’elle devient une représentation admise, puis une décision.
Chaque essai doit donc partir d’une vérité de terrain connue. Une mission courte suffit : reconnaître un axe, suivre quelques pistes, confirmer ou infirmer la présence d’un objet, puis transmettre une appréciation. L’évaluateur sait où se trouvent réellement les pistes et à quel moment les données ont été altérées. L’opérateur, lui, ne connaît ni la nature ni l’instant de la perturbation. On peut alors observer un phénomène précis : détecte-t-il l’anomalie, la signale-t-il, cherche-t-il une source indépendante, maintient-il sa décision ou la corrige-t-il ?
Le périmètre doit rester volontairement limité. Il ne s’agit ni de prédire un engagement futur, ni de représenter l’ensemble d’un théâtre, ni de conclure qu’une vulnérabilité observée dans un banc existe à l’identique en opération. Le dispositif sert à isoler un mécanisme et à comparer des réponses. Sa valeur vient de cette modestie : la même mission peut être rejouée avec une seule variable modifiée.
Un dispositif minimal fondé sur des composants existants
Un premier banc ne nécessite pas le développement d’un simulateur propriétaire. Les écosystèmes de pilotes automatiques courants disposent déjà de modes software-in-the-loop, dans lesquels le logiciel de vol fonctionne sur un ordinateur sans aéronef, ainsi que, selon les configurations, de modes hardware-in-the-loop utilisant un contrôleur réel. Ils permettent également de connecter une station sol et de faire fonctionner plusieurs véhicules virtuels5. Le travail spécifique consiste donc moins à créer le vol qu’à instrumenter les échanges, à introduire des perturbations définies et à enregistrer les réactions.
Le niveau de départ peut tenir dans une salle : un poste exécute les véhicules virtuels et le scénario ; un second affiche la station de contrôle utilisée par l’opérateur ; un module placé sur le réseau modifie certains flux ; un enregistreur conserve la télémétrie, les journaux, les écrans et les décisions. Des outils d’émulation réseau existants permettent d’ajouter de manière contrôlée du délai, de la perte, de la duplication ou de la corruption de paquets6. Une feuille de conduite précise, pour chaque essai, la mission nominale, la perturbation, son instant d’apparition et la condition de fin.
Premier niveau – logiciel seulement. C’est le niveau à privilégier pour commencer. Quelques véhicules virtuels exécutent une mission simple. La perturbation est injectée dans la télémétrie, les métadonnées ou le réseau. Aucun effet radio n’est nécessaire, aucune zone de vol n’est mobilisée et le scénario peut être répété immédiatement. Ce niveau permet de vérifier que l’injection est maîtrisée, que les journaux sont exploitables et que les indicateurs répondent bien à la question posée.
Deuxième niveau – matériel dans la boucle. Un contrôleur de vol réel, voire un élément de la liaison, est ajouté au banc afin de vérifier que les comportements observés ne dépendent pas uniquement d’une abstraction logicielle. Ce niveau n’a de sens qu’après stabilisation du protocole. Il ne faut pas le présenter comme une condition initiale : sa faisabilité dépend du matériel retenu, de ses interfaces et du niveau d’accès disponible.
Troisième niveau – essai en vol limité. Un ou deux drones peuvent ensuite reprendre la mission dans une zone contrôlée. Les perturbations les plus simples restent produites dans la chaîne de données ou à la station sol ; les émissions radio ou GNSS sensibles ne sont pas nécessaires pour valider la logique générale. L’essai en vol vérifie surtout les effets que le banc logiciel représente mal : contraintes de pilotage, qualité réelle des liaisons, charge de travail, météo, interruptions et coordination entre opérateurs.
Cette progression évite trois écueils fréquents : commencer par un essaim nombreux, développer une scène 3D détaillée ou ajouter une intelligence artificielle avant d’avoir défini la mesure. Aucun de ces éléments n’est indispensable au premier résultat. Le noyau utile est beaucoup plus simple : une vérité terrain, un flux observable, une perturbation maîtrisée, une décision attendue et un journal complet de ce qui s’est produit.
Matrice d’essais réalisable au premier niveau
| Essai | Injection contrôlée | Question opérationnelle | Mesure principale |
| Dérive de position | Décalage progressif d’une coordonnée dans la télémétrie. | L’opérateur détecte-t-il qu’une piste crédible se déplace anormalement ? | Temps de détection et erreur de position au moment de la décision. |
| Donnée ancienne | Retard ou rejeu d’une image et de son horodatage. | L’âge de la donnée est-il identifié avant validation ? | Âge de la donnée validée et nombre d’actions fondées sur un état dépassé. |
| Liaison dégradée | Délai, pertes ou duplications de paquets. | La procédure reste-t-elle stable lorsque le flux devient intermittent ? | Maintien de mission, erreurs et temps de retour à un flux exploitable. |
| Sources contradictoires | Deux capteurs donnent des positions ou identifications incompatibles. | Une source indépendante est-elle recherchée ou le premier affichage domine-t-il ? | Taux de recoupement, temps de décision et correction éventuelle. |
| Piste dupliquée | Duplication d’un identifiant ou d’une piste dans l’entrée de fusion. | Un faux consensus augmente-t-il artificiellement la confiance ? | Taux de validation erronée et niveau de confiance déclaré. |
Chaque essai est exécuté au moins sous trois conditions : fonctionnement nominal, perturbation sans contre-mesure, puis perturbation avec une correction précise. Cette correction peut être technique – affichage explicite de l’âge de la donnée, alerte de contradiction, séparation des sources – ou procédurale – double validation, demande de recoupement, suspension temporaire de l’action. L’intérêt n’est pas de multiplier les scénarios, mais de savoir si une modification identifiable améliore réellement la décision.
Des résultats limités, mais directement exploitables
Le banc ne produit pas une vérité générale sur la guerre des drones. Il fournit des résultats locaux, attachés à une mission, une interface, une organisation et un type de perturbation. C’est précisément ce qui les rend utilisables. On peut comparer deux versions d’un affichage, deux règles de validation ou deux compositions d’équipe sans changer le reste du scénario.
Les indicateurs doivent rester peu nombreux et reliés à l’emploi : temps de détection de l’anomalie, proportion de validations erronées, délai de récupération, écart entre la confiance déclarée et la fiabilité réelle, nombre de contradictions effectivement recoupées, décision finale et justification donnée. La conscience de la situation suppose de percevoir, comprendre et projeter l’évolution d’un environnement dynamique7. L’objectif n’est donc pas d’évaluer la qualité théorique du capteur, mais de voir à quel moment l’information disponible cesse de soutenir une représentation suffisamment juste pour agir.
Trois livrables sont réalistes. Le premier est un protocole reproductible : fichiers de mission, paramètres de perturbation, journaux attendus et règles d’évaluation. Le deuxième est une cartographie des fragilités observées : endroit où l’erreur entre, manière dont elle se propage, décision qu’elle modifie et condition qui permet de la corriger. Le troisième est un ensemble de règles d’action limitées à la configuration testée : afficher l’âge des données, distinguer les sources réellement indépendantes, imposer un recoupement au-delà d’un certain désaccord, ou suspendre une validation lorsque la confiance affichée repose sur une seule origine.
Ce que le dispositif ne doit pas promettre est tout aussi important. Il ne certifie pas la cybersécurité d’un drone. Il ne démontre pas qu’un adversaire possède effectivement l’accès nécessaire pour produire la perturbation. Il ne remplace ni l’analyse du code, ni les essais électromagnétiques, ni les vols d’évaluation. Enfin, il ne transforme pas automatiquement une observation en doctrine générale. Les seuils obtenus ne valent que pour le matériel, l’interface, la mission et les opérateurs testés.
En revanche, il crée un langage commun entre l’utilisateur, l’ingénieur, le spécialiste cyber et le formateur. Tous peuvent revoir le même incident, vérifier la même chronologie et discuter de la même décision. Une anomalie qui restait abstraite devient une séquence observable : donnée altérée, alerte absente ou ignorée, représentation modifiée, choix effectué, correction tardive ou réussie. Le banc permet alors de décider ce qui doit être modifié en premier : le flux, l’interface, la procédure ou l’entraînement.
La simulation trouve ici sa valeur militaire non dans le spectacle, mais dans la répétabilité. Le projet réaliste n’est pas un champ de bataille virtuel complet et encore moins la promesse d’un jumeau numérique de la guerre. C’est une chaîne instrumentée, volontairement courte, qui permet de rejouer une même mission sous perturbation et de mesurer ce qui change. On commence avec du logiciel disponible ; on ajoute du matériel seulement lorsqu’une question le justifie ; on passe au vol pour vérifier ce que le banc ne peut pas représenter.
Il ne s’agit donc pas de faire comme si la guerre avait lieu. Il s’agit de vérifier, avant elle, ce qu’une chaîne de décision fait lorsqu’une information plausible cesse d’être vraie.
La tribune est disponible ci-dessous
- Lefief, J.-P. (2026). « Comment l’Ukraine a su imposer, au moins pour un temps, sa maîtrise des données numériques issues des champs de bataille ». Le Monde, 15 mai 2026. ↩︎
- Perrin, C. et al. (2021). Se préparer à la « guerre des drones » : un enjeu stratégique. Rapport d’information n° 711 (2020-2021), Sénat. ↩︎
- Monostori, L. (2014). « Cyber-physical Production Systems: Roots, Expectations and R&D Challenges ». Procedia CIRP, 17, p. 9-13. DOI : 10.1016/j.procir.2014.03.115. ↩︎
- Van Der Merwe, J. R., Zubizarreta, X., Lukčin, I., Rügamer, A. et Felber, W. (2018). « Classification of spoofing attack types ». 2018 European Navigation Conference, p. 91-99. ↩︎
- PX4 Autopilot, « Simulation », PX4 Guide ; ArduPilot Project, « SITL Simulator (Software in the Loop) », documentation officielle, consultées en août 2026. Ces environnements prennent en charge la simulation logicielle et, selon les configurations, la simulation avec matériel dans la boucle et plusieurs véhicules. ↩︎
- Linux man-pages project, tc-netem(8). La discipline netem permet d’émuler notamment le délai, la perte, la duplication et la corruption de paquets. ↩︎
- Endsley, M. R. (1995). « Toward a Theory of Situation Awareness in Dynamic Systems ». Human Factors, 37(1), p. 32-64. DOI : 10.1518/001872095779049543. ↩︎
