Modèle / jeu de données
eracle/OpenOutreach avatar
eracle/OpenOutreach

OpenOutreach : un agent CLI qui qualifie les prospects avant de les contacter

Open-source AI agent for B2B lead generation — describe your product, it finds the people who fit, explains why each one does, and emails them from your mailbox. Self-hosted CLI, one install.

2 999 étoiles556 forksPythonGPL-3.0

En bref

De quoi s’agit-il ?
OpenOutreach enveloppe deux programmes distincts, OpenOutFind et OpenOutSend, derrière un assistant en ligne de commande auto-hébergé. Il trouve des prospects, justifie chaque sélection, puis envoie les courriels depuis votre propre boîte, sous licence GPL-3.0.
À qui s’adresse-t-il ?
Adoptez OpenOutreach si vous savez écrire une phrase précise sur votre produit et votre marché cible, si vous acceptez d'auto-héberger l'ensemble et de payer une adresse professionnelle vérifiée par prospect retenu. Écartez-le si vous cherchez une séquence de courriels à partir d'une liste existante, ou si votre cible n'est pas couverte par le fournisseur de données sous licence qu'il interroge.
Puis-je l’utiliser commercialement ?
Oui, sous conditions. GPL-3.0 est une licence copyleft : si vous distribuez un logiciel qui l’inclut, vous devez publier le code source de ce logiciel sous la même licence. Un usage interne, sans distribution, ne déclenche pas cette obligation.
Est-il encore maintenu ?
Oui. Les derniers commits datent d’il y a 8 jours.
En quel langage est-il écrit ?
Principalement Python, d’après les statistiques de langage de GitHub.

Ces réponses reposent sur les données GitHub du projet (dernière synchronisation le 15 septembre 2026) et sur notre analyse. Elles ne constituent pas un avis juridique.

ANALYSE OPEN SOURCE APPROFONDIE

Le problème : personne ne veut trier une liste de prospects à la main

La prospection B2B automatisée suppose presque toujours la même chose : vous apportez une liste. Un outil de séquençage de courriels reçoit des adresses, les envoie dans un ordre défini et gère les relances. Le travail de sélection, lui, reste en amont, et c'est là qu'il coûte cher en temps. OpenOutreach inverse cette répartition. L'entrée n'est pas un fichier CSV, c'est une description de produit et de marché cible. Le README formule la promesse ainsi : « Describe your product. Define your target market. » Le système découvre ensuite des personnes correspondantes auprès d'un fournisseur de données sous licence, les évalue par rapport à un profil de client idéal déduit de votre description, et vous rend les profils retenus avec, pour chacun, la raison du choix. La cible est donc l'équipe technique ou le fondateur qui n'a pas de base de prospects constituée mais qui sait décrire ce qu'il vend. Le README insiste sur un point : il n'y a ni navigateur, ni compte sur un réseau social, ni scraping, donc pas de compte à faire bannir. C'est un argument de conception, pas une garantie juridique, et il faut le lire comme tel.

Deux programmes séparés reliés par un tuyau public

L'architecture est explicitement modulaire. OpenOutreach est un orchestrateur : il installe et héberge deux programmes autonomes dans un même processus, une même base et un même assistant de configuration. OpenOutFind couvre la découverte, la qualification, l'enrichissement et le CRM. OpenOutSend couvre l'agent d'envoi, la boîte aux lettres et les garde-fous avant expédition. Chacun garde son propre script de console, son module de réglages et sa suite de tests. Le contrat entre les deux est public et documenté sous cette forme : outfind find 50 --json | outsend. La commande openoutreach run exécute ce même tuyau dans un seul processus, les lignes JSON traversant simplement un tampon plutôt qu'un tube Unix. Le README justifie ce choix : un second chemin en mémoire, non testé, rendrait le chemin public mensonger. C'est une position défendable, et elle a un coût direct : les deux enfants lisent leur configuration dans des variables d'environnement à chaque exécution et ne mémorisent rien. C'est adapté à un script ou à un agent, pas à un humain, ce qui explique la présence de l'assistant dans le paquet parent. Si vous êtes un agent ou un utilisateur avancé avec votre propre expéditeur, prenez les deux CLI et le tuyau. Sinon, prenez la commande unique.

