Comment valider une app Mac avant notarisation sur macOS 27 ? Liste 2026

La validation d’une app Mac sur macOS 27 doit porter sur le fichier que les utilisateurs recevront, et pas uniquement sur le projet ou l’archive de développement. Pour une distribution directe, vérifiez la signature Developer ID, le résultat de notarisation et le lancement du livrable ; pour le Mac App Store, suivez le parcours de distribution du magasin. Effectuez d’abord ces contrôles dans un environnement isolé, puis reproduisez la même procédure pour la publication.

Ce guide s’adresse aux développeurs indépendants qui distribuent directement leur app et veulent vérifier que signature, notarisation et fichier livré concordent. Il concerne aussi les petites équipes utilisant un DMG ou un PKG, ainsi que les personnes qui évaluent un Mac distant pour stabiliser leurs publications.

Dernière mise à jour : 6 novembre 2026. Vérification des règles et des informations de plateforme à partir de la documentation Apple Developer sur la notarisation, les flux de travail et macOS 27.

Les preuves à réunir avant de publier

Une notarisation réussie ne prouve pas, à elle seule, que le fichier livré est celui qui a été contrôlé ni que l’app démarre correctement sur la plateforme ciblée. La réception doit relier le résultat du service de notarisation au livrable final, puis à un essai de lancement effectué dans un environnement correspondant aux utilisateurs visés.

Apple distingue la distribution directe de la distribution par le Mac App Store. Pour la première, sa documentation sur la notarisation des logiciels macOS décrit les conditions applicables, notamment la signature et Hardened Runtime. La présentation Apple des modes de distribution permet de déterminer quel parcours concerne l’app. Il ne faut donc pas transformer l’étape de notarisation Developer ID en règle universelle pour tout logiciel Mac.

Ce tableau sert à organiser la réception ; il ne remplace pas les exigences propres à chaque canal. Les instructions d’Apple pour empaqueter un logiciel Mac précisent les aspects de distribution à examiner selon le type de livrable.

Pour éviter les confusions, séparez au minimum les éléments suivants dans le dossier de publication : le fichier soumis, la réponse du service de notarisation, le fichier final remis aux utilisateurs et le résultat du test de lancement. Une version de l’app peut être acceptée par le service, puis remplacée par un autre binaire lors de la création du DMG ou du PKG. Dans ce cas, l’ancienne réponse ne constitue pas une preuve suffisante pour le nouveau livrable.

Comment valider une distribution directe avec Developer ID ?

Commencez par confirmer que l’app est destinée à être remise directement aux utilisateurs, hors Mac App Store. Apple décrit la notarisation comme un contrôle de sécurité destiné à ce type de distribution ; sa documentation sur Hardened Runtime explique le rôle de cette protection et les capacités supplémentaires qui peuvent nécessiter des droits spécifiques.

Avant l’envoi, vérifiez que la signature correspond à l’identité Developer ID prévue pour la publication. Examinez aussi les droits activés : ils doivent répondre aux besoins réels de l’app, et non servir à masquer un problème de configuration. Les services de signature de code d’Apple détaillent les informations associées aux signatures et à la validation de code.

Comment confirmer que la notarisation est bien terminée après la signature Developer ID ? La signature seule n’est pas le résultat de notarisation. Soumettez le fichier prévu avec notarytool, conservez l’identifiant de soumission et vérifiez l’état renvoyé par le service. Si un rapport est disponible, archivez-le avec la version concernée au lieu de ne garder qu’une capture d’écran ou une mention « accepté ».

La documentation Apple sur la personnalisation du flux de notarisation décrit l’usage de notarytool et les informations de suivi du traitement. La réception doit associer ces éléments à un fichier déterminé. Un état favorable sans référence de soumission, sans identification de l’archive ou sans lien avec la version publiée est difficile à auditer et ne permet pas d’écarter une substitution ultérieure.

DMG ou PKG : quelle réception appliquer ?

Un DMG est une image disque destinée à être téléchargée puis montée. Un PKG est un paquet d’installation qui exécute une installation. Ces deux formats n’occupent donc pas le même rôle dans la chaîne de livraison. Vérifier uniquement l’app contenue dans l’image ne démontre pas que le DMG remis au public a été contrôlé ; de même, un résultat associé au PKG ne remplace pas l’examen de l’app après installation.

Pour un DMG, qu’est-ce qui doit correspondre au fichier proposé au téléchargement ? Le fichier image soumis ou contrôlé doit être celui que le canal de distribution met effectivement à disposition. Après traitement du ticket selon le flux retenu, montez l’image, vérifiez son contenu et lancez l’app selon le parcours normal prévu pour l’utilisateur. Si l’app est copiée dans le dossier Applications, testez également cette copie plutôt que de conclure à partir du seul montage.

