Comment exécuter des tâches en arrière-plan avec Celery ?

Question

Accepted Answer

**Celery** est l'outil standard pour exécuter des **tâches en arrière-plan et planifiées** dans Django — du travail qui ne devrait pas bloquer la requête HTTP (envoi d'e-mails, traitement de fichiers, appels à des API lentes) ou qui s'exécute selon un calendrier. Les tâches sont mises en file d'attente et traitées de manière asynchrone par des processus **worker** distincts.

## Le problème que Celery résout

```python
# ❌ doing slow work inline blocks the response — the user waits, risks timeouts
def register(request):
    user = create_user(request.POST)
    send_welcome_email(user)           # slow — the user waits for the email to send
    generate_report(user)               # even slower
    return redirect("home")             # finally responds after all that
```

Effectuer du travail lent en ligne force les utilisateurs à attendre et risque des dépassements de délai de requête. Celery le délègue aux workers en arrière-plan afin que la requête soit renvoyée immédiatement.

## Définir et appeler une tâche Celery

```python
# tasks.py — define a task
from celery import shared_task

@shared_task
def send_welcome_email(user_id):
    user = User.objects.get(id=user_id)
    send_email(user.email, "Welcome!")    # runs in a WORKER, not the web process

# in a view — QUEUE the task instead of running it inline
def register(request):
    user = create_user(request.POST)
    send_welcome_email.delay(user.id)     # .delay() queues it → returns IMMEDIATELY
    return redirect("home")                # user gets a fast response
```

Le décorateur `@shared_task` définit une tâche ; `.delay()` (ou `.apply_async()`) la met en file d'attente pour qu'un worker la traite de manière asynchrone — la vue n'attend pas.

## L'architecture

```text
Django (web) --.delay()--> BROKER (Redis/RabbitMQ) --> CELERY WORKER (processes the task)
                              (the message queue)         (separate process/machine)
```

```text
Components:
  ✓ Broker (Redis or RabbitMQ) — holds the queue of pending tasks
  ✓ Celery worker(s) — separate processes that pull and execute tasks
  ✓ Result backend (optional) — stores task results/status
Run workers separately: `celery -A myproject worker`
```

## Tâches planifiées / périodiques (Celery Beat)

```python
# run tasks on a schedule (like cron) via Celery Beat
CELERY_BEAT_SCHEDULE = {
    "daily-report": {
        "task": "myapp.tasks.generate_daily_report",
        "schedule": crontab(hour=0, minute=0),     # every midnight
    },
}
```

## Fonctionnalités de fiabilité

```python
@shared_task(bind=True, max_retries=3, default_retry_delay=60)
def sync_data(self):
    try:
        do_sync()
    except Exception as exc:
        raise self.retry(exc=exc)             # automatic retries on failure
```

```text
✓ Retries with backoff (resilience against transient failures)
✓ Task persistence (queued tasks survive restarts via the broker)
✓ Scheduling (Celery Beat — periodic/cron-like tasks)
✓ Rate limiting, concurrency control, task routing/priorities
✓ Workers scale independently of web servers
```

## Pourquoi c'est important

Le traitement des tâches en arrière-plan avec Celery est une connaissance essentielle pour construire des applications Django réactives et scalables, car de nombreux besoins du monde réel nécessitent un travail qui ne devrait pas se faire en ligne pendant une requête.

Comprendre cela est important car le problème fondamental — déléguer le travail lent ou différé (envoi d'e-mails, traitement d'images/fichiers, génération de rapports, appels à des API externes lentes, synchronisation de données) hors du cycle requête-réponse — est omniprésent dans les applications en production.

Effectuer un tel travail en ligne force les utilisateurs à attendre, risque des dépassements de délai de requête et perd le travail s'il échoue, tandis que **Celery** vous permet de répondre à l'utilisateur immédiatement tandis que des **workers** distincts traitent le travail de manière asynchrone et fiable.

Au-delà de la simple délégation asynchrone, Celery fournit des capacités critiques en production : **tâches planifiées/périodiques** (via Celery Beat, remplaçant cron pour la planification au niveau applicatif — rapports quotidiens, tâches de nettoyage, synchronisations récurrentes), **tentatives automatiques avec backoff** (résilience contre les défaillances temporaires), **persistance des tâches** (les tâches en file d'attente survivent aux redémarrages via le broker, le travail n'est pas perdu), et **scalabilité indépendante** des workers par rapport aux serveurs web.

Comprendre l'architecture de Celery (le broker comme Redis/RabbitMQ tenant la file d'attente, les workers traitant les tâches, le backend de résultats), comment définir et mettre en file d'attente les tâches (`@shared_task`, `.delay()`), planifier du travail périodique et configurer les fonctionnalités de fiabilité est une connaissance précieuse au niveau senior pour construire des systèmes Django en production qui gèrent le travail lourd ou différé avec élégance.

Parce que le traitement en arrière-plan est une exigence courante et importante pour des applications réactives et robustes — et Celery est la solution de facto standard dans l'écosystème Django — maîtriser cela est une compétence pratique et fréquemment pertinente qui reflète la capacité à concevoir des applications Django du monde réel au-delà du simple traitement synchrone des requêtes.