Cron jobs vs n8n vs GitHub Actions : que choisir en 2026 ?

Tous les trois mois, un client me pose la même question : “j’ai un script qui doit tourner chaque matin à 7h, je le mets où ?” Et selon le projet, la stack, la taille de l’équipe et le budget, la réponse change. Trois options se battent pour le créneau : un bon vieux cron sur un VPS, un workflow n8n, ou un GitHub Actions schedule. Voici un comparatif terrain basé sur 40+ tâches récurrentes que j’ai déployées en 2025 et 2026.

Définissons “tâche récurrente”

Avant d’attaquer, mettons-nous d’accord. On parle ici de :

• Scripts qui doivent tourner à intervalle régulier (toutes les heures, tous les jours, lundi matin, etc.)
• Durée d’exécution < 30 min
• Pas de réaction immédiate à un événement extérieur (pour ça, ce sont des webhooks, voir comment gérer 10 000 events/jour)
• Exemples concrets : envoyer un rapport quotidien, synchroniser des stocks, nettoyer une base, scraper un site, déclencher un backup

Avec ce cadre, partons des trois candidats.

Option 1 : cron classique sur un VPS

C’est l’ancêtre. Tu loues un VPS chez Hetzner ou OVH (3 à 5 €/mois), tu te logges en SSH, tu fais crontab -e, tu ajoutes une ligne :

0 7 * * * /usr/bin/node /home/etienne/scripts/daily-report.js >> /var/log/daily-report.log 2>&1

Et c’est tout. Le système d’exploitation s’occupe du reste.

Les vrais avantages :

• Coût marginal proche de zéro (le VPS sert déjà à autre chose)
• Pas de limite de durée d’exécution
• Tu as accès à tout le système (filesystem, network, n’importe quel binaire installable)
• Tu peux mixer langages, libs, dépendances système (libreoffice, ffmpeg, headless chrome)
• Latence d’exécution : 0 (le cron déclenche à la seconde près)

Les vrais inconvénients :

• Tu dois gérer le VPS (sécurité, updates, monitoring)
• Si le serveur tombe, ton cron tombe avec
• Tu n’as pas d’UI : pour voir l’historique, tu vas dans /var/log à la main
• Pas de retry automatique si le job échoue
• Difficile de partager avec un collègue non-tech

Cas d’usage idéal : tu as déjà un VPS pour tes apps, ton équipe est tech, le job est simple et fait dans un langage que tu maîtrises. Exemple type : un script Python qui fait un dump SQL chaque nuit et l’envoie sur un S3.

Ce que je fais en pratique : j’utilise systemd timers plutôt que cron quand je peux. Plus moderne, mieux loggé via journalctl, et gère mieux les jobs longs. Exemple de service :

# /etc/systemd/system/daily-report.service
[Unit]
Description=Rapport quotidien

[Service]
Type=oneshot
User=etienne
WorkingDirectory=/home/etienne/scripts
ExecStart=/usr/bin/node daily-report.js
StandardOutput=journal
StandardError=journal

# /etc/systemd/system/daily-report.timer
[Unit]
Description=Lance le rapport quotidien à 7h

[Timer]
OnCalendar=*-*-* 07:00:00
Persistent=true

[Install]
WantedBy=timers.target

Persistent=true est génial : si le serveur était down à 7h, le job tourne au prochain démarrage. Avec cron classique, le job est juste perdu.

Option 2 : n8n

n8n est une plateforme d’automatisation visuelle open-source. Tu crées un workflow, tu ajoutes un nœud “Schedule Trigger”, tu configures les nœuds suivants (HTTP, base de données, email, etc.), tu actives, fini. Une interface graphique te montre les exécutions, les logs, les erreurs.

Les vrais avantages :

• UI superbe, historique d’exécutions visualisable
• 400+ intégrations natives (Slack, Notion, Stripe, Airtable, etc.)
• Retry automatique configurable par nœud
• Tu peux partager le workflow avec un collègue non-tech qui le modifiera tout seul
• Le code custom est possible (nœud “Code” en JS ou Python)
• Self-hosté gratuit (voir guide pour self-hoster n8n) ou cloud à partir de 20 €/mois
• Notifications natives sur erreur (Slack, email)

