Osintgram sur Kali Linux : installer, dépanner, utiliser

Deux particularités de Kali font échouer une installation d'Osintgram, et aucune des deux n'est expliquée par les pages qui se classent aujourd'hui sur cette requête. Toutes deux sont arrivées après la rédaction de la plupart de ces pages.

La première tient au packaging. Osintgram n'est pas dans les dépôts Kali, donc sudo apt install osintgram ne peut pas aboutir, quel que soit le nombre d'articles de blog qui recopient cette ligne. La seconde tient à pip. Depuis Kali 2024.4, la distribution applique la PEP 668 : un simple pip install -r requirements.txt en dehors d'un environnement virtuel refuse de s'exécuter et affiche error: externally-managed-environment. Les anciens tutoriels Kali toujours bien classés sur cette requête (kalilinuxtutorials, les articles Medium de 2021, dev.to) vous donnent exactement cette commande.

Cette page ne traite que les aspects propres à Kali : la réalité du packaging, le mur de la PEP 668, le problème Python 3.13, les erreurs que l'on rencontre sur un système de la famille Debian et nulle part ailleurs, et Termux. Le contenu indépendant de la plateforme (pourquoi un virtualenv, quelle version de Python, comment fonctionnent les identifiants, Windows et Docker) se trouve dans comment installer Osintgram, et cette page ne le répète volontairement pas.

Osintgram est-il dans les dépôts Kali ?

Non. Nous avons vérifié quatre sources indépendantes le 8 août 2026 ; aucune ne le référence.

Un 404 sur la seule page outil pourrait n'être qu'un trou dans la documentation. Quatre réponses négatives couvrant le catalogue d'outils, le GitLab de packaging et Debian, non. Le projet le confirme par omission : le README de Datalux/Osintgram documente une seule voie d'installation, à savoir un git clone, un virtualenv et pip install -r requirements.txt. Il n'existe pas non plus de paquet PyPI, ni de script d'installation : setup.sh renvoie un 404 sur la branche master.

Pourquoi les anciens tutoriels Kali échouent aujourd'hui

Deux choses ont changé sur Kali après la rédaction de la plupart de ces guides, et toutes deux cassent le copier-coller.

La première est la PEP 668, qui permet à une distribution de marquer son installation Python comme gérée en externe. Kali documente ce comportement ainsi que les contournements approuvés : un virtualenv, pipx, un paquet apt, ou l'option déconseillée --break-system-packages. Lancez la ligne d'installation que ces guides vous donnent et pip s'arrête avant même d'avoir téléchargé quoi que ce soit.

error: externally-managed-environment

× This environment is externally managed
╰─> To install Python packages system-wide, try
    apt install python3-xyz, where xyz is the package you
    are trying to install.

    If you wish to install a non-Debian-packaged Python
    package, create a virtual environment using
    python3 -m venv path/to/venv.

note: If you believe this is a mistake, please contact your
Python installation or OS distribution provider.
hint: See PEP 668 for the detailed specification.

Un seul de ces quatre remèdes s'applique à Osintgram. Il n'y a pas de paquet apt, comme établi plus haut. pipx installe des applications Python : il lui faut quelque chose d'installable par pip, or Osintgram ne fournit ni setup.py ni pyproject.toml, donc pipx n'a rien à installer. Reste le virtualenv, c'est-à-dire ce que le README vous demandait de faire dès le départ.

Le second changement est l'interpréteur. Le suivi des paquets Kali indique python3-defaults en 3.13.9-3 dans le dépôt rolling : une installation rolling à jour tourne donc sous Python 3.13 par défaut ; Kali 2024.4 est la version qui avait fait passer le défaut à 3.12, et les choses ont encore évolué depuis. Osintgram n'a pas été écrit pour cela. Son Dockerfile épingle toujours python:3.9.2-alpine3.13, une image de mars 2021, le README n'indique aucune version minimale, et requirements.txt épingle trois paquets à des versions publiées entre 2019 et 2021.

Installer ces versions épinglées dans un virtualenv Python 3.11 propre, avec un pip à jour, fonctionne : nous l'avons reproduit, et prettytable et hikerapi, qui ne publient aucun wheel, se compilent depuis les sources sans broncher. Python 3.9 à 3.11 est la plage à viser. Sur Kali, cela signifie en général accepter 3.13 et en assumer les conséquences, ou, si vous disposez d'un interpréteur plus ancien, créer l'environnement avec lui de façon explicite : python3.11 -m venv venv au lieu de python3 -m venv venv.

Rien de tout cela n'est une attaque contre ces auteurs ; un guide de 2020 était juste en 2020. C'est un avertissement sur ce qui arrive quand on suit une page qui n'a jamais été révisée : on finit par corriger des erreurs créées par le guide lui-même.

L'installation qui fonctionne sur Kali actuel

