[RudeOps] Newsletter du 19.10.2026

RudeOps #86 : Fatigué

Depuis des semaines les lycéens sont dans la rue et un gamin de quinze ans y a perdu une main, une gamine un oeil... Des matraques qui tombent trop vite, des vitrines qui explosent, des commerçants qui comptent les dégâts. Et pendant ce temps sur les réseaux je regarde des adultes transformer tout ça en concours. À qui la faute, quel camp a commencé, quel candidat, lui le seul lucide entouré de quarante millions d’imbéciles, aurait tout réglé d’un claquement de doigts. Les extrêmes qui ont réponse à tout, les partis de gouvernement qui n’ont plus de réponse à rien, et chacun persuadé d’être le dernier adulte dans la pièce. On ne débat plus, on tranche. Celui qui pense autrement n’est plus un contradicteur, c’est un ennemi, un vendu, un idiot.

Je fais le même métier que vous. On sait qu’une certitude qui refuse d’être testée n’est pas une analyse mais un bug et qu’une bonne archi, c’est rarement un seul composant qui a raison contre tous les autres.

Alors voilà, je suis fatigué. J’aimerais juste qu’on applique dehors ce qu’on sait faire devant un terminal : écouter avant de trancher, douter un peu, accepter que l’autre pense autrement sans en faire un crétin. Qu’on soit clair, critiquer une idée ou un gouvernement, c’est sain, c’est le but. Arracher la main d’un gamin ou cramer la boutique d’un type qui n’a rien demandé, non. Ce n’est pas le même log, et je refuse qu’on me fasse renvoyer tout le monde dos à dos.

Ça ne réparera pas le pays, mais à force de ne plus savoir s’écouter, on finit comme ces systèmes que plus personne n’ose toucher, tout le monde gueule, personne ne répare, et un jour ça tombe.

Cyril

> Le coeur de la veille

K8S RBAC explained by breaking it Les vandales de chez DevOps Daily ont sorti un simulateur RBAC gratuit, dans le navigateur, sans cluster ni inscription : vous demandez qui peut faire quoi et où, il répond Allowed ou Denied en désignant le binding responsable, avec la commande kubectl auth can-i pour vérifier sur un vrai cluster. Sept scénarios pour comprendre enfin que le rôle dit quoi et le binding dit où, qu’un roleRef avec une faute de frappe n’accorde rien en silence, et que le simple droit de lister les secrets suffit à tous les lire. Le cas d’ouverture est le plus réaliste : la CI se prend un Forbidden en prod, quelqu’un dégaine un ClusterRoleBinding pour aller vite, et le compte de CI lit désormais tout kube-system ce qui ressemble furieusement à la politique de sécurité de votre cluster.

Crow CI Je viens de découvrir Crow CI, de la CI/CD de bonhomme self-hosted sous licence Apache 2.0, sans édition payante ni fonctionnalité planquée derrière un devis. Un seul serveur pour GitHub, GitLab, Forgejo, Gitea et Bitbucket, des pipelines en YAML dans le dépôt et des étapes qui tournent en conteneurs, en pods Kubernetes ou dans des VM Windows et macOS jetables. Windows jetable, j’en rêvais. Le tout tient dans moins de 200 Mo de RAM soit moins que l’onglet Jira que je n’ai jamais fermé depuis 2021. Le projet est né début 2025 d’un fork de Woodpecker (lui-même fork de Drone) par un ancien mainteneur qui voulait professionnaliser releases, doc et gouvernance.

Forgejo v17.0 is available Forgejo se prononce "for-djé-yo", c’est le mot espéranto pour "forge" et la FAQ fournit même un enregistrement audio pour vous l’apprendre, preuve que même eux n’y croyaient pas. Bref derrière ce nom de catcheur mexicain se cache un fork communautaire de Gitea, une forge Git auto-hébergée légère et portée par Codeberg. Passé directement de la 1.21 à la 7.0 en 2024 pour cause de versionnage sémantique, le projet sort désormais une version majeure tous les trois mois et en est déjà à la 17 ce qui en fait le seul logiciel qui vieillit plus vite que son admin. Au menu : l’autocomplétion des issues, la migration depuis Bitbucket Data Center pour ses derniers otages, une doc de sauvegarde toute neuve et un magnifique bouton Donate orné d’un cœur rose rangé à côté du bouton RSS que trois personnes utilisent encore.

> /usr/local/bin

Boring Un gestionnaire de tunnels SSH en ligne de commande qui lit votre ~/.ssh/config, range tout dans un fichier TOML et se reconnecte tout seul quand le réseau tousse, forwarding local, distant et SOCKS5 compris. Dans la démo, le tunnel de staging tient depuis onze heures et celui de prod depuis deux minutes, la capture d’écran la plus honnête de l’année.

wtfi2 wtfi2 (pour What The F*ck Internet) dessine en direct le chemin de votre connexion du Wi-Fi jusqu’au DNS, mesure pertes et jitter à chaque saut et désigne en une ligne l’endroit exact où tout meurt, sans sudo. Le mode live vous permet de traquer la zone morte en arpentant l’appart laptop à bout de bras comme un sourcier, et la démo montre une panne DNS, évidemment.

wifit3 Oui, je sais, deux outils Wi-Fi à la suite, chacun ses névroses hein. wifit3 donc, est un auditeur Wi-Fi sur clé USB qui tourne à l’identique sur Linux, Windows (hahahaha) et macOS, en Python pur sans aircrack-ng ni driver noyau, parce qu’il embarque ses propres mini-pilotes et parle au chipset directement en USB en lui chuchotant des choses que le noyau n’était pas censé entendre. Scan 2,4 et 5 GHz, capture de handshakes WPA, PixieDust, evil twin, et décloaking des réseaux cachés qui se croyaient à l’abri sous la couette. Le tout réservé aux réseaux que vous possédez, précision qui n’a jamais arrêté personne surtout pas mon taré de voisin qui a appelé son SSID "Je te vois et je sais ce que tu fais".

