Pourquoi Managed Agents a besoin d'une infrastructure distribuée

Le lancement par Anthropic de Claude Managed Agents cette semaine a secoué le marché, certains y voyant une menace directe pour les entreprises d'infrastructure et un impact potentiel pour des acteurs comme Akamai. Je comprends cette réaction : lorsqu'un fournisseur de modèles avec l'influence d'Anthropic annonce un service hébergé, le réflexe est de supposer que la couche infrastructure va être contournée. Mais cette interprétation passe à côté de ce qu'Anthropic a conçu et de ce dont sa solution a réellement besoin pour fonctionner à l'échelle de l'entreprise.

Lisez attentivement leur article qui explique l'ingénierie de la solution. Managed Agents est un service hébergé qui exécute pour votre compte des agents visant à opérer dans la durée, grâce à un nombre limité d'interfaces pensées pour traverser les évolutions d'implémentation. L'équipe d'Anthropic a virtualisé les composants d'un agent (session, harnais et sandbox) de sorte que chacun puisse être remplacé indépendamment. Elle a fait le choix de concevoir pour un avenir qu'elle admet ouvertement ne pas pouvoir prédire : le défi consistait à « concevoir un système pour des programmes encore inconcevables ».

Il ne s'agit pas d'un substitut à l'infrastructure, au contraire : cela en démultiplie la demande.

L'équipe d'ingénierie d'Anthropic décrit une décision architecturale fondamentale : dissocier le « cerveau » (Claude et son harnais) des « mains » (sandbox et outils qui effectuent des actions). Cette séparation rend possible ce qu'ils appellent « plusieurs cerveaux, plusieurs mains ». Une seule session d'agent peut générer plusieurs appels d'inférence et plusieurs environnements d'exécution, opérant en parallèle, sur différents emplacements et différentes ressources.

La phrase qu'il faut retenir de l'article, c'est qu'Anthropic ne présuppose ni le nombre ni l'emplacement des cerveaux ou des mains dont Claude aura besoin. Ce n'est pas une remarque anodine. Cela indique clairement que la couche infrastructure (là où s'exécutent l'inférence, les sandbox et les outils) est délibérément laissée ouverte. Anthropic a créé l'orchestration. La structure de calcul sous-jacente est exactement ce que des entreprises comme Akamai fournissent.

