« En cyber, nos exercices testent souvent le scénario. Pas nos hypothèses »

Clémence Foufa — La méthode expérimentée dans le cadre de l’AID s’est-elle ensuite prolongée ?

Didier Bazalgette — Oui. Jean Langlois-Berthelot a poursuivi ce travail dans plusieurs directions.

Entre 2024 et 2026, la division « Sciences opérationnelles et Développement » du Centre de l’enseignement militaire supérieur Terre a tenté de donner une forme institutionnelle à cette continuité. Elle cherchait à associer trois opérations généralement séparées : partir de l’expérience des forces, construire une connaissance à partir de cette expérience et conduire cette connaissance vers un développement.

L’opérationnel n’était plus uniquement considéré comme l’utilisateur final d’une technologie ou comme celui qui exprime un besoin. Il participait à la production de l’objet de recherche parce qu’il connaissait l’écart entre la description administrative d’une capacité et son fonctionnement effectif.

La division ne devait donc pas devenir un laboratoire académique supplémentaire. Elle devait constituer une interface entre expérience opérationnelle, recherche et développement. Son rattachement ultérieur à une logique principalement académique a cependant déplacé sa fonction.

Clémence Foufa — Pourquoi cette continuité est-elle si difficile à maintenir ?

Didier Bazalgette — Parce que chaque milieu possède ses propres critères de réussite. L’opérationnel recherche un effet dans une situation donnée. Le chercheur doit construire un objet susceptible d’être discuté au-delà de cette situation. L’ingénieur doit produire un système stable, testable et maintenable. L’institution doit respecter des procédures, des responsabilités et des temporalités spécifiques.

Aucun de ces critères n’est illégitime. Le problème apparaît lorsqu’on passe d’un milieu à l’autre sans conserver la structure du problème. L’opérationnel remet une expression de besoin. Le chercheur la transforme en question compatible avec son champ. L’ingénieur développe une solution conforme aux spécifications. À la fin, chacun peut avoir correctement rempli sa fonction alors que la continuité initiale a disparu.

Une interface doit éviter ces ruptures successives de sens. Elle doit construire un objet que chacun puisse manipuler sans que le problème soit intégralement réécrit à chaque étape.

Clémence Foufa — Le Net Assessment cognitif s’inscrit-il dans cette continuité ?

Didier Bazalgette — Oui. Le Net Assessment cognitif, ou NAC, cherchait à traiter les capacités d’analyse, de compréhension et de décision comme des objets susceptibles d’être comparés. Il ne s’agissait pas de réduire la cognition à un indicateur unique, mais d’examiner des écarts, des configurations et des effets dans la durée.

J’ai moi-même écrit plusieurs articles sur ce sujet avec le lieutenant-colonel Janin. Ces travaux montraient déjà que l’analyse cognitive ne pouvait pas reposer uniquement sur une appréciation intuitive des acteurs ou sur une série d’indicateurs isolés. Il fallait construire un cadre permettant de comparer des configurations, de rendre les hypothèses explicites et d’examiner leurs conséquences.

Jean a ensuite contribué à prolonger cette logique en reliant davantage l’expérience opérationnelle, la formalisation et la construction d’objets susceptibles d’être mis à l’épreuve.

Clémence Foufa — Et le Net Technological Assessment ?

Didier Bazalgette — Le Net Technological Assessment, ou NTA, répondait à une difficulté comparable dans le domaine technologique. Les organisations disposent de nombreuses productions : veille, prospective, renseignement, expertise technique et appréciation opérationnelle. Mais ces informations restent souvent fragmentées et ne produisent pas nécessairement une analyse d’ensemble.

Le premier objectif du NTA était donc de rendre l’analyse technologique plus systématique : expliciter les critères, structurer les comparaisons, examiner les dépendances et relier davantage l’évolution des technologies à leurs conséquences stratégiques et opérationnelles.

Clémence Foufa — Le NTA permettait-il déjà de simuler les trajectoires technologiques ?

Didier Bazalgette — Non, pas encore au sens complet. Il ne faut pas lui attribuer rétrospectivement des capacités qu’il n’avait pas.

Le NTA constituait d’abord une architecture d’analyse plus systématique. Il ne simulait pas encore véritablement les trajectoires, leurs interactions, leurs dépendances et leurs conditions d’emploi. Mais il préparait cette évolution.

Une analyse technologique atteint rapidement ses limites lorsqu’elle attribue à une technologie une valeur relativement fixe ou lorsqu’elle prolonge une tendance unique. Une technologie ne se développe jamais isolément. Sa trajectoire dépend des investissements, de l’accès aux composants, des compétences, des infrastructures, des normes, des usages, des décisions publiques et des réactions adverses.

