IA et cyberdéfense : Comment employer l’IA dans les six fonctions de sécurité de l’ISM

Je vous propose une synthèse complète du guide conjoint de l’ASD, du Centre canadien, du NCSC-NZ et du NCSC-UK

Quatre agences décrivent comment employer l’IA dans les six fonctions de sécurité de l’ISM, et à quelles conditions techniques et de gouvernance.

C’est juste au bon niveau…

Résumé exécutif

Le guide « Opportunities for AI in cyber defence : Use of AI by cyber security teams » est publié par l’Australian Cyber Security Centre, ACSC (1), de l’Australian Signals Directorate, ASD (2). Il est co-signé par le Centre canadien pour la cybersécurité, CCCS (3), le National Cyber Security Centre de Nouvelle-Zélande, NCSC-NZ (4), et le National Cyber Security Centre du Royaume-Uni, NCSC-UK (5). Première publication le 27 mai 2026, dernière mise à jour le 12 août 2026, document de 1,77 Mo au format PDF.

Quelques points structurants du document :

• Le public visé est celui des cyberdéfenseurs, en particulier les responsables de la sécurité des systèmes d’information, RSSI (6), et les responsables de la stratégie et des opérations de sécurité. Le texte suppose acquise une connaissance de base des concepts de cybersécurité.
• Quatre apports sont retenus pour une intelligence artificielle, IA (7), employée de manière sûre, sécurisée et responsable : renforcement de la priorisation des risques, amélioration de la détection des menaces et des vulnérabilités, accélération de la réponse et du rétablissement, réduction de la dépendance aux tâches manuelles répétitives.
• Les usages sont classés selon les six fonctions de l’Information Security Manual, ISM (8), australien : Govern, Identify, Protect, Detect, Respond et Recover.
• Le guide pose une limite explicite : l’IA ne remplace pas les fondamentaux. Une organisation dépourvue de gestion des identités et des accès, IAM (9), de configuration sécurisée, de gestion des correctifs, de segmentation réseau, de supervision et de processus de réponse à incident n’obtiendra pas de meilleur résultat de sécurité par le seul déploiement d’IA.
• Un spectre de capacités est décrit, du frontier AI aux fonctionnalités d’IA embarquées dans les outils de sécurité existants, en passant par les grands modèles de langage, LLM (10), généralistes. La recommandation est d’augmenter les outils et les processus existants plutôt que de déployer une solution autonome.
• L’IA agentique fait l’objet d’un traitement distinct, avec renvoi à la publication conjointe co-signée avec la Cybersecurity and Infrastructure Security Agency, CISA (11), et la National Security Agency, NSA (12), sur son adoption prudente.
• Deux annexes fournissent des grilles de questions à poser aux fournisseurs d’IA et aux fournisseurs de sécurité, orientées preuves opérationnelles plutôt que déclarations commerciales.

Le CCCS a relayé la publication sur son portail le 7 août 2026, en renvoyant vers la version intégrale hébergée par l’ACSC, disponible en anglais uniquement. Le sujet a été traité dans l’épisode 717 de mon podcast de RadioCSIRT le jeudi 13 août 2026.

Fiche du document

Élément	Valeur
Titre	Opportunities for AI in cyber defence : Use of AI by cyber security teams
Éditeur principal	ACSC, ASD (Australie)
Co-signataires	CCCS (Canada), NCSC-NZ (Nouvelle-Zélande), NCSC-UK (Royaume-Uni)
Première publication	27 mai 2026
Dernière mise à jour	12 août 2026
Format	Page web et PDF de 1,77 Mo
Public	Grandes organisations, infrastructures critiques, secteur public
Cadre de référence	ISM et Essential Eight de l’ASD
Langue	Anglais

Un paysage de menace qui change de rythme

Le document part d’un constat opérationnel et non d’une prospective. Les acteurs malveillants intègrent des modèles d’IA directement dans leurs chaînes d’attaque pour automatiser la reconnaissance, développer leur outillage, analyser les données exfiltrées et produire des contenus malveillants adaptés à leur cible. L’effet mesurable porte sur le temps : la découverte de vulnérabilités s’accélère et le délai entre la découverte et l’exploitation se raccourcit, ce qui réduit d’autant la fenêtre d’alerte et de réaction des défenseurs.

Le second effet décrit est un abaissement de la barrière technique. Des acteurs peu qualifiés accèdent à des capacités qui exigeaient auparavant une expertise spécialisée : production de code malveillant évasif, analyse de volumes importants de données, campagnes d’ingénierie sociale convaincantes.

