BisonBlog

Comment j'ai codé une application Flutter pour ma Kindle en une matinée avec Open Code

Joseph Humbert — Wed, 14 Oct 2026 00:00:00 +0000

Hier soir, je lisais sur ma Kindle des articles compilés dans un e-book pour limiter au maximum le temps passé sur mon téléphone — une habitude qui découle de La friction salutaire. Et évidemment, ça n’a pas raté : en pleine lecture, je tombe sur un lien vers un autre article passionnant.

Pas de connexion sur la liseuse à ce moment-là. Je sors mon téléphone pour chercher la page, mais je sais très bien comment ça se termine : je ne lis jamais l’article en question et je me perds pendant un quart d’heure à papillonner sur l’écran. C’est un piège récurrent dès qu’un lien m’intéresse en pleine session de lecture.

Pour couper court à ça, j’ai voulu un truc simple : une application de bookmarks qui automatise l’envoi de ces contenus directement vers ma Kindle pour les lire plus tard, au calme et hors-ligne.

Ce matin au réveil, j’ouvre mon assistant préféré dans mon terminal : Open Code.

Je démarre avec une description assez basique du projet et une interface minimale en Flutter. Je lui demande d’effectuer des recherches préalables, ce qu’il fait sans broncher. J’active ensuite la compétence « Grill Me » pour qu’il me passe au grill : une série de questions ciblées pour stress-tester le besoin et poser tous les détails avant de coder.

Puis je lui impose mes consignes habituelles :

Travailler en TDD (Test-Driven Development) : rédiger les tests avant le code pour qu’il valide un maximum de choses par lui-même ;
Initialiser le dépôt Git et commiter régulièrement ;
Déployer une première release dès que tous les tests passent et que l’app tourne.

Résultat : en seulement trois allers-retours (trois versions de test), l’application était totalement fonctionnelle.

Le design correspond exactement à ce que je voulais. L’expérience utilisateur reste perfectible, certaines finitions méritent d’être peaufinées et j’ai déjà plein d’idées pour la suite, mais le cœur du système est là et tourne parfaitement. En cumulé, le modèle a bien dû mouliner 2 h 30, mais le résultat est là : une application impeccable sur mon téléphone Android, prête à l’emploi.

Le code source et la release sont disponibles ici :
👉 GitHub - Tahlasandale/articles-kindle

Si vous possédez une Kindle, un compte Google et un appareil Android, n’hésitez pas à tester l’outil et à me partager vos retours ou vos idées de fonctionnalités !

Les ordinateurs qui me font rêver

Joseph Humbert — Tue, 13 Oct 2026 00:00:00 +0000

C’est un peu ma liste au Père Noël des ordinateurs qui me font rêver, des beaux Mac aux vieux Thinkpads en passant par les machines conçues pour durer.

Sommaire

Commercial : les Mac

Très fan des Mac depuis que j’en ai utilisé un en stage et que j’ai utilisé un MacBook Air de 2015 en daily.
Ce sont de beaux objets.

Mac Intel

Les Mac Intel vont vite ne plus coûter cher, et on pourra les passer sous Linux en gardant ces beaux objets avec des composants fiables (sauf les batteries).
J’ai donc un intérêt pour toutes les gammes de Mac Intel i5 et i7 : MacBook, iMac et Mac mini.
L’idée : les passer sous un Linux ultra léger et en faire des machines de productivité tournées principalement vers une utilisation en terminal.

Même démarche que dans La friction salutaire : s’approprier une belle machine au lieu de la jeter.

Mac silicon / récents

Les Mac avec des puces Apple silicon restent dingues en termes de performances. Les Mac M1 me semblent suffisants pour mon usage.
Je suis surtout intéressé par le MacBook de cette gamme, pour profiter de la puissance et de la portabilité, idéalement avec l’écran le plus petit possible (ultraportabilité).
Très intéressé également par le MacBook Neo, pour bénéficier de macOS à petit prix. Encore une fois, mon utilisation d’un ordinateur est vraiment tranquille : Firefox, Obsidian, VS Code, LocalSend, Syncthing, explorateur de fichiers, gestionnaires d’écran, de Bluetooth et de Wi-Fi, terminal, et des outils TUI et CLI à foison.

Je détaille ca dans mes outils bureautiques

Niche : les PC

Thinkpads et autres

Des vieux ordinateurs soi-disant obsolètes, mais construits à l’épreuve du temps.
Pas chers sur Leboncoin ou eBay.
Un hobby : bidouiller et optimiser son système pour son usage.
Mon daily driver est une machine de ce genre.
Pour la plupart des gens, avec un Linux léger, ça suffit à leur usage quotidien, et c’est carré.
Pour moi, ça suffit à mon usage de dev, alors imaginez pour une bande de gens.
Exploiter la puissance des outils TUI, et la satisfaction de naviguer sans utiliser sa souris : sérieux, c’est de la frappe, branchez-vous.
Pour moi, c’est une mine d’or :
- Une vieille tour peut devenir votre serveur, moins cher qu’un NAS dédié mais tout aussi fonctionnel. C’est exactement le basculement que j’ai fait dans Le Réveil de la bête, où une tour de récupération a pris la place du Mac noyé.
- Un PC obsolète sera plus puissant qu’un Raspberry Pi, mais ne permettra pas tous ses usages.
- Un vieux PC portable bien configuré peut devenir votre daily driver et vous fournir une UX de dingue : vous vous êtes taillé un outil sur mesure, et la difficulté de l’apprentissage rend la satisfaction de l’utilisation simplement incroyable.

Au sujet de la récupération de vieux pc: Sauvetage express : dual boot Windows 10 / Debian 13, et From bouse to tank

Ordinateurs conçus pour durer

Plus niche et plus cher, mais intéressant.
Globalement le même prix qu’un Mac : environ 1 000 €.
Conçus pour être réparables et extensibles, et ça, c’est bien de ouf.
Souvent conçus par des passionnés, donc SAV réactifs et machines bien pensées.
Composants modernes et à jour, mais remplaçables quand ils deviendront obsolètes.
Très intéressant si vous avez l’usage de la puissance de ces machines, et l’argent, et/ou la passion de créer votre environnement de travail vous-même.
Exemples :
- Framework
- MNT Reform
- Les Pinebook et Pinebook Pro de Pine64
- Les PC de Purism
- Star Labs
- Tuxedo Computers
- …

Mes notes à ce sujet : ces machines n’ont pas tout à fait la même philosophie que celle de ce gars (Ploum) — dont j’ai déjà parlé dans La friction salutaire.

Pour aller plus loin

Si cette dernière partie vous parle, allez lire les deux articles de Ploum qui m’ont fait réfléchir à tout ça :

The computer built to last 50 years (2021)
Reinventing How We Use Computers (2022)

Mes outils bureautiques pour ne plus dépendre des GAFAM

Joseph Humbert — Fri, 09 Oct 2026 00:00:00 +0000

