Blog on Zwindler's Reflection

Refonte de la page Conférences : data-driven avec Hugo

Fri, 13 Mar 2026 20:00:00 +0100

Grosse refonte de ma page “Conférences” qui était un bazar sans nom, dans lequel j’avais aussi mélangé les podcasts, les publications écrites, etc. Maintenant tout est présenté avec des “cartes”, et bien séparé en 3 pages distinctes.

Tous les fichiers sources (YAML, layouts Hugo, CSS) sont disponibles dans /misc/conferences-refonte/ si vous voulez reproduire ou vous en inspirer.

Le problème

Ma page Conférences était un gros fichier Markdown monolithique. Talks, podcasts, publications, orga : tout mélangé dans des listes à puces, avec des doublons, et de plus en plus pénible à maintenir (surtout depuis le passage en multi-langue FR/EN).

L’approche : données + layouts + CSS

Plutôt que de continuer à maintenir du Markdown, je suis passé en data-driven, comme je l’ai fait pour mon side project “101 ways to deploy Kubernetes” :

Données dans des fichiers YAML (data/)
Présentation dans des layouts Hugo custom (layouts/page/)
Style dans des CSS dédiés (static/css/)
Pages Markdown réduites au strict minimum (front matter uniquement)

Et au passage, j’ai découpé une page fourre-tout en trois : Conférences, Podcasts & Lives, Publications.

Les données YAML

`data/conferences.yaml`

Le plus gros fichier. L’idée clé : un talk (sujet unique) peut être présenté à plusieurs events. Fini la duplication.

talks:
 - id: k8s-scheduling
 title:
 fr: "Limits, Requests, QoS, PriorityClasses, ..."
 en: "Limits, Requests, QoS, PriorityClasses: ..."
 cospeaker: "Quentin Joly"
 slides: "/talks/2025-lrqppobcqvpsslsdk/..."

events:
 - talk: k8s-scheduling  # référence l'id du talk
 event: "DevoxxFR 2026"
 date: 2026-03-22
 type: conference
 - talk: k8s-scheduling
 event: "TNT 26"
 date: 2026-02-12
 type: conference
 video: "https://www.youtube.com/watch?v=..."

organizer:
 - description:
 fr: "Membre de l'équipe d'organisation du Meetup CNCF Bordeaux"
 current: true

Les titres sont bilingues (FR/EN), Hugo sélectionne la bonne langue automatiquement. Les fichiers data/podcasts.yaml et data/publications.yaml suivent le même principe (voir les fichiers sources).

Les pages Markdown minimalistes

L’ancienne page content/page/conferences.md faisait 100+ lignes avec le contenu complet. Voici la nouvelle :

---
title: 'Conférences'
authors:
 - zwindler
type: page
layout: conferences
date: 2022-03-14T18:00:00+00:00
menu:
 main:
 weight: -40
 params:
 icon: messages
toc: false
---

Le point important, c’est layout: conferences dit à Hugo d’utiliser layouts/page/conferences.html au lieu du layout par défaut. Même chose pour podcasts et publications.

Le layout Hugo

Le layout charge les données YAML, calcule des stats, et génère du HTML. Si vous avez déjà manipulé du GoTemplate (helm notamment), ça vous semblera facile à comprendre.

Chargement et indexation des talks :

{{- $data := .Site.Data.conferences -}}
{{- $talks := dict -}}
{{- range $data.talks -}}
 {{- $talks = merge $talks (dict .id .) -}}
{{- end -}}

Compteur dynamique ex. combien de fois un talk a été présenté :

{{- $count := 0 -}}
{{- $talkId := .id -}}
{{- range $data.events -}}
 {{- if eq .talk $talkId -}}
 {{- $count = add $count 1 -}}
 {{- end -}}
{{- end -}}
<p class="talk-card-count">Présenté {{ $count }}x</p>

Événements groupés par année, les 2 plus récentes dépliées, le reste en archive pliable via <details> :

{{- range $i, $year := $sortedYears -}}
 {{- if lt $i 2 -}}
 <details class="year-group" open>
 {{- else -}}
 <details class="year-group">
 {{- end -}}

Les événements à venir (date dans le futur) reçoivent automatiquement un badge “à venir”. Les layouts complets sont dans les fichiers sources.

Le CSS : des cartes partout

Le design repose sur des cartes CSS grid, avec des badges colorés par type (conf, meetup, BBL), du responsive, et un support dark mode. L’essentiel :

.talks-grid {
 display: grid;
 grid-template-columns: repeat(auto-fill, minmax(280px, 1fr));
 gap: 1.2rem;
}

.talk-card {
 background: var(--card-background);
 border-radius: 10px;
 padding: 1.2rem;
 transition: border-color 0.2s ease, box-shadow 0.2s ease;
}

