DESIGN.md : le format open source de Google Stitch pour guider l’IA
Quand une IA génère une interface, le vrai problème n’est pas toujours sa capacité à produire du code ou une maquette. Le problème, c’est la cohérence. Sans contexte durable, un agent peut créer une belle interface sur un écran puis dériver sur le suivant. C’est précisément le sujet que Google Stitch cherche à adresser avec DESIGN.md, un format de design system en texte brut, pensé pour être compris à la fois par les humains et par les agents IA. Selon la documentation Stitch, DESIGN.md est un document de design system que les agents IA lisent pour générer une UI cohérente à l’échelle d’un projet.
En avril 2026, Google Labs a annoncé l’ouverture de la spécification brouillon de DESIGN.md afin que le format puisse être utilisé au-delà de Stitch, sur d’autres outils et plateformes. Google présente ce format comme un moyen d’éviter que les agents “devinent” l’intention visuelle, en leur donnant une compréhension explicite des règles de design et en permettant notamment des vérifications liées à l’accessibilité WCAG.
Qu’est-ce que DESIGN.md ?
DESIGN.md est une représentation autonome, en texte brut, d’un design system. La spécification GitHub officielle le décrit comme un format lisible par les humains, ouvert, et destiné à capturer l’identité visuelle d’une marque ou d’un produit afin que ces choix puissent être suivis à travers différentes sessions de design, outils et agents IA.
Autrement dit, DESIGN.md joue le rôle de source de vérité textuelle pour le design. Là où une bibliothèque de composants, un fichier Figma ou un dossier de guidelines peuvent rester fragmentés, DESIGN.md rassemble dans un même fichier les tokens, les règles de style et l’intention visuelle générale. C’est cette combinaison qui le rend intéressant pour les workflows pilotés par l’IA. Cette lecture est cohérente avec la doc officielle Stitch et avec la spécification open source publiée par Google Labs.
Pourquoi Google Stitch a lancé ce format
Google présente Stitch comme un canvas de design natif IA capable de transformer du langage naturel en interfaces haute fidélité. Dans cette logique, DESIGN.md sert à donner un contexte persistant au moteur de génération : au lieu de repartir de zéro à chaque prompt, l’outil peut réutiliser des règles de design exportées ou importées entre projets. Google explique aussi que Stitch peut extraire un design system depuis une URL et utiliser DESIGN.md pour transporter ces règles vers d’autres projets ou outils.
Le point important est donc le suivant : DESIGN.md n’est pas seulement un document descriptif. Il s’inscrit dans une logique de continuité entre idéation, design system, prototypage et production. Pour une équipe produit ou web, cela peut réduire la perte d’information entre la vision de marque, la conception d’interface et l’exécution par des agents.
Comment fonctionne DESIGN.md
Une structure en deux couches
La structure du format repose sur deux parties. D’abord, un front matter YAML optionnel, qui contient les design tokens lisibles par machine. Ensuite, un corps en Markdown, qui contient le rationnel humain : pourquoi telle couleur existe, comment utiliser telle typographie, quels comportements éviter, etc. La spécification précise que les tokens sont les valeurs normatives, tandis que la prose fournit le contexte d’application.
C’est probablement l’une des idées les plus intelligentes du format. Un JSON de tokens est utile pour un pipeline technique, mais il ne dit pas toujours clairement l’intention. À l’inverse, une documentation purement narrative est agréable à lire mais souvent trop floue pour un agent. DESIGN.md cherche à réunir les deux dans un seul fichier. Cette conclusion découle directement de la structure officielle du format.
Les tokens supportés
Le schéma documenté prévoit notamment des blocs pour colors, typography, rounded, spacing et components. Les couleurs sont définies en hexadécimal, la typographie peut inclure la famille, la taille, le poids, l’interlignage ou l’approche, et les composants peuvent référencer d’autres tokens via une syntaxe de type {colors.primary}.
La spécification autorise aussi des références entre tokens et prévoit des conversions vers d’autres formats. Le dépôt officiel indique que DESIGN.md est inspiré du format W3C Design Tokens et que son CLI peut exporter les tokens vers une configuration Tailwind ou vers un tokens.json au format DTCG.
Les sections recommandées dans le Markdown
Le corps Markdown suit un ordre conseillé : Overview, Colors, Typography, Layout, Elevation & Depth, Shapes, Components puis Do’s and Don’ts. La spécification indique que certaines sections peuvent être omises si elles ne sont pas pertinentes, mais que celles présentes doivent respecter cet ordre.
Ce choix est intéressant pour le SEO sémantique comme pour le GEO : le document devient facile à lire, facile à parser, et surtout facile à résumer. Un moteur génératif ou un agent obtient une hiérarchie claire entre la vision globale, les fondations visuelles, puis les règles de composants. C’est une inférence de structure, mais elle repose sur l’organisation officielle du format.
Ce que DESIGN.md change pour les équipes design, produit et développement
Pour une équipe produit, DESIGN.md peut jouer le rôle de brief permanent. Au lieu d’expliquer à chaque nouvel agent ou nouvel outil les mêmes consignes sur la palette, les espacements, les boutons ou le ton visuel, ces informations vivent dans un fichier versionnable. La promesse officielle de Google est précisément de permettre à Stitch et à d’autres outils de réutiliser ces règles sans “réinventer la roue” à chaque nouveau projet.
Pour les développeurs, le bénéfice se situe dans la traduction entre intention design et implémentation. Comme le format peut être validé, comparé et exporté, il devient plus proche d’un artefact de production qu’une simple note créative. Le CLI officiel permet par exemple de lint un fichier DESIGN.md, de comparer deux versions avec diff, et d’exporter les tokens vers d’autres formats utilisables dans le développement.
Pour les designers, l’intérêt n’est pas de remplacer Figma ou les outils visuels, mais de compléter le dispositif. La spécification officielle précise que les tokens sont convertibles depuis ou vers tokens.json, les variables Figma et les configurations Tailwind. En pratique, cela positionne DESIGN.md comme une couche de traduction et de gouvernance plutôt que comme un remplaçant frontal d’un outil de design visuel.
Les usages concrets de DESIGN.md
Uniformiser la génération d’interfaces par IA
Le premier usage est évident : permettre à un agent IA de produire des écrans, composants ou flows avec une cohérence plus stable. La doc Stitch résume DESIGN.md comme un document de design system lu par les agents pour générer une UI cohérente sur l’ensemble du projet.
Réutiliser un design system d’un projet à l’autre
Google Labs explique que DESIGN.md permet d’exporter ou d’importer des règles de design d’un projet à un autre. Pour une agence ou une équipe multi-produits, c’est une logique intéressante : au lieu de repartir d’une base vide, on transporte un socle visuel déjà cadré.
Vérifier la qualité et l’accessibilité
Le dépôt officiel met en avant une commande lint capable de détecter des références cassées, de vérifier le contraste et de remonter des findings structurés. Google mentionne aussi explicitement la validation possible par rapport aux règles WCAG.
Aligner design, documentation et code
Comme DESIGN.md est un fichier texte versionnable, il s’intègre naturellement dans un dépôt Git. Cela facilite la revue, la comparaison de versions, et potentiellement la synchronisation avec une base de composants ou un système de tokens. Cette utilité découle directement des capacités diff, lint et export du CLI officiel.
DESIGN.md face aux design tokens JSON et à Figma
DESIGN.md ne remplace pas les tokens techniques ni les outils de maquettage. Son intérêt est ailleurs : il ajoute une couche agent-friendly et narrative au-dessus des valeurs. La spécification souligne d’un côté la présence de tokens structurés, et de l’autre la prose qui explique comment appliquer ces choix de design.
Face à un simple tokens.json, DESIGN.md apporte du contexte. Face à Figma, il apporte un format texte facilement versionnable, portable et lisible par des agents. Comme le format officiel prévoit des passerelles vers les variables Figma, les tokens DTCG et Tailwind, la bonne lecture n’est pas “ou bien / ou bien”, mais plutôt “pont entre plusieurs couches du système design”.
Les limites à connaître avant de l’adopter
Le premier point de vigilance est simple : le projet est encore en version alpha. Le dépôt officiel précise que la spécification, le schéma de tokens et le CLI sont encore en développement actif, et que des changements sont à prévoir à mesure que le format mûrit.
Le second point concerne les composants. La spécification indique clairement que cette partie est encore en évolution et qu’elle laisse volontairement de la flexibilité pour des définitions propres à chaque domaine. C’est utile, mais cela signifie aussi qu’il faudra probablement accepter une certaine instabilité au début.
Enfin, DESIGN.md ne résout pas à lui seul tous les problèmes d’un design system. Il peut formaliser les règles, mais il ne remplace ni une vraie gouvernance produit, ni une bonne bibliothèque de composants, ni une validation humaine des interfaces générées. Cette conclusion est une inférence raisonnable à partir de la portée du format telle que décrite par Google.
Bonnes pratiques pour créer un DESIGN.md utile
Rester sémantique, pas seulement descriptif
Ne te contente pas d’écrire “bleu principal” ou “titre grand”. Le format fonctionne mieux quand les tokens et la prose expriment des rôles : action principale, surface, ton éditorial, niveau de hiérarchie, densité visuelle. C’est cohérent avec la logique de la spécification, qui recommande des noms de tokens sémantiques comme primary, secondary, headline ou body.
Documenter les règles d’usage, pas seulement les valeurs
La section Do’s and Don’ts n’est pas anecdotique. Elle sert de garde-fou pour éviter les dérives visuelles. La spec donne des exemples très concrets : ne pas mélanger coins arrondis et angles vifs sur un même écran, maintenir un contraste WCAG AA, ou limiter le nombre de graisses typographiques.
Intégrer le fichier dans le cycle de versioning
Comme DESIGN.md peut être linté, comparé et exporté, il gagne à être traité comme un artefact de projet à part entière. Dans une équipe mature, il peut vivre dans le dépôt, passer en revue, et évoluer en parallèle du design system et du front-end. Cette recommandation découle directement des outils officiels fournis autour du format.
Faut-il publier un article sur DESIGN.md maintenant ?
Oui, parce que le sujet coche plusieurs cases fortes pour un blog tech orienté web, produit et IA. D’abord, il relie trois univers très recherchés : Google Stitch, design system et agents IA. Ensuite, il ne s’agit pas seulement d’un outil, mais d’un format potentiellement réutilisable, donc plus durable éditorialement. Enfin, le fait que Google Labs ait ouvert la spécification lui donne une portée plus large qu’une simple fonctionnalité interne.
Pour blacksheepcode.be, le bon angle n’est pas seulement “voici une nouveauté Google”, mais plutôt : comment structurer un design system pour qu’une IA produise des interfaces plus cohérentes ? C’est ce qui donne au sujet une vraie profondeur SEO et GEO. Cette dernière phrase relève d’un choix éditorial, mais elle s’appuie sur la nature du format et sur le positionnement officiel de Stitch.
FAQ
DESIGN.md est-il réservé à Google Stitch ?
Non. Google Labs a annoncé l’ouverture de la spécification brouillon pour permettre un usage au-delà de Stitch, sur d’autres outils et plateformes.
Un fichier DESIGN.md contient-il seulement des tokens ?
Non. Le format combine des tokens YAML lisibles par machine et une partie Markdown lisible par humain qui documente le rationnel et les règles d’usage.
Peut-on valider un DESIGN.md automatiquement ?
Oui. Le CLI officiel permet notamment de lint un fichier, de détecter des références cassées, de vérifier des contrastes et de produire des résultats structurés.
DESIGN.md remplace-t-il Figma ?
Pas vraiment. En pratique, il complète plutôt Figma et les formats de design tokens en servant de couche texte, versionnable et lisible par des agents. Cette lecture s’appuie sur les conversions prévues par la spécification officielle.
Conclusion
DESIGN.md mérite l’attention, non pas parce qu’il “révolutionne” à lui seul le design system, mais parce qu’il formalise quelque chose qui manquait jusqu’ici : une manière simple, portable et intelligible de transmettre une intention visuelle à des agents IA. Entre tokens exploitables, documentation humaine et ouverture du format, Google Stitch pose ici une brique intéressante pour le futur du design-to-code et du design-to-agent.
Pour une agence, une équipe produit ou un studio qui travaille déjà avec l’IA, DESIGN.md peut devenir un levier concret pour réduire les incohérences, documenter les règles de marque et fluidifier le passage du design vers l’implémentation. Le format est encore jeune, mais il est suffisamment structuré pour être pris au sérieux dès maintenant.
Sources
- Google Stitch Docs — What is DESIGN.md? : définition de DESIGN.md comme document de design system lu par les agents IA pour générer une UI cohérente.
- Google Blog / Google Labs — Stitch’s DESIGN.md format is now open-source so you can use it across platforms : annonce de l’open source, logique multi-outils, validation WCAG et export/import des règles de design.
- Google Blog / Google Labs — Introducing “vibe design” with Stitch : positionnement de Stitch comme canvas de design natif IA et rôle de DESIGN.md dans le toolkit design system.
- GitHub — google-labs-code/design.md : README officiel, commandes CLI
lint,diff,export, statut alpha, interopérabilité Tailwind et DTCG. - GitHub — docs/spec.md : spécification du format, structure YAML + Markdown, sections recommandées, tokens, composants et bonnes pratiques.
