automatisation on Zwindler's Reflection

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 :

Ansible : subtilités avec « defined » et « skipped »

Mon, 07 Feb 2022 07:00:00 +0000

Ansible des fois c’est pénible

Je vous parle souvent d’Ansible car c’est vraiment un outil qui a changé ma vie d’Ops. Pour autant, des fois c’est up peu pénible à comprendre…

Dans cet article je vais vous parler d’un de ces moments où j’ai vraiment pesté contre les Devs (c’est pas la première fois…). L’erreur initiale était mienne (a priori) mais les workarounds que j’ai testés me paraissaient légitimes…

Et cet article va me permettre de vous illustrer 2 concepts utiles pour vos tâches et variables Ansible qui sont skipped et defined.

C’est l’histoire de deux tâches

Pour remettre les choses dans le contexte : j’ai certaines actions que j’effectue ou non selon les cas sur un groupe d’hôtes donnés. Et c’était typiquement le cas ici…

Note: le code Ansible en lui-même n’est pas impeccable, on peut (et d’ailleurs, on va) faire beaucoup plus propre ; ce n’est pas ce que je veux montrer ici.

Voilà les tâches incriminés :

- name: "Get some content from a command"
 command: "command outputting something"
 changed_when: false
 register: command_output
 when: not_in_test_env

- name: "Write command_output to file"
 copy:
 dest: "{{ command_output_file_path }}"
 content: "{{ command_output.stdout }}"

Le contenu des deux tâches importe peu, car c’est plus des limitations d’Ansible que je vais vous présenter ensuite qui importe. On pourra retrouver cette limitation dans d’autres cas plus pertinents.

Ce qu’il faut retenir, c’est que :

la première tâche génère un output texte et enregistre le contenu dans une variable command_output
la seconde tâche copie le contenu de cette variable dans un fichier texte

Cela pourrait donc être n’importe quelle variable qu’on collecte de n’importe quelle autre façon… On peut donc légitimement appliquer ce genre d’opération dans d’autres contextes, avec certains nodes où on souhaite exécuter ces deux actions et certains autres, non.

Et là, c’est le drame.

Lors du moment où j’ai eu mon erreur, j’étais persuadé d’avoir bien mis un when: not_in_test_env pour skip la 2ème tâche aussi si la première l’est. Visiblement ce n’est pas le cas puisque je n’ai pas pu reproduire…

Dans le premier cas qui nous intéresse donc, si not_in_test_env est positionné à true, pas de problème.

En revanche, si je saute la première partie grâce à la variable not_in_test_env positionnée à false dans les fichiers de configuration de l’inventaire, vu qu’a priori j’ai fait une erreur et n’ai pas correctement écrit mon when dans la 2ème tâche, la première tâche est bien « Skipped » lors de l’exécution du playbook, mais la tâche suivante « Fail » misérablement.

Et pour cause… Ansible essaye à tout prix de résoudre la variable command_output.stdout alors même que la tâche va être « Skipped ». Sur le moment, je n’arrivais pas à comprendre POURQUOI ça n’étais pas skip et j’ai donc essayer de trouver des parades.

Pile, tu gagnes, …

Ma première idée a été de tenter de feinter l’erreur en initialisant la variable dans le cas où elle n’est pas renseignée car la tâche est « Skipped ».

- name: "Write command_output to file"
 copy:
 dest: "{{ command_output_file_path }}"
 content: "{{ command_output.stdout | default('') }}"

Manque de bol pour moi… je suis encore sur une vieille version d’Ansible, le | default( ») ne fonctionne pas sur les sous-variables (ici .stdout).

Beginning in version 2.8, attempting to access an attribute of an Undefined value in Jinja will return another Undefined value, rather than throwing an error immediately. This means that you can now simply use a default with a value in a nested data structure (in other words, {{ foo.bar.baz | default('DEFAULT') }}) when you do not know if the intermediate values are defined.

https://docs.ansible.com/ansible/latest/user_guide/playbooks_filters.html

| default ou pas, Ansible essaye donc de résoudre command_output.stdout ; la tâche continue donc de « Fail »…

… Face, je perd

En passant en mode « debug », j’ai remarqué quelque chose que je ne savais pas. Quand on « Skip » une tâche avec un register:, la variable pas enregistrée (car skip) n’est pas vide. Mon problème est que command_output.stdout n’existe effectivement pas, mais command_output si.

Plus précisément, Ansible injecte une sous entrée command_output.skipped positionnée à « true ».

