Claude sur un Mac Mini : transformer le produit Apple le plus abordable en un assistant automatisé

La plupart des automatisations meurent de la même façon. Quelqu'un construit un truc astucieux, le lance une fois dans une fenêtre de chat, ferme son ordinateur pour aller dîner, et tout s'évapore. Le script n'a jamais été le maillon faible. L'ordinateur portable l'était. Il devait rester ouvert, branché, allumé, pour que le travail continue – et les laptops sont conçus pour faire exactement l'inverse.

Un Mac mini n'a pas ce problème. Il coûte environ 599 € en configuration de base, consomme moins d'électricité qu'une lampe de bureau, ne fait aucun bruit notable, et a exactement une mission : rester allumé. Ce seul trait est la raison pour laquelle il est devenu la machine à qui les gens confient discrètement leurs workflows Claude.

Cet article parcourt trois de ces workflows – une boîte de réception qui se trie elle-même, des pull requests qui sont révisées pendant la nuit, et un calendrier qui vous remet un briefing plutôt qu'un simple titre de réunion – le tout tournant sur un mini posé quelque part dans une maison, faisant un travail que personne n'a à se rappeler de lancer.

Pourquoi ne pas simplement utiliser le chat Claude pour ça ?

Vous pouvez déjà coller un e-mail dans Claude et lui demander de rédiger une réponse. Vous pouvez déjà coller un diff et demander une relecture. Rien dans cet article ne nécessite une capacité qui n'existe pas déjà dans la fenêtre de chat.

Ce qui change, c'est qui appuie sur le bouton.

Dans le chat, vous êtes le déclencheur, à chaque fois. Vous ouvrez l'onglet, vous collez le contenu, vous lisez la réponse, vous la copiez quelque part. Dès que vous arrêtez de le faire, le processus s'arrête. C'est un outil qui ne bouge que lorsque votre main est dessus.

Sur le mini, le déclencheur est une horloge, ou un webhook, ou un nouveau fichier qui atterrit dans un dossier. Claude fait le travail, vérifie sa propre production par rapport à une règle que vous avez écrite à l'avance, et soit l'expédie, soit réessaie – sans que personne ait à ouvrir un ordinateur portable. C'est toute la différence entre « un modèle que j'utilise » et « un système qui tourne ».

Ce qui se trouve réellement sur le bureau

Trois couches, et aucune n'est exotique :

La machine. Un Mac mini qui exécute des jobs launchd (le cousin mieux élevé de cron sur macOS) qui lancent des scripts Python selon un planning ou en réponse à un changement de fichier. N'importe quel petit PC toujours allumé ferait le même travail – le mini est juste silencieux, peu coûteux à faire tourner, et assez petit pour disparaître derrière un écran.

Le stockage. Des dossiers et des fichiers Markdown standards, plus tout ce que le workflow touche directement – une boîte de réception via IMAP, un dépôt GitHub cloné localement, un calendrier synchronisé avec un flux .ics. Rien ne vit derrière l'application de quelqu'un d'autre. Si le mini disparaissait demain, chaque fichier qu'il a produit s'ouvrirait normalement sur n'importe quel ordinateur.

Le raisonnement. Claude, appelé via l'API. Sonnet gère tout ce qui nécessite un véritable jugement – décider si une pull request peut être fusionnée sans risque, rédiger une réponse qui vous ressemble. Haiku gère le travail à fort volume et bon marché – trier, étiqueter, vérifier oui/non. Diviser le travail de cette façon explique pourquoi la facture mensuelle reste inférieure au prix d'un abonnement à un café.

Maintenant les workflows réels.

Routine n°1 : la boîte de réception vidée du bruit avant que vous la consultiez

La plupart des boîtes de réception ne sont pas pleines de décisions difficiles. Elles sont pleines de choses qui n'ont pas besoin de vous du tout – une newsletter, une confirmation de calendrier, un fournisseur qui pose une question que vous avez déjà répondue cinquante fois. La partie difficile n'est pas d'y répondre. Ce sont les vingt secondes d'attention que chacune vole avant même que vous décidiez quoi en faire.

