L'équipe en charge du contrôle qualité d'iOS doit être dans ses petits souliers à l'heure qu'il est, suite à la débâcle d'iOS 8.0.1 qui a transformé l'iPhone 6 en iPod touch de luxe (fort heureusement, iOS 8.0.2 a corrigé ces vilains bugs un peu plus de 24 heures après). Un homme en particulier sent peut-être le souffle chaud de l'opprobre sur sa nuque : Josh Williams. Il est en effet en charge de superviser les mises à jour du système d'exploitation…

Il était aussi responsable du contrôle qualité logiciel lors de la sortie de Plans en 2012, avec le résultat que l'on sait : erreurs en pagaille, cartes fantaisistes, réputation (d'Apple et de l'application) fortement entachée. La polémique qui s'était ensuivie avait poussé Tim Cook à se séparer de Scott Forstall, le grand patron d'iOS à l'époque, et à réorganiser les différentes branches de l'entreprise.

Difficile de savoir si son avenir chez Apple est compromis, car on ignore ce qui a provoqué les bugs dans iOS 8.0.1. Ce dernier a été installé par 40 000 personnes avant son retrait, dixit Apple. L'homme est entré chez Apple en 2000, et il travaille sur le contrôle qualité du logiciel de l'iPhone depuis les tout débuts du smartphone. Il a sous sa coupe une centaine de personnes à travers le monde qui doivent passer au tamis les nouveaux logiciels avant qu'ils ne soient disponibles au grand public. Bien qu'Apple utilise des techniques d'automatisation pour les tests (des batteries d'iPhone placés dans des racks), la société mise d'abord sur les retours de ses testeurs pour éradiquer les bugs.

Le constructeur a mis sur pied un groupe, le Bug Review Board (BRB), qui a pour mission de prioriser les problèmes à corriger en urgence. Ce comité a à sa tête Kim Vorrath, vice-présidente en charge de la gestion produit pour les logiciels iOS et Mac. Ce comité, où siège également Williams, utilise une nomenclature spécifique pour décider des bugs prioritaires : P1 signifie que l'entreprise doit cesser toute production d'un terminal (autant dire que la décision du BRB est lourde de conséquences). P2 et P3 sont moins importants, mais ils impliquent que les ingénieurs et développeurs d'Apple doivent développer des mises à jour avant même le lancement d'un nouveau produit — Apple a besoin de livrer une première mouture de son système d'exploitation plusieurs semaines avant la commercialisation d'une nouveauté, car il faut bien que cette dernière soit équipée d'un OS en sortant de la ligne de montage.

Les réunions du BRB sont des moments souvent stressants pour les participants : les débats sont vifs entre les ingénieurs, qui ont la responsabilité du bon fonctionnement d'un nouveau produit, et les responsables des ventes et du lancement qui ont des dates fixes à respecter… ce d'autant que le laps de temps est réduit à une poignée de semaines (lire : Quand la culture du secret joue des tours à Apple).

Autre impératif à prendre en compte : les ingénieurs qui testent les logiciels n'ont en main les nouveaux terminaux qu'en même temps que les consommateurs, ou presque. Les mises à jour ne peuvent donc être parfaitement calées ni suffisamment testées pour fonctionner au petit poil. Tim Cook a voulu redoubler d'efforts pour éviter les fuites (comme ce qui était arrivé avec l'iPhone 4, oublié dans un bar de San Francisco). Si cela ne fonctionne pas vraiment en Chine, à Cupertino la sécurité a été renforcée et les ingénieurs n'ont pratiquement plus accès au matériel, à moins d'obtenir une permission spéciale.

Il existe également des problèmes de communication : l'équipe en charge de la validation du fonctionnement du réseau cellulaire et du Wi-Fi peuvent autoriser une mise à jour, et celle de Williams se rendre compte que celle-ci n'est pas compatible avec une autre fonction. Que s'est-il passé avec iOS 8.0.1 ? On ne le saura probablement jamais.