Code review du code IA : six schémas que la revue classique manque

Une revue de code généré par IA doit chercher autre chose qu'une revue classique. Une IA produit rarement des fautes de frappe ou des étourderies. Elle produit du code qui paraît plausible et qui, à certains endroits, omet systématiquement quelque chose : les contrôles d'autorisation, la gestion des erreurs, la confrontation avec la logique déjà existante.

Pourquoi la code review classique fonctionne-t-elle moins bien pour le code IA ?

Parce qu'elle est conçue pour une répartition des erreurs qui n'existe plus telle quelle. Le code humain contient typiquement des inattentions : variables intervertis, cas limites oubliés, noms peu clairs. Ces erreurs ont l'air fausses, et c'est exactement à cela qu'un relecteur est entraîné.

Le code d'IA a l'air correct. Les noms sont cohérents, la structure est conventionnelle, les commentaires sont présents. L'œil ne trouve aucun point d'accroche. Dans la Stack Overflow Developer Survey 2025, 66 % des personnes interrogées ont cité « presque correct, mais pas tout à fait » comme leur plus grande frustration avec les outils d'IA : c'est exactement la description d'une catégorie d'erreurs qu'un simple coup d'œil ne révèle pas.

S'y ajoute le volume. Une revue de 800 lignes générées ne reçoit pas l'attention de 80 lignes écrites à la main. Au-delà d'une certaine taille, toute revue devient un échantillonnage, sans que personne ne l'ait décidé.

À quoi dois-je être particulièrement attentif lors d'une revue de code IA ?

À six schémas qui apparaissent plus souvent que la moyenne dans le code généré.

• Contrôle d'autorisation manquant. La logique métier est correcte, mais la question « cet utilisateur en a-t-il le droit ? » n'a jamais été posée. Le contrôle d'accès défaillant occupe toujours la première place de l'OWASP Top 10:2025.
• Erreurs avalées. Un bloc catch vide, une valeur de retour ignorée, une valeur par défaut qui déguise un échec en succès. Catégorie OWASP à part entière depuis 2025 (A10).
• Logique réinventée à côté de la logique existante. Le modèle ne connaît pas votre fonction utilitaire et en écrit une seconde. Les deux fonctionnent, les deux devront être maintenues.
• Nouvelles dépendances passées inaperçues. Examinez les fichiers de paquets dans le diff avec la même attention que le code source.
• Tests qui confirment le code au lieu de le vérifier. Des assertions déduites du comportement actuel figent les erreurs existantes — voir Couverture de tests du code IA.
• Modifications trop larges. Si des fichiers étrangers à la tâche ont été touchés au passage, ce n'est pas un rangement, mais un effet de bord non vérifié.

Comment une revue de code IA doit-elle se dérouler ?

En quatre étapes, les deux premières étant automatiques et l'humain n'intervenant qu'à la troisième.

• Étape 1 — La machine écarte l'évident. Mise en forme, analyse statique, règles de sécurité, contrôle des dépendances et des licences, exécution des tests. Tout ce qu'un outil peut décider ne doit pas coûter de temps à un humain.
• Étape 2 — Vérifier le périmètre. Le diff correspond-il à la tâche ? Les modifications trop larges sont renvoyées avant que quiconque ne les lise. Cette règle économise plus de temps de revue que toute autre.
• Étape 3 — L'humain vérifie l'intention. La modification résout-elle le problème posé ? S'intègre-t-elle à l'architecture ? Cela existe-t-il déjà ailleurs ? Les droits d'accès et les cas d'erreur ont-ils été pris en compte ?
• Étape 4 — Preuve plutôt que promesse. La validation s'accompagne de la sortie de l'exécution des tests, non de l'affirmation qu'elle a eu lieu.

Une IA peut-elle reprendre la code review ?

Comme première instance, oui ; comme dernière, non — pour une raison structurelle.

Les relecteurs assistés par IA sont bons pour ce qui se reconnaît dans le code lui-même : schémas, incohérences, problèmes de sécurité évidents, gestion des erreurs manquante. Ils sont peu fiables sur la seule question qui compte vraiment : est-ce le bon comportement ? Cette question ne trouve pas sa réponse dans le code, mais uniquement dans la connaissance de ce à quoi sert le logiciel.

S'y ajoute un raisonnement circulaire facile à négliger : lorsque le même modèle écrit d'abord puis vérifie, il partage les deux fois les mêmes angles morts. Un second modèle aide un peu, mais ne remplace pas la personne qui connaît le problème métier.

Combien de temps une revue doit-elle coûter ?

Moins qu'aujourd'hui, si les étapes 1 et 2 sont réellement automatiques. Dans la Stack Overflow Developer Survey 2025, 45 % des personnes interrogées ont indiqué perdre un temps considérable à déboguer du code d'IA. Une partie de ce temps est du temps de revue dépensé au mauvais endroit : des humains vérifient la mise en forme et le style pendant que la faille d'autorisation passe à travers.

La règle empirique fiable est la suivante : ce qu'un outil peut décider, aucun humain ne le décide. Ce que seul un humain peut décider, aucun outil ne le décide. Tout le reste est du gaspillage d'un côté et du risque de l'autre.

Questions fréquentes sur la code review

Dois-je indiquer que du code a été produit avec l'IA ?

Il n'existe pas, en l'état actuel, d'obligation légale générale à cet égard. Pour la revue, l'information est néanmoins utile : elle oriente ce que l'on cherche. De nombreuses équipes la traitent par un marquage dans la pull request plutôt que par une règle.

Comment traiter de très grosses modifications générées ?

Les renvoyer et les faire découper. Un diff trop gros pour être lu n'est pas examiné plus soigneusement parce qu'il est urgent : il est seulement examiné plus superficiellement, sans que personne ne le dise.

Une revue par une seule personne suffit-elle ?

Pour la plupart des modifications, oui. Pour l'authentification, le paiement, les modifications de schéma et le déploiement, une seconde paire d'yeux est l'assurance la plus avantageuse.

Et si personne dans l'équipe ne comprend le code généré ?

Alors c'est là le constat, et non un obstacle au constat. Un code que personne ne comprend n'est pas maintenable, quelle que soit sa justesse, et ne devrait pas être fusionné.

Un humain qui vérifie la mise en forme est un linter acheté à prix d'or. Code Guardian avance les contrôles automatiques — un audit juste après la modification, selon des niveaux fixes comme la logique, la redondance et la sécurité — afin que la revue se concentre sur les questions pour lesquelles on a réellement besoin d'un humain.

Sources

• Stack Overflow Developer Survey 2025, section « AI » (66 % « almost right », 45 % de perte de temps en débogage).
• OWASP Top 10:2025, catégories A01 et A10.

Date : 27 juillet 2026. Appréciation technique d'ordre général, ne constitue pas un conseil juridique.