Qu'est-ce que la Synchronisation NTP et Comment Ça Garde Tes Horloges à l'Heure ?

Diagramme de synchronisation NTP montrant des serveurs de temps et horloges interconnectés sur un réseau mondial

La synchronisation de l'heure NTP est le processus par lequel les ordinateurs, les serveurs et les équipements réseau définissent et maintiennent automatiquement des horloges précises en communiquant avec des serveurs de temps dédiés sur Internet ou un réseau local. Le Protocole de temps réseau (NTP) effectue ce travail depuis 1985, ce qui en fait l'un des plus anciens protocoles Internet encore largement utilisés. Sans lui, chaque appareil de ton réseau dériverait lentement vers sa propre version de « maintenant », causant des défaillances d'authentification, des journaux corrompus et des sessions de débogage très confuses.

Qu'est-ce que NTP et pourquoi existe-t-il

NTP signifie Protocole de temps réseau. Il a été conçu par le Dr David L. Mills de l'Université du Delaware et est défini dans RFC 5905. La version actuelle est NTPv4. Son unique fonction est de synchroniser les horloges des appareils en réseau à quelques millisecondes près du Temps universel coordonné (UTC).

Avant NTP, il n'existait pas de façon standardisée pour une machine de demander « quelle heure est-il ? » sur un réseau. Chaque système gardait l'heure indépendamment en utilisant son horloge matérielle interne, et ces horloges s'écartaient constamment les unes des autres. À mesure que les réseaux se sont développés, cela est devenu un vrai problème : les systèmes distribués ont besoin que tous leurs participants s'accordent sur l'heure, sinon des choses comme l'ordre des fichiers, les transactions de base de données et les jetons de sécurité s'effondrent.

Dérive d'horloge : pourquoi les ordinateurs se trompent sur l'heure

Chaque ordinateur dispose d'une horloge matérielle appelée Horloge en temps réel (RTC), qui est alimentée par une petite batterie sur la carte mère. Elle fonctionne grâce à un oscillateur à cristal de quartz. Le problème est que les oscillateurs à quartz ne sont pas parfaitement précis. Ils gagnent ou perdent quelques millisecondes par jour selon la température, l'âge et les variations de fabrication.

Cette petite dérive s'accumule avec le temps :

  • Une horloge qui dérive de 10 ms par jour est décalée de 300 ms après un mois.
  • Après un an, elle pourrait être décalée de 3,6 secondes ou plus.
  • Dans un cluster de 50 serveurs qui dérivent tous indépendamment, tu pourrais avoir des nœuds qui se désaccordent de plusieurs secondes à tout moment.

NTP résout ce problème en mesurant périodiquement l'écart entre l'horloge locale et une source de temps de référence, puis en ralentissant (en ajustant progressivement) la vitesse de l'horloge pour combler cet écart sans causer un saut soudain. Un saut soudain vers l'arrière dans le temps peut confondre les processus en cours d'exécution, donc NTP ajuste presque toujours l'horloge lentement plutôt que de la réinitialiser brutalement.

Ralentissement vs saut : NTP ralentit l'horloge (l'accélère ou la ralentit légèrement) quand le décalage est inférieur à 128 ms. Si le décalage est plus grand, il « saute » l'horloge, ce qui signifie qu'il définit l'heure directement. La plupart des démons NTP refuseront de sauter une horloge qui est décalée de plus de 1000 secondes sans intervention manuelle, comme vérification de cohérence.

Comment NTP synchronise réellement une horloge

Le protocole fonctionne par un échange requête-réponse sur le port UDP 123. Voici ce qui se passe dans un seul cycle de synchronisation :

  1. Ton client NTP envoie un paquet de requête à un serveur de temps. Le paquet inclut un horodatage du moment où il a été envoyé (T1).
  2. Le serveur reçoit le paquet et enregistre l'heure d'arrivée (T2).
  3. Le serveur envoie une réponse qui inclut T1, T2 et l'heure à laquelle il a envoyé la réponse (T3).
  4. Ton client enregistre le moment où la réponse est arrivée (T4).

Avec ces quatre horodatages, NTP calcule deux valeurs :

  • Délai aller-retour : (T4 - T1) - (T3 - T2)
  • Décalage d'horloge : ((T2 - T1) + (T3 - T4)) / 2

