Microsoft a introduit un ensemble de nouveautés dans Microsoft Defender for Cloud (anciennement Azure Defender ou Azure Security Center). Comme pour les autres services, je vous propose un résumé des changements et fonctionnalités que Microsoft a pu introduire dans le mois.

• (Preview) L’analyse de malware à la demande prend désormais en charge des blobs, fichiers, conteneurs et partages de fichiers spécifiques dans Defender for Storage. Plutôt que d’analyser un compte de stockage entier, vous pouvez cibler un blob ou un fichier précis, un conteneur ou un partage donné, ou tous les objets correspondant à un préfixe de chemin, via des filtres dans le corps de la requête REST. Sans filtre, l’analyse couvre l’ensemble du compte de stockage.
• Changement important (CIEM) : les actions inutilisées ne sont plus prises en compte dans les évaluations d’identités surprovisionnées AWS et GCP. La liste « Unused actions » disparaît des recommandations d’identités surprovisionnées pour AWS et GCP, et les processus qui s’appuyaient dessus ne sont plus disponibles. Pour vérifier l’usage des permissions, utilisez les outils natifs des fournisseurs : AWS IAM (activité et informations de dernier accès) ou Google Cloud IAM et Cloud Asset Inventory.
• À venir : le retrait des API classiques de Defender for SQL (Vulnerability Assessment et Advanced Threat Protection) est programmée au 16 août 2027. Si vous utilisez ces API, migrez vers le modèle de configuration pris en charge et mettez à jour vos scripts ou automatisations dépendants avant cette date.
• Mise à jour de la consommation des détails de CVE dans Azure Resource Graph : les informations de CVE restent disponibles, mais leurs propriétés détaillées sont désormais exposées via le type de ressource microsoft.security/cvedetails, afin d’améliorer les performances des requêtes, la scalabilité et la prise en charge de volumes de données plus importants. Les requêtes API ou Azure Resource Graph qui lisaient les détails de CVE depuis les enregistrements d’évaluation des vulnérabilités doivent être mises à jour, faute de quoi elles risquent de ne plus retourner les propriétés attendues.

Plus d’informations sur : Release notes for Microsoft Defender for Cloud | Microsoft Docs

Microsoft a introduit un ensemble de nouveautés dans Microsoft Defender for Cloud Apps (anciennement MCAS). Comme pour les autres services, je vous propose un résumé des changements et fonctionnalités que Microsoft a pu introduire dans le mois.

Ce mois, on retrouve les changements suivants :

• RBAC unifié est activé par défaut pour les nouveaux clients Defender for Cloud Apps. Depuis août 2026, le contrôle d'accès basé sur les rôles unifié (unified RBAC) de Microsoft Defender est automatiquement activé pour les nouveaux clients Defender for Cloud Apps. Aucune activation manuelle de la charge de travail n'est nécessaire. Le RBAC unifié offre une expérience centralisée pour gérer les rôles et les autorisations à travers les produits Microsoft Defender. 

Plus d'informations sur : What's new in Microsoft Defender for Cloud Apps | Microsoft Docs 

Microsoft Defender for Identity étant un service Cloud, on retrouve des mises à jour de service continuelle. Comme pour les autres services, je vous propose un résumé des changements et fonctionnalités que Microsoft a pu introduire dans le mois.

• L’audit automatique des événements Windows configure désormais l’audit pour les serveurs AD FS, AD CS et Microsoft Entra Connect. L’audit est configuré automatiquement sur tout serveur éligible exécutant le capteur Defender for Identity v3.x, y compris les serveurs qui ne sont pas des contrôleurs de domaine. 

Plus d’informations sur: What's new in Microsoft Defender for Identity

Microsoft fait évoluer deux de ses certifications développeur pour refléter la place croissante de l'IA et des agents dans les métiers concernés. Deux mouvements distincts sont annoncés, avec des échéances rapprochées qu'il convient d'anticiper si vous êtes en cours de préparation.

Le premier concerne la certification Microsoft Certified: Azure Cosmos DB Developer Specialty, qui change à la fois de nom et de niveau pour devenir Microsoft Certified: Azure Cosmos DB AI Developer Associate. Ce changement prend effet le 6 octobre 2026, date à laquelle la version anglaise de la certification sera également mise à jour. Microsoft justifie cette évolution par la transformation du rôle de développeur Azure Cosmos DB, désormais fortement orienté vers les scénarios d'IA. Bonne nouvelle : aucune action n'est requise de votre part si vous détenez déjà cette certification.

Le second mouvement touche l'examen PL-400 (Microsoft Power Platform Developer), qui devient AB-400. Il s'agit d'un alignement sur la nouvelle nomenclature du portefeuille de certifications Microsoft, qui réorganise les codes d'examen par domaine — le préfixe AB étant dédié aux Business Applications et aux agents. L'examen AB-400 sera disponible à partir du 16 octobre 2026, et les inscriptions sont d'ores et déjà ouvertes. De son côté, la PL-400 reste passable jusqu'au 30 octobre 2026 : si vous êtes déjà inscrit, vous pouvez conserver votre inscription et passer l'examen avant cette échéance.

Point important : la certification obtenue reste strictement la même, à savoir Microsoft Certified: Power Platform Developer Associate. Il n'y a ni nouveau titre ni nouvelle catégorie — c'est bien le contenu de l'examen qui évolue. Et il évolue substantiellement, la PL-400 n'ayant pas été mis à jour depuis le 19 septembre 2023. Le plan de compétences passe de six à quatre domaines : les trois thématiques que sont la configuration de Dataverse, la création de Power Apps et la conception technique fusionnent au sein d'un bloc unique « Build Microsoft Power Platform Solutions ». Le développement personnalisé : composants PCF, scripting, personnalisation de la barre de commandes, prend une part bien plus importante, de l'ordre du quart au tiers de l'examen, tandis que la partie server-side (plugins, Web API, custom APIs) reste inchangée.

Les nouveaux sujets à intégrer à votre préparation sont sans surprise centrés sur l'IA et l'outillage moderne : Copilot Studio, Microsoft Foundry, les agents et le rôle de l'IA agentique dans la conception de solutions, les code apps Power Apps, MCP, ainsi que Power Fx, YAML, Python et la Power Platform CLI. À noter également : l'AB-400 est lancé en anglais uniquement, là où la PL-400 était disponible en espagnol et dans d'autres langues, un critère à prendre en compte selon vos équipes.

Concrètement, si votre préparation est bien avancée et que vous visiez un passage en octobre, la PL-400 reste une option valable jusqu'au 30 octobre. Si vous démarrez tout juste, il est plus pertinent de vous orienter directement sur le plan de compétences de l'AB-400. Et si vous détenez déjà la certification, rien ne change : elle se renouvelle toujours annuellement via l'évaluation en ligne gratuite.

Ce mouvement s'inscrit dans une refonte plus large du portefeuille de certifications Microsoft, où l'IA devient le fil conducteur, la PL-200 ayant déjà été remplacé par l'AB-410, tandis que les PL-500 et PL-600 ont été retirés sans remplacement. Les certifications Power Platform conservent tout leur intérêt, mais il faut désormais accepter que l'IA y occupe une place déterminante.

Plus d'informations sur : Updates to Azure Cosmos DB and Power Platform Developer Certifications

Frost & Sullivan vient de publier le résultat de l’étude 2026 sur les Cloud Workload Protection Platforms (CWPP). Microsoft est positionné parmi les Visionary Leaders, aux côtés notamment de CrowdStrike, Palo Alto Networks, Wiz, SentinelOne et Fortinet. Microsoft obtient notamment l'un des meilleurs scores sur l'axe Growth et Frost & Sullivan estime que Microsoft est aujourd'hui le premier fournisseur mondial de CWPP en chiffre d'affaires, avec une part de marché mondiale estimée à plus de 21,8 %. Le marché du CWPP continue par ailleurs de progresser rapidement avec un chiffre d'affaires mondial estimé par Frost & Sullivan à 6,43 milliards de dollars en 2025 et près de 7,95 milliards en 2026, avec une croissance annuelle moyenne attendue de 19,1 % jusqu'en 2030. Cette croissance est notamment portée par l'adoption du Cloud, des conteneurs, de Kubernetes et désormais des workloads IA.

Pour Microsoft, la solution CWPP est intégrée à Microsoft Defender for Cloud, sa plateforme CNAPP qui combine notamment CWPP, CSPM, sécurité IaC et DevOps, CIEM et protection des environnements IA dans une approche Cloud hybride et multicloud.

Parmi les forces :

