Modèles locaux ou cloud — qui gagne ?

Un an de cloud, et toujours les mêmes murs

Pendant un an, j’ai fait produire mes rendus d’architecture par des plateformes cloud clés en main. Avec des modèles comme Nano Banana Pro V2, les résultats sont devenus véritablement bluffants et facilement exploitables, moyennant plusieurs générations et un collage bien senti sur Photoshop. Mais à mesure que j’intégrais ces plateformes à mon cadre de travail hebdomadaire, quatre limites se dessinaient, qui m’ont fait reconsidérer dernièrement l’intérêt d’entraîner mes propres « sur-modèles ».

• Des sorties normalisées, d’abord : quel que soit le soin apporté au prompt, les images finissent par se ressembler.
• Aucun contrôle réel, ensuite, sur la géométrie d’entrée — or un architecte ne signe pas un bâtiment halluciné ; le dessin est le produit.
• L’effet boîte noire, enfin : zéro visibilité sur les paramètres du modèle, donc aucune possibilité d’apprendre de ce qui rate.
• Et un coût à l’usage qui punit silencieusement l’itération, c’est-à-dire exactement le geste qui fait la conception.

J’avais ouvert ComfyUI pour la première fois en janvier 2025, puis je m’en étais éloigné faute de temps. En juillet, j’y suis revenu — avec une intuition précise en tête : celle que les nouveaux modèles d’IA et les agents pourraient m’aider à améliorer sensiblement la qualité de mes modèles.

Trois couches de contrôle, et pourquoi elles changent tout

Le premier résultat concret, c’est un projet de licence rendu il y a quatre ans sous Twinmotion. À l’époque, les images étaient correctes mais ne racontaient rien de spécial. J’ai voulu reprendre ces images d’origine dans un style différent, que j’affectionne : le Post-Digital Collage. En parallèle de l’entraînement de mes sur-modèles à cette esthétique, il a fallu construire un script adapté sur ComfyUI.

Le script se comprend en trois parties, et c’est cette séparation qui fait toute la différence avec un prompt classique.

La géométrie reste sacrée : les ControlNets lisent la profondeur, les arêtes et la structure de l’image d’entrée et les verrouillent jusqu’à un certain point ; les masques décident où le modèle a le droit de réinterpréter et où il doit obéir. Toute la difficulté est là : préserver le trait tout en laissant assez d’air au modèle pour inventer son langage.

Le style vient des modèles : le checkpoint open source donne la main générale, puis mon propre LoRA injecte l’ADN visuel sur lequel je l’ai entraîné — le grain de collage, la texture, la palette. C’est ce qui transforme « une image d’IA » en mon image.

La précision vient des paramètres : forces de denoise, poids de ControlNet, sampler, steps. Une poignée de curseurs qui décident de la distance parcourue depuis l’entrée. Savoir les lire, c’est toute la différence entre un gadget et un outil dont on maîtrise les rouages.

Deux modèles en un mois : ce que les chiffres disent vraiment

En juillet, j’ai entraîné deux LoRA de style, tous deux sur SDXL base 1.0, avec Kohya_ss, sur un seul GPU portable de 12 Go.

Post-Digital Collage a marché en sept versions. La question de fond était la taille du jeu de données : mon intuition disait qu’un ensemble serré de 50 images bien choisies battrait un grand ensemble hétérogène. Les grilles comparatives à paramètres égaux ont dit l’inverse. La v7, 220 images vues 20 fois chacune, imprime un style plus fort que la v6, 50 images vues 90 fois — à nombre de pas quasi identique, 4 400 contre 4 500.

La vraie variable n’était donc pas le nombre de pas, mais le nombre de vues par image. Plus d’images uniques vues moins souvent généralisent mieux que peu d’images pilonnées. Corollaire pratique : quand le jeu de données grandit, il faut faire baisser les répétitions.

Architectural Hand Sketch a suivi le chemin inverse — et c’est celui dont j’ai le plus appris. La v1 était trop chaude : capacité élevée, encodeur de texte entraîné, quinze époques sur cinquante images. Saturée. En réaction, j’ai corrigé trois curseurs d’un coup sur la v2 — capacité réduite, bruit désactivé, époques écourtées — et j’ai obtenu l’excès symétrique : délavé, presque photoréaliste, style absent. Impossible de savoir lequel des trois était responsable.

La v3 a retrouvé l’équilibre en restaurant le milieu, un curseur à la fois. C’est la leçon la plus transférable de tout le mois : on ne change qu’un réglage à la fois. Sinon on n’apprend rien.

Définir les tâches pour lesquelles on entraîne son LoRA

Un LoRA se juge dans le régime où on l’utilise. En txt2img sans contrainte, la v7 sur-cuisait à son poids nominal — ciels griffonnés, arbres sur-cernés. En img2img avec ControlNet, là où je m’en sers réellement, la structure tient et le défaut disparaît. Chaque nouvelle version demande de re-régler son poids : celui qui allait à la précédente sur-conduit la suivante.

L’IA qui entraîne l’IA

Voilà la vraie nouveauté de ce mois, et la raison de ce billet.

Jusqu’ici, l’annotation était de loin la tâche la plus chronophage d’un entraînement : décrire chaque image pour dire au modèle ce qu’il doit apprendre et ce qu’il doit ignorer. Fait à la main sur deux cents images, c’est une soirée ou plus consacrée à une tâche répétitive. Un agent le fait en quelques minutes, en respectant une nomenclature stricte, et le fait mieux.

Le sourcing a ensuite suivi. Plutôt que d’élargir un jeu de données à la main, j’ai fait écrire des scripts Python de scraping, d’embedding et de clustering : plus d’un millier d’images collectées, puis réduites par similarité à un noyau cohérent, venu s’ajouter au jeu curé à la main. La chaîne complète tient en sept étapes, du scraping au captioning en passant par un score de similarité visuelle.

Et surtout, le diagnostic. J’ai voulu voir jusqu’où un modèle pouvait lire mes résultats — les grilles de sortie et les courbes d’entraînement — pour proposer les corrections suivantes.

Mises bout à bout — scraping, annotation, diagnostic — ces méthodes m’ont donné des résultats sans commune mesure avec ceux que j’obtenais sur les mêmes checkpoints il y a deux ans. Le matériel a peu changé. La boucle de travail, entièrement.

Alors, local ou cloud ?

La réponse honnête : le local n’est pas meilleur, il est meilleur à autre chose.

Le local gagne sur le contrôle chirurgical, et sur un style qui m’appartient littéralement. Aucun SaaS ne peut le reproduire, puisque c’est mon modèle et non un préréglage. Il gagne aussi sur la confidentialité : tout tourne sur une seule machine, rien ne sort, aucune facture à l’image. Pour du travail de concours, ce dernier point n’est pas un confort, c’est une condition.

Le cloud gagne sur l’invention. Les modèles frontière peuplent une scène d’éléments qui ne sont pas dans mon image d’entrée : foule, végétation, atmosphère, contexte. En local, les ControlNets qui protègent ma géométrie interdisent précisément ce genre de liberté. Il gagne aussi sur la vitesse et sur l’absence d’installation préalable — sans compter le GPU mis à contribution.

J’ai donc arrêté de choisir un camp. La compétence n’est pas local ou cloud, c’est l’orchestration : générer la base contrôlée en local — ma géométrie, mon style entraîné —, inventer l’impossible dans le cloud, puis marier les deux au montage dans un logiciel comme Photoshop.

C’est cela, l’avenir proche de l’IA en architecture, tel que je le vois : pas un empilement d’abonnements, mais des architectes qui dirigent ces outils au lieu de leur obéir.