Déployer REA en entreprise : versions, profils, conteneurs

Entre le 5 et le 18 octobre 2026, le paquet npm rea-agents est passé de la version 4.0.0 à la version 6.7.0, avec 6.1.0, 6.2.0 et 6.3.0 publiées en moins de 24 heures entre le 9 et le 10 octobre¹. REA est né comme un outil individuel et s'est répandu sur les postes de développeurs avant toute décision d'architecture. Une DSI qui veut l'autoriser doit d'abord le gouverner.

Épingler la version

Le rythme de publication est la première contrainte opérationnelle. Le 11 octobre, Ishank Choudhary comptait 31 versions publiées sur npm depuis juillet². Le registre en compte 33 au 23 octobre, la dernière, 6.7.0, datée du 18 octobre¹. Chaque version peut changer le catalogue d'outils, les contrats de sortie ou les prérequis, et, selon la politique de sécurité du projet, les correctifs ne visent que la dernière version publiée³.

Bannissez @latest en production. La documentation de REA indique que la commande de configuration épingle déjà la version exacte installée dans l'enregistrement MCP du client⁴ : faites de cette version une décision tracée, revue à chaque montée, plutôt qu'un effet de bord du jour d'installation. Vérifiez aussi la provenance. Le 13 octobre, un faux dépôt a distribué un exécutable Windows détecté comme trojan ; le README officiel rappelle depuis que REA s'obtient uniquement par morluto/rea, rea.tools ou le paquet npm rea-agents (voir faux dépôts REA et trojan).

Isoler le profil d'agent

Par défaut, REA s'enregistre pour tout le client d'agent. Pour Claude Code, il écrit dans ~/.claude.json et installe sa skill sous ~/.claude/skills, si bien que chaque projet ouvert peut l'appeler⁴. La documentation décrit deux façons de le limiter, dont un profil séparé via la variable CLAUDE_CONFIG_DIR. Gardez vos projets de travail sans REA et réservez-le à un profil dédié aux analyses.

Exigez le mode --dry-run avant toute écriture : il « returns a read-only plan with status planned », et la configuration réelle sauvegarde les fichiers qu'elle modifie⁴. Le plan se relit comme une modification d'infrastructure.

Le profil séparé ne constitue pas une frontière de sécurité. La même documentation précise que ces réglages contrôlent quelles sessions découvrent REA, mais laissent le shell, les fichiers et le réseau accessibles : un agent sous le même compte système peut lancer REA par npx et lire les sorties d'analyse. Pour une séparation stricte, par exemple une réécriture en clean-room, il faut un compte ou un conteneur distinct⁴.

Conteneuriser les analyses sensibles

REA n'isole pas ce qu'il analyse : « This is not a sandbox », écrit sa politique de sécurité³. Toute cible inconnue ou hostile s'analyse dans un conteneur ou une machine virtuelle jetable. Le 18 octobre, un projet communautaire non officiel a publié une image Docker qui illustre la posture : système de fichiers en lecture seule, toutes les capacités Linux retirées, réseau coupé dans l'exemple d'analyse, endpoint MCP protégé par un jeton⁵. Construisez votre propre image sur ces principes plutôt que de dépendre d'un dépôt de quelques jours. Le détail est dans REA n'est pas un sandbox.

Gouverner les outils et le modèle

Le catalogue d'outils pèse sur le contexte de l'agent. En 6.4.0, Ishank Choudhary mesurait 170 outils et une liste de 1 954 704 octets, dont le profil compact ne retirait qu'environ 9 %². En 6.7.0, Javier Cañete compte 207 outils et une liste de 3 158 352 octets, que le profil compact ramène à 219 211 octets, moins de 7 % de sa taille, pour une installation de 222 Mo et 158 dépendances⁶. Mesurez ces valeurs sur la version que vous épinglez ; le détail des coûts est dans les limites réelles de REA.

Choisissez le modèle selon la cible. REA analyse localement, mais les résultats d'outils partent vers le fournisseur du modèle, sous sa propre politique de données⁷. Pour un binaire sensible, un modèle exécuté chez vous évite cette sortie. Écrivez la politique d'usage : qui utilise REA, sur quelles cibles, avec quel modèle, avec quelle approbation des outils. Rappelez que les moteurs commerciaux (IDA Pro, Hopper, JEB) relèvent de leur propre licence, REA n'en fournissant aucune⁷, et que le cadre juridique de l'analyse se valide avant l'usage, voir clean-room ou reverse engineering. Pour choisir entre REA et un pont mono-moteur, voir REA, GhidraMCP ou ida-pro-mcp.

Mise à jour du 23 octobre 2026 : la dernière version publiée sur npm reste 6.7.0 ; le dépôt compte 369 860 étoiles selon l'API GitHub⁸.

Questions fréquentes

Faut-il utiliser @latest ?

Non. Épinglez une version précise, vérifiez qu'elle vient du paquet officiel rea-agents et planifiez les montées comme toute dépendance.

Où installer REA ?

Dans un profil d'agent dédié aux analyses, et dans un compte ou un conteneur séparé dès que la cible est inconnue ou que la séparation entre analyse et réécriture compte.

Faut-il conteneuriser ?

Pour toute cible inconnue, sensible ou hostile, oui : REA laisse les moteurs d'analyse travailler avec vos droits d'utilisateur.

Quel modèle utiliser ?

Celui que votre politique de données autorise pour la cible. Les résultats d'outils partent chez le fournisseur du modèle ; un modèle local les garde chez vous.

Encadrer l'usage d'outils agentiques de rétro-ingénierie fait partie de l'offre AI Cyber de SFEIR : politique d'usage, environnement d'analyse confiné, choix des modèles.

Sources

1. npm, paquet rea-agents, historique des versions, npmjs.com, consulté le 23 octobre 2026.
2. Ishank Choudhary, I Tested REA, GitHub's Viral Reverse Engineering Tool, on a Real Electron App, hackernoon.com, 14 octobre 2026.
3. morluto/rea, SECURITY.md, github.com, consulté le 20 octobre 2026.
4. morluto/rea, docs/installation.md (dry-run, sauvegardes, épinglage, « Limit REA to one project or agent profile »), github.com, consulté le 20 octobre 2026.
5. psyb0t, docker-reverse-engineer-anything, release v0.1.1, github.com, 18 octobre 2026.
6. Javier Cañete Arroyo, REA: ingeniería inversa con tu agente de código, probada con Ghidra y Electron, jacar.es, 19 octobre 2026.
7. morluto/rea, README (FAQ « Does REA upload my app? ») et DISCLAIMER.md (« Third-party tools and licenses »), github.com/morluto/rea, consulté le 20 octobre 2026.
8. GitHub, API du dépôt morluto/rea, github.com/morluto/rea, consulté le 23 octobre 2026.