DeepDive · Rétro-ingénierie assistée par IA

REA (Reverse Engineer Anything) : l’IA qui comprend un logiciel sans son code source

Par André Gentit, fondateur de DeepDive · Publié le 11 octobre 2026

Certains projets open source portent un nom qui est déjà une promesse. « Reverse Engineer Anything » en fait partie : tout, vraiment ? Spoiler : pas tout, pas n’importe comment, et surtout pas sans autorisation. Mais assez de choses, et assez bien, pour que l’équipe DeepDive y consacre un guide entier.

REA, c’est quoi ? Un décompilateur qui sait enfin se faire comprendre

REA, pour Reverse Engineer Anything, est un projet open source publié sur GitHub sous le pseudonyme morluto. Son principe tient en une phrase : donner à un agent de programmation les outils pour examiner un logiciel sans disposer de son code source, comprendre comment une fonctionnalité marche, produire des éléments de preuve, puis aider à en recréer une version adaptée à votre propre projet.

Le projet est tout sauf confidentiel. Début octobre 2026, il est remonté dans les tendances GitHub, et son dépôt affiche près de 89 000 étoiles. Un annuaire de skills en affiche encore 14,9 k : ce chiffre date de la préhistoire, c’est-à-dire de juillet.

Décompiler, comprendre, recréer : le mode d’emploi en trois verbes

Le projet résume sa démarche en trois verbes. Le déroulé est toujours le même :

1. Vous posez une question précise à l’agent, par exemple : « Comprends comment cette application calcule les remises ».
2. L’agent emploie REA pour examiner le programme : chaînes de caractères, fonctions, appels, modules et, selon le cas, comportement à l’exécution.
3. REA renvoie des résultats accompagnés d’éléments vérifiables : pseudocode, assembleur, références, modules JavaScript, traces réseau.
4. L’agent explique le mécanisme observé et peut proposer une réimplémentation originale.

Un serveur MCP, une CLI et une couche d’orchestration

Techniquement, REA est trois choses à la fois :

• un serveur MCP (Model Context Protocol) : il permet à un agent IA d’appeler des outils locaux spécialisés ;
• une CLI utilisable directement dans un terminal ;
• une couche d’orchestration au-dessus d’outils classiques de rétro-ingénierie, tels que Ghidra, Hopper ou IDA pour les binaires natifs.

Son intérêt n’est donc pas de remplacer les outils traditionnels, mais de les rendre exploitables par un agent conversationnel. Au lieu de demander à un développeur de jongler entre désassembleur, décompilateur, recherches de chaînes et graphes d’appels, on formule une demande fonctionnelle. REA cherche les parties pertinentes, l’agent relie les observations à une explication et à du code.

Sous le capot : trois couches, trois rôles, zéro magie

REA n’est pas un moteur de rétro-ingénierie unique. C’est un pont contrôlé entre un agent et des moteurs spécialisés. Le chemin est le suivant : l’agent envoie sa question via le protocole MCP ; REA pilote la session, normalise les résultats et trace les preuves ; les moteurs font l’analyse effective selon le format de la cible.

Qui fait quoi ?

1. L’agent IA (Claude Code, Codex, Cursor, Gemini CLI ou tout client MCP local) décide des requêtes, interprète les sorties, formule des hypothèses, demande des vérifications et peut écrire un prototype.
2. REA fournit l’interface unifiée, pilote les sessions, normalise les résultats et assure la traçabilité des preuves.
3. Les moteurs spécialisés réalisent le travail technique : désassemblage, décompilation, inspection de fichiers, capture navigateur, décodage de ressources.

Cette séparation est une excellente base de formation : trois couches que l’on confond sans cesse, alors que seule la troisième fait de la rétro-ingénierie au sens strict.

L’IA n’est pas un décompilateur (et c’est plutôt rassurant)

Dire « l’IA a décompilé le logiciel » est pratique, mais inexact. Le modèle raisonne sur des résultats fournis par des outils déterministes. S’il se trompe, la preuve est là pour le contredire. Sans REA, vous obtiendriez surtout un modèle qui devine avec aplomb, ce qui est un passe-temps national chez les LLM.

100 % local ? Presque

L’analyse s’exécute sur votre machine : REA n’envoie pas l’application à un service d’analyse hébergé. Mais votre agent reçoit les résultats, et le fournisseur de son modèle applique sa propre politique de données.

Ce que REA sait manger : du .exe de 1996 au site web

REA couvre plusieurs familles de cibles, mais pas de manière identique : le niveau d’analyse dépend du type de logiciel et des moteurs installés. Le code couleur ci-dessous indique ce qu’il faut prévoir.

