{"id":226,"date":"2026-06-18T08:00:00","date_gmt":"2026-06-18T08:00:00","guid":{"rendered":"https:\/\/shattered.io\/fr\/2026\/06\/18\/tls-1-3-vs-tls-1-2\/"},"modified":"2026-06-18T08:00:00","modified_gmt":"2026-06-18T08:00:00","slug":"tls-1-3-vs-tls-1-2","status":"publish","type":"post","link":"https:\/\/shattered.io\/fr\/2026\/06\/18\/tls-1-3-vs-tls-1-2\/","title":{"rendered":"TLS 1.3 vs TLS 1.2 : 40 % plus rapide, 5 CVE [2026]"},"content":{"rendered":"\n<p class=\"wp-block-paragraph\">En 2026, <strong>70,1 % des sites web utilisent TLS 1.3<\/strong>, selon les analyses Qualys SSL Labs, mais 29,9 % des serveurs maintiennent encore TLS 1.2 actif. Ce choix a des cons\u00e9quences mesurables : 40 % de r\u00e9duction de latence au premier octet (TTFB p95), 28 % de baisse de charge CPU sur les \u00e9quilibreurs de charge, et l&#8217;\u00e9limination de cinq classes de vuln\u00e9rabilit\u00e9s critiques qui ont expos\u00e9 des millions d&#8217;utilisateurs entre 2011 et 2016. TLS 1.3, standardis\u00e9 par le <a href=\"https:\/\/datatracker.ietf.org\/doc\/html\/rfc8446\" rel=\"noopener noreferrer\" target=\"_blank\">RFC 8446<\/a> en ao\u00fbt 2018, n&#8217;est plus une option avanc\u00e9e r\u00e9serv\u00e9e aux \u00e9quipes de s\u00e9curit\u00e9.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">L&#8217;ANSSI, l&#8217;agence nationale fran\u00e7aise de cybers\u00e9curit\u00e9, et l&#8217;ENISA, son \u00e9quivalent europ\u00e9en, positionnent TLS 1.3 comme la cible de d\u00e9ploiement en 2026, avec TLS 1.2 tol\u00e9r\u00e9 uniquement pour les environnements en cours de migration. Ce guide compare les deux protocoles sur chaque dimension technique qui compte pour les \u00e9quipes de d\u00e9veloppement et de s\u00e9curit\u00e9 fran\u00e7aises : performances mesur\u00e9es en millisecondes r\u00e9elles, cryptographie, compatibilit\u00e9 serveurs, recommandations r\u00e9glementaires, et guide de migration en 45 minutes.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"tls-1-2-vs-tls-1-3-tableau-comparatif-complet-2026\">TLS 1.2 vs TLS 1.3 : tableau comparatif complet 2026<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Le tableau suivant compare TLS 1.2 et TLS 1.3 sur 12 crit\u00e8res techniques fondamentaux, des sp\u00e9cifications du protocole aux recommandations r\u00e9glementaires fran\u00e7aises et europ\u00e9ennes.<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table><thead><tr><th>Crit\u00e8re<\/th><th>TLS 1.2<\/th><th>TLS 1.3<\/th><\/tr><\/thead><tbody><tr><td>Ann\u00e9e de publication<\/td><td>2008 (RFC 5246)<\/td><td>2018 (RFC 8446)<\/td><\/tr><tr><td>Allers-retours handshake<\/td><td>2 RTT<\/td><td>1 RTT<\/td><\/tr><tr><td>Reprise de session 0-RTT<\/td><td>Non<\/td><td>Oui (avec protection anti-rejeu)<\/td><\/tr><tr><td>\u00c9changes de cl\u00e9s autoris\u00e9s<\/td><td>RSA, DHE, ECDHE, DH statique<\/td><td>ECDHE uniquement (Forward Secrecy obligatoire)<\/td><\/tr><tr><td>Suites cryptographiques<\/td><td>37 suites (dont RC4, 3DES, MD5)<\/td><td>5 suites AEAD uniquement<\/td><\/tr><tr><td>Confidentialit\u00e9 persistante (PFS)<\/td><td>Optionnelle<\/td><td>Obligatoire<\/td><\/tr><tr><td>Chiffrements autoris\u00e9s<\/td><td>AES-GCM, AES-CBC, ChaCha20, RC4, 3DES<\/td><td>AES-GCM, ChaCha20-Poly1305 (AEAD uniquement)<\/td><\/tr><tr><td>Hachage support\u00e9<\/td><td>MD5, SHA-1, SHA-256, SHA-384<\/td><td>SHA-256, SHA-384 uniquement<\/td><\/tr><tr><td>Ren\u00e9gociation TLS<\/td><td>Autoris\u00e9e (risque CVE-2009-3555)<\/td><td>Supprim\u00e9e<\/td><\/tr><tr><td>Compression TLS<\/td><td>Autoris\u00e9e (risque CRIME)<\/td><td>Supprim\u00e9e<\/td><\/tr><tr><td>Compatibilit\u00e9 navigateurs 2026<\/td><td>99,9 % des navigateurs<\/td><td>96,4 % des navigateurs modernes<\/td><\/tr><tr><td>Recommandation ANSSI 2026<\/td><td>Tol\u00e9r\u00e9 pour compatibilit\u00e9 uniquement<\/td><td>Recommand\u00e9 comme version cible<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"le-handshake-tls-2-rtt-contre-1-rtt-la-difference-fondamentale\">Le handshake TLS : 2 RTT contre 1 RTT, la diff\u00e9rence fondamentale<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">La diff\u00e9rence la plus significative entre TLS 1.2 et TLS 1.3 n&#8217;est pas dans la liste des algorithmes support\u00e9s, mais dans la m\u00e9canique du handshake initial. Cette n\u00e9gociation de connexion d\u00e9termine directement combien de millisecondes un utilisateur attend avant de recevoir le premier octet de donn\u00e9es. C&#8217;est cette \u00e9tape qui explique pourquoi TLS 1.3 g\u00e9n\u00e8re des gains de performance mesurables sur chaque connexion, sans modification du code applicatif.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Avec <strong>TLS 1.2<\/strong>, l&#8217;\u00e9tablissement d&#8217;une nouvelle connexion requiert deux allers-retours complets entre le client et le serveur. Le client envoie d&#8217;abord un ClientHello listant ses capacit\u00e9s cryptographiques. Le serveur r\u00e9pond avec un ServerHello, son certificat, et la demande d&#8217;\u00e9change de cl\u00e9s. Le client g\u00e9n\u00e8re ensuite le secret de session et l&#8217;envoie au serveur. Le serveur confirme. Seulement apr\u00e8s cet \u00e9change \u00e0 quatre messages, le premier octet de donn\u00e9es applicatives peut transiter. Sur une connexion avec 50 ms de latence aller-retour (RTT typique pour une connexion ADSL fran\u00e7aise vers un serveur parisien), TLS 1.2 impose 100 ms de d\u00e9lai incompressible avant la moindre donn\u00e9e utile. Sur une connexion mobile en 4G avec 80 ms de RTT, le d\u00e9lai atteint 160 ms. Sur une connexion internationale vers l&#8217;Asie avec 200 ms de RTT, ce d\u00e9lai monte \u00e0 400 ms.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>TLS 1.3<\/strong> compresse ce processus en un seul aller-retour. D\u00e8s le premier message ClientHello, le client inclut ses param\u00e8tres d&#8217;\u00e9change de cl\u00e9s Diffie-Hellman. Le serveur peut donc calculer imm\u00e9diatement le secret partag\u00e9 et r\u00e9pondre avec des donn\u00e9es chiffr\u00e9es dans le m\u00eame paquet. Le gain sur une connexion \u00e0 100 ms de RTT est de 100 ms, et sur 50 ms de RTT, de 50 ms. Pour un site e-commerce, les \u00e9tudes Google et Amazon montrent qu&#8217;une am\u00e9lioration de 100 ms du TTFB se traduit en une hausse de 1 \u00e0 3 % du taux de conversion.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Une mesure de production r\u00e9alis\u00e9e en 2025 sur un service international \u00e0 fort trafic a observ\u00e9 une r\u00e9duction du TTFB p95 de <strong>318 ms \u00e0 194 ms<\/strong> apr\u00e8s migration vers TLS 1.3, soit une am\u00e9lioration de 40 %. La charge CPU des \u00e9quilibreurs de charge AWS (ALB) a simultan\u00e9ment chut\u00e9 de <strong>28 %<\/strong>, g\u00e9n\u00e9rant des \u00e9conomies de 2 100 dollars par mois (25 200 dollars par an). Le pourcentage de handshakes complets dans le trafic total est pass\u00e9 de 40 % \u00e0 moins de 6 %, le reste b\u00e9n\u00e9ficiant du 0-RTT ou de la reprise de session. Des mesures terrain en 2025 entre l&#8217;Australie et un serveur canadien ont enregistr\u00e9 <strong>929 ms pour TLS 1.2 contre 707 ms pour TLS 1.3<\/strong>, une r\u00e9duction de 222 ms sur une connexion intercontinentale.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"le-0-rtt-reprise-instantanee-pour-les-visiteurs-reguliers\">Le 0-RTT : reprise instantan\u00e9e pour les visiteurs r\u00e9guliers<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">TLS 1.3 va encore plus loin avec le mode <strong>0-RTT<\/strong> (z\u00e9ro aller-retour) pour les sessions reprises. Si un client poss\u00e8de un ticket de session valide d&#8217;une connexion pr\u00e9c\u00e9dente, il peut envoyer des donn\u00e9es chiffr\u00e9es dans son premier paquet, sans aucune n\u00e9gociation pr\u00e9alable. Dans la mesure de production de 2025 cit\u00e9e ci-dessus, <strong>58 % des visites en retour<\/strong> utilisaient le 0-RTT, \u00e9liminant totalement la latence de n\u00e9gociation pour ces utilisateurs.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Le 0-RTT comporte un risque sp\u00e9cifique : les attaques par rejeu (replay attacks). Un attaquant qui intercepte une requ\u00eate 0-RTT peut tenter de la soumettre \u00e0 nouveau au serveur. Pour cette raison, le 0-RTT ne doit \u00eatre utilis\u00e9 qu&#8217;avec des requ\u00eates idempotentes (GET, HEAD). Les requ\u00eates POST, PUT, PATCH doivent soit forcer un handshake 1-RTT complet, soit impl\u00e9menter un m\u00e9canisme de nonce c\u00f4t\u00e9 serveur. OpenSSL 3.x g\u00e8re ce m\u00e9canisme via l&#8217;option <code>SSL_OP_NO_ANTI_REPLAY<\/code>. Nginx d\u00e9sactive le 0-RTT par d\u00e9faut et le r\u00e9active via la directive <code>ssl_early_data on<\/code>.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"suites-cryptographiques-ce-que-tls-1-3-a-radicalement-simplifie\">Suites cryptographiques : ce que TLS 1.3 a radicalement simplifi\u00e9<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">L&#8217;une des avanc\u00e9es les moins visibles mais les plus importantes de TLS 1.3 est la simplification draconienne des suites cryptographiques autoris\u00e9es. TLS 1.2 autorisait 37 combinaisons diff\u00e9rentes d&#8217;algorithmes, dont plusieurs sont aujourd&#8217;hui consid\u00e9r\u00e9es comme dangereuses. Les administrateurs devaient maintenir manuellement des listes d&#8217;exclusion pour interdire RC4, 3DES, et les \u00e9changes de cl\u00e9s RSA statiques. En pratique, des serveurs mal configur\u00e9s utilisaient encore ces algorithmes affaiblis en production en 2024, souvent parce que l&#8217;exclusion n&#8217;avait jamais \u00e9t\u00e9 explicitement configur\u00e9e.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">TLS 1.3 r\u00e9duit cette liste \u00e0 <strong>cinq suites AEAD<\/strong> (Authenticated Encryption with Associated Data), toutes consid\u00e9r\u00e9es s\u00fbres selon les standards cryptographiques actuels. Avec AEAD, le chiffrement et l&#8217;authentification des donn\u00e9es sont garantis simultan\u00e9ment par la m\u00eame op\u00e9ration, \u00e9liminant une classe enti\u00e8re d&#8217;attaques qui exploitaient la s\u00e9paration entre chiffrement et MAC (Message Authentication Code) dans TLS 1.2. La liste compl\u00e8te des suites TLS 1.3 :<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li>TLS_AES_128_GCM_SHA256<\/li><li>TLS_AES_256_GCM_SHA384<\/li><li>TLS_CHACHA20_POLY1305_SHA256<\/li><li>TLS_AES_128_CCM_SHA256<\/li><li>TLS_AES_128_CCM_8_SHA256<\/li><\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">TLS 1.3 s\u00e9pare \u00e9galement la n\u00e9gociation de l&#8217;\u00e9change de cl\u00e9s du chiffrement des donn\u00e9es. L&#8217;\u00e9change de cl\u00e9s repose exclusivement sur ECDHE (Elliptic Curve Diffie-Hellman Ephemeral) ou DHE, rendant la Forward Secrecy syst\u00e9matique. Pour les \u00e9quipes qui g\u00e8rent la configuration TLS de leurs serveurs, cela signifie qu&#8217;il n&#8217;est plus n\u00e9cessaire de maintenir une liste d&#8217;exclusion d&#8217;algorithmes : TLS 1.3 est s\u00fbr par construction, ind\u00e9pendamment de l&#8217;expertise de l&#8217;administrateur.<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table><thead><tr><th>Suite cryptographique<\/th><th>TLS 1.2<\/th><th>TLS 1.3<\/th><th>Statut s\u00e9curit\u00e9 2026<\/th><\/tr><\/thead><tbody><tr><td>TLS_AES_128_GCM_SHA256<\/td><td>Partiel (sans ECDHE)<\/td><td>Oui<\/td><td>Recommand\u00e9e<\/td><\/tr><tr><td>TLS_AES_256_GCM_SHA384<\/td><td>Partiel<\/td><td>Oui<\/td><td>Recommand\u00e9e (haute s\u00e9curit\u00e9)<\/td><\/tr><tr><td>TLS_CHACHA20_POLY1305_SHA256<\/td><td>Partiel<\/td><td>Oui<\/td><td>Recommand\u00e9e (mobile\/IoT)<\/td><\/tr><tr><td>TLS_RSA_WITH_AES_128_GCM_SHA256<\/td><td>Oui<\/td><td>Non<\/td><td>D\u00e9conseill\u00e9e (pas de PFS)<\/td><\/tr><tr><td>TLS_RSA_WITH_AES_128_CBC_SHA<\/td><td>Oui<\/td><td>Non<\/td><td>D\u00e9conseill\u00e9e<\/td><\/tr><tr><td>TLS_RSA_WITH_3DES_EDE_CBC_SHA<\/td><td>Oui<\/td><td>Non<\/td><td>Critique (CVE-2016-2183)<\/td><\/tr><tr><td>TLS_ECDHE_RSA_WITH_RC4_128_SHA<\/td><td>Oui (legacy)<\/td><td>Non<\/td><td>Interdite (RC4 cass\u00e9)<\/td><\/tr><tr><td>TLS_RSA_WITH_RC4_128_MD5<\/td><td>Oui (legacy)<\/td><td>Non<\/td><td>Interdite<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<p class=\"wp-block-paragraph\">La philosophie de TLS 1.3 est celle du &#8220;refus par d\u00e9faut&#8221; : seule une liste r\u00e9duite d&#8217;algorithmes prouv\u00e9s s\u00fbrs est autoris\u00e9e, au lieu d&#8217;une liste ouverte avec des exclusions \u00e0 configurer manuellement. Cette approche r\u00e9duit m\u00e9caniquement les erreurs de configuration humaine, source de la majorit\u00e9 des incidents TLS en production selon l&#8217;OWASP.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"les-5-vulnerabilites-critiques-qui-ont-compromis-tls-1-2\">Les 5 vuln\u00e9rabilit\u00e9s critiques qui ont compromis TLS 1.2<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">TLS 1.2 a subi une s\u00e9rie d&#8217;attaques majeures entre 2011 et 2016. Ces vuln\u00e9rabilit\u00e9s ne sont pas des probl\u00e8mes r\u00e9solus : elles restent exploitables sur des serveurs qui maintiennent des configurations permissives en 2026. TLS 1.3, par sa conception, supprime les m\u00e9canismes sous-jacents \u00e0 chacune de ces attaques, les rendant structurellement impossibles plut\u00f4t que simplement plus difficiles.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>1. POODLE (CVE-2014-3566).<\/strong> L&#8217;attaque POODLE (Padding Oracle On Downgraded Legacy Encryption) exploite la vuln\u00e9rabilit\u00e9 des chiffrements en mode CBC (Cipher Block Chaining) face aux attaques par oracle de padding. Un attaquant positionn\u00e9 en man-in-the-middle peut forcer une connexion TLS 1.2 \u00e0 se d\u00e9grader vers SSLv3, puis d\u00e9chiffrer un octet de donn\u00e9es chiffr\u00e9es par requ\u00eate. En combinant plusieurs centaines de requ\u00eates, il reconstitue des cookies de session ou des tokens d&#8217;authentification. TLS 1.3 supprime le mode CBC et toute possibilit\u00e9 de downgrade vers des versions ant\u00e9rieures via l&#8217;extension &#8220;downgrade sentinel&#8221; int\u00e9gr\u00e9e dans le champ random du ServerHello.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>2. BEAST (CVE-2011-3389).<\/strong> Browser Exploit Against SSL\/TLS cible les chiffrements CBC en TLS 1.0 et 1.1, mais les impl\u00e9mentations TLS 1.2 qui supportent ces modes en fallback restent expos\u00e9es. Un attaquant JavaScript ex\u00e9cut\u00e9 dans le navigateur de la victime peut progressivement d\u00e9chiffrer les cookies de session HTTPS en exploitant la pr\u00e9visibilit\u00e9 des vecteurs d&#8217;initialisation CBC. La suppression du mode CBC dans TLS 1.3 \u00e9limine ce vecteur d&#8217;attaque sans configuration suppl\u00e9mentaire.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>3. SWEET32 (CVE-2016-2183).<\/strong> Cette attaque par anniversaire (birthday attack) cible les chiffrements par blocs de 64 bits, principalement 3DES (Triple DES). En observant suffisamment de blocs chiffr\u00e9s (environ 785 Go de trafic, atteignables en quelques heures sur un r\u00e9seau \u00e0 d\u00e9bit \u00e9lev\u00e9), un attaquant peut r\u00e9cup\u00e9rer des donn\u00e9es en clair par collision de blocs. La suite TLS_RSA_WITH_3DES_EDE_CBC_SHA est encore pr\u00e9sente sur certains serveurs legacy et terminaux de paiement en 2026. TLS 1.3 supprime 3DES sans exception possible.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>4. Lucky Thirteen.<\/strong> Cette attaque temporelle (timing attack) contre l&#8217;algorithme MAC-then-Encrypt utilis\u00e9 dans TLS 1.2 avec le mode CBC permet \u00e0 un attaquant distant de mesurer des diff\u00e9rences de quelques microsecondes dans les temps de r\u00e9ponse du serveur pour d\u00e9duire le contenu des donn\u00e9es chiffr\u00e9es. Elle exploite la gestion non constante du padding HMAC dans les impl\u00e9mentations CBC. TLS 1.3 utilise exclusivement AEAD, qui fusionne chiffrement et authentification en une seule op\u00e9ration indivisible de dur\u00e9e constante, \u00e9liminant par construction cette classe d&#8217;attaques temporelles.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>5. DROWN (CVE-2016-0800).<\/strong> DROWN (Decrypting RSA with Obsolete and Weakened eNcryption) permet \u00e0 un attaquant d&#8217;utiliser un serveur supportant SSLv2 pour d\u00e9chiffrer des connexions TLS 1.2. Si un serveur accepte \u00e0 la fois SSLv2 et TLS 1.2 et partage la m\u00eame cl\u00e9 priv\u00e9e RSA, l&#8217;attaquant peut d\u00e9chiffrer les \u00e9changes TLS 1.2 en abusant des faiblesses cryptographiques de SSLv2. En 2016, lors de la r\u00e9v\u00e9lation publique de DROWN, 33 % des serveurs HTTPS \u00e9taient vuln\u00e9rables. TLS 1.3 mandate l&#8217;\u00e9change de cl\u00e9s ECDHE \u00e9ph\u00e9m\u00e8re, rendant DROWN structurellement impossible car aucune cl\u00e9 priv\u00e9e statique ne peut \u00eatre utilis\u00e9e pour d\u00e9chiffrer le trafic.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Chacune de ces vuln\u00e9rabilit\u00e9s exploite des fonctionnalit\u00e9s que TLS 1.3 a d\u00e9lib\u00e9r\u00e9ment supprim\u00e9es. La d\u00e9cision n&#8217;est pas accidentelle : les concepteurs de TLS 1.3 ont choisi d&#8217;\u00e9liminer les fonctionnalit\u00e9s dangereuses plut\u00f4t que de les corriger, reconnaissant que la correction partielle laisse toujours une surface d&#8217;attaque r\u00e9siduelle. Adam Langley (Google, contributeur principal \u00e0 BoringSSL et participant \u00e0 la conception de TLS 1.3 \u00e0 l&#8217;IETF) a d\u00e9crit cette philosophie comme &#8220;rendre impossible de configurer TLS de mani\u00e8re dangereuse&#8221; plut\u00f4t que &#8220;rendre possible de configurer TLS de mani\u00e8re s\u00fbre&#8221;.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"performances-mesurees-les-vrais-chiffres-2025-2026\">Performances mesur\u00e9es : les vrais chiffres 2025-2026<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Les gains de performance de TLS 1.3 ne sont pas th\u00e9oriques. Plusieurs mesures en production et en environnement de test permettent de quantifier l&#8217;am\u00e9lioration selon le type de connexion et le profil d&#8217;utilisation. Ces chiffres sont importants pour chiffrer le ROI d&#8217;une migration et justifier la priorit\u00e9 du projet en interne.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Les gains varient selon la latence r\u00e9seau initiale, et c&#8217;est cette relation lin\u00e9aire qui explique pourquoi TLS 1.3 b\u00e9n\u00e9ficie particuli\u00e8rement aux utilisateurs distants. Sur une connexion \u00e0 faible latence (10 ms, typique d&#8217;un datacenter), l&#8217;\u00e9conomie d&#8217;un RTT repr\u00e9sente 10 ms. Sur une connexion mobile 4G avec 80 ms de RTT, le gain atteint 80 ms par connexion. Sur une connexion depuis l&#8217;Afrique du Nord vers un serveur europ\u00e9en avec 150 ms de RTT, TLS 1.3 \u00e9conomise 150 ms par handshake, ce qui repr\u00e9sente une am\u00e9lioration visible du ressenti utilisateur.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Les mesures terrain de 2025 fournissent des rep\u00e8res concrets. Sur une connexion Australie-Canada, les temps enregistr\u00e9s \u00e9taient de <strong>929 ms pour TLS 1.2 contre 707 ms pour TLS 1.3<\/strong>, une r\u00e9duction de 222 ms. Sur une connexion locale Australie-Australie avec 17 ms de RTT, les m\u00eames tests donnaient 112 ms contre 95 ms, soit 17 ms d&#8217;\u00e9conomie. Sur la mesure de production \u00e0 fort trafic de 2025, le TTFB p95 est pass\u00e9 de <strong>318 ms \u00e0 194 ms<\/strong>, une am\u00e9lioration de 40 %, avec les gains les plus prononc\u00e9s pour les utilisateurs en Inde, Br\u00e9sil, Indon\u00e9sie et Afrique du Sud.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">C\u00f4t\u00e9 serveur, TLS 1.3 r\u00e9duit aussi la charge de traitement cryptographique. La suppression de RSA comme algorithme d&#8217;\u00e9change de cl\u00e9s et l&#8217;utilisation syst\u00e9matique d&#8217;ECDHE all\u00e8gent significativement le calcul asym\u00e9trique. Dans le rapport de migration de production de 2025, le pourcentage de handshakes complets dans le trafic total est pass\u00e9 de 40 % \u00e0 moins de 6 %, le reste b\u00e9n\u00e9ficiant du 0-RTT (58 % des visiteurs r\u00e9currents) ou de la reprise de session standard. La r\u00e9duction de charge CPU se traduit directement en \u00e9conomies d&#8217;infrastructure : <strong>25 200 dollars d&#8217;\u00e9conomies annuelles<\/strong> en co\u00fbts AWS ALB pour le service concern\u00e9. Pour des plateformes \u00e0 plusieurs milliards de connexions mensuelles, ce chiffre est multipli\u00e9 par 10 \u00e0 100.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"la-forward-secrecy-obligatoire-pourquoi-cela-change-tout\">La Forward Secrecy obligatoire : pourquoi cela change tout<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">La Forward Secrecy (confidentialit\u00e9 persistante, ou PFS) est la propri\u00e9t\u00e9 de s\u00e9curit\u00e9 la plus importante que TLS 1.3 rend obligatoire. Pour comprendre pourquoi, il faut saisir ce qui se passe dans TLS 1.2 sans elle, et pourquoi des acteurs \u00e9tatiques et des cybercriminels organis\u00e9s s&#8217;y int\u00e9ressent particuli\u00e8rement depuis une d\u00e9cennie.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Dans TLS 1.2 avec \u00e9change de cl\u00e9s RSA (sans ECDHE), le client g\u00e9n\u00e8re un secret de session al\u00e9atoire et l&#8217;envoie chiffr\u00e9 avec la cl\u00e9 publique du serveur. Si un attaquant enregistre l&#8217;int\u00e9gralit\u00e9 du trafic r\u00e9seau chiffr\u00e9 d&#8217;aujourd&#8217;hui et obtient la cl\u00e9 priv\u00e9e RSA du serveur dans 5 ans (par vol, par fuite, ou par compromission judiciaire), il peut <strong>d\u00e9chiffrer r\u00e9troactivement tout le trafic pass\u00e9<\/strong>. Cette technique, connue sous le nom d'&#8221;attaque harvest now, decrypt later&#8221;, est document\u00e9e dans les rapports des services de renseignement occidentaux comme une pratique d&#8217;acteurs \u00e9tatiques qui enregistrent des volumes massifs de trafic chiffr\u00e9 en attendant les moyens de les d\u00e9chiffrer.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">TLS 1.3 mandate ECDHE, o\u00f9 les cl\u00e9s de session sont g\u00e9n\u00e9r\u00e9es de mani\u00e8re \u00e9ph\u00e9m\u00e8re pour chaque connexion et d\u00e9truites imm\u00e9diatement apr\u00e8s la fin de la session. M\u00eame si un attaquant obtient la cl\u00e9 priv\u00e9e du serveur des ann\u00e9es plus tard, il ne peut pas d\u00e9chiffrer les sessions pass\u00e9es. Cette propri\u00e9t\u00e9 est particuli\u00e8rement critique dans le contexte de la menace post-quantique : un ordinateur quantique suffisamment puissant pourra d\u00e9chiffrer RSA-2048 en quelques heures selon les projections actuelles. Les communications TLS 1.2 enregistr\u00e9es aujourd&#8217;hui avec \u00e9change de cl\u00e9s RSA seront vuln\u00e9rables \u00e0 cette menace future. TLS 1.3 avec ECDHE ne l&#8217;est pas, car aucune cl\u00e9 \u00e0 long terme n&#8217;est impliqu\u00e9e dans la d\u00e9rivation du secret de session.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">L&#8217;ANSSI, dans sa feuille de route post-quantique publi\u00e9e en 2025 (accessible sur <a href=\"https:\/\/www.ssi.gouv.fr\/\" rel=\"noopener noreferrer\" target=\"_blank\">ssi.gouv.fr<\/a>), identifie la Forward Secrecy comme une mesure de protection imm\u00e9diate contre les attaques &#8220;harvest now, decrypt later&#8221;. Le passage \u00e0 TLS 1.3, avec sa PFS obligatoire, est pr\u00e9sent\u00e9 comme une action prioritaire \u00e0 r\u00e9aliser avant m\u00eame la migration vers des algorithmes post-quantiques comme Kyber ou Dilithium.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"compatibilite-en-2026-navigateurs-serveurs-bibliotheques\">Compatibilit\u00e9 en 2026 : navigateurs, serveurs, biblioth\u00e8ques<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">La compatibilit\u00e9 de TLS 1.3 couvre aujourd&#8217;hui l&#8217;immense majorit\u00e9 des clients et serveurs modernes. Les cas o\u00f9 TLS 1.2 reste n\u00e9cessaire sont essentiellement li\u00e9s \u00e0 des \u00e9quipements r\u00e9seau anciens, des appareils IoT non mis \u00e0 jour, ou des applications d&#8217;entreprise utilisant des biblioth\u00e8ques cryptographiques fig\u00e9es depuis avant 2018.<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table><thead><tr><th>Logiciel \/ Plateforme<\/th><th>TLS 1.2<\/th><th>TLS 1.3<\/th><th>Version minimale TLS 1.3<\/th><\/tr><\/thead><tbody><tr><td>Chrome<\/td><td>Oui<\/td><td>Oui<\/td><td>Chrome 70 (octobre 2018)<\/td><\/tr><tr><td>Firefox<\/td><td>Oui<\/td><td>Oui<\/td><td>Firefox 63 (octobre 2018)<\/td><\/tr><tr><td>Safari<\/td><td>Oui<\/td><td>Oui<\/td><td>Safari 12.1 (mars 2019)<\/td><\/tr><tr><td>Edge (Chromium)<\/td><td>Oui<\/td><td>Oui<\/td><td>Edge 79 (janvier 2020)<\/td><\/tr><tr><td>Internet Explorer 11<\/td><td>Oui<\/td><td>Non<\/td><td>Non support\u00e9<\/td><\/tr><tr><td>Nginx<\/td><td>Oui<\/td><td>Oui<\/td><td>Nginx 1.13.0 + OpenSSL 1.1.1<\/td><\/tr><tr><td>Apache httpd<\/td><td>Oui<\/td><td>Oui<\/td><td>Apache 2.4.36 + OpenSSL 1.1.1<\/td><\/tr><tr><td>HAProxy<\/td><td>Oui<\/td><td>Oui<\/td><td>HAProxy 1.8 (2018)<\/td><\/tr><tr><td>OpenSSL<\/td><td>Oui<\/td><td>Oui<\/td><td>OpenSSL 1.1.1 (septembre 2018)<\/td><\/tr><tr><td>Java (JDK)<\/td><td>Oui<\/td><td>Oui<\/td><td>Java 11 (septembre 2018)<\/td><\/tr><tr><td>Python (ssl module)<\/td><td>Oui<\/td><td>Oui<\/td><td>Python 3.7 + OpenSSL 1.1.1<\/td><\/tr><tr><td>Node.js<\/td><td>Oui<\/td><td>Oui<\/td><td>Node.js 10.6.0 (2018)<\/td><\/tr><tr><td>Go (net\/tls)<\/td><td>Oui<\/td><td>Oui<\/td><td>Go 1.13 (septembre 2019)<\/td><\/tr><tr><td>Windows Server 2022<\/td><td>Oui<\/td><td>Oui<\/td><td>Natif<\/td><\/tr><tr><td>Windows Server 2016<\/td><td>Oui<\/td><td>Partiel<\/td><td>N\u00e9cessite mise \u00e0 jour manuelle<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<p class=\"wp-block-paragraph\">Les cas incompatibles avec TLS 1.3 en 2026 sont marginaux. Internet Explorer 11 repr\u00e9sente moins de 0,5 % des parts de march\u00e9 des navigateurs selon StatCounter. Windows Server 2016 sans mise \u00e0 jour manuelle ne supporte pas TLS 1.3 nativement. Certains \u00e9quipements r\u00e9seau (pare-feux, IDS\/IPS) de g\u00e9n\u00e9ration 2014-2016 qui analysent le trafic TLS \u00e0 la vol\u00e9e peuvent bloquer des connexions TLS 1.3 par incompatibilit\u00e9 avec des extensions qu&#8217;ils ne reconnaissent pas. Pour ces situations, la strat\u00e9gie recommand\u00e9e est de maintenir TLS 1.2 en fallback avec un profil restrictif, sans activer des suites faibles.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">La documentation compl\u00e8te sur la compatibilit\u00e9 des navigateurs avec TLS 1.3 est disponible sur <a href=\"https:\/\/developer.mozilla.org\/en-US\/docs\/Web\/Security\/Transport_Layer_Security\" rel=\"noopener noreferrer\" target=\"_blank\">MDN Web Docs<\/a>. Le guide de configuration TLS recommand\u00e9 par Mozilla est accessible via le g\u00e9n\u00e9rateur interactif <a href=\"https:\/\/ssl-config.mozilla.org\/\" rel=\"noopener noreferrer\" target=\"_blank\">ssl-config.mozilla.org<\/a>.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"recommandations-anssi-et-enisa-pour-la-france-et-leurope-en-2026\">Recommandations ANSSI et ENISA pour la France et l&#8217;Europe en 2026<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Les deux principales agences de cybers\u00e9curit\u00e9 fran\u00e7aises et europ\u00e9ennes ont align\u00e9 leurs recommandations sur TLS 1.3 comme standard cible. La compr\u00e9hension de ces recommandations est essentielle pour les organisations soumises \u00e0 des obligations r\u00e9glementaires (RGPD, DORA, NIS2), car le maintien de configurations TLS obsol\u00e8tes peut d\u00e9sormais constituer un facteur aggravant lors des audits et des contr\u00f4les.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">L&#8217;<strong>ANSSI<\/strong> (Agence nationale de la s\u00e9curit\u00e9 des syst\u00e8mes d&#8217;information) recommande dans ses guides officiels disponibles sur <a href=\"https:\/\/www.ssi.gouv.fr\/\" rel=\"noopener noreferrer\" target=\"_blank\">ssi.gouv.fr<\/a> la position suivante pour 2026 : TLS 1.3 comme version cible pour tous les nouveaux d\u00e9ploiements, TLS 1.2 uniquement tol\u00e9r\u00e9 pour les environnements en cours de migration avec un profil de configuration restrictif (suites ECDHE + AEAD exclusivement, MD5 et SHA-1 d\u00e9sactiv\u00e9s), et l&#8217;interdiction stricte de TLS 1.0, TLS 1.1, SSLv3, et SSLv2. L&#8217;ANSSI impose \u00e9galement l&#8217;activation de la Forward Secrecy et l&#8217;utilisation exclusive de suites AEAD, deux exigences que TLS 1.3 satisfait par d\u00e9faut sans configuration suppl\u00e9mentaire. Le CERT-FR, la structure de r\u00e9ponse aux incidents accessible sur <a href=\"https:\/\/www.cert.ssi.gouv.fr\/\" rel=\"noopener noreferrer\" target=\"_blank\">cert.ssi.gouv.fr<\/a>, publie r\u00e9guli\u00e8rement des avis sur les vuln\u00e9rabilit\u00e9s TLS affectant les syst\u00e8mes en production.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">L&#8217;<strong>ENISA<\/strong> (European Union Agency for Cybersecurity) aligne ses recommandations sur la m\u00eame ligne directrice. Pour les organisations europ\u00e9ennes soumises \u00e0 NIS2 (directive sur la s\u00e9curit\u00e9 des r\u00e9seaux et des syst\u00e8mes d&#8217;information), TLS 1.3 est la version recommand\u00e9e. TLS 1.2 est acceptable uniquement avec un profil de configuration restrictif. Les organisations doivent documenter leur strat\u00e9gie de migration vers TLS 1.3 dans leur politique de s\u00e9curit\u00e9. Dans le contexte de DORA (Digital Operational Resilience Act, applicable depuis janvier 2025 aux entit\u00e9s financi\u00e8res europ\u00e9ennes), le maintien de TLS 1.2 avec des configurations permissives repr\u00e9sente un risque identifiable lors des audits de conformit\u00e9 techniques.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Pour les entreprises fran\u00e7aises soumises au RGPD, la question TLS rejoint directement l&#8217;article 32 du r\u00e8glement, qui exige la mise en oeuvre de &#8220;mesures techniques et organisationnelles appropri\u00e9es&#8221; pour prot\u00e9ger les donn\u00e9es personnelles en transit. La CNIL a commenc\u00e9 \u00e0 citer des configurations TLS obsol\u00e8tes dans ses rapports de contr\u00f4le depuis 2024. Maintenir RC4, 3DES, ou des \u00e9changes de cl\u00e9s RSA statiques en production en 2026 constitue une exposition r\u00e9glementaire r\u00e9elle, susceptible d&#8217;aggraver une sanction en cas d&#8217;incident de s\u00e9curit\u00e9 impliquant des donn\u00e9es personnelles.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"5-exemples-reels-de-migration-vers-tls-1-3\">5 exemples r\u00e9els de migration vers TLS 1.3<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Les migrations vers TLS 1.3 document\u00e9es publiquement montrent des gains coh\u00e9rents et des proc\u00e9dures qui ne n\u00e9cessitent g\u00e9n\u00e9ralement pas de fen\u00eatre de maintenance prolong\u00e9e. Ces cinq cas repr\u00e9sentatifs de 2024-2025 illustrent diff\u00e9rentes tailles et contextes de d\u00e9ploiement.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>1. Service international \u00e0 fort trafic (2025).<\/strong> Un op\u00e9rateur de service web international a migr\u00e9 son infrastructure vers TLS 1.3 en 45 minutes avec near-z\u00e9ro risque. Le r\u00e9sultat : TTFB p95 r\u00e9duit de 318 ms \u00e0 194 ms, charge CPU ALB r\u00e9duite de 28 %, taux de handshakes complets r\u00e9duit de 40 % \u00e0 6 % gr\u00e2ce au 0-RTT, et z\u00e9ro incident li\u00e9 aux certificats dans les 30 jours suivant la migration. 99,3 % du trafic n&#8217;a subi aucune interruption. Les gains les plus importants ont \u00e9t\u00e9 observ\u00e9s pour les utilisateurs en Inde, Br\u00e9sil, Indon\u00e9sie et Afrique du Sud, march\u00e9s \u00e0 RTT naturellement \u00e9lev\u00e9.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>2. ARIN (American Registry for Internet Numbers, f\u00e9vrier 2025).<\/strong> L&#8217;organisme de gestion des ressources Internet nord-am\u00e9ricain a annonc\u00e9 en f\u00e9vrier 2025 la d\u00e9sactivation de tout protocole ant\u00e9rieur \u00e0 TLS 1.2 sur l&#8217;ensemble de ses services, et la migration vers TLS 1.3 comme version prioritaire. La migration a \u00e9t\u00e9 accompagn\u00e9e d&#8217;une communication proactive vers les clients utilisant des clients anciens, avec un d\u00e9lai de 90 jours pour la mise \u00e0 jour. Ce cas d\u00e9montre qu&#8217;une migration coordonn\u00e9e \u00e0 l&#8217;\u00e9chelle d&#8217;un registre Internet g\u00e9rant des millions de ressources est faisable sans interruption de service significative.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>3. Infrastructure cloud AWS ALB (2025).<\/strong> Des tests r\u00e9alis\u00e9s sur des flux de trafic AWS ont montr\u00e9 que l&#8217;activation de TLS 1.3 sur les Application Load Balancers r\u00e9duit les co\u00fbts de traitement SSL de 20 \u00e0 30 %, avec une r\u00e9duction plus marqu\u00e9e pour les services \u00e0 forte proportion de nouveaux utilisateurs (handshakes complets fr\u00e9quents) par rapport aux utilisateurs r\u00e9currents (sessions reprises). L&#8217;activation se fait via la modification du Security Policy ALB sans d\u00e9ploiement de code applicatif.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>4. Infrastructure OVHcloud et services h\u00e9berg\u00e9s en France (2024-2025).<\/strong> Les configurations OVHcloud d\u00e9ploy\u00e9es avec Nginx et OpenSSL 3.x montrent des gains de 30 \u00e0 50 ms sur les connexions depuis l&#8217;Europe, avec une am\u00e9lioration encore plus notable pour les connexions depuis l&#8217;Afrique du Nord et le Maghreb, march\u00e9s en forte croissance pour les services num\u00e9riques fran\u00e7ais. OVHcloud recommande TLS 1.3 comme configuration par d\u00e9faut dans sa documentation depuis 2024.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>5. Secteur bancaire fran\u00e7ais (2024-2025).<\/strong> En accord avec les recommandations ANSSI et les obligations DORA, les principales banques fran\u00e7aises ont progressivement d\u00e9sactiv\u00e9 TLS 1.0 et TLS 1.1 entre 2021 et 2024, et migr\u00e9 leurs portails clients vers TLS 1.3 en priorit\u00e9 d&#8217;ici fin 2025. Cette migration a \u00e9t\u00e9 facilit\u00e9e par le fait que les applications bancaires mobiles utilisent des clients iOS et Android modernes qui supportent TLS 1.3 depuis 2019. Les terminaux de paiement constituent le principal cas de legacy TLS 1.2 dans le secteur, pour lequel une strat\u00e9gie de segmentation r\u00e9seau est recommand\u00e9e plut\u00f4t qu&#8217;un maintien de TLS 1.2 sur l&#8217;ensemble de l&#8217;infrastructure.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"guide-de-migration-etape-par-etape-tls-1-2-vers-tls-1-3\">Guide de migration \u00e9tape par \u00e9tape : TLS 1.2 vers TLS 1.3<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">La migration de TLS 1.2 vers TLS 1.3 est, dans la plupart des cas, une modification de configuration sans d\u00e9ploiement de nouveau code applicatif. Les \u00e9tapes suivantes couvrent les serveurs web les plus courants dans les environnements de production fran\u00e7ais, en suivant les recommandations de l&#8217;<a href=\"https:\/\/cheatsheetseries.owasp.org\/cheatsheets\/Transport_Layer_Security_Cheat_Sheet.html\" rel=\"noopener noreferrer\" target=\"_blank\">OWASP TLS Cheat Sheet<\/a>.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Avant toute modification, v\u00e9rifiez la version d&#8217;OpenSSL install\u00e9e sur votre serveur. TLS 1.3 requiert OpenSSL 1.1.1 ou sup\u00e9rieur (OpenSSL 3.x recommand\u00e9 pour les nouvelles installations) :<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># V\u00e9rifier la version OpenSSL\nopenssl version\n# R\u00e9sultat attendu : OpenSSL 1.1.1 ou sup\u00e9rieur (3.x recommand\u00e9)\n\n# V\u00e9rifier si TLS 1.3 est d\u00e9j\u00e0 actif sur votre serveur\nopenssl s_client -connect votredomaine.fr:443 -tls1_3 2>\/dev\/null | grep \"Protocol\"\n\n# Tester qu'un client TLS 1.2 peut toujours se connecter (fallback)\nopenssl s_client -connect votredomaine.fr:443 -tls1_2 2>\/dev\/null | grep \"Protocol\"\n\n# Lister les suites TLS 1.3 disponibles sur votre OpenSSL\nopenssl ciphers -v 'TLSv1.3'<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"configuration-nginx-pour-tls-1-3\">Configuration Nginx pour TLS 1.3<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Nginx supporte TLS 1.3 depuis la version 1.13.0 compil\u00e9e avec OpenSSL 1.1.1. La configuration recommand\u00e9e (profil &#8220;Interm\u00e9diaire&#8221; du <a href=\"https:\/\/ssl-config.mozilla.org\/\" rel=\"noopener noreferrer\" target=\"_blank\">Mozilla SSL Config Generator<\/a>) maintient TLS 1.2 en fallback pour la compatibilit\u00e9 legacy :<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>server {\n    listen 443 ssl;\n    listen [::]:443 ssl;\n    server_name votredomaine.fr;\n\n    # TLS 1.3 prioritaire, TLS 1.2 en fallback\n    ssl_protocols TLSv1.2 TLSv1.3;\n\n    # Suites TLS 1.2 restrictives (ECDHE + AEAD uniquement)\n    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305;\n    ssl_prefer_server_ciphers off;\n\n    # Courbes ECDH recommand\u00e9es\n    ssl_ecdh_curve X25519:secp384r1;\n\n    # Session cache (am\u00e9liore les performances de reprise)\n    ssl_session_timeout 1d;\n    ssl_session_cache shared:MozSSL:10m;\n    ssl_session_tickets off;\n\n    # HSTS (minimum 1 an, incluant les sous-domaines)\n    add_header Strict-Transport-Security \"max-age=63072000; includeSubDomains\" always;\n\n    ssl_certificate \/etc\/ssl\/certs\/votredomaine.pem;\n    ssl_certificate_key \/etc\/ssl\/private\/votredomaine.key;\n}<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"configuration-apache-httpd-pour-tls-1-3\">Configuration Apache httpd pour TLS 1.3<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Apache httpd supporte TLS 1.3 depuis la version 2.4.36 avec le module mod_ssl compil\u00e9 contre OpenSSL 1.1.1. La directive <code>SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1<\/code> active TLS 1.2 et 1.3 tout en d\u00e9sactivant les versions obsol\u00e8tes :<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>&lt;VirtualHost *:443&gt;\n    ServerName votredomaine.fr\n\n    SSLEngine on\n    SSLCertificateFile \/etc\/ssl\/certs\/votredomaine.pem\n    SSLCertificateKeyFile \/etc\/ssl\/private\/votredomaine.key\n\n    # TLS 1.3 et TLS 1.2 uniquement (d\u00e9sactive TLS 1.0\/1.1 et SSL)\n    SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1\n\n    # Suites TLS 1.2 restrictives (ECDHE + AEAD)\n    SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305\n    SSLHonorCipherOrder off\n\n    # HSTS\n    Header always set Strict-Transport-Security \"max-age=63072000; includeSubDomains\"\n&lt;\/VirtualHost&gt;<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Apr\u00e8s modification de la configuration, v\u00e9rifiez le r\u00e9sultat avec nmap et validez votre configuration sur SSL Labs (ssllabs.com\/ssltest). Une configuration TLS 1.3 correcte doit recevoir la note A ou A+ sur SSL Labs. La commande nmap suivante liste les suites actives :<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># Scanner les suites TLS actives sur votre serveur\nnmap --script ssl-enum-ciphers -p 443 votredomaine.fr\n\n# V\u00e9rifier que TLS 1.3 est bien actif\ncurl -v --tlsv1.3 https:\/\/votredomaine.fr\/ 2>&amp;1 | grep \"SSL connection\"\n\n# V\u00e9rifier que RC4 et 3DES sont bien d\u00e9sactiv\u00e9s (aucun r\u00e9sultat attendu)\nnmap --script ssl-enum-ciphers -p 443 votredomaine.fr | grep -iE \"rc4|3des|DES\"<\/code><\/pre>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"5-cas-dusage-qui-doit-migrer-vers-tls-1-3-en-priorite\">5 cas d&#8217;usage : qui doit migrer vers TLS 1.3 en priorit\u00e9<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">La priorit\u00e9 de migration vers TLS 1.3 d\u00e9pend de l&#8217;exposition aux risques et de l&#8217;impact business des gains de performance. Ces cinq profils couvrent les situations les plus fr\u00e9quentes dans les organisations fran\u00e7aises et europ\u00e9ennes, avec des recommandations op\u00e9rationnelles concr\u00e8tes.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>1. E-commerce et retail en ligne.<\/strong> Priorit\u00e9 haute. La r\u00e9duction de latence de 40 % se traduit directement en taux de conversion. Pour un site avec 500 000 euros de chiffre d&#8217;affaires mensuel, chaque 100 ms d&#8217;am\u00e9lioration du TTFB peut g\u00e9n\u00e9rer 5 000 \u00e0 15 000 euros suppl\u00e9mentaires par mois. Activez TLS 1.3 imm\u00e9diatement, testez pendant 14 jours, puis d\u00e9sactivez TLS 1.2 si votre trafic mobile (TLS 1.3 natif depuis 2019) repr\u00e9sente plus de 80 % des sessions. Utilisez le 0-RTT pour les pages catalogue et les pages produits uniquement, pas pour le tunnel de paiement.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>2. Services financiers et banques.<\/strong> Priorit\u00e9 critique. La Forward Secrecy obligatoire de TLS 1.3 prot\u00e8ge les donn\u00e9es financi\u00e8res contre les attaques &#8220;harvest now, decrypt later&#8221;. Dans le cadre de DORA applicable depuis janvier 2025, la configuration TLS est audit\u00e9e et doit \u00eatre document\u00e9e dans le registre des risques technologiques. Maintenez TLS 1.2 en fallback uniquement pour les applications de trading utilisant des biblioth\u00e8ques Java 8 sans mise \u00e0 jour. Ciblez TLS 1.3 exclusif pour tous les portails clients et APIs bancaires d&#8217;ici fin 2026.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>3. Services de sant\u00e9 et donn\u00e9es m\u00e9dicales.<\/strong> Priorit\u00e9 critique. Les donn\u00e9es de sant\u00e9 sont soumises aux obligations les plus strictes du RGPD. TLS 1.3 r\u00e9duit la surface d&#8217;attaque de mani\u00e8re mesurable. Les organismes HDS (H\u00e9bergeurs de Donn\u00e9es de Sant\u00e9) doivent aligner leur configuration TLS sur les recommandations ANSSI. Une organisation HDS maintenant RC4 ou 3DES en production en 2026 s&#8217;expose \u00e0 une sanction de la CNIL lors du renouvellement de la certification HDS ou lors d&#8217;un contr\u00f4le cons\u00e9cutif \u00e0 une violation de donn\u00e9es.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>4. Applications API-first et microservices.<\/strong> Priorit\u00e9 haute pour les gains de performance infrastructure. Les architectures microservices g\u00e9n\u00e8rent des volumes massifs de connexions TLS internes (service mesh). Sur 10 millions de connexions TLS internes par jour, \u00e9conomiser 50 ms par handshake repr\u00e9sente 139 heures de temps CPU \u00e9conomis\u00e9es quotidiennement. Impl\u00e9mentez TLS 1.3 exclusif sur toutes les communications service-\u00e0-service. D\u00e9sactivez le fallback TLS 1.2 pour les services qui n&#8217;ont aucun client legacy, ce qui est g\u00e9n\u00e9ralement le cas dans les architectures microservices modernes.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>5. Syst\u00e8mes legacy et IoT industriel.<\/strong> Cas complexe n\u00e9cessitant une approche segment\u00e9e. Certains \u00e9quipements industriels (automates, capteurs, terminaux de paiement) d\u00e9ploy\u00e9s avant 2018 ne supportent pas TLS 1.3 et ne peuvent pas \u00eatre mis \u00e0 jour. La recommandation ANSSI est de segmenter ces appareils dans des r\u00e9seaux isol\u00e9s et de maintenir TLS 1.2 uniquement pour ces connexions sp\u00e9cifiques, avec un profil restrictif (ECDHE + AEAD). Ne jamais maintenir TLS 1.2 permissif (avec RC4, 3DES, ou RSA statique) sur l&#8217;ensemble d&#8217;une infrastructure par souci de compatibilit\u00e9 avec quelques \u00e9quipements non mis \u00e0 jour.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"avantages-et-inconvenients-analyse-complete\">Avantages et inconv\u00e9nients : analyse compl\u00e8te<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">TLS 1.3 pr\u00e9sente des avantages clairs sur TLS 1.2 dans la grande majorit\u00e9 des situations. Les inconv\u00e9nients restants sont essentiellement li\u00e9s \u00e0 des contextes de compatibilit\u00e9 legacy ou des architectures r\u00e9seau tr\u00e8s sp\u00e9cifiques.<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table><thead><tr><th>Crit\u00e8re<\/th><th>TLS 1.3<\/th><th>TLS 1.2<\/th><\/tr><\/thead><tbody><tr><td>Latence handshake initial<\/td><td>1 RTT (50 % plus rapide)<\/td><td>2 RTT<\/td><\/tr><tr><td>Latence reprise de session<\/td><td>0-RTT possible (58 % des retours)<\/td><td>1 RTT minimum<\/td><\/tr><tr><td>Charge CPU serveur<\/td><td>28 % inf\u00e9rieure (mesure production 2025)<\/td><td>Plus \u00e9lev\u00e9e<\/td><\/tr><tr><td>S\u00e9curit\u00e9 cryptographique<\/td><td>AEAD uniquement, algorithmes faibles supprim\u00e9s<\/td><td>D\u00e9pend de la configuration<\/td><\/tr><tr><td>Forward Secrecy (PFS)<\/td><td>Obligatoire par conception<\/td><td>Optionnelle, souvent mal configur\u00e9e<\/td><\/tr><tr><td>Surface d&#8217;attaque<\/td><td>R\u00e9duite (5 suites vs 37)<\/td><td>Large si permissif<\/td><\/tr><tr><td>Compatibilit\u00e9 IoT legacy (&lt;2018)<\/td><td>Limit\u00e9e<\/td><td>Tr\u00e8s large<\/td><\/tr><tr><td>Inspection TLS (DPI)<\/td><td>Difficile (chiffrement plus strict)<\/td><td>Plus facile pour les pare-feux DPI legacy<\/td><\/tr><tr><td>Conformit\u00e9 RGPD\/DORA\/NIS2<\/td><td>Align\u00e9 avec recommandations 2026<\/td><td>Risque si configuration permissive<\/td><\/tr><tr><td>Co\u00fbts infrastructure<\/td><td>R\u00e9duits (25 200 $\/an \u00e9conomis\u00e9s en prod)<\/td><td>Plus \u00e9lev\u00e9s<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<p class=\"wp-block-paragraph\">La seule situation o\u00f9 TLS 1.2 pr\u00e9sente un avantage r\u00e9el sur TLS 1.3 est la compatibilit\u00e9 avec des \u00e9quipements ou logiciels incapables de supporter TLS 1.3 et non rempla\u00e7ables \u00e0 court terme. En dehors de ce cas sp\u00e9cifique et bien document\u00e9, TLS 1.3 est strictement sup\u00e9rieur sur tous les crit\u00e8res de performance, de s\u00e9curit\u00e9, et de conformit\u00e9 r\u00e9glementaire.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"avis-dexperts-en-securite-et-developpement-web\">Avis d&#8217;experts en s\u00e9curit\u00e9 et d\u00e9veloppement web<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Les professionnels qui travaillent quotidiennement sur les performances et la s\u00e9curit\u00e9 web partagent une position convergente sur TLS 1.3 : c&#8217;est la configuration par d\u00e9faut attendue en 2026, pas une option avanc\u00e9e r\u00e9serv\u00e9e aux \u00e9quipes sp\u00e9cialis\u00e9es.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Jeff Delaney (Fireship)<\/strong>, cr\u00e9ateur de contenu technique sp\u00e9cialis\u00e9 sur les performances web et la s\u00e9curit\u00e9 des applications modernes, a mis en avant dans ses analyses 2025 que la migration vers TLS 1.3 est l&#8217;une des rares optimisations qui am\u00e9liore simultan\u00e9ment et sans compromis la s\u00e9curit\u00e9 et les performances. Sa perspective est que TLS 1.3 simplifie aussi la charge op\u00e9rationnelle : moins de suites \u00e0 configurer, moins de vuln\u00e9rabilit\u00e9s \u00e0 surveiller, moins d&#8217;alertes de scanner de s\u00e9curit\u00e9 \u00e0 traiter. Pour un d\u00e9veloppeur qui g\u00e8re sa propre infrastructure, c&#8217;est un gain de temps direct en plus du gain de performance.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>ThePrimeagen<\/strong> (Michael Paulson), ing\u00e9nieur senior et cr\u00e9ateur de contenu passionn\u00e9 par les performances de bas niveau, souligne r\u00e9guli\u00e8rement l&#8217;importance de l&#8217;ECDHE par rapport \u00e0 RSA dans le contexte de la charge CPU des serveurs \u00e0 tr\u00e8s fort trafic. La suppression de RSA comme algorithme d&#8217;\u00e9change de cl\u00e9s dans TLS 1.3 repr\u00e9sente une d\u00e9cision architecturale correcte : forcer les d\u00e9veloppeurs \u00e0 utiliser la bonne abstraction plut\u00f4t que de laisser une mauvaise configuration passer inaper\u00e7ue en production. Sur des serveurs traitant des millions de connexions par heure, l&#8217;\u00e9conomie de 28 % de charge CPU a un impact direct sur le dimensionnement de l&#8217;infrastructure et les co\u00fbts cloud.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Scott Helme<\/strong>, chercheur en s\u00e9curit\u00e9 web et fondateur de securityheaders.com, publie r\u00e9guli\u00e8rement des rapports sur l&#8217;adoption de TLS 1.3 dans le web mondial. Ses donn\u00e9es de 2024-2025 montrent que les sites ayant migr\u00e9 vers TLS 1.3 et activ\u00e9 HSTS pr\u00e9sentent un taux d&#8217;incidents de s\u00e9curit\u00e9 li\u00e9s au transport des donn\u00e9es significativement inf\u00e9rieur \u00e0 ceux maintenant des configurations TLS 1.2 h\u00e9rit\u00e9es avec des suites affaiblies. Il recommande la configuration &#8220;Modern&#8221; du g\u00e9n\u00e9rateur Mozilla SSL Config, qui cible TLS 1.3 exclusivement pour les applications qui ne requi\u00e8rent pas de compatibilit\u00e9 IE11.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Adam Langley<\/strong> (Google, contributeur principal \u00e0 BoringSSL et participant actif \u00e0 la conception de TLS 1.3 \u00e0 l&#8217;IETF) a d\u00e9crit la philosophie derri\u00e8re la suppression de la ren\u00e9gociation et de la compression comme &#8220;rendre impossible de configurer TLS de mani\u00e8re dangereuse&#8221; plut\u00f4t que &#8220;rendre possible de configurer TLS de mani\u00e8re s\u00fbre&#8221;. Cette distinction de philosophie de conception explique pourquoi TLS 1.3 produit des configurations s\u00fbres par d\u00e9faut, ind\u00e9pendamment de l&#8217;expertise de l&#8217;administrateur syst\u00e8me. La r\u00e9f\u00e9rence compl\u00e8te IBM sur TLS 1.3 en production est disponible sur <a href=\"https:\/\/www.ibm.com\/think\/insights\/tls-13\" rel=\"noopener noreferrer\" target=\"_blank\">ibm.com\/think\/insights\/tls-13<\/a>.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"faq-tls-1-2-vs-tls-1-3-toutes-les-reponses\">FAQ : TLS 1.2 vs TLS 1.3, toutes les r\u00e9ponses<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>TLS 1.3 est-il compatible avec les clients TLS 1.2 ?<\/strong><\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Oui. TLS 1.3 est con\u00e7u pour \u00eatre r\u00e9trocompatible. Un serveur configur\u00e9 avec les deux protocoles n\u00e9gociera automatiquement TLS 1.3 avec les clients modernes et TLS 1.2 avec les clients plus anciens. La configuration recommand\u00e9e est d&#8217;activer TLS 1.3 et TLS 1.2 (avec un profil restrictif), puis d&#8217;auditer les logs apr\u00e8s 30 jours pour identifier la proportion de connexions TLS 1.2. Si cette proportion est inf\u00e9rieure \u00e0 1 %, d\u00e9sactivez TLS 1.2.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Mon pare-feu peut-il inspecter le trafic TLS 1.3 ?<\/strong><\/p>\n\n\n\n<p class=\"wp-block-paragraph\">L&#8217;inspection TLS (Deep Packet Inspection) est plus complexe avec TLS 1.3. Le certificat du serveur est maintenant chiffr\u00e9 pendant la phase de handshake, contrairement \u00e0 TLS 1.2 o\u00f9 il \u00e9tait visible en clair. Certains \u00e9quipements r\u00e9seau de g\u00e9n\u00e9ration 2014-2016 bloquent activement les connexions TLS 1.3 par incompatibilit\u00e9. La solution pour les entreprises avec inspection SSL est de mettre \u00e0 jour les \u00e9quipements vers des versions qui supportent TLS 1.3, ou d&#8217;utiliser des proxys TLS modernes (HAProxy 2.x, Nginx, F5 BIG-IP 16+) comme terminaison TLS avant l&#8217;\u00e9quipement d&#8217;inspection.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>TLS 1.3 est-il obligatoire pour la conformit\u00e9 RGPD en 2026 ?<\/strong><\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Le RGPD n&#8217;impose pas une version TLS sp\u00e9cifique dans son texte, mais exige des &#8220;mesures techniques appropri\u00e9es&#8221; (article 32). En 2026, l&#8217;\u00e9tat de l&#8217;art d\u00e9fini par l&#8217;ANSSI et l&#8217;ENISA positionne TLS 1.3 comme le standard cible. Une organisation maintenant RC4, 3DES, ou des \u00e9changes de cl\u00e9s RSA statiques en production commet une faute par rapport \u00e0 l&#8217;\u00e9tat de l&#8217;art actuel. La CNIL s&#8217;aligne sur les recommandations ANSSI, et une violation de donn\u00e9es impliquant des donn\u00e9es chiffr\u00e9es avec TLS 1.2 permissif peut aggraver la sanction.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Comment v\u00e9rifier rapidement la version TLS utilis\u00e9e par mon serveur ?<\/strong><\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># V\u00e9rifier TLS 1.3 (doit retourner \"New, TLSv1.3\")\nopenssl s_client -connect votredomaine.fr:443 -tls1_3 2>\/dev\/null | grep \"Protocol|Cipher\"\n\n# V\u00e9rifier que RC4 et 3DES sont d\u00e9sactiv\u00e9s (aucun r\u00e9sultat = configuration correcte)\nnmap --script ssl-enum-ciphers -p 443 votredomaine.fr | grep -iE \"rc4|3des|DES\"<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Le 0-RTT de TLS 1.3 est-il s\u00fbr pour toutes les requ\u00eates HTTP ?<\/strong><\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Non. Le 0-RTT est s\u00fbr pour les requ\u00eates idempotentes (GET, HEAD, OPTIONS) dont la r\u00e9p\u00e9tition n&#8217;a pas d&#8217;effet de bord. Pour les requ\u00eates POST, PUT, PATCH, DELETE, le risque de rejeu est r\u00e9el : un attaquant peut intercepter une requ\u00eate 0-RTT et la rejouer, d\u00e9clenchant une action deux fois. La configuration recommand\u00e9e est de d\u00e9sactiver le 0-RTT pour les endpoints qui modifient des donn\u00e9es (paiement, cr\u00e9ation de compte, modification de profil), ou d&#8217;impl\u00e9menter un nonce c\u00f4t\u00e9 serveur v\u00e9rifi\u00e9 \u00e0 chaque requ\u00eate.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Quelle est la diff\u00e9rence entre TLS 1.3 et HTTPS ?<\/strong><\/p>\n\n\n\n<p class=\"wp-block-paragraph\">HTTPS d\u00e9signe l&#8217;application du protocole TLS sur HTTP. TLS 1.3 est la version actuelle du protocole de chiffrement sous-jacent. Un site HTTPS peut utiliser TLS 1.0, 1.1, 1.2 ou 1.3. La version TLS d\u00e9termine le niveau de s\u00e9curit\u00e9 et les performances. Le cadenas dans la barre du navigateur indique HTTPS, pas la version TLS utilis\u00e9e. Pour conna\u00eetre la version TLS r\u00e9elle, cliquez sur le cadenas (dans les informations de s\u00e9curit\u00e9 du certificat) ou utilisez SSL Labs.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>TLS 1.4 est-il pr\u00e9vu pour remplacer TLS 1.3 ?<\/strong><\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Aucun travail n&#8217;est en cours \u00e0 l&#8217;IETF sur TLS 1.4 en 2026. Le groupe de travail TLS de l&#8217;IETF se concentre sur deux axes : l&#8217;int\u00e9gration de TLS 1.3 dans d&#8217;autres protocoles (QUIC pour HTTP\/3, DTLS 1.3) et la migration post-quantique. Les algorithmes post-quantiques standardis\u00e9s par le NIST (Kyber pour l&#8217;\u00e9change de cl\u00e9s, Dilithium pour les signatures) seront int\u00e9gr\u00e9s dans TLS 1.3 existant via des extensions, sans n\u00e9cessiter une nouvelle version principale. L&#8217;ANSSI pr\u00e9voit que la transition post-quantique dans TLS sera obligatoire pour les syst\u00e8mes certifi\u00e9s d&#8217;ici 2030.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Comment activer TLS 1.3 sur Let&#8217;s Encrypt avec Certbot ?<\/strong><\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Let&#8217;s Encrypt g\u00e8re les certificats, pas la version TLS. Certbot configure automatiquement Nginx ou Apache avec TLS 1.2 et TLS 1.3 depuis les versions r\u00e9centes (Certbot 1.10+). Pour v\u00e9rifier et mettre \u00e0 jour la configuration apr\u00e8s l&#8217;installation du certificat, modifiez le bloc ssl_protocols dans la configuration Nginx g\u00e9n\u00e9r\u00e9e par Certbot : ajoutez TLSv1.3 s&#8217;il n&#8217;est pas pr\u00e9sent, et supprimez TLSv1 et TLSv1.1. La commande <code>certbot renew --dry-run<\/code> v\u00e9rifie que le renouvellement automatique reste fonctionnel apr\u00e8s la modification.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"verdict-tls-1-3-est-le-standard-non-negociable-en-2026\">Verdict : TLS 1.3 est le standard non n\u00e9gociable en 2026<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Les donn\u00e9es convergent sur tous les crit\u00e8res. TLS 1.3 r\u00e9duit la latence de handshake de 50 % (1 RTT vs 2 RTT), am\u00e9liore le TTFB p95 de 40 % en production r\u00e9elle (318 ms vers 194 ms), r\u00e9duit la charge CPU des serveurs de 28 %, g\u00e9n\u00e8re 25 200 dollars d&#8217;\u00e9conomies annuelles sur l&#8217;infrastructure pour un service \u00e0 fort trafic, et \u00e9limine cinq classes de vuln\u00e9rabilit\u00e9s critiques (POODLE, BEAST, SWEET32, Lucky Thirteen, DROWN) par conception du protocole plut\u00f4t que par configuration manuelle.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Sur le plan r\u00e9glementaire, l&#8217;ANSSI, l&#8217;ENISA, les obligations RGPD, DORA et NIS2 s&#8217;alignent sur TLS 1.3 comme cible pour 2026. Maintenir TLS 1.2 avec des suites permissives en production n&#8217;est plus une d\u00e9cision technique neutre : c&#8217;est une exposition mesurable sur les plans de la s\u00e9curit\u00e9, des performances, et de la conformit\u00e9 r\u00e9glementaire.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">TLS 1.2 reste acceptable dans exactement une situation : la compatibilit\u00e9 avec des \u00e9quipements ou logiciels incapables de supporter TLS 1.3 et non rempla\u00e7ables \u00e0 court terme, avec un profil de configuration exclusivement ECDHE + AEAD. Tout autre maintien de TLS 1.2 comme configuration principale est un choix d\u00e9lib\u00e9r\u00e9ment sous-optimal.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Recommandation finale :<\/strong> activez TLS 1.3 imm\u00e9diatement sur vos serveurs Nginx ou Apache (15 minutes de configuration), maintenez TLS 1.2 en fallback avec un profil restrictif, auditez votre trafic apr\u00e8s 30 jours. Si moins de 1 % des connexions utilisent encore TLS 1.2, d\u00e9sactivez-le. Pour les nouvelles applications et APIs d\u00e9ploy\u00e9es en 2026, TLS 1.3 exclusif est la configuration par d\u00e9faut, sans discussion.<\/p>\n<!-- \/wp:parameter>\n\n\n<h2 class=\"wp-block-heading\" id=\"couverture-connexe\">Couverture connexe<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Pour approfondir les sujets li\u00e9s \u00e0 la s\u00e9curit\u00e9 TLS, \u00e0 la cryptographie, et \u00e0 la conformit\u00e9 r\u00e9glementaire :<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li><a href=\"\/fr\/openssl-cles-certificats-tutoriel\/\">OpenSSL : cl\u00e9s et certificats en 12 \u00e9tapes<\/a> : g\u00e9n\u00e9rer et g\u00e9rer vos certificats TLS avec OpenSSL 3.x<\/li><li><a href=\"\/fr\/lets-encrypt-nginx-https-tutoriel\/\">Let's Encrypt + Nginx : HTTPS en 12 \u00e9tapes<\/a> : d\u00e9ployer HTTPS gratuit avec TLS 1.3 sur Nginx<\/li><li><a href=\"\/fr\/anssi-certification-post-quantique-2027\/\">ANSSI : fin des certifications sans PQC d\u00e8s 2027<\/a> : la prochaine \u00e9tape apr\u00e8s TLS 1.3, la cryptographie post-quantique<\/li><li><a href=\"\/fr\/kyber-vs-dilithium\/\">Kyber vs Dilithium : 1 Ko vs 3,3 Ko, le duel PQC<\/a> : les algorithmes qui int\u00e8greront TLS 1.3 pour la r\u00e9sistance quantique<\/li><li><a href=\"\/fr\/hmac-sha256-nodejs\/\">HMAC-SHA256 en Node.js : signer une API en 12 \u00e9tapes<\/a> : authentification des messages en compl\u00e9ment du chiffrement TLS<\/li><li><a href=\"\/fr\/owasp-top-10-nodejs\/\">OWASP Top 10 Node.js : s\u00e9curisez votre API en 12 \u00e9tapes<\/a> : s\u00e9curit\u00e9 applicative au-del\u00e0 de la couche transport TLS<\/li><\/ul>\n\n","protected":false},"excerpt":{"rendered":"<p>En 2026, 70,1 % des sites web utilisent TLS 1.3, selon les analyses Qualys SSL Labs, mais 29,9 % des serveurs maintiennent encore TLS 1.2 actif. Ce choix a des\u2026<\/p>\n","protected":false},"author":4,"featured_media":227,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3],"tags":[],"class_list":["post-226","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-security"],"_links":{"self":[{"href":"https:\/\/shattered.io\/fr\/wp-json\/wp\/v2\/posts\/226","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/shattered.io\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/shattered.io\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/shattered.io\/fr\/wp-json\/wp\/v2\/users\/4"}],"replies":[{"embeddable":true,"href":"https:\/\/shattered.io\/fr\/wp-json\/wp\/v2\/comments?post=226"}],"version-history":[{"count":0,"href":"https:\/\/shattered.io\/fr\/wp-json\/wp\/v2\/posts\/226\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/shattered.io\/fr\/wp-json\/wp\/v2\/media\/227"}],"wp:attachment":[{"href":"https:\/\/shattered.io\/fr\/wp-json\/wp\/v2\/media?parent=226"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/shattered.io\/fr\/wp-json\/wp\/v2\/categories?post=226"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/shattered.io\/fr\/wp-json\/wp\/v2\/tags?post=226"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}