La conclusion que le guide en tire est défensive et classique dans ses moyens : réduction de la surface d’attaque, application rapide des correctifs, architecture en défense en profondeur, augmentation du niveau d’automatisation, amélioration de la détection. Le texte précise que sans progression parallèle des défenses, les approches de sécurité traditionnelles perdront en efficacité face à des menaces assistées par l’IA. Le lecteur est renvoyé à l’évaluation du NCSC-UK sur l’impact de l’IA sur la menace cyber à horizon 2027.

Le guide rappelle également que la cybersécurité repose historiquement sur des équipes spécialisées et des flux de travail réactifs, et que ce modèle est mis sous tension par l’échelle et la complexité de l’environnement actuel. La dépendance aux processus manuels rend difficile la priorisation des risques, l’investigation des signaux et le maintien d’une couverture défensive homogène.

Le spectre des usages défensifs de l’IA

Le document refuse la question binaire de l’adoption ou du refus de l’IA et propose un spectre de capacités que chaque organisation combine selon ses objectifs, son appétence au risque et les technologies dont elle dispose.

À une extrémité, le frontier AI désigne les modèles les plus avancés, capables de raisonnement complexe, d’une couverture de tâches large et d’une intégration étroite avec des outils, des données et des flux de travail opérationnels. Le guide associe explicitement cette catégorie à des considérations de coût et de soutenabilité : consommation de jetons, besoins de calcul, dépenses d’exploitation récurrentes. Le niveau de capacité retenu doit être proportionné à l’exigence et à la valeur du cas d’usage.

Au centre se trouvent les LLM généralistes. À l’autre extrémité se trouvent les fonctionnalités d’IA déjà embarquées dans les outils de sécurité en place. La stratégie recommandée est superposée : employer les capacités les plus avancées là où elles apportent une valeur démontrable, et s’appuyer sur l’existant pour les gains d’efficacité opérationnelle.

Deux points de vigilance sont posés. Le premier concerne la finalité : identifier des vulnérabilités ne renforce pas la sécurité en soi. Sans contexte, priorisation et remédiation, un usage mal conçu de l’IA ajoute du risque au lieu d’en retirer. Le second concerne l’écart entre organisations. Le guide cite les travaux du Forum économique mondial sur la moindre cyberrésilience des petites structures et des organismes publics, et sur le faible niveau de confiance des infrastructures critiques dans leur capacité à répondre à un incident majeur. La réponse proposée passe par la préparation locale, les partenariats de confiance et un appui concret.

Le texte s’appuie enfin sur la déclaration conjointe des Five Eyes qui invite les dirigeants à mobiliser l’IA pour renforcer la défense.

L’IA agentique, un cas traité à part

L’IA agentique est définie comme un ensemble de systèmes capables de planifier, décider et agir de façon autonome pour atteindre un objectif, au lieu de répondre à des sollicitations isolées. Ces systèmes combinent des modèles avancés avec un accès à des outils, des données, une mémoire et des flux de travail.

Trois caractéristiques les distinguent des assistants conversationnels : ils poursuivent un objectif même lorsqu’il est défini de façon lâche, ils fonctionnent avec une supervision humaine réduite, ils adaptent leur comportement aux résultats obtenus et peuvent créer des sous-tâches ou des sous-agents. L’humain fixe les objectifs, les contraintes et les permissions, mais l’exécution s’étale dans le temps sans validation systématique.

Le guide renvoie à la publication conjointe de la CISA, de la NSA, du CCCS, du NCSC-NZ et du NCSC-UK sur l’adoption prudente des services d’IA agentique, et impose dans ses propres recommandations un encadrement strict, une portée clairement limitée et une supervision humaine forte.

Gouverner

La fonction Govern porte sur la manière dont la sécurité et le risque cyber sont pilotés, compris et gérés dans l’organisation : responsabilités, structure de décision, mécanismes de contrôle reliant la direction générale aux équipes techniques.

Le guide demande que la gouvernance définisse explicitement les attentes en matière d’usage de l’IA, de contrôle et de responsabilité humaine. Deux notions y sont introduites. L’autonomie bornée maintient l’IA à l’intérieur de limites définies, en particulier sur les systèmes critiques et dans les opérations de sécurité. La récupérabilité garantit que les fonctions d’IA peuvent être restreintes ou rétablies sans interruption des opérations en cas de défaillance ou de compromission.

Le partage de renseignement portant spécifiquement sur l’IA doit être renforcé en s’appuyant sur le programme de partenariat de l’ACSC, sur le National Cyber Threat Notification System, NCTNS (13), et sur le playbook de collaboration de la CISA.

Les usages identifiés pour cette fonction :

