Coder avec une IA sans perdre la main

Il y a deux façons de rater le virage des assistants de code. La première est de les ignorer et de taper à la main ce qu’une machine écrit mieux et plus vite. La seconde est de tout leur laisser et de ne plus savoir ce qui tourne en production. Entre les deux, il y a une pratique, et elle se construit.

Voici la mienne, telle qu’elle est aujourd’hui, après un an de projets livrés avec Claude Code dans l’éditeur.

Une boucle, pas une baguette

L’erreur la plus courante est de voir l’IA comme un générateur : on décrit, on reçoit, on colle. Ce n’est pas comme ça que ça marche bien. Ce qui marche, c’est une boucle courte où chaque étape a un responsable.

L’IA n’intervient qu’à une étape. Tout le reste, c’est du travail d’ingénierie classique, et c’est lui qui fait la qualité du résultat. Si le brief est flou, la génération est floue. Si la relecture est bâclée, les bugs passent. Si les tests n’existent pas, personne ne sait si la troisième itération a cassé la première.

Ce que je lui confie

Le code qui a déjà été écrit mille fois. Un formulaire avec validation, un composant de liste avec ses états, une fonction qui formate des dates en français, la configuration d’un module Nuxt. L’IA connaît ces motifs par cœur et les écrit sans faute de frappe. Je gagne vingt minutes par occurrence, et il y en a beaucoup dans une journée.

Les tâches larges et peu risquées. Renommer un composant dans tout le projet, extraire un composable, ajouter un type manquant, écrire les premiers tests d’un fichier. Ce sont des tâches où l’erreur se voit tout de suite.

La première version de quelque chose. Quand je ne sais pas encore à quoi va ressembler un écran, je lui demande trois propositions. Je n’en garde jamais une telle quelle, mais je choisis plus vite.

Les explications. Un code hérité que personne ne commente, une erreur de build incompréhensible, une API que je n’ai jamais utilisée. Demander « explique-moi ce fichier » avant de le modifier m’a évité pas mal de casse.

Ce que je garde

Les décisions. L’architecture, le découpage en composants, le choix d’une bibliothèque, ce qui va dans le state global et ce qui n’y va pas. L’IA peut argumenter, elle ne tranche pas. C’est moi qui porterai la décision dans six mois.

La relecture, ligne par ligne. Je ne fusionne rien que je n’ai pas lu. Pas survolé : lu. Si une ligne me paraît magique, je demande pourquoi elle est là, et si la réponse ne me convainc pas, elle saute. Un code que je ne comprends pas est un code que je ne pourrai pas corriger à deux heures du matin.

Tout ce qui touche à la sécurité et à l’argent. Authentification, paiement, droits d’accès, données personnelles. L’IA écrit ce code aussi bien qu’un autre, mais là, je vérifie deux fois plus, et j’écris les tests moi-même.

L’interface finale. Les détails qu’un humain remarque sans savoir les nommer, j’en parle dans un autre article. Ils ne viennent pas de la génération, ils viennent de la relecture avec les yeux de l’utilisateur.

Les règles que je me suis fixées

1. Un fichier de conventions à la racine du projet. Nom des composants, structure des dossiers, langue des commentaires, format des commits. L’assistant le lit à chaque session, et le code qu’il produit ressemble au mien. Sans ce fichier, chaque génération part dans une direction différente.
2. Une tâche à la fois. « Ajoute le champ téléphone au formulaire de contact, avec la validation et le test » est une tâche. « Améliore le formulaire » n’en est pas une. Plus la demande est bornée, plus la réponse est juste, et plus la relecture est rapide.
3. Les tests tournent avant que je regarde. Si la suite Cypress est rouge, je ne lis même pas le diff. Ça m’oblige à garder des tests fiables, et ça m’évite de perdre du temps sur un code qui ne marche pas.
4. Je relis dans l’éditeur, pas dans la conversation. Le diff dans Git, avec la coloration, le contexte autour, et la possibilité de lancer le projet. La conversation sert à discuter, pas à valider.
5. Je garde une trace de ce qui a été généré. Pas pour m’en excuser, mais parce que si un bug apparaît dans trois semaines, savoir qu’un bloc est sorti d’une génération rapide oriente la recherche.

Ce que ça change, concrètement

Je livre plus vite, c’est vrai, mais ce n’est pas le plus intéressant. Ce qui a changé, c’est où va mon attention. Moins de temps sur la syntaxe et la plomberie, plus de temps sur ce que l’utilisateur voit et ressent. Plus de temps aussi sur les tests, parce qu’ils sont devenus la vraie garantie, celle qui ne dépend pas de qui a écrit le code.

Et je comprends toujours ce que je livre. C’était la condition, et elle tient.