Comparatif des apps de suivi de position auto-hébergées

Quelle application de suivi de position auto-hébergée correspond à votre cas

Le suivi de position auto-hébergé repose sur une question simple : voulez-vous conserver un historique pour vous-même ou suivre une position en temps réel avec d’autres personnes ? Dawarich répond au premier besoin. Il remplace Google Maps Timeline en auto-hébergement et importe l’historique dont vous disposez déjà. Traccar répond au second. Il a été conçu pour le matériel GPS et les flottes, et considère un téléphone comme un tracker supplémentaire. OwnTracks intervient en complément des deux comme application mobile et format de messages. Si vous utilisez Home Assistant, celui-ci connaît déjà la position de votre téléphone, mais supprime la trace après dix jours par défaut.

Choisissez selon ce que vous voulez consulter le mois prochain :

• Une carte de tous vos déplacements de mars dernier, avec les lieux et les trajets : Dawarich.
• Une carte en temps réel de plusieurs appareils, avec des geofences et des règles d’événement : Traccar.
• Un téléphone qui envoie sa position à un service que vous utilisez déjà : OwnTracks en mode HTTP.
• Des automatisations présence/absence, sans intérêt pour l’historique : Home Assistant seul.

Rien ne fonctionne tant que le téléphone ne peut pas accéder à un endpoint HTTPS que vous contrôlez. La configuration côté serveur fait donc l’objet d’une section dédiée ci-dessous. Si vous déterminez encore quels autres services installer sur le serveur, la liste plus large de ce qu’il est pertinent d’auto-héberger cette année montre où se situe un tracker par rapport au reste.

Traccar : matériel GPS, flottes et position en temps réel

Traccar est un serveur de tracking. Il prend en charge les protocoles utilisés par les trackers GPS dédiés, chacun sur son propre port, numérotés de 5001 à 5266 dans la liste actuelle des protocoles. Les instructions Docker de Traccar publient également toute la plage 5000 à 5300 en TCP et en UDP. Le serveur fournit aussi une carte en temps réel, des geofences, des règles d’événements et des rapports. L’interface web écoute par défaut sur le port 8082.

Pour les téléphones, Traccar fournit l’application Traccar Client pour Android et iOS. Elle envoie les positions via le protocole OsmAnd, qui écoute par défaut sur le port 5055. Ses réglages déterminent l’autonomie de la batterie et le nombre de lignes enregistrées. Distance demande une mise à jour tous les N mètres pendant les déplacements. Interval active l’envoi périodique selon le temps lorsque la distance vaut 0, ce qui fonctionne uniquement sur Android, ou lorsque la précision est réglée sur « maximale ». Angle déclenche une mise à jour lorsque le cap change, en degrés, lorsque la précision est réglée sur « maximale ». Stationary Heartbeat définit le comportement lorsque l’appareil ne se déplace pas. La documentation de Traccar précise que le résultat exact n’est garanti pour aucun de ces réglages, car c’est le téléphone qui décide.

Traccar est fourni avec une base de données H2 intégrée afin que l’installation fonctionne sans configuration supplémentaire, mais le projet ne recommande pas H2 en production. Sa documentation couvre MySQL, MariaDB et PostgreSQL comme solutions de remplacement. Elle recommande TimescaleDB, une base de données de séries temporelles fondée sur PostgreSQL, pour les déploiements importants. Migrez la base de données avant d’accumuler de l’historique, car la conversion ultérieure d’un fichier H2 est une opération manuelle sans outil pris en charge.

Traccar convient moins bien lorsqu’il s’agit de conserver une chronologie personnelle : c’est une console pour surveiller des objets en temps réel. Les rapports portent sur les flottes, les trajets, les arrêts et les synthèses. Une année de vos propres week-ends ressemble donc davantage au résultat d’une requête qu’à une timeline.

OwnTracks : une application mobile et un endpoint, rien de plus