• Repérer les incohérences d’évaluation du risque entre entités, systèmes ou projets.
• Analyser les risques de chaîne d’approvisionnement, dépendances logicielles, exposition aux vulnérabilités et pratiques de sécurité des fournisseurs comprises.
• Appuyer la constitution et l’exploitation des inventaires, notamment la nomenclature logicielle, SBOM (14), et la nomenclature cryptographique, CBOM (15).
• Renforcer l’interprétation des politiques et la conformité, par exemple au moyen d’un assistant interne restituant des consignes contextualisées à partir des politiques internes et des exigences réglementaires.
• Prioriser les décisions de sécurité à partir de l’appréciation du risque.

Identifier

La fonction Identify établit la visibilité sur les actifs, les logiciels, les données et les configurations, condition d’une décision fondée sur le risque.

Les usages retenus :

• Enrichir la découverte d’actifs à partir de la télémétrie réseau pour révéler les équipements non supervisés ou dissimulés.
• Prioriser les correctifs en combinant plusieurs facteurs : sévérité, disponibilité d’un code d’exploitation, renseignement sur la menace, impact opérationnel de l’exploitation.
• Identifier les enchaînements de vulnérabilités, en reliant plusieurs failles de sévérité faible ou moyenne en chemins d’attaque exploitables.
• Repérer les configurations non sécurisées et proposer les actions de remédiation associées.
• Examiner des échantillons de journaux pour déterminer quelles actions un adversaire pourrait mener sans déclencher d’alerte, et affiner la logique de détection en conséquence.
• Analyser les SBOM et les CBOM pour cartographier les composants, repérer les bibliothèques obsolètes et les expositions de chaîne d’approvisionnement.
• Cartographier les sources de données d’entraînement et d’affinage pour évaluer leur provenance, leur durée de conservation et leur exposition à l’empoisonnement.

Scénario décrit par le guide, analyse de chemins d’attaque par une équipe de red team. Une équipe offensive interne alimente un modèle avec l’architecture des systèmes, les relations d’identité et les données de vulnérabilité de son environnement, en lui accordant des permissions larges de corrélation entre les couches réseau, applicative et contrôle d’accès. Le modèle relie des faiblesses isolées de sévérité faible ou moyenne, par exemple une erreur de configuration bénigne, des permissions excessives et un défaut logiciel mineur, en une séquence conduisant à une élévation de privilèges puis à un déplacement latéral. L’apport décrit est la couverture de test et la priorisation de la remédiation selon la faisabilité réelle d’une attaque plutôt que selon la sévérité unitaire de chaque faille.

Protéger

La fonction Protect couvre les garde-fous qui réduisent la probabilité et l’impact d’un incident : configurations sécurisées, gestion des identités et des accès, réduction de surface d’attaque, maintien de l’efficacité des contrôles dans la durée.

Les usages retenus :

• Prioriser les actions de durcissement selon l’exploitabilité et le contexte de l’environnement.
• Évaluer l’architecture de sécurité, les frontières de confiance et les flux de données pour simuler des chemins d’attaque réalistes.
• Analyser les identités, les rôles et les comportements des utilisateurs et des agents pour détecter les écarts au moindre privilège, les permissions excessives, l’accumulation de droits et les comptes orphelins.
• Analyser le trafic en temps réel pour identifier les activités anormales, y compris celles conduites de façon autonome par des systèmes d’IA, et proposer des ajustements de segmentation.
• Analyser le code source, l’infrastructure as code et les définitions de pipeline pour repérer les vulnérabilités et les défauts de logique métier que les analyseurs à base de motifs ne détectent pas.
• Étendre le zero trust et les architectures défendables aux agents d’IA comme aux utilisateurs humains, en remplaçant les identifiants statiques par des jetons dynamiques et en imposant des frontières de privilèges explicites sur ce qu’un agent peut atteindre et exécuter.

Scénario décrit par le guide, revue de code. Un outil d’analyse examine automatiquement chaque soumission de modification. Un développeur ajoute une fonction qui traite une entrée utilisateur et la stocke en base. Le code fonctionne, la syntaxe est correcte et aucune règle explicite n’est violée, mais l’outil relève que l’entrée n’est pas validée avant stockage et signale la portée du défaut, à savoir l’insertion de données malveillantes pouvant mener à une compromission. La correction intervient avant la mise en production.

Détecter

La fonction Detect porte sur l’identification et l’analyse des évènements de sécurité, avec une supervision continue des systèmes, des réseaux et des identités.

Les usages retenus :

