Un site web ne se limite pas aux interactions visibles des utilisateurs. En arrière-plan, de nombreuses opérations doivent s’exécuter de manière autonome : confirmation d’inscription, relance de panier, notification interne, envoi de rapports ou rappels d’échéances. Pour orchestrer ces actions sans intervention manuelle, l’association entre CRON et PHP offre une solution particulièrement efficace. Grâce à une tâche CRON, le serveur peut lancer automatiquement un script selon une planification précise. De son côté, PHP permet de traiter les données, générer des contenus dynamiques, cibler les destinataires et gérer l’envoi des emails. Ensemble, ces outils permettent de mettre en place un système d’emails automatisés fiable, flexible et adapté aux besoins de nombreux projets web.

Le principe d’un envoi d’emails automatique avec CRON et PHP

Une tâche CRON est une instruction planifiée sur un serveur Unix ou Linux. Elle permet d’exécuter une commande à intervalle régulier : toutes les minutes, toutes les heures, chaque jour à minuit, tous les lundis matin ou encore une fois par mois. Dans le cadre de l’envoi d’emails, cette commande appelle généralement un script PHP exécuté en ligne de commande. Le fonctionnement repose sur une logique simple mais efficace : le serveur déclenche le script PHP selon la fréquence définie, celui-ci vérifie les données disponibles (souvent dans une base de données), prépare les messages à envoyer, puis les transmet via un système d’envoi (fonction native ou SMTP). Enfin, il enregistre le résultat pour assurer un suivi fiable.

Ce mécanisme est utilisé dans de nombreux contextes professionnels et permet d’automatiser efficacement des actions répétitives. Parmi les cas d’usage les plus courants, on retrouve :

• envoyer une newsletter programmée ;
• relancer automatiquement des prospects ;
• envoyer un rapport quotidien à une équipe ;
• prévenir un client avant l’expiration d’un abonnement ;
• notifier un administrateur lorsqu’une action nécessite une vérification ;
• envoyer un récapitulatif de commandes sur un site e-commerce.

L’un des avantages majeurs de cette approche est la séparation entre l’action utilisateur et le traitement technique. Lorsqu’un internaute effectue une action (inscription, commande, demande de contact), les informations peuvent être stockées immédiatement, puis traitées plus tard par une tâche CRON. Cela permet de lisser la charge serveur et d’éviter les ralentissements. En pratique, les envois peuvent être regroupés et traités par lots à intervalles réguliers. Cette méthode améliore la performance globale du site, tout en offrant un meilleur contrôle sur le volume d’emails envoyés. Elle contribue également à réduire les risques de blocage par les fournisseurs de messagerie, qui surveillent les envois massifs ou trop rapides. Par ailleurs, cette organisation rend le système plus fiable et plus évolutif. Il devient plus simple d’ajouter de nouvelles règles d’envoi, de modifier les fréquences ou d’intégrer des logiques plus avancées, comme la segmentation des destinataires ou la priorisation des messages.

Configurer une tâche CRON pour exécuter un script PHP d’envoi d’emails

Pour mettre en place ce système, la première étape consiste à créer un script PHP dédié à l’envoi d’emails. Contrairement à un script classique utilisé dans une page web, celui-ci doit être totalement autonome. Il ne dépend ni d’un navigateur, ni d’une interface utilisateur, et doit pouvoir être exécuté directement depuis le terminal. Ce type de script est généralement conçu pour être robuste et silencieux : il traite des données, effectue des actions, puis consigne les résultats dans des fichiers de logs. Il peut être très simple dans un premier temps, puis évoluer vers une architecture plus avancée intégrant une base de données, une file d’attente ou un service SMTP. Voici un exemple simple de fichier nommé send-emails.php :

<?php

$to = 'client@example.com';
$subject = 'Votre rappel automatique';
$message = 'Bonjour, ceci est un email envoyé automatiquement depuis une tâche CRON.';
$headers = 'From: contact@example.com' . "\r\n" .
           'Reply-To: contact@example.com' . "\r\n" .
           'Content-Type: text/plain; charset=UTF-8';

