❌

Vue normale

Reçu — 19 octobre 2026 ⏭ Actualités numériques

☕️ Une faille dans le noyau Linux permet à une machine virtuelle de lire la mémoire de l’hôte

19 octobre 2026 à 15:09


La faille CVE-2026-99999, surnommée PwnEscape, affecte la plupart des noyaux Linux actuellement maintenus. Elle n’est pas présente dans le nouveau noyau 7.3, mais la mouture 7.2 (entre autres) est touchée, nécessitant l’installation de la dernière révision.

Exploitée, cette faille permet à du code exécuté dans une machine virtuelle invitée de lire la mémoire du noyau de l’hôte.

À qui incombe la faute ? Pas à KVM ni à un hyperviseur en particulier. La vulnérabilité se trouve dans la pile IPv4 du noyau de l’hôte. Avec des métadonnées de somme de contrôle (checksum) erronées, le code de calcul de cette somme peut ainsi écrire sur un en-tête IPv4 que le noyau a déjà lu et exploité. En exploitant cette brèche, chaque paquet émis par l’invité pouvait ramener environ 32 octets de la mémoire de l’hôte.

La faille a été trouvée par le chercheur Paulos Yibelo dans le cadre d’un concours organisé par Vercel. Cette société indique dans son propre billet qu’en conditions de laboratoire, PwnEscape a même permis d’obtenir les droits administrateur sur l’hôte, ou de planter ce dernier. La société précise cependant que seule la lecture de la mémoire de l’hôte a été démontrée en infrastructure de production.

Source : Paulos Yibelo

Vercel ajoute qu’elle a pisté l’origine du problème à deux modifications : la prise en charge de l’en-tête virtio-net pour les périphériques tun/tap (2008, selon AlmaLinux) et le délestage de somme de contrôle pour les sockets de paquets (2010). En d’autres termes, la faille est présente depuis 18 ans.

Conséquence, de nombreuses nouvelles versions ont été publiées pour les noyaux actuellement supportés : 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.57 et 7.2.11. À noter que les outils comme uname indiquant le numéro de version ne sont pas toujours représentatifs de l’état de la sécurité, car les distributions rétroportent souvent des correctifs sans changer le numéro de version. Il faut donc s’assurer pour chaque distribution que l’avis de distribution a bien été publié pour cette faille.

Enfin, il ne s’agit pas d’une faille 0-day. Paulos Yibelo indique dans son billet avoir signalé le problème en privé aux mainteneurs du noyau le 4 septembre. Le correctif a été accepté dans l’arbre réseau le 8 octobre et intégré au noyau principal le 14. Le bulletin CVE et les versions stables corrigées ont été publiés dès le lendemain (on peut voir la liste sur kernel.org). La précision est importante : Vercel évoque « the kernel-zero-day », mais l’expression semble renvoyer au fait que les mainteneurs du noyau ne connaissaient pas ce problème jusqu’à présent.

La faille ne semble pas exploitée. Toutefois, le chercheur précise que ses correctifs proposés ont fait l’objet de soumissions publiques sur la liste netdev entre les 19 et 22 septembre. La nature du problème y était clairement consultable, plusieurs semaines avant le CVE.

☕️ Une faille dans le noyau Linux permet à une machine virtuelle de lire la mémoire de l’hôte

19 octobre 2026 à 15:09


La faille CVE-2026-99999, surnommée PwnEscape, affecte la plupart des noyaux Linux actuellement maintenus. Elle n’est pas présente dans le nouveau noyau 7.3, mais la mouture 7.2 (entre autres) est touchée, nécessitant l’installation de la dernière révision.

Exploitée, cette faille permet à du code exécuté dans une machine virtuelle invitée de lire la mémoire du noyau de l’hôte.

À qui incombe la faute ? Pas à KVM ni à un hyperviseur en particulier. La vulnérabilité se trouve dans la pile IPv4 du noyau de l’hôte. Avec des métadonnées de somme de contrôle (checksum) erronées, le code de calcul de cette somme peut ainsi écrire sur un en-tête IPv4 que le noyau a déjà lu et exploité. En exploitant cette brèche, chaque paquet émis par l’invité pouvait ramener environ 32 octets de la mémoire de l’hôte.

La faille a été trouvée par le chercheur Paulos Yibelo dans le cadre d’un concours organisé par Vercel. Cette société indique dans son propre billet qu’en conditions de laboratoire, PwnEscape a même permis d’obtenir les droits administrateur sur l’hôte, ou de planter ce dernier. La société précise cependant que seule la lecture de la mémoire de l’hôte a été démontrée en infrastructure de production.

Source : Paulos Yibelo

Vercel ajoute qu’elle a pisté l’origine du problème à deux modifications : la prise en charge de l’en-tête virtio-net pour les périphériques tun/tap (2008, selon AlmaLinux) et le délestage de somme de contrôle pour les sockets de paquets (2010). En d’autres termes, la faille est présente depuis 18 ans.