OwnTracks est la configuration classique minimale. L’application publie une petite charge utile JSON chaque fois qu’elle détermine que l’appareil s’est déplacé. Elle peut publier via MQTT (message queuing telemetry transport) ou via HTTP simple. En mode HTTP, l’endpoint est une URL de la forme http[s]://[user[:password]@]host[:port]/path, authentifiée avec HTTP Basic, et le projet recommande fortement le schéma https://. Avec OwnTracks Recorder, le chemin est /pub.

Le mode de suivi compte davantage que les paramètres du serveur. Quiet publie uniquement lorsque vous le demandez. Manual ajoute la surveillance des régions et une demande de localisation basse consommation. Significant est le mode automatique normal. Sous iOS, Move publie dès que l’appareil a parcouru locatorDisplacement mètres ou que locatorInterval secondes se sont écoulées, selon la première condition remplie, avec des valeurs par défaut de 100 mètres et 300 secondes. Sous Android, Move demande une position toutes les 10 secondes par défaut. OwnTracks indique que le mode Move consomme autant de batterie qu’une application de navigation et le conseille pour un trajet ou pendant la recharge, plutôt que comme réglage quotidien.

OwnTracks Recorder stocke les données reçues et fournit une petite carte. Le composant distinct OwnTracks Frontend ajoute une interface web plus complète, avec une heatmap, un filtrage par plage de dates et un historique affiché sous forme de points ou de lignes. Beaucoup de personnes n’installent jamais Recorder, car la charge utile est identique que l’application pointe vers Recorder, Dawarich ou Home Assistant. C’est pourquoi il est préférable de commencer ici : l’application est un producteur stable et prévisible, et vous pourrez changer de consommateur plus tard.

Dawarich : une timeline Google Maps auto-hébergée

Dawarich est distribué sous licence AGPL-3.0 et s’exécute depuis un fichier Docker Compose. Une installation fonctionnelle comprend quatre conteneurs : l’application Rails, un worker Sidekiq pour les tâches en arrière-plan, PostgreSQL et Redis. L’application écoute sur le port 3000. Les sources d’importation incluent Google Maps Timeline, OwnTracks, Strava, Immich, les fichiers GPX et GeoJSON, ainsi que les données EXIF de vos photos. Cette liste d’importation en fait une timeline plutôt qu’une carte en temps réel, car elle peut intégrer un historique antérieur au serveur.

L’ingestion utilise un endpoint HTTP qui transmet une clé API disponible dans la page de votre compte. OwnTracks envoie ses données vers /api/v1/owntracks/points?api_key=... et Overland vers /api/v1/overland/batches?api_key=.... GPSLogger réutilise l’endpoint OwnTracks.

Vérifiez où cette clé est transmise. Elle se trouve dans la chaîne de requête, et le format de journalisation par défaut de nginx écrit la ligne complète de la requête. La clé se retrouve donc en clair dans /var/log/nginx/access.log pour chaque point. Considérez ce journal comme un secret, faites tourner la clé si vous envoyez les journaux vers un système centralisé et ne collez jamais une URL fonctionnelle dans un fil de support.

Pour le fichier Compose lui-même, les volumes et la politique de redémarrage, consultez les mécanismes des conteneurs pour exécuter Compose sur un VPS. Cette page s’arrête au stade de la décision.

Home Assistant : efficace pour la présence, inadapté à l’historique

Si vous utilisez déjà Home Assistant, vous disposez déjà du suivi des appareils. L’application compagnon transmet la position, et l’intégration OwnTracks fournit une URL de webhook ainsi qu’une clé de chiffrement à saisir dans l’application. Une fois MQTT configuré, cette intégration écoute les messages MQTT au lieu des requêtes HTTP.

La limite concerne la conservation. Le recorder de Home Assistant conserve les données pendant purge_keep_days: 10 par défaut, et la purge automatique s’exécute chaque nuit à 04:12, heure locale, pour empêcher la base de données de grossir sans limite. Cette valeur par défaut convient à une base de données de domotique, mais pas à une archive de positions. Home Assistant répond à la question « qui est à la maison ? ». Il ne répondra pas à la question « où étais-je le 14 mars ? » si vous n’augmentez pas purge_keep_days avant la purge de cette journée. Cela ferait grossir toute la base de données du recorder. Vous pouvez aussi envoyer le même flux vers un système qui le conserve.

