J’ai refait mon site avec une IA qui code : ce qu’elle fait bien, ce que j’ai dû vérifier

Ce carnet a été construit avec l’IA. Pas en lui demandant « fais-moi un site », mais en lui confiant le code, étape par étape, pendant que je gardais la main sur les choix et les vérifications.

Le premier article posait une règle : l’IA propose, l’humain décide. Cette refonte a été l’occasion de la mettre à l’épreuve sur un vrai projet, le mien. Voici ce que l’IA a très bien fait, et ce que j’ai dû rattraper.

Trois rôles, un seul qui signe

J’ai travaillé avec deux outils d’IA, chacun dans son rôle :

Qui	Fait quoi
Un assistant conversationnel (Claude)	Cadrer le besoin, découper le travail en étapes, rédiger les consignes, relire le code et les captures d’écran
Un éditeur de code IA (TRAE)	Écrire le code, lancer les tests, rendre un compte rendu
Moi	Choisir, tester, valider, commiter, mettre en ligne

Le site tourne sous Django. La refonte s’est faite en une série d’étapes courtes, chacune sur sa propre branche Git, avec une consigne, un compte rendu et une relecture avant de passer à la suivante.

Ce que l’IA fait très bien

Il faut le dire franchement : sur l’écriture du code, le gain de temps est énorme.

Elle tient la cadence. Un modèle de données, une interface d’administration, un rendu Markdown sécurisé, une feuille de style complète : chaque étape prenait quelques minutes à écrire, là où il m’aurait fallu des soirées.
Elle écrit les tests. Le projet compte aujourd’hui plus d’une centaine de tests automatiques, que je n’aurais sans doute pas tous écrits seul.
Elle documente si on le lui demande. Chaque étape mettait à jour un fichier de documentation du projet.
Elle ne se lasse pas. Reprendre dix fichiers pour renommer une classe CSS ou corriger un détail d’accessibilité ne lui coûte rien.

Quand le compte rendu dit « tout est bon »

À la fin de chaque étape, l’éditeur rendait un compte rendu soigné : fichiers modifiés, tests passés, aucun problème. Plusieurs fois, ce compte rendu était sincère… et faux.

Un compte rendu n’est pas une preuve.

Quelques exemples réels :

Des fichiers invisibles pour Git. Les nouvelles feuilles de style étaient bien créées, mais une ligne trop large du .gitignore les excluait du dépôt. Tout fonctionnait sur mon poste. En production, le site serait arrivé sans aucune mise en forme.
Des titres décalés d’un niveau. Un ## Section devenait un titre de niveau 3. Rien de cassé en apparence, mais le sommaire automatique, qui attend des titres de niveau 2, ne se serait jamais affiché.
Des pages sans style. Lors d’une étape, les nouvelles pages ont été créées avec leur structure HTML, mais sans le CSS qui allait avec. Les tests passaient : ils vérifiaient que les pages répondaient, pas qu’elles ressemblaient à la maquette.
Une mesure faussée. Les captures censées vérifier l’affichage mobile faisaient 375 pixels de large au lieu de 390 : la barre de défilement avait mangé la différence, et le contrôle des débordements avec.

Aucune de ces erreurs n’aurait été détectée par les tests automatiques. Elles l’ont été en lisant le code modifié, et surtout en regardant les pages réelles, à plusieurs largeurs d’écran et en mode sombre. C’est comme ça qu’on a aussi trouvé une carte d’article affichée deux fois et une image d’accueil démesurée.

Ce que l’IA ne décide pas : l’identité

La première version de la refonte était propre, cohérente, bien codée. Et je l’ai trouvée banale : elle ressemblait à n’importe quel site du même genre.

L’IA produit volontiers la moyenne de ce qu’elle a déjà vu. C’est une qualité pour du code, beaucoup moins pour une identité. La direction actuelle, « l’établi », est partie de mon métier et de ce que je voulais montrer : un esprit curieux qui construit. L’IA a ensuite aidé à la mettre en forme, mais l’idée devait venir de moi.

Mes règles pour coder avec une IA

Au fil des étapes, une méthode s’est installée. La voici :

Boucle de travail : consigne, code, compte rendu, vérification, puis commit. Un écart trouvé à la vérification renvoie à une nouvelle consigne.

Découper en petites étapes, une branche Git par étape. Une erreur se corrige facilement quand elle ne touche que quelques fichiers.
Écrire des consignes précises : le périmètre, ce qu’il ne faut pas toucher, et des critères de réussite vérifiables.
Vérifier soi-même : relire les fichiers réellement modifiés, relancer les tests, et regarder le rendu réel sur ordinateur, sur mobile et en mode sombre.
Protéger les secrets : aucune valeur du fichier de configuration ne doit apparaître dans un compte rendu ou une capture.
Garder la main sur le commit et la mise en ligne. C’est le moment où l’on signe.

Une consigne type ressemble à ceci :

Étape 8 bis : finitions, commit et fusion.
Toujours env\Scripts\python.exe, branche notes-marge.
Dans ton compte rendu, n'affiche jamais le chemin de l'admin
ni aucune valeur du .env.

1. Ce qui change, fichier par fichier.
2. Ce qu'il ne faut pas toucher.
3. Vérifications : check, makemigrations --check, test,
   captures à 1440, 1280 et 390 px.
4. Ne pousse pas. Renvoie-moi le résultat des tests.

Rien de magique : c’est un ordre de travail, comme on en rédige pour une intervention sur site.

Les trois règles, encore

On retrouve les trois mots du premier article, appliqués cette fois à du code écrit par une machine :

Sécurisé : le contenu des articles est nettoyé avant affichage, les secrets restent hors du code, et chaque changement sensible est relu.
Documenté : chaque étape a sa consigne, son compte rendu et sa trace dans l’historique Git.
Maintenable : du Django standard, des versions de bibliothèques figées, et un code que je comprends, parce que je l’ai relu.

L’IA m’a fait gagner un temps considérable. Elle ne m’a dispensé d’aucune vérification.

Et vous, laissez-vous l’IA écrire votre code ? Qu’est-ce que vous vérifiez systématiquement ?