Pourquoi le monde a besoin d'un service cron à 2 $

Par Thales & Claude -- CEO & AI CTO, ZeroSuite, Inc.

Il y a une développeuse à Lagos en ce moment qui a besoin de ping un endpoint API chaque matin à 9 h. Elle a construit un petit SaaS -- peut-être un outil de gestion scolaire, peut-être un système de rappel de factures -- et elle a besoin d'une tâche cron. Une seule requête HTTP planifiée, une fois par jour. C'est toute l'exigence.

Ses options : payer 19 $ par mois pour Cronhub (presque un quart de son budget d'hébergement mensuel), utiliser cron-job.org gratuitement et accepter une gigue aléatoire de 4 à 40 secondes sur chaque exécution, ou déployer un VPS à 5 $ juste pour exécuter crontab -e. Aucune de ces options ne respecte sa situation. Aucune n'a été conçue pour elle.

Nous avons construit 0cron parce que le marché des tâches planifiées a un trou béant, et personne ne semble intéressé à le combler.

Le paysage concurrentiel est un vrai bazar

Avant d'écrire la moindre ligne de Rust, nous avons cartographié chaque service de tâches cron que nous pouvions trouver. Le tableau n'était pas encourageant -- non pas parce que le marché est saturé, mais parce que chaque acteur a commis la même erreur : ils facturent trop cher, offrent trop peu, ou les deux.

Voici à quoi ressemble le marché en 2026 :

Regardez ce tableau et trouvez le produit qui offre : configuration simple, tâches illimitées, exécutions illimitées, tarification abordable, accès universel (pas verrouillé sur une plateforme), et une interface moderne.

Il n'existe pas.

Le plan gratuit est peu fiable. Le milieu de gamme est facturé par tâche ou par exécution, ce qui signifie que votre facture augmente à mesure que votre produit grandit -- exactement quand vous pouvez le moins vous permettre des surprises. Le haut de gamme commence à 19 $ par mois pour ce qui revient à une requête HTTP sur une minuterie. Et les outils de monitoring uniquement ne résolvent même pas le problème fondamental ; ils regardent pendant que votre serveur fait le travail.

Personne n'offre : simple + illimité + pas cher + universel + interface moderne. C'est la brèche.

La philosophie tarifaire : la simplicité radicale

Quand nous avons conçu la tarification de 0cron, nous avons commencé par une question : quel est le prix minimum viable qui soutient l'entreprise tout en étant accessible à chaque développeur sur Terre ?

La réponse : 1,99 $ par mois. Forfait fixe. Tout illimité.

Pas de tarification par tâche. Pas de frais par exécution. Pas de fonctionnalités verrouillées par paliers. Pas de « contactez-nous ». Vous payez 1,99 $ et vous obtenez le produit complet -- tâches illimitées, exécutions illimitées, historique illimité, accès API illimité, chaque canal de notification, planification en langage naturel, l'ensemble complet des fonctionnalités.

Ce n'est pas un produit d'appel. C'est le modèle économique.

Voici le calcul. 0cron est un serveur API Rust adossé à PostgreSQL et Redis. Le coût opérationnel par utilisateur est minimal -- chaque abonné supplémentaire ajoute quelques lignes à une base de données et quelques entrées à un sorted set Redis. Le coût marginal de la planification d'une tâche supplémentaire est effectivement nul une fois l'infrastructure en place.

À 1,99 $ par mois :

• 10 000 abonnés = 19 900 $/mois = 238 800 $/an
• 50 000 abonnés = 99 500 $/mois = 1 194 000 $/an
• 100 000 abonnés = 199 000 $/mois = 2 388 000 $/an

Le marché adressable cible est vaste. Considérez les segments :

Capturer 0,1 % de ce marché combiné nous fait dépasser 10 000 abonnés. La tarification est conçue pour éliminer les objections entièrement. Deux dollars par mois, c'est une erreur d'arrondi dans le budget de n'importe quel développeur. C'est moins qu'une tasse de café. C'est moins que les frais de transaction de la plupart des processeurs de paiement.

L'objectif n'est pas d'extraire un revenu maximum par utilisateur. L'objectif est l'adoption. Mettre l'outil dans la stack de chaque développeur, le rendre indispensable, et laisser le volume porter l'entreprise.

Pourquoi 1,99 $ fonctionne économiquement

La question sceptique est évidente : comment faire tourner un service de planification fiable pour 1,99 $ par utilisateur par mois ?

La réponse se trouve dans les choix technologiques.

Le backend de 0cron est écrit en Rust avec Axum pour le serveur HTTP, SQLx pour l'accès base de données, et Redis pour l'état de planification. Rust nous offre trois avantages qui font fonctionner l'économie :

1. Efficacité mémoire. Un serveur web Rust servant des milliers de connexions simultanées utilise une fraction de la mémoire qu'un équivalent Node.js ou Python nécessiterait. Moins de serveurs, coûts d'hébergement réduits.

1. Efficacité CPU. Pas de ramasse-miettes, pas de surcharge runtime. La boucle de polling du planificateur s'exécute une fois par seconde, vérifie un sorted set Redis, et dispatche le travail. C'est quelques microsecondes de temps CPU par tick.

1. Fiabilité. Pas d'exceptions de pointeur null, pas de crashes runtime à cause d'incompatibilités de types. Le compilateur attrape des catégories entières de bugs avant le déploiement. Moins d'incidents signifie moins d'heures d'astreinte (ce qui, dans notre cas, signifie moins de sessions où Thales doit réveiller Claude à 3 h du matin).

Voici l'initialisation de l'API principale -- le démarrage complet du serveur tient en 77 lignes :

rust#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
    tracing_subscriber::fmt()
        .with_writer(std::io::stderr)
        .with_env_filter(EnvFilter::from_default_env()
            .add_directive("zerocron=info".parse()?))
        .init();

    let config = AppConfig::from_env()?;
    let database = Database::connect(&config.database_url).await?;
    database.migrate().await?;
    let redis_client = redis::Client::open(config.redis_url.as_str())?;

    let state = api::AppState {
        db: database,
        redis: redis_client,
        config: Arc::new(config.clone()),
    };

    // Start scheduler background task
    let scheduler = Arc::new(Scheduler::new(
        state.redis.clone(),
        state.db.pool.clone(),
        Arc::clone(&state.config),
    ));
    let _scheduler_handle = scheduler.start();

    let app = api::router(state);
    let addr = format!("{}:{}", config.server_host, config.server_port);
    let listener = tokio::net::TcpListener::bind(&addr).await?;
    axum::serve(listener, app).await?;

    Ok(())
}

