Vibecoder son portfolio - Mettre en place le projet (partie 2)

Sortir du générateur

La partie 1 s'arrêtait sur un constat : l'outil qui m'avait sorti de la page blanche n'était pas celui qui finirait le site. Il fallait donc changer d'outil. Comme l'intégration Claude Design et Figma n'est pas très avancée aujourd'hui, j'ai préféré utiliser simplement un éditeur de code. Pour cela, j'ai sorti le site de Claude Design en HTML/CSS/JS vers Claude Code avec les outils d'exports proposés par Anthropic. L'idée était de faire les ajustements directement dans l'app, voir modifier le code à la main pour le contenu texte.

Je savais bien sûr que j'allais rencontrer des difficultés pour le style, car je ne suis pas développeur. Mais c'était aussi une opportunité pour moi d'en apprendre un peu plus sur le front-end.

Paper, la maquette de référence

Après avoir transféré mon projet Claude Design vers Claude Code, j'avais besoin d'une source visuelle stable avec laquelle je pourrais itérer rapidement. Je n'avais pas besoin d'un mastodonte comme Figma, avec une gestion de composants poussée. Il me fallait juste un outil qui me permette de modifier manuellement des propriétés de style, que l'IA puisse lire facilement et comprendre quoi changer dans le code. C'est à ce moment que j'ai découvert Paper.

Paper, c'est un outil de design qui part du code pour générer un design. Je suis tombé amoureux de l'outil : il répondait exactement aux besoins de ce projet. Paper utilise des calques HTML et CSS comme moteur de rendu sur le canvas. Les agents IA peuvent donc reproduire fidèlement ce qui est actuellement en production, contrairement à des outils comme Figma, qui s'appuie sur des moteurs de rendu vectoriel 2D.

Mon premier réflexe a été d'importer les tokens de mon code vers Paper et demander à l'agent de créer les maquettes en respectant ces derniers. À partir de là, j'en ai fait mon outil de référence pour créer des variants, ajuster les maquettes à la main et les renvoyer à l'agent Claude Code.

GitHub, la mémoire du projet

Si Paper me donnait une référence visuelle, il me manquait encore un filet de sécurité. En vibecodant, on modifie beaucoup, sans toujours comprendre tout ce que l'IA vient d'écrire. Il me fallait un moyen de revenir en arrière sans y penser.

J'ai donc versionné le projet sur GitHub, avec une règle simple : une idée = une branche en worktree. Par exemple, les animations de la page d'accueil ont d'abord vécu sur une branche de test, avec des pages brouillon supprimées avant la fusion. Si une idée ne me plaisait pas, j'abandonnais la branche, tout simplement.

Ce filet a servi plus d'une fois. En uniformisant le CSS, l'animation 3D du logo avait perdu son style : l'historique a donc permis de retrouver exactement ce qui avait disparu et de le remettre.

Mais c'est surtout la pull request qui a changé ma façon de travailler. Pour chaque modification, Claude m'aide à résumer toutes les itérations effectuées au sein de la branche, les prises de décisions de mon côté... 35 PR plus tard, c'est devenu le journal de tracking de mes décisions et donc la matière première de cette série d'articles.

Render et un nom de domaine

Est venue ensuite la question de l'hébergement en ligne de mon site. J'avais un peu moins d'expérience sur le sujet, j'ai donc sollicité un ami développeur full-stack.

Il m'avait conseillé d'utiliser Render pour l'hébergement d'un site web. Pourquoi cet outil ? À partir d'un dépôt Git (dans mon cas Github), Render gère automatiquement le déploiement dès qu'une modification a été faite sur la branche main. Ça simplifie énormément la mise en production pour ce type de projet, car Claude Code pouvait ouvrir et merger les PR lui-même.

En terme de process, ça donne : je modifie en local, je pousse une PR, je la merge sur main et Render met la prod à jour tout seul.

Pour donner un aspect plus professionnel à mon portfolio, j'ai décidé d'acheter un nom de domaine sur Cloudflare. Render permet même de gérer ce nom de domaine personnalisé à travers sa version gratuite.

Mesurer et analyser les performances

Une fois le site en production, j'ai souhaité le traiter comme un produit à part entière. Comment savoir si mon portfolio était lu ? Comment identifier des frictions d'utilisation ?

J'ai donc appliqué la stack suivante :

Cloudflare Web Analytics : mon outil de tracking statistiques. Il me permet de compter les visites, mesurer les performances...

Microsoft Clarity : mon outil de tracking comportemental. Je l'utilise au travail donc je savais que l'intégration n'était pas compliquée et entièrement gratuite. L'outil me permet de créer des évènements custom à tracker (téléchargement de mon CV, clic vers mon LinkedIn, copie de mon mail), sans compter la partie des enregistrements de sessions et heatmaps si l'utilisateur accepte la collecte de cookies.

Les deux ne mesurent pas de la même manière : Cloudflare ne demande aucun cookie et compte naturellement tous les visiteurs du site alors que Clarity a besoin d'un consentement de collecte de cookies pour enregistrer les sessions et les collecter.

Le portfolio comme produit

Avec du recul, la stack choisie aurait pu être revue. Peut-être que je suis parti sur Render trop vite, alors qu'il existait des alternatives comme Vercel aussi connue. Mais je dirais que sur ce genre de petit projet, le choix des outils n'a pas vraiment d'impact. Ce qui est important, c'est de comprendre pourquoi on les a intégrés et à quel besoin ils répondent.

On a tendance à traiter un portfolio comme un site vitrine : on le termine, on le publie, et on n'y touche plus. Je voulais l'inverse, le traiter comme un produit à part entière, qui me permette d'itérer rapidement, de livrer en production facilement et de récolter du feedback sur son utilisation.

Une fois les fondations posées, il n'y avait plus qu'à apporter le brin de magie à ce portfolio. La suite dans la partie 3 !