# Workers

Source : https://webgune.cloud/fr-fr/docs/workers · Mis à jour le 2026-10-27

# Workers

Un **worker** est un service sans port ni domaine : un process de fond qui consomme une file d'attente, exécute des tâches planifiées ou traite des données en continu.

## Quand choisir un worker

- Consommer une file (BullMQ, RabbitMQ, ou une simple liste [Redis](/docs/db-redis)).
- Tâches récurrentes (envoi d'e-mails, synchronisation, nettoyage).
- Traitement long qui ne doit pas bloquer votre application web (génération de PDF, imports).

## Créer un worker

1. **+ Nouveau service** → type **Worker**.
2. Connectez le dépôt (ou l'image Docker) contenant le code.
3. Définissez si besoin une [commande de démarrage](/docs/commande-demarrage) dédiée. C'est pratique quand le worker vit dans le même dépôt que l'application web :

```bash
node dist/worker.js
```

## Exemple : consommer une file Redis

```typescript
import Redis from "ioredis";

const redis = new Redis(process.env.REDIS_URL!);

while (true) {
  // BRPOP bloque jusqu'à ce qu'un job arrive
  const [, payload] = await redis.brpop("jobs:emails", 0);
  await sendEmail(JSON.parse(payload));
}
```

Le service web pousse les jobs (`LPUSH jobs:emails …`), le worker les dépile : les deux services partagent la même instance Redis du projet, connectée via ses variables d'environnement.

## Bonnes pratiques

- **Un worker = une responsabilité.** Deux files très différentes méritent deux workers : chacun se scale et redémarre indépendamment.
- Gérez l'arrêt proprement : à la réception de `SIGTERM`, terminez le job en cours avant de quitter. Les redéploiements remplacent le process.
- Idempotence : un job peut être retraité après un redémarrage. Assurez-vous qu'un traitement double soit sans effet.

Les logs et métriques (CPU/mémoire) du worker sont disponibles comme pour n'importe quel service dans les onglets **Logs** et **Observabilité**.