autonome · outil à installer · outil à fournir et configurer vous-même · dépend de l’OS

Le raccourci : « j’ai ceci, il me faut cela »

Prérequis et pièges selon votre système

REA exige Node.js 22.19+, 24.11+ ou 26+, plus npm. Pour les binaires natifs, le détail dépend du moteur :

• Ghidra : installation existante requise ; les configurations documentées indiquent Ghidra 12.1.x et JDK 21+, surtout sous Linux et macOS. Windows est décrit comme expérimental, en lecture seule, pour certains binaires PE x86/x64.
• Hopper : REA détecte une installation existante ou propose de l’installer après votre accord (macOS). Il démarre Hopper tout seul quand une opération l’exige ; une boîte de dialogue peut vous demander de choisir entre mode démo et activation de licence.
• IDA : REA s’appuie sur une configuration MCP IDA déjà existante ; les scénarios validés sont principalement sous Windows.

Lire n’est pas allumer : statique contre exécution

L’inspection statique de JavaScript et de .NET lit les fichiers sans lancer l’application. Les analyses d’exécution, elles, démarrent ou manipulent la cible avec les permissions de l’utilisateur. Ce n’est donc pas une opération totalement passive.

Observations, inférences, inconnus : l’anti-baratin de REA

Chaque résultat arrive avec ses éléments vérifiables et ses limites. Le projet insiste sur un point essentiel : le pseudocode reconstruit est une interprétation, jamais le code source d’origine. Un guide vidéo détaille un tri en trois catégories, très utile en formation :

1. Observations : faits directement vérifiés (un import détecté, une constante explicite).
2. Inférences : déductions logiques tirées des appels et des flux de données.
3. Inconnus : zones que l’outil ne peut pas certifier. L’agent doit poser une question ou vérifier par comparaison, au lieu d’inventer.

Un article indépendant le rappelle : REA n’établit pas qu’une recréation est complète, identique ou autorisée. Le dernier mot reste à un humain.

Installation pas à pas

Compter quelques minutes si Node.js est déjà là. Voici l’ordre des opérations.

Les sept étapes

1. Vérifier Node.js : node -v doit afficher 22.19+, 24.11+ ou 26+. Sinon, mettez à jour, par exemple avec brew upgrade node sous macOS.
2. Lancer l’assistant : il liste les agents détectés, enregistre le serveur MCP, ajoute les instructions de workflow et sauvegarde vos configurations existantes.
3. Prévisualiser sans écrire : l’option --dry-run montre toutes les modifications avant de les appliquer.
4. Redémarrer l’agent pour qu’il voie le nouveau serveur.
5. Installer la CLI pour un usage régulier.
6. Vérifier la liaison avec la commande doctor.
7. Option moteur natif : configurer Ghidra, Hopper ou IDA pour les binaires.

# 1. Vérifier la version de Node.js
node -v

# 2. Assistant d'installation interactif
npx rea-agents@latest setup

# 3. Simulation : aucune écriture sur le disque
npx rea-agents setup --dry-run

# 5. CLI pour usage régulier
npm install --global rea-agents
rea --help

# 6. Vérifier la liaison avec votre agent (exemple : Codex)
rea doctor client codex --json

Tester sans moteur natif

Une application Electron suffit pour un premier essai, puisque l’analyse statique de JavaScript n’exige aucun moteur natif :

npx -y rea-agents@latest analyze-javascript-application /chemin/absolu/vers/app --json

Le résultat liste les modules, les imports, les frontières Electron et les preuves associées.

Deux variantes utiles

• Skill seul : npx skills add morluto/rea ajoute les instructions d’investigation à votre agent, sans enregistrer le serveur MCP. L’installation du skill ne remplace pas le setup.
• Mises à jour : REA évolue vite. Avec la CLI globale, rea update ; avec npx, relancez npx rea-agents@latest setup, puis redémarrez l’agent.

Les démonstrations qui parlent : cinq cas, dont un à ne pas imiter

Rien ne vaut un exemple. Les quatre premiers viennent des études de cas du projet ; le dernier vient de démonstrations vidéo.

pan = position - 500;

google-chrome --remote-debugging-port=9222 "https://votre-site-de-test.example"

Et chez vous ? Six scénarios et cinq prompts pour une PME

REA sert surtout quand le code est perdu, incomplet ou impossible à relire, et qu’il faut d’abord comprendre ce que le logiciel fait. Les scénarios ci-dessous sont des illustrations imaginées par DeepDive, pas des retours d’expérience clients.

