Revue de code IA : relire ce qu'on n'a plus le temps de lire

Votre équipe produit deux ou trois fois plus de code qu'il y a un an. Et vos meilleurs développeurs passent leurs journées à le relire. Pas à concevoir, pas à trancher : à lire des diffs, ces listes de lignes ajoutées et supprimées qu'une pull request soumet à validation, écrits par une machine qui ne fatigue jamais. La productivité affichée a grimpé. Le temps de mise en production, lui, n'a pas bougé, parce que le goulot a changé d'adresse.

La revue de code IA est devenue le sujet douloureux des CTO en 2026, et pour une raison simple : les outils qu'on leur vend accélèrent celui qui écrit, pas celui qui vérifie. Cet article décrit comment relire ce qu'on n'a plus le temps de lire. Pas en lisant plus vite, mais en changeant ce qu'on lit, qui le lit, et dans quel ordre.

Pourquoi la révision de code est devenue le goulot

Chez Hones, en début d'année, nous avons posé la question à notre propre équipe : combien de temps passez-vous à relire du code que vous n'avez pas écrit ? La réponse était la majorité de la semaine. Nos agents produisaient vite, et plutôt bien. Et nous vérifiions tout, parce que le jour où ça casse chez un client, c'est nous qu'on appelle, pas le modèle. Nous étions devenus les relecteurs de notre propre machine.

Ce n'est pas une situation propre à une petite équipe de conseil. Dès que l'IA écrit vraiment, c'est-à-dire dès qu'elle produit des fonctionnalités entières et pas des complétions de lignes, la contrainte quitte l'écriture. Un modèle génère en une heure ce qu'un humain lit en une journée. La confiance suit la pente inverse : en un an, la part des développeurs qui disent faire confiance au code produit par l'IA est passée de 40 % à 29 % selon Stack Overflow. On relit davantage parce qu'on se méfie davantage, et on se méfie davantage parce que personne n'a le temps de tout relire.

Trois options, deux impasses

Devant ce constat, nous avions trois options, et toute équipe qui industrialise sa production avec des agents les retrouve.

Tout relire. On garde la qualité, et on produit au rythme d'un humain qui lit. Les agents n'ont servi à rien, sinon à déplacer la fatigue.

Ne plus relire, et croiser les doigts. C'est l'option que beaucoup d'équipes prennent sans l'avoir décidée, par épuisement. Elle se paie plus tard : une équipe que nous connaissons a vu une faille d'autorisation réintroduite en série dans du code neuf, parce que rien dans la chaîne ne s'arrêtait (nous l'avons racontée ici, et l'étude de cas complète suivra).

Ou changer ce qu'on appelle relire. C'est la troisième option, et c'est la seule qui tienne. Elle repose sur une idée que l'industrie a comprise il y a soixante-dix ans : le contrôle qualité ne se fait pas en bout de chaîne par une inspection finale, il se construit dans le process, par étapes, du moins cher au plus cher.

Les trois disciplines de revue, dans cet ordre

Une revue de code IA qui tient se compose de trois disciplines, et l'ordre n'est pas négociable : le contrôle le moins cher passe en premier, le plus cher ne voit que ce qui a survécu aux deux autres. Inverser l'ordre, c'est faire relire par un senior ce qu'un test aurait rejeté en trois secondes.

La machine d'abord : ce qui bloque sans discuter

Tests automatisés, vérification des types, lint (l'outil qui applique les conventions d'écriture), analyse de sécurité statique. Tout ce qui rend un verdict binaire, passe ou ne passe pas, et qui bloque le merge, c'est-à-dire l'intégration du code dans la branche principale, quand il échoue. C'est l'équivalent de l'andon des usines Toyota, la corde qui arrête la ligne au premier défaut.

L'erreur classique n'est pas d'en manquer, c'est de les laisser consultatifs. Un test qui échoue sans bloquer, un lint qu'on peut ignorer, une convention écrite dans le wiki mais vérifiée par personne : tout cela est de la documentation morte. Un agent ne lit pas votre wiki. Une règle qui n'est pas exécutable n'existe pas pour lui. La première semaine de travail sur la revue consiste souvent à rendre bloquant ce qui existait déjà en option.

