REA, l’agent de rétro-ingénierie : ce que cela change pour une DSI

REA, pour « Reverse Engineer Anything », est un projet open source sous licence MIT apparu dans les tendances GitHub début octobre 2026. Il se présente comme un CLI et un serveur MCP qui donnent à un agent de code, Claude Code, Codex, Cursor ou d’autres, des outils pour inspecter un programme dont on n’a pas le code source : binaires natifs, applications JavaScript et Electron, activité d’un navigateur ou d’un processus.

Pour une DSI, la nouveauté n’est pas la rétro-ingénierie, pratiquée depuis longtemps avec des désassembleurs. La nouveauté, c’est qu’un agent conversationnel peut enchaîner ces outils, formuler une hypothèse et la vérifier sans expert à chaque étape. Cela ouvre des usages utiles sur ses propres logiciels, et cela pose trois questions à traiter avant tout déploiement : ce qui part chez le fournisseur du modèle, ce que le droit autorise, et comment prouver qu’une conclusion est juste.

REA est un serveur MCP et un CLI, distribué sur npm sous le nom rea-agents, qui expose à un agent de code des outils d’inspection de programmes sans code source.

Le site rea.tools le résume ainsi : donner à l’agent les outils pour inspecter un programme et expliquer ce qu’il fait. Le README du dépôt GitHub précise trois familles de cibles. Les binaires natifs d’abord : fonctions, chaînes, symboles, références et relations d’appel, avec pseudo-code et assembleur obtenus via Hopper, Ghidra ou IDA, et JEB pour Android. Les applications JavaScript et Electron ensuite : une analyse statique d’un dossier ou d’une archive ASAR extrait modules, imports, routes, canaux IPC et extensions natives, sans moteur d’analyse natif. L’exécution enfin : capture de l’activité d’un navigateur de la famille Chrome ou d’un processus, puis comparaison des résultats entre plusieurs exécutions.

L’installation passe par une commande npx qui enregistre le serveur MCP dans la configuration de l’agent, après approbation d’un plan d’installation, avec sauvegarde de la configuration existante. Node.js 22 ou plus récent est requis. Le principe est celui de tout serveur MCP, décrit dans le protocole qui rend les agents branchables : l’agent voit des outils, les appelle, lit les résultats et décide de la suite.

Les deux démonstrations de rea.tools montrent un agent qui retrouve une règle précise dans un logiciel existant, puis la vérifie contre une source indépendante.

Sur le jeu du dinosaure de Chrome, REA lit le script réellement exécuté par la page et en extrait la règle d’accélération : vitesse de départ 6, incrément de 0,001, plafond à 13. Un agent reconstruit ensuite un mini-jeu à vitesse réglable, présenté comme une réplique pédagogique, et vérifie la règle : vitesse de 10,0 après 4 000 mises à jour, de 13,0 après 10 000.

Sur la calculatrice Windows, version 11.2508.4.0 en x64 analysée avec REA 4.1.0, l’analyse distingue deux comportements du bouton %. Après une addition ou une soustraction, le pourcentage porte sur le premier nombre : 200 + 10 % donne 220. Après une multiplication ou une division, il divise simplement par 100. La branche trouvée est recoupée avec le code source public de Microsoft. C’est ce recoupement qui donne sa valeur à la démonstration : une conclusion d’agent n’est crédible que confrontée à une référence extérieure.

REA aide à comprendre le comportement d’un programme, il ne restitue pas son code source d’origine.

Le README le dit sans détour : l’analyse native renvoie du pseudo-code et de l’assembleur. Ce pseudo-code est une reconstruction produite par le décompilateur, sans les noms de variables, les commentaires ni la structure voulue par les auteurs. L’agent en tire une explication, qui reste une hypothèse tant qu’elle n’a pas été confrontée à une exécution ou à une source indépendante. Pour JavaScript, la situation est plus favorable, puisque le code livré est souvent lisible ou accompagné de source maps, mais il reste minifié et partiel.

REA ne fournit pas non plus les outils qu’il pilote. Le README précise qu’il n’accorde aucune licence, clé ou activation pour Hopper, IDA ou JEB, et qu’il faut avoir obtenu ces outils légalement. Enfin, la capture d’exécution lance ou manipule la cible avec les droits de l’utilisateur : sur un poste de travail ordinaire, ces droits sont larges.

Les usages légitimes portent sur des logiciels que l’entreprise possède ou est autorisée à analyser : comprendre, interopérer, auditer, migrer.

