Ton outil de code review examine chaque PR avec le même playbook. Formatage ? Check. Conventions de nommage ? Check. CVEs connues ? Check. Qu'un dev junior ait écrit le code à 2h du mat' ou qu'un agent autonome l'ait généré à partir d'un message Slack — mêmes règles, mêmes heuristiques, même checkmark vert. C'est comme utiliser un détecteur de métaux pour trouver des fantômes. Techniquement, tu scannes. En pratique, tu ne sers à rien.

Le 18 avril, CodeRabbit a lancé l'analyse multi-repo — leur reviewer trace désormais les dépendances entre repositories. Joli tour de passe-passe. Mais voilà la question qu'il ne pose toujours pas : qui a écrit ce code ? Copilot review non plus, passé en GA avec son architecture agentique le 5 mars. Cursor 3 non plus, qui a lancé son interface agent-first le 2 avril. Rien d'autre sur le marché non plus. Pas un seul outil n'adapte sa stratégie de review selon que l'auteur est carboné ou silicié.

Ce n'est pas une nuance philosophique. C'est un angle mort structurel. La propre étude de CodeRabbit de décembre 2025 portant sur 470 PRs l'expose clairement : les PRs écrites par l'IA embarquent 75% de bugs logiques et de correction en plus tout en produisant 3x plus de problèmes de lisibilité. Mais les bugs que les reviewers IA détectent réellement — formatage, ordre des imports, nommage — ce sont les bugs que les humains font. Le code IA hallucine des appels API syntaxiquement parfaits vers des endpoints qui n'existent pas. Il écrit des suites de tests qui valident les hypothèses de l'implémentation elle-même au lieu de la spec. Il produit de la logique métier qui compile, passe tous les checks automatisés, et fait silencieusement la mauvaise chose. Le mode de défaillance et la méthode de détection ne sont même pas dans le même bâtiment.

La Cloud Security Alliance a rapporté le 4 avril que les CVEs liées aux outils de coding IA sont passées de 6 en janvier à 35 en mars — une multiplication par 6 en un trimestre. Pendant ce temps, Qodo a levé 70M$ le 30 mars pour la "vérification de code". Tout le monde construit des pattern-matchers plus rapides. Personne ne construit la seule feature qui compte : dire au reviewer quel type de code il regarde avant qu'il commence à regarder.

Voilà à quoi ressemblerait concrètement une review tenant compte de l'auteur. Une PR générée par un agent arrive. L'outil voit le tag auteur — cursor-agent, copilot-workspace, peu importe comment ton bot signe — et change complètement de playbook. Au lieu de vérifier le style, il vérifie la sémantique : est-ce que cette fonction correspond à la spec ? Est-ce que ce test vérifie le comportement ou se contente de refléter l'implémentation ? Est-ce que cet appel API référence quelque chose qui existe réellement ? C'est le fossé entre "ça a l'air correct" et "c'est correct", et en ce moment chaque outil de review sur le marché opère exclusivement du côté du "ça a l'air".

Tu peux simuler ça manuellement dès aujourd'hui. Étiquette tes PRs d'agent. Entraîne tes reviewers à ignorer les remarques de formatage quand ils voient le label et aller directement à la vérification d'intention. Demande "est-ce que ça fait ce que le ticket dit ?" au lieu de "est-ce que ça suit notre style guide ?". C'est bricolé. C'est aussi la seule approche qui fonctionne jusqu'à ce que quelqu'un livre le vrai produit.

L'ironie est savoureuse : l'industrie vient de dépenser des milliards pour faire écrire du code par l'IA et reviewer du code par l'IA, et la feature manquante est un seul champ de métadonnée. Humain ou machine ? Un booléen. Chaque reviewer sur le marché le zappe. Chaque outil note du code sans savoir qui l'a écrit — comme noter des dissertations sans savoir si c'est un étudiant ou ChatGPT qui les a rédigées. On a vu comment ça se passe à la fac.

Le prochain outil de review qui comptera ne sera pas le pattern-matcher le plus malin. Ce sera le premier assez honnête pour demander qui est l'auteur — et changer toute son approche en fonction de la réponse.