6 questions pour décider s'il vous faut encore un design system à l’ère de l’IA

En résumé
Les outils d’IA générative donnent aujourd’hui l’impression que les design systems sont devenus obsolètes. Chez USERADGENTS, nous pensons l’inverse. Un modèle d’IA ne comprend pas un design, il applique ce qu’on lui donne à lire, incohérences comprises, et c’est justement le design system qui va donner le cadre pour devenir la source unique de vérité permettant aux agents d’appliquer au lieu de deviner. À condition d’être bien structuré, avec des tokens et composants clairement nommés et décrits, et des gardiens du temple pour assurer la connexion avec le code.

“Un DESIGN.md, un bon prompt, et l'IA vous sort un écran en trois minutes alors à quoi bon entretenir un design system lourd, coûteux et souvent boudé par une grande partie des équipes ?” C’est ce qu’on entend partout depuis des mois. Mais est-ce seulement vrai ? 

Soyons honnêtes, le design system n'a jamais été le chouchou de la classe. Vendu initialement comme l'outil de cohérence ultime, il peine surtout, dans les faits, à se faire adopter. Le Design Systems Report 2026 de zeroheight le confirme : pour la cinquième année consécutive, l'adoption reste le principal frein pour ceux qui gèrent un design system. Seuls 7% des responsables de design system le disent adopté par “toutes les équipes”, 31% par “la plupart”. Pour 38%, il n'est utilisé que par “une partie” et pour 22% “par quelques-unes” seulement. Paradoxe cruel, toujours selon zeroheight, 42% des équipes jugent la confiance dans leur design system “forte” et 49% “modérée”. Autrement dit, on y croit, mais on ne s'en sert pas assez. Le problème n'est donc pas la confiance mais l'usage. Côté moyens, ce n'est guère mieux. 6 équipes dédiées au design system sur 10 se disent en sous-effectif. 

Et voilà que l'IA arrive avec ses promesses ! Un fichier texte suffit à orienter un modèle. Un outil d’IA génère un design system en quelques minutes. On design directement depuis le code. Alors oui, la tentation de tout jeter et de repartir d'une page blanche bien promptée est grande. Chez USERADGENTS, notre conviction est pourtant inverse. Le design system n'a jamais été aussi utile. Car en réalité l'IA ne crée rien. Elle ne fait que rendre visible ce qui existe. Elle consomme exactement ce qu'on lui sert… incohérences comprises. Les composants oubliés, les noms flous, les couleurs en doublon, elle les reproduit sans broncher, à grande échelle. Il faut dire qu’un modèle d’IA ne comprend pas votre design comme le ferait un humain. Il prédit la réponse la plus probable à partir de ce qu’on lui donne à lire : des noms, des descriptions, des liens entre éléments. Il s’appuie sur la sémantique de votre design system, c’est-à-dire le sens porté par chacun de ces noms. Un token baptisé « bleu-500 » lui dit quelle couleur appliquer, pas à quoi elle sert. Et là où le sens manque, il comble les trous avec ce qui lui paraît le plus plausible. 

Donner les clés de vos interfaces à la machine peut donc être pertinent à bien des égards mais l'importance du cadre n'a jamais été aussi grande pour connecter réellement le design au code. Voici pourquoi, à travers les 6 questions principales que se posent les équipes produit aujourd'hui.

Question 1 : Qu’est-ce qu’un design system prêt pour l’IA (AI-ready ou AI-safe) ?

Un design system prêt pour l’IA est un design system dont les composants, les tokens et les règles d’usage sont nommés, décrits et reliés de façon explicite. Un humain comme un agent IA peut alors les appliquer sans deviner.

Pour s’assurer de la lisibilité du design system, la première étape, c’est de l’auditer : faire un état des lieux complet de l’existant pour vérifier qu’il est lisible et utilisable par les équipes et par l’IA. Sans ce cadre, cette dernière devine au lieu de répondre et construit des interfaces imprécises. L’idéal pour auditer est d’utiliser une skill Claude ou Figma Agent co-construite entre designers et développeurs.