Comme vous le savez, pour ce qui est de la bureautique, on est presque toujours logé à la même enseigne : soit coincé chez Microsoft, soit enfermé chez Google. En entreprise, je bosse d’ailleurs avec la suite Google à foison. On ne va pas se mentir : c’est ultra pratique. Tout est connecté, synchronisé en temps réel, l’intégration de Gemini est propre et fluide… mais confier l’intégralité de sa vie numérique à ces silos reste un vrai problème.

Si tu veux une suite bureautique complète, boostée par un zeste d’IA bien calibrée, et que tu as un profil un peu geek, il existe une alternative solide : te tourner vers la philosophie local-first et les formats ouverts.

Voici ma boîte à outils du quotidien pour reprendre le contrôle de mes machines sans me couper du reste du monde.

La stack en un coup d’œil

Outil remplacé	En solo (local & souverain)	À plusieurs (collaboratif temps réel)
Word	Markdown (Micro / Obsidian) + Pandoc	Google Docs / Framapad / Overleaf
PowerPoint	Obsidian (plugin Slides)	Gamma AI
Excel	CSV + Python (Pandas)	Grist
OneDrive	Syncthing	MEGA
Teams	Inutile	Jitsi Meet

1. Word : l’écriture et les notes

Que ce soit chez Microsoft avec Word ou chez Google avec Docs, le besoin de base reste le même.

En solo : prendre des notes de cours (et des notes pour tout le reste), insérer des images, poser des formules mathématiques propres, tracer des schémas Mermaid, rédiger des courriers administratifs et pouvoir exporter en PDF pour transmettre des documents impeccables.
En multi : pouvoir écrire à deux ou plus sur le même document, en direct et sans prise de tête.

En solo : la puissance du Markdown brut

