Ces derniers mois, nous avons testé toute une gamme de LLM (Large Language Models, grands modèles linguistiques) orientés sécurité sur notre propre infrastructure. Ces LLMs nous aident à identifier les vulnérabilités potentiellement présentes au sein de nos propres systèmes afin que nous puissions les corriger, tout en nous révélant également ce que les acteurs malveillants pourront accomplir avec les derniers modèles.

Aucun de ces LLM n'a attiré plus d'attention que Mythos Preview d'Anthropic. Il y a quelques semaines, nous avons été invités à utiliser Mythos Preview dans le cadre du projet Glasswing. Nous l'avons bien vite fait pointer vers plus de cinquante de nos propres référentiels afin de voir ce qu'il y trouverait et de découvrir son fonctionnement.

Cet article a pour but de vous faire part de nos observations, des tâches que les modèles ont bien réalisées et de celles qu'elles n'ont pas correctement achevées, mais aussi des évolutions nécessaires de l'architecture et des processus à mettre en place autour de ces modèles pour qu'ils puissent être utilisés à plus grande échelle.

Le modèle Mythos Preview constitue une véritable avancée. Il convient de le dire clairement avant d'aborder quoi que ce soit d'autre. Nous exécutons des modèles sur notre code depuis un certain temps déjà et le passage de ce qui était possible avec les anciens modèles généralistes aux tâches effectuées aujourd'hui par Mythos Preview ne découle pas uniquement de l'affinage des modèles qui l'ont précédé.

C'est un type d'outil différent, qui effectue un travail différent. La comparaison directe avec les modèles antérieurs est donc particulièrement difficile. Plutôt que de tenter de comparer Mythos Preview aux modèles généralistes à la pointe du marché, il est plus utile de décrire ce qu'il peut réellement faire, de même que deux caractéristiques qui se sont distinguées dans les travaux que nous avons réalisés avec Mythos Preview :

• Construction de chaîne d'exploitation : une attaque réelle utilise rarement un seul bug. Elle enchaîne plusieurs petites primitives d'attaque afin de créer un exploit fonctionnel. Elle peut, par exemple, transformer un bug d'utilisation après libération en une primitive de lecture et d'écriture arbitraire, détourner le flux de contrôle et utiliser des chaînes de programmation orientée retour (ROP, Return-Oriented Programming) pour prendre le contrôle total d'un système. Mythos Preview peut prendre plusieurs de ces primitives et raisonner sur la manière de les combiner en une preuve fonctionnelle. Le raisonnement présenté tout au long du processus ressemble au travail d'un chercheur senior plutôt qu'à la sortie d'un scanner automatisé.

• Génération de preuves : le fait d'identifier un bug et de prouver qu'il est exploitable constitue deux éléments différents et Mythos Preview peut effectuer les deux tâches. Il rédige du code susceptible de déclencher le bug suspecté, compile ce code au sein d'un environnement d'essai et l'exécute. Si le programme produit ce que le modèle attendait, il en a désormais la preuve. S'il ne fonctionne pas, le modèle lit l'échec, ajuste son hypothèse et réessaie. Cette boucle est aussi importante que les bugs qu'elle détecte, car un défaut suspecté sans preuve concrète demeure une spéculation. Or, Mythos Preview comble cette lacune de manière autonome.

Certains des aspects que nous décrivons ci-dessus ne sont pas entièrement uniques à Mythos Preview. Les autres modèles de pointe que nous avons soumis au même outil ont identifié un nombre raisonnable des mêmes bugs sous-jacents et, dans certains cas, ont également progressé davantage que prévu sur le plan du raisonnement. Ils ne se sont toutefois pas comportés de manière optimum à l'étape de l'assemblage des pièces du puzzle. Un modèle pouvait ainsi identifier un bug intéressant, rédiger une description réfléchie de son importance, puis s'arrêter, en laissant la chaîne réelle inachevée et la question de l'exploitabilité ouverte. Ce qui diffère avec un LLM tel que Mythos Preview, c'est que ce modèle peut désormais prendre ces bugs de faible gravité (qui resteraient traditionnellement invisibles dans un backlog) et les enchaîner de manière à produire un exploit unique de plus grande sévérité. 

Le modèle Mythos Preview fourni par Anthropic dans le cadre du projet Glasswing ne disposait pas des mesures de sécurité supplémentaires présentes dans les modèles en disponibilité générale (comme Opus 4.7 ou GPT-5.5).

Le modèle rejetait toutefois certaines requêtes de manière organique (un peu comme les cyber-capacités qui le rendent utile pour la chasse aux vulnérabilités). Le modèle dispose de ses propres garde-fous émergents qui provoquent parfois un rejet des requêtes légitimes de recherche de la sécurité. Or, comme nous l'avons constaté, ces refus organiques ne sont pas cohérents. La même tâche, cadrée différemment ou présentée dans un autre contexte, pouvait produire des résultats complètement différents, comme illustré dans les exemples ci-dessous.

