# Auditez ce que votre Mac envoie en 10 minutes, depuis le terminal

> Un audit de dix minutes, uniquement livré avec des outils macOS : lsof, nettop, log stream, scutil --dns, dig et tcpdump - ce que chacun montre réellement, les commandes exactes et ce qu'aucun d'entre eux ne peut vous dire.

HisnLabs Security & Research Team · Published 2026-09-14
Canonical: https://hisnlabs.com/fr/blog/audit-mac-network-terminal

Vous n'avez pas besoin d'installer quoi que ce soit pour obtenir une image réelle et actuelle de ce à quoi votre Mac communique. Chaque outil de cet atelier est livré avec macOS. Aucun d’entre eux ne vous oblige à faire confiance à un tiers pour votre trafic, et tous les six prennent ensemble environ dix minutes à exécuter une fois que vous connaissez les commandes. Ce qu’ils ne feront pas, et c’est important, c’est vous dire lesquelles de ces connexions sont bonnes et lesquelles ne le sont pas – pour cela, vous avez toujours besoin de contexte, et à la fin, nous serons honnêtes quant à l’endroit où s’arrêtent ces outils.

## 1. lsof — chaque connexion ouverte, en ce moment

Sous Unix, une socket réseau est un fichier et `lsof` (liste des fichiers ouverts) les répertorie. La page de manuel de macOS décrit `-i` comme sélectionnant des fichiers dont l'adresse Internet correspond à une spécification donnée – sans qu'aucun ne soit donné, sur chaque socket Internet. Ajoutez `-n` pour ignorer la résolution des adresses en noms d'hôtes et `-P` pour ignorer la résolution des ports en noms de services ; les deux rendent la commande plus rapide et la sortie exacte plutôt qu'approximative.

*Terminal – chaque prise réseau ouverte*

```console
$ sudo lsof -i -n -P
# example output, trimmed to a few representative lines
COMMAND   PID   USER   FD   TYPE  DEVICE SIZE/OFF NODE NAME
Mail      612   alice   9u  IPv4  0x...      0t0  TCP 192.168.1.10:54321->17.57.145.13:993 (ESTABLISHED)
Slack     980   alice  22u  IPv4  0x...      0t0  TCP 192.168.1.10:54400->35.186.224.25:443 (ESTABLISHED)
mDNSResp   88   root    4u  IPv4  0x...      0t0  UDP *:5353
```

Lisez-le de gauche à droite : le nom du processus et le PID, l'adresse et le port locaux, `->` et l'adresse et le port distants, ainsi que l'état de la connexion. `ESTABLISHED` signifie actuellement une connexion bidirectionnelle active. Exécutez sans `sudo`, vous verrez toujours vos propres processus ; ceux appartenant à Root en ont besoin. Ce que cela ne peut pas vous dire : `lsof` est un instantané de l'instant où vous avez appuyé sur Entrée. Une connexion qui s'est ouverte, a envoyé quelques kilo-octets et s'est fermée une demi-seconde avant l'exécution de la commande n'est tout simplement pas là : vous devez l'exécuter à plusieurs reprises ou passer à l'outil suivant pour l'attraper.

## 2. nettop — la même vue, mais en direct

nettop est la version live de la même idée. Sa page de manuel le décrit comme affichant « une liste de sockets ou de routes » avec des statistiques périodiquement mises à jour. `-m route` le fait passer de la liste des sockets à la liste de la vue de la table de routage ; `-m tcp` ou `-m udp` le limitent à un seul protocole.

*Terminal : connexions en direct, actualisées toutes les secondes*

```console
$ nettop -m route
# interactive; press q to quit, or use -l N to print N samples and exit
# example output, trimmed
  time                     interface  state       bytes_in  bytes_out
23:41:02.123 Mail.612      en0        Established     4.2K      1.1K
23:41:02.123 Slack.980     en0        Established    18.6K      6.4K
```

Ajoutez `-l 5` pour récupérer cinq échantillons et quitter au lieu de tenir une session interactive, utile si vous souhaitez diriger la sortie quelque part. nettop résout le problème d'instantané de lsof - vous pouvez regarder une connexion apparaître, transférer des données et se fermer - mais il hérite du même plafond : un nom de processus et un PID, rien sur qui a signé le binaire, et pas de mémoire une fois le terminal fermé.

## 3. flux de journaux : ce que le système lui-même dit à propos du réseau

macOS conserve un journal unifié et structuré de ce que fait chaque processus, et `log stream` vous permet de le regarder en direct, filtré. La page de manuel décrit `--predicate` comme filtrant les entrées à l'aide de clauses de style NSPredicate par rapport au contenu du sous-système, de la catégorie, du processus et du message.

*Terminal : diffusion en continu des entrées de journal liées au réseau*

```console
$ log stream --predicate 'eventMessage contains "network" or subsystem == "com.apple.network"' --info
# live stream; Ctrl-C to stop. Example line, trimmed:
2026-09-14 23:41:05.001 process=nesessionmanager subsystem=com.apple.network "TCP Connection ... state changed to Ready"
```

