Pendant mes vacances, j'ai construit un simulateur de défense anti-drone

Oui, mes vacances sont parfois un peu particulières.

Certains lisent au bord de la piscine. D'autres visitent des musées.

Moi, entre deux activités un peu plus normales, j'ai sorti une radiocommande, lancé un simulateur de drone FPV… et commencé à me demander :

« Est-ce que je serais capable de construire un petit simulateur d'attrition pour une défense de zone ? »

Pas un outil militaire opérationnel, ce n'est pas mon métier, en tout cas aujourd'hui ! Et non, pas un logiciel destiné à prédire précisément ce qui se passerait sur un champ de bataille : il faudrait bien plus d'heures de travail là-dessus.

Simplement un prototype permettant de manipuler quelques concepts : des drones, des radars, du relief, des trajectoires, des probabilités de détection et un stock limité d'intercepteurs.

Et comme souvent avec les projets personnels, cette petite question a fini par m'emmener beaucoup plus loin que prévu.

Les drones et moi, ce n'est pas complètement nouveau

J'aime les drones depuis longtemps. Le concept d'avoir à portée de main des capacités aériennes m'a toujours fasciné.

Il y a environ sept ans, lorsque je travaillais chez Golem.ai, nous avions déjà fait une petite expérimentation qui consistait à faire décoller un drone à distance grâce à de la reconnaissance vocale. Une chaîne assez simple : voix → speech-to-text → compréhension du langage → commande → drone. Le retour vidéo arrivait directement sur mon ordinateur.

À l'époque, nous avions même discuté d'utilisations plus ludiques de ce type de technologie : paintball augmenté, interactions entre joueurs et machines, pilotage simplifié…

L'actualité des dernières années a malheureusement montré que les usages de ces appareils dépasseraient très largement le divertissement.

Aujourd'hui, je continue donc d'apprendre à les piloter. Principalement sur simulateur (Uncrashed pour les néophytes ;), avec une RadioMaster). Parce que les arbres, eux, n'ont toujours pas appris à esquiver.

Une question simple : une défense peut-elle réellement tenir ?

Quand on regarde les caractéristiques d'un système, on raisonne facilement en fiches techniques. Un radar porte à X kilomètres. Un intercepteur se déplace à telle vitesse. Un drone arrive à telle altitude.

Et intuitivement, on finit par dessiner de beaux cercles autour des systèmes.

C'est exactement la question que je voulais explorer. J'ai donc construit un petit outil permettant de positionner :

• ▸une zone à défendre ;
• ▸des radars ;
• ▸des observateurs ;
• ▸une base contenant un nombre limité de drones intercepteurs ;
• ▸un front d'attaque ;
• ▸différentes trajectoires d'intrusion.

Le simulateur fait ensuite évoluer chaque drone dans le temps, vérifie s'il peut être détecté, regarde si un intercepteur est disponible et estime si l'intrus peut être arrêté avant d'atteindre la zone protégée.

Dit comme ça, cela paraît presque trivial. Ça ne l'est pas.

Mon premier système de défense possédait des drones infinis

Et c'est probablement mon bug préféré du projet.

Dans une première version, j'avais bien défini qu'une base possédait, par exemple, sept drones. Sauf que lorsque le simulateur lançait une interception… je ne retirais jamais réellement le drone utilisé du stock.

Résultat :

• ▸trois attaquants ;
• ▸un seul intercepteur ;
• ▸trois interceptions.

Une innovation remarquable dans la logistique militaire : le drone recyclable instantanément.

C'est une erreur idiote. Mais elle illustre quelque chose d'assez fondamental dans ce genre de simulation.

La question intéressante n'est pas uniquement :

« Est-ce que ce système peut intercepter cette cible ? »

Elle devient :

« Combien d'attaques peut-il absorber avant de ne plus pouvoir répondre ? »

Et là, on commence à parler d'attrition, de saturation, de redondance et de dimensionnement. Le problème change complètement.

