ComfyUI

Présentation

Une image doit être générée.

Il faut charger un modèle.

Écrire un prompt.

Choisir une résolution.

Ajouter un LoRA.

Utiliser une image de référence.

Contrôler la pose.

Corriger le visage.

Passer le résultat dans un second modèle.

L’agrandir.

Puis transformer cette image en vidéo.

Dans beaucoup d’outils, ces opérations apparaissent sous forme de boutons, onglets et options dont les relations restent cachées.

Dans ComfyUI, on pose tout sur la table.

Littéralement.

ComfyUI transforme le pipeline de génération en graphe visuel : chaque modèle, paramètre, transformation et sortie devient un nœud que l’on peut connecter aux autres.

Le modèle cesse d’être une boîte noire entourée d’un bouton Generate.

On voit ce qui entre.

On voit ce qui sort.

Et surtout, on décide ce qui se passe entre les deux.

Cette logique explique à la fois la puissance de ComfyUI et son apparence légèrement intimidante.

Un premier workflow peut contenir sept blocs.

Un projet vidéo avancé peut en afficher plusieurs dizaines, reliés par suffisamment de câbles pour donner l’impression qu’un ingénieur réseau a décidé de se reconvertir dans l’art génératif.

Mais derrière cette complexité visuelle se cache une idée remarquablement simple :

ComfyUI ne vous donne pas seulement un générateur. Il vous laisse construire le générateur dont vous avez besoin.

Bien plus qu’une interface pour Stable Diffusion

ComfyUI est né dans l’écosystème des modèles de diffusion et reste fortement associé à Stable Diffusion.

Cette définition ne suffit plus.

Le moteur peut aujourd’hui orchestrer des workflows autour de nombreuses familles de modèles destinées à :

• l’image ;
• l’édition d’image ;
• la vidéo ;
• l’audio ;
• la 3D ;
• la segmentation ;
• l’upscaling ;
• les modèles multimodaux ;
• certains modèles de langage ;
• des traitements intermédiaires ;
• des services IA accessibles par API.

Les modèles changent rapidement.

L’architecture reste.

Un workflow utilisant SDXL peut céder la place à Flux, Qwen Image ou une autre famille.

Une chaîne vidéo peut utiliser Wan, LTX ou HunyuanVideo.

Un nœud peut générer une image localement tandis qu’un autre appelle un modèle propriétaire distant.

Cette capacité à remplacer les briques sans reconstruire toute la logique constitue probablement l’une des qualités les plus importantes de ComfyUI.

Le modèle est une pièce.

Le workflow est la méthode.

Une interface de programmation sans vraiment programmer

ComfyUI appartient à la famille des outils de programmation visuelle.

Chaque nœud réalise une opération.

Une connexion transmet une donnée.

Un workflow simple peut ressembler à ceci :

modèle → prompt → latent → sampler → décodage → image

Mais rien n’oblige à s’arrêter là.

Une image peut être envoyée vers un ControlNet.

Une autre peut devenir une référence.

Un masque peut isoler une zone.

Un upscale peut être suivi d’une nouvelle passe de diffusion.

Le résultat peut ensuite entrer dans un modèle vidéo.

La vidéo peut être interpolée, améliorée ou accompagnée d’une piste audio.

Cette logique transforme progressivement l’utilisateur.

Au début, il cherche le bon prompt.

Puis il commence à chercher le bon processus.

C’est une évolution importante.

Le prompt décrit une intention.

Le workflow décrit la manière dont la machine va essayer de la réaliser.

Local, Cloud et Partner Nodes : trois manières d’utiliser Comfy

L’écosystème Comfy possède désormais plusieurs couches qu’il faut distinguer.

Cette distinction évite une confusion devenue fréquente.

ComfyUI lui-même reste gratuit.

Un workflow constitué uniquement de modèles installés localement peut fonctionner sans abonnement et sans consommation de crédits.

En revanche, lorsqu’un nœud appelle un service distant payant ou lorsque le workflow est exécuté dans Comfy Cloud, des crédits peuvent être consommés.

Le même canvas peut donc représenter deux philosophies presque opposées :

un atelier entièrement local, contrôlé par son propriétaire ;

ou une interface commune reliant ressources locales et services cloud.

Une recette qui peut voyager

Un workflow ComfyUI peut être sauvegardé comme fichier JSON.

Les images PNG générées peuvent également embarquer des métadonnées liées au workflow.

Cette petite particularité explique une partie de la culture ComfyUI.

Une image n’est plus seulement une image.

Elle peut conserver une trace de la manière dont elle a été produite.

Lorsque les modèles et nœuds nécessaires sont disponibles, le workflow peut être rouvert, étudié, modifié puis exécuté à nouveau.

La création devient donc plus reproductible.

Au lieu d’écrire :

« Je crois que j’avais utilisé ce modèle, un CFG autour de 5, peut-être cette LoRA et probablement un sampler différent. »

on peut parfois simplement rouvrir la recette.

Pour un outil fondé sur des systèmes probabilistes, conserver la mémoire du processus représente déjà une petite victoire contre le chaos.

Fonctionnalités

Construire des workflows avec des nœuds

Le canvas constitue le cœur de ComfyUI.

Chaque opération est représentée par un nœud possédant des entrées, des sorties et différents paramètres.

Les connexions indiquent comment les données circulent.

Dans un workflow d’image classique, on peut rencontrer des éléments comme :

• chargement du modèle ;
• encodeur de texte ;
• prompt positif ;
• prompt négatif ;
• génération du latent ;
• sampler ;
• scheduler ;
• VAE ;
• sauvegarde de l’image.

Un workflow plus complexe peut ajouter références, masques, ControlNet, LoRA, upscale, détection, segmentation, compositing et autres transformations.

L’intérêt n’est pas simplement de rendre visible un pipeline existant.

Il est de pouvoir le modifier.

Un nœud peut être remplacé.

Une branche peut être ajoutée.

Une sortie peut alimenter plusieurs traitements.

Deux méthodes peuvent être comparées dans le même graphe.

On ne navigue plus entre quinze panneaux pour comprendre ce que fait le logiciel.

Le problème inverse apparaît : tout est visible.

Absolument tout.

La transparence possède parfois un goût très prononcé de câble spaghetti.

Contrôler l’inférence en profondeur

Les interfaces génératives simples masquent souvent une partie des réglages techniques.

ComfyUI les expose.

