Lundi matin. J'ouvre le tableau d'envois sortants : six cent quarante-sept brouillons en attente, six cent soixante-douze envoyés. Personne ne clique sur Envoyer. Les mails de premier contact sont préparés par un pipeline et ils dorment, parce que la dernière étape suppose un humain. Cette humaine, j'ai cessé de croire qu'elle aurait le temps. Je formule la décision : automatise l'envoi.
La réponse arrive en quelques secondes. Trois niveaux d'automatisation. Quatre canaux. Trois paliers de risque. Tout est correct, tout pourrait faire l'objet d'un atelier d'architecture d'une demi-journée. Je n'ai pas demandé d'atelier. Pauline passe derrière, jette un œil, ne dit rien.
Premier recadrage, bref, trop bizarre, on simplifie. L'agent abandonne deux axes, garde quatre couches résiduelles, warm-up progressif sur trois semaines, hash déterministe anti-rejeu, table de configuration en base, Phase 1 manuelle suivie d'une Phase 2 automatisée à valider après deux semaines de mesure. La cible reste la même, qu'un mail parte sans clic humain. Le chemin s'est allongé d'autant.
Deuxième recadrage, plus sec, simple, trois garde-fous, un kill-switch, on fait ça en une journée. L'agent ré-architecture, accepte la cible journée, garde les trois garde-fous. Mais glisse trois prothèses qu'il appelle standard de l'industrie, dashboard temps réel, retry exponentiel, audit log structuré dans une nouvelle table. Chacune justifiable isolément. Aucune demandée.
Troisième recadrage, plus court encore : je ne comprends pas pourquoi tu rajoutes ça. Phrase d'ouverture presque embarrassée, que je n'avais jamais lue de sa part : « tu as raison, je sur-équipe sans nécessité ». Et la version qui aurait dû arriver au premier tour. Une fonction qui prend l'enregistrement du brouillon, vérifie trois conditions, appelle le moteur d'envoi, retourne.
// lib/email-outbox.ts — generateFirstContactDraft (commit 3756e63)
if (!EMAIL_REGEX.test(input.email)) {
return { success: false, error: 'email_invalide' }
}
if (BLACKLIST_EMAILS.has(input.email.toLowerCase())) {
return { success: true } // silencieux
}
if (existing && existing.length > 0) return { success: true } // anti-doublon
// ... construction du brouillon ...
const autoSend = process.env.PREMIER_CONTACT_AUTOSEND === 'true'
if (!autoSend) return { success: true } // kill-switch brouillon
const { sendOutboxEmailCore } = await import('@/lib/email-outbox-send')
return sendOutboxEmailCore(inserted.id)
Au premier tour je voulais une fonction, l'agent m'a proposé une plateforme. Au deuxième je voulais une journée de code, il m'a proposé un trimestre de déploiement. Au troisième je voulais quinze lignes, il m'a proposé trois mécanismes d'observabilité. La feature a tenu sa cible journée, mais la journée s'est divisée en deux moitiés inégales, une heure et demie de recadrage, six heures de code propre.
L'agent n'a pas voulu compliquer, et je l'écris sans ironie. Il a un entraînement qui valorise la complétude des options. Quand un humain demande à un consultant « automatise mes envois », le consultant compétent ne répond pas par une fonction de quinze lignes, il répond par une grille de décision. L'agent a appris cette posture sur des millions de tokens, il l'applique parfaitement, à chaque demande qui ressemble de loin à une question d'architecture.
Trois recadrages sur une demande simple, c'est un signal. Soit la demande initiale était trop floue, soit l'agent a basculé en mode plateforme alors qu'on était en mode fonction. Au-delà de trois, le coût ne se rattrape plus dans la journée.
Le candidat de fix tient en une phrase, à insérer en tête de prompt : « propose la version minimale en quinze lignes. Pas de matrice. Pas de phases. Les extensions, après, en dessous. » La mesure tient sa première semaine. Je dirai dans le prochain épisode si elle tient le mois.