Apple et Microsoft à la colle

Le copier-coller devrait fonctionner de manière aussi transparente entre les OS d’Apple qu’entre un PC et un iPhone. Microsoft va obtenir d’Apple un équivalent de son presse-papier universel, mais pas avant l’automne 2027 au plus tôt, et probablement limité à l’Union européenne.

Apple va développer un mécanisme qui permettra à l’utilisateur d’un PC Windows de copier du texte ou un document, pour le coller sur son iPhone (et vice-versa). Microsoft a déposé une demande d’interopérabilité en mars dernier, dans le cadre du règlement sur les marchés numériques (DMA) comme le rapporte MacRumors. Le constructeur de Cupertino, en sa qualité de contrôleur d’accès, doit en effet assurer une interopérabilité gratuite et effective : les concurrents doivent être en mesure d’accéder aux mêmes fonctions d’iOS qu’Apple.

Copier sur l’iPhone, coller sur Windows

Microsoft explique dans sa demande qu’actuellement, une application destinée à Windows ne peut pas surveiller continuellement le presse-papiers d’iOS : il faut que l’app fonctionne activement au premier plan. De plus, l’utilisateur doit autoriser explicitement l’accès au presse-papiers à chaque fois. Des contraintes qui empêchent la synchronisation transparente de ce contenu.

« Le copier-coller entre appareils exige des actions explicites et répétées de la part de l’utilisateur, et ne peut pas fonctionner comme une expérience continue, intégrée au système, comparable à celle proposée entre iOS et macOS », déplore l’éditeur.

Le presse-papiers universel entre appareils Apple est effectivement un modèle du genre. Pourtant, pour que les concurrents puissent bénéficier d’une expérience similaire, Apple doit intervenir « car les limitations actuelles découlent du fonctionnement de la plateforme et des interfaces système disponibles, et non de contraintes techniques que les développeurs tiers pourraient lever par eux-mêmes », précise Microsoft.

Une fonction qui ne coule pas de source

Dans sa réponse, Apple ne promet pas l’ouverture de son presse-papiers. En revanche, l’entreprise propose un mécanisme beaucoup plus encadré qui passera par une seule autorisation de partage du presse-papiers allouée à l’appareil associé (le PC, en l’occurrence). Le mécanisme en lui-même repose sur une extension qui pourra envoyer son contenu au PC en arrière-plan ; elle serait aussi en mesure d’importer des éléments (de Windows vers l’iPhone).

La transmission se baserait sur l’Accessory Transport Extension framework, et le jumelage sur AccessorySetupKit. Il ne serait ensuite plus nécessaire d’ouvrir une application sur l’iPhone ni de valider chaque transfert, le copier/coller serait donc transparent entre les deux appareils. Attention cependant, cette fonction ne sera pas lancée avant un moment : « Il s’agit d’un chantier d’ingénierie conséquent », prévient Apple.

Le groupe prévoit de terminer le développement de sa solution à l’automne 2027, puis de la proposer en version bêta juste après. Autant dire que le grand public devra se montrer patient avant de pouvoir copier/coller quelque chose entre un PC et un iPhone comme entre un Mac et le smartphone. Toutefois, la fonction est officiellement en chantier. Puisqu’il s’agit d’une demande d’interopérabilité liée au DMA, rien ne dit qu’Apple l’étendra au-delà de l’Union européenne.

Apple a déjà dû faire des concessions sur le plan de l’interopérabilité en Europe. iOS 26.5 a par exemple apporté aux montres connectées autres que l’Apple Watch la possibilité d’interagir avec les notifications envoyées par un iPhone (elles étaient auparavant en lecture seule).

• Avec iOS 26.5, Apple ouvre un peu plus son jardin fermé dans l’UE et ailleurs

Apple et Microsoft à la colle

Le copier-coller devrait fonctionner de manière aussi transparente entre les OS d’Apple qu’entre un PC et un iPhone. Microsoft va obtenir d’Apple un équivalent de son presse-papier universel, mais pas avant l’automne 2027 au plus tôt, et probablement limité à l’Union européenne.

