GenAI on Zwindler's Reflection

Trouver des vulnérabilités dans l'open source quand on n'est pas spécialiste en sécurité

Wed, 23 Sep 2026 20:00:00 +0200

TL;DR

Trouver des failles dans l’open source en 2026, “grâce” aux LLM : facile, OUI
Être le premier à les remonter : possible, MAIS

Trouver des failles est devenu banal. Le vrai défi, c’est d’être le premier, et de survivre au triage. C’est de ça que parle le reste de l’article.

Pourquoi faire ça, au départ ?

La cybersécurité, ça me passionne depuis… bah, depuis toujours. Mon deuxième programme d’enfant était un VB 3.0 à la con, un faux virus qui avait pour seul boulot de remplir le dossier Démarrage de Windows 95/98 de milliers de commandes netsend auto-exécutables (si vous ne savez pas ce que c’était, allez jeter un œil !).

Mais je n’en ai jamais fait mon métier, même si l’idée m’est venue à plusieurs reprises. Ces derniers mois, j’ai collaboré plus étroitement que d’habitude avec mes collègues de l’équipe cybersécurité, et j’ai fini par me lancer : je voulais voir ce que je pouvais faire avec les LLM dans ce domaine.

Disclaimer : je ne suis PAS spécialiste en cybersécurité, pas le moins du monde. Si vous ne me connaissez pas, je ne suis qu’un platform engineer qui s’y connaît en Kubernetes, virtualisation et observabilité. Je code de manière correte en golang et en python.

Quel est le but, au juste ?

Ces deux derniers mois, je me suis mis à traquer (sur mon temps libre) des vulnérabilités dans des logiciels open source populaires que j’utilise au quotidien dans mon travail. Certains ont un programme de bug bounty, d’autres acceptent les GitHub Security Advisories. D’autres ne répondent tout simplement pas.

Pourquoi l’open source ? Bah déjà, le fait que le code soit ouvert me permet de vérifier les choses quand le LLM pense que quelque chose cloche, et de me forger ma propre opinion. L’inconvénient, honnêtement, c’est que les LLM sont aussi la raison pour laquelle l’open source se noie sous les rapports de sécurité depuis environ un an.

Mais surtout : je travaille avec ces outils tous les jours, je sais donc COMMENT ils devraient fonctionner, et ce qui N’EST PAS normal. On reviendra là-dessus aussi.

Une chose avant de commencer : tout ce qui est décrit ci-dessous a été fait sur ma propre infrastructure : clusters jetables, installations locales, VM de test. Chaque programme de bug bounty a ses règles du jeu : pas de scan d’instances tierces, pas de toucher aux données des autres, pas de déni de service sur une infra partagée. Lisez-les. Si une de vos découvertes nécessite de les enfreindre pour être prouvé, c’est que vous vous y prenez mal.

Ok ok, assez d’introduction : les LLM peuvent-ils trouver des failles sans expérience en cybersécurité ?

Réponse courte : oui. La vraie question, c’est de savoir si ça vaut le coup, et ça dépend surtout de si vous voulez être le premier ou non, et de QUAND vous commencez.

Voici mon propre retour d’expérience sur la chasse aux vulnérabilités dans l’open source. “YMMV”, comme on dit.

Vous avez déjà raté le coche

La première chose à savoir, c’est que (si vous commencez aujourd’hui) vous êtes très en retard.

C’est encore plus vrai pour les logiciels couverts par un bug bounty, parce que les chasseurs fouillaient déjà avant l’arrivée des LLM. Mais la pression sur ces projets a été multipliée par mille depuis.

Des chiffres concrets, tirés des pages publiques de deux très gros projets (stats sur 90 jours, septembre 2026), volontairement non cités (c’est bien l’écart qui compte) :

Un programme, encore à peu près en vie : 4 193 rapports reçus, ~454 000 $ versés
L’autre, essentiellement mort : 551 rapports reçus, 1 000 $ versés, dernier rapport traité il y a un mois

