Les guides de marque généraux couvrent raisonnablement la recherche, le positionnement, l'identité, la voix et l'application. Le handoff pour développeur intervient plus tard. Son rôle est de traduire la direction de marque approuvée en décisions pour le site web, sans demander à l'intégrateur d'inventer des règles de design ou des politiques manquantes.

Séparez six types de documents. Les assets d'identité traditionnels incluent les logos, les symboles, les couleurs de marque, les polices, la photographie, l'illustration et les directives verbales. Les décisions de design web assignent ces éléments à des rôles sémantiques, des échelles, des mises en page, des modes et des règles d'utilisation. Les exigences produit définissent le comportement, les permissions, la validation, le contenu et la récupération. Les artefacts de livraison transportent les décisions de design approuvées dans un dépôt ou un outil. Les consommateurs implémentés sont les composants et les surfaces qui lisent ces artefacts. Les preuves d'acceptation consignent ce qui a été vérifié et ce qui reste non résolu.

Enregistrez chaque décision comme une chaîne allant de l'autorité à la preuve. Cela expose deux erreurs courantes : traiter le dernier export comme la source de vérité, et traiter une valeur de token correcte comme la preuve que l'interface l'utilise correctement.

• Artefact : l'asset, la règle, le groupe de tokens, le fichier ou la référence examiné.
• Source de vérité : l'emplacement et la version approuvés qui font autorité sur la décision.
• Objectif sémantique : ce que la décision signifie dans l'interface, et non simplement sa valeur visuelle.
• Format de livraison : la manière dont la décision parvient au projet, comme des directives écrites, des tokens DTCG, des variables CSS, un thème Tailwind ou un élément de registre.
• Consommateur prévu : le composant, le template, l'agent, l'outil de build ou la couche de style runtime censé l'utiliser.
• Responsable : la personne ou l'équipe autorisée à lever une ambiguïté ou à approuver un changement.
• Modifications autorisées : transformations que l'intégrateur peut effectuer sans demander d'approbation.
• Omissions connues : rôles, modes, états, breakpoints, assets ou règles requis que la source ne définit pas.
• Preuve d'acceptation : la surface, l'état, la fenêtre d'affichage, le mode et le résultat observable utilisés pour vérifier l'implémentation.

artifact: ""
status: ready-to-implement | requires-decision | reference-only | outside-handoff
source_of_truth:
  location: ""
  version_or_date: ""
  approved_by: ""
semantic_purpose: ""
delivery:
  format: ""
  path_or_identifier: ""
intended_consumers:
  - ""
owner: ""
permitted_changes:
  - ""
known_omissions:
  - ""
acceptance_evidence:
  surfaces:
    - ""
  states:
    - ""
  viewports_or_containers:
    - ""
  color_modes:
    - ""
  expected_observation: ""
notes: ""

Le champ de statut contrôle la suite des opérations. Il empêche une image de référence d'acquérir une autorité accidentelle et exclut les exigences non définies de la file d'implémentation.

• Prêt pour l'implémentation : l'autorité, l'objectif sémantique, le consommateur, les modifications autorisées et les conditions d'acceptation pertinentes sont explicites.
• Nécessite une décision : l'entrée est pertinente, mais au moins une règle matérielle est manquante ou contradictoire. Assignez un responsable et bloquez uniquement le travail concerné.
• Référence uniquement : l'élément communique une direction ou un contexte mais n'est pas assez précis pour régir l'implémentation. Les mood boards et les maquettes de campagne appartiennent souvent à cette catégorie.
• Hors du périmètre du handoff : l'élément appartient à une autre discipline ou à un autre livrable, tel que la revue des marques déposées, la planification de campagne, les permissions produit ou la copie éditoriale finale. Documentez cette limite pour que son absence ne soit pas confondue avec une tâche de développement.

La classification est granulaire. Un pack de logos peut être prêt pour l'intégration alors que sa taille minimale sur des largeurs réduites nécessite encore une décision. Un système de couleurs peut être prêt pour le mode clair alors que le mode sombre reste indéfini. Segmenter le registre de cette manière permet au travail de continuer sans masquer la partie non résolue.

Les couleurs brutes sont des ingrédients. Le code du site web a besoin de rôles tels que l'arrière-plan de page, le premier plan, la carte, la surface atténuée, la bordure, l'action primaire, l'action destructive, l'anneau de focus et les couleurs de statut. Chaque paire premier plan/surface doit avoir un usage prévu. Si les modes clair et sombre sont supportés, enregistrez les deux mappages et précisez si un mode peut se rabattre sur une autre valeur.

