Pourquoi j’ai arrêté de traiter le provisioning Mac comme un problème MDM#

Je voulais un truc assez simple : un Mac sort de sa boîte, l’utilisateur se connecte, et quelques minutes plus tard il a un poste prêt.

Pas « enrôlé ». Pas « presque prêt, il reste juste trois scripts à lancer et deux applications à installer ». Prêt.

Dit comme ça, ça ressemble à un sujet MDM. C’est d’ailleurs comme ça que je l’avais abordé au début. On pousse des packages, quelques profils, des scripts, on remet une couche pour les exceptions, puis on finit avec un système qui marche très bien tant qu’on ne cherche pas trop à comprendre dans quel état exact se trouve la machine.

Le problème n’est pas que le MDM ne sait pas faire tout ça. C’est presque l’inverse : il sait suffisamment de choses pour qu’on soit tenté de tout lui confier.

Et c’est là que ça commence à me gêner.

Le MDM n’avait pas besoin de devenir ma source de vérité#

J’avais déjà une bonne partie de mes Mac gérée avec Nix et nix-darwin. Le shell, les outils, Home Manager, les rôles, les variantes par utilisateur : tout ça existait déjà dans un modèle déclaratif.

Recréer la même logique dans Apple Business aurait donné deux sources de vérité.

D’un côté, Nix dit ce que doit contenir un poste. De l’autre, le MDM pousse progressivement des morceaux du même état avec ses propres règles, ses propres dépendances et son propre historique.

Ça finit rarement bien.

J’ai donc gardé une règle très simple : le MDM impose, Nix compose.

Apple Business reste responsable de ce qui doit être imposé de l’extérieur : l’enrôlement, le bootstrap, les configurations de sécurité, les packages indispensables. En revanche, je ne veux pas qu’il sache comment assembler un poste Tech, Direction ou Standard jusque dans le détail des outils utilisateur.

Dans l’onglet Apps du Blueprint, il n’y a volontairement que Determinate Nix et Omnivya Workstation Bootstrap. Les permissions système restent dans une configuration séparée.

Depuis les premiers runs, j’ai quand même ajouté une troisième brique au Blueprint, mais pas une troisième couche de provisioning : un profil de configuration très étroit pour les privilèges dont macOS a réellement besoin. Il gère les Login Items du helper et de l’agent ainsi que le Full Disk Access du helper. L’ordre devient donc plutôt Determinate → privilèges macOS → Bootstrap.

Je trouve la nuance importante : Apple Business continue d’imposer les prérequis de sécurité du poste, mais il ne décrit toujours pas le contenu de la workstation.

Ça peut paraître comme une nuance de vocabulaire. En pratique, ça change complètement la manière de concevoir le provisioning.

Le hostname était devenu une mauvaise abstraction#

L’ancien modèle était très classique : j’avais des machines connues dans l’inventaire et une configuration par hostname.

Ça ressemble à ça :

macbook-zine
  -> utilisateur zine
  -> rôle tech
  -> configuration tech

Pour un petit parc, ce n’est pas absurde du tout. Le problème apparaît au moment où le hostname devient implicitement la clé qui relie la personne, la machine et son rôle.

Un utilisateur peut avoir deux Macs. Un Mac peut être remplacé. Une personne peut changer de rôle. Et surtout, je ne voulais pas devoir ouvrir une PR juste pour déclarer le hostname d’une machine avant qu’elle soit capable de se provisionner.

J’ai donc séparé les trois notions.

Le repository contient désormais les identités connues, les devices connus, et une fonction qui construit une workstation à partir de paramètres.

En gros :

mkWorkstation {
  hostName = "...";
  userName = "...";
  email = "...";
  org = "omnivya";
  role = "tech";
}

Le résultat reste composé de modules communs, du rôle, de l’organisation, des éventuels overrides utilisateur et de quelques particularités device. Mais le premier boot n’a plus besoin que la machine existe déjà dans l’inventaire.

C’est beaucoup plus proche de ce que je voulais : l’inventaire décrit le parc connu, il ne bloque pas l’arrivée d’un nouveau poste.

Le découpage a fini par devenir assez évident#

Une fois ce problème posé correctement, les responsabilités se sont séparées presque toutes seules.

Apple Business prend possession de la machine et pousse le strict nécessaire : Determinate, les privilèges macOS dont le helper a réellement besoin, puis mon Bootstrap.pkg.

Entra répond d’abord à la question « qui est devant ce Mac, et à quel profil cette personne a droit ? ». Il sert maintenant aussi à obtenir un token Azure Storage pour lire le registry privé des profils.

Omnivya Setup fait la colle entre les deux. Il orchestre le premier login, résout le profil, récupère la release correspondante et pilote l’activation.

Et Nix reste responsable de l’état du poste. Selon ce que le registry contient, le Mac peut encore construire localement ou importer directement une closure prébuildée avant activation.

Je préfère largement ce découpage à un gros workflow MDM qui essaie de tout savoir sur tout.

Il y a aussi un avantage très concret : quand quelque chose casse, on sait plus facilement où regarder. Si le package n’est pas arrivé, je regarde Apple Business. Si le rôle ou l’accès au registry ne passent pas, je regarde Entra. Si la closure est mauvaise ou l’activation échoue, je regarde Nix et le helper.

Ça paraît évident après coup. Sur un écran MDM avec vingt étapes qui s’enchaînent, ça l’est beaucoup moins.

Determinate reste séparé#

Autre choix que j’ai gardé assez strict : Determinate Nix est installé séparément du package Omnivya.

Je pourrais techniquement essayer d’embarquer plus de choses dans un énorme bootstrap. Je n’y vois pas beaucoup d’intérêt.