Installer et lancer : les commandes réelles

L'installation tient en deux lignes, telles que le README les donne : uv tool install openoutreach puis openoutreach. Une invocation nue déclenche l'assistant de configuration si nécessaire, trouve des prospects, achète une adresse professionnelle vérifiée pour chacun et envoie les courriels. Les verbes disponibles sont documentés séparément. openoutreach init ne fait que la configuration, sans rien dépenser, et accepte deux fichiers pour les champs longs : openoutreach init --product-docs product.md --target target.md. openoutreach run 5 fixe un objectif explicite et plafonne la dépense à cinq crédits. openoutreach find 10 produit dix prospects supplémentaires au format CSV sur la sortie standard et ne peut rien dépenser ; la variante openoutreach find 10 emails ajoute une adresse professionnelle, facturée un crédit par adresse. openoutreach find 0 n'effectue aucun travail et imprime ce qui est déjà stocké. openoutreach send envoie ce qui est déjà en base, et openoutreach send 5 s'arrête à cinq conversations ouvertes. openoutreach status indique ce qui est configuré, bloqué et compté. Toute la persistance vit dans ~/.openoutreach, donc relancer la commande reprend là où vous vous étiez arrêté : le nombre demandé s'entend comme un total supérieur à ce que vous possédez déjà. Le format de sortie CSV porte les colonnes email, first_name, last_name, company, title, website, linkedin_url, reason, lead_id, qualified_at. La colonne reason contient la justification en langage naturel, et c'est la partie du produit qui se discute le plus facilement.

Le coût réel se cache dans le verbe emails

La documentation est claire sur un point : find sans le mot emails est gratuit et ne peut pas dépenser. Dès que vous ajoutez emails, chaque adresse professionnelle coûte un crédit, et le README indique que le système achète une adresse vérifiée pour chaque prospect retenu. La dépense est donc proportionnelle au nombre de prospects qualifiés, pas au nombre de courriels envoyés. Un run 5 plafonne à cinq crédits, ce qui borne l'exposition. Mais cela signifie aussi qu'une description de produit trop vague peut consommer des crédits pour des profils que vous rejetterez à la lecture. Le mécanisme de correction est explicite : on corrige les verdicts en corrigeant la description, pas en éditant une liste. C'est cohérent avec le modèle, et frustrant si vous vouliez simplement supprimer une ligne. Autre contrainte de forme : la sortie est un flux CSV, pas une interface de revue. Vous devrez ouvrir le fichier dans un tableur ou le traiter avec vos propres outils pour trier et filtrer. Le README ne décrit aucune commande de suppression ou de rejet d'un prospect, seulement la réécriture de la description comme levier de correction.

Ce que le paquet ne fait pas, et quand il n'est pas le bon outil

Le cas d'usage mal servi est net : si vous possédez déjà une liste de contacts à qui vous voulez écrire, OpenOutreach ne vous aide pas, parce qu'il n'y a rien à téléverser. Le README le dit sans détour : l'entrée est une phrase sur votre produit. Un outil de séquençage classique reste le bon choix dans ce scénario. Deuxième limite : la découverte dépend entièrement d'un fournisseur de données sous licence dont le README ne nomme ni la couverture ni la provenance. Si votre marché cible est une niche mal couverte par ce fournisseur, l'agent ne trouvera rien, quelle que soit la qualité de votre description. Ce point n'est pas documenté dans le matériel fourni et mérite une vérification avant tout engagement. Troisième limite, plus structurelle : les deux programmes enfants ne mémorisent aucune configuration et relisent leurs variables d'environnement à chaque exécution. Toute automatisation par cron ou par un agent devra donc fournir ces variables à chaque appel, ou passer par le paquet parent. Enfin, le README ne mentionne aucune version publiée : la section des releases est vide dans les données dont je dispose, donc rien ne permet de juger la stabilité des interfaces entre versions.

