« Une architecture évolutive pour gérer le rythme des changements en IA »

L'infrastructure IA doit évoluer pour l'expérience des agents (Akshat Bubna, CTO de Modal)

Modal, la plateforme cloud spécialisée dans l'infrastructure pour l'intelligence artificielle, vient de boucler une levée de série C de 355 millions de dollars, un signal fort de la traction prise par l'entreprise depuis sa série A de seulement 17 millions de dollars il y a deux ans. Dans un épisode du podcast Latent Space, le directeur technique de Modal, Akshat Bubna, est revenu avec les animateurs swyx et Vibhu sur l'évolution de la plateforme, née comme un simple runtime plus performant avant de devenir un cloud entièrement pensé pour les charges de travail liées à l'IA. Bubna y détaille l'arsenal technique déployé par Modal: fonctions serverless, infrastructure pilotée par décorateurs, inférence élastique pour des modèles personnalisés en audio, vidéo, robotique et biologie computationnelle, snapshotting de GPU, décodage spéculatif via une technologie maison baptisée DeFlash, ainsi que des sandboxes réseau avec adressage IPv6 privé et support RDMA pour l'entraînement multi-nœuds. Modal s'appuie désormais sur un pool de capacité réparti chez 17 fournisseurs cloud différents, une stratégie de "supercloud" censée absorber les pics de demande propres aux workloads d'IA. L'argument central de Bubna est que l'infrastructure cloud historique, conçue pour des développeurs humains capables de lire une documentation, de raisonner sur du YAML et d'interpréter un tableau de bord, ne convient plus à l'ère des agents autonomes. Contrairement à un humain qui peut combler les zones d'ombre d'un système avec son propre jugement, un agent a besoin d'un environnement beaucoup plus resserré: un espace pour écrire du code, l'exécuter, inspecter les résultats, modifier la configuration, déboguer et recommencer, avec des boucles de rétroaction rapides et un contexte complet. Ce changement de paradigme, que Modal résume par le passage d'une "expérience développeur" à une "expérience agent", a des conséquences concrètes pour l'industrie: les entraînements par renforcement peuvent nécessiter jusqu'à 100 000 sandboxes simultanées, et les agents en production exigent des garde-fous stricts ainsi qu'une observabilité renforcée, potentiellement plus importante que la simple lecture du code qu'ils génèrent. Ce virage s'inscrit dans un constat plus large partagé par Bubna: Kubernetes, l'outil d'orchestration dominant depuis une décennie, n'a jamais été conçu pour des charges de travail aussi explosives et gourmandes en calcul que celles générées par l'IA moderne, qu'il s'agisse d'inférence élastique, de sursauts GPU, de post-entraînement ou d'agents fonctionnant en arrière-plan. Modal a d'ailleurs intégré le support GPU avant même le lancement de ChatGPT, anticipant ce basculement. L'entreprise mise désormais sur des concepts comme les Auto Endpoints pour simplifier le déploiement d'inférences optimisées, sur des sandboxes accompagnées de sidecars réseau, et sur une approche dite d'"auto-recherche" où des agents peuvent eux-mêmes lancer des expériences guidées par des modèles sur des GPU. Cette levée de fonds massive doit permettre à Modal de renforcer sa capacité de calcul et de consolider sa position face à des concurrents comme Databricks, Daytona, Railway ou E2B sur ce marché émergent du cloud pour agents.

💬 J'y vois surtout un aveu: l'infra cloud pensée pour des humains qui lisent une doc ne tient plus face à des agents qui ont besoin de boucles de rétroaction en continu, exécuter, inspecter, recommencer. Bon, sur le papier ça justifie la levée à 355 millions, mais 100 000 sandboxes simultanées pour du RL, ça sent surtout la facture qui explose. Reste à voir si Modal tient la distance face à Databricks et E2B, ou si c'est juste une fenêtre de tir avant que les hyperscalers rattrapent le coup.

Le puce "Frozen v2" de Google intégrerait directement l'architecture de Gemini dans le silicium pour des gains d'efficacité

