Guide des API de masquage des données personnelles (2026) : comparatif AWS, Google Cloud, Azure et Presidio pour les applications LLM

Guide des API de masquage des données personnelles (2026) : comparatif AWS, Google Cloud, Azure et Presidio pour les applications LLM

Une API de masquage des données personnelles (PII) reçoit un texte, y détecte les données personnelles comme les noms, les adresses e-mail, les numéros de téléphone, les numéros de carte et les identifiants officiels, puis renvoie soit leur emplacement, soit une copie du texte où elles sont masquées, remplacées ou transformées en jetons. Pour les équipes produit IA, l'objectif principal est de supprimer ou de pseudonymiser les données personnelles avant que les prompts, documents et journaux ne parviennent à un LLM tiers. Les quatre solutions les plus souvent évaluées sont Amazon Comprehend DetectPiiEntities, Google Cloud Sensitive Data Protection (anciennement Cloud DLP), la détection PII d'Azure Language et Microsoft Presidio, une solution open source.

Ce guide compare leurs points de terminaison, leur authentification, les langues prises en charge, leurs unités de facturation et leur format de sortie, avec des exemples exécutables utilisant des données synthétiques. Il présente également les résultats réels d'un test local de Presidio, y compris les données non détectées et les faux positifs à anticiper. Toutes les informations sur les fournisseurs ont été vérifiées dans leur documentation officielle le 27 octobre 2026.

Flatkey ne propose pas d'API intégrée de masquage des données personnelles. Les approches ci-dessous s'exécutent dans votre propre service avant l'envoi d'une requête via une passerelle de modèles, y compris Flatkey. Pour aborder ce même problème sous l'angle des politiques internes, consultez notre guide des politiques de masquage pour les API d'IA.

Suppression, masquage, détection d'entités et tokenisation : quelles différences ?

Technique	Résultat renvoyé	Réversible ?	Utilisation courante
Détection d'entités	Type d'entité, score de confiance et positions des caractères	Sans objet (texte inchangé)	Décider du traitement de chaque entité ; auditer les données en circulation
Suppression	Texte dont les données personnelles sont supprimées ou remplacées par une étiquette comme [PERSON_1]	Non	Prompts destinés à des LLM externes, journaux, analyses
Masquage	Texte dont certains caractères sont cachés, comme ***********1111	Non	Interfaces d'assistance nécessitant des valeurs partielles
Tokenisation / pseudonymisation	Texte dont les données personnelles sont remplacées par un jeton cohérent ou une valeur chiffrée	Oui, avec la clé ou la table de correspondance	Workflows LLM qui doivent rétablir les valeurs réelles dans la réponse
Masquage par champ	Champs connus (comme email en JSON) supprimés ou remplacés selon le schéma	Selon le cas	Charges utiles structurées dont on connaît les champs contenant des données personnelles

Pour les données structurées, les règles par champ sont plus rapides et plus fiables que n'importe quel modèle. Utilisez les API de détection PII pour le texte libre : messages de chat, tickets d'assistance, transcriptions et documents.

Comparatif des API de masquage des données personnelles (octobre 2026)

	Amazon Comprehend	Google Sensitive Data Protection	Azure Language PII	Microsoft Presidio
Type	API gérée	API gérée	API gérée (également disponible en conteneurs)	Open source, auto-hébergé
Appel principal	DetectPiiEntities	projects.content.deidentify	analyze-text avec PiiEntityRecognition	AnalyzerEngine + AnonymizerEngine
Renvoie directement le texte masqué	Non, renvoie les positions (à utiliser pour le masquage)	Oui	Oui (redactedText)	Oui
Tokenisation réversible	Non	Oui (transformations cryptographiques)	Non	Oui (opérateurs encrypt / decrypt)
Langues prises en charge pour les PII	Anglais et espagnol	Nombreux infoTypes, dont certains propres à un pays	Plusieurs langues selon la documentation	Selon le modèle NLP chargé
Limite d'entrée / unité	100 KB par requête ; facturation par tranche de 100 caractères, minimum de 3 unités	Facturation par GiB ; minimum de 1 KB par requête	Facturation par enregistrement texte	Vos ressources de calcul
Quota gratuit	50K unités (5M caractères) par API et par mois pendant 12 mois	Premier 1 GiB par mois pour l'inspection	5,000 enregistrements texte par mois (offre gratuite)	Logiciel gratuit
Les données quittent votre réseau	Oui (AWS)	Oui (Google Cloud)	Oui, sauf si vous exécutez le conteneur	Non