Selon les modèles utilisés, le workflow peut contrôler des paramètres comme :

• seed ;
• nombre de steps ;
• sampler ;
• scheduler ;
• CFG ;
• résolution ;
• conditioning ;
• denoise ;
• VAE ;
• encodeurs ;
• précision des modèles ;
• ordre des traitements ;
• passages successifs.

Cette granularité devient intéressante lorsqu’un utilisateur cherche à comprendre pourquoi deux générations se comportent différemment.

Le modèle n’est qu’une partie de l’équation.

Le sampler change la manière dont le bruit est retiré.

Le nombre d’étapes modifie le calcul.

Le denoise détermine jusqu’où une image d’origine peut être transformée.

Le seed peut permettre de comparer plusieurs réglages à partir d’une base similaire.

ComfyUI rend donc visible quelque chose que les interfaces plus simples préfèrent souvent cacher :

une génération est un processus, pas un bouton.

Combiner checkpoints, LoRA et autres composants

Les modèles modernes ne se résument plus toujours à un unique fichier.

Un workflow peut utiliser plusieurs composants :

• checkpoint ou diffusion model ;
• VAE ;
• text encoder ;
• CLIP Vision ;
• LoRA ;
• ControlNet ;
• upscale model ;
• modèles de détection ;
• modèles de segmentation ;
• modèles audio ou vidéo spécialisés.

ComfyUI permet de construire explicitement ces associations.

Plusieurs LoRA peuvent être appliquées.

Des modèles différents peuvent intervenir à plusieurs endroits du même pipeline.

Une première étape peut générer la composition.

Une seconde corrige les détails.

Une troisième agrandit l’image.

Une quatrième transforme le résultat.

Cette modularité explique pourquoi ComfyUI accompagne relativement bien l’évolution extrêmement rapide de l’IA générative.

Lorsqu’une nouvelle méthode apparaît, elle peut souvent devenir une nouvelle brique plutôt qu’exiger une nouvelle application complète.

Travailler avec de nombreuses familles de modèles

Le catalogue compatible évolue presque constamment.

ComfyUI prend aujourd’hui en charge des workflows autour de nombreuses familles d’image et de vidéo, notamment SDXL, Stable Diffusion 3.5, Flux, Qwen Image, Wan, LTX Video, HunyuanVideo et bien d’autres.

Des modèles peuvent également intervenir pour :

• l’édition d’image ;
• l’inpainting ;
• l’outpainting ;
• la profondeur ;
• la pose ;
• la segmentation ;
• l’interpolation ;
• la génération audio ;
• la 3D ;
• l’upscaling.

La liste devient rapidement absurde à maintenir dans une fiche.

Et c’est précisément le point.

La valeur de ComfyUI ne vient pas d’une liste figée de modèles compatibles.

Elle vient de son architecture permettant d’intégrer les suivants.

Le meilleur moteur de 2026 n’existera peut-être plus sous la même forme dans deux ans.

Un environnement de workflow possède davantage de chances de survivre à cette rotation qu’une interface construite autour d’un unique modèle.

Utiliser les Workflow Templates

Commencer devant un canvas vide n’est pas toujours une excellente expérience.

ComfyUI fournit désormais un navigateur de Workflow Templates.

Ces modèles de workflow proposent des configurations prêtes à l’emploi pour différentes familles de modèles et usages.

Lors du chargement d’un template officiel, ComfyUI peut vérifier la présence des fichiers nécessaires et signaler les modèles manquants.

Sur Desktop, certains téléchargements peuvent être gérés directement.

Cette approche réduit considérablement la première marche.

Au lieu de demander à un débutant de comprendre immédiatement pourquoi un text encoder doit être relié à un sampler qui reçoit lui-même un latent produit ailleurs, le template lui montre une construction déjà fonctionnelle.

Il peut alors modifier une partie.

Puis une autre.

Puis comprendre progressivement pourquoi tout s’écroule lorsqu’il débranche le câble violet qu’il pensait décoratif.

Conserver le workflow dans les images

Le nœud Save Image peut enregistrer les générations en PNG avec des métadonnées de workflow.

Une image issue de ComfyUI peut donc conserver les paramètres ayant participé à sa création.

Cette fonction devient utile pour :

• archiver les expérimentations ;
• retrouver un ancien workflow ;
• transmettre une méthode ;
• analyser une génération ;
• reproduire une image avec d’autres paramètres ;
• partager un pipeline.

Cette manière de considérer l’image comme porteuse de son processus est élégante.

Elle rapproche le résultat final du fichier source.

Une image JPEG exportée d’un logiciel de peinture ne contient généralement pas les calques du document original.

Avec ComfyUI, un PNG peut parfois vous rappeler comment la cuisine était organisée au moment où le plat est sorti.

Étendre ComfyUI avec les Custom Nodes

Le système de custom nodes constitue l’une des principales raisons de l’explosion de l’écosystème ComfyUI.

Des développeurs peuvent créer leurs propres nœuds pour ajouter de nouvelles fonctions.

Ils peuvent intégrer :

• nouveaux modèles ;
• preprocessors ;
• traitements d’image ;
• outils vidéo ;
• loaders ;
• systèmes de contrôle ;
• interfaces ;
• automatisations ;
• services externes ;
• fonctions utilitaires.

Cela transforme ComfyUI en plateforme extensible.

Une fonctionnalité qui n’existe pas dans le cœur du logiciel peut déjà être disponible dans un package communautaire.

Cette vitesse est extraordinaire.

Elle possède un prix.

Chaque extension introduit également du code, des dépendances et une version supplémentaire susceptible de décider qu’elle ne souhaite plus collaborer avec le reste de l’installation mardi matin.

Installer et maintenir les extensions avec ComfyUI Manager

ComfyUI Manager simplifie la gestion des custom nodes.

Dans les versions actuelles, il permet notamment de :

• rechercher des extensions ;
• les installer ;
• les mettre à jour ;
• les désactiver ;
• identifier des nœuds manquants ;
• gérer certains modèles ;
• créer des snapshots ;
• restaurer certains états de l’installation.

Lorsqu’un workflow importé contient des nœuds absents, le Manager peut aider à retrouver les packages correspondants.

Cette fonction est essentielle dans un écosystème où les workflows circulent entre utilisateurs.

Sans elle, recevoir un graphe avancé pourrait rapidement devenir un jeu d’enquête :

« UltimateImageLoaderAdvanced vient de quel dépôt GitHub déjà ? »

