IA on Zwindler's Reflection

Touraine Tech 2026 - Récap du jour 1

Thu, 12 Feb 2026 18:00:00 +0200

De retour à Touraine Tech !

Pour la 2ème fois, j’ai participé à la conférence Touraine Tech (la première fois c’était en 2022).

Contrairement à 2022, la conférence a maintenant lieu à l’Université de Sciences de Tours (et non plus à Polytech) et se déroule sur 2 jours. L’occasion de revenir profiter des tourangelles et des tourangeux qui nous reçoivent toujours si bien.

Keynote d’ouverture - La guerre informationnelle

Clément Hammel-Cazenave d’Agoratlas nous a proposé une keynote percutante sur les ingérences numériques et la guerre informationnelle en cours.

Son point de départ : la crise agricole autour de l’abattage des troupeaux bovins à cause de la dermatose nodulaire. En analysant 500k tweets fournis par Visibrain, son équipe a reconstruit le graphe des interactions sur les réseaux sociaux. En utilisant la méthode de Louvain (maximiser les liens intra-communauté et minimiser les liens inter-communautés), puis en labellisant manuellement les communautés, ils ont pu mettre en évidence un phénomène inquiétant : l’exclusion de la parole experte, cantonnée à sa petite bulle, pendant que le débat se polarise entre extrêmes (droites).

Clément a aussi présenté D3lta, un outil open source créé par Viginum, permettant de détecter les contenus dupliqués dans l’objectif de repérer les tentatives d’ingérences numériques.

Point important soulevé : les réseaux sociaux impactent Internet de manière générale, y compris les LLMs qui sont entraînés en partie sur ces contenus. C’est une stratégie délibérée pour transformer les LLMs en “machines à narratif (russe)”.

Mais ils ont aussi des impacts parfois importants sur “la vraie vie”. L’exemple des élections en Roumanie est frappant : un “inconnu” est arrivé au second tour grâce à des ingérences russes sur TikTok. L’élection a été annulée par la Cour constitutionnelle.

Comment riposter ?

Viginum : réseau de coordination et de protection des élections, créé après l’assassinat de Samuel Paty. La France est très en avance sur ce sujet
L’Arcom : manque malheureusement de moyens et de soutien politique
DMA / DSA : les régulations européennes
Nous : quitter X (openportability.org, non mais sérieux, vous attendez quoi ?), faire de l’analyse soi-même (NodeXL, Python, Gephi), éducation, contribuer aux outils comme ATProto ou Gephi

Une keynote qui fait réfléchir sur notre responsabilité collective face à ces enjeux.

Mes trains Jouef passent au numérique, avec des Raspberry et TinyGo !

Un talk bonbon, qui parle d’une belle histoire de side project tech intergénérationnel ! Les speakers nous ont raconté comment ils ont modernisés les trains analogiques du grand-père.

Le problème de base : les trains analogiques fonctionnent en 14V/-14V (pour avant/arrière), mais il est difficile d’en faire circuler plus de 3 simultanément sans collisions. La solution professionnelle, le DCC, permet d’envoyer de la data dans le courant pour gérer plusieurs trains.

La solution DIY en 2024 : TinyGo sur Raspberry Pi Pico W (version Wireless).

L’implémentation a été semée d’embûches techniques :

Pont abaisseur de tension (14V → 5V) + contrôleur PWM pour la vitesse
Problèmes de stabilité du réseau électrique
Stack réseau WiFi absente de TinyGo, donc à recoder !
Watchdog pour reboot automatique en cas de deadlock

Pour réduire encore la taille et rentrer dans certains trains, il a dû changer de carte. Exit le WiFi/TCP-IP, bonjour le Bluetooth ! Résultat : latence passée de 300ms à 1ms. L’inconvénient : cette carte n’a qu’un seul core, donc il a fallu ruser avec des channels pour avoir des boucles non bloquantes. Fini le REST, place aux WebSockets.

Un side project comme on les aime, avec ses galères et ses victoires !

Notre talk : Limits, Requests, QoS, PriorityClasses

C’était notre tour avec Quentin Joly ! Nous avions amélioré le talk par rapport au DevFest Nantes, j’avais rajouté une démo et changé une autre qui devait être un peu stable. Enfin ça c’était sur le papier

Spoiler : les deux nouvelles démos ont échoué… et nous n’avions pas de backup 🙈.

Ce n’est pas grave en soi, les 6 autres démos ont parfaitement fonctionné et le public a été indulgent. Nous avons eu de très bons retours sur OpenFeedback, avec des commentaires très cools mettant en avant que le talk était accessible même aux “non sachants” Kube :

Je rejoins les autres commentaires, côté développement je n’avais qu’une brève connaissance de kubernetes et j’ai pu suivre la conf’ et apprendre plein de choses ! Beau challenge pour les démos c’était au top ! Bravo et merci !

La leçon à retenir : même quand on est sûr de la démo et qu’on la lancée 10 fois sans incident, toujours avoir un plan B !

Pause déjeuner

On souffle, on profite du créneau du midi pour déguster un super potage ainsi qu’un très bon burger au pulled pork. Le traiteur était excellent, et malgré le nombre de personnes à nourrir les plats sortaient très vite. Chapeau !

Metal-As-A-Service : Gérer votre bare-metal comme une machine virtuelle !

Julien Briault continue de nous émerveiller avec la prouesse qu’il a lancé (au début seul, maintenant avec la petite 20aine de bénévoles) en réinternalisant l’informatique des 113 associations, en mutualisant sur une plateforme commune “le cloud du coeur”, entièrement construite sur des dons et des produits open source.

La philosophie : “Tout doit être API”. Ça me rappelle un peu le fameux Bezos API Mandate, mais je ne suis pas sûr que Julien apprécierait la comparaison 😉.

L’infrastructure est répartie sur 3 régions (Paris, Chartres, Marseille), avec pour chaque région 3 datacenters proches pour la haute disponibilité. Le choix du bare-metal permet d’éviter les dépendances centralisées (on se souvient tous de la panne US-EAST-1 qui a fait tomber les 3/4 d’Internet…).

Pourquoi MAAS (Metal-As-A-Service de Canonical) ?

Ironic (OpenStack) : mauvaise UX, nécessite un OpenStack complet
Tinkerbell : a besoin de Kubernetes
MAAS : existe depuis 2012, AGPL, supporte tous les vieux serveurs

Le cycle de vie : boot PXE, récupération des paramètres BMC, remontée dans l’inventaire, configuration BMC pour le power control managé par MAAS. Tout est API : les calls sont envoyés à Netbox et Slack.

