REA, l’outil viral qui confie la rétro-ingénierie aux agents d’IA : ce qu’il vaut, ce que dit le droit, et les faux dépôts à éviter

Ces derniers jours, un projet open source affole les compteurs de GitHub : REA, pour « Reverse Engineer Anything » (décortiquer n’importe quel logiciel), publié sur GitHub par le compte morluto. Le 8 octobre, le site AICoder lui comptait 12 962 étoiles ; le 14 octobre, le blog Developers Digest relevait que la bannière du projet remerciait déjà pour 180 000 étoiles, et que la discussion principale sur Hacker News avait atteint environ 800 points et plus de 330 commentaires. L’idée qui séduit tant : donner aux assistants de programmation fondés sur l’intelligence artificielle les outils des spécialistes qui dissèquent les logiciels. Nous avons regardé ce que l’outil fait vraiment, ce qu’il ne fait pas, ce que dit le droit, et pourquoi son succès attire déjà des copies douteuses.

La rétro-ingénierie consiste à comprendre comment fonctionne un logiciel sans disposer de son code source, en examinant le programme tel qu’il est livré. Les professionnels utilisent pour cela des décompilateurs, qui retraduisent le code machine en une forme proche d’un code lisible, parmi lesquels Ghidra, IDA ou Hopper. REA ne remplace pas ces outils : il les met à la disposition d’un agent d’IA. Techniquement, c’est un serveur MCP (Model Context Protocol), un protocole qui permet à un assistant comme Claude Code, Codex, Cursor ou Gemini CLI d’appeler des programmes extérieurs. Selon son dépôt, REA relie l’agent à des outils capables d’inspecter des programmes compilés, des applications JavaScript et Electron, des assemblages .NET et des sites web.

L’installation passe par le gestionnaire de paquets npm, avec la commande npx rea-agents setup : l’utilisateur choisit ses agents, examine les modifications proposées puis les approuve, et le programme sauvegarde la configuration existante avant d’y ajouter le serveur MCP. Le projet évolue très vite : la version 4.1.0, sortie le 6 octobre d’après AICoder, a ajouté l’analyse des applications Android (APK) avec JADX et celle des micrologiciels, le logiciel interne des appareils, avec Binwalk et Unblob. Le registre npm affiche désormais la version 6.5.0. Le dépôt insiste sur un point : l’analyse tourne localement, et chaque conclusion est accompagnée des éléments qui la fondent et de ses limites.

Il faut aussi comprendre ce que REA n’est pas. Il n’embarque pas son propre décompilateur : Hopper, Ghidra ou IDA Pro jouent ce rôle, et l’utilisateur doit se les procurer lui-même. Le dépôt précise que REA n’accorde aucune licence, clé ni activation pour ces outils, que les logiciels commerciaux comme IDA Pro doivent être obtenus légalement, et que les versions d’essai et de démonstration restent soumises aux conditions de leurs éditeurs, y compris pour l’automatisation et le partage des résultats. Brancher un agent sur une version de démonstration peut donc se heurter à ces conditions. À noter : l’inspection statique du JavaScript et du .NET se contente de lire les fichiers fournis, sans lancer l’application.

À l’essai, du bon et des angles morts

Le 14 octobre, le site HackerNoon a publié l’un des premiers essais détaillés, mené sur la version 6.4.0, sortie le 11 octobre, sur un poste Debian 13. L’auteur a fait analyser par REA une véritable application Electron, PI-Desktop. Résultat : 52 secondes pour un paquet de 100 Mo, un délai qu’il juge correct, et un verdict net sur l’analyse statique du JavaScript, « genuinely good and fast », autrement dit vraiment bonne et rapide. Il salue aussi l’honnêteté de l’outil, qui liste ses limites et précise lui-même, quand une recherche ne donne rien, que ce n’est pas la preuve que la fonctionnalité cherchée est absente.

Le même essai montre les angles morts. L’application testée contient deux fichiers de préchargement, les scripts qui font le lien entre l’interface et le reste du programme ; REA n’a pas établi ce lien et a donc conclu qu’aucun élément n’était exposé. Le rapport signalait 744 limitations, et pour 365 fichiers l’outil a abandonné des relations faute de budget de résultats, si bien que le traçage d’un échange réel n’a rien donné. Autre coût caché : REA expose 170 outils MCP, dont la seule liste pèse environ 1,95 Mo de JSON (un format de données) avant même que l’agent ne fasse quoi que ce soit. Enfin, l’auteur n’a testé ni Hopper, ni Ghidra, ni IDA, ni les APK, ni les micrologiciels : l’essentiel de la promesse reste à évaluer.

