# Comment réviser du code écrit par un agent d’IA?

Date: 2026-05-13 · Author: Robert Scales · https://guidetoartificialintelligence.com/fr/apprendre/reviser-code-ecrit-par-agent-ia/

**Answer:** Révisez-le comme une demande de fusion venue d’un nouveau venu rapide et sûr de lui : vérifiez d’abord la portée de ce qui a changé, puis si les tests sont réels et passent encore sur votre machine, ensuite cherchez les secrets et les nouvelles dépendances, et seulement après, lisez la logique ligne par ligne. Une liste de vérification courte et fixe repère la plupart des problèmes en quelques minutes et vous évite d’approuver du code simplement parce qu’il a l’air soigné.

Un **agent de programmation** est un outil d’IA, comme Claude Code ou Codex, qui fait plus que suggérer une ligne : il lit votre projet, modifie plusieurs fichiers, exécute des commandes et prépare souvent de lui-même un *commit* ou une demande de fusion (*pull request*). Cette vitesse est tout l’intérêt, et aussi le risque. Un agent peut modifier vingt fichiers dans le temps qu’il vous faut pour en lire un, et son code a habituellement l’air propre, qu’il soit correct ou non.

La révision doit donc être délibérée. La bonne nouvelle, c’est que vous n’avez pas besoin de lire chaque ligne avec le même soin. Il vous faut un ordre : regarder ce qui a changé avant la façon dont cela a changé, et vérifier ce qui est facile à vérifier avant ce qui demande du jugement.

## Pourquoi un code qui inspire confiance a besoin d’une liste de vérification

Une étude menée auprès d’utilisateurs à Stanford a montré que les personnes qui écrivaient du code lié à la sécurité avec un assistant d’IA produisaient un code nettement moins sûr que celles qui n’en avaient pas, et qu’elles étaient aussi *plus* susceptibles de croire leur code sûr. L’assistant de cette étude était un modèle ancien, mais la leçon sur la confiance humaine reste valable : un résultat soigné nous fait baisser la garde. Les mêmes chercheurs ont observé moins de vulnérabilités chez les participants qui se méfiaient davantage de l’assistant et travaillaient plus fort leurs prompts. Une liste de vérification est une façon simple de rester dans ce deuxième groupe.

Les conseils d’Anthropic pour son propre agent vont dans le même sens : donnez à l’agent une cible claire, comme des tests, et faites réviser le travail par une session distincte, avec un contexte neuf, plutôt que de laisser l’auteur s’évaluer lui-même.

## La liste de vérification en quatre points

| Vérification | Question à laquelle répondre | Comment vérifier rapidement |
|---|---|---|
| 1. Portée | A-t-il changé seulement ce dont la tâche avait besoin? | Lister les fichiers modifiés et le nombre de lignes |
| 2. Tests | De vrais tests couvrent-ils le changement, et passent-ils chez vous? | Regarder les différences dans les tests; lancer la suite vous-même |
| 3. Secrets | Une clé, un mot de passe ou des données privées se sont-ils retrouvés dans le code, la configuration ou les journaux? | Chercher dans les différences des motifs d’identifiants |
| 4. Dépendances | A-t-il ajouté des paquets, et existent-ils et méritent-ils confiance? | Comparer les fichiers de dépendances; vérifier chaque nouveau paquet |

C’est seulement une fois ces quatre points validés qu’il vaut la peine de lire la logique en détail : gestion des erreurs, cas limites, noms, et cohérence de l’approche avec le reste du projet.

## Un exemple concret en commandes

Disons qu’un agent a travaillé sur une branche appelée `agent/fix-login` pour corriger un bogue de connexion. Depuis le dossier du projet, dans un terminal :

```bash
# 1. Portée : quels fichiers ont changé, et dans quelle mesure?
git diff --stat main...agent/fix-login

# 2. Tests : qu’est-il arrivé aux fichiers de test? Ensuite, lancez-les vous-même.
git diff main...agent/fix-login -- tests/
git switch agent/fix-login && npm test

# 3. Secrets : des identifiants probables dans les lignes ajoutées?
git diff main...agent/fix-login | grep -inE '^\+.*(api[_-]?key|secret|token|password)'

# 4. Dépendances : la liste des paquets a-t-elle changé?
git diff main...agent/fix-login -- package.json package-lock.json
npm view some-new-package name version repository   # à répéter pour chaque nouveau nom
```