Le cercle du radar ment un peu

J'ai ensuite voulu ajouter quelque chose que je trouvais indispensable : le relief réel. Parce qu'un radar annoncé avec une portée de plusieurs dizaines de kilomètres ne voit évidemment pas de la même manière dans une plaine que derrière une montagne.

Une montagne a cette désagréable habitude de ne pas lire les brochures commerciales.

La carte du prototype intègre donc déjà les données d'altitude et permet de placer les différents capteurs directement sur le relief réel.

L'objectif, à terme, est de ne plus représenter uniquement la portée théorique du radar par un cercle, mais de calculer ce qu'il peut réellement voir en fonction du terrain : sommets, vallées, masques liés au relief, hauteur du capteur, etc.

Et c'est précisément la partie sur laquelle je travaille encore. J'ai déjà une première implémentation de la ligne de vue, mais elle n'est pas suffisamment fiable pour que je considère le problème comme réglé. Certaines zones sont correctement masquées, d'autres pas encore, et il reste quelques cas où le résultat affiché ne correspond manifestement pas au terrain.

Ce qui est finalement assez intéressant en soi : faire apparaître le relief sur une carte est relativement simple. Faire en sorte que la simulation le comprenne correctement l'est beaucoup moins.

Pour l'instant, le cercle représente donc encore principalement la portée théorique du capteur. Mais l'objectif est justement de pouvoir montrer progressivement l'écart entre ce que promet la fiche technique et ce que permet réellement le terrain.

C'est probablement l'une des prochaines briques que j'ai le plus envie de terminer sur ce prototype.

Des caractéristiques publiques de drones français et ukrainiens

Pour rendre l'exercice un peu plus intéressant, j'ai récupéré sur Internet des caractéristiques publiquement disponibles concernant différents drones et systèmes d'interception français et ukrainiens.

Pas pour prétendre reproduire leurs performances réelles. Il manque évidemment énormément d'informations pour cela : comportement réel, guidage, communications, météo, contre-mesures, doctrine d'emploi, qualité des opérateurs…

L'objectif était simplement de disposer d'ordres de grandeur plausibles et de pouvoir comparer différents types de machines. Je suis allé chercher ce qui était disponible, comme Alta Ares ou Wild Hornets par exemple.

Cela permet déjà de constater quelque chose d'intéressant : un drone n'est pas « bon » ou « mauvais » dans l'absolu. Une machine rapide, une machine bon marché, une machine endurante ou une machine capable d'emporter davantage de charge ne répondent pas au même problème.

Et lorsqu'on les replace dans un système complet, leurs caractéristiques individuelles ne racontent qu'une partie de l'histoire.

Quand une simulation ne suffit plus : Monte-Carlo

À ce stade, mon simulateur pouvait déjà faire évoluer un scénario. Un drone arrive. Un radar essaie de le détecter. Un intercepteur est éventuellement lancé. La cible atteint ou non la zone à défendre.

Le problème, c'est qu'une exécution unique ne raconte presque rien.

Imaginons que mon radar ait une probabilité de détection de 90 %. Je lance la simulation une fois : le drone est détecté. Puis-je en conclure que mon dispositif fonctionne ?

Évidemment non. Je pourrais tout aussi bien relancer exactement le même scénario et tomber cette fois dans les 10 % où la détection échoue.

C'est précisément pour répondre à ce genre de problème qu'existent les méthodes de Monte-Carlo.

Par exemple :

• ▸le radar détecte ou non une cible ;
• ▸une interception réussit ou échoue ;
• ▸un événement survient plus ou moins tôt ;
• ▸certaines caractéristiques peuvent légèrement varier ;
• ▸une trajectoire peut différer dans les limites définies.

Une simulation devient alors un tirage parmi de nombreuses évolutions possibles du même scénario. J'en lance 10. Puis 100. Puis 1 000.

Et au lieu d'obtenir une réponse du type :

