Exécuter des logiciels macOS sur Linux sans Mac : le projet open source Kakehashi valide plus de 200 outils

La règle établie voulant que les logiciels Apple ne fonctionnent que sur du matériel Apple vient de subir sa première véritable fissure. Début août 2026, un projet open source nommé Kakehashi (« le pont » en japonais) a atteint la une de Hacker News, accumulant 156 points et 34 commentaires. Son principe tient en une phrase : exécuter des logiciels macOS natifs directement sur une machine Linux ARM, sans installer le système macOS ni utiliser de machine virtuelle (VM). Actuellement, plus de 200 outils en ligne de commande intégrés à macOS fonctionnent correctement, et l’utilitaire d’archivage 7-Zip s’exécute sans erreur. Pour la première fois, un effort technique rigoureux s’attaque directement au verrouillage logiciel d’Apple.

Figure : Le fil de lancement de Kakehashi sur Hacker News, où l’auteur a répondu aux questions sur l’avancement du projet. Source : news.ycombinator.com

Pourquoi cela semblait impossible

Pour la plupart des utilisateurs, logiciels Apple et matériel Mac sont indissociables : une application conçue pour Mac refuse de se lancer sur toute autre machine. Ce comportement n’est pas le fruit du hasard, mais le résultat d’une stratégie de verrouillage (« walled garden ») méticuleusement conçue par Apple.

Le modèle économique d’Apple repose sur le couplage étroit entre la vente de matériel et l’exclusivité logicielle. Le contrat de licence (CLUF) de macOS stipule explicitement que le système d’exploitation ne peut être exécuté que sur du matériel de marque Apple. Installer le système ailleurs constitue une infraction au contrat. Ajouté aux commissions de l’App Store et aux abonnements cloud, chaque Mac acheté fait office de droit d’entrée dans le jardin fermé. Pendant des décennies, utiliser des logiciels macOS sur du matériel tiers nécessitait de choisir entre deux mauvaises options : exécuter une machine virtuelle lourde et gourmande en ressources, ou recourir aux configurations complexes et instables de type Hackintosh.

Kakehashi adopte une troisième voie : ne pas porter le système d’exploitation, mais uniquement l’application.

Fonctionnement : un traducteur au niveau système

Porter des logiciels macOS sur Linux est une tâche complexe en raison des différences de langage système (ABI et appels système). Auparavant, faire communiquer ces deux mondes imposait de transposer l’intégralité de l’environnement utilisateur de macOS.

La clé de Kakehashi repose sur un constat d’architecture : les puces Apple Silicon de la série M et les processeurs des machines Linux ARM partagent la même architecture d’instructions (ARM). Les instructions au niveau du processeur étant identiques, le binaire de l’application s’exécute directement sur le processeur Linux sans émulation CPU. La seule traduction nécessaire intervient lorsque l’application formule des requêtes auprès du système d’exploitation (lecture de fichiers, accès réseau ou allocation mémoire). Kakehashi agit comme un traducteur à cette frontière : lorsqu’une application macOS demande l’ouverture d’un fichier, Kakehashi intercepte la requête, la convertit en appel système Linux équivalent et retourne le résultat au binaire.

Figure : Les puces Apple de la série M et les appareils Linux ARM partagent la même architecture ARM, réduisant considérablement le coût d’exécution binaire. Source : Wikimedia Commons

Ce modèle architectural porte le nom de « couche de compatibilité » (compatibility layer). Son prédécesseur le plus célèbre est Wine, qui permet d’exécuter des applications Windows sous Linux.

Un défi initié il y a 30 ans

En 1993, le projet open source Wine voyait le jour avec un objectif tout aussi audacieux : faire fonctionner les logiciels Windows nativement sous Linux. À l’époque, le scepticisme dominait : reproduire des milliers d’API Windows semblait insurmontable. Pourtant, après trente ans de développement continu, Wine s’est imposé comme une technologie de premier plan.

