Dépannage

Cette page explique comment résoudre les problèmes liés à Batch.

Si vous essayez de résoudre un problème lié à une tâche pour laquelle vous ne disposez d'aucun message d'erreur, vérifiez si l'historique de la tâche contient des messages d'erreur en affichant les événements d'état avant de consulter ce document.

Pour en savoir plus sur le dépannage d'une tâche, consultez également les documents suivants:

Erreurs de création de tâches

Si vous ne parvenez pas à créer une tâche, cela peut être dû à l'une des erreurs décrites dans cette section.

Quota insuffisant

Problème

L'un des problèmes suivants se produit lorsque vous essayez de créer une tâche:

  • Lorsque la tâche est à l'état QUEUED, le problème suivant s'affiche dans le champ statusEvents:

    Quota checking process decides to delay scheduling for the job JOB_UID due to inadequate quotas [Quota: QUOTA_NAME, limit: QUOTA_LIMIT, usage: QUOTA_CURRENT_USAGE, wanted: WANTED_QUOTA.].

    Ce problème indique que la tâche a été retardée, car l'utilisation actuelle (QUOTA_USAGE) et la limite (QUOTA_LIMIT) du quota QUOTA_NAME ont empêché l'utilisation demandée (WANT_QUOTA) de la tâche.

  • Lorsque la tâche est dans l'un des états QUEUED, SCHEDULED ou FAILED, l'un des problèmes suivants s'affiche dans le champ statusEvents:

    RESOURCE_NAME creation failed:
Quota QUOTA_NAME exceeded. Limit: QUOTA_LIMIT in region REGION

    RESOURCE_NAME creation failed:
Quota QUOTA_NAME exceeded. Limit: QUOTA_LIMIT in zone ZONE

    Ce problème indique que la création d'une ressource a échoué, car la requête a dépassé votre quota QUOTA_NAME, qui est limité à QUOTA_LIMIT à l'emplacement spécifié.

Solution

Pour identifier le problème, procédez comme suit :

  • Si la tâche a été retardée, essayez d'attendre que plus de quota soit libéré.

  • Si la tâche a échoué en raison d'un quota insuffisant ou si ces retards persistent, essayez d'éviter un quota insuffisant en procédant comme suit:

    • Créez des tâches qui utilisent moins de ce quota ou un autre quota. Par exemple, spécifiez un emplacement ou un type de ressource autorisé différent pour la tâche, ou répartissez votre utilisation des quotas sur d'autres projets.

    • Demandez une limite de quota supérieure pour votre projet depuis Google Cloud.

Pour en savoir plus, consultez les pages Quotas et limites par lot et Utiliser des quotas.

Autorisations insuffisantes pour agir en tant que compte de service

Problème

Le problème suivant se produit lorsque vous essayez de créer une tâche:

  • Si la tâche n'utilise pas de modèle d'instance, le problème se présente comme suit:

    caller does not have access to act as the specified service account: SERVICE_ACCOUNT_NAME

  • Si la tâche utilise un modèle d'instance, le problème se présente comme suit:

    Error: code - CODE_SERVICE_ACCOUNT_MISMATCH, description - The service account specified in the instance template INSTANCE_TEMPLATE_SERVICE_ACCOUNT doesn't match the service account specified in the job JOB_SERVICE_ACCOUNT for JOB_UID, project PROJECT_NUMBER

Ce problème se produit généralement parce que l'utilisateur qui crée le job ne dispose pas d'autorisations suffisantes pour agir en tant que compte de service utilisé par le job, ce qui est contrôlé par l'autorisation iam.serviceAccounts.actAs.

Solution

Pour identifier le problème, procédez comme suit :

  1. Si la tâche utilise un modèle d'instance, vérifiez que le compte de service spécifié dans le modèle d'instance correspond au compte de service spécifié dans la définition de la tâche.
  2. Assurez-vous que l'utilisateur qui crée le job a été attribué au rôle Utilisateur du compte de service (roles/iam.serviceAccountUser) sur le compte de service spécifié pour le job. Pour en savoir plus, consultez la section Gérer l'accès.
  3. Recréez la tâche.

Réseaux répétés

Problème

Le problème suivant se produit lorsque vous essayez de créer une tâche:

Networks must be distinct for NICs in the same InstanceTemplate

