Speedtest Tracker

Speedtest Tracker est une application auto-hébergée qui lance le CLI Speedtest d’Ookla selon un planning défini et conserve chaque résultat, débit descendant, débit montant, ping et perte de paquets, dans un tableau de bord que vous contrôlez. Plutôt qu’une capture d’écran d’un bon jour, vous obtenez des mois d’historique montrant ce que fait réellement votre connexion à 3h du matin, pendant un orage, ou juste après que votre FAI jure avoir « réglé le problème ».

Ce que fait vraiment Speedtest Tracker

La logique de base est simple : une tâche cron que vous définissez déclenche un vrai test de vitesse Ookla à l’intervalle choisi, toutes les 30 minutes, toutes les 6 heures, peu importe, et le résultat atterrit dans une base de données avec débit, ping, gigue et perte de paquets. Au bout de quelques semaines, ça se transforme en graphique, bien plus difficile à contester pour un FAI qu’un simple « ça rame ».

Les notifications passent par Apprise : une seule configuration débloque Discord, Telegram, e-mail, Slack, ntfy et une longue liste d’autres services, avec des seuils pour n’être alerté que sous une valeur définie, pas à chaque test. Vous pouvez aussi cibler des serveurs Ookla précis plutôt que le plus proche par défaut, et les anciens résultats peuvent être purgés automatiquement après un nombre de jours donné.

Installer Speedtest Tracker avec Docker

L’image est maintenue par LinuxServer.io plutôt que par l’auteur d’origine de l’app, un schéma courant pour les outils self-hosted une fois assez populaires. Elle embarque SQLite par défaut, donc pas de conteneur de base de données séparé pour un premier essai, même si Postgres et MySQL sont pris en charge si vous préférez une instance existante.

services:
  speedtest-tracker:
    image: lscr.io/linuxserver/speedtest-tracker:latest
    container_name: speedtest-tracker
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Etc/UTC
      - APP_KEY=
      - APP_URL=http://192.168.1.50:8765
      - DB_CONNECTION=sqlite
      - SPEEDTEST_SCHEDULE=0 */6 * * *
      - SPEEDTEST_SERVERS=
      - DISPLAY_TIMEZONE=Etc/UTC
      - PRUNE_RESULTS_OLDER_THAN=90
    volumes:
      - ./data:/config
    ports:
      - 8765:80
    restart: unless-stopped

1. Générez un APP_KEY avant le premier démarrage ; le conteneur affichera un avertissement au lancement s’il est absent. La documentation officielle d’installation explique comment en générer un avec la commande artisan propre au conteneur.
2. Enregistrez le fichier compose ci-dessus, en ajustant APP_URL pour qu’il corresponde à la façon dont vous atteindrez réellement le conteneur, puis lancez docker compose up -d.
3. Ouvrez l’interface web et connectez-vous avec les identifiants par défaut admin@example.com / password, puis changez les deux immédiatement.
4. Définissez SPEEDTEST_SCHEDULE en syntaxe cron standard. 0 */6 * * * lance un test toutes les six heures ; le faire toutes les quelques minutes est excessif pour la plupart des connexions domestiques.
5. Dans les paramètres, configurez une URL de notification Apprise si vous voulez être alerté quand un test tombe sous votre référence habituelle.

docker compose up -d

Cas d’usage en homelab

La raison la plus courante d’installer cet outil, c’est de constituer un dossier de preuves face à son FAI. Le support technique adore répondre « tout est normal de notre côté » quand votre connexion rame depuis une semaine, et un graphique avec trois mois de résultats horodatés est un argument bien plus solide que « ça rame », surtout quand vous payez pour un débit contractuel précis et n’obtenez que 60 % de celui-ci en soirée.

Le deuxième cas d’usage, c’est de repérer une dégradation silencieuse. Une connexion meurt rarement d’un coup : elle empire après une mise à jour de firmware, une mauvaise soudure dans le quartier, ou parce que votre FAI sursouscrit discrètement un nœud proche de chez vous. Sans historique, les petites baisses passent inaperçues jusqu’à s’accumuler en un vague « pourquoi tout rame ces derniers temps ». Avec Speedtest Tracker qui enregistre toutes les quelques heures, vous pouvez corréler une baisse à une date précise et remonter votre propre journal de changements pour trouver la cause plutôt que deviner.

Speedtest Tracker face à un script cron DIY et à Uptime Kuma

