Vous avez passé des heures à parcourir Civitai, à tester des checkpoints et des LoRA, à affiner vos prompts. Puis un jour, le modèle que vous utilisiez disparaît de la plateforme. Retrait par l’auteur, mise en conformité légale, simple changement de version : les raisons varient, mais le résultat est le même.
Si vous n’avez pas de copie locale, votre workflow s’arrête net. Travailler avec Civitai hors ligne, c’est d’abord anticiper ce scénario en sauvegardant vos modèles et leurs métadonnées de façon organisée.
Pourquoi les modèles Civitai disparaissent de la plateforme
Civitai n’est pas un disque dur personnel. C’est une plateforme communautaire soumise à ses propres conditions d’utilisation et aux évolutions réglementaires. Un créateur peut retirer son modèle à tout moment, sans préavis.
Côté législatif, le TAKE IT DOWN Act entré en vigueur le 19 mai 2025 impose aux plateformes une procédure de notification et de retrait sous 48 heures pour certains contenus générés par IA. Les obligations se sont renforcées à compter de mai 2026. Cette pression réglementaire a provoqué une vague de retraits sur Civitai, touchant aussi des modèles qui n’étaient pas directement visés.
Compter sur la disponibilité permanente d’un fichier hébergé par un tiers est un pari risqué. La seule garantie de continuité, c’est une copie locale que vous contrôlez.
Sauvegarder un modèle Civitai avec ses métadonnées
Télécharger le fichier .safetensors ou .ckpt ne suffit pas. Six mois plus tard, un fichier nommé « v3.2_fp16.safetensors » dans un dossier ne vous dira plus rien. Vous avez besoin de trois éléments pour chaque modèle archivé.
- Le fichier du modèle lui-même : checkpoint, LoRA ou embedding, dans le format exact proposé sur la page de version Civitai (fp16, fp32, pruned, etc.)
- Les informations de provenance : URL de la page Civitai, numéro de version, nom de l’auteur, type de licence, date de téléchargement. Un simple fichier texte ou JSON placé à côté du modèle fait l’affaire
- Un exemple de prompt fonctionnel : copiez au moins un prompt d’exemple avec ses paramètres (sampler, CFG scale, steps) depuis la page du modèle. C’est ce qui vous permettra de vérifier que tout fonctionne après restauration
Cette habitude prend deux minutes par modèle. Elle vous évitera de passer une heure à retrouver quel LoRA produisait tel style, ou quelle version d’un checkpoint vous utilisiez dans un workflow précis.
Organisation des fichiers pour un usage local avec Stable Diffusion
Votre interface de génération d’images (ComfyUI, Forge, Automatic1111) attend les modèles dans des dossiers précis. Un checkpoint téléchargé via le navigateur peut encore traîner dans votre répertoire « Téléchargements » sans jamais être détecté par l’outil.
Arborescence type pour ComfyUI
ComfyUI organise les ressources par catégorie. Les checkpoints vont dans models/checkpoints, les LoRA dans models/loras, les embeddings dans models/embeddings. Si vous utilisez des modèles vidéo ou des upscalers, chaque type a son propre sous-dossier.
Adoptez une convention de nommage claire dès le départ. Par exemple : « dreamshaper_v8_fp16.safetensors » accompagné de « dreamshaper_v8_fp16_meta.txt » pour les métadonnées. La cohérence du nommage compte plus que le système choisi.
Cas des workflows multi-modèles
Certains workflows combinent un checkpoint de base, un ou plusieurs LoRA de style, et parfois un modèle d’upscaling. Si un seul fichier manque, la génération échoue ou produit un résultat dégradé. Documentez la liste exacte des modèles utilisés par chaque workflow que vous souhaitez conserver.
Valider le fonctionnement hors ligne de votre setup
Avoir les fichiers au bon endroit ne garantit pas que votre workflow est réellement autonome. Certains nodes ComfyUI font appel à des API distantes. Des extensions peuvent vérifier des mises à jour au lancement. Même un simple appel réseau qui échoue peut bloquer le démarrage.
La méthode de validation est simple : coupez votre connexion internet, relancez votre interface, et lancez une génération. Si l’image se produit normalement, votre setup est autonome. Sinon, identifiez quel composant tente de contacter un serveur et désactivez-le ou remplacez-le par une alternative locale.
Ce test fait la différence entre « j’ai téléchargé mes modèles » et « je peux réellement travailler sans connexion ». Un modèle archivé n’a de valeur que s’il est utilisable.
Gérer l’espace disque sans sacrifier vos modèles Civitai
Les checkpoints Stable Diffusion pèsent lourd. Un seul fichier fp32 peut occuper plusieurs gigaoctets. Multipliez par une vingtaine de modèles et quelques dizaines de LoRA, et votre disque se remplit vite.
Avant de supprimer quoi que ce soit, appliquez une règle : ne supprimez jamais un modèle dont vous n’avez pas vérifié qu’il est encore disponible sur Civitai. Si la page du modèle affiche une erreur 404 ou un message de retrait, votre copie locale est potentiellement la dernière accessible.
- Privilégiez les versions fp16 (demi-précision) quand votre carte graphique les supporte, elles pèsent environ deux fois moins que les fp32
- Archivez les modèles que vous n’utilisez plus sur un disque externe ou un NAS, avec leurs fichiers de métadonnées
- Conservez sur votre disque principal uniquement les modèles de votre workflow actif
Un archivage sur un second support physique protège aussi contre les pannes matérielles. Un modèle retiré de Civitai et perdu dans un crash disque est irrécupérable.
Flux de travail complet pour passer Civitai en mode hors ligne
Commencez par identifier les modèles que vous utilisez activement. Pour chacun, téléchargez le fichier depuis la page de version Civitai, enregistrez les métadonnées dans un fichier texte associé, puis placez le tout dans le dossier correspondant de votre interface locale.
Une fois tous les fichiers en place, lancez le test hors ligne : coupez le réseau, redémarrez l’outil, générez une image avec chaque modèle. Corrigez les dépendances réseau résiduelles. Enfin, dupliquez vos modèles les plus précieux sur un support de sauvegarde séparé.
Cette approche transforme une collection de téléchargements éparpillés en un environnement de production local fiable. Le jour où un modèle disparaît de la plateforme ou que votre connexion tombe, votre capacité de génération d’images reste intacte.
