Un générateur d'images produira toujours quelque chose de joli. C'est le problème. Demandez-lui de meubler un salon, il dessinera une table élégante qui n'existe dans aucun catalogue, à un prix qu'il ne connaît pas. L'image est séduisante et commercialement inutilisable : personne ne peut vendre ce meuble.
Balinaisa fabrique du mobilier en teck massif entre la France et l'Indonésie. Ses clients butaient sur la projection : difficile d'acheter une table à deux mille euros sans se figurer ce qu'elle donne chez soi. Le besoin était clair. La contrainte l'était tout autant.
C'est cette contrainte, et non la génération d'image, qui a dicté toute l'architecture de Balinaisa.ai.
Avant
ApresLe catalogue n'est pas une donnée, c'est le garde-fou
La tentation naturelle est de décrire le style souhaité au générateur et d'espérer. Nous avons pris le problème dans l'autre sens : le modèle ne choisit jamais un meuble, il reçoit ceux qu'il doit reproduire.
Le catalogue compte 97 références réparties en 17 familles, du tabouret à 74 euros à la table à 4 407 euros hors taxes. Chaque référence porte trois choses, et c'est le point qui fait tout basculer :
- son prix hors taxes réel, celui du tarif commercial ;
- sa photo de référence, le meuble tel qu'il est fabriqué ;
- son descriptif, la matière, le piètement, les proportions.
Ces trois champs sont renseignés sur 97 références sur 97. Ce n'est pas un détail de complétude : une seule référence sans photo, et le modèle redevient libre d'inventer sur celle-là.
Au moment de la génération, la requête ne dit pas « ajoute un fauteuil ». Elle transmet la photo du fauteuil retenu et son descriptif, et demande de le placer dans la pièce du client. Le modèle ne compose plus, il transpose. C'est une contrainte beaucoup plus forte qu'une consigne textuelle, et beaucoup plus fiable qu'un post-contrôle.
Le devis suit mécaniquement : il additionne les prix des références effectivement retenues. Il n'est pas estimé par catégorie, il n'est pas arrondi. Ce que l'outil ajoute pour la mise en scène, tapis, plantes, objets, est signalé au client et n'est pas facturé.
Ce qui se passe pendant la minute d'attente
Le visiteur envoie une photo, un horizon d'achat s'il en a un, une adresse email. Une minute plus tard il reçoit le rendu et le devis. Entre les deux, une chaîne orchestrée sous n8n.
Le workflow principal compte 79 nœuds et 64 liaisons : 19 nœuds de code, 8 appels HTTP, 7 branchements conditionnels, 6 accès à Google Sheets, 6 à Drive. Deux workflows secondaires gèrent l'ingestion des leads d'autres canaux et le digest quotidien envoyé au dirigeant.
Les étapes qui comptent, dans l'ordre :
- Filtrage à l'entrée. Un captcha Turnstile en mode fail-closed : en cas de doute, on refuse. Un quota par email et par adresse évite qu'un curieux consomme le budget de génération.
- Lecture de la pièce. Un premier modèle analyse la photo, identifie le volume, la lumière, le style et les surfaces disponibles.
- Sélection dans le catalogue. C'est ici que le savoir-faire du fabricant est encodé : quelles familles vont ensemble, quelles proportions dans quel volume, ce qu'on ne met pas dans une véranda.
- Génération contrainte. La requête embarque les photos de référence des produits retenus. Le cadrage, l'angle et le bâti de la photo d'origine sont conservés : l'outil ne redessine pas la charpente, il meuble.
- Chiffrage. Deux propositions partent ensemble, la scène complète telle qu'elle apparaît, et la sélection qui tient dans le budget annoncé, avec l'écart entre les deux.
- Livraison et suivi. Email au client, email au dirigeant, écriture du lead dans le CRM.
c'est la condition pour que le modèle ne puisse rien inventer
Tenir le coût et l'abus, qui sont le même problème
Chaque simulation consomme deux appels modèle payants. Un robot qui boucle sur le formulaire ne fait donc pas que polluer la base de leads, il consomme un budget réel. Les garde-fous ci-dessous ne sont pas de la sécurité d'apparat, ce sont les conditions économiques du service.
Trois plafonds plutôt qu'un
Un seul compteur se contourne toujours. Trois compteurs indépendants se contournent beaucoup moins, parce qu'ils ne mesurent pas la même chose : un visiteur légitime qui refait une simulation, un script qui martèle depuis une adresse, et le budget de la journée.
Le détail qui compte : le plafond par email ne compte que les simulations abouties, alors que le plafond journalier compte toutes les tentatives valides. Un visiteur dont la génération a échoué ne consomme pas son quota, et le budget de la journée reste protégé.
Deux modèles, deux métiers
Lire une pièce et choisir un mobilier cohérent est un travail de raisonnement. Produire l'image en est un autre. Vouloir qu'un seul modèle fasse les deux revient à payer le meilleur des deux tarifs sur la totalité du travail, pour un résultat moins bon sur chaque moitié.
La chaîne alterne donc. Un modèle de raisonnement lit la photo, identifie le volume, la lumière et le style, puis sélectionne dans les 97 références. Un modèle d'image reçoit ensuite cette sélection, avec la photo de référence de chaque produit, et compose la scène. Chacun sur son métier.
Une cascade de replis plutôt qu'une erreur
Un générateur d'images met plusieurs dizaines de secondes à répondre et dépasse parfois le délai. Renvoyer une erreur au visiteur pour cette raison serait perdre un lead sur un incident transitoire.
Quatre étages se relaient sur le rendu, chacun avec trois tentatives espacées de trois secondes. Le troisième étage est celui qui mérite l'attention : il bascule sur un modèle plus léger et plus rapide. On y accepte sciemment un rendu un peu moins fin plutôt qu'un échec, et il coûte moins cher que le modèle de qualité. Le quatrième revient au modèle nominal, au cas où l'incident serait passé.
Autrement dit, la dégradation est un choix de conception et non un accident. Le visiteur reçoit toujours quelque chose.
Le catalogue est mis en cache, pas repayé à chaque fois
Le modèle de lecture reçoit les 97 références avec leurs descriptifs à chaque simulation. C'est un bloc volumineux, identique d'une requête à l'autre, et c'est exactement ce qu'un cache de prompt sait absorber.
Le bloc catalogue est donc marqué comme cacheable. L'économie n'est pas anecdotique et elle est arithmétique : une lecture depuis le cache coûte environ un dixième du prix d'entrée normal, l'écriture coûte 1,25 fois ce prix. Le seuil de rentabilité est atteint dès la deuxième requête qui partage le préfixe.
La nuance à connaître, et elle est structurante : la durée de vie par défaut d'une entrée est de cinq minutes, et chaque lecture relance le compteur. Le cache travaille donc à plein pendant les pics, quand les simulations s'enchaînent, et ne sert à rien la nuit. C'est le bon comportement pour ce service : il réduit la facture au moment précis où elle grimperait.
Ce raisonnement impose une discipline dans la construction de la requête. Le catalogue vient en premier, la photo du visiteur et sa demande viennent après. L'inverse invaliderait le cache à chaque appel sans qu'aucune erreur ne le signale.
Ce que le système ne fait pas
Le devis est estimatif et n'engage pas commercialement. L'outil ne redessine pas le bâti : la charpente, les poteaux, le sol et l'ouverture restent ceux de la photo, ce qui est une contrainte assumée et non une limite technique. Et le rendu reste une projection, pas une photographie du résultat final.
Côté données, la photo importée et le rendu ne servent qu'à produire la simulation et à suivre le projet. Ils ne sont cédés à aucun tiers, sont supprimés au-delà de trente-six mois, et le simulateur n'emploie ni cookie publicitaire ni traceur intersites.
Ce qui se transpose ailleurs
Le mobilier n'a rien de particulier ici. Le motif se réplique partout où un catalogue existant doit contraindre une sortie générative :
- un cuisiniste qui chiffre une implantation sur ses propres caissons ;
- un fabricant de menuiseries qui projette une façade avec ses gammes réelles ;
- un revendeur d'équipement professionnel qui montre une salle équipée de son propre parc.
La question à se poser n'est jamais « quel modèle utiliser ». Elle est : de quoi mon catalogue doit-il être capable pour que le modèle n'ait plus le droit d'inventer. Une photo de référence et un descriptif par produit valent mieux que n'importe quel réglage de prompt.
Voir l'outil tourner. Le simulateur est public et gratuit, sans création de compte : balinaisa.ai.
On regarde ensemble ce que vos données permettent déjà, et ce qu'il manque pour qu'un modèle ne puisse plus improviser. Diagnostic gratuit, sans engagement.
Parler de votre situation