Comment examiner du code généré par l’IA ?

Avec les agents de codage, le code augmente et la review s’allonge

Ces quatre chiffres viennent d’une seule étude. Deux chercheurs de l’université Harvard ont suivi 718 entreprises de janvier 2021 à mars 2026, à partir des données d’une plateforme d’analytique de l’ingénierie logicielle (version d’août 2026 de l’étude). Un agent de codage est un outil qui prend une tâche, écrit du code dans plusieurs fichiers, lance les tests et recommence jusqu’à ce que le travail soit fini. Dans les entreprises passées à ces outils, les lignes de code ajoutées ont augmenté de 30 %, les commits de 20 % et les pull requests de 23 %.

Le travail terminé n’a pas suivi au même rythme : la hausse des tickets clos est faible et statistiquement non significative. La même étude explique l’écart. Le délai entre l’ouverture d’une pull request et son merge s’est allongé de 49 %, la part des pull requests pour lesquelles des modifications sont demandées a presque doublé, et le nombre de commentaires de review par pull request a augmenté de 35 %. La conclusion des auteurs : le goulot d’étranglement, c’est la revue de code.

D’autres mesures pointent au même endroit. Dans le rapport 2026 de LinearB (plus de 8,1 millions de pull requests), les pull requests générées par l’IA attendent 4,6 fois plus longtemps avant que la review commence, puis sont examinées deux fois plus vite une fois prises en main. Dans l’enquête de Sonar auprès de plus de 1 100 développeurs, 96 % des répondants ne font pas entièrement confiance à l’exactitude du code généré par l’IA ; ceux qui disent toujours le vérifier avant un commit sont 48 %.

Nous développons diffox, un outil qui examine les pull requests ; la liste ci-dessous vient de ce travail et des règles de notre propre dépôt, et elle s’applique à la main, sans outil.

Dans le code généré par l’IA, chaque ligne a l’air aussi sûre que les autres

Quand vous examinez le code d’un collègue, vous connaissez son auteur : vous devinez ce qu’il maîtrise et où il est allé trop vite, et vous lui posez la question là où vous avez un doute. Quand l’auteur est un modèle de langage, rien de tout cela n’existe.

L’étude publiée par JetBrains Research en octobre 2026 décrit le problème ainsi. Le modèle présente chaque ligne qu’il produit avec la même assurance ; aucun signal n’indique que la logique d’authentification était simple et la migration de base de données difficile. Lire chaque ligne ne tient plus quand les changements produits par les agents grossissent. Pour les chercheurs, la difficulté n’est pas de lire le diff, mais de calibrer sa confiance : savoir répartir l’effort de review en proportion du risque de chaque partie. L’étude s’appuie sur quatre ateliers menés avec 17 praticiens et sur une enquête à laquelle ont répondu 43 professionnels du logiciel.

Les signaux d’alerte habituels ne fonctionnent pas non plus. Dans du code écrit par un humain, une fonction brouillonne ou un commentaire laissé en plan vous disent « attention ici ». Le code généré par l’IA compile généralement, ses noms sont propres, il arrive avec ses commentaires et ses tests. Dans l’enquête de Sonar, 53 % des développeurs citent exactement cela parmi les effets négatifs de l’IA sur la dette technique : du code qui a l’air correct mais n’est pas fiable.

À quoi doit ressembler une checklist de revue de code ?

La liste propose un ordre. On commence à répondre aux deux premières questions avant même d’ouvrir le code, et elles indiquent où regarder ; la troisième vérifie les preuves ; les deux dernières demandent chacune une lecture à part. C’est aussi la direction que propose l’étude de JetBrains : d’abord la vue d’ensemble, puis les fichiers, et les lignes en dernier.

Liste établie pour cet article. Elle s’appuie sur le guide « Review AI-generated code » de GitHub, sur le guide de revue de code de Google et sur les règles que nous appliquons dans notre propre dépôt.

La description, les commentaires et la liste des fichiers passent avant le code

Pour la première question, lisez la description de la pull request comme une liste d’affirmations. Si elle dit « réessaie trois fois une requête qui échoue », trouvez les trois tentatives dans le diff. Lisez les commentaires de la même façon : un commentaire peut décrire ce que le code devrait faire, et non ce qu’il fait. Un exemple :

def fetch_prices(symbols):
    """Récupère les prix ; réessaie trois fois en cas d'erreur réseau."""
    try:
        return client.get_prices(symbols)
    except Exception:
        return []

Cette fonction compile et passe le test du cas nominal. Elle a deux défauts. La docstring promet trois tentatives, le code n’essaie qu’une fois. Et l’erreur est avalée : même si le service est tombé, l’appelant reçoit une liste vide et la lit comme « pas de prix ».

Pour la deuxième question, regardez la liste des fichiers avant d’ouvrir le code. Si la tâche consiste à ajouter un champ à un endpoint, la description doit dire pourquoi un module sans rapport a changé. Lisez ensuite les lignes supprimées : une ligne ajoutée attire l’œil, une validation ou une ligne de log supprimée, non. Pour chaque comportement supprimé, cherchez s’il reste un endroit qui en dépend encore.

Le troisième contrôle, c’est le chemin que suit l’erreur. La règle que nous appliquons dans notre propre dépôt : une erreur interceptée doit remonter jusqu’à l’appelant. Un except trop large, un chemin de repli qui renvoie une valeur par défaut ou une valeur de retour ignorée ne corrigent pas l’erreur ; ils la rendent invisible.

Un test qui passe ne vérifie pas forcément quelque chose

