Toutes les newsletters
#81

Newsletter du 14 Septembre 2026

GitCINixKubernetesArgo CDDockerconteneurssécuritéForgejoself-hostingIA

La semaine dernière je parlais de Omarchy 4 et cette semaine j'ai eu du courrier.

Certains d'entre vous m'ont écrit pour me signaler que l'auteur de la distro (David Heinemeier Hansson) publie depuis un moment des billets où il compare des populations entières à des animaux et réclame leur expulsion d'Europe.

Je lis DHH de temps en temps, Rails, le cloud exit, virer telle couche de sa stack etc. Jamais tombé sur le reste. Soit je ne lis pas assez, soit ça se passe sur X, et sur X je n'y suis plus.

Je suis prêt à accepter beaucoup, mais ce que j'ai lu cette semaine, je ne suis même pas en désaccord avec tellement je n'arrive même pas à me représenter le chemin qui mène quelqu'un à écrire ça, à le relire, à le trouver bon et à le publier sous son nom.

Alors on me dira qu'il faut séparer l'homme de l'œuvre et ben non. Je fais ce métier depuis plus de vingt-cinq ans, il m'a tout donné, et je ne vais pas continuer à le pratiquer sans aucune valeur au motif qu'une distro démarre vite.

Hessel appelait à s'indigner face aux grandes lâchetés de son siècle, moi je fais ce que je peux à mon échelle, et la mienne fait 36 Mo et se désinstalle en une commande.

Cyril

La pépite de la semaine

Mat Duggan ouvre son billet par une classification des gens de la tech qui vaut déjà le déplacement : ceux qui aiment la tech, ceux qui veulent de la visibilité sans les conséquences, ceux qui sont là pour le salaire et l'assument très bien et lui qui réclame les pires problèmes possibles et démissionne dès que le job devient facile. Il range dans la première catégorie ce collègue qu'on a tous croisé, celui capable de quitter une boîte sur un débat de framework, ou de hurler vingt minutes dans un open space pour imposer emacs comme éditeur officiel de l'équipe, un combat dont personne n'a jamais compris les enjeux mais dont tout le monde se souvient du volume sonore.

Puis il en arrive aux LLM. Plus aucune récompense à comprendre un truc, puisque plus personne n'est impressionné que tu aies lu la doc et le code source alors que l'agent l'a fait à ta place. Il se compare à ces gens payés pour s'asseoir dans le siège conducteur d'une voiture autonome, les mains à deux centimètres du volant, à transpirer en attendant que le robot décide de renverser quelqu'un.

D'où le titre de son billet. Ce qu'il vend maintenant, ce n'est plus des solutions, c'est un forfait mensuel de responsabilité : un humain qu'on peut convoquer, sermonner et engueuler quand ça casse. Il présentera ses excuses, il tentera de réparer, il assumera. C'est court, c'est drôle, et tu vas reconnaître ta dernière semaine dedans.

Lire l'article

Le coeur de la veille

20x the CI traffic without getting slower Les cowboys de chez Datadog racontent comment ils ont refait leur couche de service Git et il y a de chouettes trucs à apprendre. Le problème c'est qu'un fetch sur un gros monorepo coûte plusieurs secondes de CPU parce que le serveur reconstruit un packfile sur mesure pour chaque client, donc rien à cacher, et ajouter des nœuds empirait tout. Leur solution tient en des miroirs qui se synchronisent depuis GitHub et des relais qui posent le packfile reçu tel quel, sans le réindexer, puisque les objets sont adressés par leur contenu. 20 fois plus de trafic, 40 ms de latence médiane, CPU de l'ancien backend divisé par quatre. Meilleur passage : en regardant le trafic, ils découvrent que la plupart des clients ne voulaient pas un clone, juste un fichier ou le SHA d'une branche. Ils clonaient 400 000 fichiers pour lire un README, comme on déménage un appart entier pour récupérer un chargeur. Au passage, une bonne partie de la hausse de trafic vient des agents IA qui tapent sur Git avec l'enthousiasme d'un labrador devant une porte vitrée.

A Nix store is three functions Nix, pour ceux qui n'ont jamais essayé, c'est le gestionnaire de paquets qui range tout dans un store adressé par hash ce qui lui permet de rejouer exactement le même environnement dix ans plus tard, à la virgule près, y compris les bugs. L'article montre que son cache binaire tient en trois requêtes et que la signature ne couvre que le contenu, pas le transport. Traduction : n'importe quel serveur de fichiers statiques peut servir de dépôt Nix, et Nix n'en saura jamais rien. L'auteur le prouve en publiant une closure complète de quelques Mb sur npm, où elle vit désormais parmi les paquets de padding CSS. Puis il recense les autres implémentations croisées en route, la base d'objets Git, un registre OCI, des enregistrements DNS TXT découpés en tranches de 4 Ko, un pastebin dont l'expiration sert de garbage collector, et un projet qui encode les données dans une vidéo YouTube. Quelque part, un ingé réseau regarde son trafic DNS grimper de 3 Go et ne comprend pas.

