VM macOS presque à vitesse native & Neural Engine bridé en virtualisation - Actualités Hacker News (2 mai 2026)

On commence par une bonne nouvelle pour ceux qui vivent avec plusieurs macOS à la fois. The Eclectic Light Company a refait des mesures de performance de virtualisation sur Apple Silicon, cette fois avec macOS 26.4.1 « Tahoe », sur un Mac mini M4 Pro. Le résultat marquant : sur des usages courants, la VM peut être très proche du natif. En benchmark, le CPU en single-core est quasiment au niveau de l’hôte, et côté GPU via Metal, on n’est pas loin non plus. En clair : pour développer, tester des apps, isoler des environnements, ou simplement faire tourner un second macOS, la sensation de « machine au rabais » s’estompe. Ce qui compte ici, ce n’est pas un score de plus : c’est l’idée que la virtualisation devient un mode d’usage normal, pas une concession. Et ça peut changer les habitudes des équipes qui, jusque-là, préféraient jongler avec plusieurs machines ou des dual-boot impossibles sur Mac moderne.

Mais dans cette même série de tests, il y a un point faible qui saute aux yeux : le Neural Engine en VM. Sur certains scénarios, les résultats s’écroulent par rapport à la machine hôte, notamment sur des formats souvent utilisés pour accélérer l’IA. La conséquence pratique, c’est que si vous comptez sur l’accélération « IA dédiée » pour des charges locales — inference, traitement multimédia assisté, certaines briques ML — la VM risque de vous forcer à retomber sur le CPU et le GPU. Ce n’est pas forcément un drame : beaucoup d’outils savent déjà très bien exploiter GPU et CPU. Mais c’est un rappel important : “VM proche du natif” ne veut pas dire “accès identique à tous les accélérateurs”. Et c’est typiquement le genre de détail qui fait la différence entre un environnement de dev confortable et un environnement de prod fidèle.

Toujours sur macOS virtualisé, l’article insiste aussi sur un aspect beaucoup plus terre-à-terre : les ressources minimales. Apparemment, macOS reste utilisable pour des tâches légères même avec peu de cœurs et peu de RAM — ce qui peut séduire ceux qui veulent juste un macOS « utilitaire », pour une app spécifique ou un test rapide. Le vrai goulot d’étranglement, en revanche, c’est le stockage. L’auteur observe qu’il faut une marge confortable pour que les mises à jour se passent bien, sinon on se retrouve vite à gérer des échecs et des nettoyages. La nuance intéressante, c’est que les fichiers clairsemés d’APFS peuvent limiter l’espace réellement consommé. Autrement dit : de petits SSD ne condamnent pas forcément l’idée de VM, mais ils rendent la discipline de stockage beaucoup plus importante.

Changement total de décor : Windows et ses variables d’environnement TMP et TEMP. Raymond Chen, vétéran Microsoft, explique pourquoi ce doublon existe encore aujourd’hui. Et la réponse, c’est : parce que l’histoire a de l’inertie. À l’époque des micro-ordinateurs et des premiers MS-DOS, il n’y avait pas de standard unique, et différents programmes ont adopté, chacun de leur côté, soit TEMP, soit TMP. Puis le système lui-même a dû choisir un endroit pour écrire des fichiers temporaires — notamment quand les pipes sont arrivés — et ça a cristallisé certains usages. Mais ensuite, les API Windows ont ajouté leurs propres préférences, parfois dans l’autre sens. Résultat : il n’y a pas de “bonne” variable universelle, seulement des compatibilités empilées. Pourquoi c’est intéressant ? Parce que ça illustre un principe qu’on oublie facilement : les plateformes grand public sont souvent des musées vivants. Et quand vous déployez des applis en entreprise, ou que vous dépannez un outil récalcitrant, ce genre de détail peut expliquer des comportements apparemment absurdes — comme des fichiers temporaires qui n’atterrissent jamais là où vous l’attendiez.

Côté langages et écosystèmes, un projet open source attire l’attention : dotcl, un Common Lisp qui compile vers le CIL, c’est-à-dire la “langue” intermédiaire de .NET. L’idée n’est pas juste de faire tourner du Lisp : c’est de pouvoir cohabiter avec l’univers .NET sans friction, d’embarquer un runtime Lisp dans une appli, ou même de produire des composants qui parlent naturellement aux frameworks modernes. Pourquoi ça compte ? Parce qu’on voit de plus en plus d’équipes vouloir réutiliser des bibliothèques existantes, cibler plusieurs OS, et éviter les réécritures coûteuses. Un pont pratique entre un langage historique — apprécié pour sa flexibilité — et un écosystème industriel comme .NET, ça ouvre des options : prototypage rapide sans renoncer à l’intégration, ou modernisation progressive sans tout jeter.

Enfin, un mot sur une tendance qui revient fort : traiter les dashboards comme du code. Un outil open source propose de définir des tableaux de bord avec des fichiers versionnables, avec une logique plus proche du développement logiciel que du “clic-clic” dans une interface. L’intérêt est assez simple : revue de code, reproductibilité, environnements de test, et surtout moins de dépendance à une configuration invisible. Le point qui mérite l’attention, c’est l’ajout d’une couche sémantique : définir une fois des métriques et des dimensions, puis les réutiliser, ce qui peut réduire les divergences entre équipes. Et, sans surprise en 2026, on voit aussi apparaître des flux de travail avec un agent IA pour accélérer la création — à condition de garder la sortie sous forme de code, donc auditée et standardisée. C’est un bon signal : l’IA peut aider, mais le contrôle et la traçabilité restent au centre.