KaptiMethod
Design system et IA : garder Figma et le code alignés quand l’IA génère des écrans
By Romain Peltier and João Da Silva Marly · · 6 min read
Les outils d’IA savent désormais produire un écran ou un composant en quelques secondes. Sans règles communes, ils produisent aussi très vite des boutons différents sur chaque page. Le design system n’a jamais été aussi utile : c’est lui qui donne à l’IA les bonnes briques.
Les assistants de code et les fonctions IA des outils de design accélèrent beaucoup le passage de l’idée à l’écran. Chez Kapti, on les utilise au quotidien (on en parle dans notre article sur nos outils). Mais leur résultat dépend de ce qu’on leur donne : un design system clair produit des écrans cohérents, un fichier désordonné produit des variantes à l’infini.
1. Des tokens comme source unique
Les tokens sont les décisions de base du design : couleurs, typographie, espacements, rayons, ombres, avec des noms qui disent leur rôle (« texte secondaire », « surface », « danger ») plutôt que leur valeur. Ils vivent dans Figma sous forme de variables et sont exportés vers le code.
- Pourquoi c’est clé avec l’IA : un outil qui génère du code avec vos tokens reste dans votre identité. Sans eux, il invente des couleurs approchantes.
- Ce qu’on met en place : variables et modes Figma (clair, sombre, marques), export automatisé vers le code, une seule source de vérité.
2. Des composants nommés pareil dans Figma et dans le code
Un bouton qui s’appelle « Button / Primary » dans Figma et Button variant="primary" dans le code, avec les mêmes propriétés : c’est ce qui permet à un développeur, ou à un outil d’IA, de passer de la maquette au code sans réinterpréter.
- mêmes noms et mêmes variantes des deux côtés ;
- états prévus dès le départ (survol, focus, désactivé, erreur, chargement) ;
- accessibilité intégrée au composant : contrastes, focus visible, libellés.
3. Une documentation lisible par les humains et par les machines
La documentation explique quand utiliser un composant, et quand ne pas l’utiliser. Rédigée clairement, avec des exemples, elle sert aux nouvelles recrues comme aux assistants IA, qui s’appuient de plus en plus sur ces règles pour proposer du code conforme.
- une page par composant : usage, variantes, à faire et à éviter ;
- des exemples de code prêts à copier ;
- un journal des changements, pour que tout le monde suive les évolutions.
4. Une gouvernance légère mais réelle
Un design system vit : de nouveaux besoins arrivent chaque mois. Sans règle de contribution, on retrouve vite des copies locales. Il suffit souvent d’une personne référente, d’un rituel court toutes les deux semaines et d’une règle simple : un nouveau composant passe par le design system avant d’aller en production.
Par où commencer
- Faire l’inventaire de l’existant : combien de boutons, de gris, de tailles de texte différents ?
- Poser les tokens, puis les dix composants les plus utilisés.
- Brancher l’export vers le code et tester sur un vrai écran.
- Seulement ensuite, élargir.
Votre design system a besoin d’un coup de neuf ? The free mini-audit dure 30 minutes : on regarde votre fichier Figma et vos composants, et vous recevez cinq recommandations écrites sous 48 heures.
Frequently asked questions
À quoi servent les tokens dans un design system ?
Les tokens nomment les décisions de base (couleurs, typographie, espacements) selon leur rôle. Partagés entre Figma et le code, ils garantissent que tous les écrans, y compris ceux générés par des outils d’IA, restent cohérents.
L’IA remplace-t-elle le design system ?
Non, elle le rend plus utile : un outil d’IA qui s’appuie sur vos tokens et vos composants produit des écrans cohérents, alors que sans règles communes il multiplie les variantes.
Combien de temps pour poser un design system ?
Chez Kapti, le Design system express dure six semaines : inventaire, tokens, composants Figma et code, documentation et gouvernance.