« Le drone a été intercepté. »

j'obtiens quelque chose de beaucoup plus utile :

« Sur 1 000 simulations, le drone a été intercepté dans 73 % des cas. »

Ou encore :

« Dans 42 % des simulations, la défense est saturée avant la fin de l'attaque. »

Sur un scénario complet, on obtient alors une lecture de ce type : 81 % des attaques détectées, 64 % interceptées, 36 % atteignant malgré tout la zone, et une défense saturée dans certaines configurations.

On ne dit donc plus « ça fonctionne ». On commence à dire : dans ces hypothèses, cette configuration fonctionne dans X % des cas. On ne cherche plus à prédire exactement ce qui va se passer, on cherche à mesurer la distribution des résultats possibles.

Et cette différence est fondamentale.

D'où vient ce nom un peu étrange ?

Le nom « Monte-Carlo » vient évidemment du célèbre casino monégasque. La méthode s'est développée dans les années 1940, notamment autour des travaux menés à Los Alamos pendant le projet Manhattan.

Les chercheurs étaient confrontés à des problèmes physiques extrêmement complexes pour lesquels une résolution analytique exacte devenait difficile, voire impossible. L'idée était alors de remplacer une partie du calcul direct par des échantillonnages aléatoires répétés.

Dit autrement : si je ne peux pas facilement calculer toutes les possibilités d'un système, je peux en simuler énormément et observer ce qui se passe statistiquement. C'est particulièrement puissant lorsque le nombre de combinaisons possibles explose.

Un exemple très simple

Prenons un exemple volontairement simplifié. Un radar a 80 % de chances de détecter un drone. Si le drone est détecté, un intercepteur a ensuite 70 % de chances de réussir son interception.

On pourrait essayer de calculer directement la probabilité finale. Dans ce cas simple, c'est facile. Mais ajoutons maintenant :

• ▸plusieurs radars,
• ▸plusieurs drones,
• ▸des portées différentes,
• ▸des temps d'arrivée différents,
• ▸un nombre limité d'intercepteurs,
• ▸des probabilités variables,
• ▸du relief,
• ▸des priorités d'engagement,
• ▸et plusieurs trajectoires.

Très vite, les interactions deviennent suffisamment nombreuses pour que le système soit difficile à raisonner à la main. Monte-Carlo permet alors de dire : « fais tourner ce scénario 10 000 fois et montre-moi ce qui se passe. »

Puis on regarde :

• ▸combien d'intrus passent ;
• ▸combien sont interceptés ;
• ▸à quel moment la défense sature ;
• ▸combien d'intercepteurs sont consommés ;
• ▸quels capteurs sont les plus sollicités ;
• ▸quelles configurations échouent le plus souvent.

Et surtout, on peut comparer plusieurs architectures.

Ce n'est pas seulement utile pour les drones

C'est justement ce que je trouve intéressant avec Monte-Carlo : cette méthode est utilisée dans énormément de domaines, souvent très loin de l'intelligence artificielle générative.

Finance

C'est probablement l'un des usages les plus connus. On peut simuler des milliers de trajectoires possibles pour le prix d'un actif, un portefeuille ou un taux d'intérêt.

L'objectif n'est pas de prédire exactement le cours de demain. C'est plutôt d'estimer :

• ▸la probabilité d'une perte ;
• ▸la distribution des rendements ;
• ▸le niveau de risque ;
• ▸le comportement d'un portefeuille dans différents scénarios.

Les simulations Monte-Carlo sont notamment utilisées dans des problématiques de valorisation, de gestion des risques ou de stress testing.

Assurance

Même logique. Une compagnie d'assurance peut simuler des milliers ou des millions de scénarios de sinistres. Combien d'accidents ? Quelle sévérité ? À quelle fréquence ? Avec quelles corrélations ?

Cela permet ensuite d'estimer les réserves nécessaires ou la probabilité d'un scénario extrême.

Industrie et fiabilité

