L'application est endommagée et ne peut pas être ouverte sur macOS Tahoe ? Le guide complet Gatekeeper & Quarantaine

Vous double-cliquez sur une application que vous venez de télécharger et, au lieu de se lancer, macOS vous claque la porte au nez : « "App" est endommagée et ne peut pas être ouverte. Vous devriez la mettre à la Corbeille. » C'est l'une des boîtes de dialogue les plus frustrantes de tout macOS, précisément parce qu'elle est presque toujours mensongère. L'application est rarement endommagée. Ce que vous voyez en réalité, c'est Gatekeeper — le système de vérification des applications d'Apple — qui refuse d'exécuter quelque chose qu'il n'a pas pu vérifier, et Tahoe 26.5 (publié le 11 mai 2026) a rendu ce contrôle plus strict que jamais. Si vous avez rencontré l'erreur « l'application est endommagée et ne peut pas être ouverte » sur macOS Tahoe, ce guide vous explique exactement pourquoi cela se produit et comment y remédier en toute sécurité, sans compromettre la protection de votre Mac.

Il ne s'agit pas d'un article à solution unique « exécutez juste cette commande ». Supprimer un attribut de quarantaine est une correction de trente secondes, mais le faire à l'aveugle, c'est ainsi que des logiciels malveillants s'installent sur des machines qui étaient parfaitement sûres un instant plus tôt. Nous allons donc procéder correctement : comprendre le mécanisme, décoder les trois différentes boîtes de dialogue que vous pourriez voir, déterminer pourquoi une application légitime est signalée, puis appliquer la correction la moins agressive qui fonctionne réellement. À la fin, vous saurez non seulement quoi taper, mais aussi si vous devriez le faire.

Points clés à retenir

• « L'app est endommagée » est généralement un problème de quarantaine et de signature, non une vraie corruption. Tahoe applique l'attribut étendu com.apple.quarantine aux fichiers téléchargés et refuse de lancer les applications dont la signature de code ou le ticket de notarisation ne peut pas être validé.
• Trois boîtes de dialogue différentes signifient trois choses différentes. « Est endommagée » (signature cassée/manquante ou App Translocation), « le développeur ne peut pas être vérifié » (non signée/non notarisée) et « ne peut pas vérifier qu'elle est exempte de logiciels malveillants » (la vérification de notarisation n'a pas pu aboutir) ont chacune des causes et des corrections distinctes.
• Essayez d'abord la voie sûre : Réglages Système > Confidentialité et sécurité > « Ouvrir quand même ». L'ancienne méthode de contournement par clic droit → Ouvrir a été supprimée dans la génération macOS 15/26 ; Apple vous dirige désormais vers cette unique confirmation délibérée.
• Les corrections Terminal comme xattr -dr com.apple.quarantine fonctionnent, mais elles réduisent la sécurité. Ne supprimez la quarantaine que des applications en lesquelles vous avez vraiment confiance et que vous avez obtenues d'une source fiable. N'exécutez jamais de commandes générales sur /Applications.
• Ne désactivez pas Gatekeeper globalement en premier recours. spctl --master-disable ne se comporte plus comme le prétendent les anciens tutoriels, l'option « Partout » est masquée par défaut, et désactiver Gatekeeper à l'échelle du Mac est un risque bien plus important qu'approuver une seule application.

Ce que sont réellement Gatekeeper, la quarantaine et la notarisation

Avant de pouvoir corriger l'erreur intelligemment, vous devez comprendre les trois systèmes qui se superposent pour la produire. Ces termes sont souvent utilisés de manière interchangeable, mais il s'agit de mécanismes distincts qui se déclenchent tous au moment du lancement d'une application.

Gatekeeper : le videur à la porte

Gatekeeper est le sous-système de macOS qui décide si une application est autorisée à s'exécuter la première fois que vous l'ouvrez. Ce n'est pas un antivirus et il ne surveille pas votre application en continu. Imaginez-le comme un videur qui vérifie votre identité à l'entrée une seule et unique fois. Lorsque vous lancez une application nouvellement téléchargée, Gatekeeper pose deux questions : Cette application est-elle signée par un développeur reconnu par Apple ? et Cette application a-t-elle été notarisée par Apple ? Si les deux réponses sont oui, l'application s'ouvre sans problème. Si l'une ou l'autre des réponses est non, Gatekeeper bloque le lancement et affiche l'une des boîtes de dialogue que nous décoderons plus bas.

La politique de Gatekeeper est appliquée par un daemon et exposée via l'outil en ligne de commande spctl (security policy control), ce qui explique pourquoi chaque guide de dépannage finit par faire appel à spctl. L'essentiel à retenir est que Gatekeeper ne s'intéresse qu'au premier lancement. Une fois que vous avez ouvert une application avec succès, macOS mémorise votre approbation et cesse de vous importuner. C'est pourquoi la correction consiste toujours à franchir cette porte initiale, et non à modifier définitivement le comportement de l'application.

