Terminal mobile suspecté de compromission : le dataset des indicateurs observables

La question posée à une équipe d'intelligence économique n'est presque jamais formulée correctement. Un dirigeant, un négociateur ou un responsable de dossier sensible demande si son téléphone est surveillé. La réponse honnête consiste à reformuler la demande : personne ne certifie l'innocuité d'un terminal mobile, on constate ou non la présence d'indicateurs observables. Ce déplacement de vocabulaire n'est pas une précaution rhétorique, il conditionne le protocole retenu, le coût de l'examen et la valeur juridique de ce qui sera produit. Ce dataset recense les familles d'indicateurs qu'un dispositif de vérification atteint réellement, ce que chacune démontre, et à quel prix elle se collecte.

Nous avons construit ce recensement à partir des procédures publiques de vérification de terminaux mobiles, des documentations d'outils libres et des comptes rendus techniques publiés par des laboratoires de sécurité entre 2021 et le début de l'année 2026. Nous n'avons pas cherché à mesurer une prévalence de la compromission, chiffre que personne ne détient sur un parc réel. Nous avons cherché à décrire l'espace des observables : ce qu'un examen produit comme matière, indépendamment de son résultat. Le dataset compte six familles, chacune décrite par la nature de la trace, son niveau de preuve et son coût de collecte.

Périmètre du dataset, définitions retenues et construction de l'échantillon

Nous appelons indicateur observable toute trace qu'un examinateur relève sans coopération du logiciel suspecté : elle existe dans le système, dans le réseau ou dans une sauvegarde, et sa lecture ne dépend pas du bon vouloir du programme qui l'aurait produite. Cette définition exclut délibérément les symptômes rapportés par l'utilisateur, échauffement de l'appareil, autonomie dégradée, comportements erratiques de l'écran. Ces symptômes existent et ils motivent la plupart des demandes d'examen, mais ils ne constituent pas des données : ils ne sont ni datés, ni horodatés, ni reproductibles, et ils s'expliquent dans l'immense majorité des cas par le vieillissement d'une batterie ou par une mise à jour du système.

L'échantillon de départ réunit une trentaine de procédures et de documentations décrivant explicitement ce qui est collecté et comment. Nous avons écarté les publications commerciales qui annoncent un résultat sans décrire la collecte, ainsi que les billets qui reprennent une procédure sans jamais l'appliquer. Le regroupement en six familles s'est fait par nature de la trace et non par outil : deux logiciels qui lisent le même journal système alimentent la même famille. Ce choix rend le dataset stable dans le temps, puisque les outils changent de nom et de version bien plus vite que les emplacements où un système d'exploitation écrit ses journaux.

Les six familles d'indicateurs, leur niveau de preuve et leur coût de collecte

Le classement par niveau de preuve importe davantage que la liste elle-même. Une anomalie réseau isolée ne démontre rien : un terminal contacte quotidiennement des centaines de domaines dont il n'a pas informé son porteur, et la publicité programmatique produit à elle seule des motifs de connexion irréguliers qui ressemblent à ceux d'un implant discret. Un profil de configuration installé sans que le titulaire s'en souvienne, à l'inverse, constitue un marqueur direct : il porte une date, un émetteur et un périmètre de droits. C'est cette hiérarchie que les demandes d'examen ignorent le plus souvent, en attendant du trafic réseau une certitude qu'il ne produit pas.

L'outillage public documenté et ce qu'il atteint réellement

ZATAZ documente deux outils qui couvrent précisément deux de ces familles. SpyGuard, dans sa version 2, observe les communications réseau via le Wi-Fi pour identifier des comportements suspects, des indicateurs de compromission et des anomalies, en s'appuyant sur le moteur Suricata, et ne se limite pas aux smartphones. Son auteur, Felix Aimé, a repris son développement après deux ans d'interruption pour l'adapter aux évolutions de Suricata. Mobile Verification Toolkit, connu sous le sigle MVT, a été développé par le laboratoire de sécurité d'Amnesty International et publié en juillet 2021 : il automatise la collecte de traces forensiques sur Android et iOS, donc les familles journaux système et sauvegardes.

La limite que pose explicitement ZATAZ vaut comme avertissement méthodologique et non comme critique de ces outils : aucune analyse fondée uniquement sur des indicateurs publics ne garantit qu'un appareil est sain, et un logiciel malveillant qui ne communique pas pendant la fenêtre d'analyse échappe à la détection. Cette limite éclaire une propriété contre-intuitive du dataset. La famille la plus coûteuse à collecter, le trafic réseau, est aussi celle dont le résultat négatif vaut le moins. Un examen qui ne trouve rien sur vingt-quatre heures d'observation réseau ne dit presque rien, alors qu'un examen de configuration qui ne trouve rien dit quelque chose de daté et de vérifiable.

