Homebrew sur macOS - Le guide ultime pour un Mac de dev propre

Homebrew reste, à mon avis, la manière la plus propre d’installer des outils de développement sur macOS sans transformer le poste en patchwork d’installateurs et de dépendances oubliées. Pour un usage DevOps, il apporte surtout une chose précieuse: un socle reproductible pour les utilitaires en ligne de commande, les applications de travail et certains services locaux. Ici, je passe en revue l’installation correcte, le choix entre formule et cask, les erreurs qui font perdre du temps et la bonne façon d’en faire un outil durable sur un Mac de développement.

Ce que Homebrew change vraiment sur macOS

Je vois Homebrew comme une couche de distribution propre, pas comme un gadget. macOS fournit un bon système, mais pas la bibliothèque complète d’outils que l’on veut pour travailler vite sur un projet backend, une stack JavaScript ou un environnement DevOps. Homebrew comble ce manque avec un modèle simple: les paquets arrivent sous forme de formulae pour les outils en ligne de commande et de casks pour les applications macOS.

Le point que beaucoup sous-estiment, c’est l’organisation interne. Homebrew installe chaque paquet dans son propre emplacement, puis expose ce qu’il faut via un préfixe unique. Résultat: on évite de disperser des fichiers dans tout le système, et on garde une machine plus facile à maintenir. C’est aussi pour cela que je l’apprécie sur un poste de dev: je peux installer, mettre à jour et retirer un outil sans improviser.

Autre avantage concret: Homebrew installe très souvent des bottles, c’est-à-dire des binaires déjà compilés. Quand une bottle existe, l’installation est rapide. Quand elle n’existe pas, Homebrew peut compiler, mais l’opération est plus lente. Cette différence compte sur un Mac fraîchement préparé ou sur une machine d’équipe qu’il faut remettre en route vite. Avec ce cadre en tête, l’installation propre devient presque mécanique.

Installer Homebrew proprement sur un Mac récent

La documentation officielle de Homebrew insiste sur quelques prérequis simples: un Mac Apple Silicon ou Intel 64 bits, une version récente de macOS, les Xcode Command Line Tools et un shell correctement initialisé. En pratique, je commence toujours par là, parce que la plupart des erreurs ne viennent pas de Homebrew lui-même, mais d’un environnement incomplet.

Voici l’ordre que je recommande pour éviter les surprises:

• Installer les Xcode Command Line Tools avec xcode-select --install si elles ne sont pas déjà présentes.
• Lancer l’installateur officiel de Homebrew ou, sur un parc géré, utiliser le paquet .pkg officiel.
• Ajouter la ligne d’initialisation du shell dans le bon fichier de démarrage, souvent ~/.zprofile ou ~/.zshrc selon le terminal.
• Vérifier ensuite le bon fonctionnement avec brew --version puis brew doctor.

La ligne la plus importante après l’installation est celle-ci:

eval "$(/opt/homebrew/bin/brew shellenv)"

Sur un Mac Intel, le chemin devient généralement:

eval "$(/usr/local/bin/brew shellenv)"

Je préfère cette vérification explicite au bricolage de PATH au hasard. Sur Apple Silicon, le préfixe standard est /opt/homebrew; sur Intel, c’est /usr/local. Si tu confonds les deux, tu te retrouves avec un brew introuvable, des paquets installés au mauvais endroit ou des messages de compatibilité qui n’ont rien de mystérieux. Une fois le socle en place, le vrai gain arrive au moment de choisir quoi installer et sous quelle forme.

Installer un outil, une application ou un service local

C’est ici que Homebrew devient vraiment utile au quotidien. Pour moi, la règle est simple: une formule pour un outil CLI, un cask pour une application macOS, et un Brewfile quand je veux reproduire un environnement complet. Si tu hésites entre plusieurs approches, pars du besoin réel plutôt que de la syntaxe la plus courte.

Quand je ne connais pas exactement le nom du paquet, je commence par brew search et brew info. C’est plus fiable que de deviner. La recherche me donne le nom exact, et brew info me montre si j’ai affaire à une formule, à un cask, à un service compatible ou à un paquet qui demande un peu plus d’attention.

Je regarde aussi l’existence d’une bottle avant d’installer un outil lourd. Si le paquet est livré en binaire, l’installation est souvent quasi immédiate. S’il faut compiler, il faut accepter un temps plus long et parfois des dépendances supplémentaires. C’est une nuance importante en DevOps: tous les paquets ne coûtent pas le même temps ni le même niveau de maintenance.

