Dire que la sortie de macOS Catalina et d'iOS/iPadOS 13 n'a pas été un long fleuve tranquille relève d'un euphémisme. Si la première grosse mise à jour pour Catalina est en bêta-test (10.15.1) le nouveau système en a reçu une à titre intermédiaire. Apple prépare aussi la révision 13.2 de son système mobile qui succèdera aux quatre déjà distribuées en l'espace d'un mois !

iOS 13.0 n'était pas encore envoyé aux utilisateurs que la 13.1 était déjà annoncée avec un cortège de correctifs. Des fonctions et services comme le partage de dossiers sur iCloud, les routeurs compatibles HomeKit, le Secure Video pour les caméras domestiques, la mise à jour du HomePod ou la version de watchOS 6 pour les Series 1 et 2, manquent toujours à l'appel ou ont été remis à plus tard.

David Shayer, un ancien développeur d'Apple, avance dans un article sur TidBITS, quelques hypothèses pour expliquer cette situation. Aujourd'hui chez GoDaddy, hébergeur et gestionnaire de noms de domaine, il a passé en totalité 18 ans chez Apple, qu'il a quitté en 2015. Lors de sa deuxième période à Cupertino il a beaucoup travaillé sur les iPod et pendant les trois dernières années sur différents pans logiciels de watchOS.

Parmi les suggestions qu'il avance, certaines reflètent des situations qu'il a pu observer parmi ses collègues. Sa première piste d'explication est celle d'un calendrier de développement trop chargé et contraint par des délais rigides, certains imposés par l'activité matérielle :

Apple pourrait résoudre ce problème de planification en n'incluant pas autant de fonctionnalités dans chaque version, mais ce n'est tout simplement pas la culture de l'entreprise. Les produits ne faisant pas l’objet d’un calendrier de sortie défini, tels que les AirPods ou le fameux tag Bluetooth, peuvent être retardés jusqu’à ce qu’ils soient vraiment fiables. Toutefois, les produits dont le calendrier de sortie est annuel, comme les iPhone et les systèmes d’exploitation, doivent être lancés en septembre, quel que soit leur état.

David Shayer évoque au passage des situations où dans une équipe, personne ne veut admettre le premier que la partie d'une fonction dont il a la charge a pris du retard. Si aucun ne fait ce premier pas, tout le monde se tait, ces dysfonctionnements s'accumulent et la fonction finit par être repoussée.

Ensuite il peut y avoir ces bugs qui ne provoquent aucun plantage et n'entrainent donc pas l'affichage du rapport de crash que l'on peut envoyer à Apple :

Ça ne repèrera pas les photos qui ne sont jamais téléchargées sur iCloud ; la fiche de contact qui ne synchronise pas entre mon Mac et mon iPhone ; les sauvegardes sur une Time Capsule qui sont corrompues et doivent être redémarrées tous les quelques mois ; ni l'application de configuration de mon nouvel iPhone 11 qui est prise dans une boucle et qui me demande à plusieurs reprises de me connecter à mon compte iCloud.

On pourrait citer également le bug de l'assistant d'installation de Catalina qui ne comprenait pas que l'opération était terminée et refusait de rendre la main au système. Des bugs dont il est compliqué d'identifier l'origine pour les ingénieurs en qualité ou ceux qui collectent les retours d'utilisateurs sur les forums ou en Apple Store.

Plus on approche de la date de lancement des systèmes, plus les efforts se concentrent sur les bugs les plus sévères, plantogènes ou qui impliquent des pertes de données, continue David Shayer. Alors qu'au tout début du cycle des bêtas, tout est bon à apporter des corrections.

S'atteler à des problèmes plus mineurs c'est prendre le risque d'introduire d'autres bugs par inadvertance :

Les bugs générant beaucoup de visites en Apple Store ou d'appels au support technique sont généralement corrigés. Après tout, payer suffisamment de personnes pour aider de nombreux utilisateurs ça coûte très cher. Cela l'est beaucoup moins pour corriger ce bug. Lorsque je travaillais sur des produits Apple, nous avions une liste des principaux bugs qui généraient les visites en Apple Store et les appels au support technique, et nous devions les résoudre.

Malheureusement, les bugs plus rares ou moins graves, ceux qui provoquent surtout des incompréhensions chez l'utilisateur mais pas de pertes de données, ceux-là sont continuellement mis au second plan par le système de triage.

« Apple est feignante lorsqu'il s'agit de corriger de vieux bugs », observe l'ancien employé. Un bug touchant un tout nouveau produit, comme l'iPhone 11 en ce moment, sera promptement éradiqué, dit-il. Sinon c'est une toute autre histoire :

Vous vous souvenez de ce que j'ai dit à propos des changements causant de nouveaux bugs ? Si un ingénieur casse accidentellement une fonction, ça s’appelle une régression. Ils sont censés la réparer.

Mais si vous enregistrez un rapport de bug et que l’ingénieur en qualité détermine que ce bug existe également dans les versions précédentes du logiciel, il est identifié comme « pas de régression ». Par définition, ce n’est pas un nouveau bug, c’est un ancien bug. Il y a des chances alors que personne ne soit jamais affecté à sa résolution.

Tous les groupes chez Apple ne travaillent pas de cette manière, mais beaucoup le font. Ça me rendait dingue. Un groupe que j'ai connu chez Apple a même fabriqué des tee-shirts avec marqué « Pas une régression ». Si un bug n’est pas une régression, ils n’ont pas à le corriger. C’est pourquoi les problèmes de téléchargement de photos iCloud et le celui de la synchronisation de contacts que j’ai mentionnés peuvent ne jamais être rectifiés.

Un propos qui a fait réagir Peter Steinberger, cofondateur de l'éditeur de PSPDFKit, un moteur de gestion de fichiers PDF. Il se souvient d'une anecdote il y a quelques années, lors d'une WWDC. Il faisait état devant des ingénieurs d'Apple de bugs toujours existants, et on lui avait répondu : « Pourquoi ça vous embête ? Puisque vous avez déjà trouvé un moyen pour le contourner ? ».

Plus loin dans son article, David Shayer regrette qu'Apple n'utilise pas davantage des batteries de tests automatisés pour déceler des problèmes. Il cite des exceptions comme des tests automatiques menés quotidiennement pour étudier l'impact du système sur les batteries des iPhone, avec comme réserve le fait que n'est observé apparemment que le code produit par Apple. Ce qui écarte pas mal de scénarios avec des logiciels tiers. Ou encore l'équipe Safari qui fait grand usage de ces évaluations automatiques pour déterminer tout ce qui peut ralentir le navigateur.

Enfin, il y a le fait que l'écosystème d'Apple ne cesse de se complexifier avec plus de systèmes et de matériels, des interdépendances permanentes à tous les niveaux :

Les produits Apple actuels sont beaucoup plus complexes que par le passé, ce qui rend le développement et les tests plus difficiles. La matrice de test ne comporte pas simplement plus de lignes (pour les fonctionnalités et les versions de système d'exploitation), elle a également plus de dimensions (pour tous les produits compatibles avec lesquels elle doit être utilisée).

Pire, des événements asynchrones tels que plusieurs tâches s'exécutant sur plusieurs cœurs ; des notifications push et une latence du réseau font qu'il est pratiquement impossible de créer une suite de tests complète.

Il n'y a pas de solution simple à ce qui est un problème en constante évolution, mais l'ancien ingénieur d'Apple espère voir des correctifs sortir à un rythme plus élevé. Ne serait-ce que parce qu'en laissant cette situation inchangée, cela finit par se payer en termes de coût en support technique et en image pour Apple.