• Détecter les évènements et les incidents, le jugement de l’analyste restant requis pour valider les constats.
• S’appuyer sur des référentiels dédiés aux systèmes à base d’IA pour orienter la détection des comportements malveillants qui les visent : MITRE ATLAS (16), les référentiels OWASP (17) consacrés aux applications à base de LLM et aux applications agentiques, le profil IA générative du cadre de gestion des risques du National Institute of Standards and Technology, NIST (18), ainsi que le modèle de menace MAESTRO (19).
• Analyser la télémétrie réseau, flux, journaux, résolutions du système de noms de domaine, DNS (20), et appels d’interfaces de programmation, API (21), pour détecter les communications inattendues entre services ou vers des points de terminaison malveillants connus.
• Détecter le détournement de l’IA elle-même au moyen d’une télémétrie spécifique : entrées de modèle et manipulation de prompt, traces de décision, contrôles de politique, signaux de confiance, tout en protégeant l’intégrité des journaux de détection contre l’altération.
• Distinguer l’activité légitime de l’activité suspecte par l’analyse du comportement et du contexte de configuration, afin de réduire les faux positifs et les faux négatifs.
• Établir une base de référence des activités à risque élevé, identités, accès à privilèges et accès distants, pour appuyer la détection d’anomalies.

Scénario décrit par le guide, plateforme de centre opérationnel de sécurité. Une plateforme de centre opérationnel de sécurité, SOC (22), assure le tri assisté des alertes sur les télémétries d’identité, de poste de travail, de réseau et de cloud. Elle corrèle les résolutions DNS, les transactions API et les flux réseau, suit les schémas d’accès à privilèges et remonte des incidents priorisés pour revue humaine. Le bénéfice décrit est la suppression progressive des faux positifs et la réduction du temps de réponse sur les menaces les plus critiques, la visibilité restant assurée.

Répondre

La fonction Respond vise l’action coordonnée pendant l’incident, en maintenant les opérations critiques.

Les usages retenus :

• Corréler alertes, journaux et artefacts forensiques en une explication cohérente de l’incident.
• Interpréter les alertes et les comportements observés dans le contexte propre des systèmes, de l’architecture et du risque de l’organisation.
• Réduire le recours aux recherches manuelles pendant l’investigation.
• Séquencer les actions de réponse sur les contrôles d’identité, de poste de travail et de réseau.
• Rédiger les points de situation destinés à faire le lien entre intervenants et direction, la vérification de l’exactitude restant à la charge des intervenants avant diffusion.
• Absorber les pics de charge en automatisant le tri et en préparant ou en déclenchant des actions préapprouvées et réversibles en parallèle sur plusieurs incidents, l’approbation humaine demeurant obligatoire pour les décisions de confinement, de perturbation, de rétablissement ou de communication à fort impact. Le guide signale ce point comme critique dans les scénarios d’attaque conduite par IA.
• Proposer des actions de confinement et de remédiation pour les cas incertains, alignées sur les playbooks de réponse, pour revue humaine.

Rétablir

La fonction Recover porte sur la remise en service après incident, sur la base d’une intégrité vérifiée et d’un risque résiduel accepté.

Les usages retenus :

• Analyser les chemins de reconstruction et de restauration pour appuyer la planification, le séquencement et l’assurance de la reprise.
• Déclencher des actions et des playbooks de rétablissement automatisés, l’approbation humaine restant requise pour les changements destructifs ou irréversibles tels qu’une restauration système ou un retour arrière de données.
• Valider les restaurations de systèmes et de services par rapport à des références connues avant reprise des opérations.
• Revenir à une version antérieure d’un modèle en cas de compromission, d’empoisonnement ou de dérive suspectée.
• Vérifier l’intégrité et le comportement attendu des modèles et de leurs données par des contrôles spécifiques avant de réactiver les fonctions augmentées ou autonomes.
• Identifier les défaillances en cascade entre systèmes interconnectés pour sécuriser la reprise des services métier critiques.
• Générer et évaluer des séquences de reprise pour les incidents nouveaux ou complexes qui sortent des playbooks d’orchestration, d’automatisation et de réponse, SOAR (23), prédéfinis.
• Détecter en amont les faiblesses des dispositifs de reprise, de leurs dépendances et de leurs hypothèses, avant qu’un incident réel ne les révèle.

Les prérequis : données, compétences et socle technique

Le guide subordonne l’ensemble des usages précédents à trois conditions préalables.

Le socle de sécurité vient en premier. Aucune stratégie de mitigation n’offre une protection complète, mais l’alignement sur l’ISM et sur les Essential Eight réduit matériellement le risque. Les infrastructures critiques sont invitées à maintenir des contrôles continûment assurés compte tenu de leur exposition.

La qualité des données conditionne le résultat. La cyberdéfense assistée par IA ne vaut que ce que valent les données sous-jacentes : inventaires d’actifs, couverture de journalisation, données d’identité et de privilèges, enregistrements de vulnérabilités, données de configuration. Le guide demande d’évaluer et de relever la qualité, la couverture et la fraîcheur de ces données avant et pendant l’adoption, en reconnaissant que toute lacune limitera directement l’exactitude des sorties.

