ComfyUI sur Mac distant : checklist de recette 2026

Symptôme : l’interface ComfyUI s’ouvre, mais un modèle manque, un nœud échoue ou le workflow ne redémarre plus après une mise à jour.
Solution la plus rapide : validez dans cet ordre l’environnement de base, PyTorch, le lancement de ComfyUI, les répertoires de modèles, les nœuds personnalisés, le workflow fixe, puis le redémarrage et l’accès distant.

Cette méthode s’adresse à trois profils : vous préparez la location d’un Mac distant pour exécuter ComfyUI et vous voulez repérer les défauts avant la mise en production ; vous administrez des workflows partagés entre plusieurs créateurs ; ou vous migrez régulièrement une installation entre plusieurs environnements Apple Silicon et avez besoin d’une recette reproductible.

Dernière mise à jour : 10 août 2026. Les points techniques ont été vérifiés à partir de la documentation officielle de ComfyUI, de PyTorch et d’Apple.

Avant la connexion : cadrer la livraison

La première erreur consiste à commencer par l’interface graphique. Avant même d’ouvrir ComfyUI sur votre Mac distant, vous devez obtenir les informations qui permettront de comparer la livraison avec le besoin réel : version de macOS, architecture du processeur, chemin du dossier de travail, espace de stockage disponible, compte utilisé, méthode d’accès distant, port exposé et limites de responsabilité.

Ne déduisez pas la capacité de l’environnement à partir d’un simple nom de puce. La compatibilité Apple Silicon dépend aussi de la version de macOS, de Python, de PyTorch, des bibliothèques installées et des exigences propres à chaque nœud. La documentation officielle de ComfyUI indique bien que l’installation sur Mac Apple Silicon est prise en charge, mais elle renvoie également vers une installation manuelle de PyTorch et vers la vérification des dépendances. Consultez les instructions Apple Silicon du dépôt officiel de ComfyUI.

Demandez au minimum :

  • le nom exact du système d’exploitation et sa version ;
  • l’architecture retournée par le terminal, sans la remplacer par une supposition basée sur le modèle commercial ;
  • le chemin absolu de ComfyUI ;
  • le chemin des modèles, des sorties et des journaux ;
  • le compte qui possède les fichiers et celui qui lance le service ;
  • la méthode d’accès : bureau distant, partage d’écran, terminal distant ou tunnel contrôlé ;
  • le périmètre de la livraison : installation seule, modèles inclus, nœuds personnalisés, workflow de référence ou maintenance après livraison.

Cette étape révèle déjà trois coûts cachés. Un dossier appartenant à un autre compte peut être lisible mais non modifiable. Un répertoire partagé peut fonctionner jusqu’au redémarrage si le volume n’est pas monté automatiquement. Enfin, un accès qui repose sur une URL ou un port public sans règle claire peut transformer une machine de création en surface d’exposition inutile.

Pour les informations administratives, utilisez une procédure documentée plutôt qu’un échange dispersé de captures d’écran. Le centre d’aide de Macstripe peut servir de point de départ pour rassembler les consignes d’accès et les limites de l’environnement loué.

À la première session : établir la preuve technique

Une interface qui répond dans le navigateur ne prouve presque rien. Vous devez enregistrer les sorties du terminal et le journal du premier lancement afin de pouvoir distinguer un problème de système, de dépendance, de nœud ou de workflow.

Dans le répertoire de ComfyUI, vérifiez d’abord que Python et Git sont ceux attendus par l’environnement, puis contrôlez que l’installation utilise un environnement virtuel isolé. La séparation est importante : installer les dépendances dans le Python système peut donner l’impression que l’installation est complète alors que ComfyUI utilise un autre interpréteur. La documentation officielle des nœuds personnalisés avertit précisément contre ce mélange d’environnements. Voir la procédure officielle d’installation des nœuds personnalisés.

Vous pouvez conserver une preuve minimale avec des commandes de ce type, à adapter au chemin réellement livré :