Conséquence, de nombreuses nouvelles versions ont été publiées pour les noyaux actuellement supportés : 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.57 et 7.2.11. À noter que les outils comme uname indiquant le numéro de version ne sont pas toujours représentatifs de l’état de la sécurité, car les distributions rétroportent souvent des correctifs sans changer le numéro de version. Il faut donc s’assurer pour chaque distribution que l’avis de distribution a bien été publié pour cette faille.

Enfin, il ne s’agit pas d’une faille 0-day. Paulos Yibelo indique dans son billet avoir signalé le problème en privé aux mainteneurs du noyau le 4 septembre. Le correctif a été accepté dans l’arbre réseau le 8 octobre et intégré au noyau principal le 14. Le bulletin CVE et les versions stables corrigées ont été publiés dès le lendemain (on peut voir la liste sur kernel.org). La précision est importante : Vercel évoque « the kernel-zero-day », mais l’expression semble renvoyer au fait que les mainteneurs du noyau ne connaissaient pas ce problème jusqu’à présent.

La faille ne semble pas exploitée. Toutefois, le chercheur précise que ses correctifs proposés ont fait l’objet de soumissions publiques sur la liste netdev entre les 19 et 22 septembre. La nature du problème y était clairement consultable, plusieurs semaines avant le CVE.

☕️ Drupal colmate deux failles critiques exploitables à distance

19 octobre 2026 à 13:56


Drupal, une solution libre de CMS (système de gestion de contenu), a corrigé le 14 octobre deux failles critiques de type RCE (Remote Code Execution). Elles permettent donc, si exploitées, de faire exécuter un code arbitraire à distance.

La première faille, CVE-2026-108097 (bulletin SA-CORE-2026-014), touche le module Field UI du cœur de Drupal. Le bulletin la classe « critique » avec un score de 19 sur 25, mais ne donne pas directement le score CVSS. Celui-ci est de 9,8 sur 10, frôlant ainsi le maximum de dangerosité.

Drupal indique que le cœur seul ne permet pas d’exploiter cette faille directement, mais plusieurs chemins d’exploitation sont possibles via des modules contribués, c’est-à-dire créés et gérés par la communauté (Drupal ne fournit que les modules du cœur). Drupal ne donne cependant pas la liste des modules tiers en question. La faille peut également être exploitable avec du code spécifique au site. Au moins un des chemins d’exploitation ne réclame aucune authentification.

L’autre faille, CVE-2026-108099 (SA-CONTRIB-2026-218), touche le module contribué Entity List, qui sert à construire des listes d’entités sans passer par Views. Elle aussi exige l’interaction avec des modules contribués ou du code spécifique, avec au moins un chemin sans authentification là encore. Le score CVSS n’est pas encore disponible, mais la faille est probablement aussi dangereuse que la première, car Drupal lui attribue sa propre note de 19/25, le même score que la faille CVE-2026-108097.

Toutes les versions du cœur actuellement supportées sont concernées. Les correctifs sont disponibles dans les moutures 11.4.10, 11.3.19 et 10.6.19. Les versions 11.2.x et antérieures, ainsi que 10.5.x et antérieures, ne reçoivent plus de suivi de sécurité, et Drupal 8 et 9 sont en fin de vie. Pour Entity List, il faut passer en version 3.0.10.

À noter que Drupal propose une mesure d’atténuation pour la faille CVE-2026-108097 dans le cas où la mise à jour ne peut pas être appliquée tout de suite : désinstaller le module Field UI. Aucune mesure n’a en revanche été donnée pour l’autre vulnérabilité. Au vu de la dangerosité de ces failles, il est chaudement recommandé de mettre à jour les sites concernés sans attendre.

À noter qu’aucune de ces failles n’était a priori exploitée au moment de la publication des bulletins.

☕️ Drupal colmate deux failles critiques exploitables à distance

19 octobre 2026 à 13:56


Drupal, une solution libre de CMS (système de gestion de contenu), a corrigé le 14 octobre deux failles critiques de type RCE (Remote Code Execution). Elles permettent donc, si exploitées, de faire exécuter un code arbitraire à distance.

La première faille, CVE-2026-108097 (bulletin SA-CORE-2026-014), touche le module Field UI du cœur de Drupal. Le bulletin la classe « critique » avec un score de 19 sur 25, mais ne donne pas directement le score CVSS. Celui-ci est de 9,8 sur 10, frôlant ainsi le maximum de dangerosité.

Drupal indique que le cœur seul ne permet pas d’exploiter cette faille directement, mais plusieurs chemins d’exploitation sont possibles via des modules contribués, c’est-à-dire créés et gérés par la communauté (Drupal ne fournit que les modules du cœur). Drupal ne donne cependant pas la liste des modules tiers en question. La faille peut également être exploitable avec du code spécifique au site. Au moins un des chemins d’exploitation ne réclame aucune authentification.