Relisez bien. Ce volume, c’est en grande partie du bruit généré par de l’IA. curl a complètement arrêté son bug bounty payant en début 2026, après l’effondrement du ratio de rapports valides. D’autres projets ont suspendu les paiements ou sont passés en accès sur invitation (Nextcloud, Grafana). Les mainteneurs se noient.

Alors si vous pensez être plus malin que tout le monde et que vous comptez vous faire de l’argent rapide avec votre compte Claude, réfléchissez-y à deux fois. Des centaines de personnes y avaient déjà pensé il y a un an, et il y en a un peu plus chaque jour. Vous êtes en concurrence avec elles, avec des professionnels aguerris, et avec des gens qui ont bien plus de ressources IA que vous.

Parlons modèles (choisissez vos armes)

J’ai d’abord essayé les options évidentes (“ça se passe mal!”) :

Claude : tout ce qui touche de près ou de loin à la cybersécurité est flaggé et bascule en mode fortement restreint. Au bout de quelques heures, la session est carrément gelée. La seule parade, c’est de relancer des sessions et de perdre son contexte à chaque fois - et les blocages se font plus fréquents avec le temps, même pour du travail parfaitement légitime. La voie officielle, c’est le Cyber Verification Program d’Anthropic (OpenAI a un équivalent, le Cybersecurity Grant Program), mais la validation semble arbitraire : plusieurs chercheurs en sécurité que je connais personnellement se sont fait refuser sans explication, et ils ne sont pas seuls.
Google Antigravity : ça a très bien marché pendant 2 jours, puis les blocages ont commencé. Google n’a aucun programme pour certifier les chasseurs légitimes, vous pouvez donc l’oublier. Un mois d’abonnement pour rien.

Ce qui marche : laissez tomber les grands fournisseurs américains et passez à des alternatives moins regardantes. Soit un accès par abonnement à des modèles open weights / chinois, soit des plateformes agentic avec des quotas généreux.

Et les API au token ? Très mauvaise idée pour ce genre de travail. La chasse aux failles demande un nombre absurde de tokens en lecture. Mes chiffres à moi : environ 11 milliards de tokens en 2 mois, dont la grande majorité (plus de 90%) servie depuis le cache côté fournisseur. Même avec l’une des options les moins chères au moment où j’écris (GLM 5.3 sur un broker bien connu), ça revient à environ 1 800 $. Un modèle frontier coûterait plusieurs fois ce montant. Choisir un fournisseur dont le cache est facturé moins cher aide énormément, mais vous ne voulez quand même pas de cette facture en fin de mois.

Les abonnements qui donnent accès à GLM, DeepSeek, Kimi… sont probablement de bonnes options (pas encore essayé). Ce que j’ai réellement utilisé pendant 2 mois, c’est devin.ai (l’outil agentic de Cognition, anciennement Windsurf) : leur modèle maison est compétent et, au moment où j’écris, illimité dans l’abonnement de base. Ce genre de promo va et vient, vérifiez avant de vous abonner.

Pas sponsorisé, je paie de ma poche 🥲.

Et les modèles locaux ?

L’idée est vraiment séduisante. Être autonome avec du matériel local (ou en louer) plutôt que de payer au token des tâches coûteuses, tout en échappant à la censure des fournisseurs, ça ressemble à une idée de génie (qui pense GIFI dans sa tête ?). C’est la première chose que j’ai essayée après mon “fiasco” Claude/Antigravity.

Alors… peut-on utiliser des modèles open weights locaux pour éviter de griller son quota en 20 minutes ? Avec un modèle ~30B (type Qwen, ou la meilleure variante du moment), on peut trouver quelques failles sur des gros projets anciens… mais c’est comme courir un marathon avec un sac à dos rempli de cailloux après les avoir peint (dédicace à Vincent). C’est faisable, mais ne vous attendez pas à ce que ce soit simple ni efficace.

Si vous partez sur cette voie, le pipeline ci-dessous compte encore plus qu’avec des modèles plus “gros”.

Mon pipeline

Quel que soit le modèle, la première chose dont vous avez besoin, c’est un cadre solide. Voilà ce que j’ai fait (plutôt basique, il existe peut-être des méthodes plus efficaces, mais c’est un bon point de départ) :