which python
python --version
python -c "import platform; print(platform.machine())"
git --version
python -c "import torch; print(torch.__version__); print(torch.backends.mps.is_available()); print(torch.backends.mps.is_built())"

Sur un environnement Apple Silicon correctement préparé, le backend MPS de PyTorch doit être détecté lorsque la version de macOS, le matériel et l’installation PyTorch satisfont les prérequis. Apple décrit MPS comme le backend utilisé par PyTorch pour l’accélération GPU sur Mac, tandis que la documentation PyTorch fournit les contrôles is_available() et is_built() pour distinguer une absence de support d’une installation mal configurée. Lire la page Apple sur PyTorch et Metal.

Le critère de validation n’est pas seulement « MPS renvoie vrai ». Vous devez également lancer ComfyUI avec l’environnement virtuel actif, vérifier l’adresse d’écoute, observer l’absence d’erreur d’importation et conserver le journal généré pendant le démarrage. Si l’interface s’ouvre mais que le journal affiche des imports échoués, la recette doit rester en échec.

Que faut-il vérifier après l’installation des dépendances ?
Vérifiez que les commandes sont exécutées par le même interpréteur que celui utilisé pour démarrer ComfyUI, que torch est importé sans erreur, que MPS est détecté, puis que le lancement complet atteint l’état prêt sans erreur persistante. Une installation ne doit pas être acceptée sur la seule base d’une page web accessible.

Après le lancement : valider modèles et stockage

Un workflow ComfyUI n’est pas autonome. Il dépend d’un graphe de nœuds, mais aussi de fichiers externes : modèles principaux, VAE, LoRA, ControlNet, agrandisseurs, images d’entrée et parfois fichiers audio ou vidéo. La documentation officielle distingue ces catégories et explique que les modèles sont généralement placés dans les sous-répertoires de ComfyUI/models/. Consulter la documentation officielle sur les modèles ComfyUI.

Pour la recette, ne vous contentez pas de vérifier que les fichiers existent. Testez leur cycle complet :

  1. ouvrez le chemin affiché dans le nœud de chargement ;
  2. sélectionnez un checkpoint ou un modèle réellement utilisé par le workflow ;
  3. vérifiez que ComfyUI peut lire le fichier ;
  4. créez une sortie dans le dossier prévu ;
  5. contrôlez que le compte de service peut écrire dans ce dossier ;
  6. redémarrez l’environnement ;
  7. relancez le même workflow sans modifier les chemins.

Si vous réutilisez un volume externe ou un dossier partagé, documentez sa configuration au lieu de copier manuellement les fichiers dans plusieurs emplacements. ComfyUI prend en charge la configuration de chemins de modèles supplémentaires, et la documentation explique également comment déclarer des chemins de nœuds personnalisés. Voir la configuration officielle des chemins supplémentaires.

Les limitations les plus fréquentes sont les suivantes :

  • le chemin est correct pendant la session mais le volume n’est pas remonté après redémarrage ;
  • les fichiers sont visibles par le compte administrateur mais pas par le compte qui lance ComfyUI ;
  • le workflow attend un sous-répertoire précis, alors que le modèle a été copié dans un dossier voisin ;
  • deux versions d’un même modèle portent des noms proches, ce qui rend la recette difficile à reproduire ;
  • le dossier de sortie est accessible en lecture seule, empêchant la sauvegarde des images ou des séquences.

Pour un studio qui produit des visuels, des aperçus vidéo ou des éléments de design, le dossier de sortie doit également être partagé selon une règle explicite. Un artiste doit savoir où récupérer le résultat ; un administrateur doit savoir qui peut supprimer ou remplacer les fichiers ; et le workflow doit conserver une référence au fichier réellement utilisé.

Par lots : installer les ComfyUI Nodes

Installez les ComfyUI Nodes par groupes fonctionnels, jamais tous en une seule opération. Commencez par les nœuds nécessaires au workflow de référence, puis ajoutez les extensions secondaires une par une ou par petits lots cohérents. Après chaque lot, redémarrez ComfyUI, inspectez le journal et exécutez un test minimal.

