{"id":13301,"date":"2026-05-27T09:00:58","date_gmt":"2026-05-27T07:00:58","guid":{"rendered":"https:\/\/jimber.io\/?p=13301"},"modified":"2026-05-27T09:00:58","modified_gmt":"2026-05-27T07:00:58","slug":"inspection-du-trafic-chiffre-en-2026-comment-sase-gere-tls-1-3-quic-et-lepinglage-des-certificats","status":"publish","type":"post","link":"https:\/\/jimber.io\/fr\/blog\/inspection-du-trafic-chiffre-en-2026-comment-sase-gere-tls-1-3-quic-et-lepinglage-des-certificats\/","title":{"rendered":"Inspection du trafic chiffr\u00e9 en 2026 : comment SASE g\u00e8re TLS 1.3, QUIC et l’\u00e9pinglage des certificats"},"content":{"rendered":"

TL;DR.<\/strong> Environ 94 % du trafic web passe d\u00e9sormais par HTTPS, et les protocoles sous-jacents ont chang\u00e9. TLS 1.3 a supprim\u00e9 les m\u00e9tadonn\u00e9es en clair, QUIC chiffre la quasi-totalit\u00e9 de la poign\u00e9e de main sur UDP et Encrypted ClientHello cache la destination aux proxys passifs. Les plateformes SASE modernes proc\u00e8dent \u00e0 des inspections s\u00e9lectives, en combinant un d\u00e9cryptage tenant compte du protocole avec des exclusions bas\u00e9es sur la cat\u00e9gorie pour le trafic sensible \u00e0 la vie priv\u00e9e. En 2026, la question n’est plus de savoir s’il faut tout d\u00e9chiffrer, mais quel trafic doit r\u00e9ellement \u00eatre inspect\u00e9 compte tenu des changements de protocole et des contraintes de l’UE en mati\u00e8re de protection de la vie priv\u00e9e. <\/p>\n

Environ 94 % des requ\u00eates web utiliseront HTTPS en 2026, et les protocoles cryptographiques sous l’ic\u00f4ne du cadenas ont \u00e9volu\u00e9 d’une mani\u00e8re qui brise l’inspection existante. Si votre passerelle web s\u00e9curis\u00e9e expliqu\u00e9e pour SASE<\/a> a \u00e9t\u00e9 con\u00e7ue pour TLS 1.2 sur TCP, elle est d\u00e9j\u00e0 partiellement aveugle. Cet article s’adresse aux responsables de la s\u00e9curit\u00e9 et de l’informatique qui choisissent comment leur plateforme Secure Access Service Edge<\/a> doit g\u00e9rer les compromis en mati\u00e8re d’inspection. Nous supposons que vous savez d\u00e9j\u00e0 ce que fait une passerelle web s\u00e9curis\u00e9e, et nous nous concentrons donc sur la partie que la plupart des fournisseurs n\u00e9gligent : comment le d\u00e9cryptage fonctionne r\u00e9ellement sur TLS 1.3, ce que QUIC fait aux architectures bas\u00e9es sur le proxy, et pourquoi le d\u00e9cryptage s\u00e9lectif est devenu le mod\u00e8le pr\u00e9dominant dans les d\u00e9ploiements europ\u00e9ens. <\/p>\n

Pourquoi TLS 1.3 a mis fin \u00e0 l’inspection traditionnelle<\/h2>\n

TLS 1.3, d\u00e9fini dans la RFC 8446, a \u00e9t\u00e9 con\u00e7u dans un souci de protection de la vie priv\u00e9e. Il a supprim\u00e9 l’\u00e9change de cl\u00e9s en clair que TLS 1.2 exposait, crypte le certificat du serveur imm\u00e9diatement apr\u00e8s la poign\u00e9e de main et impose des cl\u00e9s Diffie-Hellman \u00e9ph\u00e9m\u00e8res pour chaque session. Le Perfect Forward Secrecy n’est plus optionnel. Le d\u00e9cryptage passif hors bande, qui permet \u00e0 un dispositif d’inspection de conserver une copie de la cl\u00e9 priv\u00e9e du serveur et de d\u00e9crypter le trafic captur\u00e9 hors ligne, ne fonctionne plus. <\/p>\n

Le secret de session partag\u00e9 est n\u00e9goci\u00e9 \u00e0 l’aide de param\u00e8tres ECDHE \u00e9ph\u00e9m\u00e8res, sign\u00e9 pour chaque session et supprim\u00e9 \u00e0 la fin de la connexion. La compromission de la cl\u00e9 \u00e0 long terme du serveur demain ne vous permettra pas de d\u00e9crypter r\u00e9troactivement le trafic captur\u00e9 hier. L’inspection d’entreprise n\u00e9cessite d\u00e9sormais un proxy actif au niveau de la passerelle SASE qui met fin \u00e0 la connexion, d\u00e9crypte, recrypte jusqu’\u00e0 la destination et s’appuie sur des dispositifs g\u00e9r\u00e9s qui font confiance \u00e0 l’autorit\u00e9 de certification racine de la passerelle. <\/p>\n

Dans TLS 1.2, un dispositif d’inspection pouvait analyser le SNI et le certificat du serveur en clair. Dans TLS 1.3, le certificat est chiffr\u00e9 d\u00e8s que l’\u00e9change de cl\u00e9s est termin\u00e9. Combin\u00e9 \u00e0 la reprise anticip\u00e9e des donn\u00e9es 0-RTT, cela donne aux proxys moins de m\u00e9tadonn\u00e9es \u00e0 utiliser avant de d\u00e9cider d’autoriser ou non la connexion. Pour les appareils non g\u00e9r\u00e9s, sans AC racine d’entreprise install\u00e9e, l’inspection TLS 1.3 n’est pas un probl\u00e8me de r\u00e9glage. Elle est impossible. <\/p>\n

ClientHello crypt\u00e9 modifie l’hypoth\u00e8se SNI<\/h3>\n

Le dernier signal en clair dans une connexion TLS 1.3, l’extension SNI dans le ClientHello initial, est en train de dispara\u00eetre. Le ClientHello chiffr\u00e9, sp\u00e9cifi\u00e9 dans la RFC 9849, divise la poign\u00e9e de main en un ClientHello ext\u00e9rieur avec un domaine de couverture g\u00e9n\u00e9rique et un ClientHello int\u00e9rieur chiffr\u00e9 \u00e0 l’aide d’un chiffrement hybride \u00e0 cl\u00e9 publique avec une cl\u00e9 que le serveur publie par le biais du DNS. <\/p>\n

L’adoption d’ECH est concentr\u00e9e plut\u00f4t qu’universelle. Cloudflare applique l’ECH dans toute sa p\u00e9riph\u00e9rie, bien qu’environ 30 % des origines h\u00e9berg\u00e9es par Cloudflare ne publient toujours pas de configuration ECH. Chrome, \u00e0 partir de la version 117, et Firefox n\u00e9gocient tous deux l’ECH de mani\u00e8re native lorsqu’ils r\u00e9solvent l’enregistrement de ressource HTTPS conform\u00e9ment \u00e0 la RFC 9460. Edge suit le comportement de Chrome. <\/p>\n

Le filtrage SNI, la technique l\u00e9g\u00e8re par laquelle un proxy lit le domaine de destination \u00e0 partir du ClientHello non chiffr\u00e9, ne fonctionne pas lorsque l’ECH est en jeu. Deux solutions d’att\u00e9nuation pour les entreprises sont en train d’\u00e9merger. La premi\u00e8re consiste \u00e0 mettre en place une politique de navigateur qui d\u00e9sactive l’ECH sur les appareils g\u00e9r\u00e9s, comme le param\u00e8tre EncryptedClientHelloEnabled<\/code> de Chrome. La seconde consiste \u00e0 contr\u00f4ler le chemin DNS : un r\u00e9solveur contr\u00f4l\u00e9 par SASE peut supprimer les enregistrements de ressources HTTPS ou renvoyer NXDOMAIN pour les enregistrements qui publient les cl\u00e9s ECH, ce qui am\u00e8ne les navigateurs \u00e0 revenir au comportement SNI standard. Aucune de ces solutions n’est \u00e9l\u00e9gante. Les deux fonctionnent. <\/p>\n

QUIC, HTTP\/3 et l’angle mort de l’inspection<\/h2>\n

QUIC, d\u00e9fini dans le RFC 9000, n’est pas TLS sur UDP. Il s’agit d’un nouveau protocole de transport qui int\u00e8gre TLS 1.3 directement dans la couche de connexion, crypte la plupart des en-t\u00eates de paquets, y compris les identifiants de connexion et les num\u00e9ros de paquets, et fonctionne sur UDP\/443 au lieu de TCP\/443. HTTP\/3, sp\u00e9cifi\u00e9 dans la RFC 9114, se trouve au-dessus. Pour les architectures d’inspection construites autour des proxys TCP, QUIC est un probl\u00e8me plus difficile que TLS 1.3. <\/p>\n

L’adoption s’est d\u00e9roul\u00e9e diff\u00e9remment des premi\u00e8res pr\u00e9visions. Le trafic HTTP\/3 repr\u00e9sente environ 21 % des requ\u00eates web mondiales au deuxi\u00e8me trimestre 2026, bien en de\u00e7\u00e0 du seuil de 30 % pr\u00e9dit par certains. HTTP\/2 sur TCP domine toujours avec 51 %, et HTTP\/1.x conserve environ 28 %. La r\u00e9partition est r\u00e9gionale : en Italie, les parts de HTTP\/3 d\u00e9passent les 30 %, tandis que les Pays-Bas et Singapour restent proches des 8-10 %. Les services qui poussent fortement QUIC, Google, YouTube, Gmail, Meta, WhatsApp et certaines parties de la pile de Microsoft, repr\u00e9sentent une part disproportionn\u00e9e du temps de l’utilisateur final. <\/p>\n

Trois mod\u00e8les architecturaux dominent les r\u00e9ponses des fournisseurs \u00e0 QUIC. Block and fall back<\/strong> drops outbound UDP\/443, and HTTP\/3-capable browsers fall back to TLS 1.3 over TCP automatically. Il s’agit du mod\u00e8le dominant, utilis\u00e9 par d\u00e9faut par Zscaler, Cato et Palo Alto Prisma Access. Le proxy QUIC natif<\/strong> termine le flux QUIC entrant au niveau d’un proxy compatible UDP, d\u00e9chiffre la charge utile et se connecte \u00e0 l’origine soit par QUIC, soit en r\u00e9trogradant vers HTTP\/2 sur TCP. Cloudflare One prend en charge cette fonctionnalit\u00e9, tout comme FortiSASE. La limitation du d\u00e9bit UDP avec analyse comportementale<\/strong> autorise l’UDP non classifi\u00e9 mais applique des limites strictes par connexion et une d\u00e9tection heuristique, g\u00e9n\u00e9ralement en tant que couche de confinement derri\u00e8re l’une des deux autres. <\/p>\n

Cons\u00e9quence pratique pour les acheteurs du march\u00e9 interm\u00e9diaire : si la r\u00e9ponse de votre fournisseur de SASE \u00e0 la question \u00ab\u00a0comment g\u00e9rez-vous QUIC ?\u00a0\u00bb est \u00ab\u00a0nous le bloquons\u00a0\u00bb, c’est honn\u00eate, mais pr\u00e9voyez des plaintes d’utilisateurs concernant les performances des vid\u00e9os et des chats. Si la r\u00e9ponse est \u00ab\u00a0nous l’inspectons de mani\u00e8re native\u00a0\u00bb, demandez une documentation sur l’architecture du proxy et sur les combinaisons navigateur-origine qui ont \u00e9t\u00e9 test\u00e9es. <\/p>\n

L’\u00e9pinglage de certificats et les applications que vous ne pouvez pas d\u00e9crypter<\/h2>\n

M\u00eame avec une inspection QUIC native et une autorit\u00e9 de certification racine parfaitement d\u00e9ploy\u00e9e, une partie du trafic ne sera pas d\u00e9crypt\u00e9e. L’\u00e9pinglage de certificats au niveau de l’application, o\u00f9 le binaire d’une application int\u00e8gre l’empreinte de la cl\u00e9 publique de son certificat de serveur attendu et rejette tout le reste, s’est r\u00e9pandu bien au-del\u00e0 des applications bancaires. L’\u00e9pinglage de la cl\u00e9 publique HTTP est obsol\u00e8te depuis 2018, mais l’\u00e9pinglage \u00e0 l’int\u00e9rieur des applications mobiles et de bureau natives est toujours d’actualit\u00e9 et se d\u00e9veloppe. <\/p>\n

Lorsqu’un proxy SASE intercepte une connexion \u00e9pingl\u00e9e, il pr\u00e9sente \u00e0 l’utilisateur un certificat de feuille sign\u00e9 par l’autorit\u00e9 de certification racine de l’entreprise. Les navigateurs l’acceptent. Les applications \u00e9pingl\u00e9es ne l’acceptent pas. Elles comparent la cl\u00e9 publique du certificat \u00e0 l’identifiant cod\u00e9 en dur, constatent une incoh\u00e9rence et interrompent la connexion en \u00e9mettant une alerte fatale TLS. L’utilisateur constate que l’application ne parvient pas \u00e0 se connecter, souvent sans message d’erreur exploitable. <\/p>\n

La liste des applications les plus couramment \u00e9pingl\u00e9es en 2026 est suffisamment longue pour influencer l’\u00e9laboration des politiques plut\u00f4t que de constituer un cas d’esp\u00e8ce.<\/p>\n

\n\n\n\n\n\n\n\n\n\n
Cat\u00e9gorie<\/th>\nApplications qui \u00e9pinglent de mani\u00e8re agressive<\/th>\n<\/tr>\n<\/thead>\n
Messagerie<\/td>\nWhatsApp, Signal, Telegram<\/td>\n<\/tr>\n
Services mobiles et OS<\/td>\nApple iCloud, service de notification push d’Apple, Apple App Store, services Google Play<\/td>\n<\/tr>\n
Collaboration et SaaS<\/td>\nMicrosoft Teams, Slack, Salesforce, Zoom, Google Drive, Google Maps<\/td>\n<\/tr>\n
Plateformes de consommateurs<\/td>\nSpotify, Netflix, Discord<\/td>\n<\/tr>\n
Services financiers<\/td>\nApplications bancaires mobiles, API Stripe, PayPal<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n

L’\u00e9pinglage d\u00e9fend les utilisateurs contre les autorit\u00e9s de certification malhonn\u00eates ou compromises, ce qui est une pr\u00e9occupation l\u00e9gitime. Le traiter comme un obstacle \u00e0 surmonter n’est pas la bonne approche. Certaines cat\u00e9gories de trafic ne seront pas d\u00e9crypt\u00e9es, quelle que soit la capacit\u00e9 du fournisseur. Les plates-formes SASE modernes maintiennent des listes de contournement mises \u00e0 jour dynamiquement qui exemptent les services \u00e9pingl\u00e9s et leur substituent d’autres contr\u00f4les : Le filtrage de la couche DNS, la r\u00e9putation IP et les contr\u00f4les de posture des points d’extr\u00e9mit\u00e9. C’est l’une des raisons pour lesquelles le d\u00e9cryptage s\u00e9lectif l’emporte sur le d\u00e9cryptage int\u00e9gral dans la pratique. <\/p>\n

Le DNS crypt\u00e9 contourne les politiques SASE par d\u00e9faut<\/h2>\n

Le DNS \u00e9tait autrefois la couche la plus simple d’une pile de s\u00e9curit\u00e9. UDP\/53, texte clair, facile \u00e0 enregistrer et \u00e0 filtrer. Cette hypoth\u00e8se ne tient plus. \u00c0 la mi-2026, environ 81 \u00e0 83 % des requ\u00eates DNS mondiales utiliseront un transport crypt\u00e9, avec DoH \u00e0 environ 72 %, DoT \u00e0 10-12 %, et DoQ marginal \u00e0 moins de 1 %. Le taux d’utilisation du protocole UDP\/53 est tomb\u00e9 \u00e0 environ 17 %. <\/p>\n

Les param\u00e8tres par d\u00e9faut des navigateurs constituent le point de pression pratique. Chrome et Edge passent automatiquement le DNS \u00e0 DoH lorsque le r\u00e9solveur du syst\u00e8me est un grand fournisseur public connu qui le prend en charge, tel que Cloudflare 1.1.1.1, Google 8.8.8.8 ou Quad9. Les deux respectent la politique de groupe de l’entreprise. Firefox est plus agressif : il active DoH par d\u00e9faut dans la plupart des r\u00e9gions et utilise une v\u00e9rification canari contre use-application-dns.net<\/code> pour d\u00e9cider s’il faut s’en remettre au DNS local. Si ce domaine renvoie NXDOMAIN, Firefox recule. S’il renvoie une r\u00e9ponse normale, Firefox poursuit avec DoH et ignore compl\u00e8tement le serveur DNS local. <\/p>\n

Pour les plateformes SASE qui s’appuient sur le filtrage de la couche DNS<\/a>, il s’agit d’un probl\u00e8me structurel. Un utilisateur utilisant Firefox sur un ordinateur portable non g\u00e9r\u00e9 peut \u00e9mettre des requ\u00eates DNS qui ne touchent jamais le r\u00e9solveur de l’entreprise, ne sont jamais enregistr\u00e9es et ne sont jamais filtr\u00e9es. Les auteurs de logiciels malveillants l’ont remarqu\u00e9. Les canaux de commande et de contr\u00f4le bas\u00e9s sur le DoH sont d\u00e9sormais une hypoth\u00e8se de routine dans la r\u00e9ponse aux incidents. <\/p>\n

Le sch\u00e9ma d\u00e9fensif est stratifi\u00e9. Bloquez TCP\/853 et UDP\/853 au niveau du pare-feu pour supprimer DoT et DoQ. R\u00e9solvez le domaine canarien de Firefox en NXDOMAIN sur le r\u00e9solveur de l’entreprise. Tenez \u00e0 jour une liste des points de terminaison DoH publics connus. Pour le trafic d\u00e9crypt\u00e9 en ligne, filtrez le type MIME application\/dns-message<\/code> afin d’emp\u00eacher le tunnelling DoH arbitraire. Aucune de ces mesures n’est \u00e0 elle seule \u00e0 l’\u00e9preuve des balles. Ensemble, ils restaurent suffisamment de visibilit\u00e9 pour \u00eatre utiles. <\/p>\n

Le d\u00e9cryptage s\u00e9lectif est la meilleure pratique pour 2026<\/h2>\n

L’inspection compl\u00e8te de chaque session crypt\u00e9e n’est plus l’objectif \u00e0 atteindre. Elle est \u00e0 peine possible techniquement \u00e0 grande \u00e9chelle, et m\u00eame lorsqu’elle l’est, le co\u00fbt en termes de protection de la vie priv\u00e9e et de r\u00e9glementation est rarement proportionn\u00e9. Les d\u00e9ploiements modernes de SASE utilisent un d\u00e9cryptage s\u00e9lectif : une politique d\u00e9cide, pour chaque cat\u00e9gorie de trafic, s’il faut mettre fin \u00e0 l’inspection, contourner le d\u00e9cryptage ou le remplacer par un autre contr\u00f4le. La norme NIST SP 800-52 Rev 2 et les orientations de l’ENISA vont dans ce sens. <\/p>\n

\n\n\n\n\n\n\n\n\n\n
Cat\u00e9gorie de trafic<\/th>\nAction de d\u00e9cryptage<\/th>\nContr\u00f4le alternatif<\/th>\nRaisonnement<\/th>\n<\/tr>\n<\/thead>\n
Finances et soins de sant\u00e9<\/td>\nNe pas d\u00e9crypter<\/td>\nFiltrage DNS, r\u00e9putation IP, m\u00e9tadonn\u00e9es TLS<\/td>\nInformations d’identification sensibles et IPI ; proportionnalit\u00e9 du GDPR<\/td>\n<\/tr>\n
SaaS sanctionn\u00e9 (Microsoft 365, Zoom, Salesforce)<\/td>\nContourner le d\u00e9cryptage<\/td>\nCASB bas\u00e9 sur l’API, restrictions pour les locataires<\/td>\n\u00c9vite les \u00e9checs d’\u00e9pinglage et les frais g\u00e9n\u00e9raux<\/td>\n<\/tr>\n
Trafic web g\u00e9n\u00e9ral<\/td>\nD\u00e9cryptage et inspection<\/td>\nAntivirus en ligne, filtrage des URL, sandboxing<\/td>\nPrincipale source de diffusion de logiciels malveillants<\/td>\n<\/tr>\n
Stockage en nuage et partage de fichiers<\/td>\nD\u00e9cryptage et inspection<\/td>\nDLP en ligne, contr\u00f4les des types de fichiers<\/td>\nCanal courant d’exfiltration des donn\u00e9es<\/td>\n<\/tr>\n
Sources non g\u00e9r\u00e9es ou \u00e0 haut risque<\/td>\nNe pas d\u00e9crypter<\/td>\nIsolation du navigateur<\/td>\nContenir l’inconnu plut\u00f4t que de l’inspecter<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n

La liste des exclusions est ce qui distingue une politique 2026 cr\u00e9dible d’une politique 2018. Les services bancaires, les soins de sant\u00e9 et les courriels personnels sont exempt\u00e9s non seulement en raison de l’\u00e9pinglage, mais aussi en raison des orientations de l’EDPB sur la surveillance du lieu de travail et du principe de proportionnalit\u00e9 \u00e9nonc\u00e9 \u00e0 l’article 5 du GDPR. Les SaaS sanctionn\u00e9s font l’objet d’une cat\u00e9gorie distincte, car le point d’inspection appropri\u00e9 est l’API du fournisseur, et non le r\u00e9seau. Pour le trafic qui ne peut pas \u00eatre d\u00e9crypt\u00e9 et qui ne doit pas \u00eatre fiable, l’isolation du navigateur<\/a> d\u00e9place la surface de risque dans un conteneur cloud jetable au lieu d’essayer d’inspecter ce qui se trouve sur le c\u00e2ble. <\/p>\n

Tensions en mati\u00e8re de protection de la vie priv\u00e9e et de r\u00e9glementation dans les juridictions de l’UE<\/h2>\n

La capacit\u00e9 technique de d\u00e9cryptage n’est pas la m\u00eame chose que l’autorit\u00e9 l\u00e9gale pour d\u00e9ployer le d\u00e9cryptage. Dans toutes les grandes juridictions de l’UE, l’inspection TLS touche \u00e0 la cod\u00e9termination du comit\u00e9 d’entreprise, \u00e0 la proportionnalit\u00e9 du GDPR et \u00e0 l’interaction avec la journalisation NIS2. Un d\u00e9ploiement qui ignore ces contraintes risque de rendre les journaux d’inspection l\u00e9galement irrecevables en cas de conflit du travail, ce qui va \u00e0 l’encontre d’une grande partie de l’objectif op\u00e9rationnel. <\/p>\n

Le Betriebsrat allemand d\u00e9tient, en vertu de l’article 87, paragraphe 1, point 6, de la loi sur la constitution des entreprises, des droits de cod\u00e9termination contraignants sur toute mesure technique permettant de surveiller le comportement des employ\u00e9s. Le d\u00e9cryptage TLS entre dans cette cat\u00e9gorie. Un d\u00e9ploiement unilat\u00e9ral sans Betriebsvereinbarung sign\u00e9 est juridiquement nul. Les Pays-Bas fonctionnent de la m\u00eame mani\u00e8re avec l’Ondernemingsraad en vertu de l’article 27, paragraphe 1, point l), de la Wet op de Ondernemingsraden, o\u00f9 le comit\u00e9 d’entreprise dispose d’un droit de consentement plut\u00f4t que d’un simple droit de consultation. La France fait appel au Comit\u00e9 social et \u00e9conomique en vertu des articles L2311-1 et L2312-8 du Code du travail ; le d\u00e9ploiement sans l’avis formel du CSE peut faire l’objet de poursuites pour d\u00e9lit d’entrave, avec une responsabilit\u00e9 p\u00e9nale pour l’employeur. <\/p>\n

La Belgique r\u00e9glemente la surveillance des communications \u00e9lectroniques par le biais de la convention collective de travail 81. La CCT 81 autorise la surveillance \u00e0 quatre fins sp\u00e9cifiques : pr\u00e9venir les actes ill\u00e9gaux ou diffamatoires, prot\u00e9ger les secrets d’affaires, assurer la s\u00e9curit\u00e9 du r\u00e9seau et v\u00e9rifier le respect des r\u00e8gles de l’entreprise. La surveillance continue et identifi\u00e9e est interdite par d\u00e9faut. L’employeur doit d’abord d\u00e9tecter une irr\u00e9gularit\u00e9 \u00e0 un niveau global, en informer l’employ\u00e9, puis passer \u00e0 un suivi cibl\u00e9. Cette s\u00e9quence d\u00e9termine directement la mani\u00e8re dont la journalisation du d\u00e9cryptage doit \u00eatre configur\u00e9e : pseudonymisation par d\u00e9faut, identification uniquement apr\u00e8s un \u00e9v\u00e9nement signal\u00e9. <\/p>\n

Les lignes directrices 05\/2020 de l’EDPB sur le contr\u00f4le du lieu de travail soulignent qu’un accord d’entreprise sign\u00e9 n’exempte pas le d\u00e9ploiement du GDPR. Le traitement doit toujours reposer sur une base l\u00e9gale, respecter les principes de l’article 5 et faire l’objet d’une analyse d’impact relative \u00e0 la protection des donn\u00e9es en vertu de l’article 35. En pratique, c’est dans le cadre de l’analyse d’impact sur la protection des donn\u00e9es que la liste d’exclusion du d\u00e9cryptage s\u00e9lectif est document\u00e9e et d\u00e9fendue. <\/p>\n

Le NIS2 ajoute une couche qui est souvent mal interpr\u00e9t\u00e9e. L’article 21 exige que les entit\u00e9s essentielles et importantes mettent en \u0153uvre une d\u00e9tection et une journalisation efficaces des menaces. Il ne pr\u00e9cise pas le d\u00e9cryptage complet de TLS. Le cadre CyberFundamentals de CCB, que les organisations belges utilisent pour d\u00e9montrer la conformit\u00e9 \u00e0 NIS2, adopte une vision bas\u00e9e sur le risque et accepte des journaux pseudonymis\u00e9s ou agr\u00e9g\u00e9s comme preuve de la capacit\u00e9 de d\u00e9tection. La combinaison de l’exigence de d\u00e9tection de NIS2 et des conseils de minimisation de l’EDPB pousse les d\u00e9ploiements pratiques vers exactement le mod\u00e8le s\u00e9lectif d\u00e9crit ci-dessus. <\/p>\n

Comment les plateformes SASE abordent l’inspection en 2026<\/h2>\n

Les principaux fournisseurs de SASE ont adopt\u00e9 des mod\u00e8les reconnaissables, et les diff\u00e9rences sont importantes lorsque l’on compare les plates-formes.<\/p>\n

\n\n\n\n\n\n\n\n\n\n
Vendeur<\/th>\nTraitement QUIC<\/th>\nInspection TLS 1.3<\/th>\nApproche DNS crypt\u00e9e<\/th>\n<\/tr>\n<\/thead>\n
Acc\u00e8s Internet Zscaler<\/td>\nBloquer UDP\/443, forcer le repli TCP<\/td>\nNatif via proxy cloud<\/td>\nLe contr\u00f4le DNS bloque les points d’extr\u00e9mit\u00e9 DoH, renvoie ServFail pour les RR HTTPS<\/td>\n<\/tr>\n
R\u00e9seaux Cato<\/td>\nBlocage par d\u00e9faut via des r\u00e8gles de contr\u00f4le des applications<\/td>\nNatif dans le moteur \u00e0 passage unique<\/td>\nLes contr\u00f4les DNS r\u00e9cursifs bloquent la r\u00e9cup\u00e9ration des cl\u00e9s ECH<\/td>\n<\/tr>\n
Cloudflare One<\/td>\nInspection native QUIC et HTTP\/3 via un proxy UDP<\/td>\nNatif \u00e0 la p\u00e9riph\u00e9rie<\/td>\nGestion de l’ECH au niveau de la p\u00e9riph\u00e9rie ou bande de la couche DNS<\/td>\n<\/tr>\n
Palo Alto Prisma Access<\/td>\nBloquer UDP\/80 et UDP\/443, forcer le repli TCP<\/td>\nNatif via NGFW \u00e0 passage unique<\/td>\nCat\u00e9gories de filtrage d’URL bloquant les sites publics du DoH et du DoT<\/td>\n<\/tr>\n
FortiSASE<\/td>\nConfigurable : inspection en bloc ou native<\/td>\nNative dans le profil d’inspection SSL<\/td>\nLes contr\u00f4les FortiOS bloquent les extensions DoT, DoQ, DoH et ECH.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n

Une s\u00e9paration architecturale claire est visible. Les fournisseurs construits sur l’h\u00e9ritage du proxy TCP (Zscaler, Cato, Palo Alto) traitent QUIC comme quelque chose \u00e0 bloquer. Les fournisseurs ayant un h\u00e9ritage Edge ou NGFW \u00e9tendu \u00e0 UDP (Cloudflare, Fortinet) l’inspectent nativement. Ni l’un ni l’autre n’est mauvais, mais le choix a des cons\u00e9quences sur l’exp\u00e9rience de l’utilisateur sur les services \u00e0 forte intensit\u00e9 de QUIC et sur la complexit\u00e9 op\u00e9rationnelle de la politique. Demandez \u00e0 n’importe quel fournisseur de la documentation sur les origines sp\u00e9cifiques qu’il a test\u00e9es dans chaque mode. <\/p>\n

Jimber adopte une approche \u00ab\u00a0cloud-native\u00a0\u00bb avec un d\u00e9cryptage s\u00e9lectif configurable par cat\u00e9gorie de trafic. La plateforme g\u00e8re la terminaison TLS 1.3 en mode natif et prend en charge le blocage QUIC avec une politique de repli pour les organisations qui pr\u00e9f\u00e8rent un mod\u00e8le op\u00e9rationnel plus simple. La plateforme SASE de Jimber<\/a> int\u00e8gre l’isolation du navigateur<\/a> pour le trafic qui ne doit pas \u00eatre d\u00e9chiffr\u00e9 mais qui ne doit pas non plus \u00eatre fiable, et lie la couche DNS \u00e0 une politique par utilisateur et par appareil. Le mat\u00e9riel NIAC \u00e9tend les m\u00eames contr\u00f4les aux dispositifs sans agent tels que les imprimantes, les cam\u00e9ras IP et les \u00e9quipements industriels qui ne peuvent pas installer d’agents de point final. L’authentification \u00e0 travers ces surfaces utilise TLS mutuel<\/a>, de sorte que la politique s’applique de la m\u00eame mani\u00e8re aux ordinateurs portables g\u00e9r\u00e9s et \u00e0 un pont IT-OT dans une usine. \u00c9tant donn\u00e9 que l’infrastructure est construite et exploit\u00e9e dans la juridiction de l’UE, la conversation sur le DPIA part d’une position plus forte qu’avec les plates-formes bas\u00e9es aux \u00c9tats-Unis qui doivent rassembler des engagements de r\u00e9sidence des donn\u00e9es autour du CLOUD Act. Pour les organisations qui passent d’une inspection bas\u00e9e sur des appareils \u00e0 des contr\u00f4les fournis dans le nuage, notre article sur le Firewall-as-a-Service<\/a> couvre le contexte plus large de l’architecture. <\/p>\n

FAQ<\/h2>\n

Les plateformes SASE pourront-elles inspecter le trafic QUIC en 2026 ?<\/strong><\/p>\n

Certains peuvent le faire de mani\u00e8re native, d’autres non. Cloudflare One et FortiSASE prennent en charge l’inspection QUIC et HTTP\/3 en ligne par le biais de proxys sensibles \u00e0 l’UDP. Zscaler, Cato et Palo Alto Prisma Access bloquent UDP\/443 pour forcer les navigateurs \u00e0 revenir \u00e0 TLS 1.3 bas\u00e9 sur TCP. <\/p>\n

TLS 1.3 emp\u00eache-t-il l’inspection du trafic de l’entreprise ?<\/strong><\/p>\n

Non, mais cela modifie le fonctionnement de l’inspection. TLS 1.3 impose le Perfect Forward Secrecy, de sorte que le d\u00e9chiffrement passif hors bande n’est plus possible. L’inspection n\u00e9cessite d\u00e9sormais un proxy actif qui met fin \u00e0 la connexion sur un appareil g\u00e9r\u00e9 qui fait confiance \u00e0 l’autorit\u00e9 de certification racine de l’entreprise. <\/p>\n

Qu’est-ce que Encrypted ClientHello et cela affecte-t-il les d\u00e9ploiements SASE ?<\/strong><\/p>\n

ECH, sp\u00e9cifi\u00e9 dans le RFC 9849, crypte l’indication du nom du serveur \u00e0 l’aide d’une cl\u00e9 que le serveur publie dans le DNS. Il interrompt le filtrage bas\u00e9 sur le SNI pour les appareils non g\u00e9r\u00e9s. Les plates-formes SASE att\u00e9nuent g\u00e9n\u00e9ralement l’ECH en appliquant la politique du navigateur sur les appareils g\u00e9r\u00e9s ou en supprimant les enregistrements de ressources HTTPS au niveau du r\u00e9solveur DNS de l’entreprise. <\/p>\n

Quelles sont les applications qui utilisent l’\u00e9pinglage de certificats pour emp\u00eacher le d\u00e9cryptage ?<\/strong><\/p>\n

Parmi les exemples les plus courants, citons WhatsApp, Signal, Apple iCloud et les services de notification push, Microsoft Teams, Slack, Salesforce, Zoom, Google Drive, Spotify, Netflix et la plupart des applications bancaires mobiles. Les applications \u00e9pingl\u00e9es d\u00e9tectent le certificat de substitution pr\u00e9sent\u00e9 par un proxy SASE et refusent de se connecter. <\/p>\n

Le d\u00e9cryptage complet de TLS est-il n\u00e9cessaire pour la conformit\u00e9 \u00e0 NIS2 ?<\/strong><\/p>\n

L’article 21 de la NIS2 exige une d\u00e9tection efficace des menaces et une journalisation, et non un d\u00e9cryptage complet de chaque session. Le cadre des principes fondamentaux du cyberespace de la DGCCRF accepte le d\u00e9cryptage s\u00e9lectif combin\u00e9 \u00e0 une journalisation pseudonymis\u00e9e comme preuve de la capacit\u00e9 de d\u00e9tection, \u00e0 condition que l’approche soit justifi\u00e9e par le risque. <\/p>\n

Comment le DNS sur HTTPS contourne-t-il le filtrage d’entreprise ?<\/strong><\/p>\n

DoH int\u00e8gre les requ\u00eates DNS dans le protocole HTTPS standard sur TCP\/443, ce qui les rend impossibles \u00e0 distinguer du trafic web normal sans inspection TLS en ligne. Firefox, en particulier, se met automatiquement \u00e0 jour vers DoH et peut contourner enti\u00e8rement les r\u00e9solveurs d’entreprise. Les mesures d’att\u00e9nuation comprennent le blocage des points de terminaison DoH connus, le renvoi de NXDOMAIN pour les domaines canaris et le filtrage du type MIME application\/dns-message<\/code>. <\/p>\n

Qu’est-ce que le d\u00e9cryptage s\u00e9lectif TLS et quand doit-il \u00eatre utilis\u00e9 ?<\/strong><\/p>\n

Le d\u00e9chiffrement s\u00e9lectif applique une politique de d\u00e9chiffrement par cat\u00e9gorie de trafic, exemptant les cat\u00e9gories sensibles telles que les banques, les soins de sant\u00e9 et les SaaS sanctionn\u00e9s, tout en inspectant le trafic web g\u00e9n\u00e9ral et le stockage dans le nuage. Cette approche devrait \u00eatre l’approche par d\u00e9faut pour toute organisation op\u00e9rant dans le cadre du GDPR ou des comit\u00e9s d’entreprise de l’UE, car elle r\u00e9pond directement aux obligations de proportionnalit\u00e9 et de minimisation tout en pr\u00e9servant une inspection significative. <\/p>\n

L’inspection du chiffrement en 2026 est devenue moins une question de capacit\u00e9 technique qu’une question de savoir quel trafic a r\u00e9ellement besoin d’\u00eatre ouvert. Les changements de protocole ont ferm\u00e9 les voies faciles, et la l\u00e9gislation europ\u00e9enne sur la protection de la vie priv\u00e9e a ferm\u00e9 la plupart des voies de force brute. Une plateforme SASE qui g\u00e8re nativement la terminaison TLS 1.3, fait un choix d\u00e9lib\u00e9r\u00e9 de QUIC, prend en charge le d\u00e9cryptage s\u00e9lectif configurable par cat\u00e9gorie et int\u00e8gre l’isolation du navigateur pour le trafic qui ne peut ou ne doit pas \u00eatre d\u00e9crypt\u00e9 donne aux \u00e9quipes du march\u00e9 interm\u00e9diaire une position d\u00e9fendable sous l’examen de NIS2 et du comit\u00e9 d’entreprise. Si vous souhaitez voir comment Jimber configure cette solution pour un environnement de PME europ\u00e9en, r\u00e9servez une d\u00e9monstration<\/a> et nous passerons en revue le cadre de politique avec vous. <\/p>\n","protected":false},"excerpt":{"rendered":"

Comment les plateformes SASE modernes inspectent le trafic TLS 1.3 et QUIC, g\u00e8rent l’\u00e9pinglage des certificats et respectent les r\u00e8gles de confidentialit\u00e9 de l’UE en 2026. Pour les responsables informatiques. <\/p>\n","protected":false},"author":3,"featured_media":13298,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[9],"tags":[],"class_list":["post-13301","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-non-categorise"],"acf":[],"_links":{"self":[{"href":"https:\/\/jimber.io\/fr\/wp-json\/wp\/v2\/posts\/13301","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/jimber.io\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/jimber.io\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/jimber.io\/fr\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/jimber.io\/fr\/wp-json\/wp\/v2\/comments?post=13301"}],"version-history":[{"count":1,"href":"https:\/\/jimber.io\/fr\/wp-json\/wp\/v2\/posts\/13301\/revisions"}],"predecessor-version":[{"id":13316,"href":"https:\/\/jimber.io\/fr\/wp-json\/wp\/v2\/posts\/13301\/revisions\/13316"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/jimber.io\/fr\/wp-json\/wp\/v2\/media\/13298"}],"wp:attachment":[{"href":"https:\/\/jimber.io\/fr\/wp-json\/wp\/v2\/media?parent=13301"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/jimber.io\/fr\/wp-json\/wp\/v2\/categories?post=13301"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/jimber.io\/fr\/wp-json\/wp\/v2\/tags?post=13301"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}