Olivier DOSSMANN

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 ?

Mes conseils pour réussir une formation Bootcamp

Sun, 13 Oct 2024 10:14:59 +0200

Introduction

Il y a peu je commençais une formation chez DataScientest. En Bootcamp. Ce format est l’équivalent d’un temps complet (lundi à vendredi de 8h à 18h) passé sur le contenu du programme pédagogique. Durée prévue dans ma situation : 3 mois.

Ce temps est nécessaire pour apprendre les différentes notions. C’est à la fois long et court : c’est dense et le temps accordé est parfois « tout juste » pour lire. Alors comment tenir ce Marathon de 3 mois ?

J’aborderais dans un premier temps les éléments qui m’ont permis d’organiser mon plan de la semaine. Après quoi j’aborderais des sujets proches du contenu des cours comme les exercices et les examens. Finalement je donnerais des astuces diverses que j’ai listées au fur et à mesure de mon avancée dans l’aventure. Cette liste risque donc de s’allonger avec le temps !

À noter que ces conseils sont forcément emprunts de mon expérience de vie, mes compétences et mes particularités (la folie, ça compte ? 🤔)

Photo trouvée sur le profil de Aurélien Adoue sur Flickr sous Licence Attribution 2.0 Generic.

Organisation

1 mois que j’ai commencé la formation. Une durée prévue de 3 mois. Une vie à mener à côté. Des objectifs professionnels en lien avec le résultat de ce Bootcamp. Vous ne pouvez pas vous pointer les mains dans les poches.

Il est évident qu’il faut un plan. Tous les conseils pointent sur la même chose : il faut compartimenter son temps. Et s’y tenir ; oui s’y tenir. Faites-le suivant votre vie et vos possibilités. Mais tenez-y vous ! Et mettez au courant votre entourage de votre planning.

Mon planning

Dans mon cas, j’ai opté pour le planning suivant :

les matins du lundi au jeudi : lecture des nouveaux cours. Apprentissage et exercices, voire examens ;
les après-midi du lundi au jeudi : révision des cours lus les jours précédents (parfois semaines précédentes), sinon faire des exercices ;
le vendredi : mise en pratique des outils/notions appri(e)s(es) sur des projets personnels.

De cette manière la nouveauté arrive quand je suis frais, c’est à dire le matin.

Viens ensuite l’après-midi, après le repas, où je suis moins attentif que le matin. Idéal pour des révisions sur des sujets déjà abordés les jours précédents. Et cela fait une fin de journée plus tranquille que le matin.

Une révision passe par la rédaction de « fiches » de synthèse pour créer des récapitulatifs de ce qui a été vu. Parfois je dessine des cartes heuristiques : plus parlantes pour moi.

Pendant la lecture des cours je note des idées d’utilisation des outils découverts (en somme des projets qui germent dans ma tête). Ce qui me permet d’aborder le vendredi un projet réfléchi pendant la semaine. Exemple : à la lecture du contenu, j’ai noté qu’il y avait beaucoup d’abréviations. Par ailleurs, un des modules du cours apprend à utiliser un outil de création d’API. Quoi de mieux que de créer une API pour lister les abréviations ? Et hop!, un projet à faire le vendredi.

Autre exemple : on apprend le scripting Bash ? Quoi de mieux que de faire un outil pour automatiser l’installation de nos logiciels habituels sur les machines virtuelles fournies par le centre de formation ? Ou bien simplifier la vie en ajoutant des raccourcis (alias) Bash pour les commandes usuelles pendant les cours ?

On apprend la méthode ETL (Extract, Transform, Load) sur des API ? Utilisons notre API des abréviations pour extraire les données !

Que faire une fois les données extraites ? On a appris à utiliser - en bonus - SQLAlchemy (bibliothèque pour faire des requêtes sur une base de données), pourquoi ne pas l’utiliser pour insérer les données extraites de l’API pour les charger dans une base de données à nous ?

Mais en dehors de ces moments, que fais-tu Olivier ?

Hors planning

Si le planning existe, c’est pour une raison : il est nécessaire d’avoir une vie à côté ! Il faut du temps pour :

la famille (conjoint(e), enfants, parents, etc.),
des pauses,
avoir du temps à soi,
dormir,
manger,
etc.

Réellement, il FAUT ce temps pour votre famille et vous !

La famille apporte un entourage (indirectement ça peut être de la confiance en soi), les pauses un souffle pour votre cerveau, le temps à soi pour se retrouver, dormir pour ranger les informations dans votre cerveau et manger pour redonner de l’énergie à votre corps !

Chacun de ces éléments va permettre de franchir plus facilement les obstacles de votre parcours en Bootcamp. D’où le côté strict des horaires que vous vous donnez.

Ainsi après une matinée de lecture de nouveaux cours, vers midi, je m’arrête. Et je passe à autre chose : le repas, une pause et un repos allongé sur le dos pendant 10 mn environ. Avant de recommencer sur l’après-midi avec les révisions de la veille.

Après 17h ? Je m’arrête également. Je passe aux tâches quotidiennes, de la famille et du repas du soir. Un peu de détente. Un bon gros sommeil de plus de 8h.

Et la journée recommence.

Le week-end ? Pas de formation. La famille, les amis, du temps pour notre conjoint, pour soi, etc. On fait toutes ces choses qui donnent de l’énergie et remplissent notre cœur, notre corps et notre moral.

La partie organisation est très importante, elle va définir si vous aurez la tête sous l’eau ou pas. Prenez donc le temps de définir tout ça. Respectez votre planning et les personnes qui vous entourent. Par ailleurs, ce n’est qu’une seule clé parmi d’autres : pour que cela fonctionne il est nécessaire d’être efficace lors de sa période de travail. C’est ce que nous allons voir dans le prochain chapitre.

Travail efficace

Il n’y a pas de secrets selon moi, un travail efficace est déterminé par :

un environnement spécifique de travail,
une technique d’assimilation particulière,
et une façon d’agir durant les examens chronométrés.

Je vais donc vous parler de chacun des ces points en donnant quelques astuces issues d’études faites sur la question.

Point 1 : l’environnement de travail

À la lecture du livre Deep work, retrouver la concentration dans un monde de distractions écrit par Cal NEWPORT (un professeur dans les sciences informatiques du MIT - rien que ça!), j’ai bien compris qu’il fallait un environnement sans distractions.

Exit les téléphones mobiles : on le met sur mode avion. On s’enferme dans une pièce, à clé. On mobilise toutes nos ressources pour se concentrer sur la tâche à accomplir : apprendre les cours.

Toute perturbation est à proscrire et malheureusement pour certains : la musique en fait partie. Il semble que des études ont déterminé que cela activait des zones du cerveau qui empêchent une concentration complète.

L’idée du livre « Deep work » est que si vous êtes concentrés vous prendrez moins de temps à travailler. Ce qui me semble tout à fait adapté pour une formation en Bootcamp, n’est-ce pas ?

Point 2 : assimiler les cours

Là encore, les scientifiques ont étudié la question. Et c’est au travers d’une vidéo de Science étonnante concernant les (vraies) techniques pour mieux apprendre et étudier que j’ai pu améliorer mon apprentissage.