^{Exemple de Mythos Preview rejetant la création d'une validation de principe fonctionnelle} 

Le modèle a, par exemple, d'abord refusé d'accomplir une recherche de vulnérabilités pour un projet, puis accepté d'effectuer cette même recherche sur le même code après une modification de l'environnement du projet sans lien avec ce dernier. Rien dans le code analysé n'avait changé. Dans un autre cas, le modèle a trouvé et confirmé plusieurs bugs de mémoire graves au sein d'une base de code, puis refusé de rédiger une démonstration de cet exploit. La même requête, formulée différemment, a abouti sur un résultat différent. La même requête peut ainsi produire des résultats différents lors de différentes exécutions du fait de la nature probabiliste du modèle. Des tâches sémantiquement équivalentes peuvent produire des résultats opposés selon la manière et le moment où elles sont présentées au modèle.

Ce constat revêt une importance particulière, car si les refus organiques/garde-fous du modèle sont bien réels, ils ne sont toutefois pas suffisamment cohérents pour servir de limite de sécurité complète à eux seuls. C'est précisément pour cette raison que n'importe quel modèle à la pointe du marché du cyber qui sera proposé en disponibilité générale à l'avenir devra inclure des garde-fous supplémentaires, en plus de ce comportement de base, afin de convenir à une utilisation plus large en dehors d'un contexte de recherche contrôlé, comme le projet Glasswing.

L'un des éléments les plus difficiles de la hiérarchisation des vulnérabilités de la sécurité consiste à décider quels bugs sont réels, lesquels sont exploitables et lesquels nécessitent une correction immédiate. Il s'agissait déjà d'un problème difficile à résoudre dans le monde pré-IA. Les outils d'analyse des vulnérabilités assistés par IA et le code généré par AI ont aggravé la situation et Cloudflare a ainsi défini plusieurs étapes de post-validation pour y faire face.

Deux facteurs dominent le niveau de bruit :

• Langage de programmation : le C et le C++ vous donnent le contrôle direct de la mémoire et, grâce à cette fonctionnalité, des classes de bugs (attaques par débordement de tampon, lectures et écritures hors limites) que les langages sécurisés du point de vue de la mémoire (ou « memory-safe », comme Rust) éliminent lors de la phase de compilation. Nous avons systématiquement constaté davantage de faux positifs provenant de projets rédigés dans des langages non sécurisés pour la mémoire.

• Biais du modèle : un bon chercheur humain vous indiquera ce qu'il a découvert et avec quel degré de confiance. Pas les modèles. Un modèle auquel vous demanderez de trouver des bugs en trouvera, que le code en contienne ou non. Les constatations reviennent dès lors accompagnées de mots comme « possiblement », « potentiellement » ou « en théorie ». Or, ces observations prudentes surpassent largement les constatations bien établies. S'il s'agit là d'un biais raisonnable pour un outil d'exploration, il s'avérerait désastreux pour une file d'attente de triage, où chaque constatation spéculative consomme de l'attention humaine et des jetons pour être rejetée. Or, ce coût est multiplié par les milliers de constatations.

Mythos Preview représente une nette amélioration à ce niveau, notamment dans sa capacité à enchaîner des primitives, en combinant plusieurs vulnérabilités pour former une validation de principe (PoC, Proof of Concept) fonctionnelle plutôt que de les signaler de manière isolée. Une constatation accompagnée d'une PoC est une constatation sur laquelle vous pouvez agir et qui implique beaucoup moins de temps passé à se demander « Cette constatation est-elle même réelle ? »

Nos outils sont délibérément réglés pour sur-signaler les problèmes afin de nous permettre d'en voir davantage (et de moins en manquer). Or, cette approche entraîne beaucoup plus de bruit. La qualité des résultats de Mythos Preview se révèle toutefois nettement supérieure lors de la phase de triage : moins de constatations floues, des étapes de reproduction plus claires et moins de travail pour prendre une décision de correction ou de rejet.

Lorsque nous avons lancé notre processus de recherche de vulnérabilités assisté par IA l'année dernière, notre instinct était des plus évidents : faire pointer un agent de codage générique vers un référentiel arbitraire et lui demander d'identifier des vulnérabilités. Cette approche fonctionne, dans le sens où le modèle produira des résultats, mais elle n'est pas efficace pour assurer une couverture significative d'une véritable base de code et identifier des résultats de valeur. Cet état de fait s'explique par deux raisons principales :

• Contexte : les agents de codage sont optimisés pour exécuter un flux de travail précis (p. ex. développer une fonctionnalité, corriger un bug ou rédiger un remaniement). Ils ingèrent une grande quantité de code source, tiennent une seule hypothèse à la fois et itèrent sur celle-ci. Cette structure se révèle parfaitement inadéquate en ce qui concerne la recherche de vulnérabilités, par nature étroite et parallèle. Un chercheur humain choisit un aspect spécifique à examiner et l'étudie en profondeur. Cet élément unique peut être une fonctionnalité complexe, des transitions entre différentes limites de sécurité ou une classe de vulnérabilités spécifique, comme les injections de commandes, au sein desquelles les entrées d'un acteur malveillant sont exécutées sous forme de commande shell. Ils réitèrent ensuite ce processus pour une autre fonctionnalité, une limite de sécurité ou une classe de vulnérabilité, plusieurs milliers de fois sur l'ensemble du code. Une session d'agent unique (même de sous-agents) lancée sur un référentiel de cent mille lignes peut couvrir peut-être un dixième de pour cent de la surface de manière utile avant que la fenêtre de contexte du modèle ne se remplisse et que la compaction n'intervienne, potentiellement en éliminant des constatations antérieures qui se seraient révélées importantes.

• Débit : un agent monoflux effectue une tâche à la fois, mais les bases de code réelles nécessitent de nombreuses hypothèses sur de nombreux composants à la fois, avec la possibilité de se déployer davantage lorsqu'un élément intéressant est identifié. Vous pouvez pousser un agent unique plus loin, mais à un certain point, vous cessez d'être limité par le modèle et commencez à être limité par la nature même de l'interaction. L'utilisation du modèle approprié directement au sein d'un agent de codage s'avère adéquate pour une investigation manuelle lorsqu'un chercheur a déjà une piste et souhaite un second avis. Il s'agit toutefois d'un mauvais outil pour atteindre une couverture élevée. Une fois ce fait accepté, nous avons cessé d'essayer de faire accomplir à Mythos Preview une tâche qui ne lui convenait pas et avons plutôt commencé à bâtir l'outil autour de celui-ci.

Quatre leçons ont émergé de la gestion du travail à grande échelle et chacune a souligné la nécessité d'un cadre de gestion de l'exécution à l'échelle mondiale :

• Un champ d'application restreint produit de meilleures constatations : le fait de demander à un modèle de « trouver les vulnérabilités dans ce référentiel » entraîne son errance. Lui demander : « Recherche une injection de commande au sein de cette fonction spécifique, avec cette limite de confiance par-dessus. Voici le document d'architecture et la couverture précédente de cette zone » rapproche bien plus ce modèle du travail réel d'un chercheur.

• L'examen contradictoire réduit le bruit : l'ajout d'un second agent entre la constatation initiale et la file d'attente (avec une invite différente, un modèle différent et aucune capacité à générer ses propres constatations) capte une grande quantité du bruit à côté duquel le premier agent passerait s'il ne contrôlait que son propre travail. Le fait de mettre deux agents en désaccord délibéré s'avère bien plus efficace que de simplement demander à un agent de se montrer minutieux.

• La division de la chaîne entre les agents produit un meilleur raisonnement : les questions « Ce code est-il défectueux ? » et « Un acteur malveillant peut-il réellement atteindre ce bug depuis l'extérieur du système ? » sont toutes deux différentes et le modèle se révèle plus efficace à répondre à chacune d'elles lorsqu'elles sont posées de manière distincte, car chaque question est mieux ciblée que leur version combinée.

• Les tâches étroites en parallèle surpassent un agent exhaustif : la couverture s'améliore lorsque de nombreux agents travaillent sur des questions bien définies et que nous dédupliquons ensuite les résultats plutôt que de demander à un seul agent de se montrer exhaustif.

Chacune de ces observations porte sur le comportement du modèle et, ensemble, décrit un aspect qui ne constitue plus une interface de discussion. Il s'agit-là d'un outil qui vous aidera à obtenir les résultats finaux. Les premières étapes de la création d'un outil sont simples, car vous pouvez demander à votre modèle de vous aider (ce que nous avons d'ailleurs fait). Nous avons utilisé Mythos Preview pour développer, adapter et améliorer nos outils d'origine afin de tirer pleinement parti de ses points forts. L'exemple ci-dessous décrit ce à quoi ressemble ce type d'outil en pratique.