Analysez un composant de votre cible à la fois. Demandez au modèle de cartographier son fonctionnement en amont. Terminez-le complètement avant de passer au suivant.
Une fois la cartographie faite, répartissez le travail (surtout des fichiers de code) entre des subagents, chacun focalisé sur une partie bien délimitée. Demandez-leur de chercher des anti-patterns connus dans les fonctions, des variables mal vérifiées et compagnie, et de consigner dans un fichier markdown tout ce qui leur paraît même vaguement bizarre ou dangereux, pour analyse ultérieure.
Faites relire le travail des subagents par l’agent principal. Chaque constat part soit dans un dossier “non-security findings” (bugs trop faibles ou trop restreints pour être exploités : je m’en sers pour faire des PR d’amélioration en upstream), soit dans un dossier “security findings” pour contre-expertise.
Une fois le scan initial terminé, demandez à l’agent principal une contre-expertise de tous les nouveaux constats sécurité validés.

Contre-expertise

C’est là que vient l’essentiel de la valeur de mes scans LLM. J’ai mis deux mois à affiner cette étape, et j’y travaille toujours.

Ma checklist actuelle :

Chercher sur GitHub/GitLab les issues, PR et documents d’amélioration éventuels. Soumettre un problème de sécurité déjà connu, c’est évidemment une mauvaise idée.
Regarder aussi dans la doc officielle les limitations connues, les faiblesses & compromis documentés (c’est à dire “acceptés” par les mainteneurs, donc inéligibles), les bonnes pratiques de sécurité.
Quand vous êtes sûr à 100% qu’il n’y a ni correctif public ni rapport antérieur, demandez au modèle de reproduire sur le vrai logiciel. Selon la cible, vous voudrez peut-être des runbooks pour différentes configurations sur différentes plateformes. Cette étape est particulièrement importante avec les modèles locaux, qui sortent des rapports de vulnérabilité absolument convaincants mais qui ne marchent jamais.
Une fois reproduite, notez-la. La plupart des bug bounties demandent un score CVSS, mais il faut aller plus loin que ça.

Concrètement, un constat dans mon pipeline, ça ressemble à ça : un subagent signale un pattern suspect dans un fichier que personne ne lit -> l’orchestrateur le déduplique face aux issues publiques et aux flux de CVE -> si ça passe, reproduction sur un cluster kind jetable ou une installation locale du vrai logiciel -> puis noté, rédigé, soumis… et ensuite, vous attendez. Le triage prend en général quelques semaines/mois. Parfois quelques jours, et dans de rares cas plusieurs années (on y reviendra, c’est généralement le signe d’un programme surchargé ou mort).

Noter à la juste valeur

Une fois que vous avez de vraies vulnérabilités, les noter avec un CVSS est une étape nécessaire. Mais le travail ne s’arrête pas là. Tout le monde qui a fait un peu de cybersécurité sait bien que le CVSS ne raconte pas toute l’histoire. Et les LLM auront tendance à surévaluer leurs propres constats.

Faites poser ces questions à l’agent pendant la contre-expertise :

Le constat est-il réaliste ?
Les prérequis sont-ils réalistes ?
Existeraient-ils / arriveraient-ils dans un déploiement réel, pas seulement en théorie ?
La configuration est-elle saine (et non un piège où l’admin de notre scénario mériterait presque d’être compromis) ?
Un attaquant chercherait-il vraiment à exploiter ça ?
Le constat donne-t-il plus de droits que l’attaquant n’en a déjà ?

Toutes ces réponses (ou au moins la plupart) devraient être “oui”. Sinon, ce n’est probablement pas un problème de sécurité (ou en tout cas, c’est ce que les équipes sécurité de ces projets vous diront !), quoi qu’en dise le CVSS.

Il y a évidemment des exceptions, mais pour rester simple restons dans le cas général.

Appropriez-vous le rapport

Une fois tout ça fait, prenez le temps de le relire (vous, l’humain). Selon la qualité du modèle, vous trouverez peut être le rapport ridicule :

Lisez le rapport du LLM attentivement, comprenez-le, appropriez-vous-en !
Si quelque chose vous paraît bizarre, challengez le LLM
Si une affirmation est exagérée, challengez le LLM