Ne dérivez pas les couleurs d'erreur, d'avertissement, de succès, de sélection ou de focus d'une couleur d'accentuation de marque, à moins que l'autorité ne leur assigne ces significations. Une même valeur hexadécimale peut être valide comme couleur de campagne et incorrecte comme rôle d'interface.

Enregistrez la famille pour chaque rôle, les graisses approuvées, l'échelle typographique, les règles de hauteur de ligne, l'espacement des lettres, les polices de secours (fallbacks) et les endroits où les polices mono ou display sont autorisées. Le nom d'une famille de polices seul laisse le navigateur et le développeur choisir les graisses et les métriques. Cela ne précise rien non plus sur les titres, le corps de texte, les libellés, les boutons, les tableaux ou les données numériques.

La livraison des polices est une décision d'implémentation distincte. Le kit de marque peut approuver les familles et les rôles tandis que le projet a encore besoin d'une stratégie de chargement, des fichiers disponibles, des fallbacks et de vérifications de performance. Ces choix techniques doivent préserver les rôles approuvés sans prétendre que le handoff visuel a réglé tous les compromis de livraison.

Spécifiez l'échelle d'espacement, les gouttières de page, les largeurs de contenu, le rythme des sections, le comportement de la grille, les rayons de courbure, les bordures, les ombres et les motifs récurrents qui rendent le système reconnaissable. Nommez les exceptions. Si un motif est décoratif, précisez où il peut apparaître et comment il se comporte dans des conteneurs restreints.

Pour les logos, enregistrez les variantes approuvées, la zone d'exclusion, la taille minimale utile, les restrictions d'arrière-plan et si le recadrage ou le recolorage est autorisé. Pour la photographie et l'illustration, incluez des règles de sélection et de traitement plutôt qu'un simple dossier d'exemples. Le texte alternatif et la signification du contenu dépendent toujours du contexte réel de la page ; une bibliothèque d'actifs de marque ne peut pas les fournir de manière universelle.

Les breakpoints, le comportement des conteneurs, le reflow, la troncature, les changements de navigation, la densité et les cibles tactiles sont des décisions liées au site web. Les états de survol (hover), de focus, pressé, sélectionné, désactivé, de chargement, de succès, vide et d'erreur nécessitent des spécifications là où le produit peut les atteindre. Un board de marque statique ne définit pas ces comportements.

Le handoff peut définir le traitement visuel des boutons, des champs de saisie, des cartes, de la navigation, des tableaux, des graphiques et des dialogues. Il ne définit pas automatiquement ce que font ces composants. Les permissions, la validation, la confirmation, l'annulation, la gestion des données et la récupération relèvent des exigences produit. Maintenez cette autorité séparée, même lorsque les deux types de règles apparaissent dans la même interface.

Le kit public Ambient Sage illustre la manière dont plusieurs couches de handoff peuvent s'articuler. Il assigne Plus Jakarta Sans aux rôles de titres et de corps de texte, avec les graisses 400, 500, 600 et 700. JetBrains Mono remplit le rôle mono avec les graisses 400, 500 et 700. L'échelle publiée est compact-product. Son système de couleurs inclut des rôles sémantiques pour les modes clair et sombre, tandis que les directives écrites décrivent un canevas warm-sage, un traitement des cartes tonal, un accent jaune retenu et des valeurs numériques surdimensionnées.

C'est plus utile qu'une simple liste de polices car cela lie les familles aux rôles et aux graisses, et plus utile qu'une palette car cela fournit des mappages sémantiques et des conseils d'utilisation. Ce même kit est disponible via DESIGN.md, le JSON des tokens DTCG, des variables CSS, des sorties Tailwind, le JSON du registre shadcn, un chemin d'installation du registre, l'Identity Forge CLI et un accès MCP.

L'exemple a des limites strictes. Il ne prouve pas que Plus Jakarta Sans et JetBrains Mono sont le meilleur duo pour un autre produit. Il n'établit pas le comportement des composants, les règles responsive, les exigences de contenu, la conformité d'accessibilité ou l'état de préparation à la production d'un autre produit. Ces décisions nécessitent toujours des responsables locaux et des preuves.

Un artefact de livraison doit transporter une décision approuvée sans devenir discrètement l'autorité qui l'a créée. Enregistrez quelle source a produit l'artefact, quand il a été généré et quel consommateur le lit. Si un export et sa source divergent, résolvez la source ou le chemin de régénération avant de corriger le composant visible.

