L'addiction est un bon filon

Meta a dans les cartons une application, nommée Arena, qui pourrait, à terme, concurrencer Polymarket et Kalshi sur le marché des plateformes de paris en ligne. Celui-ci est cependant assez instable légalement aux États-Unis et se voit critiqué par une partie de la classe politique.

Après le Metaverse, les lunettes connectées et l’IA générative, Mark Zuckerberg a dans le viseur un autre marché du numérique à la mode : les plateformes de paris en ligne. En effet, Meta a dans les cartons une application expérimentale nommée Arena prévue pour concurrencer les deux grosses plateformes du marché, Polymarket et Kalshi.

Des sources du New York Times ont expliqué à nos confrères que, contrairement aux plateformes citées ci-dessus, Meta avait prévu, au moins dans un premier temps, que les utilisateurs d’Arena ne puissent pas utiliser de l’argent réel pour parier. L’idée est de proposer des paris avec un système de points comme dans un jeu vidéo. Mais Meta n’exclut pas d’introduire ensuite des paris utilisant de l’argent réel.

Un projet en « priorité absolue » dans l’entreprise

Si Arena devrait être une application indépendante d’Instagram, Facebook ou WhatsApp, Meta espère bien s’appuyer sur le nombre d’utilisateurs de ces plateformes pour créer rapidement une audience importante à sa plateforme de paris en ligne.

Au sein de l’entreprise, le projet reste étiqueté « expérimental » mais est considéré comme une « priorité absolue » poussée par Mark Zuckerberg.

Des applications qui jouent sur la ligne de la légalité, voire qui la dépasse

Les applications comme Polymarket et Kalshi sont présentées à leurs utilisateurs comme des plateformes de paris. Et elles peuvent générer du revenu en prélevant une commission sur chaque pari. Mais, comme nous l’expliquions, aux investisseurs, elles s’affichent comme de potentiels systèmes de prédiction pour le milieu financier. D’autant plus qu’on a vu apparaitre, rapidement et en nombre, des paris soupçonnés de s’appuyer sur des délits d’initiés. L’administration Trump parie d’ailleurs sur l’IA pour les détecter.

• Polymarket, Kalshi… : les États-Unis parient sur l’IA pour détecter les délits d’initiés

Ça n’empêche pas, pour le moment, des cas de délits d’initiés de faire les titres de la presse états-unienne. Récemment, le Département de la Défense du pays a par exemple lancé lancé une enquête à propos de l’ancien élu à la Chambre des représentants des États-Unis, George Santos.

Et la légalité du marché des applications de paris est remise en cause dans certains États comme celui de New York. La procureure générale de cet État expliquait en avril s’allier avec 37 autres procureurs généraux contre Kalshi, « accusée de proposer illégalement des paris sportifs en violation de la législation de l’État en matière de jeux d’argent ». En mai, l’administration Trump a, de son côté, attaqué la loi récemment votée dans l’État du Minesota contre ce genre de plateforme.

Du côté de Polymarket, les utilisateurs américains doivent utiliser un VPN pour accéder au site autrement qu’en lecture seule. Ça n’a pas empêché l’entreprise de payer des influenceurs américains pour créer et partager des vidéos de promotion de la plateforme montrant de faux gains faramineux.

• Les vidéos de gains faramineux sur Polymarket ? Des faux, payés par la plateforme.

« Marché de prédiction »

De fait, Meta n’en est pas à son premier essai dans le secteur. En effet, l’entreprise de Mark Zuckerberg (qui s’appelait encore Facebook à l’époque) avait lancé Forecast de façon opportune dans les premiers mois de la pandémie de Covid-19. Le projet, lancé seulement aux États-Unis et au Canada permettait de poser des questions et d’utiliser des points gagnés dans l’application pour faire des prédictions. Ainsi, l’entreprise invitait les personnels de santé et de la recherche de proposer des prévisions concernant la pandémie et ses impacts. Finalement, l’entreprise a fermé le projet au bout d’un peu plus de deux ans.

Concernant le nouveau projet de Meta, le sénateur Richard Blumenthal (démocrate) a réagi sur X, en affirmant : « Meta s’est inspiré des machines à sous pour rendre les enfants accros à Instagram. Aujourd’hui, Zuckerberg transforme son entreprise en marché de prédiction. » Il a ajouté : « Le modèle économique de Meta consiste à tirer profit de la dépendance : enfants, joueurs, etc. Mettons-y un terme grâce à KOSA [le projet de loi fédérale Kids Online Safety Act qu’il porte, ndlr] et à mes projets de loi sur les marchés prédictifs. »

L'addiction est un bon filon

Meta a dans les cartons une application, nommée Arena, qui pourrait, à terme, concurrencer Polymarket et Kalshi sur le marché des plateformes de paris en ligne. Celui-ci est cependant assez instable légalement aux États-Unis et se voit critiqué par une partie de la classe politique.

Après le Metaverse, les lunettes connectées et l’IA générative, Mark Zuckerberg a dans le viseur un autre marché du numérique à la mode : les plateformes de paris en ligne. En effet, Meta a dans les cartons une application expérimentale nommée Arena prévue pour concurrencer les deux grosses plateformes du marché, Polymarket et Kalshi.

Des sources du New York Times ont expliqué à nos confrères que, contrairement aux plateformes citées ci-dessus, Meta avait prévu, au moins dans un premier temps, que les utilisateurs d’Arena ne puissent pas utiliser de l’argent réel pour parier. L’idée est de proposer des paris avec un système de points comme dans un jeu vidéo. Mais Meta n’exclut pas d’introduire ensuite des paris utilisant de l’argent réel.

Un projet en « priorité absolue » dans l’entreprise

Si Arena devrait être une application indépendante d’Instagram, Facebook ou WhatsApp, Meta espère bien s’appuyer sur le nombre d’utilisateurs de ces plateformes pour créer rapidement une audience importante à sa plateforme de paris en ligne.

Au sein de l’entreprise, le projet reste étiqueté « expérimental » mais est considéré comme une « priorité absolue » poussée par Mark Zuckerberg.

Des applications qui jouent sur la ligne de la légalité, voire qui la dépasse

Les applications comme Polymarket et Kalshi sont présentées à leurs utilisateurs comme des plateformes de paris. Et elles peuvent générer du revenu en prélevant une commission sur chaque pari. Mais, comme nous l’expliquions, aux investisseurs, elles s’affichent comme de potentiels systèmes de prédiction pour le milieu financier. D’autant plus qu’on a vu apparaitre, rapidement et en nombre, des paris soupçonnés de s’appuyer sur des délits d’initiés. L’administration Trump parie d’ailleurs sur l’IA pour les détecter.

• Polymarket, Kalshi… : les États-Unis parient sur l’IA pour détecter les délits d’initiés

Ça n’empêche pas, pour le moment, des cas de délits d’initiés de faire les titres de la presse états-unienne. Récemment, le Département de la Défense du pays a par exemple lancé lancé une enquête à propos de l’ancien élu à la Chambre des représentants des États-Unis, George Santos.

Et la légalité du marché des applications de paris est remise en cause dans certains États comme celui de New York. La procureure générale de cet État expliquait en avril s’allier avec 37 autres procureurs généraux contre Kalshi, « accusée de proposer illégalement des paris sportifs en violation de la législation de l’État en matière de jeux d’argent ». En mai, l’administration Trump a, de son côté, attaqué la loi récemment votée dans l’État du Minesota contre ce genre de plateforme.

Du côté de Polymarket, les utilisateurs américains doivent utiliser un VPN pour accéder au site autrement qu’en lecture seule. Ça n’a pas empêché l’entreprise de payer des influenceurs américains pour créer et partager des vidéos de promotion de la plateforme montrant de faux gains faramineux.

• Les vidéos de gains faramineux sur Polymarket ? Des faux, payés par la plateforme.

« Marché de prédiction »

De fait, Meta n’en est pas à son premier essai dans le secteur. En effet, l’entreprise de Mark Zuckerberg (qui s’appelait encore Facebook à l’époque) avait lancé Forecast de façon opportune dans les premiers mois de la pandémie de Covid-19. Le projet, lancé seulement aux États-Unis et au Canada permettait de poser des questions et d’utiliser des points gagnés dans l’application pour faire des prédictions. Ainsi, l’entreprise invitait les personnels de santé et de la recherche de proposer des prévisions concernant la pandémie et ses impacts. Finalement, l’entreprise a fermé le projet au bout d’un peu plus de deux ans.

Concernant le nouveau projet de Meta, le sénateur Richard Blumenthal (démocrate) a réagi sur X, en affirmant : « Meta s’est inspiré des machines à sous pour rendre les enfants accros à Instagram. Aujourd’hui, Zuckerberg transforme son entreprise en marché de prédiction. » Il a ajouté : « Le modèle économique de Meta consiste à tirer profit de la dépendance : enfants, joueurs, etc. Mettons-y un terme grâce à KOSA [le projet de loi fédérale Kids Online Safety Act qu’il porte, ndlr] et à mes projets de loi sur les marchés prédictifs. »

Depuis des décennies, les développeurs Linux utilisent une fonction nommée strncpy pour copier du texte. Développée en C, elle est étiquetée comme dangereuse par la propre documentation du noyau. Problème, elle est omniprésente.

Pour comprendre le problème, on peut utiliser une analogie. Supposons que la mémoire de l’ordinateur est comme une série de casiers. Quand un programme veut enregistrer un texte, il réserve une boite d’une certaine taille et y écrit le texte. En langage C, l’ordinateur n’a pas de moyen « naturel » pour savoir quand le mot s’arrête. Il y a donc une règle simple : quand le programme écrit un texte, il faut qu’un point rouge (caractère de fin de chaîne \0) en signale la fin.

Et c’est là que les ennuis commencent. La fonction strncpy() est responsable de la copie des textes, mais elle a un gros défaut : quand le texte est trop long, elle coupe la séquence de caractères, mais oublie d’ajouter un point. Et quand le texte est trop court ? Elle ajoute autant de points rouges que nécessaire pour remplir le champ réservé. Les conséquences vont du gaspillage d’énergie à la fuite de secrets, car l’absence de point rouge entraine l’application ou le service à lire ce qui se trouve au-delà, donc des informations présentes dans d’autres « casiers ».

