Connecter Azure OpenAI à n8n : credentials, déploiements et premiers workflows

Azure OpenAI donne accès aux modèles d'OpenAI — GPT-4o, GPT-4.1, la famille o-series, les embeddings — mais servis depuis l'infrastructure Microsoft Azure, dans la région de votre choix, sous le contrat et la gouvernance de votre organisation. Pour beaucoup d'entreprises européennes, c'est la seule voie validée par la DSI pour utiliser ces modèles en production. La bonne nouvelle : n8n gère Azure OpenAI nativement, avec un credential dédié et des nodes de chat et d'embeddings prêts à l'emploi. La subtilité qui fait trébucher tout le monde au premier essai : sur Azure, on n'appelle pas un modèle par son nom, on appelle un déploiement que vous avez créé et nommé vous-même. Ce guide reprend le parcours complet, du portail Azure au premier agent IA dans n8n.

Pourquoi Azure OpenAI plutôt qu'OpenAI direct

Si vous utilisez déjà l'API OpenAI classique dans n8n (notre guide OpenAI + n8n couvre ce cas), qu'apporte le détour par Azure ? Quatre choses, toutes orientées entreprise :

• Résidence des données par région. Vous choisissez où tourne le modèle : une ressource créée dans une région européenne traite vos prompts en Europe. Pour des données clients, RH ou santé, c'est souvent la condition sine qua non posée par le juridique.
• Gouvernance et identité. L'accès à la ressource s'administre comme n'importe quel service Azure : Azure AD (Entra ID), rôles RBAC, politiques réseau, journaux d'audit. La DSI garde la main sur qui consomme quoi.
• Facturation Azure unifiée. La consommation apparaît sur votre facture Azure existante, avec les outils de suivi de coûts du portail — pas de carte bancaire à déclarer sur un compte OpenAI séparé.
• Engagements contractuels. SLA, conditions d'entreprise et engagement de Microsoft à ne pas utiliser vos données pour entraîner les modèles s'inscrivent dans un cadre contractuel que les grandes organisations connaissent déjà.

L'investissement en vaut la peine au-delà de la conformité : l'étude « Generative AI at Work » d'Erik Brynjolfsson, Danielle Li et Lindsey Raymond (NBER 2023, publiée ensuite dans The Quarterly Journal of Economics — voir sur Google Scholar), menée en conditions réelles auprès d'agents de support client, mesure un gain de productivité d'environ 14 % en moyenne avec un assistant IA génératif, les gains les plus forts allant aux agents les moins expérimentés. Autrement dit, ce sont précisément les workflows d'assistance et de support — le terrain de jeu naturel de n8n — qui ont le plus à gagner à débloquer ces modèles dans un cadre que l'entreprise accepte.

Étape 1 : créer la ressource et un déploiement dans Azure

Tout se passe dans le portail Azure et Azure AI Foundry (le nouveau nom du studio qui regroupe les services IA de Microsoft).

1. Dans le portail Azure, créez une ressource Azure OpenAI : choisissez l'abonnement, un groupe de ressources, la région (c'est elle qui détermine où résident les traitements) et un nom de ressource. Ce nom compte : c'est lui que n8n vous demandera.
2. Ouvrez la ressource dans Azure AI Foundry et allez dans la section des déploiements.
3. Créez un déploiement : sélectionnez un modèle (GPT-4o par exemple), donnez-lui un nom de déploiement et validez le type de déploiement et le quota proposés.

C'est ici que se joue la particularité d'Azure : le nom de déploiement remplace le nom de modèle dans tous les appels API. Vous pouvez appeler votre déploiement gpt-4o pour rester lisible, ou prod-support-chat pour refléter l'usage — dans les deux cas, c'est cette chaîne exacte que n8n enverra à l'API. Un modèle non déployé est invisible pour l'API, même s'il existe au catalogue.

Récupérez ensuite, dans la section « Clés et point de terminaison » de la ressource, deux informations : l'endpoint (de la forme https://<nom-de-ressource>.openai.azure.com/) et l'une des deux clés API.

Étape 2 : créer le credential « Azure Open AI » dans n8n

Dans n8n, ouvrez Credentials → Add credential → Azure Open AI. Trois champs :

