Un pentest moderne ne manque pas d’outils. Il manque parfois de temps pour comprendre tout ce que ces outils produisent. Entre reconnaissance réseau, analyse des services, vulnérabilités, OSINT, conformité et génération de rapports, l’analyste doit transformer une quantité considérable de données techniques en décisions exploitables.
C’est précisément dans cet espace que HackGPT Enterprise, un projet open source publié sur GitHub, cherche à placer l’intelligence artificielle : non pas simplement comme un chatbot capable de répondre à une question de cybersécurité, mais comme une couche d’orchestration entre plusieurs outils, plusieurs sources de données et plusieurs fournisseurs d’IA.
Le véritable sujet de HackGPT n’est pas « une IA qui pirate ». C’est une question beaucoup plus intéressante : que se passe-t-il lorsque l’IA devient la couche qui relie les outils d’un pentest ?
Le problème n’est pas le manque d’outils
Un analyste dispose déjà d’un arsenal considérable. Nmap peut cartographier des services réseau. Scapy permet d’aller beaucoup plus loin dans l’analyse des paquets. Des bibliothèques comme Impacket interviennent sur différents protocoles et environnements réseau.
À cela peuvent s’ajouter des sources de renseignement comme Shodan ou Censys, des bases de vulnérabilités, des mécanismes de scoring et des outils de reporting.
Le problème apparaît alors ailleurs : comment relier toutes ces informations ?
Mais produire des résultats et comprendre leur relation sont deux problèmes différents.
HackGPT place l’IA au milieu du processus
Le fichier de dépendances du projet décrit une architecture qui ne repose pas sur un seul modèle. HackGPT prévoit plusieurs fournisseurs d’IA : OpenAI, Anthropic et Google, avec LiteLLM comme couche permettant de travailler avec plusieurs modèles. :contentReference[oaicite:0]{index=0}
Ce choix est important. Une plateforme de sécurité qui dépend entièrement d’un seul fournisseur d’IA devient rapidement dépendante de son API, de ses modèles, de ses tarifs et de ses limites.
Une architecture multi-provider cherche au contraire à rendre cette couche plus interchangeable.
Le dépôt référence notamment :
OpenAI → modèles et API IA
Anthropic → autre fournisseur de modèles
Google GenAI → accès aux modèles Google
LiteLLM → abstraction multi-fournisseurs
Transformers / PyTorch / TensorFlow → briques machine learning
Ce n’est donc pas simplement un chatbot de cybersécurité
C’est probablement l’un des points les plus intéressants du projet.
En regardant les dépendances déclarées, on trouve également des briques pour les bases de données, les API web, les tâches asynchrones, le cloud, les conteneurs, le monitoring, la conformité et la génération de rapports. :contentReference[oaicite:1]{index=1}
Autrement dit, le projet cherche à s’inscrire dans un environnement beaucoup plus large qu’une simple interface de conversation.
Le modèle n’est qu’une pièce du système. Autour de lui viennent les données, les outils réseau, l’authentification, les bases de données, les tâches automatisées, les journaux et les mécanismes de contrôle.
Une chaîne beaucoup plus intéressante apparaît
Si l’on regarde les différentes familles de dépendances du projet, une architecture logique commence à apparaître.
↓
COLLECTE DES DONNÉES
↓
ANALYSE PAR L’IA
↓
CORRÉLATION ET PRIORISATION
↓
IDENTIFICATION DU RISQUE
↓
RAPPORT ET REMÉDIATION
C’est là que le projet devient intéressant à observer : l’IA n’a plus seulement pour rôle de répondre. Elle peut devenir une couche d’interprétation placée entre les outils et l’analyste.
Le réseau reste le réseau. L’IA change la manière de le lire.
Nmap reste un outil de reconnaissance. Scapy reste une bibliothèque de manipulation et d’analyse réseau. Les sources OSINT restent des sources OSINT. Les bases CVE restent des bases de vulnérabilités.
Mais leur combinaison peut produire quelque chose de différent.
« Le futur du pentest ne sera peut-être pas un outil capable de tout faire. Il pourrait être une couche capable de comprendre ce que plusieurs outils ont découvert. »
Et c’est ici que l’architecture devient importante
HackGPT déclare des briques pour PostgreSQL, Redis et SQLAlchemy, ainsi que Celery pour le traitement de tâches. Le projet référence également Flask, FastAPI, Uvicorn et WebSockets pour sa couche applicative. :contentReference[oaicite:2]{index=2}
Ce détail peut sembler secondaire. Il ne l’est pas.
Dès qu’une plateforme commence à enchaîner reconnaissance, collecte, analyse et génération de rapports, le problème devient également un problème d’orchestration logicielle.
Elle la déplace. Il faut toujours gérer les permissions, les secrets, les journaux, les résultats erronés, les faux positifs, les limites des modèles et les actions réellement autorisées.
Docker et Kubernetes : le passage à l’échelle
Le dépôt référence également Docker, Kubernetes, Consul et plusieurs SDK cloud, notamment AWS, Azure et Google Cloud Storage. :contentReference[oaicite:3]{index=3}
Cela ne suffit pas à démontrer que toutes ces intégrations constituent aujourd’hui une fonctionnalité entièrement opérationnelle de la plateforme. Mais cela montre clairement l’orientation technique déclarée par le projet : penser l’outil comme une plateforme, et pas uniquement comme un script local.
HexaOS distingue ici ce que le dépôt déclare comme dépendances de ce qui est nécessairement démontré comme fonctionnalité complète. Une bibliothèque présente dans requirements.txt n’est pas, à elle seule, la preuve qu’une intégration est entièrement implémentée.
La conformité entre également dans le jeu
Autre élément intéressant : le projet référence des bibliothèques liées à CVSS, CVE et CPE. :contentReference[oaicite:4]{index=4}
Cela donne une autre dimension au système. Une vulnérabilité n’est pas seulement une ligne dans une sortie de scanner. Elle doit pouvoir être identifiée, contextualisée et éventuellement associée à une criticité et à un composant précis.
C’est exactement le genre de tâche où l’IA peut devenir intéressante : faire le lien entre des informations techniques qui existent déjà, mais qui sont dispersées.
Le vrai défi : faire confiance à la machine
Et c’est probablement ici que commence la partie la plus importante de l’histoire.
Une IA peut interpréter une information. Elle peut également se tromper sur son interprétation.
Dans un environnement de cybersécurité, cette différence est fondamentale. Une mauvaise classification peut faire perdre du temps. Une mauvaise priorisation peut détourner l’attention. Une automatisation mal contrôlée peut aller beaucoup plus loin.
HackGPT doit être utilisé uniquement sur des systèmes pour lesquels l’utilisateur dispose d’une autorisation explicite de test.
Ce que HackGPT change réellement
Il serait facile de présenter le projet comme une nouvelle génération de « hacker IA ». Ce serait pourtant passer à côté du sujet.
La tendance plus profonde est celle de l’orchestration.
Les outils spécialisés deviennent les capteurs. Les bases de données deviennent la mémoire. Les systèmes de monitoring deviennent les yeux. Les modèles d’IA deviennent une couche d’interprétation. Et l’analyste reste celui qui doit comprendre le contexte et prendre les décisions.
C’est potentiellement le rôle du pentester qui évolue : moins de temps consacré à assembler manuellement les résultats, davantage consacré à leur interprétation et à la décision.
Analyse HexaOS : le vrai saut n’est pas là où on le croit
L’image populaire du « hacker assisté par IA » met généralement le modèle au centre.
Pourtant, dans une architecture comme celle déclarée par HackGPT, le modèle n’est qu’un élément d’un système beaucoup plus large.
Le véritable changement se situe dans la capacité à faire circuler l’information entre des outils qui, historiquement, fonctionnaient chacun dans leur propre univers.
Si une IA peut comprendre les résultats de Nmap, les croiser avec une base de vulnérabilités, consulter des données complémentaires, les hiérarchiser puis produire un rapport…
sommes-nous encore simplement en train d’utiliser un outil, ou sommes-nous en train de construire une nouvelle interface pour le pentest ?
Ce qu’il faut retenir
OpenAI, Anthropic, Google et LiteLLM sont référencés dans les dépendances.
✔ Écosystème cybersécurité
Le projet référence notamment Scapy, python-nmap, Impacket, Shodan et Censys.
✔ Infrastructure
API web, bases de données, Redis, Celery, Docker et Kubernetes figurent parmi les briques déclarées.
✔ Vulnérabilités et conformité
CVE, CPE et CVSS apparaissent également dans l’environnement du projet.
Mais il faut garder une distinction essentielle : les dépendances décrivent l’architecture prévue ou utilisée, elles ne prouvent pas à elles seules que chaque fonctionnalité annoncée est pleinement opérationnelle.
Verdict HexaOS
HackGPT Enterprise est intéressant moins pour son nom que pour la direction qu’il révèle.
Le pentest possède déjà une multitude d’outils capables de scanner, cartographier, analyser et collecter. Le problème devient progressivement celui de la coordination.
L’IA pourrait devenir cette couche intermédiaire : celle qui transforme une succession de résultats techniques en une vision plus cohérente de la surface d’attaque.
Le futur n’est peut-être donc pas une IA qui pirate à la place de l’humain. C’est une IA qui aide l’humain à comprendre plus rapidement ce que ses outils ont découvert.
On ne regarde pas seulement les outils.
On regarde ce qu’ils commencent à construire ensemble.
Sources
Voir le projet sur GitHub
Article HexaOS — analyse fondée sur les éléments techniques publiquement déclarés dans le dépôt HackGPT. Utilisation uniquement dans des environnements autorisés, de laboratoire ou de test de sécurité.
