Les équipes sécurité n'ont pas un problème de détection. Elles ont un problème de remédiation et un problème de communication, et ce sont les deux endroits où l'IA en sécurité rentabilise réellement son coût. Un scanner moderne vous livrera volontiers 800 constats face à un référentiel de conformité. Les constats ne sont pas la partie difficile. La partie difficile, c'est que la plupart ne sont jamais corrigés, et que ceux qui le sont restent invisibles pour les personnes qui approuvent le budget. Ce billet est un 101 sur les deux fonctionnalités IA qui, à mon sens, s'attaquent directement à cela : la remédiation automatisée avec une validation humaine, et le reporting généré par IA pour des lecteurs non techniques. J'utiliserai Aether365, une plateforme de sécurité Microsoft 365, comme exemple tout au long du texte. Transparence totale d'entrée de jeu : Aether365 est mon produit. Jugez les arguments sur le fond.

Un principe avant de commencer : le read-only est le mode par défaut. Rien n'obtient d'accès en écriture sur votre tenant sans un consentement séparé et explicite.

Les deux failles que tout scanner de sécurité laisse ouvertes

Lancez n'importe quel scan de posture sur un vrai tenant Microsoft 365, référentiel CIS, EIDSCA, CISA ScuBA, et vous obtenez la même forme de résultat : une longue liste de contrôles en échec avec des sévérités attachées. Deux choses prévisibles se produisent ensuite.

Premièrement, la file de constats survit à l'attention de tout le monde. Chaque correction exige de retrouver le bon centre d'administration, la bonne cmdlet PowerShell ou le bon appel Microsoft Graph, puis d'appliquer un changement dans un système d'identité en production où une erreur bloque de vrais humains. Multipliez par quelques centaines de constats et la file devient un arriéré, et les arriérés sont l'endroit où les constats vieillissent.

Deuxièmement, le rapport de scan ne quitte jamais l'équipe sécurité. Il est rédigé en identifiants de contrôle et en chemins de configuration. Les personnes qui décident des effectifs et du budget n'en voient rien, ou elles voient un score de conformité sans aucune histoire derrière. Un tenant peut rester à 60 pour cent de conformité pendant un an, et la direction ne comprendra ce que cela signifiait qu'au moment du retour d'expérience post-incident.

Remarquez qu'aucune de ces deux failles ne concerne la qualité de détection. Une meilleure détection élargit la première faille. C'est important, parce que l'essentiel du marketing « IA en sécurité » porte sur détecter davantage. Le travail intéressant se situe en aval de la détection.

AI Pilot : la remédiation avec une validation humaine

AI Pilot est la réponse d'Aether365 à la première faille, et sa conception est une étude de cas utile sur la manière dont la remédiation agentique devrait fonctionner, quel que soit celui qui la construit. La boucle comporte quatre étapes : scanner, proposer, approuver, appliquer et vérifier.

Le scan produit des constats. Pour chaque constat, le système génère une correction concrète associée au changement Microsoft Graph exact qu'il va effectuer, pas une suggestion en prose, la mutation réelle. Vous examinez ensuite chaque changement proposé individuellement et vous l'approuvez ou le rejetez élément par élément. Seuls les changements approuvés sont appliqués, et chaque changement appliqué est vérifié et consigné dans une piste d'audit.

La leçon 101 ici, c'est le modèle de permissions, car c'est là que les systèmes agentiques en production gagnent la confiance ou la perdent. L'accès en lecture seule est le comportement par défaut et le reste. AI Pilot exige une connexion Microsoft de consentement en écriture séparée et explicite, à laquelle vous adhérez volontairement. Si vous ne l'activez jamais, la plateforme ne peut physiquement pas modifier votre tenant. C'est ce qui rend l'outil utilisable pour les tenants européens et réglementés qui doivent rester en lecture seule : le chemin d'écriture n'est pas un interrupteur dans l'application, c'est une frontière de consentement appliquée par la couche d'autorisation de Microsoft elle-même.

