L'inscription d'application Azure est le plus grand obstacle pour M365 dans n8n : configuration OAuth2, autorisations (scopes) et consentement de l'administrateur étape par étape.
Quiconque souhaite connecter Microsoft 365 à n8n, pour traiter des mails depuis Outlook, automatiser des messages dans Teams ou synchroniser des fichiers dans SharePoint, se heurte rarement à une limite au niveau du node lui-même. Les nodes Outlook, Teams et SharePoint de n8n sont fonctionnellement bien équipés et couvrent les cas d'usage courants. L'obstacle réel se situe presque toujours un niveau plus bas : au niveau de l'inscription d'application Azure et de la configuration OAuth2, par laquelle n8n obtient tout d'abord l'accès à un compte Microsoft 365. Quiconque franchit cette étape proprement une fois a posé la base pour les trois services en même temps, car Outlook, Teams et SharePoint fonctionnent techniquement dans n8n via la même connexion Microsoft Graph. État : juillet 2026.
Cet article montre quelles opérations offrent les trois nodes Microsoft 365 les plus importants, comment fonctionne l'inscription d'application Azure étape par étape, et à quel endroit la plupart des configurations restent bloquées dans la pratique.
Le Microsoft Outlook Node couvre six ressources : calendrier, contacts, brouillons, rendez-vous, dossiers ainsi que messages y compris les pièces jointes. Pour les messages, outre les opérations habituelles comme envoyer, déplacer ou répondre, "Send and Wait for Response" est également disponible, avec laquelle un workflow se met en pause jusqu'à ce que quelqu'un donne une validation par mail ou fournisse un retour, par exemple sous forme de texte libre ou via un formulaire personnalisé.
Le Microsoft Teams Node apporte des opérations pour les canaux, les messages de canal, les messages de chat et les tâches, y compris également "Send and Wait for Response" pour les messages de chat. Cela permet par exemple de construire des workflows de validation dans lesquels un collaborateur numérique envoie un message dans un canal Teams et attend une réponse avec des boutons avant que le workflow ne continue.
Le Microsoft SharePoint Node est structuré de façon plus légère et couvre les fichiers, les éléments de liste et les listes : télécharger, mettre à jour ou téléverser des fichiers, créer, lire, mettre à jour, supprimer ou fusionner des éléments de liste via upsert, ainsi que récupérer une ou plusieurs listes.
Les trois nodes peuvent fonctionner soit avec des identifiants OAuth2 liés à l'utilisateur, soit, à partir de la version 2, avec un principal de service Microsoft Entra, c'est-à-dire un accès application uniquement sans utilisateur connecté. Pour les locataires Government Cloud, l'URL de base de l'API Microsoft Graph appropriée doit également être sélectionnée dans les identifiants.
Avant que l'un des trois nodes ne fonctionne, n8n a besoin d'une application inscrite dans Azure, ou plus précisément dans le centre d'administration Microsoft Entra. Selon la documentation n8n sur les identifiants Microsoft voici comment cela se déroule :
Un détail de la documentation Microsoft Learn sur l'inscription d'application mérite d'être connu ici : une application déjà inscrite ne peut pas être déplacée ultérieurement vers un autre locataire. Quiconque travaille dans le cadre d'un projet client et inscrit accidentellement l'application dans son propre locataire au lieu du locataire du client doit recréer entièrement l'inscription. Il vaut donc la peine de vérifier brièvement dans quel locataire on est actuellement connecté avant le premier clic sur "New registration".
Dans le choix du type de compte, n8n et Microsoft Learn divergent légèrement dans leur recommandation : n8n recommande l'option la plus large avec des comptes personnels pour sa propre connexion OAuth2, tandis que Microsoft Learn conseille "Single tenant only" pour la plupart des applications, c'est-à-dire une restriction à son propre locataire. Pour une automatisation purement interne à l'entreprise, où seuls les collaborateurs de sa propre organisation doivent obtenir l'accès, l'option Single Tenant plus restrictive est généralement le choix le plus propre, même si n8n montre la variante ouverte comme exemple standard pour des raisons de compatibilité.
De loin le message d'erreur le plus fréquent lors de la première tentative de connexion ne concerne pas l'inscription d'application elle-même, mais l'approbation des autorisations demandées. Dès qu'un compte Microsoft 365 est géré par le service informatique d'une entreprise via Microsoft Entra, le consentement de l'utilisateur seul est souvent insuffisant. Selon la documentation n8n, soit le paramètre "User can consent to apps accessing company data on their behalf" doit être activé pour le locataire, soit un administrateur accorde le consentement séparément.
En pratique, selon Microsoft Learn, cela se déroule ainsi : après l'inscription, l'application ne reçoit d'abord que l'autorisation de base User.Read. Pour toutes les autres autorisations (scopes), par exemple Mail.ReadWrite ou Calendars.ReadWrite, un administrateur se rend sur l'inscription d'application sous "API permissions", clique sur "Grant admin consent" et confirme le consentement pour l'ensemble du locataire. Ce n'est qu'ensuite que le statut de l'autorisation concernée affiche "Granted". Quiconque saute cette étape reçoit souvent, lors du "Connect my account" dans n8n, un message d'erreur indiquant que l'administrateur doit donner son consentement, alors même que le Client ID, le Client Secret et l'URI de redirection sont correctement saisis. En pratique, cela signifie : avant de tester une intégration M365 chez un client, il vaut la peine de passer un bref appel à son service informatique afin que le consentement de l'administrateur soit accordé pour la nouvelle inscription d'application.
Pour l'accès à une boîte aux lettres partagée, la configuration des identifiants Outlook dans n8n propose l'option "Use Shared Inbox" avec un champ supplémentaire pour le User Principal Name ou l'ID de la boîte aux lettres. Pour la variante générique des identifiants Microsoft OAuth2, n8n indique comme autorisations (scopes) typiques Mail.ReadWrite, Mail.Send, Calendars.ReadWrite et Contacts.ReadWrite.
SharePoint nécessite en plus dans les identifiants un champ de sous-domaine, par exemple "tenant123" issu de l'URL tenant123.sharepoint.com. Concernant les autorisations, n8n distingue entre les Application Permissions comme Sites.Read.All et Sites.ReadWrite.All ainsi que les Delegated Permissions comme SearchConfiguration.Read.All et SearchConfiguration.ReadWrite.All. Si seule la mauvaise catégorie d'autorisations est accordée, le node signale généralement une erreur 403, même si l'inscription d'application semble correcte.
Pour les automatisations purement application à application sans utilisateur connecté, par exemple lorsqu'un workflow publie en permanence des messages de canal en arrière-plan, l'authentification par principal de service Microsoft Entra est disponible à partir de la version 2 du node. Elle fonctionne sans connexion interactive et convient particulièrement aux scénarios serveur à serveur.
n8n prend en charge deux moyens pour les identifiants Microsoft OAuth2 de s'authentifier auprès d'Azure. Le Client Secret est la voie la plus simple : une valeur texte est générée sous "Certificates & secrets" et expire après une durée définie, elle doit donc être renouvelée à un moment donné. La variante du certificat est plus complexe mais plus durable. Selon la documentation n8n, un certificat approprié peut être généré avec OpenSSL :
1openssl req -x509 -newkey rsa:2048 -nodes -keyout private-key.pem -out certificate.pem -days 365 -subj "/CN=n8n-microsoft-cert"Important ici : ce doit être une clé RSA. Une erreur fréquente est l'utilisation de clés EC ou Ed25519, qui ne sont pas acceptées par Azure à cette fin. Après la génération, seul le fichier de certificat public est téléversé sous "Certificates" dans l'inscription d'application, tandis que la clé privée et le certificat sont saisis dans n8n. Pour la plupart des configurations petites et moyennes, un Client Secret avec un rappel pour un renouvellement à temps dans le calendrier est tout à fait suffisant.
Une fois ces bases posées, on peut s'appuyer sur les automatisations n8n de NordFlux pour aller plus loin, par exemple pour construire des workflows de validation via Outlook ou Teams, dans lesquels des collaborateurs numériques préparent les tâches et les personnes n'ont plus qu'à prendre la décision d'un clic. Vous gardez ainsi le contrôle sur chaque étape, car chaque autorisation reste visible individuellement et peut être retirée à tout moment.
Dans la plupart des cas, il manque le consentement d'un administrateur aux autorisations demandées. Si le compte est géré par le service informatique d'une entreprise via Microsoft Entra, soit le paramètre du locataire pour le consentement utilisateur doit être activé, soit un administrateur doit accorder explicitement le consentement de l'administrateur sous "API permissions" dans l'inscription d'application.
Oui, techniquement une seule inscription d'application suffit pour les trois services, car ils fonctionnent via la même connexion Microsoft Graph. En pratique, il vaut tout de même la peine d'ajouter délibérément les autorisations (scopes) nécessaires par service, par exemple les autorisations mail pour Outlook et les autorisations sites pour SharePoint, plutôt que de demander dès le départ toutes les autorisations disponibles.
Selon Microsoft Learn, une application déjà inscrite ne peut pas être déplacée vers un autre locataire. Dans ce cas, la seule solution est de recréer l'inscription d'application dans le bon locataire, puis de supprimer l'ancienne inscription mal placée.
Pour la plupart des configurations, un Client Secret suffit, il est plus rapide à mettre en place mais expire après une durée définie et doit être renouvelé. Un certificat avec clé RSA est plus complexe à mettre en place, mais s'avère utile si les identifiants doivent rester valides le plus longtemps possible sans intervention manuelle.
Oui. Pour Outlook, les autorisations (scopes) déléguées de mail et de calendrier comme Mail.ReadWrite ou Calendars.ReadWrite suffisent généralement. SharePoint a besoin en plus d'Application Permissions comme Sites.Read.All ou Sites.ReadWrite.All ainsi que parfois d'autorisations déléguées pour la configuration de recherche, selon les opérations que le node doit exécuter.
Fondateur de NordFlux. Sept ans d'expérience, du web et du SEO jusqu'à l'automatisation à l'échelle d'un groupe, aujourd'hui pragmatique pour les PME et avec une souveraineté des données allemande.
Certifications
Shopware 6 n'a pas de node n8n natif. Voici comment connecter les commandes, les clients et le stock via l'Admin API et le HTTP Request Node.
URI de redirection, scopes et surtout le consentement administrateur pour les comptes professionnels sont l'endroit où la connexion d'Outlook, Teams et SharePoint à n8n échoue le plus souvent. NordFlux prend en charge la mise en place et l'exploitation encadrée de votre intégration Microsoft 365, y compris la coordination avec votre administration informatique. Lors du premier échange, nous clarifions quels services M365 vous souhaitez connecter.