Guide complet pour réutiliser un workflow ComfyUI : checklist d'import, de débogage et de reproduction

Après avoir importé le workflow ComfyUI de quelqu’un d’autre, vous pouvez vous retrouver avec une interface pleine de nœuds rouges et une liste de modèles vide. La première fois que cela m’est arrivé, il m’a fallu une demi-heure pour comprendre que le problème se divisait en trois catégories : nœuds manquants, chemins de modèles incorrects et dépendances Python non installées. Ce guide ne parle pas de l’installation de ComfyUI. Il répond à une question plus précise : quand vous recevez un JSON de workflow ou un PNG, comment compléter ce qui manque, le déboguer étape par étape et obtenir une image proche de l’exemple ? Le cœur de l’article est une checklist réutilisable, depuis l’import jusqu’à l’archivage.

Pourquoi le workflow de quelqu’un d’autre ne tourne pas

Un workflow ComfyUI est essentiellement un graphe de nœuds connectés. Un JSON ou une metadata PNG enregistre les types de nœuds, les valeurs de paramètres et les connexions, mais il ne contient pas les fichiers de modèles, les plugins de custom nodes ni les dépendances Python. Dès que vous importez un workflow partagé, tout ce qui manque dans votre environnement local apparaît.

Un nœud rouge signifie que ComfyUI ne trouve pas le type de nœud correspondant. Certains nœuds sont intégrés, ce sont les core nodes, et ne devraient pas manquer. D’autres sont des extensions tierces, les custom nodes, que vous n’avez peut-être jamais installées. Après avoir corrigé les nœuds, le menu déroulant de Load Checkpoint ou Load LoRA peut rester vide : le fichier du modèle n’est pas dans le dossier par défaut, ou la configuration de chemin est mauvaise. Même après cela, certains custom nodes peuvent signaler l’absence de paquets Python comme insightface ou onnxruntime.

Ces trois types de problèmes se superposent. Un même workflow peut manquer de trois custom nodes, de deux modèles checkpoint et d’un paquet Python. Sans ordre de diagnostic, on se bloque facilement à une étape et on installe un tas de choses inutiles. La checklist plus bas sépare ces problèmes et les traite par priorité.

Deux sources de workflow : JSON ou metadata PNG

Quand quelqu’un partage un workflow, il utilise généralement l’un de deux supports : un fichier JSON autonome ou une image PNG qui contient encore de la metadata. Le JSON est le format natif exporté par ComfyUI et conserve les informations de nœuds. La metadata PNG est un format intégré : certaines images générées contiennent les données du workflow dans le fichier, à condition que l’auteur les ait conservées.

Glisser un fichier JSON

Si vous recevez un fichier JSON, glissez-le directement dans l’interface de ComfyUI. L’interface charge le graphe de nœuds et affiche toutes les connexions. C’est la méthode la plus fiable : le JSON ne dépend pas d’une compression d’image et conserve intactes les informations de nœuds.

Si ce JSON a été exporté depuis ComfyUI, la disposition importée devrait correspondre à celle de l’auteur. Si tout semble désordonné, l’export peut venir d’une autre version de ComfyUI, ou le JSON a pu être modifié à la main.

Conditions pour charger une metadata PNG

Certaines images PNG générées par IA intègrent la metadata du workflow. Vous pouvez les charger en glissant l’image dans ComfyUI ou en choisissant “Load” dans le menu puis le fichier PNG.

La condition est simple : l’image doit encore contenir sa metadata. Beaucoup de réseaux sociaux et d’hébergeurs d’images compressent ou suppriment la metadata lors de l’envoi, ce qui efface les données du workflow. Si l’image vient d’un réseau social, il y a de fortes chances que la metadata ait déjà disparu et que ComfyUI n’ouvre qu’un canevas vide.

Privilégiez les fichiers JSON. La metadata PNG est pratique pour que l’auteur conserve son historique local de génération, mais ce n’est pas un format fiable pour partager entre plateformes.

Comparaison JSON vs metadata PNG

