LLM on Zwindler's Reflection

GenAI et développement logiciel, épisode 2 : kubectl-debug-pvc, de l'idée à krew en 2x30 minutes

Tue, 17 Mar 2026 18:00:00 +0100

Précédemment, dans “GenAI et dev”

Dans mon article précédent, je vous parlais de mon retour d’expérience avec PodSweeper, un projet développé avec OpenCode et Claude Opus. Le bilan était nuancé : vitesse brute impressionnante, mais race conditions, gestion d’erreur laxiste, et nécessité constante de supervision humaine (entre autres déconvenues).

Aujourd’hui, je vous parle d’un deuxième projet, bien plus simple, né d’un vrai besoin en production. Et le constat est assez différent.

L’incident qui a tout déclenché

Vous connaissez peut-être cette situation : un pod en production, en état de fonctionnement, qui utilise un PVC en ReadWriteOnce. Vous avez besoin d’aller regarder le contenu de ce volume. Bonne pratique de production : le pod en question ne dispose pas de shell (on réduit la surface d’attaque). Pas de /bin/sh, pas de /bin/bash, rien.

Pas grave, on a kubectl debug pour ça, me direz-vous !

Ok, créons un conteneur éphémère dans le pod et… ah non. kubectl debug ne permet pas de monter les volumes du pod dans le conteneur éphémère. Il n’expose tout simplement pas l’option volumeMounts pour les conteneurs éphémères.

On pourrait couper le pod, ce qui permet de monter le PVC RWO dans un autre pod avec un shell, mais on n’a pas envie, c’est de la prod.

Mon collègue Maxime (encore lui !) me propose une méthode de contournement. La procédure manuelle, c’est :

Créer un conteneur éphémère sur le pod avec kubectl debug
Construire à la main un patch JSON pour ajouter des volumeMounts au conteneur éphémère qu’on vient de créer
Dans un autre terminal, se brancher ~~au cul du camion~~ sur l’API de kube en direct avec kubectl proxy
Appliquer le patch via un curl sur l’API Kubernetes
Attendre que le conteneur soit prêt, s’attacher au conteneur
Se dire qu’il y avait quand même plus simple comme métier que patcheur de container à coup de curl.

Pour ceux qui pensent que c’est jouable, “téma la gueule du patch” comme disent (disaient ?) les jeunes :

curl http://localhost:8001/api/v1/namespaces/<namespace>/pods/<pod>/ephemeralcontainers \
 -X PATCH \
 -H 'Content-Type: application/strategic-merge-patch+json' \
 -d '{
 "spec": {
 "ephemeralContainers": [
 {
 "name": "debugger",
 "image": "ubuntu",
 "command": ["/bin/sh"],
 "targetContainerName": "<target-container>",
 "stdin": true,
 "tty": true,
 "volumeMounts": [
 {
 "name": "<volume-name>",
 "mountPath": "/debug/<volume-name>"
 }
 ]
 }
 ]
 }
 }'

Si vous pensez que c’est error prone, vous avez raison. Et si vous pensez que c’est pénible à faire sous pression pendant un incident de prod, vous avez encore plus raison.

Side note

Les plus aguerri·es d’entre vous dans les versions récentes de Kubernetes ont peut être entendu parler du KEP-2590, qui introduit un (relativement) nouveau flag --subresource de kubectl. En effet, les containers éphémères créés par la commande kubectl debug ne sont pas des resources (un pod, un deployment, …) mais des subresources.

Jusqu’à cette version 1.33, il était littéralement impossible de réaliser des opérations sur les subresources avec kubectl, seulement les resources.

Kubernetes v1.33: Octarine apporte le support du flag –subresource, mais seulement pour 3 subresources pour l’instant status, scale and resize

Pas de solution de ce côté-là non plus…

Le prompt de réunion

J’avais cette idée en tête depuis l’incident. Lundi matin, au début d’une réunion (pendant que les gens faisaient encore des blagues), j’ai lancé OpenCode avec Claude Opus et j’ai tapé un prompt qui décrivait :

Le problème : kubectl debug ne monte pas les volumes PVC s’ils sont en RWO
La procédure manuelle que je faisais à la main (les étapes douloureuses décrites un peu plus haut)
Ce que je voulais : un outil qui automatise tout ça

OpenCode + Opus m’ont posé 2 questions (et j’ai ajouté une consigne) :

“Quel langage ?” → Go (je persiste)
“CLI seule ou TUI ?” → Les deux (mode non-interactif pour le scripting, TUI pour l’usage quotidien)
Et je lui ai demandé de toujours vérifier à chaque fois qu’il estime avoir fini de lancer le linter golangci-lint (trauma de mon précédent test avec opencode)

Il est parti de lui-même sur l’idée d’une TUI avec Bubble Tea. Puis j’ai arrêté de regarder & j’ai suivi ma réunion.

~30 minutes plus tard, fin de la réunion, j’ai regardé le résultat. Le POC était fonctionnel.

Ce qu’Opus a produit en 30 minutes

Sans aucune intervention de ma part, le LLM a scaffoldé un projet Go complet :

Structure propre : cmd/ pour le CLI Cobra, pkg/k8s/ pour toute l’interaction Kubernetes, pkg/tui/ pour la TUI Bubble Tea
Le coeur du sujet : un appel direct à l’API Kubernetes pour patcher le subresource ephemeralcontainers du pod avec un strategic merge patch incluant les volumeMounts
Mode non-interactif : -n namespace -p pod -v volume:/mount/path, prêt pour le scripting
TUI complète : navigation vim-style (j/k), filtrage fuzzy (/), multi-sélection de volumes, spinner de chargement…
Makefile avec tout un tas de targets (vet, lint, test, build, install)

