La synchronisation de l'heure sous Windows (w32time) et les systèmes métier — résoudre à la racine « les horodatages des journaux ne correspondent pas »

« Un équipement s’est arrêté anormalement. En recoupant le journal de l’équipement avec le journal applicatif du PC, nous avons trouvé un décalage de 40 secondes, rendant impossible de déterminer si l’erreur de l’équipement ou la coupure de communication de l’application était survenue en premier. » — c’est une situation que nous avons rencontrée à de nombreuses reprises lors d’investigations d’incidents sur des systèmes d’intégration d’équipements. Caméras réseau, automates (PLC), machines de contrôle, et PC Windows : chacun horodate ses journaux avec sa propre horloge, et en réalité personne ne garantissait que ces horloges étaient synchronisées entre elles.

En temps normal, presque personne ne remarque le décalage de l’heure. Le problème surgit invariablement au moment de l’investigation d’un incident, c’est-à-dire quand la « chronologie des événements » devient une preuve nécessaire. Et dès qu’on commence à creuser, les faits s’enchaînent : « le PC en groupe de travail ne se synchronisait qu’une fois par semaine », « la machine virtuelle oscillait en recevant l’heure à la fois de l’hôte et de NTP », ou tout simplement « personne n’avait réglé l’horloge de l’équipement ».

Cet article s’adresse aux développeurs et responsables informatiques qui ont déjà eu du mal à recouper les journaux d’un équipement et d’un PC, ou d’un serveur et d’un poste client. Nous y examinons, avec l’appui des sources officielles Microsoft, le fonctionnement du service de synchronisation de l’heure Windows (w32time), le diagnostic pratique avec les commandes w32tm, le niveau de précision réaliste à attendre, et enfin la conception côté système métier en partant du principe que « l’heure peut dériver, et même reculer ».

1. La conclusion, d’abord

• L’heure de Windows est gérée par le service Windows Time (w32time). Ce n’est pas une implémentation NTP stricte, mais un client/serveur NTP qui ajuste l’horloge à l’aide des algorithmes de la spécification NTP, en communiquant sur le port UDP 123.¹
• Un environnement de domaine possède une hiérarchie temporelle fixe. Les membres se synchronisent avec le DC, le DC avec le DC du domaine parent, et le sommet est l’émulateur PDC du domaine racine de la forêt. Si ce sommet ne se synchronise pas avec une source de temps externe précise, tout le domaine dérive ensemble.¹
• Une machine en groupe de travail (non jointe à un domaine) se synchronise par défaut avec time.windows.com, à basse fréquence. La valeur de registre par défaut de SpecialPollInterval est de 604 800 secondes (une semaine) pour une configuration autonome. Un décalage de plusieurs dizaines de secondes se produit « conformément aux spécifications ».²³
• Le diagnostic se fait entièrement avec l’ensemble des commandes w32tm. w32tm /query /status pour l’état et la source de synchronisation, /stripchart pour mesurer concrètement l’écart avec un autre système, /config /manualpeerlist pour spécifier la cible de synchronisation, et /resync pour une resynchronisation immédiate.²
• w32time corrige progressivement les petits écarts en accélérant ou ralentissant l’horloge (glissement, slew), et corrige les gros écarts en réécrivant directement l’horloge (saut, step). Autrement dit, l’horloge système peut sauter aussi bien en avant qu’en arrière. Autre comportement important : si l’écart dépasse une limite (MaxPos/MaxNegPhaseCorrection), il n’est pas corrigé mais simplement consigné dans le journal des événements.¹²
• La précision de la configuration par défaut visait historiquement, comme objectif de conception, à satisfaire la contrainte des 5 minutes de Kerberos. Depuis Windows Server 2016 / Windows 10 1607, l’algorithme s’est considérablement amélioré : sous certaines conditions (source Stratum 1 précise, latence réseau, nombre de sauts, etc.), une précision de 1 seconde, 50 ms ou 1 ms est désormais prise en charge.⁴
• Un invité Hyper-V dispose de deux fournisseurs de temps, l’hôte et NTP. Depuis Windows Server 2016, l’invité a été amélioré pour choisir le meilleur des deux, mais pour un invité joint à un domaine en 2012 R2 ou antérieur, il est recommandé de désactiver le fournisseur de synchronisation de l’heure Hyper-V.³
• Côté application, la conception doit partir du principe que « l’heure dérive, et peut même reculer ». Enregistrez l’heure des journaux en UTC, et mesurez le temps écoulé avec Stopwatch, qui croît de façon monotone indépendamment de l’horloge système. Cette répartition des rôles est le socle de tout le reste.⁵⁶