Voici à quoi ressemble notre outil d'identification des vulnérabilités, étape par étape. Nous nous en sommes servis pour analyser le code en direct sur l'ensemble de notre environnement d'exécution, du chemin de données à l'edge, de notre pile de protocoles, de notre interface et des projets open source dont nous dépendons.

Étape	Ses actions	Son importance
Reconnaissance	Un agent lit le référentiel de haut en bas, se déploie aux sous-agents responsables de chaque sous-système et produit un document architectural couvrant les commandes de construction, les limites de confiance, les points d'entrée et la surface d'attaque probable. Il génère également la file d'attente initiale des tâches pour l'étape suivante.	Cette étape assure un contexte partagé à chaque agent situé en aval. Elle résout également le problème d'errance.
Traque	Chaque tâche se présente comme une classe d'attaque associée à un indice de portée. Les traqueurs (c.-à-d. les agents qui recherchent effectivement les bugs) fonctionnent de manière simultanée, généralement une cinquantaine à la fois, chacun se déployant vers une poignée de sous-agents d'exploration. Chaque traqueur a accès à des outils permettant de compiler et d'exécuter le code d'une validation de principe au sein d'un répertoire temporaire par tâche.	La plus grosse partie du travail s'effectue ici. Déploiement de nombreuses tâches étroites en parallèle, pas d'un agent exhaustif.
Validation	Un agent indépendant relit le code et tente de réfuter la constatation initiale. Il utilise une invite différente et n'a pas la capacité de produire de nouvelles constatations par lui-même.	Cette étape capture une fraction significative du bruit que le traqueur ne remarquerait pas en révisant son propre travail.
Comblement des lacunes	Les traqueurs signalent les zones qu'ils ont touchées, mais qu'ils n'ont pas complètement couvertes. Ces secteurs sont replacés en file d'attente pour un autre passage.	Cette étape contrebalance la tendance du modèle à se diriger vers les classes d'attaque avec lesquelles il a déjà obtenu des résultats.
Déduplication	Les constatations qui partagent la même cause racine entraînent leur réduction sous un seul enregistrement.	L'analyse des variantes est une fonctionnalité, pas un moyen de gonfler la file d'attente par des doublons.
Traçage	Pour chaque constatation confirmée au sein d'une bibliothèque partagée, un agent traceur se déploie (une instance par référentiel consommateur), utilise un index de symboles inter-référentiels et détermine si une entrée contrôlée par un acteur malveillant peut effectivement entrer en contact avec le bug depuis l'extérieur du système.	Cette étape transforme la constatation « Une faille est présente » en « Une vulnérabilité est accessible ». C'est l'étape qui compte le plus.
Retour d'expérience	Les traces atteignables deviennent de nouvelles tâches de traque au sein des référentiels consommateurs dans lesquels le bug est effectivement exposé.	Cette étape ferme la boucle. Le pipeline s'améliore au fur et à mesure de son exécution.
Rapport	Un agent rédige un rapport structuré selon un schéma prédéfini, corrige toute erreur de validation selon ce même schéma et envoie le rapport à une API d'ingestion.	La sortie se présente sous la forme de données interrogeables, pas d'un texte en prose libre.

La réaction la plus forte à Mythos Preview des autres responsables de la sécurité portait sur la vitesse : analyser plus vite, appliquer les correctifs plus rapidement, compresser le cycle de réponse. Plus d'une équipe avec laquelle nous avons parlé fonctionne désormais sous un SLA de deux heures entre la publication d'une CVE et la mise en production du correctif. La réponse instinctive est compréhensible : lorsque la chronologie de l'acteur malveillant se raccourcit, la chronologie de l'entreprise en défense doit également se raccourcir en conséquence. Il ne suffira pas de se montrer plus rapide et nous pensons que de nombreuses équipes sont sur le point de consacrer beaucoup de temps, d'efforts et d'argent à comprendre ce fait à leurs dépens.

L'accélération du déploiement des correctifs ne modifie pas la structure du pipeline qui les produit. Si les tests de régression demandent une journée, vous ne pouvez pas proposer un SLA de deux heures sans ignorer ce délai. De même, les bugs que vous transmettez lorsque vous sautez l'étape des tests de régression ont tendance à se révéler pires que ceux que vous essayez de corriger. Nous avons appris une version de ce principe lorsque nous avons tenté de laisser le modèle rédiger ses propres correctifs et observé certains de ces correctifs corriger le bug initial, tout en brisant discrètement un autre élément sur lequel le code dépendait.

La question la plus difficile repose sur le fait de savoir à quoi l'architecture autour d'une vulnérabilité devrait ressembler. Le principe ici consiste à compliquer l'exploitation d'une vulnérabilité plus difficile par un acteur malveillant même lorsqu'un bug existe, de sorte que l'écart entre le moment de la divulgation d'une vulnérabilité et le déploiement de son correctif importe moins. Cette approche implique la mise en place de mesures de défense qui se placent devant l'application afin d'empêcher les cybercriminels d'entrer en contact avec le bug. Elle implique aussi de concevoir l'application de manière à ce qu'une faille dans une partie du code ne puisse pas permettre à un acteur malveillant d'accéder à d'autres parties du réseau. Elle implique enfin de pouvoir déployer un correctif partout où le code est exécuté en simultané plutôt que d'attendre que les différentes équipes le déploient. 

Nous reconnaissons également que ce sujet s'avère à double tranchant. Entre de mauvaises mains, les mêmes capacités que celles qui nous ont aidés à identifier les bugs dans notre propre code pourraient accélérer les attaques contre chaque application située sur Internet. Cloudflare se place devant des millions de ces applications et les principes architecturaux décrits ci-dessus sont exactement ceux que nos produits sont conçus pour appliquer au nom de nos clients. Nous partagerons davantage d'informations sur les implications pour nos clients dans les semaines à venir.

N'hésitez pas à nous contacter sur security-ai-research@cloudflare.com si votre équipe effectue un travail similaire et souhaite comparer ses notes de recherche.

Nos recherches sur Mythos Preview ont été conduites au sein d'un environnement contrôlé et sur notre propre code. Chaque vulnérabilité identifiée a été triée, validée et corrigée lorsque l'opération s'avérait nécessaire dans le cadre du processus formel de gestion des vulnérabilités en vigueur chez Cloudflare.

Ce travail fut avant tout un effort d'équipe. Merci à Albert Pedersen, Craig Strubhart, Dan Jones, Irtefa Fairuz, Martin Schwarzl et Rohit Chenna Reddy pour leurs contributions à la recherche, à l'ingénierie et à l'analyse qui nous ont permis d'élaborer cet article.

Cet après-midi, nous avons envoyé l'e-mail suivant à nos équipes à travers le monde. L'une des valeurs essentielles sur lesquelles repose Cloudflare est la transparence et nous estimons qu'il est important que vous entendiez cette actualité directement de notre part, car il s'agit d'un tournant majeur pour Cloudflare. 

