> For the complete documentation index, see [llms.txt](https://docs.verge.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.verge.io/learn-the-platform/fr/module-8-developpeur-et-devops/06-task-engine.md).

# Moteur de tâches et webhooks

Le VergeOS **Moteur de tâches** est un framework d'automatisation intégré qui permet des opérations pilotées par les événements et par la planification sans outil externe. Plutôt que d'écrire des scripts ou de s'appuyer sur des tâches cron sur des machines séparées, les administrateurs définissent des tâches, y associent des déclencheurs et laissent la plateforme exécuter les actions automatiquement. Le moteur de tâches est le complément natif des outils API et IaC abordés plus tôt dans ce module — là où Terraform et Ansible gèrent le provisioning, le moteur de tâches prend en charge l'automatisation opérationnelle quotidienne au sein du système en cours d'exécution.

## Composants du moteur de tâches

Le moteur de tâches utilise six blocs de construction modulaires qui peuvent être combinés de manière flexible :

| Composant               | Description                                                                                                                |
| ----------------------- | -------------------------------------------------------------------------------------------------------------------------- |
| **Tâches**              | Définir l'action à exécuter (par ex. éteindre une VM, envoyer une notification)                                            |
| **Planifications**      | Préciser quand et à quelle fréquence une tâche doit s'exécuter (par ex. quotidiennement, hebdomadairement, une seule fois) |
| **Événements**          | Définir les conditions qui déclenchent une tâche (par ex. connexion utilisateur, échec de synchronisation)                 |
| **Webhooks**            | Envoyer des données aux systèmes externes via HTTP POST en temps réel                                                      |
| **Scripts**             | Blocs d'automatisation programmables exposés dans le tableau de bord des tâches (voir la section Scripts ci-dessous)       |
| **Journaux des tâches** | Enregistrer l'historique de création et d'exécution des tâches à des fins d'audit et de dépannage                          |

Tous les composants sont accessibles depuis **Système → Tableau de bord des tâches** dans l'interface VergeOS.

```mermaid
flowchart LR
    sous-graphe Déclencheurs
        E[Déclencheur d'événement<br/>connexion utilisateur, erreur de synchronisation]
        S[Déclencheur de planification<br/>quotidien, hebdomadaire, ponctuel]
    end

    sous-graphe Actions
        T1[Tâche : Démarrer la VM]
        T2[Tâche : Envoyer un e-mail]
        T3[Tâche : Envoyer un webhook]
    end

    sous-graphe Externe
        SL[Canal Slack]
        EM[E-mail / SMTP]
        ZP[Zapier / supervision]
    end

    E --> T1
    E --> T2
    E --> T3
    S --> T1
    S --> T2
    T3 --> SL
    T3 --> ZP
    T2 --> EM
```

## Architecture d'automatisation modulaire

Un point fort clé du moteur de tâches est son modèle de relations plusieurs-à-plusieurs. **plusieurs-à-plusieurs** Les composants ne sont pas verrouillés dans des appariements un-à-un :

* **Plusieurs tâches ou événements → un seul webhook** — Configurez un webhook une seule fois et déclenchez-le depuis plusieurs événements différents (échecs de synchronisation, tentatives de connexion, alertes système). Cela centralise les intégrations externes et réduit les doublons.
* **Une seule tâche → plusieurs événements** — Une tâche « Démarrer la VM » peut se déclencher lorsqu'un utilisateur spécifique se connecte *ou* lorsqu'une fenêtre de maintenance planifiée commence. Réutilisez les définitions de tâches dans différents scénarios.
* **Une seule planification → plusieurs tâches** — Définissez une fenêtre de maintenance hebdomadaire une seule fois et associez-la aux tâches de mise à jour, d'alerte et d'arrêt. Cohérence sans dérive de configuration.

Cette conception composable signifie que vous constituez une bibliothèque de tâches, de planifications et de webhooks réutilisables, puis que vous les reliez au fur et à mesure de l'évolution de vos besoins opérationnels.

## Déclencheurs basés sur les événements

Les déclencheurs d'événement lancent automatiquement des tâches lorsqu'un événement système spécifique est détecté. Lors de la création d'un événement, vous sélectionnez :

1. **Type** — La classe d'objet (par ex. Utilisateurs, Machines virtuelles, Alarmes, Locataires, Synchronisations sortantes)
2. **Événement** — L'occurrence spécifique (par ex. Connexion, Déconnexion, Démarrage, Erreur, Changement d'état)
3. **Instance d'objet ou balise** — Soit un objet spécifique (un utilisateur ou une VM particulier), soit une balise correspondant à un groupe d'objets

