Qu'est-ce que le branching dans le design conceptuel IA ?

Le branching est le workflow où chaque image générée devient un état sauvegardé depuis lequel on peut bifurquer. Au lieu d'une séquence linéaire où chaque nouveau prompt remplace le précédent résultat, le branching produit un arbre de directions explorées. Les architectes comparent les branches côte à côte et décident lesquelles développer davantage, sans perdre le travail antérieur.

En quoi le branching diffère-t-il de la régénération dans Midjourney ?

La régénération produit une nouvelle image qui remplace ou côtoie la dernière. Le branching produit une nouvelle image qui se souvient explicitement de son parent — vous pouvez dire trois jours plus tard "fais une variation de la branche 3" et l'outil sait encore ce qu'était la branche 3. Le branching est de la mémoire structurelle ; la régénération est juste du prompting répété.

Pourquoi le branching importe-t-il dans le travail conceptuel architectural ?

Le travail conceptuel est exploration. Les architectes doivent essayer huit directions, en sélectionner deux fortes, développer quatre raffinements de chacune, puis converger. Un workflow linéaire force à jeter du travail pour essayer la direction suivante. Le branching garde chaque direction atteignable — c'est ce qui rend abordable l'exploration sérieuse.

Nuit utilise-t-il le branching par défaut ?

Oui. Chaque génération dans Nuit est un nœud dans l'arbre du projet. Bifurquer une branche se fait en un clic. L'arbre complet reste visible pour que les architectes comparent les directions, reviennent aux branches abandonnées et fusionnent les insights de plusieurs explorations.

Quand le branching n'est-il pas utile ?

Quand vous savez déjà exactement ce que vous voulez et n'avez besoin que d'un rendu. Pour les hero images one-shot, le branching ajoute du surcoût sans valeur. La majorité du travail conceptuel est exploratoire et bénéficie du branching ; le rendu final de présentation, rarement.

Puis-je utiliser le branching avec des outils d'édition comme Nano Banana ?

Les outils d'édition modifient une seule image en place. Ils ne maintiennent pas un arbre d'états explorés. Vous pouvez les utiliser dans un projet Nuit (Nuit comme couche de branching ; l'outil d'édition raffine des nœuds individuels), mais le branching lui-même n'arrive que quand l'outil est conçu autour d'un state de projet persistant.

Combien de branches devrais-je typiquement explorer ?

Pour une direction d'extérieur, six à dix branches est typique. Pour les pièces intérieures, trois à cinq branches par pièce. Pour les plans, quatre à six variantes de layout. Le coût par branche dans Nuit est faible, donc la contrainte est le temps de décision — trop de branches dilue la conversation client.

Le branching comme technique d'exploration

Équipe Nuit · May 19, 2026 · 12 min read

branchingiaarchitecturedesign-conceptuelworkflowexploration

Le branching est la fonctionnalité unique qui change vraiment la sensation du design conceptuel avec IA. La plupart des outils d’IA architecturale, y compris les modèles d’image les plus forts seuls, traitent chaque prompt comme un nouveau départ : écrire, générer, remplacer, répéter. Le branching brise cette boucle en faisant de chaque image un point de bifurcation — les variations naissent d’un parent, le parent ne disparaît jamais, et le canvas accumule un arbre de décisions plutôt qu’une liste d’artefacts sans lien. L’effet est que l’exploration devient gratuite, la comparaison devient honnête, et revenir à une direction précédente ne coûte rien. Cet article est l’approfondissement sur pourquoi le branching compte pour le travail conceptuel architectural, comment il fonctionne en pratique, et pourquoi les architectes qui ne l’utilisent pas laissent la majeure partie de la valeur de l’IA sur la table.

C’est l’une des pièces satellites du cluster thématique sur les workflows d’IA architecturale. La pièce pilier est Nano Banana pour l’architecture : où ça marche, où ça ne suffit pas. Pour les mécaniques spécifiques de cohérence voir Comment obtenir de l’IA des designs cohérents à travers un projet. Pour la modélisation des phases voir Un outil d’IA pour extérieur, plan et intérieur.

