Comment notarier une app macOS ? 2026 : liste de publication sur Mac distant

Choisir le parcours de distribution avant de préparer le Mac

La première décision porte sur le destinataire et le canal de distribution. Pour remettre une application directement aux utilisateurs, le parcours repose sur une signature de distribution Developer ID et, selon le type de livrable, une soumission à la notarisation. Une publication dans l’App Store suit un processus de soumission et d’examen distinct. La notarisation ne vaut donc ni approbation App Store ni garantie qu’un produit répond aux exigences de cette boutique. Apple distingue ces modes de distribution dans sa documentation sur les versions et les tests bêta et décrit séparément la notarisation des logiciels macOS avant leur distribution.

Ce tableau évite une confusion fréquente : « signé », « notarié » et « accepté par l’App Store » désignent des états différents. La signature associe le logiciel à une identité de développeur et permet de vérifier son intégrité ; la notarisation est un contrôle automatisé du logiciel soumis pour distribution hors de la boutique. Pour les détails des certificats, consultez la description Apple des certificats Developer ID.

Sur un Mac distant, cette distinction est particulièrement utile quand un client attend un fichier précis : un projet qui se compile n’est pas nécessairement correctement signé, et un résultat de notarisation positif ne prouve pas à lui seul que le téléchargement livré s’ouvre comme prévu.

Avant le départ : réunir les accès et protéger les secrets

Avant toute soumission, vérifiez que le compte de développement, l’équipe et les autorisations nécessaires sont accessibles à la personne qui effectuera la publication. Un compte fonctionnel ne suffit pas si le développeur n’a pas le rôle requis pour gérer les certificats, signer le projet ou utiliser le flux de soumission. Si l’accès à l’équipe ou à l’identité de signature n’est pas confirmé, arrêtez-vous avant de construire un livrable destiné à la production : une archive générée localement ne compense pas une autorisation manquante.

Dans Xcode, examinez l’équipe associée à la cible de distribution et l’identité de signature sélectionnée. Apple précise les conditions de création d’un certificat Developer ID dans son guide des certificats de distribution Developer ID. Vérifiez aussi que le certificat et sa clé privée sont disponibles sur l’environnement qui signera le produit. Ne supposez pas que l’accès au dépôt de code implique l’accès à cette identité.

Les secrets exigent un traitement séparé. Un profil de trousseau destiné à notarytool, une clé privée de signature, un mot de passe ou un jeton d’accès ne doivent pas être placés dans le dépôt, dans un fichier de configuration partagé ou dans un script conservé avec les sources. Réservez les secrets aux mécanismes de stockage protégés disponibles sur votre environnement, limitez les personnes et processus qui peuvent les utiliser, puis supprimez ou révoquez les accès temporaires après la publication si votre politique l’exige. La documentation Apple sur le flux de notarisation personnalisable décrit les mécanismes de soumission et d’authentification à choisir selon le flux retenu.

Sur un poste accessible à distance, consignez également comment récupérer le projet, les certificats autorisés et les fichiers de travail après une déconnexion ou un changement d’appareil. Cette préparation ne doit pas transformer une copie de secours en duplication incontrôlée de secrets : séparez les sources récupérables des éléments d’authentification qui demandent une protection renforcée.

Depuis un Mac distant, les contrôles locaux restent indispensables

Un Mac distant peut-il mener la notarisation d’une application macOS ? Oui, si l’environnement permet de construire le projet, d’utiliser l’identité de signature et les identifiants de soumission autorisés, puis de récupérer et vérifier le résultat. Le fait de se connecter à distance ne modifie pas le parcours Apple ; les limites pratiques sont plutôt l’accès aux secrets, la stabilité de la session et la possibilité d’inspecter le fichier final.

Un Mac distant convient si vous disposez déjà d’un accès autorisé au projet et si les outils nécessaires sont présents. Avant de vous engager sur un livrable client, testez la chaîne de travail sans publier immédiatement : ouverture du projet, compilation, accès au trousseau, signature, création de l’archive et récupération d’un fichier de contrôle. Pour comprendre les modalités d’accès proposées, vous pouvez consulter la présentation du Mac distant NodeMini ; elle ne constitue toutefois pas une preuve que votre projet ou vos identifiants fonctionneront dans l’environnement choisi.

Trois limites méritent une vérification concrète :