L’autre faille, CVE-2026-108099 (SA-CONTRIB-2026-218), touche le module contribué Entity List, qui sert à construire des listes d’entités sans passer par Views. Elle aussi exige l’interaction avec des modules contribués ou du code spécifique, avec au moins un chemin sans authentification là encore. Le score CVSS n’est pas encore disponible, mais la faille est probablement aussi dangereuse que la première, car Drupal lui attribue sa propre note de 19/25, le même score que la faille CVE-2026-108097.

Toutes les versions du cœur actuellement supportées sont concernées. Les correctifs sont disponibles dans les moutures 11.4.10, 11.3.19 et 10.6.19. Les versions 11.2.x et antérieures, ainsi que 10.5.x et antérieures, ne reçoivent plus de suivi de sécurité, et Drupal 8 et 9 sont en fin de vie. Pour Entity List, il faut passer en version 3.0.10.

À noter que Drupal propose une mesure d’atténuation pour la faille CVE-2026-108097 dans le cas où la mise à jour ne peut pas être appliquée tout de suite : désinstaller le module Field UI. Aucune mesure n’a en revanche été donnée pour l’autre vulnérabilité. Au vu de la dangerosité de ces failles, il est chaudement recommandé de mettre à jour les sites concernés sans attendre.

À noter qu’aucune de ces failles n’était a priori exploitée au moment de la publication des bulletins.

☕️ Des serveurs Exchange fonctionnent mal depuis les mises à jour du 13 octobre

19 octobre 2026 à 09:56


Les dernières mises à jour pour Windows Server, publiés le 13 octobre, engendrent des problèmes avec les serveurs Exchange sur site. Microsoft a confirmé ces perturbations, les versions concernées étant les 2016, 2019 et Subscription Edition. Ces défaillances sont liées à quatre mises à jour : KB5126646 (Windows Server 2025), KB5126655 (2022), KB5126651 (2019) et KB5126868 (2016).

Les symptômes sont nombreux : messages bloqués dans la boîte d’envoi d’Outlook, files d’attente qui s’allongent, échecs d’accès aux boîtes pendant la réplication, ou encore difficultés des membres d’un groupe de disponibilité de bases de données (DAG) à atteindre le quorum. Ces symptômes peuvent cependant varier fortement selon les configurations, certaines n’en développant aucun.

Selon la note publiée par Microsoft, les mises à jour d’octobre ont introduit une limite par défaut de 512 appels simultanés de recherche de point de terminaison (Endpoint Lookup). Cette limite contrôle la mémoire utilisée par Endpoint Mapper – un composant des appels de procédure distante (RPC) – et les charges Exchange élevées peuvent la dépasser.

Nous pouvons confirmer l’ampleur du problème, l’un de nos contacts ayant été touché. Il nous a indiqué qu’un redémarrage du serveur Exchange permettait de repousser le problème temporairement, ce que Microsoft confirme dans un billet publié séparément sur le blog de l’équipe Exchange. Celle-ci recommande de ne pas désinstaller les mises à jour (puisqu’elles corrigent un grand nombre de failles) puis d’exécuter la commande suivante depuis une invite en mode administrateur :

reg add "HKLM\SOFTWARE\Microsoft\Rpc" /v EpmapSavedContextCap /t REG_DWORD /d 65536 /f

Il faudra ensuite redémarrer le serveur. Une fois cette étape réalisée, Microsoft recommande de surveiller l’état du serveur pour vérifier si le problème survient. Dans ce cas, il faudra augmenter la limite citée précédemment. Selon l’équipe Exchange, les retours ont indiqué que le problème était jugulé en appliquant cette méthode.

☕️ Des serveurs Exchange fonctionnent mal depuis les mises à jour du 13 octobre

19 octobre 2026 à 09:56


Les dernières mises à jour pour Windows Server, publiés le 13 octobre, engendrent des problèmes avec les serveurs Exchange sur site. Microsoft a confirmé ces perturbations, les versions concernées étant les 2016, 2019 et Subscription Edition. Ces défaillances sont liées à quatre mises à jour : KB5126646 (Windows Server 2025), KB5126655 (2022), KB5126651 (2019) et KB5126868 (2016).

Les symptômes sont nombreux : messages bloqués dans la boîte d’envoi d’Outlook, files d’attente qui s’allongent, échecs d’accès aux boîtes pendant la réplication, ou encore difficultés des membres d’un groupe de disponibilité de bases de données (DAG) à atteindre le quorum. Ces symptômes peuvent cependant varier fortement selon les configurations, certaines n’en développant aucun.