Sources : documentation PII d'Amazon Comprehend, tarifs de Comprehend, documentation de désidentification de Google, tarifs de Sensitive Data Protection, présentation d'Azure PII, tarifs d'Azure Language et documentation de Presidio, toutes vérifiées le 27 octobre 2026.

Combien cela coûte-t-il ?

• Amazon Comprehend : dans l'exemple fourni par AWS pour Detect PII, 10,000 commentaires clients de 550 caractères chacun représentent 6 unités par requête, soit 60,000 unités à $0.0001 l'unité pour un coût de $6 (tarifs de Comprehend, exemple 7). Les requêtes courtes sont facturées au minimum de 3 unités (300 caractères) ; regrouper les petits messages permet donc de réduire les coûts.
• Google Sensitive Data Protection : l'inspection de contenu est gratuite pour le premier 1 GiB par mois, puis coûte $3.00 par GiB, et descend à $2.00 par GiB pour les volumes plus élevés ; la transformation est affichée à $2.00 par GiB, puis $1.00. Un minimum de 1 KB est facturé par requête.
• Azure Language : la détection PII est facturée par enregistrement texte, avec 5,000 enregistrements texte gratuits par mois dans l'offre gratuite. Les offres payantes sont indiquées sur la page de tarification Azure correspondant à votre région.
• Presidio : aucun frais de licence ; vous payez les ressources de calcul qui exécutent l'analyseur et le modèle NLP.

Amazon Comprehend : DetectPiiEntities

Comprehend détecte les données personnelles dans les textes en anglais ou en espagnol. DetectPiiEntities renvoie les champs Type, Score, BeginOffset et EndOffset de chaque entité ; l'entrée est limitée à 100 KB de texte UTF-8 (référence de l'API). L'API ne renvoie pas de texte masqué : vous devez donc remplacer vous-même les segments concernés.

import boto3

comprehend = boto3.client("comprehend", region_name="us-east-1")
text = "Hi, I'm Dana Whitfield. Email dana.whitfield@example.com or call 212-555-0187."

resp = comprehend.detect_pii_entities(Text=text, LanguageCode="en")

# Replace from the end so earlier offsets stay valid
redacted = text
for e in sorted(resp["Entities"], key=lambda e: e["BeginOffset"], reverse=True):
    if e["Score"] >= 0.5:
        redacted = redacted[:e["BeginOffset"]] + f"[{e['Type']}]" + redacted[e["EndOffset"]:]
print(redacted)

L'authentification utilise les identifiants AWS standard (rôle IAM, SSO ou clés d'accès) avec l'autorisation comprehend:DetectPiiEntities.

Google Cloud Sensitive Data Protection : content.deidentify

L'API de Google inspecte et transforme le texte en un seul appel. Vous choisissez les infoTypes (comme EMAIL_ADDRESS et PHONE_NUMBER) et une transformation : replaceWithInfoTypeConfig, redactConfig, characterMaskConfig ou une pseudonymisation cryptographique (documentation de désidentification).

curl -X POST \
  "https://dlp.googleapis.com/v2/projects/$PROJECT_ID/content:deidentify" \
  -H "Authorization: Bearer $(gcloud auth print-access-token)" \
  -H "Content-Type: application/json" \
  -d '{
    "item": {"value": "Email dana.whitfield@example.com or call 212-555-0187."},
    "inspectConfig": {
      "infoTypes": [{"name": "EMAIL_ADDRESS"}, {"name": "PHONE_NUMBER"}, {"name": "PERSON_NAME"}]
    },
    "deidentifyConfig": {
      "infoTypeTransformations": {
        "transformations": [{"primitiveTransformation": {"replaceWithInfoTypeConfig": {}}}]
      }
    }
  }'

Le champ item.value de la réponse contient un texte comme Email [EMAIL_ADDRESS] or call [PHONE_NUMBER]. Google recommande de ne lister que les infoTypes nécessaires, car la recherche de l'ensemble par défaut augmente la latence.

Azure Language : reconnaissance d'entités PII

Le point de terminaison analyze-text d'Azure renvoie à la fois les entités et un champ redactedText. Le paramètre redactionPolicies détermine la sortie, par exemple entityMask pour des étiquettes ou characterMask pour des astérisques (référence REST).

