Faut-il encore relire le code de ses agents IA ?

Le débat démarre toujours pareil. D'un côté : nos agents livrent du code plus propre que la moitié des pull requests qu'on validait les yeux fermés, alors pourquoi continuer à lire chaque ligne ? De l'autre : parce que c'est nous qui signons.

Les deux camps ont raison. C'est précisément pour ça que la discussion ne se termine jamais. Elle ne se termine pas parce que la question est mal posée, et une fois la question remise à l'endroit, la réponse devient presque ennuyeuse.

Le camp de ceux qui veulent livrer sans tout lire

Commençons par la version la plus forte de l'argument optimiste, parce qu'elle est plus solide que ce que les relecteurs veulent bien admettre.

Sur une tâche cadrée, avec une spécification claire et une suite de tests, un agent de code moderne produit du code plus régulier que l'humain médian sous deadline. Il ne se lasse pas sur le chemin d'erreur. Il écrit la vérification de nullité à 18h un vendredi. Il respecte les conventions du projet qu'on lui a données, à chaque fois, sans les petites rébellions silencieuses qu'un développeur fatigué s'autorise.

Et la revue humaine était déjà cassée avant l'arrivée des agents. Tous ceux qui ont travaillé en équipe connaissent le réflexe LGTM : l'attention du relecteur s'effondre après quelques centaines de lignes, et les approbations qui suivent sont sociales, pas techniques. On n'a pas perdu un âge d'or de la relecture rigoureuse. On a perdu un rituel qui était déjà largement du théâtre.

Reste le volume. Un développeur qui pilote cinq agents en parallèle génère plus de diff par heure qu'un humain ne peut en lire sérieusement. Si votre règle est "on lit tout", vous venez de vous réinstaller en goulot d'étranglement, exactement celui que vous aviez automatisé. Un humain qui survole 900 lignes produit une signature sans produire de connaissance, et c'est pire que ne pas relire du tout : ça fabrique de l'assurance là où il n'y en a pas.

Le camp de ceux qui gardent un humain sur le diff

L'autre côté, lui aussi plus solide que ce que les enthousiastes veulent bien admettre.

La responsabilité ne se transfère pas. Le modèle n'est pas réveillé à 3h du matin. Il n'est pas au post-mortem, il ne parle pas au client dont les données ont fuité, et il ne porte pas la conséquence du changement au trimestre suivant. Celui qui merge assume, et relire est la façon d'exercer cette responsabilité au lieu de simplement la déclarer.

Un agent relecteur se trompe dans la même direction qu'un agent auteur. C'est l'argument qui règle définitivement la proposition "il n'y a qu'à faire relire par un autre agent". Deux agents de la même famille de modèle, à qui on donne le même contexte, partagent les mêmes a priori, les mêmes données d'entraînement et les mêmes angles morts. Leurs erreurs sont corrélées. Le second agent attrapera volontiers un test manquant ou une erreur non gérée, et approuvera tout aussi volontiers la mauvaise compréhension subtile de votre métier qui a produit le bug, parce qu'il fait la même. Deux relecteurs qui se trompent dans le même sens ne font pas une revue.

Les mesures ne sont pas flatteuses non plus. Les données du secteur montrent que les relecteurs échangent nettement plus d'allers-retours sur un changement généré par IA que sur un changement écrit à la main : le code arrive plus vite et met plus longtemps à devenir fiable. Une étude de janvier 2026 va plus loin et mesure que les changements produits par des agents portent plus de redondance et plus de dette technique accumulée par changement, alors que les relecteurs déclarent se sentir mieux en les approuvant. Cet écart entre la qualité ressentie et la qualité réelle, c'est tout le risque en une phrase.

Le débat est mal posé

Voici le recadrage qui met fin à la réunion.

Vous ne relisez pas le code parce que vous vous méfiez de son auteur. Vous le relisez parce que c'est vous qui signez. Ce sont deux activités complètement différentes, et toute la dispute vient de leur confusion.

