kamrulkonok/evalllm2026-french-defense huggingface dataset:
Maquette-IA-DEFENSE_2025_VDEF_WEB.pdf — page 33

33
outils d’IA générative, au-delà de leur fonctionnalité 
première, apportent des méthodes de clustering 
latent[1]. Utilisant les mêmes types d’architecture, ces 
LLMs as a judge[2] sont une sorte de « remède dans le 
poison » permettant un audit à l’échelle pour garantir 
des comportements alignés avec les attentes fixées. 
L’approche agentique précédemment évoquée 
devient alors une solution d’audit, où chaque agent 
déployé se spécialise et apporte un prisme d’analyse 
additionnel et complémentaire aux précédents. 
L’humain n’est pas laissé en dehors de la boucle 
algorithmique, comme il se positionne en « contremaître 
», disposant d’une vue panoptique assistée par IA. 
Se pose en parallèle la question de la mise à jour des outils 
analytiques des crises créées par des acteurs humains (e.g. 
Disarm, Stix) [3] : comment les adapter aux accélérations 
technologiques et garantir leur efficacité à l’échelle ? 
 
Des données, toujours des données
 
L’accès à des données de qualité, et conséquemment 
la création synthétique de jeux de données adaptés 
et représentatifs, est un enjeu majeur pour le 
développement des solutions de contrôle. Par exemple, 
comment s’assurer qu’un modèle est bien aligné avec nos 
valeurs, sans données pour les caractériser ? Comment 
entraîner des agents spécialistes de prompt-injection[4], 
sans exemples pour les entraîner ? Comment être plus 
efficace et plus rapide (i.e. des modèles spécialistes 
plutôt que des modèles généralistes), sans données 
spécialisées ? A contrario de la promesse algorithmique 
de ces dernières années (« donnez-moi tout Internet 
et je vous rendrai un modèle qui a réponse à tout »), 
les données de haute qualité n’ont jamais été aussi 
précieuses, en ce qu’elles font mouche à chaque fois. 
Elles sont la base de toute possibilité de génération de 
scénarios de synthèse pour garantir la robustesse des 
modèles, en allant explorer en profondeur les failles 
potentielles, sur des sujets précis dont les modèles sont 
moins familiers, mais tout autant attendus au tournant. 
Cette augmentation des capacités d’audit, dans une 
optique de red-teaming[5] / blue-teaming[6]assistés par 
l’IA, est une des conditions de mitigation des crises à venir.
Maquette-IA-DEFENSE_2025_VDEF_WEB.pdf — page 35

35
d’attaque, identifier les vulnérabilités les plus 
importantes et élaborer une checklist reproductible 
tenant compte des standards, des spécificités 
des assets et de la priorisation des risques.
4.	
Industrialisation : Intégrer la checklist dans une 
plateforme de sécurité offensive sous la forme d’un 
guide de test digitalisé pour systématiser les tests 
offensifs tout au long du cycle de vie des assets.
5.	
Partage et mise à jour : lorsque cela est possible, 
diffuser publiquement les checklists pour 
renforcer les compétences de la communauté des 
chercheurs, diffuser les bonnes pratiques dans les 
organisations et faciliter une mise à jour régulière 
au fur et à mesure de l’évolution des menaces.
Ces deux expérimentations ont atteint leurs objectifs 
et cette méthodologie a prouvé dans deux contextes 
différents qu’il est possible d’industrialiser les tests de 
sécurité en seulement quelques mois, même dans le 
cadre de systèmes sensibles. Elle peut être appliquée aux 
tests de sécurité et de résilience des IA, notamment LLM.
Une recette simple pour sécuriser les IA
Pour 
résumer, 
il 
apparaît 
que 
les 
leviers 
de 
l’industrialisation des tests de sécurité des IA sont les 
suivants :
•	
Plateforme de tests de sécurité offensive intégrant 
un système de checklists et adaptable aux 
contraintes d’hébergement.
•	
Intégration des standards existants (ex: Checklist 
OWASP Top 10 LLM 2025 pour les IA Générative)
•	
Collaboration interdisciplinaire : mobiliser des 
experts variés internes et externes pour combler 
les lacunes des standards.
•	
Création et systématisation des checklists : 
développer de nouvelles checklist pour les assets 
spécifiques et intégrer les tests tout au long de 
leur cycle de vie.
•	
Partage des connaissances : diffuser en interne 
et, si possible, publiquement les résultats pour 
renforcer le partage des bonnes pratiques et le 
développement de nouveaux standards.
Une sécurité résiliente dès la conception
C’est en généralisant cette approche collaborative et 
méthodique que nous pourrons regagner du terrain face 
aux technologies émergentes et développer les IA de 
confiance dans le domaine de la Défense. Elle est à même 
de garantir une sécurité renforcée et une résilience des 
écosystèmes IA grâce à une approche “Security by Design”, 
qui protège les systèmes tout au long de leur cycle de vie.
Maquette-IA-DEFENSE_2025_VDEF_WEB.pdf — page 47

47
Parallèlement, la mise en place d’un mécanisme de 
validation neuro-symbolique est recommandée. Ce 
système effectuera une vérification automatique des 
résultats par des techniques d’IA symbolique tels que 
des systèmes à base de règles ou des graphes de 
connaissance. Il attribuera un score de fiabilité basé sur des 
modèles alternatifs, et vérifiera la conformité aux normes 
de sécurité pour éviter toute dérive du modèle principal.
4.	 Maîtrise des modèles et amélioration continue 
Un ou plusieurs grands modèles de langage (LLM) 
pourront être utilisés selon les cas d’usages, sachant 
que des modèles généralistes seront plus souples à 
l’usage mais moins précis que des modèles spécialistes, 
notamment pour la production de code ou d’architectures 
techniques. On privilégiera des modèles souverains ou 
open sources contrôlées pour limiter les dépendances à 
des solutions propriétaires non maîtrisées. Leur précision 
à l’usage pourra être améliorée par des techniques 
d’affinement ou de renforcement. L’intégration d’un 
mécanisme de récompense par feedback humain 
permettra d’alimenter une boucle d’amélioration 
continue. Toutefois, l’empoisonnement des données 
d’affinage ou des récompenses sont des menaces internes 
à surveiller. Des mécanismes de signature, de détection 
et de correction des biais du modèle peuvent y remédier.
 