Apple va développer un mécanisme qui permettra à l’utilisateur d’un PC Windows de copier du texte ou un document, pour le coller sur son iPhone (et vice-versa). Microsoft a déposé une demande d’interopérabilité en mars dernier, dans le cadre du règlement sur les marchés numériques (DMA) comme le rapporte MacRumors. Le constructeur de Cupertino, en sa qualité de contrôleur d’accès, doit en effet assurer une interopérabilité gratuite et effective : les concurrents doivent être en mesure d’accéder aux mêmes fonctions d’iOS qu’Apple.

Copier sur l’iPhone, coller sur Windows

Microsoft explique dans sa demande qu’actuellement, une application destinée à Windows ne peut pas surveiller continuellement le presse-papiers d’iOS : il faut que l’app fonctionne activement au premier plan. De plus, l’utilisateur doit autoriser explicitement l’accès au presse-papiers à chaque fois. Des contraintes qui empêchent la synchronisation transparente de ce contenu.

« Le copier-coller entre appareils exige des actions explicites et répétées de la part de l’utilisateur, et ne peut pas fonctionner comme une expérience continue, intégrée au système, comparable à celle proposée entre iOS et macOS », déplore l’éditeur.

Le presse-papiers universel entre appareils Apple est effectivement un modèle du genre. Pourtant, pour que les concurrents puissent bénéficier d’une expérience similaire, Apple doit intervenir « car les limitations actuelles découlent du fonctionnement de la plateforme et des interfaces système disponibles, et non de contraintes techniques que les développeurs tiers pourraient lever par eux-mêmes », précise Microsoft.

Une fonction qui ne coule pas de source

Dans sa réponse, Apple ne promet pas l’ouverture de son presse-papiers. En revanche, l’entreprise propose un mécanisme beaucoup plus encadré qui passera par une seule autorisation de partage du presse-papiers allouée à l’appareil associé (le PC, en l’occurrence). Le mécanisme en lui-même repose sur une extension qui pourra envoyer son contenu au PC en arrière-plan ; elle serait aussi en mesure d’importer des éléments (de Windows vers l’iPhone).

La transmission se baserait sur l’Accessory Transport Extension framework, et le jumelage sur AccessorySetupKit. Il ne serait ensuite plus nécessaire d’ouvrir une application sur l’iPhone ni de valider chaque transfert, le copier/coller serait donc transparent entre les deux appareils. Attention cependant, cette fonction ne sera pas lancée avant un moment : « Il s’agit d’un chantier d’ingénierie conséquent », prévient Apple.

Le groupe prévoit de terminer le développement de sa solution à l’automne 2027, puis de la proposer en version bêta juste après. Autant dire que le grand public devra se montrer patient avant de pouvoir copier/coller quelque chose entre un PC et un iPhone comme entre un Mac et le smartphone. Toutefois, la fonction est officiellement en chantier. Puisqu’il s’agit d’une demande d’interopérabilité liée au DMA, rien ne dit qu’Apple l’étendra au-delà de l’Union européenne.

Apple a déjà dû faire des concessions sur le plan de l’interopérabilité en Europe. iOS 26.5 a par exemple apporté aux montres connectées autres que l’Apple Watch la possibilité d’interagir avec les notifications envoyées par un iPhone (elles étaient auparavant en lecture seule).

• Avec iOS 26.5, Apple ouvre un peu plus son jardin fermé dans l’UE et ailleurs

Petit pimousse

Un an après la version 8.0, l’équipe du projet FFmpeg passe à la mouture majeure suivante. Avec FFmpeg 9.0, Vulkan est particulièrement à l’honneur avec plusieurs améliorations importantes, notamment avec certains codecs orientés production et/ou post-production.

La nouvelle version, nommée « Lei », propose ainsi le décodage matériel d’APV (Advanced Professional Video) via Vulkan. APV est un codec royalties-free (sans redevance) créé par Samsung et pensé comme alternative ouverte à des formats comme le ProRes d’Apple. Comme toujours avec le décodage matériel, cela signifie que le travail est déchargé du CPU vers le GPU, indépendamment du constructeur, Vulkan étant une API multiplateforme.

