L’Internet Engineering Task Force a tranché en juillet 2026 : TLS 1.2 n’évoluera plus. La RFC 9851, publiée sous le titre « TLS 1.2 is in Feature Freeze » par le groupe de travail TLS de l’IETF, fige le protocole qui sécurise encore une bonne partie du web mondial. Aucune nouvelle fonctionnalité ne sera plus approuvée, hormis les correctifs de sécurité urgents, quelques nouveaux libellés d’export TLS et de nouveaux identifiants ALPN.
Le texte, signé par Rich Salz et Nimrod Aviram, ne supprime rien dans l’immédiat. Mais son message est limpide : l’avenir s’écrit en TLS 1.3. Cette annonce arrive au moment où plusieurs entreprises et administrations, d’Auth0 à la Bourse de Francfort, fixent déjà leurs propres dates de fin de vie pour TLS 1.2. En France, l’ANSSI recommande TLS 1.3 depuis plusieurs années déjà. En Allemagne, le BSI vient d’inscrire une échéance précise dans son référentiel technique. Voici ce que ce gel signifie concrètement, pour les entreprises comme pour les développeurs.
Ce que change concrètement la RFC 9851
La RFC 9851 n’interdit pas TLS 1.2. Elle gèle son développement. Dans le jargon de l’IETF, un « feature freeze » signifie que le groupe de travail cesse d’examiner les propositions d’évolution d’un protocole, sauf exception justifiée. Le texte précise trois exceptions : les correctifs de sécurité jugés urgents par consensus du groupe de travail TLS, les nouveaux libellés utilisés par le mécanisme d’export de clés (TLS Exporter Labels), et les nouveaux identifiants de négociation de protocole applicatif (ALPN). Le document précise aussi une limite technique importante : le gel concerne uniquement TLS, pas DTLS, sa variante pour les transports non fiables comme UDP.
Dans l’abstract du document, les auteurs justifient la décision par un constat simple : l’usage de TLS 1.3, qui corrige plusieurs faiblesses connues de TLS 1.2, continue de progresser. Plutôt que de maintenir deux protocoles actifs indéfiniment, l’IETF choisit de concentrer ses efforts d’ingénierie sur le plus récent. C’est une décision pragmatique, pas un couperet réglementaire. Aucune date de retrait de TLS 1.2 n’est fixée dans le texte lui-même.
Un calendrier 2026 qui s’est rempli en quelques mois
La RFC 9851 n’est pas un événement isolé. Elle arrive après une série d’annonces d’entreprises qui, chacune de leur côté, ont fixé une date de fin de vie pour TLS 1.2 ou pour les versions plus anciennes du protocole. Le tableau ci-dessous recense les échéances les plus concrètes rendues publiques depuis le début de l’année.
| Organisation | Échéance 2026 | Mesure annoncée |
|---|---|---|
| IETF (groupe de travail TLS) | Juillet 2026 | Publication de la RFC 9851, gel des fonctionnalités de TLS 1.2 |
| Microsoft Azure Storage | 3 février 2026 | Retrait définitif de TLS 1.0 et 1.1, sans exemption possible même sur demande |
| Mixpanel | Avril 2026 | Fin de TLS 1.0 et 1.1 sur ses API, adoption des algorithmes CNSA 2.0 |
| Auth0 | 10 juin (fin), 7 juillet (retrait) | Fin de vie des suites de chiffrement faibles encore acceptées sous TLS 1.2 |
| Eurex (Deutsche Börse) | 2026, à la publication de la version F7 4.5 | Passage à TLS 1.3 exclusif sur les interfaces destinées aux clients |
Le cas Eurex, symbole du secteur financier
La décision d’Eurex mérite un arrêt sur image. La plateforme de dérivés de Deutsche Börse a averti ses clients que ses interfaces F7, utilisées pour le trading algorithmique, passeraient à TLS 1.3 exclusif dès la sortie de la version 4.5. Pour des courtiers et des banques qui font tourner des connexions automatisées depuis parfois plus d’une décennie, ce type d’annonce impose une revue complète des chaînes de connexion, des bibliothèques clientes jusqu’aux pare-feux applicatifs. Le secteur financier, très réglementé, agit ici en éclaireur plutôt qu’en retardataire, contrairement à une idée reçue.
TLS 1.2 a 18 ans : retour sur un protocole increvable
TLS 1.2 a été publié en août 2008, sous la référence RFC 5246. Dix-huit ans plus tard, il reste l’un des protocoles cryptographiques les plus déployés au monde, présent sur des serveurs web, des bornes de paiement, des équipements industriels et des objets connectés qui ne seront peut-être jamais mis à jour. Cette longévité n’a rien d’un hasard. TLS 1.2 a survécu à des failles retentissantes comme Heartbleed ou POODLE, corrigées par des ajustements successifs plutôt que par un remplacement complet du protocole.
Cette capacité d’adaptation explique pourquoi tant d’organisations ont repoussé sa mise à la retraite. Chaque migration suppose de recertifier des équipements, de retester des intégrations tierces et parfois de renégocier des contrats avec des fournisseurs qui ne supportent que d’anciennes bibliothèques cryptographiques. Le gel décrété par la RFC 9851 ne change rien à cette réalité opérationnelle à court terme. Il envoie simplement un signal clair aux équipes qui planifient leurs budgets sur plusieurs années.
TLS 1.3, huit ans après : ce qui a vraiment changé
TLS 1.3 a été normalisé en août 2018 sous la référence RFC 8446, huit ans après son prédécesseur. Le protocole a fait le ménage. Il supprime l’échange de clés RSA statique et les suites de chiffrement jugées faibles, impose la confidentialité persistante (forward secrecy) sur toutes les connexions, et réduit la poignée de main initiale de deux allers-retours à un seul, ce qui accélère la première connexion à un site. Le nombre de suites cryptographiques autorisées a lui aussi fondu : quatre suites AEAD comme TLS_AES_256_GCM_SHA384 ou TLS_CHACHA20_POLY1305_SHA256 couvrent l’essentiel des usages, complétées par une cinquième variante réservée à des contextes contraints.
Pour un développeur, la bascule ne change presque rien au code applicatif. La bibliothèque TLS gère la négociation. La différence se joue plutôt côté infrastructure : configuration du serveur web, compatibilité des équilibreurs de charge, et parfois des équipements d’inspection réseau plus anciens qui ne savent pas déchiffrer le nouveau format de poignée de main. Notre comparatif TLS 1.3 face à TLS 1.2 détaille les écarts de performance et les CVE propres à chaque version pour les équipes qui préparent leur migration.
Geler plutôt que supprimer : la stratégie prudente de l’IETF
L’IETF aurait pu choisir une voie plus radicale, comme elle l’a fait avec TLS 1.0 et TLS 1.1, formellement dépréciés par la RFC 8996. Elle ne l’a pas fait pour TLS 1.2. Le choix du mot « freeze » plutôt que « deprecated » n’est pas anodin. TLS 1.2 reste massivement utilisé par des équipements industriels, des terminaux de paiement et des applications embarquées dont le cycle de remplacement se compte en décennies plutôt qu’en années. Une dépréciation pure et simple aurait fragilisé des pans entiers d’infrastructures encore en service.
Le compromis retenu revient donc à figer le protocole dans son état actuel, tout en laissant la porte ouverte aux correctifs de sécurité critiques. C’est une manière d’acter, sans le dire frontalement, que TLS 1.2 entre dans une phase de maintenance longue plutôt que dans un compte à rebours fixe. Reste que ce gel prive le protocole de toute amélioration future, y compris celles qui permettraient de le rendre compatible avec la cryptographie post-quantique.
Ce que recommande la France : le guide TLS de l’ANSSI
En France, l’Agence nationale de la sécurité des systèmes d’information publie et met à jour un guide dédié, les Recommandations de sécurité relatives à TLS. Sa position est constante depuis plusieurs versions : privilégier TLS 1.3, accepter TLS 1.2 à condition de restreindre les suites cryptographiques autorisées à des combinaisons précises, comme TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 pour une session TLS 1.2 avec la courbe elliptique secp256r1. L’agence ne fixe pas de date couperet dans ce document, mais son cadre technique élimine déjà la plupart des configurations héritées jugées faibles.
L’ANSSI est allée plus loin sur un point spécifique : la résistance quantique. Dans son guide dédié sur la transition post-quantique de TLS 1.3, l’agence recommande aux organisations d’adopter des mécanismes d’échange de clés hybrides, combinant un algorithme classique et un algorithme post-quantique, dès que les normes se stabilisent. Ce chantier s’inscrit dans une dynamique plus large : l’agence a par ailleurs annoncé qu’elle cesserait de certifier les produits de sécurité dépourvus de chiffrement résistant au quantique, un sujet que nous avons détaillé dans notre article sur la fin des certifications sans PQC dès 2027. TLS 1.2, par construction, ne pourra jamais accueillir cette hybridation post-quantique. C’est un argument de plus, silencieux mais réel, en faveur d’une bascule complète vers TLS 1.3.
L’Allemagne fixe une échéance : le BSI vise 2031
L’agence fédérale allemande pour la sécurité de l’information, le BSI, est allée plus loin que l’ANSSI sur un point précis : elle a inscrit une date. Selon sa directive technique TR-02102-2, TLS 1.2 ne reste recommandé que jusqu’à fin 2031, contre 2032 et au-delà pour TLS 1.3. La justification tient en une phrase : à la connaissance actuelle du BSI, aucun mécanisme d’échange de clés résistant au quantique ne sera normalisé pour TLS 1.2. Faute de pouvoir suivre la transition post-quantique, le protocole est condamné à sortir du référentiel allemand à moyen terme.
Cette précision change la nature du débat. Tant que personne ne fixait de date, la question de la fin de vie de TLS 1.2 restait théorique pour beaucoup d’équipes techniques. Avec 2031 inscrit noir sur blanc dans un référentiel gouvernemental, les directions informatiques disposent enfin d’un horizon de planification concret, même s’il ne s’applique formellement qu’aux organisations soumises au droit allemand.
Comparatif international des recommandations TLS
Les grandes agences de cybersécurité occidentales convergent sur le fond, TLS 1.3 en priorité et TLS 1.2 toléré sous conditions, mais elles divergent sur le calendrier. Outre-Manche, le NCSC britannique recommande TLS 1.3 et/ou TLS 1.2 selon des profils précis. Outre-Atlantique, le NIST impose TLS 1.3 aux serveurs fédéraux américains depuis le 1er janvier 2024. Voici où en sont les principales références utilisées par les équipes techniques françaises et européennes.
| Pays / Référence | Position sur TLS 1.2 | Position sur TLS 1.3 | Échéance chiffrée |
|---|---|---|---|
| France (ANSSI) | Accepté avec suites cryptographiques restreintes | Privilégié | Aucune date de fin publiée |
| Allemagne (BSI, TR-02102-2) | Recommandé jusqu’à fin 2031 | À utiliser en priorité | 2031 (TLS 1.2), 2032 et au-delà (TLS 1.3) |
| Royaume-Uni (NCSC) | Accepté avec profils de configuration recommandés | Conseillé pour préparer la cryptographie post-quantique | Aucune date fixe, transition progressive conseillée |
| États-Unis (NIST SP 800-52r2) | Obligatoire avec suites conformes FIPS pour les serveurs fédéraux | Obligatoire pour les serveurs et clients gouvernementaux | 1er janvier 2024 (échéance déjà passée) |
Ce tableau illustre une réalité simple : il n’existe aucune échéance mondiale unique pour l’extinction de TLS 1.2. Chaque juridiction avance à son rythme, en fonction de son propre calendrier de renouvellement d’infrastructures. Pour une entreprise opérant en France et en Allemagne, le référentiel le plus contraignant, en l’occurrence celui du BSI, dicte de fait la stratégie de migration la plus prudente à adopter.
Comment vérifier la version TLS utilisée par un serveur
Avant de planifier quoi que ce soit, encore faut-il savoir où en est son propre parc de serveurs. La commande OpenSSL suivante permet de tester rapidement si un service accepte encore TLS 1.2 ou impose déjà TLS 1.3, sans installer d’outil supplémentaire.
# Tester si le serveur accepte TLS 1.2
openssl s_client -connect exemple.fr:443 -tls1_2 -brief
# Tester si le serveur accepte TLS 1.3
openssl s_client -connect exemple.fr:443 -tls1_3 -brief
# Lister les protocoles et suites negocies en detail
nmap --script ssl-enum-ciphers -p 443 exemple.frUn serveur bien configuré doit accepter TLS 1.3 et, si TLS 1.2 reste actif pour des raisons de compatibilité, n’autoriser que des suites cryptographiques modernes, avec confidentialité persistante et algorithmes de hachage à 256 bits au minimum. Notre guide sur OpenSSL, clés et certificats détaille pas à pas la génération et l’audit de ce type de configuration côté serveur.
Impact sur le marché : CDN, cloud et éditeurs de logiciels
Le gel de TLS 1.2 ne va pas déclencher une vague d’achats à court terme, mais il pèse déjà sur les feuilles de route produit. Les grands fournisseurs de CDN et de cloud, qui gèrent le chiffrement pour des millions de domaines, avaient anticipé le mouvement depuis longtemps en poussant TLS 1.3 par défaut. Les éditeurs de logiciels d’entreprise, eux, découvrent souvent plus tard qu’une dépendance tierce, une bibliothèque cryptographique embarquée dans un produit vieux de dix ans, ne sait tout simplement pas parler TLS 1.3.
L’écosystème des autorités de certification est concerné indirectement. La réduction de la durée de vie des certificats, qui passera à 47 jours d’ici 2029 selon le calendrier du CA/Browser Forum que nous détaillions dans notre article sur les certificats SSL/TLS à 47 jours, pousse déjà les entreprises vers l’automatisation complète du cycle de vie de leurs certificats. Cette automatisation, une fois en place, facilite mécaniquement l’abandon des configurations TLS 1.2 héritées, puisque les mêmes outils gèrent souvent les deux chantiers en parallèle. Des autorités comme Let’s Encrypt, dont nous comparions le modèle gratuit aux offres payantes dans notre comparatif dédié, jouent un rôle moteur dans cette automatisation.
Les équipements qui ne pourront pas suivre
Le vrai point de friction se situe du côté du matériel industriel et des objets connectés. Automates programmables, caméras de vidéosurveillance, bornes de paiement plus anciennes : une partie de ce parc ne recevra jamais de mise à jour vers TLS 1.3, faute de puissance de calcul suffisante ou simplement parce que le fabricant a cessé toute maintenance. Pour ces équipements, le gel de TLS 1.2 ne change rien dans l’immédiat, mais il confirme qu’ils resteront figés sur un protocole qui n’évoluera plus jamais, dans un monde où les menaces, elles, continuent de progresser.
Ce que risquent les entreprises qui traînent des pieds
À court terme, rien ne change pour une entreprise qui continue d’exploiter TLS 1.2 avec des suites cryptographiques modernes. Le risque est ailleurs, dans l’accumulation de dette technique. Chaque nouvelle norme sectorielle, chaque nouvel audit de conformité, chaque nouveau client exigeant un niveau de sécurité supérieur pousse un peu plus vers la sortie les configurations héritées. Une entreprise qui n’a toujours pas migré quand un client stratégique impose contractuellement TLS 1.3 se retrouve à faire dans l’urgence un chantier qui aurait pu être planifié sur plusieurs mois.
Le secteur financier, avec l’exemple d’Eurex, montre la voie à suivre : anticiper plutôt que subir. À l’inverse, les secteurs moins réglementés, commerce en ligne, PME industrielles, associations, risquent de découvrir le sujet au moment d’un incident ou d’un audit, un scénario nettement plus coûteux qu’une migration planifiée.
Le lien avec la transition post-quantique
Le gel de TLS 1.2 s’inscrit dans une dynamique plus large que le seul confort de maintenance de l’IETF. La cryptographie post-quantique impose des clés et des mécanismes d’échange plus complexes, que seul TLS 1.3 est structurellement capable d’accueillir à terme. En bloquant toute évolution de TLS 1.2, la RFC 9851 verrouille de fait ce protocole hors du chantier post-quantique qui occupe déjà les agences de cybersécurité de toute l’Europe.
Cette convergence explique pourquoi les équipes qui pilotent aujourd’hui leur migration TLS ont intérêt à traiter les deux chantiers ensemble plutôt que séparément : la bascule vers TLS 1.3 d’un côté, la préparation des mécanismes hybrides post-quantiques de l’autre. Traiter ces sujets isolément, c’est risquer de devoir toucher deux fois à la même infrastructure en quelques années.
Cinq prédictions pour la période 2026-2031
- D’autres entreprises annonceront des dates de retrait. Après Auth0, Eurex, Azure et Mixpanel, d’autres fournisseurs cloud et éditeurs SaaS devraient publier leur propre calendrier de fin de vie pour TLS 1.2 d’ici la fin de 2026 ou 2027, par effet d’entraînement.
- TLS 1.2 ne sera pas formellement déprécié à court terme. Contrairement à TLS 1.0 et 1.1, le protocole devrait rester dans une zone grise de maintenance minimale pendant plusieurs années encore, faute de consensus international sur une date de retrait ferme.
- D’autres agences nationales fixeront des échéances chiffrées. L’exemple du BSI et son horizon 2031 devrait inspirer d’autres référentiels européens, à mesure que la pression post-quantique se précise.
- La pression réglementaire sectorielle s’étendra au-delà de la finance. Après l’exemple d’Eurex, la santé et les infrastructures critiques, déjà sous surveillance renforcée par le Cyber Resilience Act, devraient suivre un mouvement comparable.
- Le parc industriel et IoT restera le point faible. Une part significative des équipements connectés continuera de fonctionner sous TLS 1.2, voire sous des versions antérieures non supportées, créant une zone de risque durable que les grandes annonces d’entreprises ne résolvent pas.
Foire aux questions
Qu’est-ce que la RFC 9851 change concrètement ?
Elle gèle les évolutions futures de TLS 1.2. Seuls les correctifs de sécurité urgents, de nouveaux libellés d’export de clés et de nouveaux identifiants ALPN pourront encore être ajoutés au protocole. Aucune autre fonctionnalité ne sera plus approuvée par le groupe de travail TLS de l’IETF.
TLS 1.2 va-t-il disparaître en 2026 ?
Non. La RFC 9851 gèle le protocole, elle ne le supprime pas. TLS 1.2 continuera de fonctionner sur les serveurs qui le supportent. Certaines entreprises, comme Auth0 ou Eurex, ont toutefois fixé leurs propres échéances de retrait en 2026, indépendamment du calendrier de l’IETF.
Dois-je désactiver TLS 1.2 sur mon serveur dès maintenant ?
Pas nécessairement dans l’urgence, à condition de restreindre les suites cryptographiques autorisées aux combinaisons modernes recommandées par l’ANSSI ou le NIST. Le passage à TLS 1.3 en priorité, avec TLS 1.2 en repli pour la compatibilité, reste l’approche la plus réaliste pour la majorité des organisations.
Quelle est la différence principale entre TLS 1.2 et TLS 1.3 ?
TLS 1.3 supprime les suites de chiffrement faibles et l’échange de clés RSA statique, impose la confidentialité persistante sur toutes les connexions, et réduit la poignée de main initiale de deux allers-retours à un seul. TLS 1.2 conserve un éventail de configurations plus large, y compris certaines jugées obsolètes si elles ne sont pas explicitement désactivées.
Que recommande l’ANSSI aux entreprises françaises ?
De privilégier TLS 1.3 et de n’accepter TLS 1.2 qu’avec des suites cryptographiques restreintes, précisément documentées dans son guide « Recommandations de sécurité relatives à TLS ». L’agence recommande aussi de préparer l’hybridation post-quantique dans les déploiements TLS 1.3 les plus sensibles.
Pourquoi l’Allemagne fixe-t-elle précisément 2031 ?
Parce que le BSI estime qu’aucun mécanisme d’échange de clés résistant au quantique ne sera normalisé pour TLS 1.2 d’ici là. Le protocole ne pouvant pas accueillir cette évolution, l’agence allemande a préféré fixer une date plutôt que de laisser la question ouverte indéfiniment.
Le passage à TLS 1.3 protège-t-il contre l’informatique quantique ?
Pas automatiquement. TLS 1.3 seul n’est pas résistant au quantique. Il constitue en revanche le seul protocole capable d’accueillir les mécanismes d’échange de clés hybrides post-quantiques recommandés par l’ANSSI, ce que TLS 1.2 ne pourra structurellement jamais faire.
Comment vérifier rapidement quelle version de TLS utilise mon site ?
La commande openssl s_client -connect votredomaine.fr:443 -tls1_3 confirme si le serveur accepte TLS 1.3. Des outils en ligne d’audit SSL/TLS permettent aussi un diagnostic complet sans installation, en listant l’ensemble des versions et suites cryptographiques acceptées par le serveur.
