Microsoft Entra Agent ID ou principaux de service : lequel vos agents IA doivent-ils utiliser ?

By Mirko Peters · 2026-10-26

Comparez Microsoft Entra Agent ID et les principaux de service. Découvrez pourquoi les agents IA ont besoin de cadres d’identité dédiés et d’une gouvernance par blueprints dans Microsoft 365.

Automatically translated with AI from the original post. Read the English original

Lorsque vous déployez des agents IA autonomes dans Microsoft 365, le choix du bon modèle d’identité est crucial. Si les principaux de service gèrent depuis longtemps les charges de travail applicatives standard, ils montrent leurs limites face à des agents IA éphémères et à forte cadence. Microsoft Entra Agent ID introduit une architecture dédiée qui sépare la gestion des identifiants des autorisations de l’agent, ce qui répond à des enjeux majeurs de sécurité et d’auditabilité.

Points clés

• Les principaux de service lient les identifiants et les autorisations directement à une application donnée, ce qui rend difficiles le suivi et la sécurisation d’agents IA à forte cadence et de courte durée de vie.
• Microsoft Entra Agent ID dissocie les identifiants en les stockant sur un blueprint central, tout en attribuant une identité unique à chaque agent.
• Les identités d’agent suppriment les secrets locaux présents sur l’agent lui-même, ce qui réduit considérablement le rayon d’impact en cas de compromission d’un composant.
• Les blueprints permettent aux administrateurs d’appliquer des stratégies en masse, de gérer les cycles de vie et de servir d’interrupteur d’arrêt d’urgence absolu pour des familles entières d’agents IA.
• Les identités managées restent idéales pour le code hébergé sur Azure, tandis que les Agent ID sont conçues spécifiquement pour les agents IA autonomes qui prennent des décisions indépendantes à l’exécution.

Comprendre la lacune identitaire des travailleurs IA

Les agents d’intelligence artificielle ne rentrent pas facilement dans les catégories traditionnelles de l’identité d’entreprise. Contrairement aux utilisateurs standard, qui s’authentifient par mot de passe ou par code d’authentification multifacteur, et contrairement aux applications traditionnelles qui reposent sur des comptes de service stables et de longue durée, les agents IA fonctionnent de manière dynamique. Un flux de travail automatisé très sollicité peut créer des milliers d’instances d’agent et les supprimer toutes au cours d’une seule journée de travail. Lorsque ces agents éphémères s’appuient sur des comptes de service partagés ou empruntent des identifiants humains, vos journaux d’audit d’entreprise deviennent vite une fiction peu fiable.

Par ailleurs, lorsqu’un incident survient à deux heures du matin, les administrateurs informatiques doivent répondre à deux questions fondamentales : quel agent spécifique a effectué cette action, et qui en est responsable ? Les inscriptions d’applications traditionnelles et les principaux de service partagés rendent ces réponses presque impossibles sans perturber des charges de travail sans rapport. Cet angle mort opérationnel explique précisément pourquoi Microsoft a développé un cadre spécialisé pour les travailleurs non humains.

Principaux de service ou Agent ID : différences d’architecture

Pour bien comprendre pourquoi Microsoft Entra Agent ID représente un véritable changement de paradigme, il faut saisir en quoi sa structure diffère de celle d’un principal de service standard. Un principal de service est une instanciation un-à-un d’un objet application dans votre locataire. Il détient ses propres secrets de longue durée, ses certificats client et ses attributions d’autorisations directes. Pour les applications web stables et prévisibles ainsi que pour les démons en arrière-plan, ce modèle a fait ses preuves pendant des années.

Cependant, obliger un agent IA à utiliser un principal de service standard introduit une friction administrative importante :

• Prolifération des identifiants : chaque fois qu’un flux de travail automatisé crée une nouvelle instance d’agent, la création d’un nouveau principal de service laisse des secrets client dispersés dans votre environnement.
• Problèmes de granularité : désactiver un seul agent défaillant oblige à trier des centaines de principaux de service, au risque de mettre accidentellement fin à des processus métier critiques.
• Ambiguïté d’audit : les comptes d’application partagés masquent l’instance de flux de travail exacte qui a accédé à des données sensibles de l’entreprise.

En revanche, le modèle Agent ID introduit une relation parent-enfant par l'intermédiaire d'un blueprint administratif. Le blueprint stocke de manière sécurisée les identifiants d'authentification et définit les périmètres autorisés, tandis que les identités d'agents individuelles portent des identifiants uniques et sont instanciées dynamiquement. L'identité d'agent elle-même ne contient ni mot de passe ni secret, ce qui signifie qu'il n'existe aucun identifiant qu'un attaquant pourrait extraire de l'environnement d'exécution.

La puissance des blueprints dans la gestion de flotte

