Pourquoi le DLP réseau échoue face à ChatGPT

L'angle mort que votre éditeur DLP ne mentionnera jamais

Ouvrez votre SIEM et cherchez les incidents DLP liés à chatgpt.com, claude.ai ou gemini.google.com sur les trente derniers jours. Dans la plupart des organisations, le compteur reste à zéro. Non pas parce que personne n'a collé de données sensibles — la télémétrie d'usage montre qu'un collaborateur médian utilise ChatGPT 22 fois par semaine — mais parce que la pile DLP est physiquement incapable de voir à l'intérieur de la session. Le handshake TLS se termine, la réponse en streaming arrive, et le proxy reste à compter des octets qu'il ne sait pas lire.

Ce n'est pas un problème de réglage. C'est un problème d'architecture. Toutes les catégories de DLP d'avant 2023 — Symantec, Forcepoint, Microsoft Purview utilisé au niveau réseau, Netskope CASB, Zscaler — ont été conçues pour un web qui n'existe plus. Reprenons proprement les raisons, puis comparons ce que les alternatives livrent réellement en production.

TLS 1.3, épinglage de certificat et fin du MITM

Le DLP de passerelle classique fonctionne en terminant TLS au milieu. L'autorité de certification de l'entreprise est poussée sur tous les postes managés, le proxy présente un faux certificat pour chatgpt.com, le navigateur lui fait confiance puisque la racine est installée, et le proxy lit le contenu en clair. Ce modèle a tenu dix ans. Il est structurellement cassé pour trois raisons.

Premièrement, TLS 1.3 avec reprise 0-RTT masque une grande partie du handshake — y compris le SNI dans plusieurs configurations — derrière des données précoces. Deuxièmement, les navigateurs modernes embarquent une liste codée en dur d'épinglages de certificats pour les domaines à forte valeur, et Chromium impose de plus en plus la Certificate Transparency avec validation SCT. Un proxy qui injecte son propre certificat déclenche un échec dur, pas un avertissement contournable. Troisièmement, Encrypted Client Hello (ECH) est en cours de déploiement sur tous les services frontés par Cloudflare. Une fois ECH obligatoire, le proxy ne verra même plus quel nom d'hôte est contacté, et encore moins le contenu du corps.

L'application desktop d'OpenAI et la Console Anthropic épinglent explicitement leurs appels d'API de première partie. Une tentative de MITM ne fait pas de l'inspection silencieuse — elle casse la connexion. Les équipes sécurité qui forcent ce passage finissent avec une avalanche de tickets helpdesk et zéro visibilité.

Le framing WebSocket tue l'inspection du contenu, même si le MITM passe

Imaginons un instant que vous parveniez à terminer TLS sur votre propre proxy. Vous ne pourrez toujours pas lire la conversation. ChatGPT et Claude n'envoient pas une requête puis reçoivent une réponse JSON. Ils ouvrent un WebSocket persistant (ou un flux Server-Sent Events) sur le même canal TLS et échangent des trames binaires qui transportent à la fois le prompt utilisateur et la complétion en streaming, jeton par jeton.

La plupart des moteurs DLP de proxy ne parsent tout simplement pas les trames WebSocket. Ceux qui le font appliquent du pattern matching sur un framing opaque sans comprendre le protocole conversationnel — ils voient un blob d'octets, ratent la frontière de prompt, et soit laissent tout passer soit bloquent tout. Idem pour le transport gRPC-Web de Gemini. Le streaming est l'UX par défaut de l'IA moderne, et c'est exactement ce que les DLP de passerelle n'ont jamais été conçus pour lire.

Le piège du "on bloque simplement le domaine"

Le premier réflexe d'une équipe sécurité débordée est la règle pare-feu : bloquer chat.openai.com en sortie. C'est l'équivalent cyber de verrouiller la porte d'entrée en laissant toutes les fenêtres ouvertes. Trois choses se produisent en une semaine.

• Les collaborateurs basculent sur mobile. Les 22 prompts par semaine deviennent 22 prompts sur un téléphone personnel, hors réseau, sans aucun log.
• Le shadow AI explose. Les gens créent des comptes personnels avec des e-mails personnels et utilisent des outils que la sécurité n'a jamais entendus — DeepSeek, Poe, You.com, Le Chat de Mistral, une douzaine de wrappers ChatGPT.
• Le métier exige une exception. Marketing, juridique, ingénierie défendent — à juste titre — leur besoin d'outil. La DSI accorde des dérogations utilisateur par utilisateur, et la politique s'effondre.

Bloquer le domaine crée l'illusion du contrôle tout en rendant la fuite réelle plus difficile à voir. La CNIL, le BfDI et l'ICO ont publié des lignes directrices qui rappellent qu'un usage non surveillé est une posture de conformité pire que l'usage surveillé, même quand celui-ci traverse techniquement une frontière.

CASB : mieux, avec un trou de la taille de "chaque nouvel outil IA"

