Monter un agent autonome qui publie le contenu de ton app, sur un mac qui traîne

Un pote m’a demandé comment je faisais tourner mes agents. J’ai répondu en quatorze minutes de messages. À la fin, j’ai relu, et c’était illisible.

Le problème, c’est que je n’ai jamais écrit la procédure. Je la refais à chaque fois de mémoire, dans un ordre que je reconstitue au moment où j’en ai besoin. Alors la voici en entier, dans l’ordre, avec les deux règles qui comptent vraiment à la fin.

D’abord, un aveu

Je suis une brêle en VPS. Tout ce que je décris ici tourne en local, sur un mac que je n’utilise plus beaucoup. Pas de conteneur, pas d’orchestrateur, pas de cloud.

Ça a l’air d’un défaut. C’est surtout la raison pour laquelle je peux en parler : si ça marche sur une machine qui traîne, la barrière n’est pas l’infrastructure. Elle est ailleurs, et j’y viens.

Le matériel

Un ordinateur que tu n’utilises pas trop. Un mac fait très bien l’affaire, un VPS aussi si tu sais t’en servir. Un terminal. C’est tout.

Ce qui suit se pilote en langage naturel, avec Claude Code. Tu ne vas pas écrire de script d’installation.

Étape 1 : le socle

Tu ouvres un terminal sur la machine dormante, tu lances Claude Code, et tu lui dis :

installe la dernière version de Hermes avec un home path ~/Tech/auto-content-evolum/, fais un git init propre dedans, et pousse sur un dépôt privé

Il se débrouille. C’est exactement le genre de tâche pour laquelle il est bon : beaucoup d’étapes, aucune décision.

Puis tu vas vérifier sur GitHub que tout y est. Cette étape a l’air d’une formalité, elle n’en est pas une. Un socle que tu ne peux pas re-cloner ailleurs n’est pas un socle, c’est un poste de travail. Le jour où la machine meurt, tu veux repartir d’un clone, pas d’un souvenir.

Étape 2 : le contexte de marque

Tu lances un deuxième Claude Code, dans ~/Tech/, et tu lui fais cloner le dépôt de l’app elle-même. Pour Evolum, c’est evolum_app/.

Pourquoi le dépôt de l’app alors qu’on parle de contenu ? Parce qu’il contient le branding, la direction artistique et la landing page.

C’est le point que personne ne voit passer, et c’est le plus important de toute la procédure :

Ta capacité de contenu ne part pas d’un prompt de ton. Elle part du dépôt produit.

Un agent à qui tu écris « écris avec un ton chaleureux et expert » invente une marque. Un agent qui lit ta landing page, tes couleurs, tes captures de store et tes textes existants n’a rien à inventer. La différence de qualité entre les deux n’est pas marginale, elle est totale.

Pour l’accès, tu génères un personal access token à portée restreinte. Il ne va ni dans un commit, ni dans un message.

Étape 3 : le setup interactif

À un moment, l’installeur te dit qu’il est en interface interactive et il attend des réponses. Ce n’est pas un plantage.

Tu ouvres un nouveau terminal, tu réponds aux questions, et tu reviens sur le premier. C’est le seul passage de la procédure qui n’est pas automatisable de bout en bout, et il dure deux minutes.

Étape 4 : Telegram

Retour sur le premier agent. Tu lui demandes :

démarre Telegram, donne-moi le gateway, et donne-moi toutes les étapes

Au bout, tu as un bot Telegram relié à ton agent. Tu peux lui parler depuis ton téléphone, en texte ou en vocal.

C’est le moment où ça devient concret, et c’est aussi le moment où la plupart des gens font l’erreur que je décris plus bas. Garde en tête cette phrase : ce que tu viens de brancher, c’est une télécommande. Pas un atelier.

Étape 5 : le cron du matin

crée un cron chaque matin qui exécute ce qu’il y a dans auto-content-evolum/

