La revue de code est le nouveau goulot d’étranglement
La revue de code est devenue le goulot d’étranglement des équipes qui ont adopté les agents IA. Le constat est mécanique : un développeur outillé produit nettement plus de diffs qu’avant, et la capacité de relecture, elle, n’a pas bougé. Le travail ne s’accumule plus dans la colonne "à faire" mais dans la colonne "à relire".
La bonne nouvelle : ce goulot se desserre. Pas en relisant plus vite, mais en changeant ce qui arrive en revue et la façon de l’organiser.
Pourquoi la revue de code casse sous le volume IA
Trois symptômes reviennent dans toutes les équipes que nous accompagnons.
La validation mécanique. Quand quinze diffs attendent, l’approbation devient un réflexe : on parcourt, on ne lit plus, on fait confiance à la CI. Une revue qui ne refuse plus rien n’est plus une revue, et ce qui passe sans vraie lecture s’accumule ensuite en dette technique que personne n’a décidée.
La fatigue. Relire est un travail cognitif intense, et personne n’en fait six heures par jour avec attention. Les équipes qui ont doublé leur volume de code sans toucher au reste ont simplement déplacé l’épuisement de l’écriture vers la lecture.
Les seniors en point de blocage. Par prudence, beaucoup d’équipes routent tout le code généré vers leurs relecteurs les plus expérimentés. Vos meilleurs ingénieurs passent alors leurs journées à relire, le flux s’arrête à leur porte, et la vélocité promise par les agents disparaît dans la file d’attente.
Des diffs plus petits, d’abord
La mesure la plus efficace est aussi la moins spectaculaire : plafonner la taille des diffs. Une revue honnête tient sur deux à quatre cents lignes ; au-delà, elle devient une signature. Le plafond force le découpage en amont, et c’est le découpage qui rend tout le reste possible.
Les agents se prêtent bien à cette discipline : une tâche bien bornée produit un changement borné, et la définition des tâches est justement ce que vous contrôlez. Une équipe qui apprend à découper voit sa revue redevenir praticable sans rien changer d’autre.
Une pré-revue par agent avant la revue humaine
Deuxième levier : faire relire chaque diff par un agent avant qu’un humain ne l’ouvre. Chargé de la checklist de revue de l’équipe, l’agent signale les oublis évidents : cas limite absent, convention violée, duplication, test manquant. Le relecteur humain reçoit un diff déjà nettoyé et concentre son attention sur ce que la machine juge mal : le découpage, les contrats, le sens.
Deux précautions. La pré-revue ne remplace pas la revue, elle en élève le plancher. Et la checklist doit être la vôtre, versionnée dans le repo, pas un prompt générique : c’est elle qui porte vos standards.
Des niveaux de revue selon le risque
Toutes les lignes ne méritent pas la même attention. Un script interne, un test, une page de documentation peuvent passer avec une revue légère. Une migration de schéma, du code d’authentification, tout ce qui touche aux paiements ou aux données personnelles exige un relecteur humain expérimenté, voire deux. Le critère est le rayon d’impact d’une erreur, jamais l’auteur du code : un diff écrit à la main sur un chemin sensible mérite la même vigilance qu’un diff généré. La sécurité du code généré impose de toute façon de dresser cette carte des chemins sensibles.
Cette carte se décide une fois, en équipe, puis s’applique sans débat au cas par cas. C’est ce qui libère les seniors : ils cessent de tout relire pour ne relire que ce qui les exige vraiment.
Les tests relisent avant vous
Le dernier levier est le plus structurel : une bonne partie de ce qu’un relecteur humain attrape, une suite de tests solide l’attrape avant lui, sans fatigue et à chaque commit. Exiger des tests sur les lignes modifiées, c’est installer un premier relecteur qui ne bâcle jamais les régressions. Déléguer l’écriture des tests aux agents rend cette exigence tenable en volume, et des guardrails en CI la rendent non négociable : ce que le pipeline vérifie n’a plus besoin d’occuper un humain.
Le goulot de la revue signale un workflow conçu pour un autre débit, pas une fatalité de l’IA. Redessiner ce flux, plafonds de diff, pré-revue, niveaux de risque, occupe une bonne partie de nos accompagnements en ingénierie agentique : une équipe ne livre jamais plus vite que sa revue.