J’ai longtemps gardé tout mon homelab sous Docker Compose. Pas par rejet de Kubernetes : Compose faisait le travail, les volumes étaient faciles à retrouver et je savais remettre un service en route sans relire une pile de manifests.
K3s est arrivé plus tard, quand j’ai voulu uniformiser les déploiements et préparer l’ajout d’autres machines. Je n’ai pas tout migré pour autant. Aujourd’hui, les deux cohabitent encore. C’est volontaire.
Pour trancher, je regarde surtout la panne : avec lequel des deux vais-je retrouver les données et remettre le service en route sans improviser ?
Le tag latest est confortable.
On écrit un compose.yml, on lance docker compose up -d, et le service démarre. Pas besoin de choisir une version de PostgreSQL, Redis, Traefik, Gitea, Vaultwarden ou n’importe quelle application auto-hébergée.
Le problème, c’est que latest ne veut pas dire “dernière version stable adaptée à mon environnement”. Ça veut seulement dire : “ce tag pointe vers quelque chose dans le registre au moment où Docker le résout”.
Ce quelque chose peut changer sans que votre fichier Compose change.
Pour une stack de test, ce n’est pas très grave. Pour une base de données, un reverse proxy exposé, un service d’authentification ou une application avec des volumes persistants, c’est une mauvaise convention d’exploitation.
Le vrai sujet n’est pas Docker. C’est la reproductibilité.
Je suis tombé sur Hermes Agent début 2026, et il m’a fallu quelques semaines pour comprendre ce que le projet apportait par rapport aux autres frameworks d’agents.
Le pitch officiel - “self-improving AI agent with a built-in learning loop” - ne rend pas bien service à ce que le logiciel fait concrètement. Après plusieurs mois d’utilisation quotidienne, voici ce que j’en retire.
Dans mon setup opencode + Ollama sur RTX 3090, j’avais commencé avec SearXNG comme source web via MCP.
Ça fonctionnait, mais ce n’était pas exactement le bon outil pour mon usage. SearXNG est un métamoteur de recherche. Il trouve des pages. Firecrawl est plus proche d’une brique d’extraction : il cherche, scrape, nettoie, crawl et renvoie du contenu exploitable par un agent.
Pour un assistant local qui doit lire de la documentation, vérifier une API récente ou comparer plusieurs sources techniques, la différence se sent assez vite.
J’utilise des LLMs comme assistants de code depuis début 2026. D’abord avec des API cloud, puis en local.
Ce qui a changé avec une RTX 3090, c’est la bascule vers un modèle de travail où la latence et la confidentialité deviennent moins pénalisantes. L’inférence locale devient crédible pour du code à partir de 24 Go VRAM.
Voici mon setup, les chiffres réels et ce qui tient vraiment la route.
Freebox 4.11.1 déploie le DNS local .home après 15 ans d’attente, zeropod v0.12.0 corrige les probes K8s, et les outils auto-hébergés Keeper, Euro-Office passent au crible.
Le 19 mars 2026, un acteur disposant d’identifiants compromis a publié une version malveillante de Trivy et détourné les références de ses actions GitHub. Trivy est justement utilisé pour détecter des vulnérabilités dans les dépendances et les images de conteneurs.
L’incident ne rend pas le scanner inutile. Il rappelle qu’un outil de sécurité reste un logiciel distribué par une chaîne de build, des comptes, des registres et des mécanismes de mise à jour qui peuvent eux-mêmes être compromis.
Mise à jour du 28 août 2026 : cet article a été recentré sur les faits confirmés par les projets concernés. Plusieurs exemples historiques de la version initiale mélangeaient des dates ou des mécanismes d’attaque différents. Les commandes ont aussi été adaptées aux versions actuelles des outils cités.
La cryptographie post-quantique n’est pas de la science-fiction. L’attaque Harvest Now, Decrypt Later invite à préparer les usages crypto dès maintenant. Guide pratique pour auditer les usages, prioriser les risques et préparer une migration progressive vers l’hybridation.
Debian 14, nom de code Forky, est la future version stable de Debian. Au 14 mai 2026, elle est encore en branche testing. Aucune date de sortie n’est annoncée, et les étapes du freeze ne sont pas encore planifiées publiquement.
Le bulletin de l’équipe Release publié le 10 mai 2026 apporte tout de même plusieurs informations importantes : les builds reproductibles deviennent une contrainte plus forte dans la migration des paquets, les binNMU passent par davantage de tests automatiques, et l’architecture loong64 arrive dans l’archive Debian.
Pour un serveur de production, la conclusion immédiate est simple : Debian 13 Trixie reste la version stable à utiliser. Debian 14 est intéressante à tester dès maintenant, mais pas à déployer comme base principale tant qu’elle n’est pas publiée en stable.
Ubuntu 26.04 LTS est sortie le 23 avril 2026 sous le nom Resolute Raccoon.
Pour un poste desktop, c’est une nouvelle LTS avec GNOME 50, Wayland et quelques changements visibles. Pour un serveur, c’est autre chose : une base qui peut rester en production pendant plusieurs années, avec un nouveau noyau, une pile crypto plus stricte, des paquets serveur mis à jour, des changements de comportement sur des services courants, et une stratégie de support à bien comprendre avant de lancer un do-release-upgrade.
Je regarde donc Ubuntu 26.04 LTS sous l’angle qui m’intéresse le plus ici : serveurs, VPS, homelab, cloud, sécurité et migration propre.