• La session peut être interrompue. Une déconnexion ne signifie pas nécessairement que le traitement en cours a échoué, mais il faut pouvoir retrouver l’identifiant de soumission et consulter son état après reconnexion.
• Le trousseau et les autorisations ne se déduisent pas de l’accès au bureau. Si l’identité de signature n’est pas disponible ou si le projet refuse de l’utiliser, la création d’une archive ne prouve pas que celle-ci est distribuable.
• Le transfert du livrable ajoute un point de contrôle. Il faut comparer le fichier récupéré au résultat validé, puis effectuer l’installation depuis ce fichier, pas uniquement depuis le dossier de développement.

Si l’équipe ne peut pas déléguer l’accès à une identité de signature ou si un projet exige une intervention physique que l’environnement ne permet pas, gardez un Mac local de secours. En revanche, si les autorisations et la récupération des artefacts sont validées, le Mac distant peut exécuter les étapes techniques sans que le développeur emporte son poste principal.

Première signature : examiner l’application et ses composants

Une compilation réussie et une ouverture sur le Mac de développement ne suffisent pas à valider un paquet destiné à des utilisateurs. Avant la notarisation, inspectez la signature de l’application et des composants imbriqués concernés : extensions, outils auxiliaires ou autres éléments embarqués peuvent avoir leurs propres exigences de signature. La configuration du Hardened Runtime et les capacités autorisées doivent correspondre aux besoins réels du logiciel ; Apple en détaille le rôle dans sa documentation sur la configuration du Hardened Runtime.

Commencez par sélectionner la bonne équipe et l’identité Developer ID dans les réglages de signature de la cible Xcode. Construisez ensuite le produit de distribution prévu, plutôt que de supposer qu’une version de développement représente le futur installateur. La documentation Apple sur l’empaquetage des logiciels Mac pour distribution aide à choisir une forme de livraison cohérente avec le produit.

Pour recueillir des éléments de diagnostic, vous pouvez vérifier la signature de l’application construite avec codesign :

codesign --verify --deep --strict --verbose=2 "Chemin/MonApp.app"

Une commande sans erreur indique que cette vérification n’a pas signalé de problème de signature sur l’objet examiné ; elle ne prouve pas à elle seule que le logiciel a été notarié, que le ticket est attaché ou que le client pourra installer le fichier transmis. Conservez la commande utilisée et sa sortie dans le dossier de publication, en veillant à ne pas y inclure de secret.

Si un contrôle échoue, ne passez pas directement à la soumission. Examinez les journaux de construction, la signature de la cible principale et les composants embarqués, puis reconstruisez l’archive après correction. Les erreurs de signature et les erreurs de soumission ne sont pas interchangeables : il faut identifier à quelle étape elles surviennent avant de modifier des autorisations ou des réglages de sécurité.

Soumission à la notarisation : conserver une trace exploitable

Une fois l’application signée et le livrable préparé, choisissez le flux Apple adapté au format livré. Xcode ou les outils en ligne de commande peuvent participer au processus ; dans les deux cas, conservez les éléments qui permettent de relier le fichier soumis au résultat retourné. La documentation Apple sur la notarisation macOS décrit le parcours et les formats de distribution concernés.

Avec notarytool, un profil de trousseau préalablement configuré permet d’éviter d’inscrire des informations secrètes directement dans la commande de soumission. Le modèle ci-dessous montre l’ordre des opérations ; remplacez le nom du fichier et du profil par ceux de votre environnement :

xcrun notarytool submit "MonApp.zip" \
  --keychain-profile "profil-notarisation" \
  --wait

Le résultat fournit notamment un état et un identifiant de soumission. Enregistrez cet identifiant avec le nom du fichier, sa version interne et la date de votre opération, selon le système de suivi de votre équipe. Si la session distante est interrompue, reprenez le suivi à partir de cet identifiant plutôt que de soumettre à nouveau un fichier sans vérifier le premier traitement.

Pour interroger l’état ou obtenir le journal associé, utilisez les commandes correspondantes :

xcrun notarytool info "IDENTIFIANT-DE-SOUMISSION" \
  --keychain-profile "profil-notarisation"

xcrun notarytool log "IDENTIFIANT-DE-SOUMISSION" \
  --keychain-profile "profil-notarisation"

