OZINT

OZINT est un cockpit d'investigation OSINT que je construis le soir. On saisit une valeur de départ (un pseudo, un email, une IP, un domaine, un hash de fichier, une image, un couple de coordonnées, un identifiant CVE, un numéro de téléphone) et un arbre de résultats typés grandit à partir d'elle. Le moteur est écrit en Rust, le cockpit en React, et tout tourne sur sa propre machine : pas de service hébergé, pas de compte, pas de télémétrie.

Le problème

Les outils OSINT automatisés ont tendance à noyer l'utilisateur. Ils récursent seuls et livrent mille nœuds dont quatre comptent, sans qu'on sache d'où vient chacun. Je voulais l'inverse : un outil dont l'arbre garde la forme du raisonnement réel de l'analyste.

Fonctionnement

Une valeur de départ est classée dans l'un des douze types d'entité. Chaque type a un plan, et une « couche » d'outils se déclenche en parallèle sur la valeur, par phases, les phases suivantes dépendant de ce que les précédentes ont trouvé. Les résultats deviennent des nœuds enfants, et chaque enfant reste inactif tant que vous n'avez pas décidé qu'il mérite d'être suivi. Rien ne récurse seul, volontairement.

Le catalogue compte 62 outils, dont 45 sans clé d'API. Chacun est un appel HTTP à une API documentée plus un parseur, sans modèle dans la boucle. Un modèle de langage n'intervient qu'à deux endroits optionnels (raconter une couche terminée, et lever l'ambiguïté d'une valeur dont le type n'est pas clair), et les deux se dégradent proprement si aucun n'est configuré.

Les décisions qui comptent pour moi

• La provenance d'abord. Chaque résultat enregistre quel outil l'a produit, quand, depuis quelle URL et ce que disait la réponse brute. Le panneau de détail s'ouvre là-dessus, avant l'affirmation elle-même.
• Un compte rendu honnête. Une couche indique quels outils ont tourné, lesquels ont été ignorés faute de clé, et lesquels n'ont rien renvoyé : une branche vide se lit « on a cherché et rien trouvé », pas « quelque chose a cassé ».
• Un interrupteur d'urgence. Un seul appel refuse toute requête sortante pour tout le processus, survit aux redémarrages et échoue en mode fermé si son propre enregistrement est illisible. La liste des routes qu'il protège est écrite route par route, pour qu'un oubli ne passe pas inaperçu.
• Local par construction. Le serveur n'écoute que sur la boucle locale, les données sont dans SQLite, et chaque outil déclare une vraie limite de débit et passe par un client HTTP partagé avec une politique de redirection protégée contre le SSRF.

Le workspace compte cinq crates Rust (cœur, base de données, client LLM, moteur, serveur axum) plus le cockpit, sans framework CSS, dont tout le style vient d'une seule table de tokens. Environ 1 100 tests Rust et 183 tests du cockpit passent, et clippy ne remonte aucun avertissement.

Limites assumées

Une suite verte prouve moins qu'il n'y paraît : la plupart des tests de sources donnent au parseur une réponse déjà analysée, et ne détectent donc pas un changement de format côté API. Je lance de vraies valeurs sur un vrai serveur avant de faire confiance à une source. Le plus gros écart connu : certains outils renvoient leurs résultats en lignes lisibles plutôt qu'en nœuds enfants à poursuivre, si bien qu'un email fait moins grandir l'arbre que ce que le produit promet. Je l'ai suivi outil par outil et corrigé en partie, mais il n'est pas refermé.

J'ai écrit noir sur blanc ce que l'outil refuse de faire (pas de mode crawl, pas de credential stuffing, pas de fuites de données, pas de surveillance) et une section d'usage responsable, car agréger des données publiques sur une personne peut nuire. La suite : refermer cet écart, puis tester la couche réseau elle-même.