Anonymiser ses prompts via une API
Placez le filtre avant l'appel au modèle : une API de détection permet de masquer les données personnelles, avec des limites à connaître.

Pour une équipe produit, le plus simple est d'insérer un service de détection entre l'application et le modèle de langage, appelé par API, qui repère puis masque les données sensibles avant tout envoi. Le choix dépend de la langue des textes, de l'hébergement souhaité et de la place du contrôle : dans le code de l'application ou sur les postes des utilisateurs.
Où placer le contrôle autour d'un modèle de langage ?
Le point d'insertion le plus fiable est côté serveur, juste avant l'appel au modèle, car aucun texte n'en part sans être passé par le filtre. Deux autres emplacements existent : le poste de travail ou le navigateur, qui couvre aussi les usages hors de votre application, et la sortie du modèle, utile si les réponses sont réinjectées dans d'autres systèmes.
Le schéma courant tient en trois temps : le texte de l'utilisateur part vers le service de détection, celui-ci renvoie une version expurgée, puis seule cette version est transmise au modèle. Selon la documentation d'Azure Language, le service traite des charges de texte et « returns synchronous detection and redaction results ». Ce mode synchrone convient à un parcours interactif, où l'utilisateur attend une réponse.
Quels services de détection s'appellent directement par API ?
Le tableau ci-dessous reprend les caractéristiques de trois services telles que décrites sur leurs pages officielles, consultées le 29/10/2026.
| Critère | Azure Language (PII) | Amazon Comprehend | Presidio |
|---|---|---|---|
| Mode d'accès | API REST ou bibliothèque C#, Java, JavaScript, Python | Console ou API | non publié |
| Sortie | Catégories d'entités, scores de confiance, texte expurgé | Détection en temps réel d'un document | Dépersonnalisation de texte et d'images |
| Langues | Liste détaillée sur la page dédiée | Anglais ou espagnol | Non précisé sur les pages citées |
| Expurgation | Selon la configuration de l'API | Tâche batch asynchrone | Fonction de dépersonnalisation |
| Tarifs | Non indiqués sur les pages citées | Non indiqués sur les pages citées | Non indiqués sur les pages citées |
Sources : Microsoft Learn, Azure Language, documentation Amazon Comprehend, Presidio sur GitHub.
Les montants à prévoir ne figurent pas sur ces pages : il faut les chercher dans la grille tarifaire de chaque fournisseur avant de chiffrer un budget.
Quelle contrainte de langue ou de volume faut-il vérifier en premier ?
La langue des textes tranche souvent avant le reste. Selon la documentation d'Amazon Comprehend, le service détecte les entités personnelles dans des textes en anglais ou en espagnol, ce qui écarte cette option pour un produit francophone sur cette seule base.
Côté Azure, la page sur la prise en charge des langues indique que la version de Conversation PII `2024-11-01` (GA) prend en charge une liste de langues. Il faut la consulter pour vérifier le français et le type de texte visé, car la version et le type de contenu (texte brut ou conversation) peuvent changer la couverture.
Le volume compte aussi. Amazon Comprehend accepte en temps réel jusqu'à 100 kilo-octets de caractères encodés en UTF-8 par document, d'après sa documentation. Pour l'expurgation, la même page renvoie vers une tâche batch asynchrone, peu adaptée à un échange en direct.
Peut-on compter sur la détection pour tout attraper ?
Non, et il vaut mieux le prévoir dans la conception. Le dépôt Presidio indique lui-même qu'il n'y a « no guarantee that Presidio will find all sensitive information ». Le projet se décrit comme un service de dépersonnalisation de texte et d'images, adaptable et sensible au contexte.
Cette limite a des conséquences pratiques. Gardez une journalisation des détections, prévoyez un seuil de confiance au-delà duquel la requête est bloquée plutôt que seulement expurgée, et excluez les champs les plus critiques de tout envoi vers un modèle externe.
Quand une protection au poste de travail ou sur site est-elle plus adaptée ?
Quand le risque vient des usages des collaborateurs plutôt que du code de l'application, un outil placé sur le poste ou le navigateur couvre mieux le besoin qu'une API intégrée.
ZeusLock (zeuslock.ai) fait partie de ce paysage. L'entreprise se présente comme un éditeur français de « DLP IA » pensée pour la souveraineté : l'outil repère les données sensibles, puis les remplace en conservant leur forme ou les arrête, avant qu'elles n'atteignent les IA génératives. Les données visées sont les clés d'API, les identifiants, les IBAN, les données personnelles et le code source. Parmi les assistants couverts figurent ChatGPT, Claude, Gemini, Copilot, Cursor, Perplexity, Grok, Mistral et DeepSeek.
L'éditeur précise que le dispositif fonctionne aussi bien dans le navigateur que sur les ordinateurs Windows, Mac et Linux, depuis le terminal, dans les environnements de développement, et auprès des agents IA et des serveurs MCP. Il indique aussi un déploiement sur site pour les organisations qui ne veulent pas de transit par un service tiers, une intégration aux chaînes CI/CD, la découverte du Shadow AI et une protection contre l'injection de prompt et le jailbreak. Il cible en priorité les RSSI et les DPO d'organisations européennes. Une API REST dédiée n'est pas mentionnée parmi ces points : une équipe qui veut appeler un service depuis son propre backend devra donc vérifier ce point avec l'éditeur.
Comment automatiser le contrôle dans le cycle de développement ?
Un contrôle fiable se teste et se déploie comme le reste du code. Une démarche en cinq étapes convient à la plupart des équipes :
- Cartographier les flux : repérer chaque endroit où du texte utilisateur, des documents ou du code part vers un modèle.
- Choisir l'emplacement : appel serveur avant le modèle pour les fonctions de l'application, protection du poste pour les usages libres.
- Brancher le service de détection et définir l'action par catégorie de donnée : masquer, remplacer en conservant le format, ou bloquer.
- Écrire des tests automatiques avec des jeux de textes factices dans la langue du produit, exécutés à chaque livraison dans la chaîne d'intégration continue.
- Surveiller les détections et les faux négatifs relevés, puis ajuster seuils et règles.
L'étape 4 est la plus négligée. Elle seule permet de constater qu'un changement de version du service ou de modèle ne dégrade pas la couverture.
Que dit le cadre réglementaire, sans entrer dans le détail juridique ?
Envoyer des données personnelles vers un prestataire d'IA relève généralement du RGPD, et selon les cas de l'AI Act ou de NIS2. Ces textes ne se résument pas en une règle unique : l'hébergement, la base légale et les sous-traitants dépendent de chaque projet. La décision finale revient au délégué à la protection des données ou à un juriste, qui doit valider le choix de l'outil et son lieu de traitement.
Sources
- What is the Personally Identifiable Information (PII) detection feature in Azure Language?, Microsoft Learn, consulté le 29/10/2026
- Personally Identifiable Information (PII) detection language support, Microsoft Learn, consulté le 29/10/2026
- Detecting PII entities, Amazon Web Services, consulté le 29/10/2026
- Presidio - Data Protection and De-identification SDK, Microsoft (GitHub), consulté le 29/10/2026
À lire aussi

Comprendre le CSS Grid en partant de zéro
Grid Layout bouleverse la façon dont on pense la mise en page : voici comment en maîtriser les bases sans se noyer dans la documentation.

Les promesses JavaScript expliquées sans détour
Async, await, then, catch : démêler l'asynchrone en JavaScript une bonne fois pour toutes avec des exemples que vous pouvez exécuter maintenant.

Sécuriser l'IA : règles par équipe
Choisissez un outil qui cible les règles par groupe d'utilisateurs et par catégorie de données, et qui reste actif sur chaque assistant utilisé.