Il s'agit du moins accessible des six outils - le volume est élevé et la syntaxe des prédicats a une courbe d'apprentissage - mais c'est également le seul qui fait apparaître les changements d'état du réseau au niveau du système et les événements du cycle de vie des connexions au fur et à mesure qu'ils se produisent, en anglais simple, étiqueté par le sous-système responsable. Traitez-le comme quelque chose à grep, pas à lire ligne par ligne : dirigez-le via `grep` pour un nom de processus qui vous intéresse, ou un mot-clé comme `"Wi-Fi"` ou `"VPN"`.

## 4. scutil --dns et dig — ce que votre Mac résout réellement

Avant qu’une connexion n’ait lieu, une recherche DNS est généralement effectuée. `scutil --dns`, selon sa page de manuel, "rapporte la configuration DNS actuelle" : quels résolveurs sont configurés, lequel est la valeur par défaut et lesquels s'appliquent uniquement à des domaines spécifiques (DNS divisé, courant sur les VPN).

*Terminal – configuration actuelle du résolveur DNS*

```console
$ scutil --dns
# example output, trimmed
DNS configuration
resolver #1
  nameserver[0] : 192.168.1.1
  if_index : 12 (en0)
  flags    : Request A records, Request AAAA records
  reach    : 0x00020002 (Reachable,Directly Reachable Address)
```

`dig` répond directement à une seule question : à quoi correspond ce nom, à l'heure actuelle. Sa page de manuel l'appelle "un outil flexible pour interroger les serveurs de noms DNS" apprécié pour "la flexibilité, la facilité d'utilisation et la clarté du résultat".

*Terminal - résolution d'un seul nom d'hôte*

```console
$ dig example.com +short
# example output
93.184.216.34
```