Avant d’importer un workflow, vérifiez la source. Une liste de nœuds, une liste de modèles ou un README est plus sûr qu’un JSON ou un PNG seul.

Nœuds rouges : distinguer Core Node et Custom Node

Après l’import, des nœuds rouges peuvent apparaître avec des titres comme “Missing” ou “Unknown node type”. N’installez pas tout de suite des paquets. Identifiez d’abord le type de nœud, puis choisissez où chercher.

Différence entre Core Node et Custom Node

Un core node est un nœud intégré à ComfyUI. Il vient avec le programme principal et ne devrait pas manquer. Exemples courants : Load Checkpoint, KSampler, VAE Decode, Save Image. Si ces nœuds apparaissent en rouge, votre installation de ComfyUI est peut-être incomplète ou trop ancienne.

Alibaba Cloud - Choix n°1 des développeurs, 15 % de réduction exclusive sur Lighthouse

Obtenir -15 % →Pub

Un custom node est une extension tierce à installer séparément. Exemples courants : IP-Adapter Apply, ControlNet Apply, FaceDetailer. La plupart des nœuds rouges viennent de custom nodes absents.

Pour trancher, regardez le nom du nœud. S’il contient un préfixe d’extension connu, comme IPAdapter, ControlNet ou Impact, c’est probablement un custom node. En cas de doute, faites un clic droit dans l’interface ComfyUI et cherchez le nom dans “Add Node”. Un core node apparaît dans la liste par défaut ; un custom node absent n’y apparaît pas.

Comment trouver un Custom Node

Une fois le custom node identifié, trois chemins de recherche sont utiles.

ComfyUI Registry : c’est la plateforme de registre recommandée par le projet. Allez sur registry.comfy.org et cherchez le nom du nœud ou de l’extension. Registry indique souvent l’origine, la méthode d’installation et les dépendances. Certains nœuds prennent en charge l’installation en un clic, selon votre version de ComfyUI.

ComfyUI Manager : c’est un outil tiers de gestion d’extensions. Si vous l’avez installé, ouvrez ComfyUI, allez dans “Manager” -> “Install Custom Nodes” et cherchez le nom du nœud. Manager liste les extensions correspondantes et affiche l’état d’installation. Ce n’est pas une fonction core de ComfyUI ; sa stabilité dépend de la communauté.

Recherche GitHub : si Registry et Manager ne trouvent rien, cherchez le nom du nœud sur GitHub. Beaucoup d’auteurs de custom nodes documentent les noms de nœuds dans leur README. Une fois le dépôt trouvé, clonez-le dans custom_nodes en suivant le README.

Problèmes de dépendances Python

Certains custom nodes nécessitent des paquets Python supplémentaires. Par exemple, IP-Adapter peut avoir besoin de insightface, et certaines extensions ControlNet peuvent demander onnxruntime.

Entrez dans le dossier du custom node et consultez le README ou requirements.txt. Depuis la racine de ComfyUI, exécutez :

pip install -r custom_nodes/dossier-du-noeud/requirements.txt

Certains README indiquent directement pip install nom-du-paquet. Suivez les instructions du projet.

Confirmer d’abord les nœuds réellement manquants

Un workflow peut référencer de nombreux custom nodes, mais vous n’avez peut-être besoin d’installer que ceux qui apparaissent en rouge. Cette liste de nœuds rouges est l’inventaire réel des manques. N’installez pas tous les paquets populaires au hasard : chaque paquet augmente le temps de démarrage et le risque de conflit.

Modèle introuvable ? Vérifiez les dossiers et la bibliothèque externe

Une fois les nœuds corrigés, les menus de Load Checkpoint, Load LoRA ou Load VAE peuvent rester vides. Les modèles référencés par le workflow ne sont pas partagés avec le JSON ; vous devez les placer manuellement dans le dossier models de ComfyUI.

Structure du dossier models de ComfyUI

Au démarrage, ComfyUI scanne les sous-dossiers de models et charge les modèles par type. Les dossiers courants sont :

