Sept agents IA font tourner nos nuits : des agents planifiés au-delà du code, avec les prompts

Le 23 septembre, un utilisateur prénommé Rob a écrit sur notre backlog public : « would love to get examples of how you guys are doing stuff beyond coding ». Bonne question. Tout ce site parle d'agents de code, et ce qu'on fait vraiment tourner chaque soir n'est, pour l'essentiel, pas du code.

Depuis le 28 août, sept agents démarrent sur un Mac mini à 20h00. Ils lisent les commits du jour, la Search Console, les tableaux d'administration, le backlog, les retours envoyés par les utilisateurs, les rapports de la nuit précédente. Ils corrigent des bugs, corrigent le site, écrivent et traduisent un article de blog tous les trois jours, publient sur trois réseaux sociaux, mettent à jour une base de connaissances produit, et à 22h00 le septième lit ce que les six autres ont laissé et envoie un e-mail de 25 lignes. Personne ne regarde. Le fondateur lit l'e-mail sur son téléphone le lendemain matin.

Cet article est la réponse à Rob. Ce qui tourne, comment c'est câblé, comment les agents se passent le travail sans jamais se parler, quel modèle fait quel métier et pourquoi, les quatre règles que leurs prompts ont dû apprendre à la dure, et les prompts eux-mêmes, condensés en blocs que tu peux copier. Chaque chiffre ci-dessous vient du dépôt : les rapports y sont commités, nuit après nuit.

Ce que 33 nuits ont produit

Le dossier des rapports du dépôt compte 33 répertoires datés, du 28 août au 30 septembre. Les lire donne ceci :

• 31 e-mails du matin envoyés par le rapporteur.
• 51 bugs corrigés par le correcteur, chacun avec le lien du commit sur sa ligne de rapport. Plusieurs avaient été signalés par des utilisateurs sur le backlog public et ont reçu une réponse à la version suivante.
• 7 articles de blog écrits par l'équipe SEO depuis le 10 septembre, un tous les trois jours, chacun d'abord en anglais et en français, puis dans 18 autres langues la même nuit.
• 29 jours de journal des réseaux sociaux : trois réseaux et cinq groupes Facebook par soir, plus un commentaire de remerciement sous chaque publication où un utilisateur a partagé AgentsRoom.
• Une base de connaissances produit d'une centaine de fiches, tenue à jour d'après les commits du jour, que l'assistant intégré lit et que le site sert en llms-full.txt.

Rien de tout ça n'a demandé un humain après 20h00. Une partie en a demandé un à 8h00, et c'est tout l'objet du dernier agent.

L'effectif : qui tourne à 20h00

Chaque agent est une Tâche planifiée dans AgentsRoom : un prompt, un agent (rôle, CLI, modèle), une machine et une heure. Les sept tournent sur Claude Code. Deux d'entre eux ne sont pas des agents seuls mais des équipes en deux étapes, et on y reviendra.

Les fichiers .md de la dernière colonne vivent tous dans reports/night/<date>/, commités et poussés. Ce dossier est tout le système de coordination, et la section suivante explique pourquoi.

Comment c'est câblé

Chacun des sept est une Tâche planifiée de la même forme :

• Part chaque jour à 20h00 (22h00 pour le rapporteur). Pas d'expression cron ; la fréquence se choisit dans l'éditeur.
• Épinglé sur une seule machine. Le projet est ouvert sur plusieurs ordinateurs, et un déclencheur part sur chaque machine qui l'a, sauf si tu le restreins. Les nôtres sont restreints au Mac mini, donc un portable ouvert à 20h05 ne démarre pas un second CEO.
• Réveille la machine. Le Mac mini dort. La tâche a une option « réveiller la machine », qui programme un réveil avec l'outil natif du système (pmset sur macOS, le Planificateur de tâches avec réveil sur Windows, rtcwake sur Linux) quelques secondes avant le run. Sans elle, une machine endormie manque simplement le run.
• Rattrapage activé ou non, par tâche. Si la machine était éteinte à 20h00, une tâche avec rattrapage part au prochain lancement. Le CEO, le PM et le rapporteur l'ont activé. Les tâches SEO, correcteur, social et documentaliste l'ont désactivé : un run qui démarrerait à 11h00 le lendemain entrerait en collision avec le travail de la journée dans le même checkout.
• Le mode de permission est réglé sur la tâche, pas sur le fournisseur. Un run sans surveillance ne peut pas s'arrêter sur une demande d'approbation à 3h du matin, donc la tâche tourne sans, tandis que les agents que le fondateur pilote à la main sur le même CLI demandent toujours d'abord.
• La console se ferme après 60 minutes d'inactivité. Un agent qui a fini ne reste pas dans la barre latérale jusqu'à ce que quelqu'un le ferme.
• Le prompt est le premier message. Le texte de chaque prompt est rangé dans la Bibliothèque de prompts et c'est le même texte que le champ prompt du déclencheur, donc modifier l'un, c'est modifier les deux. Les prompts sont en français, parce que le fondateur lit les rapports en français. Tout le reste, des messages de commit à la base de connaissances, est en anglais.