Selon la note publiée par Microsoft, les mises à jour d’octobre ont introduit une limite par défaut de 512 appels simultanés de recherche de point de terminaison (Endpoint Lookup). Cette limite contrôle la mémoire utilisée par Endpoint Mapper – un composant des appels de procédure distante (RPC) – et les charges Exchange élevées peuvent la dépasser.

Nous pouvons confirmer l’ampleur du problème, l’un de nos contacts ayant été touché. Il nous a indiqué qu’un redémarrage du serveur Exchange permettait de repousser le problème temporairement, ce que Microsoft confirme dans un billet publié séparément sur le blog de l’équipe Exchange. Celle-ci recommande de ne pas désinstaller les mises à jour (puisqu’elles corrigent un grand nombre de failles) puis d’exécuter la commande suivante depuis une invite en mode administrateur :

reg add "HKLM\SOFTWARE\Microsoft\Rpc" /v EpmapSavedContextCap /t REG_DWORD /d 65536 /f

Il faudra ensuite redémarrer le serveur. Une fois cette étape réalisée, Microsoft recommande de surveiller l’état du serveur pour vérifier si le problème survient. Dans ce cas, il faudra augmenter la limite citée précédemment. Selon l’équipe Exchange, les retours ont indiqué que le problème était jugulé en appliquant cette méthode.

Le noyau Linux 7.3 débarque avec une longue liste d’améliorations

19 octobre 2026 à 08:41
On approche des 20 000 modifications
Le noyau Linux 7.3 débarque avec une longue liste d’améliorations

Après une longue gestation marquée par une montée en force de l’IA dans la détection des bugs, la version finale du noyau Linux 7.3 est arrivée. Les améliorations sont nombreuses, mais la disponibilité dépendra comme toujours de la distribution utilisée.

Le noyau Linux 7.3 est finalement arrivé comme prévu ce dimanche 18 octobre, après une gestation qui aura marqué les esprits. Selon les statistiques fournies par LWN, cette nouvelle mouture compte en effet 18 765 modifications (hors fusions), en provenance de plus de 3000 contributeurs. Elle est également significative par ses Release Candidates, marquées par l’arrivée « brutale » de l’IA dans la détection et la correction des bugs. Une « nouvelle normalité » commentait Linus Torvalds récemment.

Côté matériel

La nouvelle mouture comporte une liste abondante d’améliorations, à commencer par la prise en charge du matériel. On note ainsi la prise en charge initiale des puces M3 Pro, Max et Ultra, qui complète celle du M3 de base ajoutée dans la 7.2. Même chose pour le nouveau type de cœur basse consommation en préparation chez AMD pour son architecture Zen.

Plus concrètement peut-être, on y trouve aussi la gestion des interruptions thermiques chez Intel, la prise en charge du bloc d’affichage DCN 6.0 et des modificateurs de format DRM pour d’anciens GPU AMD, le support de la manette Steam Controller de 2026, ou encore des améliorations de l’ordonnanceur pour les processeurs hybrides et une gestion plus unifiée des types de cœurs Intel et AMD. Le noyau intègre également un pilote pour la manette MSI Claw, un pilote HID-HyperX pour l’état de coupure du micro HyperX QuadCast 2, et la prise en charge du commutateur de mode tablette dans le pilote AMD Sensor Fusion Hub.

Du mieux pour certains systèmes de fichiers

Le noyau Linux 7.3 introduit en outre un nouveau système de fichiers particulier : failfs. Il se veut le pendant de nullfs et fait échouer toute opération l’atteignant avec l’erreur EOPNOTSUPP (chemins absolus, liens symboliques et chemins relatifs au répertoire courant). Pour son auteur, Christian Brauner, l’intérêt est de permettre aux processus de se défaire entièrement de leur état de système de fichiers. Ainsi, un processus dont la racine ou le répertoire courant est dans failfs doit ancrer chaque résolution de chemin sur un descripteur de fichier explicite.

On reste dans les systèmes de fichiers avec une série d’améliorations pour ceux déjà en place. Le noyau 7.3 inclut par exemple une hausse des performances (parfois significatives selon les scénarios) pour btrfs que Phoronix avait repérée à la sortie de la première Release Candidate fin aout. Alors que le code de support des systèmes EFS et FreeVxFS est supprimé, celui pour ntfs3 reçoit d’importantes améliorations, dont la prise en charge des flux de données alternatifs ainsi qu’un début de durcissement pour sa sécurité.

Parmi les autres changements, on remarque en outre des travaux significatifs sur le support de SMB, qui peut gérer en option Time Machine (le système de sauvegarde de macOS). Le serveur SMB intégré au noyau (ksmbd) gagne aussi la fenêtre de séquence des commandes SMB2, le rejeu des requêtes SMB3, le chiffrement SMB3 par partage et le chiffrement pour SMB Direct (RDMA). À la sortie de la Release Candidate 3, Linus Torvalds avait indiqué qu’un nombre important de correctifs était intégré pour SMB (ainsi que pour XFS).