.type-conference { background: #dbeafe; color: #1e40af; }
.type-meetup { background: #dcfce7; color: #166534; }
.type-bbl { background: #fef9c3; color: #854d0e; }
.type-upcoming { background: #fee2e2; color: #991b1b; }

Les CSS complets gèrent aussi le dark mode et les breakpoints mobile. Ils sont dans les fichiers sources.

Bilan

Aspect	Avant	Après
Pages	1 fourre-tout	3 spécialisées
Données	Markdown libre	YAML structuré
Duplication	Oui	Non (relation talk → events)
Stats	Aucune	Automatiques
Design	Listes à puces	Cartes + badges
Multi-langue	Copier-coller	Titres FR/EN dans le YAML
Archives	Tout d’un bloc	Années pliables

C’était un gros morceau : 19 fichiers et ~2400 lignes (une grosse partie du taf, en particulier la traduction markdown => YAML et le CSS, a été faite par un LLM), mais la logique est simple : données dans YAML, présentation dans les layouts, style dans le CSS. Hugo fait le lien au build, sans JavaScript.

Pour ajouter un nouveau talk maintenant, il me suffit d’ajouter une entrée dans data/conferences.yaml et les stats se mettent à jour toutes seules.

Avouez que c’est quand même plus propre qu’un copier-coller dans plusieurs fichiers Markdown :).

De F à A+ sur HTTP Observatory : sécuriser les headers de mon blog Hugo

Sat, 21 Feb 2026 10:00:00 +0200

Après l’optimisation des performances du blog (AVIF, pré-compression), j’étais super content de moi. 🥳

Mais c’était sans compter sur Antoine Caron, qui est venu (à très juste titre) me chatouiller sur un autre aspect que j’avais ignoré, le rapport Mozilla Observatory…

J’ai donc lancé un scan Mozilla HTTP Observatory sur mon blog et le résultat était : F.

Cool, je peux pas faire pire.

Le déclic

En relisant l’article de Julien sur codeka.io, qui a aussi parlé avec Antoine, a aussi un blog statique avec Hugo, MAIS qui lui avait fait le taf, j’ai réalisé que c’était à la fois important et peut-être pas si compliqué à corriger.

Julien y détaille les headers de sécurité à ajouter sur un site Hugo, avec des exemples pour Caddy. Moi je suis sur nginx, mais le principe est le même.

Note : si ça vous intéresse, les liens des épisodes précédents sur l’infra du blog sont ici :

Ça bouge pas mal sur le blog ! (2019) - De 5s à 1s en virant Wordpress pour Hugo
Ça bouge encore sur le blog (2025) - Nettoyage massif, retour auto-hébergé
Automatiser son site Hugo sans Github Action ou Vercel - Le setup nginx + webhook actuel
Optimisation webperf : AVIF et pré-compression - Le round précédent (focus sur les images)

Ce que teste HTTP Observatory

HTTP Observatory vérifie une série de headers HTTP que votre serveur devrait envoyer pour protéger vos visiteurs. Les principaux :

Strict-Transport-Security (HSTS) : force le navigateur à toujours utiliser HTTPS
Content-Security-Policy (CSP) : contrôle quelles ressources le navigateur peut charger (scripts, styles, images, iframes…)
X-Content-Type-Options : empêche le navigateur de “deviner” le type MIME des fichiers
Referrer-Policy : contrôle les informations de provenance envoyées aux sites tiers
X-Frame-Options / frame-ancestors : empêche l’inclusion de votre site dans une iframe (clickjacking)

Sur un blog statique, on pourrait se dire que ce n’est pas critique. Pas de base de données, pas de sessions utilisateur, pas de formulaires sensibles. Mais ces headers protègent quand même contre des attaques réelles :

Un script injecté (XSS) pourrait rediriger vos lecteurs vers un site malveillant
Sans HSTS, un attaquant sur un Wi-Fi public pourrait intercepter la connexion initiale en HTTP
Sans frame-ancestors, quelqu’un pourrait inclure le blog dans une iframe piégée

Bref, même pour un blog statique, ça peut valoir le coup de faire l’effort, a minima pour s’habituer aux bonnes pratiques.

Étape 1 : les headers “faciles”

Le piège nginx : add_header et l’héritage

La première chose, c’est que je suis tombé dans un piège classique avec mon nginx. Je l’ignorais, mais les directives add_header dans un bloc location écrasent (et ne complètent pas) celles du bloc server parent.

Ça veut dire que si vous avez un add_header Cache-Control dans une location (c’était mon cas), tous vos headers de sécurité définis au niveau server disparaissent pour cette location. J’ai pété un plomb pendant quelques minutes à reload / restart en boucle sans comprendre.

La solution : créer un fichier snippet et l’inclure partout.

cat > /etc/nginx/snippets/security-headers.conf << 'EOF'
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Content-Security-Policy "..." always;
EOF

Puis dans la config nginx :

server {
 # Headers de sécurité au niveau server
 include /etc/nginx/snippets/security-headers.conf;

 # Cache des assets statiques
 location ~* \.(jpg|jpeg|png|gif|ico|css|js|woff|woff2|ttf|svg|webp|avif)$ {
 expires 1y;
 add_header Cache-Control "public, immutable";
 # OBLIGATOIRE : ré-inclure les headers ici !
 include /etc/nginx/snippets/security-headers.conf;
 }

 location ~* \.html$ {
 expires 1h;
 add_header Cache-Control "public, must-revalidate";
 include /etc/nginx/snippets/security-headers.conf;
 }
}

HSTS, X-Content-Type-Options, Referrer-Policy

Ces trois-là sont les plus simples à ajouter et “ne cassent rien” :

Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin

HSTS avec max-age=63072000 (2 ans) et preload permet à terme (pas encore fait) de s’inscrire sur la HSTS preload list. Le navigateur refusera même la toute première connexion HTTP initiale.
nosniff empêche les navigateurs d’interpréter un fichier texte comme du JavaScript.
strict-origin-when-cross-origin envoie l’URL complète en referrer pour les requêtes same-origin, mais seulement l’origine (domaine) pour les requêtes cross-origin.

Étape 2 : Content-Security-Policy (la vraie difficulté)

La CSP est un header puissant et a priori complexe. C’est lui qui rapporte le plus de points sur Observatory, mais c’est aussi lui qui peut tout casser si on va trop vite.

Le principe : vous déclarez au navigateur exactement quelles ressources votre site a le droit de charger (scripts, styles, images, iframes, fonts…) et depuis quelles origines. Tout le reste est bloqué. C’est la meilleure défense contre le XSS, parce que même si un attaquant arrive à injecter un <script> dans votre HTML, le navigateur refusera de l’exécuter s’il n’est pas dans la liste autorisée.

Le revers de la médaille : si vous oubliez une ressource légitime dans votre CSP, elle sera bloquée et votre site casse silencieusement : un script qui ne charge plus, une font qui disparaît, une iframe vide. Il faut donc faire un inventaire exhaustif avant de verrouiller.

Je me suis fait épauler par un LLM (Opus 4.6) pour les modifs à réaliser et on a fait plusieurs passes jusqu’à ce que tout fonctionne.

Inventaire des ressources externes

Avant d’écrire la CSP, il faut faire l’inventaire de tout ce que le site charge. Voilà une petite synthèse de mon pote Claudio :

Type	Ressource	Origine
Script	GoatCounter analytics	`https://gc.zgo.at/count.js`
Script	Umami analytics	`https://cloud.umami.is/script.js`
Connect	GoatCounter API	`https://blogzwindler.goatcounter.com`
Connect	Umami API	`https://api-gateway.umami.dev`
Script	De mon thème ‘stack’ - vibrant.js (couleurs d’images)	`https://cdn.jsdelivr.net`
Script	De mon thème ‘stack’ - PhotoSwipe (lightbox images)	`https://cdn.jsdelivr.net`
Style	De mon thème ‘stack’ - PhotoSwipe CSS (lightbox)	`https://cdn.jsdelivr.net`
Style	De mon thème ‘stack’ - CSS du thème	local (`'self'`)
Font	Luciole	locale
Frame	Widget Deezer (inclu dans un seul article 😖)	`https://widget.deezer.com`
Image	data: URIs (SVGs inline)	`data:`
Form	Mailchimp (abonnement newsletter)	`https://zwindler.us15.list-manage.com`

Le problème des scripts d’analytics externes

Avec une CSP comme script-src 'self' https://gc.zgo.at https://cloud.umami.is, je devais soit :

Faire confiance à ces CDN -> si le CDN est compromis, le script malveillant s’exécute sur mon blog. Nope.
Ajouter des hashes SRI (Subresource Integrity). Problème : ces scripts peuvent changer côté serveur sans prévenir, ce qui casserait le hash.

J’ai choisi une troisième voie : télécharger les scripts à chaque build et les servir localement.

# Dans mon petit script blog_refresh.sh, avant le hugo --minify
mkdir -p static/js
curl -sf --max-time 10 https://gc.zgo.at/count.js -o static/js/count.js \
 || echo "WARN: failed to download GoatCounter script"
curl -sf --max-time 10 https://cloud.umami.is/script.js -o static/js/umami.js \
 || echo "WARN: failed to download Umami script"

Et dans le template Hugo :

<script data-goatcounter="https://blogzwindler.goatcounter.com/count"
 async src="/js/count.js"></script>
<script defer src="/js/umami.js"
 data-website-id="3d8f0ea9-..."></script>

Est-ce que c’est “tricher” ?

Une fois que j’avais fait la modif, je me suis demandé : est-ce qu’héberger les scripts localement à chaque build ne contourne pas l’esprit des vérifications d’Observatory ? Sur ce point précis j’ai un petit doute, n’étant pas expert sur ces points là. J’ai demandé à un LLM qui m’a dit que non, mais je veux bien un avis tiers.

Dans tous les cas, ça semble être l’approche recommandée par la documentation GoatCounter pour les sites avec une CSP stricte.

Supprimer `unsafe-inline` de `script-src`

Observatory pénalise fortement 'unsafe-inline' dans script-src. Et c’est normal, car c’est la porte ouverte au XSS : n’importe quel script injecté dans le HTML s’exécute.

Le problème : mon thème Hugo (hugo-theme-stack) générait 4 scripts inline :

Color scheme init — lit le localStorage pour appliquer le thème clair/sombre avant le premier rendu
Color scheme detection — détecte la préférence système (prefers-color-scheme: dark)
Language switcher — le sélecteur de langue <select onchange="window.location.href=this.selectedOptions[0].value"> dans la sidebar, qui est un attribut d’événement inline (script-src-attr)
Font loader — charge la CSS de la font Luciole dynamiquement

Luciole: A typeface for visual impairment

Pour chacun, j’ai extrait le code dans un fichier .js externe dans static/js/ et remplacé le script inline par une balise <script src="...">.

Par exemple, pour le color scheme, le thème avait dans layouts/partials/head/colorScheme.html :

<script>
 (function() {
 const colorSchemeKey = 'StackColorScheme';
 if(!localStorage.getItem(colorSchemeKey)){
 localStorage.setItem(colorSchemeKey, "auto");
 }
 })();
 /* ... */
</script>

Que j’ai remplacé par un override de template Hugo :

{{- /* Override: external JS file instead of inline (CSP compliance) */ -}}
<script src="/js/color-scheme.js"></script>

Avec le contenu correspondant dans static/js/color-scheme.js. Hugo permet de surcharger n’importe quel template du thème en plaçant un fichier au même chemin dans le dossier layouts/ du projet.

Pour le language switcher, même approche : j’ai surchargé layouts/partials/sidebar/left.html pour retirer l’attribut onchange du <select> et ajouté un id="language-select", puis créé un fichier static/js/language-switcher.js :

(function () {
 var select = document.getElementById('language-select');
 if (select) {
 select.addEventListener('change', function () {
 window.location.href = this.selectedOptions[0].value;
 });
 }
})();

Note importante : il m’a fallu plusieurs allers-retours avec la console du navigateur (F12 -> Console) avant de trouver la totalité des violations CSP. Chaque correction en révélait de nouvelles, il fallait bien regarder tous les différents types de pages sur le blog (pas juste la page d’accueil et les posts), et certaines erreurs affichées dans la console venaient en fait d’extensions navigateur (typiquement les gestionnaires de mots de passe comme Bitwarden, dont le bootstrap-autofill-overlay.js génère des violations style-src-elem) et non du site lui-même. Il faut donc bien distinguer les erreurs du site de celles injectées par les extensions.

Supprimer `unsafe-inline` de `style-src`, la suite

Même logique pour les styles. J’avais quatre sources d’inline CSS :

Un bloc <style> dans custom.html — les CSS custom properties pour ma font Luciole
Des attributs style="" sur les badges de catégories — background-color: #2a9d8f; color: #fff;
Un attribut style="enable-background:..." sur un SVG (export Adobe Illustrator)
Des attributs style="" dans le formulaire Mailchimp du footer — display:none et un positionnement off-screen pour le honeypot anti-spam

Le <style> bloc : déplacé dans assets/scss/custom.scss, le fichier de personnalisation SCSS prévu par le thème.

/* Font family CSS custom properties */
:root {
 --article-font-family: "Luciole";
 --base-font-family: "Luciole";
 /* ... */
}

Les badges de catégories : toutes mes catégories utilisent les mêmes couleurs (#2a9d8f / #fff), définies dans le front matter de chaque _index.md. Le thème les injectait en style="" via le template article/components/details.html. J’ai surchargé ce template pour retirer le style inline et ajouté une règle CSS dans custom.scss :

.article-category a {
 background-color: #2a9d8f;
 color: #fff;
}

Le SVG : j’avais un SVG que j’avais ajouté à la main (un petit Robot mignon pour mon “AI Manifesto”) avec enable-background, qui est un attribut SVG 1.1 déprécié. Je l’ai simplement supprimé du fichier SVG source, sans impact visuel.

Le formulaire Mailchimp : le code HTML Mailchimp utilise style="display:none" pour masquer les divs de feedback et style="position: absolute; left: -5000px;" pour le champ honeypot (pour les robots qui s’inscrivent à ma newsletter 🤔). J’ai remplacé tout ça par des classes CSS dans custom.scss :

#mce-error-response,
#mce-success-response {
 display: none;
}

.mce-honeypot {
 position: absolute;
 left: -5000px;
}

La CSP finale

Après tous ces changements, plus aucun script ni style inline sur le site. La CSP peut donc être stricte :

default-src 'none';
script-src 'self' https://cdn.jsdelivr.net;
style-src 'self' https://cdn.jsdelivr.net;
img-src 'self' data:;
connect-src 'self' https://blogzwindler.goatcounter.com https://api-gateway.umami.dev https://cdn.jsdelivr.net;
font-src 'self';
frame-src https://widget.deezer.com;
frame-ancestors 'none';
base-uri 'self';
form-action 'self' https://zwindler.us15.list-manage.com;
manifest-src 'self';
media-src 'self'

Points notables :

default-src 'none' : par défaut, rien n’est autorisé. Chaque type de ressource doit être explicitement listé. C’est la politique la plus restrictive.
Pas de unsafe-inline nulle part : ni dans script-src, ni dans style-src
frame-ancestors 'none' remplace X-Frame-Options: DENY (plus moderne)
cdn.jsdelivr.net dans script-src, style-src ET connect-src : le thème charge vibrant.js (JS avec SRI), les CSS de PhotoSwipe (lightbox d’images) et les source maps associées depuis ce CDN
form-action autorise Mailchimp pour le formulaire d’abonnement dans le footer

Au final, de nombreux morceaux du thème de mon blog ont du être réécrit / overridés. Je suis un peu gêné d’avoir du en arriver là, mais c’était le prix à payer pour une note maximale 😂.

Nettoyage bonus : Mailchimp

En faisant l’inventaire des ressources externes, j’ai découvert un vieux widget Mailchimp dans la sidebar qui chargeait du CSS et du JavaScript depuis chimpstatic.com. Je ne l’utilisais plus : supprimé. Le formulaire d’abonnement dans le footer des articles a été gardé, mais nettoyé de ses style="" inline (voir plus haut).

Résultat final

De F (0/100) à A+ (125/100). Tous les tests sont verts.

Un grand merci à Antoine pour sa patience avec les débutants naïfs comme moi 😂 et ses super talks !

Optimisation webperf : AVIF et pré-compression pour le blog

Thu, 19 Feb 2026 17:00:00 +0200

Ce blog a presque 16 ans d’existence. Sur cette période, j’ai accumulé plus de 530 articles avec plus de 2700 images. Il y a quelques années, j’avais commencé à taper des limites (notamment quand j’ai essayer Gitlab pages chez Froggit) en atteignant les 500 Mo de medias.

J’avais fait une première passe d’optimisation, à grand coup de resize, jpegoptim et optipng et j’étais redescendu sous les 300 Mo. C’était pas mal, mais pas satisfaisant.

Puis j’ai vu le talk d’Antoine Caron (slashgear) et Mathieu Mure à Touraine Tech 2026 et j’ai enfin pris le temps de lâcher les “formats morts”.

Un peu de contexte

Ça fait un moment que je bricole l’infra et les perfs de ce blog. Si ça vous intéresse, les épisodes précédents sont ici :

Ça bouge pas mal sur le blog ! (2019) - De 5s à 1s en virant Wordpress pour Hugo
Ça bouge encore sur le blog (2025) - Nettoyage massif, retour auto-hébergé
Automatiser son site Hugo sans Github Action ou Vercel - Le setup nginx + webhook actuel

Quand j’ai commencé ce round d’optimisation, la note PageSpeed de la page d’accueil tournait autour de 70-85 en mobile selon les articles. Pas dramatique, mais on peut faire mieux !

Le talk qui a tout déclenché

À Touraine Tech 2026, Antoine Caron et Mathieu Mure ont fait un talk très clair sur l’optimisation des images web, qui pourrissent les perfs des sites web aujourd’hui.

Le message principal : les formats comme JPEG et PNG sont des “formats morts” (ou en tout cas vieillissants). À compression équivalente, les formats modernes comme AVIF prennent beaucoup moins de place, mais surtout, ils affichent des artefacts visuels bien moindres dans les hauts niveaux de compression.

J’avais failli faire une migration vers le WebP il y a quelques années, puis j’avais laissé tomber, par flemme et après quelques soucis techniques dont je ne me souviens plus trop.

Et finalement, c’est presque tant mieux, parce qu’avec AVIF, on peut compresser encore plus fort, sans que ça se voit. C’est exactement ce qu’il me fallait.

Side note : on m’a demandé une comparaison WebP vs AVIF, et Joseph a trouvé ça. C’est plutôt intéressant :

elementor blog - AVIF vs WebP : Quel format d’image règne en maître en 2024 ?

Conversion massive en AVIF

J’ai donc écrit un script qui :

Redimensionne les images trop grandes (> 1500px) pour les ramener à ~1 mégapixel
Convertit en AVIF avec avifenc (qualité 50, speed 6)
Met à jour les références dans tous les articles markdown

Et je l’ai lancé année par année, de 2026 jusqu’à 2010.

Les résultats

Année	Fichiers	Originaux	AVIF	Réduction
2010	12	0.4 MiB	0.1 MiB	74%
2011	27	1.8 MiB	0.7 MiB	63%
2012	6	0.4 MiB	0.1 MiB	78%
2013	2	0.1 MiB	0.1 MiB	56%
2014	43	5.3 MiB	1.0 MiB	81%
2015	214	10.7 MiB	3.7 MiB	65%
2016	231	12.1 MiB	4.1 MiB	66%
2017	428	23.7 MiB	9.1 MiB	62%
2018	142	7.5 MiB	2.4 MiB	68%
2019	136	12.1 MiB	2.9 MiB	76%
2020	228	23.6 MiB	5.6 MiB	77%
2021	187	31.6 MiB	4.8 MiB	85%
2022	237	29.2 MiB	7.5 MiB	74%
2023	253	43.2 MiB	7.8 MiB	82%
2024	259	34.2 MiB	8.0 MiB	77%
2025	255	31.2 MiB	6.8 MiB	78%
2026	44	6.8 MiB	1.8 MiB	74%
Total	2704	~274 MiB	~66 MiB	~76%

De PNG/JPEG qualité 90 à AVIF qualité 50 : entre 4 et 5 fois moins lourd.

Le plus satisfaisant, c’est que je ne suis pas capable de détecter visuellement de perte de qualité. Les screenshots de terminal et mes photos passent très bien en AVIF 50.

Pré-compression des documents HTML

Après la conversion AVIF, Antoine Caron (@slashgear.dev) m’a fait remarquer un truc :

Alors c’est pas mal déjà ! Je vois aussi que tes documents HTML ne sont pas compressés. Si ton blog est purement static, hésite pas à précompresser à balle et dire à ton server de servir les versions précompressées.

Effectivement, j’avais déjà gzip on; dans ma config nginx, mais c’est de la compression à la volée. Nginx utilise par défaut un niveau de compression modéré (niveau 6 sur 9) pour ne pas consommer trop de CPU.

server {
 server_name blog.zwindler.fr;
 root /usr/share/nginx/html/blog.zwindler.fr/public;
 gzip on;
 ...
}

Or, mon blog est 100% statique. Les fichiers ne changent qu’au rebuild. Ça veut dire qu’on peut les compresser une seule fois, avec le niveau maximum, et demander à nginx de servir directement les fichiers pré-compressés. Zéro CPU à chaque requête, mais surtout un meilleur ratio au final, car on peut compresser plus fort.

Côté build : `blog_refresh.sh`

J’ai ajouté les commandes de pré-compression après le hugo --minify :

# Pre-compress static files (gzip + brotli) for nginx gzip_static/brotli_static
# Zopfli: compatible gzip mais ~3-8% plus petit que gzip -9
if command -v zopfli &> /dev/null; then
 find public -type f \( -name "*.html" -o -name "*.css" -o -name "*.js" \
 -o -name "*.xml" -o -name "*.json" -o -name "*.svg" -o -name "*.txt" \) \
 -exec zopfli --i1023 {} +
else
 find public -type f \( -name "*.html" -o -name "*.css" -o -name "*.js" \
 -o -name "*.xml" -o -name "*.json" -o -name "*.svg" -o -name "*.txt" \) \
 -exec gzip -k -f -9 {} +
fi

# Brotli pre-compression (better ratio than gzip, ~15-25% smaller)
if command -v brotli &> /dev/null; then
 find public -type f \( -name "*.html" -o -name "*.css" -o -name "*.js" \
 -o -name "*.xml" -o -name "*.json" -o -name "*.svg" -o -name "*.txt" \) \
 -exec brotli -k -f -q 11 {} +
fi

Pour la compression gzip, Zigazou m’a conseillé d’utiliser Zopfli (apt install zopfli) plutôt que gzip -9. Zopfli produit des fichiers 100% compatibles gzip mais avec un meilleur ratio (~3-8% en moins). C’est plus lent, mais sur un blog statique où on compresse une seule fois au build, on s’en fiche.

En pratique, le gain de Zopfli est surtout un bonus : la majorité des navigateurs modernes supportent Brotli et recevront les .br, qui sont de toute façon plus petits. Le .gz ne sert que de fallback.

Chaque fichier index.html se retrouve ainsi avec un index.html.gz et un index.html.br à côté de lui.

Côté nginx

# Serve pre-compressed files generated at build time
gzip_static on;
brotli_static on; # nécessite libnginx-mod-http-brotli-static

# Fallback pour les contenus non pré-compressés
gzip on;
gzip_vary on;
gzip_min_length 1024;
gzip_types text/plain text/css text/xml text/javascript
 application/javascript application/json
 application/xml image/svg+xml;

Pour Brotli, sur Ubuntu 24.04+, les paquets sont dans les dépôts officiels :

sudo apt install libnginx-mod-http-brotli-filter libnginx-mod-http-brotli-static

Le gain mesuré

Un petit curl pour comparer la page d’accueil :

# Avec Brotli (ce que reçoivent les navigateurs)
curl -so /dev/null -w "%{size_download}" -H "Accept-Encoding: br, gzip" https://blog.zwindler.fr/
# => 6 206 bytes

# Sans compression
curl -so /dev/null -w "%{size_download}" -H "Accept-Encoding: identity" https://blog.zwindler.fr/
# => 32 886 bytes

-81% sur le HTML, de 33 Ko à 6 Ko transférés. Et on le vérifie dans Chrome DevTools : le header Content-Encoding: br confirme que Brotli est bien servi.

Et c’est pareil pour les autres fichiers textes statiques (CSS, JS).

Bilan

Optimisation	Avant	Après	Gain
Images (AVIF)	274 MiB	66 MiB	-76%
HTML page d’accueil (Brotli)	33 Ko transférés	6 Ko transférés	-81%

Le tout sans aucune dégradation visible de la qualité des images, et zéro impact CPU côté serveur pour la compression (puisqu’elle est faite au build).

Et des webperfs qui ont bien progressé, même en mobile :

Addendum

Un peu en vrac…

J’ai du repasser sur du webp pour les images en frontmatter car les sites sociaux (bluesky / slack / linkedin) ne supportent pas AVIF :-/.

On m’a conseillé zopfli en remplacement de gzip.

Pourquoi ne pas utiliser zopfli –i1023 en lieu et place de gzip -9 ?

Sauf que :

la très grande majorité supportent le brotli donc le gain sera marginal
Sur ma mini VM, le zopfli n’aboutissait jamais (bug ou trop intensif en CPU)
le projet n’est plus maintenu et qu’il a été archivé en octobre dernier.

Sinon, il y a libdeflate-gzip, sur le papier aussi bon que zopfli (pas testé) et semble encore maintenu.

On m’a aussi indiqué qu’il y a un paramètre nginx pour hériter les headers

https://nginx.org/en/docs/http/ngx_http_headers_module.html#add_header_inherit

Ce blog est (enfin) multilingue

Thu, 06 Nov 2025 12:00:00 +0200

Une évolution qui s’imposait

Après 15 ans d’existence de ce blog, et probablement 6 avec Hugo, j’ai enfin activé le mode multilingue propre de Hugo.

Pourquoi maintenant ? Plusieurs raisons :

D’abord parce que Quentin m’a trollé…
Mon lectorat est principalement francophone, mais j’ai aussi des lecteurs anglophones qui arrivent sur des articles techniques spécifiques. Jusqu’à présent, tout était mélangé sur la page d’accueil.
Côté référencement, c’était probablement un peu le bazar. Avoir des articles en français et en anglais mélangés sans distinction claire, ce n’est probablement pas optimal pour les moteurs de recherche.

Maintenant, chaque langue a son espace :

blog.zwindler.fr → page principale en français (n’affiche plus les articles en anglais)
blog.zwindler.fr/en → version anglaise (uniquement les articles en anglais, une dizaine pour le moment)

URLs conservées

J’aurais pu tout flinguer côté anglais et réécrire toutes les URLs pour rajouter le “/en”. Ou rajouter des alias avec Hugo (feature bien pratique que j’utilise quand je me suis foiré sur le lien mais que je l’ai déjà partagé un peu partout).

Pour l’instant, les URLs existantes restent inchangées. Les articles déjà publiés en anglais gardent leur URL sans le /en/.

Je verrai pour les prochains articles comment je gère ça.

L’implémentation technique

Pour les curieux, Hugo propose deux façons de gérer le multilingue :

Translation by file name : ajouter .en ou .fr avant .md
Translation by content directory : séparer les contenus dans des dossiers distincts

J’ai opté pour la seconde option, plus claire à mon goût :

languages:
 en:
 contentDir: content-en
 languageName: English
 weight: 10
 fr:
 contentDir: content
 languageName: Français
 weight: 20

Je ne sais pas si ça fonctionne avec tous les thèmes “out of the box”, mais le miens (https://stack.jimmycai.com/) mettait en avant que c’était supporté, donc j’en déduis qu’il faut faire gaffe à ça.

Des traductions à venir (peut-être ?)

Dans les prochains jours ou semaines, je ferai probablement quelques traductions d’articles, dans les deux sens :

Anglais → Français : certains articles très techniques et niches (comme Recompile Mimir’s “MetaMonitoring” Grafana Dashboards for Kubernetes) pourraient être traduits en français (ou non, c’est quand même giga niche)
Français → Anglais : des articles qui marchent bien en français et qui pourraient intéresser un public anglophone plus large

Je ne me mets aucun objectif, ni aucune pression. Si je trouve qu’un article mérite d’être traduit et que j’ai le temps/l’envie, je le ferai. Sinon, tant pis !

L’important, c’est d’avoir sauté le pas.

N’hésitez pas à me faire vos retours si vous constatez des problèmes de navigation ou d’affichage, j’ai un peu fait ça à l’arrache lundi soir pendant le live des copains Cuistops !

Références

Documentation officielle Hugo - Multilingual Mode

3 choses que vous ne savez pas sur Zwindler

Sun, 29 Jun 2025 14:00:00 +0200

Après toutes ces années à vous parler de Kubernetes, de containers et d’infrastructure, j’ai pensé qu’il était temps de vous révéler quelques petits secrets sur votre humble serviteur. Parce que derrière chaque nerd se cache parfois des surprises…

1. J’ai brièvement monté une entreprise en 2013-2014 qui n’a jamais eu un seul client

Ah, l’entrepreneuriat ! Ce rêve français de monter sa boîte entre copains et de révolutionner le monde. En 2013, avec 4 ex-collègues, nous étions pleins d’optimisme et convaincus que nous allions changer la donne.

L’idée ? Créer une ESN (Entreprise de Services du Numérique) qui capitaliserait fortement sur notre expertise en logiciels libres et open source pour faire de l’infogérance. Sur le papier, c’était génial : nous étions tous compétents techniquement, nous avions de l’expérience, et on se pensait plus malins que tout le monde.

Dovosys était créée !

Nous avons même intégré une pépinière d’entreprise pour nous accompagner dans cette aventure. Mais très vite, la réalité nous a rattrapés…

D’abord, nous étions tous en poste (et tous insatisfaits de ces postes) mais aucun d’entre nous n’était prêt à faire les sacrifices nécessaires pour vraiment démarrer l’activité. Le mieux aurait été qu’un d’entre nous démissionne pour bootstraper l’entreprise et chercher activement des clients, mais personne n’a osé franchir le pas. Donc tout était fait en cachette sur les pauses ou le soir. Fake it until you make it ça marche pas souvent super bien.

Ensuite, prendre des décisions à 5 (rapidement 4 car une des membres est partie dès le début), c’est un cauchemar. Les travaux n’étaient pas faits en temps et en heure. Certaines tàches n’étaient pas faites en temps et en heure. L’accompagnement de la pépinière n’était pas extraordinaire non plus, probablement du fait de notre manque de disponibilité en heures ouvrées.

À vrai dire, le mieux aurait été que je crée la boîte tout seul. Avec le recul, j’ai monté toute l’infra de virtualisation, écrit la plupart des parties techniques sur les dossiers, pondu la plupart des réponses aux appels d’offres publics…

Au final, nous n’avons jamais eu un seul client, et il a fallu clôturer l’entreprise. Sauf que l’entreprise n’a pas été correctement clôturée et je l’ai découvert un an plus tard quand les impôts ont toqué à notre porte… avec des pénalités de retard (un chiffre d’affaire à 0 n’empêche pas de payer certaines taxes).

A ce moment là (autour de 2015), mes associés étant totalement désengagés, j’ai dû faire tout le travail administratif de dissolution et liquidation tout seul. Un vrai parcours du combattant que j’ai d’ailleurs documenté dans deux articles détaillés : la dissolution et la liquidation, probablement plus à jour mais représentatif de ma galère.

Bref, cette aventure est une leçon d’humilité qui m’a appris que l’entrepreneuriat, ce n’est pas si facile, et que ce n’est certainement pas que de la technique. S’associer, en particulier avec des copains, c’est probablement souvent plus compliqué que prévu.

Je ne dirais pas que c’est un échec, je dirais que ça… ouais, en fait si, c’est un échec.

Les deux seuls points positifs que j’en retire :

avoir pu rencontrer des gens qui ont eu la même idée, en même temps, mais qui eux s’en sont sortis. Coucou Alexis, la bise à Sysnove (je ne sais pas si tu te souviens de moi, cela dit).
avoir pu en profiter pour me payer un avocat du travail pour décortiquer mon contrat de travail de l’époque (abusif sur plusieurs points). J’ai appris plusieurs tips sur le droit du travail à cette occasion :-p.

Note : j’ai tout gardé, les fichiers et les documents, je retombe dessus parfois, ça fait bizarre.

2. J’ai longtemps souffert d’anxiété sociale, que j’ai “soignée” à grand coup de conférences tech

Une *timidité** handicapante (*c’était pas ça le bon terme)

Voilà quelque chose que beaucoup de mes collègues ou amis ont du mal à croire quand je le raconte : je suis quelqu’un qui était, petit, très timide et réservé. Aller parler à des gens que je connais est parfois difficile, et alors les gens que je ne connais pas, n’en parlons pas. J’avais peu d’amis, en partie parce que garçon dans la cours de récrée dans les années 90, il fallait parler fort, faire le chef, n’avoir peur de rien. Des trucs de garçon, quoi. Tout l’inverse de moi.

Pendant longtemps, je me suis donc catégorisé comme “timide” faute de mieux. Je ne savais pas décrire ce que je ressentais réellement. Plus tard, j’ai aussi cru que j’étais “introverti”, mais ce n’était toujours pas ça (je le suis un peu aussi, mais ce n’est pas le fond du problème). En réalité, le vrai “mal” qui m’handicapait, c’était probablement plutôt de l’anxiété sociale, mais j’ai découvert ce terme très tard.

Devenu adulte, cette “timidité” est devenue franchement handicapante. Dans mon premier travail, il fallait parfois que j’appelle des clients et l’idée de décrocher le téléphone pour les appeler (et peut-être les déranger, ou pire, me tromper de numéro !) m’angoissait, au point de ne pas traiter les tickets dans les SLA fixés.

Une autre anecdote qui illustre bien mes difficultés : un soir, mes amis m’ont demandé de commander des pizzas. Je n’ai pas pu le faire en ligne, donc il fallait téléphoner. J’étais tellement mal à l’aise que j’ai appelé d’une toute petite voix, comme un enfant qui aurait fait une bêtise.

Mes copains m’ont charrié (ne sachant pas que c’était un obstacle difficile pour moi) pendant des années en mimant régulièrement cette scène et en déformant mes paroles : “Bonjour, je m’appelle Denis et je voudrais commander des pizzas”, avec une petite voix de gamin penaud.

Ça ne m’a jamais fait rire.

Le déclic des conférences tech

Le truc qui m’a vraiment aidé, c’est de commencer à faire des conférences tech. J’étais en admiration pour certains speakers, en particulier ceux se qualifiant ouvertement d’introvertis. Si eux pouvaient le faire, moi aussi, non ?

Et je me suis rapidement rendu compte que c’était une excellente idée. Quand on monte sur scène, une fois le trac initial passé, la foule n’est pas vraiment effrayante, c’est une masse informe et silencieuse. Mais surtout, être speaker et avoir des difficultés sociales confère un super pouvoir : celui de ne pas avoir à aller VERS les gens. C’est eux qui viennent vers vous, et pour vous parler du sujet dont vous venez de parler et que vous maîtrisez.

Cette technique m’a permis de parler avec une quantité incroyable d’inconnus (et même de me faire quelques copains de conf) et aujourd’hui, j’ai beaucoup moins de mal à aller voir un groupe de personnes en pleine discussion et à entamer la conversation. Même si ça me demande toujours un effort et que je me sens toujours un peu idiot, avec cette peur de déranger.

L’ironie, c’est que celui qui n’arrivait pas à commander des pizzas au téléphone donne des confs devant 800 personnes ou tape la discute avec le PDG de l’entreprise qui l’emploie !

Alors ok, ça fait un peu “bullshit LinkedIn” mais cette anecdote est 100% vraie, comme les deux autres.

3. D’où vient mon pseudo “zwindler”

Last but not least, l’origine de mon pseudo ! J’ai eu cette question tellement de fois que j’ai décidé de l’immortaliser ici. Certaines personnes que j’ai rencontrées en vrai après qu’on a échangé sur les réseaux sociaux pensaient même que “zwindler” était mon nom de famille !

En fait, ça vient tout simplement d’un jeu vidéo, mais l’histoire est plus complexe qu’un ado qui a choisi un handle au hasard, avec des Z et des R pour faire cool.

Ça date de l’époque où j’étais étudiant et que je jouais beaucoup à Counter-Strike Source. Malgré des centaines d’heures de jeu (j’avais beaucoup trop de temps libre lol), j’étais assez mauvais, même sur des serveurs pas particulièrement compétitifs.

Pour sortir mon épingle du jeu et éviter la frustration de toujours me faire “headshot” en suivant les tactiques classiques comme tout le monde, je me suis mis à expérimenter : me déplacer dans la map de façon non conventionnelle, me cacher dans des coins inhabituels, utiliser des armes boudées par les autres joueurs (pas de Deagle + M4 + HE + casque pour moi).

Je ne vais pas mentir, souvent ça ne marchait pas, en particulier contre des “pros”. Mais de temps en temps, ça me permettait quelques coups d’éclat où j’arrivais à renverser le cours de la partie quasiment à moi tout seul, grâce à l’effet de surprise et un peu de créativité (genre, balayer 5 ou 6 membres de l’équipe adverse à moi tout seul en 12v12).

Mes amis ont pris l’habitude de m’appeler “l’escroc” car ils étaient agacés de perdre dans ces conditions. Le surnom est resté et j’ai voulu l’angliciser en “swindler”. Le pseudo étant déjà pris sur de nombreux réseaux sociaux, j’ai donc simplement changé “swindler” en “zwindler” (et parfois zwindl3r quand zwindler est pris, comme sur discord ou twitch par exemple).

Et puis les années ont passé, le pseudo a suivi mes pérégrinations numériques : ce blog, Twitter, GitHub… Et aujourd’hui, il n’est pas rare qu’on me connaisse mieux sous le pseudo “zwindler” que sous mon vrai prénom ! C’est d’ailleurs pour cette raison que j’avais fait imprimer des stickers avec écrit @zwindler pour les coller sur les badges de confs. Je ne compte plus le nombre de “Aaah mais c’est TOI zwindler !” que j’ai entendu.

Fun fact : en 2015, mes collègues blaguaient que j’étais un “expert en malinerie”, à la fois en référence à Denis la Malice (ça m’a suivi un moment), mais aussi et surtout pour ma capacité à trouver des solutions créatives à des problèmes complexes. Trait que j’ai su conserver en milieu pro :)

Voilà, maintenant vous savez tout !

Enfin, presque. Il faut bien que je garde quelques mystères pour les prochains articles…

15 ans que je partage mes bidules sur ce blog

Mon, 28 Apr 2025 18:00:00 +0000

Ce blog à 15 ans (et une semaine… parce que je suis à la bourre)

Ca me parait assez incroyable de me dire que j’ai un projet perso et hobby depuis 15 ans…

Je pense que je n’ai jamais fait quelque chose aussi longtemps de ma vie. Je ne fais de la course à pied “que” depuis 10 ans, par exemple. Je suis resté dans une entreprise au maximum 6 ans (pour l’instant).

Et en vrai, je n’imagine même pas qu’un jour, j’arrêterai.

Le temps passe

Je ne regarde même plus vraiment les stats. Un peu, par curiosité, surtout depuis que je teste https://hakanai.io/ (clin d’oeil pas très discret ;P).

J’ai beaucoup moins de retours depuis que j’ai coupé les commentaires en passant en full statique et je ne suis pas spécialement triste. Bien sûr, je suis toujours hyper content quand quelqu’un me dit qu’il/elle aime bien me lire, ou que j’ai pu aider avec un article.

Mais ne pas en avoir ne me démotive pas.

La course à être le premier dans la page Google ne m’intéresse plus (pas sûr que ça m’ait jamais importé cela dit ?). J’ai plus envie qu’on me donne de l’argent pour me récompenser.

Et c’est tant mieux :)

Les blogs disparaissent

C’est le constat que je faisais dans cet article plus tôt en début d’année (Ça bouge encore sur le blog), suite à un gros nettoyage des liens morts sur ces pages.

Alors, oui, OK. Dans le tas, il y avait surtout des pages de KB VMware, Dell ou HP complètement obsolètes.

Mais dans le tas, il y a aussi tout un tas de blogs de gens que j’admirais depuis des années. Je pense même que certains admins de ces blogs ne sont plus parmi nous, pas juste leurs blogs.

Désolé pour le coup de blues.

“Au secours, mon manager me demande des KPIs”

(Ce n’est pas un message pour toi Raph, c’est un clin d’oeil à un talk :-P)

Même si j’ai plus les yeux rivés dessus, j’aime quand même un peu les chiffres.

En 15 ans de blog, j’ai atteint les 500 articles (quasiment… 497, et 3 brouillons). Ces dernières années, j’en écris environ 40 par an. Chaque article prend entre 2 et 10 heures à écrire, veille techno et tests inclus.
Ca représente plus de 580000 mots, presque 49 heures de lecture non-stop (à 200 mots par minutes).
Dans le top3 des articles les plus consultés, il y a ma fameuse (world famous!) recette de pancakes sans PLV (le trafic vient surtout de Google) et je pense que cette info absurde est représentative de ma personnalité.
Il y a environ 20k vues sur ce blog tous les mois, ce qui est stable depuis 2019, année où le blog “a arrêté de croitre” en popularité.

Autres supports / formats ?

De temps en temps, je me demande si je ne devrais pas essayer d’autres formats (plus populaires ?).

Mais :

Je suis trop perfectionniste pour faire des lives casses-gueules comme les copains de Cuistops par exemple.
Je n’aime pas trop ma voix, et ce n’est pas terrible pour un podcast, moyen pour youtube.
J’aime bien les confs, surtout pour les discussions qui suivent, mais je veux pas en faire mon métier.
J’ai écrit un livre, c’est long XD.
Je n’ai pas encore testé de donner des cours, mais c’est sur la “bucket list”.

Donc, je pense que mon blog a encore de beaux jours devant lui.

De toute façon, le plus grand lecteur de mon propre blog, c’est probablement moi ;-).

Conclusion

15 ans, ça mérite bien un gros cadeau pour mes lecteurs / lectrices, non ?

J’avais déjà théoriquement libéré tout mon travail en lui appliquant une licence Creative Commons BY-SA 4.0. Pour aller jusqu’au bout de la démarche, j’ouvre maintenant les sources de mon blog :)