Dans ce dossier, tu poses un AGENTS.md qui déclare ce que l’agent a le droit d’utiliser : les skills, les scripts, le browser, les API externes. Si tu lui demandes de s’en servir avant qu’il existe, il te répondra qu’il n’existe pas et te proposera de l’initialiser. Accepte, puis relis ce qu’il a écrit. C’est le fichier qui définit son périmètre, tu ne le laisses pas se l’écrire tout seul sans le lire.

À partir de là, la machine se réveille toute seule le matin.

Étape 6 : construire la capacité, à la main

C’est la dernière étape et c’est la seule où tu construis vraiment quelque chose.

Tu te mets dans le dossier, et tu dis :

je veux créer du contenu pour Evolum en utilisant Google AI Studio (la clé API va dans un .env gitignoré) et une API de publication cross-plateforme

Pour la publication, j’utilise upload-post, qui expose sa documentation en llm.txt (docs.upload-post.com/llm.txt), donc l’agent la lit directement au lieu que tu la recopies.

Et là, vous construisez la chose ensemble. Tu ne délègues pas cette étape. C’est ce qui m’amène aux deux règles.

Règle 1 : depuis Telegram, tu ne crées rien

La règle que je m’applique, et la seule qui a tenu dans le temps :

Depuis Telegram, tu ne crées rien. Tu modifies seulement des fichiers .md ou du code. Pour créer, tu vas à l’ordinateur, avec une architecture. Si c’est une app, avec un SDD.

Le téléphone modifie. L’ordinateur crée.

Ce n’est pas une question de confiance dans le modèle. C’est que créer, c’est poser une structure dont tout le reste va hériter, et qu’une structure posée sans architecture est une dette que tu ne verras que le jour où elle te coûte. Modifier, c’est réversible, et ça se relit en diff.

Le vrai intérêt de cette formulation, c’est qu’elle est vérifiable de l’extérieur. Une règle écrite dans un prompt est une intention : elle se dilue au fil du contexte et personne ne peut constater qu’elle a été respectée. Un canal, si. Tu regardes par où est passée la demande et tu sais quelle autorisation s’applique.

Et surtout, elle survit à la fatigue. À 23 h, sur un téléphone, tu ne te demandes pas si ta demande est raisonnable. Tu constates juste qu’elle passe par le mauvais canal.

Règle 2 : un garde-fou par type de sortie

Le conseil que je donnerais à quelqu’un qui démarre, et je le donnerais avant tout le reste :

Sois le plus déterministe possible. Pour chaque type de retour d’IA, garde un garde-fou. Templatise la structure, fais varier les combinaisons.

La structure est fixe et testable : le gabarit, les champs, les longueurs, le format. La variation vit dans les combinaisons : quel angle, quelle preuve, dans quel ordre.

Une sortie qui varie dans sa structure n’est pas créative, elle est invérifiable. Tu ne peux pas écrire un test contre « du bon contenu ». Tu peux en écrire un contre un gabarit.

Et un garde-fou, ça rejette. S’il se contente de signaler, ce n’est pas un garde-fou, c’est un log. Un log que personne ne lit ne protège de rien.

Pourquoi j’insiste : le relevé Faros sur des équipes réelles montre des demandes de fusion de code en hausse de 98 %, mais aussi des incidents par demande en hausse de 242,7 %, des bugs par développeur en hausse de 54 %, une charge de revue en hausse de 441 %, et des métriques de livraison finales plates.

Traduit pour ce qu’on est en train de monter : une machine qui produit sans garde-fou ne te fait pas gagner du temps, elle te fabrique du volume à vérifier à la main. C’est exactement l’inverse de ce que tu cherchais.

Ce que je ne sais pas encore

Cette procédure marche, elle tourne, et je ne l’ai jamais présentée comme finie.

Ce qui lui manque, c’est un inventaire honnête de ce qu’elle a cassé. Une capacité dont personne ne peut citer le raté n’est pas fiable, elle est simplement mal regardée. Je tiens ce relevé maintenant, et c’est probablement le prochain article.

En attendant, si tu montes la tienne : commence par la règle 1. Tout le reste s’installe en une soirée, mais c’est elle qui décide si dans six mois tu as une capacité ou un tas de fichiers que personne n’ose toucher.