Ce problème se produit parce que vous avez spécifié le réseau d'une tâche plusieurs fois.

Solution

Pour résoudre le problème, recréez la tâche et spécifiez le réseau à l'aide de l'une des options suivantes:

Pour en savoir plus, consultez la section Spécifier le réseau d'une tâche.

Réseau non valide pour VPC Service Controls

Problème

Le problème suivant se produit lorsque vous essayez de créer une tâche:

no_external_ip_address field is invalid. VPC Service Controls is enabled for the project, so external ip address must be disabled for the job. Please set no_external_ip_address field to be true

Solution

Ce problème se produit lorsque vous essayez de créer et d'exécuter une tâche avec des VM disposant d'adresses IP externes dans un périmètre de service VPC Service Controls.

Pour résoudre le problème, créez une tâche qui bloque l'accès externe pour toutes les VM.

Pour en savoir plus sur la configuration de la mise en réseau d'une tâche dans un périmètre de service VPC Service Controls, consultez Utiliser VPC Service Controls avec Batch.

Problèmes de tâches et erreurs d'échec

Si vous rencontrez des problèmes avec un job qui ne s'exécute pas correctement ou qui échoue pour des raisons peu claires, cela peut être dû à l'une des erreurs de cette section ou à l'un des codes de sortie de la section Codes de sortie en cas d'échec de la tâche suivante.

Aucun journal dans Cloud Logging

Problème

Vous devez déboguer une tâche, mais aucun journal ne s'affiche pour cette tâche dans Cloud Logging.

Ce problème se produit souvent pour les raisons suivantes:

  • L'API Cloud Logging n'est pas activée pour votre projet. Même si vous configurez correctement tout le reste pour les journaux d'une tâche, elle ne produira pas de journaux si le service n'est pas activé pour votre projet.
  • Le compte de service de la tâche n'est pas autorisé à écrire des journaux. Un job ne peut pas générer de journaux sans autorisations suffisantes.
  • La tâche n'a pas été configurée pour générer des journaux. Pour générer des journaux dans Cloud Logging, vous devez activer Cloud Logging pour une tâche. Les exécutables de la tâche doivent également être configurés pour écrire toutes les informations que vous souhaitez afficher dans les journaux dans les flux de sortie standard (stdout) et d'erreur standard (stderr). Pour en savoir plus, consultez la section Analyser une tâche à l'aide des journaux.
  • Les tâches n'ont pas été exécutées. Les journaux ne peuvent pas être générés tant que des ressources n'ont pas été attribuées aux tâches et que celles-ci ne commencent pas à s'exécuter.
  • Cloud Logging a été configuré pour exclure automatiquement les journaux de la tâche. Les journaux des tâches par lot ne peuvent pas s'afficher si vous avez configuré des filtres d'exclusion pour Cloud Logging qui excluent les journaux des tâches par lot.

Solution

Pour résoudre ce problème, procédez comme suit :

  1. Assurez-vous que les journaux n'ont pas été automatiquement exclus de Cloud Logging en désactivant tous les filtres d'exclusion pour Cloud Logging actuels.
  2. Assurez-vous que l'API Cloud Logging est activée pour votre projet.
  3. Assurez-vous que le compte de service de la tâche dispose du rôle IAM Rédacteur de journaux (roles/logging.logWriter). Pour en savoir plus, consultez la section Activer la fonctionnalité de traitement par lot pour un projet.
  4. Affichez les détails de la tâche à l'aide de la CLI gcloud ou de l'API Batch. Les détails de la tâche peuvent vous aider à comprendre pourquoi la tâche n'a pas généré de journaux et peuvent fournir des informations que vous espériez obtenir des journaux. Par exemple, procédez comme suit :
    1. Pour vérifier que la journalisation est activée, examinez le champ logsPolicy de la tâche.
    2. Pour vérifier que la tâche a bien été exécutée, consultez le champ status de la tâche.

Une fois les modifications effectuées, recréez la tâche et attendez qu'elle se termine avant de vérifier les journaux.

Aucun rapport sur l'agent de service

Problème

Le problème suivant s'affiche dans le champ statusEvents pour une tâche qui ne s'exécute pas correctement ou qui a échoué avant la création des VM:

No VM has agent reporting correctly within time window NUMBER_OF_SECONDS seconds, VM state for instance VM_NAME is TIMESTAMP,agent,start