• Couverture étendue : Frost & Sullivan met en avant la couverture de Microsoft Defender for Cloud sur les infrastructures, workloads, identités, permissions, données et applications. La solution couvre Azure, AWS, GCP et les environnements hybrides avec une combinaison d'approches avec et sans agent.
• Protection Runtime : Microsoft a considérablement renforcé la protection des conteneurs et environnements Kubernetes. Defender for Containers utilise notamment un capteur basé sur eBPF permettant de collecter les événements Kubernetes ainsi que la télémétrie liée aux processus et au réseau pour détecter les menaces pendant l'exécution.
• Protection Kubernetes : Microsoft propose notamment la détection DNS pour Kubernetes sur AKS, Amazon EKS et Google GKE, la détection et le blocage antimalware des conteneurs, la protection Runtime d'EKS Bottlerocket ainsi que la détection et le blocage du Binary Drift.
• Prévention avant la mise en production : le mécanisme de Kubernetes Gating permet d'appliquer des stratégies au niveau du cluster ou du namespace afin de bloquer une image risquée ou non conforme avant son exécution en production. Frost & Sullivan considère cette approche comme particulièrement pertinente pour les scénarios CWPP.
• Intégration avec le SOC : les informations issues de la Runtime Protection, des audits Kubernetes, de l'activité des processus et du réseau, du Control Plane Cloud et des identités peuvent être corrélées puis transmises à Microsoft Defender XDR et Microsoft Sentinel pour les opérations de détection et de réponse.
• Intégration DevSecOps : Defender for Cloud relie les informations issues du Runtime, l'exploitabilité des vulnérabilités et l'analyse des chemins d'attaque aux workflows des développeurs via GitHub Advanced Security et Copilot Autofix. Ceci permet notamment de faire remonter un problème découvert en production vers le développeur responsable du code concerné.
• Sécurité des workloads IA : Microsoft étend les capacités de Defender for Cloud avec l'analyse des modèles et la Runtime Threat Protection pour Azure AI Foundry et Azure OpenAI, notamment face aux attaques par Prompt Injection ou aux accès suspects. Des fonctions d'AI Security Posture Management sont également proposées pour Google Vertex AI et Amazon Bedrock.
• Intégration avec l'écosystème Microsoft : Frost & Sullivan considère l'intégration avec Defender XDR, Microsoft Sentinel, GitHub et Security Copilot comme l'un des principaux avantages de Microsoft, particulièrement dans les grandes entreprises utilisant déjà Azure et les solutions de sécurité Microsoft.

Parmi les faiblesses :

• Application Runtime Security : Frost & Sullivan considère que Microsoft doit continuer à étendre ses capacités de sécurité au niveau du Runtime applicatif afin de renforcer davantage son positionnement en matière d'innovation.
• Analyse Runtime des APIs : Microsoft doit approfondir ses capacités d'analyse du comportement des APIs en cours d'exécution afin de compléter la couverture apportée par la protection actuelle des workloads.
• Application Behavior Baselining : Frost & Sullivan identifie l'établissement de profils de comportement des applications comme un autre axe d'amélioration permettant à Microsoft d'approfondir son approche Runtime Security.
• Exploit-to-Code Mapping : Microsoft peut encore améliorer la capacité à relier directement l'exploitation d'une vulnérabilité observée au Runtime avec le code à son origine.
• Corrélation des signaux : Frost & Sullivan recommande de continuer à enrichir la corrélation entre le comportement des workloads, l'utilisation des identités, l'activité applicative et les mouvements de données sensibles.
• Positionnement hors Azure : malgré les investissements réalisés pour AWS et GCP, Frost & Sullivan recommande à Microsoft de mieux mettre en avant la valeur de Defender for Cloud dans les scénarios multicloud et de poursuivre son développement auprès des PME et des entreprises dont l'infrastructure n'est pas principalement basée sur Azure.

Le rapport souligne plus globalement une évolution importante du marché : le CWPP ne se limite plus à l'analyse des vulnérabilités et au durcissement des workloads. Les entreprises recherchent désormais une plateforme capable de déterminer si une vulnérabilité est réellement accessible ou exploitable, de détecter les attaques en cours d'exécution et de corréler les informations provenant des workloads avec celles liées aux identités, aux données et au Cloud Control Plane.

Cette évolution explique également la convergence progressive entre CWPP, CNAPP, Cloud Detection and Response (CDR) et XDR, avec une intégration toujours plus importante des opérations de Cloud Security au niveau du SOC. La sécurité des workloads IA devient également un nouveau facteur de différenciation entre les différents acteurs du marché.

Vous pouvez accéder au rapport Frost & Sullivan.

Source : Microsoft named a Leader in the Frost Radar: Cloud Workload Protection Platforms, 2026 | Microsoft Security Blog  

Gartner vient de publier le résultat de l’étude 2026 sur les Cloud-Native Application Platforms. Microsoft fait une nouvelle fois partie des leaders. C'est la troisième année consécutive que Microsoft est positionné comme Leader dans ce Magic Quadrant. La plateforme Cloud-Native de Microsoft s'appuie notamment sur Azure App Service, Azure Container Apps, Azure Functions et Azure API Management, auxquels viennent s'ajouter Microsoft Foundry et GitHub Copilot pour répondre aux nouveaux usages autour de l'IA et des agents. L'ensemble repose sur les services Azure communs d'identité, réseau, observabilité et sécurité. L'un des axes importants de la stratégie de Microsoft consiste justement à rapprocher modernisation applicative et IA, afin de permettre aux entreprises de faire évoluer leurs applications existantes tout en développant de nouvelles applications Cloud-Native et agentiques sur une plateforme commune.

Parmi les forces :

• Plateforme intégrée : Microsoft propose une plateforme couvrant différents modèles applicatifs avec Azure App Service pour les applications Web d'entreprise et leur modernisation, Azure Container Apps pour les applications conteneurisées et les agents, Azure Functions pour les architectures événementielles et Azure API Management pour la gestion et la gouvernance des APIs.
• Intégration de l'IA : Microsoft rapproche ses services applicatifs de Microsoft Foundry afin de permettre aux développeurs de construire des applications et des agents en utilisant différents modèles et frameworks, avec des fonctions d'évaluation, de tracing et de sécurité nécessaire à leur mise en production.
• Modernisation des applications : Microsoft permet aux entreprises de moderniser progressivement leur patrimoine existant. Les applications peuvent être migrées vers des services PaaS, conteneurisées ou évoluer progressivement vers des architectures événementielles. App Service Managed Instance vise notamment les applications Windows et .NET complexes sans imposer leur réécriture complète, tandis que GitHub Copilot peut accompagner les opérations d'évaluation et de remédiation.
• Développement d'applications agentiques : Azure Container Apps permet d'exécuter des applications Cloud-Native, des APIs, de l'inférence IA et des agents sans demander aux équipes de gérer directement l'infrastructure sous-jacente. Azure Container Apps Sandboxes permet en outre d'isoler l'exécution des agents, de leurs outils, des serveurs MCP et du code généré au sein de microVMs.
• Intégration et APIs : Azure API Management étend la gouvernance aux APIs, serveurs MCP et endpoints de modèles. Les fonctions d'AI Gateway permettent notamment de gérer l'authentification, les quotas et limites de tokens, la répartition de trafic entre modèles, le cache sémantique et le suivi de la consommation des services IA. Microsoft met aussi en avant plus de 1 400 connecteurs permettant aux agents d'interagir avec les systèmes d'entreprise.
• Sécurité et gouvernance : la plateforme s'appuie sur les services communs Azure en matière d'identité, de réseau, de sécurité et de stratégies. Ceci devient particulièrement important avec les agents qui peuvent appeler des APIs, exécuter du code généré ou accéder à des systèmes contenant des données sensibles.
• Observabilité et opérations : Azure Monitor et Application Insights fournissent une visibilité de bout en bout sur les applications et les workloads IA. Microsoft introduit également une approche d'opérations agentiques avec Azure SRE Agent, capable d'aider les équipes à investiguer les incidents, identifier leurs causes et réaliser des actions de remédiation auditables.

Parmi les faiblesses :

• Étendue de la plateforme : l'offre Microsoft couvre de nombreux modèles avec App Service, Container Apps, Functions, API Management, Microsoft Foundry ainsi que différents services de sécurité, d'identité et d'observabilité. Cette richesse nécessite de bien définir les architectures et services adaptés aux différents workloads.
• Complexité des nouveaux workloads IA : les applications agentiques introduisent de nouvelles problématiques puisque les agents peuvent appeler des APIs, exécuter du code généré et interagir avec des systèmes sensibles à une vitesse et un volume plus important que les applications traditionnelles. Ceci impose d'intégrer directement la sécurité, la gouvernance et l'observabilité dans l'architecture de la plateforme.
• Modernisation progressive : les entreprises disposent rarement d'un patrimoine applicatif homogène. Le passage vers des architectures Cloud-Native doit donc pouvoir combiner PaaS, conteneurs, architectures événementielles et applications historiques, ce qui peut nécessiter plusieurs stratégies de modernisation au sein d'une même organisation.