Le workflow par défaut et pourquoi il fait mal

Le workflow par défaut pour un designer utilisant un modèle d’image général se déroule ainsi :

Écrire un prompt.
Générer une image.
Tu aimes 80%. Tu veux changer les autres 20%.
Éditer le prompt et régénérer.
La nouvelle image corrige les 20% et casse autre chose.
Éditer le prompt et régénérer encore.
Après quinze rounds, tu as un dossier plein d’images. Le dossier est trié par temps. Les noms sont auto-générés. Tu ne te souviens pas laquelle était celle qui te plaisait.

Cette boucle a deux problèmes structurels. Le premier est la perte d’état : chaque régénération remplace l’état précédent dans ton attention, même si le fichier existe encore quelque part. Le second est la difficulté de comparaison : quand tu scrolles en arrière, les images sont disposées en temps linéaire, pas dans la structure logique de tes décisions. Tu ne peux pas voir facilement quelle version est sœur de laquelle, ou quelle décision a mené à quel résultat.

Pour des images de mood ou des rendus hero uniques, ça ne compte pas tant. Pour le design conceptuel, où le travail entier consiste à prendre une séquence de décisions liées, c’est le problème central. Le design conceptuel est exploration. Une exploration qui perd l’état n’est pas exploration — c’est errer.

Qu’est-ce que le branching réellement ?

Le branching est l’opération de workflow où une nouvelle génération croît explicitement d’une image parente. Le parent reste. La nouvelle image est une enfant. La relation entre parent et enfant est préservée comme donnée, pas comme souvenir de quel fichier est venu après lequel.

Mécaniquement en Nuit, chaque image générée a trois chemins en avant :

Branch. Créer des variations à partir de cette image exacte. L’original reste sur le canvas. Les variations apparaissent comme enfants, visuellement connectées par une ligne.
Improve. Raffiner exactement cette image sur place — même composition, changer un élément spécifique. Optionnellement annoter l’image (dessiner dessus, sélectionner une région) pour marquer ce qui doit changer.
New Prompt. Démarrer une direction fraîche sans lien avec cette image. Utile quand tu veux essayer un concept entièrement différent.

Branch et New Prompt produisent des enfants différents. Improve modifie l’image sur place. Les trois préservent l’état précédent. Aucun ne détruit l’image dont tu es parti.

Le résultat est que le canvas accumule un arbre, pas une liste. La racine est la première génération. Chaque image réussie peut avoir des enfants. Chaque enfant peut avoir des enfants. Revenir à une direction précédente signifie cliquer sur un nœud de l’arbre — il est encore là.

Pourquoi les arbres battent-ils les listes pour le design conceptuel ?

La raison pour laquelle cela change le travail, plutôt qu’être juste une UI plus jolie, est que le travail que tu fais est fondamentalement en forme d’arbre.

Un projet en phase concept est une série de décisions, chacune dépendant des précédentes. Tu commences avec une direction de haut niveau (villa moderniste à Bali, deux étages, intérieur-extérieur). Tu génères. Tu aimes l’une des trois variantes. À partir de cette variante, la décision suivante s’ouvre — quelle typologie de toit, quelle palette de matériaux, vers où regarde l’entrée. Chacune de ces décisions a son propre ensemble de réponses plausibles. Tu veux en voir deux ou trois avant de t’engager.

Si ton outil modélise le travail comme une liste, chaque décision écrase la précédente. Pour explorer trois options de toit sur la variante qui t’a plu, tu dois soit :

Régénérer trois fois de suite, perdant chaque état intermédiaire.
Sauvegarder chaque image manuellement dans un dossier avec un nom écrit à la main, puis suivre quel dossier représente quelle branche de décision.

Aucun ne scale. Après deux ou trois couches de décisions imbriquées, le coût cognitif du suivi dépasse le coût cognitif du travail de design lui-même.

Un arbre modélise le travail correctement. Chaque décision est un nœud. Chaque alternative est une sœur. Revenir en arrière est un clic. Montrer trois directions à un client revient à lui montrer trois branches qui partagent un parent. L’arbre n’est pas une fonctionnalité ajoutée par-dessus — c’est la bonne forme pour le travail.