Ces problèmes sont connus depuis longtemps, mais leur résolution a demandé un vaste effort d’ingénierie. Des développeurs ont ainsi passé les six dernières années à référencer toutes les occurrences de la fonction strncpy dans l’intégralité du code du noyau, totalisant 362 commits (des participations, en quelque sorte), rapporte Phoronix. La version 7.2 à venir sera donc la première à ne plus posséder strncpy, remplacé par des variantes modernes et beaucoup plus sécurisées.

Dans la plupart des cas, il s’agira de strscpy, qui possède le comportement adapté : l’outil copie du texte, mais si la séquence est trop longue, il la tronçonne en ajoutant systématiquement un point rouge à la fin de chaque morceau. Strncpy est donc supprimé définitivement à partir du prochain noyau, avec impossibilité d’y faire appel.

Depuis des décennies, les développeurs Linux utilisent une fonction nommée strncpy pour copier du texte. Développée en C, elle est étiquetée comme dangereuse par la propre documentation du noyau. Problème, elle est omniprésente.

Pour comprendre le problème, on peut utiliser une analogie. Supposons que la mémoire de l’ordinateur est comme une série de casiers. Quand un programme veut enregistrer un texte, il réserve une boite d’une certaine taille et y écrit le texte. En langage C, l’ordinateur n’a pas de moyen « naturel » pour savoir quand le mot s’arrête. Il y a donc une règle simple : quand le programme écrit un texte, il faut qu’un point rouge (caractère de fin de chaîne \0) en signale la fin.

Et c’est là que les ennuis commencent. La fonction strncpy() est responsable de la copie des textes, mais elle a un gros défaut : quand le texte est trop long, elle coupe la séquence de caractères, mais oublie d’ajouter un point. Et quand le texte est trop court ? Elle ajoute autant de points rouges que nécessaire pour remplir le champ réservé. Les conséquences vont du gaspillage d’énergie à la fuite de secrets, car l’absence de point rouge entraine l’application ou le service à lire ce qui se trouve au-delà, donc des informations présentes dans d’autres « casiers ».

Ces problèmes sont connus depuis longtemps, mais leur résolution a demandé un vaste effort d’ingénierie. Des développeurs ont ainsi passé les six dernières années à référencer toutes les occurrences de la fonction strncpy dans l’intégralité du code du noyau, totalisant 362 commits (des participations, en quelque sorte), rapporte Phoronix. La version 7.2 à venir sera donc la première à ne plus posséder strncpy, remplacé par des variantes modernes et beaucoup plus sécurisées.

Dans la plupart des cas, il s’agira de strscpy, qui possède le comportement adapté : l’outil copie du texte, mais si la séquence est trop longue, il la tronçonne en ajoutant systématiquement un point rouge à la fin de chaque morceau. Strncpy est donc supprimé définitivement à partir du prochain noyau, avec impossibilité d’y faire appel.

Un peu de bon sens

Microsoft diffuse depuis ce 23 juin une mise à jour – pour l’instant optionnelle – contenant une série d’améliorations pour Windows 11. Parmi elles, une nouvelle fonction de restauration depuis une sauvegarde, capable de remettre en place un ancien état du système datant de quelques jours au maximum, et la possibilité de reporter indéfiniment les mises à jour.

Nouvelle mise à jour pour Windows 11, avec à son bord de multiples ajouts plus ou moins importants. Portant la référence KB5095093, elle est distribuée depuis le 23 juin et se présente pour l’instant sous forme de téléchargement optionnel, quand le réglage « Recevez les dernières mises à jour dès qu’elles sont disponibles » est activé dans Windows Update. Dans notre cas, la fin de l’installation a déclenché deux redémarrages et a nécessité un peu plus de temps que d’habitude.

Une nouvelle restauration

La nouveauté la plus visible est une fonction nommée « Restauration à un instant dans le passé ». On peut la trouver dans les Paramètres > Système > Récupération. Là, une nouvelle entrée est disponible dans la partie « Options de récupération », en bas de liste.

L’ouverture du panneau correspondant réclame une validation des droits administrateurs. Dans la petite fenêtre qui s’ouvre, on peut voir une fonction activée par défaut se proposant de sauvegarder régulièrement l’état du système pour le restaurer en cas de besoin. N’est-ce pas déjà le rôle de la fonction Restauration présente depuis des années ? Oui, mais avec des différences notables.

Contrairement au mécanisme existant, la nouvelle restauration enregistre l’état complet du système à intervalles réguliers, par défaut toutes les 24 heures. L’ancien mécanisme – toujours présent – ne se déclenche qu’à certains évènements, comme l’installation d’un pilote ou d’une application, et ne sauvegarde que les fichiers système et les paramètres.

Les options liées à cette restauration dépendent de la licence utilisée pour Windows. Pour la grande majorité des PC (éditions Famille et Professionnels), le cycle de 24 heures est obligatoire. Avec une licence Entreprise, on peut choisir des cycles de 4, 8, 12 ou 24 heures. La durée de rétention est fixée par défaut à 72 heures, et on ne peut pas aller plus loin. Les licences Entreprise peuvent faire varier cette durée à 6, 12, 16 ou 24 heures. Le seul réglage identique à toutes les éditions est la quantité de stockage affectée. Elle est par défaut de 2 % de l’espace disque total, que l’on peut faire varier de 0 à 3 %. 

Il y a donc une limite nette à la quantité d’états que cette fonction peut garder. Quelle que soit la fréquence, les états finiront par être effacés au bout de 72 heures maximum ou quand l’espace réservé est plein. Le panneau indique toujours la présence des derniers états, ainsi que l’espace consommé par ces sauvegardes. En outre, la fonction ne s’active automatiquement que si le PC dispose d’au moins 200 Go d’espace libre sur le disque. Dans le cas contraire, la fonction est coupée, mais on peut l’activer manuellement depuis le même panneau. On peut l’éteindre à tout moment.

Enfin, le processus de restauration lui-même ne peut pas être déclenché depuis Windows. Pour s’en servir, vous devez redémarrer la machine dans l’environnement de récupération (WinRE). L’accès le plus simple se trouve depuis le même panneau Système > Récupération. Depuis l’interface de WinRE, il suffira alors de sélectionner « Restauration à un point dans le passé » et de choisir la sauvegarde. Si le disque est chiffré avec BitLocker, la clé de récupération devra être saisie.

Windows Update peut reporter indéfiniment les mises à jour

Sync-in est une solution d’hébergement et de synchronisation de fichiers libre et open source (licence AGPL 3), dont le code est disponible depuis un dépôt GitHub. Nous nous étions entretenus avec le créateur du projet, Johan Legrand, qui nous avait alors expliqué ses motivations : proposer une solution simple de synchronisation et de gestion des fichiers, et se concentrer sur l’aspect collaboratif.

La version 2.4, disponible depuis ce 23 juin, comporte bon nombre d’améliorations. En plus d’OnlyOffice et Collabora, l’outil prend en charge Euro-Office. Il est désormais possible d’annuler des tâches (envois, téléchargements, extractions…) depuis le panneau des tâches. Les tâches liées aux fichiers sont d’ailleurs maintenant mises en file d’attente et limitées par utilisateur. Ce changement doit empêcher de lancer un trop grand nombre d’opérations lourdes en parallèle.

On note également deux améliorations bienvenues. Sync-in 2.4 apporte ainsi le support des archives ZIP, en plus des TAR et TGZ déjà prises en charge. D’autre part, l’outil peut à présent vérifier l’email OpenID Connect. Il s’agit d’une option, qui permet aux administrateurs d’exiger qu’un utilisateur OIDC ait une adresse vérifiée avant de pouvoir associer son compte.

Une mesure de sécurité complétée par plusieurs corrections, notamment pour une application renforcée de l’authentification multifacteur et une meilleure défense contre les essais répétés de codes TOTP (Time based One Time Password). On note aussi des améliorations de fiabilité, dont les téléchargements depuis une URL, diverses corrections pour les éditeurs texte et Markdown, la sélection filtrée, le démarrage du serveur et le chargement de configuration.

Le projet a largement accéléré depuis l’automne dernier, avec la sortie de multiples versions. Au cours des six derniers mois, on a pu voir l’arrivée d’un éditeur Markdown intégré, la rétention optionnelle de la corbeille, une amélioration de l’indexation, l’OCR pour les PDF, le support d’OpenID Connect ou encore une refonte de l’interface.

Sync-in est une solution d’hébergement et de synchronisation de fichiers libre et open source (licence AGPL 3), dont le code est disponible depuis un dépôt GitHub. Nous nous étions entretenus avec le créateur du projet, Johan Legrand, qui nous avait alors expliqué ses motivations : proposer une solution simple de synchronisation et de gestion des fichiers, et se concentrer sur l’aspect collaboratif.

La version 2.4, disponible depuis ce 23 juin, comporte bon nombre d’améliorations. En plus d’OnlyOffice et Collabora, l’outil prend en charge Euro-Office. Il est désormais possible d’annuler des tâches (envois, téléchargements, extractions…) depuis le panneau des tâches. Les tâches liées aux fichiers sont d’ailleurs maintenant mises en file d’attente et limitées par utilisateur. Ce changement doit empêcher de lancer un trop grand nombre d’opérations lourdes en parallèle.

On note également deux améliorations bienvenues. Sync-in 2.4 apporte ainsi le support des archives ZIP, en plus des TAR et TGZ déjà prises en charge. D’autre part, l’outil peut à présent vérifier l’email OpenID Connect. Il s’agit d’une option, qui permet aux administrateurs d’exiger qu’un utilisateur OIDC ait une adresse vérifiée avant de pouvoir associer son compte.

Une mesure de sécurité complétée par plusieurs corrections, notamment pour une application renforcée de l’authentification multifacteur et une meilleure défense contre les essais répétés de codes TOTP (Time based One Time Password). On note aussi des améliorations de fiabilité, dont les téléchargements depuis une URL, diverses corrections pour les éditeurs texte et Markdown, la sélection filtrée, le démarrage du serveur et le chargement de configuration.

