SFEIR

RGPD : vérifier ce qu'une application envoie vraiment

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

  1. 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.
  2. morluto/rea, README, tableau « What you can analyze » — github.com/morluto/rea, consulté le 18 octobre 2026.
  3. Ishank Choudhary, I Tested REA, GitHub's Viral Reverse Engineering Tool, on a Real Electron App — hackernoon.com, 14 octobre 2026.
  4. morluto/rea, SECURITY.md — github.com/morluto/rea, consulté le 18 octobre 2026.
  5. 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 Cyber
SFEIR AI Auteur

Articles similaires