De WordPress à un site statique assisté par l’IA : reconstruire sans perdre le passé

Mon ancien site WordPress avait rempli son rôle. Au fil des années, il avait accueilli articles, images et fragments de parcours professionnel. Mais entretenir un CMS avec base de données pour un site personnel commençait à ressembler à faire tourner un moteur pour éclairer une lampe de bureau.

Je voulais quelque chose de plus rapide, de plus simple à exploiter et de plus personnel. Je voulais aussi voir jusqu’où un partenaire de code IA pouvait m’aider : pas avec un bouton magique « convertir le site », mais en examinant avec moi les vrais choix techniques.

Le résultat est le site que vous lisez : un portfolio sur mesure, conçu pour le cloud et distribué en fichiers statiques via S3 et CloudFront. Les anciens textes restent accessibles ; photos, certifications, entraînements, jeux et récits de projets les complètent.

La réussite ne consistait pas à remplacer WordPress par l’IA, mais à séparer le contenu qui méritait d’être conservé de la mécanique devenue inutile.

D’abord, préciser ce que signifie « avec l’IA »

Le site en production n’a pas besoin de modèle de langage pour servir une page. Cela ajouterait latence, complexité et dépendance sans bénéfice pour les visiteurs. Le site est statique, et c’est un choix assumé.

L’IA a participé à la réalisation : examen des anciens contenus, proposition d’organisation, rédaction et révision, génération et refonte du code, détection d’incohérences, adaptation mobile et automatisation des tâches répétitives. Je suis resté responsable du produit : sélection des contenus, correction des hypothèses, appréciation du rendu et approbation des changements en production.

« Assisté par l’IA » est donc le terme juste. L’intelligence intervient pendant la construction et la maintenance ; le système livré reste simple.

1. Faire l’inventaire avant de refaire le design

Une migration commence par des faits, pas une palette de couleurs. Avant de toucher à la présentation, j’ai rassemblé articles, pages, catégories et références des médias WordPress. Le contenu a été exporté en JSON structuré et les fichiers associés conservés localement.

Deux filets de sécurité en sont sortis :

• des archives lisibles par les outils, transformables sans extraire continuellement le site public ;
• une médiathèque conservant les images, documents et certificats d’origine.

J’ai aussi revu les URL, titres, dates, liens internes et contenus à ne jamais publier par inadvertance. Une sauvegarde complète n’est pas un site public : elle peut contenir brouillons, fichiers obsolètes, données personnelles et identifiants. Conserver et publier sont deux décisions distinctes.

2. Détacher le contenu de WordPress

La vraie valeur de WordPress n’était ni son thème, ni ses extensions, ni son schéma de base de données, mais les contenus. Une fois les articles en JSON et les médias dans des dossiers ordinaires, la présentation devenait remplaçable.

Sur l’accueil, JavaScript lit les données éditoriales pour créer les cartes d’articles. Chaque texte dispose aussi d’une page HTML statique : souplesse des données structurées, URL normales et explorables, et accès direct pour les moteurs comme pour les lecteurs.

Préserver d’abord, sélectionner ensuite évite une erreur classique : jeter l’historique parce que le nouveau design ne lui prévoit pas de place. Les archives ont d’abord survécu ; les choix éditoriaux ont suivi.

3. Concevoir le site autour de la personne, pas du CMS

WordPress pousse naturellement vers une succession de billets. Il me fallait un autre centre de gravité : présentation, projets, parcours, certifications, photos, entraînement, articles techniques et un peu de détente.

Nous avons construit cette structure directement en HTML sémantique, CSS et JavaScript. Pas de thème généraliste censé convenir à des milliers de sites. Navigation, typographie, menu mobile, cadrage des images et interactions sont conçus pour ce portfolio.

Le design s’est affiné par itérations. Sur l’aperçu local, je pouvais signaler un terminal devant mon bras, un portrait trop coupé ou un titre mal réparti, puis corriger immédiatement. L’IA est particulièrement utile dans cette boucle courte : le jugement visuel reste humain, sa traduction en CSS est plus rapide.

4. Traiter les anciennes URL et le référencement comme des données de production

Un bel accueil ne suffit pas si des années de contenus disparaissent des recherches. Chaque article sélectionné a reçu une URL autonome, un titre descriptif, une description et une adresse canonique, ainsi que des métadonnées Open Graph et Twitter et des données structurées Schema.org l’identifiant comme article technique dont je suis l’auteur.

Le sitemap répertorie les pages principales et les archives. Mon nom apparaît de manière cohérente, « Bernd Kuhlen », avec « Bernhard Kuhlen » comme variante. Les robots disposent de consignes explicites, et les liens ordinaires restent utilisables sans exécuter l’accueil interactif.

Un ancien permalien connu des moteurs ou cité ailleurs doit rester valide ou rediriger définitivement vers son remplaçant. La correspondance des URL appartient au plan de migration, pas au nettoyage après lancement.

5. Une infrastructure sans surprises, au bon sens du terme

Les fichiers sont stockés dans un bucket S3 privé, chiffré et versionné. CloudFront constitue l’entrée publique et accède au bucket par Origin Access Control : le stockage n’est pas exposé directement. HTTPS est imposé, TLS moderne requis et une politique ajoute les principaux en-têtes de sécurité du navigateur.

