Les politiques d’accès conditionnel de Microsoft Entra ID évaluent les signaux d’identité, l’état de l’appareil et le contexte de risque à chaque connexion, puis accordent, bloquent ou restreignent l’accès en fonction des règles que vous définissez. Elles constituent la couche d’identité d’une architecture de confiance zéro. Mais les contrôles de la couche d’identité ne couvrent que la moitié de la surface d’accès. L’autre moitié, l’accès au niveau du réseau aux applications internes, aux ressources sur site et aux services non Microsoft, relève de la plateforme ZTNA de SASE. Pour les équipes informatiques du marché intermédiaire qui gèrent entre 50 et 400 utilisateurs, la question stratégique en 2026 est de savoir comment coordonner les deux couches afin qu’un contexte d’identité unique détermine chaque décision d’accès, de Microsoft 365 à votre ERP sur site, sans maintenir deux ensembles de politiques déconnectés.
Quelles sont les politiques d’accès conditionnel en 2026 ?
Les politiques d’accès conditionnel sont des règles if-then dans Microsoft Entra ID qui évaluent les signaux (identité de l’utilisateur, appartenance à un groupe, conformité de l’appareil, emplacement, risque de connexion) et appliquent des contrôles (exiger MFA, exiger un appareil conforme, bloquer l’accès, limiter la durée de la session) avant d’accorder l’accès aux applications et aux ressources du cloud. En 2026, l’accès conditionnel a dépassé le stade de l’évaluation statique des règles pour passer à l’optimisation des politiques assistée par l’IA, aux capacités de déploiement progressif et à l’application des politiques par rapport aux identités des agents de l’IA. Le champ d’application s’est élargi, mais la logique de base demeure : collecte des signaux, évaluation par rapport à la politique, application d’une décision. Ce que l’accès conditionnel ne couvre pas, c’est l’accès au niveau du réseau. Les applications qui se trouvent derrière votre pare-feu, les systèmes de contrôle industriel, les applications web personnalisées sur une infrastructure privée et les services antérieurs à l’identité dans le nuage nécessitent tous une couche d’application complémentaire qui opère au niveau du réseau.
Principes fondamentaux de l’accès conditionnel
Le moteur d’accès conditionnel fonctionne en trois phases. Premièrement, la collecte des signaux : Entra ID recueille les signaux d’identité (utilisateur, groupe, rôle), les signaux d’appareil (état de conformité d’Intune, version du système d’exploitation, état du chiffrement), les signaux d’emplacement (IP, emplacements nommés), le contexte de l’application (quelle ressource est accédée) et les signaux de risque (risque d’ouverture de session et risque d’utilisateur d’Entra ID Protection). Deuxièmement, l’évaluation des politiques : toutes les politiques applicables sont évaluées simultanément. Si un utilisateur relève de plusieurs politiques, chaque condition doit être remplie. Une politique exigeant l’AMF et une autre politique exigeant un appareil conforme signifient que l’utilisateur doit satisfaire aux deux conditions avant que l’accès ne lui soit accordé. Troisièmement, l’application : le moteur bloque l’accès, accorde l’accès avec des contrôles (MFA, conformité de l’appareil, force d’authentification) ou applique des contrôles de session (durée limitée de la session, restrictions imposées par l’application, évaluation continue de l’accès).
Pour les spécificités d’installation, les détails de licence et la configuration étape par étape, Microsoft Learn reste la source de référence. Ce guide se concentre sur l’architecture de coordination que la documentation de Microsoft n’aborde pas : comment l’accès conditionnel fonctionne avec la plateforme SASE ZTNA pour fournir une application unifiée des politiques à travers les couches d’identité et de réseau.
Le paysage de l’accès conditionnel en 2026
Trois événements survenus entre janvier et mai 2026 ont modifié les possibilités de l’accès conditionnel.
L‘agent d’optimisation de l’accès conditionnel est devenu généralement disponible via Microsoft Security Copilot. Il analyse votre locataire en continu, identifie les utilisateurs, les applications et les identités des agents d’intelligence artificielle qui ne sont pas couverts par les politiques existantes, et propose des correctifs ciblés. L’agent évalue si le MFA est appliqué, si les contrôles basés sur les appareils sont actifs, si l’authentification héritée est bloquée et si des politiques similaires peuvent être consolidées. Chaque analyse consomme moins d’une unité de calcul de sécurité. La prise en charge du déploiement progressif signifie que vous pouvez déployer des changements de politique progressivement parmi les groupes d’utilisateurs plutôt que de les appliquer à l’ensemble des locataires en une seule étape. Une campagne d’adoption des clés de sécurité évalue l’état de préparation des appareils et des utilisateurs à l’authentification résistante à l’hameçonnage et génère un plan de déploiement. L’agent d’optimisation nécessite au minimum Entra ID P1. Les fonctionnalités complètes de politiques basées sur le risque nécessitent P2 ou Microsoft 365 E5.
La modification de l’application de la règle « Toutes les ressources » met fin à un contournement qui existait depuis des années. Lorsqu’une politique d’accès conditionnel ciblait « Toutes les ressources » avec une ou plusieurs exclusions de ressources, les connexions demandant uniquement des champs d’application OIDC de base (openid, profil, courriel) ou des champs d’application de répertoire limités (User.Read) étaient silencieusement exemptées de l’application de la politique. Les outils tels que Azure CLI, Visual Studio Code et les applications personnalisées utilisant ces champs d’application minimaux contournaient entièrement les vérifications de conformité de l’AMF et des appareils. Microsoft a annoncé le correctif en janvier 2026, a commencé à l’appliquer le 13 mai 2026 et achèvera le déploiement progressif au milieu de l’été 2026. Les équipes informatiques disposant d’applications personnalisées qui ne demandent que des champs d’application de base doivent vérifier que ces applications peuvent relever les défis de l’accès conditionnel avant que la mise en œuvre n’atteigne leur locataire.
Les identités des agents d’intelligence artificielle sont désormais des acteurs de premier ordre dans l’écosystème Entra ID. Microsoft Entra Agent ID assure l’enregistrement, la gestion du cycle de vie et la gouvernance des agents d’IA qui agissent au nom des utilisateurs. Les politiques d’accès conditionnel peuvent cibler ces identités par le biais de flux » on-behalf-of « , en appliquant les mêmes contrôles (MFA, conformité des appareils, évaluation des risques) que ceux qui s’appliquent aux utilisateurs humains. L’agent d’optimisation surveille les identités des agents pour détecter les autorisations excessives et recommande des ajustements de moindre privilège. Pour les organisations déployant Microsoft 365 Copilot, des assistants IA personnalisés ou des frameworks d’agents tiers, régir ces identités par le biais d’un accès conditionnel n’est plus optionnel.
Les politiques à fort impact pour les entreprises de taille moyenne
Pour les organisations comptant entre 50 et 400 utilisateurs, un petit nombre de règles bien configurées permet de réduire la majorité des risques. La complexité est l’ennemie de la sécurité sur le marché intermédiaire, et la prolifération des règles crée plus de lacunes qu’elle n’en résout.
MFA résistant à l’hameçonnage pour tous les utilisateurs. La base 2026 est constituée de passkeys ou de clés de sécurité FIDO2, et non de SMS ou de notifications push d’applications d’authentification. Les attaques de type « Adversary-in-the-middle » (AiTM) interceptent les jetons MFA traditionnels en temps réel. Les méthodes résistantes au phishing éliminent totalement ce vecteur. L’agent d’optimisation peut évaluer l’état de préparation de votre locataire et générer un plan de déploiement progressif.
Bloquer les protocoles d’authentification traditionnels. Les authentifications de base IMAP, POP3 et SMTP ne prennent pas en charge l’AMF et restent les principales cibles des attaques par pulvérisation de mot de passe. Une politique unique bloquant ces protocoles pour tous les utilisateurs ferme l’une des voies d’attaque les plus simples.
Exiger des appareils conformes pour les données de l’entreprise. Liez l’accès aux ressources Microsoft 365 (SharePoint, Teams, Outlook, OneDrive) à l’état de conformité d’Intune. Seuls les appareils dotés d’une version actuelle du système d’exploitation, d’un chiffrement de disque actif et d’une protection des points finaux en cours d’exécution peuvent y accéder. Cela permet d’éviter les fuites de données vers des appareils personnels non gérés sans bloquer complètement le BYOD, car l’accès par navigateur avec des restrictions de session reste disponible comme solution de repli.
Contrôles basés sur les risques pour les comptes privilégiés. Les administrateurs globaux, les administrateurs de sécurité et d’autres rôles privilégiés nécessitent un MFA à chaque connexion et un blocage automatique lorsque Entra ID Protection détecte un risque élevé pour l’utilisateur. Séparez-les dans une politique dédiée plutôt que de vous appuyer sur la politique MFA de base.
Bloquez l’accès à partir de zones géographiques non fiables. Les politiques de localisation nommées qui limitent les ouvertures de session aux pays où votre organisation opère filtrent un volume important de trafic d’attaques automatisées. La localisation basée sur l’IP n’est pas infaillible, mais elle augmente considérablement le coût de l’abus d’informations d’identification.
Protégez les portails administratifs. L’accès au portail Azure, au centre d’administration Entra et au centre d’administration Microsoft 365 mérite sa propre politique nécessitant à la fois un appareil conforme et un MFA résistant au phishing. Les interfaces administratives sont des cibles de grande valeur qui justifient des contrôles plus stricts que l’accès général des utilisateurs.
Le niveau de licence est important. Microsoft 365 E3 inclut Entra ID P1, qui fournit un accès conditionnel avec la conformité des appareils, l’application du MFA et des emplacements nommés. Microsoft 365 E5 ajoute Entra ID P2, qui permet des politiques basées sur le risque (risque d’ouverture de session et risque d’utilisateur), les pleines capacités de l’agent d’optimisation et Entra ID Protection. Pour les organisations qui ont besoin de contrôles basés sur les risques, d’une protection des jetons et d’une optimisation complète assistée par l’IA, E5 offre une valeur de sécurité significative supérieure à E3.
Les erreurs de déploiement les plus courantes et comment les éviter
Verrouillage par un blocage trop large. Une politique définie sur « Tous les utilisateurs, Toutes les ressources, Bloquer » sans exclusions bloque tout le monde si les services MFA subissent une panne ou si une erreur de configuration affecte tous les administrateurs. Maintenez au moins deux comptes d’accès d’urgence (comptes « break-glass ») exclus de toutes les politiques d’accès conditionnel. Ces comptes utilisent des mots de passe extrêmement longs et uniques stockés physiquement hors ligne et sont surveillés par les journaux d’audit d’Entra ID pour toute activité d’ouverture de session.
Le mitage de l’espace. Les politiques accumulent les exclusions au fil du temps : un entrepreneur qui avait besoin d’un accès temporaire, une application ancienne qui ne pouvait pas gérer l’AMF, un compte de service que personne n’a documenté. Chaque exclusion est un chemin d’accès non surveillé. L’agent d’optimisation identifie automatiquement ces lacunes, mais vous avez toujours besoin d’un processus de révision trimestriel qui examine chaque exclusion et la supprime ou en documente la justification.
Nommer le chaos. Lorsque 30 politiques portent des noms tels que « Test MFA policy » et « New policy – copy », le dépannage devient une affaire de devinettes. Adoptez une convention de dénomination structurée : CA[number]- [portée]-[action]-[condition]. Par exemple : CA001-AllUsers-RequireMFA-PhishingResistant. Utilisez le mode Rapport uniquement pendant au moins une semaine avant d’appliquer une nouvelle politique, et consultez le classeur Conditional Access Insights pour comprendre l’impact avant de passer à l’application.
Absence d’évaluation de l’accès continu. Un jeton émis à 9 heures avec une durée de vie d’une heure donne à un attaquant qui vole ce jeton une heure complète d’accès. L’évaluation continue de l’accès (CAE) permet une révocation en temps quasi réel lorsque des événements critiques se produisent : réinitialisation du mot de passe, désactivation du compte, changement de l’emplacement du réseau ou changement de l’état de conformité. Vérifiez que l’évaluation continue des accès est activée pour vos politiques critiques plutôt que de vous fier uniquement aux contrôles de la durée de vie des jetons.
Accès conditionnel et ZTNA : des politiques complémentaires
C’est là que s’arrêtent la plupart des conseils et que commence le manque de coordination. L’accès conditionnel contrôle la couche d’identité : il décide si un utilisateur disposant d’un appareil spécifique dans un contexte spécifique peut accéder à une application Microsoft 365 ou à un service SaaS enregistré. Le ZTNA de la plateforme SASE contrôle la couche réseau : il décide si ce même utilisateur peut accéder à une application interne, à un service web privé, à un serveur de base de données ou à une interface de gestion OT.
Les deux couches utilisent le même contexte d’identité. La plateforme SASE de Jimber s’authentifie auprès d’Entra ID en tant que fournisseur d’identité. L’identité de l’utilisateur, l’appartenance à un groupe et l’état de conformité de l’appareil que l’accès conditionnel évalue à la frontière de Microsoft 365 déterminent également les décisions d’accès à ZTNA à la frontière du réseau. Il n’y a pas de magasin d’identité séparé à maintenir, pas de synchronisation de justificatifs à gérer et pas de duplication de politique à aligner.
La coordination pratique fonctionne comme suit. L’accès conditionnel régit Microsoft 365 et les applications SaaS enregistrées. Lorsqu’un responsable informatique se connecte à Teams, Entra ID évalue les politiques d’accès conditionnel. Le ZTNA de Jimber régit les applications internes, les services web privés et les ressources sur site. Lorsque le même responsable informatique se connecte au système ERP sur site, la plateforme SASE évalue le contexte d’identité Entra ID et applique ses propres politiques d’accès. Les deux décisions font référence au même état de conformité de l’appareil provenant d’Intune. Si un ordinateur portable échoue au contrôle de conformité, l’accès conditionnel bloque l’accès aux équipes et la plateforme SASE bloque l’accès à l’ERP simultanément. Pas d’écart, pas d’incohérence.
Cette coordination s’étend à la journalisation et aux pistes d’audit. Entra ID enregistre les événements au niveau de l’identité : qui s’est authentifié, quelle méthode MFA a été utilisée, quels signaux de risque étaient présents, quelle politique a autorisé ou bloqué l’accès. La plateforme Jimber enregistre les événements au niveau du réseau : quelle application interne a été accédée, à partir de quelle IP source, par quelle connexion ZTNA, avec quels paramètres de cryptage. Combinés, ces journaux fournissent une image complète de l’accès qu’aucun système ne peut fournir à lui seul.
Pour les organisations qui gèrent des appareils sans agent, des imprimantes, des capteurs IoT, des équipements industriels, la coordination a une troisième dimension. Ces appareils ne peuvent pas participer à l’authentification Entra ID. Le matériel NIAC de Jimber fournit une isolation en ligne au niveau du réseau, en appliquant des contrôles d’accès pour les appareils qui se situent entièrement en dehors de la frontière d’accès conditionnel. La couche d’identité gère les utilisateurs et les terminaux gérés. La plateforme SASE s’occupe de tout le reste.
Éléments probants de l’audit NIS2 provenant de l’accès conditionnel et du SASE
L’article 21 du NIS2 exige des « mesures techniques, opérationnelles et organisationnelles appropriées et proportionnées » pour la gestion des risques, incluant explicitement les politiques de contrôle d’accès, l’authentification multifactorielle et la surveillance continue. L’accès conditionnel constitue une preuve directe de plusieurs de ces exigences.
La documentation relative au contrôle d’accès provient des exportations de politiques d’accès conditionnel montrant l’application du principe du moindre privilège : quels utilisateurs accèdent à quelles ressources dans quelles conditions. Les preuves de l’application de l’authentification multifactorielle proviennent des journaux de connexion d’Entra ID qui confirment que l’authentification multifactorielle a été requise et effectuée pour chaque accès aux systèmes dans le champ d’application. Les contrôles d’accès à la chaîne d’approvisionnement proviennent des politiques d’accès des invités qui limitent les autorisations des partenaires externes et appliquent la conformité des appareils pour la collaboration B2B.
C’est au niveau du réseau que les preuves d’accès conditionnel sont insuffisantes. Le NIS2 exige également une segmentation du réseau, des capacités de détection et de réponse aux incidents, ainsi qu’une surveillance des mouvements latéraux. Il s’agit de contrôles au niveau du réseau qu’Entra ID ne fournit pas. Une plateforme SASE comble ces lacunes. La journalisation centralisée de Jimber capture les événements d’accès au niveau du réseau en même temps que les événements au niveau de l’identité, fournissant ainsi la piste d’audit combinée que les inspecteurs NIS2 attendent. La vérification de la posture des appareils, la segmentation du réseau grâce à des politiques de microsegmentation et le confinement des incidents grâce à l’isolation en ligne génèrent tous des preuves de conformité que l’accès conditionnel seul ne peut pas produire.
Pour les organisations belges qui se préparent à la vérification des cyberfondamentaux, cette combinaison est particulièrement pertinente. Les contrôles CyFun de la fonction Protect sont directement liés aux contrôles de posture des appareils, à l’accès basé sur l’identité et à la segmentation du réseau. La liste de contrôle de conformité NIS2 destinée aux responsables informatiques couvre les attentes du Centre pour la cybersécurité en Belgique.
L’avenir de l’accès conditionnel en 2026
L’évaluation continue de l’accès est en passe de devenir le modèle de session par défaut. Plutôt que de s’appuyer sur la durée de vie des jetons, mesurée en heures, l’IAO permet de mettre fin à une session presque instantanément lorsque des événements importants pour la sécurité se produisent. La fenêtre d’opportunité pour les attaquants utilisant des jetons volés se réduit de 60 minutes à quelques secondes.
L’adoption des Passkeys et de FIDO2 s’accélère sur le marché intermédiaire, soutenue par les campagnes de déploiement de Passkeys de l’agent d’optimisation. Comme l’authentification résistante au phishing devient le plancher plutôt que le plafond, les méthodes MFA traditionnelles (SMS, notification push) seront de plus en plus considérées comme insuffisantes pour les environnements réglementés.
La gouvernance des politiques assistée par l’IA via l’agent d’optimisation s’étendra au-delà de l’identification des lacunes à des recommandations de politiques prédictives basées sur l’analyse des modèles d’ouverture de session et des renseignements sur les menaces. Les améliorations apportées en mars 2026 comprennent déjà des recommandations contextuelles, une analyse approfondie des lacunes et des rapports sur la posture de confiance zéro.
La convergence des politiques d’identité et de réseau est la trajectoire à long terme. La distinction entre « le contrôle d’identité a-t-il réussi » et « le chemin du réseau est-il sécurisé » est un artefact de mise en œuvre, et non un principe de sécurité. Les plateformes qui unifient les deux évaluations par rapport à un contexte d’identité unique, en appliquant l’accès conditionnel à la frontière du nuage et le ZTNA à la frontière du réseau, fournissent l’architecture que la prochaine génération de contrôle d’accès exige. Pour les responsables informatiques qui évaluent leur architecture de sécurité pour 2026, la question n’est pas de savoir s’il faut déployer l’accès conditionnel ou le ZTNA. Les deux sont nécessaires. Le guide de l’architecture Zero Trust explique comment ces couches s’intègrent dans un modèle complet.
Questions fréquemment posées
Quelles sont les politiques d’accès conditionnel en 2026 ?
Les politiques d’accès conditionnel sont des règles » si-alors » dans Microsoft Entra ID qui évaluent les signaux d’identité, l’état de l’appareil et le contexte de risque lors de la connexion, puis appliquent des contrôles tels que l’AMF, la conformité de l’appareil ou les restrictions de session avant d’accorder l’accès aux applications et ressources du cloud. En 2026, elles couvrent également les identités des agents d’IA et bénéficient d’une optimisation assistée par l’IA grâce à l’agent d’optimisation de l’accès conditionnel.
Qu’est-ce que l’agent d’optimisation de l’accès conditionnel ?
L’agent d’optimisation est un agent alimenté par l’IA dans Microsoft Security Copilot qui scanne continuellement votre locataire Entra ID à la recherche de lacunes dans les politiques, d’utilisateurs non couverts, d’applications et d’identités d’agents d’IA. Il recommande de nouvelles politiques, suggère la consolidation des politiques existantes, prend en charge le déploiement progressif des changements et peut générer des campagnes d’adoption de clés. Il nécessite Entra ID P1 au minimum et consomme des unités de calcul de sécurité.
Comment fonctionne l’accès conditionnel avec les plateformes SASE comme Jimber ?
L’accès conditionnel régit l’accès à Microsoft 365 et aux applications SaaS enregistrées au niveau de l’identité. La plateforme SASE de Jimber régit l’accès aux applications internes, aux ressources privées et aux appareils sans agent au niveau du réseau. Les deux utilisent le même contexte d’identité Entra ID, de sorte que la conformité des appareils et l’identité de l’utilisateur déterminent les décisions d’accès de manière cohérente à travers les ressources dans le nuage et sur site, sans avoir à maintenir des ensembles de politiques distincts.
Qu’est-ce qui a changé pour l’application du contrôle d’accès en 2026 ?
Microsoft a commencé à appliquer des politiques d’accès conditionnel contre les connexions utilisant uniquement des portées OIDC de base (openid, profil, email) et des portées d’annuaire limitées (User.Read) à partir du 13 mai 2026. Auparavant, ces connexions contournaient les politiques ciblant « Toutes les ressources » lorsque des exclusions de ressources étaient présentes. Cette modification comble une lacune de longue date qui permettait à des outils comme Azure CLI de contourner les exigences de l’AMF.
L’accès conditionnel satisfait-il aux exigences de l’article 21 du NIS2 ?
L’accès conditionnel fournit des preuves pour le contrôle d’accès basé sur l’identité et l’application de l’AMF, qui sont des exigences explicites de NIS2. Il ne répond pas aux exigences au niveau du réseau telles que la segmentation du réseau, la surveillance des mouvements latéraux et l’endiguement des incidents. Pour répondre à l’intégralité de l’article 21, il faut combiner les contrôles de la couche d’identité avec les contrôles de la couche réseau à partir d’une plateforme SASE.
Accès conditionnel et ZTNA : est-ce la même chose ?
Ils sont complémentaires, mais pas identiques. L’accès conditionnel évalue l’identité et le contexte de l’appareil à la limite de l’application en nuage. ZTNA évalue le contexte de l’identité à la frontière du réseau, accordant un accès par application aux ressources internes sans exposer le réseau au sens large. L’accès conditionnel décide si vous pouvez ouvrir Teams. ZTNA décide si vous pouvez accéder au serveur ERP sur site. Tous deux appliquent les principes de la confiance zéro à différentes couches de la pile d’accès.
Prêt à voir comment l’accès basé sur l’identité coordonne les ressources cloud et on-premise pour votre environnement ? Réservez une démonstration et découvrez comment la plateforme SASE de Jimber fonctionne avec Microsoft Entra ID pour offrir une application unifiée des politiques sans dupliquer la gestion des identités.
