Tu n'as pas besoin d'un VPS, d'un cron server ni d'un Zapier payant pour lancer
un produit web. Deux services gratuits couvrent 95 % des besoins d'un solo ou
d'une petite équipe : Vercel pour le runtime, GitHub Actions pour tout
ce qui est planifié. Voici comment les câbler proprement.

Vercel Hobby : ce que tu obtiens vraiment

  • Déploiement automatique sur git push, URL de preview par PR.
  • Pages statiques servies depuis le CDN, fonctions serverless (Node), edge middleware.
  • Bande passante et invocations généreuses pour un trafic de démarrage.

Le point d'attention : les conditions Hobby interdisent l'usage
commercial. En pratique, un site vitrine ou un side-project passe ; dès que
tu factures des clients dessus, il faut passer en Pro. Anticipe-le dans ton
modèle de coûts plutôt que de te faire couper.

GitHub Actions : le cron gratuit que tout le monde oublie

  • Repo public : minutes illimitées.
  • Repo privé : ~2000 minutes/mois gratuites — largement assez pour des jobs planifiés courts.

Le pattern : Vercel fait tourner ton app, Actions fait tourner ce qui n'a pas
besoin d'un serveur permanent — publication de contenu programmée, backups,
health checks, régénération de données.

on: schedule: - cron: "0 9 * * 1" # lundi 09:00 UTC workflow_dispatch: # + déclenchement manuel permissions: contents: write # committer un fichier d'état en fin de run

Les secrets : ne mélange pas les deux mondes

Règle simple :

  • Variables de l'app (clé API consommée au runtime par une fonction Vercel) → Vercel > Project > Settings > Environment Variables.
  • Secrets de CI (jeton utilisé seulement par un workflow) → GitHub > Repo > Settings > Secrets and variables > Actions.

Un jeton de publication Dev.to n'a rien à faire dans Vercel. Une clé de webhook
Revolut n'a rien à faire dans GitHub. Sépare, et tu réduis la surface d'un leak.

Éviter la boucle de redéploiement

Si un workflow committe un fichier (état, cache) sur main, Vercel va vouloir
redéployer. Ajoute [skip ci] dans le message de commit du bot — Vercel le
respecte et saute le build inutile.

git commit -m "chore(bot): update state [skip ci]"

Ce qui casse en premier quand tu grandis

Connaître les plafonds évite les mauvaises surprises :

  • Durée des fonctions : une fonction serverless a une limite d'exécution. Un traitement long (génération de rapport, appel LLM en série) doit être découpé, mis en file, ou déporté vers un job Actions.
  • Cold starts : la première requête après une période d'inactivité paie le démarrage. Pour un endpoint critique, garde-le léger (peu de dépendances importées).
  • Minutes Actions sur repo privé : 2000/mois, ça part vite si tes workflows installent tout node_modules à chaque run. Cache les dépendances (actions/setup-node avec cache: npm) et garde les jobs courts.

Aucun de ces plafonds n'est bloquant au démarrage — mais les anticiper te
laisse le temps de migrer proprement le jour où le trafic arrive.

Le résultat

Un pipeline complet — site rapide, déploiements continus, tâches planifiées,
notifications — pour le prix d'un nom de domaine. L'infra n'est plus une excuse
pour ne pas lancer.

🎯 Gagne les 100 heures de setup : l'écosystème Securium Labs

→ www.securium-labs.app/offres