Faire confiance à une app sur un Mac n’est pas une décision unique, oui ou non. Ce sont quatre questions distinctes, chacune tranchée par un mécanisme différent : qui l’a construite, Apple l’a-t-elle vérifiée, à quoi a-t-elle le droit de toucher, et que fait-elle réellement une fois lancée. Apple documente les trois premières en détail. La quatrième est celle que vous devez observer vous-même, et c’est celle qui rattrape une app qui a passé les trois premières avant de mal tourner.
App Store ou téléchargement direct
La page d’assistance d’Apple Ouvrir des apps en toute sécurité sur votre Mac présente l’App Store comme l’endroit le plus sûr pour obtenir des logiciels, pour deux raisons concrètes : Apple examine chaque app avant de l’accepter, et Apple peut retirer rapidement une app si un problème apparaît ensuite. Les apps de l’App Store doivent aussi s’exécuter dans l’App Sandbox, que la page d’Apple sur Gatekeeper et la protection à l’exécution décrit comme limitant les données qu’une app peut atteindre et l’obligeant à passer par les API de macOS pour dialoguer avec d’autres apps.
Cela ne rend pas suspect tout téléchargement direct. Une grande partie des logiciels Mac légitimes est distribuée hors de la boutique parce que le bac à sable interdit ce dont ils ont besoin (utilitaires disque, outils de développement, pare-feu compris). La différence, c’est que pour un téléchargement direct, l’étape d’examen est remplacée par deux contrôles plus légers qu’Apple décrit sur les mêmes pages : une signature qui dit qui a construit l’app, et une analyse de notarisation.
Developer ID et notarisation : ce qu’ils prouvent
Un certificat Developer ID est délivré par Apple à un développeur inscrit à l’Apple Developer Program, et il permet à Gatekeeper de confirmer qu’une app a été signée par ce développeur et n’a pas été modifiée depuis. C’est tout ce qu’une signature prouve : l’identité et l’intégrité. Elle ne dit rien de l’intention. Une app signée peut toujours être une mauvaise app ; la signature signifie seulement qu’Apple sait quel nom figure dessus et peut la révoquer.
La notarisation est le deuxième contrôle. La documentation développeur d’Apple sur la notarisation des logiciels macOS avant distribution la décrit comme une analyse automatisée des logiciels signés Developer ID, à la recherche de contenu hostile connu et de problèmes de signature, à l’issue de laquelle Apple délivre un ticket que Gatekeeper sait lire. La page d’assistance d’Apple est prudente dans sa formulation : la notarisation signifie qu’Apple a vérifié l’app et n’y a rien détecté de malveillant. C’est une analyse par rapport à ce qu’Apple connaît déjà, pas un examen de ce que fait l’app, et Apple peut révoquer une notarisation plus tard si elle en apprend davantage.
L’attribut de quarantaine
Le mécanisme qui relie ces contrôles à un téléchargement précis est un attribut étendu du fichier, com.apple.quarantine, que Safari et la plupart des autres navigateurs et messageries apposent sur tout ce qu’ils enregistrent. Quand vous ouvrez pour la première fois un fichier portant cet attribut, Gatekeeper effectue ses vérifications et demande votre accord. La page d’Apple sur Gatekeeper décrit le comportement par défaut comme une vérification de tout logiciel, à la recherche de contenu malveillant connu, à sa première ouverture. Vous pouvez voir l’attribut vous-même avec la commande xattr -l dans le Terminal sur un fichier téléchargé.
Si une app n’est ni signée ni notarisée, macOS refuse de l’ouvrir et propose un moyen de passer outre. La page d’assistance d’Apple Ouvrir une app Mac provenant d’un développeur inconnu détaille les étapes puis ajoute un avertissement qui mérite d’être cité en substance : la majorité des infections de Mac se produisent lorsqu’on contourne les réglages de sécurité, et Apple recommande de chercher une autre app, même quand le développeur semble établi. La règle pratique en découle directement. Un contournement doit rester un acte rare et délibéré, réservé à un logiciel auquel vous avez une raison précise de faire confiance, jamais un réflexe.
Autorisations : ce à quoi une app a le droit de toucher
La troisième question est celle du périmètre. Depuis macOS 10.15, explique la page du guide de sécurité des plateformes Apple sur le contrôle de l’accès des apps aux fichiers, les apps doivent demander avant de lire votre Bureau, vos Documents, vos Téléchargements, iCloud Drive ou les volumes réseau, et l’accès à la caméra, au micro, à l’enregistrement de l’écran, à la surveillance des frappes et à l’accès complet au disque n’est accordé que par une demande explicite ou un changement manuel dans Réglages Système, Confidentialité et sécurité. Le système derrière ces demandes s’appelle TCC (Transparency, Consent and Control), et son principe, selon les mots d’Apple, est que les utilisateurs doivent avoir une transparence, un consentement et un contrôle complets sur ce que les apps font de leurs données.
Les autorisations sont un signal de confiance en elles-mêmes. Un gestionnaire de presse-papiers qui demande l’accès Accessibilité a une raison. Une app de fonds d’écran qui demande l’accès complet au disque et l’enregistrement de l’écran n’en a pas. Le décalage entre ce à quoi sert une app et ce qu’elle réclame est souvent visible avant même que l’app ait fait quoi que ce soit, et il ne coûte rien de refuser pour voir si l’app fonctionne quand même.
Le comportement réseau : la question à laquelle les autres contrôles ne répondent pas
La signature, la notarisation et les autorisations sont toutes évaluées avant, ou au moment, d’une demande. Aucune n’observe l’app dans la durée, et aucune ne regarde la seule activité qui transforme un problème de confidentialité en problème de sécurité : envoyer des données hors du Mac. Une app peut être signée par un vrai développeur, notarisée par Apple, dotée des seules autorisations dont elle a plausiblement besoin, et quand même envoyer vos contacts à un courtier en analyse d’audience, interroger un point de suivi toutes les quelques minutes ou, après une mise à jour de routine qui remplace son code, se mettre à parler à un serveur qu’elle n’avait jamais contacté.
Lire le comportement réseau comme un signal de confiance, c’est poser quelques questions concrètes sur chaque app. Se connecte-t-elle, et si oui, est-ce attendu pour ce qu’elle fait ? À quels hôtes parle-t-elle : ceux du développeur, un service reconnaissable, ou une liste de domaines publicitaires et d’analyse d’audience ? Utilise-t-elle des connexions chiffrées, ou quelque chose part-il en HTTP clair ? Son comportement change-t-il après une mise à jour ? Se connecte-t-elle à horaire fixe quand vous ne l’utilisez pas ? Rien de tout cela n’exige d’expertise ; cela exige de voir les connexions, ce que macOS ne vous montre pas par défaut.
C’est à cela que sert FireAI. Sa carte en direct montre chaque connexion de chaque app, avec la destination, le pays et le réseau derrière, et sa revue par IA privée, un modèle embarqué, juge chaque nouvelle connexion d’une app inconnue à partir de la réputation de la destination, du fait que le binaire ait déjà été vu ou non, du port et du protocole, et du chiffrement de la liaison, puis explique sa raison en langage clair. Sa protection des données en clair empêche numéros de carte, mots de passe et clés d’API de partir en HTTP non chiffré, quelle que soit l’app qui les envoie. Chaque décision de l’IA devient une règle visible que vous pouvez annuler, et les règles peuvent être formulées en français ou en anglais courant (« bloque Microsoft Teams ») ou exportées sous forme de fichier texte.
Bloquer ce qui n’est pas signé, et suivre la signature
Deux choix de conception de FireAI découlent directement du modèle d’Apple décrit plus haut. D’abord, ses modes de sécurité les plus stricts, Paranoïaque et Sous attaque, empêchent purement et simplement les apps non signées de se connecter, en même temps que la télémétrie et les traqueurs, ce qui transforme la question « êtes-vous sûr ? » d’Apple en un réglage par défaut au niveau du réseau : un binaire non signé peut s’exécuter si vous y avez tenu, mais il ne peut téléphoner à personne. Ensuite, les règles par app de FireAI suivent la signature de code de l’app plutôt que son nom ou son chemin. Un imposteur baptisé « Slack.app » dans le dossier Téléchargements n’hérite pas de la règle que vous avez écrite pour le vrai Slack, parce que la signature ne correspond pas ; et quand la vraie app se met à jour, la règle est conservée, parce qu’elle correspond. C’est la même identité qu’Apple utilise pour Gatekeeper, appliquée au réseau.
Ce que cela ne fait pas
FireAI n’analyse pas les fichiers d’une app, n’inspecte ni son code ni sa mémoire, et n’est pas un antivirus ; il ne peut pas vous dire qu’un téléchargement est hostile avant que vous ne l’exécutiez. Si vous avez autorisé une app, le trafic qui se cache à l’intérieur de cette app hérite de son autorisation. Le trafic chiffré vers une destination réputée est jugé sur la destination et le schéma, pas sur le contenu. Et aucun pare-feu ne remplace les trois premiers contrôles : la décision de confiance la moins chère et la plus fiable sur un Mac reste de préférer l’App Store ou un téléchargement signé Developer ID et notarisé, de refuser la fenêtre de contournement, et de décliner les autorisations qu’une app n’a aucune raison visible de demander.
Mises bout à bout, les quatre questions donnent une définition pratique d’une app Mac digne de confiance : signée par un développeur connu, notarisée par Apple, ne demandant que ce dont elle a plausiblement besoin, et ne parlant qu’à des serveurs cohérents avec ce qu’elle fait. Apple vous laisse vérifier les trois premières à l’installation. La quatrième ne se voit qu’en observant, et c’est pour cela qu’elle vaut la peine d’être ajoutée.
Le rôle de FireAI et de HisnLabs
Apple répond aux trois premières questions de confiance à l’installation ; FireAI existe pour la quatrième, en montrant ce que chaque app fait réellement sur le réseau et en liant chaque règle à la même signature de code sur laquelle Gatekeeper s’appuie déjà.
FireAI est le produit de HisnLabs : un pare-feu IA embarqué pour Mac. Il montre en langage clair chaque connexion faite par vos applications et vous laisse décider ce qui sort de votre Mac — son IA fonctionne en local, votre trafic ne nous est jamais envoyé, ni à personne d’autre. L’équipe de recherche en sécurité de HisnLabs est celle qui garde ces décisions fiables : elle recense les domaines de simple télémétrie face à ceux d’un vrai service, suit le pays et le réseau derrière une connexion, et entraîne le modèle embarqué (la fonction Autopilot) sur du trafic réel, sans que rien ne quitte votre Mac.
Vous pouvez lire les choix techniques qui s’y trouvent, ou essayer FireAI pendant 17 jours, sur FireAI, par HisnLabs.