OpenOSINT est un agent OSINT en Python qui combine un CLI, une interface web, un REPL IA et un serveur MCP. Après un vrai test sur le domaine openosint.tech, mon verdict est simple : ça vaut l’essai si vous voulez orchestrer plusieurs outils de reconnaissance depuis un même endroit, mais ce n’est pas encore l’outil magique que l’on lance les yeux fermés en prod.
Je l’ai installé depuis le dépôt GitHub, branché à un proxy OpenAI-compatible local, lancé en ligne de commande, via le REPL IA et via l’interface web. Je détaille ici ce qui a réellement fonctionné, ce qui a coincé et pour qui OpenOSINT peut être utile.
OpenOSINT, c’est quoi ?
OpenOSINT se présente comme un agent OSINT assisté par IA. En pratique, c’est une couche d’orchestration autour de plusieurs outils de reconnaissance : DNS, WHOIS, GitHub, Shodan, VirusTotal, Censys, HaveIBeenPwned, Sherlock, Holehe, Sublist3r, génération de dorks et quelques intégrations payantes.
Le projet expose quatre façons de travailler :
- un CLI direct pour appeler certains outils sans IA,
- un REPL interactif où le modèle choisit les outils,
- une interface web avec chat et cartes d’outils,
- un serveur MCP pour brancher OpenOSINT à un client compatible.
L’idée est bonne : au lieu de jongler entre quinze commandes, on donne une cible autorisée, puis l’agent appelle les bons modules et rédige une synthèse.
| Point testé | Résultat observé |
|---|---|
| Version du paquet | 2.20.0 dans pyproject.toml |
| Langage | Python 3.10 ou plus |
| Backend IA testé | OpenAI-compatible via proxy local |
| Cas concret | Investigation du domaine openosint.tech |
| Sorties obtenues | WHOIS, DNS, GitHub, rapport REPL, UI web |
| Limite notable | certains outils dépendent de clés ou de binaires externes |
Installation de OpenOSINT
J’ai cloné le dépôt dans /tmp, puis installé le paquet en mode editable. Premier détail concret : dans mon environnement, /tmp est monté avec une restriction qui empêche de charger certaines bibliothèques natives depuis un virtualenv placé dans /tmp. Le CLI direct passait, mais le REPL IA a échoué avec une erreur de chargement sur pydantic_core.
J’ai donc gardé le clone dans /tmp, comme prévu, mais installé le virtualenv dans un dossier temporaire de travail, supprimé ensuite. Les commandes de base étaient :
git clone https://github.com/OpenOSINT/OpenOSINT /tmp/OpenOSINT
python3 -m venv /workspace/scout-openosint-openosint/.scratch/venv
/workspace/scout-openosint-openosint/.scratch/venv/bin/python -m pip install -e '/tmp/OpenOSINT[openai,pdf]'
Pour l’IA, je n’ai pas cherché de vraie clé. J’ai utilisé le proxy local fourni :
export OPENAI_BASE_URL=http://172.17.0.1:8790/v1
export OPENAI_API_KEY=sk-proxy
export OPENAI_API_BASE=http://172.17.0.1:8790/v1
export OPENROUTER_BASE_URL=http://172.17.0.1:8790/v1
export OPENROUTER_API_KEY=sk-proxy
export OPENAI_MODEL=openai/gpt-4o-mini
Le CLI expose bien les sous-commandes attendues pour les usages principaux : dns, github, email, username, shodan, censys, web, multi, history et d’autres. Surprise par contre : l’outil interne search_ip existe, l’interface web le liste, mais je n’ai pas trouvé de sous-commande directe ip côté CLI. Pour l’IP, il faut passer par le web, le REPL IA ou une intégration interne.
OpenOSINT à l’usage
Mon cas d’usage était volontairement sobre et autorisé : regarder l’infrastructure publique de openosint.tech, le domaine officiel du projet. J’ai commencé par un appel DNS direct :
python -m openosint.cli --json dns openosint.tech
OpenOSINT a produit une sortie JSON structurée. Les points importants :
[DNS] Domain: openosint.tech
[DNS] A: 185.199.111.153, 185.199.108.153, 185.199.110.153, 185.199.109.153
[DNS] NS: tech-domains.earth.orderbox-dns.com, tech-domains.mars.orderbox-dns.com
[!] No SPF record found: anyone can spoof email from this domain.
[!] No DMARC policy found: no enforcement of SPF/DKIM failures.
[!] No DKIM records found for common selectors.
C’est utile parce que le résultat ne se contente pas de lister des enregistrements. Il ajoute une lecture sécurité basique, ici l’absence de SPF, DMARC et DKIM détectables. Pour un freelance sécu ou DevOps, ce genre de signal est exploitable dans un pré-audit.
J’ai ensuite testé l’outil GitHub :
python -m openosint.cli --json github OpenOSINT
Résultat : le profil organisation a été retrouvé avec nom, bio, localisation, email public, nombre de dépôts et dépôt récent. Là aussi, ce n’est pas révolutionnaire, mais c’est propre et rapide.
OpenOSINT avec l’agent IA
Le test le plus intéressant est le REPL IA. Je lui ai demandé : enquêter sur openosint.tech, utiliser DNS et WHOIS, puis écrire un rapport court. Le modèle a appelé deux outils réels :
Thinking...
→ search_whois(domain='openosint.tech')
→ search_dns(domain='openosint.tech')
Le rapport produit incluait le registrar, les dates de création et d’expiration, les serveurs de noms, les IP GitHub Pages, le TXT Google Site Verification et les limites email. Un fichier Markdown a même été enregistré automatiquement dans un dossier reports/ de session.
J’ai aussi lancé l’interface web sur 127.0.0.1:8787, puis appelé l’API :
curl -s http://127.0.0.1:8787/api/health
curl -s -X POST http://127.0.0.1:8787/api/run/search_whois \
-H 'Content-Type: application/json' \
-d '{"input":"openosint.tech","timeout":60}'
Le serveur a répondu status: ok, backend openai, puis un WHOIS complet. Dans le chat web, le modèle a appelé search_whois, puis a tenté search_domain. Cette seconde étape a renvoyé une limite très claire : sublist3r n’était pas installé. C’est plutôt sain : l’outil ne masque pas l’échec et donne la dépendance manquante.
Ce que j’aime dans OpenOSINT
Premier bon point : les outils directs restent utiles sans IA. Pour du DNS, du WHOIS ou GitHub, on peut obtenir des résultats structurés, scriptables et lisibles.
Deuxième bon point : le mode agent affiche les appels d’outils. On voit ce que le modèle décide de faire, et on peut vérifier si le rapport colle aux données brutes.
Troisième bon point : l’interface web est agréable. Les cartes d’outils rendent le déroulé plus lisible qu’un gros bloc de logs, surtout pour montrer un résultat à un client non technique.
Enfin, le support OpenAI-compatible est un vrai plus. Pouvoir brancher un proxy local ou un routeur de modèles évite de dépendre uniquement d’un fournisseur.
Les limites de OpenOSINT
La promesse est ambitieuse, mais il faut garder la tête froide. Plusieurs outils dépendent de clés externes : Shodan, VirusTotal, Censys, HaveIBeenPwned, AbuseIPDB, Bright Data. Sans ces clés, OpenOSINT reste utile, mais beaucoup moins complet.
Autre limite : certains modules reposent sur des binaires tiers comme sherlock, holehe, sublist3r ou phoneinfoga. Si vous ne les installez pas, l’outil renvoie une erreur propre, mais l’enquête ne va pas au bout.
J’ai aussi vu un écart de maturité entre les interfaces. Le README annonce 16 outils, l’agent et le web les connaissent, mais le CLI direct n’expose pas tout de façon symétrique. Ce n’est pas bloquant, mais ça compte si vous voulez automatiser en shell.
Est-ce que OpenOSINT marche vraiment ?
Oui, sur mon test, OpenOSINT a vraiment produit des données. Il a résolu les DNS de openosint.tech, récupéré le WHOIS, analysé l’absence de politiques email et interrogé GitHub. Le REPL IA a bien utilisé le proxy OpenAI-compatible et a rédigé un rapport basé sur les résultats des outils.
Non, ce n’est pas un remplaçant complet à une méthodologie OSINT. C’est un accélérateur. Il faut toujours valider les conclusions, surtout quand le modèle résume des résultats ou choisit un outil un peu trop large, comme la tentative search_domain alors que j’avais demandé DNS et WHOIS.
Faut-il adopter OpenOSINT ?
Mon verdict : essayer, mais ne pas adopter aveuglément.
Pour un freelance sécu, un DevOps qui fait des pré-audits ou une petite équipe qui veut centraliser de la reconnaissance autorisée, OpenOSINT est une bonne base. Je le vois bien comme console de collecte et de premier résumé.
Pour une équipe mature, je le garderais derrière une couche de contrôle : cibles autorisées, outils activés explicitement, logs conservés, clés API séparées, et rapports relus avant diffusion. Le potentiel est là, surtout avec MCP, mais l’outil doit être cadré.
FAQ
OpenOSINT remplace-t-il un analyste OSINT ?
Non. Il accélère la collecte et le résumé, mais l’analyste doit vérifier les sources, le périmètre légal et les conclusions.
Peut-on utiliser OpenOSINT sans clé API ?
Oui, pour certains outils comme DNS, WHOIS, GitHub public ou la génération de dorks. Pour Shodan, VirusTotal, Censys, HaveIBeenPwned ou Bright Data, il faut des clés dédiées.
OpenOSINT est-il adapté à un usage client ?
Oui pour un pré-audit ou une démonstration encadrée. Pour un livrable client, je recommande de conserver les données brutes, de citer les limites et de relire le rapport IA avant envoi.