Microsoft 365 avec n8n : Outlook, Teams, SharePoint et les difficultés de l'inscription d'application Azure

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.

Quels nodes Microsoft 365 propose n8n ?

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.

Inscription d'application Azure étape par étape

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 :

• Dans le portail d'inscription des applications Microsoft choisir "Register an application" et attribuer un nom à l'application.
• Sous "Supported account types" choisir l'option "Accounts in any organizational directory ... and personal Microsoft accounts" pour que la connexion OAuth2 fonctionne dans n8n.
• Sous "Web" comme plateforme, copier l'URL de rappel OAuth depuis l'identifiant n8n et la saisir comme URI de redirection.
• Après l'inscription, copier l'Application (client) ID et l'insérer dans n8n comme Client ID.
• Sous "Certificates & secrets" créer un nouveau Client Secret, copier la valeur et la saisir dans n8n comme Client Secret.
• Dans n8n, cliquer sur "Connect my account" et se connecter avec le compte Microsoft 365.

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é.

L'obstacle le plus fréquent : le consentement de l'administrateur pour les comptes professionnels

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.

Particularités spécifiques à chaque service

Outlook

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

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.

Teams

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.

Client Secret ou certificat : quelle variante convient

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 :

```

openssl 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.

Questions fréquentes

Pourquoi n8n ne se connecte-t-il pas à mon compte Microsoft 365 alors que le Client ID et le Secret sont corrects ?

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.

Une seule inscription d'application suffit-elle pour Outlook, Teams et SharePoint en même temps ?

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.

Que faire si j'ai accidentellement inscrit l'application dans le mauvais locataire ?

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.

Client Secret ou certificat, quel est le meilleur choix pour n8n ?

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.

Ai-je besoin d'autorisations différentes pour SharePoint que pour Outlook ?

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.