À partir de cet audit, il faut prévoir un plan d’action voire une roadmap très précise. Nos designers ont identifié 7 priorités majeures à y insérer : 

• Faire le ménage : supprimer les calques cachés et inutiles, éviter de laisser des noms sans pertinence…
• Tout relier à des variables : couleurs, tailles, espacements et arrondis passent par des tokens, sans valeur en dur.
• Donner une intention aux tokens : un nom qui dit à quoi sert la couleur plutôt que quelle couleur c'est.
• Décrire chaque composant : une description courte qui dit quand l'utiliser et quand l'éviter.
• Fixer des conventions de nommage côté design, à faire appliquer par les développeurs : ils peuvent faire des recommandations selon leur technologie, mais une seule règle de nommage fait foi. Ces conventions peuvent aussi émerger dans le cadre d’un atelier commun.
• Vérifier l'accessibilité : contrastes, états de focus, règles RGAA.
• Stipuler clairement ce qui manque : ce qui est stable, ce qui est en chantier, ce qui est déconseillé ou absent.

Parfois, ce plan d’action permet de faire remonter des bugs ou des erreurs jusqu’ici jamais vus. C’est ce que nous avons pu expérimenter au cours des audits que nous avons menés cette année chez USERADGENTS. Nous avons vu émerger par exemple : un texte blanc posé sur un fond blanc, des couleurs trop peu contrastées pour être lisibles, des composants sans état de focus... En cela, le travail de structuration à mener pour les agents devient un bonus qui profite directement aux humains.

Reste à ne pas négliger la question de la méthode. Où opère-t-on cet audit et ces optimisations ? Directement en production ? Dans une copie qui ne gêne ni les designers ni les développeurs qui utilisent le design system ? La réponse à cette question s’anticipe avant d’entreprendre une quelconque mise en conformité du design system et dépend de nombreux critères : adoption du design system, taille de l’équipe qui travaille dessus, fréquence de mises à jour… 

💡 Méthode d’intégration : la recommandation de nos designers

Opter pour une vérification “parallèle” en utilisant les branches de Figma, une par type de correction à opérer. Les branches permettent d’appliquer les corrections via un script ou à la main et de vérifier toutes les corrections et les conflits potentiels avant de merger avec le Figma principal. Attention, il est nécessaire de bien garder l'historique des versions du design system pour avoir une trace de chaque merge et revenir en arrière si besoin. 

Question 2 : Un fichier DESIGN.md peut-il remplacer un design system ? 

Non. Le DESIGN.md ne peut pas remplacer un design system, il n’en est même pas un vrai concurrent car le DESIGN.md n’est qu’une traduction du design system pour l’IA et comme toute traduction, il lui faut un original. 

Le DESIGN.md est un simple fichier texte qui explique votre design à une IA pour qu’elle puisse faire son travail de génération. On y décrit les couleurs, les typos, les composants et leurs règles d'usage. Il est utile dans la logique d’interprétation sémantique des LLM, on ne le conteste pas, mais il n’a absolument pas le même rôle. Qui plus est, il vieillit vite. D’autant plus s’il a été produit manuellement. Il peut décrocher du design réel dès la première mise à jour. Un nouveau bouton, une couleur modifiée et le fichier ne dit plus la vérité. L'IA, elle, continue d'appliquer cette version périmée. Sans le savoir, sans vous prévenir. Même à jour d’ailleurs, un DESIGN.md reste une consigne et pas une règle. Il rapproche l'IA du résultat voulu, sans que ce résultat ne soit ni précis ni constant : il suffit que le modèle d'IA change pour que le rendu change avec lui.

Dans la majorité des cas, le DESIGN.md a donc besoin d'une source fiable, à savoir : un design system à jour. C'est lui qui fait foi. Le DESIGN.md en est tiré et le contexte servi aux agents se resynchronise automatiquement à chaque changement. 

