Cloud & DevOps16 octobre 2026· 7 min de lecture

Adieu à la seconde intercalaire : pourquoi l'infrastructure technologique se réjouit de sa suppression

Aziz Kerkeni
Aziz Kerkeni

Pour l'utilisateur moyen de smartphone, une seconde supplémentaire glissée dans la dernière minute d'une année passe totalement inaperçue. Pour les ingénieurs qui maintiennent des bases de données distribuées à l'échelle mondiale, des clusters cloud, des réseaux de télécommunications et des marchés financiers, ce tic unique de l'horloge a longtemps été source de cauchemars. Après des décennies de tensions opérationnelles, de pannes retentissantes et de débats intenses au sein des organismes de normalisation internationaux, la seconde intercalaire est enfin sur le point d'être éliminée. Les métrologistes du monde entier sont parvenus à un consensus pour supprimer progressivement ces ajustements sporadiques, marquant une victoire monumentale pour les informaticiens et les opérateurs d'infrastructure du monde entier.

Une histoire de deux horloges : quand l'astronomie rencontre la précision atomique

Pour comprendre pourquoi la seconde intercalaire est devenue un sujet si controversé en génie logiciel, il faut d'abord examiner comment la civilisation humaine définit le temps. Historiquement, le temps était mesuré astronomiquement par la rotation de la Terre par rapport aux corps célestes, une approche formalisée sous le nom de Temps Universel (UT1). Cependant, la planète ne tourne pas à vitesse constante ; le frottement des marées de la Lune, les changements dans le noyau en fusion de la Terre et les mouvements atmosphériques font que la rotation de la Terre accélère et ralentit de manière irrégulière au fil des décennies.

Au milieu du XXe siècle, l'avènement des horloges atomiques a apporté une norme radicalement plus cohérente. Le Temps Atomique International (TAI) mesure le temps grâce aux oscillations hyper-précises et invariables des atomes de césium. Pour concilier la précision atomique avec le mouvement irrégulier de la planète, le Temps Universel Coordonné (UTC) a été institué en 1972. Selon ce compromis, chaque fois que l'écart entre le temps atomique (TAI) et le temps planétaire (UT1) menaçait de dépasser 0,9 seconde, les métrologistes du Service international de la rotation de la Terre et des systèmes de référence décrétaient une seconde intercalaire, insérant une 61e seconde dans la journée, généralement à la fin du mois de juin ou de décembre.

Bien que cet arrangement ait satisfait les astronomes qui voulaient que le midi solaire coïncide pour toujours avec le midi de l'horloge, il a introduit une variable imprévisible dans les systèmes numériques qui n'avaient jamais été conçus à l'origine pour gérer une minute de 61 secondes.

Pourquoi les systèmes distribués détestent la 61e seconde

