AWS Lambda ouvre ses runtimes Node.js 26 et Python 3.15 en préversion publique

25 août 2026. AWS Lambda change la façon dont il livre ses runtimes managés. Node.js 26 et Python 3.15 arrivent en préversion publique, une première dans l’histoire de la plateforme. Aucun SLA. C’est la condition que le service pose à toute fonction déployée sur ces runtimes d’essai, et elle dit l’essentiel : ce canal sert à tester, pas à produire.

Depuis son lancement, Lambda ne publiait ses runtimes managés qu’en disponibilité générale, immédiatement utilisables par des charges de production. Cette politique avait un coût invisible : une fois un runtime passé en GA, l’équipe ne pouvait plus y introduire de changement cassant sans risquer de casser des fonctions existantes. La préversion inverse la logique. Elle permet de tester une charge, de remonter des anomalies et de laisser les fournisseurs d’observabilité, les outils d’Infrastructure-as-Code et les frameworks de déploiement valider leur compatibilité — pendant que les changements cassants restent encore possibles.

Ce qui change concrètement

Les deux runtimes s’activent avec les identifiants nodejs26.x et python3.15, via la console (options « Node.js 26 (Preview) » et « Python 3.15 (Preview) »), l’AWS CLI, CloudFormation, AWS SAM ou le CDK. Trois propriétés distinguent la préversion de la GA.

Premièrement, pas de SLA. Les runtimes en préversion ne sont couverts ni par le SLA de Lambda, ni par les plans de support AWS. Une fonction qui tourne sur nodejs26.x n’engage aucune garantie de disponibilité — c’est la règle à intégrer avant même d’envisager une bascule.

Deuxièmement, les changements cassants restent possibles. C’est le point le plus important pour un opérateur : pendant la préversion, AWS peut modifier le runtime d’une manière qui casse une fonction. On teste donc, on ne migre pas.

Troisièmement, la graduation est automatique. Un runtime de préversion porte le même identifiant que son futur runtime GA. Quand Node.js 26 ou Python 3.15 passeront en production, les fonctions basculeront automatiquement, sans action de l’équipe. C’est un détail d’ingénierie qui change la donne opérationnelle : le code de test écrit aujourd’hui n’aura pas à être re-déployé demain.

Le périmètre est large. Les préversions sont disponibles dans toutes les régions commerciales AWS, les régions GovCloud (US) et les régions Chine, sans surcoût — la facturation reste au tarif standard de Lambda.

Pourquoi ces deux langages maintenant

Le choix de Node.js 26 et de Python 3.15 n’est pas neutre. Ce sont les deux prochaines échéances auxquelles les parcs Lambda vont se heurter, et le calendrier propre à chaque langage impose une bascule rapide.

Node.js 26 est sorti le 5 mai 2026 en branche Current, avec l’API Temporal activée par défaut, le moteur V8 14.6 et Undici 8.0. Il entrera en LTS en octobre 2026. Le contexte compte davantage que le détail des fonctionnalités : le projet Node.js a annoncé un changement de rythme. À partir d’octobre 2026, une seule version majeure par an (en avril), promotion LTS en octobre, et surtout plus de distinction pair/impair — Node.js 27 deviendra LTS lui aussi. Pour un parc Lambda, cela signifie que la fenêtre « Current avant LTS » se lit différemment, et qu’il faut décider tôt.

Python 3.15 est en fin de cycle. La 3.15.0rc1 est sortie le 4 août 2026, et la version stable est attendue pour le 1er octobre 2026. Proposer le runtime en préversion maintenant permet de valider les dépendances natives — celles qui se cassent le plus souvent lors d’un saut de version de Python — avant la sortie officielle.

Le signal sous-jacent est celui de la fin de vie. Les fonctions encore sur Python 3.12 ou Node.js 22 approchent de la fin de support de leur runtime chez AWS, et chaque fin de support se traduit par une migration forcée. La préversion publique est le canal officiel pour ne pas subir cette migration sous contrainte.

Ce qu’un opérateur doit faire maintenant

La préversion change le travail de préparation, pas le travail de production. Concrètement, trois commandes suffisent à ouvrir le chantier.

# 1. Lister les runtimes de préversion disponibles dans la région
aws lambda list-runtimes --region eu-west-3 | jq '.Runtimes[] | select(.Runtime | test("nodejs26|python3.15"))'

# 2. Déployer une fonction de test sur le runtime Node.js 26 en préversion
aws lambda create-function --function-name preview-test --runtime nodejs26.x \
  --role arn:aws:iam::123456789012:role/lambda-exec --handler index.handler \
  --zip-file fileb://function.zip

# 3. Vérifier le runtime réellement attribué après création
aws lambda get-function-configuration --function-name preview-test --query 'Runtime'

L’essentiel n’est pas d’exécuter du code de production sur la préversion, mais de valider trois choses : la compilation des dépendances natives, le comportement au cold start, et la compatibilité des couches (layers) et des extensions. Ces trois points concentrent l’essentiel des surprises d’une migration de runtime.

Le piège classique est de traiter la préversion comme un runtime de plus. Elle n’en est pas un : sans SLA ni garantie anti-changement cassant, une fonction de production qui y bascule est une fonction sans filet. AWS l’écrit noir sur blanc — les préversions « ne doivent pas être utilisées pour des charges de production ».

Verdict

Si vos fonctions tournent sur Node.js 22 ou Python 3.12, ouvrez dès maintenant un espace de test sur nodejs26.x et python3.15. Validez les dépendances, mesurez les cold starts, et remontez les anomalies via les issues GitHub dédiées au runtime Node.js 26 et au runtime Python 3.15 avant la GA. La préversion est exactement l’outil qui manquait pour préparer la migration sans la subir.

Si vos fonctions sont encore sur des runtimes plus anciens — Node.js 20, Python 3.11 — le message est plus urgent : vous avez deux sauts de version à planifier, et la préversion de Python 3.15 est le bon moment pour vérifier que vos dépendances natives survivront au passage. Dans tous les cas, la règle reste la même : on teste en préversion, on ne produit pas en préversion. La graduation automatique fera le reste le jour de la GA.

Références

• AWS — AWS Lambda introduces managed runtimes in public preview for Node.js 26 and Python 3.15, 25 août 2026
• AWS Compute Blog — Introducing public preview runtimes on AWS Lambda
• Node.js — Node.js 26.0.0 (Current), 5 mai 2026
• PEP 790 — Python 3.15 Release Schedule
• Python — Python 3.15.0rc1, 4 août 2026