Microsoft met également en avant plusieurs références clients. Planet DDS a par exemple modernisé sa plateforme avec Azure App Service et réduit son temps de provisionnement de six semaines à une journée. Commerzbank utilise Azure Container Apps pour son architecture d'IA agentique avec son assistant Ava qui traite plus de 30 000 conversations clients par mois et en résout 75 % de façon autonome. Microsoft cite également Ghassan Aboud Group et Levi Strauss & Co. pour leurs usages de l'IA et des agents sur Azure.

Vous pouvez accéder au rapport Gartner.

Source : Microsoft named a Leader in the 2026 Gartner® Magic Quadrant for Cloud-Native Application Platforms

Gartner vient de publier le résultat de l’étude 2026 sur le Container Management. Microsoft fait partie des Leaders et se positionne le plus à droite sur l’axe Completeness of Vision.  Cette reconnaissance s’appuie notamment sur la stratégie de Microsoft autour de Azure Kubernetes Service (AKS), Azure Container Apps, Azure Arc et Azure Kubernetes Fleet Manager, avec l’objectif d'offrir une plateforme cohérente pour exécuter et administrer les workloads conteneurisés dans le cloud, en environnement hybride et en périphérie (Edge).

L'évolution des usages autour de l'IA joue également un rôle important dans cette stratégie. Microsoft met notamment en avant la capacité de Kubernetes et de ses services Azure à prendre en charge des workloads IA, depuis les infrastructures persistantes utilisant des GPU jusqu'aux scénarios d'inférence à la demande et d'agents nécessitant davantage d'élasticité et d'isolation.

Parmi les forces :

• Vision et stratégie : Microsoft est positionné le plus à droite sur l'axe Completeness of Vision. Sa stratégie repose sur un modèle permettant de gérer les applications conteneurisées depuis le cloud jusqu'au Edge et aux environnements hybrides, avec Azure Kubernetes Service (AKS), Azure Container Apps, Azure Arc et Azure Kubernetes Fleet Manager.
• Intégration de l'IA : Microsoft adapte sa plateforme de conteneurs aux nouveaux besoins liés aux workloads IA avec notamment le support des GPU et de l'inférence sur AKS, ainsi que les Serverless GPUs et les environnements isolés proposés avec Azure Container Apps.
• Cloud hybride et multicloud : avec Azure Arc-enabled Kubernetes, Microsoft propose un modèle commun d'identité, de stratégie et d'observabilité pour des environnements Kubernetes conformes CNCF, y compris en dehors d'Azure. [
• Gestion à grande échelle : Azure Kubernetes Fleet Manager permet d'adresser les problématiques liées à la multiplication des clusters en facilitant notamment la gestion des mises à jour, le placement des workloads et l'application cohérente des stratégies sur plusieurs clusters.
• Open Source : Microsoft continue de s'appuyer sur Kubernetes sans utiliser de fork propriétaire. Microsoft indique également être le deuxième plus important contributeur aux projets CNCF et le premier parmi les fournisseurs Cloud sur les trois dernières années.
• Automatisation des opérations : Microsoft investit dans l'automatisation avec AKS Automatic, mais aussi dans les opérations agentiques avec Azure SRE Agent et AKS MCP Server, afin d'accompagner les équipes depuis l'alerte jusqu'au diagnostic et à la remédiation.

Parmi les faiblesses :

• Complexité de la plateforme : l'étendue du portefeuille Microsoft, allant de Kubernetes aux services Serverless et aux environnements hybrides et Edge, implique une surface fonctionnelle importante et nécessite des compétences pour sélectionner, architecturer et exploiter les différents services. Microsoft reconnaît d'ailleurs que l'élargissement des capacités de la plateforme augmente sa surface et nécessite davantage de discernement de la part des équipes qui l'exploitent.
• Gestion des environnements distribués : la multiplication des clusters dans différentes régions, Datacenters ou environnements Edge peut entraîner des problématiques de dérive de configuration, de déploiement non homogène des mises à jour et d'application incohérente des stratégies. Microsoft adresse notamment ces problématiques avec Azure Kubernetes Fleet Manager et Azure Arc.
• Évolution rapide des besoins liés à l'IA : l'intégration de workloads IA, des GPU et des architectures agentiques fait évoluer rapidement les besoins associés aux plateformes de conteneurs. Microsoft indique lui-même que le travail visant à absorber cette complexité au niveau de la plateforme reste en cours.

Microsoft illustre également sa stratégie par plusieurs références clients utilisant ses technologies de conteneurs pour des scénarios très différents : Wayve pour l'entraînement de modèles utilisant des milliers de GPU, AT&T pour l'orchestration d'agents avec AKS, Replit avec Azure Container Apps, SimCorp pour des workloads réglementés ou encore Emirates Global Aluminium pour des environnements hybrides Azure et On-Premises.

Vous pouvez accéder au rapport Gartner.

Source : Microsoft named a Leader in the 2026 Gartner® Magic Quadrant for Container Management | Microsoft Azure Blog

Deux bonnes nouvelles coup sur coup pour les administrateurs Purview : Microsoft supprime l'exigence de facturation pay-as-you-go (PAYG) sur deux scénarios de protection en ligne qui, jusqu'ici, imposaient de rattacher un abonnement Azure et de surveiller un compteur de consommation.

Le premier concerne la Browser Data Security (Browser DLP) pour les applications non managées. Comme le détaille le message MC1470881, à partir de la mi-octobre 2026, Microsoft Purview retire l'exigence de facturation pay-as-you-go pour les stratégies de collecte inline et les stratégies DLP qui protègent les interactions supportées avec les applications cloud non managées dans Microsoft Edge for Business. Le déploiement mondial débute à la mi-octobre 2026 et devrait s'achever fin octobre 2026, de manière progressive : tant que le changement n'a pas atteint votre tenant, l'exigence PAYG peut continuer d'apparaître dans le portail Microsoft Purview et dans les cmdlets de stratégie. Ce changement revient sur l'exigence de facturation précédemment annoncée dans MC1154787.

Concrètement, la capacité est désormais entièrement incluse dans les licences E5 et supérieures, sans compteur à surveiller. Vos stratégies de collecte et DLP existantes pour les applications non managées dans Edge continueront de fonctionner sans modification : aucune migration, recréation ou mise à jour n'est nécessaire, et le comportement d'application des stratégies reste inchangé. Après le déploiement, l'abonnement Azure et la configuration de facturation pay-as-you-go ne seront plus requis pour ce scénario Edge for Business, les vérifications de prérequis de facturation disparaîtront du portail Purview et des cmdlets, et les requêtes associées ne généreront plus de coûts via le compteur In Transit Protection. Attention toutefois : ce changement n'étend en rien le périmètre des applications, navigateurs, activités, licences, appareils ou environnements cloud supportés.

Le second changement concerne la Network Data Security. Celle-ci ne nécessitera plus de compteur dès lors que vous utilisez Entra Global Secure Access (GSA) comme solution SASE : vos licences E5 et Entra GSA suffiront. En revanche, pour ceux qui s'appuient sur des solutions SASE tierces intégrées, le compteur PAYG restera d'actualité.

Aucune action n'est requise de votre part pour bénéficier de ces évolutions. Pour les organisations qui repoussaient le déploiement du DLP navigateur ou de la Network Data Security en raison de la complexité liée au rattachement d'un abonnement Azure et à l'imprévisibilité du modèle à la consommation, c'est un frein significatif qui tombe. Je vous invite à revoir vos scénarios de protection inline mis de côté pour ces raisons budgétaires : le calcul de rentabilité change sensiblement.

Sources : MC1470881 - Microsoft Purview: Removing pay-as-you-go requirements for Edge for Business DLP unmanaged app protections | Microsoft 365 Message Center Archive

Comme précédemment communiqué par Microsoft, le support d'Office LTSC 2021 prendra fin le 13 octobre 2026. Passée cette date, plus aucune mise à jour, correctif de sécurité ou assistance technique ne sera disponible pour cette version d'Office. Les applications continueront certes de fonctionner, mais l'utilisation d'un logiciel non supporté expose l'organisation à des risques de sécurité et de conformité, à des incompatibilités système et à divers autres problèmes.

Le support de Visio LTSC 2021, Microsoft Project LTSC 2021 et de plusieurs autres produits prendra également fin le 13 octobre 2026. Les organisations concernées doivent envisager une montée de version dès que possible afin de préserver leur niveau de sécurité, de conformité et de performance. Le déploiement de cette échéance interviendra à la mi-octobre 2026.

Concrètement, après la fin du support, les suites et applications autonomes Office LTSC 2021 ne recevront plus de mises à jour de sécurité ni de correctifs, et aucune assistance technique ne sera proposée pour les appareils qui les exécutent encore. Poursuivre l'usage d'un logiciel non supporté peut exposer votre organisation à des risques de sécurité et de conformité, et peut affecter la fiabilité et les performances du service.