Pour un PKG, quel contrôle faut-il ajouter après la notarisation ? Vérifiez séparément la signature et le résultat associé au paquet, puis exécutez l’installation dans un environnement de test. Une fois l’installation terminée, examinez l’app installée : chemin attendu, identité de signature et démarrage. La séquence d’installation peut révéler un problème que la seule inspection du paquet n’aurait pas montré.

Un changement du contenu après la validation — par exemple une nouvelle app intégrée à l’image, un script de post-installation modifié ou un paquet reconstruit — doit entraîner une nouvelle réception du livrable concerné. Le résultat antérieur ne certifie pas automatiquement un fichier remplacé.

Dans les deux cas, conservez des éléments qui permettent de reconstituer l’opération : nom et empreinte du fichier contrôlé, commande ou étape de soumission, identifiant et résultat, état du ticket, puis résultat du montage ou de l’installation. Ce dossier n’a pas besoin d’être volumineux ; il doit surtout établir une correspondance explicite entre l’artefact accepté et celui qui a été distribué.

Mac App Store : un parcours différent

Une app distribuée par le Mac App Store suit le processus de soumission et d’examen prévu par le magasin. Les développeurs ne doivent pas appliquer mécaniquement à ce canal toutes les étapes d’une distribution directe par Developer ID. La documentation Apple sur la distribution des apps distingue ces parcours et précise leur cadre.

Une app du Mac App Store doit-elle aussi passer par la même notarisation Developer ID que l’app distribuée directement ? Le contrôle pertinent est celui du parcours de soumission au magasin. Ne considérez pas l’absence d’une soumission directe à notarytool comme une preuve d’échec pour une version destinée au Mac App Store. En revanche, la réception du projet doit conserver la version soumise, son état de traitement et la version effectivement rendue disponible.

Le contrôle final ne s’arrête pas à l’acceptation de la soumission. Installez ou récupérez la version publiée dans les conditions de test prévues, puis vérifiez qu’elle démarre et que ses fonctions importantes répondent. Cette vérification couvre un autre risque : une publication peut suivre le bon canal tout en livrant une version différente de celle qui a été validée localement.

macOS 27 : distinguer compatibilité et notarisation

Apple indique que macOS 27 ne prend en charge que les Mac à puce Apple ; la limite doit donc entrer dans le choix de l’environnement de validation. Cette information figure dans les notes de version de macOS 27. Elle ne signifie pas qu’une app notarée est automatiquement compatible, ni qu’une app qui démarre sur une machine donnée a passé les contrôles de distribution.

Les deux conclusions doivent être consignées séparément :

• Résultat de conformité de distribution : identité de signature, exigences Hardened Runtime, soumission et statut de notarisation lorsque le canal l’exige.
• Résultat de compatibilité : environnement utilisé, architecture de la cible, installation et lancement de l’app, puis vérification des fonctions essentielles.

Pour une app qui dépend d’outils, de greffons ou de composants anciens, examinez également les changements de plateforme à partir des sources Apple plutôt que de déduire la compatibilité du seul numéro de version. Par exemple, Apple a publié une information sur l’évolution de la prise en charge de Rosetta dans son annonce consacrée à Rosetta. Cette annonce doit être lue dans son contexte : elle ne remplace ni les notes de version du système ciblé ni un essai concret de l’app et de ses dépendances.

Une validation utile consigne donc le système installé, le type de puce, la version de Xcode et les paramètres de construction pertinents, puis le résultat du lancement. Les détails exacts dépendent du projet ; ils ne doivent pas être présentés comme une configuration universelle. Apple documente aussi les possibilités de personnalisation de l’étape d’archivage Xcode, à examiner lorsqu’un flux automatisé modifie les produits exportés.

Une procédure reproductible sur Mac distant

Un Mac distant peut convenir à une réception répétée si l’équipe peut installer les outils requis, contrôler les secrets de signature et récupérer les artefacts et journaux. Il ne faut cependant pas confondre accès à une machine avec traçabilité du processus : sans gestion des versions, conservation des preuves et validation du livrable téléchargé, l’environnement distant ne règle pas les erreurs de chaîne de publication.

Première étape : isoler la version à vérifier

Créez une révision dédiée et identifiez précisément le commit, l’archive ou le binaire soumis. Évitez de modifier les ressources après le début de la réception. Si le projet produit plusieurs variantes, indiquez celle qui correspond au canal de publication visé.

Deuxième étape : préparer l’identité de signature