Je vous conseille de regarder la vidéo - YouTube - et d’imaginer une nouvelle façon d’étudier, de réviser et de travailler.

De mon côté j’ai opté pour la relecture régulière, la lecture de plusieurs cours qui font souvent des liens sur le domaine étudié et la mise en pratique par des cas concrets de la vie courante pour s’entraîner avec les outils étudiés. J’en parlais tout à l’heure : la création d’une API, l’extraction des données de cette dernière pour les introduire ensuite dans une autre base de données sous un autre format.

À noter que plus loin dans cet article je vous demanderais de ne pas suivre de vidéos YouTube pendant vos études Bootcamp, je ne suis pas schizophrène : considérez cette vidéo comme l’exception qui confirme la règle 😃 .

Point 3 : les examens

Certains examens sont chronométrés. Ce qui peut très vite être déstabilisant !

Je propose plusieurs choses pour s’en sortir :

Rien de mieux que la préparation : si vous avez fait les cours régulièrement et que vous avez révisé 1 jour après, 2 jours après, 1 semaine après, vous retiendrez bien mieux les cours ;
Faites des exercices avant et sentez-vous un minimum à l’aise, travaillez les points sensibles ;
Lors des examens : ouvrez en avance les documentations qui vous aident ;
Dans les examens, optez pour des noms de variables courts : plus vous rallongez le nom des fonctions et des variables, plus vous aurez à taper du code. Indirectement vous prenez un temps fou pour rédiger au lieu de réfléchir !
Pour les examens, préparez déjà à côté vos codes sur le sujet : c’est votre code, celui qui vous ressemble. Rien n’interdit un copier-coller de votre propre travail !

Avec ces 3 points, vous devriez déjà avoir de bonnes bases pour aborder la formation. Il y a d’autres astuces diverses que nous allons découvrir maintenant.

Diverses astuces

Ne sachant dans quelles catégories mettre ces astuces, mais considérant ces dernières comme tout aussi importantes, je vous les dépose là. Piochez selon vos envies ;)

Revoyez chaque semaine le planning que vous allez suivre : quel cours étudier chaque jour. Prenez en compte les sujets sur lesquels vous avez déjà des connaissances pour passer plus de temps sur ceux que vous ne connaissez pas ;
Ne prenez des notes qu’à une seconde lecture (lors de révisions par exemple) : sinon vous allez passer trop de temps sur un cours ;
Si vous avez un souci logiciel qui empêche de travailler : passez à autre chose !
Quand vous revenez sur un souci logiciel - plus tard - si vous ne réussisez pas mieux, utilisez ChatGPT pour décrire votre problème. Cet outil est plutôt efficace pour donner des pistes. Rappelez vous, ChatGPT est un assistant, vous le dirigez. Ce n’est pas lui qui doit vous diriger. ;
N’utilisez pas de vidéos pour apprendre - YouTube ou autre - c’est une perte de temps considérable. Pourquoi ? Tout simplement car vous ne pourrez pas voir rapidement si la vidéo vous apporte quelque chose de concret ou non. Et parfois ce qu’ils disent est tout bonnement faux ! Cela vous apporte plus de confusion qu’autre chose. En revanche chez DataScientest ils ont des vidéos de cours. Cela apporte généralement quelque chose de concret et de vrai ;
Lisez de la documentation des outils utilisés : elles ne mentent pas. Elles décrivent. Et peut-être retiendrez-vous des options qui vous feront gagner plus tard un temps fou !
Restez humbles : même si vous maîtrisez un sujet, vous trouverez souvent des nouveautés et des détails que vous ne connaissiez pas dans les cours ;
Si vous avez la possibilité, apprenez à utiliser des dépôts Git rapidement pour enregistrer votre travail sur les machines virtuelles distantes proposées par la formation. Cela vous évitera de mauvaises surprises quand les machines se réinitialisent…

Si jamais je trouve d’autres astuces je les rajouterai ici.

Conclusion

Cette formation m’a permis de travailler mon environnement, mes méthodes de travail et découvrir des astuces pour être plus efficace en journée. Et cela sans mettre de côté la famille et la maison. Ce qui donne de l’énergie pour continuer chaque semaine de travailler.

C’est un cercle vertueux que je conseille à chacun pour améliorer son quotidien et être plus productif.

Je souhaite de tout cœur que chacun trouve son équilibre dans sa vie et réussisse sa formation en Bootcamp. Bonne chance à vous et bon travail !

Cookiecutter-trognon pour initialiser mes scripts Bash

Sun, 28 Apr 2024 13:20:47 +0200

Introduction

Pour la petite histoire, l’année dernière je lisais l’article de deblan sur la création d’un modèle de script Shell sur le journalduhacker. Cela m’a rappelé que tôt ou tard dans la quête de l’automatisation on arrive toujours à faire nos propres modèles de scripts.

La plupart de mes projets utilisent le modèle de script Trognon.

Comment, en partant de ce modèle, pourrais-je automatiser la création de nouvelles commandes ? C’est là qu’entre en jeu cookiecutter, une commande et une méthode permettant de transformer n’importe lequel de vos projet en template pour les suivants !

Nous commencerons par voir le résultat de l’adaptation d’un script avec cookiecutter. Ensuite nous verrons ce qu’est cookiecutter. Finalement nous expliquerons comment adapter son projet avec cookiecutter en présentant le cas pratique de cookiecutter-trognon.

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

Le résultat : cookiecutter-trognon

Pour une fois nous commencerons par la fin, c’est à dire le résultat ! L’automatisation de Trognon a donné un dépôt : cookiecutter-trognon.

Grâce à lui, créer un nouveau script Bash suivant le modèle de Trognon revient à taper les commandes suivantes :

# Installe cookiecutter sur notre machine (à ne faire que la première fois)
pipx install cookiecutter
# Utilise mon dépôt Github de cookiecutter-trognon comme modèle
cookiecutter gh:blankoworld/cookiecutter-trognon

Ensuite 2 questions sont posées pour définir :

le nom du dossier dans lequel ma commande se trouvera
le nom souhaité pour la commande

Évidemment j’ai défini les questions à poser et ce que je faisais des réponses dans le résultat. C’est là tout l’intérêt de cookiecutter : vous définissez les questions à poser, les réponses possibles s’il en est, quoi faire des réponses et où les utiliser dans vos templates.

Voyons donc cookiecutter.

Présentation de cookiecutter

cookiecutter est un outil Python qui duplique un répertoire, vous pose des questions et modifie le duplicat en remplaçant certaines chaînes de caractères par les réponses données aux questions.

Il sait agir de manière conditionnelle : c’est-à-dire qu’il peut aussi ajouter/enlever des pans de code/texte en fonction de la valeur d’une variable. Ceci grâce au moteur de template Jinja.