github.com/zwindler/blog.zwindler.fr

Vous pouvez tout copier, même pour des projets commerciaux*. Have fun!

*dans la limite de la CC BY-SA, c’est-à-dire que dans vos modifications, il faut me citer comme auteur de l’oeuvre d’origine et partager vos modifications dans les mêmes conditions. Plus d’infos sur l’article “Le contenu du blog passe en Creative Commons CC BY-SA 4.0”.

Ça bouge encore sur le blog

Wed, 15 Jan 2025 20:00:00 +0200

À la toute fin 2019 (il y a cinq ans à 2 semaines près donc, c’est marrant comme j’ai une façon cyclique dans mon écriture), j’écrivais un long article pour détailler les nombreux (à l’époque) changements opérés sur le blog.

Ça bouge pas mal sur le blog !

Les plus gros d’entre eux étant la suppression de toute forme de tracking intrusif, en particulier ceux des boites comme Google (AMP, Analytics, Adwords), Amazon (liens sponsorisés) et le début d’un virage vers l’abandon de Wordpress (qui m’aura finalement nécessité quelques années de plus pour être totalement terminé, on en reparlera).

Creative Commons (CC BY-SA 4.0)

Je passe tout le contenu qui m’appartient sur ce blog sous licence Creative Commons

Voilà la décision aussi militante que radicale que j’ai prise le 3 octobre dernier, suite à un énième vol de propriété intellectuelle entre blogueurs et le drama qui en a suivi :