1EXÉCUTER À : toutes les 15 minutes, en semaine
2SURVEILLER : nouveaux courriels dans la boîte de réception principale
3
4ÉTAPES :
5  1. Récupérer les 10 derniers messages du même fil pour le contexte
6  2. Claude classe le nouveau message :
7       - routine (confirmations, newsletters, réponses automatiques)
8       - nécessite une réponse (une vraie question, une demande)
9       - nécessite une décision humaine (argent, conflit, ambiguïté)
10  3. Routine  -> archivé automatiquement, enregistré dans un résumé quotidien
11     Nécessite réponse -> Claude rédige une réponse dans votre ton, sauvegardée dans les brouillons,
12                          jamais envoyée sans que vous l'ouvriez
13     Nécessite humain -> laissé intact, signalé, aucune tentative de brouillon
14
15VÉRIFICATION : la classification doit inclure une raison d'une ligne. Si Claude
16               ne peut pas produire une raison qui se réfère au contenu réel du message,
17               l'élément tombe dans « nécessite humain » par défaut.
18ARRÊT : chaque message du lot a été trié, ou 3 tentatives
19         sur un même message avant qu'il ne soit signalé directement pour moi.

La règle importante ici est le repli. Tout ce que Claude ne peut pas classer avec confiance n'est pas deviné – il atterrit dans vos mains exactement comme il l'aurait fait de toute façon. Le workflow n'essaie pas de remplacer le jugement sur les 10 % difficiles. Il essaie d'arrêter de voler votre attention sur les 90 % faciles.

Routine n°2 : les pull requests reçoivent une première passe avant votre réveil

La revue de code a un mode d'échec étrange : la revue la plus importante – celle sur la PR arrivée à 23h – est la plus susceptible d'être bâclée à moitié endormie, ou pire, fusionnée avec un « je regarderai demain » qui n'arrive jamais.

1EXÉCUTER À : à chaque nouvelle pull request, via un webhook GitHub
2
3ÉTAPES :
4  1. Récupérer le diff et le ticket lié, s'il existe
5  2. Claude examine selon une grille fixe :
6       - est-ce que cela correspond au périmètre réel du ticket lié ?
7       - un changement dans l'authentification, les paiements ou les migrations ? (signaler, ne pas juger)
8       - couverture de test sur les lignes modifiées – présente ou absente ?
9       - nommage et structure cohérents avec le reste du fichier ?
10  3. Commentaire posté directement sur la PR, noté 1-5 par élément de la grille,
11     avec les deux points les plus faibles explicitement mentionnés
12
13VÉRIFICATION : un commentaire n'est posté que s'il cite des numéros de ligne spécifiques.
14               Une revue sans référence de ligne est rejetée et réessayée –
15               un feedback vague ne vaut pas la peine d'être envoyé.
16ARRÊT : commentaire posté, ou après 2 tentatives, la PR est laissée tranquille
17         avec une note indiquant que la revue automatisée n'a pas pu être complétée.

Rien ici ne fusionne quoi que ce soit. C'est une deuxième paire d'yeux qui ne se fatigue jamais, qui se pose sur vos PR avant que votre première paire d'yeux réelle ne le fasse. La notation selon une grille fixe est ce qui la rend utile – un modèle à qui on demande « révise ce code » de manière libre a tendance soit à tout louer, soit à pinailler au hasard. Un modèle noté sur quatre questions fixes produit le même type de feedback à chaque fois, ce qui le rend précisément digne d'être lu à 8h du matin.

Routine n°3 : les réunions arrivent avec un briefing, pas seulement un titre

Une invitation de calendrier vous dit quand et où. Elle ne vous dit presque jamais ce que vous avez réellement besoin de vous rappeler avant d'entrer – le dernier fil d'e-mail avec cette personne, l'élément en suspens de la réunion précédente, le chiffre que quelqu'un va demander.

1EXÉCUTER À : 45 minutes avant chaque événement de calendrier avec 2 participants ou plus
2
3ÉTAPES :
4  1. Récupérer le dernier fil d'e-mail et tout document partagé lié à
5     un nom de participant ou au titre de l'événement
6  2. Claude rédige un briefing d'une page :
7       - ce qui a été convenu la dernière fois, le cas échéant
8       - une question ouverte qui mérite d'être soulevée
9       - tout chiffre ou date mentionné dans le dernier échange
10  3. Livré comme notification push 30 minutes avant l'événement
11
12VÉRIFICATION : le briefing doit se référer à un message ou document antérieur réel.
13               Aucun contexte antérieur trouvé -> la notification dit
14               « aucun historique trouvé », pas un résumé fabriqué.
15ARRÊT : envoyé, ou ignoré complètement si les participants sont nouveaux.