Le problème indique qu'aucune des VM d'une tâche ne signale au service d'agent de traitement par lot.

Ce problème se produit souvent pour les raisons suivantes:

  • Les VM de la tâche ne disposent pas d'autorisations suffisantes. Les VM d'une tâche nécessitent des autorisations spécifiques pour signaler leur état à l'agent de service de traitement par lot. Vous pouvez fournir ces autorisations pour les VM d'une tâche en attribuant le rôle "Reporter de l'agent de traitement par lot" (roles/batch.agentReporter) au compte de service de la tâche.
  • Les VM de la tâche rencontrent des problèmes de réseau. Les VM d'une tâche nécessitent un accès réseau pour communiquer avec l'agent de service de traitement par lot.
  • Les VM de la tâche utilisent une image de système d'exploitation de VM Batch obsolète ou une image de système d'exploitation de VM avec un logiciel d'agent de service Batch obsolète. Les VM de la tâche nécessitent un logiciel dans son image de système d'exploitation de VM qui fournit les dépendances actuelles pour les rapports à l'agent de service de lot.

Solution

Pour identifier le problème, procédez comme suit :

  1. Vérifiez que les VM de la tâche disposent des autorisations requises pour signaler leur état à l'agent de service de traitement par lot.

    1. Pour identifier le compte de service de la tâche, affichez les détails de la tâche à l'aide de la CLI gcloud ou de l'API Batch. Si aucun compte de service n'est listé, le job utilise le compte de service Compute Engine par défaut.

    2. Vérifiez que le compte de service de la tâche dispose des autorisations pour le rôle de rapporteur de l'agent de traitement par lot (roles/batch.agentReporter). Pour en savoir plus, consultez les pages Gérer l'accès et Limiter l'utilisation des comptes de service.

      Par exemple, pour accorder au compte de service Compute Engine par défaut les autorisations requises, utilisez la commande suivante:

      gcloud projects add-iam-policy-binding PROJECT_ID \
  --role roles/batch.agentReporter \
  --member serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com

  2. Vérifiez que les VM de la tâche disposent d'un accès réseau approprié. Pour en savoir plus, consultez les pages Présentation de la mise en réseau par lot et Résoudre les problèmes de mise en réseau courants.

  3. Si vous avez spécifié l'image du système d'exploitation de la VM pour la tâche, vérifiez qu'elle est actuellement compatible.

    1. Si vous avez activé Cloud Logging pour la tâche, vous pouvez identifier ce problème en vérifiant si l'un des journaux d'agent suivants (batch_agent_logs) est présent. Pour en savoir plus, consultez la section Analyser une tâche à l'aide de journaux.

      • Journal de l'erreur liée à un logiciel obsolète de l'agent de service Batch:

        rpc error: code = FailedPrecondition, desc = Invalid resource state for BATCH_AGENT_VERSION: outdated Batch agent version used.

        BATCH_AGENT_VERSION correspond à la version du logiciel permettant de communiquer avec l'agent de service Batch utilisé par la tâche (par exemple, cloud-batch-agent_20221103.00_p00).

      • Journal de l'erreur d'image de l'OS de la VM par lot obsolète:

        rpc error: code = FailedPrecondition, desc = Invalid resource state for BATCH_VM_OS_IMAGE_NAME: outdated Batch image version.

        BATCH_VM_OS_IMAGE_NAME correspond à la version spécifique d'une image de système d'exploitation de VM de traitement par lots utilisée par le job (par exemple, batch-debian-11-20220909-00-p00).

    2. Pour résoudre ce problème, utilisez une image d'OS de VM plus récente. Si la tâche utilise une image personnalisée, recréez-la en vous basant sur l'une des dernières versions d'une image publique compatible.

      Pour en savoir plus, consultez les pages Images d'OS de VM compatibles et Afficher les images d'OS de VM.

  4. Recréez la tâche.

Métriques de ressources manquantes dans Cloud Monitoring

Problème

Vous souhaitez afficher les métriques de ressources d'une tâche, mais certaines ou toutes les métriques attendues sont manquantes.

