Portfolio

Technologies

• Next.js
• React
• Tailwind CSS
• Zod
• Claude Code
• TypeScript
• JavaScript
• GGSAP
• LLenis
• WWebGL
• RReact Hook Form
• Resend
• Vercel

Fonctionnalités

• Ouverture en néon, le nom qui s'allume lettre par lettre puis un rideau tranché au laser, passable d'un clic
• Héros en 3D, ciel en shader avec pluie et éclairs, projecteur qui envoie le monogramme RB dans les nuages
• Caméra amortie qui suit la souris, et le gyroscope au téléphone
• Justicier cliquable, avec un travelling qui zoome sur lui puis ouvre sa fiche
• Un méchant qui rôde sur les toits, débusqué par le faisceau du projecteur
• Manifeste en panneaux empilés, chaque idée démontrée par un geste
• Projets qui glissent de la droite et se posent sur le précédent
• Boîte à outils où chaque logo prend sa couleur de marque au survol
• Vitre embuée à essuyer à la souris ou au doigt, jusqu'à ce que l'enseigne s'allume
• Galerie des méchants, chacun un vrai problème de développement (injection SQL, XSS, fuite mémoire…) avec sa parade
• Barre fixe du recruteur pressé, avec le nom, le métier, les projets et le contact
• Formulaire de contact protégé (champ piège, délai minimum, limite d'envois) et faux terminal qui répond à quelques commandes

Contexte

Projet personnel né d'une idée simple. Un CV dit ce qu'on sait faire, une page peut le montrer. Ce portfolio sert donc à la fois de vitrine et de preuve, avec une exigence visuelle assumée, un univers de comics nocturne inventé pour l'occasion (pluie, brume, néons) et une règle tenue partout, la fluidité avant l'effet.

Architecture

Application Next.js 16 indépendante (App Router, React 19, TypeScript, Tailwind CSS 4), servie sous /portfolio et déployée par son propre projet Vercel, vers lequel le site de REPS Coaching redirige en interne l'adresse reps-coaching.com/portfolio. Animations par GSAP et ScrollTrigger, défilement doux par Lenis sur la même horloge. Un petit moteur WebGL maison, sans dépendance, fait tourner les shaders GLSL du ciel et de la vitre. Le héros est un vrai espace 3D en CSS, fait de plans à différentes profondeurs, et la ville y est dessinée en SVG. Les sections sous le premier écran sont chargées à part. Le formulaire s'appuie sur react-hook-form et Zod, et une route API envoie le message par Resend. Des scripts Node avec sharp préparent les images en AVIF et WebP.

Décisions techniques

- La fluidité passe avant l'effet. Seuls transform et opacity sont animés, toutes les boucles suivent l'horloge de GSAP, et aucun flou n'est calculé sur un calque qui bouge. - Chaque composant lourd naît avec sa version allégée. Au téléphone et sur une petite machine, moins de plans et un shader simplifié ; sans accélération graphique, une image fixe. - Les shaders se règlent seuls. Densité de pixels plafonnée, baissée d'elle-même si les images tardent, pause dès qu'ils sortent de l'écran ou que l'onglet est caché. - Le mouvement réduit est respecté. Ni ouverture ni défilement doux, une image fixe par shader, et une page qui reste lisible. - L'univers reste un cadre. Il n'occupe que le héros et la galerie des méchants, sans image officielle ni personnage existant ; ailleurs, la page reste sobre. - Méthode « les erreurs d'abord » pour le contact. Réseau coupé, envoi trop rapide, trop d'envois et service indisponible sont traités avant le cas qui marche.

Difficultés

Les flashs sur grand écran. Chaque panneau empilé gardait son calque pleine page, héros 3D et pluie animée compris. Sur un grand écran Retina, Chrome manquait alors de mémoire graphique et effaçait des morceaux de page une image sur deux. Un panneau entièrement recouvert par le suivant n'est désormais plus dessiné du tout. Le clic dans un espace 3D. Dans Chrome, cliquer sur un élément placé dans un espace 3D en CSS n'est pas fiable. La zone cliquable du justicier est donc un bouton invisible posé dans un plan 2D au-dessus de la scène, recalculé pour tomber exactement sur lui. Des personnages à la même échelle. Les poses des méchants n'ont ni le même cadrage ni les mêmes accessoires (canne, écharpe, hameçon). Un script mesure le corps seul dans chaque image, en effaçant tout ce qui est plus fin que lui, pour que chacun se tienne à la bonne taille sur les toits.

Résultats

En ligne sur reps-coaching.com/portfolio, où il sert de vitrine et de point de contact. Contrôlé sur la version en ligne au téléphone (390 px) et au bureau (1440 px), sans aucune erreur dans la console du navigateur.

Questions fréquentes

Pourquoi un univers de comics pour un portfolio de développeur ?

Pour montrer plutôt que dire. Le décor n'occupe que le héros et la galerie des méchants. Les projets, les outils et le contact restent sobres, et une barre fixe donne l'essentiel au recruteur pressé dès la sortie du héros.

Les effets sont-ils des vidéos ?

Non. Le ciel, la pluie et la buée sont des shaders WebGL écrits à la main, la ville est dessinée en SVG et les mouvements passent par GSAP. Aucune vidéo n'est incrustée dans la page.

Le site tient-il sur un téléphone ou un ordinateur modeste ?

Oui. Chaque effet lourd a sa version allégée, prévue dès le départ. Les shaders baissent leur définition quand les images tardent et s'arrêtent hors écran, et un ordinateur sans accélération graphique reçoit une image fixe.

Qui a dessiné les personnages ?

Ce sont des images générées par IA à partir de consignes écrites pour le projet, sans aucun personnage existant. Des scripts les découpent pose par pose, les convertissent en AVIF et WebP et mesurent leur corps pour qu'ils se tiennent tous à la même échelle. La ville, le ciel, la pluie et la buée sont codés.

Peut-on voir le code ?

Le dépôt est privé. Le site, lui, est en ligne, et chaque effet s'essaie directement sur la page, à la souris comme au doigt.

Y a-t-il des secrets sur la page ?

Oui, au bureau. La touche F affiche les images par seconde, et taper « gotham » éteint la page pour ne laisser que la lampe du curseur. Le terminal du contact répond aussi à quelques commandes, à commencer par help.