Olivier DOSSMANN

Découverte d'ArchLinux, 20 ans déjà !

Thu, 08 Oct 2026 18:05:11 +0200

Introduction

Au 10 octobre 2026, cela fera 20 ans que j’ai installé ArchLinux pour la première fois. Que de souvenirs et que d’aventures sur cette distribution qui a signé une forme de stabilité dans mon écosystème : je n’ai jamais été aussi bien que sous ArchLinux. Et pourtant j’ai testé des distributions ! Je vous invite d’ailleurs à consulter la Liste des distributions que j’ai testées sur mon Recueil d’astuces.

Nous parlerons rapidement de la manière dont j’ai découvert cette distribution après quoi j’aimerais vous partager quelques astuces et outils du moment autour de cette distribution.

Photo trouvée sur le profil Flickr de Mohd Sohail sous Licence CC BY-SA 2.0.

Comment j’ai découvert ArchLinux

Tout commence en avril 2005, dans le magazine « Linux+DVD magazine » qui parle d’une distribution assez récente nommée Arch Linux 0.7. D’ailleurs pour la petite histoire, j’ai été correcteur, puis rédacteur dans ce magazine. À l’époque je trouvais que la qualité du français n’était pas au rendez-vous. J’ai découvert qu’à la base l’équipe du magazine était polonaise et qu’une traduction était faite pour chaque article. Au départ les articles étaient seulement traduits. Puis quelques correcteurs français sont apparus. Et finalement ce sont carrément les correcteurs français qui sont devenus rédacteurs !

À l’époque je n’avais pas le niveau pour installer cette distribution : j’avais encore quelques difficultés avec la ligne de commande - même si j’en faisais pas mal depuis le début des années 2000. Ce n’est qu’en 2006, après avoir essayé Knoppix, Debian, Mandrake, Damn Small Linux, Suse Linux, Mandriva, Ubuntu, UbuntUSB, […] et surtout Gentoo et Slackware que j’ai voulu quelque chose de différent :

un GNU/Linux moins lourd qu’Ubuntu Linux et Mandrake/Mandriva Linux,
avec des paquets récents (contrairement à Debian à l’époque où le pinning était monnaie courante),
une distribution à construire aux petits oignons, tout comme Gentoo et Slackware,
mais qui ne demande pas autant de temps d’attente due à la compilation de nos programmes comme le demandent Gentoo et Slackware.

Après avoir passé des jours sur Gentoo à compiler plusieurs fois le noyau et attendre des nuits entières que LibreOffice (OpenOffice à l’époque) soit compilé - sans erreur - je crois qu’un passage sur ArchLinux paraît comme une promenade de santé 🤣.

J’ai donc installé ArchLinux le 10 octobre 2006 comme vous pouvez le voir sur l’article « Kiss, le bisou Linux ? ».

Au début je trouvais que c’était assez fragile cette distribution. Avec le recul je me dis que j’étais plutôt aventureux et cassait moi-même la distribution. D’ailleurs le gestionnaire de paquet de cette distribution s’appelle pacman et nous allons voir qu’il a bien évolué au fil du temps.

Quelques mots sur le gestionnaire de paquet nommé Pacman

pacman est donc le gestionnaire de paquet officiel d’ArchLinux. Il s’utilise avec la commande du même nom.

Quelques éléments majeurs de l’évolution de ce gestionnaire :

2002 marque l’arrivée du gestionnaire de paquet, écrit par Judd Vinet, créateur d’ArchLinux,
puis pacman inclut une base de données pour suivre l’évolution des paquets au cours de la vie de la distribution installée,
une bibliothèque (lib) arrive pour séparer les traitements communs du gestionnaire de paquets et le front-end habituel : libalpm est née. Cela permet à d’autres front-end de voir le jour pour le dépôt AUR (ArchLinux User Repository, un dépôt communautaire pour les paquets non supportés officiellement par la distribution),
au départ les paquets étaient compressés en .pkg.tar.gz, puis ils sont passés au format .pkg.tar.xz qui favorisait une compression forte (réduisant la taille des paquets, favorisant au passage un téléchargement plus rapide) et une décompression rapide chez l’utilisateur,
puis la signature des paquets est devenue obligatoire,
puis un nouveau format de compression apparaît pour avoir une décompression encore plus rapide que le format XZ : .pkg.tar.zst,
avec la version 6.0 de pacman arrive les téléchargements en parallèle, ce qui fait un bien fou ! Il suffit pour cela d’utiliser ParallelDownloads dans le fichier pacman.conf et de donner un nombre de téléchargements à faire en simultané,
et finalement une nouvelle façon d’installer les paquets avec un utilisateur aux permissions limitées apparaît ; avec l’usage d’une sandbox.

Que d’évolutions au fil du temps !

D’ailleurs pacman possède un easter egg connu nommé ILoveCandy. Pour l’activer il suffit d’ajouter le mot clé ILoveCandy dans la section # Misc options (sous [options]) du fichier /etc/pacman.conf. Puis au prochain pacman -Syu vous devriez voir des caractères ASCII en forme de Pacman tenter de manger les “points” de la barre de téléchargement.

Assez rigolo je dois dire 🤩.

La découverte des environnements de bureau de type Tiling Manager

Avec le côté « bidouille » d’ArchLinux, beaucoup de personnes participaient à l’arrivée de paquets dans AUR (dépôt de paquets communautaires) pour des environnements de bureau dit Tiling Manager. Sacrée tuile ! Au départ difficile, j’ai très vite apprécié un environnement de bureau que je compose moi-même de A à Z - ou presque. Je suis passé progressivement d’awesome à Sway :

2008 : mon passage à awesome,
2016 : je re-découvre i3wm et passe dessus,
juin 2021 : essais de Sway, alternative Wayland d’i3wm compatible avec les fichiers de configuration d’i3.

Je n’adopte finalement Sway qu’en mai 2025 et en fait mon environnement de bureau principal - j’ai beaucoup tardé cette fois.

Image prise en avril 2008 de mon bureau ArchLinux avec mon premier tiling manager nommé awesome.

(mon) installation semestrielle d’ArchLinux

À force d’installer tout un tas de choses, il est bon de nettoyer. Ou de réinstaller. Mais avec une distribution aux petits oignons, installer n’est pas une mince affaire. On peut oublier des paquets, des configurations, etc.

J’utilise donc 2 stratagèmes pour facilier la tâche :

un dépôt dotfiles : c’est un dépôt Git qui contient les configurations de nos applications (généralement contenues dans le dossier ~/.config),
un installeur nommé OBSCAIS qui facilite grandement une installation complète d’ArchLinux sur sa machine avec quelques fichiers et dossiers de configuration.

Je voulais aborder le sujet car on partage souvent nos dotfiles sur le Web, mais on ne parle jamais des outils pour automatiser notre installation.

Si au départ j’utilisais Ansible pour cela, j’ai vite déchanté et cherché une autre solution. Ce n’est que par hasard que j’ai découvert OBSCAIS. J’en suis très satisfait et j’ai déjà plusieurs dossiers (un par machine) pour installer ArchLinux à plusieurs endroits 😁.

L’autre solution aurait été de passer à NixOS, ce qui me paraît drastique pour automatiser l’installation de notre système d’exploitation.

À noter que sous Debian il y a le Preseed, Kickstart pour RedHat/Fedora, etc.

Finalement le monde du Logiciel Libre vous laisse le choix des armes 😉.

Conclusion

Jamais je n’aurais pensé trouver une distribution GNU/Linux qui me correspond, qui me ressemble. Enfin pas trop quand même, je suis dispersé !

J’ai testé de nombreuses distributions parmi Mandrake, Debian, Ubuntu, Gentoo, etc. Et j’ai eu de nombreux essais - infructueux - pour trouver une place dans différentes communautés comme Debian, Mandrake/Mandriva, NuTyX et Frugalware. Cela n’a pas fonctionné comme je l’espérais.

Avec le recul je me rends compte que cette expérience de 20 ans environ - avec des aléas comme souvent - m’a laissé naviguer sous ArchLinux avec brio. Que ce soit en machine de bureau ou bien en serveur, ArchLinux a toujours été à mes côtés pour fournir le service que je demandais.

Plus besoin de tester différentes distributions en se disant qu’elle sera meilleure que la précédente. Plus besoin d’installer en cassant le système en place ni en perdant les données. Plus de recherches incessantes sur Internet pour réparer ce que j’ai cassé, etc. Je peux enfin utiliser mon système pour travailler, m’amuser ou tout simplement casser d’autres choses 🤣.

Merci à ArchLinux, sa communauté, son wiki et tous les archers qui m’ont aidé. Merci à l’auteur d’OBSCAIS de partager un script qui change la vie et merci à ma persévérance et ma patience de quelques années jusqu’à avoir un environnement qui me plaît 😄.

Et vous, quelle est votre distribution phare ?

Liens utiles

Voici les liens de l’article par ordre d’apparition :

Geminispace VR

Tue, 22 Sep 2026 17:26:18 +0200

Introduction

En ce moment j’ai l’impression que l’informatique tourne à 100 à l’heure : on a du mal à suivre toutes les évolutions. Voire même tout simplement à savoir si ce sont réellement des évolutions 🤔. Qu’il y ait des outils variés - créés avec ou sans IA (Intelligence Artificielle) - ou bien de nouvelles façons de faire, on ne s’en sort plus. Et pourtant avec ce billet je vais y participer ; tout en vous prévenant que je n’ai pas inventé la roue, l’eau chaude ou que sais-je comme expression ringarde pour dire que je n’ai rien inventé de nouveau. Cette fois, je voulais simplement un peu de fun dans ce monde.

Tout commence par une phrase anodine de Richard Dern pendant une conversation au sujet de la « simplicité » dans l’informatique moderne :

Cela dit, tu as étudié Gemini ?

Il parle bien évidemment du protocole Gemini. D’ailleurs je me demande si je dois le remercier ou non 🤣. D’un côté j’ai découvert énormément de choses et vous en ait fait part dans mon dernier article sur « Étendre un blog Hugo jusqu’au protocole Gemini » ; de l’autre j’y ai passé beaucoup de temps 😅. @Richard Dern si tu me lis, ne m’en veux pas !

Pour en revenir à mon histoire, je me renseigne sur Gemini, j’apprends que c’est une alternative du Web située entre HTTP et Gopher. Et là je me souviens qu’à une époque très lointaine. Très lointaine. Très très lointaine (en 1995). Des développeurs de Gopher avait créé un client Gopher qui incluait un outil de visualisation en 3D. « E que s’apelerio GopherVR ». En 3D. Oui 3D. En 1995, vous imaginez ?

Image trouvée sur un article de LinuxFR concernant les INutilitaires graphiques.

Je me suis permis d’imaginer ! Je me suis dit : je veux du fun, j’ai un casque VR simple à disposition, je m’intéresse un peu au Geminispace, les pages Web du Geminispace sont simples, pourquoi on essaierait pas un petit Geminispace VR pour le fun ?

Et en même temps, j’avoue qu’un espace VR serait une sorte de troll comparé au protocole Gemini qui se veut extrêmement simple : faire un Geminispace VR serait un comble, un oxymore. Mais pourquoi pas après tout ?

Je vous propose dans cet article de vous présenter le concept de l’outil, où le trouver pour le tester (même sans casque VR) et ce qui pourrait être amélioré à l’avenir. C’est parti !

Concept et technologies utilisées

L’outillage

En me renseignant sur les technologies VR, je découvre WebXR :

WebXR est un standard web qui permet d’exécuter des expériences de réalité virtuelle (VR ou Virtual Reality) et de réalité augmentée (AR ou Augmented Reality) directement dans un navigateur compatible, sans avoir besoin d’installer d’application ou de plugin.

Cela semble pratique, et couplé à Javascript peut-être encore plus. Un simple site HTML/Javascript pourrait suffire.

Le concept

J’imagine alors une forme de navigation :

je souhaite visiter un seul site à la fois (sans saisir d’adresse pour le moment),
une fois sur le site - un Geminispace je le rappelle - je voudrais représenter chaque lien de la page par un polyèdre, chaque dossier, chaque fichier par un polyèdre. Chaque fois avec une couleur différente (vert pour un fichier, violet pour un fichier Gemini, gris pour le reste),
si je vise un polyèdre quelconque il s’illumine,
en « tirant/cliquant » sur le polyèdre scintillant, on se déplace dans le contenu pointé par le lien ciblé.

A priori rien de compliqué. Naviguer est une succession de « tirs », tout comme le serait une succession de clics. Parfait !

En revanche, je risque de me perdre dans le site : un dodécaèdre rouge au dessus de notre tête représente la racine d’où nous venons (comme un arbre de fichier avec son répertoire courant). De la même façon si on navigue ensuite sur un autre Geminispace, un second dodécaèdre rouge apparaît au dessus de nous pour représenter le site précédent. La navigation s’effectue relativement bien.

Nous sommes au début du projet, je dois dire que cette forme d’expérimentation est intéressante. Et inhabituelle pour moi.

Au fur et à mesure de l’usage, j’ai ajouté quelques règles/éléments :

