Automatiser l'outreach Reddit correctement

Un pipeline d'outreach Reddit, dessiné au tableau, paraît trompeusement simple : trouver le thread, écrire la réponse, envoyer le DM, consigner le résultat. Quatre cases. Quatre flèches. Les ennuis commencent quand on demande quelles cases peuvent être confiées à une machine et lesquelles non. La plupart des équipes répondent à cette question par accident, en général après leur deuxième suspension de compte.

La réponse honnête est que l'automation sur Reddit n'est pas binaire. C'est un gradient, et le travail utile consiste à repérer où ce gradient bascule de « cela compresse mon effort » à « cela imite une personne qui n'est pas là ».

Le pipeline comme quatre tâches distinctes

Il vaut mieux voir l'outreach comme quatre tâches qui partagent un même workflow, plutôt que comme une activité continue.

La première tâche est la découverte : balayer subreddits et résultats de recherche pour repérer les threads qui correspondent à un sujet, au nom d'un concurrent, ou à une formule comme « je cherche un outil pour ». C'est une opération purement en lecture. Rien n'est posté, personne n'est contacté, aucune surface de détection n'existe. Un script qui surveille cent subreddits et fait remonter les correspondances toutes les heures fait la même chose qu'un humain attentif, simplement plus vite et sans manquer les week-ends.

La deuxième tâche est le scoring. Toutes les correspondances ne sont pas des leads. Un thread qui demande des recommandations d'outils dans un subreddit rempli de votre ICP mérite quinze minutes d'attention. Un thread qui mentionne votre catégorie en passant, dans un subreddit d'amateurs, non. C'est dans le scoring que se joue la majeure partie du levier, parce que la différence entre un taux de réponse de 1 % et 15 % vient en général de la qualité de la file que vous traitez, pas de la qualité des messages.

La troisième tâche est la rédaction. À partir d'un thread et d'un persona cible, produire une réponse ou un DM candidat qui reprend les éléments concrets de la conversation. C'est la tâche où les LLM sont aujourd'hui réellement bons, avec une réserve importante sur laquelle nous reviendrons.

La quatrième tâche est l'envoi. Le clic qui poste le commentaire ou déclenche le DM. Du point de vue de Reddit, c'est la seule tâche qui crée un risque, parce que c'est la seule qui produit un événement d'écriture lié à votre compte.

Ces quatre tâches ont des profils de risque radicalement différents, et les regrouper sous une seule étiquette « automation » est la source de presque tous les problèmes.

Où la frontière doit passer

La frontière qui tient sous pression est à peu près celle-ci : automatisez tout jusqu'au moment de l'engagement public ; laissez l'humain s'engager.

Découverte, scoring et rédaction sont des tâches dont le coût d'erreur est une minute perdue. L'envoi est une tâche dont le coût d'erreur est un compte banni, un domaine grillé, ou la capture d'écran d'un mod dans un megathread « founder spam ». L'asymétrie est énorme, et elle plaide pour un modèle en file : les machines la remplissent, les humains la vident.

Concrètement, cela donne :

• Le monitoring tourne en continu et produit un flux de threads classés.
• Une couche de scoring applique vos filtres ICP, vos règles de fraîcheur et vos listes d'exclusion.
• Une couche de rédaction joint à chaque entrée une réponse suggérée, avec le thread source visible.
• Un humain lit, retouche si besoin, et valide l'envoi.

L'automation a fait huit ou neuf minutes de travail pour chaque minute passée par l'humain. L'humain a conservé la seule décision qui compte : est-ce que ce compte, avec son histoire et sa réputation, doit dire cette chose à cet endroit maintenant ?

Presque toutes les défaillances que nous avons vues viennent de la fusion de la dernière étape avec les autres. Auto-envoi, à la sortie d'un draft LLM, sans relecture, sur un thread dont le contexte subtil a échappé au modèle. La réponse est techniquement on-topic et lue comme du spam par tout humain dans le thread, modérateurs compris.

Ce qui reste humain, sans négociation

Certaines opérations ne devraient jamais être automatisées, peu importe les progrès des modèles.

L'envoi final des réponses personnalisées. Un draft est un point de départ. Valider l'envoi, c'est endosser les mots qui apparaissent sous votre pseudo. Sous-traiter cette décision est la façon dont les comptes brûlent.

Les réponses aux modérateurs. Si un mod écrit à votre compte pour vous demander pourquoi vous avez posté quelque chose, c'est une conversation qui détermine si vous continuerez à poster dans son subreddit. Aucune automation ne gère bien cela, et le mode d'échec (réponse template à un mod humain) est catastrophique.