Imaginez une usine avec plusieurs composants. Chaque pièce possède une probabilité de panne. Certaines pannes sont indépendantes, d'autres peuvent provoquer des défaillances en cascade.

Une simulation Monte-Carlo permet de tester des milliers de vies possibles du système afin d'estimer :

• ▸son taux de disponibilité ;
• ▸son risque de panne ;
• ▸sa durée de vie ;
• ▸l'impact d'une maintenance préventive.

Logistique

On peut également l'utiliser pour simuler des chaînes logistiques. Retard d'un fournisseur. Variation des délais de livraison. Indisponibilité d'une ressource. Variation de la demande.

Plutôt que de construire un seul planning idéal, on teste le comportement du système face à des milliers de perturbations.

Énergie

Dans un réseau électrique, beaucoup de paramètres varient : production solaire, vent, consommation, pannes, prix, disponibilité des moyens de production. Monte-Carlo peut servir à évaluer la robustesse du réseau face à cette variabilité.

Médecine et recherche scientifique

La méthode est aussi utilisée pour simuler des phénomènes biologiques, physiques ou radiologiques. Par exemple, pour modéliser le trajet de particules dans la matière, les interactions moléculaires ou certains phénomènes complexes où une approche analytique devient trop coûteuse.

Informatique et cybersécurité

On peut également tester la résilience d'une architecture informatique. Que se passe-t-il si tel serveur tombe ? Puis un deuxième ? Si certains paquets sont perdus ? Si une charge arrive plus tôt que prévu ?

L'idée reste la même : injecter de l'incertitude, répéter, observer la distribution des résultats.

Pourquoi Monte-Carlo est encore extrêmement actuel

Ce qui me plaît avec cette méthode, c'est qu'elle a plus de 70 ans et qu'elle reste parfaitement moderne. Parce qu'elle répond à un problème qui, lui, n'a jamais disparu : le monde réel est incertain.

Nous avons souvent tendance à construire des modèles avec une valeur unique. Un temps moyen. Une vitesse moyenne. Un taux de détection moyen. Un coût moyen.

Mais une moyenne peut cacher énormément de choses. Deux systèmes peuvent avoir exactement la même performance moyenne tout en ayant des comportements très différents. L'un peut être extrêmement stable. L'autre peut être excellent 80 % du temps et catastrophique les 20 % restants.

Monte-Carlo permet justement de voir cette différence. C'est la raison pour laquelle cette méthode est particulièrement utile lorsqu'on s'intéresse à :

• ▸la robustesse ;
• ▸la saturation ;
• ▸le risque ;
• ▸les valeurs extrêmes ;
• ▸les chaînes d'événements ;
• ▸l'incertitude.

Et cela correspond assez bien à mon petit simulateur. Je ne cherche pas vraiment à savoir « est-ce qu'un drone donné va passer ? ». Je cherche plutôt à répondre à : si je rejoue cette attaque des centaines de fois, à quelle fréquence mon dispositif tient-il ?

Et non, ce n'est pas un LLM

C'est aussi une bonne occasion de revenir sur une confusion que l'on fait de plus en plus. Lorsque l'on parle aujourd'hui d'intelligence artificielle, beaucoup de personnes pensent immédiatement à ChatGPT, Claude, Gemini ou Mistral.

Mais une grande partie des problèmes industriels ne consiste pas à générer du texte. Il faut parfois optimiser, classifier, chercher, simuler, prévoir, ou simplement calculer.

Monte-Carlo n'est d'ailleurs pas une IA générative. Ce n'est même pas nécessairement de l'apprentissage automatique.

C'est presque l'exact opposé de l'imaginaire actuel autour de l'IA. Et pourtant, pour certains problèmes, c'est infiniment plus pertinent.

Monte-Carlo ne donne pas une réponse, mais une confiance

C'est peut-être la partie la plus importante. Une simulation déterministe donne souvent une sortie. Monte-Carlo donne une distribution.

