[🤖] Le design du résultat changeait sans cesse : pourquoi il me fallait DESIGN.md

✨ Résumé de GPT-5.6 Sol

La brochure sortait différemment à chaque fois, ce qui m’a conduit à DESIGN.md. Pourtant, je ressentais depuis longtemps le besoin de cohérence visuelle et je l’appliquais déjà à ma manière dans d’autres projets personnels. Voici comment j’ai relié ces critères dispersés dans un format que l’IA peut consulter en continu.

Le design changeait à chaque nouvelle brochure

Après un long congé, j’ai repris la production d’une brochure dans mon entreprise actuelle. Après avoir géré coordinateur et workers au point de ne pas terminer la brochure à temps, j’ai allégé la méthode de travail, mais le design continuait à me gêner. Même dans un seul PPT, l’ambiance variait d’une page à l’autre, et chaque nouvelle version semblait générer un nouveau design.

Mes autres projets n’étaient pas très différents. J’ai essayé de créer une unité en demandant à l’IA de chercher des références et de bons exemples, ou en les partageant moi-même. Parfois, j’espérais simplement obtenir un bon tirage à la loterie. Ce qui revenait n’était qu’un résultat de classe D, sans cohérence et qui sentait l’IA à plein nez.

Je ne voulais pas générer un écran vaguement séduisant à chaque fois. Je voulais que les mêmes couleurs, la même hiérarchie typographique, les mêmes espaces et la même logique de composants se prolongent sur la page et la version suivantes. Mais la brochure ne possédait aucun de ces critères. À chaque nouvelle référence, l’IA recommençait à deviner l’ambiance depuis zéro.

Ce n’était pas la première fois que je voyais ce problème

Avec le recul, ce n’était pas la première fois que je ressentais le besoin de cohérence visuelle. En juillet 2025, j’avais déjà écrit une réflexion sur la création d’un système de design pour le vibe coding. À l’époque, j’imaginais déjà un processus consistant à concevoir avec Figma AI, sauvegarder écrans et code comme références, organiser typographie et palette de couleurs, puis comparer le tout au résultat réel.

Dans Tadak Bible, je ne me suis pas contenté d’y penser. À partir de janvier 2026, j’ai commencé à rassembler couleurs, typographie et thèmes au même endroit. J’ai documenté des orientations comme le bleu pastel et la lavande, une atmosphère calme et chaleureuse, ou la lisibilité de l’écran de saisie biblique. J’ai ensuite créé BibleColors, BibleTypography et des tokens d’espacement, d’angles, d’icônes et de mouvement, puis je les ai appliqués à plusieurs écrans. J’ai aussi ajouté des contrôles pour empêcher les nouveaux écrans de réinventer arbitrairement couleurs et tailles de police.

Autrement dit, je savais déjà pourquoi un système de design était nécessaire. Dans Tadak Bible, j’étais allé assez loin pour relier couleurs, polices et composants communs du produit au moyen du code et de la documentation.

Le problème était que cette expérience ne se transmettait pas aux autres projets et livrables. Les critères de Tadak Bible étaient dispersés dans sa documentation, son code Flutter et ses contrôles. Il n’existait aucun format commun qu’une IA lançant un nouveau projet web ou PPT puisse lire immédiatement pour conserver la même sensibilité. À chaque projet, je cherchais encore des références, lançais encore des exemples et attendais encore un bon résultat.

J’ai essayé de relier les critères dispersés avec DESIGN.md

J’ai alors découvert le catalogue ko/design.md, qui organise les systèmes de design de services coréens sous forme de contexte pour LLM,¹ ainsi que le dépôt DESIGN.md de Google Labs Code.²

Le nom et les exemples m’ont donné une idée approximative du fichier. Il semblait rassembler couleurs, polices, espacements, composants et ambiance générale afin que l’IA puisse les consulter à chaque création. Je me suis dit que je pouvais transférer les critères déjà construits dans Tadak Bible vers une forme qu’un Agent pourrait lire en continu, puis gérer les autres projets de la même façon.

Le problème, c’est que là encore, je me suis contenté d’une compréhension approximative. J’ai demandé à l’IA de découvrir ce qu’était DESIGN.md, d’étudier les exemples et de créer quelque chose de similaire. Puis je suis passé à autre chose en supposant qu’elle avait suffisamment étudié et appliqué le format. Je n’ai pas vérifié moi-même le périmètre décrit par la documentation officielle, si le fichier créé le respectait, ni si le résultat réel avait gagné en cohérence visuelle.

