+33-9-7266-3068
contact@gdm-pixel.fr
Le problème que personne ne voit venir
Un client nous a appelé il y a quelques mois. Il venait d’intégrer un outil IA dans son workflow de production web. Résultat ? L’IA généraitdu code. Beaucoup de code. Vite. Mais aucun des composants produits ne correspondait à son design system existant. Couleurs approximatives, espacements incohérents, typographies aléatoires. Il fallait tout reprendre à la main.
Combien d’heures perdues pour corriger ce que l’IA avait “créé” ?
Ce scénario, on le voit de plus en plus souvent. Les équipes adoptent des outils IA pour accélérer leur production — Copilot, Cursor, Claude Code, v0.dev — sans avoir préparé le terrain. Et leur design system, conçu à l’époque où un développeur lisait chaque ligne, devient un boulet.
Un design system non structuré pour l’IA, c’est un frein déguisé en accélérateur.
Voici comment éviter ça. Concrètement, avec des actions applicables aujourd’hui.
Pourquoi votre design system actuel ne suffit plus
La plupart des design systems ont été construits pour des humains. Un développeur ouvre Figma, lit la doc, comprend le contexte, fait des choix. Il interprète. Il s’adapte.
L’IA, elle, ne fait pas ça.
Un modèle de langage ou un outil de génération de code travaille à partir de tokens, de patterns, de structures. Il a besoin d’instructions explicites, non ambiguës, systématiques. Quand votre design system dit “utiliser les couleurs de la marque”, l’IA ne sait pas ce que ça signifie sans les valeurs hexadécimales précises, les contextes d’usage, les règles de combinaison.
Ce qu’on voit concrètement chez nos clients : des design systems riches visuellement dans Figma, mais quasiment inexploitables par une IA parce qu’ils sont documentés en langage naturel, sans structure machine-readable.
La documentation belle ne vaut rien si elle n’est pas lisible par une machine.
Trois problèmes récurrents :
- Les tokens de design (couleurs, espacements, typographies) existent dans Figma mais ne sont pas exportés dans un format structuré (JSON, CSS custom properties, design tokens W3C)
- Les règles de composition sont implicites — elles vivent dans la tête des designers, pas dans la doc
- Les composants n’ont pas de nommage cohérent entre Figma, le code et la documentation
Les quatre piliers d’un design system AI-ready
Pilier 1 : les tokens de design comme source unique de vérité
Si vous ne faites qu’une chose après avoir lu cet article, c’est celle-là.
Les design tokens, c’est la traduction de vos décisions visuelles en valeurs nommées et structurées. Pas #1A73E8, mais color.brand.primary. Pas 16px, mais spacing.md. Cette nomenclature sémantique permet à une IA de comprendre non seulement la valeur, mais l’intention derrière.
Le standard qui s’impose actuellement, c’est le format W3C Design Tokens. Il structure vos tokens en JSON avec des métadonnées : type, valeur, description, contexte d’usage. Des outils comme Style Dictionary ou Tokens Studio pour Figma permettent de synchroniser ces tokens entre votre fichier de design et votre codebase.
Résultat concret : quand vous donnez à Claude Code ou à Cursor l’accès à votre fichier de tokens, il génère du code qui respecte automatiquement votre charte. Plus de couleurs approximatives. Plus d’espacements inventés.
“Les tokens ne sont pas une contrainte technique supplémentaire. Ce sont la traduction de votre identité visuelle dans un langage que l’IA peut lire.” — Pratique quotidienne chez GDM-Pixel depuis 18 mois.
Pilier 2 : une nomenclature cohérente entre tous les outils
L’IA travaille par correspondance de patterns. Si votre composant s’appelle CardProduit dans Figma, product-card dans votre CSS et ProductTile dans votre React, vous avez trois entités distinctes pour l’IA. Elle ne fera pas le lien.
La règle est simple : un composant, un nom. Partout.
Choisissez une convention — BEM, camelCase, kebab-case — et appliquez-la systématiquement dans Figma, dans votre code, dans votre documentation. Cette cohérence permet aux outils IA de naviguer entre contextes sans perdre le fil.
Sur nos projets Astro + Tailwind, on utilise une nomenclature kebab-case partout. Quand Claude Code génère un composant, il retrouve immédiatement sa correspondance dans le design system. Gain de temps : réel, mesurable, immédiat.
Pilier 3 : documenter les règles, pas seulement les composants
Un design system classique montre quoi. Un design system AI-ready explique pourquoi et quand.
La différence ? Votre documentation doit inclure :
- Les règles d’usage (ce composant s’utilise uniquement pour les actions primaires)
- Les contraintes (ne jamais combiner ce fond avec ce texte pour des raisons d’accessibilité)
- Les variantes autorisées et interdites
- Les contextes d’application (mobile, desktop, dark mode)
Ces informations, structurées en Markdown ou en JSON, deviennent des instructions directement injectables dans un prompt IA. On travaille avec des fichiers de contexte que l’on passe à Claude Code en début de session. Résultat : le modèle connaît nos contraintes avant d’écrire la première ligne.
Pilier 4 : versionner et maintenir comme du code
Un design system qui n’est pas versionné est un design system qui dérive.
Avec l’IA dans la boucle, ce problème s’amplifie. Si vos tokens changent mais que votre IA travaille encore avec l’ancienne version, vous produisez des incohérences à vitesse industrielle. L’IA accélère tout — y compris les erreurs.
La solution : votre design system doit vivre dans un dépôt Git, avec des releases numérotées, un changelog clair, et une intégration dans votre pipeline CI/CD. Quand une couleur change dans votre charte, le changement se propage automatiquement — dans le code, dans la documentation, et dans les contextes que vous fournissez à vos outils IA.
Ce que ça change concrètement dans la production
Permettez-moi de vous donner un exemple terrain.
Sur le projet Nova Mind — notre propre SaaS — on a structuré notre design system avec des tokens W3C, une nomenclature unifiée Figma/Astro, et des fichiers de contexte Markdown par type de composant. Quand on ouvre une session Claude Code pour développer un nouvel écran, on injecte ces fichiers en contexte.
Le modèle génère des composants qui respectent notre palette, nos espacements, nos règles typographiques — sans qu’on ait à les rappeler à chaque prompt. On corrige la logique métier, pas le style. C’est le bon usage de l’IA : elle exécute les règles, vous concevez la stratégie.
Avant la structuration : 40 à 60% du temps de révision portait sur la cohérence visuelle. Après : moins de 10%.
Ce n’est pas une estimation. C’est mesuré sur nos derniers projets livrés.
“L’IA ne remplace pas votre design system. Elle en révèle les failles — celles que vous ne voyiez pas parce que vos développeurs les compensaient intuitivement.”
Par où commencer si vous partez de zéro (ou presque)
Vous avez un design system existant mais non structuré ? Voici un chemin réaliste, sans tout refaire d’un coup.
Étape 1 — Auditer vos tokens existants. Recensez toutes les valeurs de couleur, espacement et typographie utilisées dans votre codebase. Des outils comme Style Dictionary ou une simple recherche dans votre CSS vous donnent une vue d’ensemble en quelques heures.
Étape 2 — Nommer et structurer. Transformez vos valeurs brutes en tokens sémantiques. #2D3748 devient color.neutral.800. Exportez en JSON. Synchronisez avec Figma si vous l’utilisez.
Étape 3 — Écrire les règles d’usage en Markdown. Pour chaque composant principal, un fichier .md avec : description, cas d’usage, variantes autorisées, contraintes d’accessibilité. Simple, direct, machine-readable.
Étape 4 — Intégrer dans votre workflow IA. Créez un dossier /context dans votre projet avec vos tokens et vos règles. Référencez-les dans vos prompts ou configurez-les comme contexte persistant dans votre outil IA.
Étape 5 — Versionner. Git + changelog. Dès le premier jour.
Les erreurs à éviter absolument
On en a fait quelques-unes. Autant vous éviter la même douleur.
Vouloir tout structurer d’un coup. Un design system AI-ready se construit itérativement. Commencez par les tokens de couleur et d’espacement — c’est là que l’IA fait le plus d’erreurs. Le reste vient ensuite.
Négliger la documentation des exceptions. Votre IA va appliquer les règles générales à la lettre. Si vous avez des exceptions non documentées, elle ne les connaît pas. Documentez les cas particuliers aussi soigneusement que les cas standards.
Séparer la responsabilité design et développement. Un design system AI-ready est un projet commun. Si le designer fait évoluer les tokens dans Figma sans synchroniser avec le code, vous perdez la cohérence que vous avez mis du temps à construire. Processus commun, outil commun, responsabilité partagée.
La question que vous devriez vous poser maintenant
Votre design system actuel — si vous en avez un — est-il documenté de façon à ce qu’une IA puisse le lire et l’appliquer sans interprétation ?
Si la réponse est non, ou si vous n’êtes pas sûr, c’est le bon moment pour agir. Pas parce que l’IA est une mode. Parce que les outils IA sont déjà dans les workflows de production web, et que leur efficacité dépend directement de la qualité de la structure qu’on leur fournit.
Un design system non structuré avec l’IA dans la boucle, c’est du travail en double. Un design system AI-ready, c’est un multiplicateur de productivité réel.
Chez GDM-Pixel, on a passé du temps à structurer nos propres systèmes avant de les intégrer dans nos workflows IA. Ce temps d’investissement, on l’a récupéré dès le deuxième projet. Et on continue de le récupérer à chaque livraison.
Vous voulez structurer votre design system pour l’IA, ou auditer votre workflow de production web actuel ? Contactez-nous — on vous donne un diagnostic honnête, sans vente de refonte inutile.
Réseaux sociaux
Analyser avec l'IA
