Vague REA : des agents IA qui ouvrent les applications fermées

De 40 étoiles à plus de 57 000 en huit jours : REA, pour Reverse Engineer Anything, donne aux agents IA la capacité d'inspecter des applications sans code source disponible. Le compteur GitHub tournait autour de 40 le 2 octobre et a dépassé 57 000 le matin du 10 octobre, avec près de 20 000 ajoutées sur la seule journée du 9 octobre. Le principe est audacieux et simple : l'agent comprend comment une fonction se comporte, montre la preuve et reconstruit un comportement semblable dans ton projet. En dessous, un canal standard pour outils d'agents plus un utilitaire en ligne de commande, compatible avec Claude Code, Cursor, Gemini CLI et les assistants similaires.

La liste des cibles va bien au-delà d'Electron : programmes natifs pour Mac, Windows et Linux, assemblages .NET, paquets Android, micrologiciels, sites web et même bytecode de contrats intelligents. REA ne rend pas la source d'origine ; noms et commentaires disparaissent dès la compilation. À la place, il livre du pseudocode, des instructions machine, des chaînes de texte et une carte des appels entre fonctions. Chaque découverte apporte son origine, un score de confiance et une marque d'inconnu sur les parties non résolues, pour que l'agent ne présente jamais une lacune comme un fait.

REA n'est pas lui-même un désassembleur ; il repose sur des moteurs que les rétro-ingénieurs utilisent depuis des années. Ghidra, gratuit et né à la NSA, Hopper sur Mac et Linux, et IDA Pro la référence du secteur forment cette couche. Au-dessus de ces outils difficiles, REA ajoute des opérations en langage clair servies via MCP : ouvre ce binaire, trouve les chaînes, suis les appels. La version 5.0.0 a livré 133 outils, et la fiche Devpik situe la mouture récente à 139. L'installation tient en une commande qui montre d'abord un plan, sauvegarde la configuration, enregistre le serveur et apprend à l'agent à enquêter. L'analyse tourne sur la machine locale, même si le fournisseur du modèle de l'agent voit toujours les résultats.

L'essai sur DX-Ball, un jeu Windows de 1996, montre que l'approche est sérieuse. En traçant la répartition gauche-droite du son d'une brique qui se brise, l'agent a repéré dans les instructions machine une entrée que le pseudocode cachait, lu les constantes et réécrit la fonction en C. La réécriture a correspondu sur 3 205 vérifications et a compilé exactement les mêmes 63 octets. Le cas est documenté pas à pas sur la page de démonstration de rea.tools, avec adresses d'appel et lectures mémoire. La leçon : l'agent ne se contente pas de deviner, il produit un travail vérifiable à l'octet.

La fonction copier de l'application de bureau Notion a été suivie depuis la page web jusque dans le processus principal d'Electron. L'agent a découvert que Notion cache un identifiant de copie dans le HTML copié, et restaure les blocs grâce à lui au moment du collage. Le compte rendu admet ouvertement qu'une étape s'est terminée par lecture manuelle, une note honnête qui inspire confiance. Dans un autre essai, un développeur a forcé son propre coffre : parmi plus de 240 fonctions aux noms effacés, celle qui vérifie le code est apparue en quelques appels, un générateur que l'application n'avait jamais eu a été écrit, et le code généré a ouvert le coffre. La même méthode sert la défense : demande ce que font les applications de ta machine et où elles envoient des données.

Pendant des années, le logiciel a profité d'une protection silencieuse, et ce n'était pas le chiffrement mais le coût : inspecter était lent, cher et exigeait des compétences rares, alors presque personne ne s'y risquait. Cet outil efface l'essentiel de ce coût. Quiconque distribue une application de bureau, une extension de navigateur, un jeu, une application mobile ou un gros paquet JavaScript doit partir du principe que la carte des fonctions peut désormais être tracée. Le vrai fossé est ailleurs : dans les données, dans la base d'utilisateurs, dans la vitesse de livraison et dans la logique serveur qu'aucun regard extérieur ne peut inspecter. Déplacer la logique critique du client vers le serveur s'impose comme la réponse la plus solide face à l'inspection assistée par modèles.

Trois avertissements avant d'essayer. D'abord, le droit, et ceci n'est pas un conseil juridique : inspecter pour l'interopérabilité est généralement protégé, mais presque toutes les conditions produit l'interdisent, et contourner le chiffrement ou le DRM relève d'un autre terrain ; tes propres applications, les programmes ouverts et les tests autorisés sont un sol sûr. Ensuite, la sécurité : la page du projet dit que ceci n'est pas un bac à sable ; un programme exécuté pour l'observer tourne avec tes permissions, et un fichier peut cacher un texte conçu pour tromper ton agent, alors garde les demandes d'approbation activées et ouvre l'inconnu dans une machine virtuelle. Enfin, le rythme : la 4.0.0 est sortie le 5 octobre, la 5.0.0 le 7 et la 6.0.0 le 8, alors mets à jour souvent. Bon usage : apprendre comment la synchronisation, le presse-papiers et la recherche se comportent, puis écrire les tiens ; mauvais usage : cloner un concurrent.