Un modèle linguistique peut obtenir de très bons résultats sur un benchmark propre, puis échouer dans les cas ambigus qui importent réellement aux utilisateurs en environnement de production. C’est la leçon centrale présentée par GitHub dans un article rédigé par Mariko Wakabayashi et Zixiao Chen le 25 août 2026, à partir d’une expérience d’évaluation d’un système reposant sur un modèle linguistique pour contribuer à réduire les faux positifs dans GitHub secret scanning.
La détection des secrets recherche des identifiants, tels que des jetons et des clés, qui peuvent avoir été déposés dans un dépôt logiciel. Mais certaines chaînes de caractères ressemblent à des secrets sans être de véritables identifiants, ce qui pousse les développeurs à examiner des alertes ne nécessitant aucun traitement. La question de l’équipe n’était donc pas de savoir si le modèle pouvait classer une chaîne de caractères isolée, mais s’il pouvait réduire le bruit tout en conservant un niveau de rappel suffisant pour rendre sûr un flux de travail de sécurité sensible.
Commencer par la décision produit, et non par le choix du modèle
GitHub recommande de définir la décision que l’évaluation est censée étayer avant de modifier le prompt, d’ajouter du contexte ou de changer de modèle. Dans le cas de la détection des secrets, l’objectif était de réduire les faux positifs et d’améliorer la précision, tandis que le rappel servait de contrainte de sécurité. Masquer par erreur un véritable identifiant peut être plus dangereux que de demander à un développeur d’examiner une alerte supplémentaire.
En pratique, les critères d’évaluation ont été répartis en trois niveaux : un résultat principal mesurant l’utilité pour l’utilisateur, à savoir la réduction des faux positifs et la précision ; une contrainte de sécurité correspondant au rappel ; et des garde-fous opérationnels comprenant la latence, le coût, la fiabilité et la compatibilité avec l’environnement de production. Ainsi, une amélioration de la précision n’est pas automatiquement considérée comme un succès si elle s’accompagne d’une baisse inacceptable du rappel ou si elle rend le système trop lent, trop coûteux ou difficile à intégrer.
Faire de l’évaluation un test d’intégration reproductible
L’évaluation n’est pas une étape unique précédant le lancement. Les prompts, les modèles, la manière de construire les entrées et la logique du système qui les entoure évoluent constamment, et toute modification peut entraîner une amélioration, une régression ou le déplacement du mode d’erreur vers un autre endroit. GitHub a donc relancé l’évaluation après chaque changement important et a enregistré à chaque fois la version du prompt, du modèle, du jeu de données et de la configuration du système.
L’équipe a également isolé une variable principale à chaque expérience, en comparant une modification du prompt à une base connue avant de tester avec elle une mise à niveau du modèle. Les prompts et les paramètres d’évaluation ont été décrits comme du code : ils ont été versionnés, les changements ont été documentés et la possibilité de relancer les configurations précédentes et de revenir en arrière a été conservée. Cette pratique permet de savoir pourquoi une amélioration ou une régression s’est produite, plutôt que de l’attribuer à tort à la dernière modification.
Simuler la tâche de production et ne pas se contenter de données propres
Les résultats d’une évaluation hors ligne sont plus utiles lorsque la tâche ressemble à la tâche réelle. Dans la détection des secrets, le modèle n’examine pas nécessairement une valeur isolée, mais un candidat au sein d’un code environnant et d’informations auxiliaires qui peuvent être incomplètes ou dispersées. Il peut se concentrer sur une autre valeur qui semble davantage liée à la sécurité, comme un jeton de test présent dans le code, au lieu du candidat à évaluer.
Il convient donc de préserver les caractéristiques de la tâche de production, notamment le candidat évalué, le contexte environnant, les informations auxiliaires, la manière de formater les entrées et d’imposer les contraintes, ainsi que la logique globale du système. Si l’évaluation utilise des exemples plus clairs et un contexte plus complet que la réalité, le résultat peut refléter un problème plus facile que celui auquel le système sera confronté après son déploiement.
Considérer les étiquettes et les données comme des éléments probants à examiner
Le résultat d’une action donnée dans le produit ne signifie pas qu’il représente une vérité terrain fiable. La fermeture d’une alerte dans la détection des secrets peut signifier que l’identifiant a été renouvelé, que le risque a été accepté, que l’alerte a été fermée afin d’ouvrir un flux de travail, ou qu’elle a été mal classée. Ces situations semblent similaires dans les données de flux de travail, mais elles ne répondent pas à la même question dans le cadre de l’évaluation.
Avant d’utiliser des données de production, il faut comprendre comment l’étiquette a été créée, si elle correspond à la question évaluée et si des résultats différents ont été regroupés dans une même catégorie. GitHub suggère une vérification humaine des catégories importantes ou ambiguës, plutôt que de supposer que chaque étiquette est correcte. Les données synthétiques et les benchmarks ouverts peuvent combler des lacunes de couverture, notamment pour les cas rares tels que le contexte manquant, le format inhabituel et les valeurs proches ressemblant à des identifiants, mais ils doivent compléter les données proches de la production et non les remplacer.
Analyser les erreurs et utiliser le modèle évaluateur avec prudence
Les métriques globales indiquent à l’équipe si le système s’est amélioré, mais elles n’expliquent pas ce qu’il faudrait modifier ensuite. GitHub a donc examiné des échantillons de faux positifs et de faux négatifs et a classé leurs causes possibles selon qu’elles relevaient du modèle, du prompt, des entrées, du pipeline, du jeu de données ou des étiquettes. Cette classification transforme un problème général de qualité en tâche d’ingénierie précise : meilleur cadrage des entrées, construction différente du contexte, nettoyage des données ou politique produit plus claire.
Un autre modèle linguistique peut être utilisé comme évaluateur afin de réduire la charge de la vérification humaine, en traitant les cas évidents et en classant les cas ambigus par ordre de priorité. Mais ses sorties ne constituent pas une vérité de référence ; il peut se tromper ou être d’accord avec le modèle évalué pour la mauvaise raison. Le schéma le plus sûr consiste à transmettre aux humains les cas à faible confiance, contradictoires ou à fort impact, à prélever périodiquement des échantillons parmi les cas que l’évaluateur a classés avec une grande confiance, et à suivre ses divergences par rapport au système et aux évaluateurs, tout en versionnant et en évaluant son prompt.
Qu’a réellement démontré l’expérience ?
GitHub a indiqué avoir obtenu une réduction de 95 % des faux positifs sur le jeu de données hors ligne évalué, tout en maintenant le rappel dans les limites de la contrainte de sécurité définie. Toutefois, l’entreprise n’a pas présenté ce résultat comme la preuve que le système se comporterait de la même manière dans tous les scénarios de production. La valeur la plus importante résidait dans la compréhension de la manière d’atteindre ce résultat : une évaluation plus proche de la tâche réelle, des références reproductibles et des modes d’échec documentés.
Lecture éditoriale de certi.news : le véritable changement ne consiste pas à lancer un nouveau modèle, mais à transformer l’évaluation des systèmes LLM, en la faisant passer d’une expérience fondée sur un benchmark à un processus d’ingénierie continu, lié à une décision claire et à des limites de sécurité et d’exploitation. Cela importe aux équipes de logiciels, de sécurité et d’outils pour développeurs, car l’amélioration d’une seule métrique peut masquer une dégradation dangereuse du rappel ou une hausse des coûts. En revanche, le résultat reste limité par le jeu d’évaluation, la qualité des étiquettes et l’écart qu’il est impossible d’éliminer entre les tests hors ligne et le comportement en production ; les évaluations constituent donc une base pour passer à une expérimentation de production contrôlée, et non un substitut à la surveillance des risques après le lancement.