Le Manager ne supprime pas tous les problèmes de dépendances.

Il transforme simplement une partie de l’archéologie en gestion de packages.

Centraliser les extensions avec le Comfy Registry

Le Comfy Registry constitue un catalogue public de custom nodes.

Les développeurs peuvent y publier, versionner et déprécier leurs packages.

Le Registry utilise également un système de versionnement afin de mieux identifier les composants utilisés dans les workflows.

Cette logique répond à une difficulté importante.

Un workflow fonctionne aujourd’hui.

Un custom node reçoit une mise à jour demain.

Son API change.

Le workflow cesse de fonctionner.

En enregistrant plus précisément les versions, ComfyUI cherche à rendre les pipelines plus reproductibles.

Le Registry participe également à la vérification de certains packages et alimente le Manager.

Cela ne transforme pas automatiquement tout plugin communautaire en logiciel parfaitement sûr.

Mais l’écosystème commence à se doter de mécanismes plus proches d’un véritable gestionnaire de dépendances que du traditionnel :

« Télécharge ce ZIP trouvé dans un commentaire Discord et mets-le dans custom_nodes. »

Le progrès possède parfois des formes très concrètes.

Simplifier les graphes avec les Subgraphs

Les grands workflows deviennent rapidement difficiles à lire.

Les Subgraphs permettent de regrouper plusieurs nœuds dans un seul bloc réutilisable.

Un ensemble consacré à l’upscale peut devenir un subgraph.

Un traitement de masque peut devenir un autre.

Un système complexe peut ainsi être découpé en modules.

Les subgraphs peuvent également être imbriqués et transformés en composants réutilisables.

Cette fonction rapproche ComfyUI de la programmation modulaire.

Au lieu de recopier vingt nœuds dans chaque projet, on construit une fonction visuelle.

Elle reçoit certaines entrées.

Elle réalise son travail.

Elle renvoie des sorties.

Le canvas respire à nouveau.

Enfin, jusqu’au moment où quelqu’un ouvre le subgraph et découvre les quarante-sept nœuds que l’on avait soigneusement cachés dedans.

Exécuter seulement une partie du workflow

La Partial Execution permet de lancer uniquement la partie du graphe nécessaire à une sortie sélectionnée.

Cela devient précieux dans les workflows lourds.

Un pipeline peut générer une image, l’agrandir puis produire plusieurs variantes.

Si l’on souhaite tester uniquement une branche, recalculer l’ensemble n’est pas toujours nécessaire.

Cette logique réduit :

• le temps de calcul ;
• l’utilisation GPU ;
• les générations inutiles ;
• les coûts dans certains environnements cloud ;
• l’attente lors des expérimentations.

ComfyUI possède également une logique d’exécution qui peut réutiliser certains résultats lorsqu’une partie du graphe n’a pas changé.

L’utilisateur finit donc par apprendre une nouvelle discipline :

modifier juste ce qu’il faut pour éviter de demander à la carte graphique de refaire deux minutes de calcul parce qu’un mot a changé dans la dernière branche.

Transformer un graphe complexe en interface avec App Mode

Une des critiques historiques de ComfyUI est évidente.

Les workflows peuvent devenir incompréhensibles pour quelqu’un qui ne les a pas construits.

App Mode tente de résoudre ce problème.

Le créateur du workflow peut sélectionner les paramètres qui doivent être exposés à l’utilisateur final :

• prompt ;
• image d’entrée ;
• choix de modèle ;
• intensité ;
• résolution ;
• autres contrôles utiles.

Le reste du graphe reste caché derrière une interface simplifiée.

Le workflow devient alors presque une petite application.

Cette approche change beaucoup de choses pour le partage.

Un technical artist peut construire un pipeline complexe.

Un illustrateur peut ensuite l’utiliser sans devoir comprendre chaque connexion.

Une équipe peut distribuer une méthode plutôt qu’un diagramme électrique.

App Mode permet de garder toute la complexité sous le capot sans obliger chaque passager à apprendre la mécanique.

Installer plus simplement avec Comfy Desktop

L’installation traditionnelle de ComfyUI demande de manipuler Python, PyTorch, pilotes GPU, dossiers de modèles et dépendances.

Comfy Desktop vise à simplifier cette partie.

Le launcher moderne peut gérer plusieurs instances de ComfyUI.

Chaque instance possède ses propres :

• versions ;
• custom nodes ;
• paramètres ;
• environnement Python.

Cette isolation devient intéressante pour les utilisateurs avancés.

Une instance peut rester stable pour un projet important.

Une autre peut servir à tester les dernières nouveautés.

Une troisième peut accueillir ce custom node trouvé à une heure du matin et dont l’installation commence par une phrase rassurante comme :

« This may break some dependencies. »

Desktop prend officiellement en charge des installations préconstruites sur Windows et macOS Apple Silicon. Le cœur de ComfyUI peut également fonctionner sous Linux avec une installation adaptée.

Exécuter les workflows dans Comfy Cloud

Comfy Cloud propose la même logique de workflow sans nécessiter de GPU local.

L’environnement est accessible depuis le navigateur.

Les modèles et de nombreux custom nodes populaires sont préinstallés.

Comfy indique utiliser des GPU RTX 6000 Pro Blackwell avec 96 Go de VRAM pour son infrastructure Cloud.

Cela ouvre des workflows difficiles à lancer sur une machine personnelle.

Des modèles vidéo lourds peuvent devenir accessibles depuis un ordinateur portable.

Le cloud propose également une bibliothèque de centaines de modèles déjà disponibles.

Le fonctionnement reste basé sur des crédits.

Créer ou modifier le graphe ne consomme rien.

Les crédits sont utilisés lorsque le GPU exécute le workflow ou lorsqu’un Partner Node payant est appelé.

Le cloud transforme donc le problème matériel :

on ne se demande plus si l’on possède suffisamment de VRAM.

On commence à regarder le compteur de crédits.

Les problèmes changent.

Ils ne disparaissent jamais complètement. C’est probablement une loi fondamentale de l’informatique.

Importer certains modèles personnels dans le Cloud

Les offres supérieures de Comfy Cloud permettent d’importer certains modèles et LoRA depuis des plateformes comme Hugging Face ou CivitAI.

Cela permet de rapprocher un environnement cloud d’un setup local personnalisé.

Cette possibilité reste néanmoins plus encadrée qu’une installation locale.

Le Cloud privilégie des formats sûrs comme Safetensors et une infrastructure gérée.