L'attribut étendu com.apple.quarantine

Lorsque vous téléchargez un fichier via une application « consciente de la quarantaine » — Safari, Chrome, Mail, Messages, AirDrop, la plupart des navigateurs et des clients de messagerie — cette application étiquette le fichier avec un attribut étendu nommé com.apple.quarantine. Les attributs étendus (xattrs) sont des bribes de métadonnées attachées à un fichier dans le système de fichiers, sans faire partie du contenu réel du fichier. L'attribut de quarantaine est une courte chaîne qui enregistre que le fichier provient de l'extérieur de votre Mac, avec un indicateur, un horodatage, l'agent qui l'a téléchargé et un identifiant d'événement unique.

Cet identifiant d'événement renvoie à la base de données LSQuarantine, un petit fichier SQLite dans votre dossier personnel (historiquement situé à ~/Library/Preferences/com.apple.LaunchServices.QuarantineEventsV2) qui consigne la provenance de chaque élément mis en quarantaine. Ce sont les données qui se trouvent derrière la ligne « vous avez téléchargé ceci le [date] depuis [site web] » dans les invites de Gatekeeper. La présence de l'attribut de quarantaine est le déclencheur qui indique à Gatekeeper : « ce fichier vient du monde extérieur, examinez-le avant de l'exécuter. » Supprimez cet attribut et Gatekeeper traite l'application comme si elle avait toujours résidé sur votre Mac — ce qui explique précisément pourquoi cette suppression est à la fois la correction la plus rapide et celle qui demande le plus de discernement.

Notarisation : le pré-filtrage des logiciels malveillants par Apple

La notarisation est la pièce la plus récente du puzzle et celle qui est le plus responsable de la vague moderne de plaintes liées à l'erreur « est endommagée ». Depuis macOS Catalina, Apple exige que les logiciels distribués en dehors de l'App Store soient notarisés : le développeur télécharge son application signée vers Apple, le service automatisé d'Apple la recherche pour des logiciels malveillants connus et vérifie qu'elle est correctement signée, et si elle réussit, Apple délivre un ticket de notarisation. Ce ticket peut être « agrafé » à l'application pour que la preuve voyage avec le fichier, ou il peut être récupéré en ligne par Gatekeeper au moment du lancement.

Lorsque vous ouvrez une application notarisée, Gatekeeper valide le ticket — soit celui qui est agrafé, soit celui qu'il récupère depuis les serveurs d'Apple — pour confirmer qu'Apple a vu et approuvé exactement cette version. Si le ticket est manquant, s'il ne peut pas être récupéré (vous êtes hors ligne), ou si l'application a été modifiée après la notarisation (ce qui invalide la signature que le ticket atteste), la vérification échoue et vous êtes bloqué. La notarisation n'est pas une révision App Store ; Apple ne sélectionne pas la qualité ni ne juge l'objectif de l'application. C'est un pré-filtrage des logiciels malveillants plus une garantie d'intégrité de la signature. Comprendre cette distinction est important, car un message « ne peut pas vérifier qu'elle est exempte de logiciels malveillants » signifie souvent « je n'ai pas pu joindre Apple pour vérifier le ticket », et non « il s'agit d'un logiciel malveillant ».

Les trois boîtes de dialogue, décodées

Voici la chose la plus utile de cet article : les mots exacts de la boîte de dialogue vous indiquent ce qui ne va pas. Lisez attentivement la boîte de dialogue avant de faire quoi que ce soit, car la correction diffère selon le cas.

Boîte de dialogue 1 : « "App" est endommagée et ne peut pas être ouverte. Vous devriez la mettre à la Corbeille. »

C'est celle qui sonne le plus alarmant et qui est la plus trompeuse. Dans l'écrasante majorité des cas, l'application n'est pas endommagée. Cette boîte de dialogue apparaît généralement lorsque :

• L'application possède l'attribut com.apple.quarantine et sa signature de code ne parvient pas à être validée. Une signature peut échouer parce que l'application n'est pas signée, qu'elle est signée avec un certificat révoqué, ou — le plus fréquemment pour des applications légitimes — parce que l'application a été modifiée après la signature. Le coupable classique est un outil de décompression ou un utilitaire d'archives tiers qui ne préserve pas correctement les attributs étendus et les liens symboliques, corrompant subtilement le bundle d'application de sorte que la signature ne correspond plus.
• L'App Translocation (également appelée Gatekeeper Path Randomization) s'est déclenchée et quelque chose d'autre a mal tourné par-dessus.
• L'application présente une incompatibilité d'architecture — par exemple un binaire Intel uniquement sur un Mac Apple Silicon où Rosetta 2 n'est pas (ou n'est plus) disponible, ou un binaire universel corrompu.