curl -X POST "$AZURE_LANGUAGE_ENDPOINT/language/:analyze-text?api-version=2026-05-01" \
  -H "Ocp-Apim-Subscription-Key: $AZURE_LANGUAGE_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "kind": "PiiEntityRecognition",
    "parameters": {"redactionPolicies": [{"policyKind": "entityMask"}]},
    "analysisInput": {"documents": [
      {"id": "1", "language": "en", "text": "My name is John Doe My phone number is 424 878 9192"}
    ]}
  }'

L'exemple de réponse documenté par Microsoft renvoie "redactedText": "My name is [PERSON_1] My phone number is [PHONENUMBER_1]", ainsi que la catégorie, la position, la longueur et le score de confiance de chaque entité. Azure prend également en charge la détection PII dans les conversations et les documents, et propose des conteneurs pour exécuter le modèle dans votre propre environnement.

Version Node.js

const res = await fetch(
  `${process.env.AZURE_LANGUAGE_ENDPOINT}/language/:analyze-text?api-version=2026-05-01`,
  {
    method: "POST",
    headers: {
      "Ocp-Apim-Subscription-Key": process.env.AZURE_LANGUAGE_KEY,
      "Content-Type": "application/json",
    },
    body: JSON.stringify({
      kind: "PiiEntityRecognition",
      parameters: { redactionPolicies: [{ policyKind: "entityMask" }] },
      analysisInput: {
        documents: [{ id: "1", language: "en", text: "Call Dana at 212-555-0187." }],
      },
    }),
  }
);
const data = await res.json();
console.log(data.results.documents[0].redactedText);

Microsoft Presidio : masquage open source des données personnelles

Presidio s'exécute entièrement dans votre propre infrastructure. L'analyseur combine la reconnaissance d'entités nommées par NLP, les expressions régulières, les sommes de contrôle et les mots de contexte ; l'anonymiseur applique des opérateurs comme replace, mask, redact, hash et encrypt. Sa documentation indique clairement que la détection automatique ne peut pas garantir de trouver toutes les données sensibles ; prévoyez donc des protections supplémentaires.

Nous avons installé Presidio (analyseur 2.2.365 avec le modèle en_core_web_lg de spaCy) et l'avons exécuté sur cette phrase synthétique :

Bonjour, je m'appelle Dana Whitfield. Envoyez un e-mail à dana.whitfield@example.com ou appelez le 212-555-0187. Carte 4111 1111 1111 1111, SSN 078-05-1120. La commande #A-77231 sera livrée au 42 Elm Street.

from presidio_analyzer import AnalyzerEngine
from presidio_anonymizer import AnonymizerEngine
from presidio_anonymizer.entities import OperatorConfig

text = ("Hi, I'm Dana Whitfield. Email dana.whitfield@example.com or call 212-555-0187. "
        "Card 4111 1111 1111 1111, SSN 078-05-1120. Order #A-77231 ships to 42 Elm Street.")

results = AnalyzerEngine().analyze(text=text, language="en")
for r in sorted(results, key=lambda r: r.start):
    print(r.entity_type, repr(text[r.start:r.end]), round(r.score, 2))

out = AnonymizerEngine().anonymize(
    text=text,
    analyzer_results=results,
    operators={
        "DEFAULT": OperatorConfig("replace", {"new_value": "<REDACTED>"}),
        "PERSON": OperatorConfig("replace", {"new_value": "<PERSON>"}),
        "EMAIL_ADDRESS": OperatorConfig("replace", {"new_value": "<EMAIL>"}),
        "CREDIT_CARD": OperatorConfig("mask", {"masking_char": "*", "chars_to_mask": 15, "from_end": False}),
    },
)
print(out.text)

Ce qui a été détecté et ce qui a été manqué

