LLM Security

Chiffrer les prompts envoyés à OpenAI : analyse risque/conformité

Analyse complète chiffrement prompts OpenAI : TLS suffit-il ? E2EE possible ? Alternatives Azure OpenAI EU, Mistral, on-premise. RGPD, Schrems II, EU AI Act.

Naim Aouaichia
17 min de lecture
  • chiffrement
  • OpenAI
  • RGPD
  • conformité
  • Schrems II

Faut-il chiffrer les prompts envoyés à OpenAI ? Réponse courte : TLS 1.3 par défaut est nécessaire mais pas suffisant pour données sensibles, et le end-to-end encryption (E2EE) applicatif n'est pas possible avec API OpenAI standard car le modèle doit lire les prompts en clair pour les traiter. La vraie question 2026 n'est pas "comment chiffrer plus" mais "quelles données envoyer et où", choix entre OpenAI standard, Azure OpenAI EU, Mistral EU, ou on-premise selon classification donnée et conformité (RGPD post-Schrems II, EU AI Act, sectoriel). Cet article documente l'analyse risque/conformité complète : ce que TLS couvre / ne couvre pas, pourquoi E2EE applicatif est impossible avec LLM standard (sauf Confidential Computing, Apple PCC pattern, ou FHE recherche), alternatives concrètes (Azure OpenAI EU, Mistral, on-premise), techniques de minimisation et pseudonymisation upstream (Presidio, tokenisation HMAC, splitting), modèle de DPIA à documenter pour audit. Cible : DSI / RSSI / DPO arbitrant l'usage OpenAI, AI engineers structurant la couche privacy, équipes Legal validant choix fournisseur LLM.

Pour les risques globaux d'intégrer ChatGPT : quels sont les risques si j'intègre ChatGPT dans mon SI. Pour l'alternative on-premise : architecture sécurisée pour déployer un LLM on-premise.

Ce que TLS 1.3 couvre / ne couvre pas

TLS 1.3 par défaut

OpenAI API utilise TLS 1.3 sur toutes les connexions. Bénéfices :

  • Confidentialité in-transit : un attaquant réseau (man-in-the-middle, Wi-Fi public, ISP) ne peut pas lire les prompts en clair
  • Intégrité : modification en transit détectée
  • Authentification serveur : certificats x509 vérifiés, vous parlez bien à api.openai.com
  • Forward secrecy : compromise d'une clé n'exposera pas les sessions passées

Ce que TLS NE couvre PAS

AspectTLS protège ?
Transit (réseau)
Stockage côté OpenAI
Insider threat OpenAI (employés)
Subpoena US (FISA, CLOUD Act)
Transfert UE → US (RGPD)Partiellement
Compromission cloud OpenAI

Stockage côté OpenAI

Selon politique 2026 (à vérifier sur openai.com/policies car évolue) :

  • API tier standard : prompts/réponses stockés ~30 jours pour abuse monitoring, opt-out training par défaut.
  • API tier Enterprise : Zero Data Retention possible sur demande, opt-out training par défaut, audit logs Enterprise.
  • ChatGPT plain (chat.openai.com) : stockage potentiellement plus long, opt-out training disponible mais variable.

→ Même en tier API standard, vos prompts sont stockés 30j en clair chez OpenAI. TLS ne change rien à ça.

Subpoena US et CLOUD Act

OpenAI étant entreprise US, soumise à :

  • CLOUD Act (2018) : autorités US peuvent demander accès aux données stockées par entreprises US, même si data physiquement à l'étranger
  • FISA section 702 : surveillance étrangère par autorités US sans notification possible
  • National Security Letters : ordres de divulgation avec gag order

Pour data sensibles (santé, défense, IP stratégique), risque réel non couvert par TLS.

End-to-end encryption avec OpenAI : limitations fondamentales

Pourquoi E2EE applicatif n'est pas possible

Pour qu'un LLM traite un prompt, il doit le lire en clair. Si le prompt arrive chiffré et qu'OpenAI n'a pas la clé de déchiffrement, OpenAI ne peut littéralement rien en faire, pas d'inférence possible.

[Votre app]
   prompt en clair
        │
        │ TLS 1.3
        ▼
[api.openai.com]
   prompt déchiffré (TLS terminé)
        │
        ▼
[OpenAI inference servers]
   prompt en clair en mémoire pendant inference
   ← admin OpenAI peut voir si abuse review
   ← stocké 30j en logs (clair)
        │
        ▼
[response generation]
   response en clair
        │
        │ TLS 1.3
        ▼
