Un gestionnaire de paquets devenu incontournable
Lancé en 2009 par Max Howell, Homebrew a conquis le monde du développement Apple en quelques années, au point de devenir un réflexe pour tout développeur travaillant sous macOS. Son succès tient à une promesse simple : installer des logiciels open source en une commande, sans les tracas d'une compilation manuelle ni les lourdeurs d'un gestionnaire de paquets traditionnel. Aujourd'hui, Homebrew revendique des millions d'utilisateurs actifs et un catalogue de plus de six mille formules officielles, sans compter les milliers de versions tierces hébergées dans des dépôts communautaires.
Mais ce succès massif ne doit pas masquer les fragilités structurelles que les experts du domaine pointent depuis plusieurs années. Car si Homebrew reste l'outil par défaut, il n'est plus le seul, et son architecture commence à montrer ses limites face à des exigences modernes de reproductibilité et d'isolation.
Ce que les experts reprochent à Homebrew
Les critiques les plus sérieuses portent sur trois aspects fondamentaux : la gestion des dépendances, l'absence d'isolation, et la fragilité de l'écosystème face aux mises à jour système d'Apple.
D'abord, la gestion des dépendances. Homebrew installe les paquets dans des répertoires partagés (/usr/local sur Intel, /opt/homebrew sur Apple Silicon). Ce choix, pragmatique à l'origine, devient un problème dès que plusieurs projets nécessitent des versions différentes d'une même bibliothèque. Max Howell lui-même a reconnu, dans plusieurs interviews, que Homebrew n'a jamais été conçu pour la gestion d'environnements isolés. Il s'agit d'un gestionnaire de paquets système, pas d'un gestionnaire d'environnements de développement. La nuance est essentielle : Homebrew installe pour tous les projets, sans possibilité de versionnement par contexte.
Ensuite, l'absence d'isolation réelle. Contrairement à Nix ou Guix, Homebrew ne garantit pas la reproductibilité des installations. Un brew install effectué aujourd'hui peut produire un résultat différent du même exécuté dans six mois, parce que les formules évoluent, que les dépendances amont se mettent à jour, et que les binaires précompilés (bottles) changent au gré des versions. Pour les équipes qui cherchent à garantir un environnement identique entre développement, intégration continue et production, cette caractéristique est un obstacle. Les experts en ingénierie des builds, comme ceux de la fondation NixOS, considèrent cette absence de reproductibilité comme un défaut rédhibitoire pour les déploiements critiques.
Enfin, la fragilité face aux mises à jour système. Chaque version majeure de macOS (et particulièrement les transitions d'architecture, comme le passage d'Intel à Apple Silicon) provoque des vagues d'incompatibilités. Les formules doivent être mises à jour, les binaires recompilés, les chemins d'installation ajustés. Homebrew réagit généralement en quelques semaines, mais cette réactivité repose sur une communauté de mainteneurs bénévoles dont les ressources sont limitées. En juillet 2024, par exemple, plusieurs formules liées à Python et Ruby sont restées cassées pendant près d'un mois après une mise à jour de macOS Sonoma, obligeant les développeurs à recourir à des solutions manuelles.
Alternatives et avenir : que recommandent les experts
Face à ces limites, plusieurs alternatives gagnent du terrain, et les experts ne manquent pas de les recommander selon les contextes. Nix, en particulier, est systématiquement cité comme la référence pour les environnements reproductibles. Déjà adopté par des équipes d'ingénierie chez Shopify, GitHub ou Zalando, Nix permet de décrire l'intégralité d'un environnement dans un fichier de configuration déclaratif, garantissant que deux machines (ou deux instants) produisent exactement le même résultat. Sa courbe d'apprentissage est plus raide que celle de Homebrew, mais pour des projets où la fiabilité de l'environnement est critique, l'investissement en vaut la peine.
MacPorts, l'ancêtre toujours actif, conserve une base d'utilisateurs fidèles, principalement parmi les administrateurs système. Son approche plus rigoureuse de la gestion des dépendances et son adhésion plus stricte aux conventions Unix séduisent ceux qui travaillent sur des infrastructures legacy.
Pour les développeurs qui cherchent simplement à éviter les conflits entre projets sans changer d'outil principal, l'usage de brew bundle couplé à des Brewfile par projet constitue un compromis acceptable. Cela n'offre pas l'isolation de Nix, mais cela documente au moins les dépendances explicites et facilite la reproduction d'un environnement à partir d'une base Homebrew commune.
Les experts s'accordent sur un point : Homebrew n'est pas près de disparaître. Sa simplicité d'usage et son adoption massive en font un outil difficile à déloger, surtout pour les développeurs individuels ou les petites équipes. En revanche, pour les organisations qui doivent garantir la reproductibilité et la stabilité de leurs environnements sur le long terme, la recommandation est unanime : investir dans Nix ou Docker dès que possible, et réserver Homebrew aux usages personnels légers.
Ce constat n'est pas un rejet de Homebrew, mais sa mise en perspective. L'outil remarquable qu'il reste aujourd'hui est le fruit de quinze ans d'évolution organique, portée par une communauté active. Il assume son périmètre : être le gestionnaire de paquets le plus simple pour les développeurs macOS et Linux. Ce qu'il ne fait pas — l'isolation, la reproductibilité, la gestion multi-environnements — il ne l'a jamais promis. Le piège serait d'attendre de lui ce pour quoi il n'a pas été conçu.
Notre avis est tranché : Homebrew reste le meilleur choix pour l'installation rapide d'outils de développement sur macOS, à condition de connaître ses limites et de ne pas hésiter à le compléter par Nix ou Docker dès que les besoins en isolation se font sentir. La solution n'est pas dans l'abandon d'un outil pour un autre, mais dans la combinaison réfléchie des deux.