En local, tout tourne autour du Markdown. C’est un langage de balisage léger, ouvert et lisible même sans aucun logiciel spécialisé. En quelques caractères simples (#, *, -), on structure des titres, des listes et de la mise en page. Ça pèse trois fois rien, ça ne dépend d’aucun format propriétaire et la syntaxe s’apprend en moins d’une semaine.

Pour la prise de notes au vol dans le feu d’un cours, j’édite souvent mes fichiers directement dans Micro, un éditeur de texte dans le terminal ultra basique et sans fioritures.

Quand j’ai besoin d’une vue plus soignée ou d’une mise en page avancée, j’ouvre Obsidian. Même si l’application est propriétaire, sa philosophie reste très ouverte : les fichiers restent sur mon disque et l’écosystème de plugins communautaires est gigantesque. On peut modeler l’interface à son image (jusqu’à reproduire un espace façon Notion), profiter de la live preview, imbriquer des schémas Mermaid, coller des images et même intégrer des iframes.

Le seul piège avec Obsidian, c’est qu’on peut vite passer des heures à bidouiller ses réglages au lieu de bosser — c’est pour ça que je reviens souvent à Micro pour rédiger vite. Mais pour l’export, c’est redoutable : on peut convertir en docx via Pandoc, ou exporter directement en PDF en conservant fidèlement le thème visuel appliqué dans l’application.

En multi : Framapad et Overleaf au banc d’essai

Quand il faut rédiger à plusieurs, Google Docs reste le réflexe par défaut parce que tout le monde a déjà un compte. Pourtant, d’autres solutions font bien mieux le travail selon la situation :

Framapad : pour les documents classiques ou la prise de notes collective. Zéro compte requis : on crée un pad, on partage l’URL, et les potes peuvent taper direct dans le texte. C’est libre, sans friction et hébergé chez Framasoft en France.
Overleaf : indispensable pour les études d’ingé dès qu’il y a des maths ou de la physique. C’est un éditeur LaTeX en ligne collaboratif avec compilation et prévisualisation en direct. Plus besoin de se battre avec la syntaxe parfois lourde de LaTeX : on fait générer le code d’une formule par un LLM ou on utilise le mode d’édition visuel (WYSIWYG). Pour rendre un compte-rendu de TP nickel, ça change la vie.

Google Docs	Framapad	Overleaf

2. PowerPoint : des présentations sans surcharge

Faire des présentations claires est obligatoire dans presque tous les projets. Mais entre les usines à gaz propriétaires et les milliards d’options de mise en page qui font perdre du temps, PowerPoint et Google Slides ont tendance à m’agacer.

En solo : les slides intégrées dans Obsidian

J’avais testé des frameworks pour développeurs comme Slidev, mais c’était trop lourd pour un usage express. La vraie trouvaille, c’est le plugin natif Slides d’Obsidian.

Le principe est minimaliste : on sépare ses sections par trois tirets (---), et la note Markdown devient instantanément un diaporama projetable. Titres, listes, images, vidéos, iframes : tout s’affiche proprement. On n’a pas d’animations tape-à-l’œil, mais quand on connaît son sujet et que le message est clair, dérouler des slides épurées est mille fois plus percutant.

En multi : Gamma AI pour abattre la page blanche

Travailler un diaporama en groupe sans outil adapté vire souvent au cauchemar. Pour éviter ça, je passe par Gamma AI.

L’outil repose sur une syntaxe Markdown, ce qui permet de réutiliser directement mes notes. En fournissant simplement un plan bien structuré, Gamma génère une première trame complète en quelques secondes avec des thèmes soignés et des visuels intégrés. Bien sûr, il faut repasser derrière pour corriger et affiner, mais ça règle définitivement le syndrome de la page blanche tout en évitant les lourdeurs des suites classiques.

3. Excel : du Python en local, Grist en ligne

Le tableur traditionnel accumule les défauts : interfaces rigides, clics à répétition et formules illisibles dès qu’on dépasse trois conditions.

En solo : CSV brut et scripts Python

Pendant mes séances de TP, je ne supporte pas d’ouvrir Excel pour relever des mesures. Je note toutes mes données brutes dans un simple fichier texte, que je convertis rapidement en fichier CSV.

Ensuite, tout le traitement de données, les calculs et les courbes se font en Python avec des bibliothèques comme Pandas et Matplotlib. En tant que dev, coder un script pour manipuler un tableau est dix fois plus intuitif et reproductible que de chercher comment aligner des cellules. Si je rédige mon compte-rendu dans Overleaf, je demande directement à une IA de me convertir mes données en tableau LaTeX ou de sortir le script du graphique, et l’affaire est pliée. C’est une efficacité atomique.

CSV	Python	Pandas

En multi : la révélation Grist

Pour collaborer sur des tableaux sans subir Excel, la découverte de l’année s’appelle Grist (qui est d’ailleurs validé et utilisé par l’État français via la DINUM).

Grist fonctionne comme un hybride entre un tableur et une base de données relationnelle. Les colonnes sont rigoureusement typées (texte, date, image, devise), et surtout : les formules s’écrivent en Python.

On peut concevoir de vrais tableaux de bord partagés, et comme sur Framapad, les collaborateurs peuvent éditer sans créer de compte dès que le propriétaire du document partage le lien. Je m’en suis notamment servi pour gérer la comptabilité de mon association : si un membre oublie de téléverser un justificatif pour sa dépense, le solde global refuse de se calculer et bloque tout le monde. Pression sociale garantie, compta tenue au carré.

4. OneDrive : Syncthing pour ma toile, MEGA en dépannage

Synchroniser ses fichiers entre plusieurs appareils ne devrait pas obliger à confier l’ensemble de son disque dur aux serveurs d’un géant américain.

En solo : Syncthing en réseau décentralisé

Pour faire circuler mes notes et mes documents entre mon PC portable, ma tour et mon serveur personnel, j’utilise Syncthing.

L’outil fonctionne en pair-à-pair chiffré : pas besoin de cloud central, tes machines se découvrent et se synchronisent directement entre elles. Entre plusieurs ordinateurs, ça tourne du feu de dieu. L’interface graphique est austère, mais on s’en moque éperdument vu que le service tourne en tâche de fond et qu’on manipule ses fichiers dans son terminal ou son explorateur habituel.

Seul bémal honnête : l’application mobile sous Android reste parfois capricieuse lors des mises à jour, mais pour relier des machines physiques en direct, je n’ai rien trouvé de plus souverain.

En multi : MEGA pour les gros partages

Syncthing est parfait pour synchroniser ses propres machines, mais inadapté pour envoyer rapidement une archive de projet à un camarade.

Pour les partages ponctuels avec des personnes qui ne maîtrisent pas Git ou GitHub, j’utilise un compte MEGA ouvert au début de mes études. Le chiffrement de bout en bout côté client et l’espace de stockage gratuit évitent de se reposer sur Google Drive, même si je m’efforce de réserver son usage aux stricts dépannages.

5. Teams : place à la légèreté avec Jitsi

Teams ou Google Meet illustrent parfaitement l’obésiciel moderne : des gouffres en mémoire vive pour afficher un simple flux vidéo et échanger du texte.

En solo, le besoin n’existe évidemment pas.

En multi : Jitsi Meet

Quand il faut caler une visio rapide ou partager un écran pour déboguer un script en équipe, Jitsi Meet s’impose sans hésiter. Né à l’origine à l’université de Strasbourg, ce projet open source s’exécute directement dans le navigateur. Pas de client lourd à installer, pas de compte requis pour rejoindre l’appel : on définit le nom du salon, on transmet l’adresse aux participants, et la communication démarre instantanément. C’est fluide, sécurisé et respectueux de la vie privée.

Bilan

Adopter une stack bureautique local-first et libre ne relève pas du dogme absolu : c’est avant tout une question d’hygiène numérique et de bon sens technique. En s’appuyant sur des formats légers et universels comme le Markdown et le CSV, on s’assure de pouvoir relire ses notes dans vingt ans sans dépendre de l’abonnement d’une multinationale.

L’arrivée des outils d’IA permet désormais de combler les frictions sans abandonner cette souveraineté, que ce soit pour générer du code d’analyse ou poser une base de diaporama.

S’il vous semble manquer des alternatives intéressantes dans ce tableau ou si vous utilisez d’autres outils légers au quotidien, n’hésitez pas à me faire signe par mail ou sur les réseaux pour partager vos retours d’expérience !

From bouse to tank — le glow up du PC

Joseph Humbert — Wed, 30 Sep 2026 00:00:00 +0000

Le nouveau poste arrive un lundi de septembre. Un Asus, i5 7e génération, 16 Go de RAM, une Nvidia, un disque dur mécanique. Tu le sors du carton : Windows, WSL qui boucle au lancement. Tu ouvres un ticket Linux — réglé. Claude pose un bouton de panique quand WSL repart en vrille.

Le ricing commence. Debian allégée, Sway, Waybar, Catppuccin. Le repo BisonWallpaper porte déjà cette trajectoire : 29 avril, commit initial — un script de fond d’écran XFCE, un README, un art ASCII. 4 mai — greeter LightDM détecté, copie système, favicon. 11 mai — menus whiptail, thème Catppuccin néon sur fond nuit. D’un outil utilitaire à un design system.

Le PC suit. De la bouse Windows au tank Linux : froid, propre, fonctionnel. Les commits et le ricing racontent la même chose — on part petit, on itère, un jour ça tient. Le prix reste : couchers à 2 h, réveils lourds, dette de sommeil. Le glow up est terminé. Reste à dormir.

Du poids mort au majordome : installer Hermes Agent sur la Citadelle

Joseph Humbert — Sat, 12 Sep 2026 00:00:00 +0000

Suite de Le Réveil de la bête. Là-bas, je laissais un bloc mort dans mon compose.yml : un service Hermes que je n’arrivais même pas à démarrer, et une phrase que j’avais écrite un peu vite — « le poids mort d’Hermes ». Voici la suite, et elle ne se passe pas comme prévu.

21 h 38, « hello there »

Le 10 septembre au soir, j’écris deux mots à un truc qui n’existe pas encore vraiment : hello there. Pas de plan, pas de configuration, juste l’envie de voir ce que ça répond.

Deux jours plus tard, l’agent tourne sur la Citadelle, il répond sur Telegram, il a accès à mon serveur, à ma mémoire et à 62 compétences. La ligne morte du compose.yml, elle, n’existe plus : je l’ai retirée.

Pas de conteneur, installation directe

Mon réflexe, c’était le conteneur : un service de plus dans le compose, et on n’en parle plus. Sauf que le conteneur ne s’est jamais lancé.

Alors j’ai fait l’inverse : installation directe sur le système, à la racine. Et ça a fonctionné tout de suite. Avec un avantage que je n’avais pas anticipé et qui compte pour un agent : il a accès à tous les fichiers de la machine, sans volume à monter ni chemin à traduire. Un agent qui doit lire une configuration, un journal ou un projet n’a pas besoin d’un mur entre lui et le disque.

En prime, sur une tour qui fait déjà tourner un proxy, une base, un serveur de code et une synchro de notes, ça évite un conteneur de plus pour un programme qui parle à un modèle distant.

L’installation

L’installation, c’est vingt minutes et zéro surprise : l’installeur officiel monte tout, puis deux commandes pour choisir le modèle et vérifier l’état de la maison.

hermes setup     # assistant de configuration
hermes model     # choix du modèle et du fournisseur
hermes doctor    # état des lieux

Le modèle, c’est du deepseek-flash : rapide et bon marché, largement suffisant pour un agent qui passe sa journée à lire des fichiers et à taper des commandes. Le cadre est agnostique, je peux changer de fournisseur sans réinstaller.

Le premier mur arrive avec le gateway, la partie qui branche l’agent sur une messagerie. Je veux qu’il réponde sur Telegram, c’est là que je suis.

✗   Start failed — user systemd not reachable:
    loginctl enable-linger was denied: Failed to connect to system scope bus
    systemctl --user cannot reach the user D-Bus session in this shell.

Traduction : sur cette machine je travaille en SSH sur un compte sans session graphique ni bus utilisateur, donc systemctl --user ne peut rien piloter.

Deux erreurs, deux causes

Une fois ce point réglé, le gateway a redémarré en boucle : entre 19 h 46 et 20 h 00, quarante démarrages à vingt secondes d’intervalle.

Pour comprendre, je n’ai pas fait d’archéologie. J’ai collé les erreurs à mon agent, et je l’ai couplé avec une session d’un agent OpenCode en parallèle, sur le même problème. À deux, ils ont identifié deux causes bien distinctes :

Un token Telegram mort. Le token que j’avais collé était rejeté par le serveur, et le gateway sortait sur une erreur de configuration. C’était simplement le mauvais identifiant.
La connexion à l’API Telegram qui ne passait pas. Les journaux montrent huit tentatives de connexion, la découverte d’IP de repli par DNS-over-HTTPS, un chemin IPv4 forcé qui échoue, puis un échec complet du chemin principal : la machine n’arrivait pas à joindre les serveurs de Telegram.

Deux problèmes qui n’avaient rien à voir l’un avec l’autre, et qui se manifestaient de la même façon : un service qui tombe. C’est exactement le genre de diagnostic où je serais resté bloqué une soirée sur le mauvais problème.

Depuis, une seule instance, sous contrôle d’un superviseur, et il n’a plus bougé.

L’interface web en dix minutes

Il existe une interface web pour cet agent, maintenue à part du projet principal. Je l’ai trouvée sur GitHub, et je ne l’ai pas installée moi-même.

J’ai ouvert une conversation vide de tout contexte, je lui ai donné le lien du dépôt et j’ai dit : configure ça correctement sur mon installation. Dix minutes plus tard, c’était impeccable, en service, accessible depuis le navigateur.

C’est probablement le passage le plus déroutant de ces deux jours : un outil qui lit son propre dépôt et qui s’installe.

Une chose à ne pas faire pour autant : une interface d’administration qui donne accès à un agent ayant les droits de toucher au serveur ne se publie pas sur Internet sans authentification. Ça n’a rien à voir avec la confiance qu’on porte à l’outil.

Une recherche et une lecture auto-hébergées

Un agent sans accès au web est un agent bavard.

L’agent dispose de deux outils natifs pour ça : web_search pour chercher, web_extract pour lire une page. Je les ai branchés sur ma propre infrastructure, chacun sur son service.

Pour la recherche, un conteneur de plus dans le compose.yml : Degoog, un métamoteur auto-hébergé, exposé sur une API compatible SearXNG — le format que web_search parle nativement. Il arrive sans aucun moteur activé, et on installe ensuite ceux qu’on veut depuis son magasin d’extensions. Ma sélection :

Brave et Brave News
DuckDuckGo et DuckDuckGo News
Bing
Startpage
Wikipedia
Hacker News
Reddit

Pour la lecture, pas de conteneur du tout : un petit plugin que j’ai posé dans le dossier de plugins de l’agent, qui récupère la page avec httpx et la découpe en texte exploitable avec trafilatura, sans navigateur sans tête. web_extract pointe dessus.

Recherche et lecture tapent donc l’une sur mon métamoteur, l’autre sur ma brique locale, sans navigateur headless : aucune clé d’API, aucun tiers dans la boucle.

J’avais d’abord visé Firecrawl, la solution dont tout le monde parle, avec ses workers, son service Playwright et sa base. Abandonnée pour une raison bête : la pile demande plus de 4 Go de RAM, la machine en a 3,8. Et un plugin local suffit à lire un article ou une documentation. C’est le même raisonnement que dans La friction salutaire : la contrainte matérielle tranche les débats d’architecture mieux que n’importe quel comparatif.

La persona, en trois lignes

J’ai trouvé un fichier d’âme sur internet, je l’ai adapté au français et à ma façon de travailler, et j’ai bien aimé le style.

Je conseille à tout le monde de faire ça : ça donne beaucoup plus de personnalité aux discussions. Une persona change la donne : l’agent tient une position, il te reprend quand tu t’apprêtes à faire une bêtise, il anticipe l’étape d’après au lieu d’attendre l’instruction.

La sauvegarde, et le seul vrai garde-fou

Chaque nuit, la configuration part vers un dépôt privé — sans les secrets, exclus par principe. Et avant chaque envoi, un script relit tout et refuse le push s’il trouve une clé ou un mot de passe. Un garde-fou qui bloque au lieu d’avertir.

Pour le reste, la règle est simple : ce qui se défait reste libre, ce qui ne se défait pas demande l’autorisation. Un fichier, un commit local, un conteneur qu’on recrée — vas-y. Un envoi vers l’extérieur, une suppression, une publication — tu demandes d’abord.

Bilan

Ce qui tourne aujourd’hui : installation directe sur le système, gateway Telegram stable, interface web en service, métamoteur auto-hébergé avec neuf moteurs, 62 compétences, une persona, des sauvegardes nocturnes. Ce qui reste : quatre avertissements au dernier état des lieux, rien de bloquant, hermes doctor ne ment pas.

Deux choses que je retiens. La première, c’est que ce système est plus modeste que celui que je faisais tourner sur mon laptop — et qu’il a un avantage qui écrase le reste : il vit sur le serveur, dans une machine isolée de ma machine de travail. Il tourne quand mon laptop est fermé, et si je casse quelque chose en bricolant, ça ne touche pas mon outil de production.

La seconde, c’est que je n’ai pas installé ce logiciel tout seul. J’ai passé deux jours à coller des erreurs dans une conversation, et la plupart du temps, ça a suffi. Sans fournisseur branché, un agent reste un binaire muet. Une fois le modèle en place, il devient le meilleur assistant d’installation de lui-même. Il reste une part de maîtrise en moins : je ne saurais pas réinstaller tout ça de mémoire.

Quant à la conclusion de mon article précédent — « le prochain chantier, c’est cet agent IA qui remplacera le poids mort d’Hermes » — elle a mal vieilli. Le fameux poids mort venait de ma façon de l’installer, rien d’autre.

La friction salutaire : pourquoi j'ai désarmé mon numérique

Joseph Humbert — Thu, 10 Sep 2026 00:00:00 +0000

En traînant sur des blogs un peu obscurs du web indépendant, je suis tombé sur des mecs comme SebSauvage ou Ploum (le type derrière Offpunk). Au début je regardais ça de loin, et puis en fait ça m’a mis une vraie claque. En gros, ils posent un truc tout bête : et si, pour sauver notre cerveau, il fallait juste réapprendre à utiliser un web moche, textuel et hors-ligne ?

C’est exactement l’esprit de la slow tech : une approche de l’informatique qui refuse la course aveugle à la nouveauté, combat l’obésiciel et privilégie des outils sobres, réparables et pensés pour durer. L’idée n’est pas de rejeter la technologie, mais de ralentir délibérément le rythme pour choisir des systèmes qui nous servent au lieu de nous asservir.

En lisant ça, je me suis pas mal reconnu. En tant qu’étudiant en école d’ingé, j’avais ce dégoût qui montait en sourdine depuis des mois. On passe nos journées sur des interfaces boursouflées, blindées d’animations inutiles, qui cherchent juste à capter notre temps de cerveau au lieu d’obéir à ce qu’on leur demande. Bref, j’ai voulu tenter l’inverse complet : rajouter de la friction volontaire, arrêter de subir et reprendre le contrôle de mes machines.

1. Le RER en noir et blanc et la liseuse de survie

Le point de départ, c’est mes trajets de RER. J’ai facilement 1 h 30 de transport par jour. Sur le papier, c’est le moment rêvé pour relire des cours, taffer un projet ou lire de la doc. Dans les faits ? Une catastrophe. Je sortais mon tel pour ouvrir un PDF, je voyais une notif rouge pétante, une couleur flashy, et dix secondes après j’étais bêtement en train de scroller sur un fil d’actualité. Zéro concentration.

Du coup, j’ai testé deux trucs un peu radicaux :

Le mode noir et blanc h24 sur le smartphone : Franchement, au début c’est super bizarre. Mais ça change tout. Dès que tu vires la couleur, l’écran perd direct 90 % de son pouvoir hypnotique. Les vignettes YouTube deviennent ternes, Insta n’a plus aucun intérêt, et le tel redevient juste un outil chiant. Un bloc de verre utilitaire.
Prendre une vieille liseuse e-ink pour bosser : Pour lire des cours un peu denses ou des articles de fond, c’est le jour et la nuit. Pas d’écran qui t’arrache les yeux, et surtout : l’écran met une demi-seconde à rafraîchir. Rien que ça, ça coupe court à tout réflexe de zapping compulsif.

Ralentir le truc, c’est la slow tech appliquée à l’attention : ça crée un vide d’air incroyable. Dans le train, mon esprit arrête d’être bombardé de stimuli. Ça dépend des jours évidemment, mais souvent ça me laisse enfin le temps de réfléchir à un problème d’algo ou juste de digérer un cours sans être interrompu toutes les deux minutes.

2. Le vieux Mac de 2015 qui revit sous Linux

Cette envie de virer le superflu, je me la suis prise en pleine face sur mon ordi portable. En arrivant en cursus info, on réalise vite à quel point les OS grand public nous prennent pour des gosses.

J’avais un MacBook de 2015 qui tournait encore super bien matériellement. Le problème, c’est qu’Apple a décidé que non. J’ai voulu installer une stack mobile récente (Flutter, le SDK Android, etc.), et là, mur complet : OS plus supporté, Xcode qui refuse de s’installer parce qu’il manque un patch mineur, et des heures à bidouiller des scripts douteux pour essayer de contourner un verrouillage 100 % commercial. La machine était encore largement dans les temps niveau perfs : la marque, elle, voulait simplement que j’en rachète une neuve.

J’ai fini par péter un plomb : j’ai rasé le disque et collé une distrib Linux légère. En deux heures, tout tournait nickel. Pas d’artifice, pas de compte iCloud requis, ça compile, point. Alors oui, ça demande de mettre les mains dans le cambouis (et parfois de passer une soirée sur un driver Wi-Fi récalcitrant, je ne vais pas mentir), mais au moins la machine fait ce que je lui demande. En tant que futur dev, je pense que c’est indispensable de comprendre ce qui tourne sous le capot plutôt que d’accepter une mise au rebut artificielle.

3. Faire tourner des petits LLM en local : l’école de la contrainte

Le dernier délire en date, c’est l’IA. En ce moment, tout le monde jette ses lignes de code et ses données perso sur les serveurs de gros modèles cloud sans même y réfléchir deux secondes.

Moi, j’ai voulu faire tourner des petits modèles en local sur ma bécane. Évidemment, ça ne rivalise pas avec les clusters gigantesques des GAFAM, mais l’expérience m’a appris trois trucs majeurs :

La vie privée, la vraie : Zéro clé d’API, pas de boîte californienne qui aspire mes prompts pour réentraîner ses trucs. Tout tourne dans ma RAM, hors-ligne.
La fierté de bidouiller : Réussir à faire tourner un modèle quantifié proprement, régler les bons paramètres et le requêter via un petit script maison, c’est quand même dix fois plus gratifiant que de simplement coller un prompt sur une interface web toute faite.
Comprendre le coût des choses : Quand tu vois ta RAM saturer et tes ventilos hurler parce que ton prompt fait 500 tokens de trop, tu captes direct le coût physique de l’informatique. La contrainte matérielle force à être sobre : on apprend à poser de bonnes questions et à réfléchir avant d’appuyer sur Entrée.

En gros…

Mon idée, c’est pas du tout de vivre en ermite dans les bois ou de jouer au hacker du dimanche pour faire genre. C’est juste d’arrêter d’être un pur consommateur passif, exactement comme l’expliquent des mecs comme Ploum.

Le noir et blanc sauve mon attention, Linux sauve mon matos de la poubelle, et bidouiller du self-hosting me fait enfin piger concrètement le réseau et les ressources.

Ça demande un peu de temps, parfois ça plante et ça énerve, mais honnêtement, cette friction-là vaut largement le coup. C’est juste le prix à payer pour avoir un numérique sobre qui ne nous bouffe pas la tête.

Le Réveil de la bête

Joseph Humbert — Tue, 08 Sep 2026 00:00:00 +0000

Suite de mon Sauvetage express : dual boot Windows 10 / Debian 13 sur un OptiPlex 390 — après l’abandon du Mac et du Latitude noyé et le montage de la tour OptiPlex, je remets sur pied le serveur pour la rentrée.

Un été sans serveur

Mon serveur a passé l’été éteint — pas de course aux notes et aux infos, et une certaine sérénité qui accompagne l’interruption volontaire d’un service qu’on n’administre plus.

La rentrée venue, la question classique : est-ce que ça va repartir ? L’OS a vieilli sur place, les images Docker sont plus datées, les configs ont bougé pendant mes vacances (bon, j’avais « un peu » touché à mon syncthing et mes notes obsidian entre deux baignades).

J’appuie sur le bouton, je remonte et me connecte en SSH, et je lance la commande dont je ne me lasse pas :

cd /root/infra && docker compose up -d

Et là, la surprise : tout est remonté nickel. Presque aucune galère. Caddy qui reprend le proxy, Glances qui se remet à parler CPU, SilverBullet qui retrouve mes notes, PocketBase qui rapplique impeccable. Voilà une vertu du tout-Docker-Compose qu’on ne vante pas assez : tout le système tient dans un fichier.

La Citadelle de Seigneur Bison (Oui le nom de mon serveur est pompeux et alors ? :-))

