Elias Bellouti
EN
← Retour aux projets

Projet personnel · Génération d’images

Clothify : visuels de vêtements portés

Clothify part d’une photo de vêtement pour préparer une image de présentation portée. L’utilisateur envoie son image dans Discord, choisit le type de vêtement, la carrure et la vue, puis reçoit le résultat dans le même canal. J’ai développé ce parcours et relié le bot à PostgreSQL, n8n et un modèle d’image. Les demandes et leurs états servent de contrat entre les composants : je peux faire évoluer la génération sans reprendre l’interface, tout en distinguant une image créée d’une image effectivement livrée.

Vidéo du bot en fonctionnement ; démo avec deux vêtements présentés sous quatre angles.

Capture vidéo du bot Discord Clothify : une photo de vêtement est envoyée, le bot répond avec un identifiant de tâche et les paramètres analysés, puis poste le visuel généré dans le salon.

Partir d’une photo de vêtement

J’ai créé Clothify pour produire un visuel de vêtement porté à partir d’une photo destinée à une présentation e-commerce. Discord sert de point d’entrée : l’utilisateur envoie l’image, choisit le vêtement, la personne représentée, la carrure et l’angle de vue, puis retrouve le résultat dans la conversation.

J’ai conçu un parcours avec menus, boutons et saisie complémentaire pour rendre ces choix accessibles sans manipuler les paramètres d’une API. Les interactions sont rattachées au demandeur, et un identifiant permet de retrouver le travail lancé. Le type de vêtement accepte aussi une description libre lorsque le menu ne suffit pas.

Séparer la demande de la génération

Le bot Python enregistre le fichier et une demande dans PostgreSQL. Une notification réveille le workflow n8n, qui prépare les paramètres, construit le prompt, appelle le modèle via OpenRouter puis sauvegarde l’image. Le bot consulte ensuite l’état du traitement pour remettre le résultat dans Discord.

J’ai retenu un déclenchement par notification au départ et une consultation périodique simple pour la livraison. La base distingue une génération terminée d’un envoi effectué. Le bot connaît ce contrat de données ; les détails de l’API d’image restent dans n8n. Un changement de modèle se concentre donc sur le workflow de génération.

Relier les choix au rendu

L’angle sélectionné devient une consigne de caméra. Le prompt demande de préserver matière, vêtement et logos, de cadrer sous le visage et d’écarter les éléments d’interface qui peuvent entourer une capture source. Ces instructions orientent le modèle ; les surfaces invisibles sur la photo restent interprétées lors de la génération.

J’ai travaillé sur les défauts qui apparaissent entre composants. Une orientation fixe pouvait contredire la vue choisie. Une transition tardive pouvait remettre un travail terminé en traitement et empêcher la livraison. J’ai corrigé la construction des consignes et l’ordre des transitions, puis unifié les chemins du volume partagé pour que le bot et n8n désignent les mêmes fichiers.

Conserver une intégration modifiable

Les paramètres métier sont séparés des réglages d’environnement. Les exports n8n sont versionnés avec le code pour conserver la logique de génération et permettre sa reconstruction. La documentation du projet décrit ces contrats et la procédure de changement de modèle.

La vidéo montre le bot Discord. La démo du portfolio propose gratuitement deux vêtements sous quatre angles enregistrés. Sa génération avec code d’accès utilise un appel direct au modèle, distinct de la chaîne Discord, PostgreSQL et n8n. J’ai gardé cette séparation pour rendre les exemples consultables sans lancer de nouvelle génération.

Les compétences mises en pratique

Machine learning et intégration IA

J’ai intégré l’appel au modèle dans n8n et construit les consignes visuelles à partir du vêtement, du gabarit et de l’angle choisis.

Architecture logicielle

J’ai découplé le bot Discord et la génération n8n grâce à un contrat de données PostgreSQL : le modèle peut changer sans reprendre le parcours utilisateur.

Tests, évaluation et fiabilité

J’ai corrigé l’ordre des transitions pour préserver le statut de fin de génération, puis défini une recette qui vérifie le statut et le fichier produit.

← Retour aux projets