# Pourquoi mon e-mail reste-t-il en Accepted ou Scheduled ?

> Les e-mails acceptés partent normalement en quelques secondes, et les e-mails programmés à leur heure d’envoi. Découvrez ce qui les retarde et quand les annuler, les reprogrammer ou les renvoyer.

Cet article vous aide quand un e-mail reste en **Accepted** ou **Scheduled** plus longtemps que prévu. Ces deux statuts signifient qu’Emailit a reçu l’e-mail et n’a pas encore terminé de tentative de livraison.

## Symptômes

- Un e-mail affiche **Accepted** (« Accepted for delivery ») pendant de longues minutes.
- Un e-mail programmé affiche encore **Scheduled** après l’heure à laquelle vous attendiez son envoi.
- L’onglet **Deliveries** de la page de l’e-mail est vide, ou affiche une entrée d’erreur interne.

## Cause

Les e-mails **Accepted** sont en file d’attente et partent normalement en quelques secondes. Ils y restent plus longtemps dans les cas suivants :

- **Une tentative de livraison a rencontré une erreur interne.** L’onglet **Deliveries** affiche `An internal error occurred while sending this email. This message will be retried automatically.` L’e-mail conserve son statut et fait l’objet de nouvelles tentatives à intervalles croissants.
- **Emailit traite un arriéré ou un incident.** Consultez [status.emailit.com](https://status.emailit.com).

Notez qu’un refus temporaire du serveur du destinataire apparaît comme **Attempted**, et non comme **Accepted**. Consultez [Que signifie le statut Attempted ?](/fr/docs/kb/email-status-attempted/).

Les e-mails **Scheduled** attendent l’heure indiquée dans `scheduled_at`, puis partent en quelques secondes. Ils passent directement de **Scheduled** à **Delivered**, ou à un autre statut définitif, sans passer par **Accepted**. Un e-mail programmé qui semble en retard est généralement :

- **Programmé à une autre heure que celle que vous vouliez.** Une heure sans décalage, ou une expression comme « tomorrow at 9am », peut être interprétée dans un autre fuseau horaire que le vôtre.
- **Retardé par les mêmes erreurs internes que ci-dessus.**

## Solution

1. **Vérifiez les heures de l’e-mail.** Ouvrez-le dans **Email API → Emails**. Le résumé indique quand il a été créé et, pour les e-mails programmés, l’heure pour laquelle il est programmé. Pour comparer, basculez entre UTC et l’heure locale dans le menu utilisateur, sous **Timezone**.

2. **Lisez l’onglet Deliveries.** S’il affiche une erreur interne, Emailit réessaie de lui-même. Inutile de renvoyer l’e-mail : vous créeriez un doublon.

3. **Indiquez explicitement le fuseau horaire.** Envoyez `scheduled_at` au format ISO 8601 avec un décalage, comme `2026-10-02T09:00:00+02:00`, ou sous forme d’horodatage Unix. La réponse de l’API renvoie la valeur `scheduled_at` interprétée : enregistrez-la dans vos logs et comparez. Consultez [Programmation](/fr/docs/email-api/scheduling/).

4. **Reprogrammez ou annulez si nécessaire.** Appelez [Mettre à jour un e-mail programmé](/fr/docs/api-reference/emails/update/) avec un nouveau `scheduled_at`, ou sélectionnez **Cancel delivery** sur la page de l’e-mail. Ces deux actions ne fonctionnent que jusqu’à 3 minutes avant l’heure programmée, et la nouvelle heure doit se situer au moins 3 minutes dans le futur.

5. **Vérifiez s’il y a un incident.** Si de nombreux e-mails sont en attente en même temps, consultez [status.emailit.com](https://status.emailit.com) avant de renvoyer quoi que ce soit.

Pour suivre les e-mails en temps réel, abonnez un [webhook](/fr/docs/webhooks/) à `email.delivered`, `email.attempted` et `email.bounced`. Pour tous les statuts, consultez [Statuts des e-mails](/fr/docs/logs/email-statuses/).

## Le problème persiste ?

Si un e-mail reste **Accepted** plus d’une heure sans qu’aucun incident ne soit signalé, [contactez le support](/contact/) ou posez votre question sur [Discord](https://discord.emailit.com) en indiquant l’ID de l’e-mail (`em_…`).

---
Source: https://emailit.com/fr/docs/kb/email-stuck-in-scheduled-or-accepted/