Rien que pour le plaisir des yeux, voilà la stack qui tourne dans le boîtier :

Service	Rôle
Caddy	Reverse proxy (réseau hôte, socket Tailscale)
Dashboard (nginx)	Portail d’accueil — le tableau de bord de la Citadelle
SilverBullet	Prise de notes & savoir
code-server	VS Code dans le navigateur, pour bricoler l’infra
PocketBase	Base de données & admin
Wetty	Terminal SSH via le navigateur
Glances	Monitoring CPU/RAM en temps réel
Syncthing	Synchro de mes notes Obsidian
rclone	Sauvegardes chiffrées vers MEGA + git push sur GitHub

Et c’est dans la période qui a suivi le réveil que j’en ai profité pour développer la configuration : affinage des healthchecks, volumes mieux découpés, sauvegarde nocturne automatisée. L’art de profiter d’un redémarrage pour faire le ménage au lieu de le repousser.

La vraie galère : Syncthing après la mise à jour de l’appli mobile

Le hic, il est venu de là où on ne l’attend pas : une mise à jour de l’application mobile Syncthing. Du jour au lendemain, la synchronisation de mes notes Obsidian a décidé de ne plus avancer. Verdict : tout était à reparamétrer. J’ai dû repasser derrière sur trois fronts :

Le téléphone (Android) : l’appli mise à jour a imposé une remise à zéro de la config — ré-ajout de l’appareil, re-scan des dossiers ;
Ma nouvelle machine sous Windows : la tour OptiPlex aménagée dans mon précédent article, nouveau venu dans le foyer, a dû être déclarée comme appareil de confiance et rattachée au même dossier ;
Le serveur : au passage, j’ai fait le grand ménage dans les appareils — suppression des morts (l’ancien Mac 2015, le Latitude noyé) et ajout des nouveaux (le PC, le téléphone).

