AI-translated from English; not yet reviewed by a fluent editor.

# Créer un DESIGN.md approuvé par le propriétaire pour Claude Code

> Rédigez une spécification visuelle à partir de décisions de marque approuvées, puis utilisez-la pour deux petites modifications avec Claude Code et inspectez les différences et les rendus.

By BIG CHANGE Editorial

Published: 2026-10-20T01:05:55.739Z
Updated: 2026-10-20T01:05:55.739Z
Canonical: https://bigchange.ai/blog/claude-code-owner-approved-design-md-guide

![Conceptual charcoal illustration of a small visual reference clipped to a wall rail above two separate framed layout proofs.](https://bigchange.ai/api/media/file/owner-approved-design-reference-two-proofs-hero-v1.png)
AI-generated conceptual illustration by BIG CHANGE.

Un agent de programmation IA ne peut suivre une référence visuelle que dans la mesure où celle-ci contient des décisions exploitables. Si vous possédez le projet et disposez déjà de règles de marque approuvées, rassemblez-les dans un fichier `DESIGN.md` vérifiable, puis utilisez Claude Code pour deux petites modifications que vous inspecterez vous-même. Le livrable est votre spécification approuvée. Les deux modifications vérifient son utilité pour ces réalisations précises ; elles ne permettent pas de prévoir le résultat des modifications futures.

Cette procédure repose sur la documentation. BIG CHANGE a examiné une collection de fichiers de conception à une révision précise et les manuels Claude Code d’Anthropic le 20 octobre 2026. Nous n’avons pas exécuté Claude Code, modifié ou rendu les deux réalisations, ni mesuré le coût ou la qualité de conception.

## Le changement essentiel

- **Ce qui change :** Le propriétaire peut rédiger une spécification visuelle versionnée à partir de décisions approuvées et fournir ce fichier exact à Claude Code avant une modification limitée.
- **Pourquoi cela compte :** Une source unique vérifiée rend les règles de couleur, de typographie et de mise en page disponibles pour les comparer à deux révisions réelles, le propriétaire décidant si chaque résultat est acceptable.
- **À surveiller :** Le fichier doit être lu intégralement avant chaque modification. Sa présence dans le projet, la mention de son chemin ou l’assurance de Claude ne prouvent pas qu’il a été chargé ou suivi.

## Avant de commencer

Il vous faut un projet qui vous appartient, l’autorisation de le modifier, deux petites réalisations existantes dont vous pouvez produire un rendu et une copie de travail ou un point de contrôle de version récupérable. Il peut s’agir de deux pages, ou d’une page et d’une présentation, à condition de connaître le véritable processus de modification et de rendu de chaque projet. Choisissez une modification visuelle limitée pour chacune. Conservez les textes actuels, les liens et les interactions fonctionnelles pour comparaison.

Rassemblez les valeurs de couleur approuvées par le propriétaire **et leurs rôles**, les polices autorisées ou sous licence et leurs remplacements, les règles d’utilisation des logos et images, le public visé, les dimensions et les exigences d’accessibilité. Utilisez le véritable registre d’approbation ou demandez au propriétaire de trancher les choix manquants. Le site public d’une entreprise ou l’analyse de conception d’un tiers n’autorise pas les valeurs ou ressources pour votre projet. L’approbation d’une ressource par son propriétaire n’autorise pas non plus automatiquement son envoi à un fournisseur de modèles.

Configurez [Claude Code](https://code.claude.com/docs/en/quickstart) avec un compte ou fournisseur admissible, puis examinez les [conditions d’utilisation des données](https://code.claude.com/docs/en/data-usage) et les [autorisations des outils](https://code.claude.com/docs/en/permissions) du compte avant d’exposer du code, du texte ou des ressources privés. Un projet stocké localement peut quand même envoyer du contenu à un service de modèles. Vérifiez qui peut voir les éléments, quels outils peuvent lire ou modifier les fichiers et si vous pouvez transmettre chacun d’eux. Les [indications de coût](https://code.claude.com/docs/en/costs) dépendent du compte et du fournisseur ; ce guide ne peut pas attribuer un prix fixe à votre session.

La [collection Awesome DESIGN.md à une révision précise](https://github.com/VoltAgent/awesome-design-md/blob/3b605329240ce735b510037cca322f1831fdd7f8/README.md) peut inspirer les sections du fichier, mais reste facultative. Elle analyse des sites publics ; ce n’est pas un manuel de marque approuvé par le propriétaire. Vous pouvez rédiger le fichier directement à partir de vos décisions approuvées. Si vous copiez du texte du dépôt, conservez sa [notice de droits d’auteur et d’autorisation MIT](https://github.com/VoltAgent/awesome-design-md/blob/3b605329240ce735b510037cca322f1831fdd7f8/LICENSE). Cette notice n’accorde aucun droit sur les marques, fichiers de polices ou images d’un autre site.

## Créer la référence approuvée par le propriétaire

1. Créez `brand-reference/DESIGN.md` dans le projet qui vous appartient. Remplissez ce schéma minimal à partir du registre d’approbation. Le texte entre crochets indique les informations que le propriétaire doit fournir ; il ne propose pas une marque. Laissez un élément marqué `UNRESOLVED` tant que le propriétaire ne l’a pas décidé. Ne demandez pas à Claude d’inventer une valeur pour combler un manque.

```markdown
# Visual specification

Owner: [owner or approving role]
Approved version/date: [version and approval date, or UNRESOLVED]
Audience and artifact purpose: [owner-approved description]
Approval evidence: [internal record or location, without private data in a shared copy]

## Color roles and values
- Background: [approved value and color format, or UNRESOLVED]
- Text: [approved value and color format, or UNRESOLVED]
- Primary action: [approved value and color format, or UNRESOLVED]
- Link, border and status roles: [each approved value, or UNRESOLVED]

## Typography and scale
- Heading family and permitted fallback: [approved names, or UNRESOLVED]
- Body family and permitted fallback: [approved names, or UNRESOLVED]
- Heading/body sizes, weights and line heights: [approved scale, or UNRESOLVED]
- Font license or use restriction: [approved terms, or UNRESOLVED]

## Spacing and layout
- Spacing scale, content width and grid: [approved values, or UNRESOLVED]
- Target artifact dimensions: [approved sizes, or UNRESOLVED]

## Components and states
- Buttons, links, inputs and navigation: [approved appearance and behavior]
- Hover, focus, disabled and error states: [approved rules, or UNRESOLVED]

## Responsive and accessibility rules
- Desktop/phone behavior and breakpoints: [approved rules, or UNRESOLVED]
- Contrast, readable type, focus order and touch use: [approved requirements]

## Assets and forbidden substitutions
- Permitted logo/image assets and usage: [approved paths and permissions]
- Do not substitute: [owner-approved prohibited colors, fonts, marks or patterns]

## Owner approval and changes
- Approved by: [person or role and date, or UNRESOLVED]
- Version: [version]
- Changelog: [date, change, approver]
- Unresolved decisions: [list, or "none" after owner review]
```

2. Vérifiez chaque ligne remplie par rapport aux décisions sources du propriétaire, y compris les droits d’utilisation des polices et images. Réglez avec lui les conflits entre les anciens styles du projet et les règles actuellement approuvées. Faites approuver ce fichier exact et enregistrez sa version. Suspendez toute modification qui dépend d’une valeur non résolue. Enregistrez le fichier approuvé et les deux réalisations de départ dans le contrôle de version ou une autre copie récupérable.

## Utiliser le fichier pour deux modifications limitées

3. Dans le projet qui vous appartient, ouvrez une session Claude Code avec le compte et les autorisations vérifiés. Donnez les chemins exacts de `brand-reference/DESIGN.md` et de la première réalisation. Demandez d’abord à Claude de lire **intégralement** la référence et la réalisation, puis de s’arrêter avant toute modification. Inspectez le résultat réel de lecture de fichier/de l’outil pour vérifier le chemin et le contenu complet. Une lecture refusée, un résultat tronqué, la simple mention du chemin ou un résumé verbal ne suffisent pas. Anthropic documente les [fichiers d’instructions de projet](https://code.claude.com/docs/en/memory) comme une option de configuration distincte ; ne supposez pas qu’un fichier `DESIGN.md` quelconque est découvert automatiquement et ne comptez pas sur une référence `@` ayant le même comportement dans toutes les versions.
4. Lorsque la lecture complète est visible, demandez l’unique modification visuelle choisie pour la première réalisation, en utilisant seulement les règles approuvées. Limitez les fichiers touchés ; préservez les textes, liens, commandes et le code sans rapport. Demandez à voir les différences proposées et la méthode établie du projet pour produire le rendu. Inspectez chaque fichier modifié avant de l’accepter. Refusez les couleurs, polices, ressources, dépendances ou modifications supplémentaires non approuvées.
5. Produisez le rendu de la première réalisation avec son **véritable processus de projet**. Comparez le résultat au fichier approuvé et à la réalisation de départ dans des dimensions d’ordinateur et de téléphone adaptées au projet. Vérifiez les valeurs des jetons dans les fichiers modifiés, la lisibilité du contraste, la hiérarchie des titres et de la typographie, les coupures ou débordements horizontaux, le focus visible, le clavier et les interactions touchées, ainsi que la conservation des textes et liens. Notez la version de référence, la révision de la réalisation, les vérifications et les corrections. La description d’un rendu n’est pas le résultat rendu.
6. Pour la deuxième réalisation, indiquez de nouveau son chemin exact et `brand-reference/DESIGN.md`. Demandez une nouvelle lecture complète **avant** sa modification et inspectez le résultat de l’outil. Demandez ensuite une modification limitée, examinez les différences, produisez le rendu avec le processus propre à cette deuxième réalisation et répétez les mêmes vérifications. Comparez les deux révisions à la **même version du fichier approuvé**. Notez pour chaque règle si elle est suivie, manquée ou nécessite une révision approuvée par le propriétaire ; corrigez les écarts et revérifiez les deux réalisations si la référence change.

Le travail est terminé lorsque vous avez la spécification approuvée et versionnée, deux révisions inspectées et rendues, et un bref relevé des règles respectées ou manquées. Gardez les révisions d’origine pour pouvoir revenir en arrière. Si une lecture échoue, vérifiez le chemin exact, les autorisations, la taille du fichier ou une éventuelle troncature avant de demander une modification. Si la spécification entre en conflit avec les styles du projet ou l’accessibilité, obtenez la décision du propriétaire et réduisez la portée du changement. Si une réalisation ne peut pas être rendue ou une interaction vérifiée, laissez la modification non acceptée jusqu’à ce que la vérification soit possible. Tout changement ultérieur de marque exige une nouvelle revue délibérée des résultats antérieurs.

Pour une autre tâche utilisant un fichier communautaire comme référence pour une page, consultez [notre guide DESIGN.md à une révision précise](https://bigchange.ai/blog/claude-code-pinned-design-reference-page-guide). Le travail décrit ici consiste d’abord à créer et faire approuver votre propre spécification.

## Sources et lectures complémentaires

- Le [README Awesome DESIGN.md à une révision précise](https://github.com/VoltAgent/awesome-design-md/blob/3b605329240ce735b510037cca322f1831fdd7f8/README.md) fournit des exemples de sections et présente ses fichiers comme des analyses de sites publics fournies en l’état. Ses propos sur la qualité des résultats ne constituent pas un résultat testé ici. La [licence MIT](https://github.com/VoltAgent/awesome-design-md/blob/3b605329240ce735b510037cca322f1831fdd7f8/LICENSE) régit les éléments copiés du dépôt, et non l’identité ou les ressources de tiers.
- Le [guide de démarrage d’Anthropic](https://code.claude.com/docs/en/quickstart) couvre la configuration du compte et du projet. Ses [processus courants](https://code.claude.com/docs/en/common-workflows) et son [manuel de mémoire de projet](https://code.claude.com/docs/en/memory) décrivent les processus de fichiers et d’instructions ; aucun ne prouve que ce fichier autonome a été lu intégralement dans la session du lecteur.
- Les manuels d’Anthropic sur les [autorisations](https://code.claude.com/docs/en/permissions), l’ [utilisation des données](https://code.claude.com/docs/en/data-usage) et les [coûts](https://code.claude.com/docs/en/costs) expliquent les contrôles et conditions propres au compte. Ils n’établissent pas une modification observée, un traitement exclusivement local, une facture fixe ou un gain de qualité pour ce guide.

## Sources

- [README Awesome DESIGN.md à une révision précise](https://github.com/VoltAgent/awesome-design-md/blob/3b605329240ce735b510037cca322f1831fdd7f8/README.md) — Collection communautaire à une révision précise et exemples de sections de référence visuelle. Elle analyse des sites publics et fournit ses fichiers en l’état ; son langage promotionnel sur la qualité et l’utilisation immédiate ne prouve ni les résultats de ce propriétaire ni son approbation des marques représentées. L’intégralité du relevé source privé et la vérification indépendante figurent dans le dossier d’admission approuvé.
- [Licence MIT d’Awesome DESIGN.md](https://github.com/VoltAgent/awesome-design-md/blob/3b605329240ce735b510037cca322f1831fdd7f8/LICENSE) — La notice de droits d’auteur et d’autorisation de la révision du dépôt doit accompagner les textes ou parties substantielles copiés. Elle n’accorde pas par elle-même de droits sur le nom, la marque, le logo, les polices propriétaires ou les images d’un site représenté.
- [Guide de démarrage Claude Code](https://code.claude.com/docs/en/quickstart) — Prérequis officiels de compte/fournisseur, de connexion et de projet. BIG CHANGE n’a testé aucune installation, aucun accès ni aucune session Claude pour ce guide.
- [Processus courants de Claude Code](https://code.claude.com/docs/en/common-workflows) — Processus officiels de fichiers de projet et de revue des modifications. Le guide exige une lecture complète observée et les différences réelles pour chaque réalisation plutôt que de dépendre d’une notation abrégée de référence aux fichiers sensible aux versions.
- [Mémoire de projet Claude Code](https://code.claude.com/docs/en/memory) — Documente les instructions du projet et les imports facultatifs comme configuration. Ne prouve pas qu’un fichier autonome brand-reference/DESIGN.md est chargé automatiquement, ni que l’une des modifications du lecteur l’a suivi.
- [Autorisations Claude Code](https://code.claude.com/docs/en/permissions) — Contrôles officiels des autorisations des outils. L’approbation du contenu de marque par le propriétaire et les instructions données à Claude sont distinctes de l’autorité réelle sur les fichiers/outils et de l’autorisation de transmettre des éléments privés.
- [Utilisation des données Claude Code](https://code.claude.com/docs/en/data-usage) — Traitement et conservation dépendant du compte et du fournisseur. Un projet local ne prouve pas une session de modèle exclusivement locale ; le lecteur doit vérifier ses droits avant de fournir du contenu privé.
- [Coûts Claude Code](https://code.claude.com/docs/en/costs) — Indications officielles sur l’utilisation et la facturation selon le compte et le fournisseur. Aucun prix fixe, quota gratuit, gain de temps ou coût de tâche n’a été mesuré pour cette procédure.
- [BIG CHANGE : utiliser une référence DESIGN.md à une révision précise dans Claude Code pour une page](https://bigchange.ai/blog/claude-code-pinned-design-reference-page-guide) — Couverture connexe pour situer l’application d’une référence communautaire à une révision précise à une page existante. Elle ne rédige pas une spécification approuvée propre au propriétaire et ne constitue ni une source des nouvelles étapes de ce guide ni une suite dans la chronologie « In this story ».