LTS ou pas LTS ?

Cette version 7.3 est donc disponible, mais sa récupération réelle dépend fortement de la distribution utilisée. De nombreux systèmes ne proposent pas immédiatement les nouveaux noyaux et attendent leur version suivante pour l’intégrer. D’autres, notamment celles en rolling release, proposent les nouveaux noyaux très rapidement en général.

Enfin, un mot sur la prochaine version 7.4. Sa fenêtre d’intégration vient d’ouvrir et sa publication doit se faire vers la fin décembre. Cette version sera à nouveau importante pour le support matériel, avec par exemple l’activation du HDMI 2.1 sur les Radeon, le support des NPU dans les Ryzen AI Max 400, la poursuite des travaux sur le pilote NVIDIA Nova (pour remplacer l’actuel Nouveau), des optimisations sur la mémoire, ou encore la prise en charge initiale des puces M4 et A18 pro d’Apple.

On ne sait pas encore si cette version sera la nouvelle LTS (Long Term Support) ou s’il s’agira de la 7.3 qui vient de sortir.

Le noyau Linux 7.3 débarque avec une longue liste d’améliorations

19 octobre 2026 à 08:41
On approche des 20 000 modifications
Le noyau Linux 7.3 débarque avec une longue liste d’améliorations

Après une longue gestation marquée par une montée en force de l’IA dans la détection des bugs, la version finale du noyau Linux 7.3 est arrivée. Les améliorations sont nombreuses, mais la disponibilité dépendra comme toujours de la distribution utilisée.

Le noyau Linux 7.3 est finalement arrivé comme prévu ce dimanche 18 octobre, après une gestation qui aura marqué les esprits. Selon les statistiques fournies par LWN, cette nouvelle mouture compte en effet 18 765 modifications (hors fusions), en provenance de plus de 3000 contributeurs. Elle est également significative par ses Release Candidates, marquées par l’arrivée « brutale » de l’IA dans la détection et la correction des bugs. Une « nouvelle normalité » commentait Linus Torvalds récemment.

Côté matériel

La nouvelle mouture comporte une liste abondante d’améliorations, à commencer par la prise en charge du matériel. On note ainsi la prise en charge initiale des puces M3 Pro, Max et Ultra, qui complète celle du M3 de base ajoutée dans la 7.2. Même chose pour le nouveau type de cœur basse consommation en préparation chez AMD pour son architecture Zen.

Plus concrètement peut-être, on y trouve aussi la gestion des interruptions thermiques chez Intel, la prise en charge du bloc d’affichage DCN 6.0 et des modificateurs de format DRM pour d’anciens GPU AMD, le support de la manette Steam Controller de 2026, ou encore des améliorations de l’ordonnanceur pour les processeurs hybrides et une gestion plus unifiée des types de cœurs Intel et AMD. Le noyau intègre également un pilote pour la manette MSI Claw, un pilote HID-HyperX pour l’état de coupure du micro HyperX QuadCast 2, et la prise en charge du commutateur de mode tablette dans le pilote AMD Sensor Fusion Hub.

Du mieux pour certains systèmes de fichiers

Le noyau Linux 7.3 introduit en outre un nouveau système de fichiers particulier : failfs. Il se veut le pendant de nullfs et fait échouer toute opération l’atteignant avec l’erreur EOPNOTSUPP (chemins absolus, liens symboliques et chemins relatifs au répertoire courant). Pour son auteur, Christian Brauner, l’intérêt est de permettre aux processus de se défaire entièrement de leur état de système de fichiers. Ainsi, un processus dont la racine ou le répertoire courant est dans failfs doit ancrer chaque résolution de chemin sur un descripteur de fichier explicite.

On reste dans les systèmes de fichiers avec une série d’améliorations pour ceux déjà en place. Le noyau 7.3 inclut par exemple une hausse des performances (parfois significatives selon les scénarios) pour btrfs que Phoronix avait repérée à la sortie de la première Release Candidate fin aout. Alors que le code de support des systèmes EFS et FreeVxFS est supprimé, celui pour ntfs3 reçoit d’importantes améliorations, dont la prise en charge des flux de données alternatifs ainsi qu’un début de durcissement pour sa sécurité.

Parmi les autres changements, on remarque en outre des travaux significatifs sur le support de SMB, qui peut gérer en option Time Machine (le système de sauvegarde de macOS). Le serveur SMB intégré au noyau (ksmbd) gagne aussi la fenêtre de séquence des commandes SMB2, le rejeu des requêtes SMB3, le chiffrement SMB3 par partage et le chiffrement pour SMB Direct (RDMA). À la sortie de la Release Candidate 3, Linus Torvalds avait indiqué qu’un nombre important de correctifs était intégré pour SMB (ainsi que pour XFS).

LTS ou pas LTS ?