Le projet a largement accéléré depuis l’automne dernier, avec la sortie de multiples versions. Au cours des six derniers mois, on a pu voir l’arrivée d’un éditeur Markdown intégré, la rétention optionnelle de la corbeille, une amélioration de l’indexation, l’OCR pour les PDF, le support d’OpenID Connect ou encore une refonte de l’interface.

Brèches et oxydation

Le langage Rust et son écosystème ont désormais un ingénieur sécurité résident. Le contrat prévoit pour l’instant qu’il reste six mois, et davantage en fonction du financement. Cette embauche doit permettre la coordination et l’évolution de la sécurité au sein de l’écosystème Rust.

La fondation Rust est la structure créée en février 2021 pour gérer le développement et l’orientation du langage créé par Mozilla. Depuis, elle gère une Security Initiative destinée à protéger les parties de l’écosystème « qu’aucun mainteneur individuel ne peut raisonnablement couvrir seul » : modélisation des menaces pour crates.io (les crates sont des binaires ou des bibliothèques), signature de provenance des artefacts, publication de confiance, ou encore création d’outils comme Painter et Typomania pour cartographier les dépendances et détecter les typosquattages.

Comme l’indique la fondation dans un communiqué publié le 16 juin, l’ensemble est soutenu financièrement par des membres de la fondation (AWS est cité) et par Alpha-Omega, « une initiative inter-industrie qui finance des travaux de sécurité dédiés à travers les projets open source critiques ». C’est dans ce cadre et grâce à ces apports que la fondation annonce l’embauche d’un ingénieur à temps plein pour chapeauter la sécurité de Rust et de son écosystème.

L’impact de l’intelligence artificielle

Dans le communiqué d’Alpha-Omega publié le même jour, on peut lire que cette embauche découle d’un constat : les outils automatisés sont suffisamment puissants pour révéler les failles de sécurité à grande échelle. Plusieurs grands projets Rust ont ainsi reçu des signalements pour corriger de vraies vulnérabilités.

Cependant, le communiqué note aussi que ces outils génèrent un grand nombre de signalements qui peuvent être aussi plausibles qu’inutiles. Alpha-Omega évoque les heures perdues par les mainteneurs à trier ces informations. Une mention qui renvoie, une fois encore, à l’exemple de FFmpeg qui se plaignait du flot ininterrompu de signalements par des personnes n’ayant que peu d’expérience et incapables de voir si les informations envoyées étaient crédibles. Les signalements doivent cependant tous être analysés de peur de laisser passer une faille importante, avec une contrainte forte sur les petites équipes.

Un travail de synthèse et de lubrification

Le nouvel ingénieur, Jacob Finkelman, utilisera « un mélange de méthodes dirigées par l’humain et assistées par l’IA » pour examiner le langage Rust proprement dit et les crates sur lesquels l’écosystème s’appuie le plus. Il sera chargé de séparer le bon grain de l’ivraie : les vrais problèmes exploitables d’un côté, le reste à la poubelle, pour que seules des informations utiles soient envoyées aux mainteneurs.

Jacob Finkleman est un ingénieur logiciel plus connu sous le pseudonyme Eh2406. Il a commencé à utiliser Rust en 2015 et fait partie de l’équipe Cargo de Rust depuis 2018. Il est également le mainteneur de pubgrub-rs, un résolveur de dépendances qui alimente notamment uv, un gestionnaire de paquets et projets Python (écrit en Rust). « Sa connaissance du graphe de dépendances des crates le positionne idéalement pour travailler sur les risques liés à la chaîne d’approvisionnement logicielle », indique la fondation Rust.

Le travail s’effectuera en collaboration avec « les pairs d’autres écosystèmes » et le SRWG (Security Response Working Group) de Rust. Tout ce petit monde devra se concerter pour évaluer rapidement la gravité du contexte et aider autant que possible au développement rapide des correctifs. Cette équipe réduite devra en outre coordonner la divulgation et la publication responsables des informations. Elle servira aussi de guichet unique pour les rapports entrants, « y compris ceux arrivant via des initiatives comme le Project Glasswing », et d’intermédiaire entre chercheurs et mainteneurs quand des situations urgentes se produisent.

• Anthropic dévoile Mythos, son modèle d’IA chasseur de failles… réservé à certains

Six mois pour commencer

Au vu de l’attraction dont jouit Rust depuis plusieurs années et son utilisation plus intensive dans les projets commerciaux (y compris chez Microsoft et Google qui l’utilisent en programmation système), l’écosystème a de quoi se réjouir.

Cette embauche n’est cependant pas définitive. La fondation précise que ce nouveau poste sera à temps plein pour six mois et la suite dépendra de plusieurs facteurs, selon ce que les personnes impliquées « apprendront » et… les financements disponibles bien sûr.

En revanche, la fondation précise que tout ce travail donnera naissance à des méthodes, manuels et consignes qui seront dûment documentés « pour que le travail ne s’arrête pas avec le contrat ». Les outils et pratiques seront partagés avec d’autres écosystèmes, en particulier ceux ayant aussi reçu un financement d’Alpha-Omega, comme la fondation PHP et la Drupal Association.

Enfin, la fondation invite les mainteneurs de crates largement utilisés à la contacter pour être pris en compte dans le cadre de cette initiative de sécurisation.

Brèches et oxydation

Le langage Rust et son écosystème ont désormais un ingénieur sécurité résident. Le contrat prévoit pour l’instant qu’il reste six mois, et davantage en fonction du financement. Cette embauche doit permettre la coordination et l’évolution de la sécurité au sein de l’écosystème Rust.

La fondation Rust est la structure créée en février 2021 pour gérer le développement et l’orientation du langage créé par Mozilla. Depuis, elle gère une Security Initiative destinée à protéger les parties de l’écosystème « qu’aucun mainteneur individuel ne peut raisonnablement couvrir seul » : modélisation des menaces pour crates.io (les crates sont des binaires ou des bibliothèques), signature de provenance des artefacts, publication de confiance, ou encore création d’outils comme Painter et Typomania pour cartographier les dépendances et détecter les typosquattages.

Comme l’indique la fondation dans un communiqué publié le 16 juin, l’ensemble est soutenu financièrement par des membres de la fondation (AWS est cité) et par Alpha-Omega, « une initiative inter-industrie qui finance des travaux de sécurité dédiés à travers les projets open source critiques ». C’est dans ce cadre et grâce à ces apports que la fondation annonce l’embauche d’un ingénieur à temps plein pour chapeauter la sécurité de Rust et de son écosystème.

L’impact de l’intelligence artificielle

Dans le communiqué d’Alpha-Omega publié le même jour, on peut lire que cette embauche découle d’un constat : les outils automatisés sont suffisamment puissants pour révéler les failles de sécurité à grande échelle. Plusieurs grands projets Rust ont ainsi reçu des signalements pour corriger de vraies vulnérabilités.

Cependant, le communiqué note aussi que ces outils génèrent un grand nombre de signalements qui peuvent être aussi plausibles qu’inutiles. Alpha-Omega évoque les heures perdues par les mainteneurs à trier ces informations. Une mention qui renvoie, une fois encore, à l’exemple de FFmpeg qui se plaignait du flot ininterrompu de signalements par des personnes n’ayant que peu d’expérience et incapables de voir si les informations envoyées étaient crédibles. Les signalements doivent cependant tous être analysés de peur de laisser passer une faille importante, avec une contrainte forte sur les petites équipes.

Un travail de synthèse et de lubrification

Le nouvel ingénieur, Jacob Finkelman, utilisera « un mélange de méthodes dirigées par l’humain et assistées par l’IA » pour examiner le langage Rust proprement dit et les crates sur lesquels l’écosystème s’appuie le plus. Il sera chargé de séparer le bon grain de l’ivraie : les vrais problèmes exploitables d’un côté, le reste à la poubelle, pour que seules des informations utiles soient envoyées aux mainteneurs.

Jacob Finkleman est un ingénieur logiciel plus connu sous le pseudonyme Eh2406. Il a commencé à utiliser Rust en 2015 et fait partie de l’équipe Cargo de Rust depuis 2018. Il est également le mainteneur de pubgrub-rs, un résolveur de dépendances qui alimente notamment uv, un gestionnaire de paquets et projets Python (écrit en Rust). « Sa connaissance du graphe de dépendances des crates le positionne idéalement pour travailler sur les risques liés à la chaîne d’approvisionnement logicielle », indique la fondation Rust.

Le travail s’effectuera en collaboration avec « les pairs d’autres écosystèmes » et le SRWG (Security Response Working Group) de Rust. Tout ce petit monde devra se concerter pour évaluer rapidement la gravité du contexte et aider autant que possible au développement rapide des correctifs. Cette équipe réduite devra en outre coordonner la divulgation et la publication responsables des informations. Elle servira aussi de guichet unique pour les rapports entrants, « y compris ceux arrivant via des initiatives comme le Project Glasswing », et d’intermédiaire entre chercheurs et mainteneurs quand des situations urgentes se produisent.

• Anthropic dévoile Mythos, son modèle d’IA chasseur de failles… réservé à certains

Six mois pour commencer

Au vu de l’attraction dont jouit Rust depuis plusieurs années et son utilisation plus intensive dans les projets commerciaux (y compris chez Microsoft et Google qui l’utilisent en programmation système), l’écosystème a de quoi se réjouir.

Cette embauche n’est cependant pas définitive. La fondation précise que ce nouveau poste sera à temps plein pour six mois et la suite dépendra de plusieurs facteurs, selon ce que les personnes impliquées « apprendront » et… les financements disponibles bien sûr.

En revanche, la fondation précise que tout ce travail donnera naissance à des méthodes, manuels et consignes qui seront dûment documentés « pour que le travail ne s’arrête pas avec le contrat ». Les outils et pratiques seront partagés avec d’autres écosystèmes, en particulier ceux ayant aussi reçu un financement d’Alpha-Omega, comme la fondation PHP et la Drupal Association.

Enfin, la fondation invite les mainteneurs de crates largement utilisés à la contacter pour être pris en compte dans le cadre de cette initiative de sécurisation.

Bain d'huile

