CronLab

CronLab est parti d'un besoin concret : faire tourner ma synchro GitLab vers GitHub tous les jours, sous Windows. Il me fallait un planificateur. Le Planificateur de tâches de Windows fait le travail, mais son interface est une antiquité et configurer une simple commande récurrente demande une demi-douzaine de fenêtres. Autant en construire un à ma main.

C'est une application de bureau qui planifie des commandes selon des expressions cron, avec une interface moderne, des notifications système et un historique d'exécution. C'est aussi ma première vraie application de bureau, et le premier projet que j'ai distribué en téléchargement plutôt que déployé sur le web.

Pourquoi Tauri et pas Electron

La différence tient en un chiffre : le binaire pèse quelques mégaoctets là où l'équivalent Electron en pèserait des centaines.

Tauri utilise la WebView native du système, déjà présente sur Windows 11, au lieu d'embarquer un navigateur complet. L'interface est du web, le cœur est en Rust. Pour un utilitaire qu'on laisse tourner en permanence dans la zone de notification, la mémoire résidente compte, et c'est ce qui a fait pencher la balance.

C'était aussi l'occasion d'apprendre Rust, que je ne connaissais pas. Le langage s'est révélé être un bon choix pour ce que fait le programme.

Ce que fait le cœur Rust

• l'ordonnancement, via la crate cron pour interpréter les expressions,
• l'exécution des commandes, avec des variables d'environnement et un délai d'expiration par tâche,
• le lancement manuel d'une tâche à la demande, en un clic, sans attendre sa prochaine occurrence,
• la capture des sorties standard et d'erreur, plafonnées à dix kilooctets chacune pour qu'une commande bavarde ne fasse pas gonfler les journaux,
• la conservation des dernières exécutions, dix par défaut et ajustable,
• les notifications natives en cas de succès, d'échec ou de dépassement de délai,
• l'icône de zone de notification avec fermeture en arrière-plan, et le démarrage automatique avec Windows.

C'est là que la gestion de la propriété mémoire de Rust devient concrète. La configuration et les tâches vivent dans un état partagé entre l'interface et l'ordonnanceur ; plusieurs exécutions peuvent y accéder en même temps, et le compilateur refuse simplement de produire un binaire si cet accès n'est pas correctement synchronisé. Ce sont des bugs que je n'ai pas eu à chasser : le compilateur les empêche en amont.

Coller à l'apparence de Windows

L'interface utilise les composants Fluent UI de Microsoft, pour ressembler à une application Windows 11 native plutôt qu'à une page web posée dans une fenêtre. Elle est bilingue, français et anglais, y compris pour les notifications système.

Une configuration lisible par un humain

Tout vit dans ~/.cronlab/ : un fichier config.json contenant les réglages et les tâches, plus un journal d'exécution par tâche dans un sous-dossier.

Ce fichier est délibérément lisible et modifiable à la main. On peut l'éditer, le copier sur une autre machine pour migrer sa configuration, ou le sauvegarder, sans passer par l'application. Je préfère un format qu'on peut lire et reprendre soi-même à une configuration enfermée dans un format opaque.

La chaîne de distribution

C'est la partie dont je suis le plus fier, parce qu'elle m'a demandé le plus de travail invisible.

À chaque montée de version, un workflow GitHub Actions prend le relais. Un premier job, léger, lit la version et vérifie si la release existe déjà, pour ne pas republier deux fois. S'il faut publier, un second job compile l'application sur Windows, avec mise en cache des dépendances Rust pour ne pas tout recompiler à chaque fois, signe les binaires, génère l'installeur et publie la release automatiquement.

Le canal de mise à jour est branché dessus : l'application vérifie les nouvelles versions au démarrage et se met à jour toute seule, après avoir vérifié la signature du paquet. C'est ma première confrontation à une contrainte qu'on n'a pas sur le web : une fois l'application installée chez quelqu'un, on ne peut plus corriger à chaud. Sans canal de mise à jour signé, la moindre erreur reste sur la machine de l'utilisateur.

Le compagnon de gitlab-sync

CronLab et la synchro GitLab vers GitHub forment une paire : le second est un outil en ligne de commande fait pour être relancé régulièrement, le premier est ce qui le relance. Concrètement, une tâche CronLab exécute la synchro chaque jour et me prévient si elle échoue. C'est le cas d'usage qui a motivé le projet au départ, avant qu'il devienne un planificateur générique.

Ce que j'en retire

C'est mon passage à l'application de bureau : une autre façon de penser le cycle de vie du logiciel, où l'on ne maîtrise plus l'environnement d'exécution et où livrer passe par la signature et la distribution d'un binaire.

C'est aussi un des premiers projets que j'ai menés avec Claude Code, et le début d'un changement d'habitude. Avant, quand un outil me manquait, je me disais tant pis : je n'avais ni le temps ni toutes les compétences pour le construire. Là, je me suis mis à en fabriquer de plus en plus, simplement pour me faire gagner du temps. CronLab et la synchro GitLab sont les premiers de cette série. J'y consacrerai un article à part.