La détection de secrets vient de changer de moteur chez GitHub. Le 13 octobre, l'équipe CoreAI a détaillé son nouveau classifieur de secrets : un encodeur ModernBERT affiné, quantifié en 8 bits, qui remplace un pipeline fondé sur des appels à un LLM distant. Les chiffres annoncés sont rares dans ce genre d'annonce, parce qu'ils vont tous dans le même sens : précision hors ligne en hausse de 13 %, rappel en hausse de 19 %, temps médian du scan après push en baisse de 86 %, et coût de service réduit de plus de 98 %.
Pour une équipe qui industrialise de l'IA, l'intérêt dépasse largement les secrets. C'est un cas d'école documenté d'un choix que beaucoup repoussent : remplacer un appel LLM généraliste par un petit modèle spécialisé, une fois que la tâche est bien définie et que les données d'entraînement existent.
Le contexte
Un « secret », dans ce contexte, c'est une clé d'API, un jeton d'accès, un mot de passe ou une clé privée qui se retrouve dans le code. GitHub les cherche à deux moments : avant d'accepter un push (la push protection, qui bloque le commit) et après coup, en scannant en continu les dépôts (le post-push scanning, qui ouvre une alerte).
Les secrets structurés sont faciles : un jeton qui suit un format connu, avec un préfixe et une longueur fixe, se reconnaît par une expression régulière. Le problème, ce sont les secrets génériques : une chaîne aléatoire assignée à une variable password ou api_key. Comme le résume l'article, la même chaîne peut être un vrai identifiant ou un exemple de documentation. Trop de silence, et une vraie clé reste dans le dépôt. Trop d'alertes, et les développeurs perdent leur temps sur des chaînes qui n'en sont pas, puis finissent par ignorer l'outil.
L'enjeu n'est pas théorique. Dans un billet compagnon publié le 7 octobre, GitHub indique qu'un nouveau secret apparaît dans du code public environ toutes les deux secondes, et qu'une révocation manuelle prend en moyenne une quarantaine de jours.
Comment fonctionne le pipeline de détection de secrets
L'architecture tient en deux étages, que l'article résume par « large d'abord, prudent ensuite ».
Étage 1 : des regex à haut rappel
Des expressions régulières balaient le code pour repérer tout ce qui ressemble à un identifiant. Elles sont volontairement larges : leur rôle est de ne rien rater, quitte à remonter beaucoup de faux candidats. Cet étage est bon marché et prévisible.
Étage 2 : un classifieur qui lit le contexte
Chaque candidat passe ensuite par le classifieur. Il ne reçoit pas seulement la chaîne suspecte, mais aussi le chemin du fichier, le type de secret et une portion bornée du code environnant (l'article ne précise pas sa taille exacte). Il renvoie un score, et le scanner décide à partir de ce score si le candidat devient une alerte. Les seuils ont été choisis en évaluation hors ligne, puis validés sur du trafic proche de la production avant le déploiement.
Le modèle est un encodeur ModernBERT affiné, exporté en ONNX et quantifié en 8 bits. Pour rappel, ModernBERT est une famille d'encodeurs publiée fin 2024, en deux tailles (149 et 395 millions de paramètres), avec une fenêtre de 8 192 tokens. GitHub ne dit pas quelle variante il utilise. Le billet compagnon précise en revanche que l'évaluation d'un candidat prend moins de deux millisecondes.
Le vrai problème : des secrets « presque réels »
La partie la plus utile de l'article porte sur les hard negatives : des chaînes qui correspondent à un motif d'identifiant mais ne sont pas des identifiants utilisables. GitHub en cite plusieurs familles : marqueurs de documentation, exemples factices dans les tests, valeurs caviardées, identifiants non sensibles, fixtures générées.
Ce sont exactement les cas qui font dérailler une détection par regex, et qui rendent un LLM généraliste coûteux à appeler à chaque push. Un encodeur qui voit le chemin tests/fixtures/ et un nom de variable EXAMPLE_KEY a de quoi trancher, à condition d'avoir vu ce genre de cas à l'entraînement.
Un jeu d'entraînement construit pour les cas durs
Les données combinent trois sources :
- des exemples issus des produits GitHub ;
- des candidats remontés par les regex à haut rappel, annotés par des humains ;
- des exemples synthétiques ciblant les cas rares : secrets de documentation, fixtures de test, clés publiques, sommes de contrôle.
L'entraînement insiste explicitement sur trois catégories : vrais secrets, faux positifs réalistes et hard negatives. C'est le point clé du projet. Le modèle n'est pas meilleur parce qu'il est plus intelligent qu'un LLM, mais parce qu'il a été entraîné sur la distribution exacte du problème.
Détection de secrets : ce que disent les chiffres
GitHub a comparé le classifieur au pipeline LLM précédent de deux façons : une évaluation hors ligne sur le même trafic public, puis une expérience A/B en conditions réelles.
| Indicateur | Évolution annoncée |
|---|---|
| Précision hors ligne | +13 % |
| Rappel hors ligne | +19 % |
| Acceptation pondérée par propriétaire | +11,5 % |
| Temps médian du scan après push | −86 % |
| Coût de service | plus de −98 % |
Deux remarques pour lire ce tableau correctement. D'abord, gagner en précision et en rappel en même temps est inhabituel : en général, on échange l'un contre l'autre en déplaçant un seuil. Ici, c'est le modèle lui-même qui s'améliore. Ensuite, la métrique d'« acceptation pondérée par propriétaire » mérite d'être retenue. Elle réduit le poids des clients qui ferment des alertes en masse, ce qui fausserait une simple moyenne. C'est une bonne pratique à copier dès qu'on mesure la satisfaction sur des actions utilisateur.
Le billet compagnon ajoute que ce modèle pourrait plus que doubler le nombre de secrets bloqués avant leur entrée dans un dépôt, alors que la push protection n'en arrête aujourd'hui qu'environ 30 %. C'est une projection de GitHub, pas une mesure.
Ce que ça change pour les équipes IA
La détection de secrets n'est qu'un exemple. La leçon générale concerne toutes les équipes qui ont mis un LLM au milieu d'un traitement à fort volume.
1. Le LLM est souvent un prototype, pas une cible. Un appel à un modèle généraliste est le moyen le plus rapide de valider une idée de classification. Une fois la tâche stabilisée, les données annotées s'accumulent, et un encodeur affiné devient envisageable. GitHub a fait exactement ce chemin. Si votre pipeline appelle un LLM pour une décision binaire répétée des milliers de fois par jour, posez-vous la question.
2. La cascade bon marché puis précis reste imbattable. Un premier filtre à haut rappel, puis un modèle plus fin sur les seuls candidats : ce schéma garde le coût proportionnel au nombre de cas ambigus, pas au volume total. Il s'applique à la modération, au tri de tickets, à la détection d'anomalies dans les logs ou au routage de requêtes RAG.
3. Les hard negatives se fabriquent. Le gain vient en grande partie d'exemples synthétiques ciblés sur les cas rares. Pour un modèle maison, cela veut dire investir dans un jeu de données qui contient délibérément les pièges de votre domaine, pas seulement des exemples propres.
4. Le service compte autant que le modèle. Export ONNX, quantification 8 bits, inférence en moins de deux millisecondes : ce sont des choix d'industrialisation, pas de recherche. Ils expliquent l'essentiel du −98 % sur le coût. Un modèle plus petit se déploie aussi plus simplement, sans quotas d'API externes ni latence réseau.
5. Mesurer comme en production. Évaluation hors ligne, seuils calibrés, validation sur trafic réaliste, puis A/B test : c'est la séquence à reproduire avant de remplacer un composant qui fonctionne déjà.
Il reste des zones d'ombre. GitHub ne publie ni le modèle, ni le jeu de données, ni la taille exacte du contexte utilisé, et ne précise pas quels plans en bénéficient. Le résultat est donc un retour d'expérience, pas un outil réutilisable tel quel. Côté sécurité, rien ne remplace pour autant la rotation rapide des clés et un coffre-fort de secrets : un détecteur, même bon, intervient après l'erreur.
En bref
- GitHub remplace un pipeline LLM par un encodeur ModernBERT affiné pour sa détection de secrets génériques.
- Le pipeline combine des regex à haut rappel et un classifieur qui lit le contexte du code.
- Résultats annoncés : +13 % de précision, +19 % de rappel, −86 % de temps de scan, plus de −98 % de coût.
- La clé du gain : un jeu d'entraînement construit autour des hard negatives.
- Leçon pour les équipes IA : quand une tâche LLM se stabilise, un petit modèle spécialisé devient souvent plus juste et bien moins cher.
Si votre détection de secrets, ou n'importe quelle classification à fort volume, repose encore sur des appels LLM, ce cas mérite une revue de votre propre pipeline.
Vous industrialisez vos agents IA ? SeedVision propose des audits IA en 3-5 jours et des forfaits de mise en production de 15 à 30 jours. Voir les packages ou réserver un appel de 30 min.
Photo de couverture : Photo by Anne Nygård on Unsplash.