Quitter un site builder pour reprendre la maîtrise : comment j’ai refait xavier-barry.fr avec l’IA
Au départ, la décision était presque banale : mon abonnement de deux ans chez Hostinger arrivait à son terme et je n’obtenais pas de remise intéressante pour le renouveler. Plutôt que de payer pour continuer avec un builder qui ne me donnait plus beaucoup de marge de manœuvre, j’ai décidé de repartir de zéro.
Le déclencheur était économique, la vraie motivation était ailleurs
Pendant deux ans, le builder Hostinger avait rempli son rôle : mettre en ligne rapidement un site propre sans passer trop de temps sur la technique.
Mais au moment du renouvellement, l’équation a changé. Je pouvais simplement reconduire l’abonnement. J’ai préféré utiliser cette contrainte comme prétexte pour reprendre la maîtrise du site : son code, son hébergement, son SEO, ses langues, sa performance et son processus de déploiement.
Ce choix n’aurait probablement pas été le même quelques années plus tôt. Refaire un site complet, même statique, signifie gérer beaucoup de détails : structure des pages, composants, responsive, redirections, métadonnées, sitemap, hreflang, assets, contenu multilingue et déploiement.
L’IA a changé le coût de cette décision.
Être hands-on ne signifie plus forcément écrire chaque ligne
Je n’avais aucune envie de redevenir le développeur principal de mon propre site. Ce n’est ni là que j’apporte le plus de valeur, ni là que je veux passer mon temps.
En revanche, j’avais envie de revenir au plus près de la chaîne de production : comprendre les choix, définir l’architecture, découper le travail, relire les changements, imposer des garde-fous, contrôler les previews et décider ce qui part en production.
C’est là que l’IA est devenue intéressante pour moi. Elle ne remplace pas le jugement technique. Elle permet de déplacer l’effort : moins de temps à produire chaque ligne, davantage de temps à exprimer précisément l’intention et à contrôler le système qui la transforme en logiciel.
Une stack volontairement simple
Le nouveau site repose sur une architecture beaucoup plus sobre que le précédent : Astro pour générer un site statique, GitHub comme source de vérité, Netlify pour les previews et le déploiement.
Je voulais limiter le nombre de briques et garder une chaîne compréhensible. Pas de CMS, pas de backend, pas d’infrastructure surdimensionnée.
La difficulté n’était pas de choisir une stack exotique. Elle était de préserver tout ce qui compte lorsque l’on migre un site existant : les URLs, le référencement, les contenus, les versions française, anglaise et espagnole, les canonicals, le sitemap et les performances.
L’IA devient utile quand le process devient explicite
Au fil de la migration, j’ai progressivement formalisé une manière de travailler avec les assistants et agents.
Je garde la responsabilité du cadrage et du contenu. Les agents peuvent analyser le repo, proposer une implémentation, modifier les fichiers et lancer les validations. Mais leur travail est borné par des règles : une branche dédiée, une cible de staging, des invariants documentés, une checklist de non-régression et une validation humaine avant le merge.
Cette discipline peut sembler disproportionnée pour un site personnel. C’est justement ce qui m’intéresse : si le processus reste fiable sur un petit projet, il devient un excellent laboratoire pour comprendre comment intégrer l’IA dans une chaîne de production plus large.
Points de contrôle à conserver :
- une branche de travail issue du staging, jamais directement de la production ;
- une spécification écrite avant les changements importants ;
- des tests automatiques sur les routes, l’i18n et le build ;
- une preview avant merge ;
- une séparation claire entre génération et validation.
Le principal enseignement n’est pas « l’IA code vite »
Ce projet m’a surtout rappelé qu’un agent peut accélérer aussi bien une bonne décision qu’une mauvaise.
Si l’architecture est floue, si les règles de routing ne sont pas explicites ou si le contenu n’a pas de source de vérité, l’IA produit plus vite de l’incohérence.
À l’inverse, quand les contraintes sont documentées et que le feedback est rapide, elle devient un multiplicateur de capacité très concret.
C’est ce qui m’intéresse aujourd’hui dans l’engineering augmenté par l’IA : pas la démonstration spectaculaire d’un prompt qui génère un écran, mais la capacité à construire un système de production où la vitesse supplémentaire ne détruit ni la qualité ni la maîtrise.
Ce que ce site représente pour moi
xavier-barry.fr est évidemment ma vitrine professionnelle. Mais il est devenu aussi un petit laboratoire permanent.
J’y teste de nouvelles manières de travailler avec ChatGPT et Codex, de structurer les handoffs entre humains et agents, de documenter les invariants et d’automatiser les contrôles qui évitent de répéter les mêmes erreurs.
Je ne cherche pas à redevenir développeur grâce à l’IA. Je cherche à rester un CTO / CTPO capable de comprendre très concrètement comment la façon de construire du logiciel est en train de changer.
Découvrir mon approche de l’IA appliquée et de l’engineering augmenté