Attention toutefois, pour de tout petits produits, avec une seule marque, un DESIGN.md peut parfois suffire. À condition d’être bien tenu, bien mis à jour. En revanche, dès que les marques, les services ou les équipes se multiplient, il est impératif d’avoir un vrai design system derrière.

Question 3 : Où doit vivre un design system ?

Un design system vit un peu partout à la fois mais une seule version doit faire foi, peu importe l’outil.

Pour nous, le débat sur l’outil est secondaire car il aura sans doute encore changé dans trois mois. La vraie question, c’est celle de la centralisation. Aujourd’hui, un design system existe en plusieurs exemplaires : dans l’outil de design, dans le code sous forme de tokens et de composants, dans la documentation et désormais dans les fichiers destinés à l’IA. Avoir plusieurs copies n’est pas un problème en soi. Le problème, c’est de ne plus savoir laquelle dit vrai.

D’où une règle simple : avoir une source unique de vérité et en faire découler tout le reste. Pour l’un de nos clients aux forts enjeux d’industrialisation, c’est Figma qui joue ce rôle, et tous les fichiers destinés à l’IA y sont liés. Pour d’autres, cela commence à être directement le code. Le bon choix dépend surtout de qui fait évoluer le design au quotidien.

Question 4 : Design to code, l’IA réconcilie-t-elle enfin design et code ?

Pas totalement. Les outils d’IA ont certes rapproché le design et le code mais ils ne garantissent pas qu’ils restent d’accord sur le long terme.

Sur le papier, designers et développeurs n'ont jamais travaillé aussi près les uns des autres. Avec Code Connect, Figma affiche l'écran et son code côte à côte. Sur Paper, on design directement en HTML ou en CSS. En vibe coding, chez les Lovable et consorts, on produit le design, le front, tout en même temps en décrivant ce qu’on veut à une IA. 

En production, pourtant, ils s'éloignent. Le design évolue d'un côté, le code de l'autre. Les experts interrogés par zeroheight le disent clairement : garder les deux alignés est leur plus gros problème. Et le fait de tisser de vrais liens entre design et code reste rare. Dans l'étude State of AI in Design Systems menée par Kaelig Deloumeau-Prigent, seuls 3 design systems publics sur 21 relient vraiment leurs composants design à leur code en production via Code Connect.

Ces liens restent dans la majorité des cas déclaratifs. Si un designer supprime une variante d'un bouton dans Figma, elle ne disparaît pas du code, et personne n'est prévenu. Et confier ce lien à une IA ne règle rien. Nous l'avons constaté sur une application iOS où un agent IA avait la charge de créer automatiquement la liaison entre les composants Figma et le code. Le résultat avait l'air propre. Mais en le relisant, nous avons découvert que l'agent faisait appel à des fonctions et à des types de données qui n'existaient nulle part dans le code de l'application. Encore une fois, l'IA avait inventé ce qui lui manquait.

Impossible donc de déléguer à l'aveugle ce travail de liaison entre design et code. Il faut vérifier, comparer, toujours. Cela passe par la désignation de vrais "gardiens du temple" humains (idéalement un binôme designer-développeur), garants de la conformité entre le design system et l'interface codée. Ce sont eux qui devront arbitrer en cas d'écart, signaler les incohérences et les erreurs, et décider lequel des deux doit être corrigé.

Question 5 : Désormais, tout le monde peut créer ses propres interfaces ? 

Oui, l’IA permet à beaucoup plus de profils de construire de A à Z des interfaces. Mais cette autonomie ne marche que si chacun construit dans le même cadre : le design system. 