Ce qu’il faut chercher dans le résultat :

- **Portée.** Une correction de connexion qui touche le module de paiement ou réécrit un fichier de configuration mérite une question avant toute autre chose.
- **Tests.** Des assertions supprimées, un test marqué « skip » ou un test modifié pour attendre le résultat erroné sont des signaux d’alarme. Un test qui passe dans le rapport de l’agent mais échoue sur votre machine veut dire que vous lisiez une histoire, pas un résultat.
- **Secrets.** Toute correspondance exige un examen humain. Si une vraie clé a été versée dans un *commit*, la retirer dans un *commit* ultérieur ne suffit pas : considérez la clé comme exposée et remplacez-la.
- **Dépendances.** Pour chaque nouveau paquet, confirmez qu’il existe dans le registre officiel, qu’il a un vrai dépôt et un historique, et que son nom est exactement celui que vous vouliez.

Vous pouvez aussi confier les différences à une deuxième session d’agent, avec un mandat étroit :

```prompt
Tu révises une demande de fusion écrite par un autre agent d’IA. Ne corrige rien.
Tâche qui lui a été confiée : « Corriger l’erreur de connexion quand le courriel contient des majuscules. »
1. Énumère chaque fichier modifié qui n’est pas nécessaire à cette tâche.
2. Énumère tout test supprimé, sauté ou modifié pour attendre un résultat différent.
3. Énumère toute nouvelle dépendance et toute chaîne qui ressemble à un identifiant de connexion.
4. Nomme les deux lignes de logique les plus risquées et explique pourquoi.
Réponds sous forme de liste numérotée. Écris « rien trouvé » quand une section est vide.
```

> **À essayer :** prenez le dernier changement qu’un agent a fait dans un de vos projets et appliquez les quatre vérifications ci-dessus. Chronométrez-vous. Comparez ensuite avec la révision du deuxième agent et notez ce que chacun a repéré et que l’autre a manqué.

## Quelles erreurs les agents font-ils le plus souvent?

Le problème le plus courant est le **débordement de portée** (*scope creep*) : l’agent corrige le bogue et « améliore » aussi le code voisin, renomme des éléments ou reformate des fichiers. Chaque changement de plus est un endroit où un nouveau bogue peut se cacher, et il rend la vraie correction plus difficile à réviser. Demandez de petites tâches, et précisez dans vos consignes quels fichiers sont permis.

Viennent ensuite les **tests qui ne prouvent rien**. Pressé de faire passer les tests, un agent peut modifier le test au lieu du code, ou remplacer le vrai comportement par une doublure appelée **simulacre** (*mock*). Anthropic suggère de dire explicitement à l’agent de ne pas modifier les tests une fois que vous les avez approuvés, et de verser ces tests en premier dans un *commit*, pour que tout changement apparaisse dans les différences.

En troisième lieu viennent les **dépendances inventées ou risquées**. Des chercheurs qui ont généré 576 000 échantillons de code avec 16 modèles ont constaté qu’en moyenne, au moins 5,2 % des paquets suggérés par les modèles commerciaux et 21,7 % de ceux suggérés par les modèles à code source ouvert n’existaient pas. On appelle cela des **hallucinations de paquets** (*package hallucinations*), et elles sont dangereuses, parce qu’un attaquant peut publier du code malveillant sous un nom que les modèles ont tendance à inventer. N’installez jamais un paquet nommé par un agent sans le vérifier.

Enfin, surveillez les faiblesses discrètes : une gestion des erreurs absente, des secrets lus au mauvais endroit et des entrées acceptées sans vérification. Rien de cela n’a l’air faux au premier coup d’œil, et c’est exactement pourquoi la liste de vérification passe avant la lecture.

## Sources

- Claude Code: Best practices for agentic coding: https://www.anthropic.com/engineering/claude-code-best-practices
- We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs: https://arxiv.org/abs/2406.10279
- Do Users Write More Insecure Code with AI Assistants?: https://arxiv.org/abs/2211.03622