jadx-ai-mcp : brancher un LLM sur le décompilateur JADX via MCP
Plugin for JADX to integrate MCP server
En bref
- De quoi s’agit-il ?
- Un plugin Java pour JADX qui expose les classes décompilées à un client compatible Model Context Protocol. L'idée est bonne, l'exécution dépend d'un second dépôt et la documentation reste mince sur plusieurs points.
- À qui s’adresse-t-il ?
- À adopter si vous décompilez déjà des APK avec JADX et que vous voulez donner à un client MCP un accès structuré au code décompilé sans écrire votre propre couche d'exposition. À éviter si vous cherchez un scanner SAST autonome ou un outil dont le comportement est documenté de bout en bout.
- Puis-je l’utiliser commercialement ?
- Oui. Apache-2.0 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. Les derniers commits datent d’il y a 17 jours.
- En quel langage est-il écrit ?
- Principalement Java, 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 : le décompilé n'est pas interrogeable
JADX produit du Java lisible à partir d'un APK, mais il le produit pour un humain qui clique dans une arborescence de paquets. Un LLM, lui, ne peut pas cliquer. Il faut lui livrer des classes, des méthodes et des chaînes de caractères sous une forme qu'il puisse demander à la carte, sans recopier des milliers de lignes dans une fenêtre de contexte. C'est précisément le vide que jadx-ai-mcp prétend combler : le dépôt se décrit comme un plugin JADX qui s'intègre au Model Context Protocol pour fournir, selon le README, un support de reverse engineering en direct avec des LLM comme Claude. Le public visé est étroit : analystes mobiles, pentesters, équipes VAPT et SAST qui manipulent déjà des APK et connaissent JADX. Le tag pentesting du dépôt le confirme. Ce n'est pas un outil pour développeur Android qui veut comprendre sa propre application : c'est un outil pour quelqu'un qui inspecte le binaire d'un tiers.
Deux dépôts, un seul protocole
Le point d'architecture le plus important est aussi le plus facile à manquer. Le README renvoie explicitement à un second dépôt, JADX-MCP-SERVER, et les badges de contributeurs en haut de page couvrent les deux projets. Autrement dit, le plugin seul ne suffit pas : il y a une partie Java côté JADX et une partie serveur côté MCP, et c'est la paire qui parle au client LLM. Le README indique Java 11+ et Python 3.10+ comme prérequis, ce qui colle à cette répartition, le serveur MCP étant vraisemblablement écrit en Python. Le flux est donc le suivant : JADX charge le plugin, le plugin expose les artefacts de décompilation, le serveur les présente comme des outils MCP, le client les appelle. Chaque maillon ajoute une surface de panne. Si le serveur n'est pas lancé, le plugin ne sert à rien. Si les deux versions divergent, le contrat d'outils peut changer sous vos pieds. La release v6.3.0 s'intitule Remote Host Support, ce qui suggère que le serveur peut tourner ailleurs que sur la machine qui exécute JADX, mais le README fourni ne détaille pas la configuration correspondante.
Installation : ce que le README permet réellement d'écrire
C'est ici qu'il faut être franc. Le matériau fourni ne contient aucune commande d'installation, aucun chemin de fichier de configuration, aucune clé de configuration. Le README annonce une documentation en ligne sur jadx-ai-mcp.readthedocs.io et donne l'exemple minimal d'un flux conceptuel, la décompilation qui alimente le LLM, sans le développer. Je ne peux donc pas vous donner de commande gradle, de chemin de plugin JAR ni de bloc JSON de configuration client sans inventer. Ce que l'on peut affirmer à partir du dépôt : la branche par défaut est jadx-ai, ce qui indique un fork maintenu en parallèle de JADX plutôt qu'un plugin greffé sur une version publiée du décompilateur. C'est un détail qui a des conséquences pratiques. Un plugin branché sur une API stable de JADX se contente de suivre les versions du décompilateur. Un fork de branche doit suivre les deux projets à la fois. Avant toute chose, ouvrez la documentation Read the Docs : c'est la seule source d'instructions d'installation que ce dépôt désigne.
La recherche a été refaite en v6.4.0, et c'est révélateur
La version v6.4.0 porte le libellé Search Infrastructure Overhauled. Ce détail en dit plus que n'importe quelle description marketing. Si l'infrastructure de recherche a dû être refaite, c'est que la première version ne tenait pas la charge ou ne renvoyait pas des résultats exploitables. Or la recherche est le cœur du problème : un LLM qui demande les classes contenant une chaîne donnée doit obtenir une réponse courte et pertinente, pas l'intégralité du dex. Un mauvais classement des résultats et le contexte du modèle se remplit de bruit, ce qui dégrade directement la qualité de l'analyse. La mention de cette refonte dans le titre de release, plutôt que dans une note de bas de page, suggère que le mainteneur la considère comme structurante. Cela signifie aussi que toute évaluation antérieure à mai 2026 ne dit rien de la version actuelle. Le dépôt a été poussé pour la dernière fois le 30 août 2026 et la dernière release listée est V6.4.1 du 6 août 2026 : la cadence est soutenue, avec trois releases majeures en quelques mois.
Le cas où l'outil est le mauvais choix
Il y a un commentaire HTML dans le README qui mérite d'être cité : le projet est décrit comme encore à un stade précoce de développement, avec des bogues, des plantages et des erreurs logiques à attendre. C'est le mainteneur qui l'écrit, pas un détracteur. Prenez-le au sérieux. Un outil qui plante au milieu d'une session d'analyse ne fait pas perdre une compilation, il fait perdre le contexte accumulé dans la conversation avec le modèle. Plus gênant pour un usage professionnel : rien dans le matériau fourni ne décrit de gestion des secrets, de journalisation des appels d'outils ou de traçabilité des conclusions. Si votre livrable est un rapport d'audit signé, un pipeline dont vous ne pouvez pas reconstituer les étapes est un problème de conformité, pas seulement de confort. Et si votre besoin est de détecter des motifs de vulnérabilité à grande échelle sur des milliers d'APK, un plugin interactif branché sur un LLM est structurellement inadapté : vous voulez un scanner déterministe, reproductible, exécutable en CI.
Face à quoi : MobSF et l'analyse statique classique
L'alternative la plus directement comparable est Mobile Security Framework (MobSF), un cadre d'analyse statique et dynamique d'applications mobiles. La différence d'approche est nette. MobSF applique un ensemble de règles et de signatures prédéfinies, puis produit un rapport avec un score et une liste de constats. Le résultat est reproductible : deux exécutions sur le même APK donnent le même rapport, ce qui est exactement ce qu'attend un processus d'audit. jadx-ai-mcp fait l'inverse. Il ne décide pas ce qui est une vulnérabilité, il donne à un modèle la capacité d'explorer le code décompilé et de raisonner dessus. Cela permet de poser des questions ouvertes, du type pourquoi cette classe construit une URL à partir d'une préférence utilisateur, ce qu'un moteur à règles ne formulera jamais. En contrepartie, deux sessions peuvent aboutir à deux conclusions différentes, et rien dans le dépôt ne suggère un mécanisme de reproductibilité. Les deux outils ne s'excluent pas, mais ils ne répondent pas à la même question.
Maintenance, licence et coût réel
Le rythme de publication est le principal signal positif : V6.4.1 en août 2026, v6.4.0 en mai, v6.3.0 en mars. Un projet qui bouge à cette cadence impose une charge de mise à jour. Comme il s'agit d'un fork sur la branche jadx-ai, chaque montée de version de JADX en amont peut demander une reprise, et il faut suivre simultanément le dépôt du plugin et celui du serveur MCP. Prévoyez de figer les versions des deux côtés plutôt que de suivre la tête de branche. Sur la licence, le dépôt est publié sous Apache-2.0, une licence permissive qui autorise l'usage commercial et la modification, avec les obligations habituelles de conservation des mentions de copyright et du fichier de licence, et une clause de brevets. Deux réserves que je ne peux pas lever avec le matériau disponible : le dépôt est un fork de JADX, lui-même sous Apache-2.0, donc la compatibilité est cohérente, mais je ne peux pas confirmer la licence du dépôt serveur JADX-MCP-SERVER, qui n'est pas fournie ici. Vérifiez-la séparément si votre service juridique doit valider l'ensemble. Je ne donne pas d'avis juridique, seulement l'identifiant de licence et les points à contrôler.
Conclusion éditoriale
À adopter si vous décompilez déjà des APK avec JADX et que vous voulez donner à un client MCP un accès structuré au code décompilé sans écrire votre propre couche d'exposition. À éviter si vous cherchez un scanner SAST autonome ou un outil dont le comportement est documenté de bout en bout. Avant de vous engager, lisez la documentation sur jadx-ai-mcp.readthedocs.io, vérifiez la version de JADX requise par le plugin et confirmez que les deux dépôts, plugin et serveur, publient au même rythme.
Notes de la communauté