Moralité d’une reconfig dans les trois sens : Syncthing, c’est un réseau de confiance. Chaque appareil a un device ID, chaque pair doit être accepté des deux côtés, chaque dossier re-partagé. Quand une appli mobile force un reset, c’est toute la chaîne qu’il faut reconstruire. Bénéfice pas négligeable : j’en ai profité pour harmoniser les noms d’appareils et virer les reliques du passé.

La quête de l’agent IA léger

Pendant que la Citadelle redevenait propre, un manque s’est fait sentir : un agent IA pour administrer le serveur. J’utilise en effet OpenCode mais Glances me dit qu’il est trop lourd… J’avais tenté d’intégrer Hermes (nousresearch/hermes-agent) au compose, bloc prévu pour piloter l’infra en passant par un chat. Sauf que… je n’arrive même pas à tirer l’image. Bloc mort dans le compose, de la configuration qui ne sert à rien et qui coûte cher en « pourquoi ça marche pas » chaque fois qu’on relit le fichier.

Autant dire que je suis en recherche d’un agent IA très léger pour manager ce serveur : quelque chose qui parle Docker et systemd, qui s’exécute localement sans dévorer la RAM d’une petite tour et qui se branche proprement sur un workflow « observe → plan → exécute ».

Si tu as des pistes d’agents légers réellement utilisables pour l’administration serveur — laisse ta suggestion par mail ou sur LinkedIn, je testerai les meilleures propositions.

