Configurer des crons pour faire travailler son IA pendant qu'on dort
Votre IA travaille quand vous êtes devant l'écran, et plus du tout quand vous le quittez : la veille du matin, le tri des notes, le rapport récurrent, tout vous attend encore au réveil. Et le jour où vous tentez un cron à la main, le piège se referme : un cron mal écrit échoue en silence, pas de message, pas de trace, et vous découvrez la panne des jours plus tard.
Cette masterclass vous donne la méthode pour planifier des tâches automatiques sur votre serveur, dont au moins une qui fait travailler Claude Code pendant que vous dormez : un tableau qui décrit la tâche, un script qui laisse des traces, une borne stricte sur l'IA, puis une ligne de crontab. Et une règle d'or : rien ne se planifie sans avoir réussi une fois sous vos yeux.
Ce que cet exercice ne peut pas casser
Rien ne se planifie avant d'avoir été testé à la main, sous vos yeux. Un script qui échoue à ce stade ne casse rien : il se corrige et se relance. Et la borne posée sur la tâche IA garantit qu'aucune boucle ne tournera dans votre dos et que votre budget ne s'envolera pas pendant la nuit.
Ce que vous saurez faire à la fin
- Décrire une tâche automatisable en trois colonnes : la tâche, la fréquence, la sortie attendue.
- Exiger d'un script cron qu'il laisse des traces : log daté, erreurs capturées, clé API hors du code.
- Confier une tâche bornée à Claude Code en mode non interactif, sans risque de boucle ni de dépassement de budget.
- Tester chaque script à la main avant de le confier au crontab.
- Niveau membre· le prompt prêt à coller qui transforme votre tableau en scripts bash commentés, lignes de crontab et tests manuels, ou qui vous interviewe point par point si vous partez de zéro.
- Niveau Pro· je monte votre premier cron avec vous, en direct sur votre serveur, jusqu'au matin où le travail est déjà fait à votre réveil.
Cinq étapes, et une règle d'or : le test manuel passe toujours avant la planification.
Décrire avant de coder, tester avant de planifier
Un cron mal écrit échoue en silence : il ne vous prévient pas, il ne laisse rien, il vous laisse croire que le travail se fait. Toute la méthode découle de cette menace. On décrit la tâche avant d'écrire la moindre ligne, on force le script à laisser des traces, on borne ce qu'on confie à l'IA, et on ne planifie jamais rien qui n'ait pas réussi une fois sous nos yeux.
1Posez le tableau : tâche, fréquence, sortie attenduedoute : « par où commencer ? »
Tout part de trois colonnes : la tâche en une phrase, la fréquence exacte, et la sortie attendue, c'est à dire ce que vous voulez trouver au réveil. Ajoutez le chemin de votre vault ou de vos fichiers sur le serveur, l'horaire souhaité et, pour une tâche IA, l'instruction exacte à confier. Sans cette matière, on n'écrit rien : ce qui manque se demande, ne s'invente jamais.
2Écrivez un script bash qui laisse des tracesdoute : « comment saurai-je si ça a tourné ? »
Chaque tâche devient un script bash complet et commenté : un en-tête qui dit ce qu'il fait, la création d'un dossier de logs, puis la redirection de la sortie et des erreurs vers un fichier log daté, avant la commande finale. C'est ce log qui rend la panne visible : sans lui, le cron échoue en silence et vous ne le saurez jamais.
3Bornez la tâche qui fait travailler l'IAdoute : « et si l'IA tourne en boucle toute la nuit ? »
Pour la tâche qui mobilise Claude Code, la commande s'écrit en mode non interactif : une instruction courte et précise, et une borne stricte sur le nombre d'échanges. Cette borne est votre garde-fou : elle empêche toute boucle et tout dépassement de budget pendant que vous dormez.
4Protégez vos clés dans un fichier d'environnementdoute : « où mettre la clé API ? »
Si la tâche a besoin d'une clé API, elle vit dans un fichier d'environnement protégé, lisible par le seul propriétaire, chargé en tête du script. Jamais en clair dans le code : un script se relit, se partage, se versionne, une clé exposée finit toujours par fuiter.
5Traduisez la fréquence en ligne de crontabdoute : « que veulent dire ces cinq champs ? »
Le crontab parle en cinq champs : minute, heure, jour du mois, mois, jour de la semaine. Chaque ligne se commente en français au dessus, pour que la fréquence reste lisible dans six mois. Une ligne par tâche, et la traduction en clair de ce qu'elle fait.
6Testez à la main avant de planifierdoute : « comment être sûr que ça marchera cette nuit ? »
Avant de toucher au crontab, chaque script se lance à la main, avec la commande exacte, et vous vérifiez la sortie attendue : le log existe, le résultat est là. Un script qui n'a pas réussi sous vos yeux n'a rien à faire dans un planificateur. C'est la règle d'or de toute la méthode.
À vous de jouer : votre tableau de cron
Prenez une feuille ou une note. Vous allez produire la matière exacte que le prompt vous demandera.
Le résultat, en 30 secondes
À partir de votre seul tableau, le prompt livre, pour chaque tâche : le script bash complet et commenté, le test manuel avec la sortie attendue, puis la ligne de crontab commentée en français. Et à la fin, le récapitulatif des variables d'environnement à définir et les questions encore ouvertes.
Script suggéré : veille-matin.sh, avec en-tête commenté, création du dossier de logs et redirection des erreurs vers un log daté. Test manuel : lancer le script à la main et vérifier que la synthèse apparaît dans le log du jour. Crontab : la ligne 0 6 * * *, commentée « tous les jours à 6 heures », à ajouter seulement une fois le test réussi.
Le prompt prêt à coller
# RÔLE Vous êtes un ingénieur système senior, spécialiste de l'automatisation de tâches sur serveur Linux et de l'usage de Claude Code en mode non interactif. Vous êtes rigoureux et prudent : un cron mal écrit échoue en silence, donc vous ne livrez que du code que vous avez vérifié. Vous ne vous appuyez QUE sur ce que je vous donne. Si une information manque (chemin du serveur, fréquence exacte, sortie attendue), vous me la demandez, vous ne l'inventez jamais. # CONTEXTE Je veux planifier une ou plusieurs tâches automatiques sur mon serveur, dont au moins une qui fait travailler Claude Code. Je dispose d'un serveur Linux avec Claude Code déjà authentifié, et mon vault ou mes fichiers de travail synchronisés dessus. Ma matière (si j'en ai) : [collez ici votre tableau tâche / fréquence / sortie attendue, et tout détail utile : chemin du vault, horaires souhaités, instruction exacte à confier à l'IA].
Le prompt transforme votre tableau en scripts bash commentés, lignes de crontab traduites en clair et test manuel pour chaque tâche, clés API protégées comprises. Pas encore de tableau ? Il passe en mode interview et vous questionne point par point. Laissez votre email, je vous l'envoie.
Vérifiez que c'est à vous
Vous venez d'écrire le script qui fait travailler Claude Code chaque nuit sur votre vault. Il a l'air parfait. Que faites-vous juste avant de l'ajouter au crontab ?
D'abord avec vos mots, sans regarder les options :
Expliquez-le pour l'ancrer
Expliquez en une phrase, à un confrère qui découvre les crons : pourquoi lancer le script à la main avant de l'ajouter au crontab ? Si la réponse vous vient sans réfléchir, c'est acquis.
Ce que vous savez faire maintenant
- Formuler n'importe quelle tâche répétitive en tableau prêt à automatiser : tâche, fréquence, sortie attendue.
- Reconnaître un script cron sain : log daté, clé API hors du code, borne stricte sur la tâche IA.
- Ne plus jamais planifier un script qui n'a pas réussi son test manuel.
Un cron mal écrit échoue en silence : ne planifiez jamais un script que vous n'avez pas vu réussir à la main.
Faites-le avec moi
Je monte vos crons avec vous, en direct sur votre serveur : scripts, logs, bornes, crontab. Vous repartez avec une machine qui travaille la nuit, et la certitude qu'elle vous préviendra si elle tombe.