La méthode du site web mémorable : comment j'ai redesigné tout le site de Kai avec Claude, sans Figma
Comment j'ai reconstruit chaque page de hirekai.ai avec Claude Code sur un système de marque pensé pour les agents : la méthode de structure de page, le workflow d'inspiration, les coûts, et les erreurs.
Salut !
Je m’appelle Lambert. J’ai 23 ans et je dirige le growth chez Morgen, où on construit Kai, un assistant exécutif IA.
Il y a quelques mois, j’ai écrit sur le stack du site web AI-Native : base de connaissances, design tokens, Claude Code, Next.js, Vercel. Cet article-là parlait de la machine. Celui-ci parle de la partie que la machine ne te donne pas gratuitement : comment tu fais un site web dont les gens se souviennent vraiment.
Parce que voilà la vérité inconfortable de 2026 : tout le monde shippe vite maintenant. Tout le monde a une landing page propre. Claude peut te sortir un « beau » site SaaS en un après-midi, ce qui veut dire qu’un beau site SaaS ne vaut plus rien. Il ressemble au beau site SaaS de tout le monde.
Je viens de finir de redesigner l’intégralité du site de Kai avec Claude Code, chaque page, sans Figma, alors que le produit est encore en beta. Cet article, c’est la méthode complète : la réflexion, le système de marque qui rend tout possible, mon processus réel, les coûts, et les erreurs.
Cet article est pour toi si :
- Tu construis des sites avec l’IA et ils sortent tous « corrects » et oubliables
- Tu es founder ou marketeur et tu te demandes si la marque vaut l’investissement pré-revenu
- Tu veux une image concrète de ce que « donner ta marque à des agents » veut vraiment dire
- Tu es sur le point de redesigner un site avec Claude et tu veux éviter mes erreurs
C’est parti.
Partie 1 : Mémorable, pas beau
Quand tout le reste est automatisé et que chaque démo produit est impressionnante, il ne reste que deux choses pour se différencier : ta communication et ta marque. Qu’est-ce que les gens ressentent en arrivant sur ton site, et se souviennent-ils de toi une semaine plus tard ?
Il y a une histoire de Steven Bartlett (Diary of a CEO) qui nous a marqués. Le meilleur investissement qu’il ait fait dans sa première agence marketing, c’était un énorme toboggan bleu dans le bureau. Ça n’avait aucun sens. Les gens entraient et demandaient pourquoi il y a un toboggan géant et pas d’écrans. Et c’était exactement le but : si une équipe met autant d’effort dans un toboggan, imagine l’effort qu’elle met dans le vrai travail.
Un site web fonctionne pareil. Quand quelqu’un arrive sur ton site et qu’à chaque scroll il y a un moment qui le fait réagir « attends, c’est cool ça », il se dit : si ces gens soignent autant une page de feature, le produit doit être incroyablement bon. C’est ça le pari. Pas beau. Mémorable.
Le problème : mémorable, c’est exactement ce que l’IA ne te donne pas par défaut. La sortie par défaut de l’IA converge vers la moyenne de tout ce qu’elle a vu. Donc avant de designer la moindre page, il a fallu construire le goût et l’encoder. C’est le système de marque.
Partie 2 : Un système de marque pensé pour les agents
Le projet de marque a tourné avant le redesign, mené par Jim et David avec Dave Officer, le brand designer derrière Doodlejuice. C’est la fondation sur laquelle tout mon processus repose, donc voilà comment ça marche.
Le cerveau d’un designer, versé dans du markdown
David a trouvé Dave sur LinkedIn, via une vidéo où il rebrande une marque de papier toilette. Cette vidéo a suffi : ce gars est créatif, et il ne travaille presque pas dans la tech, donc il n’est pas biaisé par ce à quoi ressemble chaque site SaaS.
Le brief était libre : quelques marques qu’on aimait (PostHog, le site perso de Dave), un adjectif qui revenait tout le temps, familier (ça doit ressembler à un vieil ami que tu n’as pas vu depuis des années), et une mascotte. Dave est revenu avec deux directions complètes : une chaleureuse et dessinée à la main, une plus sombre avec un logo façon fantôme. On a fusionné les deux, le fantôme est devenu la mascotte. Fun fact : pendant un hackathon, les gens répétaient qu’il manquait quelque chose au logo, alors Dave a ouvert Paint, ajouté deux yeux, et le personnage de Kai était né.
Puis la partie inhabituelle. Au lieu du classique PDF de marque de 50 pages que personne ne rouvre jamais, on a demandé à Dave des instructions pour agents : pour chaque asset, écrire en texte brut pourquoi il l’a fait et comment. L’idée, le processus créatif, les règles.
Ce qui a atterri dans le repo, c’est 13 fichiers markdown. Pas des maquettes. Des règles :
- La palette de couleurs : chaque couleur avec son token CSS exact, et des règles dures comme « on utilise du crème, jamais du blanc », avec le raisonnement écrit.
- La typographie : trois polices et la logique derrière chacune. Notre police display MONTI a une règle spéciale : quand un texte est en MONTI, c’est Kai lui-même qui parle.
- La mascotte : 25 états sur deux modes de rendu, avec un doc de personnalité qui définit où s’arrête la chaleur et où commence l’insolence.
- Système de logo, ton de voix, manifeste, pensée de campagne : le « pourquoi » derrière tout, pas juste les assets.
Quand Claude lit « crème, jamais blanc » à côté de la valeur exacte du token, il arrête de deviner. C’est là qu’une marque devient de l’infrastructure.
Les pipelines de génération
Dave est freelance : il livre le système et passe à autre chose. Pour garder sa patte sans le garder sur la masse salariale, l’équipe a construit des pipelines par-dessus ses fichiers :
- Des LoRA Flux entraînés sur fal.ai sur ses 14 icônes marketing et ses 12 illustrations dessinées à la main. Tu promptes « illustration dessinée à la main d’une tasse de thé », tu récupères quatre variantes on-brand en trois minutes, pour environ 0,05 $ par asset.
- Un compositeur d’icônes déterministe : n’importe quelle icône d’une bibliothèque ouverte, redessinée avec exactement le traitement de Dave. Ses 22 icônes dessinées à la main sont devenues 137.
- Un rig Lottie avec la géométrie de la mascotte verrouillée dans le code : décris un mouvement (« Kai fait un move de breakdance »), obtiens une animation parfaitement on-brand.
Résultat concret : quand on a invité les 1 000 premières personnes de notre waitlist, l’email contenait une illustration custom d’une porte qui s’ouvre avec Kai qui dit « You made it, come on in », en MONTI. Chaque élément généré par les pipelines, indiscernable de la main de Dave.
C’est cette machine que j’avais entre les mains quand le redesign a commencé. Maintenant, ma partie.
Partie 3 : Le redesign, étape par étape
J’ai redesigné chaque page de hirekai.ai avec Claude Code. Prévu : 4 à 5 jours. Réalité : environ 10. Voici le processus que je recommanderais, qui n’est pas exactement l’ordre que j’ai suivi :
1. Verrouille la carte du site
Kai touche aux calendriers, aux emails, aux réunions, aux tâches, aux intégrations. Le premier vrai travail a été de décider quelles pages devaient même exister, à quoi ressemble la nav, et quel job a chaque page. Nos anciennes pages de features avaient été écrites trois mois plus tôt et le produit les avait déjà dépassées. Aucun design ne répare une page qui décrit le mauvais produit.
On l’a fait en doc, on s’est disputés dessus, et on l’a verrouillé. Ennuyeux. Essentiel.
2. Écris l’histoire de chaque page, de haut en bas
C’est l’étape que je mettrais en gras si je ne pouvais en garder qu’une. Avant d’ouvrir le moindre composant, j’écris la structure d’information de la page : qu’est-ce que le visiteur doit comprendre en premier, en deuxième, en troisième, à mesure qu’il descend ? Pas des blocs. Pas des layouts. L’ordre de l’information.
Prends notre page réunions. L’histoire que j’ai verrouillée avant de designer : un court résumé de ce que Kai fait avec tes réunions, puis ce qui se passe avant la réunion (la préparation), puis pendant (transcription, notes), puis après (récap, action items), puis les follow-ups. C’est l’ordre dans lequel le job se déroule dans la vraie vie, donc c’est l’ordre dans lequel la page le raconte. Et la mascotte t’accompagne : Kai apparaît le long de la page comme le guide de la visite.
Une fois que cette structure existe en texte, deux choses se produisent. Chaque bloc a un job précis (« montrer ce qui se passe après la réunion »), ce qui rend le brief de design pour Claude dix fois plus net que « fais une belle section ». Et tu peux juger un bloc objectivement : s’il ne fait pas avancer l’histoire, c’est de la décoration, et il dégage.
3. Construis un swipe file, avec l’IA qui fait le gros du travail
Mémorable ne veut pas dire inventé de zéro. Avant et pendant le design, j’ai construit un swipe file de sites et de blocs qui m’ont fait ressentir quelque chose, et j’ai utilisé l’IA pour rendre cette collection grande et pas chère :
- Le deep research de Claude pour balayer le web à la recherche de sites SaaS et studios mémorables, avec le brief « des sites que les gens screenshotent et partagent, pas des sites qui gagnent des awards ».
- Le MCP Mobbin branché dans Claude, pour chercher de vrais écrans et flows de production par pattern, directement depuis la conversation où je designais.
- Ma propre pile de favoris, accumulée depuis des mois : Gumroad, Tally, Vellum, Town, Flying Papers, Get Hyped, 30 Minutes to President’s Club, Perfect Wiki, Byooooob. Des produits complètement différents, la même propriété : tu t’en souviens.
La règle qui rend un swipe file sûr quand ta marque est verrouillée : vole la structure et l’interaction, jamais le style. La palette, la typo, la mascotte sont non négociables, elles viennent des fichiers de marque. Ce que je prends d’un bloc inspirant, c’est sa façon de séquencer l’information, un comportement de scroll, un rythme de layout. Claude reconstruit ensuite l’idée dans nos tokens, donc elle atterrit on-brand par construction.
4. Designe les blocs librement. Le design system vient en DERNIER
C’était ma plus grosse erreur. J’ai commencé par construire un design system, parce que c’est ce qu’on est censé faire. Quelques jours plus tard, le résultat était générique. Voilà pourquoi : un design system est l’ennemi du mémorable quand tu le construis en premier. Si chaque page assemble les mêmes blocs réutilisables, chaque page se ressemble, et tu as automatisé ton retour vers un site oubliable.
L’ordre qui marche : designer librement, polir les blocs page par page jusqu’à ce qu’ils soient uniques et excellents, et extraire le système après, une fois que tu sais ce qui mérite d’être systématisé. Le compromis sur lequel j’ai atterri : un petit bac à sable où je designe des blocs contre les tokens de la marque, puis je les importe dans les pages. La liberté d’abord, la convergence ensuite.
Ma barre de qualité était simple : à chaque scroll, il me faut un petit moment « wow ». Si un bloc ne me fait rien ressentir, il repart en chantier. Certains blocs m’ont pris deux ou trois heures et des dizaines d’itérations avec Claude. Il existe une version sombre complète du site et une version colorée complète que personne ne verra jamais. Ce n’est pas du gâchis. C’est le vrai coût du goût, et aux prix de Claude, il n’a jamais été aussi bas.
Une astuce qui a rendu les blocs meilleurs : chaque bloc doit dire quelque chose sur le produit. Un bloc magnifique qui ne communique rien, c’est de la décoration. Les meilleurs blocs de notre site montrent Kai en train de faire le vrai boulot : tu dors, Kai lit un email, prépare la réponse, et te le raconte au matin.
5. Écris tes règles de design en texte
Au fil des décisions, je les ai écrites comme des règles dans le repo, même philosophie que les fichiers de marque de Dave : MONTI veut dire que Kai parle. Maximum un badge « pill » par page. Toutes les FAQ partagent exactement le même style. Et ainsi de suite.
6. Laisse Claude auditer le site contre les règles
Puis la récompense : j’ai demandé à Claude d’auditer le site entier contre le fichier de règles. Il a attrapé chaque incohérence que j’avais introduite pendant dix jours d’itération. Cette boucle (règles en markdown, agent qui audite le site) est la partie la plus AI-native de tout le projet, et tu ne peux pas la faire si tes règles vivent dans ta tête ou dans Figma.
7. Shippe tout d’un coup
Pas de déploiement page par page au goutte-à-goutte. Un seul merge : toutes les pages, la nouvelle nav, les nouveaux blocs. Avant ça : passe mobile, passe performance (les Lottie et les gros aplats de couleur sont lourds), passe SEO (liens internes, métadonnées, redirections). La même discipline que n’importe quelle migration, parce qu’un redesign qui coule ton référencement est un redesign très cher.
Et la méta-leçon qui explique mes 10-jours-au-lieu-de-5 : n’itère pas seul. J’ai poli des blocs pendant des jours sans rien montrer, et tu perds la capacité de distinguer « bon » de « j’ai trop fixé ce truc ». Le correctif de David : quand tu es bloqué, mets-le de côté et passe à un autre projet jusqu’à ce que quelqu’un puisse te donner un vrai feedback. Mieux : un point quotidien où l’équipe voit le lien de preview, quel que soit son état. À la vitesse de l’IA, une boucle de feedback qui se mesure en jours devient le goulot d’étranglement.
Partie 4 : Ce que ça a coûté, honnêtement
Des reçus, parce qu’une méthode sans chiffres, c’est un poster de motivation :
- Timeline : décision du rebrand le 13 avril. Système de Dave livré le 13 mai. Marque en ligne sur le site le 14 mai, en une seule pull request. Redesign complet du site shippé en juin. À peu près deux mois entre « il nous faut une marque » et un site live entièrement redesigné.
- Avant : ~10 600 lignes de CSS par page contre ~500 partagées. 17 styles de cartes différents, 13 variantes de boutons, trois copies du même CTA. Claude « réparait » un composant et la réparation ne se propageait nulle part.
- Après : un fichier de tokens comme source de vérité et une bibliothèque de 76 blocs répartis en 12 familles.
- Coût des assets : environ 0,05 $ par image générée, 0 $ par icône composée ou animation.
- Ce qui est encore moche : pendant des semaines après le rebrand, la migration n’était faite qu’à ~60 %, avec des centaines de tokens de couleur legacy encore porteurs dans le code. Shipper la marque et finir la migration sont deux projets différents, et le second est facile à repousser pour toujours.
Le site est en ligne sur hirekai.ai. Juge par toi-même si on a passé la barre du mémorable.
Le premier verdict spontané est venu d’un inconnu sur Reddit, dans un thread qui n’avait rien à voir avec nous :
La méthode, compressée
- Vise mémorable, pas beau. Beau est gratuit maintenant, donc ça ne vaut rien.
- Fais construire la fondation par un vrai créatif. L’IA scale le goût, elle ne le crée pas.
- Change le livrable : le raisonnement créatif et les règles en markdown, pas un PDF.
- Construis des pipelines de génération par-dessus pour que la marque produise des assets pour toujours, pour quelques centimes.
- Verrouille la carte du site, puis écris l’histoire de chaque page de haut en bas avant de designer quoi que ce soit.
- Construis un swipe file avec le deep research + Mobbin ; vole la structure, jamais le style.
- Le design system en DERNIER. Un wow par scroll. Les règles en texte, des audits par agent, tout shipper d’un coup.
- Prends du feedback tous les jours. L’itération en solo est le vrai centre de coût, pas les tokens.
On raconte toute l’histoire, avec les vrais écrans, dans les épisodes 4 et 5 de How We Grow, l’émission hebdo où Jim et moi documentons comment on fait grandir Kai depuis zéro. Viens dire bonjour.
Si tu construis quelque chose de similaire, ou si tu penses qu’investir dans la marque pré-revenu est stupide, dis-moi pourquoi : LinkedIn.