Le struct AppState qui circule à travers chaque handler de requête contient trois champs :

rust#[derive(Debug, Clone)]
pub struct AppState {
    pub db: Database,
    pub redis: redis::Client,
    pub config: Arc<AppConfig>,
}

Pool de connexion base de données, client Redis, configuration applicative. C'est l'intégralité de l'état runtime. Pas de caches en mémoire à synchroniser, pas d'injection de dépendances complexe, pas de magie de framework.

Planification en langage naturel : supprimer la dernière barrière

Les expressions cron sont un format vieux de 50 ans conçu pour les administrateurs système Unix. Elles sont puissantes, concises, et complètement opaques pour quiconque n'a pas mémorisé l'ordre des champs.

Vite : que signifie 0 9 <em> </em> 1-5 ?

Cela signifie « à 9 h 00, du lundi au vendredi ». Mais il a fallu y réfléchir. Et si vous êtes développeur WordPress ou constructeur IA/no-code, vous n'avez peut-être jamais vu une expression cron de votre vie.

0cron accepte à la fois les expressions cron et l'anglais courant. L'appel API ressemble à ceci :

bashcurl -X POST https://api.0cron.dev/v1/jobs \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -d '{
    "name": "daily-report",
    "schedule": "every day at 9am",
    "url": "https://api.myapp.com/reports",
    "notify": {"on_failure": "slack"}
  }'

Le parseur en langage naturel est un système à base de règles écrit en Rust -- environ 20 patterns regex couvrant les besoins de planification les plus courants :

rustpub fn parse_natural_language(input: &str) -> AppResult<String> {
    let input = input.trim().to_lowercase();

    // "every minute"
    if input == "every minute" {
        return Ok("* * * * *".to_string());
    }

    // "every N minutes"
    if let Some(caps) = re(r"^every (\d+) minutes?$").captures(&input) {
        let n: u32 = caps[1].parse().unwrap_or(1);
        return Ok(format!("*/{n} * * * *"));
    }

    // "every day at H:MMam/pm"
    if let Some(caps) = re(r"^every day at (\d{1,2})(?::(\d{2}))?\s*(am|pm)$")
        .captures(&input)
    {
        let (hour, minute) = parse_time(&caps[1],
            caps.get(2).map(|m| m.as_str()), &caps[3])?;
        return Ok(format!("{minute} {hour} * * *"));
    }

    // "weekdays at H:MMam/pm"
    if let Some(caps) = re(r"^weekdays at (\d{1,2})(?::(\d{2}))?\s*(am|pm)$")
        .captures(&input)
    {
        let (hour, minute) = parse_time(&caps[1],
            caps.get(2).map(|m| m.as_str()), &caps[3])?;
        return Ok(format!("{minute} {hour} * * 1-5"));
    }

    // ... ~15 more patterns

    Err(AppError::Validation(format!(
        "Unrecognized schedule pattern: '{input}'. Try patterns like \
         'every day at 9am', 'every Monday at 2pm', 'every 15 minutes'."
    )))
}