Une dernière pièce est partagée par les sept : un skill nommé « agents de nuit, règles communes ». Chaque prompt commence par « charge ce skill et applique-le », et le skill contient tout ce qui est vrai pour tous : qui possède quoi, la garde « une nuit, un run », les droits git, le format du rapport, les règles du backlog et le format de l'e-mail pour le rapporteur. Quand une règle change, elle change à un seul endroit.

Comment ils se passent le travail sans se parler

Les sept agents ne s'envoient jamais de message. Ils pourraient, AgentsRoom a une messagerie entre agents, mais un message est invisible le lendemain matin et ne se grep pas. Tout passe par trois choses qui survivent à la nuit :

Le dépôt. Chaque agent écrit reports/night/<date>/<agent>.md, l'ouvre dans la première minute de son run, le réécrit après chaque travail terminé, le commite et le pousse. Le rapport a quatre sections fixes : « En deux mots » (une liste à puces, une puce par chose faite), « À décider » (uniquement ce que le prompt réserve à l'humain), « À vérifier » (une URL locale ou un écran à ouvrir), « Détails » (aussi long que nécessaire). Il se termine par un repère de run : le dernier commit que l'agent a vu.

Le backlog. Un agent qui trouve du travail pour un autre ne fait pas ce travail. Il ouvre un ticket avec un tag : ceo-fix pour un bug vérifié et petit que le correcteur prendra ; ceo-seo pour un chantier de contenu avec sa requête cible ; ceo-decision pour tout ce qui demande l'humain (base de données, facturation, auth, chiffrement, prix, une URL indexée, un comportement par défaut). Le documentaliste, en lisant les commits, trouve une feature sans page sur le site : il ouvre un ticket ceo-seo, et le SEO le prend la nuit suivante. Le CEO, en lisant les journaux d'erreurs, trouve un bug avec sa cause dans le code : ceo-fix, et le correcteur le prend la nuit suivante.

Le rapport de la veille. Avant d'ouvrir le moindre chantier, chaque agent lit son propre rapport de la nuit précédente, plus la liste des tickets fermés pendant la journée. Ce qu'il a signalé hier a souvent été corrigé dans la journée. Un sujet déjà traité ne se remonte pas ; un ticket déjà ouvert ne se recrée pas.

La boucle se ferme avec l'humain. L'e-mail du rapporteur se termine par une ligne : pour répondre au product manager, ajoute une section « ## Décisions » à la fin de rapport.md (P1 OK / P2 NON : raison / P3 PLUS TARD), commit, push. Le PM lit la version poussée le soir suivant et exécute ce qui a été validé : il crée le ticket, fusionne les doublons, range le reste avec la raison. Une décision sans réponse pendant trois nuits est une décision : la proposition sort de l'e-mail et reste en ticket.

Quel modèle fait quel métier, et pourquoi

Le tableau plus haut montre deux modèles. C'est la configuration du moment, pas un banc d'essai, et elle bouge. Mais le découpage est voulu.

Fable là où le métier est le jugement. Le CEO décide si un pouce bas sur un oracle est une vraie erreur ou une préférence. Le correcteur décide si un rapport de bug est un bug ou une configuration propre à une machine, puis trouve la cause dans le code. L'étape 1 du SEO décide quelle phrase du site est devenue fausse avec le commit du jour, quel article écrire, et quelle page laisser tranquille. L'étape 1 du Social choisit le sujet du soir et écrit pour un public qui repère un texte généré en trois lignes. Ces prompts sont longs (celui du SEO fait environ 4 000 mots) et pleins de règles « tu décides, tu ne demandes pas » avec de courtes listes d'exceptions. C'est là que le modèle le plus fort mérite son coût.