Si le nœud Load Checkpoint du workflow vise sdxl_base.safetensors, placez ce modèle dans models/checkpoints/sdxl_base.safetensors. Le menu du nœud affichera automatiquement les modèles de ce dossier.

À quoi sert extra_model_paths.yaml

Si votre bibliothèque de modèles se trouve ailleurs, par exemple sur un NAS partagé ou dans un dossier centralisé, inutile de tout copier dans models. Vous pouvez utiliser extra_model_paths.yaml pour pointer vers des chemins externes.

Le fichier se trouve à la racine de ComfyUI et utilise YAML. Exemple :

my_custom_config:
  base_path: /path/to/external
  checkpoints: models/checkpoints
  loras: models/loras
  vae: models/vae
  controlnet: models/controlnet

Au démarrage, ComfyUI scanne les chemins configurés et les combine avec le dossier models par défaut. Le format peut évoluer selon les versions ; vérifiez la documentation officielle ou les messages de démarrage si quelque chose ne correspond pas.

Confirmer la version du modèle

Un workflow peut mentionner seulement sdxl_base, alors qu’il existe plusieurs variantes : version officielle, fine-tune communautaire, fp16, pruned. Des versions différentes peuvent produire des sorties très différentes.

Quand vous recevez un workflow, demandez d’abord la source et la version du modèle. S’il n’y a pas d’explication, cherchez le nom dans la bibliothèque correspondante, comme Civitai ou Hugging Face, et vérifiez si l’auteur a publié une version précise. Choisissez la version indiquée par l’auteur, pas un fichier au même nom au hasard.

Ce guide ne donne pas de liens directs de téléchargement. Les questions de licence sont trop variables. Gardez les noms et les pages de source, puis vérifiez vous-même les autorisations.

Pourquoi le résultat ne ressemble pas à l’image d’exemple

Les nœuds et les modèles sont en place, le workflow tourne, mais la sortie reste très différente de l’image d’exemple. Ce n’est pas forcément une erreur de manipulation. L’écart peut venir des paramètres, de la version du modèle ou du backend d’exécution.

Railway - Plateforme de déploiement moderne, sans opérations complexes, en ligne en quelques minutes

Commencer →Pub

Tableau d’impact des paramètres

Voici les paramètres courants et leur impact. Les paramètres à fort impact doivent être alignés strictement ; les autres peuvent être ajustés avec plus de souplesse.

La version du modèle est le facteur le plus important

Même si vous téléchargez un modèle portant le même nom, une version différente peut faire dériver complètement le résultat. Par exemple, sdxl_base peut désigner le modèle officiel, une variante fp16 communautaire ou un fine-tune anime. Si l’auteur a utilisé l’original et que vous prenez une variante anime, le style changera entièrement.

Après avoir reçu le workflow, confirmez d’abord la source et la version du modèle. Si l’auteur ne l’indique pas, consultez la page du modèle et cherchez les notes de version. En cas de doute, demandez à l’auteur plutôt que de deviner.

Viser un style et une composition proches, pas une copie parfaite

Reproduire exactement une image exige une version de modèle identique, un seed aligné, tous les paramètres alignés et un environnement d’exécution identique. Ces conditions sont difficiles à réunir, surtout quand le seed ou la version exacte du modèle manquent.

L’objectif réaliste est d’obtenir un style et une composition proches de l’exemple. Si le sujet, le ton colorimétrique et la structure globale de l’image sont proches, la reproduction est réussie. Les détails fins, comme le visage ou la texture, peuvent varier.

Checklist de dépannage pour réutiliser un workflow ComfyUI

La checklist suivante couvre tout le processus, de l’import à l’archivage. Gardez-la sous la main et vérifiez chaque point à chaque workflow externe.

Étape 1 : confirmer la source

Commencez par identifier le support et les informations associées.