À notre équipe :

Nous vous écrivons afin de vous informer directement que nous avons pris la décision de réduire les effectifs de Cloudflare de plus de 1 100 collaborateurs à travers le monde. 

La manière dont nous travaillons chez Cloudflare s'est transformée à un niveau fondamental. Notre activité ne consiste pas qu'à développer et vendre des plateformes et des outils assistés par IA. Nous sommes nous-mêmes notre client le plus exigeant. L'utilisation de l'IA par Cloudflare a augmenté de plus de 600 % au cours du seul dernier trimestre. Les collaborateurs de l'ensemble de notre entreprise, de l'ingénierie aux ressources humaines, en passant par les finances et le marketing, lancent chaque jour des milliers de sessions avec des agents assistés par IA pour accomplir leurs tâches. Nous devons dès lors faire preuve de transparence quant à la manière dont nous avons l'intention de préparer notre entreprise pour l'ère de l'IA agentique afin de dynamiser la valeur que nous apportons à nos clients et d'honorer notre mission visant à contribuer à bâtir un Internet meilleur pour tous, partout dans le monde. 

L'annonce d'aujourd'hui est donc des plus difficiles. La décision que nous avons prise implique malheureusement de dire au revoir à des collègues qui ont contribué de manière remarquable à notre mission et à faire de Cloudflare l'une des entreprises les plus prospères du monde. Nous tenons à préciser que cette décision ne reflète en rien les efforts individuels ou le talent de ceux qui vont nous quitter. Nous réinventons au contraire chacun de nos processus internes, chacune de nos équipes et chacun des rôles au sein de notre entreprise. La décision d'aujourd'hui n'a pas pour objectif de réduire les coûts ni d'évaluer individuellement les performances de nos collaborateurs. Il s'agit pour Cloudflare de définir la manière dont une entreprise d'envergure mondiale en forte croissance fonctionne et crée de la valeur à l'ère de l'IA agentique. 

Nous devons assumer la responsabilité de ce moment en tant que fondateurs et dirigeants de l'entreprise. Matthew a personnellement envoyé chaque offre que nous avons adressée. C'est un acte qu'il a toujours anticipé, car il représentait la croissance de notre entreprise et concernait les incroyables talents qui nous ont rejoints dans notre mission. Il ne nous semblait pas juste que cette information vous parvienne par d'autres moyens que nous deux. Plutôt que de vous communiquer des notifications au compte-goutte par l'intermédiaire de vos responsables, nous adresserons un e-mail à chacun de nos collaborateurs. 

Au cours de l'heure qui va suivre, chaque membre de nos équipes à travers le monde recevra un e-mail de notre part clarifiant la manière dont ce changement va les affecter. Pour tous ceux qui nous quittent aujourd'hui, nous enverrons ce courrier à la fois à leur adresse personnelle et à leur adresse Cloudflare afin de nous assurer qu'ils reçoivent immédiatement l'information.

Il est important pour nous de traiter avec honnêteté les collaborateurs qui nous quittent, d'une manière qui va au-delà de ce que nous avons observé au sein d'autres entreprises. Nous considérons qu'agir avec empathie n'implique pas d'éviter de prendre les décisions difficiles, mais concerne plutôt la manière de traiter les individus une fois ces décisions prises. Si nous demandons à notre équipe de figurer parmi les meilleures du monde, nous avons l'obligation réciproque de figurer nous-mêmes parmi les meilleurs du monde en ce qui concerne la manière dont nous traitons ses membres. Nous associons la rigueur de ces mesures à des indemnités de départ à la pointe de ce qui se fait dans le secteur. Les indemnités destinées aux collaborateurs qui nous quittent comprendront l'équivalent de leur salaire de base complet jusqu'à la fin de l'année 2026. La couverture santé varie selon nos points d'implantation à travers le monde. Si vous vous trouvez aux États-Unis, nous continuerons à vous soutenir jusqu'à la fin de l'année. Nous accorderons également une participation aux collaborateurs qui nous quittent jusqu'au 15 août afin qu'ils reçoivent des actions au-delà de leur date de départ. De même, si les collaborateurs qui nous quittent n'ont pas atteint leur terme d'un an, nous lèverons cette condition et leur décernerons une participation calculée au prorata jusqu'au mois d'août également. 

Nous avons demandé à notre équipe de ne prendre cette décision qu'une seule fois, aussi difficile qu'elle puisse l'être aujourd'hui. Nous ne souhaitons pas la renouveler dans un avenir prévisible. En prenant des mesures décisives maintenant, nous apportons des éclaircissements immédiats à ceux qui nous quittent et protégeons la stabilité des collaborateurs qui resteront parmi nous. Nous mettons en œuvre ces changements aujourd'hui, car le fait de procéder à une série de réductions d'effectifs de moindre ampleur, mais répétées, ou d'étendre la réorganisation sur plusieurs trimestres crée une incertitude émotionnelle prolongée chez nos collaborateurs et entrave notre capacité à nous développer. Il s'agit là de la meilleure façon d'agir, la plus honnête, un acte qui reflète les valeurs de l'entreprise que nous continuerons à construire.

Cloudflare a vu le jour sous la forme d'une entreprise native du numérique et bâtie dans le cloud. Cette forme nous a permis de rattraper et de dépasser des entreprises qui disposaient d'une avance de plusieurs années, voire de plusieurs décennies, mais qui se trouvaient ralenties par des systèmes et des processus obsolètes. Maintenant que nous sommes devenus le leader du secteur, nous ne pouvons pas nous reposer sur les procédures et les structures organisationnelles d'hier. Nous sommes convaincus que notre entreprise restructurée se révélera encore plus rapide et innovante pendant que nous continuerons à façonner l'avenir.

À ceux qui nous quittent : vous avez contribué à bâtir les solides fondations sur lesquelles Cloudflare se dresse aujourd'hui. Nous avons le plus grand respect pour vos efforts et vous remercions de l'impact que vous avez eu. Nous sommes convaincus que vous trouverez d'autres postes d'excellence et fonderez de nombreuses entreprises d'avenir, en apportant avec vous l'ensemble unique de compétences que vous avez acquises en bâtissant Cloudflare.

La transparence constitue un principe fondamental de Cloudflare, il était donc important que vous entendiez la nouvelle directement de notre part. Nous assisterons à notre conférence téléphonique sur les résultats à 14 h (UTC-7), au cours de laquelle nous vous communiquerons davantage d'informations. Nous prévoyons également de traiter les annonces d'aujourd'hui en direct avec notre équipe lors de notre réunion plénière. 

Ce n'est pas une journée facile à vivre, mais nous avons pris la bonne décision. Notre mission visant à contribuer à bâtir un Internet meilleur est plus importante que jamais et nous avons encore beaucoup de travail devant nous.

