Décision immédiate — si votre chaîne de publication repose déjà sur un Mac et Xcode, privilégiez notarytool ; si vous devez confier uniquement l’échange avec le service de notarisation à un flux Windows ou Linux, évaluez Notary API. Cette API peut supprimer la dépendance à macOS pour la soumission et le suivi, mais elle ne transforme pas toute la publication d’une application macOS en processus réalisable sans Mac.
Cette semaine : identifiez séparément qui construit, signe, soumet, suit le résultat, agrafe le ticket de notarisation et valide le fichier réellement livré. Vous pourrez alors choisir l’outil selon le maillon à déplacer, plutôt que de migrer toute la chaîne pour remplacer une seule commande.
Ce guide s’adresse aux indépendants qui distribuent une application macOS en dehors de la boutique d’applications et doivent la faire notariser. Il concerne aussi les équipes qui évaluent une soumission depuis Windows ou Linux, ainsi que les responsables des secrets de signature et de l’acceptation de la version livrée.
SECTION 01 Que couvre réellement la notarisation Xcode sans Mac ?
La réponse dépend de l’étape que vous cherchez à déplacer. Notary API permet d’interagir avec le service de notarisation sans dépendre de macOS pour cette interaction. Cela ne signifie pas que l’API construit votre application, la signe, agrafe son ticket ou vérifie à votre place le paquet destiné aux utilisateurs.
Dans une chaîne de publication, distinguez les responsabilités suivantes :
| Étape | Ce que vous devez obtenir | Ce que Notary API change |
|---|---|---|
| Construction | Le binaire et les ressources de l’application | Elle ne fournit pas de capacité de construction macOS |
| Signature | Un produit signé selon les exigences de distribution | Elle ne signe pas le produit |
| Soumission | L’envoi du produit au service de notarisation | Elle permet d’effectuer cet échange sans dépendre de macOS |
| Suivi et diagnostic | L’état du traitement et les informations de journal | L’API expose des opérations de suivi et de lecture du journal |
| Agrafage et contrôle final | Le ticket associé au produit et la validation du fichier livré | Ne confondez pas l’échange avec le service et ces opérations de publication |
La documentation Apple décrit Notary API comme une interface destinée à soumettre un logiciel, à consulter l’état de la soumission et à récupérer son journal. Ce sont trois responsabilités d’échange avec le service, et non trois garanties que le logiciel complet est prêt à distribuer. Consultez la présentation officielle de Notary API avant de concevoir une intégration autour de ce périmètre.
La distinction est importante si une équipe dit « notre publication fonctionne sous Linux » alors que seul l’envoi de l’archive a été déplacé. La compilation, la signature et la préparation de l’artefact restent des responsabilités distinctes. La documentation Apple sur la préparation d’une application pour la distribution aide à replacer la notarisation dans la chaîne de préparation, au lieu de la traiter comme une étape qui remplace les autres.
SECTION 02 Pour une chaîne Xcode déjà sur Mac, conserver notarytool
Si vous construisez et signez déjà votre application sur macOS, notarytool s’insère dans un environnement où les outils de développement Apple sont disponibles. L’intérêt d’une intégration REST supplémentaire est alors limité si votre seul objectif est de faire traiter un produit par le service et de récupérer le résultat dans la même chaîne.
Apple documente des flux de notarisation personnalisés, notamment l’usage d’outils en ligne de commande et de l’interface de programmation. L’existence d’une API ne rend donc pas automatiquement souhaitable le remplacement de notarytool : le bénéfice dépend de vos besoins d’orchestration, de votre système de construction et de la manière dont vous gérez les secrets. La documentation sur la personnalisation du flux de notarisation constitue le point de comparaison pour séparer le mécanisme d’échange de vos tâches de publication.
| Critère de décision | notarytool |
Notary API |
|---|---|---|
| Chaîne déjà centrée sur Xcode et macOS | Choix naturel si la soumission s’intègre à vos outils existants | À envisager si vous avez un besoin d’intégration précis qui justifie une couche supplémentaire |
| Exécution de la soumission depuis Windows ou Linux | Ne partez pas du principe que l’outil natif sera disponible dans ces environnements | Pertinent pour déplacer l’interaction avec le service hors de macOS |
| Gestion de l’intégration | Appel de commande et traitement de son résultat | Appels HTTP, authentification, gestion des réponses et des erreurs |
| Suivi et investigation | À intégrer à votre procédure de publication avec les commandes appropriées | L’API prévoit le suivi d’état et la récupération du journal |
| Agrafage du ticket et acceptation du livrable | À traiter séparément de la soumission | Toujours à traiter séparément de l’API |
Les outils en ligne de commande Xcode sont associés à un environnement macOS, comme le rappelle la documentation Apple sur l’installation des outils de ligne de commande. Cela ne justifie pas de déduire que tout le projet doit être déplacé sur un Mac lorsqu’une autre partie de la chaîne fonctionne ailleurs ; cela signifie plutôt que vous devez vérifier l’environnement nécessaire à chaque commande.
Pour un développeur qui veut automatiser une publication Xcode existante, conservez donc notarytool tant que la soumission, le suivi et le diagnostic restent correctement intégrés à la chaîne macOS. Vous éviterez de maintenir une seconde implémentation HTTP, une génération de jetons et un traitement distinct des erreurs sans bénéfice concret. En revanche, si l’orchestrateur de publication ne peut pas exécuter d’outils macOS et que vous souhaitez faire la soumission depuis cet orchestrateur, Notary API répond à un besoin différent.
SECTION 03 Pour une équipe Windows ou Linux, les possibilités de Notary API
Le cas pertinent n’est pas « publier entièrement une application macOS sans Mac », mais « effectuer l’échange avec le service de notarisation depuis une chaîne qui n’exécute pas macOS ». Apple indique que l’API permet de dialoguer avec le service depuis un environnement qui n’est pas un Mac. La soumission, la consultation de l’état et l’obtention du journal peuvent ainsi s’intégrer à un système qui sait construire et manipuler l’artefact attendu.
La documentation Apple décrit un flux web de soumission qui sépare la préparation du fichier, son envoi et les échanges avec l’API. Pour concevoir cette partie, consultez les indications de soumission d’un logiciel pour notarisation sur le Web. Cette possibilité ne constitue pas une déclaration selon laquelle Windows ou Linux peuvent remplacer macOS pour toutes les opérations de préparation et de finalisation.
La frontière à retenir est donc précise : Notary API peut déplacer la communication avec le service, pas vous fournir une machine de construction ni valider votre distribution de bout en bout. Si l’artefact est construit dans un système externe, vérifiez que votre processus produit bien le fichier attendu par le flux de notarisation et que les étapes de signature ont été effectuées. Si une opération ultérieure dépend d’un outil macOS, prévoyez un Mac pour cette opération ou réorganisez la chaîne afin qu’un environnement Mac prenne en charge ce maillon.
Il faut aussi éviter une confusion de vocabulaire entre « le service a accepté ma soumission » et « le paquet que je distribue est prêt ». Un statut favorable décrit le résultat du traitement par le service. Il ne prouve pas, à lui seul, que vous avez récupéré le bon fichier, agrafé le ticket quand votre méthode de distribution l’exige, ou testé le produit identique à celui que vous remettrez aux utilisateurs.
SECTION 04 Quand faut-il préférer Notary API à notarytool ?
Choisissez selon le besoin qui vous fait changer d’outil, puis appliquez ces conditions avant d’ouvrir un chantier de migration :
- Si votre construction et votre signature ont lieu sur un Mac avec Xcode, et que ce Mac peut aussi soumettre le produit, choisissez
notarytool. Vous gardez une chaîne plus proche de l’environnement de publication déjà en place. - Si l’orchestrateur Windows ou Linux doit lui-même soumettre le produit et suivre le traitement, évaluez Notary API. Limitez le changement à l’interaction avec le service et documentez les étapes qui restent assurées ailleurs.
- Si vous cherchez à supprimer tout Mac du processus, ne choisissez ni l’API ni le seul outil de soumission comme solution complète. Cartographiez d’abord construction, signature, agrafage et validation ; toute étape exigeant un outil ou un environnement macOS doit avoir un responsable et un emplacement d’exécution.
- Si votre produit est construit par un système externe, mais que la préparation et la validation finale restent sur Mac, comparez l’API à
notarytoolsur le seul point de la soumission. Vous pouvez ainsi déplacer un maillon sans rendre ambiguë la responsabilité du livrable. - Si personne ne peut maintenir les jetons, les reprises sur erreur et la récupération des journaux, restez sur la voie la plus facile à exploiter. Une API multiplie les éléments d’intégration que votre équipe doit surveiller ; l’absence de besoin multiplateforme n’est pas une raison suffisante pour les ajouter.
Cette décision par conditions évite deux fausses alternatives : imposer un Mac à chaque tâche de la chaîne, ou croire qu’un appel d’API rend l’ensemble de la publication indépendant de macOS. Pour cadrer la préparation des artefacts et les contrôles attendus, appuyez-vous sur les consignes Apple de distribution plutôt que sur le seul succès de la requête de soumission.
SECTION 05 Vérifications des clés, de l’agrafage et de la livraison
Le choix de l’interface déplace aussi une responsabilité de sécurité. Le flux de Notary API repose sur une authentification par jeton JWT et sur des données d’accès associées à l’envoi du fichier ; la documentation du flux de soumission Web décrit les échanges concernés. Traitez la clé privée comme un secret de publication : elle ne doit pas se retrouver dans un dépôt, un journal de tâche partagé ou un artefact téléchargeable.
N’enregistrez pas les jetons réutilisables ni les données d’accès temporaires dans des sorties de diagnostic accessibles à toute l’équipe. Réduisez les droits d’accès au système qui génère le jeton, séparez les journaux opérationnels des secrets et définissez qui peut révoquer ou renouveler les éléments d’authentification. Pour notarytool, faites également l’inventaire de l’endroit où les identifiants sont conservés et des personnes ou processus capables de les lire. La comparaison n’est donc pas simplement « commande contre API » : elle porte aussi sur le lieu où les secrets résident et sur les contrôles autour de leur usage.
Un résultat de soumission ne suffit pas comme preuve d’acceptation du produit livré. Conservez le lien entre l’artefact soumis, son résultat, le ticket agrafé le cas échéant et le fichier réellement transmis aux utilisateurs.
Pour l’agrafage, ne supposez pas que Notary API réalise automatiquement une opération qui appartient à votre procédure locale de finalisation. Vérifiez le flux décrit par Apple pour votre type de produit et la méthode de distribution retenue ; la documentation sur la personnalisation de la notarisation aide à distinguer la communication avec le service des opérations exécutées après le traitement. Si un outil macOS est nécessaire à cette finalisation, prévoyez une étape sur Mac, même lorsque la soumission a été envoyée depuis Linux.
La validation doit porter sur l’artefact effectivement remis, pas sur un fichier voisin portant un nom similaire. Après le traitement, comparez l’identité et l’emplacement du paquet, vérifiez le résultat et son journal, réalisez l’agrafage si votre flux le demande, puis refaites les contrôles sur la copie destinée à la distribution. En cas de refus, utilisez le journal pour identifier la cause plutôt que de relancer aveuglément la même soumission. Apple fournit des pistes de diagnostic dans son guide de résolution des problèmes courants de notarisation.
Pour rendre le contrôle reproductible, faites avancer le produit par étapes plutôt que de juger le processus à partir d’un seul voyant vert :
- Jalon de préparation : consignez quel système construit le produit, quel environnement le signe et quel fichier exact sera soumis.
- Jalon d’authentification : attribuez un responsable aux clés et aux données d’accès ; vérifiez qu’aucun secret réutilisable n’est imprimé dans les journaux.
- Jalon de soumission : enregistrez l’identifiant de la demande et le lien avec l’artefact envoyé, sans exposer les données d’accès.
- Jalon de résultat : contrôlez l’état et consultez le journal avant de décider si l’équipe peut poursuivre ou doit corriger le paquet.
- Jalon de livraison : effectuez l’agrafage lorsque le flux retenu le prévoit, puis validez le fichier réellement publié.
Ces jalons ne sont pas une recette de construction complète : ils servent à rendre visibles les frontières de responsabilité, quel que soit le système qui a produit l’application. Si une équipe ne peut pas établir le lien entre le fichier soumis et celui livré, la première amélioration est la traçabilité, pas le remplacement de notarytool par Notary API.
SECTION 06 Validation d’une chaîne mixte sans déplacer tout le projet
Avant de modifier la publication, exécutez un essai limité sur un produit représentatif, avec les mêmes étapes de préparation, de soumission, de suivi et de validation que pour une version destinée aux utilisateurs. L’objectif est de découvrir quel maillon dépend réellement de macOS ; il ne s’agit pas de considérer un envoi API réussi comme un test complet de la chaîne.
Commencez par relever les contraintes de votre équipe : système qui construit le produit, système qui peut signer, emplacement des secrets, outil qui traite le résultat et environnement capable de réaliser l’agrafage ou les contrôles finaux. Ensuite, choisissez une seule voie de soumission pour l’essai. Si votre chaîne Xcode est déjà stable sur Mac, testez d’abord la procédure notarytool existante et identifiez son point de blocage avant d’ajouter une couche API. Si la soumission doit partir d’un environnement non Mac, vérifiez plutôt que l’intégration Notary API couvre bien la demande, le suivi et l’accès au journal, puis confiez explicitement les opérations restantes à leur environnement adapté.
Vous pouvez aussi tester un accès à un Mac distant lorsque les opérations de construction, de signature ou de finalisation ne peuvent pas être déplacées hors de macOS. Cela peut éviter de réserver une machine locale à une étape occasionnelle, mais ne dispense pas de vérifier que l’accès, les outils déjà utilisés par votre équipe et la récupération des fichiers correspondent à votre procédure réelle. Le guide de dépannage et d’aide peut vous aider à examiner les modalités d’accès ; pour une réflexion sur l’usage d’un Mac temporaire, consultez aussi notre article consacré à une solution Mac temporaire pour un besoin de réparation ou de travail.
Le critère final reste l’effort d’exploitation. Un flux entièrement local sur Mac peut être le plus simple si cette machine sert déjà à construire et signer. Une soumission API depuis Windows ou Linux peut être préférable lorsque l’orchestration multiplateforme est une exigence réelle, à condition que l’équipe prenne en charge l’authentification et les erreurs. Un Mac distant peut compléter les deux approches pour les étapes qui nécessitent encore les outils macOS, sans imposer que tout le code ou toute l’infrastructure de compilation y soit transféré.
Si votre chaîne actuelle utilise déjà Xcode sur un Mac, ajouter Notary API peut introduire une intégration et une gestion de secrets sans supprimer de dépendance utile. À l’inverse, une chaîne uniquement Windows ou Linux risque de laisser sans solution la signature, l’agrafage ou la validation si vous ne prévoyez aucun environnement macOS. Pour un besoin ponctuel de ces étapes, la location d’un Mac peut être plus souple que l’achat d’une machine dédiée, sans être la meilleure option pour une charge lourde et permanente ou un besoin d’interfaces physiques locales. Si vous souhaitez tester ce compromis avec VPSNIX, comparez les offres de location Mac à votre fréquence réelle de publication et gardez notarytool ou Notary API pour le maillon qu’ils sont conçus à traiter.