Ce problème se produit souvent pour les raisons suivantes:

  • L'API n'était pas activée pour votre projet. Même si vous configurez correctement tout le reste de votre projet, les métriques de ressources peuvent ne pas s'afficher tant que l'API Cloud Monitoring n'est pas activée. Pour l'agent Ops, vous devez également activer l'API Cloud Logging.
  • Vous ne disposez pas des autorisations nécessaires pour afficher les métriques. Vous ne pouvez pas afficher les métriques sans les autorisations nécessaires.
  • Les VM de la tâche ne s'exécutent pas. Les métriques ne peuvent pas être générées pour une tâche tant qu'au moins une des VM de la tâche n'est pas en cours d'exécution.
  • La configuration ou les autorisations de la tâche n'étaient pas compatibles avec les métriques de l'agent Ops. Certaines métriques de ressources ne peuvent être fournies que par l'agent Ops. Pour prendre en charge les métriques de l'agent Ops, une tâche doit répondre aux exigences de l'agent Ops, l'installer et utiliser un compte de service pouvant écrire des métriques dans Monitoring.
  • Vous devez utiliser une autre méthode ou un autre filtre pour afficher les métriques. Certaines méthodes d'affichage des métriques n'affichent pas les métriques des VM après leur suppression. De plus, les métriques ne s'affichent pas si elles sont omises par les filtres ou la période affichée. De plus, les graphiques de métriques ont des résolutions réglables qui peuvent entraîner l'affichage de petites quantités de données trop fines.
  • Les métriques ont été supprimées. Vous ne pouvez pas afficher les métriques une fois qu'elles ont été supprimées, ce qui se produit automatiquement après les périodes de conservation de la surveillance.

Solution

Si seules les métriques de l'agent Ops sont manquantes, essayez d'abord de résoudre le problème en procédant comme suit:

  1. Vérifiez la configuration de la tâche en procédant comme suit :
    1. Pour afficher les informations de configuration complètes de la tâche, consultez les détails de la tâche à l'aide de la gcloud CLI ou de l'API Batch. Utilisez la sortie pour les étapes restantes.
    2. Assurez-vous que le compte de service de la tâche dispose des autorisations nécessaires pour écrire des métriques Ops Agent.
    3. Assurez-vous que la tâche respecte toutes les exigences de l'agent Ops.
    4. Assurez-vous que la tâche installe correctement l'agent Ops. Bien qu'il soit possible d'installer manuellement l'agent Ops dans un exécutable, la méthode recommandée consiste à installer automatiquement l'agent Ops en définissant le champ installOpsAgent sur true.
  2. Si le problème persiste, consultez la section Dépannage de l'agent d'exploitation dans la documentation Google Cloud Observability.

Sinon, procédez comme suit pour résoudre le problème:

  1. Assurez-vous que l'API Monitoring est activée pour votre projet :

    Enable the API

  2. Assurez-vous que les VM du job ont commencé à s'exécuter et que la durée d'exécution est toujours dans les périodes de conservation de surveillance. Vous pouvez consulter la durée d'exécution de la tâche en affichant les détails de la tâche.
  3. Pour vérifier qu'il n'y a pas de problème avec les méthodes que vous utilisez pour afficher les métriques, procédez comme suit :
    1. Sauf si vous souhaitez afficher uniquement les métriques des ressources en cours d'exécution, assurez-vous d'afficher les métriques à l'aide de l'explorateur de métriques ou d'un tableau de bord personnalisé créé à partir de graphiques de l'explorateur de métriques. D'autres méthodes, telles que les tableaux de bord Compute Engine, n'affichent pas les métriques des ressources supprimées.
    2. Assurez-vous que la période d'affichage inclut la durée d'exécution de la tâche. Pour les graphiques, assurez-vous également que la résolution du graphique est adaptée à vos données.
    3. Assurez-vous qu'aucun filtre ne masque les données.
  4. Si le problème persiste, consultez les pages Dépannage de la surveillance Cloud de la documentation Google Cloud Observability.

Contrainte non respectée pour les adresses IP externes des VM

Problème

Le problème suivant s'affiche dans le champ statusEvents pour une tâche ayant échoué:

Instance VM_NAME creation failed: Constraint constraints/compute.vmExternalIpAccess violated for project PROJECT_NUMBER.
Add instance VM_NAME to the constraint to use external IP with it.