La compétence des équipes constitue la troisième condition. Les cyberdéfenseurs doivent savoir valider une sortie, reconnaître les limites d’un outil et éviter la dépendance excessive. Ces compétences relèvent du plan de développement des équipes et non d’une acquisition ponctuelle.

Les systèmes d’IA employés en sécurité comme en production doivent enfin être protégés des techniques adverses, injection de prompt, évasion de modèle et extraction de modèle, en s’appuyant sur les lignes directrices pour le développement sécurisé des systèmes d’IA, sur la taxonomie NIST AI 100-2 E2025 consacrée à l’apprentissage automatique adverse et sur MITRE ATLAS.

Supervision humaine et limites de l’automatisation

Le guide énumère les risques qui dégradent la fiabilité si l’usage n’est pas maîtrisé : sorties hallucinées ou trompeuses, manipulation adverse par injection de prompt ou évasion de modèle, dépendance excessive à l’outil, fatigue de supervision, pressions opérationnelles liées à l’échelle, à la disponibilité ou au coût.

Les exigences posées :

• La responsabilité des résultats de sécurité reste humaine, l’IA vient en appui.
• Les limites de l’automatisation sont définies explicitement, et une revue puis une approbation humaine sont requises pour toute action à impact significatif, notamment les modifications de contrôles d’accès, de politiques de sécurité, de systèmes et de services critiques.
• Les actions autonomes sont restreintes à un périmètre étroit, préapprouvé et réversible.
• Les sorties sont vérifiées contre des preuves et un contexte avant action, avec une attention particulière aux hallucinations.
• Dans les environnements de technologies opérationnelles, OT (24), les recommandations touchant la sécurité des personnes, la disponibilité, la segmentation, la reprise ou l’intégrité des procédés sont validées par du personnel qualifié en ingénierie et en sûreté avant mise en œuvre.
• La performance et le comportement des systèmes d’IA font l’objet d’un suivi continu.
• Les défaillances, compromissions et hallucinations liées à l’IA sont intégrées aux plans de réponse à incident.

Protection du système d’IA et sandboxing

Les outils d’IA employés en cybersécurité doivent être conçus et déployés de telle sorte qu’une défaillance, un détournement ou une manipulation ne puisse pas nuire directement aux systèmes, aux données ou aux opérations. Les contrôles portent sur ce que le système peut atteindre, influencer et exécuter, indépendamment de son mode d’intégration.

Le guide demande un déploiement sécurisé par défaut avec des configurations conservatrices et des privilèges minimaux, une contrainte du comportement et de l’autorité par sandboxing, restriction de portée et limites d’exécution, des garde-fous techniques interdisant les actions à fort impact ou irréversibles sans contrôle approprié, une traçabilité des actions assistées permettant supervision, investigation et retour arrière, et enfin une protection des composants et des interfaces contre le détournement et l’accès non autorisé.

Intégration dans l’existant

Les capacités d’IA doivent être gérées comme un composant de l’environnement d’entreprise, avec les mêmes exigences architecturales, de sécurité et de gouvernance que les autres systèmes.

Les points demandés portent sur l’usage d’architectures approuvées, sur des méthodes d’intégration contrôlées et auditables telles que des plateformes de sécurité dédiées ou des intégrations d’API sécurisées, sur le refus des intégrations mal gouvernées lorsque le système peut déclencher directement des actions dans des environnements opérationnels ou à haute disponibilité, sur la visibilité des sorties et des actions assistées dans les flux de travail existants, sur l’alignement avec la gestion du changement, la supervision et la réponse à incident, et sur la mise en place de garde-fous lors de l’ingestion de journaux et d’artefacts dans d’autres systèmes d’IA, afin de traiter le risque d’injection de prompt par des entrées non fiables.

Gouvernance de l’usage

L’adoption doit être délibérée, autorisée et redevable, en particulier lorsque des informations sensibles ou des systèmes critiques sont concernés. La responsabilité des résultats reste attribuée au cyberdéfenseur humain.

Le guide demande de documenter les cas d’usage et de les aligner sur les objectifs métier, les priorités de sécurité et la tolérance au risque, de restreindre les droits d’accès et de modification aux comptes autorisés et les privilèges d’administration au personnel vérifié, de définir et d’appliquer des politiques encadrant les données accessibles à l’IA, leurs usages et les destinations autorisées des sorties, d’empêcher le partage d’informations sensibles avec des services non approuvés y compris grand public, d’assurer la transparence et l’auditabilité en étant capable d’expliquer les entrées, l’autorité mobilisée et l’influence des sorties sur les décisions, et d’intégrer le contrôle de l’IA aux processus de gouvernance existants.

Chaîne d’approvisionnement de l’IA