Le contenu du blog passe en Creative Commons CC BY-SA 4.0

Rétrospectivement, je me demande vraiment pourquoi j’ai attendu aussi longtemps pour le faire, car cette décision colle parfaitement à ma philosophie de vie depuis plusieurs années.

Ce n’est peut-être pas le cas de tout le monde (c’est leur droit), mais ce site n’existe pas pour me faire gagner de l’argent.

Je n’ai aucune raison de le monétiser, quelle qu’en soit la forme.

Son but unique est le partage de connaissance. Et je n’ai pas la prétention d’être le meilleur ou de connaître la meilleure façon de diffuser cette connaissance.

TL;DR : vous pouvez donc copier, améliorer, redistribuer tout ou partie de ce blog, et même tirer directement ou indirectement des revenus, tant que je suis cité quelque part comme l’auteur initial. Ça me fait plaisir si vous en profitez. Enjoy.

Pas d’IA

J’ai adhéré au AI manifesto, popularisé par Cassidy Williams / cassidoo.

Je pars du principe que si je ne prends pas la peine d’écrire moi-même le contenu de ce blog, vous ne devriez pas prendre la peine de le lire.

Je sais que cette décision est plus clivante que le passage du blog en CC BY-SA 4.0, et que plusieurs personnes dans ma sphère tech sont en opposition avec ce principe. Là aussi, c’est leur droit.