Le résultat négatif, angle mort des demandes d'examen de terminal

Sur les demandes que nous voyons remonter, une large majorité, de l'ordre de sept sur dix en ordre de grandeur d'observation, arrive avec une attente implicite de blanchiment : le demandeur veut s'entendre dire que son téléphone est propre. Le dataset sert d'abord à rendre cette attente inatteignable et à la remplacer par une formulation utilisable. Un rapport d'examen honnête énonce les familles couvertes, la fenêtre temporelle, les versions d'outils et les emplacements lus, puis conclut sur l'absence d'indicateur relevé dans ce périmètre. Rien de plus. Cette formulation paraît décevante au demandeur ; elle est la seule qui survive à une contestation.

Un examen de terminal ne produit pas un verdict d'innocuité. Il produit un périmètre couvert, une fenêtre temporelle et une liste d'indicateurs relevés ou absents dans ce périmètre.

La conséquence organisationnelle est immédiate. Une équipe qui traite ces demandes gagne à documenter en amont ce qu'elle couvre, plutôt qu'à négocier après coup le sens d'un résultat. La veille technique compte ici autant que l'examen lui-même, car les marqueurs vieillissent : une signature réseau publiée par un laboratoire perd sa valeur dès que l'infrastructure visée change d'hébergeur ou de nom de domaine. NewsCore (www.newscore.fr) couvre en continu des millions de sources et fait remonter en temps réel les publications de recherche qui documentent de nouveaux marqueurs, ce qui maintient à jour la liste des emplacements et des signatures qu'un examen doit lire.

Limites du dataset et conditions de reproductibilité d'un examen

Trois limites doivent accompagner tout usage de ce recensement. La première tient à sa nature : il décrit un espace d'observables et non une fréquence de compromission, et aucune ligne ne doit être lue comme une probabilité. La deuxième tient à l'échantillon : les procédures publiques décrivent surtout des cas de surveillance ciblée documentés par des laboratoires ou par des organisations de défense des droits, ce qui surreprésente les implants sophistiqués face aux applications de traçage familial, beaucoup plus répandues et beaucoup plus banales à détecter. La troisième tient au système d'exploitation, dont les emplacements de journaux évoluent à chaque version majeure.

La reproductibilité repose sur trois éléments consignés à chaque examen : la version exacte du système du terminal, la version exacte de chaque outil utilisé, et l'horodatage de début et de fin de la fenêtre d'observation. Un tiers qui dispose de ces trois éléments et de la copie de sauvegarde refait l'analyse et compare. Sans eux, le rapport n'est pas réfutable, donc pas exploitable dans une procédure. Nous recommandons de consigner ces éléments avant même la collecte, dans le formulaire de prise en charge, plutôt qu'au moment de la rédaction, où ils sont systématiquement reconstitués de mémoire.

Questions fréquentes

Peut-on savoir avec certitude si un téléphone est espionné ?

Non, et cette réponse est la plus importante du dataset. ZATAZ le pose explicitement : aucune analyse fondée uniquement sur des indicateurs publics ne garantit qu'un appareil est sain, et un programme resté silencieux pendant la fenêtre d'analyse n'apparaît nulle part. Ce qu'un examen produit est vérifiable et borné : les familles d'indicateurs couvertes, la période observée, les outils utilisés, la liste des marqueurs relevés ou absents. Un prestataire qui promet un verdict d'innocuité promet quelque chose que la méthode ne délivre pas, quel que soit son outillage.

Quels indicateurs regarder en premier quand le temps manque ?

Les familles à coût faible et à niveau de preuve élevé, c'est-à-dire la configuration du terminal et les sessions de compte. Un profil installé, un certificat ajouté, une permission d'accessibilité accordée à une application anodine, un appareil inconnu autorisé sur le compte : ces éléments se lisent en quelques minutes, portent une date et se recoupent avec les déclarations du titulaire. Le trafic réseau, plus impressionnant, demande du matériel, du temps et une capacité de qualification que peu d'équipes possèdent en interne, pour un résultat négatif de faible valeur.

Un examen de terminal mobile a-t-il une valeur devant une juridiction ?

Il en a une si la chaîne de garde est tenue et si le rapport reste dans son périmètre. Cela suppose une copie de sauvegarde réalisée avant toute manipulation, un condensat calculé et consigné, un journal des opérations, et un rapport qui distingue explicitement le fait relevé de son interprétation. Les familles sauvegardes et sessions de compte se prêtent le mieux à cet usage, parce que leurs traces sont horodatées par un tiers. À l'inverse, une capture réseau interprétée sans qualification se retourne facilement contre celui qui la produit.