Cette version 7.3 est donc disponible, mais sa récupération réelle dépend fortement de la distribution utilisée. De nombreux systèmes ne proposent pas immédiatement les nouveaux noyaux et attendent leur version suivante pour l’intégrer. D’autres, notamment celles en rolling release, proposent les nouveaux noyaux très rapidement en général.

Enfin, un mot sur la prochaine version 7.4. Sa fenêtre d’intégration vient d’ouvrir et sa publication doit se faire vers la fin décembre. Cette version sera à nouveau importante pour le support matériel, avec par exemple l’activation du HDMI 2.1 sur les Radeon, le support des NPU dans les Ryzen AI Max 400, la poursuite des travaux sur le pilote NVIDIA Nova (pour remplacer l’actuel Nouveau), des optimisations sur la mémoire, ou encore la prise en charge initiale des puces M4 et A18 pro d’Apple.

On ne sait pas encore si cette version sera la nouvelle LTS (Long Term Support) ou s’il s’agira de la 7.3 qui vient de sortir.

Avec Minions, Apple veut mettre à profit les GPU inactifs des Mac pour l’inférence

19 octobre 2026 à 07:21
Moi, moche et virtualisé
Avec Minions, Apple veut mettre à profit les GPU inactifs des Mac pour l’inférence

Apple a publié un article de recherche sur Minions, une infrastructure permettant d’agréger les ressources GPU inutilisées sur des grappes de Mac dotés de puce Apple Silicon. Si le concept n’a rien de nouveau, les travaux d’Apple prolongent l’existant et inscrivent un peu plus les Mac dans le paysage de l’IA.

Les Mac sont décidément appréciés par les entreprises désireuses de faire tourner localement des LLM plus ou moins gros. Pourquoi les Mac ? Parce qu’ils embarquent une mémoire dite « unifiée », servant à la fois pour les parties CPU et GPU des puces Apple Silicon. Si votre Mac est équipé de 32 Go de mémoire vive, le GPU peut puiser dedans. Cette mémoire est certes moins rapide que la VRAM des cartes graphiques dédiées (sans même parler de la HBM), mais ce scénario d’usage compense par le volume.

Apple sait que ses Mac Mini et Studio partent comme des petits pains auprès d’entreprises comme OpenAI, Anthropic et Meta. C’est dans ce contexte qu’elle a mis en ligne un document de recherche (prépublication sur Arxiv) exposant le fonctionnement de Minions, une infrastructure GPU virtuelle dédiée aux charges d’inférence d’apprentissage automatique à grande échelle.

Rassembler l’inaction

L’architecture proposée repose sur quatre éléments. D’abord, un serveur central reçoit les requêtes via une interface web ou des API (REST). Il s’occupe de les valider puis de les découper de manière asynchrone en sous-tâches stockées dans une base PostgreSQL. En d’autres termes, le serveur est chargé de créer une file d’attente.

Ensuite, les exécuteurs. Ils tournent sur les Mac mis à contribution et traitent localement les sous-tâches sur le GPU, avant d’écrire le résultat des calculs dans une zone de stockage S3. Ils n’accèdent jamais directement à la base PostgreSQL : ils réservent des sous-tâches en utilisant l’API du serveur, via une table de la base dotée d’une contrainte d’unicité. Même chose pour mettre à jour l’état de la base, envoyer leur signal de vie (un message bref envoyé au superviseur pour indiquer qu’il fonctionne encore) et livrer leurs résultats.

Le superviseur, justement, est ici nommé « Watchdog » (littéralement « chien de garde »). Son rôle est de surveiller les exécuteurs en cours de traitement et de remettre en file d’attente les sous-tâches des exécuteurs devenus muets. Ce silence peut provenir de multiples causes : perte réseau, veille, extinction, arrêt volontaire, etc. Ce fonctionnement autorise donc une certaine souplesse.

Quant au dernier composant, c’est tout simplement le tableau de bord pour le suivi de l’ensemble en temps réel.

De fortes limitations

Le tout permet, comme relevé par Apple Insider, de mettre à disposition la puissance inutilisée des GPU pour les mettre à contribution lors d’un travail d’inférence. Ainsi, des équipes qui lancent de grands lots asynchrones d’inférence (index de recherche, génération de texte en masse pour l’évaluation ou l’étiquetage…) n’ont plus besoin d’attendre qu’une grappe de GPU se libère. C’est du moins le fonctionnement sur le papier.

Si le document est intéressant dans le fond, il est aussi très court. Apple ne fournit aucune information mesurée : pas de tests de débits, pas de coût énergétique, de taux de reprise ou aucune comparaison quelle qu’elle soit. Il est donc difficile de se rendre compte des performances.