sur les pages ayant énormément de liens, la population de polyèdres affichés explose les compteurs. Pour pallier à cela j’ai ajouté une légende sur votre droite qui permet de désactiver les liens par type (dossiers, fichiers *.gmi et liens HTTP(S)),
on affiche un panneau central avec le contenu du fichier index.gmi du répertoire courant,
à droite et à gauche du panneau central se trouvent des pyramides couchées bleues qui représentent « page suivante » et « page précédente »,
si la navigation sur une page contient un ou plusieurs liens, ils sont symbolisés par une sphère (une couleur différente par type de lien) sur le bord gauche du panneau central. Pointer la sphère fait qu’elle s’illumine. Au tir/clic : on s’y rend,
j’ai ajouté un message de validation Oui/Non au départ du site (si le lien nous fait naviguer vers d’autres rivages que le site actuel,
si on valide le départ, un second dodécaèdre rouge apparaît pour représenter le site d’où nous sommes partis.

Ce n’est pas une interface dite agréable en soi, mais c’est très amusant de « tirer » sur des liens et essayer de s’en sortir dans tout ce bazar 🤣.

Où trouver GeminispaceVR et comment le tester ?

Ledit « projet »

Les sources de cette expérimentation sont disponibles sur Gitlab dans l’espace odtre/gemini-vr. Ce projet est sous licence A-GPL.

Une démo est disponible sur demo.geminispace-vr.dossmann.net.

Ce projet a aussi été le cœur d’un test de Fable 5.1 (modèle provenant de chez ClaudeAI) pour voir l’autonomie d’une AI sur un projet à partir d’un prompt plus conséquent. 3$ plus tard c’était déjà utilisable. Et les corrections ont consommé 25$ de plus. Heureusement que les 100 premiers dollars étaient offerts 😅.

Tester / utiliser

Ainsi l’usage de Geminispace VR se fait via un navigateur compatible. Autrement dit :

Mozilla Firefox,
Google Chromium/Chrome,
Microsoft Edge.

Ou tout simplement le navigateur de votre casque VR, par exemple Meta Quest Browser.

Voici quelques uns de mes tests d’usage.

Navigateur Firefox et Chromium sur PC fixe

Au centre de l’écran se trouve un cercle qui représente un pointeur (j’appelle ça la mire 🤷),
un clic gauche maintenu, puis un déplacement de la souris va permettre de « regarder » ailleurs,
si vous déplacez correctement le cercle au centre sur un polyèdre, il s’illuminera et un clic permet de valider le choix « ciblé »,
en bas à droite un rectangle arrondi permet de mettre en plein écran. Inutile je trouve.

Mon expérience n’est pas très concluante sur le navigateur d’un PC fixe. Il manque clairement un dispositif de pointage.

Navigateur Firefox sur téléphone mobile

Il faut accepter au départ l’usage des senseurs du téléphone mobile pour une expérience plus sympathique,
et mettre l’écran en mode « paysage »,
un mouvement du téléphone (par exemple vers le haut) va faire comme si le téléphone était une fenêtre sur un nouveau monde,
de là, une simple pression sur l’écran peut faire l’effet d’un « clic » pour valider une cible visé,
mais cette simple pression en continu peut aussi faire avancer dans le monde (comme si on aggrandissait),
une pression avec deux doigts fait l’effet inverse : cela recule !

La navigation est plus agréable ainsi. Et toujours pas satisfaisante. Bonne chance pour arriver à cliquer sur le rectangle arrondi en bas à droite qui n’apparaît pas car il est hors champ de l’écran. Nul.

Naviguer casque VR avec le navigateur intégré

On lance le navigateur, on saisit l’URL, on met en plein écran,
le cercle au centre qui représentait un pointeur devrait disparaître,
vos dispositifs de pointage devraient faire apparaître des lasers qui permettent de cibler des polyèdres en tous genres,
à l’appui sur votre gachette du dispositif de pointage, cela devrait valider la cible,
si vous utilisez les joysticks des dispositifs de pointage vous pouvez vous déplacer dans cet « univers graphique » (mais le déplacement rend malade).

Clairement l’expérience est bien plus satisfaisante sur un casque VR. Usage totalement inutile et pourtant c’est le fameux fun que j’attendais 🥳. J’en suis content.

Améliorations possibles

Bien que le projet ait été fabriqué pour tester différentes choses comme WebXR, Fable 5.1 de chez ClaudeAI, une application sur casque VR et la navigation possible en 3D dans un Geminispace, je pense qu’on pourrait améliorer certaines choses :

l’affichage du panneau central est à parfaire. Je parle notamment de reconnaître tout ou partie de la syntaxe des fichiers Gemini (*.gmi),
l’arrivée sur une page contenant énormément de liens fait ralentir l’affichage, il serait bon de trouver une alternative (j’en imagine déjà plusieurs : désactiver automatiquement dans la légende le polyèdre correspondant si on dépasse un seuil critique de liens ou alors stopper l’affichage des liens à partir du seuil ou encore disposer les liens à la GopherVR en spirale),
il pourrait être sympa d’afficher en couleur les titres d’une page, par exemple rouge pour le titre #, vert pour ## et bleu pour ### (ce sont des titres de la syntaxe Gemini),
décaler le texte des citations,
afficher les images ou un système pour les consulter/voir,
améliorer l’affichage des boutons « page précédente » / « page suivante »,
améliorer l’affichage du panneau central,
etc.

J’avais aussi pensé ajouter un champ de saisie pour aller sur un site défini, mais cela demanderait la gestion d’un clavier et aussi la vérification de ce qui est saisi. On s’éloigne du fun à mon sens.

À vous d’imaginer ce qui pourrait être amélioré 😉.

Conclusion

Initialement parti d’une recherche sur le protocole Gemini, je me suis retrouvé dans une tornade d’idées provenant de mon imagination et dans un projet assez différent de mon habitude. J’ai apprécié modeler le concept initial et s’essayer à la 3D et l’AI - même si finalement je n’ai fais que diriger les opérations.

Je ne m’attendais pas à réussir quoique ce soit et j’avoue que ça commence petit à petit à être utilisable 😄. Jamais je ne me serais imaginé arriver à ce degré d’usage, bien qu’on puisse encore améliorer le concept !

Je me suis amusé à le faire tester à d’autres personnes, des adultes, des adolescents, etc. C’est très drôle de voir à quel point le seul concept d’une arborescence de dossiers et fichiers fait la différence entre quelqu’un qui saura s’en sortir ou quelqu’un qui sera totalement perdu. Promis, je ne suis pas sadique, je leur ai expliqué pendant l’expérience 😉.

N’hésitez pas à forker le projet, améliorer les éléments qui vous semblent pertinents, proposer des PR (Pull Request), créer des tickets, le refaire de 0 dans un autre langage, etc. Partagez également l’outil, c’est là pour s’amuser, alors amusez-vous !

Liens utiles

Voici les liens de l’article par ordre d’apparition :

Étendre un blog Hugo jusqu'au protocole Gemini

Tue, 15 Sep 2026 17:17:32 +0200

Introduction

Cela fait plusieurs années qu’à la fois certains amis et quelques articles du Web me rappellent que le protocole Gemini existe.

Définition du protocole Gemini par Wikipédia

Ce dernier (naissance en 2019) se veut être une alternative minimaliste au Web actuel, mais pas autant que le protocole Gopher (existant depuis 1991).

Découverte du protocole Gopher par Wikipédia

Une partie des internautes - sûrement les vieux barbus dont je fais partie, mais ça doit être un cliché de ma part - déplore les apparences trompeuses du Web (feuilles de style CSS mal fichues), les incompatibilités entre navigateurs, les trackers, les publicités, le pistage systématique, les batailles pour la protection des données (RGPD), etc.

Règlement Général sur la Protection des Données (RGPD)

Bref, « on en a gros » !

GIF animé évoquant « On en a gros » de la série TV Kaamelott

C’est ainsi que l’idée est d’avoir un protocole différent, avec un accès spécifique (gemini:// au lieu de http://) par des navigateurs faciles à développer et des serveurs tout aussi faciles à fabriquer/coder.

D’autres en parlent mieux que moi si le cœur vous en dit :

« Le protocole Gemini, revenir à du simple et sûr pour distribuer l’information en ligne ? » par Stéphane Bortzmeyer

« Gemini, le protocole du slow web » par Ploum

« Décollage : ce blog vient d’être propulsé dans le Geminispace ! » par Flozz

On s’égare un peu.

S’informer ne fait pas de mal, n’est-ce pas ?

Ainsi j’ai voulu faire déborder ce blog sur le Geminispace (l’espace internet composé de tous les sites disponibles en gemini://) et créer ma capsule Gemini ou gemlogs. Ce sont les deux mots que je retrouve fréquemment quand on parle de blog sur l’espace Gemini.

Le plan de cet article va être relativement simple. Nous débuterons par l’usage d’Hugo pour générer le blog au format gemtext (Gemini). Puis nous continuerons avec la mise en place d’un serveur Gemini pour servir le blog ainsi généré. Et finalement nous listerons quelques clients Gemini pour consulter notre nouveau gemlog (blog Gemini).

C’est parti !

Photo trouvée sur le profil de Alan Levine sur Flickr sous Licence Domaine public.

Utiliser les capacités d’Hugo pour générer un blog pour Gemini

J’utilise Hugo depuis 2016, un moteur de blog statique écrit en Go qui génère des dizaines de milliers d’articles en quelques secondes.

Mon article sur Hugo, le moteur de blog statique rapide et moderne

La particularité d’Hugo est donc de générer des fichiers (par exemple HTML) à partir de fichier source (par exemple au format Markdown) en passant par des templates (pour décrire le résultat attendu et remplir les « trous » par le contenu des fichiers sources).

En partant de ce principe, Hugo est capable de créer des fichiers Gemtext (suffixe de fichier gmi), attendus par Gemini.

Format Gemtext du protocole Gemini suivant Wikipédia

« Writing Gemtext (.gmi) » par Flounder (small web)

Remarquez que ce format est relativement simple. On va donc procéder à 2 actions :

modifier le fichier config.toml pour l’informer de générer des fichiers gmi,
ajouter des templates à utiliser pour générer les fichiers gmi à partir du contenu markdown déjà fourni.

À noter que plusieurs sites parlent déjà d’utiliser un projet Hugo pour créer du contenu pour Gemini (voire même pour Gopher !) :

« Converting hugo sites to Gopher Hole and/or to Gemini Capsule » par Mike A. Marin

« Une capsule gemini avec Hugo » par Alkahan

« Managing this site and my gemini capsule with Hugo » par bacardi55

Dépôt Github de mkamarin concernant le projet Hugo-2-Gopher-and-Gemini

Le fichier config.toml

Quelques lignes à renseigner dans le fichier config.toml (chez moi au format TOML) suffisent pour déclarer le nouveau besoin.

D’abord la déclaration d’un nouveau type de fichier :

[mediaTypes."text/gemini"]
    suffixes = ["gmi"]

Si vous souhaitez créer un fichier de flux Atom (pour vous déclarer sur des aggrégateurs de Gemini), il est aussi nécessaire d’ajouter quelques lignes :

[mediaTypes."application/atom+xml"]
    suffixes = ["xml"]

Ensuite on ajoute les différents formats de sorties :

[outputFormats.GEMINI]
    mediaType = "text/gemini"
    baseName = "index"
    isPlainText = true
    isHTML = false
    protocol = "gemini://"
    permalinkable = true

Si vous aviez ajouté un type de fichier atom+xml, n’oubliez pas d’ajouter aussi le format de sortie correspondant :

[outputFormats.ATOM]
    mediaType = "application/atom+xml"
    baseName = "atom"
    isPlainText = false
    isHTML = false
    protocol = "gemini://"
    permalinkable = false

Puis on demande à générer les fichiers en fonction des formats de sortie :

[outputs]
    home = ["HTML", "RSS", "GEMINI"]
    section = ["HTML", "RSS", "GEMINI"]
    page = ["HTML", "GEMINI"]

Si vous vouliez ajouter le format ATOM (par exemple sur votre page d’accueil pour avoir un /atom.xml), il suffit de l’ajouter dans la ligne “home = “ :

[outputs]
    home = ["HTML", "RSS", "GEMINI", "ATOM"]
    section = ["HTML", "RSS", "GEMINI"]
    page = ["HTML", "GEMINI"]

Le nouveau format est donc appelé GEMINI qu’on ajoute aux sorties “home”, “section” et “page”.

À la prochaine compilation, cela va générer des fichiers gmi. Du moins s’il y a des fichiers templates adéquats dans votre structure Hugo 😅.

Quelques templates pour Hugo

Nous avons déclaré 3 sorties (en plus de Gemini). Donc nous avons théoriquement 3 templates à créer :

un template pour la page d’accueil (layouts/index.gmi),
un template pour une page seule (layouts/_default/single.gmi),
et un template pour la liste des articles (layouts/_default/list.gmi) contenus dans le dossier “post”.

On créé donc le fichier layouts/index.gmi pour la page d’accueil :

# {{ .Site.Title }}

## Derniers billets

{{ range first 20 (where site.RegularPages "Type" "in" site.Params.mainSections).ByDate.Reverse }}
=> {{ with .OutputFormats.Get "GEMINI" }}{{ .Permalink }}{{ end }} {{ .Date.Format "2006-01-02" }} — {{ .Title }}
{{ end }}
## Autres pages

{{ with site.GetPage "/post" }}{{ with .OutputFormats.Get "GEMINI" }}=> {{ .Permalink }} Tous les billets
{{ end }}{{ end -}}
=> {{ .Site.BaseURL }} Version HTML de ce site

Je fais simple pour le début :

le titre du site,
une liste des 20 derniers billets précédés de la date,
un lien vers la liste de tous les billets,
et un lien vers la version HTML du site.

Dans la même veine nous allons créer le fichier layouts/_default/list.gmi pour afficher la liste des articles (contenus dans le dossier « post ») :

# {{ .Title }}

{{ with .Content }}{{ . | plainify }}

{{ end -}}
{{ range .Pages.GroupByDate "2006" }}
## {{ .Key }}

{{ range .Pages.ByDate.Reverse }}
=> {{ with .OutputFormats.Get "GEMINI" }}{{ .Permalink }}{{ end }} {{ .Date.Format "2006-01-02" }} — {{ .Title }}
{{ end }}
{{ end -}}
{{ with site.Home.OutputFormats.Get "GEMINI" }}=> {{ .Permalink }} Retour à l'accueil
{{ end -}}

Il affiche :

le titre du site,
éventuellement le contenu d’un _index.md contenu dans le dossier “post”,
puis affiche les articles groupés par année,
pour chaque année il affiche la liste des articles sous forme d’un lien composé de la date et du titre de l’article,
puis à la fin on affiche un lien pour revenir à l’accueil du site web.

Il ne reste que le fichier layouts/_default/single.gmi qui désigne l’affichage qu’aura un article au format Gemini. Je n’ai pas réinventé la roue, j’ai demandé à Internet et voici le résultat :

# {{ .Title }}

{{ .Date.Format "2006-01-02" }}{{ if .Params.tags }} — {{ delimit .Params.tags ", " }}{{ end }}

{{- $content := .Content -}}
{{- /* Blocs de code : on les protège avant de retirer le reste des balises HTML */ -}}
{{- $content = replaceRE `(?s)<pre[^>]*><code[^>]*>(.*?)</code></pre>` "\n```\n$1\n```\n" $content -}}
{{- /* Images -> lien gemtext dédié */ -}}
{{- $content = replaceRE `(?s)<img[^>]*src="([^"]+)"[^>]*alt="([^"]*)"[^>]*/?>` "\n=> $1 $2\n" $content -}}
{{- $content = replaceRE `(?s)<img[^>]*src="([^"]+)"[^>]*/?>` "\n=> $1\n" $content -}}
{{- /* Liens -> ligne "=> url texte" dédiée : gemtext exige que ce marqueur
     débute la ligne pour être reconnu comme un lien cliquable, donc on
     l'isole avec un saut de ligne avant et après plutôt que de le laisser
     inline dans le paragraphe */ -}}
{{- $content = replaceRE `(?s)<a[^>]*href="([^"]+)"[^>]*>(.*?)</a>` "\n=> $1 $2\n" $content -}}
{{- /* Titres */ -}}
{{- $content = replaceRE `(?s)<h[1-6][^>]*>(.*?)</h[1-6]>` "\n### $1\n" $content -}}
{{- /* Listes */ -}}
{{- $content = replaceRE `(?s)<li[^>]*>(.*?)</li>` "* $1" $content -}}
{{- $content = replaceRE `</?(ul|ol)[^>]*>` "\n" $content -}}
{{- /* Paragraphes et sauts de ligne */ -}}
{{- $content = replaceRE `</p>` "\n" $content -}}
{{- $content = replaceRE `<br\s*/?>` "\n" $content -}}
{{- /* Reste des balises HTML : on jette */ -}}
{{- $content = replaceRE `(?s)<[^>]+>` "" $content -}}
{{- $content = htmlUnescape $content -}}
{{ $content }}

{{ with .OutputFormats.Get "HTML" }}=> {{ .Permalink }} Version HTML de cet article
{{ end -}}
{{ if .PrevInSection }}=> {{ with .PrevInSection.OutputFormats.Get "GEMINI" }}{{ .Permalink }}{{ end }} Article précédent : {{ .PrevInSection.Title }}
{{ end -}}
{{ if .NextInSection }}=> {{ with .NextInSection.OutputFormats.Get "GEMINI" }}{{ .Permalink }}{{ end }} Article suivant : {{ .NextInSection.Title }}
{{ end -}}
{{ with site.Home.OutputFormats.Get "GEMINI" }}=> {{ .Permalink }} Retour à l'accueil
{{ end -}}

Le template va :

afficher le titre,
afficher la date, puis la liste des tags attribués à cet article,
afficher le contenu de l’article en remplaçant d’abord les blocs de code, puis les images, puis les liens, puis les titres, puis les listes, puis les paragraphes et sauts de lignes et enfin le reste des balises HTML sont jetées,
en bas de l’article on va afficher un lien HTML de l’article, un lien vers l’article précédent, un lien vers l’article suivant et finalement un lien pour retourner à l’accueil.

Il y a encore du boulot pour avoir quelque chose de propre, mais c’est un bon début !

On peut tester le résultat en faisant :

hugo && ls ./public

Le dossier « public » devrait a minima contenir un fichier index.gmi.

Passons à la publication du blog (appelé aussi gemlogs).

Servir les fichiers sur l’espace Gemini

À la découverte du protocole Gemini on découvre aussi pléthore d’outils/logiciels. Et même une page Github nommée « awesome-gemini ».

Liste de logiciels connus par le site officiel geminiprotocol.net

Liste sous Github d’outils en tous genres autour du protocole Gemini

Pas facile de faire le tri, alors je suis allé au plus simple : un serveur léger et rapide, relativement maintenu et qui gère le certificat TLS auto-signé de longue durée nécessaire à la création d’un espace Gemini. Un espace seulement (ne gère pas d’hôtes virtuels appelés vhosts).

Je parle d’Agate.

Découvrir le dépôt Github d’Agate

Utiliser le serveur Agate à l’aide de Docker Compose

En bref, j’ai fait un fichier docker-compose.yml et un fichier .env comme ceci (le fichier docker-compose.yml en premier) :

services:
  agate:
    image: ghcr.io/mbrubeck/agate:3.3.24
    container_name: agate

    restart: unless-stopped
    init: true

    # Agate n'a besoin d'aucune capacité Linux particulière.
    cap_drop:
      - ALL

    # Empêche toute élévation de privilèges.
    security_opt:
      - no-new-privileges:true

    # Le système de fichiers du conteneur est en lecture seule.
    # Les seuls emplacements accessibles en écriture sont les volumes
    # explicitement montés et /tmp.
    read_only: true

    # Agate n'a pas besoin d'un utilisateur root.
    user: "${AGATE_UID}:${AGATE_GID}"

    pids_limit: 50

    ports:
      - "1965:1965/tcp"

    volumes:
      # Contenu de la capsule Gemini
      - ${DATA_DIR:-./data}:/gmi:ro
      # Certificats et clés privées persistants
      - ${CERTS_DIR:-./certs}:/certs

    tmpfs:
      - /tmp:rw,noexec,nosuid,nodev,size=16m

    command:
      - "--hostname"
      - "${DOMAIN_URL}"

Et mon fichier .env :

# Nom de domaine de la capsule Gemini
DOMAIN_URL=gemini.example.org

# Répertoire contenant les fichiers Gemtext
DATA_DIR=/srv/data/agate/gmi

# Répertoire persistant contenant les certificats et clés privées
CERTS_DIR=/srv/data/agate/certs

# UID/GID utilisés par Agate dans le conteneur.
# Le répertoire certs et le répertoire logs doivent appartenir à cet UID/GID.
AGATE_UID=65534
AGATE_GID=65534

Les dossiers doivent exister et appartenir au UID/GID pour que tout fonctionne. Donc pensez à changer les permissions desdits dossiers 😉. Par exemple chez moi j’ai dû faire :

cd /srv/data/
mkdir -p agate/gmi
chown 65534:65534 -R ./agate

pour que cela fonctionne.

Ouverture de ports

C’est le port 1965 (sur TCP) que le serveur Gemini utilise. Il faut donc penser à ouvrir le port de votre box, de votre pare-feu ou tout autre élément bloquant les entrées/sorties.

Une fois cela fait, démarrez le serveur Gemini (ici Agate). Quelque chose comme :

docker compose up -d

Vous devriez désormais avoir votre capsule Gemini, bravo !

Mais au fait, comment se rendre sur l’espace Gemini ?

Naviguer dans l’espace Gemini

C’est bien beau d’avoir un serveur Gemini, mais comment y accéder ?

Afin de naviguer dans le Geminispace vous avez besoin d’un navigateur compatible. Si vous êtes patients et méthodique, vous trouverez une liste de clients Gemini sur la page suivante :

Liste de logiciels connus par le site officiel geminiprotocol.net

ou encore sur Github :

Section « clients » de la page Github qui liste des projets pour le protocole Gemini

Et si vous êtes paresseux - comme moi - vous pouvez utiliser l’un de ceux que je propose pour chaque type de navigateurs parmi :

un client graphique compatible Linux, MacOSX et Windows : Lagrange,
un client en ligne de commande (sous GNU/Linux) : amfora,
et une navigation via un proxy HTTP.

Navigateur graphique multiplateformes Lagrange

amfora, un navigateur en ligne de commande

Portail portal.mozz.us pour accéder à Gemini par HTTP

Dans la situation où cela vous débéquette d’installer un énième logiciel, le proxy HTTP est une bonne alternative. Il en existe d’autres évidemment.

Section « web-proxies » de la liste Github « awesome-gemini »

Conclusion

Passer à Gemini depuis Hugo semble se passer relativement bien et assez facilement après quelques bidouilles. Et je dis bien bidouille car, si vous le remarquez bien, ce article a été écrit de manière différente : je place les liens après les phrases et paragraphes.

En effet un lien Gemini commence en début de ligne sous un format spécial :

=> https://perdu.com Je suis perdu

Ainsi, entre le HTML où les liens se trouvent à n’importe quel endroit et le gemtext (format Gemini) dans lequel je voudrais afficher les liens, je dois faire des sauts de ligne et afficher le lien. Ce qui découpe fortement les articles déjà existants.

En dehors de la lisibilité, le blog s’étend désormais sur Gemini depuis le 8 septembre au soir. Vous pouvez le consulter sur un proxy HTTP dont je vous donne le lien ci-après :

Le site Olivier DOSSMANN sur le protocole Gemini via le portail « proxy » portal.mozz.us

Revoir les articles m’a amené à constater qu’il manque encore des sujets de mon ancien blog nommé « Le BlankoJoueb » que vous pouvez trouver à l’adresse suivante (pour les petits curieux) :

Le BlankoJoueb

J’avance doucement mais sûrement vers le Geminispace dont nous parlerons encore sur ce blog. Ça vaudra le détour avec ce que je vais sortir 😉.

Liens utiles

Voici les liens de l’article par ordre d’apparition :

Firmware CrossPoint (+ WebDAV) sur la liseuse Xteink X4

Wed, 05 Aug 2026 13:56:53 +0200

Introduction

De temps en temps je lis les nouvelles du site MiniMachines qui publie des bons plans sur du matériel - mais pas que. C’est toujours l’occasion de savoir où en sont les prix du marché de l’informatique (notamment les ordinateurs, les périphériques et les composants électroniques). J’avoue que c’est comme une forme de pr0n pour certains geeks 😅.

Je suis ainsi tombé sur un article concernant la micro liseuse Xteink 4 Pro à 4.3 pouces de diagonale écran. Si d’emblée l’appareil ne m’intéresse pas - car trop petit - j’ai immédiatement pensé à quelqu’un de la famille à qui ça pourrait plaire. Une personne qui aime lire mais n’a pas - encore - de liseuse et dont l’anniversaire arrive prochainement. Parfait, ça ne pouvait pas mieux tomber !

Dans cet article je vais vous parler du choix de la liseuse, la découverte d’un firmware (pilote) alternatif et ensuite l’installation de celui-ci. Et enfin, suite à quelques désagréments, comment et pourquoi j’ai activé un accès WebDAV sur cette liseuse.

La liseuse

Je me renseigne pour en savoir plus sur ces liseuses Xteink et ce qu’elles valent. Sur le site officiel Xteink plusieurs modèles sont proposés :

Xteink X4 Pro,
Xteink X4,
Xteink X3.

Ci-après une image comparative (prise de chez MiniMachines, sûrement elle-même prise de chez Xteink) des 3 modèles :

A priori le modèle intermédiaire, c’est à dire la Xteink X4, serait idéal pour le cadeau d’anniversaire que je souhaite faire. Cependant je tombe sur l’article de Liseuses.net concernant la Xteink X4. Pour récapituler ce que j’en comprends : la liseuse fait parler d’elle non pas pour son interface utilisateur - à chier, il faut dire ce qui est - mais pour à la fois son prix ET son pilote alternatif disponible sur Internet.

Découverte puis installation du pilote alternatif CrossPoint

Mais de quel pilote parlons-nous ? Il s’agit du pilote CrossPoint disponible sur crosspointreader.com. C’est un pilote open source permettant d’améliorer l’expérience utilisateur sur plusieurs liseuses. Sur la Xteink X4 cela offre plus de fonctionnalités et s’exprime par :

une meilleure mise en forme du texte et une meilleure mise en page des ebooks (livres numériques),
davantage de polices et d’options de configuration,
amélioration du système de menus,
de meilleurs outils pour transférer les ebooks vers la Xteink X4,
et une prise en charge de langues supplémentaires (comme le Français).

En somme ce pilote promet monts et merveilles et devrait nous propulser vers l’infini et au delà ! (pour ceux qui ont la référence 😉) Voyons comment l’installer.

A priori c’est simple :

on branche la liseuse en USB,
on se rend sur le site de CrossPoint, plus spécifiquement sur l’URL permettant de « flasher » la liseuse avec CrossPoint,
on choisi son appareil, ici Xteink X4,
puis on sélectionne le pilote à installer (notez que Stock English et Stock Chinese permettent de réinstaller la version d’origine de la liseuse), on sélectionne CrossPoint v1.5.0,
et on clique sur le bouton « Flash CrossPoint » (un menu apparaît dans le navigateur pour sélectionner l’appareil sur lequel installer).

Simple comme bonjour, mais compliqué comme de l’informatique : ça n’a pas fonctionné chez moi. Serait-ce le karma et mes choix de vie qui influent 😂 ? Non pas du tout, chaque difficulté avait une solution.

Premièrement il faut un navigateur compatible, par exemple Chrome. Chez moi : Chromium (sous ArchLinux). Ensuite, toujours sous ArchLinux, la liseuse n’était pas reconnue. Je vous rassure : il y a peu de chance que vous ayez le même souci sur Windows ou sur tout autre système GNU/Linux. Comment le régler si jamais ? Il suffit d’ajouter votre utilisateur au groupe uucp :

sudo gpasswd -a olivier uucp

Pensez à redémarrer la session utilisateur.

Et vous voilà avec un nouveau pilote, une liseuse toute neuve et superbement utilisable ! Alors pourquoi n’étais-je pas content jusqu’au bout ?

Accès à une bibliothèque auto-hébergée

Pour transférer des fichiers (et donc des livres) sur la Xteink X4 (avec un pilote CrossPoint fraîchement installé) nous avons - à ma connaissance - plusieurs façons de procéder :

utiliser la carte micro SD sur un ordinateur, puis la remettre dans la liseuse,
utiliser le menu « Transfert de fichiers » dans le menu principal de la liseuse et choisir « Rejoindre un réseau ». Cela permettra d’accéder depuis son ordinateur à une interface Web contenant un onglet pour gérer les fichiers contenus sur la liseuse,
utiliser ce même menu de transfert de fichiers pour sélectionner « Connexion Calibre sans fil »,
aller dans « Réglages » > « Système » > « OPDS Servers », puis ajouter un lien vers un serveur OPDS.

Cette dernière option implique d’avoir un serveur OPDS installé. Qu’est OPDS ? Je vais faire simple : un format de syndication (comme les flux RSS si on veut) développé par des groupes comme Internet Archive (dont vous connaissez sûrement la WayBack Machine pour consulter des “snapshots” d’un site web dans le temps) ou encore les Éditions O’Reilly (qui fabriquent des livres d’informatique). En gros tu mets un serveur, tu t’y connectes et tu peux récupérer des articles, des livres, etc. au format numérique. C’est une bibliothèque numérique en somme !

C’est très pratique à l’usage, mais pas à la préparation : il faut monter un serveur OPDS. On pourrait donc se rapatrier sur une connexion Calibre sans fil, mais là encore ça demande l’installation d’un outil particulier.

La personne à qui j’offre la liseuse a accès à un serveur OpenCloud. Ce service propose un serveur WebDAV. Récemment j’ai pu lire un article concernant l’utilisation de KOreader sur une liseuse pour accéder au WebDAV d’un serveur OpenCloud. Cela tombe bien car cela pourrait être très pratique pour la personne !

Fort de cela, j’apprend que la communauté des utilisateurs Xteink X4 discute d’une possibilité d’inclure WebDAV dans CrossPoint. Et qu’une branche d’un fork du dépôt propose un avant-goût de la fonctionnalité WebDAV.

Tentons l’aventure !

Installation d’un pilote alternatif CrossPoint ayant WebDAV

La procédure d’installation d’un pilote est similaire à celle que nous avions faite avant.

Cependant, ce qui change : on doit compiler le pilote nous-même avec le dépôt fourni. Étant sous ArchLinux je vais décrire la procédure utilisée sur ma machine.

On commence par le dépôt non-officiel suivant : https://github.com/mmajewsk/crosspoint-reader/tree/feature/webdav-client
On duplique le dépôt, et on se rend sur la branche webdav-client puis on télécharge les sous-modules git :

git clone https://github.com/mmajewsk/crosspoint-reader.git
cd crosspoint-reader
git switch feature/webdav-client
git submodule update --init --recursive

On a besoin de la commande pio, disponible dans le paquet « platformio-core » (Cf. le wiki ArchLinux concernant PlatformIO sur la page Arduino) :

sudo pacman -S platformio-core

De là on peut enfin compiler le pilote :

pio run

Une fois la compilation terminée, le pilote est disponible dans le dossier .pio/build/default
Il se nomme firmware.bin,
On réutilise le site web de CrossPoint pour flasher la liseuse, mais cette fois on choisit l’option « Custom bin »,
On sélectionne notre fichier firmware.bin,
Et on clique sur le bouton « Flash CrossPoint ».

WebDAV fait désormais partie du menu principal ! J’ai testé rapidement avec un dossier WebDAV à moi : cela fonctionne bien. Je suis content, désormais le cadeau est prêt à être emballé 😋.

Conclusion

Avec un prix aussi avantageux et un pilote alternatif aussi riche, cette liseuse Xteink X4 est une très belle opportunité de faire un cadeau sympathique à une personne qu’on apprécie.

Après avoir compilé puis flashé le nouveau pilote basé sur CrossPoint, on accède à un menu WebDAV qui va changer la vie à la personne à qui j’offre cette liseuse. J’espère que ça lui plaira et qu’elle sera contente de pouvoir ajouter son propre dossier WebDAV contenant ses ebooks.

Les manipulations autour de cette liseuse sont relativement simples et j’espère que cela vous motivera aussi à en avoir une ou tout simplement à en offrir une.

Edit : au 14 août (et peut-être avant), le site constructeur Xteink affichait l’épuisement du stock des liseuses X4 et l’abandon de cette dernière. Cependant le modèle X4 Pro est toujours disponible et succède la X4. Le pilote CrossPoint fonctionne aussi avec ce modèle.

Sachez également que la communauté des liseuses Xteink X3, X4 et X4 Pro a fabriqué tout un tas de pilotes disponibles sur le site readme.club. Il y a des jeux proposés, de nouvelles fonctionnalités et même un sniffeur réseau wifi. De quoi pousser l’expérience utilisateur encore plus loin !

Liens utiles

Voici les liens de l’article par ordre d’apparition :

BT-22 Wingman Elite, un chargeur de batterie en 1 clic

Thu, 30 Jul 2026 16:27:15 +0200

Introduction

À la suite d’une multitude d’échanges avec un ami je découvre l’existence d’un petit appareil nommé le BT-22 Wingman Elite de chez Kodai Industries. Nous allons voir à quoi cela ressemble et pour quel(s) usage(s). Je vous donnerai mes impressions sur ce produit qui permet de charger nos objets électroniques tels que téléphone mobile, écouteurs sans fils, liseuse, console de jeux portable, ordinateur portable, etc.

Pour information, je n’ai aucun lien d’affiliation avec le constructeur et/ou le vendeur. Je ne fais que partager mes impressions sur un appareil que j’ai acheté récemment.

Présentation

J’ai ainsi fini par craquer pour le BT-22 Wingman Elite de chez Kodai Industries, un chargeur de batterie externe qui ne vient pas avec sa batterie intégrée : on choisit son propre modèle de batterie (18650 ou 21700]) qu’on glisse dedans. Un clic, et on peut utiliser l’ensemble pour charger la batterie ou nos appareils électroniques !

C’est simple, pratique et cela utilise l’USB PD (Power Delivery) pour négocier automatiquement la bonne puissance avec l’appareil branché et ainsi favoriser une charge rapide. Résultat : ça charge vite, et c’est simple d’utilisation - un seul bouton, un seul clic. Parfait 😄

Livré sans batterie - comme je le disais déjà - il est intéressant de commander ses propres batteries sur un site de vente en ligne de produit pour cigarettes électroniques (batterie 18650 ou 21700) ou un vendeur spécialisé. Dans mon cas cela a été des batteries BAK 45D 21700 à 4500Mah - 60A sur nkon.nl. J’en suis content.

Description du produit

Le BT-22 Wingman Elite de chez Kodai Industries possède les caractéristiques suivantes :

Insertion d’une batterie en 1 clic,
L’appareil est au format carte de crédit,
37 grammes (sans batterie),
Affichage du niveau de batterie,
3 modes :
- charge rapide (sortie 9V/12V),
- mode éco (sortie 5V seulement),
- mode “courant” : l’appareil n’est pas en sommeil,
Fonctionne avec plusieurs batteries. Il est compatible avec de multiples appareils,
Livré avec une lanière composée d’un câble USB,
Module de lampe avec 4 modes :
- Lumière blanche/mélangée,
- Lumière froide,
- Lumière chaude,
- Mode SOS,
Apparence travaillée façon futuriste.

On peut également commander un support pour poser le chargeur et ses batteries.

Le produit est disponible sur le site officiel de Kodai Industries. Il est à environ 30€ avec des frais de ports d’environ 11€.

Mes impressions

Le tarif est relativement correct pour ce type d’objet et ce qu’il propose. Oui, c’est plus cher qu’une “powerbank” classique : à budget égal vous trouverez une powerbank de capacité supérieure. Mais l’argument qui m’a convaincu est ailleurs : quand la batterie est usée, on ne change qu’elle, pas tout l’appareil. C’est plus écologique qu’une “powerbank” qu’on jette entièrement au bout de deux ans - ce qui est discutable à cause du trajet de livraison. Plus souple à l’usage aussi, puisqu’on peut choisir la capacité de sa batterie selon ses besoins du moment. Et s’il faut plus de capacité de recharge, on emmène avec soi plusieurs batteries.

En revanche, je raille légèrement : le câble USB en dragonne (un câble qui s’enroule et se porte comme un bracelet) est une excellente idée sur le papier, mais cette lanière s’est révélé très fragile. Dommage.

Un module lumineux est fourni. Je ne vois absolument pas à quoi il sert au quotidien, mais je me dis qu’il doit bien y avoir une utilisation que je n’ai pas encore trouvé.

Petite anecdote encore, mon premier exemplaire est arrivé abîmé par le transport : il chauffait énormément et était inutilisable. Le SAV a été bluffant de réactivité : échange immédiat, contre simplement une photo de l’ancien appareil à la benne. Il semblerait que ce type de souci arrive de temps en temps à cause du mode de transport, une forme d’électricité statique accumulée en chemin et détériorant les circuits. Bon à savoir si ça vous arrive aussi.

Conclusion

Malgré ce premier accroc, j’ai l’impression que le BT-22 Wingman Elite va m’accompagner partout : pratique, rapide à charger, simple d’utilisation. Le câble fragile et le module lumineux inutile sont mes seuls vrais bémols. Pour le reste, c’est tout bon 😃.

Pensez à acheter des batteries de qualité en lisant les commentaires sur les sites où vous comptez les acheter. Un prix important n’implique pas forcément une bonne qualité de batterie (la preuve en est pour les BAK 45D 21700 à 2,49€ pièce sont très abordables).

Je vous conseille également de prêter attention au stockage de vos batteries : les laisser de préférence presque vides et dans un étui empêchant tout contact avec d’autres métaux ou substances. Un sac ignifugé est également idéal pour stocker ce genre de batteries.

Et surtout : profitez de cette nouvelle liberté d’avoir un “powerbank” modulable et adaptée à vos consommations et besoin. Un bonheur !

Liens utiles

Voici les liens de l’article par ordre d’apparition :

Projet tablette, alternative à Sweepy pour les tâches ménagères

Tue, 23 Jun 2026 21:12:35 +0200

Introduction

Je continue dans ma lancée de création d’une tablette tactile pour la maison en attaquant un des sujets principaux de ce foyer : les tâches ménagères. L’idée est de remplacer une application existante - et payante - par un équivalent en Logiciel Libre auto-hébergé.

Cet article ressemble bien plus à une réflexion autour du sujet et une présentation de la solution choisie qu’à un guide d’installation. Il n’y sera donc pas question de configuration serveur ni de déploiement spécifique. Si ces détails vous intéressent, vous pouvez le suggérer en commentaire d’un de mes articles publiés sur le Journal du Hacker - dont je vous recommande vivement la lecture (je parle du Journal, pas de mes articles 🤣).

L’ancien Sweepy

Un jour quelqu’un nous conseille une application - payante - nommée Sweepy (sur téléphone mobile) pour gérer à plusieurs les tâches ménagères. Que cela signifie-t-il et comment cela fonctionne-t-il ?

Page d’accueil de Sweepy avec la liste des pièces

Page d’accueil d’une pièce dans Sweepy avec la liste de ses tâches

Nous sommes plusieurs dans le foyer et souvent nous oublions des tâches à faire ; voire nous faisons, l’un après l’autre, à quelques heures de différence, la même tâche. En pareille situation nous pourrions mettre une feuille comme dans les aires d’autoroute pour noter qui a fait une tâche en dernier. Cela ne nous convient pas. Quand notre contact nous a parlé de Sweepy, on s’est dit “pourquoi pas ?”. Et on s’est lancé.

L’application est centrée sur les pièces de la maison : on crée chaque pièce, puis on ajoute petit à petit chaque tâche qu’on souhaite effectuer dans la pièce et les points (ou plutôt la pénibilité) de la tâche. On évoque aussi le laps de temps maximum entre chaque action d’une même tâche, autrement dit on définit un cycle au bout duquel on doit recommencer la tâche (parce que oui une maison ne reste pas propre indéfiniment !).

L’application se veut être un serious game avec un thème tout aussi ressemblant à un jeu vidéo : bleu avec un nuage blanc animé pour nous tenir compagnie. On voit les points de chacun, des trophées à déverrouiller, des trophées cachés et on voit nos statistiques de jeu - oups, je veux dire de travail. Cela va jusqu’à nous inciter à dépenser les points accumulés pour embellir les pièces qui sont matérialisées par des images du type de pièce (salle de bain, chambre, etc.). Comment améliorer une pièce de la maison ? On utilise les points en échange d’un meuble, d’une décoration, d’un tableau, etc. pour le déposer dans une pièce. Évidemment le nombre d’objets qu’on peut acheter est limité dans le temps et change chaque jour/semaine. De quoi obliger à revenir sur l’application chaque jour.

Bien que ce type de système ne m’intéresse pas, et encore moins la gamification d’une application, il semble que mes colocs soient plus réceptifs. Et cela fonctionne donc pour eux.

L’idée d’une application alternative, nos attentes

Après avoir utilisé cette application pendant 2 ans tout de même, j’ai constaté qu’on y utilisait peu de fonctionnalités. Elle est effectivement payante si nous sommes plus qu’une personne (c’est-à-dire plus qu’un téléphone mobile sur le même foyer). Ainsi on pourrait noter les éléments suivants comme l’« essence même » de notre activité sur Sweepy :

plusieurs utilisateurs sur la même interface,
création de pièces de la maison pour regrouper les tâches,
notion de difficulté de la tâche (représentée par des points dans Sweepy),
système de cycle des tâches, c’est-à-dire la fréquence à laquelle refaire la tâche régulièrement (par exemple “tous les 6 jours”),
possibilité d’affecter une tâche à quelqu’un - peu usité chez nous, mais utile,
visualisation rapide de la progression d’une tâche : au début elle a une barre de progression verte, puis au fil des jours elle devient orange puis rouge,
tri des tâches de la maison entière par « urgence » (les plus urgentes d’abord) ou par pièce.

Sweepy propose aussi une affectation aléatoire des tâches pour chaque personne. Une sorte de suggestion, mais nous n’avons jamais utilisé cette fonctionnalité.

Avec si peu de besoins, je me suis dit qu’on pourrait éventuellement trouver une application auto-hébergeable qui serait libre ou au moins open-source et utilisable à la maison.

Une solution alternative incomplète ?

Sur les critères listés dans le précédent chapitre j’ai trouvé quelques solutions auto-hébergées (c’est-à-dire que je pourrais installer moi-même sur un serveur à la maison) comme :

Il y en a sûrement d’autres. Commençons.

Grocy est un outil que j’ai déjà utilisé dans le passé. Je le trouve plutôt complet mais pas du tout intuitif pour le commun des mortels. Il possède une API (Application Programming Interface permettant de connecter d’autres applications après) que je pourrais utiliser pour générer une interface plus simple. Il a l’avantage de gérer plusieurs choses de la maison, en plus des tâches ménagères, comme :

la gestion des piles/batteries de la maison,
la gestion des manuels d’utilisation des appareils de la maison,
les stocks de nourriture,
des recettes de repas,
la liste des courses,
et plus encore.

Plutôt overkill pour l’usage visé.

Tableau de bord des corvées sous Grocy

Concernant Vikunja, il propose une boîte de réception dans laquelle on peut créer des tâches à la volée avant de les redistribuer/trier. Il propose une gestion par projet, par étiquette, et son affichage est très moderne : vous pouvez afficher les tâches en vue kanban, liste, Gantt ou tableau. C’est merveilleux ! Il dispose également d’une API et d’un système de webhooks, ce qui est très pratique pour le lier à un outil comme n8n pour automatiser certaines actions.

L’outil se rapproche de mes attentes. Je pourrais par exemple utiliser les projets pour définir une pièce et les tâches à l’intérieur. Cependant, bien qu’il propose une gestion de répétition cyclique avec une répétition à la date d’achèvement, on sent qu’il cible une autre forme de gestion, plus personnelle et privée. En dehors du cadre de notre gestion des tâches ménagères.

Je garde donc Vikunja pour un usage autre car il me plaît beaucoup. Mais pas pour notre solution alternative.

Page d’accueil de Vikunja

Passons à Donetick qui est minimaliste et léger. Visuellement il se rapproche de Sweepy. À la création d’une tâche, les options permettent de renseigner la répétition cyclique basée sur la date d’achèvement de la tâche. C’est ce qui permet de relancer la répétition seulement au jour où on a fini une tâche. Par exemple si on doit faire une tâche tous les 7 jours, si la première fois on l’effectue un samedi, la prochaine échéance est samedi d’après. Mais si on finit par faire la tâche le dimanche, alors la prochaine échéance sera un dimanche. C’est un petit projet très récent qui reste discret (et écrit en langage Go). Il permet, de base, de trier les tâches suivant l’urgence à les faire. Et son système d’étiquettes permettrait de regrouper les tâches par « pièces » (puisqu’une pièce serait représentée par une étiquette).

En revanche, pas de visualisation par barre de progression en fonction de l’urgence. Et bien qu’un système de création de filtres personnalisés existe, pour une raison qui m’est inconnue pour l’instant, ils ne restent effectifs/existants que sur le navigateur qui les a créé. Plutôt embêtant.

Page d’accueil de Donetick

3 outils, 3 façons différentes d’aborder le sujet. Mais aucun ne remplit toutes les cases. Ils ont tous une API pour accéder aux données, c’est ce qui m’a donné l’idée de créer un frontend à l’un d’eux. Lequel choisir ? On a écarté Grocy et Vikunja, pourquoi ne pas tenter l’aventure avec Donetick et voir ce que cela donne ? Il est léger, avec une simple base de données SQLite3 sous forme de fichier. Pour une cinquantaine de tâches ménagères ça sera super 😋.

Un Dashboard maison, pour la maison !

Page d’accueil de donetick-dashboard

C’est ainsi que j’ai créé de toutes pièces un Dashboard à Donetick pour les spécificités de notre foyer : donetick-dashboard alias « Maison Propre ».

Dans la forme, ça ressemble à un Dashboard classique : des cartes affichées représentant les tâches. Un menu avec des boutons pour choisir la pièce de la maison et filtrer sur les tâches correspondantes. Et de quoi se connecter en haut à droite de l’écran.

C’est simple, fonctionnel. Au début nous sommes amenés à nous connecter via une fenêtre modale, puis les tâches sont récupérées via l’API de Donetick et affichées. Pour un foyer, le nombre de tâches est généralement si infime que Donetick suffit amplement avec son fichier *.db (SQLite3) comme base de données.

donetick-dashboard propose les fonctionnalités suivantes :

tâches principales affichées par ordre d’urgence,
barre de progression de la tâche en couleur (rouge, orange, vert),
filtrage par pièce (il faut créer des tags sur Donetick avec le nom des pièces et y affecter vos tâches),
possibilité de marquer une tâche comme « faite » - avec fenêtre modale de validation (pour éviter les erreurs),
multi-utilisateur : on passe d’un compte à l’autre.

La technologie utilisée est NuxtJS que j’avais déjà touchée l’année dernière pour faire un Dashboard similaire.

Le projet est disponible en Docker sur le Hub Docker et utilisable avec docker-compose dans le dépôt du projet donetick-dashboard, n’hésitez pas à aller jeter un œil et tester par vous-même 😉.

Retour d’expérience

Après plus de 5 semaines d’utilisation ce Dashboard rend pleinement service au quotidien. Les utilisateurs sont contents. Ils apprécient :

l’apparence simple,
le système de carte - bien qu’ils aimeraient réduire la taille des cartes affichées,
la facilité d’utilisation,
le système de filtre par pièce,
le changement possible d’utilisateurs.

Ils ont aussi émis quelques souhaits - et je trouve important de le signaler :

ils aimeraient réduire la taille des cartes affichées qui leur paraissent trop grandes,
ils attendent avec impatience un système pour afficher les points de chacun et les points que rapporte chaque tâche,
ils ont voulu trier la liste des pièces toujours de la même manière - ce qui a été intégré,
ils voulaient disposer d’une liste « fixe » de tâches par pièce pour éviter que valider une tâche ne la réordonne tout en bas - ce qui a été intégré,
ils voudraient changer de système de validation d’une tâche et passer d’une fenêtre modale à un changement du bouton lui-même,
le pourcentage de l’ensemble de la maison les dérange. Ils préfèreraient un pourcentage par pièce.

Je suis plutôt content de l’engouement de certains, contrairement à ce qu’ils exprimaient initialement. Avoir des retours est plaisant - même si parfois ça me crispe. Et content de modifier ensuite l’application.

Conclusion

De Sweepy à donetick-dashboard, le chemin n’était pas évident. Mais le résultat est là : une solution libre, auto-hébergée, et adoptée par le foyer.

Je suis assez content du résultat aux vues de mes connaissances en matière de Dashboard et frontend en tous genres. Également surpris de l’engouement des utilisateurs que j’ai. Et pressé de pouvoir trouver le temps d’intégrer leurs demandes à l’outil.

Je sais bien qu’il ne faut jamais réinventer la roue, mais cette expérience unique m’amène à penser que certaines situations s’y prêtent. Sachons tout de même doser pour éviter de développer à l’infini toutes nos applications 😉.

Et vous, quel outil libre/open-source auto-hébergé de gestion de tâches utilisez-vous au quotidien ?

Liens utiles

Voici les liens de l’article par ordre d’apparition :

Projet Tablette, Introduction

Sun, 24 May 2026 21:40:00 +0200

Introduction

Après trois ans dans un tiroir, ma tablette tactile CHUWI Hi10Go dont je parlais dans l’article précédent a refait surface. Et avec elle, un projet qui attendait patiemment : le Projet Tablette.

T’as pas cherché loin.

C’est sûr, le titre n’est pas très racoleur. On fait avec.

Cet article présente ce que j’entends par « Projet Tablette » - à part que c’est une tablette. Les grandes lignes, les usages imaginés, et ce que vous retrouverez dans les prochains articles au fil des semaines.

Les grandes lignes

À l’achat de la tablette, j’imaginais surtout m’amuser sous GNU/Linux - sans usage précis en tête. Honnêtement, un écran tactile ne m’a jamais semblé indispensable dans mon quotidien. Mais la vie de famille a ses propres exigences, et j’ai progressivement construit un projet dans ma tête pour servir le foyer entier.

Ainsi je visualise plusieurs usages potentiellement intéressants au sein du foyer :

Pouvoir suivre les tâches ménagères de la maison, leur avancement et leur date d’échéance,
Permettre de consulter les recettes familiales, voire en ajouter de nouvelles,
Suivre le calendrier de chacun (emploi du temps),
Gérer la liste de courses (génération automatique ?, ajout simple, etc.),
Éventuellement, la gestion d’une hypothétique domotique (si mise en place),
Une interface de commande pour choisir et lancer de la musique dans la maison,
etc.

Peu importe les éléments retenus, la tablette tactile serait une interface centrale pour tout ceci. Elle pourrait même inciter certains membres de la famille à s’impliquer davantage dans le quotidien.

Qu’imaginer concrètement sur cette tablette ?

Venant du domaine du Logiciel Libre, mon premier réflexe est naturellement d’utiliser au maximum des logiciels libres. Concrètement, ça pourrait ressembler à :

un système d’exploitation GNU/Linux (Ubuntu supporte bien les écrans tactiles, mais ce n’est pas le seul),
dans un premier temps, un environnement de bureau tout-en-un pour utiliser la tablette (peut-être GNOME ? Même si je ne suis pas spécialement fan),
un système « central » pour lancer les différentes applications composant notre gestion du foyer. Je parle d’un portail, de raccourcis sur le bureau ou n’importe quoi d’autre permettant de lancer simplement au toucher une application,
si nous utilisons des logiciels libres de type « application web », j’imagine pouvoir les héberger à la maison, soit sur la machine directement, soit sur une machine tierce (ceci est du détail),
si certains logiciels libres n’existent pas ou ne conviennent pas, éventuellement développer les applications nécessaires. Et maintenir tout ça,
et dernier point - sans doute le plus délicat - écouter les membres de la famille et ajuster selon leurs besoins.

Ce dernier point est le plus difficile pour moi. Avec des utilisateurs professionnels, j’arrive généralement à identifier les vrais besoins derrière les demandes exprimées. Avec des proches, c’est une autre paire de manches. Il y a des anicroches 😓.

Un produit minimum viable - selon moi

La plupart des personnes de mon entourage imaginent qu’il est simple de mettre en place une tablette :

Tu installes n’importe quelle distribution Linux moderne, tu lances automatiquement un navigateur web au démarrage et roulez jeunesse !

C’est sans compter mes habitudes professionnelles et mon côté méticuleux (à me lire je suis un mafieux au travail et un tortionnaire à la maison 🤣).

Ainsi j’imagine :

avoir un système permettant de déployer rapidement la tablette : même si nous n’en avons qu’une seule, si elle devient « importante », il serait intéressant de pouvoir retrouver rapidement notre travail en cas d’incident,
(facultatif) optimiser progressivement : réduire la consommation si possible, alléger les outils, améliorer l’expérience utilisateur - même si le « user-friendly » n’est pas mon point fort, soyons honnêtes,
avoir une interface unique pour tous les éléments (que ça soit des raccourcis sur un bureau, une application de gestion qui se lance automatiquement, un portail web, etc.),
avoir un clavier visuel pour taper quelques caractères si besoin,
(exprimé par la famille) permettre une mise en veille rapide de l’appareil et un rallumage rapide de ce dernier,
avoir une première application fonctionnelle pour que la famille puisse adopter la tablette rapidement.

Mis bout à bout, cela paraît gigantesque ! J’ai avancé point par point, avec ce que j’avais - et le temps disponible. Progressivement.

Conclusion

Dans les prochaines semaines, vous retrouverez des articles concernant le Projet Tablette et mes pérégrinations sur les différents sujets. J’avais commencé au début du mois avec mes difficultés à faire fonctionner l’écran tactile sur la tablette Chuwi Hi10Go avec Ubuntu 22.04. Je ne m’arrêterai donc pas en si bon chemin, croyez-moi !

J’aimerais pouvoir partager mon alternative à l’application de gestion des tâches ménagères, comment j’ai imaginé une interface d’accueil pour les applications de la maison, ou encore quelle distribution choisir pour un système d’exploitation orienté usage familial.

Je ne vais pas prétendre que tout s’est passé sans accroc. La tablette m’a refroidi en 2023, c’est un fait. Et même aujourd’hui, je sais que ce genre de projet réserve des surprises parfois désagréables.

Mais il y a quelque chose de satisfaisant à prendre un objet qu’on avait mis de côté et le remettre en vie pour un usage concret. Surtout quand cet objet tourne sous GNU/Linux, avec des logiciels libres, dans un coin de la maison.

Je ne promets pas que le résultat sera parfait. Je promets que ce sera honnête. Et si ça peut donner des idées à quelqu’un qui a une vieille tablette qui traîne - ou qui veut se lancer dans un projet similaire - tant mieux.

Liens utiles

Voici les liens de l’article par ordre d’apparition :

Problème d'écran tactile sur Chuwi Hi10Go

Tue, 12 May 2026 20:20:35 +0200

Introduction

Il y a longtemps j’étais tombé sur un article de Richard Dern sur une tablette Asus T100TA dans lequel il explique comment il y avait installé NixOS. Ce jour là je ne sais pas ce qu’il s’est passé mais une lubie s’est installée dans ma tête : et si je faisais pareil ? Et si j’avais une tablette sous GNU/Linux pour piloter la maison ? Un écran intelligent, posé quelque part, par exemple la cuisine, toujours à portée de main.

Bref, une mouche m’a piquée en mai 2023 et j’ai finalement commandé une CHUWI Hi10Go.

Ce n’était pas sans contrepartie et l’objet était « piégé ». Nous allons voir en quoi, puis nous parlerons d’accéléromètre et finalement d’écran tactile. Accrochez-vous !

Photo trouvée sur le profil Flickr de Hernán Piñera sous Licence CC BY-SA 2.0.

La tablette et le problème

La CHUWI Hi10Go est une tablette 10,1 pouces avec 6 Go de RAM, 128 Go de stockage et un processeur Celeron N5100 cadencé à 2.8 Ghz. Le tout pour 192,99€ (à l’époque, c’est à dire en mai 2023). Pour le prix, c’est une belle machine. J’étais content. J’ai installé Ubuntu 22.04, j’ai branché un clavier et là… L’écran était à l’envers.

Pas légèrement de travers. Carrément à 180°, comme si j’avais pendu la tablette par les pieds. Et quand je la tournais dans l’autre sens, le système détectait le mouvement et faisait pivoter l’image pour qu’elle reste - toujours - à l’envers. Tête en bas, invariablement.

Bah, tu désactives la rotation automatique et tu mets l’orientation fixe

Vous avez raison, c’est une solution ; mais c’est aussi passer à côté de l’intérêt principal d’une tablette tactile.

J’ai cherché des solutions en 2023. Longtemps. Forums, wikis, fils Reddit, questions Stack Overflow… sans - réel - succès. Agacé et débordé par d’autres choses, j’ai posé la tablette dans un coin. Elle a dormi là pendant deux ans.

Puis, récemment, je l’ai ressortie (sûrement une autre mouche qui m’a piquée, ça en fait des mouches décidément !), bien motivé à en finir avec ce problème. Et cette fois j’ai complété mes connaissances et trouvé une, voire plusieurs, solutions.

L’accéléromètre et sa matrice

Le coupable, c’est l’accéléromètre - le capteur qui mesure l’orientation physique de la tablette et dit au système comment afficher l’image. Il transmet ses données sous forme d’une matrice de transformation (une grille de chiffres qui encode les axes et les rotations). Si cette matrice est mal configurée pour le modèle, le système interprète systématiquement l’orientation à l’envers. C’est exactement ce qui se passe sur la CHUWI Hi10Go sous Linux. Sûrement que sous Windows le pilote installé par défaut corrigeait le problème. Mais pas sous Linux.

Sous Ubuntu, on corrige ça via une règle udev (le gestionnaire de périphériques Linux) dans l’hardware database, par exemple dans le fichier /etc/udev/hwdb.d/61-sensor.hwdb avec le contenu suivant pour inverser la matrice de l’accéléromètre :

# Chuwi Hi10 Go
sensor:modalias:acpi:MXC6655*:dmi:*:svnCHUWIINNOVATIONLIMITED:pnHi10Go:*
 ACCEL_MOUNT_MATRIX=-1, 0, 0; 0,-1, 0; 0, 0, 1

J’ai trouvé cette règle sur le dépôt Github de systemd. Curieux que je n’étais pas tombé dessus auparavant, surtout que cela date de 2021 !

Puis on recharge la base de données matérielle :

sudo systemd-hwdb update
sudo udevadm trigger -v -p DEVNAME=/dev/iio:device0

Après un redémarrage, l’écran s’affiche enfin dans le bon sens. Quel soulagement. Et ceci chaque fois que je tourne physiquement la tablette de 90° en 90°.

Second problème caché : l’écran tactile

Parce qu’on ne doit pas crier victoire trop vite, je me suis rendu compte d’un autre souci. L’écran était dans le bon sens, mais le touchscreen (l’écran tactile, un composant Goodix Capacitive TouchScreen) ne répondait pas correctement. Les coordonnées de toucher étaient elles aussi inversées : si j’appuie en haut à gauche, le curseur apparaît en bas à droite. “Farpait” 🤣.

La correction passe également par une règle udev sur la variable LIBINPUT_CALIBRATION_MATRIX. Cette variable permet de recalibrer les coordonnées du tactile indépendamment du reste.

On crée un fichier, par exemple /etc/udev/rules.d/98-goodix-touchscreen-calibration.rules avec le contenu suivant :

ACTION=="add|change", KERNEL=="event*", ATTRS{name}=="Goodix Capacitive TouchScreen", ENV{LIBINPUT_CALIBRATION_MATRIX}="-1 0 1 0 -1 1"

Puis on recharge les règles :

sudo udevadm control --reload-rules
sudo udevadm trigger --subsystem-match=input

On vérifie que la règle est bien prise en compte :

sudo udevadm info /dev/input/event15 | grep LIBINPUT_CALIBRATION

Et la sortie attendue :

E: LIBINPUT_CALIBRATION_MATRIX=-1 0 1 0 -1 1

On peut désormais tester avec le doigt sur l’écran. Miracle, le tactile répond enfin correctement 😄.

Conclusion

Après ces deux corrections la tablette est enfin utilisable. Je suis content de mon achat - même avec deux ans de retard sur le planning initial. J’ai bon espoir qu’elle devienne ce que j’avais imaginé dès le départ : une interface centrale pour piloter la maison.

Mais cette expérience m’a rappelé quelque chose : on parle trop peu du tactile sous GNU/Linux. Les articles sur le sujet sont rares, souvent anciens, rarement complets. C’est dommage, parce qu’il y a clairement une demande et des solutions existent, comme on vient de le voir.

Côté GNOME (interface graphique par défaut sur Ubuntu) : je n’ai jamais été fan car trop différent de mes habitudes, trop lourd à mon goût. Mais force est de constater qu’avec Ubuntu, l’environnement a bien évolué. Le tactile y est géré de façon cohérente - clavier virtuel, gestes, rotation. C’est un vrai effort visible et ça change la donne pour des machines comme les tablettes.

Pour 192,99€, on ne pouvait pas rêver mieux. À condition de passer une heure à corriger ce que les fabricants n’ont pas pris la peine de configurer pour Linux. Ce qui, dans notre écosystème, est finalement presque devenu une tradition.

Liens utiles

Voici les liens de l’article par ordre d’apparition :

Publier son blog Hugo sur Gitlab Pages

Tue, 28 Apr 2026 18:18:10 +0200

Introduction

Il y a plus d’un an je travaillais en équipe dans le cadre du passage d’un titre professionnel d’Administrateur Système DevOps. Pour étayer nos travaux nous avions choisi, entre autre, de publier un site à l’aide du très célèbre moteur de blog statique Hugo. Nous utilisions la plateforme Gitlab CI dont je vous parlais déjà pour automatiser le déploiement du site sur Gitlab Pages. C’est une plateforme pour publier gratuitement ses sites webs statiques.

Aujourd’hui nous allons voir comment publier son blog/site fabriqué avec Hugo sur Gitlab Pages, ce qui ressemblera beaucoup au tutoriel officiel de Gitlab pour construire et déployer un site Hugo. Le présent tutoriel s’appuie sur l’article précédent concernant les premiers pas avec Hugo, moteur de blog statique, je vous invite à en prendre connaissance - excepté si vous savez déjà utiliser Hugo.

Dans un premier temps nous listerons les pré-requis à l’usage de ce tutoriel, puis nous aborderons le nommage du dépôt Gitlab lors de sa création. Après quoi nous agrémenterons ce dernier avec un site Hugo (avec une configuration minime). Et nous attaquerons l’automatisation de la compilation du site sur Gitlab CI pour finalement terminer sur la publication du blog/site.

Photo trouvée sur Wikimedia Commons concernant le Tanuki du Japon sous Licence CC BY-SA 4.0.

Pré-requis

savoir utiliser Git,
avoir un compte Gitlab et avoir déposé une clé SSH sur son profil Gitlab pour y accéder,
installer Hugo sur sa machine et savoir l’utiliser (cas échéant je vous invite à lire mon article nommé « Premiers pas avec Hugo, moteur de blog statique »).

Ce « tutoriel » peut sembler long la première fois, mais il vaut la peine d’être accompli jusqu’au bout. Les fois d’après sont plus rapides, plus faciles et ne durent que quelques minutes seulement ! Je l’ai déjà fait en moins de 10 minutes - si je devais être une référence 🤣.

Création du dépôt et règles de nommage

Dans le principe, c’est très simple :

vous créez un nouveau dépôt à l’aide de « Nouveau projet/dépôt » puis « Créer un projet vide »,
vous renseignez les champs demandés, par exemple pour l’URL de projet on choisit son pseudo dans le menu déroulant,
puis il s’agit de donner un nom spécifique au dépôt et un slug correspondant.

Parlons du nom du dépôt (et du champ « identifiant slug » hérité de ce nom).

Imaginons que vous ayez comme pseudo blankoworld, pour ne viser personne 🤣 . À défaut dans Gitlab Pages votre accès est : blankoworld.gitlab.io. Essayez : il n’y a rien pour l’instant à cette URL.

Pour faciliter les choses et bénéfier d’une adresse URL permettant d’accéder à votre blog/site statique, je vous suggère fortement de créer un dépôt nommé blankoworld.gitlab.io (oui oui, avec le domaine dans le titre du dépôt). C’est la méthode la plus simple. Bien évidemment, changez blankoworld par votre pseudo choisi sur Gitlab.

Si au contraire vous créez un dépôt nommé veille par exemple, il sera finalement disponible à l’adresse blankoworld.gitlab.io/veille. C’est ce qui permet de bénéficier de plusieurs blog/sites statiques sans être limité par Gitlab.

Il est aussi possible d’utiliser un groupe Gitlab, en ce cas cela fonctionne avec le nom du groupe, par exemple odtre.gitlab.io pour le groupe nommé odtre.

Et si vous êtes intéressés par l’usage d’un nom de domaine en lieu et place de celui fourni par Gitlab pour votre blog/site statique généré ; je vous invite à lire la documentation Gitlab au sujet des noms de domaines personnalisés.

Autre point important : le niveau de visibilité de votre dépôt Git. Si le dépôt est public, ça facilitera possiblement les actions pour afficher le site final au reste du monde. Nous verrons cela en détail plus tard.

Laissez « Initialiser le dépôt avec un README » coché, comme ça nous aurons déjà un dépôt Git prêt à être récupéré.

Récupération initiale du dépôt et préparation

En bref, ça pourrait faire quelque chose comme les lignes suivantes dans une invite de commande :

PSEUDO_GITLAB=VOTRE_PSEUDO # par exemple blankoworld
DEPOT=VOTRE_DEPOT          # par exemple blankoworld.gitlab.io
git clone git@gitlab.com:${PSEUDO_GITLAB}/${DEPOT}
cd "${DEPOT}"
hugo new site . --force    # le point définit le dossier courant
git submodule add https://github.com/zhaohuabing/hugo-theme-cleanwhite themes/cleanwhite
echo "theme = 'cleanwhite'" >> hugo.toml
echo "public/" >> .gitignore
sed -i "s#baseURL = \(.*\)#baseURL = 'https://${DEPOT}/'#" hugo.toml
git add . # on ajoute les fichiers au prochain commit git
git commit -m "chore: Hugo initialized" # création du prochain commit
git push

Procédons étape par étape avec des explications.

On va récupérer notre dépôt Gitlab à l’aide de la commande suivante :

git clone git@gitlab.com:blankoworld/blankoworld.gitlab.io

blankoworld (le premier qui apparaît) est notre pseudo sur Gitlab, mais ça peut aussi être le “groupe” Gitlab sur lequel nous avons créé le dépôt (rappelez-vous le menu déroulant qui demandait l’URL du projet),
blankoworld.gitlab.io est le mot clé que je vous avais demandé de fabriquer en fonction de votre pseudo/groupe pour faciliter l’accès. Je dis mot-clé car il sera repéré par Gitlab pour mettre à disposition le site contenu dans le dépôt directement à la racine de l’adresse URL blankoworld.gitlab.io.

Ensuite on se rend dans ce répertoire pour préparer un site Hugo. D’après mon tutoriel sur la fabrication initiale d’un site Hugo, en choisissant le thème CleanWhite pour Hugo, cela ressemblerait à quelque chose comme :

cd blankoworld.gitlab.io  # pour se rendre dans le répertoire qu'on vient de récupérer avec Git
hugo new site . --force   # `--force` prend en compte les fichiers existant du dépôt Git
git submodule add https://github.com/zhaohuabing/hugo-theme-cleanwhite themes/cleanwhite
echo "theme = 'cleanwhite'" >> hugo.toml

Pour éviter d’augmenter la taille du dépôt Gitlab distant, on va ignorer - seulement sous Git - les fichiers contenus dans le répertoire public/. Ce qui revient à le rajouter dans le fichier .gitignore comme ceci :

echo "public/" >> .gitignore

Nous devons également adapter l’URL du site dans la configuration afin qu’il corresponde à l’URL fournie par Gitlab Pages pour servir votre - futur - site statique. Dans le cas où vous auriez suivi mes conseils et utilisé quelque chose comme mon_pseudo.gitlab.io, alors l’URL sera https://mon_pseudo.gitlab.io/. Dans mon cas c’est https://blankoworld.gitlab.io/ .

Éditons le fichier hugo.toml pour adapter l’URL du site comme il se doit :

baseURL = 'https://blankoworld.gitlab.io/'
locale = 'en-us'
title = 'My New Hugo Project'
theme = 'cleanwhite'

Il ne reste plus qu’à enregistrer les changements dans le dépôt Git et l’envoyer sur Gitlab :

git add .                               # on ajoute les fichiers au prochain commit git
git commit -m "chore: Hugo initialized" # création du prochain commit
git push                                # on pousse le résultat sur Gitlab

À ce stade, nous avons un site Hugo - très sommaire - avec un thème et l’URL de Gitlab enregistrée dans la configuration. Ce sont les seuls besoins vitaux pour compiler et publier le site. Rédiger un article est une étape qui peut attendre.

Voyons désormais comment permettre la publication de notre travail.

Automatisation avec compilation d’Hugo

La documentation de Gitlab sur l’intégration continue parle d’un fichier .gitlab-ci.yml à fournir à la base du répertoire principal.

Ce fichier .gitlab-ci.yml - oui, oui, avec un point devant le nom du fichier - va décrire les actions à effectuer pour construire, ou plutôt compiler, votre site Hugo et le publier sur Gitlab Pages.

Créons donc le fichier .gitlab-ci.yml à la base de notre répertoire principal - dans mon cas dans le dossier blankoworld.gitlab.io - avec le contenu suivant :

 1default:
 2  image: "hugomods/hugo:exts"
 3
 4variables:
 5  GIT_SUBMODULE_STRATEGY: recursive
 6  HUGO_ENV: production
 7
 8create-pages:
 9  script:
10    - hugo
11  pages: true
12  artifacts:
13    paths:
14      - public
15  rules:
16    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

C’est une version allégée de celle trouvée sur la documentation Gitlab à propos de la publication d’un site Hugo en utilisant Gitlab CI.

Inutile d’être un as de l’écriture de fichiers .gitlab-ci.yml pour en comprendre le détail :

Les lignes 1 à 2 renseignent l’image Docker à utiliser pour compiler votre site. Ici nous utilisons les excellentes images Docker fournies par Hugomods. Attention cependant à trouver une image qui contient aussi l’outil Git pour récupérer le thème du site,
ligne 4 à 6, nous avons respectivement une variable GIT_SUBMODULE_STRATEGY pour définir la statégie de récupération Git (utile pour récupérer notre thème) et HUGO_ENV pour définir l’environnement cible pour la compilation Hugo,
ligne 8 à 17 sont les lignes où tout va se jouer. C’est là qu’on décrit la commande à lancer - ici c’est juste hugo. Le fait qu’on souhaite utiliser Gitlab Pages et qu’on va utiliser le contenu résultant du dossier public pour l’envoyer sur Gitlab Pages.
ligne 15 et 16 définissent dans quel cas exécuter cette étape nommée create-pages. En l’occurrence cela ne sera que si la branche attachée au commit est la branche par défaut dans Gitlab. Si vous m’avez suivi dès le départ, nous n’avons qu’une seule branche dans Gitlab nommée master.

Une fois le fichier dûment complété, n’oubliez pas de l’ajouter au dépôt Git et de pousser le tout sur Gitlab :

git add .gitlab-ci.yml
git commit -m "feat(CI): Add .gitlab-ci.yml file to compile Hugo"
git push

Vous devriez retrouver rapidement les détails de la compilation dans le menu Gitlab (à gauche) nommé “Compilation > Pipelines”. Les pipelines de Gitlab CI représentent une suite automatisée d’étapes justement fournies dans le fichier .gitlab-ci.yml. Donc chaque fois que vous ferez un commit sur votre dépôt et que vous poussez le résultat sur Gitlab, une pipeline s’exécutera si et seulement si le fichier .gitlab-ci.yml est présent dans votre dépôt (et qu’il soit bien bien formé comme Gitlab CI l’attend).

Mais ne crions pas victoire trop tôt, nous avons encore quelques détails à régler.

Publication de son blog

Bien entendu, suite à notre dernier commit Git, une pipeline s’est exécutée. Elle est sûrement arrivée au bout de son exécution et le site est envoyé vers Gitlab Pages.

Cependant même en ayant l’URL il se pourrait que vos visiteurs n’accèdent pas au site : nous devons vérifier la « visibilité du site ». Et où cela se trouve ? Dans les paramètres de votre dépôt.

Sur Gitlab, une fois sur votre dépôt :

allez dans le menu latéral gauche et choisissez cette fois “Paramètres > Général”,
puis cliquez sur le titre “Visibilité, fonctionnalités du projet, autorisations”. Vous devriez avoir une loooooongue liste de boutons à cocher/décocher,
parmi eux, sous un titre “Pages”, doit se trouver un bouton activé. Et un menu déroulant pour choisir qui peut voir le site,
si vous souhaitez que tout le monde puisse accéder au site, choisissez “Toute personne ayant accès”,
ET n’oubliez pas d’aller plus bas de la page pour cliquer sur le bouton “Enregistrer les modifications”. Cas échéant vos modifications n’auront aucun effet.

Le menu “Paramètres > Général” en image :

et son petit copain l’encart “Pages” également en image :

C’est tout bon ! Vous devriez avoir un site accessible sur mon_depot.gitlab.io, dans mon cas c’est blankoworld.gitlab.io. Allez vérifier tout de même 😉.

Conclusion

À travers quelques étapes comme la création du dépôt, celle du site Hugo, la configuration de ce dernier, l’ajout d’un fichier .gitlab-ci.yml et finalement une configuration Gitlab, nous avons vu que quelques minutes suffisent à démarrer un nouveau blog/site statique, ce qui est très pratique !

Loin d’être un modèle de beauté, nous avons pourtant un site prêt à l’usage sur Gitlab Pages, à l’adresse blankoworld.gitlab.io. Chaque nouvelle modification enregistrée par Git (via un commit) puis poussée sur Gitlab génèrera une pipeline Gitlab CI qui publiera le site Hugo sur l’adresse fournie ci-avant.

Si d’aventures vous voudriez voir ce qui a été fait, je vous invite à lire le dépôt Gitlab utilisé pour ce tutoriel sur la publication d’un site Hugo sur Gitlab Pages.

Vous pourriez aller plus loin en ajoutant un domaine personnalisé sur votre dépôt Gitlab en lisant la documentation Gitlab. Vous allez devoir cependant apprendre comment avoir un nom de domaine et comment en modifier ce qu’on appelle la zone DNS. Mais ceci est une autre histoire que nous n’aborderons pas aujourd’hui.

Amusez-vous bien et n’hésitez pas à tester votre site Hugo en local avant de pousser le résultat sur le dépôt Gitlab 😉 .

Liens utiles

Voici les liens de l’article par ordre d’apparition :

Premiers pas avec Hugo, moteur de blog statique

Tue, 07 Apr 2026 17:19:03 +0200

Introduction

Hugo est un moteur de blog statique célèbre pour sa rapidité et sa souplesse d’utilisation. Il permet de générer un site web contenant des milliers d’articles en quelques secondes.

Qu’entends-tu par générer un site web ?

Dire que c’est un moteur de site statique signifie que l’outil va prendre un répertoire d’origine comme base pour compulser les données et générer des pages webs comme par exemple des pages HTML, CSS, XML ou encore du JS (mais d’autres formats sont possibles).

Quel(s) avantage(s) à ce qu’il soit statique ? Une fois vos fichiers générés dans un dossier cible (par exemple un dossier nommé « public »), vous pouvez le déposer chez n’importe quel hébergeur web.

Imaginez votre blog, votre site vitrine ou un site professionnel : aucune dépendance, pas de faille de sécurité liée au langage ou au framework choisi pour publier le site, pas de surcoût de serveur pour des environnements particuliers, pas de lenteurs sur votre site pour calculer tous les éléments avant de les servir à chaque visiteur, etc.

En somme fournir un site web statique est très pratique, économique et facile. D’autant qu’il existe des hébergeurs gratuits pour fournir vos fichiers HTML, CSS, XML, JS. Pourquoi ne pas en profiter ?

En 2016, j’ai fait le choix de migrer mon blog sur Hugo, j’ai donc un peu de bouteille dans son utilisation. J’ai d’ailleurs proposé un thème nommé Adam & Eve pour Hugo que j’utilise pour l’espace Recueil de ce blog.

Aujourd’hui nous allons faire nos premiers pas dans la création d’un blog statique à l’aide d’Hugo. Nous parlerons de l’installation de l’outil, puis de la création du squelette principal, le choix d’un thème, la configuration du blog et la rédaction d’un article avant de générer notre premier blog Hugo 😎.

Photo trouvée sur le profil de Stephen Bowler sur Flickr sous licence CC BY 2.0.

Installation

Étant donné qu’Hugo est un outil qui s’utilise en ligne de commande, il faut installer le binaire sur notre machine. En fonction de votre système d’exploitation la méthode diffère.

La documentation officielle sur l’installation d’Hugo est bien faite. Je vous invite à la consulter promptement.

Si vous avez une distribution GNU/Linux, il existe sûrement un paquet spécifique d’Hugo pour votre distribution.

Par exemple sous ArchLinux il me suffit de faire :

sudo pacman -S hugo

Et le tour est joué !

Une fois installée, vous pouvez taper la commande suivante dans une console pour vérifier que tout soit en ordre :

hugo version

Cela affiche la version d’Hugo que vous venez d’installer.

Plusieurs méthodes permettent d’avoir des infos sur la commande hugo :

man hugo
hugo help

Ou tout simplement se rendre sur la documentation officielle d’Hugo.

Créer un nouveau site

Pour générer un nouveau site nommé superblog :

hugo new site superblog

Hugo lui-même vous informe des étapes à suivre pour terminer votre projet de site, parmi :

se rendre dans le nouveau répertoire,
choisir et ajouter un thème,
configurer le site à l’aide du fichier hugo.toml,
créer du contenu,
vérifier le résultat avec un serveur local dédié (rien que ça !).

Agissons de suite : rendez-vous dans le répertoire superblog et passons au chapitre suivant.

cd superblog

Choisir un thème

L’avantage d’avoir un outil très connu c’est de bénéficier d’innombrables thèmes proposés par la communauté. Vous les retrouverez sur un site officiel dédié aux thèmes prévus pour Hugo.

Étant donné que le travail est fourni par la communauté, leur qualité ou la couverture de fonctionnalités intégrées est dépendante du temps passé sur ces thèmes et le temps accordé à leur maintenance. Autrement dit : il y a à boire et à manger là dedans !

Parcourez l’annuaire de thèmes Hugo, choisissez un thème, par exemple le thème Clean White pour Hugo et cliquez de droit sur le bouton « Download » pour copier l’adresse où se trouve le thème.

Pour l’installer il suffira de taper la commande suivante dans le répertoire superblog (exemple avec le thème Clean White) :

# Nécessite d'avoir la commande `git` installée sur sa machine
git init && git submodule add https://github.com/zhaohuabing/hugo-theme-cleanwhite themes/cleanwhite

On enregistre ensuite le thème dans la configuration de ce site - dont nous parlerons dans le chapitre suivant :

echo "theme = 'cleanwhite'" >> hugo.toml

Si vous êtes curieux du résultat, vous pouvez directement lancer la commande suivante :

hugo serve -D

qui aura pour effet de lancer un serveur web en arrière plan et de vous fournir une adresse URL où consulter votre nouveau site. Par exemple sur http://localhost:1313/. Pour arrêter le serveur, pressez simultanément les touches [Ctrl]+[c].

Regardons de plus près la configuration du site.

Configuration du site, le fichier hugo.toml

La configuration principale de votre site se trouve dans le fichier hugo.toml (anciennement config.toml). La documentation officielle sur le fichier hugo.toml vous donnera une idée de l’ampleur des possibilités qu’offre la configuration d’un site Hugo.

Cantonnons-nous ici de quelques éléments seulement. Le contenu actuel du fichier hugo.toml est :

baseURL = 'https://example.org/'
locale = 'en-us'
title = 'My New Hugo Project'
theme = 'cleanwhite'

Les éléments sont plutôt parlants :

baseURL : va définir l’adresse URL finale de votre site (par exemple pour mon blog ça sera https://olivier.dossmann.net/),
locale : définit le langage du site au regard de la RFC5646,
title : est le titre affiché sur le site,
et theme est l’adresse vers les fichiers du thème utilisé pour notre site.

Modifions le fichier hugo.toml pour ressembler à ceci :

baseURL = 'https://example.org/'
locale = 'fr'
title = 'Mon Super Blog'
theme = 'cleanwhite'
enableEmoji = true

On relance le serveur local intégré à Hugo pour voir le résultat :

# Faites Ctrl + c pour arrêter le serveur
hugo serve -D

On a rajouté une ligne enableEmoji pour activer l’utilisation des emojis dans les articles. Cf. la page de la documentation officielle consacrée à la liste des émojis disponibles sous Hugo.

Mon premier article

Commençons par créer ledit article :

# Très souvent les thèmes proposés n'utilisent que les articles situés dans le dossier "post"
hugo new content -k post post/mon_premier_post.md

L’extension .md est ici nécessaire. L’option -k va suggérer d’utiliser un template post.md s’il existe. C’est ce qu’on appelle un archétype : un fichier au format Markdown situé dans le dossier themes/monTheme/archetypes/ (par exemple themes/cleanwhite/archetypes/post.md) qui sera copié en lieu et place de l’article demandé ; ici dans post/mon_premier_post.md. Les fichiers sont toujours placés dans le dossier content.

Le fichier est placé dans le dossier content/post/mon_premier_post.md dont voici le contenu :

---
title:       "An Example Post"
subtitle:    ""
description: ""
date:        2018-06-04
author:      ""
image:       ""
tags:        ["tag1", "tag2"]
categories:  ["Tech" ]
---

Les articles auront toujours la même forme :

Une entête délimitée par une chaîne de caractère de début et de fin (ici --- en début et fin),
Le contenu de l’article, écrit au format Markdown (par défaut).

Dans le cas présent, nous n’avons aucun contenu.

L’article propose seulement une entête contenant des informations qui seront utilisées comme méta-données de l’article (par exemple son titre, une description, un sous-titre, l’auteur de l’article, éventuellement une image, des balises (tags) et des catégories). L’exemple utilise les tags nommés tag1 et tag2 ; et une catégorie Tech.

Notez également la date fournie : on peut déterminer la date de publication d’un article. Si c’est une date dans le futur, alors l’article ne sera pas publié - ce qui est très pratique !

Pour empêcher également qu’un article soit publié, on peut rajouter une information comme :

draft: true

Ce qui aura pour effet, excepté si l’option -D est ajoutée, de ne pas rendre disponible cet article - très pratique aussi !

Ajoutez quelques lignes à la fin du fichier (après les méta-données et la chaîne de caractère ---) pour regarder le résultat :

# Titre 1

Quelques lignes avec du texte en **gras**, ou *italique*, c'est comme vous voulez.

# Titre 2

## Sous-titre

Avec un lien vers [mon blog](https://olivier.dossmann.net/).

On vérifie à l’aide de la commande hugo serve -D.

Compilation du site

Maintenant que nous avons un site, un thème configuré dans le fichier hugo.toml et un article, voyons l’étape de compilation.

La compilation, avec Hugo, c’est le fait de prendre l’ensemble des fichiers et informations du site et de les transformer en un dossier complet qui fournit les pages Web - et tout autre fichier nécessaire à l’élaboration du site. Hugo stocke le résultat dans un dossier nommé public.

Pour lancer la compilation complète, on peut, à la racine du site, taper la commande suivante :

hugo

Cette commande seule suffit à compiler l’ensemble du site et le rendre disponible dans le dossier public. C’est le contenu de ce dernier que vous devez déposer dans l’espace fourni par votre hébergeur de site web.

On peut agrémenter la commande de plusieurs options, par exemple :

hugo -D --minify

L’option -D va aussi compiler les articles dits « brouillons » (ayant draft: true dans la section des méta-données).

L’option –minify va réduire la taille des fichiers en enlevant le plus possible les espaces, retour à la ligne et assimilés.

Il y a énormément d’options et là encore la documentation officielle d’Hugo sur la commande hugo permet d’en savoir plus.

Conclusion

À travers quelques étapes simples, nous avons vu comment installer la commande hugo, créer un nouveau site, ajouter un thème, configurer le site, rédiger un article et compiler l’ensemble pour générer les fichiers suffisants pour créer un nouveau site web statique.

Hugo est un moteur de site statique très riche et bourré de fonctionnalités en tous genres comme la gestion de contenu multilingue, l’usage de « bouts de code » réemployables, le redimensionnement des images, les commentaires, la génération d’un ou plusieurs flux RSS, la personnalisation des thèmes, une page 404 personnalisée, l’usage de coloration syntaxique pour les balises HTML code, le serveur web embarqué, une commande de déploiement et bien plus encore…

C’est mon outil favori depuis 2016. Je prévois cette année encore de concocter un article supplémentaire à son sujet qui dépendra du présent article qui, je l’espère, vous plaira.

Qui sait, peut-être vous lancerez-vous, vous aussi, dans la création et la publication d’un blog - et cela gratuitement 😉.

Liens utiles

Voici les liens de l’article par ordre d’apparition :

Encore un autre lecteur de flux RSS, Yarr

Sun, 22 Mar 2026 11:42:00 +0100

Introduction

Il y a fort fort longtemps (en 2009), je testais TinyTinyRSS, un lecteur de flux RSS avec une interface Web. J’en parlais d’ailleurs dans un article pour signaler la venue de deux nouveaux tutoriels (dont TinyTinyRSS) dans mon Recueil d’astuces. Ce lecteur était agréable à l’usage, rapide et utilisait une base de données postgreSQL. Bref, tout ce que je voulais à l’époque. Le temps a passé ; je dépensais moins de temps sur les flux RSS. Puis j’ai arrêté - qu’importe les raisons. Ça fait bientôt 10 ans que j’ai laissé cela derrière moi.

Bouh la honte Olivier !

Certes.

Récemment, une mouche m’a piquée - ou une lubie - et je me suis renseigné sur les outils de lecture de flux RSS façon auto-hébergés et minimalistes. Je ne vais pas détailler la liste dans cet article puisque, vous l’aurez compris, on parle déjà dans le titre de Yarr !

Ainsi nous commencerons par présenter l’outil, pour ensuite décrire comment l’utiliser avec docker-compose pour finalement terminer par mon retour d’expérience après quelques jours d’utilisation (démarrage au 25 février 2026) et via un tour complet de l’outil - ça va être long mais il y a des images 😉 .

Photo trouvée sur le profil de Kevin Dooley sur Flickr sous licence CC BY 2.0.

Découverte de Yarr

Avant de découvrir : on cherche ! J’ai donc établi une petite liste de critères pour la recherche d’un lecteur de flux RSS :

simple, voire basique,
avec une interface Web,
auto-hébergeable,
Open Source,
rapide,
léger,
sans forcément une base de données de type MySQL ou PostgreSQL. SQLite acceptable,
écrit, éventuellement, en Go (j’envisage d’apprendre prochainement le Go).

J’ai donc cherché. J’ai trouvé quelques outils comme :

Miniflux (en Go),
FreshRSS (en PHP),
LeedRSS (en PHP),
feedpushr (en Go),
et Yarr (en Go).

Je l’ai déjà annoncé : nous n’irons pas plus loin avec cette liste.

Nul besoin de faire la promotion de Yarr, je pense qu’Internet fait déjà de belles suggestions d’utilisation de Yarr comme remplaçant de TinyTinyRSS. Petite histoire marrante : le nom est l’acronyme de Yet Another Rss Reader, littéralement « Encore un autre lecteur RSS » ou « L’énième lecteur de flux RSS ».

Une fois cette lecture de blog effectuée, j’ai voulu tester Yarr. Je me suis donc lancé dans l’écriture d’un fichier docker-compose.yml.

Mon fichier docker-compose.yaml pour Yarr

Il aura fallu moins de 20 minutes pour trouver l’image Docker de Yarr sur le dépôt officiel de Yarr sur Github. Cependant l’image étant sur Github Actions - que je connais peu - j’ai eu plus de mal à trouver le nom donné à l’image pour la récupérer depuis Docker. Je vous le donne de suite : ghcr.io/nkanaev/yarr:v2.5.

Une fois le nom de l’image obtenu, il reste à en connaître son usage. Heureusement j’ai trouvé un article sur la création d’un fichier docker-compose.yaml pour Yarr (Cf. https://awesome-docker-compose.com/apps/rss/yarr) dont je me suis, forcément, grandement inspiré. Et oui je le dis quand j’utilise quelque chose qui n’est pas de moi 😉 .

Ainsi j’ai pu construire le fichier docker-compose.yaml suivant :

services:
  yarr:
    image: ghcr.io/nkanaev/yarr:v2.5
    container_name: yarr
    restart: always
    ports:
      - 7070
    volumes:
      - ${DATA_DIR:-./data}:/data
    command:
      - --addr=0.0.0.0:7070
      - --db=/data/yarr.db
      - --auth=${Y_USER}:${PASSWORD}
    environment:
      - TZ=Europe/Paris
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.${SERVICE}.rule=Host(`$DOMAIN_URL`)"
      - "traefik.http.routers.${SERVICE}.entrypoints=websecure"

où :

DATA_DIR, Y_USER, PASSWORD, SERVICE et DOMAIN_URL sont à renseigner dans un fichier .env (avec une valeur),
DATA_DIR est le chemin vers le point de montage où seront stockées les données de Yarr,
Y_USER est le nom d’utilisateur que vous souhaitez utiliser comme login pour s’identifier sur votre Yarr,
PASSWORD… bah le mot de passe pour s’identifier au service Yarr,
SERVICE est un nom (en minuscule, sans espace et sans point) pour le routeur dans Træfik (si vous n’utilisez pas Træfik, supprimez la section “labels” de ce docker-compose.yaml),
DOMAIN_URL est l’adresse web pour accéder au service, mais seulement si vous utilisez Træfik en frontal. Sinon supprimez la section “labels” de ce fichier docker-compose.yaml.

Exemple de fichier .env :

SERVICE=monService
DOMAIN_URL=domain.tld
DATA_DIR=/srv/http/yarr_data
Y_USER=olivier
PASSWORD=mot2passe

Vous noterez qu’on autorise volontairement toutes les IP pour accéder au service (0.0.0.0). Ce dernier s’ouvrira sur le port 7070 dans le conteneur, mais Docker choisira un port aléatoire sur ce service (pour éviter de demander un port déjà utilisé). Nous en parlerons ci-après avec la commande docker compose port.

Une fois le fichier .env configuré, on lance et accède rapidement au service (pour tester par exemple) :

# Lance le service en arrière plan - récupération de la main sur l'invite de commande
docker compose up -d
# Affiche les conteneurs lancés
docker compose ps
# Affiche l'adresse pour accéder au service en local
docker compose port yarr 7070

On lance un navigateur, on tape l’adresse retournée par la dernière commande (chez moi 0.0.0.0:32768) et le lecteur de flux RSS apparaît. C’est parti pour une période d’essai de plusieurs jours (tests commencés à partir du 25 février 2026).

Mon expérience avec Yarr - on fait le tour !

L’authentification

Dans le fichier docker-compose.yml précédent nous avons ajouté l’option --auth afin d’activer l’authentification de Yarr. La première page sur laquelle nous tombons est donc celle pour s’identifier :

Simple, efficace.

L’interface générale

L’accueil est plutôt austère - chouette c’est ce que je voulais ! - et propose une disposition en 3 colonnes :

Chaque colonne sert un objectif précis, de gauche à droite :

la liste des flux RSS,
puis la liste des articles/éléments d’un flux en particulier,
puis l’article choisi parmi la liste précédente.

Donc plus on se dirige à droite, plus la lecture se précise.

Sur téléphone mobile il n’y aura plus qu’une seule colonne : celle tout à gauche. On choisira ainsi un flux, ce qui affichera la liste des articles et si on choisit un article, on verra son contenu. Toujours sur une colonne. Astucieux, logique et presque intuitif.

J’avoue que sur ce dernier point, sur téléphone mobile, j’ai été totalement perdu : je ne savais pas où j’étais et ce que je faisais. Ce n’est qu’en comparant l’usage entre un grand écran et un petit écran que j’ai saisi ce qu’il en était. Sur ce coup-là, je suis le couteau le moins aiguisé du tiroir…

La configuration de l’interface

Je continue ma découverte avec l’icône représentant 3 petits points en haut à droite de la première colonne (ou en haut à droite sur un petit écran ne présentant donc qu’une seule colonne). Les options de l’outil apparaissent :

C’est ici que va se jouer les seules options disponibles dans Yarr :

New Feed : Permet d’ajouter un nouveau flux. Il faut 2 infos : l’adresse URL du flux, et le dossier dans lequel le ranger,
Refresh Feeds : Actualisation des flux,
Theme : Pour changer l’apparence de Yarr. Nous en parlerons tout à l’heure,
Auto Refresh : Permet de choisir le laps de temps entre plusieurs rafraîchissements automatiques. Comprendre : on récupère les flux tous les X temps (de 0mn à 4h),
Show first : Permet de choisir si on préfère afficher les articles parus récemment en premier (New) ou ceux les plus anciens en premier (Old),
Subscriptions :
- Import : Donne la possibilité d’importer une liste de flux (au format OPML),
- Export : Permet d’exporter sa liste de flux (au format OPML) pour la partager par exemple,
- Shortcuts : Affiche un rappel des raccourcis claviers possibles pour naviguer et lire les flux. Et ils sont très utiles,
- Log out : Apparaîtra seulement si l’option --auth a été utilisée. C’est pour se déconnecter.

J’avais peur de tomber sur un lecteur avec des milliers de configurations. Finalement Yarr va à l’essentiel. Cela me plaît - encore une fois.

Choix d’un thème

Vous aurez remarqué que mes impressions écrans présentent les pages d’une couleur simili jaune (qui fait penser à Solarized Light d’Ethan Shoonover). C’est parce que j’ai choisi un thème. On peut choisir entre 3 thèmes :

blanc,
jaune,
noir.

Je suis content du thème jaune car ma vue pose problème avec les thèmes noirs (l’astigmathie a une forme d’opposition rebelle au “dark theme” et peut rendre les textes “flous”). Certes, la performance de lecture est plus importante en mode “light”, mais ça reste trop lumineux pour moi. Je n’aime pas le jaune en tant que tel, mais pour mon efficacité de lecture c’est le “moins pire” 🤣 . Évidemment les tendances s’inversent la nuit (mais pas pour moi), dans la pénombre et/ou dans un environnement peu lumineux. Mais nous ne sommes pas ici pour lancer le troll « Dark Mode vs. Light Mode », ou bien ? Combat !

Les trois icônes principales

Vous avez découvert l’usage en 3 colonnes, cette fois nous allons découvrir l’usage des 3 icônes tout en haut qui sont, en quelque sorte, le menu principal de Yarr :

un rond rempli de noir,
une étoile,
3 traits horizontaux parallèles de longueurs différentes.

La première (le rond noir) permet d’afficher la liste des flux sur lesquels nous avons encore des articles/éléments à lire.

La seconde (étoile noire) affiche une liste des flux sur lequels vous avez marqués des articles/éléments comme favoris.

Et la dernière (les 3 traits horizontaux) affiche la liste complète des flux, qu’importe qu’il vous reste ou non des articles/éléments à lire.

Exemple d’affichage en 3 colonnes sur le rond noir avec le choix d’un article et son affichage :

Simple, basique, sans fioritures. Utilisable avec des raccourcis clavier. Parfait !

Les derniers petits détails - et après j’arrête promis !

Dernière liste d’icônes dans l’interface :

deuxième colonne :
- icône de loupe : Fait une recherche dans la liste d’article de CE flux choisi,
- icône de validation : Marque tous les articles de ce flux comme lus,
- icône de 3 petits points l’un à côté de l’autre verticalement : c’est ici qu’on a les détails du flux. On peut le renommer, le changer de place, le supprimer, aller sur le site Web, etc.,
troisième colonne :
- icône d’étoile (vide/remplie) : Marque l’article en favori ou au contraire l’enlève des favoris,
- icône d’un rond (vide/rempli) : Marque l’article comme lu ou non-lu (suivant de quel état on commence),
- icône de traits verticaux entrecoupés comme de petits pistons : Permet de changer la police d’écriture (parmi sans-serif, serif et monospace) ainsi que la taille de police (petit, ou grand, plus on appuie plus ça réduit/aggrandit),
- icône d’un livre ouvert : Choisi de lire l’article dans Yarr ou bien seulement les informations du flux RSS,
- icône d’un carré avec une flèche qui en sort) : Va directement sur le site Web de l’article en question.

J’utilise souvent l’icône de validation de la seconde colonne pour marquer tous les articles comme lus une fois que j’ai parcouru la liste des titres et que rien ne m’intéressait.

Les raccourcis claviers sont là pour faciliter le traitement des articles (lu, non-lu, favori, lire à l’extérieur, etc.). Parfois j’utilise le raccourci “o” pour lire l’article sur le site Web.

Du reste, je n’utilise quasiment rien. Après tout je ne viens que pour lire des titres, trier et lire un article de temps en temps 🤷 . Je ne suis pas là pour bosser.

Conclusion

Au début un peu perdu par l’interface afin de comprendre à quoi sert chaque élément - surtout entre interface petit écran et grand écran - j’ai finalement apprécié Yarr à l’usage.

C’est un outil “menu” (maigre, léger), simple, basique, sans fioritures. Configurable un minimum. Utilisable avec des raccourcis clavier. Très efficace d’ailleurs avec un clavier quand on s’y fait. C’est même redoutable de rapidité quand on a le coup de main !

À vrai dire, je ne sais même pas de quoi j’aurais besoin en plus pour lire des flux. J’ajoute rapidement des flux, j’importe et exporte facilement pour partager avec d’autres, je vois de nouveaux articles, je clique sur ce qui m’intéresse, je lis, je note le reste des articles comme lus pour ce flux et voilà.

Ni plus. Ni moins. Parfait 😄 .

Liens utiles

Voici les liens de l’article par ordre d’apparition :

RustFS, alternative au service de stockage objet MinIO

Sun, 15 Feb 2026 17:27:26 +0100

Quand on étudie Kubernetes, on arrive tôt ou tard sur la question de la gestion des sauvegardes. Et avec elles le sujet du stockage de ces dernières. La référence en matière de sauvegarde - dont je parlerais sûrement dans un prochain article - est Velero. Cet outil supporte plusieurs fournisseurs de stockage pour ses opérations de sauvegarde comme Amazon Web Services, Google Cloud, Microsoft Azure ou VMware Sphere. Principalement des fournisseurs liés à une entreprise. Que faire dans la situation où nous souhaitons auto-héberger une solution de stockage chez soi ?

C’est ce dont je voudrais parler aujourd’hui : une solution spécifique que j’ai - presque - choisie. Surtout pourquoi cette solution ? Je décrirais son installation sous Docker Compose derrière un proxy nommé Traefik, dont je vous ai déjà parlé. Et j’ajouterais quelques mots sur les ports réseau à ouvrir, l’initialisation des premiers « buckets » (nous y reviendrons) et l’usage de noms de domaines.

Pourquoi cette solution ?

Si vous n’êtes pas fan de l’histoire de « pourquoi choisir cette solution », vous pouvez passer au chapitre suivant, je ne vous en voudrais pas 😉.

En étudiant la documentation de Velero on découvre parmi les fournisseurs de solutions de stockage le célèbre Amazon Web Services. Et avec lui le service Amazon S3. Ce service est une solution de stockage objet qui a développé un protocole ouvert du même nom : S3. Grâce à cela, de nombreux outils compatibles avec ce protocole ont vu le jour ; que ce soit des clients comme des serveurs. Top, c’est ce que je recherche !

Ayant beaucoup entendu parler de MinIO, je m’enquiers de l’installer fin novembre 2025. En Docker Compose, derrière Traefik comme je l’explique dans un précédent article sur le sujet. Mais quelques problèmes se posent successivement :

en août 2025 les dépôts de Bitnami, qui fournissaient jusqu’alors d’excellentes images, chartes Helm et outils en tous genres sont chamboulés par une décision drastique prise par Bitnami. L’impact est énorme sur la communauté,
faute de cette image pratique, je me tourne vers l’image officielle qui demande des ajustements pour avoir des « buckets » à l’initialisation,
finalement le 13 février 2026, l’entreprise qui gérait MinIO décide d’abandonner la maintenance de la version communautaire.

Coup dur. Je recherche des alternatives. Je tombe sur le message de loverustfs qui compare les solutions alternatives à RustFS, dont MinIO, Garage, Ceph, Seaweeedfs, etc..

Edit (24 fév. 2026) : Un fork de MinIO est apparu il y a quelques jours. Si le cœur vous en dit 🤷.

RustFS n’est probablement pas la solution la plus performante (Seaweedfs semble plus performant), mais il se défend bien. Et il semble proche de MinIO en terme d’interface et d’utilisation. Allons donc, ne le faisons pas attendre, installons-le !

RustFS sous Docker Compose

L’idée est d’installer/utiliser RustFS avec Docker Compose. Derrière Træfik. Avec des domaines.

Installation minimale

On commence par une installation de base. On a besoin de :

une image Docker. Ça tombe bien, il y a des images officielles de RustFS sur le Hub Docker,
ouvrir 2 ports :
- 9000,
- 9001,
un volume local pour stocker les données et pouvoir les réutiliser entre 2 redémarrages de conteneurs,
un identifiant et un mot de passe initial.

ATTENTION : le projet RustFS est encore jeune, il est en développement actif et les versions ne sont pas toutes utilisables telles quelles. Par exemple dans ma situation, la version 1.0.0-alpha.83 était inutilisable. Ceci dû à un bug sur l’architecture de ma machine comme le montre ce ticket Github.

Une première ébauche d’un fichier docker-compose.yaml pourrait s’écrire de la manière suivante :

services:
  rustfs:
    image: rustfs/rustfs:1.0.0-alpha.82
    restart: always
    ports:
      - 9000
      - 9001
    volumes:
      - ./storage_data:/data
      - /etc/localtime:/etc/localtime:ro
      - /etc/timezone:/etc/timezone:ro
    environment:
      - RUSTFS_VOLUMES=/data
      - RUSTFS_ADDRESS=0.0.0.0:9000
      - RUSTFS_CONSOLE_ADDRESS=0.0.0.0:9001
      - RUSTFS_CONSOLE_ENABLE=true
      - RUSTFS_ACCESS_KEY=olivier
      - RUSTFS_SECRET_KEY=mot2passe
      - RUSTFS_OBS_LOGGER_LEVEL=info
    healthcheck:
      test:
        [
          "CMD",
          "sh", "-c",
          "curl -f http://127.0.0.1:9000/health && curl -f http://127.0.0.1:9001/rustfs/console/health"
        ]
      interval: 30s
      timeout: 10s
      retries: 3
      start_period: 40s

Veillez à changer les éléments suivants - au minimum :

./storage_data dans la section volumes. Renseigner par un dossier dans lequel vous voulez stocker les données,
RUSTFS_ACCESS_KEY dans la section environment. Changez olivier par un identifiant que vous souhaitez utiliser,
RUSTFS_SECRET_KEY dans la section environment. Changez la valeur mot2passe par quelque chose de bien plus long et bien plus compliqué que cela (une clé secrète en somme).

De cette façon, le service va se lancer avec des ports choisis par Docker Compose. Vous pouvez les connaître en tapant les commandes suivantes :

docker compose port rustfs 9000
docker compose port rustfs 9001

On constate sur l’interface (port initial 9001), après s’être authentifié avec l’identifiant et la clé secrète, qu’il n’y aucun bucket.

Initialisation des buckets

Qu’est un bucket ?

C’est un espace qui regroupe plusieurs objets qu’on aurait déposé à cet endroit. Cela permet de se repérer plus facilement dans un espace de stockage objet.

Afin de créer un bucket, soit on utilise l’interface (méthode manuelle), soit on créé un conteneur d’initialisation qui fera le job à notre place (automatique).

J’opte pour le conteneur d’initialisation pour créer 3 buckets. Dans notre fichier docker-compose.yaml on ajoute les lignes suivantes :

  init_buckets:
    image: minio/mc:RELEASE.2025-08-13T08-35-41Z
    depends_on:
      - rustfs
    restart: on-failure
    entrypoint: >
      /bin/sh -c "
      sleep 5;
      /usr/bin/mc alias set s3server http://rustfs:9000 \"olivier\" \"mot2passe\";
      /usr/bin/mc mb s3server/default;
      /usr/bin/mc mb s3server/bucket1;
      /usr/bin/mc mb s3server/bucket2;
      exit 0;
      "

Pensez à changer olivier et mot2passe par les mêmes identifiants/mot de passe que renseignés dans le service rustfs du docker-compose.yaml précédent.

L’astuce est donc d’utiliser le client mc de MinIO pour ajouter les buckets qu’on souhaiterait. Dans l’exemple présenté ci-avant, le conteneur d’initialisation permet de créer 3 buckets :

default,
bucket1,
bucket2.

Libre à vous d’adapter ce conteneur pour répondre à vos besoins en matière de création initiale de bucket.

Il ne reste alors plus que la mise à disposition sur Internet via l’usage de sous-domaines et de Træfik.

Configurer les labels pour Træfik

Træfik est un proxy souvent utilisé avec Docker Compose pour se charger des routes. L’idée de Træfik est d’utiliser le champ labels pour récupérer des instructions utiles à la création des routes en lien avec les domaines.

Pour RustFS sous Docker Compose, et avec Træfik en frontal, je suggère les labels suivants :

    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.api-rustfs.rule=Host(`api.mondomaine.tld`)"
      - "traefik.http.routers.api-rustfs.entrypoints=websecure"
      - "traefik.http.routers.api-rustfs.service=api-rustfs"
      - "traefik.http.services.api-rustfs.loadbalancer.server.port=9000"
      - "traefik.http.routers.rustfs.rule=Host(`mondomaine.tld`)"
      - "traefik.http.routers.rustfs.entrypoints=websecure"
      - "traefik.http.routers.rustfs.service=rustfs"
      - "traefik.http.services.rustfs.loadbalancer.server.port=9001"

Prenez soin de changer les éléments suivants :

websecure par le nom de votre routeur permettant d’avoir du HTTPS,
api.mondomaine.tld par le domaine de votre choix pour accéder à l’API de RustFS,
mondomaine.tld par le domaine utilisé pour accéder à l’interface Web de RustFS.

Évidemment tout un tas d’autres options sont possibles, il suffit de lire la documentation de Træfik pour cela.

Résultat final complet

Ce qui nous donne :

services:
  rustfs:
    image: rustfs/rustfs:1.0.0-alpha.82
    restart: always
    ports:
      - 9000
      - 9001
    volumes:
      - ./storage_data:/data
      - /etc/localtime:/etc/localtime:ro
      - /etc/timezone:/etc/timezone:ro
    environment:
      - RUSTFS_VOLUMES=/data
      - RUSTFS_ADDRESS=0.0.0.0:9000
      - RUSTFS_CONSOLE_ADDRESS=0.0.0.0:9001
      - RUSTFS_CONSOLE_ENABLE=true
      - RUSTFS_ACCESS_KEY=olivier
      - RUSTFS_SECRET_KEY=mot2passe
      - RUSTFS_OBS_LOGGER_LEVEL=info
    healthcheck:
      test:
        [
          "CMD",
          "sh", "-c",
          "curl -f http://127.0.0.1:9000/health && curl -f http://127.0.0.1:9001/rustfs/console/health"
        ]
      interval: 30s
      timeout: 10s
      retries: 3
      start_period: 40s
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.api-rustfs.rule=Host(`api.mondomaine.tld`)"
      - "traefik.http.routers.api-rustfs.entrypoints=websecure"
      - "traefik.http.routers.api-rustfs.service=api-rustfs"
      - "traefik.http.services.api-rustfs.loadbalancer.server.port=9000"
      - "traefik.http.routers.rustfs.rule=Host(`mondomaine.tld`)"
      - "traefik.http.routers.rustfs.entrypoints=websecure"
      - "traefik.http.routers.rustfs.service=rustfs"
      - "traefik.http.services.rustfs.loadbalancer.server.port=9001"

  init_buckets:
    image: minio/mc:RELEASE.2025-08-13T08-35-41Z
    depends_on:
      - rustfs
    restart: on-failure
    entrypoint: >
      /bin/sh -c "
      sleep 5;
      /usr/bin/mc alias set s3server http://rustfs:9000 \"olivier\" \"mot2passe\";
      /usr/bin/mc mb s3server/default;
      /usr/bin/mc mb s3server/bucket1;
      /usr/bin/mc mb s3server/bucket2;
      exit 0;
      "

Avec ce contenu vous devriez pouvoir démarrer une instance RustFS sans problème 😉.

Quelle aventure !

Au bout du compte, avoir cherché à lancer un service de stockage objet a été une sacrée odyssée pour moi. Beaucoup d’aléas liés au changement de politique de Bitnami (pour les images MinIO), à l’arrêt de maintenance du code du serveur MinIO par AIStor et aux effets de bord de RustFS en plein développement.

Mes besoins spécifiques en terme d’infrastructure (Docker Compose et Træfik) m’ont amené à devoir retravailler plusieurs fois le fichier docker-compose.yaml. Et j’ai essuyé quelques plâtres avant d’avoir une instance fonctionnelle.

Je suis ainsi content de partager ce fichier docker-compose.yaml. Bien qu’il y a matière à faire évoluer ce fichier. On peut imaginer améliorer ce fichier en utilisant des variables pour le dossier où seront stockées les données, le nom du service, le domaine et bien évidemment l’identifiant et le mot de passe du service RustFS. Et déposer les valeurs dans un fichier .env.

On pourrait également trouver un autre client que mc pour initialiser les buckets au départ. Voire trouver un autre outil permettant de créer les buckets plus facilement. Imaginons une nouvelle image Docker ayant un script d’initialisation avec des variables d’environnement le permettant.

Je laisse votre imagination faire le reste 😊.

Sources utilisées pour la mise en place de RustFS

Liens utiles

Mon Labo K8S pour essayer des applications

Sun, 09 Nov 2025 06:25:39 +0100

Introduction

Quand on commence à étudier Kubernetes (k8s), on a besoin d’un environnement où tester ce qu’on apprend. Les environnements possibles sont nombreux : Minikube, Kubernetes (k8s) officiel, k0s, k3s, etc. Cela ne s’arrête plus !

Entre les difficultés à installer l’environnement et celles à appliquer ce qu’on apprend, on ne s’en sort plus. Cela devient vite compliqué au point de vouloir tout arrêter ; c’était mon cas.

De plus je souhaitais avoir un environnement reproductible et spécifique à chacun de mes projets, de quoi travailler unitairement sur un service particulier.

Avant de décrocher complètement, j’ai fait une pause, pris du recul et étudié la question. Je vous relate ici le résultat de cette petite aventure dans le monde de Kubernetes et des outils envisagés pour créer un labo de développement d’applications tournant sous Kubernetes.

Dans un premier temps nous poserons le problème, après quoi nous étudierons quelques solutions pour finalement détailler le produit de cette pérégrination.

Photo trouvée sur publicdomainpictures.net sous Licence CC0 Public Domain.

Le contexte

Venant du monde de Docker et Docker Compose, il me semblait aller de soi d’étudier ensuite le monde de Kubernetes - qui utilise la conteneurisation. Seulement je ne pensais pas que l’installation même de Kubernetes était un cap à franchir.

Je souhaite en profiter pour migrer petit à petit mes services sur Kubernetes. Chacun d’eux devient donc un projet en soi. Et comme souvent, j’aime avoir un environnement spécifique de développement pour créer les fichiers nécessaires à Kubernetes et permettre a posteriori d’améliorer le service. Je cherche donc à avoir un simili de docker-compose.yml pour chaque service et permettant de développer l’application dans un environnement Kubernetes propre.

Au début on découvre Minikube. Du moins c’est un outil très souvent conseillé. Pratique sur une machine bureautique pour triturer rapidement quelques fichiers Kubernetes (des fichiers au format YAML). Il est bien documenté et possède plusieurs plugins pour faciliter l’étude du Kubernetes en place ; par exemple un plugin Dashboard permet de visualiser les métriques du serveur et les objets instanciés. J’ai la sensation que cet outil reste « trop spécifique ». Il ne représente pas totalement un « vrai » Kubernetes. Ça peut parfois causer des torts au moment de déployer sur un autre serveur Kubernetes. L’outil est également lourd et relativement lent pour instancier un nouvel environnement.

Pourquoi ne pas tester un Kubernetes connu pour sa légèreté ? Par exemple k3s. D’autant qu’il s’installe rapidement à l’aide de k3sup (qui fonctionne à merveille). Sur le papier c’est une bonne idée : léger, facile à installer. En revanche il ne permet pas d’instancier un nouvel environnement ; il faut donc jouer avec les namespaces Kubernetes. Rebelote : ce n’est pas un outil adapté à l’apprentissage de Kubernetes. Au départ on fait forcément des erreurs dues à l’incompréhension ou l’ignorance ; ce qui peut rendre l’environnement rapidement inutilisable.

Après ces deux premières tentatives, je sais désormais ce que je veux :

possibilité de créer un environnement « propre »,
encore mieux s’il peut créer plusieurs environnements,
si possible léger (petit) - ce qui exclue les machines virtuelles,
facile à installer,
et rapide.

Nous avons nos critères, il ne reste plus qu’à chercher le(s) outil(s) permettant de créer rapidement un environnement de développement autour de Kubernetes.

Solutions étudiées

À la recherche des mots clés « lightweight » (similaire au mot léger) et « kubernetes » dans un moteur de recherche, on trouve plusieurs outils comme :

MicroK8S,
k0s,
k3s,
et kind.

k3s a déjà été cité dans cet article. Il ne me convient pas pour un environnement de développement/d’étude concernant k8s. Il est sûrement très redoutable à l’installation rapide sur une quantité importante de machines à l’aide de k3sup. Mais ce n’est pas le sujet de cet article.

La liste mentionne également MicroK8S, le petit rejeton de la famille Ubuntu, qui semble être une alternative à Minikube avec des plugins (Dashboard, DNS, registry, istio, etc.). Je pense qu’il est effectivement intéressant pour un usage complet entre des développeurs, une intégration continue (CI) / déploiement continue (CD) et plusieurs environnements allant jusqu’à des environnements dit « de production ». Je sens cependant que la similitude avec Minikube ne puisse me convenir. Je le laisse de côté pour l’instant.

k0s, quant à lui, semble être la solution idéale pour une installation sur une machine physique. À usage privé. Bien qu’il semble léger, facile à installer et utiliser, je comprends rapidement qu’il est fait pour avoir une installation unique sur une machine physique précise. Il ne répond pas à mon critère de création multiple d’environnements.

Et un de plus en moins !

Il reste le dernier de cette liste : kind. A priori il semble léger, prévu pour un usage spécifique au développement ou de l’intégration continue (CI) et utilise Docker pour créer un cluster complet à chaque fois. Waouh, rien que ça ! Sur le papier, cet outil est très prometteur car il répond aux critères précédemment listés :

créer des environnements « propres » grâce à l’usage de Docker,
ainsi il permet l’usage de plusieurs environnements,
il est léger, petit,
facile à installer puisque kind est disponible dans les dépôts AUR d’ArchLinux,
et pour la rapidité nous verrons.

À l’usage, kind (qui veut dire Kubernetes IN Docker) semble facile à prendre en main :

# Créer un cluster nommé olivier
kind create cluster --name olivier
# Supprime le cluster nommé olivier
kind delete cluster --name olivier

Une fois le cluster créé, il s’agit simplement de jouer avec la commande kubectl habituelle pour contacter le cluster. Et la commande étant à taper, je peux tout à fait scripter la création du cluster et sa destruction.

Il serait plus pratique de l’utiliser avec d’autres outils pour en faciliter l’usage. J’ai donc cherché au fur et à mesure de nouveaux outils dont voici la liste :

kubectx va permettre de commuter d’un contexte Kubernetes à un autre. Autrement dit passer d’un cluster à un autre facilement,
kubeconform pour valider nos fichiers YAML,
kube-linter pour pousser à l’usage des bonnes pratiques en matière de rédaction de fichiers YAML,
skaffold pour surveiller la moindre modification (équivalent d’un « watcher ») sur nos fichiers YAML et les déployer directement sur le cluster,
et make (avec un fichier Makefile) pour mélanger tout ça.

Mon idée est d’utiliser un fichier Makefile pour fournir plusieurs commandes permettant de créer le cluster, le détruire, vérifier les fichiers YAML ou encore lancer un déploiement automatique s’il y a des changements dans les fichiers en cours de développement.

J’imagine quelque chose comme :

make cluster pour créer un cluster,
make dev pour lancer skaffold et écouter le moindre changement sur le dossier de développement de l’application,
make kubeconform pour vérifier les fichiers une fois écrits,
make lint pour vérifier les bonnes pratiques avec kube-linter,
et make clean pour détruire le cluster.

Tentons l’aventure et voyons le résultat !

Ce que j’ai finalement produit

En bref

Le fichier Makefile :

CLUSTER_NAME := k8s-dev-example
KUBECTL := kubectl
SKAFFOLD := skaffold
KIND := kind
KUBECONFORM := kubeconform
KUSTOMIZE := kustomize

NAMESPACES := dev

.PHONY: help
help:
	@echo "Commandes disponibles :"
	@echo "  make cluster       - Crée un cluster Kind"
	@echo "  make namespaces    - Crée les namespaces Kubernetes (dev/staging/prod)"
	@echo "  make dev           - Lance Skaffold pour l'env dev"
	@echo "  make kubeconform   - Lance kubeconform sur l'env de DEV"
	@echo "  make clean         - Supprime le cluster Kind"

cluster:
	$(KIND) create cluster --name $(CLUSTER_NAME) ||:

namespaces:
	@for ns in $(NAMESPACES); do \
		$(KUBECTL) get ns $$ns >/dev/null 2>&1 || $(KUBECTL) create ns $$ns; \
	done

dev: cluster namespaces
	$(SKAFFOLD) dev

kubeconform: kubeconform-dev

kubeconform-dev:
	$(KUSTOMIZE) build overlays/dev | $(KUBECONFORM) -strict -summary -ignore-missing-schemas

clean:
	$(KIND) delete cluster --name $(CLUSTER_NAME)

Ce fichier Makefile est disponible sur le dépôt Gitlab d’ODTRE.

Il va utiliser deux dossiers principaux :

base qui contient les fichiers YAML de l’application qu’on souhaite implémenter sur Kubernetes,
overlays/dev qui contient un fichier kustomization.yaml pour surcharger le dossier base.

Et 2 fichiers de configuration :

kube-linter.yaml avec votre configuration de l’outil,
skaffold.yaml avec le contenu suivant :

apiVersion: skaffold/v4beta13
kind: Config
metadata:
  name: k8s-demo-app
manifests:
  kustomize:
    paths:
      - ./overlays/dev
# Exemple de redirection de port sur le service nommé dev-nginx (car l'overlay ajoute dev- devant tout)
portForward:
  - resourceType: service
    resourceName: dev-nginx
    namespace: dev
    port: 80
    localPort: 4000

Cela permet de surveiller le dossier ./overlays/dev avec kustomize pour interpréter les fichiers. Et il va ouvrir le port 4000 sur la machine locale pour rediriger sur le port 80 du service Nginx d’exemple (fourni dans le dépôt Gitlab mentionné précédemment).

À l’usage

Tout n’est pas parfait. Cependant ce fichier Makefile permet de lancer quelques commandes make utiles :

# Lance l'environnement de DEV. Si le cluster n'existe pas : il le créé. Sinon il ignore.
make dev
# Vérifie la conformité des fichiers YAML en utilisant le dossier overlays/dev
make kubeconform
# Détruit le cluster de DEV
make clean
# Pousse à l'usage des bonnes pratiques sur les fichiers contenus dans le dossier ./base
kube-linter lint --config kube-linter.yaml ./base

Pour toute aide supplémentaire, faites : make help.

Ainsi il devient facile de travailler sur un nouvel environnement :

je copie les fichiers disponible sur un dépôt template sur Gitlab,
j’ouvre le fichier Makefile en écriture,
j’édite la ligne suivante pour adapter le nom du cluster de travail :

CLUSTER_NAME := k8s-dev-example

Et le tour est joué !

Je suis assez satisfait de cet environnement. Il répond aux critères édictés plusieurs fois dans cet article. Et je me sens plus à l’aise de pouvoir modifier comme bon me semble cet environnement de développement/travail.

Les outils utilisés me font penser à une boîte à outil de base pour le travail sur Kubernetes. Même sans utiliser le fichier Makefile je suis amené à pratiquer les outils comme kubeconform, kubectl, kube-linter et kustomize.

C’est donc une très bonne chose d’avoir regroupé ces outils autour de Makefile et de les utiliser régulièrement sur mes projets Kubernetes.

Conclusion

Nous avons posé le contexte d’une recherche d’outil simple, rapide et léger pour créer de nombreux environnements Kubernetes afin de travailler sur ces environnements dans le cadre d’un développement de fichiers YAML.

Après quelques essais sur Minikube et k3s, mes recherches se sont portées sur l’utilisation de kind. Puis j’ai utilisé make pour le manipuler et regrouper aussi les différents outils utiles.

La boîte à outil se compose de :

kind,
skaffold,
kubectl,
kubeconform,
kube-linter,
et make.

J’aborde désormais de manière plus sereine le développement d’une application qui sera hébergée par un Kubernetes. J’ai un template à ma disposition pour ces fichiers. Template que je peux faire évoluer au gré des obstacles rencontrés. Il utilise tous les outils que j’ai appréciés. J’en suis pleinement satisfait 😎 .

Et vous, quel environnement Kubernetes utilisez-vous pour vos développements de fichiers YAML ?

Liens utiles

Clavier Keychron Q6 Knob ISO version

Wed, 10 Sep 2025 21:47:52 +0200

Introduction

À une époque lointaine je m’intéressais aux claviers mécaniques. Notamment le Das Keyboard 2. Aucun article sur le présent site n’avait été publié. Je l’ai pourtant fait lors de l’acquisition de mon clavier USB Compact Thinkpad avec TrackPoint en 2017. Mais ce n’est pas un clavier mécanique.

Aujourd’hui j’aimerais partager avec vous des éléments autour des claviers mécaniques. Et pour cela nous parlerons, entre autre, du clavier Keychron Q6 Knob ISO Version acquis il y a quelques années déjà : en 2022.

Je tiens à préciser que d’autres personnes, comme Richard Dern, parlent mieux de ce sujet sur leur blog, voire détaillent mieux les parties concernant les composants de clavier mécaniques.

J’aimerais surtout partager les caractéristiques de ce clavier, pourquoi je l’ai choisi, quels composants permettent de construire son propre clavier, combien cela coûte et les outils disponibles pour améliorer son expérience sur un clavier personnalisé et personnalisable.

Le Keychron Q6 Knob ISO Version

Vous l’aurez compris : j’ai acheté un Keychron Q6 Knob ISO Version.

Modèle et disposition

Que veut dire Keychron Q6 Knob ISO Version

Keychron est la marque du clavier (l’entreprise qui fabrique le clavier),
Q6 en est le modèle. Il existe plusieurs modèles en fonction du nombre de touches, du type de clavier (filaire, bluetooth ou wifi), etc.
Knob est une alternative possédant un potentiomètre. Bref, un gros bouton qui tourne pour changer le volume 😄
Et ISO version signifie que la disposition du clavier est européenne plutôt que la version ANSI qui par exemple ne se présente pas de la même manière au niveau de la touche entrée (bien plus fine que celle pour la version européenne).

Edit : En réalité ISO est un standard nommé aussi IEC 9995 (merci à GreyXor de l’avoir signalé).

Caractéristiques

Ayant pris seulement la base du clavier (sans les touches ni les switches - dont nous parlerons plus tard), voici les caractéristiques de ce support de clavier :

Clavier avec une base en aluminium,
Branchement filaire avec de l’USB-C - avec un adaptateur USB-C vers USB Type B,
Bouton pour changer de disposition Win/Mac,
Clavier programmable (avec un firmware QMK - open source),
Touches rétroéclairées,
Disposition ISO (européenne),
Couleur « Navy Blue ».

Apparence de la base que j’ai prise :

Pourquoi ce choix ?

À 200€ environ - rien que la base, sans touches - on peut se demander ce qui a motivé cet achat. Et curieusement la réponse est : financière !

Je divague ? Pas totalement.

En effet ces dernières annnées, avant l’acquisition d’un tel objet, j’achetais 1 clavier par an. Pas pour être à la page, ni pour toujours avoir un clavier neuf. Mais parce que mes claviers tombent en panne environ 1 an après leur achat.

J’utilise énormément la ligne de commande. Et contrôle mon bureau au clavier. Il a donc une place cruciale dans mes usages. Et à cet effet il s’use aussi très vite. Avec 12 000 phrases par mois sur un seul salon de discussion sur lequel je suis actif, avec 50 mots par phrase en moyenne, même si un mot faisait 3 lettres, cela fait - en arrondissant beaucoup - quelque chose comme 2 millions de touches appuyées sur 1 an. Et ceci n’est qu’un seul de mes - nombreux - usages. J’écris sur d’autres supports.

Au début j’achetais des claviers simples, à 30€, puis 60€ pour monter en gamme. Et à force mes habitudes se tournaient vers des claviers pratiques, rétroéclairés, mécaniques, avec un potentiomètre pour le son, etc. Et les coûts avoisinaient facilement 200€. Jusqu’à ce qu’il tombe en panne et que je doive en racheter un.

Autant vous dire qu’à 200€ l’année, ça commence à faire cher. Ainsi j’ai décidé de me tourner vers les claviers « faits-maison » : des claviers qu’on assemble soi-même.

L’idée ? Si quelque chose tombe en panne je le remplace au prix de la pièce. Pas au prix d’un clavier entier.

Historique de mes claviers

Pour vous donner un ordre de grandeur des dépenses, voici un historique de mes achats et de leur prix approximatif. Uniquement pour les claviers mécaniques, sans les claviers intermédiaires :

2009 - (~80€) Das Keyboard 2 (switches Cherry MX blue),
2017 - (~120€) Das Keyboard 4 Ultimate (switches Cherry MX brown),
2019 - (~200€) Corsair K95 RGB platinum (switches Cherry MX brown),
2022 - (~70€) DREVO Calibur V2 Te RGB 60% (switches Cherry MX brown),
2022 - (~210€ + switches + touches) Keychron Q6 Knob ISO Version (nu, sans touches, sans switches)

Avant 2022, rien qu’en clavier mécanique, sur 10 ans j’avais dépensé 400€. Et quasiment tout autant en clavier “non mécanique”. Soit 800€ sur 10 ans, soit 80€ par an.

L’idée est donc de diminuer ce budget pour les 10 ans à venir (à partir de 2022).

Les composants d’un clavier « fait-maison » (assemblé)

Avoir un clavier assemblé veut dire composer soi-même son clavier : il faut choisir chacun des composants. Trouver des composants compatibles, comparer les prix, commander, patienter, monter/assembler.

Nous ne sommes pas là pour faire un cours sur les éléments nécessaires à un clavier ni pour détailler chacun des composants, mais voici les éléments de base :

un boîtier de clavier (pour mettre la carte mère de clavier notamment),
mousse dans le boîtier pour réduire l’écho (quand on tape sur une touche),
une carte mère pour gérer la ou les dispositions de clavier,
une plaque à mettre par dessus,
des switches (qui sont le lien entre un emplacement de touche et la touche elle-même),
des stabilisateurs pour les touches plus grosses comme la touche Entrée, la barre espace, etc.,
des touches pardi !
et un repose-poignet (facultatif).

Combien cela a-t-il coûté ?

Faisons le calcul approximatif. En 2022 j’ai acheté :

80€ - switches pour clavier mécanique,
28€ - une seule touche personnalisée (Toadstool Retainer de Mario Bros),
210€ - la base du clavier keychron (sans les touches, sans les switches),
40€ - une seule touche en métal (le point interrogation de Mario Bros),
62€ - ensemble de touches north-facing,
57€ - repose-poignet en marbre.

Total : ~480€.

À ce prix, le clavier devient économique au bout de 2 ans et demi - pour moi. En effet, ces dernières années je dépensais pas moins de 200€ de clavier par an (avant l’arrivée du Keychron Q6 dans le foyer).

Retour(s) d’expérience

À l’heure où j’écris ces lignes nous sommes en 2025. Le clavier est toujours vivant. Toujours robuste. Toujours fonctionnel. J’ai dû changer 2 switches seulement à moindre coût. Les touches ont été changées pour une raison simple : on m’en a offertes. Je n’ai rien dépensé de plus pour ce clavier. J’ai donc réduit grandement mon budget clavier à l’année.

L’utilisation est appréciable. Très appréciable ! J’ai choisi des switches qui me conviennent parfaitement : la pression des touches est adaptée à ma frappe. Ni trop dure, ni trop molle. De temps en temps, je change les touches (appelées « caps » en anglais) pour le plaisir. Comme si c’était un revêtement de saison ou une nouvelle parure.

En revanche ce clavier est très lourd. Il est mastoc. Ce qui le rend impossible à transporter comme on le ferait avec d’autres claviers. Si vous prévoyez de déplacer le clavier, mieux vaut en prendre un plus petit - avec moins de touches. Mais quoi de mieux qu’un bon gros clavier pour son bureau ?

Finalement je me sens à l’aise avec ce clavier qui coche mes critères et répond à son rôle à merveille ; sans défaillir !

Outils disponibles pour un tel clavier

La particularité d’un tel clavier est de pouvoir être personnalisable non seulement en matière de touches, de réaction et de pressions, mais aussi en terme de réponse à un appui. C’est à dire de pouvoir définir sous chaque touche l’action qui sera entreprise. Si la plupart des claviers répondront par un A à l’appui de la touche A, nous pouvons tout à fait définir que l’appui sur la touche A met en pause la vidéo en cours de lecture. Et c’est ça qu’on recherche, croyez-moi !

Pour ce faire, nous disposons d’une ribambelle d’outils, parmi :

QMK Configurator, une interface Web de configuration de son clavier (utilise le firmware QMK, votre clavier doit donc être compatible),
Keychron Launcher, l’outil officiel de Keychron pour configurer son clavier en ligne (nécessite un navigateur parmi Microsoft Edge, Chrome ou Opera - qui doit surtout gérer WebUSB, Cf. Support de WebUSB sur la plupart des navigateurs courants),
VIA, une interface conviviale et simple.

Ces outils ne fonctionneront que si le clavier est reconnu par le système et le navigateur. Pour savoir comment procéder avec le Keychron Q6, je vous renvoie vers ma page d’astuce concernant le Keychron Q6 ISO Knob version.

Vous pouvez également installer sur votre machine certains outils, comme ceux contenus dans QMK Toolbox.

Conclusion

Après avoir détaillé les caractéristiques de ce clavier Keychron Q6 Knob ISO Version, les composants nécessaires à sa complétude, l’historique de mes claviers pour comprendre la baisse éventuelle du budget par an et mes retours d’expérience, il semble clair qu’au bout de 3 ans je suis pleinement satisfait de ce clavier. Avec l’ensemble des claviers mécaniques que j’ai achetés, je peux désormais dire que ce clavier me convient parfaitement. Il est devenu LE clavier.

De 2022 à 2025, ce changement de clavier est devenu rentable. Le temps nous dira de combien il l’est. Rien que pour la maintenance possible par « petites doses » (comme changer seulement les touches usées), cela vaut le coup ! En revanche on s’aperçoit que changer d’apparence peut coûter cher : en fonction de l’ensemble de touches choisi les prix varient entre luxe et arnaque (les prix sont parfois indécents)…

Par ailleurs une large gamme d’outils est disponible pour personnaliser les touches et on peut facilement se lancer dans une programmation du clavier très forte avec une réelle évolution de l’usage que nous en faisons. Je conseille !

Et vous ? Quel sera votre prochain clavier mécanique ?

Liens utiles

Clavier Das Keyboard 2,
Clavier Keychron Q6 Knob ISO Version,
Article de Richard Dern sur la recherche du clavier parfait,
Article de Richard Dern concernant l’orientation des switches,
QMK Configurator, une interface Web de configuration de son clavier (utilise le firmware QMK, votre clavier doit donc être compatible),
Keychron Launcher, l’outil officiel de Keychron pour configurer son clavier en ligne (nécessite un navigateur parmi Microsoft Edge, Chrome ou Opera),
VIA, une interface conviviale et simple,
Ma page d’astuce concernant le Keychron Q6 ISO Knob version.

Ce que j'aurais voulu savoir sur Gitlab CI

Sun, 18 May 2025 13:55:39 +0200

Introduction

Il y a quelques mois je parlais de ma formation Bootcamp pour devenir Ingénieur DevOps. J’y ai utilisé - à nouveau - Gitlab CI (Continuous Integration). Vous savez, cet outil permettant d’exécuter des actions après avoir envoyé votre code/dépôt sur la plateforme Gitlab ?

C’est très utile, par exemple pour lancer les tests sur votre code, vérifier que le code s’exécute dans un environnement précis ou tout simplement vérifier que le code compile. Et si votre dépôt n’est pas du code, par exemple un site web, vous pouvez tester les liens morts ; voire publier votre site ! Les possibilités sont - finalement - nombreuses !

En revanche, un tel outil est parfois déstabilisant. Et des cheveux, j’en ai arrachés ! J’aurais apprécié tomber sur un article explicatif. Avec des astuces. Peut-être que le présent article m’aurait convenu, qui sait !

J’aurai par exemple aimé savoir comment publier facilement un site web, tester localement le fichier .gitlab-ci.yml avant de l’envoyer sur Gitlab, connaître plus d’astuces pour les mots clés Gitlab, savoir utiliser Docker dans Gitlab CI et ce que sont les composants réutilisables.

Ce sont ainsi tous les sujets que nous allons aborder aujourd’hui.

Photo trouvée sur le profil de didier.camus sur Flickr sous Licence Œuvre du domaine public.

Publier rapidement un site statique

Gitlab met à disposition des utilisateurs un espace permettant d’héberger des sites webs statiques. Incroyable n’est-ce pas ? Cet espace est Gitlab Pages.

Comment cela fonctionne ? Il suffit de créer un dépôt Gitlab, d’ajouter un fichier .gitlab-ci.yml contenant la section suivante :

image: busybox

pages:
  stage: deploy
  script:
    - echo "The site will be deployed to $CI_PAGES_URL"
  artifacts:
    paths:
      - public
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

Code récupéré du projet https://gitlab.com/pages/plain-html.

Cela signifie qu’au terme de la CI/CD (dans l’étape nommée deploy), le contenu du dossier public sera publié sur Gitlab Pages. À quelle adresse ? Imaginons que vous partez d’un dépôt dont l’adresse est : https://gitlab.com/blankoworld/monprojet/, l’adresse URL d’accès à votre site publié sera : https://blankoworld.gitlab.io/monprojet/. Pratique non ?

Astuce : Si votre dépôt est privé, vous pouvez quand même rendre votre site public. Il suffit d’aller dans Settings > General, Section « Visibility, project features, permissions » et dans le sous-titre « Pages », activez la fonctionnalité. Et dans le menu déroulant à côté, choisissez « Everyone ». N’oubliez pas de sauvegarder cette configuration. Le code sera privé, le site web statique public !

Pour plus d’exemple, veuillez vous rendre sur la page Gitlab présentant la liste de projets utilisant Gitlab Pages.

Tester avant d’envoyer sur le dépôt ?

Le truc vraiment embêtant avec les fichiers .gitlab-ci.yml, c’est qu’on ne peut pas les tester sur notre machine (localement). Pour avancer il faut :

modifier le fichier .gitlab-ci.yml,
le valider (faire un commit),
l’envoyer sur Gitlab,
patienter que la pipeline se lance (et parfois se termine),
bénéficier du résultat ou, dans la plupart des cas, recommencer à l’étape 1…

À une époque on pouvait utiliser une commande gitlab-runner exec en local. Mais celle-ci a été supprimée : https://gitlab.com/gitlab-org/gitlab-runner/-/commit/f8508c924f80b104ec7353353e6ad0edb5daae66 .

Suivant ce que nous faisons dans la CI/CD de Gitlab, il est possible d’utiliser un outil bien pratique nommé gitlab-ci-local : gitlab-ci-local.

Vous trouverez quelques détails de gitlab-ci-local sur mon recueil d’astuces.

Généralités

Voici quelques pistes intéressantes sur le sujet Gitlab :

Une documentation de départ est : https://docs.gitlab.com/topics/build_your_application/. Elle permet d’en savoir plus sur la syntaxe de gitlab-ci.yaml, les variables pré-définies ou encore le fonctionnement d’un pipeline dans Gitlab CI,
Toujours utiles : les actions que je nomme comme « globales ». Par exemple les mots clés image, variables ou before_script peuvent être utilisés en début du fichier pour définir des actions ou des valeurs qui seront utilisées dans toutes les étapes du pipeline. Ce qui peut être un avantage, ou un inconvénient. Exemple : image: ubuntu:latest va définir que toutes les étapes se lanceront dans un docker partant de l’image Ubuntu,
Entrées/sorties : un artefact = une sortie. C’est à dire des fichiers utilisables/disponibles pour les étapes suivantes (donc en entrée pour les autres étapes) en utilisant le mot clé dependencies (Cf. https://docs.gitlab.com/ci/jobs/job_artifacts/#fetching-artifacts). Sauf si dependencies = [] est utilisé.
Utiliser des variables globales en début du fichier (par exemple pour les numéros de versions) fait gagner du temps sur le long terme. Exemple :

variables:
  DOCKER_VERSION: "27.3.1"
  UBUNTU_VERSION: "24.04"

Concernant le mot clé script :
- si on veut écrire plusieurs lignes, utiliser la syntaxe suivante :
```
script:
  - echo "première étape des scripts"
  - |
    echo "première ligne"
    echo "seconde ligne"
    echo "etc."
```
- limiter à 10 lignes maximum,
- si on utilise la syntaxe pour écrire plusieurs lignes, le debug est plus difficile
Pour organiser les étapes, on peut donner à chacune d’elle une étape pré-requise en utilisant le mot clé « needs », cela permet de chaîner les étapes dans un certain ordre. Exemple : si on veut que l’étape « deploy » se fasse après « compile », alors à la fin de l’étape « deploy » on met needs: [compile].

Le Cas Docker

Création d’une image Docker… dans un conteneur Docker

Dans la situation où vous voudriez fabriquer des images Docker, vous allez être confrontés à plusieurs problématiques :

il faut utiliser des commandes docker pour créer des images,
mais la plupart des Gitlab Runner exécutent les étapes de Gitlab CI dans un Docker,
donc on se retrouve à vouloir exécuter des commandes docker dans un environnement Docker.

Vous voyez le problème ?

Pour contourner cette situation il suffit d’utiliser Docker-in-Docker.

En somme le début du fichier .gitlab-ci.yml ressemblera à :

variables:
  DOCKER_VERSION: "27.4.1"

image: docker:$DOCKER_VERSION

services:
  - docker:$DOCKER_VERSION-dind

S’identifier

Pour utiliser les dépôts de conteneurs de Gitlab, rien de plus simple il suffit d’écrire le code suivant dans le fichier .gitlab-ci.yml :

before_script:
  - docker info
  - echo "$CI_REGISTRY_PASSWORD" | docker login $CI_REGISTRY -u $CI_REGISTRY_USER --password-stdin

Nul besoin de renseigner les variables. Elles sont renseignées par Gitlab CI.

Construire l’image

Pour construire l’image cela va ressembler à :

variables:
  CONTAINER_TEST_IMAGE: $CI_REGISTRY_IMAGE:$CI_COMMIT_REF_SLUG

build-image:
  stage: build
  script:
    - docker pull "$CONTAINER_TEST_IMAGE" || true
    - docker build --build-arg BUILDKIT_INLINE_CACHE=1 -t $CONTAINER_TEST_IMAGE .
    - docker push $CONTAINER_TEST_IMAGE

On part du principe que le fichier Dockerfile est situé à la racine de votre projet Gitlab.

CONTAINER_TEST_IMAGE est une variable globale construite à partir des variables pré-définies de Gitlab CI.

Pousser l’image sur le dépôt

Dans cette situation nous sommes contents d’avoir déjà ajouté l’authentification aux dépôts de conteneurs Gitlab.

Cette fois on fait une étape pour récupérer l’image précédente et lui donner un nouveau nom :

push-image:
  stage: push
  script:
    - export IMAGE_TAG="$(date +'%Y%m%d')-${CI_COMMIT_SHORT_SHA}"
    - docker pull $CONTAINER_TEST_IMAGE
    - docker tag $CONTAINER_TEST_IMAGE $CI_REGISTRY_IMAGE:$IMAGE_TAG
    - docker push $CI_REGISTRY_IMAGE:$IMAGE_TAG
  rules:
    - if: $CI_COMMIT_BRANCH == "main"

L’idée est :

de créer un nom de tag pour l’image (variable IMAGE_TAG),
récupérer l’image précédente - puisque les étapes d’un fichier .gitlab-ci.yml s’exécutent dans des conteneurs isolés les uns des autres,
apposer un nouveau tag sur l’image récupérée,
publier le résultat en poussant l’image ainsi étiquetée.

Ceci ne s’exécute que si la branche est nommée main. Donc chaque commit sur cette branche générera une image Docker et un tag.

Ordre d’exécution des étapes

Afin que les deux étapes précédentes s’exécutent dans un certain ordre, ne pas oublier les lignes suivantes dans le fichier .gitlab-ci.yml :

stages:
  - build
  - push

Comme si ça ne suffisait pas…

En outre, voici d’autres éléments à rajouter dans son fichier .gitlab-ci.yml :

variables:
  # Use TLS https://docs.gitlab.com/ee/ci/docker/using_docker_build.html#tls-enabled
  DOCKER_HOST: tcp://docker:2376
  DOCKER_TLS_CERTDIR: "/certs"

Ces lignes permettent de renseigner un autre accès à l’API Docker pour lancer les commandes docker.

Les composants réutilisables

Gitlab CI offre la possibilité d’utiliser des composants réutilisables pour agrémenter les étapes de son fichier .gitlab-ci.yml. Ceci évite de réinventer la roue (en codant soi-même).

Plusieurs composants sont disponibles sur la page Gitlab components.

Exemple d’utilisation d’un composant :

include:
  - component: gitlab.com/components/container-scanning/container-scanning@5.1.0

C’est très utile dans certaines situations comme pour tester des fichiers Terraform (avec le composant OpenTofu), le composant Go, le composant Rust ou même utiliser les fonctionnalités Autodevops de Gitlab.

Conclusion

Au premier abord Gitlab CI paraît complexe et maigre en fonctionnalités. Cependant la lecture de la documentation (très fournie !) donne rapidement un aperçu bien plus avantageux de cet outil. On y découvre les composants réutilisables, les mots clés image, variables, before_script, les artefacts (sorties), les variables globales, le déploiement de sites statiques et j’en passe !

Certaines difficultés telles que Docker viennent s’immiscer dans nos essais. Mais une fois les obstacles franchis c’est un outil très satisfaisant. Je l’apprécie.

Je serais ravi de tomber plus souvent sur des articles décrivant ses fonctionnalités. J’espère participer à une diffusion plus grande de la connaissance Gitlab CI et, qui sait, peut-être partagerais-je prochainement d’autres astuces ?