Cela permet de commencer à parler de choses comme :

• ▸la médiane ;
• ▸les percentiles ;
• ▸la variance ;
• ▸les probabilités de dépassement ;
• ▸les scénarios rares ;
• ▸les intervalles de confiance.

Et à partir de là, on peut enfin prendre des décisions plus intéressantes. Par exemple : « cette configuration arrête 95 % des attaques. » C'est déjà utile.

Mais on peut aller plus loin :

« Elle arrête 95 % des attaques dans les scénarios normaux, mais tombe à 61 % lorsqu'on double le nombre d'intrus. »

Là, on commence à voir apparaître le véritable intérêt de la simulation. On ne mesure plus seulement une performance : on mesure la fragilité du système.

Pourtant, l'IA a joué un rôle énorme dans ce projet

Et c'est là que l'histoire devient un peu paradoxale. Le simulateur ne repose pas sur un modèle d'IA type LLM. Mais je l'ai largement construit avec l'aide d'un assistant IA.

C'est probablement l'un des meilleurs exemples que j'ai eus récemment de ce que l'on appelle désormais le vibe coding.

• 01Je décris une fonctionnalité.
• 02Je produis une première implémentation.
• 03Je teste.
• 04Je casse quelque chose.
• 05Je corrige.
• 06Je demande une nouvelle fonctionnalité.
• 07Je re-teste.

En quelques jours, j'ai pu arriver à un prototype avec une interface cartographique, du relief 3D, des lignes de vue, différentes unités, une timeline de simulation, des statistiques et des scénarios reproductibles.

Il y a encore quelques années, un projet personnel de ce type m'aurait probablement demandé suffisamment de temps pour que je ne commence tout simplement jamais.

C'est là, pour moi, que les assistants de programmation changent réellement quelque chose. Ils diminuent énormément le coût de l'expérimentation.

Mais le vibe coding ne supprime pas le besoin de comprendre ce que l'on construit

C'est même presque l'inverse. Les bugs les plus intéressants de ce projet n'étaient pas forcément des erreurs de syntaxe. C'étaient des erreurs de logique.

• ▸Le fameux intercepteur qui ne disparaissait jamais.
• ▸Une caméra 3D qui s'ouvrait très loin de la zone étudiée.
• ▸Des objets graphiques qui capturaient les clics et empêchaient d'en positionner d'autres.
• ▸Une simulation techniquement fonctionnelle mais conceptuellement absurde.

L'assistant peut écrire extrêmement rapidement une fonction. Il ne sait pas forcément que la fonction qu'on lui demande n'a aucun sens par rapport au problème réel.

Et plus le coût d'écriture du code diminue, plus une autre compétence devient importante : savoir tester, questionner et challenger ce que l'on vient de construire.

Le travail ne disparaît pas. Il se déplace.

Ce que je retiendrai de ce projet

Je suis parti d'une question de vacances : « est-ce que je peux fabriquer ça ? »

Et j'ai fini avec un petit laboratoire permettant d'explorer du relief, des capteurs, de la saturation et des probabilités.

Ce prototype ne prétend évidemment pas représenter fidèlement la réalité opérationnelle d'un système de défense. Et ce n'était pas son objectif. Ce qui m'intéressait était ailleurs :

• ▸comprendre comment quelques règles simples commencent à produire des comportements complexes ;
• ▸voir comment le terrain remet immédiatement en cause une fiche technique ;
• ▸expérimenter avec des données publiques ;
• ▸tester jusqu'où un assistant IA pouvait accélérer la création d'un outil totalement nouveau pour moi.

Et surtout revenir à quelque chose que je considère essentiel lorsqu'on travaille dans l'IA :

Parfois, la bonne réponse est un LLM. Parfois, c'est un modèle spécialisé. Parfois, c'est Monte-Carlo.

Et parfois… c'est juste un -1 qu'on avait oublié d'appliquer au nombre de drones disponibles.