M365-Expert : LLM sécurité et hardening Microsoft 365

M365-Expert est un assistant LLM mis à disposition sur le portfolio huggingface de Ayi Nedjimi pour accompagner les administrateurs et RSSI dans le hardening de Microsoft 365. Le modèle a été fine-tuné sur un corpus combinant le CIS Benchmark Microsoft 365 dans sa version la plus récente, la documentation Microsoft Defender for Office 365 et Defender for Cloud Apps, les guides Purview pour la classification et la prévention des pertes de données, la documentation Entra ID anciennement Azure AD avec une focale sur Conditional Access et Privileged Identity Management, ainsi que les recommandations ANSSI applicables aux environnements cloud français. L'objectif est de fournir un copilote capable de diagnostiquer une configuration tenant, de prioriser les actions de hardening, de proposer des politiques Conditional Access concrètes, d'aider à investiguer un incident MailFlow, ou de produire la documentation d'un projet Zero Trust dans Microsoft 365. Tout est calibré pour rester déployable en local et préserver la confidentialité des tenants traités.

Intégration du LLM M365 dans les workflows de sécurité Office 365

L'intégration du LLM M365-Expert dans les workflows opérationnels de sécurité Microsoft 365 transforme la manière dont les équipes IT et sécurité interagissent avec le tenant. Plutôt que de naviguer manuellement dans le Security Center, Compliance Center et Exchange Admin Center, les administrateurs peuvent interroger le modèle en langage naturel pour obtenir des diagnostics, des configurations et des playbooks d'intervention.

L'un des cas d'usage les plus impactants est la gestion des incidents de phishing à grande échelle. Lorsqu'une campagne de phishing est détectée, le LLM peut générer automatiquement le script PowerShell pour quarantainer tous les e-mails correspondant à un pattern donné via Exchange Online Protection, révoquer les sessions authentifiées des utilisateurs ciblés, et ajouter les domaines malveillants à la blocklist Defender pour Office 365 — en quelques secondes vs plusieurs dizaines de minutes en configuration manuelle.

La revue des politiques Conditional Access est une autre application à forte valeur : le LLM analyse les règles existantes, identifie les gaps de couverture (utilisateurs non couverts, scénarios non traités), détecte les conflits entre règles et propose des optimisations alignées avec le CIS Microsoft 365 Benchmark. Cette revue, qui nécessite habituellement une expertise pointue en Azure AD, devient accessible à des administrateurs de niveau intermédiaire avec l'assistance du modèle.

Dans le cadre de la conformité continue, le LLM peut analyser les rapports de Secure Score Microsoft, interpréter les recommandations dans le contexte spécifique de l'organisation, prioriser les actions selon leur impact sur le score et la criticité business, et générer les tickets de remédiation formatés pour le système ITSM de l'organisation. Cette capacité de traduction entre les recommandations techniques Microsoft et le plan d'action opérationnel est particulièrement précieuse pour les organisations sans expertise M365 dédiée.

Limites opérationnelles et supervision du LLM M365-Expert

Malgré ses capacités étendues, le LLM M365-Expert présente des limites que les organisations doivent identifier et gérer pour éviter des configurations erronées ou des faux sentiments de sécurité. La compréhension de ces limites est aussi importante que la maîtrise de ses fonctionnalités.

La première limite concerne la fraîcheur des informations : Microsoft 365 évolue rapidement avec des nouvelles fonctionnalités, des changements d'interface et des modifications de comportement publiés chaque mois. Le modèle a une date de coupure de connaissance et peut donner des informations obsolètes sur des fonctionnalités récemment modifiées. Il est essentiel de vérifier les informations critiques dans la documentation officielle Microsoft et de croiser les recommandations du modèle avec les notes de version M365.

La seconde limite est le manque de contexte tenant : sans accès à votre configuration réelle (logs, paramètres, utilisateurs), le modèle raisonne sur des scénarios génériques. Les recommandations doivent donc être adaptées à votre contexte spécifique avant application. L'intégration via Microsoft Graph API pour fournir au modèle des données de contexte réelles (état du Secure Score, liste des politiques actives, résultats de rapports d'audit) améliore significativement la pertinence des réponses.

Enfin, le LLM ne remplace pas une expertise humaine certifiée (MS-500, SC-300, SC-400) pour les décisions architecturales majeures et les configurations à fort impact (modifications des politiques d'authentification globales, changements de paramètres Exchange Online affectant l'ensemble des utilisateurs). L'outil est un accélérateur et un support à la décision, pas un substitut à l'expertise humaine pour les opérations critiques. Documenter systématiquement les décisions prises avec l'assistance du LLM, avec validation par un expert certifié, constitue la bonne pratique à adopter.

