Comment exporter les données d'utilisation réseau de macOS

Vous avez enfin attrapé le pic. Pendant trois jours vous vous demandiez pourquoi votre usage Internet à la maison sautait à des heures aléatoires, et vous avez enfin un outil ouvert au bon moment pour le voir. Et maintenant ? Vous voulez ces données hors de l'interface en direct et dans quelque chose que vous pouvez analyser, partager avec un collègue, ou corréler à un log serveur. La capacité d'exporter les données d'usage réseau macOS compte plus que les gens ne le réalisent, et macOS a des options correctes une fois que vous savez où regarder.

Ce billet parcourt les chemins pratiques : nettop -L pour les captures courtes, le journal unifié pour les événements réseau côté système, les scripts d'échantillonnage pour CSV, et où ova stocke ses données sur disque.

Pourquoi exporter l'usage réseau macOS du tout

Quelques cas réels :

• Investigation d'anomalie — vous avez vu un téléversement de 2 Go à 3 h, vous voulez tracer le processus source à travers la nuit.
• Planification de capacité — vous êtes sur une connexion plafonnée ou comptée (Starlink Roam, Wi-Fi d'hôtel, partage mobile) et voulez savoir ce qu'il est sûr de laisser actif.
• Débogage de performance — votre équipe serveur demande quand les requêtes lentes ont commencé, et vous voulez superposer l'usage réseau côté client à leurs logs serveur.
• Budgétisation de bande passante par projet — vous facturez les clients à l'heure et voulez un contrôle de bon sens sur ce que leurs pipelines de build ont téléversé hier.
• Curiosité — vous voulez simplement regarder vos propres données.

Pour tout cela, « ouvrir Activity Monitor et fixer » ne suffit pas. Il vous faut des données sur disque, dans un format que vous pouvez manipuler.

Option 1 : mode log de nettop

Le chemin d'export le plus simple est intégré. nettop -L <count> tourne en mode log pour <count> échantillons, déversant chaque échantillon comme une ligne de texte, et quitte. Combiné avec -J pour choisir les colonnes et -s pour régler l'intervalle, vous obtenez une sortie propre que vous pouvez piper vers un fichier.

nettop -L 600 -s 1 -P -J bytes_in,bytes_out,interface,state \
  > ~/Desktop/nettop-10min.txt

C'est 600 échantillons à intervalles d'une seconde — dix minutes de capture. Chaque échantillon liste chaque processus actif avec les colonnes que vous avez demandées.

La sortie n'est pas exactement du CSV — elle a un en-tête par échantillon, des lignes vides entre les échantillons, et des noms de processus avec des espaces. Mais elle est analysable. Un court script awk ou Python la transformera en table propre.

Limites du logging nettop

• Il ne capture que pendant qu'il tourne. Si vous vouliez savoir ce qui s'est passé hier, c'est raté.
• Il rapporte cumulé-depuis-démarrage-du-processus par défaut ; vous calculez les deltas vous-même.
• Les processus auxiliaires apparaissent comme lignes séparées (pas de regroupement).
• Le format d'échantillon n'est pas du CSV de première classe ; attendez-vous à écrire un parseur.

Pour les captures ponctuelles d'une fenêtre temporelle spécifique — « je vais pousser sur GitHub, laissez-moi capturer cinq minutes autour de cela » — nettop -L est génial. Pour des données continues, vous voulez autre chose.

Option 2 : le journal unifié

Le journal unifié de macOS capture des événements structurés depuis les frameworks système, y compris le réseau. CFNetwork (la couche URLSession) et Network.framework émettent tous deux des lignes de log pour le cycle de vie de connexion, la poignée de main TLS, les retries, et les échecs. Vous pouvez les extraire après coup.

Pour voir ce qu'il y a maintenant, interrogez la dernière heure :

log show --last 1h --predicate 'subsystem == "com.apple.CFNetwork"' \
  --info --debug

Pour exporter dans un fichier :

log show --last 24h --predicate 'subsystem == "com.apple.CFNetwork"' \
  --style compact > ~/Desktop/cfnetwork-day.log

Prédicats utiles :

• subsystem == "com.apple.CFNetwork" — requêtes URLSession, TLS, redirections
• subsystem == "com.apple.network" — changements de chemin Network.framework, état de connexion
• process == "YourApp" — restreindre à une application
• eventMessage CONTAINS "443" — recherche textuelle dans les messages de log

Le journal unifié garde grossièrement les derniers jours d'événements système, selon le volume. Il n'est pas conçu pour la comptabilité d'octets — il est conçu pour l'audit d'événements. Mais si votre question est « la connexion à api.example.com a-t-elle échoué à 14:23 », le journal unifié sait.

log show vs log stream

log show lit le journal historique. log stream observe les nouveaux événements en direct. Utilisez log stream quand vous voulez laisser un terminal tourner et observer les événements à mesure qu'ils arrivent :

log stream --predicate 'subsystem == "com.apple.network"' --level debug

Pipez vers un fichier avec >> pour ajouter à une capture roulante.

Option 3 : un script d'échantillonnage personnalisé

Si vous voulez une sortie CSV de bande passante par processus — le vrai but pour la plupart des gens — vous pouvez le construire en 20 lignes de shell. L'idée : sondez toutes les N secondes, faites le diff des compteurs cumulés d'octets, émettez du CSV.

#!/usr/bin/env bash
# Naive per-process bandwidth sampler.
INTERVAL=5
echo "timestamp,pid,process,delta_in,delta_out"
declare -A prev_in prev_out
while true; do
  ts=$(date +%s)
  while IFS=, read pid name in_bytes out_bytes; do
    pi=${prev_in[$pid]:-0}
    po=${prev_out[$pid]:-0}
    di=$((in_bytes - pi))
    do_=$((out_bytes - po))
    if (( di > 0 || do_ > 0 )); then
      echo "$ts,$pid,$name,$di,$do_"
    fi
    prev_in[$pid]=$in_bytes
    prev_out[$pid]=$out_bytes
  done < <(nettop -P -L 1 -J pid,interface,bytes_in,bytes_out 2>/dev/null \
            | awk 'NR>2 {print $2","$1","$3","$4}')
  sleep $INTERVAL
done

C'est une esquisse — du code de production gérerait les sorties de processus, le regroupement des auxiliaires, la rotation des logs, et le fait que le format de sortie de nettop est agaçant à parser — mais cela montre la forme. Vous échantillonnez, vous diffez, vous émettez du CSV. Lancez-le sous caffeinate ou comme agent launchd si vous voulez qu'il survive à la mise en veille.

Voyez ova en action

Un moniteur de bande passante en barre de menu consultable d'un coup d'œil — local, signé, ~3 Mo.

Télécharger pour macOS

Option 4 : la base de données locale d'ova

Un moniteur de bande passante dédié vous épargne d'écrire le script ci-dessus. ova garde une base SQLite dans :

~/Library/Application Support/ova/

Le contenu est la même donnée de série temporelle que vous voyez dans l'interface : octets entrants et sortants par application, échantillonnés à environ 1 Hz, avec les processus auxiliaires regroupés sous leur application parente. C'est local, pas de synchro cloud, pas de télémétrie. Vous possédez le fichier.

Parce que c'est SQLite, tout ce qui peut lire SQLite peut le lire : la CLI sqlite3, le module sqlite3 de Python, DB Browser for SQLite, ou une requête rapide dans DuckDB. Vous pouvez :

• Exporter l'historique entier en CSV avec une commande
• Lancer des agrégations (« quelle application a utilisé le plus de bande passante cette semaine, par heure »)
• Faire des jointures avec vos propres logs (pipelines de build, logs d'accès serveur, événements de calendrier)
• La sauvegarder vers votre cible de sauvegarde habituelle

Un export typique vers CSV avec sqlite3 :

sqlite3 -header -csv \
  ~/Library/Application\ Support/ova/<file>.sqlite \
  "SELECT timestamp, app, bytes_in, bytes_out FROM samples \
   WHERE timestamp > strftime('%s','now','-7 days') \
   ORDER BY timestamp" > ~/Desktop/last-week.csv

Recettes pratiques, jointures, et confidentialité

Une fois que vous avez un CSV — depuis n'importe quelle source — quelques requêtes paient l'effort.

Top applications par semaine

SELECT app,
       SUM(bytes_in) / (1024*1024) AS mb_down,
       SUM(bytes_out) / (1024*1024) AS mb_up
  FROM samples
 WHERE timestamp > strftime('%s','now','-7 days')
 GROUP BY app
 ORDER BY (mb_down + mb_up) DESC
 LIMIT 20;

Raconte presque toujours une histoire claire. Navigateur en haut, applications de synchro au milieu, services système en bas.

Heatmap horaire

SELECT strftime('%H', timestamp, 'unixepoch', 'localtime') AS hour,
       SUM(bytes_in + bytes_out) / (1024*1024) AS mb
  FROM samples
 WHERE timestamp > strftime('%s','now','-30 days')
 GROUP BY hour
 ORDER BY hour;

Vous montre quand votre trafic pique. Pour la plupart des gens : 9 h, 13 h, et 16 h, avec une longue traînée de synchro cloud durant la nuit.

Détection d'anomalies

SELECT app,
       date(timestamp, 'unixepoch', 'localtime') AS day,
       SUM(bytes_out) / (1024*1024) AS mb_up
  FROM samples
 GROUP BY app, day
HAVING mb_up > 500
 ORDER BY mb_up DESC;

Signale toute paire application-jour avec plus de 500 Mo de téléversement. Une poignée est normale (Time Machine vers une cible réseau, synchro photo, gros transferts de fichiers). Une liste entière d'applications inconnues mérite l'investigation.

Combiner les sources

Le flux de travail le plus fort utilise plusieurs sources à la fois.

• ova pour la comptabilité d'octets — ce qui a été utilisé, par quelle application, quand
• Journal unifié pour les événements — quand les connexions ont démarré, échoué, retenté
• tcpdump pour le câble — quand quelque chose est franchement mystérieux

Vous pouvez les joindre sur l'horodatage. Si ova montre un téléversement de 200 Mo par cloudd à 3:14, le journal unifié montre ce que cloudd synchronisait, et (si vous aviez une capture de paquets en marche) tcpdump montre l'espace IP de destination confirmant que c'était iCloud.

Une note sur la confidentialité

Tout ce qui exporte des données réseau peut fuiter de l'information que vous n'aviez pas l'intention de partager. Les noms d'hôtes, même les chemins dans le journal unifié, peuvent révéler quels services vous utilisez. Avant d'envoyer des logs à un collègue ou de coller dans un chat :

• Retirez les adresses IP si elles identifient votre réseau maison
• Censurez les noms d'hôtes qui révèlent des services personnels
• Supprimez les noms de processus qui révèlent des applications que vous préférez ne pas annoncer

C'est aussi pourquoi les outils strictement locaux comptent. ova n'envoie vos données nulle part — elles restent sur votre disque. Ce que vous exportez est votre décision.

Pour conclure

Pour exporter les données d'usage réseau macOS, vous avez plusieurs chemins raisonnables : nettop -L pour les captures courtes, le journal unifié pour l'audit d'événements, des scripts d'échantillonnage personnalisés pour le contrôle complet, et un moniteur local adossé à SQLite comme ova pour la comptabilité par application continue. Choisissez selon que vous avez besoin d'événements ou d'octets, et la durée de fenêtre qui vous importe.

Pour un chemin à effort minimal qui capture en continu et vous laisse interroger plus tard, installez ova — environ 3 Mo, macOS 14+, Apple Silicon et Intel, échantillonne à environ 1 Hz. Les données vivent dans votre répertoire ~/Library/Application Support/ova/ en SQLite, donc tout outil d'analyse que vous connaissez déjà peut les lire.