L'innovation majeure de Microsoft Entra Agent ID repose sur l'objet blueprint. Considérez un blueprint comme un modèle principal qui régit une flotte d'agents IA apparentés. Par exemple, si votre organisation déploie un modèle « Sales Assistant Agent », vous pouvez instancier dynamiquement des déclinaisons régionales pour l'Amérique du Nord, l'Amérique du Sud et l'Europe à partir de cette seule définition.

Parce que ces agents partagent un blueprint commun, les administrateurs disposent de capacités de gestion puissantes qui passent à l'échelle sans effort :

• Application centralisée des stratégies : l'application d'une stratégie d'accès conditionnel ou d'une restriction d'autorisations Microsoft Graph au blueprint couvre automatiquement chaque instance d'agent qui en est issue, y compris les instances futures.
• Le bouton d'arrêt d'urgence : si une vulnérabilité est découverte dans une classe d'agents spécifique, la désactivation du blueprint parent interrompt immédiatement l'authentification de chaque identité d'agent sous-jacente dans l'ensemble du locataire.
• Gouvernance par sponsor : chaque identité d'agent nécessite un sponsor humain nommément désigné. Si ce sponsor quitte l'organisation, Microsoft Entra transfère automatiquement le parrainage à son manager, ce qui évite que des charges de travail IA orphelines ne fonctionnent sans supervision.

Quel type d'identité utiliser selon votre architecture

Les environnements Microsoft 365 et Azure modernes exigent une approche à plusieurs facettes pour les identités non humaines. Choisir le mécanisme approprié permet d'éviter les failles de sécurité et la charge administrative inutile.

Identités managées pour le code hébergé dans Azure

Si votre code personnalisé, vos fonctions ou vos microservices s'exécutent directement dans l'infrastructure Azure, privilégiez systématiquement les identités managées. Azure gère automatiquement le cycle de vie et la rotation des identifiants, ce qui signifie qu'aucun secret ne subsiste pour que vos équipes le surveillent ou le divulguent accidentellement dans les dépôts de code source.

Principaux de service pour les applications traditionnelles

Continuez d'utiliser les principaux de service standard pour les applications d'entreprise stables, les intégrations SaaS et les services daemon de longue durée qui nécessitent des contextes d'application persistants et dédiés ainsi que les flux d'identifiants client classiques.

Agent ID pour les travailleurs IA autonomes

Recourez à Microsoft Entra Agent ID spécifiquement lorsque vous déployez des agents IA (par exemple ceux créés dans Copilot Studio ou dans des frameworks d'orchestration personnalisés) qui évaluent dynamiquement des situations, prennent des décisions autonomes et interagissent avec les données Microsoft 365 au nom des utilisateurs ou des flux de travail.

Sécuriser votre avenir dans le cloud

Alors que l'intelligence artificielle autonome devient un pilier central de la transformation numérique, gérer des agents IA avec des comptes de service hérités crée une dette de sécurité inacceptable. En adoptant Microsoft Entra Agent ID, les administrateurs informatiques peuvent tirer parti de la rapidité et de l'échelle de l'IA moderne tout en conservant une gouvernance stricte, des pistes d'audit claires et des garde-fous robustes fondés sur le principe du moindre privilège. Pour approfondir le fonctionnement de ces mécanismes, écoutez l'épisode complet et rejoignez notre conversation continue sur la sécurisation du cloud Microsoft.

Questions fréquentes

Les identités d'agents Microsoft Entra stockent-elles localement des mots de passe ou des secrets ?

Non. Les identités d'agents sont conçues pour ne contenir aucun identifiant, secret ni certificat local. La gestion de l'authentification est assurée de manière sécurisée par le blueprint parent, ce qui empêche les attaquants d'extraire des clés de l'environnement d'exécution de l'agent.

Comment les blueprints d'agents gèrent-ils les déploiements multilocataires ?

Les blueprints peuvent être publiés entre organisations en tant que modèles multilocataires. Toutefois, lorsqu'un client déploie le blueprint dans son locataire, les identités d'agents qui en résultent sont strictement monolocataires et localisées, ce qui garantit que le rayon d'impact reste entièrement contenu dans les limites de votre organisation.

Que devient un agent IA si son sponsor humain quitte l'entreprise ?

Pour éviter que des agents IA orphelins ne fonctionnent indéfiniment sans supervision, Microsoft Entra transfère automatiquement le parrainage de l'identité d'agent au manager direct du sponsor sortant.

Les stratégies d’accès conditionnel peuvent-elles être appliquées directement aux identités d’agent ?

Oui. Le moteur d’accès conditionnel évalue les signaux de connexion des identités d’agent exactement comme ceux des utilisateurs. De plus, cibler une stratégie sur un plan d’agent (blueprint) applique automatiquement ces règles à toutes les instances d’agent existantes et futures créées à partir de ce modèle.