{"meta":{"title":"Syntaxe de flux de travail pour GitHub Actions","intro":"Un workflow est un processus automatisé configurable qui comprend un ou plusieurs travaux. Vous devez créer un fichier YAML pour définir votre configuration de workflow.","product":"GitHub Actions","breadcrumbs":[{"href":"/fr/actions","title":"GitHub Actions"},{"href":"/fr/actions/reference","title":"Référence"},{"href":"/fr/actions/reference/workflows-and-actions","title":"Flux de travail et actions"},{"href":"/fr/actions/reference/workflows-and-actions/workflow-syntax","title":"Syntaxe des workflows"}],"documentType":"article"},"body":"# Syntaxe de flux de travail pour GitHub Actions\n\nUn workflow est un processus automatisé configurable qui comprend un ou plusieurs travaux. Vous devez créer un fichier YAML pour définir votre configuration de workflow.\n\n## À propos de la syntaxe YAML pour les workflows\n\nLes fichiers de workflow utilisent la syntaxe YAML, et doivent avoir une extension de fichier `.yml` ou `.yaml`. Si vous débutez avec YAML et souhaitez en savoir plus, consultez [Découvrir YAML en Y minutes](https://learnxinyminutes.com/docs/yaml/).\n\nVous devez stocker les fichiers de workflow dans le répertoire `.github/workflows` de votre dépôt.\n\n## `name`\n\nNom du workflow. GitHub affiche les noms de vos workflows sous l’onglet « Actions » de votre référentiel. Si vous omettez `name`, GitHub affiche le chemin du fichier de workflow relatif à la racine du référentiel.\n\n## `run-name`\n\nNom des exécutions de workflow généré à partir du workflow.\nGitHub affiche le nom d’exécution du flux de travail dans la liste des exécutions de flux de travail sous l’onglet « Actions » de votre référentiel. Si `run-name` elle est omise ou n’est qu’un espace blanc, le nom d’exécution est défini sur des informations spécifiques à l’événement pour l’exécution du flux de travail. Par exemple, pour un flux de travail déclenché par un événement `push` ou `pull_request`, il est défini comme le message de commit ou le titre de la pull request.\n\nCette valeur peut inclure des expressions et peut référencer les contextes [`github`](/fr/actions/learn-github-actions/contexts#github-context) et [`inputs`](/fr/actions/learn-github-actions/contexts#inputs-context).\n\n### Exemple de `run-name`\n\n```yaml\nrun-name: Deploy to ${{ inputs.deploy_target }} by @${{ github.actor }}\n```\n\n## `on`\n\nPour déclencher automatiquement un workflow, utilisez `on` pour définir les événements qui peuvent conduire à l’exécution du workflow. Pour obtenir la liste des événements disponibles, consultez [Événements qui déclenchent des flux de travail](/fr/actions/using-workflows/events-that-trigger-workflows).\n\nVous pouvez définir un ou plusieurs événements susceptibles de déclencher un workflow, ou définir un calendrier. Vous pouvez également restreindre l’exécution d’un workflow de façon à ce qu’il ne se produise que pour des fichiers, étiquettes ou modifications de branche spécifiques. Les étapes de cette procédure sont décrites dans les sections suivantes.\n\n### Utilisation d’un seul événement\n\nPar exemple, un workflow avec la valeur `on` suivante s’exécute quand une poussée (push) est effectuée dans une branche incluse dans son dépôt :\n\n```yaml\non: push\n```\n\n### Utilisation de plusieurs événements\n\nVous pouvez spécifier un événement unique ou plusieurs événements. Par exemple, un workflow avec la valeur `on` suivante s’exécute quand une poussée (push) est effectuée dans une branche du dépôt ou quand quelqu’un duplique (fork) le dépôt :\n\n```yaml\non: [push, fork]\n```\n\nSi vous spécifiez plusieurs événements, un seul de ces événements a besoin de se produire pour déclencher votre workflow. Si plusieurs événements déclencheurs se produisent pour votre workflow en même temps, plusieurs exécutions de workflow sont déclenchées.\n\n### Utilisation de types d’activités\n\nCertains événements ont des types d’activités qui vous donnent davantage de contrôle sur le moment où votre workflow devrait s’exécuter. Utilisez `on..types` pour définir le type d’activité d’événement qui déclenchera l’exécution d’un workflow.\n\nPar exemple, l’événement `issue_comment` a les types d’activité `created`, `edited` et `deleted`. Si votre worflow se déclenche sur l’événement `label`, il s’exécute chaque fois qu’une étiquette est créée, modifiée ou supprimée. Si vous spécifiez le type d’activité `created` de l’événement `label`, votre workflow s’exécute quand une étiquette est créée, mais pas quand une étiquette est modifiée ou supprimée.\n\n```yaml\non:\n label:\n types:\n - created\n```\n\nSi vous spécifiez plusieurs types d’activités, un seul de ceux-ci doit se produire pour déclencher votre workflow. Si plusieurs types d’activité d’événement déclencheur pour votre workflow se produisent simultanément, plusieurs exécutions de workflow seront déclenchées. Par exemple, le workflow suivant se déclenche quand un problème est ouvert ou étiqueté. Si un problème avec deux étiquettes est ouvert, trois exécutions de workflow démarrent : une pour l’événement d’ouverture du problème, et deux pour les deux événements étiquetés du problème.\n\n```yaml\non:\n issues:\n types:\n - opened\n - labeled\n```\n\nPour plus d’informations sur chaque événement et leurs types d’activité, consultez [Événements qui déclenchent des flux de travail](/fr/actions/using-workflows/events-that-trigger-workflows).\n\n### Utilisation de filtres\n\nCertains événements comportent des filtres qui vous permettent de mieux contrôler le moment où votre workflow devrait s’exécuter.\n\nPar exemple, l’événement `push` comporte un filtre `branches` avec lequel votre workflow ne s’exécute que lorsqu’un envoi (push) vers une branche qui correspond au filtre `branches` se produit, et non lorsque n’importe quel envoi se produit.\n\n```yaml\non:\n push:\n branches:\n - main\n - 'releases/**'\n```\n\n### Utilisation de types d’activités et de filtres avec plusieurs événements\n\nSi vous spécifiez des types d’activités ou des filtres pour un événement et que votre workflow se déclenche sur plusieurs événements, vous devez configurer chaque événement séparément. Vous devez ajouter un signe deux-points (`:`) à tous les événements, notamment aux événements sans configuration.\n\nPar exemple, un workflow avec la valeur `on` suivante s’exécute quand :\n\n* Une étiquette est créée.\n* Une poussée (push) est effectuée dans la branche `main` du dépôt.\n* Une poussée (push) est effectuée dans une branche compatible avec GitHub Pages.\n\n```yaml\non:\n label:\n types:\n - created\n push:\n branches:\n - main\n page_build:\n```\n\n## `on..types`\n\nUtilisez `on..types` pour définir le type d’activité qui déclenchera une exécution de workflow. La plupart des événements GitHub sont déclenchés par plusieurs types d’activité. Par exemple, le déclencheur `label` est déclenché lorsqu’une étiquette est `created`, `edited`ou `deleted`. Le mot clé `types` vous permet d’affiner l’activité qui provoque l’exécution du workflow. Lorsqu’un seul type d’activité déclenche un événement de webhook, le mot clé `types` n’est pas nécessaire.\n\nVous pouvez utiliser un tableau d’événements `types`. Pour plus d’informations sur chaque événement et leurs types d’activité, consultez [Événements qui déclenchent des flux de travail](/fr/actions/using-workflows/events-that-trigger-workflows#available-events).\n\n```yaml\non:\n label:\n types: [created, edited]\n```\n\n## `on..`\n\nQuand vous utilisez les événements `pull_request` et `pull_request_target` vous pouvez configurer un workflow afin qu’il s’exécute uniquement pour les demandes de tirage (pull requests) qui ciblent des branches spécifiques.\n\nUtilisez le filtre `branches` quand vous souhaitez inclure des modèles de noms de branches, ou quand vous souhaitez à la fois inclure et exclure des modèles de noms de branches. Utilisez le filtre `branches-ignore` quand vous souhaitez exclure uniquement les modèles de nom de branche. Vous ne pouvez pas utiliser les filtres `branches` et `branches-ignore` en même temps pour le même événement dans un workflow.\n\nSi vous définissez à la fois `branches`/`branches-ignore` et [`paths`/`paths-ignore`](/fr/actions/using-workflows/workflow-syntax-for-github-actions#onpushpull_requestpull_request_targetpathspaths-ignore), le workflow s’exécute uniquement quand les deux filtres sont satisfaits.\n\nLes mots clés `branches` et `branches-ignore` acceptent les modèles Glob qui utilisent des caractères tels que `*`, `**`, `+`, `?`, `!` et certains autres pour correspondre à plusieurs noms de branches. Si un nom contient l’un de ces caractères et si vous souhaitez une correspondance littérale, vous devez utiliser le caractère d’échappement `\\` avec chacun de ces caractères spéciaux. Pour plus d’informations sur les modèles glob, consultez l’[Syntaxe de flux de travail pour GitHub Actions](/fr/actions/using-workflows/workflow-syntax-for-github-actions#filter-pattern-cheat-sheet).\n\n### Exemple : Inclusion de branches\n\nLes modèles définis dans `branches` sont évalués par rapport au nom de la référence Git. Par exemple, le workflow suivant s’exécute chaque fois qu’il existe un événement `pull_request` pour une demande de tirage qui cible :\n\n* Une branche nommée `main` (`refs/heads/main`)\n* Une branche nommée `mona/octocat` (`refs/heads/mona/octocat`)\n* Une branche dont le nom commence par `releases/`, par exemple `releases/10` (`refs/heads/releases/10`)\n\n```yaml\non:\n pull_request:\n # Sequence of patterns matched against refs/heads\n branches:\n - main\n - 'mona/octocat'\n - 'releases/**'\n```\n\nSi un workflow est ignoré en raison du filtrage de branche, du [filtrage de chemin d’accès](/fr/actions/using-workflows/workflow-syntax-for-github-actions#onpushpull_requestpull_request_targetpathspaths-ignore) ou d’un [message de commit](/fr/actions/managing-workflow-runs/skipping-workflow-runs), les vérifications associées à ce workflow restent alors à l’état « En attente ». La fusion d’une demande de tirage (pull request) nécessitant la réussite de ces vérifications sera bloquée.\n\n### Exemple : Exclusion de branches\n\nQuand un modèle correspond au modèle `branches-ignore`, le workflow ne s’exécute pas. Les modèles définis dans `branches-ignore` sont évalués par rapport au nom de la référence Git. Par exemple, le workflow suivant s’exécute chaque fois qu’il existe un événement `pull_request`, sauf si la demande de tirage cible :\n\n* Une branche nommée `mona/octocat` (`refs/heads/mona/octocat`)\n* Une branche dont le nom correspond à `releases/**-alpha`, par exemple `releases/beta/3-alpha` (`refs/heads/releases/beta/3-alpha`) \n\n```yaml\non:\n pull_request:\n # Sequence of patterns matched against refs/heads\n branches-ignore:\n - 'mona/octocat'\n - 'releases/**-alpha'\n```\n\n### Exemple : Inclusion et exclusion de branches\n\nVous ne pouvez pas utiliser `branches` et `branches-ignore` pour filtrer le même événement dans un seul workflow. Si vous souhaitez à la fois inclure et exclure des modèles de branche pour un seul événement, utilisez le filtre `branches` avec le caractère `!` pour indiquer les branches à exclure.\n\nSi vous définissez une branche avec le caractère `!`, vous devez également définir au moins une branche sans le caractère `!`. Si vous souhaitez uniquement exclure des branches, utilisez `branches-ignore` à la place.\n\nL’ordre dans lequel vous définissez les modèles est important.\n\n* Un modèle de correspondance négative (préfixé avec `!`) après une correspondance positive exclut la référence Git.\n* Un modèle de correspondance positive après une correspondance négative inclut à nouveau la référence Git.\n\nLe workflow suivant s’exécute sur les événements `pull_request` pour les demandes de tirage qui ciblent `releases/10` ou `releases/beta/mona`, mais pas pour les demandes de tirage qui ciblent `releases/10-alpha` ou `releases/beta/3-alpha`, car le modèle négatif `!releases/**-alpha` suit le modèle positif. \n\n```yaml\non:\n pull_request:\n branches:\n - 'releases/**'\n - '!releases/**-alpha'\n```\n\n## `on.push.`\n\nLorsque vous utilisez l’événement `push`, vous pouvez configurer un workflow pour qu’il s’exécute sur des branches ou des étiquettes spécifiques.\n\nUtilisez le filtre `branches` lorsque vous souhaitez inclure des modèles de noms de branche ou lorsque vous souhaitez inclure et exclure des modèles de noms de branche. Utilisez le filtre `branches-ignore` quand vous souhaitez exclure uniquement les modèles de nom de branche. Vous ne pouvez pas utiliser les filtres `branches` et `branches-ignore` en même temps pour le même événement dans un workflow.\n\nUtilisez le filtre `tags` lorsque vous souhaitez inclure des modèles de nom d’étiquette ou lorsque vous souhaitez inclure et exclure des modèles de noms d’étiquette. Utilisez le filtre `tags-ignore` lorsque vous souhaitez exclure uniquement les modèles de nom d’étiquette. Vous ne pouvez pas utiliser les filtres `tags` et `tags-ignore` en même temps pour le même événement dans un workflow.\n\nSi vous définissez uniquement `tags`/`tags-ignore` ou uniquement `branches`/`branches-ignore`, le flux de travail ne s’exécutera pas pour les événements affectant la référence Git non définie. Si vous définissez ni `tags`/`tags-ignore` ou `branches`/`branches-ignore`, le flux de travail sera exécuté pour les événements affectant les branches ou les étiquettes. Si vous définissez à la fois `branches`/`branches-ignore` et [`paths`/`paths-ignore`](/fr/actions/using-workflows/workflow-syntax-for-github-actions#onpushpull_requestpull_request_targetpathspaths-ignore), le workflow s’exécute uniquement quand les deux filtres sont satisfaits.\n\nLes mots clés `branches`, `branches-ignore`, `tags` et `tags-ignore` acceptent des modèles Glob qui utilisent des caractères tels que `*`, `**`, `+`, `?`, `!` et d’autres pour correspondre à plus d’un nom de branche ou d’étiquette Si un nom contient l’un de ces caractères et que vous souhaitez une correspondance littérale, vous devez *échapper* chacun de ces caractères spéciaux avec `\\`. Pour plus d’informations sur les modèles glob, consultez l’[Syntaxe de flux de travail pour GitHub Actions](/fr/actions/using-workflows/workflow-syntax-for-github-actions#filter-pattern-cheat-sheet).\n\n### Exemple : Inclure des branches et des étiquettes\n\nLes modèles définis dans `branches` et `tags` sont évalués par rapport au nom de la référence Git. Par exemple, le workflow suivant s’exécuterait chaque fois qu’il existe un événement `push` pour :\n\n* Une branche nommée `main` (`refs/heads/main`)\n* Une branche nommée `mona/octocat` (`refs/heads/mona/octocat`)\n* Une branche dont le nom commence par `releases/`, par exemple `releases/10` (`refs/heads/releases/10`)\n* Une étiquette nommée `v2` (`refs/tags/v2`)\n* Une étiquette dont le nom commence par `v1.`, comme `v1.9.1` (`refs/tags/v1.9.1`)\n\n```yaml\non:\n push:\n # Sequence of patterns matched against refs/heads\n branches:\n - main\n - 'mona/octocat'\n - 'releases/**'\n # Sequence of patterns matched against refs/tags\n tags:\n - v2\n - v1.*\n```\n\n### Exemple : Exclusion de branches et de tags\n\nLorsqu’un modèle correspond au modèle `branches-ignore` ou `tags-ignore`, le workflow n’est pas exécuté. Les modèles définis dans `branches` et `tags` sont évalués par rapport au nom de la référence Git. Par exemple, le workflow suivant s’exécuterait chaque fois qu’il existe un événement `push`, sauf si l’événement `push` concerne :\n\n* Une branche nommée `mona/octocat` (`refs/heads/mona/octocat`)\n* Une branche dont le nom correspond à `releases/**-alpha`, par exemple `releases/beta/3-alpha` (`refs/heads/releases/beta/3-alpha`) \n* Une étiquette nommée `v2` (`refs/tags/v2`)\n* Une étiquette dont le nom commence par `v1.`, comme `v1.9` (`refs/tags/v1.9`)\n\n```yaml\non:\n push:\n # Sequence of patterns matched against refs/heads\n branches-ignore:\n - 'mona/octocat'\n - 'releases/**-alpha'\n # Sequence of patterns matched against refs/tags\n tags-ignore:\n - v2\n - v1.*\n```\n\n### Exemple : Inclure et exclure des branches et des tags\n\nVous ne pouvez pas utiliser `branches` et `branches-ignore` pour filtrer le même événement dans un même workflow. De même, vous ne pouvez pas utiliser `tags` et `tags-ignore` pour filtrer le même événement dans un même workflow. Si vous souhaitez inclure et exclure des modèles de branche ou d’étiquette pour un seul événement, utilisez le filtre `branches` ou `tags` avec le caractère `!` pour indiquer quelles branches ou étiquettes doivent être exclues.\n\nSi vous définissez une branche avec le caractère `!`, vous devez également définir au moins une branche sans caractère `!`. Si vous souhaitez uniquement exclure des branches, utilisez `branches-ignore` à la place. De même, si vous définissez une étiquette avec le caractère `!`, vous devez également définir au moins une étiquette sans caractère `!`. Si vous souhaitez uniquement exclure des étiquettes, utilisez `tags-ignore` à la place.\n\nL’ordre dans lequel vous définissez les modèles est important.\n\n* Un modèle de correspondance négative (préfixé avec `!`) après une correspondance positive exclut la référence Git.\n* Un modèle de correspondance positive après une correspondance négative inclut à nouveau la référence Git.\n\nLe workflow suivant s’exécute sur les envois push vers `releases/10` ou `releases/beta/mona`, mais pas sur `releases/10-alpha` ou `releases/beta/3-alpha` parce que le modèle négatif `!releases/**-alpha` fait suite au modèle positif. \n\n```yaml\non:\n push:\n branches:\n - 'releases/**'\n - '!releases/**-alpha'\n```\n\n## `on..`\n\nLorsque vous utilisez les événements `push` et `pull_request` événements, vous pouvez configurer un workflow pour qu’il s’exécute en fonction des chemins d’accès aux fichiers qui ont changé. Les filtres de chemin d’accès ne sont pas évalués pour les envois (push) d’étiquettes.\n\nUtilisez le filtre `paths` lorsque vous souhaitez inclure des modèles de chemins d’accès aux fichiers, ou lorsque vous souhaitez à la fois inclure et exclure des modèles de modèles de chemins d’accès aux fichiers. Utilisez le filtre `paths-ignore` lorsque vous souhaitez uniquement exclure modèles de chemins d’accès aux fichiers. Vous ne pouvez pas utiliser les filtres `paths` et `paths-ignore` en même temps pour le même événement dans un workflow. Si vous souhaitez inclure et exclure des modèles de chemin d’accès pour un seul événement, utilisez le filtre `paths` avec en préfixe le caractère `!` pour indiquer les chemins d’accès à exclure.\n\n> \\[!NOTE]\n> L’ordre dans lequel vous définissez les modèles `paths` est important :\n>\n> * Un modèle négatif de correspondance (préfixé avec `!`) après une correspondance positive exclut le chemin d’accès.\n> * Un modèle positif de correspondance après une correspondance négative inclut à nouveau le chemin d’accès.\n\nSi vous définissez à la fois `branches`/`branches-ignore` et `paths`/`paths-ignore`, le workflow s’exécute uniquement quand les deux filtres sont satisfaits.\n\nLes mots clés `paths` et `paths-ignore` acceptent des modèles globaux qui utilisent les caractères génériques `*` et `**` pour faire correspondre plusieurs noms de chemin d’accès. Pour plus d’informations, consultez [Syntaxe de flux de travail pour GitHub Actions](/fr/actions/using-workflows/workflow-syntax-for-github-actions#filter-pattern-cheat-sheet).\n\n### Exemple : Inclusion de chemins d’accès\n\nSi au moins un chemin d’accès correspond à un modèle dans le filtre `paths`, le workflow s’exécute. Par exemple, le workflow suivant s’exécuterait chaque fois que vous envoyez (push) un fichier JavaScript (`.js`).\n\n```yaml\non:\n push:\n paths:\n - '**.js'\n```\n\nSi un workflow est ignoré en raison du filtrage de chemin d’accès, du [filtrage de branche](/fr/actions/using-workflows/workflow-syntax-for-github-actions#onpull_requestpull_request_targetbranchesbranches-ignore) ou d’un [message de commit](/fr/actions/managing-workflow-runs/skipping-workflow-runs), les vérifications associées à ce workflow restent alors à l’état « En attente ». La fusion d’une demande de tirage (pull request) nécessitant la réussite de ces vérifications sera bloquée.\n\n### Exemple : Exclusion de chemins d’accès\n\nLorsque tous les noms de chemin d’accès correspondent à des modèles dans `paths-ignore`, le workflow ne s’exécute pas. Si des noms de chemin d’accès ne correspondent pas à des modèles dans `paths-ignore`, même si certains noms de chemin d’accès correspondent aux modèles, le workflow s’exécute.\n\nUn workflow avec le filtre de chemin d’accès suivant s’exécute uniquement sur des événements `push` qui incluent au moins un fichier en dehors du répertoire `docs` à la racine du dépôt.\n\n```yaml\non:\n push:\n paths-ignore:\n - 'docs/**'\n```\n\n### Exemple : Inclusion et exclusion de chemins d’accès\n\nVous ne pouvez pas utiliser `paths` et `paths-ignore` pour filtrer le même événement dans un seul workflow. Si vous souhaitez inclure et exclure des modèles de chemin d’accès pour un seul événement, utilisez le filtre `paths` avec en préfixe le caractère `!` pour indiquer les chemins d’accès à exclure.\n\nSi vous définissez un chemin d’accès avec le caractère `!`, vous devez également définir au moins un chemin d’accès sans caractère `!`. Si vous souhaitez uniquement exclure des chemins d’accès, utilisez plutôt `paths-ignore`.\n\nL’ordre dans lequel vous définissez les modèles `paths` est important :\n\n* Un modèle négatif de correspondance (préfixé avec `!`) après une correspondance positive exclut le chemin d’accès.\n* Un modèle positif de correspondance après une correspondance négative inclut à nouveau le chemin d’accès.\n\nCet exemple s’exécute à chaque fois que l’événement `push` inclut un fichier dans le répertoire `sub-project` ou ses sous-répertoires, sauf si le fichier se trouve dans le répertoire `sub-project/docs`. Par exemple, un envoi (push) qui change `sub-project/index.js` ou `sub-project/src/index.js` déclenche l’exécution d’un workflow, au contraire d’un envoi (push) changeant uniquement `sub-project/docs/readme.md`.\n\n```yaml\non:\n push:\n paths:\n - 'sub-project/**'\n - '!sub-project/docs/**'\n```\n\n### Comparaisons de différences Git\n\n> \\[!NOTE]\n> Si vous envoyez plus de 1 000 validations ou si GitHub ne génère pas la différence en raison d’un délai d’expiration, le workflow s’exécute toujours.\n\nLe filtre détermine si un workflow doit s’exécuter en évaluant les fichiers modifiés et en les exécutant sur la liste `paths-ignore` ou `paths`. S’il n’y a pas de fichier modifié, le workflow ne s’exécute pas.\n\nGitHub génère la liste des fichiers modifiés à l’aide de différences de deux points pour les envois (push) et de différences de trois points pour les demandes de tirage :\n\n* **Demandes de tirage :** les différences de trois points sont une comparaison entre la version la plus récente de la branche de rubrique, et la validation dans laquelle la branche de rubrique a été synchronisée pour la dernière fois avec la branche de base.\n* **Envois (push) à des branches existantes :** une différence de deux points compare directement les SHA principal et de base.\n* **Envois (push) à nouvelles branches :** une différence de deux points par rapport au parent de l’élément ancêtre de la validation la plus profonde envoyées (push).\n\n> \\[!NOTE]\n> Les différences sont limitées à 300 fichiers. S’il y a des fichiers modifiés qui ne sont pas mis en correspondance dans les 300 premiers fichiers retournés par le filtre, le workflow n’est pas exécuté. Il se peut que vous deviez créer des filtres plus spécifiques afin que le workflow s’exécute automatiquement.\n\nPour plus d’informations, consultez « [Comparaison des branches dans les pull requests](/fr/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-comparing-branches-in-pull-requests) ».\n\n## `on.schedule`\n\nVous pouvez utiliser `on.schedule` pour définir un calendrier pour vos workflows.\n\nUtilisez la [syntaxe cron POSIX](https://pubs.opengroup.org/onlinepubs/9699919799/utilities/crontab.html#tag_20_25_07) pour planifier l’exécution des flux de travail à des moments spécifiques. Par défaut, les flux de travail planifiés s’exécutent au format UTC. Vous pouvez éventuellement spécifier un fuseau horaire à l’aide d’une [chaîne de fuseau horaire IANA](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones) pour la planification prenant en charge le fuseau horaire. Les flux de travail planifiés s’exécutent sur le dernier commit de la branche par défaut. L’intervalle le plus court auquel vous pouvez exécuter des workflows planifiés est une fois toutes les 5 minutes.\n\n> \\[!NOTE]\n> Pour les programmes définis `timezone` sur un fuseau horaire qui observe l'heure d'été, pendant le passage à l'heure d'été, les workflows planifiés pendant les heures sautées avancent jusqu'à la prochaine heure valide. Par exemple, un horaire de 2 h 30 avance à 3 h 00.\n\nLa syntaxe cron comporte cinq champs séparés par un espace, chaque champ représentant une unité de temps.\n\n```text\n┌───────────── minute (0 - 59)\n│ ┌───────────── hour (0 - 23)\n│ │ ┌───────────── day of the month (1 - 31)\n│ │ │ ┌───────────── month (1 - 12 or JAN-DEC)\n│ │ │ │ ┌───────────── day of the week (0 - 6 or SUN-SAT)\n│ │ │ │ │\n* * * * *\n```\n\nVous pouvez utiliser ces opérateurs dans n'importe lequel de ces cinq champs :\n\n| Opérateur | Description | Exemple |\n| --------- | ----------------- | ------- |\n| \\* | Valeur quelconque | |\n\n```\n `15 * * * *` s'exécute à chaque minute 15 de chaque heure de chaque jour. |\n```\n\n\\| , | Séparateur de liste de valeurs |\n`2,10 4,5 * * *` s'exécute à la 2ème et à la 10ème minute de chaque 4ème et 5ème heure de la journée. |\n\\| - | Plage de valeurs |\n`30 4-6 * * *` s'exécute à la 30e minute des 4e, 5e et 6e heures. |\n\\| / | Valeurs d'étape |\n`20/15 * * * *` s'exécute toutes les 15 minutes de la minute 20 à 59 (minutes 20, 35 et 50). |\n\nCet exemple déclenche l’exécution du flux de travail à 5h30 dans le fuseau horaire de New York, du lundi au vendredi :\n\n```yaml\non:\n schedule:\n - cron: '30 5 * * 1-5'\n timezone: \"America/New_York\"\n```\n\nUn seul workflow peut être déclenché par plusieurs événements `schedule`. Accédez à l’événement `schedule` qui a déclenché le flux de travail via le contexte `github.event.schedule`. Dans cet exemple, le flux de travail est déclenché à 5h30 UTC tous les jours du lundi au jeudi, et à 17h30 UTC les mardis et jeudis, mais l’étape `Not on Monday or Wednesday` est ignorée les lundis et mercredis.\n\n```yaml\non:\n schedule:\n - cron: '30 5 * * 1,3'\n - cron: '30 5,17 * * 2,4'\n\njobs:\n test_schedule:\n runs-on: ubuntu-latest\n steps:\n - name: Not on Monday or Wednesday\n if: github.event.schedule != '30 5 * * 1,3'\n run: echo \"This step will be skipped on Monday and Wednesday\"\n - name: Every time\n run: echo \"This step will always run\"\n```\n\nPour plus d’informations sur les événements `schedule`, consultez [Événements qui déclenchent des flux de travail](/fr/actions/reference/workflows-and-actions/events-that-trigger-workflows#schedule).\n\n## `on.workflow_call`\n\nUtilisez `on.workflow_call` pour définir les entrées et sorties d’un workflow réutilisable. Vous pouvez également mapper les secrets disponibles au workflow appelé. Pour plus d’informations sur les flux de travail réutilisables, consultez « [Réutiliser des workflows](/fr/actions/using-workflows/reusing-workflows) ».\n\n## `on.workflow_call.inputs`\n\nLorsque vous utilisez le mot clé `workflow_call`, vous pouvez éventuellement spécifier des entrées qui sont passées au workflow appelé à partir du workflow appelant. Pour plus d’informations sur le mot clé `workflow_call`, consultez « [Événements qui déclenchent des flux de travail](/fr/actions/using-workflows/events-that-trigger-workflows#workflow-reuse-events) ».\n\nEn plus des paramètres d’entrée standard disponibles, `on.workflow_call.inputs` nécessite un paramètre `type`. Pour plus d’informations, consultez [`on.workflow_call.inputs..type`](#onworkflow_callinputsinput_idtype).\n\nSi aucun paramètre `default` n’est défini, la valeur par défaut de l’entrée est `false` pour une valeur booléenne, `0` pour un nombre et `\"\"` pour une chaîne.\n\nDans le workflow appelé, vous pouvez utiliser le contexte `inputs` pour référencer une entrée. Pour plus d’informations, consultez « [Référence des contextes](/fr/actions/learn-github-actions/contexts#inputs-context) ».\n\nSi un workflow appelant passe une entrée qui n’est pas spécifiée dans le workflow appelé, cela entraîne une erreur.\n\n### Exemple de `on.workflow_call.inputs`\n\n```yaml\non:\n workflow_call:\n inputs:\n username:\n description: 'A username passed from the caller workflow'\n default: 'john-doe'\n required: false\n type: string\n\njobs:\n print-username:\n runs-on: ubuntu-latest\n\n steps:\n - name: Print the input name to STDOUT\n run: echo The username is ${{ inputs.username }}\n```\n\nPour plus d’informations, consultez « [Réutiliser des workflows](/fr/actions/using-workflows/reusing-workflows) ».\n\n## `on.workflow_call.inputs..type`\n\nObligatoire si l’entrée est définie pour le mot clé `on.workflow_call`. La valeur de ce paramètre est une chaîne spécifiant le type de données de l’entrée. Il doit s’agir de l’une des valeurs suivantes : `boolean`, `number` ou `string`.\n\n## `on.workflow_call.outputs`\n\nCarte des sorties pour un workflow appelé. Les sorties de workflow appelé sont disponibles pour tous les travaux en aval dans le workflow appelant. Chaque sortie a un identificateur, une `description,` facultative et un `value.`. Le `value` doit être défini sur la valeur d'une sortie d'un travail dans le workflow appelé.\n\nDans l’exemple ci-dessous, deux sorties sont définies pour ce workflow réutilisable : `workflow_output1` et `workflow_output2`. Celles-ci sont mappées aux sorties appelées `job_output1` et `job_output2`, toutes les deux provenant d’un travail appelé `my_job`.\n\n### Exemple de `on.workflow_call.outputs`\n\n```yaml\non:\n workflow_call:\n # Map the workflow outputs to job outputs\n outputs:\n workflow_output1:\n description: \"The first job output\"\n value: ${{ jobs.my_job.outputs.job_output1 }}\n workflow_output2:\n description: \"The second job output\"\n value: ${{ jobs.my_job.outputs.job_output2 }}\n```\n\nPour plus d’informations sur la façon de référencer une sortie de travail, consultez [`jobs..outputs`](#jobsjob_idoutputs). Pour plus d’informations, consultez « [Réutiliser des workflows](/fr/actions/using-workflows/reusing-workflows) ».\n\n## `on.workflow_call.secrets`\n\nUne carte des secrets qui peuvent être utilisés dans le workflow appelé.\n\nDans le workflow appelé, vous pouvez utiliser le contexte `secrets` pour faire référence à un secret.\n\n> \\[!NOTE]\n> Si vous transmettez le secret à un flux de travail réutilisable imbriqué, vous devez utiliser à nouveau [`jobs..secrets`](#jobsjob_idsecrets)pour transmettre le secret. Pour plus d’informations, consultez « [Réutiliser des workflows](/fr/actions/using-workflows/reusing-workflows#passing-secrets-to-nested-workflows) ».\n\nSi un workflow appelant passe un secret qui n’est pas spécifié dans le workflow appelé, cela entraîne une erreur.\n\n### Exemple de `on.workflow_call.secrets`\n\n```yaml\non:\n workflow_call:\n secrets:\n access-token:\n description: 'A token passed from the caller workflow'\n required: false\n\njobs:\n\n pass-secret-to-action:\n runs-on: ubuntu-latest\n steps:\n # passing the secret to an action\n - name: Pass the received secret to an action\n uses: ./.github/actions/my-action\n with:\n token: ${{ secrets.access-token }}\n\n # passing the secret to a nested reusable workflow\n pass-secret-to-workflow:\n uses: ./.github/workflows/my-workflow\n secrets:\n token: ${{ secrets.access-token }}\n```\n\n## `on.workflow_call.secrets.`\n\nIdentificateur de chaîne à associer au secret.\n\n## `on.workflow_call.secrets..required`\n\nValeur booléenne spécifiant si le secret doit être fourni.\n\n## `on.workflow_run.`\n\nLorsque vous utilisez l’événement `workflow_run`, vous pouvez spécifier les branches sur lesquelles le workflow déclencheur doit s’exécuter afin de déclencher votre workflow.\n\nLes filtres `branches` et `branches-ignore` acceptent les modèles Glob qui utilisent des caractères tels que `*`, `**`, `+`, `?`, `!` et certains autres pour correspondre à plusieurs noms de branches. Si un nom contient l’un de ces caractères et que vous souhaitez une correspondance littérale, vous devez *échapper* chacun de ces caractères spéciaux avec `\\`. Pour plus d’informations sur les modèles glob, consultez l’[Syntaxe de flux de travail pour GitHub Actions](/fr/actions/using-workflows/workflow-syntax-for-github-actions#filter-pattern-cheat-sheet).\n\nPar exemple, un workflow avec le déclencheur suivant s’exécute uniquement lorsque le workflow nommé `Build` s’exécute sur une branche dont le nom commence par `releases/` :\n\n```yaml\non:\n workflow_run:\n workflows: [\"Build\"]\n types: [requested]\n branches:\n - 'releases/**'\n```\n\nUn workflow avec le déclencheur suivant s’exécute uniquement lorsque le workflow nommé `Build` s’exécute sur une branche qui n’est pas nommée `canary` :\n\n```yaml\non:\n workflow_run:\n workflows: [\"Build\"]\n types: [requested]\n branches-ignore:\n - \"canary\"\n```\n\nVous ne pouvez pas utiliser les filtres `branches` et `branches-ignore` en même temps pour le même événement dans un workflow. Si vous souhaitez à la fois inclure et exclure des modèles de branche pour un seul événement, utilisez le filtre `branches` avec le caractère `!` pour indiquer les branches à exclure.\n\nL’ordre dans lequel vous définissez les modèles est important.\n\n* Un modèle négatif de correspondance (préfixé avec `!`) après une correspondance positive exclut la branche.\n* Un modèle positif de correspondance après une correspondance négative inclut à nouveau la branche.\n\nPar exemple, un workflow avec le déclencheur suivant s’exécute lorsque le workflow nommé `Build` s’exécute sur une branche nommée `releases/10` ou `releases/beta/mona`, mais pas `releases/10-alpha`, `releases/beta/3-alpha` ni `main`. \n\n```yaml\non:\n workflow_run:\n workflows: [\"Build\"]\n types: [requested]\n branches:\n - 'releases/**'\n - '!releases/**-alpha'\n```\n\n## `on.workflow_dispatch`\n\nQuand vous utilisez l’événement `workflow_dispatch`, vous pouvez éventuellement spécifier des entrées qui sont passées au workflow.\n\nCe déclencheur reçoit uniquement les événements lorsque le fichier de flux de travail se trouve sur la branche par défaut.\n\n## `on.workflow_dispatch.inputs`\n\nLe workflow déclenché reçoit les entrées dans le contexte `inputs`. Pour plus d’informations, consultez [Contextes](/fr/actions/learn-github-actions/contexts#inputs-context).\n\n> \\[!NOTE]\n>\n> * Le workflow recevra également les entrées dans le contexte `github.event.inputs`. Les informations dans le contexte `inputs` et le contexte `github.event.inputs` sont identiques, à l’exception du fait que le contexte `inputs` conserve les valeurs booléennes en tant que valeurs booléennes au lieu de les convertir en chaînes. Le type `choice` est résolu en chaîne et est une option sélectionnable unique.\n> * Le nombre maximal de propriétés de niveau supérieur pour `inputs` 25 .\n> * La charge utile maximale pour `inputs` est de 65 535 caractères.\n\n### Exemple de `on.workflow_dispatch.inputs`\n\n```yaml\non:\n workflow_dispatch:\n inputs:\n logLevel:\n description: 'Log level'\n required: true\n default: 'warning'\n type: choice\n options:\n - info\n - warning\n - debug\n print_tags:\n description: 'True to print to STDOUT'\n required: true\n type: boolean\n tags:\n description: 'Test scenario tags'\n required: true\n type: string\n environment:\n description: 'Environment to run tests against'\n type: environment\n required: true\n\njobs:\n print-tag:\n runs-on: ubuntu-latest\n if: ${{ inputs.print_tags }} \n steps:\n - name: Print the input tag to STDOUT\n run: echo The tags are ${{ inputs.tags }} \n```\n\n## `on.workflow_dispatch.inputs..required`\n\nValeur booléenne spécifiant si l’entrée doit être fournie.\n\n## `on.workflow_dispatch.inputs..type`\n\nLa valeur de ce paramètre est une chaîne spécifiant le type de données de l’entrée. Il doit s’agir de l’une des valeurs suivantes : `boolean`, `choice`, `number`, `environment` ou `string`.\n\n## `permissions`\n\nVous pouvez utiliser `permissions` pour modifier les autorisations par défaut octroyées à `GITHUB_TOKEN`, en ajoutant ou en supprimant l’accès selon les besoins, afin d’autoriser uniquement l’accès minimal nécessaire. Pour plus d’informations, consultez « [Utiliser GITHUB\\_TOKEN pour l’authentification dans les flux de travail](/fr/actions/security-guides/automatic-token-authentication#modifying-the-permissions-for-the-github_token) ».\n\nVous pouvez utiliser `permissions` en tant que clé de niveau supérieur, à appliquer à tous les travaux du workflow ou à des travaux spécifiques. Quand vous ajoutez la clé `permissions` à un travail spécifique, toutes les actions et commandes d’exécution de ce travail qui utilisent `GITHUB_TOKEN` obtiennent les droits d’accès que vous spécifiez. Pour plus d’informations, consultez [`jobs..permissions`](/fr/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idpermissions).\n\nLes propriétaires d’une organisation ont la possibilité de restreindre l’accès en écriture pour le `GITHUB_TOKEN` au niveau du référentiel. Pour plus d’informations, consultez « [Désactivation ou limitation des GitHub Actions pour votre organisation](/fr/organizations/managing-organization-settings/disabling-or-limiting-github-actions-for-your-organization#setting-the-permissions-of-the-github_token-for-your-organization) ».\n\nLorsqu'un workflow est déclenché par l'événement [`pull_request_target`](/fr/actions/using-workflows/events-that-trigger-workflows#pull_request_target), le `GITHUB_TOKEN` reçoit une autorisation de dépôt en lecture/écriture, même s'il est déclenché à partir d'un fork public. Pour plus d’informations, consultez « [Événements qui déclenchent des flux de travail](/fr/actions/using-workflows/events-that-trigger-workflows#pull_request_target) ».\n\nÀ chacune des autorisations disponibles (cf. tableau ci-dessous), vous pouvez attribuer l'un des niveaux d'accès suivants : `read` (le cas échéant), `write` ou `none`.\n`write` comprend `read`. Si vous spécifiez l'accès pour chacune de ces autorisations, toutes celles qui ne sont pas spécifiées seront définies comme `none`.\n\nAutorisations disponibles et détails de l'action déclenchée par chacune :\n\n| Autorisation | Autorise une action à l’aide de `GITHUB_TOKEN` à |\n| ------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| `actions` | Utilisez GitHub Actions. Par exemple, `actions: write` permet à une action d’annuler l’exécution d’un workflow. Pour plus d’informations, consultez « [Autorisations requises pour les applications GitHub](/fr/rest/overview/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-actions) ». |\n| | |\n| `artifact-metadata` | Travaillez avec les métadonnées d'artéfacts. Par exemple, `artifact-metadata: write` autorise l'action de créer des rapports de stockages au non d'un artefact de build. Pour plus d’informations, consultez « [Points de terminaison d’API REST pour les métadonnées d’artefact](/fr/rest/orgs/artifact-metadata?apiVersion=2022-11-28) ». |\n| | |\n| | |\n| `attestations` | Tâche avec des attestations d'artefact. Par exemple, `attestations: write` autorise l'action de générer une attestation d'artefact pour un build. Pour plus d'informations, consultez [Utilisation des attestations d’artefacts pour établir la provenance des builds](/fr/actions/security-guides/using-artifact-attestations-to-establish-provenance-for-builds) |\n| | |\n| `checks` | Utilisez des exécutions de vérifications et des suites de vérifications. Par exemple, `checks: write` permet à une action de créer l’exécution d’une vérification. Pour plus d’informations, consultez « [Autorisations requises pour les applications GitHub](/fr/rest/overview/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-checks) ». |\n| `contents` | Utilisez le contenu du référentiel. Par exemple, `contents: read` autorise une action à répertorier les validations et `contents: write` autorise l’action à créer une mise en production. Pour plus d’informations, consultez « [Autorisations requises pour les applications GitHub](/fr/rest/overview/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-contents) ». |\n| `deployments` | Utilisez des déploiements. Par exemple, `deployments: write` permet à une action de créer un nouveau déploiement. Pour plus d’informations, consultez « [Autorisations requises pour les applications GitHub](/fr/rest/overview/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-deployments) ». |\n| `discussions` | Tâche avec des discussions GitHub. Par exemple, `discussions: write` permet à une action de fermer ou de supprimer une discussion. Pour plus d’informations, consultez « [Utilisation de l’API GraphQL pour les discussions](/fr/graphql/guides/using-the-graphql-api-for-discussions) ». |\n| | |\n| `id-token` | Récupérer un jeton OpenID Connect (OIDC). Cela nécessite `id-token: write`. Pour plus d'informations, consultez [OpenID Connect](/fr/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect#updating-your-actions-for-oidc) |\n| | |\n| `issues` | Tâche avec des problèmes. Par exemple, `issues: write` permet à une action d’ajouter un commentaire à un problème. Pour plus d’informations, consultez « [Autorisations requises pour les applications GitHub](/fr/rest/overview/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-issues) ». |\n| | |\n| `models` | Générer des réponses d’inférence IA avec GitHub Models. Par exemple, `models: read` autorise une action à utiliser l’API d’inférence GitHub Models . Consultez [Prototypage avec des modèles IA](/fr/github-models/prototyping-with-ai-models). |\n| | |\n| `packages` | Tâche avec des packages GitHub. Par exemple, `packages: write` permet à une action de charger et de publier des packages sur des packages GitHub. Pour plus d’informations, consultez « [À propos des autorisations pour les packages GitHub](/fr/packages/learn-github-packages/about-permissions-for-github-packages#about-scopes-and-permissions-for-package-registries) ». |\n| `pages` | Tâche avec des pages GitHub. Par exemple, `pages: write` autorise une action à demander une build GitHub Pages. Pour plus d’informations, consultez « [Autorisations requises pour les applications GitHub](/fr/rest/overview/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-pages) ». |\n| `pull-requests` | Tâche avec des requêtes de tirage. Par exemple, `pull-requests: write` permet à une action d’ajouter une étiquette à une demande de tirage. Pour plus d’informations, consultez « [Autorisations requises pour les applications GitHub](/fr/rest/overview/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-pull-requests) ». |\n| | |\n| `security-events` | Tâche avec des alertes de numérisation de code GitHub. Par exemple, `security-events: read` autorise l'action de répertorier les alertes de numérisation de code pour le référentiel, et `security-events: write` autorise l'action de mettre à jour le statut d'une alerte de numérisation de code. Pour plus d’informations, consultez [Autorisations du référentiel pour « Alertes d’analyse du code ».](/fr/rest/overview/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-code-scanning-alerts)

|\n\n```\n Pour les alertes Dependabot, utilisez l’autorisation `vulnerability-alerts` . Les alertes d’analyse des secrets ne peuvent pas être lues avec cette autorisation et nécessitent une application GitHub ou un personal access token. Pour plus d’informations, consultez [Autorisations du référentiel pour « Scans de secrets »](/rest/overview/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-secret-scanning-alerts) dans « Autorisations requises pour GitHub Apps ». |\n```\n\n\\| `statuses` | Tâche avec des statuts attribués. Par exemple, `statuses:read` autorise une action à répertorier les états de validation pour une référence donnée. Pour plus d’informations, consultez « [Autorisations requises pour les applications GitHub](/fr/rest/overview/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-commit-statuses) ». |\n\\| |\n\\| `vulnerability-alerts` | Lisez les alertes Dependabot. Par exemple, `vulnerability-alerts: read` autorise une action à répertorier les alertes Dependabot pour le référentiel. Uniquement `read` et `none` sont pris en charge ; `write` n’est pas valide. Quand `write-all` ou `read-all` est utilisé, `vulnerability-alerts` est automatiquement inclus en tant que `read`. Pour plus d’informations, consultez [Autorisations du référentiel pour les « alertes Dependabot ».](/fr/rest/overview/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-dependabot-alerts) |\n\\| |\n\n### Définition de l’accès pour les périmètres `GITHUB_TOKEN`\n\nVous pouvez définir l’accès que le `GITHUB_TOKEN` autorise en spécifiant `read`, `write` ou `none` comme valeur des autorisations disponibles dans la clé `permissions`.\n\n```yaml\npermissions:\n actions: read|write|none\n artifact-metadata: read|write|none\n attestations: read|write|none\n checks: read|write|none\n contents: read|write|none\n deployments: read|write|none\n id-token: write|none\n issues: read|write|none\n models: read|none\n discussions: read|write|none\n packages: read|write|none\n pages: read|write|none\n pull-requests: read|write|none\n security-events: read|write|none\n statuses: read|write|none\n vulnerability-alerts: read|none\n```\n\nSi vous spécifiez l’accès pour l’une de ces autorisations, toutes celles qui ne sont pas spécifiées sont définies sur `none`.\n\nVous pouvez utiliser la syntaxe suivante pour définir l'un des accès `read-all` ou `write-all` à toutes les autorisations disponibles :\n\n```yaml\npermissions: read-all\n```\n\n```yaml\npermissions: write-all\n```\n\nVous pouvez utiliser la syntaxe suivante afin de désactiver les autorisations pour toutes les autorisations disponibles :\n\n```yaml\npermissions: {}\n```\n\n#### Modification des autorisations dans un référentiel dupliqué\n\nVous pouvez utiliser la clé `permissions` afin d’ajouter et de supprimer des autorisations d’accès en lecture pour les dépôts dupliqués. Toutefois, en règle générale, vous ne pouvez pas octroyer d’accès en écriture. Il existe une exception à ce comportement. Il s’agit du moment où un utilisateur administrateur a sélectionné l’option **Envoyer des jetons d’écriture aux workflows à partir des demandes de tirage** dans les paramètres de GitHub Actions. Pour plus d’informations, consultez « [Gestion des paramètres de GitHub Actions pour un référentiel](/fr/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#enabling-workflows-for-private-repository-forks) ».\n\n## Calcul des autorisations pour une tâche de workflow\n\nLes autorisations pour le `GITHUB_TOKEN` sont initialement définies sur le paramètre par défaut pour l’entreprise, l’organisation ou le dépôt. Si la valeur par défaut est définie sur les autorisations restreintes à l’un de ces niveaux, cela s’applique aux dépôts appropriés. Par exemple, si vous choisissez la valeur par défaut restreinte au niveau de l’organisation, tous les dépôts de cette organisation utiliseront les autorisations restreintes comme valeur par défaut. Les autorisations sont ensuite ajustées en fonction de n’importe quelle configuration dans le fichier de workflow, d’abord au niveau du workflow, puis au niveau du travail. Enfin, si le flux de travail a été déclenché par un événement de demande de tirage autre que depuis un `pull_request_target` référentiel forké, et que le paramètre **Envoyer des jetons d’écriture aux flux de travail des demandes de tirage** n’est pas sélectionné, les autorisations sont ajustées pour convertir toutes les autorisations d’écriture en lecture seule.\n\n### Définition des autorisations `GITHUB_TOKEN` pour tous les travaux d’un workflow\n\nVous pouvez spécifier `permissions` au niveau supérieur d’un workflow, afin que le paramètre s’applique à tous les travaux du workflow.\n\n#### Exemple : définition des autorisations `GITHUB_TOKEN` pour un workflow entier\n\nCet exemple montre les autorisations définies pour `GITHUB_TOKEN`, qui s’appliquent à tous les travaux du workflow. Toutes les autorisations se voient octroyer un accès en lecture.\n\n```yaml\nname: \"My workflow\"\n\non: [ push ]\n\npermissions: read-all\n\njobs:\n ...\n```\n\n### Utilisation de la clé `permissions` pour les référentiels dupliqués\n\nVous pouvez utiliser la clé `permissions` afin d’ajouter et de supprimer des autorisations d’accès `read` pour les dépôts dupliqués. Toutefois, en règle générale, vous ne pouvez pas octroyer d’accès `write`. L’exception à ce comportement se produit lorsqu’un utilisateur administrateur a sélectionné l’option **Envoyer les jetons d’écriture aux workflows à partir des pull requests** dans les GitHub Actionsparamètres. Pour plus d’informations, consultez « [Gestion des paramètres de GitHub Actions pour un référentiel](/fr/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#enabling-workflows-for-private-repository-forks) ».\n\n### Autorisations pour les exécutions de flux de travail déclenchées par Dependabot\n\nLes exécutions de workflow déclenchées par les demandes de tirage de Dependabot s’exécutent comme si elles provenaient d’un référentiel dupliqué et utilisent donc un `GITHUB_TOKEN` en lecture seule. Ces exécutions de workflow ne peuvent pas accéder à des secrets. Pour plus d’informations sur les stratégies de sécurisation de ces workflows, consultez [Informations de référence sur l’utilisation sécurisée](/fr/actions/security-guides/security-hardening-for-github-actions).\n\n## `env`\n\nUn ensemble (`map`) de variables qui sont disponibles pour les étapes de tous les travaux du workflow. Vous pouvez également définir des variables qui sont disponibles uniquement pour les étapes d’un seul travail ou pour une seule étape. Pour plus d’informations, consultez [`jobs..env`](#jobsjob_idenv) et [`jobs..steps[*].env`](#jobsjob_idstepsenv).\n\nLes variables du mappage `env` ne peuvent pas être définies d’après d’autres variables du mappage.\n\nQuand plusieurs variables d’environnement sont définies avec le même nom, GitHub utilise la variable la plus spécifique. Par exemple, une variable d’environnement définie dans une étape remplace les variables d’environnement du travail et du workflow portant le même nom, pendant l’exécution de l’étape. Une variable d’environnement définie pour un travail remplace une variable de workflow de même nom, pendant l’exécution du travail.\n\n### Exemple de `env`\n\n```yaml\nenv:\n SERVER: production\n```\n\n## `defaults`\n\nUtilisez `defaults` pour créer un `map` de paramètres par défaut qui s’appliqueront à tous les travaux du workflow. Vous pouvez également définir des paramètres par défaut uniquement disponibles pour un travail. Pour plus d’informations, consultez [`jobs..defaults`](/fr/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_iddefaults).\n\nQuand plusieurs paramètres par défaut sont définis avec le même nom, GitHub utilise le paramètre par défaut le plus spécifique. Par exemple, un paramètre par défaut défini dans un travail remplace un paramètre par défaut portant le même nom défini dans un workflow.\n\n## `defaults.run`\n\nVous pouvez utiliser `defaults.run` afin de fournir les options `shell` et `working-directory` par défaut pour toutes les étapes [`run`](/fr/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idstepsrun) d’un workflow. Vous pouvez également définir pour `run` des paramètres par défaut qui sont disponibles uniquement pour un travail. Pour plus d’informations, consultez [`jobs..defaults.run`](/fr/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_iddefaultsrun). Vous ne pouvez pas utiliser de contextes ou d’expressions dans ce mot clé.\n\nQuand plusieurs paramètres par défaut sont définis avec le même nom, GitHub utilise le paramètre par défaut le plus spécifique. Par exemple, un paramètre par défaut défini dans un travail remplace un paramètre par défaut portant le même nom défini dans un workflow.\n\n### Exemple : Définir l’interpréteur de commandes et le répertoire de travail par défaut\n\n```yaml\ndefaults:\n run:\n shell: bash\n working-directory: ./scripts\n```\n\n## `defaults.run.shell`\n\nUtilise `shell` pour définir le `shell` d'une étape. Ce mot clé peut référencer plusieurs contextes. Pour plus d’informations, consultez [Contextes](/fr/actions/learn-github-actions/contexts#context-availability).\n\n| Plateforme prise en charge | Paramètre `shell` | Description | Commande exécutée en interne |\n| -------------------------- | ----------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------- |\n| Linux / macOS | unspecified | Interpréteur de commandes par défaut sur les plateformes non Windows. Notez que cette opération exécute une commande différente par rapport à quand `bash` est spécifié explicitement. Si `bash` n’est pas trouvé dans le chemin, il est considéré comme `sh`. | `bash -e {0}` |\n| Tous | `bash` | Interpréteur de commandes par défaut sur les plateformes non Windows avec `sh` comme valeur de secours. Lors de la spécification d’un interpréteur de commandes Bash sur Windows, l’interpréteur de commandes Bash inclus avec Git pour Windows est utilisé. | `bash --noprofile --norc -eo pipefail {0}` |\n| Tous | `pwsh` | PowerShell Core. GitHub ajoute l’extension `.ps1` au nom de votre script. | `pwsh -command \". '{0}'\"` |\n| Tous | `python` | Exécute la commande Python. | `python {0}` |\n| Linux / macOS | `sh` | Comportement de secours pour les plateformes non Windows si aucun interpréteur de commandes n’est fourni et que `bash` ne se trouve pas dans le chemin. | `sh -e {0}` |\n| Windows | `cmd` | GitHub ajoute l’extension `.cmd` au nom de votre script et se substitue à `{0}`. | `%ComSpec% /D /E:ON /V:OFF /S /C \"CALL \"{0}\"\"`. |\n| Windows | `pwsh` | Il s’agit de l’interpréteur de commandes par défaut utilisé sur Windows. PowerShell Core. GitHub ajoute l’extension `.ps1` au nom de votre script. Si *PowerShell Core* n’est pas installé sur votre exécuteur Windows auto-hébergé, *PowerShell Desktop* est utilisé à la place. | `pwsh -command \". '{0}'\"`. |\n| Windows | `powershell` | PowerShell Desktop. GitHub ajoute l’extension `.ps1` au nom de votre script. | `powershell -command \". '{0}'\"`. |\n\nQuand plusieurs paramètres par défaut sont définis avec le même nom, GitHub utilise le paramètre par défaut le plus spécifique. Par exemple, un paramètre par défaut défini dans un travail remplace un paramètre par défaut portant le même nom défini dans un workflow.\n\n## `defaults.run.working-directory`\n\nUtilise `working-directory` pour définir le répertoire de travail pour le `shell` d'une étape. Ce mot clé peut référencer plusieurs contextes. Pour plus d’informations, consultez [Contextes](/fr/actions/learn-github-actions/contexts#context-availability).\n\n> \\[!TIP]\n> Assurez-vous que le `working-directory` que vous affectez existe sur l'exécuteur avant toute exécution du shell dans ce dernier.\n> Quand plusieurs paramètres par défaut sont définis avec le même nom, GitHub utilise le paramètre par défaut le plus spécifique. Par exemple, un paramètre par défaut défini dans un travail remplace un paramètre par défaut portant le même nom défini dans un workflow.\n\n## `concurrency`\n\nUtilisez `concurrency` pour vérifier qu’un seul travail ou workflow utilisant le même groupe d’accès concurrentiel s’exécute à la fois. Un groupe d’accès concurrentiel peut correspondre à n’importe quelle chaîne ou expression. L’expression peut uniquement utiliser les contextes [`github`](/fr/actions/learn-github-actions/contexts#github-context), [`inputs`](/fr/actions/learn-github-actions/contexts#inputs-context) et [`vars`](/fr/actions/learn-github-actions/contexts#vars-context). Pour plus d’informations sur les expressions, consultez [Évaluer des expressions dans les workflows et les actions.](/fr/actions/learn-github-actions/expressions).\n\nVous pouvez également spécifier `concurrency` au niveau du travail. Pour plus d’informations, consultez [`jobs..concurrency`](/fr/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idconcurrency).\n\nCela signifie qu’il peut y avoir au plus un travail en cours d’exécution ou un workflow dans un groupe de concurrence à tout moment. Quand un travail ou un workflow simultané est mis en file d’attente, si un autre travail ou workflow utilisant le même groupe d’accès concurrentiel dans le dépôt est en cours d’exécution, le travail ou le workflow en file d’attente a la valeur `pending`. Par défaut, tout travail ou flux de travail existant `pending` dans le même groupe de concurrence sera annulé et le nouveau travail ou flux de travail mis en file d'attente prendra sa place.\n\nPour annuler également un travail ou un workflow en cours d’exécution dans le même groupe d’accès concurrentiel, spécifiez `cancel-in-progress: true`. Pour annuler de façon conditionnelle les travaux ou les flux de travail en cours d’exécution dans le même groupe d’accès concurrentiel, vous pouvez spécifier `cancel-in-progress` en tant qu’expression avec l’un des contextes d’expression autorisés.\n\nPour autoriser plusieurs `pending` exécutions de travail ou de flux de travail à attendre dans le même groupe d’accès concurrentiel, utilisez la propriété facultative `queue` . La `queue` propriété accepte les valeurs suivantes :\n\n* `single` (valeur par défaut) : Au plus un travail ou une exécution de flux de travail peut se trouver `pending` dans le groupe d’accès concurrentiel. Lorsqu’une nouvelle exécution de travail ou de flux de travail est mise en file d’attente, toute exécution de travail ou de flux de travail existante `pending` dans le même groupe est annulée et remplacée.\n* `max`: jusqu’à 100 travaux ou exécutions de flux de travail peuvent être `pending` dans le groupe de concurrence. Lorsque la file d’attente est pleine, les travaux supplémentaires ou les exécutions de flux de travail sont annulées.\n\nLa combinaison de `queue: max` et de `cancel-in-progress: true` n'est pas autorisée et entraînera une erreur de validation du flux de travail.\n\n> \\[!NOTE]\n>\n> * Le nom du groupe de concurrence n'est pas sensible à la casse. Par exemple, `prod` et `Prod` seront traités comme le même groupe de concurrence.\n> * Les tâches ou exécutions de flux de travail dans le même groupe de concurrence sont traitées selon l'ordre PEPS (premier entré, premier sorti) en fonction du moment où chacune a commencé à attendre dans le groupe de concurrence, plutôt que du moment où chaque flux de travail a été distribué. Étant donné que l’heure de début réelle d’un travail ou d’une exécution peut varier, l’ordre n’est pas garanti.\n\n### Exemple : utilisation de la concurrence et du comportement par défaut\n\nLe comportement par défaut consiste à autoriser l’exécution simultanée de GitHub Actions plusieurs travaux ou flux de travail. Le mot clé `concurrency` vous permet de contrôler la concurrence des exécutions de flux de travail.\n\nPar exemple, vous pouvez utiliser le mot clé `concurrency` immédiatement après le lieu de définition des conditions de déclenchement afin de limiter la concurrence des exécutions de l'ensemble du flux de travail pour une branche spécifique :\n\n```yaml\non:\n push:\n branches:\n - main\n\nconcurrency:\n group: ${{ github.workflow }}-${{ github.ref }}\n cancel-in-progress: true\n```\n\nVous pouvez également limiter la concurrence des projets au sein d'un flux de travail en utilisant le mot-clé `concurrency` au niveau du projet :\n\n```yaml\non:\n push:\n branches:\n - main\n\njobs:\n job-1:\n runs-on: ubuntu-latest\n concurrency:\n group: example-group\n cancel-in-progress: true\n```\n\n### Exemple : groupes de concurrence\n\nLes groupes de concurrence permettent de gérer et de limiter l'exécution des flux de travail ou des projets qui partagent la même clé de concurrence.\n\nLa clé `concurrency` est utilisée pour regrouper des flux de travail ou des projets ensemble dans un groupe de concurrence. Lorsque vous définissez une `concurrency` clé, GitHub Actions garantit qu’un seul flux de travail ou travail avec cette clé s’exécute à tout moment. Si une nouvelle exécution ou un travail commence avec la même `concurrency` clé, GitHub Actions annulera toute exécution ou travail déjà en cours avec cette clé. La clé `concurrency` peut être une chaîne codée en dur, ou il peut s'agir d'une expression dynamique qui inclut des variables de contexte.\n\nIl est possible de définir des conditions de concurrence dans votre flux de travail afin que le flux de travail ou le projet fasse partie d'un groupe de concurrence.\n\nEn d'autres termes, lorsqu'un flux de travail ou un projet est lancé, GitHub annule tous les flux de travail ou projets déjà en cours dans le même groupe de concurrence. Cette fonction est utile dans les scénarios où vous souhaitez empêcher les exécutions parallèles pour un certain ensemble de flux de travail ou de projets, comme ceux utilisés pour les déploiements dans un environnement intermédiaire, afin d'éviter les actions susceptibles de provoquer des conflits ou de consommer plus de ressources qu'il n'est nécessaire.\n\nDans cet exemple, `job-1` fait partie d'un groupe de concurrence nommé `staging_environment`. En d'autres termes, si une nouvelle exécution de `job-1` est déclenchée, toutes les exécutions du même projet dans le groupe de concurrence `staging_environment` qui sont déjà en cours seront annulées.\n\n```yaml\njobs:\n job-1:\n runs-on: ubuntu-latest\n concurrency:\n group: staging_environment\n cancel-in-progress: true\n```\n\nPar ailleurs, l'utilisation d'une expression dynamique comme `concurrency: ci-${{ github.ref }}` dans votre flux de travail signifie que le flux de travail ou le projet fera partie d'un groupe de concurrence dont le nom `ci-` est suivi de la référence de la branche ou de la balise qui a déclenché le flux de travail. Dans cet exemple, si un nouveau commit est poussé vers la branche principale alors qu'une exécution précédente est toujours en cours, cette dernière sera annulée et la nouvelle commencera.\n\n```yaml\non:\n push:\n branches:\n - main\n\nconcurrency:\n group: ci-${{ github.ref }}\n cancel-in-progress: true\n```\n\n### Exemple : Mise en file d’attente de plusieurs exécutions en attente\n\nPar défaut, une seule exécution de travail ou de flux de travail peut se trouver `pending` dans un groupe d’accès concurrentiel à la fois. Pour autoriser plusieurs exécutions à être ajoutées à la file d'attente plutôt que d'être annulées, définissez `queue: max`. Avec `queue: max`, jusqu’à 100 travaux ou exécutions de flux de travail peuvent attendre dans le groupe d’accès concurrentiel ; une fois la file d’attente remplie, toutes les exécutions supplémentaires sont annulées.\n\nPar exemple, les déploiements de flux de travail suivants sont mis en file d’attente dans l’environnement `production` , en les traitant un à la fois en fonction du moment où chaque exécution a commencé à attendre le groupe d’accès concurrentiel :\n\n```yaml\non:\n push:\n branches:\n - main\n\nconcurrency:\n group: production-deploy\n queue: max\n```\n\nNotez que `queue: max` ne peut pas être combiné avec `cancel-in-progress: true`, car les deux options décrivent des comportements contradictoires pour la gestion des exécutions en cours.\n\n### Exemple : Utilisation de la concurrence pour annuler un travail ou une exécution en cours\n\nPour utiliser la concurrence pour annuler un travail ou une exécution en cours dans GitHub Actions, vous pouvez utiliser la clé `concurrency` avec l’option `cancel-in-progress` définie sur `true`.\n\n```yaml\nconcurrency:\n group: ${{ github.ref }}\n cancel-in-progress: true\n```\n\nRemarquez que dans cet exemple, sans définir de groupe de concurrence particulier, GitHub Actions annulera *toute* exécution en cours de la tâche ou du flux de travail.\n\n### Exemple : Utilisation d’une valeur de secours\n\nSi vous créez le nom de groupe avec une propriété définie uniquement pour des événements spécifiques, vous pouvez utiliser une valeur de secours. Par exemple, `github.head_ref` est défini uniquement pour les événements `pull_request`. Si votre workflow répond à d’autres événements en plus des événements `pull_request`, vous devez fournir une valeur de secours pour éviter une erreur de syntaxe. Le groupe d’accès concurrentiel suivant annule les travaux ou les exécutions en cours pour les événements `pull_request` uniquement. Si `github.head_ref` n’est pas défini, le groupe d’accès concurrent utilise l’ID d’exécution, qui offre la garantie d’être à la fois unique et défini pour l’exécution.\n\n```yaml\nconcurrency:\n group: ${{ github.head_ref || github.run_id }}\n cancel-in-progress: true\n```\n\n### Exemple : Annuler uniquement les travaux ou les exécutions en cours pour le workflow actuel\n\nSi vous avez plusieurs workflows dans le même dépôt, les noms de groupes de concurrence doivent être uniques entre les workflows pour éviter d'annuler des tâches ou des exécutions en cours provenant d'autres workflows. Sinon, tout travail en cours ou en attente est annulé, quel que soit le workflow.\n\nPour annuler uniquement les exécutions en cours du même workflow, vous pouvez utiliser la propriété `github.workflow` afin de créer le groupe d’accès concurrentiel :\n\n```yaml\nconcurrency:\n group: ${{ github.workflow }}-${{ github.ref }}\n cancel-in-progress: true\n```\n\n### Exemple : Annuler uniquement les travaux en cours sur des branches spécifiques\n\nSi vous souhaitez annuler des travaux en cours sur certaines branches, mais pas sur d’autres, vous pouvez utiliser des expressions conditionnelles avec `cancel-in-progress`. Par exemple, vous pouvez procéder ainsi si vous souhaitez annuler les processus en cours sur les branches de développement, mais pas sur les branches de release.\n\nPour n’annuler que les exécutions en cours du même workflow lorsqu’il n’est pas exécuté sur une branche de publication, vous pouvez définir `cancel-in-progress` comme une expression similaire à la suivante :\n\n```yaml\nconcurrency:\n group: ${{ github.workflow }}-${{ github.ref }}\n cancel-in-progress: ${{ !contains(github.ref, 'release/')}}\n```\n\nDans cet exemple, plusieurs envois push vers une branche `release/1.2.3` n’annulent pas les exécutions en cours. Les envois (push) vers une autre branche, par exemple `main`, annulent les exécutions en cours.\n\n## `jobs`\n\nUne exécution de workflow est composée d’un ou de plusieurs `jobs`, qui s’exécutent en parallèle par défaut. Pour exécuter des travaux de manière séquentielle, vous pouvez définir des dépendances par rapport à d’autres travaux à l’aide du mot clé `jobs..needs`.\n\nChaque travail s’exécute dans un environnement d’exécuteur spécifié par `runs-on`.\n\nVous pouvez exécuter un nombre illimité de travaux tant que vous respectez les limites d’utilisation du workflow. Pour plus d’informations, consultez [Facturation et utilisation](/fr/actions/learn-github-actions/usage-limits-billing-and-administration) pour les exécuteurs hébergés par GitHub et [Limites d’Actions](/fr/actions/hosting-your-own-runners/managing-self-hosted-runners/usage-limits-for-self-hosted-runners) pour les limites d’utilisation des exécuteurs auto-hébergés.\n\nSi vous devez trouver l’identificateur unique d’un travail en cours d’exécution dans un flux de travail, vous pouvez utiliser l’API GitHub. Pour plus d’informations, consultez « [Points de terminaison d’API REST pour GitHub Actions](/fr/rest/actions#workflow-jobs) ».\n\n## `jobs.`\n\nUtilisez `jobs.` pour attribuer un identificateur unique à votre travail. La clé `job_id` est une chaîne et sa valeur est une carte des données de configuration du travail. Vous devez remplacer `` par une chaîne propre à l’objet `jobs`. `` doit commencer par une lettre ou par `_`, et contenir uniquement des caractères alphanumériques, des `-` ou des `_`.\n\n### Exemple : Création de travaux\n\nDans cet exemple, deux travaux ont été créés, et leurs valeurs `job_id` sont `my_first_job` et `my_second_job`.\n\n```yaml\njobs:\n my_first_job:\n name: My first job\n my_second_job:\n name: My second job\n```\n\n## `jobs..name`\n\nUtilisez `jobs..name` pour définir un nom pour le travail, qui s’affiche sur l’interface utilisateur GitHub.\n\n## `jobs..permissions`\n\nPour un travail spécifique, vous pouvez utiliser `jobs..permissions` afin de modifier les autorisations par défaut octroyées à `GITHUB_TOKEN`, en ajoutant ou en supprimant l’accès selon les besoins, afin d’autoriser uniquement l’accès minimal nécessaire. Pour plus d’informations, consultez « [Utiliser GITHUB\\_TOKEN pour l’authentification dans les flux de travail](/fr/actions/security-guides/automatic-token-authentication#modifying-the-permissions-for-the-github_token) ».\n\nEn spécifiant l’autorisation dans une définition de travail, vous pouvez configurer un ensemble d’autorisations différent pour le `GITHUB_TOKEN` de chaque travail, le cas échéant. Vous pouvez également spécifier les autorisations relatives à tous les travaux du workflow. Pour plus d’informations sur la définition d’autorisations au niveau du workflow, consultez [`permissions`](/fr/actions/using-workflows/workflow-syntax-for-github-actions#permissions).\n\nÀ chacune des autorisations disponibles (cf. tableau ci-dessous), vous pouvez attribuer l'un des niveaux d'accès suivants : `read` (le cas échéant), `write` ou `none`.\n`write` comprend `read`. Si vous spécifiez l'accès pour chacune de ces autorisations, toutes celles qui ne sont pas spécifiées seront définies comme `none`.\n\nAutorisations disponibles et détails de l'action déclenchée par chacune :\n\n| Autorisation | Autorise une action à l’aide de `GITHUB_TOKEN` à |\n| ------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| `actions` | Utilisez GitHub Actions. Par exemple, `actions: write` permet à une action d’annuler l’exécution d’un workflow. Pour plus d’informations, consultez « [Autorisations requises pour les applications GitHub](/fr/rest/overview/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-actions) ». |\n| | |\n| `artifact-metadata` | Travaillez avec les métadonnées d'artéfacts. Par exemple, `artifact-metadata: write` autorise l'action de créer des rapports de stockages au non d'un artefact de build. Pour plus d’informations, consultez « [Points de terminaison d’API REST pour les métadonnées d’artefact](/fr/rest/orgs/artifact-metadata?apiVersion=2022-11-28) ». |\n| | |\n| | |\n| `attestations` | Tâche avec des attestations d'artefact. Par exemple, `attestations: write` autorise l'action de générer une attestation d'artefact pour un build. Pour plus d'informations, consultez [Utilisation des attestations d’artefacts pour établir la provenance des builds](/fr/actions/security-guides/using-artifact-attestations-to-establish-provenance-for-builds) |\n| | |\n| `checks` | Utilisez des exécutions de vérifications et des suites de vérifications. Par exemple, `checks: write` permet à une action de créer l’exécution d’une vérification. Pour plus d’informations, consultez « [Autorisations requises pour les applications GitHub](/fr/rest/overview/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-checks) ». |\n| `contents` | Utilisez le contenu du référentiel. Par exemple, `contents: read` autorise une action à répertorier les validations et `contents: write` autorise l’action à créer une mise en production. Pour plus d’informations, consultez « [Autorisations requises pour les applications GitHub](/fr/rest/overview/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-contents) ». |\n| `deployments` | Utilisez des déploiements. Par exemple, `deployments: write` permet à une action de créer un nouveau déploiement. Pour plus d’informations, consultez « [Autorisations requises pour les applications GitHub](/fr/rest/overview/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-deployments) ». |\n| `discussions` | Tâche avec des discussions GitHub. Par exemple, `discussions: write` permet à une action de fermer ou de supprimer une discussion. Pour plus d’informations, consultez « [Utilisation de l’API GraphQL pour les discussions](/fr/graphql/guides/using-the-graphql-api-for-discussions) ». |\n| | |\n| `id-token` | Récupérer un jeton OpenID Connect (OIDC). Cela nécessite `id-token: write`. Pour plus d'informations, consultez [OpenID Connect](/fr/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect#updating-your-actions-for-oidc) |\n| | |\n| `issues` | Tâche avec des problèmes. Par exemple, `issues: write` permet à une action d’ajouter un commentaire à un problème. Pour plus d’informations, consultez « [Autorisations requises pour les applications GitHub](/fr/rest/overview/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-issues) ». |\n| | |\n| `models` | Générer des réponses d’inférence IA avec GitHub Models. Par exemple, `models: read` autorise une action à utiliser l’API d’inférence GitHub Models . Consultez [Prototypage avec des modèles IA](/fr/github-models/prototyping-with-ai-models). |\n| | |\n| `packages` | Tâche avec des packages GitHub. Par exemple, `packages: write` permet à une action de charger et de publier des packages sur des packages GitHub. Pour plus d’informations, consultez « [À propos des autorisations pour les packages GitHub](/fr/packages/learn-github-packages/about-permissions-for-github-packages#about-scopes-and-permissions-for-package-registries) ». |\n| `pages` | Tâche avec des pages GitHub. Par exemple, `pages: write` autorise une action à demander une build GitHub Pages. Pour plus d’informations, consultez « [Autorisations requises pour les applications GitHub](/fr/rest/overview/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-pages) ». |\n| `pull-requests` | Tâche avec des requêtes de tirage. Par exemple, `pull-requests: write` permet à une action d’ajouter une étiquette à une demande de tirage. Pour plus d’informations, consultez « [Autorisations requises pour les applications GitHub](/fr/rest/overview/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-pull-requests) ». |\n| | |\n| `security-events` | Tâche avec des alertes de numérisation de code GitHub. Par exemple, `security-events: read` autorise l'action de répertorier les alertes de numérisation de code pour le référentiel, et `security-events: write` autorise l'action de mettre à jour le statut d'une alerte de numérisation de code. Pour plus d’informations, consultez [Autorisations du référentiel pour « Alertes d’analyse du code ».](/fr/rest/overview/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-code-scanning-alerts)

|\n\n```\n Pour les alertes Dependabot, utilisez l’autorisation `vulnerability-alerts` . Les alertes d’analyse des secrets ne peuvent pas être lues avec cette autorisation et nécessitent une application GitHub ou un personal access token. Pour plus d’informations, consultez [Autorisations du référentiel pour « Scans de secrets »](/rest/overview/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-secret-scanning-alerts) dans « Autorisations requises pour GitHub Apps ». |\n```\n\n\\| `statuses` | Tâche avec des statuts attribués. Par exemple, `statuses:read` autorise une action à répertorier les états de validation pour une référence donnée. Pour plus d’informations, consultez « [Autorisations requises pour les applications GitHub](/fr/rest/overview/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-commit-statuses) ». |\n\\| |\n\\| `vulnerability-alerts` | Lisez les alertes Dependabot. Par exemple, `vulnerability-alerts: read` autorise une action à répertorier les alertes Dependabot pour le référentiel. Uniquement `read` et `none` sont pris en charge ; `write` n’est pas valide. Quand `write-all` ou `read-all` est utilisé, `vulnerability-alerts` est automatiquement inclus en tant que `read`. Pour plus d’informations, consultez [Autorisations du référentiel pour les « alertes Dependabot ».](/fr/rest/overview/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-dependabot-alerts) |\n\\| |\n\n### Définition de l’accès pour les périmètres `GITHUB_TOKEN`\n\nVous pouvez définir l’accès que le `GITHUB_TOKEN` autorise en spécifiant `read`, `write` ou `none` comme valeur des autorisations disponibles dans la clé `permissions`.\n\n```yaml\npermissions:\n actions: read|write|none\n artifact-metadata: read|write|none\n attestations: read|write|none\n checks: read|write|none\n contents: read|write|none\n deployments: read|write|none\n id-token: write|none\n issues: read|write|none\n models: read|none\n discussions: read|write|none\n packages: read|write|none\n pages: read|write|none\n pull-requests: read|write|none\n security-events: read|write|none\n statuses: read|write|none\n vulnerability-alerts: read|none\n```\n\nSi vous spécifiez l’accès pour l’une de ces autorisations, toutes celles qui ne sont pas spécifiées sont définies sur `none`.\n\nVous pouvez utiliser la syntaxe suivante pour définir l'un des accès `read-all` ou `write-all` à toutes les autorisations disponibles :\n\n```yaml\npermissions: read-all\n```\n\n```yaml\npermissions: write-all\n```\n\nVous pouvez utiliser la syntaxe suivante afin de désactiver les autorisations pour toutes les autorisations disponibles :\n\n```yaml\npermissions: {}\n```\n\n#### Modification des autorisations dans un référentiel dupliqué\n\nVous pouvez utiliser la clé `permissions` afin d’ajouter et de supprimer des autorisations d’accès en lecture pour les dépôts dupliqués. Toutefois, en règle générale, vous ne pouvez pas octroyer d’accès en écriture. Il existe une exception à ce comportement. Il s’agit du moment où un utilisateur administrateur a sélectionné l’option **Envoyer des jetons d’écriture aux workflows à partir des demandes de tirage** dans les paramètres de GitHub Actions. Pour plus d’informations, consultez « [Gestion des paramètres de GitHub Actions pour un référentiel](/fr/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#enabling-workflows-for-private-repository-forks) ».\n\n#### Exemple : définition des autorisations `GITHUB_TOKEN` pour un travail dans un workflow\n\nCet exemple montre les autorisations définies pour `GITHUB_TOKEN`, qui s’appliquent uniquement au travail nommé `stale`. L’accès en écriture est octroyé pour les autorisations `issues` et `pull-requests`. Toutes les autres autorisations n’ont aucun accès.\n\n```yaml\njobs:\n stale:\n runs-on: ubuntu-latest\n\n permissions:\n issues: write\n pull-requests: write\n\n steps:\n - uses: actions/stale@v10\n```\n\n## `jobs..needs`\n\nUtilisez `jobs..needs` pour identifier les travaux à accomplir avant l’exécution de ce travail. Il peut s’agir d’une chaîne ou d’un tableau de chaînes. Si un travail échoue ou est ignoré, tous les travaux qui besoin de celui-ci sont ignorés, sauf s’ils utilisent une expression conditionnelle entraînant la poursuite du travail. Si une exécution contient une série de travaux qui ont besoin l’un de l’autre, une défaillance ou l’action d’ignorer s’applique à tous les travaux de la chaîne de dépendance à partir du point en question. Si vous souhaitez qu’un travail s’exécute même si un travail dont il dépend n’a pas réussi, utilisez l’expression conditionnelle `always()` dans `jobs..if`.\n\n### Exemple : Exigence de réussite de travaux dépendants\n\n```yaml\njobs:\n job1:\n job2:\n needs: job1\n job3:\n needs: [job1, job2]\n```\n\nDans cet exemple, `job1` doit être correctement accompli avant que `job2` commence, et `job3` attend que `job1` et `job2` soient accomplis.\n\nLes travaux dans cet exemple s’exécutent séquentiellement :\n\n1. `job1`\n2. `job2`\n3. `job3`\n\n### Exemple : Non-exigence de réussite de travaux dépendants\n\n```yaml\njobs:\n job1:\n job2:\n needs: job1\n job3:\n if: ${{ always() }}\n needs: [job1, job2]\n```\n\nDans cet exemple, `job3` utilise l’expression conditionnelle `always()` afin de toujours s’exécuter après que `job1` et `job2` ont été effectués avec ou sans succès. Pour plus d’informations, consultez « [Évaluer des expressions dans les workflows et les actions.](/fr/actions/learn-github-actions/expressions#status-check-functions) ».\n\n## `jobs..if`\n\nVous pouvez utiliser le `jobs..if` conditionnel pour empêcher l’exécution d’un travail, sauf si une condition est remplie. Vous pouvez utiliser n’importe quel contexte et n’importe quelle expression pris en charge pour créer un conditionnel. Pour plus d’informations sur les contextes pris en charge dans cette clé, consultez [Référence des contextes](/fr/actions/learn-github-actions/contexts#context-availability).\n\n> \\[!NOTE]\n> La condition `jobs..if` est évaluée avant que [`jobs..strategy.matrix`](/fr/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idstrategymatrix) soit appliqué.\n\nQuand vous utilisez des expressions dans un conditionnel `if`, vous pouvez omettre la syntaxe de l’expression `${{ }}` parce que GitHub Actions évalue automatiquement le conditionnel `if` en tant qu’expression. Toutefois, cette exception ne s’applique pas partout.\n\nVous devez utiliser la syntaxe d’expression `${{ }}` ou l’échappement avec `''`, `\"\"` ou `()` lorsque l’expression commence par `!`, car `!` est une notation réservée au format YAML. Par exemple :\n\n```yaml\nif: ${{ ! startsWith(github.ref, 'refs/tags/') }}\n```\n\nPour plus d’informations, consultez « [Évaluer des expressions dans les workflows et les actions.](/fr/actions/learn-github-actions/expressions) ».\n\n### Exemple : Exécuter un travail uniquement pour un dépôt spécifique\n\nCet exemple utilise `if` pour contrôler le moment où le travail `production-deploy` peut s’exécuter. Il s’exécute uniquement si le dépôt se nomme `octo-repo-prod`, et s’il se trouve dans l’organisation `octo-org`. Sinon, le travail est marqué comme étant *ignoré*.\n\n```yaml copy\nname: example-workflow\non: [push]\njobs:\n production-deploy:\n if: github.repository == 'octo-org/octo-repo-prod'\n runs-on: ubuntu-latest\n steps:\n - uses: actions/checkout@v6\n - uses: actions/setup-node@v4\n with:\n node-version: '14'\n - run: npm install -g bats\n```\n\n## `jobs..runs-on`\n\nUtilisez `jobs..runs-on` pour définir le type de machine sur laquelle le travail doit être exécuté.\n\n* la machine de destination peut être un [exécuteur hébergé par GitHub](#choosing-github-hosted-runners), [exécuteur plus grand](#choosing-runners-in-a-group) ou un [exécuteur auto-hébergé](#choosing-self-hosted-runners).\n\n- Vous pouvez cibler les coureurs en fonction des étiquettes qui leur ont été attribuées, de leur appartenance à un groupe ou d'une combinaison de ces éléments.\n\n- Vous pouvez fournir `runs-on` sous la forme suivante :\n * Une seule chaîne\n * Une seule variable contenant une chaîne\n * Un tableau de chaînes, des variables contenant des chaînes ou une combinaison des deux\n * Une paire `key: value` utilisant les clés `group` ou `labels`\n\n- Si vous spécifiez un tableau de chaînes ou de variables, votre workflow s’exécute sur n’importe quel exécuteur correspondant à toutes les valeurs `runs-on` spécifiées. Par exemple, ici, le travail s’exécute uniquement sur un exécuteur auto-hébergé qui a les étiquettes `linux`, `x64` et `gpu` :\n\n ```yaml\n runs-on: [self-hosted, linux, x64, gpu]\n ```\n\n Pour plus d’informations, consultez [Choix d’exécuteurs auto-hébergés](#choosing-self-hosted-runners).\n\n- Vous pouvez mélanger des chaînes et des variables dans un tableau. Par exemple :\n\n ```yaml\n on:\n workflow_dispatch:\n inputs:\n chosen-os:\n required: true\n type: choice\n options:\n - Ubuntu\n - macOS\n\n jobs:\n test:\n runs-on: [self-hosted, \"${{ inputs.chosen-os }}\"]\n steps:\n - run: echo Hello world!\n ```\n\n- Si vous souhaitez exécuter votre workflow sur plusieurs machines, utilisez [`jobs..strategy`](/fr/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idstrategy).\n\n> \\[!NOTE]\n> Les guillemets ne sont pas obligatoires autour de chaînes simples comme `self-hosted`, mais ils sont requis pour des expressions comme `\"${{ inputs.chosen-os }}\"`.\n\n### ChoisirGitHub- des coureurs hébergés par\n\nSi vous utilisez un exécuteur hébergé par GitHub, chaque travail s’exécute sur une nouvelle instance d’une image d’exécuteur spécifiée par `runs-on`.\n\nLa valeur des exécutions, lorsque vous utilisez un exécuteur hébergé par GitHub, est une étiquette d’exécuteur ou le nom d’un groupe d’exécuteurs. Les étiquettes des exécuteurs standard hébergés par GitHub sont indiquées dans les tableaux suivants.\n\nPour plus d’informations, consultez « [Exécuteurs hébergés par GitHub](/fr/actions/using-github-hosted-runners/about-github-hosted-runners/about-github-hosted-runners) ».\n\n### Exécuteurs hébergés standard GitHubpour les référentiels publics\n\nPour les dépôts publics, les travaux utilisant les étiquettes de flux de travail indiquées dans le tableau ci-dessous s’exécutent avec les spécifications associées.\nÀ l’exception des coureurs à UC unique, tous les GitHub-hosted runners sont des nouvelles machines virtuelles hébergées par GitHub. Les exécuteurs Single-CPU sont hébergés dans un conteneur sur une machine virtuelle partagée, voir [Référence des exécuteurs hébergés par GitHub](/fr/actions/reference/runners/github-hosted-runners#single-cpu-runners). L’utilisation des exécuteurs hébergés standard GitHub est gratuite et illimitée sur les référentiels publics.\n\n\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n\n\n \n \n \n \n \n \n\n\n \n \n \n \n \n \n\n\n \n \n \n \n \n \n\n\n \n \n \n \n \n \n\n\n \n \n \n \n \n \n\n```\n\n \n\n
\n Machine virtuelle / conteneur\n Processeur (CPU)\n Mémoire (RAM)\n Stockage (SSD)\n Architecture\n Étiquette de workflow
Linux15 GB14 GB x64 \n ubuntu-slim\n
Linux416 Go14 Go x64 \n\n```\n ubuntu-latest, , ubuntu-24.04ubuntu-22.04
Windows416 Go14 Go x64 \n \n windows-latest, , windows-2025windows-2025-vs2026, ,windows-2022
Linux416 Go14 Go arm64 \n \n ubuntu-24.04-arm, ubuntu-22.04-arm
Windows416 Go14 Goarm64\n windows-11-arm\n
macOS414 Go14 Go Intel \n \n macos-15-intel, macos-26-intel
macOS3 (M1)7 Go14 Go arm64 \n \n macos-latest, , macos-14macos-15, ,macos-26
\n\n### Exécuteurs standard hébergés GitHubpour privés\n\nPour privés, les travaux utilisant les étiquettes de flux de travail indiquées dans le tableau ci-dessous s’exécutent sur des machines virtuelles avec les spécifications associées. Ces coureurs utilisent l’allocation de votre GitHub compte de minutes gratuites, puis sont facturés aux tarifs par minute. Consultez « [Tarification des runners Actions](/fr/billing/reference/actions-minute-multipliers) ».\n\n\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n\n\n \n \n \n \n \n \n\n\n \n \n \n \n \n \n\n\n \n \n \n \n \n \n\n\n \n \n \n \n \n \n\n\n \n \n \n \n \n \n\n```\n\n \n
\n Machine virtuelle\n Processeur (CPU)\n Mémoire (RAM)\n Stockage (SSD)\n Architecture\n Étiquette de workflow
Linux15 GB14 GB x64 \n ubuntu-slim\n
Linux28 Go14 Go x64 \n\n```\n ubuntu-latest, , ubuntu-24.04ubuntu-22.04
Windows28 Go14 Go x64 \n \n windows-latest, , windows-2025windows-2022
Linux28 Go14 Go arm64 \n \n ubuntu-24.04-arm, ubuntu-22.04-arm
Windows28 Go14 Go arm64 \n windows-11-arm\n
macOS414 Go14 Go Intel \n \n macos-15-intel, macos-26-intel
macOS3 (M1)7 Go14 Go arm64 \n \n macos-latest, , macos-14macos-15, ,macos-26
\n\nEn plus des exécuteurs standard hébergés par GitHub, GitHub offre aux clients sur des plans GitHub Team et GitHub Enterprise Cloud une gamme de machines virtuelles dotées de fonctionnalités avancées, comme plus de cœurs et d’espace disque, des machines alimentées par GPU et des machines alimentées par ARM. Pour plus d’informations, consultez « [Exécuteurs plus grands](/fr/actions/using-github-hosted-runners/about-larger-runners/about-larger-runners) ».\n\n> \\[!NOTE]\n> Les images d’exécuteur `-latest` sont les dernières images stables que fournit GitHub et peuvent ne pas correspondre à la version la plus récente du système d’exploitation disponible auprès du fournisseur de système d’exploitation.\n\n> \\[!WARNING]\n> Les images bêta et dépréciées sont fournies « en l’état », « avec toutes les imperfections » et « selon la disponibilité », et sont exclues du contrat de niveau de service et de la garantie. Les images bêta peuvent ne pas être couvertes par le service client.\n\n#### Exemple : Spécification d’un système d’exploitation\n\n```yaml\nruns-on: ubuntu-latest\n```\n\nPour plus d’informations, consultez « [Exécuteurs hébergés par GitHub](/fr/actions/using-github-hosted-runners/about-github-hosted-runners) ».\n\n### Choix des exécuteurs auto-hébergés\n\nSi vous souhaitez spécifier un exécuteur autohébergé pour votre travail, configurez `runs-on` dans votre fichier de workflow avec des étiquettes d’exécuteur autohébergé.\n\nLes runners auto-hébergés peuvent avoir le `self-hosted` label. Lors de la configuration d’un exécuteur auto-hébergé, nous inclurons l’étiquette `self-hosted` par défaut. Vous pouvez utiliser l’option `--no-default-labels` pour empêcher l’application du label auto-hébergé. Les étiquettes peuvent être utilisées pour créer des options de ciblage pour les exécuteurs, telles que le système d’exploitation ou l’architecture. Nous recommandons de fournir un tableau d’étiquettes qui commence par `self-hosted` (ceci doit être listé en premier) et inclut ensuite des étiquettes supplémentaires si nécessaire. Quand vous spécifiez un tableau d’étiquettes, les travaux sont mis en file d’attente sur des exécuteurs qui comportent toutes les étiquettes que vous indiquez.\n\n> \\[!NOTE] Actions Runner Controller ne prend pas en charge le `self-hosted` label.\n\n#### Exemple : Utilisation d’étiquettes pour la sélection des exécuteurs\n\n```yaml\nruns-on: [self-hosted, linux]\n```\n\nPour plus d’informations, consultez « [Exécuteurs auto-hébergés](/fr/actions/hosting-your-own-runners/managing-self-hosted-runners/about-self-hosted-runners) » et « [Utilisation d’exécuteurs auto-hébergés dans un workflow](/fr/actions/hosting-your-own-runners/managing-self-hosted-runners/using-self-hosted-runners-in-a-workflow) ».\n\n### Choix des exécuteurs dans un groupe\n\nVous pouvez utiliser `runs-on` pour cibler des groupes d’exécuteurs, afin que le travail s’exécute sur n’importe quel exécuteur membre de ce groupe. Pour un contrôle plus précis, vous pouvez également combiner des groupes d’exécuteurs avec des étiquettes.\n\nLes groupes d’exécuteurs peuvent uniquement avoir des [exécuteur plus grand](/fr/actions/using-github-hosted-runners/using-larger-runners/about-larger-runners) ou [des exécuteurs auto-hébergés](/fr/actions/how-tos/managing-self-hosted-runners) comme.\n\n#### Exemple : utilisation de groupes pour contrôler où les travaux sont exécutés\n\nDans cet exemple, des exécuteurs Ubuntu ont été ajoutés à un groupe appelé `ubuntu-runners`. La clé `runs-on` envoie le travail à n’importe quel exécuteur disponible dans le groupe `ubuntu-runners` :\n\n```yaml\nname: learn-github-actions\non: [push]\njobs:\n check-bats-version:\n runs-on: \n group: ubuntu-runners\n steps:\n - uses: actions/checkout@v6\n - uses: actions/setup-node@v4\n with:\n node-version: '14'\n - run: npm install -g bats\n - run: bats -v\n```\n\n#### Exemple : combinaison de groupes et d’étiquettes\n\nQuand vous combinez des groupes et des étiquettes, l’exécuteur doit satisfaire aux deux exigences pour pouvoir exécuter le travail.\n\nDans cet exemple, un groupe d’exécuteurs appelé `ubuntu-runners` est rempli avec des exécuteurs Ubuntu, qui ont également reçu l’étiquette `ubuntu-24.04-16core`. La clé `runs-on` combine `group` et `labels` afin que le travail soit routé vers n’importe quel exécuteur disponible au sein du groupe qui a également une étiquette correspondante :\n\n```yaml\nname: learn-github-actions\non: [push]\njobs:\n check-bats-version:\n runs-on:\n group: ubuntu-runners\n labels: ubuntu-24.04-16core\n steps:\n - uses: actions/checkout@v6\n - uses: actions/setup-node@v4\n with:\n node-version: '14'\n - run: npm install -g bats\n - run: bats -v\n```\n\n## `jobs..snapshot`\n\nVous pouvez utiliser `jobs..snapshot` pour générer une image personnalisée.\n\nAjoutez le mot clé d’instantané au travail, à l’aide de la syntaxe de chaîne ou de la syntaxe de mappage, comme indiqué dans [Génération d’une image personnalisée](/fr/actions/how-tos/manage-runners/larger-runners/use-custom-images#generating-a-custom-image).\n\nChaque travail qui inclut le mot-clé 'instantané' crée une image distincte. Pour générer une seule image ou version d’image, incluez toutes les étapes de flux de travail dans un seul travail. Chaque exécution réussie d’un travail qui inclut le mot-clé \"snapshot\" crée une nouvelle version de cette image.\n\nPour plus d’informations, consultez « [Utilisation d’images personnalisées](/fr/actions/how-tos/manage-runners/larger-runners/use-custom-images) ».\n\n## `jobs..environment`\n\nUtilisez `jobs..environment` pour définir l’environnement référencé par le travail.\n\nVous pouvez fournir l’environnement en tant qu’environnement `name` uniquement, ou en tant qu’objet d’environnement avec `name` et `url`. L’URL est mappée à `environment_url` dans l’API des déploiements. Pour plus d’informations sur l’API des déploiements, consultez [Points de terminaison d’API REST pour les référentiels](/fr/rest/repos#deployments).\n\n> \\[!NOTE]\n> Toutes les règles liées à la protection du déploiement doivent être respectées avant qu’un projet faisant référence à l’environnement ne soit envoyé à un exécuteur. Pour plus d’informations, consultez « [Gestion des environnements pour le déploiement](/fr/actions/deployment/targeting-different-environments/managing-environments-for-deployment) ».\n\n### Exemple : Utilisation d’un seul nom d’environnement\n\n```yaml\nenvironment: staging_environment\n```\n\n### Exemple : Utilisation du nom et de l’URL de l’environnement\n\n```yaml\nenvironment:\n name: production_environment\n url: https://github.com\n```\n\nLa valeur de `url` peut être une expression. Contextes d’expression autorisés : [`github`](/fr/actions/learn-github-actions/contexts#github-context), [`inputs`](/fr/actions/learn-github-actions/contexts#inputs-context), [`vars`](/fr/actions/learn-github-actions/contexts#vars-context), [`needs`](/fr/actions/learn-github-actions/contexts#needs-context), [`strategy`](/fr/actions/learn-github-actions/contexts#strategy-context), [`matrix`](/fr/actions/learn-github-actions/contexts#matrix-context), [`job`](/fr/actions/learn-github-actions/contexts#job-context), [`runner`](/fr/actions/learn-github-actions/contexts#runner-context), [`env`](/fr/actions/learn-github-actions/contexts#env-context) et [`steps`](/fr/actions/learn-github-actions/contexts#steps-context). Pour plus d’informations sur les expressions, consultez [Évaluer des expressions dans les workflows et les actions.](/fr/actions/learn-github-actions/expressions).\n\n### Exemple : Utilisation de la sortie en tant qu’URL\n\n```yaml\nenvironment:\n name: production_environment\n url: ${{ steps.step_id.outputs.url_output }}\n```\n\nLa valeur de `name` peut être une expression. Contextes d’expression autorisés : [`github`](/fr/actions/learn-github-actions/contexts#github-context), [`inputs`](/fr/actions/learn-github-actions/contexts#inputs-context), [`vars`](/fr/actions/learn-github-actions/contexts#vars-context), [`needs`](/fr/actions/learn-github-actions/contexts#needs-context), [`strategy`](/fr/actions/learn-github-actions/contexts#strategy-context) et [`matrix`](/fr/actions/learn-github-actions/contexts#matrix-context). Pour plus d’informations sur les expressions, consultez [Évaluer des expressions dans les workflows et les actions.](/fr/actions/learn-github-actions/expressions).\n\n### Exemple : Utilisation d’une expression comme nom d’environnement\n\n```yaml\nenvironment:\n name: ${{ github.ref_name }}\n```\n\n## `jobs..concurrency`\n\nVous pouvez utiliser `jobs..concurrency` pour vous assurer qu’un seul travail ou workflow utilisant le même groupe d’accès concurrentiel s’exécute à la fois. Un groupe d’accès concurrentiel peut être n’importe quelle chaîne ou expression. Contextes d’expression autorisés : [`github`](/fr/actions/learn-github-actions/contexts#github-context), [`inputs`](/fr/actions/learn-github-actions/contexts#inputs-context), [`vars`](/fr/actions/learn-github-actions/contexts#vars-context), [`needs`](/fr/actions/learn-github-actions/contexts#needs-context), [`strategy`](/fr/actions/learn-github-actions/contexts#strategy-context) et [`matrix`](/fr/actions/learn-github-actions/contexts#matrix-context). Pour plus d’informations sur les expressions, consultez [Évaluer des expressions dans les workflows et les actions.](/fr/actions/learn-github-actions/expressions).\n\nVous pouvez également spécifier `concurrency` au niveau du workflow. Pour plus d’informations, consultez [`concurrency`](/fr/actions/using-workflows/workflow-syntax-for-github-actions#concurrency).\n\nCela signifie qu’il peut y avoir au plus un travail en cours d’exécution ou un workflow dans un groupe de concurrence à tout moment. Quand un travail ou un workflow simultané est mis en file d’attente, si un autre travail ou workflow utilisant le même groupe d’accès concurrentiel dans le dépôt est en cours d’exécution, le travail ou le workflow en file d’attente a la valeur `pending`. Par défaut, tout travail ou flux de travail existant `pending` dans le même groupe de concurrence sera annulé et le nouveau travail ou flux de travail mis en file d'attente prendra sa place.\n\nPour annuler également un travail ou un workflow en cours d’exécution dans le même groupe d’accès concurrentiel, spécifiez `cancel-in-progress: true`. Pour annuler de façon conditionnelle les travaux ou les flux de travail en cours d’exécution dans le même groupe d’accès concurrentiel, vous pouvez spécifier `cancel-in-progress` en tant qu’expression avec l’un des contextes d’expression autorisés.\n\nPour autoriser plusieurs `pending` exécutions de travail ou de flux de travail à attendre dans le même groupe d’accès concurrentiel, utilisez la propriété facultative `queue` . La `queue` propriété accepte les valeurs suivantes :\n\n* `single` (valeur par défaut) : Au plus un travail ou une exécution de flux de travail peut se trouver `pending` dans le groupe d’accès concurrentiel. Lorsqu’une nouvelle exécution de travail ou de flux de travail est mise en file d’attente, toute exécution de travail ou de flux de travail existante `pending` dans le même groupe est annulée et remplacée.\n* `max`: jusqu’à 100 travaux ou exécutions de flux de travail peuvent être `pending` dans le groupe de concurrence. Lorsque la file d’attente est pleine, les travaux supplémentaires ou les exécutions de flux de travail sont annulées.\n\nLa combinaison de `queue: max` et de `cancel-in-progress: true` n'est pas autorisée et entraînera une erreur de validation du flux de travail.\n\n> \\[!NOTE]\n>\n> * Le nom du groupe de concurrence n'est pas sensible à la casse. Par exemple, `prod` et `Prod` seront traités comme le même groupe de concurrence.\n> * Les tâches ou exécutions de flux de travail dans le même groupe de concurrence sont traitées selon l'ordre PEPS (premier entré, premier sorti) en fonction du moment où chacune a commencé à attendre dans le groupe de concurrence, plutôt que du moment où chaque flux de travail a été distribué. Étant donné que l’heure de début réelle d’un travail ou d’une exécution peut varier, l’ordre n’est pas garanti.\n\n### Exemple : utilisation de la concurrence et du comportement par défaut\n\nLe comportement par défaut consiste à autoriser l’exécution simultanée de GitHub Actions plusieurs travaux ou flux de travail. Le mot clé `concurrency` vous permet de contrôler la concurrence des exécutions de flux de travail.\n\nPar exemple, vous pouvez utiliser le mot clé `concurrency` immédiatement après le lieu de définition des conditions de déclenchement afin de limiter la concurrence des exécutions de l'ensemble du flux de travail pour une branche spécifique :\n\n```yaml\non:\n push:\n branches:\n - main\n\nconcurrency:\n group: ${{ github.workflow }}-${{ github.ref }}\n cancel-in-progress: true\n```\n\nVous pouvez également limiter la concurrence des projets au sein d'un flux de travail en utilisant le mot-clé `concurrency` au niveau du projet :\n\n```yaml\non:\n push:\n branches:\n - main\n\njobs:\n job-1:\n runs-on: ubuntu-latest\n concurrency:\n group: example-group\n cancel-in-progress: true\n```\n\n### Exemple : groupes de concurrence\n\nLes groupes de concurrence permettent de gérer et de limiter l'exécution des flux de travail ou des projets qui partagent la même clé de concurrence.\n\nLa clé `concurrency` est utilisée pour regrouper des flux de travail ou des projets ensemble dans un groupe de concurrence. Lorsque vous définissez une `concurrency` clé, GitHub Actions garantit qu’un seul flux de travail ou travail avec cette clé s’exécute à tout moment. Si une nouvelle exécution ou un travail commence avec la même `concurrency` clé, GitHub Actions annulera toute exécution ou travail déjà en cours avec cette clé. La clé `concurrency` peut être une chaîne codée en dur, ou il peut s'agir d'une expression dynamique qui inclut des variables de contexte.\n\nIl est possible de définir des conditions de concurrence dans votre flux de travail afin que le flux de travail ou le projet fasse partie d'un groupe de concurrence.\n\nEn d'autres termes, lorsqu'un flux de travail ou un projet est lancé, GitHub annule tous les flux de travail ou projets déjà en cours dans le même groupe de concurrence. Cette fonction est utile dans les scénarios où vous souhaitez empêcher les exécutions parallèles pour un certain ensemble de flux de travail ou de projets, comme ceux utilisés pour les déploiements dans un environnement intermédiaire, afin d'éviter les actions susceptibles de provoquer des conflits ou de consommer plus de ressources qu'il n'est nécessaire.\n\nDans cet exemple, `job-1` fait partie d'un groupe de concurrence nommé `staging_environment`. En d'autres termes, si une nouvelle exécution de `job-1` est déclenchée, toutes les exécutions du même projet dans le groupe de concurrence `staging_environment` qui sont déjà en cours seront annulées.\n\n```yaml\njobs:\n job-1:\n runs-on: ubuntu-latest\n concurrency:\n group: staging_environment\n cancel-in-progress: true\n```\n\nPar ailleurs, l'utilisation d'une expression dynamique comme `concurrency: ci-${{ github.ref }}` dans votre flux de travail signifie que le flux de travail ou le projet fera partie d'un groupe de concurrence dont le nom `ci-` est suivi de la référence de la branche ou de la balise qui a déclenché le flux de travail. Dans cet exemple, si un nouveau commit est poussé vers la branche principale alors qu'une exécution précédente est toujours en cours, cette dernière sera annulée et la nouvelle commencera.\n\n```yaml\non:\n push:\n branches:\n - main\n\nconcurrency:\n group: ci-${{ github.ref }}\n cancel-in-progress: true\n```\n\n### Exemple : Mise en file d’attente de plusieurs exécutions en attente\n\nPar défaut, une seule exécution de travail ou de flux de travail peut se trouver `pending` dans un groupe d’accès concurrentiel à la fois. Pour autoriser plusieurs exécutions à être ajoutées à la file d'attente plutôt que d'être annulées, définissez `queue: max`. Avec `queue: max`, jusqu’à 100 travaux ou exécutions de flux de travail peuvent attendre dans le groupe d’accès concurrentiel ; une fois la file d’attente remplie, toutes les exécutions supplémentaires sont annulées.\n\nPar exemple, les déploiements de flux de travail suivants sont mis en file d’attente dans l’environnement `production` , en les traitant un à la fois en fonction du moment où chaque exécution a commencé à attendre le groupe d’accès concurrentiel :\n\n```yaml\non:\n push:\n branches:\n - main\n\nconcurrency:\n group: production-deploy\n queue: max\n```\n\nNotez que `queue: max` ne peut pas être combiné avec `cancel-in-progress: true`, car les deux options décrivent des comportements contradictoires pour la gestion des exécutions en cours.\n\n### Exemple : Utilisation de la concurrence pour annuler un travail ou une exécution en cours\n\nPour utiliser la concurrence pour annuler un travail ou une exécution en cours dans GitHub Actions, vous pouvez utiliser la clé `concurrency` avec l’option `cancel-in-progress` définie sur `true`.\n\n```yaml\nconcurrency:\n group: ${{ github.ref }}\n cancel-in-progress: true\n```\n\nRemarquez que dans cet exemple, sans définir de groupe de concurrence particulier, GitHub Actions annulera *toute* exécution en cours de la tâche ou du flux de travail.\n\n### Exemple : Utilisation d’une valeur de secours\n\nSi vous créez le nom de groupe avec une propriété définie uniquement pour des événements spécifiques, vous pouvez utiliser une valeur de secours. Par exemple, `github.head_ref` est défini uniquement pour les événements `pull_request`. Si votre workflow répond à d’autres événements en plus des événements `pull_request`, vous devez fournir une valeur de secours pour éviter une erreur de syntaxe. Le groupe d’accès concurrentiel suivant annule les travaux ou les exécutions en cours pour les événements `pull_request` uniquement. Si `github.head_ref` n’est pas défini, le groupe d’accès concurrent utilise l’ID d’exécution, qui offre la garantie d’être à la fois unique et défini pour l’exécution.\n\n```yaml\nconcurrency:\n group: ${{ github.head_ref || github.run_id }}\n cancel-in-progress: true\n```\n\n### Exemple : Annuler uniquement les travaux ou les exécutions en cours pour le workflow actuel\n\nSi vous avez plusieurs workflows dans le même dépôt, les noms de groupes de concurrence doivent être uniques entre les workflows pour éviter d'annuler des tâches ou des exécutions en cours provenant d'autres workflows. Sinon, tout travail en cours ou en attente est annulé, quel que soit le workflow.\n\nPour annuler uniquement les exécutions en cours du même workflow, vous pouvez utiliser la propriété `github.workflow` afin de créer le groupe d’accès concurrentiel :\n\n```yaml\nconcurrency:\n group: ${{ github.workflow }}-${{ github.ref }}\n cancel-in-progress: true\n```\n\n### Exemple : Annuler uniquement les travaux en cours sur des branches spécifiques\n\nSi vous souhaitez annuler des travaux en cours sur certaines branches, mais pas sur d’autres, vous pouvez utiliser des expressions conditionnelles avec `cancel-in-progress`. Par exemple, vous pouvez procéder ainsi si vous souhaitez annuler les processus en cours sur les branches de développement, mais pas sur les branches de release.\n\nPour n’annuler que les exécutions en cours du même workflow lorsqu’il n’est pas exécuté sur une branche de publication, vous pouvez définir `cancel-in-progress` comme une expression similaire à la suivante :\n\n```yaml\nconcurrency:\n group: ${{ github.workflow }}-${{ github.ref }}\n cancel-in-progress: ${{ !contains(github.ref, 'release/')}}\n```\n\nDans cet exemple, plusieurs envois push vers une branche `release/1.2.3` n’annulent pas les exécutions en cours. Les envois (push) vers une autre branche, par exemple `main`, annulent les exécutions en cours.\n\n## `jobs..outputs`\n\nVous pouvez utiliser `jobs..outputs` pour créer une `map` de sorties pour un travail. Les sorties de travail sont disponibles pour tous les travaux en aval qui dépendent de ce travail. Pour plus d’informations sur la définition des dépendances de travail, consultez [`jobs..needs`](/fr/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idneeds).\n\nLa taille maximale des sorties est de 1 Mo par projet. La taille totale maximale de toutes les sorties d’une exécution de workflow est de 50 Mo. La taille est approximative et basée sur l’encodage UTF-16.\n\nLes sorties de travail contenant des expressions sont évaluées sur l’exécuteur à la fin de chaque travail. Les sorties contenant des secrets sont rédigées sur l’exécuteur et ne sont pas envoyées à GitHub Actions.\n\nSi une production est ignorée, car elle peut contenir un secret, le message d’avertissement suivant s’affiche : « Ignorer la production `{output.Key}`, car elle peut contenir un secret ». Pour plus d’informations sur la gestion des secrets, consultez [Exemple : masquage et transfert d’un secret entre des projets ou des flux de travail](/fr/actions/writing-workflows/choosing-what-your-workflow-does/workflow-commands-for-github-actions#example-masking-and-passing-a-secret-between-jobs-or-workflows).\n\nPour utiliser les sorties de travail dans un travail dépendant, vous pouvez utiliser le contexte `needs`. Pour plus d’informations, consultez « [Référence des contextes](/fr/actions/learn-github-actions/contexts#needs-context) ».\n\n### Exemple : Définition de sorties pour un travail\n\n```yaml\njobs:\n job1:\n runs-on: ubuntu-latest\n # Map a step output to a job output\n outputs:\n output1: ${{ steps.step1.outputs.test }}\n output2: ${{ steps.step2.outputs.test }}\n steps:\n - id: step1\n run: echo \"test=hello\" >> \"$GITHUB_OUTPUT\"\n - id: step2\n run: echo \"test=world\" >> \"$GITHUB_OUTPUT\"\n job2:\n runs-on: ubuntu-latest\n needs: job1\n steps:\n - env:\n OUTPUT1: ${{needs.job1.outputs.output1}}\n OUTPUT2: ${{needs.job1.outputs.output2}}\n run: echo \"$OUTPUT1 $OUTPUT2\"\n```\n\n### Utilisation des sorties d'un travail dans un travail matriciel\n\nLes matrices peuvent être utilisées pour générer plusieurs sorties de noms différents. Lors de l'utilisation d'une matrice, les résultats des travaux seront combinés à partir de tous les travaux à l'intérieur de la matrice.\n\n```yaml\njobs:\n job1:\n runs-on: ubuntu-latest\n outputs:\n output_1: ${{ steps.gen_output.outputs.output_1 }}\n output_2: ${{ steps.gen_output.outputs.output_2 }}\n output_3: ${{ steps.gen_output.outputs.output_3 }}\n strategy:\n matrix:\n version: [1, 2, 3]\n steps:\n - name: Generate output\n id: gen_output\n run: |\n version=\"${{ matrix.version }}\"\n echo \"output_${version}=${version}\" >> \"$GITHUB_OUTPUT\"\n job2:\n runs-on: ubuntu-latest\n needs: [job1]\n steps:\n # Will show\n # {\n # \"output_1\": \"1\",\n # \"output_2\": \"2\",\n # \"output_3\": \"3\"\n # }\n - run: echo '${{ toJSON(needs.job1.outputs) }}'\n```\n\n> \\[!WARNING]\n> Les actions ne garantissent pas l'ordre d'exécution des travaux de la matrice. Veillez à ce que le nom de la sortie soit unique, sinon le dernier travail matriciel exécuté remplacera la valeur de la sortie.\n\n## `jobs..env`\n\nEnsemble (`map`) de variables qui sont disponibles pour toutes les étapes de la tâche. Vous pouvez définir des variables pour l’ensemble du workflow ou pour une étape individuelle. Pour plus d’informations, consultez [`env`](#env) et [`jobs..steps[*].env`](#jobsjob_idstepsenv).\n\nQuand plusieurs variables d’environnement sont définies avec le même nom, GitHub utilise la variable la plus spécifique. Par exemple, une variable d’environnement définie dans une étape remplace les variables d’environnement du travail et du workflow portant le même nom, pendant l’exécution de l’étape. Une variable d’environnement définie pour un travail remplace une variable de workflow de même nom, pendant l’exécution du travail.\n\n### Exemple de `jobs..env`\n\n```yaml\njobs:\n job1:\n env:\n FIRST_NAME: Mona\n```\n\n## `jobs..defaults`\n\nUtilisez `jobs..defaults` pour créer un `map` des paramètres par défaut applicable à toutes les étapes du travail. Vous pouvez également définir des paramètres par défaut pour l’ensemble du workflow. Pour plus d’informations, consultez [`defaults`](/fr/actions/using-workflows/workflow-syntax-for-github-actions#defaults).\n\nQuand plusieurs paramètres par défaut sont définis avec le même nom, GitHub utilise le paramètre par défaut le plus spécifique. Par exemple, un paramètre par défaut défini dans un travail remplace un paramètre par défaut portant le même nom défini dans un workflow.\n\n## `jobs..defaults.run`\n\nUtilisez `jobs..defaults.run` pour fournir le `shell` par défaut, et `working-directory` pour toutes les étapes `run` du travail.\n\nVous pouvez fournir des options `shell` et `working-directory` par défaut toutes les étapes [`run`](/fr/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idstepsrun) d’un travail. Vous pouvez également définir des paramètres par défaut de `run` pour l’ensemble du workflow. Pour plus d’informations, consultez [`defaults.run`](/fr/actions/using-workflows/workflow-syntax-for-github-actions#defaultsrun).\n\nCes éléments peuvent être remplacés aux niveaux `jobs..defaults.run` et `jobs..steps[*].run`.\n\nQuand plusieurs paramètres par défaut sont définis avec le même nom, GitHub utilise le paramètre par défaut le plus spécifique. Par exemple, un paramètre par défaut défini dans un travail remplace un paramètre par défaut portant le même nom défini dans un workflow.\n\n## `jobs..defaults.run.shell`\n\nUtilise `shell` pour définir le `shell` d'une étape. Ce mot clé peut référencer plusieurs contextes. Pour plus d’informations, consultez [Contextes](/fr/actions/learn-github-actions/contexts#context-availability).\n\n| Plateforme prise en charge | Paramètre `shell` | Description | Commande exécutée en interne |\n| -------------------------- | ----------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------- |\n| Linux / macOS | unspecified | Interpréteur de commandes par défaut sur les plateformes non Windows. Notez que cette opération exécute une commande différente par rapport à quand `bash` est spécifié explicitement. Si `bash` n’est pas trouvé dans le chemin, il est considéré comme `sh`. | `bash -e {0}` |\n| Tous | `bash` | Interpréteur de commandes par défaut sur les plateformes non Windows avec `sh` comme valeur de secours. Lors de la spécification d’un interpréteur de commandes Bash sur Windows, l’interpréteur de commandes Bash inclus avec Git pour Windows est utilisé. | `bash --noprofile --norc -eo pipefail {0}` |\n| Tous | `pwsh` | PowerShell Core. GitHub ajoute l’extension `.ps1` au nom de votre script. | `pwsh -command \". '{0}'\"` |\n| Tous | `python` | Exécute la commande Python. | `python {0}` |\n| Linux / macOS | `sh` | Comportement de secours pour les plateformes non Windows si aucun interpréteur de commandes n’est fourni et que `bash` ne se trouve pas dans le chemin. | `sh -e {0}` |\n| Windows | `cmd` | GitHub ajoute l’extension `.cmd` au nom de votre script et se substitue à `{0}`. | `%ComSpec% /D /E:ON /V:OFF /S /C \"CALL \"{0}\"\"`. |\n| Windows | `pwsh` | Il s’agit de l’interpréteur de commandes par défaut utilisé sur Windows. PowerShell Core. GitHub ajoute l’extension `.ps1` au nom de votre script. Si *PowerShell Core* n’est pas installé sur votre exécuteur Windows auto-hébergé, *PowerShell Desktop* est utilisé à la place. | `pwsh -command \". '{0}'\"`. |\n| Windows | `powershell` | PowerShell Desktop. GitHub ajoute l’extension `.ps1` au nom de votre script. | `powershell -command \". '{0}'\"`. |\n\nQuand plusieurs paramètres par défaut sont définis avec le même nom, GitHub utilise le paramètre par défaut le plus spécifique. Par exemple, un paramètre par défaut défini dans un travail remplace un paramètre par défaut portant le même nom défini dans un workflow.\n\n## `jobs..defaults.run.working-directory`\n\nUtilise `working-directory` pour définir le répertoire de travail pour le `shell` d'une étape. Ce mot clé peut référencer plusieurs contextes. Pour plus d’informations, consultez [Contextes](/fr/actions/learn-github-actions/contexts#context-availability).\n\n> \\[!TIP]\n> Assurez-vous que le `working-directory` que vous affectez existe sur l'exécuteur avant toute exécution du shell dans ce dernier.\n> Quand plusieurs paramètres par défaut sont définis avec le même nom, GitHub utilise le paramètre par défaut le plus spécifique. Par exemple, un paramètre par défaut défini dans un travail remplace un paramètre par défaut portant le même nom défini dans un workflow.\n\n### Exemple : Définition d’options d’étape `run` par défaut pour un travail\n\n```yaml\njobs:\n job1:\n runs-on: ubuntu-latest\n defaults:\n run:\n shell: bash\n working-directory: ./scripts\n```\n\n## `jobs..steps`\n\nUn travail contient une séquence de tâches appelées `steps`. Les étapes peuvent exécuter des commandes, exécuter des tâches de configuration ou exécuter une action dans votre dépôt ou dans un dépôt public, ou une action publiée dans un registre Docker. Toutes les étapes n’exécutent pas d’actions, mais toutes les actions s’exécutent en tant qu’étape. Chaque étape s’exécute dans son propre processus dans l’environnement de l’exécuteur et a accès à l’espace de travail et au système de fichiers. Étant donné que les étapes s’exécutent dans leur propre processus, les modifications apportées aux variables d’environnement ne sont pas conservées d’une étapes à l’autre.\nGitHub fournit des étapes intégrées pour configurer et exécuter une tâche.\n\n```\n GitHub affiche uniquement les 1 000 premières vérifications. Toutefois, vous pouvez exécuter un nombre illimité d’étapes tant que vous êtes dans les limites d’utilisation du flux de travail. Pour plus d’informations, consultez [AUTOTITLE](/actions/learn-github-actions/usage-limits-billing-and-administration) for GitHub- pour les coureurs hébergés par et [AUTOTITLE](/actions/hosting-your-own-runners/managing-self-hosted-runners/usage-limits-for-self-hosted-runners) pour les limites d’utilisation des coureurs auto-hébergés.\n```\n\n### Exemple de `jobs..steps`\n\n```yaml\nname: Greeting from Mona\n\non: push\n\njobs:\n my-job:\n name: My Job\n runs-on: ubuntu-latest\n steps:\n - name: Print a greeting\n env:\n MY_VAR: Hi there! My name is\n FIRST_NAME: Mona\n MIDDLE_NAME: The\n LAST_NAME: Octocat\n run: |\n echo $MY_VAR $FIRST_NAME $MIDDLE_NAME $LAST_NAME.\n```\n\n## `jobs..steps[*].id`\n\nIdentificateur unique pour l’étape. Vous pouvez utiliser l’`id` pour référencer l’étape dans des contextes. Pour plus d’informations, consultez « [Référence des contextes](/fr/actions/learn-github-actions/contexts) ».\n\n## `jobs..steps[*].if`\n\nVous pouvez utiliser la condition `if` pour empêcher l’exécution d’une étape si une condition n’est pas remplie. Vous pouvez utiliser n’importe quel contexte et n’importe quelle expression pris en charge pour créer un conditionnel. Pour plus d’informations sur les contextes pris en charge dans cette clé, consultez [Référence des contextes](/fr/actions/learn-github-actions/contexts#context-availability).\n\n````\n Quand vous utilisez des expressions dans un conditionnel `if`, vous pouvez omettre la syntaxe de l’expression `${{ }}` parce que GitHub Actions évalue automatiquement le conditionnel `if` en tant qu’expression. Toutefois, cette exception ne s’applique pas partout.\n \n Vous devez utiliser la syntaxe d’expression `${{ }}` ou l’échappement avec `''`, `\"\"` ou `()` lorsque l’expression commence par `!`, car `!` est une notation réservée au format YAML. Par exemple :\n \n \n \n ```yaml\n if: ${{ ! startsWith(github.ref, 'refs/tags/') }}\n ```\n \n Pour plus d’informations, consultez [AUTOTITLE](/actions/learn-github-actions/expressions).\n````\n\n### Exemple : Utilisation des contextes\n\nCette étape s’exécute uniquement lorsque le type d’événement est `pull_request` et que l’action d’événement est `unassigned`.\n\n```yaml\nsteps:\n - name: My first step\n if: ${{ github.event_name == 'pull_request' && github.event.action == 'unassigned' }}\n run: echo This event is a pull request that had an assignee removed.\n```\n\n### Exemple : Utilisation des fonctions de vérification d’état\n\nL’étape `my backup step` s’exécute uniquement lorsque l’étape précédente d’un travail échoue. Pour plus d’informations, consultez « [Évaluer des expressions dans les workflows et les actions.](/fr/actions/learn-github-actions/expressions#status-check-functions) ».\n\n```yaml\nsteps:\n - name: My first step\n uses: octo-org/action-name@main\n - name: My backup step\n if: ${{ failure() }}\n uses: actions/heroku@1.0.0\n```\n\n### Exemple : Utilisation de secrets\n\nLes secrets ne peuvent pas être directement référencés dans les conditions `if:`. Au lieu de cela, envisagez de définir des secrets en tant que variables d’environnement au niveau du travail, puis de référencer les variables d’environnement pour exécuter des étapes de manière conditionnelle dans le travail.\n\nSi aucun secret n’a été défini, la valeur de retour d’une expression référençant le secret (par `${{ secrets.SuperSecret }}` exemple) est une chaîne vide.\n\n```yaml\nname: Run a step if a secret has been set\non: push\njobs:\n my-jobname:\n runs-on: ubuntu-latest\n env:\n super_secret: ${{ secrets.SuperSecret }}\n steps:\n - if: ${{ env.super_secret != '' }}\n run: echo 'This step will only run if the secret has a value set.'\n - if: ${{ env.super_secret == '' }}\n run: echo 'This step will only run if the secret does not have a value set.'\n```\n\nPour plus d’informations, consultez « [Référence des contextes](/fr/actions/learn-github-actions/contexts#context-availability) » et « [Utilisation de secrets dans GitHub Actions](/fr/actions/security-guides/using-secrets-in-github-actions) ».\n\n## `jobs..steps[*].name`\n\nNom de votre étape à afficher sur GitHub.\n\n## `jobs..steps[*].uses`\n\nSélectionne une action à exécuter dans le cadre d’une étape de votre travail. Une action est une unité de code réutilisable. Vous pouvez utiliser une action définie dans le même dépôt que le workflow, dans un dépôt public ou dans une [image conteneur Docker publiée](https://hub.docker.com/).\n\nNous vous recommandons vivement d’inclure la version de l’action que vous utilisez en spécifiant une étiquette Git ref, SHA ou Docker. Si vous ne spécifiez pas de version, cela peut arrêter vos workflows ou provoquer un comportement inattendu lorsque le propriétaire de l’action publie une mise à jour.\n\n* L’utilisation du SHA de commit d’une version d’action publiée est la solution la plus sûre en termes de stabilité et de sécurité.\n* Si l’action publie des balises de version majeure, vous devez vous attendre à recevoir des correctifs critiques et des correctifs de sécurité, tout en conservant la compatibilité. Notez que ce comportement est à la discrétion de l’auteur de l’action.\n* L’utilisation de la branche par défaut d’une action peut être pratique. Toutefois, si un utilisateur publie une nouvelle version majeure avec un changement entraînant une rupture, votre flux de travail pourrait être interrompu.\n\nCertaines actions nécessitent des entrées que vous devez définir à l’aide du mot clé [`with`](#jobsjob_idstepswith). Examinez le fichier README de l’action pour déterminer les entrées nécessaires.\n\nLes actions sont des fichiers JavaScript ou des conteneurs Docker. Si l’action que vous utilisez est un conteneur Docker, vous devez exécuter le travail dans un environnement Linux. Pour plus d’informations, consultez la page [`runs-on`](#jobsjob_idruns-on).\n\n### Exemple : Utilisation d’actions versionnées\n\n```yaml\nsteps:\n # Reference a specific commit\n - uses: actions/checkout@8f4b7f84864484a7bf31766abe9204da3cbe65b3\n # Reference the major version of a release\n - uses: actions/checkout@v6\n # Reference a specific version\n - uses: actions/checkout@v6.2.0\n # Reference a branch\n - uses: actions/checkout@main\n```\n\n### Exemple : Utilisation d’une action publique\n\n`{owner}/{repo}@{ref}`\n\nVous pouvez spécifier une branche, une référence ou une sha dans un référentiel public GitHub .\n\n```yaml\njobs:\n my_first_job:\n steps:\n - name: My first step\n # Uses the default branch of a public repository\n uses: actions/heroku@main\n - name: My second step\n # Uses a specific version tag of a public repository\n uses: actions/aws@v2.0.1\n```\n\n### Exemple : Utilisation d’une action publique dans un sous-répertoire\n\n`{owner}/{repo}/{path}@{ref}`\n\nUn sous-répertoire dans un dépôt publicGitHubsur une branche, un ref ou un SHA spécifique.\n\n```yaml\njobs:\n my_first_job:\n steps:\n - name: My first step\n uses: actions/aws/ec2@main\n```\n\n### Exemple : Utilisation d’une action dans le même dépôt que le workflow\n\n`./path/to/dir`\n\nChemin du répertoire qui contient l’action dans le dépôt de votre workflow. Vous devez valider votre dépôt avant d’utiliser l’action.\n\nExemple de structure de fichier de dépôt :\n\n```shell\n|-- hello-world (repository)\n| |__ .github\n| └── workflows\n| └── my-first-workflow.yml\n| └── actions\n| |__ hello-world-action\n| └── action.yml\n```\n\nLe chemin d’accès relatif (`./`) par rapport au répertoire de travail par défaut (`github.workspace`, `$GITHUB_WORKSPACE`). Si l’action extrait le référentiel d’un emplacement différent du flux de travail, le chemin d’accès relatif utilisé pour les actions locales doit être mis à jour.\n\nExemple de fichier de workflow :\n\n```yaml\njobs:\n my_first_job:\n runs-on: ubuntu-latest\n steps:\n # This step checks out a copy of your repository.\n - name: My first step - check out repository\n uses: actions/checkout@v6\n # This step references the directory that contains the action.\n - name: Use local hello-world-action\n uses: ./.github/actions/hello-world-action\n```\n\n### Exemple : Utilisation d’une action de Docker Hub\n\n`docker://{image}:{tag}`\n\nImage Docker publiée sur [Docker Hub](https://hub.docker.com/).\n\n```yaml\njobs:\n my_first_job:\n steps:\n - name: My first step\n uses: docker://alpine:3.8\n```\n\n### Exemple : utilisation de l’objet GitHub PackagesContainer registry\n\n`docker://{host}/{image}:{tag}`\n\nImage Docker publique dans le GitHub PackagesContainer registry.\n\n```yaml\njobs:\n my_first_job:\n steps:\n - name: My first step\n uses: docker://ghcr.io/OWNER/IMAGE_NAME\n```\n\n### Exemple : Utilisation d’une action de registre public Docker\n\n`docker://{host}/{image}:{tag}`\n\nImage Docker dans un registre public. Cet exemple utilise Google Container Registry à l’adresse `gcr.io`.\n\n```yaml\njobs:\n my_first_job:\n steps:\n - name: My first step\n uses: docker://gcr.io/cloud-builders/gradle\n```\n\n### Exemple : Utilisation d’une action à l’intérieur d’un autre dépôt privé que le workflow\n\nVotre workflow doit valider le dépôt privé et référencer l’action localement. Générez un personal access token et ajoutez le jeton en tant qu'un secret. Pour plus d’informations, consultez « [Gestion de vos jetons d’accès personnels](/fr/authentication/keeping-your-account-and-data-secure/creating-a-personal-access-token) » et « [Utilisation de secrets dans GitHub Actions](/fr/actions/security-guides/using-secrets-in-github-actions) ».\n\nRemplacez `PERSONAL_ACCESS_TOKEN` dans l’exemple par le nom de votre secret.\n\n```yaml\njobs:\n my_first_job:\n steps:\n - name: Check out repository\n uses: actions/checkout@v6\n with:\n repository: octocat/my-private-repo\n ref: v1.0\n token: ${{ secrets.PERSONAL_ACCESS_TOKEN }}\n path: ./.github/actions/my-private-repo\n - name: Run my action\n uses: ./.github/actions/my-private-repo/my-action\n```\n\nVous pouvez également utiliser un GitHub App plutôt qu’un personal access token pour vous assurer que votre flux de travaux continue de fonctionner même si le personal access token détenteur quitte. Pour plus d’informations, consultez « [Effectuer des requêtes d’API authentifiées avec une application GitHub dans un flux de travail GitHub Actions](/fr/apps/creating-github-apps/guides/making-authenticated-api-requests-with-a-github-app-in-a-github-actions-workflow) ».\n\n## `jobs..steps[*].run`\n\nExécute des programmes en ligne de commande qui ne dépassent pas 21 000 caractères à l’aide de l’interpréteur de commandes du système d’exploitation. Si vous ne fournissez pas d’élément `name`, le nom de l’étape est défini par défaut sur le texte spécifié dans la commande `run`.\n\nPar défaut, les commandes s’exécutent à l’aide d’interpréteurs de commandes sans connexion. Vous pouvez choisir un autre interpréteur de commandes et personnaliser l’interpréteur de commandes utilisé pour exécuter des commandes. Pour plus d’informations, consultez [`jobs..steps[*].shell`](#jobsjob_idstepsshell).\n\nChaque mot clé `run` représente un nouveau processus et un nouvel interpréteur de commandes dans l’environnement de l’exécuteur. Lorsque vous fournissez des commandes qui s’étendent sur plusieurs lignes, chaque ligne s’exécute dans le même interpréteur de commandes. Par exemple :\n\n* Commande sur une seule ligne :\n\n ```yaml\n - name: Install Dependencies\n run: npm install\n ```\n\n* Commande sur plusieurs lignes :\n\n ```yaml\n - name: Clean install dependencies and build\n run: |\n npm ci\n npm run build\n ```\n\n## `jobs..steps[*].working-directory`\n\nÀ l’aide du mot clé `working-directory`, vous pouvez spécifier le répertoire de travail d’où exécuter la commande.\n\n```yaml\n- name: Clean temp directory\n run: rm -rf *\n working-directory: ./temp\n```\n\nVous pouvez également spécifier un répertoire de travail par défaut pour toutes les étapes `run` d'un projet ou pour toutes les étapes `run` de l'ensemble du flux de travail. Pour plus d’informations, consultez [`defaults.run.working-directory`](/fr/actions/using-workflows/workflow-syntax-for-github-actions#defaultsrunworking-directory) et [`jobs..defaults.run.working-directory`](/fr/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_iddefaultsrunworking-directory).\n\nVous pouvez également utiliser une étape `run` pour exécuter un script. Pour plus d’informations, consultez « [Ajout de scripts à votre workflow](/fr/actions/writing-workflows/choosing-what-your-workflow-does/adding-scripts-to-your-workflow) ».\n\n## `jobs..steps[*].shell`\n\nVous pouvez remplacer les paramètres d’interpréteur de commandes par défaut dans le système d’exploitation de l’exécuteur ainsi que les paramètres par défaut du travail à l’aide du mot clé `shell`. Vous pouvez utiliser des mots clés `shell` intégrés ou définir un ensemble personnalisé d’options d’interpréteur de commandes. La commande d’interpréteur de commandes exécutée en interne exécute un fichier temporaire qui contient les commandes spécifiées dans le mot clé `run`.\n\n| Plateforme prise en charge | Paramètre `shell` | Description | Commande exécutée en interne |\n| -------------------------- | ----------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------- |\n| Linux / macOS | unspecified | Interpréteur de commandes par défaut sur les plateformes non Windows. Notez que cette opération exécute une commande différente par rapport à quand `bash` est spécifié explicitement. Si `bash` n’est pas trouvé dans le chemin, il est considéré comme `sh`. | `bash -e {0}` |\n| Tous | `bash` | Interpréteur de commandes par défaut sur les plateformes non Windows avec `sh` comme valeur de secours. Lors de la spécification d’un interpréteur de commandes Bash sur Windows, l’interpréteur de commandes Bash inclus avec Git pour Windows est utilisé. | `bash --noprofile --norc -eo pipefail {0}` |\n| Tous | `pwsh` | PowerShell Core. GitHub ajoute l’extension `.ps1` au nom de votre script. | `pwsh -command \". '{0}'\"` |\n| Tous | `python` | Exécute la commande Python. | `python {0}` |\n| Linux / macOS | `sh` | Comportement de secours pour les plateformes non Windows si aucun interpréteur de commandes n’est fourni et que `bash` ne se trouve pas dans le chemin. | `sh -e {0}` |\n| Windows | `cmd` | GitHub ajoute l’extension `.cmd` au nom de votre script et se substitue à `{0}`. | `%ComSpec% /D /E:ON /V:OFF /S /C \"CALL \"{0}\"\"`. |\n| Windows | `pwsh` | Il s’agit de l’interpréteur de commandes par défaut utilisé sur Windows. PowerShell Core. GitHub ajoute l’extension `.ps1` au nom de votre script. Si *PowerShell Core* n’est pas installé sur votre exécuteur Windows auto-hébergé, *PowerShell Desktop* est utilisé à la place. | `pwsh -command \". '{0}'\"`. |\n| Windows | `powershell` | PowerShell Desktop. GitHub ajoute l’extension `.ps1` au nom de votre script. | `powershell -command \". '{0}'\"`. |\n\nVous pouvez également spécifier un shell par défaut pour toutes les étapes `run` d'un projet ou pour toutes les étapes `run` de l'ensemble du flux de travail. Pour plus d’informations, consultez [`defaults.run.shell`](/fr/actions/using-workflows/workflow-syntax-for-github-actions#defaultsrunshell) et [`jobs..defaults.run.shell`](/fr/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_iddefaultsrunshell).\n\n### Exemple : Exécution d’une commande à l’aide de Bash\n\n```yaml\nsteps:\n - name: Display the path\n shell: bash\n run: echo $PATH\n```\n\n### Exemple : Exécution d’une commande à l’aide de Windows `cmd`\n\n```yaml\nsteps:\n - name: Display the path\n shell: cmd\n run: echo %PATH%\n```\n\n### Exemple : Exécution d’une commande à l’aide de PowerShell Core\n\n```yaml\nsteps:\n - name: Display the path\n shell: pwsh\n run: echo ${env:PATH}\n```\n\n### Exemple : Utilisation de PowerShell Desktop pour exécuter une commande\n\n```yaml\nsteps:\n - name: Display the path\n shell: powershell\n run: echo ${env:PATH}\n```\n\n### Exemple : Exécution d’un script Python inline\n\n```yaml\nsteps:\n - name: Display the path\n shell: python\n run: |\n import os\n print(os.environ['PATH'])\n```\n\n### Interpréteur de commandes personnalisé\n\nVous pouvez définir la valeur `shell` sur une chaîne de modèle à l’aide de `command [options] {0} [more_options]`.\nGitHub interprète le premier mot délimité par des espaces blancs de la chaîne en tant que commande et insère le nom de fichier pour le script temporaire à l’adresse `{0}`.\n\nPar exemple :\n\n```yaml\nsteps:\n - name: Display the environment variables and their values\n shell: perl {0}\n run: |\n print %ENV\n```\n\nLa commande utilisée, `perl` dans cet exemple, doit être installée sur l’exécuteur.\n\nPour plus d’informations sur le logiciel inclus sur les exécuteurs hébergés par GitHub, consultez [Exécuteurs hébergés par GitHub](/fr/actions/using-github-hosted-runners/about-github-hosted-runners#supported-software).\n\n### Codes de sortie et préférence d’action en cas d’erreur\n\nPour les mots-clés de shell intégrés, nous fournissons les valeurs par défaut suivantes qui sont exécutées par les coureurs GitHub-hébergés par. Vous devez utiliser ces instructions lors de l’exécution de scripts de l’interpréteur de commandes.\n\n* `bash`\n /\n `sh`:\n * Par défaut, le comportement fail-fast est appliqué en utilisant `set -e` tant pour `sh` que pour `bash`. Lorsque `shell: bash` est spécifié, `-o pipefail` est également appliqué pour mettre en œuvre la sortie anticipée des pipelines qui génèrent un état de sortie différent de zéro.\n * Vous pouvez prendre le contrôle total des paramètres de l’interpréteur de commandes en fournissant une chaîne de modèle aux options de l’interpréteur de commandes. Par exemple : `bash {0}`.\n * Les interpréteurs de commandes de type `sh` se terminent par le code de sortie de la dernière commande exécutée dans un script, ce qui est également le comportement par défaut pour les actions. L’exécuteur signale l’état de l’étape en tant qu’échec/réussite en fonction de ce code de sortie.\n\n* `powershell`/`pwsh`\n * Comportement Fail-fast lorsque cela est possible. Pour l’interpréteur de commandes intégré `pwsh` et `powershell`, nous allons ajouter `$ErrorActionPreference = 'stop'` au contenu du script.\n * Nous ajoutons `if ((Test-Path -LiteralPath variable:\\LASTEXITCODE)) { exit $LASTEXITCODE }` aux scripts PowerShell afin que les états d’action reflètent le dernier code de sortie du script.\n * Les utilisateurs peuvent toujours choisir de ne pas utiliser l’interpréteur de commandes intégré et de fournir une option d’interpréteur de commandes personnalisée comme `pwsh -File {0}` ou `powershell -Command \"& '{0}'\"`, selon les besoins.\n\n* `cmd`\n * Il semble qu’il n’existe pas de moyen d’adopter entièrement un comportement Fail-fast autre que l’écriture de votre script pour vérifier chaque code d’erreur et répondre en conséquence. Étant donné que nous ne pouvons en fait pas fournir ce comportement par défaut, vous devez écrire ce comportement dans votre script.\n * `cmd.exe` s’arrête avec le niveau d’erreur du dernier programme qu’il a exécuté, et retourne le code d’erreur à l’exécuteur. Ce comportement est cohérent en interne avec le comportement par défaut précédent de `sh` et de `pwsh`, et c’est la valeur par défaut de `cmd.exe`. Ce comportement reste donc intact.\n\n## `jobs..steps[*].with`\n\nMappage (`map`) des paramètres d’entrée définis par l’action. Chaque paramètre d’entrée est une paire clé/valeur. Les paramètres d’entrée sont définis en tant que variables d’environnement. La variable est dotée du préfixe `INPUT_` et est convertie en majuscules.\n\nLes paramètres d’entrée définis pour un conteneur Docker doivent utiliser `args`. Pour plus d’informations, consultez [`jobs..steps[*].with.args`](#jobsjob_idstepswithargs).\n\n### Exemple de `jobs..steps[*].with`\n\nDéfinit les trois paramètres d’entrée (`first_name`, `middle_name` et `last_name`) définis par l’action `hello_world`. Ces variables d’entrée seront accessibles à l’action `hello-world` en tant que variables d’environnement `INPUT_FIRST_NAME`, `INPUT_MIDDLE_NAME` et `INPUT_LAST_NAME`.\n\n```yaml\njobs:\n my_first_job:\n steps:\n - name: My first step\n uses: actions/hello_world@main\n with:\n first_name: Mona\n middle_name: The\n last_name: Octocat\n```\n\n## `jobs..steps[*].with.args`\n\nUne valeur `string` définit les entrées d’un conteneur Docker.\nGitHub passe le `args` au `ENTRYPOINT` du conteneur lors du démarrage de celui-ci. Un `array of strings` n’est pas pris en charge par ce paramètre. Un argument unique qui inclut des espaces doit être entouré de guillemets doubles `\"\"`.\n\n### Exemple de `jobs..steps[*].with.args`\n\n```yaml\nsteps:\n - name: Explain why this job ran\n uses: octo-org/action-name@main\n with:\n entrypoint: /bin/echo\n args: The ${{ github.event_name }} event triggered this step.\n```\n\nLes valeurs `args` sont utilisées à la place de l’instruction `CMD` dans un `Dockerfile`. Si vous utilisez `CMD` dans votre `Dockerfile`, utilisez les instructions classées par ordre de préférence :\n\n1. Documentez les arguments requis dans le fichier README de l’action et omettez-les de l’instruction `CMD`.\n2. Utilisez les valeurs par défaut qui autorisent l’utilisation de l’action sans spécifier aucune valeur `args`.\n3. Si l’action expose un indicateur `--help`, ou quelque chose de similaire, utilisez-le comme valeur par défaut pour rendre votre action auto-documentée.\n\n## `jobs..steps[*].with.entrypoint`\n\nRemplace la valeur `ENTRYPOINT` Docker dans le `Dockerfile`, ou la définit si aucune n’est encore spécifiée. Contrairement à l’instruction Docker `ENTRYPOINT` qui a un interpréteur de commandes et le format exec, le mot clé `entrypoint` accepte une seule chaîne définissant l’exécutable à exécuter.\n\n### Exemple de `jobs..steps[*].with.entrypoint`\n\n```yaml\nsteps:\n - name: Run a custom command\n uses: octo-org/action-name@main\n with:\n entrypoint: /a/different/executable\n```\n\nLe mot clé `entrypoint` est destiné à être utilisé avec des actions de conteneur Docker, mais vous pouvez également l’utiliser avec des actions JavaScript qui ne définissent aucune entrée.\n\n## `jobs..steps[*].env`\n\nDéfinit des variables pour les étapes à utiliser dans l’environnement de l’exécuteur. Vous pouvez également définir des variables pour l’ensemble du workflow ou pour un travail. Pour plus d’informations, consultez [`env`](#env) et [`jobs..env`](#jobsjob_idenv).\n\nQuand plusieurs variables d’environnement sont définies avec le même nom, GitHub utilise la variable la plus spécifique. Par exemple, une variable d’environnement définie dans une étape remplace les variables d’environnement du travail et du workflow portant le même nom, pendant l’exécution de l’étape. Une variable d’environnement définie pour un travail remplace une variable de workflow de même nom, pendant l’exécution du travail.\n\nLes actions publiques peuvent spécifier les variables attendues dans le fichier README. Si vous définissez un secret ou une valeur sensible, comme un mot de passe ou un jeton, vous devez définir des secrets à l’aide du contexte `secrets`. Pour plus d’informations, consultez « [Référence des contextes](/fr/actions/learn-github-actions/contexts) ».\n\n### Exemple de `jobs..steps[*].env`\n\n```yaml\nsteps:\n - name: My first action\n env:\n GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}\n FIRST_NAME: Mona\n LAST_NAME: Octocat\n```\n\n## `jobs..steps[*].continue-on-error`\n\nEmpêche que l’échec d’une étape fasse échouer un travail. Définissez la valeur `true` pour permettre à un travail de réussir en cas d’échec de cette étape.\n\n## `jobs..steps[*].timeout-minutes`\n\nNombre maximal de minutes pour exécuter l’étape avant l’arrêt du processus. Maximum : 360 pour les coureurs hébergés par GitHub- et les coureurs auto-hébergés.\n\nLes valeurs fractionnaires ne sont pas prises en charge.\n`timeout-minutes` doit être un entier positif.\n\n## `jobs..timeout-minutes`\n\nNombre maximal de minutes pendant lesquelles un travail peut s'exécuter avant que GitHub ne l'annule automatiquement. Valeur par défaut : 360\n\nSi le délai d’expiration dépasse le délai d’exécution du travail pour l’exécuteur, le travail est annulé lorsque le délai d’exécution est écoulé à la place. Pour plus d’informations sur les limites de temps d’exécution des tâches, consultez [Facturation et utilisation](/fr/actions/learn-github-actions/usage-limits-billing-and-administration#usage-limits) pour GitHub- les coureurs hébergés par [Limites d’Actions](/fr/actions/hosting-your-own-runners/managing-self-hosted-runners/usage-limits-for-self-hosted-runners) pour les limites d’utilisation des coureurs auto-hébergés.\n\n> \\[!NOTE]\n> Le `GITHUB_TOKEN` expire à la fin d’un travail ou après un délai maximal de 24 heures. Pour les coureurs auto-hébergés, le jeton peut constituer le facteur limitant si le délai d’exécution de la tâche dépasse 24 heures. Pour plus d’informations sur `GITHUB_TOKEN`, consultez « [Utiliser GITHUB\\_TOKEN pour l’authentification dans les flux de travail](/fr/actions/security-guides/automatic-token-authentication#about-the-github_token-secret) ».\n\n## `jobs..strategy`\n\nUtilisez `jobs..strategy` pour utiliser une stratégie de matrice pour vos travaux.\nUne stratégie de matrice vous permet d’utiliser des variables dans une définition de travail unique pour créer automatiquement plusieurs exécutions de travaux basées sur les combinaisons des variables. Par exemple, vous pouvez utiliser une stratégie de matrice pour tester votre code dans plusieurs versions d’un langage ou sur plusieurs systèmes d’exploitation. Pour plus d’informations, consultez [Exécution de variantes de tâches dans un workflow](/fr/actions/using-jobs/using-a-matrix-for-your-jobs).\n\n## `jobs..strategy.matrix`\n\nUtilisez `jobs..strategy.matrix` pour définir une matrice de différentes configurations de travail. Pour plus d’informations, consultez « [Exécution de variantes de tâches dans un workflow](/fr/actions/how-tos/writing-workflows/choosing-what-your-workflow-does/running-variations-of-jobs-in-a-workflow) ».\n\nUne matrice génère au maximum 256 travaux par exécution de workflow. Cette limite s’applique aux coureurs hébergés par GitHub- ainsi qu’aux coureurs auto-hébergés.\n\nLes variables que vous définissez deviennent des propriétés dans le contexte `matrix`. Vous pouvez référencer la propriété dans d’autres zones de votre fichier de workflow. Dans cet exemple, vous pouvez utiliser `matrix.version` et `matrix.os` pour accéder aux valeurs actuelles de `version` et `os` utilisées par le travail. Pour plus d’informations, consultez « [Référence des contextes](/fr/actions/learn-github-actions/contexts) ».\n\nPar défaut, GitHub maximisera le nombre de travaux exécutés en parallèle en fonction de la disponibilité de l’exécutant. L’ordre des variables dans la matrice détermine l’ordre dans lequel les travaux sont créés. La première variable que vous définissez est le premier travail créé dans votre exécution de workflow.\n\n### Utilisation d’une matrice à une seule dimension\n\nLe workflow suivant définit la variable `version` avec les valeurs `[10, 12, 14]`. Le workflow exécute trois travaux, un pour chaque valeur de la variable. Chaque travail accède à la valeur `version` via le contexte `matrix.version`, et passe la valeur en tant que `node-version` à l’action `actions/setup-node`.\n\n```yaml\njobs:\n example_matrix:\n strategy:\n matrix:\n version: [10, 12, 14]\n steps:\n - uses: actions/setup-node@v4\n with:\n node-version: ${{ matrix.version }}\n```\n\n### Utilisation d’une matrice multidimensionnelle\n\nSpécifiez plusieurs variables pour créer une matrice multidimensionnelle. Une tâche sera exécutée pour chaque combinaison possible des variables.\n\nPar exemple, le workflow suivant spécifie deux variables :\n\n* Deux systèmes d’exploitation spécifiés dans la variable `os`\n* Trois versions de Node.js spécifiées dans la variable `version`\n\nLe workflow exécute six travaux, un pour chaque combinaison des variables `os` et `version`. Chaque travail affecte la valeur `runs-on` à la valeur `os` actuelle, et passe la valeur `version` actuelle à l’action `actions/setup-node`.\n\n```yaml\njobs:\n example_matrix:\n strategy:\n matrix:\n os: [ubuntu-22.04, ubuntu-24.04]\n version: [10, 12, 14]\n runs-on: ${{ matrix.os }}\n steps:\n - uses: actions/setup-node@v4\n with:\n node-version: ${{ matrix.version }}\n```\n\nUne configuration de variable dans une matrice peut être un `array` de `object`s. Par exemple, la matrice suivante produit 4 travaux avec des contextes correspondants.\n\n```yaml\nmatrix:\n os:\n - ubuntu-latest\n - macos-latest\n node:\n - version: 14\n - version: 20\n env: NODE_OPTIONS=--openssl-legacy-provider\n```\n\nChaque travail de la matrice aura sa propre combinaison de valeurs de `os` et de `node` , comme indiqué ci-dessous.\n\n```yaml\n- matrix.os: ubuntu-latest\n matrix.node.version: 14\n- matrix.os: ubuntu-latest\n matrix.node.version: 20\n matrix.node.env: NODE_OPTIONS=--openssl-legacy-provider\n- matrix.os: macos-latest\n matrix.node.version: 14\n- matrix.os: macos-latest\n matrix.node.version: 20\n matrix.node.env: NODE_OPTIONS=--openssl-legacy-provider\n```\n\n## `jobs..strategy.matrix.include`\n\nPour chaque objet de la liste `include`, les paires clé:valeur dans l’objet sont ajoutées à chacune des combinaisons de matrices si aucune des paires clé:valeur ne remplace les valeurs de matrice d’origine. Si l’objet ne peut pas être ajouté à l’une des combinaisons de matrices, une nouvelle combinaison de matrices est créée à la place. Notez que les valeurs de matrice d’origine ne seront pas remplacées, mais que les valeurs de matrice ajoutées peuvent être remplacées.\n\n### Exemple : Développement de configurations\n\nPar exemple, le workflow suivant exécute quatre tâches, un pour chaque combinaison de `os` et `node`. Lorsque le travail pour la valeur `os` de `windows-latest` et la valeur `node` de `16` s’exécute, une variable supplémentaire appelée `npm` avec la valeur `6` sera incluse dans le travail.\n\n```yaml\njobs:\n example_matrix:\n strategy:\n matrix:\n os: [windows-latest, ubuntu-latest]\n node: [14, 16]\n include:\n - os: windows-latest\n node: 16\n npm: 6\n runs-on: ${{ matrix.os }}\n steps:\n - uses: actions/setup-node@v4\n with:\n node-version: ${{ matrix.node }}\n - if: ${{ matrix.npm }}\n run: npm install -g npm@${{ matrix.npm }}\n - run: npm --version\n```\n\n### Exemple : Ajout de configurations\n\nPar exemple, cette matrice exécutera 10 travaux, un pour chaque combinaison de `os` et `version` dans la matrice, plus un travail pour la valeur `os` de `windows-latest` et la valeur `version` de `17`.\n\n```yaml\njobs:\n example_matrix:\n strategy:\n matrix:\n os: [macos-latest, windows-latest, ubuntu-latest]\n version: [12, 14, 16]\n include:\n - os: windows-latest\n version: 17\n```\n\nSi vous ne spécifiez aucune variable de matrice, toutes les configurations sous `include` sont exécutées. Par exemple, le workflow suivant exécuterait deux travaux, un pour chaque entrée `include`. Cela vous permet de tirer parti de la stratégie de matrice sans avoir une matrice entièrement remplie.\n\n```yaml\njobs:\n includes_only:\n runs-on: ubuntu-latest\n strategy:\n matrix:\n include:\n - site: \"production\"\n datacenter: \"site-a\"\n - site: \"staging\"\n datacenter: \"site-b\"\n```\n\n## `jobs..strategy.matrix.exclude`\n\nUne configuration exclue a seulement besoin d’être une correspondance partielle pour être exclue.\n\n```\n `include` Toutes les combinaisons sont traitées après `exclude`. Cela vous permet d’utiliser `include` pour rajouter des combinaisons qui ont été précédemment exclues.\n```\n\n## `jobs..strategy.fail-fast`\n\nVous pouvez contrôler la façon dont les échecs de travaux sont gérés avec `jobs..strategy.fail-fast` et `jobs..continue-on-error`.\n\n`jobs..strategy.fail-fast` s’applique à l’ensemble de la matrice. Si `jobs..strategy.fail-fast` est défini sur `true`, ou son expression aboutit à `true`, GitHub annule tous les travaux en cours et en file d’attente dans la matrice en cas d’échec d’un des travaux de la matrice. Cette propriété a la valeur par défaut `true`.\n\n`jobs..continue-on-error` s’applique à un seul travail. Si `jobs..continue-on-error` a la valeur `true`, les autres travaux de la matrice continuent de s’exécuter même en cas d’échec du travail avec `jobs..continue-on-error: true`.\n\nVous pouvez utiliser `jobs..strategy.fail-fast` et `jobs..continue-on-error` ensemble. Par exemple, le workflow suivant démarre quatre travaux. Pour chaque travail, `continue-on-error` est déterminé par la valeur de `matrix.experimental`. En cas d’échec de l’un des travaux avec `continue-on-error: false`, tous les travaux en cours ou en file d’attente sont annulés. En cas d’échec du travail avec `continue-on-error: true`, les autres travaux ne sont pas affectés.\n\n```yaml\njobs:\n test:\n runs-on: ubuntu-latest\n continue-on-error: ${{ matrix.experimental }}\n strategy:\n fail-fast: true\n matrix:\n version: [6, 7, 8]\n experimental: [false]\n include:\n - version: 9\n experimental: true\n```\n\n## `jobs..strategy.max-parallel`\n\nPar défaut, GitHub maximisera le nombre de travaux exécutés en parallèle en fonction de la disponibilité de l’exécutant.\n\n## `jobs..continue-on-error`\n\n```\n `jobs..continue-on-error` s’applique à un seul travail. Si `jobs..continue-on-error` a la valeur `true`, les autres travaux de la matrice continuent de s’exécuter même en cas d’échec du travail avec `jobs..continue-on-error: true`.\n```\n\nEmpêche que l’échec d’un travail fasse échouer une exécution de workflow. Définissez la valeur `true` pour permettre à un workflow de réussir en cas d’échec de ce travail.\n\n### Exemple : Empêcher un job de matrice défaillant spécifique de compromettre l'exécution d'un workflow.\n\nVous pouvez autoriser l’échec de travaux spécifiques d’une matrice de travaux sans faire échouer l’exécution du workflow. Par exemple, si vous souhaitiez autoriser uniquement l'échec d'un travail expérimental configuré avec `node` sur `15` sans compromettre l’exécution du workflow.\n\n```yaml\nruns-on: ${{ matrix.os }}\ncontinue-on-error: ${{ matrix.experimental }}\nstrategy:\n fail-fast: false\n matrix:\n node: [13, 14]\n os: [macos-latest, ubuntu-latest]\n experimental: [false]\n include:\n - node: 15\n os: ubuntu-latest\n experimental: true\n```\n\n## `jobs..container`\n\n> \\[!NOTE]\n> Si vos flux de travail utilisent des actions de conteneurs Docker, des conteneurs de tâches ou des conteneurs de services, vous devez utiliser un programme d'exécution Linux :\n>\n> * Si vous utilisez des exécuteurs hébergés sur GitHub, vous devez utiliser un exécuteur Ubuntu.\n> * Si vous utilisez des exécuteurs autohébergés, vous devez utiliser une machine Linux en tant qu’exécuteur, et Docker doit être installé.\n\nUtilisez `jobs..container` pour créer un conteneur permettant d’exécuter les étapes d’un travail qui ne spécifient pas encore de conteneur. Si vous avez des étapes qui utilisent à la fois des actions de script et des actions de conteneur, les actions de conteneur s’exécutent en tant que conteneurs frères sur le même réseau avec les mêmes montages de volume.\n\nSi vous ne définissez pas de `container`, toutes les étapes s’exécutent directement sur l’hôte spécifié par `runs-on`, sauf si une étape fait référence à une action configurée pour s’exécuter dans un conteneur.\n\n> \\[!NOTE]\n> L’interpréteur de commandes par défaut pour les étapes `run` incluses dans un conteneur est `sh` plutôt que `bash`. Vous pouvez le remplacer par [`jobs..defaults.run`](/fr/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_iddefaultsrun) ou [`jobs..steps[*].shell`](/fr/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idstepsshell).\n\n### Exemple : Exécution d’un travail dans un conteneur\n\n```yaml copy\nname: CI\non:\n push:\n branches: [ main ]\njobs:\n container-test-job:\n runs-on: ubuntu-latest\n container:\n image: node:18\n env:\n NODE_ENV: development\n ports:\n - 80\n volumes:\n - my_docker_volume:/volume_mount\n options: --cpus 1\n steps:\n - name: Check for dockerenv file\n run: (ls /.dockerenv && echo Found dockerenv) || (echo No dockerenv)\n```\n\nQuand vous spécifiez uniquement une image conteneur, vous pouvez omettre le mot clé `image`.\n\n```yaml\njobs:\n container-test-job:\n runs-on: ubuntu-latest\n container: node:18\n```\n\n## `jobs..container.image`\n\nUtilisez `jobs..container.image` pour définir l’image Docker à utiliser en tant que conteneur afin d’exécuter l’action. La valeur peut être le nom de l’image Docker Hub ou un nom de registre.\n\n> \\[!NOTE]\n> Docker Hub impose normalement des limites de débit sur les opérations d’envoi (push) et de tirage (pull), ce qui affectera les tâches sur les exécuteurs auto-hébergés. Toutefois, les exécuteurs hébergés par GitHub ne sont pas soumis à ces limites, conformément à un accord entre GitHub et Docker.\n\n## `jobs..container.credentials`\n\nSi le registre de conteneurs de l’image nécessite une authentification pour tirer l’image, vous pouvez utiliser `jobs..container.credentials` pour définir un `map` de `username` et de `password`. Les informations d’identification correspondent aux mêmes valeurs que celles que vous fournissez à la commande [`docker login`](https://docs.docker.com/engine/reference/commandline/login/).\n\n### Exemple : Définition des informations d’identification d’un registre de conteneurs\n\n```yaml\ncontainer:\n image: ghcr.io/owner/image\n credentials:\n username: ${{ github.actor }}\n password: ${{ secrets.github_token }}\n```\n\n## `jobs..container.env`\n\nUtilisez `jobs..container.env` pour définir un `map` de variables d’environnement dans le conteneur.\n\n## `jobs..container.ports`\n\nUtilisez `jobs..container.ports` pour définir un `array` de ports à exposer sur le conteneur.\n\n## `jobs..container.volumes`\n\nUtilisez `jobs..container.volumes` pour définir un `array` de volumes à utiliser par le conteneur. Vous pouvez utiliser des volumes pour partager des données entre des services ou d’autres étapes d’un travail. Vous pouvez spécifier des volumes Docker nommés, des volumes Docker anonymes ou des montages de liaisons sur l’hôte.\n\nPour spécifier un volume, vous spécifiez le chemin source et le chemin de destination :\n\n`:`.\n\nLa valeur `` est un nom de volume ou un chemin absolu sur la machine hôte et `` est un chemin absolu dans le conteneur.\n\n### Exemple : Montage de volumes dans un conteneur\n\n```yaml\nvolumes:\n - my_docker_volume:/volume_mount\n - /data/my_data\n - /source/directory:/destination/directory\n```\n\n## `jobs..container.options`\n\nUtilisez `jobs..container.options` pour configurer des options supplémentaires de ressources de conteneur Docker. Pour obtenir la liste des options, consultez « [Options `docker create`](https://docs.docker.com/engine/reference/commandline/create/#options) ».\n\n> \\[!WARNING]\n> Les options `--network` et `--entrypoint` ne sont pas prises en charge.\n\n## `jobs..services`\n\n> \\[!NOTE]\n> Si vos flux de travail utilisent des actions de conteneurs Docker, des conteneurs de tâches ou des conteneurs de services, vous devez utiliser un programme d'exécution Linux :\n>\n> * Si vous utilisez des exécuteurs hébergés sur GitHub, vous devez utiliser un exécuteur Ubuntu.\n> * Si vous utilisez des exécuteurs autohébergés, vous devez utiliser une machine Linux en tant qu’exécuteur, et Docker doit être installé.\n\nUtilisé pour héberger des conteneurs de service pour une tâche dans un workflow. Les conteneurs de service sont utiles pour créer des bases de données ou des services de cache comme Redis. L’exécuteur crée automatiquement un réseau Docker et gère le cycle de vie des conteneurs de service.\n\nSi vous configurez votre travail pour qu’il s’exécute dans un conteneur ou que votre étape utilise des actions de conteneur, vous n’avez pas besoin de mapper les ports pour accéder au service ou à l’action. Docker expose automatiquement tous les ports entre les conteneurs se trouvant sur le même réseau de pont défini par l’utilisateur Docker. Vous pouvez référencer directement le conteneur de service par son nom d’hôte. Le nom d’hôte est automatiquement mappé au nom d’étiquette que vous configurez pour le service dans le workflow.\n\nSi vous configurez le travail pour qu’il s’exécute directement sur la machine de l’exécuteur et que votre étape n’utilise pas d’action de conteneur, vous devez mapper tous les ports de conteneur de service Docker requis à l’hôte Docker (la machine de l’exécuteur). Vous pouvez accéder au conteneur de service à l’aide de localhost et du port mappé.\n\nPour plus d’informations sur les différences entre les conteneurs de service réseau, consultez « [Communication avec les conteneurs de service Docker](/fr/actions/using-containerized-services/about-service-containers) ».\n\n### Exemple : Utilisation de localhost\n\nCet exemple crée deux services : nginx et redis. Lorsque vous spécifiez le port du conteneur, mais pas le port de l’hôte, le port du conteneur est attribué de manière aléatoire à un port libre sur l’hôte.\nGitHub définit le port hôte affecté dans le `${{job.services..ports}}` contexte. Dans cet exemple, vous pouvez accéder aux ports hôtes du service à l’aide des contextes `${{ job.services.nginx.ports['80'] }}` et `${{ job.services.redis.ports['6379'] }}`.\n\n```yaml\nservices:\n nginx:\n image: nginx\n # Map port 8080 on the Docker host to port 80 on the nginx container\n ports:\n - 8080:80\n redis:\n image: redis\n # Map random free TCP port on Docker host to port 6379 on redis container\n ports:\n - 6379/tcp\nsteps:\n - run: |\n echo \"Redis available on 127.0.0.1:${{ job.services.redis.ports['6379'] }}\"\n echo \"Nginx available on 127.0.0.1:${{ job.services.nginx.ports['80'] }}\"\n```\n\n## `jobs..services..image`\n\nImage Docker à utiliser comme conteneur de service pour exécuter l’action. La valeur peut être le nom de l’image Docker Hub ou un nom de registre.\n\nSi `jobs..services..image` est une chaîne vide, le service ne démarre pas. Vous pouvez l’utiliser pour configurer des services conditionnels, comme dans l’exemple suivant.\n\n```yaml\nservices:\n nginx:\n image: ${{ options.nginx == true && 'nginx' || '' }}\n```\n\n## `jobs..services..credentials`\n\nSi le registre de conteneurs de l’image nécessite une authentification pour tirer l’image, vous pouvez utiliser `jobs..container.credentials` pour définir un `map` de `username` et de `password`. Les informations d’identification correspondent aux mêmes valeurs que celles que vous fournissez à la commande [`docker login`](https://docs.docker.com/engine/reference/commandline/login/).\n\n### Exemple de `jobs..services..credentials`\n\n```yaml\nservices:\n myservice1:\n image: ghcr.io/owner/myservice1\n credentials:\n username: ${{ github.actor }}\n password: ${{ secrets.github_token }}\n myservice2:\n image: dockerhub_org/myservice2\n credentials:\n username: ${{ secrets.DOCKER_USER }}\n password: ${{ secrets.DOCKER_PASSWORD }}\n```\n\n## `jobs..services..env`\n\nDéfinit un ensemble (`map`) de variables d'environnement dans le conteneur de service.\n\n## `jobs..services..ports`\n\nSpécifie un ensemble (`array`) de ports à exposer sur le conteneur de service.\n\n## `jobs..services..volumes`\n\nDéfinit un tableau (`array`) de volumes pour le conteneur de service à utiliser. Vous pouvez utiliser des volumes pour partager des données entre des services ou d’autres étapes d’un travail. Vous pouvez spécifier des volumes Docker nommés, des volumes Docker anonymes ou des montages de liaisons sur l’hôte.\n\nPour spécifier un volume, vous spécifiez le chemin source et le chemin de destination :\n\n```\n `:`.\n```\n\nLa valeur `` est un nom de volume ou un chemin absolu sur la machine hôte et `` est un chemin absolu dans le conteneur.\n\n### Exemple de `jobs..services..volumes`\n\n```yaml\nvolumes:\n - my_docker_volume:/volume_mount\n - /data/my_data\n - /source/directory:/destination/directory\n```\n\n## `jobs..services..options`\n\nOptions de ressources de conteneur Docker supplémentaires. Pour obtenir la liste des options, consultez « [Options `docker create`](https://docs.docker.com/engine/reference/commandline/create/#options) ».\n\n> \\[!WARNING]\n> L'option `--network` n'est pas prise en charge.\n\n## `jobs..services..command`\n\nRemplace la commande par défaut de l’image Docker (`CMD`). La valeur est passée comme arguments après le nom de l’image dans la commande `docker create`. Si vous spécifiez `entrypoint`également , `command` fournit les arguments à ce point d’entrée.\n\n### Exemple de `jobs..services..command`\n\n```yaml\nservices:\n mysql:\n image: mysql:8\n command: --sql_mode=STRICT_TRANS_TABLES --max_allowed_packet=512M\n env:\n MYSQL_ROOT_PASSWORD: test\n ports:\n - 3306:3306\n```\n\n## `jobs..services..entrypoint`\n\nRemplace la valeur par défaut `ENTRYPOINT`de l’image Docker. La valeur est une chaîne unique définissant l’exécutable à exécuter. Utilisez cette option lorsque vous devez remplacer entièrement le point d’entrée de l’image. Vous pouvez combiner `entrypoint` avec `command` pour passer des arguments au point d’entrée personnalisé.\n\n### Exemple de `jobs..services..entrypoint`\n\n```yaml\nservices:\n etcd:\n image: quay.io/coreos/etcd:v3.5.17\n entrypoint: etcd\n command: >-\n --listen-client-urls http://0.0.0.0:2379\n --advertise-client-urls http://0.0.0.0:2379\n ports:\n - 2379:2379\n```\n\n## `jobs..uses`\n\nEmplacement et version d’un fichier de workflow réutilisable à exécuter en tant que travail. Utilisez l’une des syntaxes suivantes :\n\n* `{owner}/{repo}/.github/workflows/{filename}@{ref}` pour les flux de travail réutilisables dans les référentiels publics et privés.\n* `./.github/workflows/{filename}` pour des workflows réutilisables dans le même dépôt.\n\nDans la première options, `{ref}` peut être un SHA, une étiquette de mise en production ou un nom de branche. Si une balise de mise en production et une branche portent le même nom, la balise de mise en production est prioritaire sur le nom de la branche. L’utilisation du SHA de validation est l’option la plus sûre pour la stabilité et la sécurité. Pour plus d’informations, consultez « [Informations de référence sur l’utilisation sécurisée](/fr/actions/security-guides/security-hardening-for-github-actions#reusing-third-party-workflows) ».\n\nSi vous utilisez la deuxième option de syntaxe (sans `{owner}/{repo}` et `@{ref}`), le workflow appelé provient du même commit que le workflow appelant. Les préfixes ref tels que `refs/heads` et `refs/tags` ne sont pas autorisés. Vous ne pouvez pas utiliser de contextes ou d’expressions dans ce mot clé.\n\n### Exemple de `jobs..uses`\n\n```yaml\njobs:\n call-workflow-1-in-local-repo:\n uses: octo-org/this-repo/.github/workflows/workflow-1.yml@172239021f7ba04fe7327647b213799853a9eb89\n call-workflow-2-in-local-repo:\n uses: ./.github/workflows/workflow-2.yml\n call-workflow-in-another-repo:\n uses: octo-org/another-repo/.github/workflows/workflow.yml@v1\n```\n\nPour plus d’informations, consultez « [Réutiliser des workflows](/fr/actions/using-workflows/reusing-workflows) ».\n\n## `jobs..with`\n\nLorsqu’un travail est utilisé pour appeler un workflow réutilisable, vous pouvez utiliser `with` pour fournir un mappage d’entrées qui sont passées au workflow appelé.\n\nToutes les entrées que vous passez doivent correspondre aux spécifications d’entrée définies dans le workflow appelé.\n\nContrairement à [`jobs..steps[*].with`](#jobsjob_idstepswith), les entrées que vous passez avec `jobs..with` sont non disponibles en tant que variables d’environnement dans le workflow appelé. Au lieu de cela, vous pouvez référencer les entrées à l’aide du contexte `inputs`.\n\n### Exemple de `jobs..with`\n\n```yaml\njobs:\n call-workflow:\n uses: octo-org/example-repo/.github/workflows/called-workflow.yml@main\n with:\n username: mona\n```\n\n## `jobs..with.`\n\nPaire composée d’un identificateur de chaîne pour l’entrée et de la valeur de l’entrée. L’identificateur doit correspondre au nom d’une entrée définie par [`on.workflow_call.inputs.`](/fr/actions/creating-actions/metadata-syntax-for-github-actions#inputsinput_id) dans le workflow appelé. Le type de données de la valeur doit correspondre au type défini par [`on.workflow_call.inputs..type`](#onworkflow_callinputsinput_idtype) dans le workflow appelé.\n\nContextes d’expression autorisés : `github` et `needs`.\n\n## `jobs..secrets`\n\nLorsqu’un travail est utilisé pour appeler un workflow réutilisable, vous pouvez utiliser `secrets` pour fournir un mappage de secrets qui sont passés au workflow appelé.\n\nLes secrets que vous passez doivent correspondre aux noms définis dans le workflow appelé.\n\n### Exemple de `jobs..secrets`\n\n```yaml\njobs:\n call-workflow:\n uses: octo-org/example-repo/.github/workflows/called-workflow.yml@main\n secrets:\n access-token: ${{ secrets.PERSONAL_ACCESS_TOKEN }}\n```\n\n## `jobs..secrets.inherit`\n\nUtilisez le mot clé `inherit` pour passer tous les secrets du workflow appelant au workflow appelé. Sont inclus tous les secrets auxquels le workflow appelant a accès, notamment les secrets de l’organisation, des dépôts et de l’environnement. Le mot clé `inherit` peut être utilisé pour passer des secrets entre des dépôts au sein de la même organisation ou entre des organisations au sein de la même entreprise.\n\n### Exemple de `jobs..secrets.inherit`\n\n```yaml\non:\n workflow_dispatch:\n\njobs:\n pass-secrets-to-workflow:\n uses: ./.github/workflows/called-workflow.yml\n secrets: inherit\n```\n\n```yaml\non:\n workflow_call:\n\njobs:\n pass-secret-to-action:\n runs-on: ubuntu-latest\n steps:\n - name: Use a repo or org secret from the calling workflow.\n run: echo ${{ secrets.CALLING_WORKFLOW_SECRET }}\n```\n\n## `jobs..secrets.`\n\nPaire composée d'un identificateur de type chaîne pour le secret et de sa valeur. L’identificateur doit correspondre au nom d’un secret défini par [`on.workflow_call.secrets.`](#onworkflow_callsecretssecret_id) dans le workflow appelé.\n\nContextes d’expression autorisés : `github`, `needs` et `secrets`.\n\n## Aide-mémoire de modèle de filtre\n\nVous pouvez utiliser des caractères spéciaux dans les filtres de chemin, de branche et d’étiquette.\n\n* `*` : correspond à zéro caractère ou plus, mais ne correspond pas au caractère `/`. Par exemples, `Octo*` correspond à `Octocat`.\n* `**` : correspond à zéro caractère, quel qu’il soit, ou plus.\n* `?` : correspond à zéro caractère ou à l’un des caractères précédents.\n* `+` : correspond à l’un des caractères précédents, ou plus.\n* `[]` : correspond à un caractère alphanumérique indiqué entre crochets ou inclus dans des plages. Les plages ne peuvent inclure `a-z`, `A-Z` et `0-9`. Par exemple, la plage `[0-9a-z]` correspond à n’importe quel chiffre ou lettre minuscule. Par exemple, `[CB]at` correspond à `Cat` ou à `Bat`, et `[1-2]00` correspond à `100` et à `200`.\n* `!` : Placé au début d'un modèle, cela inverse les modèles positifs précédents. Il n’a pas de signification spéciale si ce n’est pas le premier caractère.\n\nLes caractères `*`, `[` et `!` sont des caractères spéciaux dans YAML. Si vous commencez un modèle avec `*`, `[` ou `!`, vous devez placer ce modèle entre guillemets. En outre, si vous utilisez une [séquence de flux](https://yaml.org/spec/1.2.2/#flow-sequences) avec un modèle contenant `[` et/ou `]`, le modèle doit être placé entre guillemets.\n\n```yaml\n# Valid\npaths:\n - '**/README.md'\n\n# Invalid - creates a parse error that\n# prevents your workflow from running.\npaths:\n - **/README.md\n\n# Valid\nbranches: [ main, 'release/v[0-9].[0-9]' ]\n\n# Invalid - creates a parse error\nbranches: [ main, release/v[0-9].[0-9] ]\n```\n\nPour plus d’informations sur la syntaxe des filtres de branche, d’étiquette et de chemin, consultez « [`on..`](#onpushbranchestagsbranches-ignoretags-ignore) », « [`on..`](#onpull_requestpull_request_targetbranchesbranches-ignore) » et « [`on..paths`](#onpushpull_requestpull_request_targetpathspaths-ignore) ».\n\n### Modèles pour établir une correspondance avec des branches et des étiquettes\n\n| Modèle | Description | Exemples de correspondances |\n| ------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------- |\n| `feature/*` | Le caractère générique `*` correspond à n’importe quel caractère, mais ne correspond pas à la barre oblique (`/`). | `feature/my-branch`

`feature/your-branch` |\n| `feature/**` | Le caractère générique `**` correspond à n’importe quel caractère, y compris la barre oblique (`/`), dans les noms de branche et d’étiquette. | `feature/beta-a/my-branch`

`feature/your-branch`

`feature/mona/the/octocat` |\n| `main`

`releases/mona-the-octocat` | Correspond au nom exact d’une branche ou d’une étiquette. | `main`

`releases/mona-the-octocat` |\n| `'*'` | Correspond à tous les noms de branche et d’étiquette qui ne contiennent pas de barre oblique (`/`). Le caractère `*` est un caractère spécial dans YAML. Lorsque vous commencez un modèle par `*`, vous devez utiliser des guillemets. | `main`

`releases` |\n| `'**'` | Correspond à tous les noms de branche et d’étiquette. Il s’agit du comportement par défaut lorsque vous n’utilisez pas de filtre `branches` ou `tags`. | `all/the/branches`

`every/tag` |\n| `'*feature'` | Le caractère `*` est un caractère spécial dans YAML. Lorsque vous commencez un modèle par `*`, vous devez utiliser des guillemets. | `mona-feature`

`feature`

`ver-10-feature` |\n| `v2*` | Correspond aux noms de branche et d’étiquette qui commencent par `v2`. | `v2`

`v2.0`

`v2.9` |\n| `v[12].[0-9]+.[0-9]+` | Correspond à toutes les branches et balises de versionnage sémantique avec la version majeure 1 ou 2. | `v1.10.1`

`v2.0.0` |\n\n### Modèles pour établir une correspondance avec des chemins de fichiers\n\nLes modèles de chemin doivent correspondre au chemin complet et commencer à la racine du dépôt.\n\n| Modèle | Description des correspondances | Exemples de correspondances |\n| -------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------- |\n| `'*'` | Le caractère générique `*` correspond à n’importe quel caractère, mais ne correspond pas à la barre oblique (`/`). Le caractère `*` est un caractère spécial dans YAML. Lorsque vous commencez un modèle par `*`, vous devez utiliser des guillemets. | `README.md`

`server.rb` |\n| `'*.jsx?'` | Le caractère `?` correspond à zéro caractère ou à l’un des caractères précédents. | `page.js`

`page.jsx` |\n| `'**'` | Le caractère générique `**` correspond à n’importe quel caractère, y compris la barre oblique (`/`). Il s’agit du comportement par défaut lorsque vous n’utilisez pas de filtre `path`. | `all/the/files.md` |\n| `'*.js'` | Le caractère générique `*` correspond à n’importe quel caractère, mais ne correspond pas à la barre oblique (`/`). Correspond à tous les fichiers `.js` se trouvant à la racine du dépôt. | `app.js`

`index.js` |\n| `'**.js'` | Correspond à tous les fichiers `.js` se trouvant dans le dépôt. | `index.js`

`js/index.js`

`src/js/app.js` |\n| `docs/*` | Tous les fichiers se trouvant à la racine du répertoire `docs` uniquement, à la racine du dépôt. | `docs/README.md`

`docs/file.txt` |\n| `docs/**` | Tous les fichiers du répertoire `docs` et de ses sous-répertoires à la racine du référentiel. | `docs/README.md`

`docs/mona/octocat.txt` |\n| `docs/**/*.md` | Fichier avec un suffixe `.md` n’importe où dans le répertoire `docs`. | `docs/README.md`

`docs/mona/hello-world.md`

`docs/a/markdown/file.md` |\n| `'**/docs/**'` | Tout fichier se trouvant dans un répertoire `docs` n’importe où dans le dépôt. | `docs/hello.md`

`dir/docs/my-file.txt`

`space/docs/plan/space.doc` |\n| `'**/README.md'` | Fichier README.md n’importe où dans le dépôt. | `README.md`

`js/README.md` |\n| `'**/*src/**'` | Tout fichier d’un dossier avec un suffixe `src` n’importe où dans le dépôt. | `a/src/app.js`

`my-src/code/js/app.js` |\n| `'**/*-post.md'` | Fichier avec le suffixe `-post.md` n’importe où dans le dépôt. | `my-post.md`

`path/their-post.md` |\n| `'**/migrate-*.sql'` | Fichier avec le préfixe `migrate-` et le suffixe `.sql` n’importe où dans le dépôt. | `migrate-10909.sql`

`db/migrate-v1.0.sql`

`db/sept/migrate-v1.sql` |\n| `'*.md'`

`'!README.md'` | L’utilisation d’un point d’exclamation (`!`) devant un modèle le neutralise. Lorsqu’un fichier correspond à un modèle et qu’il correspond également à un modèle négatif défini ultérieurement dans le fichier, ce fichier n’est pas inclus. | `hello.md`

|\n\n```\n _Ne correspond pas à_

`README.md`

`docs/hello.md` |\n```\n\n\\| `'*.md'`

`'!README.md'`

`README*` | Les modèles sont vérifiés de manière séquentielle. Un modèle qui neutralise un modèle précédent inclut à nouveau les chemins de fichier. | `hello.md`

`README.md`

`README.doc` |"}