Le recours à des modèles préentraînés, à des jeux de données tiers et à des services externes accélère la mise en capacité, mais introduit des compromissions héritées, des dépendances masquées et une visibilité réduite sur le comportement du système.

Les exigences :

• Maintenir la visibilité sur les composants de la chaîne, modèles, sources de données, services tiers et modalités d’hébergement, à l’appui d’une nomenclature des composants d’IA, AIBOM (25), d’un SBOM ou d’une documentation équivalente.
• Évaluer les risques spécifiques : sensibilité des données, maîtrise des composants, menaces d’apprentissage automatique adverse.
• Intégrer ces risques aux processus existants de gestion du risque et de réponse à incident.
• Conduire une diligence raisonnable et fixer des attentes de sécurité contractuelles avec les fournisseurs, signalement des vulnérabilités et des incidents compris.
• Comprendre comment les données de l’organisation sont consultées, employées et traitées tout au long de la chaîne, afin de vérifier l’alignement avec les exigences de souveraineté des données et de déterminer quelles solutions sont acceptables.
• Développer la sensibilisation interne, en particulier chez les personnels impliqués dans le développement, le déploiement et l’exploitation.

Le guide renvoie sur ce point aux travaux du groupe de travail cybersécurité du G7 sur une vision partagée des nomenclatures logicielles pour l’IA, ainsi qu’aux publications du NIST sur le rôle de l’AIBOM dans la maîtrise des risques de chaîne d’approvisionnement logicielle.

Test et assurance des outils

Le guide écarte explicitement la valeur probante des démonstrations fournisseurs et des tests limités. L’évaluation doit porter sur le comportement de l’outil dans l’environnement de l’organisation elle-même, et se poursuivre dans le temps à mesure que les systèmes, les données et la menace évoluent.

Les actions demandées :

• Tester avant mise en production, dans l’environnement cible.
• Valider l’exactitude et la pertinence des sorties par rapport aux preuves et au contexte observés.
• Vérifier que les recommandations produites sont actionnables et permettent une décision assumée par les équipes.
• Évaluer le comportement en conditions réalistes : données bruitées, informations incomplètes, activité malveillante en cours.
• Tester la continuité de la cyberdéfense lorsque l’outil tombe en panne, se trouve compromis ou produit des sorties non fiables, dispositifs de repli et d’escalade compris.
• Suivre la performance dans la durée pour détecter la dégradation ou la dérive.
• Revoir le rôle et la configuration de l’outil dès lors que les sorties cessent d’être fiables ou de répondre au besoin.

Secure by Demand

Le principe Secure by Demand prolonge les fondations Secure by Design sur l’ensemble de la chaîne d’approvisionnement de l’IA. Les fournisseurs et les intermédiaires ont la responsabilité de concevoir des produits sécurisés dès l’origine. Les clients et les intermédiaires exercent cette responsabilité en n’achetant que des produits conçus selon ce principe. La sécurité n’est donc pas ajoutée après la sélection, elle intervient comme critère de sélection.

Interroger les fournisseurs : les grilles des annexes A et B

Les deux annexes constituent la partie la plus directement réutilisable du document. L’annexe A évalue les capacités d’IA proposées par un fournisseur, l’annexe B évalue l’apport réel d’une fonctionnalité d’IA dans un produit de cybersécurité. Toutes deux sont construites pour distinguer une solution industrialisée d’une fonctionnalité émergente présentée comme mature.

