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.
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 *:5353Lisez-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.
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.4KAjoutez -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.
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).
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".
dig example.com +short
# example output
93.184.216.34Aucun 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 :
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)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
sudo lsof -i -n -P— obtient la liste actuelle des sockets ouverts, un passage, trente secondes.nettop -m route -l 5- récupérez quelques échantillons en direct pour capturer tout ce que l'instantané de lsof a manqué.scutil --dns— confirmez quel résolveur vous utilisez réellement, surtout si vous utilisez un VPN ou un Wi-Fi public.dig <name> +short, sur tout ce qui n'est pas familier à l'étape 1, pour voir à quoi cela correspond actuellement.sudo tcpdump -i en0 -n port 53, pendant soixante secondes, pour observer le trafic DNS brut pendant que les applications vaquent à leurs occupations.log stream --predicateavec 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 Autopilot) 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.