Six étapes. Rien ici n'exige les droits root sauf la première ; tout le reste se passe dans votre répertoire personnel et à l'intérieur du virtualenv.

1. 1

   Installer les prérequis système

   Git, le module venv et les outils de compilation dont gnureadline a besoin s'il doit compiler. C'est la seule commande qui nécessite sudo.

   sudo apt update
   sudo apt install -y git python3-venv build-essential libncurses-dev

2. 2

   Cloner le dépôt

   Clonez-le dans votre répertoire personnel. Les tracebacks du gestionnaire d'issues regorgent de /home/kali/Osintgram/, une convention qui en vaut une autre.

   git clone https://github.com/Datalux/Osintgram.git
   cd Osintgram

3. 3

   Créer et activer le virtualenv

   C'est l'étape qui rend la PEP 668 sans effet. Ne passez pas --system-site-packages : cela réintroduirait les copies gérées par apt que vous cherchez justement à éviter.

   python3 -m venv venv
   source venv/bin/activate

4. 4

   Installer les dépendances à l'intérieur

   Mettez d'abord à jour les outils de build. Le prettytable==0.7.2 épinglé est assez ancien pour échouer face à un setuptools obsolète.

   pip install --upgrade pip setuptools wheel
   pip install -r requirements.txt

5. 5

   Remplir le fichier d'identifiants

   Le dépôt fournit config/credentials.ini avec trois champs vides : username, password et hikerapi_token. Renseignez soit le couple Instagram, soit le token HikerAPI. make setup demande le couple et écrit le fichier pour vous, mais il omet la ligne du token et réinitialise votre cache de session. Le choix des identifiants est traité en détail dans le guide d'installation.

   nano config/credentials.ini

6. 6

   Le lancer sur une cible

   Le nom d'utilisateur est un argument positionnel obligatoire : main.py ne démarre pas sans lui. Ajoutez -c <command> pour exécuter une seule commande et sortir, au lieu d'entrer dans le shell.

   python3 main.py <target username>

Deux remarques sur l'étape 1. python3-venv est généralement déjà présent, mais pas sur une image Kali allégée, et python3 -m venv venv échoue sans lui ; le message de la PEP 668 vous demande lui-même de vérifier que python3-full est installé. build-essential et libncurses-dev relèvent de l'assurance plutôt que de l'obligation : les versions récentes de gnureadline publient des wheels manylinux2014 pour x86_64 et aarch64, donc sur une machine Kali amd64 ou arm64 ordinaire, pip télécharge un wheel et ne compile rien. Ces deux paquets sont ce qui évite /usr/bin/ld: cannot find -lncurses sur les machines où pip retombe effectivement sur la distribution source.

Les erreurs d'installation sur Kali et ce qu'elles signifient vraiment

Voici les échecs qui apparaissent spécifiquement sur les systèmes de la famille Debian, à peu près par ordre de fréquence dans le gestionnaire d'issues. Le texte de l'erreur est ce que vous collez dans un moteur de recherche ; la colonne du milieu dit ce qui se passe réellement.

Une ligne mérite un développement, parce qu'elle envoie les gens chasser le mauvais paquet. Sous Linux, vous pouvez obtenir une erreur pyreadline. main.py s'ouvre sur un try: import gnureadline / except: import pyreadline nu, et le marqueur d'environnement de requirements.txt n'installe pyreadline que sous Windows. Sur Kali, ce message ne concerne donc jamais pyreadline : il signifie que l'import de gnureadline a échoué, ce qui veut presque toujours dire que la compilation de gnureadline a échoué. Installer pyreadline n'y changera rien. Corriger ncurses, si.

Lancer Osintgram sur Kali

Trois lignes à chaque fois, et la première compte plus qu'il n'y paraît.

cd ~/Osintgram
source venv/bin/activate
python3 main.py <target username>

src/config.py lit config/credentials.ini par un chemin relatif, et main.py importe src.Osintgram de la même manière. Lancez-le avec python3 ~/Osintgram/main.py target depuis votre répertoire personnel et la lecture de la configuration ne trouve strictement rien, ou bien vous obtenez ModuleNotFoundError: No module named 'src.Osintgram'. C'est exactement l'objet de l'issue #105. Il n'y a ni préfixe d'installation ni script d'encapsulation : le répertoire du clone est l'application.

Tout ce que l'outil lit et écrit se trouve sous ce clone :

• ~/Osintgram/config/credentials.ini : vos nom d'utilisateur et mot de passe Instagram, ou un token HikerAPI.
• ~/Osintgram/config/settings.json : la session de connexion mise en cache. La commande cache, ou un lancement avec -C, la réinitialise à {}.
• ~/Osintgram/output/<target>/ : les résultats, sous la forme <target>_<command>.txt et .json. L'écriture dans des fichiers est désactivée tant que vous ne tapez pas FILE=y ou JSON=y, ou que vous ne lancez pas avec -f / -j.