Voici l'article traduit et résumé : Google développerait actuellement un nouveau processeur baptisé « Frozen v2 », conçu pour intégrer directement l'architecture de son modèle Gemini au niveau du silicium. Selon des sources internes citées par The Decoder, cette puce serait de 6 à 10 fois plus efficace que les TPU actuels de l'entreprise. Son lancement serait prévu pour 2028, ce qui laisse à Google plusieurs années de développement avant une mise en production à grande échelle. Cette approche marquerait un tournant stratégique majeur pour Google dans la course à l'intelligence artificielle. En gravant directement l'architecture de Gemini dans le matériel plutôt que de s'appuyer sur des puces génériques, l'entreprise pourrait considérablement réduire ses coûts d'inférence, c'est-à-dire les coûts liés à l'exécution des modèles d'IA une fois entraînés. Un tel gain d'efficacité permettrait potentiellement à Google de proposer ses services d'IA à des prix inférieurs à ceux d'OpenAI et d'Anthropic, ses principaux concurrents, tout en préservant ses marges. Cette stratégie s'inscrit dans une tendance de fond de l'industrie : les géants technologiques cherchent de plus en plus à concevoir leurs propres puces spécialisées plutôt que de dépendre de fournisseurs comme Nvidia. Google dispose déjà d'une expertise reconnue avec ses TPU (Tensor Processing Units), développés en interne depuis plusieurs années. En poussant cette logique plus loin avec une puce pensée spécifiquement pour Gemini, l'entreprise viserait un avantage structurel durable sur les coûts, un enjeu central alors que la rentabilité des modèles d'IA générative reste un défi majeur pour l'ensemble du secteur, y compris pour ses rivaux directs.

CopilotKit redéfinit l'architecture IA à base d'agents en 2026

CopilotKit, startup basée à Seattle et co-fondée par Atai Barkai et Uli Barkai, s'est imposée en 2026 comme l'un des acteurs centraux de l'infrastructure pour agents IA. La société a lancé en avril 2026 AIMock, un outil de test pour systèmes agentiques, et AG-UI, un protocole d'interaction entre agents et utilisateurs au sein des applications. AG-UI est aujourd'hui soutenu par Google, Microsoft, Amazon et Oracle, ainsi que par des frameworks majeurs comme LangChain, Mastra, PydanticAI et Agno. AWS l'a intégré dans son template FAST (Fullstack AgentCore Solution Template) et dans Bedrock AgentCore. Des SDKs communautaires couvrent déjà Kotlin, Go, Dart, Java, Rust, Ruby et C++, tandis que .NET, Nim, Flowise et Langflow sont en cours de développement. Atai Barkai enseigne par ailleurs un cours complet sur AG-UI chez DeepLearning.AI, couvrant un backend LangChain, un frontend React et AG-UI comme runtime. Ce que CopilotKit résout est concret : jusqu'ici, intégrer une IA dans une application signifiait coller un widget de chat dans un coin d'interface. L'utilisateur tapait, le modèle répondait en texte, et personne ne prenait en charge la traduction de cette réponse en action réelle. AG-UI comble le troisième maillon manquant de la pile agentique : MCP standardise l'accès aux outils externes, A2A coordonne les agents entre eux, AG-UI gère la couche d'interaction entre l'agent, l'application et l'utilisateur. Il permet le streaming en temps réel, la génération dynamique de composants d'interface, la synchronisation d'état bidirectionnelle, et les pauses "human-in-the-loop" où l'agent attend une confirmation avant d'agir. AIMock, lui, s'attaque à un problème que peu d'équipes osent admettre : les suites de tests pour agents sont, pour la plupart, de la fiction. Une requête agentique typique en 2026 traverse six ou sept services (LLM, serveur MCP, base vectorielle, reranker, API de recherche web, couche de modération, sous-agent A2A) et la plupart des équipes n'en simulent qu'un seul, laissant les autres non-déterministes et incontrôlés. L'analogie avancée par CopilotKit est parlante : AG-UI serait à la pile agentique ce que HTML est au web, la couche de présentation et d'interaction que TCP et HTTP rendent possible sans pouvoir la fournir eux-mêmes. Pendant des années, l'IA dans les logiciels est restée un outil passif, fonctionnel comme une calculatrice mais incapable d'agir de façon autonome. CopilotKit parie que l'avenir appartient aux agents qui vivent à l'intérieur des applications, comprennent le contexte de l'utilisateur, prennent des actions et génèrent des interfaces adaptées plutôt que de longs blocs de texte. Avec l'adoption par les grands fournisseurs cloud et l'entrée dans les cursus pédagogiques, la startup semble avoir franchi le cap qui sépare le protocole expérimental de l'infrastructure de production. La prochaine étape annoncée porte sur la persistance runtime, troisième chantier d'une feuille de route 2026 qui vise délibérément les angles morts de l'architecture agentique.