L’utilisateur ne possède pas le même accès arbitraire à l’environnement Python ou au système.

Cette différence résume assez bien les deux philosophies.

Local : liberté maximale, maintenance personnelle.

Cloud : environnement contrôlé, maintenance déléguée.

Appeler des modèles propriétaires avec Partner Nodes

Les Partner Nodes permettent d’insérer des services externes directement dans un workflow.

Un nœud peut appeler un modèle propriétaire hébergé chez un partenaire sans demander à l’utilisateur de construire lui-même toute l’intégration API.

L’écosystème officiel propose des fournisseurs dans plusieurs domaines :

• image ;
• vidéo ;
• texte ;
• audio ;
• 3D ;
• upscale.

Des modèles issus de fournisseurs comme OpenAI, Google, ByteDance, Kling, Runway, Luma, Black Forest Labs, Ideogram, Recraft, MiniMax, Tripo ou Meshy peuvent apparaître sous forme de nœuds partenaires selon le catalogue actuel.

Cette approche donne à ComfyUI une position intéressante.

Le workflow peut mélanger :

modèle open source local → traitement local → modèle propriétaire distant → post-traitement local

sans quitter le canvas.

Le mot « local » mérite donc une petite astérisque.

Un workflow ComfyUI peut être totalement local.

Mais un workflow ComfyUI peut également appeler Internet avec enthousiasme dès qu’on lui connecte les bons nœuds.

Transformer les workflows en API

ComfyUI peut fonctionner comme backend.

Son API locale permet d’envoyer des workflows, fournir des entrées, suivre l’exécution et récupérer les résultats.

Comfy Cloud propose également une API destinée aux workflows hébergés.

Cela permet d’intégrer ComfyUI dans :

• une application ;
• un site web ;
• un outil interne ;
• un pipeline automatisé ;
• un traitement batch ;
• un service de génération ;
• un logiciel créatif.

Le workflow visuel devient alors l’équivalent d’un programme.

L’interface sert à le construire et le tester.

L’application l’appelle ensuite sans afficher nécessairement le graphe à l’utilisateur final.

Cette combinaison est particulièrement intéressante pour les développeurs qui ne souhaitent pas recoder en Python toute une chaîne de modèles déjà validée visuellement.

Connecter des agents grâce à MCP

Comfy développe également des outils autour du Model Context Protocol — MCP.

L’objectif consiste à permettre à certains assistants ou agents IA de lancer et manipuler des workflows par langage naturel.

Un agent peut potentiellement :

• rechercher des modèles ;
• rechercher des nœuds ;
• sélectionner un workflow ;
• générer une image ;
• générer une vidéo ;
• produire de l’audio ;
• lancer une génération 3D.

Comfy Cloud MCP reste encore en évolution et certaines fonctions peuvent être en bêta ou accessibles progressivement.

Mais la direction est intéressante.

Le workflow n’est plus seulement utilisé par un humain cliquant sur Run.

Il devient une capacité qu’un autre système logiciel peut appeler.

ComfyUI commence alors à devenir une sorte de moteur graphique pour agents créatifs.

Développer ses propres nœuds

ComfyUI est écrit principalement en Python et possède une architecture conçue pour être étendue.

Un développeur peut créer un custom node pour intégrer :

• un modèle ;
• une API ;
• un algorithme ;
• une interface ;
• une transformation ;
• un outil interne de studio.

Cette extensibilité transforme ComfyUI en infrastructure.

Un studio n’est pas obligé d’attendre qu’une fonction particulière soit ajoutée officiellement.

Il peut développer son propre composant et le placer directement dans les workflows de l’équipe.

La frontière entre utilisateur et développeur devient alors très fine.

On commence par déplacer des nœuds.

Puis on modifie un JSON.

Puis un petit script Python.

Puis, à un moment assez difficile à dater précisément, on possède un dépôt GitHub et trois personnes demandent pourquoi la version 1.4 du node interne casse leur workflow de vendredi.

Bienvenue dans le développement logiciel.

Cas d’usage

Construire un pipeline de création de personnages

Un artiste doit générer régulièrement le même type de personnage.

Il souhaite contrôler :

• le modèle ;
• plusieurs LoRA ;
• la pose ;
• le visage ;
• la profondeur ;
• la résolution ;
• l’upscale final.

Dans une interface classique, il faudrait reconfigurer plusieurs options à chaque génération.

Dans ComfyUI, le workflow est construit une fois.

Les paramètres qui changent régulièrement peuvent être placés dans des zones facilement accessibles ou exposés via App Mode.

Le reste devient la méthode de production.

L’artiste ne réinvente plus son pipeline à chaque image.

Il modifie ses entrées.

Cette distinction devient particulièrement précieuse lorsque plusieurs centaines d’images doivent partager les mêmes règles.

Construire une planche de character design

Un workflow peut recevoir une image ou une identité de départ.

Plusieurs branches produisent ensuite différentes vues.

Une branche travaille le portrait.

Une autre la silhouette complète.

Une autre la pose.

Une autre agrandit certains détails.

Des systèmes de contrôle peuvent aider à orienter la pose, la composition ou les références.

Les sorties peuvent être enregistrées séparément puis réunies dans un autre outil.

ComfyUI ne devient pas automatiquement un logiciel de character design.

Il permet de construire une machine spécialisée pour une étape précise du character design.

Cette distinction est fondamentale.

L’outil généraliste devient le matériau avec lequel on fabrique son outil personnel.

Créer une chaîne image vers vidéo

Une image est générée avec un modèle spécialisé.

Elle passe ensuite par une étape de correction.

Le visage est restauré ou affiné.

Une version agrandie est créée.

Cette image est envoyée dans un modèle image-to-video.

Les images intermédiaires peuvent ensuite être interpolées ou améliorées.

Tout ce pipeline peut vivre dans le même graphe.

Un workflow pourrait par exemple suivre cette logique :

prompt → image → référence → correction → upscale → vidéo → interpolation → export

Le principal avantage n’est pas seulement la quantité d’outils.

C’est leur connexion.

L’image validée devient automatiquement l’entrée de la vidéo.

Aucun dossier temp_final_good_version_3 n’est théoriquement nécessaire.

En théorie.

Nous parlons toujours d’êtres humains travaillant avec des fichiers.

Automatiser plusieurs variantes d’une image

Un studio doit produire vingt variations d’un visuel.

Même composition.