« Every day at 9am » devient 0 9 <em> </em> <em>. « Weekdays at 6am » devient 0 6 </em> <em> 1-5. « Every 15 minutes » devient </em>/15 <em> </em> <em> </em>. La traduction est déterministe, auditable et rapide -- aucune inférence LLM requise.

Nous avons choisi une approche à base de règles plutôt qu'une approche basée sur un LLM de manière délibérée. La planification est un domaine où la prévisibilité compte plus que la flexibilité. Quand un développeur dit « every Monday at 2pm », il a besoin exactement de 0 14 <em> </em> 1, pas d'une interprétation probabiliste qui pourrait occasionnellement dériver. Le parseur soit correspond à un pattern connu et retourne l'expression cron correcte, soit indique à l'utilisateur exactement quels patterns sont supportés. Aucun risque d'hallucination.

Le schéma de base de données : à quoi ressemble réellement une tâche

Chaque tâche dans 0cron vit dans une table PostgreSQL avec à la fois les métadonnées de planification et les statistiques d'exécution :

sqlCREATE TABLE IF NOT EXISTS jobs (
    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    team_id UUID REFERENCES teams(id),
    created_by UUID REFERENCES users(id),
    name VARCHAR(255) NOT NULL,
    description TEXT,
    schedule_cron VARCHAR(100) NOT NULL,
    schedule_human VARCHAR(255),
    timezone VARCHAR(50) DEFAULT 'UTC',
    job_type VARCHAR(20) DEFAULT 'http',
    config JSONB NOT NULL,
    status VARCHAR(20) DEFAULT 'active',
    tags TEXT[],
    next_run_at TIMESTAMPTZ,
    last_run_at TIMESTAMPTZ,
    last_status VARCHAR(20),
    last_duration_ms INTEGER,
    total_runs BIGINT DEFAULT 0,
    total_failures BIGINT DEFAULT 0,
    notification_config JSONB,
    created_at TIMESTAMPTZ DEFAULT NOW(),
    updated_at TIMESTAMPTZ DEFAULT NOW()
);

CREATE INDEX IF NOT EXISTS idx_jobs_next_run
    ON jobs(next_run_at) WHERE status = 'active';

Quelques décisions de conception à noter :

• schedule_cron et schedule_human sont tous deux stockés. L'expression cron est la source de vérité pour le planificateur ; la version lisible par l'humain est conservée pour l'affichage dans le tableau de bord. Cela signifie que le parseur NLP ne s'exécute qu'une fois à la création de la tâche, pas à chaque tick.

• config est en JSONB. La configuration de la tâche HTTP -- URL, méthode, en-têtes, corps, timeout, politique de retry -- vit dans une seule colonne JSONB plutôt que d'être normalisée sur plusieurs tables. Cela garde le schéma simple et rend trivial l'ajout de nouveaux types de tâches plus tard sans migrations.

• Les statistiques runtime sont dénormalisées sur la ligne de la tâche. total_runs, total_failures, last_run_at, last_status, last_duration_ms -- ces valeurs pourraient être calculées à partir de la table executions, mais les stocker directement signifie que le tableau de bord peut afficher l'état de la tâche sans scanner l'historique d'exécution. Un simple UPDATE ... SET total_runs = total_runs + 1 après chaque exécution est moins coûteux qu'un COUNT(*) à chaque chargement de page.

• L'index partiel sur next_run_at ne couvre que les tâches actives. Les tâches en pause et supprimées ne participent pas aux requêtes de planification, elles ne doivent donc pas gonfler l'index.

Pourquoi maintenant : l'argument du timing de marché

Cinq forces convergent pour faire de 2026 le bon moment pour un service comme 0cron :

1. cPanel est en train de mourir. L'hébergement mutualisé -- l'environnement où la plupart des développeurs ont découvert les tâches cron pour la première fois -- est en déclin terminal. Les développeurs qui ont grandi avec crontab -e dans leur panneau d'hébergement migrent vers des plateformes serverless, et ils découvrent que Vercel et Netlify ne leur offrent pas de crontab.