Les vrais inconvénients :

• Overkill pour un script de 10 lignes
• Le scheduler n8n est moins précis (peut décaler de quelques secondes)
• Si tu self-hostes, tu as la même problématique de maintenance qu’un VPS
• Versioning des workflows : possible mais moins propre que Git
• Pour 100+ workflows actifs, le moteur peut ramer (selon RAM allouée)

Cas d’usage idéal : tâches qui touchent à plusieurs APIs SaaS (genre “lundi matin, prends les leads HubSpot de la semaine, envoie un Slack au commercial avec le récap + crée une fiche Notion”). C’est typiquement ce que les clients me demandent et où n8n brille. Un développeur pourrait coder ça, mais en 3h, alors qu’un workflow n8n se monte en 30 minutes et reste maintenable.

Mon retour terrain : j’ai un client e-commerce avec 23 workflows n8n actifs, dont 17 sont scheduled. RAM allouée : 1 Go. Aucun problème. Au-delà de 50 workflows scheduled, je commence à conseiller de séparer en plusieurs instances n8n.

Option 3 : GitHub Actions schedule

Tu mets un fichier .github/workflows/cron.yml dans ton repo, tu définis un schedule cron, et GitHub exécute le workflow à intervalle régulier.

name: Daily report
on:
  schedule:
    - cron: '0 7 * * *'
  workflow_dispatch: # pour lancer manuellement

jobs:
  report:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: npm ci
      - run: node scripts/daily-report.js
        env:
          API_KEY: ${{ secrets.API_KEY }}

Les vrais avantages :

• Gratuit jusqu’à 2000 minutes/mois sur les repos privés (illimité sur les repos publics)
• Versionné dans Git par design (le workflow EST du code)
• Logs accessibles dans l’interface GitHub, historique infini
• Pas de serveur à maintenir
• Tu as accès à tout l’écosystème GitHub Actions (200 000+ actions sur le marketplace)
• Notifications natives via email/Slack en cas d’échec
• Tu peux relancer manuellement depuis l’UI ou avec gh workflow run

Les vrais inconvénients :

• Le scheduler GitHub est notoirement imprécis : il peut décaler de 5 à 15 minutes pendant les heures de pointe (les heures pile-poil sont les pires). Si ton job doit tourner exactement à 7h00, oublie.
• Pas de retry natif (mais facile à coder avec nick-fields/retry)
• Cold start de 10-30 secondes pour chaque exécution (provisioning du runner)
• Les secrets sont chiffrés mais visibles dans les logs si tu les echo (classique)
• Le workflow est désactivé automatiquement après 60 jours d’inactivité sur le repo. Si tu ne pushes rien pendant 2 mois, ton cron s’arrête. Vraiment.

Cas d’usage idéal : tâche dont le timing exact n’a pas d’importance (deploy nightly d’un site, génération d’un rapport hebdo, scraping qui doit tourner “quelque part dans la nuit”), code qui vit déjà dans un repo GitHub. C’est ce que j’utilise sur 80% des projets clients où on a déjà un repo Git actif.

Astuce que j’utilise systématiquement : je combine schedule + workflow_dispatch pour pouvoir lancer la même tâche manuellement quand je débugge. Et je rajoute une notification Slack en cas d’échec avec un step if: failure().

Comparatif chiffré

J’ai déployé exactement le même script (un health check qui ping 12 endpoints et envoie un Slack en cas d’erreur, tourne toutes les 15 minutes) sur les trois plateformes. Voici les chiffres réels sur 30 jours :

Critère	Cron VPS	n8n self-hosté	GitHub Actions
Exécutions réussies	2880/2880	2876/2880	2867/2880
Décalage moyen	< 1 s	2-3 s	4-7 min
Coût infra	4,50 €/mois (mutualisé)	6 €/mois (mutualisé)	0 €
Setup initial	10 min	20 min	15 min
Temps de debug moyen	8 min (SSH + logs)	3 min (UI claire)	5 min (logs GitHub)
Maintenance/mois	~30 min (updates)	~20 min	0

Le cron VPS gagne en fiabilité brute. n8n gagne en visibilité/debug. GitHub Actions gagne en simplicité/coût mais perd en précision temporelle.