Comparez avec le mode de défaillance : un agent totalement autonome avec un accès en écriture permanent qui corrige les choses à mesure qu'il les trouve. Cela semble efficace jusqu'à ce qu'il « corrige » une politique Conditional Access à 2 heures du matin et que l'ingénieur d'astreinte ne puisse plus se connecter pour voir pourquoi. L'autonomie sans validation par changement transforme un outil de remédiation en administrateur non audité doté d'une patience infinie. La validation n'est pas une limitation de l'IA. C'est la fonctionnalité.

Business Impact Reports : la couche de traduction

La seconde faille est la communication, et c'est l'usage des LLM le moins spectaculaire et le plus défendable en sécurité aujourd'hui. Les modèles de langage sont réellement bons dans un domaine où l'outillage de sécurité a toujours été mauvais : traduire un état technique en un récit sur lequel un lecteur non technique peut agir.

Business Impact Reports prend les constats bruts du scan et produit un document prêt pour le conseil d'administration : un résumé exécutif en langage clair, ce que le score de conformité signifie pour l'entreprise, quelles unités métier portent le plus de risque, une feuille de route priorisée de type « faites ceci en premier », et une correspondance des constats avec les obligations RGPD, NIS2 et ISO 27001. Il est généré dans l'une de 24 langues, ce qui compte plus qu'il n'y paraît : un directeur financier à Munich reçoit le rapport en allemand pendant que l'équipe sécurité travaille en anglais, à partir des mêmes données de scan.

Deux réserves ont leur place dans tout 101 honnête. Le rapport ne vaut que ce que vaut le scan en dessous ; un LLM qui narre de mauvaises données produit des absurdités assurées avec des numéros de page. Et le reporting généré par IA exige une position claire sur le traitement des données. Celle d'Aether365 : vos données de scan ne servent jamais à entraîner ou affiner un quelconque modèle, l'IA ne s'exécute que pour générer votre rapport à l'instant, et l'ensemble reste sous supervision humaine, en accord avec l'AI Act européen. Quel que soit l'outil que vous choisissez, exigez ces réponses par écrit.

Une checklist 101 pour toute fonctionnalité de sécurité IA

Retirez la marque et évaluez toute fonctionnalité « IA plus sécurité » avec cinq questions :

  • L'accès en écriture est-il optionnel et consenti séparément ? La lecture seule par défaut est le minimum attendu. Un chemin de consentement en écriture séparé est le vrai test.
  • Puis-je approuver chaque changement individuellement ? L'approbation en lot de 300 changements est un tampon, pas une validation.
  • Existe-t-il une piste d'audit vérifiée ? Appliqué n'est pas la même chose que vérifié. Vous voulez les deux, pour chaque changement.
  • L'IA prend-elle des décisions ou prépare-t-elle des présentations ? Une IA qui rédige des corrections et des rapports pour approbation humaine présente un risque faible. Une IA qui agit sans surveillance sur une infrastructure d'identité, non.
  • Mes données servent-elles à l'entraînement ? Si la réponse prend plus d'une phrase, la réponse est oui.

AI Pilot et Business Impact Reports sont, à mes yeux, la version honnête de l'IA en sécurité : le modèle fait le travail fastidieux de correspondance et de traduction, les humains gardent l'autorité. La détection n'a jamais été le goulot d'étranglement. Corriger et expliquer l'étaient, et c'est exactement là que cette génération d'outils doit viser.

À lire ensuite

Pour le versant infrastructure de cette histoire, pourquoi un tenant Microsoft 365 doit être traité comme n'importe quel autre parc cloud, voir Checking Cloud with Cloud: M365 Security Posture Scanning 101 sur ercan.cloud. Pour du conseil en IA, cloud et travail de plateforme, ou simplement pour dire bonjour, commencez par ercanermis.com.

Références