AWS a ajouté une nouvelle carte à la console cette semaine : Agent Toolkit for AWS. C'est gratuit, en disponibilité générale, et ça fonctionne avec Claude Code, Codex, Cursor et Kiro. Un seul prompt d'installation donne à votre agent de codage un serveur MCP pour les API AWS, des skills sélectionnées pour les tâches courantes et des garde-fous IAM. Le toolkit en soi est utile. Ce qu'il admet est plus grand : le premier lecteur de la documentation AWS n'est plus une personne.

Ce qu'il y a dans la boîte

Trois couches, qui fonctionnent indépendamment les unes des autres :

  • Le serveur MCP AWS. Un endpoint hébergé (aws-mcp.us-east-1.api.aws) que votre agent atteint via mcp-proxy-for-aws. Il donne à l'agent un accès aux API AWS, l'exécution de scripts en sandbox et la recherche en temps réel dans la documentation. Les credentials ne sont nécessaires que pour les appels d'API ; la recherche documentaire fonctionne sans.
  • Les plugins. aws-core couvre le choix des services, CDK et CloudFormation, le serverless, les conteneurs, le stockage, l'observabilité et la facturation. aws-agents ajoute des skills Bedrock et AgentCore, aws-data-analytics et aws-agents-for-devsecops couvrent leurs propres domaines. Sur Claude Code, ils s'installent depuis la marketplace officielle de plugins avec un simple /plugin install.
  • Les skills. Des instructions de tâches sélectionnées, installées avec npx skills add aws/agent-toolkit-for-aws/skills. Chargées à la demande : l'agent ne récupère que ce qui correspond à la tâche en cours, elles ne coûtent donc rien tant qu'elles ne sont pas utilisées.

L'authentification passe par le nouveau flux aws login dans le navigateur, vérifié avec aws sts get-caller-identity. Si vous vivez dans le terminal, aws configure agent-toolkit branche la même chose via l'AWS CLI.

L'installation est un prompt, pas un script

Voici le détail qui mérite qu'on s'y arrête. La console ne vous tend pas un script shell. Elle vous tend une phrase à coller dans votre agent :

Set up Agent Toolkit for AWS by following instructions:
https://raw.githubusercontent.com/aws/agent-toolkit-for-aws/refs/heads/main/setup-instructions/setup.md

Cette URL est un fichier Markdown. Votre agent le lit, détecte votre OS, installe l'AWS CLI si elle manque, exécute aws login, branche le serveur MCP et installe les skills. Le document est structuré comme un runbook pour une machine : étapes numérotées, tableaux de gestion d'erreurs, commandes de vérification après chaque étape. AWS a écrit un guide d'installation dont le public visé n'est pas vous. Vous ne faites qu'approuver les demandes de permission.

C'est le motif à retenir. Les instructions d'installation étaient jusqu'ici de la prose pour humains avec des blocs de code à copier. Ceci est du code pour agents, avec de la prose que l'humain survole une fois.

Plus personne ne lit la doc, sauf les agents

Je vais avouer quelque chose. Pendant des années, ma lecture du week-end n'était ni des polars ni de la fiction. C'était la documentation AWS : quotas de service, cas limites d'API, le changelog d'une classe de stockage dont personne ne parle. Cette lecture a construit l'index mental qui me rendait rapide, parce que savoir où vit la réponse représentait l'essentiel du travail.

Cet index est désormais une commodité. Un agent doté de la recherche documentaire lit la page actuelle, pas celle que j'ai mémorisée il y a deux ans, et il la lit en quelques secondes. Le toolkit rend cela officiel : AWS maintient maintenant un pipeline dédié pour servir sa propre doc à des machines, avec « une documentation à jour et des procédures testées » comme argument phare. Le client le plus important de l'équipe documentation a changé d'espèce.

Ce qui ne devient pas une commodité, c'est le jugement. Quel service convient, quel est le rayon d'impact d'un changement, est-ce que le plan de l'agent survit au contact des réalités de votre compte. C'est pourquoi le troisième mot du pitch d'AWS est guardrails : un agent avec des credentials valides est un principal comme un autre, et il reçoit le moindre privilège comme un autre. Deux notes pratiques sur ce front :

  • Épinglez la version du proxy (à la manière de mcp-proxy-for-aws@1.6.3). Le README d'AWS le recommande lui-même contre le risque de supply chain, et ils ont raison.
  • Limitez le rôle de l'agent à la lecture seule par défaut et verrouillez chaque chemin de mutation séparément. Les garde-fous IAM du toolkit aident, mais la policy reste la vôtre à écrire.

Pour conclure

L'ère agentique du développement AWS n'est pas arrivée avec une keynote. Elle est arrivée sous la forme d'une petite carte dans la console proposant un prompt d'installation. AWS part désormais du principe que votre premier collaborateur sur n'importe quel projet est un agent, et livre une documentation, des procédures et des limites de permissions construites pour ce lecteur. Mes week-ends auront peut-être enfin de la place pour un roman policier. La doc est entre de bonnes mains, et le travail intéressant, décider quoi construire et ce qu'un agent a le droit de toucher, a toujours été la partie impossible à indexer de toute façon.

À lire ensuite