Non, votre pile CMOS se porte très bien. Ce décalage de deux heures qui réapparaît comme par magie à chaque fois que vous jonglez entre Windows et Linux sur la même machine n’a rien à voir avec une batterie moribonde : c’est un désaccord philosophique entre deux systèmes d’exploitation qui refusent de parler la même langue horaire. Et une fois qu’on comprend le mécanisme, la correction prend littéralement trente secondes.
À retenir
- Windows et Linux ne lisent pas l’horloge matérielle de la même façon
- Le décalage de deux heures n’est pas aléatoire, il suit le fuseau horaire saisonnier
- Une seule commande règle le problème définitivement en quelques secondes
Deux OS, deux façons de lire la même horloge
Chaque carte mère embarque une petite horloge physique, la fameuse RTC (real-time clock), alimentée en permanence par une pile bouton même quand l’ordinateur est éteint. Cette horloge, aussi appelée CMOS ou BIOS clock, est extérieure au système d’exploitation et se trouve sur la carte mère de l’ordinateur, où elle continue de tourner même une fois l’appareil éteint. Jusque-là, rien d’exotique : c’est le composant qui vous évite de ressaisir la date à chaque démarrage.
Le problème commence dès qu’on interroge cette horloge pour savoir « quelle heure affiche-t-elle réellement ». Par défaut, Linux considère que l’heure stockée dans l’horloge matérielle est en UTC, alors que Windows part du principe qu’il s’agit de l’heure locale, et c’est précisément là que les ennuis commencent. Concrètement, si vous êtes à Paris et qu’il est 15h00 chez vous, Linux va écrire 13h00 (l’équivalent UTC) dans la RTC. Windows, lui, va relire cette même valeur et l’afficher telle quelle, sans y appliquer de correction de fuseau, ce qui donne un magnifique 13h00 alors qu’il est en réalité 15h00.
Pourquoi exactement deux heures, et pas une seule
C’est là que l’histoire devient croustillante. En France comme dans une bonne partie de l’Europe, le décalage n’est pas figé toute l’année : l’heure affichée correspond à UTC+1 h en hiver et à UTC+2 h en été. Résultat, un utilisateur qui bascule entre les deux OS l’hiver ne verra « qu’» une heure de retard, alors qu’en été, au moment où l’heure d’été est appliquée, le fossé se creuse à deux heures pile. Un témoignage sur un forum d’entraide résume ça très bien : le problème était simple à comprendre, on réglait l’heure sous Windows, on redémarrait sous Linux sans souci, mais en retournant sous Windows l’horloge affichait deux heures de retard avec l’heure d’été, et une heure de retard avec l’heure d’hiver.
Ce n’est donc pas un bug aléatoire ni une carte mère capricieuse. C’est un calcul mécanique et parfaitement reproductible : à chaque saison, le décalage colle exactement à l’écart entre UTC et l’heure locale en vigueur à ce moment-là. Un développeur qui a documenté le phénomène le formule sans détour : ce comportement touche de nombreuses distributions (Ubuntu, Fedora, Linux Mint et bien d’autres) et il ne s’agit pas d’un bug, mais du résultat de choix d’architecture différents dans la façon dont les systèmes interprètent le temps.
La solution tient en une commande (ou une clé de registre)
Deux chemins s’offrent à vous, et il faut en choisir un seul, jamais les deux à la fois. Il existe deux options : faire en sorte que Linux utilise l’heure locale, ou faire en sorte que Windows utilise l’heure UTC, sans suivre les deux méthodes en même temps sous peine qu’elles ne se comprennent plus.
La méthode la plus rapide consiste à demander à Linux de se caler sur le fonctionnement de Windows. Un terminal, une ligne de commande, et l’affaire est réglée : « timedatectl set-local-rtc 1 –adjust-system-clock » fait passer Linux en heure locale. Une fois la commande passée, vérifiez que le changement a bien été pris en compte en relançant timedatectl : RTC in local TZ doit être passé à Yes. Aucun redémarrage supplémentaire n’est nécessaire, le correctif s’applique immédiatement.
L’autre option, plus radicale mais tout aussi valable, consiste à faire l’inverse : apprendre à Windows à raisonner en UTC comme le fait nativement tout système Unix. Cela passe par une modification du registre, en ajoutant une valeur DWORD nommée RealTimeIsUniversal réglée sur 1 dans la clé TimeZoneInformation du registre. Il suffit de créer un fichier .reg contenant cette clé, de l’exécuter en double-cliquant dessus, puis de redémarrer Windows pour que le changement prenne effet.
Quelle option privilégier, et pourquoi je penche pour Linux
Personnellement, je conseille de laisser Windows tranquille et de faire plier Linux plutôt que l’inverse. La raison est simple : bidouiller le registre Windows peut avoir des effets de bord sur d’autres logiciels qui s’attendent à un comportement standard, alors que la commande côté Linux est réversible et sans risque. Cela dit, la méthode « heure locale sous Linux » a un revers qu’il ne faut pas ignorer : le système avertit que ce mode n’est pas totalement pris en charge et peut causer quelques soucis lors des changements de fuseau horaire ou de passage à l’heure d’été et d’hiver. Dans les faits, sur une configuration de bureau classique qui ne bouge pas de fuseau horaire, ce risque reste largement théorique.
Un détail amusant que peu de gens réalisent : même sous Windows, en coulisses, tous les horodatages système, les logs, les certificats ou les timestamps Unix utilisés par une multitude de logiciels reposent sur UTC. Les timestamp Unix utilisés partout, y compris sous Windows, sont en UTC, et si vous voyagez avec un PC portable, l’UTC ne change jamais d’un fuseau horaire à l’autre. Windows fait une exception d’affichage sur la RTC, mais tout le reste de la mécanique interne parle déjà UTC depuis toujours. La prochaine fois que votre horloge fait des siennes après un redémarrage croisé, vous saurez que le coupable n’est pas votre matériel, mais un choix de conception vieux de plusieurs décennies que personne n’a jamais harmonisé entre les deux mondes.
Sources : forum.ubuntu-fr.org | malekal.com