Le projet reconnaît lui-même que la décompilation, la reconstruction, les heuristiques et l’analyse assistée par IA peuvent être incomplètes ou erronées. Deux précautions s’imposent donc. D’abord, si l’analyse tourne sur la machine, l’agent reçoit les résultats, et ce sont les règles du fournisseur du modèle d’IA en matière de données qui s’appliquent à ces résultats : une entreprise qui examine un logiciel interne peut ainsi en transmettre des morceaux à un service tiers. Ensuite, la capture à l’exécution lance le programme ciblé ou interagit avec lui avec les droits de l’utilisateur. Le projet recommande d’ailleurs un environnement adapté aux cibles non fiables : un programme douteux s’examine dans une machine virtuelle, pas sur son poste de travail.

Ce que dit le droit

REA se présente comme un outil d’analyse licite : recherche en sécurité, analyse de logiciels malveillants et d’incidents, interopérabilité, préservation des logiciels, ou examen de programmes que l’on possède ou que l’on est autorisé à étudier. Son avertissement exclut le contournement des DRM (les verrous numériques), des contrôles de licence et des systèmes anti-triche, ainsi que la copie de logiciels propriétaires ou de leur code. Le dépôt ajoute que les copies piratées, les clés volées ou partagées sans autorisation et le contournement des restrictions de licence ne sont pas autorisés. Il rappelle enfin que la rétro-ingénierie peut être restreinte selon le pays, ou par la licence du logiciel analysé.

En France, c’est l’article L. 122-6-1 du Code de la propriété intellectuelle qui fixe le cadre. La personne qui a le droit d’utiliser un logiciel peut, sans autorisation de l’auteur, en observer, étudier ou tester le fonctionnement ou la sécurité afin d’en déterminer les idées et principes. La décompilation proprement dite, c’est-à-dire la reproduction ou la traduction du code, n’est permise que lorsqu’elle est indispensable pour obtenir les informations nécessaires à l’interopérabilité d’un logiciel créé de façon indépendante, et à des conditions strictes : être en droit d’utiliser le logiciel, que ces informations n’aient pas déjà été rendues facilement et rapidement accessibles, et s’en tenir aux parties nécessaires. Les informations obtenues ne peuvent servir à aucune autre fin que cette interopérabilité, ni à produire ou commercialiser un logiciel substantiellement similaire.

Obtenir un résultat qui ressemble à du code source, ou un rapport d’analyse, ne confère aucun droit sur le programme d’origine : c’est l’avertissement de REA lui-même.

Cette frontière compte d’autant plus que REA met ces analyses à la portée de n’importe quel utilisateur d’un agent d’IA. Comprendre comment un logiciel échange ses données pour le rendre compatible avec un autre, ou tester la sécurité d’un programme que l’on a le droit d’utiliser, reste légitime. Reconstruire une application commerciale pour en diffuser un clone, ou faire sauter une protection, ne le devient pas parce qu’une IA a fait le travail. Les conditions d’utilisation des logiciels analysés comptent aussi : certaines licences restreignent la rétro-ingénierie, et le dépôt de REA renvoie explicitement l’utilisateur à cette responsabilité.

Gare aux faux dépôts

Le succès a son revers. Le dépôt officiel indique qu’on obtient REA depuis morluto/rea, le site rea.tools ou le paquet npm rea-agents, et prévient que un nom de dépôt ressemblant ou un fichier de présentation recopié ne prouvent pas qu’un téléchargement est officiel. La mise en garde n’a rien de théorique. Un dépôt GitHub nommé rea-githu/REA propose une archive ZIP pour Windows présentée comme la version 6.3.0 du 10 octobre 2026, avec une description truffée de mots-clés (« rea github, github rea, reverse engineer anything ») et la mention « Official free download ».

Nous n’avons pas analysé cette archive, et rien ne permet d’affirmer ici qu’elle est malveillante. Mais rien ne la rattache non plus aux trois canaux officiels, et le dépôt du projet documente une installation par la commande npx rea-agents setup, pas une archive à télécharger puis à décompresser sur son poste. Quand un outil devient viral, ceux qui cherchent à le télécharger peuvent tomber sur ce genre de copie, dont la description truffée de mots-clés semble viser les moteurs de recherche. Pour un logiciel qui manipule des programmes et s’exécute avec les droits de l’utilisateur, l’erreur peut coûter cher. La règle reste simple : partir du dépôt officiel, jamais d’un lien trouvé au hasard.

Pour une TPE, une PME ou un particulier, REA n’est pas un outil du quotidien. Il intéresse d’abord les équipes de sécurité, les développeurs qui doivent faire dialoguer deux logiciels, ou les curieux qui veulent savoir ce que fait réellement une application. Si vous l’essayez, faites-le dans une machine virtuelle, sur des logiciels que vous avez le droit d’examiner, en sachant que les résultats partent chez le fournisseur de votre agent d’IA et qu’ils peuvent être faux. Et si l’on vous propose une version Windows à télécharger en dehors des canaux officiels, abstenez-vous. Dans la mesure de nos disponibilités, nous pouvons aider bénévolement et gratuitement à vérifier la provenance d’un outil avant de l’installer.