L'agent tiers ensuite : jamais d'auto-évaluation

Un second agent relit le diff et livre une synthèse priorisée : quoi regarder, dans quel ordre, et pourquoi. Il attrape ce que la machine déterministe ne voit pas, un choix d'architecture discutable, une duplication, un écart avec la spécification.

La règle qui fait tout : ce n'est pas le modèle qui a produit qui juge. Idéalement, ce n'est même pas le même modèle. Un modèle qui relit sa propre sortie y retrouve ses propres angles morts et les valide avec la même assurance qu'il les a créés. La mission première de cet agent est d'éviter la dérive silencieuse, celle qu'aucun test ne détecte et qu'aucun humain n'a le temps de lire : le code qui marche, passe les tests, et rend la base un peu plus complexe à chaque merge. La CMU a mesuré +41 % de complexité et GitClear ×4 de duplication là où l'IA produit sans ce filet.

L'humain enfin : il juge, il ne refait pas

Le relecteur humain lit la synthèse, va sonder les endroits qu'elle désigne, et signe le merge. Il ne relit pas le diff ligne à ligne. Relire tout, c'est payer deux fois le même travail et redevenir le goulot qu'on cherchait à supprimer.

Son temps se concentre sur deux choses. Le jugement : est-ce que ce qui a été construit correspond à ce qui a été demandé, et est-ce qu'on veut de ça dans le produit ? Et le sensible, où la revue humaine reste systématique quel que soit le niveau de confiance : authentification, gestion des droits, données personnelles, tout ce qui touche à l'argent. C'est là que la machine a le plus de chances de reproduire un pattern fragile avec l'air le plus légitime du monde.

Ce qui circule entre les étapes : l'unité de revue n'est plus le diff

Les trois disciplines ne forment une ligne que si quelque chose de précis passe de l'une à l'autre. Pas une conversation entre agents, pas un fil de commentaires : un artefact dont on sait qui le produit et qui le lit.

Ce découpage a une conséquence que beaucoup de CTO trouvent inconfortable au début : l'unité de revue n'est plus le diff, c'est la spécification. Dans un atelier, on relisait les lignes parce qu'un humain les avait écrites et qu'un autre humain allait les maintenir. Dans une usine logicielle, on juge d'abord si ce qui a été construit correspond à ce qui a été validé en amont, puis on intègre par petits incréments contrôlés. Le diff reste disponible pour qui veut sonder, mais il n'est plus l'objet qu'on lit en entier.

C'est aussi ce qui rend chaque maillon remplaçable. Changer de modèle de revue, ajouter une vérification, remplacer le relecteur de garde : le reste de la ligne ne bouge pas, parce que ce que chaque étape attend et livre est écrit. L'anatomie complète de cette ligne, production et revue, est décrite dans notre article de référence sur l'AI Software Factory.

Calibrer la revue de code par l' ia : quand alléger, quand serrer

Nous avons appris ça à nos dépens. Notre première usine, au printemps, était un modèle de prudence : chaque poste rendait des comptes au suivant, un humain validait entre deux étapes, et les agents n'avaient le droit de toucher à rien sans demander. Sur le papier, c'était la revue la plus sûre qu'on puisse imaginer. En pratique, les agents passaient leur temps à solliciter des autorisations, les comptes-rendus s'empilaient, et quand quelque chose coinçait, le volume d'explications rendait la cause introuvable. Au bout de quatre jours, pas une ligne n'était sortie. Nous avions obtenu une machine aussi lente qu'une équipe, et moins lisible.

