Platform Engineer le jour, homelab addict le soir. Je conçois et opère des plateformes DevOps robustes — de l’infrastructure as code aux pipelines CI/CD, du homelab aux environnements de production industriels.
Ici, je documente mes pratiques, mes retours d’expérience et mes expérimentations techniques.
120 projets à migrer. Seul. La dernière fois qu’on avait dû faire ça, on s’était promis de ne plus jamais le refaire. La dernière fois Il y a deux ans, on avait déjà dû faire une migration de pipelines CI à l’échelle du département. Un template maison à mettre à jour, une évolution structurelle. On avait fait la seule chose qui semblait possible : communiquer. Demander à chaque responsable de projet de faire la mise à jour. Certains l’ont fait dans la semaine. D’autres jamais. Résultat : un drift entre les projets à jour et les projets à la traîne, du support pendant des mois, et des « Ah, il fallait migrer ? » à chaque incident. ...
Avant, parallel:matrix permettait de lancer la même tâche sur plusieurs versions. Mais impossible de référencer UN job spécifique de la matrice dans un needs. Toute la matrice formait un bloc indivisible. GitLab 16.7 a changé ça. Maintenant, tu peux needs un job précis de la matrice. Et ça débloque des pipelines plus propres. Avant : le workaround # ❌ Avant GitLab 16.7 : impossible de référencer un job de la matrice test: parallel: matrix: - PYTHON: ["3.9", "3.10", "3.11"] script: pytest deploy: needs: ["test"] # Attend TOUS les jobs de la matrice script: ./deploy.sh Après : des needs chirurgicaux # ✅ GitLab 16.7+ : on cible un job précis test: parallel: matrix: - PYTHON: ["3.9", "3.10", "3.11"] script: pytest deploy_39: needs: ["test: [3.9]"] script: ./deploy-py39.sh deploy_latest: needs: ["test: [3.11]"] script: ./deploy-pylatest.sh Le job deploy_39 attend UNIQUEMENT test: [3.9]. Il n’attend pas les tests Python 3.10 et 3.11. Résultat : le déploiement peut partir dès que sa version est validée, sans attendre les autres. ...
Découvrez comment un projet bénévole transforme l’informatique dans une école privée, améliorant les compétences techniques des élèves et élargissant mes horizons professionnels.
J’ai découvert just en parcourant des projets Rust lorsque j’ai commencé à apprendre le langage. just c’est un Makefile sans la syntaxe particulière de Make. Les recettes sont plus lisibles, le langage est pensé pour lancer des commandes (pas pour compiler du C). Et la syntaxe des dépendances est plus intuitive : # justfile deploy: build push kubectl apply -f deploy/ build: docker build -t monapp . push: docker push monapp:latest Moi qui ai tendance à utiliser pas mal Make pour ce genre de raccourcis (et jamais pour builder du C), ça m’a convaincu pendant 3 mois. Puis j’ai travaillé sur des machines où just n’était pas installé. Et là, Make est toujours installé. Prêt à opérer. Aucun obstacle. ...
Pourquoi construire un Enterprise Homelab ? L’idée est partie d’un constat : dans mon métier, on manipule des patterns complexes (GitOps, Zero Trust, Kubernetes à l’échelle) qu’on peut rarement tester librement une fois en production. Alors j’ai décidé de me construire un terrain de jeu qui reproduit ces contraintes, sans les enjeux. Cet article est une RFC (Request For Comments) : je vous expose ma démarche, mes choix d’architecture, et j’ouvre le débat. ...
k9s est un excellent TUI Kubernetes. Quand je l’ai découvert, j’ai eu l’impression de passer du terminal IBM 3270 à un OS graphique. Tu navigues dans les pods avec ↑↓, tu filtres avec /, tu lances des commandes avec :. Plus besoin de taper kubectl get pods -n machin -o wide | grep bidule. Mais il y a un prix : tu oublies kubectl. Vite. Très vite. Ce que k9s fait mieux que kubectl Navigation : :pods → liste des pods → Enter sur un pod → logs. 3 touches au lieu de kubectl get pods -n X && kubectl logs -n X pod/Y. Filtrage : /error filtre en temps réel. Ctrl+A pour désactiver. C’est grep intégré, réactif à chaque frappe. Actions : d pour décrire, s pour shell, l pour logs, y pour YAML. Tout le monde a les mêmes raccourcis — pas besoin d’apprendre les flags. Nodes : :nodes → tu vois l’état des nœuds, les pods par nœud, les ressources utilisées. En une vue. kubectl describe node × 10 nœuds, c’est 10 commandes. k9s = une vue. Le revers Après 3 mois de k9s intensif, j’ai réalisé que j’étais incapable d’écrire un kubectl get pods --sort-by=.status.startTime sans Google. k9s m’a rendu plus rapide au quotidien mais plus dépendant d’un outil qui n’est pas installé partout. ...
J’ai découvert uv en février 2025. En mars, pip n’existait plus chez moi. Avant, gérer les dépendances Python c’était pip + pip-tools + virtualenv + un fichier texte pour se souvenir de la commande d’activation. Trop de pièces mobiles pour un truc qui devrait être simple. (Quant à poetry, j’ai jamais passé le pas) uv pip install est 10 à 100× plus rapide que pip. uv venv crée un virtualenv en moins d’une seconde. Et uv pip compile remplace pip-tools sans avoir à installer quoi que ce soit. Tout est dans un seul binaire. ...
Stocker des secrets dans Git, tout le monde le dit : c’est une mauvaise pratique. Mais stocker ses secrets dans un vault et ses fichiers de config dans Git, c’est deux sources de vérité qui finissent par dériver. sops résout ça : on commit ses secrets chiffrés avec ses fichiers de config. Un seul dépôt, une seule source de vérité. Au déploiement, le secret est déchiffré à la volée. Setup avec age # Générer une clé age (une ligne) age-keygen -o ~/.config/sops/age/keys.txt # Récupérer la clé publique age-keygen -y ~/.config/sops/age/keys.txt # → age1ql3z7hjy54p3w6d... La config minimale .sops.yaml à la racine du dépôt : ...
Pendant des années, chiffrer un fichier c’était : générer une clé GPG, la stocker sur une clé physique, gérer l’expiration, prier pour que le keyring ne soit pas corrompu, et relire la doc GPG pour la trente-septième fois. age a remplacé tout ça. Une clé publique, une clé privée, zéro concept de keyring. La clé privée tient sur une ligne. La clé publique aussi. C’est tellement simple qu’on peut les stocker dans son gestionnaire de mots de passe. ...
Je n’ai jamais utilisé tmux. Pas par principe, juste parce que quand j’ai commencé à chercher un multiplexer, zellij est tombé au bon moment. C’est contre-intuitif : tmux est plus réputé, plus ancien, installé partout. Mais zellij a une qualité rare : il est utilisable sans config. Pas de .tmux.conf à écrire. Pas de préfixes bizarres à mémoriser. Une barre d’état qui montre les onglets et les processus en cours, sans plugin. Des raccourcis qu’on découvre en appuyant sur Ctrl+G. ...