Je me suis donc dit : banco ! Je vais modifier ma condition pour qu’elle empêche l’exécution de la tâche si command_output.skipped existe (car ça veut dire que command_output.stdout n’existe pas).

Ça donne quelque chose comme ça :

- name: "Get some content from a command"
 command: "command outputting something"
 changed_when: false
 register: command_output
 when: not_in_test_env

- name: "Write command_output to file"
 copy:
 dest: "{{ command_output_file_path }}"
 content: "{{ command_output.stdout }}"
 when: not command_output.skipped

Et là, dans le cas où not_in_test_env est false, ça ne fail plus.

Victoire ? Non bien sûr… car command_output.skipped n’existe pas (pas de skipped = false) quand la tâche est exécutée (c’est à dire « pas skipped »). Retour à la case départ : maintenant ça « Fail » dans le cas où on ne « Skip » plus…

Sur la tranche, je perds aussi

Dernière idée, on peut se dire que le plus simple / propre, c’est tout simplement de tester le fait qu’une variable (que ce soit command_output.stdout ou command_output.skipped) soit « defined » pour décider si on exécute ou pas la tâche.

- name: "Write command_output to file"
 copy:
 dest: "{{ command_output_file_path }}"
 content: "{{ command_output.stdout }}"
 when: command_output.stdout is defined

Mais évidemment, pour que la blague soit complète, ce qu’il faut savoir c’est qu’une solution à base de command_output.skipped is defined, ne peut pas marcher…

En fait, il n’est pas possible avec Ansible d’utiliser is defined pour vérifier l’existence (ou non) d’un sous élément.

Solutions

La solution la plus simple, que je croyais dur comme fer avoir implémenté (mais mes tests additionnels me prouvent que non) c’est simplement d’ajouter un when: not_in_test_env à la 2ème tâche…

Dans la même veine, et qui permet en plus d’éviter d’initialiser pour rien command_output.skipped, il aurait pu être malin de simplement utiliser un block: avec le when, englobant les deux tâches :

- block:
 - name: "Get some content from a command"
 command: "command outputting something"
 changed_when: false
 register: command_output

 - name: "Write command_output to file"
 copy:
 dest: "{{ command_output_file_path }}"
 content: "{{ command_output.stdout }}"
 when: not_in_test_env

Et la vraie solution si jamais vous voulez absolument vérifier si la tâche précédente a été skipped ou pas, est d’utiliser la syntaxe suivante :

- name: "Write command_output to file"
 copy:
 dest: "{{ command_output_file_path }}"
 content: "{{ command_output.stdout }}"
 when: 'skipped' not in command_output

Cette syntaxe n’est pas hyper évidente de prime abord, mais c’est la seule qui fonctionne dans Ansible pour faire ça…

Bonus

Un lecteur (‘Jof) m’a fait remarquer qu’il y a une autre solution qui marche dans tous les cas :

- when command_output|skipped

Merci à lui !

Conclusion

Le vrai problème ici est quand même que j’avais vraiment besoin de vacances pour ne pas avoir été capable de trouver l’erreur aussi basique ;-).

La seconde est que j’utilise une version antédiluvienne d’Ansible et que ça irait beaucoup mieux avec des versions plus récentes (pour le | default notamment).

La dernière chose à retenir est que quand on veut vérifier la présence ou non d’un sous élément dans une variable, le mieux reste d’utiliser in ou not in plutôt que is defined qui ne fonctionne pas dans tous les cas.

Sources additionnelles

Import manuel de records DNS route53 avec Terraform

Mon, 20 Sep 2021 06:10:00 +0000

Terraform et l’Infrastructure as Code

Ce n’est pas la première fois que je parle de terraform, l’outil d’Infrastructure as Code particulièrement efficace dans les environnements cloud (mais pas que) de Hashicorp.

J’avais fait un petit « tour d’horizon » de l’outil quand il était encore en v0.10 (Hashicorp a passé terraform en v1.0 en juin), si vous avez besoin d’un petit rafraîchissement de mémoire ou que vous découvrez l’outil.

Pour la faire courte, l’intérêt de terraform (et de l’infrastructure as code) par rapport à l’automatisation plus classique est de passer dans un mode « déclaratif » où vous déclarez dans des manifests l’état souhaité de votre infrastructure plutôt que de dérouler un script qui fait les opérations unes à unes.

Vos manifests deviennent la « source de vérité », auditable, versionnable, absolue (pas de diff possible entre ce que vous pensez avoir déployé et le bidule modifié à la main hier que vous avez oublié).

Réconcilier l’existant avec l’infrastructure as code

Tout ça c’est super si jamais vous venez de commencer à travailler dans le cloud et que vous partez de 0.