Autrement dit : vous définissez les fichiers dont vous avez besoin (parfois un copier/coller suffit), puis vous insérez dans vos fichiers des chaînes de caractères que vous souhaitez remplacer dans le projet. Vous pouvez également définir des valeurs conditionnelles. Par exemple : si je souhaite avoir une licence MIT, alors le fichier LICENSE contiendra un certain texte. Si je choisis la licence LPRÀB/WTFPL, alors j’aurais un autre texte.

Un exemple concret serait plus parlant, essayons avec cookiecutter-trognon !

Comment transformer Trognon en cookiecutter-trognon ?

En rapide

Pour rendre un projet compatible avec cookiecutter, il va falloir suivre quelques étapes clés :

Créer un nouveau répertoire pour votre projet,
Y créer un fichier nommé cookiecutter.json,
Créer un répertoire nommé {{ cookiecutter.project_slug }} (oui oui, AVEC les accolades),
Déposer les fichiers nécessaires au projet dans le répertoire {{ cookiecutter.project_slug }},
Remplacer dans les fichiers tous les mots à adapter à chaque nouveau projet : pour cela utiliser les mots clés fournis dans le fichier cookiecutter.json (variables).

Dans le cas de Trognon, j’ai déposé les fichiers du projet dans le répertoire {{ cookiecutter.project_slug }}.

cookiecutter.json, la configuration du projet

J’ai ensuite rempli le fichier cookiecutter.json tel que montré ici :

{
  "project_name": "Mon projet",
  "__project_slug": "{{ cookiecutter.project_name.lower().replace(' ', '_').replace('-', '_') }}",
  "command_shortname": "CommandePrincipale",
  "__command_slug": "{{ cookiecutter.command_shortname.lower().replace(' ', '_').replace('-', '_') }}",
  "__prompts__": {
    "project_name": "Choisissez un nom de projet court",
    "command_shortname": "Que voudriez-vous comme nom court de commande ?"
  }
}

Je défini des variables comme :

project_name : le nom du projet, avec comme valeur par défaut Mon projet,
command_shortname : le nom de la commande Bash que nous utiliserons.

D’autres variables ne demanderont rien à l’utilisateur car elles commencent par deux espaces soulignes __. Je parle bien entendu de __project_slug, __command_slug et __prompts__.

Cependant __prompts__ a une particularité : il permet de personnaliser la question posée pour chaque variable.

Ainsi pour définir project_name, l’utilisateur verra la question suivante : Choisissez un nom de projet court.

Remplacer des mots par des variables

Maintenant que le fichier cookiecutter.json possède des mots clés spécifiques (des variables), nous allons pouvoir modifier les fichiers de notre projet pour contenir des « mots-clés ». Par exemple voici le début du fichier README.md de Trognon (AVANT modifications) :

# Trognon

Un lanceur de commandes personnalisées pour votre projet de développement.

Exemple : 

# Affiche l'aide
./agnes help

# Installe votre projet (vous devez définir ce que `install` fait)
./agnes install

# créé un dump de la base de données
./agnes dump

Ce qui donne le fichier README.md suivant dans notre projet cookiecutter-trognon (APRÈS modifications) :

# {{ cookiecutter.project_name }}

Un lanceur de commandes personnalisées pour votre projet de développement.

Exemple : 

# Affiche l'aide
./{{ cookiecutter.__command_slug }} help

# Installe votre projet (vous devez définir ce que `install` fait)
./{{ cookiecutter.__command_slug }} install

# créé un dump de la base de données
./{{ cookiecutter.__command_slug }} dump

Nous avons ainsi remplacé respectivement le titre du fichier et les commandes d’exemple en {{ cookiecutter.project_name }} et {{ cookiecutter.__command_slug }}.

Vous pouvez en savoir plus sur la documentation officielle de cookiecutter.

Conclusion

J’espère qu’à travers cet article vous aurez compris l’avantage d’utiliser cookiecutter et que vous envisagerez à l’avenir de l’intégrer dans votre processus d’automatisation de la génération initiale de vos projets et de vos scripts.

L’informatique énonce souvent d’éviter de réinventer la roue ; je pense que cookiecutter est l’outil indispensable pour favoriser ce concept.

Une fois ce processus de création automatisé, vous vous rendrez compte que vous générerez plus souvent des scripts/projets, que vous vous concentrerez uniquement sur le contenu du projet et pas sur tout l’environnement autour : c’est un gain de temps et de qualité ! Une belle valeur ajoutée en somme.

Vers quelle console se tourner en 2024 ?

Wed, 10 Apr 2024 16:24:18 +0200

Introduction

Après plusieurs échanges similaires avec des amis, il était temps de lister ce que je trouve intéressant et/ou problématique dans chacune des 3 consoles suivantes :

Nintendo Switch (Switch)
Microsoft Xbox Serie X (Xbox)
Sony Playstation 5 Standard FAT (PS5)

Ceci est mon avis, cela représente ce que je pense sur ces dernières. Il reste à chacun de juger selon lui et suivant ses infos.

Je regarde essentiellement le coût de ces consoles et ce que nous avons à disposition. Si vous détestez voir des chiffres défiler, arrêtez la lecture de cet article 😉. Par ailleurs chaque console représente un écosystème entier, il est difficile d’être réellement objectif dans leur comparaison, tant ils sont différents.

Alerte spoiler : Cet article sera long.

Photo trouvée sur le profil de Aurélien Adoue sur Flickr sous licence CC BY 2.0.

Avant de commencer

Dans cet article je comparerais plusieurs éléments comme :

le prix d’achat de la console
l’abonnement pour bénéficier de sauvegardes de ses parties (et parfois l’accès à un catalogue de jeux)
la quantité de jeux disponibles (la variété du catalogue de jeux vidéos par exemple)
le prix des jeux d’occasion, ce qui permet d’estimer l’accès aux jeux pour les petits budgets
les problèmes matériels connus qui peuvent engendrer un rachat de la console ou bien des accessoires
le prix d’une manette

Je cherche plus ou moins à savoir ce qui pourrait - économiquement parlant - être plus accessible. Autrement dit sur quelle console pourrais-je estimer pouvoir dépenser le moins d’argent par an pour jouer et renouveler mon catalogue de jeux joués ? Évidemment les prix fluctuent beaucoup, notamment pour les consoles PS5 et Xbox qui varient parfois de 50€ à 100€. À vos calculatrices !

Nous commencerons avec la Nintendo Switch, puis la Microsoft Xbox Serie X et enfin la Sony Playstation 5 Standard FAT. Ce sont 3 consoles que j’ai eu en main, que j’ai pu tester et où j’ai pu expérimenter quelques éléments entre 2 et 5 ans (suivant les consoles).

J’insiste sur les modèles disposant d’un compartiment pour accueillir les jeux vidéos (lecteur DVD, slot pour des cartouches de jeu, etc.) car cela permet d’avoir accès à des jeux d’occasion (donc coûter moins que les jeux neufs).

Les 3 modèles visés/testés se branchent au minimum sur une télévision.

On part du principe qu’on joue environ 500 heures par an, c’est à dire environ 1h30 par jour. Si les jeux prennent une cinquantaine d’heures à finir, on consommerait 10 jeux par an. Tout ceci est relatif et doit bien être pris en compte dans vos calculs. C’est intéressant de faire le calcul pour soi, histoire de voir si le jeu vidéo est un loisir très dépensier dans VOTRE budget. Mine de rien, ça consomme de l’argent tout cela, comme nous le verrons ci-après !

