Making-of · 12 min de lecture
Conçu avec Claude
Comment ce portfolio a été conçu en binôme avec une IA — et où j'ai repris les rênes
Ce site est mon premier projet IA. Pas une démo générée à la chaîne : un vrai exercice de direction artistique, où j'ai briefé Claude, validé, recadré, et codé moi-même quand il fallait reprendre la main.
01 Pourquoi raconter ça
Diriger l'IA, pas l'utiliser
Parce qu’aujourd’hui, « j’ai utilisé une IA » n’a plus aucune valeur. Tout le monde l’a fait. Ce qui distingue, c’est savoir la diriger — choisir ce qu’on lui délègue, ce qu’on garde sous la main, quand recadrer, quand laisser filer.
Ce portfolio est mon premier projet construit avec Claude Code comme binôme. La machine a écrit du code, j’ai fait toutes les décisions. À la fin, le site est entièrement à mon image — parce que c’est moi qui ai tenu la direction artistique, ligne par ligne. L’IA n’a pas remplacé un designer. Elle a remplacé l’attente qu’on a habituellement entre l’intention et l’exécution.
Je ne conçois pas des interfaces avec l’IA. Je conçois avec l’IA des expériences de marque complètes — et je ne demande à l’IA que ce que je sais juger.
02 La méthode
Tout tient en trois fichiers
Pas d'agents complexes, pas de RAG, pas de pipeline obscure. Un humain qui sait ce qu'il veut, une IA qui sait l'écrire vite.
1. CLAUDE.md à la racine. Une longue note dense — vision, stack, identité, architecture, phases, conventions. C’est ce que Claude Code lit en premier à chaque session. Sans ça, il invente. Avec ça, il sait à quoi il s’attaque.
2. Skills custom dans .claude/skills/ — design-system, i18n, case-study, motion. Une skill, c’est un document précis sur une chose. Claude Code ne le charge que quand il en a besoin (par exemple, le skill motion se charge quand je touche à GSAP). Ça évite de saturer sa mémoire avec tout, tout le temps.
3. Le repo Git lui-même. Chaque phase de la roadmap = un commit validé par moi. Si quelque chose tourne mal, je sais exactement où revenir.
03 La construction
Phase par phase
Sept phases, chacune un commit validé. Le site déployé live dès la phase 1.
00 Phase 0
La vision et le design system
Avant une ligne de code, deux heures de brainstorming stratégique avec Claude. Pas pour qu’il décide — pour structurer ce que j’avais en tête. Audience, ton, positionnement, contraintes. À la fin, on avait CLAUDE.md.
Puis le design system : palette noir / blanc / jaune, Anton + Inter + Fraunces, une échelle d’espacement, des règles de motion. Transposé de mon ancien site Wix, mais affirmé — plus de contraintes de template.
Où j’ai repris les rênes : la palette. Claude Code proposait quelque chose de plus « tech start-up ». Le jaune signature, c’est moi. Une intuition de designer qu’aucune IA ne peut deviner depuis une description.
01 Phase 1
Le setup technique
Astro 6 (statique, performant, Markdown-friendly), Tailwind 4, GSAP + Lenis, Vercel. En une session, le site était en ligne avec une URL live — vide mais déployé. Voir l’évolution en ligne à chaque commit a été un levier de motivation énorme.
Ce qui a marqué : le moment où Claude Code a écrit astro.config.mjs avec l’i18n configuré pour FR/EN/ES en une fois, sans que j’aie à chercher dans la doc. C’est ça, le gain réel — pas la créativité, l’absence de friction technique.
02 Phase 2
L'architecture de contenu
Schémas Zod pour les case studies, sous-dossier par langue pour les collections multi-docs, fichier à plat pour les single-docs (about, making-of). Création des skills case-study et i18n.
Où j’ai recadré : Claude Code voulait une collection par langue (case-studies-fr, case-studies-en…). Plus simple à coder pour lui, mais ça aurait dupliqué le schéma trois fois. J’ai imposé une seule collection avec un sous-dossier par langue. La conséquence se voit maintenant : ajouter une nouvelle langue prend cinq minutes.
03 Phase 3
Composants & motion system
Nav, Footer, LangSwitcher, ProjectCard, Reveal, SmoothScroll (Lenis). Création de la skill motion. C’est là que la coquille a commencé à vivre — animations d’entrée, hover qui s’allume en jaune, scroll fluide.
Décision clé : animer le hero en CSS pur, pas en GSAP. Plus de dépendance au bundle JS pour le LCP. Une intuition de developer web, défendue contre la suggestion « GSAP partout ».
04 Phase 4
La home complète
Hero définitif, grille « Selected work » qui consomme enfin la collection Astro, section About en preview, CTA contact en monumental.
Pari assumé : publier quatre stubs de case studies en published plutôt que d’attendre le contenu réel. Mieux vaut montrer la machine fonctionner sur des stubs lisibles que d’avoir une grille vide. Le contenu final viendra par-dessus, sans toucher à la structure.
05 Phase 5
Les pages projets
Index /work en liste éditoriale (numéro Fraunces + titre Anton XXL + meta), avec une thumbnail qui suit le curseur au hover (effet Awwwards, GSAP quickTo, lazy import). Page dynamique /work/[slug] pour chaque projet : hero full-bleed, bloc meta structuré, body Markdown rendu en style éditorial .prose, NextProject cyclique.
Le moment de fierté : la première fois que j’ai survolé un item de l’index et vu la thumbnail flotter doucement vers le curseur. 70 lignes de code pour quelque chose qui, sur Awwwards, est l’effet signature de nombreux portfolios récompensés.
06 Phase 6
About & Contact
Pages narratives. La page About raconte une vraie trajectoire — pas une liste de compétences. L’hôtellerie quittée sans plan B. Le design découvert par hasard via WordPress et le marketing d’affiliation. Un master en développement web pour formaliser ce qui avait été appris seule. La polyvalence comme résultat d’une succession de choix non-planifiés, pas comme une posture. Page contact sans formulaire — juste un email géant et une ligne directe.
Un portfolio personnel n’a pas besoin d’un form Hubspot.
04 Honnêteté
Quand Claude Code est bon. Quand il ne l'est pas.
Bon pour
- Setup technique — configs, dépendances, conventions Astro/Tailwind/GSAP.
- Boilerplate — 12 stubs de pages multilingues en 2 minutes.
- Types & schémas Zod — jamais une erreur de syntaxe TypeScript.
- Patterns connus — smooth scroll Lenis, ScrollTrigger, image optim.
- Écriture documentaire — skills, READMEs, commit messages.
- Refactor multi-fichiers cohérent.
- Exploration visuelle (Claude Design) — directions de layout, palette, composants — avant de s’engager dans le code.
Pas bon pour
- Décisions de design — palette, typo, ratio, rythme visuel.
- Choix architecturaux non-standard — mes conventions de fichiers.
- Voix éditoriale — ton, choix des mots, ce qu’on tait.
- Sentir quand « ça va mieux » sans qu’on lui dise pourquoi.
- Connaître mon métier mieux que moi.
Le jour où il s'est planté
Un matin, je lui demande un état des lieux du projet à partir des logs d’une routine. Il me sort une checklist parfaitement confiante : remote Git absent, zéro lien sécurisé, case studies encore en placeholder. Tout était faux — il avait lu un fichier tronqué et comblé les trous tout seul, sans le dire.
Ce qui compte, c’est la suite. Je lui demande de vérifier pour de vrai. Il rouvre les fichiers, mesure, et réécrit sa propre checklist en signalant ses erreurs : remote OK, liens déjà sécurisés, contenu réel et complet.
C’est exactement ça, travailler avec une IA. Elle ne se fatigue jamais, mais elle ne doute jamais assez — mon rôle, c’est de douter à sa place. Une IA qu’on vérifie reste un accélérateur. Une IA qu’on croit sur parole devient un risque.
Produire, sans déléguer le jugement
Dernier exemple en date : les vignettes des projets sur l’accueil. Les images existaient, mais mal cadrées — des bannières panoramiques écrasées de force dans un cadre presque carré. J’ai dirigé l’IA pour en générer de nouvelles, mais c’est moi qui ai tranché le cadrage : refusé une photo verticale qui aurait coupé la posture de yoga, imposé le format paysage, validé chaque crop un par un.
Même réflexe à l’intégration. Un fichier nommé « documentaire » contenait en réalité une planche de stratégie de contenu. Plutôt que de le coller sous la mauvaise légende, Claude Code a lu le contenu de l’image et m’a demandé de trancher. Un nom de fichier n’est pas une preuve — diriger l’IA, c’est aussi lui apprendre de quoi se méfier.
Trois détails qu'il a fallu *voir*
Le hero a eu trois vies cette semaine — un bandeau de mots-clés défilant, un trait signature sous mon nom, des repères graphiques façon studio photo. Trois ajouts en CSS pur, animés en cascade. Sur le papier, terminé.
Sauf que. Le bandeau bouclait avec un trou visible sur grand écran — la technique translateX(-50%) exige que chaque moitié de la piste dépasse la largeur du viewport, et sur un 27 pouces, cinq mots ne suffisaient pas. Le trait sous « Belleudy » était dessiné avec une largeur approximative — visuellement presque juste, mais pas pile. Et en réduisant la fenêtre du navigateur à une taille tablette (sur ordinateur, donc avec une souris), le curseur disparaissait purement et simplement : le natif masqué, le custom caché, plus rien à l’écran.
Ces trois bugs, je les ai tous repérés moi-même — capture à l’appui pour le premier, comparaison à l’œil pour le deuxième, un simple redimensionnement de fenêtre pour le troisième. Claude Code n’avait vu aucun des trois : le code « marchait », au sens où rien ne plantait. Diriger l’IA, ici, c’était surtout tester comme une utilisatrice, pas comme un linter.
Les correctifs racontent bien l’écart entre « ça a l’air bon » et « c’est juste ». Pour le bandeau : répéter la liste de mots-clés jusqu’à dépasser largement le viewport. Pour le trait : un ResizeObserver qui mesure la largeur réelle de « Belleudy » dans le DOM et la répercute sur le tracé SVG — il colle désormais au pixel près, peu importe la langue ou la taille d’écran. Pour le curseur : une simple incohérence entre la requête média du script (qui décide de monter le curseur custom) et celle du CSS (qui décide de l’afficher) — corrigée en alignant les deux sur la même condition.
Aucun de ces trois bugs n’était « gros ». C’est précisément pour ça qu’ils comptent : ce sont les détails qu’un visiteur pressé ne remarque jamais consciemment, mais qui, accumulés, font la différence entre un site qui fonctionne et un site qui donne confiance.
05 Trois prompts
Qui ont changé quelque chose
On n’utilise pas Tailwind Typography pour la .prose. Je veux que chaque détail soit du design system — barre jaune avant les h2, numéros en Fraunces italique pour les ol, blockquote avec label en caps.
Résultat : un style éditorial qui n’existe nulle part ailleurs sur le web. Tailwind Typography est trop générique pour ce projet.
Le hero doit être animé en CSS pur, pas en GSAP. Pourquoi : le LCP.
Une phrase, une décision technique fondée. Claude Code a immédiatement réécrit le hero avec des @keyframes et un fallback prefers-reduced-motion.
Je veux que les cards des case studies sur la home soient visibles dès maintenant, même si le contenu réel viendra plus tard. Crée 3 stubs published, avec des SVG placeholder distincts dans le style design system.
Résultat : un site qui montre dès le push, pas un site qui attend le contenu. Une décision produit que j’ai assumée seule.
06 Apprentissages
Quatre maximes tirées du chantier
Diriger l’IA, c’est diriger soi-même. Plus le brief est clair, plus le résultat est juste. Quand je tâtonne, Claude Code tâtonne. Quand je sais, il livre.
Le designer n’est pas remplacé. La friction l’est. Le temps que je gagne, c’est celui que je passais à attendre, traduire, expliquer. Plus celui de la conception.
Les skills sont une forme de design. Encoder mes conventions dans .claude/skills/, c’est inscrire ma méthode dans le projet. Demain, si quelqu’un reprend le repo, il aura ma façon de penser à portée.
Le CLAUDE.md est l’objet le plus important du projet. Plus important que le package.json. Sans lui, chaque session redémarrerait à zéro.
07 Chantier réel
Pas 5 minutes
L'IA a effacé la friction technique. Elle n'a pas remplacé le temps de penser.
Un site généré en 5 minutes, ça existe. Un site calibré prend plus longtemps — et ce n’est pas la faute de l’IA.
Ce portfolio : 9 phases, plusieurs semaines travaillées en parallèle d’autres projets. Des dizaines de sessions, chaque commit validé à la main. Des décisions prises, interrogées, parfois défaites. Le design system affiné jusqu’à ce que le jaune soit ce jaune. Les animations réglées jusqu’à ce qu’elles cessent d’être visibles — au sens où elles font leur effet sans qu’on les remarque.
Ce qui a pris du temps, c’est ce que l’IA ne peut pas faire à ma place : décider. Savoir quand « ça marche » et quand « ça passe » ne sont pas la même chose. L’exigence ne se délègue pas.
08 Pour vous
Designers, recruteurs, clients
Si vous êtes designer
Ce n’est pas un remplaçant, c’est un amplificateur. Il ne fait pas de vous un meilleur designer. Il fait de vous un designer qui livre plus, plus vite, sans rogner sur la qualité — à condition de savoir exactement ce que vous voulez.
Si vous êtes recruteur
Ce site est un livrable réel : déployé, multilingue (FR/EN/ES), animé, accessible, performant. Construit à temps partiel en quelques semaines. Premier projet IA.
Ce que ça démontre en pratique : une capacité à prendre des décisions d’architecture (pas juste exécuter des consignes), à détecter ce que l’IA ne voit pas, et à tenir une direction artistique cohérente de la première intention au rendu final. Cette page elle-même — rédigée et structurée comme un case study — fait partie du livrable.
Si vous êtes client
L’IA a changé ma vitesse d’exécution. Elle n’a pas changé ma façon de penser un projet.
Le brief, la stratégie, l’identité visuelle, les décisions de structure — tout ça reste humain. Ce que l’IA remplace, c’est le temps entre l’intention et la ligne de code. Ce qu’elle ne remplace pas : savoir quelle ligne écrire.
Si quelqu’un vous propose un site complet en 5 minutes avec l’IA : demandez-lui comment il a choisi la couleur. Et pourquoi cette couleur-là parlera à votre audience.
Le second sera différent. Mais celui-ci aura toujours été le premier.
Travaillons ensemble
Le prochain projet, c'est peut-être le vôtre.
luciebelleudy@outlook.com