Ce que je lui ai demandé d’ajouter :

Discovery intelligente : au lieu de scanner tous les pods de tous les namespaces (lent sur un de mes gros cluster), l’outil liste d’abord les PVCs cluster-wide (un seul appel API) pour identifier les namespaces pertinents, PUIS les pods dans le namespace sélectionné. On réduit drastiquement le nombre d’appels à l’API server de kube et la TUI ne montre que les namespaces et pods qui ont des volumes PVC
Héritage du SecurityContext : le conteneur éphémère copie le securityContext du conteneur cible, ce qui lui permet de passer les PodSecurity policies (restricted, baseline…). C’est un cas que je n’avais pas envisagé dans mon prompt initial et qui a planté immédiatement sur un cluster bien configuré.

Sans ces petites améliorations le tool était déjà utilisable (sauf pour le cas où vous avez configuré des SecurityContext), mais c’est nettement plus confortable à l’usage (parce que oui, je l’utilise).

Le code de la mécanique centrale (le patch de l’API) fait quelques centaines de lignes de Go propre. Il récupère le pod, construit le patch JSON avec le conteneur éphémère et ses volumeMounts, l’applique via Patch() sur le subresource, attend que le conteneur soit Running, puis lance kubectl attach. Rien de sorcier, c’est juste ce qu’il faut, bien fait du premier coup.

 ephemeralContainer := corev1.EphemeralContainer{
 EphemeralContainerCommon: corev1.EphemeralContainerCommon{
 Name: containerName,
 Image: opts.Image,
 Command: []string{"/bin/sh"},
 Stdin: true,
 TTY: true,
 VolumeMounts: mounts,
 SecurityContext: targetSecurityContext,
 },
 TargetContainerName: targetContainer,
 }
...
 _, err = c.Clientset.CoreV1().Pods(opts.Namespace).Patch(
 ctx,
 opts.PodName,
 types.StrategicMergePatchType,
 patchBytes,
 metav1.PatchOptions{},
 "ephemeralcontainers",
 )

Les itérations suivantes (30 minutes-ish)

Une fois le POC validé, j’ai enchaîné quelques prompts ciblés. Je lui ai demandé ce qu’on pouvait améliorer. Il a proposé (et implémenté) :

quelques corrections mineures de code qu’il avait mal codé (mais non bloquant)
Warnings : si le SecurityContext hérité a readOnlyRootFilesystem, runAsNonRoot, ou autre mesure de sécurité, l’outil prévient l’utilisateur avant l’attach
Ajouté une CI complète à base de goreleaser et de github actions
Ajouté de la documentation

La cerise sur le Macdo : publication sur Krew

Une fois que j’avais une version propre, j’ai demandé à Opus comment faciliter l’installation du plugin. Il m’a proposé brew, ou alors Krew, le gestionnaire de plugins kubectl.

Je lui ai demandé si le processus d’acceptation du plugin était complexe. Il a dit que non, je lui ai dit “chiche !”.

Il a réalisé l’intégralité du processus :

Création d’un fork de krew-index
Rédaction du manifeste Krew (le fichier .yaml qui décrit le plugin)
Prise en compte de toutes les bonnes pratiques demandées par les maintainers de krew-index (format des URLs de téléchargement, descriptions courtes, checksums SHA256, etc.)
Préparation de la PR, directement sur krew-index

J’ai juste regardé. La PR a été mergée 12 heures plus tard par les mainteneurs.

Résultat : kubectl krew install debug-pvc fonctionne.

Mini échec - déléguer aussi la démo

Fort de ce succès avec la PR pour krew-index, je me suis demandé si on ne pourrait pas faire une démo visuelle (un GIF à ajouter dans le README.md du projet qui montre comment ça fonctionne) avec le LLM.

Je lui ai demandé s’il pouvait le faire avec asciinema et le LLM m’a répondu que “oui” (oui, je discute avec le LLM comme avec mes collègues). Banco, on a essayé.

Le résultat était presque bon, j’aurais pu m’en contenter si j’étais pas quelqu’un de pénible : c’était un poil lent. J’ai l’impression la réactivité du LLM dans ses actions était inégale, ce qui rendait le rendu un peu désagréable au visionnage. J’aurais pu insister jusqu’à avoir quelque chose de correct, mais j’ai finalement enregistré moi-même une vidéo, convertie en GIF avec ffmpeg. C’était plus fluide et plus rapide que d’itérer.

Le diff avec PodSweeper

La différence de ressenti entre ce projet et PodSweeper est frappante. Là où PodSweeper était un combat constant (race conditions, amnésie du LLM, fonctionnalités hors-spécifications), kubectl-debug-pvc s’est déroulé sans accroc notable.

Pourquoi ? Je pense que ça tient à la nature du projet :

Une seule chose à faire, clairement définie : patcher un subresource Kubernetes avec des volumeMounts
Pas de logique concurrente : on fait une requête API, on attend, on s’attache
Un domaine bien documenté : l’API Kubernetes, Cobra, Bubble Tea. Le LLM connaît tout ça par coeur
Pas d’état partagé complexe : pas de goroutines qui se marchent dessus, pas de graceful shutdown à gérer, de microservices multiples
Scope limité : le projet entier tient dans une quinzaine de fichiers, CI et documentation incluses

