Agents IA : des échanges déjà exposés au risque quantique
Les agents IA échangent déjà des données à garder secrètes après 2030, sur des canaux dont la cryptographie a été héritée, jamais décidée. Pourquoi l'exposition quantique est déjà là, et cinq gestes.
Le 12 octobre 2026, l'office fédéral allemand de cybersécurité, le BSI, a publié avec deux ministères la ligne directrice nationale de migration post-quantique. Elle demande des responsables désignés et des plans de mise en œuvre contraignants d'ici fin 2026, des usages à haut risque protégés avant fin 2030, et vise la quasi-totalité des systèmes pour 2035. Elle décline la feuille de route européenne de juin 2025, dont le premier jalon tombe le 31 décembre 2026. Ces calendriers sont organisés par système et par usage, et aucun des deux textes ne mentionne les agents IA, qui échangent pourtant déjà des données à garder secrètes bien après 2030.
Prenons l'agent d'achat d'un industriel qui négocie avec l'agent commercial d'un fournisseur des prix, des volumes et un calendrier de livraison confidentiels dix-huit mois. Les deux agents s'authentifient, signent et journalisent, tandis que TLS, le protocole du cadenas des navigateurs, chiffre l'échange jusqu'au réseau de diffusion de contenu (CDN) du fournisseur. Personne, pourtant, n'a choisi l'échange de clés qui protège ce canal. L'équipe achats a retenu un cadre d'agents, l'équipe plateforme un hébergement, et le CDN applique sa propre configuration.
J'appelle ici agent un programme qui, piloté par un modèle, décide lui-même de ses appels à des outils ou à d'autres agents. Deux protocoles ouverts structurent ces échanges, MCP (Model Context Protocol) entre un agent et ses outils, et A2A (Agent2Agent) entre agents. Leurs spécifications détaillent l'identité et l'autorisation, exigent HTTPS pour l'autorisation (MCP) ou le chiffrement de tout déploiement en production (A2A), et confient le reste au TLS sous-jacent. Ni l'une ni l'autre ne précise l'échange de clés, et le post-quantique n'apparaît à ce jour dans aucune de leurs pages de transport ou de sécurité.
Pourquoi le risque est déjà là
Les textes allemand et européen nomment le même scénario, "stocker maintenant, déchiffrer plus tard". Un adversaire enregistre aujourd'hui un trafic chiffré et le déchiffrera quand un ordinateur quantique en sera capable. L'exposition dépend donc de la durée de confidentialité des données plus que de la date d'arrivée de la machine. La feuille de route européenne classe ainsi à haut risque tout usage dont la divulgation après dix ans ou plus causerait encore un dommage significatif, à protéger avant fin 2030.
Les prix de notre exemple auront sans doute expiré avant une telle machine. Mais ces canaux transportent aussi ce que la collecte vise, accords-cadres, dossiers de diligence, données de santé ou financières, code source, et les échanges de délégation qui disent quel agent peut ordonner quoi à quel autre. Un échange enregistré en 2026 pourrait ainsi devenir lisible au début des années 2030, l'hypothèse de travail du gouvernement fédéral allemand pour ses systèmes de haute sécurité. L'objection selon laquelle AES-256 résiste au calcul quantique ne tient pas ici, car chaque clé de session est négociée par l'échange de clés asymétrique classique du début de connexion. C'est cette poignée de main qu'un adversaire enregistre, et la casser plus tard livre les clés.
Qui fixe la posture du canal
Le point qui termine la connexion TLS, celui qui la déchiffre, retient l'échange de clés parmi ceux que le client propose, et se trouve à l'un de trois endroits. Au CDN, la feuille de route du prestataire décide. À une passerelle ou à un proxy, c'est l'équipe plateforme. Au serveur d'origine, c'est l'entreprise, par sa bibliothèque TLS, dont les versions récentes négocient l'hybride d'elles-mêmes et dont les autres restent classiques tant que personne n'y touche. Côté client, la bibliothèque du cadre d'agents doit elle aussi proposer l'hybride. Un grand réseau de diffusion indiquait le 29 septembre 2026 qu'environ 70 % du trafic navigateur qu'il reçoit négocie l'hybride, contre environ 15 % des serveurs d'origine qu'il contacte. Hériter d'une feuille de route crédible est une décision. Hériter du classique parce que personne n'a regardé n'en est pas une.
La réponse existe, la décision manque
L'échange de clés hybride combine un échange classique et un échange post-quantique, et la session reste confidentielle tant que l'un des deux tient. L'IETF l'a publié en août 2026 comme norme proposée pour TLS, les textes allemand et européen le recommandent, et le NCSC britannique a publié le 15 octobre ses configurations TLS post-quantiques, jugeant venu le moment de migrer. La difficulté est d'ordre architectural, savoir où se termine chaque canal d'agent, y décider la posture et garder la capacité de changer d'algorithme, ce qu'on appelle la crypto-agilité. Un composant ancien peut passer derrière un proxy qui termine l'hybride à sa place.
Pour la plupart des entités financières soumises à DORA, applicable depuis le 17 janvier 2025, cette capacité est une obligation en vigueur. Ses normes techniques (règlement délégué 2024/1774, article 6, paragraphe 4) demandent que la politique de chiffrement prévoie de mettre à jour ou de modifier, si nécessaire, la technologie cryptographique en fonction de l'évolution de la cryptanalyse. Elle porte sur la capacité de changer d'algorithme, pas sur le post-quantique, et un canal d'agent laissé sans décision s'y accorde mal, à mon sens. Le 2 octobre, au Forum Fintech de l'ACPR et de l'AMF, un responsable de l'autorité prudentielle indiquait qu'elle interroge déjà les établissements et insistera, sans doute en 2027, pour que chacun ait un plan d'action post-quantique. Dans la même intervention, la traçabilité des décisions des agents IA figurait à l'agenda de l'an prochain. La directive NIS 2 (article 21), pas encore transposée en France, demande plus largement des politiques sur l'usage de la cryptographie.
Cinq gestes permettent d'avancer, et le premier dresse la liste des canaux d'agents, serveurs d'outils et points d'échange entre agents, internes ou inter-entreprises. Le deuxième identifie, pour chacun, qui termine la connexion. Le troisième demande par écrit au prestataire sa posture et sa feuille de route post-quantiques pour ce trafic, et vérifie l'hybride à l'origine. Le quatrième classe chaque canal selon l'horizon de confidentialité de ce qu'il transporte, tout secret à garder au-delà du début des années 2030 étant concerné. Le cinquième décide, canal par canal, d'hériter ou de construire, et consigne ce choix. Pour démarrer, une demande écrite à l'équipe plateforme sur ces points de terminaison suffit, et les réponses forment un premier inventaire.
Sources
- BMDS, BMI et BSI, "Leitlinie zur Umstellung auf PQC. Nationale Umsetzung der EU-Roadmap zur Umstellung auf Post-Quanten-Kryptografie", document daté du 11 septembre 2026, publié le 12 octobre 2026 (communiqué du BSI, Bonn). Jalons fin 2026, fin 2030 et 2035 (§3, §4 et figure 2), procédés hybrides recommandés (§4.4), scénario "Store now, decrypt later" (p. 4), hypothèse de travail du gouvernement fédéral, début des années 2030 (note 3) · https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Krypto/Leitlinie-Umstellung-PQC.html · https://www.bsi.bund.de/DE/Service-Navi/Presse/Pressemitteilungen/Presse2026/261012_Leitlinie-PQC.html
- Groupe de coopération NIS, EU PQC Workstream, "A Coordinated Implementation Roadmap for the Transition to Post-Quantum Cryptography", partie 1, version 1.1, datée du 11 juin 2025, publiée le 23 juin 2025. Jalons au 31 décembre 2026, 2030 et 2035 (§4.1), seuil des dix ans pour le haut risque (§4.2), solutions hybrides recommandées · https://digital-strategy.ec.europa.eu/en/library/coordinated-implementation-roadmap-transition-post-quantum-cryptography
- ENISA, webinaire "ENISA PQC Webinars · How is Estonia approaching the Post-Quantum Cryptography transition?", jeudi 22 octobre 2026, 10 h 00 à 11 h 15 (heure de Bruxelles), en ligne · https://www.enisa.europa.eu/events/enisa-pqc-webinars-how-is-estonia-approaching-the-post-quantum-cryptography-transition
- Model Context Protocol, spécification, révision du 28 juillet 2026, pages transports, autorisation (OAuth 2.1, HTTPS obligatoire pour les points d'autorisation) et sécurité, consultées le 20 octobre 2026 · https://modelcontextprotocol.io/specification/2026-07-28
- A2A (Agent2Agent) Protocol, spécification v1.0.0, Linux Foundation, §13.4 (chiffrement obligatoire en production, TLS 1.3 recommandé), consultée le 20 octobre 2026 · https://a2a-protocol.org/latest/specification/
- Cloudflare, billet technique du 29 septembre 2026 (environ 70 % du trafic navigateur protégé par un échange hybride ML-KEM, environ 15 % des serveurs d'origine) · https://blog.cloudflare.com/post-quantum-visibility/
- IETF, RFC 10024, "Post-Quantum Traditional (PQ/T) Hybrid Key Agreement Mechanisms for TLS 1.3", Proposed Standard, août 2026 · https://datatracker.ietf.org/doc/rfc10024/
- NCSC (Royaume-Uni), "Post-quantum updates to our TLS guidance", billet du 15 octobre 2026 · https://www.ncsc.gov.uk/blogs/post-quantum-updates-to-our-tls-guidance
- Règlement (UE) 2022/2554 (DORA), applicable depuis le 17 janvier 2025 · règlement délégué (UE) 2024/1774 de la Commission du 13 mars 2024, article 6, paragraphe 4 · https://eur-lex.europa.eu/legal-content/FR/TXT/?uri=CELEX:32024R1774
- ACPR et AMF, Forum Fintech 2026, 2 octobre 2026, conclusion de l'atelier (enregistrement public sur la chaîne de l'ACPR, vers 5 h 19 du flux) · https://www.youtube.com/watch?v=oxeAEr9awE8&t=19193s
- Directive (UE) 2022/2555 (NIS 2), article 21, paragraphe 2, point h).