Apple interdit aux développeurs de stocker les données HealthKit dans iCloud

Apple vient de mettre à jour les conditions imposées aux développeurs pour la création des applications mobiles sur iOS 8. La firme y inclut notamment une importante précision : aucune donnée stockée dans HealthKit ne pourra être envoyée sur iCloud. Une information cruciale à la lueur du récent piratage des comptes iCloud de dizaines de célébrités.

HealthKit : pas de stockage des données dans iCloud

Alors que l’arrivée d’iOS 8 se rapproche, Apple a mis à jour les conditions que les développeurs doivent respecter pour que leurs applications soient validées et apparaissent sur l’App Store. Ces conditions s’attardent notamment sur HealthKit, la nouvelle infrastructure d’échange des données liées à la santé et au bien-être, ainsi que sur HomeKit (domotique), TestFlight (gestion des bêtas avec invitation d’utilisateurs pour les tests) et les Extensions, qui vont permettre pour la première fois à iOS d’agrémenter certaines zones du système avec des services tiers.

Les précisions les plus importantes concernent HealthKit, surtout quand on considère les récents piratages de comptes iCloud et les multiples photos dénudées de stars qui en sont sorties. Apple indique ainsi que toute application liant iCloud à HealthKit sera rejetée. Les données stockées dans cette zone n’ont donc pas vocation à voyager vers l'espace de stockage distant d'Apple, mais rien n'empêche en théorie les données d'être enregistrées chez l'éditeur de l'application. On comprend en effet tout l’intérêt de cette barrière quand on sait qu’il suffit d’un mot de passe trop faible pour voir sa vie privée exposée sur la toile.

Les applications utilisant HealthKit devront par ailleurs être accompagnées d’une politique claire de gestion de la vie privée. Pour les entreprises concevant des accessoires, elles devront en outre fournir à la demande des documents écrits prouvant que ces produits ont été approuvés pour une commercialisation. Enfin, toute application qui voudrait communiquer des données HealthKit à une autre, sans l’approbation de l’utilisateur, sera rejetée également.

Des garde-fous pour la manipulation des données dans HomeKit et les Extensions

Rappelons qu’Apple a déjà indiqué récemment que les données collectées par HealthKit ne pourront pas faire l’objet d’une exploitation commerciale, notamment à des fins publicitaires. Le seul cas prévu de transmission concerne les études de santé réalisées par des hôpitaux, centre de recherches, etc. Même dans ce cas, l’accord de l’utilisateur reste obligatoire. Avec la publication des nouvelles conditions, on sait de plus que cette condition s’applique aux données stockées dans HomeKit, donc pour tout ce qui touche à la domotique, et dans les Extensions. Il n’est pas question d’études de santé cette fois.

Concernant HomeKit plus précisément, Apple précise que les applications doivent clairement renseigner l’utilisateur sur le service qui sera apporté. L’objectif prioritaire doit concerner la domotique et une politique de gestion de la vie privée doit être fournie, comme pour HealthKit.

Pour les Extensions enfin, qui devraient changer assez profondément la manière d’utiliser iOS, Apple indique qu’une application ne pourra pas en fournir à moins qu’elles n’exposent de réelles fonctionnalités. Ces dernières ne pourront d’ailleurs pas concerner le marketing, la publicité ou des achats in-app. Concernant les claviers alternatifs, la firme tient à ce qu’ils restent pleinement fonctionnels en cas de coupure complète du réseau, et le guide des extensions impose qu’un lot minimal de chiffres et de symboles y soient accessibles. Une extension de clavier peut d’ailleurs collecter des informations sur son utilisation, mais seulement en vue d’améliorer le service fourni.

Enfin, dans un langage peu coutumier de la firme, Apple indique que les applications qui seront « just plain creepy » (« tout simplement effrayantes ») seront rejetées. Une manière d’aborder la qualité globale des applications et d’enjoindre les développeurs à les rendre agréables.