Guide de synchronisation de l’heure du serveur

UTC, TAI, l’heure GPS et l’heure civile locale servent à des fins différentes. TAI (International Atomic Time) est une échelle de temps atomique continue calculée par le BIPM à partir des horloges contributrices ; il n’ajoute pas de secondes intercalaires. UTC (Temps Universel Coordonné) diffère du TAI par un nombre entier de secondes et constitue la référence internationale des fuseaux horaires civils. GPS Time était aligné sur UTC à ses débuts en 1980 mais n’ajoute pas de secondes intercalaires.

Selon le [U.S. Observatoire naval] (https://maia.usno.navy.mil/information/eo-values), en septembre 2026, le TAI est de 37 secondes et l’heure GPS est de 18 secondes en avance sur l’UTC. Ces décalages peuvent changer en vertu de la future politique de seconde intercalaire.

La définition du BIPM de la seconde SI fixe la fréquence de transition hyperfine non perturbée de l’état fondamental du césium 133 à 9 192 631 770 Hz. Les horloges au césium utilisent cette transition atomique comme référence de fréquence.

Les étalons primaires et les horloges optiques plus récentes ont des incertitudes mesurées différentes ; un seul chiffre « une seconde sur N ans » ne peut pas décrire tous les appareils. Les instituts nationaux de métrologie comparent leurs normes et contribuent aux échelles de temps internationales. La distribution de ces normes via NTP est un processus distinct de l’affichage du navigateur de Clock-Tani, qui ne se connecte pas directement à une horloge atomique.

Le Network Time Protocol (NTP) synchronise les horloges des ordinateurs sur les réseaux. RFC 5905 (NTPv4) décrit une hiérarchie de serveurs de temps et un calcul de décalage utilisant quatre horodatages : les heures d’envoi et de réception du client et les heures de réception et de transmission du serveur. Un client peut utiliser ces observations pour discipliner son horloge système.

Les performances dépendent de la référence du serveur, de l’horloge de l’appareil, du délai du réseau et de l’asymétrie. Les exemples de réseaux locaux rapides dans la RFC ne constituent pas une promesse de précision fixe pour l’Internet public ou pour chaque système d’exploitation. Service de temps Internet du NIST note que la précision constatée par un utilisateur dépend en grande partie de la stabilité du réseau et de la réciprocité.

Clock-Tani n’exécute pas NTP dans le navigateur et n’ajuste pas l’horloge de l’appareil. Sa page d’heure du serveur estime une différence par rapport aux réponses de l’API Web et au timing aller-retour.

Les horloges des ordinateurs et des téléphones dépendent des oscillateurs matériels et de l’horloge du système d’exploitation. La fréquence de l’oscillateur peut varier en fonction de la température, de l’âge et de la conception de l’appareil, mais aucune fréquence, taux de dérive quotidien ou intervalle de synchronisation ne s’applique à chaque ordinateur.

De nombreux systèmes d’exploitation peuvent ajuster périodiquement leur horloge à l’aide d’un service de temps réseau lorsqu’il est activé et connecté. La méthode et le calendrier dépendent des paramètres et de l’appareil. Si un décalage semble inattendu, vérifiez les paramètres automatiques d’heure et de fuseau horaire ; traiter une comparaison de navigateur comme une estimation affectée par le réseau. FAQ sur le chronométrage du NIST illustre comment les erreurs d’horloge à quartz dépendent de l’oscillateur.

La [page d’heure du serveur] par défaut (/fr/server-time) envoie trois requêtes à l’API de Clock-Tani. Pour chaque réponse, il ajoute la moitié du temps d’aller-retour mesuré par le navigateur à l’horodatage Date.now() de l’API, puis sélectionne l’échantillon avec la latence moyenne. Cela réduit l’influence d’une valeur aberrante lente ; il ne s’agit pas d’une synchronisation NTP ou d’une certification de précision. Le retour à la page ou la reconnexion au réseau peuvent déclencher une autre mesure.

Pour une vue spécifique au site, le serveur envoie une requête HEAD à la cible lorsqu’un résultat récent n’est pas déjà mis en cache ; un décalage estimé valide peut être réutilisé pendant 60 secondes maximum. Il consulte l’en-tête HTTP Date et le temps d’aller-retour de la cible, puis mesure séparément le saut d’API vers le navigateur. HTTP-date a une résolution d’une seconde. Des en-têtes manquants ou peu fiables peuvent conduire à une autre heure de source ou de périphérique, que l’interface distingue. La correction demi-RTT suppose des délais de sortie et de retour similaires et ne peut pas garantir une précision fixe.

Selon les règles UTC actuelles, les secondes intercalaires sont utilisées lorsque cela est nécessaire pour maintenir l’UTC proche du temps de rotation de la Terre (UT1). Le IERS Bulletin C annonce si une seconde intercalaire sera introduite. Une seconde intercalaire positive peut insérer 23:59:60 après 23:59:59 en UTC, ce qui nécessite un logiciel pour gérer une minute inhabituelle.

Résolution CGPM 4 (2022) appelle à augmenter la différence UT1-UTC autorisée d’ici 2035 ou avant et à préparer un plan de mise en œuvre pour un UTC plus continu. Elle ne spécifie pas de méthode d’ajustement déjà définitive après 2035 et ne fait pas de promesse générale que toute gestion des secondes intercalaires se termine à une date particulière.

Les marchés financiers, les systèmes d’aviation et de navigation, les réseaux de télécommunications et les réseaux électriques utilisent tous le timing, mais la précision et les méthodes de validation requises diffèrent selon l’application. Par exemple, [Règlement délégué UE 2025/1155 sur l’activité de trading algorithmique à haute fréquence] (https://eur-lex.europa.eu/eli/reg_del/2025/1155/oj/eng) spécifie une divergence UTC maximale de 100 microsecondes pour une activité particulière ; ce n’est pas une règle universelle pour tous les métiers ou industries.

La navigation par satellite, la coordination des stations de base et les mesures de grille ont leurs propres exigences temporelles. Une vue de navigateur basée sur des réponses Web, telle que Clock-Tani, n’est pas une horloge validée pour ces systèmes. Utilisez la source de temps et les enregistrements officiels du système concerné pour les décisions conséquentes.

Ouvrez la page d’heure du serveur pour comparer l’horloge de votre appareil avec une estimation Clock-Tani basée sur une réponse Web. La vue par défaut prend déjà trois échantillons d’API et choisit le résultat de latence moyenne ; l’actualisation trois fois ne transforme pas ces décalages en une erreur « réelle » certifiée de l’appareil.

La page affiche un décalage estimé en millisecondes, et non une valeur de délai aller-retour mesurée ou un diagnostic de l’état NTP de votre système d’exploitation. Utilisez « Synchroniser à nouveau » après un changement de connexion si vous souhaitez une autre estimation. Si une différence persistante semble inattendue, vérifiez les paramètres automatiques d’heure et de fuseau horaire de votre appareil. Il n’existe pas de seuil universel normal/prudent/sérieux pour cette mesure du navigateur, et un redémarrage n’est pas une condition préalable générale avant un événement urgent.

La page d’heure du serveur de Clock-Tani affiche une référence basée sur une réponse Web à côté de l’heure de l’appareil et estime leur différence. La source par défaut est l’horodatage de l’API de Clock-Tani ; une vue spécifique au site peut utiliser l’en-tête HTTP Date de la cible ou une solution de secours clairement indiquée.

Cette comparaison ne peut pas établir si le service NTP de votre ordinateur fonctionne, certifier une erreur absolue ou vérifier l’heure d’ouverture interne d’un vendeur de billets. Le retard du réseau et l’erreur d’horloge du serveur peuvent l’affecter. Pour les ventes, les examens et autres délais consécutifs, fiez-vous aux annonces officielles et aux dossiers de soumission de l’organisateur. L’outil peut vous aider à observer et à revérifier une référence, et il peut compter à rebours jusqu’à une heure que vous avez définie.