L’essentiel
Le 23 octobre 2026, le PDG d’Amazon Andy Jassy a déclaré que la capacité d’AWS était épuisée pour 2026, « largement épuisée » pour 2027 et qu’une bonne partie de 2028 était déjà réservée, malgré quelque 220 milliards de dollars d’investissements prévus en 2026. AWS conserve une réserve pour EC2 à la demande et Bedrock, mais les gros volumes sont déjà engagés. Si votre produit a besoin de GPU ou de beaucoup de calcul dans les 12 à 24 prochains mois, inscrivez la capacité comme un jalon de votre feuille de route cloud et DevOps. Réservez tôt, consommez efficacement et gardez la possibilité de changer de région ou de fournisseur.
Qu’a dit Andy Jassy sur la capacité d’AWS ?
Jassy s’exprimait dans The a16z Show, le podcast d’Andreessen Horowitz, aux côtés du cofondateur Ben Horowitz et du general partner Erik Torenberg, dans un épisode diffusé le vendredi 23 octobre. Il a expliqué qu’AWS avait déjà vendu sa capacité pour cette année et que 2027 était « largement épuisée » elle aussi. AWS laisse toujours une partie de la capacité pour l’usage à la demande et pour son service d’inférence Bedrock ou EC2, a-t-il précisé, mais « vend l’essentiel des gros blocs ». Il a ajouté qu’« une bonne partie de 2028 est vendue ». Reuters et The Information ont rapporté ces propos le jour même.
Cela intervient alors qu’Amazon n’a jamais autant investi. Le groupe a relevé en juillet son plan d’investissement 2026 à environ 220 milliards de dollars, en partie parce que la mémoire est devenue plus chère. Jassy a affirmé dans le podcast qu’Amazon « pourrait investir beaucoup plus, et ce ne serait pas un mauvais usage du capital ». La demande vient des laboratoires d’IA et des entreprises qui intègrent l’IA à leurs produits. Ni Amazon ni les articles n’ont cité de clients, de régions ou de types de puces derrière ces réservations.
Pourquoi la capacité cloud vient-elle à manquer ?
Le problème n’est pas l’argent, mais l’offre physique. Jassy a cité trois limites : l’espace en centres de données, l’électricité et la mémoire. Aucune ne se résout en un trimestre. Les nouveaux sites demandent des années d’autorisations et de travaux, les raccordements au réseau électrique sont rares dans de nombreuses régions, et la mémoire à haute bande passante des accélérateurs IA est contrainte dans tout le secteur. Si le premier fournisseur cloud se dit réservé jusqu’en 2028 avec un tel niveau d’investissement, ses concurrents subissent très probablement une pression comparable.
Pour les acheteurs, le point clé est la façon dont AWS répartit ce dont il dispose. La plus grosse part va aux engagements pluriannuels de grands clients, surtout des laboratoires d’IA et des entreprises qui ont réservé tôt. Le reste est gardé pour l’usage à la demande et l’inférence managée. Concrètement, une équipe de taille moyenne peut encore lancer des instances et appeler des modèles aujourd’hui, mais la capacité importante ou spécialisée, comme de grands clusters GPU pour l’entraînement ou le fine-tuning, est la plus difficile à obtenir à court terme, et elle peut coûter plus cher quand on l’obtient.
Ce que cela signifie pour les équipes logicielles en France
Premièrement, la planification de capacité fait désormais partie de la planification produit. Si votre feuille de route 2027 prévoit l’entraînement ou le fine-tuning de modèles, de l’inférence à fort volume ou une migration d’envergure, c’est avant le démarrage des travaux qu’il faut sécuriser le calcul, pas quand le backlog y arrive. AWS propose déjà des outils pour cela : réservations de capacité, tarifs avec engagement d’utilisation et blocs GPU planifiés pour le ML. La contrepartie : vous vous engagez à dépenser avant que la demande soit avérée. Dimensionnez donc les réservations sur des prévisions défendables. Surréserver ne fait que déplacer le risque de la disponibilité vers le coût.
Deuxièmement, les services managés deviennent le choix par défaut le plus sûr. Selon Jassy, AWS garde de la capacité pour l’inférence via Bedrock et EC2. Les équipes qui appellent des modèles de fondation via un service managé comme Amazon Bedrock puisent dans cette réserve et n’ont pas à sécuriser leur propre parc GPU. Pour la plupart des équipes produit, c’est un argument en faveur de l’inférence managée plutôt que de clusters de modèles auto-hébergés, sauf si les règles sur les données, le coût à grande échelle ou le contrôle du modèle justifient clairement de les exploiter soi-même.
Troisièmement, l’efficacité conditionne désormais la disponibilité autant que le coût. Quand le calcul est rare, l’équipe qui en consomme le moins livre la première. Modèles plus petits ou distillés, mise en cache des réponses, traitement par lots et instances bien dimensionnées réduisent la facture et la dépendance à une capacité rare. La portabilité fonctionne de la même façon : des charges décrites en infrastructure-as-code et conteneurisées sur Kubernetes peuvent basculer vers une autre région ou un autre fournisseur quand l’une est saturée. Vérifiez à l’avance que toute région de repli respecte vos obligations RGPD et de localisation des données.
Comment planifier la capacité dès maintenant ?
- Prévoir 12 à 24 mois de besoins de calcul. Par type de charge : entraînement, inférence, batch, charge de base. Les projets gourmands en GPU passent en premier.
- Réserver ce que vous pouvez justifier. Utilisez réservations de capacité ou engagements pour la charge de base prévisible, et laissez les pics et les expérimentations à la demande.
- Privilégier l’inférence managée. Appelez les modèles via des services managés quand c’est possible, plutôt que de monter vos propres clusters GPU.
- Faire de l’efficacité un critère de mise en production. Suivez le calcul consommé par requête ou par utilisateur, et misez sur le cache, le traitement par lots et des modèles plus petits avant d’ajouter du matériel.
- Garder des charges portables. Infrastructure-as-code et conteneurs évitent qu’un manque de capacité dans une région ou un cloud bloque un lancement.
- Vérifier la conformité des régions de repli. Assurez-vous que toute région alternative respecte vos exigences de localisation des données et réglementaires (RGPD, le cas échéant SecNumCloud ou DORA) avant qu’un incident n’impose la bascule.
- Revoir vos hypothèses tarifaires. Une capacité rare peut signifier moins de remises. Intégrez-le dans vos budgets cloud 2027.
Questions fréquentes
AWS est-il vraiment à court de capacité ?
Pas complètement. Le 23 octobre 2026, le PDG d’Amazon Andy Jassy a déclaré que la capacité AWS pour 2026 était vendue, que 2027 était « largement épuisée » et qu’une bonne partie de 2028 l’était aussi. Selon lui, AWS garde toujours de la capacité pour l’usage à la demande et pour l’inférence via Bedrock et EC2. Ce qui est épuisé, ce sont les gros blocs engagés par les grands clients. Les équipes peuvent toujours lancer des instances et appeler des modèles, mais la capacité importante ou spécialisée, en particulier les GPU, est plus difficile à obtenir à court terme.
Pourquoi Amazon ne construit-il pas simplement plus de centres de données ?
Amazon prévoit déjà environ 220 milliards de dollars d’investissements en 2026, et Jassy a indiqué que le groupe pourrait investir davantage. Les limites sont physiques : les centres de données mettent des années à sortir de terre, l’électricité et les raccordements au réseau sont rares, et la mémoire pour le matériel d’IA manque dans tout le secteur. Jassy a cité les centres de données, l’électricité et la mémoire comme goulots d’étranglement.
Comment une équipe logicielle peut-elle sécuriser de la capacité cloud ?
Prévoyez vos besoins de calcul 12 à 24 mois à l’avance, charge par charge, et réservez la capacité de la charge de base prévisible via les options de réservation ou d’engagement du fournisseur. Laissez les charges expérimentales et irrégulières à la demande. Privilégiez les services managés pour l’inférence, car AWS dit y réserver de la capacité. Réduisez vos besoins avec le cache, le traitement par lots et des modèles plus petits, et gardez des charges portables grâce à l’infrastructure-as-code et aux conteneurs pour pouvoir changer de région ou de fournisseur en cas de pénurie.
La pénurie de capacité AWS touche-t-elle différemment les équipes en France ?
Les articles n’ont pas détaillé la capacité par région : il n’existe donc pas de chiffre publié pour la région de Paris. La vraie différence pour les équipes françaises tient à la conformité. Si vous prévoyez de basculer ou de vous étendre vers une autre région parce que la vôtre est saturée, celle-ci doit toujours respecter vos obligations RGPD et de localisation des données et, pour les données sensibles du secteur public, les exigences SecNumCloud. Vérifiez-le en amont et intégrez des régions de repli conformes à votre plan de capacité plutôt que d’en choisir une en plein incident.
Sources
The a16z Show — Andy Jassy, PDG d’Amazon, sur le chantier IA à 220 milliards de dollars (source primaire, 23 octobre 2026)
Reuters (via U.S. News) — La capacité cloud d’Amazon épuisée jusqu’en 2027, selon le PDG Andy Jassy (23 octobre 2026)
The Information — AWS quasi épuisé jusqu’en 2028, selon Jassy (23 octobre 2026)
CNBC — Amazon relève son capex 2026 à 220 milliards de dollars face à la hausse du coût de la mémoire (30 juillet 2026)