### Modèles courants de déclenchement d'événements

| Type d'événement           | Exemple d'événement           | Action typique                                                |
| -------------------------- | ----------------------------- | ------------------------------------------------------------- |
| Utilisateurs               | Connexion / Déconnexion       | Allumer/éteindre les VM GPU pour l'utilisateur connecté       |
| Synchronisations sortantes | Erreur                        | Envoyer une notification Slack + une alerte par e-mail        |
| Machines virtuelles        | Démarrage / Arrêt             | Consigner dans un système de supervision externe via webhook  |
| Alarmes                    | Niveau de gravité de l'erreur | Envoyer une notification par e-mail à l'équipe d'exploitation |
| Alarmes                    | Déclenchée                    | Envoyer un webhook à PagerDuty ou à la rotation d'astreinte   |

{% hint style="success" %}
**Déclencheurs basés sur les balises**

Au lieu de créer des événements séparés pour chaque VM, attribuez une **balise** (par ex. `gpu-workstation`) aux VM concernées. Configurez ensuite le déclencheur d'événement pour correspondre à cette balise — toute VM portant cette balise activera le déclencheur. C'est bien plus facile à maintenir que des événements par objet.
{% endhint %}

## Déclencheurs basés sur les planifications

Les déclencheurs de planification exécutent les tâches à des moments ou à des intervalles prédéfinis. VergeOS inclut plusieurs planifications par défaut et prend en charge la création de planifications personnalisées.

### Options de configuration des planifications

* **Récurrent** — Répéter tous les N jours, heures, minutes, semaines, mois ou années, avec sélection d'un jour et d'une heure précis
* **Ponctuel** — Sélectionnez « Ne se répète pas » et spécifiez une seule date et heure de début
* **Date de fin** — Les planifications récurrentes sont perpétuelles par défaut ; vous pouvez éventuellement définir une date de fin

### Modèles courants de planification

| Planification             | Cas d'utilisation                                                          |
| ------------------------- | -------------------------------------------------------------------------- |
| Tous les samedis à 17 h   | Vérifier et télécharger les mises à jour du système                        |
| Tous les vendredis à 18 h | Éteindre les VM gourmandes en ressources à la fin de la journée de travail |
| Date future spécifique    | Désactiver un compte d'employé temporaire 30 jours après sa création       |
| Tous les jours à minuit   | Exécuter les vérifications de validation des sauvegardes du locataire      |
| Premier de chaque mois    | Générer des rapports d'utilisation des ressources                          |

## Webhooks

Les webhooks permettent l'envoi de messages en mode push vers des systèmes externes lors de l'exécution des tâches. Au lieu que des systèmes externes interrogent VergeOS pour obtenir l'état, la plateforme envoie de manière proactive des requêtes HTTP POST vers des URL prédéfinies lorsque les conditions configurées sont remplies.

### Configuration du webhook

Lors de la création d'un webhook, vous configurez :

| Champ                                       | Description                                                                       |
| ------------------------------------------- | --------------------------------------------------------------------------------- |
| **Nom**                                     | Identifiant descriptif du webhook                                                 |
| **URL**                                     | Le point de terminaison API du système externe qui accepte les requêtes HTTP POST |
| **Type d'autorisation**                     | Jeton Bearer, clé API, Basic (nom d'utilisateur/mot de passe) ou aucun            |
| **En-têtes**                                | En-têtes HTTP personnalisés (par défaut : `content-type: application/json`)       |
| **Autoriser les certificats non sécurisés** | Pour les certificats auto-signés dans les environnements de développement/test    |
| **Délai d'attente**                         | Nombre maximal de secondes d'attente d'une réponse (minimum 3)                    |
| **Tentatives**                              | Nombre de nouvelles tentatives en cas d'échec ou d'absence de réponse             |

### Variables de charge utile

Les charges utiles des tâches webhook prennent en charge des variables dynamiques résolues au moment de l'exécution :