Même personnage.

Différentes couleurs, prompts ou seeds.

ComfyUI peut automatiser ces déclinaisons avec des branches, batches ou paramètres variables.

Les résultats peuvent être générés en série.

Cette approche devient utile pour :

• publicité ;
• concept art ;
• tests de style ;
• variations de personnages ;
• recherche visuelle ;
• assets de jeux ;
• réseaux sociaux.

La génération cesse d’être une suite de clics manuels.

Elle devient un traitement.

Créer un pipeline d’upscale et de restauration

Une image ancienne ou générée doit être améliorée.

Un workflow peut combiner plusieurs étapes :

1. chargement de l’image ;
2. détection ou segmentation ;
3. restauration ;
4. upscale ;
5. légère passe de diffusion ;
6. correction de visage ;
7. export.

Chaque étape reste visible.

Le créateur peut comparer différentes branches.

L’une conserve davantage l’image originale.

L’autre reconstruit davantage de détails.

Cette visibilité évite de réduire l’upscale à un mystérieux curseur « Enhance ».

On peut voir exactement où l’image commence à devenir meilleure.

Et où le modèle commence éventuellement à inventer une nouvelle paire de boucles d’oreilles qui n’existait absolument pas sur la photographie originale.

Travailler entièrement en local

Une illustratrice possède une machine suffisamment puissante et souhaite conserver ses fichiers sur son ordinateur.

Elle installe ses modèles localement et construit des workflows qui ne nécessitent aucun Partner Node.

Les images, prompts et modèles restent alors dans son environnement local.

ComfyUI peut même fonctionner sans compte pour ces usages open source locaux.

Cette possibilité devient importante pour :

• projets confidentiels ;
• prototypes ;
• données internes ;
• œuvres non publiées ;
• utilisateurs refusant une dépendance systématique au cloud.

Elle n’élimine pas toute question de sécurité.

Les custom nodes sont du code exécuté localement.

Installer un plugin douteux sur une machine privée reste une façon assez créative de transformer un avantage de confidentialité en problème de cybersécurité.

Utiliser un modèle propriétaire au milieu d’un pipeline local

Un créateur préfère travailler localement mais souhaite utiliser ponctuellement un modèle inaccessible sur sa machine.

Il construit la majorité du workflow avec des modèles locaux.

Une branche utilise ensuite un Partner Node.

Le résultat revient dans le workflow et reçoit un post-traitement local.

Cette architecture hybride permet de choisir où chaque étape doit s’exécuter.

La question n’est plus :

« local ou cloud ? »

Elle devient :

« quelles parties ont réellement besoin du cloud ? »

C’est une approche beaucoup plus intéressante.

Elle permet de réserver les ressources payantes aux étapes qui apportent réellement quelque chose.

Tester rapidement un nouveau modèle

Un nouveau modèle d’image apparaît.

Les fichiers sont publiés.

ComfyUI ajoute ou reçoit les nœuds nécessaires.

Un template circule dans la communauté.

Un utilisateur peut rapidement comparer ce modèle avec son pipeline actuel.

Même référence.

Même résolution.

Traitements similaires.

Deux branches.

Deux résultats.

Cette culture de l’expérimentation explique pourquoi ComfyUI est devenu l’un des endroits où les nouveaux modèles sont testés très rapidement.

Il ne faut pas reconstruire toute une application autour de chaque nouveauté.

Il suffit souvent d’intégrer une nouvelle brique au graphe.

Partager un workflow avec une équipe

Un technical artist construit un pipeline de génération complexe.

Les autres membres de l’équipe n’ont pas besoin de connaître le détail du sampler, du ControlNet ou des modèles intermédiaires.

Le workflow peut être préparé avec App Mode.

Quelques paramètres sont exposés :

• prompt ;
• référence ;
• style ;
• résolution.

L’utilisateur clique sur Run.

Le pipeline reste identique pour tous.

Cette approche peut améliorer la reproductibilité.

Le technical artist contrôle la méthode.

Les artistes contrôlent les entrées créatives.

ComfyUI commence alors à ressembler moins à un outil personnel qu’à une infrastructure de studio.

Transformer un workflow en fonctionnalité logicielle

Une équipe développe un outil de création de personnages.

Elle possède déjà un workflow ComfyUI capable de produire les images souhaitées.

Au lieu de demander à l’utilisateur final d’ouvrir ComfyUI, l’application peut envoyer les données au backend via API.

L’interface du produit affiche :

« Générer le personnage »

Derrière ce bouton, un graphe de cinquante nœuds effectue le véritable travail.

Cette séparation possède beaucoup de valeur.

Les personnes qui conçoivent le pipeline peuvent continuer à le modifier visuellement.

Les développeurs n’ont pas à réimplémenter chaque changement de modèle dans l’interface produit.

ComfyUI devient ici moins une application qu’un moteur graphique caché derrière une autre application.

Exploiter un GPU Cloud pour la vidéo

Un utilisateur possède une carte graphique correcte pour l’image mais insuffisante pour certains modèles vidéo.

Il prépare son workflow puis l’exécute dans Comfy Cloud.

L’infrastructure distante fournit davantage de VRAM.

Le même principe de nodes reste disponible.

Cette solution évite :

• l’achat immédiat d’une nouvelle carte ;
• l’installation de plusieurs dizaines de gigaoctets ;
• certaines complications CUDA ou PyTorch ;
• le téléchargement local de chaque modèle.

En échange, le calcul devient facturé.

Le problème « ma carte graphique n’a pas assez de VRAM » est remplacé par :

« combien cette expérimentation va-t-elle consommer ? »

La physique économique possède son propre système de conservation de l’énergie.

Construire un workflow reproductible pour une production

Une équipe produit plusieurs centaines d’assets.

Les images doivent passer par les mêmes étapes.

Le workflow peut être versionné et conservé avec les modèles et custom nodes nécessaires.

Les subgraphs isolent certaines fonctions.

Les snapshots aident à retrouver un environnement antérieur.

Les sorties peuvent être générées par lots ou déclenchées via API.

ComfyUI devient alors une manière de formaliser une méthode.

Ce qui était auparavant :

« Julie sait comment obtenir ce rendu »

peut progressivement devenir :

« voici le workflow utilisé pour obtenir ce rendu ».

Ce passage de la connaissance personnelle à une procédure partageable est l’une des raisons pour lesquelles les outils nodaux deviennent si intéressants en production.

Avis PANACHES

