projet perso

Ce portfolio

Ce site, de la méthode au code : PRD, direction artistique, design system, maquettes, puis intégration en Vue.

Type
Projet perso
Rôle
Conception, design et développement
Durée
Depuis octobre 2026, en cours
Équipe
Seul
Stack
Vue 3 · TypeScript · Vite · GSAP · Docker
Capture de Ce portfolio

Contexte

Étudiant ingénieur à l’ESIEA, je cherche un stage de fin d’études en développement full-stack.

Jusqu’ici, je me présentais avec un CV, LinkedIn et GitHub. Ces supports listent des compétences, mais ne montrent ni ma méthode, ni ma créativité, ni qui je suis : rien ne permet à un recruteur de me reconnaître.

Besoin

Un seul support qui rende visibles la rigueur d’un ingénieur, la créativité d’un développeur web et ma personnalité.

Deux lecteurs à servir. La recruteuse RH, qui trie vite et sans bagage technique, doit comprendre le profil et récupérer le CV en un clic. Le tech lead veut lire une étude de cas, comprendre les choix et ouvrir le code.

Contraintes

  • Budget : 0 €. Aucun service payant.
  • Auto-hébergé. Sur mon serveur personnel (Proxmox), dans un conteneur Docker, derrière Nginx Proxy Manager.
  • Référencement. Des pages pré-rendues, en français et en anglais.
  • Accessibilité. WCAG 2.2 niveau AA ; toutes les animations respectent « réduire les animations ».
  • Temps variable. Ma disponibilité change d’une semaine à l’autre : le travail est découpé en petites étapes livrables.

Méthode

Sept phases, dans l’ordre, chacune avec son livrable, sa branche Git et sa validation avant de passer à la suivante.

  1. PRD. Ce qu’on construit et pourquoi.
  2. Territoire de marque. Positionnement, valeurs, ton de voix.
  3. Direction artistique. Couleurs, typographie, mouvement.
  4. Architecture et UX. Arborescence, parcours, wireframes.
  5. Design system. Tokens et composants, avec leurs états.
  6. Maquettes. Les écrans clés, construits en code.
  7. Code. L’intégration en Vue.

Les maquettes sont faites directement en code, avec les vrais composants : chaque choix visuel se fait sur une page où l’on bascule entre plusieurs versions, dans le navigateur.

Choix techniques

Un design system avant les écrans

Des composants génériques, des « briques », tous construits sur des tokens : aucune valeur en dur. Chacun a sa page dans un catalogue de développement, avec ses réglages en direct, ses états et le mode « mouvement réduit ».

Compromis : plus de temps avant le premier écran, moins de retouches ensuite.

Le fond animé en WebGL natif

Les courbes de niveau de l’accueil reprennent un composant écrit pour une bibliothèque 3D, réécrit en WebGL 2 sans elle : une dépendance de moins. Image fixe en mouvement réduit, pause hors de l’écran.

Compromis : un shader à maintenir soi-même.

Tout auto-hébergé

Polices servies par le site, conteneur Docker sur mon serveur, aucune mesure d’audience : aucun service tiers, pas de bandeau de consentement.

Compromis : la disponibilité dépend de mon serveur.

Vue 3, Vite et TypeScript, sans Nuxt

Chaque page est pré-rendue en HTML complet avec vite-ssg, pour le référencement. Le routage bilingue, les balises head et le sitemap sont assemblés à la main, en petits morceaux lisibles.

Compromis : plus de code maison qu’avec Nuxt.

Résultats

7étapes, du PRD au code, chacune validée avant la suivante
32composants génériques, chacun dans le catalogue
105décisions écrites, chacune avec sa raison
6fonds de section, contre un seul dans la première direction artistique
avant1
après6

Les scores Lighthouse, visés à 95 ou plus sur les quatre axes, seront ajoutés à la mise en ligne.

Enseignements

  • Comparer plutôt que décrire. Décider devant deux à six versions affichées va plus vite que débattre sur un document.
  • Garder sa méthode. Un assistant de design automatique a été essayé deux fois, puis retiré : il imposait son propre déroulé à un projet qui avait déjà le sien.
  • Écrire les décisions. Une ligne et une raison par décision : on ne revient pas deux fois sur le même choix.