Tu fais relire ton code par Claude. Il répond « looks good, c'est propre, bien découpé ». Évidemment. C'est lui qui l'a écrit cinq minutes plus tôt. Tu viens de demander à l'auteur de noter sa propre copie, et il s'est mis un 18.
Faire relire du code par une IA, ça marche. Mais pas en posant la question à celui qui vient de l'écrire. La qualité ne vient pas d'un modèle plus malin, elle vient d'une architecture où aucun rôle ne se contrôle lui-même.
Le biais d'auto-préférence
Ce n'est pas une intuition, c'est mesuré. Un modèle qui évalue sa propre production la note plus haut que celle des autres, à qualité égale : c'est le self-preference bias, documenté par Panickssery et ses coauteurs en 2024, et il est causal, pas corrélatif. Le modèle reconnaît son propre style et le préfère.
Concrètement, ça veut dire que la boucle naïve « écris, puis relis ce que tu viens d'écrire » est cassée par construction. Tu n'obtiens pas une relecture, tu obtiens une justification. L'agent a déjà décidé que son code était bon au moment où il l'a produit ; lui redemander ne fait que confirmer.
Le relecteur aveugle
La première règle, donc : le relecteur n'est jamais l'auteur. Dans ma config, les agents de revue tournent en contexte vierge. Ils ne voient pas le prompt d'implémentation, ils ne savent pas quelles contraintes l'auteur s'est données, ils découvrent le diff comme un collègue le lundi matin. Et quand l'auteur est un modèle identifié, le relecteur est d'une famille différente, pour casser la reconnaissance de style.
Un détail compte autant que le reste : le nom du développeur n'entre jamais dans le prompt du relecteur. Pas de « ce code a été écrit par un senior », pas de « relis le travail de tel modèle ». L'identité de l'auteur est exactement l'information qui déclenche le biais. On la retire de la table.
Pas de finding sans reçu
Le deuxième piège est l'inverse du premier. Un relecteur IA, surtout en contexte vierge, a tendance à sur-signaler : il invente des problèmes pour avoir l'air utile, il flague des « failles » qui n'en sont pas. Une revue qui crie au loup à chaque ligne ne vaut pas mieux qu'une revue complaisante : dans les deux cas, tu cesses de l'écouter.
D'où la règle du reçu. Tout finding doit citer un fichier:ligne et passer une vérification avant d'être remonté : un grep qui prouve l'occurrence, une exécution en sandbox, un test qui échoue, un traçage du flux de données. Un finding que personne ne peut prouver est droppé en silence, sans débat.
Finding : "appel SQL non paramétré, risque d'injection"
→ reçu exigé : grep du flux user-input → requête
→ si la valeur est une constante du code : droppé
→ si elle vient de la requête HTTP : gardé, avec la ligneLa preuve passe avant le jugement. Le relecteur n'a pas le droit de te déranger pour une intuition.
Le panel adverse
Pour les findings critiques, ceux qui bloqueraient un merge, j'ajoute une dernière couche : un panel de sceptiques indépendants dont la consigne n'est pas de confirmer, mais de réfuter. Chacun reçoit le finding et essaie de le démolir : « voici pourquoi ce n'est pas un bug ». S'il faut une majorité pour garder le finding, les fausses alertes plausibles ne survivent pas. Celles qui restent ont encaissé une tentative de démolition.
C'est l'inverse exact de la boucle naïve. Au lieu d'un modèle qui cherche à avoir raison, plusieurs qui cherchent à se contredire. La vérité qui sort de là a été attaquée, pas auto-proclamée.
La séparation des pouvoirs
Mis bout à bout, ça donne une équipe d'agents où les rôles ne se recouvrent jamais. Celui qui écrit le code n'est pas celui qui écrit les tests, qui ne sont écrits que depuis la spec, pas depuis le code. Celui qui relit n'a pas écrit. Et avant même qu'un humain ou un LLM ne donne un avis, un gate objectif (build, lint, tests) doit être vert : le jugement du modèle ne passe qu'après la machine, jamais à sa place.
Ce n'est pas de la défiance gratuite envers l'IA. C'est le même principe qui régit une rédaction, une compta, une justice : on ne laisse personne valider son propre travail, parce que personne n'est un bon juge de soi. Les LLM, qui ont un biais d'auto-préférence prouvé, encore moins que les autres.
Conclusion
La tentation, avec un modèle qui code bien, c'est de lui confier tout le cycle : écris, teste, relis, valide. C'est précisément ce qu'il ne faut pas faire, parce que chacune de ces étapes corrige la précédente, et qu'un correcteur qui se corrige lui-même ne corrige rien. La qualité d'une revue IA ne se mesure pas à l'intelligence du modèle. Elle se mesure au nombre de fois où on l'empêche de se noter lui-même.