Cette discipline permet d’identifier la cause d’une régression. Une installation globale peut mélanger une exigence Python stricte, une version particulière de PyTorch, une extension d’interface incompatible et un paquet déjà utilisé par un autre nœud. La documentation officielle de dépannage cite justement les conflits de dépendances, les échecs d’importation et les modifications du frontal comme causes fréquentes de panne. Consulter le guide officiel de résolution des problèmes liés aux nœuds.

Pour chaque nœud, archivez :

  • l’adresse du dépôt ;
  • le commit ou la version installée ;
  • le fichier requirements.txt utilisé ;
  • la commande d’installation ;
  • le résultat du test minimal ;
  • les erreurs apparues dans le journal ;
  • la décision prise : conserver, corriger, désactiver ou retirer.

Le gestionnaire de nœuds peut faciliter l’installation, la désactivation et la détection des extensions manquantes, mais il ne remplace pas la validation de votre workflow. Pour un environnement partagé, la traçabilité du commit est plus utile qu’une simple mention « installé depuis le gestionnaire ».

Que vérifier après l’installation d’un nœud personnalisé ?
Vérifiez que le nœud apparaît dans la bibliothèque, qu’il se charge sans erreur au démarrage, que ses entrées correspondent au workflow fourni et qu’un test isolé produit le résultat attendu. Si une extension modifie l’interface, testez aussi l’ouverture du workflow dans un navigateur propre ou une session sans cache.

Lors de l’import : traiter les nœuds manquants

Que faire si le workflow ComfyUI signale des nœuds manquants ?
Commencez par distinguer un nœud natif absent d’un nœud personnalisé non installé. La documentation officielle indique qu’un nœud natif peut manquer après une mise à jour incohérente de ComfyUI, tandis qu’un nœud personnalisé absent signifie généralement que l’extension tierce correspondante n’est pas présente dans l’environnement. Voir les états de nœud et les causes de nœuds manquants.

La procédure de correction doit rester contrôlée :

  1. notez le nom exact du nœud manquant ;
  2. comparez-le avec la liste des extensions déclarées par le workflow ;
  3. identifiez le dépôt correspondant ;
  4. vérifiez si une version précise est recommandée ;
  5. installez cette extension dans l’environnement ComfyUI concerné ;
  6. redémarrez et relisez le journal ;
  7. exécutez le workflow sans remplacer silencieusement le nœud par une alternative.

Évitez de remplacer un nœud manquant par un autre simplement parce que son nom semble proche. Les paramètres, les types de sortie et la logique d’exécution peuvent différer. Pour une équipe qui partage des workflows, cette substitution non documentée crée une divergence difficile à repérer dans les rendus finaux.

Sur le workflow fixe : tester le résultat réel

La recette doit reposer sur un workflow ComfyUI fixe, versionné et représentatif de votre usage. Pour une équipe audiovisuelle, il peut inclure le chargement d’un modèle, un encodage texte, un échantillonnage, une étape d’amélioration et l’enregistrement d’une image ou d’une séquence. Pour un designer, il peut inclure une image d’entrée, un contrôle de composition, un LoRA et une sortie destinée à la retouche.

Le fichier du workflow doit être conservé en JSON, avec les modèles utilisés, les noms de nœuds, les paramètres essentiels et un exemple de sortie. ComfyUI permet d’enregistrer les workflows en JSON et de conserver leurs informations dans les métadonnées des images générées, ce qui facilite le partage et l’archivage. Consulter la documentation officielle sur les workflows.

Pendant le test, enregistrez :

  • le fichier JSON du workflow ;
  • la version de ComfyUI ;
  • la version du frontal ;
  • les versions Python et PyTorch ;
  • la liste des nœuds personnalisés ;
  • les noms ou empreintes des modèles ;
  • le journal du lancement ;
  • le fichier de sortie produit ;
  • les éventuels avertissements qui n’empêchent pas l’exécution.

