Référence syntaxique des métadonnées

Remarque

Vous pouvez créer des actions composites, de conteneur Docker et JavaScript. Les actions nécessitent un fichier de métadonnées pour définir les entrées, les sorties et la configuration d’exécution de votre action. Les fichiers de métadonnées d’action utilisent la syntaxe YAML, et le nom du fichier de métadonnées doit être action.yml ou action.yaml. Le format préféré est action.yml.

`name`

          **Obligatoire** Le nom de votre action. GitHub affiche `name` sous l’onglet **Actions** pour identifier visuellement les actions de chaque travail.

`author`

          **Facultatif** Le nom de l’auteur de l’action.

`description`

          **Obligatoire** Une brève description de l’action.

`inputs`

          **Facultatif** Les paramètres d’entrée vous permettent de spécifier les données que l’action s’attend à utiliser lors de l’exécution. GitHub stocke les paramètres d’entrée en tant que variables d’environnement. Nous vous recommandons d’utiliser des ID d’entrée en minuscules.

Exemple Spécifier des entrées

Cet exemple configure deux entrées : num-octocats et octocat-eye-color. L’entrée num-octocats n’est pas obligatoire et a par défaut la valeur 1. octocat-eye-color est obligatoire et n’a pas de valeur par défaut.

Remarque

Les actions utilisant required: true ne renverront pas automatiquement une erreur si l'entrée n'est pas spécifiée.

Les fichiers de workflow qui utilisent cette action peuvent utiliser le mot clé with afin de définir une valeur d’entrée pour octocat-eye-color. Pour plus d’informations sur la withsyntaxe, consultez « Syntaxe de flux de travail pour GitHub Actions ».

inputs:
  num-octocats:
    description: 'Number of Octocats'
    required: false
    default: '1'
  octocat-eye-color:
    description: 'Eye color of the Octocats'
    required: true

Si vous spécifiez une entrée, GitHub crée une variable d’environnement pour l’entrée avec le nom INPUT_<VARIABLE_NAME>. La variable d’environnement créée convertit les noms d’entrée en lettres majuscules et remplace les espaces par des caractères _.

Si l’action est écrite à l’aide d’un composite, elle n’obtiendra pas automatiquement INPUT_<VARIABLE_NAME>. Avec les actions composites, vous pouvez utiliser inputsRéférence des contextes pour accéder aux entrées d’action.

Pour accéder à la variable d’environnement dans une action de conteneur Docker, vous devez passer l’entrée à l’aide du mot clé dans le fichier de métadonnées d’action args. Pour plus d’informations sur le fichier de métadonnées des actions de conteneur Docker, consultez « Création d’une action de conteneur Docker ».

Par exemple, si un workflow a défini les entrées num-octocats et octocat-eye-color, le code d’action peut lire les valeurs des entrées à l’aide des variables d’environnement INPUT_NUM-OCTOCATS et INPUT_OCTOCAT-EYE-COLOR.

`inputs.<input_id>`

          **Obligatoire** Un identificateur `string` à associer à l’entrée. La valeur de `<input_id>` est une carte des métadonnées de l’entrée. 
          `<input_id>` doit être un identificateur unique dans l’objet `inputs`. 
          `<input_id>` doit commencer par une lettre ou par `_`, et contenir uniquement des caractères alphanumériques, des `-` ou des `_`.

`inputs.<input_id>.description`

          **Obligatoire** Une description `string` des paramètres d’entrée.

`inputs.<input_id>.required`

          **Facultatif** Un `boolean` pour indiquer si l’action nécessite le paramètre d’entrée. À définir sur `true` si le paramètre est obligatoire.

`inputs.<input_id>.default`

          **Facultatif** Un `string` représentant la valeur par défaut. La valeur par défaut est utilisée lorsqu’un paramètre d’entrée n’est pas spécifié dans un fichier de workflow.

