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 j’ai faite sans suivre de tutoriel.

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. Techniquement, elle reste modeste, 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 les projets que j’avais réalisés jusque-là, un démineur en Java écrit pendant un cours de DUT et un petit jeu de plateforme fait au lycée, 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.

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 une double authentification, et le formulaire de contact envoie ses notifications par une passerelle mail qui tourne sur mon propre serveur.

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 superflu, 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é.

Au-delà du confort d’écriture, ce qui m’a convaincu tient surtout à ce qui entoure le cadre. La documentation est claire et à jour, ce qui n’est pas si courant. Les briques officielles couvrent la plupart des besoins d’un site de contenu, donc je dépends de peu de bibliothèques tierces, et chacune de celles que j’ajoute est une chose de plus qui peut vieillir mal. Les mainteneurs communiquent leurs choix et leurs montées de version à l’avance, la communauté est petite mais présente, et les réponses se trouvent. Pour un site que je compte garder des années et faire évoluer sans tout réécrire, cette stabilité compte davantage que la nouveauté.

Tout gérer moi-même

C’est le premier de mes sites que j’administre de bout en bout. Les précédents vivaient sur des plateformes qui s’occupaient de tout à ma place, et c’était confortable, mais je ne voyais rien de ce qui se passait derrière.

Cette fois, je voulais mon propre serveur, mes propres services, ma base de données, mes sauvegardes. Décider où vont les choses et savoir les remettre en route quand elles tombent. Ce site s’y prêtait bien : assez simple pour ne pas se noyer, assez complet pour avoir à s’occuper d’une base, de fichiers, d’envoi de mails et de statistiques de visite. C’était un bon terrain pour commencer, et rien ici ne dépend d’un service que je ne contrôle pas.

Bonne lecture

J’espère que le site vous plaira et que vous y trouverez ce que vous cherchez. Si vous voulez échanger, me poser une question ou simplement dire bonjour, la page de contact est là pour ça.

Bonne lecture.