Le résultat visuel ne doit pas être le seul critère. Un fichier correctement généré peut masquer une dépendance non documentée, un chemin local propre à votre session ou une extension chargée de manière facultative. La recette est réussie seulement si une autre session autorisée peut ouvrir le workflow, retrouver ses modèles et reproduire le chemin d’exécution prévu.

Au redémarrage : prouver la reproductibilité

Le redémarrage est le test qui sépare une démonstration ponctuelle d’un environnement exploitable. Fermez ComfyUI proprement, redémarrez le service ou la machine selon le périmètre de la livraison, reconnectez-vous avec le compte prévu, puis relancez le workflow sans réinstaller manuellement les composants.

Contrôlez successivement :

  • le montage automatique des volumes ;
  • la disponibilité du chemin des modèles ;
  • les droits d’écriture sur les sorties ;
  • le chargement des ComfyUI Nodes ;
  • l’accès au port ou au tunnel ;
  • la conservation des paramètres de démarrage ;
  • l’absence d’identifiants exposés dans les journaux ;
  • la possibilité de fermer l’accès distant après la session.

Un environnement qui exige une intervention manuelle après chaque redémarrage n’est pas nécessairement inutilisable, mais sa limite doit être écrite dans le procès-verbal de recette. Pour un usage individuel ponctuel, cette contrainte peut être acceptable. Pour un studio qui travaille sur des workflows partagés, elle devient rapidement une source d’interruptions et d’erreurs de manipulation.

Checklist de validation finale

  • [ ] Les informations de macOS, d’architecture et de chemin de travail ont été enregistrées.
  • [ ] Le compte de lancement et ses droits sur les fichiers sont connus.
  • [ ] Python, Git et l’environnement virtuel ont été identifiés.
  • [ ] PyTorch est importé sans erreur et le backend MPS est contrôlé.
  • [ ] ComfyUI démarre sans erreur persistante dans le journal.
  • [ ] Les dossiers checkpoints, VAE, LoRA et autres modèles requis sont accessibles.
  • [ ] Le dossier de sortie est inscriptible par le compte de service.
  • [ ] Les chemins supplémentaires sont documentés lorsqu’un volume externe est utilisé.
  • [ ] Les ComfyUI Nodes ont été installés par lots et leurs versions sont enregistrées.
  • [ ] Chaque extension nécessaire apparaît dans la bibliothèque de nœuds.
  • [ ] Le workflow fixe charge son modèle, exécute son graphe et enregistre une sortie.
  • [ ] Le fichier JSON, le journal et le résultat de référence sont archivés.
  • [ ] Le workflow a été relancé après redémarrage.
  • [ ] Les ports, identifiants, dossiers partagés et règles d’accès ont été vérifiés.
  • [ ] Les limites restantes sont écrites avant l’acceptation de la livraison.

Un poste local non préparé vous laisse généralement trois problèmes : une configuration matérielle difficile à partager, des dépendances qui évoluent sans journal de recette et une récupération manuelle après une panne ou un redémarrage. Une solution générique peut ajouter des contraintes de chemin, de contrôle d’accès ou de stockage qui ne correspondent pas à votre workflow créatif. Dans ces cas, un Mac distant géré avec une liste de validation explicite offre un cadre plus lisible pour tester une installation temporaire, migrer un projet ou faire travailler plusieurs personnes sur le même environnement.

Si vous avez besoin de ComfyUI pour une période limitée, un prototype audiovisuel, une production de design ou la vérification d’un ensemble de nœuds, vous pouvez transmettre à Macstripe votre liste de modèles, vos extensions, votre workflow de référence et la durée souhaitée. L’objectif n’est pas de louer un environnement indistinct, mais de vérifier avant utilisation que le Mac livré peut démarrer, charger, produire et redémarrer conformément à votre procédure. Pour préparer les éléments de la demande, utilisez la page configuration et commande de Macstripe.

Pour aller plus loin