nibrunner nibrunner fait tourner vos apps dans des microVM Firecracker sur une seule machine : un binaire, un JSON où vous listez ce que vous voulez, et le daemon démarre chacune dans sa microVM et l’y maintient. L’idée mon gâté, c’est que toute app sans trafic est gelée puis réveillée à la première requête, si bien qu’une machine qui en fait tourner quelques dizaines peut en garder des centaines sous le coude tels des hamsters en hibernation qui se relaient sur la roue. TLS, backups vers un object store, snapshots, logs et page Prometheus compris, pour que votre VPS héberge enfin les trente side projects que vous ne finirez jamais.

> En bref

A single console log was costing us 40K a year Une équipe a accusé la base, l’ORM, le framework et le stagiaire avant de découvrir que ses 40 000 dollars annuels de serveurs en trop venaient d’une ligne de log qui sérialisait le body de chaque requête pour qu’un logger réglé en warn le jette aussitôt. Trouvée par hasard en profilant autre chose ce qui reste à ce jour la méthode d’observabilité la plus fiable du marché.

3-2-1 backup strategy Un chouette guide step by step hoooo baby pour monter une sauvegarde 3-2-1 avec restic, qui chiffre et déduplique tout vers Backblaze B2, lancée chaque nuit par un timer systemd, avec la procédure de restauration pour le jour où le bureau brûle. Le premier envoi a pris cinquante heures et le test de restauration arrive en toute dernière ligne, à faire de temps en temps, exactement comme chez vous ouais.

Better HTTP/1 connection reuse Go 1.27 vide désormais tout seul les bodies HTTP/1 que vous n’avez pas lus, ce qui évite de jeter la connexion pour en rouvrir une, handshake TLS compris, et rend le programme de démo près de cinq fois plus rapide sans toucher une ligne. Toutes les fonctions maison qui drainaient les bodies à la main deviennent du code mort, ce qui ne les empêchera pas de rester dans votre dépôt jusqu’à la fin des temps.

PID, TID, TGID and why processes and threads don't really exist Un article qui part d’un simple ps sur gedit pour vous expliquer que les processus et les threads n’existent pas dans le noyau Linux qui ne connaît que des tasks, chacune avec son PID et regroupées sous un TGID qui est le PID du chef de groupe. Le PID du premier thread égale celui du processus parce qu’un PID est en fait un TID, CQFD, et le champ s’appelle pid et non tid pour une simple raison historique que l’auteur déroule jusque dans le code source. De quoi relancer à la machine à café le débat qui finira votre amitié avec le collègue qui dit encore "processus".

> Sous les pavés l'IA

Du code au merge avec les agents IA L’IA a enfin réglé le problème du code qui s’écrivait trop lentement, il reste celui du code que personne ne relit. Florian Bruniaux reprend son talk Dev With AI sur ce qui coince avant le merge : contrôles locaux, trois IA qui relisent le code d’une IA, corrections bornées par un budget et un humain qui garde le bouton etc. Il précise que les gains ne sont pas vraiment mesurés, ce qui en fait le seul talk IA de l’année à ne pas promettre un x10.

abtop Un btop pour agents de code qui affiche toutes vos sessions Claude Code, Codex et OpenCode avec tokens, contexte, rate limits et les serveurs que vos agents ont lancés puis oubliés, le tout en lecture seule et sans clé d’API. Il génère ses résumés en appelant Claude, donc il grignote le quota qu’il surveille et surtout il fait de l’ombre à rudeclaude, je ne peux donc objectivement pas le recommander.

Redesigning source control at Anthropic Les freaks de chez Anthropic sont passés de 2 500 à plus de 30 000 merges par jour entre mai et septembre, et git, avec ses 100 Go d’historique et ses centaines de miroirs internes, a fini par demander grâce. Sept personnes et Claude ont donc écrit en cinq mois Scion, un gestionnaire de versions où le serveur fait tout et le client plus rien, en gros SVN avec un meilleur service marketing, mais des checkouts cent fois plus rapides et une infra deux cents fois plus légère. Claude a cassé git, Claude a réécrit git, et tous les ingénieurs de l’équipe le jugent désormais meilleur qu’eux pour coder, leur métier consistant surtout à lui dire non, comme des parents. Des Claude « superfans » passent leurs journées dans Slack à rafraîchir les graphes d’un seul composant, et la file de merge a perdu son verrou : les changements se marchent dessus mais Claude répare plus vite qu’un humain ne s’en aperçoit, ce qui est aussi la définition exacte d’un incident que personne n’a vu. Ils remercient la communauté git pour vingt ans de travail, ne publieront pas Scion et vous préviennent que votre tour viendra d’ici six à douze mois, le temps d’acheter assez de tokens.

OpenCode 2.0 OpenCode 2.0 tourne désormais en serveur permanent sur votre machine, enchaîne vos serveurs MCP dans des scripts et peut s’écrire ses propres plugins en pleine session, le tout sur une API réécrite de zéro parce que l’ancienne, de leur propre aveu, était mauvaise. Les plugins 1.0 sont cassés mais il suffit de demander à OpenCode de migrer à votre place puisqu’il est le seul à savoir ce qu’il a cassé.

“An open source project that doesn’t have clear contribution guidelines is a project that doesn’t want contributors.” - Jono Bacon, auteur de The Art of Community