Tâches planifiées : ce que le mutualisé autorise vraiment
Ou : le serveur partagé accepte de vous réveiller, mais pas toutes les minutes.
La réponse courte : sur un hébergement mutualisé, une tâche cron, c’est-à-dire un script lancé automatiquement à intervalle fixe, ne tourne pas aussi souvent qu’on le voudrait. Infomaniak impose un intervalle de quinze minutes au minimum en mutualisé, et d’une minute sur son Serveur Cloud, selon sa FAQ sur le planificateur de tâches mise à jour le 27 octobre 2026. OVHcloud n’autorise qu’une exécution par heure, sans choix de la minute. o2switch, avec le formulaire de cPanel, laisse régler la tâche à la minute. Pour une sauvegarde nocturne ou l’envoi d’une lettre d’information, ces écarts ne comptent pas ; pour une file d’attente à vider toutes les minutes, ils décident du choix de l’offre. C’est un point du guide du mutualisé qui se vérifie avant l’achat, pas après.
La fréquence n’est qu’une des règles. Le nombre de tâches, la durée maximale d’exécution, la taille de la sortie et le sort d’une tâche qui échoue varient autant d’un hébergeur à l’autre.
Pour qui : un site vitrine, un blog ou une petite boutique dont les tâches planifiées tournent toutes les quinze minutes ou moins souvent : sauvegardes, nettoyage, envoi de lettres d’information.
À partir de : 5,75 € HT par mois pour l’hébergement web Infomaniak, facturé à l’année par défaut, sans prix promotionnel affiché (relevé du 12 novembre 2026).
Pour démarrer : commander l’hébergement web Infomaniak, ouvrir le planificateur de tâches dans les outils avancés du Manager, puis protéger par mot de passe l’adresse du script appelé.
Tâche cron sur un hébergement mutualisé : fréquence, nombre et durée par hébergeur
| Hébergeur | Fréquence la plus courte | Nombre de tâches | Durée et autres limites |
|---|---|---|---|
| Infomaniak, mutualisé | 15 minutes | non publié | planificateur qui appelle l’adresse d’un script ; 1 minute sur Serveur Cloud |
| o2switch | à la minute, formulaire de cPanel | non publié | un appel par wget reste soumis au délai web de 360 secondes |
| OVHcloud | une fois par heure, minute non réglable | non publié | 60 minutes au plus, 5 Mo de sortie, tâche désactivée après 10 échecs |
| Hostinger | non publiée | 2 sur Single ; « Unlimited » dès Premium selon l’aide, 400 selon le contrat | éviter les exécutions simultanées |
| LWS | non publiée | 1, 10 ou 50 selon l’offre | non publiées |
| IONOS | non publiée | 10, 25, 50 ou 100 selon l’offre | non publiées |
Relevé du 12 novembre 2026 dans la documentation officielle : FAQ d’Infomaniak, documentation d’o2switch sur les tâches cron, guide des tâches automatisées d’OVHcloud (mis à jour le 3 juin 2026), article d’aide d’Hostinger (29 octobre 2026) et contrat d’hébergement d’Hostinger (28 août 2026), pages des offres de LWS et d’IONOS.
La ligne d’Hostinger illustre la distance entre deux documents d’un même hébergeur : l’article d’aide annonce un nombre de tâches illimité à partir de l’offre Premium, la clause du contrat sur les services illimités cite 400 tâches cron. La seconde a valeur contractuelle ; elle laisse d’ailleurs une marge que peu de sites approcheront.
Le mode d’appel compte autant que la fréquence. Une tâche qui appelle une adresse web, comme le planificateur d’Infomaniak ou un wget chez o2switch, passe par le serveur web et subit ses délais : 360 secondes chez o2switch, le temps d’exécution maximal de PHP ailleurs. Une tâche qui lance directement le script en ligne de commande échappe à ces délais, mais doit appeler le bon binaire de PHP, avec un chemin absolu. OVHcloud demande de choisir la version de PHP de chaque tâche et de toujours utiliser des chemins absolus.
Le piège le plus courant n’est pas la fréquence, c’est le chevauchement. La documentation d’o2switch le décrit : une tâche lancée toutes les minutes qui met plus d’une minute à s’exécuter démarre une nouvelle copie avant la fin de la précédente, et les processus s’accumulent jusqu’à saturer l’hébergement ; sa FAQ sur les ressources précise que cela finit en erreurs 503. Le remède proposé est la commande flock, qui pose un verrou et empêche une seconde exécution tant que la première tourne :
| |
Deux autres réflexes évitent les mauvaises surprises. Rediriger la sortie, sinon certains hébergeurs écrivent un fichier à chaque exécution ou envoient un mail ; o2switch rappelle d’ajouter -o /dev/null à un appel wget. Et vérifier qu’une tâche est vraiment active : OVHcloud désactive la sienne après dix échecs et n’envoie son rapport d’erreur qu’au dixième.
WordPress, enfin, possède son propre planificateur, déclenché par les visites et non par l’horloge. Le remplacer par une vraie tâche cron est une question propre à WordPress, qui dépasse le cadre de cette page.
Le terminal, l’autre porte vers la planification
Sur certains hébergements, la crontab se règle en ligne de commande plutôt que dans un formulaire, et un accès SSH aide à tester un script avant de le planifier. Les offres qui ouvrent le terminal, et à quelles conditions, sont comparées dans SSH et Git sur un mutualisé.
Les processus qui s’empilent
Une tâche qui se chevauche avec elle-même consomme des processus, et le nombre de processus d’un compte est plafonné. Ces plafonds, et les erreurs qu’ils provoquent, sont détaillés dans les ressources allouées à chaque compte.
Des pics à heure fixe
Une courbe de consommation qui grimpe toutes les heures pile trahit souvent une tâche planifiée, sauvegarde ou import, plutôt qu’un voisin bruyant. La lecture de ces graphiques fait partie de la méthode face à un site lent.