C’est probablement le terrain de jeu idéal pour un LLM. Un problème bien cadré, un domaine technique bien balisé, une solution linéaire.

Qu’est-ce que j’en pense ?

Objectivement, ce genre de projet “simple” (une chose à faire, simple à comprendre) marche vraiment super bien avec OpenCode + Opus. Je pense que c’est ce genre à cause (grâce) de ce genre de petits projets que la hype est tellement forte autour du développement agentique. On a une idée en tête qu’on avait la flemme de dev, on teste, ça marche. “WOW”.

Mais je ne veux pas non plus minimiser le travail réalisé. Le fait qu’un outil fonctionnel, propre, publié sur Krew et utilisable par n’importe qui ait pu émerger d’un prompt lancé en début de réunion, c’est quand même assez dingue.

Un peu flippant aussi, de se dire qu’un nombre hallucinant de micro tools vont apparaître dans les prochains mois, avec un niveau de qualité probablement inégal.

Le projet

Le code est disponible ici :

https://github.com/zwindler/kubectl-debug-pvc

Installation :

# Via Krew (recommandé)
kubectl krew install debug-pvc

# Utilisation interactive (TUI)
kubectl debug-pvc

# Utilisation non-interactive
kubectl debug-pvc -n my-namespace -p my-pod-0 -v data:/debug/data

Si vous aussi vous avez déjà galéré à inspecter un PVC sur un pod sans shell, essayez. Et si vous trouvez des bugs, vous pourrez blâmer le LLM 😄.

GenAI et développement logiciel : retour d'expérience avec PodSweeper

Sun, 08 Mar 2026 18:00:00 +0200

La GenAI, c’est fantastique ?

Pas mal de gens ont sorti leur avis sur la Gen AI pour dev en très peu de temps, alors je me rends compte qu’il est plus que temps que je poste ce brouillon commencé il y a plus de deux semaines 🙃.

Pour le travail, j’utilise de plus en plus d’assistants IA pour m’épauler dans mes tâches du quotidien. En 2024, c’était surtout pour automatiser des tâches pénibles (scripter des trucs, faire une liste pénible de tâches répétitives sans coder ça proprement). Courant 2025, j’ai testé plusieurs fois de lui faire faire de l’Ops et, à chaque fois, les résultats étaient moyens, tant pour concevoir une infra cohérente, fiable et efficiente que pour de l’assistance à la résolution d’incident (cf. mon article sur le sujet).

En 2026, sur ce dernier point, je trouve qu’on n’a toujours pas avancé, même si je reconnais qu’il existe des outils spécialisés que je n’ai pas encore suffisamment testés, open source ou non. Je peux citer k8sgpt et HolmesGPT en open source, et Anyshift avec son agent SRE pour la détection de root cause et la résolution d’incident.

Note : fun fact, dans son post “Mon positionnement sur l’Intelligence Artificielle Générative” posté juste avant moi, Alex cite une longue liste de métiers qui vont profiter de l’IA Gen, et les ops ont le droit à rien d’autre qu’un argument de plus pour passer sur Kube 😭.

J’ai en revanche commencé à utiliser la GenAI pour réaliser plusieurs projets de sites web à 100% (vibe coding ?), dont je vous ai d’ailleurs déjà parlé :

Convertir un blog de Bloggrify à Hugo
Créer un site “joli” (largement au-delà de mes compétences) pour héberger les recherches que j’ai faites sur les différentes façons de déployer Kubernetes
Améliorer la sécurité de mon site web en automatisant la modification du thème Hugo que j’utilise, de manière à avoir la meilleure note sur Mozilla HTTP Observatory

Dans les 3 cas, le résultat est là. Ou plutôt, il semble l’être pour le béotien que je suis.

Je n’ai jamais caché que je n’ai aucune compétence en front, et peut-être que pour un expert du domaine, ce que j’ai fait avec l’IA est horrible (ou non ?). Dans tous les cas, ça ne peut pas être pire que les UIs que j’ai faites sans. Petit exemple 😄 :

ou alors : la GêneAI ?

C’est le genre de retours qu’on voit fleurir de la part de toutes les personnes qui sont vraiment expertes d’un domaine quand elles voient des novices s’extasier. On a de bons exemples avec les vidéos générées par IA : si on ne fait pas attention, on a l’impression que c’est incroyable. Mais n’importe qui avec un œil un peu critique voit tout de suite de GROS problèmes de cohérence. Pareil pour la génération d’image, ou de musique.

C’est aussi vrai pour le code, et on a de très bons exemples de projets vibe codés qui sont d’immondes plats de spaghetti, et des passoires en termes de cybersécurité. Bref, vous l’aurez compris, j’ai beau être utilisateur (quotidien), je ne suis pas “incroyablé” (comme disent mes enfants) par les LLMs, même les meilleurs.

Pourtant, j’ai plusieurs copains qui ne jurent que par ça, notamment des gens bien plus brillants / intelligents (appelez ça comme vous voulez) que moi. Donc je me dis “OK, peut-être que je m’y prends mal. Essayons avec ce qui se fait de mieux” : un IDE type “Claude Code” et un modèle Opus.

L’éditeur

Après avoir fait une petite étude de marché rapide, on se rend compte que les options sont pléthoriques : Claude Code, OpenCode, Amp Code, …