WhatsApp est la messagerie instantanée la plus utilisée au monde après Messenger, les deux appartenant à Meta. Le service possède plusieurs applications, dont deux « desktop » pour Windows et macOS. La différence de traitement est pourtant énorme.

L’histoire de la version Windows du client WhatsApp se découpe en trois phases :

• Jusqu’en 2023 : la première version, essentiellement le service web encapsulé dans une application Electron, qui embarquait également tout le moteur Chromium pour le rendu
• De fin 2022 à 2025 : nouvelle version, native et utilisant UWP (Universal Windows Platform). Particulièrement légère et rapide
• Depuis 2025 : version en date, basée sur WebView2, donc retour à une encapsulation web

Depuis cette dernière mouture, les critiques n’ont pas manqué. Alors que la version native était célébrée pour ses performances, la nouvelle retourne à un rendu web, avec la consommation des ressources qui l’accompagnent.

Pluie de critiques

Si le grand public se « déplace » rarement pour commenter les applications du quotidien, il en va autrement de la presse spécialisée. Windows Latest s’est largement étendu sur le sujet dès novembre 2025, critiquant l’appétit vorace en ressources : 300 Mo de mémoire sur l’écran de connexion, en moyenne 1,2 Go en discutant, et jusqu’à 2 voire 3 Go en utilisation intensive. Nous avons nous-mêmes constaté que l’application pouvait dépasser ces 3 Go, notamment quand on ouvre le panneau des médias échangés dans une longue conversation. Dans ce cas, il n’est pas rare que l’occupation CPU grimpe en flèche, entrainant des ralentissements sur le reste du système.

Fin mai, IntraBlog publiait un billet allant dans le même sens, notant ici encore la forte consommation des ressources. Le site signalait également la multiplication des processus en arrière-plan, un manque fréquent de réactivité et des problèmes de fiabilité, particulièrement dans la synchronisation. Même chose chez Digital Trends, où la critique était sévère fin avril. Même John Grubber, habitué des informations Apple sur son blog Daring Fireball, n’hésitait pas à dire fin 2025 que la nouvelle application était « merdique ».

Sur Reddit, même combat. Les plaintes sont nombreuses, la plupart soulignant la consommation excessive de ressources et la lenteur générale. Plusieurs affirment avoir basculé sur la version web, la mouture desktop n’apportant plus rien. D’autres évoquent des problèmes fréquents de déconnexion, et d’autres encore recommandent d’ouvrir la version web et de passer par l’installation d’application web de Chrome (ou d’un autre navigateur Chromium).

Silence de Meta et pression de Microsoft

On peut comprendre pourquoi Meta s’est orientée vers ces technologies. L’utilisation d’une version web réclame moins de ressources de développement, puisqu’il s’agit dans les grandes lignes de reprendre l’existant. Contrairement à la première version qui utilisait Electron, la dernière se sert de WebView2, une vue web dérivée d’Edge. Techniquement, cette application devrait donc être plus légère, notamment car il n’est plus nécessaire d’embarquer tout le moteur Chromium. En pratique, le client WhatsApp semble renvoyer plusieurs années dans le passé.

Interrogée par plusieurs médias sur le sujet, Meta n’a pourtant jamais répondu. En novembre 2025, certains y voyaient d’ailleurs le signe d’une bascule : l’âge du code natif était-il révolu ?

Pourtant, si le sujet refait intensément parler aujourd’hui, c’est parce que Microsoft semble avoir changé complètement de braquet. À la dernière conférence Build, l’éditeur a largement appuyé sur le code natif et l’utilisation de son framework WinUI. Une équipe est actuellement chargée de développer de nouvelles applications internes, dont le code a été confirmé comme natif. Des éléments actuellement en React Native, dont le menu Démarrer, vont également être réécrits en code natif.

• Vers des applications natives et un menu contextuel personnalisable pour Windows 11

Concrètement, pour les développeurs tiers, le message de Microsoft a été inhabituellement direct : WinUI n’est pas une expérience en attente d’être remplacée, ni un pont technologique avant la prochaine grande unification : c’est désormais la plateforme de production native pour les apps Windows modernes. L’entreprise en est même jusqu’à parler de « web app slop ».

Cette nouvelle insistance de Microsoft et la pression des utilisateurs seront-elles suffisantes pour faire changer d’avis Meta ? Pour l’instant, WhatsApp reste en zone grise. Mais il est probable que cette version WebView2 ait été conçue pour des questions de coûts. En attendant, la version Mac reste native, avec des performances sans commune mesure.

Bain d'huile

WhatsApp est la messagerie instantanée la plus utilisée au monde après Messenger, les deux appartenant à Meta. Le service possède plusieurs applications, dont deux « desktop » pour Windows et macOS. La différence de traitement est pourtant énorme.

L’histoire de la version Windows du client WhatsApp se découpe en trois phases :

• Jusqu’en 2023 : la première version, essentiellement le service web encapsulé dans une application Electron, qui embarquait également tout le moteur Chromium pour le rendu
• De fin 2022 à 2025 : nouvelle version, native et utilisant UWP (Universal Windows Platform). Particulièrement légère et rapide
• Depuis 2025 : version en date, basée sur WebView2, donc retour à une encapsulation web

Depuis cette dernière mouture, les critiques n’ont pas manqué. Alors que la version native était célébrée pour ses performances, la nouvelle retourne à un rendu web, avec la consommation des ressources qui l’accompagnent.

Pluie de critiques

Si le grand public se « déplace » rarement pour commenter les applications du quotidien, il en va autrement de la presse spécialisée. Windows Latest s’est largement étendu sur le sujet dès novembre 2025, critiquant l’appétit vorace en ressources : 300 Mo de mémoire sur l’écran de connexion, en moyenne 1,2 Go en discutant, et jusqu’à 2 voire 3 Go en utilisation intensive. Nous avons nous-mêmes constaté que l’application pouvait dépasser ces 3 Go, notamment quand on ouvre le panneau des médias échangés dans une longue conversation. Dans ce cas, il n’est pas rare que l’occupation CPU grimpe en flèche, entrainant des ralentissements sur le reste du système.

Fin mai, IntraBlog publiait un billet allant dans le même sens, notant ici encore la forte consommation des ressources. Le site signalait également la multiplication des processus en arrière-plan, un manque fréquent de réactivité et des problèmes de fiabilité, particulièrement dans la synchronisation. Même chose chez Digital Trends, où la critique était sévère fin avril. Même John Grubber, habitué des informations Apple sur son blog Daring Fireball, n’hésitait pas à dire fin 2025 que la nouvelle application était « merdique ».

Sur Reddit, même combat. Les plaintes sont nombreuses, la plupart soulignant la consommation excessive de ressources et la lenteur générale. Plusieurs affirment avoir basculé sur la version web, la mouture desktop n’apportant plus rien. D’autres évoquent des problèmes fréquents de déconnexion, et d’autres encore recommandent d’ouvrir la version web et de passer par l’installation d’application web de Chrome (ou d’un autre navigateur Chromium).

Silence de Meta et pression de Microsoft

On peut comprendre pourquoi Meta s’est orientée vers ces technologies. L’utilisation d’une version web réclame moins de ressources de développement, puisqu’il s’agit dans les grandes lignes de reprendre l’existant. Contrairement à la première version qui utilisait Electron, la dernière se sert de WebView2, une vue web dérivée d’Edge. Techniquement, cette application devrait donc être plus légère, notamment car il n’est plus nécessaire d’embarquer tout le moteur Chromium. En pratique, le client WhatsApp semble renvoyer plusieurs années dans le passé.

Interrogée par plusieurs médias sur le sujet, Meta n’a pourtant jamais répondu. En novembre 2025, certains y voyaient d’ailleurs le signe d’une bascule : l’âge du code natif était-il révolu ?

Pourtant, si le sujet refait intensément parler aujourd’hui, c’est parce que Microsoft semble avoir changé complètement de braquet. À la dernière conférence Build, l’éditeur a largement appuyé sur le code natif et l’utilisation de son framework WinUI. Une équipe est actuellement chargée de développer de nouvelles applications internes, dont le code a été confirmé comme natif. Des éléments actuellement en React Native, dont le menu Démarrer, vont également être réécrits en code natif.

• Vers des applications natives et un menu contextuel personnalisable pour Windows 11

Concrètement, pour les développeurs tiers, le message de Microsoft a été inhabituellement direct : WinUI n’est pas une expérience en attente d’être remplacée, ni un pont technologique avant la prochaine grande unification : c’est désormais la plateforme de production native pour les apps Windows modernes. L’entreprise en est même jusqu’à parler de « web app slop ».

Cette nouvelle insistance de Microsoft et la pression des utilisateurs seront-elles suffisantes pour faire changer d’avis Meta ? Pour l’instant, WhatsApp reste en zone grise. Mais il est probable que cette version WebView2 ait été conçue pour des questions de coûts. En attendant, la version Mac reste native, avec des performances sans commune mesure.

La nouvelle version du système d’exploitation pour l’Apple Watch, watchOS 27, ne s’installera que sur les versions les plus récentes des montres connectées. Une nécessité pour Siri AI, a expliqué Apple.

Les utilisateurs de la première génération d’Apple Watch Ultra seront privés de watchOS 27. Le modèle n’est pourtant pas si vieux, puisqu’il a été lancé en 2022. Malgré tout, cette version devra se contenter de 3 ans de nouveautés : à l’avenir, elle ne recevra que des mises à jour de sécurité.

• Compatibilité matérielle : le grand écart des nouveaux OS 27 d’Apple

watchOS 27 fait aussi l’impasse sur les Apple Watch Series 6, 7, 8 ainsi que sur la SE 2. Pour pouvoir profiter des nouveautés logicielles annoncées durant la conférence mondiale des développeurs d’Apple, il faut donc posséder une Series 9, une Ultra 2 ou une SE3 au minimum, autrement dit des modèles sortis à partir de 2023.

Pourquoi donc abandonner des modèles d’Apple Watch toujours très capables ? « À chaque mise à jour de nos plateformes, notre priorité est de vous offrir la meilleure expérience possible. C’est pourquoi nous accordons une attention particulière aux performances et à l’autonomie de nos appareils », explique Cait Dooley, le directeur produit Apple Watch à TechRadar. Il poursuit :

