Votre logiciel est lisible par n'importe quel agent : guide pour éditeurs

Le 20 octobre 2026, Connor Turland a cartographié le client de bureau de Slack avec REA en 52 secondes : 529 fichiers JavaScript, 1 904 modules, 45 canaux IPC, 8 add-ons natifs. Si vous éditez un logiciel, partez de ce chiffre : tout ce que vous installez sur le poste de vos clients se lit désormais en une minute, par n'importe qui disposant d'un agent de code.

Ce qu'un agent voit de votre application

Le README de REA décrit ce que l'outil renvoie par type de cible¹. Pour une application Electron : modules, imports, source maps, routes, canaux IPC et add-ons natifs, sans lancer l'application. Pour une assembly .NET : métadonnées, instructions CIL et dépendances natives. Pour une APK : manifeste, classes, méthodes décompilées. Pour un binaire natif, avec Ghidra, Hopper ou IDA : pseudocode, assembleur, chaînes, symboles, appels.

Le niveau de détail dépasse la cartographie. Turland dit avoir compris la logique d'un contrôle de notifications de Slack en une dizaine de minutes². Le README de REA assume l'usage : voir une fonctionnalité dans une application, demander à l'agent comment elle marche, puis en construire une version pour son propre projet¹. Le détail des tests figure dans ce que REA révèle d'une application Electron.

Ce que vous ne pouvez plus cacher

Trois catégories passent du « difficile à trouver » au « lisible en une session ». Les secrets embarqués : clés d'API, jetons, identifiants de services tiers placés dans le binaire ou l'archive (voir secrets et logique métier dans l'ASAR). La logique métier exécutée côté client : règles de calcul, contrôles de droits, activation de fonctionnalités. La carte de vos appels réseau : points de terminaison, formats, en-têtes.

Minification, empaquetage et compilation native ralentissent un humain. Ils gênent peu les outils d'un agent : dans le test d'Ishank Choudhary sur une application JavaScript minifiée, l'analyseur statique de REA a gardé l'expression réelle d'un libellé de canal plutôt qu'une chaîne inventée⁵. Notre article sur l'obfuscation face aux agents détaille ce qu'elle protège encore.

Où déplacer la valeur

Traitez le client comme public. Aucun secret durable dans le binaire livré : les clés restent sur vos serveurs, et le client reçoit des jetons courts, émis à l'exécution et révocables. La validation qui compte (droits, quotas, licences, calculs tarifés) se refait côté serveur, même si le client la fait aussi pour l'ergonomie. La logique qui fait votre différence vit derrière une API que vous contrôlez.

Le reste de vos actifs se copie mal : vos données, vos utilisateurs, votre infrastructure, votre distribution, la qualité de votre support et le rythme de vos livraisons. Un concurrent qui copie une fonctionnalité vue dans votre client repart sans votre historique d'incidents, ni les réglages que ces incidents vous ont appris.

Testez vous-même ce qu'un agent voit de votre produit, sur votre propre build, avant vos concurrents. Sur votre propre code, la question d'autorisation se limite aux composants tiers : votre build embarque souvent des dépendances et des SDK sous leur propre licence.

Ce que la licence et le droit protègent encore

Une licence peut restreindre la rétro-ingénierie, mais en France une partie de ces clauses est nulle. L'article L122-6-1 du Code de la propriété intellectuelle déclare nulle et non avenue toute stipulation contraire à la copie de sauvegarde, à l'observation et à l'étude du fonctionnement lors d'une utilisation autorisée, et à la décompilation nécessaire à l'interopérabilité³. Le détail est dans clauses de licence et rétro-ingénierie.

Le code lui-même et vos assets restent protégés. La Cour de justice de l'Union européenne a jugé en 2012 que la fonctionnalité d'un programme, son langage et le format de ses fichiers de données ne sont pas protégés par le droit d'auteur⁴. Un concurrent qui réimplémente un comportement est sur un terrain différent de celui qui recopie votre code. Le hub clean-room ou reverse engineering pose les distinctions, et décompiler pour interopérer détaille l'exception d'interopérabilité.

Questions fréquentes

Faut-il arrêter d'obfusquer ?

Non. Gardez l'obfuscation comme ralentisseur, sans en faire votre défense principale.

Un secret présent dans mon application est-il exposé ?

Considérez que oui. Révoquez-le, déplacez-le côté serveur et remplacez-le par un jeton court.

Une clause anti-rétro-ingénierie me protège-t-elle ?

Partiellement. En France, elle ne peut pas interdire l'observation du fonctionnement ni la décompilation pour l'interopérabilité dans les conditions de la loi. Faites relire vos licences par votre juriste.

Faire l'audit avant les autres

L'offre AI Cyber passe votre propre code et vos builds aux mêmes outils qu'un agent extérieur, puis livre la liste de ce qu'il faut retirer du client, avec les correctifs. Le hub rétro-ingénierie par agents et sécurité donne la vue d'ensemble.

Sources

1. morluto/rea, README, github.com/morluto/rea, consulté le 21 octobre 2026.
2. Connor Turland, What is REA (Reverse Engineer Anything)? I ran it on Slack to find out, atcyrus.com, 20 octobre 2026.
3. Code de la propriété intellectuelle, article L122-6-1, legifrance.gouv.fr.
4. CJUE, 2 mai 2012, SAS Institute Inc. c. World Programming Ltd, C-406/10, curia.europa.eu.
5. Ishank Choudhary, I Tested REA, GitHub's Viral Reverse Engineering Tool, on a Real Electron App, hackernoon.com, 14 octobre 2026.