Le problème de Claude Code, c’est le ticket d’entrée. Je ne suis pas encore prêt à lâcher 100 ou 200 € par mois pour l’usage que j’en ai aujourd’hui. Je ne sais pas si l’offre à 20€ me suffirait ou non. Au-delà de rares side projects perso que j’ai cités plus haut, je code peu. Le gros de mes geekeries, c’est de l’infra : installer des Kube et des OS de virtualisation. Des trucs difficiles à automatiser avec un LLM.

On (Pierre surtout) m’a conseillé Amp Code pour du perso, notamment parce que de base, il y a un tier gratuit avec un certain nombre de tokens et que si on n’est pas trop gourmand, c’est assez efficace. J’ai préféré n’en faire qu’à ma tête et tester plutôt sur OpenCode, qui a l’avantage d’être plus flexible sur les providers de LLM et la consommation de tokens. Il est d’ailleurs possible de profiter de modèles locaux (gratuits, donc) ou des modèles inclus gratuitement (en tout cas pour l’instant) tels que GLM 5 Free, qui est plutôt bien placé dans les modèles de dev (surtout, c’est gratuit…).

OK, on a l’éditeur. Maintenant, le code ?

Pour me faire une idée de la pertinence du code généré par mon LLM favori (Sonnet et Opus, depuis un moment), il me faut donc un langage et un cas d’usage que je maîtrise, pour être capable de lui dire “non mais là, c’est n’importe quoi !?”.

Cas d’usage que je maîtrise… vous vous en doutez, il y aura forcément du Kubernetes dedans.

Langage que je maîtrise : j’ai appris Go en 2022 grâce à un collègue de chez Deezer (encore merci Martial !) et j’ai publié quelques outils et fait des contributions mineures. J’ai écrit une grande partie de l’outil GroROTI et aussi commencé (mais jamais terminé) le développement d’un RPG en Go, fortement inspiré de Castle of the Winds, un jeu de mon enfance : gocastle. Et j’ai une capacité professionnelle (même si ce n’est pas le coeur de mon métier) dans mon travail de tous les jours.

Après le contexte, le projet

OK, on a le contexte technique : Kube + Go. Reste donc l’idée à implémenter. Il faut un projet suffisamment volumineux pour que le test soit pertinent, suffisamment rigolo pour que j’aie envie d’y passer du temps perso, mais quand même un peu utile pour que j’aie envie d’en parler et de montrer l’avancement. Et surtout, un projet dont la logique métier reste à ma portée : pour évaluer honnêtement la qualité du code produit par l’IA, il faut que je sois capable de le relire et de le critiquer.

Et là, dans mes tiroirs à idées débiles qui débordent de mon cerveau, je me suis souvenu de ce “pitch” de 2023-2024, que j’avais laissé moisir faute de temps :

PodSweeper : la manière la plus complexe, over-engineerée et chaotique de jouer au démineur.

Partez pas, vous allez voir c’est rigolo. Si !

Au lieu d’une grille visuelle où on clique sur des cases en espérant ne pas tomber sur une “mine”, on a une “grille” virtuelle où chaque case est un Pod et le clic est un kubectl delete.

Oui, c’est débile. Ça me plaît donc beaucoup :).

Au-delà du troll assumé (over-engineering des enfers) de ce jeu, il y a quand même un objectif pédagogique derrière.

Si, si, vraiment.

J’ai pensé le jeu comme une introduction à la sécurité dans Kubernetes, avec des niveaux de difficulté à débloquer, façon CTF de cybersécurité.

Au début, vous pouvez tout faire. Vous pouvez bien sûr jouer normalement (delete un Pod, voir s’il y a des mines à côté) pour vous faire la main. Vous pouvez aussi automatiser les actions (un script qui “clique sur une case” au hasard, récupère les hints de proximité de mines, clique à un endroit safe, …).

Mais vous pouvez aussi tricher.

Et c’est tout l’intérêt du jeu. Dans les premiers niveaux de difficulté, les manifests Kubernetes du jeu sont volontairement vulnérables. On peut donc gagner sans effort, si on sait où chercher.

Cependant, très vite, les niveaux s’enchaînent et les restrictions avec. Assez rapidement, on arrive dans des bonnes pratiques de production qui empêchent toute “triche”. Et si vous trouvez des vulnérabilités non prévues dans le code du jeu lui-même… eh bien, c’est du bonus 😈.

Le processus initial

C’est probablement une erreur, mais j’ai fait toute la phase d’idéation avec Gemini avant de lancer OpenCode. L’expérience aurait probablement été meilleure (a minima plus représentative) si j’avais commencé directement avec OpenCode.

J’ai pondu tout ce que j’avais dans la tête, ainsi qu’un gros pavé informe de dizaines de lignes provenant de mes notes de quand j’ai eu l’idée en 2023, et je lui ai demandé de me sortir un fichier SPECIFICATIONS.md avec toutes les infos importantes, remises dans l’ordre.

Une fois les specs écrites, je lui ai demandé de détailler les différents niveaux et les difficultés que nous allions progressivement ajouter, dans GAMEPLAY.md.

Enfin, j’ai demandé de faire un découpage du projet par “issues” et par priorité, de manière à avoir un MVP rapidement : ISSUES_PRIORITY.md. Mon idée était de donner le plan de bataille très détaillé et découpé finement à OpenCode et de lui laisser dérouler.

Première déconvenue : Gemini 3 Pro est assez mauvais pour ça. Les tâches étaient crédibles(-ish) mais ordonnées n’importe comment (dépendances entre tâches non respectées). J’ai donc lancé pour la première fois OpenCode dans mon repo et je lui ai dit “voilà le contexte, voilà ce qu’on a imaginé comme tâches. Qu’est-ce que tu en penses ?”.

