Le problème avant le NTP
Avant qu’Internet n’apprenne à donner l’heure, chaque ordinateur était livré à lui-même. Un serveur à New York pouvait avancer de trois minutes en une semaine. Une réplique de base de données à San Francisco pouvait retarder de deux minutes. Un terminal de trading à Chicago pouvait être en désaccord avec les deux. Personne ne s’en apercevait quand les machines travaillaient de manière isolée, mais dès qu’elles ont commencé à communiquer entre elles, le chaos est devenu impossible à ignorer.
Le temps compte plus que la plupart des gens ne le pensent. Les marchés financiers doivent savoir quelle transaction est arrivée en premier. Lorsque deux serveurs de bases de données répliquent des données entre eux, ils utilisent des horodatages pour décider quelle écriture l’emporte. Les fichiers journaux de différentes machines doivent être fusionnés par ordre chronologique pour que les ingénieurs puissent diagnostiquer les pannes. Les systèmes de contrôle aérien, les distributeurs de médicaments hospitaliers, les synchroniseurs de réseaux électriques, les autorités de certification qui émettent les clés de chiffrement derrière chaque connexion HTTPS — tous dépendent d’horloges qui s’accordent.
Au début des années 1980, Internet n’était encore qu’un ensemble de réseaux universitaires et gouvernementaux, mais le problème était déjà aigu. Les machines synchronisaient leurs horloges en appelant des services d’heure par ligne modem, un processus lent, coûteux et terriblement imprécis. Certains administrateurs réglaient les horloges à la main, en jetant un coup d’œil à leur montre et en tapant l’heure. L’erreur pouvait être de quelques secondes, de quelques minutes, voire pire. Ce dont le réseau en pleine croissance avait besoin, c’était un protocole — un moyen automatique et auto-correcteur pour que chaque machine sur Internet s’accorde sur l’heure.
David Mills et la naissance du NTP
La personne qui a résolu ce problème s’appelait David L. Mills, professeur d’informatique à l’université du Delaware. Mills réfléchissait à la synchronisation horaire en réseau depuis la fin des années 1970, et en 1985 il publia le RFC 958, la première spécification formelle du Network Time Protocol. Ce n’était pas sa première tentative — il avait conçu des protocoles antérieurs appelés DCNET et Internet Clock Service — mais c’est le NTP qui s’est imposé.
Le RFC 958 décrivait une architecture à la fois élégante et pragmatique. Plutôt que d’exiger de chaque ordinateur qu’il accède directement à une horloge atomique, le NTP organisait les sources de temps en une hiérarchie. Il utilisait des mathématiques astucieuses pour compenser les délais réseau imprévisibles. Et il était conçu pour être robuste : si une source de temps tombait en panne, les clients basculaient automatiquement vers une autre. Le protocole pouvait synchroniser des horloges à travers l’Internet chaotique et instable des années 1980 avec une précision de l’ordre de quelques dizaines de millisecondes — un exploit qui semblait presque magique à l’époque.
Mills a maintenu et fait évoluer le NTP pendant près de trois décennies, quasiment seul. Il a écrit l’implémentation de référence. Il répondait aux questions sur les listes de diffusion. Il a publié des RFC mis à jour au fil de la maturation du protocole à travers les versions 2, 3 et 4. Au moment de sa retraite, le NTP était devenu l’un des plus anciens protocoles Internet encore en usage quotidien, plus ancien que HTTP, plus ancien que SSL, plus ancien que le DNS tel que nous le connaissons aujourd’hui. Mills est décédé en janvier 2024 à l’âge de 85 ans, laissant derrière lui un protocole qui synchronise silencieusement des milliards d’appareils chaque jour. La plupart des gens qui dépendent de son travail n’ont jamais entendu son nom.
Comment fonctionne le système de strates
Le NTP organise les sources de temps en couches appelées strates. Au sommet se trouve la Strate 0 : le matériel de chronométrage proprement dit. Il s’agit d’horloges atomiques au césium, de masers à hydrogène, de récepteurs GPS et d’autres instruments de précision qui produisent un signal horaire exact à la milliardième de seconde près. Il est impossible de se connecter à un appareil de Strate 0 par le réseau : ce sont des instruments physiques, souvent fixés sur des baies dans des laboratoires nationaux ou montés sur des satellites en orbite à 20 200 kilomètres au-dessus de la Terre.
Les serveurs de Strate 1 sont des ordinateurs directement connectés au matériel de Strate 0, généralement par un câble série, une antenne GPS dédiée sur le toit, ou un lien direct vers une horloge au césium dans le couloir. Ces machines lisent le signal de temps atomique et le mettent à disposition du réseau. Il existe environ un millier de serveurs publics de Strate 1 dans le monde, exploités par des laboratoires nationaux de métrologie, des universités et des entreprises technologiques.
Les serveurs de Strate 2 se synchronisent sur la Strate 1. Ceux de Strate 3 sur la Strate 2. Chaque couche ajoute une petite quantité d’erreur et un léger délai. La hiérarchie se poursuit jusqu’à la Strate 15. La Strate 16 est une valeur spéciale signifiant « non synchronisé » : un serveur en Strate 16 signale qu’il ne dispose pas de source de temps fiable et ne doit pas être consulté.
Le génie de cette architecture en couches, c’est la répartition de charge. Des milliards d’appareils connectés à Internet ont besoin d’une heure précise, mais il n’existe que quelques centaines d’horloges atomiques. Si tous les smartphones de la planète tentaient de se synchroniser directement sur une fontaine atomique au césium du National Institute of Standards and Technology à Boulder, dans le Colorado, le système s’effondrerait instantanément. À la place, votre téléphone se synchronise sur un serveur de Strate 2 ou 3, qui se synchronise sur un serveur de Strate 1, qui se synchronise sur l’horloge atomique. La charge se répartit entre des millions de serveurs intermédiaires, et les horloges atomiques restent imperturbables.
Les mathématiques astucieuses du NTP
Le défi fondamental de la synchronisation horaire en réseau, c’est qu’on ne peut pas simplement demander à un serveur « quelle heure est-il ? » et utiliser la réponse. La question met du temps à traverser le réseau. La réponse met du temps à revenir. Et ces deux temps de trajet ne sont pas nécessairement égaux — un paquet peut mettre 20 millisecondes pour traverser l’Atlantique vers l’ouest et 35 millisecondes pour revenir vers l’est, selon le routage, la congestion et les caprices du moment.
Le NTP résout ce problème par un échange de quatre horodatages. Le client enregistre l’heure à laquelle il envoie sa requête (T1). Le serveur enregistre l’heure à laquelle il la reçoit (T2). Le serveur enregistre l’heure à laquelle il envoie sa réponse (T3). Et le client enregistre l’heure à laquelle il reçoit cette réponse (T4). À partir de ces quatre valeurs, le NTP calcule deux grandeurs essentielles.
Le délai aller-retour est (T4 - T1) - (T3 - T2). Il indique combien de temps le paquet a passé en transit, hors temps de traitement par le serveur. Le décalage d’horloge est ((T2 - T1) + (T3 - T4)) / 2. C’est la différence estimée entre l’horloge du client et celle du serveur, en supposant que le délai réseau est à peu près symétrique dans les deux sens.
Cette hypothèse de symétrie n’est pas toujours vérifiée, et le NTP le sait. Le protocole ne se fie pas à un seul échange. Il interroge plusieurs serveurs, collecte de nombreux échantillons au fil du temps, applique des filtres statistiques pour écarter les valeurs aberrantes, et utilise des algorithmes portant des noms comme l’« algorithme de sélection d’horloge » et l’« algorithme de regroupement d’horloge » pour choisir les meilleures sources et les combiner. Le résultat, sur l’Internet public avec toute son imprévisibilité, est une synchronisation précise à quelques millisecondes près. Sur un réseau local, où les délais sont courts et stables, le NTP atteint couramment une précision inférieure à 100 microsecondes.
D’où vient réellement l’heure
À la base même de la pyramide du chronométrage se trouvent les laboratoires nationaux de métrologie du monde entier. Le National Institute of Standards and Technology (NIST) à Boulder, dans le Colorado, exploite une batterie de fontaines atomiques au césium — des dispositifs qui propulsent des nuages d’atomes de césium vers le haut à travers une cavité micro-ondes et mesurent les transitions d’état quantique des atomes lorsqu’ils retombent. La fréquence d’oscillation du césium 133, exactement 9 192 631 770 cycles par seconde, définit la seconde du SI depuis 1967.
Le Physikalisch-Technische Bundesanstalt (PTB) allemand à Braunschweig, le National Physical Laboratory (NPL) britannique à Teddington, le LNE-SYRTE français à Paris et environ 80 autres laboratoires nationaux à travers le monde entretiennent leurs propres horloges atomiques. Chaque laboratoire produit sa propre réalisation de la seconde, et ces réalisations ne coïncident pas parfaitement. Une horloge au césium à Boulder peut différer de quelques nanosecondes par rapport à une horloge à Braunschweig sur un mois.
C’est là qu’intervient le Bureau international des poids et mesures (BIPM) à Paris. Le BIPM ne possède pas d’horloge. Il collecte les données de synchronisation d’environ 450 horloges atomiques réparties dans quelque 80 laboratoires à travers le monde, applique un algorithme de moyenne pondérée et publie une échelle de temps sur papier appelée Temps universel coordonné, ou UTC. Ce processus de moyennage s’effectue après coup — le BIPM publie les corrections des semaines plus tard — si bien que l’UTC n’est pas disponible en temps réel. Ce à quoi vous vous synchronisez réellement via le NTP, c’est l’approximation en temps réel de chaque laboratoire, appelée UTC(NIST), UTC(PTB) ou similaire. Le rôle du BIPM est d’empêcher toutes ces approximations de diverger les unes des autres.
Il y a ensuite les satellites GPS. Chacun des 31 satellites GPS opérationnels embarque plusieurs horloges atomiques — au rubidium et au césium — et diffuse des signaux horaires dans son message de navigation. L’heure GPS n’est pas identique à l’UTC (elles ont divergé en 1980 et l’heure GPS n’inclut pas les secondes intercalaires), mais le décalage est transmis dans le message de navigation, de sorte qu’un récepteur GPS peut calculer l’UTC. De nombreux serveurs NTP de Strate 1 utilisent le GPS comme horloge de référence, car un récepteur à 50 dollars et une antenne sur le toit peuvent fournir une heure précise à 10 nanosecondes près, bien moins cher que l’achat d’une horloge au césium.
Le NTP à grande échelle
Le NTP Pool Project, hébergé sur pool.ntp.org, est l’une des grandes réussites de l’infrastructure bénévole d’Internet. Lancé en 2003 par Adrian von Bidder, le pool rassemble des milliers de serveurs NTP exploités par des volontaires à travers le monde. Lorsque votre ordinateur est configuré pour utiliser pool.ntp.org, le système DNS renvoie à chaque fois un ensemble différent d’adresses de serveurs, répartissant la charge sur l’ensemble du pool. En 2025, le pool dessert environ 50 millions de clients par seconde et couvre les besoins de synchronisation de la plupart des distributions Linux, de nombreux appareils IoT et d’innombrables autres systèmes qui utilisent pool.ntp.org comme source NTP par défaut.
Les grandes entreprises technologiques gèrent leur propre infrastructure horaire à une échelle considérable. Google exploite une flotte de serveurs synchronisés sur des horloges atomiques et des récepteurs GPS dans ses centres de données. Le service de temps de Google est accessible au public à l’adresse time.google.com et met en œuvre une variante intéressante : au lieu d’insérer les secondes intercalaires de manière abrupte, Google utilise une technique appelée « leap smear », étalant progressivement la seconde supplémentaire sur une fenêtre de 24 heures. Cela évite les plantages logiciels que les insertions brutales de secondes intercalaires ont historiquement provoqués, mais signifie que pendant un événement de leap smear, l’heure de Google s’écarte délibérément de l’UTC d’une demi-seconde au maximum.
Meta (anciennement Facebook) gère un service de temps interne similaire et a publié des articles d’ingénierie détaillés sur son utilisation du Precision Time Protocol (PTP) au sein de ses centres de données, superposé à des horloges maîtresses disciplinées par GPS. Amazon exploite l’Amazon Time Sync Service, disponible pour toutes les instances AWS. Cloudflare propose un service NTP public et milite en faveur de Roughtime, un protocole développé par Google qui ajoute une preuve cryptographique aux réponses horaires afin que les clients puissent vérifier qu’ils ne sont pas trompés.
Quand le NTP déraille
Le 30 juin 2012, une seconde intercalaire a été insérée dans l’UTC à minuit. La seconde supplémentaire — 23:59:60 — a déclenché un bogue dans le code de chronométrage du noyau Linux, provoquant l’emballement du minuteur haute résolution du système. Les processus qui dépendaient de ces minuteurs ont soudainement consommé 100 pour cent de leurs cœurs de processeur, tournant en boucles serrées. Reddit est tombé. Mozilla est tombé. Gawker est tombé. Le système d’enregistrement de Qantas Airlines s’est bloqué, laissant des passagers en plan. StumbleUpon, FourSquare, Yelp et LinkedIn ont tous signalé des perturbations. La solution consistait à redémarrer les systèmes affectés ou à régler l’horloge manuellement, ce qui était ironique puisque le problème avait commencé par une tentative de maintenir les horloges à l’heure.
L’usurpation de signal GPS représente une menace plus insidieuse. Les signaux GPS arrivent avec une puissance extrêmement faible — environ 10^-16 watts à la surface de la Terre — et peuvent être écrasés par un émetteur relativement peu coûteux diffusant de faux signaux. Un signal GPS falsifié peut fournir une heure erronée à n’importe quel serveur NTP de Strate 1 utilisant le GPS comme référence. En 2013, des chercheurs de l’université du Texas à Austin ont démontré qu’ils pouvaient usurper un récepteur GPS à un kilomètre de distance avec un équipement coûtant environ 3 000 dollars, décalant progressivement l’heure rapportée sans déclencher la moindre alerte.
En 2016, Cloudflare a connu un incident largement médiatisé au cours duquel certains de ses serveurs ont brièvement renvoyé des dates de 2026 ou 1970 aux clients en raison d’un bogue dans la gestion du NTP. Des défaillances plus subtiles se produisent en permanence. Des serveurs NTP mal configurés qui s’annoncent comme Strate 1 alors qu’ils fonctionnent en roue libre provoquent des imprécisions en cascade chez tous les clients qui leur font confiance. Les pare-feu qui bloquent le trafic NTP laissent les machines dériver silencieusement. Les machines virtuelles dans les environnements cloud sont connues pour leur dérive d’horloge, car l’ordonnancement CPU de l’hyperviseur introduit des délais imprévisibles dans le chronométrage du système d’exploitation invité.
Ces modes de défaillance expliquent pourquoi l’authentification NTP est importante. Le protocole NTP d’origine ne permettait pas à un client de vérifier qu’une réponse horaire provenait bien du serveur qu’elle prétendait être. Un attaquant sur le chemin réseau pouvait altérer les réponses en transit. Network Time Security (NTS), spécifié dans le RFC 8915 et publié en 2020, ajoute une authentification basée sur TLS au NTP. L’adoption est lente — la majeure partie du trafic NTP sur Internet reste non authentifié — mais les principaux fournisseurs comme Cloudflare prennent désormais en charge NTS, et la tendance va vers une adoption généralisée.
Heure GPS et NTP
Votre smartphone n’utilise presque certainement pas le NTP comme source horaire principale. Il utilise plutôt l’heure diffusée par le réseau cellulaire, qui est elle-même dérivée du GPS. Les satellites GPS embarquent des horloges atomiques et diffusent l’heure courante dans chaque signal de navigation. Le récepteur de votre téléphone, en plus de calculer votre latitude et votre longitude, extrait l’heure des signaux satellites et l’utilise pour régler l’horloge du téléphone.
L’heure GPS et l’UTC ne sont pas la même chose. Lors du lancement du GPS en 1980, il était synchronisé sur l’UTC. Mais l’UTC insère occasionnellement des secondes intercalaires pour rester aligné sur le ralentissement de la rotation terrestre, et le GPS ne le fait pas. En 2025, l’heure GPS est en avance de 18 secondes sur l’UTC. Le message de navigation GPS inclut le décalage en cours, de sorte que les récepteurs peuvent convertir entre les deux, mais la distinction est importante pour les ingénieurs qui travaillent avec des données GPS brutes.
Les smartphones modernes utilisent une approche hybride. Le signal horaire GPS ou cellulaire fournit une synchronisation grossière, généralement précise à quelques dizaines de nanosecondes près. Mais la réception GPS est intermittente — le téléphone peut se trouver à l’intérieur, dans le métro ou en mode avion. Le NTP comble les lacunes. Apple, Google et la plupart des fabricants de téléphones configurent leurs appareils pour qu’ils interrogent également des serveurs NTP (Apple utilise time.apple.com, les appareils Android utilisent time.android.com) afin de maintenir la précision lorsque les signaux satellites ne sont pas disponibles. Les deux systèmes se complètent : le GPS offre une précision absolue quand le ciel est visible, et le NTP assure une correction continue quand il ne l’est pas.
Le problème de l’an 2038
Le temps Unix, le système utilisé par la quasi-totalité des serveurs, téléphones et systèmes embarqués de la planète, compte le nombre de secondes écoulées depuis minuit UTC le 1er janvier 1970. Pendant des décennies, ce compteur a été stocké sous forme d’entier signé sur 32 bits, pouvant contenir des valeurs jusqu’à 2 147 483 647. Ce nombre de secondes après l’époque Unix correspond au 19 janvier 2038 à 03:14:07 UTC. Une seconde plus tard, le compteur déborde, et les systèmes utilisant encore des horodatages 32 bits interpréteront la date comme le 13 décembre 1901.
Le NTP a sa propre version de ce problème. Le format d’horodatage NTP utilise une valeur de 64 bits : 32 bits pour les secondes depuis le 1er janvier 1900 et 32 bits pour la fraction de seconde. Le champ des secondes déborde le 7 février 2036 — deux ans avant l’échéance Y2038 d’Unix. NTPv4, la version actuelle du protocole, gère cela en définissant des « numéros d’ère » qui permettent de désambigüer à quel cycle de 136 ans appartient un horodatage, mais les deux extrémités doivent implémenter correctement cette logique d’ères.
La plupart des serveurs, ordinateurs de bureau et téléphones modernes utilisent déjà des systèmes d’exploitation 64 bits avec des représentations temporelles sur 64 bits, qui ne déborderont pas avant environ 292 milliards d’années. Le danger réside dans la longue traîne des systèmes embarqués : contrôleurs industriels, systèmes d’automatisation de bâtiments, dispositifs médicaux, calculateurs automobiles et les milliards d’appareils IoT exécutant un micrologiciel 32 bits qui ne recevra peut-être jamais de mise à jour. Beaucoup de ces appareils utilisent le NTP pour régler leur horloge. Le travail discret et ingrat d’identification et de mise à niveau des systèmes vulnérables est en cours, mais contrairement au bogue de l’an 2000, il n’y a pas de date butoir unique pour focaliser l’attention du public. Le débordement NTP de 2036 et le débordement Unix de 2038 arriveront, que le dernier thermostat embarqué et le dernier contrôleur de feux de signalisation aient été corrigés ou non.
Quarante ans et ce n’est pas fini
Le NTP synchronise les horloges d’Internet depuis quatre décennies. Il a survécu à la transition d’ARPANET vers l’Internet commercial, du modem à la fibre optique, des mainframes aux smartphones. David Mills a conçu un protocole si robuste et si bien adapté à sa tâche qu’il a survécu à presque tout ce pour quoi il avait été initialement construit. Les machines ont changé, les réseaux ont changé, les débits ont été multipliés par un million, et le NTP fonctionne toujours.
Mais les exigences en matière de chronométrage grandissent. Les réseaux cellulaires 5G exigent une synchronisation précise à quelques dizaines de nanosecondes entre stations de base. Les véhicules autonomes ont besoin d’un chronométrage précis pour fusionner les données du lidar, du radar et des caméras. Les sociétés de trading haute fréquence mesurent la latence en nanosecondes et sont prêtes à payer des millions pour quelques microsecondes d’avance. Pour ces applications, la précision à la milliseconde du NTP ne suffit pas. Le Precision Time Protocol (PTP), défini dans la norme IEEE 1588, peut atteindre une synchronisation à la nanoseconde sur du matériel réseau dédié. Le PTP est déjà la norme dans les télécommunications, la radiodiffusion et les réseaux de trading financier.
Pourtant, pour les milliards d’appareils du quotidien — l’ordinateur portable sur votre bureau, le serveur dans un centre de données, le thermostat sur votre mur, la caméra de votre sonnette — le NTP reste l’épine dorsale invisible du temps synchronisé. C’est l’un de ces protocoles fondamentaux d’Internet qui fonctionne si bien que presque personne n’y pense. Chaque fois que vous jetez un œil à l’horloge de votre téléphone et qu’elle correspond à celle de votre ordinateur portable, qui correspond à l’horloge murale de l’aéroport, qui correspond à l’heure de départ affichée sur le panneau d’information des vols, vous voyez l’œuvre d’un protocole conçu par un professeur du Delaware il y a quatre décennies, fonctionnant sans se plaindre, maintenant le monde à l’heure.