5.	
Supervision et gestion des incidents
Une détection proactive et une réponse rapide aux 
menaces sont essentielles. Les personnels du Centre 
d’Opérations de Sécurité (SOC) doivent être formés 
à reconnaître et traiter des attaques spécifiques à 
l’IA, telles que l’empoisonnement, l’évasion, l’inversion 
de modèle ou l’injection de prompt. Une analyse en 
temps réel des journaux système et du comportement 
des utilisateurs est recommandée afin d’identifier 
toute anomalie, gérer centralement les incidents de 
cyber-sécurité et mettre en place des contre-mesures 
adaptées. Une veille systématique sur les menaces et 
les vulnérabilités spécifiques à l’IA devra être assurée. 
De plus, il conviendra de surveiller les évolutions 
réglementaires et d’assurer une mise en conformité 
continue de la plateforme avec les normes de sécurité.
Conclusion
L’intégration de l’IA générative dans l’ingénierie des 
systèmes critiques est une avancée majeure qui 
soulève des défis de sécurité, de souveraineté et 
d’explicabilité. Le présent article propose une réponse 
à ces enjeux à travers des préconisations : 1) Protection 
de l’Infrastructure Matérielle, 2) Sécurisation des 
interactions homme-machine, 3) Contrôle des sources 
et vérification des sorties, 4) Maîtrise des modèles et 
amélioration continue, 5) Supervision et gestion des 
incidents. Une application des bonnes pratiques en 
vigueur en matière de sécurité informatique traite déjà 
une grande partie des risques identifiés. Néanmoins, 
une compréhension des menaces et vulnérabilités 
spécifiques à l’IA, et notamment à l’IA générative, est 
nécessaire. Pour cela, nous orientons le lecteur vers 
quelques solides références : ENISA[1], ANSSI[2] MITRE 
ATLAS[3], NIST AI 600-1[4], OWASP[5], CWE AI WG[6].
Maquette-IA-DEFENSE_2025_VDEF_WEB.pdf — page 51

51
2.	
Protection du modèle
Confidentialité
Les réseaux neuronaux profonds fonctionnent sur 
des GPU, qui offrent une grande efficacité de calcul, 
mais présentent de sérieuses lacunes en matière de 
sécurité. Cela rend le vol d’un modèle relativement 
simple. Cette vulnérabilité constitue une menace 
majeure pour les systèmes embarquant de l’IA, 
qu’il s’agisse d’applications mobiles ou de véhicules 
militaires équipés de capteurs et d’intelligence 
artificielle. Une solution prometteuse consiste à 
obfusquer les paramètres du modèle et à mettre 
en place un protocole entre le GPU et un circuit 
d’exécution sécurisé, chargé de révéler uniquement le 
résultat final.
 
Privacy
Est-il possible d’identifier un modèle enfermé dans 
une boîte noire (accès via une API) simplement en 
l’interrogeant ? C’est possible dans une certaine 
mesure et cette information s’avère précieuse pour 
un attaquant cherchant à mener une attaque 
d’évasion, car la divulgation du modèle cible améliore 
grandement l’efficacité des attaques. Du point de 
vue du défenseur, l’identification de modèle pourrait 
également détecter le vol de modèles.
 