Thème	Question à poser	Ce qui est attendu en réponse
Résultats mesurables	Quels résultats de sécurité l’IA améliore-t-elle de façon mesurable, temps moyen de détection, MTTD (26), temps moyen de réponse, MTTR (27), faux positifs et faux négatifs ?	Des preuves chiffrées issues d’un usage opérationnel, pas des affirmations d’architecture ou de marketing
Validation	Comment la performance est-elle validée en conditions réelles et non en laboratoire ?	Évaluation continue, red teaming, validation côté client, métriques de production
Maturité	Quelles parties de la capacité sont en production aujourd’hui, quelles parties relèvent de la feuille de route ?	Une séparation nette entre capacité éprouvée et fonctionnalité expérimentale
Portée	L’IA est-elle contrainte à des règles et à des flux prédéfinis, ou peut-elle raisonner au-delà des cas d’usage prévus ?	Une qualification honnête entre outil spécialisé et capacité analytique générale
Nouveauté	Comment le modèle traite-t-il des techniques d’attaque inédites ?	Des explications sur la généralisation et l’adaptation, pas un renvoi aux signatures statiques
Biais d’automatisation	Comment le produit prévient-il le biais d’automatisation chez les analystes ?	Des éléments de conception qui incitent à la revue et à la contestation
Responsabilité	Qui est responsable en cas d’erreur du système, comment les erreurs sont-elles identifiées et corrigées ?	Des chaînes d’escalade et un processus d’amélioration explicites
Explicabilité	Le raisonnement et les recommandations sont-ils auditables et défendables par les cyberdéfenseurs ?	Une reconstitution possible des entrées, des décisions et des sorties après incident
Sécurité du système	Comment l’IA est-elle protégée contre la manipulation, l’empoisonnement et les entrées malveillantes ?	Une résistance documentée à l’injection de prompt, à l’empoisonnement des données d’entraînement et à l’abus des boucles de retour
Données	Quelles données sont conservées, réemployées ou utilisées pour réentraîner, et dans quelles conditions ? Quelles juridictions traitent ou stockent les données ?	Des réponses opposables au regard des obligations de souveraineté et de confidentialité
Intégration	Comment le produit s’intègre-t-il à l’IAM, à la journalisation, à la supervision, à la gestion du changement et à la réponse à incident ?	Une intégration native ou par API, sans processus parallèle
Résilience	Comment le système se comporte-t-il si le composant d’IA se dégrade, tombe en panne ou produit des sorties peu fiables ?	Des mécanismes de repli permettant la poursuite sûre des opérations
Réversibilité	Quels contrôles permettent de restreindre, de cadrer ou de désactiver la fonctionnalité d’IA ? Quelle portabilité en cas de changement de fournisseur ?	Une capacité de désactivation et une limitation du verrouillage propriétaire
Traçabilité	Le fournisseur fournit-il un SBOM et un AIBOM lisibles par machine, et peut-il démontrer la provenance et la lignée des modèles ?	Une documentation exploitable dans une investigation

Ce qu’il faut prioriser

Périmètre	Actions clés	Pourquoi
Socle de sécurité	Vérifier l’état de l’IAM, de la configuration sécurisée, de la gestion des correctifs, de la segmentation, de la supervision et de la réponse à incident avant tout projet d’IA défensive	Le guide pose que sans ce socle, le déploiement d’IA n’améliore pas les résultats de sécurité
Données	Mesurer la qualité, la couverture et la fraîcheur des inventaires d’actifs, des journaux, des données d’identité et de vulnérabilité	La fiabilité des sorties est plafonnée par celle des données d’entrée
Périmètre d’autonomie	Définir par écrit les actions autonomes autorisées, étroites, préapprouvées et réversibles, et les actions soumises à approbation humaine	L’autonomie bornée est le mécanisme central de maîtrise retenu par le guide
Systèmes d’IA exposés	Appliquer sandboxing, privilèges minimaux, garde-fous sur les actions irréversibles et traçabilité des actions assistées	Un système d’IA défensif est lui-même une surface d’attaque
Ingestion de journaux	Encadrer l’injection de journaux et d’artefacts dans les systèmes d’IA	Les entrées non fiables constituent un vecteur d’injection de prompt
Fournisseurs	Employer les annexes A et B comme grille d’achat et d’évaluation annuelle	Les critères déplacent la discussion des déclarations vers les preuves opérationnelles
Chaîne d’approvisionnement	Exiger SBOM et AIBOM, cartographier modèles, données et services tiers, intégrer ces risques aux processus existants	La compromission héritée et les dépendances masquées sont les risques spécifiques identifiés
Réponse à incident	Ajouter aux plans les cas de défaillance, de compromission et d’hallucination des systèmes d’IA	Ces modes de défaillance ne figurent pas dans les playbooks traditionnels
Compétences	Former les équipes à la validation des sorties, à la reconnaissance des limites et à la prévention de la dépendance excessive	La supervision humaine ne fonctionne qu’avec des compétences correspondantes
Environnements OT	Soumettre à validation par du personnel d’ingénierie et de sûreté toute recommandation touchant disponibilité, segmentation, reprise ou intégrité des procédés	Le guide isole ce cas comme non délégable

Conclusion

Le guide conjoint ne présente pas l’IA comme une rupture défensive, mais comme une capacité de traitement à insérer dans un cadre existant, celui des six fonctions de l’ISM, sous condition d’un socle de sécurité opérationnel et de données exploitables. Sa contribution principale tient dans deux déplacements. Le premier consiste à traiter le système d’IA défensif comme un actif à protéger et non seulement comme un outil à employer, ce qui entraîne des exigences de sandboxing, de traçabilité, de test en environnement réel et de réponse à incident spécifique. Le second consiste à formaliser l’autonomie bornée, la réversibilité des actions et l’approbation humaine des décisions à fort impact comme les mécanismes de maîtrise de référence, y compris pour l’IA agentique.