Mon arbre de décision concret

Voici les questions que je me pose, dans l’ordre, pour décider :

1. Est-ce que la tâche doit tourner à un timing précis (genre “exactement à 9h00 pour ouvrir un système de réservation”) ?

• Oui → cron VPS ou systemd timer. Stop.

2. Est-ce que la tâche touche à plus de 2 APIs externes différentes ?

• Oui → n8n. La visualisation et les intégrations natives valent largement les 20 min de setup en plus.

3. Est-ce que le code vit déjà dans un repo GitHub actif ?

• Oui → GitHub Actions. Tu as tout dans Git, c’est versionnable, et tu paies zéro.

4. Tu n’as pas de VPS, pas de repo GitHub actif, et tu veux le truc plus rapide ?

• → GitHub Actions sur un repo dédié, ou Supabase Edge Functions + pg_cron (voir tutoriel Supabase Edge Functions).

Cet arbre couvre 90% de mes décisions. Les 10% restants, c’est des cas tordus où on combine deux solutions (genre cron VPS pour le timing précis qui appelle un webhook n8n pour orchestrer le flow).

Les outils que je n’ai pas inclus mais qui méritent d’être cités

Vercel Cron Jobs : excellent si tu utilises déjà Vercel, gratuit jusqu’à 2 crons sur le plan hobby, mais limité aux endpoints Next.js de ton app. Très pratique si ta tâche planifiée appelle directement une route API de ton site.

EasyCron / Cron-job.org : services hébergés qui pingent une URL à intervalle régulier. Utile pour réveiller une fonction serverless ou pinger un endpoint custom. Gratuit jusqu’à 50 jobs.

Temporal : pour les workflows long-running, retry complexes, workflows distribués. Surdimensionné pour 99% des besoins clients que je rencontre, mais top pour des architectures complexes.

AWS EventBridge / Lambda scheduled : si tu es déjà tout-AWS, c’est l’option logique. Sinon, le setup est plus pénible que Supabase ou GitHub Actions.

Erreurs que je vois souvent

1. Utiliser le mauvais timezone. Le cron de GitHub Actions tourne en UTC. Si tu mets 0 7 * * * en pensant à 7h du matin Paris, ton job tournera à 9h heure française l’été et à 8h l’hiver. Toujours penser à convertir, ou pire, à compenser le décalage.

2. Empiler les jobs. Un client avait 14 workflows n8n scheduled qui tournaient tous “0 9 * * *”. À 9h00 pile, n8n essayait de lancer 14 workflows simultanément, dont 3 lourds. Résultat : crash de l’instance toutes les semaines. Solution : décaler de 2-5 min entre chaque (0 9 * * *, 2 9 * * *, 5 9 * * *, etc.).

3. Pas de monitoring. Tu as un cron qui tourne “tous les jours à 7h”. Trois mois plus tard, tu te rends compte qu’il a planté depuis 6 semaines parce que ton accès API a expiré. Avant de mettre un cron en prod, toujours ajouter une notification de succès ET d’échec (heartbeat). Healthchecks.io fait ça très bien et est gratuit jusqu’à 20 jobs.

4. Croire que le cron va “auto-réparer”. Si ton job plante au step 3 et que tu ne gères pas l’idempotence, le prochain run va peut-être créer des doublons. Toujours coder en pensant : “que se passe-t-il si ce job tourne 2 fois aujourd’hui ?”

Conclusion

En 2026, je n’ai pas de gagnant universel. Mais une tendance se dégage clairement sur mes projets :

• Pour les petits scripts mono-tâche : GitHub Actions (gratuit, versionné, suffisant)
• Pour les automatisations multi-API ou business : n8n (UI, intégrations, debug rapide)
• Pour les jobs critiques au timing serré : cron/systemd sur VPS

Si tu hésites entre ces trois options pour un projet précis, j’analyse ton besoin et je te dis exactement quelle stack utiliser dans le cadre d’un audit d’automatisation. 45 minutes en visio, conclusions claires, devis adapté. Et si tu veux qu’on aille plus loin avec un workflow simple bien fichu, on peut partir directement sur un workflow clé-en-main que je code et maintiens.