🚀 dontallow macOS : bloquer le réseau local (⚡)
Découvrez dontallow macOS : bloquez l’accès réseau local, comprenez l’autorisation réseau local Mac, et sécurisez votre confidentialité. Précautions avant installation.
dontallow sur macOS : reprendre la main sur les demandes réseau local
Depuis macOS Sequoia, certaines apps peuvent afficher une fenêtre vous demandant si elles sont autorisées à rechercher des appareils sur votre réseau local. En théorie, vous répondez une fois et la décision reste mémorisée. En pratique, quelques logiciels finissent par redemander à chaque lancement - parfois sous un nom qui ressemble beaucoup à celui que vous utilisez déjà (comme Chrome), mais avec un chemin qui change.
C'est là que dontallow intervient : l'outil repère la fenêtre et clique sur Ne pas autoriser. Il tourne en arrière-plan, peut être mis en pause, et inclut une liste d'exceptions pour les cas où une application a vraiment besoin du réseau local. Il ne choisit jamais « Autoriser ».
Ce n'est pas un réglage officiel de macOS, et ce n'est pas non plus un remplacement du contrôle de confidentialité d'Apple. dontallow est un petit agent d'automatisation - et pour fonctionner, il faut lui donner l'accès à l'accessibilité. Voici pourquoi les alertes reviennent, comment dontallow agit, et quand son installation a (vraiment) du sens.
Pourquoi macOS redemande-t-il l'accès au réseau local ?
L'autorisation vise la capacité d'une application à découvrir ou à contacter des appareils sur le même réseau : téléviseur, imprimante, enceinte, ou autre ordinateur. Concrètement, cela peut servir à diffuser une vidéo (Chromecast, AirPlay), imprimer, ou jouer en réseau local. Donc, une demande n'est pas forcément « louche ». Le vrai sujet, c'est que la réponse doit coller à votre usage réel.
Le problème, d'après le projet dontallow, vient surtout de la façon dont macOS associe une décision à une application. Si, au prochain lancement, le système ne « retrouve » pas le logiciel comme prévu, il peut réafficher la fenêtre. Résultat : vous refaites le même choix, sans être sûr à quelle fonction précise il correspond.
Le cas des navigateurs fondés sur Chromium
Chrome, Brave, Edge, Arc et d'autres navigateurs basés sur Chromium peuvent lancer une copie de l'application depuis un emplacement temporaire selon leur mode de fonctionnement. Le chemin n'est alors plus le même à chaque démarrage.
Comme macOS s'appuie notamment sur l'identité et l'emplacement du logiciel pour retrouver la décision précédente, cette copie peut être traitée comme une application différente.
Le résultat est agaçant : dans les réglages « Réseau local », on peut voir plusieurs entrées au nom semblable, parfois liées à des chemins qui n'existent plus. Et une mise à jour placée dans un répertoire versionné peut aussi créer une nouvelle entrée. Dans tous ces cas, rien n'implique automatiquement une intention malveillante : ça peut juste refléter la façon dont l'app est distribuée ou mise à jour.
Une fenêtre parfois attribuée au mauvais logiciel
Autre scénario : selon le projet, macOS peut afficher la demande au nom d'une application qui n'est pas forcément celle que vous utilisez directement. Là , la tentation de cliquer « Autoriser » par réflexe est forte - et c'est une mauvaise habitude, parce que refuser n'importe quoi peut aussi casser une fonction dont vous avez besoin.
La règle pratique reste simple : demandez-vous d'abord ce que vous utilisez. Si la découverte d'appareils vient de votre navigateur ou d'un lecteur multimédia, l'accès peut avoir un intérêt. Si vous ne vous en servez jamais, le refuser est cohérent. dontallow vise surtout ceux qui ont compris cette nuance et qui veulent arrêter la répétition des demandes, pas ceux qui veulent supprimer en bloc tous les contrôles de macOS.
Comment dontallow ferme-t-il les demandes ?
dontallow est un utilitaire écrit en Swift, distribué en deux fichiers dans son dépôt, sans dépendance externe annoncée. Il s'installe comme agent de lancement pour votre utilisateur (via launchd, le mécanisme macOS pour exécuter des tâches en arrière-plan) et est prévu pour redémarrer après une ouverture de session ou un redémarrage.
Son fonctionnement dépend de l'accessibilité. L'outil observe l'apparition de fenêtres par le processus système UserNotificationCenter, puis lit le texte affiché. Il vérifie qu'il s'agit bien d'une demande liée au réseau local, tient compte d'une éventuelle période de pause et des exceptions, puis clique sur Ne pas autoriser. Si l'accès à l'interface échoue, il tente un clic simulé à l'endroit attendu du bouton.
Un refus automatisé, pas une règle réseau « générale »
Il faut distinguer : dontallow ne bloque pas toutes les communications réseau de votre Mac, et il ne remplace pas un pare-feu. Il répond à une fenêtre précise en choisissant le refus. D'après le projet, il ne modifie pas les fichiers système, ne désactive pas les protections de macOS et ne sélectionne jamais « Autoriser ».
L'agent reste aussi en attente : il n'est censé solliciter le processeur que lorsqu'une fenêtre apparaît. Chaque demande fermée peut déclencher une notification indiquant l'application concernée, ainsi que la commande pour suspendre l'outil. Si ces notifications deviennent pénibles, vous pouvez les couper dans les réglages système.
Ce que l'accès à l'accessibilité implique
Pour cliquer à votre place, l'outil doit avoir l'autorisation Accessibilité dans Réglages Système, sous Confidentialité et sécurité. C'est un droit sérieux : il permet à un logiciel d'interagir avec l'interface.
Donc, traitez dontallow comme un logiciel à vérifier : installez une version que vous connaissez et choisissez de faire confiance, regardez le chemin du binaire avant de donner l'accès, et comprenez ce que ce droit autorise réellement. Le fait que ce soit léger ou open source ne change pas le principe : si vous n'avez pas envie de donner ce pouvoir à un agent tiers, la solution la plus prudente reste de répondre manuellement aux alertes et, quand c'est possible, de corriger la cause des demandes répétées.
Comment installer et configurer dontallow ?
Le projet propose une installation via Homebrew ou une compilation manuelle. Pour Homebrew, la commande fournie est :
brew install johncassil/tap/dontallowL'autre option mentionnée est make && make install. Une fois l'exécutable disponible, lancez :
dontallow installCette commande écrit un agent launchd pour votre compte, le démarre et ouvre la section Accessibilité des réglages système. Si macOS ne vous montre pas la demande tout de suite, l'outil affiche alors le chemin exact à ajouter. Il attend l'autorisation puis confirme que l'agent est actif. La commande dontallow status sert à retrouver l'information si le droit manque ou a été retiré.
Suspendre l'agent ou préserver une application
Vous n'avez pas besoin de laisser dontallow « refuser tout » en permanence. Pour le mettre en pause, utilisez une durée explicite :
dontallow pause 10mLe projet accepte 30m, 2h, 1d ou forever. Pour reprendre automatiquement les refus, utilisez dontallow resume. Une notification après chaque action aide à garder la main : vous pouvez suspendre dontallow le temps d'ouvrir un logiciel dont la fonction réseau local vous intéresse, puis répondre vous-même à la fenêtre.
Pour une exception durable, ajoutez le nom de l'application dans le fichier ~/.config/dontallow/allowlist, une entrée par ligne. La correspondance est une sous-chaîne insensible à la casse : c'est pratique, mais ça peut être trop large. Prenez une minute pour vérifier les noms que vous mettez avant d'ajouter plusieurs entrées.
Le fichier ~/.config/dontallow/grace sert à définir un délai (en secondes) avant l'action. La valeur par défaut annoncée est de 0,25 seconde. Si vous voulez une micro-fenêtre pour cliquer vous-même sur « Autoriser », augmentez cette valeur. Elle reste courte, donc il vaut mieux tester selon vos habitudes.
Vérifier les règles et désinstaller
La commande dontallow rules lit le magasin de règles réseau local du système et affiche ce que représentent les lignes des réglages, y compris les entrées « orphelines ». C'est utile pour repérer les doublons, mais ne remplace pas la prudence : une entrée ancienne ne veut pas dire que l'app correspondante existe encore.
Pour observer le comportement sans cliquer sur un bouton, lancez dontallow run --dry-run. L'outil tourne au premier plan et vous dit ce qu'il ferait, sans agir. C'est le meilleur point de départ si vous voulez vérifier la détection avant d'activer l'agent. Enfin, dontallow uninstall arrête et supprime l'agent. Et si vous ne voulez plus lui conserver ce droit, pensez à retirer son entrée dans Accessibilité.
Quelles sont les limites et les précautions à connaître ?
La limite principale est assumée : dontallow répond « Ne pas autoriser » aux demandes qu'il reconnaît. Il ne peut pas décider si une application devrait avoir accès au réseau local, et il ne peut pas deviner si vous utilisez AirPlay, une imprimante ou une fonctionnalité de jeu en réseau au moment où la fenêtre apparaît. C'est à vous de gérer les exceptions et de suspendre l'agent quand nécessaire.
Si un refus a été enregistré, vous pouvez l'inverser dans Réglages Système (Confidentialité et sécurité) sous Réseau local. Si une application perd une fonction de découverte ou de connexion, vérifiez cette liste et réactivez l'accès.
Le projet précise aussi qu'il n'existe pas de méthode prise en charge pour « nettoyer » facilement toutes les anciennes entrées, et que tccutil reset ne couvre pas ce magasin de règles. Donc, ne comptez pas sur une commande unique de réinitialisation universelle.
Après une mise à jour
Toujours selon le projet, macOS peut associer l'autorisation Accessibilité à la signature du binaire. Une nouvelle compilation (y compris après une mise à jour Homebrew) peut donc faire perdre le droit accordé auparavant.
Après une mise à jour, lancez dontallow status. Si l'accès est signalé comme manquant, retirez l'entrée existante dans Accessibilité puis ajoutez à nouveau le chemin indiqué par l'outil.
C'est un coût opérationnel réel, même si ça ne touche pas toutes les mises à jour. Sur un Mac personnel, c'est souvent gérable ; sur un parc, il faut prévoir la distribution du binaire, l'identité de signature et la gestion des autorisations.
Le cas des Mac administrés
Le projet indique que l'accès au réseau local ne peut pas être préconfiguré via une charge utile MDM, tandis que l'autorisation Accessibilité peut être gérée avec un profil PPPC (Privacy Preferences Policy Control). Pour un déploiement en entreprise, l'approche consiste à compiler et signer le binaire avec un Developer ID, distribuer le binaire et le profil correspondant, puis exécuter dontallow install pour chaque utilisateur.
Ça ne veut pas dire que l'outil s'adapte à toutes les organisations. L'équipe IT doit valider le code, définir le cycle de mise à jour, cadrer la portée du profil et vérifier que ça colle aux besoins métier. Pour un usage individuel, la décision se résume plutôt à trois questions : les alertes sont-elles vraiment répétitives, avez-vous besoin d'une fonction réseau local, et êtes-vous prêt à donner à un agent un droit d'interagir avec l'interface ?
À retenir : dontallow vaut le coup si les alertes répétées vous énervent et si vous acceptez une réponse par défaut négative. Gardez au moins une exception pour les apps utiles, testez d'abord en mode
--dry-run, et revérifiez l'autorisation Accessibilité après une mise à jour.
Conclusion
dontallow traite un irritant précis : les demandes d'accès au réseau local qui reviennent, parce que macOS n'arrive pas toujours à retrouver l'application à laquelle la décision était associée. L'approche est directe : surveiller la fenêtre, regarder ce qui s'affiche, puis sélectionner « Ne pas autoriser ».
En échange, il faut lui donner l'accès à l'accessibilité et accepter de gérer les exceptions, les mises à jour et les cas où l'accès réseau local est vraiment utile. Commencez par une simulation (--dry-run), gardez les fonctions dont vous avez besoin, et vérifiez régulièrement ses autorisations. Si ce compromis ne vous convient pas, répondre manuellement aux fenêtres reste la solution la plus maîtrisée.