La revue de code exige désormais une posture différente. Lorsque la majeure partie du code d'une pull request était écrite par la personne qui la soumettait, le rôle du relecteur consistait à détecter les erreurs et à partager les connaissances. Lorsqu'une grande partie est générée par un modèle, le relecteur doit également vérifier que l'auteur comprend réellement ce qu'il est en train de fusionner.
Pourquoi la nature du problème a changé
Les modèles d'IA produisent du code syntaxiquement propre, bien formaté et souvent plausible au premier coup d'œil. La surface semble aboutie. Les bugs, lorsqu'ils existent, ont tendance à se situer dans la logique, les cas limites ou les hypothèses d'intégration, plutôt que dans des erreurs de syntaxe évidentes. Cela signifie que les signaux visuels sur lesquels les relecteurs avaient l'habitude de s'appuyer, un formatage négligé, des patterns inhabituels, des copier-coller évidents, sont moins utiles. Quelque chose peut sembler correct et être pourtant erroné d'une façon qui compte.
Il y a aussi un problème de volume. Les ingénieurs utilisant des outils d'IA peuvent produire plus de code plus rapidement. Les pull requests sont de plus en plus volumineuses et arrivent plus fréquemment. Relire 800 lignes de code qu'une seule personne a écrites en deux jours est différent de relire 800 lignes qu'un modèle a produites en vingt minutes, car dans le second cas, rien ne garantit que l'auteur les a toutes parcourues.
Ce que les relecteurs vérifient désormais
Le changement concret est que les relecteurs vérifient de plus en plus la compréhension de l'auteur, et pas seulement la correction du code. Les questions utiles lors d'une revue incluent désormais :
- L'auteur peut-il expliquer un bloc précis si on lui pose la question ?
- La couverture de tests reflète-t-elle une compréhension des cas limites, ou seulement du chemin nominal ?
- Y a-t-il des patterns qui semblent avoir été acceptés tels quels depuis le modèle, sans modification ?
- La gestion des erreurs est-elle cohérente avec ce système, ou s'agit-il d'un code générique standard ?
Il ne s'agit pas d'affirmer que le code généré par l'IA est en moyenne moins bon. Il s'agit d'affirmer que le profil de risque est différent, et que les processus de revue conçus pour du code écrit par des humains ne détectent pas automatiquement les modes de défaillance du code généré par un modèle.
Pour en savoir plus sur ce qu'il convient de vérifier lorsqu'on travaille avec du code qu'on n'a pas écrit, voir comment relire du code généré par l'IA et tester un logiciel qu'on n'a pas conçu.
La dette technique s'accumule différemment
Avec du code écrit par des humains, la dette technique se constitue généralement de façon progressive. Des raccourcis sont pris sous la pression du temps ; la personne qui les a pris sait généralement où se trouvent les problèmes. Avec du code généré par l'IA et accepté sans compréhension complète, la dette peut paraître structurellement solide alors que les hypothèses sous-jacentes sont erronées. Le refactoriser plus tard est plus difficile, car personne dans l'équipe ne dispose d'un modèle mental clair de la raison pour laquelle il a été écrit ainsi.
Cela concerne surtout les codebases où plusieurs ingénieurs utilisent chacun des outils d'IA de leur côté et fusionnent du code que les autres n'ont pas lu de près. Au final, le code devient difficile à comprendre dans son ensemble. Aucun fichier pris seul n'est forcément mauvais, mais personne n'a vraiment construit le modèle mental de leur assemblage.
Ce qui n'a pas changé
L'objectif de la revue reste le même : une compréhension partagée de ce qui est en production et la certitude que le système se comporte correctement. Les moyens d'atteindre cet objectif ont évolué. Demander aux auteurs d'expliquer la logique à l'oral, exiger des explications sur les décisions de conception non évidentes, et être plus rigoureux sur la qualité des tests sont des pratiques qui étaient déjà bonnes auparavant et qui sont aujourd'hui encore plus importantes.
Certaines équipes ont répondu en ajoutant des outils d'IA du côté de la revue également, en utilisant des modèles pour signaler les problèmes potentiels avant la revue humaine. Cela peut réduire le bruit, mais ne supprime pas la nécessité d'un relecteur humain qui comprend le système.
Ce que nous évaluons
Les deux sessions de comment nous sélectionnons sont directement pertinentes ici. La session 1 établit si un ingénieur est capable d'identifier de vrais problèmes sans assistance, grâce à un débogage structuré et une compréhension technique réelle de la stack. La session 2 teste les mêmes instincts dans des conditions différentes : s'ils détectent des API hallucinées ou une logique subtilement erronée dans les sorties générées avant leur mise en production, et s'ils sont capables d'expliquer une modification qu'ils n'ont pas écrite. Les ingénieurs qui considèrent la vérification des sorties d'IA comme facultative ont tendance à rendre la revue de code formelle plutôt qu'utile.
Réponses courtes
Le code généré par l'IA est-il plus difficile à relire que le code écrit par un humain ?
Il est différent à relire, pas nécessairement plus difficile en termes de volume. La surface est souvent propre, ce qui peut masquer des erreurs de logique ou des hypothèses incorrectes. Le principal défi est que les relecteurs ne peuvent plus supposer que l'auteur comprend pleinement chaque ligne qu'il a soumise.
Une génération de code plus rapide entraîne-t-elle davantage de dette technique ?
Cela peut arriver, si les pratiques de revue ne suivent pas le rythme. Lorsque le code est généré et accepté sans que l'auteur l'ait parcouru, l'équipe accumule des hypothèses que personne n'a vérifiées. Cela crée une dette plus difficile à trouver et à corriger que celle accumulée consciemment sous la pression du temps.
Les équipes devraient-elles intégrer des outils d'IA dans le processus de revue lui-même ?
Cela peut aider pour les vérifications de surface, mais ne remplace pas un relecteur qui comprend le système. La revue automatisée détecte certains problèmes ; elle ne vérifie pas que l'auteur a compris ce qu'il a fusionné ni que la conception s'intègre à la base de code globale.