💬 L'idée du maillon manquant est bonne : MCP pour les outils, A2A pour la coordination, AG-UI pour l'utilisateur, la stack agentique commence à avoir une vraie colonne vertébrale. Ce qui me parle autant, c'est AIMock, parce que les suites de tests pour agents c'est de la fiction dans la plupart des équipes, et c'est enfin assumé. AWS dans Bedrock, Google et Microsoft embarqués, bon, sur le papier c'est le seuil qui sépare le protocole expérimental du vrai standard de prod.

Couchbase construit une architecture IA multi-modèle pour Capella iQ avec Amazon Bedrock

Le fournisseur de bases de données Couchbase a fait évoluer son assistant de développement Capella iQ pour s'appuyer sur Amazon Bedrock et la famille de modèles Claude d'Anthropic, en remplacement d'une architecture d'inférence à modèle unique. Le projet, décrit dans un billet co-écrit avec Tushar Madaan de Couchbase, repose sur une infrastructure déployée sur deux régions AWS, us-east-1 et us-west-2, afin de garantir une haute disponibilité. Un cluster Amazon EKS héberge trois microservices clés dans us-east-1 : cp-api, qui reçoit les requêtes des développeurs et orchestre les appels d'inférence ; cp-internal-api, qui gère la communication interne et la logique de routage des modèles ; et cp-ns, qui gère la configuration au niveau des espaces de noms, notamment les préférences de fournisseur de modèles par client. Un point de terminaison d'interface VPC assure une connectivité privée entre ce cluster et le runtime d'Amazon Bedrock, permettant d'exploiter l'inférence multi-région (Cross-Region Inference, ou CRIS) sur trois régions américaines : us-east-1, us-east-2 et us-west-2. Cette bascule répond à un besoin très concret de résilience opérationnelle et de flexibilité pour les grandes entreprises clientes de Couchbase. En s'appuyant sur l'inférence multi-région d'Amazon Bedrock, Capella iQ peut absorber des pics de trafic soudains et basculer automatiquement vers une région disponible en cas de dégradation, sans capacité pré-provisionnée et sans logique applicative supplémentaire à gérer côté Couchbase. Autre point important pour les clients entreprise : l'intégralité du trafic d'inférence, prompts et réponses inclus, transite exclusivement par l'infrastructure privée d'AWS et ne passe jamais par l'internet public, ce qui répond aux exigences de sécurité et de résidence des données propres à ce type de clientèle. Concrètement, quand un développeur demande à Capella iQ de générer une requête SQL++, de recommander un index ou de poursuivre une conversation multi-tours, le pod cp-api authentifie la demande, récupère le contexte de session, construit le prompt en intégrant l'historique de conversation, puis transmet l'appel via le point de terminaison VPC vers Bedrock, avant de renvoyer la réponse normalisée au développeur. Cette évolution s'inscrit dans la tendance plus large des éditeurs de logiciels d'entreprise à adopter des architectures d'inférence agnostiques par rapport au modèle, plutôt que de rester dépendants d'un unique fournisseur de LLM. Face à la croissance de l'adoption de Capella iQ, Couchbase avait besoin d'un système capable de s'adapter aux préférences de déploiement variées de ses clients tout en conservant une infrastructure scalable et robuste. Le choix d'Amazon Bedrock comme couche d'inférence permet à Couchbase de bénéficier directement des capacités de basculement régional et de répartition de charge gérées par AWS, sans avoir à développer cette logique en interne. Cette approche illustre aussi comment les modèles Claude d'Anthropic s'intègrent de plus en plus dans des produits d'infrastructure de données critiques, où la fiabilité, la confidentialité des données et la conformité pèsent autant que la qualité pure des réponses générées.