2 787 commits en 5 mois : comment j’ai développé le nouveau BlogNT avec l’IA, de Codex à Claude Code

Le projet ne part pas d’une page blanche. BlogNT tournait sur un thème acheté sur ThemeForest des années plus tôt, enrichi au fil du temps de réglages, de surcouches et de correctifs. Un héritage qui fonctionne, mais qu’on n’ose plus toucher.

WordPress offre une échappatoire pour ces cas-là : le thème enfant, une couche où l’on peut modifier sans altérer l’original. C’est l’approche la plus prudente, et c’est celle par laquelle tout a commencé.

La période Codex : dix jours, 78 commits

Le dépôt en a gardé les traces sous forme de branches : refonte-codex, puis refonte-codex-2. En une dizaine de jours, 78 commits et environ 22 000 lignes ajoutées.

Deux fusions marquent la période. Le 30 mars, une refonte visuelle ajoute 625 lignes de style et retouche les gabarits d’article. Le 2 avril, une seconde passe autrement plus large : 2 068 lignes de style supplémentaires et une page de recherche entièrement réécrite, 235 lignes.

Sur ce terrain, Codex tenait très bien la route. Une demande identifiée, un périmètre clair, un résultat visible immédiatement : le compte y était. Il serait injuste de raconter cette période comme un échec — elle a produit du code qui a servi.

Le basculement vers Claude Code n’a pas été motivé par la vitesse, ni par le volume produit. Il l’a été par la qualité de ce qui restait après.

Un thème WordPress n’est pas une collection de correctifs indépendants, c’est un système. Une règle de style ajoutée dans un coin casse un affichage à l’autre bout. Une convention de nommage tenue à 90 % ne sert plus à rien, parce qu’on ne peut plus s’y fier. Et le code mort s’accumule, parce que personne ne sait plus s’il est encore lu par quelque chose.

Le vrai coût d’un développement assisté ne se mesure donc pas au code écrit. Il se mesure à la dette qu’on ne crée pas.

Trois exemples concrets

Le 14 mai : 3 031 déclarations !important supprimées en une passe. Pour les non-développeurs, !important est l’instruction qui dit « applique cette règle, quoi qu’il arrive ». C’est utile une fois, ingérable trois mille fois : le style devient un empilement de passages en force où plus rien n’est prévisible. Les enlever sans rien casser demande de comprendre pourquoi chacune était là.

Des purges qui vont chercher l’invisible. 67,6 Ko d’options chargées à chaque page par l’ancien thème, et qui ne servaient plus. Un paquet de production allégé de 7,2 Mo de fichiers d’audit qui n’avaient rien à y faire. Des clés d’API sorties du chargement automatique — autrement dit, un secret qui traînait là où il ne fallait pas.

Et, surtout : des décisions de ne rien changer. C’est le point le plus contre-intuitif. Un commit du 1^er septembre retire sept variables inutilisées et
documente la huitième au lieu de l’effacer, parce qu’elle avait une raison d’être. Un autre conclut qu’une famille de couleurs jugée suspecte est en réalité conforme : dossier clos, on n’y touche pas. Un outil qui ne sait que produire du code ne s’arrête jamais là.

La conséquence de ce changement de méthode, c’est que le projet a cessé de rapiécer pour commencer à découpler. Deux dates comptent :

• 14 mai — les métadonnées héritées du vieux thème (préfixées innovation_ruby_) sont renommées et détachées. Des dizaines de milliers de lignes en base à migrer sans rien perdre.
• 17 mai — le thème enfant devient un thème autonome et prend son nom : blognt-media.

Résumé en une phrase : Codex a amélioré le thème existant, la suite l’a remplacé.

Ce que disent les chiffres

Le pic se situe en juin : 1 169 commits dans le seul mois. Aujourd’hui, le thème compte plus de 1 400 fichiers PHP, une centaine de feuilles de style et soixante scripts, organisés autour d’un design system et de 19 formats éditoriaux.

Détail que je trouve parlant : le dépôt garde la trace du modèle utilisé pour chaque commit. Sonnet 4.6 en a signé 1 145, Opus 4.8 environ un millier, puis Opus 5, Fable 5 et quelques autres. Le projet a traversé plusieurs générations de modèles sans changer de méthode — ce qui en dit peut-être plus long sur la méthode que sur les modèles.

Le code n’était pas le seul chantier. Le site changeait aussi de nom — BlogNT devient BlogNT Media — ce qui supposait un logo, une signature, et un système capable de se décliner en BlogNT Podcast ou BlogNT Vidéo sans repartir de zéro.

Cette partie a été menée avec Claude Design, et l’exercice n’a rien à voir avec le développement. Écrire du code, c’est converger vers une solution qui marche ou ne marche pas. Dessiner une identité, c’est explorer un espace où plusieurs réponses sont défendables, et où le critère de réussite ne se teste pas : il se juge.

Ce que j’en retiens tient en une observation : l’IA est bien meilleure quand on lui donne une contrainte que quand on lui demande une idée. « Propose-moi un logo » produit du générique. « La séparation entre BlogNT et Media doit être une tranche diagonale, dessinée et non typographique, à une pente reproductible » produit un système.

Le résultat est d’ailleurs plus un système qu’un dessin. La tranche est un tracé à 18,43°, une pente de 1:3 — un rapport simple, donc reproductible à toutes les tailles, et jamais le glyphe «  » d’une police, qui varierait d’une fonte à l’autre. Dans l’icône, cette même inclinaison découpe réellement la tuile, au lieu d’être un trait posé par-dessus.