Le document énonce également une limite qui conditionne tout le reste : une organisation dont les fondamentaux ne sont pas identifiés n’obtiendra pas de meilleur résultat en déployant de l’IA, et pourra au contraire ouvrir des chemins d’attaque supplémentaires par un accès système excessif, des entrées non fiables ou des actions automatisées insuffisamment encadrées. La version intégrale, publiée en anglais, ainsi que ses deux annexes de questions fournisseurs, constituent le support directement exploitable pour une revue de programme au sein de votre entreprise quelque soit sa taille.

Enjoy !

Lexique

N°	Sigle	Développé	Précision
1	ACSC	Australian Cyber Security Centre	Centre australien de cybersécurité, rattaché à l’ASD, éditeur principal du guide
2	ASD	Australian Signals Directorate	Agence australienne du renseignement d’origine électromagnétique et de la cybersécurité
3	CCCS	Canadian Centre for Cyber Security	Centre canadien pour la cybersécurité, co-signataire
4	NCSC-NZ	National Cyber Security Centre New Zealand	Agence nationale néo-zélandaise de cybersécurité, co-signataire
5	NCSC-UK	National Cyber Security Centre United Kingdom	Agence nationale britannique de cybersécurité, co-signataire
6	RSSI	Responsable de la sécurité des systèmes d’information	Équivalent français de Chief Information Security Officer
7	IA	Intelligence artificielle	Objet central du guide
8	ISM	Information Security Manual	Référentiel de sécurité de l’ASD, organisé en six fonctions
9	IAM	Identity and Access Management	Gestion des identités et des accès
10	LLM	Large Language Model	Grand modèle de langage
11	CISA	Cybersecurity and Infrastructure Security Agency	Agence américaine de cybersécurité et de sécurité des infrastructures
12	NSA	National Security Agency	Agence américaine de sécurité nationale
13	NCTNS	National Cyber Threat Notification System	Dispositif australien de notification des menaces
14	SBOM	Software Bill of Materials	Nomenclature des composants logiciels
15	CBOM	Cryptographic Bill of Materials	Nomenclature des composants cryptographiques
16	ATLAS	Adversarial Threat Landscape for Artificial-Intelligence Systems	Base de connaissance MITRE des techniques visant les systèmes d’IA
17	OWASP	Open Worldwide Application Security Project	Communauté à l’origine des Top 10 pour les applications à base de LLM et agentiques
18	NIST	National Institute of Standards and Technology	Institut américain de normalisation, éditeur du cadre de gestion des risques liés à l’IA et de la taxonomie AI 100-2 E2025
19	MAESTRO	Multi-Agent Environment, Security, Threat, Risk and Outcome	Modèle de menace appliqué aux systèmes multi-agents
20	DNS	Domain Name System	Système de noms de domaine, source de télémétrie citée pour la détection
21	API	Application Programming Interface	Interface de programmation applicative
22	SOC	Security Operations Centre	Centre opérationnel de sécurité
23	SOAR	Security Orchestration, Automation and Response	Orchestration, automatisation et réponse en sécurité
24	OT	Operational Technology	Technologies opérationnelles, systèmes industriels et de procédés
25	AIBOM	Artificial Intelligence Bill of Materials	Nomenclature des composants d’un système d’IA
26	MTTD	Mean Time To Detect	Temps moyen de détection
27	MTTR	Mean Time To Respond	Temps moyen de réponse

Sources

• Australian Cyber Security Centre • Opportunities for AI in cyber defence : Use of AI by cyber security teams • première publication 27 mai 2026, mise à jour 12 août 2026 • https://www.cyber.gov.au/business-government/secure-design/artificial-intelligence/opportunities-for-ai-in-cyber-defence
• Centre canadien pour la cybersécurité • Bulletin conjoint sur les possibilités liées à l’intelligence artificielle en cyberdéfense • 7 août 2026 • https://www.cyber.gc.ca/fr/nouvelles-evenements/bulletin-conjoint-possibilites-liees-lintelligence-artificielle-cyberdefense
• CISA, NSA, CCCS, NCSC-NZ, NCSC-UK • Careful adoption of agentic AI services • publication conjointe citée par le guide
• National Cyber Security Centre du Royaume-Uni • Impact of AI on cyber threat from now to 2027 • évaluation citée par le guide
• National Institute of Standards and Technology • Adversarial Machine Learning : A Taxonomy and Terminology of Attacks and Mitigations, NIST AI 100-2 E2025 • référencé par le guide
• MITRE • ATLAS • base de connaissance référencée par le guide
• Australian Signals Directorate • Information Security Manual et Essential Eight • référentiels de rattachement du guide
• RadioCSIRT • Épisode 717 du jeudi 13 août 2026 • https://www.radiocsirt.org/podcast/ep-717-radiocsirt-flash-info-cybersecurite-du-jeudi-13-aout-2026/