Puisque l’on parle du ProRes, FFmpeg 9.0 a également du neuf sur le codec. Une accélération Vulkan est là aussi proposée, en complément d’un support ProRes RAW via VideoToolbox. Les flux ProRes RAW, très lourds et jusqu’ici majoritairement décodés au format logiciel ou via des chemins propriétaires Apple, obtiennent ainsi une voie d’accélération GPU générique, ce qui devrait là aussi avoir des répercussions importantes.

Ces deux ajouts, en plus du nouveau filtre v360_vulkan pour la reprojection vidéo 360° et/ou équirectangulaire, positionnent encore un peu plus FFmpeg comme pipeline GPU indépendant. Il fonctionne à l’identique sur les puces Intel, AMD ou encore NVIDIA, sur tous les systèmes d’exploitation, sans dépendre de SDK (kits de développement) propriétaires comme CUDA, NVENC, AMF ou encore VideoToolbox.

Invisible et omniprésent

Parmi les autres nouveautés, on peut noter la lecture native des WebP animés, des améliorations liées au cadre AMF d’AMD, l’arrivée d’un filtre transpose_cuda (rotation/retournement d’image accéléré CUDA, pour éviter les allers-retours GPU > CPU > GPU), le support et le passthrough des métadonnées dynamiques SMPTE 2094 - 50 pour améliorer la gestion des flux de travail HDR, le décodage HE-AAC 960 pour le contenu DAB+ côté audio, ou encore un nettoyage du code avec la suppression de plusieurs éléments obsolètes, dont le décodeur CELT et le parseur Ogg/CELT.

Comme toujours avec les nouvelles versions de FFmpeg, de nombreux composants sont mis à jour, comme libavutil 61.1.100, libavcodec 63.1.100, libavformat 63.1.100, libavdevice 63.1.100, libavfilter 12.1.100, libswscale 10.1.100 et libswresample 7.1.100.

L’importance de cette nouvelle version ne se révèlera, comme d’habitude, qu’une fois son intégration réalisée dans d’autres projets qui en exploiteront les capacités. Rappelons que FFmpeg, même s’il n’est pas connu généralement du grand public, est une brique d’infrastructure invisible mais omniprésente dans le traitement multimédia au sens large.

Si vous connaissez mal ce projet, il s’agit d’une boite à outil pour coder, décoder, transcoder, muxer, démuxer et filtrer à peu près tous les formats audio/vidéo existants. On le retrouve dans de nombreux logiciels et services connus, dont le plus célèbre est sans doute VLC. FFmpeg joue également un rôle essentiel dans YouTube, HandBrake, OBS Studio, des serveurs multimédia domestiques comme Plex et Jellyfin, Discord, Chrome, Blender ou encore WhatsApp. Certains services commerciaux ayant pignon sur rue, comme Netflix, s’en servent également, mais on ne connait pas la nature précise de cet usage.

Petit pimousse

Un an après la version 8.0, l’équipe du projet FFmpeg passe à la mouture majeure suivante. Avec FFmpeg 9.0, Vulkan est particulièrement à l’honneur avec plusieurs améliorations importantes, notamment avec certains codecs orientés production et/ou post-production.

La nouvelle version, nommée « Lei », propose ainsi le décodage matériel d’APV (Advanced Professional Video) via Vulkan. APV est un codec royalties-free (sans redevance) créé par Samsung et pensé comme alternative ouverte à des formats comme le ProRes d’Apple. Comme toujours avec le décodage matériel, cela signifie que le travail est déchargé du CPU vers le GPU, indépendamment du constructeur, Vulkan étant une API multiplateforme.

Puisque l’on parle du ProRes, FFmpeg 9.0 a également du neuf sur le codec. Une accélération Vulkan est là aussi proposée, en complément d’un support ProRes RAW via VideoToolbox. Les flux ProRes RAW, très lourds et jusqu’ici majoritairement décodés au format logiciel ou via des chemins propriétaires Apple, obtiennent ainsi une voie d’accélération GPU générique, ce qui devrait là aussi avoir des répercussions importantes.