Ce problème survient, car votre projet, votre dossier ou votre organisation a défini la contrainte de règle d'administration compute.vmExternalIpAccess afin que seules les VM de la liste d'autorisation puissent utiliser des adresses IP externes.

Solution

Pour résoudre le problème, recréez la tâche et effectuez l'une des opérations suivantes:

Contrainte non respectée pour les images de confiance

Problème

Le problème suivant s'affiche dans le champ statusEvents pour une tâche ayant échoué:

Instance VM_NAME creation failed: Constraint constraints/compute.trustedImageProjects violated for project PROJECT_ID. Use of images from project batch-custom-image is prohibited.

Solution

Ce problème survient, car votre projet a défini la contrainte de règles sur les images de confiance (compute.trustedImageProjects) afin que les images de Batch, qui se trouvent dans le projet d'images batch-custom-image, ne soient pas autorisées.

Pour résoudre le problème, effectuez au moins l'une des opérations suivantes:

  • Recréez la tâche pour spécifier une image d'OS de VM déjà autorisée par la contrainte du règlement relatif aux images de confiance.
  • Demandez à votre administrateur d'autoriser la modification de la contrainte du règlement relatif aux images de confiance pour autoriser les images de l'OS de la VM à partir du projet d'images batch-custom-image. Pour obtenir des instructions, consultez la section Contrôler l'accès aux images de l'OS de la VM pour Batch.

Échec de la tâche lors de l'utilisation d'un modèle d'instance

Problème

Le problème suivant apparaît dans le champ statusEvents pour une tâche ayant échoué qui utilise un modèle d'instance:

INVALID_FIELD_VALUE,BACKEND_ERROR

Ce problème se produit en raison de problèmes peu clairs avec le modèle d'instance de la tâche.

Solution

Pour déboguer le problème plus en détail, procédez comme suit:

  1. Créez un MIG à l'aide du modèle d'instance et observez si des erreurs se produisent avec plus de détails.

  2. Facultatif: Pour essayer d'obtenir plus d'informations, consultez l'opération de longue durée qui crée le MIG dans la console Google Cloud.

    Accéder à "Opérations Compute Engine"

Codes de sortie en cas d'échec de la tâche

Lorsqu'une tâche spécifique d'une tâche échoue, elle renvoie un code de sortie non nul. Selon la configuration du champ ignoreExitStatus, une tâche ayant échoué peut ou non entraîner l'échec d'une tâche.

En plus des codes de sortie que vous définissez dans un exécutable, un lot comporte plusieurs codes de sortie réservés, y compris les codes de sortie suivants.

Préemption de VM (50001)

Problème

Le problème suivant s'affiche dans le champ statusEvents d'une tâche:

Task state is updated from PRE-STATE to FAILED on zones/ZONE/instances/INSTANCE_ID due to Spot Preemption with exit code 50001.

Ce problème survient lorsqu'une VM Spot pour la tâche est préemptée au moment de l'exécution.

Solution

Pour résoudre le problème, effectuez l'une des opérations suivantes:

  • Réessayez la tâche à l'aide des nouvelles tentatives automatiques de la tâche ou en réexécutant manuellement le job.
  • Pour vous assurer qu'il n'y a pas de préemption, utilisez plutôt des VM avec le modèle de provisionnement standard.

Délai avant expiration de la création de rapports sur les VM (50002)

Problème

Le problème suivant s'affiche dans le champ statusEvents d'une tâche:

Task state is updated from PRE-STATE to FAILED on zones/ZONE/instances/INSTANCE_ID due to Batch no longer receives VM updates with exit code 50002.

Ce problème se produit lorsqu'un délai avant expiration dans le backend empêche Batch de recevoir des mises à jour d'une VM pour la tâche. Malheureusement, de nombreuses défaillances matérielles ou logicielles peuvent empêcher une VM de répondre. Par exemple, une VM peut planter en raison d'un événement hôte temporaire ou d'un manque de ressources.

Solution