if (mail($to, $subject, $message, $headers)) {
    file_put_contents(__DIR__ . '/email.log', date('Y-m-d H:i:s') . " - Email envoyé\n", FILE_APPEND);
} else {
    file_put_contents(__DIR__ . '/email.log', date('Y-m-d H:i:s') . " - Erreur d’envoi\n", FILE_APPEND);
}

Ce script illustre le principe de base : définir un destinataire, un message, puis utiliser la fonction mail() pour envoyer l’email. Il enregistre ensuite le résultat dans un fichier de log, ce qui permet de vérifier le bon fonctionnement du processus. La fonction native mail() peut convenir pour des tests ou des besoins simples, mais elle montre rapidement ses limites en production. Elle dépend fortement de la configuration du serveur et offre peu de garanties en termes de délivrabilité. Pour des projets plus sérieux, il est recommandé d’utiliser une bibliothèque comme PHPMailer ou Symfony Mailer, couplée à un serveur SMTP authentifié. Avant d’automatiser l’exécution, il est indispensable de tester le script manuellement. Cela permet de vérifier que les chemins sont corrects, que les permissions sont bien définies et que l’envoi fonctionne réellement :

php /home/utilisateur/scripts/send-emails.php

Une fois le test validé, on peut planifier son exécution via CRON. Pour cela, il faut éditer la crontab de l’utilisateur :

crontab -e

On ajoute ensuite une ligne de planification. Par exemple, pour exécuter le script toutes les 10 minutes :

*/10 * * * * /usr/bin/php /home/utilisateur/scripts/send-emails.php >> /home/utilisateur/logs/cron-emails.log 2>&1

Cette configuration indique au serveur de lancer le script PHP toutes les dix minutes. La redirection >> permet d’ajouter les sorties dans un fichier de log, tandis que 2>&1 redirige également les erreurs. Cela garantit une meilleure visibilité sur l’exécution du script, même en cas de problème. Voici quelques exemples de planification selon les besoins :

Dans un contexte réel, le script PHP ne doit pas se limiter à un envoi unique codé en dur. Il est préférable de mettre en place une file d’attente d’emails stockée en base de données. Cela permet de gérer dynamiquement les envois et de mieux contrôler le processus. Une table email_queue peut par exemple contenir les informations suivantes :

• adresse du destinataire ;
• objet de l’email ;
• contenu du message ;
• statut (en attente, envoyé, erreur) ;
• date de création ;
• date d’envoi ;

Le script va alors récupérer les emails en attente, les envoyer progressivement, puis mettre à jour leur statut. Cette méthode permet de gérer les volumes, de relancer les échecs et de conserver un historique complet des envois. Enfin, cette approche rend le système plus flexible. Il devient possible d’ajouter des règles métiers, comme limiter le nombre d’emails par minute, prioriser certains messages ou différer des envois selon des plages horaires spécifiques. La combinaison entre CRON et PHP devient ainsi une véritable brique d’automatisation pour la gestion des communications d’un site web.

Les bonnes pratiques pour fiabiliser l’envoi automatique d’emails

L’envoi automatique d’emails ne doit pas être réduit à une simple ligne CRON exécutant un script PHP. Dès qu’un site envoie des messages à intervalles réguliers, plusieurs enjeux apparaissent : délivrabilité, sécurité, performance, suivi des erreurs, respect du consentement, gestion des doublons et maîtrise de la charge serveur. Une tâche mal configurée peut envoyer plusieurs fois le même message, saturer le serveur, déclencher des filtres antispam ou rester en erreur pendant plusieurs jours sans que personne ne s’en aperçoive. Pour fiabiliser ce type de mécanisme, il faut donc raisonner comme pour n’importe quel traitement serveur sensible. Le script doit être testé, surveillé, documenté et capable de gérer les imprévus. Un envoi automatique fiable repose autant sur la qualité du code PHP que sur la configuration CRON, le choix du serveur d’envoi et la stratégie de suivi.