Bilan

Ressusciter un serveur après un été d’inactivité, c’est finalement du presque-rien quand tout est Dockerisé : une commande, un café, et la Citadelle est debout. La vraie charge, elle vient des chaînes qui relient les machines entre elles — et Syncthing me l’a rappelé en me forçant à re-coudre toute la toile pour cause de mise à jour mobile.

Windows n’est plus qu’un coin à jeux, les notes revivent, et le prochain chantier, c’est cet agent IA qui remplacera le poids mort d’Hermes. À suivre…

Sauvetage express : dual boot Windows 10 / Debian 13 sur un OptiPlex 390

Joseph Humbert — Sun, 06 Sep 2026 00:00:00 +0000

La semaine où tout a cramé

Tout commence par une cascade de morts informatiques. Mon MacBook de 2015 — ma machine de tous les jours, celle dont la batterie tenait mieux que toutes les autres — rend l’âme après dix ans de bons et loyaux services. Dans la foulée, mon Latitude 3790 2-en-1 prend la flotte : connecteur cramé, écran mort, irréparable. Je me retrouve sans aucun ordinateur quelques jours avant la reprise des cours.

Le lundi de la débrouille

Sans machine, le lundi se transforme en purgatoire. J’essaie de bosser depuis mon téléphone et du papier-crayon. Verdict en fin de journée : invivable.

L’écran du téléphone est trop petit pour afficher un sujet de maths et sa correction côte à côte ;
Mes fiches sont dans Obsidian, version mobile : pour consulter une fiche puis revenir au sujet, je dois changer d’application en permanence — et ce va-et-vient infini est le meilleur piège à concentration qu’on puisse imaginer. Plus d’une fois, un « vite fait, je vérifie une formule » s’est terminé dans les méandres de YouTube, vingt minutes plus tard.

Bilan de la journée : presque rien. Il me faut un vrai PC, et vite.

Le mardi de la chance

Mardi soir, je file en catastrophe chez des potes qui tiennent un petit stock de machines d’occasion. Ils me ressortent un vieux Dell OptiPlex 390 — une tour discrète, pas une bête de course, avec un HDD vieillissant sous Windows 10 sans licence. Elle démarre : c’est parti pour le plan B.

Le plan : deux disques, deux mondes

J’ai besoin de deux choses apparemment contradictoires :

garder Windows 10 pour mes jeux ;
Debian pour travailler — c’est sous Linux que je travaille et que je développe depuis plusieurs mois, et je ne compte pas revenir en arrière.

Solution : installer un second disque dur dans la tour, installer Debian dessus, et laisser GRUB jouer l’arbitre entre les deux systèmes.

J’ouvre le boîtier, je plaque un disque de 240 Go sur un port SATA libre (petit détail au passage : n’oublie pas le câble d’alimentation — un disque qui n’est pas alimenté, c’est un disque qui n’existe pas), je referme, j’insère la clé Debian.

Installation anodine : partitionnement ciblé sur le nouveau disque, GRUB installé par l’installateur, redémarrage. Et là…

La galère GRUB, ou l’art de tirer trois fois

Deuxième tentative : je relance l’installateur, je m’assure que tout part sur le bon disque, je redémarre… Windows encore. Troisième essai, même résultat. Trois installations de Debian derrière moi, et toujours pas l’ombre d’un menu GRUB. C’est là que ça gratte.

Le coupable, en réalité : la priorité de démarrage du BIOS.

GRUB avait bien été installé… mais pas sur le disque que la carte mère regardait en premier. Quand le BIOS cherche un système à démarrer, il consulte sa liste de périphériques bootables dans l’ordre : si Debian (et son GRUB) est sur le deuxième disque et que Windows reste en tête de liste, aucun menu ne s’affiche jamais. Windows démarre, comme si Debian n’existait pas.

La morale est simple et brutale : réfléchis à la priorité de démarrage de tes disques avant d’installer quoi que ce soit. Sur un OptiPlex 390, on éduque la bête dans le BIOS (F2 au boot), section Boot Sequence : place le disque Debian en première position. De mon côté, une fois le bon disque en tête, tout est rentré dans l’ordre : menu GRUB, Windows en choix n°1, Debian en n°2, GRUB_TIMEOUT=5 pour respirer.

Personnalisation : un environnement au look Sweet

Debian tourne. Il reste à faire en sorte que ce soit le mien. Je pars sur KDE Plasma, avec un thème précis en tête : sombre, bleuté, polaire — le Sweet-Ambar-Blue, décliné jusqu’à l’écran de connexion :

Look & Feel Sweet-Ambar-Blue pour Plasma, et même thème pour SDDM, l’écran de connexion — la cohérence visuelle paie ;
Icônes : candy-icons, colorées sans être criardes ;
Curseurs : ArcStarry (Sweet en backup) ;
Konsole : profil « SweetAmbar », la vraie signature — fond translucide à 50 % avec flou, schéma sombre (fond 24,27,40, texte blanc pur) ;
GTK : Breeze en mode sombre, pour que les applis non-KDE ne jurent pas avec le reste ;
Wallpaper : un cyber-bison qui pose l’ambiance.