Un agent de codage lance les tests lui-même et recommence jusqu’à ce qu’ils passent. Dans la pull request d’un agent, « les tests passent » est donc un prérequis, pas une preuve à lui seul. Le guide de revue de code de Google pose la même question : les tests échoueront-ils vraiment si le code est cassé ? Un exemple :

def test_discount_is_applied():
    order = make_order(total=100)
    apply_discount(order, code="WELCOME10")
    assert order is not None

Ce test passe même si la remise n’est jamais appliquée. Son nom parle de la remise ; son assertion vérifie seulement que la commande existe. La correction tient en une ligne : assert order.total == 90.

Le premier contrôle s’appelle la vérification par mutation : vous annulez la correction et vous constatez que le test échoue. Pour le deuxième, une distinction aide : une recherche n’est pas une vérification. Un test qui affirme « le message d’erreur n’apparaît pas dans la sortie » passe aussi quand le message n’est jamais produit ; il lui faut un contre-exemple qui montre que la recherche sait trouver ce qu’elle cherche.

Les données de test font partie du même problème. Un exemple inventé à la main teste l’idée que l’auteur se fait des données. Prenez l’exemple dans un enregistrement réel, ou comparez-le à un enregistrement réel.

La sécurité demande une lecture à part, même quand le code compile

D’après le rapport de Veracode de juillet 2026, le code généré sans consigne de sécurité compile presque toujours, mais son taux de réussite aux tests de sécurité est en moyenne de 56 % sur plus de 100 modèles. Ce taux varie selon le langage : 63 % en Python, 30 % en Java. Le rapport teste les modèles bruts, pas un agent entouré d’outils, de garde-fous ou d’une review humaine. La conclusion reste nette : la sécurité demande une lecture à part.

Dans cette lecture, regardez trois endroits. Une entrée venue de l’extérieur atteint-elle une requête, une commande shell ou un chemin de fichier sans être filtrée ? Le nouvel endpoint a-t-il le même contrôle d’autorisation que ses voisins, et un secret a-t-il été écrit dans le code ou dans les logs ? Enfin, ouvrez chaque nouvelle dépendance, une par une.

Une étude acceptée à USENIX Security 2025 a généré 576 000 exemples de code avec 16 modèles : en moyenne, au moins 5,2 % des paquets suggérés par les modèles commerciaux n’existaient pas en réalité, et 21,7 % pour les modèles open source. C’est pourquoi le guide de GitHub recommande de vérifier qu’une dépendance suggérée existe, qu’elle est maintenue, et quelle est sa licence.

La review se mesure aux règles écrites du dépôt

La cinquième question ne demande pas si le code est correct, mais s’il a sa place dans ce dépôt. Si vos règles sont écrites dans un fichier (AGENTS.md, CLAUDE.md ou CONTRIBUTING.md), gardez ce fichier ouvert pendant la review et lisez le changement en le confrontant à ce fichier.

Des deux autres contrôles, le premier porte sur la duplication : un nouvel utilitaire a peut-être été écrit alors que le dépôt en a déjà un qui fait la même chose. Dans l’enquête de Sonar, 40 % des développeurs citent aussi le code inutile et dupliqué parmi les effets négatifs. Quand vous voyez une nouvelle fonction utilitaire, cherchez son équivalent dans le dépôt.

Le second : les deux moitiés d’une opération doivent être tirées de la même valeur. Si une fonction vérifie la validité avec une liste et fait l’opération avec une autre, ou lit l’heure deux fois à deux endroits différents, chaque moitié a l’air correcte prise isolément ; le bug est dans la relation entre les deux. Notre règle : la valeur est résolue une fois, et c’est elle qu’on transmet aux deux moitiés.

Pour appliquer la liste, gardez les pull requests petites et dosez l’attention selon le risque

Appliquer quinze contrôles à une pull request de mille lignes est difficile. Le guide de Google juge raisonnable une taille d’environ 100 lignes, trouve 1 000 lignes souvent trop gros, et laisse au relecteur le droit de refuser un changement pour sa seule taille. L’étude de Harvard n’a pas trouvé de changement significatif de la taille des pull requests après le passage aux agents de codage ; la moyenne de référence était d’environ 1 168 lignes ajoutées par pull request. Demander à l’agent de petites pull requests qui ne font qu’une chose, c’est le premier pas de la review.

Même dans une petite pull request, tous les fichiers ne demandent pas la même attention. L’ordre que propose l’étude de JetBrains consiste à classer les fichiers selon le risque avant de lire la moindre ligne.

Une partie de la liste peut être confiée à un outil, une autre non :

• Confiez-le à l’outil. Compilation, tests, linter, analyse statique, détection de secrets, contrôle des dépendances et des licences.
• L’outil signale, vous décidez. Contradiction entre un commentaire et le code, erreur avalée, test vide, ligne contraire au fichier de règles. C’est la personne qui connaît le contexte qui décide si ce qui a été trouvé est vraiment un bug.
• Gardez-le pour vous. Savoir si le changement résout le bon problème et si sa conception convient au dépôt, et la décision de merge.

diffox se situe dans le deuxième de ces trois cas. Il fait lire la pull request par des agents spécialisés qui cherchent chacun une seule chose ; quatre points de la liste apparaissent dans les commentaires sous le nom de quatre agents : Broken Promise Agent pour un commentaire qui affirme ce que le code ne fait pas, Silent Failure Agent pour une erreur avalée, Empty Test Agent pour un test qui passe quoi que fasse le code, House Rules Agent pour une ligne contraire à votre fichier de règles. diffox ne bloque pas le merge ; la décision de merge appartient à votre équipe (son fonctionnement fait l’objet d’un article à part).