« Les nouvelles fonctionnalités de watchOS, notamment les capacités d’IA de Siri et le nouveau geste de pincement, tirent le meilleur parti de la puissance de calcul disponible sur l’Apple Watch Series 9 et les modèles ultérieurs, l’Ultra 2 et les versions suivantes, ainsi que la SE 3. »

La messe est dite : les nouveautés logicielles de watchOS 27, à commencer par le support de Siri AI, nécessitent donc une puissance que seules les montres équipées d’une puce S9 ou S10 peuvent offrir. Bien sûr, les modèles plus anciens continueront de fonctionner normalement, jumelés à un iPhone. Mais ils sont maintenant considérés comme des citoyens de seconde zone. C’est d’autant plus dommage qu’iOS 27 est compatible avec tous les iPhone prenant en charge iOS 26.

• Aperçu de Siri AI sur iOS 27 : Apple a-t-elle sauvé le soldat Siri ?

La nouvelle version du système d’exploitation pour l’Apple Watch, watchOS 27, ne s’installera que sur les versions les plus récentes des montres connectées. Une nécessité pour Siri AI, a expliqué Apple.

Les utilisateurs de la première génération d’Apple Watch Ultra seront privés de watchOS 27. Le modèle n’est pourtant pas si vieux, puisqu’il a été lancé en 2022. Malgré tout, cette version devra se contenter de 3 ans de nouveautés : à l’avenir, elle ne recevra que des mises à jour de sécurité.

• Compatibilité matérielle : le grand écart des nouveaux OS 27 d’Apple

watchOS 27 fait aussi l’impasse sur les Apple Watch Series 6, 7, 8 ainsi que sur la SE 2. Pour pouvoir profiter des nouveautés logicielles annoncées durant la conférence mondiale des développeurs d’Apple, il faut donc posséder une Series 9, une Ultra 2 ou une SE3 au minimum, autrement dit des modèles sortis à partir de 2023.

Pourquoi donc abandonner des modèles d’Apple Watch toujours très capables ? « À chaque mise à jour de nos plateformes, notre priorité est de vous offrir la meilleure expérience possible. C’est pourquoi nous accordons une attention particulière aux performances et à l’autonomie de nos appareils », explique Cait Dooley, le directeur produit Apple Watch à TechRadar. Il poursuit :

« Les nouvelles fonctionnalités de watchOS, notamment les capacités d’IA de Siri et le nouveau geste de pincement, tirent le meilleur parti de la puissance de calcul disponible sur l’Apple Watch Series 9 et les modèles ultérieurs, l’Ultra 2 et les versions suivantes, ainsi que la SE 3. »

La messe est dite : les nouveautés logicielles de watchOS 27, à commencer par le support de Siri AI, nécessitent donc une puissance que seules les montres équipées d’une puce S9 ou S10 peuvent offrir. Bien sûr, les modèles plus anciens continueront de fonctionner normalement, jumelés à un iPhone. Mais ils sont maintenant considérés comme des citoyens de seconde zone. C’est d’autant plus dommage qu’iOS 27 est compatible avec tous les iPhone prenant en charge iOS 26.

• Aperçu de Siri AI sur iOS 27 : Apple a-t-elle sauvé le soldat Siri ?

Tout a changé, rien n'a changé

Un responsable de l’équipe Edge chez Microsoft s’est amusé à porter sur iOS un prototype du navigateur avec le moteur Blink, plutôt qu’en passant par le traditionnel (et obligatoire) WebKit. Résultat, une hausse significative des performances. Il ne s’agit toutefois pas d’un test réellement officiel, et les facteurs limitants n’ont pas changé.

Kyle Pflug est l’un des responsables produit d’Edge chez Microsoft. Dans une publication sur LinkedIn le 15 juin, il raconte un projet lancé le temps d’un week-end. Puisque le DMA en Europe permet aux éditeurs de navigateurs de fournir leur propre moteur sur iOS au lieu de passer par WebKit – normalement obligatoire – il s’est demandé ce que donnerait une version d’Edge effectivement accompagnée de Blink, comme sur ordinateur.

Les tests ont été effectués sur un iPhone 17 Pro Max sous iOS 26.5.1. Ils n’ont pas été poussés très loin, Pflug voulant une vue de synthèse sur la base de quelques benchmarks connus :

• Speedometer 3.1 (réactivité web) : 49,27 pour la version Blink, contre 38,3 pour la version WebKit, soit 28,6 % de mieux
• Jetstream 3 (JavaScript et WASM) : 306,35 pour la version Blink, contre 270,9 pour la version WebKit, soit 13,1 % de mieux
• MotionMark 1.3.1 (rendu graphique) : 4 773,52 pour la version Blink, contre 4 673,68 pour la version WebKit, soit 2,1 % de mieux

Comme il le raconte, il s’est amusé à entrer dans un Apple Store pour lancer les trois tests sur un iPad Pro M5. Les résultats étaient plus serrés, avec notamment 45,7 obtenus sur Speedometer. Mais les scores obtenus avec la version de test d’Edge restaient en tête.

Qu’en déduire ?

Difficile dans l’absolu de tirer de grandes conclusions, mais le cas souligne plusieurs points intéressants. Précisons quand même que Kyle Pflug indique bien qu’il s’agit d’une version de développement pour des tests personnels.

« Pour être clair, il s’agit d’un prototype de recherche, pas d’une annonce de produit. Et ce sont des chiffres préliminaires provenant de mon propre appareil, pas des résultats de laboratoire. Mais cela représente une opportunité de combler de véritables écarts de capacités et de susciter une nouvelle concurrence en termes de performance », écrit le responsable sur LinkedIn.

Le 16 juin, alors que Pflug publiait ses résultats sur Bluesky, le post a été repartagé par Ruck Byers, qui n’est autre que l’ingénieur en chef de Chrome chez Google. Il s’est dit impressionné, tout en lâchant une pique à Apple :

« Étant donné que Chromium et WebKit se disputent constamment la première place du classement Speedometer sur macOS, l’écart est vraiment frappant sur iOS ! Et nous n’avons même pas encore vraiment cherché à optimiser les performances pour cette plateforme ! À mon avis, c’est ce à quoi il faut s’attendre en l’absence de concurrence »

Pourquoi personne ne peut-il en profiter ?

Qu’est-ce qu’attend Microsoft pour sortir une version Blink d’Edge dans ce cas ? Ou même Google avec son Chrome ? N’ont-ils pas les moyens de se lancer ?

Techniquement, ils le peuvent. Depuis l’ouverture forcée par le Digital Markets Act de l’Union européenne, Apple a été obligée de lacher du lest. Mais Apple étant Apple, l’entreprise l’a fait d’une manière très particulière.

Ainsi, sur l’App Store, seuls des navigateurs basés sur WebKit (le moteur de Safari) peuvent être validés. Apple a toujours mis en avant la sécurité pour cette limitation : puisque tout le monde passe par le même moteur de rendu, Apple s’assure que ses sécurités sont les mêmes partout. Inévitablement, les performances sont à peu près égales partout aussi. Pour utiliser un autre moteur, il faut soit montrer patte blanche, soit passer par une boutique tierce, sachant que celles-ci ont du mal à se faire une place sur iOS à cause de multiples règles freinant leur développement.

• App Store : Apple détaille ses adaptations au DMA, des réactions déjà virulentes

Si l’on repart maintenant du cas d’Edge, que se passerait-il ? Il faudrait que Microsoft reparte de zéro et sorte un nouveau navigateur mobile pour iOS utilisant Blink. On ne parle pas d’un prototype, mais d’un produit fini, avec tout ce que cela suppose de tests et de finitions. Cette version pourrait soit être lancée sur l’App Store, avec un autre identifiant et en respectant le cadre BrowserEngineKit, soit sur une boutique tierce avec des règles plus libres.

Il y aurait donc deux versions d’Edge, dont une peut-être plus performante, mais accessible uniquement depuis une autre fiche ou un autre emplacement, dont la plupart des utilisateurs n’entendraient pas parler et qui n’existerait que dans l’Union européenne. Une proposition double qui ferait perdre en lisibilité. Et même en cas de boutique tierce, il faudrait d’abord installer cette dernière, ce qui réclame quelques manipulations. On est loin évidemment de la facilité d’installation depuis l’App Store, ou un bouton et une validation biométrique suffisent.

Rien n’a changé en deux ans

Comme le relève notamment The Register, la situation n’a guère évolué en deux ans malgré le DMA. L’ouverture forcée a engendré bien des navettes entre Apple et la Commission européenne, l’entreprise américaine ne cachant plus depuis longtemps sa détestation de cette réglementation.

Les critiques de Mozilla en janvier 2024, soit il y a près de deux ans et demi, sont toujours valables : « Nous sommes encore en train d’examiner les détails techniques, mais nous sommes extrêmement déçus par le plan proposé par Apple de restreindre le BrowserEngineKit nouvellement annoncé aux applications spécifiques à l’UE. Cela aurait pour effet de forcer un navigateur indépendant comme Firefox à construire et à maintenir deux implémentations de navigateur distinctes – un fardeau qu’Apple n’aura pas à supporter ».

Car oui, dans un tel système, Apple garde l’avantage de proposer simplement des mises à jour de son navigateur sans avoir à plier devant d’autres règles que les siennes. Safari et son moteur WebKit restent ainsi tout puissants sur iOS. BrowserEngineKit, créé pour permettre à d’autres moteurs de s’exprimer sur iOS, a des conditions trop restrictives pour être réellement utilisé.

Dans ce contexte, malgré une version de test, Mozilla n’a jamais donné suite à une version entièrement basée sur Gecko, le moteur attitré de la fondation. Le Firefox d’iOS est basé sur WebKit, comme les autres. Sortir une deuxième version ne serait pas rentable, forcerait une maintenance sur les deux moutures, avec une part de marché négligeable et pour laquelle il faudrait payer Apple, puisque « l’ouverture » consentie se fait aussi à travers une redevance.

Même Google avait travaillé sur une version Blink de Chromium pour iOS, comme l’entreprise l’avait confirmé en 2023. Depuis, rien ne s’est passé. Le test de Microsoft a cependant servi à remettre une pièce dans une machine silencieuse. L’association Open Web Advocacy a ainsi mené une nouvelle charge :