Opus avec un contexte de 1M là où le métier est le volume. Traduire un article dans 18 langues avec des sous-agents, trois locales chacun, puis contrôler la fusion contre la référence française, c'est de la lecture et de l'écriture, beaucoup, avec les mêmes règles appliquées 18 fois. Le documentaliste lit une journée de diffs contre une centaine de fiches. Le PM lit un export de 8 Mo de conversations de sortie. Le rapporteur lit cinq rapports et recopie, il ne réfléchit pas. Un grand contexte et un coût au token plus bas comptent plus que le jugement, là.

Deux des sept sont donc des équipes d'agents de deux étapes, chaque étape étant un agent avec son propre modèle. L'étape 1 sur Fable termine en écrivant une section « Handoff » dans le rapport partagé : la liste exacte des fichiers et des clés que le traducteur doit livrer, ou les publications exactes que le publieur doit publier. L'étape 2 sur Opus lit cette section et ne fait que ce qu'elle liste. Le graphe de l'équipe est linéaire, un seul cycle, et le rapport garde sa ligne « run en cours » jusqu'à ce que l'étape 2 la retire. Vu de l'extérieur, à 22h00, un rapport encore marqué « en cours » veut dire soit un run coupé, soit une équipe entre ses deux étapes, et le rapporteur dit lequel.

Les quatre règles que les prompts ont dû apprendre

Les premiers prompts étaient des fiches de poste. Les actuels sont surtout des règles, et chaque règle a une date, parce que chacune a été écrite après une nuit qui a mal tourné.

1. Un repère de run, lu dans le rapport de la veille. La première version de l'agent SEO lisait « les commits des dernières 24 heures ». Deux problèmes : un run à 20h00 et un run à 20h10 le lendemain ne voient pas les mêmes 24 heures, et une nuit où l'agent n'a pas tourné est une journée de commits que personne ne regarde. Maintenant chaque rapport se termine par Dernier commit vu : <sha>, et le run suivant part de ce commit, quoi que dise l'horloge. Pas de repère (première nuit, rapport manquant) : deux jours en arrière, et le rapport le dit.

2. L'historique est sur le disque, donc grep-le avant de remonter quoi que ce soit. Le reproche revenu le plus souvent les deux premières semaines : « tu me l'as déjà dit, je l'ai corrigé hier ». La correction est une règle avec une commande dedans : avant de signaler un sujet ou d'ouvrir un chantier, grep -ril "<le sujet>" reports/night/ et git log --since="30 days ago" -- <le fichier>. Une correspondance veut dire lire ce rapport d'abord. Trois cas, et trois seulement, autorisent à reparler d'un sujet traité : le correctif n'a pas marché et tu viens de le vérifier ; le correctif est partiel et tu nommes ce qui reste ; le sujet a changé de nature. Deux corollaires sont venus avec. Une nuit, un run : si le rapport du soir existe, contient « En deux mots » et ne dit plus « run en cours », l'agent s'arrête. Et une proposition sans réponse pendant trois nuits sort du rapport ; le ticket reste.

3. Le rapport est ouvert avant que le travail commence. Un run coupé à 21h30 ne laissait rien. Maintenant, la première chose que fait un agent après avoir chargé le skill est mkdir -p reports/night/$(date +%F) et écrire le squelette du rapport avec ses quatre titres de section et une ligne run en cours, démarré à 20:01. Il réécrit le fichier entier après chaque chantier terminé. Un run coupé laisse un rapport partiel que le rapporteur peut recopier, ce qui vaut bien mieux qu'un agent qui « n'a pas tourné ».

4. Commiter au fil de l'eau, jamais à la fin. Mesuré le 9 septembre : deux agents ont été arrêtés à la même minute. Celui qui commitait après chaque chantier n'a rien perdu. L'autre a laissé 45 fichiers modifiés, non poussés et non attribuables, que le fondateur a ramassés à la main le lendemain matin, et son rapport n'existait pas. Depuis, la règle est un commit par chantier terminé, fichiers nommés un par un, un dernier commit pour le rapport, et au moins un push pendant le run. Un commit est aussi une trace datée, et c'est ce que la règle 2 grep.

