Clemz — Génération de photos portées par IA pour les vendeurs Vinted
- Ruby on Rails
- Intelligence artificielle
- Application métier
Clemz automatise le dressing en ligne des vendeurs Vinted : republication des annonces, messagerie, suivi des ventes, sauvegarde des articles. Laurie y a développé une fonctionnalité qui n’existait pas encore : générer la photo portée d’un vêtement à partir d’une simple photo de l’article.
Le problème qu’elle résout est très concret. Une annonce avec un vêtement porté se vend mieux qu’un vêtement posé à plat. Mais l’enfiler, trouver la lumière, se prendre en photo et recommencer pour chaque pièce, c’est ce qui décourage la plupart des vendeurs. Les modèles d’image génératifs — Nano Banana chez Google, puis d’autres — savent aujourd’hui produire ce rendu sans jamais toucher au vêtement.
Le parcours
Le vendeur sélectionne ses articles depuis son tableau de bord et les envoie dans une liste dédiée. Puis il choisit comment il veut ses photos.

Trois modes, avec leurs avantages et leurs limites annoncés sans détour : une photo entièrement générée, plus variée mais plus exposée aux ratés de l’IA ; une photo à partir de son propre modèle, plus stable mais plus répétitive ; ou un simple détourage de l’arrière-plan. Le vendeur sait ce qu’il achète avant de payer.

Vient ensuite le réglage. Qui porte le vêtement — femme, homme, enfant, ou au choix de l’IA — la morphologie, la couleur de peau, le cadrage et le décor. Rien d’autre à faire que cliquer : ces réglages sont traduits en contraintes de prompt par l’application.
Le résultat, et la validation
Les photos produites arrivent dans une vue de validation, en carrousel. L’article original et la photo générée sont présentés côte à côte, et le vendeur tranche : corbeille ou approbation.

Le détail qui compte n’est pas que la photo soit jolie, c’est qu’elle soit fidèle. Sur l’exemple ci-dessus, la boîte Nike du décor d’origine se retrouve dans le rendu. Sur celui-ci, les traces d’usure de la basket blanche sont conservées : semelle marquée, empeigne fatiguée.

C’est une exigence produit autant que technique, et elle est rappelée directement dans l’interface : la photo doit rester représentative de l’article, sous peine de tromper l’acheteur — et de transformer une vente en litige. Un modèle génératif laissé libre embellit spontanément ; tout le travail consiste à l’en empêcher.
Tant qu’une photo n’est pas validée, elle reste invisible partout ailleurs dans l’application.
Payer moins cher en acceptant d’attendre
C’est la partie du produit dont l’ingénierie est la plus intéressante. Le vendeur ne choisit pas seulement un rendu, il choisit un compromis entre le prix et le délai : une génération immédiate, une génération par un modèle alternatif plus coûteux, ou une génération différée sous 24 heures à moitié prix.
Ce dernier mode impose de tenir un état que l’application ne maîtrise plus : la photo est commandée, payée, mais elle arrivera plus tard. Elle apparaît donc dans les générations en cours, signalée comme attendue en différé, et bascule toute seule dans les photos à valider quand elle arrive. Le prix de chaque option est affiché en crédits, avant le clic, et le coût total du lot est rappelé sur le bouton.
Comment c’est construit
Un fournisseur d’IA interchangeable. Chaque modèle est derrière la même interface, si bien qu’en ajouter un ne touche à rien d’autre. C’est la décision structurante du projet : dans un domaine où le meilleur modèle change tous les trimestres, ce qui compte est de pouvoir en changer sans réécrire l’application.
Un prompt en deux couches. Une base figée, qui porte les règles non négociables du rendu — le visage et les mains du mannequin ne doivent jamais apparaître, par exemple — et une partie composée à partir des choix du vendeur. Les réglages de l’interface se traduisent en contraintes, sans jamais que l’utilisateur ait à écrire quoi que ce soit.
Une génération asynchrone et orchestrée. Un service répartit le travail en tâches parallèles, une par photo, exécutées en arrière-plan. Le vendeur n’attend devant rien : ses articles passent dans un onglet dédié, avec un compteur, et en ressortent dès que le rendu est prêt.

En cas d’échec répété, l’article retourne dans la liste, l’erreur est enregistrée avec son contexte, et le crédit est remboursé.
Des crédits tracés. Toute écriture sur le solde passe par un service unique qui journalise chaque mouvement — achat, consommation, remboursement, geste commercial — et applique la remise liée à l’abonnement. Les crédits offerts sont consommés avant les crédits achetés, et la génération est payée avant d’être lancée : sans cela, il suffit d’en déclencher vingt en parallèle pour n’en payer qu’une.
Un suivi côté administration. Chaque lancement crée une activité rattachée aux articles concernés, dont l’avancement progresse photo après photo — avec l’incrément fait de façon à supporter plusieurs générations simultanées sans se marcher dessus.
Ce que ce projet a d’intéressant
La partie visible est spectaculaire, la partie qui fait tenir le produit l’est beaucoup moins : la comptabilité des crédits, le remboursement automatique quand un modèle échoue, l’isolation du fournisseur, la traçabilité des erreurs. C’est là que se joue la différence entre une démonstration d’IA et une fonctionnalité qu’on facture à des clients.






Projets similaires

Nova Vita — Marketplace Ruby on Rails et livraison de meubles avec Cocolis
- Ruby on Rails
- Marketplace
- Application métier

Cocolis.fr — Direction technique et refonte de la plateforme
Plusieurs millions de requêtes par mois
- Ruby on Rails
- Architecture
- Performance

Audit technique d'un extranet de commandes — marque de puériculture
Faille critique corrigée pendant l'audit
- Audit de code
- Ruby on Rails