• DESIGN.md véhicule l'intention, les règles d'utilisation, les directives de mise en page, les motifs, les traitements de composants et les contraintes qui sont difficiles à exprimer sous forme de valeurs de tokens.
• Les tokens DTCG fournissent une représentation structurée qui peut alimenter des outils ou des transformations tout en conservant les noms et les valeurs des tokens.
• Les variables CSS exposent les valeurs du thème directement aux styles et aux composants. Leur présence ne prouve pas que chaque composant référence le rôle correct.
• La sortie Tailwind mappe les décisions dans les conventions d'utilitaires et de thème du projet. Des utilitaires locaux peuvent toujours outrepasser ou contourner ce mappage.
• Un élément du registre shadcn package des valeurs pour un chemin d'installation compatible. Il reste un mécanisme de livraison, et non la preuve que les composants installés satisfont toutes les règles de marque.
• L'accès CLI applique ou écrit des artefacts dans un projet. L'accès MCP permet à un agent compatible de découvrir, lire ou appliquer les informations du kit. Dans les deux cas, le projet destinataire a toujours besoin d'une autorité déclarée et d'un registre d'acceptation.

Choisissez des surfaces qui sollicitent différents rôles plutôt que de vérifier chaque route superficiellement. Incluez les modes, les états et les largeurs de conteneurs que le produit supporte réellement.

• Navigation : traitement du logo, état actif, hiérarchie, focus et comportement sur largeur réduite.
• Titres et corps de texte : mappage des rôles, graisses autorisées, longueur de ligne, retour à la ligne et rythme vertical.
• Formulaires : libellés, champs de saisie, texte d'aide, validation, contrôles désactivés, focus et états de récupération inclus dans le périmètre.
• Boutons et liens : traitements primaire, secondaire, destructif, pressé, désactivé et focus lorsque nécessaire.
• Cartes et superpositions : rôles de surface, paires de premier plan, bordures ou séparation tonale, rayon, espacement et empilement.
• Tableaux ou métriques : hiérarchie des titres, traitement numérique, alignement, densité, valeurs longues et états vides.
• États de statut : rôles de succès, d'avertissement, d'erreur, de sélection et de chargement, sans inventer de signification à partir de couleurs décoratives.
• Modes clair et sombre : parité sémantique, lisibilité, substitutions locales et composants conservant une valeur brute en mode clair.
• Conteneurs étroits : retour à la ligne, reflow, clipping, changements de navigation et motifs entrant en conflit avec le contenu.

Une capture d'écran peut révéler un écart, mais elle identifie rarement le responsable. Tracez une décision approuvée tout au long de la chaîne complète. Un changement contrôlé rend visibles les couches obsolètes ou contournées.

1. 1

   Choisir une décision approuvée à faible risque

   Utiliser un token réversible ou un mappage typographique ayant une source claire et un consommateur représentatif. Enregistrer la version actuelle de la source et les surfaces attendues.

2. 2

   Confirmer l'enregistrement faisant autorité

   Vérifier l'objectif sémantique, les modes autorisés, le responsable et la valeur ou règle attendue. Si l'autorité est ambiguë, interrompre le test et résoudre cette ambiguïté en priorité.

3. 3

   Régénérer ou mettre à jour l'artefact de livraison sélectionné

   Utiliser le flux de livraison habituel. Enregistrer la version de l'artefact ou le changement résultant afin de pouvoir distinguer un export obsolète d'une implémentation incorrecte.

4. 4

   Inspecter le consommateur visé

   Confirmer que le composant ou la couche de style concernée lit le rôle sémantique. Rechercher les valeurs brutes, les alias, les constantes copiées, les valeurs par défaut du framework et les substitutions locales.

5. 5

   Vérifier les surfaces représentatives

   Inspecter l'état, le viewport, le conteneur et le mode de couleur applicables. Enregistrer à la fois le changement attendu et toute surface qui n'a pas changé.

6. 6

   Classifier chaque écart par couche

   Une décision source erronée revient au responsable du design. Un export obsolète revient au processus de livraison. Un mauvais mappage relève de l'intégration du consommateur. Une substitution locale relève de l'implémentation. Un changement ailleurs peut être une dérive non liée et ne doit pas être intégré à la correction de la marque sans preuve.

7. 7

   Restaurer ou approuver la valeur contrôlée

   Revenir à la valeur approuvée, sauf si le test lui-même était une mise à jour autorisée. Conserver l'enregistrement des preuves dans les deux cas.

Terminer l'intégration par une décision explicite. L'approbation doit être limitée aux décisions et surfaces étayées par les preuves, et non formulée comme une affirmation générale selon laquelle la marque ou le site web est terminé.

decision: approve | revise | block
scope:
  decisions: []
  consumers: []
  surfaces: []
  modes: []
  viewports_or_containers: []
resolved_evidence:
  - decision: ""
    source_of_truth: ""
    delivery_artifact: ""
    observed_result: ""
unresolved:
  - issue: ""
    classification: missing-decision | stale-artifact | consumer-mapping | local-override | unrelated-drift
    owner: ""
    required_evidence: ""
    next_action: ""
    blocks: ""
