Bienvenue dans l’Agents Week

Cloudflare s’est toujours donné pour mission de contribuer à bâtir un Internet meilleur. Parfois, cette approche implique de développer des solutions pour l’Internet tel qu’il existe. Parfois, il s’agit de construire pour l’Internet tel qu’il est sur le point de devenir. 

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.