Nous avons modifié les paramètres par défaut. Les bots d'exploration destinés à l'entraînement de l'IA seront bloqués par défaut pour tous les nouveaux domaines sur le réseau Cloudflare à moins que les propriétaires de ces domaines n'en décident autrement. Cette modification n'avait pas pour objectif d'isoler le web. Nous l'avons déployée, car nous considérions qu'un écosystème plus sain nécessitait un certain degré de transparence, de contrôle et de rareté, mais aussi, en définitive, l'apparition d'un marché au sein duquel le contenu de haute qualité pourrait être valorisé et échangé de manière équitable.

Ce marché a émergé un an plus tard. Or, la transformation d'Internet s'est produite encore plus rapidement que prévu. Ce rapport a pour objectif de vous présenter des points de données essentiels qui illustrent la vitesse à laquelle le modèle économique de l'Internet a évolué, mais aussi ce que ce nouveau marché du contenu implique pour les éditeurs et les propriétaires de sites.

L'IA n'est pas un énième nouveau cycle technologique. Ce changement d'infrastructure se produit à plus de deux fois la vitesse à laquelle les smartphones ont été adoptés. En seulement 3 ans et demi, plus de 30 % de l'humanité a adopté l'utilisation régulière de l'IA générative (soit 2,5 milliards d'utilisateurs actifs). La courbe d'adoption ne présente plus seulement un pic rapide : elle en devient verticale.

Jamais auparavant nous n'avons observé une mutation aussi rapide de la manière dont les êtres humains interagissent avec l'information, procèdent à leurs tâches et passent du temps en ligne.

La façon dont les utilisateurs se servent d'Internet évolue dans des proportions considérables. Pour chaque heure passée en ligne à rechercher des informations aujourd'hui, 15 minutes seulement sont passées sur le web ouvert. Le comportement traditionnel de recherche s'effondre à mesure que les utilisateurs se tournent vers un processus de découverte et de consommation des informations piloté par IA. Plutôt que de se rendre sur plusieurs sites pour obtenir et comparer des informations, les utilisateurs n'ont désormais plus qu'à saisir une invite (prompt) pour recevoir une réponse consolidée presque instantanément.

Cette année, le trafic des agents a franchi un seuil historique pour la première fois : plus de 50 % du trafic circulant sur Internet est désormais d'origine automatisée. Ce changement a des implications stupéfiantes pour les éditeurs, les propriétaires de contenu, et l'avenir du web ouvert.

Lorsqu'on s'intéresse à l'objectif des bots d'exploration que Cloudflare identifie, la composition du trafic automatisé est des plus éloquentes :

• 52 % des requêtes des bots d'exploration concernaient l'entraînement de l'IA en juin 2026, contre 22 % au printemps 2025.

• Les bots d'exploration à usage mixte (qui allient la recherche, l'utilisation des agents et l'entraînement) totalisent plus de 36 % de l'activité.

• La pure exploration à des fins de recherche représente désormais une part réduite et en déclin de l'activité globale des bots, bien qu'elle reste essentielle pour la visibilité des éditeurs.

À l'heure où l'entraînement de l'IA devient le principal moteur de l'activité des bots d'exploration, la capacité de distinguer l'identification de l'entraînement gagne nettement en importance. Les bots d'exploration à usage mixte brouillent cette distinction, en contraignant les propriétaires de contenu à adopter une position difficile : choisir entre le fait de rester identifiable à l'ère de l'agentivité et céder leur contenu le plus précieux sans compensation.

Pendant des décennies, le modèle économique du web ouvert se révélait plutôt simple. Les créateurs de contenu échangeaient l'accès à leur contenu contre de la visibilité dans les moteurs de recherche, qui renvoyaient du trafic de référence. Ce trafic est devenu le principal mécanisme par lequel les éditeurs, les créateurs et les entreprises ont généré de la valeur économique.

Or, cette relation est en train de s'effondrer aujourd'hui. Le contenu continue d'être exploré, indexé et utilisé, mais de plus en plus sans trafic de référence correspondant vers la source. Lorsque les systèmes IA répondent aux questions, comparent des produits, mènent des recherches et accomplissent directement les tâches, les informations qui circulent sur le web ouvert deviennent de plus en plus partie intégrante des systèmes d'entraînement et de récupération sur lesquels repose l'IA. La question existentielle soulevée par ce constat est simple : si le contenu est consommé sans que les audiences ne se rendent jamais sur la source, comment les créateurs de contenu peuvent-ils se rémunérer de manière soutenable ?

Les premiers secteurs à ressentir l'impact sont ceux des organismes de presse et des entreprises de médias. Plusieurs dynamiques similaires impactent aujourd'hui les entreprises des secteurs du commerce, des logiciels, de l'IT et de la finance. Certaines des catégories les plus explorées ont vu le trafic d'origine humaine diminuer de 40 % en moins d'un an.

De nombreux éditeurs se préparent maintenant à ce qu'ils appellent le « Google Zero », un monde dans lequel peu ou pas de trafic provient de références liées aux recherches.

Les implications s'étendent à pratiquement tous les secteurs. Toutes les entreprises qui publient des informations propriétaires sur Internet devront comprendre comment opérer à l'ère agentique. Cette dynamique est des plus importantes, non seulement pour les propriétaires de contenu, mais également pour chacun d'entre nous. Le réseau Internet est une composante essentielle de l'économie mondiale et l'une des ressources publiques les plus essentielles pour faire émerger des informations. Il est crucial pour nous tous de nous assurer qu'il demeure sain et durable.

Nous nous sommes engagés sur trois aspects lorsque nous avons lancé la Journée de l'indépendance du contenu :

1. transparence et contrôle pour les propriétaires de sites afin de leur permettre de définir une approche quant à l'accès à leur contenu et à la monétisation de ce dernier ;

2. des outils qui créent de la rareté afin de renverser l'équilibre des pouvoirs en faveur des propriétaires de contenu ;

3. un marché au sein duquel les créateurs de contenu et les entreprises de développement d'IA de toutes les tailles peuvent identifier le contenu, l'évaluer et contracter une licence pour y accéder de manière plus efficace.

Un an plus tard, un marché pour le contenu monétisé est présent et les conditions sont en train de se former pour l'émergence d'un marché dynamique.

Historiquement, les éditeurs disposaient d'une visibilité limitée sur la manière dont les entreprises de développement d'IA accédaient à leur contenu et l'utilisaient. Plus le trafic référent diminuait, plus ce manque de visibilité est devenu un problème économique qui a incité les éditeurs à chercher de nouveaux moyens de capturer de la valeur.

Les structures d'attribution, d'intelligence métier et d'application des règles proposées par Cloudflare ont offert une visibilité sur la consommation de l'IA au niveau du réseau aux éditeurs. Ce mécanisme d'application s'est révélé bien plus efficace que les normes volontaires comme robots.txt. Pour la première fois, les éditeurs pouvaient déterminer une approche définissant l'accès à leur contenu et la monétisation de ce dernier. Ce contrôle a entraîné la rareté et engendré une économie basée sur l'offre et la demande autour du contenu.

Les éditeurs qui exerçaient un contrôle sur l'accès à leur contenu ont réussi à créer la rareté et cette dernière leur a donné un avantage pour négocier de meilleurs accords. Pour la première fois, les éditeurs ont bénéficié de données d'attribution de niveau opérationnel, comme une preuve de la fréquence à laquelle les LLM tentaient d'accéder à leur contenu, quels LLM concurrents exploraient leur contenu et quelles URL les modèles demandaient le plus souvent, en plus du rapport explorations/renvois. Ces données ont réduit l'asymétrie en matière d'information lors des discussions sur la cession de licences et ont permis aux éditeurs de négocier en toute connaissance de cause.

L'effet de levier généré a donné du pouvoir à nos clients.En acquérant davantage de visibilité sur la manière dont les systèmes IA accèdent à leurs contenus et les utilisent, nos clients sont mieux équipés pour comprendre les implications pour leurs entreprises et exprimer avec plus de confiance la valeur des informations, de la marque et des audiences qu'ils ont construites.

À l'heure où l'équilibre des pouvoirs entre les propriétaires de contenu et les entreprises de développement d'IA commence à changer, une économie tournant autour de l'octroi de licences émerge : 

• Plus de 50 accords éditeurs-IA ont été signés depuis 2023.

• En reconnaissant de plus en plus la valeur d'un contenu différencié et premium, les grandes entreprises de l'IA contractent désormais des licences pour accéder au contenu.

• Les modèles de licence collective continuent d'émerger et de se développer.

• Les grands éditeurs concluent des accords de licence significatifs et démontrent ainsi que le contenu présente une véritable valeur économique au sein de l'écosystème de l'IA.

La conversation ne porte plus sur le fait de savoir si le contenu doit être rémunéré. Elle porte maintenant sur la manière de le faire.

Les premiers accords de licence ont prouvé qu'il existait une demande, mais l'octroi de licence en lui-même demeure aujourd'hui largement une procédure sur mesure et se révèle peu susceptible de remplacer entièrement les revenus perdus du trafic référent, de la publicité et de l'affiliation. En conséquence, les éditeurs optimisent de plus en plus leur contenu pour la consommation par l'IA en parallèle de la découverte traditionnelle par des humains, tout en explorant de nouvelles voies de monétisation.

L'offre et la demande restent difficiles à concilier efficacement et à l'heure où le public commence à comprendre que tous les contenus n'ont pas la même valeur, le problème de l'évaluation de ces derniers n'est toujours pas résolu.

Aucune discussion sur ce marché ne saurait être complète sans aborder le rôle unique de Google. Avec près de 88 % du trafic de référence, Google demeure la principale porte d'entrée en matière de découverte de contenu en ligne. Google aide toutefois de plus en plus les utilisateurs à consommer du contenu directement au sein de l'expérience IA détenue par Google.

La découverte et la consommation servent des objectifs fondamentalement différents. La recherche oriente les utilisateurs vers le contenu, tandis que les expériences assistées par IA synthétisent et réutilisent de plus en plus ce dernier sans que les utilisateurs aient besoin de se rendre sur le site source. Les propriétaires de sites web traitent ces activités différemment, car l'une génère du trafic, tandis que l'autre le remplace de plus en plus.

Ces différences se révèlent particulièrement importantes lorsque les propriétaires de sites décident qui doit être autorisé à accéder à leur contenu et dans quel but. La plupart des grandes entreprises de développement d'IA distinguent les bots de découverte des bots d'entraînement. Les éditeurs peuvent dès lors proposer un accès relativement simple au contenu pour l'une ou l'autre de ces activités. Google ne fait pas cette différence. Google a aujourd'hui accès à près de deux fois plus d'informations que les principales entreprises de l'IA, car Google tire parti d'un bot à usage mixte qui complique la tâche aux clients qui souhaitent participer à l'écosystème de recherche Google sans également participer à l'écosystème IA de Google. 

Contrairement à d'autres fournisseurs d'IA, le bot d'exploration à usage mixte de Google limite également la transparence pour les propriétaires de sites. Comme les fonctions de découverte de contenu et d'accès à l'IA sont combinées sous un seul bot, les éditeurs ne peuvent pas connaître la finalité pour laquelle Google accède à leur contenu ni distinguer le trafic utilisé à des fins de recherche du trafic utilisé pour nourrir les expériences IA. Ils perdent également la visibilité et les preuves résultant de la capacité à autoriser ou bloquer ces activités de manière indépendante au niveau du réseau.

Cette dynamique a accéléré la demande pour davantage de transparence et de contrôle, ainsi que de nouveaux modèles de monétisation conçus pour servir à la fois les propriétaires de contenu et les entreprises de développement d'IA de toutes les tailles.

Cloudflare se situe à l'intersection de l'économie agentique émergente.

Plus de 20 % du web se situe derrière le réseau Cloudflare. 36 % des sites web les plus visités au monde s'appuient sur notre réseau et plus de 40 % des entreprises classées au Fortune 500 sont clientes de Cloudflare. Près de 80 % des principales entreprises de développement d'IA utilisent Cloudflare, en plus de milliers de développeurs et d'entreprises émergentes dans le domaine de l'IA.

Cette position unique nous confère une visibilité sur les deux côtés du marché. Nous observons ainsi les créateurs concevoir du contenu, les entreprises de l'IA le consommer et les signaux connecter de plus en plus ces deux acteurs. Cette perspective nous a permis de disposer d'une vision unique sur l'évolution du marché au cours de l'année écoulée, ainsi que sur ses exigences actuelles.

À l'heure où les éditeurs et les entreprises de développement d'IA s'adaptent à une nouvelle économie agentique, Cloudflare bénéficie désormais d'une compréhension plus nette des besoins actuels de l'écosystème.

Les propriétaires de contenu ont de plus en plus besoin de visibilité et de contrôle sur les utilisateurs et les entités qui accèdent à leur contenu, la manière dont ce dernier est utilisé et la finalité à laquelle il l'est. Les entreprises de développement d'IA reconnaissent de plus en plus que la transparence permet de bâtir la confiance et de réduire les frictions avec les éditeurs. La visibilité et l'application des règles ne sont plus uniquement des préoccupations de sécurité, il s'agit désormais d'exigences opérationnelles qui influencent directement les négociations autour de l'octroi de licences et la prise de décisions commerciales.

Pour contribuer à faire de la transparence une norme, Cloudflare continue d'investir dans des mécanismes améliorés de contrôle des mesures, de l'attribution et de la publication capables de proposer une plus grande visibilité aux propriétaires de contenu et un plus grand contrôle sur la manière dont leur contenu est consulté et utilisé.

Alors que le secteur évolue vers davantage de transparence, nous pensons que la mise en place d'un processus vérifiable d'auto-identification et de déclaration d'intention des bots d'exploration s'avère fondamentale pour un écosystème durable. Il reste toujours impossible pour les propriétaires de contenu de distinguer l'intention de l'exploration, car plus d'un tiers de l'activité des bots d'exploration sur notre réseau provient encore aujourd'hui de bots à usage mixte. Nous collaborons activement avec l'écosystème et investissons dans des outils pour faire en sorte que ce chiffre atteigne zéro d'ici l'année prochaine.

Il est devenu de plus en plus clair au cours de l'année écoulée que les entreprises de développement d'IA ont besoin de davantage que d'un simple accès au contenu. Elles ont besoin de meilleures méthodes pour déterminer à quel contenu accéder, à quel moment y accéder et à quelle fréquence ce contenu a fait l'objet de changements. L'exploration au hasard gaspille des ressources de calcul pour les entreprises de l'IA et entraîne une charge inutile en termes de bande passante pour les éditeurs. L'efficacité de l'ensemble de l'écosystème s'en trouve ainsi réduite.

Nous considérons que de meilleures réponses nécessitent une meilleure intelligence. Nous investissons dans des signaux de récence en temps réel avec une confiance, une qualité et une pertinence enrichies de manière à aider les entreprises de développement d'IA à découvrir des informations différenciées tout en réduisant les efforts d'exploration inutiles sur le web.

Nous pensons que l'amélioration du processus de découverte doit précéder celle de la tarification. Afin que le marché arrive à maturité, les éditeurs et les entreprises de l'IA ont besoin de meilleures informations les uns sur les autres. En investissant dans des dispositifs plus riches en termes de connaissance du marché, de signaux de contenu et de capacités susceptibles d'améliorer la découverte des deux côtés de l'écosystème, nous posons dès lors les bases de mécanismes de marché plus évolutifs sur le long terme.

Il y a un an, la Journée de l'indépendance du contenu a introduit une idée simple : les propriétaires de contenu devraient disposer de davantage de contrôle sur la manière dont les entreprises de développement d'IA accèdent à leurs informations et utilisent ces dernières.

Au cours des douze derniers mois, ce contrôle a contribué à donner naissance à un véritable marché. La transparence a créé la rareté. La rareté a généré un effet de levier. Cet effet de levier a accéléré l'émergence d'un système d'octroi de licences. Ce qui était autrefois une discussion théorique sur l'avenir de l'IA et du contenu est devenu un marché actif au sein duquel les éditeurs, les entreprises de l'IA et les fournisseurs de technologies s'adaptent tous à une nouvelle réalité économique.

Le marché entre maintenant dans une nouvelle phase nécessitant de nouvelles infrastructures. À l'heure où Internet devient de plus en plus agentique, les systèmes sous-jacents qui soutiennent le réseau mondial doivent évoluer pour gérer les autorisations, les licences et les transactions commerciales à grande échelle. Les propriétaires de contenu et les entreprises de développement d'IA ont besoin de moyens plus efficaces pour se connecter et échanger de la valeur. Nous pensons que ces capacités vont converger sous forme de mécanismes programmables et évolutifs encadrant la découverte et la monétisation du contenu afin de réduire les frictions, tout en libérant des structures d'échange de valeur plus riches.

Le rôle de Cloudflare consiste à bâtir l'infrastructure et l'intelligence métier, à contribuer aux normes qui permettent au marché de déterminer plus efficacement la valeur, mais aussi à aider les éditeurs et les entreprises de l'IA à participer à une économie dynamique plus saine autour du contenu.

L'Internet a toujours évolué. L'évolution qui nous intéresse aujourd'hui est plus rapide et plus conséquente que la plupart des évolutions qui ont précédé. Toutefois, avec la bonne infrastructure, les bonnes mesures incitatives et davantage d'engagement envers la transparence, nous pensons que l'Internet agentique peut devenir plus durable, plus efficace et meilleur pour tous.

Méthodologie : Les données de ce rapport sont compilées à partir de Cloudflare Radar et de la présentation de la Journée des investisseurs Cloudflare 2026.

Cloudflare Radar est un portail présentant des tendances et des analyses concernant le trafic Internet, les attaques et la technologie au niveau international. Soutenu par les données du réseau mondial Cloudflare, le service Radar a été créé pour aider chaque internaute à comprendre ce qui se passe sur Internet du point de vue de la sécurité, des performances et de l'utilisation.

Cloudflare présente une compréhension unique de l'Internet grâce à son réseau mondial (un des plus vastes au monde, présent dans plus de 270 villes de plus de 100 pays), ainsi qu'aux données agrégées et anonymisées issues de son résolveur DNS public 1.1.1.1, largement utilisé pour naviguer rapidement et en toute confidentialité sur Internet. Plus de 20 % du web se situe derrière le réseau Cloudflare.

Les moteurs de réponse d'aujourd'hui analysent votre page et proposent une synthèse à l'utilisateur, de sorte que la visite (et le revenu qui en dépendait) n'est plus nécessaire. Nous sommes aux premières loges pour observer ce phénomène, confirmé par des recherches indépendantes : une étude du Pew Research Center de 2025 a révélé que lorsque Google affiche une synthèse par IA, les utilisateurs ne cliquent sur un lien de résultat de recherche traditionnel que 8 % du temps (soit près de deux fois moins souvent qu'en l'absence d'une telle synthèse) et ne cliquent sur les liens présents dans le résumé que 1 % du temps. Cette situation place nos clients dans une impasse : se passer de l'IA et constater que leur contenu est désormais plus difficile à trouver, ou adhérer à cette nouvelle manière de faire et offrir une valeur significative aux utilisateurs, tout en ne bénéficiant que de moins en moins de retours. Nos clients souhaitent que leur contenu soit découvert et recevoir une juste rémunération pour la valeur qu'ils proposent. Or, l'époque actuelle les contraint à faire un choix.

Nous annonçons aujourd'hui de nouvelles options de gestion des bots afin d'aider nos clients à mieux contrôler qui peut accéder à leur site et ce que les bots et les utilisateurs peuvent faire de leur contenu. Le blocage ne constituait cependant que la première étape : le fait de dire « non » protège le contenu sans toutefois reconstruire les modèles économiques qui le soutiennent. Il est donc temps de commencer à bâtir le nouveau modèle économique de l'Internet, en commençant par le processus de recherche.

La transparence et le contrôle forment les bases, mais d'autres facteurs sont nécessaires. En 2025, nous avons établi nos fondations en définissant un ensemble de principes responsables pour la gestion des bots utilisés par l'IA : les bots doivent être transparents quant à leur identité et à leur finalité, ils doivent respecter les choix effectués par les propriétaires de sites et également agir de bonne foi. Nos outils exigent des bots qu'ils respectent ces normes. Toutefois, le fait de veiller à la mise en œuvre des bons comportements chez les bots n'améliore pas la recherche assistée par IA pour les utilisateurs qui en dépendent. Le processus ne renvoie aucune rémunération financière au créateur dont le travail a permis à la réponse d'exister. Nous pouvons faire davantage que de simplement aider le web à dire « non » : nous pouvons contribuer à reconstruire l'accord tacite qui existait par le passé, c'est-à-dire ce à quoi le réseau Internet avait dit « oui ».

Aujourd'hui, nous annonçons deux initiatives qui déplacent le curseur de la défense vers l'offensive et nous permettent de commencer à réassembler les deux moitiés de cet ancien accord.

Rendre la recherche assistée par IA plus intelligente : en utilisant les signaux que nous observons sur notre réseau mondial (p. ex. le contenu nouveau, de haute qualité et qui a réellement fait l'objet de modifications), nous pouvons aider les moteurs de réponse à mettre en avant le contenu le plus pertinent et à réduire le nombre d'explorations non désirées. Les utilisateurs qui effectuent des recherches obtiennent de meilleures réponses, tandis que les entreprises de développement d'IA et les propriétaires de sites voient leurs coûts diminuer si les pages web ne sont réexplorées que lorsqu'elles ont réellement fait l'objet de modifications.

Rémunérer les créateurs pour la valeur qu'ils proposent : les créateurs devraient être récompensés lorsque leur travail est utilisé pour répondre à une question, plutôt que d'être simplement extrait gratuitement. De même, ils devraient être en mesure de voir le contenu utilisé et ce que les utilisateurs demandent. Ce processus devrait être une véritable source de revenus et un mécanisme incitant les créateurs à continuer à produire du contenu original, digne d'être découvert.

Nous lançons aujourd'hui un programme conçu pour rendre la recherche assistée par IA plus intelligente et éviter que nos clients ne paient la facture d'explorations qui ne produisent rien de nouveau.

Nous bénéficions d'une perspective unique pour ce faire, car plus de 20 % du web est protégé par le réseau Cloudflare. Nous pouvons identifier les pages qui ont réellement fait l'objet de modifications, ainsi que celles vers lesquelles les utilisateurs et les agents se dirigent en masse. Ce programme nous permettra d'explorer l'utilisation des signaux que nos clients ont choisi de partager en ce qui concerne le caractère actuel de leur contenu, avant de les combiner à nos propres connaissances des flux de trafic, qu'ils soient d'origine humaine ou automatisée. Pour les moteurs de réponse, il s'agit là d'une feuille de route vers un contenu de haute qualité. Pour nos clients, ce programme propose une vue sur ce que les utilisateurs demandent réellement et sur la manière dont leur contenu apparaît dans les résultats de l'IA. L'objectif ici est de mesurer deux choses : dans quelle mesure ces signaux aident les moteurs de réponse à faire remonter un contenu plus récent et de meilleure qualité, ainsi que le nombre d'explorations inutiles que ces signaux permettent d'éliminer.

Ce deuxième avantage (réduire le nombre d'explorations inutiles) est plus important qu'il n'y paraît. Les données de Cloudflare suggèrent que plus de 50 % du trafic d'exploration issu de « bons bots » concerne la nouvelle analyse de pages qui n'ont pas changé. Ce chiffre pourrait augmenter à mesure que les volumes d'exploration s'accroissent. Un signal qui indique simplement « rien n'a changé ici » invitera les bots d'exploration à passer leur chemin. Il permettra ainsi au moteur de réponse d'économiser de la puissance de calcul. Plus important encore, il permettra aux propriétaires de sites d'éviter de diffuser leur contenu inutilement et de payer pour des requêtes dont ils n'ont jamais eu besoin. 

Le programme est neutre par conception : l'objectif que nous poursuivons pour ce dernier est qu'il s'applique à tous les moteurs de réponse prêts à respecter les règles du jeu. Il se limite d'ailleurs à la recherche. Nous ne partageons aucun contenu et n'utilisons pas non plus ce dernier pour entraîner des modèles de base. Nous avons l'intention de publier ce que nous apprenons, notamment les avantages qui en résultent pour les propriétaires de sites, comme une meilleure découvrabilité du contenu et une réduction de la charge serveur. Nous prévoyons de rendre cette fonctionnalité largement disponible plus tard au cours de l'année et de réduire le nombre d'explorations inutiles sur notre réseau.

L'année dernière, nous avons lancé le paiement à l'exploration pour permettre aux éditeurs de facturer les entreprises de développement d'IA qui souhaitent explorer leur contenu. Il s'agissait d'un véritable début, mais l'exploration ne constitue qu'une mesure brute de la valeur. Une page donnée peut être explorée une fois et ensuite citée dans des milliers de réponses, ou explorée maintes fois sans jamais être utilisée. Les créateurs souhaitent être rémunérés équitablement pour la valeur qu'ils proposent.

Nous commençons donc à transformer le principe de paiement à l'exploration en paiement à l'utilisation. Nous sommes en train de conduire diverses expériences avec des entreprises de pointe du secteur de l'IA, comme Ceramic.ai et You.com. L'arrangement est des plus simples : les entreprises peuvent utiliser leurs modèles de paiement et étendre facilement ces derniers aux créateurs de contenus situés sur le réseau Cloudflare.

Ceramic a créé ce qu'elle appelle un modèle de « paiement par requête », qui permet aux éditeurs adhérant à ce dernier d'être rémunérés lorsque leur contenu apparaît dans les résultats de recherche de Ceramic. Ce modèle implique que le paiement est conçu pour suivre la valeur générée par le travail plutôt que le nombre de fois qu'un bot d'exploration le récupère.

« Pour faire évoluer l'avenir de la recherche assistée par IA, nous avons besoin d'un partenaire doté d'une portée massive et d'un engagement commun en faveur de la transparence et d'une rémunération équitable », explique Anna Patterson, fondatrice et CEO de Ceramic.ai. Cloudflare nous permet d'étendre nos opérations facilement et de manière programmatique. En intégrant notre modèle de paiement à la requête à leur réseau, nous veillons à ce que des millions de créateurs de contenu puissent choisir en toute transparence d'être rémunérés chaque fois que leur contenu apparaît dans nos résultats de recherche. »

En plus d'une rémunération, les propriétaires de contenu participant au programme Cloudflare/Ceramic bénéficieront de nouveaux outils de reporting conçus pour améliorer leurs efforts d'optimisation des moteurs de réponse (AEO, Answer Engine Optimization). Les clients peuvent enfin voir les principales requêtes qui conduisent à l'apparition de leur contenu dans les résultats de recherche, la page web spécifique et l'extrait, ainsi leur position moyenne dans le classement des résultats de recherche, parmi d'autres informations. Ce produit constitue le premier d'une longue série que nous lancerons pour aider nos clients à améliorer leur découvrabilité.

Il ne s'agit là que d'une approche émergente. You.com va mettre en œuvre une autre approche, dans laquelle les agents peuvent payer un contenu premium spécifique dont ils ont besoin à la demande, sans engagement initial. Nous sommes actuellement en train de tester de nouveaux modèles de paiement des fournisseurs d'IA (p. ex., le paiement par requête, le paiement par résultat, etc.) et disposons de l'infrastructure nécessaire pour prendre tous ces modèles en charge. 

Nous souhaitons être honnêtes avec vous : il s'agit d'une expérience. Nous en avons toutefois beaucoup à apprendre, notamment comment cette approche se comporte à l'échelle d'Internet. Nous allons résoudre cette question au fur et à mesure, en collaboration avec nos partenaires et nos clients, avant de partager ce que nous apprendrons. L'objectif demeure clair cependant : les entreprises de recherche assistée par IA obtiennent des réponses plus récentes et mieux étayées, tandis que nos clients dont le travail permet ces dernières sont rémunérés lorsqu'ils contribuent à une réponse. Le rôle de Cloudflare dans cet organigramme consiste à proposer la couche d'infrastructure qui permet à ce marché d'exister et de se développer. 

Nous pensons que ce mode de fonctionnement correspond plus naturellement à l'évolution économique du processus de recherche. L'ancien web, axé sur l'humain, optimisait les recherches afin de gagner du temps, en proposant des extraits de contenu, dix liens bleus et une possibilité de clic. L'Internet agentique se comporte de manière différente : un agent peut lire rapidement le contenu et rechercher ce dernier en continu. La recherche devient dès lors une mécanique qu'un agent emploie des dizaines de fois pour répondre à une seule question. Le processus se rapproche dès lors davantage d'un service que d'une destination. Dans cet univers, l'unité importante n'est pas l'exploration ou le clic. Il s'agit du résultat. Le web continuera de prospérer grâce à l'évaluation des résultats et à la rémunération des créateurs qui ont rendu ces derniers possibles.

Il y a un an, lors de la Journée de l'indépendance du contenu, ce résultat se présentait sous la forme d'un « non » par défaut : l'IA ne peut pas explorer le contenu sans le rémunérer. Cette année, notre objectif consiste à proposer plus de produits et de mesures de contrôle à nos utilisateurs pour leur permettre de dire « oui » et d'en retirer davantage de bénéfices.

Les annonces d'aujourd'hui ne sont que le début d'une nouvelle aventure. Le projet de recherche de Cloudflare est conçu pour déterminer si nos signaux produisent de meilleurs résultats avec moins d'exploration. Le paiement à l'utilisation est une orientation prometteuse que nous allons expérimenter en compagnie de partenaires qui considèrent que les créateurs de contenu méritent une juste rémunération pour leur travail. C'est également sous cette forme qu'Internet s'est bâti ces 30 dernières années : quelqu'un lance un projet pilote qui transforme le schéma « le modèle est cassé » en « voici le nouveau modèle », une expérience à la fois. Nous pensons que nos clients peuvent dégager de la valeur du fait d'être découvrables dans cette nouvelle ère agentique et d'optimiser leur contenu pour une découverte maximale. Ils devraient toutefois pouvoir le faire sans céder gratuitement leurs ressources créatives les plus précieuses.

Le web évolue, de même que les modèles économiques sur lesquels il repose. L'ancien Internet était ouvert, neutre et valait la peine d'y contribuer. Nous avons devant nous une rare opportunité de le maintenir ainsi et de bâtir les modèles économiques qui le financeront à l'avenir. Des réponses plus intelligentes pour les utilisateurs humains et les agents qui posent les questions. Un accord équitable pour les créateurs dont la compétence, la créativité et l'engagement génèrent la valeur de ces réponses. C'est en suivant cette voie que nous poursuivons la mission de Cloudflare : contribuer à bâtir un Internet meilleur.

Joyeuse Journée de l'indépendance du contenu !

Vous souhaitez développer sur un web ouvert et prêt pour les agents ? Nous vous invitons à remplir ce formulaire si vous souhaitez en apprendre davantage sur les programmes de Ceramic et de You. Nous serions également ravis de vous entendre sur aeo@cloudflare.com si vous développez un moteur de réponse et souhaitez définir l'exploration de votre contenu de manière plus intelligente.

La situation a beaucoup évolué en un an. En juillet dernier, les discussions autour des « bots IA » se concentraient sur le blocage de l'entraînement des IA sans compensation et pointaient vers une situation perdant-gagnant où le contenu était utilisé pour l'entraînement des modèles sans retour de valeur pour le propriétaire du site web. Un désir pour davantage de nuance a toutefois émergé : les propriétaires de contenu souhaitent toujours pouvoir protéger leur contenu et devraient être rémunérés pour le contenu original sur lequel ils travaillent dur, que ce soit pour le créer, l'organiser ou le partager. Nous savons également que le verrouillage du contenu ne constitue pas une solution universelle. Les propriétaires de sites web souhaitent en effet disposer de davantage d'options que de simplement « bloquer tout le trafic automatisé, à chaque fois ».

Si vous gérez un petit site, le problème ne réside pas uniquement dans le fait que quelqu'un pourrait entraîner ses modèles sur votre contenu, c'est que personne ne peut vous trouver en premier lieu. Vous devez donc conclure un pacte faustien : soit apparaître dans les recherches et laisser l'IA s'entraîner sur votre contenu, soit risquer de perdre en visibilité. Cette situation avantage injustement les fournisseurs de recherche en place s'ils utilisent les mêmes bots pour la recherche et l'entraînement. Cet avantage injuste incite ainsi les nouveaux acteurs à se montrer évasifs lorsqu'ils tentent de réduire leur écart concurrentiel.

L'IA peut être présente dans n'importe quel type de ressource aujourd'hui. La recherche Google est passée de l'utilisation d'un outil de tri des réponses assisté par IA à celui du déploiement d'un moteur de réponse complet qui répond directement à votre question sur la page des résultats. Or, le cas Google n'est pas unique : c'est dans cette direction que s'oriente l'avenir de l'activité de « recherche ».

Nous pourrions débattre du seuil permettant de déterminer ce qui qualifie un bot comme « lié à l'IA » aujourd'hui, pour finalement découvrir que la norme aura changé demain. Ainsi, plutôt que de définir un bot principalement comme « lié à l'IA » ou non, notre approche actualisée de la classification posera des questions plus profondes sur le comportement des bots ou des agents : quelles actions effectuent-ils sur mon site ? Que stockent-ils ? Et comment vont-ils repartager mon contenu ?

Nous avons besoin d'une vision plus nuancée pour répondre à ces questions : une taxonomie pragmatique qui s'aligne avec les scénarios d'utilisation de l'IA qui intéressent nos clients. Nous élargissons donc la discussion au-delà de l'entraînement de l'IA pour nous concentrer sur trois scénarios d'utilisation de l'IA que nous souhaitons permettre à tous nos clients de traiter :

• Recherche : tout comportement qui collecte ou indexe votre contenu afin de pouvoir répondre ultérieurement à des questions le concernant. L'essentiel à saisir ici est que l'activité de recherche construit une base de données de votre site de manière proactive afin de pouvoir ensuite répondre aux requêtes. Les propriétaires de sites doivent s'attendre à recevoir du trafic référent ou à bénéficier d'une autre compensation équitable en conséquence.

• Agent : un comportement automatisé qui agit (généralement en temps réel) pour le compte d'une personne afin d'immédiatement réaliser une tâche. Cette catégorie inclut les bots de récupération de chat (p. ex., ChatGPT-User) et les agents d'utilisation de navigateur (p. ex., Gemini ou Claude sur Chrome). L'élément clé ici est que l'agent visite votre application web pour accomplir une tâche et qu'un utilisateur humain attend souvent à l'autre bout.

• Entraînement : un bot d'exploration qui utilise votre contenu pour entraîner ou affiner un modèle. L'idée clé ici est que vos données sont absorbées de manière permanente au sein de l'architecture sous-jacente de l'IA afin d'améliorer ses capacités.

De nombreux bots d'exploration populaires sur le web appartiennent à l'une des classes ci-dessus. Certains entrent même dans plusieurs catégories. Nous classifions de nombreux autres comportements au-delà des trois mentionnés ci-dessus, notamment la vérification des publicités, la récupération de flux et les transactions agentiques (nous reviendrons sur ce cas plus bas). Or, nous considérons qu'il devrait être simple pour tous les propriétaires de sites web de gérer l'accès à leur contenu pour ces trois scénarios d'utilisation axés sur l'IA. Nous pensons que les exploitants de bots devraient distinguer leurs bots d'exploration, car cette opération permet de générer davantage de transparence pour les propriétaires de sites web. Ces derniers peuvent ensuite mieux comprendre pour quelles raisons un bot donné se rend sur son site et dès lors mieux gérer l'accès qu'ils accordent à ce bot d'exploration. Nous encourageons fortement les entreprises à diviser leur processus d'automatisation en trois bots d'exploration distincts si ce dernier a pour tâche de construire des index de recherche, d'agir comme un agent et de collecter des données pour entraîner les modèles.

Nous souhaitons mettre en place un système de classification évolutif et représentatif de l'univers du trafic automatisé vers lequel il tend. Suivre les objectifs d'un bot n'est pas nouveau, mais notre nouvelle taxonomie inclut quelques mises à jour qui représentent mieux l'état actuel du trafic des bots. Nous souhaitons plus particulièrement reconnaître que les bots qui présentent plusieurs finalités doivent être suivis pour l'ensemble de ces dernières, et non pour une seule.

Nous souhaitons offrir davantage d'options de gestion des différents types de trafic IA à tous les propriétaires de sites web sur le réseau Cloudflare.

Le préréglage géré pour « Bloquer les bots IA » que nous avons annoncé par le passé incluait les bots à but unique qui exploraient les données à des fins d'entraînement des modèles, comme indiqué ci-dessous : 

^{Capture d'écran du paramètre existant de gestion du trafic lié aux bots IA le 1er juillet 2025.}

L'IA n'est toutefois pas toujours utilisée de la même manière et nous souhaitons que nos clients disposent des mesures de contrôle dont ils ont besoin. Nous lançons donc la possibilité de gérer le trafic IA en fonction de trois scénarios d'utilisation majeurs : la recherche (Search), les agents (Agents) et l'entraînement (Training). Grâce à ces nouvelles options, nos clients peuvent affiner la gestion du trafic lié aux bots, notamment les utilisateurs de notre offre gratuite.

^{Capture d'écran des nouvelles options de gestion du trafic lié aux bots IA le 1er juillet 2026.}

Le 15 septembre 2026, nous définirons de nouveaux paramètres par défaut pour chacune de ces trois classifications. Pour tous les nouveaux domaines qui intègrent le réseau Cloudflare, les catégories Entraînement et Agent seront bloquées par défaut sur les pages qui affichent des publicités, tandis que la classe Recherche restera autorisée par défaut. 

Une publicité est un signal qu'un propriétaire de site web a mis en place dans l'intention qu'un utilisateur accède à une page et voie la publicité, c'est-à-dire un élément monétisable conçu pour soutenir l'entreprise. Nous considérons donc l'attention humaine comme la finalité ultime sur ces pages et écartons les bots qui pourraient empêcher l'établissement de cette attention (c'est-à-dire les bots d'entraînement et les bots agents). D'autre part, la recherche constitue le comportement qui attire le plus naturellement les visiteurs et nous pensons qu'il va dans l'intérêt de la plupart des propriétaires de sites d'autoriser ce type d'activité.

Autre changement qui s'appliquera le 15 septembre : les bots d'exploration polyvalents (notamment ceux qui combinent recherche et entraînement) seront autorisés/bloqués en vertu de l'ensemble de leurs comportements, conformément à notre appel à davantage de transparence pour les propriétaires de sites web. Comme l'application des paramètres par défaut s'effectuera en fonction des règles les plus restrictives, les bots polyvalents (p. ex. Googlebot, Applebot et BingBot) seront bloqués par les clients qui ont choisi de bloquer l'activité d'entraînement (soit par l'intermédiaire des nouvelles options de gestion du trafic lié à IA, soit par le biais du service existant de blocage des bots IA).

Bien entendu, le choix du client demeure primordial : si un propriétaire de site web souhaite se désinscrire de ces nouvelles configurations par défaut, il peut facilement le mentionner dans ses paramètres de sécurité à tout moment avant le 15 septembre. Il confirmera dès lors qu'il ne souhaite aucun changement s'appliquer aux bots d'entraînement qui explorent également le contenu à des fins de recherche. Nous continuerons également à informer les clients de la modification à venir des paramètres par défaut à l'approche du 15 septembre afin de nous assurer que les clients qui souhaitent choisir des paramètres différents de ceux par défaut puissent le faire.

Nous nous réjouissons également de lancer une mise à jour majeure de la visibilité sous forme d'une nouvelle fonctionnalité de niveau Enterprise pour la gestion des bots. Plus le répertoire de bots suivis par Cloudflare s'est élargi, plus le désir de gérer ces bots en fonction de groupes logiques et de comprendre plus en détail un bot particulier a également augmenté. 

Nous vous présentons dès lors BotBase,notre nouvelle base de données qui répertorie l'ensemble des bots connus, y compris les bots et les agents vérifiés. Cette base de données assure une vue d'ensemble complète et consultable sur l'intégralité de notre répertoire de bots, directement sur le tableau de bord Cloudflare. Nous nous attaquons à la visibilité en premier lieu, mais nous étendrons BotBase plus tard cette année afin de vous proposer un centre de contrôle direct du contenu automatisé connu sur votre site web.

Grâce à cette nouvelle vue, les clients de niveau Enterprise de notre solution Bot Management peuvent consulter le catalogue complet de tous les bots/agents vérifiés et leur classification dans cette taxonomie mise à jour. Ils bénéficient dès lors d'une visibilité que nous n'avons jamais affichée de manière dynamique sur le tableau de bord Cloudflare auparavant. Les clients qui souhaitent cibler un bot spécifique avec précision peuvent aussi facilement filtrer l'ensemble du trafic issu de ce bot, et copier l'ID de détection à utiliser dans les règles de sécurité. Toutes ces fonctions sont désormais disponibles sur une page dédiée, elle-même accessible par l'intermédiaire de la carte de configuration de la solution Bot Management. 

En développant BotBase, nous souhaitions prendre en compte toutes les informations permettant de produire des informations puissantes et évolutives d'un bot à l'autre. L'un de ces éléments constitue une pierre angulaire de notre taxonomie mise à jour, basée sur ce qu'un bot peut faire sur votre site, c'est-à-dire son comportement. Nous distinguons ces différentes classes comme indiqué ci-dessous et chaque bot est classé selon un ou plusieurs de ces comportements.

^{Les lignes en gras et en italique indiquent les nouvelles options configurables disponibles pour l'ensemble de nos clients.}

Un autre élément d'information dont nous avons entendu dire par nos clients qu'il était important pour eux est l'utilisation du contenu par un bot, c'est-à-dire ce qu'un bot peut conserver et repartager après avoir exploré votre contenu. Pour aborder cette question, nous développons des capacités conçues pour que les clients de notre service Bot Management puissent sélectionner et bloquer ce qu'ils souhaitent en fonction de « l'utilisation du contenu ». Ce paramètre peut être défini selon trois niveaux, du moins permissif au plus permissif :

• immediate (immédiate) : interaction, mais sans stockage ni réutilisation

• reference (référence, par défaut) : indexation, créations d'extraits et de liens retour

• full (complète) : synthèse et reproduction

Ces valeurs peuvent être combinées aux classes de bots pour exprimer des règles plus nuancées, comme « autoriser tous les bots utilisés à des fins de recherche, de SEO et de vérification des publicités, mais uniquement jusqu'au niveau d'utilisation référence. » Cette possibilité permet aux propriétaires de sites web de prendre des décisions par groupes homogènes plutôt que de gérer les règles bot par bot.

Pour aller plus loin dans ce sens, nous testons un nouveau signal (use) à partir d'aujourd'hui. Ce dernier étend les signaux de contenu (Content Signals) et réside dans votre fichier robots.txt. Cet ajout étend les trois champs de la première version des signaux de contenu par un quatrième champ facultatif qui exprime la même préférence que ci-dessus :

• use=immediate

• use=reference

• use=full

Comme pour tous les autres éléments listés dans le fichier robots.txt, les valeurs de contenu signalent la préférence du propriétaire du site web plutôt que de procéder directement au blocage. Nous ajoutons aujourd'hui la prise en charge de cette extension : tous les clients qui ont déjà activé le fichier géré robots.txt (qui précise ci-dessous que l'exploration est autorisée pour la recherche, mais pas pour l'entraînement) verront désormais la préférence supplémentaire use=reference ajoutée à leur fichier robots.txt.

# Cloudflare Managed content with original Content Signals

User-agent: *
Content-Signal: search=yes,ai-train=no
Allow: /

^{Le contenu du fichier robots.txt géré par Cloudflare, avec les valeurs originales des signaux de contenu.}

# Cloudflare Managed content with the new content-use signal

User-agent: *
Content-Signal: search=yes,ai-train=no,use=reference
Allow: /

^{Le contenu du fichier robots.txt géré par Cloudflare avec le paramètre ajouté.}

Nous commençons aussi à suivre l'utilisation du contenu pour chaque bot dans BotBase. Le bot perdra le statut « Vérifié » lorsque nous découvrons qu'il abuse de ces signaux, ce qui entraînera son interdiction. Les bots qui reproduisent intégralement le contenu ne peuvent pas avoir le statut Vérifié à l'heure actuelle.

En ce qui concerne le statut « Vérifié », la définition de la vérification est mise à jour pour refléter les prochains changements comparés aux critères par défaut Autoriser et Bloquer. Auparavant, tous les bots vérifiés étaient autorisés par défaut. Cette situation était reflétée dans notre offre de base Bot Fight Mode afin de bloquer le trafic automatisé indésirable et dans nos modèles de règles pour les clients Enterprise du service Bot Management. 

À compter d'aujourd'hui, nous ajustons ce mode de fonctionnement afin d'ajouter de la nuance : les bots non vérifiés demeurent par défaut bloqués, mais nous ne considérons plus les bots vérifiés comme « autorisés par défaut ». L'étiquette « Vérifié » permet désormais à un bot d'être autorisé en fonction de sa catégorie pertinente, c'est-à-dire que la catégorie autorisée (p. ex., autoriser l'activité Recherche) déterminera quels bots sont autorisés à accéder à un site web.

Pour équilibrer ce changement, nous ouvrons le processus visant à permettre à un bot d'obtenir le statut Vérifié et le rendons également plus transparent. Pour « vérifier » un bot, l'entité qui exploite ce dernier doit démontrer deux choses : que le bot se présente de manière honnête et qu'il n'abuse pas de l'accès que cette honnêteté lui confère. Enfin, nous développons actuellement des outils de gestion pour faciliter la tâche aux exploitants de bots et leur permettre d'assurer une représentation précise au sein du système de classification Cloudflare (à annoncer prochainement). 

^{Une capture d'écran de la plateforme à venir, conçue directement pour les exploitants de bots qui font partie ou souhaitent faire partie de BotBase, la nouvelle génération de l'annuaire des bots Cloudflare.}

Autre élément de l'équation : le bot (ou l'agent) à votre porte n'est de plus en plus souvent pas géré par l'entreprise qui l'a développé. Une plateforme comme la Cloudflare Developer Platform exécute des automatisations pour des milliers d'exploitants différents en même temps, qui vont des entreprises aux développeurs dont vous n'avez jamais entendu parler. Vous pouvez faire confiance à Stripe, mais vous n'avez pas nécessairement à faire confiance à tous les utilisateurs qui ont intégré les outils Stripe à un projet personnel (weekend project).

Nous considérons le scénario « propriétaire de site → entreprise détentrice du bot → utilisateur final » comme une question de confiance transitive et proposons d'utiliser l'en-tête Forwarded (Transféré) existant, tel que défini dans la RFC 7239. Cet en-tête accompagne la requête et permet aux « composants proxy de divulguer des informations perdues dans le processus de mise en proxy ». 

Il se révèle similaire à ce qu'effectue l'en-tête X-Forwarded-For pour les adresses IP ou l'en-tête X-Forwarded-Host pour préserver l'en-tête Host original. Ainsi, lorsque le propriétaire d'un site web déclare « Autoriser cet exploitant », la préférence restera en place, que l'entité exploitante vienne directement à vous ou par l'intermédiaire de trois couches d'intermédiaires de confiance. Vous trouverez davantage de détails dans notre documentation, avec un bref exemple de présentation du format ci-dessous.

Forwarded: for="openai"

En ajoutant l'extension comportant le paramètre « content-use » dont nous avons discuté ci-dessus, l'ajout de l'en-tête précisant la manière dont l'entité exploitante indique qu'elle utilisera le contenu auquel elle accède ressemblerait à ce qui suit :

Forwarded: for="openai";use="reference"

Cette approche aligne également le modèle incitatif que nous souhaitons encourager. Le fait de perdre le statut « de confiance » sur plus de 20 % des domaines web situés derrière Cloudflare constitue un puissant moyen de dissuasion. La confiance devient une qualité qui peut vous accompagner et que vous pouvez perdre.

Toutefois, à l'heure où le trafic lié aux bots se mêle au trafic d'origine humaine, il est possible que ce système de confiance transitive ne s'étende pas au-delà des utilisateurs qui peuvent se permettre d'être identifiables. Les mesures que nous proposons aujourd'hui aident à instaurer cette confiance, mais elles ne conviendront pas toujours à l'ensemble du web. Les petites sources de trafic ont besoin de confidentialité, et les entreprises qui souhaitent préserver leurs engagements en matière de respect de la vie privée doivent avoir la possibilité d'explorer des éléments constitutifs équitables pour l'avenir d'un Internet agentique, comme le contrôle du volume des requêtes.

Il s'agit là de petits changements qui vont dans la même direction : permettre aux propriétaires de sites d'obtenir davantage de contrôle sur qui utilise leur contenu et de quelle manière. Nous pensons que les nouveaux paramètres par défaut dont nous avons discuté aujourd'hui et que nous allons bientôt mettre en œuvre encouragent la transparence et reflètent davantage la direction que prend le monde.

Bien entendu, les fluctuations d'Internet continueront de survenir sous nos yeux et nous devrons nous adapter constamment. Mais la direction générale ne changera pas, car il s'agit toujours de celle avec laquelle Cloudflare a commencé : un écosystème web bâti autour de la confiance. Un écosystème au sein duquel les créateurs peuvent décider de la manière dont leurs créations sont utilisées et dans lequel faire preuve d'honnêteté sur ses intentions permet de disposer de davantage d'accès, pas d'un accès réduit.

Ces nouvelles options de gestion du trafic lié à l'IA sont désormais disponibles et peuvent être configurées par tous les clients existants dans leurs paramètres de zone. Votre site n'est pas encore sur Cloudflare ? Souscrivez à notre offre gratuite et définissez les mesures de contrôle du trafic que vous souhaitez dès aujourd'hui.

Bonne Journée de l'indépendance du contenu.

Les propriétaires de sites web alimentent l'écosystème d'idées, d'actualités et de nouvelles intéressantes, mais ils doivent faire face à la problématique de plus en plus complexe qui consiste à gérer le trafic à destination de leurs sites web et d'être rémunérés pour leur contenu. Si certains types de trafic lié aux bots sont clairement malveillants, il n'est cependant pas toujours évident de savoir si un bot d'exploration IA particulier soutient l'activité de votre entreprise ou lui nuit. Pour répondre à cette question, les propriétaires de sites ont besoin de données fiables et granulaires pour différencier le trafic qui génère de la valeur du trafic qui épuise les ressources, tout en érodant la base de leur modèle économique, c'est-à-dire les utilisateurs humains qui consomment leur contenu. 

Cloudflare perpétue une de ses convictions fondamentales : les propriétaires de sites web ont le droit de contrôler l'accès à leur contenu. Nous souhaitons aider ces derniers à maintenir le haut degré de qualité de leur contenu, ainsi qu'à réguler le trafic en lien avec l'IA.

C'est pourquoi nous nous réjouissons d'annoncer le nouveau tableau de bord Attribution Business Insights (informations opérationnelles sur l'attribution), conçu pour les décisionnaires des entreprises et les éditeurs, afin de proposer la clarté nécessaire aux propriétaires de sites et de les aider à prendre le contrôle.

Le modèle économique de l'Internet reposait depuis des décennies sur un accord tacite et simple : les propriétaires de sites web permettaient aux moteurs de recherche d'explorer leur contenu et, en retour, les moteurs de recherche redirigeaient les lecteurs vers leurs pages. Cette relation symbiotique (dans laquelle les moteurs de recherche traditionnels fonctionnaient avec un rapport « explorations/renvois » à l'équilibre) générait les visites de pages nécessaires au soutien de la publicité, des revenus d'affiliation et des abonnements. Les bots d'exploration peuvent analyser votre contenu plusieurs fois pour chaque occurrence de trafic référent. Le fait de rendre votre site web accessible aux bots d'exploration vous permet ainsi de bénéficier d'un canal direct vers des revenus supplémentaires. Nous pouvons considérer cette situation comme l'ère du SEO (Search Engine Optimization, optimisation pour les moteurs de recherche).

La montée en flèche des bots d'exploration et des agents IA a désormais rompu ce contrat et plongé le secteur de l'édition numérique dans une crise sans précédent. L'Internet risque une transition vers un écosystème « zéro clic », au sein duquel les chatbots IA extraient du contenu original afin de synthétiser des réponses instantanées, en contournant dès lors totalement les sources. Nous observons déjà une mutation de l'ensemble du paysage, qui passe d'un monde exclusivement basé sur le SEO à un univers axé sur l'AEO (Answer Engine Optimization, optimisation pour les moteurs de réponse), mais les discussions autour du GEO (optimisation pour les moteurs génératifs) occupent désormais le devant de la scène.

L'instabilité de cette nouvelle réalité ressort clairement des rapports explorations/renvois que nous observons actuellement sur l'ensemble du réseau Internet. Là où les moteurs de recherche traditionnels présentaient un ratio plus équilibré d'explorations par rapport aux renvois de visiteurs légitimes, les principaux bots d'exploration l'IA opèrent à une échelle radicalement différente et extractive. Nous avons ainsi observé toute une gamme de rapports explorations/renvois en ce qui concerne les bots utilisés par les principales entreprises de développement d'IA, d'un minimum de 118:1 à un maximum de près de 50 000:1 aux alentours de la Journée de l'indépendance du contenu que nous avons lancée en 2025. En d'autres termes, un bot d'exploration IA a peut-être exploré votre contenu premium des dizaines de milliers de fois pour finalement ne vous rapporter qu'un seul visiteur. Ce rapport est donc fondamentalement injuste.

Cette situation frappe doublement les éditeurs. Dans un premier temps, ils perdent un trafic référent crucial, le revenu des pages vues comportant une publicité, ainsi que les relations directes avec le public qui financent la création de contenu et le journalisme. Dans un deuxième temps, ils se voient contraints de supporter les coûts d'infrastructure croissants liés à l'hébergement et à la diffusion du contenu aux bots automatisés, qui ne leur offrent aucune valeur commerciale en retour. L'époque où il était logique d'autoriser le trafic de l'ensemble des bots d'exploration dans l'espoir que son contenu soit indexé est révolue.

Nous souhaitons que les propriétaires de sites web disposent de faits, de chiffres bruts et précis, afin de mieux comprendre quels bots soutiennent l'activité de leur entreprise et quels bots lui nuisent. Nous souhaitons également rendre cette analyse plus facile que jamais. Nous avons ainsi conçu le service Attribution Business Insights pour réduire le bruit et permettre à nos clients de se concentrer sur les détails qu'ils nous ont indiqués comme étant les plus importants. 

Le tableau de bord Attribution Business Insights est désormais disponible pour tous les clients de la solution Cloudflare Bot Management. Ce nouveau tableau de bord est conçu pour vous assurer une vue ciblée du trafic lié aux bots vers votre site web. Contrairement aux outils d'analyse traditionnels (qui peuvent nécessiter un filtrage manuel approfondi), cet outil vous propose immédiatement des informations essentielles.

Nous nous sommes engagés à répondre aux questions les plus pressantes auxquelles les propriétaires de sites doivent faire face aujourd'hui. Comment devez-vous envisager le trafic lié à l'IA qui circule sur vos sites web ? Quelle est la valeur de vos différents publics (c'est-à-dire les utilisateurs humains, les bots sans lien avec l'IA et les bots utilisés par l'IA) ? Et, surtout, à quelles fins vos données sont-elles utilisées par l'IA ? 

^{La nouvelle vue du tableau de bord Attribution Business Insights, qui inclut des informations sur le trafic de bots général, un rapport explorations/renvois à l'échelle du site et la répartition du trafic des bots IA par rapport au trafic organique.} 

Pour répondre à ces questions, le tableau de bord affiche une vaste gamme de données et d'informations :

• Trafic lié aux bots vers les pages de contenu : consultez votre trafic de bots général par rapport à celui d'origine humaine, ainsi que le volume de l'ensemble des bots qui accèdent avec succès à votre contenu.

• Rapports explorations/renvois : consultez le rapport explorations/renvois de l'ensemble de votre site sur une échelle de 24 heures, 7 jours ou 30 jours. Vous pouvez également voir les rapports explorations/renvois des différentes entités exploitantes de bots (par entreprise possédant un ou plusieurs bots).

• Répartition des principaux bots : découvrez la liste des principaux bots par volume. La liste inclut leur pays d'origine, la bande passante qu'ils occupent sur votre site web et leur statut actuel sur ce dernier (blocage/autorisation).

• Classification actualisée du comportement des bots d'exploration : nous allons au-delà de la seule étiquette générique de « bot d'exploration IA » en classifiant les bots selon les catégories de notre taxonomie actualisée, à savoir Entraînement (c'est-à-dire les tâches d'entraînement de la prochaine version d'un chatbot reposant sur un LLM), Recherche (c'est-à-dire les fins visant à mettre à jour les bases de données pour la génération augmentée par récupération, en anglais Retrieval-Augmented Generation ou RAG), ou la catégorie Agent (c'est-à-dire les bots utilisés dans les interactions agentiques visant à renvoyer des réponses à l'utilisateur final).  

Vous ne devriez pas avoir besoin d'être un expert de la sécurité pour comprendre de quelle manière les bots d'exploration IA affectent votre entreprise. Les propriétaires de sites web qui souhaitent seulement consacrer quelques minutes à ingérer les informations de haut niveau peuvent obtenir un aperçu clair de l'efficacité de leur politique de sécurité du contenu.

Nous proposons également une vue plus détaillée et organisée par entité exploitante de bot pour ceux qui souhaitent approfondir le sujet afin de mieux comprendre de quelle manière les entreprises de développement d'IA utilisent leur contenu (ou collecter des informations qui serviront à orienter l'établissement de leurs relations avec les entreprises de l'IA.

^{Analyse de l'activité des bots sur un site web, avec les détails importants sur chaque bot, comme le type, le rapport explorations/renvois et l'action en cours.} 

Grâce à une vue consolidée des entreprises qui cherchent à accéder au contenu de votre site web, vous pouvez disposer d'une meilleure base concernant l'activité des bots d'exploration. Nous souhaitons que ces données permettent à nos clients d'aborder n'importe quelle discussion commerciale ou opérationnelle sur le sujet en ayant les faits de leur côté. Elles pourraient, par exemple, vous permettre d'indiquer à l'entreprise 1 que son volume d'exploration est vingt fois supérieur à celui de l'entreprise 4 et que cette dernière vous rémunère pour l'accès à votre contenu. Vous pourriez également revoir la manière dont l'entreprise 2 peut acquérir une licence pour l'accès à votre contenu en fonction de ses activités récentes. Ce nouveau tableau de bord vous permettra de soutenir toutes vos discussions professionnelles. 

Comment ce nouveau niveau de visibilité s'intègre-t-il aux outils existants dont vous disposez pour protéger votre site web contre les abus ? Conformément aux autres fonctionnalités de gestion des bots, l'étape Action se déroule toujours dans le cadre des règles de sécurité. Afin d'éviter de générer du bruit dans votre interface de contrôle, Le tableau de bord Attribution Business Insights est conçu pour se comporter comme un centre d'analyses réfléchies et filtrées plutôt que comme un énième lieu d'action. Il sert dès lors de source centrale d'informations afin de vous permettre d'examiner les faits avant de décider d'une action dans le même moteur de règles que celui qui régit vos autres mesures d'atténuation des abus. Nous souhaitons inviter clairement et distinctement les décisionnaires des entreprises à utiliser ce tableau de bord afin qu'ils puissent constater par eux-mêmes que les discussions autour du trafic lié à l'IA concernent un ensemble plus large de parties prenantes que les seuls utilisateurs spécialisés en sécurité.

Le tableau de bord Attribution Business Insights constitue la prochaine étape essentielle dans le processus qui vise à proposer la transparence et le contrôle nécessaires aux propriétaires de sites web pour gérer l'évolution des menaces liées aux bots utilisés par l'IA et, dans une mesure plus large, façonner les nouvelles dynamiques d'Internet. Nous sommes déjà en train de travailler avec des partenaires de confiance du secteur de l'édition sur la prochaine itération qui permettra de créer un plan de visibilité couvrant la sécurité du point de vue des propriétaires de sites web qui disposent de contenu original et précieux à partager. 

Un aperçu ci-dessous présente une nouvelle vue conçue pour analyser l'activité des bots d'exploration par article et ainsi révéler l'appétence des entreprises de développement d'IA pour les divers types de contenu, les différentes campagnes, etc.

^{Répartition des articles les plus populaires en fonction du volume de trafic. La vue présente des indicateurs clés, comme le trafic lié aux bots utilisés par l'IA par rapport aux autres formes de trafic de bots et au trafic d'origine humaine, à la fois direct et provenant d'un renvoi.}  

La visibilité constitue le premier élément, mais de nouveaux outils et développements sont en cours pour permettre aux propriétaires de sites web de reprendre le contrôle de leur contenu dans la nouvelle ère qui s'ouvre. Nous encourageons tous les clients de la solution Cloudflare Bot Management (notamment ceux qui soutiennent des discussions professionnelles) à accéder dès aujourd'hui à cet outil pour découvrir un nouveau point de vue sur les analyses. 

Il y a douze ans ce mois, Cloudflare a lancé un projet ambitieux fondé sur une idée simple : personne ne devrait être privé d’accès à Internet sous prétexte qu’une entité plus puissante n’est pas d’accord avec lui. Aujourd’hui, le projet Galileo propose un accès gratuit à des services de cybersécurité à plus de 3 400 sites web appartenant à des journalistes, à des défenseurs des droits humains et à d’autres organisations à but non lucratif dans 120 pays. Nous continuons de croire qu’un Internet meilleur est un Internet où toute personne ayant une idée peut s’adresser à un public mondial. 

Chaque année, à l’occasion de l’anniversaire du projet Galileo, nous annonçons de nouveaux produits, programmes et partenariats stratégiques. Pour célébrer notre douzième anniversaire cette année, nous publions notre premier rapport exhaustif consacré aux cyberattaques ciblant la société civile, nous diffusons également des études de cas qui explorent les besoins de sécurité de 16 organisations participant au projet Galileo, et nous annonçons l’intégration de nouveaux partenaires au projet.

Parce que le projet Galileo regroupe désormais 3 400 domaines appartenant à des organisations originaires de plus de 120 pays, Cloudflare dispose d’un accès à des données uniques concernant les cybermenaces, les attaques et les tendances ciblant la société civile, qui constitue un pilier essentiel de la démocratie mondiale. En outre, parce que le réseau Cloudflare couvre plus de 335 villes dans 125 pays et protège plus de 20 % du web, nous avons également pu comparer les attaques ciblant la société civile à celles qui visent Internet de manière plus générale. Vous pouvez consulter le rapport intégral ici.

Les données recueillies cette année révèlent que les organisations de la société civile ont été ciblées plus fréquemment, et souvent de manière plus intense, que les autres utilisateurs d’Internet. Les cyberattaques ont souvent coïncidé avec des moments critiques dans le travail de la société civile, tels que la publication de rapports d’investigation ou la conduite d’activités de sensibilisation du public. Nos conclusions essentielles sont les suivantes : 

• Les attaques DDoS constituaient la cybermenace la plus couramment employée contre la société civile. Leur principale caractéristique était leur durée, certaines ayant perduré pendant plusieurs jours, voire plusieurs semaines.

• Les organisations de la société civile ont été confrontées à des tentatives d’exploitation des failles de sécurité de leurs sites web sept fois plus fréquentes que les autres clients de Cloudflare. Les organisations de médias ont été ciblées de manière disproportionnée.

• Les journalistes travaillant en exil ont été confrontés à un taux de trafic malveillant près de quatre fois supérieur à celui des organismes de presse dans leur ensemble. 

• Près de 10 % de l’ensemble des e-mails traités par Cloudflare pour le compte de la société civile contenaient des éléments susceptibles de constituer une tentative de phishing. 

Nous concluons notre rapport par un appel à l’action : garantir à tous une cybersécurité simple et abordable, renforcer la transparence concernant les cyberattaques et les coupures d’Internet, et intégrer par défaut l’IA et les mesures de protection post-quantiques aux outils de sécurité. Nous espérons que ce rapport pourra constituer une ressource à l’intention de la société civile, des décideurs politiques et du grand public désireux de comprendre les cyberattaques et d’y répondre. À l’avenir, nous avons l’intention de publier ce rapport une fois par an, ce qui nous permettra de comparer l’évolution des tendances concernant les cybermenaces au fil du temps. 

En plus du rapport, Cloudflare a publié les études de cas qualitatives suivantes, qui permettent de contextualiser les besoins de sécurité de chaque organisation.

Le succès du projet Galileo repose sur ses 59 partenaires issus de la société civile. Chaque organisation demandant à s’inscrire au programme fait l’objet d’un examen et d’une validation par l’un de ces partenaires. Ces groupes contribuent bénévolement leur temps et leur expertise, examinant souvent plusieurs demandes d’inscription par jour, afin de s’assurer que nos services sont fournis exclusivement aux organisations qui le méritent. 

Au fil du temps, ces relations ont non seulement contribué à faire du projet Galileo le programme qu’il est aujourd’hui, mais elles ont également donné naissance à des initiatives entièrement nouvelles, telles que notre partenariat de sécurité du courrier électronique avec Protect.ngo (anciennement CyberPeace Institute) ou notre action en faveur de la mesure de la qualité d’Internet dans les écoles publiques, à travers le projet Giga de l’UNICEF.

Depuis plusieurs années, l’un de nos objectifs pour le projet Galileo est d’en étendre la portée à davantage d’organisations situées dans des régions hors de l’Amérique du Nord et de l’Europe. Dans le cadre de cette démarche, nous avons notamment participé à des événements régionaux, tels que RightsCon au Costa Rica (2023) et à Taïwan (2025), afin de dialoguer directement avec les organisations locales de défense des droits numériques. Nous avons également accueilli de nouveaux partenaires qui apportent au programme leurs propres réseaux et communautés actifs. À titre d’exemple, l’année dernière, nous avons annoncé deux nouveaux partenaires dans la région Asie-Pacifique : EngageMedia et OpenCulture Foundation.

Compte tenu des nouveaux services que nous avons récemment ajoutés au projet Galileo afin d’aider les organes de presse locaux à protéger leurs contenus contre les robots d’indexation pilotés par IA, cette année, notre partenariat a priorisé les groupes qui opèrent au service des journalistes. À cette fin, nous sommes fiers d’annoncer l’intégration de trois nouveaux partenaires :

Le nouveau rapport, les études de cas et les nouveaux partenaires présentés aujourd’hui ont tous pour finalité de contribuer à la réalisation de l’objectif fondamental du projet Galileo : veiller à ce que les cyberattaques ne réduisent pas au silence les organisations œuvrant dans des secteurs vulnérables et essentiels, tels que le journalisme et les droits humains. 

Tandis que nous nous tournons vers l’avenir, nous restons déterminés à trouver de nouveaux moyens d’étendre nos mesures de protection aux groupes vulnérables dans le monde entier. Si votre organisation souhaite bénéficier de la protection offerte par le projet Galileo, veuillez consulter la page cloudflare.com/galileo.

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.