Les threads sensibles. Posts sur les licenciements, la santé mentale, les industries controversées, tout ce où le registre émotionnel de la salle compte. Un modèle peut identifier le sujet, pas la salle. Sautez ces threads ou écrivez-les à la main.

Le premier contact avec un compte à forte valeur. Si un thread vient d'un fondateur que vous voudriez comme client pour les cinq prochaines années, la réponse que vous lui écrivez est un investissement de 90 secondes pour un retour pluriannuel. Aucune version de « j'ai gagné 90 secondes » ne ressort gagnante.

Tout ce qui vous gênerait de voir attribué à vous-même. C'est le test universel. Si le draft, envoyé tel quel, vous ferait grincer des dents quand un ami vous le transférerait, ne l'envoyez pas. Le fait qu'un outil l'ait produit ne change pas la signature.

Ce qui est vraiment sûr à automatiser

La liste est plus longue que celle des tâches strictement humaines, et c'est précisément pourquoi l'automation est rentable.

Monitoring de mots-clés et de concurrents. Une requête comme alternative à [concurrent] qui tourne sur vingt subreddits, toutes les quinze minutes, avec déduplication. Aucun écrit. Aucun risque. Du levier pur.

Classification d'intention. Étiqueter les threads en « évaluation d'outils », « ras-le-bol sur un pain point », « demande d'aide sur un workflow », « discussion informelle ». Le classifieur n'a pas besoin d'être parfait ; il doit faire remonter les éléments à forte intention en haut de la file.

Rédaction. Produire une réponse candidate qui reprend les éléments concrets du thread. Le draft est destiné à l'humain, pas au public, donc le seuil est « point de départ utile », pas « prêt à expédier ».

Cadencement et planification. Maintenir une file de réponses validées et les libérer à des horaires qui collent au pattern d'activité habituel du compte. Six commentaires validés entre 9 h et 18 h en heure locale, c'est ce que fait un utilisateur réel et engagé. Six commentaires validés à 3 h du matin, c'est ce que fait un script.

Suivi de la santé du compte. Trajectoire de karma, ratio de commentaires retirés, shadowbans par subreddit, taux de signalement des DM. C'est le tableau de bord qui vous dit d'arrêter avant que Reddit ne vous le dise.

Analytics. Taux de réponse par subreddit, taux de conversion par structure de message, courbes de décroissance sur la fraîcheur de l'engagement. Le genre de travail fastidieux à la main et qui devient, sur plusieurs mois, une vraie reconnaissance de patterns.

La forme d'un bon système d'outreach

Bien dessiné, le système a un sommet large et un fond étroit. Des dizaines de milliers de threads entrent dans l'entonnoir via le monitoring. Quelques centaines survivent au scoring. Quelques dizaines sont rédigées. Une poignée part, expédiée par un humain, après un coup d'œil et une retouche.

Le ratio travail automatisé sur travail humain est d'environ 50 pour 1 en temps, mais le ratio décisions automatisées sur décisions humaines concernant ce qui est posté est de 0 pour 1. L'humain signe chaque message sortant.

Ce n'est pas un plafond de productivité. Un fondateur qui consacre une heure par jour à un système comme celui-ci peut tenir dix à quinze réponses de qualité et trois ou quatre DM, chaque jour, pendant des mois. C'est plus de relations construites que la plupart des équipes de cold outbound ne produisent en un trimestre, sans compte banni et sans pénalité au niveau du domaine.

Le piège de résoudre le mauvais problème

La tentation, quand on commence à automatiser Reddit, est d'optimiser le nombre de messages envoyés par jour. Ce chiffre est facile à mesurer, à mettre dans un dashboard, à reporter. C'est aussi le mauvais chiffre.

Le bon chiffre, c'est réponses validées par heure de temps humain. Optimiser cette métrique pousse à construire des files, du scoring, de la rédaction, de la déduplication, de la fraîcheur. Optimiser les messages par jour pousse à construire des auto-senders, de faux comptes et de la rotation de proxies. Le premier système croît tranquillement pendant des années. Le second pique pendant un mois et meurt.

L'essentiel du travail d'ingénierie dans une bonne automation Reddit est la partie ennuyeuse : rendre la file assez propre pour qu'un relecteur humain la traverse sans fatigue. Une fois cela résolu, le reste du système se débrouille presque seul.