Contrôler le code généré avec Git, les diffs et les tests

TL;DR

L’IA peut produire du code très vite. Elle ne peut pas te dispenser de savoir ce qui a réellement changé, ce qui a été vérifié et ce que tu pourras réparer demain. Git, les diffs et les tests ne sont pas une bureaucratie ajoutée autour de l’agent : ce sont les outils qui te permettent de garder la main.

« C’est fait » n’est pas un compte rendu technique

Claude Code ou Codex peut terminer une tâche et te répondre que tout est prêt, que les tests passent et que le code respecte les conventions du projet.

Cette réponse est pratique. Elle n’est pas une preuve.

La preuve se trouve dans le dépôt : dans les fichiers qui ont changé, dans les dépendances qui ont été ajoutées, dans les commandes réellement exécutées et dans le comportement qui a été observé. C’est une différence importante, surtout lorsqu’on débute. Si tu ne regardes jamais le résultat concret, tu ne développes pas une capacité à vérifier. Tu développes une confiance dans le récit de l’agent.

Le problème n’est pas que l’agent puisse se tromper. Nous nous trompons tous en développant. Le problème, c’est de ne plus être capable de voir qu’il s’est trompé.

Notre mini-dashboard est un bon terrain pour comprendre cela. Imaginons que nous voulions ajouter une carte CPU. Une demande raisonnable devrait toucher le composant de métrique, les données de démonstration ou la récupération de l’API, et un test correspondant. Si une tâche aussi limitée modifie aussi la configuration de déploiement, ajoute trois dépendances et réorganise toute l’arborescence, ce n’est pas forcément faux. Mais c’est forcément une discussion à avoir avant d’accepter le changement.

Le diff est l’endroit où la promesse rencontre la réalité

Avant de laisser l’agent modifier quoi que ce soit, commence par savoir où tu te situes. Un git status te montre les fichiers déjà modifiés. Un git diff te montre le travail non validé. Ce réflexe évite une erreur très simple : attribuer à l’agent un changement que tu avais commencé la veille, ou écraser ton propre travail en revenant trop vite en arrière.

Ensuite, demande un plan avant le code. Pas un roman d’architecture. Un plan très concret : quels fichiers seront modifiés, pourquoi, quels tests seront ajoutés et quelles commandes permettront de vérifier le résultat. Ce plan crée une attente. Le diff final devient alors quelque chose que tu peux comparer à une intention, au lieu d’être un bloc de texte technique dont tu essaies de deviner la logique après coup.

Pour la carte CPU, ton échange peut être aussi simple que celui-ci :

Ne modifie encore aucun fichier.

Je veux ajouter uniquement l’affichage de la métrique CPU dans le mini-dashboard.
Indique les fichiers concernés, les comportements à couvrir, les éventuelles dépendances et les commandes de validation.
Si un changement dépasse cette tâche, explique pourquoi et attends ma validation.

Tu ne demandes pas à l’IA de devenir moins autonome. Tu lui imposes un périmètre vérifiable. C’est exactement ce qu’un développeur expérimenté attendrait d’une revue de tâche.

Quand le changement est prêt, ne commence pas par la partie la plus impressionnante du code. Commence par les noms de fichiers. Ils racontent souvent une histoire plus claire que le détail des lignes. Regarde ensuite package.json et le fichier de verrouillage : une carte d’affichage ne nécessite pas forcément une bibliothèque supplémentaire. Puis remonte vers les frontières du système, là où le code récupère une réponse externe, lit une variable d’environnement ou transforme une donnée. C’est à ces endroits que les erreurs deviennent rapidement coûteuses.

Enfin, lis le comportement nominal et les cas qui sortent du scénario idéal. Que se passe-t-il si l’API ne répond pas ? Si la valeur CPU vaut zéro ? Si elle est absente, négative ou supérieure à cent ? Un écran qui ne plante pas n’est pas automatiquement un écran qui dit la vérité.

Les petits changements rendent la compréhension possible

Un gros diff donne une illusion de vitesse. L’agent crée une API, quatre cartes, la gestion des erreurs, les tests, le responsive et une couche d’abstraction en une seule fois. Le résultat peut même fonctionner du premier coup.

Mais il devient très difficile à relire. Et lorsqu’un comportement est mauvais, tu ne sais plus où chercher ni quelle décision a introduit le problème.