On retrouve la même logique dans le détail du fichier. Le bleu du wordmark est un dégradé à quatre arrêts plutôt qu’un aplat, le mot MEDIA est composé en capitales espacées d’un cinquième de cadratin pour former une bande sous le nom, et le bleu de marque est fixé à une valeur unique dont tout le reste du site dérive. Rien de spectaculaire pris isolément ; c’est l’ensemble qui tient.

Et la déclinaison a été pensée avant d’être nécessaire. Le code du thème contient cette règle : une verticale, une couleur dédiée. La couleur de BlogNT Podcast y est déjà réservée, alors que le podcast n’a pas encore son espace. C’est typiquement le genre de décision qu’un outil ne prend pas tout seul : il faut avoir en tête où l’on va.

L’iceberg : ce qui ne s’affiche jamais

Un chiffre m’a surpris en préparant cet article. À côté du thème lui-même, le projet a produit 25 scripts d’outillage, 24 scripts de migration et 38 documents internes. Rien de tout cela n’atteint le visiteur. C’est pourtant là qu’est passée une part considérable du travail.

Quelques exemples de ce que contient cette caisse à outils : un orchestrateur qui enchaîne les quatorze étapes de la bascule dans le bon ordre de dépendances, avec simulation par défaut et arrêt automatique si une étape critique échoue ; des scripts qui reconstruisent les feuilles de style optimisées ; un vérificateur de redirections ; un comparateur entre l’état local et l’état de production.

Cette infrastructure est la vraie différence entre « du code produit par une IA » et « un projet mené avec une IA ». Sans elle, on accumule des modifications qu’on ne sait plus vérifier.

Une douzaine d’audits complets ont été menés au fil des mois — sécurité, accessibilité, performance, code mort — avec une note et un suivi des points bloquants. Celui du 29 juin conclut à environ 86/100 et zéro problème critique. Les suivants ont continué de creuser.

L’accessibilité en particulier a fait l’objet d’une campagne à part entière, pas d’un rattrapage de dernière minute : contrastes repris page par page, neuf échecs corrigés sur les seuls en-têtes de recherche et d’auteur, une échelle de couleurs entière dotée d’un plancher garantissant la lisibilité, et les nuances volontairement plus discrètes explicitement annotées comme telles.

Ce dernier point résume assez bien la méthode : distinguer ce qui est un défaut de ce qui est un choix, et écrire la différence quelque part. Un audit qui signale tout ne sert à rien ; un audit qui explique pourquoi il ne signale pas quelque chose, si.

La répétition générale

Le passage en production ne s’est pas fait à l’aveugle. Une copie complète du site réel — 52 740 articles, la vraie base de données — a été montée pour y jouer la bascule entière avant de toucher au site en ligne.

Cette répétition a coûté une nuit de machine. Elle a rapporté cinq défauts qui seraient tous apparus le jour J, dont deux méritent d’être racontés :

• La procédure de retour arrière désignait le mauvais thème. Elle nommait le thème parent alors que le site tourne sur son thème enfant : en cas de problème, le « retour à l’état d’avant » aurait ajouté une panne à la panne, au pire moment.
• La migration prenait trois heures, parce qu’une étape relançait WordPress entièrement pour chaque article — cinquante-deux mille fois. Réécrite, elle prend six minutes. La même opération, le même résultat, vérifié identique ligne à ligne.

Aucun de ces deux problèmes n’était visible en lisant le code. Il a fallu l’exécuter pour de vrai, sur des données réelles.

Il serait malhonnête de s’arrêter au bilan flatteur. Trois choses ne se sont jamais déléguées.

Les décisions. Quels formats éditoriaux créer, quelle identité visuelle adopter, quelles fonctionnalités abandonner en cours de route, quel compromis accepter entre personnalisation et vie privée : rien de tout cela ne se sous-traite. Un outil propose ; il ne sait pas ce que doit être un site.

La vérification. C’est là qu’est passé l’essentiel du travail utile, et il consiste à exiger des preuves plutôt que des affirmations. Deux exemples récents, tous deux découverts avant la mise en ligne :

• Un garde-fou censé bloquer la migration en cas de problème s’est révélé incapable de mesurer ce qu’il prétendait surveiller : il cherchait une information dans la base de données, alors qu’elle vivait dans des fichiers. Il n’a été démasqué qu’en le testant dans les deux sens — vérifier qu’une alarme se déclenche ne suffit pas, il faut vérifier qu’elle s’éteint.
• Pour fermer le site pendant la bascule, la commande évidente aurait suffi… pendant dix minutes. Le code de WordPress considère en effet la maintenance terminée passé ce délai. Sur une opération d’une heure trente, le site serait revenu en ligne tout seul, en plein milieu. Ça ne s’invente pas : ça se lit dans le code source, et ça se vérifie sur un banc d’essai.

La responsabilité. Ce qui s’affiche sur BlogNT est publié sous mon nom. Une régression reste ma régression, et « c’est l’IA qui l’a écrit » n’est pas une excuse recevable pour un lecteur qui tombe sur une page cassée.

Ce que j’en retire

L’assistance par IA n’a pas remplacé le développement : elle a déplacé l’effort. Moins de temps passé à écrire des lignes, beaucoup plus à définir ce qu’on veut, à relire, et à réclamer des démonstrations plutôt que des assurances.

La question utile n’est plus « est-ce que ça marche ? » mais « qu’est-ce qui prouve que ça marche ? ». C’est une compétence différente de celle d’écrire du code, et pour tout dire plus exigeante.

Le résultat est en ligne depuis aujourd’hui. Le détail des nouveautés est ici — et si vous trouvez un défaut, il est très probablement de mon fait plutôt que de celui d’une machine.