L’infrastructure est décrite dans CloudFormation, pas seulement assemblée à la souris dans la console AWS. À l’époque décrite ici, le script mettait à jour la stack, synchronisait une liste explicite de fichiers publics et invalidait le cache CloudFront. La livraison était ainsi reproductible et les changements révisables.

L’hébergement statique retire du chemin des requêtes la base WordPress, PHP, les mises à jour de thème et les correctifs d’extensions. La responsabilité d’exploitation demeure, mais sur un problème plus petit et plus observable.

6. Prévisualiser, puis basculer

Pendant le travail, le site tournait localement dans un conteneur derrière Nginx. On pouvait vérifier les écrans d’ordinateur et de téléphone, ouvrir les archives, jouer et examiner les graphiques avant la mise en production.

Une bascule prudente prévoit :

1. un gel du contenu ou un export final clairement défini ;
2. une sauvegarde complète de la base et des médias ;
3. la validation locale et en préproduction des URL importantes ;
4. les enregistrements DNS et certificats prêts avant le changement ;
5. un retour possible vers l’origine précédente ;
6. des contrôles après mise en ligne depuis l’extérieur du poste de développement.

Le versionnement S3 et l’infrastructure as code facilitent la reprise, mais ne remplacent pas une procédure de retour arrière réfléchie.

7. Ajouter de l’observabilité après avoir supprimé le serveur applicatif

Un site statique peut tomber en panne, attirer des robots ou recevoir un trafic inattendu. Les logs CloudFront enregistrent requêtes, statuts, user-agents et points de présence. Ils alimentent un tableau CloudWatch avec volumes et familles HTTP, et une rétention définie plutôt qu’une accumulation sans fin.

Les vues géographiques indiquent l’origine apparente du trafic, mais un point de présence ou une localisation déduite d’une IP ne prouve jamais l’identité d’une personne. Les données opérationnelles parlent des requêtes, rarement de l’identité.

Cela fournit aussi une référence utile. Au lieu d’attendre un signalement de lien cassé, je peux voir les tendances d’erreurs et les chemins demandés.

8. Profiter de la migration pour sortir du cadre WordPress

Libéré du thème de blog classique, le site pouvait mieux refléter mes intérêts. Les exports Apple Health sont devenus des vues agrégées quotidiennes, hebdomadaires et mensuelles. Les certificats ont leur archive dédiée, les photos leurs légendes et Snake et Galaga leur place dans Détente.

Tout reste distribué en fichiers statiques et code client. Le changement n’est pas une plateforme plus lourde, mais une structure où cohabitent de petites fonctionnalités ciblées.

Ce que l’IA a bien fait, et ce qui demandait une supervision

L’IA s’est montrée efficace pour les vérifications répétitives, les transformations, les premières implémentations, les formulations et l’application de retours détaillés à plusieurs fichiers. Elle pouvait suivre les liens entre données d’article, page, sitemap et ensemble à déployer.

La vérification restait indispensable. Un lien plausible peut être faux. Une mise en page valide peut mal fonctionner sur un téléphone réel. Un texte généré peut être générique ou promettre plus que le système. Et les commandes d’infrastructure peuvent avoir des conséquences autrement plus larges qu’une faute de frappe.

Le processus le plus productif était conversationnel mais rigoureux : observer le système réel, apporter un changement borné, prévisualiser, tester, puis publier. L’IA accélère cette boucle ; elle ne la supprime pas.

Une liste de contrôle reproductible

1. Sauvegarder la base, les fichiers et la configuration WordPress.
2. Exporter articles, pages, taxonomies, dates, auteurs et références des médias.
3. Classer les contenus : publics, privés, obsolètes ou incertains.
4. Inventorier les URL et préparer les redirections.
5. Choisir l’architecture la plus simple répondant aux besoins réels.
6. Créer un petit système de design et des modèles réutilisables.
7. Générer des pages autonomes et sémantiques pour les contenus à référencer.
8. Ajouter métadonnées, URL canoniques, données structurées, règles robots et sitemap.
9. Tester l’accessibilité, les mises en page adaptatives, les liens, les documents et les pages d’erreur.
10. Décrire l’infrastructure et le déploiement en code.
11. Basculer avec sauvegardes, supervision et retour arrière testé.
12. Conserver les archives jusqu’à ce que le nouveau site ait fait ses preuves.

Le compromis

Un site statique n’est pas toujours le bon remplaçant de WordPress. Une rédaction avec de nombreux contributeurs non techniques, des circuits complexes, des commentaires ou des données serveur très changeantes peut encore tirer parti d’un CMS mature, éventuellement découplé d’un frontend statique.

Pour un portfolio personnel maintenu en code, l’équilibre diffère. J’ai échangé le confort de la rédaction dans un navigateur contre une surface d’attaque réduite, une diffusion prévisible, des changements versionnés et la maîtrise de l’expérience. L’IA a suffisamment réduit les frictions de ce travail en code pour rendre le choix intéressant.

Ce qu’il faut retenir

L’ancien WordPress n’a pas été jeté. Il a été démonté avec soin : contenus préservés, éléments utiles mis en valeur, présentation reconstruite et infrastructure simplifiée.

C’est cette leçon que je retiens. Ne commencez pas par chercher quel produit IA doit remplacer WordPress. Demandez d’abord ce qui doit survivre, ce que le site doit vraiment faire et quelle complexité retirer. Utilisez ensuite l’IA comme partenaire technique : curieux, rapide et utile, mais toujours confronté à de vrais fichiers, de vrais tests et au jugement humain.