Le bon rythme consiste à construire une première carte, à traiter son cas d’erreur, à vérifier son test, puis seulement à généraliser. C’est légèrement moins spectaculaire. C’est beaucoup plus formateur. Tu peux expliquer chaque étape, identifier le moment où une abstraction devient utile et revenir au dernier état sain si quelque chose casse.

Git n’est pas là uniquement pour sauvegarder des fichiers. Un commit bien découpé est une unité de raisonnement. Il doit raconter une modification que tu peux résumer sans raconter toute ta journée. Ajouter une carte CPU, protéger l’affichage d’une valeur invalide ou isoler une fonction de formatage sont trois décisions différentes. Les séparer te permet de les vérifier et de les remettre en question séparément.

Les tests ne servent pas à rassurer l’agent

Il existe une manière très trompeuse de travailler avec les tests : demander à l’agent d’en écrire quelques-uns à la fin, regarder qu’ils passent, puis considérer la fonctionnalité comme validée.

Un test qui passe prouve seulement que le programme s’est comporté comme ce test l’attendait. Il ne prouve pas que le test protège une situation utile.

Avant d’écrire le test de notre carte CPU, formule le comportement en français. Une valeur de 42 doit être affichée avec son unité. Zéro reste une valeur valide. Une donnée absente ne doit pas se déguiser en zéro. Une valeur impossible doit être traitée explicitement. Une erreur de récupération ne doit pas faire disparaître tout le dashboard.

À partir de là, l’IA peut devenir excellente. Elle peut proposer les cas manquants, challenger une assertion trop faible ou expliquer pourquoi un test dépend trop de la structure interne du composant. Mais la stratégie de test ne doit pas naître uniquement de ce qu’elle a déjà codé. Sinon, elle risque de vérifier sa propre implémentation au lieu de vérifier le besoin.

Un bon réflexe consiste à casser volontairement, pendant quelques secondes, le comportement que tu penses protéger. Si ton test reste vert lorsque la valeur CPU n’est plus affichée, il ne protège pas ce que tu crois. Tu rétablis ensuite le code correct, bien sûr. Mais tu viens d’obtenir une preuve plus solide que le simple message « tests passed ».

La documentation de Next.js sur les tests est utile ici : elle rappelle que les outils ne couvrent pas tous les mêmes niveaux de comportement. Un test unitaire, un test d’intégration et une vérification manuelle n’apportent pas la même information. Chercher l’outil parfait est moins utile que savoir précisément ce que tu cherches à vérifier.

Ce qui est vérifié doit être distingué de ce qui est supposé

À la fin d’une tâche, demande à l’agent de te dire exactement quelles commandes ont été exécutées, avec quel résultat, et ce qui n’a pas été vérifié. Le typage, le lint, les tests et le build donnent chacun une information différente. Si l’un d’eux n’a pas pu tourner, ce n’est pas un drame. Le cacher, en revanche, te prive d’une décision.

Cette exigence change beaucoup de choses dans une équipe. « Les tests devraient passer » n’a pas le même poids que « npm test a été exécuté et voici le résultat ». La première phrase est une intuition. La seconde est une observation.

Les permissions jouent le même rôle. Installer une dépendance, lancer une migration, accéder au réseau ou pousser du code ne sont pas des actions neutres. Tu n’as pas besoin de tout interdire à l’agent. Tu dois savoir à quel moment son action devient assez risquée pour demander une validation humaine. Les réglages évoluent, donc les documentations de Codex et de Claude Code restent les bonnes références pour leurs capacités actuelles.

La revue est une compétence qui s’apprend

Au début, lire un diff est fatigant. On a l’impression de perdre du temps face à un agent capable de produire dix fichiers en quelques minutes. Puis un jour, tu repères une dépendance inutile, une donnée transformée trop tôt, un test qui ne teste rien ou un changement hors périmètre avant qu’il ne devienne un bug en production.

À ce moment-là, tu comprends que la revue n’est pas une formalité. C’est une compétence de développeur. Et c’est aussi l’une des compétences qui rend l’IA réellement utile : tu peux aller plus vite parce que tu sais où regarder, quoi demander et quand dire non.

Dans le prochain article, on appliquera cette même logique au débogage. Pas pour demander à l’agent de faire disparaître une erreur, mais pour apprendre à remonter vers sa vraie cause.