| Variable       | Valeur                                                                                   |
| -------------- | ---------------------------------------------------------------------------------------- |
| `${DATE}`      | Date/heure actuelle au format chaîne complète (par ex.  `Thu, 16 Oct 2025 11:38:07 EDT`) |
| `${TIMESTAMP}` | Date/heure actuelle sous forme d'entier epoch (par ex.  `1760629087`)                    |
| `${RANDOM}`    | Entier généré aléatoirement                                                              |
| `${NAME}`      | Nom de l'objet VergeOS applicable                                                        |

### Cas d'utilisation des webhooks

* Envoyer une **notification Slack** à un canal d'administration lorsqu'une tâche de synchronisation produit une erreur
* Publier dans un **système comptable** lorsqu'un locataire se met en ligne, déclenchant une facturation automatique
* Déclencher un **workflow Zapier** lorsqu'une VM spécifique démarre, en initiant des actions interapplications

## Exemple pratique 1 : Démarrage/arrêt automatique des VM GPU

Cet exemple montre comment les balises, les tâches, les événements et les planifications fonctionnent ensemble pour gérer des charges de travail GPU gourmandes en ressources.

**Scénario :** L'utilisateur JThompson utilise plusieurs VM équipées de GPU pour la modélisation 3D. Ces VM consomment beaucoup de calcul et de mémoire — les laisser en fonctionnement lorsqu'elles sont inactives est du gaspillage.

**Objectif :** Démarrer les VM lorsque JThompson se connecte, les éteindre à la déconnexion et imposer un arrêt le vendredi à 18 h comme filet de sécurité.

### Étapes de configuration

1. **Créer une balise** — Dans Système → Balises, créez une catégorie `VM` avec la balise `JThompson-GPU`. Attribuez cette balise aux VM cibles.
2. **Créer la tâche « Démarrer »** — Système → Tableau de bord des tâches → Nouvelle tâche. Définissez le type d'objet sur `Machines virtuelles`, sélectionnez la balise `JThompson-GPU`, et définissez l'action sur `Démarrer`.
3. **Ajouter un déclencheur d'événement de connexion** — Depuis le tableau de bord des tâches, ajoutez un déclencheur d'événement : Type = `Utilisateurs`, Événement = `Connexion`, Objet = `JThompson`.
4. **Créer la tâche « Arrêter »** — Nouvelle tâche avec la même sélection de balise, mais Action = `Arrêter`.
5. **Ajouter un déclencheur d'événement de déconnexion** — Déclencheur d'événement sur la tâche d'arrêt : Type = `Utilisateurs`, Événement = `Déconnexion`, Objet = `JThompson`.
6. **Créer la planification du vendredi** — Nouvelle planification : répéter chaque semaine le vendredi à 18 h 00.
7. **Ajouter un déclencheur de planification** — Associez la planification du vendredi à la tâche « Arrêter » en tant que déclencheur de planification.

**Résultat :** Les VM démarrent automatiquement lorsque JThompson se connecte, s'arrêtent à la déconnexion et sont garanties de s'éteindre chaque vendredi à 18 h, quel que soit l'état de connexion. Ce modèle s'applique à toute charge de travail gourmande en ressources — plateformes d'entraînement ML, stations de rendu CAO, environnements de tests d'intégration ou clusters de modélisation financière.

## Exemple pratique 2 : Alerte Slack + e-mail en cas d'erreur de synchronisation

Cet exemple montre comment les webhooks, les tâches et les événements se combinent pour fournir des alertes multicanal pour les opérations de reprise après sinistre / continuité d'activité.

**Scénario :** Un fournisseur de services a besoin d'une notification immédiate lorsque les tâches de synchronisation nocturnes rencontrent des erreurs, à la fois via Slack et par e-mail.

### Étapes de configuration

1. **Créer un webhook** — Système → Tableau de bord des tâches → Nouveau webhook. Configurez l'URL du webhook entrant Slack et définissez le type d'autorisation sur `Jeton Bearer` avec le jeton du bot Slack, puis définissez content-type sur `application/json`.
2. **Créer la tâche e-mail** — Nouvelle tâche : Type d'objet = `E-mail`, configurez l'adresse du destinataire et le corps du message d'alerte.
3. **Créer la tâche webhook** — Nouvelle tâche : Type d'objet = `Webhook`, sélectionnez le webhook Slack, Action = `Envoyer`. Définissez la charge utile JSON :

   ```json
   {
     "text": "Alerte d'erreur de synchronisation : ${NAME} a échoué à ${DATE}"
   }
   ```