« Étant donné qu’Apple a eu plus de deux ans pour produire une solution conforme, la Commission européenne doit ouvrir une procédure de spécification pour instruire Apple, en termes précis, sur la manière dont ces obstacles doivent être levés. C’est, à notre avis, l’intervention la plus cruciale que l’UE puisse faire, et la plus susceptible de transformer l’ensemble de l’écosystème mobile. Aucune autre intervention ne s’en approche. »

Tout a changé, rien n'a changé

Un responsable de l’équipe Edge chez Microsoft s’est amusé à porter sur iOS un prototype du navigateur avec le moteur Blink, plutôt qu’en passant par le traditionnel (et obligatoire) WebKit. Résultat, une hausse significative des performances. Il ne s’agit toutefois pas d’un test réellement officiel, et les facteurs limitants n’ont pas changé.

Kyle Pflug est l’un des responsables produit d’Edge chez Microsoft. Dans une publication sur LinkedIn le 15 juin, il raconte un projet lancé le temps d’un week-end. Puisque le DMA en Europe permet aux éditeurs de navigateurs de fournir leur propre moteur sur iOS au lieu de passer par WebKit – normalement obligatoire – il s’est demandé ce que donnerait une version d’Edge effectivement accompagnée de Blink, comme sur ordinateur.

Les tests ont été effectués sur un iPhone 17 Pro Max sous iOS 26.5.1. Ils n’ont pas été poussés très loin, Pflug voulant une vue de synthèse sur la base de quelques benchmarks connus :

• Speedometer 3.1 (réactivité web) : 49,27 pour la version Blink, contre 38,3 pour la version WebKit, soit 28,6 % de mieux
• Jetstream 3 (JavaScript et WASM) : 306,35 pour la version Blink, contre 270,9 pour la version WebKit, soit 13,1 % de mieux
• MotionMark 1.3.1 (rendu graphique) : 4 773,52 pour la version Blink, contre 4 673,68 pour la version WebKit, soit 2,1 % de mieux

Comme il le raconte, il s’est amusé à entrer dans un Apple Store pour lancer les trois tests sur un iPad Pro M5. Les résultats étaient plus serrés, avec notamment 45,7 obtenus sur Speedometer. Mais les scores obtenus avec la version de test d’Edge restaient en tête.

Qu’en déduire ?

Difficile dans l’absolu de tirer de grandes conclusions, mais le cas souligne plusieurs points intéressants. Précisons quand même que Kyle Pflug indique bien qu’il s’agit d’une version de développement pour des tests personnels.

« Pour être clair, il s’agit d’un prototype de recherche, pas d’une annonce de produit. Et ce sont des chiffres préliminaires provenant de mon propre appareil, pas des résultats de laboratoire. Mais cela représente une opportunité de combler de véritables écarts de capacités et de susciter une nouvelle concurrence en termes de performance », écrit le responsable sur LinkedIn.

Le 16 juin, alors que Pflug publiait ses résultats sur Bluesky, le post a été repartagé par Ruck Byers, qui n’est autre que l’ingénieur en chef de Chrome chez Google. Il s’est dit impressionné, tout en lâchant une pique à Apple :

« Étant donné que Chromium et WebKit se disputent constamment la première place du classement Speedometer sur macOS, l’écart est vraiment frappant sur iOS ! Et nous n’avons même pas encore vraiment cherché à optimiser les performances pour cette plateforme ! À mon avis, c’est ce à quoi il faut s’attendre en l’absence de concurrence »

Pourquoi personne ne peut-il en profiter ?

Qu’est-ce qu’attend Microsoft pour sortir une version Blink d’Edge dans ce cas ? Ou même Google avec son Chrome ? N’ont-ils pas les moyens de se lancer ?

Techniquement, ils le peuvent. Depuis l’ouverture forcée par le Digital Markets Act de l’Union européenne, Apple a été obligée de lacher du lest. Mais Apple étant Apple, l’entreprise l’a fait d’une manière très particulière.

Ainsi, sur l’App Store, seuls des navigateurs basés sur WebKit (le moteur de Safari) peuvent être validés. Apple a toujours mis en avant la sécurité pour cette limitation : puisque tout le monde passe par le même moteur de rendu, Apple s’assure que ses sécurités sont les mêmes partout. Inévitablement, les performances sont à peu près égales partout aussi. Pour utiliser un autre moteur, il faut soit montrer patte blanche, soit passer par une boutique tierce, sachant que celles-ci ont du mal à se faire une place sur iOS à cause de multiples règles freinant leur développement.

• App Store : Apple détaille ses adaptations au DMA, des réactions déjà virulentes

Si l’on repart maintenant du cas d’Edge, que se passerait-il ? Il faudrait que Microsoft reparte de zéro et sorte un nouveau navigateur mobile pour iOS utilisant Blink. On ne parle pas d’un prototype, mais d’un produit fini, avec tout ce que cela suppose de tests et de finitions. Cette version pourrait soit être lancée sur l’App Store, avec un autre identifiant et en respectant le cadre BrowserEngineKit, soit sur une boutique tierce avec des règles plus libres.

Il y aurait donc deux versions d’Edge, dont une peut-être plus performante, mais accessible uniquement depuis une autre fiche ou un autre emplacement, dont la plupart des utilisateurs n’entendraient pas parler et qui n’existerait que dans l’Union européenne. Une proposition double qui ferait perdre en lisibilité. Et même en cas de boutique tierce, il faudrait d’abord installer cette dernière, ce qui réclame quelques manipulations. On est loin évidemment de la facilité d’installation depuis l’App Store, ou un bouton et une validation biométrique suffisent.

Rien n’a changé en deux ans

Comme le relève notamment The Register, la situation n’a guère évolué en deux ans malgré le DMA. L’ouverture forcée a engendré bien des navettes entre Apple et la Commission européenne, l’entreprise américaine ne cachant plus depuis longtemps sa détestation de cette réglementation.

Les critiques de Mozilla en janvier 2024, soit il y a près de deux ans et demi, sont toujours valables : « Nous sommes encore en train d’examiner les détails techniques, mais nous sommes extrêmement déçus par le plan proposé par Apple de restreindre le BrowserEngineKit nouvellement annoncé aux applications spécifiques à l’UE. Cela aurait pour effet de forcer un navigateur indépendant comme Firefox à construire et à maintenir deux implémentations de navigateur distinctes – un fardeau qu’Apple n’aura pas à supporter ».

Car oui, dans un tel système, Apple garde l’avantage de proposer simplement des mises à jour de son navigateur sans avoir à plier devant d’autres règles que les siennes. Safari et son moteur WebKit restent ainsi tout puissants sur iOS. BrowserEngineKit, créé pour permettre à d’autres moteurs de s’exprimer sur iOS, a des conditions trop restrictives pour être réellement utilisé.

Dans ce contexte, malgré une version de test, Mozilla n’a jamais donné suite à une version entièrement basée sur Gecko, le moteur attitré de la fondation. Le Firefox d’iOS est basé sur WebKit, comme les autres. Sortir une deuxième version ne serait pas rentable, forcerait une maintenance sur les deux moutures, avec une part de marché négligeable et pour laquelle il faudrait payer Apple, puisque « l’ouverture » consentie se fait aussi à travers une redevance.

Même Google avait travaillé sur une version Blink de Chromium pour iOS, comme l’entreprise l’avait confirmé en 2023. Depuis, rien ne s’est passé. Le test de Microsoft a cependant servi à remettre une pièce dans une machine silencieuse. L’association Open Web Advocacy a ainsi mené une nouvelle charge :

« Étant donné qu’Apple a eu plus de deux ans pour produire une solution conforme, la Commission européenne doit ouvrir une procédure de spécification pour instruire Apple, en termes précis, sur la manière dont ces obstacles doivent être levés. C’est, à notre avis, l’intervention la plus cruciale que l’UE puisse faire, et la plus susceptible de transformer l’ensemble de l’écosystème mobile. Aucune autre intervention ne s’en approche. »

Fortnite avale Unreal Engine

Avec Unreal Engine 6, Epic ne prépare pas seulement le successeur d’UE5. L’éditeur veut réunir Fortnite et son moteur dans une plateforme unique pour faire circuler des objets entre les jeux, simplifier la création de mondes persistants et, bien sûr, intégrer les outils d’IA générative.

Epic avait profité d’un événement Rocket League pour préparer les esprits à la nouvelle version de son moteur, l’Unreal Engine 6, colonne vertébrale d’une bonne partie de l’industrie du jeu vidéo. À l’occasion de l’Unreal Fest 26, l’éditeur lève le voile sur les principales nouveautés de son environnement de développement et donne des dates : l’accès anticipé est programmé pour la fin de l’année prochaine, avec une version finale prévue dans les 12 à 18 mois qui suivront – probablement dans la foulée des consoles de dixième génération, du moins si la crise de la mémoire le permet.

Fortnite s’invite dans l’Unreal Engine

Comme le résume Epic, UE6 est la combinaison d’Unreal Engine et de l’Unreal Editor for Fortnite (UEFN). Un moteur « unique et unifié pour la prochaine génération du jeu vidéo », qui remplira les mêmes fonctions qu’UE5, mais en mieux : « Le rendu continuera de s’améliorer. Les temps de calcul diminueront. Les cycles d’itération deviendront plus courts. Les appareils mobiles gagneront encore en capacités. »

UE6 se distinguera de son prédécesseur par l’intégration d’UEFN, une version du moteur destinée à Fortnite. Elle permet aux créateurs, aux studios et aux développeurs de concevoir leurs propres jeux et expériences directement dans l’univers de Fortnite, qui n’est plus depuis longtemps un simple battle royale, mais une véritable plateforme de jeux en tout genre. UEFN permet ensuite de distribuer ces expériences à plus de 500 millions de comptes.

UEFN est en quelque sorte le laboratoire d’Epic, qui permet à l’éditeur de tester ses technologies majeures, avant de les intégrer dans l’Unreal Engine tout court. C’est le cas du nouveau langage de programmation Verse, qui constitue la base technique d’UE6. La 6e génération du moteur va fusionner ces deux branches en un seul outil. Pour Epic, il s’agit moins d’une évolution d’UE5 que d’un changement d’architecture.

