Images faites maison avec ComfyUI
Générer une image avec un service en ligne coûte peu, mais coûte à chaque fois. On le paie en crédits qui s'épuisent au milieu du mois, en forfaits gratuits qui se rechargent quand bon leur semble, en règles sur ce que l'on a le droit de demander ou non définies par quelqu'un d'autre. Midjourney, DALL-E et Firefly sont des outils remarquables, mais ils partagent la nature de la location : la maison est magnifique, mais elle n'est pas à moi. C'est de là qu'est partie cette expérience, née comme un essai personnel et devenue un article en cours de route. Je voulais savoir si l'on pouvait produire des images sans coût par rendu, sans compteurs qui décrémentent et sans limites de crédit, en utilisant uniquement l'ordinateur qui se trouve sur mon bureau.
J'avais entendu parler de ComfyUI il y a quelque temps, puis le nom avait glissé hors des radars, comme c'est le cas pour les choses lues une seule fois. Je me le suis retrouvé sous les yeux ces derniers jours en interrogeant, en quête d'inspiration, le wiki LLM que je mets à jour avec Matteo Baccan, un archivage où nous intégrons chaque jour des actualités sur le monde de l'IA, dans le dépôt AINews. Un archive bien tenue sert à cela : elle vous restitue ce que vous aviez oublié d'avoir oublié. La promesse était séduisante : un contrôle granulaire sur chaque étape de la génération, sans abonnement et sans crédits mensuels. La vraie question, cependant, était autre : ma machine en est-elle capable ?
La machine est celle déjà décrite dans le premier épisode sur l'IA à la maison : un Ryzen 7700, 32 Go de RAM DDR5 et une Radeon RX 9060 XT avec 16 Go de mémoire vidéo. Rien d'exotique, un matériel que beaucoup de passionnés reconnaîtraient comme le leur. Elle présente toutefois une caractéristique qui pèse lourd dans les pages qui suivent : la carte est une AMD, pas une NVIDIA, et quiconque suit ce domaine sait que cette différence n'est pas un détail de passionné mais une variable technique.
Nœuds, erreurs et SD 1.5
J'ai installé ComfyUI Desktop sur Windows, attiré par la simplicité par rapport à la version portable. La documentation officielle l'indique pour Windows 10 ou ultérieur avec GPU NVIDIA ou AMD, et voir AMD citée tout naturellement était déjà une bonne nouvelle. La prise en main de l'interface a ensuite procuré une curieuse familiarité : une toile remplie de blocs reliés par des fils est la grammaire exacte de n8n, l'outil d'automatisation que je connais et utilise pour certains processus. Seul le contenu des blocs change, pas l'idée fondamentale, car chaque nœud reçoit un élément, le transforme et le transmet au suivant.
ComfyUI, pour ceux qui ne le connaîtraient pas, est un programme open source qui transforme la génération d'images en une chaîne de montage : chaque phase du processus est un bloc, et c'est à l'utilisateur de décider lesquels connecter et dans quel ordre.
Pour ne pas partir à l'aveuglette, j'ai demandé à la version gratuite de DeepSeek un guide pas à pas, de l'installation au premier flux de travail. Il m'a été utile mais un peu confus, car il est arrivé d'un seul bloc plutôt qu'étape par étape, et il décrivait les blocs avec leurs noms anglais alors que mon ComfyUI les affichait en italien. Quelle part de ce qui s'est passé ensuite incombe au guide et quelle part me revient pour avoir interverti des nœuds aux noms voisins, je ne saurais le dire en toute honnêteté. Probablement un peu des deux.
Le premier obstacle concret a concerné les modèles. Où doit-on les placer ? J'ai cherché dans le dossier d'installation sous Program Files, celui qui semblait évident, et je l'ai trouvé vide. Les modèles résident ailleurs, dans un dossier partagé au sein du profil utilisateur (dans mon cas sous LOCAL/APPDATA, dans Comfy-Desktop puis ComfyUI-Shared, sous models). Un détail logique a posteriori mais invisible a priori. Le second obstacle était plus psychologique : face aux milliers de modèles sur Hugging Face et Civitai, j'ai éprouvé la sensation d'entrer dans une bibliothèque sans catalogue. J'ai décidé de commencer par le plus léger et le plus direct, Stable Diffusion 1.5, dans le fichier v1-5-pruned-emaonly-fp16.safetensors. C'est un modèle de 2022 et cela se voit. La fiche officielle du modèle le place sous licence CreativeML OpenRAIL-M, et l'organisation qui l'héberge se présente désormais comme la gardienne des modèles historiques de Stable Diffusion.
J'ai construit le premier flux bloc par bloc pour en saisir la logique. Load Checkpoint charge le modèle. CLIP Text Encode traduit mon texte en nombres compréhesibles par la machine, une sorte d'interprète simultané. Empty Latent Image est la toile de départ, qui n'est pas blanche mais remplie de bruit, aux dimensions de l'image finale. KSampler est le cœur du système : il part du bruit et le nettoie étape par étape jusqu'à ce qu'émerge quelque chose de reconnaissable, le principe de la diffusion dont j'ai déjà parlé. VAE Decode traduit du langage interne du modèle vers les pixels réels et Save Image les enregistre sur le disque.
L'erreur de débutant ne s'est pas fait attendre : KeyError: 'g'. Le message d'erreur mentionnait un champ, tokens["g"], qui n'existe que dans les modèles SDXL. J'avais placé CLIPTextEncodeSDXL au lieu de CLIPTextEncode, deux nœuds aux noms quasi jumeaux. Cela m'a rappelé Primer, le film de Shane Carruth sorti en 2004 où deux ingénieurs construisent une machine à voyager dans le temps dans un garage et où un seul branchement incorrect fait dérailler l'ensemble. Mon garage était plus modeste, mais la leçon identique : une fois le nœud remplacé par le bon, tout s'est mis à fonctionner. C'est à ce moment-là que j'ai compris la logique modulaire du logiciel et l'importance d'associer le bon nœud au bon modèle.
Puis la première image est arrivée, à partir de mon prompt pour le moins banal : "a cat on a windowsill, sunlight", en 1024x1024. Un désastre : une triple tête superposée, des détails confus, des couleurs étranges. La cause résidait dans la fiche du modèle, qui indique un entraînement en 512x512. De retour à cette résolution, j'ai ajouté au prompt les formules d'usage (masterpiece, best quality, detailed fur, soft lighting, photorealistic) et j'ai ajusté les paramètres du KSampler : étapes montées de 20 à 30, CFG passé de 8 à 7, planificateur changé de simple à karras. Je ne saurais dire quel ingrédient a le plus agi, comme dans tout rituel, mais le résultat s'est grandement amélioré.
Flux change les règles
Le véritable tournant est venu avec Flux.1 schnell, choisi après avoir lu des avis sur sa qualité supérieure. J'ai téléchargé la version FP8 en un fichier unique, un checkpoint dit "all-in-one" qui rassemble modèle, encodeur de texte et découdeur dans un seul paquet. Il pèse environ 17 Go et présente un avantage décisif pour qui expérimente : la licence Apache 2.0, contrairement à son frère dev qui est limité à un usage non commercial.
La surprise a été de découvrir que les paramètres appris péniblement avec SD 1.5 devaient être jetés aux oubliettes. Avec Flux schnell, le CFG reste à 1.0 et non à 7, les étapes sont au nombre de 4 et non de 25-30, et la résolution de départ est de 1024x1024. La version schnell est distillat, c'est-à-dire entraînée à obtenir en très peu d'étapes ce que d'autres modèles font en plusieurs dizaines, et elle s'utilise dans une fourchette de une à quatre étapes. Premier test avec le prompt exactement identique au désastre précédent : très bonne qualité.
Mises côte à côte, la différence entre SD 1.5 et Flux sur le chat au soleil est frappante. Flux comprend le langage naturel bien mieux, n'a pas besoin de mots magiques et produit une image bien plus grande, cohérente même avec une phrase écrite comme la dirait une personne.
Il y a toutefois une réserve esthétique. Flux tend vers un rendu lissé, presque de rendu 3D ou de photo de banque d'images, trop propre pour paraître vrai. J'ai essayé d'atténuer cet effet avec des termes comme film grain, raw photo et unedited, avec des résultats variables. Je ne suis pas le seul à me poser la question. Krea a axé la présentation de Krea 2 en version ouverte précisément sur l'esthétique, proposant son modèle comme le plus soigné parmi ceux aux poids ouverts. C'est une affirmation marketing à prendre comme telle, mais elle montre que la compétition se joue aujourd'hui aussi sur le goût et pas seulement sur la fidélité au prompt.
Après une vingtaine d'essais, les limites de Flux Schnell se sont révélées moins aléatoires que je ne le pensais. Il excelle dans les scènes statiques et le mouvement ne lui fait pas peur : le guépard, la voiture en dérapage et le canard géant sont bien réussis. Le problème survient avec le corps humain en action dynamique, car la course, le coup de pied ou le ski entraînent une fusion ou une multiplication des membres. L'autre point faible concerne le texte, typique des modèles de diffusion. Il s'agit de mes propres observations, basées sur un seul modèle et un seul système.
Le mur de la VRAM
J'ai ensuite fait ce que fait quiconque vient de découvrir un nouveau jouet : j'ai augmenté la résolution. À 1 500 pixels, la génération demandait environ une minute. À 2 048 pixels, il fallait compter cinq ou six minutes. La hausse n'est pas proportionnelle : pour une image carrée, le nombre total de pixels augmente d'un peu moins du double, mais le temps est multiplié par cinq ou six. L'explication la plus plausible — et je souligne plausible car il s'agit d'une hypothèse et non d'un diagnostic — est qu'au-delà d'un certain seuil, la mémoire de la carte ne suffit plus et ComfyUI est contraint de transférer des morceaux de modèle dans un va-et-vient entre la VRAM et la RAM du système. Ce soupçon est renforcé par un fait simple : le fichier de Flux schnell FP8 pèse plus que les 16 Go de ma carte, et un wiki non officiel indique 12 Go comme minimum et 16 Go comme valeur recommandée pour ce modèle. En clair : je suis à la limite, et la limite se fait sentir. Les 32 Go de RAM servent de tampon, mais de tampon lent.
C'est la prise de conscience la plus concrète de toute cette expérience. Ma Radeon est puissante, mais pas illimitée, et avec les modèles locaux, le choix de l'architecture se fait en fonction de la mémoire disponible avant même le goût personnel. Le reste est assuré par les versions quantifiées, copies du modèle utilisant des nombres moins précis et donc plus légères, comme le format FP8 que j'ai utilisé ou les GGUF dont je parlerai dans un instant. Chaque réduction de précision est un compromis entre espace, vitesse et qualité, à évaluer à l'œil au cas par cas.
J'ai été frappé, par contraste, par une autre expérience récente. Avec OmniVoice Studio, sur ce même PC, la carte AMD sous Windows est restée à l'écart et la synthèse vocale s'est effectuée sur le processeur, demandant environ 200 secondes pour dix secondes d'audio. Avec ComfyUI, les choses se sont bien mieux passées : la documentation officielle liste pour AMD sous Windows les paquets ROCm et cite explicitement l'architecture RDNA 4 de ma carte, et j'ai utilisé ROCm sans encombre. Il faut préciser que le wiki non officiel déjà cité qualifie d'expérimentatif le support d'AMD sous Windows ; il s'agit donc d'un domaine en rapide progrès mais pas encore totalement stabilisé. Une même carte graphique, deux destins différents, confirmant que dans l'IA locale, la qualité de communication entre le logiciel et le silicium est capitale.
Cela vaut plus encore pour la vidéo, que je n'ai pour l'instant observée que de l'extérieur. Dans mes articles précédents, Ovi exigeait au moins 24 Go de VRAM et LongCat-Video en demandait environ 60, ou 18 avec la quantification 8 bits sur une RTX 4090. Le paysage évolue. La documentation de ComfyUI affirme que Wan 2.2 dans sa version à 5 milliards de paramètres tient dans environ 8 Go avec le déchargement natif, tandis que le dépôt officiel parle de 24 Go ; son frère de 14 milliards nécessite, pour tourner sur 16 Go, des versions quantifiées selon les retours de la communauté. Et le 12 août 2026 est arrivé sur ComfyUI LTX-2.5, avec des poids ouverts, de l'audio et de la vidéo synchronisés et une promesse affichée par les auteurs de rapidité sur du matériel grand public. Promesse à vérifier sur sa propre carte, comme toujours.
Modifier est un autre métier
Satisfait de la génération à partir de zéro, j'ai essayé de modifier une image existante : une voiture jaune à transformer en rouge, tout le reste demeurant inchangé. Le paramètre qui régit cela est le denoise du KSampler. Selon la documentation, le système ajoute du bruit aux données de l'image originale en fonction de cette valeur, puis laisse le modèle la repeindre ; ainsi, à des valeurs basses cela change peu, à des valeurs hautes cela change tout. Avec SD, cela fonctionne comme un curseur progressif. Avec Flux schnell, j'ai observé un comportement en palier : en dessous de 0,8 l'image ne changeait pas du tout ; à 0,81 le modèle réécrivait tout et perdait la voiture originale. Aucun contrôle, grande frustration.
Je n'ai pas d'explication certaine. Un indice provient d'une discussion sur le forum de FLUX.2 klein 9B, un autre modèle distillé à quatre étapes, où un utilisateur décrit des artefacts croissants à des niveaux de denoise bas et les attribue à l'échantillonnage en très peu d'étapes. Ce n'est ni le même scénario ni le même modèle, je le prends donc comme un soupçon et non comme un verdict. Mon hypothèse de travail est qu'un modèle conçu pour tout faire en quatre coups manque de finesse pour régler un curseur, et qu'en tout état de cause l'img2img agit sur l'ensemble de l'image et non sur une partie. Pour des modifications ciblées, il existe des outils conçus à cet effet.
Le plus prometteur est FLUX.1 Kontext dev, un modèle de 12 milliards de paramètres dédié exclusivement à l'édition guidée par des instructions textuelles, sous la même licence non commerciale que Flux dev. Il affirme pouvoir tourner sur du matériel grand public, mais le calcul est vite fait. Un modèle de 12B occupe de l'ordre de 24 Go en pleine précision, à l'instar de Flux dev qui pèse 23,8 Go, environ 12 Go en FP8 et environ 7 Go dans une quantification GGUF 4 bits (estimations personnelles approximatives). Sur ma carte, la version FP8 serait lente et la GGUF représenterait un compromis intéressant. Ces deux essais restent à effectuer.
Entre-temps, une voie plus commode est apparue. Black Forest Labs a publié au début de l'année 2026 la famille FLUX.2 klein, des modèles réduits de 4 et 9 milliards de paramètres, conçus pour tourner sur du matériel grand public et capables de générer et modifier des images. La version à 4 milliards est sous licence Apache 2.0, celle à 9 milliards sous licence non commerciale. La mémoire réellement nécessaire varie selon les sources : le dépôt parle d'environ 8 Go, la documentation officielle d'environ 13 Go. Dans les deux cas, ma carte les accueille très confortablement, et la prochaine expérience est déjà décidée.
La liberté avec la facture d'électricité
Avant de faire les comptes, il convient de définir ce qu'est réellement ComfyUI, car mon essai n'en a effleuré que la surface. Le système de blocs n'est pas un caprice d'interface mais sa raison d'être : la même méthode de travail qui m'a permis de générer un chat sert à modifier une image existante, comme j'ai tenté de le faire avec la voiture jaune, ainsi qu'à la vidéo, que ses développeurs soutiennent par des mises à jour dédiées à chaque nouveau modèle d'importance. On change de tâche en changeant les blocs, pas l'outil. Un flux se sauvegarde, se répète à l'identique, se partage et se modifie à partir de modèles prêts à l'emploi. C'est la différence entre un appareil ménager et un établi : le premier fait bien une chose, le second demande d'apprendre à l'utiliser mais permet de fabriquer ce dont on a besoin. Le prix, comme on le verra, est la patience.
Si cette expérience m'a appris quelque chose, c'est que "gratuit" est un mot à manier avec précaution. Les avantages du local sont réels et je les ai touchés du doigt. Chaque image supplémentaire n'a aucun coût marginal, si bien qu'expérimenter devient un geste léger et que l'on essaie sans y penser, comme on ne le fait que lorsqu'aucun compteur ne tourne. Les données et les images restent sur ma machine. Et le contrôle est total, au sens où chaque paramètre est à portée de main et où l'on apprend en faisant, y compris en se trompant.
L'architecture aide aussi. ComfyUI sépare nettement le moteur, les modèles et les extensions, si bien que l'on peut changer de modèle sans refaire le flux ou ajouter des fonctionnalités sans toucher au cœur. Il existe une communauté qui produit des nœuds personnalisés, rassemblés dans un registre public et gérés avec ComfyUI-Manager, qui est déjà inclus dans la version Desktop (la documentation officielle, dans ce cas, est consultable en coréen). Les flux de travail prêts à être modifiés abondent, avec une astuce que j'ai trouvée élégante : les images enregistrées emportent avec elles le flux qui les a générées, si bien qu'il suffit de faire glisser un fichier PNG sur la toile pour reproduire le travail. La réproductibilité, pour qui veut comprendre et pas seulement consommer, est un trésor.
Le revers de la médaille est fait de trois choses. La première est le matériel, dont j'ai parlé. La deuxième est le coût caché : la carte, l'électricité, l'espace disque, et surtout le temps, qui dans mon cas est parti dans de mauvais dossiers, des nœuds intervertis et des essais infructueux. La troisième est la fragmentation des licences. Chaque modèle a ses règles d'usage et sa licence : SD 1.5 avec OpenRAIL-M, Flux dev et Kontext dev avec des licences non commerciales, Flux schnell et klein 4B avec Apache 2.0, klein 9B à nouveau non commercial. Les licences varient, et quiconque souhaite en faire un usage professionnel doit les lire attentivement sans se fier à un résumé.
Il y a ensuite une question de perspective. Les entreprises qui publient des modèles ouverts les accompagnent souvent de services payants : Black Forest Labs propose aussi klein via API, pour quelques centimes par image, et les mêmes poids que je télécharge gratuitement alimentent une grille tarifaire commerciale. Pour qui expérimente, c'est une bonne nouvelle, car le local reste une porte ouverte. Ceux qui y gagnent le plus sont les entreprises, qui utilisent la communauté comme banc d'essai, et les fabricants de GPU, en particulier NVIDIA, qui figure encore dans le wiki comme la référence en matière de performances et de compatibilité. Ceux qui risquent de rester sur le carreau sont les utilisateurs possédant une machine ancienne, pour qui la liberté du local n'est accessible que théoriquement. Une question ouverte concerne la comparaison avec le cloud : je n'ai pas fait de tests directs, mais il est clair que les modèles propriétaires de frontière restent supérieurs, en particulier pour la génération de figures humaines. Les deux approches représentent deux façons différentes de concevoir et d'accéder à un outil.
Qui devrait essayer ?
Je conseillerais cette aventure à quiconque cherche le contrôle et la confidentialité et ne craint pas de passer un après-midi derrière un message d'erreur. Ceux qui disposent d'au moins 12 Go de VRAM partent dans des conditions raisonnables, et avec 16 Go comme dans mon cas, on travaille confortablement tant que l'on ne monte pas la barre trop haut. Le profil idéal est celui du curieux prêt à se mettre les mains dans le cambouis, quelqu'un qui apprécie le moment où un nœud trouve sa place. Je le déconseille à ceux qui cherchent une solution clé en main, de celles où l'on tape une phrase et où l'on obtient une image sans jamais croiser une variable, ainsi qu'à ceux qui ont un matériel limité et peu d'envie d'attendre.
Le bilan personnel est positif, avec quelques réserves. J'ai appris que le bon nœud doit aller avec le bon modèle, que chaque famille de modèles possède son propre vocabulaire de paramètres et que les chiffres d'une fiche technique ne racontent que la moitié de l'histoire. J'ai obtenu des images de bonne qualité avec Flux en partant de zéro. J'ai mesuré les limites : la mémoire, la complexité, des modèles encore trop lourds pour certains usages. L'img2img et la vidéo restent des évolutions futures, car la partie qui m'intéressait aujourd'hui était la création "text to image" à partir de zéro en local, et celle-ci a fonctionné.
Cela me rappelle Dungeon Meshi, le manga de Ryoko Kui dans lequel un groupe d'aventuriers traverse un labyrinthe en cuisinant les monstres qu'il rencontre, avec ce qu'il trouve et en apprenant les recettes à ses dépens. L'IA en local partage ce même esprit d'autosuffisance, avec une bonne dose de risque d'intoxication. Ce n'est pas une alternative gratuite aux services cloud, c'est autre chose : un écosystème où la personnalisation et l'apprentissage sont possibles d'une manière impensable avec un abonnement. La prochaine étape consiste à tester klein 4B et un Kontext quantifié, avec le chat sur le rebord de la fenêtre qui attend de changer de couleur.
Note technique : Les données sur les dimensions, licences et prérequis sont vérifiées d'après les sources liées en octobre 2026 et peuvent évoluer. Les temps de génération sont des observations personnelles sur un système unique (Ryzen 7700, 32 Go DDR5, RX 9060 XT 16 Go, Windows, ComfyUI Desktop avec ROCm), et non des bancs d'essai comparatifs officiels.