Le décalage indique au client à quel point son horloge est éloignée de celle du serveur. NTP ajuste ensuite l'horloge locale en fonction de ce décalage, en tenant compte de la latence du réseau. Sur plusieurs cycles de sondage (généralement tous les 64 à 1024 secondes), NTP construit un modèle statistique du délai du réseau et de la dérive de l'horloge, devenant progressivement plus précis.

Niveaux de stratum expliqués

NTP organise les sources de temps dans une hiérarchie appelée niveaux de stratum, numérotés de 0 à 15. Le numéro de stratum te dit à combien de sauts de distance un appareil se trouve d'une horloge de référence primaire.

Stratum Ce que c'est Précision typique
0 Appareil de référence primaire (récepteur GPS, horloge atomique, signal radio). Pas directement sur le réseau. Nanosecondes
1 Serveur directement connecté à un appareil de Stratum 0. C'est le sommet du réseau NTP. Microsecondes
2 Serveur synchronisé avec un serveur de Stratum 1. La plupart des serveurs NTP publics se trouvent ici. 1-10 ms
3 Serveur synchronisé avec un serveur de Stratum 2. Courant pour les serveurs NTP internes des entreprises. 10-50 ms
4-15 Clients et serveurs en aval supplémentaires. Se dégrade à chaque saut
16 Non synchronisé. Un appareil annonçant Stratum 16 n'a pas de source de temps valide. Inconnu / peu fiable

Une règle clé : un serveur s'annonce toujours à un niveau de stratum supérieur à sa source en amont. Si ton serveur NTP interne se synchronise avec un serveur public de Stratum 2, il devient un serveur de Stratum 3 pour tes clients. Cela empêche les références circulaires et garde la hiérarchie propre.

Serveurs de temps : d'où vient l'heure précise

L'infrastructure NTP publique la plus largement utilisée est le Projet NTP Pool, un pool de milliers de serveurs gérés par des bénévoles dans le monde entier. Quand tu configures un appareil pour utiliser pool.ntp.org , il est automatiquement acheminé vers un serveur géographiquement proche.

Autres serveurs de temps publics bien connus :

  • time.cloudflare.com (Cloudflare, utilise GPS + horloges atomiques)
  • time.google.com (Google, utilise des récepteurs GPS dans ses centres de données)
  • time.windows.com (Microsoft, utilisé par défaut par Windows)
  • time.apple.com (Apple, utilisé par macOS et iOS)
  • ntp.ubuntu.com (Ubuntu/Canonical)

Pour les environnements d'entreprise, la configuration recommandée est d'avoir un ou deux serveurs NTP internes synchronisés avec des sources publiques de Stratum 1 ou Stratum 2, puis d'avoir tous les appareils internes synchronisés avec ces serveurs internes. Cela réduit la charge sur les pools publics et maintient tous tes appareils sur une référence interne cohérente.

NTP vs SNTP vs PTP : quelle est la différence

Tu verras occasionnellement ces trois termes utilisés indifféremment, mais ce ne sont pas la même chose :

  • NTP (Protocole de temps réseau) : Le protocole complet. Utilise un algorithme sophistiqué avec filtrage, pondération et sondage de plusieurs serveurs. Atteint une précision de 1-10 ms sur Internet.
  • SNTP (NTP simple) : Un sous-ensemble simplifié et sans état de NTP. Utilise le même format de paquet mais ignore les algorithmes avancés de discipline d'horloge. Suffisant pour les appareils des utilisateurs finaux qui ont juste besoin d'une heure « assez proche ». La plupart des appareils IoT utilisent SNTP.
  • PTP (Protocole de temps de précision, IEEE 1588) : Conçu pour les réseaux locaux où une précision inférieure à la microseconde est nécessaire, comme les systèmes de trading financier, l'automatisation industrielle et les réseaux de télécommunications. PTP utilise l'horodatage matériel au niveau de l'interface réseau, ce que NTP ne peut pas faire.

Pour la plupart des développeurs et administrateurs système, NTP est le bon choix. PTP n'est nécessaire que si tu as besoin d'une précision supérieure à celle que NTP peut fournir sur un LAN.

Exemples pratiques pour les développeurs et administrateurs système