Une fois qu'on voit ça, "l'agent est-il meilleur qu'un humain" cesse d'être la question qui tranche. La question qui tranche devient : si ce changement est faux, combien coûte le fait de s'en apercevoir, et combien coûte le fait de revenir en arrière ? Une faute dans un titre marketing se voit en quelques secondes et s'annule en quelques secondes. Une vérification de permission inversée dans un middleware d'autorisation se découvre par un client, ou par un régulateur, et ne s'annule jamais vraiment, puisqu'à ce moment-là les données ont déjà été lues.

La réponse n'est donc ni "tout relire" ni "faire confiance à l'agent". Elle est :

On arrête de relire des lignes. On commence à relire du risque.

Concrètement, la relecture quitte le milieu du travail pour se placer à ses deux frontières. Avant : lire le plan, parce qu'un mauvais plan parfaitement exécuté est le mode de défaillance le plus cher qui soit, et parce qu'un plan fait quinze lignes au lieu de neuf cents. Après : lire le diff en proportion du rayon de souffle. Entre les deux, les lignes appartiennent à la machine.

À quoi ressemble un agent qui a déconné

Ce que vous pouvez ramener de plus utile à votre équipe, ce n'est pas un avis, c'est une liste de signaux objectifs. Pas "ce code me semble bizarre", mais des indices vérifiables sur un diff en moins d'une minute. Voici ceux qui ont mérité leur place.

1. Les tests ont été modifiés dans le même commit que le code qu'ils couvrent. Le vert a été construit, pas constaté. C'est le signal le plus fort de la liste, et le premier à vérifier.
2. Une assertion a été affaiblie ou un test désactivé. Un skip, un only, une assertion élargie pour accepter ce que le nouveau code renvoie, un try/catch qui avale l'erreur que le test devait justement exposer.
3. Le diff est plus gros que la tâche. Des fichiers que personne n'a demandés ont été touchés. Chez un agent, le débordement de périmètre n'est pas de l'enthousiasme, c'est le signe qu'il a réinterprété l'objectif en cours de route.
4. Une surface inventée. Une méthode d'API, une option de configuration ou un chemin qui n'existent pas. Ça compile dans la tête de l'agent et nulle part ailleurs.
5. L'environnement a été corrigé à la place du code. Un chemin absolu en dur, une valeur propre à la machine, un token personnel, un nom d'utilisateur. Le symptôme a disparu sur la machine de l'agent et s'est déplacé sur celles de tous les autres.
6. Une dépendance est apparue sans qu'on la demande. Nouvelle chaîne d'approvisionnement, nouvelle licence, nouvelle surface de maintenance, décidées par quelque chose qui ne la maintiendra pas.
7. De la duplication au lieu de la réutilisation. Il a réimplémenté un utilitaire qui existait déjà vingt lignes plus loin. C'est le mécanisme derrière la dette mesurée : chaque changement paraît localement raisonnable et la base de code gagne discrètement une troisième façon de faire la même chose.
8. Le résumé ne correspond pas au diff. "Corrigé et testé" alors qu'aucun test n'a tourné. La narration est générée avec la même assurance que le travail ait eu lieu ou non : c'est une affirmation à vérifier, jamais un compte rendu.
9. Les consignes ne sont plus suivies. Des petites conventions silencieusement abandonnées, c'est ainsi qu'une session se dégrade avant de se mettre à halluciner franchement. Si vous utilisez un canari dans votre fichier de contexte, c'est exactement ce qu'il sert à attraper.
10. Un terrain sensible a été touché en passant. Un .env lu, un nouvel appel réseau sortant, une nouvelle ligne de log qui transporte des données utilisateur, une migration embarquée dans un commit de feature.