2. Le fonctionnement de w32time — un comportement radicalement différent entre domaine et groupe de travail

Le service Windows Time (W32Time) est le composant standard de synchronisation de l’heure sous Windows. Il obtient des échantillons de temps auprès de sources réseau via NTP (et MS-SNTP, sa variante sécurisée pour les domaines), sélectionne le meilleur échantillon grâce aux algorithmes de filtrage et de sélection d’horloge de NTP, puis ajuste l’horloge locale.¹

Le point à retenir est que la façon dont la cible de synchronisation est déterminée diffère radicalement selon la configuration.

Dans un environnement de domaine (Type=NT5DS), la forêt AD DS possède une hiérarchie temporelle prédéfinie. Les PC/serveurs membres se synchronisent avec le DC de leur propre domaine, le DC se synchronise avec le DC du domaine parent, et le sommet de la hiérarchie est l’émulateur PDC du domaine racine de la forêt (ou un DC configuré comme source de temps fiable). Les paquets NTP sont signés avec une clé de session Kerberos, et seule une heure authentifiée est acceptée.¹ Grâce à cela, les PC d’un même domaine sont en général raisonnablement synchronisés entre eux. Le problème se situe au sommet : si l’émulateur PDC ne se synchronise pas avec une source de temps externe précise (horloge GPS ou serveur NTP fiable), tout le monde se retrouve avec « la même heure, mais fausse ». Ce décalage n’apparaît qu’au moment où l’on recoupe les journaux avec un système externe ou un enregistrement côté cloud.

flowchart TD
    EXT["Source de temps externe précise<br/>Horloge GPS / serveur NTP fiable"]
    PDC["Émulateur PDC du<br/>domaine racine de la forêt"]
    CDC1["DC du domaine enfant"]
    CDC2["Autre DC du même domaine"]
    M1["Serveur membre / PC"]
    M2["Serveur membre / PC"]
    M3["Serveur membre / PC"]

    EXT -->|"C'est l'administrateur qui configure ce point"| PDC
    PDC --> CDC1
    PDC --> CDC2
    CDC1 --> M1
    CDC1 --> M2
    CDC2 --> M3

Figure 1 : la hiérarchie temporelle du domaine — les flèches indiquent le sens de distribution de l’heure

En visualisant cet arbre en une seule image, on voit clairement que si la racine se trompe, tout le monde se trompe de la même façon. Et comme tout le monde se trompe ensemble, personne ne s’en aperçoit tant qu’on ne compare que des journaux internes. Le problème n’éclate que le jour où l’on recoupe avec l’extérieur. C’est pour cette raison qu’il faut commencer par vérifier la configuration du sommet.

Dans un environnement de groupe de travail (Type=NTP), la cible de synchronisation par défaut est time.windows.com,0x1. 0x1 (SpecialInterval) est un indicateur qui fait déterminer l’intervalle de sondage par la valeur de registre SpecialPollInterval, dont la valeur par défaut est de 604 800 secondes = une semaine pour une configuration autonome.² Même sur un client Windows 10, c’est environ une fois par jour, et pour la génération Windows Server 2012 R2, le défaut était d’une fois par semaine.³ Comme l’horloge interne d’un PC (oscillateur à quartz) dérive couramment de l’ordre de la seconde par jour selon l’environnement (température, etc.), un décalage de plusieurs dizaines de secondes est tout à fait normal avec une synchronisation hebdomadaire. Le « décalage de 40 secondes » évoqué en introduction, c’est généralement de cela qu’il s’agit.