Le prolongement logique du NTA consiste donc à aller vers le stochastique : ne plus produire une seule trajectoire supposée, mais représenter plusieurs évolutions possibles, faire varier leurs conditions et observer la sensibilité des résultats aux hypothèses retenues.

Clémence Foufa — Que permettrait cette évolution vers le stochastique ?

Didier Bazalgette — Elle permettrait d’abord de distinguer l’anticipation de la prédiction. Nous ne pouvons généralement pas affirmer qu’une trajectoire technologique précise se réalisera. Nous pouvons en revanche représenter plusieurs évolutions compatibles avec les informations disponibles et identifier les facteurs qui modifient réellement les résultats.

Une technologie peut sembler très prometteuse si l’on considère uniquement sa performance. Mais sa trajectoire peut être transformée par une pénurie de composants, une dépendance industrielle, une évolution réglementaire, une hausse des coûts énergétiques ou l’apparition d’un usage concurrent.

Une approche stochastique permettrait de faire varier ces facteurs, de produire un grand nombre de configurations et d’observer les zones de fragilité, les seuils et les décisions qui restent robustes malgré l’incertitude. L’objectif n’est pas d’obtenir un chiffre prétendument exact. Il est de rendre l’incertitude manipulable.

Clémence Foufa — Comment cette méthode générale rejoint-elle les enjeux cyber ?

Didier Bazalgette — La cybersécurité est un domaine profondément dynamique. Une défense n’existe jamais indépendamment d’un adversaire, d’une architecture, d’une chaîne de dépendances et d’un environnement d’usage. Une mesure efficace dans une configuration peut déplacer l’attaque, produire une nouvelle vulnérabilité ou devenir obsolète lorsque l’adversaire adapte son comportement.

Une organisation peut tester sa résilience à partir d’un scénario unique et obtenir un résultat rassurant. Mais ce résultat peut changer si l’attaquant utilise une autre technique, si la détection intervient plus tard, si une équipe n’est pas disponible ou si une dépendance non identifiée accélère la propagation.

Une approche stochastique permettrait de faire varier ces éléments. On ne demanderait plus seulement si le dispositif résiste dans le scénario retenu, mais dans quelle proportion de configurations il échoue, selon quels mécanismes et à partir de quels seuils.

La cyber constitue cependant une application d’une méthode plus large. La même logique peut servir à examiner une trajectoire industrielle, l’évolution d’une capacité, la diffusion d’une technologie, une organisation de commandement ou un système de décision.

Clémence Foufa — Quel rôle la simulation joue-t-elle dans cette évolution ?

Didier Bazalgette — Elle permet de distinguer quatre éléments : le cas, le mécanisme, le modèle et l’épreuve.

Le cas est la situation réelle. Il comprend les acteurs, les systèmes, les données, les contraintes et les informations protégées. Dans une situation cyber, il peut s’agir de l’architecture exacte d’une organisation et d’une vulnérabilité effectivement observée.

Le mécanisme est la relation que nous supposons déterminante. Nous pouvons, par exemple, faire l’hypothèse que certaines dépendances indirectes accélèrent la propagation d’une compromission ou qu’un délai particulier réduit fortement la capacité de réaction.

Le modèle rend ce mécanisme manipulable. Il traduit certaines relations en règles, en variables et en paramètres.

L’épreuve compare les conséquences du modèle, fait varier les hypothèses et recherche les conditions dans lesquelles le mécanisme supposé cesse d’expliquer les résultats.

Une simulation qui ne permet pas cette dernière opération reste une illustration. Elle peut être utile pour former, communiquer ou préparer une décision, mais elle ne constitue pas encore une architecture de preuve.

Clémence Foufa — Une simulation peut pourtant dissimuler les hypothèses de son concepteur dans son code.

Didier Bazalgette — Absolument. Une simulation ne produit pas une preuve par nature. Elle peut même donner une apparence scientifique à une conviction déjà arrêtée.

Pour devenir un instrument de R&D, elle doit rendre séparables les données, les règles, les paramètres, les résultats et leur interprétation. Si le résultat dépend d’une règle implicite enfouie dans le code, la contradiction devient presque impossible. Si le scénario, le mécanisme et les paramètres sont confondus, l’utilisateur ne peut pas déterminer ce qui produit réellement l’effet observé.