Point FinOps intéressant : grâce à Open Baremetal (écrit en Rust) qui utilise RAPL (Running Average Power Limit) via Scaphandre et VictoriaMetrics, ils allument et éteignent les machines en fonction de seuils. Résultat : division par 3 de la consommation électrique et 300 000€ économisés par an (soit 300 000 repas !).

Pause et discussions avec les sponsors

J’ai longuement discuté avec Horacio et Yannick (akanoa) de Clever Cloud. Au menu : développement à l’ère de la GenAI, ordonnancement d’agents IA, et… Kubernetes managé chez Clever Cloud. Je n’en dis pas plus 😏.

Les Agents : l’ordre dans le chaos des IA

Thierry Chantier nous a fait un état des lieux du monde des agents IA.

Rappel sur les LLMs : ce sont des modèles statistiques entraînés sur des montagnes de texte. On est passé du “texte only” à des systèmes “agentic” qui bougent très vite. Un agent, c’est une entité autonome avec la capacité de décomposer des tâches et de s’auto-évaluer.

Conseil important : spécialiser les agents pour optimiser les outils, réduire le domaine et être plus performant. On peut même utiliser des SLM voire des TinyLM pour des cas d’usage spécifiques.

Les différents types de workflows :

Séquentiel : les agents s’enchaînent
Routeur : route vers le bon agent
Hand-offs : comme le routeur, mais les agents peuvent déléguer s’ils s’estiment incapables de répondre
Superviseur : comme le routeur, mais vérifie que l’objectif est atteint

Côté frameworks, Thierry a mentionné :

LangGraph (de LangChain) : un peu trop couplé
ADK (Agent Development Kit)
Strands Agent : beaucoup plus agnostique
Crew.ai

J’ai aimé la mention de l’option Tracing=true dans crew.ai. Si je comprend bien, ce sont des traces OpenTelemetry et pour pouvoir debug un workflow, ça me parait hyper intéressant.

KO technique

J’avais prévu de voir le talk de Stéphane Philippart sur les CLI boostées à l’IA avec Picocli, ou celui de Laurent Grangeau sur la protection de la mémoire.

Mais la fatigue de la soirée “before” passant par là, j’ai décidé de rentrer un peu plus tôt à mon hôtel, en attendant la soirée speaker. Celle-ci a eu lieu dans un bar à jeux privatisé, l’occasion de rencontrer d’autres speakers autour de tapas et d’une bière bien fraîche.

À suivre…

La suite au prochain épisode avec le récap du jour 2 ! Stay tuned 🎉

J'ai donné 1 heure à des agents Copilot pour migrer un site de Bloggrify à Hugo

Tue, 02 Dec 2025 18:00:00 +0200

TL;DR pour les pressés

J’ai fait migrer un site statique de Bloggrify vers Hugo par GitHub Copilot Agent.

Les règles ? Une heure chrono, quelques tâches mais jamais plus de 2 en parallèle pour que l’humain conserve une charge mentale acceptable.

Spoiler : l’IA est meilleure que moi en bash (je le savais déjà, c’est pas très dur), correcte pour le CSS (après 2-3 essais), et dangereusement créative sur les parties rédigées, même celles qui sont déjà bonnes (askip j’ai été speaker à la KubeCon EU 2024… j’y étais même pas !).

Point fort inattendu : Playwright qui fait des screenshots automatiques à chaque modif. Un vrai game changer dans ce genre de cas d’usage IMO.

Le contexte : pourquoi se faire mal ?

Si vous suivez le blog, vous savez que j’ai publié un livre (Kubernetes : 50 solutions pour les postes de développement et les clusters de production), et vous savez aussi qu’il y a un site séparé pour la promotion du livre : 50ndk.zwindler.fr.

A l’époque je voulais en profiter pour tester un truc nouveau, j’avais donc testé Bloggrify (un générateur de sites statiques écrit par Hugo Lassiège). Sauf qu’à l’usage, je suis perdu dans l’écosystème JS, et je me suis dit que j’allais le migrer vers Hugo avec le thème Stack (exactement le même que ce blog).

Dans les deux cas, c’est des générateurs de sites statiques avec le contenu en markdown. Théoriquement, c’est pas compliqué à faire.

Mais au lieu de le faire manuellement, j’ai décidé de me lancer un petit défi : tout déléguer à des agents GitHub Copilot, en me limitant à 1 heure et en maintenant une charge mentale acceptable (comprendre : pas plus de 2 tâches en parallèle, sinon mon cerveau explose).

J’ai donc ouvert Copilot, choisi Claude Sonnet 4.5 (car Gemini 3 Pro, qui venait de sortir, était cassé) et je lui ai donné d’un côté le dépôt de 50ndk, de l’autre le dépôt de blog.zwindler.fr et je lui ai donné un court prompt du type :

Ce site a été créé à partir d’un outil appelé bloggrify. J’aimerai migrer tout le contenu markdown / images de ce blog vers un blog statique de type Hugo, que je maitrise mieux. Bases toi sur @zwindler/blog.zwindler.fr pour la structure et le thème à utiliser

Phase 1 : La migration technique (15 minutes)

Ce qui a marché tout seul

Première bonne impression : la migration de base a pris 15 minutes. Copilot Agent a :

Converti la structure Bloggrify vers Hugo
Installé Hugo
Mis en place le thème Stack
Créé un workflow automatisé complet avec :
- Build du site
- Démarrage d’un serveur local
- Capture d’écran Playwright 📸 (on y reviendra, c’est LE truc génial)
Nettoyer tout ce qui avait un rapport avec Bloggrify / Javascript

Résultat : un site fonctionnel du premier coup. Mais pas parfait !

Les premiers soucis (détectés par l’humain… aka moi)

En regardant le screenshot généré, j’ai repéré deux trucs bofs :

Menu “Archives” affiché en double dans la partie gauche
Des catégories inutiles. En effet, dans le site 50ndk, je n’avais pas utilisé de catégories, seulement des tags. Or le thème Stack met beaucoup en avant les catégories, et c’était moche.

L’agent n’avait rien détecté car en soi, c’est OK, ça fonctionne. Normal : c’est du visuel, et il faut un humain pour dire “euh, là c’est moche”.

Les corrections (7 min + 4 min)

Une fois que je lui ai signalé les problèmes, l’agent a :

su diagnostiquer précisément la cause du menu dupliqué (défini à la fois dans hugo.yaml ET dans le frontmatter de content/page/archives/index.md)
corrigé en ~7 minutes
réglé le problème des catégories en ~4 minutes