Unreal Engine 6 va donc exploiter Verse, qui va remplacer progressivement le modèle actuel basé sur C++ et Blueprint. Le moteur a été imaginé pour faciliter la création de mondes persistants à grande échelle, tout en automatisant une partie de la complexité liée au multijoueur, à la synchronisation des données et à la répartition des calculs sur plusieurs serveurs.

Actuellement, les développeurs doivent constamment gérer les conflits entre plusieurs joueurs ou serveurs qui modifient simultanément le même objet ou les mêmes données. L’approche adoptée par Verse, inspirée par les bases de données, permet à chaque opération d’être annulée ou rejouée si un conflit ou un déplacement de données survient.

UE6 doit se charger de la redistribution des données, de la relance des transactions et du maintien d’un état cohérent à travers plusieurs serveurs. « L’astuce, c’est que le code de votre jeu peut être écrit comme s’il s’exécutait sur une seule machine, sans avoir à disséminer partout du code réseau spécifique pour coordonner les différents serveurs », décrypte Epic.

Des standards ouverts pour tout partager

Le second pilier du nouveau moteur concerne la portabilité du contenu et du code entre les jeux, les écosystèmes et les moteurs. Un asset Unreal (un personnage, un objet…) est généralement lié à un jeu, à une version donnée du moteur ou à des systèmes internes spécifiques à un projet. Avec UE6, Epic veut faire sauter ces limites, en s’appuyant sur des formats ouverts comme glTF ou USD ; s’ils ne sont pas suffisants ou s’il n’existe pas de standard, l’éditeur s’engage à ouvrir ses propres systèmes sous forme de spécifications publiques.

Epic veut permettre à certains assets de circuler entre plusieurs jeux, voire entre différents moteurs compatibles avec ses spécifications ouvertes. Le groupe va montrer la voie avec un module ouvert pour les cosmétiques de Fortnite : « vous pourrez, si vous le souhaitez, utiliser dans vos propres jeux les tenues Fortnite possédées par un joueur ». Il s’agit de valider un concept qui rappelle certaines promesses formulées autour des NFT, mais avec une approche très différente.

Au lieu de s’appuyer sur la blockchain pour transporter la seule propriété d’un objet, l’éditeur cherche à standardiser la représentation et le comportement de l’objet pour qu’il puisse être utilisé dans d’autres jeux. Vu l’audience de la plateforme Fortnite et le poids d’Unreal Engine dans l’industrie, Epic est probablement l’un des rares acteurs capables d’imposer une telle solution.

« Au fond, il ne s’agit pas vraiment d’une histoire liée à Fortnite », écrit l’entreprise. « Il s’agit de démontrer qu’un système aussi mature et complexe peut fonctionner à grande échelle, et que chaque jeu qui adoptera ces mécanismes pourra immédiatement en tirer parti. » On verra si les studios accepteront de construire leurs jeux autour de standards définis par Epic.

Les LLM aux manettes

Le dernier volet mis en avant par Epic est peut-être le plus attendu et pourtant, le moins original puisqu’il s’agit d’adosser l’IA générative à UE6. Les grands modèles de langage sont désormais considérés comme une composante normale du processus de développement, comme on l’a d’ailleurs vu tout récemment avec le nombre impressionnant de démos du Steam Next Fest utilisant cette technologie.

• Steam Next Fest : le volume de démos publiées explose sur fond d’IA générative

Dans UE6, Claude, Gemini ou un autre modèle pourra automatiser des tâches répétitives et fastidieuses (ajustement de l’éclairage, analyse des plantages, génération de tests…). Il ne s’agit pas pour autant de remplacer les artistes, mais de leur donner « plus de temps pour l’exploration créative » et « augmenter le nombre d’itérations qu’une équipe peut réaliser pour peaufiner son travail », assure Epic. Pas question non plus que ChatGPT développe un jeu de A à Z dans UE6 à partir d’une requête.

L’intégration de l’IA dans Unreal Engine n’attendra pas la version 6 du moteur. La mise à jour 5.8 propose en effet le support expérimental du plugin Model Context Protocol (MCP), un protocole open source développé à l’origine par Anthropic. C’est devenu un standard de fait pour permettre à un modèle de se connecter à des sources de données et à des outils externes – comme le moteur Unreal, désormais.

Dans une démonstration, Epic a montré comment Claude Code pouvait se brancher à l’Unreal Engine, puis récupérer des objets dans une bibliothèque pour les placer dans un salon virtuel ou dans une ville. Les développeurs gardent heureusement la possibilité de déplacer ces objets à la main, dans l’éditeur d’UE. En plus des bibliothèques d’objets, Claude peut également accéder aux principaux systèmes du moteur (ressources, niveaux, matériaux…).

Epic veut aussi rassurer tous ceux qui craignent une « Fortnitisation » de leurs jeux : les studios pourront continuer à publier des projets « exactement comme aujourd’hui », les proposer directement dans Fortnite ou au sein de leur propre écosystème. « Le passage de l’un à l’autre se fera naturellement », affirme l’entreprise. Pour les curieux, le code source d’UE6 va être mis à disposition sur GitHub.

• Epic lance Lore, un système de contrôle de version dédié au jeu vidéo et open source

Fortnite avale Unreal Engine

Avec Unreal Engine 6, Epic ne prépare pas seulement le successeur d’UE5. L’éditeur veut réunir Fortnite et son moteur dans une plateforme unique pour faire circuler des objets entre les jeux, simplifier la création de mondes persistants et, bien sûr, intégrer les outils d’IA générative.

Epic avait profité d’un événement Rocket League pour préparer les esprits à la nouvelle version de son moteur, l’Unreal Engine 6, colonne vertébrale d’une bonne partie de l’industrie du jeu vidéo. À l’occasion de l’Unreal Fest 26, l’éditeur lève le voile sur les principales nouveautés de son environnement de développement et donne des dates : l’accès anticipé est programmé pour la fin de l’année prochaine, avec une version finale prévue dans les 12 à 18 mois qui suivront – probablement dans la foulée des consoles de dixième génération, du moins si la crise de la mémoire le permet.

Fortnite s’invite dans l’Unreal Engine

Comme le résume Epic, UE6 est la combinaison d’Unreal Engine et de l’Unreal Editor for Fortnite (UEFN). Un moteur « unique et unifié pour la prochaine génération du jeu vidéo », qui remplira les mêmes fonctions qu’UE5, mais en mieux : « Le rendu continuera de s’améliorer. Les temps de calcul diminueront. Les cycles d’itération deviendront plus courts. Les appareils mobiles gagneront encore en capacités. »

UE6 se distinguera de son prédécesseur par l’intégration d’UEFN, une version du moteur destinée à Fortnite. Elle permet aux créateurs, aux studios et aux développeurs de concevoir leurs propres jeux et expériences directement dans l’univers de Fortnite, qui n’est plus depuis longtemps un simple battle royale, mais une véritable plateforme de jeux en tout genre. UEFN permet ensuite de distribuer ces expériences à plus de 500 millions de comptes.

UEFN est en quelque sorte le laboratoire d’Epic, qui permet à l’éditeur de tester ses technologies majeures, avant de les intégrer dans l’Unreal Engine tout court. C’est le cas du nouveau langage de programmation Verse, qui constitue la base technique d’UE6. La 6e génération du moteur va fusionner ces deux branches en un seul outil. Pour Epic, il s’agit moins d’une évolution d’UE5 que d’un changement d’architecture.

Unreal Engine 6 va donc exploiter Verse, qui va remplacer progressivement le modèle actuel basé sur C++ et Blueprint. Le moteur a été imaginé pour faciliter la création de mondes persistants à grande échelle, tout en automatisant une partie de la complexité liée au multijoueur, à la synchronisation des données et à la répartition des calculs sur plusieurs serveurs.

Actuellement, les développeurs doivent constamment gérer les conflits entre plusieurs joueurs ou serveurs qui modifient simultanément le même objet ou les mêmes données. L’approche adoptée par Verse, inspirée par les bases de données, permet à chaque opération d’être annulée ou rejouée si un conflit ou un déplacement de données survient.

UE6 doit se charger de la redistribution des données, de la relance des transactions et du maintien d’un état cohérent à travers plusieurs serveurs. « L’astuce, c’est que le code de votre jeu peut être écrit comme s’il s’exécutait sur une seule machine, sans avoir à disséminer partout du code réseau spécifique pour coordonner les différents serveurs », décrypte Epic.

Des standards ouverts pour tout partager

Le second pilier du nouveau moteur concerne la portabilité du contenu et du code entre les jeux, les écosystèmes et les moteurs. Un asset Unreal (un personnage, un objet…) est généralement lié à un jeu, à une version donnée du moteur ou à des systèmes internes spécifiques à un projet. Avec UE6, Epic veut faire sauter ces limites, en s’appuyant sur des formats ouverts comme glTF ou USD ; s’ils ne sont pas suffisants ou s’il n’existe pas de standard, l’éditeur s’engage à ouvrir ses propres systèmes sous forme de spécifications publiques.

Epic veut permettre à certains assets de circuler entre plusieurs jeux, voire entre différents moteurs compatibles avec ses spécifications ouvertes. Le groupe va montrer la voie avec un module ouvert pour les cosmétiques de Fortnite : « vous pourrez, si vous le souhaitez, utiliser dans vos propres jeux les tenues Fortnite possédées par un joueur ». Il s’agit de valider un concept qui rappelle certaines promesses formulées autour des NFT, mais avec une approche très différente.

Au lieu de s’appuyer sur la blockchain pour transporter la seule propriété d’un objet, l’éditeur cherche à standardiser la représentation et le comportement de l’objet pour qu’il puisse être utilisé dans d’autres jeux. Vu l’audience de la plateforme Fortnite et le poids d’Unreal Engine dans l’industrie, Epic est probablement l’un des rares acteurs capables d’imposer une telle solution.