2. Le verrouillage de plateforme s'intensifie. Vercel Cron Jobs ne fonctionne que si vous êtes sur Vercel. Netlify Scheduled Functions ne fonctionne que sur Netlify. AWS EventBridge nécessite un compte AWS et une expertise CloudWatch. Chaque plateforme veut posséder votre planification, ce qui signifie que chaque migration de plateforme implique de reconstruire votre configuration cron. Un planificateur externe et agnostique est une assurance contre le verrouillage fournisseur.

3. Les agents IA ont besoin de planification. L'explosion des applications construites par IA -- outils assemblés par des constructeurs no-code, prototypes assistés par Cursor, MVP générés par Claude -- ont toutes besoin à terme d'un moyen d'exécuter des choses sur une minuterie. Ces constructeurs n'ont aucun intérêt à gérer de l'infrastructure. Ils veulent un endpoint API qu'ils peuvent appeler avec un planning et oublier.

4. Les acteurs SaaS existants n'ont pas innové. L'interface d'EasyCron ressemble à quelque chose construit en 2015 parce que c'est le cas. Cronhub n'a pas ajouté de fonctionnalité majeure depuis des années. La page de tarification de FastCron nécessite une calculatrice pour être comprise. Les acteurs en place se reposent sur leurs lauriers, et le marché est prêt pour une disruption par le bas.

5. Les développeurs des marchés émergents arrivent en ligne. L'Afrique seule ajoute des centaines de milliers de développeurs chaque année. Ce sont des ingénieurs talentueux qui construisent de vrais produits, mais ils opèrent dans des économies où 19 $ par mois est une dépense significative. 0cron à 1,99 $ par mois est le premier service de tâches cron tarifé pour la population mondiale de développeurs, pas seulement pour celle de San Francisco.

L'angle africain : construire des outils mondiaux depuis Abidjan

0cron est construit depuis Abidjan, en Côte d'Ivoire. Ce n'est pas un argument marketing -- c'est une contrainte architecturale qui façonne chaque décision.

Quand votre CEO est en Afrique de l'Ouest, vous comprenez viscéralement ce que signifie être sensible au prix. Vous comprenez que 19 $ par mois n'est pas « abordable » -- c'est un prix d'exclusion qui bloque des centaines de milliers de développeurs compétents. Vous comprenez que la fiabilité compte encore plus quand les connexions internet sont intermittentes et que chaque requête échouée coûte de l'argent réel en données mobiles.

Construire depuis Abidjan signifie aussi construire avec un essai gratuit de 60 jours plutôt que de 14 jours. L'infrastructure de paiement africaine est complexe -- tout le monde n'a pas une carte de crédit qui fonctionne avec Stripe du premier coup. Donner aux développeurs deux mois pour intégrer 0cron dans leur workflow, confirmer que ça marche, et régler leur moyen de paiement est une décision business enracinée dans la compréhension de l'expérience utilisateur réelle, pas un growth hack de la Silicon Valley.

ZeroSuite -- la société mère -- a désormais six produits, tous construits par un CEO (Thales) et un AI CTO (Claude), avec zéro ingénieur humain. 0cron est le deuxième produit à être livré, après sh0 (un PaaS auto-hébergé). La même équipe, la même méthodologie, le même appartement à Abidjan. Les outils que nous construisons reflètent le monde dans lequel nous vivons.

Positionnement : les fonctionnalités de Cronhub au prix de cron-job.org

Si vous nous obligiez à décrire 0cron en une ligne, ce serait celle-ci :

Les fonctionnalités de Cronhub au prix de cron-job.org avec une interface moderne de 2026.

Cela signifie : gestion complète des tâches avec opérations CRUD, historique d'exécution avec journalisation complète des requêtes/réponses, logique de retry avec backoff exponentiel/linéaire/fixe, notifications multi-canaux (Slack, Discord, Telegram, e-mail, webhooks), monitoring heartbeat, support d'équipe avec contrôle d'accès basé sur les rôles, clés API avec permissions granulaires, gestion de secrets chiffrés, et planification en langage naturel.

Tout cela. Pour 1,99 $ par mois. Illimité.

Le pari est que la simplicité radicale de la tarification crée une adoption radicale. Supprimez la calculatrice, supprimez la comparaison de plans, supprimez la page « contactez-nous ». Un prix, un plan, tout inclus. La seule décision du développeur est de savoir si 1,99 $ par mois vaut le fait de ne pas gérer son propre planificateur.

Nous croyons que la réponse, pour des millions de développeurs dans le monde, est évidemment oui.

Ceci est la partie 1 d'une série en trois parties sur la construction de 0cron.dev. Prochain article : 4 agents, 1 produit : construire 0cron en une seule session -- comment nous avons utilisé une équipe parallèle de quatre agents pour scaffolder l'ensemble du produit en un après-midi.