Débit d'envoi

Régler combien d'e-mails partent par minute, serveur SMTP par serveur : 60 par minute par défaut, jusqu'à 2 000 pour un relais qui le supporte. Les plafonds de l'heure et du jour du serveur restent des plafonds durs : le débit ne fait que répartir l'envoi à l'intérieur. Disponible à partir de la migration v151.

Pourquoi

Avant la v151, la file partait à environ 50 e-mails par minute au plus, un par un, quel que soit le serveur : une liste de 20 000 contacts mettait près de 7 heures à partir. Tu règles maintenant, pour chaque serveur :

Sans réglage, rien ne devient risqué : 60 par minute et 3 envois simultanés, c'est un peu au-dessus d'avant.

Où le régler

Email Marketing → Serveurs SMTP, ouvre un serveur : la section « Débit » porte les deux réglages. Chaque ligne et le panneau du serveur disent son verdict, calculé par le serveur :

• « 60 e-mails par minute, 3 envois simultanés » ;
• ce qui est parti ces 60 dernières secondes, ce qui attend (les envois dus de ce serveur) ;
• quand la file sera vidée : « La file sera vidée vers 16 h 40 », « File vide », « Bloquée : plafond horaire atteint », « Bloquée : plafond journalier atteint », « Bloquée : serveur désactivé », « Bloquée : mot de passe à corriger », « Ralentie par le fournisseur — baisse le débit » (le fournisseur a refusé un envoi pour débit trop élevé ces 15 dernières minutes), « Ralentie : une erreur du serveur tient, un envoi d’essai par minute », ou « La file ne sera pas vidée aujourd’hui : plafond journalier ». L'estimation compte les pauses du plafond horaire, et prend le débit mesuré (envois des 5 dernières minutes) quand il est plus bas que le réglage — un relais lent n'atteint pas son réglage.

Par l'API : GET /admin/api/email/debit (?fuseau=Africa/Casablanca pour l'heure dans ton fuseau ; sans lui, l'heure est en UTC et la phrase le dit). Par MCP : get_email_queue_throughput pour lire, update_email_smtp_server pour régler (niveau 2 : aperçu, puis confirmation).

Les risques d'un débit élevé

Un débit élevé vide la file plus vite, mais :

• chaque fournisseur a ses limites — par seconde, par minute, par heure. Au-delà, il refuse ou ralentit (« 421 Too many connections », « 454 Throttling »), et ces envois sont retentés plus tard ;
• une rafale abîme la réputation d'un domaine ou d'une IP neufs : les messageries (Gmail, Outlook) se méfient d'un expéditeur qui passe de 0 à 1 000 e-mails en une minute. Monte par paliers ;
• trop d'envois simultanés est la cause la plus fréquente de refus : beaucoup de relais acceptent 2 à 10 connexions par compte.

Ce qui te protège sans rien faire : les plafonds hourly_limit et daily_limit du serveur ne sont jamais dépassés par la file — chaque envoi réserve sa place dans le compteur avant de partir, même avec plusieurs conteneurs ; un serveur qui renvoie une erreur de serveur (identifiant, connexion, relais) s'arrête aussitôt pour le passage en cours, puis n'est sondé qu'une fois par minute ; un fournisseur qui freine (« 454 Throttling », « 421 Try again later », « Too many messages, slow down »…) arrête le serveur pour le passage, l'envoi refusé garde sa tentative et repartira, le débit repart de zéro, et l'écran affiche « Ralentie par le fournisseur — baisse le débit » : c'est le signal pour baisser le réglage.

Les envois transactionnels (reçu de commande, lien de connexion) gardent leur règle : comptés dans les plafonds, jamais retenus par eux — un reçu part toujours, c'est la file qui attend.

Exemples de réglages

Une liste de 20 000 contacts part en environ 33 minutes à 600 par minute, 5 h 30 à 60 par minute — si les plafonds le permettent : avec 500 par heure, il faut 40 heures quel que soit le débit.

Comment le moteur l'applique

• Un passage toutes les 5 s tant qu'il y a du travail. Le tick de 60 s garde toutes ses autres tâches à leur rythme ; seule la file d'envoi repasse toutes les 5 s tant qu'il reste des envois dus et du débit, puis se tait quand la file est vide.
• Un seau à jetons par serveur. Il se remplit à débit / 60 envois par seconde et contient au plus 10 secondes de débit (au moins 1) : sur toute minute glissante, au plus débit + 10 s de débit envois (70 pour 60 par minute), et un serveur au repos ne garde jamais plus de 10 s de débit d'avance — pas de rafale d'une minute après une pause. Un serveur neuf commence seau plein. Sous 12 par minute, le seau (moins de 2 jetons) peut perdre un peu entre deux passages : 7 par minute peuvent devenir 6, jamais 8.
• Le budget d'un passage : les jetons du seau, jamais plus que ce qui reste de l'heure et du jour, et 5 000 envois au plus par passage, partagés en tourniquet entre les serveurs qui ont des envois dus — un serveur sans rien en file ne prend rien, aucun n'est affamé.
• Aucune attente partagée. Le budget est réservé dans une transaction très courte avant les envois, puis corrigé après (les jetons non utilisés sont rendus). Un relais lent n'arrête pas les autres serveurs, ni les autres conteneurs, ni les autres tâches du tick ; un passage dure 20 s au plus.
• En parallèle, jamais deux fois. Les envois d'un serveur partent à plusieurs (au plus ses envois simultanés), les serveurs en même temps. Chaque envoi est pris de façon atomique : deux passages ou deux conteneurs ne l'envoient jamais deux fois. Toutes les règles d'avant sont jugées pour chaque envoi (consentement, suppression, commande annulée, parcours, préférences du contact, contenu dynamique, test A/B), et la file garde son ordre (les séquences et confirmations avant les envois ponctuels, puis l'échéance). Un envoi sauté par une de ces règles ne consomme pas le débit.
• Plusieurs conteneurs : le seau de chaque serveur est partagé en base (email_smtp_debit) : deux conteneurs se partagent ses jetons, ils ne doublent pas son débit. Supprimer un serveur supprime son seau.
• Un redéploiement n'abandonne rien. À l'arrêt du conteneur (SIGTERM), la file ne tente plus rien et laisse finir les envois en vol (20 s au plus). Après un arrêt brutal, le tick reprend les envois restés « en cours d'envoi » depuis plus de 10 minutes : jamais tentés, ils repartent en file sans perdre de tentative ; déjà confiés au serveur SMTP, ils passent en échec « interrompu pendant l'envoi » et ne sont jamais renvoyés (ils sont peut-être partis : mieux vaut un e-mail perdu qu'un doublon).
• Sans la v151 (base pas encore migrée) : la file d'avant, 50 par minute, un par un, et l'écran ne propose pas les réglages.

Voir aussi : SMTP Servers (plafonds, verdict « Peut envoyer ? », erreurs de serveur), Envois ponctuels.