Suivi continu ou partage ponctuel ?

Le suivi continu signifie que l’application publie des données toute la journée, que vous soyez en déplacement ou non, et que l’archive qu’elle constitue est l’objectif principal. Le partage ponctuel signifie que les utilisateurs se suivent pendant un trajet, et que l’archive n’est qu’un effet secondaire dont personne n’a besoin. Le même logiciel peut servir aux deux usages, avec des réglages différents.

Pour un suivi continu, privilégiez les rapports déclenchés par le déplacement plutôt qu’une minuterie courte, stockez la base de données sur un support réellement sauvegardé et définissez la durée de conservation dès le premier jour, pas lorsque le disque est plein. Pour un partage ponctuel, augmentez la fréquence des rapports uniquement pendant la période utile, puis repassez le téléphone en mode basse consommation. OwnTracks propose ce réglage directement dans l’application, et Traccar Client fait de même avec ses champs de distance et d’intervalle.

Si vous voulez un lien de partage valable deux heures pour un seul trajet, consultez les notes de version du serveur choisi avant de vous engager. C’est la fonctionnalité qui change le plus d’une version à l’autre et le point le plus faible de toutes les options présentées ici.

Faut-il vraiment un broker MQTT ?

Commencez sans broker. Le mode HTTP nécessite une URL, un mot de passe et TLS (Transport Layer Security), et tous les serveurs cités plus haut l’acceptent. Un broker devient utile lorsque plusieurs éléments doivent recevoir le même flux au même moment, par exemple Home Assistant qui réagit à une zone pendant qu’un enregistreur écrit l’historique, ou lorsque les membres d’une même famille doivent se voir entre eux.

MQTT est un protocole de publication et d’abonnement, et Mosquitto est le broker habituel. Il écoute sur 1883 en clair et sur 8883 avec TLS ; utilisez uniquement 8883. Le contrôle d’accès s’applique à chaque topic. Un compte peut donc être autorisé à publier sur owntracks/alice/phone sans pouvoir lire quoi que ce soit d’autre. C’est le véritable intérêt de MQTT dans un environnement familial : le broker contrôle qui voit qui, en dessous de l’application. Un bug applicatif ne peut donc pas élargir cet accès.

En contrepartie, vous ajoutez un service avec son propre certificat, sa propre liste d’utilisateurs et son propre mode de panne. Lorsqu’un broker cesse d’accepter les connexions, le résultat ressemble exactement à celui d’un téléphone sans signal. Ni l’un ni l’autre ne vous indique la cause.

Combien de lignes de position un téléphone va-t-il produire ?

Les chiffres ci-dessous sont des calculs, pas des mesures. Ils supposent un intervalle de remontée fixe, une ligne par rapport et aucune autre donnée.

[
  {
    "label": "Every 30 seconds",
    "points_30d": "86,400",
    "points_365d": "1,051,200"
  },
  {
    "label": "Every 60 seconds",
    "points_30d": "43,200",
    "points_365d": "525,600"
  },
  {
    "label": "Every 5 minutes",
    "points_30d": "8,640",
    "points_365d": "105,120"
  },
  {
    "label": "Every 15 minutes",
    "points_30d": "2,880",
    "points_365d": "35,040"
  }
]

Un téléphone qui transmet une position chaque minute écrit 43,200 lignes par mois et 525,600 lignes par an. Avec un intervalle de quinze minutes, l’année ne représente plus que 35,040 lignes. Les applications réelles sont moins prévisibles, car elles transmettent aussi une position lors d’un déplacement et cessent d’en envoyer lorsque le téléphone est immobile. Considérez donc la première valeur comme un plafond, et non comme une prévision.

