Mathieu est design system lead chez Deezer depuis janvier. Après douze ans de design, dont sept chez Brigade de founding designer à VP Brand, il partage sa grille de lecture sur une question concrète : comment faire entrer l'IA dans un design system qui a déjà des années d'histoire. Trois observations, des cas vécus, et une conviction sur ce qui reste incompressible.
1. Un design system est une infrastructure, pas un produit
Mathieu commence par revenir sur la définition, volontairement. Sur LinkedIn, design system rime avec composants et delivery. Pour lui, c'est réducteur.
"Un design system, une infrastructure partagée, un langage commun entre les équipes afin de produire rapidement une expérience cohérente."
Il assume le glissement de vocabulaire. Moins de produit, plus d'infrastructure. Une infrastructure de cohérence et de vélocité. Il compare ça au DevOps : poser des rails.
Sa grille découpe le design system en six briques : les design assets (pas seulement Figma, aussi les illustrations, photos, animations), le content (localisation, tone of voice, inclusivité, le design system des mots), la documentation, l'écosystème, les process et le tooling avec les skills, la gouvernance, et le code.
Sur l'écosystème, l'exemple Deezer est parlant. Ce n'est pas web plus mobile. C'est aussi la télé, les enceintes, la voiture.
2. L'infrastructure humaine reste la variable d'ajustement
"On parle beaucoup d'infrastructure technique, mais il y a l'infrastructure humaine."
Pour lui c'est la partie qu'on élude et qui restera pourtant déterminante. Il y a de la prise de décision, du jugement, des équipes qui doivent collaborer.
Il cite Arthur Mensch, CEO de Mistral, entendu en commission parlementaire.
"Seul, on va dix à vingt fois plus vite. À cinq, les gains sont moindres à cause de l'enjeu de communication. Et dans une très grosse entreprise, il faut lever les goulets d'étranglement organisationnel pour atteindre les gains espérés."
L'échelonnement qu'il décrit : en solo, Figma et le code suffisent. À deux ou trois designers, les premiers process émergent. En multi-produits et multi-plateformes, arrivent les enjeux de contenu et de localisation. Au-delà, avec des équipes contenu, design, marketing et brand, c'est la gouvernance qui devient le sujet.
Les challenges typiques du legacy : du code ancien et récent qui se croisent (XML et Compose sur mobile), des architectures back-end qui ne sont plus résilientes, l'absence de process, les incompréhensions de naming entre équipes, et le manque de documentation.
Sur la documentation, il pose un changement de nature :
"Le but, ce n'est plus vraiment qu'un humain le lise, c'est plutôt que ce soit un manuel d'instruction pour l'IA."
3. Ce que l'IA débloque vraiment sur du legacy
Ses cas d'usage concrets, tous testés en mission.
Audit du code existant. Il a créé beaucoup de skills et utilise Copilot pour discuter avec la code base. Il génère la doc de l'existant et des rapports interactifs HTML sur l'utilisation des composants : nombre d'occurrences, cas d'usage. Utile pour recréer de la documentation et réaligner sur les namings.
Audit des Figma. Figma s'interroge via le MCP. Il se connecte avec Claude Code pour faire des comparatifs massifs, typiquement sur des migrations d'anciennes icônes vers des nouvelles.
Synthèse de feedbacks massifs. Workshops, surveys sur la satisfaction, les usages, le temps passé, les points de friction. Beaucoup de matière quand on interroge soixante personnes.
Sparring partner permanent. Il souligne que le modèle connaît les guidelines Apple, Material et Uber, ses références.
Sur le gain de temps, il est précis. Pour connaître les cas d'usage et le nombre d'occurrences d'un composant, on passe de plusieurs jours à dix minutes. Pour la génération de documentation, un draft en quelques minutes contre deux heures à la main, à reprendre ensuite.
"Il n'y a pas juste du temps, il y a de la qualité de output."
4. Les layers et les zones de compression
Sa deuxième observation. Le design system est une superposition de layers. Certaines sont incompressibles, d'autres sont devenues compressibles grâce à l'IA. Tout l'enjeu est de trouver où sont les zones de compression.
La layer de base, c'est code et design. On aimerait que ce soit tout. Mais avec du legacy et plus de monde, chaque strate s'accumule et prend elle-même de la place. Une feature doit traverser une épaisseur croissante avant d'arriver en prod.
Deux leviers. En amont, sur les nouveaux design systems, se passer entièrement de Figma et démarrer directement en code pour limiter le nombre de strates. Sur l'existant, compresser chaque strate par l'automatisation et l'outillage.
Les exemples qu'il a repérés : l'automatisation des GitHub release notes chez Back Market, la génération de documentation via Dust chez Deezer, Vitamin Checker chez Decathlon, les checklists embarquées dans Figma chez Uber, aujourd'hui potentiellement rendues obsolètes par Check Design.
Troisième levier : les outils sur mesure. Ses propres plugins autour du tone of voice, de la data, des assets design system compliant, ou des formulaires Slack pour le support du design system. Ce qui passait avant par l'équipe tech.
5. Les quatre types de code
L'ambition partagée par tout le monde : manipuler un code unique de l'idéation à la delivery. Facile dans une entreprise jeune bâtie directement avec l'IA. Beaucoup plus compliqué avec des strates accumulées. En attendant, il distingue quatre codes.
Code d'idéation. Générer des variations autour d'une idée. Stitch, le slash inspirations de Magic Patterns, Subframe. Ou Claude Code avec shadcn.
User test code. Un code avec lequel l'utilisateur sera familier, cohérent avec la marque, sans être fidèle aux composants finaux. Les fichiers design.md, Figma Make qui embarque les librairies Figma, ou un environnement connecté aux repos.
Delivery code. Un proto fonctionnel qui utilise grosso modo les composants existants. Contre-intuitif, mais il a vu des développeurs s'en satisfaire.
"Ils sont en mode, je reconnais le bouton, je reconnais le tableau, je reconnais le menu. C'est simplement suffisant pour moi."
Production code. Le code qui colle parfaitement au design system et aux composants en prod, avec les adaptations par plateforme.
Ses cas vécus. Chez Sofinco : idéation sur Replit, même proto conservé pour les tests utilisateurs, personnalisation de chaque session au nom et à l'entreprise de l'utilisateur, puis livraison du proto plus des spécifications Figma. Chez Station F, un sprint pour une boîte sans aucun legacy : Cursor de bout en bout, de l'idéation à la delivery. Chez Home Exchange : du code d'idéation pour travailler l'onboarding avec les équipes. Chez Deezer, il cite le travail de Victor sur Remix Lab, construit avec un design.md via Claude Code, les spécifications étant ensuite faites sur Figma.
6. La culture de boîte change tout
Une composante qu'il ajoute à sa liste : la culture. Toutes les cultures d'entreprise diffèrent, donc les design systems aussi.
"Systems attract system people."
Dans certaines boîtes, l'approche est très SaaS : on ne réinvente pas la roue, on systémise tout, on ne sort pas du cadre. Chez Deezer, le niveau de craft est élevé et les enjeux d'expérience et d'émotion sont différents. L'objectif n'est pas de tout systémiser. C'est d'accélérer la partie fastidieuse, les menus, les navigations, les fonctionnalités sans gros enjeu d'expérience, pour libérer du temps là où il y a une vraie expression de marque à construire.
Conséquence pratique : on ne met pas le poids du corps au même endroit. Avec des équipes moins seniors, on investit sur les process, les bonnes pratiques et les conventions de naming. Avec une équipe mature, on documente et on processe moins, parce qu'ils travaillent déjà bien.
7. Le code est la source of truth
Question posée pendant le live. Sa réponse est nette.
"De toute façon, ce que vit l'utilisateur final, c'est du code. Ce n'est pas des Figma."
Il décrit la sensation en side project sur Claude Code : aucune contrainte, aucun legacy, très satisfaisant. Puis le retour sur Figma, où on est frappé par le côté statique et lent.
Sur l'avenir de Figma, il voit Code Layers comme un vrai tournant, et Figma Make comme un futur environnement de code sur mesure pour construire avec le design system. Il a testé Paper et Pencil, et trouve le plugin snapshot de Paper intéressant pour retoucher visuellement un composant sur des détails de padding ou de radius, ce qui lui économise trois ou quatre prompts. Mais avec les agents Figma, il voit moins l'intérêt de ces outils.
Sa réserve sur la convergence : la place du craft reste importante pour innover. Faire de l'idéation sur du code de composants déjà existants limite la capacité d'expression.
8. Par où commencer quand tout a drifté
Sa recommandation face à un design system legacy avec beaucoup de drift : une approche produit.
Faire de la recherche quanti et quali pour voir où c'est bloquant. Commencer par le problème le plus important. Si le problème est l'interprétation divergente des composants, identifier les plus utilisés et adresser les problématiques par ordre de priorité. Si le problème est la lenteur de contribution, la question devient : qu'est-ce qu'on automatise, quel ownership on donne, qui décide quoi.
Une piste fréquente : découper le design system en périmètres. Des composants de coeur, puis des librairies propres à différents domaines, terme qu'il emprunte à Carrefour. Une télé et une application mobile ne se croisent pas beaucoup.
"Par quoi je commencerais ? Je commencerais par un audit."
Mapper les stakeholders, mapper l'écosystème du design system, identifier ce que couvre le système aujourd'hui. Les next steps apparaissent vite, parce qu'on voit de quoi les gens se plaignent. Là où ils se plaignent, il y a de la valeur ajoutée.
Sur le désalignement Figma et prod, sa méthode : d'abord déterminer qui est la source de vérité. Est-ce Figma la référence et le code qui a drifté, ou le code qui est à jour après des micro-ajustements et Figma qui n'a pas suivi. Ensuite mesurer le drift. Si le code fait foi, interroger le code via Copilot ou Claude Code pour récupérer les specs et properties, ou le faire en peering avec un développeur. Si c'est le code qui est désaligné, prioriser par matrice d'impact sur les composants les plus utilisés, puis trancher en gouvernance : un sprint dédié d'alignement, ou une intégration au fil des features.
Son critère de décision transversal :
"Il ne faut pas penser IA tout le temps, il faut surtout penser temps."
Son mot de la fin est un disclaimer assumé. Il n'a pas travaillé dans des structures à soixante-dix feature teams, où d'autres complexités arrivent. Et une reco : ouvrir Claude Code et lui parler directement. Ça apprend à parler code, à lire la code base, à construire.