4. **Ajouter un déclencheur d'événement à la tâche webhook** — Type = `Synchronisations sortantes`, Événement = `Erreur`, sélectionnez la tâche de synchronisation spécifique (ou utilisez une balise pour plusieurs synchronisations).
5. **Ajouter le même déclencheur d'événement à la tâche e-mail** — Même configuration qu'à l'étape 4, en la reliant à la tâche e-mail.

**Résultat :** Lorsqu'une tâche de synchronisation surveillée produit une erreur, le canal Slack et la boîte de réception e-mail reçoivent des alertes simultanément. Les administrateurs peuvent enquêter rapidement, ce qui maximise les chances d'achever la synchronisation dans la fenêtre disponible.

{% hint style="success" %}
**Passer à l'échelle avec des balises**

Si vous voulez que le même déclencheur s'applique à toutes les synchronisations sortantes, attribuez une balise partagée (par ex.  `critical-sync`) à ces tâches de synchronisation. Configurez le déclencheur pour qu'il s'active sur toute synchronisation portant cette balise — pas besoin de créer un déclencheur individuel par synchronisation.
{% endhint %}

## Création de tâches : référence rapide

Chaque tâche suit le même modèle de création :

1. Accédez à **Système → Tableau de bord des tâches → Nouvelle tâche**
2. Configurer : **Nom**, **Type d'objet**, **Objet** (instance spécifique ou balise), **Action**, **Paramètres**
3. Associer un ou plusieurs **déclencheurs d'événement** et/ou **déclencheurs de planification**
4. Vérifiez dans **Journaux des tâches** que la tâche se déclenche correctement

Les tâches ont un **Activé** indicateur ; vous pouvez désactiver temporairement une tâche si vous devez vérifier la configuration avant de l'activer, puis la réactiver lorsqu'elle est prête.

### Champs de tâche

**Nom** — Identifiant descriptif **Type d'objet** — Section de l'application (VM, réseaux, utilisateurs, webhooks, etc.) **Objet** — Cible spécifique ou balise **Action** — Opération à effectuer **Supprimer après exécution** — Option d'exécution unique

### Journaux des tâches

Chaque exécution de tâche est enregistrée avec : - Horodatage et durée - État de réussite/échec - Événement ou planification déclencheur - Détails de l'objet cible Les journaux sont accessibles depuis le tableau de bord des tâches à des fins d'audit.

## Scripts (aperçu)

Le **Scripts** La fonctionnalité, introduite dans VergeOS 26, pose les bases des futurs workflows d'automatisation définis par l'administrateur. Bien qu'elle soit actuellement réservée aux opérations internes du système, elle a été conçue dans une optique d'extensibilité. Les futures versions étendront Scripts pour prendre en charge l'automatisation personnalisée des administrateurs directement dans la plateforme — en complétant le moteur de tâches existant par une logique programmable.

{% hint style="info" %}
**Vous venez de VMware ou de Nutanix ?**

Le moteur de tâches est intégré à VergeOS à tous les niveaux (y compris à l'intérieur des locataires) — aucun appareil d'orchestration séparé, aucune licence d'automatisation supplémentaire. Configurez les déclencheurs d'événements, les planifications et les webhooks depuis la même interface que celle que vous utilisez déjà pour les VM et le stockage.
{% endhint %}

## Points clés

### Piloté par les événements

Déclenchez l'automatisation à partir d'événements système — connexion/déconnexion utilisateur, erreurs de synchronisation, changements d'état des VM, conditions d'alarme — sans interrogation périodique ni planificateurs externes.

### Piloté par la planification

Exécutez des tâches à des moments précis à l'aide de planifications intégrées ou personnalisées. Ponctuelles ou récurrentes, avec dates de fin facultatives.

### Intégration externe

Envoyez des notifications vers Slack, e-mail, Zapier ou n'importe quel point de terminaison HTTP via des webhooks avec authentification, en-têtes et logique de nouvelle tentative configurables.

### Modulaire et réutilisable

Relations plusieurs-à-plusieurs entre les tâches, les événements, les planifications et les webhooks. Construisez une fois, composez librement.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.verge.io/learn-the-platform/fr/module-8-developpeur-et-devops/06-task-engine.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.