`inputs.<input_id>.deprecationMessage`

          **Facultatif** Si le paramètre d’entrée est utilisé, cette `string` est journalisée en tant que message d’avertissement. Vous pouvez utiliser cet avertissement pour informer les utilisateurs que l’entrée est déconseillé et leur proposer des alternatives.

          `outputs` pour les actions de conteneur Docker et JavaScript

          **Facultatif** Les paramètres de sortie vous permettent de déclarer les données qu’une action définit. Les actions qui s’exécutent par la suite dans un workflow peuvent utiliser le jeu de données de sortie des actions précédemment exécutées. Par exemple, si vous avez une action qui a réalisé l’addition de deux entrées (x + y = z), l’action peut générer la somme (z) d’autres actions afin de l’utiliser en tant qu’entrée.

Si vous ne déclarez pas de sortie dans votre fichier de métadonnées d’action, vous pouvez toujours définir des sorties et les utiliser dans un workflow. Pour plus d’informations sur la définition des sorties dans une action, consultez « Commandes de flux de travail pour GitHub Actions ».

Exemple : déclaration de sorties pour les actions de conteneur Docker et JavaScript

outputs:
  sum: # id of the output
    description: 'The sum of the inputs'

`outputs.<output_id>`

          **Obligatoire** Un identificateur `string` à associer à la sortie. La valeur de `<output_id>` est une carte des métadonnées de la sortie. 
          `<output_id>` doit être un identificateur unique dans l’objet `outputs`. 
          `<output_id>` doit commencer par une lettre ou par `_`, et contenir uniquement des caractères alphanumériques, des `-` ou des `_`.

