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é.
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.
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é.
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.
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.
Source : Kyle Pflug
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.
« É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.
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. »
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.
Source : Kyle Pflug
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.
« É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.
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. »
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.
Les personnages et les lieux emblématiques de la série Les Simpsons seront bientôt disponibles pour les développeurs dans l’UEFN. Image : Epic
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.
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.
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.
Les personnages et les lieux emblématiques de la série Les Simpsons seront bientôt disponibles pour les développeurs dans l’UEFN. Image : Epic
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.
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.
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.
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.
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.
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.
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.
Image : Google
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.
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.
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.
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.
Image : Google
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.
Connexion