Le bon (open)code…

Dans les trucs assez chouettes : OpenCode + Claude Opus a tout de suite vu que le plan imaginé par Gemini était bancal, et m’a posé des questions et proposé un découpage encore imparfait mais déjà plus cohérent. C’est probablement là le gros de l’intérêt de ces logiciels. Ils embarquent des connaissances pour guider le développement logiciel et surtout (SURTOUT) apportent du cadre.

Assez vite, on finit par se mettre d’accord sur un plan qui me plaît. OpenCode met à jour les documents et se met à développer (scaffolding, création des pipelines, premiers binaires et images Docker vides). On a un projet prêt à développer en un claquement de doigt, c’est assez enthousiasmant, de prime abord.

Les assistants LLMs ont très envie de se jeter dans le code, ça reste vrai avec OpenCode+Opus. Alors même qu’on n’avait pas fini de discuter du plan et des options possibles, il me proposait de lui-même de passer au code. Cela dit, c’était pareil (voire pire) pour Gemini (à qui j’avais dit spécifiquement qu’on n’allait pas faire de code du tout).

Très vite, les créations de fichiers s’enchaînent. J’ai du mal à suivre et à chaque pause (quand le LLM a fini une tâche et qu’il me demande s’il peut passer à la suivante), je prends de longues minutes à lire ce que le LLM a produit. C’est à la fois grisant et épuisant (relire tout ça, c’est dur pour mon cerveau rouillé).

La vitesse brute est impressionnante. En 3 sessions de 1 à 2h, j’ai un MVP fonctionnel. Je comprends qu’on parle régulièrement de 10x engineering quand on parle de génération de code avec les LLMs récents. Si on ne parle pas de génération de code brute (ce qui n’a pas vraiment de sens), à la louche, le code fonctionnel est généré entre 3x et 10x plus rapidement que ce que j’aurais pu faire seul. Des features qui mises bout à bout m’auraient pris des heures à implémenter (génération de la grille, logique de reveal, gestion des états de jeu) tombent en quelques minutes. Vous l’avez déjà lu ailleurs, je dis pareil - le goulot d’étranglement, ce n’est plus le code que je tape : c’est le code que je dois relire.

De ce que j’ai lu, le code est correct, en particulier lors des premières itérations, un peu moins au bout d’un moment. Mais quand je dis “correct”, je sous-vends peut-être le truc : le code produit est du Go idiomatique. Bonne structure en packages, conventions de nommage respectées, gestion d’erreur dans le style Go (quand elle est là…), utilisation appropriée des interfaces. Ce n’est pas juste du code qui compile : c’est du code qu’un reviewer Go ne rejetterait pas d’emblée. On a pour objectif un MVP donc ça reste de la logique “métier” très simple, mais le socle est propre.

Tout est testé, très vite le projet contient une couverture parfaite et 100+ tests alors qu’on ne fait encore rien. Si c’était du code généré par un humain, je ne saurais pas dire si c’est une bonne chose. On est pas du tout dans du TDD, beaucoup de code teste des choses inutiles. Dans le cas du code généré par le LLM, c’est probablement pour le mieux, car le LLM a tendance à ajouter très régulièrement des régressions (on en reparlera). C’est donc intéressant ici, car :

ça ne coûte quasiment rien en temps de dev (ça va tellement vite à générer)
cela permet au LLM de se rendre compte que son code introduit une régression, et de fixer de lui-même, sans attendre.

… et le mauvais (open)code

Côté outil et modèle d’abord, quelques irritants :

Par défaut, OpenCode n’incite pas le LLM à lancer golangci-lint à chaque commit. On corrige ça avec un pre-commit hook et/ou les fameux AGENTS.md / skills, mais ça aurait DÛ faire partie du kit de base d’un projet golang (il y a bien les tests…).
Le LLM (Claude Opus sur OpenCode, mais c’est un biais habituel même en dehors) adore les versions de logiciels qui existaient au moment de son entraînement. Il faut continuellement lui répéter que les versions qu’il suggère sont obsolètes. C’est vrai pour tout : le code Go, les dépendances, les versions des actions GitHub.
On tombe très souvent dans la limite des 100k tokens. On perd du temps à “compacter” et on perd de la précision. Typiquement : le LLM me demande s’il peut git commit des modifs, le contexte se compacte avant que je réponde, et il commit sans mon autorisation en redéroulant le contexte. Sur du code aussi peu sensible, ça va. Mais sur de la prod, ça serait un vrai problème.
Le LLM est souvent amnésique : il oublie qu’il a accès à un cluster kind pour faire des tests réels (alors qu’il l’a fait juste avant la précédente compaction, par exemple).

Côté qualité du code produit, c’est plus préoccupant :

Gestion d’erreur laxiste. Certaines erreurs qui auraient dû retourner un FATAL (controller qui n’arrive pas à s’initialiser correctement !) sont simplement logguées comme ERROR. On se retrouve à ship des versions qui échouent silencieusement. Là encore, ça doit pouvoir se fine tuner avec un AGENTS.md.
Race conditions. Je suis tombé très vite sur des race conditions assez bêtes. Dans mon cas, des pods bloqués en terminating impactaient le jeu suivant (graceful shutdown mal géré). Opus est parti en boucle sans comprendre la source du problème. J’ai dû le stopper et lui spécifier qu’il ne fallait jamais lancer une nouvelle partie sans s’être assuré que la précédente était terminée.
Génération de code en dehors des clous. Parfois, sans crier gare, le LLM ajoute une fonctionnalité qui n’est pas demandée, inutile, voire qui va à l’encontre de la SPECIFICATION écrite précédemment. On est obligé de lui remettre un taquet derrière la tête.