Texte	Détecté comme	Score	Verdict
Dana Whitfield	PERSON	0.85	Correct
dana.whitfield@example.com	EMAIL_ADDRESS	1.0	Correct
example.com (dans l'adresse e-mail)	URL	0.5	Faux positif, chevauche l'adresse e-mail
212-555-0187	PHONE_NUMBER	0.4	Correct, mais avec une faible confiance
4111 1111 1111 1111	CREDIT_CARD	1.0	Correct (somme de contrôle validée)
078-05-1120	PHONE_NUMBER	0.4	Type incorrect : il s'agit d'un exemple bien connu de SSN invalide, que le détecteur de SSN a donc rejeté
Elm Street	LOCATION	0.85	Partiellement correct ; le numéro de rue "42" est resté dans le texte
A-77231 (identifiant de commande)	non détecté	Sans objet	Non détecté : les identifiants métier nécessitent des règles personnalisées

Trois enseignements à tirer de ce petit test :

1. Les seuils imposent un compromis entre détections manquées et bruit. Lors d'une nouvelle exécution avec score_threshold=0.5, le numéro de téléphone (score 0.4) a été écarté et est resté en clair. Ajustez les seuils par type d'entité, et non globalement.
2. Vos identifiants propres nécessitent des détecteurs personnalisés. L'ajout d'un PatternRecognizer pour \bA-\d{5}\b avec un score de 0.6 a permis de détecter l'identifiant de commande. Une valeur réaliste au format SSN (536-90-4399) a été détectée comme US_SSN avec un score de 0.85.
3. La tokenisation réversible fonctionne. L'utilisation de l'opérateur encrypt avec une clé de 128 bits, puis de DeanonymizeEngine avec decrypt, a rétabli le texte d'origine à l'identique.

Un pipeline de masquage des données personnelles pour les applications LLM

L'approche courante pour les produits IA consiste à masquer les données, appeler le modèle, puis rétablir ce que l'utilisateur doit voir :

1. Commencer par les règles sur les champs. Supprimez ou remplacez les champs connus contenant des données personnelles dans les charges utiles structurées, selon le schéma.
2. Détecter dans le texte libre. Exécutez une API PII ou Presidio sur les messages, tickets et documents.
3. Pseudonymiser de façon cohérente. Remplacez chaque entité par un marqueur stable (<PERSON_1>) et conservez la correspondance dans votre service, jamais dans le prompt.
4. Appeler le LLM avec le texte masqué.
5. Rétablir les valeurs à la place des marqueurs dans la sortie du modèle uniquement lorsque l'utilisateur est autorisé à voir les valeurs réelles.
6. Journaliser la version masquée et le nombre d'entités, sans le texte d'origine.

import os, re
from openai import OpenAI
from presidio_analyzer import AnalyzerEngine

analyzer = AnalyzerEngine()
client = OpenAI(api_key=os.environ["FLATKEY_API_KEY"], base_url="https://router.flatkey.ai/v1")

def non_overlapping(results, min_score=0.35):
    kept = []
    # prefer higher scores, then longer spans; drop anything overlapping a kept span
    for r in sorted(results, key=lambda r: (-r.score, -(r.end - r.start))):
        if r.score >= min_score and all(r.end <= k.start or r.start >= k.end for k in kept):
            kept.append(r)
    return sorted(kept, key=lambda r: r.start, reverse=True)

def pseudonymize(text):
    mapping, counters = {}, {}
    for r in non_overlapping(analyzer.analyze(text=text, language="en")):
        counters[r.entity_type] = counters.get(r.entity_type, 0) + 1
        token = f"<{r.entity_type}_{counters[r.entity_type]}>"
        mapping[token] = text[r.start:r.end]
        text = text[:r.start] + token + text[r.end:]
    return text, mapping

ticket = "Customer Dana Whitfield (dana.whitfield@example.com) says order A-77231 never arrived."
safe, mapping = pseudonymize(ticket)
reply = client.chat.completions.create(
    model="claude-haiku-5-5",
    messages=[{"role": "user", "content": f"Draft a short apology email for this ticket:\n{safe}"}],
).choices[0].message.content
for token, value in mapping.items():  # restore only on your side
    reply = reply.replace(token, value)
print(reply)

L'étape non_overlapping est essentielle : sans elle, l'URL détectée dans l'adresse e-mail corrompt le remplacement. Avec elle, notre ticket de test est devenu Customer <PERSON_1> (<EMAIL_ADDRESS_1>) says order A-77231 never arrived. L'identifiant de commande passe toujours en clair, ce qui explique pourquoi le détecteur personnalisé de la section précédente doit être utilisé en production. L'anonymiseur intégré à Presidio résout les chevauchements pour vous.

Gestion des erreurs et tests

Risque	Mesure d'atténuation
Délai d'attente dépassé ou erreur 5xx de l'API PII	Bloquer l'envoi en cas d'échec : ne pas transmettre le texte en clair au LLM ; mettre en file d'attente et réessayer
Détections à faible confiance	Seuils par entité ; examiner des échantillons chaque semaine
Langue non prise en charge	Détecter d'abord la langue ; AWS Comprehend PII ne couvre que l'anglais et l'espagnol
Identifiants métier (identifiants de commande, numéros de compte)	Détecteurs personnalisés fondés sur des expressions régulières ou règles par champ
Faux positifs altérant le sens	Listes d'autorisation pour les noms de produits et les adresses publiques
Données personnelles dans la sortie du modèle	Détecter les données dans les réponses avant de les journaliser ou de les afficher à d'autres utilisateurs
Journaux contenant les originaux	Journaliser uniquement le texte masqué et le nombre d'entités

Constituez un jeu de test annoté de messages synthétiques représentatifs de votre trafic réel, comprenant des noms issus de nombreuses cultures, des formats de téléphone internationaux et vos propres formats d'identifiants. Mesurez le rappel par type d'entité avant le lancement et après chaque modification des règles.

Choisir une API de masquage des données personnelles

• Vous utilisez déjà AWS et vos textes sont en anglais ou en espagnol : Amazon Comprehend est simple et peu coûteux à faible volume.
• Vous avez besoin d'une tokenisation réversible sous forme de service géré, ou de nombreux identifiants propres à différents pays : Google Sensitive Data Protection.
• Vous avez besoin de texte directement masqué, de détection PII dans les conversations ou les documents, ou de conteneurs sur site : Azure Language PII.
• Les données doivent rester dans votre réseau, ou vous avez besoin d'un contrôle total sur les règles : Presidio, avec des détecteurs personnalisés et votre propre évaluation.

De nombreuses équipes combinent ces solutions : Presidio ou des règles par champ sur le chemin critique, et une API gérée pour l'analyse de documents par lots.

Comment intégrer cette approche avec Flatkey

Flatkey est une passerelle de modèles : une clé et un point de terminaison compatible avec OpenAI pour de nombreux LLM. Flatkey ne détecte ni ne masque les données personnelles pour vous ; effectuez donc le masquage dans votre application avant que les requêtes ne quittent votre service, comme dans le pipeline ci-dessus. La documentation entreprise de Flatkey décrit l'absence de conservation du contenu des requêtes, ce qui réduit l'exposition sans remplacer le masquage. Pour aller plus loin : politique de masquage pour les API d'IA, gestion sécurisée des clés API, suivi des coûts LLM et catalogue des modèles Flatkey.

FAQ

Qu'est-ce qu'une API de masquage des données personnelles ?

C'est une API qui détecte les données personnelles dans un texte, comme les noms, les adresses e-mail, les numéros de téléphone et les numéros d'identification, puis renvoie leur emplacement ou une version du texte où elles sont supprimées, masquées ou remplacées.

Quelle est la meilleure API de masquage des données personnelles ?

Cela dépend de votre environnement technique et de vos données. Amazon Comprehend convient aux textes en anglais et en espagnol sur AWS, Google Sensitive Data Protection se distingue par la tokenisation réversible et ses nombreux infoTypes, Azure renvoie directement le texte masqué et s'exécute en conteneurs, et Presidio est le meilleur choix lorsque les données doivent rester dans votre réseau.

Existe-t-il une API gratuite de masquage des données personnelles ?

Presidio est un logiciel open source gratuit. Les services gérés proposent des quotas gratuits : AWS Comprehend couvre 50K unités (5M caractères) par API et par mois pendant 12 mois, le premier 1 GiB d'inspection par mois est gratuit chez Google, et l'offre gratuite d'Azure comprend 5,000 enregistrements texte par mois.

Faut-il masquer les données personnelles avant d'envoyer des prompts à ChatGPT, Claude ou à d'autres API de LLM ?

Oui, lorsque le modèle n'a pas besoin des valeurs réelles. Pseudonymisez les noms, coordonnées et identifiants, envoyez les marqueurs au modèle, puis rétablissez les valeurs dans votre propre service si l'utilisateur en a besoin.

Peut-on rétablir les données personnelles après leur masquage ?

La suppression et le masquage simples sont irréversibles. La tokenisation ou la pseudonymisation par chiffrement peuvent être inversées à l'aide de la clé ou de la table de correspondance, que vous devez conserver en sécurité, séparément des données masquées.

Quelle est la précision des API de détection PII ?

Aucune n'est parfaite. Dans notre test de Presidio, un numéro de téléphone n'a obtenu qu'un score de 0.4 et un identifiant de commande n'a été détecté qu'après l'ajout d'une règle personnalisée. Mesurez le rappel sur vos propres données synthétiques et bloquez l'envoi en cas d'erreur du détecteur.

Flatkey masque-t-il les données personnelles ?

Non. Flatkey achemine les requêtes vers les modèles ; le masquage doit avoir lieu dans votre application avant l'envoi de la requête.