Migrer WordPress vers Astro avec Claude Code : ce que la migration a fait remonter

Le point de départ

Mon site tournait sous WordPress depuis des années. Avant de toucher à quoi que ce soit, j’ai regardé ce qu’il contenait vraiment :

Ce que WordPress gérait	La réalité
Contenu publié	6 articles, dont aucun depuis avril 2026, et 7 pages
Commentaires	92 en attente, du spam d’après un échantillon, et aucun approuvé
Formulaires	Aucun
À maintenir	7 extensions, un thème payant et une base MySQL

Rien de tout cela ne justifiait un moteur PHP, une base de données et des mises à jour de sécurité à suivre. J’ai donc migré le site vers Astro, un générateur de site statique, en travaillant avec Claude Code.

Pourquoi un site statique

• Plus rien ne s’exécute sur le serveur : il n’y a plus d’extension à mettre à jour ni de faille PHP à surveiller.
• Les articles deviennent des fichiers : ils sont écrits en Markdown et versionnés dans Git, comme du code.
• Rien ne change pour les visiteurs : même hébergement chez OVH, mêmes adresses, même flux RSS.
• Ce que j’ai perdu : l’édition dans le navigateur. Pour un site que je suis seul à modifier, ce n’est pas un problème.

La méthode

L’IA écrit vite. La méthode sert à ce que cette vitesse ne coûte rien.

1. Inventorier avant de toucher. Les contenus, les extensions, les adresses, et tout ce qui traîne sur le serveur.
2. Tester dans un sous-dossier. Le nouveau site a d’abord vécu sous /staging/, à côté de WordPress, avec un en-tête qui en interdit l’indexation.
3. Garder les adresses. Les 17 adresses principales sont conservées, et les autres (équipe, auteurs, archives) redirigent.
4. Vérifier avec des outils, pas à l’œil. 618 liens internes testés, 740 segments de texte comparés entre l’ancien et le nouveau site, et chaque page contrôlée en largeur mobile.
5. Ne jamais supprimer automatiquement en production. Le déploiement ajoute et remplace des fichiers, mais n’en retire aucun : les suppressions se font à la main.
6. Neutraliser plutôt qu’effacer. Les fichiers de WordPress sont encore sur le serveur, mais l’administration, l’API et les extensions répondent « 410 Supprimé ».

Ce que la migration a fait remonter

Le plus instructif n’est pas la migration elle-même. C’est ce que l’inventaire a révélé, sur un site qui « marchait ».

Un script oublié, ouvert à tous

À la racine du serveur, un fichier PHP au nom anodin acceptait des identifiants de base de données, sans aucune authentification. Il permettait de joindre la base MySQL depuis l’hébergement, la seule machine qui y a accès. Il est supprimé.

Un déploiement qui aurait écrasé la production

Le déploiement automatique, déclenché à chaque envoi sur GitHub, aurait renvoyé tout le dossier du site sur la production, en pleine transition. Les correctifs urgents sont partis fichier par fichier. Depuis, le déploiement de production ne supprime jamais rien.

Des erreurs 500 que personne ne voyait

Des pages annexes hébergées à côté du site plantaient. La moindre erreur dans l’envoi d’un e-mail faisait tomber la page, et chaque visite déclenchait cet envoi avant d’afficher quoi que ce soit. Celles qui servent encore sont corrigées, et les autres répondent désormais « 410 Supprimé ».

Un taux fiscal périmé depuis près de deux ans

Ma page sur le Crédit d’Impôt Innovation annonçait un taux de 30 %. Pour les dépenses engagées depuis le 1er janvier 2025, il est de 20 %.

Aucun de ces problèmes ne se voyait dans le navigateur. Tous ont été trouvés parce qu’on les a cherchés.

Le résultat, en chiffres

	WordPress	Site statique
Temps de réponse du serveur	0,47 s	0,13 s
HTML de la page d’accueil	107 Ko	16 Ko
Taille du site sur le serveur	798 Mo	13 Mo

Les 798 Mo comprenaient 229 Mo pour une ancienne application, retirée depuis. Les polices sont désormais servies par le site lui-même : il n’y a plus aucun appel à Google Fonts.

Ce que j’en retiens

Claude Code a fait l’essentiel du travail : extraire les contenus, écrire les gabarits, les redirections, le déploiement et les contrôles. Ce qu’il ne pouvait pas faire seul, c’est décider : quoi garder, quoi supprimer, quand basculer, et quel risque accepter.

C’est exactement ce que je fais avec les vibe coders : ne pas freiner, mais poser les questions que l’IA ne pose pas.