Ces deux ajouts, en plus du nouveau filtre v360_vulkan pour la reprojection vidéo 360° et/ou équirectangulaire, positionnent encore un peu plus FFmpeg comme pipeline GPU indépendant. Il fonctionne à l’identique sur les puces Intel, AMD ou encore NVIDIA, sur tous les systèmes d’exploitation, sans dépendre de SDK (kits de développement) propriétaires comme CUDA, NVENC, AMF ou encore VideoToolbox.

Invisible et omniprésent

Parmi les autres nouveautés, on peut noter la lecture native des WebP animés, des améliorations liées au cadre AMF d’AMD, l’arrivée d’un filtre transpose_cuda (rotation/retournement d’image accéléré CUDA, pour éviter les allers-retours GPU > CPU > GPU), le support et le passthrough des métadonnées dynamiques SMPTE 2094 - 50 pour améliorer la gestion des flux de travail HDR, le décodage HE-AAC 960 pour le contenu DAB+ côté audio, ou encore un nettoyage du code avec la suppression de plusieurs éléments obsolètes, dont le décodeur CELT et le parseur Ogg/CELT.

Comme toujours avec les nouvelles versions de FFmpeg, de nombreux composants sont mis à jour, comme libavutil 61.1.100, libavcodec 63.1.100, libavformat 63.1.100, libavdevice 63.1.100, libavfilter 12.1.100, libswscale 10.1.100 et libswresample 7.1.100.

L’importance de cette nouvelle version ne se révèlera, comme d’habitude, qu’une fois son intégration réalisée dans d’autres projets qui en exploiteront les capacités. Rappelons que FFmpeg, même s’il n’est pas connu généralement du grand public, est une brique d’infrastructure invisible mais omniprésente dans le traitement multimédia au sens large.

Si vous connaissez mal ce projet, il s’agit d’une boite à outil pour coder, décoder, transcoder, muxer, démuxer et filtrer à peu près tous les formats audio/vidéo existants. On le retrouve dans de nombreux logiciels et services connus, dont le plus célèbre est sans doute VLC. FFmpeg joue également un rôle essentiel dans YouTube, HandBrake, OBS Studio, des serveurs multimédia domestiques comme Plex et Jellyfin, Discord, Chrome, Blender ou encore WhatsApp. Certains services commerciaux ayant pignon sur rue, comme Netflix, s’en servent également, mais on ne connait pas la nature précise de cet usage.

Mince, ça marche bien en plus

Comment ? Un gestionnaire des tâches sur macOS ? Oui, et bien fait en plus. Il s’agit pour l’instant d’une bêta, mais le projet est prometteur. Et des versions pour Windows et Linux sont prévues.

Dave Plummer, ex-ingénieur de Microsoft (il a notamment travaillé sur NT 4.0), s’est lancé dans un drôle de projet : estimant que le moniteur d’activité de macOS n’était pas digne de la plateforme, il a attaqué le développement d’un authentique gestionnaire des tâches pour la plateforme d’Apple. Oui, un gestionnaire des tâches, comme sous Windows.

Du code neuf et natif

L’histoire est intéressante pour plusieurs raisons. D’abord, le moniteur de macOS, s’il remplit bien ses fonctions élémentaires, ne propose pas de vue de synthèse de ce qui se passe sur la machine : le taux d’occupation du CPU (avec séparation par cœur logique), le remplissage de la mémoire, l’activité réseau ou du stockage, etc.

Ensuite, Dave Plummer a apporté un soin particulier à son développement. Il raconte comment Microsoft l’a laissé examiner, « à titre gracieux », le code source du gestionnaire des tâches de Windows XP. Cependant, aucun pan de code n’a été repris, affirme le développeur. À la place, il a développé un nouveau moteur partagé en C++ ainsi qu’une interface en Swift. C’est d’ailleurs un autre point intéressant : l’interface est léchée, réactive et parfaitement intégrée à l’ambiance macOS. La filiation avec le composant de Windows est cependant assumée dans le nom : TMOG, pour Task Manager Original.

C’est un « oui » !

L’application réunit également plusieurs fonctions au sein de la même interface. On retrouve, comme dans le gestionnaire des tâches de Windows, des onglets avec la vue de synthèse de ce que fait la machine, la liste des processus (qui reprend la vue par défaut du moniteur de macOS) ou encore celle des services. TMOG y ajoute un onglet pour les informations système ou encore la liste des applications lancées au démarrage, avec possibilité de les désactiver.