Ces deux derniers trimestres (et même un peu plus), nous avons entrepris un effort de développement intensif, baptisé en interne « Code Orange: Fail Small », un projet axé sur le renforcement de la résilience, de la sécurité et de la fiabilité de l'infrastructure Cloudflare pour chacun de nos clients.

L'équipe Cloudflare a achevé ces travaux au début du mois.

Nous ne considérerons jamais l'amélioration de la résilience comme un « travail fini ». Il s'agira d'ailleurs toujours d'une de nos priorités en tête de liste tout au long de notre cycle de développement. Nous avons néanmoins achevé le travail qui nous aurait évité les deux défaillances mondiales survenues les 18 novembre et 5 décembre 2025.

Le projet s'axait autour de plusieurs domaines essentiels : l'amélioration de la sécurité des modifications de configuration, la réduction de l'impact des défaillances, ainsi que la révision de nos procédures d'urgence (break-glass) et de gestion des incidents. Nous avons également introduit des mesures destinées à éviter la dérive et les régressions au fil du temps, mais aussi à renforcer la manière dont nous communiquons avec nos clients lors d'une défaillance.

Cet article détaille en profondeur les fonctionnalités que nous avons lancées et leurs implications pour vous.

Les implications pour vous : dans la plupart des cas, les modifications de configuration du réseau Cloudflare effectuées en interne ne se propagent plus instantanément sur notre réseau, mais sont déployées progressivement, en surveillant l'intégrité de ce dernier en temps réel. Ce processus permet à nos outils d'observabilité de détecter les problèmes et de résoudre les dysfonctionnements avant qu'ils n'affectent votre trafic.

Afin d'intercepter les déploiements potentiellement dangereux avant leur mise en production, nous avons identifié les pipelines de configuration à haut risque et développé de nouveaux outils conçus pour mieux gérer les modifications apportées aux configurations.

Nous ne déployons ainsi plus ces changements instantanément sur l'ensemble du réseau pour les produits qui s'appuient sur notre réseau pour traiter le trafic client et recevoir les modifications apportées. De ce fait, les équipes concernées ont adopté une méthodologie de « déploiement piloté par l'intégrité », qui se révèle strictement la même que celle que nous utilisons pour la mise en œuvre de toutes les configurations lorsque nous lançons des logiciels. Cette approche inclut, sans toutefois s'y limiter, les équipes produits directement affectées par les incidents.

La clé de cette stratégie réside dans un nouveau composant interne que nous nommons Snapstone et que nous avons développé pour mettre en place le déploiement piloté par l'intégrité au niveau des modifications de configurations. Le système Snapstone regroupe ces modifications au sein d'un package et permet ensuite de procéder à un déploiement progressif de ces dernières en suivant les principes du pilotage par l'intégrité. Avant Snapstone, l'application de cette méthodologie aux configurations était possible, mais demeurait une tâche des plus ardues. L'opération demandait un travail considérable à chacune des équipes et les modifications n'étaient pas appliquées de manière cohérente sur l'ensemble du réseau. Snapstone comble cette lacune en proposant, par défaut, un moyen unifié d'incorporer les notions de mise en œuvre progressive, de surveillance de l'intégrité en temps réel et de roll-back automatique aux déploiements de configurations.

Le principal atout de Snapstone réside dans sa flexibilité. Plutôt que de corriger les défaillances spécifiques déjà passées, la solution Snapstone permet aux équipes de définir de manière dynamique n'importe quelle unité de configuration nécessitant un pilotage par l'intégrité, qu'il s'agisse d'un fichier de données (comme celui qui causé la panne du 18 novembre) ou d'un indicateur de contrôle au sein de notre système de configuration mondial (comme celui impliqué dans la défaillance du 5 décembre). Les équipes produisent ces unités de configuration à la demande et Snapstone s'assure que ces dernières soient déployées de manière sécurisée, partout où elles sont utilisées.

Cette opération nous offre quelque chose dont nous ne disposions pas auparavant. La solution est désormais des plus simples lorsqu'un processus d'examen des risques ou une expérience opérationnelle identifie une configuration dangereuse : il nous suffit d'aiguiller l'élément en question vers Snapstone et la configuration bénéficiera immédiatement d'un déploiement sécurisé. 

Les implications pour vous : en cas de problème observé au sein de notre réseau, nos systèmes tombent désormais en panne avec davantage de souplesse. Cette situation réduit le champ potentiellement affecté dans des proportions considérables et nous permet d'assurer la diffusion de votre trafic, même dans les scénarios les plus catastrophiques.

Les équipes produit ont analysé avec soin (de façon manuelle et programmatique) les modes de défaillance potentiels de leurs produits essentiels au traitement du trafic de nos clients. Elles ont ainsi supprimé les dépendances non essentielles de l'environnement d'exécution et déployé de meilleurs modes de défaillance. Nous employons désormais la dernière configuration fonctionnelle connue si possible (« fail stale »). Si l'opération ne se révèle pas possible, nous examinons chaque scénario d'erreur et mettons en œuvre une solution « fail open » (basculement en position ouverte) ou « fail close » (basculement en position fermée) selon que la diffusion du trafic sous fonctionnalité réduite s'avère préférable au fait ne pas diffuser du tout le trafic.

Illustrons ce fonctionnement par un exemple. Notre panne survenue au mois de novembre 2025 résulte de l'échec du déploiement de notre classificateur (soutenu par apprentissage automatique) chargé de la détection et de la gestion des bots. Avec nos nouvelles procédures, si des données que notre système ne pouvait pas lire étaient générées à nouveau, ce dernier refuserait d'utiliser la configuration mise à jour et emploierait dès lors l'ancienne configuration. Si l'ancienne configuration n'était pas disponible pour une raison quelconque, le système basculerait en mode « fail open » afin de faire en sorte que le trafic de production du client continue d'être diffusé. Il s'agit là d'une bien meilleure solution que de passer par un épisode d'interruption de service.

Par conséquent, si la modification de la solution Bot Management qui était à l'origine de la défaillance de novembre devait être déployée aujourd'hui, le système détecterait l'erreur à une phase avancée du déploiement, avant qu'elle n'affecte davantage qu'un faible pourcentage du trafic.

Nous avons également commencé à segmenter davantage notre système afin que des copies indépendantes des services soient exécutées pour différents groupes de trafic. Cloudflare tire déjà parti de ces groupes de clients aujourd'hui pour atténuer le rayon d'action des attaques grâce à diverses techniques de gestion du trafic. Cette segmentation supplémentaire des processus nous permet désormais de disposer de puissantes capacités en termes de fiabilité.  

L'environnement d'exécution de Workers, par exemple, est segmenté en plusieurs services indépendants qui gèrent chacun un groupe de trafic différent et seul l'un de ces groupes gère le trafic de nos clients titulaires de l'offre gratuite. Les modifications sont déployées sur ces segments en fonction des groupes de clients, en commençant par nos clients gratuits. Nous envoyons également plus rapidement et plus fréquemment les mises à jour vers les segments moins critiques, et à un rythme plus lent vers les segments les plus essentiels.