C’est là qu’un bagage en cybersécurité ou une connaissance fine de l’outil que vous auditez devient vraiment utile. Ça vous évitera de vous ridiculiser (l’humain, le LLM, lui, s’en fout).

Ne faites pas partie du problème

Prenons le taureau par les cornes : je viens de vous dire que les mainteneurs se noient sous les rapports générés par l’IA, et j’en ai envoyé plus de 30 moi-même. Oui, il y a un léger problème de cohérence. Voici ce que j’essaie de faire autrement :

Rien n’est soumis sans avoir été reproduit sur le vrai logiciel et/ou un vrai cluster
Chaque rapport est lu, compris et assumé par moi avant de partir. Si je ne peux pas l’expliquer aux mainteneurs sans le LLM, il ne part pas
Les constats à faible sévérité ou limite ne passent pas par les canaux sécurité : ils finissent en issues publiques ou en PR en upstream
Les notes sont contestées : pas de CVSS gonflé par le LLM
Sur les petits projets, les rapports partent un par un, en attendant le triage avant d’en envoyer d’autres

Les doublons arrivent quand même (9 pour l’instant), mais un doublon de vraie vulnérabilité reproduite coûte quelques minutes au triage sur des plateformes de bug bounty. Un rapport halluciné lui coûte potentiellement des heures, et beaucoup de la patience du maintainer.

Gardez une trace de tout

Ça, je l’avais pas vu venir.

Très très (très) vite, on est soi même ensevelli sous les reports. Après une trentaine de constats et une dizaine de rapports envoyés, je ne savais plus où j’en étais, honnêtement. Quel constat avait été reproduit ? Lequel avait déjà été soumis, et dans quel programme ? Quel rapport m’attendait, et lequel attendait les mainteneurs ? Un dossier de fichiers markdown ne passe pas à l’échelle, et les immenses tables markdown entretenues par le LLM sont vite devenues ingérables aussi.

Du coup, j’ai fini par faire “Clauder” mon tableau de bord de suivi (oui, l’ironie : Claude code avec plaisir une UI pour chasser des failles, il veut juste pas faire la chasse lui-même). La source de vérité est désormais une base JSON, que le LLM met à jour via des scripts (jamais en éditant le fichier à la main). À chaque commit, un tableau kanban HTML statique est régénéré à partir de celle-ci, en suivant chaque constat tout au long de son cycle de vie.

(Les titres ont été censurés pour des raisons évidentes)

Chaque constat est une carte qui progresse de gauche à droite :

Candidate : signalée par un subagent, pas encore vérifiée
Confirmée : a survécu à la contre-expertise et à la reproduction
Rédaction puis Prête : rapport en cours de rédaction, puis prêt à envoyer
Envoyé et Triage : soumis, en attente que le programme le regarde
Acceptée (embargo) : acceptée par le programme, correctif ou divulgation en attente
Corrigée : correctif publié
Fermée : rejetée comme doublon, wontfix ou informative

Chaque carte porte un score composite (CVSS + risque de wontfix + risque de doublon, on y revient dans la section suivante), le CVSS, combien de fois elle a été soumise, et si elle a déjà été remontée en upstream. Trier par score composite me dit quoi écrire ensuite. Filtrer par programme me dit combien de places il me reste avant d’atteindre la limite de soumission.

La vue stats, c’est aussi un bon retour à la réalité :

163 constats (après en avoir écarté 215 non-sécurité), sur 26 projets, et seulement 31 soumis.

La seule colonne “Prête” contient déjà 118 constats. En trouver, c’est trivial. Ce qui me limite, ce n’est plus le LLM : c’est mon temps à moi pour reproduire, rédiger et assumer chaque rapport (l’humain dans la boucle est le goulot d’étranglement), puis les plafonds de soumission des programmes. Et même dans ces conditions, être le premier et survivre au triage reste du ressort de la chance.

Quel que soit l’outil que vous utilisez (un tableur fait l’affaire aussi, voire JIRA lol), mettez ça en place avant de commencer à soumettre. Le rajouter après 10 rapports envoyés, en remuant les mails et les boîtes de réception des plateformes, c’est un exercice douloureux.