Ne confondez pas un accusé de réception, un traitement en cours et un résultat accepté. Tant que l’état final et le journal n’ont pas été examinés, le livrable n’est pas prêt à être annoncé comme notarié. Si le service signale un rejet ou un avertissement, conservez le journal, reliez-le au fichier soumis, puis corrigez la cause dans le projet ou le paquet avant une nouvelle tentative. Évitez de remplacer le fichier en silence après validation : la version que vous livrez doit rester identifiable.

Cette traçabilité est particulièrement importante en déplacement, lorsque le développeur change d’appareil ou travaille à des heures différentes de celles du client. Un dossier de publication utile rassemble le fichier exact soumis, l’identifiant de traitement, son état final, les journaux pertinents et la version qui sera remise.

Après l’acceptation : traiter le ticket et tester le fichier livré

Un résultat positif de notarisation, le traitement du ticket et la validation de l’expérience d’installation sont des étapes distinctes. Selon le type de livrable, le ticket doit être attaché à l’élément approprié ; l’outil stapler permet notamment de traiter un élément compatible et de vérifier l’attachement. Suivez les instructions Apple correspondant au format réellement distribué plutôt que d’appliquer une commande identique à tous les paquets.

Pour une application distribuée sous forme d’app, le contrôle peut prendre cette forme :

xcrun stapler staple "MonApp.app"
xcrun stapler validate "MonApp.app"

N’interprétez pas le succès de ces commandes comme une validation de l’installateur complet si vous livrez un autre type de paquet. Vérifiez le fichier qui sera remis — application, image disque ou installateur — et suivez le parcours adapté à cet artefact. Apple décrit les options d’empaquetage et de distribution dans son guide de préparation des logiciels Mac.

La dernière vérification doit être faite depuis une copie récupérée comme le ferait le destinataire. Téléchargez le fichier livré dans un environnement de test propre, ouvrez-le et examinez le premier lancement. Vérifiez que le bon nom d’application apparaît, que les ressources attendues sont présentes et que les fonctions essentielles ne dépendent pas d’un fichier ou d’un accès resté sur le Mac de construction. Pour une application audio, vidéo ou de conception, ajoutez un test du flux créatif réellement promis : ouvrir un projet témoin, charger les ressources et exporter ou enregistrer un résultat. Une simple ouverture depuis Xcode ne couvre pas ces usages.

Avant l’envoi au client, rapprochez le nom et la version du fichier testé de ceux du fichier joint au message ou mis à disposition. Si le fichier change après la notarisation ou après le test, reprenez les contrôles appropriés sur la nouvelle version au lieu de considérer les anciens résultats comme valables.

Décision de publication : valider le poste avec le projet réel

La validation d’un environnement distant dépend du projet, des droits accordés et de la manière dont l’équipe protège ses identifiants. Aucune présentation d’environnement ne garantit qu’un certificat particulier sera utilisable ou qu’une application donnée recevra un résultat positif. La décision raisonnable se prend donc après un essai avec le dépôt, les réglages et le livrable réels, en vérifiant au minimum les points suivants :

• le développeur peut ouvrir le projet et construire la cible prévue ;
• l’identité de signature et les accès de soumission autorisés sont disponibles ;
• le contrôle de signature ne révèle pas de défaut non résolu ;
• l’état final de la soumission et son journal peuvent être retrouvés après reconnexion ;
• le ticket est traité pour le format concerné ;
• le fichier récupéré s’installe et s’ouvre dans un environnement de test.

Si l’un des contrôles liés à l’identité ou au livrable échoue, conservez votre Mac local comme poste de publication et traitez le Mac distant comme un environnement de préparation. Si tous les contrôles passent pour une version représentative du projet, vous pouvez envisager d’y effectuer la publication suivante, tout en gardant une procédure de récupération et une copie de travail vérifiée.

Un poste local reste préférable lorsque le travail exige un accès matériel particulier, une utilisation hors ligne fiable ou une présence physique auprès de périphériques. À l’inverse, emporter le Mac principal en voyage ajoute le risque de perte de l’appareil, rend le travail dépendant de ce matériel et complique la reprise si celui-ci devient indisponible. Pour les périodes où il faut seulement un environnement macOS accessible à distance, NodeMini peut être envisagé après examen de ses modalités de Mac distant et un essai court avec le projet réel. Cette vérification porte sur l’accès et le flux de travail ; elle ne préjuge pas du résultat de notarisation, qui dépend toujours de l’application, de sa signature et du traitement Apple.