`outputs.<output_id>.description`

          **Obligatoire** Une description `string` des paramètres de sortie.

          `outputs` pour les actions composites

          **Optionnel** Les `outputs` utilisent les mêmes paramètres que `outputs.<output_id>` et `outputs.<output_id>.description` (voir « [`outputs` pour les actions de conteneur Docker et JavaScript](#outputs-for-docker-container-and-javascript-actions) »), mais ils comprennent également le jeton `value`.

Exemple : déclaration de sorties pour les actions composites

outputs:
  random-number:
    description: "Random number"
    value: ${{ steps.random-number-generator.outputs.random-id }}
runs:
  using: "composite"
  steps:
    - id: random-number-generator
      run: echo "random-id=$(echo $RANDOM)" >> $GITHUB_OUTPUT
      shell: bash

`outputs.<output_id>.value`

          **Obligatoire** La valeur à laquelle le paramètre de sortie sera mappé. Vous pouvez définir cette valeur sur une `string` ou sur une expression avec un contexte. Par exemple, vous pouvez utiliser le contexte `steps` pour définir la `value` d'une sortie en fonction de la valeur de sortie d'une étape.

Pour plus d’informations sur l’utilisation de la syntaxe de contexte, consultez « Référence des contextes ».

`runs`

          **Obligatoire** Spécifie s’il s’agit d’une action JavaScript, d’une action composite ou d’une action de conteneur Docker, ainsi que la façon dont l’action est exécutée.

          `runs` pour les actions JavaScript

          **Obligatoire** Configure le chemin du code de l’action et le runtime utilisé pour exécuter le code.

Exemple : utilisation de Node.js v24

runs:
  using: 'node24'
  main: 'main.js'

          `runs.using` pour les actions JavaScript

          **Obligatoire** Le runtime utilisé pour exécuter le code spécifié dans [`main`](#runsmain).

Utilisez node20 pour Node.js v20.
Utilisez node24 pour Node.js v24.

`runs.main`

          **Obligatoire** Le fichier qui contient votre code d’action. Le runtime spécifié dans [`using`](#runsusing-for-javascript-actions) exécute ce fichier.

`runs.pre`

          **Facultatif** Permet d’exécuter un script au début d’un travail, avant que l’action `main:` ne commence. Par exemple, vous pouvez utiliser `pre:` pour exécuter un script de configuration prérequis. Le runtime spécifié avec la syntaxe [`using`](#runsusing-for-javascript-actions) exécute ce fichier. L’action `pre:` s’exécute toujours par défaut, mais vous pouvez modifier cela en utilisant [`runs.pre-if`](#runspre-if).

Remarque

          `runs.pre` n’est pas pris en charge pour les actions locales.

Dans cet exemple, l’action pre: exécute un script appelé setup.js :

runs:
  using: 'node24'
  pre: 'setup.js'
  main: 'index.js'
  post: 'cleanup.js'

`runs.pre-if`

          **Facultatif** Permet de définir des conditions pour l’exécution de l’action `pre:`. L’action `pre:` s’exécute uniquement si les conditions de `pre-if` sont remplies. Si les conditions ne sont pas définies, `pre-if` aura `always()` comme valeur par défaut. Dans `pre-if`, les fonctions de vérification d’état évaluent l’état du travail, et non l’état de l’action.

Notez que le contexte step n’est pas disponible, car aucune étape n’a encore été exécutée.

Dans cet exemple, cleanup.js s'exécute uniquement sur des agents basés sur Linux.

  pre: 'cleanup.js'
  pre-if: runner.os == 'linux'

`runs.post`

          **Optionnel** Permet d’exécuter un script à la fin d’un travail, une fois l’action `main:` terminée. Par exemple, vous pouvez utiliser `post:` pour arrêter certains processus ou supprimer des fichiers inutiles. Le runtime spécifié avec la syntaxe [`using`](#runsusing-for-javascript-actions) exécute ce fichier.

Dans cet exemple, l’action post: exécute un script appelé cleanup.js :

runs:
  using: 'node24'
  main: 'index.js'
  post: 'cleanup.js'

L’action post: s’exécute toujours par défaut, mais vous pouvez modifier cela en utilisant post-if.

`runs.post-if`

          **Facultatif** Permet de définir des conditions pour l’exécution de l’action `post:`. L’action `post:` s’exécute uniquement si les conditions de `post-if` sont remplies. Si les conditions ne sont pas définies, `post-if` aura `always()` comme valeur par défaut. Dans `post-if`, les fonctions de vérification d’état évaluent l’état du travail, et non l’état de l’action.

Par exemple, ce cleanup.js ne s’exécutera que sur les exécuteurs Linux :

  post: 'cleanup.js'
  post-if: runner.os == 'linux'

          `runs` pour les actions composites

          **Obligatoire** Configure le chemin de l’action composite.

          `runs.using` pour les actions composites

          **Obligatoire** Vous devez définir cette valeur sur `'composite'`.

`runs.steps`

          **Obligatoire** Les étapes que vous prévoyez d’exécuter dans cette action. Il peut s’agir d’étapes `run` ou `uses`.

`runs.steps[*].run`

          **Facultatif** La commande que vous souhaitez exécuter. Il peut s’agir d’un inline ou d’un script de votre dépôt d’actions :

runs:
  using: "composite"
  steps:
    - run: ${{ github.action_path }}/test/script.sh
      shell: bash

Vous pouvez également utiliser $GITHUB_ACTION_PATH :

runs:
  using: "composite"
  steps:
    - run: $GITHUB_ACTION_PATH/script.sh
      shell: bash

Pour plus d’informations, consultez « Référence des contextes ».

`runs.steps[*].shell`

          **Facultatif** Le shell dans lequel vous souhaitez exécuter la commande. Vous pouvez utiliser l’un des interpréteurs de commandes dans [AUTOTITLE](/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idstepsshell). Obligatoire si `run` est défini.

`runs.steps[*].if`

          **Facultatif** Vous 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.

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.

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 :

if: ${{ ! startsWith(github.ref, 'refs/tags/') }}

Pour plus d’informations, consultez « Évaluer des expressions dans les workflows et les actions. ».

          **Exemple : Utilisation des contextes**

Cette étape s’exécute uniquement lorsque le type d’événement est pull_request et que l’action d’événement est unassigned.

steps:
  - run: echo This event is a pull request that had an assignee removed.
    if: ${{ github.event_name == 'pull_request' && github.event.action == 'unassigned' }}

          **Exemple : Utilisation des fonctions de vérification d’état**

          `my backup step` s’exécute uniquement en cas d’échec de l’étape précédente d’une action composite. Pour plus d’informations, consultez « [AUTOTITLE](/actions/learn-github-actions/expressions#status-check-functions) ».

steps:
  - name: My first step
    uses: octo-org/action-name@main
  - name: My backup step
    if: ${{ failure() }}
    uses: actions/heroku@1.0.0

`runs.steps[*].name`

          **Facultatif** Le nom de l’étape composite.

`runs.steps[*].id`

          **Facultatif** Un identificateur unique pour l’étape. Vous pouvez utiliser `id` pour référencer l’étape dans des contextes. Pour plus d’informations, consultez « [AUTOTITLE](/actions/learn-github-actions/contexts) ».

`runs.steps[*].env`

          **Facultatif** Définit une variable d’environnement `map` pour cette étape uniquement. Si vous souhaitez modifier la variable d’environnement stockée dans le workflow, utilisez `echo "{name}={value}" >> $GITHUB_ENV` dans une étape composite.

`runs.steps[*].working-directory`

          **Facultatif** Spécifie le répertoire de travail dans lequel la commande est exécutée.

`runs.steps[*].uses`

          **Facultatif** Sé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/).

Nous vous recommandons vivement d’inclure la version de l’action que vous utilisez en spécifiant un numéro d’é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.

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é.
L’utilisation de la version d’action majeure spécifique vous permet de recevoir des correctifs critiques et des correctifs de sécurité tout en maintenant la compatibilité. Cela garantit également que votre workflow continue de fonctionner.
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 cassant, votre workflow peut s’arrêter.

Certaines actions nécessitent des entrées que vous devez définir à l’aide du mot clé with. Examinez le fichier README de l’action pour déterminer les entrées nécessaires.

runs:
  using: "composite"
  steps:
    # Reference a specific commit
    - uses: actions/checkout@8f4b7f84864484a7bf31766abe9204da3cbe65b3
    # Reference the major version of a release
    - uses: actions/checkout@v5
    # Reference a specific version
    - uses: actions/checkout@v5.2.0
    # Reference a branch
    - uses: actions/checkout@main
    # References a subdirectory in a public GitHub repository at a specific branch, ref, or SHA
    - uses: actions/aws/ec2@main
    # References a local action
    - uses: ./.github/actions/my-action
    # References a docker public registry action
    - uses: docker://gcr.io/cloud-builders/gradle
    # Reference a docker image published on docker hub
    - uses: docker://alpine:3.8

`runs.steps[*].with`

          **Facultatif** Une `map` des paramètres d’entrée définis par l’action. Chaque paramètre d’entrée est une paire clé-valeur. Pour plus d’informations, consultez « [Exemple : Spécification d’entrées](#example-specifying-inputs) ».

runs:
  using: "composite"
  steps:
    - name: My first step
      uses: actions/hello_world@main
      with:
        first_name: Mona
        middle_name: The
        last_name: Octocat

`runs.steps[*].continue-on-error`

          **Facultatif**  Empêche l’action d’échouer lorsqu’une étape échoue. Définissez la valeur `true` pour permettre à l’action de réussir en cas d’échec de cette étape.

          `runs` pour les actions de conteneur Docker

          **Obligatoire** Configure l’image utilisée pour l’action de conteneur Docker.

Exemple : utilisation d’un fichier Dockerfile dans votre dépôt

runs:
  using: 'docker'
  image: 'Dockerfile'

Exemple : Utilisation d’un conteneur de registre Docker public

runs:
  using: 'docker'
  image: 'docker://debian:stretch-slim'

          `runs.using` pour les actions de conteneur Docker

          **Obligatoire** Vous devez définir cette valeur sur `'docker'`.

`runs.pre-entrypoint`

          **Facultatif** Permet d’exécuter un script avant le début de l’action `entrypoint`. Par exemple, vous pouvez utiliser `pre-entrypoint:` pour exécuter un script de configuration prérequis. GitHub Actions utilise `docker run` pour lancer cette action et exécute le script à l’intérieur d’un nouveau conteneur qui utilise la même image de base. Cela signifie que l’état du runtime est différent de celui du conteneur principal `entrypoint`, et que tous les états dont vous avez besoin doivent être accessibles dans l’espace de travail `HOME` ou sous forme de variable `STATE_`. L’action `pre-entrypoint:` s’exécute toujours par défaut, mais vous pouvez modifier cela en utilisant [`runs.pre-if`](#runspre-if).

Le runtime spécifié avec la syntaxe using exécute ce fichier.

Dans cet exemple, l’action pre-entrypoint: exécute un script appelé setup.sh :

runs:
  using: 'docker'
  image: 'Dockerfile'
  args:
    - 'bzz'
  pre-entrypoint: 'setup.sh'
  entrypoint: 'main.sh'

`runs.image`

          **Obligatoire** Image Docker à utiliser comme conteneur pour exécuter l’action. La valeur peut être le nom de l’image de base Docker, un `Dockerfile` local dans votre dépôt ou une image publique dans Docker Hub ou un autre registre. Pour référencer un `Dockerfile` local vers votre dépôt, le fichier doit être nommé `Dockerfile`. En outre, vous devez utiliser un chemin relatif à votre fichier de métadonnées d’action. L’application `docker` exécute ce fichier.

`runs.env`

          **Facultatif** Spécifie un mappage clé/valeur des variables d’environnement à définir dans l’environnement de conteneur.

`runs.entrypoint`

          **Facultatif** Remplace le `ENTRYPOINT` Docker dans le `Dockerfile`, ou définit celui-ci s’il n’a pas déjà été spécifié. Utilisez `entrypoint` si `Dockerfile` ne spécifie pas de `ENTRYPOINT` ou si vous souhaitez remplacer l’instruction `ENTRYPOINT`. Si vous omettez `entrypoint`, les commandes que vous spécifiez dans l’instruction Docker `ENTRYPOINT` s’exécuteront. L’instruction Docker `ENTRYPOINT` peut avoir un format _shell_ ou un format _exec_. La documentation Docker `ENTRYPOINT` recommande d’utiliser le format _exec_ de l’instruction `ENTRYPOINT`.

Pour plus d’informations sur la façon dont s’exécute entrypoint, consultez « Prise en charge de Dockerfile pour GitHub Actions ».

`runs.post-entrypoint`

          **Facultatif** Permet d’exécuter un script de nettoyage une fois l’action `runs.entrypoint` terminée. GitHub Actions utilise `docker run` pour lancer cette action. Étant donné que GitHub Actions exécute le script à l’intérieur d’un nouveau conteneur à l’aide de la même image de base, l’état d’exécution est différent de celui du conteneur principal `entrypoint`. Vous pouvez accéder à n’importe quel état dont vous avez besoin dans l’espace de travail `HOME` ou en tant que variable `STATE_`. L’action `post-entrypoint:` s’exécute toujours par défaut, mais vous pouvez modifier cela en utilisant [`runs.post-if`](#runspost-if).

runs:
  using: 'docker'
  image: 'Dockerfile'
  args:
    - 'bzz'
  entrypoint: 'main.sh'
  post-entrypoint: 'cleanup.sh'

`runs.args`

          **Facultatif** Tableau de chaînes qui définissent les entrées d’un conteneur Docker. Les entrées peuvent inclure des chaînes codées en dur. GitHub passe `args` au `ENTRYPOINT` du conteneur quand celui-ci démarre.

Les args sont utilisés à 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 :

Documentez les arguments requis dans le fichier README de l’action et omettez-les de l’instruction CMD.
Utilisez les valeurs par défaut qui autorisent l’utilisation de l’action sans spécifier aucune valeur args.
Si l’action expose un indicateur --help, ou quelque chose de similaire, utilisez-le pour rendre votre action auto-documentée.

Si vous devez passer des variables d’environnement à une action, vérifiez que votre action exécute un interpréteur de commandes pour effectuer une substitution de variable. Par exemple, si votre attribut entrypoint est défini sur "sh -c", args sera exécuté dans un interpréteur de commandes. Sinon, si Dockerfile utilise un ENTRYPOINT pour exécuter la même commande ("sh -c"), args s’exécutera dans un interpréteur de commandes.

Pour plus d’informations sur l’utilisation de l’instruction CMD avec GitHub Actions, consultez « Prise en charge de Dockerfile pour GitHub Actions ».

Exemple : Définition d’arguments pour le conteneur Docker

runs:
  using: 'docker'
  image: 'Dockerfile'
  args:
    - ${{ inputs.greeting }}
    - 'foo'
    - 'bar'

`branding`

          **Facultatif** Vous pouvez utiliser une couleur ainsi qu’une icône [Feather](https://feathericons.com/) pour créer un badge permettant de personnaliser et de distinguer votre action. Les badges s’affichent en regard du nom de l’action dans [GitHub Marketplace](https://github.com/marketplace?type=actions).

Exemple : Configuration de l'image de marque pour une action

branding:
  icon: 'award'
  color: 'green'

café
colonnes
divide-circle
divide-square
divide
grimace
hexagon
clé
meh
pointeur de souris
sourire
outil
x-octagon

Liste exhaustive de toutes les icônes actuellement prises en charge

activité
airplay
alert-circle
alert-octagon
triangle d'alerte
align-center
align-justify
align-left
align-right
ancre
ouverture
archive
cercle-flèche-vers-le-bas
flèche-bas-gauche
flèche-bas-droite
flèche vers le bas
flèche-gauche-cercle
flèche gauche
flèche-droite-cercle
flèche droite
arrow-up-circle
arrow-up-left
arrow-up-right
arrow-up
at-sign
prix
bar-chart-2
diagramme en barres
chargement de la batterie
battery
désactivation de la sonnerie
clochette
bluetooth
gras
book-open
livre
signet
boîte
porte-documents
calendrier
caméra éteinte
caméra
Caster
cercle de validation
check-square
vérifier
chevron-down
chevron gauche
chevron-right
chevron-up
chevrons-down
chevrons-left
chevrons-right
chevrons-up
cercle
presse-papiers
horloge
cloud-drizzle
cloud-lightning
cloud-off
nuage-pluie
nuage-neige
cloud
code
commande
boussole
copy
corner-down-left
corner-down-right
corner-left-down
corner-left-up
corner-right-down
corner-right-up
corner-up-left
corner-up-right
cpu
carte de crédit
crop
crosshair
base de données
supprimer
disque
dollar-sign
download-cloud
télécharger
gouttelette
edit-2
edit-3
modifier
lien externe
eye-off
œil
avance rapide
feather
file-minus
file-plus
fichier texte
fichier
film
filtre
indicateur
folder-minus
folder-plus
dossier
cadeau
git-branch
git-commit
git-merge
git pull request
globe
grid
disque dur
hash
casque audio
cœur
help-circle
accueil
image
boîte de réception
info
italique
couches
mise en page
bouée de sauvetage
link-2
lien
liste
chargeur
verrou
log-in
déconnexion
courriel
map-pin
carte
maximize-2
maximize
menu
cercle de message
message-square
micro désactivé
mic
minimize-2
minimiser
minus-circle
minus-square
moins
écran
lune
more-horizontal
more-vertical
déplacer
musique
navigation-2
navigation
octogone
paquet
paperclip
cercle de pause
pause
pour cent
appel téléphonique
phone-forwarded
appel-entrant
appel manqué
téléphone éteint
phone-outgoing
téléphone
pie-chart
play-circle
jouer
plus-cercle
plus-square
plus
pocket
puissance
imprimante
radio
refresh-ccw
refresh-cw
répéter
rewind
rotate-ccw
rotate-cw
rss
enregistrer
ciseaux
recherche
Envoyer
serveur
paramètres
share-2
partager
désactivation du bouclier
bouclier
sac de courses
panier d'achat
lecture aléatoire
barre latérale
skip-back
skip-forward
slash
contrôles Slider
téléphone intelligent
haut-parleur
carré
étoile
cercle d'arrêt
soleil
lever du soleil
coucher de soleil
tableau
tablette
balise
target
terminal
thermomètre
pouce vers le bas
pouce levé
toggle-left
toggle-right
trash-2
trash
tendance à la baisse
en tendance à la hausse
triangle
camion
télé
type
parapluie
souligné
déverrouiller
téléverser sur le cloud
télécharger
vérification utilisateur
user-minus
utilisateur-plus
user-x
utilisateur
utilisateurs
vidéo désactivée
vidéo
messagerie vocale
volume-1
volume-2
volume-x
volume
watch
Wi-Fi désactivé
wifi
wind
x-circle
x-square
x
zap-off
zap
zoom avant
dézoomer

Dans cet article