Vous n’êtes pas seul

Même quand le programme ne verse pas de bounty, attendez-vous à de la concurrence : via les plateformes de bug bounty ou des rapports GHSA (GitHub Security Advisory). Vous pouvez partir du principe que chaque problème “facile à repérer” a été trouvé il y a des mois, plusieurs fois. Sur les projets dont l’équipe sécurité est à bout, comptez plutôt des années.

Je ne peux pas encore donner de détails, mais je suis tombé sur une vulnérabilité qui avait été remontée il y a des années, avec un CVE réservé l’année d’avant, toujours ni corrigée ni publique.

Voilà l’état du triage de sécurité de l’open source aujourd’hui : la file d’attente est plus longue que ce qu’on arrive à traiter, et ça ne s’améliore pas.

Alors si vous visez à être le premier (pour le bounty, pour la gloire), il faut être plus stratégique que la moyenne :

Évitez les bugs qui se repèrent en lisant un seul fichier, ou qu’un outil SAST/DAST signalerait. Les LLM sont relativement doués pour ça, et vous pouvez être sûr que quelqu’un l’a trouvé avant vous. Malheureusement, c’est peut-être le seul type de constat que vous obtiendrez avec des modèles locaux/petits (ou il vous faut un harness très spécifique).
Ciblez en priorité du code qui n’est pas le plus audité. Ne visez pas une RCE pré-auth si vous ne savez pas ce que vous faites. Ce code a été audité par des gens bien meilleurs que vous. Visez plutôt du code récent en beta/GA, ou à l’inverse du vieux legacy qui paraît inoffensif.
Visez des problèmes qui supposent de savoir comment l’outil fonctionne, et ce qui ne devrait pas fonctionner. Les LLM sont mauvais là-dessus : si vous avez cette connaissance, vous avez un avantage.
Si vous ne payez pas au token, n’hésitez pas à donner le fichier entier au subagent. J’ai découvert par hasard qu’un agent qu’on restreint aux “fonctions sensibles” en rate ÉNORMÉMENT. C’est peut-être moins vrai pour les modèles frontier, mais c’est une vérité absolue pour les modèles moins bons.

De là, j’ai mis au point un score qui évalue mes vulnérabilités non seulement sur leur CVSS, mais aussi sur le risque de “wontfix” de la part des mainteneurs et le risque de “doublon” parce qu’elles étaient trop faciles à trouver.

Conclusion

Est-ce que ça marche ? Oui, absolument. J’ai trouvé des dizaines de vulnérabilités réelles, non corrigées, dans de l’open source en production, allant de sévérité moyenne à critique.

La vérité qui pique : j’ai envoyé plus de 30 rapports jusqu’ici. Sur les verdicts revenus, la plupart étaient des doublons - quelqu’un était arrivé avant moi (mon erreur de débutant : je pensais que les constats faciles passeraient, alors que “facile” signifie simplement que quelqu’un les a déjà trouvés). L’un m’a valu un CVE avec co-crédit, CVE-2026-77524, qui vient de sortir en public : une élévation critique namespace-admin vers cluster-admin dans KEDA ; un autre advisory a été accepté mais n’est pas encore public ; et un correctif a été mergé via une issue publique. Le reste est soit encore en triage, soit bloqué derrière des limites de débit. Certaines plateformes plafonnent les soumissions, par exemple 4 rapports par programme sur une fenêtre glissante de 30 jours, un peu plus si vous chassez sur plusieurs programmes, avec en plus un plafond global sur toute la plateforme.

Et quand un projet ne répond simplement pas ? Je n’ai pas encore de règle parfaite : je relance une fois après quelques semaines. La convention courante, c’est une publication publique après un embargo raisonnable (90 jours), mais je n’ai pas encore décidé si je l’appliquerai. Il y a aussi des paliers intermédiaires, comme escalader auprès d’une CNA, ou de GitHub Security Lab pour les projets hébergés sur GitHub. Un rapport qui pourrit dans une file privée n’aide personne, mais laisser une vulnérabilité non corrigée entre les mains des utilisateurs non plus.

