OpenOSINT : un agent OSINT qui refuse d'inventer ses résultats
AI-powered OSINT agent with interactive REPL, MCP server, and CLI. 19 tools. Works with Claude, GPT-4, or local models. For authorized security research only.
En bref
- De quoi s’agit-il ?
- Le projet empaquette une vingtaine d'outils de reconnaissance derrière un REPL, une CLI, un serveur MCP et une interface web. Sa promesse tient dans un détail d'architecture : le modèle ne produit pas les données, il déclenche des binaires.
- À qui s’adresse-t-il ?
- OpenOSINT convient à un analyste qui sait déjà ce qu'il cherche et veut automatiser l'enchaînement d'outils, ainsi qu'à une équipe qui préfère exposer des capacités OSINT via MCP plutôt que de réécrire des wrappers. Il ne convient pas à qui veut une couverture exhaustive sans écrire de code, ni à qui ne peut pas installer de binaires externes.
- Puis-je l’utiliser commercialement ?
- Oui. MIT est une licence permissive : vous pouvez utiliser, modifier et vendre un logiciel qui en dépend, à condition de conserver les mentions de droit d’auteur et de licence.
- Est-il encore maintenu ?
- Oui. Le dépôt a reçu de nouveaux commits au cours des dernières 24 heures.
- 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 : un modèle qui raconte au lieu de chercher
Un agent conversationnel à qui l'on demande de faire de la reconnaissance a un défaut structurel : il génère du texte plausible. Une adresse IP géolocalisée, un compte trouvé sur un forum, une correspondance d'email, tout cela peut sortir d'un modèle sans qu'aucune requête réseau n'ait eu lieu. Le README d'OpenOSINT formule le problème à sa manière : le modèle émet des appels d'outils avec arrêt net, et c'est le code du projet qui exécute le vrai binaire, ce qui rend les conclusions hallucinées, selon cette formulation, structurellement impossibles. C'est la thèse centrale du projet, et elle mérite d'être prise au sérieux parce qu'elle déplace la responsabilité : le LLM choisit quoi lancer et comment interpréter, il ne fabrique pas la matière première. Le public visé est nommé explicitement, chercheurs en sécurité et analystes, avec une mention d'usage restreint à la recherche autorisée. Le dépôt est en Python, sous licence MIT, et le README renvoie vers un site dédié.
Une vingtaine d'outils, quatre façons de les appeler
Le projet se présente comme un agent OSINT avec REPL interactif, serveur MCP et CLI, et la description du dépôt parle de 19 outils tandis que le README annonce 20 outils d'investigation. Cet écart d'une unité entre les deux sources n'est pas anodin : il suggère que le compte a bougé entre deux mises à jour, ou que la description du dépôt n'a pas suivi. Les sujets associés au dépôt donnent une idée du contenu : holehe, maigret, sherlock, ce qui indique que l'agent encapsule des outils de correspondance de comptes existants plutôt que de réimplémenter la logique de recherche. Quatre surfaces d'usage sont documentées : le REPL en mode par défaut, une interface web, une CLI directe, et un serveur MCP publié sur le registre sous l'identifiant io.github.OpenOSINT/openosint. Ce dernier point est le plus intéressant pour une équipe : exposer des outils OSINT via Model Context Protocol signifie qu'un client compatible peut les appeler sans que le projet impose son propre client.
Le graphe d'entités et la couche de déclarations
La démonstration du graphe web montre une architecture plus élaborée qu'un simple enchaînement de commandes. Les entités n'existent pas directement : elles sont posées au niveau des déclarations, chaque déclaration portant son jeu de données, son extracteur, son identifiant d'exécution et un score de confiance. Deux nœuds Organisation observés indépendamment par les jeux de données openosint:github et openosint:whois peuvent être reliés par une arête candidate same_as notée 0.83, et l'interface de révision humaine compare les deux entités champ par champ, valeurs identiques en vert, valeurs divergentes en ambre, avec l'explication de la caractéristique de correspondance de noms qui a produit le score. L'acceptation par le réviseur transforme l'arête en relation same_as solide et fusionne la paire. Le README précise que cette démonstration utilise des données synthétiques et que les entités sont injectées au niveau des déclarations, pas produites par les mappers actuels. Autrement dit, la mécanique de révision est réelle, la qualité de peuplement du graphe ne l'est pas encore dans ce qui est montré.
Installation et premières commandes
L'installation tient en une ligne, pip install openosint, et le README donne trois points d'entrée. openosint lance le REPL interactif avec IA, qui est le mode par défaut. openosint web ouvre l'interface web. openosint email target@example.com appelle directement un outil sans passer par un modèle, ce qui est probablement le mode le plus utile pour vérifier que l'outillage sous-jacent fonctionne avant d'y brancher un LLM. Le projet annonce une compatibilité avec Claude, GPT-4 et des modèles locaux, sans que le README détaille la configuration des clés d'API ou des points de terminaison. C'est une lacune réelle : savoir quels modèles sont supportés ne dit rien sur la façon de les déclarer. Le projet est publié sur PyPI, dispose d'un identifiant MCP enregistré, et le README mentionne des intégrations sponsorisées, dont IP2Location.io pour l'outil search_ip2location et RapidProxy pour la collecte via proxys. Ces intégrations sont documentées dans des guides séparés sous docs/integrations/.
Le modèle économique autour d'un dépôt MIT
Le code est sous MIT, mais le README pousse vers trois offres payantes : un Complete Kit à 55 dollars regroupant prompts et playbook, un Setup Sprint à 350 dollars pour une installation clé en main, et une licence commerciale à partir de 300 euros par an présentée comme un contrat vendeur avec SLA et indemnisation. La coexistence d'une licence MIT et d'une licence commerciale n'a rien d'illégal, mais elle mérite d'être lue attentivement : le fichier COMMERCIAL.md est la seule source qui puisse dire ce que la licence commerciale ajoute réellement par rapport à MIT, et rien dans le matériel fourni ne le précise. Si vous comptez vendre un service bâti sur OpenOSINT, c'est ce fichier qu'il faut ouvrir avant de dimensionner quoi que ce soit, pas le badge de licence du README. Le rythme de publication est soutenu, avec trois versions entre le 24 et le 26 août 2026, et un dernier push en septembre 2026. Un rythme aussi serré signifie que les correctifs arrivent vite, mais aussi que la surface peut bouger entre deux lectures de la documentation.
Ce que le projet ne fera pas pour vous
La limite la plus visible est le périmètre des outils. Le projet s'appuie sur des briques existantes comme holehe, maigret ou sherlock, ce qui veut dire que la qualité d'un résultat dépend d'un binaire tiers que vous devez installer et maintenir, et dont les sites cibles peuvent casser la logique à tout moment. Un outil de correspondance de comptes qui repose sur des pages web change de comportement quand ces pages changent. Rien dans le matériel fourni n'indique de mécanisme de détection de ces ruptures. Deuxième limite : la promesse d'impossibilité structurelle des hallucinations vaut pour les données brutes, pas pour l'interprétation. Un modèle qui reçoit une sortie d'outil peut encore la résumer de travers, relier deux entités à tort, ou suggérer une piste que rien n'étaye. La couche de révision humaine visible dans la démonstration du graphe existe précisément parce que ce risque n'est pas nul. Troisième limite : l'usage est restreint à la recherche autorisée, et le projet ne fournit aucun garde-fou technique visible pour faire respecter cette restriction. C'est à l'opérateur de savoir ce qu'il a le droit de cibler.
Face à un script maison ou à un framework d'orchestration
L'alternative la plus directe n'est pas un autre agent OSINT, c'est ce que beaucoup d'équipes font déjà : un script qui appelle maigret, holehe et quelques requêtes DNS, avec un fichier de sortie. La différence d'approche est nette. Le script est déterministe, testable, et ne consomme aucun jeton de modèle. OpenOSINT ajoute une couche de langage naturel qui choisit l'outil et enchaîne les appels, ce qui a de la valeur quand l'enchaînement dépend du résultat précédent, et beaucoup moins quand la séquence est connue d'avance. Si votre besoin est une commande fixe lancée sur une liste de cibles, la CLI directe suffit et le REPL n'apporte rien. Face à un framework d'orchestration générique, la différence tient au serveur MCP : au lieu d'écrire vous-même des wrappers autour de chaque outil et de les exposer à votre client, vous branchez un serveur qui déclare déjà ces capacités. C'est un gain d'intégration, pas un gain d'analyse.
Conclusion éditoriale
OpenOSINT convient à un analyste qui sait déjà ce qu'il cherche et veut automatiser l'enchaînement d'outils, ainsi qu'à une équipe qui préfère exposer des capacités OSINT via MCP plutôt que de réécrire des wrappers. Il ne convient pas à qui veut une couverture exhaustive sans écrire de code, ni à qui ne peut pas installer de binaires externes. Avant d'adopter, vérifier deux choses concrètes : la liste des 20 outils réellement disponibles dans votre version, et si le mode web accepte une liaison sur l'interface locale uniquement.
Notes de la communauté