Un demi-million de lignes par an reste peu pour PostgreSQL. Le premier coût important concerne leur affichage : une carte chargée de rendre une année de positions à leur résolution complète ralentit le navigateur bien avant que la base de données ne le remarque. C’est pourquoi ces applications regroupent l’historique en trajets et en lieux. Mesurez le nombre réel sur votre propre serveur au lieu de vous fier à un chiffre trouvé dans un article de blog :

SELECT pg_size_pretty(pg_total_relation_size('tc_positions'));

Il s’agit de la table positions de Traccar dans PostgreSQL. Après un mois d’utilisation normale, exécutez l’équivalent pour le serveur que vous aurez choisi, puis multipliez le résultat par douze. Aucun de ces serveurs ne supprime automatiquement les anciennes positions. Ils conservent tout ce que vous leur envoyez jusqu’à ce que vous le supprimiez. Définissez donc une règle de rétention tant que la table reste petite, et vérifiez que la sauvegarde couvre bien la base de données, et pas uniquement la configuration : un historique de localisation ne peut pas être reconstitué à partir d’une autre source.

Le coût en batterie dépend de votre téléphone, pas de votre serveur

C’est le seul aspect que l’auto-hébergement ne change pas. Le système d’exploitation décide quand le GPS se réactive, combien de temps une application en arrière-plan peut s’exécuter et si elle continuera à fonctionner pendant la nuit. La gestion de l’énergie d’Android suspend fortement les tâches en arrière-plan, tandis qu’iOS transmet les changements de position importants plutôt qu’un flux continu. Votre serveur n’a aucun contrôle sur ces décisions. Un intervalle de transmission plus court dans l’application est donc une demande, et le téléphone y répond comme il le peut.

Les réglages que vous contrôlez se trouvent sur le téléphone : accordez l’autorisation d’utiliser la position en arrière-plan en permanence, excluez l’application de suivi de l’optimisation de la batterie et adaptez le mode de transmission à la journée. Utiliser le mode déplacement toute la semaine suffit à retrouver un téléphone à plat à 16 heures.

Côté serveur, le symptôme est une rafale de lignes contenant d’anciens horodatages. OwnTracks et Traccar Client, lorsque la mise en tampon hors ligne est activée, conservent les points hors ligne puis les envoient dès que le réseau revient. L’heure d’écriture et l’heure de la position sont donc différentes. Lorsque votre carte trace une ligne droite à travers une ville, cela indique une interruption des positions, pas une route.

Côté serveur : TLS et chemin d’ingestion authentifié

Le téléphone a besoin d’un nom d’hôte qu’il peut résoudre et d’un certificat auquel il fait confiance. Un certificat autosigné est la raison la plus fréquente pour laquelle une installation récente ne reçoit absolument rien : l’application échoue lors de la négociation TLS et abandonne, tandis que le journal du serveur reste vide parce que la requête n’a jamais abouti. Un journal vide ressemble à un problème du téléphone, mais ce n’en est pas un.

Deux solutions propres sont possibles. Terminez TLS dans nginx avec un certificat valide, par exemple un certificat Let’s Encrypt devant nginx, et n’ouvrez que le port 443. Ou n’exposez aucun port entrant avec un tunnel Cloudflare afin que rien n’écoute sur l’IP publique, ce qui convient à Dawarich et OwnTracks, car leur ingestion utilise du HTTP standard.

Une limite concerne la solution avec tunnel. Le protocole OsmAnd de Traccar utilise HTTP : un client de téléphone peut donc passer par un reverse proxy ou un tunnel sans difficulté. Les protocoles binaires utilisés par les équipements GPS dédiés sont du TCP brut sur leurs propres ports. Ils nécessitent un port réellement ouvert, à la fois dans le firewall du VPS et dans le firewall réseau distinct de votre fournisseur. Chez la plupart des hébergeurs, ce dernier se configure dans un autre panneau de contrôle.

Une fois le service accessible, vérifiez le chemin avec une seule requête au lieu de déduire le problème à partir de l’application :

curl -si -u alice:secret -H 'Content-Type: application/json' \
  -d '{"_type":"location","lat":51.5,"lon":-0.12,"tst":1788480000}' \
  https://track.example.com/pub | head -1