L’agent est bon pour débugger… une fois que l’humain a détecté le bug :

Agent génère
Screenshot Playwright
Humain vérifie puis formule un feedback
Agent corrige
et on itère comme ça

Sans Playwright, j’aurais dû manuellement builder, lancer le serveur, rafraîchir le navigateur à chaque itération. L’automatisation de cette boucle, c’est un game changer absolu.

Phase 2 : La page “À propos” (20-25 min, et des “““hallucinations”””)

Ce qui a bien commencé

Deuxième tâche : améliorer la page “À propos”. L’agent a :

Analysé le contexte (mes articles, ma page whoami sur blog.zwindler.fr)
Pondu une première version correcte, bien structurée
Su ajouter des images quand je lui ai demandé
Été capable de faire des ajustements rapides sur demande (“double la longueur”) ou seul, “j’au corrigé la faute de frappe ‘20240’ → ‘2024’”)

Jusque-là, RAS. Puis…

Quand l’IA devient romancier

Après quelques itérations, le LLM a commencé à réécrire certaines parties qui étaient bonnes.

Genre, carrément :

“Participation à la KubeCon EU 2024 en tant qu’organisateur/speaker”
Changé le nom du livre et l’éditeur
…

La supervision humaine pour la vérification factuelle est indispensable, surtout sur du contenu biographique. J’ai dû corriger plusieurs fois en mode “non, cette partie est fausse”.

Phase 3 : Les tâches techniques (et là, ça roule)

Ajout de scripts de tracking

Tâche : intégrer Hakanai + Umami sur toutes les pages.

L’agent a :

Créé un partial template dans layouts/partials/
Inclus automatiquement dans le layout principal
Placé les scripts au bon endroit (avant </body>)

C’est ce que j’aurais fait aussi. Nickel, RAS.

Optimisation d’image (succès… mais… pourquoi ???)

Je lui ai donné la tâche complètement débile de réduire ma photo de profil, qui était extrêmement grosse (j’avais vraiment été bourrin sur la version Bloggrify…)

Tâche : réduire avatar.jpg de 1.3 Mo à ~250 Ko.

L’agent l’a fait. Techniquement, ✅. J’aurais été beaucoup plus rapide à le faire manuellement (quelques secondes avec un outil d’optimisation d’images). Mais j’ai voulu pousser l’expérience jusqu’au bout et tester les limites de l’agent sur des tâches “simples” (pour un humain) comme celle là.

Entre le coût cognitif de formulation de la demande, le temps d’attente et l’énergie consommée pour lancer un pauvre resize de JPEG par rapport à une action manuelle directe, c’est clairement pas le meilleur usage. Mais ça fonctionne.

Mise en page des images (page “À propos”) - CSS/Layout complexe

Tâche : faire “épouser” le texte autour des images (float layout) + définir hauteur à 200px.

L’agent a proposé plusieurs itérations avant d’arriver à une version qui fonctionnait. Les tâches CSS/layout complexes nécessitent souvent plusieurs itérations. L’agent propose des solutions techniquement valides mais qui peuvent entrer en conflit avec les styles existants du thème. La validation visuelle via screenshot est indispensable.

Widget “Commander le livre” dans la barre de droite

Tâche : ajouter un widget dans la sidebar avec liens vers vendeurs (Eyrolles, Cultura, Amazon, Fnac).

Là encore, il a fallu plusieurs tentatives pour avoir un truc qui fonctionne sur Hugo / mon thème. La première itération était KO. Il a fallu qu’il comprenne qu’il fallait faire un widget personnalisé (j’ai eu à en faire aussi, j’aurais pu le guider s’il n’avait pas trouvé seul).

L’agent a créé :

layouts/partials/widget/book-links.html
HTML + CSS inline cohérent avec le thème Stack
Modification de hugo.yaml pour référencer book-links

Résultat final : un widget affiché avec les 4 liens avec en bonus que je n’avais pas demandé un effet hover (jamais j’aurais su faire ça).

Comportement bizarre : PR ou commit direct ?

Sur ce projet, la branche main n’était pas protégée (oui c’est pas bien, nia nia nia). Donc selon les cas, l’agent s’est mis, soit à créer des PRs, soit à commiter directement sur main (avec mon accord).

Je n’ai pas réussi à bien comprendre comment il arrivait à déterminer que dans tel cas il fallait une PR, et dans tel autre, un simple commit suffisait. Je n’ai pas creusé, mais ça m’intrigue un peu (si quelqu’un a l’explication).

Dans tous les cas, cette question est probablement un peu bêbette, le mieux, c’est de protéger main.

Un PaaS, ça aide

Petit point bonus qui a bien aidé pour cette migration, le fait que le site ait été hébergé sur Clever Cloud (sur un PaaS plus généralement, car ça aurait probablement été vrai sur d’autres PaaS).

Dans ce cas précis, Clever a su détecter qu’on était passé de JS à Hugo sans que je n’aie rien à faire. Ça, plus le fait que les builds étaient très rapides (30 secondes entre le commit et la mise à dispo de la nouvelle version), ça m’a permis d’itérer extrêmement vite.

Si j’avais dû m’occuper de l’infra pour migrer le tooling sur une VM, ou en monter une autre, cette expérimentation ne serait pas allée aussi loin.

Conclusion

La découverte majeure de l’expérimentation, c’est sans aucun doute possible le fait que Copilot utilise Playwright pour tester, et quand il est content de son résultat, pouvoir afficher à l’humain une capture d’écran de ce qu’il pense être valide.

Ça s’est révélé extrêmement utile dans le cadre de ce projet. À de multiples reprises, sans Playwright, j’aurais dû manuellement builder, lancer le serveur, rafraîchir le navigateur avant de voir un truc cassé ou moche, à chaque itération. L’automatisation de cette boucle de feedback visuelle est un game changer pour la productivité.

Ça ne sera pas universel, mais j’ai trouvé que 2 tâches simultanées (3 à la rigueur) c’était une bonne limite pour garder suffisamment en tête toutes les tâches en cours et être efficace pour review quand le LLM avait “fini”. J’aurais pu faire plus de choses mais j’ai eu peur d’être moins alerte et de laisser passer plus de bêtises.

Cette expérimentation d’environ 1 heure a démontré que GitHub Copilot Agent est particulièrement efficace pour :

Les migrations techniques (gain de temps massif : ~15 min pour Bloggrify → Hugo, j’aurais mis plus, c’est sûr)
Le debugging assisté (une fois le problème identifié par l’humain)

Cependant, il nécessite toujours une supervision humaine attentive, voire très attentive pour :

