Apple ferme arbitrairement des rapports de bugs si l’utilisateur ne confirme pas lui-même que le problème n’est pas corrigé

• Apple clôt automatiquement des bugs signalés via Feedback Assistant si l’utilisateur ne vérifie pas lui-même que le problème « n’est toujours pas corrigé »
• Concernant un bug de fuite de données personnelles lié à une extension de filtre réseau (FB12088655) resté sans réponse pendant 3 ans, Apple a soudainement demandé une vérification et indiqué qu’en l’absence de réponse sous 2 semaines, le bug serait considéré comme corrigé
• Pourtant, les développeurs de Little Snitch ont confirmé que le même problème persistait sur les dernières versions de macOS, mais Apple a tout de même fermé le rapport
• Cette procédure fonctionne comme une structure qui réduit artificiellement le nombre de rapports de bugs, avec pour effet de masquer les véritables problèmes de qualité
• En conséquence, la méthode de gestion des bugs d’Apple affaiblit la confiance des développeurs et nuit à une culture de feedback collaborative

---

Le problème de fermeture automatique des rapports de bugs chez Apple

• Un développeur ayant signalé un bug via Apple Feedback Assistant critique la pratique d’Apple consistant à fermer des rapports sans validation réelle de l’utilisateur
  • Apple ferme automatiquement un rapport si l’utilisateur ne confirme pas lui-même que « le bug n’est toujours pas corrigé »
  • Après plusieurs années sans réponse, Apple envoie soudainement une demande de vérification et considère le problème comme « corrigé » si aucune réponse n’arrive sous 2 semaines
• Dans le cas de FB12088655 « Privacy: Network filter extension TCP connection and IP address leak », soumis en mars 2023, Apple n’a donné aucune réponse pendant 3 ans, puis a demandé en mars 2026 une vérification sur macOS 26.4 beta 4
  • Il était difficile de vérifier car l’OS bêta n’était pas installé en permanence, et malgré une demande adressée à Apple pour savoir si le bug avait été corrigé, aucune réponse claire n’a été fournie
  • Apple a indiqué que « si aucune vérification n’était faite sous 2 semaines, le problème serait considéré comme corrigé et le rapport fermé »
  • Les développeurs de Little Snitch ont signalé que le même problème était reproductible sur macOS 26.4 beta 4
  • Le même bug était également toujours présent dans la version finale de macOS 26.4
• Le fait qu’Apple exige une vérification directe de l’utilisateur pour un bug non corrigé est décrit comme une procédure inefficace et déraisonnable
  • Il est évoqué qu’en interne, une structure d’incitation visant à réduire le nombre de rapports de bugs pourrait être à l’œuvre
  • Cela réduit le nombre de « bugs ouverts » et donne, dans les indicateurs internes, l’impression que la qualité s’améliore

Autres cas de rapports de bugs

• Un autre exemple cité est le bug FB22057274 « Pinned tabs: slow-loading target="_blank" links appear in the wrong tab »
  • Bien que le problème soit reproductible à 100 %, Apple l’a marqué comme « Investigation complete - Unable to diagnose with current information »
  • Des informations supplémentaires ont été demandées le 9 mars, mais Apple n’a pas répondu
• Dans la bêta d’iPadOS 26.4, un bug de plantage de Safari est également apparu, et Apple ne l’a pas corrigé avant la sortie de la version publique
  • L’auteur critique la situation en affirmant que « le but de la bêta ne semble pas être de corriger des bugs, mais d’ennuyer ceux qui les signalent »

Évolutions après Hacker News et réponse d’Apple

• Juste après que cet article est arrivé en première page de Hacker News, Apple a mis à jour le rapport FB22057274
  • Apple a demandé l’envoi de journaux sysdiagnose pour un problème d’interface
  • L’auteur souligne qu’il avait déjà fourni les étapes de reproduction et une capture vidéo de l’écran, et que sysdiagnose représente un risque pour la vie privée tout en étant inutile dans ce cas
• L’auteur a répondu à la demande d’Apple de la manière suivante
  • « Pour un bug d’interface, sysdiagnose n’est pas nécessaire et n’aide pas »
  • Il propose une méthode reproductible sans Little Snitch : utiliser Network Link Conditioner dans les Xcode Additional Tools et régler le profil de latence montante sur 3000 ms pour reproduire le même comportement