Nintendo Switch

Les chiffres

Commençons par la plus ancienne console sur le marché : la Nintendo Switch.

Prix d’achat (sur Amazon) : ~ 250€
Prix abonnement annuel minimum : ~ 20€
Avantage abonnement : jeux NES, SNES et Gameboy (color) (~ 30 jeux)
Abonnement familial : ~ 35€
Manettes disponibles à l’achat : 2 (gauche et droite, même si petites)
Particularité : utilisable en console portable, prend peu de place (~ 3h30 d’autonomie)
Prix d’un jeu neuf : ~ 50€
Prix du même jeu en occasion : ~30 (varie en fonction des régions et de l’interlocuteur + capacité à discuter le prix)
Prix d’une manette (simple) : ~ 45€ à l’unité, ou ~ 65€ les deux

Photo trouvée sur le profil de Sinchen.Lin sur Flickr sous licence CC BY 2.0.

Avantage(s)

L’avantage principal de cette console : elle est aussi portable. C’est à dire qu’elle s’enlève du socle de la télévision pour être utilisable partout dans la maison (ou ailleurs). Sa batterie tient au moins 3h30.

Elle est relativement petite pour une console de salon, ce qui fait un gain de place.

Le catalogue des jeux est un des plus riches et des plus complets. Avec des jeux variés : il y en a pour tous les goûts ! Certaines exclusivités d’autres consoles sont portés sur la Nintendo Switch, ce qui est très plaisant.

Inconvénient(s)

Du fait de la « petitesse » de cette console, il y a une limitation sur le matériel embarqué, notamment pour ce qui est du refroidissement de la carte graphique. Ceci implique des graphismes moins proches de la réalité (comparé à d’autres consoles).

Cependant sachez qu’au lieu de se concentrer sur la parfaite illusion de réalité dans les jeux vidéos, les concepteurs de jeu peuvent s’atteler à la jouabilité.

Autre point négatif : le problème connu dit du « Joy-Con Drift ». Après un certain temps d’utilisation, il arrive que la manette gauche pose problème : le personnage que vous dirigez dans le jeu bouge tout seul. Bien que ce soit problématique, au lieu de racheter une manette il existe une solution « maison » tel que vous pouvez le lire dans l’article expliquant la solution avec… un bout de carton ! Cette solution ne fonctionnera pas avec une Nintendo Switch Lite dont les manettes ne sont pas détachables.

Au minimum (sans jeux)

1^ère année : 270€ (250€ HA + 20€ abonnement simple)
années suivantes : 20€ (20€ abonnement simple)

Au minimum (avec HA de jeux)

1^ère année : 770€ (250€ HA + 20€ abonnement simple + 10 jeux neufs × 50€)
années suivantes : 520€ (20€ abonnement simple + 10 jeux neufs × 50€)

Minimum familial

1^ère année : 785€ (250€ HA + 35€ abonnement familial + 10 jeux neufs × 50€)
années suivantes : 535€ (35€ abonnement familial + 10 jeux neufs × 50€)

Au maximum (familial + pack additionnel à 70€/an)

Avec le pack additionnel vous avez, en plus des jeux NES, SNES et GameBoy (color), un accès à :

des jeux GameBoy Advance
des jeux Nintendo 64
des jeux Mega Drive

Ainsi :

1^ère année : 320€ (250€HA + 70€ abonnement familial + pack additionnel)
années suivantes : 70€ (70€ abonnement familial + pack additionnel)

Conclusion intermédiaire - Switch

On notera :

la différence négligeable entre abonnement simple et familial : très rentable quand nous sommes plusieurs à la maison (même avec chacun une console)
le pack aditionnel (abonnement supplémentaire) permet de jouer à des jeux rétros mais pas avec des jeux modernes
le catalogue (Nintendo eShop) est large, varié, avec des réductions fréquentes de 80% sur de bons jeux
vous jouez sur la TV et quelqu’un de la famille voudrait regarder la TV ? Pas de souci : vous enlevez la console du socle et pouvez continuer votre partie ailleurs. Le côté portable de cette console est très pratique !

La Nintendo Switch est donc une console bas prix avec beaucoup de possibilités !

Microsoft Xbox Série X

Les chiffres

Prix d’achat (sur Amazon) : ~ 550€
Prix abonnement annuel minimum : ~ 84€ (7€ × 12 mois)
Avantage abonnement : petit catalogue de jeux (~ 25 jeux)
Abonnement familial : aucun
Manettes disponibles à l’achat : 1
Particularité : prend peu de place, même debout
Prix d’un jeu neuf : ~80€
Prix du même jeu en occasion : ~40 (varie en fonction des régions et de l’interlocuteur + capacité à discuter le prix)
Prix d’une manette : ~ 60€

Photo trouvée sur le profil de ru3ch initiative sur Flickr sous licence CC BY 2.0.

Avantage(s)

console puissante, ce qui permet d’accéder à des images plus fines et proches de la réalité
esthétique de la console, tout en prenant peu de place ET passe inaperçue dans le salon (vous ne passerez pas pour un gosse en soirée 🤣).
tout repose sur l’abonnement au Game Pass : accès illimité pour 11€/mois à une quantité incroyable de jeux. Vous trouverez toujours votre bonheur.
accès dès le premier jour à des jeux dès leur sortie (Halo, Starfield, Sea of thieves, etc.)

Inconvénient(s)

le budget d’achat initial est conséquent (550€)
jeux neufs très chers
pour jouer en ligne : abonnement nécessaire (7€/mois minimum)

Au minimum (sans jeux)

1^ère année : 634€ (550€ HA + 84€ abonnement)
années suivantes : 84€ (84€ abonnement)

Au minimum (avec HA de jeux)

1^ère année : 1434€ (550€ HA + 84€ abonnement + 10 jeux neufs × 80€)
années suivantes : 884€ (84€ abonnement + 10 jeux neufs × 80€)

Au maximum (abonnement Game Pass Console à 11€/mois)

Avec l’achat d’un abonnement - complet - donnant accès à un catalogue de plus de 100 jeux vidéos, soit 11€ × 12 mois = 132€. Ceci enlève le besoin d’avoir 10 jeux neufs par an…

1^ère année : 682€ (550€ HA + 132€ abonnement Game Pass Console)
années suivantes : 132€ (132€ abonnement Game Pass Console)

Conclusion intermédiaire - Xbox X

Le catalogue de jeux vidéos du Game Pass Console (à 11€/mois) donne non seulement accès à beaucoup de jeux vidéos, mais il permet en plus d’accéder à la plupart des sorties de jeux vidéos dès le premier jour !

C’est ce qui fait toute la force de cette console : tant que le Game Pass Console existe, l’accès à des jeux vidéos coûte 132€ par an - excepté toute modification du prix évidemment.

Si vous consommez plus de 2 jeux par an, la Xbox Serie X sera très rentable dès les premières années.

