Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

# Comprendre comment Lambda gère les mises à jour de version de l’environnement d’exécution
<a name="runtimes-update"></a>

Lambda maintient à jour chaque environnement d’exécution géré avec des mises à jour de sécurité, des corrections de bogues, de nouvelles fonctionnalités, des améliorations de performance et la prise en charge des versions mineures. Ces mises à jour d’environnement d’exécution sont publiées sous forme de *versions d’environnement d’exécution*. Lambda applique les mises à jour d’environnement d’exécution aux fonctions en faisant migrer la fonction d’une version antérieure vers une nouvelle version.

Par défaut, pour les fonctions utilisant des exécutions gérées, Lambda applique des mises à jour automatiquement. Avec les mises à jour de l’environnement d’exécution automatiques, Lambda prend en charge la charge opérationnelle de l’application de correctifs aux versions de l’environnement d’exécution. Pour la plupart des clients, les mises à jour automatiques sont le bon choix. Vous pouvez modifier ce comportement par défaut en [configurant les paramètres de gestion de l’environnement d’exécution](runtime-management-configure-settings.md).

Lambda publie également chaque nouvelle version de l’environnement d’exécution sous forme d’image de conteneur. Pour mettre à jour les versions des environnements d’exécution pour les fonctions basées sur des conteneurs, vous devez [créer une nouvelle image de conteneur](images-create.md) à partir de l’image de base mise à jour et redéployer votre fonction.

Chaque version de l’environnement d’exécution est associée à un numéro de version et à un ARN (Amazon Resource Name). Les numéros de version de l’environnement d’exécution utilisent un schéma de numérotation que Lambda définit, indépendamment des numéros de version utilisés par le langage de programmation. Les numéros de version des environnements d’exécution ne sont pas toujours séquentiels. Par exemple, la version 42 peut être suivie de la version 45. L’ARN de la version de l’environnement d’exécution est un identifiant unique pour chaque version. Vous pouvez voir l’ARN de la version de l’environnement d’exécution actuelle de votre fonction dans la console Lambda ou dans la [ligne `INIT_START` des journaux de votre fonction](runtime-management-identify.md).

Les versions des environnements d’exécution ne doivent pas être confondues avec les identifiants des environnements d’exécution. Chaque environnement d’exécution possède un **identifiant unique**, tel que `python3.14` ou `nodejs24.x`. Ceux-ci correspondent à chaque version majeure du langage de programmation. Les versions de l’environnement d’exécution décrivent la version corrective d’un environnement d’exécution individuel.

**Note**  
L'ARN pour le même numéro de version d'exécution peut varier selon Régions AWS les architectures de processeur.

