--- title: "voxcog : un design system en code et des tests utilisateurs" description: "Comment l’interface de voxcog a reçu un design system en code, et une étude où cinq constats sur dix-sept sont tombés à la confrontation au code." url: https://torn.studio/fr/realisations/voxcog-design-system-et-tests-utilisateurs locale: fr published: 2026-08-31 updated: 2026-08-26 --- # voxcog : un design system en code et des tests utilisateurs > **Réponse courte:** Torn Studio a posé l’interface de voxcog sur un design system en code, avec des jetons en OKLCH et un jeu de règles documenté. Une étude utilisateurs a produit dix-sept constats ; onze ont tenu, un en partie et cinq sont tombés à la confrontation au code. Douze changements sont partis en production. **Client:** voxcog · **Livré:** 2026-08-26 **La relation du studio au client:** voxcog est un produit que Torn Studio a construit et dans lequel le studio détient une participation. Le studio a assuré la direction produit, l’architecture et la réalisation jusqu’à la livraison en août 2026. ## La commande voxcog avait besoin d’une interface cohérente sur une quarantaine de vues construites par une seule personne en quelques mois, et devait savoir lesquels des problèmes remontés étaient réels avant de refaire quoi que ce soit. ## Ce qui rendait la tâche difficile - Une interface construite à vive allure par une seule personne dérive visuellement dès que chaque vue choisit ses propres couleurs et ses propres espacements. - Une étude utilisateurs livre de vrais défauts mêlés à des souhaits, et bâtir tout ce qui remonte est le chemin le plus court vers les mauvaises choses. - Le produit devait être prêt au lancement, ce qui exige que les états vides et les surfaces juridiques soient du travail achevé. ## Des chiffres vérifiables | Des chiffres vérifiables | | | | --- | --- | --- | | 17 | constats dans une étude utilisateurs | Onze ont tenu, un en partie, cinq sont tombés face au composant qu’ils désignaient. L’évaluation reste dans le dépôt avec le motif de chaque rejet. | | 12 | changements livrés depuis cette étude | Les cinq rejetés restent dans le document avec leur motif, si bien que le lecteur suivant voit ce qui a été testé puis écarté. | | 373 | fichiers de test | Placés à côté du code qu’ils couvrent. Les évaluations de l’agent figurent parmi eux et s’exécutent comme des commandes propres. | | 300 | lignes de plafond par fichier | La règle qui garde les composants divisibles. Elle figure dans le fichier de consignes du dépôt et vaut pour tout le neuf. | ## Comment cela a été fait ### Les jetons comme unique source visuelle Couleur, typographie, rayons et ombres sont déclarés comme jetons en OKLCH et utilisés par variables. La règle a été consignée comme référence propre, si bien qu’une vue nouvelle hérite du système et y puise ses valeurs. ### Chaque constat confronté au code d’abord Les dix-sept constats de la campagne d’avril 2026 ont été lus un à un face au composant que chacun désignait. Onze ont tenu, un a tenu en partie, et cinq décrivaient en réalité une chose qui marchait déjà ou une fonction inexistante. ### Des états vides qui donnent une direction Les états vides trop maigres ont été réécrits en guides courts qui expliquent à quoi sert la surface et proposent une étape suivante. Les barres d’outils restent masquées tant qu’une liste est vide, si bien qu’un nouvel arrivant trouve une consigne. ### La récupération de données comme un seul motif Toute la lecture côté client est passée sur une couche de cache commune avec fabrique de clés et gestion d’erreurs partagée. Les boutons de rafraîchissement ont pu disparaître, car les listes savent désormais d’elles-mêmes quand elles sont périmées. **Technologies:** React 19, Next.js 16, Tailwind CSS v4, shadcn/ui, OKLCH, TanStack Query, Playwright ## Jusqu’où va cette preuve Ceci montre une interface cohérente et une méthode qui sépare les vrais problèmes des souhaits. Sur la conversion, cela ne montre rien : voxcog a été livré avant le lancement, il n’existe donc aucun trafic à mesurer. ## Questions fréquentes ### Pourquoi confronter les constats utilisateurs au code avant de construire ? Parce qu’une étude mêle de vrais défauts à des souhaits et à des choses qui marchent déjà. Cinq constats sur dix-sept sont tombés à la vérification, et les bâtir aurait coûté du temps et dégradé l’interface. ### Quelle différence entre un design system et une bibliothèque de composants ? La bibliothèque, ce sont les composants. Le système, ce sont les règles qui décident de ce qui a le droit d’exister : quelles couleurs existent, quels espacements sont permis et ce qui se passe quand une chose manque. Les règles tiennent un produit qui grandit vite. ### Pourquoi OKLCH comme espace colorimétrique ? OKLCH est perceptuellement uniforme, donc une échelle à pas réguliers paraît régulière et le contraste se calcule. Une variante sombre devient une redéfinition de la clarté dans le même système. ### Que veut dire qu’un état vide donne une direction ? Que la surface explique à quoi elle sert et propose une étape suivante quand il y a zéro ligne à montrer. Un nouvel arrivant trouve une consigne, et la recherche et les filtres restent masqués jusqu’à ce qu’il y ait matière à chercher. ### Pouvez-vous bâtir un design system pour notre produit existant ? Oui. Le travail commence par un inventaire des valeurs déjà en usage, les rassemble en un jeu de jetons, puis migre vue par vue. Le système est livré comme du code dans votre dépôt et comme une référence écrite. ### Combien de vues le travail d’interface a-t-il couvert ? Une quarantaine de vues réparties entre le chat, les documents, les signaux, les tâches, les espaces de travail et une partie entretiens publique. Toutes partagent le même jeu de jetons et la même bibliothèque de composants.