La première fois qu’on ouvre ComfyUI, il est assez facile de penser :

« Pourquoi faudrait-il relier sept boîtes pour faire ce qu’un autre outil réalise avec un bouton ? »

La question est parfaitement légitime.

Puis le workflow grandit.

Une référence doit être ajoutée.

Un autre modèle intervient.

Un masque doit être conservé.

Deux versions doivent être comparées.

Une vidéo doit partir de l’image finale.

Et soudain, les sept boîtes commencent à avoir du sens.

ComfyUI est puissant précisément parce qu’il refuse de prétendre que tous les workflows créatifs peuvent tenir derrière le même bouton.

Un outil qui expose la mécanique

Les logiciels grand public cherchent généralement à cacher la complexité.

C’est souvent une excellente décision.

Personne ne souhaite choisir manuellement son algorithme de compression chaque fois qu’il envoie une photographie à un ami.

ComfyUI prend la direction opposée.

Il expose la mécanique.

Le créateur voit les modèles.

Les encodeurs.

Les conditions.

Les transformations.

Les sorties.

Cette transparence devient éducative.

Après quelque temps, certains concepts d’IA générative cessent d’être des mots abstraits.

On comprend mieux ce qu’est un VAE parce qu’on doit le connecter.

On comprend qu’un LoRA n’est pas un modèle complet parce qu’il intervient sur autre chose.

On comprend qu’une image-to-image possède une logique différente d’une génération pure parce que le workflow n’est pas construit de la même façon.

ComfyUI peut donc apprendre beaucoup sur l’IA générative simplement parce qu’il refuse de cacher ses tuyaux.

Le workflow est plus important que le prompt

La culture populaire de l’IA générative s’est énormément concentrée sur le prompt.

Trouver les bons mots.

Les bons adjectifs.

La formulation magique.

ComfyUI montre rapidement les limites de cette vision.

Le prompt n’est qu’une entrée parmi d’autres.

Le résultat dépend également du modèle, des références, du sampler, du conditioning, des contrôles, des LoRA, du denoise et de toute la chaîne construite autour.

C’est probablement l’une des leçons les plus intéressantes de l’outil.

La qualité ne vient pas toujours d’un meilleur prompt. Elle vient parfois d’un meilleur pipeline.

Cette idée rapproche l’IA générative des autres métiers créatifs.

Un photographe ne résume pas son travail à la phrase dite au modèle.

Un artiste 3D ne résume pas son rendu au nom du shader.

Un cinéaste ne résume pas son film à son scénario.

Le processus compte.

ComfyUI donne enfin au processus une interface.

Une liberté qui peut devenir sa propre prison

La modularité est merveilleuse.

Jusqu’à ce qu’elle ne le soit plus.

Un workflow peut grandir sans réelle discipline.

Une correction est ajoutée.

Puis une autre.

Un custom node économise trois nœuds.

Une dépendance en installe quatre autres.

Une branche est conservée « au cas où ».

Trois mois plus tard, le canvas ressemble à la carte du métro d’une ville conçue par quelqu’un qui détestait les lignes droites.

ComfyUI ne force pas une bonne architecture.

Il permet une bonne architecture.

C’est différent.

Les groupes, subgraphs, conventions de nommage et méthodes de travail deviennent essentiels.

Comme dans le code, une mauvaise organisation fonctionne très bien.

Jusqu’au jour où il faut la modifier.

L’écosystème de custom nodes est à la fois son superpouvoir et son chaos

L’open source permet à la communauté d’aller extrêmement vite.

Un nouveau modèle sort.

Quelques jours plus tard, plusieurs implémentations apparaissent.

Un besoin très spécifique existe.

Quelqu’un a probablement créé un node pour cela.

Cette énergie est difficile à reproduire dans un produit fermé.

Mais l’autre côté est tout aussi réel.

Des extensions peuvent être abandonnées.

Des dépendances entrent en conflit.

Un workflow téléchargé peut utiliser huit packs différents.

Une mise à jour peut casser un composant.

Et, surtout, un custom node est du code.

Il faut donc le traiter comme tel.

Pas comme un filtre Instagram innocent simplement parce que son rectangle possède une jolie couleur.

Le Registry, le Manager et les mécanismes de vérification améliorent progressivement la situation.

Ils ne remplacent pas le jugement.

Comfy Desktop corrige l’un des défauts historiques

Pendant longtemps, recommander ComfyUI à une personne non technique demandait une petite phrase inquiétante :

« Alors, il faut d’abord installer Python... »

Puis venaient CUDA, PyTorch, Git et quelques dossiers dont le nom semblait avoir été choisi pour décourager toute vocation artistique.

Comfy Desktop améliore nettement cette entrée.

L’environnement devient plus facile à installer et à maintenir.

La possibilité de gérer plusieurs instances est même particulièrement intelligente.

Elle reconnaît une réalité de ComfyUI :

les utilisateurs avancés veulent à la fois un environnement stable et un endroit où casser des choses joyeusement.

Séparer les deux est souvent une excellente idée.

App Mode pourrait être plus important qu’il n’en a l’air

Le graphe complet est idéal pour la personne qui construit le workflow.

Il est souvent catastrophique pour celle qui doit simplement l’utiliser.

App Mode crée une séparation entre ces deux rôles.

Cette idée peut profondément changer l’usage professionnel de ComfyUI.

Un spécialiste prépare le moteur.

Un artiste utilise l’application simplifiée.

Un studio peut standardiser un processus sans imposer à chaque personne de devenir spécialiste de diffusion.

ComfyUI cesse alors d’être uniquement un outil d’expert.

Il devient un outil avec lequel un expert peut construire l’interface destinée aux autres.

C’est une nuance énorme.

Le Cloud ne remplace pas le local : il lui ajoute une seconde route

Le lancement de Comfy Cloud pourrait sembler contradictoire avec l’identité locale et open source de ComfyUI.

En réalité, les deux approches peuvent très bien coexister.

Le local offre :

• contrôle maximal ;
• absence de coût par génération ;
• fonctionnement hors ligne ;
• installation libre de custom nodes ;
• maîtrise de l’environnement.

Le Cloud offre :

• matériel puissant ;
• aucun setup GPU ;
• modèles préinstallés ;
• accès depuis plusieurs appareils ;
• infrastructure gérée ;
• exécution distante.

Le choix ne devrait donc pas devenir idéologique.

Une personne possédant une grosse workstation peut préférer le local.