Une fois lancé, vous vous retrouvez dans un shell interactif avec une invite jaune Run a command: et la complétion TAB sur les noms de commandes. Méfiez-vous des commandes lourdes : les quatre commandes d'e-mails et de numéros de téléphone effectuent un appel API supplémentaire par abonné, sans aucune temporisation, et un utilisateur de Kali dans l'issue #366 a obtenu 41,643 enregistrements de fwersemail avant qu'Instagram ne bloque les requêtes. Le plantage qui a suivi les a tous jetés. La référence complète des commandes, les noms des fichiers de sortie et la liste de celles qui ne renvoient plus rien sont dans comment utiliser Osintgram.

Kali sur ARM, et Osintgram dans Termux

Kali sur arm64 ne demande aucune modification de la séquence ci-dessus. gnureadline 8.3.3 publie des wheels manylinux2014 pour x86_64 comme pour aarch64, si bien que la seule dépendance susceptible d'exiger un compilateur n'en a généralement besoin sur aucune des deux architectures.

Osintgram dans Termux

Termux n'est pas Kali, mais c'est l'autre endroit d'où les gens essaient de faire tourner l'outil depuis un téléphone, et c'est l'environnement où la compilation est réellement incontournable. La libc bionic d'Android ne correspond ni aux tags de wheels manylinux ni aux tags musl, donc pip se rabat sur la distribution source de gnureadline, ce qui suppose que clang et les en-têtes ncurses soient déjà là.

pkg update -y && pkg upgrade -y
pkg install -y python git clang make binutils ncurses-utils libffi openssl
git clone https://github.com/Datalux/Osintgram.git
cd Osintgram
python3 -m venv venv
source venv/bin/activate
pip install -r requirements.txt

Termux renvoie Linux pour platform_system, donc le marqueur de requirements.txt sélectionne gnureadline et jamais pyreadline : le plantage au démarrage propre à Windows ne s'applique pas ici. Le rapport Termux le plus fréquent du tracker, l'issue #583, c'est simplement quelqu'un qui lance python3 main.py avant d'installer les dépendances et qui obtient ModuleNotFoundError: No module named 'requests'. Tout ce qui suit l'étape des paquets est identique au parcours Kali, fichier d'identifiants compris, et le problème de connexion ci-dessous aussi.

Ça installe. Puis la connexion échoue.

Faire arriver Osintgram sur Kali est la moitié facile. La moitié difficile, c'est qu'une connexion à Instagram par nom d'utilisateur et mot de passe ne fonctionne pour ainsi dire plus, et rien de ce que vous faites côté Kali n'y change quoi que ce soit. Si votre installation s'est terminée et que l'outil meurt à Attempt to login..., vous n'avez pas commis d'erreur.

L'échec est côté serveur. Le backend historique est instagram-private-api==1.6.0, épinglé à un endpoint Instagram depuis retiré, et les rapports de 2026 (issue #2627, mars 2026) reviennent en checkpoint_required avec une checkpoint_url valant https://i.instagram.com/web/unsupported_version/. Instagram rejette la version d'API de la bibliothèque, pas votre mot de passe. Il existe un second backend : placez un token dans le champ hikerapi_token de config/credentials.ini, ou lancez HIKERAPI_TOKEN=<token> python3 main.py <target> -c <command>, et main.py construit un client HikerAPI à la place, sans aucune connexion Instagram. C'est la voie encore conçue pour fonctionner, et les utilisateurs rapportent qu'elle fonctionne, mais c'est un service tiers payant, cela implique d'envoyer vos cibles à ce tiers, et il a ses propres ruptures de format de réponse, signalées dans l'issue #2664.

Le panorama complet (ce qui a cassé, quand, ce qui fonctionne encore et ce que cela coûte) se trouve dans Osintgram fonctionne-t-il encore en 2026. Et si votre cible est un compte privé, il existe une limite infranchissable qu'aucune plateforme, aucun fork et aucune option ne contourne.

Quand l'installation n'en vaut pas la peine

Il existe une version de ce travail où rien de ce qui précède ne justifie son coût. Si vous avez besoin de données de profil publiques sur une poignée de comptes, et que vous ne cherchez pas spécifiquement à apprendre l'outil ou à travailler hors ligne, alors le clone, le compte jetable, la limitation de débit et les échecs de connexion ne vous apportent rien que vous ne puissiez obtenir plus vite.

Une recherche hébergée supprime aussi la partie du parcours en ligne de commande qui porte le vrai risque sur Kali : vous ne mettez jamais vos propres identifiants Instagram dans un fichier, donc aucun bannissement pour connexion automatisée à redouter. Les mêmes données publiques, sans la PEP 668.