Pour limiter ces risques tout en conservant l'accès aux applications Office de bureau, Microsoft recommande de faire évoluer les postes vers une suite Microsoft 365 ou Office 365 incluant Microsoft 365 Apps (for enterprise ou for business). Microsoft 365 Apps fournit des versions toujours à jour des applications familières comme Word, Excel et PowerPoint, sur poste de travail, mobile et web, avec un support continu sous la Modern Lifecycle Policy, et est éligible à l'add-on Microsoft 365 Copilot. En pratique :

• Les entreprises s'orienteront vers Microsoft 365 E3, Office 365 E3 ou Microsoft 365 Apps for enterprise.
• Les organisations de moins de 300 utilisateurs s'orienteront vers Microsoft 365 Business Premium, Microsoft 365 Business Standard ou Microsoft 365 Apps for business.

Pour les scénarios nécessitant une solution totalement déconnectée, la recommandation est de migrer vers Office LTSC 2024. Il s'agit de la version on-premises d'Office actuellement supportée par Microsoft pour les clients commerciaux, prise en charge jusqu'en octobre 2029 sous la Fixed Lifecycle Policy.

Pour préparer cette transition, je vous invite à consulter le guide de montée de version qui présente la démarche pour passer d'Office LTSC 2021 à Microsoft 365 Apps.

MC1472429

Microsoft introduit un nouveau contrôle d'administration permettant de déterminer qui peut uploader des agents et plugins avancés dans Microsoft 365 Copilot. L'objectif est d'aider les organisations à maîtriser le déploiement des scénarios d'extensibilité avancés de Copilot, en renforçant la gouvernance et la manageabilité à l'échelle de l'entreprise. Concrètement, les administrateurs pourront restreindre l'upload de packages avancés à des utilisateurs ou à des groupes Microsoft Entra ID spécifiques, tout en conservant la souplesse nécessaire aux organisations qui souhaitent laisser un accès plus large.

Le déploiement en disponibilité générale débute le 25 septembre 2026 et devrait s'achever d'ici la fin du mois d'octobre 2026. Sont concernés les administrateurs Microsoft 365 responsables de la gestion des agents et plugins Copilot, les organisations qui autorisent leurs utilisateurs à uploader des agents ou plugins avancés, ainsi que les utilisateurs qui créent ou uploadent ce type de packages une fois la fonctionnalité disponible. Côté périmètre, le changement touche Microsoft 365 Copilot et Cowork, les agents et plugins Copilot, ainsi que Microsoft Entra ID.

Deux dates structurent la bascule. Le 25 septembre 2026, le contrôle devient visible dans le Microsoft Admin Center sous le paramètre Advanced package uploads. Les administrateurs disposent alors d'une fenêtre allant jusqu'au 25 octobre pour choisir leur préférence : tous les utilisateurs, aucun utilisateur, ou des utilisateurs et groupes spécifiques. À partir du 25 octobre 2026, l'upload de packages avancés sera activé par défaut, sauf si l'administrateur a explicitement sélectionné « aucun utilisateur » ou un périmètre restreint.

Quelques points méritent d'être précisés :

• L'upload peut être configuré pour tous les utilisateurs, des utilisateurs sélectionnés, des groupes Entra ID, ou aucun utilisateur.
• Les uploads de packages basiques restent autorisés et ne sont pas impactés.
• Le paramètre s'applique uniquement aux agents et plugins avancés uploadés après la mise à disposition du contrôle.
• Aucune action n'est requise pour conserver le comportement actuel : à défaut de configuration, l'upload demeure autorisé par défaut.

Je vous recommande donc de consulter le paramètre dès sa mise à disposition le 25 septembre, de trancher avant le 25 octobre sur le périmètre à ouvrir, puis de mettre à jour votre documentation interne à destination des administrateurs et du help desk sans oublier d'informer les équipes de support de ce nouveau levier de gouvernance. Ce changement introduit de nouveaux contrôles de gouvernance administrative pour les agents et plugins avancés, avec une administration qui s'appuie sur l'appartenance à des groupes Microsoft Entra ID.

Dans une logique de moindre privilège, ne laissez pas passer la fenêtre du 25 septembre au 25 octobre : le réflexe consiste à restreindre d'emblée l'upload d'agents et plugins avancés à un groupe Entra ID dédié quitte à l'élargir ensuite plutôt que de subir l'activation par défaut sur l'ensemble du tenant.

MC1472007

Microsoft Defender XDR introduit une nouvelle règle de tuning d'alertes intégrée (built-in alert tuning rule) qui positionne les alertes Microsoft Purview Data Loss Prevention (DLP) en tant que behaviors (comportements). L'objectif est de réduire le volume d'alertes dans Microsoft Defender XDR, tout en préservant les données d'investigation DLP dans l'Advanced Hunting et dans le portail Microsoft Purview.

Les administrateurs qui préfèrent conserver le comportement actuel en faisant remonter les alertes DLP standard dans les files d'incidents de Defender XDR, peuvent désactiver la règle.

La règle de tuning d'alertes est disponible pour revue dès aujourd'hui dans Microsoft Defender XDR. Elle sera activée par défaut à compter du 12 octobre 2026.

Une fois la règle active :

• Les alertes DLP n'apparaîtront plus par défaut dans la file d'incidents de Microsoft Defender XDR.
• Les signaux DLP resteront disponibles pour investigation via les tables BehaviorInfo et BehaviorEntities de l'Advanced Hunting.
• Les alertes DLP restent disponibles dans le portail Microsoft Purview.
• Ce changement est piloté par la règle intégrée : Set-As-Behavior - Data Loss Prevention (DLP) Alerts.

À noter qu’aucune donnée n'est perdue. Il s'agit d'un changement de présentation. Les événements DLP sortent de la file d'incidents XDR mais restent pleinement exploitables en Advanced Hunting et côté Purview.

Aucune action n'est nécessaire si vous souhaitez adopter la nouvelle expérience par défaut.

En revanche, si votre organisation s'appuie sur la présence des alertes DLP dans la file d'incidents de Microsoft Defender XDR, désactivez la règle avant le 12 octobre 2026 pour conserver le comportement actuel. La règle peut également être désactivée à tout moment après son entrée en vigueur.

Voici les étapes pour continuer à recevoir les alertes DLP dans la file d'incidents de Microsoft Defender XDR :

1. Rendez-vous dans Settings > Microsoft Defender XDR > Alert tuning.
2. Localisez la règle Set-As-Behavior - Data Loss Prevention (DLP) Alerts.
3. Désactivez la règle.

Je vous partage un outil créé par Sebastian F. Markdanner (MVP) qui permet, via une interface web (portail hébergé ou auto-hébergeable), de découvrir, réviser et gérer les extensions personnalisées (custom extensions) de Microsoft Entra ID : Schema extensions, Directory extensions et Open extensions.

Travailler avec les extensions personnalisées peut vite devenir pénible, en particulier dans des environnements volumineux ou hérités, où l'on doit identifier quelles extensions existent, à quoi elles servent, où elles sont utilisées et comment elles sont configurées. Entra Extensions Manager répond précisément à ce besoin, sans avoir à écrire un script Graph ponctuel pour chaque tâche.

L'application permet pour l'instant :

