RGPD : vérifier ce qu'une application envoie vraiment
Le règlement (UE) 2016/679 demande à chaque responsable de traitement de tenir un registre de ses traitements et d'encadrer tout transfert de données personnelles hors de l'Union1. Pour une application tierce installée sur les postes ou les téléphones de l'entreprise, ce registre repose souvent sur la seule déclaration de l'éditeur. Les outils de rétro-ingénierie par agents, comme REA, rendent abordable la vérification du comportement réel. Pour un DPO, l'écart entre les deux est le sujet.
Le besoin
Le RGPD impose de savoir quelles données personnelles sont traitées, par qui, et vers où elles partent. Un éditeur qui embarque un SDK d'analytics, un outil de suivi des plantages ou un service de publicité fait sortir des données que sa politique de confidentialité décrit plus ou moins fidèlement. Vérifier le comportement d'un logiciel avant de le déployer, ou en cours de contrat, fait partie de la diligence attendue d'un responsable de traitement. Selon les cas, l'éditeur est son sous-traitant, un responsable de traitement distinct ou un responsable conjoint : la qualification se tranche avec le DPO.
Ce que l'analyse statique révèle
L'analyse statique lit le logiciel sans l'exécuter. Selon le README de REA, l'outil renvoie pour une application JavaScript ou Electron ses modules, imports, routes et canaux IPC ; pour une assembly .NET, ses métadonnées et ses dépendances ; pour une APK Android, les déclarations du manifeste, les classes et les méthodes décompilées via JADX ; pour un binaire natif piloté dans Ghidra, Hopper ou IDA, les chaînes, symboles et références2. Sur votre propre code, cette lecture ne pose pas de question ; sur un logiciel tiers, la décompilation en pose une, traitée plus bas.
Pour un audit de confidentialité, on cherche dans ce matériau les URL et noms de domaine en dur, les bibliothèques de télémétrie connues, les permissions demandées par l'application mobile, et les endroits du code où une donnée personnelle (identifiant, adresse électronique, localisation) part vers un appel réseau. Chaque trouvaille arrive avec sa localisation dans le fichier, ce qui la rend vérifiable ; notre page sur la lecture d'une sortie REA explique comment séparer ce qui est prouvé de ce qui est déduit.
Sur une application Electron, le test public d'Ishank Choudhary donne l'ordre de grandeur : 52 secondes pour analyser une archive de 100 Mo, avec des comptages de fenêtres et de canaux IPC conformes à une recherche manuelle, mais deux scripts de préchargement manqués3. Notre synthèse sur ce que REA révèle d'une application Electron détaille ces résultats.
Le statique montre le possible, la capture montre le réel
Un domaine présent dans le code peut ne jamais être appelé, et une URL peut être construite à l'exécution ou téléchargée depuis le serveur de l'éditeur. Pour voir ce que l'application envoie vraiment, il faut observer son trafic, donc l'exécuter. REA sait relire des captures réseau enregistrées au format HAR ou SAZ et en extraire requêtes, réponses et charges exposées2.
Exécuter un logiciel tiers impose le confinement. La politique de sécurité de REA le dit : l'outil n'est pas un bac à sable, et une capture à l'exécution tourne avec les permissions de l'utilisateur4. Faites-le dans une machine virtuelle dédiée, avec un compte de test sans données réelles et le trafic routé vers un proxy d'inspection. Notre page sur le confinement de l'analyse donne la marche à suivre.
Deux autres précautions viennent de la clause de non-responsabilité de REA. Être autorisé à inspecter un fichier « does not necessarily authorize execution, interception, device changes, or interaction with another party's system ». Et l'utilisateur reste responsable de la protection des données personnelles et du trafic capturé5. Une capture réseau contient elle-même des données personnelles : elle se traite comme telle.
Du constat à la conformité
Un écart entre la déclaration de l'éditeur et le comportement observé se trace : quelle donnée, vers quel domaine, dans quelle version du logiciel, avec quelle preuve. Il appelle ensuite une décision du responsable de traitement : demande d'explication au fournisseur, désactivation de la fonction, blocage réseau, mise à jour du registre ou retrait du logiciel. La même logique, appliquée à un composant dont on ignore le contenu, mène à la nomenclature logicielle exigée par le Cyber Resilience Act, et à l'audit d'un binaire fournisseur.
Côté droit, le III de l'article L122-6-1 du Code de la propriété intellectuelle permet à l'utilisateur légitime d'observer, d'étudier et de tester le fonctionnement d'un logiciel afin de déterminer les idées et principes qui en sont à la base, lors des opérations de chargement, d'affichage, d'exécution, de transmission ou de stockage qu'il est en droit d'effectuer. La décompilation, elle, n'est prévue que pour l'interopérabilité (IV) ou, selon l'arrêt Top System, pour la correction d'erreurs. Un audit de confidentialité s'appuie donc d'abord sur l'observation, comme la capture réseau d'une exécution autorisée ; décompiler une application tierce pour l'auditer demande en principe l'accord de l'éditeur. C'est un point d'attention à faire valider par votre juriste. Notre hub juridique et la page sur les clauses de licence détaillent les limites. Pour les assistants et agents déployés sur les postes de travail, voir aussi la conformité RGPD du digital workplace.
Questions fréquentes
L'analyse statique suffit-elle pour le RGPD ?
Elle montre ce que l'application peut envoyer. Pour établir ce qu'elle envoie, il faut une capture réseau, réalisée dans un environnement isolé.
Puis-je vérifier une application tierce ?
Celle que vous utilisez légalement ou êtes autorisé à examiner. L'observation de son fonctionnement est la voie la plus sûre ; la décompilation demande en principe l'accord de l'éditeur. Faites valider le périmètre par votre juriste, surtout si l'analyse implique une interception de trafic.
Que faire d'un écart constaté ?
Le documenter avec ses preuves, le soumettre au fournisseur, puis décider : correction, désactivation, blocage ou retrait, et mise à jour du registre des traitements.
La capture réseau contient-elle des données personnelles ?
Souvent. Utilisez des comptes de test et traitez la capture comme un fichier sensible.
L'offre AI Cyber analyse en boîte blanche le code source dont vous disposez et, pour les applications tierces de votre parc, leur comportement observable ; chaque écart est documenté avec sa preuve, pour que votre DPO décide sur des faits.
Sources
- Règlement (UE) 2016/679 du 27 avril 2016 relatif à la protection des personnes physiques à l'égard du traitement des données à caractère personnel (RGPD), article 30 et chapitre V — eur-lex.europa.eu.
- morluto/rea, README, tableau « What you can analyze » — github.com/morluto/rea, consulté le 18 octobre 2026.
- Ishank Choudhary, I Tested REA, GitHub's Viral Reverse Engineering Tool, on a Real Electron App — hackernoon.com, 14 octobre 2026.
- morluto/rea, SECURITY.md — github.com/morluto/rea, consulté le 18 octobre 2026.
- morluto/rea, DISCLAIMER.md — github.com/morluto/rea, consulté le 18 octobre 2026.
Mesurer l'écart entre la déclaration d'un éditeur et le comportement de son logiciel
Découvrir l'offre AI CyberArticles similaires
Cyber Resilience Act et SBOM : inventorier un binaire livré sans inventaire
Depuis le 11 septembre 2026, les fabricants doivent signaler à l'ENISA les vulnérabilités activement exploitées de leurs produits. Quand un composant arrive en binaire sans inventaire, l'analyse par agent aide à reconstruire une base de travail. Calendrier et méthode.
Auditer un binaire fournisseur sans son code source
Un composant livré en binaire, sans code source ni inventaire, entre en production chez vous. Ce qu'un agent de rétro-ingénierie comme REA révèle de son contenu, comment en tirer un embryon de SBOM utile au Cyber Resilience Act, et ce que le contrat doit prévoir.
REA n'est pas un sandbox : confiner l'analyse d'un binaire inconnu
La politique de sécurité de REA le dit en toutes lettres : l'outil n'est pas un bac à sable. Ouvrir un binaire inconnu le fait analyser par Ghidra ou Hopper avec vos droits. Ce que protège le pont authentifié, ce qu'il ne protège pas, et comment confiner l'analyse.
Clean-room ou reverse engineering : méthode et risque juridique à l'ère des agents
Rétro-ingénierie et clean-room ne se confondent pas en droit. Ce que la directive 2009/24/CE, le Code de la propriété intellectuelle et la CJUE autorisent, et pourquoi un agent qui lit le décompilé puis réécrit fragilise la défense.