Les faits (ça sortait tellement de nulle part, cette réécriture du contenu alors que je lui demandais de rajouter des images ?!?)
Les décisions UX/Design et les validations visuelles (lui, si c’est moche il s’en fout, un peu comme un dev back qui fait du front)
Les tâches CSS/layout complexes (rarement bon du premier coup, mais en même temps j’aurais pas fait mieux)
Les architecture spécifiques de frameworks/thèmes (et en plus il t’engueule en te disant que c’est la faute de ton thème)

J’insiste une dernière fois, mais l’intégration de Playwright pour les screenshots automatiques crée une boucle de feedback visuel qui transforme radicalement l’expérience de développement avec les agents. Je ne me renseigne peut-être pas assez et peut-être que ça existe depuis longtemps, mais c’est vraiment LE truc qui m’a le plus convaincu dans ce use case.

Globalement satisfait, ça fait réfléchir. Je vous laisse admirer le résultat :

BDX I/O 2025 - Récap de ma 10ème édition

Fri, 07 Nov 2025 18:00:00 +0200

10 ans déjà !

BDX I/O fêtait sa 10ème édition cette année, et c’était forcément une édition particulière pour moi. Après avoir co-organisé l’an dernier, cette année j’étais de nouveau un simple participant (même si j’ai aidé pour la relecture du CFP).

Voir le résultat incroyable, une fois de plus, de cette conf, et replonger dans les souvenirs en foulant les couloirs du Palais des congrès, je n’ai pu m’empêcher de ressentir un petit pincement au coeur de n’avoir pas été capable de participer plus activement, cette année.

Je vais donc devoir me contenter de mon habituel récap’ de conf !

Zébartyyyy

Keynote d’ouverture : Dix ans d’impact, 10 ans d’innovation

La keynote a célébré ces 10 années de BDX I/O, La technologie au service de la société.

10 éditions de BDX I/O, ça en fait des années d’évolutions techniques et technologiques. Et des émotions !

Coralie et Amélie étaient au top. J’ai reconnu toute l’équipe sur leurs photos d’eux enfants ;-)

Mention spéciale à La Grappe Numérique, qui regroupe toutes les associations et meetups bordelais, dont le CNCF Bordeaux que je co-organise. C’est important de souligner ce genre d’initiatives qui structurent la communauté tech locale !

https://www.lagrappenumerique.fr/#/

Comment prédire l’imprévisible

Ludovic Cinquin, fondateur de WhereWeGo (stratégie IA), nous a proposé une réflexion sur le futur de la tech.

Citation de Bill Gates qui résume bien sa pensée :

“Nous surestimons le changement dans les 2 prochaines années, sous-estimons celui qui surviendra dans les 10 prochaines années”

Quelques points marquants :

Le web 3.0 a fait pschit, le quantum reste difficile à quantifier (ho ho ho)
“Software is eating the world” (Marc Andreessen) - toutes les activités humaines basculent dans le numérique. “But AI is going to eat software” - l’IA transforme maintenant le software lui-même.
HLMI (Human-Level Machine Intelligence, le terme pour ne pas dire AGI dans les milieux savants) : la question du moment où on aura des machines autonomes à moindre coût par rapport à un humain. Estimation 2045 ? Mais gros bond en avant dans les prévisions entre 2022 et 2023 quand on a demandé à 1800 chercheurs.
Il a mentionné le projet ai-2027.com et l’histoire d’OpenBrain AI - le débat éternel : Terminator vs IA for good.
Les limites de l’IA selon Eric Schmidt : consommation d’énergie. Pour 2027, +29 GW prévus aux US, ce qui va être compliqué (euphémisme). L’IA devrait induire à terme un doublement possible de la taille des datacenters, mais pour décarbonner les usages de l’humanité dans sa globalité, il va y avoir prédation entre les usages. Idem pour la disponibilité du cuivre nécessaire à l’électrification.

Pour finir, Ludovic a parlé de comment accompagner cette transition qui arrive (c’est son métier de consultant).

Ludovic a évoqué le framework Cynefin : complexe / compliqué / chaotique / simple, pour aider les décideurs à naviguer la complexité.

Il a cité “L’Agile” comme un outil très utilisé dans l’IT qui permet justement ça, et le travail par scénario. Ce qui est prévu n’arrivera pas forcément, mais la capacité d’adaptation est acquise. Exemple du TGV COVID : scénario qui avait déjà été réfléchi à la base pour les attentats, et qui a très bien marché pour la crise COVID.

Conclusion : nous avons tous une responsabilité sur les enjeux sociétaux.

De développeur à hacker : savoir casser c’est savoir protéger

Florian Toulemont (architecte solution, ethical hacker, 161ème sur root-me.org, excusez du peu !) nous a parlé de hacking éthique.

Sans même être allé sur son profil root-me (je n’avais pas de réseau sur le moment), ça se voyait que Florian savait de quoi il parlait. Notamment, entre 2 phrases de vulgarisation, il lâchait un terme très technique… un peu comme s’il avait envie d’expliquer en détail des trucs pointus mais que c’était pas prévu dans le talk 😉.

Je regrette juste que trop de temps ait été passé sur l’introduction. C’était très (très) vulgarisé, en partant vraiment de la base (de la base), et c’est dommage parce que l’intérêt du talk résidait vraiment dans la seconde partie qui a été rushée. Les exemples d’attaques classiques étaient super clair.

Quelques outils mentionnés que j’ai noté :

Analyse DAST : OWASP ZAP / Burp Suite
Ffuf : fuzzing web
Dirb : exploration web
SQLMap : exploitation SQL injection
Exegol : environnement de pentest dockerisé pré-configuré

Fun fact, j’ai d’ailleurs découvert Exegol hier pendant mon running en écoutant le podcast de mon éminent collègue Martial (Hack-n-speak) qui recevait Shutdown, son créateur.

Note à moi-même : voir le talk Réécrire le rôle : développeur à l’ère des LLM d’Horacio (que je n’ai pas eu le temps de voir), qui m’a été unanimement recommandé.

Oui, Kubernetes peut faire tourner vos applis Windows. Sérieusement.

Un talk que j’attendais depuis des années.

Nicolas Boisseau de chez Peaksys (la filiale IT de CDiscount) nous a démontré que oui, vraiment, Kubernetes supporte Windows.

Petit rappel historique :

Docker : 2013(ish)
Windows : des containers docker dans Windows en 2015
Kubernetes 1.14 : support en GA pour les nodes Windows en tant que worker Node (2019)
1 an plus tard : GA sur AKS

