Édition Markdown

AI-translated from English; not yet reviewed by a fluent editor.

# Inspecter le comportement d’une application Electron avec REA

> REA cartographie les modules et les frontières Electron d’une application locale. Ce guide montre comment suivre une fonctionnalité à partir de ses preuves et vérifier son comportement séparément.

By BIG CHANGE Editorial

Published: 2026-10-14T04:55:21.558Z
Updated: 2026-10-14T04:55:21.558Z
Canonical: https://bigchange.ai/blog/rea-static-electron-app-inspection-guide

![Conceptual charcoal illustration of an external storage drive beside a desktop monitor showing unlabeled file-tree and code-like lines.](https://bigchange.ai/api/media/file/rea-local-artifact-inspection-hero-v1.png)
AI-generated conceptual illustration by BIG CHANGE; no actual REA interface, application finding or runtime result is depicted.

REA peut cartographier une application JavaScript ou Electron locale à partir des fichiers que vous êtes autorisé à examiner, même sans disposer de son arborescence de code source. Le résultat utile est une piste de preuves pour un comportement : quel module l’expose, où un appel franchit une frontière de processus et quels éléments doivent encore être vérifiés séparément. Ce guide s’appuie sur la [documentation actuelle du projet REA](https://github.com/morluto/rea/blob/main/README.md), vérifiée le 14 octobre 2026. BIG CHANGE n’a pas exécuté REA sur une application.

## Le grand changement

- **Ce qui a changé :** REA fournit à un agent de programmation une carte structurée des modules, imports, source maps, routes et échanges IPC d’Electron à partir d’un dossier d’application ou d’un ASAR fourni. Chaque constat peut renvoyer aux fichiers qui l’ont produit.
- **Pourquoi c’est important :** Un développeur qui enquête sur une fonctionnalité peut suivre une API nommée ou un canal IPC dans l’application empaquetée avant de décider quoi inspecter manuellement. La question devient plus précise et les preuves plus faciles à vérifier.
- **Ce qu’il faut surveiller :** Les chemins statiques sont des possibilités, pas la preuve que l’application les emprunte pendant son utilisation. Une affirmation sur un comportement précis nécessite toujours une observation indépendante ou un test sur une cible autorisée.

## Avant de commencer

Ce parcours s’adresse à un développeur qui possède une application JavaScript ou Electron locale, ou qui est autorisé à l’inspecter. Il faut le dossier d’application extrait ou son fichier `app.asar` , ainsi qu’un chemin absolu vers celui-ci. Le [manifeste du paquet](https://github.com/morluto/rea/blob/main/package.json) indique `rea-agents` version **6.4.0** et exige Node.js 22.19 ou plus récent dans la branche 22.x, 24.11 ou plus récent dans la branche 24.x, ou 26 et ultérieur. npm est également nécessaire. Sous Linux, l’analyse statique JavaScript/Electron de REA exige un programme compatible avec procps `ps` sur REA `PATH` pour vérifier la propriété des processus, comme l’explique son [guide d’installation](https://github.com/morluto/rea/blob/main/docs/installation.md#linux-owned-process-prerequisite). Ce sont des exigences pour l’hôte REA, distinctes de celles de l’application cible.

Le flux statique JavaScript ne nécessite ni Hopper, Ghidra, IDA, navigateur ni processus Electron en cours d’exécution. Ces outils relèvent d’autres flux REA. Vérifiez vos droits d’inspection et conservez une copie des fichiers d’origine afin de savoir précisément quel artefact a produit chaque résultat. Utilisez le [`morluto/rea` dépôt officiel](https://github.com/morluto/rea) ou le paquet npm qui y est lié ; un dépôt au nom similaire ne prouve pas sa provenance.

## 1. Configurer REA ou utiliser la CLI ponctuelle

Pour un agent de programmation connecté, la [commande de configuration documentée](https://github.com/morluto/rea/blob/main/README.md#quick-start) est :

```sh
npx rea-agents setup
```

Examinez les changements proposés à la configuration de l’agent, approuvez ceux que vous souhaitez, puis redémarrez-le. Pour une inspection depuis le terminal, la commande documentée ci-dessous appelle le paquet pour cette exécution. `@latest` sélectionne la version disponible au moment de l’exécution ; consignez la version résolue avec vos preuves, car le détail des sorties peut évoluer. La version 6.4.0 ci-dessus est celle du manifeste consulté lors de la vérification de cet article, le 14 octobre.

## 2. Analyser les fichiers fournis

Remplacez le chemin d’exemple par le chemin absolu du dossier de l’application autorisée ou de son ASAR :

```sh
npx -y rea-agents@latest analyze-javascript-application /absolute/path/to/app --json > app-evidence.json
```

Le [guide de la CLI](https://github.com/morluto/rea/blob/main/docs/cli.md) avertit que les éléments de preuve complets peuvent être très volumineux. Enregistrez-les dans un fichier, puis consultez un résumé ou la vue d’un module choisi. Évitez de coller tout le résultat dans un prompt. Si la commande échoue, conservez l’erreur et le chemin cible pour le diagnostic ; un code de sortie nul peut tout de même s’accompagner d’une couverture partielle, d’avertissements ou de constats non résolus. Sous Windows, le README montre un chemin tel que `"D:/apps/example"`.

La [référence sur la reconstruction d’artefacts](https://github.com/morluto/rea/blob/main/docs/javascript-artifact-reconstruction.md) indique que cette opération lit les fichiers sélectionnés comme des données sans exécuter l’application. Elle inventorie les chemins et empreintes des artefacts, analyse le JavaScript et TypeScript disponibles et signale les points d’entrée possibles, imports, source maps, routes, points de terminaison réseau, liens entre preload et renderer d’Electron, `contextBridge` API, appels et gestionnaires IPC, ainsi que les demandes de modules natifs. Le résultat attendu est un enregistrement Evidence comprenant un graphe, un résumé Electron statique, la couverture et les limites. Une `.node` est une relation à examiner, pas le décodage de ce module natif.

## 3. Suivre une fonctionnalité précise

Choisissez une fonctionnalité dont vous pouvez retrouver le nom, par exemple une action de menu ou une méthode d’API exposée. Notez son nom visible par l’utilisateur et recherchez dans le résultat REA le module correspondant, le canal IPC littéral ou la route. Suivez dans l’ordre les emplacements signalés : appel depuis le renderer ou la page, pont preload, transmission IPC, gestionnaire correspondant du processus principal, puis opération de fichier ou de service qu’il appelle. L’[exemple CSV d’Electron](https://rea.tools/guides/javascript/) de REA illustre ce schéma avec `notes.exportCsv()` , le canal `notes:export` et un rédacteur du processus principal. Ces noms appartiennent à l’application d’exemple ; la vôtre en aura d’autres.

Pour chaque lien, consignez l’empreinte de l’artefact, le chemin du fichier, l’emplacement et ce que le code montre réellement. Distinguez un canal littéral associé à un gestionnaire d’un canal calculé ou d’une association ambiguë. Consultez les champs de couverture et de limites avant de conclure à l’absence d’un module ou d’un gestionnaire. REA précise qu’un fichier mal formé ou indisponible, des octets compagnons d’ASAR manquants, des expressions non résolues ou une analyse bornée peuvent laisser des relations inconnues. Une source map peut révéler les noms du code d’origine, mais l’outil ne promet pas de retrouver l’arborescence source initiale.

## 4. Vérifier le comportement de façon indépendante

Formulez une affirmation réfutable à partir de la piste statique, par exemple : « cette action appelle ce canal et le gestionnaire écrit ce type de fichier ». Utilisez ensuite un environnement de test approuvé pour effectuer uniquement cette action et observer directement le résultat : fichier créé, état modifié ou trace recueillie avec vos propres autorisations. Consignez la version de l’application, l’empreinte de l’artefact, les étapes du test et le résultat observé. Si vous n’êtes pas autorisé à exécuter l’application, limitez l’affirmation au chemin de code statique. L’exemple de REA indique explicitement que le chemin déduit peut être vérifié par capture à l’exécution ; le graphe statique seul ne montre pas quelle branche a été exécutée.

La vérification est réussie lorsqu’un autre développeur peut retrouver les mêmes emplacements source, voir les limites de l’association statique et répéter votre contrôle ciblé. Une commande d’analyse réussie ne vérifie pas à elle seule le comportement à l’exécution et n’établit pas une réimplémentation fidèle de l’application.

## Si le résultat est incomplet

Vérifiez d’abord que le chemin pointe vers un dossier extrait complet ou un ASAR et que les éventuels `.asar.unpacked` fichiers compagnons nécessaires sont présents. Examinez la couverture et les diagnostics de REA ; une source manquante ou en échec est inconnue, et non un constat négatif. Pour une grande application, la [référence](https://github.com/morluto/rea/blob/main/docs/javascript-artifact-reconstruction.md) documente les sélections `--source-path` exactes, mais les fichiers non sélectionnés restent hors du périmètre d’analyse. Si une correspondance IPC littérale est ambiguë ou si le canal est calculé, examinez les fichiers cités et resserrez la question. Conservez l’ambiguïté dans les notes finales si elle subsiste.

Le code de REA est sous licence MIT, mais le logiciel cible et tout moteur d’analyse externe conservent leurs propres licences et conditions. L’analyse statique traite les fichiers cibles localement. Si vous transmettez les constats de REA à un agent de programmation, le fournisseur du modèle applique sa propre politique de données ; évitez d’envoyer des secrets ou des résultats propriétaires avant autorisation de votre organisation. Vérifiez les conditions et les coûts de l’agent et de tout moteur facultatif. La procédure et la version du paquet ont été vérifiées le **14 octobre 2026** et reposent sur la documentation.

## Sources

- [README de REA](https://github.com/morluto/rea/blob/main/README.md) — Identité officielle, configuration, commande d’analyse JS, sortie, exigences Node et Linux pour ps, traitement local et limites de confidentialité.
- [Manifeste du paquet REA](https://github.com/morluto/rea/blob/main/package.json) — rea-agents 6.4.0 et plage de versions Node requises.
- [Guide d’analyse JavaScript et Electron](https://rea.tools/guides/javascript/) — Exemple détaillé pour suivre le renderer, preload et IPC jusqu’à un gestionnaire du processus principal ; les exemples datent de REA 4.1.0.
- [Reconstruction d’artefacts JavaScript](https://github.com/morluto/rea/blob/main/docs/javascript-artifact-reconstruction.md) — Périmètre statique, sélection des sources, intégrité, couverture et sémantique des chemins non résolus.
- [CLI et Evidence](https://github.com/morluto/rea/blob/main/docs/cli.md) — Commande CLI, volume important des sorties Evidence et limites des codes de sortie.
- [Guide d’installation de REA](https://github.com/morluto/rea/blob/main/docs/installation.md) — La dépendance Linux à ps compatible procps s’applique explicitement à l’analyse statique JavaScript/Electron et le guide propose des conseils de récupération.