← Retour aux projets
CodeEn cours

Envelope : Étude de cas : médiathèque, review et IA

Mission freelance chez Noside sur Envelope, SaaS de workflows IA pour la mode. Médiathèque d'équipe, outil de review créative, enrichissement IA des médias et ingénierie assistée par Claude Code.

2026
Code
En cours
Next.js, React, TypeScript, Supabase, PostgreSQL, Yjs / Liveblocks, Vercel AI SDK, Claude Code

Contexte

Envelope est un SaaS de workflows IA : les équipes créatives de la mode et du luxe assemblent sur un canvas collaboratif des nœuds (images, textes, vidéos, modèles génératifs) pour produire leurs visuels. Le produit est développé par Noside, avec une équipe de deux développeurs. J’y interviens en freelance depuis juillet 2026.

Stack : Next.js 16, React 19, TypeScript, Supabase (Postgres, Auth, Storage, RLS), Drizzle, canvas synchronisé par CRDT (Yjs, Liveblocks), Vercel AI SDK, Stripe, Vitest.

Cette page décrit la démarche et les problèmes résolus, sans code ni donnée client.

Ce que j’ai livré

Médiathèque d’équipe et review créative

Le besoin : les équipes échangeaient leurs visuels par mail et Slack, sans historique ni versions. J’ai conçu et livré de bout en bout une médiathèque partagée au niveau de l’équipe, puis un outil de review inspiré de Frame.io.

  • Overlay unique pour prévisualiser et commenter : pins, annotations vectorielles, fils de tickets avec statuts.
  • Versions v1…vN d’un même visuel, avec comparaison A/B par balayage.
  • Vidéo : capture de poster côté client et commentaires horodatés sur une timeline.
  • Relecture anonyme : un client externe commente via un lien de partage, avec passphrase, kill switch et notifications par e-mail.

Enrichissement IA des médias

Chaque média est décrit par un modèle vision-langage. J’ai transformé ces descriptions en outils de recherche : facettes (cadrage, moment de la journée, ambiance lumineuse), extraction de palette 12 couleurs et filtre par couleur de fond, champs personnalisés définis par l’équipe et classifiés par LLM, regroupement de visages en personnes derrière un opt-in.

Connecteurs DAM, sécurité, sauvegardes

Framework de connecteurs OAuth à tokens chiffrés (OneDrive, SharePoint, Dropbox) pour importer et publier les médias. Garde d’autorisation généralisée à toutes les server actions, avec un test qui fait échouer la CI dès qu’une action touche la base sans passer par la garde. Sauvegarde chiffrée nightly de la base et du stockage vers Scaleway.

Trois problèmes qui méritent d’être racontés

Une image ressuscitée par un second navigateur

Après un « remplacer cette image partout dans le canvas », l’ancienne image réapparaissait pour un collègue qui ouvrait le projet. Cause : un navigateur fraîchement ouvert peint d’abord son cache local, un traitement de fond démarrait sur cette vue périmée et réécrivait le contenu entier comme une nouvelle écriture CRDT, causalement postérieure au remplacement. Elle gagnait. Diagnostic par timestamps de stockage et lecture directe de la room Liveblocks ; correctif par un signal « vue réconciliée avec le serveur » qui gate tout writer de fond.

Une notification qui ne pouvait jamais partir

La spec disait qu’un visiteur anonyme laissait son e-mail. Le champ n’avait jamais existé. La règle « pas d’e-mail, pas de notification » masquait parfaitement un « jamais d’e-mail ». Leçon : vérifier qu’une donnée est réellement collectée avant d’écrire la règle qui la consomme.

Une fuite que 6 000 tests ne voyaient pas

Une route de push vers un DAM validait la forme d’un chemin de stockage, puis téléchargeait le fichier avec un rôle privilégié : un chemin d’une autre équipe passait. Trouvée en revue de code, pas par la suite de tests. Depuis, une liste d’autorisation du proxy est épinglée par un test, et toute nouvelle surface anonyme doit y figurer.

Méthode : l’IA comme outil de travail quotidien

Toute la mission s’est faite avec Claude Code, en gardant la responsabilité de chaque décision.

  1. Spec puis plan. Chaque feature commence par un document de spec, puis un plan d’implémentation en incréments, chacun avec ses critères de succès.
  2. Exécution par agents. Les incréments sont exécutés par des agents, avec validation visuelle entre chaque et la suite complète de tests à chaque étape.
  3. Revue multi-agents. Chaque branche passe une revue de code menée par des dizaines d’agents en parallèle, puis chaque finding est vérifié de façon contradictoire. Entre 6 et 11 findings réels par feature, tous corrigés et épinglés par un test de régression.
  4. Plan de test et mutation-check. Un plan de test manuel est rédigé avant la PR, en commençant par les scénarios de fuite. Chaque test de régression est vérifié en retirant le correctif : il doit échouer.

Résultat : la suite de tests est passée de 3 800 à 6 700, plus de 20 PR mergées en trois mois, et une mémoire de projet qui capitalise les pièges pour les sessions suivantes.