Relire du code généré par IA ne consiste pas à traquer des fautes de syntaxe : un agent produit rarement du code qui ne compile pas. La relecture cherche des décisions, celles que l'agent a prises sans les expliciter. On vérifie en priorité la gestion des cas limites et des erreurs, les dépendances ajoutées, l'absence de secrets ou de chemins codés en dur, la duplication silencieuse d'une fonction déjà existante, et la cohérence avec les conventions du dépôt.
Le réflexe qui casse le plus vite, c'est de relire un diff d'agent comme on relirait la pull request d'un collègue junior. Le code d'un agent est syntaxiquement correct et plausible par construction : il ressemble à du bon code, même quand il ne l'est pas. C'est précisément ce qui rend la relecture ligne à ligne insuffisante, et ce qui justifie une grille de contrôle différente.
1. Pourquoi relire du code d'agent différemment d'un code humain
Un développeur junior qui écrit du mauvais code laisse des traces reconnaissables : variables mal nommées, logique hésitante, commentaires qui trahissent le doute. Un agent, lui, produit un code propre en apparence, avec une structure cohérente et un style homogène, même quand la logique sous-jacente est fausse ou incomplète.
C'est le constat qui ressort d'une session de formation animée récemment auprès d'une équipe de développement : la difficulté n'était pas de repérer des erreurs de syntaxe, mais d'accepter que la relecture devait chercher autre chose. Un code qui a l'air correct passe souvent une relecture rapide, ce qui déplace le risque vers les décisions non explicites : un cas limite ignoré, une dépendance ajoutée sans réflexion, une convention de nommage non respectée.
Cette différence a un coût mesuré. Le rapport 2025 de GitClear, qui a analysé 211 millions de lignes de code modifiées, relève une hausse du taux de churn de 4,5 % en 2023 à 5,7 % en 2024, une baisse de 39,9 % du refactoring, et une multiplication par huit des blocs de code dupliqués sur la même période. Ce ne sont pas des signaux d'alerte anecdotiques : ce sont des tendances de fond dans les dépôts qui adoptent des agents de code sans ajuster leur revue.
2. Par où commencer sur un diff volumineux
Un diff de plusieurs centaines de lignes ne se relit pas dans l'ordre où il est présenté. Trois priorités, dans cet ordre :
Les zones à risque avant les zones neutres
On commence par les fichiers qui touchent l'authentification, les permissions, les paiements ou la manipulation de données personnelles. Un bug dans une fonction d'affichage se corrige en cinq minutes. Un bug dans un contrôle d'accès se découvre parfois des mois plus tard.
Les tests avant le code métier
Les tests écrits par l'agent indiquent ce qu'il pense avoir couvert, et par élimination, ce qu'il a laissé de côté. Les lire en premier oriente la relecture du code vers les zones réellement fragiles, au lieu de parcourir le diff dans l'ordre alphabétique des fichiers.
Réduire le volume plutôt que le survoler
Si le diff dépasse ce qu'on peut tenir en tête, la bonne réponse n'est pas de relire plus vite : c'est de demander une modification plus petite. Accepter des changements plus modestes, quitte à multiplier les itérations, garde la relecture réellement exhaustive au lieu de la transformer en survol de confort.
3. Les points de contrôle prioritaires sur le code lui-même
Au-delà du volume, une grille de lecture concentrée sur cinq points couvre l'essentiel des risques observés en pratique.
Gestion des cas limites et des erreurs. Un agent traite naturellement le chemin nominal, celui que la demande décrit explicitement. Les cas limites (entrée vide, valeur nulle, dépassement de capacité, appel réseau qui échoue) sont souvent absents, sauf si le prompt les mentionnait précisément. On vérifie systématiquement ce que fait le code quand une hypothèse implicite ne tient pas.
Dépendances ajoutées. Chaque ligne nouvelle dans un fichier de dépendances mérite une question simple : une fonction déjà présente dans le dépôt, ou dans la bibliothèque standard du langage, aurait-elle suffi ? Un agent installe volontiers un paquet tiers pour une tâche de dix lignes, ce qui ajoute une surface d'attaque et une charge de maintenance non justifiées.
Secrets et chemins codés en dur. Clés d'API, identifiants de base de données, chemins de fichiers absolus propres à un poste de développement : ces éléments apparaissent parfois dans du code généré, en particulier quand l'agent s'est appuyé sur un exemple ou une variable d'environnement mal isolée. Un grep systématique sur les motifs de secrets avant fusion reste plus fiable qu'une relecture visuelle. Le guide de gestion des secrets de l'OWASP détaille les motifs à surveiller et les alternatives (gestionnaires de secrets, variables d'environnement chiffrées). Ce risque rejoint plus largement la question de la sécurité de Claude Code en entreprise : ce que l'agent lit pour construire son contexte peut inclure des éléments qui n'auraient jamais dû s'y trouver.
Duplication silencieuse. Un agent qui ne connaît pas l'intégralité du dépôt réécrit parfois une fonction qui existe déjà ailleurs, sous un nom différent. Cette duplication ne casse rien dans l'immédiat, mais elle multiplie les endroits où corriger un même bug plus tard. C'est un défaut à traiter comme bloquant, pas comme un détail de style.
Cohérence avec les conventions du dépôt. Nommage des variables, structure des dossiers, gestion des erreurs par exceptions ou par valeurs de retour : un agent suit les conventions qu'on lui montre, pas celles qu'il devine. Un code qui fonctionne mais qui rompt avec le style du reste du dépôt complique chaque relecture future, bien après que l'agent a quitté la conversation.
4. Les tests écrits par l'agent, une confiance à vérifier
Un agent qui écrit à la fois le code et son test peut valider sa propre erreur de raisonnement. Si sa compréhension du problème est incomplète, le test qu'il rédige reflète cette même compréhension incomplète, et passe sans jamais révéler le défaut.
Trois vérifications simples limitent ce risque :
- Le test échoue-t-il quand on casse volontairement la fonction ? Un test qui passe même sur un code délibérément faux ne teste rien.
- Couvre-t-il au moins un cas limite et un cas d'erreur ? Pas seulement le chemin nominal que la demande décrivait.
- Vérifie-t-il un résultat précis, ou seulement l'absence de plantage ? Un test qui se contente de vérifier que le code s'exécute sans lever d'exception ne garantit pas que le résultat produit est correct.
Point de contrôle
Une bonne pratique de revue de code chez Google consiste à se demander si le code, dans son ensemble, améliore la santé du dépôt, pas uniquement s'il fonctionne. Appliqué au code d'agent, ce principe justifie de refuser un diff qui fonctionne mais qui introduit de la duplication, une dépendance superflue ou une incohérence de convention.
5. Ce qui reste humain : architecture, dépendances, performance
Certaines décisions ne se délèguent pas à un agent, quelle que soit la qualité du code produit.
L'architecture
Découper un système en services, choisir où placer une frontière entre deux modules, décider ce qui doit rester synchrone ou passer en file d'attente : ce sont des choix qui engagent le projet sur plusieurs années. Un agent exécute une architecture qu'on lui décrit, il ne la conçoit pas à la place d'une équipe qui connaît le contexte métier et les contraintes de charge réelles.
Le choix d'une dépendance structurante
Ajouter une bibliothèque de test ou un utilitaire de formatage de dates est anodin. Choisir un framework, une base de données ou un fournisseur de paiement engage l'organisation sur le long terme, avec des coûts de migration difficiles à anticiper. Ce type de décision reste un arbitrage humain, documenté et assumé.
L'arbitrage de performance
Un agent optimise rarement pour la charge réelle de production, parce qu'il ne la connaît pas. Un compromis entre lisibilité du code et temps de réponse, ou entre coût d'infrastructure et latence, suppose de connaître les contraintes business du produit, pas seulement la syntaxe du langage utilisé.
6. Formaliser une charte de revue pour l'équipe
La question qui revient le plus souvent après une première période d'usage d'agents de code n'est pas technique, elle est organisationnelle : qui relit quoi, et qui porte la responsabilité de ce qui est fusionné ? Cette charte trouve naturellement sa place dans le fichier CLAUDE.md du projet, à côté des conventions et des zones sensibles déjà documentées.
Une charte courte, tenue à jour, répond à trois questions concrètes :
- Quel volume de modification accepte-t-on d'un agent en une seule fois avant d'exiger un découpage en plusieurs revues plus petites ?
- Quelles zones du dépôt exigent une double relecture (authentification, paiement, données personnelles) et lesquelles tolèrent une revue plus légère ?
- Que refuse-t-on de déléguer, même si l'agent produit un résultat qui fonctionne : décisions d'architecture, choix de dépendance structurante, code touchant à la sécurité sans double vérification humaine ?
Sur ce dernier point, la règle la plus simple reste la plus efficace : la personne qui approuve la fusion en porte la responsabilité, exactement comme pour le code écrit par un collègue. L'agent n'est pas interrogeable après un incident en production ; la responsabilité reste entièrement humaine, ce qui suppose d'avoir réellement compris ce qu'on valide, pas seulement vérifié que les tests passent au vert.
Pour une équipe qui commence tout juste à intégrer des agents de code dans son flux de développement, la comparaison entre agents de code et développement sur mesure aide à situer où l'automatisation apporte un vrai gain, et où elle exige un cadrage préalable plus poussé.
Pour aller plus loin
- formation Claude Code sécurité : former une équipe technique à un usage encadré des agents de code, avec une charte de revue adaptée au dépôt.
- Agents de code vs développement sur mesure pour une PME : comprendre quand déléguer à un agent et quand passer par un développement encadré.
- Dynamic workflows dans Claude Code : orchestrer plusieurs agents en parallèle sans perdre le contrôle sur la qualité produite.
- Model Context Protocol en entreprise : comment un agent accède à vos outils et vos données internes, et ce que cela implique pour la revue de sécurité.