• Vérifiez s’il s’agit d’un fichier JSON ou d’une image PNG. Privilégiez le JSON ; la metadata PNG peut être supprimée par les plateformes.
• Regardez s’il y a des notes associées : liste de nœuds, liste de modèles, README ou commentaire de l’auteur.
• Si vous n’avez qu’un PNG, essayez de charger la metadata. Si cela échoue, elle est perdue ; demandez le JSON à l’auteur ou abandonnez ce workflow.
• Si la source est floue ou si le partage communautaire date de plus de 12 mois, la confiance est plus faible. Utilisez-le avec prudence.

Étape 2 : compléter les nœuds

Après l’import, inspectez les nœuds rouges.

• Listez tous les noms de nœuds rouges et confirmez s’il s’agit de core nodes ou de custom nodes.
• Core node manquant : vérifiez que l’installation de ComfyUI est complète, ou que la version n’est pas trop ancienne.
• Custom node manquant :
  • Cherchez le nom du nœud ou de l’extension dans ComfyUI Registry.
  • Si Manager est installé, cherchez dans “Install Custom Nodes”.
  • Si vous ne trouvez rien, cherchez le nom du nœud sur GitHub et suivez le README.
• Redémarrez ComfyUI après l’installation du custom node.
• Vérifiez que les nœuds rouges ont disparu. S’ils restent rouges, une dépendance Python manque peut-être ; allez dans le dossier du custom node, ouvrez requirements.txt et exécutez pip install -r requirements.txt.

Installez d’abord les nœuds réellement manquants. N’installez pas tous les paquets populaires.

Étape 3 : mapper les modèles

Une fois les nœuds complétés, vérifiez les nœuds de modèles.

• Listez toutes les références de modèles du workflow : checkpoint, LoRA, VAE, ControlNet, IP-Adapter, etc.
• Identifiez le type de chaque modèle pour savoir dans quel sous-dossier de models/ le placer.
• Vérifiez si vous avez déjà un modèle local au même nom. Si oui, confirmez que la version correspond.
• Si vous n’en avez pas, cherchez le modèle dans une bibliothèque comme Civitai ou Hugging Face et vérifiez sa source et sa version.
• Après téléchargement, placez-le dans le bon dossier ou configurez un chemin externe avec extra_model_paths.yaml.
• Redémarrez ComfyUI et vérifiez que le modèle apparaît dans le menu du nœud.

La version du modèle est le facteur qui influence le plus la reproduction. Confirmez-la avant de modifier les autres paramètres.

Étape 4 : verrouiller les paramètres

Avec les modèles en place, examinez les paramètres du workflow.

• Vérifiez si le seed est fixé. S’il ne l’est pas, vous ne pourrez pas reproduire la même image, seulement ajuster le style.
• Vérifiez sampler, steps, CFG Scale et taille d’image.
• Vérifiez si un VAE est chargé et quels poids LoRA sont utilisés.
• Comparez l’image d’exemple et les paramètres pour repérer les écarts évidents.
• Si l’auteur a noté des ajustements, appliquez-les.

Les paramètres peuvent avoir été retouchés par l’auteur. Si l’image d’exemple et le JSON ne correspondent pas exactement, il faudra aligner à la main.

Étape 5 : test minimal

Une fois les paramètres vérifiés, lancez d’abord un test simple.

• Utilisez un prompt simple, par exemple “a cat sitting on a chair”.
• Vérifiez que la sortie est normale : pas d’erreur, pas d’image vide, pas d’effondrement visible.
• En cas d’erreur, consultez le log du terminal et localisez le nœud ou le modèle en cause.
• Si la sortie est normale, ajustez progressivement le prompt et les paramètres pour vous rapprocher de l’exemple.
• Ne commencez pas avec un prompt complexe. Un prompt complexe peut masquer un problème de nœud ou de modèle.

Étape 6 : nommer et archiver

Quand la reproduction fonctionne, sauvegardez et organisez le workflow.