Une fois remis sur les rails, le LLM déroule à nouveau, mais ces épisodes montrent bien que sur du code concurrent ou en dehors de user stories hyper strictes (ce qui sort du workflow de base d’opencode), la supervision humaine reste indispensable.

On me répondra que je débute avec ces outils, et que j’aurais pu éviter certains écueils en configurant mieux mon environnement (AGENTS.md, pre-commit hooks, etc.). C’est vrai.

Mais c’est justement là que le bât blesse : une des promesses vantées de la GenAI appliquée au dev, c’est de permettre à des non-développeurs (ou des débutants) de produire du logiciel de qualité à grande vitesse, de manière à pouvoir ship des logiciels complets. Si pour en tirer le meilleur, il faut déjà être un développeur expérimenté qui sait configurer un environnement complexe (avec les spécificités de ces outils IA), anticiper les race conditions et relire du code concurrent… on n’a pas démocratisé le développement, on a juste donné un outil de plus aux gens qui savaient déjà coder. Mon profil (ops qui code, pas dev pur jus) était précisément le public cible de cette promesse. Et aujourd’hui, “les calculs sont pas bons, Kévin”.

Où j’en suis ?

Depuis tout à l’heure, je vous parle de PodSweeper. Mais il en est où, ce projet ?

Après 3 sessions de 1 à 2h max, sans compter l’idéation, j’ai un MVP fonctionnel. Comme je l’ai dit plus haut, le gain de productivité est indéniable, pour quelqu’un qui n’est pas “dev” de métier.

Le code est probablement “globalement” de meilleure qualité que le code golang que j’aurais pu écrire, mais le LLM laisse passer des trous béants dans la logique métier (tout simplement parce qu’il ne réfléchit pas, alors que moi, oui. Enfin, normalement). Dur pour la confiance… Il faut vraiment rester très méfiant de tout ce qui est produit.

Le code est disponible à l’adresse suivante :

https://github.com/zwindler/PodSweeper/tree/main

Vous pouvez aller voir le code pour vous faire une idée. Si vous n’avez pas peur de vous spoiler, vous pouvez lire la SPECIFICATION.md (spoilers), voire GAMEPLAY.md (j’y détaille tous les niveaux donc c’est giga spoilers).

Vous pouvez (normalement) jouer aux premiers niveaux de difficulté. Ça reste assez basique, si vous avez déjà manipulé kubectl vous devriez trouver la solution très rapidement. Mon but est de rajouter des niveaux au fur et à mesure, j’en ai déjà imaginé 10, certains bien retors 😈 et d’autres viendront peut-être ensuite.

Le code est en MPL v2.0 parce que c’est une licence copyleft que j’aime bien, car elle est à la fois assez peu restrictive, OSI compliant et oblige quand même à reverser les modifs si on en fait dans son coin.

Voilà :) si vous aussi vous trouvez ça rigolo, n’hésitez pas à tester et/ou à me faire des retours.

$ kubectl apply -k https://github.com/zwindler/podsweeper//deploy/base?ref=v0.1.4
namespace/podsweeper-game created
...

$ kubectl wait --for=condition=ready pod -l app.kubernetes.io/name=podsweeper \
 -n podsweeper-game --timeout=60s
pod/gamemaster-54f4dddcc4-6m88z condition met

Have fun !

Réflexions sur le blogging technique à l’ère des LLMs

Tue, 17 Jun 2025 18:00:00 +0200

Introduction : quand l’IA rencontre le blogging technique

Ce n’est un secret pour personne, je ne suis pas hyper fan des blogueurs techs qui utilisent des LLMs pour rédiger des articles techniques à la pelle, sans saveur, parfois faux (parce que mal relus par l’humain derrière la machine). C’est la raison pour laquelle j’ai rédigé un AI manifesto et qu’on pourrait résumer avec la phrase suivante :

Je pars du principe que si je ne prends pas la peine d’écrire moi-même le contenu de ce blog, vous ne devriez pas prendre la peine de le lire.

Cependant, j’ai exceptionnellement brisé cette règle aujourd’hui pour la rédaction d’un article “technique”, comme support d’une réflexion plus large que j’ai depuis quelques semaines maintenant. Question que j’ai d’ailleurs “posée tout haut” sur Bluesky et qui a eu des retours intéressants et même parfois inattendus.

Vraie question : à quoi sert un blog technique (rédigé par un être humain, je veux dire) si même les technophiles considèrent que c’est plus simple de bypass la doc officielle et les gens qui partagent leur XP, avec de l’IA ?

bsky.app/profile/zwindler.fr/post/3lpohy3efg22l

Plus globalement, la question était “est-ce que je ne me fais pas un peu de mal à rédiger des trucs techniques si les gens préfèrent le style fade des LLMs ?”

Vos réponses à cette question (qui n’en attendait pas forcément)

Je ne vais pas citer tout le monde, mais grosso modo, ce qui en ressort c’est :

le blog tech, c’est avant tout pour son propre plaisir (d’écrire, d’apprendre)
c’est une façon très efficace pour apprendre un nouveau sujet
ça peut aider au moins une personne
dans des cas très pointus ou niche, les LLMs ne rivalisent pas encore
les LLMs ne peuvent pas “générer” un REX (enfin, pas un vrai :p)
les LLMs ne vont pas faire des captures d’écrans pour les logiciels complexes qui ont des UIs