Nous sommes repartis de l'autre bout. Une étape à la fois, déclenchée à la main, observée jusqu'à savoir exactement ce qu'elle produisait, puis seulement automatisée. Le nombre de contrôles a baissé. La compréhension de ce qui se passait dans la chaîne a augmenté. C'est ce qui nous a fait changer de définition de la confiance : on ne la fabrique pas en multipliant les validations, on la gagne en rendant lisible ce que la machine fait et pourquoi. Une revue de code IA qu'on ne comprend pas ne rassure personne, même avec dix verrous.

La relecture s'allège avec la confiance, jamais sur le sensible

Le calibrage découle de là. Au départ, la revue humaine sonde large, parce qu'on apprend ce que la machine fait bien et mal sur cette base de code. À mesure que les vérifications déterministes se densifient et que l'agent de revue prouve qu'il attrape ce qu'il doit attraper, le relecteur humain lit moins et juge plus. Sur les zones sensibles, authentification, droits, données personnelles, le niveau ne descend jamais, quelle que soit la confiance acquise ailleurs.

Deux signaux disent qu'on s'est trompé de réglage, et ils sont symétriques :

• une revue qui ne rejette plus rien. Si aucun merge n'est refusé depuis trois semaines, la ligne ne contrôle plus, elle tamponne. Soit la machine est devenue parfaite, soit plus personne ne regarde ;
• une file qui s'allonge. Si les pull requests attendent des jours avant signature, le contrôle est redevenu le goulot, et l'équipe finira par contourner.

Entre les deux, le réglage juste n'est pas un point fixe. Il bouge avec la base de code, avec les modèles, avec l'équipe. Nous le revoyons tous les trimestres, et il a changé à chaque fois.

Ce que le développeur fait du temps rendu

Quand la ligne tient, un senior qui passait la majorité de sa semaine à lire des diffs en passe une fraction à signer des merges. La question qui vient ensuite n'est pas technique : qu'est-ce qu'il fait du reste ?

Chez nous, ce temps est parti vers l'amont. Écrire des spécifications plus précises, parce qu'une spec floue se paie désormais en code produit très vite et très à côté. Resserrer les vérifications déterministes, parce que chaque règle rendue exécutable est une relecture de moins pour toujours. Et décider, plus souvent qu'avant, qu'une fonctionnalité ne vaut pas la peine d'être construite. Le goulot a continué de remonter. Il est maintenant dans le choix de ce qu'on demande à la machine, et celui-là, personne n'a encore trouvé comment le déléguer.

FAQ

Peut-on confier la revue de code à une IA ?

Une partie, oui, à deux conditions. L'agent qui relit n'est pas celui qui a produit, et de préférence pas le même modèle. Et il ne remplace pas la revue humaine, il la prépare : il livre une synthèse priorisée que le relecteur sonde, et c'est toujours un humain qui signe le merge. Un agent qui s'auto-évalue ou qui valide seul en production n'est pas une revue, c'est un pipeline sans point d'arrêt.

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

Non, et c'est l'erreur qui fait de la revue le goulot. Les vérifications déterministes (tests, types, lint, analyse de sécurité) traitent le volume et bloquent le merge quand elles échouent. L'agent de revue désigne où regarder. Le relecteur humain sonde ce qui est désigné et juge si le résultat correspond à la spécification. La seule exception est le sensible : authentification, droits, données personnelles, paiement. Là, la relecture humaine reste systématique.

Quel modèle utiliser pour la revue de code IA ?

Un modèle différent de celui qui produit, et plutôt capable que rapide : la revue est l'étape où le jugement compte plus que la vitesse. Dans une AI Software Factory, le modèle est volontairement placé à l'extérieur du système pour être remplacé sans rien démonter ; le choix du modèle de revue se revoit donc régulièrement, sans toucher au reste de la ligne.

Comment savoir si notre revue de code est trop légère, ou trop lourde ?

Deux signaux symétriques. Trop légère : aucun merge n'est refusé depuis des semaines, la revue tamponne au lieu de contrôler. Trop lourde : les pull requests attendent des jours avant signature, et l'équipe commence à contourner. Entre les deux, le réglage juste évolue avec la base de code et les modèles ; une revue trimestrielle du calibrage est un minimum.