Vous n’avez pas strictement besoin de Speedtest Tracker pour enregistrer des résultats : une tâche cron qui appelle le CLI Ookla et déverse la sortie dans un CSV fait le même travail de base. La différence, c’est tout ce que Speedtest Tracker construit autour de ces données brutes : un tableau de bord, des graphiques, des seuils de notification et une purge automatique, sans que vous ayez à écrire et maintenir cet outillage vous-même.

	Speedtest Tracker	Script cron + CLI Ookla (DIY)	Uptime Kuma
Effort d’installation	Conteneur + docker-compose + APP_KEY	Scripts, parsing et stockage à maintenir	Conteneur, zéro config pour un premier moniteur
Ce qui est mesuré	Débit, ping, gigue, perte de paquets, vrais tests Ookla	Mêmes données brutes, si vous codez le parsing	État up/down et latence, pas de débit
Tableau de bord	Intégré, historique filtrable	Aucun, à construire ou envoyer vers Grafana	Intégré, mais pour la disponibilité
Notifications	Apprise, 70+ services, par seuils	Ce que vous scriptez	90+ services intégrés
Idéal pour	Prouver la performance du FAI dans la durée	Contrôle total si le dashboard intégré ne suffit pas	Savoir si un service répond, tout court

Une précision utile : Uptime Kuma et Speedtest Tracker résolvent des problèmes différents et se complètent plutôt qu’ils ne se concurrencent. Uptime Kuma vous dit qu’un service est joignable et à quelle vitesse il a répondu à un ping ou une requête HTTP. Il n’a aucune idée de votre débit descendant réel, et ce n’est pas son rôle. Si vous voulez savoir à la fois « est-ce que mon internet fonctionne » et « est-ce que mon internet est vraiment rapide », vous finissez par faire tourner les deux.

Speedtest Tracker : avantages et inconvénients

• Utilise la vraie infrastructure de test d’Ookla, les mêmes serveurs et la même méthodologie que speedtest.net
• Conteneur unique avec SQLite par défaut, rien de plus à provisionner pour un premier déploiement
• Notifications Apprise par seuils : repérez une mauvaise connexion sans surveiller un tableau de bord en permanence
• Les graphiques historiques transforment une plainte vague en argument concret et horodaté pour le support du FAI

• Chaque test planifié consomme de la vraie bande passante, en concurrence avec le reste de vos usages
• Dépend du CLI et des serveurs tiers d’Ookla, donc pas indépendant à 100 % d’un service externe
• Nécessite de générer un APP_KEY avant de démarrer, une étape de plus que les outils zéro-config
• Mesure uniquement débit et latence, aucun diagnostic paquets ni traceroute intégré

FAQ

Speedtest Tracker est-il gratuit ?

Oui, l’app est sous licence MIT, code source complet sur GitHub, aucun palier payant. Seul point d’attention côté coût : le CLI Ookla sous-jacent, gratuit sous sa propre EULA pour un usage personnel non commercial, exactement le genre de test que la plupart des gens font tourner ici.

Est-ce que ça utilise mon compte Ookla speedtest.net ?

Non, aucun compte requis. L’app appelle directement le CLI Ookla, qui tourne anonymement sur le réseau de serveurs public d’Ookla, la même infrastructure que speedtest.net utilise dans un navigateur, simplement sans connexion associée.

Puis-je choisir le serveur testé ?

Oui, via la variable d’environnement SPEEDTEST_SERVERS, une liste d’identifiants de serveurs Ookla séparés par des virgules. Laissée vide, l’app sélectionne automatiquement le plus proche ; fixer un identifiant précis donne des résultats plus cohérents dans le temps.

En quoi est-ce différent de lancer speedtest-cli manuellement ?

Un test manuel ne renseigne que sur l’instant où vous l’avez lancé. Speedtest Tracker automatise ce même test selon un planning et conserve l’historique, pour repérer des tendances sur plusieurs jours ou semaines plutôt qu’un point isolé qui a pu tomber sur un bon ou un mauvais moment.

Faut-il exposer le tableau de bord sur internet ?

Pas directement. Comme la plupart des tableaux de bord self-hosted, il est conçu pour être atteint depuis votre réseau local ou via un reverse proxy avec authentification, ou un VPN comme Tailscale pour un accès à distance, plutôt qu’exposé en redirection de port vers internet.

Speedtest Tracker mérite sa place dans un homelab de la même façon qu’Uptime Kuma : un petit conteneur mono-usage qui répond bien à une question précise, ici « est-ce que mon FAI livre vraiment ce pour quoi je paie ». Associez-le à Uptime Kuma pour la disponibilité et à Netdata pour la visibilité sur votre propre matériel. Notre guide auto-hébergement pour monter votre premier homelab couvre les bases Docker dont ces trois outils dépendent.