Les limites réelles de REA : taille des sorties, coût, couverture

Le 11 octobre 2026, l'analyse statique d'une application Electron de 100 Mo par REA 6.4.0 a pris 52,2 secondes et produit un fichier JSON de 59,2 Mo. L'outil va vite. Son point faible se mesure en octets : volume des sorties, poids du catalogue d'outils dans le contexte de l'agent, et angles morts qu'aucun compteur ne signale.

Des sorties énormes

Ishank Choudhary a mesuré chaque étape de son test, publié sur HackerNoon le 14 octobre¹. Sur l'application PI-Desktop v0.16.1, REA a parcouru 421 fichiers JavaScript et 3 114 427 nœuds d'arbre syntaxique, sans un seul échec de parsing, pour écrire 59,2 Mo de résultats. Un unique appel MCP de résumé a duré 60,5 secondes et renvoyé 1 350 868 octets, dont 672 Ko de texte. Un modèle de langage qui reçoit 1,35 Mo pour un « résumé » sature sa fenêtre de contexte avant d'avoir posé sa deuxième question.

Le volume grossit avec la cible. Javier Cañete Arroyo (Jacar Systems) a passé Hyper 3.4.1 à REA 6.7.0 : un app.asar de 14 Mo, 2 236 fichiers, 18 canaux IPC, et un JSON de preuves de 253 Mo². Connor Turland a obtenu 158 Mo sur Slack 4.52.171³. Ces fichiers servent d'archive de preuves. L'agent, lui, doit interroger REA par petites questions ciblées, faute de quoi il noie sa propre fenêtre.

Un catalogue d'outils qui pèse avant la première action

En 6.4.0, REA exposait 170 outils MCP. La liste de leurs définitions (tools/list) pesait 1 954 704 octets, soit selon l'estimation de Choudhary, à quatre caractères par token, « roughly half a million tokens » avant toute action¹. Le profil compact de l'époque ne la réduisait qu'à 1 772 775 octets, environ 9 % de moins. Un petit modèle local ne pouvait pas charger cette liste.

Mise à jour du 20 octobre 2026. Le constat a changé avec la version 6.7.0, publiée sur npm le 18 octobre⁴. Selon le test de Javier Cañete Arroyo du 19 octobre, REA expose désormais 207 outils, 6 prompts et 153 commandes en ligne de commande ; la liste complète pèse 3 158 352 octets, et le profil compact la ramène à 219 211 octets². Le profil compact divise donc le poids du catalogue par plus de quatorze. Activez-le par défaut si votre client MCP le prend en charge, et mesurez vous-même : REA publie des versions presque chaque jour, et ces chiffres datent d'une version précise.

L'installation a aussi un coût : 222 Mo et 158 dépendances dans le test de Jacar Systems.

Une couverture partielle, pas toujours signalée

REA dit beaucoup de ce qu'il ignore : 744 limitations explicites sur l'application de 100 Mo, dont 365 liées au budget de résultat. Il rate aussi des choses sans le dire. Sur la même application, il a annoncé zéro script preload alors que le code en chargeait deux, construits à l'exécution par un helper, et ce zéro a vidé le comptage des API exposées¹. Sur une application jouet, il a manqué un contrôle d'expéditeur caché derrière un helper. Les comptages simples (fenêtres, contextBridge, gestionnaires IPC) concordaient avec grep. Plus le code passe par des indirections, plus la couverture baisse.

Le code natif ajoute une dépendance. Sans Ghidra, Hopper ou IDA installé, l'appel d'analyse a renvoyé provider_unavailable sur un binaire Rust de 20 Mo, et REA s'en est tenu à l'identification du format. Sur Linux arm64, Javier Cañete Arroyo a dû compiler lui-même le décompilateur natif de Ghidra (gradlew buildNatives) avant que REA ne décompile un binaire C sans symboles et en retrouve les constantes.

Quand REA vaut son coût

Le test de Jacar Systems donne un critère net. Si vous ne faites que décompiler des binaires et que vous utilisez déjà IDA ou Ghidra, un pont vers un seul moteur ajoute moins de surface. REA prend l'avantage quand la question traverse les couches, par exemple pour suivre une fonction depuis le renderer d'une application Electron jusqu'à un add-on natif. Notre comparatif REA, GhidraMCP ou ida-pro-mcp détaille ce choix, et déployer REA en entreprise traite l'épinglage des versions.

Avant tout essai sur un binaire inconnu, rappelez-vous que REA ne confine rien : voir REA n'est pas un sandbox. Et pour relire les résultats sans confondre déduit et prouvé : lire une sortie REA.

Pour l'architecture de l'outil et son installation, voir REA expliqué en trois schémas.

Questions fréquentes

REA est-il lent ?

Non : 52 secondes pour l'analyse statique de 100 Mo dans le test de HackerNoon, 52 secondes pour Slack chez Cyrus. Le volume de sortie pèse davantage que le temps de calcul.

Faut-il un gros modèle ?

Avec le catalogue complet, oui. Le profil compact de la version 6.7.0 divise l'empreinte par plus de quatorze dans le test de Jacar Systems ; testez-le sur votre client MCP avant de conclure.

REA voit-il tout le code ?

Non. Les chemins construits à l'exécution, les helpers et le code chargé depuis un serveur lui échappent souvent. Un zéro dans un comptage se vérifie toujours à la main.

Mesurer avant de généraliser

Dans AI Cyber, nous cadrons chaque essai de rétro-ingénierie par agents avec un budget de tokens, une version épinglée et une liste de constats à vérifier à la main. C'est la condition pour savoir ce que l'outil a couvert et ce qu'il a laissé de côté.

Sources

1. Ishank Choudhary, I Tested REA, GitHub's Viral Reverse Engineering Tool, on a Real Electron App, hackernoon.com, 14 octobre 2026 (tests du 11 octobre, REA 6.4.0).
2. Javier Cañete Arroyo (Jacar Systems), REA: ingeniería inversa con tu agente de código, probada con Ghidra y Electron, jacar.es, 19 octobre 2026 (rea-agents 6.7.0).
3. Connor Turland, What is REA (Reverse Engineer Anything)? I ran it on Slack to find out, atcyrus.com, 20 octobre 2026.
4. npm, paquet rea-agents, historique des versions, npmjs.com, consulté le 20 octobre 2026.