Une autre peut utiliser Cloud uniquement pour les workflows vidéo lourds.

Une équipe peut standardiser certaines productions dans Cloud et conserver ses outils expérimentaux en local.

Cette coexistence est probablement plus intéressante que la vieille opposition :

« local contre cloud ».

Le bon pipeline peut utiliser les deux.

Partner Nodes brouille intelligemment la frontière open source / propriétaire

L’intégration de modèles propriétaires dans ComfyUI pourrait également sembler étrange.

Mais elle répond à un problème réel.

Les créateurs ne travaillent plus avec une seule famille de modèles.

Ils passent d’un moteur à un autre selon le besoin.

Partner Nodes permet de conserver l’architecture du workflow même lorsque certaines briques deviennent des services distants.

C’est pragmatique.

Cela évite de transformer le débat open source contre propriétaire en religion.

Un modèle local peut être excellent pour une étape.

Un modèle commercial meilleur pour une autre.

Le créateur décide où il souhaite payer et où il souhaite conserver le contrôle.

Le canvas reste le même.

Quelle place face aux alternatives ?

AUTOMATIC1111 Stable Diffusion Web UI reste une référence historique. Son interface par panneaux est beaucoup plus immédiate pour générer des images et manipuler les fonctions classiques de Stable Diffusion. ComfyUI devient nettement plus intéressant lorsque plusieurs étapes doivent être reliées, automatisées ou réutilisées.

Stable Diffusion WebUI Forge conserve la logique familière des WebUI tout en améliorant différents aspects techniques et la gestion de modèles récents. Il peut être plus simple pour un utilisateur qui souhaite essentiellement générer et modifier des images sans construire de graphes.

InvokeAI propose une expérience plus structurée et orientée création visuelle, avec un canvas et des outils qui demandent moins de connaissances techniques. ComfyUI offre généralement davantage de liberté architecturale et un écosystème de nodes plus vaste.

SwarmUI cherche à fournir une interface plus accessible autour des moteurs de génération et peut notamment s’appuyer sur ComfyUI comme backend. Il illustre parfaitement une possibilité intéressante : utiliser la puissance de Comfy sans nécessairement exposer son graphe à tout le monde.

Krea appartient davantage au monde des plateformes cloud créatives multi-modèles. Son expérience est plus immédiate, visuelle et intégrée. ComfyUI garde l’avantage du contrôle local, de l’open source et de la construction explicite du pipeline.

Il ne faut donc pas choisir ComfyUI parce qu’il possède le plus grand nombre de nœuds.

Il faut le choisir lorsque la méthode de génération elle-même mérite d’être construite.

Pour produire une image occasionnelle, son niveau de contrôle peut être inutile.

Pour construire une chaîne répétable, combiner plusieurs modèles, expérimenter, automatiser ou intégrer la génération dans une application, cette complexité commence à devenir son principal avantage.

Dans un workflow PANACHES, ComfyUI peut se placer presque partout dans la chaîne visuelle : concept art, personnages, décors, variations, retouche, upscale, animation, vidéo, audio et automatisation. Il ne remplace pas nécessairement les logiciels créatifs existants. Il peut devenir la couche qui prépare ou transforme les assets avant de les envoyer ailleurs.

ComfyUI ne demande pas seulement ce que vous voulez générer. Il demande comment vous voulez le générer. Et lorsque cette seconde question devient importante, très peu d’outils offrent autant de liberté.

Points d’attention

• ComfyUI local est réellement gratuit et open source : le cœur du projet est distribué sous GPL-3.0 et peut être exécuté sur son propre matériel sans abonnement Comfy Cloud.

• La licence GPL-3.0 concerne ComfyUI, pas automatiquement les modèles : un checkpoint, LoRA, ControlNet, custom node ou autre ressource peut posséder sa propre licence. Il faut donc vérifier séparément les droits d’utilisation et de redistribution des composants utilisés.

• Les droits commerciaux dépendent fortement du workflow local : utiliser ComfyUI ne garantit pas qu’un modèle téléchargé depuis Hugging Face, CivitAI ou ailleurs autorise l’usage commercial. Les licences de chaque modèle restent applicables.

• Comfy affirme que les modèles proposés directement dans Comfy Cloud sont autorisés pour un usage commercial : cette garantie concerne le catalogue Cloud proposé par Comfy et ne doit pas être généralisée à n’importe quel modèle importé ou utilisé localement.

• Partner Nodes ne sont pas des modèles locaux : ils appellent des services externes par API. Prompts, images, modèles ou paramètres nécessaires à la requête peuvent donc être transmis au fournisseur concerné.

• Les conditions des fournisseurs de Partner Nodes restent importantes : Comfy agit comme intermédiaire pour les appels, mais les pratiques et conditions du fournisseur tiers peuvent également s’appliquer.

• L’utilisation locale peut être entièrement hors ligne, mais seulement si le workflow l’est réellement : Partner Nodes, téléchargements automatiques, API externes et certaines extensions nécessitent une connexion réseau.

• Les custom nodes sont du code exécutable : un plugin malveillant peut compromettre la machine. La documentation officielle recommande d’utiliser des extensions provenant de développeurs fiables et d’éviter les packages obscurs ou non vérifiés.

• Le Registry améliore la sécurité sans la rendre absolue : les nœuds enregistrés peuvent recevoir des vérifications et indicateurs de confiance, mais cela ne dispense pas de contrôler la provenance et le rôle d’une extension.

• Les dépendances peuvent entrer en conflit : les custom nodes installent parfois leurs propres bibliothèques Python. Deux extensions peuvent demander des versions incompatibles du même package.

• Les mises à jour peuvent casser un workflow : ComfyUI, les custom nodes et les modèles évoluent rapidement. Une configuration parfaitement fonctionnelle aujourd’hui peut nécessiter des adaptations après une mise à jour.

• Les snapshots du Manager sont précieux mais ne constituent pas une sauvegarde universelle : ils facilitent la restauration de certaines configurations, mais la documentation précise que la prise en charge peut être incomplète pour certains nodes non gérés par Git.

• Un workflow partagé n’est pas automatiquement autonome : le JSON décrit la structure du graphe, mais le destinataire doit encore posséder les modèles, custom nodes et dépendances nécessaires.

• Une image contenant le workflow ne contient pas les modèles eux-mêmes : les métadonnées permettent de retrouver la recette, pas de compresser plusieurs dizaines de gigaoctets de checkpoints à l’intérieur d’un PNG. La physique garde encore quelques droits.