De ce fait, si une modification était déployée au sein de l'environnement d'exécution de Workers et engendrait une perturbation du trafic, cette modification n'affecterait qu'un faible pourcentage de nos clients gratuits, avant d'être automatiquement détectée et annulée.

Pour en revenir à l'environnement d'exécution de Workers, le processus de déploiement s'est, par exemple, déclenché plus de 50 fois au cours d'une période de sept jours au début du mois. Le graphique ci-dessous montre comment chacun de ces scénarios se déroule « par vagues », lorsque la modification se propage vers la périphérie du réseau (l'edge), souvent de manière parallèle aux versions suivantes et précédentes :

Nous comptons étendre ce principe de déploiement à bien d'autres de nos systèmes à l'avenir.

Les implications pour vous : si un incident se produit, nous disposons des outils et des équipes nécessaires pour nous permettre de communiquer plus clairement sur le problème et de résoudre ce dernier plus rapidement, tout en réduisant l'épisode d'interruption de service au minimum.

Cloudflare s'exécute sur Cloudflare. Nous sécurisons notre infrastructure à l'aide de nos propres produits Zero Trust, mais cette situation entraîne une dépendance. Dès lors, si une panne à l'échelle du réseau affecte ces outils, nous perdons les liaisons même que celles dont nous avons besoin pour les corriger. Avant l'initiative « Code Orange », nos protocoles d'urgence étaient réservés à une poignée de personnes et ne proposaient qu'un accès limité aux outils. Nous avons besoin de ces outils et de liaisons plus largement disponibles en cas de défaillance.

Pour résoudre ce problème, nous avons conduit un audit complet des outils essentiels à la visibilité du système, au débogage et aux modifications apportées à l'environnement de production. Nous avons finalement développé des liaisons d'autorisation de secours composées de 18 services essentiels, pris en charge par de nouveaux scripts et proxys d'urgence.

Le programme Code Orange nous a permis de passer de la théorie à la pratique. Après une phase d'exercices en petites équipes, nous avons organisé un exercice impliquant l'ensemble de notre service technique (soit plus de 200 collaborateurs) le 7 avril 2026. Les exercices de ce type permettent à nos techniciens de développer des automatismes sur lesquels ils pourront compter en cas de crise, même si nos processus automatisés nous permettent de préserver le bon fonctionnement de ces liaisons.

Cette initiative portait également sur le flux d'informations. Notre processus de réponse aux incidents ralentit en cas de perturbation de notre visibilité interne et notre capacité à communiquer avec le monde extérieur en pâtit. Traditionnellement, les observations techniques réalisées dans le feu de l'action ne se sont pas toujours traduites par des mises à jour précises pour nos clients.

Nous avons mis en place une équipe de communication dédiée pour remédier à ce problème. Cette dernière est chargée de travailler en étroite collaboration avec les équipes de réponse aux incidents lors des événements majeurs. Pendant que nos techniciens s'exerçaient à pratiquer leurs procédures d'urgence, cette équipe s'appuyait sur le programme Code Orange pour s'exercer à rationaliser le rythme et la clarté des mises à jour clients. Maintenant que nous nous sommes assurés que nous disposons à la fois des outils nécessaires à la visibilité et d'une structure adéquate pour communiquer, nous pouvons résoudre plus rapidement les incidents et mieux informer nos clients.

Les implications pour vous : nous nous souviendrons des enseignements tirés des incidents que nous avons subis et avons codifié nos résolutions en ce sens. Notre réseau ne peut désormais que devenir plus résilient.

Afin d'éviter tout dérapage et de réintroduire des vulnérabilités dans le travail accompli au fil du temps dans le cadre du programme Code Orange, notre équipe a mis au point un codex interne qui réunit l'ensemble de nos recommandations sous la forme de règles claires et concises.

L'utilisation du codex est désormais obligatoire pour l'ensemble de nos équipes techniques et produits. Cet ouvrage s'impose donc comme un composant central des procédures internes en vigueur chez Cloudflare. Ses règles sont mises en application par des processus de révision du code généré par IA qui mettent automatiquement en lumière les instances susceptibles de diverger de nos lignes directrices et qui impliquent la réalisation d'examens manuels supplémentaires. Le codex s'applique à l'intégralité de notre base de code, sans exception. L'objectif est simple : nous bâtir des automatismes à l'échelle de l'entreprise capables de s'appliquer eux-mêmes.

Les pannes des mois de novembre et de décembre partageaient un mode de défaillance commun, à savoir un code qui supposait que les entrées seraient toujours valides et qui ne disposait d'aucun mécanisme de dégradation en douceur lorsque cette hypothèse s'avérait fausse. Un service Rust appelait .unwrap() plutôt que de traiter une erreur, tandis que le code Lua indexait un objet qui n'existait pas. Ces deux schémas peuvent être évités si les leçons ont bien été assimilées et mises en application.

Le codex fait partie intégrante de notre processus de réponse. Ce référentiel vivant de normes techniques est rédigé par des experts de leur domaine par l'intermédiaire de notre processus RFC (Request for Comments, demandes de commentaires), avant d'être synthétisé sous la forme de règles exploitables. Les bonnes pratiques autrefois uniquement connues des techniciens expérimentés ou qui n'étaient identifiées qu'après un incident deviennent désormais une somme de savoir partagé et accessible à tous. Chaque règle suit un format simple : « Si vous avez besoin de X, servez-vous de Y ». Elle s'accompagne également d'un lien vers la RFC qui en explique les raisons.

Une RFC stipule désormais : « Ne pas utiliser .unwrap() » en dehors des tests et du fichier build.rs », par exemple. Une autre exprime un principe plus large : « Les services DOIVENT valider que les dépendances en amont sont bien dans l'état attendu avant de traiter une opération quelconque ».

Si ces règles avaient été appliquées plus tôt, les défaillances de novembre et décembre auraient pris la forme de demandes de fusion refusées plutôt que de se traduire par des incidents mondiaux.

Sans mise en application, les règles ne sont que des suggestions. Le codex s'intègre à des agents assistés par IA à chaque étape du cycle de vie du développement logiciel, de l'examen de la conception jusqu'au déploiement en passant par l'analyse des incidents. Ce mode de fonctionnement fait passer la mise en application du statut de « panne mondiale » à celui de « demande de fusion refusée ». Le rayon d'action d'une violation passe de millions de requêtes affectées à l'information d'un seul développeur par le biais d'un retour exploitable avant que le code n'atteigne la production.

Le codex est un document vivant, qui sera amélioré en permanence au fil du temps. Les experts de leur domaine rédigent des RFC afin de codifier les bonnes pratiques. Les incidents mettent en lumière les lacunes, qui deviennent ensuite de nouvelles RFC. Chaque RFC approuvée génère des règles qui viennent intégrer le codex. Ces règles nourrissent les agents qui examineront la demande de fusion suivante. L'ensemble se comporte un peu comme un volant d'inertie : l'expertise se transforme en normes, les normes deviennent des mesures d'application et ces mesures relèvent le niveau pour tout le monde.

Les implications pour vous : la transparence est essentielle à nos yeux. En cas de problème, nous nous engageons à vous tenir informés à chacune des étapes du cycle afin de vous permettre de continuer à vous concentrer sur l'essentiel.

Les défaillances à l'échelle mondiale nous ont amenés à remettre en question certains processus clés et certaines approches culturelles en vigueur au sein de notre entreprise, au-delà même de la technique et du développement produits. Nous avons ainsi ajouté des objectifs de niveau de service (Service Level Objectives, SLO) supplémentaires à l'ensemble de nos services dans le cadre des initiatives Code Orange au sens plus large. Nous avons en outre imposé un journal des modifications mondial, intégré toutes nos équipes à notre système de coordination de la maintenance et amélioré la transparence de notre backlog de tickets de « prévention » d'incidents sur l'ensemble de notre entreprise. 

Nous avons également renforcé la manière dont nous communiquons avec nos clients lors d'un épisode de défaillance. L'objectif poursuivi ici est de vous alerter d'un problème dès que nous pouvons le confirmer, et ce avant même que vous ne remarquiez le problème. Ainsi, lorsque vous constatez un délai ou une erreur, vous devriez déjà avoir un bulletin d'information de notre part dans vos notifications.

En cas d'incident, nous vous informons désormais à intervalles prévisibles (p. ex. toutes les 30 ou 60 minutes), même si ce n'est que pour vous indiquer « Nous sommes toujours en train de tester la solution. Aucune modification n'est déployée pour le moment ». Vous pouvez ainsi continuer à organiser votre journée plutôt que de devoir constamment actualiser une page d'état.

Notre travail ne se termine pas au moment où la situation revient à la normale. Nous vous proposons une analyse après incident détaillée afin de vous expliquer ce qui s'est passé, les raisons pour lesquelles l'incident s'est produit, ainsi que les changements structurels spécifiques que nous apportons à nos systèmes afin de nous assurer que cet événement ne se reproduise pas à l'avenir.

Nous prenons ces incidents très au sérieux et, en ce sens, avons adopté la notion de responsabilité partagée au sein de l'ensemble de Cloudflare en demandant à chacune de nos équipes : « Qu'aurait-on pu mieux faire ? » Les réponses à cette question ont guidé les travaux que nous avons entrepris ces deux derniers trimestres.

Bien que ce travail ne prenne jamais vraiment fin, nous sommes convaincus de nous trouver dans une position bien meilleure et Cloudflare en ressort désormais bien plus solide.

À compter d’aujourd’hui, les agents peuvent provisionner Cloudflare pour le compte de leurs utilisateurs. Ils peuvent créer un compte Cloudflare, souscrire un abonnement payant, enregistrer un domaine et obtenir un jeton d’API pour déployer immédiatement leur code. Des utilisateurs humains peuvent être intégrés au processus de demande d’autorisation, et ils doivent accepter les conditions d’utilisation de Cloudflare. En dehors de cette tâche, toutefois, aucune autre intervention humaine n’est requise du début à la fin du processus. Il n’est pas nécessaire d’accéder au tableau de bord, de copier-coller des jetons d’API ou de saisir les informations d’une carte de paiement. Sans aucune configuration supplémentaire, les agents disposent de toutes les informations et autorisations nécessaires pour déployer une nouvelle application de production en une seule fois. Et, grâce aux serveurs MCP Code Mode et aux packages Agent Skills de Cloudflare, ils le font encore plus efficacement.

Tout cela fonctionne grâce à un nouveau protocole que nous avons conçu en collaboration avec Stripe, dans le cadre du lancement de Stripe Projects.

Nous sommes ravis d’inaugurer ce nouveau partenariat avec Stripe et d’offrir 100 000 dollars de crédits Cloudflare à toutes les start-ups qui utilisent Stripe Atlas pour leur incorporation. Toutefois, ce nouveau protocole permet également d’intégrer toute plateforme comportant des utilisateurs connectés à Cloudflare, de la même manière que Stripe, sans aucune difficulté pour les utilisateurs finaux.

Installez l’interface de ligne de commande Stripe CLI avec le plugin Stripe Projects, connectez-vous à Stripe, puis créez un nouveau projet :

stripe projects init

Demandez ensuite à votre agent de créer une nouvelle application et de la déployer sur un nouveau domaine. Vous pouvez regarder ci-dessous une courte vidéo de deux minutes résumant l’ensemble de cette séquence :

Si l’adresse e-mail avec laquelle vous êtes connecté à Stripe est déjà associée à un compte Cloudflare, vous serez invité à suivre une procédure d’authentification OAuth habituelle afin d’accorder l’accès à l’agent. Si aucun compte Cloudflare n’est associé à l’adresse e-mail avec laquelle vous vous êtes connecté, Cloudflare créera automatiquement un compte pour vous et votre agent :

Vous verrez l’agent créer et déployer un site sur un nouveau compte Cloudflare, puis utiliser l’interface CLI de Stripe Projects pour enregistrer le domaine :

L’agent vous demandera de saisir des informations et d’autoriser ses actions lorsque nécessaire. Par exemple, si aucun moyen de paiement n’est encore associé à votre compte Stripe, l’agent vous invitera à en ajouter un :

À la fin de la procédure, l’agent a été déployé en production et l’application s’exécute sur le domaine nouvellement enregistré :

L’agent a progressé du point zéro, sans compte Cloudflare, sans package Agent Skills ni serveur MCP préconfiguré, à :

• La fourniture d’un nouveau compte Cloudflare

• L’obtention d’un jeton d’API

• L’achat d’un domaine

• Le déploiement d’une application en production

Mais attendez… Comment l’agent a-t-il découvert qu’il était capable de faire tout cela ? Comment savait-il quels services il pouvait provisionner et comment acheter un domaine ? Comment a-t-il obtenu les informations contextuelles indispensables pour comprendre comment déployer une application sur Cloudflare ? Examinons cela de plus près.

L’interaction entre l’agent, Stripe et Cloudflare illustrée ci-dessus comporte trois éléments :

• Découverte : l’agent peut appeler une commande afin d’interroger le catalogue de services disponibles.

• Autorisation : la plateforme authentifie l’identité de l’utilisateur, ce qui permet aux fournisseurs de créer des comptes ou d’associer des comptes existants, puis d’assurer la transmission sécurisée des identifiants à l’agent.

• Paiement : la plateforme fournit un jeton de paiement que les fournisseurs peuvent utiliser pour facturer le client, permettant à l’agent de souscrire des abonnements, d’effectuer des achats et d’établir une facturation en fonction de l’utilisation.

Ces procédures sont fondées sur l’état de la technique et les normes existantes, telles que OAuth, OIDC et la tokenisation des paiements, mais elles sont utilisées conjointement pour éliminer une multitude d’étapes qui pourraient autrement nécessiter l’intervention d’un utilisateur humain.

Dans la session d’agent décrite ci-dessus, avant d’exécuter la commande CLI stripe projects add cloudflare/registrar:domain, l’agent a d’abord dû découvrir le service Cloudflare Registrar. Pour cela, il a exécuté la commande stripe projects catalog, qui renvoie la liste des services disponibles :

La liste complète de produits Cloudflare et de services proposés par d’autres fournisseurs est vaste et ne cesse de s’allonger, ce qui peut logiquement paraître déconcertant pour des utilisateurs humains. Pour les agents, toutefois, ce catalogue de services fournit précisément le contexte dont ils ont besoin. L’agent sélectionne les services à utiliser dans ce catalogue en fonction de ce que l’utilisateur lui a demandé de faire et de ses préférences. L’utilisateur n’a pas besoin de connaître au préalable les services proposés par les différents fournisseurs et n’a pas besoin de fournir d’informations. Les fournisseurs tels que Cloudflare mettent ce catalogue à disposition via une simple API REST qui renvoie des données au format JSON et fournit aux agents toutes les informations dont ils ont besoin.

Lorsque l’agent sélectionne et provisionne un service (par exemple : stripe projects add cloudflare/registrar:domain), il provisionne la ressource dans un compte Cloudflare. Mais comment parvient-il à créer un compte à la demande, sans demander à l’utilisateur de se rendre sur une page d’enregistrement ?

Vous souvenez-vous qu’au début, l’utilisateur s’est connecté à son compte Stripe ? Stripe se comporte comme un fournisseur d’identité, certifiant l’identité de l’utilisateur. Cloudflare provisionne automatiquement un nouveau compte pour l’utilisateur, si aucun compte n’existe déjà, puis renvoie les informations d’identification à l’interface CLI de Stripe Projects. Ces identifiants sont stockés de façon sécurisée, mais restent accessibles à l’agent, qui peut les utiliser pour exécuter des requêtes authentifiées auprès de Cloudflare. Cela signifie que si un utilisateur découvre Cloudflare ou d’autres services pour la première fois, il peut immédiatement commencer à développer des applications avec son agent, sans aucune étape supplémentaire.

Si l’utilisateur dispose déjà d’un compte Cloudflare, il est redirigé vers un processus OAuth standard, afin d’autoriser l’accès à l’interface CLI de Stripe Projects, ce qui lui permet de provisionner des ressources sur son compte Cloudflare existant.

Vous pourriez vous inquiéter, à juste titre : « Et si mon agent se laisse un peu emporter et commence à acheter des dizaines de domaines ? Vais-je me retrouver à devoir payer une facture astronomique ? Puis-je vraiment confier ma carte de paiement à mon agent ? »

Le protocole tient compte de ces préoccupations de deux manières. Lorsqu’un agent provisionne un service payant, Stripe inclut un jeton de paiement dans la requête adressée au fournisseur (c’est-à-dire Cloudflare). Les données de paiement brutes, telles que les numéros de carte de paiement, ne sont jamais communiquées à l’agent. Stripe impose alors une limite par défaut de 100,00 USD par mois, qui correspond au montant maximal que l’agent peut dépenser auprès d’un même fournisseur. Lorsque vous serez prêt à augmenter cette limite, vous pourrez configurer des alertes budgétaires sur votre compte Cloudflare.

Toute plateforme comportant des utilisateurs connectés peut se comporter comme un « orchestrateur », à l’instar de Stripe avec Stripe Projects, et s’intégrer à Cloudflare.

Supposons que votre produit soit un agent de codage. Vous aimeriez que les utilisateurs puissent déployer en production les applications qu’ils ont développées, en utilisant Cloudflare et d’autres services. Toutefois, la dernière chose que vous souhaitez, c’est bien d’inviter les utilisateurs à s’égarer dans un véritable dédale de procédures d’autorisation et d’arborescences décisionnelles pour déterminer où et comment déployer l’application. Vous souhaitez simplement permettre aux utilisateurs de déployer leurs applications.

Votre plateforme joue le rôle d’orchestrateur pour les utilisateurs déjà connectés. Si un utilisateur a besoin de pouvoir fournir un domaine, un compartiment de stockage, une sandbox ou quoi que ce soit d’autre à son agent, il vous suffit d’exécuter un simple appel d’API à Cloudflare pour provisionner un nouveau compte Cloudflare pour lui et obtenir un jeton permettant d’effectuer des requêtes authentifiées en leur nom.

Ou, supposons que vous souhaitiez permettre aux clients de Cloudflare de provisionner facilement votre service, de la même manière que le partenariat entre Cloudflare et Planetscale permet la création de bases de données Postgres Planetscale directement depuis Cloudflare. Nous avons commencé à travailler avec Planetscale sur ce projet bien avant que ce nouveau protocole ne voie le jour, mais le déroulement des opérations est ici assez similaire. Cloudflare joue le rôle d’orchestrateur, vous permettant de vous connecter à votre compte PlanetScale, de créer des bases de données et d’utiliser le mode de paiement existant de l’utilisateur pour la facturation.

Ce nouveau protocole commence à normaliser les types d’intégrations entre produits que de nombreuses plateformes proposent depuis des années, souvent de manière ponctuelle ou spécifique à une plateforme particulière. En l’absence de norme, chaque intégration nécessitait l’intervention de personnel technique, dont le travail s’avérait souvent inexploitable dans le cadre d’intégrations ultérieures. De la même manière que la norme OAuth a permis de déléguer l’accès à votre compte à d’autres plateformes, le protocole utilise OAuth et étend ses fonctionnalités aux paiements et à la création de comptes d’une manière qui accorde une place centrale aux agents.

Nous sommes impatients de continuer à faire évoluer cette norme et de collaborer avec Stripe afin de publier prochainement une spécification plus officielle. Nous sommes également impatients de proposer l’intégration d’autres plateformes. Écrivez-nous à l’adresse agenticpartnerships@cloudflare.com et dites-nous comment vous souhaitez intégrer votre plateforme à Cloudflare.

Stripe Projects est actuellement disponible en bêta ouverte, et vous pouvez commencer à l’utiliser, même si vous ne disposez pas encore d’un compte Cloudflare. Installez simplement l’interface de ligne de commande Stripe CLI, connectez-vous à Stripe, puis créez un nouveau projet :

stripe projects init

Demandez à votre agent de développer une nouvelle application sur Cloudflare et montrez-nous ce que vous avez créé !

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.