Aujourd’hui marque la fin de notre première Agents Week – une semaine consacrée à l’innovation, entièrement dédiée à l’ère des agents. La date n’aurait pu être plus opportune : au cours de l’année passée, les agents ont rapidement transformé l'approche du travail des utilisateurs. Les agents de codage aident aujourd'hui les développeurs à déployer des solutions plus rapidement que jamais auparavant. Les agents d'assistance résolvent les tickets de bout en bout. Les agents de recherche vérifient des hypothèses en consultant des centaines de sources en quelques minutes seulement. Par ailleurs, les utilisateurs ne se contentent pas d'exécuter un seul agent : ils en exécutent une multitude en parallèle, de jour comme de nuit.

Comme l’ont souligné Dane Knecht, CTO de Cloudflare, et Rita Kozlov, VP Product de Cloudflare, dans notre article de blog Bienvenue dans l'Agents Week, l’ampleur potentielle des agents est stupéfiante : si même une fraction des travailleurs du savoir du monde exécutait chacun quelques agents en parallèle, il faudrait disposer d'une capacité de calcul suffisante pour exécuter des dizaines de millions de sessions simultanées. Le modèle « d'une application servant de nombreux utilisateurs » sur lequel repose le cloud ne convient pas à cela. Or, c’est précisément ce que souhaitent faire les développeurs et les entreprises : créer des agents, les déployer auprès des utilisateurs et les exécuter à grande échelle.

Pour y parvenir, il sera nécessaire de résoudre des problèmes affectant l’ensemble de l'environnement technologique. Les agents ont besoin d’une puissance de calcul capable d'évoluer d’un système d’exploitation complet à des isolats légers. Ils ont besoin d’une sécurité et d’une identité intégrées à leur fonctionnement.  Ils ont besoin d’une suite d'outils pour agents: les modèles, les outils et le contexte pertinents pour accomplir un travail concret. L'ensemble du code généré par les agents doit suivre un parcours clair, d'un simple prototype à l'application de production. Enfin, tandis que les agents sont à l'origine d'une part croissante du trafic Internet, le web lui-même doit s'adapter à l'émergence du web agentique. Il s’avère que la plateforme de calcul sans conteneur et serverless que nous avons lancée il y a huit ans avec Workers était parfaitement adaptée à ce moment. Depuis, nous l’avons développée pour en faire une plateforme complète et, cette semaine, nous avons lancé une nouvelle série de primitives dédiées aux agents, conçues pour répondre précisément à ces problématiques.

Notre objectif consiste à créer le Cloud 2.0, le cloud agentique – une infrastructure conçue pour un monde dans lequel les agents constituent une charge de travail principale. 

Voici la liste de toutes les annonces que nous avons faites cette semaine, pour que vous n'en manquiez pas une seule.

Nous avons commencé par le calcul. Les agents ont besoin d'un environnement d'exécution, ainsi que d'un espace pour stocker et exécuter le code qu'ils écrivent. Tous les agents n'ont pas les mêmes besoins : certains nécessitent un système d'exploitation complet, permettant l'installation de packages et l'exécution de commandes de terminal, tandis que la plupart requièrent une solution légère, capable de démarrer en quelques millisecondes et d'évoluer massivement. Cette semaine, nous avons déployé les environnements nécessaires à leur exécution, ainsi qu'un nouvel espace de travail compatible avec Git pour les agents :

L’exécution d’agents et de leur code ne représente que la moitié du défi. Les agents se connectent à des réseaux privés, accèdent à des services internes et effectuent des actions de manière autonome pour le compte des utilisateurs. Lorsque tous les collaborateurs d'une entreprise peuvent déployer leurs propres agents, la sécurité ne peut pas être reléguée au second plan. Elle doit devenir le mode de fonctionnement par défaut. Cette semaine, nous avons inauguré les outils qui permettent de parvenir facilement à ce résultat.

Un agent performant doit être capable de réfléchir, de mémoriser, de communiquer et de voir. Pour cela, il doit disposer de modèles adéquat et avoir accès à des outils appropriés et à un contexte pertinents pour accomplir la tâche qui lui est attribuée. Cette semaine, nous avons lancé les composantes primitives (inférence, recherche, mémoire, voix, messagerie électronique et navigateur) qui permettent à un agent d'être réellement opérationnel.

La meilleure infrastructure doit également être facile à utiliser. Nous souhaitons aller à la rencontre des développeurs et de leurs agents là où ils opèrent déjà (sur le terminal, dans l’éditeur et dans l'invite de commande) et leur permettre d'accéder à l’intégralité de la plateforme Cloudflare sans changement de contexte.

Un nombre croissant d'agents se connectent désormais à Internet, mais naviguent encore sur un Internet conçu pour les humains. Les sites web existants ont besoin de nouveaux outils pour contrôler l'accès des bots à leur contenu, regrouper les contenus et les présenter aux agents et mesurer leur état de préparation à ce changement.

L’Agents Week 2026 touche à sa fin, mais le cloud agentique n'en est qu'à ses débuts. Tout ce que nous avons déployé cette semaine, des services de calcul et de sécurité à la suite d'outils pour agents et au web agentique, en constitue la fondation. Nous allons continuer à créer sur cette fondation afin de vous offrir tout ce dont vous aurez besoin pour développer les services de demain.

D'autres articles seront publiés aujourd'hui et demain afin de continuer cette histoire ; alors, restez à l’écoute des dernières actualités sur notre blog.

Si vous utilisez les produits que nous avons annoncés cette semaine pour développer des services, nous serions ravis d'en entendre parler. Venez nous retrouver sur X ou sur Discord, ou consultez notre documentation pour développeurs.

Nous pensons qu’il est nécessaire de disposer d’une nouvelle primitive : un système de fichiers distribué et versionné, conçu avant tout pour les agents, et capable de servir les types d’applications développés aujourd’hui.

C’est ce que nous appelons Artifacts : un système de fichiers versionné qui parle le Git. Vous pouvez créer par programmation des référentiels, en même temps que vos agents, sandbox, Workers ou tout autre paradigme de calcul, et vous y connecter depuis n’importe quel client Git standard.

Souhaitez-vous prévoir un référentiel pour chaque session d’agent ? Artifacts peut le faire. Chaque instance de sandbox ? Également Artifacts. Souhaitez-vous créer 10 000 reprises logicielles à partir d’un point de départ connu pour être fiable ? Vous l’avez deviné : toujours Artifacts. Artifacts expose une API REST et une API Workers native pour créer des référentiels, générer des identifiants et procéder à dse validations pour les environnements auxquels un client Git n’est pas adapté (c’est-à-dire dans n’importe quelle fonction serverless).

Artifacts est disponible en version bêta privée pour tous les développeurs ayant souscrit à l’offre Workers payante, et nous avons l’intention de le proposer en version bêta publique au début du mois de mai.

// Create a repo
const repo = await env.AGENT_REPOS.create(name)
// Pass back the token & remote to your agent
return { repo.remote, repo.token }

# Clone it and use it like any regular git remote
$ git clone https://x:${TOKEN}@123def456abc.artifacts.cloudflare.net/git/repo-13194.git

Et voilà ! Un simple référentiel, prêt à l’emploi, créé à la volée, avec lequel n’importe quel client Git peut interagir.

Et si vous voulez amorcer un référentiel Artifacts à partir d’un référentiel git existant afin que votre agent puisse y travailler de manière indépendante et effectuer des modifications indépendantes, vous pouvez le faire également avec .import():

interface Env {
  ARTIFACTS: Artifacts
}

export default {
  async fetch(request: Request, env: Env) {
    // Import from GitHub
    const { remote, token } = await env.ARTIFACTS.import({
      source: {
        url: "https://github.com/cloudflare/workers-sdk",
        branch: "main",
      },
      target: {
        name: "workers-sdk",
      },
    })

    // Get a handle to the imported repo
    const repo = await env.ARTIFACTS.get("workers-sdk")

    // Fork to an isolated, read-only copy
    const fork = await repo.fork("workers-sdk-review", {
      readOnly: true,
    })

    return Response.json({ remote: fork.remote, token: fork.token })
  },
}

Consultez la documentation pour vous lancer, ou si vous souhaitez comprendre comment Artifacts est utilisé, comment il a été conçu et comment il fonctionne en coulisses : poursuivez la lecture.

Les agents connaissent Git. Il est profondément inscrit dans les données d’entraînement de la plupart des modèles. Le scénario idéal et les cas particuliers sont bien connus des agents, et les modèles optimisés en fonction du code (ou les harnais) sont particulièrement efficaces dans l’utilisation de Git.

Par ailleurs, le modèle de données de Git convient non seulement au contrôle des sources, mais aussi à toute situation pour laquelle vous vous avez besoin de suivre l’état, remonter dans le temps et conserver pendant longtemps de grandes quantités de petites données. Code, configuration, invites de session et historique de l’agent : tous ces éléments (les « objets ») que vous souhaitez souvent stocker sous forme de petits fragments (les « validations ») afin de pouvoir y revenir ou les rétablir (« historique »). 

Nous aurions pu inventer un protocole entièrement nouveau, sur mesure... mais se pose alors le problème du démarrage (bootstrap). Les modèles d’IA ne le connaissent pas, vous devez donc répartir les compétences, ou une interface de ligne de commande (CLI), ou encore espérer que les utilisateurs sont connectés à vos documents MCP... tout cela ajoute des contraintes. Et si nous pouvions nous contenter de fournir aux agents une URL Git distante HTTPS authentifiée et sécurisée, et les faire fonctionner comme s’il s’agissait d’un référentiel Git ? Il s’avère que la solution fonctionne plutôt bien. Et pour les clients ne parlant pas le Git — tels qu’un Cloudflare Worker, une fonction Lambda ou une application Node.js — nous proposons une API REST et (bientôt) des SDK spécifiques à chaque langage. Ces clients peuvent également utiliser isomorphic-git, mais dans de nombreux cas, une API TypeScript plus simple peut réduire la surface d’API nécessaire.

Vous pourriez avoir l’impression que l’API Git d’Artifacts ne sert qu’au contrôle de version, mais il s’avère que l’API Git et le modèle de données constituent un moyen puissant de conserver un état persistant, d’une manière qui vous permette de procéder à des reprises logicielles, de remonter dans le temps et de différencier les états pour n’importe quelle donnée.

Au sein de Cloudflare, nous utilisons la solution Artifacts pour nos agents internes : en maintenant automatiquement l’état actuel du système de fichiers et l’historique de session au sein d’un référentiel Artifacts par session. Cela nous permet de :

• Consolider l’état de la sandbox sans avoir à provisionner (et conserver) le stockage par blocs.

• Partager les sessions avec d’autres utilisateurs et leur permettre de remonter dans le temps à la fois dans l’état de la session (invite) et dans l’état du fichier, indépendamment du fait que des validations aient été effectuées dans le référentiel « réel » (contrôle de la source).

• Et le meilleur pour la fin : dupliquer une session à partir de n’importe quel point, et laisser notre équipe partager des sessions avec un collègue et lui permettre de la reprendre. Vous déboguez quelque chose et vous voulez un autre avis ? Envoyer une URL et la dupliquer. Vous voulez améliorer une API ? Demandez à un collègue de la dupliquer et de reprendre là où vous vous êtes arrêté.

Nous avons également parlé à des équipes qui souhaitent utiliser Artifacts dans des cas où le protocole Git n’est pas du tout obligatoire, mais où la sémantique (restauration, clonage, comparaison des différences) l’est. Vous stockez les configurations personnalisées par client dans le cadre de votre produit et vous souhaitez bénéficier de la possibilité de les restaurer ? Les artefacts peuvent en être une bonne représentation.

Nous sommes impatients de voir les équipes explorer les scénarios d’utilisation hors Git autour d’Artifacts, autant que ceux liés à Git.

Artifacts est construit à partir de Durable Objects. La capacité de créer des millions (ou des dizaines de millions) d’instances de calcul isolé et avec état est inhérente au fonctionnement actuel de Durable Objects ; c’est exactement ce dont nous avions besoin pour prendre en charge des millions de référentiels Git par espace de noms.

La Major League Baseball (pour la diffusion en direct des matchs), les tableaux blancs de Confluence et notre propre SDK Agents utilisent des Durable Objects en coulisses à une échelle significative ; nous développons donc cette solution sur une primitive que nous avons en production depuis un certain temps.

Ce dont nous avions besoin, toutefois, était une mise en œuvre de Git pouvant être exécutée sur Cloudflare Workers. Elle devait être petite, aussi complète que possible, extensible (notes, LFS) et efficace. Nous en avons donc créé une dans Zig, et nous l’avons compilée dans Wasm.

Pourquoi avons-nous utilisé Zig ? Trois raisons :

1.  L’ensemble du moteur de protocoles git est écrit en Zig pur (pas de libc), compilé dans un fichier binaire WASM d’environ 100 Ko (avec de l’espace pour l’optimisation !). Il met en œuvre SHA-1, la compression/décompression zlib, l’encodage/décodage delta, l’analyse des paquets et le protocole git smart HTTP complet, le tout, de A à Z, sans aucune dépendance externe autre que la bibliothèque standard.

2.  Zig nous permet de contrôler manuellement l’allocation de mémoire, ce qui est important dans les environnements limités tels que Durable Objects. Le système de génération Zig nous permet de partager facilement du code entre le runtime de WASM (WebAssembly) (production) et les versions natives (tests avec libgit2 pour vérification de l’exactitude).

3. Le module WASM communique avec l’hôte JS par l’intermédiaire d’une interface légère de rappel : 11 fonctions importées par l’hôte pour les opérations de stockage (host_get_object, host_put_object, etc.) et une pour la diffusion en sortie (host_emit_bytes). Le côté WASM peut être entièrement testé en environnement isolé.

En arrière-plan, Artifacts utilise également R2 (pour les instantanés) et KV (pour le suivi des jetons d’authentification) :

^{Fonctionnement d’Artifacts (Workers, Durable Objects et WebAssembly)}

Un Worker agit comme le front-end, gérant l’authentification et l’autorisation, les indicateurs clés (erreurs, latence) et recherchant chaque référentiel Artifacts (Durable Object) à la volée. 

Ces initiatives comprennent plus spécifiquement les mesures suivantes :

• Les fichiers sont stockés dans la base de données SQLite de l’Objet durable sous-jacent.

  • Le stockage Durable Object ne peut pas dépasser 2 Mo de lignes : les objets Git volumineux sont donc fragmentés et stockés sur plusieurs lignes.

  • Nous utilisons l’API sync KV (state.storage.kv)  qui dans son fonctionnement interne repose sur SQLite.

•  Les DO (Durable Objects) ont des limites de mémoire d’environ 128 Mo : cela signifie que nous pouvons en générer des dizaines de millions (ils sont rapides et légers), mais nous devons respecter ces limites.

  • Nous utilisons intensivement la diffusion en continu pour les chemins de récupération et d’envoi, et renvoyons directement un `ReadableStream<Uint8Array>` construit à partir des fragments de sortie WASM bruts.

  • Nous évitons de calculer nos propres deltas git ; au lieu de cela, les deltas bruts et les hachages de base sont conservés parallèlement à l’objet résolu. Lors d’une récupération, si le client demandeur possède déjà l’objet de base, Zig émet le delta au lieu de l’objet complet, ce qui permet d’économiser de la bande passante et de la mémoire.

• Prise en charge de la version v1 et v2 du protocole Git.

  • Nous prenons en charge des fonctionnalités telles que ls-refs, des clones peu profonds (deepen, deepen-since, deepen-relative) et la récupération incrémentielle avec négociation have/want.

  • Nous disposons d’une suite de tests complète, avec des tests de conformité sur des clients git et des tests de vérification sur un serveur libgit2 conçu pour valider la prise en charge des protocoles.

Par ailleurs, nous proposons la prise en charge native des notes git. La solution Artifacts est conçue pour être orientée agent, et les notes permettent aux agents d’ajouter des notes (métadonnées) aux objets Git. Cela comprend les invites, l’attribution d’agent et d’autres métadonnées qui peuvent être lues/écrites depuis le référentiel sans muter les objets eux-mêmes.

La plupart des référentiels ne sont pas très volumineux et Git est conçu pour être extrêmement efficace en matière de stockage : la plupart des référentiels sont clonés en quelques secondes seulement, au maximum, et ce phénomène est dominé par le temps de configuration du réseau, l’authentification et le calcul de la somme de contrôle. Dans la plupart des scénarios d’agent ou de sandbox, c’est possible : il suffit de cloner le référentiel au démarrage de la sandbox et de commencer à travailler.

Mais qu’en est-il d’un référentiel de plusieurs Go ou d’un référentiel contenant des millions d’objets ? Comment cloner rapidement ce référentiel, sans bloquer la capacité de l’agent à travailler pendant quelques minutes et à consommer beaucoup de puissance de calcul ?

Le clone d’un framework web populaire (à un volume de 2,4 Go et avec un long historique !) prend près de 2 minutes. Un clone peu profond est plus rapide, mais pas suffisant pour atteindre un chiffre de quelques secondes, et nous ne voulons pas toujours ignorer l’historique (les agents trouvent cela utile).

Pouvons-nous réduire les référentiels volumineux à environ 10 à 15 secondes pour que notre agent puisse se mettre au travail ? Eh bien, oui : en suivant quelques conseils !

Dans le cadre du lancement d’Artifacts, nous proposons ArtifactFS en open source, un pilote de système de fichiers conçu pour monter des référentiels Git volumineux aussi rapidement que possible, en chargeant le contenu des fichiers à la volée, au lieu de bloquer lors du clone initial. Il est idéal pour les agents, les sandbox, les conteneurs et les autres scénarios d’utilisation dans lesquels le temps de démarrage est très important. Si vous pouvez réduire d’environ 90 à 100 secondes le temps de démarrage de votre sandbox pour chaque grand dépôt, et que vous exécutez 10 000 de ces tâches par mois : cela représente 2 778 heures de sandbox économisées.

Vous pouvez envisager ArtifactFS comme un « clone Git, mais asynchrone » :

• ArtifactFS exécute un clone sans blobs d’un référentiel Git : il récupère l’arborescence de fichiers et les références, mais pas le contenu des fichiers. Il peut accomplir cette tâche lors du démarrage de la sandbox, ce qui permet ensuite à votre harnais d’agent de se mettre au travail.

• En arrière-plan, il commence à hydrater (télécharger) le contenu des fichiers simultanément par l’intermédiaire d’un démon léger.

• Il donne la priorité aux fichiers sur lesquels les agents veulent généralement travailler en premier : les manifestes de packages (package.json, go.mod), les fichiers de configuration et le code, en dépriorisant les blobs binaires (images, exécutables et autres fichiers non texte) chaque fois que possible, afin que les agents puissent parcourir l’arborescence de fichiers pendant que les fichiers eux-mêmes sont hydratés.

• Si un fichier n’est pas complètement hydraté lorsque l’agent essaie de le lire, la lecture sera bloquée jusqu’à ce qu’il soit hydraté.

Le système de fichiers ne tente pas de « synchroniser » les fichiers avec le référentiel distant : avec des milliers ou des millions d’objets, l’opération est généralement très lente, et comme il s’agit de Git, nous n’avons pas besoin de le faire. Votre agent a simplement besoin de valider et envoyer (push), comme il le ferait avec n’importe quel référentiel. Aucune nouvelle API à apprendre.

Qui plus est, ArtifactFS fonctionne avec n’importe quel Git distant, pas seulement avec nos propres Artifacts. Si vous clonez des référentiels volumineux issus de GitHub, de GitLab ou d’une infrastructure Git auto-hébergée, vous pouvez toujours utiliser ArtifactFS.

Le lancement d’aujourd’hui ne concerne qu’une version bêta, et nous travaillons déjà sur un certain nombre de fonctionnalités que vous découvrirez au cours des prochaines semaines :

• Élargissement des indicateurs disponibles que nous exposons. Aujourd’hui, nous fournissons des mesures correspondant au nombre d’opérations clés par espace de noms, référentiel et octets stockés par référentiel, de sorte que la gestion de millions d’Artifacts n’est pas fastidieuse.

• Prise en charge des abonnements aux événements pour les événements au niveau du référentiel, afin de nous permettre d’émettre des événements sur les envois, extractions, clones et reprises logicielles vers n’importe quel référentiel au sein d’un espace de noms. Ce mode de fonctionnement vous permettra également de consommer des événements, d’écrire des webhooks et d’utiliser ces événements pour notifier les utilisateurs finaux, gérer les événements de cycle de vie au sein de vos produits ou exécuter des tâches de post-envoi (comme l’intégration continue/la livraison continue (CI/CD).

• SDK clients natifs TypeScript, Go et Python pour interagir avec l’API Artifacts

• API de recherche au niveau du référentiel et à l’échelle de l’espace de noms, par exemple « chercher tous les référentiels associés à un fichier package.json ». 

Nous prévoyons également une API pour Workers Builds, qui vous permettra d’exécuter des tâches d’intégration continue/de livraison continue (CI/CD) sur n’importe quel flux de travail piloté par un agent.

Nous n’en sommes encore qu’aux débuts avec Artifacts, mais nous souhaitons que notre tarification soit efficace à l’échelle agentique : elle doit être rentable pour des millions de référentiels, les référentiels inutilisés (ou rarement utilisés) ne doivent pas constituer un frein, et notre tarification doit correspondre à la nature massivement mono-locataire des agents.

Vous ne devriez pas non plus avoir à vous demander si un référentiel va être utilisé ou non, s’il fait chaud ou froid ou si un agent va le réveiller. Nous vous facturerons le stockage que vous consommez et les opérations (p. ex. clonages, envois, reprises logicielles et extractions) pour chaque dépôt.

Les référentiels volumineux et très fréquentés coûteront plus cher que les référentiels plus petits et moins souvent utilisés, que vous en ayez 1 000, 100 000 ou 10 millions.

Nous ajouterons également Artifacts à l’offre gratuite Workers (dans certaines limites équitables) au fur et à mesure de la progression de la version bêta, et nous fournirons des mises à jour tout au long de la version bêta en cas de modification de la tarification et avant la facturation de toute utilisation.

Artifacts est lancé en version bêta privée, et nous prévoyons une version bêta publique pour le début du mois de mai (2026, pour être précis !). Nous allons intégrer les clients progressivement au cours des prochaines semaines, et vous pouvez manifester directement votre intérêt pour la bêta privée.

En attendant, vous pouvez en apprendre davantage sur « Artifacts » en :

• Lisant le guide de démarrage dans les docs.

• Accédant au tableau de bord de Cloudflare (Build > Storage & Databases > Artifacts)

• Consultant les exemples de l’API REST

• En savoir plus sur le fonctionnement d’Artifacts dans les coulisses

Suivez le journal des modifications pour suivre la version bêta dans sa progression.

Un événement survenu plus tôt cette année a bouleversé notre perception de l’IA. Des outils tels que Pi, OpenClaw, Claude Code et Codex ont démontré une idée simple, mais puissante : si vous donnez à un LLM la capacité de lire des fichiers, d’écrire du code, de l’exécuter et de mémoriser ce qu’il a appris, vous obtiendrez une solution qui ressemble davantage à un assistant généraliste qu’à un outil de développement.

Ces agents de codage ne se contentent plus d’écrire du code. Les utilisateurs s’en servent pour gérer leurs calendriers, analyser des ensembles de données, négocier des achats, remplir leurs déclarations d’impôts et automatiser des processus opérationnels entiers. Le schéma est toujours le même : l’agent analyse le contexte, exécute un raisonnement, écrit du code pour agir, observe le résultat, puis recommence. Le code est le moyen d’action universel.

Notre équipe, qui utilise ces agents de codage tous les jours, se heurtait continuellement aux mêmes obstacles :

• Les agents s’exécutent uniquement sur votre ordinateur portable ou sur un serveur virtuel privé (VPS) coûteux : il n’y a ni partage, ni collaboration, ni transfert entre les appareils.

• Ils sont coûteux lorsqu’ils sont inactifs : un agent comporte un coût mensuel fixe, qu’il fonctionne ou non. Si vous transposez ce coût à une équipe, voire à une entreprise, le montant augmente rapidement.

• Les agents nécessitent une gestion et une configuration manuelles : installation des dépendances, gestion des mises à jour, configuration des identités et des secrets.

Il existe par ailleurs un problème structurel plus profond. Les applications traditionnelles servent une multitude d’utilisateurs depuis une instance unique. Comme nous l’avons indiqué dans notre article « Bienvenue dans l’Agents Week », les agents opèrent selon un principe « un pour un ». Chaque agent est une instance unique, qui sert un utilisateur et exécute une tâche. Un restaurant propose un menu et dispose d’une cuisine optimisée pour préparer des plats en grande quantité. Un agent ressemble davantage à un chef à domicile : à chaque fois, il utilise d’autres ingrédients, d’autres techniques et d’autres outils.

Cela modifie radicalement les calculs concernant l’évolutivité. Si cent millions de travailleurs du savoir utilisent chacun un assistant agentique, même avec un nombre modeste de sessions simultanées, vous devez disposer d’une capacité permettant de gérer des dizaines de millions de sessions simultanées. Compte tenu des coûts par conteneur actuels, cette approche n’est pas viable. Nous avons besoin d’une fondation différente.

Et c’est ce que nous avons développé, dernièrement.

Project Think propose un ensemble de nouvelles composantes primitives pour le SDK Agents :

• Exécution durable avec les « fibers » : reprise après incident, points de sauvegarde et persistance automatique

• Sous-agents : agents enfants isolés disposant chacun de leur propre instance SQLite et d’un RPC typé

• Sessions persistantes : messages structurés en arborescence, création de branches, compaction, recherche en texte intégral

• Exécution de code en sandbox : instances Dynamic Workers, codemode, résolution dynamique des packages npm lors de l’exécution

• L’échelle d’exécution : espace de travail, isolat, npm, navigateur, sandbox

• Extensions auto-générées : les agents créent leurs propres outils lors de l’exécution

Chacune de ces composantes primitives est utilisable directement avec la classe de base Agent. Vous pouvez utiliser les primitives pour développer précisément les agents dont vous avez besoin ou utiliser la classe de base de Think pour vous lancer rapidement. Examinons ce que fait chacune d’elles.

Les agents, tels qu’ils existent aujourd’hui, sont éphémères. Ils s’exécutent le temps d’une session, liés à un processus ou à un appareil unique, puis ils s’arrêtent. Un agent de codage qui s’arrête lorsque votre ordinateur se met en veille est un simple outil. Un agent qui persiste (c’est-à-dire un agent capable de se réveiller à la demande, de poursuivre le travail après une interruption et de transférer l’état sans dépendre de votre environnement d’exécution local) commence à ressembler à une infrastructure – et cela modifie complètement le modèle d’évolutivité des agents.

Le SDK Agents s’appuie sur Durable Objects pour fournir à chaque agent une identité, un état persistant et la capacité de se réveiller à la réception d’un message. Il s’agit du modèle acteur : chaque agent est une entité adressable disposant de sa propre base de données SQLite. Il ne consomme aucune puissance de calcul lorsqu’il est en veille prolongée. Lorsqu’un événement se produit (une requête HTTP, un message WebSocket, une alerte programmée, un e-mail entrant), la plateforme réveille l’agent, charge son état et lui transmet l’événement. L’agent effectue son travail, puis se remet en veille.

Cette approche modifie les paramètres économiques de l’exécution d’agents à grande échelle. Au lieu de déployer « un agent coûteux par utilisateur expérimenté », vous pouvez créer « un agent par client », « un agent par tâche » ou « un agent par fil de discussion par e-mail ». Le coût marginal qu’entraîne la création d’un nouvel agent est pratiquement nul.

L’exécution d’un appel à un LLM demande 30 secondes. L’exécution d’une boucle d’agent à plusieurs tours peut durer beaucoup plus longtemps. À tout moment pendant cette période, l’environnement d’exécution peut être arrêté en raison d’un déploiement, d’un redémarrage de la plateforme ou du dépassement des limites des ressources. La connexion en amont vers le fournisseur de modèles est définitivement interrompue, l’état en mémoire est perdu et, pour les clients connectés, le flux s’arrête sans aucune explication.

runFiber() résout ce problème. Un « fiber » est un appel de fonction persistant : il est enregistré dans SQLite avant le début de l’exécution, peut être sauvegardé à tout moment via stash() et peut être restauré au redémarrage via onFiberRecovered.

import { Agent } from "agents";

export class ResearchAgent extends Agent {
  async startResearch(topic: string) {
    void this.runFiber("research", async (ctx) => {
      const findings = [];

      for (let i = 0; i < 10; i++) {
        const result = await this.callLLM(`Research step ${i}: ${topic}`);
        findings.push(result);

        // Checkpoint: if evicted, we resume from here
        ctx.stash({ findings, step: i, topic });

        this.broadcast({ type: "progress", step: i });
      }

      return { findings };
    });
  }

  async onFiberRecovered(ctx) {
    if (ctx.name === "research" && ctx.snapshot) {
      const { topic } = ctx.snapshot;
      await this.startResearch(topic);
    }
  }
}

Le SDK maintient automatiquement l’activité de l’agent pendant l’exécution du fiber, sans qu’aucune configuration particulière ne soit nécessaire. Pour les tâches mesurées en minutes, les fonctions keepAlive()/keepAliveWhile() empêchent l’éviction pendant son fonctionnement actif. Pour les opérations plus longues (pipelines CI, revues de conception, génération de vidéos), l’agent démarre l’exécution de la tâche, enregistre l’identifiant de la tâche, se met en veille prolongée, puis se réactive en cas de rappel.

Un agent unique ne devrait pas exécuter toutes les tâches lui-même. Les sous-agents sont des instances enfant Durable Objects colocalisées avec l’instance parent via Facets, disposant chacune de leur propre base de données SQLite et d’un contexte d’exécution isolé :

import { Agent } from "agents";

export class ResearchAgent extends Agent {
  async search(query: string) { /* ... */ }
}

export class ReviewAgent extends Agent {
  async analyze(query: string) { /* ... */ }
}

export class Orchestrator extends Agent {
  async handleTask(task: string) {
    const researcher = await this.subAgent(ResearchAgent, "research");
    const reviewer = await this.subAgent(ReviewAgent, "review");

    const [research, review] = await Promise.all([
      researcher.search(task),
      reviewer.analyze(task)
    ]);

    return this.synthesize(research, review);
  }
}

Les sous-agents sont isolés au niveau du stockage. Chacun dispose de sa propre base de données SQLite, et il n’y a aucun partage implicite de données entre eux. Cet isolement est imposé par l’environnement d’exécution, où la latence d’un appel RPC vers un sous-agent équivaut à un simple appel de fonction. TypeScript détecte les utilisations abusives lors de la compilation.

Le fonctionnement d’agents qui s’exécutent pendant plusieurs jours, voire plusieurs semaines nécessite plus qu’une liste linéaire standard de messages. L’API Session expérimentale modélise explicitement ce processus. Dans la classe de base Agent, les conversations sont stockées sous forme d’arborescences, chaque message disposant d’un parent_id. Cette configuration permet la création de branches (c’est-à-dire l’exploration d’une approche alternative sans perdre le chemin d’origine), la compaction non destructive (le résumé d’anciens messages, plutôt que leur suppression) et la recherche en texte intégral dans l’historique des conversations via FTS5.

import { Agent } from "agents";
import { Session, SessionManager } from "agents/experimental/memory/session";

export class MyAgent extends Agent {
  sessions = SessionManager.create(this);

  async onStart() {
    const session = this.sessions.create("main");
    const history = session.getHistory();
    const forked = this.sessions.fork(session.id, messageId, "alternative-approach");
  }
}

L’API Session est utilisable directement avec Agent et constitue la couche de stockage sur laquelle s’appuie la classe de base Think.

La syntaxe conventionnelle des appels d’outils est peu pratique. Le modèle appelle un outil, récupère le résultat par le biais de la fenêtre de contexte, appelle un autre outil, récupère ce résultat, et ainsi de suite. À mesure que la surface des outils s’accroît, cette approche devient à la fois coûteuse et peu pratique. Une centaine de fichiers correspond à une centaine d’allers-retours dans le modèle.

Toutefois, les modèles sont plus à même d’écrire du code permettant d’utiliser un système que de se livrer au jeu de l’exécution d’appels d’outils. C’est l’idée sur laquelle repose @cloudflare/codemode : au lieu d’exécuter des appels d’outils séquentiels, le LLM écrit un programme unique qui gère l’ensemble de la tâche.

// The LLM writes this. It runs in a sandboxed Dynamic Worker.
const files = await tools.find({ pattern: "**/*.ts" });
const results = [];
for (const file of files) {
  const content = await tools.read({ path: file });
  if (content.includes("TODO")) {
    results.push({ file, todos: content.match(/\/\/ TODO:.*/g) });
  }
}
return results;

Au lieu d’effectuer 100 allers-retours vers le modèle, il suffit d’exécuter un programme unique. Cela permet de réduire le nombre de jetons utilisés, d’accélérer l’exécution et d’obtenir de meilleurs résultats. Le serveur MCP de l’API Cloudflare le démontre à grande échelle. Nous n’exposons que deux outils (search() et execute()), qui consomment environ 1 000 jetons, contre environ 1,17 million de jetons pour l’approche équivalente naïve, reposant sur un outil par point de terminaison. Cela représente une réduction de 99,9 %.

Lorsque vous avez admis le postulat que les modèles doivent écrire du code pour le compte des utilisateurs, la question qui se pose est la suivante : où s’exécute ce code ? Pas finalement, pas après qu’une équipe produit en ait fait un élément de la feuille de route. À l’heure actuelle, pour cet utilisateur, sur ce système, avec des autorisations étroitement définies.

Dynamic Workers est cette sandbox. Un nouvel isolat V8 est lancé lors de l’exécution, en quelques millisecondes, avec quelques mégaoctets de mémoire seulement. Cette approche est environ 100 fois plus rapide et jusqu’à 100 fois plus économe en mémoire qu’un conteneur. Vous pouvez démarrer un nouvel isolat pour chaque requête, exécuter un fragment de code, puis le supprimer.

Le choix conceptuel déterminant est le modèle de capacité. Au lieu de partir d’une machine polyvalente et d’essayer de la contraindre, les instances Dynamic Workers commencent pratiquement sans aucune autorité ambiante (globalOutbound: null, aucun accès réseau) et le développeur accorde les capacités de manière explicite, ressource par ressource, par le biais de liaisons. La question n’est plus « Comment empêcher cet agent d’en faire trop ? » à « Que voulons-nous exactement qu’il soit capable de faire ? ».

Il s’agit de la question pertinente concernant l’infrastructure des agents.

Ce modèle de capacité engendre naturellement un éventail d’environnements de calcul, une échelle d’exécution que l’agent peut gravir à mesure que ses besoins évoluent :

Le niveau Tier 0 correspond à Workspace, un système de fichiers virtuel durable reposant sur SQLite et R2. Lecture, écriture, édition, recherche, grep, diff. Repose sur @cloudflare/shell.

Le niveau Tier 1 est une instance Workers dynamique : du code JavaScript généré par LLM, exécuté dans un isolat en sandbox sans accès au réseau. Repose sur @cloudflare/codemode.

Le niveau Tier 2 ajoute npm. @cloudflare/worker-bundler récupère les packages dans le registre, les regroupe avec esbuild, puis charge le résultat dans l’instance Dynamic Workers. L’agent écrit import { z } from "zod", et ça fonctionne – tout simplement.

Le niveau Tier 3 correspond à un navigateur headless via Cloudflare Browser Run. Navigation, clic, extraction, capture d’écran. Utile lorsque le service ne prend pas encore en charge les agents via MCP ou les API.

Le niveau Tier 4 est une sandbox Cloudflare configurée avec vos chaînes d’outils, vos référentiels et vos dépendances (git clone, npm test, cargo build), qui bénéficie d’une synchronisation bidirectionnelle avec Workspace.

Le principe de conception fondamental : l’agent doit être utile dès le niveau Tier 0, chaque niveau étant additif. L’utilisateur peut ajouter des fonctionnalités au fur et à mesure.

Toutes ces composantes primitives sont disponibles sous forme de packages autonomes. Dynamic Workers, @cloudflare/codemode, @cloudflare/worker-bundler et @cloudflare/shell (un système de fichiers durable avec des outils) sont tous utilisables directement avec la classe de base Agent. Vous pouvez les associer pour fournir à n’importe quel agent une instance Workspace, ainsi que la capacité d’exécuter du code et de résoudre des packages de l’environnement d’exécution sans adopter un cadre prescriptif.

Voici la pile complète pour développer des agents sur Cloudflare :

Chacun de ces éléments est un composant fondamental. Ensemble, ils forment quelque chose de nouveau : une plateforme sur laquelle chacun peut développer, déployer et exécuter des agents IA aussi performants que ceux qui s’exécutent actuellement sur votre machine locale. Toutefois, ces agents sont serverless, durables et intrinsèquement sûrs.

Maintenant que vous avez découvert les composantes primitives, voici ce qui se passe lorsque vous les connectez toutes.

Think est un cadre de travail prescriptif, qui gère l’intégralité du cycle de vie de la conversation : boucle agentique, persistance des messages, streaming, exécution d’outils, reprise de flux et extensions. Vous vous concentrez ainsi sur ce qui rend votre agent unique.

La sous-classe minimale se présente ainsi :

import { Think } from "@cloudflare/think";
import { createWorkersAI } from "workers-ai-provider";

export class MyAgent extends Think<Env> {
  getModel() {
    return createWorkersAI({ binding: this.env.AI })(
      "@cf/moonshotai/kimi-k2.5"
    );
  }
}

En pratique, c’est tout ce dont vous avez besoin pour disposer d’un agent de discussion fonctionnel avec streaming, persistance, interruption/annulation, traitement des erreurs, des flux avec reprise et un système de fichiers intégré dans l’espace de travail. Déployez avec npx wrangler deploy.

Think prend des décisions pour vous. Si vous avez besoin de davantage de contrôle, vous pouvez vous réserver celles qui importent pour vous :

En coulisses, Think exécute la boucle agentique complète à chaque tour : il assemble le contexte (instructions de base + descriptions d’outils + compétences + mémoire + historique de la conversation), appelle streamText, exécute les appels d’outil (avec troncature de la sortie afin d’éviter l’explosion du contexte), ajoute les résultats, puis répète la boucle jusqu’à ce que le modèle ait terminé ou que la limite d’étape soit atteinte. Tous les messages sont persistants après chaque tour.

Think met à votre disposition des hooks (c’est-à-dire des points d’ancrage) à chaque étape du tour de conversation, sans vous contraindre à gérer l’ensemble du pipeline :

beforeTurn()
  → streamText()
    → beforeToolCall()
    → afterToolCall()
  → onStepFinish()
→ onChatResponse()

Optez pour un modèle moins coûteux pour les tours de suivi, restreignez le choix d’outils que peut utiliser le modèle et transmettez le contexte côté client à chaque tour. Vous pouvez également enregistrer chaque appel d’outil dans le système d’analyse de données et déclencher automatiquement un tour de suivi supplémentaire, une fois l’exécution du modèle terminée – et tout cela, sans remplacer onChatMessage.

Think utilise l’API Session comme couche de stockage, mettant ainsi à votre disposition des messages structurés sous forme d’arborescence avec une gestion des branches intégrée.

Par ailleurs, Think ajoute de la mémoire persistante par le biais de blocs de contexte. Il s’agit de sections structurées de l’invite système que le modèle peut lire et mettre à jour au fil du temps, et qui persistent pendant toute la durée de la mise en veille prolongée. Le modèle voit « MEMORY (infos importantes, utiliser set_context pour mettre à jour) [42%, 462/1100 jetons] » et peut mémoriser proactivement des informations.

configureSession(session: Session) {
  return session
    .withContext("soul", {
      provider: { get: async () => "You are a helpful coding assistant." }
    })
    .withContext("memory", {
      description: "Important facts learned during conversation.",
      maxTokens: 2000
    })
    .withCachedPrompt();
}

Les sessions sont flexibles. Vous pouvez exécuter plusieurs conversations par agent et créer des branches afin d’explorer une autre approche, sans toutefois perdre le chemin original. 

À mesure que le contexte s’étoffe, Think gère les limites grâce à une compaction non destructive. Les messages les plus anciens sont résumés, et non supprimés, tandis que l’historique complet reste stocké dans SQLite.

Une fonction de recherche est également intégrée. Avec FTS5, vous pouvez interroger l’historique des conversations d’une session ou de l’ensemble des sessions. L’agent peut également effectuer des recherches dans son propre passé avec l’outil search_context.

Think intègre la totalité de la chaîne d’exécution dans le retour d’une fonction getTools() unique :

import { Think } from "@cloudflare/think";
import { createWorkspaceTools } from "@cloudflare/think/tools/workspace";
import { createExecuteTool } from "@cloudflare/think/tools/execute";
import { createBrowserTools } from "@cloudflare/think/tools/browser";
import { createSandboxTools } from "@cloudflare/think/tools/sandbox";
import { createExtensionTools } from "@cloudflare/think/tools/extensions";

export class MyAgent extends Think<Env> {
  extensionLoader = this.env.LOADER;

  getModel() {
    /* ... */
  }

  getTools() {
    return {
      execute: createExecuteTool({
        tools: createWorkspaceTools(this.workspace),
        loader: this.env.LOADER
      }),
      ...createBrowserTools(this.env.BROWSER),
      ...createSandboxTools(this.env.SANDBOX), // configured per-agent: toolchains, repos, snapshots
      ...createExtensionTools({ manager: this.extensionManager! }),
      ...this.extensionManager!.getTools()
    };
  }
}

Think va encore plus loin dans l’exécution du code. Un agent peut écrire ses propres extensions : des programmes TypeScript qui s’exécutent dans des instances Dynamic Workers et définissent les autorisations d’accès au réseau et d’exécution d’opérations dans Workspace.

{
  "name": "github",
  "description": "GitHub integration: PRs, issues, repos",
  "tools": ["create_pr", "list_issues", "review_pr"],
  "permissions": {
    "network": ["api.github.com"],
    "workspace": "read-write"
  }
}

Le service ExtensionManager de Think regroupe l’extension (éventuellement avec des dépendances npm, via @cloudflare/worker-bundler), charge celle-ci dans une instance Dynamic Workers, puis et enregistre les nouveaux outils. L’extension reste enregistrée dans le stockage de DO et survit à la mise en veille prolongée. La prochaine fois que l’utilisateur interroge les requêtes pull, l’agent disposera d’un outil github_create_pr qui n’existait pas encore 30 secondes plus tôt.

C’est ce genre de boucle d’amélioration qui permet aux agents de devenir véritablement plus utiles au fil du temps – pas grâce à des réglages précis ou à l’apprentissage par renforcement à partir de retours humains, mais par le biais du code. L’agent est capable d’écrire de nouvelles fonctionnalités pour lui-même, et cela, en TypeScript, dans un environnement en sandbox, vérifiable et révocable.

Think peut également fonctionner comme un sous-agent, appelé via l’instruction chat() par l’intermédiaire de RPC depuis un agent parent, avec la transmission des événements de streaming via une fonction de rappel :

const researcher = await this.subAgent(ResearchSession, "research");
const result = await researcher.chat(`Research this: ${task}`, streamRelay);

Chaque agent enfant isolé dispose d’une arborescence de conversation, d’une mémoire, d’outils et d’un modèle propres. L’agent parent n’a pas besoin de connaître les détails.

Le projet Think est expérimental. La surface de l’API est stable, mais l’API continuera d’évoluer au fil des jours et des semaines à venir. Nous l’utilisons déjà en interne pour créer notre propre infrastructure d’agents en arrière-plan, et nous la partageons précocement pour vous permettre de développer des solutions avec nous.

npm install @cloudflare/think agents ai @cloudflare/shell zod workers-ai-provider

// src/server.ts
import { Think } from "@cloudflare/think";
import { createWorkersAI } from "workers-ai-provider";
import { routeAgentRequest } from "agents";

export class MyAgent extends Think<Env> {
  getModel() {
    return createWorkersAI({ binding: this.env.AI })(
      "@cf/moonshotai/kimi-k2.5"
    );
  }
}

export default {
  async fetch(request: Request, env: Env) {
    return (
      (await routeAgentRequest(request, env)) ||
      new Response("Not found", { status: 404 })
    );
  }
} satisfies ExportedHandler<Env>;

// src/client.tsx
import { useAgent } from "agents/react";
import { useAgentChat } from "@cloudflare/ai-chat/react";

function Chat() {
  const agent = useAgent({ agent: "MyAgent" });
  const { messages, sendMessage, status } = useAgentChat({ agent });
  // Render your chat UI
}

Think utilise le même protocole WebSocket que @cloudflare/ai-chat ; ainsi, les composants d’IU existants fonctionnent immédiatement. Si vous avez développé une solution avec AIChatAgent, votre code client n’a pas besoin d’être modifié.

Nous distinguons trois vagues d’agents IA :

La première vague a été celle des chatbots. Ils étaient réactifs et fragiles, et s’exécutaient sans état. Chaque conversation partait de zéro, sans mémoire, sans outils et sans capacité d’agir. Les chatbots étaient utiles pour répondre aux questions d’utilisateurs, mais leur utilité se limitait à cette seule fonction.

La deuxième vague a été celle des agents de codage. Ces outils avec état sont capables d’utiliser des outils et sont dotés de capacités considérablement supérieures (Pi, Claude Code, OpenClaw et Codex, entre autres). Ces agents peuvent lire des bases de code, écrire du code, l’exécuter et réaliser des améliorations itératives. S’ils ont démontré qu’un LLM doté d’outils pertinents est une machine polyvalente, ils s’exécutent sur votre ordinateur portable, pour un utilisateur seulement, sans aucune garantie de durabilité.

Nous abordons maintenant dans la troisième vague : les agents en tant qu’infrastructure. Ils sont durables, distribués, structurellement sûrs et proposent une exécution serverless. Il s’agit d’agents qui s’exécutent sur Internet, survivent aux défaillances, n’entraînent aucun coût lorsqu’ils sont inactifs et assurent une sécurité reposant sur leur architecture, plutôt que sur leur comportement. Ces agents peuvent être créés et déployés par n’importe quel développeur pour un nombre illimité d’utilisateurs.

C’est l’approche que nous privilégions.

Des milliers d’agents de production reposent déjà sur le SDK Agents. Avec Project Think et les primitives qu’il introduit, nous ajoutons les pièces manquantes permettant de rendre ces agents considérablement plus performants : espaces de travail persistants, exécution de code en sandbox, tâches durables à longue durée d’exécution, sécurité structurelle, coordination de sous-agents et extensions auto-générées.

Project Think est disponible dès aujourd’hui dans une version préliminaire. Nous développons à vos côtés, et nous avons vraiment hâte de découvrir ce que vous (et votre agent de codage) allez créer avec cet outil.

^{Think fait partie du SDK Agents de Cloudflare, disponible sous @cloudflare/think. Les fonctionnalités décrites dans cet article sont disponibles en version préliminaire. Les API sont susceptibles d’être modifiées à mesure que nous intégrons les commentaires. Consultez la documentation et l’exemple pour vous lancer.}

Chacun de ces flux de travail présente le même problème sous-jacent : les agents doivent accéder à des ressources privées ; or, les outils qui permettent cet accès été conçus pour les humains, et non pour les logiciels autonomes. Les VPN nécessitent une connexion interactive. Les tunnels SSH nécessitent une configuration manuelle. L’exposition publique des services constitue un risque pour la sécurité. Cependant aucune de ces approches ne vous donne de visibilité sur ce que fait réellement l’agent une fois connecté.

Aujourd’hui, nous lançons Cloudflare Mesh conçu pour connecter vos réseaux privés entre eux et proposer un accès sécurisé à vos agents. Nous intégrons également Mesh à la Plateforme pour développeurs Cloudflare afin que Workers, Durable Objects et les agents développés avec le SDK Agents puissent atteindre directement votre infrastructure privée.

Si vous utilisez la suite SASE et Zero Trust de Cloudflare One, vous avez déjà accès à Mesh. Vous n’avez pas besoin d’un nouveau cadre technologique pour sécuriser les charges de travail des agents. Vous avez besoin d’une solution SASE conçue pour l’ère des agents, et c’est ce que propose Cloudflare One. Cloudflare Mesh est une nouvelle expérience avec une configuration plus simple qui exploite les accès directs (on-ramp) que vous connaissez déjà : WARP Connector (désormais appelé nœud Cloudflare Mesh) et WARP Client (désormais appelé Cloudflare One Client). Ensemble, ces fonctionnalités créent un réseau privé pour le trafic, qu'il provienne d'humains, de développeurs ou d'agents. Mesh est directement intégré à votre déploiement Cloudflare One existant. Vos politiques Gateway, règles d’accès et mesures de contrôle du niveau de sécurité des appareils existants s’appliquent automatiquement au trafic du maillage (Mesh).

Si vous êtes développeur et que vous souhaitez simplement mettre en place des réseaux privés pour vos agents, vos services et votre équipe, le service Mesh est un bon point de départ. Configurez la solution en quelques minutes, connectez vos réseaux et sécurisez votre trafic. Et, Mesh s’exécutant sur la plateforme Cloudflare One, vous pouvez évoluer vers des fonctionnalités plus avancées au fil du temps : réseau Gateway, politiques DNS et HTTP pour un contrôle précis du trafic, Access for Infrastructure pour la gestion des sessions SSH et RDP, isolement de navigateur pour un accès web sécurisé, DLP pour empêcher les données sensibles de quitter votre réseau, et CASB pour la sécurité SaaS. Vous n’aurez pas à planifier tout cela dès le premier jour. Simplement, lorsque vous en aurez besoin, il ne sera pas nécessaire de migrer.

En ce qui concerne la mise en réseau privée, il a toujours été question de connecter des clients à des ressources : SSH vers un serveur, interrogation d’une base de données, accès à une API interne. Ce qui a changé, c’est l’identité des clients. Il y a un an, les clients étaient vos développeurs et vos services. Aujourd’hui, il s’agit de plus en plus de vos agents.

Il ne s'agit plus d'une simple théorie. Observez l’écosystème : l’explosion des serveurs MCP (Model Context Protocol) donnant accès aux outils, des agents de codage qui doivent lire dans des référentiels et des bases de données privés, des assistants personnels fonctionnant sur du matériel domestique. Chacun de ces modèles suppose que l’agent peut accéder aux ressources dont il a besoin. Lorsque ces ressources sont isolées sur des réseaux privés, l’agent est bloqué.

Cette situation donne lieu à trois flux de travail difficiles à sécuriser aujourd’hui :

1. Accéder à un agent personnel depuis un appareil mobile. Vous exécutez OpenClaw sur un Mac mini chez vous. Vous pouvez y accéder depuis votre téléphone, votre ordinateur portable dans un café ou votre machine de travail. Toutefois, l’exposition de cette application à l’Internet public (même derrière un mot de passe) peut laisser certaines failles ouvertes. Votre agent dispose d’un accès au shell, d’un accès au système de fichiers et d’un accès réseau à votre réseau domestique. Un seul défaut de configuration et n'importe qui peut y avoir accès.

2. Autoriser un agent de codage à accéder à votre environnement de préproduction. Vous utilisez Claude Code, Cursor ou Codex sur votre ordinateur portable. Vous lui demandez de vérifier l’état du déploiement, d’interroger les analyses d’une base de données de préproduction ou de lire des informations issues d’un magasin d’objets interne. Cependant ces services résident dans un VPC cloud privé, par conséquent votre agent ne peut pas les atteindre sans les exposer à Internet ou tunnelliser l’intégralité de votre ordinateur portable vers le VPC.

3. Connecter des agents déployés à des services privés. Vous intégrez des agents à votre produit à l’aide du SDK Agents sur Cloudflare Workers. Ces agents doivent appeler des API internes, interroger des bases de données et accéder à des services qui ne se trouvent pas sur l’Internet public. Ils ont besoin d’un accès privé, mais avec des autorisations limitées, des pistes d’audit et aucune fuite d’identifiants.

Cloudflare Mesh est une connectivité réseau privée conviviale pour les développeurs. Un connecteur léger, binaire, connecte toutes les ressources : vos appareils personnels, vos serveurs distants et vos points de terminaison utilisateur. Il n’est pas nécessaire d’installer des outils distincts pour chaque modèle. Un connecteur sur votre réseau, et chaque modèle d’accès fonctionne.

Une fois connectés, les appareils de votre réseau privé peuvent communiquer entre eux par l’intermédiaire d’adresses IP privées. Le trafic est acheminé par le réseau mondial de Cloudflare, présent dans plus de 330 villes, ce qui améliore la fiabilité et le contrôle sur votre réseau.

Désormais, grâce à Mesh, une solution unique peut résoudre tous les scénarios d’agents que nous avons mentionnés ci-dessus :

• Avec Cloudflare One Client pour iOS sur votre téléphone, vous pouvez connecter en toute sécurité vos appareils mobiles à votre Mac mini local en exécutant OpenClaw via un réseau privé Mesh.

• Avec Cloudflare One Client pour macOS sur votre ordinateur portable, vous pouvez connecter votre ordinateur portable à votre réseau privé afin que vos agents de codage puissent atteindre les bases de données en préproduction ou les API et les interroger.

• Avec les nœuds Mesh sur vos serveurs Linux, vous pouvez connecter les VPC dans des clouds externes, et ainsi permettre aux agents d’accéder aux ressources et aux MCP des réseaux privés externes.

Étant donné que Mesh est optimisé par Cloudflare One Client, chaque connexion hérite des contrôles de sécurité de la plateforme Cloudflare One. Les politiques Gateway s’appliquent au trafic du maillage (Mesh). Les contrôles de niveau de sécurité des appareils valident les appareils connectés. Le filtrage DNS bloque les recherches suspectes. Vous bénéficiez de cette fonctionnalité sans configuration supplémentaire : les mêmes politiques qui protègent votre trafic humain protègent également le trafic de vos agents.

Avec l’introduction de Mesh, vous pourriez vous poser la question suivante : quand devrais-je utiliser Mesh au lieu de Tunnel ? Les deux connectent des réseaux externes de manière privée à Cloudflare, mais ils servent des objectifs différents. Cloudflare Tunnel constitue la solution idéale pour le trafic unidirectionnel, lorsque Cloudflare met en proxy le trafic provenant de la périphérie vers des services privés spécifiques (comme un serveur web ou une base de données). 

Cloudflare Mesh, quant à lui, fournit un réseau entièrement bidirectionnel et de type « plusieurs-à-plusieurs ». Chaque appareil et chaque nœud de votre maillage peuvent accéder les uns aux autres via leur adresse IP privée. Une application ou un agent en cours d’exécution sur votre réseau peut identifier et accéder à n’importe quelle autre ressource située sur le Mesh, sans que chaque ressource ait besoin de son propre Tunnel. 

Cloudflare Mesh vous offre les avantages d’un réseau maillé (résilience, évolutivité élevée, faible latence et performances élevées), mais, dans la mesure où il achemine l’ensemble des ressources via Cloudflare, il résout un problème majeur des réseaux maillés : la traversée NAT.

La majeure partie d’Internet se trouve derrière une NAT (Network Address Translation). Ce mécanisme permet à l’intégralité d’un réseau local d’appareils de partager une adresse IP publique unique en mettant en correspondance le trafic entre les en-têtes publics et les adresses internes privées. Lorsque deux appareils sont derrière la NAT, les connexions directes peuvent échouer et le trafic doit se replier sur les serveurs relais. Si votre infrastructure de relais ne comporte que des points de présence limités, une fraction importante de votre trafic passe par ces relais, ce qui ajoute de la latence et réduit la fiabilité. Et s’il est toujours possible d’héberger vos propres serveurs relais pour compenser, l’opération implique de se charger de la gestion d’une infrastructure supplémentaire simplement pour connecter votre réseau existant.

Cloudflare Mesh fonctionne différemment. Tout le trafic Mesh est acheminé par le réseau mondial de Cloudflare, la même infrastructure qui sert le trafic pour certains des plus grands sites web d’Internet. Pour le trafic transrégional ou multicloud, cette approche devance toujours le routage Internet public. Il n’existe pas de chemin de secours dégradé, car c’est la périphérie de Cloudflare qui est le chemin.

Le routage par Cloudflare signifie également que chaque paquet traverse la pile de sécurité de Cloudflare. C’est l’avantage fondamental qu'il y a à développer Mesh sur la plateforme Cloudflare One : la sécurité n’est pas un produit séparé ajouté a posteriori. En mettant à profit ce même réseau d’infrastructure mondial, nous pouvons dès le premier jour proposer ces piliers fondamentaux à chaque équipe :

50 nœuds et 50 utilisateurs gratuits. Toute votre équipe et votre environnement de préproduction se trouvent sur un réseau privé inclus dans chaque compte Cloudflare. 

Routage périphérique mondial. Plus de 330 villes, routage optimisé dans l'infrastructure. Pas de serveurs relais avec points de présence limités. Pas de chemins de secours dégradés.

Des mesures de contrôle de la sécurité dès le premier jour. Mesh s’exécute sur Cloudflare One. Les politiques Gateway, le filtrage DNS, DLP, l’inspection du trafic et les contrôles du niveau de sécurité des appareils sont tous disponibles sur la même plateforme. Commencez par une connectivité privée simple. Activez les politiques Gateway lorsque vous avez besoin de filtrer le trafic. Activez Access for Infrastructure lorsque vous avez besoin de contrôles au niveau de la session pour SSH et RDP. Utilisez la DLP pour empêcher les données sensibles de quitter votre réseau. Chaque fonctionnalité est accessible par un simple bouton.

Disponibilité élevée. Créez un nœud Mesh avec haute disponibilité et déployez plusieurs connecteurs en utilisant le même jeton en mode actif-passif. Ils annoncent les mêmes itinéraires d’adresses IP, donc en cas de défaillance de l’un d’entre eux, le trafic bascule automatiquement.

Mesh connecte vos agents et vos ressources via des clouds externes, mais vous devez également pouvoir vous connecter depuis vos agents développés sur Workers avec le SDK Agents. Pour ce faire, nous avons étendu Workers VPC afin que l’intégralité de votre réseau maillé soit accessible à Workers et Durable Objects.

Cela signifie que vous pouvez vous connecter à votre réseau Cloudflare Mesh depuis Workers, ce qui rend l’ensemble du réseau accessible à partir d’un seul appel fetch() d’une liaison. Cela complète la prise en charge existante de Workers VPC pour Cloudflare Tunnel, et propose un choix supplémentaire pour la manière dont vous souhaitez sécuriser vos réseaux. Vous pouvez désormais spécifier des réseaux entiers auxquels vous souhaitez vous connecter dans votre fichier wrangler.jsonc. Pour établir une liaison vers votre réseau Mesh, utilisez le mot-clé réservé cf1:network qui assure une liaison au réseau Mesh de votre compte :

"vpc_networks": [
  { "binding": "MESH", "network_id": "cf1:network", "remote": true },
  { "binding": "AWS_VPC", "tunnel_id": "350fd307-...", "remote": true }
]

Vous pouvez ensuite l’utiliser au sein de votre Worker ou du code de votre agent :

export default {
  async fetch(request: Request, env: Env, ctx: ExecutionContext) {
    // Reach any internal host on your Mesh, no pre-registration required
    const apiResponse = await env.MESH.fetch("http://10.0.1.50/api/data");

    // Internal hostname resolved via tunnel's private DNS resolver
    const dbResponse = await env.AWS_VPC.fetch("http://internal-db.corp.local:5432");

    return new Response(await apiResponse.text());
  },
};

En connectant la plateforme Developer à vos réseaux Mesh, vous pouvez créer des instances Workers avec accès sécurisé à vos bases de données privées, ainsi qu’à vos API internes et MCP, ce qui vous permet de concevoir des agents multicloud et des MCP fournissant des capacités d’agent à votre application. Mais cela ouvre également la voie à un monde dans lequel les agents peuvent observer de manière autonome l’intégralité de votre pile de bout en bout, comparer les journaux et suggérer des optimisations en temps réel.

Ensemble, Cloudflare Mesh, Workers VPC et le SDK Agents fournissent à vos agents un réseau privé unifié couvrant à la fois Cloudflare et vos clouds externes. Nous avons fusionné la connectivité et la puissance de calcul afin que vos agents puissent accéder en toute sécurité aux ressources dont ils ont besoin, quel que soit l'endroit où ils se trouvent dans le monde.

Les nœuds de maillage sont vos serveurs, vos machines virtuelles et vos conteneurs. Ils exécutent une version headless de Cloudflare One Client et obtiennent une adresse IP Mesh. Les services communiquent avec des services via des adresses IP privées, dans les deux sens, acheminés via la périphérie de Cloudflare. 

Les appareils sont vos ordinateurs portables et vos téléphones. Ils exécutent le Cloudflare One Client et accèdent directement aux nœuds Mesh : SSH, requêtes de base de données, appels d’API, le tout via des adresses IP privées. Vos agents de codage locaux utilisent cette connexion pour accéder aux ressources privées. 

Les agents sur Workers accèdent aux services via des liaisons réseau VPC de Workers. Ils bénéficient d’un accès limité aux réseaux entiers, assisté par MCP. Le réseau contrôle ce que l’agent peut atteindre. Le serveur MCP régule ce que l’agent peut faire. 

La version actuelle de Mesh établit les fondations d’une connectivité sécurisée et unifiée. Cependant, à mesure que les flux de travail agentiques gagnent en complexité, nous travaillons à aller au-delà de la simple connectivité vers un réseau plus intuitif à gérer et capable de savoir plus en détail qui, ou ce qui, s’adresse à vos services. Voici ce que nous développons pour le reste de l’année.

Nous étendons le routage des noms d’hôtes de Cloudflare Tunnel à Mesh cet été. Vos nœuds Mesh pourront ainsi attirer le trafic de noms d’hôtes privés, comme wiki.local ou api.staging.internal, sans que vous ayez à gérer de listes d’adresses IP ni à vous soucier de la résolution de ces noms d’hôtes à la périphérie de Cloudflare. Acheminez le trafic vers les services par nom, et non par adresse IP. Si votre infrastructure utilise des adresses IP dynamiques, des groupes à évolution automatique ou des conteneurs éphémères, vous êtes débarrassé d'une catégorie entière de problèmes de routage.

Aujourd’hui, vous accédez aux nœuds Mesh par leur adresse IP Mesh : ssh 100.64.0.5. Cela fonctionne, mais ce n’est pas ainsi que vous concevez votre infrastructure. Vous pensez en noms : postgres-staging, api-prod, nikitas-openclaw.

Plus tard dans l'année, nous allons développer Mesh DNS afin que chaque nœud et appareil rejoignant votre maillage obtienne automatiquement un nom d’hôte interne routable. Pas de configuration DNS ni d’enregistrement manuel. Ajoutez un nœud nommé postgres-staging, et postgres-staging.mesh est traduit en adresse IP Mesh correcte depuis n’importe quel appareil présent sur votre maillage.

En complément du routage par nom d’hôte, vous pourrez utiliser la commande ssh postgres-staging.mesh ou curl http://api-prod.mesh:3000/health sans jamais connaître ni gérer d’adresse IP.

Aujourd’hui, les nœuds Mesh s’authentifient auprès de la périphérie de Cloudflare, mais ils partagent une identité au niveau de la couche réseau. Les appareils s’authentifient avec l’identité de l’utilisateur via le Cloudflare One Client, mais les nœuds ne disposent pas encore d’identités distinctes et routables que les politiques de Gateway peuvent différencier.

Nous voulons y remédier. L’objectif est de parvenir à un routage sensible à l’identité pour Mesh, dans lequel chaque nœud, chaque appareil et enfin chaque agent reçoit une identité distincte que les politiques peuvent évaluer. Au lieu d’écrire des règles basées sur des plages d’adresses IP, vous écrivez des règles basées sur qui ou ce qui se connecte.

En ce qui concerne les agents, c’est ce qui importe le plus. Aujourd’hui, lorsqu’un agent exécuté sur Workers appelle un outil via une liaison VPC, le service cible voit un Worker effectuer une requête. Il ne sait pas quel agent appelle, qui l’a autorisé, ni le champ d'action qui lui a été accordé. Du côté de Mesh, lorsqu’un agent de codage local présent sur votre ordinateur portable accède à un service de préproduction, Gateway voit l’identité de votre appareil, mais pas celle de l’agent.

Nous travaillons à la mise en place d’un modèle dans lequel les agents seront caractérisés par leur propre identité sur le réseau :

• Donneur d'ordre/commanditaire : l’humain qui a autorisé l’action (Nikita de l’équipe chargée de la plateforme)

• Agent : le système IA qui exécute l'action (l’assistant de déploiement, session #abc123)

• Champ d’application : ce que l’agent est autorisé à faire (lire les déploiements, déclencher des restaurations, rien d’autre)

Ce modèle permettrait ainsi de rédiger des politiques telles que : les lectures issues des agents de Nikita sont autorisées, mais les écritures nécessitent directement Nikita. Le trafic des agents peut être filtré indépendamment du trafic humain. L’accès au réseau d’un agent peut être révoqué sans toucher à ceux de Nikita.

L’infrastructure nécessaire à cela est en place. Les nœuds Mesh assurent le provisionnement avec des jetons par nœud, les appareils s’authentifient avec l’identité de chaque utilisateur et les liaisons VPC Workers définissent l’accès par service. Il ne reste plus désormais qu'à rendre ces identités visibles à la couche de politique, afin que Gateway puisse prendre des décisions de routage et d’accès en fonction de ces identités. Nous y travaillons.

Aujourd’hui, les nœuds Mesh fonctionnent sur des machines virtuelles et des serveurs Linux dédiés. Cependant, les infrastructures modernes fonctionnent de plus en plus dans des conteneurs : pods Kubernetes, piles Docker Compose, instances d’exécution de code CI/CD éphémères. Nous sommes en train de créer une image Docker Mesh qui vous permettra d’ajouter un nœud Mesh à n’importe quel environnement conteneurisé.

Cela signifie que vous serez en mesure d’inclure un kit d’extension Mesh dans votre pile Docker Compose et de prévoir un accès au réseau privé pour chaque service de cette pile. Un microservice exécuté dans un conteneur de votre cluster de préproduction pourrait accéder à une base de données de votre VPC de production via Mesh, sans qu’aucun des deux services n’ait besoin d’un point de terminaison public.

Cette possibilité est également utile pour les pipelines CI/CD qui peuvent accéder à l’infrastructure privée pendant les générations et les tests : votre exécuteur GitHub Actions extrait l’image du conteneur Mesh, accède à votre réseau, exécute des tests d’intégration dans votre environnement de préproduction, puis se déconnecte. Le tout sans identifiants VPN à gérer ni tunnels persistants à entretenir : le nœud disparaît au départ du conteneur.

Nous estimons que l’image Mesh Docker sera disponible plus tard dans l’année.

Tandis que nous continuons à faire évoluer ces fonctionnalités de gestion de l’identité et du routage, les fondations d’une connectivité réseau sécurisée et unifiée sont disponibles dès aujourd’hui. Vous pouvez commencer à relier vos clouds et à sécuriser vos agents en quelques minutes seulement.

Démarrez Cloudflare Mesh : accédez à Networking > Mesh dans le tableau de bord Cloudflare. Gratuit jusqu’à 50 nœuds et 50 utilisateurs.

Développez des agents avec le SDK Agents et le VPC Workers : installez le SDK Agents (`npm i agents`), suivez le guide de démarrage rapide Workers VPC et développez un serveur MCP distant avec un accès backend privé.

Vous êtes déjà sur Cloudflare One ? La solution Mesh s’intègre à votre configuration existante. Vos politiques Gateway, vos mesures de contrôle du niveau de sécurité des appareils et vos règles d’accès s’appliquent automatiquement au trafic Mesh. Consultez la documentation de Mesh pour ajouter votre premier nœud.

Les Dynamic Workers peuvent servir de nombreuses utilisations. Dans l’annonce initiale, nous nous sommes concentrés sur la manière de les utiliser pour exécuter du code généré par agent IA au lieu d'appeler des outils. Dans ce scénario d’utilisation, un agent d’IA effectue des actions à la demande d’un utilisateur en écrivant quelques lignes de code et en les exécutant. Le code est à usage unique, destiné à exécuter une tâche une fois seulement, puis il est éliminé immédiatement après son exécution.

Mais comment faire si vous voulez qu’une IA génère du code plus persistant ? Et si vous souhaitez que votre IA développe une petite application dotée d’une interface utilisateur personnalisée, avec laquelle l’utilisateur peut interagir ? Et si vous souhaitez un état durable pour cette application ? Par ailleurs, vous souhaitez évidemment toujours l’exécuter dans une sandbox sécurisée.

Vous avez la possibilité d’utiliser des Dynamic Workers, et de vous contenter de fournir au Worker une API RPC qui lui donne accès au stockage. À l’aide de liaisons, vous pouvez donner au Dynamic Worker une API qui pointe vers votre base de données SQL distante (peut-être étayée par Cloudflare D1, ou une base de données Postgres à laquelle vous accédez via Hyperdrive, c’est à vous de choisir).

Cependant, Workers dispose également d’un type de stockage unique et extrêmement rapide qui peut être parfaitement adapté à ce cas d’utilisation : les Durable Objects. Un Durable Object est une forme particulière de Worker désignée par un nom unique, avec une seule instance dans le monde entier pour chaque nom. Cette instance associée à une base de données SQLite qui réside sur le disque local de la machine sur laquelle s’exécute le Durable Object. L’accès au stockage devient ainsi ridiculement rapide : il y a en pratique une latence nulle.

Ensuite, ce que vous souhaitez vraiment, c’est peut-être que votre IA écrive du code pour un Durable Object, que vous voudrez exécuter dans un Dynamic Worker.

Voilà un problème étrange. Normalement, pour utiliser la solution Durable Objects, vous devez :

1. Écrire une classe pour étendre DurableObject.

2. L'exporter depuis le module principal de votre Worker.

3. Indiquer dans votre configuration Wrangler que le stockage doit être provisionné pour cette classe. Cette opération crée un espace de noms Durable Object qui pointe vers votre classe pour le traitement des requêtes entrantes.

4. Déclarer une liaison d’espace de noms Durable Object pointant vers votre espace de noms (ou utiliser ctx.exports), et l'utiliser pour effectuer des requêtes vers votre instance Durable Object.

Cela ne s’étend pas naturellement aux Dynamic Workers. Il se pose d'abord un problème évident : le code est dynamique. Vous l’exécutez sans faire appel du tout à l’API Cloudflare. Cependant, le stockage Durable Objects doit être provisionné par le biais de l’API, et l’espace de noms doit pointer vers une classe de mise en oeuvre. Il ne peut pas pointer vers votre Dynamic Worker.

Mais il existe un problème plus profond : même si vous pouviez, d’une manière ou d’une autre, configurer un espace de noms Durable Object de façon qu’il pointe directement vers un Dynamic Worker, le souhaiteriez-vous ? Souhaitez-vous que votre agent (ou votre utilisateur) puisse créer un espace de noms complet contenant des Durable Objects ? Qu'il utilise un stockage illimité et réparti dans le monde entier ?

Probablement non. Vous souhaitez probablement garder un certain contrôle. Vous souhaitez certainement limiter (ou, au moins, suivre) le nombre d’objets qu’il crée. Vous souhaitez peut-être le limiter à un seul objet (probablement suffisant pour les applications personnelles codées en vibe coding). Vous pouvez ajouter la journalisation et d’autres fonctionnalités d’observabilité. Mesures. Facturation. Etc.

Pour effectuer tout cela, ce que vous souhaitez vraiment, c’est que les requêtes adressées à ces Durable Objects soient transmises à votre code en premier, où vous pouvez ensuite effectuer toute la « logistique », avant de transmettre la requête au code de l’agent. Vous souhaitez écrire un superviseur qui s’exécute dans le cadre de chaque Durable Object.

Nous lançons aujourd’hui, en bêta ouverte, une fonctionnalité qui résout ce problème.

Les facettes Durable Object vous permettent de charger et d’instancier une classe Durable Object dynamiquement, tout en lui fournissant une base de données SQLite à utiliser pour le stockage. Avec les facettes :

• Vous commencez par créer un espace de noms Durable Objects normal, pointant vers une classe que vous écrivez.

• Dans cette classe, vous chargez le code de l’agent en tant que Dynamic Worker et vous l’appelez.

• Le code de Dynamic Worker peut mettre directement en oeuvre une classe Durable Object. C’est-à-dire qu’il exporte littéralement une classe comportant l'instruction extends DurableObject.

• Vous instanciez cette classe en tant que « facette » de votre propre Durable Object.

• La facette obtient sa propre base de données SQLite, qu’elle peut utiliser via les API normales de stockage Durable Objects. Cette base de données se distingue de la base de données du superviseur, mais les deux sont stockées ensemble dans le même Durable Object global.

Vous trouverez ci-dessous une mise en œuvre simple et complète d’une plateforme d’applications permettant de charger et d’exécuter dynamiquement une classe Durable Objects :

import { DurableObject } from "cloudflare:workers";

// For the purpose of this example, we'll use this static
// application code, but in the real world this might be generated
// by AI (or even, perhaps, a human user).
const AGENT_CODE = `
  import { DurableObject } from "cloudflare:workers";

  // Simple app that remembers how many times it has been invoked
  // and returns it.
  export class App extends DurableObject {
    fetch(request) {
      // We use storage.kv here for simplicity, but storage.sql is
      // also available. Both are backed by SQLite.
      let counter = this.ctx.storage.kv.get("counter") || 0;
      ++counter;
      this.ctx.storage.kv.put("counter", counter);

      return new Response("You've made " + counter + " requests.\\n");
    }
  }
`;

// AppRunner is a Durable Object you write that is responsible for
// dynamically loading applications and delivering requests to them.
// Each instance of AppRunner contains a different app.
export class AppRunner extends DurableObject {
  async fetch(request) {
    // We've received an HTTP request, which we want to forward into
    // the app.

    // The app itself runs as a child facet named "app". One Durable
    // Object can have any number of facets (subject to storage limits)
    // with different names, but in this case we have only one. Call
    // this.ctx.facets.get() to get a stub pointing to it.
    let facet = this.ctx.facets.get("app", async () => {
      // If this callback is called, it means the facet hasn't
      // started yet (or has hibernated). In this callback, we can
      // tell the system what code we want it to load.

      // Load the Dynamic Worker.
      let worker = this.#loadDynamicWorker();

      // Get the exported class we're interested in.
      let appClass = worker.getDurableObjectClass("App");

      return { class: appClass };
    });

    // Forward request to the facet.
    // (Alternatively, you could call RPC methods here.)
    return await facet.fetch(request);
  }

  // RPC method that a client can call to set the dynamic code
  // for this app.
  setCode(code) {
    // Store the code in the AppRunner's SQLite storage.
    // Each unique code must have a unique ID to pass to the
    // Dynamic Worker Loader API, so we generate one randomly.
    this.ctx.storage.kv.put("codeId", crypto.randomUUID());
    this.ctx.storage.kv.put("code", code);
  }

  #loadDynamicWorker() {
    // Use the Dynamic Worker Loader API like normal. Use get()
    // rather than load() since we may load the same Worker many
    // times.
    let codeId = this.ctx.storage.kv.get("codeId");
    return this.env.LOADER.get(codeId, async () => {
      // This Worker hasn't been loaded yet. Load its code from
      // our own storage.
      let code = this.ctx.storage.kv.get("code");

      return {
        compatibilityDate: "2026-04-01",
        mainModule: "worker.js",
        modules: { "worker.js": code },
        globalOutbound: null,  // block network access
      }
    });
  }
}

// This is a simple Workers HTTP handler that uses AppRunner.
export default {
  async fetch(req, env, ctx) {
    // Get the instance of AppRunner named "my-app".
    // (Each name has exactly one Durable Object instance in the
    // world.)
    let obj = ctx.exports.AppRunner.getByName("my-app");

    // Initialize it with code. (In a real use case, you'd only
    // want to call this once, not on every request.)
    await obj.setCode(AGENT_CODE);

    // Forward the request to it.
    return await obj.fetch(req);
  }
}

Dans cet exemple :

• AppRunner est un Durable Object « normal » écrit par le développeur de la plateforme (vous).

• Chaque instance de AppRunner gère une application. Elle stocke le code de l’application et le charge à la demande.

• L’application elle-même met en oeuvre et exporte une classe Durable Object, dont la plateforme s’attend à ce qu'elle soit nommée App.

• AppRunner charge le code de l’application à l’aide de Dynamic Workers, puis exécute le code en tant que facette Durable Object.

• Chaque instance de AppRunner est un Durable Object composé de deux bases de données SQLite : l’une appartenant au parent (AppRunner lui-même) et l’autre appartenant à la facette (App). Ces bases de données sont isolées : l’application ne peut pas lire la base de données de AppRunner, seulement la sienne.

Pour exécuter l’exemple, copiez le code ci-dessus dans un fichier worker.js, associez-le au fichier wrangler.jsonc suivant, et exécutez-le en local avec npx wrangler dev.

// wrangler.jsonc for the above sample worker.
{
  "compatibility_date": "2026-04-01",
  "main": "worker.js",
  "migrations": [
    {
      "tag": "v1",
      "new_sqlite_classes": [
        "AppRunner"
      ]
    }
  ],
  "worker_loaders": [
    {
      "binding": "LOADER",
    },
  ],
}

Les facettes sont une fonctionnalité des Dynamic Workers, disponible immédiatement en version bêta pour les utilisateurs de l’offre payante Workers.

Consultez la documentation pour en savoir plus sur les Dynamic Workers et les Facettes.

Si un agent agit comme un développeur, cela implique de cloner des référentiels, de créer du code dans de nombreux langages et d’exécuter des serveurs de développement, etc. Pour effectuer ces tâches de manière efficace, ils auront souvent besoin d’un ordinateur complet (et si ce n’est pas le cas, ils peuvent se tourner vers quelque chose de léger!).

De nombreux développeurs assemblent des solutions hétéroclites en utilisant des machines virtuelles ou des solutions de conteneurs existantes, mais ils sont confrontés à de nombreux problèmes difficiles à résoudre :

• Intermittence - Chaque session nécessitant sa propre sandbox, vous devez souvent faire tourner rapidement de nombreuses sandboxes, mais vous ne souhaitez pas payer de calcul inactif en mode veille.

• Restauration rapide de l’état – Chaque session doit démarrer et redémarrer rapidement, en revenant à son état précédent.

• Sécurité - Les agents doivent accéder aux services en toute sécurité, mais ils ne sont pas fiables pour ce qui est des informations d’identification.

• Contrôle - Le contrôle du cycle de vie de la sandbox, l’exécution de commandes, le traitement des fichiers, etc., doivent être simples.

• Ergonomie - Vous devez proposer aux humains et aux agents une interface simple pour effectuer des opérations courantes.

Nous avons passé du temps à résoudre ces problèmes pour que vous n’ayez pas à le faire. Depuis notre lancement initial, nous avons fait des Sandboxes un endroit encore plus propice à l’exécution d’agents à grande échelle. Nous avons collaboré avec nos partenaires initiaux, tels que Figma, qui exécute des agents dans des conteneurs avec Figma Make :

« Figma Make est conçue pour aider les développeurs et les créateurs de tous horizons à concrétiser l’idée en production, et ce, plus rapidement. Pour atteindre cet objectif, nous avions besoin d’une solution d’infrastructure capable de fournir des sandboxes fiables et hautement évolutives, dans lesquelles nous pourrions exécuter du code non fiable, créé par l’agent et l’utilisateur. Cloudflare Containers est la solution. »

- Alex Mullans, IA et plateformes pour développeurs chez Figma

Nous voulons proposer Sandboxes à encore plus de grandes organisations, c’est pourquoi aujourd’hui nous sommes heureux d’annoncer que Sandboxes et les conteneurs Cloudflare sont tous deux proposés en disponibilité générale.

Examinons certaines des récentes modifications apportées à Sandboxes :

• L’injection d’identifiants sécurisés vous permet de passer des appels authentifiés sans que l’agent ne dispose d’un accès aux identifiants  

• La prise en charge du PTY vous offre, à vous et à votre agent, un véritable terminal

• Les interpréteurs de code persistants donnent à votre agent un endroit où exécuter les fonctions Python, JavaScript et TypeScript avec état, prêts à l’emploi

• Les processus en arrière-plan et les URL de prévisualisation en direct proposent un moyen simple d’interagir avec les serveurs de développement et de vérifier les modifications en cours

• La surveillance du système de fichiers améliore la vitesse d’itération à mesure que les agents effectuent des modifications

• Les instantanés vous permettent de récupérer rapidement la session de codage d’un agent

• Des limites plus élevées et la tarification CPU active vous permettent de déployer une flotte d’agents à grande échelle sans payer pour les cycles processeur inutilisés

Avant d’aborder les récentes modifications, examinons rapidement les principes de base.

Un Cloudflare Sandbox est un environnement persistant et isolé, alimenté par Cloudflare Containers. Vous demandez une sandbox par son nom. Si elle est en cours d’exécution, vous l’obtenez. Si ce n’est pas le cas, elle démarre. Lorsqu’elle est inactive, elle se met automatiquement en pause et se réveille lorsqu’elle reçoit une requête. Il est facile d’interagir de manière programmatique avec la sandbox à l’aide de méthodes telles que exec, gitClone, writeFile et plus encore.

import { getSandbox } from "@cloudflare/sandbox";
export { Sandbox } from "@cloudflare/sandbox";

export default {
  async fetch(request: Request, env: Env) {
    // Ask for a sandbox by name. It starts on demand.
    const sandbox = getSandbox(env.Sandbox, "agent-session-47");

    // Clone a repository into it.
    await sandbox.gitCheckout("https://github.com/org/repo", {
      targetDir: "/workspace",
      depth: 1,
    });

    // Run the test suite. Stream output back in real time.
    return sandbox.exec("npm", ["test"], { stream: true });
  },
};

Tant que vous fournissez le même ID, les requêtes suivantes peuvent être acheminées vers cette même sandbox depuis n’importe où dans le monde.

L’authentification constitue l’un des problèmes les plus difficiles pour les charges de travail des agents. Vous avez souvent besoin d’agents pour accéder à des services privés, mais vous ne pouvez pas leur faire entièrement confiance en ce qui concerne les informations d’identification brutes. 

Les sandbox résolvent ce problème en injectant des informations d’identification au niveau de la couche réseau à l’aide d’un proxy de sortie programmable. Ainsi, les agents de sandbox n’ont jamais accès aux informations d’identification et vous pouvez personnaliser entièrement la logique d’authentification comme vous le souhaitez :

class OpenCodeInABox extends Sandbox {
  static outboundByHost = {
    "my-internal-vcs.dev": (request, env, ctx) => {
      const headersWithAuth = new Headers(request.headers);
      headersWithAuth.set("x-auth-token", env.SECRET);
      return fetch(request, { headers: headersWithAuth });
    }
  }
}

Pour une analyse approfondie du fonctionnement de cette solution (y compris l’injection d’identifiants tenant compte de l’identité, la modification dynamique des règles et l’intégration avec les liaisons Workers), lisez notre récent article de blog sur l’authentification Sandbox.

Les premiers systèmes d’agent modélisaient souvent l’accès au shell comme une boucle requête-réponse : exécuter une commande, attendre le résultat, renvoyer la transcription dans l’invite, puis répéter. Cela fonctionne, mais ce n’est pas la manière dont les développeurs utilisent réellement un terminal. 

Les humains exécutent quelque chose, observent le flux de sortie, l’interrompent, se reconnectent plus tard et continuent. Les agents bénéficient de cette même boucle de rétroaction.

En février, nous avons lancé la prise en charge de PTY. Une session pseudo-terminale dans une sandbox, mise en proxy via WebSocket, compatible avec xterm.js.

Il suffit d’appeler sandbox.terminal pour servir le back-end :

// Worker: upgrade a WebSocket connection into a live terminal session
export default {
  async fetch(request: Request, env: Env) {
    const url = new URL(request.url);
    if (url.pathname === "/terminal") {
      const sandbox = getSandbox(env.Sandbox, "my-session");
      return sandbox.terminal(request, { cols: 80, rows: 24 });
    }
    return new Response("Not found", { status: 404 });
  },
};

Puis d'utiliser add-on xterm pour l’appeler depuis le client :

// Browser: connect xterm.js to the sandbox shell
import { Terminal } from "xterm";
import { SandboxAddon } from "@cloudflare/sandbox/xterm";

const term = new Terminal();
const addon = new SandboxAddon({
  getWebSocketUrl: ({ origin }) => `${origin}/terminal`,
});

term.loadAddon(addon);
term.open(document.getElementById("terminal-container")!);
addon.connect({ sandboxId: "my-session" });

Ceci permet aux agents et aux développeurs d’utiliser un PTY complet pour déboguer ces sessions en direct.

Chaque session de terminal dispose de son propre shell isolé, de son propre répertoire de travail et de son propre environnement. Ouvrez autant d’instances que vous le souhaitez, comme vous le feriez sur votre propre machine. La sortie est mise en mémoire tampon côté serveur, de sorte que la reconnexion permet de reproduire ce que vous avez manqué.

Pour l’analyse des données, la création de scripts et les flux de travail exploratoires, nous publions également une abstraction de plus haut niveau : un contexte d’exécution de code persistant.

Le mot clé est « persistant ». De nombreuses implémentations d’interpréteurs de code exécutent chaque extrait de code de manière isolée, de sorte que l’état disparaît entre les appels. Vous ne pouvez pas définir une variable lors d'une étape et la lire à la suivante.

Les sandboxes vous permettent de créer des « contextes » présentant un état persistant. Les variables et les importations sont persistantes au sein des appels, de la même manière qu’elles le seraient dans un notebook Jupyter :

// Create a Python context. State persists for its lifetime.
const ctx = await sandbox.createCodeContext({ language: "python" });

// First execution: load data
await sandbox.runCode(`
  import pandas as pd
  df = pd.read_csv('/workspace/sales.csv')
  df['margin'] = (df['revenue'] - df['cost']) / df['revenue']
`, { context: ctx });

// Second execution: df is still there
const result = await sandbox.runCode(`
  df.groupby('region')['margin'].mean().sort_values(ascending=False)
`, { context: ctx, onStdout: (line) => console.log(line.text) });

// result contains matplotlib charts, structured json output, and Pandas tables in HTML

Les agents sont plus utiles lorsqu’ils peuvent créer quelque chose et le montrer immédiatement à l’utilisateur. Les sandboxes prennent en charge les processus en arrière-plan, les contrôles de préparation et les URL d’aperçu. Cela permet à un agent de lancer un serveur de développement et de partager un lien en direct sans quitter la conversation.

// Start a dev server as a background process
const server = await sandbox.startProcess("npm run dev", {
  cwd: "/workspace",
});

// Wait until the server is actually ready — don't just sleep and hope
await server.waitForLog(/Local:.*localhost:(\d+)/);

// Expose the running service with a public URL
const { url } = await sandbox.exposePort(3000);

// url is a live public URL the agent can share with the user
console.log(`Preview: ${url}`);

Avec waitForPort() et waitForLog(), les agents peuvent séquencer le travail en fonction de signaux réels provenant du programme en cours d’exécution au lieu de suppositions. C’est beaucoup plus intéressant que l'autre solution courante qui correspond généralement à une version de sleep(2000) exécutée en croisant les doigts.

Les boucles de développement modernes sont commandées par des événements. Enregistrez un fichier, puis exécutez à nouveau la version exécutable. Éditez une configuration, puis redémarrez le serveur. Modifiez un test et exécutez à nouveau la suite.

Nous avons lancé sandbox.watch() au mois de mars. Elle renvoie un flux SSE étayé par inotify natif, le mécanisme du noyau que Linux utilise pour les événements du système de fichiers.

import { parseSSEStream, type FileWatchSSEEvent } from '@cloudflare/sandbox';

const stream = await sandbox.watch('/workspace/src', {
  recursive: true,
  include: ['*.ts', '*.tsx']
});

for await (const event of parseSSEStream<FileWatchSSEEvent>(stream)) {
  if (event.type === 'modify' && event.path.endsWith('.ts')) {
    await sandbox.exec('npx tsc --noEmit', { cwd: '/workspace' });
  }
}

Il s’agit d’une de ces primitives qui modifient discrètement ce que les agents peuvent faire. Un agent capable d’observer le système de fichiers en temps réel peut participer aux mêmes boucles de collecte d’informations qu’un développeur humain.

Imaginez un développeur (humain) travaillant sur son ordinateur portable. Il clone un référentiel Git, exécute une installation via npm, écrit du code, déploie un PR, puis ferme son ordinateur portable en attendant la révision du code. Lorsque vient le moment de reprendre le travail, il lui suffit de rouvrir l’ordinateur portable et de poursuivre là où il s'est arrêté.

Si un agent souhaite reproduire ce flux de travail sur une plateforme de conteneur simpliste, vous rencontrez un problème. Comment reprendre rapidement là où vous vous êtes interrompu ? Vous pouvez maintenir une sandbox active, mais vous payez alors pour le calcul inutilisé. Vous pouvez tout recommencer à partir de l’image du conteneur, mais vous devrez ensuite patienter longtemps, le temps d'un clonage de référentiel git et d'une installation via npm.

Notre réponse, ce sont les instantanés, qui seront déployés dans les semaines à venir.

Un instantané préserve l’état complet du disque d’un conteneur, la configuration du système d’exploitation, les dépendances installées, les fichiers modifiés, les fichiers de données et bien davantage. Il vous permet ensuite de tout restaurer rapidement.

Vous pouvez configurer une sandbox afin qu’elle réalise automatiquement un instantané lorsqu’elle est mise en veille.

class AgentDevEnvironment extends Sandbox {
  sleepAfter = "5m";
  persistAcrossSessions = {type: "disk"}; // you can also specify individual directories
}

Vous pouvez également effectuer un instantané de manière programmatique, puis le restaurer manuellement. Cette fonctionnalité est utile pour contrôler les tâches ou prévoir des instances de sessions. Par exemple, si vous souhaitiez exécuter quatre instances d’un agent en parallèle, vous pourriez facilement démarrer quatre sandboxes à partir du même état.

class AgentDevEnvironment extends Sandbox {}

async forkDevEnvironment(baseId, numberOfForks) {
  const baseInstance = await getSandbox(baseId);
  const snapshotId = await baseInstance.snapshot();

  const forks = Array.from({ length: numberOfForks }, async (_, i) => {
    const newInstance = await getSandbox(`${baseId}-fork-${i}`);
    return newInstance.start({ snapshot: snapshotId });
  });

  await Promise.all(forks);
}

Les instantanés sont stockés dans R2 au sein de votre compte, ce qui vous garantit durabilité et indépendance vis-à-vis de l’emplacement. Le système de mise en cache par niveau de R2 permet des restaurations rapides dans toutes les régions du monde.

Dans les versions futures, l’état de la mémoire en direct sera également capturé, ce qui permettra aux processus en cours de reprendre exactement là où ils se sont arrêtés. Un terminal et un éditeur rouvriront dans l’état exact où ils se trouvaient lors de leur dernière fermeture.

Si vous souhaitez restaurer l’état de la session avant la mise en service des instantanés, vous pouvez utiliser dès maintenant les méthodes de sauvegarde et de restauration. Ces méthodes conservent et restaurent également les répertoires à l’aide de R2, mais ne se montrent pas aussi performantes que les véritables instantanés au niveau de la VM. Toutefois, elles peuvent encore améliorer considérablement la vitesse par rapport à la recréation simpliste de l’état de session.

^{Le démarrage d’une sandbox, le clonage d’axios et l’installation via npm prennent 30 secondes. La restauration à partir d’une sauvegarde prend deux secondes.}

Restez à l’écoute dans l'attente de la publication officielle de l’instantané.

Depuis notre lancement initial, nous avons régulièrement augmenté notre capacité. Les utilisateurs de notre offre Standard peuvent désormais exécuter 15 000 instances simultanées de type léger, 6 000 instances de base et plus de 1 000 instances simultanées de plus grande taille. Contactez-nous pour en exécuter encore plus !

Nous avons également modifié notre modèle de tarification afin que ce dernier soit plus rentable à grande échelle. Les sandboxes ne facturent désormais que les cycles CPU activement utilisés. Cela signifie que vous ne payez pas de temps processeur inutilisé pendant que votre agent attend la réponse d’un LLM.

Il y a neuf mois, nous avons livré une sandbox capable d’exécuter des commandes et d’accéder à un système de fichiers. Cela a suffi à éprouver le concept.

Ce dont nous disposons aujourd’hui est différent par nature. Aujourd’hui, un environnement de test est un environnement de développement complet : un terminal auquel vous pouvez connecter un navigateur, un interpréteur de code avec un état persistant, des processus en arrière-plan avec des URL de prévisualisation en direct, un système de fichiers qui émet des événements de changement en temps réel, des proxys de sortie pour l’injection sécurisée d’informations d’identification et un mécanisme d’instantanéité qui rend les démarrages à chaud presque instantanés. 

Lorsque vous développez sur cette base, il se dégage une logique satisfaisante : des agents qui effectuent un véritable travail d’ingénierie. Cloner un référentiel, l’installer, exécuter les tests, lire les erreurs, modifier le code, exécuter à nouveau les tests. Le genre de boucle de rétroaction étroite qui rend l'ingénieur humain efficace ; et maintenant, l’agent la suit également.

Nous sommes à la version 0.8.9 du SDK. Commencez dès aujourd’hui :

npm i @cloudflare/sandbox@latest

Aujourd'hui, nous donnons le coup d'envoi de l'Agents Week, consacrée au développement d'Internet pour l'avenir.

Le cloud, tel que nous le connaissons, est le fruit du dernier grand changement de paradigme technologique : l'arrivée des smartphones.

Lorsque les smartphones ont mis Internet dans la poche de tout le monde, ils n’ont pas seulement ajouté des utilisateurs, ils ont fondamentalement modifié ce que signifie être en ligne. Toujours connecté, toujours en attente d’une réponse instantanée. Les applications ont dû gérer un nombre d’utilisateurs considérablement supérieur, et l’infrastructure soutenant leur fonctionnement a dû évoluer.

La solution vers laquelle le secteur a convergé était simple : plus d’utilisateurs, plus de copies de votre application. À mesure que les applications gagnaient en complexité, les équipes les ont divisées en fragments plus petits, appelés microservices, afin que chaque équipe puisse maîtriser son propre destin. Cependant, le principe fondamental est resté le même : un nombre fini d’applications, chacune servant de nombreux utilisateurs. Évoluer signifiait multiplier les copies.

Kubernetes et les conteneurs sont devenus la norme. Ils vous ont aidés à lancer des instances, à équilibrer les charges et à éliminer les composants dont vous n’aviez pas besoin. Dans ce modèle un-vers-plusieurs, une instance seule pouvait servir de nombreux utilisateurs, et même lorsque le nombre d’utilisateurs se comptait en milliards, le nombre d’éléments à gérer est resté limité.

Les agents viennent perturber ce fonctionnement.

Contrairement à toutes les applications précédentes, les agents suivent un modèle un-vers-un. Chaque agent est une instance unique. Servir un utilisateur, exécuter une tâche. Alors qu’une application traditionnelle s'exécute de la même façon, quel que soit l’utilisateur qui l’utilise, un agent nécessite son propre environnement d’exécution : un environnement dans lequel le LLM indique le chemin au code, appelle les outils de manière dynamique, ajuste son approche et poursuit jusqu’à la fin de la tâche.

Voyez cette différence comme celle qui distingue un restaurant d'un chef personnel. Un restaurant propose un menu (un ensemble fixe d’options) et dispose d’une cuisine optimisée pour les préparer en grande quantité. Aujourd’hui, c’est le cas de la plupart des applications. Un agent ressemble davantage à un chef personnel qui vous demande ce que vous voulez manger. Il peut arriver qu’il ait besoin d’ingrédients, d’ustensiles ou de techniques totalement différents à chaque fois. Vous ne pouvez pas gérer un service de chef personnel avec la même configuration de cuisine que celle d'un restaurant.

Au cours de l’année passée, nous avons vu les agents prendre leur essor, notamment les agents de codage ; ce n'est pas une surprise dans la mesure où les développeurs sont souvent les premiers adoptants. La plupart des agents de codage fonctionnent aujourd’hui en faisant tourner un conteneur pour fournir au LLM ce dont il a besoin : un système de fichiers, git, bash et la possibilité d’exécuter des fichiers binaires arbitraires.

Mais les agents de codage ne sont qu'un début. Des outils comme Claude Cowork rendent déjà les agents accessibles aux utilisateurs moins techniques. Une fois que les agents dépassent le cadre des développeurs pour être mis entre les mains de tous (assistants administratifs, analystes de recherche, représentants du service client, planificateurs personnels), les chiffres associés à cette évolution sont déconcertants.

Si les plus de 100 millions de travailleurs du savoir aux États-Unis utilisaient chacun un assistant agentique à concurrence d’environ 15 %, il faudrait une capacité d’environ 24 millions de sessions simultanées. En comptant 25 à 50 utilisateurs par processeur, cela représente entre 500 000 et 1 million de processeurs de serveur, rien que pour les États-Unis, pour un agent par personne.

Imaginez maintenant que chaque personne exécute plusieurs agents en parallèle. Imaginez également que le reste du monde compte plus d’un milliard de travailleurs du savoir. Nous ne sommes pas simplement à la traîne en matière de puissance de calcul. Nous sommes totalement dépassés.

Comment combler cet écart ?

Il y a huit ans, nous avons lancé Workers qui formait les prémices de notre plateforme pour développeurs et un pari sur le calcul sans conteneur et serverless. La motivation à l’époque était d'ordre pratique : nous avions besoin d’une capacité de traitement léger, sans démarrage à froid, pour les clients qui comptaient sur Cloudflare pour garantir la vitesse. Développée à partir d’isolats V8 au lieu de conteneurs, la plateforme Workers s’est avérée considérablement plus efficace — plus rapide au démarrage, moins coûteuse à exécuter et nativement adaptée au modèle « démarrer, exécuter, arrêter ».

Ce que nous n’avions pas prévu, c’est à quel point ce modèle serait parfaitement adapté l’ère des agents.

Là où les conteneurs offrent à chaque agent une cuisine intégrée complète : des appareils installés, des réfrigérateurs encastrés, tout le nécessaire, que l’agent en ait besoin ou non, les isolats, en revanche, donnent au chef personnel exactement l’espace de travail, le brûleur et le couteau dont il a besoin pour un repas particulier. Provisionnement en quelques millisecondes. Nettoyage immédiat une fois le plat servi.

Dans un monde où nous devons prendre en charge non pas des milliers d’applications de longue durée, mais des milliards d’environnements d’exécution éphémères et à usage unique, les isolats sont la composante primitive idéale. 

Chaque isolat démarre en quelques millisecondes. Chacun est sandboxé en toute sécurité. Et vous pouvez en exécuter énormément plus sur le même matériel qu'avec les conteneurs.

Il y a tout juste quelques semaines, nous sommes allés plus loin avec la version bêta ouverte de Dynamic Workers. Il s'agit d'environnements d’exécution créés dynamiquement pendant l’exécution et à la demande. Le démarrage d’un isolat prend quelques millisecondes et consomme quelques mégaoctets de mémoire. C’est à peu près 100 fois plus rapide et jusqu’à 100 fois plus rentable en matière de mémoire qu’un conteneur. 

Vous pouvez en démarrer une nouvelle pour chaque requête, exécuter un fragment de code, puis l'éliminer et ce à un rythme de millions par seconde.

Pour toucher davantage que les primo-adoptants et se retrouver entre les mains de tous les utilisateurs, les agents doivent également se montrer abordables. L’exécution de chaque agent au sein de son propre conteneur se révèle des plus coûteuses, si bien que les outils agentiques actuels sont principalement limités aux assistants de codage pour les techniciens qui peuvent en justifier le coût. Les isolats, étant plus efficaces pour exécuter en quantité massive rendent les économies par unité viables à l’échelle requise par les agents.

S’il est essentiel de prévoir les bonnes fondations l’avenir, nous n’y sommes pas encore. Et à chaque changement de paradigme il se passe une période pendant laquelle nous essayons de faire fonctionner la nouvelle solution dans l’ancien modèle. Les premières voitures étaient appelées « voitures sans chevaux ». Les premiers sites web étaient des brochures numériques. Les premières applications mobiles étaient des interfaces utilisateur de bureau réduites. Nous sommes actuellement dans cette phase, avec les agents.

C'est visible partout. 

Nous donnons aux agents des navigateurs headless pour naviguer sur des sites web conçus pour les humains, alors que ce dont ils ont besoin, ce sont des protocoles structurés tels que MCP pour découvrir et appeler directement des services. 

Parmi les premiers serveurs MCP, de nombreux ne sont que de minces enveloppes autour des **API** REST existantes (mêmes opérations CRUD, nouveau **protocole**) alors que les LLM sont en fait bien meilleurs pour écrire du code que pour effectuer des appels d’outils séquentiels. 

Nous utilisons les CAPTCHA et les empreintes comportementales pour vérifier ce qui se trouve à l’autre extrémité d’une requête et de plus en plus souvent, il s'agit d’un agent opérant pour le compte de quelqu’un. La bonne question n'est donc pas « es-tu humain ? » mais « quel agent êtes-vous, qui vous a autorisé et qu’êtes-vous autorisé à faire ? »

Nous démarrons des conteneurs complets pour les agents qui ont simplement besoin d’effectuer quelques appels d’API et de renvoyer un résultat.

Il ne s’agit là que de quelques exemples, mais rien de tout cela n’est surprenant. C’est à ça que ressemblent les transitions.

L’Internet se situe toujours quelque part entre deux époques. IPv6 est objectivement meilleur qu’IPv4, mais l’abandon de la prise en charge d’IPv4 anéantirait la moitié de l’Internet. HTTP/2 et HTTP/3 coexistent. TLS 1.2 n’a pas encore complètement cédé à 1.3. Il existe une technologie plus avancée, mais l’ancienne technologie perdure, et le rôle de l’infrastructure est de permettre aux deux de coexister.

Cloudflare a toujours oeuvré pour faciliter des transitions harmonieuses. La transition vers les agents ne fait pas exception.

Les agents de codage ont réellement besoin de conteneurs : un système de fichiers, git, bash, une exécution binaire arbitraire. Cela n’est pas près de s’arrêter. Cette semaine, nos environnements sandbox basés sur des conteneurs passent en disponibilité générale, car nous nous engageons à les rendre aussi performants que possible. Nous allons approfondir le rendu du navigateur pour les agents, car il restera un certain nombre de services qui ne prendront pas encore en charge le protocole MCP, et les agents devront continuer d'interagir avec eux. Il ne s’agit pas de solutions temporaires, mais d’éléments d’une plateforme complète.

Mais nous travaillons également au développement de ce qui viendra ensuite : les isolats, les protocoles et les modèles d’identité dont les agents ont réellement besoin. Notre rôle consiste à nous assurer que vous n’aurez pas à choisir entre ce qui fonctionne aujourd’hui et ce qui est bon pour demain.

Si des agents doivent gérer nos tâches professionnelles et personnelles (lire nos e-mails, opérer sur notre code, interagir avec nos services financiers), la sécurité doit alors être intégrée au modèle d’exécution, et non être ajoutée a posteriori.

Les RSSI ont été les premiers à y faire face. Les gains de productivité résultant de la mise en place d’agents entre tous les acteurs sont réels, mais aujourd’hui, la plupart des déploiements d’agents sont empreints de nombreux risques : injection d’invites, exfiltration de données, API non autorisées, utilisation d’outils opaques. 

L’agent de vibe-coding d’un développeur a besoin d’accéder aux référentiels et aux pipelines de déploiement. L’agent de service client d’une entreprise doit avoir accès aux API internes et aux données des utilisateurs. Dans les deux cas, la sécurisation de l’environnement aujourd’hui implique d’assembler des identifiants, des politiques réseau et des contrôles d’accès qui n’ont jamais été conçus pour les logiciels autonomes.

Cloudflare a développé deux plateformes en parallèle : notre plateforme pour développeurs, destinée aux personnes qui créent des applications, et notre plateforme Zero Trust, pour les entreprises qui ont besoin de sécuriser leurs accès. Pendant un certain temps, ces plateformes s’adressaient à des publics distincts. 

Mais « comment puis-je développer cet agent ? » et « Comment m’assurer qu’il est sûr ? » sont deux questions qui se rejoignent de plus en plus. Nous réunissons ces plateformes de manière à ce que toutes ces fonctionnalités soient natives pour l’exécution des agents, et qu'il ne s'agisse pas d'une couche distincte que l’on ajoute séparément.

L’ère des agents compte une autre dimension qui va au-delà du calcul et de la sécurité : l’économie et la gouvernance.

Lorsque des agents interagissent avec Internet pour notre compte « pour lire des articles, utiliser des API, accéder à des services », les personnes et les entreprises qui créent ces contenus et exécutent ces services peuvent en définir les conditions et être rémunérées. Aujourd’hui, le modèle économique du web repose sur l’attention humaine : publicités, contenus, abonnements. 

Les agents n’ont pas d’attention (du moins, pas ce genre d’attention). Ils ne voient pas de publicités. Ils ne cliquent pas sur les bannières de cookies.

Si nous voulons un Internet où les agents peuvent agir librement et où les éditeurs, les créateurs de contenus et les fournisseurs de services sont équitablement rémunérés, nous avons besoin d’une nouvelle infrastructure. Nous développons des outils grâce auxquels il sera plus facile aux éditeurs et aux propriétaires de contenu de définir et d’appliquer des politiques régissant la manière dont les agents interagissent avec leur contenu.

Construire un meilleur Internet a toujours impliqué de faire en sorte qu’il fonctionne pour tout le monde ; pas seulement pour les personnes qui développent la technologie, mais aussi pour celles dont le travail et la créativité font de l’Internet un outil utile. L’ère des agents ne remet pas en cause cet impératif, au contraire, elle le rend plus important encore.

Notre vision pour la plateforme de développement a toujours été de fournir une plateforme complète et performante : de l’expérimentation au produit minimum viable, jusqu’à la distribution à grande échelle pour des millions d’utilisateurs. Mais fournir les primitives n’est qu’une partie de l’équation. Une plateforme performante doit également tenir compte de la manière dont tous les éléments fonctionnent ensemble et à la manière dont elle s’intègre dans votre flux de développement.

Cette tâche évolue. Autrefois, il n'était question que de l’expérience des développeurs, l'idée était de faciliter le développement, les tests et la mise en œuvre pour des humains. De plus en plus, Il s’agit également d’aider les agents à aider les humains et de faire en sorte que la plateforme fonctionne non seulement pour les personnes qui créent des agents, mais pour les agents eux-mêmes. Un agent peut-il trouver les pratiques recommandées les plus récentes ? Avec quelle facilité peut-il découvrir et invoquer les outils et les interfaces de ligne de commande dont il a besoin ? Comment peut-il passer de l’écriture du code à son déploiement le plus harmonieusement possible ?

Cette semaine, nous déployons des améliorations dans les deux dimensions, afin de rendre Cloudflare meilleure pour les humains qui y travaillent et pour les agents qui l’utilisent.

Développer pour l’avenir n’est pas quelque chose que nous pouvons faire seuls. Chaque transition majeure d’Internet (de HTTP/1.1 à HTTP/2 et HTTP/3, de TLS 1.2 à 1.3) a exigé que l'ensemble du secteur converge vers des normes partagées. Il en sera de même pour la transition vers les agents.

Cloudflare contribue depuis longtemps à l’élaboration de normes qui font fonctionner Internet. Nous sommes très investis dans l’IETF depuis plus d’une décennie, en contribuant au développement et au déploiement de protocoles tels que QUIC, TLS 1.3 et Encrypted Client Hello. Nous avons été un membre fondateur de WinterTC, le comité technique de l’ECMA pour l’interopérabilité des environnements d'exécution JavaScript. Nous avons lancé l'environnement d'exécution Workers lui-même en open source, car nous pensons que le principe fondamental devrait être ouvert.

Nous envisageons l'ère des agents dans le même esprit. Nous sommes ravis de faire partie de la Linux Foundation et de l’AAIF, et de contribuer à soutenir et promouvoir des normes telles que le protocole MCP, qui seront fondamentales pour l’avenir de l’ère des agents. Depuis le lancement de MCP par Anthropic, nous avons travaillé en étroite collaboration avec eux pour bâtir l’infrastructure des serveurs MCP distants, nous avons open-sourcé nos propres mises en oeuvre et nous avons investi dans la mise en œuvre du protocole à grande échelle. 

L’année dernière, aux côtés de Coinbase, nous avons cofondé la x402 Foundation, une norme ouverte et neutre qui redynamise le code d’état HTTP 402, longtemps dormant, afin de proposer aux agents un moyen natif de payer les services et les contenus qu’ils consomment. 

Identité, autorisation, paiement, sécurité : ces éléments nécessitent tous des normes ouvertes qu’aucune entreprise ne peut définir seule.

Cette semaine, nous annonçons des solutions couvrant toutes les dimensions de la pile d’agents : le calcul, la connectivité, la sécurité, l’identité, l’économie et l’expérience des développeurs.

L’Internet n’a pas été créé dans une optique d’IA. Le cloud n’a pas été créé pour les agents. Cloudflare s’est toujours donné pour objectif de contribuer à bâtir un Internet meilleur, et ce que « meilleur » signifie évolue à chaque époque. Nous entrons dans l'ère des agents. Cette semaine, suivez-nous et nous vous montrerons ce que nous développons dans cette optique.

Chez Cloudflare, nous avons à cœur de rendre l’Internet confidentiel et sécurisé par défaut. Nous avons commencé par proposer des certificats SSL universels gratuits en 2014, nous avons commencé à préparer notre migration post-quantique en 2019, puis nous avons activé le chiffrement post-quantique pour tous les sites web et les API en 2022, afin d’atténuer les attaques de type « collecter maintenant/déchiffrer plus tard ». Si nous nous réjouissons de constater que plus de 65 % du trafic humain acheminé vers Cloudflare est chiffré avec un algorithme post-quantique, notre travail restera inachevé tant que l’authentification n’aura pas bénéficié d’une mise à niveau, elle aussi. De nouvelles études fiables et la rapidité des évolutions du secteur laissent penser que l’échéance de cette migration est beaucoup plus proche que prévu. Il s’agit là d’un défi que toutes les entreprises doivent relever avec urgence ; c’est pourquoi nous accélérons notre calendrier interne de préparation à l’événement Q-Day.

Que s’est-il passé ? La semaine dernière, Google a annoncé avoir considérablement amélioré l’algorithme quantique permettant de briser les systèmes de cryptographie sur les courbes elliptiques, largement utilisés pour sécuriser Internet. L’entreprise n’a pas révélé l’algorithme, mais a fourni une preuve à divulgation nulle de connaissance qu’elle en possède un.

Et il ne s’agit même pas là de la plus grande avancée révolutionnaire. Le même jour, Oratomic a publié une estimation des ressources nécessaires pour briser les systèmes cryptographiques RSA-2048 et P-256 sur un ordinateur à atomes neutres. Pour P-256, cela nécessite un nombre incroyablement faible de 10 000 qubits seulement. On comprend désormais pourquoi Google a récemment annoncé son intention de se lancer également dans la recherche sur les technologies à atomes neutres, parallèlement aux ordinateurs quantiques supraconducteurs. Bien qu’Oratomic explique son approche fondamentale, l’entreprise omet néanmoins intentionnellement certains détails essentiels.

Ces avancées indépendantes ont incité Google à avancer son calendrier de migration vers l’informatique post-quantique à l’horizon 2029. Par ailleurs, dans son communiqué et d’autres interventions également, Google a accordé la priorité à l’authentification quantique sécurisée plutôt qu’à l’atténuation des attaques de type « collecter maintenant/déchiffrer plus tard » (« Harvest-Now/Decrypt-Later, HNDL). Comme nous l’examinerons ci-dessous, cette priorité indique que Google craint que l’échéance Q-Day puisse survenir dès 2030. À la suite de ces annonces, le directeur technique d’IBM Quantum Safe s’est montré plus pessimiste, n’excluant pas la possibilité « d’attaques quantiques ambitieuses » contre des cibles de grande valeur dès 2029.

La menace quantique est bien connue : Q-Day désigne le jour où des ordinateurs quantiques suffisamment puissants se montreront capables de briser les systèmes cryptographiques essentiels utilisés pour protéger les données et les accès sur les systèmes actuels. Les ordinateurs quantiques cryptographiquement compétents (« Cryptographically Relevant Quantum Computer », CRQC) n’existent pas encore, mais de nombreux laboratoires dans le monde explorent différentes approches de leur construction. Encore récemment, les avancées concernant les systèmes CRQC étaient pour l’essentiel rendues publiques, mais rien ne laisse présager que cela perdurera. En effet, tout porte à croire que les progrès futurs seront occultés au grand public. Scott Aaronson, scientifique en informatique quantique, a émis cette mise en garde à la fin de l’année 2025 :

À un moment donné, les personnes qui établissent des estimations détaillées du nombre de qubits physiques et de portes logiques nécessaires pour briser les systèmes cryptographiques actuellement déployés utilisant l’algorithme de Shor cesseront de publier ces estimations, ne serait-ce que pour éviter de divulguer un trop grand nombre d’informations aux adversaires. Et, pour autant que nous le sachions, ce stade est peut-être déjà dépassé.

En effet, ce stade est désormais bel et bien dépassé.

Nous aimerions expliquer brièvement pourquoi il est difficile d’anticiper les progrès accomplis dans le domaine de l’informatique quantique. De véritables « bonds quantiques » dans la compréhension, comme celui dont nous avons été témoins la semaine dernière, peuvent être effectués, même lorsque tout se déroule sous les yeux du public. En termes simples, briser un système cryptographique à l’aide d’un ordinateur quantique exige de mener des travaux de développement sur trois fronts indépendants : le matériel quantique, la correction d’erreurs et les logiciels quantiques. Les progrès réalisés sur chaque front renforcent ceux accomplis sur les autres.

Le matériel. Il existe de nombreuses approches concurrentes. Nous avons évoqué les atomes neutres et les qubits supraconducteurs, mais il existe également les pièges à ions, les qubits photoniques et des projets ambitieux, tels que les qubits topologiques. Certaines approches complémentaires peuvent même être associées. La plupart de ces approches sont mises en œuvre par plusieurs laboratoires à travers le monde. Elles présentent toutes une longue liste de défis et de problèmes techniques distincts restant à résoudre et, il y a encore quelques années, il était difficile de savoir si l’une de ces approches pourrait un jour être mise en œuvre à grande échelle. Aujourd’hui, des progrès considérables ont été accomplis dans la plupart de ces domaines. Cependant, aucune de ces technologies n’a encore démontré sa capacité à être déployée à grande échelle : si c’était le cas, il ne nous resterait même plus quelques années avant l’échéance. Ces approches sont désormais beaucoup plus proches, toutefois, en particulier celle concernant les atomes neutres. Pour ignorer ce progrès, il faudrait croire que chaque approche se heurtera inéluctablement à un mur.

Correction des erreurs. Tous les ordinateurs quantiques sont sujets au bruit et nécessitent des codes de correction des erreurs pour exécuter des calculs pertinents. Cela génère une surcharge de traitement supplémentaire non négligeable, même si l’ampleur dépend de l’architecture. Plus le bruit est présent, plus la correction d’erreurs requise est importante ; toutefois, plus intéressant encore, l’amélioration de la connectivité des qubits permet d’obtenir des codes beaucoup plus efficaces. Pour vous donner un ordre de grandeur, il faut généralement environ un millier de qubits physiques pour un qubit logique dans les ordinateurs quantiques supraconducteurs, qui sont sujets au bruit et ne disposent que d’une connectivité entre qubits voisins. Nous savons que les « qubits reconfigurables », tels que ceux des machines à atomes neutres, permettent d’améliorer considérablement l’efficacité des codes de correction d’erreurs. Étonnamment, Oratomic a démontré que cet avantage est encore plus important : seuls 3 ou 4 qubits d’atomes neutres physiques sont nécessaires par qubit logique.

Les logiciels. Enfin, les algorithmes quantiques permettant de briser les systèmes cryptographiques peuvent être améliorés. Il s’agit là de l’avancée révolutionnaire de Google : ils ont massivement accéléré l’algorithme permettant de déchiffrer le système cryptographique P-256. Oratomic a par ailleurs présenté d’autres optimisations spécifiques à l’architecture pour les qubits reconfigurables.

Le tableau se précise : en 2025, les atomes neutres se sont révélés plus évolutifs que prévu, et aujourd’hui, Oratomic a compris comment créer des codes de correction d’erreurs considérablement plus performants avec ces qubits hautement connectés. Par ailleurs, briser le système cryptographique P-256 demande beaucoup moins d’efforts. Il en résulte que la date du Q-Day a été considérablement avancée par rapport aux prévisions habituelles au-delà de 2035, les atomes neutres arrivant en tête, suivis de près par d’autres approches.

Dans des articles de blog précédents, nous avons examiné comment les différents ordinateurs quantiques se mesurent, au regard du nombre de qubits physiques et de la fidélité, par rapport à l’objectif conservateur de briser le système cryptographique RSA-2048 sur une architecture à qubits supraconducteurs. Cette analyse nous donne une idée approximative du temps dont nous disposons, et elle est certainement meilleure que le suivi des records de factorisation quantique ; toutefois, elle ne tient pas compte des optimisations spécifiques à l’architecture ni des améliorations logicielles. Il convient désormais de surveiller le moment où les dernières fonctionnalités manquantes de chaque architecture seront mises en œuvre.

Historiquement, l’intérêt porté par le secteur à la cryptographie post-quantique (Post-Quantum Cryptography, PQC) se concentrait principalement sur le chiffrement post-quantique, qui permet d’arrêter les attaques de type « collecter maintenant, déchiffrer plus tard » (« Harvest Now/Decrypt Later », HNDL). Lors d’une attaque HNDL, un acteur malveillant collecte aujourd’hui du trafic réseau sensible chiffré, qu’il stocke jusqu’à ce qu’il puisse, à une date ultérieure, utiliser un ordinateur quantique puissant pour déchiffrer les données recueillies. Les attaques HNDL constituent la principale menace tant que le Q-Day reste encore une échéance lointaine. C’est pourquoi, jusqu’à présent, nous nous sommes attachés à atténuer ce risque, en intégrant par défaut le chiffrement post-quantique dans nos produits depuis 2022. Aujourd’hui, comme nous l’avons indiqué plus haut, la plupart des produits Cloudflare sont sécurisés contre les attaques HNDL, et nous nous employons à mettre à niveau les autres en ce moment même.

L’autre catégorie d’attaques cible l’authentification : des adversaires disposant d’ordinateurs quantiques opérationnels se font passer pour des serveurs ou falsifient des identifiants d’accès. Tant que l’échéance Q-Day reste encore lointaine, l’authentification n’est pas urgente : le déploiement de certificats et de signatures post-quantiques n’ajoute aucune valeur, mais uniquement une charge de travail supplémentaire.

À l’inverse, une échéance Q-Day imminente viendrait bouleverser la donne : les fuites de données seraient graves, mais une faille dans l’authentification serait catastrophique. Toute clé de connexion à distance vulnérable aux attaques quantiques qui aurait été négligée deviendrait un point d’accès permettant à un acteur malveillant de faire ce qu’il souhaite, qu’il s’agisse d’extorquer des fonds ou de paralyser ou d’espionner votre système. Tout mécanisme de mise à jour automatique des logiciels deviendrait un vecteur d’exécution de code à distance. Pour un acteur malveillant actif exploitant l’informatique quantique, c’est un jeu d’enfant : il lui suffit de trouver une seule clé de confiance vulnérable à l’informatique quantique pour s’introduire dans le système.

Lorsque les experts du développement d’ordinateurs quantiques commenceront à appliquer des correctifs aux systèmes d’authentification, nous aurons tous intérêt à prêter attention. La question n’est plus « Quand nos données chiffrées seront-elles menacées ? », mais « Combien de temps avant qu’un acteur malveillant ne franchisse la porte d’entrée avec une clé factice générée par un ordinateur quantique ? ».

Si les ordinateurs quantiques font leur apparition dans les prochaines années, ils seront rares et coûteux. Les acteurs malveillants privilégieront les cibles de grande valeur, telles que les clés à longue durée de vie permettant d’accéder à des ressources considérables ou d’obtenir un accès persistant, notamment les certificats racine, les clés d’authentification d’API et les certificats de signature de code. Un acteur malveillant qui parviendrait à compromettre l’une de ces clés conserverait un accès illimité jusqu’à ce qu’il soit démasqué ou que cette clé soit révoquée.

Cela suggère que les clés à longue durée de vie seront probablement ciblées en priorité. Ce sera certainement vrai si l’attaque quantique d’une clé unique s’avère être un processus coûteux et lent, ce qui sera vraisemblablement le cas pour la première génération d’ordinateurs quantiques à atomes neutres. Ce ne sera, en revanche, pas le cas pour les ordinateurs quantiques supraconducteurs évolutifs et les générations ultérieures d’ordinateurs quantiques à atomes neutres, qui pourraient parvenir à déchiffrer les clés beaucoup plus rapidement. Ces systèmes CRQC rapides changeraient une nouvelle fois la donne, et un adversaire qui disposerait d’un tel ordinateur pourrait se concentrer exclusivement sur des attaques HNDL, afin que ses actions restent indétectables. Sophie Schmieg de Google compare ce scénario à la cryptanalyse d’Enigma, qui a renversé le cours de la Seconde Guerre mondiale.

Il ne suffit pas d’ajouter la prise en charge de la cryptographie post-quantique. Pour être protégés contre les attaques par rétrogradation, les systèmes doivent désactiver la prise en charge de la cryptographie vulnérable aux attaques quantiques. Dans les systèmes plus vastes, notamment les systèmes fédérés, tels que le web, cela n’est pas envisageable, car tous les clients (navigateurs) ne prennent pas en charge les certificats post-quantiques, et les serveurs doivent continuer à assurer la prise en charge de ces clients traditionnels. Cependant, il est toujours possible d’assurer la protection contre la rétrogradation pour le protocole HTTPS en utilisant « PQ HSTS » et/ou la transparence des certificats.

La désactivation de la cryptographie vulnérable aux ordinateurs quantiques n’est pas la dernière étape : une fois cette opération effectuée, tous les secrets, tels que les mots de passe et les jetons d’accès précédemment exposés dans le système vulnérable aux ordinateurs quantiques doivent être renouvelés. Contrairement au chiffrement post-quantique, qui nécessite la mise en œuvre d’une initiative de grande ampleur, la migration vers l’authentification post-quantique comporte une longue chaîne de dépendances, sans même parler de la validation par des tiers et de la surveillance des fraudes. Il s’agit d’une évolution qui demandera des années, plutôt que des mois.

Il est tout à fait naturel que les entreprises qui lisent ces lignes se précipitent dans une réflexion sur les systèmes internes qu’elles doivent mettre à niveau. Toutefois, l’histoire ne s’arrête pas là. Le Q-Day menace tous les systèmes. Il est donc important de bien comprendre l’impact d’un éventuel Q-Day sur les dépendances tierces, qu’elles soient directes ou indirectes. Cela ne concerne pas uniquement les tiers avec lesquels vous communiquez via des systèmes cryptographiques, mais également tous les tiers qui représentent des dépendances commerciales essentielles, tels que les services financiers et les services publics.

À l’approche du Q-Day, dont l’échéance a été avancée, l’authentification post-quantique est devenue une priorité absolue. Les clés à long terme doivent être mises à niveau en priorité. En raison de la complexité des chaînes de dépendances et du fait que toutes les entreprises font appel à des fournisseurs tiers, cette évolution demandera des années, plutôt que des mois. Il ne suffit pas d’adopter à la cryptographie post-quantique : pour éviter les rétrogradations, il est également nécessaire de désactiver la cryptographie vulnérable à l’informatique quantique.

Aujourd’hui, Cloudflare propose un chiffrement post-quantique pour la majorité de ses produits, permettant ainsi d’atténuer les risques d’attaques de type « collecter maintenant, déchiffrer plus tard ». C’est le fruit d’un travail que nous avons commencé il y a plus de dix ans, afin de protéger nos clients et l’Internet au sens large. Notre objectif est d’assurer, d’ici 2029, une sécurité post-quantique intégrale, incluant notamment l’authentification, pour l’ensemble de notre gamme de produits. Nous vous présentons ici quelques échéances intermédiaires que nous avons définies, qui sont susceptibles d’évoluer à mesure que notre compréhension des risques et des difficultés liées au déploiement progresse.

Pour les entreprises, nous recommandons de considérer la prise en charge de l’informatique post-quantique comme une condition préalable à tout achat. Les bonnes pratiques courantes, telles que la mise à jour régulière des logiciels et l’automatisation de la délivrance des certificats, sont particulièrement pertinentes et vous permettront de réaliser des progrès considérables. Nous vous recommandons d’évaluer, le plus rapidement possible, les fournisseurs essentiels afin de comprendre les implications potentielles de leur inaction sur votre entreprise.

Pour les organismes de réglementation et les pouvoirs publics, jusqu’à présent, l’établissement d’échéances précoces a joué un rôle crucial dans les progrès réalisés à l’échelle du secteur. Nous nous trouvons aujourd’hui à un tournant décisif, où la fragmentation des normes et des initiatives, tant entre les juridictions qu’au sein de celles-ci, pourrait compromettre les progrès accomplis. Nous recommandons aux pouvoirs publics de désigner une agence dirigeante et de doter celle-ci d’une autorité suffisante, afin de coordonner la migration conformément à un calendrier précis, d’assurer une vigilance quant aux problématiques de sécurité et de promouvoir l’application des normes internationales existantes. Sans céder à la panique, les pouvoirs publics doivent diriger la migration avec confiance.

Pour les clients de Cloudflare, en ce qui concerne nos services, aucune mesure corrective n’est nécessaire de votre part. Nous suivons de près les dernières avancées en matière d’informatique quantique et prenons des mesures proactives afin de protéger vos données. Comme nous l’avons fait par le passé, nous activerons la sécurité post-quantique par défaut, sans qu’il soit nécessaire pour vous de modifier un paramètre. Ce qui échappe à notre contrôle, c’est l’autre partie : les navigateurs, les applications et les serveurs d’origine doivent être mis à jour. Les entreprises qui acheminent leur trafic réseau via Cloudflare n’ont guère de souci à se faire : Cloudflare One offre une protection de bout en bout lors de l’acheminement du trafic sur notre infrastructure protégée par le chiffrement post-quantique.

La confidentialité et la sécurité sont des enjeux majeurs pour Internet. C’est pourquoi chaque mise à niveau post-quantique que nous développons restera disponible pour tous nos clients, dans toutes les offres – et ce, sans frais supplémentaires. Assurer la mise en œuvre par défaut de la sécurité post-quantique est l’unique moyen de protéger l’Internet à grande échelle.

Free TLS a contribué au chiffrement du web. La cryptographie post-quantique gratuite contribuera à le sécuriser pour l’avenir.

Il y a exactement 8 ans aujourd’hui, nous avons lancé le résolveur DNS public 1.1.1.1, avec l’intention d’en faire le résolveur le plus rapide du monde – et le plus privé également. Nous avions conscience que la confiance est primordiale pour un service qui gère le « répertoire téléphonique d'Internet ». C’est pourquoi, lors de son lancement, nous avons pris l'engagement sans précédent de confirmer publiquement que nous honorons notre engagement concernant les données personnelles. En 2020, plutôt que de simplement vous demander de nous croire sur parole, nous avons fait appel à un cabinet indépendant pour examiner notre travail, et nous avons fait part de notre intention de tenir à jour ces examens à l’avenir. Nous avons également invité d'autres fournisseurs à imiter notre démarche, mais, à notre connaissance, aucun autre grand résolveur public n'a demandé un examen indépendant de ses pratiques en matière de confidentialité du DNS.

Au moment de l’examen, en 2020, le résolveur 1.1.1.1 avait moins de deux ans. L’objectif de l’examen était de démontrer que nos systèmes respectaient tous les engagements que nous avions pris concernant le fonctionnement de 1.1.1.1, même ceux qui n’avaient pas d’incidence sur les données personnelles ou la confidentialité des utilisateurs.

Depuis, la pile technologique de Cloudflare s'est considérablement développée, tant en termes d'ampleur que de complexité. Par exemple, nous avons développé une plateforme entièrement nouvelle, sur laquelle reposent notre résolveur 1.1.1.1 et d’autres systèmes DNS. Nous avons donc estimé qu'il était vital d'effectuer un nouvel audit de nos systèmes, et en particulier de nos engagements en matière de confidentialité concernant le résolveur 1.1.1.1, en sollicitant un nouvel examen rigoureux et indépendant. 

Aujourd’hui, nous présentons les conclusions de notre dernier examen de confidentialité, réalisé par le même cabinet comptable – l'une des quatre plus grandes firmes d'expertise comptable du monde. L'examen indépendant réalisé par ce cabinet est disponible sur notre page de conformité.

Après la fin de l’année civile 2024, nous avons lancé notre processus complet de collecte et de préparation des pièces justificatives destinées à nos auditeurs indépendants. L'examen a duré plusieurs mois et a nécessité la participation de nombreuses équipes de Cloudflare, qui ont fourni des preuves tangibles de la mise en œuvre de nos contrôles de protection de la confidentialité. À l’issue de l’examen réalisé par les auditeurs indépendants, nous sommes heureux de vous présenter le rapport final, qui confirme que nous avons tenu nos engagements : nos systèmes garantissent bien la confidentialité promise. Plus important encore, nos garanties fondamentales en matière de confidentialité du résolveur 1.1.1.1 restent inchangées, comme l’a confirmé un examen indépendant :

• Cloudflare ne vendra ni ne partagera les données personnelles des utilisateurs du résolveur public avec des tiers, et n’utilisera pas les données personnelles du résolveur public pour envoyer de la publicité ciblée à un utilisateur.

• Cloudflare conservera et utilisera uniquement les informations demandées, et non des informations permettant d'identifier la personne demandant ces informations. 

• Les adresses IP sources sont anonymisées et supprimées sous 25 heures.

Nous tenons également à faire preuve de transparence concernant deux aspects. Premièrement, comme nous l'avons expliqué dans notre article de blog de 2020 annonçant les résultats de notre précédent examen, les paquets réseau échantillonnés de manière aléatoire (représentant au maximum 0,05 % de l'ensemble du trafic, y compris l'adresse IP de l'utilisateur du résolveur public 1.1.1.1 transmettant la requête) sont utilisés uniquement à des fins de résolution des incidents réseau et d'atténuation des attaques.

Deuxièmement, cet examen porte exclusivement sur nos engagements en matière de protection de la confidentialité. En 2020, notre premier examen portait sur l’ensemble de nos représentations : non seulement sur nos engagements en matière de confidentialité, mais également sur la manière dont nous traiterions les données anonymisées issues des journaux de transactions et de débogage (« journaux du résolveur public ») aux fins de l'exploitation légitime de notre résolveur public et de nos recherches. Au fil du temps, notre utilisation de ces données pour alimenter Cloudflare Radar, dont le lancement a eu lieu après l'examen initial de 1.1.1.1, a modifié notre approche du traitement de ces journaux, même si cela n’a aucune incidence sur les informations personnelles ou la confidentialité. 

Comme nous l'avons souligné lors du premier examen, il y a six ans de cela, nous n'avons jamais cherché à savoir ce que font les utilisateurs sur Internet, et nous avons pris des dispositions techniques qui nous en empêchent. Chez Cloudflare, nous pensons que la confidentialité devrait être la norme. En nous soumettant, de notre propre initiative, à ces examens indépendants, nous espérons établir une norme pour l'ensemble du secteur. Nous pensons que chaque utilisateur, qu'il parcoure directement le web ou qu'il déploie un agent IA pour le faire à sa place, mérite un Internet qui ne surveille pas ses activités. Par ailleurs, Cloudflare s'engage avec fermeté à honorer l'engagement pris dans notre Politique de confidentialité, conformément auquel nous ne recouperons aucune information collectée à partir des requêtes DNS adressées au résolveur 1.1.1.1 avec d'autres données de Cloudflare ou de tiers d'une manière qui permettrait d'identifier des utilisateurs finaux individuels.

Comme toujours, nous vous remercions de faire confiance à 1.1.1.1 pour accéder à Internet. Vous trouverez plus de détails concernant l'examen de la confidentialité du résolveur 1.1.1.1, ainsi que le rapport de notre expert-comptable, sur la page « Certifications et ressources en matière de conformité » de Cloudflare. Consultez la page https://developers.cloudflare.com/1.1.1.1/ pour découvrir comment faire vos premiers pas avec le résolveur DNS le plus rapide et le respectueux de la confidentialité d’Internet.

Les propriétaires de sites web ont besoin d'outils qui leur permettent de mettre un terme aux abus qui sévissent sur leur site, peu importe l'origine de ces derniers.

Lors de la Semaine anniversaire 2024, nous avons offert un outil de détection des identifiants compromis à tous nos clients, y compris ceux qui ne souscrivent à qu'à notre offre gratuite. Nous avons depuis ajouté des identifiants de détection de l'usurpation de compte à notre solution de gestion des bots afin de vous aider à identifier les bots qui s'attaquent à vos pages de connexion. 

Nous associons aujourd'hui ces puissants outils à de nouveaux. Nos mesures de contrôle des adresses e-mail à usage unique et des risques liés au courrier électronique vous aident à appliquer vos préférences en matière de sécurité aux utilisateurs qui s'inscrivent avec des adresses temporaires (une tactique courante pour la création de faux comptes et l'abus de promotions) ou dont les adresses e-mail sont jugées risquées en fonction du schéma et de l'infrastructure des e-mails envoyés à l'aide de ces dernières. Nous sommes également ravis de vous présenter notre fonction de Hashed User ID (« ID utilisateur hachés », c.-à-d. des identifiants spécifiques à un domaine et générés par hachage cryptographique des noms d'utilisateur) qui permettra à nos clients de bénéficier de davantage d'informations sur l'activité des comptes suspects et d'une meilleure capacité à atténuer le trafic potentiellement frauduleux, sans compromettre la confidentialité de l'utilisateur final.

Les nouveaux outils que nous annonçons aujourd'hui vont au-delà de l'automatisation, en vous permettant d'identifier les comportements abusifs et les identités à risque parmi les utilisateurs humains et parmi les bots. Disponible en accès anticipé, la fonctionnalité Account Abuse Protection (protection contre l'utilisation abusive des comptes) permettra à tous les clients utilisateurs de notre solution Bot Management de niveau Enterprise d'utiliser ces fonctionnalités sans frais supplémentaires pendant une période limitée, jusqu'à la mise en disponibilité générale de la suite Cloudflare Fraud Prevention, qui aura lieu plus tard dans l'année. Inscrivez-vous ici pour plus d'informations sur cette fonctionnalité en accès anticipé.

Les barrières permettant d'empêcher les comportements frauduleux sont dangereusement basses, notamment du fait de la disponibilité d'immenses ensembles de données et de l'accès à des outils automatisés capables de commettre des fraudes au niveau des comptes à grande échelle. Les propriétaires de sites web ne font pas uniquement face aux pirates informatiques, mais également à une vague de fraudes industrialisée. Nous avons souligné l'année dernière que 41 % des connexions à notre réseau s'effectuaient à l'aide d'identifiants qui avaient fuité. Ce nombre n'a eu de cesse d'augmenter après l'exposition d'une base de données contenant 16 milliards d'enregistrements et plusieurs violations à haute visibilité se sont depuis produites. 

Les utilisateurs réutilisent en outre leurs mots de passe sur plusieurs plateformes. Une simple fuite survenue il y a des années peut ainsi encore parvenir à débloquer un compte de grande valeur sur une plateforme de vente aujourd'hui, voire un compte bancaire. Notre fonctionnalité gratuite de vérification des fuites d'identifiants nous permet de vérifier si un mot de passe a fuité lors d'une violation de données survenue sur un autre service ou une autre application sur Internet. Respectueux de la confidentialité, ce service de contrôle des identifiants nous aide à protéger nos utilisateurs contre la compromission de leurs identifiants. Cloudflare procède ainsi aux contrôles sans accéder aux mots de passe des utilisateurs finaux ni les stocker en texte clair. Les mots de passe font l'objet d'un hachage (c.-à-d. qu'ils sont convertis en une chaîne de caractères aléatoires à l'aide d'un algorithme de chiffrement) avant d'être comparés à une base de données d'identifiants dont on sait qu'ils ont fuité. Si vous ne l'avez pas encore fait, nous vous invitons à activer dès maintenant notre fonctionnalité de vérification des fuites d'identifiants afin de protéger vos comptes contre le piratage facile !

L'accès à une vaste base de données d'identifiants ayant fait l'objet de fuites n'est utile que si un acteur malveillant peut les utiliser rapidement sur de nombreux sites afin d'identifier les comptes qui demeurent vulnérables du fait du phénomène de réutilisation des mots de passe. Dans l'analyse du Black Friday que nous avons publiée en 2024, nous avions observé que plus de 60 % du trafic des pages de connexion à notre réseau était automatisé. Ce chiffre montre qu'un grand nombre de bots cherchent manifestement à s'y introduire.

Afin d'aider nos clients à protéger leurs points de terminaison de connexion contre ce bombardement constant, nous avons ajouté des mesures de détection spécifiques à l'usurpation de compte (ATO, Account TakeOver) conçues pour révéler les schémas de trafic suspects. Cette démarche fait partie de l'accent que nous avons récemment placé sur les processus de détection personnalisés en fonction du client, qui nous permettent de proposer des mesures de détection des anomalies comportementales uniques à chaque client de notre solution Bot Management. Ces clients peuvent aujourd'hui voir et atténuer les tentatives d'usurpation de compte figurant dans leurs requêtes de connexion directement sur le tableau de bord des outils d'analyse de la sécurité.

^{La carte située à gauche du tableau de bord des outils d'analyse de la sécurité vous permet d'afficher les tentatives d'usurpation de compte et de déployer des mesures correctives.}

La semaine passée, nos mesures de détection de l'usurpation de compte nous ont permis d'intercepter en moyenne 6,9 milliards de tentatives de connexion suspectes par jour sur l'ensemble de notre réseau. Associées aux nombreux autres mécanismes de détection proposées par notre solution de gestion des bots Bot Management, ces mesures de détection permettent de mettre en place une défense multicouche contre les ATO et les autres attaques automatisées.

Faut-il distinguer l'automatisation, ou distinguer l'intention et l'identité ? C'est là la question. Notre réponse est « oui » et « oui », car les deux approches constituent deux couches essentielles d'une stratégie de sécurité robuste. Les acteurs malveillants opèrent désormais à une échelle jusqu'alors réservée aux services pour entreprises. Ils tirent parti des fuites massives d'identifiants, recourent à des « usines à fraude » pilotées par des humains pour prendre le contrôle d'appareils ou de lieux, et créent des identités synthétiques afin d'entretenir des milliers (voire des millions) de faux comptes à des fins de promotion et d'utilisation abusive des plateformes. Un humain équipé d'outils automatisés pourrait ainsi vider des comptes bancaires, abuser des promotions ou frauder sur des paiements (et même se livrer à toutes les activités ci-dessus).

Ces outils automatisés sont en outre plus accessibles que jamais, notamment depuis que les utilisateurs se sont davantage familiarisés avec l'utilisation des agents IA et que les navigateurs « traditionnels » depuis longtemps présents au sein de notre paysage tendent à se doter de capacités agentiques par défaut. Qu'elle émane d'un acteur isolé utilisant un agent IA ou d'une campagne de fraude coordonnée, la menace va au-delà de l'écriture d'un simple script. L'intention peut, par exemple, se révéler d'origine humaine, tandis que l'exécution sera confiée à des outils automatisés.

Découvrons ensemble certains scénarios dont nos clients nous ont parlé :

• Nous avons 1 000 nouveaux utilisateurs ce mois-ci, mais plus de la moitié d'entre eux sont liés à de fausses identités qui bénéficient d'une offre d'essai gratuit avant de disparaître.

• L'acteur malveillant s'est connecté avec le bon mot de passe, alors comment savoir qu'il ne s'agit pas du véritable utilisateur ?

• Cette entité agit à une vitesse humaine et vide les comptes.

Ces problèmes ne peuvent pas être résolus en ne s'intéressant qu'au seul volet que constitue l'évaluation de l'automatisation. L'authenticité et l'intégrité devront également faire l'objet d'un contrôle. Il s'agit là d'une faille à laquelle nos fonctionnalités de prévention de la fraude dédiées peuvent vous permettre de remédier.

Commençons par évaluer le premier point d'abus potentiel d'un compte : la création de ce dernier. La création de faux comptes ou la création massive de comptes est l'un des sujets les plus importants dans les discussions autour des comportements frauduleux affectant les sites web, car ces actions peuvent ouvrir la porte aux acteurs malveillants et leur permettre d'accéder à une application, voire à un modèle économique entier. 

Cloudflare propose à ses clients deux moyens d'évaluer, à la source, la création de comptes suspects :

1. Contrôle des adresses e-mail à usage unique : détectez les utilisateurs qui s'inscrivent à l'aide d'adresses e-mail à usage unique ou temporaires, couramment utilisées dans les scénarios d'utilisation abusive de promotions et de création de faux comptes. Ces services e-mail à usage unique permettent aux acteurs malveillants de créer des milliers de comptes « uniques » sans s'inquiéter de la gestion et de l'entretien d'une infrastructure réelle, notamment dans le cas des services sans authentification qui assurent un accès instantané sans création de compte ou permettent à l'utilisateur de disposer d'un nombre illimité d'alias. Lorsqu'ils définissent des règles d'application de leurs préférences en matière de sécurité, les clients peuvent ainsi mettre à profit ce champ binaire en choisissant de bloquer purement et simplement toutes les adresses e-mail à usage unique ou d'adresser un test à tous les utilisateurs qui tentent de créer un compte avec une adresse e-mail temporaire.

   

2. Risques liés au courrier électronique : Cloudflare analyse les schémas et l'infrastructure des e-mails afin de proposer des niveaux de risque (faible, moyen, élevé) que les clients peuvent utiliser dans leurs propres règles de sécurité. Nous savons que toutes les adresses e-mail ne se valent pas. Ainsi, une adresse au format prénom.nom@domaineconnu.com présente des caractéristiques de risque bien différentes d'une adresse de type xk7q9m2p@nouveaudomaine.xyz. Les niveaux de risque liés aux e-mails permettent aux clients d'exprimer leur tolérance au risque et à la friction lors de la création d'un compte. 

Conçues pour permettre aux propriétaires de sites web de disposer de la possibilité de protéger leur procédure de création de comptes, les fonctionnalités de contrôle des adresses e-mail temporaires et des risques liés au courrier électronique sont désormais disponibles dans nos outils d'analyse de la sécurité et nos règles de sécurité. Ces mesures de détection répondent à un problème fondamental : lorsqu'un compte commet un abus, il est déjà trop tard. Le propriétaire du site web a déjà payé des frais d'acquisition, l'utilisateur frauduleux a consommé des crédits promotionnels et les mesures correctives nécessitent un examen manuel. Le processus d'atténuation des adresses e-mail suspectes implique l'ajout d'une friction appropriée lors de l'inscription, c'est-à-dire au moment où cela importe le plus.

La compréhension des schémas d'abus nécessite de la visibilité. Pas uniquement sur le réseau, mais également sur l'activité du compte dans son ensemble. Traditionnellement, la sécurité impliquait un processus d'examen des adresses IP et des requêtes HTTP isolées afin de détecter les activités automatisées. Or, les propriétaires de sites web ne pensent pas uniquement en termes de signaux réseau, ils tiennent également compte de leurs utilisateurs et des comptes connus. C'est la raison pour laquelle nous étendons aujourd'hui notre ensemble d'outils d'atténuation afin qu'elle corresponde à la manière dont les applications sont réellement structurées, en nous concentrant sur la détection des activités frauduleuses en fonction de l'utilisateur.

Les acteurs malveillants peuvent « faire tourner » leurs adresses IP sans effort afin de masquer leurs traces. Or, le fait de les contraindre à générer de nouveaux comptes crédibles de manière répétée introduit des frictions considérables, notamment lorsque cette approche est associée à des mesures de protection du processus de création de compte. Si l'on s'intéresse à ce qui se passe au-delà de la couche réseau et que nous essayons de faire correspondre les actions frauduleuses à un compte compromis (ou auteur d'abus) donné, nous pouvons repérer les comportements ciblés liés à un unique acteur persistant et mettre un terme à ces abus. Ainsi, plutôt que de jouer au chat et à la souris avec des adresses IP « tournantes » et des proxys résidentiels, la stratégie de défense est déplacée au niveau du compte. Dès lors, nos clients peuvent atténuer les comportements abusifs en fonction de la manière dont leurs applications distinguent l'identité.

Afin de doter les propriétaires de sites web de cette capacité, Cloudflare lance sa fonction Hashed User ID (identifiants utilisateur hachés) que les clients peuvent utiliser dans leurs outils d'analyse de la sécurité, leurs règles de sécurité et leurs transformations gérées. Les ID utilisateur sont des versions spécifiques à un domaine et chiffrées de manière cryptographique des valeurs du champ Nom d'utilisateur. Chaque ID utilisateur se présente sous la forme d'un identifiant chiffré, unique et stable généré pour un nom d'utilisateur donné sur une application client donnée. Remarque importante : le nom d'utilisateur réel n'est ni enregistré ni stocké par Cloudflare dans le cadre de ce service. Comme pour le processus de contrôle des identifiants compromis et les mesures de détection de l'usurpation de compte (qui identifient le trafic de connexion avant de chiffrer les identifiants afin de les comparer), nous accordons la priorité à la confidentialité des utilisateurs finaux, tout en permettant à nos clients de prendre des mesures contre les comportements frauduleux.

L'accès à la fonction Hashed User ID permettra aux propriétaires de sites web :

• d'identifier les principaux utilisateurs (quels comptes sont les plus actifs ?) ;

• de voir lorsqu'un utilisateur unique se connecte depuis un pays d'où il ne se connecte généralement pas (ou depuis plusieurs pays au cours d'une seule journée !) ;

• d'atténuer le trafic en fonction d'un utilisateur unique, par exemple, en bloquant un utilisateur dont l'activité est historiquement suspecte ;

• d'associer les champs afin de voir à quel moment des utilisateurs tentent de se connecter aux comptes à l'aide d'identifiants qui ont fuité ;

• de découvrir les schémas ou les signaux réseau associés à certains utilisateurs.

^{La vue étendue d'un identifiant utilisateur haché unique au sein du tableau de bord des outils d'analyse de la sécurité. Les détails de l'activité de cet utilisateur unique sont affichés, notamment la position géographique de sa connexion et son navigateur.} 

Cette visibilité au niveau de l'utilisateur transforme la manière dont les propriétaires de sites web peuvent analyser et atténuer le trafic. Plutôt que d'examiner chaque requête de manière isolée, nos clients peuvent observer la représentation complète du mode opératoire suivi par les acteurs malveillants pour définir leurs cibles et se dissimuler parmi les utilisateurs légitimes.

Nous vous invitons à vous inscrire ici si vous souhaitez bénéficier de davantage d'informations sur cette fonctionnalité en accès anticipé. Tous les clients utilisateurs de notre solution Bot Management de niveau Enterprise peuvent ajouter ces nouvelles fonctionnalités de protection contre l'utilisation abusive des comptes dès aujourd'hui à leur arsenal. Nous sommes de même tout à fait disposés à ouvrir le dialogue avec tous les clients potentiels de la solution Bot Management.

Les mesures de détection des bots continueront à répondre à la question de l'automatisation et de l'intention, mais les mesures de détection des fraudes doivent également s'intéresser à la question de l'authenticité. Ensemble, elles permettent aux propriétaires de sites web de disposer d'outils complets pour lutter contre l'ensemble du spectre de l'abus de comptes. Cette suite constitue une étape de notre investissement continu envers la protection de l'ensemble du parcours de l'utilisateur, de la création de compte à la connexion, en passant par la sécurisation des paiements et l'intégrité des interactions.

Nous lançons de nouvelles fonctionnalités (comme les mesures de détection personnalisées des sujets) et rendons le processus d'identification des points de terminaison IA gratuit pour tous les clients Cloudflare (y compris les souscripteurs d'une offre gratuite, Pro et Business) afin que chacun d'eux dispose d'une visibilité concernant l'endroit où leurs outils IA sont déployés sur leurs applications en contact avec Internet.

Nous annonçons également l'élargissement de notre collaboration avec IBM, qui a choisi Cloudflare pour proposer la sécurité de l'IA à ses clients cloud. Enfin, nous avons également signé un partenariat avec Wiz pour permettre à nos clients mutuels de disposer d'une vue unifiée sur leur niveau de sécurité de l'IA.

Les opérations réalisables par les applications web traditionnelles sont définies : consulter un solde bancaire, effectuer un virement, etc. Vous pouvez rédiger des règles déterministes pour sécuriser ces interactions. 

Les applications et les agents soutenus par IA sont différents. Ils acceptent le langage naturel et génèrent des réponses imprévisibles. Il n'existe pas d'ensemble fixe d'opérations à autoriser ou à refuser, car les données saisies (entrées) et les données produites (sorties) sont probabilistes. Les acteurs malveillants peuvent manipuler les grands modèles linguistiques (LLM, Large Language Models) afin d'effectuer des actions non autorisées ou de faire fuiter des données sensibles. L'injection d'invite, la divulgation d'informations sensibles et la surconsommation de ressources ne constituent qu'une partie des risques recensés dans le Top 10 de l'OWASP consacré aux applications LLM.

Ces risques s'intensifient à mesure que les applications IA se transforment en agents. Lorsqu'une IA peut effectuer des appels d'outils (traiter un remboursement, modifier des informations sur un compte, proposer une réduction ou accéder aux données d'un client), la moindre invite malveillante devient immédiatement un incident de sécurité.

Les clients nous parlent de ce à quoi ils doivent faire face. « La plupart des équipes de Newfold Digital mettent en place leurs propres garde-fous en matière d'IA générative, mais tous les acteurs innovent tellement vite que des lacunes finiront inévitablement par apparaître », déclare Rick Radinger, Principal Systems Architect chez Newfold Digital, l'entreprise qui exploite Bluehost, HostGator et Domain.com.

Nous avons développé la solution AI Security for Apps pour répondre à cette problématique. Que vous utilisiez un modèle tiers ou que vous hébergiez le vôtre, la solution vient se placer devant vos applications soutenues par IA afin de protéger vos ressources dans le cadre du proxy inverse proposé par Cloudflare. Elle vous aide ainsi (1) à identifier les applications soutenues par IA sur l'ensemble de vos propriétés web, (2) à détecter les comportements malveillants ou non conformes à vos politiques sur ces points de terminaison et (3) à atténuer les menaces à l'aide du générateur de règles WAF que vous connaissez déjà.

Avant de pouvoir protéger vos applications soutenues par LLM, vous devez savoir à quel endroit elles sont utilisées. Les équipes de sécurité nous indiquent souvent qu'elles ne disposent pas d'une vision complète concernant les déploiements d'outils IA sur l'ensemble de leur parc applicatif, notamment à l'heure où le marché des LLM évolue et où les développeurs changent de modèles et de fournisseurs. 

La solution AI Security for Apps identifie automatiquement les points de terminaison assistés par LLM sur l'ensemble de vos propriétés web, indépendamment de l'endroit où ils sont hébergés ou du modèle utilisé. À compter d'aujourd'hui, cette fonctionnalité est gratuite pour tous les clients Cloudflare, y compris les souscripteurs d'une offre gratuite, Pro ou Business. 

^{La page du tableau de bord Cloudflare consacrée aux ressources web affiche ici deux exemples de points de terminaison étiquetés sous la dénomination cf-llm.}

L'identification automatique de ces points de terminaison nécessite plus que la simple mise en correspondance de schémas d'adressage courants, comme /chat/completions. De nombreuses applications assistées par l'IA ne disposent pas d'une interface de discussion, comme les applications de recherche de produits, les outils d'évaluation de propriétés immobilières ou les moteurs de recommandation, par exemple. Nous avons ainsi développé un système de détection qui s'intéresse au comportement des points de terminaison et pas à leur dénomination. Une quantité suffisante de trafic valide est requise pour identifier en toute confiance les points de terminaison soutenus par IA.

Les points de terminaison identifiés par ce processus seront visibles sous Security → Web Assets (Sécurité → Ressources web) et étiquetés sous la dénomination cf-llm. Pour les clients titulaires d'une offre gratuite, l'identification des points de terminaison sera lancée lorsque vous accéderez pour la première fois à la page Discovery (Identification). Pour ceux qui ont souscrit une offre payante, le processus d'identification s'effectue automatiquement en arrière-plan, à intervalles réguliers. Vous pourrez examiner immédiatement vos points de terminaison assistés par IA une fois ces derniers identifiés.

Les mesures de détection de la solution AI Security for Apps suivent l'approche « Active en permanence » concernant la gestion du trafic vers vos points de terminaison assistés par IA. Chaque invite passe par plusieurs modules de détection conçus pour révéler la présence d'attaques par injection d'invite, l'exposition d'informations d'identification personnelle (PII, Personally Identifiable Information) et les sujets sensibles ou toxiques. Que l'invite soit malveillante ou non, les résultats sont joints sous forme de métadonnées que vous pouvez utiliser au sein de vos règles WAF personnalisées afin de mieux appliquer vos politiques. Nous cherchons en permanence des moyens de tirer parti de notre réseau mondial (qui voit passer le trafic d'environ 20 % d'Internet) afin d'identifier les nouveaux schémas d'attaque sur des millions de sites web avant qu'ils n'atteignent le vôtre.

Le produit est doté d'une fonctionnalité de détection intégrée des menaces courantes : les attaques par injection d'invite, l'extraction d'informations d'identification personnelle et les sujets toxiques. Chaque entreprise dispose toutefois de sa propre définition des sujets contraires à ses politiques. Une entreprise de services financiers peut ainsi avoir besoin de détecter les discussions traitant de titres spécifiques. Un acteur de la santé pourrait avoir besoin de signaler les conversations qui concernent les données des patients. Un commerçant pourrait souhaiter savoir à quel moment les clients s'informent sur les produits de ses concurrents.

La nouvelle fonctionnalité de personnalisation des sujets vous permet de définir ces catégories. Vous spécifiez le sujet, nous inspectons l'invite et générons un score de pertinence que vous pouvez utiliser comme vous le décidez (journalisation, blocage ou traitement). Notre objectif consiste à créer un outil extensible qui s'adapte à l'ensemble de vos scénarios d'utilisation.

^{Un score de pertinence des invites proposé au sein de la solution AI Security for Apps}

La solution AI Security for Apps met en place des garde-fous autour des invites non sécurisées avant qu'elles ne puissent entrer en contact avec votre infrastructure. Pour exécuter les mesures de détection avec précision et assurer une protection en temps réel, nous devons d'abord identifier l'invite qui figure dans le contenu malveillant de la requête. Les invites peuvent résider à n'importe quel endroit du corps d'une requête et les fournisseurs de LLM structurent leurs API de manière différente. OpenAI et la plupart des fournisseurs utilisent le format $.messages[*].content pour les réponses par chat. L'API de traitement par lots (batch) d'Anthropic imbrique les invites au sein de la formule $.requests[*].params.messages[*].content. Votre outil d'évaluation des biens personnalisé pourrait utiliser la forme $.property_description.

Nous prenons actuellement en charge les formats standard utilisés par OpenAI, Anthropic, Google Gemini, Mistral, Cohere, xAI, DeepSeek et d'autres. Lorsque nous ne parvenons pas à obtenir une correspondance avec un modèle connu, nous appliquons la posture de sécurité par défaut et exécutons le processus de détection sur l'ensemble du corps de la requête. Cette approche peut introduire des faux positifs lorsque le contenu malveillant contient des champs sensibles, mais qui n'alimentent pas directement un modèle IA (un champ $.customer_name situé à côté de l'invite réelle pourrait déclencher inutilement les mesures de détection des PII, par exemple).

Vous pourrez bientôt définir vos propres expressions JSONPath afin de nous indiquer exactement à quel endroit trouver l'invite. Cette opération nous permettra de réduire le nombre de faux positifs et d'améliorer la précision de nos mesures de détection. Nous sommes également en train de développer une capacité d'apprentissage des invites qui s'adaptera automatiquement à la structure de votre application au fil du temps.

Une fois une menace identifiée et évaluée, vous pouvez la bloquer, la journaliser ou proposer des réponses personnalisées à l'aide du même moteur de règles WAF que celui que vous utilisez déjà pour le reste de vos activités de sécurité des applications. La puissance de la plateforme partagée Cloudflare réside dans la possibilité de combiner des signaux spécifiques à l'IA avec tout ce que nous savons d'une requête, c'est-à-dire des connaissances représentées par les centaines de champs du pare-feu WAF. Une tentative d'injection d'invite est déjà suspecte par essence. Une tentative d'injection issue d'une adresse IP qui a sondé votre page de connexion, utilise les empreintes numériques d'un navigateur associé à des attaques précédentes et « fait tourner » les adresses à l'aide d'un botnet entre dans une catégorie tout à fait différente. Une solution dédiée qui ne voit que la couche IA ne peut pas établir ces connexions.

Cette couche de sécurité unifiée est exactement ce dont Newfold Digital a besoin pour identifier, étiqueter et protéger les points de terminaison IA. Comme le précise Radinger : « Nous sommes impatients d'utiliser cette technologie sur l'ensemble de ces projets en tant que mécanisme de sécurité. »

La solution AI Security for Applications sera également disponible au sein de l'écosystème en pleine expansion de Cloudflare, notamment grâce à l'intégration avec IBM Cloud. Les utilisateurs finaux peuvent déjà se procurer des solutions avancées de sécurité des applications par l'intermédiaire de la plateforme IBM Cloud Internet Services (CIS) et les gérer directement depuis leur compte IBM Cloud. 

Nous avons également conclu un partenariat avec Wiz afin de connecter la solution AI Security for Applications à leur plateforme Wiz AI Security. Nous pourrons ainsi proposer à nos clients mutuels une vue unifiée sur leur stratégie de sécurité de l'IA, de l'identification des modèles et des agents dans le cloud aux garde-fous protégeant la couche applicative déployés à la périphérie du réseau.

La solution AI Security for Apps est désormais disponible pour les clients Enterprise de Cloudflare. Contactez l'équipe chargée de votre compte pour essayer le produit ou découvrez-le en action dans le cadre d'un tour d'horizon en autonomie.

Si vous êtes titulaires d'une offre gratuite, Pro ou Business, vous pouvez utiliser la fonctionnalité d'identification des points de terminaison IA dès aujourd'hui. Connectez-vous à votre tableau de bord et cliquez sur Security → Web Assets (Sécurité → Ressources web) pour découvrir les points de terminaison que nous avons identifiés. Restez à l'écoute : nous prévoyons de mettre l'ensemble des fonctionnalités de la solution AI Security for Apps prochainement à la disposition de tous nos clients, quel que soit leur niveau d'offre.

Consultez notre documentation pour plus d'informations sur la configuration.

Le quatrième trimestre 2025 s'est caractérisé par un bombardement sans précédent lancé par le botnet Aisuru-Kimwolf. Cette campagne d'attaques DDoS a été surnommée « The Night Before Christmas » (la veille de Noël). Les clients de Cloudflare (de même que le tableau de bord et l'infrastructure de notre plateforme) se sont ainsi retrouvés la cible d'attaques DDoS HTTP hypervolumétriques dépassant les 200 millions de requêtes par seconde (Mr/s), quelques semaines seulement après une attaque record mesurée à 31,4 térabits par seconde (Tb/s).

1. Le nombre d'attaques DDoS s'est accru de 121 % en 2025 pour atteindre une moyenne de 5 376 attaques atténuées automatiquement par heure.

2. Hong Kong a gagné 12 places au classement lors du dernier trimestre 2025 pour devenir la deuxième cible la plus touchée par les attaques DDoS à travers le monde. Le Royaume-Uni a également vu sa position bondir de 36 places pour devenir la sixième cible la plus attaquée.

3. Les Android TV infectées (un composant du botnet Aisuru-Kim Wolf) ont bombardé le réseau Cloudflare d'attaques DDoS HTTP hypervolumétriques, tandis que le secteur des télécommunications s'est imposé comme le secteur le plus attaqué.

Le nombre total d'attaques DDoS a plus que doublé en 2025, avec un total incroyable de 47,1 millions. Ces chiffres ont explosé ces dernières années : le nombre d'attaques DDoS a ainsi bondi de 236 % entre 2023 et 2025.

Cloudflare a atténué en moyenne 5 376 attaques DDoS par heure en 2025, dont 3 925 attaques DDoS sur la couche réseau et 1 451 attaques DDoS HTTP. 

C'est au niveau des attaques DDoS sur la couche réseau que nous avons observé la croissance la plus importante. Le nombre de ces dernières a plus que triplé par rapport à l'année précédente. Cloudflare a ainsi atténué 34,4 millions d'attaques DDoS sur la couche réseau en 2025, contre 11,4 millions en 2024.

Une part considérable des attaques sur la couche réseau (environ 13,5 millions) s'en sont directement prises à l'infrastructure de Cloudflare, ainsi qu'à l'infrastructure Internet mondiale protégée par notre service Cloudflare Magic Transit, dans le cadre d'une campagne d'attaques DDoS de 18 jours qui a débuté au premier trimestre 2025. Parmi ces attaques, 6,9 millions visaient les clients de Magic Transit, tandis que les 6,6 millions restants visaient directement Cloudflare. 

Ces attaques faisaient partie d'une campagne DDoS multivectorielle regroupant des attaques SYN flood, des attaques DDoS générées par Mirai et des attaques par amplification SSDP, pour n'en citer que quelques exemples. Nos systèmes ont détecté et atténué ces attaques automatiquement. Nous n'avons en réalité découvert la campagne qu'au cours de la phase de préparation de notre rapport sur les menaces DDoS au premier trimestre 2025. Un véritable exemple de l'efficacité des mesures d'atténuation DDoS de Cloudflare !

Lors du dernier trimestre 2025, le nombre d'attaques DDoS a augmenté de 31 % par rapport au trimestre précédent et de 58 % par rapport à 2024. Les attaques DDoS sur la couche réseau ont alimenté cette croissance. Au quatrième trimestre 2025, les attaques DDoS sur la couche réseau représentaient ainsi 78 % de l'ensemble des attaques DDoS. Le nombre d'attaques DDoS HTTP est resté le même, mais leur ampleur a atteint des débits que nous n'avions pas observés depuis la campagne d'attaques DDoS HTTP/2 Rapid Reset de 2023. Ces récentes flambées d'attaques ont été lancées par le botnet Aisuru-Kimwolf, que nous aborderons dans la section suivante. 

Le vendredi 19 décembre 2025, le botnet Aisuru-Kimwolf a commencé à bombarder l'infrastructure et les clients de Cloudflare sous un flot d'attaques DDoS hypervolumétriques. L'élément novateur de cette campagne résidait dans sa taille. En effet, les attaques DDoS HTTP hypervolumétriques lancées par le botnet affichaient des débits supérieurs à 20 millions de requêtes par seconde (Mr/s).

Le botnet Aisuru-Kimwolf se présente sous la forme d'un ensemble massif d'appareils infectés par des logiciels malveillants, principalement des téléviseurs connectés Android TV. Composé d'environ 1 à 4 millions d'hôtes infectés, il est capable de lancer des attaques DDoS susceptibles de paralyser les infrastructures essentielles, d'entraîner l'arrêt de la plupart des solutions existantes de protection contre les attaques DDoS dans le cloud, voire de perturber la connectivité de pays entiers.

Les systèmes autonomes de défense contre les attaques DDoS de Cloudflare ont détecté et atténué l'ensemble des attaques tout au long de la campagne : 384 attaques intensives du point de vue des paquets, 329 attaques intensives du point de vue des bits et 189 attaques intensives du point de vue des requêtes, pour un total de 902 attaques DDoS hypervolumétriques, soit une moyenne de 53 attaques par jour.

Les tailles moyennes des attaques DDoS hypervolumétriques observées pendant la campagne étaient de 3 Gp/s, 4 Tb/s et 54 Mr/s (respectivement, pour chacun des indicateurs précédents). Les débits maximaux enregistrés pendant la campagne étaient de 9 Gp/s, 24 Tb/s et 205 Mr/s.

Pour vous donner un ordre d'idée, l'ampleur d'une attaque DDoS mesurée à 205 Mr/s est comparable à ce qui se produirait si l'ensemble des habitants du Royaume-Uni, de l'Allemagne et de l'Espagne saisissaient tous simultanément une adresse de site web avant d'appuyer sur « Entrée » lors de la même seconde.

Malgré son caractère spectaculaire, la campagne « The Night Before Christmas » ne représentait qu'une petite partie des attaques DDoS hypervolumétriques que nous avons observées tout au long de l'année.

Cloudflare a constaté un accroissement continu du nombre d'attaques DDoS hypervolumétriques tout au long de l'année 2025. Au quatrième trimestre 2025, ce type d'attaques a ainsi augmenté de 40 % par rapport au trimestre précédent.

Si le nombre d'attaques a augmenté au cours de l'année 2025, la taille de ces attaques s'est également accrue de plus de 700 %, l'une d'elles ayant même culminé à 31,4 Tb/s lors d'une attaque DDoS qui n'a toutefois duré que 35 secondes. Le graphique ci-dessous présente la croissance rapide en taille des attaques DDoS observées et bloquées par Cloudflare. Chacune d'elles constitue d'ailleurs un record mondial, c'est-à-dire l'attaque la plus volumineuse jamais révélée publiquement par une entreprise à l'époque.

Comme toutes les autres attaques, l'attaque DDoS mesurée à 31,4 Tb/s a été détectée et atténuée automatiquement par le système autonome de défense contre les attaques DDoS proposé par Cloudflare, qui s'est révélé capable de s'adapter et de concentrer rapidement ses efforts sur les botnets du type d'Aisuru-Kimwolf.

La plupart des attaques DDoS hypervolumétriques visaient des clients Cloudflare du secteur des télécommunications, des fournisseurs d'accès Internet et des opérateurs. Les clients Cloudflare du secteur des jeux vidéo et les clients fournisseurs de services d'IA générative ont également été fortement touchés. Enfin, l'infrastructure de Cloudflare s'est elle-même retrouvée la cible de plusieurs vecteurs d'attaque, comme les floods HTTP, les attaques DNS et les floods UDP.

Lorsque l'on analyse les attaques DDoS de toutes les tailles, on s'aperçoit que le secteur des télécommunications, des fournisseurs d'accès Internet et des opérateurs s'est également révélé le plus touché. C'est le secteur des technologies et des services de l'information qui détenait ce titre regrettable par le passé.

Les secteurs des jeux de hasard/casinos, ainsi que celui des jeux vidéo, se sont classés respectivement en troisième et quatrième position. Les changements les plus importants survenus dans le top 10 concernaient le secteur des logiciels et celui des services aux entreprises, qui ont tous deux progressé de plusieurs places dans le classement. 

Les secteurs les plus visés sont définis par leur rôle d'infrastructure essentielle, d'épine dorsale pour les autres entreprises, ou par leur sensibilité financière immédiate et substantielle aux épisodes d'interruption de service et à la latence.

En ce qui concerne les pays les plus attaqués à travers le monde, le panorama des attaques DDoS a connu à la fois une stabilité prévisible et des fluctuations spectaculaires. En conservant une place dans le classement des cinq premiers pays visés, la Chine, l'Allemagne, le Brésil et les États-Unis ont démontré un attrait persistant pour les acteurs malveillants. 

Hong Kong a réalisé une avancée significative, en gagnant douze places pour se hisser à la deuxième position. L'événement majeur du trimestre s'est toutefois révélé l'ascension fulgurante du Royaume-Uni, qui a bondi de 36 places au classement pour s'inscrire en 6e position des pays les plus attaqués.  

Le Vietnam a conservé sa place en tant que septième pays le plus fréquemment visé par les attaques, suivi par l'Azerbaïdjan (en huitième position), l'Inde (neuvième) et Singapour (dixième).

Le Bangladesh a détrôné l'Indonésie en tant que plus importante source d'attaques DDoS au quatrième trimestre 2025. L'Indonésie a chuté à la troisième place après avoir passé un an en tête des sources d'attaques DDoS. L'Équateur a également gagné deux places pour devenir la deuxième source la plus importante d'attaques DDoS.

De manière remarquable, l'Argentine a progressé de 20 places pour s'installer à la quatrième position du classement des sources d'attaques DDoS. Hong Kong a progressé de trois rangs, pour atteindre la cinquième place. L'Ukraine arrivait en sixième position, suivie par le Vietnam, Taïwan, Singapour et le Pérou.

Le classement des 10 premiers réseaux à l'origine d'attaques se présente comme une liste des géants de l'Internet. Il révèle ainsi une histoire fascinante quant à l'anatomie des attaques DDoS modernes. Le fil rouge apparaît de manière évidente : les acteurs malveillants tirent parti des infrastructures réseau les plus accessibles et les plus puissantes du monde, qui se composent principalement de grands services accessibles au public. 

Nous remarquons que la plupart des attaques DDoS proviennent d'adresses IP associées à des plateformes d'informatique cloud et à des fournisseurs d'infrastructure cloud, comme DigitalOcean (AS 14061), Microsoft (AS 8075), Tencent (AS 132203), Oracle (AS 31898) et Hetzner (AS 24940). Ce constat démontre le lien fort qui existe entre les machines virtuelles facilement accessibles et les attaques à volume élevé. Fortement concentrées aux États-Unis, ces sources cloud sont suivies de près par une présence significative d'attaques issues d'adresses IP associées à des fournisseurs de télécommunications traditionnels. Ces entreprises de télécommunications principalement situées dans la région Asie-Pacifique (qui inclut le Vietnam, la Chine, la Malaisie et Taïwan) viennent compléter le reste du top 10.

Cette diversité géographique et organisationnelle confirme la réalité bidimensionnelle des attaques. Si l'échelle même des sources d'attaques les plus importantes tire souvent son origine de hubs cloud internationaux, le problème s'avère incontestablement mondial, car les attaques transitent sur les voies les plus essentielles d'Internet, partout dans le monde. Nous observons ainsi la présence de milliers d'ASN sources différents dans de nombreuses attaques DDoS. Ce point met en évidence la répartition véritablement mondiale des nœuds de botnets.

Nous tirons parti de la position avantageuse de Cloudflare pour aider les fournisseurs d'hébergement, les plateformes d'informatique cloud et les fournisseurs d'accès Internet à identifier et à éliminer les adresses IP/comptes malveillants à l'origine des attaques DDoS en leur proposant notre flux d'informations gratuit sur les menaces liées aux botnets (DDoS Botnet Threat Feed for Service Providers).

Plus de 800 réseaux à travers le monde entier se sont inscrits à ce flux et nous avons déjà constaté une excellente collaboration s'établir au sein de la communauté pour éliminer les nœuds de botnets.

Les attaques DDoS connaissent une croissance rapide, tant en termes de sophistication que d'ampleur, et dépassent désormais tout ce qui était imaginable jusqu'ici. L'évolution du panorama des menaces constitue un défi considérable pour les nombreuses entreprises qui cherchent à suivre le rythme. Les entreprises qui font actuellement appel à des équipements d'atténuation sur site ou aux services de centres de nettoyage à la demande pourraient bénéficier d'une réévaluation de leur stratégie de défense.

Peu importe la taille, la durée ou le volume des attaques, Cloudflare s'efforce de proposer une protection DDoS gratuite et illimitée à l'ensemble de ses clients en tirant parti de son vaste réseau mondial et de ses systèmes autonomes d'atténuation des attaques DDoS.

Portée par une mission visant à défendre Internet, l'équipe de Cloudforce One tire parti des données télémétriques du réseau mondial Cloudflare (qui protège près de 20 % du web) afin de soutenir la recherche sur les menaces et d'assurer une réponse opérationnelle, deux axes qui permettront par la suite de protéger les systèmes essentiels de millions d'entreprises à travers le monde.

Le 18 novembre 2025, le réseau de Cloudflare a subi des défaillances importantes dans l’acheminement du trafic réseau pendant environ deux heures et dix minutes. Près de trois semaines plus tard, le 5 décembre 2025, notre réseau a de nouveau été incapable d’assurer le trafic pour 28 % des applications protégées par notre réseau pendant environ 25 minutes.

Nous avons publié des articles de blog détaillés de type post-mortem à la suite de ces deux incidents, mais nous savons que nous devons en faire davantage pour regagner votre confiance. Aujourd’hui, nous partageons des informations détaillées sur les travaux actuellement menés chez Cloudflare afin d’éviter que des pannes de ce type ne se reproduisent.

Nous avons baptisé ce plan « Code Orange : Fail Small » (Code Orange : limiter l’impact des défaillances), ce qui reflète notre objectif de rendre notre réseau plus résilient face aux erreurs ou aux défaillances susceptibles d’entraîner une panne majeure. Un « Code Orange » signifie que ce projet est prioritaire par rapport à tout le reste. Pour rappel, nous n’avons déclaré un « Code Orange » chez Cloudflare qu’une seule fois auparavant, à la suite d’un autre incident majeur ayant nécessité une mobilisation prioritaire de l’ensemble de l’entreprise. Nous estimons que les événements récents exigent le même niveau d’attention.  Code Orange nous permet de concrétiser cet objectif en autorisant, si nécessaire, une collaboration transversale entre les équipes, tout en suspendant les autres projets.

Le programme Code Orange s’articule autour de trois grands axes :

• Imposer des déploiements contrôlés pour toute modification de configuration propagée sur le réseau, comme nous le faisons déjà aujourd’hui pour les versions logicielles.

• Examiner, améliorer et tester les modes de défaillance de tous les systèmes qui traitent le trafic réseau, afin de garantir qu’ils adoptent un comportement clairement défini dans toutes les situations, y compris en cas d’états d’erreur imprévus.

• Faire évoluer nos procédures internes de type « break glass »* et supprimer toute dépendance circulaire, afin que nous (tout comme nos clients) puissions agir rapidement et accéder à tous les systèmes sans difficulté lors d’un incident.

Ces projets apporteront des améliorations itératives au fur et à mesure de leur avancement, plutôt qu’un changement unique et massif à leur terme. Chaque mise à jour individuelle contribuera à renforcer la résilience de Cloudflare. À terme, nous nous attendons à ce que le réseau Cloudflare soit nettement plus résilient, y compris face à des problèmes similaires à ceux qui ont déclenché les incidents mondiaux que nous avons connus au cours des deux derniers mois.

Nous savons que ces incidents sont difficiles à vivre pour nos clients et pour Internet dans son ensemble. Ils nous embarrassent profondément, et c’est précisément pour cette raison que ce travail constitue la priorité absolue de toutes les équipes chez Cloudflare.

^{* Les procédures « break glass » chez Cloudflare permettent à certaines personnes d’élever temporairement leurs privilèges, dans des circonstances bien précises, afin d’effectuer des actions urgentes pour résoudre des situations particulièrement graves.}

Lors du premier incident, les utilisateurs qui visitaient un site client via Cloudflare voyaient des pages d’erreur indiquant que Cloudflare ne pouvait pas fournir de réponse à leur requête. Lors du second incident, ils voyaient des pages blanches.

Les deux défaillances ont suivi un schéma similaire. Dans les instants précédant chaque incident, nous avons déployé instantanément une modification de configuration dans nos datacenters, répartis dans des centaines de villes à travers le monde.

Le changement de novembre consistait en une mise à jour automatique de notre classificateur Bot Management. Nous exploitons différents modèles d’intelligence artificielle qui apprennent à partir du trafic transitant par notre réseau afin de créer des mécanismes de détection capables d’identifier les bots. Nous mettons constamment ces systèmes à jour pour garder une longueur d’avance sur les acteurs malveillants qui tentent de contourner nos protections de sécurité pour atteindre les sites de nos clients.

Lors de l’incident de décembre, alors que nous cherchions à protéger nos clients contre une vulnérabilité affectant le framework open source populaire React, nous avons déployé une modification d’un outil de sécurité utilisé par nos analystes afin d’améliorer nos signatures. Comme pour les mises à jour urgentes liées à la gestion des bots, nous devions agir rapidement pour devancer les attaquants qui cherchaient à exploiter cette vulnérabilité. Ce changement a déclenché le début de l’incident.

Ce schéma a mis en évidence une lacune importante dans notre manière de déployer les changements de configuration chez Cloudflare, par rapport à notre processus de publication des mises à jour logicielles. Lorsque nous publions de nouvelles versions logicielles, nous le faisons de manière contrôlée et surveillée. Chaque nouvelle version binaire doit franchir avec succès plusieurs étapes de validation avant de pouvoir prendre en charge le trafic à l’échelle mondiale. Nous déployons la mise à jour auprès des employés, puis l’étendons progressivement auprès d’un pourcentage croissant de clients dans le monde, en commençant par les utilisateurs gratuits. Si nous détectons une anomalie à une étape quelle qu’elle soit, nous pouvons revenir en arrière sans aucune intervention humaine.

Nous n’avons pas appliqué cette méthodologie aux changements de configuration. Contrairement aux mises à jour du logiciel central qui alimente notre réseau, les changements de configuration consistent à modifier les paramètres qui déterminent le comportement de ce logiciel, et ils peuvent être appliqués instantanément. Nous offrons d’ailleurs cette même capacité à nos clients : lorsqu’un paramètre est modifié dans Cloudflare, le changement se propage à l’échelle mondiale en quelques secondes.

Si cette rapidité présente des avantages, elle comporte également des risques que nous devons corriger. Les deux incidents récents ont démontré que toute modification affectant la manière dont nous assurons le trafic sur notre réseau doit être abordée avec le même niveau de prudence et de tests que les changements apportés au logiciel lui-même.

Notre capacité à déployer des modifications de configuration à l’échelle mondiale en quelques secondes a été le point commun principal des deux incidents. Dans les deux cas, une mauvaise configuration a mis notre réseau hors service en quelques secondes.

L’introduction de déploiements contrôlés pour nos configurations, comme nous le faisons déjà pour les mises à jour logicielles, constitue le chantier le plus important de notre plan Code Orange.

Les changements de configuration chez Cloudflare se propagent très rapidement sur le réseau. Lorsqu’un utilisateur crée un enregistrement DNS ou une règle de sécurité, cet enregistrement ou cette règle atteint 90 % des serveurs du réseau en quelques secondes. Cette rapidité est assurée par un composant logiciel que nous appelons en interne Quicksilver.

Quicksilver est également utilisé pour toute modification de configuration requise par nos équipes internes. Cette rapidité est une fonctionnalité : nous pouvons réagir et mettre à jour le comportement de notre réseau à l’échelle mondiale très rapidement. Cependant, lors des deux incidents, cette vitesse a provoqué la propagation d’un changement catastrophique sur l’ensemble du réseau en quelques secondes, sans passer par les étapes de validation nécessaires.

Si la possibilité de déployer presque instantanément des changements sur notre réseau est utile dans de nombreux cas, elle est rarement indispensable. Des travaux sont en cours pour traiter les modifications de configuration de la même manière que le code, en introduisant des déploiements contrôlés via Quicksilver pour toute modification de configuration.

Nous publions des mises à jour logicielles sur notre réseau plusieurs fois par jour grâce à ce que nous appelons notre système de déploiement piloté par ’état de santé (Health Mediated Deployment, ou HMD). Dans ce cadre, chaque équipe Cloudflare qui possède un service (un logiciel déployé sur notre réseau) doit définir les indicateurs permettant de déterminer si le déploiement a réussi ou échoué, le plan de déploiement et les actions à entreprendre en cas d’échec.

Différents services auront des variables légèrement différentes. Certains pourraient demander des temps d’attente plus longs avant de passer à d’autres datacenters, tandis que d’autres pourraient avoir des tolérances plus faibles pour les taux d’erreur, même si cela génère des signaux faussement positifs.

Une fois le déploiement lancé, notre kit HMD progresse soigneusement selon le plan défini, en surveillant chaque étape avant de continuer. En cas d’échec, la restauration se déclenche automatiquement et l’équipe peut être alertée si nécessaire.

À la fin du plan Code Orange, les mises à jour de configuration suivront le même processus. Nous nous attendons à ce que cela nous permette de détecter rapidement les problèmes similaires à ceux survenus lors des deux derniers incidents, bien avant qu’ils ne deviennent des problèmes généralisés.

Bien que nous soyons optimistes sur le fait qu’un meilleur contrôle des changements de configuration permettra de détecter davantage de problèmes avant qu’ils ne se transforment en incidents, nous savons que des erreurs peuvent et vont se produire. Lors des deux incidents, des erreurs sur une partie de notre réseau se sont propagées à la majorité de notre infrastructure, y compris au plan de contrôle sur lequel les clients s’appuient pour configurer l’utilisation de Cloudflare.

Nous devons penser en termes de déploiements gradués et prudents, et non seulement en termes de progression géographique (étendre à davantage de datacenters) ou en termes de progression de la population (étendre aux employés et selon les types de clients). Nous devons également prévoir des déploiements plus sûrs qui isolent les défaillances entre services (passer d’un produit comme notre service Bot Management à un autre produit non lié, comme notre tableau de bord).

À cet effet, nous sommes en train de réviser les contrats d’interface entre chaque produit et service critique de notre réseau pour nous assurer que : a) nous anticipons les défaillances entre chaque interface ; et b) nous gérons ces défaillances de la manière la plus raisonnable possible. 

Pour revenir à l’incident concernant le service Bot Management, il y avait au moins deux interfaces clés que nous aurions pu gérer de manière à ce qu’aucun client ne soit probablement impacté, si nous avions anticipé les défaillances. La première était l’interface qui lisait le fichier de configuration corrompu. Au lieu de provoquer une défaillance, il aurait dû exister un ensemble de valeurs par défaut validées permettant au trafic de continuer à circuler sur notre réseau, tandis que, dans le pire des cas, nous aurions seulement perdu le réglage en temps réel alimentant nos modèles de machine learning pour la détection des bots. La deuxième interface se situait entre le logiciel central de notre réseau et le module Bot Management lui-même. En cas de défaillance du module de gestion des robots (comme cela s’est produit), nous n’aurions pas dû bloquer le trafic par défaut. Nous aurions pu définir un comportement par défaut plus raisonnable, laissant passer le trafic avec une classification approximative, mais acceptable.

Pendant les incidents, il nous a fallu trop de temps pour résoudre les problèmes. Dans les deux cas, cela a été aggravé par nos systèmes de sécurité qui empêchaient certains membres de l’équipe d’accéder aux outils nécessaires, et, dans certains cas, des dépendances circulaires nous ont ralentis, car certains systèmes internes étaient également indisponibles.

En tant qu’entreprise de sécurité, tous nos outils sont protégés par des couches d’authentification avec des contrôles d’accès précis, afin de sécuriser les données clients et d’éviter tout accès non autorisé. Cela est nécessaire, mais nos processus et systèmes actuels nous ont ralentis lorsque la vitesse était une priorité absolue.

Les dépendances circulaires ont également affecté l’expérience client. Par exemple, lors de l’incident du 18 novembre, Turnstile, notre solution anti-bot sans CAPTCHA, est devenue indisponible. Comme nous utilisons Turnstile pour la connexion au tableau de bord Cloudflare, les clients n’ayant pas de session active ni de jeton d’API n’ont pas pu se connecter à Cloudflare au moment où ils en avaient le plus besoin pour effectuer des changements critiques.

Notre équipe va réviser et améliorer toutes les procédures et technologies « break glass » afin de garantir que, lorsque nécessaire, nous puissions accéder aux bons outils le plus rapidement possible tout en respectant nos exigences de sécurité. Cela inclut la révision et la suppression des dépendances circulaires, ou la possibilité de les « contourner » rapidement en cas d’incident. Nous allons également augmenter la fréquence de nos exercices de formation, afin que les processus soient bien compris par toutes les équipes avant toute situation de crise potentielle. 

Bien que nous n’ayons pas détaillé dans cet article l’ensemble des travaux internes, les axes décrits ci-dessus représentent les priorités principales sur lesquelles les équipes doivent se concentrer. Chacun de ces axes correspond à un plan détaillé impliquant presque tous les produits et équipes d’ingénierie de Cloudflare. Nous avons beaucoup de travail devant nous.

D’ici la fin du premier trimestre, et pour une grande partie avant cette date, nous prévoyons de :

• garantir que tous les systèmes de production sont couverts par des déploiements pilotés par l’état de santé (HMD) pour la gestion des configurations ;

• mettre à jour nos systèmes afin qu’ils respectent les modes de défaillance appropriés pour chaque ensemble de produits ;

• nous assurer que nous avons mis en place des processus garantissant que les bonnes personnes ont le bon accès pour appliquer les remédiations appropriées lors d’une urgence.

Certaines de ces mesures seront perpétuelles. Nous devrons toujours améliorer la gestion des dépendances circulaires lors du lancement de nouveaux logiciels, et nos procédures « break glass » devront évoluer en fonction des changements de nos technologies de sécurité.

Nous avons échoué auprès de nos utilisateurs et d’Internet dans son ensemble lors de ces deux derniers incidents. Nous avons beaucoup de travail pour réparer ces erreurs. Nous prévoyons de partager des mises à jour régulières au fur et à mesure de l’avancement de ce travail et nous apprécions les questions et les retours que nous avons reçus de la part de nos clients et partenaires.

Cet éclairage unique découle directement de notre visibilité sur le réseau mondial Cloudflare. Présent dans 330 villes réparties dans plus de 125 pays et régions, ce dernier traite en moyenne plus de 81 millions de requêtes HTTP par seconde (avec des pics de plus de 129 millions de requêtes HTTP par seconde) pour les millions de propriétés web de nos clients et répond également à près de 67 millions de requêtes DNS par seconde (serveur de référence + résolveur). Cloudflare Radar s'appuie sur les données générées par ces services web et DNS, combinées à d'autres ensembles de données complémentaires, pour proposer des informations en quasi-temps réel sur les tendances et les schémas relatifs au trafic, aux bots, à la sécurité et à la connectivité DNS que nous observons sur Internet. 

Notre bilan annuel Radar Year in Review tire parti de cette observabilité pour proposer un retour sur l'année 2025 plutôt qu'une vue en temps réel. Les divers outils interactifs (tableaux, graphiques et cartes) incorporés au rapport vous permettent d'explorer et de comparer les tendances et les mesures sélectionnées d'une année sur l'autre, dans toutes les zones géographiques, mais aussi de partager et d'intégrer ses graphiques à vos pages. 2

Le bilan Year In Review 2025 s'organise autour de six sections : Trafic, IA, Adoption et utilisation, Connectivité, Sécurité et Sécurité du courrier électronique. Ses données couvrent la période qui s'étend du 1er janvier au 2 décembre 2025. Afin de garantir la cohérence des informations, nous n'avons pas changé de méthodologies sous-jacentes par rapport aux calculs des années précédentes. Nous avons également intégré plusieurs nouveaux ensembles de données au bilan de cette année, notamment plusieurs indicateurs liés à l'IA, mais aussi des données sur l'activité mondiale des tests de vitesse et la progression de la taille des attaques DDoS hyper-volumétriques. Le microsite présente les tendances de plus de 200 pays et régions. Les lieux de petite taille ou moins densément peuplés ont été exclus des calculs faute de données suffisantes. Certains indicateurs sont uniquement proposés au niveau mondial et ne s'afficheront pas si vous sélectionnez un pays ou une région spécifique. 

Cet article met en lumière les conclusions et observations intéressantes tirées des principales sections du microsite Year In Review. Nous avons également publié un article de blog consacré aux services Internet les plus populaires qui explore de manière plus spécifique les tendances observées au sein des principaux services Internet.

Nous vous invitons à consulter le microsite Year in Review 2025 pour explorer plus en détail ces ensembles de données et ces indicateurs (notamment ceux de votre pays ou de votre région) afin de découvrir comment ils ont évolué depuis 2024 et comment ils se comparent à d'autres secteurs d'intérêt.

Nous espérons que vous considérerez notre bilan Year in Review comme un outil pertinent et puissant pour explorer les perturbations, les avancées et les indicateurs qui ont défini Internet en 2025. 

Découvrons maintenant toutes ces informations en détail.

• Le trafic Internet mondial a augmenté de 19 % en 2025, avec une croissance significative à partir du mois d'août. ➜

• Le top 10 des services Internet les plus populaires a fait l'objet de quelques changements par rapport à l'année dernière, tandis qu'un certain nombre de nouveaux services ont fait leur entrée dans les diverses catégories. ➜

• Le trafic Starlink a doublé en 2025, notamment le trafic issu de plus de 20 nouveaux pays ou nouvelles régions. ➜

• En explorant des millions de sites de clients Cloudflare à des fins d'indexation des recherches et d'entraînement de l'IA, le Googlebot a de nouveau généré le volume le plus élevé de trafic de requêtes vers Cloudflare en 2025. ➜

• La part du trafic web d'origine humaine chiffré de manière post-quantique est passée à 52 %. ➜

• Le trafic lié au Googlebot représentait plus d'un quart du trafic des bots vérifiés. ➜

• Le volume d'indexation réalisé par le Googlebot dans le cadre de son double objectif a éclipsé celui des autres bots IA et des autres robots d'exploration. ➜

• L'exploration IA résultant « d'actions de la part des utilisateurs » a été multipliée par plus de 15 en 2025. ➜

• Le trafic de requêtes HTML du Googlebot représentait à lui seul 4,5 %, tandis que celui des autres bots IA ne totalisait que 4,2 %. ➜

• Anthropic a affiché le coefficient exploration/renvoi le plus élevé parmi les principales plateformes d'IA et de recherche. ➜

• Les bots d'exploration IA sont les agents utilisateurs qui font le plus souvent l'objet d'une interdiction totale dans les fichiers robots.txt. ➜

• Le modèle llama-3-8b-instruct de Meta était le modèle le plus populaire sur Workers AI, tandis que la génération de texte constituait le type de tâche le plus répandu. ➜

• Les appareils iOS ont généré 35 % du trafic des appareils mobiles à travers le monde et plus de la moitié de ce trafic dans de nombreux pays. ➜

• La proportion des requêtes web mondiales utilisant le HTTP/3 et le HTTP/2 a légèrement augmenté en 2025. ➜

• Les bibliothèques et les cadres JavaScript ont conservé leur statut d'outils essentiels pour le développement de sites web. ➜

• Un cinquième des appels d'API automatisés provenaient de clients codés en Go. ➜

• Google demeure le premier moteur de recherche, tandis que Yandex, Bing et DuckDuckGo sont loin derrière. ➜

• Chrome reste le navigateur dominant sur l'ensemble des plateformes et des systèmes d'exploitation, sauf sur iOS, où Safari s'octroie la part du lion. ➜

• Près de la moitié des 174 pannes majeures d'Internet observées à travers le monde en 2025 résultaient de coupures régionales et nationales de la connectivité Internet à l'initiative d'un gouvernement. ➜

• Moins d'un tiers des requêtes dual-stack ont été effectuées en IPv6 à l'échelle mondiale, tandis que cette part s'élève à plus des deux tiers en Inde. ➜

• Les pays européens ont affiché certains des débits descendants les plus élevés du marché, avec une vitesse supérieure à 200 Mbit/s pour l'ensemble d'entre eux. L'Espagne est restée systématiquement en tête du classement des indicateurs de la qualité d'Internet. ➜

• Londres et Los Angeles ont été des points névralgiques concernant les tests de vitesse effectués à l'aide de l'outil Cloudflare en 2025. ➜

• Plus de la moitié du trafic de requêtes provient d'appareils mobiles dans 117 pays/régions. ➜

• Nos systèmes ont atténué 6 % du trafic mondial circulant sur le réseau Cloudflare, soit car il avait été défini comme potentiellement malveillant, soit pour des raisons définies par le client. ➜

• 40 % du trafic lié aux bots était issu des États-Unis. Amazon Web Services et Google Cloud sont à l'origine d'un quart de ce trafic. ➜

• Les entreprises du secteur « Population et société » ont été les plus visées en 2025. ➜

• La sécurité du routage, mesurée par la part des itinéraires RPKI valides et de l'espace d'adressage IP couvert, s'est améliorée tout au long de l'année 2025. ➜

• La taille des attaques DDoS hyper-volumétriques a augmenté de manière considérable tout au long de l'année. ➜

• Plus de 5 % des e-mails analysés par Cloudflare se sont avérés malveillants. ➜

• Les liens trompeurs, l'usurpation d'identité et l'usurpation de marque constituaient les menaces les plus courantes détectées au sein des e-mails malveillants. ➜

• La quasi-totalité des e-mails provenant des TLD .christmas et .lol ont été identifiés comme indésirables ou malveillants. ➜

Nous prenons comme base de référence le volume de trafic quotidien moyen (hors trafic lié aux bots) circulant pendant la deuxième semaine calendaire complète de l'année 2025 (du 12 au 18 janvier) pour déterminer les tendances du trafic au fil du temps qui figurent dans le bilan Year in Review. (Nous avons choisi la deuxième semaine calendaire afin de permettre aux utilisateurs de reprendre leurs routines scolaires et professionnelles « normales » après les vacances d'hiver et le jour de l'an.) Le pourcentage de variation indiqué dans le graphique des tendances du trafic est calculé par rapport à la valeur de référence. Il ne représente pas le volume absolu du trafic pour un pays ou une région. La courbe de tendance représente une moyenne glissante sur sept jours, que nous utilisons pour lisser les brusques variations observées avec des données à granularité quotidienne. 

La croissance du trafic au cours de l'année 2025 semble s'être déroulée en plusieurs phases. En moyenne, le trafic est resté relativement stable jusqu'à la mi-avril, avec un pourcentage généralement situé à quelques points de la valeur de référence. Il a ensuite augmenté tout au long du mois de mai, pour s'établir à près de 5 % au-dessus de la valeur de référence, avant de se stabiliser autour de la plage des +4 à +7 % jusqu'à la mi-août. C'est à ce moment que sa croissance s'est accélérée. Le trafic a progressé régulièrement au cours des mois de septembre, octobre et novembre, pour atteindre un pic de 19 % cette année. Soutenu par une augmentation survenue fin novembre, le taux de croissance de l'année 2025 est environ 10 % supérieur au taux de croissance de 17 % constaté en 2024. Nous avons également constaté une accélération de la croissance du trafic au cours du second semestre les années précédentes, bien que cette accélération ait débuté en juillet pour la période 2022-2024. Les raisons pour lesquelles la croissance de cette année a apparemment été retardée de plusieurs semaines ne sont pas claires.

^{Tendances du trafic Internet sur l'année 2025 (échelle mondiale)}

Le Botswana a enregistré la plus forte croissance avec un pic de 298 % au-dessus de la valeur de référence le 8 novembre. Le pays a terminé la période à 295 % au-dessus de cette même valeur. (Vous trouverez davantage d'informations sur les facteurs qui expliquent cette croissance dans la section Starlink ci-dessous.) Si le Botswana et le Soudan ont été les seuls pays/régions à voir leur trafic plus que doubler au cours de l'année, d'autres pays ont également connu des pics supérieurs à 100 % à un moment donné.

^{Tendances du trafic Internet sur l'année 2025 : Botswana}

L'impact des épisodes d'interruption prolongés d'Internet est aussi clairement visible sur les graphiques. Le 29 octobre, par exemple, le gouvernement tanzanien a imposé une coupure d'Internet dans le pays en réponse aux manifestations ayant suivi le jour du scrutin. Cette coupure n'a duré qu'une journée, mais une autre a suivi, du 30 octobre au 3 novembre. Malgré l'augmentation de plus de 40 % du trafic au sein du pays par rapport au niveau de référence avant les coupures, la perturbation a finalement fait chuter le trafic de plus de 70 % par rapport au niveau de référence, soit une inversion rapide de la tendance. Le trafic a repris rapidement après le rétablissement de la connectivité. Une tendance similaire a été observée en Jamaïque, où le trafic Internet a connu un pic avant l'arrivée de l'ouragan Melissa le 28 octobre, puis a chuté considérablement suite aux coupures de courant et aux dégâts infligés aux infrastructures de l'île par la tempête. Le trafic a commencé à reprendre après le passage de l'ouragan, pour revenir à un niveau légèrement supérieur à la normale début décembre.

^{Tendances du trafic Internet sur l'année 2025 : Tanzanie}

^{Tendances du trafic Internet sur l'année 2025 : Jamaïque}

Pour compiler le bilan Year in Review, nous nous intéressons à la période de 11 mois qui s'est écoulée depuis le début de l'année. Outre un classement « général », nous classons également les services dans neuf catégories, en fonction de l'analyse d'un ensemble anonymisé de données de requêtes émises par des millions d'utilisateurs à travers le monde et adressées à notre résolveur DNS public 1.1.1.1. Pour établir ces classements, les domaines qui appartiennent à un seul service Internet sont regroupés ensemble.

Google et Facebook ont conservé les deux premières places du top 10. Si la position des autres membres du top 10 est généralement restée stable par rapport au classement de 2024, le milieu de tableau a toutefois fait l'objet de quelques changements. Microsoft, Instagram et YouTube ont tous progressé au classement. Amazon Web Services (AWS) a reculé d'une place, tandis que TikTok a chuté de quatre places.

^{Principaux services Internet en 2025 (échelle mondiale)}

ChatGPT/OpenAI a gardé la première place du classement des services d'IA générative. Nous avons toutefois constaté des mouvements ailleurs, qui soulignent la nature dynamique du secteur. Perplexity, Claude/Anthropic et GitHub Copilot figurent ainsi au rang des services qui ont progressé au classement. Les nouveaux arrivants dans le top 10 de l'année 2025 sont Google Gemini, Windsurf AI, Grok/xAI et DeepSeek.

^{Meilleurs services d'IA générative en 2025 (échelle mondiale)}

D'autres catégories ont également connu des changements au niveau de leurs classements. Shopee (« la principale plateforme d'e-commerce en Asie du Sud-Est et à Taïwan ») fait ainsi son entrée dans le classement consacré à l'e-commerce, tandis qu'HBO Max a rejoint le classement des services de diffusion vidéo. Nous examinons plus en détail ces classements par catégorie, ainsi que les tendances observées pour des services spécifiques, dans un article de blog distinct.

Par ailleurs, nous proposons également des statistiques sur les principaux services Internet au niveau du pays/de la région pour les catégories Classement général, IA générative, Réseaux sociaux et Messagerie cette année. (Nous n'avions partagé de statistiques que pour la catégorie Classement général en 2024.)

Le service de connexion Internet satellite Starlink proposé par SpaceX continue d'être une option populaire pour connecter les zones non desservies ou mal desservies, ainsi que pour les utilisateurs à bord des avions et des bateaux. Nous avons analysé les volumes agrégés de trafic de requêtes associés au principal système autonome de Starlink (AS14593) afin de suivre la croissance de l'utilisation du service tout au long de l'année 2025. Le volume de requêtes montré sur la courbe de tendance du graphique représente une moyenne glissante sur sept jours. 

À l'échelle mondiale, le trafic de Starlink a continué de croître de manière constante tout au long de l'année 2025, avec un volume total de requêtes multiplié par 2,3 sur l'ensemble de l'année. Nous observons généralement une tendance à la croissance rapide du trafic lorsque le service Starlink devient disponible dans un pays ou une région et cette tendance se poursuit en 2025. 

^{Croissance du trafic Starlink en 2025 (échelle mondiale)}

C'est exactement ce que nous avons constaté pour les plus de 20 nouveaux pays (et nouvelles régions) dans lesquels @Starlink a annoncé la disponibilité de son service : le trafic Starlink au sein de ces nouvelles zones a augmenté rapidement en l'espace de quelques jours. Ces nouvelles zones comprenaient l'Arménie, le Niger, le Sri Lanka et Saint-Martin (partie hollandaise).

Nous avons également observé la présence de trafic Starlink en provenance de plusieurs endroits dans lesquels le service n'est pas identifié comme disponible à l'heure actuelle. Le geofeed publié par Starlink (une liste d'adresses IP associées à des données de géolocalisation) contient toutefois des préfixes IPv4 et/ou IPv6 associés à ces pays. Ce trafic provient probablement d'utilisateurs en déplacement dans ces zones, car les utilisateurs de Starlink peuvent bénéficier de l'itinérance pour leur service (et leur équipement).

^{Croissance du trafic Starlink en 2025 : Niger}

Le Bénin, le Timor oriental et le Botswana ont enregistré les plus fortes croissances de trafic parmi les pays/régions où le service était actif avant 2025, avec une hausse respective de 51, 19 et 16 fois. La disponibilité du service Starlink au Bénin a été annoncée pour la première fois en novembre 2023, en décembre 2024 pour le Timor oriental et en août 2024 pour le Botswana.

^{Croissance du trafic Starlink en 2025 : Botswana}

Des services similaires, comme Leo d'Amazon Konnect d'Eutelsat et le service chinois Qianfan, continuent de développer leurs constellations de satellites en vue d'une prochaine mise en disponibilité commerciale. Nous espérons également pouvoir étudier la croissance du trafic de ces services à l'avenir.

Nous pouvons faire appel à une courbe de Hilbert pour examiner le volume agrégé de trafic de requêtes observé par Cloudflare en 2025 sur l'ensemble de l'Internet IPv4. Cette courbe nous permet de visualiser une séquence d'adresses IPv4 selon un schéma bidimensionnel qui maintient les adresses IP physiquement proches à proximité les unes des autres, un outil bien utile pour étudier l'espace d'adressage IPv4 d'Internet. Dans notre visualisation, nous agrégeons les adresses IPv4 en préfixes /20. Chaque carré représente ainsi le trafic de 4 096 adresses IPv4 au niveau de zoom maximal. Ce niveau d'agrégation permet de maîtriser la quantité de données utilisées pour produire la vue. Vous trouverez davantage d'informations sur la visualisation dans l'article de blog consacré au bilan Year in Review 2024 ».

Pour la troisième année consécutive, le bloc d'adresses IP qui a enregistré le volume maximal de requêtes transmises à Cloudflare en 2025 était le bloc d'adresses 66.249.64.0/20 de Google, l'un des nombreux blocs utilisés par le bot d'exploration web Googlebot pour récupérer du contenu à des fins d'indexation des recherches et d'entraînement de l'IA. Il n'est pas surprenant qu'un bloc d'adresses IP Googlebot arrive à nouveau en tête des principales sources de trafic de requêtes, compte tenu du nombre de propriétés web sur le réseau Cloudflare et de l'agressivité dont fait preuve le Googlebot dans son activité d'exploration. Le préfixe Googlebot totalisait presque 4 fois plus de trafic de requêtes IPv4 que la source de trafic suivante la plus importante, 146.20.240.0/20, qui fait partie d'un bloc plus étendu d'espace d'adressage IPv4 annoncé par Rackspace Hosting. En tant que fournisseur de services cloud et d'hébergement, Rackspace prend en charge de nombreux types de clients et d'applications. L'origine du trafic observé vers Cloudflare est par conséquent inconnue.

^{Vue agrandie de la courbe de Hilbert montrant le bloc d'adresses ayant généré le plus grand nombre de requêtes en 2025}

Cette année, nous avons ajouté la possibilité de rechercher un système autonome (AS, Autonomous System) à notre vue afin de vous permettre de visualiser la répartition des adresses IP d'un fournisseur réseau au sein de l'univers IPv4. 

L'un des exemples, l'AS16509 (AMAZON-02, utilisé par AWS), illustre les conséquences des acquisitions de vastes quantités d'espace d'adressage IPv4 par Amazon au fil des ans. L'AS7018 (ATT-INTERNET4, AT&T), l'un des plus importants fournisseurs d'espace d'adressage IPv4 aux États-Unis constitue également un autre exemple. Une grande partie du trafic que nous observons depuis ce numéro de système autonome (ASN, Autonomous System Number) provient de 12.0.0.0/8, un bloc de plus de 16 millions d'adresses IPv4 détenu par AT&T depuis 1983.

^{Courbe de Hilbert montrant les blocs d'adresses IPv4 de l'AS7018 qui ont envoyé du trafic à Cloudflare en 2025}

Le terme « post-quantique » désigne un ensemble de techniques cryptographiques conçues pour protéger des données chiffrées contre les attaques de type « récolter maintenant, déchiffrer plus tard » lancées par des adversaires disposant de la possibilité de capturer et de stocker du contenu en vue d'un déchiffrage ultérieur lorsque les ordinateurs quantiques seront suffisamment avancés. L'équipe de recherche Cloudflare travaille sur le chiffrement post-quantique depuis 2017 et publie régulièrement des mises à jour relatives à l'avancement de l'Internet post-quantique.

Après avoir connu une croissance significative en 2024, la part mondiale du trafic chiffré à l'aide d'un algorithme post-quantique a presque doublé au cours de l'année 2025, en passant de 29 % au début de l'année à 52 % début décembre. 

^{Croissance du trafic chiffré en TLS 1.3 post-quantique en 2025 (échelle mondiale)}

Dans 28 pays ou régions, la proportion de trafic chiffré en post-quantique a plus que doublé tout au long de l'année, avec notamment une hausse significative à Porto Rico et au Koweït. La part du Koweït a presque triplé (en passant de 13 à 37 %), tandis que celle de Porto Rico est passée de 20 à 49 %. 

Ces trois pays figuraient parmi ceux qui ont observé une croissance significative de leur part à la mi-septembre, un moment concomitant à la date du lancement par Apple d'une mise à jour de son système d'exploitation, dans laquelle « les connexions protégées par TLS annonceront automatiquement la prise en charge d'un processus d'échange de clés hybride et sécurisé contre l'informatique quantique au sein du protocole TLS 1.3 ». Plus de la moitié du trafic de requêtes provient d'appareils mobiles au Koweït et à Porto Rico, tandis que près de la moitié provient d'appareils iOS dans les deux pays. Il n'est donc pas étonnant de constater que cette mise à jour logicielle ait entraîné une augmentation significative de la part du trafic post-quantique.

^{Croissance du trafic TLS 1.3 chiffré à l'aide d'un algorithme post-quantique en 2025 : Porto Rico}

La part du trafic chiffré en post-quantique et provenant d'appareils Apple iOS a ainsi considérablement augmenté en septembre après la sortie officielle d'iOS 26. La part mondiale des requêtes en provenance d'appareils iOS et incluant la prise en charge du post-quantique est passée d'un peu moins de 2 % à 11 % seulement quatre jours après la sortie. Plus de 25 % des requêtes provenant d'appareils iOS faisaient appel au chiffrement post-quantique début décembre.

Le nouveau répertoire de bots disponible sur Cloudflare Radar propose une multitude d'informations sur les bots vérifiés et les agents signés, notamment sur leurs opérateurs, leurs catégories et les agents utilisateurs associés, mais aussi sous forme de liens vers la documentation et de tendances du trafic. Les bots vérifiés doivent se conformer à un ensemble d'exigences et être contrôlés à l'aide du processus Web Bot Auth ou du processus de validation de l'adresse IP. Un agent signé est contrôlé par un utilisateur final et un agent de signature vérifié issus du déploiement Web Bot Auth et doit se conformer à un ensemble d'exigences distinct.

Utilisé pour explorer le contenu des sites web à des fins d'indexation des recherches et d'entraînement de l'IA, le robot Googlebot a été de loin le bot le plus actif observé par Cloudflare tout au long de l'année 2025. Responsable de plus de 28 % du trafic issu de bots vérifiés, il s'est révélé le plus actif entre mi-février et mi-juillet, avec un pic d'activité à la mi-avril. D'autres bots gérés par Google ont été responsables de volumes de trafic notables, parmi lesquels Google AdsBot (utilisé pour surveiller les sites web au sein desquels des publicités Google sont diffusées), Google Image Proxy (utilisé pour récupérer et mettre en cache les images intégrées aux e-mails) et GoogleOther (utilisé par diverses équipes produits pour extraire du contenu accessible au public sur les sites).

Le robot GPTBot d'OpenAI (qui explore le contenu à des fins d'entraînement de l'IA) était le deuxième bot le plus actif. Il a ainsi totalisé près de 7,5 % du trafic lié aux bots vérifiés, avec une activité d'exploration assez volatile au cours du premier semestre. Le Bingbot de Microsoft explore le contenu des sites web à des fins d'indexation des recherches et d'entraînement de l'IA. Il a généré 6 % du trafic lié aux bots vérifiés tout au long de l'année. Son activité est donc relativement stable. 

^{Tendances du trafic lié aux bots vérifiés en 2025 (échelle mondiale)}

Les deux catégories de bots vérifiés les plus actives sont celle des bots d'indexation des moteurs de recherche et celle des bots d'exploration IA. Leurs schémas de trafic correspondent étroitement aux principaux bots de ces catégories, c'est-à-dire le GoogleBot et le robot GPTBot d'OpenAI. Les bots d'indexation des moteurs de recherche ont totalisé 40 % du trafic lié aux bots vérifiés, tandis que les robots d'exploration IA en ont généré la moitié (20 %). Les bots d'optimisation pour les moteurs de recherche (Search Engine Optimization, SEO) se sont également montrés très actifs. Ils ont ainsi généré plus de 13 % des requêtes émises par les bots vérifiés.

^{Tendances du trafic lié aux bots vérifiés par catégorie (échelle mondiale)}

Au mois de septembre, un article de blog Cloudflare a présenté une proposition visant à définir les principes régissant une utilisation responsable des bots IA. L'un de ces principes stipulait que « les bots IA doivent avoir un objectif distinct et le déclarer ». Dans la vue d'ensemble des bonnes pratiques concernant les bots IA disponible sur Radar, nous remarquons que plusieurs exploitants de bots disposent de robots d'exploration à double usage, notamment Google et Microsoft.

Le Googlebot explore le contenu à des fins d'indexation pour les moteurs de recherche, mais aussi d'entraînement de l'IA. Nous l'avons donc inclus dans la vue d'ensemble des bots d'exploration IA de cette année. Son volume d'exploration sur l'année 2025 a littéralement éclipsé celui des autres bots IA principaux. Le trafic de requêtes a commencé à augmenter à la mi-février, pour atteindre un pic fin avril, avant de diminuer lentement jusqu'à la fin juillet. Après cette période, le trafic a de nouveau augmenté progressivement jusqu'à la fin de l'année. Bien que son volume d'exploration ne totalise qu'une fraction de celui du Googlebot, le Bingbot présente également un double objectif similaire. De manière générale, l'activité d'exploration du Bingbot a augmenté tout au long de l'année.

^{Tendances du trafic lié aux bots d'exploration IA sur l'année 2025 (échelle mondiale)}

Le GPTBot d'OpenAI explore le contenu susceptible d'être utilisé pour entraîner les modèles sur lesquels repose l'IA générative d'OpenAI. L'activité d'exploration s'est révélée plutôt volatile tout au long de l'année. Si ses pics se sont produits en juin, elle a néanmoins terminé le mois de novembre avec un niveau légèrement supérieur à ceux observés au début de l'année. 

Le volume d'exploration généré par ChatGPT-User d'OpenAI (un bot qui consulte les pages web lorsque les utilisateurs posent des questions à ChatGPT ou à un CustomGPT) a connu une croissance soutenue au cours de l'année. Son schéma d'utilisation hebdomadaire se précise à partir de la mi-février et suggère ainsi un usage accru dans les établissements scolaires et sur le lieu de travail. Les pics de volume de requêtes se sont montrés jusqu'à 16 fois plus élevés qu'au début de l'année sur cette période. Une baisse de l'activité apparaît également de manière évidente sur la période qui s'étend de juin à août, c'est-à-dire le moment où de nombreux étudiants sont en congé scolaire et où de nombreux professionnels prennent leurs vacances. 

Utilisé pour relier et faire apparaître les sites web dans les résultats de recherche de ChatGPT, l'OAI-SearchBot a vu son activité d'exploration augmenter progressivement jusqu'au mois d'août, avant de connaître plusieurs pics de trafic en août et septembre. Le trafic a ensuite commencé à augmenter de nouveau en octobre, bien que de manière plus agressive, avec un pic de volume de requêtes environ 5 fois plus élevé qu'au début de l'année à la fin du mois d'octobre.

^{Tendances du trafic lié aux bots d'exploration d'OpenAI sur l'année 2025 (échelle mondiale)}

L'activité d'exploration du ClaudeBot d'Anthropic a effectivement doublé au cours du premier semestre de l'année, avant de décliner progressivement au cours du second semestre, pour s'établir à un niveau environ 10 % plus élevé qu'au début de l'année. Le trafic d'exploration du PerplexityBot a lentement augmenté aux mois de janvier et février, mais a connu un fort pic d'activité de la mi-mars jusqu'au mois d'avril. La croissance du trafic s'est ensuite montrée plus progressive jusqu'au mois d'octobre, avant de connaître une nouvelle augmentation significative en novembre, pour finalement atteindre un niveau environ 3,5 fois supérieur à celui observé au début de l'année.

^{Tendances du trafic du ClaudeBot sur l'année 2025 (échelle mondiale)}

^{Tendances du trafic du PerplexityBot sur l'année 2025 (échelle mondiale)}

L'un des principaux bots d'exploration IA de 2024, le Bytespider de ByteDance, a généré un volume d'indexation inférieur à celui de plusieurs autres bots d'entraînement. Son activité a chuté tout au long de l'année, en poursuivant ainsi la baisse observée l'année dernière.

L'activité d'exploration de la plupart des bots IA tire son origine de l'un des trois objectifs suivants : l'entraînement (c'est-à-dire le fait de collecter le contenu d'un site web à des fins d'entraînement des modèles IA), la recherche (c'est-à-dire le fait d'indexer le contenu d'un site web afin de le rendre accessible à la fonctionnalité de recherche disponible sur les plateformes IA) et les actions des utilisateurs (c'est-à-dire le fait de se rendre sur un site web en réponse à une question posée à un chatbot par un utilisateur). Veuillez remarquer que l'indexation en vue de la recherche peut également inclure l'exploration pour la génération augmentée par récupération (RAG, Retrieval-Augmented Generation), une approche qui permet à un propriétaire de contenu d'intégrer ses propres données au processus de génération des LLM sans devoir réentraîner ni procéder à l'affinage d'un modèle. (Un quatrième objectif « non déclaré » consiste à capturer le trafic des bots IA dont l'activité d'exploration présente une finalité incertaine ou inconnue.)

L'indexation à des fins d'entraînement des modèles constitue l'écrasante majorité du trafic des bots d'exploration IA, avec une activité maximale jusqu'à 7 à 8 fois supérieure à celle de l'exploration web à des fins de recherche et 32 fois supérieure à l'exploration web résultant d'actions de la part des utilisateurs. Le chiffre du trafic d'entraînement est fortement influencé par le GPTBot d'OpenAI. Il a, par conséquent, suivi une tendance pour le moins similaire tout au long de l'année.

L'indexation à des fins de recherche caracolait en tête jusqu'à la mi-mars, avant de diminuer d'environ 40 %. Elle a ensuite repris une croissance plus progressive, mais a néanmoins terminé la période examinée avec une activité d'un peu moins de 10 % par rapport à celle observée au début de l'année.

L'exploration résultant d'actions de la part d'utilisateurs a débuté l'année 2025 avec le volume d'indexation le plus faible parmi les trois objectifs définis. Ce volume a toutefois plus que doublé en janvier et février. Il a de nouveau doublé début mars, puis a continué à croître tout au long de l'année, pour afficher ainsi une augmentation de plus de 21 fois entre le volume observé au mois de janvier et le volume de début décembre. Cette croissance correspond très étroitement aux tendances du trafic observées pour le bot ChatGPT-User d'OpenAI.

^{Tendances du trafic lié à l'exploration résultant d'actions de la part d'utilisateurs sur l'année 2025 (échelle mondiale)}

Les bots IA se sont fréquemment retrouvés dans l'actualité en 2025, lorsque les propriétaires de contenu ont exprimé leurs préoccupations quant au volume de trafic qu'ils génèrent, notamment sur le fait qu'une grande partie de ce trafic ne se traduit pas en renvoi des utilisateurs finaux vers les sites web sources. Afin de mieux comprendre l'impact de l'activité d'exploration des bots IA par rapport à celle des bots sans lien avec l'IA et à l'utilisation humaine d'Internet, nous avons analysé le trafic des requêtes de contenu HTML émises parmi les clients Cloudflare et l'avons classé comme provenant d'un humain, d'un bot IA ou d'un autre type de bot « sans lien avec l'IA ». (Nous nous concentrons ici uniquement sur le contenu HTML. Vous remarquerez donc sans doute que les parts de trafic liées aux bots et aux humains diffèrent de celles qui figurent sur Radar, qui analysent le trafic des requêtes pour tous les types de contenu.) Comme le Googlebot explore Internet de manière très active et qu'il poursuit une double finalité, nous avons décomposé sa part de manière distincte dans cette analyse.

Tout au long de l'année 2025, nous avons constaté que le trafic provenant des bots IA représentait 4,2 % des requêtes HTML en moyenne. Cette part a considérablement varié au cours de l'année. Elle a ainsi chuté jusqu'à 2,4 % début avril et atteint 6,4 % fin juin.

Les bots sans lien avec l'IA ont ainsi commencé l'année 2025 en étant responsables de la moitié des requêtes adressées aux pages HTML, soit sept points de plus que le trafic d'origine humaine. L'écart s'est élargi pour atteindre 25 points début juin. Ces parts de trafic ont toutefois commencé à se rapprocher à partir de la mi-juin et sont entrées dans une période où la proportion de trafic HTML d'origine humaine a parfois dépassé celle des bots (à partir du 11 septembre). Au 2 décembre, le trafic d'origine humaine générait ainsi 47 % des requêtes HTML, tandis que les bots sans lien avec l'IA en généraient 44 %.

Le Googlebot est un robot d'exploration particulièrement vorace. Il était ainsi à l'origine de 4,5 % des requêtes HTML cette année, soit une part légèrement supérieure à celle des bots IA dans leur ensemble. Sa part de trafic a commencé l'année à tout juste un peu moins de 2,5 % et augmenté rapidement au cours des quatre mois suivants, pour atteindre un pic de 11 % à la fin du mois d'avril. Elle est ensuite revenue à son point de départ lors des mois suivants, avant d'augmenter de nouveau au cours du second semestre, pour terminer l'année sur une proportion de 5 %. Comme mentionné plus haut, ces évolutions reflètent en grande partie l'activité d'exploration du Googlebot.

^{Parts de trafic HTML par type de bot sur l'année 2025 (échelle mondiale)}

Nous avons lancé l'indicateur présentant le coefficient exploration/renvoi sur Radar le 1er juillet afin de suivre la fréquence à laquelle une plateforme d'IA ou de recherche envoie du trafic vers un site donné par rapport à la fréquence d'indexation de ce même site. Un coefficient élevé indique une forte activité d'exploration par l'IA sans renvoi de véritables utilisateurs humains vers le site web.

L'indicateur peut s'avérer pour le moins volatile, car les valeurs fluctuent quotidiennement en fonction des variations de l'activité d'exploration et du trafic de renvoi. Cet indicateur compare le nombre total de requêtes émises par les agents utilisateurs pertinents associés à une plateforme de recherche ou à une plateforme d'IA donnée (pour lesquelles la réponse était de type « Content-type: text/html ») au nombre total de requêtes de contenu HTML dont l'en-tête « Referer » contenait un nom d'hôte associé à une plateforme de recherche ou une plateforme d'IA donnée. 

Avec un chiffre maximal de 500 000:1, Anthropic a enregistré les coefficients exploration/renvoi les plus élevés cette année malgré une période un peu erratique de janvier à mai. L'ampleur et la nature irrégulière de l'indicateur sont probablement dues à un faible trafic de renvoi sur cette période. Les coefficients sont devenus plus cohérents par la suite, mais sont restés plus élevés que d'autres, en s'échelonnant d'environ 25 000:1 à près de 100 000:1.

Les coefficients d'OpenAI ont fortement fluctué au fil du temps, pour atteindre un pic de 3 700:1 au mois de mars. Ces évolutions peuvent découler de la stabilisation de l'activité d'exploration du GPTBot, associée à une utilisation accrue de la fonctionnalité de recherche de ChatGPT, dont les réponses intègrent des liens vers les sites web sources. La masse d'utilisateurs qui cliquent sur ces liens pourrait augmenter le nombre de renvois et ainsi réduire potentiellement le coefficient. (En partant du principe que le trafic d'exploration ne s'est pas accru à un rythme similaire ou supérieur.)

Perplexity a affiché les coefficients d'exploration/renvoi les plus faibles parmi les principales plateformes d'IA. Le bot a ainsi commencé l'année à moins de 100:1 avant d'atteindre un pic supérieur à 700:1 fin mars, de manière concomitante à l'augmentation du trafic d'indexation observée au niveau du PerplexityBot.  Un retour à la normale s'est opéré après le pic. De manière générale, les valeurs maximales du coefficient sont ainsi restées inférieures à 400:1 par la suite et même inférieures à 200:1 à partir du mois de septembre.

Parmi les plateformes de recherche, le coefficient de Microsoft nous a présenté un schéma hebdomadaire cyclique pour le moins inattendu, avec ses niveaux les plus bas le jeudi et un pic le dimanche. Les valeurs maximales du coefficient se situaient généralement entre 50:1 et 70:1 tout au long de l'année. Le coefficient exploration/renvoi de Google a augmenté régulièrement jusqu'au mois d'avril, où il a atteint les 30:1. Après ce pic, le coefficient s'est montré quelque peu erratique jusqu'à la mi-juillet (où il est tombé à 3:1) avant de remonter lentement au cours du deuxième semestre 2025. Le coefficient de DuckDuckGo est resté inférieur à 1:1 pendant les trois premiers trimestres civils de 2025, avant de connaître un bond soudain à 1,5:1 à la mi-octobre. Il est ensuite resté élevé sur le reste de la période.

^{Coefficients exploration/renvoi des plateformes de recherche et d'IA sur l'année 2025 (échelle mondiale)}

Le fichier robots.txt, formellement dénommé « protocole d'exclusion des robots » dans la RFC 9309, est un fichier texte que les propriétaires de contenu peuvent utiliser pour définir les parties d'un site web auxquelles les bots d'exploration sont autorisés à accéder. Ils établissent des directives qui permettent d'autoriser ou d'interdire l'accès aux robots d'indexation de recherche et d'IA sur l'ensemble du site, ou seulement à certaines parties de ce dernier. Les directives contenues dans le fichier se comportent de fait comme un panneau « Entrée interdite ». Elles n'assurent aucune mesure formelle de contrôle des accès. La fonctionnalité de gestion du fichier robots.txt proposée par Cloudflare met automatiquement à jour le fichier existant d'un site ou crée un nouveau fichier, en y intégrant des directives qui demandent aux exploitants de bots IA populaires de ne pas utiliser le contenu pour l'entraînement de leurs modèles IA. Notre service AI Crawl Control peut également surveiller les violations des directives du fichier robots.txt d'un site et permettre au propriétaire du site de bloquer les requêtes émises par l'agent utilisateur incriminé.

Cloudflare Radar propose des informations sur le nombre de fichiers robots.txt trouvés parmi les 10 000 principaux domaines dont nous avons la charge, ainsi que sur la disposition complète ou partielle des directives d'autorisation et d'interdiction contenues dans ces fichiers pour une sélection d'agents utilisateurs d'exploration. (Dans ce contexte, le terme « complète » désigne les directives qui s'appliquent à l'ensemble du site et « partielle » celles qui s'appliquent à des chemins d'accès ou des types de fichiers spécifiques.) Nous détaillons la manière dont la disposition de ces directives a évolué au cours de l'année 2025 sur le microsite Year in Review.

Les agents utilisateurs concernés par le plus grand nombre de directives d'interdiction totale sont ceux qui sont associés aux bots d'exploration IA, notamment le GPTBot, le ClaudeBot et le CCBot. Les directives relatives au Googlebot et au Bingbot, deux robots utilisés à la fois à des fins d'indexation des recherches et l'entraînement de l'IA, penchaient fortement vers l'interdiction partielle, probablement dans le but d'isoler les points de terminaison de connexion et les autres secteurs sans lien avec le contenu d'un site. Pour ces deux bots, les directives applicables à l'ensemble du site ne sont restées qu'une petite fraction du nombre total de directives d'interdiction observées tout au long de l'année. 

^{Directives d'interdiction du fichier robots.txt, répartition par agent utilisateur}

Le nombre de directives d'autorisation explicites trouvées dans les fichiers robots.txt identifiés ne représentait qu'une petite partie des directives d'interdiction observées. Ce constat découle probablement du fait qu'en l'absence de directive spécifique, la directive d'autorisation constitue la politique par défaut. Le Googlebot disposait du plus grand nombre de directives d'autorisation explicites, même si plus de la moitié d'entre elles étaient des autorisations partielles. Les bots d'exploration IA disposaient de directives d'autorisation dans moins de domaines, tandis que les directives visant les robots d'indexation d'OpenAI tendaient davantage vers l'autorisation complète et explicite. 

Google-Extended est un jeton pour agent utilisateur que les éditeurs web peuvent utiliser pour déterminer si le contenu que Google explore sur leurs sites peut être utilisé pour entraîner les modèles Gemini ou pour proposer le contenu d'un site sur Gemini depuis l'index Google Search. Le nombre de directives d'autorisation le concernant a triplé au cours de l'année. La plupart d'entre elles ne lui autorisaient qu'un accès partiel au début de l'année, tandis qu'à la fin de l'année, un plus grand nombre de directives autorisaient explicitement l'accès au contenu complet du site que celles qui ne lui autorisaient l'accès qu'à une partie. 

^{Directives d'autorisation du fichier robots.txt, répartition par agent utilisateur}

Le panorama des modèles IA évolue rapidement, car les fournisseurs lancent régulièrement des modèles plus puissants, capables de diverses tâches, comme la génération de textes et d'images, la reconnaissance vocale et la classification d'images. Cloudflare travaille en étroite collaboration avec les fournisseurs de modèles IA pour s'assurer que Workers AI prenne en charge ces modèles le plus rapidement possible après leur lancement. Nous avons en outre fait récemment l'acquisition de Replicate, une plateforme qui va nous permettre d'étoffer considérablement notre catalogue de modèles pris en charge. En février 2025, nous avons doté Radar d'une visibilité basée sur le pourcentage de comptes client et concernant la popularité des modèles pris en charge disponibles au public, ainsi que sur les types de tâches que ces modèles peuvent accomplir. 

Tout au long de l'année, le modèle llama-3-8b-instruct de Meta a bénéficié d'une position dominante, avec une proportion des comptes (36,3 %) plus de trois fois supérieure à celle des modèles les plus populaires suivants, c'est-à-dire whisper d'OpenAI (10,1 %) et stable-diffusion-xl-base-1.0 de Stability AI (9,8 %). Meta et la BAAI (Beijing Academy of Artificial Intelligence, l'Académie de Pékin de l'intelligence artificielle) comptaient plusieurs modèles parmi les 10 premiers. Les modèles figurant dans le top 10 représentaient une part de marché de 89 %, le reste étant réparti sur une longue traîne d'autres modèles.

^{Les modèles les plus populaires sur Workers AI en 2025 (échelle mondiale)}

La popularité des tâches était en grande partie induite par la popularité des modèles. La génération de texte, la conversion texte-image et la reconnaissance vocale automatique arrivaient en tête de ces dernières. 48,2 % des comptes clients Workers AI ont fait appel à la génération de textes, soit un chiffre près de quatre fois supérieur à la part de la conversion texte-image (12,3 %) et de la reconnaissance vocale automatique (11 %). 

^{Les tâches les plus populaires sur Workers AI en 2025 (échelle mondiale)}

Outre l'analyse annuelle présentée ci-dessus, vous trouverez ci-dessous une analyse ponctuelle des éléments explorés. Veuillez noter que ces informations ne figurent pas sur le microsite Year in Review.

La section IA du bilan Year in Review s'intéresse au trafic mondial des bots IA et des robots d'indexation sans tenir compte de la position géographique du compte propriétaire du contenu exploré. Si nous examinons les données d'octobre 2025 à un niveau géographique inférieur afin d'identifier les bots qui génèrent le plus grand volume de trafic d'exploration pour les sites détenus par des clients dont l'adresse de facturation se situe au sein d'une région géographique donnée, nous constatons que le Googlebot totalise entre 35 et 55 % du trafic d'exploration dans chaque région.

Les deuxièmes bots les plus actifs sont le GPTBot d'OpenAI et le Bingbot de Microsoft, avec une part du volume de trafic comprise entre 13 et 14 %. Le Bingbot conserve une nette avance sur les bots d'exploration IA dans les économies développées d'Amérique du Nord, d'Europe et d'Océanie. En revanche, pour les sites basés au sein de marchés à forte croissance en Amérique du Sud et en Asie, c'est le GPTBot qui a une légère avance sur le Bingbot.

L'analyse de l'activité des bots d'exploration IA au cours du mois d'octobre 2025 en fonction du secteur du client nous a permis de découvrir que les secteurs qui attiraient le plus de trafic étaient le secteur du commerce et le secteur des logiciels, qui totalisent ensemble un peu plus de 40 % de l'activité.

Les autres secteurs du top 10 ne représentaient que des portions beaucoup plus négligeables de l'activité d'exploration. Ces 10 principaux secteurs totalisaient un peu moins de 70 % de l'activité d'exploration, le reste étant réparti sur un large éventail d'autres secteurs.

^{Part du secteur dans l'activité d'exploration IA, octobre 2025}

L'iOS d'Apple et l'Android de Google constituent les deux principaux systèmes d'exploitation mobiles utilisés dans le monde. En analysant les informations contenues dans l'en-tête User-Agent qui accompagne chaque requête web, nous pouvons calculer la répartition du trafic en fonction du système d'exploitation utilisé par le client sur l'année. Les appareils Android génèrent la majorité du trafic mobile à l'échelle mondiale, en raison de leur vaste gamme de prix, de formats et de capacités.

La part du trafic émise par des appareils iOS à l'échelle mondiale a légèrement augmenté par rapport à l'année précédente pour atteindre les 35 % en 2025, soit une progression de deux points. Si l'on examine les principaux pays en fonction de leur part de trafic iOS, c'est Monaco qui détient la part la plus élevée (avec 70 %). Le système iOS totalise en outre 50 % ou plus du trafic mobile dans 30 pays ou régions, comme le Danemark (65 %), le Japon (57 %) et Porto Rico (52 %).

^{Répartition du trafic mobile en fonction du système d'exploitation pour l'année 2025 (échelle mondiale)}

Les parts de trafic étaient nettement plus importantes dans les pays et les régions où l'utilisation d'Android est plus répandue. Vingt-sept pays/régions disposaient d'une adoption d'Android supérieure à 90 % en 2025. La Papouasie-Nouvelle-Guinée affiche à ce titre le taux le plus élevé, avec 97 %. Le Soudan, le Malawi, le Bangladesh et l'Éthiopie affichent également un taux d'adoption d'Android de 95 % ou plus. Android totalisait au minimum 50 % du trafic mobile dans 175 pays ou régions. La proportion de 51 % des Bahamas place le pays en bas de cette liste. 

^{Répartition de l'utilisation d'iOS et d'Android en 2025}

Le réseau Internet dans son ensemble repose sur le protocole HTTP (HyperText Transfer Protocol). Il a connu plusieurs révisions majeures au cours des 30 dernières années. La première version normalisée, HTTP/1.0, a été adoptée en 1996, le HTTP/1.1 en 1999 et le HTTP/2 en 2015. Le HTTP/3, normalisé en 2022, constituait une mise à jour d'importance, car il fonctionne sur un nouveau protocole de transport nommé QUIC. L'utilisation du QUIC pour assurer le transport sous-jacent permet au protocole HTTP/3 d'établir des connexions plus rapidement et de se montrer plus performant en atténuant les effets des pertes de paquets et des changements de réseau. Le HTTP/3 permet en outre d'atténuer le risque d'attaques, car il propose également le chiffrement par défaut. 

50 % des requêtes mondiales adressées à Cloudflare en 2025 ont été effectuées à l'aide du protocole HTTP/2. Le HTTP/1.x totalisait 29 % de ces dernières, tandis que les 21 % restants s'appuyaient sur le HTTP/3. Ces parts n'ont quasiment pas évolué depuis 2024. Le HTTP/2 et le HTTP/3 n'ont gagné que quelques fractions de point cette année.

^{Répartition du trafic en fonction de la version HTTP sur l'année 2025 (échelle mondiale)}

Du point de vue géographique, l'utilisation du HTTP/3 semble à la fois augmenter et s'étendre. Nous avions remarqué l'année dernière que huit pays/régions envoyaient plus d'un tiers de leurs requêtes par l'intermédiaire du HTTP/3. 15 pays/régions ont envoyé plus d'un tiers des requêtes à l'aide du HTTP/3 en 2025. Le taux d'adoption de 38 % affiché par la Géorgie dépasse désormais de peu le taux d'adoption maximal de 37 % observé à la Réunion en 2024. (L'examen des données historiques révèle que la Géorgie a commencé l'année autour des 46 % d'adoption HTTP/3, mais que ce taux a ensuite reculé au cours du premier semestre avant de se stabiliser.) L'Arménie a connu la plus forte augmentation de l'adoption du protocole HTTP/3 par rapport à l'année précédente, en passant de 25 à 37 %. 

Sept pays/régions (Hong Kong, la Dominique, Singapour, l'Irlande, l'Iran, le Paraguay et Gibraltar) ont constaté une utilisation globale du protocole HTTP/3 inférieure à 10 % en raison de la forte proportion de trafic HTTP/1.x lié aux bots.

Afin de proposer un site web moderne, les développeurs doivent être capables d'intégrer une collection croissante de bibliothèques et de cadres de travail à des plateformes et des outils tiers. Tous ces éléments doivent fonctionner ensemble afin d'assurer une expérience performante, riche en fonctionnalités et sans problème à l'utilisateur. Comme les années précédentes, nous nous sommes servis de l'outil URL Scanner de Cloudflare Radar pour analyser les sites web associés aux 5 000 principaux domaines afin d'identifier les technologies et les services les plus populaires parmi 11 catégories. 

jQuery se décrit elle-même comme une petite bibliothèque JavaScript rapide et riche en fonctionnalités. Notre analyse l'a identifiée sur huit fois plus de sites que Slick, une bibliothèque JavaScript servant à afficher des carrousels d'images. Le principal cadre JavaScript utilisé pour développer des interfaces web est resté React, que nous avons retrouvé sur deux fois plus de sites analysés que Vue.js. Les langages/technologies de programmation les plus populaires demeurent le PHP, le Node.js et le Java. Ces derniers conservent une avance considérable sur les autres langages, comme le Ruby, le Python, le Perl et le C.

^{Principales technologies utilisées sur les sites web en 2025, catégorie des bibliothèques JavaScript}

Bien que sa part de présence sur les sites analysés soit tombée à 47 %, WordPress est resté le système de gestion de contenu (CMS, Content Management System) le plus populaire. La différence avec l'ancien pourcentage est répartie sur les gains observés chez plusieurs concurrents. HubSpot et Marketo demeurent les principales plateformes d'automatisation du marketing, avec un accroissement de 10 % de leur part combinée par rapport à l'année précédente. Concernant les outils de test A/B, la part de VWO a augmenté de huit points par rapport à l'année précédente. Le service a ainsi renforcé son avance sur Optimizely, tandis que Google Optimize (dont l'abandon a été prononcé en septembre 2023) a vu sa part chuter de 14 à 4 %.

Les API (Application Programming Interfaces, interfaces de programmation d'applications) sont à la base des sites web dynamiques modernes, mais aussi des applications, à la fois web et natives. Ces sites et ces applications s'appuient ainsi fortement sur les appels d'API automatisés pour proposer des informations personnalisées. Nous pouvons identifier les appels adressés aux points de terminaison d'API grâce à l'analyse du trafic web protégé et diffusé par Cloudflare. Nous pouvons ensuite identifier les principaux langages utilisés pour développer des clients API en appliquant de méthodes heuristiques (déterminées comme ne provenant pas d'un utilisateur se servant d'un navigateur ou d'une application mobile native) à ces requêtes liées aux API.

20 % des appels d'API automatisés ont été effectués par des clients basés sur Go en 2025, soit une croissance significative par rapport à la proportion de 12 % enregistrée pour le Go en 2024. La part du Python a également augmenté par rapport à l'année précédente et est passée de 9,6 à 17 %. Le Java a fait un bond à la troisième place avec une part de marché de 11,2 %, contre 7,4 % en 2024. Le Node.js, le deuxième langage le plus populaire l'année dernière, a vu sa part chuter à seulement 8,3 % en 2025. Il a ainsi été relégué à la quatrième place, tandis que .NET a conservé sa place en bas du top 5, après la chute de sa part à seulement 2,3 %.

^{Les langages les plus populaires dans les clients API automatisés en 2025}

Comme nous assurons la protection des sites web et des applications de millions de clients, Cloudflare est particulièrement bien placée pour évaluer la part de marché des moteurs de recherche. Nous publions à cette fin des rapports trimestriels sur ces données depuis le quatrième trimestre 2021. Dans le cadre de notre méthodologie, nous utilisons l'en-tête Referer HTTP pour identifier le moteur de recherche à l'origine du trafic vers les sites et les applications de nos clients. Les données concernant la part de marché des moteurs de recherche sont présentées sous forme agrégée globale, mais aussi sous forme détaillée, par type d'appareil et par système d'exploitation. (Les informations sur le type d'appareil et le système d'exploitation s'appuient sur les données contenues dans les en-têtes de requête HTTP User-Agent et Client Hints.)

Avec une part de près de 90 % en 2025, c'est Google qui a renvoyé le plus de trafic vers des sites protégés et diffusés par Cloudflare à l'échelle mondiale. Les autres moteurs de recherche qui composent le top 5 sont Bing (3,1 %), Yandex (2 %), Baidu (1,4 %) et DuckDuckGo (1,2 %). L'observation des tendances de l'année révèle que Yandex est passé d'une part de 2,5 % au mois de mai à 1,5 % en juillet, tandis que celle de Baidu est passée de 0,9 % en avril à 1,6 % au mois de juin.

^{Parts de marché globales des moteurs de recherche en 2025 (échelle mondiale)}

Les utilisateurs de Yandex se situent principalement en Russie, où cette plateforme nationale détient une part de marché de 65 % (près du double de celle de Google, enregistrée à 34 %). Les utilisateurs de République tchèque préfèrent Google (84 %), mais la part de marché de 7,7 % du moteur de recherche local (Seznam) affiche un solide résultat par rapport aux moteurs de recherche placés en deuxième position dans d'autres pays. 

^{Parts de marché globales des moteurs de recherche en 2025 (République tchèque)}

La part de marché de Google pour le trafic issu de systèmes « desktop » (postes fixes) agrégé au niveau mondial chute à environ 80 %, tandis que celle de Bing bondit à près de 11 %. Ces chiffres résultent probablement de la domination continue du marché sur les systèmes Windows. Google ne totalise ainsi que 76 % du trafic sur Windows, tandis que la proportion de Bing est d'environ 14 %. Google détient près de 93 % des parts de marché concernant le trafic issu d'appareils mobiles (le trafic provenant des appareils Android et iOS affiche une part similaire).

^{Parts de marché globales des moteurs de recherche en 2025 (systèmes Windows)}

Vous trouverez davantage d'informations, notamment sur les moteurs de recherche regroupés sous la catégorie « Autres », dans les rapports trimestriels concernant les renvois effectués par les moteurs de recherche disponibles sur Cloudflare Radar.

Cloudflare bénéficie également d'une position unique pour mesurer les parts de marché des navigateurs. Nous publions d'ailleurs des rapports trimestriels sur le sujet depuis plusieurs années. Nous nous intéressons aux informations contenues dans les en-têtes HTTP User-Agent et Client Hints pour identifier le navigateur et le système d'exploitation associé à l'origine des requêtes de contenu. Les données concernant la part de marché des navigateurs sont présentées sous forme agrégée globale, mais aussi sous forme détaillée, par type d'appareil et par système d'exploitation. Veuillez noter que les parts de marché des navigateurs disponibles à la fois sur poste fixe et sur appareil mobile, comme Google Chrome ou Apple Safari, sont présentées sous forme agrégée.

Deux tiers du trafic de requêtes vers Cloudflare à l'échelle mondiale provenaient de Chrome en 2025, soit un chiffre similaire par rapport à l'année précédente. Exclusivement disponible sur les appareils Apple, Safari était le deuxième navigateur le plus populaire, avec une part de marché de 15,4 %. Ces deux têtes de liste étaient suivies par Microsoft Edge (7,4 %), Mozilla Firefox (3,7 %) et Samsung Internet (2,3 %). 

^{Parts de marché globales des navigateurs en 2025 (échelle mondiale)}

Avec une part de marché de 44 %, Chrome demeure le navigateur le plus populaire en Russie, tandis que le navigateur national Yandex arrive en deuxième position avec 33 % (contre moins de 10 % pour Safari, Edge et Opera). Il est intéressant de noter que le navigateur Yandex a en réalité dépassé Chrome d'un point au mois de juin (39 % contre 38 %), avant de céder beaucoup de terrain à Chrome à mesure que l'année avançait.

^{Parts de marché globales des navigateurs en 2025 (Russie)}

Fort de sa position de navigateur par défaut sur iOS, Safari est de loin le plus populaire sur ces appareils, avec une part de marché de 79 % (soit quatre fois celle de Chrome, enregistrée à 19 %). Moins de 1 % des requêtes sont issues de DuckDuckGo, Firefox et QQ Browser (un navigateur développé en Chine par Tencent). Sur Android, 85 % des requêtes proviennent de Chrome, en revanche, tandis que Samsung Internet (le navigateur fourni par le fabricant) arrive en deuxième position avec une proportion de 6,6 %. Huawei Browser (un autre navigateur fourni par un fabricant) arrive en troisième position avec seulement 1 %. Bien qu'il s'agisse du navigateur par défaut sur Windows, la part d'Edge est faible (19 %) par rapport à celle de Chrome, qui domine le marché avec une part de 69 % sur ce système d'exploitation.

^{Parts de marché globales des navigateurs en 2025 (appareils iOS)}

Vous trouverez davantage d'informations, notamment sur les navigateurs regroupés sous la catégorie « Autres », dans les rapports trimestriels concernant les parts de marché des navigateurs disponibles sur Cloudflare Radar.

Les pannes d'Internet demeurent une menace constante et l'impact potentiel de ces épisodes d'interruption ne cesse de croître, car ils sont susceptibles d'entraîner des pertes économiques, des perturbations au niveau des services éducatifs et administratifs, ainsi qu'une limitation des communications. Nous avons largement couvert les perturbations importantes d'Internet et leurs causes associées en 2025 dans nos récapitulatifs trimestriels (premier trimestre, deuxième trimestre, troisième trimestre), ainsi que dans des articles indépendants consacrés aux pannes majeures survenues au Portugal et en Espagne ou en Afghanistan. Notre centre de suivi des pannes, Cloudflare Radar Outage Center, effectue un suivi de ces perturbations Internet et s'appuie sur les données de Cloudflare concernant le trafic pour en analyser l'ampleur et la durée.

Près de la moitié des pannes observées cette année étaient liées à des coupures d'Internet visant à empêcher la tricherie lors des examens scolaires. Plusieurs pays, comme l'Irak, la Syrie et le Soudan, ont de nouveau mis en place des coupures régulières de plusieurs heures pendant plusieurs semaines cette année au moment des examens. D'autres gouvernements, comme ceux de Libye et de Tanzanie, ont également ordonné d'autres coupures en réponse à des manifestations et à des troubles civils, tandis qu'en Afghanistan, les Taliban ont décrété la coupure de la connectivité Internet par fibre optique dans plusieurs provinces afin « d'empêcher l'immoralité ».

Les ruptures de câbles, qui ont affecté à la fois les infrastructures sous-marines et les infrastructures nationales en fibre optique, ont également été l'une des principales causes de perturbations du réseau Internet en 2025. Ces coupures ont entraîné des épisodes d'interruption de service d'une durée de plusieurs heures à plusieurs jours chez les fournisseurs d'accès de plusieurs pays/régions, comme les États-Unis, l'Afrique du Sud, Haïti, le Pakistan et Hong Kong. Parmi les autres défaillances notables, on peut citer un incendie survenu au sein d'un bâtiment de télécommunications au Caire, en Égypte. Cet incident a perturbé la connectivité Internet de plusieurs fournisseurs de services pendant plusieurs jours. De même, les dégâts provoqués par l'ouragan Melissa en Jamaïque ont entraîné une baisse du trafic Internet en provenance de l'île pendant plus d'une semaine.

Passez votre curseur sur un point de la chronologie du microsite Year in Review pour afficher des informations sur un événement donné et cliquez dessus si vous souhaiter davantage de détails.

^{Plus de 170 pannes Internet majeures ont été observées à travers le monde en 2025}

L'espace d'adressage IPv4 disponible est largement épuisé depuis plus de dix ans, bien que diverses solutions, comme le NAT (Network Address Translation, traduction de l'adresse réseau) aient permis aux fournisseurs de service d'étendre leurs ressources IPv4 limitées. Ces mécanismes ont en partie contribué à ralentir l'adoption de l'IPv6, un protocole conçu au milieu des années 1990 comme successeur de l'IPv4 et disposant d'un espace d'adressage étendu destiné à mieux prendre en charge l'augmentation prévue du nombre d'appareils connectés à Internet.

Depuis près de 15 ans, Cloudflare a ardemment soutenu l'IPv6 en lançant diverses solutions, comme la passerelle Automatic IPv6 Gateway en 2011 (qui a permis la prise en charge gratuite d'IPv6 pour l'ensemble de nos clients) et la prise en charge du protocole IPv6 par défaut pour tous nos clients en 2014. En termes simples, la prise en charge côté serveur ne constitue que la moitié des outils dont nous avons besoin pour favoriser l'adoption de l'IPv6, car les connexions des utilisateurs finaux doivent également la prendre en charge. Nous pouvons dégager plus d'informations sur la répartition du trafic entre les protocoles IPv6 et IPv4 en agrégeant et en analysant la version de l'adresse IP utilisée pour les requêtes adressées à Cloudflare sur l'ensemble de l'année.

À l'échelle mondiale, 29 % des requêtes de contenu compatibles IPv6 (« dual-stack », double pile) ont été effectuées en IPv6, soit une augmentation d'un point par rapport aux 28 % de 2024. L'Inde arrive de nouveau en tête du classement avec un taux d'adoption de l'IPv6 de 67 %, suivie par seulement trois autres pays/régions (la Malaisie, l'Arabie saoudite et l'Uruguay) à avoir également effectué plus de la moitié de ces requêtes à l'aide du protocole IPv6, comme l'année dernière. Les gains les plus importants ont été observés au Belize (dont la part a augmenté de 4,3 % l'année dernière à 24 % aujourd'hui) et au Qatar, où le taux d'adoption a presque doublé pour atteindre les 33 % en 2025. Certains pays et certaines régions restent malheureusement en retard derrière les leaders en la matière. 94 pays affichent ainsi des taux d'adoption inférieurs à 10 %, notamment la Russie (8,6 %), l'Irlande (6,5 %) et Hong Kong (3 %). 20 pays/régions sont encore plus à la traîne avec des taux d'adoption inférieurs à 1 %, notamment la Tanzanie (0,9 %), la Syrie (0,3 %), et Gibraltar (0,1 %).

^{Répartition du trafic en fonction de la version IP sur l'année 2025 (échelle mondiale)}

^{Les cinq principaux pays d'adoption du protocole IPv6 en 2025}

De nombreuses raisons nous poussent à faire appel aux outils de tests de la vitesse disponibles sur Internet depuis une dizaine d'années environ : veiller à l'honnêteté de nos fournisseurs de services, dépanner une connexion qui pose problème ou publier un débit descendant particulièrement élevé sur les réseaux sociaux. En réalité, nous avons été ni plus ni moins formatés à nous concentrer sur le débit descendant comme principal indicateur de la qualité d'une connexion. Si cet indicateur revêt en effet une importance absolue, une faible latence et un débit ascendant élevé s'avèrent également essentiels dans bon nombre de scénarios d'utilisation de plus en plus populaires, comme la visioconférence, la diffusion en direct et les jeux vidéo en ligne. Or, l'adoption de ce point de vue par les consommateurs demeure mitigée en raison du coût, de la disponibilité ou d'autres problèmes, même lorsque les fournisseurs d'accès Internet proposent des niveaux de service qui incluent des vitesses symétriques élevées et une faible latence.

Les tests effectués sur speed.cloudflare.com mesurent à la fois le débit descendant et le débit ascendant, ainsi que la latence en et hors charge. L'agrégation des résultats des tests effectués partout dans le monde en 2025 nous permet d'obtenir une perspective par pays/région concernant les valeurs moyennes de ces indicateurs de qualité de connexion, ainsi que des informations sur la répartition de ces mesures.

L'Europe était bien représentée parmi les pays qui affichaient les débits descendants moyens les plus élevés en 2025. L'Espagne, la Hongrie, le Portugal, le Danemark, la Roumanie et la France figuraient ainsi dans le top 10 du classement, notamment l'Espagne et la Hongrie avec un débit descendant moyen supérieur à 300 Mbit/s. Le débit moyen de l'Espagne a ainsi augmenté de 25 Mbit/s par rapport à 2024, tandis que celui de la Hongrie a gagné 46 Mbit/s. En parallèle, les pays d'Asie affichaient certains des débits ascendants moyens les plus élevés. La Corée du Sud, Macao, Singapour et le Japon ont ainsi intégré les 10 premières places du classement, avec un débit ascendant supérieur à 130 Mbit/s

C'est toutefois l'Espagne qui est encore arrivée en tête pour l'indicateur de débit ascendant avec 206 Mbit/s, soit 13 Mbit/s de plus qu'en 2024. Les solides performances du pays sur ces deux indicateurs de vitesse découlent potentiellement de « l'UNICO-Broadband », un « appel à projets lancé par des opérateurs de télécommunications en vue du déploiement d'une infrastructure broadband à haut débit capable de proposer un service à des vitesses symétriques d'au moins 300 Mbit/s, extensibles à 1 Gbit/s » afin de couvrir 100 % de la population en 2025.

^{Les pays et régions affichant les débits descendants les plus élevés en 2025 (échelle mondiale)}

Comme mentionné ci-dessus, une connexion faible latence est nécessaire afin d'assurer une expérience satisfaisante aux utilisateurs en matière de jeux vidéo et de vidéoconférence/diffusion en direct. L'indicateur de latence peut être décomposé en deux : la latence en charge et la latence au repos. Le premier indicateur mesure la latence sur une connexion chargée, c'est-à-dire une connexion qui utilise activement la bande passante, tandis que le second mesure la latence d'une connexion au repos (ou « inactive »), c'est-à-dire qui ne connaît pas d'autre trafic réseau. (Ces définitions sont proposées du point de vue de l'application de test de la vitesse.) 

Un certain nombre de pays européens figuraient au rang des pays qui présentaient les latences les plus faibles en 2025, tant au repos qu'en charge. L'Islande a enregistré la latence au repos la plus faible avec 13 ms, soit seulement 2 ms de mieux que la Moldavie. Le Portugal, l'Espagne et la Hongrie figuraient également dans les dix premiers, avec une latence au repos moyenne inférieure à 20 ms. La Moldavie arrive en tête du classement des pays/régions présentant la latence en charge moyenne la plus faible, avec 73 ms. La Hongrie, l'Espagne, la Belgique, le Portugal, la Slovaquie et la Slovénie figuraient également dans le top 10, avec une latence en charge moyenne inférieure à 100 ms.

^{Latence mesurée au repos/en charge : Moldavie}

Comme mentionné ci-dessus, les tests de vitesse effectués sur speed.cloudflare.com mesurent la vitesse et la latence de la connexion d'un utilisateur. Nous avons examiné les résultats agrégés de ces tests, en mettant en valeur les pays/régions qui ont obtenu les meilleurs résultats. Nous nous sommes également interrogés sur les tests effectués partout à travers le monde : à quel endroit les utilisateurs sont-ils le plus préoccupés par la qualité de leur connexion et à quelle fréquence procèdent-ils à ces tests ? Le bilan Year in Review propose une nouvelle visualisation animée pour illustrer l'activité liée aux tests de vitesse, agrégée chaque semaine.

Les données sont agrégées au niveau régional et l'activité associée est indiquée sur la carte sous forme de cercles d'une taille proportionnelle au nombre de tests effectués chaque semaine. Veuillez noter que les lieux dans lesquels les utilisateurs effectuent moins de 100 tests de vitesse par semaine ne sont pas représentés. Si l'on considère le volume de tests sur l'année, les régions du Grand Londres et de Los Angeles se sont révélées les plus actives, à l'instar de Tokyo, de Hong Kong et de plusieurs villes américaines.

L'animation du graphique permettant de visualiser les changements survenus au cours de l'année révèle plusieurs pics hebdomadaires du volume de tests. Ces pics comprennent la région de Nairobi, au Kenya, pendant la période de sept jours qui précèdent le 10 juin, la région de Téhéran, en Iran, pendant la période qui précède le 29 juillet, plusieurs régions de Russie pendant la période qui précède le 5 août et la région de Karnataka, en Inde, pendant la période qui précède le 28 octobre. Les causes à l'origine de ces augmentations du volume de tests ne sont pas claires. Le Cloudflare Radar Outage Center n'a observé aucune panne d'Internet au sein de ces régions et sur ces périodes. Il est donc peu probable qu'il s'agisse d'abonnés procédant à des tests pour savoir si leur connectivité a été rétablie.

^{Activité des tests de vitesse effectués à l'aide de l'outil Cloudflare en 2025, répartition en fonction de la position géographique}

Pour le meilleur ou pour le pire, les appareils mobiles sont devenus un élément indispensable de la vie quotidienne ces 25 dernières années. L'adoption de ces appareils varie à travers le monde : les statistiques de la Banque mondiale indiquent que plusieurs pays/régions présentent un taux de possession de téléphone mobile supérieur à 90 % en date d'octobre 2025, tandis que ce taux est inférieur à 10 % dans plusieurs autres. Les appareils mobiles se connectent principalement à Internet en Wi-Fi dans certains pays et certaines régions, tandis que d'autres sont « mobile first » (orientés mobile, c'est-à-dire que le service 4G/5G y constitue le principal moyen d'accès à Internet).

Les informations contenues dans l'en-tête User-Agent qui accompagne chaque requête adressée à Cloudflare nous permettent de catégoriser cette dernière comme issue d'un appareil mobile, d'un poste fixe ou d'un autre type d'appareil. L'agrégation de cette catégorie à l'échelle mondiale a révélé que 43 % des requêtes avaient été émises par des appareils mobiles en 2025, contre 41 % en 2024. Le reste provenait d'ordinateurs portables et de postes fixes « classiques ». Similaires aux valeurs relevées l'année dernière, ces parts de trafic sont conformes aux valeurs mesurées dans les divers rapports Year in Review depuis 2022. Ces chiffres suggèrent donc que l'utilisation des appareils mobiles a atteint un « état stable ».

Plus de la moitié des requêtes provenaient d'appareils mobiles dans 117 pays ou régions, parmi lesquels le Soudan et le Malawi arrivent en tête, avec une part respective de 75 et de 74 %. Cinq autres pays/régions d'Afrique, l'Eswatini (Swaziland), le Yémen, le Botswana, le Mozambique et la Somalie, ont également enregistré une proportion de requêtes mobiles supérieure à 70 % en 2025, en accord avec la forte pénétration de la téléphonie mobile au sein du continent. Parmi les pays/régions qui présentent une faible proportion de trafic mobile, Gibraltar est le seul endroit à afficher un taux inférieur 10 % (avec 5,1 %), tandis que seulement six autres pays/régions ont enregistré un taux de requêtes mobiles de moins d'un quart. C'est moins qu'en 2024, où une douzaine de pays/régions faisaient état d'une proportion de trafic d'origine mobile inférieure à 25 %.

^{Répartition du trafic en fonction du type d'appareil sur l'année 2025 (échelle mondiale)}

^{Répartition mondiale du trafic en fonction du type d'appareil sur l'année 2025}

Cloudflare atténue automatiquement le trafic hostile visant les sites web et les applications à l'aide de techniques d'atténuation des attaques DDoS ou des règles gérées du pare-feu applicatif web (WAF, Web Application Firewall) afin de les protéger ses clients contre toute une gamme de menaces posées par les acteurs malveillants. Nous permettons également aux clients d'atténuer le trafic (même s'il n'est pas malveillant) en utilisant diverses techniques, comme le contrôle du volume des requêtes ou le blocage de l'ensemble du trafic issu d'une position géographique donnée. La nécessité de procéder ainsi peut être motivée par des exigences réglementaires ou commerciales. Nous avons examiné la part globale du trafic vers le réseau Cloudflare atténuée pour une raison ou pour une autre en 2025, ainsi que la part bloquée, car le trafic était lié à une attaque DDoS ou que son blocage avait été décidé par les règles gérées du pare-feu WAF.

6,2 % du trafic mondial a été atténué cette année, soit une baisse d'un quart de point par rapport à 2024. 3,3 % du trafic a été atténué du fait de son appartenance à une attaque DDoS ou parce que son atténuation découlait de règles gérées, soit une augmentation d'un dixième de point par rapport à l'année précédente. Des mesures d'atténuation générales ont été appliquées à plus de 10 % du trafic en provenance de plus de 30 pays/régions, ainsi que des mesures d'atténuation DDoS/WAF à plus de 10 % du trafic originaire de 14 pays/régions. Ces deux chiffres étaient en baisse par rapport à 2024. 

La Guinée équatoriale a enregistré les parts de trafic atténué les plus importantes, avec 40 % du trafic atténué de manière générale et 29 % à l'aide de mesures d'atténuation DDoS/WAF. Ces parts ont augmenté par rapport à l'année précédente. Elles étaient alors de 26 % (atténuation générale) et de 19 % (atténuation DDoS/WAF). À l'inverse, la Dominique a affiché les plus faibles parts de trafic atténué, avec seulement 0,7 % du trafic atténué. L'application de mesures d'atténuation DDoS/WAF n'a eu lieu que pour 0,1 % du trafic.

La forte augmentation du trafic atténué constatée au mois de juillet sur le graphique ci-dessous découle d'une campagne d'attaques DDoS de très grande ampleur qui s'est principalement concentrée sur un unique domaine d'un client Cloudflare.

^{Tendances du trafic atténué sur l'année 2025 (échelle mondiale)}

Le terme bot désigne une application logicielle programmée pour effectuer certaines tâches. Cloudflare fait appel à des outils heuristiques avancés pour différencier le trafic des bots du trafic d'origine humaine, en attribuant un score à chaque requête en fonction de la probabilité qu'elle provienne d'un bot ou d'un utilisateur humain. Les propriétaires de sites et d'applications peuvent identifier et (si nécessaire) bloquer les activités potentiellement malveillantes en surveillant le trafic soupçonné d'avoir été émis par des bots. Tous les bots ne sont cependant pas malveillants. Certains sont même utiles. Cloudflare tient à jour un répertoire des bots vérifiés qui recense les bots utilisés à des fins d'indexation pour les moteurs de recherche, d'analyses de sécurité, ainsi que de surveillance des sites et des applications. Quelle que soit son intention, nous avons analysé l'origine du trafic lié aux bots en 2025, en utilisant l'adresse IP d'une requête afin d'identifier le réseau (système autonome) et la région ou le pays associé au bot effectuant la requête. 

Les 10 premiers pays/régions du classement totalisaient 71 % du trafic lié aux bots observé à l'échelle mondiale. 40 % de ce trafic était issu des États-Unis, loin devant les 6,5 % de l'Allemagne. La part des États-Unis a augmenté de plus de cinq points par rapport à 2024, tandis que celle de l'Allemagne a diminué d'une fraction de point. Les pays restants du top 10 ont tous contribué au total avec des parts de trafic lié aux bots inférieures à 5 % en 2025.

^{Répartition du trafic mondial lié aux bots en fonction du pays/de la région d'origine en 2025}

L'étude du trafic lié aux bots selon l'angle du réseau nous a permis de constater que les plateformes cloud figuraient toujours parmi les principales sources. Ce constat découle de plusieurs facteurs, notamment la facilité d'utilisation des outils automatisés pour provisionner rapidement des ressources de calcul, leur coût relativement faible, leur vaste couverture géographique et la connectivité Internet à large bande passante de ces plateformes. 

Deux systèmes autonomes (AS, Autonomous Systems) associés à Amazon Web Services représentaient un total de 14,4 % du trafic automatisé observé, tandis que deux systèmes associés à Google Cloud étaient responsables d'une part combinée 9,7 % du trafic lié aux bots. Ces quatre AS étaient suivis par Microsoft Azure, à l'origine de 5,5 % du trafic automatisé. Les parts de ces trois plateformes étaient en hausse par rapport à 2024. Ces plateformes cloud disposent d'une forte présence en termes de datacenters régionaux dans de nombreux pays et de nombreuses régions du top 10. Les fournisseurs de télécommunications locaux représentaient fréquemment la plus grande partie du trafic automatisé observé partout ailleurs que dans ces pays et régions.

^{Répartition du trafic mondial lié aux bots en fonction du réseau en 2025}

Les acteurs malveillants changent en permanence de tactiques et de cibles. Ils diversifient leurs approches pour échapper à la détection ou en fonction des dégâts qu'ils souhaitent provoquer. Ils peuvent, par exemple, essayer de causer un préjudice financier aux entreprises en ciblant des sites d'e-commerce pendant une période de forte affluence, adresser un message politique en s'en prenant à des sites gouvernementaux ou liés à la société civile, voire tenter d'entraîner la mise hors ligne de leurs adversaires dans un jeu vidéo en s'attaquant aux serveurs de ce dernier. Pour identifier les activités hostiles visant une verticale particulière au cours de l'année 2025, nous avons analysé le trafic atténué des clients dont le dossier spécifiait un secteur d'activité et une verticale. Nous avons ainsi agrégé le trafic atténué sur une base hebdomadaire en fonction du pays/de la région source dans 17 verticales cibles.

Les entreprises de la verticale « Population et société » ont été les plus visées cette année, avec 4,4 % de l'ensemble du trafic atténué à destination de cette dernière. Les clients classés dans la catégorie « Population et société » comprennent les institutions religieuses, les organisations à but non lucratif, les associations citoyennes et sociales, ainsi que les bibliothèques. La verticale a commencé l'année en recevant moins de 2 % du trafic atténué, mais a vu cette part bondir à 10 % la semaine du 5 mars, pour augmenter à plus de 17 % à la fin du mois. D'autres pics d'attaques à l'encontre de ces sites se sont produits fin avril (19,1 %) et début juillet (23,2 %). Bon nombre de ces entreprises sont protégées dans le cadre du projet Galileo de Cloudflare. Cet article de blog détaille les attaques et les menaces subies par ces entreprises en 2024 et 2025.

Le secteur des jeux/jeux de hasard (c'est-à-dire la verticale la plus ciblée l'année dernière) a vu sa part d'attaques atténuées chuter de plus de moitié par rapport à l'année précédente, pour atteindre seulement 2,6 % cette année. Alors que l'on aurait pu s'attendre à ce que les attaques à l'encontre des sites de jeux d'argent atteignent un pic lors des événements sportifs majeurs, comme le Super Bowl et la March Madness (la « folie de mars », le tournoi final de l'association nationale de basket universitaire, qui suscite un fort engouement aux États-Unis), cette tendance ne s'est cependant pas vérifiée. La part des attaques a culminé à 6,5 % la semaine du 5 mars, soit un mois après le Super Bowl et quelques semaines avant le début de la March Madness.

^{Part mondiale du trafic atténué en 2025, répartition en fonction de la verticale, vue d'ensemble}

Le BGP (Border Gateway Protocol, protocole de passerelle en bordure) est le protocole de routage principal d'Internet. Il permet au trafic de circuler entre sa source et sa destination en communiquant les itinéraires entre les réseaux. Toutefois, comme il repose sur la confiance entre les réseaux connectés, les inexactitudes au niveau des informations partagées entre pairs (intentionnellement ou non) peuvent envoyer le trafic au mauvais endroit, potentiellement vers des systèmes contrôlés par un acteur malveillant. Pour remédier à ce problème, les acteurs d'Internet ont développé la RPKI (Resource Public Key Infrastructure, infrastructure de gestion des clés publiques de ressources) comme moyen de chiffrement permettant de signer les enregistrements qui associent une annonce de routage BGP au numéro de système autonome (AS, Autonomous System) d'origine approprié afin de s'assurer que les informations partagées proviennent bien d'un réseau autorisé à le faire initialement. Cloudflare soutient ardemment la sécurité du routage, notamment en tant que membre fondateur du programme MANRS consacré au CDN et au cloud, mais aussi en proposant un outil public qui permet aux utilisateurs de tester si leur fournisseur d'accès à Internet a mis en œuvre le protocole BGP de manière sécurisée. 

Nous avons analysé les données disponibles sur la page Routing (Routage) de Cloudflare Radar afin de déterminer la proportion des itinéraires RPKI valides et la manière dont cette part a évolué au cours de l'année 2025, ainsi que la part de l'espace d'adressage IP couvert par des itinéraires valides. Ce dernier indicateur revêt une importance particulière, car une annonce de routage couvrant une grande partie d'un espace d'adressage IP (des millions d'adresses IPv4) présente un impact potentiel plus important qu'une annonce couvrant un petit bloc d'espace d'adressage IP (des centaines d'adresses IPv4).

Nous avons commencé l'année 2025 avec 50 % d'itinéraires IPv4 valides, pour atteindre un pourcentage de 53,9 % au 2 décembre. La part des itinéraires IPv6 valides, quant à elle, a pris 4,7 points pour se stabiliser à 60,1 %. L'examen de la part globale de l'espace d'adressage IPv4 couvert par des itinéraires valides révèle que cette dernière est désormais de 48,5 %, soit une augmentation de trois points par rapport à l'année précédente. La proportion de l'espace d'adressage IPv6 couvert par des itinéraires valides a légèrement diminué, à 61,6 %. Malgré le ralentissement de ces indicateurs par rapport à l'année passée, nous avons accompli des progrès considérables ces cinq dernières années. Depuis le début de la décennie 2020, les parts correspondant aux itinéraires IPv4 RPKI valides et à l'espace d'adressage IPv4 ont toutes deux été multipliées par un facteur d'environ trois.

^{Parts des entrées de routage RPKI valides au niveau mondial en 2025, répartition en fonction de la version IP}

^{Parts de l'espace d'adressage IP annoncé au niveau mondial couvert par des itinéraires RPKI valides en 2025}

C'est La Barbade qui a connu la plus forte croissance de la part de ses itinéraires IPv4 valides, avec une progression de 2,2 % à 20,8 %. Du point de vue des itinéraires IPv6 valides, c'est la part du Mali qui a enregistré la plus forte croissance en 2025 en passant de 10 % à 58,3 %. 

La Barbade a également connu la plus forte augmentation de sa part de l'espace IPv4 couvert par des itinéraires valides, en passant de 2 % à 18,6 %. Concernant l'espace d'adressage IPv6, le Tadjikistan et la Dominique sont passés d'un espace qui n'était dans les faits couvert par aucun itinéraire valide au début de l'année, à une proportion de respectivement 5,5 et 3,5 %. 

Dans notre série de rapports trimestriels sur les attaques DDoS (T1, T2, T3), nous avons souligné la fréquence et l'ampleur croissantes des attaques hyper-volumétriques sur la couche réseau ciblant les clients et l'infrastructure de Cloudflare. Nous qualifions les « attaques hyper-volumétriques sur la couche réseau » comme les attaques qui visent la couche 3/4 et dont le volume dépasse un térabit (1 Tbit/s) par seconde ou un milliard de paquets par seconde (1 Gp/s). Ces rapports proposent une perspective trimestrielle, mais nous souhaitions également vous présenter une vue de l'activité sur l'ensemble de l'année afin de vous permettre de mieux comprendre à quel moment les acteurs malveillants sont les plus actifs et l'évolution de la taille des attaques au fil du temps. 

En s'intéressant à l'activité liée aux attaques hyper-volumétriques de l'année 2025 du point de vue des Tbit/s, on remarque que le mois de juillet a enregistré le plus grand nombre d'attaques de ce type (plus de 500), tandis que le mois de février en a enregistré le moins (un peu plus de 150). Si l'intensité des attaques est généralement restée sous la barre des 5 Tbit/s, une attaque de 10 Tbit/s bloquée à la fin du mois d'août s'est révélée comme un signe avant-coureur des événements qui allaient se produire. Cette attaque a été la première d'une campagne d'attaques d'ampleur supérieure à 10 Tbit/s qui s'est déroulée pendant la première semaine de septembre, en préambule d'une série d'attaques d'un volume supérieur à 20 Tbit/s au cours de la dernière semaine du mois. Nous avons observé plusieurs attaques hyper-volumétriques de plus grande taille au début du mois d'octobre et la plus volumineuse de ces dernières a culminé à 29,7 Tbit/s. Ce record a été bien vite éclipsé lorsqu'une attaque survenue début novembre a atteint un pic de 31,4 Tbit/s

L'activité des attaques hyper-volumétriques s'est montrée beaucoup plus faible du point de vue des Gp/s (milliards de paquets par seconde). C'est le mois de novembre qui a enregistré le plus grand nombre d'attaques (plus de 140), tandis que seulement trois ont été observées en février et en juin. L'intensité des attaques sur l'ensemble de l'année est généralement restée sous la barre des 4 Gbit/s jusqu'à fin août, bien qu'une succession d'attaques de plus en plus volumineuses aient été observées au cours des mois suivants, avec un point culminant en octobre. Si l'intensité de la plus grande partie des plus de 110 attaques bloquées au mois d'octobre s'est révélée inférieure à 5 Gp/s, une attaque culminant à 14 Gp/s a été observée pendant le mois. Cette attaque volumétrique, la plus volumineuse bloquée cette année en termes de paquets par seconde, a surpassé cinq autres attaques records observées en septembre et associées à cette campagne d'attaques successives.

^{Ampleur maximale des attaques DDoS en 2025}

Les statistiques récentes suggèrent que, malgré l'utilisation croissante des applications collaboratives et des applications de messagerie par les entreprises, le courrier électronique demeure le principal canal de communication pour les contacts professionnels externes. Du fait de sa vaste utilisation en milieu professionnel, les acteurs malveillants continuent de le considérer comme un séduisant point d'accès aux réseaux des entreprises. Les outils d'IA générative facilitent la production d'e-mails malveillants très ciblés, qui imitent de manière convaincante des marques de confiance ou des expéditeurs légitimes (les dirigeants d'une entreprise, par exemple), mais contiennent des liens trompeurs, des pièces jointes dangereuses ou d'autres types de menaces. La solution Cloudflare Email Security protège nos clients contre les attaques de phishing, notamment celles conduites par l'intermédiaire d'e-mails malveillants ciblés. 

En moyenne, 5,6 % des e-mails analysés par Cloudflare se sont révélés malveillants en 2025. La proportion de messages traités par le service Cloudflare Email Security qui se sont avérés malveillants se situait généralement entre 4 % et 6 % la majeure partie de l'année. Nos données indiquent une augmentation de la part des e-mails malveillants à partir d'octobre, probablement suite à la mise en œuvre d'un système de classification amélioré mis au sein du service Cloudflare Email Security.  

^{Tendances mondiales des e-mails malveillants en 2025}

Les liens trompeurs constituaient la principale catégorie de menaces véhiculées par e-mail en 2025. Ils étaient ainsi présents dans 52 % des messages, contre 43 % en 2024. Comme le texte affiché pour un hyperlien est en HTML peut être défini de manière arbitraire, les acteurs malveillants peuvent amener les utilisateurs à croire qu'une URL renvoie vers un site légitime (alors qu'elle est en réalité malveillante) afin de dérober des identifiants de connexion ou de télécharger des logiciels malveillants. La proportion d'e-mails traités contenant des liens trompeurs a atteint les 70 % une première fois fin avril et de nouveau à la mi-novembre.

On parle d'usurpation d'identité lorsqu'un acteur malveillant envoie un e-mail en se faisant passer pour une autre personne. Ils peuvent y parvenir en utilisant des domaines similaires en apparence, usurpés ou mettant en œuvre une supercherie au niveau du nom d'affichage afin de donner l'illusion de provenir d'un domaine de confiance. L'usurpation de marque est une forme d'usurpation d'identité dans laquelle un acteur malveillant envoie un e-mail de phishing qui usurpe l'identité d'une entreprise ou d'une marque aisément reconnaissable. La technique de l'usurpation de marque peut également faire appel à l'usurpation du nom d'affichage ou l'usurpation de domaine. L'usurpation d'identité (38 %) et l'usurpation de marque (32 %) se sont révélées deux menaces croissantes en 2025 (leurs pourcentages respectifs étaient de 35 % et de 23 % en 2024). Ces deux menaces ont pris leur essor à la mi-novembre.

^{Tendances de la catégorie des menaces véhiculées par e-mail sur l'année 2025 (échelle mondiale)}

En plus de proposer des informations sur le trafic, la répartition géographique et les certificats numériques pour les domaines de premier niveau (TLD, Top Level Domains) tels que .com ou .us, Cloudflare Radar propose également des informations sur les TLD « les plus utilisés », c'est-à-dire les domaines à l'origine de la plus grande proportion d'e-mails malveillants et de courrier indésirable d'après l'analyse des messages effectuée par la solution Cloudflare Email Security. L'analyse se base sur le TLD du domaine de l'expéditeur, consigné dans l'en-tête De : (From:) décrivant la provenance d'un e-mail. Ainsi, dans le cas d'un message envoyé par sender@example.com, par exemple, example.com représente le domaine d'envoi, tandis que « .com » constitue le TLD associé. Pour l'analyse présentée dans le bilan Year in Review, nous n'avons inclus que les TLD sur lesquels nous avons observé une activité minimum de 30 messages par heure en moyenne.

Suite à l'analyse des messages tout au long de l'année 2025, nous avons découvert que les TLD .christmas et .lol étaient les plus utilisés à des fins abusives. En effet, 99,8 % et 99,6 % des e-mails envoyés par ces TLD étaient respectivement identifiés comme indésirables ou malveillants. Après tri de la liste des TLD en fonction de leur proportion d'e-mails malveillants, les TLD .cfd et .sbs affichaient tous les deux un pourcentage de plus de 90 % d'e-mails classés comme malveillants parmi l'ensemble des messages analysés. Le TLD .best était le pire en termes de courrier indésirable, avec 69 % des e-mails considérés comme tels.

^{Les TLD à l'origine de la plus grande proportion d'e-mails malveillants et indésirables en 2025}

Internet et le web continuent certes d'évoluer et de se transformer au fil du temps, mais il semble que certains indicateurs essentiels soient désormais relativement stabilisés. Nous nous attendons toutefois à ce que d'autres indicateurs, comme ceux qui suivent les tendances de l'IA, changent eux aussi ces prochaines années du fait de l'évolution rapide de cet espace. 

Nous vous encourageons à consulter le microsite Cloudflare Radar 2025 Year In Review et à explorer les tendances pour votre pays/région, et à réfléchir à leur impact sur votre organisation lorsque vous planifiez pour 2026. Vous pouvez également obtenir des informations quasi-temps réel sur un grand nombre de ces indicateurs et tendances sur Cloudflare Radar. Comme indiqué ci-dessus, pour obtenir des informations sur les principaux services Internet dans plusieurs catégories de secteurs et pays/régions, nous vous invitons à consulter l'article de blog complémentaire Bilan de l'année.

N'hésitez pas à contacter l'équipe Cloudflare Radar sur radar@cloudflare.com ou sur les réseaux sociaux @CloudflareRadar (X), https://noc.social/@cloudflareradar (Mastodon) et radar.cloudflare.com (Bluesky) si vous avez des questions.

De l'agrégation à l'analyse des données, en passant par la conception du microsite ou le développement du contenu associé, la production de notre bilan annuel Year in Review constitue une œuvre véritablement collective. Je tiens donc à remercier tous les membres de l'équipe qui ont contribué aux efforts de cette année, notamment : Jorge Pacheco, Sabina Zejnilovic, Carlos Azevedo, Mingwei Zhang, Sofia Cardita (analyse des données), André Páscoa, Nuno Pereira (développement front-end), João Tomé (les services Internet les plus populaires), David Fidalgo, Janet Villarreal et l'équipe d'internationalisation (traductions), Jackie Dutton, Kari Linder, Guille Lasarte (communication), Laurel Wamsley (rédaction des articles de blog) et Paula Tavares (gestion de la technique), ainsi que tous nos autres collègues chez Cloudflare pour leur soutien et leur assistance.

Le 5 décembre 2025 à 8 h 47 UTC (toutes les heures mentionnées dans ce blog sont au format UTC), une partie du réseau Cloudflare a commencé à connaître des défaillances significatives. L'incident a été résolu à 9 h 12 avec le rétablissement complet de l'ensemble des services (au total, le problème s'est donc fait sentir pendant environ 25 minutes).

Le sous-ensemble de clients affectés totalisait près de 28 % de l'ensemble du trafic HTTP diffusé par Cloudflare. La réunion de plusieurs facteurs était nécessaire pour qu'un client particulier soit touché selon les modalités décrites ci-après.

Le dysfonctionnement ne résultait en aucune façon d'une cyberattaque ou d'une quelconque activité malveillante sur les systèmes Cloudflare, ni directement ni indirectement. Il découlait de modifications que nous avons apportées à notre logique d'analyse du corps des requêtes lors d'une tentative visant à détecter et à atténuer une vulnérabilité des React Server Components (composants serveur React) révélée cette semaine et affectant l'ensemble du secteur.

Toute forme d'interruption de nos systèmes est inacceptable et nous savons que nous avons encore une fois déçu la communauté Internet après l'incident déjà survenu le 18 novembre. Restez à l'écoute de nos canaux la semaine prochaine, nous publierons des informations détaillées sur les mesures que nous comptons prendre pour éviter que ce type de dysfonctionnement se reproduise.

Le graphique ci-dessous présente le nombre d'erreurs HTTP 500 émises par notre réseau sur l'ensemble de la période de l'incident (ligne rouge en bas) par rapport au trafic Cloudflare total non affecté par le problème (ligne verte en haut).

Le pare-feu applicatif web (Web Application Firewall, WAF) de Cloudflare assure une protection contre le contenu malveillant à nos clients afin de leur permettre de détecter et de bloquer ce dernier. Pour ce faire, le proxy Cloudflare place le contenu du corps de la requête HTTP en mémoire tampon afin de procéder à son analyse. La taille du tampon était jusqu'ici de 128 Ko.

Dans le cadre des efforts que nous menons pour protéger nos clients utilisateurs de React contre la vulnérabilité critique dénommée CVE-2025-55182, nous avons commencé à déployer une augmentation de la taille de notre mémoire tampon à 1 Mo, la limite autorisée par défaut pour les applications Next.js afin de nous assurer de protéger le plus grand nombre de clients possible.

L'implémentation de cette première modification a été confiée à notre système de déploiement progressif. Nous avons remarqué lors du déploiement que notre outil interne chargé de tester le pare-feu WAF ne prenait pas en charge l’augmentation de la taille de la mémoire tampon. Comme cet outil de test interne n’était pas nécessaire à l’époque et qu’il n’affectait en aucune façon le trafic de nos clients, nous avons procédé à une deuxième modification afin de le désactiver.

Cette deuxième modification visant à désactiver notre outil de test du pare-feu WAF a été déployée à l'aide de notre système de configuration mondial. Ce système ne procède pas par déploiements progressifs, mais propage les modifications en quelques secondes à l’ensemble de la flotte de serveurs qui composent notre réseau. Il est d'ailleurs toujours en cours d'examen suite au dysfonctionnement survenu le 18 novembre. 

Malheureusement, certaines circonstances entourant le déploiement de cette deuxième modification (conçue, rappelons-le, pour désactiver notre outil de test des règles WAF) au sein de la version FL1 de notre proxy ont entraîné une erreur, qui a abouti à l’émission de codes d’erreur HTTP 500 depuis notre réseau.

Lorsque la modification s'est propagée à notre réseau, l'exécution du code au sein de notre proxy FL1 a débouché sur un bug présent dans notre module de règles, qui a conduit à l'exception Lua suivante :

[lua] Failed to run module rulesets callback late_routing: /usr/local/nginx-fl/lua/modules/init.lua:314: attempt to index field 'execute' (a nil value)

Le système a dès lors émis des erreurs de code HTTP 500 en conséquence.

Identifiée peu après l'application, la modification à l'origine du problème a été annulée à 9 h 12, suite à quoi l'intégralité du trafic est revenu à la normale.

Seuls les clients dont les ressources web sont traitées par notre ancien proxy FL1 ET qui avaient déployé l'ensemble de règles gérées Cloudflare ont été touchés. Toutes les requêtes adressées aux sites web concernés ont renvoyé un message d'erreur HTTP 500, mis à part un petit nombre de points de terminaison dédiés aux tests, comme /cdn-cgi/trace, par exemple.

Les clients qui ne disposaient pas de la configuration présentée ci-dessus n'ont pas été affectés. De même, le trafic client traité par le réseau Chine n'a pas non plus été touché.

La plateforme Cloudflare consiste en plusieurs ensembles de règles évalués lors de l'entrée d'une requête au sein de notre système (chacune de ces requêtes en fait). Ces règles se composent d'un filtre (qui sélectionne un certain trafic) et d'une action qui applique un effet au trafic sélectionné. Les actions généralement mises en œuvre sont « block » (Bloquer), « log » (Journaliser) ou « skip » (Ignorer). Un autre type d'action est l'action « execute » (Exécuter), utilisée pour déclencher l'évaluation d'un autre ensemble de règles.

Notre système de journalisation interne s'appuie sur cette fonctionnalité pour évaluer les nouvelles règles avant de les proposer au public. Un ensemble de règles de niveau supérieur exécutera un autre ensemble contenant des règles de test. Ce sont ces dernières que nous avons tenté de désactiver.

Nous avons intégré un sous-système d'arrêt d'urgence (également appelé « killswitch ») au système d'ensembles de règles. Ce dispositif est conçu pour permettre la désactivation rapide d'une règle qui présenterait un comportement anormal. Le killswitch reçoit des informations de la part du système de configuration mondial que nous mentionnons dans les sections précédentes. Nous avons utilisé ce système d'arrêt d'urgence plusieurs fois par le passé pour atténuer des incidents et disposons d'une procédure opérationnelle standard bien définie concernant son fonctionnement. La procédure a d'ailleurs été suivie à la lettre lors de l'incident.

Nous n'avions toutefois jamais appliqué ce killswitch à une règle accompagnée de l'action type « execute ». Le code a ainsi correctement ignoré l'évaluation de l'action Exécuter lorsque le système d'arrêt d'urgence a été enclenché et n'a pas évalué le sous-ensemble de règles désigné par cette action. Or, une erreur est survenue lors du traitement des résultats généraux de l'évaluation de l'ensemble de règles.

if rule_result.action == "execute" then
  rule_result.execute.results = ruleset_results[tonumber(rule_result.execute.results_index)]
end

Ce code s'attend à ce que l'objet « rule_result.execute » existe si l'ensemble de règles a comme action « execute ». Toutefois, comme la règle avait été ignorée, l'objet rule_result.execute n'existait pas et le système Lua a renvoyé une erreur, car il tentait de rechercher une valeur nulle.

Cette simple erreur au sein du code existe probablement depuis de nombreuses années, mais n'avait jamais été détectée jusqu'ici. Les langages dotés de systèmes de typage forts permettent d'éviter ce type d'erreur de code. Cette erreur ne s'est ainsi pas produite au sein de notre nouveau proxy FL2 (dont le code a été remplacé par un code rédigé en Rust).

Un incident de disponibilité plus long, mais néanmoins similaire, s'est produit il y a deux semaines (le 18 novembre 2025) suite au déploiement par nos services d'une modification sans lien avec le problème qui nous occupe aujourd'hui. Le problème résultait, dans les deux cas, du déploiement d'un correctif visant à atténuer un problème de sécurité pour nos clients. La modification s'est ensuite propagée à l'ensemble de notre réseau et a conduit à des erreurs pour pratiquement tous nos clients.

Nous avons parlé directement à des centaines de clients à la suite de cet incident et les avons informés de notre volonté de procéder à des changements au sein de notre plateforme afin d'empêcher qu'une simple mise à jour n'entraîne d'aussi nombreuses conséquences. Nous pensons que ces changements auraient permis d'éviter les effets de l'incident d'aujourd'hui, mais nous n'avons malheureusement pas encore terminé de les déployer.

Nous savons qu'il est décevant d'apprendre que ces travaux ne sont pas encore achevés, mais ils demeurent toutefois une priorité absolue pour l'ensemble de notre entreprise. Les projets décrits ci-dessous devraient notamment contribuer à limiter l'incidence de ce type de modifications :

• Amélioration des processus de déploiement et de gestion des versions : les données utilisées pour la réponse rapide aux menaces et la configuration générale doivent bénéficier des mêmes fonctionnalités de sécurité et d'atténuation des risques sur lesquelles nous nous appuyons lorsque nous déployons des logiciels, de manière lente et mesurée, avec un strict processus de validation de l'intégrité. Outre la validation de l'intégrité, ces fonctionnalités comprennent, entre autres, des capacités de restauration rapide.

• Rationalisation des fonctionnalités d'urgence (break-glass) : nous devons nous assurer d'être toujours à même de réaliser nos opérations essentielles, malgré les autres types de défaillances qui pourraient se produire. Ce plan s'applique aux services internes, mais aussi aux méthodes standard d'interaction avec l'interface Cloudflare utilisée par l'ensemble de nos clients.

• Traitement « fail-open » des erreurs : dans le cadre de nos efforts d'amélioration de notre résilience, nous remplaçons la logique incorrectement mise en œuvre de gestion des erreurs de type « hard-fail » (échec total, sans basculement) pour tous les composants essentiels du plan de données Cloudflare. Ainsi, en cas de corruption d'un fichier de configuration ou de fonctionnement hors plage de ce dernier (en cas de dépassement des limites d'une fonctionnalité, par exemple), le système journalise l'erreur et, plutôt que d'abandonner les requêtes, revient par défaut à un état correct connu ou transmet le trafic sans lui attribuer de score. Certains services permettront probablement au client de choisir entre le basculement en position ouverte (fail-open) ou fermée (fail-closed) dans certains scénarios de défaillance. Ces nouvelles mesures comprendront des fonctionnalités de prévention des dérives afin d'assurer leur application en continu.

Nous publierons une analyse détaillée de l'ensemble des projets d'amélioration de la résilience actuellement en cours (notamment de ceux présentés ci-dessus) avant la fin de la semaine prochaine. Nous verrouillerons le déploiement de toutes les modifications apportées à notre réseau pendant ces travaux afin de nous assurer que nous disposons de meilleurs systèmes d'atténuation et de restauration avant de reprendre les opérations.

Les incidents de ce type (de même que la proximité temporelle de ces derniers) ne sont pas acceptables pour un réseau comme le nôtre. Au nom de toute l'équipe Cloudflare, nous tenons à vous présenter nos excuses pour les effets néfastes et les désagréments que ce problème a (de nouveau) causé à nos clients et à l'ensemble de l'Internet.

Le troisième trimestre 2025 a été assombri par les méfaits du botnet Aisuru et de sa gigantesque armée d'environ 1 à 4 millions d'hôtes infectés à travers le monde. Les attaques DDoS hyper-volumétriques lancées par Aisuru ont régulièrement dépassé le térabit par seconde (Tb/s) et le milliard de paquets par seconde (p/s). Le nombre de ces attaques a bondi de 54 % par rapport au trimestre précédent, avec une moyenne de 14 attaques volumétriques par jour. L'ampleur de cette campagne était jusqu'ici inédite, certaines attaques ayant culminé à 29,7 Tb/s et 14,1 milliards de p/s.

Outre Aisuru, les autres enseignements majeurs de ce rapport sont les suivants :

1. Le trafic des attaques DDoS à l'encontre des entreprises de développement d'IA a augmenté de 347 % en septembre 2025 par rapport au mois précédent, dans un contexte d'intensification des inquiétudes du public et de l'intérêt des autorités réglementaires quant à cette technologie. 

2. L'escalade des tensions commerciales entre l'UE et la Chine concernant les terres rares et les tarifs des véhicules électriques coïncide avec une augmentation considérable des attaques DDoS contre le secteur de l'exploitation minière, des minerais et des métaux (ainsi que le secteur automobile) au troisième trimestre 2025.

3. Les mesures de défense autonomes de Cloudflare ont bloqué un total de 8,3 millions d'attaques DDoS au cours du troisième trimestre 2025. Ce total représente en moyenne près de 3 780 attaques DDoS par heure. Le nombre d'attaques DDoS a augmenté de 15 % par rapport au trimestre précédent et de 40 % par rapport à l'année précédente. 

Cloudflare a déjà atténué 36,2 millions d'attaques DDoS en 2025 et il reste encore un trimestre complet avant la fin de l'année. Ce chiffre correspond à 170 % du nombre total d'attaques DDoS atténuées par Cloudflare sur le courant de l'année 2024.

Cloudflare a automatiquement détecté et atténué 8,3 millions d'attaques DDoS au cours du troisième trimestre 2025, soit une augmentation de 15 % par rapport au trimestre précédent et de 40 % par rapport à l'année précédente.

Les attaques DDoS sur la couche réseau (qui totalisaient 71 % des attaques DDoS alors du troisième trimestre 2025, soit 5,9 millions d'attaques DDoS) ont augmenté de 87 % par rapport au trimestre précédent et de 95 % par rapport à l'année précédente. Toutefois, les attaques DDoS HTTP, qui ne représentaient que 29 % des attaques DDoS au troisième trimestre 2025 (soit 2,4 millions d'attaques DDoS), ont respectivement diminué de 41 % et de 17 % sur les mêmes périodes.

Cloudflare a atténué en moyenne 3 780 attaques DDoS par heure au troisième trimestre 2025.

Une force de subversion

Aisuru s'est attaqué à des fournisseurs de télécommunications, des entreprises de jeux vidéo, des fournisseurs d'hébergement et des services financiers, pour ne citer que quelques-unes de ses cibles. Comme signalé sur Krebs on Security, ce phénomène a également entraîné des « épisodes majeurs d'interruption collatérale du trafic Internet » [aux États-Unis] du simple fait de la quantité de trafic lié au botnet acheminé par les fournisseurs d'accès Internet (FAI). 

Rendons-nous bien compte de la situation ici. Si le trafic hostile d'Aisuru peut perturber des pans entiers de l'infrastructure Internet américaine alors même que les FAI n'étaient pas la cible de ces attaques, imaginez les dégâts que ce botnet pourrait causer s'il s'en prenait directement à des FAI, des infrastructures essentielles, des services de santé, des services d'urgence et des systèmes militaires sans protection ou dotés d'une protection insuffisante. 

Statistiques concernant les « botnets à louer » et les attaques DDoS

Certains acteurs malveillants proposent des « pans » d'Aisuru sous forme de « botnets à louer » afin de permettre à n'importe qui de semer le chaos au sein de pays entiers en paralysant les infrastructures réseau et en saturant les liaisons Internet. Ces attaques perturberaient l'accès de millions d'utilisateurs et entraveraient l'accès aux services essentiels, le tout pour un coût s'élevant à quelques centaines ou quelques milliers de dollars américains. 

Cloudflare a déjà atténué 2 867 attaques liées à Aisuru depuis le début de l'année 2025. Nous avons d'ailleurs atténué 1 304 attaques volumétriques lancées par Aisuru sur le seul troisième trimestre. Ce chiffre représente une augmentation de 54 % par rapport au trimestre précédent. Il comprend également les attaques DDoS de tous les records culminant respectivement à 29,7 Tb/s et 14,1 milliards de p/s. 

L'événement chiffré à 29,7 Tb/s était une attaque de type carpet-bombing (tapis de bombes) UDP, qui a bombardé en moyenne 15 000 ports de destination par seconde. Cette attaque distribuée a randomisé divers attributs de paquet pour échapper aux mesures de défense, mais les systèmes d'atténuation de Cloudflare ont détecté et atténué l'ensemble des attaques de manière entièrement autonome (y compris celle-ci). Cliquez sur le lien pour en apprendre davantage sur la manière dont Cloudflare atténue les attaques DDoS hyper-volumétriques.

Si la majeure partie des attaques DDoS s'avèrent relativement modestes du point de vue de la taille, le nombre d'attaques DDoS dépassant les 100 millions de paquets par seconde (p/s) au troisième trimestre a augmenté de 189 % par rapport au trimestre précédent. De manière similaire, les attaques dépassant 1 Tb/s ont augmenté de 227 % par rapport à la même période. De même, sur la couche HTTP, 4 attaques sur 100 ont dépassé le million de requêtes par seconde. 

La plupart de ces attaques (71 % des attaques DDoS HTTP et 89 % des attaques sur la couche réseau) ne durent en outre que moins de 10 minutes. Ce délai est trop court pour qu'un service à intervention humaine ou à la demande puisse réagir. Quand bien même elle ne durerait que quelques secondes, les perturbations engendrées par une attaque de courte durée peuvent s'avérer graves et la récupération post-incident demander beaucoup plus de temps. Les équipes techniques et opérationnelles doivent alors composer avec un processus complexe et multi-étapes pour remettre en ligne leurs systèmes essentiels et vérifier la cohérence des données présentes sur leurs systèmes distribués, avant de rétablir un service sécurisé et fiable pour leurs clients. 

Même de courte durée, les attaques DDoS (hyper-volumétriques ou non) ont des effets qui peuvent s'étendre bien au-delà de l'événement proprement dit.

Sept des dix principales sources sont situées en Asie, l'Indonésie en tête. L'Indonésie s'est imposée comme la source n° 1 d'attaques DDoS dans le monde depuis maintenant un an (depuis le troisième trimestre 2024). Le pays figurait néanmoins toujours parmi les principales sources d'attaques avant l'année dernière. L'Indonésie était ainsi la deuxième source la plus importante d'attaques lors du deuxième trimestre 2024, après avoir lentement gravi les échelons du classement année après année.

Pour illustrer l'avènement de l'Indonésie au statut de véritable plateforme d'attaques DDoS, il faut savoir que le pourcentage de requêtes liées à des attaques DDoS HTTP en provenance du pays a explosé de manière spectaculaire en seulement cinq ans (soit depuis le troisième trimestre 2021), avec une augmentation de 31 900 %. 

Les auteurs d'attaques DDoS s'en prennent aux ressources minières rares de la Terre

Le nombre d'attaques DDoS à l'encontre du secteur de l'exploitation minière, des minerais et des métaux a considérablement augmenté au troisième trimestre 2025 qui, d'après de nombreux médias, a également vu une hausse des tensions autour des droits de douane appliqués aux véhicules électriques (VE), des exportations de terres rares et des problèmes de cybersécurité lors du 25e sommet commercial Union européenne-Chine. La BBC a signalé que « la Chine a également renforcé ses mesures de contrôle des exportations de terres rares et de ressources minières essentielles ». Au total, le secteur de l'exploitation minière, des minerais et des métaux a gagné 24 places au classement mondial, pour devenir le 49e secteur le plus visé au monde.

Avec une progression de 62 places en un trimestre seulement, le secteur automobile a connu la plus forte hausse du nombre d'attaques DDoS et s'inscrit désormais à la sixième place des secteurs les plus visés à travers le monde. Les entreprises de cybersécurité ont également constaté une augmentation considérable du nombre d'attaques DDoS à leur encontre. Le secteur de la cybersécurité a ainsi gagné 17 places au classement, pour devenir le 13e secteur mondial le plus fréquemment visé par les attaques.

Le nombre d'attaques DDoS contre l'IA augmente de 347 %

En septembre 2025, une enquête de l'Institut Tony Blair a révélé que les Britanniques considèrent davantage l'IA comme un risque économique que comme une opportunité, un chiffre qui a depuis fait couler beaucoup d'encre sur l'automatisation et la confiance. Les questions d'éthique, de réglementation et d'adoption de l'IA générative se sont ainsi accaparées les gros titres pendant un mois suite au lancement d'une évaluation de l'utilisation faite de l'IA au sein de l'administration publique par la UK Law Commission. Au mois de septembre 2025, Cloudflare a également observé des pics mensuels d'activité atteignant les 347 % au niveau du trafic des attaques DDoS HTTP contre les entreprises de développement d'IA générative (le chiffre se base sur un échantillon des principaux services d'IA générative).

Le top 10

Le secteur des services et technologies de l'information a été le plus attaqué au troisième trimestre 2025, suivi par le secteur des télécommunications, puis celui des jeux de hasard et des casinos. Fait remarquable également, le secteur automobile a fortement progressé, avec une augmentation considérable de 62 places par rapport au trimestre précédent. Le secteur de la production et de l'édition multimédias a également connu une forte hausse, précédé par le secteur des services bancaires et financiers, le secteur du commerce de détail et le secteur de l'électronique grand public.

Il existe une corrélation directe entre les événements géopolitiques et l'activité des attaques DDoS.

Arrêtez le pillage !

Le terme maldivien « Lootuvaifi » (Arrêtez le pillage !) est devenu le slogan de ralliement des manifestations maldiviennes de 2025. Les manifestants sont ainsi descendus dans la rue pour s'opposer à « l'impression perçue de corruption et de recul démocratique au sein du gouvernement », notamment suite au projet de loi « sur la fin de la liberté d'expression » des médias, qui « portera gravement atteinte à la liberté de la presse et au droit à la liberté d'expression du peuple maldivien si elle n'est pas retirée » (d'après le haut-commissaire aux droits humains des Nations unies). Les manifestations maldiviennes de 2025 se sont accompagnées d'un barrage d'attaques DDoS. En conséquence, le pays a ainsi connu la plus forte augmentation du nombre d'attaques DDoS. Les Maldives ont gagné 125 places dans le classement au troisième trimestre 2025, pour s'établir comme le 38e pays le plus touché par les attaques DDoS au monde.

« Bloquons tout »

Lancé par les syndicats français en septembre 2025, le mouvement de protestation national « Bloquons tout » avait pour objectif de s'opposer au gouvernement du président Macron concernant les nouvelles mesures d'austérité, les modifications apportées au système de retraite et l'augmentation du coût de la vie. Alors que les syndicats appelaient à des actions de grève coordonnées et à des blocages au niveau des transports afin de paralyser le pays, les acteurs malveillants ont lancé des vagues d'attaques DDoS à l'encontre de sites web et de services Internet français. La France a gagné 65 places au classement par rapport au trimestre précédent, pour devenir le 18e pays le plus visé par les attaques au monde. 

« Fixer des limites sur la situation de Gaza à Bruxelles »

Nous avons observé une hausse du nombre d'attaques DDoS consécutive à l'organisation de manifestations dans un plus grand nombre de pays. La Belgique, par exemple, a gagné 63 places (et est donc devenue le 74e pays le plus attaqué au monde) lorsque « des dizaines de milliers de manifestants ont rejoint l'appel du mouvement Draw the Red Line pour Gaza à Bruxelles ».

Le top 10

La Chine est restée le pays le plus visé par les attaques au troisième trimestre 2025, suivie par la Turquie en deuxième position et l'Allemagne à la troisième place. Le changement le plus notable survenu ce trimestre a été une augmentation des attaques DDoS contre les États-Unis, qui ont gagné 11 places au classement pour devenir le cinquième pays le plus visé. Les Philippines ont enregistré la plus forte progression du top 10, avec un gain de 20 places au classement.

Attaques DDoS sur la couche réseau

Le nombre d'attaques DDoS UDP (en partie alimenté par les attaques lancées par Aisuru) a augmenté de 231 % par rapport au trimestre précédent. Ce vecteur est donc devenu le principal utilisé pour lancer des attaques sur la couche réseau. Les attaques DNS Floods (saturation de DNS) arrivaient en deuxième position, les attaques SYN Floods (saturation SYN) en troisième et les les attaques ICMP Floods (saturation ICMP) à la quatrième place. Au total, ces attaques représentaient un peu plus de la moitié de l'ensemble des événements DDoS visant la couche réseau.

Les attaques DDoS lancées par Mirai demeurent encore assez courantes près de 10 ans après le premier événement majeur lié à ce botnet. Près de 2 attaques DDoS sur 100 à l'encontre de la couche réseau sont ainsi lancées par des variantes du botnet Mirai.

Attaques DDoS HTTP

Près de 70 % des attaques DDoS HTTP provenaient de botnets déjà connus de Cloudflare. Ce chiffre reflète l'un des avantages dont nos clients peuvent bénéficier en utilisant Cloudflare. Ainsi, tous les utilisateurs sont automatiquement protégés contre un botnet donné lorsque ce dernier attaque l'un des millions de clients Cloudflare.

Par ailleurs, près 20 % des attaques DDoS HTTP étaient issues de navigateurs factices ou sans interface graphique (headless). Une même proportion incluait des attributs HTTP suspects. Les 10 % (environ) d'attaques restants se composaient d'une combinaison d'attaques par saturation génériques, de requêtes inhabituelles, d'attaques par infiltration de cache (cache busting) et d'attaques visant les points de terminaison des connexions.

Nous sommes entrés dans une ère au sein de laquelle les attaques DDoS ont rapidement gagné en sophistication et en ampleur. Elles dépassent désormais tout ce que nous pouvions imaginer il y a quelques années. De nombreuses entreprises éprouvent encore des difficultés à suivre les évolutions du panorama des menaces. 

Les entreprises qui s'appuient sur des équipements d'atténuation sur site ou des solutions de centres de nettoyage à la demande peuvent bénéficier d'un examen de leur stratégie de défense face au paysage actuel.

Épaulée dans ses efforts par son vaste réseau mondial et ses systèmes autonomes d'atténuation des attaques DDoS, Cloudflare s'engage à assurer une protection contre les attaques DDoS gratuite et illimitée à tous ses clients contre les attaques DDoS auxquelles ils font face, quels que soient l'ampleur, la durée ou le nombre de ces dernières.

Le dysfonctionnement ne résultait, directement ou indirectement, ni d'une cyberattaque ni d'une activité malveillante. L'événement était en réalité dû à une modification des permissions au sein d'un de nos systèmes de base de données. Cette opération a contraint la base de données à sortir plusieurs entrées au sein d'un « fichier de fonctionnalité » utilisé par notre système de gestion des bots Bot Management. Ce fichier a doublé de taille en retour. Plus volumineux que prévu, le fichier de fonctionnalité a ensuite été propagé à toutes les machines qui composent notre réseau.

Le logiciel exécuté sur ces machines lit ce fichier de fonctionnalités afin d'acheminer le trafic sur notre réseau et de maintenir le système de notre service Bot Management à jour face à un panorama des menaces en constante évolution. La limite définie pour ce fichier de fonctionnalité au sein du logiciel était inférieure à la taille réelle du fichier ce jour-là, qui représentait le double de la normale. Ce problème a entraîné une défaillance du logiciel.

Après avoir initialement soupçonné (à tort) que les symptômes observés résultaient d'une attaque DDoS hypervolumétrique, nous avons correctement identifié le problème principal. Nous avons ainsi pu mettre un terme à la propagation de ce fichier de fonctionnalité plus volumineux que prévu et le remplacer par une version antérieure. Le trafic principal était, dans sa plus grande part, revenu à la normale à 14 h 30. Au cours des heures qui ont suivi, nous nous sommes efforcés d'atténuer la charge accrue pesant sur diverses parties de notre réseau à mesure que le trafic revenait en ligne. Tous les systèmes Cloudflare fonctionnaient à nouveau normalement à 17 h 06.

Nous sommes navrés des répercussions de cet événement sur nos clients et sur Internet en général. Compte tenu de l'importance de Cloudflare au sein de l'écosystème Internet, toute forme d'interruption de nos systèmes se révèle inacceptable. Chaque membre de notre équipe est profondément peiné que notre réseau n'ait pas été en mesure de router le trafic pendant un certain temps. Nous savons que nous vous avons déçus aujourd'hui.

Cet article présente un compte rendu détaillé des événements, tels qu'ils se sont produits exactement, ainsi que des systèmes et des processus qui ont été pris en défaut. Il marque également le début (mais pas la fin) des mesures que nous prévoyons de déployer afin de nous assurer qu'une défaillance de ce genre ne se reproduise plus.

Le graphique ci-dessous montre le volume de codes d'erreur HTTP 5xx renvoyés par le réseau Cloudflare. Cette valeur devrait normalement être très faible. Il l'était d'ailleurs jusqu'au début de la défaillance.

Le volume avant 11 h 20 correspond au niveau de base attendu en termes d'erreurs 5xx observées sur notre réseau. Le pic et les fluctuations ultérieures montrent la défaillance de notre système en raison d'un chargement incorrect du fichier de fonctionnalité. Fait notable, nous pouvons remarquer que notre système a ensuite connu des moments de rétablissement pendant un certain temps. Ce comportement était très inhabituel pour une erreur interne.

L'explication de ces moments de rétablissement réside dans le fait que le fichier était généré toutes les cinq minutes par une requête exécutée sur un cluster de base de données ClickHouse, qui faisait l'objet d'une mise à jour progressive destinée à améliorer la gestion des autorisations. Les données incorrectes n'étaient générées que si la requête était exécutée sur une partie du cluster en cours de mise à jour. Il y avait par conséquent une chance pour que le fichier de configuration généré et rapidement propagé sur le réseau toutes les cinq minutes se révèle fonctionnel ou dysfonctionnel.

Ces fluctuations compliquaient fortement nos efforts visant à comprendre ce qui se passait, car du fait de la distribution de fichiers de configuration tantôt valides, tantôt dysfonctionnels sur notre réseau, le système dans son ensemble se rétablissait avant de connaître une nouvelle défaillance. C'est ce comportement qui nous a fait croire au départ que l'événement pouvait être dû à une attaque. Au bout du compte, chaque nœud ClickHouse s'est mis à générer le mauvais fichier de configuration et la fluctuation s'est stabilisée dans un état de défaillance.

Les erreurs se sont poursuivies jusqu'à identification et résolution du problème sous-jacent, soit à partir de 14 h 30. Nous avons résolu le problème en arrêtant la génération/propagation du fichier de fonctionnalité erroné, puis en insérant manuellement un fichier fonctionnel connu au sein de la file d'attente de distribution du fichier de fonctionnalité. Nous avons ensuite forcé le redémarrage de notre proxy principal.

La longue traîne subsistante dans le graphique ci-dessus représente les efforts de redémarrage, par notre équipe, des services restants qui commençaient eux aussi à se dégrader. Le nombre de codes d'erreur 5xx a retrouvé son volume normal à 17 h 06.

Voici la liste des services affectés par l'événement :

Outre le renvoi d'erreurs HTTP 5xx, nous avons constaté une forte hausse de la latence des réponses de notre CDN pendant l'événement. Ce phénomène résultait d'une consommation importante de ressources CPU par nos systèmes de débogage et d'observabilité, qui améliorent automatiquement le processus de détection des erreurs non interceptées à l'aide d'informations de débogage supplémentaires.

Chaque requête adressée à Cloudflare suit un chemin bien défini à travers notre réseau. Une requête donnée peut, par exemple, provenir d'un navigateur en train de charger une page web, d'une application mobile effectuant un appel d'API ou d'une quelconque forme de trafic automatisé issu d'un autre service. Ces requêtes arrivent d'abord sur notre couche HTTP et TLS. Elles pénètrent ensuite dans notre système de proxy principal (que nous nommons FL, pour « Frontline »), pour finir par atteindre Pingora, qui recherche les données dans le cache ou les récupère depuis le serveur d'origine, selon les besoins.

Nous avons déjà partagé plus de détails sur le fonctionnement de notre proxy principal dans un article précédent, que vous trouverez ici. 

Lorsqu'une requête transite par notre proxy principal, nous exécutons les divers produits d'amélioration de la sécurité et des performances disponibles sur notre réseau. Le proxy applique la configuration et les paramètres propres à chaque client, de l'application des règles WAF à la protection contre les attaques DDoS, en passant par le routage du trafic vers la plateforme pour développeurs et le service R2. Ces opérations s'effectuent à l'aide d'un ensemble de modules spécifiques au domaine qui appliquent les règles de configuration et les politiques au trafic circulant au sein de notre proxy.

L'un de ces modules, celui du service Bot Management, s'est révélé à l'origine de la panne d'aujourd'hui. 

Entre autres systèmes, le service de gestion des bots de Cloudflare intègre un modèle d'apprentissage automatique (Machine Learning) servant à générer un score de bot pour chaque requête qui circule à travers notre réseau. Nos clients s'appuient sur ce score de bot pour contrôler quels bots sont autorisés à accéder à leurs sites, ou non.

Le modèle ingère un fichier de configuration des « fonctionnalités » en guise de données entrantes. Dans ce contexte, la fonctionnalité désigne une caractéristique individuelle utilisée par le modèle d'apprentissage automatique afin de prédire si la requête a été automatisée ou non. Le fichier de configuration des fonctionnalités regroupe un ensemble de fonctionnalités individuelles.

Actualisé toutes les quelques minutes, ce fichier de fonctionnalité est publié sur l'ensemble de notre réseau afin de nous permettre de réagir aux variations des flux de trafic circulant sur Internet. Il nous permet également de réagir aux nouveaux types de bots et aux nouvelles attaques de bots. Comme les acteurs malveillants modifient rapidement les tactiques qu'ils utilisent, il est primordial que ce fichier soit déployé fréquemment et à grande vitesse.

Un changement (expliqué ci-dessous) de comportement de notre système de requêtes ClickHouse sous-jacent (qui génère ce fichier) a entraîné la production d'un grand nombre de lignes de « fonctionnalité » en double. Cet incident a modifié la taille du fichier de configuration des fonctionnalités (auparavant de taille fixe) et l'événement a entraîné l'apparition d'une erreur au sein du module dédié aux bots.

Le système de proxy principal qui gère le traitement du trafic de nos clients a par conséquent renvoyé des codes d'erreur HTTP 5xx pour l'ensemble du trafic dépendant de ce module. Le problème a également affecté Workers KV et Access, qui reposent sur le proxy principal.

Indépendamment de cet incident, nous étions (et sommes toujours) en train de procéder à la migration du trafic de nos clients vers une nouvelle version de notre service de proxy, connu en interne sous le nom de FL2. Les deux versions ont été affectées par le problème, mais les impacts observés se sont montrés différents.

Les clients déployés sur le nouveau moteur de proxy FL2 ont constaté l'apparition d'erreurs HTTP 5xx. Les clients qui utilisaient notre ancien moteur de proxy (FL) ne rencontraient pas d'erreurs, mais les scores de bot n'étaient pas générés correctement. L'ensemble du trafic se retrouvait ainsi doté d'un score de zéro. Les clients qui avaient déployé des règles de blocage des bots constataient un grand nombre de faux positifs. Ceux qui n'utilisaient pas nos scores de bot dans leurs règles n'observaient aucun impact.

Un autre symptôme apparent nous a induits en erreur et nous a fait croire que le problème pourrait être dû à une attaque : la page d'état des systèmes de Cloudflare est devenue inaccessible. Cette page d'état est intégralement hébergée hors de l'infrastructure de Cloudflare, sans aucune dépendance vis-à-vis de Cloudflare. Bien qu'il se soit avéré qu'il s'agissait uniquement d'une coïncidence, cet événement a amené certains membres de l'équipe chargée de diagnostiquer l'incident à penser qu'un acteur pouvait être en train de cibler à la fois nos systèmes et notre page d'état. Les utilisateurs qui tentaient d'accéder à la page d'état à ce moment ont été accueillis par le message d'erreur suivant :

Dans notre espace de discussion interne consacré aux incidents, nous craignions que l'incident ne soit la continuation d'Aisuru, une récente vague d'attaques DDoS à volume élevé :

J'ai mentionné plus haut qu'un changement survenu au niveau du comportement de notre système de requête sous-jacent a entraîné la production d'un fichier de fonctionnalité contenant un grand nombre de lignes en double. La base de données en question utilise le logiciel ClickHouse.

Afin de vous donner davantage de contexte, il peut être utile d'expliquer comment le système de requêtes distribuées de ClickHouse fonctionne. Un cluster ClickHouse se compose de nombreux fragments (shards). Pour interroger les données de l'ensemble de ces fragments, nous disposons de tables dites distribuées (à l'aide du moteur de table Distributed) contenues au sein d'une base de données nommée default. Le moteur Distributed interroge les tables sous-jacentes d'une base de données r0. Ce sont dans ces tables sous-jacentes que les données sont stockées sur chaque shard d'un cluster ClickHouse.

Les requêtes adressées aux tables distribuées s'exécutent par l'intermédiaire d'un compte système partagé. Dans le cadre de nos efforts visant à améliorer la sécurité et la fiabilité de nos requêtes distribuées, nous avons lancé une vague de travaux destinés à ce que ces requêtes soient plutôt exécutées sous le compte des utilisateurs initiaux.

Avant aujourd'hui, les utilisateurs de ClickHouse ne pouvaient voir les tables de la base de données default que lorsqu'ils interrogeaient les métadonnées des tables système de ClickHouse, comme system.tables ou system.columns.

Comme les utilisateurs disposent déjà d'un accès implicite aux tables sous-jacentes de r0, nous avons modifié nos paramètres à 11 h 05 afin de rendre cet accès explicite et que les utilisateurs puissent également consulter les métadonnées de ces tables. En nous assurant que l'ensemble des sous-requêtes distribuées puissent s'exécuter sous le compte de l'utilisateur initial, les limites de requête et les autorisations d'accès peuvent être évaluées de manière plus précise afin d'éviter qu'une sous-requête défaillante envoyée par un utilisateur n'affecte les autres.

Suite à la modification expliquée ci-dessus, tous les utilisateurs ont pu accéder aux métadonnées exactes concernant les tables auxquelles ils avaient accès. Malheureusement, selon certaines hypothèses déjà émises par le passé, la liste des colonnes renvoyées par une requête de ce type n'inclurait que la base de données « default » :

SELECT name, type FROM system.columns WHERE table = 'http_requests_features' order by name;

Vous remarquerez que la requête ne filtre pas selon le nom de la base de données. Alors que nous déployions progressivement les autorisations explicites aux utilisateurs d'un cluster ClickHouse donné, après cette modification effectuée à 11 h 05, la requête ci-dessus a commencé à renvoyer des « doublons » de colonnes, car celles-ci concernaient des tables sous-jacentes stockées au sein de la base de données r0.

Il s'agissait malheureusement du type de requête que la logique de génération de fichier de fonctionnalité du service Bot Management était justement en train d'exécuter afin de construire chaque « fonctionnalité » d'entrée pour le fichier mentionné au début de cette section. 

La requête ci-dessus renverrait dès lors une table de colonnes du type suivant (exemple simplifié) :

Toutefois, grâce aux autorisations supplémentaires accordées à l'utilisateur, la réponse contenait également l'ensemble des métadonnées du schéma r0. Le nombre de lignes contenues dans la réponse s'en retrouvait effectivement plus que doublé. Cette inflation allait ensuite, à son tour, affecter le nombre de lignes (c.-à-d. les fonctionnalités) présentes dans le fichier final. 

Chaque module qui s'exécute sur notre service de proxy dispose d'un certain nombre de limites conçues pour éviter une consommation de mémoire illimitée, mais aussi pour pré-allouer de la mémoire afin d'optimiser les performances. Dans ce cas précis, le système du service Bot Management limite le nombre de fonctionnalités d'apprentissage automatique utilisables pendant l'exécution. Cette limite est actuellement fixée à 200, un chiffre bien supérieur au nombre de fonctionnalités que nous utilisons actuellement (près de 60). Encore une fois, cette limite existe, car nous pré-allouons de la mémoire à ces fonctionnalités pour des raisons de performances.

Lorsqu'un fichier dysfonctionnel contenant plus de 200 fonctionnalités a été propagé à nos serveurs, cette limite a été atteinte et a entraîné une panique au sein du système. Le code Rust de FL2 que nous vous présentons ci-dessous est chargé de la vérification. C'est lui qui se tient à l'origine de cette erreur non gérée :

L'application de ce code a engendré la panique suivante, qui a ensuite conduit à l'émission d'une erreur 5xx :

thread fl2_worker_thread panicked: called Result::unwrap() on an Err value

L'incident a également touché d'autres systèmes reposant sur notre proxy principal, notamment Workers KV et Cloudflare Access. Notre équipe a réussi à réduire l'impact sur ces systèmes à 13 h 04, suite à l'application d'un correctif à Workers KV afin de contourner le proxy principal. En conséquence, tous les systèmes en aval qui reposent sur Workers KV (comme le service Access lui-même) ont constaté une réduction du taux d'erreur. 

Le tableau de bord Cloudflare a également été affecté du fait de l'utilisation en interne de Workers KV, mais aussi de notre processus de connexion, qui fait appel à Cloudflare Turnstile.

Le service Turnstile a été impacté par la défaillance. Nos clients sans session de tableau de bord active ne pouvaient ainsi plus se connecter. Comme le montre le graphique ci-dessous, le problème s'est manifesté par une disponibilité réduite pendant deux périodes précises : 11 h 30 – 13 h 10 et 14 h 40 – 15 h 30.

La première période, de 11 h 30 à 13 h 10, était due aux effets de la défaillance au niveau du service Workers KV, sur lequel reposent certaines fonctions de l'interface et du tableau de bord. La situation a été rétablie à 13 h 10, lorsque Workers KV a pu contourner le système de proxy principal. La deuxième période de répercussions sur le tableau de bord s'est produite après la restauration des données de configuration des fonctionnalités, lorsque le backlog de tentatives de connexion non traitées a commencé à submerger le tableau de bord. L'association de nouvelles tentatives de connexion à l'ensemble des tentatives antérieures qui s'étaient soldées par un échec a entraîné une latence élevée et réduit la disponibilité du tableau de bord. La mise à l'échelle de la concurrence de l'interface a rétabli la disponibilité vers environ 15 h 30.

Maintenant que nos systèmes sont de nouveau en ligne et fonctionnent normalement, nous avons commencé à travailler sur les solutions que nous allons devoir déployer afin de les prémunir contre des défaillances de ce type à l'avenir. Nous sommes plus spécifiquement en train :

• de renforcer le processus d'ingestion des fichiers de configuration générés par Cloudflare afin qu'il se comporte de la même manière qu'avec les entrées générées par l'utilisateur ;

• d'activer davantage de « kill switchs » (boutons d'arrêt d'urgence) mondiaux pour les fonctionnalités ;

• d'éliminer la possibilité que des opérations de vidage de la mémoire ou d'autres rapports d'erreurs submergent les ressources système ;

• d'examiner les modes de défaillance à la recherche de conditions d'erreur dans tous les modules de proxy principaux.

La panne survenue aujourd'hui est la pire que Cloudflare ait vécu depuis 2019. Nous avons déjà connu des défaillances qui ont entraîné l'indisponibilité de notre tableau de bord. D'autres ont conduit à l'indisponibilité de nouvelles fonctionnalités pendant un certain temps. Toutefois, ces six dernières années, nous n'avons pas connu d'autre épisode d'interruption de nos services ayant entraîné l'arrêt de la majorité du trafic principal sur notre réseau.

Un épisode d'interruption comme celui que nous avons subi aujourd'hui est inacceptable. Nous avons bâti l'architecture de nos systèmes afin qu'ils se montrent exceptionnellement résilients en cas de défaillance, mais aussi de garantir la circulation continue du trafic. Les pannes que nous avons connues par le passé nous ont toujours amenés à développer de nouveaux systèmes, plus solides et résilients.

Au nom de toute l'équipe Cloudflare, je tiens à vous présenter nos excuses pour les désagréments que nous avons causés à l'ensemble d'Internet aujourd'hui.

Nous avons d'importantes nouvelles à communiquer aujourd'hui : Replicate, la principale plateforme d'exécution de modèles d'IA, rejoint Cloudflare.

Au-delà d'une simple passion pour les palettes de couleurs vives, ce sont nos nombreux points communs qui nous ont poussés à engager la discussion avec Replicate. Notre mission vis-à-vis de la plateforme de développement Workers de Cloudflare a été de simplifier au maximum la création et le déploiement d'applications full-stack. Entre-temps, Replicate s'est donné une mission similaire : faire en sorte qu'il soit aussi simple de déployer des modèles d'IA que d'écrire une seule ligne de code. Nous avons réalisé que nous pouvions construire quelque chose d'encore mieux ensemble en intégrant directement la plateforme Replicate à Cloudflare.

Nous sommes ravis d'annoncer cette nouvelle et encore plus enthousiastes à l'idée des avantages qu'elle apportera à nos clients. Avec l'intégration des outils de Replicate dans Cloudflare, notre plateforme de développement continuera d'être le meilleur endroit sur Internet pour créer et déployer n'importe quel flux de travail IA ou agentique.

Avant de consacrer plus de temps à l'avenir de l'IA, nous souhaitons répondre aux questions qui préoccupent le plus les utilisateurs de Replicate et de Cloudflare. En bref : 

Pour les utilisateurs Replicate existants : vos API et flux de travail continueront de fonctionner sans interruption. Vous bénéficierez bientôt d'une amélioration des performances et de la fiabilité du réseau mondial de Cloudflare.

Pour les utilisateurs existants de Workers AI : préparez-vous à un enrichissement massif du catalogue de modèles et à des possibilités nouvelles en matière de précision des réglages et de modèles personnalisés directement sur Workers AI.

Maintenant, revenons à ce qui nourrit notre enthousiasme concernant notre avenir commun.

Avant que l'IA ne soit l'IA, et le sujet de toutes les conversations, elle existait depuis des décennies sous le nom d'« apprentissage automatique ». C'était un domaine spécialisé, presque académique. Les progrès ont été constants, mais isolés, les percées se produisant au sein de quelques grands laboratoires de recherche bien financés. Les modèles étaient monolithiques, les données étaient propriétaires et les outils étaient inaccessibles à la plupart des développeurs. Tout a changé lorsque la culture de la collaboration open source, la force motrice derrière l'Internet moderne, a rencontré l'apprentissage automatique. Les chercheurs et les entreprises ont alors commencé à publier non seulement leurs articles, mais aussi les poids de leurs modèles et leur code.

Cela a déclenché une formidable explosion d'innovation. Le rythme des évolutions de ces dernières années a été vertigineux ; ce qui était à la pointe de la technologie il y a 18 mois (ou parfois, il semble que ce n'était qu'il y a quelques jours) est désormais la norme. Cette accélération est particulièrement visible dans le domaine de l'IA générative. 

Nous sommes passés de curiosités étranges et floues à la génération d'images photoréalistes en un clin d'œil. Les modèles open source comme Stable Diffusion ont ouvert la voie à une créativité immédiate pour les développeurs, et ce n'était que le début. Si vous consultez aujourd'hui le catalogue de modèles de Replicate, vous y trouverez des milliers de modèles d'images de toutes sortes, chacun itérant sur le précédent. 

Cela s'est produit non seulement avec les modèles d'image, mais aussi avec la vidéo, l'audio, les modèles de langage, pour ne citer que quelques exemples. 

Cependant, cette progression incroyable, portée par la communauté, s'est accompagnée d'une difficulté majeure pour la mise en pratique : comment exécuter concrètement ces modèles ? Chaque nouveau modèle est associé à des dépendances différentes, exige du matériel GPU spécifique (et suffisamment) et fait appel à une infrastructure de service complexe pour assurer l'évolutivité. Les développeurs ont passé plus de temps à s'efforcer des régler des problèmes liés aux pilotes CUDA et les fichiers requirements.txt qu'à réellement développer leurs applications.

C'est exactement ce que Replicate a permis de résoudre. Ils ont mis au point une plateforme qui élimine toute cette complexité (en utilisant leur outil open source Cog pour regrouper les modèles dans des conteneurs standard et reproductibles), ce qui permet à n'importe quel développeur ou expert en science des données d'exécuter même les modèles open source les plus complexes avec un simple appel d'API. 

Aujourd'hui, le catalogue de Replicate comprend plus de 50 000 modèles open source et modèles affinés. Si l'open source a ouvert de nombreuses possibilités, la suite d'outils de Replicate va encore plus loin en permettant aux développeurs d'accéder à tous les modèles dont ils ont besoin, en un seul endroit. Point final. Grâce à sa place de marché, elle offre également un accès transparent aux principaux modèles propriétaires tels que GPT-5 et Claude Sonnet, le tout via une API unifiée.

Il est intéressant de noter que l'équipe de Replicate n'a pas simplement créé un service d'inférence ; ils ont bâti une communauté. De nombreuses innovations peuvent avoir lieu parce qu'elles s'inspirent de ce que font d'autres, en s'appuyant sur des itérations et en améliorant les solutions. Replicate est devenu la plateforme de référence sur laquelle les développeurs peuvent découvrir, partager, ajuster et expérimenter les derniers modèles dans un environnement public. 

Pour en revenir à la mission de Workers Platform : notre objectif a toujours été de permettre aux développeurs de créer des applications full-stack sans avoir à se soucier de l'infrastructure. Et si rien n'a changé à cet égard, l'IA a toutefois modifié les exigences des applications.

Les types d'applications que les développeurs créent évoluent ; il y a trois ans, personne ne développait d'agents ni ne créait de vidéos de lancement générées par IA. Aujourd'hui, c'est le cas. En conséquence, l'évolution concerne également ce dont ils ont besoin et ce qu'ils attendent du cloud, ou du cloud IA.

Pour répondre aux besoins des développeurs, Cloudflare a mis en place les piliers fondamentaux du cloud IA, conçu pour exécuter l'inférence en périphérie, au plus près des utilisateurs. Il ne s'agit pas simplement d'un produit, mais d'une pile complète :

• Workers AI : inférence GPU serverless sur notre réseau mondial.

• AI Gateway : un plan de contrôle pour la mise en cache, le contrôle du volume des requêtes et l'observation de toute API d'IA.

• Pile de données : dont Vectorize (notre base de données vectorielle) et R2 (pour le stockage de modèles et de données).

• Orchestration : des outils tels que AI Search (anciennement Autorag), Agents et Workflows, pour créer des applications complexes en plusieurs étapes.

• Fondation : tout est basé sur notre plateforme de développement principale, Workers, Durable Objects et le reste de notre pile.

Tandis que nous aidions les développeurs à faire évoluer leurs applications, Replicate s'est donné une mission similaire : faire en sorte qu'il soit aussi simple de déployer des modèles d'IA que de déployer du code. C'est là que tout se rejoint. Replicate propose un catalogue de modèles et une communauté de développeurs parmi les plus riches et les plus dynamiques du secteur. Cloudflare apporte un réseau mondial et une plateforme d'inférence sans serveur incroyablement performants. Ensemble, nous pouvons offrir le meilleur des deux mondes : la sélection la plus complète de modèles, exécutables sur une plateforme d'inférence rapide, fiable et abordable.

Au coeur-même de la communauté Replicate figure la possibilité de partager des modèles, de publier des réglages précis, de collecter des étoiles et d'expérimenter dans l'environnement de test. Nous continuerons d'investir et de développer cette plateforme pour en faire la destination de référence pour la découverte et l'expérimentation en matière d'IA, désormais optimisée par le réseau mondial de Cloudflare pour une expérience encore plus rapide et réactive pour tous.

Notre projet est de réunir le meilleur des deux plateformes. Nous allons intégrer l'intégralité du catalogue Replicate, soit plus de 50 000 modèles et réglages précis dans Workers AI. C'est ce qui vous offre le choix par excellence : exécuter les modèles dans l'environnement flexible de Replicate ou sur la plateforme serverless de Cloudflare, le tout depuis un seul endroit.

Mais nous ne nous contentons pas d'enrichir le catalogue. Nous sommes ravis d'annoncer l'ajout de fonctionnalités de réglage précis à Workers AI, grâce à la solide expertise de Replicate. Nous rendons également Workers AI plus flexible que jamais. Bientôt, vous pourrez apporter vos propres modèles personnalisés à notre réseau. Nous allons nous appuyer sur l'expertise de Replicate avec Cog pour rendre ce processus transparent, reproductible et facile.

L'exécution d'un modèle n'est qu'un élément du casse-tête. La magie opère lorsque vous connectez l'IA à l'ensemble de votre application. Imaginez ce que vous pouvez créer lorsque l'immense catalogue de Replicate est étroitement intégré à la plateforme pour développeurs Cloudflare : exécutez un modèle et stockez les résultats directement dans R2 ou Vectorize ; déclenchez l'inférence depuis une instance Worker ou une file d'attente ; utilisez des Durable Objects pour gérer l'état d'un agent IA ; ou créez une interface utilisateur générative en temps réel avec WebRTC et les protocoles WebSocket.

Pour gérer tout cela, nous intégrerons étroitement notre plateforme d'inférence unifiée avec la AI Gateway et vous offrons ainsi un plan de contrôle unique pour l'observabilité, la gestion des invites, les tests A/B et l'analyse des coûts sur tous vos modèles, qu'ils soient exécutés sur Cloudflare, Replicate ou un autre fournisseur, quel qu'il soit.

Nous sommes extrêmement heureux d'accueillir l'équipe Replicate chez Cloudflare. Leur passion pour la communauté des développeurs et leur expertise de l'écosystème de l'IA sont sans égal. Nous sommes impatients de bâtir ensemble l'avenir de l'IA.

Cette semaine, la dernière d'octobre 2025, nous avons franchi une étape importante concernant la sécurité d'Internet : la majorité du trafic d'origine humaine destiné à Cloudflare utilise le chiffrement post-quantique pour atténuer les menaces suivant l'approche collecter maintenant/déchiffrer plus tard.

Nous souhaitons profiter de ce moment de joie pour faire le point sur l'état actuel du processus de migration d'Internet vers le chiffrement post-quantique (PQC, Post-Quantum Cryptography) et sur le long chemin qui reste encore à parcourir. Notre dernière vue d'ensemble remonte à 21 mois et l'actualité s'est révélée particulièrement chargée depuis. Une grande partie des événements que nous avions prédits se sont réalisés : finalisation des normes NIST, adoption généralisée du chiffrement post-quantique, roadmaps plus détaillées de la part des organismes de réglementation, progrès dans la mise au point des ordinateurs quantiques, compromission d'une partie des algorithmes de chiffrement (pas d'inquiétude : rien de comparable à l'offre déployée) et avènement de nouveaux développements passionnants dans le domaine du chiffrement.

Toutefois, quelques surprises se trouvaient également au programme : nous avons effectué un grand pas en avant vers le « Q-Day » (le « Jour de l'avènement du quantique ») en raison de l'amélioration des algorithmes quantiques. L'un d'entre eux nous a d'ailleurs causé une grande frayeur. Voilà un aperçu des sujets que nous aborderons ici, parmi bien d'autres. Nous nous intéresserons également à ce que nous pouvons attendre dans les années à venir et à ce que vous pouvez faire dès aujourd'hui.

Commençons par le commencement. Pourquoi changeons-nous d'approche cryptographique ? Tout bonnement à cause des ordinateurs quantiques. Plutôt que de se limiter aux zéros et aux uns, ces incroyables appareils calculent en s'appuyant sur un ensemble encore plus étendu des possibilités présentées par la nature : la superposition quantique, l'interférence et l'intrication. Ces phénomènes permettent aux ordinateurs quantiques d'exceller dans certains calculs très spécifiques, notamment la simulation de la nature elle-même. Cet aspect s'avérera d'ailleurs très utile pour développer de nouveaux matériaux.

Les ordinateurs quantiques ne remplaceront toutefois pas les ordinateurs classiques. En réalité, ils se révèlent bien moins performants que les ordinateurs classiques pour la plupart des tâches importantes de notre quotidien. Vous pouvez les considérer comme des cartes graphiques ou des moteurs neuronaux : des outils spécialisés dans la réalisation de calculs spécifiques et non des appareils à usage général.

Malheureusement, les ordinateurs quantiques excellent également dans le déchiffrage de méthodes de chiffrement reposant sur des clés encore couramment utilisées aujourd'hui, comme le chiffrement RSA et le chiffrement basé sur les courbes elliptiques (ECC, Elliptic Curve Cryptography). Nous évoluons ainsi vers le chiffrement post-quantique, à savoir une approche cryptographique conçue pour résister aux attaques quantiques. Nous discuterons plus tard de l'impact exact du quantique sur les différents types de chiffrement.

Pour le moment, les ordinateurs quantiques se montrent plutôt anémiques. Ils ne sont tout simplement pas assez performants à l'heure actuelle pour briser les clés cryptographiques utilisées en conditions réelles. Ce n'est pas pour autant que nous devons cesser de nous inquiéter pour le présent. Le trafic chiffré peut ainsi être collecté aujourd'hui et déchiffré après le Q-Day, c'est-à-dire le jour où les ordinateurs quantiques seront capables de briser les méthodes de chiffrement encore largement utilisées à l'heure actuelle, comme le RSA-2048. C'est ce que nous appelons une attaque de type « collecter maintenant, déchiffrer plus tard ».

Si l'on utilise la factorisation comme référence, les ordinateurs quantiques n'impressionnent en aucune façon : le plus grand nombre factorisable par un ordinateur quantique (sans tricher) est 15, un record facilement battu de bien des manières pour le moins « ludiques ». Il est tentant d'ignorer les réalisations des ordinateurs quantiques tant que leurs capacités en matière de factorisation ne surpassent pas celles des ordinateurs classiques, mais ce serait commettre une grave erreur. Toutes les estimations, même les plus prudentes, situent le Q-Day moins de trois ans après le jour où les ordinateurs quantiques parviendront à supplanter les ordinateurs classiques en matière de factorisation. Alors, comment suivre leur progression dans ces circonstances ?

Deux catégories sont à prendre en compte dans la marche vers le Q-Day : les progrès réalisés au niveau du matériel quantique et les améliorations algorithmiques apportées aux logiciels qui fonctionnent sur ces équipements physiques. Nous avons constaté d'importantes évolutions sur ces deux fronts.

La presse annonce tous les ans, avec une régularité d'horlogerie, le lancement de nouveaux ordinateurs quantiques affichant un nombre record de qubits. Toutefois, l'accent mis sur le nombre de qubits se révèle là encore assez trompeur. Pour commencer, les ordinateurs quantiques sont des machines analogiques. Un certain bruit vient donc toujours interférer avec leurs calculs.

De même, de grandes différences existent entre les différents types de technologie utilisées pour bâtir une machine quantique : les ordinateurs quantiques reposant sur le silicium semblent faciles à redimensionner à l'échelle souhaitée et exécutent rapidement les instructions reçues, mais disposent de qubits très bruyants. Ils n'en sont pas inutiles pour autant. En effet, les codes de correction d'erreurs quantiques permettent de transformer efficacement des millions de qubits à base de silicium bruyants en quelques milliers de qubits haute fidélité, soit un nombre qui pourrait suffire à briser le chiffrement RSA. Les ordinateurs quantiques à ions piégés, quant à eux, présentent beaucoup moins de bruit, mais se révèlent plus difficiles à faire évoluer. Seules quelques centaines de milliers de qubits à ions piégés pourraient potentiellement venir à bout du code du RSA-2048.

^{Chronologie du meilleur de l'informatique quantique entre 2021 et 2025. L'axe des abscisses présente le nombre de qubits et celui des ordonnées, le bruit. Les points dans la zone grise représentent les différents ordinateurs quantiques disponibles sur le marché. Le début des problèmes commencera lorsque la zone grisée atteindra la ligne rouge la plus à gauche, car un ordinateur quantique sera alors devenu suffisamment puissant pour casser des clés RSA de grande taille. Graphique compilé par Samuel Jaques, de l'Université de Waterloo.}

Le débat entre le nombre de qubits et le bruit ne fait que commencer. D'autres détails de bas niveau sont susceptibles de faire une grande différence, comme l'interconnexion des qubits, par exemple. Plus important encore, le graphique ne restitue pas le potentiel d'évolution de la technique à l'œuvre derrière ces records.

Ainsi, si l'on s'en réfère aux graphiques, les progrès des ordinateurs quantiques semblent avoir stagné ces deux dernières années. Or, pour les experts, l'annonce de Willow par Google en décembre 2024 (une actualité qui ne se distingue pas particulièrement sur le graphique) représente en réalité un véritable tournant, qui marque le moment où nous avons atteint le premier qubit logique au sein du code de surface, de manière évolutive. Comme le dit lui-même Sam Jaques :

« J'ai eu des frissons lorsque j'ai lu ces résultats [les réalisations de Willow]. Je me suis dit : « Ouah, l'informatique quantique, c'est vraiment une réalité ! »

S'il s'agit là d'un réel bond en avant, nous ne sommes toutefois pas dans l'inattendu. Pour citer Sam à nouveau :

« Malgré mon enthousiasme, nous en sommes plus ou moins là où nous devrions être, voire un peu en retard. Toutes les grandes avancées qui ont été démontrées constituent des étapes que nous devions atteindre pour espérer arriver à la machine de 20 millions de qubits qui se révélera capable de briser le RSA. Ça n'existe pas, une percée inattendue. Tout cela ressemble un peu à l'augmentation annuelle de la densité des transistors sur les puces classiques. Ça reste un exploit impressionnant, mais en fin de compte, c'est un peu la routine habituelle. »

Cette routine habituelle s'applique également à la stratégie : l'approche des qubits supraconducteurs adoptée par Google pour Willow s'est toujours présentée comme le chemin le plus direct pour s'attaquer directement aux difficultés, celle qui nécessitait le moins de bonds technologiques.

Microsoft poursuit la stratégie opposée en pariant sur les qubits topologiques, des qubits qui seraient, en théorie, quasiment insensibles au bruit. Ces derniers n'ont toutefois pas été pleinement concrétisés de manière physique à cette heure. Ils se montreraient éminemment supérieurs aux qubits supraconducteurs s'ils pouvaient être construits sous une forme évolutive, mais nous ne savons même pas s'ils peuvent l'être pour commencer. Au début de l'année 2025, Microsoft a annoncé le processeur Majorana 1, qui montre comment ces qubits pourraient être construits. Cette puce est cependant loin d'être un véritable prototype : elle ne prend en charge aucun calcul et n'apparaît donc même pas dans le graphique comparatif compilé par Sam ci-dessus.

Entre les qubits topologiques et les qubits supraconducteurs, les laboratoires à travers le monde suivent une quantité d'autres approches qui figurent sur le graphique, quant à elles, comme QuEra avec les atomes neutres et Quantinuum avec son approche des ions piégés.

Les progrès concernant l'aspect matériel des machines qui nous permettront d'arriver un jour au Q-Day ont de loin suscité le plus d'intérêt de la part de la presse, mais la plus grande percée de ces deux dernières années se situe toutefois à un autre niveau.

Avec l'approche supraconductrice, nous pensions avoir besoin d'environ 20 millions de qubits pour briser le modèle RSA-2048. Il s'avère que nous pouvons parvenir au même résultat avec beaucoup moins de ressources. Dans un article incroyablement complet datant de juin 2025, Craig Gidney montre qu'avec des optimisations logicielles quantiques intelligentes, nous avons en réalité besoin de moins d'un million de qubits. C'est la raison pour laquelle les lignes rouges du graphique de Sam ci-dessus (qui indiquent la taille que doit atteindre un ordinateur quantique pour casser le RSA) ont opéré une translation spectaculaire vers la gauche en 2025.

Pour mettre cet exploit en perspective, imaginons que Google réussisse à doubler le nombre de qubits physiques tous les 18 mois (un peu comme une sorte de loi de Moore appliquée au quantique). Il s'agit là d'un rythme bien plus rapide que ce à quoi Google nous a habitués jusqu'à présent, mais il n'est pas impensable que l'entreprise puisse y parvenir une fois le travail de fond effectué. Il faudrait ainsi attendre 2052 pour atteindre les 20 millions de qubits, mais seulement 2045 pour atteindre le million. À lui seul, Craig a donc rapproché le Q-Day de sept ans !

Jusqu'où peuvent aller les optimisations logicielles ? Pour Sam, il semble impossible de descendre en dessous des 100 000 qubits supraconducteurs. Il s'attend d'ailleurs à ce que plus de 242 000 qubits supraconducteurs soient nécessaires pour percer le chiffrement RSA-2048. En prenant pour base les suppositions actuelles concernant les progrès de l'informatique quantique, le Q-Day se produirait dès lors en 2039 et 2041 (peut-être un peu plus tard pour cette deuxième date).

L'estimation de Craig repose sur des hypothèses détaillées et raisonnables concernant l'architecture d'un ordinateur quantique à qubits supraconducteurs déployé à grande échelle, mais il s'agit toujours d'une estimation, qui pourrait s'avérer assez éloignée de la réalité en définitive.

Du point de vue algorithmique, nous pourrions non seulement assister à une amélioration des algorithmes quantiques existants lors des années à venir, mais également à la découverte d'algorithmes totalement nouveaux. En avril 2024, Yilei Chen a publié un preprint (prépublication) annonçant la découverte d'un nouvel algorithme quantique pour résoudre certains problèmes concernant les réseaux euclidiens (lattices). S'ils sont proches, ces problèmes restent néanmoins différents de ceux sur lesquels nous nous appuyons pour la technologie de chiffrement post-quantique que nous déployons. Cette actualité a fait grand bruit. Même s'il ne peut s'attaquer à nos algorithmes post-quantiques à l'heure actuelle, l'algorithme de Chen pourrait-il néanmoins être amélioré ? Pour avoir une idée du potentiel d'amélioration, il est nécessaire de bien comprendre ce que l'algorithme accomplit réellement à un niveau supérieur. Or, cette tâche s'avère pour le moins difficile avec l'algorithme de Chen, car il est très complexe, bien plus que l'algorithme quantique de Shor qui va venir à bout du RSA. Il a donc fallu un certain temps aux experts pour commencer à entrevoir les limites de l'approche de Chen. Ces derniers ont d'ailleurs fini par découvrir un bug fondamental au sein de l'algorithme dix jours après sa publication : l'approche ne fonctionne pas. La crise a donc été évitée.

Quels enseignements retirer de cette expérience ? Si l'on observe la situation de manière optimiste, nous restons là dans l'ordinaire du chiffrement. Les réseaux euclidiens sont même en meilleure posture maintenant, car une voie d'attaque potentielle a finalement débouché sur une impasse. D'un point de vue réaliste, l'expérience nous rappelle toutefois que nous avons mis tous nos œufs dans le panier des réseaux euclidiens. Comme nous le verrons plus tard, il n'existe, à l'heure actuelle, aucune véritable alternative qui fonctionne partout et à tous les niveaux.

Les partisans de la distribution quantique de clé (QKD, Quantum Key Distribution) pourraient faire valoir que cette approche résout précisément le problème, car elle s'appuie sur les lois de la nature pour assurer la sécurisation. Cette affirmation doit être prise avec quelques réserves, bien entendu, mais à un niveau plus fondamental, personne n'a encore trouvé comment faire évoluer la QKD au-delà des connexions point à point, comme nous l'expliquons dans cet article de blog.

S'il reste bon de spéculer sur l'approche de chiffrement qui sera balayée par une attaque d'un genre totalement nouveau, n'oublions pas le problème actuel : une grande partie des méthodes de chiffrement voleront certainement en éclats devant les ordinateurs quantiques. Le Q-Day approche à grands pas. Toute la question consiste à savoir quand.

Si vous travaillez dans ou autour du secteur du chiffrement et de la sécurité depuis suffisamment longtemps, vous avez probablement entendu dire que « le Q-Day se produira dans X ans », chaque année, depuis plusieurs années. Ce genre d'affirmation peut donner l'impression que le Q-Day est perpétuellement fixé à « un jour dans le futur »… jusqu'à ce que nous replacions cette affirmation dans le contexte approprié.

Depuis 2019, le Global Risk Institute (l'Institut mondial du risque) contacte des experts dans le cadre d'une enquête annuelle qui les interroge sur la probabilité que le RSA-2048 soit brisé d'ici 5, 10, 15, 20 ou 30 ans. Voici les résultats pour l'année 2024 (les entretiens ont eu lieu avant le lancement de Willow et la découverte de Gidney).

^{Résultats de l'enquête 2024 réalisée auprès d'experts par le Global Risk Institute et concernant la probabilité qu'un ordinateur quantique parvienne à percer le chiffrement RSA-2048 selon différentes chronologies.}

Comme le montre la colonne centrale de ce graphique, plus de la moitié des experts interrogés ont estimé qu'il existait au moins 50 % de chances qu'un ordinateur quantique parvienne à percer le RSA-2048 d'ici 15 ans. Consultons les réponses des années précédentes : 2019, 2020, 2021, 2022 et 2023. Nous considérons ici la probabilité que le Q-Day se produise dans un délai de 15 ans (au moment de l'entretien) :

^{Réponses des rapports précédents sur la chronologie des menaces quantiques concernant la probabilité que le Q-Day survienne dans les 15 ans.}

Le graphique montre que les réponses tendent progressivement vers davantage de certitude, mais augmentent-elles effectivement au rythme que nous pouvons attendre ? Avec six années de réponses, nous pouvons représenter graphiquement la cohérence des prédictions sur une année : l'estimation à 15 ans pour l'année 2019 correspond-elle à l'estimation sur 10 ans de 2024 ?

^{Réponses des rapports précédents sur la chronologie des menaces quantiques concernant la date du Q-Day au fil des ans. L'axe des abscisses montre l'année lors de laquelle le Q-Day devrait censément se produire, tandis que l'axe des ordonnées montre la part des experts interrogés qui pensent qu'il est probable que cet événement survienne à au moins 50 % (à gauche) ou 70 % (à droite).}

Si nous demandons à un panel d'experts à quelle date le Q-Day pourrait avoir lieu, à probabilité égale (graphique de gauche), la plupart d'entre eux continuent à donner la même réponse année après année : oui, ce type d'événement pourrait se produire dans 15 ans. Toutefois, si nous insistons pour qu'ils se prononcent avec davantage de certitude, soit avec une probabilité supérieure à 70 % (graphique de droite) que le Q-Day se produise, les experts restent généralement cohérents au fil des ans. Un cinquième des personnes interrogées ont pensé à l'année 2034 lors des enquêtes réalisées en 2019 et en 2024, par exemple.

Donc, si vous souhaitez obtenir une réponse cohérente de la part d'un expert, ne lui demandez pas la date du Q-Day, mais plutôt à quelle date il est probable qu'il se produise. S'il peut être amusant d'essayer de deviner à quel moment le Q-Day surviendra, la seule réponse honnête est que personne ne peut le savoir avec certitude. Trop d'inconnues entrent en jeu, tout simplement. En fin de compte, la date du Q-Day se révèle bien moins importante que les dates limites définies par les organismes de réglementation.

Nous pouvons également examiner les calendriers des différentes autorités de réglementation. En 2022, la National Security Agency (NSA, l'Agence nationale de la sécurité américaine) a publié ses directives CNSA 2.0, qui fixent une date d'échéance située entre 2030 et 2033 pour la migration vers le chiffrement post-quantique. Toujours en 2022, le gouvernement fédéral américain a fixé l'année 2035 comme date-limite pour la migration complète des États-Unis. La nouvelle administration n'a pas remis en question cet objectif. En 2024, l'Australie a défini l'année 2030 comme date d'échéance forte pour sa migration. Début 2025, le NCSC britannique a fixé l'année 2035 comme date limite pour le Royaume-Uni. Mi-2025, l'Union européenne a publié sa feuille de route, avec des échéances fixées entre 2030 et 2035 en fonction de l'application.

Toutes les autorités réglementaires nationales n'ont pas défini de chronologie pour la migration vers le post-quantique, mais celles qui l'ont fait s'en tiennent généralement à la période 2030-2035.

À quelle date les ordinateurs quantiques commenceront-ils à poser problème ? Que ce soit en 2034 ou en 2050, cette date arrivera certainement trop tôt. L'immense succès rencontré par le chiffrement depuis plus de cinquante ans implique son omniprésence dans notre vie quotidienne, des lave-vaisselles aux stimulateurs cardiaques en passant par les satellites. La plupart des initiatives de modernisation s'effectueront facilement et s'intégreront naturellement au cycle de vie du produit, mais il ne faudra pas occulter la longue traîne de mises à niveau difficiles et coûteuses.

Intéressons-nous maintenant au processus de migration vers le chiffrement post-quantique.

Afin de faciliter la hiérarchisation, il est important de comprendre que les différents types de chiffrement nécessaires à l'établissement de connexions sécurisées présentent des différences significatives en termes de difficulté, d'impact et d'urgence du processus de migration post-quantique. En réalité, la plupart des entreprises procéderont à deux migrations post-quantiques : la migration des accords de clé et la migration des signatures/certificats. Nous allons expliquer le fonctionnement de ces deux migrations en prenant pour contexte l'établissement d'une connexion sécurisée lors de la visite d'un site web à l'aide d'un navigateur.

Le chiffrement symétrique (comme l'algorithme AES-GCM) constitue l'épine dorsale cryptographique d'une connexion. Il représente exactement ce que l'on imagine lorsque l'on pense au chiffrement : les deux parties (ici le navigateur et le serveur) partagent une clé et chiffrent/déchiffrent leurs messages à l'aide de cette même clé. Un utilisateur ne peut rien lire ni modifier à moins de disposer de cette clé.

La bonne nouvelle, c'est que les algorithmes de chiffrement symétrique (comme l'AES-GCM donc) sont déjà sécurisés contre le post-quantique. On pense souvent à tort que l'algorithme quantique de Grover nous contraint à doubler la longueur des clés symétriques. Après examen plus approfondi de cet algorithme, il est évident que cette opération n'est pas réalisable dans la pratique. La manière dont le NIST (National Institute of Standards and Technology, l'Institut national des normes et de la technologie des États-Unis, qui mène les efforts de normalisation du chiffrement post-quantique) définit ses niveaux de sécurité post-quantique s'avère particulièrement révélatrice. Il définit un niveau de sécurité spécifique en indiquant que le mécanisme devrait être aussi difficile à déchiffrer, à l'aide d'un ordinateur classique ou quantique, qu'un algorithme de chiffrement symétrique existant. Ces niveaux sont les suivants :

^{Niveaux de sécurité de la PQC du NIST. Plus le niveau est élevé, plus l'algorithme est difficile à percer (« plus sécurisé »). Nous aborderons le ML-DSA, le SLH-DSA et le ML-KEM en tant qu'exemples un peu plus loin dans la page.}

La suggestion consistant à doubler la longueur de la clé de chiffrement symétrique part d'une bonne intention. Dans de nombreux scénarios d'utilisation, le coût supplémentaire de cette opération n'est pas si élevé et ce fait atténue les éventuels risques théoriques. La mise à l'échelle souhaitée du chiffrement symétrique s'avère également peu coûteuse. Un nombre de bits doublé coûte ainsi généralement beaucoup moins que la moitié du coût. Il s'agit donc d'un simple conseil en apparence.

Ainsi, si nous insistons sur le déploiement du chiffrement AES-256, il semble également logique d'insister sur le déploiement d'une solution correspondant au niveau 5 de la CPQ du NIST en ce qui concerne le chiffrement à clé publique. Le problème, c'est que le chiffrement à clé publique n'est pas très facile à faire évoluer à l'échelle souhaitée. Selon le mécanisme utilisé, la différence entre le niveau 1 et le niveau 5 entraîne une multiplication par plus de deux de l'utilisation des données et des coûts processeur. Comme nous le verrons plus bas, si le déploiement de signatures post-quantiques au niveau 1 se révèle déjà pénible, leur déploiement au niveau 5 est tout bonnement incapacitant.

Plus important encore, les entreprises ne disposent que de ressources limitées. Nous ne souhaitons pas qu'une entreprise privilégie la migration vers le chiffrement AES-128 en devant pour ce faire maintenir le chiffrement RSA, clairement vulnérable à l'informatique quantique.

Les algorithmes de chiffrement symétrique ne suffisent pas à eux seuls. Comment savoir quelle clé utiliser lorsque je me rends sur un site web pour la première fois ? Le navigateur ne peut pas se contenter d'envoyer une clé aléatoire, car n'importe quel acteur en train d'écouter la communication verrait également la clé. On pourrait penser l'opération impossible, mais il est possible de passer par des calculs mathématiques ingénieux pour résoudre ce problème afin que le navigateur et le serveur puissent s'accorder sur une clé partagée. Ce type de dispositif s'appelle un mécanisme d'accord de clé. Il est mis en œuvre lors de la négociation TLS. En 2024, la quasi-totalité du trafic est sécurisée à l'aide du X25519, un mécanisme d'accord de clé de type Diffie-Hellman, mais sa sécurité est totalement compromise par l'algorithme de Shor sur un ordinateur quantique. Toutes les communications sécurisées à l'aide du protocole Diffie-Hellman (et actuellement stockées) pourront être déchiffrées plus tard par un ordinateur quantique.

Il est donc urgent de procéder dès aujourd'hui à la mise à niveau des mécanismes d'accord de clé. Fort heureusement, le déploiement d'un mécanisme d'accord de clé post-quantique s'avère relativement simple. En outre, comme nous l'avons vu précédemment, la moitié des requêtes adressées à Cloudflare fin 2025 sont déjà sécurisées par un tel mécanisme !

L'accord de clé permet un échange de clés sécurisé, mais le processus comporte néanmoins une lacune importante : nous ne savons pas avec qui nous nous sommes accordés sur la clé. Si nous nous contentions de procéder à un simple échange de clés, un acteur malveillant en position d'interception pourrait effectuer des échanges distincts avec le navigateur et le serveur, avant de rechiffrer l'ensemble des messages échangés. Un dernier ingrédient est nécessaire pour éviter cette situation : l'authentification.

L'opération est rendue possible par l'utilisation de signatures. Lorsque vous vous rendez sur un site web, comme cloudflare.com, par exemple, le serveur web présente un certificat signé par une autorité de certification (CA, Certification Authority) qui atteste que la clé publique de ce certificat est bien contrôlée par cloudflare.com. Le serveur web signe ensuite la négociation et la clé partagée à l'aide de la clé privée correspondant à la clé publique présente dans le certificat. Ce processus permet au client de s'assurer qu'il a bien passé un accord de clé avec cloudflare.com.

Deux mécanismes de signature traditionnels, le RSA et l'ECDSA, sont fréquemment utilisés aujourd'hui. Là encore, en permettant à un pirate quantique de falsifier n'importe quelle signature, l'algorithme de Shor les balaie en un instant. Un acteur malveillant disposant d'un ordinateur quantique peut donc usurper l'identité d'un utilisateur (et procéder à une attaque de l'homme du milieu, également appelée MitM, « Man-in-the-Middle ») sur n'importe quel site web pour lequel nous acceptons des certificats non préparés pour le post-quantique.

Ce type d'attaque ne pourra être lancé qu'une fois les ordinateurs quantiques capables de déchiffrer le RSA/l'ECDSA. À première vue, cette constatation rend la mise à niveau des mécanismes de signature TLS moins urgente, car il suffit que tout le monde ait terminé sa migration avant le Q-Day. Nous verrons malheureusement que la migration vers les signatures post-quantiques s'avère bien plus difficile que prévu et demandera davantage de temps.

Avant de nous intéresser plus en détail aux défis techniques liés à la migration de l'Internet vers le chiffrement post-quantique, examinons de quelle manière nous en sommes arrivés là et ce à quoi nous pouvons attendre dans les années à venir. Commençons par la genèse du chiffrement post-quantique.

Les physiciens Feynman et Manin ont suggéré le concept d'ordinateurs quantiques en indépendants vers 1980. Il faudra attendre encore 14 ans avant que Shor ne publie son algorithme remettant en cause les modèles de chiffrement RSA et ECC. Les méthodes de chiffrement post-quantique sont, pour la plupart, antérieures au célèbre algorithme de Shor.

Le domaine du chiffrement post-quantique se décompose en différentes branches, dont les plus importantes reposent sur les réseaux euclidiens (lattice-based), sur les fonctions de hachage (hash-based), sur l'analyse multivariée (multivariate), sur le code (code-based) et sur les isogénies (isogeny-based). À l'exception du chiffrement basé sur les isogénies, aucune de ces méthodes n'a été conçue à l'origine pour la cryptographie post-quantique. En réalité, les premiers schémas basés sur le code et sur les fonctions de hachage sont contemporains du RSA. Initialement proposés dans les années 1970, ils sont donc largement antérieurs à la publication de l'algorithme de Shor en 1994. De même, le premier schéma multivarié remonte à 1988 et s'avère donc bien plus ancien que l'algorithme de Shor. Ainsi, c'est par un pur hasard que la branche la plus performante, le chiffrement basé sur les réseaux euclidiens, se révèle la plus proche contemporaine de Shor (elle a été proposée en 1996). À titre de comparaison, le chiffrement basé sur les courbes elliptiques (largement utilisée aujourd'hui) a été proposé pour la première fois en 1985.

Dans les années qui ont suivi la publication de l'algorithme de Shor, les cryptographes ont évalué le panorama existant du chiffrement : quels sont les aspects qui ne fonctionnent manifestement plus et comment pourrait-on imaginer le post-quantique ? Le premier atelier international annuel consacré au chiffrement post-quantique s'est déroulé en 2006. Un texte introductif, qui constitue toujours une bonne introduction à ce champ d'études, a été préparé à l'issue de cette conférence. La chute du mécanisme de signature Rainbow constitue néanmoins une mise en garde notable. Le mécanisme d'accord de clé sur courbes elliptiques X25519 a été proposé cette même année (2006). Il sécurise désormais la majorité des connexions Internet, que ce soit de manière autonome ou hybride, à l'aide du ML-KEM-768 post-quantique. 

Dix ans plus tard, en 2016 donc, le NIST a lancé un concours public consacré à la normalisation du chiffrement post-quantique. À cette occasion, l'institut a employé un format ouvert similaire à celui qui a servi à normaliser l'AES en 2001 et le SHA3 en 2012. Tout le monde pouvait participer au concours en soumettant des mécanismes et en évaluant les propositions. Les cryptographes du monde entier ont envoyé leurs algorithmes pour examen. Afin de concentrer les efforts, la liste de propositions a été réduite après trois tours. Sur les 82 algorithmes initialement soumis, huit ont été sélectionnés sur la base des commentaires du public et ont atteint la finale. Parmi ces huit finalistes, le NIST a choisi en 2022 d'en sélectionner quatre à normaliser en premier : un KEM (pour « Key Agreement », accord de clé) et trois mécanismes de signature.

Les normes finales correspondant aux trois premiers de la liste ont été publiées en août 2024. La FN-DSA a pris du retard et nous en discuterons plus loin.

Le ML-KEM est le seul mécanisme d'accord de clé post-quantique normalisé à ce jour. Il s'agit en outre d'une mise à niveau plutôt facile à mettre en œuvre, malgré certaines difficultés occasionnelles liées à la plus grande taille des clés.

La situation est plutôt différente du côté des signatures. Il est d'ailleurs assez révélateur que le NIST ait déjà choisi d'en normaliser trois. Le nombre de signatures devant être normalisées sera encore plus élevé à l'avenir. Ce constat s'explique par le fait qu'aucun des modèles de signatures proposés ne se révèle particulièrement idéal. En résumé, nous disposons tous aujourd'hui de clés et de signatures de taille beaucoup plus importante que celles auxquelles nous sommes habitués.

Du point de vue de la sécurité, le SLH-DSA constitue le choix le plus prudent, mais également le moins performant. En ce qui concerne la taille des clés publiques et des signatures, le FN-DSA l'emporte clairement sur les trois autres, mais le processus de signature se révèle difficile à déployer en toute sécurité du fait de son modèle arithmétique à virgule flottante. En raison de l'applicabilité limitée et de la complexité de conception du FN-DSA, le NIST a choisi de se concentrer en premier lieu sur les trois autres mécanismes.

Le ML-DSA constitue donc le choix par défaut. Vous trouverez des comparatifs plus approfondis ci-dessous.

Le simple fait de disposer de normes définies par le NIST ne suffit pas. Il est également nécessaire d'uniformiser la manière dont les nouveaux algorithmes sont utilisés dans les protocoles de niveau supérieur. Dans de nombreux cas, comme le mécanisme d'accord de clé utilisé par le protocole TLS, rien de plus simple : il suffit d'attribuer un identifiant aux nouveaux algorithmes. Dans d'autres, comme pour le DNSSEC, l'opération demande un peu plus de réflexion. De nombreux groupes de travail de l'IETF se préparent depuis des années à l'arrivée des normes finales du NIST. Quant à nous, nous nous attendions à ce que de nombreuses intégrations de protocoles soient finalisées peu après, soit avant la fin de l'année 2024. Cette estimation s'est révélée trop optimiste : certaines normes sont terminées, mais beaucoup d'autres en sont loin.

Commençons par les bonnes nouvelles et intéressons-nous aux normes finalisées.

• Le mécanisme d'accord de clé TLS hybride X25519MLKEM768, qui allie le X25519 et le ML-KEM-768 (nous y reviendrons plus tard), est prêt à l'emploi et, dans les faits, largement déployé. D'autres protocoles adoptent également le ML-KEM sous un mode de fonctionnement hybride, comme l'IPsec, prêt à l'emploi pour les configurations simples. (Un petit problème reste à résoudre pour certaines configurations. Nous aborderons le sujet dans un prochain article de blog.) Il peut être surprenant de constater que les RFC correspondantes n'aient pas encore été publiées. Toutefois, l'enregistrement d'un mécanisme d'accord de clé TLS ou IPsec ne nécessite pas de RFC. Dans les deux cas, la RFC est toujours en application afin d'éviter toute forme de confusion pour ceux qui attendent une RFC. Pour le TLS, il est nécessaire d'identifier l'accord de clé comme recommandé.

• En ce qui concerne les signatures, l'intégration du ML-DSA aux certificats X.509 et au protocole TLS est prête. La première norme est une RFC fraîchement définie, tandis que la seconde n'en a pas besoin.

Passons maintenant aux mauvaises nouvelles. Au moment de la rédaction de cet article, soit en octobre 2025, l'IETF n'a pas encore défini la marche à suivre pour les certificats hybrides, c'est-à-dire les certificats qui combinent un mécanisme de signature post-quantique et un mécanisme de signature traditionnel. L'opération est toutefois presque terminée. Nous espérons que le problème sera résolu d'ici le début de l'année 2026.

Mais quelle est donc la cause de ce retard s'il suffit d'attribuer quelques identifiants ? Il s'agit surtout d'une question de choix. Commençons par les choix qui ont dû être faits pour le ML-DSA.

Les deux principaux sujets de discussion concernant les certificats ML-DSA tournaient autour du pré-hachage (prehashing) et du format des clés privées.

Le pré-hachage désigne le processus par lequel une partie du système hache le message, tandis qu'une autre crée les signatures finales. Cette approche s'avère utile si vous ne souhaitez pas envoyer un fichier volumineux à un HSM pour signature. Les premières versions du ML-DSA prenaient en charge le pré-hachage à l'aide du SHAKE256, mais l'opération n'était pas évidente. Le NIST a inclus deux variantes dans la version finale du ML-DSA : le ML-DSA standard et une version avec pré-hachage explicite, dans laquelle vous pouvez choisir n'importe quel type de hachage. Le fait de disposer de différentes variantes n'est pas idéal, car les utilisateurs devront choisir laquelle utiliser. Or, tous les logiciels pourraient ne pas prendre pas en charge l'ensemble des variantes. De même, un processus de tests/validations doit être suivi pour chacune d'elles. Le fait de vouloir choisir une seule variante ne prête aucunement à controverse, mais toute la question consiste à déterminer laquelle. Après de nombreux débats, c'est le ML-DSA standard qui a été choisi.

Le deuxième point concerne le format des clés privées. Vu la manière dont les candidats sont comparés aux référentiels de performances, la possibilité de mettre en cache certains calculs au sein de la clé privée constitue un bon point de la version ML-DSA originale. L'opération implique que la clé privée sera plus volumineuse (plusieurs kilo-octets) qu'elle n'a besoin de l'être et nécessitera davantage d'étapes de validation. L'une des suggestions visait à réduire la clé privée à l'essentiel : une simple graine de 32 octets. Pour la norme finale, le NIST a décidé d'autoriser à la fois la graine et la clé privée originale, de plus grande taille. Cette situation n'est pas idéale : mieux vaut s'en tenir à l'une des deux options. Dans ce cas précis, l'IETF n'est pas parvenu à faire un choix et a même ajouté une troisième option : une paire contenant à la fois la graine et la clé privée étendue. Techniquement, presque tout le monde s'accordait à dire que la graine constitue le meilleur choix, mais la raison pour laquelle elle n'a pas obtenu la préférence réside dans le fait que certains fournisseurs avaient déjà créé des clés pour lesquelles ils n'avaient pas conservé la graine. Oui, nous sommes déjà en présence d'un héritage post-quantique. Il a fallu près d'un an pour parvenir à ces deux choix.

De nombreux choix supplémentaires doivent être effectués pour définir un mécanisme de signature ML-DSA hybride. Avec quel mécanisme traditionnel associer le ML-DSA ? Quels sont les niveaux de sécurité de chaque côté ? Nous devons ensuite également faire des choix pour les deux mécanismes : quel format de clé privée utiliser ? Quel type de hachage utiliser avec l'ECDSA ? Les mécanismes hybrides soulèvent de nouvelles questions qui leur sont propres. Comptons-nous autoriser la réutilisation des clés au sein du mécanisme hybride et, si oui, souhaitons-nous empêcher les attaques par suppression ? La question du pré-hachage revient en outre avec une troisième option : le pré-hachage au niveau hybride.

Le projet d'octobre 2025 relatif aux signatures hybrides ML-DSA contient 18 variantes, contre 26 l'année précédente. Tout le monde s'accorde à dire encore une fois que ce nombre est bien trop important, mais le processus de réduction pour parvenir à ce nombre s'est avéré bien difficile. Afin d'aider les utilisateurs finaux à choisir, une courte liste a été ajoutée à l'ensemble. Elle a commencé avec trois options, mais s'est retrouvée bien vite étendue à six, bien sûr. Parmi ces mécanismes, nous pensons que le MLDSA44-ECDSA-P256-SHA256 bénéficiera d'un large soutien et sera utilisé de manière généralisée sur Internet.

Revenons maintenant au mécanisme d'accord de clé pour lequel les normes ont été établies.

L'étape suivante est le support logiciel. Tous les écosystèmes ne peuvent pas évoluer à la même vitesse, mais nous avons constaté une adoption importante du mécanisme d'accord de clé post-quantique pour contrer la stratégie « stocker maintenant, déchiffrer plus tard ». Les versions récentes de tous les principaux navigateurs ont activé le X25519MLKEM768 par défaut, de même que de nombreuses bibliothèques et plateformes TLS, notamment OpenSSL, Go et les systèmes d'exploitation Apple récents. Nous vous proposons une vue d'ensemble ici.

Là encore, une grande différence existe entre le mécanisme d'accord de clé et les signatures pour le protocole TLS. Pour le mécanisme d'accord de clé, le serveur et le client peuvent ajouter et activer la prise en charge de l'accord post-quantique de manière indépendante. Une fois la fonctionnalité activée des deux côtés, la négociation TLS utilisera un mécanisme d'accord de clé post-quantique. Nous détaillons le processus de la négociation TLS dans cet article de blog. Si votre produit utilise uniquement le TLS, le problème du « stocker maintenant, déchiffrer plus tard » pourrait être résolu par une simple mise à jour logicielle de votre bibliothèque TLS.

Les certificats TLS post-quantiques se révèlent plus problématiques. À moins de contrôler les deux extrémités de la connexion, vous devrez installer deux certificats : un certificat post-quantique pour les nouveaux clients et un certificat traditionnel pour les anciens. Si vous n'utilisez pas encore de fonctionnalité automatisée d'émission de certificats, le moment pourrait être bien choisi pour vous informer sur cette dernière. Le protocole TLS permet au client d'annoncer les mécanismes de signature qu'il prend en charge afin que le serveur puisse choisir de diffuser un certificat post-quantique uniquement aux clients qui supportent cette fonctionnalité. Malheureusement, tous les serveurs n'exposent pas cette configuration, même si la quasi-totalité des bibliothèques TLS prennent en charge la configuration de plusieurs certificats. Dans la plupart des cas, l'opération nécessitera néanmoins une modification de la configuration. (Bien entendu, caddy s'en chargera sans doute pour vous.)

À propos des certificats post-quantiques d'ailleurs, il faut savoir que les autorités de certification (CA) auront besoin d'un certain temps avant de pouvoir les émettre. Leurs HSM auront d'abord besoin d'un support (physique), qui devra ensuite faire l'objet d'un audit. Le forum CA/Browser devra en outre approuver l'utilisation des nouveaux algorithmes. Les programmes racines, quant à eux, ont des optiques divergentes concernant les délais. D'après les rumeurs, l'un des programmes racines préparerait un pilote visant à accepter les certificats ML-DSA-87 d'une durée d'un an, avec un lancement prévu potentiellement avant la fin de l'année 2025. Pour étayer cette actualité, un sondage est d'ailleurs en cours sur le forum CA/Browser. De son côté, Chrome préfère résoudre le problème des certificats de grande taille en priorité. Les audits risquent d'être le principal goulot d'étranglement pour les primo-adoptants, car les CA s'attendent à recevoir une foule de demandes après la publication des normes NIST. S'il est certain que nous verrons les premiers certificats post-quantiques en 2026, il est toutefois peu probable que ces derniers soient largement disponibles ou reconnus par tous les navigateurs avant 2027.

Nous sommes dans une période intermédiaire intéressante : une grande partie du trafic Internet est protégée par des accords de clé post-quantiques, mais aucun certificat post-quantique public n'est en cours d'utilisation.

Le NIST n'a pas tout à fait terminé de normaliser le chiffrement post-quantique. Deux autres concours post-quantiques sont en cours : le quatrième tour et le tremplin signatures.

Le NIST n'a normalisé qu'un seul mécanisme d'accord de clé post-quantique jusqu'à présent : le ML-KEM. L'institut aimerait en normaliser un deuxième afin de disposer d'un KEM de secours qui ne soit pas basé sur les réseaux euclidiens, au cas où ceux-ci s'avéreraient moins solides que prévu. Il a ajouté pour ce faire un quatrième tour au concours initial afin de choisir un KEM de secours parmi les finalistes. Le HQC a ainsi été sélectionné en mars 2025 afin d'être normalisé.

Le mécanisme HQC affiche des performances bien inférieures au ML-KEM pour chaque indicateur. Le HQC-1, la variante au niveau de sécurité le plus bas, nécessite une transmission de 7 Ko de données. C'est presque le double des 3 Ko nécessaires au ML-KEM-1024, la variante au niveau de sécurité le plus élevé pour ce mécanisme. On observe un écart similaire en matière de performances processeur. Le HQC évolue en outre de moins en moins bien lorsque le niveau de sécurité augmente. Alors que le ML-KEM-1024 demande environ le double de ressources par rapport au ML-KEM-512, le niveau de sécurité le plus élevé du HQC consomme trois fois plus de données (21 Ko !) et nécessite une puissance de calcul plus de quatre fois supérieure.

Qu'en est-il du point de vue de la sécurité ? Le ML-KEM-768 présente un avantage certain sur le HQC-1 en ce qui concerne la possibilité de se prémunir contre l'amélioration progressive des attaques : il est beaucoup plus performant et sa marge de sécurité au niveau 3 est énorme par rapport à celle du niveau 1. Et en ce qui concerne les sauts ? Le ML-KEM et le HQC s'appuient tous deux sur une structure algébrique similaire, qui repose respectivement sur les réseaux euclidiens et les codes. Il n'est ainsi pas inconcevable qu'une percée dans ce domaine puisse s'appliquer aux deux mécanismes. Les codes et les réseaux euclidiens semblent donc désormais liés, même sans la structure algébrique. Nous sommes toutefois là en pleine spéculation : une attaque d'ampleur catastrophique sur les réseaux euclidiens pourrait en effet ne pas affecter les codes, mais il ne serait pas non plus étonnant que ces derniers soient touchés de la même manière. Après tout, le RSA et l'ECC, qui présentent encore moins de similitudes, sont tous deux anéantis par les ordinateurs quantiques.

La possibilité de conserver le HQC à portée de main, juste au cas où, pourrait néanmoins nous permettre de garder l'esprit tranquille. À ce stade, nous souhaiterions vous faire part d'une anecdote issue de la semaine chaotique où nous ne savions pas encore que l'algorithme quantique de Chen contre les réseaux euclidiens comportait des lacunes. Par quoi allions-nous remplacer le ML-KEM si ces réseaux étaient affectés ? Le HQC a été brièvement envisagé, mais il apparaissait clairement qu'une variante ajustée du ML-KEM se révélerait bien plus performante.

En prenant un peu de recul, le fait que nous soyons à la recherche d'un deuxième KEM efficace constitue un véritable luxe. Si je pouvais faire un vœu concernant un nouveau mécanisme post-quantique, je ne demanderais pas un meilleur KEM, mais un meilleur mécanisme de signature. Voyons si mon vœu est exaucé.

Après l'annonce des quatre premiers lauréats fin 2022, le NIST a également lancé un nouveau concours, baptisé tremplin signatures (Signatures Onramp), afin de trouver d'autres mécanismes de signature. Ce concours présente deux objectifs. La première consiste à se prémunir contre les avancées cryptanalytiques à l'encontre du chiffrement basé sur les réseaux euclidiens. Le NIST souhaiterait normaliser un mécanisme de signature plus performant que le SLH-DSA (à la fois en termes de taille et de puissance de calcul), mais qui ne repose pas sur ce type de réseaux. Deuxièmement, l'institut recherche un mécanisme susceptible de s'en sortir avec les honneurs dans les scénarios d'utilisation où les outils actuels ne donnent pas de bons résultats. Nous en discuterons de manière détaillée plus loin dans cet article.

En juillet 2023, le NIST a publié les 40 projets reçus à l'occasion du premier tour d'examens publics. La communauté cryptographique s'est mise au travail et, comme de juste pour un premier tour, de nombreux mécanismes ont été invalidés en une semaine. Dix projets avaient été totalement éliminés une fois le mois de février 2024 arrivé et plusieurs autres ont été considérablement affaiblis. En octobre 2024, le NIST a sélectionné 14 projets pour le second tour parmi les candidats restants en lice.

Nous avons publié un article de blog traitant de ces 14 projets dans le détail l'année dernière. En bref, des progrès considérables ont été réalisés en matière de mécanismes de signature post-quantique. Nous les évoquerons brièvement plus tard et ferons le point sur les avancées survenues depuis l'année dernière. Il convient de mentionner qu'à l'instar de la manière dont le principal concours post-quantique se déroule, le processus de sélection demandera de nombreuses années. Il est peu probable qu'un des mécanismes issus du tremplin signatures soit normalisé avant 2028, si tant est qu'il ne soit pas invalidé d'ici là. Nous ne pouvons ainsi pas avoir la certitude que de meilleurs mécanismes de signature résoudront nos problèmes actuels, même si ces systèmes seront bien entendu plus que bienvenus à l'avenir. Comme l'écrit Eric Rescorla, l'éditeur du TLS 1.3 : « On part au front avec les algorithmes dont on dispose, pas avec ceux dont on aimerait disposer. »

Conservons ces éléments en mémoire et intéressons-nous aux progrès concernant les déploiements.

Maintenant que nous disposons d'une vue d'ensemble, examinons de plus près certains détails du mécanisme X25519MLKEM768, désormais largement déployé.

Penchons-nous en premier lieu sur la partie post-quantique. Le mécanisme ML-KEM a été soumis sous le nom CRYSTALS-Kyber. Bien qu'il s'agisse d'une norme américaine, ses concepteurs travaillent dans les milieux professionnels et universitaires en France, en Suisse, aux Pays-Bas, en Belgique, en Allemagne, au Canada, en Chine et aux États-Unis. Jetons un œil à ses performances.

À l'heure actuelle, la vaste majorité des clients utilisent le mécanisme d'accord de clé traditionnel X25519. Comparons-le au ML-KEM.

^{Comparatif des différences en termes de taille et d'efficacité processeur entre le X25519 et le ML-KEM. Les performances varient considérablement selon la plateforme matérielle et les contraintes de mise en œuvre. Elles ne sont données ici qu'à titre d'indication approximative.}

Les variantes ML-KEM-512, ML-KEM-768 et ML-KEM-1024 sont conçues pour se montrer aussi résistantes aux attaques (quantiques) que les algorithmes AES-128, AES-192 et AES-256, respectivement. Même au niveau de l'AES-128, le ML-KEM s'avère beaucoup plus volumineux que le X25519. Il nécessite ainsi une transmission de 800 + 768, soit 1 568 octets, là où le X25519 n'en nécessite que 64.

À l'inverse, le ML-KEM (même le ML-KEM-1024) se montre bien beaucoup plus rapide que le X25519, bien que les chiffres réels puissent varier considérablement en fonction de votre plateforme et de votre déploiement.

Nous ne profitons pas encore de cette augmentation de vitesse. Comme beaucoup d'autres primo-adoptants, nous préférons la sécurité et ainsi déployer un mécanisme d'accord de clé hybride, qui allie le X25519 et le ML-KEM-768. Cette combinaison pourrait vous surprendre pour deux raisons.

1. Pourquoi combiner le X25519 (« 128 bits de sécurité ») et le ML-KEM-768 (« 192 bits de sécurité ») ?

2. Pourquoi s'encombrer du X25519 alors qu'il n'est pas post-quantique ?

Le décalage apparent en termes de niveau de sécurité constitue une protection contre les améliorations cryptanalytiques en matière de chiffrement basé sur les réseaux euclidiens. La sécurité (non post-quantique) du X25519 jouit d'une grande confiance. Il est déjà plus que suffisant d'égaler le niveau de l'AES-128. Ainsi, même si nous sommes à l'aise avec la sécurité du ML-KEM-512 à l'heure actuelle, la cryptanalyse pourrait progresser au cours des prochaines décennies. Nous souhaiterions donc conserver une marge pour le moment.

Le X25519 a été inclus pour deux raisons. Premièrement, il existe toujours une faible probabilité qu'une avancée technologique rende toutes les variantes de ML-KEM caduques. Dans ce cas, le X25519 continuera à assurer une sécurité non post-quantique et notre processus de migration vers le post-quantique n'aura pas aggravé la situation.

Plus important encore, nous devons non seulement nous soucier des attaques contre l'algorithme, mais aussi de la mise en œuvre de la sécurité. Le cas de la vulnérabilité KyberSlash, une attaque temporelle qui a affecté de nombreux déploiements du mécanisme Kyber (une version antérieure du ML-KEM), notamment le nôtre, constitue un exemple notable de moment où nous avons évité le pire. Fort heureusement, la vulnérabilité KyberSlash n'affecte pas le mécanisme Kyber lorsqu'il est utilisé dans un déploiement TLS. Une erreur de mise en œuvre similaire susceptible d'affecter effectivement le TLS nécessiterait probablement l'implication d'un acteur malveillant actif. Dans ce cas, l'objectif probable de ce dernier ne serait pas de déchiffrer des données dans plusieurs décennies, mais de dérober un cookie ou un jeton, voire d'injecter du contenu malveillant. L'inclusion du mécanisme X25519 empêche ce type d'attaque.

Alors, dans la pratique, à quel point le ML-KEM-768 et le X25519 fonctionnent-ils bien en association ?

Consciente des problèmes potentiels en matière de compatibilité et de performances, Google a lancé une première expérience de chiffrement post-quantique dès 2016, soit la même année où le NIST a proposé son concours. L'opération a été suivie d'une deuxième expérience menée de manière conjointe par Cloudflare et Google en 2018. Nous avons testé deux mécanismes hybrides d'accord de clé post-quantique : le CECPQ2 (une combinaison entre le NTRU-HRSS basé sur les réseaux euclidiens et le X25519) et le CECPQ2b (une combinaison entre le mécanisme SIKE, basé sur les isogénies, et le X25519). Le NTRU-HRSS est très similaire au ML-KEM en termes de taille, mais un peu plus exigeant au niveau des calculs côté client. Le SIKE, quant à lui, utilise des clés de très petite taille, s'avère particulièrement coûteux en termes de puissance de calcul et a été totalement invalidé en 2022. La combinaison X25519+NTRU-HRSS s'est révélée très performante en ce qui concerne les temps nécessaires à l'établissement d'une négociation TLS.

Une petite (mais néanmoins significative) proportion de clients a malheureusement rencontré des problèmes de connexion avec le NTRU-HRSS du fait de la taille des partages de clé NTRU-HRSS. Par le passé, le premier message envoyé par le client lors de l'établissement d'une connexion TLS (le ClientHello) tenait presque toujours dans un seul paquet réseau. La spécification TLS permet un ClientHello plus long, mais personne ne s'est vraiment servi de cette possibilité jusqu'ici. L'ossification des protocoles frappe ainsi à nouveau, car certains boîtiers intermédiaires, équilibreurs de charge et autres logiciels partent tacitement du principe que le ClientHello tient toujours dans un paquet unique.

Au cours des années suivantes, nous avons poursuivi nos expérimentations post-quantiques avec l'adoption de Kyber en 2022, puis du ML-KEM en 2024. Chrome a effectué un travail remarquable de contact des fournisseurs dont les produits se révélaient incompatibles. Sans ces problèmes de compatibilité, nous aurions probablement vu Chrome adopter les mécanismes d'accord de clé post-quantiques cinq ans plus tôt. En effet, il a fallu attendre mars 2024 pour que Chrome se sente suffisamment à l'aise pour activer l'accord de clé post-quantique par défaut sur Desktop. De nombreux autres clients, de même que l'ensemble des principaux navigateurs, ont ensuite emboîté le pas à Chrome et activé cette fonctionnalité par défaut. Voici une chronologie succincte :

Vous noterez certainement l'existence d'un décalage entre l'activation du post-quantique par Chrome sur Desktop et sur Android. Si le ML-KEM ne présente pas un impact de taille sur les performances (comme le montrent les graphiques), il n'est cependant pas négligeable non plus, notamment sur la longue traîne de connexions plus lentes, plus fréquentes sur les appareils mobiles. Sa mise en œuvre a donc nécessité davantage de réflexion.

Nous y sommes néanmoins enfin arrivés ! Plus de 50 % (et cette proportion augmente constamment !) du trafic d'origine humaine est désormais protégé contre les attaques de type « stocker maintenant/déchiffrer plus tard ». L'accord de clé post-quantique est ainsi devenu la nouvelle référence en matière de sécurité du web.

Les navigateurs représentent un aspect de l'équation, mais qu'en est-il des serveurs ?

Nous avons activé les mécanismes d'accord de clé post-quantiques côté serveur pour la quasi-totalité de nos clients depuis 2022. Google a fait de même pour la plupart de ses serveurs (sauf GCP) en 2023. De nombreux autres acteurs nous ont emboîté le pas depuis lors. Jan Schaumann publie régulièrement des analyses des 100 000 principaux domaines. Dans son article de septembre 2025, il indique que la prise en charge du chiffrement post-quantique atteint désormais les 39 %, contre 28 % six mois plus tôt. À la lecture de son étude, nous constatons non seulement le déploiement de cette prise en charge chez de grands fournisseurs de services, comme Amazon, Fastly, Squarespace, Google et Microsoft, mais également au sein d'un petit nombre croissant de serveurs auto-hébergés chez Hetzner et OVHcloud.

Nous avons parlé jusqu'ici de la portion d'Internet web accessible au public. Qu'en est-il des serveurs situés derrière un service comme Cloudflare ?

En septembre 2023, nous avons élargi cette prise en charge afin de permettre à nos clients d'activer l'accord de clé post-quantique sur les connexions entre Cloudflare et leurs serveurs d'origine. Cette prise en charge est représentée par la connexion (3) dans le schéma ci-dessous :

^{Schéma décrivant le processus de connexion typique survenant lorsqu'un visiteur demande une page non mise en cache.}

En 2023, 0,5 % seulement des serveurs d'origine prenaient en charge les mécanismes d'accord de clé post-quantiques. La situation n'a pas foncièrement évolué jusqu'en 2024. Cette année, en 2025 donc, nous constatons que les chiffres de cette prise en charge commencent à rejoindre lentement ceux du déploiement du support logiciel. Nous en sommes désormais à 3,7 %.

^{Part des serveurs d'origine prenant en charge le mécanisme d'accord de clé post-quantique X25519MLKEM768.}

Ce chiffre de 3,7 % peut sembler peu impressionnant par rapport aux 50 % et aux 39 % précédents concernant les clients et les serveurs publics, mais il ne faut néanmoins pas le sous-estimer. Les serveurs d'origine sont bien plus divers que les clients et un nombre beaucoup plus important d'acteurs doivent intervenir pour faire augmenter ce nombre. Ce chiffre a ainsi été plus que multiplié par sept. N'oublions pas que nous avons célébré le fait d'avoir atteint les 1,8 % de prise en charge client en 2024. En effet, les serveurs d'origine ne sont pas toujours faciles à mettre à niveau pour les clients. Est-ce que ce chiffre signifie que les clients risquent de passer à côté de la sécurité post-quantique ? Pas nécessairement. Vous pouvez sécuriser la connexion entre Cloudflare et votre serveur d'origine en configurant le service Cloudflare Tunnel comme complément de votre origine.

La prise en charge est certes utile, mais comme nous l'avons constaté lors des expériences sur les navigateurs, l'ossification des protocoles demeure une préoccupation majeure. Qu'en est-il pour les serveurs d'origine ? Eh bien, cela dépend.

L'activation des mécanismes d'accord de clé post-quantiques se décline de deux façons : la méthode rapide et la méthode lente, mais plus sûre. Dans les deux cas, un serveur d'origine qui ne prendrait pas en charge le post-quantique reste capable de se reposer en toute sécurité sur l'accord de clé traditionnel. Nous expliquons la situation plus en détail dans cet article de blog, mais en bref, la méthode rapide consiste à transmettre immédiatement les clés post-quantiques, tandis que la méthode plus sûre reporte cette transmission d'un aller-retour à l'aide du message HelloRetryRequest. Les principaux navigateurs utilisent tous la méthode rapide.

Nous analysons régulièrement l'ensemble des serveurs d'origine afin de contrôler ce qu'ils prennent en charge ou non. La bonne nouvelle, c'est que tous les serveurs d'origine prennent en charge la méthode sûre, mais lente. La méthode rapide ne jouit pas encore d'une adoption aussi répandue, car nous avons constaté une interruption de 0,05 % des connexions. Ce chiffre est trop élevé pour activer la méthode rapide par défaut. Nous avons activé le chiffrement post-quantique par défaut pour les serveurs d'origines (à l'aide de la méthode plus sûre) pour tous nos clients non-Enterprise. Les clients Enterprise peuvent choisir d'activer cette option.

Nous ne serons toutefois pas satisfaits tant que cette fonctionnalité ne sera pas rapide et accessible à tous. C'est pourquoi nous n'activerons automatiquement la méthode rapide de chiffrement post-quantique au sein des serveurs d'origine pour tous nos clients que si nos analyses montrent que l'opération est sûre.

Jusqu'à présent, toutes les connexions dont nous avons parlé sont établies entre Cloudflare et des parties externes. Or, de nombreuses connexions internes existent également au sein du réseau Cloudflare (la partie portant le chiffre 2 dans les deux schémas ci-dessus). En 2023, nous avons déployé beaucoup d'efforts pour mettre à niveau nos connexions internes afin qu'elles prennent en charge l'accord de clé post-quantique. Par rapport à toutes les autres initiatives post-quantiques que nous menons, il s'agit là du travail le plus important, et de loin. Nous avons demandé à chaque équipe technique de notre entreprise d'interrompre ses activités, d'évaluer les données et les connexions sécurisées par leurs produits, et de les mettre à niveau de manière à ce qu'elles prennent en charge l'accord de clé post-quantique. Dans la plupart des cas, la mise à niveau s'est révélée simple. En réalité, de nombreuses équipes étaient déjà à niveau par l'intermédiaire des mises à jour logicielles. Il faut parfois un certain temps pour comprendre que vous avez déjà atteint votre objectif ! Sur une note positive, nous n'avons également constaté aucun problème de performances ou d'ossification suite à ce déploiement.

Nous avons fait évoluer la majorité de nos connexions internes, mais une longue traîne de connexion reste à mettre à niveau et nous nous efforçons d'y parvenir. La connexion entre le client WARP et Cloudflare reste la connexion la plus importante que nous n'avons pas réussi à mettre à niveau en 2023. Nous y sommes parvenus en septembre 2025, en passant de Wireguard à QUIC.

Comme nous l'avons vu, l'accord de clé post-quantique s'est avéré des plus simples à déployer, malgré les difficultés initiales liées à l'ossification des protocoles. Dans la grande majorité des cas, ce déploiement a pris la forme d'une mise à jour logicielle sans incident. Avec un taux de déploiement de 50 % (chiffre en augmentation), il s'agit là de la nouvelle base de référence en matière de sécurité d'Internet.

Passons à la seconde migration, la plus ardue.

Intéressons-nous maintenant à la mise à niveau des signatures utilisées sur Internet.

Nous avons publié un long article consacré aux mécanismes de signature post-quantiques l'année dernière, en novembre 2024. La plupart des informations contenues dans cette étude approfondie sont toujours à jour, mais certains développements intéressants se sont produits entretemps. Les paragraphes suivants vont simplement passer en revue quelques faits marquants et mises à jour intéressantes de l'année dernière.

Commençons par évaluer les signatures post-quantiques dont nous disposons actuellement au niveau de sécurité AES-128 : le ML-DSA-44 et les deux variantes du SLH-DSA. Nous utiliserons le ML-DSA-44 comme base de référence, car il s'agit du mécanisme qui sera le plus largement répandu au départ. À titre de comparaison, nous incluons également à cet article les vénérables mécanismes Ed25519 et RSA-2048 (largement utilisés aujourd'hui), le FN-DSA-512 (qui sera bientôt normalisé) et un échantillon de neuf mécanismes de signature TLS prometteurs issus du tremplin signatures.

^{Comparaison de divers mécanismes de signature au niveau de sécurité AES-128. Les temps processeur varient considérablement selon la plateforme et les contraintes de mise en œuvre. Ils ne sont donnés ici qu'à titre d'indication approximative. ⚠️ Temps de signature FN-DSA en cas d'utilisation du modèle arithmétique à virgule flottante rapide, mais dangereux. Voir l'avertissement ci-dessous. ⚠️ Le processus de signature SQISign n'est pas sécurisé du point de vue des canaux temporels auxiliaires (timing side-channels).}

Il apparaît immédiatement qu'aucun des mécanismes de signature post-quantiques ne peut espérer s'imposer comme un remplacement direct de l'Ed25519 (un schéma comparable au ECDSA P-256), car les signatures sont pour la plupart beaucoup trop volumineuses. Issus du tremplin, les mécanismes SQISign, MAYO, SNOVA et UOV font exception à la règle, mais se révèlent loin d'être parfaits. Le MAYO, le SNOVA et l'UOV utilisent des clés publiques de grande taille, tandis que le SQISign nécessite une forte puissance de calcul.

Pour anticiper un peu : le meilleur mécanisme issu du premier concours semble être le FN-DSA-512. Les signatures et la clé publique du FN-DSA-512 ne totalisent ensemble que 1 563 octets, pour un temps de signature assez raisonnable. Le FN-DSA présente toutefois un talon d'Achille : il nécessite l'emploi du modèle arithmétique rapide à virgule flottante pour afficher des performances acceptables en termes de durée du processus de signature. Le temps de signature est environ 20 fois plus lent sans ce modèle. Toutefois, la vitesse ne fait pas tout, car le modèle arithmétique à virgule flottante doit s'exécuter en temps constant. Dans le cas contraire, la clé privée FN-DSA peut être récupérée en mesurant le temps nécessaire à la création de la signature. La rédaction d'implémentations FN-DSA sécurisées s'est en outre avérée assez difficile. Or, ce problème rend le FN-DSA dangereux lorsque les signatures sont générées à la volée, comme lors d'une négociation TLS. Il est important de souligner que ce problème n'affecte que la signature. La vérification FN-DSA ne nécessite pas l'emploi du modèle arithmétique à virgule flottante (il n'y aurait de toute façon aucune clé privée à divulguer pendant la vérification).

Le principal inconvénient de la migration d'Internet vers les signatures post-quantiques réside dans le grand nombre de signatures impliquées, même au sein d'une seule connexion. Le simple fait de se connecter à notre site web pour la première fois implique l'envoi de cinq signatures et deux clés publiques de notre part.

La majorité de ces signatures concernent la chaîne de certificats : l'autorité de certification signe le certificat intermédiaire, qui signe le certificat Leaf, qui à son tour signe la transcription TLS afin de prouver l'authenticité du serveur. Si vous comptez bien, il nous manque toujours deux signatures.

Elles interviennent sur les SCT (Signed Certificate Timestamps, horodatage de signature numérique) nécessaires à la transparence des certificats. La transparence des certificats (CT, Certificate Transparency) constitue un élément clé, mais moins connu, du Web PKI (Public Key Infrastructure, l'infrastructure à clés publiques du web), c'est-à-dire l'écosystème qui sécurise les connexions des navigateurs. Cette opération a pour objectif d'enregistrer publiquement chaque certificat émis afin que les erreurs d'émissions puissent être détectées a posteriori. Il s'agit là du système qui sous-tend le fonctionnement de crt.sh et de Cloudflare Radar. Ce système a encore récemment apporté la preuve de sa valeur en faisant apparaître un certificat non autorisé pour le résolveur 1.1.1.1.

Le processus de transparence des certificats repose sur le fait de demander à des parties indépendantes d'exécuter des journaux CT. Avant d'émettre un certificat, une autorité de certification doit d'abord l'envoyer à au moins deux journaux CT différents. Un SCT constitue la signature d'un journal CT. Il sert de preuve, de reçu, que le certificat a bien été enregistré.

Il convient de souligner l'importance de deux aspects de l'utilisation d'une signature : l'inclusion ou non de la clé publique au sein de la signature et le fait que la signature soit disponible en ligne ou hors ligne.

La clé publique n'est pas transmise lors de la négociation pour les SCT et la signature de la racine sur le certificat intermédiaire. Le MAYO, le SNOVA ou l'UOV seraient ainsi particulièrement bien adaptés aux systèmes qui recherchent un mécanisme reposant sur de petites signatures, mais des clés publiques de plus grande taille. La clé publique est incluse dans les autres signatures, pour lesquelles il est plus important de réduire la taille combinée de la clé publique et de la signature.

La signature de négociation est la seule signature à être créée en ligne. Toutes les autres signatures le sont à l'avance.  La signature de négociation est créée et vérifiée une seule fois, tandis que les autres signatures sont généralement vérifiées de nombreuses fois, par différents clients. Dans le cas de la signature de négociation, il est ainsi plus avantageux d'équilibrer les temps de signature et de vérification, qui se situent tous deux dans le hot path (le déroulement critique). Pour les autres signatures, il est préférable de disposer d'un temps de vérification plus rapide, même si cela implique un processus total de signature plus lent. C'est là l'un des avantages dont le RSA bénéficie encore aujourd'hui par rapport aux signatures basées sur les courbes elliptiques.

L'association de différents mécanismes de signature peut constituer un casse-tête amusant, mais cette approche comporte également certains inconvénients. Premièrement, l'utilisation de plusieurs mécanismes différents augmente la surface d'attaque, car la présence d'une vulnérabilité algorithmique ou liée à la mise en œuvre au sein d'un seul d'entre eux compromet l'ensemble. En outre, l'écosystème dans son ensemble doit déployer et optimiser plusieurs algorithmes, ce qui peut représenter une charge significative.

Quelles combinaisons raisonnables pouvons-nous donc essayer ?

Les projets de normes disponibles à l'heure actuelle ne nous laissent pas beaucoup d'options.

Si nous nous contentons de passer au ML-DSA-44 pour l'ensemble des signatures, nous ajoutons 15 Ko à la quantité de données qui doivent être transmises du serveur au client lors de la négociation TLS. Est-ce là une quantité importante de données ? Probablement. Nous répondrons à cette question plus tard.

Si nous attendons un peu et que nous remplaçons l'ensemble des mécanismes par le FN-DSA-512 (sauf pour la signature de négociation), nous n'ajoutons que 7 ko. C'est mieux, mais au risque de me répéter, je dois rappeler que la mise en œuvre du FN-DSA-512 de manière sécurisée se révèle des plus difficiles sans canaux temporels auxiliaires. Il y a donc de fortes chances pour que nous nous tirions une balle dans le pied si nous ne faisons pas attention. Les signatures basées sur le hachage et persistantes (stateful) constituent un autre moyen de se tirer une balle dans le pied aujourd'hui, comme nous l'expliquons ici. Dans l'ensemble, le FN-DSA-512 et les signatures persistantes basées sur le hachage sont tentants de par leur promesse similaire et claire d'avantages en termes de performances par rapport au ML-DSA-44, mais elles se révèlent difficiles à utiliser en toute sécurité.

De nouveaux mécanismes de signature prometteurs ont été soumis à l'occasion du tremplin signatures du NIST.

Si l'on se base uniquement sur la taille, le SQISign I ressort clairement vainqueur, en parvenant même à dépasser le RSA-2048. Malheureusement, la puissance de calcul nécessaire au processus de signature et (surtout) au processus de vérification s'avère trop importante. Le mécanisme SQISign est dans une position moins favorable que le FN-DSA en ce qui concerne la sécurité des déploiements. Il est très compliqué et la marche à suivre pour procéder à la signature en temps constant n'est pas claire. Le SQISign peut s'avérer utile pour les applications de niche, mais de gros efforts doivent être faits sur le temps de vérification si l'on vise l'adoption généralisée, même si le résultat implique l'utilisation d'une signature de plus grande taille. Des progrès considérables ont été réalisés ces dernières années en termes de temps de vérification, de simplification de l'algorithme et de sécurité du déploiement pour (les variantes de) SQISign. Nous ne sommes pas encore au bout de nos peines, mais l'écart s'est fortement réduit. Bien plus que ce à quoi nous nous attendions. Si le rythme des améliorations se maintient, un futur SQISign pourrait bien s'avérer viable pour le TLS.

L'un de ses prétendants les plus prudents est le mécanisme UOV (Unbalanced Oil and Vinegar, mélange non-équilibré d'huile et de vinaigre). Cet ancien mécanisme multivarié utilise une clé publique de grande taille (66,5 Ko), mais de petites signatures (96 octets). De nombreuses tentatives de structuration des clés publiques UOV ont été initiées au fil des décennies afin d'obtenir un meilleur équilibre entre la taille de la clé publique et celle de la signature. Malheureusement, bon nombre de ces mécanismes prétendument multivariés et structurés (comme Rainbow et GeMMS) ont été invalidés de manière spectaculaire « en un week-end, avec un simple ordinateur portable ». Le MAYO et le SNOVA (que nous examinerons dans un instant) sont les dernières tentatives en termes de mécanismes multivariés et structurés. En soi, l'UOV s'en est sorti globalement indemne. Fait surprenant, Lars Ran a découvert une toute nouvelle attaque « wedges » (une attaque impliquant le produit extérieur) contre l'UOV en 2025. Si cette attaque n'affecte pas énormément l'UOV en définitive, les mécanismes SNOVA et MAYO sont plus durement touchés quant à eux. Le point qui rend cette attaque si remarquable, c'est qu'elle repose sur une idée relativement simple. Il est même surprenant qu'elle n'ait pas été découverte plus tôt. Pour en revenir aux performances, si nous associons l'UOV pour la racine et les SCT au ML-DSA-44 pour les autres signatures, nous n'obtenons qu'une quantité de données de 10 Ko, soit un résultat proche du FN-DSA-512.

Passons maintenant à l'événement que nous attendons tous :

Si l'on examine le classement actuel, le MAYO et le SNOVA (plus particulièrement) affichent d'excellentes performances. Le SNOVA et le MAYO étaient plus proches l'année dernière en termes de performances, mais leurs résultats ont fortement divergé depuis.

Le MAYO a été conçu par le cryptographe qui a invalidé le Rainbow. La sécurité de ce mécanisme nécessite une analyse rigoureuse, du fait de sa nature multivariée et structurée, mais son utilité demeure particulièrement séduisante (en partant du principe qu'il ne sera pas délégitimisé dans un avenir plus ou moins proche). Le MAYO permet un compromis précis entre la taille de la signature et celle de la clé publique. Pour rester simple, les auteurs en ont proposé deux variantes concrètes lors de sa soumission : le MAYO_one, équilibré du point de vue de la taille de la signature (454 octets) et de la clé publique (1,4 Ko), et le MAYO_two, qui présente une signature de 216 octets, tout en conservant une clé publique de taille gérable, avec 4,3 Ko. Le temps de vérification est excellent, tandis que le temps de signature se montre légèrement plus lent que pour l'ECDSA, mais bien meilleur qu'avec le RSA. En associant les deux variantes de manière évidente, nous ne totalisons que 4,3 Ko. Ces chiffres se révèlent légèrement supérieurs à ceux de l'année dernière, car le MAYO a de nouveau légèrement ajusté ses paramètres afin de tenir compte des attaques récemment identifiées.

Le SNOVA a été plus sévèrement touché par les attaques que le MAYO pendant le concours. La réponse de ses auteurs s'est montrée plus énergique : plutôt que de se contenter d'ajuster les paramètres pour s'adapter à la situation, l'équipe a également apporté des modifications importantes aux rouages internes du mécanisme afin de contrer les attaques et d'améliorer les performances par la même occasion. En associant le SNOVA_(37,17,16,2) et le SNOVA_(24,5,23,4) de la manière la plus évidente, nous ne totalisons une augmentation de volume que de 2,1 Ko seulement.

Un antagonisme est ainsi en train de se dessiner entre le SNOVA, risqué mais de taille bien plus petite, et le MAYO, prudent mais plus lent. Sur un plan d'ensemble, ces mécanismes proposent tous deux des performances très louables et se révèlent tous deux trop risqués pour faire l'objet d'un déploiement à l'heure actuelle. À titre d'exemple, la nouvelle attaque « wedges » identifiée par Ran montre que le domaine de la cryptanalyse multivariée nous réserve encore bien des surprises. De même, cette approche nécessite davantage d'attention et de temps. Il est trop tôt pour désigner un vainqueur entre le SNOVA et le MAYO : laissons-les continuer à s'affronter encore un peu. Il est peu probable que ces mécanismes soient normalisés avant 2029, quand bien même ils s'avéraient finalement sécurisés. Nous ne pouvons par conséquent pas nous reposer sur ces deniers pour la migration initiale vers l'authentification post-quantique.

En y repensant avec un peu de recul, ce chiffre de 15 ko pour le ML-DSA-44 est-il vraiment aussi mauvais ?

En moyenne, près de 18 millions de connexions TLS sont établies avec Cloudflare chaque seconde. La mise à niveau de chacune d'elles vers le ML-DSA nécessiterait 2,1 Tb/s, soit 0,5 % de notre capacité réseau totale à l'heure actuelle. Aucun problème pour le moment donc. Toute la question consiste à savoir de quelle manière ces octets supplémentaires affectent les performances.

Le passage au ML-DSA-44 demanderait 15 Ko supplémentaires. C'est beaucoup par rapport au volume d'une négociation typique d'aujourd'hui, mais peu comparé au JavaScript et aux images diffusées sur de nombreuses pages web. L'idée à retenir ici est que le changement que nous devons apporter affectera toutes les connexions TLS, qu'elle soit établie pour faire fonctionner un site web exagérément lesté ou procéder à un appel d'API prioritaire, pour lequel le temps de réponse constitue une notion critique. De même, l'idée n'est pas que nous allons devoir attendre un peu plus longtemps. Ce volume de données supplémentaire peut faire toute la différence entre le chargement d'une page et l'expiration du délai de connexion en cas de réception irrégulière du fait d'un réseau mobile sporadique. (Petite info en aparté, tant que nous sommes en train de parler de lest excessif : beaucoup d'applications procèdent à un nombre étonnamment élevé de négociations TLS).

Tout comme pour les mécanismes d'accord de clé, nous ne nous soucions pas uniquement des performances : nous souhaitons également que la connexion puisse être établie en premier lieu. En 2021, nous avons conduit une expérience visant à agrandir artificiellement la chaîne de certificats afin de simuler l'utilisation de certificats post-quantiques de plus grande taille. Nous en résumons le résultat ici. L'un des enseignements que nous devons retirer de cette expérience, c'est que certains clients ou boîtiers intermédiaires n'apprécient pas les chaînes de certificats d'une taille supérieure à 10 Ko. Ce point s'avère problématique pour une stratégie de migration à certificat unique. Selon cette approche, le serveur installe un unique certificat traditionnel contenant un certificat post-quantique distinct au sein d'une extension définie comme non critique. Un client qui ne prendrait pas en charge les certificats post-quantiques ignorera l'extension. Selon cette approche, toujours, l'installation d'un unique certificat entraînera immédiatement l'émergence de problèmes de compatibilité pour tous les clients. Cette solution est donc vouée à l'échec. Nous constatons également une forte baisse des performances à partir de 10 Ko du fait de la fenêtre de congestion initiale.

Un volume de 9 Ko serait-il trop élevé également ? Le temps nécessaire à la négociation TLS serait ralenti d'environ 15 %. Nous avons estimé que cette deuxième solution était envisageable, mais loin d'être parfaite. En effet, ce type de ralentissement est perceptible et pourrait inciter les entreprises à repousser le déploiement de certificats post-quantiques jusqu'à ce qu'il soit tard pour y procéder en toute sécurité.

Chrome est plus prudent et s'est fixé un objectif de 10 % pour la régression maximale du temps nécessaire à la négociation TLS. Ses équipes rapportent que le déploiement de l'accord de clé post-quantique a déjà entraîné un ralentissement de 4 % du temps nécessaire à la négociation TLS, en raison des 1,1 Ko de données supplémentaires à transmettre du serveur vers le client et des 1,2 Ko à transmettre du client vers le serveur. Proportionnellement, ce ralentissement se révèle plus important que les 15 % que nous avons observés pour les 9 Ko. Ce phénomène pourrait toutefois s'expliquer par le fait que le débit montant (importation) est plus lent que le débit descendant (téléchargement). 

L'accent mis sur le temps nécessaire à la négociation TLS a rencontré certaines résistances. L'un des arguments avancés est que la possibilité de reprendre une session élimine la nécessité de renvoyer les certificats. Deuxième argument : la quantité de données nécessaires pour naviguer sur un site web typique dépasse de loin les octets supplémentaires requis par les certificats post-quantiques. Cette publication de 2024, dans laquelle des chercheurs d'Amazon ont simulé l'impact des certificats post-quantiques de grande taille sur les connexions TLS présentant un volume élevé de données, en constitue un bon exemple. Ils soutiennent que plusieurs requêtes et des centaines de kilo-octets font l'objet d'un transfert lors d'une connexion habituelle et que le ralentissement de la négociation TLS apparaît dès lors comme marginal.

La reprise de session et la transmission de centaines de kilo-octets au cours d'une connexion sont-elles néanmoins des opérations typiques ? Nous souhaiterions vous faire part de ce que nous observons. À cet effet, nous nous concentrerons sur les connexions QUIC, qui sont généralement initiées par des navigateurs ou des clients apparentés à des navigateurs. 27 % des connexions QUIC établies avec Cloudflare et sur lesquelles transite au moins une requête HTTP sont des reprises. C'est-à-dire qu'elles réutilisent les informations de clé d'une connexion TLS précédente afin d'éviter de devoir transmettre à nouveau les certificats. Le nombre médian d'octets transférés d'un serveur vers un client sur une reprise de connexion QUIC est de 4,4 Ko, tandis que la moyenne est de 259 Ko. Le chiffre médian est de 8,1 ko et la moyenne de 583 ko pour les connexions qui ne sont pas des reprises. La forte différence entre le chiffre médian et la moyenne indique que cette dernière est faussée par une faible proportion de connexions très consommatrices de données. En réalité, seuls 15,5 % de l'ensemble des connexions QUIC transfèrent plus que 100 Ko de données.

La chaîne de certificats médiane actuelle (avec compression) est de 3,2 Ko. Ce chiffre signifie que près de 40 % des données transférées du serveur vers le client sur plus de la moitié des connexions QUIC non reprises sont uniquement réservées aux certificats. Or, ce problème ne fait qu'empirer avec les algorithmes post-quantiques. Pour la majeure partie des connexions QUIC, l'utilisation du ML-DSA-44 en remplacement des mécanismes de signature classiques doublerait (au minimum) le nombre d'octets transmis sur l'ensemble du cycle de vie de la connexion.

Le fait que la grande majorité des données transférées au cours d'une connexion typique soient uniquement destinées aux certificats post-quantiques constitue assurément un problème. Il ne s'agit toutefois que de l'arbre qui cache la forêt par rapport à ce qui est réellement important : l'impact sur les indicateurs pertinents pour l'utilisateur final, comme l'expérience de navigation (p. ex. le Largest Contentful Paint ou LCP, c'est-à-dire le temps nécessaire au rendu du plus grand élément de contenu visible) et la quantité de données que ces certificats consomment sur le forfait de données mensuel de l'utilisateur. Nous allons poursuivre nos investigations afin de mieux comprendre les répercussions de cette situation.

Le chemin à suivre pour procéder à la migration de l'Internet vers l'authentification post-quantique est beaucoup moins clair que pour l'accord de clé. Nous nous attendons à ce que la grande majorité des entreprises n'active pas l'authentification post-quantique tant que nous ne parviendrons pas à améliorer sensiblement les performances de manière à ce qu'elles soient similaires à celles des mécanismes d'authentification utilisés d'aujourd'hui. Le fait de reporter l'activation de l'authentification post-quantique jusqu'à l'approche du Q-Day comporte un risque réel : ne pas être en mesure de déceler les problèmes avant qu'il ne soit trop tard pour les résoudre. Nous devons donc rendre l'authentification post-quantique suffisamment performante pour permettre son activation par défaut. Il s'agit là d'une priorité des plus essentielles.

Nous sommes actuellement en train d'explorer différentes idées pour réduire le nombre de signatures, que nous vous présentons ici par ordre d'ambition croissant : l'abandon des certificats intermédiaires, le KEMTLS et les certificats Merkle Tree. Nous avons étudié ces aspects en détail l'année dernière. Nous avons justement réalisé le plus de progrès sur les derniers de cette liste : les certificats Merkle Tree (MTC, Merkle Tree Certificates). Selon cette proposition (et dans le cas le plus fréquent), toutes les signatures, à l'exception de la signature de négociation, sont remplacées par une courte preuve de moins de 800 octets, basée sur l'arbre de Merkle. Cette approche pourrait bien permettre la mise en place d'un mécanisme d'authentification post-quantique qui se révélerait en fait plus rapide que les certificats traditionnels utilisés actuellement ! Nous allons procéder à des essais de manière conjointe avec Chrome d'ici la fin de l'année. Vous trouverez toutes les informations à ce sujet dans cet article de blog.

L'article présent, malgré sa longueur, n'a fait qu'effleurer la question de la migration TLS. De même, nous n'avons pas abordé le protocole TLS de manière exhaustive, car nous n'avons pas évoqué l'Encrypted ClientHello (nous ne l'avons cependant pas oublié). En dépit de son importance, le TLS n'est pas le seul protocole essentiel à la sécurité d'Internet. Nous souhaitons ainsi mentionner brièvement quelques autres difficultés dans les lignes qui suivent, mais nous ne pouvons entrer dans les détails. Le DNSSEC, responsable de la sécurisation de la résolution des noms de domaine, constitue l'une de ces problématiques particulières.

Si les accords de clé et les signatures sont effectivement les primitives cryptographiques les plus utilisées, nous avons assisté ces dernières années à l'adoption de modes de chiffrement plus ésotériques conçus pour servir des scénarios d'utilisation plus avancés, comme les jetons non liables avec le Privacy Pass/PAT, les identifiants anonymes et le chiffrement basé sur les attributs pour n'en citer que quelques-uns. Aucune alternative post-quantique pratique connue n'existe encore pour la plupart de ces mécanismes cryptographiques avancés. À notre grande joie, des avancées considérables ont toutefois été réalisées dans le domaine des identifiants anonymes post-quantiques.

En résumé, deux axes de migration post-quantique sont principalement à surveiller : les mécanismes d'accord de clé et les certificats.

Nous vous recommandons de passer à l'accord de clé post-quantique pour contrer les attaques de type « stocker maintenant, déchiffrer plus tard ». Cette opération ne nécessite qu'une simple mise à jour logicielle des deux côtés. Dans un contexte d'adoption rapide du X25519MLKEM768 au sein des logiciels et des services (nous tenons une liste ici), cette simplicité implique que vous pourriez déjà être protégé contre l'approche « stocker maintenant, déchiffrer plus tard » ! Vous pouvez également vous rendre sur Cloudflare Radar pour vérifier si votre navigateur prend en charge le X25519MLKEM768. Si vous utilisez Firefox, une extension existe pour contrôler la prise en charge des sites web sur lesquels vous vous rendez. Vous pouvez vérifier si votre site web prend en charge ce mécanisme ici et utiliser Wireshark pour vérifier cette prise en charge sur vos connexions.

Il ne s'agit là que des vérifications ponctuelles. Pour vous lancer dans un processus de migration approprié, vous devrez déterminer à quel endroit utiliser le chiffrement. C'est là un défi de taille, car la plupart des entreprises ont du mal à suivre l'ensemble des logiciels, des services et des fournisseurs externes qu'elles utilisent en premier lieu. Certains systèmes seront plus difficiles à mettre à niveau ou disposeront de dépendances externes, mais l'opération devrait globalement s'avérer simple. Pour tout dire, dans de nombreux cas, vous consacrerez beaucoup de temps à découvrir que la migration a déjà été effectuée.

Comme l'essentiel du travail consiste à déterminer ce qui reste à faire, il est peut-être tentant de diviser cette tâche en commençant par cette première étape : la production d'un inventaire détaillé (que l'on appelle également la nomenclature cryptographique, ou CBOM pour Cryptographic Bill Of Materials). Ne laissez pas cet inventaire devenir un objectif en soi : veillez à bien rester concentrés sur l'essentiel. Dans la plupart des cas, l'opération sera des plus simples : si vous avez déterminé la procédure de migration dans un cas précis, n'attendez pas et ne changez pas de contexte, procédez directement à la migration. Le processus n'en sera pas pour autant rapide : c'est un marathon, pas un sprint, mais vous seriez surpris de voir tout le chemin que vous pouvez parcourir en vous lançant dès maintenant.

Passons aux certificats. À l'heure où nous écrivons ces lignes, en octobre 2025, les normes finales régissant les certificats post-quantiques ne sont pas encore définies. Espérons que cette finalisation ne demande pas trop de temps. Il vous reste néanmoins des quantités de choses à faire dès aujourd'hui pour vous préparer au déploiement des certificats post-quantiques afin de vous assurer que vous ne le regretterez en aucun point. Maintenir vos logiciels à jour. Automatiser l'émission de certificats. Vous assurer d'être en mesure d'installer plusieurs certificats.

Aucune raison d'attendre si l'ossification des protocoles vous inquiète : les normes post-quantiques finales ne seront pas très différentes de leurs versions de projet. Vous pouvez commencer à tester les versions préliminaires dès aujourd'hui (ou procéder à des tests à l'aide de faux certificats de grande taille).

Le processus de migration post-quantique est tout à fait unique. En général, l'invalidation d'une méthode de chiffrement arrive soit soudainement, soit de manière progressive, ce qui permet d'ignorer facilement la mauvaise nouvelle pendant un certain temps. Dans les deux cas, les migrations finissent par être précipitées. Concernant la menace quantique, nous savons avec certitude que nous devrons remplacer une grande partie de nos techniques de chiffrement, mais nous avons également un peu de temps devant nous. Plutôt qu'une corvée, nous vous invitons donc à y voir une opportunité : celle d'assurer la maintenance de nombreux systèmes rarement utilisés. C'est l'occasion rêvée de repenser vos choix passés, au lieu de vous contenter de déployer des correctifs à chaud.

Du moins, si vous vous lancez dans l'aventure dès aujourd'hui. Bonne chance pour votre migration et n'hésitez pas à nous contacter sur ask-research@cloudflare.com si vous rencontrez des problèmes.

Chaque année, nous consacrons la Semaine anniversaire au lancement de produits et de fonctionnalités dont nous pensons qu'Internet a besoin à ce moment précis et dans un avenir proche. Les Semaines anniversaire précédentes ont été l'occasion du lancement de la passerelle IPv6 en 2011, de Universal SSL en 2014, de Cloudflare Workers et de la protection illimitée contre les attaques DDoS en 2017, de Cloudflare Radar en 2020, du stockage d'objets R2 sans frais de trafic sortant en 2021 et des mises à niveau post-quantiques pour Cloudflare Tunnel en 2022, Workers AI et Encrypted Client Hello en 2023. Et ce ne sont que quelques exemples de lancements.

Les thèmes abordés cette année ont principalement porté sur la préparation d'Internet à un nouveau modèle de monétisation qui favorise la publication de contenus de qualité, crée davantage d'opportunités pour développer une communauté tant au sein de Cloudflare qu'à l'extérieur, et englobe des missions pérennes telles que la mise à disposition de fonctionnalités supplémentaires pour tous et l'amélioration constante de la vitesse et de la sécurité de notre offre.

Nous avons commercialisé beaucoup de nouveautés cette année. Si vous êtes passés à côté des dizaines d'articles de blog qui les présentaient, voici un aperçu de tout ce que nous avons annoncé pendant la Semaine anniversaire 2025. 

Lundi 22 septembre

Mardi 23 septembre

Mercredi 24 septembre

Jeudi 25 septembre

Vendredi 23 septembre

Contribuer à bâtir un Internet meilleur ne se limite pas à la technologie. À l'instar des annonces concernant les stagiaires ou la collaboration dans nos bureaux, la communauté des personnes qui contribuent à construire un Internet meilleur est essentielle pour son avenir. Cette semaine, nous avons lancé notre ensemble d'initiatives le plus ambitieux à ce jour pour soutenir les bâtisseurs, les fondateurs et les étudiants qui façonnent l'avenir.

Pour les fondateurs et les start-ups, nous sommes ravis d'accueillir la 6e promotion du Workers Launchpad, notre programme d'accélération qui offre aux entreprises en phase de démarrage les ressources nécessaires pour se développer. Toutefois, nous allons encore plus loin. Nous ouvrons nos portes, littéralement, en lançant de nouveaux hubs physiques pour les start-ups dans nos bureaux de San Francisco, Austin, Londres et Lisbonne. Ces espaces offriront un accès à du mentorat, à des ressources et à une communauté d'autres créateurs.

Nous investissons également dans la nouvelle génération de talents. Nous avons annoncé l'accès gratuit à la plateforme de développement de Cloudflare pour tous les étudiants, leur offrant par là même les outils pour apprendre et expérimenter sans limites. Pour faciliter la transition de la salle de classe à l'industrie, nous avons également annoncé notre objectif de recruter 1 111 stagiaires en 2026, notre plus grand engagement à ce jour pour encourager les futurs leaders technologiques.

Et parce qu'un Internet meilleur concerne tout le monde, nous étendons notre soutien aux organisations à but non lucratif et d'intérêt public, en leur offrant un accès gratuit à nos outils de développement de qualité professionnelle, afin qu'elles puissent se concentrer sur leurs missions.

Que vous soyez un fondateur avec une grande idée, un étudiant qui commence à peine, ou une équipe travaillant pour une cause en laquelle vous croyez, nous voulons vous aider à réussir.

Merci à nos clients, notre communauté et aux millions de développeurs qui nous font confiance pour les aider à construire, sécuriser et accélérer l'Internet. Votre curiosité et vos retours stimulent notre innovation.

Ces 15 années ont été incroyables. Et, encore une fois, ce n'est qu'un début !