[Votre app]

Aucune phase n'est E2EE au sens cryptographique strict (clé partagée uniquement entre 2 endpoints, intermédiaire ne peut pas déchiffrer).

Solutions partielles émergentes 2024-2026

1. Confidential Computing

Intel TDX / AMD SEV-SNP / NVIDIA H100 Confidential Computing permettent exécution dans Trusted Execution Environment (TEE) où :

  • Mémoire chiffrée par hardware
  • Admin host (incluant cloud admin) ne peut pas inspecter
  • Attestation cryptographique du code en exécution

OpenAI a annoncé travail sur des features Confidential Computing 2024-2025 mais déploiement limité 2026. Pas encore standard sur API.

Modèle de référence Apple Private Cloud Compute (PCC) introduit 2024 :

  • Prompts chiffrés en transit
  • Déchiffrés UNIQUEMENT dans TEE attesté
  • Traités, puis destruction garantie post-traitement
  • Audit code public possible
  • "Cloud private inference" pattern

OpenAI ne propose pas l'équivalent en 2026 (mais inspire l'industrie).

2. Homomorphic Encryption (FHE)

Permet calcul sur données chiffrées sans déchiffrement. Théoriquement E2EE compatible LLM.

Réalité performance 2026 : FHE pour LLMs ~1000-10000× plus lent que inference standard. Inutilisable production sauf cas extrême.

Recherche active (Microsoft SEAL, IBM HElib, OpenFHE) mais pas mature.

3. Confidential Inference startups

Quelques startups 2024-2026 (Confidential VM-based inference) proposent solutions hybrides :

  • Instances cloud avec TEE
  • Gestion clés avec KMS isolé
  • Attestation

Mais latence + coût élevés, écosystème jeune.

Conclusion : pas d'E2EE applicatif avec OpenAI standard 2026

Pour zéro-trust strict :

  • Soit données ne quittent pas votre infra (on-premise)
  • Soit Confidential Computing si disponible (rare encore)
  • Soit acceptation du risque résiduel après mitigations

Données à NE JAMAIS envoyer à OpenAI standard

Liste explicite

TypePourquoiAlternative
RGPD Art. 9 (santé, opinion, religion, etc.)DPIA + base légale solide requis, transfert US risquéAzure EU + DPIA, Mistral, on-premise
Secrets industriels stratégiquesRisque insider + subpoena USOn-premise
Code propriétaire critiqueIP exposureOn-premise, Azure EU avec opt-out training
M&A / stratégie en coursConfidentialité contractuelle, IPOn-premise, Azure EU
Passwords / API keys / certificatesLogs OpenAI peuvent les retenir 30jNe JAMAIS, strip avant prompt
PII massif (10000+ records)Minimisation RGPD violéePseudonymisation + Azure EU
Données classifiées défenseInterdit par lawOn-premise air-gap obligatoire
Données sous NDA strict clientRisk juridiqueVérifier termes NDA, possiblement Azure EU

Comment décider pratiquement

# Classifier et router
def classify_data_for_llm(content: str, context: dict) -> dict:
    """Classifie la donnée pour décider quel LLM utiliser."""
    
    findings = {
        "rgpd_article_9": detect_health_political_religious(content),
        "secrets": detect_secrets(content),  # API keys, passwords, certs
        "code_proprietary": detect_proprietary_code(content),
        "pii_massive": count_pii(content) > 10,
        "ndatop": context.get("under_nda_strict", False),
    }
    
    if findings["secrets"]:
        return {"action": "REJECT", "reason": "secrets detected, never send to LLM"}
    
    if findings["rgpd_article_9"] or findings["code_proprietary"]:
        return {"action": "ROUTE_ONPREM", "reason": "high sensitivity"}
    
    if findings["pii_massive"]:
        return {"action": "PSEUDONYMIZE_AND_AZURE_EU", "reason": "minimization required"}
    
    # Default : tier OpenAI Enterprise OK
    return {"action": "OPENAI_ENTERPRISE", "reason": "standard"}

Alternatives concrètes par ordre d'effort

Alternative 1, Azure OpenAI Service (région EU)

Setup :

from openai import AsyncAzureOpenAI
 
client = AsyncAzureOpenAI(
    azure_endpoint="https://my-resource-france-central.openai.azure.com/",
    api_version="2024-08-01-preview",
    api_key=os.environ["AZURE_OPENAI_API_KEY"],
)
 
response = await client.chat.completions.create(
    model="gpt-4o-deployment",  # nom du deployment, pas du model
    messages=[...],
    max_tokens=1500,
)

