Meta détaille Catching JiTTests : des tests conçus pour échouer sur chaque modification, rôle clé revendiqué dans l’interception de 74 défauts graves de confidentialité au premier semestre

Le 29 octobre 2026, l’équipe d’ingénierie de Meta a décrit le fonctionnement en production de « Catching JiTTests » (tests de capture juste-à-temps) : un grand modèle de langage génère, pour chaque modification de code proposée, des tests exécutables conçus pour échouer, et leur échec révèle un défaut introduit par la modification. Selon Meta, 589 ingénieurs avaient interagi avec le système au moment de la rédaction, et les ingénieurs ont rapporté un taux de vrais positifs de 60 %. Au premier semestre 2026, il aurait joué un rôle clé pour intercepter 74 défauts graves (SEV) de confidentialité au stade du diff.

Meta distingue cette approche de la revue de code par IA courante. La plupart des méthodes à base de LLM lisent le code comme le ferait un relecteur humain et jugent par expérience où une erreur peut se cacher. Catching JiTTests génère au contraire des tests qui démontrent une différence de comportement concrète introduite par la modification. Meta reconnaît que cela demande plus d’étapes de calcul, mais affirme que la méthode attrape des classes de défauts que les revues par LLM ou par agent peuvent laisser passer. La difficulté tient à l’échelle : avec des centaines de millions de lignes de code en évolution, les tests comprennent des « captures fortes » qui révèlent de vrais défauts et des « captures faibles » qui peuvent être de faux positifs, et le système doit les distinguer automatiquement sans ralentir les ingénieurs.

Le système fonctionne en cinq étapes. L’étape 1 est le ciblage et le déclenchement : il tourne la nuit sur la capacité inutilisée et ne traite que les diffs soumis la veille et jugés risqués, grâce à un mécanisme proche du Diff Risk Score, entraîné sur des modifications passées. L’étape 2 comprend deux flux de génération de tests en parallèle. Le flux « dodgy diff » traite chaque diff comme un mutant, une version avec un défaut, et utilise la génération de tests guidée par la mutation pour produire des tests qui séparent le comportement du diff de celui de son parent, sans déduire d’intention ; le but est d’élargir le réservoir de captures faibles. Le flux « intent-aware » demande d’abord à un LLM de déduire l’intention du diff à partir des changements, du titre et du résumé, puis de décrire les risques, c’est-à-dire les façons dont l’implémentation de cette intention pourrait mal tourner. Il construit des mutants à partir de ces risques et génère des tests pour tuer chacun. Ces tests sont ensuite exécutés sur le vrai diff, et ceux qui échouent sont retenus comme captures faibles.

L’étape 3 est l’ensemble « LLM-as-Judge » : plusieurs modèles de pointe examinent le code du test, le résultat d’exécution (code d’échec, message, trace), la différence entre parent et enfant et l’intention déduite, et jugent s’il s’agit plutôt d’un faux positif ou d’un vrai défaut. L’étape 4 est RubFake, un évaluateur à règles qui donne des jugements vérifiés et déterministes pour compenser le caractère non déterministe et difficile à vérifier des jugements des LLM ; ensemble, ils classent les captures faibles. L’étape 5 est le « human-on-the-loop » : le système décide d’après le classement s’il faut contacter un ingénieur, et les ingénieurs fixent des critères et examinent les résultats de façon agrégée au lieu de superviser chaque sortie.

Plusieurs chiffres demandent qu’on garde leurs limites en tête. Les 589 ingénieurs représentent 64 % des sollicitations de Meta, mais l’article ne donne pas le nombre total de sollicitations. Le taux de 60 % de vrais positifs est celui rapporté par les ingénieurs. Catching JiTTests aurait joué un rôle clé dans l’interception des 74 défauts graves de confidentialité, et l’article le place dans la même phrase qu’une baisse de 20 % des SEV de confidentialité sur la période, mais il ne donne aucune base de comparaison et ne dit pas que le système en est la seule cause. Les tableaux comparatifs et le graphique d’impact sont des images dans l’original, et aucune de leurs valeurs n’est utilisée ici.

Ce que d’autres équipes peuvent retenir, c’est la forme du dispositif : choisir quelques diffs risqués avec un score de risque, générer des tests qui prouvent une différence de comportement, filtrer les faux positifs par des modèles et par des règles, et ne solliciter une personne que lorsqu’un cas est bien classé. Les limites sont tout aussi nettes : les chiffres viennent du déploiement de Meta, le coût est un calcul supplémentaire, et les résultats portent sur des défauts de confidentialité, donc ne se généralisent pas à tous les types de défauts.