• Inventorier dans une seule vue les schema extensions et directory extensions de l'environnement.
• Gérer les extensions (lecture, création, modification, suppression, assignation) pour les Schema, Directory et Open extensions, là où c'est pris en charge.
• Utiliser des outils dédiés : moniteur d'utilisation (Usage monitor), validation de valeur (Validate value), génération de snippet de manifeste et journal d'audit (Audit log).
• Travailler sur plusieurs tenants grâce à un tenant switcher, avec des fonctions de confort (raccourcis, commandes).  
• Basculer entre un mode lecture et un mode édition, et disposer d'un mode démo pour tester l'outil sans exposer les données de votre tenant. [

L'outil s'appuie sur des permissions Graph déléguées et peut être auto-hébergé (self-host) si vous préférez ne pas utiliser la version hébergée, via une inscription d'application Microsoft Entra dédiée.

Télécharger / accéder à Entra Extensions Manager

Source : Introducing Entra Extensions Manager: A Better Way to Manage Custom Extensions

Le 1er septembre 2026, Microsoft a annoncé la disponibilité générale (GA) d'Azure Virtual Desktop Hybrid. Il s'agit d'une extension significative de la plateforme AVD : au lieu d'exiger que les session hosts s'exécutent dans un datacenter Azure (ou sur Azure Local), les organisations peuvent désormais héberger leurs session hosts AVD sur leur propre infrastructure on-premises, tout en continuant à s'appuyer sur le service Azure Virtual Desktop dans le cloud.

Avec AVD Hybrid, le control plane reste dans Azure (brokering, workspaces, application groups, intégration d'identité Microsoft Entra), tandis que les bureaux et applications Windows s'exécutent dans votre propre datacenter. Le mécanisme repose sur Azure Arc :

• Vous déployez une machine virtuelle Windows (sur l'hyperviseur de votre choix) ou un serveur physique headless.
• Vous installez l'agent Azure Arc Connected Machine, qui enregistre la machine comme Arc-enabled server.
• Vous exécutez l'extension Azure Virtual Desktop Arc, qui installe les composants AVD et enregistre la machine comme session host dans un host pool.
• Les utilisateurs se connectent via Windows App, exactement comme pour n'importe quel session host AVD.

En résumé : Microsoft gère le service AVD ; vous gérez les session hosts, l'hyperviseur, le réseau et le stockage.  

Jusqu'ici, exécuter des session hosts AVD hors d'Azure imposait de passer par Azure Local (ex-Azure Stack HCI), avec du matériel certifié et une pile managée par Microsoft. AVD Hybrid supprime ces contraintes matérielles : vous pouvez utiliser l'hyperviseur qui supporte des VM Windows (Hyper-V, VMware vSphere, Nutanix AHV…) ou même un serveur physique bare-metal.

AVD n'est donc plus seulement une plateforme VDI cloud-native : elle devient aussi un plan de contrôle cloud-managed pour des bureaux et applications Windows exécutés sur une infrastructure de datacenter existante. [

Toutes les charges de travail n'ont pas vocation à migrer vers une région Azure. Les applications peuvent avoir des dépendances vis-à-vis de bases de données locales, de systèmes de production, d'équipements médicaux ou de gros volumes de données. AVD Hybrid permet de garder le bureau proche de ces systèmes tout en bénéficiant du workspace, du brokering et de l'expérience de gestion AVD.  

Autres bénéfices notables :

• Souveraineté et résidence des données : exécution locale des workloads tout en conservant le control plane Azure.
• Sécurité renforcée : plus de ports RDP exposés (connexions sortantes uniquement), authentification via Microsoft Entra ID avec Conditional Access et MFA, et passerelle managée par Microsoft (plus besoin de maintenir votre propre frontend).
• Valorisation de l'existant : réutilisation des investissements de virtualisation encore amortissables.  

Systèmes d'exploitation et licences

AVD Hybrid supporte les OS suivants, avec deux composantes de licence (droit utilisateur + licence de service AVD Hybrid) : [

️ Limitation importante : le multi-session (Windows 10/11 Enterprise Multi-Session) n'est pas pris en charge sur AVD Hybrid.

Points de vigilance

AVD Hybrid ne gère pas le cycle de vie ni l'état des machines : power management, autoscale, Start VM on Connect et Session Host Configuration ne sont pas supportés. Vous restez responsable du provisioning et du lifecycle de vos hosts (via vos outils d'hyperviseur, scripts, SCCM, ou des solutions partenaires comme Nerdio, Login VSI/Hydra, ControlUp, Nutanix).

Enfin, un élément technique est clé pour que l'architecture fonctionne correctement d'un point de vue réseau : RDP Shortpath, qui établit un chemin direct entre le client et le session host on-premises.

Source : Microsoft Azure Virtual Desktop Hybrid is now generally available

Microsoft a publié le 27 août 2026 la mise à jour annuelle de fonctionnalités Windows 11 version 26H2 (Build 26300.9278) dans le canal Release Preview du programme Windows Insider. Les ISO sont quant à elles disponibles depuis le 31 août 2026. Cette étape permet aux clients de tester la nouvelle version en avance de phase, avant sa disponibilité générale prévue plus tard dans l'année civile.

Comme pour la version 25H2, Windows 11 version 26H2 est livrée sous la forme d'un enablement package (eKB). Cela signifie que les versions 24H2, 25H2 et 26H2 partagent la même branche de servicing : elles reposent sur le même socle et bénéficient des mêmes nouvelles fonctionnalités et améliorations, diffusées au fil de l'eau via la démarche de continuous innovation de Microsoft.

Concrètement, beaucoup des nouveautés de la version 26H2 vous seront déjà familières, car elles ont été introduites progressivement via les mises à jour mensuelles. Le passage en 26H2 consiste alors essentiellement à activer ces fonctionnalités déjà présentes sur le poste.

Pour les clients commerciaux, la version 26H2 active plusieurs expériences introduites dans les versions précédentes mais qui n'étaient pas activées par défaut sur les appareils commerciaux, notamment :  

• La sauvegarde des paramètres Windows (Windows settings backup).
• Les actions spécifiques aux applications depuis la barre des tâches (app-specific actions from the taskbar).
• Certaines améliorations de l'Explorateur de fichiers.

Pour préparer votre organisation, Microsoft met à disposition le guide Get ready for Windows 11, version 26H2.  

Comment tester la version 26H2

• Insiders (canal Release Preview) : si vous êtes déjà inscrit au canal Release Preview sur un PC compatible avec les prérequis matériels de Windows 11, rendez-vous dans Paramètres > Windows Update et choisissez de télécharger et installer Windows 11 version 26H2 (expérience « seeker »). Une fois à jour, le poste continue de recevoir automatiquement les mises à jour de servicing via le processus mensuel habituel. [
• Clients commerciaux (Windows Insider Program for Business) : vous pouvez déployer et valider la version 26H2 via les Windows Update client policies et WSUS. La disponibilité sur Azure Marketplace est également prévue.
• ISO : téléchargeables depuis la page Windows Insider ISO download.  

Point de vigilance : fin de support de la 24H2

Attention aux échéances de support à anticiper dans votre planification :

• Les éditions Home et Pro de Windows 11 version 24H2 atteindront leur fin des mises à jour le 13 octobre 2026.
• Les éditions Enterprise et Education de la 24H2 restent supportées jusqu'au 12 octobre 2027.

Pour plus d'informations, consultez l'annonce officielle sur le Windows Insider Blog

Microsoft vient de publier une mise à jour (2.32.294) au client Global Secure Access de Microsoft Entra. Global Secure Access est le client utilisé par Microsoft Entra Internet Access et Private Access. Ces services sont la solution Security Service Edge de Microsoft.

La dernière mise à jour (2.32.294), disponible au téléchargement depuis le 26 août 2026, apporte les éléments suivants :

Changements fonctionnels

• Ajout d'une option« Prefer local network » (préférence pour le réseau local) pour les cas où le sous-réseau local chevauche celui d'applications privées (private applications), par exemple lors d'une impression ou d'une diffusion (casting). L'option apparaît dans les paramètres du client lorsqu'un administrateur l'active.
• Accélération de la création de nouveaux tunnels pour une meilleure expérience de tunnelisation.

Autres changements

• Le programme d'installation du client inclut désormais.NET Runtime version 10.0.9.
• Suppression de la télémétrie LastMile for Office 365 du client Global Secure Access.
• De nouvelles télémétries sont disponibles.
• Améliorations d'accessibilité.
• Diverses améliorations et corrections de bogues.

À noter : mises à jour automatiques via Windows Update

À partir de novembre 2026, le client Global Secure Access recevra automatiquement ses mises à jour via Windows Update. Les appareils bénéficieront de ces mises à jour à condition d'exécuter les versions de client suivantes (ou ultérieures) :

Pour se désinscrire (opt-out) des mises à jour automatiques, utilisez le paramètre suivant lors de l'installation ou de la mise à jour du client, en exécutant le programme d'installation en ligne de commande ou via votre solution MDM :

<Global Secure Access installer file> /quiet /norestart EnableWindowsUpdates=0

En cas de désinscription, vous êtes responsable du maintien à jour du client Global Secure Access sur les appareils concernés. Les appareils exécutant d'anciennes versions du client ne reçoivent pas les dernières fonctionnalités, correctifs et mises à jour de sécurité.

Plus d'informations sur les fonctionnalités et les différences : Global Secure Access client for Windows version release notes - Global Secure Access | Microsoft Learn

Le client est téléchargeable depuis le portail Microsoft Entra en naviguant dans Global Secure Access > Connect > Client download.

Microsoft vient d'annoncer que la Microsoft 365 Roadmap devient l'AI at Work Roadmap. Derrière ce changement de nom se cache bien plus qu'un simple relooking : c'est un signal clair de la réorientation du portefeuille de Microsoft autour de l'IA et de Copilot. L'AI at Work Roadmap se veut un point d'entrée unique pour découvrir les innovations à venir sur l'ensemble de l'écosystème : Microsoft 365, Copilot, les agents, et les expériences associées propulsées par l'IA.

À partir de septembre 2026, les informations de roadmap de Dynamics 365, Power Platform et Dataverse viendront également s'y publier. Autrement dit, Microsoft consolide dans un même endroit ce qui était jusqu'ici dispersé entre la productivité (M365), les applications métier (Dynamics/Power Platform) et la donnée (Dataverse).

La finalité opérationnelle ne change pas : la roadmap continue de soutenir vos activités de planification et de readiness en offrant de la visibilité sur les fonctionnalités et changements à venir.

Pourquoi ce n'est pas qu'un changement de nom

Le renommage d'un outil de référence comme la roadmap n'est jamais anodin. Plusieurs lectures se cumulent :

• Le centre de gravité se déplace vers l'IA. En plaçant « AI at Work » comme identité de la roadmap, Microsoft signale que l'IA n'est plus une catégorie de fonctionnalités parmi d'autres, mais le fil conducteur de toute son innovation. La productivité, les apps métier et la donnée sont désormais présentées à travers le prisme de l'IA.
• Copilot devient la couche d'orchestration transverse. Copilot n'est plus un assistant cantonné à Word, Excel ou Teams : il se positionne comme l'interface commune à M365, Dynamics et Power Platform. Regrouper les roadmaps, c'est refléter le fait que ces produits convergent autour d'une même expérience conversationnelle et agentique.
• Les agents montent en puissance. L'inclusion explicite des « agents » dans le périmètre traduit le passage d'un modèle « IA qui assiste » à un modèle « IA qui agit ». C'est cohérent avec l'essor de Copilot Studio et des agents autonomes qui exécutent des tâches métier de bout en bout.
• Casser les silos produits. Historiquement, M365 et la Business Applications (Dynamics/Power Platform) vivaient dans des univers séparés, avec leurs propres roadmaps et cycles de communication. Les réunir, c'est reconnaître — et accélérer — leur convergence autour de Dataverse comme socle de données et de Copilot comme couche d'intelligence.

La stratégie derrière la manœuvre

Ce mouvement s'inscrit dans une logique où Microsoft veut faire de l'IA le standard de travail par défaut (« AI at Work »), et non une option. En unifiant la vitrine des innovations, l'éditeur poursuit plusieurs objectifs :

• Cohérence du récit. Un message unique — « l'IA au travail » — est plus lisible pour les décideurs qu'une mosaïque de roadmaps produit. Cela facilite la construction d'un discours de valeur autour de Copilot.
• Accélérer l'adoption de Copilot. En donnant à voir un flux continu d'innovations IA transverses, Microsoft entretient l'élan d'adoption et justifie l'investissement dans les licences Copilot.
• Aligner la donnée et l'action. Intégrer Dataverse et Power Platform à la même roadmap souligne que l'IA d'entreprise a besoin d'un socle de données gouverné et de capacités d'automatisation pour délivrer de la valeur réelle.

Microsoft annonce la Public Preview du Mode Audit de l'Antivirus pour Microsoft Defender for Endpoint sur Linux. L'objectif est de permettre une détection en temps réel des malwares et des activités suspectes, sans application des actions correctives.  Concrètement, lorsque le niveau d'application (Enforcement Level) de l'antivirus est positionné sur Audit, les détections issues de l'Antivirus et du Behavior Monitoring continuent de générer des alertes, mais les actions d'enforcement — mise en quarantaine des fichiers, arrêt de processus — sont supprimées. Les équipes de sécurité conservent la même visibilité via les alertes, incidents, la Device Timeline et l'Advanced Hunting de Microsoft Defender.

De nombreuses organisations hésitent à activer la protection en temps réel (Real-time Protection) sur des serveurs Linux de production, par crainte que des faux positifs n'impactent des charges de travail critiques. Faute de voie d'évaluation sûre, l'adoption est souvent repoussée, ou le produit reste opéré en mode passif.

Le mode Audit répond précisément à ce frein : il offre un moyen sûr d'évaluer la protection antivirus en production, avant de basculer en enforcement complet. Les équipes peuvent évaluer les détections, valider les exclusions et gagner en confiance vis-à-vis de Defender Antivirus.

Ceci permet de :

• Evaluer Defender Antivirus en production sans remédiation automatique.
• Gagner en visibilité sur les détections de malwares et les activités suspectes via les alertes, incidents, la Device Timeline et l'Advanced Hunting.
• Valider les exclusions et investiguer les détections avant d'activer l'enforcement complet.
• Accélérer l'adoption de la protection en temps réel avec un risque opérationnel réduit.

Le mode Audit se configure de manière centralisée via Security Settings Management dans le portail Defender, ou localement via un profil JSON managé.  

Via le portail Defender (Security Settings Management)

1. Rendez-vous dans le portail Microsoft Defender, sous Endpoints > Configuration management > Endpoint security policies.
   
2. Créez ou modifiez une politique Antivirus ciblant vos serveurs Linux
   
3. Nommez la stratégie
4. Positionnez le paramètre Enforcement Level sur Audit.
   
5. Affectez la politique au groupe d'appareils concerné, puis enregistrez.

Générez une détection de test (fichier EICAR) puis confirmez qu'une alerte remonte dans le portail sans que le fichier soit mis en quarantaine :

curl -o /tmp/eicar.com https://secure.eicar.org/eicar.com.txt

mdatp threat list

En mode Audit, la menace doit apparaître dans les détections et alertes, tout en restant présente sur le disque (aucune remédiation appliquée).

À compter de fin septembre 2026, Microsoft modifie la manière dont certaines actions d'administration des communautés et des adhésions (memberships) sont autorisées dans Microsoft Viva Engage. L'objectif est d'aligner l'administration des communautés sur le modèle de sécurité et d'administration de Microsoft Entra.

Aujourd'hui, les utilisateurs disposant du rôle Verified Admin ou Network Admin au sein de Viva Engage peuvent réaliser un ensemble limité de tâches d'administration des communautés et des adhésions, même s'ils ne disposent pas des permissions correspondantes dans Microsoft Entra. Après ce déploiement, ces actions nécessiteront les permissions administratives Microsoft Entra appropriées.

Pour continuer à réaliser ces actions, les utilisateurs devront soit :

• Disposer du rôle Yammer Administrator dans Microsoft Entra ;
• Soit être désignés comme Community Admin de la communauté spécifique qu'ils gèrent.

Ce changement renforce la cohérence entre l'administration de Viva Engage et les contrôles d'accès de Microsoft Entra.

Ce qui va changer

Après ce déploiement, les utilisateurs disposant uniquement du rôle Verified Admin ou Network Admin au sein de Viva Engage ne pourront plus modifier les paramètres de communauté suivants, sauf s'ils disposent également du rôle Yammer Administrator dans Microsoft Entra ou s'ils sont désignés comme Community Admin de la communauté concernée :

• Nom de la communauté (Community name)
• Description de la communauté (Community description)
• Avatar de la communauté (Community avatar)
• Paramètres de confidentialité de la communauté (public ou privé)
• Gestion des adhésions (Membership management)
• Suppression de la communauté (Community deletion)

À noter : aucune modification n'est apportée aux capacités du rôle Community Admin.

Les administrateurs doivent passer en revue les attributions administratives Viva Engage avant le déploiement. Voici les étapes à prendre en compte :

• Passer en revue les utilisateurs actuellement titulaires des rôles Verified Admin et Network Admin dans Viva Engage.
• Identifier les utilisateurs qui doivent continuer à gérer les paramètres de communauté ou les adhésions.
• Déterminer si ces utilisateurs doivent se voir attribuer le rôle Yammer Administrator dans Microsoft Entra.
• Ou, alternativement, leur attribuer des permissions Community Admin pour les communautés spécifiques concernées, lorsque cela est approprié.

Dans un précédent article, je vous annonçais le passage de Microsoft Edge à un rythme de publication majeure toutes les deux semaines. Microsoft aligne désormais le runtime WebView2 sur cette même cadence : à partir de la version 152, le runtime WebView2 suivra le nouveau cycle bihebdomadaire d'Edge, contre un cycle de quatre semaines jusqu'à présent. L'objectif est d'accélérer la diffusion des correctifs de sécurité, des améliorations de la plateforme et des nouvelles fonctionnalités.  

La bascule s'opère de façon progressive :

• Depuis la semaine du 27 août 2026 : la version 152 du runtime WebView2 était la dernière version majeure publiée 4 semaines après la précédente.
• Dès la semaine du 10 septembre 2026 : la version 153 sera la toute première version publiée seulement 2 semaines après la précédente.
• Ensuite : une nouvelle version majeure sera publiée environ toutes les deux semaines, en alignement avec la cadence d'Edge.

La cadence de publication du SDK WebView2 évolue également. Au lieu des publications mensuelles, les versions du SDK seront désormais publiées lorsqu'il y a de nouvelles fonctionnalités, corrections de bugs, mises à jour de sécurité ou autres améliorations à partager. Lorsqu'un SDK est publié, il le sera à la même date que la version du runtime correspondante.

L'impact sur vos applications dépend du mode de distribution du runtime que vous utilisez :  

• Mode Evergreen Runtime (mode par défaut) : aucune action n'est requise. Les machines de vos utilisateurs commenceront simplement à recevoir les correctifs de sécurité et de plateforme à un rythme plus fréquent.
• Mode Fixed Version Runtime : vous gardez le contrôle du moment de la mise à jour, mais les nouvelles versions majeures arrivent plus souvent. Prévoyez de valider et d'adopter les nouvelles versions plus fréquemment afin de ne pas prendre de retard sur les correctifs de sécurité.

Voici les bonnes pratiques mises en avant par Microsoft :

• Tester votre application WebView2 via le canal de préversion Beta de Microsoft Edge, afin de détecter les éventuels bugs avant leur diffusion à vos utilisateurs. Le test anticipé reste le meilleur moyen d'identifier les problèmes spécifiques à votre application avant qu'ils n'atteignent le canal Stable.
• Automatiser la validation des workflows critiques de votre application avec les canaux de préversion WebView2, notamment via Microsoft Edge WebDriver.
• Signaler les régressions au plus tôt (via le dépôt GitHub WebView2Feedback) afin qu'elles puissent être corrigées avant la publication Stable.

S'aligner sur Edge signifie que vos utilisateurs bénéficient plus rapidement d'une plateforme web plus sûre et plus riche, tout en vous offrant un train de publication unique et prévisible autour duquel planifier vos activités.

Depuis la version de plateforme 4.18.26060 (publiée en juin 2026), le comportement par défaut du mode Warn des règles ASR (Attack Surface Reduction) de Microsoft Defender for Endpoint a changé. Pour lever un blocage via l'option Unblock, l'utilisateur doit désormais disposer de droits d'administrateur local. Ce changement est intentionnel et s'inscrit dans une démarche de renforcement de la sécurité de la solution.

Pour rappel, les règles ASR (réduction de la surface d'attaque) de Microsoft Defender Antivirus ciblent les comportements logiciels à risque sur les postes Windows, comportements couramment exploités par les attaquants via des malwares. Par exemple : Le lancement d'exécutables et de scripts qui tentent de télécharger ou d'exécuter des fichiers, l'exécution de scripts obfusqués ou non approuvés, etc.

Bien que des applications légitimes puissent aussi présenter ces comportements, les malwares les utilisent très fréquemment de la même manière. Les règles ASR permettent de contraindre ces comportements et d'améliorer la posture défensive de l'organisation.

Chaque règle ASR peut être configurée dans l'un des modes suivants :

• Not configured / Disabled : la règle est désactivée.
• Audit : la règle n'applique aucun blocage mais journalise l'événement (idéal pour tester l'impact avant l'application). C'est l'événement 1122 dans le journal Microsoft-Windows-Windows Defender/Operational.
• Block : la règle bloque le comportement à risque (événement 1121). [
• Warn : la règle bloque le comportement mais présente à l'utilisateur une notification lui permettant de débloquer temporairement l'action (option Unblock), sur le principe de SmartScreen. L'action est alors autorisée pendant une durée de 24 heures.

Le mode Warn constitue ainsi un compromis entre Audit et Block : il protège tout en laissant à l'utilisateur la possibilité de poursuivre une action légitime.  

Jusqu'à présent, un utilisateur standard confronté à un blocage en mode Warn pouvait cliquer sur Unblock pour outrepasser temporairement la règle. Depuis la plateforme 4.18.26060 :

• L'option Unblock en mode Warn nécessite désormais une approbation administrateur : seul un compte disposant de droits d'administrateur local peut lever le blocage.
• Ce changement empêche un utilisateur standard (ou un malware s'exécutant dans son contexte) de contourner trivialement une règle ASR, ce qui renforce la robustesse du dispositif.

Important : l'option Unblock n'est destinée qu'à une suppression temporaire du blocage. Ce n'est pas un mécanisme d'exclusion durable.

Recommandations

Voici les points à prendre en compte :

• Pour une exclusion persistante, ne vous appuyez pas sur l'option Unblock. Configurez plutôt une exclusion par règle ASR (per-ASR rule exclusion), qui est le mécanisme adapté et durable.
• Distinguez bien les trois mécanismes d'exclusion : exclusion par règle ASR, exclusion globale ASR, et exclusion antivirus. Plusieurs règles ignorent totalement l'exclusion antivirus.
• Vérifiez la version de plateforme déployée sur votre parc via Get-MpComputerStatus (champ AMProductVersion) afin d'identifier les postes déjà en 4.18.26060 ou ultérieure.
• Informez votre support (help desk) et adaptez vos procédures internes : les utilisateurs standards ne pourront plus lever eux-mêmes un blocage en mode Warn.
• Mettez à jour votre documentation de dépannage pour intégrer ce nouveau comportement lors de l'analyse des événements ASR (ID 1121/1122).

Pour plus d'informations, consultez Attack surface reduction (ASR) rules overview sur Microsoft Learn.

Dans un précédent article, je vous annonçais le changement à venir pour Endpoint DLP sur macOS 27 (Golden Gate). Pour rappel, et comme le confirme le message MC1448378, macOS 27 (Golden Gate) désactive par défaut les autorisations Accessibility et autorise les utilisateurs à les désactiver, y compris lorsque le paramètre est imposé via une solution MDM. [microsofttouch.fr]

Pourquoi est-ce important : Microsoft Purview Endpoint DLP s'appuie sur les autorisations Accessibility pour appliquer certains contrôles liés aux navigateurs. Il convient de réaliser les actions décrites ci-dessous pour maintenir la protection sur les postes concernés.

Je vous recommande d'agir dès que possible afin de disposer d'une protection dès le jour 0 sur macOS 27 (Golden Gate). Gardez à l'esprit que ces changements ne fonctionneront que pour la version Stable de macOS 27 (Golden Gate), dont la sortie est prévue par Apple en septembre.

Contrôles Endpoint DLP concernés

• Upload vers un domaine de service cloud restreint (Upload to a restricted cloud service domain)
• Coller (paste) vers les navigateurs pris en charge (Paste to supported browsers)

Si Accessibility est désactivé, ces contrôles ne peuvent pas être appliqués sans le client Endpoint DLP et la configuration décrits ci-dessous.

Aucun impact : les postes qui n'exécutent pas macOS 27, les postes macOS 27 sur lesquels Accessibility reste activé, ainsi que le navigateur Edge, ne sont pas concernés.

Action requise : mettre à niveau le client Endpoint DLP, [Optionnel] configurer Accessibility via votre solution MDM, puis vérifier le statut de l'autorisation dans le portail Microsoft Purview.

Étape 1 – Mettre à niveau le client Endpoint DLP

Installez le client Endpoint DLP version 101.26072 ou ultérieure sur tous les postes macOS 27 concernés. Pour cela, vous pouvez configurer Microsoft AutoUpdate sur les postes ou récupérer les binaires dans le portail Purview que vous pouvez ensuite packager/déployer avec Microsoft Intune : 

Cette version assure la protection des scénarios d'upload et de paste concernés lorsque Accessibility est indisponible. Les versions antérieures ne peuvent pas appliquer ces contrôles lorsque Accessibility est désactivé.

Étape 2 – Configurer Accessibility via MDM

• Activer Accessibility pour Endpoint DLP. macOS 27 désactivant Accessibility par défaut, vous devez activer ce paramètre via votre solution MDM.
  • Si vous utilisez le client Endpoint DLP version 101.26072 ou ultérieure et que l'activation d'Accessibility est déjà en place (accessibility.mobileconfig sur GitHub – microsoft/mdatp-xplat) déployée dans votre organisation lors de l'onboarding macOS, alors vous êtes déjà couvert sur ce point.
  • Si ce n'est pas le cas, vous devez utiliser le fichier mobileconfig et le déployer avec Microsoft Intune sous la forme d'une stratégie de configuration (Custom)

• [Optionnel] Personnaliser l'application (enforcement) pour les uploads vers les domaines de service cloud restreints et les actions de paste dans les navigateurs pris en charge. Si vous ne personnalisez pas ces paramètres, le client Endpoint DLP version 101.26072 ou ultérieure bloque par défaut les actions concernées lorsque Accessibility est indisponible.

Configurez les paramètres suivants dans le preference domain Microsoft Defender for Endpoint. Vous pouvez récupérer le fichier mobileconfig mis à jour avec cette section sur : mdatp-xplat/macos/settings/data_loss_prevention/accessibility/com.microsoft.wdav.mobileconfig at master · microsoft/mdatp-xplat · GitHub. Chargez le avec Microsoft Intune sous la forme d'une stratégie de configuration (Custom)

 

<key> features</key> <dict>     <key>dataLossPrevention</key>     <string>enabled</string> </dict> <key>dlp</key> <dict>     <key>accessibility</key>     <dict>         <key>enforcement</key>         <dict>             <key>unallowedBrowserMode</key>             <string>enforce</string>             <key>pasteToBrowserMode</key>             <string>enforce</string>         </dict>         <key>notification</key>         <dict>             <key>customMessage</key>             <string>Please enable Accessibility permissions to comply with IT Policy</string>         </dict>     </dict> </dict>

Étape 3 – Vérifier le statut de l'appareil

Pour consulter le statut des autorisations Endpoint DLP d'un poste dans le portail Microsoft Purview :

• Accédez à Settings > Device Onboarding > Devices.
• Sélectionnez le poste concerné.
• Dans le volet de détails de l'appareil, examinez Accessibility sous Configuration status.

Vérification : confirmez que Accessibility remonte bien le statut de configuration attendu pour chaque poste macOS 27 concerné.

Informations complémentaires

Pour plus d'informations, consultez Microsoft Purview Endpoint DLP on macOS 27 (Preview) sur Microsoft Learn.

Note sur la documentation : l'exemple XML actuel de Microsoft Learn contient un problème connu lié à l'élément <key>notification</key>. L'exemple présenté dans cet article reflète la configuration attendue ; l'article Learn sera mis à jour.

iOS 28 est attendu pour la fin de l’année. A partir de cette publication, iOS 18/iPadOS 18 sera un prérequis à l’installation du portail d’entreprise Intune, les stratégies de protection applicative (APP/MAM). Si vous gérez des périphériques iOS/iPadOS, il se peut que vous ayez des périphériques qui ne pourront pas être mis à niveau vers la version minimale prise en charge (iOS 18/iPadOS 18). Consultez la documentation Apple suivante afin de vérifier quels périphériques prennent en charge iOS 18 ou iPadOS 18 (le cas échéant).

• Modèles d’iPhone supportés
• Modèles d’iPad supportés

Microsoft précise également un traitement spécifique pour les appareils enrôlés via :

• Automated Device Enrollment (ADE) sans utilisateur
• Scénarios de terminaux partagés

Vérifiez vos rapports Intune pour voir quels périphériques ou utilisateurs peuvent être affectés. Pour les périphériques gérés en MDM, allez dans Devices > All devices et filtrez par OS. Pour les périphériques avec des stratégies de protection des applications, allez dans Apps > Monitor > App protection status > App Protection report: iOS, Android.

Avec l’arrivée de macOS 27 (Golden Gate) à l’automne 2026, Microsoft annonce la fin de support par Microsoft Intune des versions autre que macOS 15 (Sequoia) et les versions ultérieures peu après la publication.

Il se peut que cela n'ait pas d'impact sur vous car les utilisateurs ont probablement déjà mis à niveau leurs périphériques macOS. Pour connaître la liste des matériels compatibles, vous pouvez consulter : macOS Sequoia is compatible with these computers – Apple Support 

Les périphériques actuellement enregistrés sous macOS 14 ou antérieure resteront inscrits même si ces versions ne sont plus prises en charge. Les nouveaux périphériques ne pourront pas s'inscrire s'ils utilisent macOS 14 ou une version inférieure.

Vous pouvez utiliser les rapports Intune pour voir quels périphériques ou utilisateurs peuvent être impactés. Accédez à Devices > All devices et filtrez par macOS. Demandez aux utilisateurs de mettre à niveau vers une version d'OS prise en charge avant la sortie de macOS 27.

Microsoft annonce la fin du support de Microsoft Defender for Endpoint (MDE) sur Amazon Linux 2 exécuté sur une architecture ARM64 à compter du 31 octobre 2026.

À partir de cette date :

• Les nouvelles versions de Defender for Endpoint ne pourront plus être installées sur Amazon Linux 2 (ARM64).
• La version 101.25122.0004 sera la dernière version supportée.
• Aucun correctif de sécurité, correctif de bugs ou support technique ne sera fourni après le 31 octobre 2026.

Cette évolution concerne uniquement Amazon Linux 2 sur ARM64.

Vous êtes concerné si vous exécutez Microsoft Defender for Endpoint sur :Amazon Linux 2 (ARM64). En revanche, les serveurs utilisant : Amazon Linux 2 (AMD64/x86_64) ne sont pas impactés par cette annonce.

Après la fin du support, les équipements concernés ne bénéficieront plus :

• Des nouvelles fonctionnalités MDE
• Des améliorations de détection
• Des évolutions de protection
• Des mises à jour de sécurité

Cette annonce concerne un scénario relativement spécifique, mais potentiellement fréquent dans les environnements AWS reposant sur des instances ARM. Les organisations utilisant Amazon Linux 2 (ARM64) avec Microsoft Defender for Endpoint devront anticiper une migration avant le 31 octobre 2026 afin de continuer à bénéficier des mises à jour de sécurité et du support Microsoft.

Microsoft a annoncé la fin prochaine du support du paramètre historique "Target to apps on all device types" (Cibler les applications sur tous les types d'appareils) au sein des stratégies de protection d'application Intune (App Protection Policies - APP). Ce paramètre historique sera remplacé par les filtres d'attribution (assignment filters). Cette fin de support prendra effet à partir du 11 janvier 2027, ou peu après.

L'utilisation du paramètre de ciblage historique peut prendre le pas sur les filtres d'attribution, ce qui peut entraîner un comportement de ciblage des stratégies ne correspondant pas aux attentes des administrateurs.

Important : pour éviter tout écart dans l'application des stratégies, il ne faut pas supprimer ou désactiver la configuration de ciblage historique avant que le nouveau filtre d'attribution n'ait été assigné à la stratégie.

Impact sur votre organisation

Les télémétries de Microsoft indiquent que le paramètre historique "Target to apps on all device types" est actuellement configuré dans certains tenants. Une fois le support de ce paramètre historique terminé, celui-ci ne s'appliquera plus. Les stratégies qui n'auront pas été migrées exclusivement vers des filtres d'attribution peuvent alors présenter des écarts de ciblage ou d'application.

À noter : si l'appareil est géré en MDM par un service tiers ou partenaire, les filtres d'attribution d'applications gérées ne pourront pas être mis en correspondance avec les types de gestion les plus granulaires.

Ce que vous devez faire pour vous préparer

Avant ce changement, afin d'éviter toute interruption dans le ciblage des stratégies, il convient de suivre les étapes suivantes, dans l'ordre, pour basculer vers les filtres d'attribution :

1. Passer en revue les stratégies APP existantes. Les stratégies pour lesquelles "Target to apps on all device types" est défini sur "No" utilisent la configuration de ciblage historique et doivent être migrées vers des filtres d'attribution :
   • Accédez au centre d'administration Intune > Apps > Protection pour éditer les stratégies APP existantes.
   • Sélectionnez une stratégie existante afin de vérifier si elle utilise un paramètre historique.
   • Dans le volet Intune App Protection, sélectionnez Properties.
   • Dans la section Apps, si "Target to apps on all device types" est défini sur "No", passez à l'étape 2. Si le paramètre est défini sur "Yes", aucune action n'est requise pour cette stratégie : revenez à Apps > Protection pour examiner les autres stratégies.
     
2. Créer un filtre d'attribution "Managed apps" en utilisant la propriété app.deviceManagementType reflétant le comportement de ciblage souhaité. Par exemple : (app.deviceManagementType -eq "Automated Device Enrollment user-associated devices"). Microsoft recommande également de créer et d'utiliser un filtre incluant (app.deviceManagementType -ne "Unmanaged") afin de garantir que le filtre ne s'applique qu'aux appareils gérés.
   • Si votre stratégie historique était configurée pour cibler les appareils iOS/iPadOS "Managed", votre nouveau filtre d'attribution doit inclure :
     • Managed
     • Automated Device Enrollment user-associated devices
     • Automated Device Enrollment userless devices
     • Account Driven User Enrollment
     • Device Enrollment with Company Portal and Web Enrollment
   • Si votre stratégie historique était configurée pour cibler les appareils Android "Android Enterprise", votre nouveau filtre d'attribution doit inclure tous les types d'appareils Android pertinents ci-dessous :
     • Corporate-owned dedicated devices with Entra ID Shared mode
     • Corporate-owned dedicated devices without Entra ID Shared mode
     • Corporate-owned with work profile
     • Corporate-owned fully managed
     • Personally-owned work profile
       
       
       Le filtre doit être adapté à votre stratégie
3. Assigner le filtre à la stratégie existante tout en conservant la configuration de ciblage historique active. Cela permet d'éviter tout changement involontaire dans le ciblage de groupes et les assignations de stratégies :
   • Dans le volet de la stratégie Intune App Protection, sélectionnez Properties.
   • Dans la section Assignments, sélectionnez "Edit".
   • Dans la section Included group, sélectionnez "Edit Filter" > "Include filtered devices in assignment" et choisissez le filtre Managed apps précédemment créé.
   • Vérifiez et enregistrez vos modifications.
     
     
     
4. Supprimer la configuration de ciblage historique. Une fois la bonne configuration du filtre d'attribution confirmée, mettez à jour le paramètre historique de la stratégie pour cibler All device types. Les filtres d'attribution deviendront alors le mécanisme de ciblage principal, et le paramètre historique ne sera plus visible ni modifiable dans le centre d'administration.
   Dans les propriétés, éditez la section Apps puis changer Target to app on all devices types à Yes.
   
5. Répéter les étapes 1 à 4 pour chaque stratégie APP Intune de votre tenant.
6. Surveiller le déploiement des stratégies afin de valider leur bonne application et leur conformité après le changement.

Plus d'informations sur la création d'un filtre dans la documentation Microsoft Intune.