Alors : exploitez cette contrainte. Transformez la faiblesse en atout. Tout le monde se concentre sur les mêmes cibles médiatiques (qui ne veut pas d’une RCE pré-auth ?) ou sur les failles évidentes et faciles. Si vous voulez des résultats (être le premier), laissez tomber les deux. Concentrez-vous sur les cas limites obscurs qui se retrouvent éparpillés sur 3 composants. Oui, ça demande plus de travail, de meilleurs LLM, et un peu de chance.

Si vous commencez maintenant, les victoires faciles sont déjà prises. Mais c’est précisément là que se trouve votre atout : savoir comment devraient se comporter les outils que vous utilisez tous les jours, c’est quelque chose que personne ne peut louer “au token”.

Refonte de l'UI de GroROTI

Fri, 22 May 2026 12:00:00 +0200

Si vous lisez régulièrement ce blog et mes aventures sur les réseaux sociaux, vous savez que j’aime énormément l’infrastructure, un peu le code backend (surtout en Golang), mais que dès qu’il s’agit de concevoir une interface graphique moderne et agréable, il n’y a plus personne.

C’est un fait établi, je n’ai aucune compétence en développement front. Dommage pour les offres FullSteak (jeu de mot pourri, mais plutôt approprié ici).

C’est exactement ce qui pénalisait GroROTI, un petit outil web open source en Go que j’avais développé en 2024 (en partie sur mon temps libre, en partie lorsque j’étais chez mon ancien employeur, ce qui explique pourquoi le dépôt soit hébergé sur leur GitHub).

Pour rappel, l’application permet d’évaluer rapidement et anonymement la qualité des réunions ou des ateliers via le format ROTI (Return On Time Invested).

Le problème, c’est que l’outil était fonctionnel, mais franchement moche. Un petit look Web 1.0, voire soviétique, qui était franchement assumé dans un premier temps, mais dont on se lasse assez vite.

Qu’à cela ne tienne. Fort de mes expériences plutôt concluantes avec la refonte de ma page Conférence (cf “Refonte de la page Conférences : data-driven avec Hugo”) et la v3 de mon projet pour cataloguer toutes les manières de déployer Kubernetes (cf “101 façons de déployer Kubernetes : 125 solutions, des PRs communautaires et une UI qui s’améliore”), j’ai fait chauffer un LLM perso pour lui demander de m’aider à rendre ça un peu plus agréable à l’oeil.

Le résultat va bien au-delà de mes compétences (“la barre est au sol” comme on dit). Si on compare les captures d’écran avant (à gauche) et après (à droite), le changement est flagrant :

Une page d’accueil transformée : Fini l’alignement de texte un peu triste. On passe sur une interface épurée, une colorimétrie violette moderne (petit clin d’oeil), un bloc de création “New ROTI” bien délimité et une barre latérale pour afficher les derniers examens créés.

Des résultats clairs : La page de restitution des votes affiche désormais la moyenne globale en grand, ainsi que le nombre de participants et les valeurs minimales et maximales sous forme de “cartes”. Le QR code de partage est lui aussi bien mieux intégré visuellement.

Un système de notation plus intuitif : Le vieux curseur glissant a été remplacé par un système de notation à 5 étoiles (avec support des demi notes) bien plus classique et parlant pour les utilisateurs. Le tout reste accompagné d’une zone de texte (redesignée) pour les retours optionnels, quand ils sont activés.

Juste un lifting

Sous le capot, l’application reste la même, je n’ai pas touché au code backend (*), juste la partie templates HTML (gotpl) et CSS.

(*) c’est pas 100% vrai, j’ai fait quelques modifs en 2025, notamment pour ajouter du tracing otel, support de la CR ServiceMonitor, amélioration du build multi arch et quelques bugfixes… dont je ne vous avais pas parlé.

Au final, ce petit truc en plus fait la diff entre un tool interne que je n’avais pas trop envie de mettre en avant, et un outil qui me parait utilisable en dehors de mon contexte pro :

https://github.com/deezer/GroROTI

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 !