Nous développons actuellement une intégration personnalisée (nœuds n8n, informations d’identification de produit et workflows) et aimerions la publier sur la Place de marché n8n.
Pourriez-vous nous guider sur les points suivants ?
Quel est le processus et quels sont les critères de publication d’un nœud personnalisé sur la Place de marché n8n ?
Y a-t-il des modèles pour créer le README et la documentation/guide utilisateur ?
Quelles sont les étapes de publication de la documentation (nous avons trouvé un référentiel n8n-docs, devons-nous soumettre la documentation ici) ?
Y a-t-il une documentation officielle ou une liste de contrôle à suivre avant de soumettre le nœud ?
Veuillez partager également la procédure correspondante pour les Workflows.
Si vous pouviez partager les directives ou ressources pertinentes, ce serait vraiment utile.
Merci d’avance !
Bonjour @Avadh_Sonagara Bienvenue !
Il n’y a pas de téléchargement séparé sur la marketplace pour les nœuds. La publication se fait via npm plus vérification : le nom du package doit commencer par n8n-nodes- ou @scope/n8n-nodes-, n8n-community-node-package doit être dans les mots-clés, et vos nœuds et identifiants doivent être déclarés sous l’attribut n8n dans package.json. Une fois sur npm, vous le soumettez sur Login - n8n.io.
La checklist que n8n examine avant de vérifier : échafaudage avec la CLI n8n-node, respect des directives de vérification technique sans aucune dépendance d’exécution, respect des directives UX, fourniture d’un README, et publication via un workflow GitHub Actions avec une déclaration de provenance. Ce dernier point est obligatoire pour la vérification du Creator Portal depuis le 1er mai 2026, les packages publiés depuis une machine locale ne sont pas acceptés.
La documentation ne va pas dans le référentiel n8n-docs. L’exigence est un README dans le package npm ou dans un référentiel public lié, afin que ce README soit votre guide utilisateur. Le référentiel n8n-docs contient des modèles de pages dont vous pouvez copier la structure, app-nodes.md, credentials.md et common-issues.md se trouvent dans son dossier document-templates/ : Contribution guide for n8n Docs | Contribute | n8n Docs
Les workflows passent par le même compte Creator hub plutôt que par un référentiel :
Salut @Anshul_Namdev, merci pour cette explication détaillée !
J’ai une petite confusion concernant la partie documentation. Pourrais-tu confirmer si j’ai bien compris ?
Pour notre nœud personnalisé, toute la documentation destinée aux utilisateurs (similaire aux modèles app-nodes.md, credentials.md, common-issues.md, etc.) doit-elle être incluse dans le README.md de notre package / référentiel public lié ?
Nous n’avons pas besoin de créer une PR ou de soumettre notre documentation au référentiel n8n-docs, c’est bien ça ?
Une fois le nœud soumis pour vérification via le Creator Portal, l’équipe n8n se charge-t-elle de la publication/intégration de la documentation du côté n8n, ou y a-t-il une étape de soumission de documentation séparée que nous devons effectuer ?
Je connais déjà le processus de publication du nœud/package. Ma seule confusion concerne le processus de publication de la documentation et si nous devons faire quelque chose de séparé avec n8n-docs.
Oui pour les deux premiers.
Le README dans le paquet npm ou le dépôt public lié est la documentation destinée aux utilisateurs, et les directives de vérification définissent ce qu’il doit contenir : les instructions d’utilisation, les exemples de flux de travail et les détails d’authentification, en anglais uniquement. Les modèles app-nodes.md et credentials.md sont simplement une structure que vous pouvez copier dedans.
Pas de PR vers n8n-docs. Les nouvelles pages doivent d’abord être proposées comme un problème afin que l’équipe de documentation puisse confirmer le périmètre, et la section des nœuds communautaires de la documentation couvre l’installation et l’utilisation des nœuds communautaires en général plutôt que de contenir une page de référence par nœud.
Pas d’étape de documentation séparée après la soumission non plus. La vérification récupère le paquet depuis npm, et la vue détaillée que les utilisateurs voient dans le panneau des nœuds est construite à partir de la définition du nœud dans ce paquet, donc maintenir le README à jour sur npm est tout ce qu’il faut.
Juste une dernière clarification concernant la documentation :
Si je comprends bien, nous devons uniquement maintenir la documentation dans notre README.md (soit dans le paquet npm, soit dans le référentiel public lié), en suivant la structure des modèles app-nodes.md, credentials.md et common-issues.md. Est-ce exact ?
De plus, toutes ces sections (app-nodes, credentials, common-issues, etc.) doivent-elles être incluses ensemble dans un seul README.md, ou devons-nous créer des fichiers de documentation séparés pour chaque section ?
Et une fois que le nœud est soumis via le Creator Portal, n8n utilisera les informations de documentation/paquet que nous fournissons et aucune soumission de documentation séparée n’est requise de notre côté, correct ?
De plus, votre équipe publierait la documentation en fonction de mon README, n’est-ce pas ?
Conservez un seul README.md à la racine du package. C’est le fichier qu’npm affiche sur la page du package et celui que les relecteurs lisent. Tout ce que vous divisez en fichiers séparés n’est visible que si le README y fait référence. Utilisez les modèles app-node, credential et common-issues comme titres de sections dans ce seul README plutôt que comme documents autonomes. n8n n’héberge ni ne republique vos docs : le lien Docs qui apparaît dans le panneau du nœud provient de resources.primaryDocumentation.url dans le fichier *.node.json de chaque nœud, alors pointez-le vers votre page de dépôt ou votre propre URL de documentation. Après la publication, ouvrez le nœud dans un workflow et cliquez sur ce lien pour confirmer qu’il se résout au lieu d’afficher une erreur 404.
Une chose pratique que j’ajouterais du côté du modèle de workflow : traiter la documentation comme faisant partie du workflow, et non comme quelque chose qu’on ajoute après la construction.
Pour un workflow prêt à la soumission, je voudrais que quelqu’un comprenne :
- ce que fait le workflow
- quelles credentials sont requises
- quelles entrées il attend
- quel résultat ils doivent voir
- où il peut échouer
- comment le tester en toute sécurité
Les notes autocollantes dans le canvas aident beaucoup car quelqu’un peut ouvrir le workflow et suivre le chemin sans lire d’abord un guide séparé. Je conserverais le README épuré, mais le workflow lui-même devrait expliquer les décisions et transferts importants.