**Topics**
+ [Rétrocompatibilité](#runtime-update-compatibility)
+ [Modes de mise à jour de l’environnement d’exécution](#runtime-management-controls)
+ [Déploiement des versions de l’environnement d’exécution en deux phases](#runtime-management-two-phase)
+ [Configuration des paramètres de gestion de l’environnement d’exécution Lambda](runtime-management-configure-settings.md)
+ [Rétablissement d’une version de l’environnement d’exécution Lambda](runtime-management-rollback.md)
+ [Identification des changements de version de l’environnement d’exécution Lambda](runtime-management-identify.md)
+ [Comprendre le modèle de responsabilité partagée pour la gestion des environnements d’exécution Lambda](runtime-management-shared.md)
+ [Contrôle des autorisations de mise à jour de l’environnement d’exécution Lambda pour les applications hautement conformes](runtime-management-hc-applications.md)

## Rétrocompatibilité
<a name="runtime-update-compatibility"></a>

Lambda s’efforce de fournir des mises à jour d’environnement d’exécution qui sont rétrocompatibles avec les fonctions existantes. Cependant, comme pour les correctifs logiciels, il existe de rares cas dans lesquels une mise à jour de l’environnement d’exécution peut avoir un impact négatif sur une fonction existante. Par exemple, les correctifs de sécurité peuvent exposer un problème sous-jacent à une fonction existante qui dépend du comportement précédent, non sécurisé.

Lorsque vous créez et déployez votre fonction, il est important de comprendre comment gérer vos dépendances afin d’éviter d’éventuelles incompatibilités lors d’une future mise à jour d’environnement d’exécution. Supposons, par exemple, que votre fonction soit dépendante du package A, lui-même dépendant du package B. Les deux packages sont inclus dans l’environnement d’exécution Lambda (par exemple, ils peuvent faire partie du SDK ou de ses dépendances, ou faire partie des bibliothèques du système d’exécution).

Réfléchissez aux scénarios suivants :


| Déploiement | Compatible avec les correctifs | Raison | 
| --- | --- | --- | 
|  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/runtimes-update.html)  | Oui | Les futures mises à jour d’environnement d’exécution des packages A et B seront rétrocompatibles. | 
|  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/runtimes-update.html)  | Oui | Votre déploiement étant prioritaire, les futures mises à jour d’environnement d’exécution des packages A et B n’auront aucun effet. | 
|  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/runtimes-update.html)  | Oui\$1 |  Les futures mises à jour d’environnement d’exécution du package B seront rétrocompatibles. \$1Si A et B sont étroitement couplés, des problèmes de compatibilité peuvent survenir. Par exemple, les `botocore` packages `boto3` et du AWS SDK pour Python doivent être déployés ensemble.  | 
|  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/runtimes-update.html)  | Non | Les futures mises à jour d’environnement d’exécution du package A peuvent nécessiter une version mise à jour du package B. Cependant, la version déployée du package B est prioritaire et risque de ne pas être compatible avec la version mise à jour du package A. | 

Pour maintenir la compatibilité avec les futures mises à jour d’environnement d’exécution, suivez les bonnes pratiques suivantes :
+ Dans la mesure du **possible, regroupez toutes les dépendances :** incluez toutes les bibliothèques requises, y compris le AWS SDK et ses dépendances, dans votre package de déploiement. Cela garantit que votre ensemble de composants reste stable et compatible.
+ **Utilisez l'environnement d'exécution SDKs avec parcimonie :** utilisez uniquement le SDK fourni par l'exécution lorsque vous ne pouvez pas inclure de packages supplémentaires (par exemple, lorsque vous utilisez l'éditeur de code de la console Lambda ou du code en ligne dans un modèle). AWS CloudFormation 
+ **Évitez de remplacer les bibliothèques système :** ne déployez pas de bibliothèques de système d’exploitation personnalisées susceptibles d’entrer en conflit avec les futures mises à jour d’environnement d’exécution.

## Modes de mise à jour de l’environnement d’exécution
<a name="runtime-management-controls"></a>