Dans l'architecture informatique classique, le temps est traité comme une progression continue et monotone. La norme POSIX, qui sous-tend les systèmes d'exploitation modernes de type Unix, notamment Linux, macOS et Android, définit le temps comme le nombre total de secondes écoulées depuis le 1er janvier 1970 (l'époque Unix). De manière cruciale, le temps POSIX suppose que chaque journée compte précisément 86 400 secondes. Il n'existe aucune représentation sémantique naturelle pour une seconde désignée comme « 23:59:60 ».

Lorsqu'une seconde intercalaire se produit, les noyaux des systèmes d'exploitation standard sont contraints de faire un choix contre nature : soit répéter la 86 400e seconde, soit arrêter l'horloge pendant une seconde entière. Ce comportement sème le chaos dans l'informatique distribuée. Les systèmes modernes à plusieurs nœuds dépendent fortement des horloges monotones pour établir l'ordre des événements, résoudre les conflits de transactions et calculer les délais d'attente. Lorsque l'horloge du système répète soudainement une seconde ou recule, les hypothèses logicielles s'effondrent immédiatement.

Les précédentes secondes intercalaires ont provoqué des répercussions massives dans le monde réel. En 2012, une seconde intercalaire a provoqué des paniques du noyau (« kernel panics ») et des boucles de processeur hyperactives sur des milliers de serveurs Linux, mettant hors service des services Internet majeurs tels que Reddit, Yelp et LinkedIn, tout en clouant au sol plus de 400 vols en Australie en raison d'une panne du système de réservation. Des occurrences ultérieures ont fait tomber des réplicas de bases de données critiques et perturbé des plateformes de commerce électronique, démontrant que malgré des mois de préparation, le décalage horaire automatisé à grande échelle reste intrinsèquement fragile.

L'ère du rafistolage : l'essor et les failles de l'étalement des secondes intercalaires (« Leap Smearing »)

Confrontées à des pannes récurrentes et à un calendrier imprévisible déterminé par la physique planétaire, les entreprises technologiques à hyper-échelle ont décidé de prendre les choses en main. En 2011, Google a mis au point une technique connue sous le nom de « leap smearing » (étalement de la seconde intercalaire). Au lieu de suspendre brusquement l'horloge ou d'insérer une 61e seconde à minuit, Google a modifié ses serveurs internes de protocole NTP (Network Time Protocol) pour étirer progressivement chaque seconde de quelques microsecondes sur une période prolongée, généralement de 12 à 24 heures autour de l'événement intercalaire.

L'étalement des secondes intercalaires s'est avéré remarquablement efficace pour prévenir les plantages, car les applications au sein des réseaux privés de Google n'ont jamais observé l'horloge reculer ou s'arrêter. Bientôt, d'autres géants du cloud, notamment Amazon Web Services et Meta, ont adopté leurs propres versions de cette technique. Les systèmes d'exploitation et les implémentations NTP open source ont progressivement introduit des indicateurs de configuration pour permettre aux plus petites entreprises d'étaler également le temps.

Cependant, cette approche « maison » a fracturé la synchronisation mondiale de l'heure. En raison de l'absence de consensus standardisé sur la manière d'étaler le temps, différents fournisseurs ont adopté des algorithmes incompatibles. Un fournisseur de cloud pouvait étaler le temps sur une fenêtre de 24 heures centrée sur minuit, tandis qu'un autre pouvait l'étaler sur une fenêtre de 18 heures précédant strictement minuit. Pour les applications communiquant entre plusieurs fournisseurs cloud, les registres financiers rapprochant des transactions entre des centres de données disparates ou les systèmes cryptographiques nécessitant une validation stricte des horodatages, ces divergences de l'ordre de la milliseconde ont créé un tout nouveau lot de bogues de synchronisation subtils et insidieux.

La décision historique de la métrologie d'abandonner l'ajustement

Reconnaissant que l'infrastructure logicielle forme désormais la colonne vertébrale du commerce mondial, des communications et de la distribution d'énergie, les autorités internationales de chronométrie ont admis que le statu quo était devenu indéfendable. La Conférence générale des poids et mesures (CGPM) — l'organisme intergouvernemental qui supervise le Système international d'unités — a voté l'abandon de l'insertion régulière de secondes intercalaires d'ici 2035 au plus tard.

Dans le cadre adopté, la tolérance entre le temps atomique et la rotation physique de la Terre sera autorisée à s'élargir considérablement au-delà du seuil traditionnel de 0,9 seconde. Au lieu d'intervenir toutes les quelques années, les métrologistes permettront à la différence d'accumuler une valeur beaucoup plus importante — potentiellement une minute entière ou plus — au cours de décennies ou de siècles. Tout ajustement futur, s'il est jugé nécessaire, se fera sur des échelles de temps si vastes que les plateformes logicielles auront des décennies pour se préparer et coordonner les protocoles de mise en œuvre standard.

Ce changement historique reflète une profonde évolution philosophique dans la mesure du temps par l'humain. Pendant des millénaires, le temps humain a été subordonné au mouvement du soleil et des étoiles. Avec la mise à la retraite de la seconde intercalaire, la communauté internationale a officiellement privilégié la stabilité mathématique des réseaux numériques au détriment d'un alignement strict sur la mécanique planétaire.

Implications en matière d'ingénierie : ce qui change pour les développeurs

Pour les programmeurs système, les architectes cloud et les administrateurs de bases de données, l'élimination progressive de la seconde intercalaire apporte des avantages substantiels à long terme :

  • Comportement d'horloge déterministe : Les environnements d'exécution de bas niveau et les noyaux de systèmes d'exploitation ne nécessiteront plus de routines de secours alambiquées conçues pour intercepter et avaler des 61e secondes inattendues.
  • Mécanismes de consensus robustes : Les bases de données distribuées qui s'appuient sur des horloges matérielles physiques synchronisées (telles que l'architecture TrueTime de Google Cloud Spanner) peuvent fonctionner avec des marges d'erreur nettement plus étroites, évitant ainsi les tampons d'incertitude artificielle requis auparavant pendant les fenêtres de secondes intercalaires.
  • Élimination des divergences d'étalement : Les charges de travail multi-cloud et les opérations financières interinstitutionnelles ne souffriront plus de dérives de synchronisation causées par des algorithmes d'étalement de secondes intercalaires non concordants entre des plateformes cloud concurrentes.
  • Implémentations de protocoles plus simples : Des protocoles tels que le Precision Time Protocol (PTP, IEEE 1588) et le NTP peuvent rationaliser la gestion de leurs indicateurs et le traitement des cas limites, réduisant ainsi la surface d'attaque pour les bogues de synchronisation.

En fin de compte, la suppression des ajustements imprévisibles rend le suivi du temps dans les logiciels beaucoup plus déterministe, éliminant une catégorie persistante de cas limites des tests d'intégration continue et des manuels opérationnels.

Naviguer vers l'horizon de la transition

Bien que la décision de supprimer la seconde intercalaire ait été formellement adoptée, les développeurs ne doivent pas encore abandonner leurs bonnes pratiques de synchronisation. La période de transition s'étend jusqu'en 2035, ce qui signifie que les systèmes doivent continuer à gérer correctement les événements intercalaires potentiels dans les années à venir si les conditions planétaires exigent un ajustement.

De plus, des décennies de logiciels hérités, de microgiciels embarqués propriétaires et de matériel de télécommunications dotés de tables de recherche de secondes intercalaires codées en dur existent toujours en production dans le monde entier. Mettre à niveau ou isoler ces systèmes avant que leurs hypothèses internes ne soient en contradiction avec la nouvelle norme exigera un audit rigoureux de la part des mainteneurs de systèmes. Les organisations dotées d'une infrastructure à long terme doivent s'assurer que leurs configurations de démons temporels, leurs noyaux de systèmes d'exploitation et leurs pipelines de télémétrie restent compatibles à mesure que la tolérance entre le temps atomique et le temps astronomique commence à s'élargir.

Ce qu'il faut retenir

La mise à la retraite de la seconde intercalaire est la reconnaissance claire qu'à l'ère moderne, la stabilité des logiciels et la synchronisation distribuée priment sur les excentricités mineures de la physique planétaire. En éliminant un mécanisme qui générait des pannes récurrentes pour un bénéfice astronomique marginal, les métrologistes ont résolu de manière permanente l'un des obstacles de synchronisation les plus étranges de l'informatique. Pour les développeurs du monde entier, le calendrier devient enfin un peu plus prévisible.

Source: wired.com