Îlots d’identité : naviguer entre jetons ACS et Azure AD

Par Mirko Peters · 2026-08-11

Bon retour sur le blog ! Si vous vous êtes déjà penché sur une feuille de route produit, en vous demandant s’il fallait intégrer directement des fonctionnalités de communication personnalisées dans votre application web o…

Traduit automatiquement par IA à partir de l'article original. Lire l'original en anglais

Titelbild: Identity Islands: Navigating ACS Tokens vs Azure AD

Bienvenue sur le blog ! Si vous avez déjà longuement examiné une feuille de route produit en vous demandant s’il fallait intégrer directement des fonctionnalités de communication personnalisées à votre application web, ou contraindre vos utilisateurs à passer par l’univers fermé de Microsoft Teams, vous n’êtes pas seul. Un mauvais choix d’architecture de communication peut entraîner une dette technique considérable, des factures de licences inattendues et des difficultés d’intégration qui freinent complètement l’adoption. Pour vous aider à y voir plus clair, nous explorons en profondeur les différences fondamentales entre la gestion des jetons émis par l’application dans Azure Communication Services (ACS) et l’authentification des collaborateurs avec Azure AD, ainsi que la manière de faire correspondre ces deux systèmes d’identité distincts lors de la conception d’architectures de communication.

Cet approfondissement fait directement suite à notre dernier épisode de podcast. Si vous souhaitez une analyse audio complète de ces compromis tirés de cas réels, n’hésitez pas à écouter Azure Communication Services vs Teams APIs.

Public visé

Responsables produit qui déploient une messagerie ou des appels clients dans des applications web ou mobiles
Architectes plateforme qui évoluent avec Microsoft 365, Azure AD et Graph
Responsables d’ingénierie qui veulent éviter les mauvaises surprises en matière de conformité ou de licences

Points clés

L’identité conditionne tout. ACS offre une grande souplesse pour les utilisateurs externes ou anonymes ; les API Teams s’alignent sur Azure AD pour les utilisateurs internes, mais l’intégration des invités ajoute des frictions.
La présence fait la différence. Les API Teams exposent une présence riche via Graph ; ACS ne dispose d’aucune présence native dans Teams, il faudra donc prévoir une synchronisation personnalisée ou accepter des compromis.
La parité des fonctionnalités de chat compte. Teams reprend les fonctionnalités de ses clients (fils de discussion, réactions, cartes) ; ACS est épuré et facile à intégrer, mais vous devrez développer vous-même l’expérience utilisateur manquante.
Les limites des appels existent. L’interopérabilité entre ACS et les réunions Teams n’est pas native ; la participation d’invités via Teams nécessite souvent des invitations d’invités Azure AD.
Conformité contre coût. Teams hérite de la conformité de Microsoft 365 (eDiscovery, DLP, conservation à des fins juridiques) mais repose sur les licences E3/E5 et des contraintes premium et de limitation de débit ; ACS fonctionne à l’usage, mais vous gérez vous-même le stockage, la rétention et les audits.
L’hybride est puissant, mais coûteux à exploiter. Prévoyez un middleware pour la correspondance des identités, la transformation des messages, la synchronisation de la présence et l’application des stratégies.

Conseils rapides : choisir ACS, Teams ou l’hybride ?

Choisissez ACS si vous avez besoin d’une montée en charge B2C sans friction, d’une messagerie anonyme ou invitée, d’une rapidité d’intégration avec les SDK mobiles et web, et d’un contrôle fin des coûts, et si vous êtes prêt à gérer le cycle de vie des jetons, le stockage, la rétention et les audits.
Choisissez les API Teams si vos utilisateurs principaux sont des collaborateurs qui ont besoin de la présence, de conversations en fils, de la participation aux réunions et de la conformité intégrée selon les stratégies du locataire, tout en acceptant la charge liée aux licences et aux autorisations Graph.
Optez pour l’hybride lorsque vous devez exposer des conversations externes à des agents internes dans Teams, ou combiner discussions et appels publics avec la conformité et la présence de Teams.

Pièges du terrain (retours d’expérience)

Deux îlots d’identité : jetons ACS d’un côté, objets Azure AD de l’autre, ce qui impose une couche de correspondance.
La taxe liée à l’expérience invité : les invitations d’invités AAD ralentissent les parcours B2C rapides.
Décalage de présence : ACS ne peut pas « voir » qu’un conseiller est occupé dans une réunion Teams.
Gestion des pièces jointes : Teams s’appuie sur OneDrive et SharePoint, tandis qu’ACS utilise souvent des blobs et des URL.
Limites cachées : la limitation de débit de Graph et les points de terminaison premium peuvent devenir contraignants à grande échelle.
Charge de conformité supplémentaire avec ACS : vous êtes responsable du chiffrement, de la rétention, des journaux d’audit et des garanties de région.