Moi, j’adhère totalement à cette vision.

Aucun de mes articles n’est écrit par l’IA. Ils ne sont même pas relus par des IA pour les “améliorer”.

Note pour plus tard, je vais aussi essayer également de ne plus générer de visuels avec l’IA pour des problématiques de propriété intellectuelle.

Fin de la migration Wordpress vers Hugo et ménage dans les liens morts

Lorsque j’avais entamé la migration Wordpress vers Hugo en 2020, je n’avais pas nettoyé tout le code qui avait été importé de Wordpress. Pas mal d’images restaient dans un format bâtard non-markdown, avec des balises HTML chelou.

De la même manière, ça doit faire plus de 10 ans que je n’ai pas fait une passe sur mon site pour nettoyer les liens morts derrière moi.

Comme je suis quelqu’un d’un peu têtu/bourrin, je me suis mis en tête qu’il était temps de finaliser cette migration, que j’ai quasiment faite d’une traite (je n’ai écrit que 2 articles entre le début et la fin). Quelques exemples :

Même à coup de regex et de tooling python pour automatiser le plus possible, cette énorme passe de nettoyage a duré plusieurs sessions de blogging, étalées sur plusieurs semaines (probablement 10 heures de travail). Quelques stats pour vous donner une idée :

360 fichiers modifiés (sur un peu moins de 500 articles)
3600 lignes modifiées
plus de 200 liens morts
plus de 120 contenus retrouvés (souvent manuellement) sur Internet Archive

