Newsletter du 26 Mai 2026

Caddy Proxy Manager CPM est une chouette interface web légère pour gérer Caddy en tant que reverse proxy, avec gestion visuelle des règles, certificats SSL wildcard via DNS challenge, RBAC, backup, et 17 templates préconfigurés, tout ça dans une image de 6 Mo après une réécriture complète en Go (la version Python précédente pesait 794 Mo, ce qui en dit long sur le chemin parcouru). Support multi-plateforme amd64/arm64, Docker Compose en deux minutes, et une intégration Cloudflare pour le wildcard SSL qui évite de mettre les mains dans le Caddyfile. Rien de révolutionnaire, mais propre, léger et bien pensé pour qui héberge des services légers. Pour les autres, ceux qui ont des vraies responsabilités et un vrai cluster, il y a Traefik.

Kubernetes in anger Un anonyme a sorti un guide de référence intitulé "Kubernetes in Anger" qui mérite qu'on s'y arrête. Pas un tuto pour apprendre Kubernetes mais plutôt un guide de survie spécifiquement centré sur EKS en production. On y trouve tout ce qu'on ne trouve généralement pas ailleurs, genre les modes de défaillance propres à EKS (parce qu'EKS ne crashe pas comme un monolithe, il dégrade en silence), les interactions avec la VPC CNI d'AWS, les timeouts silencieux du NAT Gateway, les limites de la table conntrack, les pièges du Load Balancer Controller, et les runbooks d'incident avec les commandes exactes à lancer dans l'ordre. Une section entière explique aussi pourquoi votre cluster a l'air en bonne santé pendant que vos utilisateurs se plaignent, ce qui est précisément ce qui rend EKS plus traître que du K8s vanilla. Dense, sourcé, sans fioriture, à garder sous le coude et à partager avec quiconque opère de l'EKS en production.

The sovereign cloud illusion Les coyotes de chez InfoWorld ont pondu un article qui fait mal là où ça fait mal : le cloud souverain n'existe pas vraiment, et tout le monde le sait mais personne ne le dit. La souveraineté d'un cloud ne se résume pas à l'adresse postale du datacenter, elle dépend de qui possède la plateforme, contrôle le codebase, fournit les puces et surtout de quel système juridique peut vous forcer la main un matin de mauvaise humeur. Seuls les États-Unis et la Chine maîtrisent leur stack de bout en bout, le reste c'est de la mitigation vendue comme de l'indépendance. Gaia-X est passé par là pour confirmer que la volonté politique ne suffit pas à faire tourner un hyperscaler. À lire et à faire suivre à votre DSI, avec un café et sans commentaire.

How incidents can teach us about what's already working well Lorin Hochstein propose une lecture des post-mortems qu'on ne voit pas souvent : plutôt que de chercher uniquement ce qui a merdé, utiliser l'incident comme une illusion d'optique qui révèle comment le système fonctionne bien la plupart du temps. Quand un expert se trompe de diagnostic pendant un incident, la bonne question n'est pas "comment éviter cette erreur la prochaine fois", c'est "comment cet expert a-t-il raisonné, et qu'est-ce que ça nous apprend sur sa compréhension du système ?" Un peu comme si on demandait à Gandalf pourquoi il n'a pas vu venir le Balrog dans la Moria pour comprendre comment il navigue dans les mines depuis des siècles sans se perdre mais bref c'est un autre débat. Court, bien écrit, et qui donne envie de poser des questions différentes dans les prochaines réunions de post-mortem, à condition d'en faire vraiment.

Le radar RudeOps Cette semaine je suis en congés, ce qui chez moi se traduit invariablement par "enfin le temps de pousser ce truc en prod qui traîne depuis des semaines." Le truc en question s'appelle le Radar. Chaque jour ouvré, 5 signaux de l'écosystème DevOps sélectionnés et classés, pas de résumé, pas de remplissage, juste un titre, une source et votre jugement. L'idée est simple : la newsletter c'est moi qui parle, le Radar c'est l'écosystème qui parle. Les deux coexistent, les deux sont gratuits, aucun ne remplace l'autre et il y a bien sûr un flux RSS dédié pour ceux qui vivent encore en 2008.

TapMap TapMap surveille en temps réel toutes les connexions de votre machine et les visualise sur une carte interactive, avec un historique sur 30 jours pour distinguer ce qui est normal de ce qui ne l'est pas. Tout tourne en local, pas de télémétrie, support Docker sur Linux, et ce qu'il montre est souvent plus surprenant qu'on ne le pense.

Turn your own source code into typing challenges GitType est un jeu de frappe dans votre terminal qui utilise du vrai code source comme support d'entraînement. Vous tapez vos propres fichiers, des dépôts GitHub populaires, ou n'importe quel repo public. Métriques en temps réel, modes de jeu variés, système de progression avec des titres de devs plus ou moins flatteurs. C'est bête, c'est addictif, et ça fait travailler la mémoire musculaire sur du code réel plutôt que sur des exercices artificiels. À essayer.

The code nobody read is already in production Ben Sigelman (co-créateur de Dapper et Monarch chez Google, co-fondateur de Lightstep et papa d'OpenTelemetry rien que ça) pose une question qui fait mal dans un article publié chez Lightstep : est-ce que quelqu'un a vraiment lu le code qui tourne en prod en ce moment ? Sa thèse est simple et un peu vnr comme on dit à Montargis : l'IA génère du code plus vite que les humains ne peuvent le relire, le contexte qui permettait de comprendre pourquoi un bout de code était écrit d'une certaine façon n'existe plus nulle part, et la prod est en train de devenir le seul endroit où on peut vraiment valider si un logiciel fonctionne ou non. Ce n'est pas une prédiction, c'est déjà en cours. Il va plus loin en estimant que dans deux ans, on verra tourner en parallèle plusieurs versions du même service écrites différemment, évaluées directement sous charge réelle. La conséquence logique c'est que l'observabilité ne peut plus être réactive, elle doit devenir continue et automatisée, et l'ops d'astreinte doit arriver en fin d'investigation plutôt qu'en début. Un article qui mérite d'être lu, même si l'auteur travaille pour une boîte qui vend précisément les outils dont il parle.

AI powered K8s assistant kubectl-ai est un plugin kubectl signé Google Cloud Platform qui traduit du langage naturel en opérations Kubernetes en s'appuyant sur les LLMs de votre choix : Gemini, OpenAI, Grok, Bedrock, ou un modèle local via Ollama. En pratique, vous tapez "how's nginx doing in my cluster" et l'outil fait le kubectl à votre place, ce qui est soit une excellente idée soit une façon créative de laisser une IA faire des choses irréversibles sur votre prod. Support MCP dans les deux sens (client et serveur), sessions persistantes, outils personnalisables, et une intégration Docker pour les clusters GKE. À tester sur un environnement de dev d'abord, ou sur la prod d'un collègue si vous êtes du genre audacieux.