Aujourd’hui, Wine constitue la brique de base d’écosystèmes majeurs : la console portable Steam Deck de Valve s’appuie sur une version optimisée (Proton) permettant à des centaines de milliers de joueurs d’exécuter des jeux Windows sur un appareil portable Linux. Un projet jugé irréaliste à ses débuts est devenu le fondement d’une plateforme matérielle commerciale.

Kakehashi n’est pas la première tentative de créer un pont vers les logiciels macOS. Un projet antérieur nommé Darling avait exploré cette voie, mais son développement restait lent. Sur Hacker News, l’auteur de Kakehashi a précisé qu’il ne s’agit pas d’un fork de Darling, mais d’une réécriture complète en Rust fonctionnant exclusivement en espace utilisateur avec des privilèges minimaux. L’auteur a également indiqué avoir utilisé des outils d’IA pour accélérer le codage, suscitant des discussions dans les commentaires sur la propreté du code, auxquelles il a répondu en rappelant que l’ensemble du projet est open source et vérifiable par tous.

Un ralentissement de 5,2x est-il rédhibitoire ?

Le benchmark le plus significatif concerne l’utilitaire de compression 7-Zip : lors d’un test de compression portant sur 8 000 fichiers pour un volume de 240 Mo, 7-Zip a produit un résultat rigoureusement exact, mais avec une vitesse 5,2 fois plus lente que la version native Linux (118 secondes contre 22,5 secondes). En parallèle, plus de 200 variantes de la commande curl ont passé les tests automatisés, et les fonctionnalités de base de l’outil Git fourni avec Xcode se sont exécutées correctement.

Si un facteur de 5,2 peut paraître élevé, il s’agit d’un coût classique pour une couche de compatibilité à ses débuts. Le ralentissement provient principalement du changement de contexte lors de l’interception des appels système. Traiter des milliers de petits fichiers multiplie les allers-retours de traduction. Pour des fichiers volumineux avec moins d’appels système, l’écart se réduit à un facteur compris entre 1,1 et 1,2. À ses débuts, Wine accusait des ralentissements bien plus importants. Le développeur a publié une feuille de route visant à optimiser les performances, avec pour prochaines étapes la prise en charge de la chaîne d’outils Xcode complète et du gestionnaire de paquets Homebrew pour macOS.

Des observateurs sur Hacker News rappellent toutefois un défi majeur : Apple modifie ses interfaces système internes à chaque version majeure de macOS, contraignant les couches de compatibilité à un travail d’adaptation permanent face à un système propriétaire.

Portée de cette avancée pour l’écosystème

À plus grande échelle, ce projet illustre la confrontation entre modèles ouverts et écosystèmes fermés. L’éthique de l’open source prône la libre exécution des logiciels sur tout matériel capable de les supporter, tandis qu’Apple défend l’intégration verticale au sein d’un environnement maîtrisé. Kakehashi démontre que les barrières logicielles peuvent être franchies au moyen d’abstractions adaptées.

Si des outils de création exclusifs à macOS (montage vidéo, composition musicale, design) devaient un jour s’exécuter sur du matériel ARM abordable, la valeur perçue du matériel Apple s’en trouverait modifiée. L’histoire de Wine montre que la disponibilité de logiciels sur d’autres plateformes n’a pas affaibli l’écosystème d’origine, mais a renforcé l’usage global de ces applications.

Le niveau de maturité que Kakehashi atteindra reste une question ouverte : l’écart de performance, les évolutions de l’OS et les enjeux de licences représentent des obstacles réels. Néanmoins, l’expérience acquise depuis 1993 rappelle que les évolutions durables débutent souvent par une première fissure technique.

Liens de référence :

• Dépôt GitHub de Kakehashi (wie-project) : Page du projet, README, documentation d’architecture et feuille de route
• Fil de discussion HN (item?id=49145937) : Détails de l’auteur sur 7-Zip, curl, Xcode Git et la relation avec Darling
• Documentation historique officielle de Wine : Présentation du projet sur WineHQ (« Wine Is Not an Emulator »)
• Article Wikipédia sur Wine : Histoire du développement de 1993 à l’intégration sur Steam Deck