Régions EU disponibles 2026 : France Central, West Europe (Pays-Bas), Sweden Central, Switzerland North, Germany West Central, Italy North.

Bénéfices :

  • Pas de transfert US (data reste dans région choisie)
  • DPA Microsoft Enterprise
  • Conformité héritée Azure (HDS pour santé, ISO 27001, BSI C5, EU Data Boundary)
  • Intégration Entra ID, Key Vault, Sentinel
  • Auditabilité complète Azure logs

Limites :

  • Lag par rapport à OpenAI direct (nouveaux modèles disponibles avec quelques semaines/mois de retard)
  • Quotas régionaux parfois plus stricts
  • Coût similaire à OpenAI direct

Effort migration : faible si vous utilisez déjà Azure. Code quasi-identique (SDK même API).

Recommandation #1 pour 80% des cas entreprise EU.

Alternative 2, Mistral AI (France)

Setup :

from mistralai import Mistral
 
client = Mistral(api_key=os.environ["MISTRAL_API_KEY"])
 
response = await client.chat.complete_async(
    model="mistral-large-latest",
    messages=[...],
    max_tokens=1500,
)

Bénéfices :

  • Souveraineté EU forte (entreprise française, hébergement EU obligatoire)
  • DPA français, juridiction française
  • Modèles compétitifs (Mistral Large 2, Mixtral 8x22B, Codestral)
  • Conformité EU AI Act ready (entreprise EU)

Limites :

  • Modèles légèrement en-deçà GPT-4o sur certaines tâches (gap se réduit)
  • Écosystème SDK plus jeune
  • Prompt format légèrement différent (à adapter)

Effort migration : moyen (prompts à re-tester, parfois ajuster).

→ Recommandation pour orgs où souveraineté FR/EU est non-négociable.

Alternative 3, Anthropic Claude via AWS Bedrock EU

Setup :

import boto3
 
client = boto3.client(
    "bedrock-runtime",
    region_name="eu-central-1",  # Frankfurt
)
 
response = client.converse(
    modelId="anthropic.claude-sonnet-4-6-20250101-v2:0",
    messages=[{"role": "user", "content": [{"text": "..."}]}],
    inferenceConfig={"maxTokens": 1500},
)

Bénéfices :

  • Modèles Claude (qualité top tier 2026)
  • AWS Bedrock data not used for training (Anthropic policy)
  • Régions EU disponibles (Frankfurt, Ireland)
  • Intégration ecosystem AWS (IAM, KMS, CloudTrail)

Limites :

  • Anthropic est entreprise US, même si AWS Bedrock EU, certaines questions juridiques peuvent rester (contractuelles)
  • Lag potentiel vs Claude direct API

Alternative 4, Google Gemini via Vertex AI (EU)

Setup :

from google.cloud import aiplatform
from vertexai.generative_models import GenerativeModel
 
aiplatform.init(project="my-project", location="europe-west4")  # Pays-Bas
 
model = GenerativeModel("gemini-2.0-pro-exp-2026")
response = model.generate_content(
    "...",
    generation_config={"max_output_tokens": 1500},
)

Bénéfices : si vous êtes déjà ecosystem Google Workspace.

Alternative 5, On-premise modèle open-source

Cf article Architecture sécurisée pour déployer un LLM on-premise. Récap :

  • Llama 3.3 70B / Mistral Large 2 / Qwen 2.5 / DeepSeek V3
  • vLLM ou TGI sur GPU H100 / L40S / A100
  • Souveraineté absolue
  • CapEx 50k-2M€ + expertise

→ Recommandation pour volume très élevé ou IP critique ou secret défense.

Décision multi-critères

CritèreOpenAI standardAzure OpenAI EUMistral EUBedrock Claude EUOn-premise
Souveraineté EU3/108/1010/107/1010/10
Qualité top modèle10/1010/108/1010/107-8/10
Coût (volume modéré)7/107/108/107/105/10
Coût (volume élevé)5/105/106/106/109/10
Effort migrationn/aFaibleMoyenMoyenÉlevé
Conformité sectorielle (HDS, etc.)4/109/108/107/1010/10
Latency8/108/109/108/109/10

Recommandation pragmatique 2026 : Azure OpenAI EU pour 80% des cas, Mistral si souveraineté FR critique, on-premise si volume très élevé / IP stratégique. Hybride avec routing par classification donnée.

Techniques de minimisation et pseudonymisation upstream