Pour résoudre ce problème, procédez comme suit :

  1. Si le problème est temporaire et se résout de lui-même, réessayez la tâche à l'aide des nouvelles tentatives automatiques de tâches ou en réexécutant manuellement le job.

  2. Si le problème persiste, identifiez et corrigez la cause de l'absence de réponse de la VM en procédant comme suit:

    • Recommandation:Obtenez de l'aide via l'assistanceGoogle Cloud ou le libellé de lot sur les forums Cloud.

    • Essayez d'identifier et de résoudre le problème vous-même. Par exemple, si vous connaissez Compute Engine, vous pouvez essayer de résoudre les problèmes liés aux VM de la tâche en procédant comme suit:

      1. Pour identifier les noms des VM de votre tâche, procédez comme suit:

        1. Affichez les journaux de la tâche.
        2. Filtrez les journaux pour afficher les entrées contenant la phrase report agent state:.

        3. Examinez les journaux pour déterminer la VM pour chaque tentative de chaque tâche. Chaque journal est semblable à celui-ci, qui comporte une phrase instance: et une ou plusieurs phrases task_id:.

          report agent state: ... instance:"INSTANCE_NAME" ... task_id:"task/JOB_UID-group0-TASK_INDEX/TASK_RETRIES/0 ..."

          Ce journal inclut les valeurs suivantes:

          • INSTANCE_NAME : nom de la VM.
          • JOB_UID: ID unique (UID) de la tâche.
          • TASK_INDEX: index de la tâche.
          • TASK_RETRIES: tentative de la tâche exécutée sur cette VM, au format du nombre de nouvelles tentatives. Par exemple, cette valeur est 0 pour la première tentative d'une tâche. Chaque tâche n'est tentée qu'une seule fois, sauf si vous activez les tentatives de tâches automatiques.

      2. Résolvez les problèmes liés aux VM de votre tâche à l'aide de la documentation Compute Engine. Consultez par exemple Résoudre les problèmes liés aux arrêts et aux redémarrages de VM et Dépannage du démarrage des VM.

La VM a redémarré pendant l'exécution (50003)

Problème

Le problème suivant s'affiche dans le champ statusEvents d'une tâche:

Task state is updated from PRE-STATE to FAILED on zones/ZONE/instances/INSTANCE_ID due to VM is rebooted during task execution with exit code 50003.

Ce problème se produit lorsqu'une VM pour une tâche redémarre de manière inattendue pendant l'exécution.

Solution

Pour résoudre ce problème, réessayez la tâche à l'aide des nouvelles tentatives automatiques de tâche ou en réexécutant manuellement le job.

La VM et la tâche ne répondent pas (50004)

Problème

Le problème suivant s'affiche dans le champ statusEvents d'une tâche:

Task state is updated from PRE-STATE to FAILED on zones/ZONE/instances/INSTANCE_ID due to tasks cannot be canceled with exit code 50004.

Ce problème se produit lorsqu'une tâche atteint la limite de temps d'inactivité et ne peut pas être annulée.

Solution

Pour résoudre ce problème, réessayez la tâche à l'aide des nouvelles tentatives automatiques de tâche ou en réexécutant manuellement le job.

La tâche dépasse la durée d'exécution maximale (50005)

Problème

Le problème suivant s'affiche dans le champ statusEvents d'une tâche:

Task state is updated from PRE-STATE to FAILED on zones/ZONE/instances/INSTANCE_ID due to task runs over the maximum runtime with exit code 50005.

Ce problème se produit dans les cas suivants:

  • La durée d'exécution d'une tâche dépasse la limite de temps spécifiée dans le champ maxRunDuration.
  • Le temps d'exécution d'un exécutable dépasse la limite de temps spécifiée dans le champ timeout.

Pour identifier précisément la limite de temps dépassée, affichez les journaux de la tâche et recherchez un journal qui mentionne le code de sortie 50005. Ce champ textPayload de ce journal indique où et quand la limite de temps a été dépassée.

Solution

Pour résoudre le problème, essayez de vérifier la durée d'exécution totale requise par la tâche ou l'exécutable qui a dépassé la limite de temps. Effectuez l'une des opérations suivantes :

VM recréée pendant l'exécution (50006)

Problème

Le problème suivant s'affiche dans le champ statusEvents d'une tâche:

Task state is updated from PRE-STATE to FAILED on zones/ZONE/instances/INSTANCE_ID due to VM is recreated during task execution with exit code 50006.

Ce problème se produit lorsqu'une VM pour une tâche est recréée de manière inattendue au moment de l'exécution.

Solution

Pour résoudre ce problème, réessayez la tâche à l'aide des nouvelles tentatives automatiques de tâche ou en réexécutant manuellement le job.

Étape suivante