Un endpoint fonctionnel renvoie un statut 2xx. Un 401 signifie que le serveur a rejeté les identifiants ou ne les a jamais reçus, tandis que le transport fonctionne correctement. Une erreur curl avant toute ligne de statut indique un problème de DNS ou de TLS. Corrigez donc le certificat avant de modifier l’application.

Un point d’ingestion ouvert révèle votre position

Une URL d’ingestion sans authentification transmet votre position à quiconque la découvre, et cela arrive.

• Toute personne qui possède l’URL peut ajouter des points à votre historique. Les faux points sont difficiles à repérer et fastidieux à supprimer.
• Une URL n’est pas un secret. Elle se trouve dans les paramètres de l’application du téléphone, dans le journal d’accès de votre reverse proxy, dans l’historique du navigateur si vous l’avez testée dans un onglet, et dans toute capture d’écran jointe à une demande d’aide.
• Un endpoint qui répond aux requêtes GET non authentifiées transmettra votre dernière position à un crawler qui aura deviné le chemin.
• Le hostname est public quoi que vous fassiez. Un certificat nouvellement émis apparaît dans les journaux de certificate transparency en quelques minutes. Une adresse que vous n’avez jamais publiée reste donc détectable.

Utilisez HTTP Basic sur TLS pour OwnTracks, la clé d’API pour Dawarich, et le modèle de comptes de Traccar avec un identifiant d’appareil unique. Placez l’interface d’administration derrière la même authentification que le chemin d’ingestion, car c’est dans cette interface que l’intégralité de l’historique est lisible. Vérifiez ensuite qui essaie de se connecter après la première semaine :

sudo awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20

Les adresses IP mobiles de votre téléphone devraient dominer cette liste. Toute autre adresse avec un nombre élevé de requêtes mérite d’être examinée. Ajoutez une limite de débit sur l’emplacement d’ingestion dans nginx : cela ne coûte rien.

Un tracker peut aussi tomber en panne silencieusement. Le conteneur s’arrête, le téléphone continue de mettre les données en tampon, et vous ne vous en rendez compte que des semaines plus tard, lorsqu’un trajet manque. Configurez un health check du conteneur ou un OnFailure= systemd vers votre propre serveur ntfy, afin que ce silence vous parvienne sur le même téléphone que celui qui envoie les données.

Qui peut voir la trace, et comment cet accès est appliqué

Traccar applique les contrôles d’accès avec les utilisateurs et les permissions sur les appareils : un compte voit les appareils qu’un administrateur lui a attribués, et l’API utilise une session ou un token. Avec MQTT, OwnTracks applique ces contrôles dans le broker au moyen d’ACL sur les topics. C’est le mécanisme le plus robuste ici, car un compte qui ne peut pas s’abonner à un topic ne peut pas le lire, quelles que soient les actions de l’application. OwnTracks over HTTP ne possède pas de couche équivalente. Tout ce qui se trouve derrière l’endpoint constitue donc l’intégralité du contrôle d’accès. Dawarich est conçu pour qu’une personne consulte son propre historique. Lorsque plusieurs personnes doivent suivre leur position en temps réel, Traccar ou un broker est donc mieux adapté.

Le suivi familial relève aussi du consentement, pas seulement de la technique. Toute personne dont le téléphone publie des données doit savoir qu’il le fait et comment arrêter cette publication. Un tracker qu’une personne ne peut pas désactiver n’est pas une fonctionnalité familiale.

Ce que l’auto-hébergement ne résout pas

