Comment créer un script php qui s'exécute via une tâche cron tous les jours ?
- Comment créer un script php qui va s'exécuter via une tâche cron tout les jours?
- Écrire un script PHP pensé pour cron (et pas pour une page web)
- Créer la tâche cron quotidienne (la ligne qui lance tout)
- Éviter les pièges classiques (ceux qui font perdre du temps)
- Rendre la tâche cron «pilotable» (logs lisibles, alertes, et tests)
Automatiser une tâche côté serveur, c'est souvent ce qui fait passer un site «qui tourne» à un site vraiment fiable. Nettoyer des logs, relancer un cache, envoyer un digest email, vérifier un flux... tout ça n'a pas à dépendre d'un clic humain. Et c'est là que le duo PHP + cron devient votre meilleur allié.
Le principe est simple : vous écrivez un script PHP conçu pour s'exécuter seul, puis vous demandez à cron (le planificateur de tâches sur la plupart des serveurs Linux) de le lancer chaque jour à une heure donnée. Pas besoin d'un framework lourd. Juste quelques bonnes pratiques, et un peu de rigueur sur les chemins, les droits et les logs.
Comment créer un script php qui va s'exécuter via une tâche cron tout les jours?
Avant d'écrire la moindre ligne, clarifiez deux choses : quand la tâche doit tourner (heure exacte, fuseau horaire) et quoi elle doit produire (fichier, email, mise à jour en base, rapport). Ça paraît évident... et pourtant c'est là que les scripts «fantômes» naissent : ils tournent, mais on ne sait pas ce qu'ils ont fait.
Pensez aussi à l'environnement. En cron, il n'y a pas de navigateur, pas de session, et très peu de variables définies. Votre script doit être autonome, robuste, et prévisible. Oui, c'est moins «confort» que du PHP web, mais c'est plus sain.
Écrire un script PHP pensé pour cron (et pas pour une page web)
Un script cron se lance en ligne de commande, via PHP CLI. Du coup, évitez tout ce qui dépend de $_SERVER ou d'un contexte HTTP. Commencez par un fichier dédié, par exemple cron-daily.php, placé hors du répertoire public si possible (souvent hors de public_html).
Voici une base fiable, volontairement «sobre», avec gestion d'erreurs et log. Le but : si ça casse, vous le saurez tout de suite.
Exemple de squelette (à adapter) :
declare(strict_types=1);
date_default_timezone_set('Europe/Paris');
$logFile = __DIR__ . '/logs/cron-daily.log';
function logLine(string $msg, string $logFile): void {
$line = '[' . date('Y-m-d H:i:s') . '] ' . $msg . PHP_EOL;
file_put_contents($logFile, $line, FILE_APPEND);
}
set_error_handler(function($severity, $message, $file, $line) use ($logFile) {
logLine("PHP ERROR: $message ($file:$line)", $logFile);
});
set_exception_handler(function(Throwable $e) use ($logFile) {
logLine('EXCEPTION: ' . $e->getMessage(), $logFile);
exit(1);
});
logLine('DÉBUT', $logFile);
// ... votre traitement ...
logLine('FIN OK', $logFile);
Deux détails comptent vraiment : le chemin absolu (via __DIR__) et le fichier de log. Sans log, vous pilotez à l'aveugle. Et quand un client vous dit «les emails ne partent plus», vous perdez une heure à deviner.
[ Voir ici aussi ]
Gérer les chemins, les droits et les dépendances
En cron, le «répertoire courant» n'est pas celui auquel vous pensez. Utilisez toujours des chemins absolus, ou calculez-les avec __DIR__. Pour les accès fichiers, vérifiez que le dossier de logs existe et qu'il est inscriptible. Sinon, le script échoue... sans bruit si vous n'avez rien prévu.
Si votre script utilise Composer, appelez explicitement l'autoload : require __DIR__ . '/vendor/autoload.php';. C'est basique, mais ça évite les «Class not found» qui arrivent uniquement en cron (et jamais en dev local, évidemment...).
Créer la tâche cron quotidienne (la ligne qui lance tout)
Une tâche cron, c'est une ligne dans la crontab. Vous pouvez l'éditer avec crontab -e (pour l'utilisateur courant) ou via le panneau d'hébergement si vous êtes sur un mutualisé. Dans les deux cas, l'idée est la même : définir une planification et une commande.
Le format cron classique : minute, heure, jour du mois, mois, jour de la semaine. Pour une exécution tous les jours à 03:15, ça donne :
15 3 * * * /usr/bin/php -d detect_unicode=0 /chemin/absolu/cron-daily.php >> /chemin/absolu/logs/cron-run.log 2>&1
Retenez trois points : le chemin vers l'exécutable PHP (souvent /usr/bin/php), le chemin absolu du script, et la redirection stdout/stderr vers un fichier. Cette dernière partie (le 2>&1) capture aussi les erreurs. C'est précieux.
Checklist rapide avant de sauvegarder la crontab
- Le script tourne à la main : testez avec /usr/bin/php /chemin/cron-daily.php.
- Les permissions sont correctes sur le script et le dossier de logs.
- Le bon utilisateur exécute la tâche (celui qui a accès aux fichiers et à la base).
- La timezone est maîtrisée (cron peut utiliser celle du serveur, pas la vôtre).
- Les sorties sont redirigées vers un log, pas «perdues».
Éviter les pièges classiques (ceux qui font perdre du temps)
Le piège numéro un : appeler une URL au lieu d'un script CLI. On voit encore des cron du type curl https://monsite/cron.php. Ça marche... jusqu'au jour où un cache, une protection, ou un timeout s'en mêle. En général, préférez une exécution locale via PHP CLI, plus stable et plus rapide.
Autre souci fréquent : les tâches qui se chevauchent. Si votre traitement dure 12 minutes et que vous le lancez toutes les 10 minutes, vous créez une file d'attente involontaire. Même en quotidien, ça peut arriver si un script bloque sur un appel réseau. Une solution simple : un lockfile (un fichier «verrou») au démarrage, supprimé à la fin. Si le lock existe déjà, on quitte. Ça évite les doublons sans complexité.
Un petit verrou anti-doublon (simple et efficace)
Le principe : créer un fichier qui signale «je tourne». Si le fichier existe, vous stoppez. C'est rustique, mais ça sauve des sites.
$lock = __DIR__ . '/tmp/cron-daily.lock';
if (file_exists($lock)) { exit(0); }
file_put_contents($lock, (string)getmypid());
register_shutdown_function(function() use ($lock) { @unlink($lock); });
Et si vous voulez faire propre : mettez ce verrou juste après le démarrage, puis logguez «déjà en cours» avant de quitter. Vous aurez une trace, sans spam.
Rendre la tâche cron «pilotable» (logs lisibles, alertes, et tests)
Un bon script cron, ce n'est pas seulement du code qui s'exécute. C'est un script qu'on peut auditer. Donnez-lui un log clair : une ligne de début, une ligne de fin, et au milieu des étapes courtes («20 lignes supprimées», «3 emails envoyés», «cache reconstruit»). Vous verrez tout de suite si le résultat est cohérent.
Pour les cas critiques, vous pouvez ajouter une alerte mail uniquement en cas d'échec (pas à chaque run, sinon vous finirez par filtrer ces mails... et rater le jour où ça compte). Si votre serveur le permet, cron peut aussi envoyer la sortie par email, mais je préfère un log + une notification ciblée : moins de bruit, plus d'action.
Dernier conseil de webmaster : ajoutez un mode «test» via un argument CLI, par exemple --dry-run. Vous pourrez vérifier la logique sans toucher à la base ou sans envoyer de message, et ça rend les mises à jour beaucoup moins stressantes quand vous déployez.
👉 Lire aussi: Comment mettre en oeuvre une Content Security Policy tout en conservant des css inline ?
A propos de moi : Clara MetaWeb
Passionnée de web depuis plus de dix ans, je partage sur Ton Site mes astuces et conseils pour aider les webmasters à optimiser et sécuriser leurs sites. De la gestion technique à l’ergonomie, j’aime explorer tous les aspects qui rendent un site performant et agréable à utiliser. Mon parcours m’a permis d’accompagner aussi bien des débutants que des experts dans leurs projets digitaux. Je crois fermement que chaque webmaster peut progresser avec les bons outils et les bonnes pratiques. Rejoignez-moi pour découvrir ensemble les secrets d’un web efficace et durable !