Cette dernière vérification est celle qui mérite qu'on s'y attarde. Il serait facile pour Claude d'écrire un briefing plausible à partir de rien quand il ne trouve pas de contexte réel – et un faux plausible est pire qu'aucun briefing, car vous lui feriez confiance. Forcer un honnête « rien trouvé » est ce qui rend les briefings qui arrivent dignes d'être lus.

Les deux règles sur lesquelles tout ce qui précède repose

Enlevez les spécificités et chaque routine ici repose sur les mêmes deux garde-fous.

Une règle vérifiable, pas une impression. « Classe cet e-mail » est une impression. « Classe cet e-mail, et si tu ne peux pas citer la phrase qui justifie l'étiquette, tombe par défaut dans la catégorie sécurisée » est une règle. La différence est de savoir si Claude évalue son propre travail par rapport à quelque chose de spécifique, ou s'il produit simplement quelque chose qui semble fini.

Une vraie condition d'arrêt. Chaque routine ci-dessus a une limite d'essais dure et un repli défini pour ce qui se passe quand elle ne peut pas faire le travail proprement. Sans cela, un seul e-mail mal formé ou une PR avec un diff cassé brûlera joyeusement des appels API dans une boucle de réessai toute la nuit, et la facture arrive avant le rapport de bug.

Obtenez ces deux choses correctement et la tâche spécifique importe peu – boîte de réception, code, calendrier, ou autre chose.

Testez-le à la main avant de le construire

Rien de tout cela ne nécessite de toucher à un terminal pour commencer. Vous pouvez exécuter la même forme dans une conversation Claude normale et voir si elle vous est réellement utile avant d'automatiser quoi que ce soit :

1Vous allez travailler sur cette tâche par passes, en vérifiant votre
2propre production avant de la déclarer terminée.
3
4TÂCHE :
5[la chose que vous voulez traiter]
6
7RÈGLE DE PASSE :
8- Faites le travail.
9- Vérifiez-le par rapport à : [la condition spécifique et vérifiable]
10- Si ça échoue à la vérification, dites ce qui ne va pas et refaites juste cette partie.
11- Si ça passe, dites « terminé » et arrêtez-vous.
12- Ne me demandez jamais de question de clarification – faites l'hypothèse
13  la plus raisonnable, énoncez-la en une ligne, et continuez.
14
15Commencez.

C'est tout le mécanisme en miniature. Pas de mini, pas de webhook, pas de planning – juste Claude qui vérifie son propre travail par rapport à une règle au lieu de s'arrêter au premier brouillon plausible. Si vous exécutez cela à la main trois ou quatre fois sur le même genre de tâche et que vous y revenez, c'est le signal qu'il vaut la peine de le mettre sur une machine qui n'a pas besoin de vous pour se souvenir de l'exécuter.

L'ordre qui empêche tout cela de casser à 2h du matin

Personne ne lance ces automatismes de manière fiable en commençant par écrire le cron job. L'ordre qui tient vraiment :

1. Exécutez-le à la main dans le chat jusqu'à ce que la production soit systématiquement correcte.
2. Transformez cette invite exacte en script – sans aucun changement à la logique.
3. Ajoutez la vérification et la limite de tentatives avant toute autre chose.
4. Ce n'est qu'ensuite que vous le branchez à un planning ou à un webhook.

Sautez directement à l'étape quatre et vous découvrirez ce que « pas de condition d'arrêt » vous coûte de la manière la plus dure, généralement un matin plein de commentaires de PR en double ou une centaine de brouillons identiques dans votre dossier Envoyés.

Ce que cela vous apporte réellement

Rien de tout cela ne rend Claude plus intelligent. Cela fait la différence entre quelque chose que vous utilisez et quelque chose qui fonctionne, que vous soyez attentif ou non. Le mini n'est pas la partie intéressante – c'est juste le moyen le moins cher et le plus silencieux de donner à un workflow une machine qui n'a jamais besoin d'être rouverte.

Commencez par la version manuelle dans cet article. Si vous vous surprenez à l'exécuter plus de deux fois à la main, c'est celle qui mérite d'être mise sur une boîte qui reste allumée après que vous soyez allé au lit.

Merci d'avoir lu cet article

Créateur : @0xclayn**

Sauvegarder ceci