Garder son code maintenable quand l'IA l'a écrit

Mille lignes en trois minutes, ça procure un vrai vertige — et c'est mérité, c'est l'un des super-pouvoirs de coder avec l'IA. La facture arrive plus tard : six mois après, un bug surgit dans du code que personne n'a jamais vraiment lu, l'IA qui l'a écrit n'en a plus aucun souvenir, et tu as peut-être changé de modèle entre-temps. La solution n'est pas d'écrire moins de code IA. C'est de le rendre lisible au moment où il naît — et, bonne surprise, le code lisible est aussi le plus rapide à faire évoluer.

Le vrai coût n'est pas d'écrire, c'est de comprendre

Générer est devenu gratuit ; comprendre, non. Et c'est là tout le piège : tu paies la lisibilité plus tard, au pire moment, quand il faut modifier quelque chose que tu n'as jamais lu.

Rappelle-toi comment l'IA fonctionne : à chaque session, elle repart sans mémoire de ce qu'elle a écrit avant. Dans six mois, ton code sera la seule trace de comment ton app marche — ni l'IA ni toi n'aurez l'historique en tête. Si ce code est clair, n'importe quel modèle (ou ton toi futur) le reprend en cinq minutes. S'il est illisible, tout le monde rame, l'humain comme la machine.

C'est pour ça que la lisibilité n'a rien d'un devoir moral : c'est de l'intérêt bien compris. Un fichier de mille lignes emmêlées, ça sature la fenêtre de contexte, ça embrouille le modèle, ça déclenche les boucles sans fin. Du code propre, l'IA le navigue, change la bonne chose, casse moins. Maintenable, ce n'est pas le contraire de rapide — c'est ce qui garde la vitesse.

Une structure et des noms que tu peux suivre

Deux leviers coûtent presque rien et rapportent énormément : où vivent les choses, et comment elles s'appellent.

La structure. Une responsabilité par fichier, des dossiers prévisibles. Le test tout simple : « où un nouveau venu chercherait-il ça ? » — et c'est là que ça doit être. Or l'IA a un réflexe : tout déverser dans le fichier qu'elle a déjà sous les yeux. Sans toi pour rediriger, un composant finit par faire dix choses. Quand un fichier enfle, demande de le découper par responsabilité. Bonus : l'IA n'a alors qu'à charger le fichier utile, pas tout le bazar — moins cher, plus juste.

Les noms. C'est la documentation la moins chère du monde. calculerTotalMensuel te dit ce que fait la fonction sans lire son corps ; calc, handleData ou temp2, non. La moitié du « code illisible » n'est que du mauvais nommage. L'IA nomme très bien quand on la laisse faire — mais elle accepte aussi tes noms vagues sans broncher. Dès que tu vois data, info ou truc2, renomme (ou demande-le). Petites règles, gros effet : un booléen dit ce qui est vrai (estEnChargement), une fonction est un verbe, une collection est au pluriel.

Des petites fonctions, des commentaires qui servent

Une fonction, un boulot. Si tu peux la lire de haut en bas sans scroller et résumer ce qu'elle fait en une phrase, elle est saine. Si tu n'y arrives pas, elle en fait trop — demande à l'IA de la couper. Les fonctions de trois cents lignes, c'est là que les bugs se planquent et que le modèle se perd. En prime, des petits morceaux sont testables et un bug y reste localisé au lieu de s'étaler partout.

Les commentaires. Voici la nuance que connaissent les pros : un bon commentaire explique le pourquoi, pas le quoi. Le code dit déjà ce qu'il fait ; un commentaire gagne sa place en capturant la raison ou le piège (« on réessaie deux fois, l'API de paiement est capricieuse »). L'IA, elle, adore sur-commenter — un // incrémente i au-dessus d'un i++, c'est du bruit, et pire : quand le code change, ces commentaires-là mentent. Demande-lui de commenter l'intention et les pièges, pas l'évidence. Moins de commentaires, mais des vrais.

La dette technique : un prêt, pas un péché

Déculpabilisons : la dette technique n'est pas une faute, c'est un emprunt. Il t'arrive d'en prendre exprès — livrer le proto maintenant, nettoyer après —, et c'est parfaitement légitime tant que c'est un choix visible. Le vrai problème, c'est la dette accidentelle que personne n'a décidée et que personne ne voit.

Donc rends-la visible : une petite liste des raccourcis assumés (un // TODO: dans le code, un fichier TODO.md), pour que ton toi futur — ou l'IA — tombe dessus. Nommer la dette, c'est déjà à moitié la gérer.

Et pour la rembourser, oublie le grand « week-end de réécriture » qui n'arrive jamais : nettoie en passant, la fonction que tu touches aujourd'hui. Bonne nouvelle, l'IA est un excellent outil de refactoring — pointe-la sur un fichier brouillon, demande-lui de le clarifier sans changer le comportement, et fais tourner les tests pour le prouver. Rendre du code propre n'a jamais été aussi peu cher.

Le réflexe qui change tout : exige la lisibilité d'emblée

Tout ça devient automatique si tu n'as pas à le réclamer à chaque fois. Mets tes conventions dans un fichier de règles (CLAUDE.md, .cursor/rules) : « petites fonctions, noms explicites, une responsabilité par fichier, commenter le pourquoi ». L'IA génère alors du code lisible par défaut, et tu cesses de jouer au gendarme.

Reste le geste le plus important, et le seul que tu gardes pour toi : lis ce qui sort. Pas chaque ligne — assez pour garder une carte mentale de ton app. Le jour où tu ne comprends plus ton propre code, tu en as perdu le contrôle. Et tu le récupères non pas en lisant mille lignes d'un coup, mais en demandant à l'IA de t'expliquer un fichier, et en gardant le code assez simple pour se survoler. Tu restes l'architecte ; l'IA est la paire de mains rapide.

En résumé

Le code que l'IA génère, c'est ton code — autant qu'il soit lisible, parce que c'est toi (et le prochain modèle) qui le reprendrez. Structure claire, noms explicites, petites fonctions, commentaires qui disent le pourquoi, et une dette qu'on assume au lieu de la subir : rien de moralisateur là-dedans, juste ce qui garde ton app — et ton vibecoding — rapides dans la durée. Coder pour ton toi de dans six mois : c'est exactement ça, vibecoder comme un pro.