Si vous devez envoyer à OpenAI standard malgré tout, mitiger en amont.

Technique 1, Pseudonymisation Presidio

from presidio_analyzer import AnalyzerEngine
from presidio_anonymizer import AnonymizerEngine
from presidio_anonymizer.entities import OperatorConfig
 
analyzer = AnalyzerEngine()
anonymizer = AnonymizerEngine()
 
PII_ENTITIES = ["EMAIL_ADDRESS", "PHONE_NUMBER", "PERSON", "FR_NIR", "IBAN_CODE", "CREDIT_CARD"]
 
# Mapping local pour reverse-substitution
class PIIMapper:
    def __init__(self):
        self._map = {}  # token → real value
        self._counter = {}  # entity_type → counter
    
    def get_token(self, entity_type: str, real_value: str) -> str:
        if real_value in self._map.values():
            return [k for k, v in self._map.items() if v == real_value][0]
        
        self._counter[entity_type] = self._counter.get(entity_type, 0) + 1
        token = f"[{entity_type}_{self._counter[entity_type]:03d}]"
        self._map[token] = real_value
        return token
    
    def reverse(self, text: str) -> str:
        for token, real_value in self._map.items():
            text = text.replace(token, real_value)
        return text
 
 
def pseudonymize_for_llm(text: str, mapper: PIIMapper, language: str = "fr") -> str:
    results = analyzer.analyze(text=text, language=language, entities=PII_ENTITIES)
    
    # Replace from end to start to preserve indices
    text_pseudo = text
    for r in sorted(results, key=lambda x: x.start, reverse=True):
        original = text[r.start:r.end]
        token = mapper.get_token(r.entity_type, original)
        text_pseudo = text_pseudo[:r.start] + token + text_pseudo[r.end:]
    
    return text_pseudo
 
 
# Usage
mapper = PIIMapper()
 
prompt_user = "Bonjour, je suis Marie Dupont (marie.dupont@example.com), pour ma commande #1234..."
prompt_safe = pseudonymize_for_llm(prompt_user, mapper)
# → "Bonjour, je suis [PERSON_001] ([EMAIL_ADDRESS_001]), pour ma commande #1234..."
 
response = await openai_client.chat.completions.create(
    messages=[{"role": "user", "content": prompt_safe}],
    model="gpt-4o",
)
 
answer_safe = response.choices[0].message.content
# La réponse contient les tokens [PERSON_001], [EMAIL_ADDRESS_001]
 
# Re-substituer pour le user final
answer_real = mapper.reverse(answer_safe)
# OpenAI n'a jamais vu marie.dupont@example.com, l'utilisateur final reçoit la version normale

Limites pseudonymisation :

  • Si entropy faible (peu de users), ré-identification possible
  • Si plusieurs prompts liés, attaque par triangulation
  • N'élimine pas le risque de data classifiée article 9

Technique 2, Tokenisation HMAC stable

Pour identifiants techniques (IDs commande, IDs client) qui ne sont pas PII directs mais permettent re-link :

import hmac
import hashlib
import os
 
TOKEN_KEY = os.environ["TOKEN_HMAC_KEY"].encode()
 
def tokenize_id(identifier: str) -> str:
    h = hmac.new(TOKEN_KEY, identifier.encode(), hashlib.sha256).hexdigest()
    return f"id_{h[:12]}"
 
def detokenize_id(token: str, mapping: dict) -> str:
    return mapping.get(token, token)
 
 
# Usage : remplacer les IDs avant envoi LLM
order_id = "ORD-2026-001234"
order_token = tokenize_id(order_id)  # "id_a1b2c3d4e5f6"
 
# Mapper local
mapping[order_token] = order_id
 
prompt = f"Concernant la commande {order_token}..."
# → OpenAI voit le token, pas l'ID réel

Technique 3, Minimisation explicite

def minimize_for_llm(full_context: dict, request_intent: str) -> dict:
    """N'inclure que les infos strictement nécessaires."""
    
    if request_intent == "summarize_email":
        return {"email_body": full_context["email_body"]}
        # Pas d'historique, pas de métadonnées user, pas d'IDs
    
    if request_intent == "classify_ticket":
        return {"ticket_subject": full_context["ticket_subject"], 
                "ticket_first_message": full_context["ticket_first_message"][:500]}
    
    # Refuse si intent inconnu
    raise ValueError(f"Unknown intent: {request_intent}")

Technique 4, Splitting documents

