Le génératif normalise, par nature
Le mécanisme des outils génératifs est presque toujours le même : une interaction = une réponse. Sans contexte persistant, le modèle optimise pour le plus probable, et il normalise : menu en haut, scroll fluide, rubriques « Accueil / À propos / Contact ». Dans beaucoup de projets, c'est très bien. Mais quand l'objectif n'est pas d'être standard, chaque nouvelle génération tire le projet vers le générique.
Et le problème s'aggrave à plusieurs : versions contradictoires de l'intention, règles d'interface qui changent selon l'écran généré, direction artistique qui se dilue parce que chaque prompt ré-explique le monde. Résultat connu : plus on génère, plus on retouche. Et souvent, on retouche pour revenir à ce qu'on avait décidé au départ.
Le vrai levier n'est pas d'écrire de meilleurs prompts, ni d'empiler des consignes à chaque génération. C'est d'avoir un système qui empêche ce qui est singulier de redevenir générique.
La méthode en trois temps
Dans ce projet, BAM n'a pas « fait des maquettes ». Il a servi à trois choses très concrètes, avant d'ouvrir l'outil de production :
Intention, architecture d'information, règles d'interface, modèles de contenu, exceptions assumées : tout est décidé et documenté en amont.
Parcours, contenus, règles d'interface et direction visuelle ne sont pas des listes séparées : chaque décision sait à quoi elle sert.
Claude Design et Claude Code reçoivent une direction claire et la matérialisent. L'humain valide chaque étape.
BAM ne remplace pas Claude Design ni Claude Code. BAM fait en sorte que Claude ne tombe pas dans la normalité, et suive l'intention du projet à chaque étape.
Cas réel : une visite, pas un site
L'expérience « je suis tous » est organisée comme une exposition : des salles numérotées de 0 à 4, une barre de progression fixe en bas, un couloir qui séquence volontairement la lecture, des Notes en panneau permanent (logique cartel / audioguide) et un code couleur qui porte la thèse (rouge = accès au rôle, bleu = droit à l'opacité). Autant de décisions qu'un générateur, livré à lui-même, aurait « corrigées ». Voici ce que la mémoire de projet a préservé :
Le point commun de ces cinq lignes : aucune n'est un détail à répéter dans chaque prompt. Ce sont des décisions stables, documentées dans la mémoire de projet, transmises une fois et vérifiables écran par écran. Le récit complet est dans l'article Medium d'origine.
Pourquoi l'humain garde la main
Même avec une source de vérité, un modèle peut proposer des solutions convenues, lisser une exception créative, revenir à des réflexes web standards. La différence, c'est que les règles ne sont plus « dans la tête de quelqu'un » ou « dans un prompt du mois dernier » : elles sont documentées, vérifiables, réutilisables et surtout arbitrables.
- Certaines imperfections sont des choix de lecture. Le couloir qui casse le scroll n'est pas une anomalie à corriger : c'est du sens.
- Chaque exception est justifiée par écrit. Un anti-pattern assumé et documenté ne sera pas « réparé » à la génération suivante.
- Les points de validation sont posés d'avance. Ce que l'humain doit revoir, arbitrer et confirmer fait partie de la méthode, pas de l'improvisation.
Les prompts qui font le pont
Le passage de BAM à Claude Code se fait par des livrables demandés à JOHANNES. Quatre prompts pour les obtenir, à adapter à votre projet :
- « En tenant compte des facteurs clés de succès de la marque et de notre stratégie, proposez-moi un design system simple et compréhensible pour Claude Code. »
- « Résumez notre mémoire de projet (intention, règles de parcours, exceptions assumées, modèles de contenu) en un document de cadrage que je peux donner tel quel à Claude Code. »
- « Rédigez la charte de nos couleurs sémantiques : pour chaque couleur, sa signification et sa règle d'usage, valables sur tous les écrans. »
- « Voici un écran généré par Claude en pièce jointe. Vérifiez-le contre nos règles de projet : qu'est-ce qui a été normalisé ? »
Le premier prompt est celui du cas réel : c'est lui qui a produit le design system transmis à Claude Code. Notez la logique commune aux quatre : on ne demande pas un écran, on demande le document qui cadrera tous les écrans.
Avant de générer : la checklist
Cette méthode se réutilise sur n'importe quel projet produit avec un outil génératif : site, expérience, identité, présentation. Nous l'avons condensée en une checklist à remplir avant d'ouvrir Claude : intention, règles, exceptions, modèles de contenu, langage visuel, points de validation.
À garder sous la main : la checklist L'intention avant la génération, dans les modèles de l'Académie.