Intégrité
De nombreux modèles sont disponibles en open-
source. L’utilisateur doit avoir la garantie qu’ils sont 
exempts de portes dérobées. Une autre menace 
est un cheval de Troie par micro-modifications des 
poids d’un modèle pour injecter un comportement 
dangereux.
3.	
Protection des données de tests
Confidentialité
L’inférence sur une requête sans la « voir » est possible. 
C’est le problème dual de l’entrainement sur des 
données chiffrées où c’est maintenant la requête est 
chiffrée et le modèle pré-appris. Dans ce contexte, 
deux approches principales sont en concurrence : le 
calcul multipartite et le chiffrement homomorphe. La 
première repose sur l’hypothèse que les différentes 
parties impliquées ne collaborent pas de manière 
malveillante, 
tandis 
que 
la 
seconde 
présente 
l’inconvénient d’être très lente.
Privacy
L’utilisateur souhaite inférer une donnée pour un 
problème de classification spécifique. Cependant, 
il 
ne 
souhaite 
pas 
que 
d’autres 
informations 
soient extraites de cette donnée. Est-il possible de 
`dépouiller’ la donnée en ne soumettant au modèle 
que le strict minimum pour mener à bien son 
inférence ? Ce problème est très peu étudié dans le 
monde académique.
Intégrité
C’est le domaine des exemples adverses. L’attaquant 
ajoute une petite perturbation souvent indétectable à 
la requête pour tromper un classificateur. Ce sujet est 
la partie émergée de l’iceberg de la sécurité du ML, 
avec plus de 6 000 publications scientifiques au cours 
des quatre dernières années. Et pourtant, aucune 
ligne de défense simple n’a été trouvée.
 
La sécurité du ML considère ce panorama riche de 
scénarios d’attaques. Les défenses visent à protéger 
de bout en bout l’apprentissage et l’utilisation d’un 
modèle. La sécurité du ML est partie intégrante de l’IA 
de confiance surtout lorsque l’IA est opérée dans un 
milieu hostile.
Maquette-IA-DEFENSE_2025_VDEF_WEB.pdf — page 53

53
les activités d’IA de confiance au sein du cycle de 
développement de l’IA se concentrent dans un 
premier temps sur une IA du type apprentissage 
machine supervisé. Cela signifie que les données sont 
au cœur du problème et nécessite en conséquence 
des activités de confiance relatives à leur viabilité, 
pertinence, représentativité ... 
Comparativement au cycle de vie en V classique [6], 
ces travaux considèrent désormais un cycle en W : le 
premier V se concentre justement sur l’algorithme 
d’IA (conception, développement, évaluation) en 
considérant dans un premier temps une plateforme 
hôte ; le second V est plus classique puisqu’il 
correspond à l’intégration, vérification, validation de 
cet algorithme au sein d’une plateforme cible (souvent 
embarquée). Une autre différence caractéristique 
clé de ce nouveau cycle de développement de l’IA 
touche aux données puisqu’on est dans le cas d’un 
apprentissage machine. On reprend alors une notion 
introduite par le monde automobile il y a quelques 
années : le domaine opérationnel de conception. 
Il permet de décrire les conditions dans lesquels 
le comportement du système d’IA sera assuré (ex  : 
conditions météorologiques). Il faut néanmoins 
caractériser cette enveloppe de fonctionnement 
multidimensionnelle afin de vérifier que le système 
d’IA fonctionnera nominalement quel que soit le 
cas de figure prévu au sein de cette enveloppe ou à 
proximité. A terme, ce nouveau cycle de vie devra être 
étendu pour considérer d’autres types d’IA comme 
par exemple l’apprentissage par renforcement, l’IA 
hybride, distribuée ou générative.
Le challenge de l’adaptation de l’ingénierie de l’IA 
pour la Défense ne s’arrête pas là : cette dernière 
doit maintenant faire face à une accélération de son 
processus de qualification d’IA. En effet les stratèges 
militaires sont très ingénieux pour tromper l’ennemi 
au travers de multiples idées de camouflage. Une IA 
qui doit détecter des armements ou forces ennemis 
doit être fréquemment remise à jour pour intégrer de 
nouvelles photos montrant ces dissimulations. A cela 
il faudrait ajouter les problématiques de confiance en 
termes d’autonomie. Mais ce ne sont là que quelques 
exemples de challenges que l’ingénierie de l’IA pour la 
Défense devra adresser sans attendre.
Maquette-IA-DEFENSE_2025_VDEF_WEB.pdf — page 63

63
(comme le choix des cibles) restent sous contrôle 
humain direct[3]. Cela exclut les SALA capables 
d’engager des cibles de manière entièrement 
autonome ;
•	
Cependant, des États membres tels que la France 
estiment que « Le débat sur les SALA ne doit pas 
parasiter les efforts entrepris dans le domaine 
de l’autonomie des systèmes d’armes, au risque 
d’un 
déclassement 
technologique, 
industriel 
et stratégique  »[4] et retient une définition très 
restrictive des SALA, insistant sur leur caractère 
létal et autonome, qu’elle distingue notamment 
des drones armés[5]. En 2020, la diplomatie 
française affirmait ainsi que les SALA, définis 
comme étant « des systèmes d’armes qui seraient 
capables de recourir à la force létale sans aucune 
forme de supervision humaine », n’existaient 
pas [6]. Le Comité d’éthique de la défense fait quant 
à lui une différence entre les systèmes d’armes 
létaux autonomes et les systèmes d’armes létaux 
« intégrant de l’autonomie » mais demeurant 
sous maîtrise de l’humain (les « SALIA ») et rejette 
fermement l’usage des SALA[7] ;
•	
à ce jour, et sans préjuger des évolutions de leur 
doctrine liées au retour de Trump à la présidence, 
les États-Unis mettent en avant l’idée de « 
contrôle humain significatif » mais interprètent 
ce concept de manière flexible. Selon la Directive 
3000.09[8], ce contrôle peut inclure des « niveaux 
appropriés de jugement humain » à différents 
stades (conception, déploiement ou activation), 
plutôt qu’une intervention humaine directe en 
temps réel. 
Les guerres en Ukraine ou dans la Bande de Gaza 
ont popularisé l’image des drones comme outils 
indispensables sur le champ de bataille, mais elles 
ont aussi alimenté des craintes liées à la prolifération 
et à l’utilisation irresponsable des SALA. Ces conflits, 
où des drones et systèmes semi-autonomes ont été 
largement déployés, ont mis en lumière à la fois les 
avantages stratégiques et les défis éthiques de ces 
armes. Ils modifient potentiellement les approches 
des grandes puissances en matière de régulation et 
de développement de ces technologies[9]. 
Cela pourrait diviser davantage les grandes puissances, 
entre partisans d’une régulation stricte et ceux 
privilégiant la supériorité stratégique (notamment les 
États-Unis, la Chine et la Russie).
Maquette-IA-DEFENSE_2025_VDEF_WEB.pdf — page 65

65
La 
question 
n’est 
pas 
de 
restreindre 
son 
développement, mais de garantir que son utilisation 
respecte les valeurs fondamentales de la société, 
notamment en matière de protection des libertés 
individuelles et de souveraineté technologique.
Une IA éthique et responsable au service de la 
souveraineté technologique
L’adoption d’une approche proactive pour garantir 
la fiabilité et l’acceptabilité des solutions IA est 
essentielle. 
Cela 
implique 
l’intégration 
dès 
la 
conception de principes fondateurs tels que la 
bienfaisance, la non-malfaisance, l’autonomie, la 
justice et la transparence. Investir massivement dans 
la recherche et la sensibilisation des parties prenantes 
est un moyen de garantir une IA exempte de biais et 
alignée avec les normes éthiques européennes. Le 
respect des règles du RGPD et du futur AI Act doit être 
vu non pas comme une contrainte, mais comme un 
atout stratégique pour assurer la confiance du public 
et des institutions.
Le 
développement 
d’outils 
d’explicabilité 
est 
également un axe central. Les solutions mises en 
œuvre doivent permettre une traçabilité claire des 
décisions algorithmiques, assurant ainsi que chaque 
utilisateur – des forces de l’ordre aux citoyens – puisse 
comprendre et vérifier l’utilisation des systèmes d’IA. 
De plus, un audit continu des performances et des 
limites de ces technologies est nécessaire pour éviter 
toute dérive ou distorsion de résultats.
L’intelligence artificielle est une révolution comparable 
à l’invention de la poudre à canon ou de l’atome. 
Comme le rappelait Benjamin Franklin : « Un peuple 
prêt à sacrifier un peu de liberté pour un peu de 
sécurité ne mérite ni l’une ni l’autre et finit par perdre 
les deux. » Si l’Europe veut en tirer parti, elle doit 
trouver un équilibre entre régulation et innovation. 
La vision par ordinateur est un des leviers clés de 
cette transformation, et une approche responsable et 
performante est possible. Il est temps d’adopter une 
posture proactive, pragmatique et ambitieuse pour 
faire de la France et de l’Europe des leaders mondiaux 
de l’IA de confiance. L’avenir de la souveraineté 
technologique européenne dépend de la capacité à 
allier innovation et responsabilité, sans céder à une 
vision trop restrictive ou purement commerciale de 
l’intelligence artificielle.
Maquette-IA-DEFENSE_2025_VDEF_WEB.pdf — page 77

77
Industrialisation de l’IA, un pilier de la confiance 
(p.24)
[1] - https://inside-machinelearning.com/recall-
precision-f1-score/
[2] - https://fr.wikipedia.org/wiki/M%C3%A9moire_vive
[3] - https://fr.wikipedia.org/wiki/M%C3%A9moire_
vid%C3%A9o
Construire la confiance en l’IA : la nécessité de la 
certification. Le point de vue d’un CESTI (p.22)
[1] - Voir https://fr.wikipedia.org/wiki/Alignement_des_
intelligences_artificielles .
[2] - Voir le blog : https://aleph.se/andart2/ethics/
ethics-for-neural-networks/
[3] - Exemple : [1802.01933] A Survey Of Methods 
For Explaining Black Box Models - https://arxiv.org/
abs/1802.01933
Transformations de la guerre : les enjeux de la 
confiance dans les applications militaires de l’IA 
(p.28)
[1] - Un systémier-intégrateur est un maître d’œuvre 
industriel qui conçoit, développe, produit et intègre 
des systèmes complexes ou « systèmes de systèmes » 
afin de répondre aux besoins capacitaires des forces 
armées.
Vers la sécurisation et la frugalité des fonctions IA 
embarquées (p.30)
[1] - www.skyld.io
[2] - H. Khaleghi, S. Paquelet, Unleashing Timing 
Advance Precision: CRLB Limit and Neural 
Implementation, WiMob 2024. 
[3] - J-P. Kahane, Sur le théorème de superposition de 
Kolmogorov, Journal of Approximation Theory, vol. 13, 
issue 3, pp. 229-234, mars 1975. 
[4] - Z. Liu et al., KAN: Kolmogorov-Arnold Networks, 
arXiv:2404.1975, juin 2024.
[5] - b<>com *Sublima* Implemented on Synaptics 
VS680 SoC for First AI-Enabled Frame-Accurate 
SDR-to-HDR Video Conversion for Set-Top Boxes, 
broadcastprome.com/...synaptics-vs680, septembre 
2024. 
Face à une IA source de crises, la confiance 
comme solution ? (p.32)
[1] - https://www.sciencedirect.com/science/article/pii/
S2215016122001273
[2] - https://huggingface.co/learn/cookbook/fr/llm_
judge
[3] - https://www.wto.org/library/events/event_
resources/sps_1411202310/329_1130.pdf
[4] - https://www.riskinsight-wavestone.com/2023/10/
quand-les-mots-deviennent-des-armes-prompt-
injection-et-intelligence-artificielle/
[5] - https://www.cnil.fr/fr/definition/red-teaming
[6] - https://www.cyber-management-school.com/
ecole/les-fondamentaux-de-la-cybersecurite/que-
signifie-la-blue-team-en-cybersecurite/
L’IA de confiance est une illusion : construisons des 
produits de confiance
[1] -https://www.ibm.com/fr-fr/think/topics/
embedding
[2] - Shrivu Shankar (2024). How to Backdoor Large 
Language Models. [online] Available at: https://blog.
sshh.io/p/how-to-backdoor-large-language-models 
[3]  - Royal United Services Institute (2023). Tactical 
Lessons from IDF Operations in Gaza. Available 
at: https://static.rusi.org/tactical-lessons-from-idf-
gaza-2023.pdf 
[4] - John, D. (2024). Why Boeing’s problems with 737 
MAX began more than 25 years ago. [online] Harvard 
Business School Working Knowledge. Available at: 
https://www.library.hbs.edu/working-knowledge/why-
boeings-problems-with-737-max-began-more-than-
25-years-ago
Maquette-IA-DEFENSE_2025_VDEF_WEB.pdf — page 79

79
Intelligence Artificielle responsable ou de 
confiance pour la Défense : quelle nouvelle 
ingénierie ? (p.52)
[1] - HLEG. Ethics guidelines for trustworthy AI”. Avril 
2019.
[2] - https://www.nato.int/cps/en/natohq/official_
texts_187617.htm 
[3] - RISC-V International
[4] - https://www.confiance.ai/ 
[5] - EUROCAE WG 114
[6] - Cycle en V
Les principales vulnérabilités des LLMs face aux 
attaques malveillantes (p.56)
[1] - https://www.cnil.fr/fr/definition/execution-en-bac-
sable-ou-sandboxing
[2] - https://www.ibm.com/fr-fr/topics/ai-
hallucinations
La cybersécurité de l’IA au cœur du champ de 
bataille (p.58)
[1] - Étape où le modèle applique les connaissances 
acquises lors de l’entraînement à de nouvelles 
informations pour prendre des décisions ou faire des 
prédictions.
[2] - Les recommandations listées dans cet article ne 
sont pas exhaustives mais visent à proposer un premier 
niveau de réponse.
[3] - Il est possible de retrouver une liste de travaux 
portant sur ce thème ici : https://ssg-research.github.
io/mlsec/modelExtDef 
[4] - Les attaques par canaux auxiliaires sur un SIA 
exploitent des informations indirectes ou “fuites” issues 
du système, comme la consommation d’énergie, les 
variations de temps d’exécution ou les émissions 
électromagnétiques, pour analyser le fonctionnement du 
SIA et déduire des informations sur son fonctionnement. 
[5] - Les travaux du projet PICTURE, piloté par le CEA 
sont à ce titre éclairants : https://picture-anr.cea.fr/
presentation 
[6] - Les attaques en déni de service sur SIA visent à 
rendre un SIA indisponible en saturant ses ressources 
avec un flux massif de requêtes.
[7] - Il est possible d’avoir une vision d’ensemble plus 
large de ces problématiques dans le guide de l’ANSSI 
sur l’IA générative : https://cyber.gouv.fr/publications/
recommandations-de-securite-pour-un-systeme-dia-
generative 
Systèmes d’Armes Létales Autonomes – aspects 
juridiques (p.62)
[1] - https://legrandcontinent.eu/fr/2025/01/07/lia-aux-
racines-de-la-guerre/ 
[2] - https://disarmament.unoda.org/fr/le-
desarmement-a-geneve/convention-sur-certaines-
armes-classiques/ 
[3] - https://www.europarl.europa.eu/doceo/
document/TA-9-2021-0009_FR.pdf
[4] - https://www.assemblee-nationale.fr/dyn/15/
rapports/cion_def/l15b3248_rapport-information.pdf, 
p65
[5] - https://www.defense.gouv.fr/dems/systemes-
darmes-letales-autonomes-sala 
[6] - https://www.diplomatie.gouv.fr/fr/politique-
etrangere-de-la-france/securite-desarmement-et-
non-proliferation/desarmement-et-non-proliferation/
systemes-d-armes-letales-autonomes-quelle-est-l-
action-de-la-france/ 
[7] - https://www.defense.gouv.fr/sites/
default/files/ministere-armees/20210429_
Comit%C3%A9%20d%27%C3%A9thique%20
de%20la%20d%C3%A9fense%20-%20Avis%20
int%C3%A9gration%20autonomie%20
syst%C3%A8mes%20armes%20l%C3%A9taux.pdf 
[8] - https://www.esd.whs.mil/portals/54/documents/
dd/issuances/dodd/300009p.pdf
[9] - https://www.usine-digitale.fr/article/comment-
les-start-up-d-ia-de-defense-veulent-conquerir-le-
champ-de-bataille.N2207171
Maquette-IA-DEFENSE_2025_VDEF_WEB.pdf — page 81

81
avril 2021, p.4. « Il existe une différence de nature entre 
les systèmes d’armes létaux autonomes, les SALA, et 
les systèmes d’armes létaux intégrant de l’autonomie 
mais demeurant sous maîtrise de l’humain, ci-après 
dénommés SALIA ».  
[3] -  Ministère de l’Europe et des Affaires étrangères, « 
Systèmes d’armes létales autonomes, quelle est l’action 
de la France ? », Février 2020.  
[4] -  Comité d’éthique de la défense, Avis sur l’usage 
des technologies d’intelligence artificielle par les forces 
armées, 14 janvier 2025, p.16. 
[5] - Assemblée nationale, 17ème législature, Position de 
la France concernant les systèmes d’armes autonomes, 
question écrite n°1610, question écrite n°1610 publiée 
au JO le 5 novembre 2024, Réponse publiée au JO le 
10 décembre 2024. 
[6] - Winston MAXWELL, Le contrôle humain des systèmes 
algorithmiques – un regard critique sur l’exigence d’un 
« humain dans la boucle ». Droit, Université Paris 1 
Panthéon-Sorbonne, 2022. Tel-04010389, p. 83. 7 Article 
36 du Protocole additionnel I aux Conventions de Genève 
du 12 août 1949 relatif à la protection des victimes des 
conflits armés internationaux du 8 juin 1977 ( PA I) : « dans 
l’étude, la mise au point, l’acquisition ou l’adoption d’une 
nouvelle arme, de nouveaux moyens ou d’une nouvelle 
méthode de guerre, une Haute Par/e contractante a 
l’obligation de déterminer si l’emploi en serait interdit, 
dans certaines circonstances ou en toutes circonstances, 
par les dispositions du présent Protocole ou par toute 
autre règle du droit international applicable à cette 
Haute Partie contractante ».
20230609_np_dpid_2eme_edition_de_la_directive_ndeg_39.pdf — page 1

DIR-39 SNSI – 2eme édition  
 
Page 1 | 79 
 
 
DIRECTIVE N°39 
 
PORTANT SUR  
LA SÉCURITE NUMERIQUE DES SYSTEMES INDUSTRIELS 
(DIR-SNSI) 
 
 
2EME ÉDITION 
APPROUVEE LE 09 JUIN 2023 
 
ENTRETENUE PAR LA DPID 
 
 
 
 
 
 
 
 
 
 
 
 
Rédaction 
LCL Jean-Sébastien REVY 
DGNUM/SDSN/BCN 
Vérification 
ICDD Franck ROUSSET 
DPID/DSDN 
Vérification 
ICA Sophie GRIFFE 
DPID/FSSI 
Approbation 
VA Denis BERTRAND 
DPID 
 
 
 
 
 
 
 
L'édition en vigueur de ce document est celle accessible via le site DGNUM. 
S'assurer de la validité de toute copie avant usage. 
La présente directive annule et remplace la première édition de la directive n°39 
du 1er juillet 2016 relative à la sécurité des systèmes industriels.
20230609_np_dpid_2eme_edition_de_la_directive_ndeg_39.pdf — page 4

DIR-39 SNSI – 2eme édition  
 
Page 4 | 79 
6.7. 
Utilisation du système industriel ............................................................................................. 22 
6.7.1. 
Principaux acteurs et leur responsabilité .............................................................................. 22 
6.7.2. 
Maintien en condition de sécurité (MCS) .............................................................................. 23 
6.7.3. 
Contrôle .............................................................................................................................. 24 
6.7.4. 
Incident de sécurité ............................................................................................................. 24 
6.8. 
Retrait de service .................................................................................................................... 25 
ANNEXE 1 – GLOSSAIRE ............................................................................................................ 26 
ANNEXE 2 – CLASSIFICATION, CATÉGORISATION, SEGMENTATION ET HOMOLOGATION ............ 30 
ANNEXE 3 - ÉVALUATION DES IMPACTS .................................................................................... 38 
ANNEXE 4 – SCHÉMA CLASSIQUE D’UNE DÉMARCHE D’HOMOLOGATION .................................. 45 
ANNEXE 5 – SOCLE DE SÉCURITÉ ............................................................................................... 47
20230609_np_dpid_2eme_edition_de_la_directive_ndeg_39.pdf — page 6

DIR-39 SNSI – 2eme édition  
 
Page 6 | 79 
mais également aux acteurs participant à leur maintien en condition de sécurité (MCS). Ces 
acteurs peuvent être du domaine de la sécurité numérique ou d’autres domaines concourant à la 
vie des systèmes industriels.  
Elle s’adresse également aux autorités qualifiées en matière de SSI (AQSSI), aux autorités 
d’homologation (AH), aux autorités d’emploi et aux autorités clientes ou bénéficiaires d’un 
système industriel. 
L’autorité d’homologation (AH) ajoute cette directive à son socle de sécurité, en complément des 
directives n°27 [Dir HSI] et n°47 [Dir MCS] qui portent respectivement sur l’homologation de 
sécurité des systèmes d’information et sur le maintien en condition de sécurité (MCS).  
Les annexes sont destinées à évoluer sous la responsabilité de la DPID sur proposition des états-
majors, directions et services. Leur dernière version est accessible sur SYNOPTIC. 
Nota : si l’autorité d’homologation (AH) choisit, avec l’accord de son AQSSI, de ne pas ajouter la 
présente directive à son socle de sécurité, par exemple lorsque la partie industrielle des systèmes 
est minoritaire, elle s’assure de l’application des documents de référence listés au §2.1. 
1.4. Niveaux de préconisation 
Les règles définies dans ce document ont différents niveaux de préconisation et sont conformes 
au [RGI] et à la [RFC 2119]2 : 
OBLIGATOIRE 
 
Ce niveau de préconisation signifie que la règle édictée indique une 
exigence absolue de la directive. 
RECOMMANDÉ 
Ce niveau de préconisation signifie qu’il peut exister des raisons valables, 
dans des circonstances particulières, pour ignorer la règle édictée, mais les 
conséquences doivent être comprises et pesées soigneusement avant de 
choisir une voie différente. 
CONSEILLÉ 
Ce niveau de préconisation signifie que la règle édictée est une bonne 
pratique de sécurité numérique. Il n’est pas nécessaire d’instruire une 
dérogation lorsqu’elle n’est pas respectée. 
DÉCONSEILLÉ 
Ce niveau de préconisation signifie que la règle édictée indique une 
prohibition qu’il est toutefois possible, dans des circonstances particulières, 
de ne pas suivre, mais les conséquences doivent être comprises et le cas 
soigneusement pesé. 
INTERDIT 
Ce niveau de préconisation signifie que la règle édictée indique une 
prohibition absolue de la directive. 
1.5. Gestion des dérogations aux règles de la directive 
Les règles peuvent s’appliquer sur le système industriel dans son ensemble ou sur un sous-
système selon leur niveau de classe*. 
Les dérogations : 
- 
aux règles portant sur la classe 1, ou ; 
                                               
2 https ://www.ietf.org/rfc/rfc2119.txt – Keywords for use in RFCs to indicate requirement levels.
20230609_np_dpid_2eme_edition_de_la_directive_ndeg_39.pdf — page 7

DIR-39 SNSI – 2eme édition  
 
Page 7 | 79 
- 
aux règles RECOMMANDÉES ou DECONSEILLÉES portant sur les classes*3 2 ou 3, ou 
portant sur le système dans son ensemble. 
sont du ressort de l’autorité d’homologation (AH). L’AQSSI en est tenu informée. 
Les dérogations : 
- 
aux règles OBLIGATOIRE ou INTERDIT portant sur les classes* 2 ou 3 , ou portant sur 
le système dans son ensemble, ou ; 
- 
aux règles relevant des systèmes d’information d’importance vitale (S2IV) ; 
sont du ressort de l’AQSSI. Le fonctionnaire SSI (FSSI) en est tenu informé. 
2. 
CADRE DOCUMENTAIRE 
2.1. Documents applicables 
[PSSIM]  
Instruction ministérielle n°7326/ARM/CAB relative à la politique de sécurité des 
systèmes d’information du ministère des Armées du 25 juin 2018.  
https://synoptic.intradef.gouv.fr/sites/synoptic/files/im7326_edition_2_du_25_juin_2018.pdf. 
[PSSIM-T] 
Instruction n°7326-2/ARM/CAB du 21 juillet 2021, édition 2 relative au volet 
technique de la politique de sécurité du système d'information du ministère des Armées (PSSI-
M). 
https://synoptic.intradef.gouv.fr/securite-numerique/pssi-m-volet-technique-2nd-edition. 
[DIR HSI] 
Directive n°27 portant sur l’homologation des systèmes d’information du ministère 
des armées, 3ème édition, 07 juin 2022. 
https://synoptic.intradef.gouv.fr/securite-numerique/directive-ndeg27dgnum-2eme-edition-du-
19-novembre-2019-portant-sur-lhomologation (Intradef). 
[DIR MCS]  
Directive n°47 portant sur le maintien en condition de sécurité (MCS), Note 
200/ARM/DGNUM/DG/DR du 4 juin 2020. 
https://synoptic.intradef.gouv.fr/securite-numerique/publication-de-la-directive-ndeg47-portant-
sur-le-maintien-en-condition-de. 
[DIR DEV-SEC] Directive n°40 portant sur le développement d’applications informatiques et des 
logiciels robustes. 
https://synoptic.intradef.gouv.fr/architecture-technique-generale/directive-ndeg40defdgsic-du-
17-mai-2017-portant-sur-le 
[Guide HYG] Guide d’hygiène informatique - ANSSI. 
https://www.ssi.gouv.fr/uploads/2017/01/guide_hygiene_informatique_anssi.pdf . 
[Guide ANSSI] Maîtriser la SSI pour les systèmes industriels - ANSSI.  
https://www.ssi.gouv.fr/uploads/IMG/pdf/Guide_securite_industrielle_Version_finale-2.pdf. 
[Arrêté SIIV AME] Arrêté du 22 mars 2021 fixant les règles de sécurité et les modalités de 
déclaration des systèmes d’information d’importance vitale et des incidents de sécurité relatives 
au sous-secteur d’importance vitale « Activités militaires de l’État ».  
https://www.legifrance.gouv.fr/jorf/id/JORFTEXT000043310173. 
                                               
3 La notion et les niveaux de classe* sont définis et précisés au paragraphe 5.1.1
20230609_np_dpid_2eme_edition_de_la_directive_ndeg_39.pdf — page 8

DIR-39 SNSI – 2eme édition  
 
Page 8 | 79 
[Arrêté SIIV AIA] Arrêté du 8 septembre 2017 fixant les règles de sécurité et les modalités de 
déclaration des systèmes d’information d’importance vitale et des incidents de sécurité relatives 
au sous-secteur d’importance vitale « Activités industrielles de l’armement ». 
[IGI 1300] 
Instruction générale interministérielle n°1300 sur la protection du secret de la 
défense nationale du 9 août 2021. 
https://synoptic.intradef.gouv.fr/securite-numerique/igi-1300-protection-sur-le-secret-de-la-
defense-nationale.  
[II 901] Instruction interministérielle n°901/SGDSN/ANSSI du 28 janvier 2015 portant sur la 
protection des systèmes d’information sensibles.https://synoptic.intradef.gouv.fr/securite-des-
systemes-dinformation/publication-de-lii-901-sur-la-protection-du-sensible-et-du-dr 
[IM 900] 
Instruction ministérielle n°900/ARM/CAB/NP du 15 mars 2021, portant sur la 
protection du secret et des informations diffusion restreinte et sensibles. 
http://portail.intradef.gouv.fr/sites/default/files/im_900_du_15_mars_2021_-_np.pdf 
2.2. Autres documents et sites de référence 
[IEC 62443] 
Norme ISA/IEC 62443 portant sur la sécurité des systèmes d’automatisation et des 
systèmes de commande 
[ANSSI] 
Site SSI de l’ANSSI  www.ssi.gouv.fr 
[DGNUM] 
SYNOPTIC (Intradef) synoptic.intradef.gouv.fr  
3. 
DÉFINITIONS ET CARACTÉRISTIQUES 
3.1. Définition des systèmes industriels 
Un système industriel4 est un système d’information particulier ayant pour finalité de contrôler ou 
de commander des installations ou équipements techniques, composés d’un ensemble de 
capteurs* et/ou d’actionneurs*. Il permet ainsi une interaction entre le monde numérique et le 
monde réel.  
3.2. Catégories d’appartenance des systèmes industriels 
3.2.1. Selon leur finalité 
Les systèmes industriels sont très présents dans des domaines d’emploi variés comme 
l’armement, l’énergie, la santé, le bâtiment, la recherche, et dans des activités de conception, de 
production, de gestion, de supervision. Ils sont également présents au sein des processus de 
contrôle, de mesure, de prévision, de facturation, d’analyse et de planification. 
Un système industriel peut : 
- 
piloter des installations physiques (unité et chaîne de production, unités de distribution d’eau, 
d’énergie, …) ou des équipements (armes, transports, outil de laboratoire, robots, …) ; 
- 
assurer des fonctions de protection des biens et des personnes ou de l’environnement ; 
- 
collecter et traiter des données d’expériences et de mesures… 
                                               
4 Par abus de langage, les termes SCADA* ou SCI* sont souvent utilisés afin de désigner les 
systèmes industriels alors que ces termes ne représentent qu’un sous-ensemble de ces derniers.
20230609_np_dpid_2eme_edition_de_la_directive_ndeg_39.pdf — page 10

DIR-39 SNSI – 2eme édition  
 
Page 10 | 79 
précédemment, l’autorité d’emploi ou bénéficiaire décide si effectivement ce système relève ou 
non de la présente directive. 
3.3. Périmètre de la sécurité numérique du système industriel 
Une grande majorité des systèmes industriels est organisée selon une architecture de type CIM6, 
qui répartit les équipements du système en cinq grands niveaux: 
- 
niveau 0 : composants (capteurs*, actionneurs*) qui assurent des fonctions de mesures 
et de commandes. Ils assurent le lien entre la partie numérique et la partie physique ; 
- 
niveau 1 : composants (automates*) qui assurent les fonctions de pilotages des 
actionneurs* en fonction des données fournies par les capteurs* ; 
- 
niveau 2 : composants (SCADA*7) qui réalisent des fonctions de supervision et de 
contrôle du processus ; 
- 
niveau 3 : composants (MES8) qui assurent l’exécution et la gestion du 
processus opérationnel ; 
- 
niveau 4 : composants (ERP9) qui assurent la gestion et la planification des ressources 
(gestion des stocks, commande, facturation , etc.). 
 
 
Schéma de fonctionnement d'un système industriel 
 
                                               
6 Le computer integrated manufacturing (CIM) est un concept décrivant l'automatisation des 
procédés de fabrication.  
7 Supervisory Control and Data Acquisition, équivalent au système de supervision industrielle. 
8 Manufacturing Execution System. 
9 Enterprise Resource Planning.
20230609_np_dpid_2eme_edition_de_la_directive_ndeg_39.pdf — page 11

DIR-39 SNSI – 2eme édition  
 
Page 11 | 79 
Des canaux de communication* permettent de connecter les différents niveaux entre eux. 
Les systèmes industriels font l’objet de nombreuses évolutions qui intègrent des innovations liées 
à l’Internet des objets (IoT*) et aux technologies numériques (intelligence artificielle, robotique, 
informatique en nuage, Big Data, réalité augmentée, …) et qui peuvent alors remettre en cause 
cette architecture. Les composants de niveau 0 peuvent ainsi directement être connectés avec 
des composants de niveau 4.   
La sécurité numérique d’un système industriel doit être globale et se fonder sur une démarche 
de gestion de risques. Cette démarche inclut dans son analyse : 
- 
tous les éléments intervenant dans le processus métier (matériel, logiciel, organisation, 
personnel, formation), du capteur* jusqu’au poste de gestion des ressources (du CIM 0 
au 4), de sa conception jusqu’à son retrait de service sans oublier les opérations de 
maintenance ; 
- 
l’environnement dans lequel le système est déployé ; 
- 
les besoins de sécurité des métiers et des activités ainsi que des systèmes numériques 
qu’il supporte ;  
- 
les impacts d’attaques informatiques sur les métiers, les activités et les systèmes 
numériques qu’il supporte.  
Plus standardisés, les composants de niveau 4 (stations d’ingénierie* les consoles de 
programmation*, les postes de maintenance, …) ainsi que leurs connexions avec les autres 
niveaux doivent faire l’objet d’une grande attention. Ils sont à inclure dans la démarche 
d’homologation et dans l’analyse de risques. Néanmoins, leur intégration dans le périmètre 
d’homologation10 du système industriel n’est pas systématique. S’ils ne sont pas inclus dans 
l’homologation du système industriel, ils doivent nécessairement relever d’un système homologué 
ou en cours d’homologation. Les mesures génériques de sécurité portant sur tout système 
numérique doivent leur être appliquées autant que cela est possible dans une démarche de 
gestion de risque.  
 
                                               
10 Si les composants du niveau 4 ne sont pas inclus dans le périmètre d’homologation, ils sont 
alors considérés comme partie prenante [au sens EBIOS RM] dans l’analyse de risques.
20230609_np_dpid_2eme_edition_de_la_directive_ndeg_39.pdf — page 16

DIR-39 SNSI – 2eme édition  
 
Page 16 | 79 
alors segmenté en zones de sécurité* homogènes et distinctes, raccordées entre elles par des 
conduits*. L’architecture technique est ainsi définie en cohérence avec le besoin de 
sécurité de chaque zone de sécurité* portant les fonctions principales du système 
industriel.  
5.1. Phase d’attribution de classe  
5.1.1. Définition d’une classe* de sécurité 
L’attribution de classe consiste à estimer le niveau de sécurité numérique attendu à partir d’une 
appréciation de risques.   
La classe* peut être attribuée à : 
- 
un système industriel réparti sur plusieurs sites ; 
- 
un système industriel déployé sur un site ; 
- 
un sous-ensemble du système qui correspond à une zone de sécurité*. 
La classe* attribuée à un système industriel ou à une zone de sécurité* est déterminée à partir 
de la criticité des fonctions et de leur exposition aux menaces.  
La criticité des fonctions est évaluée à partir des impacts : 
- 
d’une fuite, d’un vol ou d’une divulgation d’informations (criticité en matière de 
confidentialité) ; 
- 
d’une défaillance ou d’une conséquence d’une défaillance du système industriel sur les 
fonctions qu’il réalise, sur les missions auxquelles il contribue, sur l’activité et les systèmes 
d’information dont ils garantissent le bon fonctionnement, que l’impact soit le résultat d’une 
attaque, d’une erreur ou d’une panne (criticité en matière de disponibilité et d’intégrité). 
La criticité d’un système est évaluée à partir de la criticité de ses fonctions principales. 
L’exposition aux menaces (ou la surface d’attaques) est évaluée à partir de l’environnement du 
système industriel, de ses interconnexions avec d’autres systèmes ou de sa connectivité avec 
l’extérieur, de son niveau de standardisation et de complexité, de sa taille, de son hétérogénéité 
et de son niveau d’accessibilité. D’autres facteurs peuvent être pris en compte.  
Il existe trois niveaux de classes* de sécurité : 
- 
classe 1 pour des systèmes industriels ou sous-ensembles pour lesquels la criticité du SI ET 
son exposition aux menaces sont faibles ; 
- 
classe 2 pour des systèmes industriels ou sous-ensembles pour lesquels la criticité du SI OU 
son exposition aux menaces est significative ; 
- 
classe 3 pour des systèmes industriels ou sous-ensembles pour lesquels la criticité du SI ET 
son exposition aux menaces sont critiques. 
Afin de simplifier l’appréciation de risques, il est possible d’attribuer une classe 0 à un sous-
ensemble qui n’est pas exposé aux attaques informatiques de par l’absence de composants 
numériques. 
5.1.2. Attribution de classe* 
Les classes* de sécurité doivent être estimées à partir de la méthode définie en annexe 2 ou par 
toute autre méthode autorisée par l’autorité d’homologation (AH). La catégorie d’appartenance 
du système industriel (cf. §3.2) est nécessairement un élément à prendre en compte dans 
l’attribution d’une classe*.
20230609_np_dpid_2eme_edition_de_la_directive_ndeg_39.pdf — page 21

DIR-39 SNSI – 2eme édition  
 
Page 21 | 79 
Elle peut nécessiter des dispositifs particuliers à mettre en œuvre tels que les dispositifs 
d’authentification et les systèmes de supervision de sécurité à déployer (sonde de détection 
d’intrusion, système de gestion des événements et des informations de sécurité (SIEM, etc.). 
Les exigences de sécurité numérique portent sur : 
- 
les données traitées en fonction de leur nature et de leur niveau de confidentialité ; 
- 
le corpus documentaire, qui, en raison de la durée d’exploitation généralement longue du 
système industriel, porte la connaissance du système ; 
- 
le personnel qui, par ses fonctions, peut être vecteur de risques ou cibles d’attaques en cas 
de négligence ou d’incompétence ; 
- 
la sécurité physique des locaux qui peut, dans certains cas, être la seule barrière de 
sécurité efficace ; 
- 
les équipements, y compris ceux qui se connectent de manière temporaire sur le système 
industriel, tels qu’un poste de diagnostic dans le cadre d’une maintenance ; 
- 
le système industriel en lui-même sous trois aspects : 
 
les moyens de communication mis en œuvre entre : 
 
le système industriel et son environnement ; 
 
le système industriel et d’autres systèmes numériques ; 
 
le groupement de fonctions en zone de sécurité*, permettant d’appliquer des mesures de 
sécurité distinctes et homogènes, communes aux ressources constitutives, dont 
nécessairement : 
 
le durcissement des équipements ; 
 
le cloisonnement* et le filtrage* du réseau ; 
 
la mise en place d’un contrôle d’accès physique ; 
 
la surveillance au sein d’une zone ; 
 
la mise à jour des équipements (fréquence, démarche) ; 
 
les règles d’authentification sur les équipements ; 
 
les conduits* (interactions et échanges entre les zones de sécurité). 
Les responsabilités des différents acteurs, y compris des tierces parties (prestataires), en matière 
de sécurité numérique, sont définies au plus tôt. 
La mise en place de profils de protection standardisés est une bonne pratique. Elle permet de 
définir les exigences de sécurité applicable à un modèle de système industriel utilisé dans un 
certain contexte d’emploi. Cela facilite la prise en compte et l’intégration de la sécurité numérique 
dans les projets ou programmes de systèmes industriels.  
6.6. Conception du système industriel 
La maîtrise d’œuvre fournit des solutions pour répondre aux besoins et aux objectifs de sécurité 
formellement définis.  
Afin de limiter l’exposition aux menaces et l’introduction de vulnérabilités lors de l’implémentation, 
elle veille à limiter les interfaces et la complexité du système au strict nécessaire.  
Elle intègre dès la conception du système des outils et des mécanismes qui permettent de faciliter 
la gestion de la sécurité numérique et l’application des exigences telles que : 
- 
le durcissement et la maîtrise des configurations ; 
- 
la gestion des vulnérabilités ;