Je ne remercie pas du tout HPE, VMware, Dell EMC, Microsoft, d’avoir supprimé la totalité des ressources sur lesquelles j’ai bloggé dans les années 2015 et +. Toutes les docs, les forums, les KBs, les fichiers de configuration ont été annihilés. Si une partie de ces contenus étaient effectivement obsolètes, ce n’était pas le cas de tous.

Je ne remercie pas non plus les boites comme Oracle, SAP ou autre qui ont racheté de plus petites entités et détruit des billets de blogs corporate pourtant toujours utiles aujourd’hui et que je n’ai pas toujours pu retrouver sur Internet Archive, malheureusement.

Je ne remercie toujours pas les entreprises ou les logiciels open source tels que Ansible, pfSense ou encore XWiki (que j’apprécie par ailleurs) qui ont décidé un jour de changer l’arborescence de leur site / leur documentation officielle sans mettre en place de redirection correcte…

Enfin, j’ai pu constater avec tristesse que de très nombreux blogs de petites entreprises ou de particuliers, dont certains que j’aimais beaucoup, avaient disparu d’Internet sans laisser de traces… Souvent autour de 2020… J’espère ne pas y voir un signe lugubre 😔.

Au revoir, Clever Cloud

Depuis que j’ai migré de Wordpress à Hugo (changement que je bénis chaque jour… que c’était horrible ce CMS de la mort), j’ai un peu hésité sur le provider pour héberger le blog statique (et l’infra pour le construire).

