fr en

À propos de mon blog

Posted on 2025-09-05 in Blog

Après plus de dix ans, voici mon 200e article de blog ! J’ai décidé que ce serait un bon moment pour faire un point sur ces années et envisager le futur.

J’ai démarré ce blogue en 2013 alors que j’étais encore étudiant à Centrale Marseille. Il était alors fait en Drupal et hébergé sur les serveurs de l’école.

J’ai assez rapidement décidé d’en faire un site statique pour avoir quelque chose de plus simple et de plus facilement hébergeable et de le migrer sur mon domaine pour être plus indépendant (ma remise de diplôme approchait). Comme je faisais déjà pas mal de Python, j’ai choisi Pelican un générateur écrit en Python. De mémoire, j’avais aussi regardé Jekyll une autre solution très populaire à l’époque écrite en Ruby. Aujourd’hui, j’étudierai aussi Hugo une solution écrite en Go qui me semble de plus en plus populaire.

Pour ce blogue, je compte rester sur Pelican : ça fonctionne très bien, c’est suffisant pour mes besoins et comme j’ai peu d’articles le site est généré en moins d’une seconde. Je n’ai donc pas besoin des performances d’Hugo. En somme, aucune bonne raison de changer. Changer serait même difficile : mes articles sont écrits en reStructuredText et pas en Markdown (plus d’info à ce sujet ci-dessous) ce qui fonctionne avec Python moins dans les autres langages.

Le blogue a assez peu changé : je continue à bloguer sur les sujets tech qui m’intéressent. Certaines catégories n’ont pas eu d’articles récemment n’en auront surement jamais : elles correspondent à mes sujets d’intérêts quand j’ai lancé le blog. Seule la programmation est vraiment restée. L’expérience aidant, j’ai aussi l’impression d’avoir moins de sujets qui méritent un article. De ce point de vue, 2025 s’annonce comme une année exceptionnelle avec beaucoup de sujets.

Mon blogue reste assez peu connu. C’est principalement ma faute, je fais peu de pub, car ça ne m’intéresse pas. Il faut croire qu’écrire pour moi-même me suffit et que je préfère clarifier mes idées au fait d’être lu. Au début, je postais les liens sur Twitter pour avoir un peu de visibilité. Désormais, j’ai quitté Twitter où je n’étais de toute façon pas actif. J’ai un compte Mastodon, plus pour suivre des choses que pour poster. Et peu de personnes me suivent.

J’ai toujours des statistiques anonymes et compatibles RGPD sans bannière de cookies. Au début, j’autohébergeais une instance Matomo. Pour me simplifier la vie et gagner du temps, je suis passé sur plausible cette année : c’est simple, suffisant pour mon usage, RGPD compatible par défaut et pas très cher (9 € par mois, ce que je peux me permettre maintenant). Mon article le plus vu d’année en année reste un article publié en 2013 sur la création d’une page de garde en LaTeX avec le double de vues des autres articles. Au coude à coude viennent ensuite un article sur l’utilisation de trap en Bash et sur un sur les espaces de nom dans Docker. Pour les articles publiés cette année, celui sur uv et ruff et celui sur Pydantic et les enums fonctionnent très bien.

La langue d’écriture a aussi changé. Initialement, j’écrivais tout en français, puis j’ai proposé des traductions de mes articles en anglais pour accroitre leur visibilité. Comme la traduction demandait beaucoup de temps, maintenant j’écris en anglais, sauf pour de rares articles spéciaux comme celui-ci.

L’hébergement a changé également. Je suis passé d’un site Drupal, à un site statique hébergé sur mon VPS à un site statique dans des buckets (chez Scaleway pour éviter les géants américains). C’est encore plus simple (plus de serveur), et fonctionne très bien. C’est aussi moins cher. J’ai configuré la CSP via le HTML, car je n’ai pas l’impression qu’on puisse configurer ces entêtes dans les buckets. Je trouve que c’est moins bon, mais ça fonctionne. Je garde un VPS pour d’autres projets qui ont besoin d’un serveur, dont mes commentaires qui restent autohébergés grace à isso.

Concernant le format des sources, je suis toujours sur reStructuredText. Pelican fonctionne avec reSTtructuredText (via docutils l’implémentation de référence pour ce format) et Markdown par défaut. À titre personnel, je n’ai jamais accroché au Markdown : je le trouve pas assez spécifié et il a trop de variantes pas forcément compatibles entre elles. Avec reStrucuturedText, je peux inclure des fichiers, avoir les numéros de lignes à côté du code… J’ai donc plus de fonctionnalités qui fonctionnent correctement et sont correctement standardisées. Cela me convient mieux, même si je dois reconnaitre que le format manque de flexibilité. C’est, je pense, la force de Mardown : les cas simples sont gérés correctement par tout le monde et pas de prise de tête avec l’indentation, on écrit du texte un peu n’importe comment et ça fonctionne. Je doute qu’un langage à balisage sans cette caractéristique puisse devenir populaire, même si parser les cas plus complexes ou avoir toutes les fonctionnalités dont vous avez besoin est plus difficile.

Et l’IA dans tout ça ? Je n’ai pas vraiment d’avis. Comme la visibilité n’a que peu d’impact, je vais continuer à bloguer même si moins de personnes visitent mon blog. Si ça devient vraiment un souci et que je ne veux pas nourrir les LLM, je pense que je continuerais à écrire, pour moi sans rien publier. Ce serait dommage, car je sais que certains de mes articles sont utiles. Affaire à suivre…

Pour finir : je suis très content de ce blogue. Il me force à mettre mes idées au clair, me permet de partager certaines trouvailles, et, je pense, qu’il a fait de moi un meilleur développeur. Je compte continuer à bloguer quand j’ai envie sur les sujets qui m’intéressent. Je ne pense pas changer quoique ce soit sur la partie technique : ça fonctionne et j’en suis satisfait. Le fait que le blogue soit statique est un gros avantage, je pense, et je ne peux que vous recommander de faire un site statique vous aussi, si vous voulez un blogue : tout est plus simple, on peut utiliser git pour gérer les articles et il y a pléthore de bons outils pour vous simplifier la tâche.

Note

Dans un bucket, on ne peut pas définir des entêtes HTTP personnalisés dont X-Frame-Options pour empêcher l’inclusion du site dans une iframe. Utiliser <meta http-equiv="X-Frame-Options" content="DENY"> n’a pas d’effet. De même, la directive frame-src de Content-Security-Policy n’a pas d’effet au sein d’un élément meta (contrairement aux autres directives). Voir X-Frame-Options header et Content-Security-Policy: frame-src directive.

Tant que ces entêtes ne pourront pas être utilisées, j’ai décidé d’utiliser ce code javascript pour afficher une page vide quand le site est inclus dans une iframe (pour les utilisateurs qui ont javascript activé, ce qui devrait être la plupart des utilisateurs de nos jours) :

if (window.parent !== window) {
    window.location.replace('about:blank');
}