Installer ComfyUI et FLUX.1-dev en local demande de distinguer l’interface, les poids du modèle, les encodeurs, le VAE et la licence. Ce guide documente chaque choix sans promettre une configuration universelle.
Mise à jour du 5 août 2026 — transparence éditoriale
La première version de ce guide simplifiait excessivement l’installation de FLUX.1-dev et parlait de « confidentialité totale » et d’IA « sans censure ». Ces formulations étaient inexactes. Cette nouvelle version s’appuie sur la documentation officielle de ComfyUI et la licence de Black Forest Labs.
Cette réécriture applique la méthode éditoriale BlackFury pour utiliser un assistant IA sans inventer d’expérience : les sources et les limites sont explicites, et aucune mesure personnelle n’est revendiquée sans essai reproductible.
Faire tourner une IA générative sur son propre PC reste l’une des meilleures façons de comprendre ce qui se passe derrière une simple zone de texte. Avec ComfyUI, on ne demande pas seulement une image : on construit un graphe, on choisit le modèle, l’encodeur de texte, le VAE, le sampler, les dimensions, la graine et la destination du résultat.
Cette liberté demande en échange davantage de rigueur. FLUX.1-dev n’est pas un petit fichier que l’on dépose au hasard dans un dossier checkpoints. Le modèle complet possède 12 milliards de paramètres, utilise plusieurs fichiers et sa licence n’autorise pas tous les usages du modèle.
Voici donc une installation réaliste, avec ses choix, ses limites et une méthode pour produire un workflow que l’on saura encore expliquer six mois plus tard.
ComfyUI n’est pas un modèle
ComfyUI est une interface, un moteur d’exécution et une API construits autour d’un système de nœuds. Le modèle est un ensemble de poids séparé, comme FLUX.1-dev, FLUX.1-schnell, SDXL ou un autre modèle pris en charge.
Cette distinction évite plusieurs confusions :
- mettre ComfyUI à jour ne met pas automatiquement tous les modèles à jour ;
- changer de modèle peut exiger d’autres encodeurs, un autre VAE ou un workflow différent ;
- un nœud manquant peut venir d’une extension absente, pas du modèle ;
- les conditions d’utilisation viennent à la fois du logiciel, des modèles et des éventuelles extensions ou API.
ComfyUI lui-même est open source. FLUX.1-dev est distribué avec des poids accessibles, mais sous une licence spécifique non commerciale pour l’utilisation et la modification du modèle.
Installer ComfyUI et FLUX.1-dev en local : choisir la méthode
En 2026, il existe trois grandes méthodes. Je ne conseille plus la même procédure à tout le monde.
ComfyUI Desktop
C’est le chemin le plus simple pour débuter. L’application crée et gère son propre environnement Python.
- Sous Windows, la version Desktop documentée vise actuellement les cartes NVIDIA.
- Sous macOS, elle vise les Mac Apple Silicon et utilise MPS.
- Le logiciel Desktop est encore présenté comme bêta ; ses écrans peuvent évoluer.
La documentation Windows demande environ 15 Go libres pour l’application et ses dépendances. Les modèles viennent en plus et peuvent occuper plusieurs dizaines de gigaoctets.
Version portable Windows
La version portable contient son propre Python. Les publications officielles proposent aujourd’hui plusieurs variantes pour NVIDIA, AMD, Intel ou un fonctionnement CPU, selon le matériel.
Elle est pratique pour isoler l’environnement et éviter de modifier le Python du système. Il faut cependant lancer les scripts et installer les dépendances avec le Python intégré à cette version, pas avec une autre commande python trouvée dans le PATH.
Installation manuelle
Elle offre le plus de contrôle et prend en charge davantage de matériels et de systèmes : NVIDIA, AMD, Intel, Apple Silicon et d’autres accélérateurs selon la pile PyTorch disponible.
Le principe reste :
git clone https://github.com/Comfy-Org/ComfyUI.git
Set-Location ComfyUI
python -m venv .venv
.\.venv\Scripts\Activate.ps1
python -m pip install --upgrade pip
Il faut ensuite installer PyTorch avec la commande correspondant précisément au GPU et au système, puis les dépendances de ComfyUI :
python -m pip install -r requirements.txt
python main.py
Les commandes PyTorch, CUDA et ROCm évoluent rapidement. Je les récupère dans la documentation ComfyUI/PyTorch au moment de l’installation au lieu de recopier une commande ancienne.
Python et matériel : pourquoi je ne donne plus un simple « 6 Go de VRAM »
La documentation actuelle recommande Python 3.13 et propose Python 3.12 comme solution de repli si des nœuds personnalisés ne fonctionnent pas. Python 3.14 peut fonctionner, mais certaines extensions peuvent encore poser problème.
Pour le matériel, une valeur unique serait trompeuse. Les besoins dépendent :
- de la version complète ou quantifiée du modèle ;
- de l’encodeur T5 choisi ;
- de la résolution ;
- du nombre d’images traitées simultanément ;
- de l’offload vers la RAM ;
- des nœuds supplémentaires ;
- de l’aperçu et des autres applications ouvertes.
La documentation officielle de FLUX.1 indique que t5xxl_fp16.safetensors est recommandé lorsque l’on dispose de plus de 32 Go de VRAM. Pour une configuration plus limitée, elle propose un encodeur T5 en FP8. Le modèle FLUX complet demande davantage de ressources que le checkpoint FP8, qui réduit les besoins au prix d’une légère perte de qualité.
Une carte de 6 ou 8 Go peut éventuellement exécuter certaines versions quantifiées ou fortement déportées en mémoire, mais cela ne signifie pas que le workflow complet sera confortable. Je préfère mesurer sur une configuration réelle plutôt que promettre un minimum universel.
Télécharger FLUX.1-dev depuis sa source
Le dépôt de référence est celui de Black Forest Labs sur Hugging Face :
https://huggingface.co/black-forest-labs/FLUX.1-dev
Le téléchargement de flux1-dev.safetensors nécessite de se connecter et d’accepter les conditions du dépôt. Je n’utilise pas comme source principale une copie republiée sans modèle de carte, licence ni historique.
Le workflow complet officiel utilise quatre fichiers :
flux1-dev.safetensors— modèle de diffusion ;clip_l.safetensors— premier encodeur de texte ;t5xxl_fp16.safetensorsou sa variante FP8 — second encodeur ;ae.safetensors— VAE.
Ils doivent être rangés ainsi :
ComfyUI/
└── models/
├── diffusion_models/
│ └── flux1-dev.safetensors
├── text_encoders/
│ ├── clip_l.safetensors
│ └── t5xxl_fp16.safetensors
└── vae/
└── ae.safetensors
La version FP8 « checkpoint », plus simple, peut être placée dans ComfyUI/models/checkpoints/. Elle ne doit pas être confondue avec la version complète à quatre fichiers.
Après chaque téléchargement important, je conserve le nom exact du fichier, sa source, la date et si possible son empreinte. Un fichier nommé flux-final-v2.safetensors sans provenance n’est pas une base de travail reproductible.
La licence : ouverte ne veut pas dire sans condition
FLUX.1-dev relève de la licence non commerciale de Black Forest Labs. Elle autorise l’accès et l’utilisation du modèle à des fins non commerciales selon ses conditions. Elle précise aussi ne pas revendiquer la propriété des images produites et autoriser certains usages des sorties, y compris commerciaux, selon le texte de la licence.
La nuance compte : utiliser les poids du modèle pour exploiter un service commercial et utiliser une image produite ne sont pas nécessairement la même opération juridique.
Je ne résume donc plus la licence par « modèle libre » ou « aucune restriction ». Pour une utilisation professionnelle, un service vendu ou un entraînement dérivé, il faut lire la version actuelle de la licence et obtenir un conseil adapté en cas de doute.
Le modèle possède également une liste d’usages hors périmètre : harcèlement, nudité non consentie, contenu pornographique illégal, décisions automatisées portant atteinte à des droits et campagnes de désinformation à grande échelle, entre autres.
Présenter FLUX.1-dev comme une IA « conçue sans censure » était donc incorrect.
Charger le workflow officiel plutôt que le reconstruire au hasard
ComfyUI publie un exemple officiel FLUX.1 texte-vers-image. L’image du workflow contient les métadonnées nécessaires et peut être glissée directement dans l’interface. On peut aussi ouvrir son fichier depuis le menu des workflows.
Avant de lancer la génération, je vérifie :
DualCLIPLoaderchargeclip_l.safetensorset le bon T5 ;Load Diffusion Modelchargeflux1-dev.safetensors;Load VAEchargeae.safetensors;- les dimensions sont raisonnables pour la mémoire disponible ;
- la graine, le nombre d’étapes et le prompt sont enregistrés.
La génération se lance avec le bouton Queue ou Ctrl + Entrée sous Windows et Linux. Si un nœud apparaît en rouge, je lis son message et le journal de démarrage avant d’installer une extension au hasard.
FLUX suit généralement bien les descriptions positives et le workflow officiel n’utilise pas de prompt négatif comme certains anciens modèles Stable Diffusion. Ajouter des nœuds inutiles dès le premier essai rend seulement le diagnostic plus difficile.
Rendre le premier test reproductible
Le premier résultat ne sert pas uniquement à obtenir une jolie image. Il doit prouver que l’installation fonctionne.
Je conserve une fiche de test :
| Élément | Valeur à relever |
|---|---|
| ComfyUI | version ou commit |
| Système | version de Windows, Linux ou macOS |
| GPU | modèle et quantité de VRAM |
| RAM | quantité installée |
| Pilote | version |
| PyTorch | version et backend CUDA/ROCm/MPS |
| Modèle | nom exact et variante |
| Workflow | fichier JSON ou PNG source |
| Résolution | largeur × hauteur |
| Étapes | valeur utilisée |
| Graine | valeur fixe |
| Temps | durée mesurée |
| Mémoire | pic observé si disponible |
Je relance ensuite exactement le même workflow avec la même graine. Si le résultat ou le comportement change, je sais qu’une dépendance, un réglage ou une version n’est pas identique.
Cette fiche sera complétée dans BlackFury avec la configuration réellement utilisée. Sans elle, parler de performance n’aurait pas beaucoup de valeur.
« En local » ne signifie pas toujours « confidentialité totale »
Un workflow composé uniquement de nœuds natifs et de modèles stockés localement peut traiter les prompts et images sur la machine. C’est un vrai avantage.
Pour replacer cette nuance dans un cadre plus large, le dossier IA locale : gains réels et coûts souvent sous-estimés compare autonomie, confidentialité, matériel et maintenance au-delà du seul cas de ComfyUI.
Mais ComfyUI sait aussi utiliser des nœuds partenaires qui appellent des services externes par API. Les nœuds personnalisés sont du code Python téléchargé depuis des tiers ; ils peuvent installer des dépendances, accéder aux fichiers ou communiquer avec le réseau.
La documentation officielle recommande d’éviter les extensions obscures ou non vérifiées, car un nœud malveillant peut compromettre le système.
Avant d’ouvrir un workflow trouvé sur Internet, je vérifie donc :
- s’il utilise seulement des nœuds natifs ;
- quels nœuds manquent et qui les publie ;
- si un nœud appelle une API ;
- où partent les images d’entrée ;
- quelles clés et dépendances sont demandées ;
- si ComfyUI écoute uniquement sur
localhostou est exposé au réseau.
Je n’expose jamais directement l’interface ComfyUI sur Internet sans authentification, chiffrement et architecture réseau adaptée.
Installer moins de nœuds pour obtenir plus de stabilité
Les extensions rendent ComfyUI extrêmement puissant, mais elles sont aussi la première source de conflits de dépendances et de workflows impossibles à rouvrir.
Pour débuter avec FLUX.1-dev, aucun nœud communautaire n’est nécessaire si l’on utilise le workflow natif officiel. Je commence avec ce socle, je crée une sauvegarde ou un instantané, puis j’ajoute une extension uniquement lorsqu’elle répond à un besoin identifié.
ComfyUI Manager facilite installation, mise à jour, désactivation et suppression. Cela ne dispense pas de vérifier l’auteur, le dépôt, les problèmes ouverts et les dépendances. Un bouton « Install » exécute toujours du code sur la machine.
Sauvegarder un workflow qui survivra aux mises à jour
Pour chaque projet important, je conserve :
- le workflow JSON ;
- une image PNG contenant le workflow lorsque c’est possible ;
- la liste des modèles et leurs sources ;
- la liste des nœuds personnalisés avec version ou commit ;
- une capture du résultat attendu ;
- les paramètres de génération ;
- une note sur le matériel et la durée.
Je sépare les workflows de test des workflows stables. Avant une grosse mise à jour, je sauvegarde l’environnement et je vérifie que le workflow de référence fonctionne encore.
La documentation ComfyUI recommande des mises à jour régulières pour les fonctions et la sécurité, tout en rappelant que les versions stables conviennent mieux aux systèmes où la stabilité prime. Le bon rythme dépend donc de l’usage : laboratoire ou production.
Les mesures qui rendent un test réellement utile
Une affirmation comme « ce modèle fonctionne sur telle carte graphique » ne vaut presque rien sans contexte. Un test reproductible devrait indiquer :
- configuration complète du PC ;
- variante FLUX utilisée ;
- workflow téléchargeable ;
- image générée et paramètres ;
- temps de génération ;
- pic de VRAM ;
- erreurs rencontrées ;
- compromis qualité/performance ;
- consommation électrique si elle peut être mesurée proprement.
Ces données apportent bien plus qu’une promesse du type « une carte de 6 Go suffit ». Elles permettent au lecteur de comparer sa machine à une configuration connue. Tant qu’un essai BlackFury ne fournit pas ces éléments, le présent article reste un guide documentaire et ne revendique aucune performance personnelle.
ComfyUI et FLUX.1-dev en local : garder le contrôle
ComfyUI est un excellent outil pour apprendre et maîtriser une chaîne de génération locale. FLUX.1-dev offre une très bonne compréhension des prompts, mais il reste lourd et possède une licence qui demande d’être lue.
La bonne installation n’est pas celle qui empile le plus de modèles et de nœuds. C’est celle dont on connaît les sources, les versions, les besoins, les flux de données et les conditions d’utilisation.
Commencer avec le workflow officiel, enregistrer un test reproductible et n’ajouter des extensions qu’ensuite demande un peu plus de discipline. C’est aussi ce qui permet de garder réellement le contrôle.
Sources techniques
- ComfyUI — configuration requise : https://docs.comfy.org/installation/system_requirements
- ComfyUI — dépôt officiel : https://github.com/Comfy-Org/ComfyUI
- ComfyUI — workflow officiel FLUX.1 : https://docs.comfy.org/tutorials/flux/flux-1-text-to-image
- ComfyUI — sécurité des nœuds personnalisés : https://docs.comfy.org/installation/install_custom_node
- ComfyUI — nœuds partenaires et appels API : https://docs.comfy.org/tutorials/partner-nodes/overview
- Black Forest Labs — modèle, licence et usages : https://huggingface.co/black-forest-labs/FLUX.1-dev
