jordan-t.dev v2

Ce site. Une refonte complète, où chaque choix technique devient sa propre démonstration.

Pourquoi refondre

Gatsby a été un bon choix en son temps, surtout pour sa couche de données et son pipeline d'images (placeholders SVG, formats responsives, lazy-loading natif). Mais l'écosystème a bougé, et moi avec. Ce que Gatsby résolvait via une abstraction lourde, la plateforme le fait aujourd'hui nativement, et la v1 embarquait du JavaScript client malgré un objectif inverse.

Le déclencheur réel, c'est la maintenance. Les montées de version sur Gatsby devenaient complexes et chronophages. Je cherchais un socle durable, qui limite la dette technique, plutôt qu'un choix optimal sur un seul critère à un instant donné.

Pourquoi Next, et pas Astro

Astro était tentant : zéro JS par défaut, architecture en îlots, idéal pour un site de contenu comme celui-ci. En génération statique pure, il aurait sans doute produit un build plus léger que Next, qui ajoute toujours un peu de JavaScript. Pour ce site précis, ça aurait suffi.

Le critère décisif n'est pas ce site isolé, c'est la suite. Next est massivement implanté, son écosystème (RSC, View Transitions, gestion des images) domine la concurrence, et il laisse la porte ouverte au dynamique côté serveur si je veux faire évoluer le projet. Astro m'aurait sans doute enfermé dans le statique, comme Gatsby m'avait enfermé sur les montées de version. Entre le plus léger maintenant et le plus évolutif ensuite, j'ai tranché pour la durabilité.

Le JavaScript est un budget

La règle que je me suis fixée inverse la logique habituelle. Au lieu d'ajouter du client par défaut et de retirer « si on a le temps », chaque kilo-octet de JavaScript doit gagner sa place.

• Architecture : React Server Components par défaut, tout est serveur sauf preuve du contraire. Les rares îlots interactifs sont des 'use client' explicites et isolés, jamais une contamination de tout l'arbre.
• Styles : CSS Modules plutôt que Tailwind ou CSS-in-JS, pour garder un runtime de style à zéro. L'animation passe par le CSS natif (scroll-driven animations, View Transitions), sans framework dédié.
• Décisions tracées : le dépôt est public, et chaque arbitrage vit dans un ADR versionné (.ai/decisions/). J'écris mes décisions pour pouvoir les discuter plus tard, pas seulement pour les prendre.

Le CV, généré depuis une source unique

Le CV téléchargeable n'est pas un fichier maintenu à la main. Il est généré automatiquement à partir de la même configuration que le site, via @react-pdf/renderer. L'idée : une seule source de vérité, pour que le CV ne puisse jamais contredire le site.

Les vrais défis étaient ailleurs que dans la génération elle-même. D'abord le typage strict des données, pour garantir que ce qui alimente le PDF est exactement ce qui alimente le site. Ensuite la mise en page : le moteur de rendu PDF n'utilise qu'un sous-ensemble de Flexbox, avec ses propres contraintes, qu'il a fallu apprivoiser pour rester fidèle au rendu web.

L'accessibilité, conçue et non rattrapée

Le site reste lisible et utilisable avec JavaScript désactivé. C'est de l'amélioration progressive au sens strict : le contenu est rendu côté serveur et vit dans le HTML servi, la navigation repose sur de vrais liens. Ce qui marche sans JS marche aussi quand le JS échoue à charger, sur connexion lente ou bundle en erreur.

Concrètement, l'accessibilité a été traitée dès la conception : navigation entièrement au clavier avec des focus toujours visibles, un lien d'évitement pour rejoindre directement le contenu, et le respect de prefers-reduced-motion pour qui désactive les animations.

Le soin va jusqu'à l'impression du CV. Plutôt que d'empiler des surcharges CSS, la couleur a été pensée à la racine : la luminosité de la teinte primaire est calibrée pour rester identique à l'écran, tout en garantissant un contraste correct une fois imprimée en noir et blanc.

Les chiffres

Pour vérifier ces arbitrages, les mesures comptent autant que les intentions. Sur Lighthouse, en émulation mobile (Moto G Power, 4G lente) :

Le CLS à 0 confirme qu'aucune mise en page ne bouge pendant le chargement. Le TBT à 20 ms, lui, mérite une nuance. Ce chiffre n'est pas nul, et il ne le sera jamais avec ce choix technique. Une partie vient du runtime Turbopack, incompressible dès qu'on utilise un bundler de modules.

Astro aurait sans doute produit un TBT plus bas, grâce à une architecture en îlots sans ce runtime. Mais il n'apporte pas nativement le préchargement des liens ni les mêmes optimisations par défaut. Next.js les inclut, et s'appuie sur un écosystème largement adopté : Server Components, et d'autres possibilités si le projet évolue. « JS est un budget » ne veut pas dire JS à zéro. Ça veut dire accepter un coût mesuré, en échange de ce qu'il permet.

Je croise aussi avec GTmetrix, qui note Grade A (100 % en performance, 99 % en structure) et apporte d'autres angles utiles comme le waterfall réseau. Croiser deux outils évite de s'enfermer dans un seul référentiel.

L'IA, sans dette de conception

Contexte : Le marché redéfinit les attentes envers notre métier. Didier Girard (Studio Devoxx 2025) note que des entreprises comme Sfeir ciblent désormais les développeurs augmentés par l'IA. L'écriture du code n'est plus le véritable goulot d'étranglement, le défi se déplace vers la conception de systèmes solides. Nathan Menard rappelle cependant une limite fondamentale : la machine ne porte ni la vision produit, ni l'intuition métier, ni la responsabilité du résultat.

Décision : J'ai structuré ce portfolio pour encadrer l'IA, traitée ici comme un exécutant, pas un décideur. Le dossier de configuration est volontairement nommé .ai, et non .claude, pour éviter tout enfermement technologique. Il impose un cadre technique rigoureusement défini et documenté en Markdown. La machine lit ces directives agnostiques pour s'imprégner des règles du projet. Je conserve le rôle d'architecte et je valide manuellement chaque ligne proposée.

Conséquence et compromis : Le temps gagné sur la saisie de code standard est réinvesti dans l'exigence architecturale, pas dans le confort. Le compromis direct reste le niveau d'attention requis lors de la revue. Diriger une IA demande un effort de documentation lourd et une vigilance constante. Sans cette rigueur, on retombe exactement dans ce que Topçu et Chevalier décrivent comme la dette de conception : des décisions d'architecture prises sous pression, invisibles dans le code, mais qui contraignent tout ce qui suit. La documentation .ai reste valide même si le modèle de langage change, ce qui garde cette indépendance technologique dans la durée.

---

Ce projet est vivant et open-source. Si vous repérez un axe d'amélioration, un comportement inattendu, ou si vous voulez simplement échanger sur ces choix d'architecture, n'hésitez pas à ouvrir une issue sur le dépôt Jordan-T/my-portfolio-next.