Il faut donc documenter le modèle, permettre le rejeu, conserver les configurations et comparer plusieurs ensembles d’hypothèses. Dans certains cas, des équipes différentes devraient pouvoir proposer des mécanismes concurrents à partir d’un même problème abstrait.

La simulation devient alors un espace de contradiction. Elle ne sert plus seulement à montrer ce qui pourrait se produire. Elle permet d’examiner pourquoi un résultat apparaît et dans quelles conditions il disparaît.

Clémence Foufa — Peut-on garantir qu’un modèle abstrait ne révélera rien du problème initial ?

Didier Bazalgette — Non. Aucune abstraction ne doit être considérée comme automatiquement inoffensive. Un modèle peut révéler indirectement les préoccupations d’une organisation, ses priorités, certaines caractéristiques de son système ou les scénarios qu’elle juge plausibles.

Il faut donc évaluer non seulement les données contenues dans le modèle, mais aussi ce que sa structure permet d’inférer. La séparation entre cas et mécanisme doit faire l’objet d’une procédure, d’une revue et d’une responsabilité clairement identifiée.

Toutes les couches ne doivent d’ailleurs pas nécessairement être publiques. Certaines règles peuvent circuler largement. D’autres peuvent être partagées avec un cercle sélectionné de chercheurs ou d’industriels. Certains paramètres doivent rester exclusivement dans le périmètre spécialisé.

L’erreur serait d’opposer un monde ouvert à un monde fermé. Il faut construire plusieurs espaces de connaissance et définir précisément ce qui peut passer de l’un à l’autre.

Clémence Foufa — Quelle place cette méthode accorde-t-elle à l’expérience opérationnelle ?

Didier Bazalgette — Une place centrale. L’opérationnel ne doit pas seulement fournir un témoignage initial, valider un prototype à la fin ou choisir entre plusieurs solutions. Il doit participer à la construction du mécanisme étudié.

Il connaît les écarts entre les procédures et les pratiques, entre les capacités annoncées et les capacités effectives, entre le fonctionnement nominal d’un système et son comportement en situation dégradée. Cette connaissance est indispensable pour éviter que le modèle ne reproduise uniquement la représentation administrative du problème.

L’une des forces du travail de Jean a précisément été de considérer l’expérience opérationnelle comme une matière première de la R&D. Mais une matière première n’est pas encore une preuve. Elle doit être formalisée, comparée et soumise à l’épreuve.

Clémence Foufa — Cette démarche transforme-t-elle le rôle du responsable cyber ?

Didier Bazalgette — Profondément. Le responsable cyber ne se contente plus de décrire une menace, de commander un audit, de choisir une solution ou de participer à un exercice de crise. Il devient capable de construire un modèle du problème, d’expliciter ses hypothèses et d’organiser leur réfutation.

Cela modifie également la relation entre l’organisation, les laboratoires et les industriels. Le commanditaire ne transmet plus seulement un cahier des charges expurgé. Il construit une interface intellectuelle permettant à des compétences extérieures de contribuer sans accéder à l’ensemble du cas protégé.

Cette capacité devrait devenir une compétence professionnelle à part entière dans les directions cyber. Elle permettrait de travailler avec des écosystèmes plus larges sans transformer chaque coopération en diffusion incontrôlée d’informations sensibles.

Clémence Foufa — Faut-il alors revoir la formation à la cybersécurité ?

Didier Bazalgette — Oui. Une partie des formations se concentre sur les outils, les référentiels, les procédures ou la réponse à incident. D’autres utilisent des scénarios de crise dans lesquels les participants doivent prendre des décisions face à une situation préparée à l’avance. Ces approches sont utiles, mais elles ne suffisent pas.

Il faut apprendre à distinguer une hypothèse d’un résultat, un scénario d’une expérimentation, une démonstration d’une preuve et une corrélation d’un mécanisme. Il faut également apprendre à identifier ce qui ferait échouer une solution.

Dans un exercice traditionnel, les participants cherchent souvent la bonne réponse dans le cadre construit par les organisateurs. Dans une simulation conçue comme instrument de R&D, ils doivent aussi pouvoir contester le cadre, modifier les règles, tester d’autres mécanismes et déterminer si le scénario repose sur une représentation crédible de la menace.

Clémence Foufa — La simulation peut-elle aider à éliminer de mauvaises solutions avant qu’elles deviennent trop coûteuses ?

Didier Bazalgette — C’est l’un de ses intérêts majeurs. Une solution peut fonctionner dans le scénario retenu et devenir très fragile lorsque deux ou trois paramètres changent. Une autre, moins spectaculaire, peut rester efficace dans une gamme beaucoup plus large de configurations.