def split_and_filter_relevant(document: str, query: str) -> str:
    """Split doc en chunks, n'envoyer que les chunks pertinents pour la query."""
    chunks = split_into_chunks(document, max_size=500)
    
    # Embedding similarity locale (ne va pas chez OpenAI)
    relevant = filter_by_local_embedding(chunks, query, top_k=3)
    
    return "\n".join(relevant)

Technique 5, Privacy-preserving prompt engineering

# Anti-pattern : exposer noms individuels
prompt = "Qui parmi mes clients John Doe, Jane Smith, Marie Dupont a un crédit > 10k€ ?"
 
# Pattern : exposer info agrégée seulement
prompt = "Classer ces 3 montants en risque/non-risque selon le seuil 10k€ : 5000, 15000, 8000."
# Résoudre le mapping clients-montants en local

Décision documentée pour audit / DPIA

Template DPIA spécifique LLM

# DPIA, Usage OpenAI API pour [Application]
 
## 1. Description du traitement
 
- Application : ZerodaySupport ChatBot SAV v2.4
- Cas d'usage : Réponses automatiques niveau 1 SAV, escalation humaine si complexe
- Volume estimé : ~50 000 conversations/mois
- Données traitées :
  * PII clients (nom, email, téléphone)
  * Numéros commande
  * Historique conversation
- Catégories acteurs :
  * Utilisateurs : clients ZerodaySupport (particuliers EU)
  * Personnel : équipe SAV (visualisation)
  * Sous-traitants : OpenAI (API tier Enterprise)
 
## 2. Nécessité et proportionnalité
 
### Pourquoi ce traitement ?
Réduction temps réponse SAV (-60%), disponibilité 24/7, réduction coût support.
 
### Alternatives évaluées
- Mistral EU : qualité légèrement inférieure pour notre cas (test 2026-Q1, 8/10 vs 10/10)
- Azure OpenAI EU : équivalent qualité, choisie comme alternative en cours d'évaluation
- On-premise : non retenu (CapEx, expertise, volume insuffisant)
 
### Justification choix OpenAI standard (transitoire)
- Migration Azure OpenAI EU planifiée Q3 2026
- Tier API Enterprise + DPA + opt-out training
- Volume actuel ne justifie pas on-premise
 
## 3. Risques identifiés
 
### Confidentialité
- Transit UE→US (Schrems II) : risque MOYEN, atténué par DPA + SCC
- Logs OpenAI 30j : risque FAIBLE post-mitigation pseudonymisation
- Insider OpenAI : risque RÉSIDUEL après mitigations
- Subpoena US : risque RÉSIDUEL FAIBLE (données pseudonymisées)
 
### Intégrité
- Prompt injection : risque MOYEN, mitigation guardrails (classifier + filter)
- Hallucinations : risque MOYEN, disclaimer + escalation humaine
 
### Disponibilité
- Panne OpenAI : risque MOYEN, plan failover Azure OpenAI
 
### Conformité
- RGPD Art. 32 : OK avec mitigations
- RGPD Art. 6 : base légale = legitimate interest (intérêt légitime)
- EU AI Act : non haut risque (Annex III non applicable au SAV générique)
 
## 4. Mitigations implémentées
 
- [x] Pseudonymisation upstream (Presidio), emails, noms, téléphones, IBAN remplacés
- [x] Minimisation : context limité au strict nécessaire
- [x] DPA Enterprise OpenAI signé (réf : DPA-OAI-2025-0042)
- [x] Opt-out training par défaut
- [x] Tier API Enterprise (pas plain ChatGPT)
- [x] Audit logs structurés avec PII redaction
- [x] Disclaimer chatbot IA dans UI
- [x] Right to erasure implémenté (purge logs par user_id_hash)
- [x] Retention 1 an logs sécurité, 90j logs informationnels
- [x] Plan migration Azure OpenAI EU Q3 2026
 
## 5. Risque résiduel
 