Lambda s’efforce de fournir des mises à jour d’environnement d’exécution qui sont rétrocompatibles avec les fonctions existantes. Cependant, comme pour les correctifs logiciels, il existe de rares cas dans lesquels une mise à jour de l’environnement d’exécution peut avoir un impact négatif sur une fonction existante. Par exemple, les correctifs de sécurité peuvent exposer un problème sous-jacent à une fonction existante qui dépend du comportement précédent, non sécurisé. Les contrôles de gestion de l’environnement d’exécution Lambda permettent de réduire le risque d’impact sur vos charges de travail dans le cas rare d’une incompatibilité de version. Pour chaque [version de fonction](configuration-versions.md) (`$LATEST` ou version publiée), vous pouvez choisir l’un des modes de mise à jour de l’environnement d’exécution suivants :
+ **Auto (par défaut)** – Mettre automatiquement à jour vers la version de l’environnement d’exécution la plus sécurisée et la plus sûre à l’aide de [Déploiement des versions de l’environnement d’exécution en deux phases](#runtime-management-two-phase). Nous recommandons ce mode à la plupart des clients afin que vous puissiez toujours bénéficier des mises à jour de l’environnement d’exécution.
+ **Mise à jour de fonction** – Mise à jour vers la version d’exécution la plus récente et la plus sécurisée lorsque vous mettez à jour votre fonction. Lorsque vous mettez à jour votre fonction, Lambda met à jour l’exécution de votre fonction vers la version la plus récente et la plus sécurisée. Cette approche synchronise les mises à jour de l’environnement d’exécution avec les déploiements de fonctions, ce qui vous permet de contrôler le moment où Lambda applique les mises à jour de l’environnement d’exécution. Avec ce mode, vous pouvez détecter et atténuer rapidement les rares incompatibilités de mise à jour de l’environnement d’exécution. Lorsque vous utilisez ce mode, vous devez régulièrement mettre à jour vos fonctions pour maintenir leur environnement d’exécution à jour.
+ **Manuel** – Mise à jour manuelle de la version de votre exécution. Vous spécifiez une version de l’exécution dans la configuration de votre fonction. La fonction utilise cette version de l’environnement d’exécution indéfiniment. Dans les rares cas où une nouvelle version de l’environnement d’exécution est incompatible avec une fonction existante, vous pouvez utiliser ce mode pour ramener votre fonction à une version antérieure. Nous vous déconseillons d’utiliser le mode **Manual** (Manuel) pour tenter d’obtenir une cohérence de l’environnement d’exécution entre les déploiements. Pour de plus amples informations, veuillez consulter [Rétablissement d’une version de l’environnement d’exécution Lambda](runtime-management-rollback.md).

La responsabilité de l’application des mises à jour de l’environnement d’exécution à vos fonctions varie en fonction du mode de mise à jour que vous choisissez. Pour de plus amples informations, veuillez consulter [Comprendre le modèle de responsabilité partagée pour la gestion des environnements d’exécution Lambda](runtime-management-shared.md).

## Déploiement des versions de l’environnement d’exécution en deux phases
<a name="runtime-management-two-phase"></a>

Lambda introduit de nouvelles gestions des versions d’exécution dans l’ordre suivant :

1. Dans la première phase, Lambda applique la nouvelle version d’exécution chaque fois que vous créez ou mettez à jour une fonction. Une fonction est mise à jour lorsque vous appelez les opérations de [UpdateFunctionConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionConfiguration.html)l'API [UpdateFunctionCode](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionCode.html)or.

1. Dans la deuxième phase, Lambda met à jour toute fonction qui utilise le mode de mise à jour **Auto** de l’environnement d’exécution et qui n’a pas encore été mise à jour vers la nouvelle version. 

La durée totale du processus de déploiement varie en fonction de plusieurs facteurs, notamment la gravité de tout correctif de sécurité inclus dans la mise à jour de l’environnement d’exécution.

Si vous développez et déployez activement vos fonctions, vous obtiendrez très probablement de nouvelles versions de l’environnement d’exécution au cours de la première phase. Cela permet de synchroniser les mises à jour de l’environnement d’exécution avec les mises à jour des fonctions. Dans le cas rare où la dernière version d’exécution aurait un impact négatif sur votre application, cette approche vous permet de prendre rapidement des mesures correctives. Les fonctions qui ne sont pas en cours de développement bénéficient toujours des avantages opérationnels des mises à jour automatiques de l’environnement d’exécution au cours de la deuxième phase.

Cette approche n’affecte pas les fonctions définies en mode **Function update** (Mise à jour de fonction) ou en mode **Manual** (Manuel). Les fonctions utilisant le mode **Function update** (Mise à jour de fonction) reçoivent les dernières mises à jour de l’environnement d’exécution uniquement lorsque vous les créez ou les mettez à jour. Les fonctions utilisant le mode **Manual** (Manuel) ne reçoivent pas de mises à jour de l’environnement d’exécution.

Lambda publie les nouvelles versions de l’environnement d’exécution de manière progressive et continue à travers Régions AWS. Si vos fonctions sont configurées en mode **Auto** ou **Function update** (Mise à jour de fonction), il est possible que les fonctions déployées au même moment dans différentes régions, ou à différents moments dans la même région, reçoivent des versions de l’environnement d’exécution différentes. Les clients qui exigent une cohérence garantie des versions de l’environnement d’exécution dans leurs environnements doivent [utiliser des images de conteneurs pour déployer leurs fonctions Lambda](images-create.md). Le mode **Manuel** est conçu comme une mesure d’atténuation temporaire pour permettre de restaurer la version d’exécution dans le rare cas où une version d’exécution est incompatible avec votre fonction.

# Configuration des paramètres de gestion de l’environnement d’exécution Lambda
<a name="runtime-management-configure-settings"></a>

Vous pouvez configurer les paramètres de gestion de l’environnement d’exécution à l’aide de la console Lambda ou de AWS Command Line Interface (AWS CLI).

**Note**  
Vous pouvez configurer les paramètres de gestion de l’environnement d’exécution séparément pour chaque [version de fonction](configuration-versions.md).

**Pour configurer la façon dont Lambda met à jour la version de votre environnement d’exécution (console)**

1. Ouvrez la [page Functions](https://console.aws.amazon.com/lambda/home#/functions) (Fonctions) de la console Lambda.

1. Choisissez le nom d’une fonction.

1. Dans l’onglet **Code**, sous **Runtime settings** (Paramètres de l’environnement d’exécution), choisissez **Edit runtime management configuration** (Modifier la configuration de gestion de l’environnement d’exécution).

1. Sous **Runtime management configuration** (Configuration de la gestion de l’environnement d’exécution), choisissez l’une des options suivantes :
   + Pour que votre fonction se mette automatiquement à jour vers la dernière version de l’environnement d’exécution, sélectionnez **Auto**.
   + Pour que votre fonction se mette à jour vers la dernière version de l’environnement d’exécution lorsque vous modifiez la fonction, sélectionnez **Function update** (Mise à jour de fonction).
   + Pour que votre fonction soit mise à jour vers la dernière version de l’environnement d’exécution uniquement lorsque vous modifiez la version de l’environnement d’exécution ARN, sélectionnez **Manual** (Manuel). Vous trouverez l’ARN de la version de l’environnement d’exécution sous **Runtime management configuration** (Configuration de la gestion de l’environnement d’exécution). Vous pouvez également trouver l’ARN dans la ligne `INIT_START` des journaux de votre fonction.

   Pour de plus amples informations sur ces options, veuillez consulter [Modes de mise à jour de l’environnement d’exécution](runtimes-update.md#runtime-management-controls).

1. Choisissez **Enregistrer**.

**Pour configurer la façon dont Lambda met à jour votre version de l’environnement d’exécution (AWS CLI)**

Pour configurer la gestion de l’environnement d’exécution d’une fonction, exécutez la commande [put-runtime-management-config](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/put-runtime-management-config.html) de l’AWS CLI. Lorsque vous utilisez le mode `Manual`, vous devez également fournir l’ARN de la version de l’environnement d’exécution.

```
aws lambda put-runtime-management-config \
  --function-name my-function \
  --update-runtime-on Manual \
  --runtime-version-arn arn:aws:lambda:us-east-2::runtime:8eeff65f6809a3ce81507fe733fe09b835899b99481ba22fd75b5a7338290ec1
```

Vous devez voir des résultats similaires à ce qui suit :

```
{
  "UpdateRuntimeOn": "Manual",
  "FunctionArn": "arn:aws:lambda:us-east-2:111122223333:function:my-function",
  "RuntimeVersionArn": "arn:aws:lambda:us-east-2::runtime:8eeff65f6809a3ce81507fe733fe09b835899b99481ba22fd75b5a7338290ec1"
}
```

# Rétablissement d’une version de l’environnement d’exécution Lambda
<a name="runtime-management-rollback"></a>

Dans le cas rare où une nouvelle version de l’environnement d’exécution est incompatible avec votre fonction existante, vous pouvez rétablir sa version à une version antérieure. Cela permet à votre application de continuer à fonctionner et de minimiser les perturbations, en laissant le temps de remédier à l’incompatibilité avant de revenir à la dernière version de l’environnement d’exécution.

Lambda n’impose pas de limite de temps à l’utilisation d’une version de l’environnement d’exécution particulière. Cependant, nous vous recommandons vivement de passer à la dernière version de l’environnement d’exécution dès que possible pour bénéficier des derniers correctifs de sécurité, des améliorations de performances et des fonctionnalités. Lambda offre la possibilité de revenir à une version antérieure de l’environnement d’exécution uniquement à titre d’atténuation temporaire dans le cas rare d’un problème de compatibilité de mise à jour de l’environnement d’exécution. Les fonctions qui utilisent une version d’exécution antérieure pendant une période prolongée peuvent subir une dégradation des performances ou des problèmes, tels que l’expiration d’un certificat, qui peuvent les empêcher de fonctionner correctement.

Vous pouvez rétablir une version de l’environnement d’exécution de l’une des manières suivantes :
+ [En utilisant le mode de mise à jour Manual (Manuel) de l’environnement d’exécution](#runtime-management-rollback-manual)
+ [En utilisant les versions de la fonction publiée](#runtime-management-rollback-published)

Pour plus d’informations, consultez [Introduction aux contrôles de gestion de l’environnement d’exécution AWS Lambda](https://aws.amazon.com/blogs/compute/introducing-aws-lambda-runtime-management-controls/) sur le blog AWS.

## Rétablissement d’une version de l’environnement d’exécution à l’aide du mode de mise à jour Manual (Manuel)
<a name="runtime-management-rollback-manual"></a>

Si vous utilisez le mode de mise à jour **Auto** de la version de l’environnement d’exécution, ou si vous utilisez la version `$LATEST`, vous pouvez rétablir la version de votre environnement d’exécution en utilisant le mode **Manual** (Manuel). Pour la [version de la fonction](configuration-versions.md) que vous voulez rétablir, définissez le mode de mise à jour de la version de l’environnement d’exécution sur **Manual** (Manuel) et indiquez l’ARN de la version précédente. Pour plus d’informations sur la recherche de l’ARN de la version de l’environnement d’exécution précédente, consultez [Identification des changements de version de l’environnement d’exécution Lambda](runtime-management-identify.md).

**Note**  
Si la version `$LATEST` de votre fonction est configurée pour utiliser le mode **Manual** (Manuel), vous ne pouvez pas modifier l’architecture du processeur ou la version de l’environnement d’exécution que votre fonction utilise. Pour effectuer ces modifications, vous devez passer en mode **Auto** ou **Function update** (Mise à jour de fonction).

## Rétablissement d’une version de l’environnement d’exécution à l’aide des versions de fonction publiées
<a name="runtime-management-rollback-published"></a>

Les [versions de fonction](configuration-versions.md) publiées sont un instantané immuable du code et de la configuration de la fonction `$LATEST` au moment où vous les avez créées. En mode **Auto**, Lambda met automatiquement à jour la version de l’environnement d’exécution des versions de fonctions publiées pendant la phase deux du déploiement de la version de l’environnement d’exécution. En mode **Function update** (Mise à jour de fonction), Lambda ne met pas à jour la version de l’environnement d’exécution des versions de fonctions publiées.

Les versions de fonctions publiées utilisant le mode **Function update** (Mise à jour de fonction) créent donc un instantané statique du code de la fonction, de la configuration et de la version de l’environnement d’exécution. En utilisant le mode **Function update** (Mise à jour de fonction) avec les versions de fonctions, vous pouvez synchroniser les mises à jour de l’environnement d’exécution avec vos déploiements. Vous pouvez également coordonner le rétablissement des versions de code, de configuration et de l’environnement d’exécution en redirigeant le trafic vers une version de fonction publiée antérieurement. Vous pouvez intégrer cette approche à votre système d’intégration et de livraison continues (CI/CD) afin de rétablir automatiquement la situation dans les rares cas d’incompatibilité des mises à jour de l’environnement d’exécution. Lorsque vous utilisez cette approche, vous devez mettre à jour votre fonction régulièrement et publier de nouvelles versions de la fonction pour récupérer les dernières mises à jour de l’exécution. Pour de plus amples informations, consultez [Comprendre le modèle de responsabilité partagée pour la gestion des environnements d’exécution Lambda](runtime-management-shared.md).

# Identification des changements de version de l’environnement d’exécution Lambda
<a name="runtime-management-identify"></a>

Le [numéro de version de l’environnement d’exécution](runtimes-update.md) et l’ARN sont consignés dans la ligne de journal `INIT_START`, que Lambda émet vers CloudWatch Logs chaque fois qu’il crée un nouvel [environnement d’exécution](concepts-basics.md#gettingstarted-concepts-runtime). Étant donné que l’environnement d’exécution utilise la même exécution pour tous les invocations de fonction, Lambda émet la ligne de journal `INIT_START` uniquement lorsqu’il exécute la phase init. Lambda n’émet pas cette ligne de journal pour chaque invocation de fonction. Lambda émet la ligne de journal vers CloudWatch Logs, mais elle n’est pas visible dans la console. 

**Note**  
Les numéros de version des environnements d’exécution ne sont pas toujours séquentiels. Par exemple, la version 42 peut être suivie de la version 45.

**Example Exemple de ligne de journal INIT\$1START**  

```
INIT_START Runtime Version: python:3.13.v14    Runtime Version ARN: arn:aws:lambda:eu-south-1::runtime:7b620fc2e66107a1046b140b9d320295811af3ad5d4c6a011fad1fa65127e9e6I
```

Plutôt que de travailler directement avec les journaux, vous pouvez utiliser [Amazon CloudWatch Contributor Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ContributorInsights-CreateRule.html) pour identifier les transitions entre les versions de l’environnement d’exécution. La règle suivante compte les versions de l’environnement d’exécution distinctes de chaque ligne de journal `INIT_START`. Pour utiliser la règle, remplacez l’exemple de nom de groupe de journaux `/aws/lambda/*` par le préfixe approprié pour votre fonction ou groupe de fonctions.

```
{
  "Schema": {
    "Name": "CloudWatchLogRule",
    "Version": 1
  },
  "AggregateOn": "Count",
  "Contribution": {
    "Filters": [
      {
        "Match": "eventType",
        "In": [
          "INIT_START"
        ]
      }
    ],
    "Keys": [
      "runtimeVersion",
      "runtimeVersionArn"
    ]
  },
  "LogFormat": "CLF",
  "LogGroupNames": [
    "/aws/lambda/*"
  ],
  "Fields": {
    "1": "eventType",
    "4": "runtimeVersion",
    "8": "runtimeVersionArn"
  }
}
```

Le rapport suivant de CloudWatch Contributor Insights montre un exemple de transition de version de l’environnement d’exécution tel que capturé par la règle précédente. La ligne orange montre l’initialisation de l’environnement d’exécution pour la version précédente (**python:3.13.v12**), et la ligne bleue montre l’initialisation de l’environnement d’exécution pour la nouvelle version (**python:3.13.v14**).

![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/runtime_version_graph.png)


# Comprendre le modèle de responsabilité partagée pour la gestion des environnements d’exécution Lambda
<a name="runtime-management-shared"></a>

Lambda est responsable de la conservation et de la publication des mises à jour de sécurité pour tous les environnements d’exécution gérés et les images de conteneurs pris en charge. La responsabilité de la mise à jour des fonctions existantes pour utiliser la dernière version de l’environnement d’exécution varie en fonction du mode de mise à jour que vous utilisez.

Lambda est responsable de l’application des mises à jour de l’environnement d’exécution à toutes les fonctions configurées pour utiliser le mode de mise à jour **Auto**.

Pour les fonctions configurées avec le mode de mise à jour d’exécution **Function update** (Mise à jour de fonction), vous êtes responsable de la mise à jour régulière de votre fonction. Lambda est responsable de l’application des mises à jour de l’environnement d’exécution lorsque vous effectuez ces mises à jour. Si vous ne mettez pas à jour votre fonction, Lambda ne met pas à jour l’environnement d’exécution. Si vous ne mettez pas régulièrement à jour votre fonction, nous vous recommandons vivement de la configurer pour les mises à jour automatiques de l’environnement d’exécution afin qu’elle continue à recevoir les mises à jour de sécurité.

Pour les fonctions configurées pour utiliser le mode de mise à jour **Manual** (Manuel), vous êtes responsable de la mise à jour de votre fonction pour utiliser la dernière version de l’environnement d’exécution. Nous vous recommandons vivement d’utiliser ce mode uniquement pour rétablir la version de l’environnement d’exécution à titre de mesure d’atténuation temporaire dans le cas rare d’une incompatibilité de mise à jour. Nous vous recommandons également de passer en mode **Auto** le plus rapidement possible afin de minimiser le temps pendant lequel vos fonctions ne sont pas corrigées.

Si vous [utilisez des images de conteneur pour déployer vos fonctions](images-create.md), Lambda est responsable de la publication des images de base mises à jour. Dans ce cas, vous êtes responsable de la recréation de l’image de conteneur de votre fonction à partir de la dernière image de base et du redéploiement de l’image de conteneur.

Ceci est résumé dans le tableau suivant :


****  

| Mode de déploiement | Responsabilité de Lambda | Responsabilité du client | 
| --- | --- | --- | 
| Environnement d’exécution géré, mode Auto |  Publiez de nouvelles versions de l’environnement d’exécution contenant les derniers correctifs. Appliquez les correctifs de l’environnement d’exécution aux fonctions existantes.  | Rétablissez une version de l’environnement d’exécution précédente dans le cas rare d’un problème de compatibilité de mise à jour de l’environnement d’exécution. Suivez les meilleures pratiques de [rétrocompatibilité](runtimes-update.md#runtime-update-compatibility). | 
| Environnement d’exécution géré, mode Function update (Mise à jour de fonction) | Publiez de nouvelles versions de l’environnement d’exécution contenant les derniers correctifs. |  Mettez régulièrement à jour les fonctions afin de bénéficier de la dernière version de l’environnement d’exécution. Passez une fonction en mode **Auto** lorsque vous ne la mettez pas régulièrement à jour. Rétablissez une version de l’environnement d’exécution précédente dans le cas rare d’un problème de compatibilité de mise à jour de l’environnement d’exécution. Suivez les meilleures pratiques de [rétrocompatibilité](runtimes-update.md#runtime-update-compatibility).  | 
| Environnement d’exécution géré, mode Manual (Manuel) | Publiez de nouvelles versions de l’environnement d’exécution contenant les derniers correctifs. |  Utilisez ce mode uniquement pour restaurer temporairement l’environnement d’exécution dans le cas rare d’un problème de compatibilité de mise à jour. Passez les fonctions en mode **Auto** ou **Function update** (Mise à jour de fonction) et la dernière version de l’environnement d’exécution dès que possible.  | 
| Image de conteneur | Publiez de nouvelles images de conteneur contenant les derniers correctifs. | Redéployez régulièrement les fonctions en utilisant la dernière image de base du conteneur pour bénéficier des derniers correctifs. | 

Pour plus d’informations sur la responsabilité partagée avec AWS, consultez [Modèle de responsabilité partagée](https://aws.amazon.com/compliance/shared-responsibility-model/).

# Contrôle des autorisations de mise à jour de l’environnement d’exécution Lambda pour les applications hautement conformes
<a name="runtime-management-hc-applications"></a>

Pour répondre aux exigences de correctifs, les clients Lambda s’appuient généralement sur des mises à jour automatiques de l’environnement d’exécution. Si votre application est soumise à des exigences strictes en matière de nouveauté des correctifs, vous voudrez peut-être limiter l’utilisation de versions de l’environnement d’exécution antérieures. Vous pouvez restreindre les contrôles de gestion de l’environnement d’exécution de Lambda en utilisant Gestion des identités et des accès AWS (IAM) pour refuser aux utilisateurs de votre compte AWS l’accès à l’opération d’API [PutRuntimeManagementConfig](https://docs.aws.amazon.com/lambda/latest/api/API_PutRuntimeManagementConfig.html). Cette opération est utilisée pour choisir le mode de mise à jour de l’environnement d’exécution d’une fonction. En refusant l’accès à cette opération, toutes les fonctions passent par défaut au mode **Auto**. Vous pouvez appliquer cette restriction à l’échelle de votre organisation en utilisant des [politiques de contrôle des services (SCP)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html). Si vous devez rétablir une fonction à une version de l’environnement d’exécution antérieure, vous pouvez accorder une exception de politique au cas par cas.