Chez Peaksys, ils ont donc remplacé une architecture complexe à base d’AppServices Azure d’un côté (pour le legacy .NET Framework) et d’AKS (.NET Core) par tout sur AKS avec des workers Linux et Windows.

Tout au long de ce REX (efficace), j’ai découvert pas mal de choses sur les containers Windows.

D’abord, l’existence d’une fonction “Switch to Windows container” en un clic droit dans Docker Desktop ?!?

Ensuite, les containers Windows fonctionnent sur des concepts similaires à ceux pour Linux : le kernel Windows est partagé avec le container. Ça veut dire qu’on doit avoir un container Windows compatible avec l’OS Windows hôte.

Et ce n’est pas la seule contrainte :

sur Azure, Azure CNI obligatoire pour avoir des clusters multi-OS.
Attention à la taille des images : 10GB+ (nodes Windows préchargés avec les images de base)
Il faut bien sûr des licences Windows (sinon c’est pas rigolo) !
Et la gestion des logs complexe : tout ne sort pas dans stdout (events, logs fichiers)

Pour ce dernier point, Log Monitor, un outil microsoft, semble faire le café.

Mais ça fonctionne, ils ont leur prod dessus. GG

Crossplane : Déployer vos composants Cloud depuis K8s sans drift

À 14h50 en salle D, Vivien Ramahandry nous a présenté Crossplane.

Le problème de l’IaC classique : c’est cool, mais on ne gère pas le drift.

Arrive alors Crossplane : OSS depuis 2018, version 2.0 récemment, et Graduated CNCF (la veille de la conf !).

“Extend Kubernetes to manage any resource anywhere”

C’est particulièrement utile pour les ressources cloud. Le concept, tirer parti de la philosophie de Kubernetes “tout est une boucle de contrôle” et étendre les controllers Kubernetes built-in pour gérer n’importe quelle resource externe.

Vivien nous a ensuite prouvé ça avec une petite démo bien orchestrée :

Gestion d’un bucket S3 et des tags
Import de ressources existantes : mode “observe” dans un premier temps, puis géré par Crossplane

Ce point est très impressionnant quand on vient du monde TF. C’est BEAUCOUP plus simple que dans Terraform !

Live Coding d’algorithmes de génération de labyrinthes

Fabien Lamarque nous a proposé un live coding ludique et pédagogique.

Très chouette talk ! On a livecodé “tous ensemble” (et un peu réfléchi à plusieur quand il y avait des erreurs) 3 algorithmes pour générer des labyrinthes dits parfaits (sans boucle, ni portions inaccessibles), ainsi qu’un bout d’algo de Dijkstra pour calculer le plus long chemin.

Pas mal de fun facts, un peu de théorie, beaucoup de fun. C’était du Ruby, que Fabien nous a vendu comme “facile à lire pour ce genre d’exercice d’algorithmique” et j’ai trouvé ça très vrai.

Le genre de talk qui change d’air et qui me rappelle pourquoi j’aime coder !

Kyverno : la conformité dans votre cluster Kubernetes

Julien Canon nous a présenté Kyverno.

Petit aveu : j’ai participé à la relecture du CFP et quand j’ai vu cet abstract, j’ai pensé “ce talk, j’aurais aimé le donner moi-même”. Je suis donc super content que Julien ait été retenu, comme ça (égoïstement) je peux le voir 😄.

Contexte : Julien nous a présenté Kyverno à travers un REX, au sein d’une entreprise multi-région, assez mature sur l’infra/DevOps, avec observabilité et scaling automatique, mais de plus en plus de petits problèmes générant des incidents.

Problèmes récurrents :

Limits/requests pas définies ou mal définies
Ownership flou
apiVersions vieillissantes
Containers pas sécurisés
Images non sécurisées
Ressources non décommissionnées
Problèmes de nomenclature

Les problèmes classiques, j’ai envie de dire 😄. En tout cas, j’ai eu les mêmes.

Et il nous a montré avec une grosse démo que Kyverno peut nous aider à résoudre ces problèmes. Ou du moins, empêcher les gens de déployer, tant que ça n’est pas réglé :trollface:.

Dans les petits “trucs” au-delà des fonctionnalités de base, j’ai aimé que Julien aille un peu plus loin sur :

le flag --enablePolicyExceptions pour permettre de gérer des exceptions ponctuelles, mais attention : impact important sur les perfs.
la règle autogen.rules (cf doc) qui permet d’appliquer automatiquement les policies sur les pods aux objets qui créent des pods (Deployments, StatefulSets, etc.).
la mention du support de CEL (Common Expression Language) par Kyverno dans les versions récentes : précompilé, plus performant
le playground.kyverno.io pour visualiser l’impact de ses policies

J’ai aussi aimé qu’il donne des petits conseils pour débuter, notamment en commençant simplement par un audit Popeye pour aider à décider quelles règles ajouter en premier.

Quelques ref de “vieux” qui m’ont bien fait rire 😉

J’ai malheureusement dû partir avant la fin du talk, pour respecter mes obligations familiales 😅.

Networking et rencontres

Comme toujours, BDX I/O c’est aussi (surtout ?) les rencontres !

J’ai eu le plaisir de rencontrer Virginie “en vrai” pour la première fois, et de revoir Jean, Thomas, Ane, Horacio, Marina, Stéphane, Benoit, Loïc, Jean-Rémy, Christian, Julien (x2), Romane et bien sûr tous les membres de l’équipe d’orga (je ne vais pas citer tout le monde mais je pense à TOUS) et de la team Deezer (idem).

Vivement l’année prochaine :).

DevFest Nantes 2025 - Récap des 2 jours

Fri, 17 Oct 2025 18:00:00 +0200

Mon premier DevFest Nantes !

Comme vous l’attendez tous (oui, je le sais), je suis obligé de rédiger, dans le train, mon traditionnel “récap’ de conf”, ici pour le DevFest Nantes 2025 !

Pour rappel, c’était une double première pour moi : je n’avais jamais participé à cette conférence en particulier, et je n’avais jamais présenté de sujet “en duo”.

Dasha Ilina - Advice well taken

Dasha Ilina, artiste techno-critique (si j’ai bien saisi le terme), a ouvert le DevFest avec une keynote intéressante sur le folklore technologique moderne.

https://dashailina.com/

Son point de départ : nous développons peu à peu un nouveau type de folklore autour de la technologie - le “techlore”.

Elle a exploré comment nous créons des mythes technologiques modernes (Cher est convaincue que son iPad était “hanté” ???), alors que nous ne comprendrions plus vraiment comment fonctionnent nos outils quotidiens.