# Profil Konsole « SweetAmbar »
[Background]
Color=24,27,40

[Foreground]
Color=255,255,255

[General]
Description=Sweet Ambar Blue
Opacity=0.5

Le terminal est la vitrine du setup : demi-transparence, un brin de flou, fastfetch qui annonce la couleur à l’ouverture, et quelques amusements qu’on a tous (cmatrix, lolcat, cowsay).

La tournée des outils

Parce qu’un bel OS sans bons outils, c’est une façade. J’ai ramené mon quotidien d’étudiant-développeur dessus :

Obsidian — le vault de notes autour duquel tourne toute ma vie de travail ;
LocalSend pour envoyer des fichiers entre machines sans câble ni compte ;
Firefox ESR en brouette de base ;
zola, le générateur de site statique derrière ce blog ;
arrosé de flatpak pour tout ce qu’apt ne fournit pas.

Bilan

En l’espace d’une soirée de panique aboutissant à la récupération d’une machine et d’une semaine de bricolage, l’OptiPlex 390 est passé de « vieille tour sous Windows pirate » à machine de dev principale. Les leçons, en vrac :

La priorité de démarrage du BIOS, c’est la moitié de la bataille du dual boot sur disques séparés ;
Un setup Linux cohérent (thème + SDDM + Konsole + GTK) se monte vite, mais chaque détail compte ;
Parfois, la créativité technique naît de l’urgence du quotidien : il a fallu perdre un lundi à galérer sur un téléphone pour mériter mardi ce vieux boîtier de récupération.

Windows est toujours là, cantonné aux jeux. Tout le reste a migré.

Lancer son blog avec Zola

Joseph Humbert — Fri, 21 Aug 2026 00:00:00 +0000

Introduction à Zola

Zola est un générateur de sites statiques écrit en Rust, conçu pour être rapide, simple et fiable. Créé par Vincent Prouillet, il se distingue par une architecture épurée et une philosophie minimaliste : pas de dépendance lourde, un binaire unique et un rendu prévisible.

Contrairement à d’autres générateurs qui regroupent de nombreuses fonctionnalités dans le noyau principal, Zola adopte une approche stricte. Le binaire est petit, la compilation est ultra-rapide et le rendu est reproductible. Pour un blog personnel ou un site documentaire, c’est souvent le choix idéal — et pour quelqu’un comme moi qui aime comprendre de bout en bout ce qu’il déploie, c’est exactement ce que je cherchais.

Pourquoi Zola plutôt qu’un autre outil ?

J’ai testé plusieurs alternatives ces dernières années. Jekyll (Ruby), Hugo (Go), ou les générateurs basés sur Node. Tous fonctionnent très bien, mais Zola coche des cases qui comptent pour moi :

Aucune dépendance d’exécution : pas de runtime à installer sur la machine de build, un simple binaire suffit
Vitesse de génération : quelques millisecondes même pour un site fourni, ce qui se remarque en local comme en CI
Sobriété : le minimalisme du rendu pousse à écrire de l’HTML propre et léger, cohérent avec ma manière de concevoir des solutions légères
Facilité d’intégration : un site statique se déploie n’importe où, y compris sur un Raspberry Pi de mon homelab

Ce blog tourne pour l’instant sur Vercel, en déploiement continu depuis son dépôt Git, mais c’est tout l’intérêt d’un site statique : il se pose n’importe où, y compris sur le Raspberry Pi de mon homelab — et c’est cette voie-là que je documente ici.

Installation

L’installation de Zola est remarquablement simple. Plusieurs méthodes sont disponibles selon votre système d’exploitation.

Via les binaires précompilés

Téléchargez la dernière version stable depuis la page GitHub des releases. Pour Linux, il suffit de décompresser l’archive et d’ajouter le binaire à votre PATH :

tar -xzf zola-v0.23.5-x86_64-unknown-linux-gnu.tar.gz
export PATH="$HOME/.local/bin:$PATH"

Sous Linux, Zola ne nécessite ni Node.js ni environnement lourd : c’est l’un de ses grands atouts pour qui veut du tooling simple.

Via les gestionnaires de paquets

Sur macOS, vous pouvez utiliser Homebrew :

brew install zola

Sur Debian ou Ubuntu, Zola n’est pas dans les dépôts officiels : passez par le binaire des releases GitHub, par Snap (snap install --edge zola), par Flatpak (flatpak install flathub org.getzola.zola) ou par l’archive APT tierce pkg.haus. Sur Windows, Winget, Scoop et Chocolatey proposent également Zola.

Vérification de l’installation

Une fois l’installation terminée, vérifiez que tout fonctionne correctement :

zola --version

La commande doit retourner la version installée. Si vous voyez un numéro de version comme 0.23.5, c’est que tout est en ordre et vous pouvez passer à l’étape suivante.

Initialiser un nouveau site

La commande zola init crée la structure de base d’un nouveau site. Elle vous demande la base URL du site, puis génère les dossiers et fichiers nécessaires :

zola init mon-blog

Après cette commande, vous trouverez dans le dossier mon-blog les éléments suivants :

config.toml : le fichier de configuration principal
content/ : le dossier contenant les pages et articles
templates/ : les fichiers de templates HTML
static/ : les ressources statiques (images, CSS, JavaScript)
sass/ : les feuilles de style SCSS

Le fichier de configuration est le cœur du site. C’est là que vous définissez le titre, la base URL, les taxonomies et toutes les options de génération. Notez que les versions récentes de Zola le nomment zola.toml, avec config.toml accepté en rétrocompatibilité.

Comprendre la structure de configuration

Le fichier de configuration utilise le format TOML, un format lisible et concis que je retrouve d’ailleurs quotidiennement dans mes pipelines CI et mes fichiers Docker. Voici les éléments principaux :

base_url = "https://mon-blog.example.com"
title = "Mon Blog"
author = "Joseph Humbert"
generate_feeds = true
feed_filenames = ["rss.xml"]

taxonomies = [
  { name = "tags", paginate_by = 10 },
  { name = "categories", paginate_by = 10 },
]

[markdown.highlighting]
light_theme = "github-light"
dark_theme = "synthwave-84"

La section taxonomies permet de définir les classifications de vos articles. Attention à la syntaxe des versions récentes : il s’agit d’un tableau de tables, et non plus d’une carte clé/valeur. Tags et catégories sont les plus courants, mais vous pouvez en ajouter d’autres selon vos besoins.

Rédiger et publier du contenu

Zola organise le contenu en sections. Chaque section est un dossier dans content/ avec un fichier _index.md qui définit les métadonnées de la section. Les articles sont des fichiers Markdown avec un en-tête TOML délimité par +++.

Voici un exemple de structure pour un blog :

content/
  _index.md
  blog/
    _index.md
    article-1.md
    article-2.md
  a-propos.md

Pour créer un article, il suffit d’ajouter un fichier .md dans le dossier blog/ avec le front matter approprié. Un détail qui m’a fait trébucher au départ : les taxonomies d’une page se déclarent dans un sous-bloc [taxonomies] du front matter, et non comme de simples clés à plat. Une fois ceci compris, Zola gère automatiquement le tri par date, la pagination et la génération des flux RSS.