En revanche, je trouve que sans l’abonnement Game Pass Console (11€/mois), la console est coûteuse. Cela revient à acheter une brique de 550€ à poser dans le salon sans jamais y toucher, avec des jeux horriblement chers.

Sony Playstation 5 FAT

Les chiffres

Prix d’achat (sur Amazon) : ~ 525€
Prix abonnement annuel minimum : ~ 72€
Avantage abonnement : 3 jeux par mois (~ 36 jeux sur l’année)
Abonnement familial : aucun
Manettes disponibles à l’achat : 1
Particularité : très puissante pour les graphismes
Prix d’un jeu neuf : ~80€
Prix du même jeu en occasion : ~40 (varie en fonction des régions et de l’interlocuteur + capacité à discuter le prix)
Prix d’une manette : ~ 70€

À noter : Le prix d’une Playstation 5 SLIM est quasi similaire (525€).

Avantage(s)

console puissante, ce qui permet d’accéder à des images plus fines et proches de la réalité
la plupart des jeux PS4 fonctionnent sur cette console avec une amélioration graphique
rapidité de chargement des niveaux, grâce à un disque dur SSD embarqué

Inconvénient(s)

le budget d’achat initial est conséquent (525€)
jeux neufs très chers
pour jouer en ligne : abonnement nécessaire (6€/mois minimum)
le DualSense Drift de la manette de PS5 qui réduit la durée de vie d’une manette à 417h, soit environ 7 mois d’utilisation (à raison de 2h par jour) - sans possibilité de réparation pour le moment
un potentiel problème de liquide de refroidissment sur la PS5 ? sur une petite partie des consoles
prend une place monstrueuse au salon

Au minimum (sans jeux)

1^ère année : 597€ (525€ HA + 72€ abonnement)
années suivantes : 72€ (72€ abonnement)

Au minimum (avec HA de jeux)

1^ère année : 1397€ (525€ HA + 72€ abonnement + 10 jeux neufs × 80€)
années suivantes : 872€ (72€ abonnement + 10 jeux neufs × 80€)

Au maximum (abonnement Premium à ~152€/an)

L’abonnement Premium donne accès à un bon catalogue de jeux vidéos. Cependant vous n’aurez pas accès aux sorties des jeux vidéos : il faudra patienter quelques années à chaque fois.

1^ère année : 677€ (525€ HA + 152€ abonnement Premium)
années suivantes : 152€ (152€ abonnement Premium)

Conclusion intermédiaire - PS5

Se tourner vers cette console paraît curieux, à moins que vous n’êtes un grand fan de Playstation - comme je l’ai été de la PS1 à la PS4 - et que vous appréciez à la fois la qualité d’image et des jeux en exclusivité sur cette console.

En effet, malgré la qualité des jeux vidéos (souvent à 1 seul joueur), ces jeux ont un prix élevé. On se tournerait alors vers l’abonnement premium (152€/an) qui est « rentable » si vous consommez plus de 2 jeux par an.

Cependant l’abonnement Premium ne permet pas d’accéder régulièrement à des nouveautés (comprendre des jeux qui viennent de sortir), il y a une forme de patience à avoir.

Si vous achetez 1 jeu neuf et l’abonnement pour jouer en ligne, cela vous revient au prix de l’abonnement Premium.

Au final il bien trop d’inconvénients à cette console pour si peu d’avantages comparé à la concurrence : que se passe-t-il chez Sony ? 🤔

Récapitulatif des chiffres

	Switch	Switch OLED	Switch Lite	Xbox S	Xbox X	PS5 FAT	PS5 Slim	PS5 Digital Slim
Achat	250 €	300 €	200 €	300 €	550 €	525 €	550 €	450 €
Abonnement	20 €	20 €	20 €	84 €	84 €	72 €	72 €	72 €
Abo. Familial (switch)	35 €	35 €	35 €	Aucun	Aucun	Aucun	Aucun	Aucun
Game Pass Console (xbox)	Aucun	Aucun	Aucun	132 €	132 €	Aucun	Aucun	Aucun
Abo. Premium (PS5)	Aucun	Aucun	Aucun	Aucun	Aucun	152 €	152 €	152 €
Jeu neuf	50 €	50 €	50 €	80 €	80 €	80 €	80 €	80 €
Jeu occasion	30 €	30 €	30 €	40 €	40 €	40 €	40 €	40 €
Manette	45 €	45 €	45 €	60 €	60 €	70 €	70 €	70 €
Totaux :
1^ère année (HA + abo)	270 €	320 €	220 €	384 €	634 €	597 €	622 €	522 €
Nbre jeux rentabilité (Abo)	0,4	0,4	0,4	1,05	1,05	0,9	0,9	0,9
1^ère année (HA + abo. Prem/Fam/Console)	285 €	335 €	235 €	432 €	682 €	677 €	702 €	602 €
Nbre jeux rentabilité (HA + abo. Prem/Fam/Console)	0,7	0,7	0,7	1,65	1,65	1,9	1,9	1,9
Si budget de 700€ :
Nbre jeux neufs rentabilité (Abo)	8,60	7,60	9,60	3,95	0,83	1,29	0,98	2,23
Nbre jeux neufs rentabilité (Abo. Prem/Fam/Console)	8,30	7,30	9,30	3,35	0,23	0,29	-0,03	1,23

2 possibilités la première année :

achat de la console et abonnement simple (HA + abo),
ou achat de la console avec l’abonnement « intéressant » : Premium pour PS5, Familial pour Switch et Game Pass Console pour Xbox (HA + abo. Prem/Fam/Console).

Ensuite, pour chacune des possibilités nous calculons le nombre de jeux gratuits à consommer sur l’abonnement pour arriver à rentabilité ; en comparaison au prix de jeux neufs donc. Le calcul est : prix de l’abonnement à l’année divisé par le prix d’un jeu neuf.

Finalement les deux dernières lignes calculent le nombre de jeux neufs qu’on peut acheter ((700 - prix HA - abonnement choisi) ÷ prix jeu neuf) si on avait un budget initial de 700€. Et cela dans deux situations :

avec un abonnement simple,
avec un abonnement premium/familial/console tel qu’évoqué ci-avant.

Notez que si le chiffre est négatif alors il faudra ajouter un peu d’argent pour acheter un jeu.

Conclusion

Après avoir traité chaque console en étudiant son prix, les abonnements possibles, ce à quoi nous avons accès, les problèmes matériels éventuels et le prix des jeux neufs et d’occasion, je pense qu’on peut imaginer quelques types de public pour chacune des consoles.

À mon sens les petits budgets se tourneront vers la Nintendo Switch pour 270€ (HA console + abonnement simple), ce qui permettra d’accéder à des jeux NES, SNES et GameBoyColor, le temps de regarder sur l’eShop (magasin virtuel) pour acheter des jeux à bas prix (soit à plus de 80% de réduction, soit pour petits budgets), il y a même des jeux gratuits comme des courses de voiture, des combats de Pokémon, etc. C’est une bonne entrée en matière avec une souplesse « console de salon » vs. « portable ».