Le terme « endommagée » est le terme générique d'Apple pour « cette application a échoué à une vérification de sécurité ou d'intégrité et je ne vais pas vous offrir un bouton d'approbation doux ». C'est pourquoi celle-ci n'affiche souvent pas le remplacement convivial de Confidentialité et sécurité et vous oriente plutôt vers Terminal.

Boîte de dialogue 2 : « "App" ne peut pas être ouverte car le développeur ne peut pas être vérifié. »

C'est la variante plus douce et plus honnête. Elle signifie que l'application est non signée ou non notarisée — Apple n'a aucune trace de qui l'a faite ni si elle a été soumise au filtrage des logiciels malveillants. Fait important, cette boîte de dialogue est généralement accompagnée d'un bouton « Mettre à la Corbeille » et d'un bouton « Annuler », et la vraie échappatoire se trouve dans les Réglages Système plutôt que dans la boîte de dialogue elle-même. C'est la boîte de dialogue que vous obtenez le plus souvent pour les outils open source, les utilitaires de niche ou les logiciels de petits développeurs qui n'ont pas payé pour un compte Apple Developer. C'est le cas le plus facile à gérer en toute sécurité via le flux officiel « Ouvrir quand même », que nous abordons ensuite.

Boîte de dialogue 3 : « Apple n'a pas pu vérifier que "App" est exempte de logiciels malveillants. »

Cette formulation est apparue dans la génération macOS 15/26 et est la plus souvent mal comprise. Elle ne signifie pas qu'Apple a trouvé des logiciels malveillants. Elle signifie que Gatekeeper a tenté de vérifier le statut de notarisation de l'application et n'a pas pu terminer la vérification. Les raisons habituelles sont :

• Votre Mac est hors ligne ou derrière un pare-feu/proxy restrictif, de sorte que Gatekeeper ne peut pas joindre les serveurs de notarisation d'Apple pour valider le ticket.
• L'application est notarisée mais le ticket n'est pas agrafé, et la recherche en ligne a expiré.
• L'horloge de votre système est incorrecte (nous y reviendrons), ce qui casse les vérifications de validité temporelle des certificats et des tickets.

Cette boîte de dialogue vous oriente également généralement vers « Ouvrir quand même » dans Confidentialité et sécurité. Si vous la voyez alors que vous êtes en ligne, la démarche intelligente consiste à rechercher pourquoi la vérification échoue avant de la contourner — une application notarisée devrait réussir proprement.

Pourquoi une application légitime affiche « Est endommagée »

Examinons les raisons spécifiques pour lesquelles une application parfaitement bonne déclenche l'alarme, car connaître la cause vous indique quelle correction utiliser.

L'attribut de quarantaine lui-même

C'est la raison numéro un. Vous téléchargez une application tout à fait légitime, le navigateur l'étiquette avec com.apple.quarantine, et si la signature de l'application est même légèrement incorrecte, Gatekeeper passe de « le développeur ne peut pas être vérifié » à « est endommagée ». Vous pouvez voir l'attribut directement :

xattr -l /Applications/ExampleApp.app

Exemple de sortie pour une application mise en quarantaine :

com.apple.quarantine: 0083;6612a3b0;Safari;5F1B2C3D-7A8E-4F90-B1C2-D3E4F5061728
com.apple.macl: [binary data, 72 bytes]

Le premier champ (0083) est la valeur de l'attribut de quarantaine, suivi d'un horodatage hexadécimal, de l'agent qui l'a appliqué (Safari) et de l'UUID de l'événement qui pointe vers la base de données LSQuarantine. Si vous exécutez xattr -l et ne voyez aucune ligne com.apple.quarantine, la quarantaine n'est pas votre problème et vous devriez plutôt examiner les problèmes de signature ou d'architecture.

App Translocation (Gatekeeper Path Randomization)

C'est la subtile. Pour prévenir une classe d'attaques où une application malveillante charge un fichier empoisonné situé à côté d'elle, macOS transloques une application mise en quarantaine : lorsque vous l'exécutez depuis un emplacement de téléchargement (comme votre dossier Téléchargements ou une image disque montée) sans d'abord la faire glisser dans /Applications, macOS la lance depuis un point de montage temporaire en lecture seule et aléatoire au lieu de son emplacement réel. L'application voit un chemin différent de l'endroit où elle réside réellement.

Pour la plupart des applications, c'est invisible. Mais les applications qui s'attendent à trouver des ressources relativement à leur propre emplacement, ou qui tentent de se mettre à jour automatiquement, se brisent de manière déroutante — se manifestant parfois par une erreur « endommagée » ou un plantage au lancement. Le remède à l'App Translocation est d'une simplicité presque embarrassante : faites glisser l'application hors de Téléchargements/du DMG et dans le dossier /Applications, puis lancez-la depuis là. Déplacer le bundle d'application efface la translocation pour cette copie. Cette seule étape résout une part surprenante des rapports d'« endommagement » signalés par des utilisateurs qui exécutent des applications directement depuis une image disque.

