Le Microsoft Digital Defense Report 2026, publié le 1er octobre 2026, décrit un changement que les équipes de sécurité ne peuvent plus ignorer. L'intelligence artificielle ne sert plus uniquement à accélérer le travail des attaquants humains. Elle dirige désormais des séquences d'attaque de façon autonome : identification de la vulnérabilité, exploitation, mouvement latéral, exfiltration. Les humains supervisent. La machine exécute. Ce glissement change une hypothèse fondamentale dans vos programmes NIS2 et DORA : celle que votre organisation disposera de suffisamment de temps entre l'intrusion et la détection pour déclencher une procédure d'alerte.
Ce que le rapport documente précisément
Le Microsoft DDR 2026 analyse l'activité de menace enregistrée entre janvier et juin 2026. Deux données structurent l'analyse. Premièrement, l'IA est passée d'un rôle d'assistance à un rôle de direction dans les attaques : les groupes malveillants utilisent des systèmes agentiques pour chaîner automatiquement les étapes d'une intrusion, du phishing initial jusqu'à la collecte de données, sans intervention manuelle entre les étapes. Deuxièmement, 39 000 vulnérabilités ont été publiées dans les seuls six premiers mois de 2026 (source : Microsoft Digital Defense Report 2026, 1er octobre 2026), ce qui met l'année sur une trajectoire de doublement du record annuel historique.
Ces deux données se combinent. La surface d'exposition s'élargit à une vitesse sans précédent. Les outils capables d'exploiter automatiquement les vulnérabilités nouvellement publiées atteignent les opérateurs malveillants plus vite qu'auparavant. Le délai entre la publication d'un CVE et son exploitation active se comprime : ENISA documentait, dans son Threat Landscape de septembre 2026, que 73 % des organisations victimes d'une intrusion avaient un patch disponible au moment de l'attaque qu'elles n'avaient pas encore déployé (source : ENISA Threat Landscape 2026, septembre 2026).
Pourquoi le T0 NIS2 devient le point de rupture
La directive NIS2 et sa transposition française imposent une alerte précoce à l'ANSSI dans les 24 heures suivant la « prise de connaissance » d'un incident significatif. Ce délai de 24 heures est calculé depuis T0, le moment où l'entité prend connaissance de l'incident.
La logique implicite de ce délai suppose que l'intrusion se déroule sur plusieurs jours ou semaines : l'attaquant entre, se déplace, établit sa persistance, puis commence à exfiltrer. L'organisation dispose d'une fenêtre pour détecter. Si ses outils fonctionnent, elle déclenche la procédure avant que l'exfiltration ne soit complète.
L'attaque autonome guidée par l'IA brise cette hypothèse. Quand une séquence d'exploitation automatisée peut enchaîner accès initial, élévation de privilèges et collecte de données en moins d'une heure, T0 ne précède plus l'exfiltration. Il coïncide avec elle, ou arrive après. L'organisation apprend l'incident au moment où les données ont déjà quitté le périmètre.
Ce n'est pas une situation hypothétique. Le CERT-FR documente depuis 2025 des compromissions où le délai entre l'accès initial et le début de l'exfiltration s'établit en dessous de deux heures pour les intrusions les plus automatisées. Le problème n'est pas la notification : c'est la détection.
Un exemple concret : l'attaque sur un prestataire logistique
En août 2026, un opérateur logistique européen relevant de NIS2 a subi une intrusion exploitant une vulnérabilité publiée 11 jours plus tôt dans un composant de son VPN. La séquence enregistrée dans les journaux : exploitation à 02h17, création d'un compte de service privilégié à 02h31, connexion au serveur de fichiers RH à 02h44, exfiltration de 4 Go de données vers un service de stockage externe entre 02h51 et 03h09. L'alerte SIEM s'est déclenchée à 03h22, sur la détection d'un volume anormal de transfert sortant.
L'organisation a notifié l'ANSSI à 04h15. Elle était dans les délais. Mais au moment de la notification, 4 Go de données RH incluant des informations à caractère spécial avaient déjà quitté l'infrastructure. La notification RGPD aux personnes concernées devenait obligatoire. L'organisation avait respecté la lettre de NIS2 et de l'article 33 du RGPD. Elle n'avait pas détecté l'intrusion à temps pour l'arrêter.
Ce que cela impose à votre programme de détection
La réponse n'est pas d'accélérer la notification. C'est de déplacer la détection plus tôt dans la chaîne d'attaque. Les pièges opérationnels de la notification d'incident NIS2 en 24 heures incluent déjà le risque d'une détection trop tardive. Ce que le contexte des attaques autonomes ajoute, c'est une contrainte de temps nouvelle : votre MTTD (Mean Time To Detect) doit maintenant être mesuré en minutes, non en heures, pour les segments d'infrastructure les plus critiques.
Trois ajustements concrets s'imposent.
Premier ajustement : couverture comportementale sur les comptes à privilèges. Les attaques automatisées ciblent d'abord les identifiants à hauts privilèges. Un système UEBA (User and Entity Behavior Analytics) calibré sur les comportements normaux de ces comptes peut détecter une création de session inhabituelle en dehors des plages horaires normales dans les premières minutes. La règle de détection n'est pas complexe. Elle est absente dans la majorité des programmes NIS2 audités en 2025 selon les équipes terrain de l'ANSSI.
Deuxième ajustement : surveillance du volume sortant en temps réel. L'exfiltration laisse une trace volumétrique. Un transfert de plusieurs gigaoctets vers un service cloud non répertorié à 3h du matin est détectable par un outil DLP (Data Loss Prevention) configuré sur des seuils dynamiques. Ce type de détection ne nécessite pas une corrélation complexe. Il nécessite d'avoir activé la supervision de l'activité réseau sortante, ce que beaucoup d'organisations différent pour des raisons de coût ou de complexité.
Troisième ajustement : test de la chaîne de détection, pas seulement de la procédure de notification. Les exercices de simulation d'incident se concentrent souvent sur la procédure de notification : qui appelle qui, quel formulaire, quel délai. Le scénario d'une attaque autonome à 2h du matin, dont la détection intervient après l'exfiltration, devrait faire partie de vos exercices. Le résultat vous donnera une mesure réelle de votre MTTD sur les scénarios les plus à risque.
Ce que le glissement vers l'autonomie change pour vos plans de remédiation
Le Microsoft DDR 2026 identifie un second effet du passage à l'IA autonome : les groupes malveillants peuvent désormais opérer à une échelle qui dépasse la capacité humaine de supervision. Un seul opérateur peut superviser des dizaines d'intrusions simultanées, déléguant l'exécution à des systèmes agentiques.
Pour vos équipes, cela signifie que le volume d'incidents significatifs auxquels vous devrez notifier pourrait augmenter. NIS2 impose une notification pour chaque incident significatif. Si votre organisation est visée par plusieurs intrusions simultanées automatisées, votre charge opérationnelle de notification peut dépasser la capacité de votre équipe sécurité.
La réponse n'est pas d'ajouter des ressources humaines. C'est de disposer d'un système de gestion des incidents qui automatise la qualification (significatif ou non), la documentation de la chronologie et la pré-rédaction de la notification, pour que vos équipes se concentrent sur les décisions à fort enjeu. C'est précisément ce que Presidio couvre dans son module de gestion d'incidents : qualification automatique selon les critères NIS2, chronologie horodatée immuable et assistant de rédaction de notification.
L'exigence réglementaire ne change pas. La menace, si.
NIS2 ne sera pas révisé pour tenir compte des attaques autonomes. Le délai de 24 heures reste 24 heures. Ce qui change, c'est que maintenir le respect de ce délai exige aujourd'hui une détection que la majorité des organisations n'ont pas encore mise en place. Votre capacité à notifier dans les temps dépend de votre capacité à détecter avant l'exfiltration. Ce n'est plus une question de procédure. C'est une question d'infrastructure.