Les cas présentés ont également un périmètre limité. La publication n’évoque que deux types de charges : les modèles de vecteurs de représentation chargés via la bibliothèque Transformers de Hugging Face, et la génération de texte via Ollama. Il n’y a pas d’ordonnanceur central, il ne s’agit donc pas d’un modèle découpé et réparti entre les machines.

En fait, chaque exécuteur doit pouvoir faire tourner intégralement le modèle en local, ce qui limite d’autant les cas. La mémoire a beau être universelle sur les Mac Apple Silicon, sa quantité détermine directement ce que l’on peut y faire résider. Pas question par exemple d’y faire tourner le tout récent Muse Spark Open.

Et si vous vous posez la question : non, l’entrainement n’est pas pris en charge, en tout cas pour l’instant. Apple compte prendre en charge l’entraînement distribué à l’avenir, sans plus de détails.

Quel intérêt ?

Au sein d’une organisation, l’infrastructure présentée peut avoir des avantages, mais il ne s’agit pas d’un projet « magique » capable de fonctionner avec tous les modèles. Il y a quand même plusieurs avantages : pas d’achat de GPU dédiés, un coût d’infrastructure considéré comme « nul », une capacité générale qui grandit avec le nombre de Mac présents sur place, ou encore un fonctionnement local puisque les données ne sortent pas de l’organisation.

L’intérêt d’Apple est d’avancer discrètement sur l’argument commercial que les Mac sont des machines taillées pour l’IA. Sur ce point, la présentation de Minions rejoint les annonces autour de Muse Spark Open et du rapprochement avec Meta, Apple ayant publié des mesures et de la documentation MLX.

En filigrane, le papier raconte également une autre histoire : celle des propres limites d’Apple. L’entreprise le dit elle-même dans son article, elle manque de GPU centraux. Ainsi, avant que Minions ne soit utilisé (montrant au passage que l’infrastructure n’est pas que théorique), certaines tâches d’inférence pouvaient attendre plus de 10 heures avant de commencer. Avec Minions, le temps ne serait plus que de quelques minutes, mais Apple ne donne aucun détail supplémentaire.

Dans l’absolu, Minions ne crée aucune rupture, car la récupération de cycles, le calcul bénévole ou encore l’inférence répartie existent déjà. C’est dans les grandes lignes le schéma adopté par l’infrastructure de calcul distribué BOINC, qui exploite les GPU depuis vingt ans. On peut également citer Petals pour répartir un grand modèle en blocs de couches sur des machines bénévoles réparties sur internet. Mais l’idée pourrait séduire les organisations déjà dotées de nombreux Mac, surtout s’ils sont récents et accompagnés d’une bonne quantité de mémoire.

« Plus largement, Minions ouvre une perspective inédite pour la communauté de l’apprentissage automatique : si les appareils macOS inactifs, à l’échelle de plusieurs organisations, voire de la communauté mondiale, pouvaient être fédérés de manière sûre, ils formeraient un vaste parc de GPU partagé, au bénéfice de l’ensemble de l’écosystème », indique Apple dans une conclusion plus ambitieuse.

Avec Minions, Apple veut mettre à profit les GPU inactifs des Mac pour l’inférence

19 octobre 2026 à 07:21
Moi, moche et virtualisé
Avec Minions, Apple veut mettre à profit les GPU inactifs des Mac pour l’inférence

Apple a publié un article de recherche sur Minions, une infrastructure permettant d’agréger les ressources GPU inutilisées sur des grappes de Mac dotés de puce Apple Silicon. Si le concept n’a rien de nouveau, les travaux d’Apple prolongent l’existant et inscrivent un peu plus les Mac dans le paysage de l’IA.

Les Mac sont décidément appréciés par les entreprises désireuses de faire tourner localement des LLM plus ou moins gros. Pourquoi les Mac ? Parce qu’ils embarquent une mémoire dite « unifiée », servant à la fois pour les parties CPU et GPU des puces Apple Silicon. Si votre Mac est équipé de 32 Go de mémoire vive, le GPU peut puiser dedans. Cette mémoire est certes moins rapide que la VRAM des cartes graphiques dédiées (sans même parler de la HBM), mais ce scénario d’usage compense par le volume.

Apple sait que ses Mac Mini et Studio partent comme des petits pains auprès d’entreprises comme OpenAI, Anthropic et Meta. C’est dans ce contexte qu’elle a mis en ligne un document de recherche (prépublication sur Arxiv) exposant le fonctionnement de Minions, une infrastructure GPU virtuelle dédiée aux charges d’inférence d’apprentissage automatique à grande échelle.

Rassembler l’inaction

L’architecture proposée repose sur quatre éléments. D’abord, un serveur central reçoit les requêtes via une interface web ou des API (REST). Il s’occupe de les valider puis de les découper de manière asynchrone en sous-tâches stockées dans une base PostgreSQL. En d’autres termes, le serveur est chargé de créer une file d’attente.