Déploiement en entreprise : architecture et gouvernance du LLM M365

Le déploiement du LLM M365-Expert dans un environnement d'entreprise nécessite une architecture réfléchie qui intègre les contraintes de sécurité, de disponibilité et de gouvernance propres aux organisations de taille significative. Une approche non structurée risque de créer des Shadow IT ou des usages non conformes au RGPD.

L'architecture de référence pour un déploiement sécurisé comprend : un serveur d'inférence isolé dans un segment réseau dédié (pas d'accès internet direct depuis le modèle), une API gateway avec authentification OAuth 2.0 et journalisation des requêtes, un système de gestion des secrets (HashiCorp Vault, Azure Key Vault) pour les tokens d'accès Microsoft Graph, et un pipeline de mise à jour régulière du modèle (mensuel minimum) aligné avec les évolutions de Microsoft 365.

La gouvernance des usages passe par la définition d'une charte d'utilisation du LLM précisant les cas d'usage autorisés et interdits, les types de données pouvant être soumis au modèle (notamment l'interdiction d'y soumettre des données personnelles d'utilisateurs ou des identifiants de connexion), et les responsabilités en cas d'erreur de configuration résultant d'une recommandation du modèle. Cette charte doit être signée par les utilisateurs et intégrée dans le programme de formation des administrateurs.

Le modèle de support doit prévoir un niveau d'escalade vers des experts humains certifiés Microsoft pour les situations où le LLM donne des réponses contradictoires ou incertaines. Un canal de feedback permettant aux administrateurs de signaler les erreurs du modèle alimente un processus d'amélioration continue. Les corrections validées par des experts sont intégrées dans les cycles de fine-tuning suivants, créant une boucle vertueuse d'amélioration de la qualité basée sur les cas réels rencontrés dans l'organisation.

Enfin, l'évaluation du ROI du LLM M365-Expert doit être menée 6 à 12 mois après le déploiement : temps économisé sur les tâches répétitives (configuration, audit, documentation), réduction des tickets de support de niveau 2 sur les problématiques M365, amélioration du Secure Score, et nombre d'incidents de sécurité détectés précocement grâce aux analyses assistées. Ces métriques justifient le renouvellement de l'investissement et guident les évolutions futures du modèle.

Pourquoi un LLM dédié à Microsoft 365

Microsoft 365 est devenu le cœur du SI bureautique de l'écrasante majorité des entreprises. Sa surface d'attaque est colossale : Exchange Online, SharePoint, OneDrive, Teams, Power Platform, Entra ID, Microsoft Defender, Purview, Intune. Chaque service expose ses propres réglages, ses propres consoles, ses propres journaux. Les attaquants exploitent les failles de configuration et les autorisations OAuth permissives plus que des vulnérabilités logicielles classiques. La consoles d'administration changent régulièrement, les noms des fonctionnalités évoluent et les bonnes pratiques se déplacent.

Un LLM généraliste fournit des réponses approximatives sur Microsoft 365, mélangeant l'ancien Azure AD avec le nouveau Entra ID, confondant DLP Purview avec les anciennes règles MailFlow, ou suggérant des paramètres déconseillés. M365-Expert a été fine-tuné spécifiquement pour éliminer ces confusions. Il connaît la nomenclature à jour, sait référencer les contrôles CIS par leur numéro et anticipe les pièges fréquemment relevés lors d'audits.

À quoi sert M365-Expert

Le modèle s'adresse à quatre profils. L'administrateur Microsoft 365 qui veut un copilote pour configurer ou auditer un tenant. Le RSSI qui veut comprendre rapidement la posture de sécurité de son environnement cloud collaboratif. L'auditeur ou consultant qui réalise des missions d'évaluation Microsoft 365. L'équipe SOC qui investigue un incident impliquant Exchange, SharePoint ou Entra ID.

Concrètement, le modèle peut générer une checklist de hardening, expliquer un contrôle CIS spécifique, proposer une politique Conditional Access pour un cas d'usage donné, suggérer une stratégie DLP Purview adaptée à un secteur, analyser un message d'erreur PowerShell Exchange Online, expliquer le fonctionnement de la cascade d'autorisations Microsoft Graph et préparer une réponse à un incident BEC ou phishing avancé.

Méthodologie d'entraînement

Le corpus repose sur quatre piliers. Premier pilier, le CIS Microsoft 365 Foundations Benchmark, dans sa version la plus récente avec les niveaux L1 et L2. Chaque contrôle a été reformulé en plusieurs paires question-réponse couvrant la finalité, la commande PowerShell ou la procédure portail, l'impact opérationnel et les pièges de mise en œuvre.