Une cinquième règle ne parle pas de mémoire mais de courage, et c'est celle qui a le plus changé la production. Le prompt du SEO dit : « Tu n'es pas un auditeur qui remonte des constats : la nuit, le site t'appartient. Un run qui se termine par six pistes à valider est un run raté. » Puis il liste les six cas, et six seulement, où l'agent doit demander au lieu d'agir : supprimer ou renommer une URL, changer le titre d'une page qui ranke, un texte juridique, un prix ou un quota, une affirmation sur la vie privée ou le chiffrement, un changement qui toucherait plus de cinq pages. Tout le reste, il le fait, et le fondateur retire ce qui ne lui va pas le lendemain matin. Le correcteur a la même règle avec trois cas. Avant cette règle, les rapports étaient des listes de suggestions. Après, ce sont des listes de commits.

Les prompts

Les originaux sont en français et longs. Ce qui suit est la partie qui se transpose, avec nos chemins et nos noms propres au projet retirés. Trois blocs : les règles communes que chaque agent charge, le rapporteur, et les deux sections « tu décides, tu ne demandes pas ».

Bloc 1 : les règles communes (chargées par les sept comme un skill)

# Agents de nuit : règles communes
Elles priment sur ton propre prompt si les deux se contredisent.

## Une nuit, un run
DAY=$(date +%F); F=reports/night/$DAY/<toi>.md
Si F existe, contient « En deux mots » et ne contient plus « run en cours » :
arrête-toi. N'écris rien, n'envoie rien, termine par un message d'une ligne.
S'il dit encore « run en cours » : c'est ton propre run, coupé il y a quelques minutes.
Reprends là où il s'est arrêté, ne recommence pas du début.

## Ce que tu as le droit de faire
- Git : add <fichiers nommés>, commit, push de TON travail, au fil de l'eau.
  Jamais : add -A, commit -a, push --force, stash, reset, checkout, clean, nouvelle branche.
- Build : typecheck, lint, scripts de contrôle, un build local pour vérifier.
  Jamais : un script qui déploie ou publie.
- Backlog : créer un ticket, ajouter à un ticket, fermer un ticket que tu as corrigé.
  Jamais : répondre à un utilisateur (ça envoie un e-mail), supprimer un ticket, écraser une description.
- Jamais un chiffre inventé. Source indisponible : dis-le et passe.
- Avant toute écriture git : git status --short. L'arbre est partagé avec d'autres agents.

## Se mettre à jour, et savoir ce qui a DÉJÀ été fait
git fetch && git status -sb
En retard et propre : git pull --ff-only. En retard et sale : ne pull pas, dis-le en tête de ton rapport.
Ton repère de run : la ligne « Dernier commit vu : <sha> » à la fin du rapport de la veille.
Pas de repère : --since="2 days ago", et dis-le.
Trois lectures obligatoires avant toute analyse :
1. git log --no-merges --format='%h %s' <sha>..HEAD et git diff --stat <sha>..HEAD
2. les tickets fermés depuis hier, et les tickets qu'un humain a mis en attente
3. ton propre rapport de la veille : « En deux mots » et « À décider »

## Le dossier des rapports EST ton historique
Avant de remonter un constat ou d'ouvrir un chantier :
grep -ril "<sujet>" reports/night/ | sort | tail -5
git log --since="30 days ago" --oneline -- <le fichier>
Une correspondance : lis ce rapport avant de décider quoi que ce soit.
Deux nuits de suite sur le même sujet : c'est la deuxième qui est perdue.
Une page ou un texte que tu as touché ne se retouche pas avant trois semaines,
sauf pour corriger quelque chose devenu faux.

## On ne remonte jamais deux fois la même chose
Une remontée déjà traitée qui revient le lendemain est une faute.
Trois cas seulement l'autorisent :
1. le correctif n'a pas marché, et tu viens de le vérifier : « corrigé le <date> par <commit>, toujours cassé : <preuve> »
2. le correctif est partiel : nomme précisément ce qui reste
3. le sujet a changé de nature : nouvelle cause, nouvelle mesure, nouveau périmètre
Ne recompte pas un stock. Écris la variation, jamais le stock.