Dasha a évoqué les promesses oubliées des débuts d’Internet, en citant le “Whole Earth Catalog” publié au début d’Internet (modes de vie alternatifs, DIY), précurseur d’Internet dans la façon dont l’information était créée et diffusée.

Elle a également parlé de ses projets artistiques autour des mythes technologiques contemporains : “Cover your camera”, “Smartphone tombé dans l’eau qu’on met dans le riz”, “My cell phone is spying on me”.

Particulièrement intéressant : son concept de “contestation café” - un lieu pour récolter des histoires de traitement injuste algorithmique et systèmes décisionnels. Pas comme un repair café pour apprendre à faire, mais pour trouver collectivement comment lutter contre les algorithmes.

Je ne me suis pas retrouvé dans la totalité de ses positions, mais c’était certainement intéressant d’avoir le point de vue extérieur d’une non technicienne sur le monde technologique que nous contribuons, nous techs, à créer.

Select amazing feature FROM PostgreSQL

À 10h00, Kevin Davin nous a fait découvrir les trésors cachés de PostgreSQL.

Kevin a commencé par un petit historique de PostgreSQL, dont j’ignorais les racines.

Ce qui m’a marqué dans cette présentation, c’est la richesse de PostgreSQL au-delà du SQL classique :

Common Table Expressions (CTE) pour améliorer la lisibilité du code, avec exécution en parallèle
FILTER pour mettre les données dans plusieurs buckets avec count(*)
row_number() pour la déduplication et récupérer les dernières locations de films
LEFT JOIN LATERAL pour des jointures plus sophistiquées
UUID pour protéger des attaques par énumération (au lieu des classiques serial)
Contraintes regex POSIX pour valider le format des données (exemple avec l’ISAN)
LISTEN/NOTIFY pour de la messagerie en temps réel
ltree pour gérer des arborescences (exemple donné : les films Terminator non linéaires)
Foreign Data Wrapper - exemple parlant avec /etc/passwd exposé comme une table, avec des exemples plus concrets ensuite
Full text search natif dans PostgreSQL
JSONB pour du NoSQL dans du SQL

Kevin a terminé en citant des outils comme ferretDB (surcouche à PG compatible MongoDB), postgREST et graphjin qui exposent les tables sous forme REST.

Super présentation, très dense (plus de 150 slides). Et surtout, il a su résister courageusement à de gros problèmes de clignottement (voire extinction) d’écran. Expliquer du SQL en slideless, chapeau !

Talk que j’aurais voulu voir en même temps : From Flatcar dev to proxmox Deployment

La science peut-elle s’implémenter positivement ?

À 14h00, m4dz et Nicolas Delsaux ont proposé une réflexion philosophique sur l’intelligence artificielle.

Leur point de départ : “L’intelligence artificielle est partout, surtout dans les talks qu’on va voir cet après-midi…”. Pourtant, c’est un vieux sujet !

Ils ont exploré des questions fondamentales :

Peut-on détecter une conscience dans un LLM ?
Comment définit-on la pensée ? (Question philosophique ET neuroscientifique)
Qu’est-ce que la “théorie de l’esprit” ?

Ils ont cité le film “Her” et évoqué des exemples troublants comme les “chiens robots” AIBO, et des conséquences psychologiques que ça a eu quand Sony a décidé de couper les serveurs (le robot-chien est “mort”). Le concept de “seemingly human” : l’impression que l’attention est portée, le sentiment d’attente. C’est ce qui crée des dark patterns.

Ils ont revisité les 3 lois de la robotique et cité le Dune d’Herbert : “Tu ne feras pas de machine à l’image de l’esprit humain.”

Conclusion forte : ça nous libère de la singularité/AGI ! Ils ont évoqué “l’asservissement volontaire” (Alain Damasio, “La zone du dehors”) - vrai pour les données personnelles, mais aussi avec l’IA.

Référence intéressante au “techno-féodalisme” de Yanis Varoufakis et au livre “CLEER” qui montre que la réalité n’est pas la même selon les échelons sociaux. J’ai envie de lire ce dernier, d’ailleurs !

Je ne m’attendais pas du tout à ça, mais c’était une session rafraîchissante qui posait les vraies questions (plus qu’elle n’y répond 😏) !

Let’s play Factorio

À 15h10, Julien Wittouck nous a proposé une analogie brillante et ludique entre divers concepts d’ingénierie logicielle et le jeu Factorio.

Le parallèle était saisissant :

Code spaghetti vs Monolithe -> Début chaotique avec des rustines partout Lasagna architecture -> Architecture en couches bien organisées Microservices -> Modules spécialisés… avec leurs problèmes d’observabilité !

Julien a exploré l’urbanisation des systèmes, l’Enterprise Service Bus (ESB), et les concepts de scalabilité verticale vs horizontale.

Points marquants :

Les buffers sur les topics Kafka comme les convoyeurs dans Factorio
Le monitoring (on/off, débit) essentiel dans les deux cas
Le firewalling pour protéger ses ressources

Et bien sûr, la philosophie ultime de Factorio qui s’applique parfaitement au développement : “The factory must grow” ! Le vrai problème, c’est que ça donne envie de jouer à Factorio 🙈.

C’était dans quel épisode déjà ? - Bref j’ai indexé une série culte

À 17h50, Tim Carry nous a présenté un side project de dev qui est enfin terminé (:trollface:) : brefsearch.com.

Tim, fan inconditionnel de la série “Bref”, a créé un moteur de recherche pour retrouver n’importe quel clip vidéo contenant n’importe quelle réplique de la série.

Quelques concepts techniques et outils évoqués :

yt-dlp pour télécharger les épisodes (CLI avec une DX simple, mais il faut lire la doc pour les cas complexes)
IA speech-to-text via HappyScribe pour la transcription
ffmpeg pour les screenshots et aperçus vidéos
Algolia (API) pour le moteur de recherche + instantSearch
Cloudinary CDN++ pour le redimensionnement et l’optimisation d’images
LQIP (Low Quality Image Placeholder) en 16x9 pixels pour améliorer la sensation de fluidité
Buffer invisible sur le hover (100px) pour précharger les aperçus vidéos

La référence à “Algolia 3000” m’a bien fait sourire !

La citation qui restera :

“Il n’y a pas de side projects abandonnés, il n’y a que des bonnes idées qui attendent le bon moment.”

C’est mignon :)

Vendredi - Jour 2

Karpenter x Keda - le duo gagnant du FinOps

À 9h00, Guillaume Membré et Sébastien Fourreau nous ont parlé d’une migration OVHcloud → AWS avec une stratégie FinOps au cœur du projet.

