Version technique→

Étude de cas · automatisation · 2026 · Usage interne

Pipeline de prospection

Pipeline en dix étapes orchestré par des sous-agents Claude : découverte, collecte, fiches, arbitrage, rédaction, vérification adversariale des faits. Un humain relit et envoie.

Année
2026
Statut
Usage interne
Périmètre
Conception → développement → exploitation
Stack
Node.js 22PlaywrightApifyClaude Code (sous-agents)node:test

Contexte

Prospection locale par lots d'une quinzaine de cibles. Le problème n'est pas d'écrire un message, c'est d'en écrire un qui ne contienne aucun fait faux : une accroche inexacte ruine le premier contact. Le pipeline sépare donc strictement ce qui produit (fiches, rédaction) de ce qui contrôle (arbitrage, vérification), et garde un humain à la sortie.

Chaîne

La découverte passe par un binaire de scraping local, sans coût, qui produit un pool dédoublonné. Un lot est ensuite constitué par filtres (catégorie, code postal, exclusion des réseaux et franchises), chaque écart étant consigné avec son motif dans un fichier relisible.

La collecte tourne en parallèle : avis via Apify, crawl des sites avec Playwright (pages, captures, détection des outils en place, blocage anti-robot noté et jamais contourné), recherche dans les stores d'applications, profils Instagram. Un pré-tri sur Sonnet écarte les cas évidents, chacun avec sa règle et sa preuve ; le douteux passe en fiche complète.

Un sous-agent par cible rédige une fiche, en parallèle. Un arbitre lancé à neuf applique une grille écrite, sans voir la conversation. Un rédacteur produit les messages, puis un vérificateur par message les juge sur les sources seules et rend OK, OK à retoucher ou Bloqué. Je relis ce qui reste, puis j'envoie moi-même.

Décisions

01
L'état d'un lot vit dans un fichier, pas dans la conversation : une session neuve reprend un lot sans historique. Introduit après un lot dont la vérification avait saturé la fenêtre de contexte (environ 2 M de tokens).
02
Un contrôle de fin d'étape bloquant, et un --dry avec coût annoncé avant tout run payant. Un contrôle rouge se corrige par un rerun ciblé ou se signale, jamais ne s'ignore.
03
Chaque rôle ne reçoit que son entrée : l'arbitre voit la grille et les fiches, le rédacteur le tableau et les fiches, le vérificateur le message et ses sources. Aucun ne voit la conversation, donc aucun ne peut s'aligner sur ce qui a déjà été décidé.
04
Instantanés d'API : l'agent qui tire un fait d'une API en enregistre la réponse brute, avec URL et heure. Le vérificateur juge dessus et recharge en direct ; si le direct ne montre plus le fait, l'instantané récent fait foi.
05
Modèle choisi par mesure : le pré-tri tourne sur Sonnet, mais le vérificateur reste sur Opus après un banc sur Sonnet (3 critiques bloquées sur 4, 2 blocages à tort).
06
Aucun envoi automatique. L'envoi par navigateur piloté a été retiré : l'outil prépare le lien du canal, le texte et le contrôle, l'humain envoie.

Garde-fous et mesures

Un script borne la consommation des entrées du vérificateur (avis cités, captures recadrées, fichiers allégés). L'arbitrage mesuré au banc coûte 175 000 à 240 000 tokens par lot, en 5 à 6 minutes. Les modules de scripts/lib sont couverts par des tests node:test.

Les données collectées restent hors du dépôt (RGPD, conditions d'usage des sites) : le dossier de données est ignoré par git et rien de brut n'entre dans l'historique.

Extension : la matinale

Un balayage quotidien de quatre sources d'offres et de posts, lancées en parallèle. Une source en échec n'arrête pas les autres et est retentée le lendemain avec une fenêtre élargie. Un fichier d'éléments déjà vus ne montre que le nouveau, le coût de chaque collecte est journalisé, et un script liste les relances dues à J+7.

Présentation courte, version clients : Pipeline de prospection

Étude suivante

Moteur de veille →

Veille concurrentielle en ligne de commande : deux sources, un critère de réussite propre à chacune, une analyse à schéma imposé, un plafond de coût par exécution.