Les plateformes CASB (Netskope, Zscaler, Microsoft Defender for Cloud Apps) ont amélioré la situation en devenant cloud-natives. Elles ont des intégrations API avec le SaaS validé, savent appliquer une politique sur les tenants OpenAI Enterprise, et comprennent davantage du handshake moderne. Pour ChatGPT Enterprise et Microsoft Copilot pour M365, un CASB fait du vrai travail.

Le trou, c'est la longue traîne. Le CASB exige que l'éditeur ait écrit un connecteur pour l'outil concerné. Pas de connecteur Netskope pour Le Chat de Mistral en gratuit, pas de politique Zscaler pour une instance Ollama auto-hébergée sur le laptop d'un dev, pas de visibilité Defender sur les dix-sept extensions de navigateur ChatGPT qu'un employé a installées. Les éditeurs CASB appellent ça "mode Universal" ou "couverture toute application", et ça veut presque toujours dire heuristiques de motif de trafic, pas inspection de contenu. Vous voyez que quelque chose est parti quelque part d'IA; vous ne voyez pas ce qu'il y avait dans le prompt.

Ajoutez la latence. Le CASB inline route chaque session de navigateur via un PoP éditeur. Pour un utilisateur parisien qui interroge Claude sur us-east-1, c'est une pénalité mesurable sur une réponse en streaming déjà sensible à la latence. Les utilisateurs le remarquent. Les utilisateurs contournent.

Isolation navigateur : ça marche, et presque personne ne s'en sert deux fois

Cloudflare Browser Isolation, Forcepoint RBI et Menlo résolvent le problème d'inspection en déplaçant le navigateur lui-même dans le cloud. L'écran local ne reçoit que des pixels ; copier-coller et upload de fichier sont interceptés au niveau de l'isolation. D'un point de vue DLP pur, c'est l'option passerelle la plus solide.

Le coût se ressent immédiatement côté utilisateur. Latence du copier-coller, rendu Markdown cassé, déconnexions WebSocket occasionnelles sur les longues complétions Claude, boucles SSO Google, génération d'image téléchargée en capture plate plutôt qu'en vrai fichier. Les enquêtes d'adoption montrent invariablement que les déploiements d'isolation s'effondrent en six mois, à moins que la sécurité n'accepte que 30 à 50 % des utilisateurs trouveront un contournement. L'économique est aussi brutale : la tarification par siège pour le RBI est typiquement 4 à 8 fois supérieure à une approche client-side.

L'isolation navigateur est la réponse techniquement correcte à une question que personne hors de la sécurité ne veut poser. Ça marche en laboratoire et ça meurt dans l'organigramme.

L'approche client-side : se placer dans le navigateur, pas devant

La seule architecture qui survit à TLS 1.3, ECH, au framing WebSocket, au repli mobile et au shadow AI est celle qui s'exécute entre l'utilisateur et la couche de chiffrement : dans le navigateur lui-même, en extension, et sur le poste comme agent natif pour les apps qui contournent le navigateur. C'est l'approche Zeuslock.

En accrochant le DOM et l'API WebSocket du navigateur, le prompt est inspecté avant que TLS ne l'enveloppe. Le pipeline de détection à trois couches — regex local pour les correspondances évidentes, modèle NER fine-tuné, puis heuristiques contextuelles — tourne côté client en quelques millisecondes, avec une confirmation optionnelle par une API ML hébergée en UE. Aucun certificat à installer. Aucun trafic à rerouter. Aucune latence ajoutée au flux de réponse. L'utilisateur voit un avertissement inline, une anonymisation automatique (une vraie clé AWS AKIA remplacée par un faux structurellement valide), ou un blocage dur, selon le mode de politique.

Le même moteur s'étend à Claude Code, Cursor, Copilot CLI et Aider via le CLI Zeuslock et l'agent desktop. Le trafic MCP entre agents et outils est inspecté à la frontière du protocole. Le mode Universal couvre les outils que l'équipe n'a jamais entendus, parce que la détection porte sur le contenu du prompt, pas sur une liste blanche éditeur.

Comparaison honnête

Ce qu'il faut faire ce trimestre

1. Sortez un rapport 30 jours de votre DLP existant filtré sur chatgpt.com, claude.ai, gemini.google.com et copilot.microsoft.com. Si le compteur d'incidents est anormalement bas, vous avez l'angle mort.
2. Mesurez l'usage réel avec un pilote de télémétrie côté navigateur sur 2 semaines. Attendez-vous à 5 à 10 fois plus de trafic IA que ce que voit votre passerelle.
3. Déployez une extension client-side en mode Monitor pour les semaines 1-2, Anonymize pour 3-5, Block sur les types de détection les plus sensibles à partir de la semaine 6. La progression est dans le guide de configuration des politiques.
4. Désactivez les règles proxy qui ciblent les domaines IA. Elles vous donnent un faux confort.