Gitignore everything by default L'idée tient en une ligne : tu mets une étoile en haut de ton .gitignore, tu ignores tout, puis tu réautorises uniquement ce que tu veux vraiment voir dans le repo. Cinq lignes pour un projet Go, et plus jamais de .DS_Store, de node_modules ou de fichier d'environnement poussé un vendredi soir avec les clés API dedans. L'auteur justifie ça par l'état actuel de nos répertoires de travail, où s'empilent les dossiers d'agents, les configs d'éditeur et les docs générées par des robots, au point que le .gitignore de typescript-go atteint 207 lignes, soit un fichier de configuration plus long que la moitié des projets qu'il ignore.

/usr/local/bin

Sofka Un k9s réécrit en Rust par quelqu'un qui a visiblement compté les secondes en attendant sa liste de pods. Même principe que k9s donc, une TUI pour naviguer dans le cluster, sauf que Flux et ArgoCD sont intégrés en natif, suspend, reconcile et sync passant par des patches API sans aucun binaire externe et que l'inspecteur Helm décode les Secrets de release tout seul. Une touche ouvre une vue d'incident déterministe qui te dit pourquoi ton pod est par terre (sans IA ce qui en 2026 relève presque de la provocation).

Languard Un scanner de LAN qui découvre tes appareils, les range dans des pièces sur un plan, surveille leurs ports et t'alerte sur Discord dès qu'un inconnu se pointe. Il t'apprendra surtout que tu héberges quatorze machines dont six que tu ne reconnais pas, dont trois qui sont ton téléphone.

DTop J'en avais déjà parlé ici, la TUI Docker écrite en Rust qui affiche tes conteneurs et leurs métriques dans le terminal. Depuis, le projet a pris du muscle : plusieurs hôtes en même temps via SSH, TCP ou TLS, donc un seul écran pour tes serveurs, un fichier de config YAML pour filtrer par label, par statut ou par santé, l'intégration Dozzle pour ouvrir les logs d'un conteneur au clavier et la lecture des labels Coolify pour afficher de vrais noms plutôt que des identifiants. La roadmap annonce Kubernetes, ce qui est la manière polie d'annoncer que le projet ne s'arrêtera jamais.

Argo9s Un k9s qui ne fait que de l'Argo CD. Applications, ApplicationSets, AppProjects, une touche qui te redessine l'arbre de ressources dans le terminal, sync, refresh et suspend au clavier, et un mode read-only par connexion pour que ta prod ne dépende plus de ton discernement du vendredi soir. Il y a aussi un mode démo sans cluster, le seul dans lequel tout est vert.

En bref

Hardening container images Mike Cardwell voulait faire tourner un PowerDNS Recursor et a découvert que l'image officielle, c'est Debian et 7 500 fichiers autour d'un binaire. Il l'a refaite, 355 Mo deviennent 36 Mo, 7 500 fichiers deviennent deux, plus de shell, plus rien à se mettre sous la dent pour celui qui rentre. Le reste du billet raconte le hardening, Landlock, seccomp, SBOM, signature, rebuild quotidien, le tout exposé avec le calme d'un homme qui explique comment il a muré sa propre cave.

Avoid Duke Nukem Forever mode Duke Nukem Forever, annoncé pour Noël 1998 et sorti en 2011 dans un état lamentable après quatorze ans de dev, quatre moteurs et un procès : c'est le nom que l'auteur de ce post donne au piège dans lequel il est tombé avec sa propre bibliothèque. Prête pour la production il y a dix-huit mois, toujours pas publiée, parce qu'entre-temps il a réécrit la gestion des connexions, ajouté deux bases, collé de l'OpenTelemetry et refait tout l'asynchrone. Sa mise en garde vaut surtout à l'heure des agents, où ajouter le truc dont personne n'a parlé ne coûte plus rien. Quelque part sur une branche nommée v2-final-clean dort un projet parfait que personne n'utilisera jamais.

I moved all my side projects off Github to Forgejo Un retex court et honnête sur une migration que beaucoup repoussent sans jamais l'essayer. Forgejo déployé en quelques minutes via Portainer, deux projets rapatriés depuis GitHub avec 443 commits et 15 releases, un token d'accès et c'est plié. Le reste du billet répond à la seule question qui compte vraiment : qu'est-ce que ça casse au quotidien. Réponse, à peu près rien côté workflow, il pousse et Coolify redéploie exactement comme avant. Mais il liste aussi ce qui coince, la CI qui reste muette tant qu'aucun runner n'est enregistré, la registry de paquets qui ne suit pas dans la migration, et l'uptime qui devient son problème.

Sous les pavés l'IA

K8s did not miss the AI wave L'argument du papier tient en une phrase : l'IA n'a pas produit une nouvelle pile d'infra, elle s'est installée dans celle des microservices et la déforme de l'intérieur. Chiffres à l'appui, 66 % des boîtes qui hébergent des modèles génératifs font déjà de l'inférence sur Kubernetes, la Dynamic Resource Allocation a fait entrer les accélérateurs dans l'API, Kueue les compte dans les quotas comme le CPU, et la Gateway API sait désormais router en fonction des métriques du modèle. Le passage le plus utile est ailleurs : seulement 7 % des organisations déploient un modèle par jour et plus de la moitié n'en entraînent aucun. Autrement dit, l'IA en entreprise est un problème d'exploitation, pas de recherche. Routage, quotas, observabilité, coûts... Soit exactement ce que tu fais déjà depuis dix ans, mais avec des cartes graphiques hors de prix et un vocabulaire neuf pour dire aux dirigeants que c'est un métier différent.