Ensuite, les exécuteurs. Ils tournent sur les Mac mis à contribution et traitent localement les sous-tâches sur le GPU, avant d’écrire le résultat des calculs dans une zone de stockage S3. Ils n’accèdent jamais directement à la base PostgreSQL : ils réservent des sous-tâches en utilisant l’API du serveur, via une table de la base dotée d’une contrainte d’unicité. Même chose pour mettre à jour l’état de la base, envoyer leur signal de vie (un message bref envoyé au superviseur pour indiquer qu’il fonctionne encore) et livrer leurs résultats.

Le superviseur, justement, est ici nommé « Watchdog » (littéralement « chien de garde »). Son rôle est de surveiller les exécuteurs en cours de traitement et de remettre en file d’attente les sous-tâches des exécuteurs devenus muets. Ce silence peut provenir de multiples causes : perte réseau, veille, extinction, arrêt volontaire, etc. Ce fonctionnement autorise donc une certaine souplesse.

Quant au dernier composant, c’est tout simplement le tableau de bord pour le suivi de l’ensemble en temps réel.

De fortes limitations

Le tout permet, comme relevé par Apple Insider, de mettre à disposition la puissance inutilisée des GPU pour les mettre à contribution lors d’un travail d’inférence. Ainsi, des équipes qui lancent de grands lots asynchrones d’inférence (index de recherche, génération de texte en masse pour l’évaluation ou l’étiquetage…) n’ont plus besoin d’attendre qu’une grappe de GPU se libère. C’est du moins le fonctionnement sur le papier.

Si le document est intéressant dans le fond, il est aussi très court. Apple ne fournit aucune information mesurée : pas de tests de débits, pas de coût énergétique, de taux de reprise ou aucune comparaison quelle qu’elle soit. Il est donc difficile de se rendre compte des performances.

Les cas présentés ont également un périmètre limité. La publication n’évoque que deux types de charges : les modèles de vecteurs de représentation chargés via la bibliothèque Transformers de Hugging Face, et la génération de texte via Ollama. Il n’y a pas d’ordonnanceur central, il ne s’agit donc pas d’un modèle découpé et réparti entre les machines.

En fait, chaque exécuteur doit pouvoir faire tourner intégralement le modèle en local, ce qui limite d’autant les cas. La mémoire a beau être universelle sur les Mac Apple Silicon, sa quantité détermine directement ce que l’on peut y faire résider. Pas question par exemple d’y faire tourner le tout récent Muse Spark Open.

Et si vous vous posez la question : non, l’entrainement n’est pas pris en charge, en tout cas pour l’instant. Apple compte prendre en charge l’entraînement distribué à l’avenir, sans plus de détails.

Quel intérêt ?

Au sein d’une organisation, l’infrastructure présentée peut avoir des avantages, mais il ne s’agit pas d’un projet « magique » capable de fonctionner avec tous les modèles. Il y a quand même plusieurs avantages : pas d’achat de GPU dédiés, un coût d’infrastructure considéré comme « nul », une capacité générale qui grandit avec le nombre de Mac présents sur place, ou encore un fonctionnement local puisque les données ne sortent pas de l’organisation.

L’intérêt d’Apple est d’avancer discrètement sur l’argument commercial que les Mac sont des machines taillées pour l’IA. Sur ce point, la présentation de Minions rejoint les annonces autour de Muse Spark Open et du rapprochement avec Meta, Apple ayant publié des mesures et de la documentation MLX.

En filigrane, le papier raconte également une autre histoire : celle des propres limites d’Apple. L’entreprise le dit elle-même dans son article, elle manque de GPU centraux. Ainsi, avant que Minions ne soit utilisé (montrant au passage que l’infrastructure n’est pas que théorique), certaines tâches d’inférence pouvaient attendre plus de 10 heures avant de commencer. Avec Minions, le temps ne serait plus que de quelques minutes, mais Apple ne donne aucun détail supplémentaire.

Dans l’absolu, Minions ne crée aucune rupture, car la récupération de cycles, le calcul bénévole ou encore l’inférence répartie existent déjà. C’est dans les grandes lignes le schéma adopté par l’infrastructure de calcul distribué BOINC, qui exploite les GPU depuis vingt ans. On peut également citer Petals pour répartir un grand modèle en blocs de couches sur des machines bénévoles réparties sur internet. Mais l’idée pourrait séduire les organisations déjà dotées de nombreux Mac, surtout s’ils sont récents et accompagnés d’une bonne quantité de mémoire.

« Plus largement, Minions ouvre une perspective inédite pour la communauté de l’apprentissage automatique : si les appareils macOS inactifs, à l’échelle de plusieurs organisations, voire de la communauté mondiale, pouvaient être fédérés de manière sûre, ils formeraient un vaste parc de GPU partagé, au bénéfice de l’ensemble de l’écosystème », indique Apple dans une conclusion plus ambitieuse.

❌