La question ne devrait donc plus être seulement : « Est-ce que cette solution fonctionne ? » Il faut demander : « Dans quelles conditions fonctionne-t-elle, dans quelles conditions échoue-t-elle et quelle confiance pouvons-nous accorder à cette conclusion ? »

L’approche stochastique renforce cette capacité parce qu’elle ne dépend plus d’un scénario central unique. Elle permet d’évaluer la robustesse d’une solution face à une distribution de situations possibles.

Clémence Foufa — Quelle application cyber pourrait démontrer rapidement la valeur de cette méthode ?

Didier Bazalgette — Il faudrait choisir un problème rencontré par plusieurs organisations, mais dont aucune ne peut partager complètement le cas réel. Les chaînes d’approvisionnement logicielles, les dépendances cachées ou la propagation d’une compromission constitueraient de bons terrains.

Chaque organisation conserverait son architecture, ses fournisseurs, ses vulnérabilités et ses journaux. Un modèle commun permettrait cependant d’étudier les mécanismes de dépendance, les délais de détection, les réactions organisationnelles et les conditions de résilience.

Il faudrait surtout choisir une question comportant une véritable incertitude et plusieurs hypothèses concurrentes. Si la réponse est déjà connue, la simulation ne produira qu’une démonstration.

L’objectif ne serait pas de réaliser une étude ponctuelle supplémentaire, mais de construire un environnement rejouable que plusieurs acteurs pourraient enrichir sans devoir accéder aux cas des autres.

Clémence Foufa — Quel serait le changement par rapport aux exercices de crise cyber déjà pratiqués ?

Didier Bazalgette — Un exercice de crise place généralement une organisation face à un scénario afin d’évaluer ses réactions. C’est utile pour la préparation et la formation. Mais le scénario lui-même est rarement soumis à la contradiction.

Dans l’approche que nous proposons, il faudrait pouvoir modifier les mécanismes de propagation, les comportements adverses, la disponibilité des équipes, les délais, les dépendances et les règles de décision. Il ne s’agirait plus uniquement d’entraîner les participants à répondre à une histoire écrite à l’avance, mais d’éprouver les hypothèses sur lesquelles repose leur organisation de défense.

La simulation passerait ainsi du statut d’exercice à celui d’instrument de R&D cyber.

Clémence Foufa — Cette méthode est-elle suffisamment mûre pour être industrialisée ?

Didier Bazalgette — Ses principes sont suffisamment solides pour passer à une autre échelle.

Les premiers projets ont montré qu’une double production était possible : une partie destinée aux services opérationnels et une autre permettant de capitaliser la méthode. La division Sciences opérationnelles et Développement a montré l’intérêt d’une continuité entre expérience, connaissance et développement. Le NAC et le NTA ont étendu cette logique à de nouveaux objets. Le travail engagé autour de la simulation permet maintenant de construire un environnement dans lequel les hypothèses deviennent manipulables et comparables.

L’industrialisation suppose de définir des formats communs, des protocoles d’épreuve, des règles de séparation entre informations protégées et modèles partageables, ainsi que des modalités de traçabilité et de rejeu.

Il faut également constituer des bibliothèques de mécanismes. Plusieurs organisations peuvent rencontrer des manifestations différentes d’un même phénomène. Si le mécanisme a déjà été formalisé et éprouvé, elles ne devraient pas avoir à recommencer tout le travail depuis le début.

Clémence Foufa — Quel bénéfice concret les organisations cyber pourraient-elles en retirer ?

Didier Bazalgette — Elles pourraient d’abord élargir leur accès aux compétences sans élargir dans les mêmes proportions l’accès à leurs informations sensibles. Un laboratoire pourrait tester un mécanisme de propagation sans connaître l’organisation victime. Un industriel pourrait comparer plusieurs stratégies de résilience sans disposer de l’architecture réelle. Un centre de formation pourrait rejouer le modèle sans reproduire un incident identifiable.

Elles pourraient ensuite comparer les solutions sur une base plus rigoureuse. Aujourd’hui, deux produits ou deux doctrines peuvent être évalués dans des scénarios différents, avec des paramètres différents et des critères qui ne sont pas toujours explicites. Un environnement commun permettrait de rejouer les mêmes mécanismes et de mesurer la sensibilité des résultats.

Elles pourraient enfin capitaliser les retours d’expérience sans constituer une base centralisée de vulnérabilités réelles. Chaque cas enrichirait les mécanismes, les règles et les distributions du modèle, tandis que les informations permettant d’identifier les organisations resteraient dans leurs périmètres respectifs.

