AWS installe S3 dans le Marketplace Vercel et remplace la clé statique par une fédération OIDC
Le 14 octobre 2026, AWS rend S3 — y compris S3 Tables et S3 Vectors — provisionnable depuis le dashboard Vercel et v0, avec un échange de jeton OIDC qui élimine les clés d’accès statiques. Pour les équipes front-end qui consomment du stockage objet sans jamais ouvrir la console AWS, c’est la fin de la clé IAM collée dans un fichier .env.
14 octobre 2026. AWS rend Amazon S3 disponible sur le Marketplace Vercel et dans v0, l’éditeur de génération d’interface de Vercel. Trois types de ressources. C’est ce que l’on peut désormais provisionner sans quitter son environnement de développement : les buckets S3 general purpose, les S3 Tables pour les tables Apache Iceberg et les S3 Vectors pour le stockage de vecteurs. 19 octobre 2026. Le AWS Weekly Roundup en fait l’un des deux faits marquants de la semaine. Pourquoi c’est important : le détail qui compte n’est pas la présence dans le catalogue, c’est le mécanisme d’authentification — un échange de jeton OIDC qui élimine la clé d’accès statique du chemin d’accès aux données.
Ce que Vercel provisionne exactement
Jusqu’ici, un développeur qui hébergeait son application sur Vercel et voulait du stockage objet devait ouvrir la console AWS, créer un bucket, fabriquer un utilisateur IAM, générer une paire de clés, puis coller ces clés dans ses variables d’environnement. C’était l’aller-retour mental qui cassait le flux de travail, et la clé longue durée qui traînait ensuite dans un fichier .env ou un secret de projet.
Le Marketplace Vercel replie cette séquence dans le dashboard : on choisit AWS, on sélectionne le type de bucket, une région et un nom, et le provisionnement prend quelques secondes. Les trois types couvrent des usages différents. Le bucket general purpose sert à n’importe quelle charge : assets statiques, uploads utilisateurs, sauvegardes. Les S3 Tables livrent des tables Iceberg entièrement managées, optimisées pour l’analytique. Les S3 Vectors stockent et interrogent nativement des vecteurs à grande échelle, pour les applications IA qui font de la recherche par similarité.
S3 rejoint ainsi des intégrations qui existaient déjà — Amazon Aurora, Amazon DynamoDB et Amazon OpenSearch Serverless. La pile entière se déploie dans un seul compte AWS, avec une seule facture, mais se configure depuis l’outil que le développeur utilise déjà. C’est la bascule stratégique : AWS ne demande plus au développeur de venir à lui, il va là où le développeur travaille.
Le mécanisme qui compte : OIDC plutôt que clé statique
La partie la plus intéressante de l’annonce tient en une phrase : Vercel établit une connexion sécurisée avec AWS « en s’appuyant sur la fédération OIDC de Vercel et l’authentification IAM de S3 », sans clé d’accès codée en dur. Concrètement, au moment de l’exécution, un jeton OIDC à courte durée de vie est échangé auprès d’AWS Security Token Service contre des identifiants temporaires restreints à la ressource concernée.
La différence avec le schéma classique est structurelle. Une clé d’accès statique ne expire pas, se duplique facilement, et une fois divulguée reste valide jusqu’à ce que quelqu’un la révoque manuellement. Un jeton OIDC échangé contre des identifiants STS vit quelques minutes, est scopé au bucket visé, et n’existe jamais sous forme de secret stocké dans la configuration du projet. C’est exactement le modèle que GitHub Actions a imposé à l’écosystème CI/CD avec son OIDC provider : supprimer la clé longue durée du pipeline.
Pour l’équipe front-end, la conséquence est concrète. Plus de rotation de clés à gérer, plus de secret qui fuite dans un dépôt public, plus de « qui a encore cette clé ? » au moment d’un audit. La gouvernance se déplace du fichier de configuration vers la fédération d’identité — là où elle aurait toujours dû être.
La stratégie : acheter de la distribution sur le terrain du développeur
Cette intégration ne sort pas de nulle part. AWS et Vercel ont rapproché leurs surfaces depuis plusieurs trimestres, et l’annonce du 14 octobre en est l’aboutissement logique. Le message commercial est limpide : les nouveaux comptes AWS créés via Vercel reçoivent 100 dollars de crédits, valables jusqu’à six mois, utilisables sur Amazon S3, OpenSearch Serverless et les services de base de données. Les clients AWS existants peuvent, eux, lier leur compte pour utiliser S3 avec leurs projets Vercel.
C’est un pari d’acquisition. En entrant dans le Marketplace Vercel, AWS capte des développeurs qui n’auraient jamais franchi le seuil de la console, et les convertit en clients de S3 dès leur premier déploiement sérieux. Le stockage objet est le produit d’appel parfait : il est bon marché, inerte, et une fois les données écrites, la migration vers un concurrent est un vrai projet. Les 100 dollars de crédits sont un coût d’acquisition dérisoire face à la valeur d’un bucket qui grossit mois après mois.
La disponibilité est globale : S3 sur Vercel fonctionne dans toutes les régions AWS où Vercel est présent. Pour une équipe qui déploie en Edge via Vercel, cela signifie qu’elle peut placer son stockage près de ses utilisateurs sans renoncer à la console unique de son fournisseur d’hébergement.
Ce que l’intégration ne règle pas
Bornons la portée, parce que la tentation est de voir dans cette annonce plus qu’elle ne contient. D’abord, S3 sur Vercel reste du S3 AWS : la facture arrive sur le compte AWS, pas sur la facture Vercel. L’intégration simplifie le provisionnement et la connexion, elle ne fusionne pas les deux systèmes de facturation. Une équipe qui ne surveille pas son compte AWS peut découvrir une surprise sur une facture qu’elle regardait à peine.
Ensuite, la fédération OIDC résout le problème de la clé statique, pas celui de la gouvernance IAM au sens large. Les identifiants temporaires sont scopés à la ressource, mais c’est toujours la politique IAM qui définit ce qu’ils peuvent faire. Une policy trop large — s3:* sur tout le compte — reste une policy trop large, quel que soit le mécanisme d’émission des identifiants. La sécurité se déplace d’un maillon à l’autre, elle ne disparaît pas.
Enfin, le choix du type de bucket n’est pas neutre et ne doit pas être laissé à la valeur par défaut. Les S3 Tables et les S3 Vectors ne sont pas interchangeables avec un bucket general purpose : ils ont des modèles de coût et des cas d’usage précis. Provisionner une S3 Table pour stocker des assets statiques revient à payer un moteur analytique pour un travail de vitrine. La simplicité du provisionnement ne dispense pas de comprendre ce que l’on provisionne.
Verdict
Si votre équipe héberge sur Vercel et consomme du stockage objet, activez l’intégration S3 et supprimez vos clés IAM statiques : le modèle OIDC → STS est strictement supérieur, et le coût de migration est nul puisque le provisionnement se fait en quelques secondes. Si vous gérez déjà un compte AWS mature, liez-le plutôt que d’en créer un nouveau — vous garderez une facture unique et vos politiques IAM existantes. Si vous avez besoin d’analytique ou de recherche vectorielle, choisissez explicitement les S3 Tables ou les S3 Vectors au lieu d’un bucket généraliste. L’annonce du 14 octobre ne crée pas un nouveau S3 : elle supprime la friction et la clé statique qui séparaient le développeur front-end de son stockage — et c’est exactement la partie qui méritait de disparaître.
Références
- AWS — Amazon S3 is now available on the Vercel Marketplace and v0 by Vercel (14 octobre 2026)
- AWS News Blog — Amazon S3 is now available on the Vercel Marketplace and v0 by Vercel
- AWS News Blog — AWS Weekly Roundup (19 octobre 2026)
- Vercel — Amazon S3 joins the Vercel Marketplace
- Vercel Marketplace — AWS S3