Contrôle des applications macOS 27 : bloquer ou autoriser des apps sur les Mac managés

Avec macOS 27, vous décidez quelles applications ont le droit de s'exécuter sur vos Mac managés. Vous pouvez en bloquer quelques-unes, ou n'autoriser que celles que vous choisissez.

C'est une nouveauté d'Apple, annoncée à la WWDC26. Appaloosa la prend en charge dès le premier jour de macOS 27. Cet article explique comment elle fonctionne et comment la configurer.

Ce que macOS 27 apporte vraiment

La nouvelle déclaration d'Apple s'appelle com.apple.configuration.app.settings. Sur Mac, elle porte deux clés qui nous intéressent ici : AllowedBinaries et DeniedBinaries. L'une dit « seules celles-ci peuvent s'exécuter », l'autre « celles-ci ne s'exécuteront jamais ». Le contrôle passe par le framework Endpoint Security : le blocage intervient donc au moment de l'exécution, pas à l'installation.

Trois points rendent ce mécanisme meilleur que ce qu'on avait jusqu'ici.

• C'est déclaratif. Le Mac détient la règle et l'applique lui-même, au lieu d'attendre que le serveur pousse une commande en espérant qu'elle arrive. Si ce modèle est nouveau pour vous, notre fiche de glossaire sur le DDM en détaille le fonctionnement.
• La correspondance se fait sur la signature de l'application, pas sur un nom ou un bundle ID que n'importe qui peut modifier. Renommer Torrent.app en Notes.app ne sert à rien.
• Le blocage est réel. Les applications ne se lancent plus, et une application déjà en cours d'exécution à l'arrivée de la règle est arrêtée.

L'ancien payload, com.apple.applicationaccess.new, est déprécié dans macOS 27. Il fonctionne encore pour l'instant sur les systèmes plus anciens, mais Apple a clairement indiqué la direction. Pour la référence brute des clés, lisez les nouveautés de gestion des applications de la WWDC26 dans le guide Apple Platform Deployment.

Soyons précis sur le périmètre : il ne s'agit pas de déploiement d'applications. Ces listes n'installent rien et ne suppriment rien. Elles indiquent à macOS ce qu'il a le droit de lancer, point. Le déploiement reste là où il a toujours été, côté catalogue d'applications, dans le mobile application management.

Comment macOS identifie une application

Les deux listes décrivent une application avec les cinq mêmes champs. Les trois premiers répondent à la question « quelle application ». Les deux derniers ne font qu'affiner cette réponse, et c'est pour cela que chaque ligne doit porter au moins un des trois premiers. Un chemin seul n'identifie rien.

Ces valeurs se lisent sur une installation réelle avec codesign, fourni avec macOS :

$ codesign -dvvv /Applications/Firefox.app
...
Identifier=org.mozilla.firefox
...
TeamIdentifier=43AQ936H96
...
CDHash=bb880c62979ba21924f3599b660477436cabaa96

Identifier est votre Signing ID, TeamIdentifier votre Team ID, CDHash votre CDHash. Les lignes Authority indiquent d'où vient l'application, ce qu'exprime le champ État de signature. Une application signée Developer ID Application correspond à DeveloperID, une application de l'App Store correspond à AppStore.

Deux cas piègent régulièrement. Les applications d'Apple affichent TeamIdentifier=not set : codesign ne vous donne donc rien d'exploitable. À la place, les listes acceptent la valeur littérale *APPLE*, que vous associez au Signing ID : *APPLE* plus com.apple.iCal. Elle survit aux mises à jour système, contrairement à un CDHash.

L'autre cas, ce sont les web clips. Ils partagent tous le même Signing ID, com.apple.Safari.WebApp. Bloquez-le, et plus aucun web clip ne s'ouvre sur le Mac. Utilisez une liste d'autorisation sans lui, et les webapps que vous déployez depuis Appaloosa ne s'ouvriront pas non plus.

Bloquer une liste d'applications

C'est le cas dont la plupart des équipes ont réellement besoin. Dans la carte Applications bloquées, ajoutez une ligne par application à empêcher, renseignez au moins un Signing ID, un Team ID ou un CDHash, puis enregistrez.

Une application bloquée ne se lance plus. Tout ce que vous n'avez pas listé continue de fonctionner exactement comme avant. Cette asymétrie est tout l'intérêt : vous retirez trois choses, vous n'en accordez pas six cents.

Le Team ID est en général la bonne granularité. Bloquer un Signing ID neutralise une application ; bloquer le Team ID neutralise tout ce que publie cet éditeur, y compris l'utilitaire qu'il renommera au printemps prochain. Ne descendez à l'application que si vous tenez vraiment à garder le reste du catalogue de l'éditeur disponible.

N'autoriser qu'une liste

La carte Applications autorisées fonctionne dans l'autre sens, et elle est bien plus stricte. Dès qu'elle contient une seule ligne, toute application absente de la liste cesse de fonctionner. Safari. Mail. Réglages Système. Les applications d'Apple n'ont droit à aucun passe-droit.

Ici, une ligne doit porter au moins un Team ID ou un CDHash. Un Signing ID seul n'est pas accepté par macOS sur cette liste, ce qui surprend, puisque la carte de blocage, elle, l'accepte.