Les 4 premières réponses, je les attendais. C’est ce qui me motive à écrire ce blog depuis maintenant plus de 15 ans et c’est d’ailleurs assez proche de ce que je dis dans mon tout premier billet de blog de 2010.

Les trois dernières, je ne les avais pas forcément vues venir et c’est vraiment sur ça que je vais peut-être maintenant plus me reconcentrer : des REX et des sujets très pointus (qui étaient là aussi dans l’ADN du blog, surtout au début).

Mais il y a un point que personne n’a évoqué, c’est ce fameux style fade que je n’aime pas dans les LLMs. C’est générique, mécanique, lisse, (statistiquement) moyen.

Est-ce qu’avec un bon LLM aujourd’hui, on arrive à contourner cette limitation ?

Il se trouve que depuis peu, j’ai une licence Copilot pour le travail, avec accès à Claude Sonnet 4. J’ai donc décidé de tester le mode “Agent” sur mon blog (la machine a accès à tous les fichiers de mon workspace et peut écrire dans le workspace).

Note : c’est là où on voit que c’est pratique d’avoir tout en markdown dans un dépôt git !

J’ai donc décidé de prendre un sujet d’actualité (pour mon travail), que je connais plutôt bien, plutôt théorique mais surtout très bien documenté. Un exemple parfait d’article qu’on pourrait voir sur un blog généraliste généré par IA.

Version basique (en 2 prompts)

Prompt 1 : Demande initiale

Dans cette version basique, j’ai volontairement laissé beaucoup de liberté au LLM. Je lui ai juste donné le contexte du blog, lui ai demandé de “manger” quelques-uns de mes articles.

Il en a “consommé” 6 entre 2025 et 2023 sur différents thèmes, et un de 2015. Personnellement, j’ai pensé que ça serait beaucoup trop peu car les 6 articles étaient vraiment hétérocites (il y avait un billet d’humeur politique et une recette de cuisine dans le lot).

Contexte : Je suis auteur d'un blog technique, spécialisé dans l'observabilité et la virtualisation depuis 2010. Depuis 8 ans, je parle beaucoup de Kubernetes. De temps en temps j'écris des billets d'humeurs ou sur des sujets non tech. Le blog est rédigé en markdown avec hugo, dans le dossier content/post. La grande majorité des posts sont en Français.
Analyse le style d'écriture en lisant quelques posts.

Réponse 1 : Analyse du style

Ton et personnalité :

Ton décontracté et accessible
Humour et auto-dérision réguliers
Émotions transparentes

Structure et organisation :

Titres descriptifs et directs
Introduction contextuelle
Progression logique

Vocabulaire et expressions récurrentes :

“Fun fact” pour les anecdotes
“Stay tuned” pour les annonces
Parenthèses humoristiques
Émojis utilisés avec parcimonie

Évolution du style (2015 vs 2025) :

2015 : Plus formel, phrases longues
2025 : Beaucoup plus décontracté et personnel

Ce qui est noté ici est un résumé. En réalité, l’analyse était bien plus longue et j’ai été un peu bluffé par la précision de la réponse.

Il y a un peu de flagornerie par défaut dans les réponses des LLMs, il faut savoir lire entre les lignes, mais globalement c’était fidèle et intéressant d’avoir une analyse de la progression de mon style d’écriture.

La version 1 est disponible ici :

le commit qui va bien

Prompt 2 : Création de l’article

Pour écrire l’article, j’ai essayé d’écrire un prompt relativement rapide. J’ai un peu triché par contre, je lui ai dit de se baser sur mon talk “SRE ! SRE partout !” dans lequel j’introduis les principes que j’avais envie de voir dans l’article écrit.

Est-ce que tu penses pouvoir écrire un article daté du jour sur les concepts SLO / SLI / error budget / critical user journey en copiant mon style ?
Indique qu'il ne faut pas confondre SLA et SLO
Tu peux aussi t'inspirer en partie d'un talk que j'ai écrit sur le sujet et qu'on peut trouver ici :
static/talks/2022-sre-sre-partout/index.md (À partir de la ligne 303)

Réponse 2 : Premier article généré

L’IA a produit un article complet qui reprenait effectivement mon style avec :

Ton décontracté
Structure progressive
Exemples concrets
Vulgarisation accessible

Le résultat est assez bluffant.

Avec un peu d’habitude, on peut deviner que ce n’est pas moi qui ai écrit l’article. Ma femme (qui lit la plupart de mes articles, a minima en diagonale) n’a pas su le dire à première vue.

Il y a quelques tournures que je n’aurais pas utilisées, mais surtout ça reste hyper généraliste (voire générique), lisse. En revanche, le ton est suffisamment décontracté pour que les détecteurs type ZeroGPT soient bernés :

12.62% : Votre Texte est probablement écrit par un humain, peut inclure des parties générées par une IA/GPT

Les parties surlignées en jaune sont les seules détectées comme “générées”.

Produire l’article dans cette version m’a pris à peu près 2 minutes chrono. Mais ça ne correspond toujours pas à mon standard de “blogging”.

Donc j’ai décidé de pousser l’expérience jusqu’au bout, quitte à passer plus de temps à prompter et lui donner des instructions que ça ne m’aurait pris à l’écrire moi-même.

Avec plus de prompts (version itérative)