## Une proposition sans réponse s'éteint au bout de trois nuits
Nuits 1 à 3 : la ligne porte son compteur et sa date de première remontée (« 2e nuit, posée le 07/09 »).
À partir de la 4e : elle sort de « À décider ». Le ticket reste ; au plus une ligne dans « Détails ».
Si la décision t'appartient, tranche à la 3e nuit et dis-le.

## Commiter et pousser au fil de l'eau
Premier commit dès que le premier chantier est fini et vérifié. Puis un par chantier.
Dernier commit pour ton rapport. Pousse au moins une fois en cours de run et une fois à la fin.
Push refusé (la remote a avancé) : git pull --ff-only, puis push. Toujours refusé : ne force rien,
ne rebase rien, écris-le dans le rapport.

## Ton rapport : ouvert au début, jamais écrit seulement à la fin
reports/night/<YYYY-MM-DD>/<toi>.md, créé AVANT le travail, avec :
  # <Agent> - <date>
  _run en cours - démarré à <HH:MM>_   (retirée à la fin)
  ## En deux mots      (3 à 5 lignes, ou une liste à puces : une puce par chose faite)
  ## À décider         (uniquement ce que ton prompt réserve à l'humain ; sinon « Rien »)
  ## À vérifier        (- [ ] quoi : où : ce qu'on doit voir ; sinon « Rien »)
  ## Détails           (aussi long que nécessaire : preuves, fichiers, commandes)
  ## Repère de run
  Dernier commit vu : <git rev-parse HEAD après ton dernier commit>
Réécris le fichier entier après chaque chantier terminé.
Le lecteur est sur un téléphone, pendant deux minutes : phrases courtes, pas de chemin de fichier,
pas de SHA, pas de nom de fonction dans la première section. Un chiffre seulement s'il change une décision.

Bloc 2 : le rapporteur (22h00)

Tu es le rapporteur. Tu passes deux heures après les autres.
Ton seul travail : lire ce qu'ils ont laissé et envoyer UN e-mail que le fondateur lit
en une minute sur un téléphone, et qu'il comprend sans rien ouvrir d'autre.
Tu n'analyses rien, tu ne corriges rien, tu ne proposes rien. Tu rassembles et tu clarifies.

La nuit que tu rapportes se lit sur le disque, pas sur l'horloge :
DAY=$(ls -1 reports/night | sort | tail -1)

1. git fetch ; git pull --ff-only si l'arbre est propre : les rapports sont commités.
2. ls reports/night/$DAY : attends les cinq fichiers (ceo, seo, pm, fixer, social).
   Il en manque : sleep 9 minutes et recompte, 6 tours maximum. Puis envoie quand même, en nommant qui manque.
3. Un rapport qui dit encore « run en cours » est un run coupé, pas un run absent.
   Recopie ce qu'il contient et écris dans « Ce qui n'a pas marché » que cet agent a été coupé.
4. De chaque rapport, prends trois sections seulement : « En deux mots », « À décider », « À vérifier ».
   Ne cite jamais « Détails ».
5. Les bugs corrigés du correcteur sont des puces en trois parties séparées par « > » :
   ce que subissait l'utilisateur > la cause en une phrase > l'URL du commit.
   Recopie-les au caractère près, lien compris, dans « Bugs corrigés ».
6. git status -sb et git log --oneline --since="4 hours ago" : un rapport qui annonce
   un travail sans commit, des fichiers modifiés que personne ne revendique, ou des commits
   non poussés : première ligne de l'e-mail.

Écris reports/night/$DAY/rapport.md. 25 lignes de texte maximum
(les titres de section et les lignes de « Bugs corrigés » ne comptent pas).
Six règles, appliquées ligne par ligne :
1. Une puce = une phrase complète qui se comprend seule. Jamais « comme signalé hier ».
2. Un sujet n'apparaît que dans UNE section.
3. Zéro jargon : pas de chemin, pas de SHA, pas de nom de clé, pas d'abréviation interne.
   Une exception : l'URL GitHub complète d'un commit, obligatoire sur chaque ligne de « Bugs corrigés ».
