kevin-dev.com

C'est le site que vous lisez en ce moment : portfolio, blog, CV, formulaire de contact, et derrière, une administration complète pour tout gérer moi-même. C'est la troisième version, et la première que je n'ai copiée sur personne.

Les deux d'avant

La première date de 2021. Du HTML, du CSS, un peu de JavaScript, le tout suivi pas à pas depuis un tutoriel vidéo. Je n'en tire aucune fierté technique, mais c'est très concrètement ce qui m'a appris ces trois langages : reproduire, casser, comprendre pourquoi ça casse, recommencer. J'y hébergeais même mes projets d'alors, un démineur en Java et un petit jeu de plateforme, directement dans le dépôt.

La deuxième, en 2022, suivait encore un modèle tout fait, mais je commençais à m'en écarter. J'y ai ajouté de l'interactivité, un menu mobile, un accordéon de compétences, des onglets pour le parcours, un carrousel de projets, le lien de navigation qui se met en surbrillance au défilement. Elle m'a servi presque quatre ans, et je l'ai maintenue jusqu'à récemment.

Toutes les deux étaient statiques. Pour changer une ligne, j'ouvrais un fichier HTML, je modifiais le texte à la main, je poussais sur Git et j'attendais le redéploiement. Ça fonctionne quand on met son CV à jour une fois par an. Ça ne fonctionne plus dès qu'on veut écrire.

Ce que je voulais vraiment

Un endroit où je puisse ajouter un projet, écrire un article, retoucher une phrase, depuis une interface, sans toucher au code ni redéployer.

C'est le point de départ de cette version, et c'est aussi la partie qui a demandé le plus de travail : celle que personne ne voit.

Le back-office

L'administration couvre une douzaine de sections : projets, articles, interventions, technologies, catégories, médias, messages du formulaire de contact, pages légales, contenu de la page d'accueil, sécurité, sessions, et un tableau de bord.

L'éditeur de contenu propose deux modes sur la même source Markdown. Un mode visuel pour écrire normalement, avec tableaux, images et listes, et un mode brut avec coloration syntaxique quand je veux voir exactement ce que j'écris. Le contenu est stocké deux fois, en Markdown pour rester lisible et récupérable, et en HTML déjà rendu pour ne pas recalculer l'affichage à chaque visite. Le rendu passe par unified, remark et rehype, avec coloration du code et diagrammes.

Les images téléversées sont converties en WebP et déclinées en plusieurs tailles, pour que la page serve la variante adaptée plutôt qu'une image de deux mégaoctets.

L'accès est protégé par un second facteur, et le formulaire de contact envoie ses notifications par une passerelle mail qui tourne sur mon propre serveur.

Un détail dont je suis content : la publication programmée. Une entrée peut porter une date future, et la règle qui décide de ce qui est visible publiquement existe à un seul endroit dans le code, partagée par les projets, les articles et les interventions. Pas une condition recopiée dans chaque contrôleur, avec le risque d'en oublier une et d'exposer un brouillon.

Un style qui est enfin le mien

Après deux versions bâties sur des modèles, je voulais un design que je puisse défendre ligne par ligne.

Le résultat est volontairement sobre : clair par défaut, très aéré, une seule couleur d'accent, un rouge profond, et trois polices avec des rôles bien séparés. Pas d'effet de manche, pas d'animation qui se remarque, pas de design à concept. Le ton du texte suit la même logique, factuel plutôt que commercial.

C'est un parti pris assumé : le site doit donner envie de lire ce qu'il y a dedans, pas d'admirer sa mise en page. Les polices sont d'ailleurs auto-hébergées, comme le reste.

Côté technique

Le site tourne sur AdonisJS, en grande partie parce que je voulais essayer autre chose. J'avais déjà fait plusieurs projets avec Next.js, et j'avais envie de voir à quoi ressemble un cadre plus classique, avec son ORM, sa validation, ses sessions et son stockage de fichiers fournis d'origine.

Le point que je retiens est le pont entre le serveur et l'interface. Le front est en React, mais il n'y a aucune API entre les deux : les contrôleurs passent directement leurs données à la page React, avec les types partagés d'un bout à l'autre. Pas de couche d'API à maintenir, pas de types dupliqués, une seule source de vérité. Pour un site de contenu, c'est le meilleur compromis que je connaisse.

Tout héberger moi-même

Le site tourne sur mon serveur, déployé automatiquement à chaque poussée sur la branche principale. La base de données est isolée sur un réseau interne : elle n'est joignable ni depuis Internet ni depuis les autres projets qui tournent sur la même machine.

Les statistiques de visite sont auto-hébergées elles aussi, tout comme l'envoi des mails. Rien de ce que fait ce site ne dépend d'un service tiers que je ne contrôle pas, et c'était une intention dès le départ.

Où j'en suis

Le contenu est en cours de remplissage, et dans un ordre précis : d'abord les projets, un par un, en reprenant le code de chacun pour vérifier ce que j'en dis. Ensuite le blog, pour lequel j'ai déjà des idées.

C'est un peu l'inverse de l'ordre habituel, j'ai construit l'outil avant d'avoir le contenu. Mais c'est exactement pour ça que je l'ai construit : je n'écrivais pas parce qu'écrire demandait d'éditer du HTML à la main. Maintenant, il ne reste plus d'excuse.