Prompt X : Demande de modifications

Il y a tellement de modifications demandées ici, certaines tellement directives (exemples que je lui demande d’inclure), que j’ai quasiment envie de dire que c’est moi qui ai écrit une bonne moitié de l’article, pas le LLM… Mais c’était pour la science :p

L’article final est disponible ici :

SLO, SLI, Error Budget et Critical User Journey expliqués simplement et pourquoi ce ne sont pas des SLA !

Garde ce fichier tel quel, c'est une bonne première version
Écris un nouveau fichier avec le premier comme base, mais en prenant en compte les modifications suivantes (Tu as le droit de donner ton avis sur ces modifications tant que c'est constructif) :
De manière générale, je trouve qu'il y a beaucoup de listes (bullet points) ce qui ne correspond pas forcément à mon style (j'en mets mais pas aussi souvent)
En intro, j'aime bien fixer le contexte :
- Explique que c'est suite à des discussions avec des collègues développeurs pour qui les concepts n'étaient pas clairs que j'ai voulu redéfinir les termes, tels qu'ils ont été conçus par Google.
- Explique dès l'introduction que le SRE et tous les concepts associés dont les SLO, ont été inventés par Google.
Au niveau de "Et au-delà d'un certain seuil, les utilisateurs ne voient même plus la différence !", cite l'exemple d'un site web qui ne charge pas sur un smartphone. Au-delà d'un certain niveau de disponibilité, l'utilisateur ne saura pas dire si c'est son smartphone qui a un problème, son navigateur, le réseau 5G ou bien le site web qui rencontre un incident. Si recharger la page une fois de temps en temps suffit et que les utilisateurs ne sont pas plus impactés que ça, inutile d'investir dans plus de fiabilité
Explique également que pour les CUJ, la notion d'utilisateur du service n'est pas nécessairement "l'utilisateur final". L'utilisateur pour la fiabilité d'un service backend, ce n'est pas forcément l'utilisateur final, ça peut être le front qui initie le call. L'utilisateur de la CI, ce ne sont pas directement les utilisateurs finaux non plus, c'est les devs qui veulent livrer une nouvelle version de l'appli.
Explique qu'un microservice ne doit pas avoir trop de SLI, 3-4 les plus pertinentes et qui ont un sens métiers (cf les CUJ). Seuls les membres de l'équipe qui fournissent le service / le développent peuvent savoir (dans le sens : on ne peut pas en imposer des génériques pour toute une entreprise)
Dans les conseils pour définir des SLO cite aussi les méthodes USE et RED pour aider à concevoir des SLI fiables (définis-les très brièvement)
Enlève la phrase "tags pour moi même" en conclusion qui ne correspond pas à mon style "habituel"
Pour calculer les SLA / SLO tu peux citer le site https://uptime.is/
Pour le lien "mon talk sur le SRE en 2022", il faut mettre ce lien-là : /talks/2022-sre-sre-partout/index.html plutôt que /conferences/
Ajoute l'image /talks/2022-sre-sre-partout/binaries/simpsons.png dans la partie sur les error budgets qu'il faut consommer (c'est une blague qui montre une personne qui dit qu'elle casse régulièrement la prod pour finir sur le ton de l'humour)
Mets cette image en "image:" /talks/2022-sre-sre-partout/binaries/sre_sre_partout.jpg dans les métadonnées markdown des deux posts
Change le titre de la première version en y ajoutant "(en 2 prompts)", et le titre du second en y ajoutant "(en plusieurs prompts)"

Après avoir écrit tout ça, le résultat n’est pas mal, proche de ce que j’aurais pu écrire “moi-même” ou presque.

Si on compare le diff entre la version 1 et la version 2, on voit que quasiment TOUT a été réécrit.

Réflexions sur le processus

Ce qui marche VRAIMENT bien, c’est l’analyse de style : le LLM est capable d’identifier et de reproduire mes patterns stylistiques avec une précision surprenante par rapport au peu d’articles qu’il a analysé, au point de berner ma chérie sur une première lecture rapide.

Cependant, on reste sur quelque chose de super générique techniquement (qui a dit “chiant” ?). Sans guidage explicite, les exemples ne sont pas dingues, ça manque de contextualisation, etc. Il y a une grosse phase d’aller-retours avant que le résultat soit “correct” (aka “pas pénible à lire”) à mes yeux.

Je pense aussi qu’on aurait encore pu améliorer le résultat en demandant au LLM de lire plus d’articles de mon blog (ou en lui pointant ceux qui sont pertinents).

Enfin, Claude Sonnet 4 ne permet pas de générer des images donc si je voulais pousser l’expérience en ajoutant des schémas, il aurait fallu que je me contente d’outils textuels type mermaid, ou que je les ajoute à la main.

Conclusion ?

Que dire de tout ça ?

Déjà, Zero GPT ne sert à rien. Il a été totalement incapable de détecter que le texte avait été généré (à part quelques bribes).

Ensuite, je n’ai pas vraiment prévu de changer ma manière de blogger, même si j’y réfléchirai peut être à deux fois si j’ai un sujet très généraliste en tête. Je ferai peut être un peu plus de sujets “niches” et de REX.

Enfin, que “oui” on peut produire des articles plutôt pas mal (je trouve) avec un LLM, mais il faut (pour l’instant encore) :

connaître le sujet
passer pratiquement autant de temps (voire plus) à itérer sur le résultat pour avoir quelque chose de similaire à ce qu’un humain (moi) aurait pu écrire