• Le système d’exploitation du téléphone décide quand le GPS se réactive. La décharge de la batterie et les interruptions dans la trace sont donc principalement liées au téléphone, pas au serveur.
• Google a modifié l’exportation des données Timeline. Consultez la documentation actuelle de Dawarich sur l’importation avant de planifier une migration, car le fichier fourni aujourd’hui par Google n’est pas celui que les utilisateurs importaient il y a deux ans.
• Votre endpoint voit l’adresse IP mobile à chaque requête, comme tous les réseaux intermédiaires. L’auto-hébergement modifie l’entité qui conserve cet enregistrement. Il ne le supprime pas.
• Un historique de localisation est irremplaçable. Sauvegardez la base de données, effectuez une restauration pour vérifier que la sauvegarde fonctionne, puis conservez la copie chiffrée, car il s’agit du fichier le plus sensible du serveur.

FAQ

Quelle application auto-hébergée remplace Google Maps Timeline ?

Dawarich. Cette application est conçue comme une alternative auto-hébergeable à Google Timeline. Elle importe un export Google Maps Timeline ainsi que des données OwnTracks, Strava, Immich, GPX et GeoJSON, et les métadonnées EXIF des photos. Elle présente l’historique sous forme de lieux et de trajets, plutôt que sous la forme d’une carte en temps réel. Traccar peut stocker les mêmes points, mais son interface est une console de gestion de flotte et ses rapports portent sur la flotte. Consultez la documentation d’importation de Dawarich pour connaître le format d’export attendu avant de planifier la migration, car le format d’export de Google a changé.

Puis-je utiliser OwnTracks sans broker MQTT ?

Oui. Configurez l’application en mode HTTP et indiquez-lui une URL de la forme http[s]://[user[:password]@]host[:port]/path, qui correspond à /pub pour OwnTracks Recorder. Elle envoie le même payload JSON, authentifié avec HTTP Basic, et OwnTracks recommande fortement le schéma https://. Ajoutez un broker plus tard, lorsque deux services doivent utiliser le même flux simultanément, ou lorsque vous avez besoin d’un contrôle d’accès par topic afin que le broker détermine qui peut voir qui.

Quel espace de stockage faut-il prévoir pour un an d’historique de localisation ?

Raisonnez en nombre de lignes plutôt qu’en gigaoctets. Un rapport par minute représente 525,600 lignes par an et par téléphone, tandis qu’un rapport toutes les quinze minutes en représente 35,040. Dans les deux cas, le volume reste faible pour PostgreSQL. La limite pratique vient du navigateur, qui doit dessiner une année de points sur une seule carte. C’est pourquoi ces applications agrègent les données. Mesurez votre propre table après un mois avec pg_total_relation_size, puis multipliez le résultat par douze.

Pourquoi mon historique de localisation comporte-t-il des interruptions ?

Le système d’exploitation du téléphone décide quand activer le GPS et quand arrêter une application en arrière-plan. La plupart des interruptions commencent donc à ce niveau. Accordez à l’application l’autorisation d’accéder à la localisation en arrière-plan en permanence, excluez-la de l’optimisation de la batterie et vérifiez le mode de rapport. Dans OwnTracks sur iOS, le mode Move publie une position tous les locatorDisplacement mètres ou toutes les locatorInterval secondes. Les valeurs par défaut sont de 100 mètres et 300 secondes. Sur Android, l’application demande par défaut une position toutes les 10 secondes. Dans les deux cas, la consommation de batterie est comparable à celle d’une application de navigation. Si plusieurs lignes arrivent tardivement par lots avec d’anciens timestamps, cela signifie que le buffer hors ligne est en cours de vidage. Les positions ont donc bien été relevées, mais leur envoi a été retardé.

Une URL secrète suffit-elle à protéger un endpoint de localisation ?

Non. Un endpoint d’ingestion sans authentification permet à toute personne qui connaît l’URL d’ajouter de faux points à votre historique. Une URL n’est pas un secret : elle se trouve dans les paramètres de l’application, dans le journal d’accès de votre reverse proxy, dans l’historique de votre navigateur et dans toutes les captures d’écran que vous partagez. Le hostname est également découvrable, car un nouveau certificat apparaît dans les journaux de certificate transparency peu après son émission. Utilisez HTTP Basic sur TLS ou une clé d’API, appliquez une limite de débit au chemin d’ingestion et protégez l’interface d’administration avec la même authentification.