Determinate gère son installation, son daemon et son cycle de vie. Mon package installe l’application d’onboarding, le helper privilégié et ce qu’il faut pour démarrer le parcours au premier login.

Le postinstall ne lance pas un gros nix switch caché en arrière-plan.

Je veux que l’installateur reste un installateur.

Le provisioning lourd arrive ensuite, dans une vraie session utilisateur, avec une interface, de l’état persistant, du retry et des diagnostics.

C’est moins « magique », mais beaucoup plus contrôlable.

Il y a d’ailleurs une asymétrie volontaire entre les deux stockages : le Bootstrap.pkg doit être récupérable par Apple Business avant qu’un utilisateur existe sur la machine, alors que les profils workstation sont dans un container privé lu uniquement après l’auth Entra. Je préfère assumer ces deux contraintes plutôt que d’inventer un mécanisme d’auth commun qui ne correspond à aucun des deux moments du cycle de vie.

Je ne cherche pas vraiment le zero-touch#

On utilise facilement ce terme pour ce genre de sujet, mais ce n’est pas exactement mon objectif.

Je ne cherche pas à supprimer toute interaction humaine. Je cherche à supprimer les interactions inutiles.

Choisir soi-même son rôle dans une liste ? Inutile.

Copier un PAT GitHub ? Inutile.

Ouvrir un terminal pour lancer trois commandes dans le bon ordre ? Inutile.

S’authentifier avec son compte professionnel, en revanche, a du sens. C’est même une étape que je préfère garder explicite : elle marque clairement la frontière entre une machine enrôlée et une identité autorisée à recevoir un environnement donné.

Le parcours que je vise est donc assez simple : le Mac s’enrôle, l’utilisateur se connecte, son identité détermine son profil, puis la configuration s’applique.

Le point important est que chaque étape sache ce qu’elle fait et pourquoi elle le fait.

Et je ne vais pas attendre de reformater tout le parc#

Le chemin propre pour une machine neuve reste évident : erase, ADE, Apple Business, bootstrap, puis Nix.

Mais j’ai déjà des Macs en service. Les laisser dans leur ancien état pendant six mois ou deux ans en attendant leur prochain formatage n’aurait aucun sens.

Je veux donc que le même modèle sache aussi adopter une machine existante.

Dans ce cas, Apple Business n’est simplement pas le point d’entrée. J’installe le même Bootstrap.pkg signé sur le Mac déjà utilisé, Omnivya Setup constate qu’il arrive sur une machine existante, fait un état des lieux, authentifie l’utilisateur et calcule ce qu’il faudrait changer pour rejoindre le profil attendu.

La différence importante, c’est que je ne peux plus raisonner comme sur un disque vierge.

S’il existe déjà une installation Nix que je ne reconnais pas, je ne la supprime pas. Si Homebrew est déjà là, je regarde ce que je peux réutiliser. Si Home Manager va écraser un fichier utilisateur, je veux le savoir avant l’activation. Et je ne renomme pas brutalement la machine juste pour la faire rentrer dans mon inventaire.

Le premier passage devient donc davantage une convergence qu’un provisioning.

Mac existant
   -> Bootstrap.pkg
   -> état des lieux
   -> Entra
   -> profil cible
   -> review / dry-run
   -> convergence
   -> validation

Une fois cette convergence faite, je veux que le poste soit traité exactement comme les autres pour les versions, les updates, le rollback et les diagnostics.

Il restera simplement une information visible : la workstation est conforme, mais le device n’est pas encore passé par ADE.

Workstation     compliant
Management      local adoption
ADE             pending next reinstall

Je trouve cette distinction importante. « Conforme » et « enrôlé via ADE » ne décrivent pas la même chose.

Entre-temps, ce chemin n’est d’ailleurs plus seulement une idée dans un schéma. L’app détecte maintenant si elle arrive depuis ADE ou sur une machine existante, collecte l’état local et affiche une vraie étape de review avant le premier apply. Une installation Nix non reconnue bloque volontairement la convergence au lieu d’être supprimée automatiquement. Homebrew existant est détecté, les backups Home Manager sont signalés et le mode de provisioning est enregistré dans l’état de la workstation.

C’est exactement ce que je voulais éviter : avoir un « nouveau parc propre » et un « vieux parc qu’on ne touche surtout pas » pendant des mois.

Et le jour où la machine est réellement effacée, elle repasse naturellement par le chemin Apple Business sans avoir besoin d’un autre modèle de profil.

Sur un Mac déjà utilisé, Setup ne repart pas de zéro : il affiche l’état trouvé avant de faire converger la machine.

Apple Business reste très important dans le modèle#

Ce n’est pas une série « pourquoi j’ai remplacé mon MDM par Nix ».

Je n’ai justement aucune envie de réécrire un MDM.

Apple Business fait très bien la partie enrollment et contrôle du device. Je veux simplement éviter qu’il devienne aussi mon moteur de composition, mon inventaire applicatif, mon gestionnaire de shell, mon orchestrateur Nix et mon mécanisme de mise à jour.

Le poste de travail est une plateforme. J’ai donc préféré lui appliquer les mêmes principes que ceux que j’utilise ailleurs : séparation des responsabilités, état déclaratif, identité explicite, versionnement et rollback.

La question suivante était alors assez naturelle : si Apple Business ne choisit plus la workstation, qui la choisit ?

Dans mon cas, la réponse était déjà dans Entra.

Sources officielles#

• Apple Platform Deployment : Automated Device Enrollment
• Apple Business
• Determinate Systems : Deploy Determinate with MDM
• nix-darwin