Analyse détaillée fonctionnalité par fonctionnalité

Identité et accès

ACS : utilisateurs et jetons émis par l’application, idéal pour les visiteurs de site web et les prestataires ; vous gérez vous-même l’authentification multifacteur, la révocation et l’expiration.
API Teams : authentification unique Azure AD pour les collaborateurs ; les invités nécessitent des invitations, un consentement et un alignement sur les stratégies du locataire.

Présence

API Teams : présence riche et instantanée via Graph à l’échelle du locataire.
ACS : aucune présence native dans Teams ; une télémétrie et une synchronisation personnalisées sont nécessaires.

Chat et expérience utilisateur

API Teams : fils de discussion, réactions, cartes, réponses et fichiers intégrés directement dans la conversation, avec une parité proche de celle de Teams.
ACS : messagerie épurée ; vous devez ajouter vous-même les fils de discussion, la recherche, les emojis personnalisés et la persistance des messages.

Appels/Réunions

ACS : intégrez la voix et la vidéo à votre application ; idéal pour l’accès public ; vous devez diagnostiquer vous-même les chemins média.
Teams APIs : fluides pour les utilisateurs du locataire ; la participation externe implique souvent l’intégration d’invités AAD.

SDK et expérience développeur

ACS : SDK Web, iOS et Android unifiés ; intégration rapide.
Teams/Graph/Bot : puissants, mais courbe d’apprentissage plus raide (autorisations, webhooks, pagination).

Conformité et licences

Teams : eDiscovery, DLP, conservation à des fins juridiques et résidence des données intégrés ; facturation via les licences M365, avec d’éventuelles fonctionnalités premium et limites.
ACS : facturation à l’usage ; vous maîtrisez l’emplacement de stockage, la rétention, le SIEM et les exports d’audit.

Architectures de référence (modèles mentaux)

Portail B2C (ACS d’abord) : chat et appels ACS -> votre stockage et votre rétention -> relais optionnel vers Teams, via bot ou canal, pour les agents.
Helpdesk interne (Teams d’abord) : chat Teams/bot + présence Graph -> SSO du personnel -> prise en charge publique optionnelle via formulaires ou intégration d’invités.
Pont hybride : ACS pour le widget public <-> middleware (mappage d’ID, transformation des messages, synchronisation de la présence, points d’accrochage de conformité) <-> expérience canal/agent Teams.

Liste de contrôle de conception

Définissez l’utilisateur principal : collaborateurs, prestataires ou public.
Décidez de l’emplacement des données et de qui gère la rétention et les audits.
Cartographiez les flux d’identité (SSO, invités, anonymes) avant d’écrire du code.
Validez tôt les exigences de présence : ne les ajoutez pas après coup.
Testez en charge les limites de Graph ainsi que le débit des messages et des appels ACS.
Budgétez les licences et les opérations (middleware, audits, supervision).
Prévoyez un plan de retour arrière et de sortie si vos besoins évoluent au prochain trimestre.

Mini questions fréquentes

Les utilisateurs ACS peuvent-ils rejoindre nativement une réunion Teams ? Pas directement ; prévoyez un pont ou un parcours d’invité AAD.
Ai-je besoin de licences M365 pour les utilisateurs ACS ? Non, ACS est facturé à l’usage.
Les Teams APIs gèrent-elles les utilisateurs externes anonymes ? Pas proprement ; cela nécessite généralement l’intégration d’invités AAD.
La présence est-elle disponible avec ACS ? Pas pour les utilisateurs Teams ; cela nécessite une synchronisation personnalisée ou des contournements.

Étapes d’action

Identifiez vos trois besoins incontournables : (par exemple, chat anonyme, présence Teams, eDiscovery).
Lancez un spike en deux volets : PoC ACS pour le chat public ; PoC Teams pour les agents internes.
Si les deux sont nécessaires, cadrez un MVP de middleware : mappage des identités, relais des messages, synchronisation minimale de la présence et journalisation d’audit.
Alignez le budget : sièges M365 face à la consommation ACS, plus les effectifs d’exploitation pour la conformité.

Pour conclure, concevoir une architecture qui relie efficacement les îlots d’identité entre Azure Communication Services et Azure AD exige une compréhension claire de votre audience. Que vous construisiez un portail grand public ouvert ou un helpdesk d’entreprise interne, placer l’identité au cœur de la réflexion vous évitera bien des maux de tête. Pour approfondir ces choix, écoutez l’épisode complémentaire sur Azure Communication Services vs Teams APIs et abonnez-vous pour rester à la pointe de tout ce qui touche à l’architecture Microsoft 365 et Azure !