Face à un séquenceur de courriels classique

La différence avec un outil d'envoi automatisé porte sur l'endroit où se situe le travail de qualification. Un séquenceur reçoit une liste et gère la cadence, les relances et les tests de sujet. Il ne sait rien de la correspondance entre un contact et votre produit, sinon ce que vous avez décidé vous-même en construisant la liste. OpenOutreach déplace ce jugement dans le logiciel : il produit un verdict par personne, en langage naturel, et ce verdict est stocké dans la colonne reason du CSV. La contrepartie est une perte de contrôle direct sur la composition de la liste : vous ne choisissez pas qui entre, vous choisissez la description qui détermine qui entre. C'est un renversement qui convient à quelqu'un qui sait formuler son marché cible et pas à quelqu'un qui a déjà fait ce travail en amont. Le second point de comparaison est l'absence de navigateur et de compte sur une plateforme sociale, revendiquée comme un avantage de conception. Un outil fondé sur l'automatisation d'un compte existant porte un risque de suspension que celui-ci n'a pas, mais il accède aussi à des signaux que celui-ci ne voit pas.

Licence, maintenance et coût de mise à jour

Le projet est publié sous GPL-3.0. Concrètement, si vous redistribuez une version modifiée d'OpenOutreach, vous devez fournir le code source correspondant sous la même licence. Si vous l'exécutez pour votre usage interne sans le distribuer, la question ne se pose pas de la même façon. Je ne donne pas de conseil juridique ici : faites relire votre cas si vous envisagez d'intégrer le code dans un produit distribué. Le coût de maintenance tient à trois éléments visibles dans le matériel. D'abord, la configuration vit dans ~/.openoutreach et dans des variables d'environnement préfixées OPENOUTFIND_ et OUTSEND_, ce qui signifie que toute automatisation doit reproduire ces variables à chaque appel. Ensuite, les deux paquets enfants évoluent séparément, avec leurs propres scripts de console et leurs propres tests ; une mise à jour de l'un peut donc modifier le contrat du tuyau JSON Lines sans que le parent change de version. Enfin, la dépense en crédits est un coût d'exploitation récurrent, pas un coût d'installation : chaque adresse achetée se paie. Le README ne documente ni politique de support, ni cadence de publication, ni procédure de migration entre versions. Le plugin Claude Code, installable via /plugin marketplace add eracle/OpenOutreach puis /plugin install openoutreach@openoutreach, n'ajoute aucune dépendance à l'usage du CLI lui-même : le fichier skills/find-leads/SKILL.md décrit le contrat de la ligne de commande et peut être copié dans ~/.claude/skills/ ou pointé depuis les instructions d'un autre agent.

Conclusion éditoriale

Adoptez OpenOutreach si vous savez écrire une phrase précise sur votre produit et votre marché cible, si vous acceptez d'auto-héberger l'ensemble et de payer une adresse professionnelle vérifiée par prospect retenu. Écartez-le si vous cherchez une séquence de courriels à partir d'une liste existante, ou si votre cible n'est pas couverte par le fournisseur de données sous licence qu'il interroge. Avant tout déploiement, exécutez openoutreach init pour vérifier que le budget de crédits, le fichier ~/.openoutreach et la configuration de votre boîte sont corrects, puis lancez openoutreach find 10 sans le mot emails : cette commande ne peut rien dépenser et vous montre la qualité des verdicts avant qu'un seul euro ne soit engagé.

Sources officielles

  1. eracle/OpenOutreach on GitHub
  2. Issues
  3. License: GPL-3.0
  4. Project website
  5. README
Notes de la communauté

Notes de la communauté