Développement local et build

Zola propose deux commandes principales pour le développement :

zola serve

Cette commande lance un serveur de développement local avec rechargement automatique. Vous pouvez prévisualiser le site en temps réel, modifier vos articles et voir les changements immédiatement. Le serveur écoute par défaut sur le port 1111.

Pour générer la version finale du site, prête pour la mise en production :

zola build

La commande crée un dossier public/ contenant tous les fichiers HTML, CSS et JS optimisés. Ce dossier est ce que vous déployez sur votre serveur d’hébergement. La compilation est extrêmement rapide, souvent en moins d’une seconde pour un blog de taille moyenne.

Déploiement et maintenance

Une fois le site généré, plusieurs options de déploiement s’offrent à vous :

Netlify : déploiement automatique via Git, très populaire pour les sites statiques
GitHub Pages : hébergement gratuit avec intégration GitHub Actions
VPS ou serveur personnel : transfert via rsync, ou déploiement automatisé via un pipeline de CI que je configure en général avec Docker ou des tâches cron

Pour ma part, c’est cette dernière option que j’affectionne : elle s’inscrit naturellement dans ma démarche d’automatisation et de self-hosting. Un simple rsync ou un job de CI suffit à publier la dernière version du site.

Pour la maintenance, Zola impose très peu de contraintes. Les mises à jour sont rares et généralement rétrocompatibles. Il est recommandé de surveiller les notes de version pour connaître les changements éventuels.

Conclusion

Lancer un blog avec Zola est une expérience agréable et efficace. L’installation est rapide, la configuration est claire et la rédaction se fait naturellement en Markdown. Pour développeurs techniques cherchant un outil fiable et performant, Zola représente un excellent choix. Cet article est d’ailleurs lui-même publié avec la version 0.23.5 de Zola, et vous êtes en train de lire le résultat direct du pipeline que je viens de décrire.

N’hésitez pas à explorer la documentation officielle pour approfondir les fonctionnalités avancées, et à me suivre sur GitHub où les projets évoqués dans ce blog sont régulièrement mis à jour.

Bienvenue sur mon nouveau blog technique

Joseph Humbert — Tue, 10 Mar 2026 00:00:00 +0000

Pourquoi ce blog ?

Après de longues hésitations, j’ai décidé de lancer ce blog. L’idée germe dans mon esprit depuis plusieurs années, mais entre les études à Polytech Paris-Saclay, ma recherche d’alternance et une vingtaine de projets personnels, je n’avais jamais trouvé le bon moment. Aujourd’hui, avec les outils modernes de génération de sites statiques, la barre à franchir est plus basse que jamais. Plus aucune excuse, donc.

Ce blog a pour vocation de documenter mon parcours technique, de partager des tutoriels et de réfléchir à des questions plus larges sur le développement logiciel : l’architecture, l’autonomie, l’outillage. J’espère que les articles que tu liras ici te seront utiles, que tu sois développeur chevronné ou simple curieux.

Le choix de Zola

J’ai longtemps hésité entre plusieurs générateurs de sites statiques : Jekyll, Hugo, Pelican… autant d’options intéressantes, chacune avec ses avantages et ses inconvénients. Entre un besoin de vitesse et la volonté de garder un contrôle total sur mon code, j’ai finalement opté pour Zola, écrit en Rust.

Voici les raisons principales de ce choix :

Rapidité : Zola est écrit en Rust et la génération du site prend quelques millisecondes
Simplicité : la configuration est claire, le templating est intuitif
Documentation : la doc officielle est complète et bien structurée
Communauté : malgré une base d’utilisateurs plus modeste que Hugo, la communauté est active et bienveillante
Templates : le système de templates est familier et puissant

En bonus, Zola gère nativement les flux RSS, les taxonomies et la pagination, ce qui correspond exactement à mes besoins.

Un premier aperçu du code

Pour te donner un aperçu de ce à quoi ressemble un article Zola, voici un petit extrait de configuration en TOML :

base_url = "https://blog.example.com"
title = "Mon Blog"
author = "Joseph Humbert"

[taxonomies]
tags = ["zola"]

[extra]
github = "https://github.com/Tahlasandale"
portfolio = "https://portfoliojosephhumbert.vercel.app"

Ce format est lisible, concis et ne nécessite aucune connaissance approfondie pour être compris. À côté du TOML que je manipule déjà au quotidien avec les CI, les pipelines et les outils comme Docker, c’est un langage que j’apprécie directement.

Ce que tu trouveras ici

Les articles de ce blog seront principalement répartis en quatre grandes thématiques :

1. Dev en autonomie

Je développe seul depuis longtemps : 24 dépôts publics sur GitHub, de Flutter à Go en passant par TypeScript. Je partagerai ici des retours d’expérience sur la livraison de projets de A à Z, les pièges à éviter et les méthodes qui fonctionnent.

2. Self-hosting et DIY

Un Raspberry Pi, Docker, du Linux maison : mon homelab est un terrain de jeu pédagogique. J’y déploie des services, j’y expérimente et je documente mes erreurs pour que tu puisses reproduire et aller plus loin.

3. IA appliquée

Bots Telegram, transcription Whisper, agents Hermes et OpenCode, APIs Gemini et Mistral : j’aime brancher les LLM sur des usages concrets plutôt que de les regarder en démonstration. Ces sujets seront régulièrement abordés.

4. Vie d’alternant

Je suis actuellement en alternance de trois ans chez un éditeur de logiciel pour un produit de gestion d’école, sur une stack PHP/Symfony, React, PostgreSQL, Docker, Kubernetes et Azure. Entre les rythmes entreprise/école et le passage d’étudiant à ingénieur, il y a beaucoup à raconter et à apprendre ensemble.

La stack technique

Pour les curieux, voici un résumé de la stack technique utilisée pour ce blog :

Générateur : Zola 0.23.5
Langage : Rust (pour Zola), HTML/CSS côté front
Hébergement : Vercel, en déploiement continu depuis le dépôt Git — un site statique se poserait tout aussi bien sur mon homelab
Feed : flux RSS disponible dans /rss.xml

La configuration du site est relativement simple. Le fichier config.toml définit la structure globale, les taxonomies (tags et catégories) et les options de génération. Les templates sont stockés dans le dossier templates/ et les feuilles de style dans static/css/.

Je réfléchis également à ajouter un système de commentaires ouvert, peut-être via un service externe comme Giscus. Ce n’est pas encore décidé, mais c’est une piste que j’explore.

Pour conclure

Ce premier article a surtout vocation à poser les bases. Il est court, volontairement simple, et sert surtout d’introduction à ce qui sera développé dans les prochains billets. Je ne cherchais pas ici à impressionner, mais simplement à dire bonjour et à te donner envie de revenir.

Si tu as des suggestions d’articles, des remarques sur le site ou simplement envie d’échanger, tu me trouveras sur GitHub ou mon portfolio. Les retours des lecteurs sont toujours précieux et m’aident à améliorer la qualité du contenu.

Merci de ta visite et à bientôt pour de nouveaux articles.