Un bogue d'une milliseconde a paralysé le trafic aérien britannique. Six heures.

Ce que couvre cette vidéo

• 10:00 : une requête, interrompue dans une fenêtre de 1 ms
• Chronologie : 10:00 squawk → 10:02 blip → 12:45 arrêts des départs → 13:32 lien perdu
• Le remède : redémarrer les données de vol de tout le pays
• Mécanisme : mis en pause à mi-chemin d'une écriture
• Pourquoi une fonction de sécurité a arrêté le ciel

Transcription traduite

Traduit de la narration originale en anglais. L'audio et les sous-titres disponibles sont gérés par YouTube.

10:00 : une requête, interrompue dans une fenêtre de 1 ms

0:00 À dix heures du matin, une demande de routine dans le système de données de vol de la Grande-Bretagne est interrompue à la milliseconde exactement erronée, et le soir, plus de deux mille vols sont retardés, annulés ou déroutés. C'est d'après le rapport préliminaire de Nats, le service de contrôle aérien du Royaume-Uni. Aucun signe d'attaque, et personne n'a appuyé sur le mauvais bouton. Juste un défaut hérité, et une milliseconde très spécifique. Comment cela s'est produit, pourquoi une milliseconde a suffi, et qui est réellement à blâmer. Ceci est The Daily Diff, postmortem.

0:31 Dix heures. Quelqu'un demande manuellement un code squawk, le numéro à quatre chiffres qui

Chronologie : 10:00 squawk → 10:02 blip → 12:45 arrêts des départs → 13:32 lien perdu

0:36 lie un blip radar à son plan de vol. La demande est valide, tout comme le plan. Dix heures deux. La liaison entre le contrôle de la zone de Londres et le système central se coupe, puis revient d'elle-même après quarante-cinq secondes. Le ticket indique récupéré, stable, pas d'impact opérationnel. Douze heures trente-deux. La liaison commence à se couper à nouveau, plus rapidement à chaque fois, et les contrôleurs perdent une partie de l'automatisation.

0:56 À douze heures quarante-cinq, les départs du Royaume-Uni sont arrêtés. À une heure trente-deux, la liaison se coupe et reste coupée. Le remède est un redémarrage contrôlé, et c'est la partie coûteuse,

Le remède : redémarrer les données de vol de tout le pays

1:06 car le même système alimente les centres de contrôle et les aéroports à travers le pays. Le bogue se trouve dans l'espace aérien de Londres. Les restrictions couvrent l'ensemble du Royaume-Uni. Le redémarrage s'effectue de trois heures quinze à quatre heures dix, et le démêlage des plans de vol en double prend jusqu'à six heures cinquante. Alors pourquoi une milliseconde a-t-elle suffi ?

Mécanisme : mis en pause à mi-chemin d'une écriture

1:23 Le système gère les tâches par priorité, et mettre en pause une petite tâche pour une tâche urgente est normal. Mais cette tâche était en cours de mise à jour d'une valeur. Le message urgent arrive pendant cette milliseconde, et la mise à jour s'arrête à mi-chemin. Lorsqu'elle reprend, elle ne reprend pas correctement. Les données erronées se répandent ensuite dans certaines des mises à jour de vol ultérieures.

Pourquoi une fonction de sécurité a arrêté le ciel

1:40 Londres essaie d'en lire une, prend trop de temps et expire. Un délai d'expiration coupe la liaison, comme prévu, pour protéger les deux systèmes. La fonction de sécurité fonctionne parfaitement. C'est ça le problème. Les propres mots du rapport. Si le message urgent était arrivé une milliseconde plus tôt ou plus tard, la mise à jour se serait terminée normalement. Sur Hacker News, un programmeur appelle une milliseconde une éternité absolue,

2:02 garantie d'arriver d'ici mardi de cette semaine. C'était un mardi.

git blame — code hérité 50 · plan de redémarrage 30 · l'alarme de 10:02 15 · 1 ms 5

2:05 git blame. Le code hérité, cinquante pour cent, pour une mise à jour qui peut être mise en pause à mi-chemin et qui revient de manière incorrecte. Le plan de redémarrage, trente, parce qu'un enregistrement erroné à Londres signifie redémarrer les données de vol de tout le pays. L'alarme de dix heures deux, quinze, pour s'être réparée elle-même et avoir été classée sans impact. Cinq pour cent à la milliseconde, pour son timing. Rayon d'action. Nats avait prévu environ huit mille vols ce jour-là et en a traité

Rayon d'action : 8 000 prévus, 6 094 traités, troisième panne en trois ans

2:27 environ six mille. Les départs du Royaume-Uni ont été interrompus pendant environ quatre heures et demie, et le retard a pris plus de deux jours à être résorbé. C'est la troisième panne de trafic aérien de la Grande-Bretagne en trois ans, et le PDG qualifie ce bogue de très, très obscur.

Verdict + la ligne du lundi : écritures atomiques, alarmes sonores

2:41 Verdict, postmortem : NEEDS REVIEW. Le rapport est rapide et spécifique, et le correctif est rédigé et en test. Mais le plan est un redémarrage plus rapide, pas un plus petit. Ligne du lundi : si une tâche peut être mise en pause, rendre son écriture atomique, et traiter une alarme qui se répare d'elle-même comme une alarme. Envoyez-moi l'incident dont vous n'êtes toujours pas autorisé à parler, dans les commentaires, ou à thedailydiff.dev. Et c'est le diff pour aujourd'hui.

3:02 Je suis Niko d'Axrisi. SHIP IT.

Sources

1. NATS, Major Incident Preliminary Investigation Report, NAS incident 08 September 2026 (report date Sep 16)www.nats.aero
2. NATS press release, "NATS publishes preliminary report on technical incident of 8 September" (Sep 18, 2026)www.nats.aero
3. NATS on X, 8 Sepx.com
4. BBC, "Flight chaos caused by 'millisecond' software defect, report says"www.bbc.co.uk
5. The Guardian (Sep 18, 2026)www.theguardian.com
6. Hacker News thread on the reportnews.ycombinator.com