Champ	Valeur
Resource Name	Le nom de votre ressource Azure (la partie <nom-de-ressource> de l'endpoint)
API Key	L'une des deux clés de la ressource
API Version	La version d'API Azure OpenAI (format date, ex. celle indiquée dans la doc ou les exemples du portail)

Deux pièges classiques : saisir l'URL complète de l'endpoint dans « Resource Name » (n8n n'attend que le nom, il reconstruit l'URL lui-même), et laisser une api-version obsolète (l'API Azure est versionnée par dates, et certaines fonctionnalités récentes exigent une version récente).

Comme toujours, la clé ne doit vivre que dans le gestionnaire de credentials — jamais dans un node Code ou une variable en clair. Les bons réflexes (rotation, environnements séparés, moindre privilège) sont détaillés dans notre guide sur la sécurisation des credentials API dans n8n.

Étape 3 : le node Azure OpenAI Chat Model

Le node Azure OpenAI Chat Model est un sous-node LangChain : il ne s'exécute pas seul, il se branche comme modèle de langage sur un node parent — AI Agent, Basic LLM Chain, Text Classifier, Information Extractor…

Chat Trigger ──▶ AI Agent ──▶ Réponse
                   │
                   ├── Azure OpenAI Chat Model  (credential Azure Open AI)
                   │     Model (Deployment) Name : prod-support-chat
                   └── Outils (HTTP Request, Vector Store…)

1. Ajoutez un AI Agent (ou une Basic LLM Chain pour un appel simple sans outils).
2. Attachez un Azure OpenAI Chat Model comme modèle, avec votre credential.
3. Dans le champ modèle, saisissez le nom de votre déploiement — pas le nom du modèle au catalogue. C'est la différence clé avec le node OpenAI classique, qui liste les modèles publics.

À partir de là, tout ce qui s'applique aux agents n8n s'applique ici : mémoire, outils, prompts système — notre guide complet du node AI Agent détaille la mécanique. Et si votre workflow utilisait déjà Claude ou GPT via les nodes standards, la migration se résume souvent à remplacer le sous-node de chat model et à ajuster le nom de modèle en nom de déploiement.

Embeddings Azure OpenAI pour le RAG

Le RAG suit la même logique. Déployez un modèle de la famille text-embedding dans votre ressource (c'est un déploiement séparé, avec son propre nom), puis utilisez le node Embeddings Azure OpenAI avec le même credential. Il se branche sur les nodes de vector store de n8n (indexation comme interrogation) exactement comme son équivalent OpenAI classique.

L'intérêt en entreprise est évident : les documents que vous vectorisez — base de connaissances interne, contrats, tickets — ne quittent pas la région Azure choisie, ni à l'indexation ni à la recherche. Attention à une seule cohérence : utilisez le même déploiement d'embeddings pour indexer et pour interroger, sinon les vecteurs ne sont pas comparables et la recherche renvoie du bruit.

Erreurs courantes et leur diagnostic

Trois erreurs reviennent sans cesse avec Azure OpenAI dans n8n :

• 404 DeploymentNotFound : le nom saisi dans le node ne correspond à aucun déploiement de la ressource. Vous avez probablement saisi le nom du modèle (« gpt-4o ») au lieu du nom du déploiement, ou le déploiement vit dans une autre ressource que celle du credential. Vérifiez la liste des déploiements dans Azure AI Foundry et copiez le nom à l'identique.
• api-version invalide ou non supportée : le credential pointe vers une version d'API inexistante ou trop ancienne pour la fonctionnalité demandée. Reprenez une version documentée par Microsoft (format date) et retestez.
• 429 : quota de tokens par minute dépassé : sur Azure, la limite de débit se règle par déploiement, sous forme de quota de tokens par minute alloué à la création. Un workflow à fort volume peut saturer son déploiement alors que la ressource a encore de la marge. Deux leviers : augmenter le quota alloué au déploiement dans Azure AI Foundry, et rendre le workflow tolérant avec des retries et du lissage — notre guide sur la gestion des rate limits des API d'IA donne les patterns n8n concrets (retry avec backoff, files d'attente, batching).

Bonnes pratiques en production

• Un déploiement par usage. Plutôt qu'un déploiement unique partagé par tous les workflows, créez un déploiement par cas d'usage (chatbot support, extraction de documents, embeddings RAG…). Chacun a son quota de tokens par minute : un pic sur le chatbot ne prive plus l'extraction de factures, et les 429 se diagnostiquent en un coup d'œil.
• Nommez les déploiements pour les humains. prod-support-gpt4o dit ce qu'il fait ; le jour où vous changez de version de modèle sous-jacent, le nom de déploiement — donc la config n8n — peut ne pas bouger.
• Suivez les coûts des deux côtés. Azure agrège la consommation dans sa facturation, mais ne dit pas quel workflow n8n consomme quoi. Loggez les usages par exécution côté n8n : notre méthode de suivi du coût des appels IA par workflow s'applique telle quelle à Azure OpenAI.
• Prévoyez un plan B. Même en entreprise, un déploiement peut saturer ou une région connaître un incident. Le pattern du fallback multi-fournisseurs fonctionne aussi en intra-Azure : un second déploiement (autre région, autre modèle) en secours du premier.

En résumé

• Azure OpenAI sert les modèles OpenAI depuis votre abonnement Azure : résidence des données par région (dont l'Europe), gouvernance Azure AD, facturation et contrats unifiés.
• Créez la ressource puis un déploiement dans Azure AI Foundry : c'est le nom du déploiement, pas le nom du modèle, que n8n utilisera.
• Le credential Azure Open AI de n8n demande trois champs : resource name (sans l'URL complète), clé API, api version.
• Branchez le node Azure OpenAI Chat Model sur un AI Agent ou une Basic LLM Chain, et le node Embeddings Azure OpenAI pour le RAG.
• Les trois erreurs classiques — 404 DeploymentNotFound, api-version invalide, 429 de quota — se résolvent côté Azure (noms, versions, quotas par déploiement) et côté n8n (retries, lissage).