Aucun des deux outils ne vous indique quelle application a déclenché la recherche ou ce qui s'est passé après : le DNS ne vous donne que l'adresse à laquelle une application est sur le point de se connecter (ou s'est déjà connectée) ; la connexion elle-même est ce que lsof, nettop ou un journal de pare-feu vous montre.

## 5. tcpdump - la vérité terrain et celle qui a besoin de sudo

Tout ce qui précède indique l'état que le système d'exploitation conserve déjà. `tcpdump` est différent : il capture les paquets directement depuis une interface, c'est pourquoi sa propre documentation est directe sur l'exigence — "La lecture de paquets à partir d'une interface réseau peut nécessiter que vous disposiez de privilèges spéciaux" — en pratique, `sudo` sur macOS. Utilisez `-i` pour sélectionner l'interface, `-n` pour conserver les adresses numériques et une expression de filtre comme `port 53` pour isoler le trafic DNS :

*Terminal : regarder les requêtes DNS quitter la machine*

```console
$ sudo tcpdump -i en0 -n port 53
# example output, trimmed
23:41:10.221331 IP 192.168.1.10.54812 > 192.168.1.1.53: 41213+ A? example.com. (30)
23:41:10.244109 IP 192.168.1.1.53 > 192.168.1.10.54812: 41213 1/0/0 A 93.184.216.34 (46)
```

> **Warning:** Cela nécessite des privilèges élevés car il lit les paquets directement sur l'interface réseau – le même niveau d'accès qui pourrait, en principe, capturer bien plus que le DNS si vous élargissez le filtre ou le supprimez complètement. Gardez le filtre étroit, exécutez-le pendant une courte fenêtre et fermez le terminal lorsque vous avez terminé. Ne laissez pas une capture large et non filtrée s’exécuter sans surveillance.

Le schéma à remarquer : une requête sortante sur le port 53 immédiatement suivie d'un retour de réponse. Si vous exécutez `dig` dans un terminal tandis que `tcpdump` s'exécute dans un autre, vous pouvez observer la requête et la réponse exactes produites par votre propre commande - un bon moyen de croire réellement ce que disent les pages de manuel plutôt que de les prendre sur la foi.

## Un septième outil gratuit : Activity Monitor

Il vaut la peine de nommer la seule option graphique de cette liste, car tout n'a pas besoin d'un terminal. L'onglet Réseau d'Activity Monitor vous donne les totaux - données envoyées et reçues par processus, et un graphique de débit en direct - qui est le bon premier arrêt pour "quelque chose grignote la bande passante et je ne sais pas quoi". C'est également l'illustration la plus claire du plafond que partagent tous les outils de cet article : il peut vous indiquer qu'un processus d'assistance a déplacé deux gigaoctets du jour au lendemain, et il n'a pas de colonne indiquant où sont allés ces deux gigaoctets. Le volume et la destination sont deux questions différentes, et macOS y répond avec deux outils différents.

## Rassembler les dix minutes

1. `sudo lsof -i -n -P` — obtient la liste actuelle des sockets ouverts, un passage, trente secondes.
2. `nettop -m route -l 5` - ​​récupérez quelques échantillons en direct pour capturer tout ce que l'instantané de lsof a manqué.
3. `scutil --dns` — confirmez quel résolveur vous utilisez réellement, surtout si vous utilisez un VPN ou un Wi-Fi public.
4. `dig <name> +short`, sur tout ce qui n'est pas familier à l'étape 1, pour voir à quoi cela correspond actuellement.
5. `sudo tcpdump -i en0 -n port 53`, pendant soixante secondes, pour observer le trafic DNS brut pendant que les applications vaquent à leurs occupations.
6. `log stream --predicate` avec un mot-clé grep, si quelque chose ci-dessus soulevait une question à laquelle les cinq précédentes n'avaient pas répondu.

## Un exemple concret

Supposons que l'étape 1 génère un processus appelé `helperd` détenant une connexion ouverte à une adresse que vous ne reconnaissez pas. Ne vous arrêtez pas là. Exécutez `dig -x <the address>` pour une recherche inversée : elle ne sera pas toujours résolue en quelque chose de lisible, mais lorsque c'est le cas, un nom d'hôte comme `ads.example-cdn.net` vous en dit plus en cinq secondes que l'adresse IP brute ne le fera jamais. Exécutez `nettop -m tcp -l 3` et vérifiez si cette même connexion est toujours ouverte quelques secondes plus tard et si des octets la traversent réellement ou si elle est inactive. S'il est inactif et rouvre à intervalle fixe, il s'agit d'un enregistrement périodique plutôt que d'un transfert ponctuel – ce qui mérite d'être rappelé, mais ne vaut pas automatiquement la peine de s'inquiéter, puisque les vérificateurs de mise à jour ordinaires se comportent de la même manière. Vérifiez ensuite `scutil --dns` pour confirmer que le résolveur qui a produit l'adresse à laquelle `helperd` connecté était celle à laquelle vous vous attendiez, surtout si vous êtes sur le Wi-Fi de quelqu'un d'autre. Cinq commandes, un processus, et vous êtes passé de « Je ne reconnais pas cela » à « Voici précisément ce que je sais et ce que je n’en sais pas » – ce qui est le véritable objectif d’un audit comme celui-ci, plus qu’un verdict de bien ou de mal.

## Ce qu'aucun de ces outils ne vous dira

Parcourez les six et vous avez encore trois véritables lacunes. Premièrement, l'identité au-delà du nom du processus : rien ici ne vérifie si le binaire appelé "Mail" est le courrier d'Apple ou quelque chose qui s'est renommé, ou s'il est signé du tout - il s'agit d'une recherche distincte avec `codesign` et `spctl`. Deuxièmement, la mémoire : une fois la fenêtre du terminal fermée, tout ce que vous avez appris se ferme également ; il n'y a pas de journal de "ce à quoi mon Mac s'est connecté mardi dernier" à moins que vous n'en construisiez un vous-même. Troisièmement, le jugement : aucun de ces outils n’a d’opinion sur la question de savoir si une connexion est attendue. Une application de prise de notes se connectant à une adresse qu'elle n'a jamais utilisée auparavant a exactement la même apparence dans `lsof` qu'une application se connectant à son serveur de synchronisation habituel - distinguer ces deux est une reconnaissance de formes que vous devez apporter vous-même, ou un outil doit apporter pour vous.

## Le rôle de FireAI et de HisnLabs

Everything in this lab is free and built into macOS, and none of it names the process behind a connection or remembers it after the terminal closes — which is the specific, narrow gap FireAI’s per-app rules and connection history are built to close.

FireAI est le produit de HisnLabs : un pare-feu IA embarqué pour Mac. Il montre en langage clair chaque connexion faite par vos applications et vous laisse décider ce qui sort de votre Mac — son IA fonctionne en local, votre trafic ne nous est jamais envoyé, ni à personne d’autre. L’équipe de recherche en sécurité de HisnLabs est celle qui garde ces décisions fiables : elle recense les domaines de simple télémétrie face à ceux d’un vrai service, suit le pays et le réseau derrière une connexion, et entraîne le modèle embarqué (la fonction FireAI Pilot) sur du trafic réel, sans que rien ne quitte votre Mac.

Vous pouvez lire les choix techniques qui s’y trouvent, ou essayer FireAI pendant 17 jours, sur [FireAI, par HisnLabs](https://hisnlabs.com/fireai/fr/download).

## Sources

- [SS64: lsof man page for macOS](https://ss64.com/mac/lsof.html)
- [nettop(1) man page (Xcode man pages mirror)](https://keith.github.io/xcode-man-pages/nettop.1.html)
- [log(1) man page (Xcode man pages mirror)](https://keith.github.io/xcode-man-pages/log.1.html)
- [scutil(8) man page (Xcode man pages mirror)](https://keith.github.io/xcode-man-pages/scutil.8.html)
- [dig(1) man page (Xcode man pages mirror)](https://keith.github.io/xcode-man-pages/dig.1.html)
- [SS64: tcpdump man page for macOS](https://ss64.com/mac/tcpdump.html)