Pour la cyber, l’apport est donc très concret : partager davantage de capacité d’analyse sans partager davantage de vulnérabilités.

Clémence Foufa — Cette méthode peut-elle aussi améliorer la défense face à des adversaires adaptatifs ?

Didier Bazalgette — Oui, parce qu’elle oblige à abandonner l’idée d’un scénario adverse unique. Un attaquant observe, apprend, modifie ses outils et exploite les réactions du défenseur. Une protection évaluée uniquement contre un comportement fixe risque d’être performante dans le modèle et fragile dans la réalité.

La simulation permet d’introduire plusieurs comportements adverses, plusieurs rythmes d’adaptation et plusieurs objectifs. Une approche stochastique permet ensuite d’examiner la robustesse de la défense face à cette diversité.

Elle peut également révéler des déplacements du risque. Une mesure peut réduire la probabilité d’une intrusion directe tout en augmentant la dépendance à un fournisseur. Une automatisation peut accélérer la détection tout en créant une nouvelle surface de compromission. Une segmentation peut limiter une propagation technique tout en ralentissant la réponse humaine. L’intérêt du modèle est précisément de rendre visibles ces interactions.

Clémence Foufa — La méthode pourrait-elle contribuer à une véritable souveraineté cyber européenne ?

Didier Bazalgette — Oui, à condition de ne pas réduire la souveraineté à la localisation d’un fournisseur ou à la propriété d’une technologie.

Une souveraineté réelle suppose aussi de maîtriser les hypothèses sur lesquelles reposent nos choix, de pouvoir comparer des architectures, de comprendre les dépendances et de conserver la capacité de contredire nos propres décisions.

Des partenaires européens pourraient partager des modèles de mécanismes sans centraliser leurs incidents, leurs vulnérabilités ou leurs architectures nationales. Ils pourraient construire des épreuves communes, comparer des solutions et accumuler une connaissance collective tout en maintenant la protection des cas opérationnels.

Cette capacité serait particulièrement utile dans les domaines où aucun acteur ne possède seul toutes les compétences et toutes les données nécessaires.

Clémence Foufa — Quelle formule résume le mieux cette proposition ?

Didier Bazalgette — Le secret doit porter sur l’instanciation, pas nécessairement sur toute la structure du modèle.

Une organisation doit protéger le cas réel : ses vulnérabilités, ses capacités, ses données, ses sources et ses intentions. Mais elle doit essayer d’extraire de ce cas un mécanisme suffisamment abstrait pour être partagé et suffisamment fidèle pour être utile.

La simulation rend ce mécanisme manipulable. L’épreuve en recherche les limites. Le stochastique permet d’explorer plusieurs évolutions plutôt que de figer une trajectoire unique.

Clémence Foufa — Le véritable enjeu n’est donc plus seulement de savoir qui peut entrer dans le secret ?

Didier Bazalgette — Exactement. Pendant longtemps, la R&D confidentielle a principalement organisé l’entrée des personnes et des technologies dans un périmètre protégé. Cette logique reste nécessaire, mais elle ne suffit plus.

Nous devons également apprendre à faire sortir des objets intellectuels contrôlés : des mécanismes, des modèles, des métriques et des protocoles d’épreuve qui puissent être discutés sans révéler le cas dont ils proviennent.

Pour la cybersécurité, le changement serait considérable. Nous pourrions mutualiser des capacités de recherche sans mutualiser les vulnérabilités, comparer des solutions sans exposer les architectures, capitaliser des incidents sans constituer un inventaire exploitable par un adversaire et entraîner les responsables cyber à contester les hypothèses plutôt qu’à seulement réagir à des scénarios.

Nous pourrions également passer d’exercices fondés sur une histoire unique à des environnements dans lesquels les attaques, les réactions, les dépendances et les délais varient. Une solution cyber ne serait plus jugée sur sa capacité à réussir une démonstration, mais sur sa robustesse dans un ensemble de configurations.

Enfin, cette méthode permettrait de créer une connaissance cumulative. Chaque incident protégé pourrait enrichir un modèle commun sans être directement exposé. Les chercheurs, les industriels et les responsables opérationnels pourraient travailler sur les mêmes mécanismes sans devoir accéder aux mêmes informations.

La R&D souveraine ne peut pas choisir entre la protection et la contradiction. Elle a besoin des deux. La confidentialité protège les capacités et les vulnérabilités. La contradiction protège la qualité des décisions. La simulation devient décisive lorsqu’elle parvient à maintenir simultanément ces deux exigences.