4. Un chiffre seulement s'il change une décision, et c'est une variation, jamais un stock.
5. Deux lignes maximum par puce. Le détail est dans le rapport de l'agent.
6. Une mauvaise nouvelle avant une bonne, et la première ligne dit si quelque chose est cassé.

Sections, dans l'ordre : À décider / À vérifier / Bugs corrigés / Ce qui a été fait /
Réseaux sociaux (3 lignes max, liens compris) / CLI et modèles (1 ligne) /
Ce qui n'a pas marché. Une section vide tient en un mot : « Rien ».
Ne saute jamais : « À décider », « Bugs corrigés » avec les liens, les liens des publications, l'article du SEO.
Envoie. Vérifie le code HTTP. Ajoute « Envoyé à ... - HTTP <code> » en bas.
Commit et push de rapport.md. N'envoie jamais deux fois : si le rapport.md du jour
porte déjà une ligne « Envoyé à », arrête-toi.

Bloc 3 : les sections « tu décides, tu ne demandes pas »

L'agent SEO, section 0 de son prompt :

# 0. Tu décides, tu ne demandes pas
C'est la règle la plus importante de ce prompt et elle prime sur ton réflexe de prudence.
Tu n'es pas un auditeur qui remonte des constats : la nuit, le site t'appartient.
Un run qui se termine par « voici 6 pistes, à valider » est un run raté.
Quand tu hésites, mets-toi à la place du fondateur et tranche avec quatre repères :
- ce que le produit fait vraiment, lu dans le dépôt et dans la version publiée, jamais dans la copy existante ;
- ce que le site raconte déjà : son angle, son ton, ses promesses. Tu prolonges, tu ne réinventes pas ;
- ce que dit la Search Console : quelles pages vivent, quelles intentions existent réellement ;
- la cible : des développeurs qui cherchent sur Google, et les assistants IA qui recommandent des outils.
  Ce qui pèse pour eux : une affirmation vérifiable et datable ; une page qui répond à une question précise ;
  un llms.txt à jour et cohérent avec les pages ; des comparaisons honnêtes.
Le fondateur lit ton rapport le lendemain matin et te dira de retirer ce qui ne lui va pas.
Une correction en trop coûte cinq minutes ; une nuit sans production est perdue pour toujours.

Tu ne demandes son avis que dans ces six cas :
1. supprimer ou renommer une URL existante ;
2. changer le titre ou la meta description d'une page qui ranke alors qu'il n'est pas faux ;
3. un texte juridique (CGU, confidentialité, licence) ;
4. un prix, un quota commercial, une promesse d'offre ;
5. une affirmation sur la vie privée, le chiffrement ou l'endroit où tournent les données ;
6. une refonte qui toucherait plus de cinq pages d'un coup.
Dans ces six cas : un ticket tagué pour décision, une ligne dans « À décider », et tu passes à la suite.
Tout le reste, tu le fais ce soir. Si « À décider » contient autre chose,
tu as sous-traité une décision qui t'appartenait.

Le correcteur, section 0 de son prompt :

# 0. Tu corriges, tu ne classes pas
Un bug remonté par un utilisateur est une promesse. Quelqu'un a pris le temps d'écrire, il attend,
et personne d'autre ne va s'en occuper cette nuit. Un run qui rend « 5 bugs analysés, 1 corrigé,
4 documentés » est un run raté. Ton objectif est la file vide : les bugs des utilisateurs d'abord,
du plus ancien au plus récent, puis les autres, jusqu'à ce qu'il n'y en ait plus.
Quand tu hésites sur un correctif, tranche avec trois repères :
- ce que fait le code aujourd'hui, lu, pas supposé ;
- ce que l'utilisateur attendait manifestement quand il a écrit son rapport ;
- le moindre risque : le correctif le plus étroit qui règle la cause, pas le plus élégant.
Un correctif discutable coûte cinq minutes à annuler ; un bug laissé un mois de plus coûte un utilisateur.

Tu n'as le droit de laisser un bug remonté sans correctif que dans trois cas, prouvés dans le ticket :
1. tu n'as pas trouvé la cause après une vraie investigation : écris ce que tu as éliminé,
   pas seulement « pas reproductible » ;
