Specs UI maquettées en Tailwind
Ce skill produit un petit site de specs (une page par écran, publié comme un seul artifact multi-pages) qui sert de référence entre le métier et les développeurs : chaque écran y est maquetté en Tailwind (desktop et mobile), situé dans son parcours et annoté avec ses règles. On itère jusqu'à valider le fonctionnement et le rendu, puis les développements reprennent les mêmes tokens et les mêmes classes.
Documents, libellés, annotations et échanges sont en français. Le code (scripts, attributs, variables, identifiants techniques) est en anglais ; ses commentaires peuvent être en français.
Les specs sont
fonctionnelles et UI : aucun nom de bibliothèque, de fonction, de champ d'API ni de notation technique dans les écrans, les annotations ou les règles (
, « Specs fonctionnelles, sans code »).
désigne le dossier de ce skill : les scripts se lancent avec
depuis le projet de la personne.
Économiser le contexte (à lire en premier)
Un projet de specs grossit vite : un lot d'une dizaine d'écrans en une seule page dépasse 300 Ko. C'est pourquoi les specs sont découpées en pages par écran, et pourquoi il ne faut jamais relire ce qui n'est pas utile. Règles :
- est la mémoire du projet. En reprise, le lire en premier et s'en contenter tant que possible. Il contient les décisions, l'identité, la disposition, les personas, les faits du fil rouge en chaînes exactes (identifiants, libellés, heures : à y ajouter dès qu'un écran en crée), l'inventaire avec les ancres, l'état des lots et leurs URL, les conventions propres au projet, les points ouverts et la prochaine étape. Le créer depuis dès l'étape 1, et le mettre à jour à la fin de chaque étape. Il doit rester sous 200 lignes.
- Ne jamais lire les pages construites (). Les specs vivent dans : un fichier par état d'écran. On lit et modifie seulement les fichiers utiles (
sources/<lot>/070-e15d.html
sources/shared/shells.html
- Relire ses captures en commençant par le moins cher. Lire d'abord les alertes de , puis la planche réduite (, environ 1 000 tokens pour plusieurs écrans), et ouvrir un cadre seul seulement en cas de doute. Les captures de section () coûtent cher : à réserver aux mises en page de document.
- Limiter au travail en cours : pour ne capturer que les écrans modifiés, références du skill lues selon la table ci-dessous.
- Déléguer sobrement, au bon modèle (voir « Répartir le travail entre modèles »). Un sous-agent reçoit le chemin de et sa tâche, pas un résumé de tout le projet. Deux sous-agents en parallèle ne travaillent jamais sur les mêmes fichiers, et l'inventaire révisé (ID, titres, ancres) est écrit dans avant de les lancer.
- Publier seulement ce qui a changé. Tout le projet est un seul artifact multi-pages : liste les pages modifiées depuis la dernière publication, et seules celles-là sont envoyées. Regrouper les retouches avant de publier.
Répartir le travail entre modèles
Écrire ou modifier du HTML d'écran, appliquer une décision, extraire du texte : c'est de l'exécution, qui ne demande pas le modèle le plus capable. Quand l'environnement permet de choisir le modèle d'un sous-agent (paramètre
de l'outil Agent dans Claude Code), répartir ainsi :
| Rôle | Modèle | Tâches |
|---|
| Conception et décision | modèle principal de la session | Cadrage, propositions (disposition + thème), inventaire, fiches d'écran, relecture des planches avec la grille de , dialogue et questions, , publication |
| Rédaction | | Écrire les fichiers d'écran d'un lot à partir des fiches ; appliquer des retours ou des décisions dans les sources ; mutualiser un composant ; migrer un projet |
| Exécution mécanique | | Lancer et et rapporter les alertes ; corriger une pastille ou un lien signalé ; extraire en texte brut les points ouverts, journaux ou inventaires ; renommer en série |
Pourquoi Sonnet pour rédiger : écrire un écran demande de composer une mise en page soignée et de rester fidèle à la fiche, au fil rouge et à la grille de qualité. Haiku y perd en finition et oblige à des allers-retours qui coûtent plus que l'écart de prix. Haiku reste le bon choix pour ce qui ne demande aucun jugement de mise en page : lancer les scripts, extraire, renommer, corriger une pastille ou un lien signalé.
Fiche d'écran : ce que le modèle principal transmet au rédacteur, en 10 à 20 lignes par écran. Elle contient l'ID et les ancres de chaque état, l'objectif et l'usage dominant, le point focal, le contenu exact (faits du fil rouge), les composants et l'écran modèle à reprendre, les annotations à écrire (règle, condition, renvoi), les liens Depuis / Ensuite, et la portée mobile. Plus la fiche est précise, moins le rédacteur a besoin de contexte, et plus il peut être léger.
Le rédacteur ne décide pas : une ambiguïté ou un manque dans la fiche lui fait poser la question dans son compte rendu, pas improviser. Le modèle principal relit toujours les planches avant de publier ; un défaut de conception revient au rédacteur avec une consigne précise.
| Tâche | À lire |
|---|
| Reprise, itération, retouche | , puis les fichiers sources concernés ; §6 si besoin |
| Nouveau lot de specs | , §2 à §6, §9, un écran existant comme modèle, |
| Propositions d'interface | , |
| Site existant | |
| Inventaire, évolution transverse | §1 à §4 |
Fichiers produits
Les trois skills de la chaîne rangent leurs livrables dans un seul dossier
à la racine du projet. C'est aussi le dossier qui vit dans le dépôt de code de l'application pendant les développements :
specs/
├── ui/ ce skill : specs maquettées
├── prototype/ skill prototype-ui (facultatif)
└── requirements/ skill requirements-doc : cahier des charges (facultatif)
specs/ui/
├── CONTEXTE.md mémoire du projet (à jour à chaque étape)
├── tokens.css identité : bloc @theme Tailwind, injecté dans chaque document
├── propositions.html propositions d'interface et décision (jamais supprimé ; copié dans le site)
├── captures/ captures du site existant (étape 1B)
├── assets/ (facultatif) images du produit : logos, illustrations, photos de démonstration
├── sources/
│ ├── site.json titre, introduction, URL de l'artifact, liste ordonnée des lots, dossier des images
│ ├── shared/shells.html coquilles <template id="tpl-shell-…"> communes à tous les lots
│ └── <lot>/ lot.json, 000-header.html, NNN-<id>.html (un état d'écran par fichier), templates.html
└── site/ construit par build.mjs, ne pas modifier à la main :
index.html (accueil), <lot>/index.html (en-tête, règles, écrans, points ouverts,
journal), <lot>/eN.html (une page par écran, tous ses états), propositions.html,
assets/ (les images citées par les pages)
Images du produit. Un logo, une mascotte, une illustration ou un insigne que l'interface affiche se montre dans la maquette, pas une forme de couleur qui le remplace : sans lui, l'écran ne se reconnaît pas. Les sources citent l'image par
; dans un projet qui a déjà ses images (application existante),
→
désigne leur dossier (chemin relatif à
, par exemple
"../../apps/web/public/assets"
) plutôt que de les copier.
copie dans
les seules images citées, et
les publie avec les pages (
§7).
Les captures de vérification vont dans un dossier temporaire (le scratchpad de la session s'il existe), jamais dans le projet.
Dans un dépôt git, on commite les sources et
, qui dit ce qui est publié, mais
pas le site construit : le build est déterministe et prend quelques secondes, et l'équipe lit les specs dans l'artifact publié. Dans le
du projet :
, puis
!specs/ui/site/.published.json
. Sur un clone neuf, lancer
avant
. Ne versionner le site que si l'équipe doit lire le HTML sans rien construire ni ouvrir l'artifact. Les captures et les dossiers de publication restent hors du dépôt.
Ressources du skill
| Fichier | Rôle |
|---|
| Tokens, cadres, blocs réutilisables, annotations, catalogue de composants |
| Principes de qualité UI et grille de revue avant publication |
references/propositions.md
| Construire trois propositions (disposition + thème) |
references/site-existant.md
| Fonctionnalité ajoutée à un site ou une application existante |
references/redaction-specs.md
| Inventaire, anatomie d'un écran, états, itérations, évolutions transverses |
| Squelette d'un document de specs : habillage, script, deux écrans d'exemple |
templates/propositions.html
| Page de comparaison : trois dispositions, trois thèmes, combinables en direct |
| , | Fichier d'identité, mémoire du projet |
| Construit le site depuis les sources : pages, liens entre pages, tokens, coquilles, habillage, typographie ; liste les pages modifiées |
| Crée un lot (--new <lot> --root specs/ui
|
| Contrôles d'un fichier ou de tout le site ; images : , , , , , |
scripts/check-contrast.mjs
| Contrôle WCAG AA des tokens |
scripts/prepare-publish.mjs
| Prépare la publication du site (page principale + pages modifiées) ou d'un document isolé ; dit si l'artifact est en retard sur le site local |
scripts/migrate-layout.mjs
| Range un projet à l'ancienne disposition (, , côte à côte) dans |
scripts/extract-identity.mjs
| Identité d'un site (URL) ou d'un code (dossier), captures |
| Met un document ancien (sans sources) au niveau des templates, sans toucher aux maquettes |
| Typographie française (appliquée automatiquement par ) |
scripts/export-design-system.mjs
| (Facultatif) Prépare un dossier Design System Claude Design : tokens, fondations, composants, README |
scripts/design-sync-package.mjs
| (Facultatif) Crée le paquet « tokens seuls » envoyé à Claude Design par |
templates/design-system.html
| Catalogue de composants exporté vers le Design System |
| Modèles du paquet : , brouillon de conventions, notes de synchronisation |
Les templates contiennent un produit fictif (« Orbe », demandes clients) qui ne sert qu'à montrer le format : en remplacer tout le contenu.
Où poser les questions. Une question ne doit jamais exister seulement dans la conversation. Les choix fermés passent par l'outil de questions interactives s'il existe (AskUserQuestion), avec une option recommandée. Tout ce qui attend une réponse est aussi reporté dans le document publié (« À valider » des propositions, « Points ouverts » des specs) et dans
. Le message annonce ce qui est attendu.
Étape 0 · Cadrer
- Reprise ? Si existe, lire et reprendre à l'étape utile. Un projet à l'ancienne disposition ( à la racine, versions 2.x) se range d'abord avec
node <skill>/scripts/migrate-layout.mjs <projet>
- sur chaque document de specs, dans l'ordre des lots ;
- ranger les anciens documents dans ;
- , puis contrôle avec
capture.mjs specs/ui/site <tmp>
- rédiger en extrayant le texte des points ouverts et des journaux, plutôt qu'en lisant les pages ;
- publier le site comme un nouvel artifact, et noter les anciens artifacts comme remplacés.
- Origine de l'identité, déduite de la conversation : à définir → étape 1A ; site ou code existant → étape 1B ; fournie (charte, design system, tokens) → directement, puis étape 2. Si la personne dispose d'un Design System Claude Design et souhaite partir de celui-ci (c'est facultatif, le proposer seulement s'il existe), le lire (outil Artifact : avec le type « Design System », puis du README et des tokens) et le traduire en et en coquilles : l'étape 1A devient inutile.
- Besoin fonctionnel : objectif, utilisateurs, règles, documents fournis. Un brief qui s'appuie sur une bibliothèque ou une documentation se lit avant de concevoir, puis se traduit en vocabulaire fonctionnel ( §1). La bibliothèque n'apparaît jamais dans les specs.
S'il manque des informations, les demander toutes dans un seul message. Si le brief suffit, ne rien demander : écrire les hypothèses et produire. Sans nom de produit, en choisir un provisoire et le signaler.
Étape 1A · Trois propositions : disposition + thème
Suivre
references/propositions.md
. Une proposition associe une
disposition (navigation, organisation, manière de travailler) et un
thème (palette, typographie, formes, densité). Les trois propositions diffèrent sur les deux plans, sur le
même écran représentatif, avec le même contenu réel, desktop et mobile. Partir de
templates/propositions.html
: chaque disposition a son balisage, et des boutons appliquent n'importe quel thème à n'importe quelle disposition.
Vérifier :
, puis
(test de la vignette : les trois dispositions se distinguent au premier coup d'œil),
sur deux ou trois combinaisons, et la grille de
. Publier, puis demander un choix : une lettre, une combinaison ou des retouches.
Présenter au même point d'arrêt l'inventaire de l'étape 2 dans la section « À valider ».
Après un retour (« A et C se ressemblent »), refaire l'étape dans le même fichier et le même artifact, avec un encadré « Depuis la version précédente ». Une fois le choix fait :
- figer le thème dans (source, date, contrastes revérifiés) et la disposition dans
sources/shared/shells.html
- ajouter à un encadré « Décision » et marquer « À valider » comme tranché. Ne jamais supprimer .
Un choix composite se reformule précisément avant d'être appliqué. S'il reste ambigu sans moyen de demander, retenir l'interprétation la plus plausible, l'écrire comme hypothèse et la poser en première question.
Étape 1B · Reprendre un site existant
Suivre
references/site-existant.md
:
extract-identity.mjs <url> --screenshots specs/ui/captures
(ou un dossier de code), croiser le rapport avec les captures, écrire
avec les valeurs exactes et leur origine, puis reproduire une page en
E0 · Existant à côté de sa capture et faire valider la fidélité. Si l'emplacement de la fonctionnalité est incertain, proposer deux ou trois dispositions d'intégration.
Étape 2 · Inventaire des écrans
Suivre
references/redaction-specs.md
§1. Avant toute maquette, présenter le tableau des écrans (ID, objectif, états), les parcours, les règles comprises, les hypothèses et deux ou trois questions au plus. L'écrire aussi dans le document publié et dans
, avec l'ancre de chaque écran. Attendre la validation. Un brief large se découpe en
lots (un document par lot, numérotation globale) ; commencer par celui qui fixe la coquille. Le mobile est maquetté pour chaque écran, sauf portée réduite acceptée par la personne.
Étape 3 · Écrire les specs (sources par écran)
Créer un lot :
bash
node <skill>/scripts/split.mjs --new <lot> --root specs/ui # → sources/<lot>/, inscrit dans sources/site.json
Dans un projet qui a déjà ses coquilles, le lot démarre d'un squelette vide (en-tête, règles, points ouverts, journal à remplir, annexe d'identité reprise d'un lot existant) : partir des écrans modèles cités dans
.
Puis, dans
:
- renseigner : (« Lot 2 · Projets et dépôts »), , , (titre court de chaque écran :
{ "e4": "Assistant de création" }
- renseigner l'en-tête () : contexte, règles, parcours ;
- écrire un fichier par état d'écran (, …) en remplaçant les écrans d'exemple. Les sections d'un même écran forment une page ; les autres sections (règles, points ouverts, journal, annexe) vont sur l'index du lot.
Un lot peut n'avoir aucun écran : une revue des points ouverts ou une liste de décisions à prendre, faite seulement de sections (tableaux à annoter avec « Retours »), avec
dans
pour sa carte sur l'accueil.
Les coquilles se modifient une seule fois dans
, pour tous les lots ; les composants communs à plusieurs lots (en-tête de projet…) vont dans
sources/shared/components.html
. Les fonds de calque et contenus réutilisés vont dans
. Les liens s'écrivent simplement (
,
,
) : le build les réécrit vers la bonne page.
Construire après chaque série de modifications :
bash
node <skill>/scripts/build.mjs specs/ui
produit
: il injecte
, les coquilles utiles à chaque page, l'habillage et le script du template à jour, ajoute la navigation entre écrans, réécrit les liens et applique la typographie française. Les pages construites n'ont jamais besoin de mise à niveau. Il signale les liens non résolus et liste les pages modifiées.
Contenu : suivre
(tokens uniquement, catalogue de composants, annotations) et
(usage dominant, point focal, hiérarchie). Chaque écran comporte un ID, un titre, un badge, une note, « Depuis / Ensuite », une maquette desktop, une maquette mobile repensée et 3 à 6 annotations. Écrire l'en-tête et le premier écran, construire, vérifier, puis la suite.
Étape 4 · Vérifier, puis publier
bash
node <skill>/scripts/capture.mjs specs/ui/site <tmp>/captures # contrôles seuls, aucune image
node <skill>/scripts/capture.mjs specs/ui/site <tmp>/captures --sheet --ids e4,e5 # planches des écrans touchés
Le script signale la version du template, les icônes inconnues, les blocs non assemblés, le contenu coupé et les
pastilles posées sur du texte ou coupées par un bord (avec le cadre, le numéro et le texte recouvert). Corriger ces alertes, relire les planches avec la grille de
§9, ouvrir un cadre seul (
) seulement en cas de doute, puis corriger les trois défauts les plus visibles et recapturer les écrans touchés. Cette boucle prime sur toute consigne générale de vérification unique. Sans navigateur, le dire.
Publier (outil Artifact s'il existe ; les fichiers locaux font foi). Tout le projet est un seul artifact multi-pages :
bash
node <skill>/scripts/prepare-publish.mjs specs/ui/site <tmp>/publish # page principale + pages à envoyer
- Passer à l'outil Artifact la page principale préparée () et la table affichée par le script : chemin publié → fichier de . Les pages secondaires sont des documents complets ; les liens relatifs entre pages fonctionnent tels quels.
- Première publication : toutes les pages (). Ensuite, seules les pages modifiées depuis la dernière publication ; les autres restent en ligne. Un artifact introuvable (supprimé, ou publié depuis un autre compte claude.ai) se remplace par un nouveau : publier avec , puis remplacer l'URL partout (, , configurations du prototype et du cahier des charges, README du projet) en notant l'ancienne comme remplacée. Avec , l'outil peut exiger d'avoir vu la liste des fichiers : demander la liste () plutôt que de relire les pages.
- Après une publication réussie :
prepare-publish.mjs specs/ui/site --confirm
- Respecter les règles de l'outil Artifact pour la publication ; titre de deux à quatre mots.
Terminer par le chemin, le lien, un résumé court et les décisions attendues, et rappeler comment faire des retours : bouton « Retours » sur chaque page, puis coller l'export (voir « Retours de relecture » à l'étape 5). Mettre
à jour.
Étape 5 · Itérer
Suivre
§6. Pour chaque retour :
- modifier seulement les sources concernées (et celles qu'elles impactent) en gardant les identifiants stables, puis reconstruire ;
- incrémenter l'itération, ajouter une entrée au journal, mettre à jour les points ouverts ;
- vérifier, republier, mettre à jour .
Selon le type de changement :
- identité : passe par , puis reconstruire ;
- coquille : se fait dans , puis reconstruire (c'est une maintenance, pas une itération) ;
- disposition d'un écran qui fait débat : maquetter des variantes / côte à côte ;
- évolution transverse : analyse d'impact, décisions, inventaire révisé dans et les propositions, puis production en commençant par le lot qui la porte.
Retours de relecture
Chaque page du site porte un bouton
« Retours » (habillage du document, absent des captures et de l'impression). La personne qui relit passe en mode « Annoter », clique sur l'endroit d'une maquette ou d'un texte (règle, annotation, point ouvert) et écrit une
correction à faire ou une
question. Chaque retour est repéré à l'endroit cliqué (R1, R2…), gardé dans son navigateur seulement, puis exporté en Markdown et collé dans la conversation : « Copier l'export », « Afficher l'export » (grande fenêtre de lecture, avec copie et sélection du texte quand le presse-papiers est refusé) et, hors artifact, « Télécharger » (une page publiée dans un artifact ne peut pas déclencher de téléchargement). L'export regroupe les retours par état d'écran et cite pour chacun le fichier source (
sources/<lot>/NNN-<id>.html
, inscrit par
dans chaque section), le cadre (
), la position dans le cadre et le texte visé.
Pour traiter un export :
- Ne lire que l'export, puis les seuls fichiers sources qu'il cite. Repérer l'élément par le texte cité, le cadre et la position (en % de la largeur et de la hauteur du cadre) ; jamais de relecture des pages construites.
- Correction claire et compatible avec les règles et décisions : l'appliquer dans la source. Correction ambiguë, qui contredit une règle, une décision de ou un autre écran : la poser à la personne (outil de questions, choix fermés) plutôt que d'improviser.
- Question : y répondre dans la conversation ; si elle appelle une décision, l'ajouter aux points ouverts du lot (et à ) avec une recommandation.
- Une itération par série de retours : journal du lot qui cite les retours traités (« R1, R3 : … »), reconstruire, capturer les écrans touchés (), republier les pages modifiées.
- Répondre par un tableau
Retour | Suite donnée | Écran
Les retours restent dans le navigateur de chaque personne : plusieurs relecteurs exportent chacun les leurs (le nom saisi les signe). Un retour sur un écran déjà livré (statut d'implémentation) suit la boucle de l'étape 7 : il change aussi le code, ou devient un écart.
Option · Design System Claude Design
Fonctionnalité
facultative : chaque personne décide de l'utiliser ou non. La proposer une fois, par une question fermée (« Exporter l'identité vers un Design System Claude Design ? » Oui / Non / Plus tard), juste après la décision de l'étape 1A ou à l'étape 6, et noter la réponse dans
(section « Préférences ») pour ne pas la reposer. Ne jamais l'exporter sans accord.
Si la réponse est oui, deux temps.
bash
node <skill>/scripts/export-design-system.mjs specs/ui
Il contient le README (thème, vocabulaire des tokens, règles d'usage),
, les fondations (couleurs, typographie, formes), les composants du catalogue et ceux du projet (
). Chaque fiche porte le marqueur de carte de Claude Design.
2. Le paquet « tokens seuls » (
specs/design-system-package/
, à côté de
). Claude Design construit en React à partir d'un paquet : comme les specs n'ont pas de composants React, on lui envoie l'identité sous forme de tokens et de classes utilitaires. Les fiches du catalogue deviennent les cartes visibles du projet.
bash
node <skill>/scripts/design-sync-package.mjs specs/ui
cd design-system-package && npm install && npm run build
- Compléter
.design-sync/conventions.md
- La personne lance ensuite depuis ce dossier, et accorde l'accès avec si on le lui demande. Ce skill n'envoie rien lui-même.
- Les étapes de reconstruction et les pièges connus sont dans .
Après une évolution de l'identité ou des composants partagés : relancer l'export, puis
dans le paquet, puis
.
Étape 6 · Passer aux développements
Vérifier qu'aucun point ouvert ne bloque, activer le statut d'implémentation (étape 7), proposer l'export Design System si la personne ne s'est pas encore prononcée (voir l'option ci-dessus), proposer l'inventaire des composants récurrents, et rappeler que
se colle tel quel après
. Sur demande, découper en stories avec les annotations comme critères d'acceptation.
Pour faire tester les parcours ou les montrer avant de développer, le skill
transforme ces specs en prototype cliquable (mêmes écrans, données simulées, scénarios de test). Pour lancer les développements, le skill
en tire le cahier des charges de l'équipe (specs par lot avec critères d'acceptation, architecture, stack, infrastructure, lots et estimations).
Étape 7 · Maintenir pendant les développements
Une fois les développements lancés, les specs restent
la référence : elles décrivent ce que l'application fait, écran par écran, et suivent l'implémentation. Le dossier
vit dans le dépôt de l'application.
Statut d'implémentation. L'activer dans
(
), puis le tenir à jour dans le
de chaque lot :
json
"status": { "e1": "done", "e2": "doing", "e3": { "status": "gap", "note": "Codex pas encore pris en charge" } }
- Valeurs : (À développer, par défaut), (En cours), (Livré), (Écart : l'application diffère des specs ; la note dit en quoi).
- Le build remplace le badge « Nouveau » de chaque état par le statut, met une pastille dans la navigation et affiche l'avancement sur l'index des lots et l'accueil. Le cahier des charges reprend les statuts à l'extraction.
Un écart constaté pendant le développement se tranche, puis se reporte dans le même changement que le code (même branche, même PR) :
- Le code a raison (contrainte technique, meilleure idée validée) : modifier les sources de l'écran, incrémenter l'itération et noter au journal du lot « aligné sur l'implémentation », avec la raison. Garder les identifiants (écrans, états, numéros de règles) : le code et les tests les citent.
- Les specs ont raison : le code se corrige ; en attendant, statut avec une note.
- Question ouverte : point ouvert du lot et de , statut .
Puis, dans l'ordre :
- reconstruire les specs ;
- reporter l'écart dans le prototype s'il câble l'écran (skill , « Suivre les specs ») ;
- réextraire le cahier des charges et ajuster les critères touchés (skill , « Maintenir ») ;
- publier les artifacts concernés (
prepare-publish.mjs … --check
- commiter les sources et les ensemble (et les sites construits, s'ils sont versionnés).
Numérotation stable. Une règle fonctionnelle garde son numéro : une nouvelle règle va à la fin de la liste, une règle abandonnée reste avec la mention « Retirée ». Un écran ou un état retiré garde son identifiant réservé. Les identifiants RF du cahier des charges viennent de ces numéros.
Ce que ce skill ne fait pas
- Il ne code pas l'application : les maquettes sont statiques, et les specs restent la référence.
- Il ne copie pas l'identité d'un produit tiers : un site extérieur sert d'inspiration de structure, jamais de modèle visuel.