L’ensemble est particulièrement fluide, surtout pour les jauges et les courbes d’occupation. Les paramètres de l’application permettent de modifier différents éléments d’interface, dont le thème (clair ou sombre), la police par défaut ou encore la fréquence de rafraichissement.

TMOG est fournie pour l’instant sous forme de bêta. Elle n’est pas distribuée sur le Mac App Store pour une raison très simple : la boutique d’Apple oblige les applications qui y sont distribuées à fonctionner dans une sandbox. Pour un projet comme TMOG, ce type d’isolation est impossible, car elle doit aller chercher des informations dont la sandbox n’autorise pas la récupération.

L’application est gratuite et doit le rester, du moins sous cette forme. Dave Plummer indique qu’une version Pro payante pourrait apparaître plus tard. Et si vous vous posez la question : oui, des versions Windows et Linux sont prévues (cette dernière vient tout juste d’être confirmée). Le développeur insiste sur le caractère natif de ces applications et leurs performances.

Mince, ça marche bien en plus

Comment ? Un gestionnaire des tâches sur macOS ? Oui, et bien fait en plus. Il s’agit pour l’instant d’une bêta, mais le projet est prometteur. Et des versions pour Windows et Linux sont prévues.

Dave Plummer, ex-ingénieur de Microsoft (il a notamment travaillé sur NT 4.0), s’est lancé dans un drôle de projet : estimant que le moniteur d’activité de macOS n’était pas digne de la plateforme, il a attaqué le développement d’un authentique gestionnaire des tâches pour la plateforme d’Apple. Oui, un gestionnaire des tâches, comme sous Windows.

Du code neuf et natif

L’histoire est intéressante pour plusieurs raisons. D’abord, le moniteur de macOS, s’il remplit bien ses fonctions élémentaires, ne propose pas de vue de synthèse de ce qui se passe sur la machine : le taux d’occupation du CPU (avec séparation par cœur logique), le remplissage de la mémoire, l’activité réseau ou du stockage, etc.

Ensuite, Dave Plummer a apporté un soin particulier à son développement. Il raconte comment Microsoft l’a laissé examiner, « à titre gracieux », le code source du gestionnaire des tâches de Windows XP. Cependant, aucun pan de code n’a été repris, affirme le développeur. À la place, il a développé un nouveau moteur partagé en C++ ainsi qu’une interface en Swift. C’est d’ailleurs un autre point intéressant : l’interface est léchée, réactive et parfaitement intégrée à l’ambiance macOS. La filiation avec le composant de Windows est cependant assumée dans le nom : TMOG, pour Task Manager Original.

C’est un « oui » !

L’application réunit également plusieurs fonctions au sein de la même interface. On retrouve, comme dans le gestionnaire des tâches de Windows, des onglets avec la vue de synthèse de ce que fait la machine, la liste des processus (qui reprend la vue par défaut du moniteur de macOS) ou encore celle des services. TMOG y ajoute un onglet pour les informations système ou encore la liste des applications lancées au démarrage, avec possibilité de les désactiver.

L’ensemble est particulièrement fluide, surtout pour les jauges et les courbes d’occupation. Les paramètres de l’application permettent de modifier différents éléments d’interface, dont le thème (clair ou sombre), la police par défaut ou encore la fréquence de rafraichissement.

TMOG est fournie pour l’instant sous forme de bêta. Elle n’est pas distribuée sur le Mac App Store pour une raison très simple : la boutique d’Apple oblige les applications qui y sont distribuées à fonctionner dans une sandbox. Pour un projet comme TMOG, ce type d’isolation est impossible, car elle doit aller chercher des informations dont la sandbox n’autorise pas la récupération.

L’application est gratuite et doit le rester, du moins sous cette forme. Dave Plummer indique qu’une version Pro payante pourrait apparaître plus tard. Et si vous vous posez la question : oui, des versions Windows et Linux sont prévues (cette dernière vient tout juste d’être confirmée). Le développeur insiste sur le caractère natif de ces applications et leurs performances.