Comment ce site est construit

Un recruteur a environ une minute. Ce site a donc un seul travail : montrer qui je suis, ce que je construis et comment me joindre, puis s’effacer. Cette note raconte comment je suis arrivé au résultat, de A à Z, avec les décisions et surtout les refus.

Ce que je voulais, avant de choisir un outil

J’ai commencé par écrire des contraintes, pas du code.

Une page légère, parce qu’une bonne partie des gens qui m’écriront ouvrent le site sur un téléphone, en 4G.
Trois langues, français, anglais et allemand, parce que je vis en Allemagne et que je viens du Cameroun.
Un site que je peux modifier sans toucher au code.
Un site qui ne ressemble pas à ce que fabrique un générateur : pas de dégradé violet, pas de verre dépoli, pas de grille de cartes avec des icônes, pas de phrases creuses.
Une palette fixée dès le début : six bleus et un blanc, du noir minuit au bleu royal.

Choisir en regardant, pas en lisant

Je ne choisis pas un design sur une description. Pour chaque décision visuelle, j’ai demandé une page rendue, avec plusieurs options côte à côte, et j’ai tranché devant l’écran.

Cela m’a fait rejeter beaucoup de choses. Ma première direction, une fiche de composant électronique avec un brochage et un numéro de pièce, était trop recherchée et pas du tout moderne : je l’ai abandonnée. Une vague de particules en WebGL ne me plaisait pas. Une aurore non plus. J’ai gardé un ciel de nuit avec un halo bleu à l’horizon. Pour le logo, j’ai comparé plusieurs pistes, rejeté les monogrammes trop fins, puis choisi un Y plein à trois pointes, dont le centre est évidé en forme d’anneau. Chaque refus a resserré le style.

La stack : Astro, TypeScript, du CSS simple

Astro produit du HTML statique et n’envoie du JavaScript que là où quelque chose bouge. C’était exactement le besoin : pas de framework d’interface à charger pour afficher du texte et des images. TypeScript pour les modules qui ont de la logique, du CSS écrit à la main pour le reste, et aucun framework de styles.

Le résultat est mesurable. La page d’accueil charge environ 9 Ko de JavaScript à moi. Le seul morceau lourd est Three.js (137 Ko compressés), utilisé pour le mur de logos de technologies. Il ne se télécharge que lorsque ce mur approche de l’écran, et jamais pour un visiteur qui demande moins d’animations, qui économise ses données ou qui est en 2G.

Une police, hébergée chez moi

Poppins porte tout, du nom dans le hero aux libellés du formulaire. Je l’héberge moi-même, en quatre graisses seulement, et je précharge les deux utilisées au premier écran. Pas de requête vers un service de polices, donc pas de dépendance externe et pas d’affichage qui saute.

Trois langues, une seule source

Les pages viennent du même arbre de composants. Les mots vivent dans un fichier par langue, et ce qui est commun (liens, projets, technologies, couleurs) dans un fichier partagé. Chaque page déclare ses versions avec hreflang et le sitemap les relie, pour que Google traite les trois langues comme une seule page traduite et non comme des doublons. Ajouter une langue ou corriger une phrase ne demande jamais de toucher à un composant.

Un tableau de bord pour ne plus toucher au code

C’est la décision dont je suis le plus content. Un petit serveur Node, lancé avec npm run admin, me donne une interface pour tout modifier : textes dans les trois langues, projets, parcours, images, CV, réglages de référencement.

Il est écrit sans aucune dépendance. Il n’écoute que sur la machine locale, jamais sur le réseau. Le mot de passe est haché avec scrypt, la session est protégée, chaque modification exige un jeton contre le CSRF et une vérification de l’origine, et chaque fichier envoyé est contrôlé par sa signature réelle et sa taille, pas par son nom. Avant d’enregistrer, il vérifie que les données ont la bonne forme : si je me trompe de champ, il refuse plutôt que de casser le site.

Le mouvement

Le ciel du hero est un canvas de quelques centaines d’étoiles sur trois profondeurs, qui scintillent, dérivent et suivent un peu le curseur. Il se met en pause hors écran. Au premier chargement d’une session, une courte intro de moins de quatre secondes fait voler le logo jusqu’à sa place dans la barre de navigation, puis ne revient plus pendant la session.

Tout cela obéit à une règle : si le visiteur demande moins d’animations ou économise ses données, il voit une image fixe, et le site reste complet. Le mouvement est un plus, jamais une condition.

Les projets : montrer le vrai produit

Pour chaque projet, j’ai voulu de vraies captures de l’application qui tourne, pas des maquettes. Quand une application n’était pas lancée, je l’ai lancée sur une copie, avec une base jetable et des données de démonstration que j’ai inventées : noms de clubs fictifs, scores tirés au hasard. Les coordonnées personnelles qui apparaissaient dans des documents ont été effacées avant publication, y compris dans les pixels d’une image.

Quand un projet est une proposition non demandée, comme celle pour une enseigne de poulet camerounaise, la page le dit. Chaque image porte aussi, dans ses métadonnées, son origine : capture réelle, photo sous licence libre, ou rendu. Je ne publie rien dont je ne peux pas dire d’où ça vient.

Le référencement, traité comme du code

Le site est du HTML complet, lisible par un moteur de recherche sans exécuter de script. Chaque page a son adresse canonique, ses alternatives de langue et ses données structurées (la personne, le site, chaque projet, le rapport téléchargeable, la vidéo). Le sitemap porte de vraies dates de dernière modification, et un fichier llms.txt résume le site pour les outils de recherche à base d’IA. Les images de partage sont générées par un script.

Surtout, un script d’audit (npm run seo) parcourt toutes les pages construites et échoue si quelque chose est cassé : titre, description, lien interne, lien retour entre langues, image sans texte alternatif. Je le lance à chaque modification.

Les outils, honnêtement

J’ai construit ce site avec un assistant de programmation à base d’IA, qui a écrit une grande partie du code et lancé les vérifications. Les décisions sont les miennes : le brief, les contraintes, la palette, ce qui a été rejeté et ce qui a été gardé. Je relis ce qui est publié, et je ne livre rien que je ne comprends pas.

Ce qui n’est pas parfait

Sur ordinateur, la page d’accueil est un peu moins rapide que sur mobile à cause du mur 3D. Je mesurais environ 98 sur 100 en performance sur mobile et 85 sur ordinateur, avec 100 en accessibilité, bonnes pratiques et référencement. Corriger le mur 3D est sur ma liste.
Le formulaire de contact envoie un courriel et ne propose pas de confirmation de rendez-vous.
Aucun script de suivi ne tourne ici : je ne sais donc pas combien de personnes viennent, et je préfère ça.