Deuxième pilier, la documentation Microsoft officielle des services suivants : Defender for Office 365, Defender for Cloud Apps, Defender for Identity, Purview, Entra ID dont Conditional Access et PIM, Intune. Le corpus a été enrichi par les advisories et bulletins sécurité émis par le MSRC.

Troisième pilier, les recommandations ANSSI applicables au cloud collaboratif, en particulier les guides hygiène et configuration sécurisée. La perspective francophone et souveraine est essentielle pour les organisations soumises à des exigences SecNumCloud ou voulant s'aligner sur la doctrine nationale.

Quatrième pilier, un corpus d'incidents M365 anonymisés couvrant Business Email Compromise, exfiltration via OneDrive, élévation OAuth, abus PowerShell Graph, prise de contrôle d'Entra Connect Sync. Cette couche apporte un ancrage opérationnel au modèle.

Le fine-tuning combine SFT et DPO avec une évaluation interne sur 200 questions auditées par trois experts Microsoft 365. Le modèle atteint 84 pour cent de réponses correctes ou utiles, contre 65 pour cent pour un modèle généraliste 7B francophone.

Cas d'usage concrets

Un MSSP utilise M365-Expert pour pré-instruire les rapports d'audit M365 livrés à ses clients. Le consultant collecte la configuration via un script PowerShell générique, transmet la sortie au modèle accompagné d'une question structurée et obtient une analyse priorisée par criticité. Le rapport final est révisé manuellement.

Une ETI met le modèle à disposition de ses administrateurs M365 internes via un chatbot Slack ou Teams self-hosted. Les administrateurs posent leurs questions techniques sans devoir attendre la disponibilité de l'expert interne. Le ticket arrive enrichi de premières pistes lorsqu'il monte au niveau 2.

Un RSSI prépare un plan Zero Trust pour son tenant. Le modèle propose une feuille de route articulée autour de quatre vagues : identité Conditional Access et PIM, devices Intune Compliance et Defender for Endpoint, applications OAuth governance et Defender for Cloud Apps, données Purview classification, DLP et chiffrement.

Une équipe SOC investigue un incident BEC. Le modèle aide à reconstituer la chronologie en lisant les journaux Unified Audit Log filtrés, suggère les requêtes KQL pour Sentinel et propose des règles Conditional Access ajustées pour bloquer la récidive.

Un développeur Power Platform vérifie la sécurité d'une application Power Apps avant déploiement. Le modèle relit les permissions des connecteurs, signale les risques de partage trop large et propose des bonnes pratiques DLP Power Platform.

Installation rapide

Le modèle est livré aux formats SafeTensors et GGUF. Un wrapper PowerShell d'aide est fourni pour faciliter l'usage par les administrateurs Windows.

ollama pull m365-expert:q4\nollama run m365-expert:q4 "Genere une politique Conditional Access pour bloquer logins non MFA hors France."\n\n# Couplage avec extraction PowerShell\nConnect-MgGraph -Scopes "Policy.Read.All","Directory.Read.All"\nGet-MgIdentityConditionalAccessPolicy | Out-File ca.json\n# Puis pousser ca.json en contexte du modele pour analyse\n

Pour les organisations qui veulent un assistant intégré, une recette LangChain est fournie : elle combine M365-Expert avec un connecteur Microsoft Graph pour lire à la demande les configurations en lecture seule et produire des recommandations contextualisées sur le tenant réel. L'accès Graph doit rester en lecture seule et limité aux scopes minimaux.

Articulation avec Microsoft Graph et automatisation

Le modèle est conçu pour s'articuler avec une couche d'extraction Microsoft Graph qui collecte la configuration réelle du tenant en lecture seule. Cette articulation permet d'aller au-delà des recommandations génériques : l'analyste fournit en contexte le JSON résultant de l'extraction Graph et le modèle produit un diagnostic adapté à la configuration effective. Les scripts d'extraction PowerShell sont documentés dans le dépôt. Ils couvrent les politiques Conditional Access, les paramètres Defender for Office 365, les règles Exchange Online, les paramètres SharePoint et OneDrive, les autorisations Power Platform, les paramètres Intune Compliance et l'inventaire des applications avec leurs permissions OAuth.

Pour les organisations matures, une boucle d'automatisation hebdomadaire est envisageable : un job planifié extrait la configuration, la soumet au modèle, génère un rapport de drift par rapport à la baseline souhaitée et alerte le RSSI sur les écarts critiques. Cette approche industrialise le monitoring de configuration sans dépendance à un produit commercial dédié de type Microsoft Secure Score Premium.

Couverture des contrôles CIS Microsoft 365

