Deux moteurs, un seul audit

Faites lire la même pull request à deux relecteurs expérimentés : vous obtenez deux listes différentes. L'un remarque que l'identifiant présent dans l'URL n'est jamais confronté à la session ; l'autre voit que la boucle de réessai laisse une connexion à la base ouverte à chaque échec. Aucun n'a tort, aucun n'est complet. Les modèles de langage se comportent de la même façon, pour la même raison : ce qu'un relecteur remarque dépend de ce qu'il a déjà vu.

L'accord est un signal

Un modèle seul vous donne sa confiance. Ce chiffre vaut quelque chose, mais il est auto-déclaré : le modèle corrige sa propre copie. Quand deux modèles entraînés par des laboratoires différents, sur des données différentes, avec des faiblesses différentes, tombent indépendamment sur la même faiblesse dans le même fichier, cet accord est une preuve venue de l'extérieur du modèle. C'est ce qu'une revue automatisée a de plus proche d'un second avis.

L'inverse compte tout autant. Un résultat signalé par un seul moteur n'est pas faux pour autant, et l'écarter reviendrait à jeter précisément les bugs qu'un relecteur seul repère bien. Il doit être rapporté et attribué, pour que vous puissiez trancher vous-même.

Là où un moteur reste muet

En pratique, les deux moteurs divergent surtout sur les classes de bugs qui demandent du raisonnement plutôt que de la reconnaissance de motifs :

• Failles de logique : une remise appliquée deux fois, une machine à états qui accepte un remboursement après un remboursement, un contrôle de propriété effectué sur le mauvais objet.
• Autorisation propre au framework : un middleware qui protège un groupe de routes mais pas le gestionnaire d'API monté à côté.
• Fuites de ressources et de mémoire : écouteurs, minuteurs et connexions ouverts à chaque requête et libérés seulement sur le chemin nominal.
• Injection de prompt cachée dans des commentaires ou des fixtures, qui se lit comme un texte anodin si on ne la cherche pas.

Comment deux rapports n'en font qu'un

La fusion est l'endroit où le second moteur se rentabilise ou double votre bruit. Les règles que nous avons retenues :

• Les résultats sont rapprochés sur ce qui identifie un bug, pas sur la formulation : sa classe CWE et le fichier où il vit.
• Une correspondance est rapportée une fois, avec la plus stricte des deux gravités, car la lecture sûre est celle sur laquelle on agit.
• On garde la rédaction exploitable par un développeur : la preuve la plus longue, le correctif concret, les étapes ordonnées.
• Un résultat corroboré passe en confiance élevée et porte le nom des deux moteurs.
• Un résultat vu par un seul moteur est conservé, marqué du moteur qui l'a trouvé.

Les deux moteurs lisent la même source en même temps : l'audit ne dure donc pas deux fois plus longtemps ; il coûte deux fois plus cher à exécuter, et c'est pourquoi il relève du plan Pro. Si le second moteur est indisponible ou renvoie quelque chose d'inutilisable, l'audit se termine avec le premier plutôt que d'échouer.

Rien de tout cela ne rend un rapport vrai. Deux moteurs peuvent s'accorder et se tromper tous les deux ; la preuve citée sous chaque résultat est là précisément pour que vous vérifiiez au lieu de croire. Ce que la corroboration vous apporte, c'est un ordre de priorité : quand cent résultats arrivent et que vous avez un après-midi, commencez par ceux que deux relecteurs indépendants ont vus.