Ce qui change d'abord, ce sont les rôles. Avec l'IA, des designers poussent du code, des chefs de projet prototypent. On parle désormais de "product builders" : des profils hybrides qui, grâce à l'IA, conçoivent et construisent eux-mêmes une fonctionnalité, de l'idée jusqu'au déploiement, sans passer à chaque étape par un designer puis un développeur. La barrière technique s’abaisse pour tout le monde mais engendre un énorme risque : que chacun construise avec ses propres règles. Un bouton par-ci, une couleur par-là. Les interfaces partent alors dans tous les sens, à la vitesse de la machine.

Pour l'éviter, il faut un cadre commun. Le design system définit ce que chacun (humain et agent) a le droit d'utiliser. Il devient la matière première partagée par toute l'équipe. Mais ce cadre ne peut plus être un simple document qu'on consulte quand on y pense. Il doit s'imposer, sans détour, et rester, à nouveau, la seule et unique source de vérité pour tous. C’est ce que nous prototypons pour des clients qui veulent tester la GenUI. L'IA ne peut générer des interfaces qu'avec les composants autorisés du design system. Tout ce qui sort du cadre est automatiquement rejeté.

Plus d'autonomie ne veut pas dire moins d'experts pour autant. Le binôme de gardiens du temple évoqué plus haut prend d'ailleurs encore plus son sens ici.

Question 6 : Comment faire vivre son design system dans la durée ?

En automatisant ce qui se répète (synchronisation des tokens, documentation, contrôle qualité) et en gardant des humains pour arbitrer. 

Avant, maintenir un design system était, disons-le, fastidieux : il fallait faire la même mise à jour à plusieurs endroits, manuellement. Prenons un exemple. La couleur du bouton a été changée (et validée officiellement) dans une maquette. Il faut changer cette couleur dans le design system, dans le code, dans la documentation. Trois fois la même modification, souvent faite par des personnes différentes, avec à chaque fois un risque d'oubli. zeroheight affirme que 60% des équipes synchronisent encore leurs tokens (couleurs, tailles, espacements) à la main entre le design et le code.

Aujourd'hui, trois types de tâches peuvent s'automatiser selon nos designers : 

• La synchronisation des tokens : on modifie une couleur dans Figma, le code suit automatiquement.
• La documentation : l'IA rédige les descriptions des composants et met à jour les fichiers destinés aux agents. 
• Le contrôle qualité : on peut auditer automatiquement le design system à intervalles réguliers, et plus seulement une fois par an.

Attention, l'automatisation du design system est un projet à part entière, qui demande du temps et des ressources pour être mis en place. Mais le jeu en vaut la chandelle : moins de temps à répéter la même mise à jour, c'est plus de temps pour faire évoluer le design system et l'expérience.

En conclusion : le design system, en 2027, on garde ou on jette ?

On garde. Sans hésiter. Mais pas pour les mêmes raisons qu'avant. Hier, le design system servait aux designers et aux développeurs. Aujourd'hui, il sert aussi de bible pour l'IA. C'est lui qui alimente le DESIGN.md. C'est lui qui dit à l'IA quoi utiliser et quoi éviter. C'est lui qui fixe le cadre dans lequel tous les nouveaux profils hybrides peuvent construire. Et cerise sur le gâteau : grâce à l'automatisation, il devient enfin moins pénible à entretenir ! 

Une chose en revanche ne change pas : il faut toujours des humains pour le faire vivre. Pour vérifier que le design et le code restent d'accord et pour décider de ce que le design system doit devenir. Sans système de gouvernance clair, l’adoption restera difficile à atteindre. 

Quelques questionnements restent toutefois ouverts chez les équipes de USERADGENTS. Jusqu'où cadrer l'IA ? Un design system trop strict ne laisse-t-il pas trop peu de place à la nouveauté, au risque que tous les écrans finissent par se ressembler ? Combien investir ? Toutes les marques n'ont en effet pas besoin du même niveau d'exigence, et un petit produit n'a pas les enjeux d'un grand groupe multimarque. Et demain, qui sait ? Peut-être que le design vivra totalement différemment, qu'on n'aura plus besoin du design system sous sa forme actuelle. Rien n'est exclu, mais nous pensons fermement que le design system d'aujourd'hui prépare justement celui du monde d'après.