Vérifier le statut NTP sur Linux

Sur les systèmes utilisant systemd-timesyncd (Ubuntu 16.04+, Debian 8+) :

timedatectl show-timesync --all

Sur les systèmes exécutant le démon ntpd complet :

ntpq -p

La sortie affiche chaque serveur configuré, son stratum, le délai aller-retour et le décalage actuel. Un astérisque (*) à côté d'un serveur signifie qu'il s'agit de la source actuellement sélectionnée.

Configurer les serveurs NTP sur Linux (chrony)

chrony est le client NTP recommandé sur les systèmes RHEL/CentOS/Fedora modernes et est également disponible sur Debian/Ubuntu. Modifie /etc/chrony.conf :

# Use the NTP Pool for your region
pool 2.pool.ntp.org iburst

# Or use a specific provider
server time.cloudflare.com iburst
server time.google.com iburst

# Allow clients on your local network to sync from this machine
allow 192.168.0.0/24

Vérifier la synchronisation horaire sur Windows

w32tm /query /status

Pourquoi cela importe spécifiquement pour les développeurs

Si tu travailles avec des jetons d'authentification, tu as presque certainement rencontré des défaillances liées au temps. Les jetons JWT utilisent les revendications iat (émis à) et exp (expiration) qui sont des horodatages Unix. Si l'horloge du serveur qui émet le jeton et celle du serveur qui le valide sont décalées de plus de quelques secondes, les jetons parfaitement valides sont rejetés. Tu peux en savoir plus sur le fonctionnement de ces revendications d'horodatage dans notre article sur les revendications d'expiration et d'émission JWT.

De même, les bases de données distribuées comme Cassandra, CockroachDB et Spanner s'appuient sur la précision de l'horloge pour la résolution des conflits et l'ordre des transactions. Spanner de Google, par exemple, utilise des récepteurs GPS et des horloges atomiques dans chaque centre de données précisément parce que NTP seul n'est pas assez précis pour ses garanties de cohérence.

La corrélation des journaux est un autre point douloureux courant. Si deux serveurs sont décalés de 5 secondes, tracer une requête dans les deux systèmes devient un puzzle parce que les horodatages ne s'alignent pas. Les horloges synchronisées par NTP rendent le traçage distribué et l'agrégation des journaux dramatiquement plus faciles.

Pourquoi la précision de l'heure est plus importante que tu ne le penses

La synchronisation de l'heure NTP n'est pas juste une tâche de maintenance de fond. C'est une dépendance fondamentale pour un nombre surprenant de systèmes :

  • Certificats TLS/SSL : La validité du certificat est vérifiée par rapport à l'heure actuelle. Une horloge décalée de plus que la fenêtre de validité du certificat cause l'échec des connexions HTTPS.
  • Authentification Kerberos : Par défaut, Kerberos rejette les tickets si le décalage d'horloge entre client et serveur dépasse 5 minutes. Les environnements Active Directory sont particulièrement sensibles à cela.
  • Réplication de base de données : De nombreux systèmes de réplication utilisent des horodatages pour déterminer quelle écriture est plus récente. La dérive d'horloge peut causer que les données soient écrasées par des valeurs plus anciennes.
  • Systèmes financiers : Les exigences réglementaires (MiFID II dans l'UE, par exemple) exigent que les systèmes de trading maintiennent la précision de l'horloge à 1 ms de l'UTC.
  • Horodatages Unix : Chaque horodatage Unix que ton application génère n'est aussi précis que l'horloge système. Si tu veux comprendre la fondation sur laquelle ces horodatages sont construits, notre guide sur le temps d'époque et les horodatages Unix couvre les bases en détail.
Les machines virtuelles nécessitent une attention particulière. Les machines virtuelles n'ont pas d'horloges matérielles dédiées. Quand une machine virtuelle est mise en pause, migrée ou restaurée à partir d'un instantané, son horloge peut sauter énormément. Configure toujours NTP (ou utilise VMware Tools / Services d'intégration Hyper-V) sur chaque machine virtuelle, et vérifie que l'hôte hyperviseur lui-même est également synchronisé par NTP.