• Les workflows très complexes deviennent difficiles à maintenir : groupes, noms, couleurs, subgraphs et documentation interne deviennent indispensables lorsque plusieurs dizaines de nœuds commencent à interagir.

• ComfyUI demande une véritable courbe d’apprentissage : comprendre modèles, latents, samplers, schedulers, VAEs, conditioning, seeds et autres notions prend du temps. Les Templates et App Mode améliorent l’entrée, mais ne suppriment pas la complexité sous-jacente.

• Le matériel local reste déterminant : certains modèles d’image sont relativement accessibles, tandis que les modèles vidéo ou 3D peuvent demander énormément de VRAM et de RAM.

• Le support matériel varie selon les plateformes : l’installation manuelle prend en charge NVIDIA, AMD, Intel et Apple Silicon ainsi que plusieurs accélérateurs spécialisés, mais la maturité, les performances et la simplicité d’installation ne sont pas identiques.

• AMD sous Windows reste plus spécifique que NVIDIA : certaines générations de GPU AMD disposent d’un support expérimental ou dépendent de configurations particulières. Une carte officiellement détectée ne garantit pas que tous les custom nodes fonctionneront comme sur CUDA.

• Le CPU peut techniquement exécuter ComfyUI : cela ne signifie pas que lancer un gros modèle de diffusion ou une vidéo sur CPU constitue une excellente activité pour occuper son après-midi.

• Comfy Desktop simplifie l’installation mais ne couvre pas tous les environnements de la même manière : les builds précompilés ciblent principalement Windows et macOS Apple Silicon. Linux reste pleinement utilisable via installation adaptée, mais demande davantage de manipulation.

• Desktop peut avoir un léger retard sur les nouveautés : les builds stables ne reçoivent pas forcément immédiatement les derniers changements disponibles dans les versions manuelles ou nightly.

• ComfyUI évolue très vite : certains guides, workflows communautaires ou tutoriels vidéo peuvent déjà être dépassés quelques mois après leur publication.

• Comfy Cloud est un service payant distinct du logiciel local : au moment de cette vérification, Standard coûte 20 $/mois, Creator 35 $/mois et Pro 100 $/mois, avec des réductions en facturation annuelle.

• Les crédits Cloud sont consommés pendant l’exécution GPU : construire et modifier le workflow ne consomme pas de temps GPU. Les crédits commencent à être utilisés lorsque le workflow est réellement exécuté.

• Les Partner Nodes utilisent le même solde de crédits : les appels vers les modèles propriétaires sont facturés selon le modèle et ses paramètres, même lorsque le workflow ComfyUI lui-même tourne localement.

• Les crédits mensuels Cloud ne sont pas tous reportés : les crédits inclus dans l’abonnement sont renouvelés à chaque cycle. Les crédits supplémentaires achetés séparément possèdent leurs propres règles et peuvent être conservés pendant une période déterminée.

• Les workflows Cloud possèdent des limites d’exécution : Standard et Creator disposent actuellement d’une durée maximale de 30 minutes par workflow, tandis que Pro peut atteindre une heure.

• Le Cloud ne permet pas la même liberté sur les custom nodes : Comfy Cloud maintient une sélection de nodes compatibles. L’utilisateur ne peut pas simplement envoyer n’importe quel dépôt Python personnel dans l’environnement comme il le ferait en local.

• Le catalogue Cloud reste néanmoins très large : Comfy annonce des centaines de modèles préinstallés et prend en charge une grande partie des custom nodes les plus utilisés, mais un workflow local très spécialisé peut toujours rencontrer des composants absents.

• L’import de modèles personnels dans Comfy Cloud est réservé à certaines offres : Creator, Pro et certaines offres supérieures peuvent importer des modèles ou LoRA depuis Hugging Face ou CivitAI selon les formats et conditions pris en charge.

• L’import Cloud n’est pas équivalent à un accès au système de fichiers : les modèles doivent passer par les mécanismes prévus par Comfy et certains formats seulement sont acceptés.

• Le partage de workflow Cloud peut inclure les assets associés : un lien partagé peut exposer les images, masques ou autres médias référencés par le workflow. Il ne faut donc pas partager publiquement un lien contenant des données privées en pensant qu’il ne montre que les nœuds.

• Les conditions actuelles de Comfy indiquent que les Inputs et Outputs du Cloud restent la propriété du client : Comfy précise également qu’il n’utilise pas ces Inputs ou Outputs pour entraîner des modèles génératifs ou de diffusion.

• Comfy peut néanmoins utiliser certaines métadonnées : les conditions autorisent l’utilisation limitée d’informations comme les structures de workflows, configurations de nœuds ou classifications de prompts pour améliorer les produits et leur fonctionnement.

• Les données Cloud sont conservées pour faire fonctionner et améliorer le service : prompts, workflows, outputs et autres contenus peuvent être stockés aussi longtemps que nécessaire selon les politiques de rétention. Une demande de suppression peut être effectuée, sous réserve des obligations légales, sauvegardes et autres exceptions prévues.

• Comfy Cloud ne remplace pas automatiquement une politique interne de confidentialité : une entreprise manipulant des assets sensibles doit encore vérifier ses besoins de stockage, de conformité et les éventuelles conditions Enterprise.

• Comfy ne fournit pas actuellement d’image Docker officielle : des images communautaires existent, mais la documentation précise qu’elles ne sont ni officielles ni prises en charge par l’équipe Comfy.

• App Mode simplifie l’usage, pas le pipeline : masquer les nœuds à l’utilisateur final ne rend pas le workflow plus simple à maintenir pour la personne qui l’a construit.

• L’API transforme facilement un workflow en backend, ce qui augmente aussi les responsabilités : authentification, exposition réseau, ressources GPU, files d’attente et gestion des utilisateurs deviennent alors des problèmes d’application classique.

• Les fonctions MCP et agentiques évoluent encore : certaines intégrations peuvent être en bêta, changer rapidement ou nécessiter un abonnement Cloud et un accès spécifique.

ComfyUI peut transformer un prompt en image, l’image en vidéo, la vidéo en nouvelle branche et le tout en API réutilisable. Il peut aussi transformer un dimanche tranquille en enquête sur une dépendance Python cassée par un custom node installé six mois plus tôt. La liberté est réelle. La responsabilité de construire quelque chose de maintenable l’est aussi.