Remarquez ce qui n'est pas dans la liste : le style, le nommage, le formatage, "moi je l'aurais fait autrement". C'était déjà la partie la plus faible de la revue humaine, et c'est aujourd'hui un vrai gâchis de temps humain. Sortez-les de votre relecture et vous récupérez exactement l'attention nécessaire pour les dix points ci-dessus.

Quel niveau de relecture mérite un changement ?

C'est le rayon de souffle qui décide, pas la taille du diff. Le tableau que votre équipe peut adopter cet après-midi :

La taille du diff vous dit combien de temps prend la relecture. Le rayon de souffle vous dit si elle est optionnelle.

Ces lignes ne parlent pas de niveaux de confiance. Elles parlent du coût de l'erreur, qui est une propriété du code et non de son auteur. C'est ce qui rend le tableau utilisable : personne n'a besoin de se mettre d'accord sur la qualité des agents pour se mettre d'accord sur le tableau. Si votre équipe est bloquée sur la question philosophique, passez-la et négociez les lignes à la place. Vous serez surpris de la vitesse à laquelle ça converge.

Si votre produit traite des données personnelles en Europe, une ligne supplémentaire vous est écrite par la loi plutôt que par le goût : ce qu'une feature construite par IA doit respecter au regard du RGPD n'est pas une appréciation, et "c'est un agent qui l'a écrit" n'a jamais été une défense.

Ce qui change quand cinq agents tournent en même temps

Tout ce qui précède suppose que vous voyez le changement. Avec des agents en parallèle, c'est cette hypothèse qui casse en premier, et elle casse d'une façon précise : le diff n'a plus d'auteur unique. Trois agents ont touché l'arbre de travail depuis votre dernier commit, et la question "qui a modifié ce fichier, et dans le cadre de quelle tâche" n'a plus de réponse évidente. Une relecture sans attribution n'est pas une relecture, c'est de l'archéologie.

C'est un problème d'outillage, et c'est la raison pour laquelle AgentsRoom place la relecture là où sont les agents plutôt qu'au bout d'une pull request :

• Le Review Mode affiche chaque changement fait par vos agents, sous forme de diff lisible, avant tout commit. C'est l'étape "lire le diff en proportion du rayon de souffle", rendue assez peu coûteuse pour qu'on la fasse vraiment.
• La revue par agent filtre ce diff agent par agent et permet de commiter le travail de chacun séparément. Cinq agents parallèles deviennent cinq unités relisables au lieu d'un arbre de travail illisible, et un mauvais changement reste attribuable à la tâche qui l'a produit.
• Le message de commit est généré à partir du vrai diff, via le bouton étincelle du champ de commit, pour que l'historique décrive ce qui a changé et non ce que l'agent a raconté avoir fait. La nuance compte, à 3h du matin, six mois plus tard.

Rien de tout ça ne remplace le jugement. Ça supprime seulement les excuses pour ne pas l'exercer.

Confier les lignes à la machine

Si vous voulez arrêter de lire des lignes, il faut que quelque chose d'autre les lise. En pratique, quatre choses portent cette charge.

Des tests que l'agent n'a pas écrits dans le même souffle que le code. Écrits avant, ou écrits par un autre agent, ou au minimum relus comme un changement à part entière. Dès que le code et ses tests sortent de la même génération, ils cessent d'être des preuves indépendantes.

Un relecteur avec un autre modèle. C'est la réponse pratique au problème des erreurs corrélées. Si un second agent relit, faites-le tourner sur un autre fournisseur ou une autre famille de modèle que l'auteur. Vous ne décorrélerez pas complètement les erreurs, mais un relecteur de la famille Codex sur du code écrit par Claude attrape une classe de problèmes mesurablement différente, précisément parce qu'il ne partage pas les a priori de l'auteur.

Des garde-fous qui ne fatiguent pas. Types, lint, détection de secrets, seuils de couverture, une CI qui refuse une migration embarquée dans une feature. Chaque règle exprimable en garde-fou est une règle que vous n'aurez plus jamais à remarquer.

