# Un design system pour tous ceux qui designent
Vibe.co · 2026 · Lead Product Designer · Étude de cas
Source : https://albancarmet.com/fr/case-study/design-system
Le design system de Vibe reconstruit dans Claude Design et ouvert à toute l’entreprise, pour que tous ceux qui construisent des écrans avec Claude les construisent cohérents.
En une ligne : J’ai donné le système à tous.
Équipe : Moi, puis l’autre product designer pour la documentation · Durée : Depuis juin 2026 · IA : Construit et documenté dans Claude Design

## En bref

- Le problème : Devs, marketing et PM construisaient avec Claude des écrans qui ressemblaient à Vibe sans utiliser ses composants. Rien ne les rendait cohérents.
- Ce que j’ai fait : De ma propre initiative, j’ai reconstruit le design system dans Claude Design, je l’ai ouvert à toute l’entreprise, j’ai documenté chaque composant pour le modèle, et j’ai créé un skill de QA pour relire ce qui part en production.
- Résultat : L’autre product designer et moi ne designons plus que dans Claude. Des PM présentent leurs idées en prototype haute fidélité et designent eux-mêmes de petites features, qu’ils nous font relire.
- La limite : Aucune mesure d’usage, et le système n’est pas encore tokenisé : il reste de la dérive.

## L'entreprise

Vibe est une plateforme publicitaire en self-serve pour la TV connectée. Des marques de toutes tailles, des jeunes marques en vente directe aux grands annonceurs, y achètent des spots sur les principales chaînes de streaming, ciblent leurs audiences (y compris les audiences d’acheteurs Walmart) et mesurent les ventes générées, comme elles le feraient sur le search ou les réseaux sociaux.
- Secteur : Ad tech · TV connectée
- Clients : Des milliers de marques, du DTC aux grands annonceurs
- Mon passage : Depuis déc. 2023 · Lead Product Designer

## Démarche

Claude Design est l’endroit où vit le système et où il se documente. Ce qui y entre, et les relectures, sont restés de mon ressort.
- Reconstruire le système : Les composants de Vibe reconstruits dans Claude Design, là où le reste de l’entreprise construit déjà ses écrans. (avec IA, Claude Design)
- L’ouvrir à tous : Une alpha annoncée à toute l’entreprise sur Slack, un guide d’onboarding sur Notion, et deux canaux Slack : les retours design, et le partage des créations. (sans IA)
- Documenter pour le modèle : Avec l’autre product designer, une structure unique de notes d’usage, appliquée à tous les composants. (avec IA, Claude)
- Tester ce qui sort : Des écrans générés avec le système, vérifiés à la main : la cohérence a nettement progressé, il reste de la dérive. (sans IA)
- Relire ce que d’autres designent : Des PM designent de petites features avec le système ; je les relis avant la livraison. (sans IA)
- Automatiser la QA : Un skill qui compare le design à la preview de la PR et décrit chaque écart pour les développeurs. (avec IA, Claude)

## Le problème — Des écrans qui ressemblaient à Vibe, sans en être

Vibe travaille avec Claude. Devs, marketing et PM construisaient déjà leurs propres interfaces avec, et ces interfaces ressemblaient à Vibe sans en être : des composants redessinés, proches mais jamais identiques.
Le cas le plus net : un outil commercial interne construit par un membre de l’équipe growth, pour prospecter, suivre les comptes et gérer le pipeline. Il est utile, et il n’utilise aucun de nos composants : il ne ressemble donc pas à notre produit. Je ne peux pas le montrer.
À quelle fréquence, je ne sais pas : les équipes partagent peu ce qu’elles construisent. J’en ai vu assez pour ne plus attendre.

## La décision — Mettre le système là où les gens designent déjà

Vibe travaille dans Claude au quotidien et Claude Design venait de sortir : je n’ai pas comparé d’outils, le bon endroit était celui que tout le monde avait déjà ouvert. Personne ne me l’a demandé. Mon lead PM en a tout de suite vu l’intérêt, je n’ai donc eu personne à convaincre.

## L’approche — L’ouvrir à tous, puis le documenter pour le modèle

Fin juin 2026, je l’ai annoncé en alpha à toute l’entreprise sur Slack. Avec, un guide d’onboarding sur Notion pour utiliser Claude Design avec le système, parce que le but était aussi d’encourager chacun à construire des outils pour son équipe. J’ai ouvert deux canaux Slack : l’un pour demander un retour design sur ce qu’on fait dans Claude Design, l’autre pour partager ses créations.
L’alpha avait des composants, pas de règles. Avec l’autre product designer et Claude, nous avons d’abord fixé une structure unique pour les notes d’usage, puis nous l’avons appliquée à tous les composants : une définition en une phrase, qui sert aussi de résumé dans l’index ; quand l’utiliser et, pour chaque cas voisin, quel composant prendre à la place ; puis le contenu, le comportement, le placement, les espacements, les états, l’accessibilité et les attributs de test. Une idée par ligne, le pourquoi dans la phrase plutôt qu’un « doit », et une source au bout de chaque ligne.
Puis nous avons testé ce que le modèle produisait. La cohérence a nettement progressé. Il reste de la dérive, sans doute parce que le système n’est pas tokenisé : ni le design ni la tech n’en ont eu le temps. Quand je génère des écrans pour mes propres projets, j’estime qu’environ quatre sur cinq sortent justes. La dérive sur le reste pèse peu face à la vitesse que ça apporte sur un projet complexe.

## Ce qui a changé — Des PM designent de petites features, et je les relis