Utiliser un serveur SMTP fiable plutôt que la fonction mail()

La fonction native mail() de PHP peut être utile pour comprendre le principe ou réaliser un test rapide, mais elle reste limitée pour un usage en production. Elle dépend fortement de la configuration du serveur, ne permet pas toujours une authentification propre et offre peu de retours exploitables en cas d’échec. Pour un système plus fiable, il est préférable d’utiliser un serveur SMTP authentifié avec une bibliothèque PHP dédiée, comme PHPMailer ou Symfony Mailer. Cette approche permet de définir clairement l’expéditeur, l’hôte SMTP, le port, le chiffrement, les identifiants et les paramètres d’envoi. Les erreurs sont aussi plus lisibles, ce qui facilite le diagnostic.

Limiter le volume envoyé à chaque exécution

Un script lancé par CRON ne doit pas forcément traiter tous les emails en attente d’un seul coup. Si une base contient plusieurs milliers de messages, il est souvent préférable d’envoyer les emails par lots. Par exemple, le script peut traiter 100 messages toutes les cinq minutes plutôt que 10 000 emails en une seule exécution. Cette méthode réduit la charge sur le serveur, limite les risques d’expiration du script et permet de mieux respecter les limites imposées par certains fournisseurs d’envoi. Elle facilite aussi la reprise après erreur : si un lot échoue, il est plus simple de relancer uniquement les messages concernés.

SELECT * FROM email_queue 
WHERE status = 'pending' 
ORDER BY created_at ASC 
LIMIT 100;

Ce principe de traitement progressif est particulièrement utile pour les newsletters, les relances commerciales, les rappels automatiques ou les notifications envoyées à de nombreux utilisateurs.

Mettre en place une file d’attente d’emails

Dans une architecture propre, le script CRON ne devrait pas construire tous les emails au hasard à chaque exécution. Il est préférable d’utiliser une file d’attente, souvent représentée par une table en base de données. Chaque email y est enregistré avec son destinataire, son objet, son contenu, son statut et ses dates de traitement.

Grâce à cette organisation, le système devient plus lisible et plus maîtrisable. On peut consulter les messages en attente, identifier ceux qui échouent, relancer certains envois ou exclure les emails trop anciens.

Prévoir des logs exploitables

Chaque exécution CRON doit laisser une trace claire. Les logs permettent de savoir si le script s’est lancé, combien d’emails ont été traités, combien ont été envoyés, quelles erreurs sont apparues et combien de temps le traitement a duré. Sans journalisation, une tâche CRON peut échouer silencieusement pendant plusieurs jours. Un bon fichier de log peut contenir :

• la date et l’heure de début d’exécution ;
• le nombre d’emails récupérés ;
• le nombre d’emails envoyés avec succès ;
• le nombre d’erreurs ;
• les messages retournés par le serveur SMTP ;
• la durée totale du traitement.

*/10 * * * * /usr/bin/php /home/utilisateur/scripts/send-emails.php >> /home/utilisateur/logs/cron-emails.log 2>&1

Il est également conseillé de prévoir une rotation des logs. Un fichier qui grossit indéfiniment peut finir par occuper trop d’espace disque. Sur un serveur Linux, cette rotation peut être gérée avec un outil comme logrotate.

Empêcher les exécutions simultanées

Un risque fréquent avec CRON est le chevauchement d’exécutions. Si une tâche est programmée toutes les cinq minutes mais que le script met huit minutes à se terminer, une nouvelle instance peut démarrer alors que la précédente est encore active. Cela peut provoquer des doublons, des conflits de mise à jour ou une surcharge du serveur. Pour éviter ce problème, il faut mettre en place un système de verrouillage. La solution la plus simple consiste à créer un fichier temporaire pendant l’exécution du script. Si le fichier existe déjà, le script s’arrête.

<?php

$lockFile = __DIR__ . '/send-emails.lock';