2. ce n'est pas un bug, c'est une décision : base de données, facturation, auth, chiffrement, vie privée,
   une URL indexée, un comportement par défaut. Ticket pour décision, avec ta recommandation ;
3. un gate refuse ton correctif et tu ne sais pas le réparer.
« C'est gros », « ça touche plusieurs fichiers », « je préfère demander » ne sont pas des raisons.
Un bug = un commit. Puis le ticket passe en terminé, et si un utilisateur l'a signalé,
un message de deux phrases part avec la version suivante. Jamais « en attente » : cette colonne
appartient aux humains.
Ta ligne de rapport pour chaque bug corrigé, recopiée telle quelle dans l'e-mail du matin :
- <ce que subissait l'utilisateur> > <la cause, en une phrase simple> > <URL du commit>

Les quatre autres prompts (CEO, PM, documentaliste, étape 2 du SEO) suivent le même squelette : charge le skill, nomme les fichiers que tu as le droit d'écrire, liste les lectures dans l'ordre, dis ce qui va dans le ticket et ce qui va dans le rapport, termine par le repère de run.

Ce qui n'a pas marché, et ne marche toujours pas

Certaines nuits sont dans la section « Ce qui n'a pas marché » de l'e-mail, et elles valent la peine d'être listées parce que c'est ce que tu vas rencontrer.

• Cinq agents qui poussent sur la même branche à la même minute. Un push est refusé parce que la remote a avancé. La règle est git pull --ff-only puis push, jamais de force, et si ça échoue deux fois le rapport le dit et l'humain pousse le matin. Ça arrive environ une fois par semaine.
• Un commit qui a emporté un fichier stagé par un autre agent. Le 29 septembre, le premier commit du SEO a emporté une suppression que le documentaliste avait stagée dans le checkout partagé. Rien n'a été perdu (la suppression était voulue), mais le commit est attribué au mauvais agent. Depuis, chaque commit utilise des chemins explicites, et la règle « fichiers nommés un par un » n'est pas une préférence de style.
• Un disque tombé à zéro octet libre à 20h10, deux soirs de suite. Extérieur aux agents, revenu tout seul à 20h25, aucun fichier perdu. Mais les rapports le disent, parce qu'une nuit avec un disque plein ressemble exactement à une nuit où un agent n'a rien fait.
• Le rapporteur qui attend 54 minutes un rapport qui ne viendra pas. Six tours de neuf minutes, c'est le plafond. Une équipe entre ses deux étapes à 22h00 ressemble à un run coupé, et l'e-mail dit « n'avait pas fini », ce qui est honnête et légèrement inquiétant à lire.
• Les premières semaines de remontées répétées. La règle 2 ci-dessus n'existait pas avant que le fondateur écrive « tu me l'as dit il y a trois jours » pour la quatrième fois.

Comment monter ça chez toi

Tu n'as pas besoin de sept agents. Tu as besoin d'un seul qui écrit un rapport que tu liras, et un rapporteur n'est utile qu'à partir du troisième agent. Dans AgentsRoom :

1. Écris le prompt dans la Bibliothèque de prompts. Commence par le bloc 1 ci-dessus comme skill, et un prompt court qui dit ce que cet agent possède et quels fichiers il a le droit d'écrire.
2. Crée une Tâche planifiée sur le projet : chaque jour à l'heure que tu veux, le rôle, le CLI et le modèle de l'agent, le prompt, et dans le bloc avancé le mode de permission pour un run sans surveillance. Épingle-la sur la machine qui la fera tourner, et active « réveiller la machine » si cette machine dort.
3. Crée le dossier reports/night/ dans le dépôt et commite-le. C'est toute la couche de coordination.
4. Ajoute un deuxième agent le jour où le premier commence à produire des tickets pour quelqu'un d'autre : un tag ceo-fix ne veut dire quelque chose que si un correcteur le lit la nuit suivante.
5. Quand un métier se sépare en jugement et en volume, fais-en une équipe de deux étapes avec deux modèles, et fais écrire à l'étape 1 une section de handoff que l'étape 2 lit.

