Le logiciel avait l'habitude de se cacher. Compilé, minifié, sans symboles, livré sous forme de blocs opaques qu'on ne pouvait tâter que de l'extérieur. Cette époque s'est terminée discrètement en avril 2026, et en octobre le monde du développement tout entier l'avait remarqué.
REA, pour Reverse Engineer Anything, est devenu l'un des dépôts à la croissance la plus rapide que GitHub ait jamais hébergés : environ 262 000 étoiles et 66 000 forks, le tout sur un seul projet sous licence MIT qui n'existait pas il y a huit mois. Ce n'est ni une fuite de base de données ni une panique de jour zéro. C'est plus grand et plus étrange. REA donne à votre agent de code IA les clés pour inspecter n'importe quel logiciel, jusqu'à l'assembleur brut, et expliquer comment il fonctionne réellement.
Si vous construisez, achetez ou défendez du logiciel, cela change vos calculs. Voici ce qu'est vraiment REA, ce qu'il peut et ne peut pas faire, et ce que cela signifie pour votre entreprise.
Ce qu'est réellement REA
REA est une CLI et un serveur MCP. Cette seconde partie est la plus importante. Le Model Context Protocol est le standard ouvert qui permet aux agents comme Claude Code, Codex, Cursor, Gemini CLI et Grok Build d'appeler des outils externes. REA s'y branche et donne à votre agent une boîte à outils complète de rétro-ingénierie.
Pointez-le vers une app, un binaire ou un site web, puis posez une question en langage courant. Pourquoi le dinosaure accélère-t-il ? Comment cet authenticator génère-t-il mon code de connexion ? REA renvoie les preuves : pseudo-code, assembleur, chaînes de caractères, symboles, graphes d'appels et observations à l'exécution. Votre agent lit ces preuves, explique le comportement, puis peut reconstruire la fonction pour votre propre projet.
Tout tourne en local. Rien ne part vers le cloud de quelqu'un d'autre. Et surtout, REA renvoie ses preuves et ses limites côte à côte. Il vous dit ce qu'il a trouvé et où la conclusion devient fragile.
Les cibles qu'il peut ouvrir
C'est là que la portée devient vraiment large. REA n'est pas un décompilateur à un seul tour. Sa documentation officielle couvre :
- Binaires natifs : pseudo-code, assembleur, chaînes, symboles, appels et références, propulsés par Hopper, Ghidra ou IDA
- Applications JavaScript et Electron : modules, imports, source maps, routes et frontières IPC
- Assemblys .NET : métadonnées, instructions CIL et dépendances natives
- Sites web : structure des pages, scripts et observations réseau depuis une vraie session de navigateur
- APK Android : déclarations du manifeste, classes et méthodes décompilées
- Binaires Go et Rust : listes de modules intégrés, noms de crates, versions et arêtes de dépendance
- Firmware, WASM, bytecode EVM, bases SQLite, apps Flutter et captures de paquets
Les guides, les étapes d'installation et les études de cas se trouvent sur le site du projet, rea.tools. Le site parcourt de vraies enquêtes : pourquoi la calculatrice Windows transforme 200 + 10% en 220 (elle prend un pourcentage du premier nombre après un plus), comment Notion copie les données de blocs enrichis dans le presse-papiers, ou comment un jeu de 1996 calculait le panoramique sonore gauche-droite. Chaque affirmation renvoie aux instructions réelles et se recoupe avec le code public.
Ce qu'il ne peut pas faire (lisez cette partie deux fois)
REA ne récupère pas le code source original. Il reconstruit la logique et le comportement. Cette distinction sépare un outil d'ingénierie utile de la pensée magique, et qui promet le contraire vous vend une histoire, pas une capacité.
Il n'est pas non plus sans friction. L'analyse native exige un vrai moteur installé : Hopper, Ghidra ou IDA. Certaines cibles demandent des outils supplémentaires, comme JADX pour Android ou TShark pour les paquets. Le projet avance vite, vous mettrez donc à jour souvent.
Ensuite vient le bruit. Un dépôt aussi populaire attire les imitateurs et les arnaques. Des dépôts copiés réutilisent le nom et recopient le README, et de faux téléchargements REA ont déjà fait surface. Les sources légitimes sont étroites : github.com/morluto/rea, rea.tools et le paquet rea-agents sur npm. Tout le reste mérite la méfiance.
La partie que tout dirigeant doit entendre
Voici la vérité inconfortable que REA vient de rendre évidente : si votre application livre de la logique sur la machine de l'utilisateur, cette logique n'est plus un secret.
Pas difficile à trouver. Pas assez obscurcie. Lisible. La minification, le packing et la suppression des symboles ralentissent un humain. Ils ralentissent à peine un agent IA capable de suivre un graphe d'appels sur des milliers d'instructions en quelques secondes.
Cela ne veut pas dire que votre produit ne vaut soudain plus rien. Cela veut dire que votre forteresse doit se déplacer. Les parties défendables du logiciel moderne n'ont jamais vraiment été dans le client :
- Gardez les joyaux côté serveur. Règles de prix, algorithmes de scoring, logique antifraude et données propriétaires appartiennent à votre API, pas compilés dans une app que quelqu'un peut déballer.
- Ne livrez jamais de secrets. Les clés d'API, jetons et identifiants dans le code client ont toujours été une mauvaise idée. REA vient de transformer quelqu'un les trouvera en une certitude.
- Concurrencez par l'expérience et l'exécution, pas par le secret. Une excellente UX, la fiabilité, le support, les intégrations et la vitesse d'itération sont bien plus durs à cloner qu'une fonction.
- Isolez tout ce qui n'est pas de confiance. Un outil de rétro-ingénierie inspecte par nature du code hostile. Lancez-le dans une machine virtuelle isolée, jamais sur une machine qui contient vos vraies données.
- Connaissez la ligne légale. Les audits de sécurité, l'interopérabilité, l'apprentissage et la récupération de votre propre code perdu sont généralement légitimes. Cloner le produit d'un concurrent ou contourner un DRM ne l'est pas, et l'outil ne blanchit pas l'intention.
La conclusion
REA est le signal le plus clair que la transparence logicielle est désormais la norme. Les agents de vos utilisateurs peuvent lire votre app. Ceux de vos concurrents aussi. La question n'est pas de savoir si votre logique est visible. Elle est de savoir si vous avez construit quelque chose qui survit au fait d'être vu.
Pour les développeurs, c'est libérateur : étudiez comment fonctionnent les meilleures apps, puis construisez mieux. Pour les entreprises, c'est une invitation à auditer ce que vous livrez vraiment. Ouvrez le bundle client et demandez-vous ce que vous trouveriez si un agent curieux commençait à tirer sur les fils.
Car en ce moment même, l'agent de quelqu'un tire déjà.
Sources : le projet REA (github.com/morluto/rea et rea.tools), l'analyse approfondie de Nate's Newsletter sur REA, et la couverture de Geeky-Gadgets et des guides de la communauté REA.