Informations sur Xcode Additional Tools

• Les Xcode Additional Tools comprennent plusieurs utilitaires utiles et peuvent être téléchargés depuis la page Apple Developer Downloads (connexion requise)

Évaluation globale

• La méthode de gestion des rapports de bugs d’Apple impose une charge inutile aux développeurs et semble fonctionner selon une logique davantage centrée sur la baisse du nombre de rapports que sur la résolution effective des problèmes
• Les rapports laissés longtemps sans réponse, les demandes de vérification déraisonnables et les requêtes d’informations inefficaces affaiblissent la confiance des développeurs et leur volonté de coopération

[GN⁺]

Avis sur Hacker News

• L’auteur n’a probablement jamais eu affaire à un logiciel d’entreprise
  Quand un développeur reçoit un bug report, la technique classique pour gagner du temps sans rien faire, c’est de dire : « Je n’arrive pas à le reproduire, vous avez vérifié sur la dernière version ? »
  S’il ne peut pas le vérifier, il le ferme en disant « erreur utilisateur » ou « impossible à reproduire »
  La seule parade, c’est de répondre « oui, j’ai vérifié » alors qu’en réalité on ne l’a pas fait

  • J’ai déjà utilisé le support payant de Microsoft, et ils demandent toujours des preuves
    S’ils voient un antivirus dans les logs, ils ferment aussitôt en disant « voyez ça avec eux »
  • Vu de l’intérieur, c’est moins de la malveillance qu’un problème de rentabilité/coût
    Il y a souvent des priorités business plus importantes qu’un bug signalé par un seul utilisateur
    Mais du point de vue de l’utilisateur, ça reste regrettable
  • Dans l’open source, c’est pareil. stalebot ferme automatiquement les anciennes issues
  • J’ai appris à faire de bons GIFs de reproduction qu’on peut insérer directement dans un e-mail
    La plupart des développeurs ne savent pas tester leur propre produit, ou n’en ont pas envie
  • J’ai connu les deux côtés
    Quand je faisais du support technique enterprise, je devais ouvrir au moins deux nouveaux dossiers par jour et en gérer plus de 20 en parallèle
    La sensation de soulagement quand on fermait un dossier sans aucun progrès comme « clôture pour inactivité » était énorme
    Plus tard, une règle a imposé de contacter le client trois fois avant fermeture, et c’était un cauchemar
    Au final, la bureaucratie des grandes entreprises ruine tout

• Apple donne l’impression d’espérer que les bugs disparaissent d’eux-mêmes
  Moi aussi, je ne signale plus de bugs maintenant
  Être ignoré ne me dérange pas tant que ça, le vrai problème c’est quand ils me traitent comme de la main-d’œuvre QA non rémunérée
  Ils exigent énormément d’efforts pour prouver qu’un bug existe

  • Microsoft fait pareil, surtout sur les problèmes liés à Azure ou à 365
    L’idée, c’est : « c’est ton logiciel, donc à toi de le déboguer »

• Les projets open source font pareil avec la fermeture automatique des issues obsolètes
  Considérer automatiquement qu’un problème est résolu au bout d’un certain temps n’a aucun sens

  • Du point de vue des mainteneurs, les priorités peuvent être différentes
    L’avantage de l’open source, c’est qu’on peut corriger soi-même, soumettre une PR, ou fork le projet pour résoudre le problème
  • Que stalebot n’ajoute qu’un label stale au lieu de fermer l’issue, ça me paraît acceptable
    Filtrer les vieux tickets est plus raisonnable

• C’est agaçant côté utilisateur, mais tous les bugs ne sont pas faciles à reproduire
  Parfois, après une modification du code concerné, il est plus efficace de demander à l’utilisateur de retester
  Malgré tout, fermer de vieux bugs non exécutables met mal à l’aise

  • J’ai autrefois travaillé sur l’intégration de Mac à ActiveDirectory, et la réponse habituelle d’Apple était : « works on 17! »
    Autrement dit, le problème n’était pas reproductible uniquement sur le réseau interne d’Apple
  • Certains disent : « pourquoi ne pas simplement laisser le ticket ouvert ? »
    Le fermer ne fait que masquer le problème, et garder un ticket ouvert ne coûte rien
  • Apple ne dit ni « impossible à reproduire » ni « corrigé », mais seulement « vérifiez sur macOS 26.4 beta 4 »
    Exiger l’installation d’une bêta est bien plus inefficace pour l’utilisateur
    J’avais pourtant fourni un projet d’exemple Xcode ainsi que les étapes de reproduction
    Je suis convaincu qu’Apple n’a rien fait du tout
    On dirait sans doute une opération de nettoyage des bugs avant la préparation de macOS 27 pour la WWDC
  • Une entreprise comme Apple devrait avoir des outils capables de capturer parfaitement l’état du système pour reproduire un problème