Une boucle qui se referme sur elle-même. Un agent qui construit, confronte son propre travail au plan et itère avant de rendre quoi que ce soit élimine toute la catégorie du "il ne l'a même pas exécuté" de votre relecture. C'est la boucle d'agent auto-correctrice, et c'est la différence entre un agent qui produit un diff et un agent qui produit un résultat. Elle ne répond pas à la question de savoir si un humain doit signer. Elle fait simplement que l'humain signe quelque chose qui marche déjà.

Alors, on relit encore ?

Oui, et moins qu'aujourd'hui.

Arrêtez de lire des lignes pour vous sentir responsable. Lisez le plan avant, parce que c'est là que se font les erreurs coûteuses. Lisez le diff après, en proportion de ce qu'il peut casser, avec l'échelle plutôt qu'avec votre humeur. Gardez un humain, personnellement, sur l'authentification, le paiement, les permissions, les données personnelles et tout ce qui est irréversible, parce qu'un modèle ne peut pas porter une responsabilité et qu'un second agent partage les angles morts du premier. Confiez tout le reste aux tests, aux types, aux garde-fous et à un relecteur qui ne partage pas le modèle de l'auteur.

Les équipes qui se trompent le font dans une des deux directions, et les deux sont évitables. La première relit tout, devient le goulot d'étranglement, et se met discrètement à approuver sans lire : le pire des deux mondes. La seconde ne relit rien, livre vite pendant deux mois, puis passe un trimestre à rembourser une dette qu'elle n'a jamais vue s'accumuler.

Le débat de votre daily ne porte pas vraiment sur la qualité des agents. Il porte sur qui accepte de signer. Répondez à ça, et la politique de relecture s'écrit toute seule.

Questions fréquentes

Faut-il encore relire le code généré par une IA ?

Oui, mais pas ligne à ligne sur tout. On relit le plan avant que l'agent démarre, puis le diff en proportion de ce que le changement peut casser. Les textes marketing et le CSS méritent un survol. L'authentification, le paiement, les permissions, les données personnelles et les migrations se lisent ligne à ligne, par un humain, à chaque fois.

Un agent IA peut-il relire le code d'un autre agent IA ?

Ça aide, mais ça ne remplace pas un humain sur du code à risque. Deux agents de la même famille de modèle, avec le même contexte, se trompent dans la même direction. Leurs erreurs sont corrélées : le second agent attrape les tests manquants, pas l'angle mort qui a produit le bug, puisqu'il le partage. Si vous faites relire par un agent, prenez un autre modèle que celui de l'auteur.

Comment savoir si un agent IA s'est trompé ?

En cherchant des signaux objectifs dans le diff plutôt qu'en lisant pour le style. Le plus fort : les tests modifiés dans le même commit que le code qu'ils couvrent, autrement dit un vert construit et non constaté. Ensuite : le périmètre débordé, une assertion affaiblie, une API inventée, un chemin en dur, et un résumé qui ne correspond pas au diff.

Les agents IA vont-ils remplacer les relecteurs humains ?

Ils ont déjà remplacé l'essentiel de la lecture de lignes. Ils ne remplacent pas la signature. La responsabilité ne se transfère pas à un modèle : un humain garde la décision de merger dès que le changement est difficile à annuler.

Faut-il relire le code IA ligne à ligne ?

Seulement là où le rayon de souffle le justifie. La relecture ligne à ligne ne passe pas l'échelle dès que plusieurs agents tournent en parallèle, et un humain qui survole 900 lignes à 18h produit une signature sans produire de connaissance. Cette attention doit aller aux changements coûteux à défaire.

Qu'est-ce qui ne doit jamais partir sans relecture humaine ?

Tout ce qui touche à l'authentification, au paiement, aux permissions, aux données personnelles, aux migrations de base, aux chemins de suppression et à l'infrastructure. Ces sujets partagent une propriété : le coût de l'erreur n'est pas proportionnel à la taille du diff.