Vérifiez que le certificat Developer ID et les ressources de signature nécessaires sont disponibles pour le compte autorisé. Limitez l’accès aux secrets et consignez la méthode employée pour les injecter dans le processus. Cette préparation doit être identique entre la réception de test et la publication, à l’exception des identifiants ou paramètres explicitement réservés à l’un des environnements.

Troisième étape : construire et inspecter

Construisez l’app dans l’environnement macOS choisi. Vérifiez la signature, les droits et l’archive exportée avant de soumettre quoi que ce soit. Si l’application dépend de bibliothèques ou de ressources intégrées, contrôlez qu’elles font bien partie du livrable final. Une compilation réussie n’établit pas à elle seule que le produit exporté est correctement signé.

Quatrième étape : soumettre le bon artefact

Choisissez le fichier correspondant au mode de livraison : app, DMG ou PKG selon le flux effectivement retenu. Lancez la soumission avec notarytool lorsqu’il s’agit d’une distribution directe concernée, puis archivez l’identifiant et le rapport de traitement. Les outils Apple permettent de personnaliser le flux ; l’équipe doit néanmoins éviter de soumettre un artefact intermédiaire en pensant avoir contrôlé le fichier final.

Cinquième étape : traiter le ticket et vérifier le paquet livré

Appliquez le traitement du ticket adapté à l’artefact, puis reconstruisez le fichier de livraison si cette étape fait partie du processus. Après toute reconstruction, comparez le résultat au fichier précédemment contrôlé. Si le DMG ou le PKG a changé, recommencez les contrôles nécessaires sur ce nouveau livrable.

Sixième étape : installer et lancer dans la cible

Téléchargez ou récupérez le fichier exactement comme le ferait un utilisateur. Montez le DMG ou installez le PKG selon le cas, puis lancez l’app. Consignez les éventuels avertissements, le chemin d’installation et les opérations essentielles testées. Pour une app destinée à macOS 27, l’environnement choisi doit tenir compte de la limite matérielle documentée par Apple.

Septième étape : figer le dossier de preuve

Réunissez l’identifiant de version, le type d’artefact, les informations de signature, le résultat de notarisation lorsqu’il s’applique, l’état du ticket et le résultat du lancement. Archivez ces données avec le fichier distribué, ou avec une empreinte permettant de l’identifier. Ce dossier transforme un résultat ponctuel en procédure reproductible et aide à repérer si le fichier publié diffère de celui qui a été reçu.

Choisir un environnement sans alourdir la publication

La décision dépend du rythme de sortie, de la confidentialité des certificats et de la nécessité d’une machine disponible pour les essais. Une machine locale convient si elle offre déjà un environnement macOS compatible et un stockage suffisant. Une chaîne entièrement automatisée peut suffire si elle conserve les artefacts et les preuves. Un Mac distant devient intéressant lorsque plusieurs versions doivent passer par un environnement stable, mais il nécessite tout de même une discipline de gestion des accès et des secrets.

• Si l’équipe possède déjà un Mac adapté et publie ponctuellement, gardez la réception en local et documentez les mêmes vérifications de livrable.
• Si la compilation et la notarisation doivent être répétées, choisissez un environnement Mac administrable où versions, certificats et rapports restent accessibles à l’équipe.
• Si le projet est distribué par le Mac App Store, conservez le parcours du magasin et n’ajoutez pas une étape Developer ID uniquement pour reproduire un guide de distribution directe.
• Si le livrable est un DMG ou un PKG, faites porter la dernière vérification sur ce format précis, puis sur l’app montée ou installée.
• Si l’app exige une interface physique ou une charge locale soutenue, un Mac dédié sur place peut être plus approprié qu’un environnement distant.

Pour les équipes qui veulent examiner les conditions d’accès et les modalités d’un Mac distant, la présentation des offres Mac d’OrbVPS permet de vérifier si ce mode correspond au processus envisagé. La FAQ OrbVPS peut aussi aider à clarifier les questions pratiques avant de déplacer une chaîne de publication.

Un poste déjà disponible évite une location, mais peut immobiliser la machine pendant les compilations et les validations ; une chaîne CI sans Mac administré peut rendre plus difficile l’inspection manuelle du livrable ; un environnement mal documenté expose l’équipe à perdre la trace de la version réellement notarée. Si ces limites ralentissent des vérifications récurrentes, louer un Mac auprès d’OrbVPS peut fournir un environnement macOS dédié sans achat immédiat de matériel. Ce choix est pertinent pour une période de publication ou une équipe qui a besoin d’un environnement stable ; pour une charge soutenue à long terme ou des périphériques physiques indispensables, un Mac acheté et présent sur site peut rester préférable.