Case study
FIB__R
Éco-score textile : l'impact d'un vêtement à partir d'une photo
Problème
L'industrie textile est l'une des plus polluantes de la planète.
Pourtant, devant un vêtement en magasin, on n'a aucun repère. Ni sur la qualité de fabrication, ni sur ce qu'il a coûté à l'environnement.
Pourtant, devant un vêtement en magasin, on n'a aucun repère. Ni sur la qualité de fabrication, ni sur ce qu'il a coûté à l'environnement.
Yuka a rendu la nutrition lisible d'un scan. Côté vêtements, rien.
Le pari de FIB__R : en quelques photos : l'étiquette, la face, le dos… un diagnostic fiable est généré en quelques secondes. Un score de qualité détaillé, une estimation d'impact adossée à une source officielle, et un expert IA pour creuser une réponse.
Contraintes
Trois contraintes ont cadré le projet, et chacune a laissé une trace dans l'architecture.
Le temps, d'abord. C'était un projet de fin de bootcamp.
J'ai choisi une tranche verticale complète et fonctionnelle plutôt qu'un produit large et creux, mieux valait un chemin qui marche du début à la fin qu'une collection d'écrans à moitié branchés.
Ensuite, une règle que je me suis imposée : une réponse d'IA doit être exploitable par du code. Pas « à peu près exploitable ».
J'ai donc contraint la sortie du modèle par un schéma, réponse est toujours un JSON valide, et l'interface n'a jamais à deviner.
Ça supprime le parsing fragile, la source de bug numéro un quand on branche un LLM sur une vraie application.
Enfin, le coût. Appeler une API de vision à chaque test, en développement, ça chiffre vite.
J'ai câblé un mode réel/stub commutable : je développe et je teste sur des réponses simulées, je bascule sur l'IA réelle quand j'en ai besoin.
Le temps, d'abord. C'était un projet de fin de bootcamp.
J'ai choisi une tranche verticale complète et fonctionnelle plutôt qu'un produit large et creux, mieux valait un chemin qui marche du début à la fin qu'une collection d'écrans à moitié branchés.
Ensuite, une règle que je me suis imposée : une réponse d'IA doit être exploitable par du code. Pas « à peu près exploitable ».
J'ai donc contraint la sortie du modèle par un schéma, réponse est toujours un JSON valide, et l'interface n'a jamais à deviner.
Ça supprime le parsing fragile, la source de bug numéro un quand on branche un LLM sur une vraie application.
Enfin, le coût. Appeler une API de vision à chaque test, en développement, ça chiffre vite.
J'ai câblé un mode réel/stub commutable : je développe et je teste sur des réponses simulées, je bascule sur l'IA réelle quand j'en ai besoin.
Démarche
Le point de départ n'a pas été l'upload. Techniquement, envoyer une photo est trivial.
Le vrai sujet, c'est de rendre lisibles deux familles de résultats qui n'ont rien à voir :
un score de qualité en cinq critères, et un impact environnemental en CO₂ et en eau.
J'ai cadré le parcours minimal : trois photos guidées, étape par étape, avec une vérification de lisibilité de l'étiquette avant de lancer quoi que ce soit. Si l'étiquette est floue, on le sait tout de suite, pas après trente secondes d'analyse.
Pour la donnée de qualité, j'ai conçu une visualisation orbitale.
Pour l'expert, je voulais un chat qui connaisse l'analyse en cours et réponde à ce vêtement-là, pas un assistant générique de plus.
Le vrai sujet, c'est de rendre lisibles deux familles de résultats qui n'ont rien à voir :
un score de qualité en cinq critères, et un impact environnemental en CO₂ et en eau.
J'ai cadré le parcours minimal : trois photos guidées, étape par étape, avec une vérification de lisibilité de l'étiquette avant de lancer quoi que ce soit. Si l'étiquette est floue, on le sait tout de suite, pas après trente secondes d'analyse.
Pour la donnée de qualité, j'ai conçu une visualisation orbitale.
Pour l'expert, je voulais un chat qui connaisse l'analyse en cours et réponde à ce vêtement-là, pas un assistant générique de plus.
Le fil rouge : faire dialoguer le design et la technique au lieu de les empiler.
La sortie d'IA est structurée pour que l'écran ne casse jamais.
Les traitements lourds tournent en arrière-plan pour ne pas figer l'utilisateur pendant l'analyse.
Les traitements lourds tournent en arrière-plan pour ne pas figer l'utilisateur pendant l'analyse.
Nous étions quatre. Mon rôle a été de tenir le cap et la base de code : mise en place du dépôt et de l'environnement, revue de toutes les pull requests, gestion des clés d'API et des déploiements, achat et configuration du nom de domaine. J'ai trouvé la base de données gouvernementale Ecobalyse, lu sa documentation, puis transmis à l'équipe la manière de l'exploiter.
Un arbitrage a demandé d'insister : le design. Il aurait été plus rapide de laisser l'IA générer l'interface. J'ai imposé un parti pris neutre et tenu, pour que FIB__R ne ressemble pas à une énième application sortie d'un prompt.
Design
Le produit devait donner envie d'essayer sans barrière.
L'analyse fonctionne sans création de compte, on scanne, on voit, on décide ensuite si on veut aller plus loin.
L'interface de capture ouvre la caméra dans le navigateur et guide en trois temps : étiquette, face, dos.
Chaque étape a son cadrage et sa validation.
La pièce maîtresse, c'est la visualisation des résultats.
Un score global au centre, cinq nœuds critères en orbite, chacun cliquable pour afficher sa justification.
Anneaux de progression, panneau de détail au clic, nœuds animés.
Je ne l'ai pas prise dans une bibliothèque de composants, je l'ai codée à la main, parce qu'aucun graphique tout fait ne racontait ce que je voulais montrer.
C'est là que le design et le code se rejoignent vraiment sur ce projet.
Le tout porte une identité complète :
nom, logo, système graphique, ton éditorial.
FIB__R ressemble à un produit, pas à un exercice.
L'analyse fonctionne sans création de compte, on scanne, on voit, on décide ensuite si on veut aller plus loin.
L'interface de capture ouvre la caméra dans le navigateur et guide en trois temps : étiquette, face, dos.
Chaque étape a son cadrage et sa validation.
La pièce maîtresse, c'est la visualisation des résultats.
Un score global au centre, cinq nœuds critères en orbite, chacun cliquable pour afficher sa justification.
Anneaux de progression, panneau de détail au clic, nœuds animés.
Je ne l'ai pas prise dans une bibliothèque de composants, je l'ai codée à la main, parce qu'aucun graphique tout fait ne racontait ce que je voulais montrer.
C'est là que le design et le code se rejoignent vraiment sur ce projet.
Le tout porte une identité complète :
nom, logo, système graphique, ton éditorial.
FIB__R ressemble à un produit, pas à un exercice.
Technique
Une application full-stack Ruby on Rails 8.1, pensée mobile-first, sans rechargement grâce à Turbo et Stimulus. Le flux complet : capture des photos, analyse asynchrone par un modèle de vision, estimation d'impact via Ecobalyse, restitution des résultats, chat expert en temps réel.
Le pipeline IA a trois usages bien séparés.
L'analyse du vêtement tourne en tâche de fond : un appel à Claude Sonnet 4.6 via ruby_llm, avec la sortie contrainte par schéma.
Le retour est garanti exploitable : score, cinq critères détaillés, paramètres matières.
L'impact environnemental passe par un service dédié. Il estime la masse du vêtement (poids de base par type × coefficient de taille), mappe les matières vers les identifiants Ecobalyse, puis interroge l'API gouvernementale de l'ADEME.
Retour : CO₂, eau, score global.
J'ai branché une source officielle et traçable plutôt que d'inventer un score maison, sur un sujet environnemental, la crédibilité de la donnée est le produit.
Le chat expert tourne aussi en arrière-plan : reconstruction de l'historique, prompt système « expert textile », injection du contexte de l'analyse en cours (les scores, les données environnementales), réponse diffusée en temps réel.
Côté données :
Le pipeline IA a trois usages bien séparés.
L'analyse du vêtement tourne en tâche de fond : un appel à Claude Sonnet 4.6 via ruby_llm, avec la sortie contrainte par schéma.
Le retour est garanti exploitable : score, cinq critères détaillés, paramètres matières.
L'impact environnemental passe par un service dédié. Il estime la masse du vêtement (poids de base par type × coefficient de taille), mappe les matières vers les identifiants Ecobalyse, puis interroge l'API gouvernementale de l'ADEME.
Retour : CO₂, eau, score global.
J'ai branché une source officielle et traçable plutôt que d'inventer un score maison, sur un sujet environnemental, la crédibilité de la donnée est le produit.
Le chat expert tourne aussi en arrière-plan : reconstruction de l'historique, prompt système « expert textile », injection du contexte de l'analyse en cours (les scores, les données environnementales), réponse diffusée en temps réel.
Côté données :
User → Analysis → Chat → Message plus un Criterium pour les cinq critères de qualité (score 0 à 10).
Les chats sont scindés par usage : analyse, discussion, questionnaire.
La composition matières est stockée en JSONB.
Le user_id est nullable, puisqu'on peut analyser sans compte.
Deux détails de temps réel que j'ai tranchés à dessein, pas par défaut : les jobs de fond passent par Solid Queue (une file en base SQL, sans Redis) ; et pour les mises à jour d'écran, WebSocket via Turbo Streams pour le chat, mais simple polling JSON pour le statut de l'analyse. Deux problèmes différents, deux réponses différentes.
Les chats sont scindés par usage : analyse, discussion, questionnaire.
La composition matières est stockée en JSONB.
Le user_id est nullable, puisqu'on peut analyser sans compte.
Deux détails de temps réel que j'ai tranchés à dessein, pas par défaut : les jobs de fond passent par Solid Queue (une file en base SQL, sans Redis) ; et pour les mises à jour d'écran, WebSocket via Turbo Streams pour le chat, mais simple polling JSON pour le statut de l'analyse. Deux problèmes différents, deux réponses différentes.
Stack et déploiement : Rails 8.1, PostgreSQL, Solid Queue / Cache / Cable, Turbo + Stimulus + ImportMap, Bootstrap 5.3, Active Storage vers Cloudinary, Devise. Déploiement sur Heroku, avec un nom de domaine dédié
Impact
Un produit qui marche de bout en bout, déployé, qui enchaîne capture caméra, analyse IA, calcul d'impact officiel et chat expert sans se casser en route.
La preuve, surtout, que je passe d'une idée à un produit IA déployé en tenant la conception, la direction technique et une bonne partie du code : vision à sortie structurée, API gouvernementale, jobs asynchrones, temps réel, interface de visualisation sur mesure. Et la présentation en direct au demo day.
Un cas qui pose noir sur blanc ce que je fais : je conçois les parcours, je rédige l'UX, et je code le produit.
Réflexion
Ce que j'en retiens
FIB__R est un projet de fin de bootcamp, bâti en temps contraint.
Un MVP qui fonctionne, pas un produit fini, et c'est ce qu'il devait être.
Ce que je pousserais ensuite, si je le reprenais : affiner l'estimation environnementale et assumer son incertitude directement dans l'interface, au lieu de la lisser ; donner une vraie mémoire à l'expert avec un RAG sur une base de connaissances textile, le chat actuel est contextuel, pas encore documentaire ; durcir la sécurité ; monter un vrai protocole de tests utilisateurs.
Le projet confirme surtout la place que je veux : la couture entre le design et l'ingénierie. Concevoir un parcours, le coder, et faire dialoguer une IA avec une donnée métier.
Un MVP qui fonctionne, pas un produit fini, et c'est ce qu'il devait être.
Ce que je pousserais ensuite, si je le reprenais : affiner l'estimation environnementale et assumer son incertitude directement dans l'interface, au lieu de la lisser ; donner une vraie mémoire à l'expert avec un RAG sur une base de connaissances textile, le chat actuel est contextuel, pas encore documentaire ; durcir la sécurité ; monter un vrai protocole de tests utilisateurs.
Le projet confirme surtout la place que je veux : la couture entre le design et l'ingénierie. Concevoir un parcours, le coder, et faire dialoguer une IA avec une donnée métier.