Si, pour vous, la qualité d’image doit se rapprocher de la réalité dans les jeux vidéos, sachez qu’on passe du simple au double avec la Xbox Serie X et la PS5 FAT aux alentours de 500€. À ce prix là, il faut tout de même prendre un abonnement pour les jeux en ligne, pour une copie des sauvegardes des jeux, etc. Et là on douille : c’est plus de 70€ par an (soit quasiment le prix d’un jeu). Vu le prix des jeux sous ces consoles, il est clair que pour 132€/mois avec le Game Pass Console, c’est rentable en moins de 2 jeux par an ET avec un catalogue de plus de 100 jeux ET des nouveautés. C’est donc la Xbox Serie X avec abonnement Game Pass Console que vous devriez vous tourner.

Malheureusement la PS5, avec ses problèmes de manettes, un abonnement qui ne donne accès qu’à peu de jeux, va être plus coûteuse sur le long terme. Deux raisons pourraient justifier, selon moi, l’achat et l’utilisation de la console :

accéder à des jeux en exclusivité sous PS5 (comme God of War, Horizon Forbidden West, Kena : bridge of spirit, Ratchet & Clank, etc.). Mais là encore les jeux deviennent disponibles sur PC généralement (plateforme Steam par exemple)
améliorer les performances de nos jeux PS4 et passer à une console plus moderne

Au final je ne conseillerais que 2 consoles (suivant les budgets) - alors que je suis pourtant un grand fan des consoles Sony :

la Nintendo Switch pour les petits budgets et une utilisation plutôt familiale (jeux à plusieurs, jeux « good vibes » simples, etc.), elle permet l’accès à des jeux rétros Nintendo (NES, SNES, GameCube, Mega Drive, Nintendo 64, etc.),
la Xbox Série X pour des budgets plus conséquents avec l’abonnement Game Pass Console (11€/mois) pour accéder régulièrement à des nouveautés, des jeux variés et récents et le plaisir des yeux niveau qualité d’image.

Ma préférence, quitte à payer un abonnement mensuel, est d’utiliser le Game Pass Console sur la Xbox Série X pour pouvoir tester plusieurs jeux dès leur sortie. Et d’éventuellement acheter lesdits jeux en occasion dès que le prix me convient (pour les finir ou les garder à la maison).

Sachez que, quoiqu’il arrive, dès que vous souhaitez jouer en ligne, la plupart des consoles vous amèneront à prendre un abonnement minimal pour cela… Une console de jeu est finalement un budget à part entière de nos jours !

Ordinateur portable Xiaomi Book Air 13 (version 2022)

Fri, 01 Dec 2023 21:17:01 +0200

Edit : article rédigé et publié ultérieurement (courant 2024). La date du 1er décembre représente approximativement l’arrivée de l’appareil dans le foyer.

Présentation

2024, écologiquement parlant nous devrions faire durer un ordinateur un minimum de 5 à 7 ans ! Mon dernier achat d’ordinateur portable était en décembre 2018, il y a exactement 5 ans ! C’était un Xiaomi Mi Notebook Air 13.3 (version 2017).

Techniquement il fonctionne encore très bien. C’est pourquoi je l’ai donné à quelqu’un (en installant Windows 10 dessus, berk!). Je n’avais pas à en racheter un.

Seulement voilà, les habitudes ont la vie rude ! Le confort de la mobilité (travail à l’extérieur, déplacements et utilisation dans différentes pièces de la maison) me manquait énormément.

C’est ainsi que mon côté technophile a eu raison de moi : j’ai fais l’acquisition d’un Xiaomi Book Air 13 (version 2022).

Description du produit

Le Xiaomi Book Air 13 (version 2022) possède les caractéristiques suivantes :

un processeur Intel Core i5-1230U (12e génération, 10 cœurs, 12 threads, jusqu’à 4.40Ghz)
une mémoire vive de 16 Go de RAM LPDDR5 cadencé à 5200 Mhz
un disque dur SSD de 512Go
une carte graphique intégrée Intel Iris Xe graphics
une batterie de 12 heures d’utilisation et 1 à 2h de charge
un écran 13 pouces 360° OLED tactile avec une résolution 2.8K
un lecteur d’empreinte
Bluetooth 5.2
Wifi 6E
2 prises USB 3 de Type C Thunderbolt
une prise jack
poids de 1,3 kg
épaisseur de 12 mm

Il n’y a pas de ventilation ni d’aération : vous n’entendrez jamais tourner cet ordinateur.

Mes impressions

Cet ordinateur, en plus d’avoir de bonnes caractéristiques pour l’année 2022, ressemble à un véritable bijou : il est brillant, présenté comme une parure qu’on mettrait sur soi.

Il est pratique : très léger, très maniable (se plie même en mode tablette, c’est dire !) et tient longtemps (entre 10h et 12h d’autonomie). Il est très impressionnant.

Cependant sans le stylo spécifique (non fourni par Xiaomi) de cet ordinateur, l’écran tactile n’est pas très utile. Au contraire : il me pose problème régulièrement. Sans doute ne suis-je pas habitué aux écrans taciles. Par contre plier l’ordinateur et le poser comme un écran de TV est pratique !

Étant donné qu’il est silencieux, car aucune ventilation, on pourrait s’attendre à ce qu’il chauffe énormément. Mais ce n’est pas le cas. Il chauffe, certes, mais avec l’assemblage aluminium tout autour cela passe très bien.

Je regrette qu’il soit si fin et donc quasiment pas réparable : si la moindre pièce venait à tomber en panne, il faudrait quasiment changer l’ordinateur portable entier. Cela m’embête un peu.

On notera également un écran avec une définition et des couleurs à couper le souffle ! Et surtout un peu compliqué à configurer pour moi sur ArchLinux car la résolution était tellement grande qu’il a fallu déterminer un ratio d’aggrandissement. J’ai ri - de honte 😉.

A contrario je déplore le manque d’informations pour savoir comment faire fonctionner la Webcam sur GNU/Linux pour cette machine. Impossible pour le moment 🤷.

Conclusion

Je dois dire que cet ordinateur est un objet de très bonne facture. Avec du matériel à la hauteur, de bonnes caractéristiques techniques, léger, pratique et silencieux. Et pas cher pour ce que c’est !

Pourtant le côté peu réparable, un écran tactile - presque - inutile et une webcam ne fonctionnant pas sous GNU/Linux, m’ont légèrement irrité.

Je pense ne pas garder cet ordinateur portable longtemps et le revendre dès que j’aurais trouvé un ordinateur qui me seille bien plus.

La Genèse d'un projet

Wed, 13 Sep 2023 12:13:23 +0200

Il y a quelques temps je lançais un billet sur le projet Gachette qui permet de publier mon blog. Dans la même lancée je souhaite aujourd’hui vous présenter un autre projet sur lequel je travaille de temps en temps : Genèse. Genèse est assez difficile à définir. Cependant je l’imagine comme une commande unique pour permettre à plusieurs développeurs de travailler sur un environnement commun et en lançant une instance par ticket/problème relevé.