L’autre product designer et moi ne designons plus que dans Claude. Des PM présentent une idée en prototype haute fidélité plutôt qu’en wireframe. Certains designent eux-mêmes de petites features ou des correctifs, puis nous les font relire. Les projets complexes restent aux designers. Au-delà du produit, je ne sais pas jusqu’où c’est allé.
Les créatives bloquées, en novembre 2026, en sont un bon exemple. Une créative est bloquée quand elle enfreint les règles éditoriales, et jusque-là l’annonceur devait contacter un CSM pour savoir pourquoi. Le PM a conçu la première version avec le système. En relecture, j’ai réutilisé le composant Alert existant pour que le blocage se lise au premier coup d’œil, et passé le nom et les labels en variante désactivée, puisqu’une créative bloquée ne se modifie pas.
La première partie, en production, explique le blocage dans le produit. Dans la seconde, sur laquelle le PM et moi avons aussi travaillé, un formulaire permet de demander des détails sans passer par un CSM, et un e-mail prévient l’annonceur quand une créative est bloquée.

## Relire à grande échelle — Un skill de QA, pour que la relecture ne devienne pas le goulot

Plus de monde qui génère des écrans, c’est plus à relire, et j’étais devenu le goulot. Sur un projet de la taille de la bibliothèque de publicités, une revue visuelle manuelle pouvait me prendre plusieurs heures. Et je génère mes designs dans Claude en menant plusieurs projets en parallèle : ma propre relecture laissait parfois passer le rendu d’un élément qui n’est pas un composant.
J’ai donc créé un skill de QA. Il compare le design à la preview de la PR, les met côte à côte, signale chaque écart et rédige les étapes pour le reproduire. Les devs corrigent en autonomie. Je l’ai d’abord utilisé sur l’upload de créatives dans l’agent, en novembre 2026, une feature pleine de cas d’usage et de cas limites. Le premier passage a relevé une douzaine d’écarts entre le design et le développement : la plupart côté intégration, certains dans des détails que j’avais laissés passer en relecture.
Il n’est pas parfait : il signale parfois un faux positif. Deux choses l’améliorent avec le temps. Plus mes flows sont documentés dans Claude Design, moins il se trompe. Et quand je lui signale un faux positif pendant qu’il rédige le rapport, il en tient compte et en produit moins la fois suivante.
Je suis le seul à m’en servir pour l’instant, et je l’ai partagé à l’autre product designer. J’ai appris ensuite qu’un développeur construisait son pendant côté code : l’intégration générée à partir de Claude Design, avec un skill qui corrige seul les composants non réutilisés et la dérive visuelle.

## La suite — Un site dédié, pour tous ceux qui construisent

Le système vit encore dans les réglages de Claude Design, où peu de gens regardent. Je construis un site dédié, au niveau des design systems publics, qui réunit le système produit et les guidelines de la marque et du site web, que gère le marketing. Il n’est pas encore en ligne : un refresh du système est en discussion, et nous l’attendrons peut-être.

## Contraintes

- Tout le monde avait déjà Claude : Devs, marketing et PM construisaient leurs propres écrans. Le but n’était pas de les arrêter, mais de rendre cohérent ce qu’ils construisaient.
- Un système qui n’est pas tokenisé : Ni le design ni la tech n’ont eu le temps de le tokeniser : le modèle a donc moins de prise.
- Des équipes qui partagent peu : Je ne pouvais pas mesurer à quelle fréquence se construisaient des écrans incohérents. Je n’en voyais qu’une partie.

## Signaux et recherche

Pas de discovery formelle : je suis parti de ce que je voyais se construire.
- Outil interne — Un outil commercial construit par la growth : Utile, et construit sans aucun de nos composants : il ne ressemble donc pas à notre produit.
- Product design — Deux designers, une seule identité : L’autre product designer et moi avions besoin, autant que les autres, d’écrans visuellement cohérents en sortie de Claude.

## Décisions et arbitrages

- Reconstruire le système dans Claude Design plutôt que le garder dans Figma. Décidé avec : Ma propre initiative, soutenue par mon lead PM. Écarté : Garder le système dans Figma — Là où seuls les designers pouvaient s’en servir. Retenu : Le reconstruire dans Claude Design — Là où devs, marketing et PM construisent déjà leurs écrans, avec derrière chaque composant une note d’usage que le modèle lit. Pourquoi : Le bon endroit était celui que tout le monde avait déjà ouvert : Vibe travaille dans Claude au quotidien. Ce que ça a coûté : Une comparaison des outils. J’ai misé sur celui qui était déjà ouvert, sans vérifier si un autre générerait un design plus cohérent.

## Résultats

Pas encore de mesure d’usage, mais la façon de designer autour de moi a changé.
(Depuis juin 2026)
- 2 sur 2 : Product designers qui ne designent plus que dans Claude
- ~12 : Écarts entre design et développement relevés au premier passage de QA
Ce qui a marché :
- Des PM prototypent en haute fidélité plutôt qu’en wireframe
- Des PM designent de petites features et demandent une relecture design
- Les devs corrigent les écarts de QA en autonomie
Ce qui n'a pas marché :
- Il reste de la dérive : le système n’est pas tokenisé
- Aucune visibilité sur l’usage hors produit

## Reste ouvert

D’abord les tokens, puis un moyen de voir qui construit quoi. Le système n’est pas tokenisé, la dérive ne disparaîtra donc pas d’elle-même, et je n’ai aucune mesure de l’usage hors produit. La prochaine étape, ce sont les tokens, puis un moyen de voir qui construit quoi.