L’économie de l’exploration

Une manière pratique de comprendre pourquoi cela compte : le branching change le coût d’essayer des choses.

Dans un workflow à liste plate, le coût d’essayer une variante agressive est la perte de la variante sûre. Tu as généré l’extérieur sûr. Tu envisages une version plus dramatique. Pour l’essayer, tu dois t’engager — régénérer, et la version sûre recule dans l’historique. Si la version agressive est pire, revenir à la sûre est suffisamment douloureux pour que tu arrêtes d’essayer.

Dans un workflow avec branching, le coût de la variante agressive est le coût d’une génération. La version sûre est encore sur le canvas, juste à côté de l’agressive. Si la variante agressive est pire, tu l’ignores. Si elle est meilleure, tu continues sur cette branche. Dans les deux cas, tu gardes les deux options visibles.

L’effet sur le comportement réel de design est significatif. Les architectes travaillant dans un workflow avec branching essaient plus de variantes par projet, s’engagent plus tard sur une direction finale, et produisent des dossiers conceptuels qui montrent une réflexion plus claire — parce que la réflexion est préservée dans l’arbre.

Un nombre concret de données d’usage internes : dans les projets où l’utilisateur utilise le branching, le nombre moyen de générations par projet est environ quinze fois plus élevé que dans les projets où l’utilisateur ne l’utilise pas. Les générations coûtent de l’argent. L’augmentation n’est pas du gaspillage — c’est l’exploration que le workflow rend possible.

Sélectionner ce qui doit changer : annotation dans Branch et Improve

L’autre morceau du branching facile à manquer est ce qu’il accepte en entrée.

Une opération de branch naïve accepte seulement un prompt texte pour la variation. C’est bien pour « plus dramatique », « matériaux plus clairs », « autre heure de la journée ». Mais le design conceptuel implique souvent de changer un élément spécifique d’une image par ailleurs bonne : la porte d’entrée, une fenêtre spécifique, la proportion du toit à un coin, le luminaire dans la cuisine.

Nuit permet l’annotation sur l’image lors du Branch ou Improve. Tu peux dessiner sur l’image avec un pinceau ou un rectangle, dans plusieurs couleurs, pour marquer exactement ce qui doit changer. L’annotation est composée avec le prompt et envoyée au modèle comme indice structurel. Le modèle change alors la région marquée et laisse le reste tranquille.

C’est une petite affordance avec un grand effet. Sans elle, changer un élément unique d’une bonne image signifie écrire un prompt qui décrit l’image entière plus le changement, en espérant que le modèle préserve ce qui fonctionnait. Avec l’annotation, tu pointes la chose.

Quand le branching n’est-il pas le bon mouvement ?

Le branching est le mouvement par défaut, mais pas le seul. Liste honnête de quand autre chose convient mieux :

Tu es satisfait de l’image telle qu’elle est et tu veux la garder. Clic sur Save. L’image devient une référence sauvegardée-de-concept pour le projet et reste accessible sans génération supplémentaire.
Tu veux une direction entièrement différente, pas une variation. Utilise New Prompt, pas Branch. Branch croît du parent ; si le parent n’est pas le point de départ que tu veux, tu paies un coût pour rien.
Tu veux corriger la qualité du modèle sur une image spécifique sans changer le design. Utilise Improve avec un prompt centré qualité (« restaurer détail, corriger bords doux ») et sans annotation. C’est pour rerender en fidélité plus haute, pas pour des changements de design.
Tu veux explorer un projet complètement nouveau. Crée un nouveau projet. Le branching est par projet ; le branching cross-project n’existe pas et ne devrait pas.

Le réflexe à développer est : quand l’image que tu as est majoritairement juste et que tu veux une variation, Branch. Quand l’image est majoritairement juste et que tu veux changer un élément spécifique, Improve. Quand l’image est fausse et que tu veux recommencer conceptuellement, New Prompt. Quand l’image est juste et que tu as fini, Save.