Pour la plupart des applications, NTP sur Internet public te donne une précision de 10-50 ms, ce qui est plus que suffisant. Pour des exigences plus strictes, l'exécution de ton propre serveur Stratum 1 avec un récepteur GPS (un Raspberry Pi avec un chapeau GPS coûte moins de 50 €) peut te donner une précision inférieure à la milliseconde sur ton réseau local. Et pour tout ce qui nécessite une précision microsecondes, PTP avec horodatage matériel est le chemin à suivre.

Le résumé : NTP est une infrastructure discrète que tu ne remarques que quand elle casse. Une configuration NTP bien réglée signifie que tes journaux ont du sens, tes jetons fonctionnent, tes certificats se valident et tes systèmes distribués s'accordent sur ce que « maintenant » signifie.

Outil de conversion d'horodatage Unix affichant la conversion de temps synchronisée par NTP

Convertis les horodatages Unix synchronisés par NTP instantanément

Quand la synchronisation de l'heure NTP produit un horodatage Unix et que tu dois savoir ce qu'il signifie sous forme lisible par l'humain, notre convertisseur gratuit le gère instantanément. Colle n'importe quel horodatage de 10 ou 13 chiffres et obtiens la date complète, l'heure, le format ISO 8601 et le temps relatif en un clic.

Essaie le convertisseur d'horodatage gratuit →

Sur une connexion haut débit typique, NTP atteint une précision de 10 à 50 millisecondes par rapport à l'UTC. Sur un réseau local bien réglé se synchronisant avec un serveur Stratum 1 ou Stratum 2 à proximité, tu peux descendre à 1 à 5 ms. Le principal facteur limitant est la latence variable du réseau, que l'algorithme de NTP prend en compte statistiquement sur plusieurs cycles de sondage.

Sans NTP, l'horloge du serveur dérive librement en fonction de son oscillateur matériel. Selon le matériel, cela peut signifier perdre ou gagner plusieurs secondes par jour. Sur des semaines ou des mois, la dérive peut devenir assez grande pour casser la validation des certificats TLS, causer des défaillances d'authentification Kerberos, corrompre les horodatages des journaux et déclencher des erreurs d'expiration de jeton dans les applications qui s'appuient sur les horodatages Unix.

ntpd est le démon NTP original de l'implémentation de référence NTP. chronyd (du projet chrony) est une implémentation plus récente qui gère mieux les connexions réseau intermittentes, se synchronise plus rapidement après un redémarrage et est plus précise dans les environnements avec latence variable. La plupart des distributions Linux modernes (RHEL 7+, Ubuntu 18.04+) utilisent par défaut chrony. Les deux implémentent le même protocole NTPv4 et sont interopérables.

Oui, mais cela nécessite de la prudence. Les serveurs NTP annoncent les secondes intercalaires à venir via un indicateur dans le paquet de protocole. Les clients peuvent alors gérer la seconde supplémentaire en l'insérant directement (ce qui peut causer un saut d'une seconde vers l'arrière) ou en utilisant « l'étalement des secondes intercalaires », où la seconde supplémentaire est répartie sur une fenêtre de 24 heures. Google et Cloudflare utilisent tous deux l'étalement des secondes intercalaires sur leurs serveurs NTP publics pour éviter complètement le saut.

Configure au moins quatre serveurs. NTP utilise un algorithme de vote appelé « algorithme d'intersection » pour détecter et rejeter les valeurs aberrantes. Avec un ou deux serveurs seulement, NTP ne peut pas déterminer lequel a un problème s'ils ne s'accordent pas. Avec quatre ou plus, il peut identifier et ignorer un serveur mal comporté tout en maintenant la précision. Le Projet NTP Pool rend cela facile en fournissant des adresses de pool régionales comme 0.pool.ntp.org à 3.pool.ntp.org .

NTP synchronise toujours les horloges sur l'UTC. Les fuseaux horaires sont une question d'affichage gérée par le système d'exploitation séparément de NTP. Un serveur à Tokyo et un serveur à New York se synchronisent tous deux sur l'UTC, et chacun applique son propre décalage de fuseau horaire local à des fins d'affichage. C'est exactement pourquoi les horodatages Unix sont stockés en UTC et convertis en heure locale uniquement quand ils sont affichés aux utilisateurs. Notre guide sur les horodatages Unix et l'UTC explique la relation en plus de détail.