• Quand je travaillais chez Facebook et Google, j’ai vu beaucoup de petites combines de gestion des bugs
  Après l’introduction des SLA, on abaissait artificiellement la priorité des bugs, ou on les renvoyait au client avec un « le problème existe-t-il toujours ? »
  Après un certain temps, on les fermait en disant que « la version est obsolète »
  On allait même parfois jusqu’à les fusionner de force avec d’autres bugs pour éviter d’en porter la responsabilité
  Au fond, tout cela vient des indicateurs de performance de l’organisation (SLA)
  Résultat, je fais désormais très peu de bug reports

  • En réalité, les ingénieurs veulent corriger les bugs
    Mais la direction leur dit : « concentrez-vous sur les projets IA pour l’instant »
    Puis elle les réprimande parce qu’« il y a trop de bugs »
  • Moi aussi, j’ai déjà rétrogradé des p2/s2 en p3/s3
    Je trouvais plus honnête de simplement les ignorer plutôt que de les fermer
    Le leadership encourageait ce type de triage forcé
    Bloquer les notifications automatiques est un vrai problème
  • La distinction entre priorité (priority) et gravité (severity) existe parce que, par exemple, même si un site est totalement hors service, ce n’est pas forcément un P0 si on est en basse saison
    Mais en pratique, la qualité des données est trop faible pour un usage de reporting
    C’est pourquoi une valeur de priorité unique est souvent plus utile
    stalebot finit par fermer à la place ces issues ignorées
  • C’était pareil dans la grande entreprise où j’ai travaillé
    On gérait séparément la severity côté client et la priority en interne
    Salesforce « Lightning Experience », malgré son nom, est très lent
    Les outils internes étaient bien plus rapides et efficaces
  • Tout cela est un exemple typique de problème principal-agent (principal-agent problem)

• La même chose est arrivée chez ElevenLabs
  Quand on soumet un bug report, une IA répond automatiquement, puis le ticket passe en stale au bout de 48 heures

  • Un employé d’ElevenLabs est intervenu pour préciser que si on soumet le problème dans le dépôt open source GitHub, un humain répond directement

• Bientôt, des agents LLM régleront probablement ce problème
  Ils pourront commenter automatiquement « ce bug n’est toujours pas corrigé » et le remonter automatiquement à intervalles réguliers en disant « cela affecte un workflow important »

  • Si un mainteneur ferme malgré tout l’issue, l’agent pourrait même publier automatiquement un billet de blog critique

• J’avais soumis un bug à Microsoft, et quelques mois plus tard on m’a répondu « impossible à reproduire »
  En réalité, le problème avait été résolu indirectement par un autre correctif entre-temps
  J’ai compris que j’étais comme un aveugle touchant seulement une partie de l’éléphant

• Je suis un ancien employé d’Apple
  Le bug tracker interne d’Apple s’appelle Radar, et toutes les issues doivent passer par une étape « Verify » avant de pouvoir être fermées
  En apparence, cela ressemble à une procédure d’assurance qualité, mais en pratique d’innombrables Radar restent bloqués pour toujours à l’état Verify
  Les équipes étant évaluées sur le « nombre de Radar non vérifiés », elles finissent par les fermer de force après un certain délai

  • La plupart des équipes utilisent en pratique Verify comme si c’était l’état Closed
    L’illusion du « zéro bug » produit des indicateurs de performance biaisés
  • La solution serait aussi d’évaluer le « nombre de bugs rouverts »
  • Le message de Feedback Assistant disant de « vérifier sur la dernière bêta » est distinct de l’état Verify dans Radar
    Cela ne signifie pas forcément qu’un ingénieur Apple a réellement tenté de corriger le problème

• Dans mon entreprise, avec mes collègues, on faisait des réunions de nettoyage du backlog
  On y triait les vieux bugs ponctuels
  Ce genre de processus est très courant