Pourquoi la plupart des architectes ne découvrent-ils pas le branching seuls ?

Une note spécifique de l’usage du produit, au cas où elle serait utile : la plupart des architectes qui essaient un outil de workflow IA pour la première fois ne cliquent pas sur Branch seuls. Ils cliquent sur New Prompt — parce que la mémoire musculaire de travailler avec des modèles d’image généraux est « régénérer pour itérer », et Branch ressemble juste à un autre bouton générer.

Le résultat est que le même outil, utilisé sans branching, produit la même expérience de liste plate qu’un modèle d’image général. Utilisé avec branching, il produit un arbre structuré. La différence est environ un ordre de grandeur en termes de combien d’exploration se produit par projet.

C’est pourquoi les outils construits à dessein mettent le branching en avant dans l’onboarding et produisent par défaut plusieurs variations par opération de Branch (trois, dans le cas de Nuit). La découvrabilité de la fonctionnalité est le goulot d’étranglement pour les nouveaux utilisateurs, pas la fonctionnalité elle-même.

Si tu utilises un outil de workflow et que tu ne ramifies pas, tu l’utilises comme un générateur d’images plus lent. Essaie de ramifier la prochaine fois que tu as une image générée que tu aimes majoritairement. Le changement dans la sensation du travail est immédiat.

Ce que le branching permet en pratique

Trois choses concrètes changent quand le branching devient une habitude :

Plusieurs directions restent vivantes plus longtemps. Au lieu de t’engager sur une direction à l’itération trois, tu peux garder deux ou trois directions ouvertes jusqu’à l’itération dix ou quinze. La bonne direction ne devient habituellement claire qu’après plusieurs rounds. Le branching te permet de garder les options ouvertes sans payer le coût de tout recommencer depuis zéro.

Les présentations clients deviennent plus claires. Montrer trois directions du même parent est structurellement honnête — elles sont sœurs, partagent le brief, diffèrent seulement sur les dimensions que tu voulais comparer. Montrer trois images sans lien et les appeler « directions » est malhonnête, et les clients le sentent.

Revenir en arrière est gratuit. Le design conceptuel est itératif, et la direction finale est souvent un retour à quelque chose que tu as essayé à l’itération cinq. Avec le branching, ce nœud antérieur est juste là. Sans, tu le reconstruis depuis la mémoire de quel prompt tu as écrit il y a trois jours.

Une brève note sur la nomenclature

Branching est de la terminologie empruntée au contrôle de version — la même opération qu’un développeur exécute dans Git. L’analogie est suffisamment exacte pour être utile. Un dépôt a une branche principale et des branches de feature. Un projet a une direction principale et des variantes explorées. Fusionner les variantes est, dans le cas architectural, du travail de curateur — tu choisis la variante qui devient la prochaine direction principale. Les autres restent comme ancêtres sur l’arbre, récupérables si le design change de cap.

Si tu viens d’un background logiciel, le branching est intuitif. Si tu viens d’un background design, le modèle mental sous-jacent prend un projet à intérioriser. Après ça, le workflow à liste plate d’un modèle d’image général semble inconfortable — comme éditer un document sans historique d’annulation.

Essaie-le sur ton prochain projet

La recommandation est simple : sur ton prochain projet en phase concept, fais-toi une règle de faire Branch au lieu de New Prompt à chaque fois que l’image que tu as est quelque chose que tu envisagerais de garder. Même si tu ne finis pas par utiliser les variantes ramifiées, l’arbre de décisions que tu construis est le livrable. Les clients répondent à la structure. Tu réponds à la vitesse.

Nuit produit par défaut trois variations par opération de Branch. Le défaut est délibéré — explorer trois sœurs est le mouvement qui rend l’arbre utile. Ajuste le compte dans la barre d’outils si tu en veux moins ou plus.

Pour le contexte plus large, la pièce pilier est dans Nano Banana pour l’architecture : où ça marche, où ça ne suffit pas. Pour la comparaison head-to-head si tu hésites encore sur quel outil, voir Nuit vs Nano Banana : quand chacun convient.