Cet outil, bien qu’il soit utile et facile à utiliser, demande un minimum d’explication pour comprendre à la fois le concept et l’utilité réelle.
C’est pourquoi je vais avant tout poser la problématique principale qui a initiée le projet, puis montrer quelques usages intéressants qui sont plus parlants et finalement tenter d’expliquer son fonctionnement en interne.

Photo trouvée sur le profil de Damian Gadal sur Flickr sous licence CC BY 2.0.

Ce qui a initié le projet

De nombreuses années d’expérience professionnelle dans le domaine informatique m’ont amené à rencontrer plusieurs problèmes et à réfléchir sur énormément de sujets.

L’un d’eux se porte sur l’environnement de travail : je parle de l’environnement système utilisé pour travailler sur un projet. J’ai relevé quelques éléments intéressants, similaires à des postulats :

on essaie souvent de se rapprocher de l’environnement système de la production : ceci pour repérer assez tôt d’éventuels problèmes
plus l’environnement entre collègues est similaire, mieux nous travaillons : si un collaborateur rencontre un problème il peut se tourner vers le reste de l’équipe pour avoir de l’aide
nous en arrivons souvent à faire un fichier docker-compose.yml pour cela : peut-être est-ce initialement plus facile de partager un fichier léger (docker-compose.yml) qu’une machine virtuelle entière ?
quand on nouveau collaborateur arrive dans l’équipe, il a pas mal de choses à apprendre sur le projet. Et il peine souvent - en plus de toutes les choses à apprendre - à devoir installer l’environnement initial
on utilise souvent un fichier docker-compose.yml très proche entre plusieurs projets : ce qui est normal puisqu’on utilise très souvent des technologies similaires qu’on maîtrise pour les vendre à nos clients
on travaille souvent sur plusieurs tickets, c’est à dire plusieurs problèmes émis par le client. Chaque fois que nous démarrons un nouveau ticket, dans l’idéal, nous devrions avoir un environnement sain et propre pour ne pas avoir de fioritures de nos travaux précédents

En discutant avec Richard Dern (qui a d’ailleurs fait une refonte de son site web avec un nouveau moteur de blog), nous avons réfléchi à un outil capable de résoudre plusieurs de ces problématiques. Le fil rouge était :

les environnements doivent rester isolés : utilisation d’un fichier docker-compose.yml pour générer un environnement
création d’un répertoire unique pour chaque nouveau ticket/projet/autre afin de garder quelque chose de sain et propre
éviter de devoir se répéter entre plusieurs projets : mettre en commun les éléments qui le peuvent, comme par exemple le type de base de données
permettre à plusieurs utilisateurs de travailler sur la même machine : nommage des environnements d’une manière particulière (avec le nom de l’utilisateur par exemple)
permettre à chaque développeur de personnaliser son environnement : par exemple s’il souhaite avoir une interface web pour la base de données, qu’il puisse rajouter l’outil qu’il souhaite
si nous travaillons sur 2 tickets d’un même projet, sachant que l’environnement est similaire pour un même projet, ces deux environnements doivent pouvoir exister en même temps : s’ils utilisent les mêmes ports d’adresses, cela va échouer. Il faut donc des ports aléatoires.
si les ports sont aléatoires, alors il faut un accès facile à chacun des environnements, par exemple à l’aide d’une interface Web commune à tous ces environnements

C’est assez difficile à se l’imaginer sans des explications, une démonstration et/ou quelqu’un qui nous guide pour nous montrer le fonctionnement, alors je vais vous présenter un cas d’usage.

Usage et exemple de Genèse

Imaginons un cas d’usage typique : un client détient une application web (faite avec un framework) qui utilise une base de données MySQL. Appelons cette application : memory_game.

Il est très probable que nous ayons d’autres clients qui utilisent MySQL. Et il est très probable que notre client fera des tickets de bugs que nous aurons à résoudre. Nous aurons probablement plusieurs collaborateurs (pour lesquels nous allons répartir les tickets).

Il utilise un fichier docker-compose.yml avec le contenu suivant :

version: '3'

services:
  php:
    image: toasterlint/php-apache-mysql
    ports:
      - "8888:80"
    volumes:
      - ./:/var/www/html

  db:
    image: mysql
    command: --default-authentication-plugin=mysql_native_password
    restart: always
    environment:
      MYSQL_ROOT_PASSWORD: mot2passe
      MYSQL_DATABASE: maBdd
    volumes:
      - ./base_de_donnees:/docker-entrypoint-initdb.d

On comprend donc qu’il y a :

un service (nommé db) pour une base de données MySQL,
un service (nommé php) pour l’application écrite en PHP sur le port 8888.

Avec Genèse, générer un nouvel environnement de développement reviendrait à faire :

# Génère un docker-compose.yml dans le dossier instances/memory_game à partir du profil nommé memory_game
./genese -p memory_game

instances/memory_game est un répertoire de travail :

avec le dépôt de version du projet memory_game,
un fichier docker-compose.yml prévu pour lancer un environnement complet,
et un fichier .env contenant des variables permettant au projet d’être autonome.

Si l’exécutable ./genese venait à disparaître, le dossier reste fonctionnel pour travailler (avec Docker Compose évidemment).

Si on travaille sur plusieurs problèmes en parallèle, on peut vouloir créer un dossier par problème. Imaginons le ticket 42 et le ticket 16 :

# Génère une instance du projet dans le dossier instances/ticket42
./genese -p memory_game -n ticket42
# Même chose avec le dossier instances/ticket16
./genese -p memory_game -n ticket16

Il faut récupérer une branche spéciale du service memory_game ?

# Récupère dans le dépôt Git fourni dans le service memory_game la branche maBrancheSpeciale
BRANCHE_MEMORY_GAME="maBrancheSpeciale" ./genese -p memory_game -n essaiautrebranche

Vous découvrirez dans un prochain article à quel usage je réserve cela 😉

Quelles sont les instances dont je dispose ?

# Liste l'ensemble des instances
./genese -i

Et j’obtiens une liste des dossiers ayant été créés.

Si je veux supprimer une instance spécifique :

# Supprimer l'instance ticket16
./genese -s ticket16

Et si on veut avoir une visualisation des instances lancées, d’accéder à leur détail, éteindre un conteneur, le rallumer, regarder les fichiers de journalisation (logs) ou encore entrer dans un conteneur avec une invite de commande, on peut utiliser l’interface Web Portainer fournie avec Genèse. Cela ressemble à quelque chose comme :

Seriez-vous curieux de savoir comment cela fonctionne (sans entrer dans le technique évidemment !) ?

Comment ça marche ?

Nous allons voir que Genèse s’appuie sur quelques éléments clés comme :

l’instance : version autonome et isolée, située dans le dossier instance,
le service : la description nécessaire pour générer un service, par exemple MySQL,
le profil : contient une liste de services permettant de démarrer une instance.

Prenons l’exemple précédent, nous aurons :

deux services :
- l’un nommé mysql pour la base de données,
- l’autre nommé memory_game pour notre application,
un profil nommé memory_game qui liste les services mysql et memory_game.