Cela correspond directement à l'architecture d'inférence distribuée que nous avons présentée lors de la conférence NVIDIA GTC à San Jose, en mars 2026. Notre thèse, selon laquelle l'inférence d'IA en production (en particulier les flux de travail agentiques nécessitant des réponses à faible latence, un raisonnement en plusieurs étapes et des appels d'outils en temps réel) exige une approche différente des usines d'IA centralisées, est précisément ce dont Managed Agents a besoin pour fonctionner à l'échelle de l'entreprise.

Les usines d'IA excellent dans l'entraînement des modèles de base et dans les charges de travail GPU massives et simultanées. Cependant, lorsque Managed Agents déclenche cinq « cerveaux » parallèles, chacun devant appeler des outils, exécuter du code et renvoyer des résultats dans des contraintes de latence propres à une application en temps réel (n'oubliez pas qu'Anthropic conçoit pour des « programmes encore inconcevables »), cela requiert alors des GPU répartis dans toutes les zones géographiques, connectés par un réseau haut débit, avec des mécanismes de sécurité appliqués à chaque couche.

C'est là qu'Akamai Inference Cloud entre en jeu. Des clusters GPU centralisés pour l'entraînement et le réglage précis, aux GPU NVIDIA RTX PRO™ 6000 Blackwell Server Edition distribués pour l'inférence en production, jusqu'aux points de présence en bordure de l'Internet pour le routage, la mise en cache et la sécurité, notre continuum de ressources de calcul est conçu spécifiquement pour ce type de charge de travail.

On ne peut pas dépasser la vitesse de la lumière : un utilisateur à Londres qui appelle un point d'inférence basé dans l'État de Virginie connaît un délai de propagation d'environ 28 millisecondes dans chaque sens, avant même qu'un seul jeton ne soit généré. Multipliez cela par le nombre d'appels d'inférence séquentiels d'un flux de travail agentique, et l'inférence centralisée est alors inutilisable pour des applications en temps réel.

L'équipe d'ingénierie d'Anthropic s'est exprimée avec une franchise remarquable sur les défis de sécurité liés aux agents gérés. Dans la conception couplée, tout code non fiable généré par Claude s'exécutait dans le même conteneur que les informations d'identification. Une simple injection de prompt suffisait alors à convaincre Claude de lire son propre environnement. Une fois ces jetons récupérés, un attaquant pouvait créer de nouvelles sessions sans restriction et déléguer des tâches aux agents gérés.

L'équipe a corrigé ce problème structurel en séparant les informations d'identification de la sandbox. Elle a toutefois reconnu une tension fondamentale : restreindre le périmètre est une mesure d'atténuation évidente, qui suppose néanmoins de savoir ce que Claude ne pourra pas faire avec un jeton limité, alors même que Claude devient chaque jour plus intelligent.

C'est là que nous pensons que le portefeuille de solutions de sécurité d'Akamai devient non seulement pertinent, mais essentiel. Lorsque les entreprises déploient Managed Agents en production, ces agents capables d'effectuer de manière autonome des tâches en plusieurs étapes, d'appeler des API externes, de générer et d'exécuter du code et d'interagir avec des systèmes internes étendent considérablement la surface d'attaque. L'injection de prompt, la génération de code malveillant, le vol d'identifiants, les mouvements latéraux et l'exfiltration de données deviennent des risques opérationnels bien réels, appelés à se manifester à l'échelle des « programmes encore inconcevables ».

Akamai Firewall for AI protège les points de terminaison LLM (grands modèles de langage) contre l'injection de prompt et les abus de modèles. Akamai API Security identifie, cartographie et surveille les appels d'API effectués par les agents vers des outils et services externes. Akamai App & API Protector, notre pare-feu d'application web, inspecte le trafic entre les agents et les applications avec lesquelles ils interagissent. Akamai Guardicore Segmentation limite ce qu'un agent (ou un agent compromis) peut atteindre au sein du réseau d'une entreprise. Enfin, Akamai Bot Manager distingue le trafic d'agents légitimes des automatisations malveillantes qui imitent le comportement des agents.

Il est peu probable que les fournisseurs de modèles (y compris Anthropic) développent toutes ces capacités. Ils se concentrent plutôt sur la couche d'orchestration. La protection à l'exécution, la sécurité réseau et l'application de règles au niveau de l'infrastructure sont la spécialité des entreprises comme Akamai, et c'est ce dont les entreprises auront besoin avant de déployer des agents autonomes sur des systèmes de production qui manipulent des données clients, des transactions financières et des opérations critiques.

Dans un premier temps, le marché a réagi comme si Anthropic avait annoncé le remplacement des CDN, du cloud et des infrastructures de sécurité par Managed Agents. Nous pensons exactement l'inverse.

Chaque session de Managed Agents exécutée en production nécessite des ressources de calcul pour l'inférence (demande pour Akamai Inference Cloud), une connectivité réseau et du routage (demande pour la plateforme en bordure de l'Internet et l'infrastructure d'Akamai), des mécanismes de sécurité aux niveaux applicatif, API et réseau (demande pour le portefeuille de solutions de sécurité d'Akamai) et une orchestration sur des emplacements distribués (demande pour le continuum de calcul que nous continuons de développer).

Rappelez-vous ce qui s'est passé lors de l'émergence du Cloud Computing. AWS n'a pas éliminé le besoin de CDN, de solutions de sécurité et d'Edge Computing. Il a au contraire multiplié les applications, le trafic et les surfaces d'attaque, renforçant la demande pour les services que propose Akamai. Nous pensons que les agents gérés suivront la même trajectoire. Plus il y a d'agents, plus il y a d'appels d'inférence, d'interactions API, d'exigences de calcul distribué et d'exposition aux menaces. Nous entendons être l'infrastructure qui les propulse.

En l'espace d'une seule semaine, deux annonces de la même entreprise (Project Glasswing et Claude Managed Agents) ont illustré les deux faces de l'équation sécurité et infrastructure de l'IA. Glasswing accélère la détection des vulnérabilités, ce qui renforce le besoin de protection à l'exécution pendant l'intervalle entre la divulgation et la correction. Managed Agents rend possibles les flux de travail d'IA autonomes à grande échelle, ce qui renforce le besoin d'une infrastructure d'inférence distribuée et de mécanismes de sécurité appliqués à chaque couche de la pile.

Ces deux initiatives renforcent la pertinence de ce qu'Akamai conçoit. Notre réseau, nos données, notre portefeuille de solutions de sécurité et notre plateforme de calcul distribué ne sont pas menacés par ces innovations. Selon nous, elles exigent les solutions d'Akamai. Chaque nouvelle vulnérabilité découverte doit être protégée en production jusqu'au déploiement d'un correctif. Chaque nouvel agent déployé en production nécessite des ressources d'inférence, une structure réseau et des contrôles de sécurité que le fournisseur de modèle ne fournit pas ; mais Akamai, oui.

Le réseau en bordure de l'Internet, les capacités de protection à l'exécution et l'infrastructure d'inférence distribuée d'Akamai sont conçus pour faire le lien entre ce que l'IA rend possible et ce dont les entreprises ont besoin pour déployer l'IA en toute sécurité et à grande échelle. Ce lien n'a jamais été aussi vital qu'aujourd'hui.

Cet article contient des déclarations prospectives au sens de la Section 27A du Securities Act of 1933, tel que modifié, et de la Section 21E du Securities Exchange Act of 1934, tel que modifié. Ces déclarations comprennent, sans s'y limiter, des déclarations concernant la demande attendue pour l'infrastructure distribuée et les produits de sécurité d'Akamai, stimulée par le déploiement d'agents d'IA, le positionnement concurrentiel du portefeuille de solutions cloud et d'Inference Cloud d'Akamai, la croissance anticipée de l'adoption d'agents d'IA gérés par les entreprises, ainsi que nos plans et stratégies de développement produit et de positionnement sur le marché. Les termes « pensons », « entendons », « voulons », « estimons » et des expressions similaires désignent ces déclarations prospectives. Ces déclarations reposent sur les attentes et hypothèses actuelles, et sont soumises à des risques et incertitudes susceptibles d'entraîner des résultats réels sensiblement différents, notamment : le rythme et l'ampleur de l'adoption par les entreprises des technologies d'agent d'IA ; l'évolution du paysage concurrentiel des services d'infrastructure et de sécurité pour l'IA ; le rythme de développement des capacités d'IA par des tiers ; les taux d'adoption par les clients d'Akamai Inference Cloud et des solutions de sécurité d'Akamai ; l'efficacité de nos produits face à l'évolution des menaces de sécurité liées à l'IA ; les conditions économiques et de marché générales ; ainsi que d'autres facteurs décrits dans nos documents déposés auprès de la SEC, y compris notre dernier formulaire 10-K annuel. Nous déclinons toute obligation de mettre à jour ces déclarations prospectives pour tenir compte d'événements ou circonstances survenus après la date de publication du présent article.