OPINION. Apple obligée de tout dire sur son système d'exploitation
Charles Cuvelliez et Jean-Pierre Cuvelliez

Photo d'illustration
Dado Ruvic
Charles Cuvelliez et Jean-Pierre Cuvelliez

Photo d'illustration
Dado Ruvic
C'est en vertu de l'article 6(7) du Digital Market Act que la Commission impose ces mesures à iOS. Tout ce que Apple se réserve pour lui-même au sein d'iOS doit potentiellement devenir disponibles à tous les développeurs.
Apple devra commencer par informer la communauté des développeurs sur tout ce qui existe : quelles sont les fonctionnalités accédées ou contrôlées par iOS pour que les développeurs puissent « rêver » et travailler sur un pied d'égalité avec les développeurs internes d'Apple. Il ne s'agit pas de donner en open source le code d'iOS, mais de rendre accessible à tous, non pas une partie, mais l'ensemble des fonctions d'iOS. Cela se fait via les API (Application Program Interface) c'est-à-dire des connecteurs permettant aux développeurs d'utiliser ces fonctions d'iOS de façon structurée. La documentation sur certains API est déjà disponible pour les développeurs. Généralement, Apple déclarera que les autres sont cachées aux tiers parce qu'elles sont instables ou transitoires ou pour ne pas mettre en péril la sécurité et l'intégrité d'iOS. Cependant il n'y a pas réellement de raison qu'Apple les dissimule du fait de sa position de gatekeeper en vertu du DMA. C'est par les API, en effet, que les développeurs peuvent utiliser iOS pour leurs propres applications mobiles, et il est toujours possible de préciser dans la documentation qu'une fonction de l'API n'est pas encore stabilisée. Cela doit donc commencer par une description générale sans entrer dans les détails. Seuls les développeurs qui ont signé une licence ad hoc et sont membres du « Programme Développeur » auront accès à cette information.
Mais cela peut ne pas suffire au développeur pour pouvoir en faire quelque chose. Le développeur pourra introduire une demande d'interopérabilité plus détaillée en justifiant pourquoi la description donnée par Apple ne suffit pas. Apple peut demander en retour au développeur pourquoi il en a besoin. Il devra aussi signer un NDA et Apple garde la possibilité de refuser cette demande si elle peut porter atteinte à l'intégrité d'iOS, sinon Apple a 30 jours pour s'exécuter.
La demande d'un développeur ne se fera pas par un email qu'on peut si facilement laisser trainer. C'est tout un process qui devra être détaillé sur une page web, avec un formulaire à la clé. Apple devra dire à l'avance quels critères il compte utiliser pour donner suite ou non à toute demande d'interopérabilité. Le processus ne peut être aveugle : il faut un point de contact avec lequel le développeur peut interagir pour savoir où on en est. Le développeur sera protégé pour tout ce qu'il voudra soumettre comme information confidentielle, dans le cas, imagine-t-on, où il a une idée de développement qu'il ne veut pas évidemment partager avec des concurrents ou même au sein de Apple.
Pendant tout le process de développement d'un nouveau API plus adapté par Apple, le développeur doit pouvoir donner son feedback. Ce serait trop facile pour Apple de fournir une solution clé sur porte à prendre ou à laisser. Le développeur doit participer à l'élaboration de la solution.
L’actualité qui compte pour vous, chaque jour dans votre boîte mail.

Si Apple rejette la demande, il y aura même une procédure de conciliation. Apple doit engager des conciliateurs indépendants parmi lesquels le développeur mécontent, peut faire son choix. Ce conciliateur peut émettre un avis non contraignant, mais devra se focaliser sur les aspects techniques du conflit développeur/Apple. Cela permettra d'éviter sans doute des considérations commerciales dans le refus d'Apple d'ouvrir une API qui donnerait lieu à une innovation qui lui aurait échappé.
Si tout se passe bien et qu'une nouvelle API est rendue disponible, elle sera accessible à tous sans restriction. En d'autres termes, le développeur qui a demandé le premier cette nouvelle API n'a pas d'exclusivité. Enfin, pas question pour Apple de ne pas tenir à jour cette API.
Si cette obligation d'ouvrir son système d'exploitation est la plus spectaculaire, la Commission ne veut plus du paradigme que seuls des appareils Apple peuvent dialoguer avec des iPhones : il s'agit par exemple des notifications qu'iOS ne peut (veut) envoyer qu'à des appareils connectés Apple. Une autre montre connectée, d'un autre fabricant, doit aussi pouvoir les recevoir. Les apps de tiers sur iPhone pourront désormais aussi fonctionner aussi en arrière-plan pour envoyer à leurs appareils connectés à l'iPhone des notifications, par exemple au cours de la nuit.
Les écouteurs intelligents pourront désormais aussi se connecter à 'l'iPhone quand un appel entrant arrive, ce qu'on appelle l'automatic audio switching. Seuls les écouteurs Apple sont habilités, aujourd'hui, à recevoir un signal de préemption venant d'un iPhone. Les connections pair à pair wifi sans passer par un réseau extérieur ne peuvent être réservées à deux appareils Apple, propose la Commission. Ces connections directes sont particulièrement indiquées pour des transferts de données volumineux et à haut débit. Bien sûr Airdrop et Airplay devront également s'ouvrir à des appareils non Apple (même si Airplay s'ouvrait déjà à certains appareils non Apple). Enfin, la fonctionnalité NFC devra être accessible à tous quand il s'agit de piements sans contact et cela doit pouvoir s'étendre aux appareils connectés comme les montres. Même les réseaux wifi que l'iPhone sauve et partage avec les appareils portables Apple qui lui sont connectés devront être partagés avec tout autre appareil non Apple reliés de la même manière.
La commission va très loin dans le détail, comme on le voit. Apple a déjà réagi vigoureusement en accusant la commission de vouloir mettre un frein à l'innovation et, autre argument habituel, à mettre en danger la confidentialité des données des usagers en forçant la porte de chaque iPhone à des tirs via des API.
______
Pour en savoir plus
Charles Cuvelliez et Jean-Pierre Cuvelliez