Amazon, Microsoft, and Google are converging on the same enterprise agent architecture

À retenir

1. Idée-force : trois hyperscalers, une seule architecture. En 9 mois, Amazon, Microsoft et Google ont convergé sur les mêmes six primitives d'agent d'entreprise — runtime, mémoire, tool gateway, identité, observabilité, gouvernance — sous des marques différentes. Ce qui était une collection fragmentée de librairies il y a 18 mois devient une couche plateforme à part entière.
2. Le trou dans la raquette : pas de contrat, donc pas de portabilité. La convergence des composants ne produit pas la portabilité. Il manque le contrat (au sens PaaS) qui rendrait un agent agnostique de son lieu d'exécution. Aujourd'hui état de session, traces et identité terminent tous chez un seul fournisseur ; déplacer l'agent un an plus tard = tout reconstruire.
3. L'analogie directrice : PaaS 2011-2016. Avant Cloud Foundry / Heroku, on assemblait VM, load balancers, files, secret stores et agents de monitoring, chacun avec son API. Le PaaS a unifié tout ça autour d'un contrat applicatif : « l'appli déclare ce dont elle a besoin et reste agnostique de l'endroit où elle tourne ». Ce qui comptait, c'était le contrat, pas l'implémentation.
4. Leçon Cloud Foundry : le contrat survit à la plateforme. Cloud Foundry n'a pas gagné le marché (Kubernetes l'a fait), mais ses principes ont voyagé : buildpacks nés chez Heroku (2011) → Cloud Native Buildpacks (Pivotal+Heroku, janv. 2018, acceptés CNCF en octobre) ; abstraction Cloud Foundry reconstruite sur K8s via Korifi. Les entreprises sur ce socle en 2016 avaient une portabilité que la plupart des équipes agent ne peuvent pas acheter aujourd'hui.
5. Les trois plateformes, marketing déshabillé. (1) AgentCore (GA oct. 2025) : 7 services composables (runtime, gateway, memory, browser, code interpreter, identity, observability) ; runtime = fenêtres d'exécution de 8 h isolées ; gateway branche des serveurs MCP existants ; observabilité exportée via OpenTelemetry vers CloudWatch. (2) Microsoft Foundry (renommage d'Azure AI Foundry au 1ᵉʳ janv. 2026) : runtime managé isolé par session, identité Entra Agent ID, mémoire session/user/procédurale, tracing OpenTelemetry. (3) Gemini Enterprise Agent Platform (retrait du nom Vertex AI à Cloud Next 2026) : Agent Engine → Deployments, plus Memory Bank, Sessions, Agent Registry, Policies, Gateways.
6. La convergence n'est pas un complot, c'est la marge. Les entreprises d'infra bâtissent des plateformes verticalement intégrées parce que « l'intégration, c'est là qu'est la marge ». La conséquence retombe sur le client : identité, télémétrie et déploiement terminent chez un seul fournisseur → la couche opérationnelle sous l'agent est ce qui résiste à la migration.
7. Le mapping du contrat (tableau, à réutiliser en due diligence). 8 lignes « abstraction PaaS → équivalent agent → où la portabilité casse » : source appli → code+instructions+suite d'éval (chaque framework a sa forme de package) ; buildpack → détection framework+packaging (pas de build contract partagé entre SDK) ; backing service → modèle/mémoire/retrieval/tool (fournisseurs câblés dans la logique) ; service binding → attachement authentifié (credentials émis par le cloud hôte) ; router → endpoint MCP/A2A (les protocoles existent, pas le cycle de vie) ; logs → traces/tool calls/coût/qualité (conventions GenAI encore en dev) ; release promotion → évaluer/versionner/déployer progressivement (l'éval couple à un harness vendor) ; policy → identité/permissions/approbations (identité liée à l'annuaire du fournisseur).
8. Trois principes de conception. (1) Packager l'agent en une unité déployable : code, instructions, dépendances outils, contrat mémoire, permissions, suite d'éval voyagent ensemble ou pas du tout. AWS s'en approche avec son harness export (une commande → code Strands préservant modèle, prompt, outils, mémoire, conteneur), « le bon instinct pointé vers un seul cloud ». (2) Attacher plutôt qu'embarquer (leçon Twelve-Factor) : modèles, mémoire, retrieval, browsers, gateways = ressources attachées par config. « Un agent qui nomme son fournisseur de modèle dans sa logique applicative a déjà renoncé à la portabilité. » (3) Intégrer l'opérationnel à l'abstraction : les bonnes questions agent = l'agent a-t-il accompli la tâche, choisi les bons outils, dépassé son autorité, à quel coût, la qualité a-t-elle régressé après un update modèle.
9. Un agent n'est pas une web app avec un modèle greffé. Trois différences portent tout le poids : comportement probabiliste (mêmes entrées → tool calls différents) ; autorité déléguée de l'utilisateur (un bug de permissions devient un effet de bord réel, pas une page d'erreur) ; les dépendances changent le comportement sans déploiement de code (un update modèle ou une description d'outil révisée modifie ce que l'agent décide). La règle Twelve-Factor « processus stateless » n'y survit pas : il faut des workers jetables plus un état durable, inspectable et portable. LangGraph le démontre en open source (checkpointing à chaque étape, interruptions humaines, reprise après crash) — mais le control plane est dans le produit commercial LangSmith : la fragmentation apparaît à l'intérieur d'un même projet.
10. Ce que les protocoles ouverts laissent hors champ : le cycle de vie. MCP (accès outils/données), A2A (découverte/communication inter-agents), OpenTelemetry (conventions GenAI, la plupart des attributs encore « in development »), images OCI (échappatoire de packaging) : les primitives existent presque toutes. Mais une fondation qui régit comment les agents parlent aux outils ne dit rien sur comment versionner un agent, le promouvoir entre environnements ou le rollback quand une éval régresse. Protocoles ≠ plateforme de cycle de vie.
11. Le signal de concession des vendors. La Linux Foundation a annoncé l'Agentic AI Foundation (décembre 2025) ; projets fondateurs : MCP (Anthropic), goose (Block), AGENTS.md (OpenAI) ; AWS, Google et Microsoft membres platine ; Google a versé A2A à la Linux Foundation. Les hyperscalers admettent qu'une couche neutre compte.
12. Trois questions de due diligence (à garder en tête pour choisir une plateforme agent). (1) Gouvernance : le projet est-il contrôlé par une fondation neutre ou par le vendor qui vend la version managée ? (2) Packaging : le même artefact tourne-t-il sur deux clouds sans réécriture ? (3) État : la mémoire vit-elle quelque part d'exportable par l'entreprise ? Aucun projet ouvert ne répond aux trois aujourd'hui.
13. Enjeu final : qui possède le control plane possède la définition. Comme Kubernetes a défini pods/deployments/services et façonné la pensée de toute une industrie, l'équivalent agent n'est pas encore figé. Celui qui possèdera le control plane agent ne possèdera pas seulement le déploiement : il définira ce qu'est un agent, quels composants il contient, ce qu'une équipe plateforme a le droit de remplacer. Un projet neutre rendrait aux entreprises le pouvoir de négociation que buildpacks et service brokers leur avaient donné — au bénéfice des vendors autant que des acheteurs.
14. À relier. « The Development Environment Is The Next Layer To Collapse » (Greyling) et « Building for trillions of agents » (Levie) sur les couches d'agents ; identité des agents (fiche Uber Engineering, zero-trust/SPIRE) — même problème d'identité déléguée traité côté infra ; famille souveraineté / réversibilité / Design to Exit (fiche ZML/LLMD) — même logique « payer d'avance la couche qui rend le fournisseur remplaçable », transposée du silicium au control plane agent.