Si vous avez déjà de l’existant, c’est plus compliqué puisque vous vous retrouvez avec une partie décrite dans votre dépôt Git et une autre partie « historique ».

Et même si on peut se dire que cette partie « historique » va finir par disparaitre au profit des nouveaux projets gérés par IaC, il existe une zone floue où on ne sait plus très bien si c’est géré à la main ou en IaC.

Du coup, autant en profiter quand on a le temps pour réintégrer le legacy dans l’IaC.

Route53, le DNS by AWS

Je suis donc arrivé dans un contexte technique où le DNS externe est géré par AWS depuis bien longtemps, et qu’on intègre progressivement les nouveaux records dans terraform. Cependant, j’avais besoin de modifier un record déjà existant (de type TXT) et je n’avais pas envie de le faire à la main.

Sachez donc qu’il existe pour une grande partie (tous ?) des providers terraform une commande terraform import qui permet comme son nom l’indique d’importer l’existant dans terraform.

Le souci est que cette import n’est réalisée que dans le « state » de terraform, pas la configuration elle même.

The current implementation of Terraform import can only import resources into the state. It does not generate configuration. A future version of Terraform will also generate configuration.

Vous allez donc devoir écrire le pavé HCL à la main.

D’un certain côté, c’est presque plus rassurant quand on y réfléchit, car ça permet de bien se poser la question de comment on souhaite découper nos projets, comment on veut construire l’IaC (avec des variables, avec des boucles, etc).

Récupérer les IDs uniques

L’idée ici va être de récupérer le record en donnant à terraform toutes les infos nécessaire pour qu’il retrouve celui qui nous intéresse. A la suite de terraform import, on doit lui donner les informations suivantes :

terraform import {resource_type}.{resource_name} {zone_id}_{record_name}_{record_type}

Dans mon cas, le resource_type était aws_route53_record, le resource_name mytxtrecord (le nom que je veux lui donner dans ma conf et mon state terraform). La zone ID dépend de votre compte AWS/route53, le record_name, c’est le nom du record (comme sur la console) et le record_type dans mon cas, un TXT mais ça aurait très bien pu être un A, un AAAA, un CNAME, etc.

terraform import aws_route53_record.mytxtrecord ABCDE1234567890_awesomeexample.org_TXT
aws_route53_record.mytxtrecord: Importing from ID "ABCDE1234567890_awesomeexample.org_TXT"...
aws_route53_record.mytxtrecord: Import prepared!
Prepared aws_route53_record for import

A l’issue de la commande, si tout s’est bien passé, vous devriez avoir un message qui indique le succès de l’opération et l’ajout du record dans le state de votre terraform. Il ne reste plus qu’à rédiger le pavé HCL pour votre IaC qui a cette tête là dans mon exemple :

resource "aws_route53_record" "mytxtrecord" {
zone_id = data.aws_route53_zone.awesomedomain.zone_id
name = "awesomeexample.org"
type = "TXT"
ttl = "60"
records = ["existingsuperimportantdata"]
}

On peut commiter ça, puis faire nos modifications comme d’habitude et en toute sécurité :-)

terraform plan
[...]
Terraform will perform the following actions:
# aws_route53_record.mytxtrecord will be updated in-place
~ resource "aws_route53_record" "mytxtrecord" {
fqdn = "awesomeexample.org"
id = "ABCDE1234567890_awesomeexample.org_TXT"
name = "awesomeexample.org"
~ records = [
+ "newtxtstring=veryimportantdata",
"existingsuperimportantdata",
]
~ ttl = 300 -> 60
type = "TXT"
zone_id = "ABCDE1234567890"
}
Plan: 0 to add, 1 to change, 0 to destroy.

automatisation on Zwindler's Reflection

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

TL;DR pour les pressés

Le contexte : pourquoi se faire mal ?

Phase 1 : La migration technique (15 minutes)

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

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

Comportement bizarre : PR ou commit direct ?

Un PaaS, ça aide

Conclusion

Ansible : subtilités avec « defined » et « skipped »

Ansible des fois c’est pénible

C’est l’histoire de deux tâches

Et là, c’est le drame.

Pile, tu gagnes, …

… Face, je perd

Sur la tranche, je perds aussi

Solutions

Bonus

Conclusion

Sources additionnelles

Import manuel de records DNS route53 avec Terraform

Terraform et l’Infrastructure as Code

Réconcilier l’existant avec l’infrastructure as code

Route53, le DNS by AWS

Récupérer les IDs uniques

Informations/sources additionnelles