Le modèle couvre les sept sections principales du benchmark : Account et Authentication Policies, Application Permissions, Data Management, Email Security et Exchange Online, Auditing Policies, Storage Policies, Mobile Device Management. Chaque contrôle est associé à sa commande de vérification PowerShell ou Graph, à sa procédure portail, à son score CIS niveau et à un commentaire de mise en œuvre.

Les contrôles les plus fréquemment manqués lors d'audits sont identifiés et expliqués en priorité : désactivation de l'authentification basique Exchange, application stricte de Conditional Access aux comptes Service principaux, restriction des consentements utilisateurs OAuth, configuration anti-phishing Defender, rétention Purview adaptée au secteur. Le modèle propose des plans d'action concrets pour chacun.

Templates Conditional Access et stratégies Defender

La bibliothèque de prompts livrée avec le modèle inclut une vingtaine de patrons Conditional Access prêts à adapter : blocage des connexions hors pays autorisés, exigence MFA pour les rôles privilégiés, restriction du téléchargement depuis OneDrive sur appareil non conforme, exigence d'appareil hybride joint pour les applications sensibles, blocage des protocoles d'authentification hérités, exigence de session courte pour les administrateurs. Chaque patron est documenté avec les utilisateurs ciblés, les conditions, les contrôles d'octroi et les pièges de mise en œuvre.

Côté Defender for Office 365, le modèle propose des configurations baseline pour les politiques anti-phishing, anti-spam, anti-malware, Safe Links et Safe Attachments. Pour Defender for Cloud Apps, il aide à structurer la session policy pour les applications SaaS critiques. Pour Purview, il oriente vers les labels de sensibilité et les politiques DLP adaptées aux secteurs régulés santé, finance, juridique. L'objectif est de fournir une base solide que l'organisation affine ensuite selon son contexte, plutôt que de partir de la page blanche que présente la console à l'ouverture.

Limites et garde-fous

M365-Expert n'est pas un produit Microsoft. Il n'a pas d'accès aux préversions privées ni aux roadmaps internes. Les recommandations qu'il fournit s'appuient sur la documentation publique disponible à la date de coupure du corpus. Les évolutions très récentes des produits, en particulier dans Defender et Copilot for Security, peuvent ne pas être reflétées. L'utilisateur est invité à recouper systématiquement avec la documentation officielle pour les décisions critiques.

Le modèle a été aligné pour refuser de produire des scripts offensifs ou des techniques d'abus contre des tenants tiers. Il assiste la défense uniquement. Les organisations qui pratiquent du red team M365 dans un cadre contractuel maîtrisé utiliseront d'autres outils dédiés.

Roadmap

Quatre axes pour la suite. Premier axe, intégration native des contrôles Copilot for Microsoft 365 et de leurs implications data governance. Deuxième axe, extension à Azure Workloads pour les organisations qui hébergent aussi des services Azure au-delà de M365. Troisième axe, support du benchmark CIS Azure et de la matrice de correspondance avec NIS 2. Quatrième axe, intégration plus fine avec Sentinel pour faciliter les rotations entre conseil de configuration et analyse d'incident.

FAQ

Le modèle a-t-il un accès direct à mon tenant ?

Non par défaut. Le modèle traite uniquement les données que vous lui fournissez en prompt. Si vous configurez le wrapper LangChain Graph, l'accès passe par votre propre application enregistrée et reste totalement sous votre contrôle.

Quelle est la version du CIS Benchmark utilisée ?

Le corpus s'appuie sur la version la plus récente publiée par le CIS au moment de la coupure du dataset. La version exacte est précisée dans la model card. Le modèle sait néanmoins répondre sur les versions antérieures quand l'utilisateur le précise.

Le modèle peut-il auditer Defender for Endpoint ou Defender for Cloud ?

Defender for Endpoint et Defender for Office 365 sont couverts. Defender for Cloud, qui concerne Azure plus largement, est partiellement couvert et fait partie de la roadmap. Les utilisateurs Azure intensifs sont invités à coupler M365-Expert avec un outil dédié Azure.

Le modèle peut-il aider à investiguer un BEC ?

Oui. Le modèle propose les requêtes Unified Audit Log et KQL Sentinel pertinentes, aide à reconstituer la timeline et suggère les actions de containment et de remediation. L'investigation finale doit rester pilotée par l'équipe SOC, surtout si l'incident a un impact business significatif.

Pour aller plus loin

La fiche modèle complète, les exemples et la model card sont accessibles via le portfolio /huggingface du compte Ayi Nedjimi. Pour approfondir Microsoft 365, consultez le guide d'audit de sécurité Microsoft 365, l'article pratiques de sécurité Microsoft 365 2025, l'analyse détection d'attaques Microsoft 365 et Azure AD et l'étude implémentation Zero Trust Microsoft 365.