if (file_exists($lockFile)) {
    exit("Script déjà en cours d’exécution\n");
}

file_put_contents($lockFile, getmypid());

try {
    // Traitement des emails ici
} finally {
    unlink($lockFile);
}

Cette méthode est simple, mais elle doit être utilisée avec prudence. Si le script s’interrompt brutalement, le fichier de verrouillage peut rester présent. Dans une version plus avancée, on peut stocker l’heure de création du verrou et le supprimer automatiquement s’il est trop ancien.

Sécuriser les données utilisées dans les emails

Un script d’envoi automatique manipule souvent des données issues d’un formulaire, d’un compte client ou d’une base de données. Ces données ne doivent jamais être utilisées sans contrôle. Les adresses email doivent être validées, les contenus doivent être nettoyés et les requêtes SQL doivent être préparées. Il faut notamment éviter l’injection dans les en-têtes d’emails. Un champ comme le nom de l’expéditeur, le sujet ou l’adresse de réponse ne doit jamais accepter de retours à la ligne non contrôlés, car cela pourrait permettre d’ajouter des en-têtes malveillants.

<?php

$email = filter_var($email, FILTER_VALIDATE_EMAIL);

if (!$email) {
    // Adresse invalide : on ignore ou on marque en erreur
    exit;
}

Les contenus HTML doivent également être maîtrisés. Si des informations saisies par un utilisateur sont intégrées dans un email, elles doivent être échappées ou filtrées selon le contexte.

Prévoir une version texte pour les emails html

Un email HTML est plus agréable visuellement, mais il ne doit pas être la seule version disponible. Certains clients mail, outils de sécurité ou lecteurs d’écran peuvent préférer une version texte. Prévoir les deux formats améliore la compatibilité et la lisibilité du message. Un email bien construit contient donc généralement (voir notre sujet sur l’emailing marketing et le nurturing :

• une version HTML structurée ;
• une version texte alternative ;
• un objet clair ;
• un expéditeur identifiable ;
• un lien de désinscription lorsque le message est commercial ;
• des informations cohérentes avec le consentement du destinataire.

Gérer les erreurs, les rebonds et les tentatives de renvoi

Tous les emails ne partiront pas correctement. Une adresse peut être invalide, une boîte peut être pleine, un domaine peut ne plus exister ou un serveur distant peut refuser temporairement le message. Le script doit donc prévoir une stratégie claire de gestion des erreurs. Une bonne pratique consiste à enregistrer le nombre de tentatives dans la file d’attente. Après une erreur temporaire, l’email peut être relancé plus tard. Après plusieurs échecs, il peut être marqué comme définitivement échoué.

Respecter la délivrabilité et les règles de consentement

La fiabilité ne concerne pas seulement l’exécution technique. Un email envoyé avec succès par le serveur peut quand même finir en spam. Pour améliorer la délivrabilité, il faut utiliser un domaine d’expédition cohérent, éviter les objets trompeurs, limiter les envois massifs soudains et surveiller les taux d’erreur. Pour les emails marketing, il faut aussi respecter le consentement des destinataires. Le message doit correspondre à ce que l’utilisateur a accepté de recevoir, et un mécanisme de désinscription doit être prévu. Les emails transactionnels, comme une confirmation de commande ou une réinitialisation de mot de passe, n’ont pas le même objectif qu’une newsletter commerciale et doivent être traités séparément.

Surveiller la tâche CRON dans le temps

Une fois en place, une tâche CRON ne doit pas être oubliée. Elle doit être surveillée régulièrement, surtout si elle gère des emails importants. Un changement de mot de passe SMTP, une mise à jour PHP, une modification de chemin serveur ou un manque d’espace disque peut suffire à bloquer les envois. Il est conseillé de prévoir une alerte si aucun email n’a été traité depuis un certain temps, si le nombre d’erreurs augmente fortement ou si le script dépasse une durée normale d’exécution. Cette supervision peut être faite avec des logs, des outils de monitoring ou une notification envoyée à l’administrateur.