L’architecture de diffox : 17 agents spécialisés, quatre étapes
diffox répartit une revue de code par IA entre 17 agents spécialisés. Chaque constat cite le code ; la citation est vérifiée par du code, pas par un modèle.
En bref. diffox est un outil de revue de code par IA qui examine les pull requests sur GitHub. Chaque review passe par quatre étapes ; cet article explique ce qui se passe à chacune, et pourquoi. Nous avons mesuré les résultats dans les deux premiers articles : diffox ultra est premier des 23 outils du benchmark de Martian ; une review de diffox coûte $0,41.
- Contexte et orientation. diffox rassemble le changement, ses fichiers avant et après, et les règles que vous avez écrites. La nature du changement et son risque déterminent quels agents spécialisés le liront.
- Analyse spécialisée. L’équipe compte 17 agents spécialisés. Chacun cherche une seule chose et appuie ce qu’il trouve sur une citation exacte du code.
- Vérification des preuves. C’est du code, et non un modèle, qui contrôle chaque constat. Le code cité est-il vraiment dans ce fichier ? Le constat porte-t-il sur ce que cette pull request a changé ? Le même problème a-t-il été signalé deux fois ?
- Choisir et publier. Chaque constat a une classe : Critique, Avertissement ou Suggestion. La pull request reçoit ce que vous devez corriger : les constats critiques et les avertissements. Les suggestions ne se perdent pas, elles attendent sur la page Constats. Une review ne bloque jamais un merge.
Comment se déroule une review
Pour examiner un changement, le plus rapide est de demander à un modèle : « Y a-t-il un bug ici ? » diffox ne procède pas ainsi. Il fait lire le même changement par plusieurs agents spécialisés : l’un traque les erreurs de logique, un autre les problèmes de concurrence, un troisième regarde si un test teste vraiment quelque chose. Chaque agent a une mission étroite et bien définie. Deux étapes suivent. Des vérifications rattachent chaque constat au fichier lui-même plutôt qu’à la parole du modèle, puis une sélection décide de ce qui est publié.
Nous avons mesuré ce que donne cette architecture dans le premier article : sur le benchmark de Martian (50 pull requests), diffox ultra a détecté 119 des 158 bugs connus et diffox 106. Le coût est détaillé dans le deuxième article. Voici maintenant les quatre étapes, dans l’ordre.
Ce que voient les agents, et lesquels interviennent
Une review démarre sans que vous ayez à la demander : à l’ouverture d’une pull request et à chaque nouveau push. diffox publie d’abord sur la pull request un commentaire indiquant que la review a commencé ; une fois la review terminée, ce même commentaire affiche le résultat. Avant que les agents spécialisés voient le changement, deux questions sont tranchées : que leur présenter, et lesquels appeler.
Chacune des quatre parties répond à une question différente. Le diff dit ce qui a changé. Les fichiers, avant et après, montrent où se situe le changement. Le titre, la description et les messages de commit disent ce que l’auteur voulait faire. Et AGENTS.md ou CLAUDE.md, si votre dépôt en contient un, indique les règles que suit votre équipe.
Le fichier de règles est lu sur la branche dans laquelle la pull request sera fusionnée, pas sur la branche de la pull request elle-même. Une pull request ne peut donc pas modifier les règles de sa propre review : un changement du fichier de règles ne s’applique qu’une fois fusionné. Les fichiers de verrouillage, le code tiers comme vendor/ et node_modules/, et les fichiers minifiés ne sont pas examinés.
Vient ensuite l’orientation. diffox détermine la nature du changement (correction de bug, nouvelle fonctionnalité, refactoring, migration, test…) et évalue son risque : combien de fichiers il touche, s’il affecte d’autres fichiers, s’il est accompagné de tests. Certains agents lisent tous les changements ; d’autres n’interviennent que si leur sujet est concerné. Si aucune ligne n’a été supprimée, l’agent qui cherche les comportements retirés n’a rien à faire. Si aucun test n’a été touché, l’agent qui cherche les tests vides non plus.
Quand un nouveau push arrive sur la même pull request, diffox ne lit que le nouveau changement.
Chaque agent spécialisé cherche une seule chose
À la deuxième étape, les agents spécialisés lisent le changement. L’équipe compte 17 agents, répartis en deux types selon ce qu’ils cherchent.
12 agents cherchent des bugs : du code qui donne un résultat faux à l’exécution. 5 cherchent des contradictions : des endroits où le code ne concorde pas avec le commentaire, le test ou le document qui l’accompagne. Chaque agent a ses propres consignes ; tous lisent le même changement et le même contexte.
Pour être pris en compte, un constat doit dire trois choses : ce qu’il affirme, ce qui tourne mal et dans quelle situation, et le code sur lequel repose l’affirmation, cité mot pour mot. Un constat de contradiction apporte deux citations : le code et le texte qui le contredit. S’il en manque une, le constat n’est pas pris en compte.
Les agents ne donnent pas de numéro de ligne. Les modèles de langage ne comptent pas les lignes de façon fiable ; diffox demande donc au modèle la citation plutôt que le numéro, puis trouve la ligne lui-même en cherchant la citation dans le fichier. Ainsi, qu’un constat tombe sous la bonne ligne ne dépend pas de ce que dit le modèle.
Des détecteurs à base de règles tournent en parallèle des agents spécialisés. Ils n’utilisent aucun modèle et cherchent avec des règles exactes : un identifiant qui a fuité dans le code, une méthode définie deux fois dans la même classe, une branche qui ne peut jamais être atteinte.
Toute l’équipe, et ce que cherche chaque agent :
| Agent | Type | Ce qu’il cherche |
|---|---|---|
| ➗ Logic | Bug | Traque les décalages d'une unité, les conditions aux limites, les conditions inversées, les mauvais opérateurs et les contrats de fonction non respectés. |
| ⭕ Null Path | Bug | Traque une valeur qui peut être absente là où le code la lit comme présente : un None, un null ou un résultat vide utilisé comme s'il contenait quelque chose. |
| 🔀 Race | Bug | Traque les situations de concurrence, les interblocages, les séquences lecture-modification-écriture non atomiques, l'état partagé non protégé et les problèmes d'ordre des verrous. |
| 🔇 Silent Failure | Bug | Traque les exceptions avalées, les catch trop larges, les valeurs de retour ignorées et les faux replis qui masquent les erreurs. |
| 💾 Data Integrity | Bug | Traque les schémas incohérents, les migrations non rétrocompatibles, les écritures perdues et les opérations non idempotentes. |
| 🔓 Security | Bug | Traque les injections, l'authentification et l'autorisation cassées, les fuites de secrets, les SSRF et la désérialisation ou la gestion de chemins non sûres. |
| 💥 Blast Radius | Bug | Traque les appelants cassés, les surfaces d'API modifiées et les changements de signature ou de type de retour qui cassent d'autres fichiers du changement. |
| 🐛 Regression | Bug | Traque le retour de motifs de bugs déjà corrigés dans ces fichiers. |
| 🥅 Safety Net | Bug | Traque une rupture de contrat entre le changement et les tests qui le couvrent : un comportement vérifié par un test et modifié par ce diff sans mise à jour du test. |
| 🔥 Hot Path | Bug | Traque les requêtes N+1, les allocations inutiles sur les hot paths et les régressions algorithmiques. |
| 🏷️ Naming | Bug | Ne traque que quatre cas démontrables : une faute de frappe dans un identifiant, contredite par un voisin du même diff, deux orthographes d'une même clé, un libellé qui nomme la mauvaise chose, un test nommé d'après ce qu'il n'exécute jamais. |
| 📐 House Rules | Bug | Traque les lignes de ce diff qui enfreignent les règles de review que le dépôt a écrites lui-même dans AGENTS.md ou CLAUDE.md, s'il en a. |
| 💬 Broken Promise | Contradiction | Traque le texte qui fait une promesse que le code voisin ne tient pas : un commentaire, une docstring ou un README qui annonce ce que le code ne fait pas. |
| 🪦 Dead Code | Contradiction | Traque le code dont l'effet ne peut pas être observé : inaccessible après ce changement, ou dupliqué. |
| 📜 Stale Contract | Contradiction | Traque une déclaration modifiée ici alors que du code visible repose encore sur son ancienne forme. |
| 🗑️ Lost Behaviour | Contradiction | Traque un comportement que ce changement a supprimé sans le remplacer, et demande si quelque chose en dépend encore. |
| 📭 Empty Test | Contradiction | Traque un test qui ne teste pas ce qu'il prétend tester : il passerait quoi que fasse le code. |
Le commentaire d’un constat porte le symbole et le nom de l’agent qui l’a trouvé, par exemple ➗ Logic Agent.
Comment chaque constat est vérifié sur le code
Un modèle de langage peut écrire quelque chose de convaincant et pourtant faux : il cite une ligne absente du fichier, conteste du code que cette pull request n’a pas touché, ou formule le même problème trois fois en trois phrases différentes. La troisième étape rattache donc chaque constat au fichier lui-même, et non à la parole du modèle.
Ces vérifications sont du code ordinaire, pas un appel à un modèle : la même entrée donne toujours la même réponse.
- Anchor Verifier. La citation du constat est recherchée dans le fichier. Une citation introuvable ne désigne aucune ligne. Si la ligne trouvée ne fait pas partie de ce que cette pull request a changé, le constat est hors périmètre.
- Second Witness. Les constats qui soulèvent la même objection au même endroit sont fusionnés en un seul : on ne vous signale pas deux fois le même problème. Et quand plusieurs sources désignent un même endroit, cela joue en faveur du constat.
- Verbatim Matcher. La seconde citation d’un constat de contradiction est elle aussi recherchée mot pour mot : dans le changement, les fichiers, la description de la pull request, les messages de commit et votre fichier de règles. Si le modèle prétend qu’un commentaire dit quelque chose qu’il ne dit pas, cela se voit ici.
Une autre vérification s’ajoute : un constat qui affirme qu’une valeur peut être vide est réfuté si le type de la valeur, ou un contrôle quelques lignes plus haut, l’exclut déjà.
Quels constats sont publiés
Après les vérifications, il reste une liste de candidats. La quatrième étape décide lesquels publier sur la pull request.
Attention Ranker répond à une seule question pour chaque candidat : quelle est la probabilité que ce constat soit un bug réel ? Le score tient compte de la gravité et du type du constat, du résultat des vérifications de preuves, et du fait que d’autres constats désignent ou non le même endroit. Parmi des constats situés sur des lignes voisines, seul le plus solide est publié.
Sur la pull request, vous ne voyez que ce qui doit être corrigé : les constats critiques et les avertissements. Les suggestions attendent sur la page Constats, sans réglage à faire de votre côté.
Nous avons mesuré les chiffres ci-dessous sur le même benchmark, avec trois réglages de sensibilité. Ce réglage était un seuil appliqué à un score. Élevée a détecté le plus de bugs. Moyenne et Faible relevaient le seuil : diffox publiait moins de constats, et il était plus sûr de ceux qu’il publiait.
| Sensibilité | diffox | diffox ultra | ||
|---|---|---|---|---|
| Bugs réels | Fausses alertes | Bugs réels | Fausses alertes | |
| Élevée | 106 | 132 | 119 | 144 |
| Moyenne | 89 | 55 | 98 | 51 |
| Faible | 59 | 19 | 70 | 19 |
Benchmark de Martian : 50 pull requests, 158 bugs connus, juge Claude Opus 4.5. Sensibilité élevée : notre exécution publique, 7 octobre 2026. Moyenne et faible : notre mesure interne sur les mêmes 50 pull requests, moyenne de 5 exécutions pour diffox ultra et de 2 pour diffox.
Rien de ce qui n’est pas publié sur la pull request n’est perdu : ces constats attendent 30 jours sur votre page Constats, dans la console, et vous pouvez publier n’importe lequel depuis cette page.
La publication comprend deux parties : un commentaire de synthèse sur la pull request et, pour chaque constat, un commentaire juste sous la ligne concernée. Quand un constat peut être corrigé, il est accompagné d’une correction suggérée que GitHub applique en un clic ; le commit est fait en votre nom. Les titres et les corrections suggérées sont rédigés après la sélection, uniquement pour les constats qui seront publiés. La review arrive dans la langue de votre équipe. La dernière ligne de la synthèse indique le prix de la review, sa durée et le commit lu.
Le statut de diffox sur une pull request ne passe jamais au rouge : c’est votre équipe qui décide de fusionner. À chaque 👍 et 👎 sur ses commentaires, diffox apprend à mieux vous connaître, vous et votre dépôt, et ses reviews s’ajustent peu à peu à votre équipe.
Ce que diffox ultra fait différemment
diffox ultra passe par les mêmes quatre étapes ; la différence se joue à la deuxième et à la quatrième. Deux modèles distincts lisent le changement, chacun menant sa propre review du début à la fin. Les deux reviews tournent en parallèle et sont publiées comme une seule. À l’étape de sélection intervient aussi un troisième modèle, un petit modèle de décision : il n’écrit aucun texte et répond par oui ou par non à des questions sur chaque constat. La sélection note les constats des deux reviews en tenant compte de ces réponses ; quand les deux modèles désignent le même endroit, cela joue en faveur du constat. Après la sélection, le modèle de décision repère les constats qui remontent à la même cause et les regroupe en un seul.
Le résultat est dans les deux premiers articles : diffox ultra a détecté 119 des 158 bugs connus et diffox 106 ; une review de diffox ultra coûte en moyenne $1,64, une review de diffox $0,41.
Questions fréquentes
Pourquoi diffox utilise-t-il des agents spécialisés ?
« Y a-t-il un bug ici ? » est une question large, et la réponse l’est tout autant. Chaque agent spécialisé cherche une seule chose et doit appuyer ce qu’il trouve sur une citation du code. On sait ainsi de quel agent vient chaque constat.
Puis-je donner mes propres règles de review à diffox ?
Oui. Les règles que vous écrivez dans AGENTS.md ou CLAUDE.md, à la racine de votre dépôt, sont lues à chaque review, et un agent dédié cherche les lignes qui les enfreignent. Elles sont lues sur la branche dans laquelle la pull request sera fusionnée : si une pull request modifie le fichier de règles, la modification s’applique une fois la pull request fusionnée.
À quoi servent les 👍 et les 👎 ?
À chaque réaction, diffox apprend à mieux vous connaître, vous et votre dépôt : il comprend ce qui compte pour vous et ce qui n’est que du bruit. Ses reviews s’ajustent peu à peu à votre équipe.
diffox bloque-t-il un merge ?
Non. Le statut de diffox sur une pull request ne passe jamais au rouge et ce n’est pas une vérification obligatoire ; votre équipe fusionne quand elle le veut.
Toute la pull request est-elle réexaminée à chaque push ?
Non. diffox examine automatiquement chaque push, mais ne lit que le nouveau changement. Après les 5 premiers push, il n’examine que lorsque vous le demandez ; vous pouvez modifier ce nombre dans la console.
Pourquoi les suggestions ne sont-elles pas publiées sur la pull request ?
Dans nos mesures, publier aussi les suggestions ajoutait des commentaires à la pull request et faisait baisser la part de bugs réels parmi eux. La pull request reçoit donc les constats critiques et les avertissements. Les suggestions ne se perdent pas : elles attendent 30 jours sur la page Constats, et vous publiez celles que vous voulez depuis cette page.
diffox conserve-t-il mon code ?
Non. diffox ne conserve pas de copie du code analysé ; la copie du dépôt est supprimée à la fin de l’analyse. Les services utilisés sont indiqués sur notre page de confidentialité.
La suite : le modèle de décision
Le quatrième article décrit le modèle de décision que diffox ultra utilisait alors à la quatrième étape, et la règle que nous avons tirée de nos mesures : Comment nous utilisons Jev en revue de code par IA.