L’Enquête SANS IA 2026 : Pourquoi les attaques dopées à l’IA nécessitent toujours l’analyse critique d’un expert humain
Cette année, les équipes de sécurité ont confié une part croissante de leur charge de travail quotidienne à l’IA générative, et les outils les ont suffisamment souvent déçues pour que les professionnels s’en aperçoivent. L’enquête SANS AI 2026, menée auprès de 536 professionnels de l’IT et de la sécurité, chiffre les deux faces de cette évolution : l’adoption progresse, mais la fiabilité ne suit pas, et les professionnels les plus proches du terrain convergent vers une vieille réponse à une nouvelle question : un humain formé et sceptique détecte encore ce que le modèle rate.
L’enquête intervient à un moment charnière. L’IA générative est passée de projets pilotes à une utilisation quotidienne dans les centres d’opérations de sécurité en l’espace d’un an, prenant en charge le tri des logs, la synthèse des alertes, la priorisation des vulnérabilités et la rédaction des rapports d’incident.
En parallèle, 78 % des organisations déclarent avoir subi des attaques assistées par l’IA, dont moins de la moitié ont été confirmées par des preuves médico-légales, le reste demeurant à l’état de soupçon. Kiteworks observe cette même tension dans les environnements de données d’entreprise : plus les organisations adoptent l’IA rapidement, plus elles s’exposent à des flux de données non maîtrisés, à du contenu non vérifié qui alimente les modèles, et à des décisions prises sur la base d’un contexte jamais contrôlé. Les résultats SANS décrivent la version « opérations de sécurité » de ce même problème.
Ce que mesure l’enquête, et ce qu’un intervenant en gestion d’incident a confié à Help Net Security sur l’application de ces résultats sous pression, soulève une question à laquelle toutes les équipes de sécurité et de gouvernance des données sont aujourd’hui confrontées : comment calibrer la confiance dans un outil qui a généralement raison, mais parfois, avec assurance, tort ?
Le partage sécurisé de données Kiteworks répond à un aspect connexe mais distinct de ce problème. Lorsque des systèmes d’IA — copilotes SOC ou agents autonomes — analysent du contenu sensible, il faut d’abord qu’une personne ait vérifié ce contenu, contrôlé qui et quoi peut y accéder, et consigné toute la chaîne, au lieu de simplement supposer qu’il est fiable.
Résumé des points clés
1. L’adoption de l’IA dans les opérations de sécurité a bondi, mais la confiance n’a pas suivi.
L’utilisation active de l’IA générative chez les professionnels de la sécurité atteint 78 % en 2026, contre environ la moitié un an plus tôt, tandis que 63 % signalent désormais des insuffisances majeures dans la détection et la réponse aux menaces pilotées par l’IA.
2. Les attaques assistées par l’IA touchent désormais la majorité des organisations.
L’enquête SANS AI 2026 révèle que 78 % des organisations ont détecté des attaques assistées par l’IA au cours de l’année écoulée, dont 45 % confirmées et 33 % suspectées mais non prouvées.
3. Deux tiers des professionnels ont été induits en erreur par des recommandations IA au moins une fois cette année.
Neuf pour cent déclarent que cela s’est produit plus de vingt fois, rappelant à quel point les réponses de l’IA, souvent très assurées, peuvent être erronées.
4. C’est la rapidité des attaquants, et non leur sophistication, qui réduit le temps de réaction des défenseurs.
Les intrusions assistées par l’IA peuvent passer du point d’entrée au mouvement latéral en quelques minutes, supprimant le temps de latence sur lequel reposent les seuils de détection et les rotations d’astreinte.
5. Les professionnels privilégient les contrôles centrés sur l’humain aux outils spécifiques à l’IA pour contrer les menaces assistées par l’IA.
La détection comportementale, la formation à la sécurité, la relecture par un analyste humain et l’architecture zéro trust arrivent en tête du classement d’efficacité de l’enquête, loin devant les défenses spécialisées IA.
Vous pensez que votre organisation est sécurisée. Mais pouvez-vous le prouver ?
Pour en savoir plus :
Adoption plus rapide que la fiabilité : l’écart de confiance que les équipes de sécurité ne peuvent ignorer
Le chiffre d’adoption est déjà parlant en soi. L’utilisation active de l’IA générative dans la cybersécurité atteint 78 % des professionnels en 2026, contre environ la moitié un an plus tôt. Concrètement, cela signifie que la plupart des équipes de sécurité font désormais passer une partie de leur flux de travail quotidien par une couche IA, qu’il s’agisse d’un copilote qui synthétise une file d’alertes, d’un modèle qui évalue la gravité d’une vulnérabilité ou d’un assistant qui rédige la première version d’un rapport d’incident.
La fiabilité, elle, n’a pas suivi cette croissance. Soixante-trois pour cent des professionnels déclarent des insuffisances majeures lorsque l’IA détecte ou répond à des menaces, un taux bien supérieur à celui constaté l’année précédente. Les échecs ne sont pas aléatoires : ils se concentrent autour de trois motifs récurrents — des faux positifs qui font perdre du temps aux analystes, des difficultés à reconnaître des menaces nouvelles ou inhabituelles qui n’apparaissent pas dans les données d’entraînement, et des résultats très assurés qui s’avèrent tout simplement erronés.
Matt Bromiley, SANS certified instructor et intervenant en gestion d’incident, décrit là où les professionnels ont appris à fixer la limite. « Nos données montrent que les professionnels sont à l’aise pour laisser l’IA classifier les menaces ou prioriser les vulnérabilités, mais beaucoup moins pour la laisser confirmer un vrai positif ou juger une anomalie comportementale », a-t-il confié à Help Net Security.
Cette distinction est essentielle : elle sépare les tâches disposant d’un vaste corpus d’entraînement bien étiqueté des jugements qui dépendent d’un contexte auquel un modèle d’IA n’a que rarement accès. « Ces outils montrent qu’ils sont efficaces sur des problèmes structurés et faibles sur les décisions contextuelles », explique Bromiley. « On développe l’instinct en apprenant à connaître les faiblesses de l’outil et en vérifiant en fonction du coût d’une erreur. »
Cet instinct — savoir quand faire confiance à la confiance du modèle et quand vérifier — est précisément la compétence que l’enquête estime que le secteur n’a pas développée assez vite. L’adoption a dépassé la formation à la sécurité et l’évaluation des risques nécessaires pour utiliser ces outils en toute sécurité, et ce décalage se retrouve directement dans les chiffres sur les erreurs d’aiguillage ci-dessous.
Quand les recommandations IA induisent en erreur : le coût des réponses fausses mais assurées
Un répondant à l’enquête compare l’utilisation des outils IA à la gestion d’un stagiaire numérique — utile, parfois pertinent, mais nécessitant une relecture avant toute diffusion. Bromiley partage ce point de vue. « Je ne peux qu’être d’accord : ‘mesurez deux fois, coupez une fois’ », dit-il. « Malheureusement, la plupart des équipes n’ont pas les outils pour développer cet instinct. »
L’ampleur du problème confirme la métaphore. Deux tiers des professionnels ont été induits en erreur par des recommandations IA au moins une fois cette année, et 9 % déclarent que cela s’est produit plus de vingt fois. Ce n’est pas un problème d’IA inutile. C’est un problème d’IA suffisamment souvent faussement sûre d’elle pour que la vérification doive être intégrée au processus, et non laissée à l’appréciation individuelle.
Un résultat erroné mais assuré est particulièrement dangereux dans les opérations de sécurité, car le coût d’une action basée dessus n’est pas symétrique. Un faux positif fait perdre une heure. Un vrai positif manqué, confirmé comme bénin par un système IA que personne n’a vérifié, peut laisser une intrusion active perdurer plusieurs jours. L’exposition à une fuite de données qui en résulte — en particulier pour les organisations traitant des informations personnelles identifiables (PII), des informations médicales protégées (PHI) ou des données financières réglementées — aggrave l’échec de sécurité par des obligations de notification réglementaire et de remédiation qui suivent leur propre calendrier.
L’un des problèmes sous-jacents est la provenance des données : les modèles produisent des réponses assurées à partir du contexte fourni, et si ce contexte est incomplet, obsolète ou issu de sources non vérifiées, le résultat paraît aussi crédible que s’il venait de données propres. C’est là que les pratiques de gouvernance des données et de traçabilité rejoignent la fiabilité de l’IA : un analyste peut calibrer plus facilement sa confiance dans un résultat s’il peut retracer exactement quelles données le modèle a vues et vérifier qu’aucune n’a été altérée, mal classée ou erronée à la base. En l’absence de cette traçabilité, les équipes doivent calibrer leur confiance uniquement sur la sortie, sans pouvoir vérifier l’entrée.
L’argument de Bromiley sur la formation prolonge ce point. « En tant qu’instructeur, je peux témoigner que la salle de classe apporte bien plus qu’on ne le pense », dit-il. « On peut y enseigner les modes d’échec, l’instrumentation, ce qu’il faut vérifier avant d’agir, et comment faire tourner un système en parallèle assez longtemps pour voir où il dérive. Mais on ne peut pas transmettre par un cours la calibration, c’est-à-dire le degré de doute qu’un résultat doit susciter. Une bonne formation accélère simplement ces répétitions dans un contexte où l’erreur ne coûte pas cher. » La formation construit la checklist. Seule l’expérience — idéalement encadrée et à faible enjeu — forge le jugement pour l’appliquer sous pression.
Chronologie compressée : comment les attaques assistées par l’IA effacent le temps de réaction des défenseurs
Le versant offensif de l’enquête impose une échéance à tout cela. Bromiley décrit un incident où le facteur déterminant n’était pas la technique de l’attaquant, mais le tempo. « J’ai travaillé sur un cas où c’est le rythme qui nous a pris de court », explique-t-il.
L’intrusion a commencé par une défaillance de gestion des risques supply chain : un package malveillant compromis via la chaîne logicielle a permis à l’attaquant d’entrer dans un environnement logiciel de confiance. Ensuite, l’intrusion est passée de la reconnaissance interne au mouvement latéral en quelques minutes, l’adversaire déployant des scripts à la chaîne. « Le rythme était effréné — l’adversaire utilisait aussi des scripts bien commentés, avec des instructions détaillées, typiques d’un ‘script développé par IA’ », précise Bromiley.
Il reste prudent sur l’attribution. « Je préfère rester mesuré. Nous avons estimé que ces scripts étaient probablement générés par IA en raison de leur structure et de la rapidité d’itération, pas parce que nous en avons la preuve », explique-t-il.
Cette nuance rejoint la façon dont l’enquête présente les chiffres : sur les 78 % d’organisations signalant des attaques assistées par l’IA, 45 % l’ont confirmé par des preuves, 33 % ne l’ont que soupçonné.
Le cas de Bromiley appartient à la seconde catégorie — une déduction raisonnable, pas une certitude médico-légale, et les auteurs de l’enquête tiennent à maintenir cette distinction.
Ce qu’il veut que les défenseurs retiennent, ce n’est pas la question de l’attribution, mais celle du rythme. « Ce qui a changé, c’est la cadence. La reconnaissance suivie du mouvement latéral donne d’habitude du temps aux défenseurs, car c’est lent et manuel. Ici, ce temps a quasiment disparu », explique-t-il. « Les seuils de détection et les rotations d’astreinte supposent une certaine latence côté attaquant, et c’est cette hypothèse qui est remise en cause. »
La phase reconnaissance-mouvement latéral est normalement la plus lente et la plus manuelle d’une intrusion, et le délai qu’elle induit est la fenêtre dont dispose l’équipe de sécurité pour réagir. Supprimez ce délai, et la marge d’erreur disparaît avec lui.
Les menaces persistantes avancées s’appuyant sur des outils assistés par l’IA n’ont pas besoin de techniques inédites pour être dangereuses — il leur suffit d’aller plus vite que le processus de réponse. Une plateforme SIEM qui ingère en temps réel les flux de données sortantes et les mouvements latéraux constitue la couche de détection qui transforme cette rapidité en un signal visible et exploitable.
Ce en quoi les professionnels ont confiance : détection comportementale, relecture humaine et Zéro Trust
En revenant sur l’incident, Bromiley liste ce que l’équipe aurait aimé avoir en place avant la première alerte. « Ils voulaient un inventaire précis de leur chaîne logicielle, une journalisation des flux sortants rendant la phase de reconnaissance visible en temps réel, et des comptes de service restreints pour limiter la portée de l’intrusion — ce qui rejoint les résultats de l’enquête », explique-t-il.
Ces trois priorités correspondent exactement à ce que l’enquête révèle lorsque les professionnels classent les contrôles auxquels ils font le plus confiance face aux menaces assistées par l’IA. La détection comportementale, la formation à la sécurité, la relecture par un analyste humain et l’architecture zéro trust arrivent en tête. Les outils spécialisés IA ferment la marche. « La détection comportementale fonctionne parce qu’elle observe ce que fait l’attaquant, pas ce que le script a écrit », explique Bromiley. « La rapidité ne nécessite pas de contre-mesure inédite ; elle supprime simplement la marge de manœuvre qui permettait aux équipes d’improviser. »
Le schéma est clair : les défenseurs font confiance aux contrôles qui limitent ce qu’un attaquant — humain ou assisté par IA — peut réellement faire dans l’environnement, plutôt qu’à ceux qui tentent d’analyser l’outil de l’attaquant.
Un modèle de contrôle d’accès basé sur le principe du moindre privilège et le contrôle d’accès basé sur les rôles limite la progression d’un compte de service compromis, quelle que soit la rapidité de l’attaquant. L’ABAC ajoute une couche contextuelle que le RBAC ne fournit pas seul : les décisions d’accès évaluent la sensibilité du contenu, le rôle utilisateur et la posture du terminal à chaque requête, de sorte qu’un compte compromis opérant en dehors de son comportement habituel déclenche un blocage plutôt que d’hériter de toutes ses autorisations.
Les pratiques de gestion des risques tiers qui maintiennent un inventaire précis de la chaîne logicielle comblent exactement la faille qui a permis l’intrusion du package malveillant de Bromiley. Aucun de ces contrôles n’est spécifique à l’IA. Ce sont des fondamentaux de la sécurité qui restent efficaces, que l’attaquant soit une personne ou un script.
Développer un scepticisme calibré : formation, gouvernance et humain dans la boucle
La conclusion centrale de l’enquête, en résumé, est que le secteur a un problème de calibration, pas d’intelligence. Les systèmes d’IA sont assez bons pour traiter des tâches structurées et bien délimitées, mais pas encore pour les jugements qui dépendent du contexte complet. Les professionnels qui s’en sortent le mieux ne sont pas ceux qui évitent l’IA, mais ceux qui ont appris, souvent à leurs dépens, quels résultats nécessitent une seconde vérification et lesquels non.
Cette calibration ne se fait pas dans le vide. Elle dépend de la capacité de l’analyste à voir ce que l’IA a vu : quelles données ont alimenté le modèle, si elles étaient à jour et vérifiées, et qui y a accédé avant que le modèle ne les analyse.
C’est là que la gouvernance cesse d’être un exercice de conformité pour devenir un outil de fiabilité. La gouvernance des données IA qui applique les règles au moment où le contenu atteint le modèle — plutôt qu’après coup — réduit le risque qu’un système IA produise une réponse assurée à partir de données obsolètes, non autorisées ou altérées.
La classification des données auxquelles les systèmes IA peuvent accéder est le contrôle préalable indispensable : une couche de gouvernance ne peut appliquer des politiques différenciées sur des données qu’elle n’a pas catégorisées. Kiteworks Compliant AI applique précisément ce type de contrôle à la frontière entre la donnée et l’IA. Elle filtre et régule le contenu accessible aux systèmes génératifs et agents, pour que la réponse affichée à l’analyste repose sur des données effectivement vérifiées, et non sur ce que le modèle a pu trouver au hasard.
Le même principe s’applique à l’IA agentique. À mesure que les équipes de sécurité connectent des agents IA directement aux systèmes internes et aux bases de données via des protocoles comme MCP, le défi de calibration décrit par Bromiley ne disparaît pas — il s’accroît, car un agent agissant sur un mauvais contexte peut passer à l’action, et pas seulement donner un conseil.
Un Serveur MCP Sécurisé qui régule ce qu’un agent peut lire, consigne chaque accès et applique les mêmes politiques que pour les utilisateurs humains permet aux équipes de sécurité d’étendre la confiance calibrée aux systèmes autonomes, exactement comme Bromiley décrit la construction de cette confiance chez les analystes humains : en connaissant les faiblesses, en instrumentant pour les détecter, et en vérifiant selon le coût d’une erreur.
Combler l’écart de préparation : la gouvernance, couche manquante
Les auteurs de l’enquête présentent les 12 prochains mois comme un test : les organisations sauront-elles combler l’écart de préparation face au déploiement IA déjà engagé ? Trois priorités se dégagent : une validation qui mesure réellement la précision et le rappel, et non les promesses des fournisseurs ; une gouvernance intégrée aux contrôles utilisés au quotidien par les analystes, et non cantonnée à des documents de politique ; et le développement des compétences du personnel traité comme un besoin opérationnel immédiat, pas comme une ligne de budget formation pour l’an prochain.
L’incident de Bromiley illustre concrètement les enjeux. Le rythme d’une intrusion assistée par l’IA consomme exactement le temps que les défenseurs ont passé l’année écoulée à développer leur instinct d’utilisation.
Combler cet écart ne consiste pas à acheter un meilleur outil de détection IA — l’enquête est claire : les contrôles spécifiques à l’IA sont les moins plébiscités. Il s’agit de réduire l’espace où une sortie fausse mais assurée, qu’elle provienne d’un outil d’attaquant ou d’un assistant IA du défenseur, peut causer des dégâts avant qu’un humain ne la détecte.
Une gouvernance des données qui vérifie le contenu avant qu’il n’atteigne un modèle, une traçabilité sur ce qu’un système IA a réellement consulté, et des contrôles d’accès qui limitent l’impact réduisent tous cette fenêtre de vulnérabilité.
Un plan de réponse aux incidents documenté, qui modélise explicitement le scénario « agent IA agissant sur un mauvais contexte » — avec des procédures de retour arrière et des seuils d’escalade humaine — complète l’architecture de gouvernance : il définit ce qui se passe après la détection, et pas seulement comment détecter.
Aucun de ces éléments ne remplace l’analyste sceptique auquel l’enquête revient sans cesse. Ils lui offrent simplement une base fiable sur laquelle exercer son scepticisme.
Pour en savoir plus sur la gouvernance des données accessibles à vos systèmes IA et la traçabilité vérifiable de chaque accès, réservez une démo personnalisée dès maintenant.
Foire aux questions
L’enquête SANS AI 2026 a interrogé 536 professionnels de l’IT et de la sécurité sur leur usage de l’IA générative dans la cybersécurité et sur la fiabilité de ces outils en pratique. Elle mesure les taux d’adoption, les domaines où les professionnels font confiance aux résultats de l’IA et ceux où ils préfèrent vérifier manuellement, la fréquence des erreurs d’aiguillage, ainsi que l’expérience des organisations face aux attaques assistées par l’IA. Les résultats sont étroitement liés aux pratiques d’évaluation des risques et de gouvernance des données qui déterminent la fiabilité des déploiements IA. Les organisations soumises à des obligations de conformité réglementaire — HIPAA, RGPD, CMMC — doivent considérer les conclusions sur la provenance des données comme directement applicables : les mêmes failles de gouvernance qui produisent des résultats IA faussement assurés dans un SOC exposent aussi les données réglementées à des risques liés à l’IA.
Les professionnels font le plus confiance à l’IA pour des problèmes structurés et bien étiquetés, comme la classification des menaces ou la priorisation des vulnérabilités, où les données d’entraînement sont abondantes et la tâche clairement définie. Confirmer un vrai positif ou juger une anomalie comportementale exige un jugement contextuel que les modèles d’IA gèrent mal, ce qui explique pourquoi 63 % des répondants signalent des insuffisances majeures dans la détection et la réponse pilotées par l’IA. Des contrôles d’accès robustes et une provenance des données vérifiée réduisent cet écart en garantissant que l’IA raisonne sur des informations précises et à jour. La minimisation des données accessibles aux systèmes IA — en limitant chaque modèle au strict nécessaire pour sa tâche — réduit aussi la surface sur laquelle une réponse fausse mais assurée peut avoir un impact opérationnel.
Dans l’incident décrit par Bromiley, une compromission supply chain est passée du point d’entrée au mouvement latéral en quelques minutes, alors que la reconnaissance manuelle prend habituellement des jours ou des semaines. Les seuils de détection et les rotations d’astreinte reposent sur l’hypothèse d’un temps de latence côté attaquant, et les outils assistés par l’IA réduisent fortement ce tampon. Pour ne plus dépendre de ce délai, il faut des contrôles comme l’architecture zéro trust et la visibilité sur les flux sortants, qui ne reposent pas sur la détection en pleine reconnaissance. Un SIEM avec ingestion de télémétrie en temps réel et analyse comportementale constitue l’infrastructure de détection qui transforme ce temps de latence réduit en anomalie détectée — les organisations dépourvues de cette couche de visibilité sont structurellement aveugles au schéma d’attaque documenté par l’enquête.
La détection comportementale, la formation à la sécurité, la relecture par un analyste humain et l’architecture zéro trust arrivent en tête de la confiance des professionnels, tandis que les outils spécialisés IA ferment la marche. Le point commun est que ces contrôles limitent ce qu’un attaquant peut réellement faire dans l’environnement, plutôt que d’essayer de surpasser l’outil de l’attaquant. Les pratiques de gestion des risques tiers, incluant un inventaire précis de la chaîne logicielle, figurent aussi parmi les besoins exprimés. Les politiques ABAC, qui évaluent la sensibilité du contenu et le contexte utilisateur à chaque requête — et pas seulement lors de l’authentification initiale — sont l’implémentation du contrôle d’accès qui permet d’appliquer le principe du moindre privilège supposé par les contrôles les mieux classés de l’enquête.
Les systèmes IA produisent des réponses très assurées à partir du contexte fourni, et si ce contexte est obsolète, non vérifié ou non autorisé, le résultat paraît aussi crédible que s’il venait de données propres. Appliquer la gouvernance au moment où le contenu atteint le modèle — via des outils comme Kiteworks Compliant AI et un Serveur MCP Sécurisé pour l’accès agentique — offre aux analystes une traçabilité vérifiable de ce que l’IA a réellement consulté, ce qui facilite la calibration de la confiance à accorder à chaque résultat. Un plan de réponse aux incidents documenté, couvrant les scénarios d’erreur d’agent IA — y compris le mode opératoire lorsque le système IA a agi sur des données erronées ou non autorisées — transforme cette infrastructure de gouvernance d’un contrôle préventif en une capacité de réponse complète.
Ressources complémentaires
- Article de blog
Stratégies zéro trust pour une protection abordable de la vie privée à l’ère de l’IA - Article de blog
Comment 77 % des organisations échouent à sécuriser les données IA - eBook
AI Governance Gap : pourquoi 91 % des petites entreprises jouent à la roulette russe avec la sécurité des données en 2025 - Article de blog
Il n’existe pas de « –dangerously-skip-permissions » pour vos données - Article de blog
Les régulateurs ne se contentent plus de demander si vous avez une politique IA. Ils veulent des preuves de son efficacité.