J’ai fait de l’auto-hébergé, vercel, froggit (gitlab runners + gitlab pages), de l’auto-hébergé encore. Puis finalement, pour tester le produit des copains, j’ai essayé Clever Cloud.

Migration du blog sur Clever Cloud

Au début, j’étais plutôt content, et j’ai même fait quelques articles de plus pour améliorer mon expérience (sur les conseils avisés de David). Mais au fil des mois, je me suis rendu compte que l’expérience utilisateur n’y était pas.

Pousser un commit sur un remote git spécial pour mettre à jour mon blog, ou alors déclencher une github action au commit, qui lance la CLI avec un token, qui relance un build, ce n’est pas dingue.

Et avoir une facture entre 7 et 8€ par mois (que j’aurais pu optimiser un peu, certes) pour ne pas avoir de compatibilité IPv6 (une régression par rapport à mon site auto-hébergé en 2021), et autant de configuration manuelle et de “moving parts” pouvant planter à chaque commit, ce n’était vraiment pas pour moi.

Le dernier mois, j’ai eu de nombreux plantages, que ce soit la partie Github action, la partie build qui ne rendait pas la main, ou la partie Run qui ne se lançait pas correctement, ce qui laissait mes commits errer dans les limbes (et le compteur de temps d’instance M qui va avec).

Je ne pense pas qu’admettre que le produit n’était pas pour moi ne remette d’aucune façon en question la qualité de ce qui est fait chez Clever en tant que PaaS. Mais il était grand temps de repartir sur un setup plus simple à base d’auto-hébergement, que j’avais heureusement documenté (sur ce blog, ahahah) et que j’ai remonté en moins d’une soirée :

Automatiser son site Hugo sans Github Action ou Vercel

Ce blog est donc hébergé sur une VM ultra cheap à 1,20€ par mois chez IONOS, se rebuild en moins d’une minute à chaque commit via un webhook et est compatible IPv6 sans effort.

À ce prix-là, je ne m’attends pas à un très bon support utilisateur en cas de problème. Mais en réalité, je n’ai pas de SLO à tenir et je peux migrer n’importe où en très peu de temps (la preuve avec les multiples migrations faites ces cinq dernières années).

Analytics

Pour ne pas m’embêter avec le RGPD (et ne pas avoir de bandeau à mettre), et n’utilisant même pas 1% des capacités de Matomo, j’avais retiré toute forme d’analytics sur un coup de tête.

Sur les conseils de Pierre, j’ai quand même remis le minimum l’an dernier (j’ai un an tout pile d’historique maintenant) goatcounter.com, un site d’analytics gratuit qu’on peut auto-héberger ou utiliser gratuitement en SaaS.

C’est moche, mais ça marche. Et ça me permet de savoir les articles qui marchent le mieux, comme ma fameuse recette des pancakes à la banane sans PLV (j’en parlais dans l’article Dans le rétro de 2024 : trop de side projects)

Et comme c’est un peu moche et que je suis les aventures d’Hugo Lassiège avec attention, je teste aussi en parallèle son tout dernier produit d’analytics spécial blogueurs BlogTally

L’objectif étant de faire un outil de web analytics mais dédié aux bloggers

Je vous en dirais plus quand j’aurai de quoi comparer par rapport à toutes les solutions que j’ai pu tester jusqu’à présent.

Être speaker en conférence ne triplera pas votre salaire (sauf exceptions)

Sun, 28 Apr 2024 12:00:00 +0200

Note : cet article est la version longue / version litteraire, d’un long thread Twitter (lien mort, j’ai quitté Twitter), et du débat qui a suivi. Il s’agit de mon expérience personnelle et tout le monde n’est pas d’accord avec mon point de vue. YMMV comme disent les anglosaxons.

Marronnier et contexte

Début avril, j’ai lu un message qui m’a fait tiquer sur Twitter.

Grosso modo, une personne (j’irai même jusqu’à dire “un habitué”) raconte que “les gens” qui vont faire des talks en conférence, le font pour l’argent, allant même jusqu’à affirmer qu’un speaker lui aurait secrètement avoué que depuis qu’il était speaker, son salaire avait été multiplié par 3.

Argent, théorie du complot, société secrète. Tout ce qu’il faut pour buzzer sur X.

Alors bien sûr, quand d’autres personnes viennent expliquer que non, eux le font par passion, l’énergumène leur répond par un GIF d’une personne qui nage dans des billets de banque avec comme légende “la passion en question” (ça vous donne une idée du niveau de l’argumentaire du bonhomme).

Donc allons-y : qu’est-ce que j’en pense, moi ?

Me, myself and I

Je suis speaker depuis 2018, avec une trentaine de talks, quelques podcasts, quelques interviews à mon actif. J’imagine que je rentre donc dans la catégorie des “habitués” des confs en France dont on parle ici.