Le titre m’avait laissé penser qu’il y avait un lien direct entre KEDA et Karpenter, mais en fait les deux outils étaient simplement utilisés conjointement.

Point intéressant, Sébastien a cité un gain de coût substanciel juste en changeant de type d’instances (m5a vs m6a, j’avoue que je ne connais pas le catalogue AWS 😂).

J’ai été un peu surpris (déçu serait trop fort) que les instances spot aient été abandonnées sur les environnements de développement car trop disruptives pour les développeurs, et que la compaction de Karpenter ait été bridée en journée (uniquement du scaling up pendant la journée).

J’imagine qu’il faudra faire une suite pour ce talk, une fois la migration terminée !

Notre talk : Limits, requests, QoS, PriorityClasses

Notre talk du DevFest ! Vendredi à 11h20 en salle Belem, avec Quentin Joly.

Premier talk en duo dans ma courte carrière de speaker, et globalement ça s’est très bien passé ! Nous avons effectivement “balayé ce que vous pensiez savoir sur le scheduling dans Kubernetes” avec des démos qui ont poussé nos clusters dans leurs derniers retranchements, comme promis.

Le bilan honnête :

Salle à moitié pleine (~200-250 personnes), mais public attentif et intéressé, bons feedbacks, chouettes questions
Toutes les démos ont marché, malgré quelques petites frayeurs (non, je n’ai pas de bonne recette de “flans”, Quentin)
Quelques soucis de changement d’écran entre slides et démos (je ne m’étais pas assez entraîné sur le setup de Quentin 🙈)
Des blagues improvisées qui ont plutôt bien marché
Du fayotage de haut vol (les collègues comprendront)
Petit souci de gestion du temps : on a été un peu trop rapides ! À priori ça s’est peu vu. On a fini avec de l’avance, mais heureusement, le public génial nous a posé plein de questions pertinentes

La palme de la session, au-delà des divers retours positifs en direct que nous avons reçus, est qu’à priori nous avons débloqué un incident en cours dans l’entreprise d’un des participants, à l’aide d’un des takeaways que nous avons donnés (impact des cpu.limits sur le P99).

Coup de barre

Je voulais aller voir les talks de Thierry Chantier (TUI) et Stéphane Philippart (JBang), mais je suis arrivé trop tard à l’un, trop vidé pour me déplacer jusqu’à la salle de l’autre.

Les interactions sociales sont hyper intenses pendant ces jours de confs et vident les batteries de tout le monde (même les extravertis, ce que je ne suis pas).

Démêler vrais produits et hallucinations, REX d’un agent téléphonique chercheur de chaussettes

À 16h50, j’ai quand même fait l’effort d’aller voir le talk de Marie Terrier, dont j’avais lu l’abstract lors de ma relecture du CFP de BDX I/O. Il s’agissait d’un REX fascinant sur l’implémentation d’un agent conversationnel “trouveur de chaussettes”.

Marie travaille chez Yelda, un SaaS d’agents vocaux qui existe depuis 7 ans. À l’origine, c’était du NLP classique avec des réponses prégénérées ou avec des “slots” (genre de variables si j’ai compris). En 2022-2023, l’intégration de GPT 3.5 en 2023 comme filet de sécurité pour les questions non prévues a été le début d’un tournant pour son produit.

À l’aide de cette technologie, elle a essayé de construire un produit permettant aux pharmaciens de retrouver par téléphone des produits (bas de contention) aux noms complexes. Problème : passer de 40 produits en proto à 20000 en production avec les limitations techniques de l’époque (tokens, lenteur, hallucinations).

Leur solution : architecture hybride avec RAG + Algolia pour la recherche floue, LLM pour la conversation et un LLM vérificateur. Marie a aussi évoqué les défis UX spécifiques aux agents vocaux (SSML, gestion des interruptions).

Excellent talk qui a su captiver son audience malgré l’heure tardive.

Soirées et networking

En réalité, le DevFest commence un jour plus tôt pour quelques “happy few”. J’avais déjà eu la chance de visiter et faire un tour de manège sur le “Carrousel des Mondes Marins” lors d’une précédente visite de Nantes. J’ai pu réitérer l’expérience grâce aux organisateurs du DevFest qui avaient privatisé le lieu, puis organisé une petite soirée d’accueil.

C’était très sympa, j’ai eu des discussions passionnantes avec plein de gens, mais en particulier avec Kevin Davin, un des tout premiers speakers que j’ai vus en conf à BDX I/O il y a 7 ans maintenant (avant d’être speaker donc).

Le jeudi soir, rebelote, mais ça commençait à tirer un peu 🥳😴. J’ai pu parler avec Fanny, Stéphane, Julien (x3 🙃), mes collègues de Lucca (présents en force), Laurent et d’autres que j’oublie sûrement.

Sur le stand de Lucca, j’ai parlé avec plusieurs collègues plus côté dev / produit, ce que je ne fais pas assez souvent. C’était très instructif :). Et bigup aux TAMs, of course, qui font un travail formidable.

Et dans les couloirs ou en salle speakers, j’ai croisé certains d’entre vous, dont Mathieu, Alexandre, Jérôme, mais aussi Xavier, dont certains avec qui j’avais déjà discuté plusieurs fois, mais jamais rencontré “en vrai”. C’est chose faite !

Un dernier gigantesque MERCI aux organisateurs du DevFest, qui nous ont chouchouté et concocté une très chouette édition.

See you next time.

Au secours, le métier d’Ops va ENCORE disparaître ! (5 ans après)

Fri, 15 Aug 2025 12:00:00 +0200

Note : cet article est la suite d’un long post de 2020 qui s’appelait Au secours, le métier d’Ops va disparaître ! Je parlais notamment (mais pas que) d’une prédiction de Gartner qui annonçait la fin des ingé sto en 2025. Mais qu’en est il, maintenant qu’on y est ? Et qu’est-ce que ça dit de ce genre de prédictions ?

Introduction

Musique de film catastrophe et voix off grave

Nous sommes en 2025. Exactement comme Gartner l’avait prédit en 2019, il est aujourd’hui impossible de trouver un emploi en tant qu’ingénieur stockage. 💀💀💀

(Pour rappel)

“Le cloud et l’hyperconvergence ont à ce point réduit la demande pour des spécialistes du stockage que, d’ici à cinq ans, il sera tout simplement impossible de trouver un tel profil sur le marché de l’emploi.”

Operations & Cloud Strategies, Gartner, fin 2019

…Oh. Wait. 😵

