Parmi tous les services qui tournent à la maison, il y en a un qu’on ne voit jamais, qu’on ne consulte jamais par un navigateur, mais dont absolument tout le reste dépend en silence : l’heure. Chez moi, c’est un petit Raspberry Pi 4 (4 Go de RAM, adresse fixe 192.168.1.3) qui s’en occupe, avec un récepteur GPS en USB comme référence de temps — et quelques garde-fous pour qu’il ne soit jamais, lui, la cause d’une coupure.
Pourquoi un serveur NTP maison plutôt qu’Internet
Par défaut, à peu près toutes mes machines pourraient se synchroniser directement sur des serveurs NTP publics, sur Internet. Ça marche très bien dans l’immense majorité des cas — mais ça veut dire que l’heure de tout mon réseau local dépend d’une connexion extérieure, avec la précision (et la latence) que ça implique. Avoir un serveur de temps local, lui-même synchronisé sur une référence très précise, change la donne sur deux points : la hiérarchie NTP du réseau local reste fonctionnelle même si la liaison Internet tombe, et la précision obtenue dépasse largement ce qu’offre un simple serveur public au bout de plusieurs sauts réseau.
Le GPS comme horloge atomique à 30 €
Le cœur du dispositif, c’est le petit récepteur GPS USB branché sur le Raspberry Pi. Ce qui en fait une référence de temps intéressante n’a rien à voir avec la localisation : chaque satellite GPS embarque une horloge atomique, et le système diffuse en permanence un signal de temps extrêmement précis, dérivé de ces horloges. Un récepteur GPS grand public, une fois qu’il a un nombre suffisant de satellites en vue, peut donc servir de référence de temps à la précision redoutable — pour une poignée d’euros, bien loin du prix d’une horloge atomique ou d’un récepteur GPS professionnel dédié au time-keeping.
Côté logiciel, le récepteur GPS est généralement piloté par gpsd, qui décode à la fois les trames NMEA (contenant la date et l’heure) et, si le module le supporte, le signal PPS (Pulse Per Second) — une impulsion électrique émise exactement au passage de chaque seconde, bien plus précise dans le temps que le simple message NMEA qui, lui, met quelques dizaines de millisecondes à être transmis et décodé. ntpd va ensuite piocher dans cette référence (via le pilote refclock adapté à gpsd) pour caler son horloge locale, puis la redistribue à tout le réseau local comme un serveur NTP de stratum 1 — c’est-à-dire directement relié à une référence de temps, sans dépendre d’un autre serveur NTP en amont.
Les garde-fous : un serveur de temps qui ne doit jamais planter
Un serveur NTP a une particularité : s’il tombe en panne silencieusement (figé, mais toujours alimenté), plus aucune machine du réseau ne reçoit de mise à jour d’heure, sans qu’il y ait forcément d’alerte visible ailleurs. Pour éviter ce scénario, plusieurs filets de sécurité se complètent sur ce Raspberry Pi :
- Le watchdog matériel du SoC (le Broadcom BCM2711 du Pi 4 intègre un circuit de surveillance dédié) : si le système d’exploitation ne vient plus régulièrement « rassurer » ce circuit, celui-ci force un redémarrage matériel complet, même si le noyau Linux est totalement figé.
- Un service de surveillance applicatif, qui vérifie en plus que les services qui comptent vraiment (ntpd, gpsd) répondent correctement, et pas seulement que le système répond au ping — un process qui tourne encore mais ne fait plus son travail doit être détecté comme une panne, pas comme un succès.
- Une alimentation et une carte SD/stockage dimensionnées pour la fiabilité, plutôt que pour la performance brute — sur un serveur censé tourner en continu depuis des mois sans surveillance active, c’est souvent la pièce la plus simple qui lâche en premier.
Résultat : une petite boîte, discrète sur le réseau, qui ne demande presque jamais d’intervention — et qui, le jour où elle en aurait vraiment besoin, est censée se redémarrer elle-même avant que quiconque ne s’en aperçoive.