Les news du mois d'avril 2026
Elin Mel sur Unsplash
Avril est terminé, et il fut déjà le mois le plus chaud de l’année. Malgré la pluie et les inondations de cet hiver, nous sommes déjà en sécheresse sur une bonne partie du pays et notamment en Bretagne !
Malgré cette nouvelle démoralisante, je vous ai sélectionné des articles intéressants à tout point de vue. Les thèmes sont les mêmes depuis le début d’année, à savoir comment l’IA générative bouscule nos habitudes, la souveraineté de nos infrastructures et de nos données et enfin des évolutions significatives de Kubernetes.
Bonne lecture !
📖 Sommaire du mois
- Cloud Native : Kubernetes 1.36 (MutatingAdmissionPolicies en GA, HPA Scale-to-Zero, User Namespaces stable), HAProxy Data Plane API, MinIO → RustFS, Prometheus → Elasticsearch, blog souverain avec Bunny.net
- Intelligence Artificielle : Qualité du code avec les agents IA, Claude Code + Obsidian + système de mémoire CLAUDE.md, Codeburn pour monitorer ses tokens, The AI Layoff Trap
- Programmation & PKM : Graphify, Java et l’IA
- Découvertes : Les émissions des datacenters resteront secrètes grâce au lobbying américain
☁️ Cloud Native et Infrastructure
Kubernetes 1.36 : les MutatingAdmissionPolicies passent en GA
La nouvelle version de Kubernetes (1.36) est une mise à jour majeure qui mérite que nous la testions avant de la déployer en production. Elle apporte des changements qui pourraient affecter nos applications.
Jusqu’ici, pour muter des ressources à l’admission (injecter un sidecar, forcer un label, modifier un namespace), il fallait déployer et opérer un webhook HTTP externe — avec tout ce que ça implique en termes de disponibilité, de certificats TLS, de latence ajoutée sur chaque appel API.
Avec la 1.36, les MutatingAdmissionPolicies passent en GA. La logique de mutation s’écrit désormais directement dans l’API server en CEL (Common Expression Language), sans aucun composant externe à déployer. Les webhooks existants continuent de fonctionner — mais les outils qui n’auraient pas encore migré vers les MutatingAdmissionPolicies devront le faire à terme. D’ailleurs, j’avais dû coder un contrôleur Kubernetes pour injecter un sidecar Netbird à la volée dans mes pods applicatifs pour pouvoir accéder à un réseau distant via une connexion WireGuard. Il faudra changer le paradigme et la logique.
Quote
“Instead of building and operating external HTTP webhooks, you can define mutation logic directly inside the API server using CEL.”
La 1.36 apporte aussi d’autres changements intéressants :
- HPA Scale-to-Zero en Alpha pour les métriques Object/External — Ainsi les workloads pourraient être mis à zéro si une file SQS est vide par exemple. KEDA résout ce problème depuis longtemps ; l’intérêt ici est de réduire les dépendances externes au cluster.
- Node Log Query en GA —
kubectlpeut désormais récupérer les logs directement des nœuds sans SSH (avecNodeLogQueryactivé dans le kubelet) - User Namespaces en Stable — Un processus root dans le container n’est plus root sur l’hôte, ce qui limite l’impact d’une évasion de container.
- ComponentStatusz/ComponentFlagz en Beta — des endpoints
/statuszet/flagzstandardisés sur tous les composants du control plane
HAProxy Data Plane API : de SSH à REST
J’avais un besoin de contrôler la configuration d’HAProxy de manière dynamique à l’aide d’un contrôleur Kubernetes. Cet article de Stéphane Thirion nous explique comment la gestion du load balancer passe de l’artisanat à l’automatisation grâce au Data Plane API.
L’idée derrière cette API : un daemon REST qui tourne à côté de HAProxy et expose l’intégralité de sa configuration via des endpoints HTTP. Ainsi, tout est modifiable à chaud via des appels API, avec un système de transactions pour grouper les changements. C’est l’idéal pour mon besoin de gérer mon HAProxy via le contrôleur Kubernetes
Quote
“Data Plane API supports cluster mode. Changes on one node sync to the others automatically. No more manual rsync.”
Ainsi, les modifications de configuration deviennent des opérations idempotentes, rejouables, automatisables depuis un pipeline CI ou un outil IaC. C’est le chaînon manquant pour intégrer HAProxy dans un workflow GitOps.
MinIO → RustFS : migration sans douleur
Si comme moi, vous avez un code legacy qui s’appuie sur Minio pour gérer son stockage objet, il est temps pour vous de passer à autre chose. En effet, Minio a fait l’annonce de la fin des mises à jour de sécurité pour l’édition open source.
Différentes solutions existent en open source et celles qui reviennent souvent sont
RustFS se présente comme le successeur naturel : compatible S3, écrit en Rust, sous licence Apache 2.0. Et la promesse est simple : remplacement binaire drop-in. L’infra de stockage existante est réutilisée intégralement, et les clients S3 continuent de fonctionner sans changement.
Quote
“RustFS is fully S3-compatible. This conversion does not introduce significant changes to existing workflows.”
Pas de migration de données, pas de changement d’API, pas de reconfiguration des clients. Juste un binaire à remplacer. Je l’ai testé sur mes workloads de démonstration et la promesse tient — à valider sur des volumes de production avant toute migration critique.
Prometheus → Elasticsearch : une ligne de config
Elasticsearch supporte désormais nativement le protocole Remote Write de Prometheus.
En pratique : vous ajoutez un bloc remote_write dans votre config Prometheus pointant vers Elasticsearch, et vos métriques arrivent directement dans des Time Series Data Streams (TSDS) optimisés pour le stockage long terme. Et vos dashboards Grafana avec des requêtes PromQL continuent de fonctionner. Elasticsearch inférera automatiquement le type de métrique (counter vs gauge) depuis les conventions de nommage.
Quote
“ES|QL embraces PromQL: a built-in PROMQL function lets your existing queries run unchanged.”
Et côté stockage, les TSDS avec leur partitionnement temporel et leur compression font d’Elasticsearch un candidat crédible pour remplacer un Thanos ou un Cortex dans des architectures qui ont déjà de l’Elasticsearch en place.
La seule limite actuelle : seulement Remote Write v1 est supporté. La v2 (histogrammes natifs, exemplars) est planifiée mais pas encore implémentée — ce qui est bloquant si vous avez migré vers les histogrammes natifs de Prometheus 3.x. Pour une architecture Prometheus 2.x avec métriques classiques, la v1 suffit largement.
En pratique : si Elasticsearch est déjà dans votre stack, c’est une piste sérieuse pour remplacer Thanos ou Cortex sans ajouter un outil de stockage dédié.
Blog souverain : Hugo + GitLab CI + Bunny.net
Pour la migration de mon blog, je cherchais une alternative européenne à Github et à Cloudflare. En faisant mes recherches de solutions, j’ai trouvé ces deux articles intéressants pour héberger un site statique en 2026. La conclusion : Bunny.net est actuellement la meilleure option européenne.
L’article de TechCube détaille l’architecture complète : Hugo génère le site, GitLab CI orchestre le build et le déploiement, le state OpenTofu est stocké dans le backend HTTP de GitLab, et Bunny.net fait office à la fois de stockage objet (storage zone) et de CDN (pull zone).
Quote
“J’ai testé les CDN européens : KeyCDN, Gcore, OVHcloud, Myra Security, BlazingCDN. Un seul a répondu à mes critères : Bunny.net. C’est le seul CDN européen à proposer un provider Terraform.”
L’article de jola.dev apporte le complément : une migration concrète de Cloudflare vers Bunny.net, avec les forces (performances comparables, tarifs agressifs, société slovène indépendante) et les limites (minimum 1$/mois).
Quote
“Bunny.net is a Slovenian (EU) company that is building up a lot of momentum. Their CDN-related services rival Cloudflare already.”
De l’idée au déploiement en un git push — Dropping Cloudflare for bunny.net
🤖 Intelligence Artificielle
Qualité du code avec les agents : la discipline avant tout
Un article sous forme de REX qui explique comment utiliser sereinement un agent de code pour l’implémentation de nouvelles fonctionnalités. Et c’est exactement le genre de REX qui manque dans la littérature tech actuelle.
Le constat de départ :
Quote
“Most of the advice out there covers the basics – write a good CLAUDE.md, keep it short, plan before you code. This is about what we learned after the basics stopped being enough.”
Un des problèmes récurrents est de définir ce que nous attendons exactement. Ainsi, demander à un agent de “reviewer le code” ne fonctionne pas si vous n’avez jamais défini ce que “correct” signifie.
Quote
“Before you can write a single useful rule for the agent, the team needs to have made the decisions. How do modules communicate? How do you handle filtering? What goes in a repository and what doesn’t?”
Ce que l’auteur explique dans cet article est qu’il faut repenser le contenu du CLAUDE.md ou de l’AGENT.md. L’idée est d’ajouter la transcription de décisions déjà prises par l’équipe. Et quand l’agent fait une erreur architecturale, plutôt que de corriger silencieusement le code, ils lui demandent pourquoi — parce que le raisonnement révèle exactement quelle règle est manquante.
Quote
“When you fix the code, you fix one file. When you add the rule, you fix every file the agent will ever write.”
Une lecture intéressante à tout point de vue.
Claude Code + Obsidian : le vault qui apprend
Andrej Karpathy a encore frappé. En tweetant son modèle de “LLM Knowledge”, il a déclenché une vague d’implémentations plus ou moins différentes de son LLM Wiki. Son approche ne me convient pas pour gérer mon second cerveau avec Obsidian et Claude Code.
En cherchant comment alimenter mon obsidian de manière efficace, j’ai trouvé ces deux ressources sur la combinaison Claude Code / Obsidian qui pourraient être mes sources d’inspiration.
Le premier article de Kristopher Dunham sur Medium explore comment transformer Obsidian d’un cimetière de notes en un second cerveau actif avec Claude Code.
Quote
“You stop thinking of your knowledge base as a thing you manage. You start thinking of it as a thing you feed.”
L’agent peut faire une recherche sémantique sur des milliers de fichiers interconnectés et faire remonter des connexions entre des idées écrites à six mois d’intervalle. Ce qui résonne avec ma propre pratique.
En complément, le tutoriel SFEIR Institute sur le système de mémoire CLAUDE.md offre un éclairage plus technique sur les mécanismes : mémoire utilisateur globale (~/.claude/CLAUDE.md), mémoire projet (racine du dépôt), mémoire locale (dossiers enfants).
Le fichier projet se versionne avec Git — c’est le seul moyen de partager les conventions avec toute l’équipe sans effort de synchronisation.
Quote
“Les projets utilisant un fichier CLAUDE.md bien structuré réduisent significativement le nombre de rappels manuels nécessaires au cours d’une session.”
Claude Code and Obsidian — Le système de mémoire CLAUDE.md
Bref, de quoi m’inspirer pour alimenter mon vault obsidian et le maintenir dans le temps.
Codeburn : combien coûtent vraiment vos sessions ?
Avec l’arrivée de nouveaux modèles ce mois-ci aussi bien du côté d’Anthropic que du côté d’OpenAI, il est de plus en plus important de surveiller sa consommation de token.
Un outil pratique découvert cette semaine : Codeburn, un dashboard TUI pour visualiser la consommation de tokens de Claude Code, Codex et Cursor.
Il fonctionne en lisant directement les fichiers de session depuis le disque — pas de wrapper, pas de proxy, ou encore de clé API à configurer.
Les fonctionnalités utiles : taux de succès en un shot par type d’activité, comparaison de modèles côte à côte, et surtout codeburn optimize qui scanne votre setup ~/.claude/ pour identifier les patterns de gaspillage courants.
Pour ceux qui gèrent un budget de tokens d’équipe, c’est un outil à avoir sous la main.
The AI Layoff Trap : le piège du dilemme du prisonnier
Le podcast Tech Café ce mois-ci a couvert une étude de mars 2026 publiée par des chercheurs de l’université de Pennsylvanie et de Boston. Son titre : The AI Layoff Trap. Le mécanisme qu’elle décrit est simple et inquiétant.
Chaque entreprise a individuellement intérêt à automatiser pour réduire ses coûts. Si les autres ne le font pas, elle gagne un avantage compétitif. Si les autres le font aussi, elle est obligée de suivre pour ne pas être distancée.
Résultat : tout le monde automatise, les revenus globaux baissent, la consommation chute — et les entreprises elles-mêmes perdent des clients.
Quote
“C’est le dilemme du prisonnier appliqué à l’IA : chacun fait un choix rationnel individuel, et tout le monde perd collectivement.”
Les auteurs parlent de surautomatisation destructrice. Les solutions classiques — formation, redistribution, revenu universel — ne suffisent pas selon eux car elles ne changent pas les incitations des entreprises. Ils proposent des taxes pigouviennes sur les tâches automatisées pour corriger l’externalité négative.
Un sujet qui méritera son propre article tant il touche au cœur de ce qui se joue dans notre industrie.
Dans le même épisode, mention du lancement de Claude Design par Anthropic : un outil qui transforme un brief textuel en maquette d’interface directement exploitable par un agent de développement. Si ça fonctionne comme annoncé, est-ce la fin du tunnel Figma → développeur pour les projets pilotés par IA ?
💻 Programmation & PKM
Graphify : un vault en graphe de connaissances
Graphify est un outil qui prend une approche radicalement différente du contexte pour les agents IA. Plutôt que de charger des fichiers bruts, il parse tout votre dossier — code (tree-sitter pour 20 langages), PDFs, images, vidéos (faster-whisper pour la transcription) — et construit un graphe de connaissances structuré avec des nœuds étiquetés et des scores de confiance.
Quote
“It builds a persistent, queryable knowledge graph from your code, docs, papers, images, and video — by up to 71.5x.”
Ce qui m’intéresse particulièrement : le flag --obsidian qui génère un vault avec backlinks automatiques, et la capacité à s’intégrer comme skill dans un orchestrateur via un hook PreToolUse.
Le projet revendique des gains de performance de l’ordre de 71,5x pour certains types de requêtes. Des chiffres à prendre avec des pincettes, mais l’approche sémantique par graphe est clairement supérieure au grep, outil utilisé par défaut pour la recherche de fichiers.
Java et l’IA : l’âge d’or revient avec Julien Dubois
Le podcast IFTTD a reçu Julien Dubois, créateur de JHipster, pour parler de Java et l’IA. Une discussion qui surprend par sa pertinence : Java, longtemps perçu comme le langage corporate par excellence, retrouve une nouvelle jeunesse avec Spring AI et LangChain4J.
Ce qui est intéressant dans ce podcast : Julien a passé plus de 10 ans à faire de la génération de code (JHipster, c’est fondamentalement ça), et il regarde les LLMs avec l’œil de quelqu’un qui connaît le problème de l’intérieur.
Quote
“Moi je faisais de la génération de code il y a plus de 10 ans. Et maintenant avec l’IA on a de la génération de code intelligente. C’est assez amusant de relier mon hobby de l’époque à mon boulot d’aujourd’hui.”
Sa nuance sur les agents IA est utile : ils sont très forts pour comprendre l’intention d’un projet et continuer dans la même direction — ce que JHipster ne savait pas faire après la génération initiale. À écouter sans modération.
🎲 Découvertes insolites
Datacenters américains en Europe : les émissions resteront secrètes
Microsoft et d’autres grandes entreprises tech américaines ont fait pression sur l’Union Européenne pour que les données d’émissions de leurs datacenters restent confidentielles. Et ça a fonctionné !
Quote
“With demands to block a database of green metrics from public view written almost word for word into EU rules.”
En pratique : les chercheurs et le public n’auront accès qu’à des résumés nationaux agrégés, et non directement aux données par datacenter. Au moment où l’UE prévoit de tripler sa capacité datacenter d’ici 5 à 7 ans pour se positionner sur l’IA — et où seulement 36% des datacenters éligibles ont déjà respecté les obligations de reporting existantes — c’est un recul de transparence significatif.
Ce qui rend cette histoire particulièrement amère : l’Europe était en train de construire un cadre de reporting sérieux sur l’empreinte environnementale du numérique. Il a suffi d’une campagne de lobbying pour que ce cadre soit vidé de sa substance avant même d’exister. À lire sur le site du Guardian.
📊 Ma veille en chiffres (avril)
- Articles lus : 58 articles sélectionnés (+ flux RSS et threads)
- Podcasts écoutés : 24 podcasts sélectionnés
- Thème dominant : Claude Code et gestion des connaissances, modernisation Kubernetes
- Découverte du mois : RustFS comme alternative à MinIO
- Lecture en cours : Bleus, Blancs, Rouges
❤️ Mon coup de cœur du mois
Être ou ne pas être D.E.V. — IFTTD avec Antonio Goncalves
Le podcast IFTTD #305 avec Antonio Goncalves pose une question qui semble simple mais qui résonne différemment en 2026 : qu’est-ce que c’est, être développeur ?
Antonio raconte l’histoire d’Alex, qui est devenu développeur non pas en suivant une école d’ingénieurs, mais en construisant un produit. Et il met ça en perspective avec ce que les LLMs changent aujourd’hui : le code se génère de plus en plus automatiquement, mais le métier de développeur — shipper, tester, sécuriser, scaler, répondre des incidents — lui, ne se génère pas.
Quote
“C’est qu’il faut shipper, il faut déployer, il faut tester, il faut sécuriser, il faut scaler. C’est Claude Code, le copilote. Et développeur, c’est nous.”
Ce qui m’a particulièrement plu : la digression sur l’origine du mot patch. Les cartes perforées, les mauvais trous qu’on bouchait avec du scotch — le patch, c’est le petit bout de tissu qu’on recoud sur un tissu troué. Débuguer, c’est faire du patchwork depuis 70 ans !
Quote
“En fait, quand on débug, on fait du patchwork. Comme ta grand-mère qui fait une couverture avec un bout de tissu.”
Un épisode léger mais qui pose une vraie question d’identité professionnelle à un moment où la frontière entre “codeur” et “développeur” est en train de se redessiner.
Pour conclure
Encore une belle sélection d’articles mais c’est de plus en plus difficile de suivre l’actualité entre les annonces tonitruantes des géants de la tech, les conséquences de la géopolitique au Moyen-Orient sur l’économie et les différents sujets qui m’intéressent.
Ce fut déjà l’objet d’un article et ce sera l’objet d’un talk que je présenterai au BreizhCamp 2026 à Rennes le vendredi 26 juin. Ce sera ma première participation à cet évènement et juste en face de mon bureau à Teralab.
À bientôt pour la sélection de mai !
À lire aussi : mes précédents articles sur le blog