Les modèles privés ne sont utiles que si vos automatisations peuvent les atteindre. Le parcours générique vérifié de n8n passe par son nœud HTTP Request. Il peut appeler un serveur vLLM compatible avec OpenAI ou un autre déploiement qui expose et accepte réellement POST /v1/chat/completions.
Cet article est un guide opérateur : comment configurer l’appel HTTP, l’authentifier, définir des budgets de délai qui reflètent l’inférence locale mesurée et maintenir le service de modèle hors des réseaux non fiables.
Si vous vous demandez encore si n8n est la bonne couche d’automatisation, commencez par n8n comparé à Zapier et Make. Pour des flux de travail avec agents sur cette plomberie, voir votre premier agent d’IA dans n8n.
Un point de terminaison compatible avec OpenAI joignable depuis Internet sans authentification est un proxy d’inférence ouvert. Quiconque le trouve peut consommer du temps GPU. Avec vLLM, un attaquant peut également atteindre des routes d’inférence et d’exploitation que
--api-keyne protège pas. La fuite de prompts est un risque distinct lié à la journalisation et au contrôle d’accès, et non une propriété automatique de la route de discussion. Limitez l’écoute aux réseaux privés. Exigez une authentification au niveau de la passerelle. Ne transférez pas de port « juste pour une démonstration ».
Ce que signifie ici « compatible avec OpenAI »
Pour n8n, le contrat est étroit :
- L’URL de base pointe vers la racine du serveur ou
/v1, selon ce que le nœud attend. - Les appels de discussion atteignent
/v1/chat/completions(ou le chemin équivalent ajouté par votre nœud). - Le corps de la requête ressemble à une complétion de discussion :
model,messages, et éventuellementtemperature,max_tokens, entre autres. - La réponse renvoie des choix contenant un message que le nœud peut analyser.
Vous n’avez pas besoin d’une parité fonctionnelle avec chaque interface produit OpenAI. Vous avez besoin d’une route de complétion de discussion dont vous avez testé depuis n8n la requête, l’authentification, l’identifiant de modèle et la forme de réponse.
vLLM documente ce mode de serveur compatible avec OpenAI ; d’autres environnements annoncent des formes similaires. Vérifiez la route et un exemple avec curl sur votre installation avant de configurer des flux de production. L’interface est courante, mais les routes, identifiants de modèle, méthodes d’authentification et réponses compatibles peuvent varier selon les produits et les versions.
Le parcours n8n vérifié : HTTP Request
La documentation officielle actuelle de n8n n’établit pas d’URL de base personnalisée pour les identifiants OpenAI ni pour le nœud OpenAI Chat Model. Considérez tout champ de ce type dans une version de n8n ou un nœud communautaire comme propre à cette version tant que vous ne l’avez pas vérifié. Le parcours générique documenté est le nœud HTTP Request, qui donne un contrôle explicite sur la méthode, l’URL, les en-têtes, le corps, l’authentification et les réglages de nouvelle tentative du nœud.
Utilisez un identifiant générique de type bearer ou en-tête au lieu d’intégrer un secret dans le flux. Cet identifiant doit contenir une valeur réellement vérifiée par le service d’inférence ou sa passerelle. Une clé factice sur un point de terminaison limité au LAN n’est pas une authentification.
POST http://10.0.0.20:8000/v1/chat/completions
Content-Type: application/json
Authorization: Bearer <secret>
{
"model": "installer-recommended-local-model",
"messages": [
{ "role": "system", "content": "Classify the ticket. Reply with JSON only." },
{ "role": "user", "content": "{{ $json.body }}" }
],
"temperature": 0
}
Remplacez la chaîne du modèle par l’identifiant exact servi par /v1/models. Si vous utilisez le parcours vLLM local de NVIDIA NemoClaw, reprenez l’identifiant qu’il enregistre depuis le serveur actif ou son profil géré sélectionné. vLLM géré est une option pour les hôtes pris en charge, et non une propriété universelle de chaque installation NemoClaw ; un système Linux générique exige une sélection expérimentale ou explicite du fournisseur. N’inventez pas un nom de checkpoint en vous fiant à votre mémoire.
HTTP Request est également la bonne solution de repli lorsqu’un nœud IA propre à un fournisseur ne documente pas de point de terminaison personnalisé.
Authentification et contrôles réseau qui résistent
Local ne signifie pas non authentifié.
Pour vLLM, --api-key n’est pas un périmètre de sécurité pour l’ensemble du service HTTP. La page de sécurité officielle documente les ensembles de points de terminaison protégés et non protégés, et recommande une isolation réseau accompagnée d’un proxy inverse lorsque l’exposition est nécessaire (recommandations de sécurité vLLM). Une clé API sur les routes d’inférence ne prouve pas que chaque route rejette le trafic non authentifié.
Base de référence obligatoire : liez vLLM uniquement à l’interface de bouclage, à un réseau de conteneurs ou de cluster, ou à une interface privée protégée par une politique de pare-feu qui n’autorise que le proxy ou la charge de travail n8n. Placez Caddy, nginx, Traefik ou une passerelle contrôlée équivalente devant le service lorsque plusieurs hôtes doivent se connecter. Terminez TLS lorsque le parcours n’utilise pas déjà un réseau chiffré fiable, authentifiez chaque route exposée, limitez le débit et la taille des requêtes, puis n’autorisez que les chemins nécessaires. n8n communique avec le proxy ; les clients n’atteignent pas directement vLLM.
Utilisez --api-key de vLLM comme contrôle supplémentaire pour les points de terminaison d’inférence pris en charge, et non comme remplacement du proxy ou du pare-feu. Stockez tous les identifiants dans les identifiants n8n ou un magasin de secrets approuvé, jamais dans des champs de flux en clair exportables vers Git.
À ne pas faire :
- Lier
0.0.0.0à une adresse IP WAN domestique ou professionnelle « temporairement ». - Partager une URL de tunnel dans Slack.
- Réutiliser une clé OpenAI personnelle comme « mot de passe » pour un serveur local qui ne la vérifie jamais. Si le serveur ignore
Authorization, la clé ne protège rien.
Les prompts envoyés à un point de terminaison local quittent toujours l’hôte n8n et peuvent être journalisés par le serveur d’inférence, le proxy et l’historique d’exécution n8n. L’hébergement local réduit la conservation par un cloud tiers ; il ne supprime ni la journalisation, ni les captures d’écran, ni l’accès des opérateurs. Classez les textes clients comme des données potentiellement sensibles ou à caractère personnel selon votre politique et le droit applicable, puis vérifiez les contrôles de conservation et d’accès.
Pour une hygiène d’intégration plus large, notamment des identifiants à portée limitée, des comptes de service et des pistes d’audit, utilisez les modèles de connexion sûre de l’IA.
Délais d’attente et inférence lente
La latence des modèles locaux varie fortement selon le modèle, la longueur du prompt, le matériel, la concurrence et l’état de démarrage à froid. Le délai effectif d’un nœud n8n dépend également du nœud et de la version installée. Pour le nœud HTTP Request, le délai documenté couvre l’attente des en-têtes de réponse ou du début du corps ; il ne prouve pas qu’une génération diffusée en continu ou longue soit limitée de bout en bout. Une valeur copiée d’un tutoriel peut donc faire échouer une tâche saine ou laisser une autre couche sans limite claire.
Définissez les délais volontairement :
- Mesurez un appel à froid et un appel à chaud avec curl depuis l’hôte n8n.
- Réglez le délai de réponse initiale du nœud au-dessus du p95 mesuré, avec une marge justifiée pour les pics de charge.
- Alignez les limites du flux, du proxy, du client et du serveur d’inférence sur le budget complet de génération.
- Préférez des prompts plus courts et un
max_tokensplus petit pour la classification ou le routage ; réservez les longues générations aux brouillons pouvant continuer de manière asynchrone.
Si une étape dépasse régulièrement quelques minutes, elle devrait peut-être être placée dans une file avec continuation asynchrone plutôt que dans une réponse webhook synchrone.
Testez depuis l’espace de noms réseau du processus n8n, et pas seulement depuis votre ordinateur. Un n8n conteneurisé ne peut pas atteindre
localhostsur l’hôte, sauf si vous publiez le port du modèle dans ce réseau. Utilisez le nom du service Docker, l’adresse IP de la passerelle de l’hôte ou une adresse LAN que le conteneur peut atteindre.
Liste de contrôle de l’URL de base
Avant de considérer l’identifiant comme prêt pour la production :
| Contrôle | Condition de réussite |
|---|---|
| Accessibilité | L’environnement n8n atteint la route de santé documentée et /v1/models authentifié sans quitter le réseau privé |
| Chemin | /v1/chat/completions réussit avec une petite charge utile |
| Authentification | L’inférence non authentifiée est rejetée ; aucune route vLLM non protégée n’est accessible hors de la limite privée prévue |
| ID du modèle | La chaîne exacte correspond à celle annoncée par le serveur |
| TLS | Obligatoire si le parcours traverse des réseaux non fiables |
| Journalisation | La journalisation des prompts et réponses est volontaire, avec une conservation limitée |
| Repli | Le flux a un comportement clair lorsque le point de terminaison est indisponible |
| Délai | Les limites de réponse initiale et de bout en bout reflètent les mesures depuis l’environnement n8n |
Le comportement face à un point de terminaison indisponible doit être explicite : nouvelle tentative avec temporisation, routage vers une file de vérification humaine ou échec visible de l’exécution. Ne basculez pas silencieusement vers une API publique avec une posture de protection des données différente, sauf si ce parcours est documenté et approuvé.
Ne jamais exposer sans passerelle
La règle est simple : n’exposez pas directement vLLM à un réseau non fiable. Sa clé API ne protège pas tout le service HTTP. Isolez le réseau et n’exposez que les chemins requis par l’intermédiaire d’une passerelle authentifiée et limitée en débit.
Modèles acceptables :
- Interface de bouclage ou réseau Docker uniquement, avec n8n sur le même hôte ou réseau superposé.
- LAN + liste d’autorisation du pare-feu pour le proxy, l’identité de la charge de travail n8n ou son adresse IP ; vérifiez les règles depuis un hôte refusé.
- VPN ou réseau maillé Tailscale/ZeroTier ; aucune écoute WAN.
- Proxy inverse avec authentification forte, TLS et limites de débit lorsque plusieurs clients de confiance doivent être servis.
Modèles inacceptables :
- Liaison WAN non authentifiée.
- Démonstration « authentification plus tard » sur de vraies données.
- Partage du même point de terminaison non authentifié avec tous les ordinateurs sur le Wi-Fi invité.
Si vous construisez une infrastructure privée combinant inférence locale, orchestration n8n et étape d’agent, gardez l’URL du modèle comme contrat interne. Hermes et d’autres environnements peuvent utiliser le même service privé. Lorsque n8n invoque Hermes, choisissez le serveur API authentifié si n8n a besoin du résultat, ou l’adaptateur webhook HMAC pour l’entrée d’événements et la diffusion configurée par Hermes. Cette distinction est traitée dans n8n → Hermes : appel API ou webhook d’événement.
Un parcours minimal pour une assistance privée
Flux illustratif que vous pouvez mettre en œuvre sans inventer de chiffres de performance :
- Le webhook du ticket arrive dans n8n.
- Validez et masquez les champs.
- HTTP Request appelle le point de terminaison privé
/v1/chat/completionspour obtenir un JSON de classification. - Le nœud Switch effectue le routage selon le libellé.
- Les brouillons qui quittent le périmètre de l’entreprise attendent une validation humaine (idempotence et validations humaines).
Cela suffit pour prouver que le point de terminaison local mérite sa place avant d’ajouter des agents plus riches.
Vérifications à effectuer le jour de la modification
Les interfaces produit et les noms de champs d’identification évoluent. Le jour où vous livrez ou actualisez ce flux :
- Confirmez la documentation actuelle de la route compatible avec OpenAI de votre serveur d’inférence.
- Confirmez que l’identifiant et la configuration du nœud HTTP Request envoient toujours l’authentification, les en-têtes et le JSON brut requis.
- Relancez curl et une exécution de test n8n avec une charge utile hors production.
- Confirmez que l’écouteur est toujours privé (
ss/lsof, règles de pare-feu, aucun tunnel inattendu), qu’une requête d’inférence non authentifiée échoue et que les points de terminaison non protégés documentés par vLLM ne sont pas accessibles au-delà de la limite externe.
Les points de terminaison locaux compatibles avec OpenAI permettent à n8n d’utiliser une inférence privée sans réécrire le graphe d’automatisation. Le travail ne consiste pas à élaborer un prompt astucieux. Il s’agit de traiter l’inférence comme toute autre API interne : authentifiée à la limite exposée, mesurée, journalisée volontairement et inaccessible aux inconnus.
