Votre Mac a bien un bug après 49 jours
mais ce n’est pas une « date d’expiration » au sens strict.
Le bug est réel, reproductible et techniquement documenté. En revanche, il faut corriger deux raccourcis fréquents : tous les Mac ne tombent pas brutalement en panne à la 49e journée, et la machine n’« expire » pas. C’est la gestion du temps dans la pile TCP qui se bloque, ce qui finit par empêcher l’ouverture de nouvelles connexions réseau.
La découverte de Photon : un bug rare, mais parfaitement reproductible
Le bug a été mis en évidence au printemps 2026 par Photon, une société qui exploite notamment des Mac dans une infrastructure de surveillance d’iMessage. Ces machines fonctionnaient en continu pendant de longues périodes, un scénario beaucoup plus proche d’un serveur que de l’usage habituel d’un MacBook personnel.
Photon a constaté que plusieurs machines cessaient d’établir de nouvelles connexions réseau après exactement la même durée d’activité : 49 jours, 17 heures, 2 minutes et 47 secondes. La répétition du phénomène à un intervalle aussi précis a rapidement orienté les ingénieurs vers un compteur numérique.
Le point remarquable est que la machine ne s’éteint pas et ne « plante » pas forcément. Certaines connexions déjà établies continuent de fonctionner et le ping peut encore répondre. C’est la création de nouvelles connexions TCP qui se dégrade progressivement.
Photon a ensuite reproduit le problème et étudié le code source public du noyau XNU d’Apple. L’analyse a conduit à une variable interne nommée tcp_now, utilisée comme référence temporelle dans plusieurs mécanismes de la pile TCP.
Cette découverte a été reprise par plusieurs médias techniques au mois d’avril, notamment Macworld, Tom’s Hardware et MacGeneration. Le mécanisme général décrit par Photon est cohérent avec la structure du code XNU public où tcp_now apparaît bien comme un entier non signé sur 32 bits.
Le titre original parlant de « date d’expiration cachée » fonctionnait comme image journalistique. Techniquement, il est plus exact de parler d’un débordement de compteur après une durée d’uptime précise, et non d’une date inscrite dans le système.
Le mécanisme technique expliqué sans exagération
Le cœur du problème se trouve dans la manière dont macOS suit le temps pour certaines opérations TCP. Le noyau XNU utilise un compteur nommé tcp_now, défini sur 32 bits non signés et exprimé en millisecondes.
Un entier non signé sur 32 bits peut stocker des valeurs comprises entre 0 et 4 294 967 295. Lorsqu’on compte une milliseconde à la fois, cette valeur maximale est atteinte au bout d’environ 49,7 jours.
En théorie, un compteur qui déborde repart simplement de zéro. Le problème décrit par Photon vient d’une logique supplémentaire destinée à garantir la progression monotone du temps. Lorsque la valeur revient à zéro, cette protection interprète le nouveau nombre comme inférieur au précédent et le compteur peut alors se figer au lieu de poursuivre normalement après le débordement.
Cette horloge interne est utilisée pour gérer différentes temporisations TCP, notamment l’expiration des connexions placées dans l’état TIME_WAIT. Cet état est normal : après la fermeture d’une connexion TCP, le système conserve temporairement certaines informations avant de libérer complètement les ressources associées.
Si le temps TCP ne progresse plus correctement, les entrées en TIME_WAIT peuvent ne plus être nettoyées comme prévu. Les ports éphémères utilisés pour ouvrir de nouvelles connexions s’accumulent alors progressivement jusqu’à épuisement.
Le résultat final est trompeur : l’interface réseau fonctionne toujours, le Wi-Fi peut rester connecté, le routeur est accessible et certaines connexions existantes persistent. Pourtant, Safari, un client API ou une application peuvent devenir incapables d’ouvrir une nouvelle session TCP.
En résumé
Le compteur atteint sa limite.
Il revient théoriquement à zéro.
Une logique de contrôle empêche sa progression normale.
Les temporisations TCP cessent de fonctionner correctement.
Les nouvelles connexions finissent par échouer.
Ce qui se passe réellement après 49,7 jours
Le raccourci « Internet tombe exactement à la 49e journée » est trop brutal. Le compteur atteint bien sa limite à ce moment précis, mais l’épuisement des ports peut prendre un certain temps selon l’activité réseau de la machine.
Un Mac qui ouvre et ferme énormément de connexions TCP peut rencontrer les symptômes plus rapidement après le débordement qu’une machine presque inactive. C’est pourquoi le contexte d’utilisation compte autant que la durée d’uptime.
Les signes peuvent inclure des pages qui ne chargent plus, des API qui échouent, des outils cloud qui cessent de se synchroniser, des connexions SSH impossibles ou certaines applications qui semblent hors ligne alors que le Mac reste connecté au réseau local.
Le ping constitue justement l’un des pièges du diagnostic. ICMP n’utilise pas TCP ; il peut donc continuer à répondre. Un administrateur peut alors croire que « le réseau fonctionne » et chercher du côté du DNS, du pare-feu, du VPN ou du fournisseur d’accès.
Les connexions TCP déjà ouvertes peuvent elles aussi continuer à vivre. Ce mélange de services fonctionnels et de services défaillants rend le problème particulièrement déroutant.
Pour un Mac utilisé normalement, la probabilité d’atteindre ce seuil reste relativement faible. Les mises à jour, redémarrages ou arrêts complets interrompent généralement l’uptime bien avant 49 jours. Le bug devient beaucoup plus pertinent pour les Mac mini utilisés comme serveurs, les machines de build, les postes de production continue et les infrastructures automatisées.
Quels Mac sont réellement concernés ?
Photon a décrit le phénomène sur des Mac modernes fonctionnant plusieurs semaines en continu. Les articles publiés après la découverte ont parfois généralisé le problème à « tous les Mac », mais cette formulation mérite d’être nuancée.
Le mécanisme repose sur le noyau XNU et sur la pile TCP de macOS, pas sur un modèle particulier de processeur. Cela explique pourquoi il n’est pas limité aux Mac Intel ou aux Mac Apple Silicon. En revanche, la présence exacte du comportement peut varier selon la version du noyau et donc de macOS.
Des administrateurs ont d’ailleurs signalé des Mac anciens affichant des uptimes largement supérieurs à 49 jours sans panne comparable. Cela suggère que toutes les versions historiques de macOS ne sont pas touchées de la même manière.
Le contexte le plus exposé reste celui d’une machine moderne utilisée comme infrastructure : Mac mini en serveur, station de rendu, build machine, système de supervision, machine dédiée à Home Assistant, CI/CD ou poste servant d’hôte permanent à des automatisations.
Un MacBook utilisé quotidiennement est moins susceptible d’atteindre 49,7 jours d’uptime réel, surtout s’il redémarre lors des mises à jour. La simple mise en veille ne doit toutefois pas être confondue avec un redémarrage complet : elle ne remet pas nécessairement tous les compteurs du noyau à zéro.
La meilleure manière de connaître l’uptime est d’utiliser la commande système uptime dans Terminal. Elle permet de savoir depuis combien de temps la machine fonctionne depuis son dernier démarrage.
Apple a-t-il corrigé le bug depuis avril 2026 ?
C’est le point qui devait impérativement être réactualisé. Depuis avril, Apple a publié plusieurs versions de macOS Tahoe : 26.5, 26.5.2, 26.6, 26.6.1 et 26.6.2. Ces mises à jour corrigent de nombreux bugs, problèmes de sécurité et incidents réseau.
Au 8 septembre 2026, les notes publiques d’Apple que nous avons pu vérifier ne mentionnent cependant pas explicitement le bug tcp_now, le seuil des 49,7 jours ou le débordement TCP décrit par Photon.
Cette absence ne permet pas d’affirmer que le code n’a pas changé. Apple corrige régulièrement des comportements dans macOS sans détailler chaque modification dans ses notes destinées au grand public. Mais elle empêche d’écrire honnêtement que « le bug est corrigé » sans autre preuve.
À l’inverse, il serait également trop affirmatif de dire qu’Apple « n’a rien fait ». Les versions 26.6 et 26.6.2 comportent des corrections de noyau, de réseau et de sécurité, mais aucune documentation publique consultée ne relie clairement ces changements à ce problème précis.
La formulation la plus rigoureuse en septembre 2026 est donc : aucun correctif explicitement documenté par Apple pour ce bug précis n’a été identifié. Si la machine joue un rôle critique et reste allumée plus de plusieurs semaines, le redémarrage préventif reste la mesure la plus simple tant que l’absence du problème n’a pas été confirmée sur la version utilisée.
Ce type de silence documentaire n’est pas exceptionnel. Apple publie surtout le détail des correctifs de sécurité lorsqu’ils sont associés à des vulnérabilités ou des CVE. Un bug fonctionnel du réseau peut être corrigé sans recevoir une entrée dédiée.
Pourquoi cela rappelle le bug de l’an 2000, sans être le même problème
Le bug de l’an 2000
De nombreux logiciels stockaient l’année sur deux chiffres. Le passage de 99 à 00 pouvait être interprété comme 1900 au lieu de 2000. Le problème venait donc d’une représentation trop courte du temps.
Le seuil de 49,7 jours
Ici, le problème vient d’un entier 32 bits utilisé pour compter des millisecondes. Le parallèle est pertinent parce qu’une limite numérique finit par devenir un événement réel dans le système.
Windows 95 et 98
Ces systèmes ont connu un problème célèbre lié à un compteur de millisecondes atteignant lui aussi sa limite après environ 49,7 jours.
Le bug de 2038
Certains anciens systèmes Unix utilisant un entier signé 32 bits pour le temps Unix atteindront leur limite le 19 janvier 2038.
La leçon est toujours la même : même sur des machines 64 bits extrêmement modernes, des structures internes héritées ou volontairement limitées peuvent rester codées sur 32 bits. L’architecture générale du processeur ne garantit pas que chaque compteur utilisé dans le système soit lui-même sur 64 bits.
Cette catégorie de bugs rappelle également que les systèmes modernes restent vulnérables à des erreurs très simples. Microsoft a lui aussi corrigé un bug notable de Windows en 2026, preuve que la sophistication d’un système n’élimine pas les problèmes de logique élémentaire.
La solution pratique : simple, mais à appliquer au bon moment
La mesure la plus simple reste le redémarrage complet. Un reboot réinitialise le compteur et restaure la gestion normale des connexions TCP.
Pour un Mac personnel, il n’est pas nécessaire de créer une routine obsessionnelle : la plupart des utilisateurs redémarrent suffisamment souvent lors des mises à jour ou à l’occasion d’un arrêt volontaire.
Pour un Mac utilisé comme serveur ou machine permanente, une politique de redémarrage mensuel place la machine très loin du seuil. Dans un environnement professionnel, cette opération peut être planifiée pendant une fenêtre de maintenance.
En cas de panne réseau inexpliquée sur une machine ayant plusieurs semaines d’uptime, le redémarrage constitue aussi un test de diagnostic utile avant d’investiguer longuement le routeur, le VPN ou le DNS.
Il faut toutefois éviter de présenter le reboot comme un « patch ». Il contourne le problème en remettant le compteur à zéro ; il ne modifie pas le code du noyau. La machine recommence donc un nouveau cycle.
Cette situation rappelle un autre incident Apple analysé par WY-Créations : l’expiration d’un certificat Logitech qui avait rendu certains accessoires inutilisables sur Mac. Dans les deux cas, une dépendance logicielle invisible peut produire une panne disproportionnée.
Pourquoi les agents IA rendent ce bug plus intéressant en 2026
La découverte de Photon est particulièrement intéressante parce qu’elle vient précisément d’une infrastructure exploitant des Mac en permanence pour des usages automatisés. Or cette catégorie de machines devient plus fréquente avec les agents IA.
Un agent local peut effectuer des tâches pendant plusieurs jours ou semaines : surveillance d’e-mails, génération de code, interaction avec des API, automatisation de fichiers, exécution de navigateurs ou communication avec des services distants. Tous ces usages reposent massivement sur le réseau.
Une machine qui héberge ce type d’agent cumule donc les deux facteurs favorables au bug : un uptime très long et un volume élevé de connexions TCP courtes. Cela ne signifie pas que l’IA provoque le problème ; elle rend simplement le scénario d’exploitation permanent plus courant.
Apple développe lui-même de nouveaux usages d’assistance intelligente, tandis que les outils concurrents multiplient les workflows agents. Le rôle du Mac comme machine toujours disponible pourrait donc prendre davantage d’importance.
Perplexity et les autres acteurs de l’IA développent eux aussi des systèmes connectés en permanence à des services externes. Plus les logiciels deviennent autonomes, plus la stabilité du système hôte devient un sujet opérationnel.
Apple investit parallèlement dans la sécurité, avec notamment des programmes de récompenses pouvant atteindre plusieurs millions de dollars. Le bug des 49 jours n’est pas nécessairement une vulnérabilité exploitable, mais il rappelle que fiabilité et sécurité restent deux dimensions distinctes.
Enfin, la persistance d’anciens composants dans l’écosystème Apple montre aussi à quel point les logiciels modernes reposent encore sur des couches historiques. Le défi n’est pas seulement d’ajouter de nouvelles fonctions : il faut maintenir des décennies de code et de compatibilité.
Ce qu’on nous demande le plus souvent.
Un Mac tombe-t-il forcément en panne après 49 jours ?
Non. Le compteur concerné atteint sa limite après 49 jours, 17 heures, 2 minutes et 47 secondes, mais les symptômes dépendent ensuite de l’activité TCP et de l’épuisement progressif des ressources réseau.
Pourquoi 49,7 jours exactement ?
Parce que le compteur utilise un entier non signé sur 32 bits exprimé en millisecondes. 2 puissance 32 millisecondes correspondent à environ 49,7 jours.
Le Wi-Fi s’arrête-t-il de fonctionner ?
Pas nécessairement. L’interface réseau peut rester connectée, le ping peut répondre et des connexions déjà ouvertes continuer à fonctionner. Ce sont surtout les nouvelles connexions TCP qui finissent par échouer.
Quels Mac sont les plus concernés ?
Les machines qui restent allumées plusieurs semaines sans redémarrage : Mac mini utilisés comme serveurs, postes de build, infrastructures automatisées, machines de supervision ou systèmes exécutant des agents en permanence.
Apple a-t-il corrigé le problème ?
Au 8 septembre 2026, nous n’avons trouvé aucune note Apple confirmant explicitement un correctif pour ce bug précis. Plusieurs mises à jour de macOS Tahoe ont été publiées depuis avril, mais leurs notes publiques ne mentionnent pas le débordement tcp_now.
Un simple redémarrage suffit-il ?
Oui pour restaurer le fonctionnement normal, car il remet le compteur à zéro. Ce n’est toutefois pas un correctif définitif : une machine laissée à nouveau en fonctionnement continu peut recommencer le même cycle.
La mise en veille remet-elle le compteur à zéro ?
Non. Une mise en veille n’équivaut pas à un redémarrage complet. Pour être certain de réinitialiser l’uptime et les compteurs du noyau, il faut redémarrer le Mac.
Pourquoi compare-t-on ce bug à l’an 2000 ?
Parce que les deux problèmes viennent d’une représentation numérique insuffisante du temps. Le mécanisme exact est différent, mais le principe est similaire : une limite de format finit par provoquer un comportement inattendu.
- Photon — analyse technique du bug TCP après 49,7 jours — site Photon
- Macworld — analyse du bug macOS des 49 jours, avril 2026
- Tom’s Hardware — analyse technique du débordement TCP
- Apple — mises à jour de macOS Tahoe 26
- Apple Open Source — code source public du noyau XNU
- Apple — contenu de sécurité de macOS Tahoe 26.6
- Apple — contenu de sécurité de macOS Tahoe 26.6.2
WY-Créations suit les évolutions de macOS, de la cybersécurité et des infrastructures numériques en distinguant les comportements techniquement documentés des correctifs réellement confirmés. Retrouvez toutes les actualités web et les avis clients WY-Créations.
Un Mac peut fonctionner parfaitement pendant des semaines avant qu’un compteur interne ne devienne le problème.
Sur les machines utilisées en continu, la maintenance préventive reste aussi importante que les performances.