Six scénarios illustratifs

Bonne idée, mauvaise idée

Cinq prompts prêts à l’emploi

Adaptez-les à votre cible. Ils fonctionnent mieux avec une question précise qu’avec un « explique-moi ce logiciel ».

1. « Utilise REA pour comprendre comment cette application calcule les remises. Montre-moi les preuves, puis écris la même règle en Python. »
2. « Analyse ce dossier Electron et cartographie les modules, les routes et les canaux IPC. Sépare ce qui est observé de ce qui est supposé. »
3. « Inspecte les scripts chargés et les requêtes réseau de cette page, et liste les tiers qui s’y connectent. »
4. « Décompile le manifest et les classes de cet APK, et liste les permissions et les points d’accès réseau. »
5. « Compare ces deux versions de l’assembly .NET et résume les différences de comportement. »

Le « Anything » est un argument marketing, pas un permis

Le nom est volontairement accrocheur, mais il ne signifie pas que tout est techniquement, contractuellement ou légalement analysable. Le dépôt précise que l’utilisateur doit obtenir les autorisations requises et respecter le droit applicable. La voie saine consiste à utiliser REA sur vos propres logiciels, des logiciels open source, des logiciels pour lesquels vous avez une autorisation écrite, ou dans un audit de sécurité mandaté.

Un repère juridique européen

En Europe, la directive 2009/24/CE sur la protection juridique des programmes d’ordinateur n’autorise la décompilation qu’à des conditions strictes, notamment pour l’interopérabilité. Les conditions d’utilisation du logiciel visé peuvent aussi l’interdire. Ce repère est donné à titre indicatif et n’est pas un avis juridique : faites valider votre cas par un juriste.

Hygiène de sécurité

• Analysez les binaires inconnus dans une machine virtuelle ou un conteneur isolé du réseau principal.
• Gardez REA et ses moteurs (Ghidra, JDK, Node.js) à jour pour éviter l’exploitation de vulnérabilités d’analyseur.
• Rappelez-vous que l’agent reçoit les résultats : la politique de données de son fournisseur s’applique.
• Méfiez-vous des jetons ou cryptomonnaies qui reprennent le nom REA : le projet déclare n’en avoir émis aucun.

Le code n’est plus une douve : et maintenant ?

Si un agent peut déduire une logique fonctionnelle à partir d’un exécutable, le code livré côté client protège moins qu’avant. Un créateur de contenu cité dans les démonstrations résume l’idée : la valeur se déplace vers la marque, la communauté, l’expérience utilisateur et les données propriétaires.

Pour un éditeur ou une PME qui développe ses outils, quatre réflexes s’imposent :

1. Déplacer la logique critique côté serveur et réduire ce qui s’exécute chez le client.
2. Protéger les données : chiffrement, flux réseau maîtrisés, secrets jamais embarqués.
3. Miser sur l’expérience et le service, qu’un simple clone de code ne reproduit pas.
4. Compter sur le droit autant que sur la technique : contrats, licences, conditions d’utilisation.

REA contre l’approche manuelle : lecture DeepDive

Ce tableau est notre appréciation, pas une mesure. Il dépend de la cible et de l’expérience de l’équipe.

FAQ : vos questions sur REA

Verdict DeepDive : comprendre, oui ; photocopier, non

Résumons. REA fait passer la rétro-ingénierie d’un métier de spécialiste à une conversation guidée par des preuves. Il orchestre en local de vrais moteurs, sépare observations, inférences et inconnus, et s’installe en une commande. Sa limite tient à la responsabilité de l’utilisateur : cible légitime, autorisation, relecture humaine.

Et maintenant ? La vraie question n’est plus « peut-on lire un logiciel sans son code source ? », mais « que se passe-t-il quand n’importe qui peut lire le vôtre ? ». Combien de règles métier de votre entreprise ne vivent que dans un exécutable que personne n’ose ouvrir ? Si vous voulez en parler, ou monter un atelier REA en trois couches pour vos équipes, DeepDive est là pour ça.

Sources

• Dépôt GitHub morluto/rea : README, cibles, installation, études de cas, avertissement légal (consulté le 11 octobre 2026)
• Site du projet REA et ses études de cas (DX-Ball, Notion, TH04)
• Runtime Wire : analyse du projet et de ses limites
• Fiche skills.sh du skill REA
• Démonstrations vidéo (Stripe, Whisper Flow, DX-Ball, Notion) : citées à titre indicatif, détails non revérifiés