Vous voulez vérifier que votre design system actuel passe le contrôle technique ? 🔧 Contactez nos experts !

---

À retenir

• L’IA ne crée pas la cohérence. Elle reproduit celle de votre design system, avec ses incohérences aussi, à grande échelle.
• Un design system prêt pour l’IA commence par un audit. Viennent ensuite sept chantiers : ménage, variables, tokens à intention, descriptions de composants, conventions de nommage, accessibilité et statut de chaque élément.
• Le DESIGN.md est une traduction du design system pour l’IA, pas un remplaçant. Il doit en être tiré et se mettre à jour automatiquement.
• Un design system existe en plusieurs lieux, mais une seule version doit faire foi. Le bon choix dépend de qui fait évoluer le design au quotidien.
• Les liens entre design et code restent déclaratifs. Un binôme designer-développeur doit les vérifier et arbitrer les écarts.
• Plus il y a de product builders, plus un cadre commun et imposé devient indispensable.
• La synchronisation des tokens, la documentation et le contrôle qualité peuvent s’automatiser, mais l’automatisation est un projet à part entière.

Questions fréquentes sur le design system

Qu’est-ce qu’un design system ?
Un design system est la bibliothèque de référence d’un produit digital. Il réunit les couleurs, typographies, espacements, composants et règles d’usage partagés par les designers et les développeurs. Il garantit la cohérence d’une marque sur tous ses écrans.

Pourquoi un design system est-il utile à l’IA générative ?
Un modèle d’IA ne comprend pas un design, il prédit la réponse la plus probable à partir de ce qu’on lui fournit. Sans design system structuré, il comble les manques avec ce qui lui semble plausible. Le design system lui donne un cadre précis à appliquer.

Qu’est-ce qu’un token sémantique ?
Un token est une valeur nommée (une couleur, une taille, un espacement) utilisée à la place d’une valeur en dur. Un token sémantique porte une intention dans son nom : « couleur-action-principale » dit à quoi sert la couleur, là où « bleu-500 » dit seulement laquelle appliquer. C’est ce sens qui guide l’IA.

Qu’est-ce qu’un fichier DESIGN.md ?
Un DESIGN.md est un fichier texte qui décrit un design à une IA : couleurs, typos, composants et règles d’usage. Il oriente la génération mais ne la garantit pas, et il vieillit vite s’il est tenu à la main. Il doit donc être tiré d’un design system à jour.

Faut-il garder son design system dans Figma ou dans le code ?
Les deux peuvent fonctionner. Ce qui compte, c’est de désigner une seule source de vérité et d’en faire découler toutes les autres versions. 

Comment savoir si son design system est prêt pour l’IA ?
En l’auditant. Un audit vérifie le nommage, le lien de chaque valeur à une variable, la présence de descriptions sur les composants et l’accessibilité. Il fait souvent remonter des erreurs invisibles jusque-là, comme des contrastes insuffisants ou des états de focus manquants.

Qu’est-ce que Code Connect dans Figma ?
Code Connect est une fonction de Figma qui associe un composant de maquette à son composant réel dans le code. Le développeur voit ainsi le vrai code à utiliser à côté du design. Ce lien reste déclaratif : une modification dans Figma ne se répercute pas seule dans le code.

Qu’est-ce qu’un product builder ?
Un product builder est un profil hybride qui conçoit et construit lui-même une fonctionnalité grâce à l’IA, de l’idée jusqu’au déploiement. Designers, chefs de projet ou product managers peuvent jouer ce rôle. Il suppose un cadre commun, le design system, pour éviter que chacun applique ses propres règles.

Un petit produit a-t-il besoin d’un design system ?
Pas forcément. Pour un petit produit avec une seule marque, un DESIGN.md bien tenu peut suffire. Dès que les marques, les services ou les équipes se multiplient, un vrai design system devient indispensable.