Un autre point important en pratique est le comportement de la discipline d’horloge (clock discipline). Tant que l’écart est faible, w32time le corrige progressivement en accélérant ou ralentissant l’horloge (glissement) ; quand l’écart dépasse MaxAllowedPhaseOffset, il règle directement l’horloge (saut).¹² De plus, si l’écart dépasse MaxPosPhaseCorrection/MaxNegPhaseCorrection (par défaut 54 000 secondes = 15 heures en autonome), la correction n’est plus appliquée : seul un événement est consigné.² Quand « la synchronisation devrait fonctionner mais rien ne se corrige », il arrive que ce soit cette limite qui soit atteinte. Et la correction par saut peut aussi jouer dans le sens négatif — autrement dit, l’horloge système de Windows peut sauter en arrière — ce qui nous mène directement à la conception applicative abordée plus loin.

3. Les commandes w32tm en pratique — vérifier l’état, mesurer l’écart, changer la cible de synchronisation

Les commandes utilisées pour les investigations liées à l’heure se résument en pratique à cinq. Toutes s’exécutent dans une invite de commandes avec des privilèges administrateur.²

Commençons par vérifier l’état actuel.

w32tm /query /status

Indicateur de secondes intercalaires: 0(pas d'avertissement)
Niveau: 4 (référence secondaire - synchronisé par (S)NTP)
Précision: -23 (119.209ns par tic)
Délai racine: 0.0312500s
Dispersion racine: 7.7756348s
ID de référence: 0xC0A80A14 (IP source:  192.168.10.20)
Dernière synchronisation réussie: 22/07/2026 08:14:02
Source: dc01.example.local
Intervalle d'interrogation: 10 (1024s)

Il y a trois points à examiner : la « Source » est-elle bien celle attendue (Local CMOS Clock ou Free-running System Clock signifie qu’il n’y a en réalité pas de synchronisation), la « Dernière synchronisation réussie » est-elle récente (si elle remonte à plusieurs jours, la synchronisation ne fonctionne pas), et le « Niveau » (Stratum) est-il raisonnable (à combien de sauts d’une source de temps précise ; w32time n’accepte que jusqu’au Stratum 15).⁷ Pour connaître uniquement la source de synchronisation, utilisez w32tm /query /source ; pour l’état de plusieurs cibles de synchronisation, w32tm /query /peers ; pour les valeurs de configuration et leur origine (stratégie de groupe ou locale), w32tm /query /configuration.

Les libellés ci-dessus sont ceux d’un Windows en locale française ; un Windows en locale anglaise affiche les siens en anglais. Voici la correspondance entre les deux. Utilisez-la lorsque vous échangez avec du personnel d’un site à l’étranger, ou pour vos recherches en anglais. Notez que les libellés affichés dépendent de la locale : n’écrivez pas de script qui analyse mécaniquement cette sortie.

Ensuite, la mesure concrète de l’écart avec l’autre partie. Cela sert, lors d’une investigation d’incident, à chiffrer « de combien ce PC est actuellement décalé par rapport au serveur ».

w32tm /stripchart /computer:192.168.10.20 /samples:5 /dataonly

Suivi de 192.168.10.20 [192.168.10.20:123] en cours.
L'heure actuelle est le 24/07/2026 09:41:03.
09:41:03, +28.1246875s
09:41:05, +28.1250120s
09:41:07, +28.1248533s
09:41:09, +28.1251008s
09:41:11, +28.1249517s

Dans cet exemple, on peut immédiatement conclure que « ce PC est en retard d’environ 28 secondes par rapport à l’autre partie ». Comme /stripchart est une mesure d’affichage qui ne modifie pas l’horloge locale, on peut l’utiliser sans crainte même sur un PC d’équipement en cours de fonctionnement. Chez nous, la première chose que nous faisons lors d’une investigation d’incident est d’exécuter cette commande sur toutes les machines concernées avant de recouper les journaux, afin de dresser d’abord un tableau des décalages avant de commencer le recoupement.

Pour spécifier explicitement la cible de synchronisation, on utilise /config. Voici la pratique standard pour désigner un serveur NTP interne (ou un DC) :

w32tm /config /manualpeerlist:"ntp1.example.local,0x8 ntp2.example.local,0x8" /syncfromflags:manual /update
w32tm /resync

0x8 est l’indicateur qui fait synchroniser en mode client ; en le combinant avec 0x1 (SpecialInterval) (soit ,0x9), le sondage suit l’intervalle défini par SpecialPollInterval. 0x1 seul fait tomber l’indicateur de mode client, donc si vous voulez spécifier un intervalle, utilisez ,0x8 ou ,0x9. Si vous ne disposez que de deux serveurs, il est recommandé d’ajouter 0x2 (UseAsFallbackOnly) à l’un des deux pour expliciter la priorité (Microsoft indique qu’il vaut mieux en prévoir trois ou plus si possible).² Pour abandonner la désignation manuelle et revenir à la hiérarchie du domaine, exécutez w32tm /config /syncfromflags:domhier /update puis redémarrez le service. w32tm /resync abandonne les statistiques d’erreur accumulées et force une resynchronisation immédiate ; utilisez-la pour vérifier la prise en compte d’un changement de configuration.²

Le nombre placé après le nom du serveur est l’indicateur NtpServer. Comme ces valeurs sont dispersées et faciles à mal utiliser, voici un tableau récapitulatif.²

Ne spécifiez jamais 0x1 seul. L’indicateur de mode client ne serait pas activé, ce qui donnerait une configuration où seul l’intervalle est défini, sans synchronisation réelle. Si vous voulez fixer l’intervalle, utilisez 0x9.

Réduire l’intervalle de sondage d’un PC en groupe de travail

La « réduction de SpecialPollInterval » mentionnée dans le tableau de décision du chapitre 7 se fait en modifiant la valeur de registre puis en redémarrant le service. Voici la procédure pour passer de la valeur par défaut de 604 800 secondes (une semaine) à 3 600 secondes (une heure).²

rem (1) Régler l'intervalle de sondage à 3 600 secondes (la valeur REG_DWORD est indiquée en décimal)
reg add "HKLM\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\NtpClient" /v SpecialPollInterval /t REG_DWORD /d 3600 /f

rem (2) SpecialPollInterval ne s'applique qu'aux sources de temps portant un indicateur incluant 0x1 -- on utilise donc 0x9
w32tm /config /manualpeerlist:"ntp1.example.local,0x9 ntp2.example.local,0x9" /syncfromflags:manual /update

rem (3) Redémarrer le service pour appliquer le changement, puis resynchroniser immédiatement
net stop w32time && net start w32time
w32tm /resync

rem (4) Vérifier le résultat appliqué et l'origine de chaque valeur (stratégie de groupe ou locale)
w32tm /query /configuration
w32tm /query /status

Si vous omettez l’étape (2), modifier uniquement le registre ne change pas l’intervalle : SpecialPollInterval n’est utilisé que pour les sources de temps portant l’indicateur 0x1. Par ailleurs, dans un environnement où les réglages d’heure sont distribués par stratégie de groupe, une modification locale du registre sera écrasée à la prochaine application de la stratégie. Vérifiez l’origine de chaque valeur dans la sortie de w32tm /query /configuration ; si elle est gérée par stratégie, configurez-la plutôt via « Configuration ordinateur » > « Modèles d’administration » > « Système » > « Windows Time Service » > « Time Providers » > « Configurer le client NTP Windows ».

Notez que la désignation d’un serveur NTP externe via /manualpeerlist est distincte de l’heure authentifiée du domaine — elle n’est pas authentifiée — et ne doit donc en principe pas être utilisée sur un membre de domaine : elle est réservée au sommet de la hiérarchie (l’émulateur PDC) ou aux machines hors domaine.¹

4. La question de la précision — jusqu’où va-t-on par défaut, et les conditions du milliseconde

À la question « au final, à quel point la synchronisation NTP de Windows est-elle précise ? », la réponse dépend de l’époque.

Sur Windows Server 2012 R2 / Windows 8.1 et antérieur, l’objectif de conception de w32time était de fournir une précision satisfaisant l’exigence d’authentification Kerberos (5 minutes par défaut) et une « heure globalement correcte » au sein d’une même forêt ; toute exigence de précision plus stricte est explicitement déclarée hors du périmètre de conception et non prise en charge.⁴ Autrement dit, dans ce monde-là, « être juste à la seconde près » est déjà conforme à la conception.

Depuis Windows Server 2016 / Windows 10 1607, l’algorithme a été amélioré et la fréquence de mise à jour de l’horloge a été considérablement relevée par défaut (par exemple, sur un serveur, l’ajustement de l’horloge est passé d’une fois par heure à une fois par seconde).³ En conséquence, une précision de 1 seconde, 50 ms ou 1 ms est désormais définie comme limite de prise en charge, sous certaines conditions. Voici les principales conditions pour le millisecond — et inversement, il ne faut pas attendre le millisecond dans un environnement qui ne les réunit pas toutes.⁴

• Une hiérarchie NTP dont le sommet est une source Stratum 1 précise et stable (horloge GPS, etc.), avec tous les Windows du chemin configurés en haute précision
• Une latence réseau inférieure à 0,1 ms vers la source de temps, à moins de 5 Stratum et 4 sauts de celle-ci
• Une utilisation CPU (moyenne quotidienne) inférieure ou égale à 80 % à chaque niveau (y compris l’hôte en environnement virtualisé)

Par ailleurs, pour une source de temps distante sur Internet comme time.windows.com, on ne peut pas attendre une précision de 1 ms, car elle subit l’asymétrie du chemin réseau et la congestion.⁷ Comme repère pratique, il est prudent de raisonner en trois paliers : « groupe de travail par défaut = décalage possible de la seconde à plusieurs dizaines de secondes », « synchronisation NTP interne correctement configurée = quelques dizaines de ms à moins d’une seconde », « source de temps dédiée avec conception adaptée = de l’ordre de la milliseconde ». Si l’intégration d’équipements exige une chronologie précise à la milliseconde, il vaut mieux ne pas compter sur la synchronisation de l’heure et privilégier, comme expliqué plus loin, une conception mesurant avec l’horloge d’un seul côté.

5. L’heure des machines virtuelles — la double relation entre le service d’intégration de synchronisation Hyper-V et NTP

L’heure des machines virtuelles est un domaine plus sujet à complications que celle des machines physiques. La raison est simple : il y a deux sources qui fournissent l’heure. Un Windows invité Hyper-V dispose à la fois du service d’intégration de synchronisation de l’heure Hyper-V (fournisseur VMICTimeSync), qui reçoit l’heure de l’hôte, et d’un client NTP classique ; Windows choisit « le meilleur » selon l’ordre : niveau (Stratum), retard racine, dispersion racine, puis décalage.⁷

Ce mécanisme a été considérablement amélioré avec Windows Server 2016 : l’heure initiale au démarrage ou à la restauration de la VM est devenue précise, des échantillons corrigés du délai d’interruption sont désormais transmis à w32time, ce qui permet de maintenir une précision de l’ordre de 10 µs par rapport à l’hôte. Le Stratum que l’hôte rapporte à l’invité reflète désormais mieux la réalité (« Stratum de l’hôte + 1 »), et un invité joint à un domaine à partir de 2016 choisit désormais l’horloge la plus précise au lieu de s’en remettre systématiquement à l’hôte.³

En revanche, pour un invité Windows Server 2012 R2 ou antérieur exécuté dans un domaine, le fournisseur de synchronisation de l’heure Hyper-V peut perturber la synchronisation du domaine, aussi Microsoft recommande-t-il de désactiver ce fournisseur.³

reg add HKLM\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\VMICTimeProvider /v Enabled /t REG_DWORD /d 0 /f
net stop w32time && net start w32time

Le cas des VM Azure est également documenté ; l’essentiel est le suivant : « une VM jointe à un domaine (en particulier un DC virtualisé) doit désactiver TimeSync et se rabattre exclusivement sur la hiérarchie du domaine, tandis qu’une VM isolée hors domaine garde par défaut la synchronisation avec l’hôte ».³ Le principe est le même avec les hyperviseurs tiers (VMware, etc.) : il est recommandé de désactiver la fonction de synchronisation de l’heure côté hôte pour un invité joint à un domaine.³ Si vous observez le symptôme « NTP et la synchronisation avec l’hôte se tirent alternativement l’horloge, et l’heure des journaux fait des allers-retours », soupçonnez cette double relation. Ajoutons une précaution opérationnelle : juste après une restauration depuis un état enregistré de la VM ou une migration en direct, la correction démarre depuis un état très décalé, donc ne faites pas particulièrement confiance à l’heure des journaux immédiatement après une restauration.

6. La conception côté système métier — construire en partant du principe que l’heure « dérive, et peut reculer »

Tout ce qui précède relève de l’infrastructure, mais quel que soit le soin apporté à la synchronisation de l’heure, le décalage ne tombera jamais à zéro. Du côté de ceux qui développent un logiciel d’intégration d’équipements, il faut concevoir la journalisation et la mesure du temps en partant du principe que l’heure dérive, et qu’elle peut même reculer.

Le premier principe est d’enregistrer les horodatages des journaux en UTC. Enregistrer en heure locale expose le recoupement aux perturbations du fuseau horaire, de l’heure d’été, et des différences de réglage entre appareils (ce sujet est traité en détail dans « Date, heure et fuseau horaire dans les applications métier »). Le second principe est de choisir l’horloge en fonction du besoin : « quand cela s’est-il produit » ou « combien de temps cela a-t-il pris ».

// [Piège] Mesurer un temps écoulé avec l'horloge système
// Si une correction par saut de w32time intervient, cet écart peut être plus long, plus court, ou même négatif par rapport à la réalité
var start = DateTime.UtcNow;
ExecuteInspection();
var elapsed = DateTime.UtcNow - start;   // se déclenche à tort si utilisé pour un test de délai d'expiration

// [Pratique standard] Mesurer le temps écoulé avec Stopwatch (horloge à croissance monotone)
long t0 = Stopwatch.GetTimestamp();
ExecuteInspection();
TimeSpan elapsed2 = Stopwatch.GetElapsedTime(t0);   // .NET 7 et ultérieur. Avant cela, Stopwatch.StartNew()

Stopwatch est une classe dédiée à la mesure du temps écoulé qui compte des tics via un compteur de performance haute résolution (équivalent à QueryPerformanceCounter) ; elle n’est pas affectée par les corrections de l’horloge système.⁵ DateTime.UtcNow, en revanche, est l’horloge système elle-même, et sa résolution dépend aussi du minuteur système (environ 0,5 à 15 ms).⁶ Test de délai d’expiration, intervalle de nouvelle tentative, mesure de performance, mesure du temps de réponse d’un équipement — tout traitement portant sur une « durée » doit être confié à Stopwatch.

Consignez les deux dans les journaux. En conservant ensemble une paire horloge murale (UTC) et horloge monotone, vous pourrez reconstituer l’ordre et l’intervalle même sur une période qui a chevauché une correction par saut de NTP.

public sealed class OpLog
{
    private static readonly long _baseTimestamp = Stopwatch.GetTimestamp();
    private static long _seq;

    public static void Write(string message)
    {
        long seq = Interlocked.Increment(ref _seq);
        // Heure UTC (quand c'est arrivé) + ms écoulées de façon monotone depuis le démarrage (ordre et intervalle) + numéro de séquence (ordre au sein d'un même horodatage)
        var line = $"{DateTime.UtcNow:yyyy-MM-dd'T'HH:mm:ss.fff'Z'}\t" +
                   $"{Stopwatch.GetElapsedTime(_baseTimestamp).TotalMilliseconds:F1}\t" +
                   $"{seq}\t{message}";
        // ... sortie vers un fichier/ETW
    }
}

Pour recouper les journaux de plusieurs machines et équipements, ajoutez encore deux éléments. Le premier est de consigner régulièrement le décalage avec l’horloge de l’autre partie. Un équipement doté de sa propre horloge, comme une caméra ou un automate, permet souvent de lire son heure via le protocole de communication ; consignez donc dans le journal, au démarrage de l’application puis régulièrement (par exemple toutes les heures), « l’écart entre l’heure UTC du PC et l’heure de l’équipement ». C’est l’équivalent, côté équipement, de w32tm /stripchart, et cela permet, après un incident, de recouper mécaniquement en se disant « sur cette période, il faut appliquer une correction de +12,3 secondes pour lire l’heure du journal de l’équipement ». Le second est d’aligner le système temporel de votre propre journal avec celui du journal des événements et d’ETW (voir « Introduction au journal des événements Windows et à ETW »). Pour la conception des traces en cas de plantage (« Concevoir la conservation des journaux et des dumps lors d’un plantage ») ou pour l’investigation d’incidents d’origine réseau comme une coupure de communication de caméra (« Quand les retransmissions TCP bloquent la communication d’une caméra industrielle »), le fait que les systèmes temporels soient alignés ou non change le temps d’investigation d’un ordre de grandeur.

Sur un réseau local d’usine hors ligne (sans connexion Internet), time.windows.com est inaccessible ; la pratique standard consiste donc à installer un serveur NTP local sur le LAN et à aligner tous les appareils sur celui-ci. Une horloge GPS serait idéale, mais même sans elle, si l’on parvient à un état où « l’heure absolue est peut-être légèrement fausse, mais tous les appareils sont alignés sur la même référence », l’objectif du recoupement des journaux est presque atteint. Pour le serveur de référence, envisagez aussi d’ajuster LocalClockDispersion, qui détermine la précision auto-déclarée pendant la période où il ne peut pas se synchroniser avec l’extérieur.²

7. Tableau de décision par environnement

8. Conclusion

• L’heure de Windows est gérée par w32time : dans un domaine, il s’agit d’une synchronisation hiérarchique dont le sommet est l’émulateur PDC ; en groupe de travail, c’est par défaut une synchronisation basse fréquence avec time.windows.com. Un décalage de plusieurs dizaines de secondes n’est pas une panne, c’est la conséquence des valeurs par défaut.
• L’investigation commence par vérifier la source de synchronisation et l’heure de dernière synchronisation avec w32tm /query /status, puis mesurer concrètement l’écart avec l’autre partie via w32tm /stripchart. La désignation explicite de la cible se fait avec /config /manualpeerlist, et l’application immédiate avec /resync.
• w32time corrige les petits écarts par glissement et les gros écarts par saut. Retenez que l’horloge système peut sauter en arrière, et qu’au-delà d’une certaine limite, la correction n’est plus appliquée.
• Historiquement, l’objectif de précision de la configuration par défaut se limitait à satisfaire « les 5 minutes de Kerberos ». La précision de l’ordre de la milliseconde relève de Windows Server 2016 ou ultérieur, et n’est prise en charge que si les conditions de source de temps précise, de latence, de nombre de sauts et de charge CPU sont réunies.
• Une machine virtuelle possède deux systèmes : la synchronisation avec l’hôte et NTP. Une VM jointe à un domaine doit se rabattre exclusivement sur la synchronisation de domaine (désactiver VMICTimeProvider pour un invité d’ancien système), tandis qu’une VM isolée doit en principe garder la synchronisation avec l’hôte.
• Côté application, distinguez l’horodatage en UTC de la mesure du temps écoulé avec Stopwatch, et consignez régulièrement le décalage avec l’horloge propre de l’équipement. Ces trois points suffisent à sortir des investigations d’incidents où l’on ne sait plus « lequel est arrivé en premier ».

Articles connexes

• Date, heure et fuseau horaire dans les applications métier — des pièges de DateTime au principe de stockage en UTC et à la conception des tests
• Concevoir la conservation des journaux et des dumps lors d’un plantage d’une application Windows
• Introduction au journal des événements Windows et à ETW
• Quand les retransmissions TCP bloquent la communication d’une caméra industrielle — causes et diagnostic
• Concevoir une exploitation fiable du Planificateur de tâches
• Traiter le calendrier japonais, les jours fériés et les dates de clôture dans les applications métier

Domaines de conseil associés

合同会社小村ソフト (Komura Software LLC) prend en charge les consultations d’investigation du type « l’heure des journaux d’un équipement et d’un PC ne correspond pas, impossible de déterminer la chronologie de l’incident », la conception de la synchronisation de l’heure pour les LAN d’usine et les environnements d’intégration d’équipements, ainsi que le développement et l’amélioration de logiciels d’intégration d’équipements, y compris les anomalies liées aux délais d’expiration et à la mesure du temps.

• Investigation d’anomalies et analyse des causes
• Conseil technique et revue de conception
• Développement d’applications Windows soft temps réel
• Contact

Références

Articles associés

Articles récents partageant les mêmes étiquettes, pour approfondir des sujets proches.

Sujets associés

Ces pages replacent le sujet dans un contexte plus large de services et de décisions.

Services liés à ce sujet

Cet article est directement lié aux services suivants.

Questions fréquentes

Questions souvent posées lors d’une consultation sur le sujet de cet article.

Les horodatages des journaux du PC et de l'équipement sont décalés. Que faut-il vérifier en premier ?

Commencez par exécuter w32tm /query /status côté PC et vérifiez la « Source » (avec quoi il se synchronise) et la « Dernière synchronisation réussie ». Si la source est Local CMOS Clock ou si la dernière synchronisation remonte à plusieurs jours, ce PC ne se synchronise en réalité avec rien. Ensuite, mesurez concrètement l'écart avec l'autre partie (le port NTP d'un serveur ou d'un équipement) avec w32tm /stripchart /computer:cible /dataonly, pour connaître en chiffres qui est décalé et de combien. Si l'équipement possède sa propre horloge, il est souvent possible de lire son heure via l'écran de réglage ou le protocole de communication et de consigner l'écart avec l'heure du PC — cela sert aussi ensuite à recouper d'anciens journaux.

À quelle fréquence un Windows en groupe de travail synchronise-t-il son heure ?

Un Windows qui n'a pas rejoint de domaine se synchronise par défaut avec time.windows.com, mais à une fréquence assez faible. La valeur de registre par défaut de SpecialPollInterval est de 604 800 secondes (une semaine) pour une configuration autonome, et même sur un client Windows 10 c'est environ une fois par jour. Comme l'horloge interne d'un PC dérive couramment d'une seconde à plusieurs dizaines de secondes par jour, on ne peut pas attendre de cette fréquence une précision suffisante pour recouper des journaux métier. Sur un site où la précision temporelle des journaux compte, la pratique standard consiste à indiquer un serveur NTP interne avec w32tm /config /manualpeerlist et à réduire SpecialPollInterval.

Pour une machine virtuelle sous Hyper-V, faut-il caler l'heure sur l'hôte ou sur NTP ?

Un invité Hyper-V dispose de deux fournisseurs de temps : le service d'intégration de synchronisation de l'heure Hyper-V (VMICTimeSync) et le client NTP, et Windows choisit le meilleur en se basant notamment sur le niveau hiérarchique (Stratum). Le principe pour un invité joint à un domaine est de se synchroniser avec la hiérarchie du domaine (le DC) ; avec une combinaison hôte/invité Windows Server 2016 ou ultérieur, les deux ont été améliorés pour pouvoir coexister. Pour un invité Windows Server 2012 R2 ou antérieur utilisé dans un domaine, Microsoft recommande de désactiver VMICTimeProvider pour se rabattre exclusivement sur la synchronisation de domaine. Pour une VM isolée en groupe de travail, il est simple et fiable de garder par défaut la synchronisation avec l'hôte.

Que se passe-t-il si l'heure dérive fortement dans un environnement de domaine ?

Kerberos, utilisé pour l'authentification Active Directory, exige par défaut une concordance d'heure à 5 minutes près entre le client et le serveur. Au-delà, l'authentification échoue et les fonctions de base du domaine cessent de fonctionner : accès aux dossiers partagés, application de la stratégie de groupe, etc. Un PC joint à un domaine se synchronise par défaut selon une hiérarchie dont le sommet est, en dernier ressort, l'émulateur PDC de la racine de la forêt en passant par le DC, si bien qu'un tel écart ne se produit normalement pas. Autrement dit, si l'émulateur PDC lui-même ne se synchronise pas avec une source de temps externe précise, tout le domaine se retrouve avec « une heure fausse, mais la même pour tous » — d'où l'importance de vérifier la configuration au sommet.

Pourquoi ne faut-il pas utiliser DateTime.UtcNow pour mesurer un temps écoulé ?

Parce que DateTime.UtcNow lit l'horloge système et subit donc directement les corrections de w32time. Quand l'écart est important, w32time n'ajuste pas progressivement (slew) mais règle directement l'horloge (step), et l'heure peut alors sauter aussi bien en avant qu'en arrière. Le temps écoulé calculé par soustraction avec UtcNow peut donc se retrouver plus long, plus court, voire négatif par rapport à la réalité. Pour mesurer un temps écoulé ou un délai d'expiration, utilisez Stopwatch (ou Stopwatch.GetTimestamp), qui croît de façon monotone indépendamment de l'horloge système, et réservez UtcNow exclusivement à l'enregistrement du « moment où l'événement s'est produit ».

Profil de l’auteur

Page de présentation de l’auteur de l’article.

Go Komura

Représentant de KomuraSoft LLC

Spécialisé dans le développement de logiciels Windows, le conseil technique et l’analyse de pannes, notamment pour les systèmes existants et les incidents difficiles à reproduire.