La page Tâches planifiées décrit les champs, et l'article sur les agents de code en équipe de nuit est le raisonnement qui a précédé l'effectif. Si tes agents partagent une machine, lis d'abord ce qui se passe quand dix d'entre eux lancent la même commande : c'est arrivé ici, la nuit, et le correctif est un petit verrou partagé.

Rob, voilà ce qu'on fait au-delà du code. Les prompts sont le produit.

Questions fréquentes

Faut-il AgentsRoom pour lancer des agents à heure fixe comme ça ?

Non. Une ligne de cron et claude -p démarrent une session Claude Code à 20h00 sur n'importe quelle machine. Ce que tu écris ensuite toi-même, c'est le reste : réveiller un ordinateur endormi, rattraper un run que la machine a manqué, garder un seul run par nuit quand le projet est ouvert sur deux ordinateurs, passer un rapport d'un agent à un second sur un autre modèle, et voir sur ton téléphone que le run est bloqué sur une question. Les Tâches planifiées d'AgentsRoom portent ces pièces, et les sept agents de cet article les utilisent toutes. Les prompts et les règles se transposent tels quels, quel que soit ce qui démarre la session.

Combien coûte une nuit de sept agents ?

Ils tournent comme des sessions Claude Code sur un abonnement Claude, comme n'importe quel agent lancé dans AgentsRoom, donc il n'y a pas de facture au token pour eux, et nous n'avons pas publié de coût par nuit. La règle qui le borne est la garde « une nuit, un run » : un déclencheur qui part deux fois, ou un run coupé puis relancé, ne refait pas le travail, parce que la première chose que fait chaque agent est de vérifier si le rapport du soir existe déjà et s'il est clos.

Est-ce prudent de laisser des agents commiter et pousser sans personne devant ?

C'est prudent à cause de ce qu'ils n'ont pas le droit de faire, pas à cause de ce qu'on leur demande de vouloir. Les règles communes interdisent git add -A, commit -a, le push forcé, stash, reset, checkout, clean, la création de branche et tout script qui déploie. Chaque commit nomme ses fichiers un par un, l'arbre est inspecté avec git status avant toute écriture, et un push refusé parce que le dépôt distant a avancé se règle par un pull en fast-forward ou se laisse à l'humain. La relecture du matin, c'est la liste des commits de la nuit, et ce qui ne va pas est un revert de cinq minutes.

Pourquoi les agents écrivent-ils des rapports Markdown dans le dépôt plutôt qu'un tableau de bord ?

Parce que le rapport est aussi la mémoire. Chaque agent commence par lire son propre rapport de la veille, y trouve son repère de run (le dernier commit qu'il a vu), et fait un grep sur tout le dossier des rapports avant de remonter quoi que ce soit, donc un sujet traité la semaine dernière n'est pas remonté une deuxième fois. Un tableau de bord montrerait les mêmes chiffres et ne se souviendrait de rien. Commiter le rapport le date aussi, et c'est ce qui permet à la nuit suivante de savoir exactement ce que la précédente a touché.

Pourquoi deux des sept agents sont-ils des équipes de deux étapes sur deux modèles différents ?

Parce que les deux moitiés du travail ne sont pas le même travail. L'étape SEO qui lit la Search Console, décide ce qui est faux sur le site et écrit l'article en anglais et en français demande du jugement, et tourne sur Fable. Traduire cet article dans 18 autres langues, passer les gates i18n et le build, c'est du volume, et ça tourne sur Opus avec un contexte de 1M. La première étape écrit une section de handoff explicite dans le rapport partagé, la seconde ne fait que ce que cette section liste. Même découpage pour l'équipe Social : rédaction et visuel sur Fable, publication dans Chrome et remerciements sur Opus.

Que se passe-t-il quand un run est coupé en plein milieu ?

Le rapport existe dès la première minute du run, avec une ligne qui dit « run en cours », et chaque travail terminé est commité sur-le-champ. Donc un run coupé à 21h40 laisse un rapport partiel, ses commits, et aucun fichier non suivi. Le rapporteur recopie le rapport partiel et écrit que l'agent a été coupé. On l'a appris à nos dépens le 9 septembre : deux agents se sont arrêtés à la même minute, celui qui commitait au fil de l'eau n'a rien perdu, l'autre a laissé 45 fichiers modifiés que personne ne pouvait attribuer.