Pour un service local comme PostgreSQL ou Redis, Homebrew peut aussi servir de lanceur, via brew services quand le paquet le supporte. Je trouve ça pratique pour un poste de développement, moins pour une machine qui doit rester parfaitement figée. Et quand on passe d’un poste individuel à un workflow d’équipe, la discipline de gestion devient plus importante que la simple commande d’installation.

Les erreurs les plus fréquentes et comment les corriger

La majorité des blocages que je vois reviennent toujours aux mêmes causes. Ce n’est pas un reproche à Homebrew, c’est juste la réalité des Macs utilisés comme machines de travail: shell mal configuré, outils Apple manquants, architecture mal comprise ou attentes trop proches d’un gestionnaire de paquets Linux.

• brew: command not found - le shell n’a pas chargé la ligne brew shellenv. Je vérifie d’abord le fichier de démarrage du shell, puis je rouvre le terminal.
• Demande de mot de passe ou de sudo - Homebrew doit fonctionner sans bricolage de droits après l’installation initiale. Si un paquet courant demande des contorsions, je m’arrête et je vérifie le préfixe.
• Erreur liée aux Command Line Tools - si Xcode CLT manque, installe-les avant de relancer quoi que ce soit.
• Mauvais préfixe - sur Apple Silicon, je veux voir /opt/homebrew; sur Intel, /usr/local. Mélanger les deux casse rapidement le PATH.
• Paquet introuvable - le nom peut avoir changé, ou le logiciel peut venir d’un tap externe. Dans ce cas, je cherche le nom exact au lieu d’insister à l’aveugle.
• MacOS trop ancien ou matériel non supporté - Homebrew fonctionne le mieux sur les configurations officiellement prises en charge. Sur un poste hors cible, les avertissements de brew doctor deviennent plus fréquents.

Le réflexe que je garde avant d’ouvrir un ticket est simple: brew update, puis brew doctor, puis vérification des Command Line Tools et du préfixe. Dans la plupart des cas, le problème est déjà visible à ce stade. C’est aussi ce qui rend Homebrew fiable au quotidien: il te dit assez vite si ton environnement est propre ou s’il commence à dériver.

Le bon usage dans un workflow DevOps

Sur un poste individuel, Homebrew sert à installer vite. Dans une équipe, il sert surtout à standardiser. La pièce que je recommande presque systématiquement, c’est le Brewfile. Ce fichier décrit l’état attendu de la machine: les formules, les casks et parfois les taps. Autrement dit, on ne documente plus seulement ce qu’on a installé, on documente ce qu’on veut retrouver.

Un Brewfile minimal ressemble à ça:

brew "git"
brew "jq"
cask "visual-studio-code"

À partir de là, la logique devient très saine: je génère le fichier une fois sur une machine de référence avec brew bundle dump --describe --force, puis je le garde dans le dépôt du projet ou dans mon dépôt de configuration. Sur une nouvelle machine, brew bundle install recrée l’environnement beaucoup plus vite qu’une suite de commandes rédigées à la main.

Je m’en sers aussi pour le cycle de vie: brew update pour rafraîchir les définitions, brew upgrade pour mettre à jour les paquets, puis brew cleanup pour éviter l’accumulation d’anciennes versions. Ce trio suffit à garder un poste de développement propre sans y passer sa journée. Et si un outil doit rester actif en arrière-plan, Homebrew peut parfois le gérer comme service local, ce qui reste utile pour une base de données de dev ou un cache de test.

Il y a quand même une limite importante: Homebrew n’est pas un lockfile applicatif au sens strict. Si ton besoin exige un environnement figé au bit près, je préfère une image Docker, une VM ou une image système préparée à l’avance. Pour un poste de développement, en revanche, Homebrew offre le bon compromis entre souplesse, vitesse et maintien dans le temps.

Le réflexe que je garde pour un Mac de développement stable

Quand je prépare un Mac pour du travail sérieux, je garde une règle très simple: je laisse Homebrew gérer le socle, et je réserve les installateurs manuels aux cas où il apporte une vraie valeur. Pour les outils CLI, je prends une formule. Pour les applications graphiques, je prends un cask. Pour une machine d’équipe ou un poste à recréer souvent, je passe par un Brewfile sans hésiter.

Le meilleur gain n’est pas seulement le temps d’installation. C’est la capacité à remettre la machine en état sans réinventer sa configuration à chaque fois. Tant que le besoin reste celui-là, Homebrew est le bon outil. Si le besoin devient plus strict qu’un poste de dev, je sors du cadre et je passe à un environnement conteneurisé ou à une image figée. C’est cette frontière, bien posée dès le départ, qui évite les Macs bricolés et les journées perdues à corriger un PATH mal né.