Niveau : ACCEPTABLE TRANSITOIREMENT (jusqu'à migration Azure EU).
 
Justification : mitigations couvrent confidentialité courante, transit US 
limité par pseudonymisation, migration imminente vers EU.
 
## 6. Validation
 
- DPO : Marie Lambert, signé 2026-04-15
- RSSI : Jean Bernard, signé 2026-04-15
- AI Officer : Claire Roux, signée 2026-04-15
- Métier : Pierre Martin (Head of Customer Support), signé 2026-04-15
 
## 7. Revue
 
- Cadence : annuelle minimum
- Déclencheurs ad hoc : changement OpenAI ToS, jurisprudence Schrems III, 
  changement classification donnée, incident
- Prochaine review : 2027-04-15
- Migration Azure EU prévue : Q3 2026 → DPIA refresh post-migration

Anti-patterns DPIA

  • DPIA générique copié-collé sans analyse spécifique → auditeur va voir
  • Pas de validation signée → impossible à défendre en audit
  • Pas de versioning → évolutions invisibles
  • Stocké dans email au lieu de système de gouvernance → introuvable

Règle de décision rapide

def should_use_openai_standard(data_classification: str, content: str) -> dict:
    """Aide-décision rapide."""
    
    # Bloqueurs absolus
    if data_classification == "rgpd_article_9":
        return {"decision": "NO", "alternative": "Azure OpenAI EU + DPIA, ou on-premise"}
    
    if contains_secrets(content):  # API keys, passwords
        return {"decision": "NO", "alternative": "Strip secrets first, never send"}
    
    if data_classification == "secret_defense":
        return {"decision": "NO", "alternative": "On-premise air-gap obligatoire"}
    
    if data_classification == "confidential" and not has_pseudonymization(content):
        return {"decision": "MAYBE", "condition": "Pseudonymize first, then OK with Enterprise tier"}
    
    # Acceptable
    if data_classification in {"public", "internal"}:
        return {"decision": "YES", "tier": "OpenAI Enterprise"}
    
    # Default : besoin DPIA
    return {"decision": "DPIA_REQUIRED", "next": "Run DPIA before decision"}

Erreurs récurrentes 2026

Erreur 1, "TLS suffit"

Croyance largement répandue. TLS = transit. Stockage tiers + insider + subpoena = autre histoire.

Erreur 2, Penser pouvoir E2EE applicatif

Pas possible avec API LLM standard. Confidential Computing partiel ou rien.

Erreur 3, Envoyer secrets / passwords

Souvent involontaire (logs apps mal préparés). Strip avant prompt.

Erreur 4, Pas de DPIA pour usage entreprise

Violation RGPD si données personnelles. DPIA obligatoire dès traitement de PII massif.

Erreur 5, ChatGPT plain pour usage corporate

Tier inadapté entreprise. Toujours minimum tier Enterprise.

Erreur 6, Pas de pseudonymisation

PII envoyés en clair "parce que OpenAI ne fait pas de training". OK pour training mais 30j de logs en clair restent. Pseudonymisation upstream quand possible.

Erreur 7, Pas d'alternative évaluée

"OpenAI parce que c'est connu". Évaluer Azure OpenAI EU systématiquement.

Erreur 8, DPIA générique

Copié-collé sans analyse. DPIA spécifique au cas d'usage.

Ce que vous devriez retenir

  1. TLS 1.3 = baseline nécessaire mais pas suffisant pour données sensibles
  2. E2EE applicatif = pas possible avec OpenAI API standard
  3. Confidential Computing = solution partielle émergente, peu mature 2026
  4. FHE = théoriquement possible, pratiquement inutilisable
  5. Données à NE JAMAIS envoyer : RGPD Art. 9, secrets, IP critique, classifié défense
  6. Alternatives 2026 : Azure OpenAI EU (#1 recommandé), Mistral EU, Bedrock Claude EU, on-premise
  7. Si OpenAI standard nécessaire : pseudonymisation Presidio + minimisation + tokenisation + tier Enterprise
  8. DPIA documentée signée DPO + RSSI + AI Officer + métier
  9. Décision multi-critères matrice pondérée
  10. Cadence revue annuelle + déclencheurs ad hoc

Le chiffrement seul ne résout pas le problème. La vraie question est : quelles données envoyer et où. Les choix architecturaux (Azure EU, Mistral, on-premise) ont plus d'impact que des techniques de chiffrement applicatives qui ne sont pas vraiment possibles avec l'API standard.

Pour les données sensibles, en 2026, Azure OpenAI Service en région EU est le compromis pragmatique pour la majorité des entreprises EU. Pour la souveraineté absolue, on-premise. Pour les données publiques / non sensibles, OpenAI standard reste OK avec les bonnes mitigations.


Pour aller plus loin : pour le panorama global des risques d'intégrer ChatGPT : quels sont les risques si j'intègre ChatGPT dans mon SI. Pour la couche zero-trust générale : chiffrement, isolation et zero-trust appliqués aux workloads IA.

Questions fréquentes

  • Le TLS qu'OpenAI utilise par défaut n'est-il pas suffisant ?
    **TLS 1.3** sécurise le **transit** entre votre app et l'API OpenAI : confidentialité, intégrité, authentification serveur. Suffisant pour empêcher un attaquant réseau de lire les prompts en transit. Mais TLS ne couvre PAS : (1) **Stockage côté OpenAI** : prompts/réponses stockés 30j sur serveurs OpenAI (logs abuse monitoring), théoriquement non utilisés pour training en tier API standard mais accessibles aux employés OpenAI sous certaines conditions (review abuse). (2) **Subpoena US** : autorités US peuvent demander accès aux logs (FISA, CLOUD Act), TLS ne protège pas. (3) **Transferts UE→US** : RGPD problème post-Schrems II, TLS n'est pas une mesure suffisante au regard du droit RGPD pour data transfers, exige Standard Contractual Clauses + Transfer Impact Assessment. (4) **Insider threat OpenAI** : employés peuvent voir prompts si abuse review, TLS terminé chez OpenAI. (5) **Compromission OpenAI** : breach hypothétique chez OpenAI exposerait prompts loggués, TLS protège transit, pas stockage tiers. **Conclusion** : TLS = baseline nécessaire mais **pas suffisant** pour données sensibles. Mesures supplémentaires requises selon classification donnée et conformité visée.
  • Le end-to-end encryption (E2EE) avec OpenAI est-il techniquement possible ?
    **Non**, pas avec API OpenAI standard. Raison fondamentale : pour qu'un LLM puisse **traiter** un prompt, il doit le **lire en clair**. Si le prompt arrive chiffré et qu'OpenAI n'a pas la clé, OpenAI ne peut rien en faire. Solutions partielles 2024-2026. (1) **Confidential Computing** (Intel TDX, AMD SEV-SNP, NVIDIA H100 TEE) : OpenAI annonce *Private Cloud Compute*-style features mais limité encore en 2026. Permet exécution dans TEE, admin OpenAI ne peut pas inspecter mémoire. Pas vraiment E2EE mais réduction de surface insider/host. (2) **Apple Private Cloud Compute** (introduit 2024, étendu 2025-2026) : Apple's pattern où prompts chiffrés transits, déchiffrés UNIQUEMENT dans TEE attesté, traités, puis détruits. Modèle de référence pour 'private inference at scale'. Pas accessible directement chez OpenAI mais inspire l'industrie. (3) **Homomorphic encryption** (FHE) : permet calcul sur données chiffrées. Théoriquement E2EE compatible LLM. **Réalité 2026** : FHE pour LLMs est ~1000-10000× plus lent que inference standard. Inutilisable production sauf cas extrême. Recherche active mais pas mature. **Conclusion pratique** : pas d'E2EE applicatif possible avec OpenAI standard. Pour zéro-trust strict : on-premise.
  • Quelles données ne JAMAIS envoyer à OpenAI sans précautions supplémentaires ?
    Liste explicite. (1) **Données régulées RGPD article 9** (données sensibles) : santé, opinion politique, religion, orientation sexuelle, données génétiques/biométriques, condamnations pénales. Sans DPIA + base légale solide + souvent meilleur de ne pas. (2) **Secrets industriels / IP critique** : code propriétaire stratégique, formules brevet en cours, M&A en cours. Risque insider OpenAI + subpoena. (3) **Secrets techniques** : passwords, API keys, certificates, clés privées, JWT tokens. Risque leak via logs OpenAI. (4) **PII massif clients** : milliers d'emails/téléphones/adresses dans un seul prompt. DPIA + minimisation principle violé. (5) **Données classifiées défense / secret défense** : interdit par law dans la plupart des juridictions. (6) **Données pseudonymisées non robustes** : si pseudonymisation cassable, équivaut à PII. (7) **Données soumises à confidentialité contractuelle stricte** : contrats clients avec NDA, dépend des termes. **Vérifier dans CGU/DPA OpenAI** : à jour 2026, OpenAI Enterprise + API tier permettent zero-data retention sur demande, opt-out training par défaut, hébergement régional limité. Lire DPA actuel sur openai.com/policies. **Recommandation** : pour ces classes, privilégier Azure OpenAI EU, Mistral EU, ou on-premise.
  • Quelles alternatives concrètes pour réduire le risque de transfert vers les US ?
    Cinq alternatives par ordre d'effort/impact. (1) **Azure OpenAI Service (région EU)** : modèles OpenAI hébergés sur Azure dans région EU choisie (France Central, North Europe, Sweden Central). Pas de transfert US, conformité Azure héritée (HDS, ISO, BSI C5). DPA Microsoft Enterprise. **Effort migration** : faible si vous utilisez déjà Azure. **Recommandation #1 pour entreprise EU**. (2) **Mistral AI (France)** : Le Chat / API, modèles compétitifs (Mistral Large 2, Codestral). Souveraineté EU forte, hébergement France. **Effort** : moyen (modèles différents, prompts à adapter parfois). (3) **Anthropic via AWS Bedrock EU** : Claude hébergé sur AWS Bedrock dans région EU (Frankfurt, Ireland). Anthropic ne stocke pas data. **Effort** : moyen. (4) **Google Gemini via Vertex AI (région EU)** : modèles Gemini sur Vertex en région EU. Si déjà ecosystem Google. (5) **On-premise modèle open-source** (Llama 3.3, Mistral, Qwen 2.5) : contrôle complet, souveraineté absolue. **Effort** : élevé (CapEx GPU, expertise). **Recommandation pragmatique 2026** : Azure OpenAI EU pour 80% des cas, Mistral EU si souveraineté FR critique, on-premise si volume élevé ou IP stratégique. Hybride avec routing par classification donnée pour optimum coût/risque.
  • Comment chiffrer / minimiser ce qui doit aller à OpenAI quand on n'a pas le choix ?
    Cinq techniques. (1) **Pseudonymisation upstream** : avant envoi, remplacer PII par tokens (Presidio anonymizer). Email → `[EMAIL_001]`, nom → `[PERSON_001]`. Maintenir mapping en local (jamais chez OpenAI). Re-substituer dans la réponse. (2) **Minimisation** : envoyer SEULEMENT le strict nécessaire. Si la question est 'résume cet email', n'envoyer que l'email ; pas tout le contexte. (3) **Tokenisation strong** : pour identifiants (numéros commande, IDs internes), remplacer par tokens dérivés HMAC stables. OpenAI voit les tokens, pas les vrais IDs. (4) **Splitting** : pour gros documents avec PII, diviser en chunks et n'envoyer que ceux pertinents pour la requête. (5) **Privacy-preserving prompt engineering** : reformuler la requête pour qu'elle n'expose pas plus que nécessaire (ex: 'Notre client de la région X' plutôt que noms individuels). **Limites** : pseudonymisation peut être cassée si entropy faible (peu de users). Tokenisation ajoute complexité. Ces techniques **réduisent** le risque mais ne l'éliminent pas. **Anti-pattern** : chiffrer le prompt avec une clé qu'OpenAI n'a pas, le LLM ne peut pas traiter. Ne marche pas. Le seul chiffrement compatible OpenAI est TLS in-transit + Confidential Computing au sens TEE.
  • Quelle décision de conformité documenter pour audit / DPIA ?
    Document type DPIA spécifique LLM, sections recommandées. **(1) Description du traitement** : quelle app, quel cas d'usage, quel volume estimé, quelles données traitées (catégories), quels acteurs (utilisateurs, dev, OpenAI). **(2) Nécessité et proportionnalité** : pourquoi cette app, alternatives évaluées (Azure OpenAI EU, Mistral, on-premise), justification choix OpenAI standard si retenu. **(3) Risques identifiés** : a) Confidentialité (transit US, logs OpenAI, insider, subpoena), b) Intégrité (prompt injection, output untrusted), c) Disponibilité (panne OpenAI), d) Conformité (Schrems II, RGPD article 32, EU AI Act selon classification). **(4) Mitigations** : pseudonymisation upstream (Presidio), minimisation, classification données, opt-out training, DPA Enterprise signé, monitoring usage. **(5) Risque résiduel** : après mitigations, niveau de risque acceptable ? Décision RSSI + DPO. **(6) Validation** : signature DPO + RSSI + AI Officer + métier. Date + version. **(7) Revue** : cadence annuelle + déclencheurs (changement OpenAI ToS, nouvelles décisions juridiques, nouvelles régulations). **Anti-pattern** : DPIA générique copié-collé sans analyse spécifique. Auditeur va voir. **Bonne pratique** : 5-10 pages spécifiques, signed off, archivées avec versioning. À refaire si changement majeur.

Écrit par

Naim Aouaichia

Cyber Security Engineer et fondateur de Zeroday Cyber Academy

Ingénieur cybersécurité avec un parcours hybride : développement, DevOps Capgemini, DevSecOps IN Groupe (sécurité des documents d'identité régaliens), audits CAC 40. Fondateur de Hash24Security et Zeroday Cyber Academy. Présence LinkedIn 43 000 abonnés, Substack Zeroday Notes 23 000 abonnés.