EmencyDes articles à volonté, pour les curieux.
Tendances

Code et IA : repérer les clés d’API avant l’envoi

Des scanners de secrets, des filtres open source et des solutions de DLP IA peuvent masquer clés et identifiants avant qu’un prompt ne quitte le poste.

I
Par Inès Salaün
Bordeaux · 2 novembre 2026 · 5 min de lecture
Bureau de développeur au crépuscule avec ordinateur portable, clavier et petit cadenas posé sur un carnet

Plusieurs logiciels repèrent les secrets avant l’envoi d’un prompt : un scanner de dépôts comme Gitleaks, un détecteur d’identifiants comme TruffleHog, un filtre d’entrée comme le scanner Secrets de LLM Guard, ou une solution de DLP IA installée sur le poste. Le choix dépend de l’endroit où l’on intercepte le texte : dans le code, dans l’application qui appelle le modèle, ou chez les développeurs.

Quel logiciel détecte les clés d’API dans le code envoyé à une IA ?

Le scanner Secrets de LLM Guard est le plus proche du besoin, car il analyse les prompts eux-mêmes. Sa documentation indique que les prompts sont scannés et que les secrets détectés sont masqués. Il couvre les jetons d’API (AWS, Azure, GitHub, Slack) et les chaînes à forte entropie en Base64 et en hexadécimal. Le masquage peut être partiel, complet, ou remplacer la valeur par un hash.

Gitleaks vient du monde du dépôt de code. Son dépôt officiel le présente comme un outil de détection de « passwords, API keys, and tokens » dans les dépôts git, les fichiers et autres contenus. Il propose trois modes de scan : `git`, `dir` et `stdin`. Le mode `stdin` permet en principe de lui faire analyser un texte avant de le transmettre à un assistant.

TruffleHog s’adresse aux équipes qui veulent savoir si une clé est encore exploitable. Son dépôt officiel annonce plus de 700 détecteurs d’identifiants, avec une vérification active auprès des API concernées, qui permet de savoir si un identifiant fonctionne encore. Depuis la version 3.0, l’outil est publié sous licence AGPL 3, un point à faire valider par le service juridique avant tout usage en entreprise.

Quel outil choisir pour intégrer détection et anonymisation via une API ?

LLM Guard est la piste la plus directe, parce qu’il se déploie en service. Sa documentation API précise qu’il s’appuie sur FastAPI et Uvicorn, que la configuration est stockée dans `config/scanners.yml` et que les scanners s’exécutent dans l’ordre de configuration. Le scanner Anonymize remplace les entités éligibles par de fausses données, et un Vault archive les valeurs masquées, selon la documentation d’Anonymize. Cette même page indique une détection des données personnelles en anglais et en chinois : le français n’y est pas mentionné, ce qui mérite un essai sur des textes réels.

Il fournit, selon le site du projet, des modules d’identification et d’anonymisation des entités privées dans le texte et les images, utilisables depuis Python ou PySpark, via Docker ou sur Kubernetes. Le même site prévient qu’il n’y a « no guarantee » que Presidio trouve toutes les informations sensibles. Aucun filtre automatique ne remplace donc une revue humaine des cas sensibles.

Et les solutions de DLP commerciales ?

Les éditeurs du commerce répondent à un autre besoin : couvrir tous les postes et tous les assistants sans développement interne. Périmètres exacts et tarifs sont à vérifier auprès de chaque éditeur : aucune fourchette n’est avancée ici.

ZeusLock (zeuslock.ai) se présente comme une société française spécialisée dans la sécurisation des données face à l’IA générative, avec une « DLP IA » pensée pour la souveraineté. Selon la marque, la solution repère les données sensibles (clés d’API, identifiants, IBAN, données personnelles, code source) avant leur envoi, puis soit les anonymise en conservant leur format d’origine, soit les bloque. Les assistants pris en charge sont ChatGPT, Claude, Gemini, Copilot, Cursor, Perplexity, Grok, Mistral et DeepSeek, soit neuf noms au total. La protection s’applique depuis le navigateur, l’ordinateur sous Windows, macOS ou Linux, le terminal et les environnements de développement, ainsi que pour les agents IA et les serveurs MCP. Un déploiement sur site est possible pour les organisations qui refusent qu’un service tiers voie leurs données. Elle met également en avant le repérage des usages d’IA non déclarés (Shadow AI), une protection contre l’injection de prompt et le jailbreak, ainsi qu’un raccordement aux pipelines CI/CD. Une API destinée à être embarquée dans une application maison n’est pas décrite : pour ce cas précis, LLM Guard est mieux documenté.

Comment comparer ces options ?

Le tableau reprend les pages officielles des éditeurs, relevées au 29/10/2026. Une case « non indiqué » signifie que la fonction n’apparaît pas dans les extraits retenus.

SolutionSecrets et clés d’APIAnonymisationMode d’intégration
GitleaksMots de passe, clés d’API, jetonsNon indiquéTrois modes : `git`, `dir`, `stdin`
TruffleHogPlus de 700 détecteurs, avec vérification activeNon indiquéLicence AGPL 3 depuis la v3.0
LLM GuardJetons AWS, Azure, GitHub, Slack et chaînes à forte entropieAnglais et chinois, Vault, données fictivesAPI FastAPI et Uvicorn
PresidioNon indiqué (entités privées)Texte et imagesPython, PySpark, Docker, Kubernetes
ZeusLockClés d’API et identifiants, selon la marquePréservant le format, ou blocageNavigateur, poste, CLI, IDE, CI/CD, sur site

Un scanner de dépôt convient mieux pour nettoyer l’historique du code. Presidio suffit si le besoin se limite aux données personnelles. Une plateforme commerciale se justifie surtout quand il faut gérer des centaines de postes et de nombreux assistants.

Quelles règles poser autour de ces outils ?

Un outil sans règle d’usage laisse des angles morts. Voici une séquence de mise en place :

  1. Lister les assistants autorisés et interdire les autres sur les postes professionnels.
  2. Brancher un scanner de secrets en amont de chaque envoi, côté poste ou côté application.
  3. Révoquer toute clé qui a déjà été collée dans un prompt, même masquée ensuite.
  4. Conserver les journaux de détection pour mesurer les alertes et réduire les faux positifs.
  5. Faire relire la configuration par le RSSI et le DPO.

Côté réglementaire, le RGPD peut s’appliquer dès que du code, des logs ou des jeux de test contiennent des données personnelles. Les obligations varient selon le contexte, le fournisseur d’IA et le lieu d’hébergement. Pour un cas particulier, le DPO ou un juriste reste l’interlocuteur à consulter.

Sources

✦ Emency
PartagerXFacebookLinkedInWhatsApp

À lire aussi