Signatures cassées par les outils de décompression et de transfert

Une signature de code est un hachage cryptographique du contenu du bundle d'application, incluant sa structure de répertoires, ses liens symboliques et ses attributs étendus. Si quoi que ce soit dans le bundle change après la signature, la signature ne correspond plus et la validation échoue. Plusieurs opérations courantes peuvent corrompre silencieusement un bundle :

• Les utilitaires d'archives tiers qui ne préservent pas les liens symboliques ou qui aplatissent la structure du bundle lors de la décompression.
• Les transferts de fichiers via des outils ou des systèmes de fichiers (certains partages réseau, certains clients de synchronisation cloud, les disques USB FAT/exFAT) qui suppriment les attributs étendus ou altèrent les liens symboliques.
• Modifier manuellement quoi que ce soit à l'intérieur du bundle .app, même renommer un fichier.

Lorsque cela se produit, vous obtenez « est endommagée » même si le téléchargement original était correct. La correction ici ne consiste pas seulement à supprimer la quarantaine — c'est de re-télécharger l'application depuis la source officielle en utilisant Safari (qui gère correctement les bundles) ou, pour les propres builds d'un développeur, de re-signer localement (abordé plus loin, avec des mises en garde).

Binaires Apple Silicon vs Intel

Si vous utilisez un Mac Apple Silicon (M1 jusqu'aux dernières séries M) et essayez d'exécuter une application Intel uniquement, macOS a besoin de Rosetta 2 pour la traduire. Sur un système fraîchement installé, Rosetta peut ne pas être installé, et Apple a signalé que Rosetta 2 est en cours d'élimination progressive — à l'horizon macOS 27, sa disponibilité change significativement. Un binaire Intel qui ne peut pas être traduit, ou un binaire universel endommagé dont il manque la tranche arm64, peut se manifester comme un échec de lancement qui ressemble à une corruption. Vous pouvez inspecter les architectures contenues dans un binaire :

lipo -archs /Applications/ExampleApp.app/Contents/MacOS/ExampleApp

Sortie pour une application universelle :

x86_64 arm64

Si vous ne voyez que x86_64 sur un Mac Apple Silicon, vous avez besoin de Rosetta 2 (ou d'une version native). Si vous ne voyez que arm64 sur un Mac Intel, cette version ne s'y exécutera tout simplement pas. Pour le tableau d'ensemble sur le coucher du soleil de Rosetta, consultez notre guide de fin de vie de Rosetta 2.

Une horloge incorrecte casse la notarisation

Celui-ci prend les gens par surprise. La validation des certificats et les vérifications des tickets de notarisation sont sensibles au temps — elles confirment que le certificat de signature était valide à un moment donné et que le ticket n'a pas expiré. Si la date et l'heure de votre Mac sont très incorrectes (une batterie d'horloge morte sur un ancien matériel, une date manuellement réglée de manière erronée, ou une configuration de fuseau horaire ratée), ces vérifications peuvent échouer et produire « ne peut pas vérifier qu'elle est exempte de logiciels malveillants » ou même « est endommagée ». Vérifiez toujours l'horloge :

date

Si la date est incorrecte, corrigez-la dans Réglages Système > Général > Date et heure et activez « Régler la date et l'heure automatiquement », puis réessayez l'application. Cela peut sembler trivial, mais c'est une cause réelle et reproductible.

Le flux de correction sûr : Confidentialité et sécurité en premier

Voici la règle d'or : essayez la méthode officielle la moins agressive avant de toucher Terminal. Dans Tahoe, cela signifie le flux « Ouvrir quand même » dans les Réglages Système. Il approuve exactement une application, laisse Gatekeeper entièrement activé pour tout le reste, et crée un moment délibéré pour vous permettre de confirmer que vous faites confiance au logiciel.

Étape 1 : Déplacez l'application dans /Applications

Si l'application se trouve dans Téléchargements ou s'exécute depuis un DMG monté, faites glisser le .app dans votre dossier /Applications en premier. Cela seul efface l'App Translocation et résout de nombreux cas « endommagée » avant que vous ne fassiez quoi que ce soit d'autre. Éjectez l'image disque ensuite.

Étape 2 : Essayez de l'ouvrir, puis ouvrez Confidentialité et sécurité

Double-cliquez sur l'application. Lorsque la boîte de dialogue de blocage apparaît, cliquez sur Annuler (ne cliquez pas sur « Mettre à la Corbeille »). Puis allez dans :

Réglages Système > Confidentialité et sécurité, et faites défiler vers le bas jusqu'à la section Sécurité. Si macOS a récemment bloqué l'application, vous verrez une ligne comme « "ExampleApp" a été bloquée pour protéger votre Mac » avec un bouton « Ouvrir quand même » à côté.

Étape 3 : Cliquez sur « Ouvrir quand même » et authentifiez-vous

Cliquez sur Ouvrir quand même. macOS vous demandera de vous authentifier avec Touch ID ou votre mot de passe, puis affichera une dernière confirmation. Confirmez-la et l'application se lance. Dès lors, cette application figure sur votre liste approuvée et s'ouvre normalement.

C'est le flux qui a remplacé l'ancien truc du clic droit → Ouvrir. Dans macOS 14 Sonoma et les versions antérieures, vous pouviez faire un clic secondaire sur une application, choisir Ouvrir et obtenir une boîte de dialogue de contournement ponctuel. Apple a supprimé ce raccourci à partir de la génération macOS 15/26 précisément pour empêcher les utilisateurs de contourner Gatekeeper par réflexe sans réfléchir. La route Confidentialité et sécurité est intentionnellement plus lente — cette friction est une fonctionnalité. Pour les modifications plus larges apportées aux paramètres de sécurité dans cette version, notre guide complet de sécurité et confidentialité macOS Tahoe parcourt le panneau redessiné en détail.

Important : Si l'application affiche la sévère boîte de dialogue « est endommagée » et que vous ne voyez pas de bouton « Ouvrir quand même » dans Confidentialité et sécurité, cela signifie généralement que la signature est véritablement cassée (pas simplement non notarisée). Dans ce cas, re-téléchargez depuis la source officielle en premier ; si elle échoue toujours, la section Terminal ci-dessous est votre prochaine étape.

Les corrections Terminal (et leurs véritables coûts)

Lorsque la route GUI ne produit pas de bouton « Ouvrir quand même », Terminal est l'outil suivant. Tout ce qui suit est sûr uniquement lorsqu'il est appliqué à une application spécifique en laquelle vous avez confiance et provenant d'une source en laquelle vous avez confiance. Ces commandes réduisent la sécurité pour les cibles sur lesquelles vous les pointez — c'est tout l'enjeu, et tout le risque.

Inspectez avant d'agir

Regardez toujours avant de sauter. Listez les attributs étendus :

xattr -l /Applications/ExampleApp.app

Si com.apple.quarantine est présent, la quarantaine contribue au blocage. Si elle est absente, la supprimer n'aidera pas et votre problème réside dans la signature ou l'architecture.

Supprimez l'attribut de quarantaine

Pour retirer la quarantaine d'une seule application, de manière récursive (-r) en supprimant (-d) l'attribut dans l'ensemble du bundle :

xattr -dr com.apple.quarantine /Applications/ExampleApp.app

Il n'y a aucune sortie en cas de succès. Relancez maintenant l'application ; dans de nombreux cas, elle s'ouvre immédiatement car Gatekeeper ne la traite plus comme étrangère. Vous pouvez confirmer que l'attribut a disparu :

xattr -l /Applications/ExampleApp.app

La ligne com.apple.quarantine devrait avoir disparu.

Ce que cela fait réellement et pourquoi c'est risqué : supprimer l'attribut xattr de quarantaine indique à Gatekeeper de cesser de scruter cette application comme un téléchargement venant du monde extérieur. Pour une application légitime que vous avez téléchargée vous-même, c'est bien — vous confirmez simplement la décision de confiance que vous aviez déjà prise. Mais si vous l'exécutez aveuglément sur quelque chose que vous avez obtenu depuis un site douteux, un lien de forum ou une application « crackée », vous venez de désarmer la seule vérification qui aurait pu détecter un logiciel malveillant. N'exécutez jamais xattr -dr com.apple.quarantine sur /Applications dans son ensemble ni sur une application dont vous ne pouvez pas répondre. La manière la plus courante dont les utilisateurs Mac bien intentionnés se font infecter est de copier-coller une commande de suppression de quarantaine depuis une page de téléchargement qui veut que vous désarmiez Gatekeeper.

Re-signer un bundle cassé (avancé, avec de grandes mises en garde)

Si le problème est une signature corrompue plutôt que la quarantaine, supprimer l'attribut seul n'aidera pas — Gatekeeper voit toujours une signature invalide. Certains guides suggèrent de forcer la re-signature de l'application avec une signature ad hoc :

codesign --force --deep --sign - /Applications/ExampleApp.app

L'option --sign - signifie une signature ad hoc (sans véritable identité), --force écrase la signature existante, et --deep recurse dans le code imbriqué.

Soyez très prudent ici. C'est véritablement avancé et fréquemment la mauvaise réponse :

• --deep est déprécié par Apple pour la signature et peut produire des résultats subtilement cassés sur des applications complexes ; il a été conçu pour la commodité de vérification, pas comme une stratégie de signature appropriée.
• La re-signature ad hoc abandonne complètement la vraie signature et la notarisation du développeur. Vous cautionnez l'application avec la confiance de votre propre machine, pas celle d'Apple.
• Si le bundle est corrompu (le véritable scénario « endommagée »), re-signer la corruption ne le répare pas. La bonne correction est de re-télécharger une copie propre depuis la source officielle.

En pratique, la re-signature est un outil pour les développeurs qui déboguent leurs propres builds, pas un remède pour les utilisateurs finaux. Si vous vous retrouvez à utiliser codesign --force --deep --sign - sur une application que vous n'avez pas créée, arrêtez-vous et re-téléchargez plutôt.

Vérifiez le verdict de Gatekeeper avec spctl

Pour comprendre pourquoi Gatekeeper est mécontent, demandez-le-lui directement. Évaluez une application spécifique en mode verbeux :

spctl -a -vvv /Applications/ExampleApp.app

Une application notarisée saine retourne quelque chose comme :

/Applications/ExampleApp.app: accepted
source=Notarized Developer ID
origin=Developer ID Application: Example Developer (AB12CD34EF)

Une application bloquée pourrait retourner :

/Applications/ExampleApp.app: rejected
source=no usable signature

Cette ligne source= est précieuse — source=Notarized Developer ID signifie que tout va bien, source=no usable signature signifie que la signature est cassée ou manquante, et un rejet avec une raison « non notarisée » indique la notarisation plutôt que la quarantaine. Vérifiez l'état global de Gatekeeper avec :

spctl --status

Ce qui affiche normalement :

assessments enabled

Gérer les applications hors App Store

La grande majorité des rapports d'« endommagement » proviennent d'applications installées en dehors du Mac App Store, il vaut donc la peine d'y consacrer un mot dédié. Les applications de l'App Store passent par une révision et sont signées et notarisées de bout en bout, elles ne déclenchent donc pratiquement jamais ces boîtes de dialogue. Les applications du web ouvert sont là où Gatekeeper gagne sa place.

Vos sources les plus sûres, par ordre de confiance, sont : le Mac App Store, le site officiel du développeur avec un téléchargement notarisé, et les gestionnaires de paquets réputés comme Homebrew Cask (qui tirent généralement des sources officielles). Soyez bien plus prudent avec les miroirs de téléchargement aléatoires, les versions « gratuites » d'applications payantes et les liens partagés dans des forums ou des chats. Le fait qu'une application puisse être rendue fonctionnelle en supprimant la quarantaine ne dit rien sur le fait qu'elle soit sûre à exécuter.

Un rappel sobre que la notarisation est un filtre et non une garantie : des logiciels malveillants notarisés glissent parfois à travers les vérifications automatisées d'Apple. Notre analyse du logiciel malveillant MacSync stealer distribué avec une notarisation Apple valide montre que même une application qui passe Gatekeeper proprement peut être malveillante. La leçon n'est pas « méfiez-vous de tout » mais « la source compte plus que la boîte de dialogue ». Si vous ne feriez pas confiance au site web, ne faites pas confiance au téléchargement, peu importe à quel point il se lance proprement. Pour une liste de contrôle de durcissement plus large, notre guide de sécurité et confidentialité Mac couvre les outils qui valent la peine d'être exécutés aux côtés de Gatekeeper.

Comment cela a changé dans Tahoe par rapport aux anciennes versions de macOS

Si vous avez combattu ce problème il y a quelques années, le mode d'emploi a changé. Connaître les différences vous évite de suivre des tutoriels obsolètes.

Clic droit → Ouvrir a disparu. Jusqu'à macOS 14 Sonoma, faire un clic secondaire sur une application et choisir Ouvrir vous donnait une boîte de dialogue de contournement ponctuel. Apple a supprimé cela dans la génération macOS 15/26, et Tahoe 26.5 continue dans cette voie. Le seul remplacement sanctionné pour une application bloquée est le bouton « Ouvrir quand même » dans Réglages Système > Confidentialité et sécurité. Les tutoriels qui vous disent de faire un clic droit et Ouvrir sont périmés.

L'option « Partout » est masquée. Les anciennes versions de macOS vous permettaient de régler Gatekeeper pour autoriser les applications « Partout » dans le panneau Sécurité et confidentialité. Ce bouton radio a été supprimé de l'interface il y a des années et reste masqué dans Tahoe. Vous pouvez parfois faire apparaître un état similaire via la ligne de commande, mais Apple a délibérément rendu la posture « faire confiance à tout » difficile à atteindre parce qu'elle est dangereuse.

spctl --master-disable ne se comporte plus comme annoncé. De nombreux guides anciens vous disent d'exécuter sudo spctl --master-disable pour désactiver Gatekeeper entièrement et faire réapparaître l'option « Partout ». Sur macOS moderne, l'effet de cette commande est limité : elle peut signaler un succès mais les protections de Gatekeeper (en particulier les comportements de notarisation et de translocation) ne sont pas entièrement désactivées comme elles l'étaient sur, disons, macOS 10.14. La System Integrity Protection et l'architecture de sécurité redessinée signifient qu'une seule commande ne peut plus nettoyer l'ensemble du sous-système. Traitez tout guide construit autour de spctl --master-disable comme obsolète.

Plus de friction délibérée dans l'ensemble. Le fil conducteur de l'approche de Tahoe est la friction intentionnelle. Apple veut qu'approuver une application non vérifiée soit une décision consciente et authentifiée prise dans les Réglages Système, pas un réflexe de clic droit. Pour le tableau complet de la sécurité et des CVE de cette version spécifique, consultez notre guide de mise à jour de macOS Tahoe 26.5.

Notes pour les entreprises et MDM

Si vous gérez des Macs dans une organisation, vous disposez d'options que les utilisateurs finaux n'ont pas, et vous ne devriez pas apprendre aux utilisateurs à exécuter des commandes xattr. La gestion des appareils mobiles (MDM) vous permet de déployer la confiance à grande échelle plutôt que machine par machine. Vous pouvez déployer un profil Privacy Preferences Policy Control (PPPC) et des profils de configuration liés à Gatekeeper pour pré-approuver des identités de développeurs spécifiques, de sorte que les applications internes distribuées et approuvées par des tiers se lancent sans invites Gatekeeper. Les builds internes correctement signés et notarisés — même pour les outils internes — sont la bonne réponse à long terme ; payez pour un Developer ID, signez et notarisez vos applications internes pour qu'elles passent Gatekeeper nativement plutôt que de demander aux employés de le désarmer.

Évitez la tentation de pousser une désactivation de Gatekeeper à l'échelle de la flotte. Cela convertit chaque Mac de votre organisation en une cible facile et c'est exactement la posture que les attaquants espèrent trouver. Si vous gérez également ce qui se lance à la connexion à travers la flotte, notre guide de gestion des éléments de connexion et des applications en arrière-plan de Tahoe se marie bien avec une politique Gatekeeper pour contrôler ce qui s'exécute et quand.

Résolution des problèmes courants

Problème : le bouton « Ouvrir quand même » n'apparaît jamais dans Confidentialité et sécurité

Solution : Cela signifie presque toujours que la boîte de dialogue obtenue était la sévère variante « est endommagée » (signature cassée/manquante) plutôt que la plus douce « le développeur ne peut pas être vérifié » — et Apple n'offre pas de remplacement GUI pour les signatures véritablement invalides. D'abord, déplacez l'application depuis Téléchargements/le DMG dans /Applications pour écarter l'App Translocation, puis essayez de la lancer à nouveau afin que macOS enregistre un nouveau blocage. Si le bouton n'apparaît toujours pas, re-téléchargez l'application depuis le site officiel en utilisant Safari. Si elle se télécharge de manière cassée de manière cohérente, le build du développeur lui-même peut être le problème. En dernier recours pour une application en laquelle vous avez confiance, utilisez xattr -dr com.apple.quarantine sur elle.

Problème : Terminal dit « Operation not permitted » lors de l'exécution de xattr

Solution : Il s'agit d'un problème de permissions, pas de syntaxe. macOS protège certains emplacements, et votre application Terminal peut manquer d'accès complet au disque. Allez dans Réglages Système > Confidentialité et sécurité > Accès complet au disque, activez votre terminal (Terminal.app, iTerm, etc.), puis quittez-le complètement et relancez-le. Confirmez également que vous avez tapé le vrai chemin — faites glisser l'application dans la fenêtre Terminal pour insérer son chemin exact. Si l'application réside dans un endroit protégé, la copier dans /Applications en premier et opérer depuis là contourne la restriction.

Problème : l'application s'ouvre une fois, puis se casse ou « s'endommage » à nouveau après une mise à jour

Solution : Cela pointe vers une application qui se met à jour automatiquement en conflit avec l'App Translocation ou avec une signature cassée dans son programme de mise à jour. Assurez-vous que l'application réside dans /Applications (pas Téléchargements), car les programmes de mise à jour automatique en place se comportent mal lorsqu'ils sont transloques. Si l'application se re-met en quarantaine après chaque mise à jour, le programme de mise à jour peut re-télécharger via un mécanisme conscient de la quarantaine. La correction la plus propre est de supprimer l'application, de télécharger une copie fraîche depuis la source officielle, de la faire glisser dans /Applications, de l'approuver une fois via « Ouvrir quand même » et de laisser les futures mises à jour s'exécuter depuis là.

Problème : « Ne peut pas vérifier qu'elle est exempte de logiciels malveillants » même si je suis en ligne

Solution : Vérifiez d'abord l'horloge de votre système avec date — une date incorrecte casse la validation du ticket. Ensuite, confirmez que vous n'êtes pas derrière un proxy, un VPN ou un pare-feu qui bloque les serveurs de notarisation d'Apple ; désactiver temporairement un VPN restrictif et réessayer résout souvent le problème. Exécutez spctl -a -vvv /chemin/vers/App.app pour voir le verdict précis. Si spctl signale l'application comme acceptée/notarisée une fois la connectivité rétablie, l'échec initial était purement un problème de réseau/d'horloge, pas l'application.

Questions fréquemment posées

Est-il sûr d'utiliser xattr pour supprimer l'attribut de quarantaine ?

C'est sûr uniquement lorsqu'il est appliqué à une application spécifique en laquelle vous avez vraiment confiance et provenant d'une source en laquelle vous avez confiance. La commande elle-même ne cause aucun dommage à votre système ; le risque concerne entièrement ce sur quoi vous la pointez. Supprimer la quarantaine désarme la vérification de Gatekeeper pour cette application, donc l'exécuter sur un logiciel douteux est la façon dont les Macs propres se font infecter. Application de confiance depuis le site du développeur : d'accord. Téléchargement « cracké » aléatoire : jamais.

Désactiver Gatekeeper me vaudra-t-il des logiciels malveillants ?

Désactiver Gatekeeper à l'échelle du système augmente considérablement votre exposition, oui. Gatekeeper bloque le chemin le plus facile qu'utilisent les attaquants — vous faire exécuter du code non signé et non notarisé. Sans lui, chaque téléchargement s'exécute sans vérification. Il n'y a pratiquement jamais de bonne raison pour un utilisateur individuel de le désactiver globalement ; approuver une application via « Ouvrir quand même » atteint votre objectif sans laisser la porte ouverte à tout le reste. Gardez Gatekeeper activé.

Pourquoi Terminal dit-il « operation not permitted » lorsque j'exécute xattr ?

Votre application Terminal manque d'accès complet au disque, ou vous ciblez un emplacement protégé par le système. Accordez l'accès dans Réglages Système > Confidentialité et sécurité > Accès complet au disque, activez votre terminal, puis quittez-le et relancez-le. Vérifiez que le chemin est correct en faisant glisser l'application dans la fenêtre Terminal. Il s'agit d'une protection de la confidentialité de macOS qui fait son travail, pas d'un bug dans votre commande.

L'astuce du clic droit « Ouvrir » fonctionne-t-elle toujours dans Tahoe ?

Non. Apple a supprimé le contournement ponctuel clic droit → Ouvrir dans la génération macOS 15/26, et Tahoe 26.5 continue dans cette voie. La seule façon sanctionnée d'ouvrir une application bloquée est le bouton « Ouvrir quand même » dans Réglages Système > Confidentialité et sécurité, qui nécessite une authentification. Tout guide recommandant encore clic droit → Ouvrir est obsolète.

Mon application fonctionnait hier et dit maintenant qu'elle est endommagée. Pourquoi ?

Plusieurs causes correspondent à ce schéma : le certificat de signature du développeur a été révoqué, une mise à jour intégrée a introduit un build cassé ou non notarisé, l'application s'est re-mise en quarantaine lors d'une mise à jour, ou l'horloge de votre système a dérivé et cassé la validation du ticket. Vérifiez d'abord date, puis re-téléchargez une copie fraîche depuis la source officielle et approuvez-la une fois. Si cela continue à se reproduire, signalez-le au développeur.

L'« App Translocation » est-elle la même chose que la quarantaine ?

Non, bien qu'elles soient liées. La quarantaine est l'attribut qui signale un fichier comme téléchargé. L'App Translocation est un comportement défensif que macOS déclenche parce qu' une application est mise en quarantaine et exécutée depuis un emplacement de téléchargement — elle lance l'application depuis un chemin en lecture seule aléatoire pour contrecarrer les attaques par fichiers chargés latéralement. Déplacer l'application dans /Applications arrête la translocation ; supprimer l'attribut de quarantaine arrête le signalement. Des mécanismes différents, des corrections différentes.

Conclusion

L'erreur « l'application est endommagée et ne peut pas être ouverte » sur macOS Tahoe est écrasantement un problème de confiance, pas de corruption. Gatekeeper, l'attribut com.apple.quarantine et la notarisation travaillent ensemble pour empêcher votre Mac d'exécuter du code qu'il ne peut pas vérifier — et la plupart du temps, une application légitime les déclenche à cause d'un attribut de quarantaine, de l'App Translocation, d'une signature cassée par une décompression négligente, d'une incompatibilité d'architecture ou d'une horloge incorrecte. Lisez la boîte de dialogue pour savoir lequel des trois problèmes vous avez, essayez d'abord la route officielle « Ouvrir quand même » dans Confidentialité et sécurité, et utilisez xattr, spctl et codesign uniquement lorsque vous comprenez ce qu'ils sacrifient. La règle à retenir par-dessus tout : la sécurité d'une application vient de sa source, pas de la façon dont vous pouvez la forcer à se lancer.

Pour en savoir plus sur la sécurisation de votre Mac de la bonne façon, poursuivez avec notre guide de sécurité et confidentialité Mac pour 2026 et le guide complet de sécurité et confidentialité macOS Tahoe.