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.

Comme j’avais envie de tester un truc nouveau, j’avais 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 donner une contrainte débile : tout déléguer à GitHub Copilot Agent, 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 que je n’arrive pas à utiliser correctement. 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 :

1. Menu “Archives” affiché en double dans le menu
2. 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”, “corrige 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.

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 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 visuel 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 :