« Au fond, il ne s’agit pas vraiment d’une histoire liée à Fortnite », écrit l’entreprise. « Il s’agit de démontrer qu’un système aussi mature et complexe peut fonctionner à grande échelle, et que chaque jeu qui adoptera ces mécanismes pourra immédiatement en tirer parti. » On verra si les studios accepteront de construire leurs jeux autour de standards définis par Epic.

Les LLM aux manettes

Le dernier volet mis en avant par Epic est peut-être le plus attendu et pourtant, le moins original puisqu’il s’agit d’adosser l’IA générative à UE6. Les grands modèles de langage sont désormais considérés comme une composante normale du processus de développement, comme on l’a d’ailleurs vu tout récemment avec le nombre impressionnant de démos du Steam Next Fest utilisant cette technologie.

• Steam Next Fest : le volume de démos publiées explose sur fond d’IA générative

Dans UE6, Claude, Gemini ou un autre modèle pourra automatiser des tâches répétitives et fastidieuses (ajustement de l’éclairage, analyse des plantages, génération de tests…). Il ne s’agit pas pour autant de remplacer les artistes, mais de leur donner « plus de temps pour l’exploration créative » et « augmenter le nombre d’itérations qu’une équipe peut réaliser pour peaufiner son travail », assure Epic. Pas question non plus que ChatGPT développe un jeu de A à Z dans UE6 à partir d’une requête.

L’intégration de l’IA dans Unreal Engine n’attendra pas la version 6 du moteur. La mise à jour 5.8 propose en effet le support expérimental du plugin Model Context Protocol (MCP), un protocole open source développé à l’origine par Anthropic. C’est devenu un standard de fait pour permettre à un modèle de se connecter à des sources de données et à des outils externes – comme le moteur Unreal, désormais.

Dans une démonstration, Epic a montré comment Claude Code pouvait se brancher à l’Unreal Engine, puis récupérer des objets dans une bibliothèque pour les placer dans un salon virtuel ou dans une ville. Les développeurs gardent heureusement la possibilité de déplacer ces objets à la main, dans l’éditeur d’UE. En plus des bibliothèques d’objets, Claude peut également accéder aux principaux systèmes du moteur (ressources, niveaux, matériaux…).

Epic veut aussi rassurer tous ceux qui craignent une « Fortnitisation » de leurs jeux : les studios pourront continuer à publier des projets « exactement comme aujourd’hui », les proposer directement dans Fortnite ou au sein de leur propre écosystème. « Le passage de l’un à l’autre se fera naturellement », affirme l’entreprise. Pour les curieux, le code source d’UE6 va être mis à disposition sur GitHub.

• Epic lance Lore, un système de contrôle de version dédié au jeu vidéo et open source

Rufus est une petite application très pratique qui permet de préparer des clés USB pour l’installation de systèmes d’exploitation. Elle s’est fait un nom avec Windows 11 en particulier, en incluant des options permettant de faire « sauter » les prérequis techniques, comme la présence obligatoire d’une puce TPM 2.0.

Quand la version 4.14 est sortie le 30 avril, elle a introduit une nouveauté majeure : l’installation silencieuse pour Windows 11. On peut ainsi paramétrer par avance tous les choix du processus, afin que l’installation se déroule d’une traite, sans intervention manuelle. On peut configurer ce que l’on souhaite comme configuration de stockage, créer un nouveau compte ou encore passer le premier assistant de configuration.

Cette version comportait cependant plusieurs problèmes. La mouture 4.15, disponible en bêta, en corrige la plupart, notamment deux importants : un blocage qui pouvait survenir à 75 % de l’installation, ou encore un autre qui entrainait un plantage au démarrage sur les machines ARM64 équipées d’une puce Snapdragon X. L’utilisation d’une image ISO contenant plusieurs conteneurs WIM pouvait également déclencher une boucle de redémarrage sans fin.

Dans les notes de version, on peut voir que les garde-fous autour de cette fonction d’installation silencieuse ont été améliorés. En outre, il est maintenant possible d’annuler l’opération si des erreurs d’écritures sont rencontrées.

On peut récupérer cette bêta depuis le dépôt GitHub de l’application. Les plus prudents attendront cependant l’arrivée de la version finale.

Rufus est une petite application très pratique qui permet de préparer des clés USB pour l’installation de systèmes d’exploitation. Elle s’est fait un nom avec Windows 11 en particulier, en incluant des options permettant de faire « sauter » les prérequis techniques, comme la présence obligatoire d’une puce TPM 2.0.

Quand la version 4.14 est sortie le 30 avril, elle a introduit une nouveauté majeure : l’installation silencieuse pour Windows 11. On peut ainsi paramétrer par avance tous les choix du processus, afin que l’installation se déroule d’une traite, sans intervention manuelle. On peut configurer ce que l’on souhaite comme configuration de stockage, créer un nouveau compte ou encore passer le premier assistant de configuration.

Cette version comportait cependant plusieurs problèmes. La mouture 4.15, disponible en bêta, en corrige la plupart, notamment deux importants : un blocage qui pouvait survenir à 75 % de l’installation, ou encore un autre qui entrainait un plantage au démarrage sur les machines ARM64 équipées d’une puce Snapdragon X. L’utilisation d’une image ISO contenant plusieurs conteneurs WIM pouvait également déclencher une boucle de redémarrage sans fin.

Dans les notes de version, on peut voir que les garde-fous autour de cette fonction d’installation silencieuse ont été améliorés. En outre, il est maintenant possible d’annuler l’opération si des erreurs d’écritures sont rencontrées.

On peut récupérer cette bêta depuis le dépôt GitHub de l’application. Les plus prudents attendront cependant l’arrivée de la version finale.

Pas de papiers, pas d'application

Google va bel et bien lancer l’année prochaine son système de vérification pour les développeurs d’applications Android, qu’elles soient distribuées sur le Play Store ou dans des boutiques alternatives. Pour le géant du web, c’est un pas de plus vers une amélioration de la sécurité de l’écosystème Android ; pour certaines échoppes en revanche, ce processus est une menace existentielle.

La vérification pour les développeurs Android sera exigée partout dans le monde à partir de 2027, a rappelé Matthew Forsythe, directeur produit chargé de la sécurité des applications Android. Plusieurs pays feront office de cobayes dès le mois de septembre : Brésil, Indonésie, Singapour et Thaïlande. La mesure, présentée en août 2025, oblige les développeurs à enregistrer leurs applications auprès de Google et à vérifier leur identité, avant de pouvoir les distribuer sur les appareils Android certifiés.

• Android : Google va imposer une vérification d’identité à tous les développeurs

Une carte d’identité pour chaque développeur

Les apps proposées sur le Play Store sont concernées bien sûr (elles sont généralement enregistrées automatiquement), mais aussi celles des boutiques alternatives. Pour la première fournée automnale, Google liste ainsi les magasins d’Honor, OPlus, Samsung, Transsion, Vivo et Xiaomi. Depuis le mois de mars et l’ouverture de la validation à tous les développeurs, ce sont « des millions d’apps qui ont été enregistrées », affirme le dirigeant. Ces applications couvrent « la quasi-totalité des installations effectuées via Google Play ainsi qu’une large majorité de celles réalisées en dehors de la boutique de Google ».

Le processus comprend deux étapes : la vérification du développeur à proprement parler, et l’enregistrement de ses applications. Le développeur doit créer un compte dans l’Android Developer Console et fournir des informations pour vérifier son identité (nom réel ou nom de l’entreprise, adresse, un contact, une pièce d’identité officielle…). Google veut être en mesure d’associer chaque développeur à une identité vérifiée.

Ouvrir un compte développeur pour le Play Store coûte 25 dollars. Les développeurs qui ne distribuent pas leurs apps sur la boutique officielle et qui veulent malgré tout les enregistrer auprès de Google (ce n’est pas comme s’ils avaient vraiment le choix…) doivent s’acquitter de la même somme.

Chaque application doit ensuite être enregistrée auprès de Google à l’aide de son nom de paquet, qui fait office d’identifiant unique du logiciel sur Android. Plusieurs boutiques alternatives se sont opposées au système, en particulier F-Droid qui a lancé la contre-offensive : elle estime en effet que cette vérification donne à Google un trop grand pouvoir de contrôle sur toutes les apps Android, y compris celles distribuées en dehors du Play Store.

La boutique a publié le 24 février une lettre ouverte plaidant pour une révision profonde du système de vérification et pour préserver un moyen de distribuer des applications sans devoir obtenir l’approbation de Google. La lettre compte parmi les signataires l’Electronic Frontier Foundation, Proton, la Quadrature du Net, ou encore AdGuard.

• Sur Android, F-Droid part en guerre contre la vérification d’identité des développeurs

Le sideloading survivra, mais ce sera compliqué

Matthew Forsythe précise dans son billet que les apps non enregistrées peuvent toujours être installées en sideloading, via Android Debug Bridge ou « parcours d’installation avancé ». Ce processus a le mérite d’exister, mais il est particulièrement lourd. L’utilisateur devra confirmer qu’il n’est pas forcé d’installer l’application, de redémarrer son appareil, et… d’attendre 24 heures. Au bout du délai, l’installation sera finalement possible.

Google a aussi mis au point des comptes de distribution limités permettant aux étudiants et aux amateurs de partager des apps sur un maximum de 20 appareils, sans avoir à fournir de pièce d’identité ni payer de frais d’inscription.

L’entreprise annonce également de nouvelles API pour vérifier si un nom de paquet est déjà enregistré, et une autre pour enregistrer et gérer des apps directement depuis des outils tiers. Un mécanisme de délégation OAuth est aussi disponible pour effectuer des opérations pour le compte de développeurs sur des boutiques alternatives. Autrement dit, Google ne veut pas forcer les développeurs à passer par la console du Play Store.

Les oppositions à ce nouveau système ne devraient toutefois pas s’éteindre. À compter de ce mois de juin, Google va en effet déployer un nouveau service qui va s’installer automatiquement sur la plupart des terminaux Android. Ce dernier va s’assurer qu’une application est enregistrée auprès d’un développeur vérifié. Ce qui placera Google dans une position d’autorité : l’entreprise pourra ainsi décider quelles apps possèdent une identité reconnue sur Android, même si elles sont distribuées en dehors du Play Store.