(Ça fait 5 ans que j’attends de pouvoir faire ce post 😆)

Cette prédiction qui semblait déjà tirée par les cheveux à l’époque… l’est encore plus aujourd’hui.

Non seulement il y a encore beaucoup d’ingénieurs stockage, en France et ailleurs, mais le marché regorge d’offres (des centaines sur le site de l’APEC), y compris sur d’autres techno de stockage (Ceph ? S3 ?) qui tirent la demande vers le haut.

Ce n’est pas la première fois que j’entends ce genre de prophétie :

2013 : on m’explique que je dois “vite devenir développeur” car avec l’adoption du cloud, il n’y aurait bientôt plus de sysadmins. On en rigolait alors, on en rigole toujours.
2020-ish : le nocode allait “tuer” le développement traditionnel. Oui car tu comprends, on peut recoder Airbnb en 2 jours sans coder une ligne sur Bubble. M-D-R.
Début 2024 : un influenceur IA (sûrement un reconverti NFT ?) sur LinkedIn annonçait que GPT-4o “allait plier le game du développement” en 6 mois. Verdict : coder uniquement avec GPT-4o reste… une expérience (je reste poli). On verra avec GPT-5 :trollface:

Les remarques que j’ai reçues

J’ai posté une version plus courte de ce billet sur les réseaux sociaux et voilà quelques réflexions intéressantes que j’ai reçu en échange :

“Les experts SAN ne pouvaient pas disparaître en 5 ans, ce n’était pas sérieux comme prédiction.”
“J’ai même l’impression que la ddemande d’experts stockage augmente, notamment parce qu’il faut aussi des experts Ceph ou S3, plus seulement NAS/SAN.”
“Les offres de sysadmin ‘traditionnel’ se raréfient drastiquement… mais j’imagine que le métier évolue.”
“Il y a 5 ans, je faisais surtout du stockage traditionnel. A mon échelle, l’hyperconvergence a effectivement changé la donne et m’a poussé à évoluer… mais ça disparaîtra peut-être un jour à son tour.”

C’est un poil plus complexe que mon “c’est débile comme prédiction”, je vous l’accorde volontiers 😉

Et je suis totalement d’accord : le métier évolue. C’était d’ailleurs la conclusion de mon blogpost de 2020. Comme quoi je n’étais pas totalement à côté de la plaque.

Il est vrai de dire qu’un poste de sysadmin “comme en 2013", c’est devenu plus rare, surtout dans les grosses structures. Et en vrai de ce que je me souviens d’une partie de mes tâches de 2013, c’est peut être pas dommage (coucou les intalls de softs sous Windows server en déroulant des docx maison avec les mdp en dur)…

Mais dans les petites boîtes, il reste encore de la demande pour des profils plus généralistes, épaulés par plus d’outillage qu’avant.

Prendre du recul

Ce qui est amusant (ou agaçant ?), c’est que ces annonces de “fin du métier” reviennent régulièrement, souvent lancées par des gens pas sérieux.

Mais ce n’est pas toujours le cas ! Ici, on est face au supposé sérieux des analystes de chez Gartner (même si les PPTs de McKinsey sont passés par là).

Même si Gartner est de moins en moins unefigure d’autorité, j’aurais plutôt dit que c’était le genre d’annonces qu’un board aurait pu prendre (à tort) au sérieux. Alors que c’était évidemment cavalier comme prédiction.

Les faits montrent que :

Les métiers (notamment techniques) ne disparaissent pas brutalement, ils ont plutôt tendance à muter.
Chaque vague technologique supprime des tâches répétitives… mais crée aussi de nouvelles couches de complexité. Oui, expert Kubernetes, c’est mon métier 🤣.
Ceux qui connaissent le “fond” technique finissent toujours par être nécessaires, même quand la surface change.

On pourrait penser que la GenAI est différente (en tout cas, je me le suis demandé) : pendant un temps, elle a semblé être une vraie technologie de rupture, capable de bouleverser certains métiers, et pas seulement dans la tech.

Et dans l’infra ???

On parle très souvent des avancées récentes de la GenAI dans le code. Mais Quid de la GenAI dans administration système : fantasme ou vraie révolution ?

Mon avis est clairement que “c’est nul” aujourd’hui (oui je suis visiblement fatigué de la nuance aujourd’hui), et c’est ce que j’ai partagé à plusieurs personnes. Les réactions ont été intéressantes.

A mon avis, pourquoi ça coince ?

Les LLMs s’appuient sur un mélange de probabilité et du contexte fourni. Sur des sujets très spécifiques (ex : “une grosse base mélangée de docs, code et IaC pour un gros SaaS multi-tenant”), ils sortent rarement quelque chose de directement exploitable.

Les datasets d’infra sont pauvres : la plupart des configs ou procédures ne sont pas publiques contrairement au code, donc les modèles manquent d’exemples pertinents.

L’infra a mille façons d’être faite, et il y a rarement de pattern adaptable à de nombreux contextes, ce qui rend la généralisation encore plus bancale.

Mais on m’a quand meme remonté quelques cas où ça marche mieux :

Génération de scripts bash, “curler” des APIs, pondre une grande quantité d’IaC (exemple avec du code Terraform) à partir de l’existant.
Investigation ponctuelle : certains m’ont cité GPT o3 ou Claude Code capables de trouver des problèmes de config que l’humain n’avait pas vus.
Automatisation de tâches pénibles ou répétitives.

Mon expérience perso :

Oui, en “pair programming” pour construire, ça marche si on y va vraiment trèèès progressivement… mais c’est lent au point que parfois je me dis que j’aurais mieux fait de le faire moi-même.

Pour du day 2 ops (debug, maintien en conditions opérationnelles, gestion d’incidents), ça reste loin du compte, même si des agents SRE commencent à pointer le bout du nez… Mais j’attends encore de voir un “agent SRE” qui fait bien le job la plupart du temps… sans casser la prod pendant que je dors !

Conclusion

Après plus de deux ans de hype intense, la réalité me semble plus nuancée : oui, le cloud et maintenant la GenAI commencent à chahuter nos métiers, parfois spectaculairement, mais on est loin de provoquer la disparition massive et soudaine (pas que dans la tech) de tout un pan de la tech actuelle (ex. les ingés sto).

L’expérience montre que, si changement il y a, il sera progressif et laissera le temps de s’adapter.

Bref, on n’est pas encore remplacés.

Peut-être qu’un jour, une prédiction de ce genre sera juste. Mais l’histoire récente invite surtout à rester prudent… et à ne pas paniquer à chaque annonce catastrophiste.

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