Chaque fois que nous lancerons la commande ./genese avec le profil memory_game nous aurons la possibilité de générer une instance avec un nom spécifique.

Comment cela peut-il fonctionner ? Les services ont une structure permettant de décrire :

la partie du fichier docker-compose.yml qui va être utilisée,
la possibilité de donner le dépôt Git utilisé pour récupérer les sources du projet et la branche par défaut à récupérer,
la possibilité de donner un dossier extras permettant de surcharger les sources du projet récupéré (par exemple pour mettre des fichiers de configuration),
la possibilité d’agir à des moments clés de la génération de l’instance via des déclencheurs qui sont des scripts pour :
- procéder à des changements AVANT le lancement des conteneurs Docker, par exemple modifier des fichiers de configuration,
- agir APRÈS le lancement des conteneurs, par exemple pour lancer des commandes dans les conteneurs Docker lancés,
- afficher des informations à la fin du processus de création de l’instance, par exemple pour afficher les ports utilisés par les différents conteneurs

À cela s’ajoute une interface Web (Portainer) permettant de contrôler les instances lancées et accéder à des fonctionnalités particulières de Docker.

La documentation de Genèse devrait se charger bien mieux que moi pour les détails techniques et les possibilités de cet outil.

Conclusion

Malgré l’exemple d’utilisation et quelques détails sur son fonctionnement, Genèse mérite qu’on s’y attarde : nous n’avons gratté que la surface.

Cela ressemble à un framework pour des profils de personnes de type devops afin de leur fournir un outil unique ; à la fois déployer des instances pour les développeurs ; et des instances de type test pour les personnes fonctionnelles.

Je ne sais pas comment suggérer de passer un peu de temps sur l’outil pour comprendre que c’est un bon investissement de temps. Surtout pour des personnes d’un profil DevOps et qui connaissent le scripting Bash. J’espère que la curiosité vous piquera au vif !

Nous nous retrouverons très probablement pour en reparler dans un cadre différent encore.

Bye Bye Gandi Mail, Bonjour Mailo

Fri, 25 Aug 2023 21:26:05 +0200

Ça fait quelques mois qu’on nous rabache que Gandi Mail va devenir payant. NextInpact affirme aussi que Gandi passe les mails en payant. Quel problème cela pose ? Où en suis-je ? Y a-t-il d’autres alternatives à cela ?

Photo trouvée sur le profil d’irio sur Flickr sous licence BY 2.0.

Problèmes posés

Gandi annonce la mise du service Gandi Mail payant à partir de fin septembre/début octobre. Le prix des boîtes mail passe de gratuit à 4.79€ par mois. C’est à dire 57.48€/an. Et cela pour chaque boîte courriel !

Le souci ? Quand on utilise plusieurs boîtes courriel, ça douille tout de suite plus ! Exemple : j’ai 4 boîtes courriel utilisées chez Gandi, ce qui me ferait passer de 0€/an à… 229.92€ !!

Avouez que la facture est plutôt corsée quand on a été habitué plus de 10 ans à ne rien débourser pour cela. Et encore, j’abuse un peu car il faut savoir que les domaines sous Gandi sont généralement plus chers que d’autres fournisseurs de domaines. Les adresses courriel gratuites et de bonne qualité amenait des clients chez Gandi.

J’utilise Gandi pour l’ensemble de mes domaines car j’apprécie le service, les possibilités (comme le « Live DNS ») et - antérieurement - la possibilité de créer des adresses courriels avec 1 000 alias de redirection courriels (vous choisissez des adresses courriels qui vont rediriger vers 1 à plusieurs adresses courriels, même si les adresses cibles ne vous appartiennent pas).

Et dans tout cela, où me situe-je ?

Où j’en suis

Si j’écris cet article, c’est parce que j’aimerais partager à la fois le fait qu’il y a du changement chez Gandi Mail, mais aussi mes pérégrinations en matière de recherche d’un fournisseur de mail prenant en compte les noms de domaine sans forcément les gérer.

On le dit souvent, en informatique il est intéressant de pouvoir changer un service sans avoir d’impact sur un autre : choisir un fournisseur d’adresses courriels sans changer de fournisseur de domaine par exemple. Et c’est ce que je visais.

Quelles alternatives ?

Si SebSauvage propose Infomaniak en migrant ses domaines là bas, d’autres proposent différents services comme FastMail, Ikoula.

La plupart du temps, il faut migrer ses domaines avec : ce que je ne recherche pas du tout. C’est le cas pour OVH qui propose des offres quand on gère les domaines chez eux.

Je suis alors tombé sur un article intéressant sur le passage à Mailo.com, service que je ne connaissais pas. Mailo.com est Français, garantit aux utilisateurs d’être respectueux de leurs données, ne pas les vendre à des tiers et visant une utilisation éthique et responsable du Web. Le service Mailo est gratuit, mais une option à 2€/mois existe, ce qui permet de gérer 5 adresses mails. Ça tombe bien, j’ai 4 adresses à créer !

Quelques détails sur ma migration

Ce qui est intéressant dans ce dernier article sur Mailo.com, c’est que l’auteur suggère l’utilisation d’imapsync comme outil pour synchroniser son ancienne boîte aux lettres avec la nouvelle. Et il donne les détails sur comment configurer tout cela.

À noter une petite subtilité que je n’avais pas prise en compte : si sous Gandi Mail vous avez droit à 1 000 redirections courriel, sous Mailo c’est limité à 100 redirection par boîte courriel. Quand on a 390+ redirections… il faut faire du tri ! Fort heuresement, Mailo propose un fonctionnement intéressant : ajouter ++ dans l’adresse courriel. Par exemple si vous faites une boîte prenom.nom@domaine.tld, vous pouvez créer dynamiquement prenom.nom++quelquechose@domaine.tld. Autant que vous voulez. Sans utiliser d’ordinateur. À la volée je vous disais !

Autre chose à viser aussi : le catch-all. C’est le fait que n’importe quelle adresse mal écrite, ou différente de votre boîte courriel entraînera quand même la redirection vers votre boîte courriel. Exemple : au lieu d’écrire prenom.nom@domaine.tld, si je me trompe en écrivant prenmo.nmo@domaine.tld, je recevrais quand même l’adresse courriel.

Conclusion

Je joue les montagnes russes avec les prix : je suis passé de 4 boîtes Gandi Mail gratuites à potentiellement 230€/an pour finalement payer 24€/an. Le coût numérique augmente légèrement. Je pense être en droit de me demander jusqu’où cela ira pour bénéficier d’un pseudo contrôle de mes données et le choix de mes fournisseurs sur Internet ?

Quoiqu’il en soit le passage de Gandi Mail à Mailo, même si rocambolesque et pas de tout repos, a été plus serein avec l’aide de l’article de Jonathan Tremesaygues sur le passage de Gandi Mail à Mailo à l’aide d’imapsync.

Je trie encore mes 390+ redirections Gandi Mail vers Mailo au fur et à mesure, mais c’était nécessaire et je suis bien content de l’avoir fait, malgré le côté payant de la chose !