• Enregistrez le workflow comme nouveau fichier JSON.
• Format recommandé : [thème]-[modèle]-[date]-v1.json. Exemple : portrait-sdxl-base-20260623-v1.json.
• Notez la version du modèle. Utilisez de préférence un README.txt associé au workflow ; ne comptez pas sur des commentaires dans le JSON.
• Notez le checkpoint et sa version, les noms et poids LoRA, le VAE, le sampler et les paramètres.
• Si vous partagez le workflow, ajoutez la liste des nœuds, la liste des modèles, une image d’exemple et les notes de paramètres. Ne partagez pas les fichiers de modèles.

Vous pouvez copier cette checklist et la cocher à chaque réutilisation de workflow.

Gestion des workflows : nommage et partage

Quand une reproduction fonctionne, l’organisation évite de refaire le même diagnostic plus tard. Si vous partagez le workflow, des informations complètes réduisent le temps de dépannage pour l’autre personne.

Vultr - Serveur cloud NVMe haute performance, 32 emplacements mondiaux, déploiement Docker en un clic

Voir les tarifs →Pub

Convention de nommage

Des noms de fichiers désordonnés rendent les workflows difficiles à retrouver, surtout quand vous en accumulez des dizaines.

Format recommandé : [thème]-[modèle]-[date]-v1.json

Exemples :

• portrait-sdxl-base-20260623-v1.json : thème portrait, modèle SDXL Base, 23 juin 2026, version 1
• landscape-sd15-controlnet-20260620-v1.json : thème paysage, SD1.5 + ControlNet

Le thème peut être l’usage : portrait, landscape, anime, product, concept-art. Le modèle doit reprendre le checkpoint principal en version courte. Utilisez le format de date YYYYMMDD. v1, v2 servent à distinguer les itérations.

Méthode pour enregistrer les versions de modèles

Le JSON du workflow n’enregistre pas la version réelle du fichier de modèle ; il enregistre seulement son nom. Si plusieurs versions portent le même nom dans une bibliothèque, vous ne saurez peut-être plus laquelle vous aviez utilisée.

Deux méthodes :

Méthode 1 : un README.txt associé

Créez un README-[nom-du-fichier].txt dans le même dossier et notez :

• le nom du checkpoint et son lien de source (pas de lien direct de téléchargement, seulement l’URL de la page du modèle)
• les noms, poids et sources des LoRA
• le nom et la source du VAE
• sampler, steps, CFG et taille
• les autres paramètres importants

Utilisez README.txt comme source principale pour les versions de modèles. C’est plus compatible, et plus simple à partager avec le JSON et l’image d’exemple.

Recommandations pour partager un workflow

Quand vous partagez un workflow, les informations complètes aident le destinataire à démarrer vite.

Contenu indispensable :

• Fichier JSON : le workflow complet, priorité absolue.
• Liste des nœuds : tous les custom nodes et leur origine, par exemple un lien Registry ou un dépôt GitHub.
• Liste des modèles : checkpoint, LoRA, VAE, ControlNet et autres modèles, avec noms et suggestions de source, sans lien direct de téléchargement.
• Image d’exemple : une sortie générée pour confirmer la cible de reproduction.
• Notes de paramètres : si les paramètres du JSON ne correspondent pas à l’image d’exemple, indiquez les paramètres réellement utilisés.

À ne pas fournir :

• Fichiers de modèles : les licences sont complexes ; ne partagez pas les modèles eux-mêmes.
• Liens directs de téléchargement : la page de la bibliothèque peut être indiquée, mais les liens directs sont plus risqués.
• Commandes d’installation de paquets Python : si un custom node a des dépendances particulières, indiquez les paquets ; laissez le destinataire lire le README pour la commande exacte.

Ajoutez un README court avec ces informations. Le destinataire pourra suivre la checklist point par point et gagner beaucoup de temps.

Pour continuer

Si vous n’avez pas encore installé ComfyUI, commencez par le guide complet d’introduction à ComfyUI pour comprendre l’installation, le dossier des modèles et la première image. Pour améliorer les prompts, lisez Prompt Engineering appliqué au business. Pour les workflows de création assistée par IA entre plusieurs formats, consultez la création cross-média. Pour lancer des modèles de langage en local, poursuivez avec l’introduction à Ollama.