Une carte vide signifie aucune restriction, et non « rien n'est autorisé ». Laissez-la vide, sauf si vous voulez vraiment limiter le Mac à un ensemble d'applications connu.

Et si une application se retrouve dans les deux cartes, le blocage l'emporte. Elle ne s'exécutera pas, liste d'autorisation ou non.

Garder vos applications déployées en fonctionnement

Sous la liste des applications autorisées se trouve une option, Toujours autoriser les applications déployées depuis Appaloosa en plus de la liste ci-dessus, activée par défaut. Elle correspond à la clé AlwaysAllowManagedApps d'Apple et vous évite de lister à la main chaque application managée. Ne la désactivez que si le Mac doit exécuter strictement ce que vous avez saisi, et rien de plus.

Sur votre configuration Par défaut, chaque ligne porte un cadenas. Verrouiller une ligne la copie vers vos autres configurations macOS et les empêche de la modifier. Les configurations qui en héritent affichent la ligne, mais ne peuvent ni la modifier ni la supprimer. C'est ainsi que vous obtenez un socle commun sur toute une flotte sans le ressaisir site par site.

Ce que voit l'utilisateur

Rien, jusqu'à ce qu'il tente de lancer quelque chose qu'il ne devrait pas. macOS affiche alors une alerte. Pas d'échec silencieux, pas d'icône qui rebondit indéfiniment dans le Dock sans explication.

Prévenez votre support avant d'activer tout cela. L'alerte dit que l'application est bloquée, elle ne dit ni par qui ni pourquoi, et un utilisateur qui se servait tranquillement de cette application hier ouvrira un ticket. Une courte note interne vaut mieux que trois jours de confusion.

Cinq pièges à connaître

Les applications système ont des effets de bord. La plupart des binaires système restent autorisés quoi qu'il arrive, mais ceux que vous pouvez bloquer peuvent entraîner d'autres fonctionnalités dans leur chute. Bloquez l'App Store, et vos utilisateurs ne peuvent plus accepter les conditions nécessaires aux achats en volume, ce qui casse discrètement votre distribution VPP.

Les applications Apple Business Manager ont quand même besoin d'un droit de lancement. Attribuer une licence via Apple Business Manager et installer l'application ne dit rien de son droit à s'exécuter. Avec une liste d'autorisation stricte, licencier et autoriser sont deux décisions distinctes.

Le CDHash change à chaque build. C'est le champ le plus précis, et le plus fragile. La prochaine mise à jour de Chrome arrive avec un nouveau CDHash, et votre règle cesse de correspondre sans prévenir. Réservez-le à un outil interne figé, quand c'est justement le comportement recherché. Partout ailleurs, utilisez le Team ID.

Vide ne veut pas dire verrouillé. On le répète, parce que c'est ce piège-là qui vaut l'appel de 2 h du matin : une carte d'autorisation vide ne restreint rien.

Ne testez pas d'abord sur votre propre Mac. Placez une machine de réserve dans une configuration de test. Une liste d'autorisation stricte où l'on a oublié Réglages Système, c'est un après-midi pénible.

Disponible dans Appaloosa dès le premier jour

Les deux cartes se trouvent dans l'onglet Applications d'une configuration macOS, à côté du reste de vos réglages de gestion des Mac. Elles nécessitent macOS 27 ou plus récent. Les appareils encore sous macOS 26 les ignorent : vous pouvez donc configurer dès maintenant et laisser la règle s'appliquer au fil des mises à jour.

Ajouter, modifier ou supprimer une ligne envoie les listes à jour à tous les appareils de la configuration. Le détail de la mise en place et la description champ par champ figurent dans l'article de support sur le contrôle des applications sur les appareils macOS.

Une chose n'a pas changé avec macOS 27 : pour les clés équivalentes, l'iPhone et l'iPad utilisent des bundle ID et non des signatures, donc les règles écrites pour vos Mac ne se transposent pas. Si vous gérez les deux, traitez-les comme des politiques distinctes. Notre page sur la gestion d'iOS et iPadOS couvre ce volet.

À lire aussi : Appaloosa gère désormais Windows et macOS

FAQ

Bloquer une application la supprime-t-elle du Mac ?

Non. L'application reste sur le disque, elle ne se lance simplement plus. Ces listes contrôlent l'exécution, pas l'installation. Supprimer un logiciel est une action de déploiement, gérée séparément.

Mon ancien profil de restriction d'applications fonctionne encore. Dois-je migrer ?

Pas aujourd'hui, mais prévoyez-le. Le profil com.apple.applicationaccess.new est déprécié dans macOS 27. Déprécié, cela veut dire qu'Apple a cessé d'y investir et finira par ne plus le respecter. Déplacez donc les règles qui comptent vers les nouvelles listes tant que vous avez le luxe de pouvoir tester.

Dois-je autoriser explicitement les applications d'Apple ?

Oui, si vous utilisez la liste d'autorisation. Safari, Mail et Réglages Système sont bloqués comme n'importe quelle autre application s'ils en sont absents. Ajoutez-les avec le Team ID *APPLE* et le Signing ID de l'application, qui continue de correspondre après les mises à jour système. Pour comprendre comment s'articule la pile de gestion d'Apple, consultez notre fiche de glossaire MDM macOS.