Le fait que l’IA lise un lien et produise un fichier plausible n’était pas la même chose que disposer des critères de design que je voulais. Ne pas avoir contrôlé cette différence était mon erreur.

J’ai failli mettre toute la planification produit dans DESIGN.md

Sans avoir correctement vérifié le périmètre de DESIGN.md, j’ai voulu y organiser tous les écrans et parcours par utilisateur, les états, les permissions et la récupération du prochain produit. Codex a repris cette extension telle quelle et a commencé à créer des DESIGN.md par rôle et des règles séparées.

Quelque chose clochait. L’UI ne semblait pas réellement traitée, alors j’ai répété qu’il fallait commencer par examiner l’exemple Google Labs Code que j’avais présenté comme le plus important.

Après lecture de la source, la frontière est devenue beaucoup plus claire. Le DESIGN.md de Google Labs Code est un format qui transmet en continu l’identité visuelle d’un produit à un Agent de programmation. Le YAML peut contenir des tokens de design précis, tandis que le corps Markdown explique pourquoi ces couleurs, polices et formes sont utilisées, et comment l’ensemble doit apparaître, être ressenti et se comporter.³

Le mot se comporter ne voulait pas dire absorber toute la planification produit. Rôles, parcours, permissions, exceptions, récupération, structure des écrans et validation devaient continuer à être détaillés dans la documentation produit ordinaire. Les détails par rôle que j’avais d’abord voulu créer n’étaient pas inutiles ; ils appartenaient simplement à docs/, et non à un fichier nommé DESIGN.md.

Suivre le format n’est pas copier le design

Une fois cette frontière corrigée, il restait un autre point à vérifier. Prendre Google Labs Code comme référence ne signifiait pas copier le design d’exemple du dépôt pour l’appliquer à tous les projets.

Google a fourni le format DESIGN.md et sa méthode d’interprétation, pas le contenu du design. Les couleurs, polices et ambiances des exemples appartiennent uniquement à l’identité visuelle de ces exemples. Le DESIGN.md d’un vrai projet doit contenir des critères issus de ses utilisateurs, de son environnement, de sa marque et des références que j’ai choisies. Le catalogue ko/design.md sert aussi de matériau de comparaison ; copier n’importe quel design ne crée pas automatiquement l’identité de notre produit.

J’ai donc corrigé les règles communes et le Skill de planification produit. Un DESIGN.md ne serait créé que lorsque l’identité visuelle fait réellement partie du périmètre, tandis que rôles, parcours, permissions, récupération et conception détaillée des écrans resteraient dans la documentation produit ordinaire. J’ai supprimé l’orientation par rôle que j’avais inventée, et le modèle final a passé la validation officielle de Google.

Cette fois, j’ai trouvé DESIGN.md pour réduire la loterie du design, mais j’ai aussi confié la signification de DESIGN.md à la loterie de l’IA. Si je donne un lien, dis “cherche et applique”, puis fais confiance au résultat simplement parce qu’un fichier existe, l’IA remplit à sa manière tous les blancs que je n’ai pas vérifiés.

Un fichier DESIGN.md ne produit pas automatiquement un bon design. Pour un PPT en particulier, il faut encore créer de vrais masques et exemples de mise en page, puis vérifier que le rendu respecte ces critères. Mais si je laisse dans DESIGN.md la source canonique des critères visuels acceptés pour chaque produit, l’IA aura au moins moins d’occasions de retirer une ambiance depuis un écran vide à chaque fois.

Je comprenais depuis longtemps le besoin de cohérence visuelle. Je construisais déjà un système de design dans Tadak Bible. Ce n’est que maintenant que j’ai trouvé un format lisible par un Agent, capable de transmettre cette expérience à d’autres projets et livrables, et que je l’ai enfin relié au nom DESIGN.md.

Références

1. ko/design.md, catalogue des systèmes de design de services coréens. Il fournit les designs distinctifs de services coréens comme contexte pour LLM. ↩

2. Google Labs Code, DESIGN.md. Il présente un format d’identité visuelle que les Agents de programmation peuvent consulter en continu. ↩

3. Google Labs Code, spécification DESIGN.md. Elle définit la structure, les sections standard et les règles de validation des tokens de design YAML et de leur justification en Markdown. ↩