Plus récemment, je suis aussi organisateur de conférences (KCD France 2023, BDX I/O 2024).

Et avant ça, je blogue ici depuis 2010, avec plus de 400 articles techniques, des milliers d’heures (sur mon temps personnel) à faire de la veille, tester des trucs, rédiger, poster, améliorer ce blog. Un investissement en temps et en énergie considérable.

Pour rappel (ou info ???), tout ceci est entièrement bénévole. L’écosystème tech français ne rémunère pas les speakers ou les orgas en conférence (sauf exceptions très rares). Je ne tire pas un centime de cet engagement personnel.

Et la question est donc : est-ce qu’en échange de tout cet engagement personnel pour la communauté, j’ai multiplié mon salaire par 3 depuis 2018 ?

TL;DR : non. J’ai un très (très) bon salaire, mais clairement, je n’ai pas triplé mon salaire depuis 2018. Ni même doublé. Et les confs n’y sont pour rien dans les augmentations que j’ai eues (le full remote a eu bien plus d’impact, par exemple).

Back to reality

On passe notre temps à nous dire qu’il faudrait avoir des side projects pour se différencier au moment du tri des CVs ou pendant les entretiens.

La réalité que moi, j’ai expérimenté est tout autre.

La plupart du temps, lors des entretiens que j’ai pu passer ces cinq dernières années, la mention (pourtant bien visible sur le CV et j’insiste oralement) de mon blog est ignorée. Ça me met un peu en rogne, car j’en retire une grande fierté.

Pour ce qui est de l’expérience en tant qu’organisateur de conférences ou de mon “habitude” d’aller en conférence partager des sujets, dans la grande majorité des cas, c’est aussi ignoré. Au pire, c’est vu comme une contrainte plus qu’un atout. Pour illustrer ça, on m’a dit lors d’un processus de recrutement :

Denis, c’est bon ! J’ai négocié avec le CTO, tu pourras aller en conférence de temps en temps.

Euh… Merci ?

Note : pour être parfaitement honnête, il y a eu deux exceptions, où c’était vu comme quelque chose de chouette, mais avec un peu de méfiance quand même, notamment sur la fréquence ou sur le hype driven development.

Pour beaucoup d’entreprises, sortir du cadre de ce qui est prévu pour les salariés est impensable. Et comme beaucoup n’ont pas ou plus (post COVID) de stratégie concernant la marque employeur ou les contributions externes à l’écosystème tech, aller en conférence présenter le travail de l’entreprise n’est pas vu comme une partie de mon travail en tant que “staff engineer”, mais comme un “privilège”.

Mon actuel employeur accepte que j’aille en conférence et que je prépare en partie mes sujets sur mon temps de travail, et me paie le transport et l’hébergement pour aller à ces conférences.

C’est déjà mieux que beaucoup de speakers qui doivent tout faire sur leur temps perso, et parfois doivent poser des congés, voire se payer les transports eux même quand ils sont pris comme speaker. Certains speakers dépensent beaucoup d’argent pour partager leur passion et ça me fait ch**r qu’on fasse croire qu’ils le font pour s’enrichir, alors que c’est l’inverse.

Tout n’est pas à jeter non plus

Il y a cependant des avantages réels à participer à des conférences en tant que speaker.

D’abord, ça force à bosser et se documenter sur des sujets que vous pensez maîtriser. Le risque à ne pas le faire, c’est que vous disiez une énormité et qu’une personne vous le fasse bruyamment remarquer. Pas super agréable. Donc, on se documente et on apprend beaucoup.

Autre avantage indéniable, ça entraîne à la prise de parole.

Ça peut paraître difficile à croire, car j’ai l’air à l’aise en public aujourd’hui, mais j’ai longtemps été paralysé en groupe par une phobie sociale.

Aller en conférence est un moyen (certes un peu brutal) de dépasser ce genre d’angoisses : après le talk, les gens viennent vers vous d’eux-mêmes, vous n’avez pas à combattre l’angoisse de leur parler, et en plus, ça sera un sujet que vous maîtriserez.

Le vrai “game changer”, le réseau

Dernier point, qui a été évoqué sur Twitter à un moment : ça agrandira considérablement votre réseau.

Toutes les opportunités intéressantes que j’ai eu récemment, j’ai su qu’elles existaient grâce à mon réseau.

Attention, ça ne veut pas dire que j’ai directement eu le poste ! J’ai passé les entretiens comme les autres et j’ai ensuite eu le poste, ou pas !

J’ai juste eu connaissance de ces opportunités GRÂCE à mon réseau, sans passes droits.

Cependant, il y a 1000 autres façons de se faire un réseau pro. Les conférences ne sont qu’une manière parmi d’autres et je ne vois personne s’insurger contre ça. Pourquoi se faire un réseau en conférence serait une mauvaise chose (spoiler, ça n’en est pas) ?

Conclusion

On en a beaucoup discuté sur Twitter et j’ai échangé avec des gens pour qui faire des conférences avaient eu un impact significatif sur leur carrière. Tant mieux pour elles/eux, c’est mérité !

Mais je pense qu’il ne s’agit pas de la mentalité majoritaire des entreprises, en particulier en France.

Sauf exceptions, faire un amphi bleu DevoxxFR ne vous rendra pas riche.

Tripler votre salaire (ou même juste l’augmenter) n’est pas une fin en soi. À vous de savoir si vous avez besoin de cet argent ou pas. Avoir un salaire à six chiffres peut quand même faire de vous un individu triste comme les pierres.

Bref : ne soyez pas speaker (ou écrire un blog, ou écrire un livre tech) parce que vous pensez que vous allez en retirer de l’argent. Faites-le parce que partager sa connaissance, c’est hyper gratifiant et ça vaut tous les dramas Twitter.

Blog on Zwindler's Reflection

Refonte de la page Conférences : data-driven avec Hugo

Le problème

L’approche : données + layouts + CSS

Les données YAML

data/conferences.yaml

Les pages Markdown minimalistes

Le layout Hugo

Le CSS : des cartes partout

Bilan

De F à A+ sur HTTP Observatory : sécuriser les headers de mon blog Hugo

Le déclic

Ce que teste HTTP Observatory

Étape 1 : les headers “faciles”

Étape 2 : Content-Security-Policy (la vraie difficulté)

Inventaire des ressources externes

Le problème des scripts d’analytics externes

Supprimer unsafe-inline de script-src

Supprimer unsafe-inline de style-src, la suite

La CSP finale

Nettoyage bonus : Mailchimp

Résultat final

Optimisation webperf : AVIF et pré-compression pour le blog

Un peu de contexte

Le talk qui a tout déclenché

Conversion massive en AVIF

Les résultats

Pré-compression des documents HTML

Côté build : blog_refresh.sh

Côté nginx

Le gain mesuré

Bilan

Addendum

Ce blog est (enfin) multilingue

Une évolution qui s’imposait

URLs conservées

L’implémentation technique

Des traductions à venir (peut-être ?)

Références

3 choses que vous ne savez pas sur Zwindler

1. J’ai brièvement monté une entreprise en 2013-2014 qui n’a jamais eu un seul client

2. J’ai longtemps souffert d’anxiété sociale, que j’ai “soignée” à grand coup de conférences tech

Une timidité* handicapante (*c’était pas ça le bon terme)

Le déclic des conférences tech

3. D’où vient mon pseudo “zwindler”

15 ans que je partage mes bidules sur ce blog

Ce blog à 15 ans (et une semaine… parce que je suis à la bourre)

Le temps passe

Les blogs disparaissent

“Au secours, mon manager me demande des KPIs”

Autres supports / formats ?

Conclusion

Ça bouge encore sur le blog

Creative Commons (CC BY-SA 4.0)

Pas d’IA

Fin de la migration Wordpress vers Hugo et ménage dans les liens morts

Au revoir, Clever Cloud

Analytics

Être speaker en conférence ne triplera pas votre salaire (sauf exceptions)

Marronnier et contexte

Me, myself and I

Back to reality

Tout n’est pas à jeter non plus

Le vrai “game changer”, le réseau

Conclusion

`data/conferences.yaml`

Supprimer `unsafe-inline` de `script-src`

Supprimer `unsafe-inline` de `style-src`, la suite

Côté build : `blog_refresh.sh`

Une *timidité** handicapante (*c’était pas ça le bon terme)