Le premier cas est le plus fréquent : une application interne dont le code source est perdu, le prestataire disparu, la documentation absente. Un agent outillé peut cartographier ses fonctions, ses formats de fichiers et ses appels réseau, ce qui prépare une reprise ou un remplacement. L’article frère sur la modernisation d’un logiciel legacy sans documentation détaille cette démarche, et la reprise d’un système construit par quelqu’un d’autre en donne les réflexes d’inventaire.

Le deuxième cas est l’interopérabilité : comprendre le format d’échange ou le protocole d’un progiciel pour y raccorder un outil créé indépendamment, situation proche de celle traitée dans brancher un modèle sur un progiciel sans API. Le troisième est l’audit de sécurité de ses propres binaires, ou de ceux livrés par un fournisseur quand le contrat le permet. Le quatrième est la migration : comparer le comportement d’une ancienne et d’une nouvelle version sur les mêmes scénarios, ce que la comparaison entre exécutions rend plus systématique.

Les trois risques principaux sont la confidentialité de ce qui part vers le modèle, la propriété intellectuelle de l’éditeur et le respect des licences et conditions d’utilisation.

Le README écrit que REA analyse les cibles en local, mais que l’agent reçoit les résultats des outils et que son fournisseur de modèle applique sa propre politique de données. Autrement dit, des chaînes extraites d’un binaire, des URL internes, des identifiants embarqués ou des extraits de pseudo-code partent dans le contexte du modèle. Les règles exposées dans ce qu’on a le droit de mettre dans un prompt s’appliquent intégralement, et un modèle exécuté en local, comme décrit dans les petits modèles sur poste, devient une option sérieuse pour les cibles sensibles.

Le site rea.tools cite parmi les usages la reconstruction de jeux et le clonage de sites, et le README ouvre sur une question : vous voyez une fonctionnalité dans une application et la voulez dans votre produit ? C’est précisément la zone où le droit d’auteur et les CGU deviennent déterminants. S’ajoute un risque propre aux agents : le contenu analysé peut contenir du texte qui oriente le modèle, comme le décrit l’injection de prompt indirecte.

Le droit européen autorise l’utilisateur légitime à observer et tester un logiciel, et à le décompiler pour la seule interopérabilité, sous conditions strictes.

La directive 2009/24/CE, transposée en France à l’article L122-6-1 du Code de la propriété intellectuelle, prévoit à son article 5 que la personne autorisée à utiliser un programme peut en observer, étudier ou tester le fonctionnement pour dégager les idées et principes qui le sous-tendent, à l’occasion des opérations qu’elle est en droit d’effectuer. Son article 6 autorise la décompilation lorsqu’elle est indispensable à l’interopérabilité d’un programme créé indépendamment, si l’information n’est pas déjà facilement accessible et si l’on se limite aux parties nécessaires.

Les informations obtenues ne peuvent servir à d’autres fins, ni être communiquées à des tiers hors nécessité d’interopérabilité, ni servir à développer un programme substantiellement similaire. Le texte français déclare nulle toute clause contraire aux paragraphes II, III et IV de l’article L122-6-1. L’analyse détaillée figure dans l’article frère ce que le droit autorise en rétro-ingénierie logicielle, et la méthode dite de salle blanche, qui sépare l’analyse de la réécriture, est illustrée dans Photocraft, un Photoshop open source en salle blanche.

Je recommande une recette en quatre étapes : périmètre autorisé, environnement isolé, preuve reproductible, revue humaine.

1. Périmètre autorisé. Écrire la liste des logiciels analysables, le fondement de chaque analyse (propriété, contrat, interopérabilité) et ce qui est exclu. Une ligne par cible, validée par le juridique pour les logiciels tiers. C’est l’application directe du principe décrit dans le périmètre avant l’autonomie.
2. Environnement isolé. Machine virtuelle dédiée, compte sans privilège, pas d’accès aux secrets de production, réseau filtré. Les outils commerciaux pilotés sont sous licence. Le choix du modèle, hébergé ou local, découle de la classification des cibles.
3. Preuve reproductible. Toute conclusion de l’agent s’accompagne de ce qui permet de la rejouer : version exacte de la cible, version de REA, commande, trace capturée, test qui confirme le comportement. C’est ce que font les démonstrations officielles, et c’est le standard à exiger.
4. Revue humaine. Un ingénieur relit la conclusion et la preuve avant tout usage, et une revue juridique intervient dès qu’une information doit sortir de l’équipe ou nourrir un développement.

Ce cadre se teste d’abord sur un cas réel et borné, par exemple un outil interne sans documentation. Pour un diagnostic de vos usages d’agents et de leurs points de contrôle, voir l’audit IA.

Analyse et méthode proposées par Anand Candassamy au 13 octobre 2026.