L’ancienne authentification EAT n’est plus prise en charge depuis le 8 juin 2026 : migrez votre fournisseur vers les jetons Microsoft Entra ID, puis validez séparément le rendu de la carte, le jeton et le résultat de l’action. Cette procédure convient aux équipes qui testent leur propre service dans une portée Microsoft 365 autorisée ; une boîte de réception temporaire ne remplace pas un utilisateur organisationnel admissible. (État de la migration)
Les développeurs responsables d’une intégration existante peuvent suivre les contrôles de configuration. Les ingénieurs QA peuvent distinguer un message reçu d’une carte visible ou d’une action réussie. Les équipes qui administrent un environnement Microsoft 365 peuvent préparer la recette avec des destinataires et des autorisations approuvés.
Dernière mise à jour : 25 octobre 2026. Vérification des dates et exigences à partir des pages Microsoft Learn sur la migration vers les jetons Entra ID, le tableau de bord des développeurs Actionable Messages et les exigences de sécurité.
Avant la migration : isoler l’ancien mode des symptômes
La migration n’est pas un simple changement de modèle de courriel. Une intégration Actionable Messages comprend plusieurs maillons : enregistrement du fournisseur, identité d’expédition, construction du message, prise en charge côté destinataire, requête au point de terminaison d’action et vérification de l’authentification par le serveur. Un défaut visible en aval ne révèle donc pas à lui seul l’étape en panne.
Microsoft indique que la transition de l’EAT vers l’authentification par jeton Microsoft Entra ID a été achevée le 8 juin 2026 et que l’ancien mécanisme n’est plus pris en charge. Si votre service dépend encore de cette authentification, la priorité est de migrer sa configuration, pas de tenter de rétablir l’ancien fonctionnement. La date et l’état de prise en charge sont précisés dans la documentation de migration Microsoft.
Avant toute modification, consignez les faits observés sans les fusionner :
| Observation | Ce qu’elle établit | Ce qu’elle ne démontre pas |
|---|---|---|
| Le message arrive dans la boîte de réception | Le chemin d’envoi et de réception a fonctionné pour ce message et ce destinataire | Que la carte est admissible ou que le jeton sera accepté |
| Le message arrive, mais la carte ne s’affiche pas | La réception a eu lieu ; le problème se situe dans le rendu ou les conditions d’affichage | Que le point de terminaison d’action est en panne |
| La carte s’affiche et le bouton déclenche une requête | Le client a présenté une action et une requête a été émise | Que le serveur a validé le jeton ou autorisé l’opération |
| Le serveur accepte le jeton, puis refuse l’opération | Le contrôle d’authentification a pu réussir | Que la règle métier autorise cette action |
Cette séparation empêche une confusion fréquente : « le courriel fonctionne » et « l’action est sécurisée » sont deux conclusions différentes. Les preuves doivent correspondre à chaque couche, plutôt qu’à une impression générale de réussite.
À retenir : l’apparition d’un bouton est une preuve d’affichage, pas une preuve de validation du jeton. Le résultat de la requête doit être vérifié dans le système qui reçoit et traite l’action.
Première étape : préparer une base de recette réversible
Avant de toucher à la configuration, relevez les éléments actuellement utilisés par l’intégration : l’enregistrement du fournisseur, les URL d’action, l’identité d’expédition, les paramètres d’authentification et le comportement serveur à la réception d’une requête. Pour chaque élément, indiquez s’il est géré par l’équipe de développement, l’équipe de messagerie ou l’administrateur de l’environnement. Cette répartition évite de faire porter à l’équipe applicative une erreur qui relève des droits ou de l’enregistrement.
Établissez ensuite une base de référence exploitable. Elle peut inclure la configuration connue, un message de test représentatif, le journal de la requête reçue et le résultat attendu dans l’application. Ne conservez pas de jeton actif dans un compte rendu ou une capture destinée à être partagée : consignez plutôt les contrôles effectués et les identifiants de suivi non sensibles.
La recette doit se dérouler dans un environnement isolé, avec un destinataire autorisé à tester votre propre service. Confirmez au préalable que cet utilisateur relève bien de la portée déclarée pour l’enregistrement. Une adresse jetable ou un transfert vers une adresse personnelle ne devient pas, par ce seul fait, un utilisateur de test Microsoft 365 admissible. Les conditions d’enregistrement et de test sont décrites dans le guide du tableau de bord Actionable Messages.
Pour éviter de confondre une régression fonctionnelle avec un changement de configuration, définissez des résultats attendus distincts : message reçu, carte rendue, action envoyée, jeton accepté et effet métier constaté. Précisez également les cas de refus que l’application doit traiter. Une action refusée par la règle métier peut être un résultat correct, même lorsque l’authentification a réussi.
Deuxième étape : migrer l’enregistrement vers Microsoft Entra ID
La migration doit suivre le parcours officiel applicable à votre fournisseur. En pratique, l’équipe doit vérifier l’enregistrement de l’application, les identifiants configurés, les autorisations API nécessaires et les paramètres d’authentification associés à l’enregistrement Actionable Messages. La documentation Microsoft décrit les étapes et les paramètres concernés ; il faut s’y référer plutôt que recopier une configuration issue d’un autre environnement.
Le changement doit être cohérent des deux côtés. D’un côté, l’application et l’enregistrement doivent désigner les paramètres attendus pour l’intégration. De l’autre, le serveur qui reçoit l’action doit reconnaître et vérifier le jeton conformément aux exigences Microsoft. Une configuration visible dans un tableau de bord ne prouve pas que le service sait valider une requête reçue.
Examinez aussi la portée du fournisseur et la portée de test. Les règles peuvent différer selon qu’il s’agit d’un utilisateur de test, d’une organisation ou d’une portée plus large ; les exigences d’approbation doivent être confirmées dans la documentation à jour et dans votre environnement. N’élargissez pas la portée de publication uniquement pour faire disparaître un échec de recette. Une portée trop permissive peut masquer le vrai problème et exposer l’intégration à des utilisateurs non prévus.
Enfin, gardez une trace de la configuration antérieure et de la nouvelle version. Cela ne rend pas l’ancien mode à nouveau pris en charge : la trace sert à comprendre les changements et à revenir sur une modification de configuration récente si celle-ci introduit un défaut. Le plan de retour arrière ne doit jamais supposer que l’ancienne authentification EAT reste une solution de secours valide.
Troisième étape : valider le jeton avant le parcours utilisateur
Avant d’envoyer une campagne de messages de recette, testez le traitement serveur de manière contrôlée. Le point de terminaison doit appliquer les contrôles de jeton adaptés à ce service et à cette requête. Microsoft précise les exigences de sécurité propres aux Actionable Messages ; elles doivent guider la vérification, et non une comparaison approximative de chaînes ou la simple présence d’un en-tête.
La documentation générale sur la validation des jetons d’accès Microsoft Entra ID aide à comprendre pourquoi un jeton doit être vérifié selon son contexte. Pour une Actionable Message, la référence décisive reste toutefois les exigences de sécurité spécifiques à la fonctionnalité. Les contrôles exacts doivent être appliqués selon ces instructions et la configuration déclarée pour le fournisseur.
Préparez des cas distincts, sans utiliser de requêtes non autorisées contre un service réel :
- Jeton attendu et requête autorisée : la validation doit permettre l’exécution du traitement prévu.
- Jeton invalide ou altéré : le serveur doit refuser l’authentification et ne pas déclencher l’effet métier.
- Contexte ou autorisation inadapté : le serveur doit refuser la requête selon les contrôles applicables.
- Authentification valable, opération interdite : le service doit distinguer un refus métier d’un échec d’authentification.
Ces résultats doivent être visibles dans les journaux techniques sans y exposer de secrets. Il est utile de relier chaque requête à un identifiant de corrélation, à l’heure de test et à un résultat synthétique : contrôle du jeton accepté ou refusé, puis décision métier. Ne consignez pas le jeton complet dans les tickets, les journaux partagés ou les échantillons de preuve.
Le critère de réussite n’est donc pas « la requête HTTP est arrivée ». Il faut démontrer que la requête a été reçue, que le jeton a passé les contrôles pertinents et que l’application a appliqué la décision métier attendue. Si l’un de ces résultats manque, notez précisément l’étape non prouvée au lieu de déclarer la chaîne valide.
Quatrième étape : tester l’arrivée et l’affichage séparément
Une fois la configuration et le traitement serveur examinés, envoyez un message de test du service concerné à un destinataire qui répond aux critères de l’environnement. Conservez le message et ses en-têtes utiles dans un espace de test approuvé, en retirant les données sensibles avant tout partage. Cette preuve d’arrivée est pertinente pour le chemin de messagerie, mais elle ne valide ni la carte ni le jeton.
Si le courriel est présent mais que la carte manque, vérifiez l’admissibilité du destinataire, l’état de l’enregistrement du fournisseur, la structure du message et la compatibilité du client utilisé. Comparez le résultat avec les indications du tableau de bord et de la documentation officielle. Ne commencez pas par remplacer l’adresse de réception : un changement d’adresse ne corrige pas une portée d’enregistrement, une configuration de fournisseur ou une limite du client.
Lorsque la carte s’affiche, vérifiez que son action correspond à la fonction prévue et que le contrôle côté serveur donne le résultat attendu. Testez également les cas de refus définis plus tôt : une interface qui permet une action ne doit pas pouvoir contourner l’autorisation serveur. La validation de l’interface et celle du point de terminaison restent des contrôles distincts, même lorsqu’elles sont exécutées dans la même session de test.
Pour choisir le destinataire et la preuve à conserver, appliquez les conditions suivantes :
- Si l’objectif est de vérifier l’admissibilité Microsoft 365, utilisez un compte organisationnel de test autorisé dans la portée requise ; n’utilisez pas une boîte temporaire comme substitut.
- Si l’objectif est seulement de vérifier qu’un message de test est reçu, choisissez une boîte de recette maîtrisée et conservez une preuve de réception. Cette preuve ne vaut pas validation d’une carte Actionable Message.
- Si l’objectif est de vérifier l’action, utilisez un destinataire admissible, puis contrôlez la requête et sa validation serveur. Si l’équipe ne peut pas observer le résultat du serveur, la recette reste incomplète.
- Si la carte ne s’affiche pas, revenez aux contrôles d’enregistrement, de portée et de client avant d’accuser le mécanisme de réception.
Une boîte temporaire peut parfois servir d’outil auxiliaire pour isoler une réception de courriel, à condition que son usage soit autorisé et adapté au test. Elle ne prouve pas l’admissibilité d’un compte organisationnel, la bonne configuration de l’application ni la sécurité du point de terminaison.
Avant le déploiement : critères de passage et preuves
Le passage à une portée plus large doit suivre le circuit d’approbation de l’équipe. Avant cette étape, vérifiez que les tests prévus couvrent la réception, l’affichage, les actions et les refus attendus. Réexaminez les autorisations, l’identité d’expédition et les URL d’action dans l’environnement concerné. Une recette menée dans un environnement isolé ne prouve pas automatiquement que la configuration de production est identique.
Conservez un dossier de recette assez précis pour permettre une revue ultérieure : version de configuration, portée du test, destinataire autorisé utilisé, échantillon de message expurgé, résultats des contrôles de jeton et réponse fonctionnelle du point de terminaison. Indiquez aussi les limites observées, notamment les clients non testés ou les portées qui n’ont pas été approuvées.
| Preuve conservée | Ce qu’elle permet de conclure | Limite à signaler |
|---|---|---|
| Message reçu et échantillon expurgé | Le message de test a atteint la boîte utilisée | Ne prouve pas l’affichage de la carte ni l’authentification |
| Capture ou observation du rendu | La carte est visible dans le contexte testé | Ne prouve pas que le serveur accepte le jeton |
| Journal serveur expurgé et résultat du contrôle | Le point de terminaison a appliqué le contrôle documenté | Ne prouve pas, à lui seul, que toutes les opérations métier sont correctes |
| Résultat métier associé à la requête | L’action a produit le résultat prévu ou un refus attendu | Ne garantit pas une réception générale ni la compatibilité de tous les clients |
Ces preuves attestent uniquement des chemins et des comptes testés. Elles ne constituent ni une garantie de livraison en production ni une validation universelle de tous les destinataires. Si Microsoft modifie les exigences d’authentification, les portées admissibles ou la prise en charge des clients, reprenez les contrôles concernés avant de réutiliser le dossier comme référence.
Questions fréquentes sur la recette après la migration
Que faut-il corriger en premier après la désactivation de l’EAT ?
Identifiez d’abord le mode d’authentification de l’intégration et confirmez la configuration du fournisseur. Migrez ensuite vers les jetons Microsoft Entra ID en suivant le parcours officiel. En parallèle, classez séparément les symptômes de réception, de rendu et d’action : un courriel absent ne se diagnostique pas comme une carte absente, et aucun des deux ne démontre un défaut de validation serveur.
Comment tester l’authentification avec un utilisateur de test ?
Sélectionnez un utilisateur autorisé qui correspond à la portée enregistrée, puis vérifiez l’application, les autorisations et l’enregistrement du fournisseur selon la documentation en vigueur. Envoyez un message de votre propre service et contrôlez le rendu ainsi que le traitement serveur. Une adresse temporaire peut aider à observer une réception si le test le permet, mais elle ne remplace pas un compte organisationnel admissible.
Le message est arrivé, mais la carte ne s’affiche pas : quelle est la suite ?
Ne confondez pas preuve de réception et preuve de rendu. Confirmez d’abord l’admissibilité du destinataire et l’état de l’enregistrement dans le tableau de bord des développeurs Actionable Messages. Examinez ensuite le message et le client utilisé à la lumière des limites documentées. Si ces points ne suffisent pas, conservez les observations et poursuivez le diagnostic sans conclure que l’adresse est seule en cause.
Comment confirmer qu’un bouton a été validé côté serveur ?
Suivez la requête jusqu’au point de terminaison et vérifiez les résultats de validation du jeton, sans enregistrer le jeton lui-même. Comparez le cas autorisé avec les refus prévus pour les jetons invalides, les autorisations inadaptées et les interdictions métier. Une requête émise ou un bouton visible ne suffit pas : il faut une preuve du contrôle serveur et du résultat fonctionnel associé.
Pour isoler un simple contrôle de réception, une boîte temporaire peut être envisagée uniquement si elle convient au scénario et si son usage est autorisé. Elle ne remplace jamais les exigences Microsoft 365 relatives au compte de test, ni la migration vers les jetons Microsoft Entra ID, ni les vérifications du point de terminaison. Si une adresse de recette séparée aide à éviter de mélanger des essais et le courrier professionnel, BoxTmp peut servir d’option complémentaire : son rôle se limite alors à l’observation de courriels, pas à la preuve d’une authentification ou d’une action sécurisée. Consultez le guide de vérification de l’arrivée des courriels et les parcours de confidentialité pour séparer les usages avant de choisir votre dispositif de test.
Questions fréquentes
Que faut-il modifier en premier après l’arrêt de l’authentification EAT ?
Commencez par identifier le mode d’authentification réellement configuré pour votre fournisseur Actionable Messages. Ne corrigez pas d’abord le modèle de courriel ou l’adresse du destinataire : consignez séparément les échecs de réception, d’affichage et d’action, puis préparez la migration du fournisseur vers les jetons Microsoft Entra ID selon la procédure officielle.
Comment tester les jetons Microsoft Entra ID avec un utilisateur de test ?
Utilisez un destinataire autorisé qui correspond à la portée de test déclarée pour votre fournisseur, puis vérifiez que l’enregistrement, l’application et les autorisations sont configurés conformément aux consignes Microsoft. Envoyez un message de votre propre service et observez séparément le rendu de la carte et le traitement serveur. Une adresse temporaire ne remplace pas un compte organisationnel admissible.
Le courriel est reçu, mais la carte Actionable Message n’apparaît pas : que vérifier ?
La réception seule ne prouve pas que le destinataire est admissible ni que la carte doit être affichée. Contrôlez la portée de l’enregistrement du fournisseur, son état dans le tableau de bord, la configuration du message et la prise en charge du client utilisé. Gardez la preuve de réception, mais classez le rendu comme un contrôle distinct tant que la carte n’est pas visible.
Comment savoir si le bouton a passé la validation côté serveur ?
Un bouton visible ou une requête émise ne suffit pas. Dans un environnement autorisé, vérifiez que le serveur contrôle le jeton reçu selon les exigences Microsoft, puis comparez le résultat avec des cas de jeton invalide, de droits inadaptés et de refus métier. Seule une validation réussie suivie du résultat attendu démontre que l’action a franchi les contrôles prévus.
Préparez une adresse distincte pour vos prochaines vérifications à faible risque
Ouvrez l’espace de travail pour copier l’adresse, suivre le compte à rebours et lire l’e-mail de vérification sur la même page. Pour les comptes importants, utilisez toujours une adresse e-mail permettant une récupération à long terme.
Créer un e-mail temporaire