permitted_implementation_step: ""
reviewed_by: ""
reviewed_on: ""

L'étape d'implémentation suivante doit découler directement de cet enregistrement. Appliquer l'artefact approuvé lorsque la chaîne est complète. Demander une décision nommée lorsque l'autorité est manquante. Corriger la couche de livraison ou de consommation identifiée lorsque la source est déjà correcte. Cela évite que le développeur ne transforme une question de marque non résolue en une convention locale permanente.

• How To Build a Brand From Scratch (2026) : Shopify présente le kit de marque et le guide de style dans un processus plus large qui couvre également la recherche d'audience, la voix, le nommage, l'histoire, la création du logo, l'application et la mesure.
• What is a Brand? Definition and Examples : Ramotion décrit les composants de la marque à travers l'identité visuelle, l'identité verbale, les expériences d'interaction, les valeurs et le positionnement, montrant qu'une marque s'étend au-delà d'un simple logo.
• What is Branding? Understanding Its Importance : HubSpot aborde la stratégie de marque, les ressources visuelles, la voix et l'application sur les sites web et autres canaux comme faisant partie d'un processus de branding plus vaste.
• Kit de design Ambient Sage : le kit public Ambient Sage documente l'usage de Plus Jakarta Sans pour les titres et le corps de texte, de JetBrains Mono pour le style mono, des design tokens sémantiques (clair et sombre), des directives écrites ainsi que plusieurs formats de livraison pour les développeurs.
• Comment générer un DESIGN.md (et à quoi cela sert) : Identity Forge définit le DESIGN.md comme un brief de design écrit comprenant l'intention, les systèmes de couleurs et de typographie, les règles de mise en page et d'espacement, le traitement des composants, les motifs et les contraintes d'utilisation explicites.
• Explications sur les design tokens de couleur sémantiques : Identity Forge explique que les tokens sémantiques nomment les couleurs par leur fonction (comme background, foreground, primary, border et ring) plutôt que par leur teinte brute.
• Checklist de revue UI pour l'IA : testez les interfaces générées avant le déploiement : ce guide de revue distingue les exigences produit, l'autorité de design, les livrables, les preuves d'implémentation et les preuves d'accessibilité, et recommande de tracer les modifications contrôlées jusqu'à la couche responsable d'une incohérence.
• Générateurs de design system shadcn/ui : avez-vous besoin d'un thème, d'un système ou d'un handoff pour agent ? : Identity Forge distingue le thème visuel d'un design system plus large et d'un handoff pour agent, et recommande d'inspecter la signification des tokens, la parité des modes, la typographie, les directives de mise en page, les méthodes d'installation et les lacunes connues.

• How To Build a Brand From Scratch (2026): Shopify présente le kit de marque et le guide de style au sein d'un processus plus vaste qui couvre également la recherche d'audience, la voix, le naming, le storytelling, la création du logo, son application et la mesure des résultats.
• What is a Brand? Definition and Examples: Ramotion décrit les composants de marque à travers l'identité visuelle, l'identité verbale, les expériences d'interaction, les valeurs et le positionnement, démontrant qu'une marque s'étend bien au-delà d'un simple logo.
• What is Branding? Understanding Its Importance: HubSpot aborde la stratégie de marque, les assets visuels, la voix et l'application sur les sites web et autres canaux comme faisant partie d'un processus de branding global.
• Ambient Sage Design Kit: Le kit public Ambient Sage documente l'usage de Plus Jakarta Sans pour les titres et le corps de texte, de JetBrains Mono pour le style mono, des design tokens sémantiques (clair et sombre), des directives écrites ainsi que plusieurs formats de livraison pour les développeurs.
• How to generate a DESIGN.md (and what it is): Identity Forge définit DESIGN.md comme un brief de design écrit comprenant l'intention, les systèmes de couleurs et de typographie, les règles de mise en page et d'espacement, le traitement des composants, les motifs et les contraintes d'utilisation explicites.
• Semantic color tokens explained: Identity Forge explique que les tokens sémantiques nomment les couleurs par leur fonction (comme background, foreground, primary, border et ring) plutôt que par leur teinte brute.
• AI UI review checklist: test generated interfaces before you ship: Le guide de revue distingue les exigences produit, l'autorité de design, les livrables, les preuves d'implémentation et les preuves d'accessibilité, et recommande de tracer les modifications contrôlées jusqu'à la couche responsable d'une incohérence.
• Shadcn design system generators: do you need a theme, a system, or an agent handoff?: Identity Forge distingue le thème visuel d'un design system plus large et d'un handoff pour agent, et recommande d'inspecter la signification des tokens, la parité des modes, la typographie, les directives de mise en page, les méthodes d'installation et les lacunes connues.